home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / rexx / 781 < prev    next >
Encoding:
Text File  |  1992-08-25  |  2.4 KB  |  52 lines
  1. Newsgroups: comp.lang.rexx
  2. Path: sparky!uunet!paladin.american.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!The-Star.honeywell.com!umn.edu!noc.msc.net!uc.msc.edu!apctrc!wsc!mozart!zjlc12
  3. From: zjlc12@hou.amoco.com (Jerry Campbell)
  4. Subject: Re: REXXCOMP versus EXECUPDT (NOUPDATE NOCOM
  5. Message-ID: <1992Aug25.160136.1074@hou.amoco.com>
  6. Sender: news@hou.amoco.com
  7. Reply-To: zjlc12@hou.amoco.com
  8. Organization: Amoco
  9. References: <92237.141853CJS@psuvm.psu.edu>
  10. Date: Tue, 25 Aug 1992 16:01:36 GMT
  11. Lines: 39
  12.  
  13. In article 141853CJS@psuvm.psu.edu, CJS@psuvm.psu.edu (Christopher Sacksteder) writes:
  14. >In article <1992Aug21.190236.4733@hou.amoco.com>, zjlc12@hou.amoco.com (Jerry
  15. >Campbell) says:
  16. >>
  17. >>Look at the file sizes of the resulting compressed files.  Whichever is
  18. >>smaller in size and more efficiently blocked for i/o will be interpreted
  19. >>more quickly by Rexx.  The compression utilities don't change any code
  20. >>they just make it more efficient for Rexx to read and scan the program
  21. >
  22. >I don't think this is right.  REXXCOMP doesn't just "compress" the
  23. >source code.  It preprocesses it and produces a tokenized format, just
  24. >as the first stage of the interpreter does.  For large files, parsing
  25. >the source takes a significant amount of time, which REXXCOMP eliminates.
  26. >The output is always 1 fixed-length record.  (What is "efficiently
  27. >blocked"?)
  28. >
  29. >If you had REXXCOMP (we call it REXXOPT because it isn't a compiler or
  30. >compressor) I don't know why you would use EXECUPDT, except for export
  31. >purposes.  Modifications need to be made to the interpreter in CMS to
  32. >run REXXCOMP'ed files (the interpreter has to know to skip the parse
  33. >stage).
  34. >
  35. >We use REXXCOMP for many production EXECs, and often prefer it to
  36. >results from the CMS REXX Compiler, which can be very large.
  37.  
  38. I was speaking from my experience with CMS Rexx.  I've never heard of a
  39. anything available for CMS Rexx that preprocesses the source in the
  40. way you're talking about.  What does the interpreter do with it?  How does
  41. it recognize that this file has been "tokenized"?  The REXXCOMP we have
  42. around here does nothing but strip out comments and extra blanks and then
  43. block the results into as large a records as it can (so that the interpreter
  44. can read the file more efficiently/quickly (more efficiently blocked)).  
  45. Obviously, you guys have something more sophisticated. 
  46.  
  47. ---
  48. Jerry Campbell   reply to: zjlc12@hou.amoco.com 
  49. Amoco Corp. ISD  SSS/Graphics
  50. Houston, Tx.     713/556-7036
  51.  
  52.