Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!uunet!lotus!patman
From: patman@lotus.com (Pat Mancuso)
Newsgroups: comp.lang.rexx
Subject: Re:  REXX, VM/CMS
Summary: more drivel about unimportant topics
Message-ID: <1991Jan24.170939.11582@lotus.com>
Date: 24 Jan 91 17:09:39 GMT
References: <1991Jan22.022019.5280@ncsuvx.ncsu.edu> <1991Jan23.135615.20072@lotus.com> <2848@sunic.sunet.se>
Sender: news@lotus.com
Reply-To: patman@spice.lotus.com (Pat Mancuso)
Organization: Lotus Development Corp.
Lines: 36

In article <2848@sunic.sunet.se> eric@sejnet.sunet.se writes:
><stuff about the stack>

Granted- I stand corrected.  

>
>EXEC2? Did you mean EXECIO? 
>
>  Eric
No, I meant EXEC2, 'cause EXECIO originated from EXEC2-land.  

(Disclaimer: I have had nothing but bad experiences with EXEC2,
and as such, I am thouroughly biased against EXEC2 and convinced
that it is the root of all evil... :) 

As EXEC2 has no concept of stem variables (see disclaimer), EXECIO's 
STEM option was set up to cater to both REXX and EXEC2.  EXECIO only 
knows enough to create variables with a base name, and suffix them 
with a number.  If you want to use 'em in EXEC2, the base would be LINE, 
and if you want a rexx stem, you use LINE. and it 'just works out' that it
ends up looking (to rexx) like a stem variable.  If there were no EXEC2,
EXECIO (or something better) would not need to be told that its STEM
option should create stem variables (intuitive, no?).  

Yes, you can still use them in REXX as LINE1 and LINE2, but for the cases 
where you *don't* know the number of lines in a data source (such as a list
of the files on a disk...) a stem seems more appropriate.  The overhead
in accessing line.1 and line.2 over line1 and line2 is minimal (given
that you know n=2) and considering that someday n might change to 3 (or 37 for
that matter), the maintenance/code-clarity benefits outweigh it in my
opinion.  

(Hmmm...maintenance?, performance?...what was the question again? ;)

--
Pat Mancuso - patman@lotus.com