Greetings Erich,
Erich Steinböck wrote:
Any ideas on how this was meant to be when it was designed?
I never claim to be the best expert at REXX history, however...
On Mainframe, I believe either the Stream concept came much later or still is
not there at all.
On OS/2 / Windows / Linux... Object Rexx... there is support for both Classic Rexx File I/O functions, and the Object Rexx class based File I/O. The Object based File I/O quite well encapsulates the
former Classic Rexx File I/O functions. I am not certain how all the legacy support (Classic Rexx running under ooRexx) has been mapped. Back in the Object Rexx v2.x days, there were some attempts to
improve the performance of Object Rexx running Classic Rexx function call based File I/O in not having it create and destroy so many Stream Objects behind the scenes.
Oh.... then there was I believe File I/O on the Array class in the v1.0.3.0
days. Later IBM Germany worked to improve the poor performance of that
implementation by supporting...
/* Check fow how many lines the file has */
FILEsize = file~command('QUERY SIZE')
/* Read in the file */
/* This code requires at least ORexx 2.1.1 on Win32 - only tested with
>=2.1.2 */
INstr = file~charin(1, FILEsize)
FINDarray = INstr~makearray()
MakeArray() method off the String class. And for output...
/* Write out the file */
/* This code requires at least ORexx 2.1.3 on Win32 */
file~LineOut(FINDarray~MakeString())
So apparently IBM Germany provided one higher performance method in the String Class and the other higher performance method was later added to the Array Class. That pair of methods were added in the
ORexx 2.x era, never in the ORexx 1.0.3.0
At RexxLA symposiums, must have been early 2000's, I spoke with the IBM Germany developers about the poor performance performing File I/O via class methods, and they seemed unwilling to touch that
part of the ORexx code. So in my mind... "replace (with the above two added API's) rather than touch the ORexx methods that did exist back then." Back then, ORexx 1.0.3.0, File I/O had a recursively
growing lag in processing files when the number of lines would grow.
Perhaps the code is a bit of a patchwork quilt in that it is expected to
execute all possible eras of CRexx / ORexx / ooRexx code?
<><><><>
So about Rexx and file write in append mode... as far as I know that method of output is true append. So a Windows system opens in append, issues LineOut calls, and results in lines being added with
CrLf line endings. A Linux ooRexx program writes more to the same file, opening in append mode, LineOut calls result in lines being added with Lf line endings. I would think if the same were done on
Mac, then lines would be added with Cr line endings. So writing to a shared file with ooRexx code running on multiple operating systems could produce a file with mixed line endings.
Erich Steinböck wrote:
Do we have a third WRITE mode - non-APPEND, non-REPLACE - that needs to be
documented?
What characteristics would the third WRITE mode have? Ignore "non"
capabilities... those show what it lacks. What is left as a capability to yet support?
I am thankful,
--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
