home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / rexx / 1018 < prev    next >
Encoding:
Text File  |  1992-09-15  |  1.5 KB  |  41 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!paladin.american.edu!auvm!SERVER.UWINDSOR.CA!OPHOF
  3. X-Mailer: ELM [version 2.3 PL11]
  4. Message-ID: <9209142024.AA09315@SERVER.uwindsor.ca>
  5. Newsgroups: comp.lang.rexx
  6. Date:         Mon, 14 Sep 1992 16:24:37 EDT
  7. Sender:       REXX Programming discussion list <REXXLIST@UGA.BITNET>
  8. From:         Scott Ophof <ophof@SERVER.UWINDSOR.CA>
  9. Subject:      LINEOUT() behaviour
  10. Comments: To: REXX Discussion list <REXXLIST@uga.cc.uga.edu>
  11. Lines: 28
  12.  
  13. Sub:  LINEOUT() behaviour
  14.  
  15. From the olden days I remember that doing LINEOUT(name,string,n)
  16. to a file containing more than "n" lines resulted in loss of all
  17. lines past "n", and thus hurriedly dropped its use...
  18.  
  19. "The REXX Language" (2nd edition) sounds different to what I
  20. remember of the 1st ed.  It now seems to be an implementation-
  21. dependant matter.  Is this feeling of change correct?
  22. Side note:
  23.    And if so, what's stopping IBM from implementing the I/O model as
  24.    defined by TRL for their mainframe REXXes?  It should be a vast
  25.    improvement over EXECIO...  ;-)
  26.  
  27. The idea of writing (say) a line of 20 chars in the middle of a file
  28. and not deleting the remaining (say) 13 chars of the overwritten
  29. line seems rather horrifying behaviour to me.  Same if (say) 40
  30. chars were written, thus overwriting 7 chars (minus EOL chars, of
  31. course) of the next line...
  32. This example assumes the file is a stream of bytes (like - but not
  33. only - in UN*X).
  34. There's no problem with record-oriented systems, I think.
  35.  
  36. Your views, please?
  37.  
  38.  
  39. Regards.
  40. $$/
  41.