HDTenEightyP/NetNews huggingface dataset:
From: eric@sejnet.sunet.se (Eric Thomas)
Subject: Re: Eric's question
Reply-To: ERIC@SEARN.SUNET.SE
Organization: SUNET, Stockholm, Sweden
Date: Sun, 30 Aug 1992 15:16:20 GMT

In article <ANDERS.92Aug30131227@lise3.lise.unit.no>, anders@lise3.lise.unit.no (Anders Christensen) writes:
>> What a pathetic conclusion - "if you can't do it, it means you 
>> shouldn't do it this way, and not that something is wrong". 
> 
> Is this meant as a sort of quote from my posting?

No, as a summary of the long description I had deleted to save space and which
basically said that my error was to attempt to use the NAMES format on a unix
machine and the solution was to use a format better suited to unix, and not to
complain about the programming language.

>   1) Parsing with a literal pattern containing a Space character, is
>      not the same as parsing words delimited by whitespace into
>      variables and placeholders.
> 
>      The latter will (normally) match a non-empty, non-leading series
>      of 'blanks', with one 'word-delimiter' in the template. Suppose
>      your operating system normally considers words to be separated by
>      not one single character, but any from a class of characters.
>      Then it seems natural to me that implementations of Rexx under
>      that operating system should recognize all characters in that
>      class as possible word-delimiting whitespace.

What nonsense. VMS generally considers TRUE and YES as synonyms for 1, and
NO/FALSE stand for 0. Then it seems natural that any implementation of REXX
under VMS should recognize these values as valid booleans, right? Why not have
'7F'x = 'FF'x on systems which are not 8-bits capable, too? And there are
systems where '00'x stands for a placeholder, a character which doesn't exist
and is skipped when reading the data. I suppose on such systems 'FFFFFF00'x
should be equal to 'FFFFFF'x, and parse should happily skip over the nulls.

>   2) You can solve this by adding regexps. But that might not be wise
>      since it also adds a lot of complexity. If you want to leave
>      regexps (and other extensions) out of it, then you have to write
>      more than one parse clause to do it.

Let's face it, all you need is an expand() function. You don't need regexp, you
don't need to change every single function and internal aspect of the language,
you don't need to make assumptions about when the programmer wants TAB to be a
word separator and the case where he was reading a makefile and wants TAB to be
a TAB, you don't need to add OPTIONS qualifiers. All you need is to expand the
stupid tabs whenever you want them to stand for blanks, ie after acquiring text
data from an external source like a file or a system command. Then it is clear
to all the REXX programmers on the planet what your program does, and there is
no unexpected pitfall or anything like that.

  Eric
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Sun, 30 Aug 1992 11:11:25 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: Eric's question
              30 Aug 1992 15:16:20 GMT from <eric@SEJNET.SUNET.SE>

Eric, your last posting suggests an expanded   ;^)>   syntax for expand:

    expand(source [,whitespacestring])

and now there can be 1M whitespace characters if desired.  Ohh goody!
And those of us who think one is enough can have one.   Dave
Newsgroups: comp.lang.rexx
From: ets@wrkgrp.COM (Edward T Spire)
Subject: Re: Blanks, REXX, and portability...
Organization: The Workstation Group
Date: Mon, 31 Aug 92 14:16:58 GMT

GOMBERG@UCSFVM.BITNET (Dave Gomberg) writes:
: There are really four questions:
: 
: 1. How do we seperate words?
: 2. How do we save disk space?
: 3. How do we save typist hassle?
: 4. How do we make our printed output look nice?
: 
: I claim we ought, on this list, to address only 1.  The others belong on
: the operating system, disk management, word processing, and desktop
: publishing lists.  From the perspective of question one alone, the answer
: is obvious, with a blank.  And just a blank (or two).  And that is what
: TRL documents.  If your OS has let considerations leak from questions 2-4
: into question 1, that is a fault in the design of that system.  Nothing
: on this planet is perfect, least of all mis-designed operating systems.

I would like REXX to be useful in the environment in which it is to be
used.  Hence if it is to parse OS generated output that contains tabs
where one would expect blanks, it is better to modify the REXX
definition to be something useful for that environment rather than
simply curse the darkness.

We're gonna have to modify some REXX definitions to make it useful
outside the narrow boundaries in which it grew up.  The newer OS's do
not have an external data queue, they are generally much more case
sensitive than CMS, they support multi-programming, they will generally
have GUI human interfaces, they will support a heavily networked
environment, etc., etc.  My goodness, if we must live with such a strict
interpretation of the original language definition as "words are
seperated by God-given blanks and nothing else" I wonder how we're ever
gonna adapt REXX to the evolving computing environment.

-Ed
From: GNR100@psuvm.psu.edu
Newsgroups: comp.lang.rexx
Subject: VM/REXX Manual
Date: 1 Sep 92 13:05:21 GMT
Organization: Penn State University


     Could somebody direct me towards a good manual for learning VM/REXX,
along with where to get it and approximate cost?  The languages I currently
know are BASIC, FORTRAN, and C.
        Please Email any responses.

        Thanks,
           Gordon Rogers
           Student -EET
           Penn State University
           gnr100@psuvm.psu.edu
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Sun, 23 Aug 1992 00:48:45 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: PARSE wishlist/brainstorming
              21 Aug 1992 18:57:00 GMT from <SEB1525@MVS.DRAPER.COM>

I am sorry, guys, but I just don't see the stem. bit with parse.

First, I have not seen a syntax that doesn't already have a (different)
meaning.  Second, I haven't seen a syntax I like.

But worst of all, I don't see how this adds much to the language.  For
the case where you have some string that introduces what you want and
some string that terminates it (eg. A=7,B=3,C=4,D=11) where you want the
values being assigned, what on earth is wrong with:

 DO I=1 BY 1 WHILE String<>''
  PARSE VAR String '=' Stem.I ',' String
  END
 Stem.0=I-1

And this type of code generally supports changing delimiters when some
other situation occurs that might change the parsing rules.  Personally,
I don't care if REXX looks like awk or BASIC or any other language.  I
care that it supports its target audience well.   I don't think the
suggestions made so far do that.

If you want to see some unclear on the concept REXX thinking, if you see
what the VM folks have done with pipes (itself a wonderful product) it is
sort of like APL write-only code.  Not a tribute to REXX.  So let's remember
that just because  something could be added to REXX means it should.   Dave
Newsgroups: comp.lang.rexx
From: eric@sejnet.sunet.se (Eric Thomas)
Subject: Re: Eric's question
Reply-To: ERIC@SEARN.SUNET.SE
Organization: SUNET, Stockholm, Sweden
Date: Mon, 31 Aug 1992 15:24:58 GMT

In article <ANDERS.92Aug31144933@lise3.lise.unit.no>, anders@lise3.lise.unit.no (Anders Christensen) writes:
> Are you really suggesting that it is nonsense for a Rexx interpreter
> to follow the conventions of the computer it is running on? (...)
> It also includes (on some systems) converting end-of-line characters and
> end-of-file characters between their representation and their meaning.

No, I am suggesting that you suffer from an unfortunate inability to understand
that system idiosyncrasies are a normal component of functions which interface
with the "external world", such as things which read disk files and convert
system specific file information to something compatible with REXX conventions,
while they have absolutely no place in internal, "abstract" functions which
operate on arbitrary data whose origin is totally unknown and may not come from
the "external world", such as WORDS.

>> Let's face it, all you need is an expand() function. 
> 
> No, TRANSLATE() performs that operation perfectly, as long as you are
> only interested in the whitespaceness of the character, not to
> tranlate it into the right number of spaces.

TRANSLATE requires you to supply a list of the characters which are supposed to
be white space on your system, and it will not handle the wunderblanks that
only indicate font-spacing and are supposed to be deleted entirely. But above
all it does not return something which looks the same if you SAY it; it is not
suitable for use immediately after obtaining the data from the system.

> Great! Then on a Unix system, you have to use two parse clauses
> whenever you want to pull something off the stack and parse it into
> words. One to pull it off the stack so it can be expanded, and then
> one to parse it into the variables.

Am I supposed to cry? REXX has never been and never will be a keystroke saving
language. If you are REALLY concerned about this, you can always add a new
EXPAND qualifier to the PARSE function, it is a logical extension given the
precedent of UPPER.

  Eric
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Thu, 3 Sep 1992 09:42:52 EST
From:         "Scott (nmi) Mattes" <COTRSSM@SEA04VM.NAVSEA.NAVY.MIL>
Subject:      Re: Blanks, REXX, and portability...
Comments: To: Multiple recipients of list REXXLIST <REXXLIST@ucf1vm.cc.ucf.edu>

On Thu, 3 Sep 1992 09:56:21 EDT Turgut Kalfaoglu said:
>Does anyone know if there is a profiler available for Rexx? (one that
>would show how often functions are called, how much time was spent in
>each one, etc..) I found a such thing for C, and I was really impressed
>with it. Like Eric, I have to maintain a rather large, but similar :)
>tool.  -turgut

  There is one for CMS.  It is HISTOREX and is available on VM-UTIL or
via FTP at KSUVM in the VMTOOLS directory as file WORK53 VMARC.

--------------------------------------+----------------------------------------
Scott (nmi) Mattes                    | No success can compensate for failure
Work: COTRSSM@SEA04VM.NAVSEA.Navy.Mil | in the home.  David O. McKay, Prophet
Home: 73027.3270@CompuServe.COM       | and President of the Church of Jesus
Voice: (703) 769-2917                 | Christ of Latter-day Saints, 1951-70
Newsgroups: comp.lang.rexx
From: giguere@csg.uwaterloo.ca (Eric Giguere)
Subject: Life is full of compromises
Originator: giguere@csg.uwaterloo.ca
Organization: Computer Systems Group, University of Waterloo
Date: Fri, 28 Aug 1992 18:22:23 GMT

Life is full of compromises.  So are standards.  I, for one, am disappointed
in seeing an innocent question about what "blanks" are degenerate into an
opinionated debate about the proper (or improper) design and mindsets of
certain operating systems.

If REXX is to be successful, it _has_ to be able to adapt to the idiosyncracies
of the various operating platforms.  If it doesn't, the _users_ of those
platforms will be very annoyed.  Users don't care about philosophical debates,
they only want to get their work done.  If they work on a system where "blanks"
routinely means more than just a "space" character, then they'll expect any
REXX interpreter on that system to handle it.  (By the way, it's not just Unix
that does this... this is also common behaviour on most micros.)  To most
users REXX cross-platform portability is a non-issue.  It's no use sitting on
your high horse and telling them that they're not doing it The Right Way or
using A Real System.  I would rather program in OS/2 than Windows, but I don't
at this point because my job requires the latter and I like getting my monthly
paycheque.

That's why I worry sometimes that CMS is perhaps having too much of an
influence on the way REXX is being standardized.  I hope that's not the case.
REXX's future really lies with other operating systems, and we should try to
use the best ideas from all platforms.  Otherwise implementors will ignore
any standards that may be defined.  ARexx is a good case in point.  It's
got enough variations in it that the ANSI committee will have a hard time
bringing it completely "into the fold".  It's also proven to be extremely
popular and _useful_ to Amiga users.  You don't need to follow a standard
to succeed.  But it would be sad if following a standard leads to failure.

-- 
 Eric Giguere                                    giguere@csg.UWaterloo.CA
          So is Windows NT short for "Windows, NOT?"  
Newsgroups: comp.lang.rexx
From: giguere@csg.uwaterloo.ca (Eric Giguere)
Subject: Stealing ideas from Unix (was Re: Blanks, REXX, and portability...)
Organization: Computer Systems Group, University of Waterloo
Date: Tue, 1 Sep 1992 17:50:46 GMT

In article <1992Sep1.165241.1@sejnet.sunet.se> ERIC@SEARN.SUNET.SE writes:
>Ok Scott, say I give you a unix playstation with a copy of the source code for
>LISTSERV (25-30k lines of REXX), and pay you by the hour to make it work under
>unix. How much money will I save if I give you a REXX interpreter to make the
>conversion easier?
>
>The answer is I'll lose money, because it will take you about 1-2 months to
>realize it is much faster to rewrite everything in C than to try to reuse the
>REXX code with the interpreter.

The smart answer would probably be: do it in Perl. A step above C in 
abstraction, but built around the Unix mentality and supports all the 
networking functions you'd need....

And people, don't get me wrong:  it's not that I don't support this debate
over the use of spaces in REXX, but please let's keep cool heads about us.
Not only will that prevent people from tuning out of the debate (because that's
what I do when a "mine is better than yours" mentality prevails), it'll also
keep the message lengths shorter.

Here's a related topic I think would make for some interesting discussion:
how do we adapt REXX to the Unix environment?  Or better yet, What can we
learn from the Unix environment to improve REXX?  Unix supports a number
of scripting/shell languages.  Whether any one of them is "better" than REXX
is a matter of opinion, but I don't think we can deny that the mentality
that influenced their design is different from design decisions that influenced
REXX.  I know Ed & Nick have thought about this a lot, and Anders, but I
think that their ideas have revolved mostly around "how can I get REXX 
running on Unix?" and not "what ideas from Unix can I incorporate into REXX?".
And it's not just Unix, really.  OS/2 and Windows (both regular and NT) also
deserve consideration, though perhaps they won't bring the same concrete
ideas that Unix will.  Do we just need a bunch of new BIFs?  (I have some
opinions, but I'll post them separately.)

And PLEASE, NO CROSSPOSTING!  Let's not turn this into a REXX vs. Perl war
again.  Keep your posting to comp.lang.rexx and the mailing list.  Thanks.

-- 
 Eric Giguere                                    giguere@csg.UWaterloo.CA
          So is Windows NT short for "Windows, NOT?"
From: ets@wrkgrp.COM (Edward T Spire)
Subject: Re: Blanks, REXX, and portability...
Organization: The Workstation Group
Date: Fri, 4 Sep 92 15:46:21 GMT

eric@sejnet.sunet.se (Eric Thomas) writes:
: In article <1992Sep2.162052.25264@wrkgrp.COM>, ets@wrkgrp.COM (Edward T Spire) writes:
: > 3.  REXX is used as a macro language for other applications (XEDIT
: > and ISPF come to mind) that have themselves been "ported".  XEDIT macros
: > ported from CMS to Unix port very nicely indeed (since the primary
: > addressible environments are very similar).
: 
: No question here. But wouldn't the unix version of XEDIT exhibit the same kind
: of behaviour as the CMS version? Or does it, too, use tabs in the data returned
: by (say) EXTRACT?

Not normally, but if you were editing a makefile that had tabs as part
of the data lines and you extracted a data line...

: > 4.  Even if you did need to essentially re-implement a large OS macro
: > on Unix, doing it in REXX again may be your best choice.  You cannot be
: > as productive in C or PERL (unless you code these languages all day
: > long every day, and even then I doubt it...)
: 
: I hope this is a joke. I don't want to make a 300-lines post explaining why
: REXX is unsuitable for large applications, but believe me, you spend more time
: reaching your business goals (especially in the area of performance) than you
: might ever possibly waste rewriting all the REXX library functions in C and
: then keying in the extra keystrokes C requires. Note that I despise C and will
: go a LONG way to avoid having to use it.

I am not joking, nor are the other folks who choose this route.
Hardware performance bottlenecks are becoming less important as
price/performance ratios change.  Note that I'm writing this on a
25 MIP RS/6000 that is essentially a single user system.

-Ed
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Thu, 27 Aug 1992 11:23:47 EST
From:         Paul Russell <PRUSSELL@IUBVM.BITNET>
Subject:      Re: Blanks, REXX, and portability...
              27 Aug 1992 06:30:35 LCL from <anders@LISE3.LISE.UNIT.NO>

On Thu, 27 Aug 1992 06:30:35 LCL Anders Christensen said:
... lots of stuff deleted ...
>Someone posted earlier that CMS programmers often tend to regard the
>format of data as very constant, e.g. that the interesting portion of
>the output from command XXX starts in column 42, and is 8 characters
>long. That is very different from the Unix approach, in which the
>exact column where things start is often not constant, and where the
>number of whitespace-separated words in the output is used to find the
>right data. The difference can be seen from these two examples
>
>    parse var foo 42 user +8
>    parse var foo . . . user .
>
>Rexx is powerful enough to handle both approaches. But this will only
>work on Unix machines, if Unix Rexx interpreters are allowed to
>interpret all Unix' whitespace characters as blanks.
... more stuff deleted ...
I've been following this discussion for several days and have found it
both interesting and enlightening.  I was a little concerned about the
general nature of the statement cited at the beginning of the excerpt
above, however, I let it pass without comment, because I didn't feel
that an editorial comment would add value to the discussion.  However,
since it now appears that the original statement has been accepted as
gospel, I think that it's time to add my 2 cents worth, to wit: *SOME*
CMS REXX programmers (including me) do parse *SOME* things on the basis
of hard-coded "column" numbers, *IF* the format of the data is constant.
However, it has been my experience (however limited you might perceive
that to be) that the format of the data is seldom constant, so, it seems
that *MOST* CMS REXX programmers parse data on the basis of white-space-
delimited words and/or the presence of known constants at least as often
as they parse data on the basis of hard-coded "column numbers".  Jumping
to the conclusion that *ALL* CMS REXX programmers have an "80-column
card" mindset is just about as valid as jumping to the conclusion that
*ALL* U**X programmers are (insert your favorite pejorative here).  8-)
I can hardly remember the last time that I used an 80-column card, but
I'm sure that I was writing a grocery list on the back.  8-)  pdr
Newsgroups: comp.lang.rexx
From: grossman@cs.ucf.edu (David Grossman)
Subject: Rexx under VM/XA
Organization: University of Central Florida
Distribution: na
Date: Fri, 28 Aug 1992 17:17:15 GMT

I am interested in rewriting some REXX code that currently runs under
VM to take advantage of additional memory available under a larger
virtual machine under VM/XA. I am curious if anyone has any comments about
the potential for performance improvements (I realize that you are still going
to be swapping out pages to disk). Some additional questions are:

1. Is their a limit on the program stack size under VM/XA or does it
   take advantage of the larger virtual storage as well.

2. Is there any documentation on how compound variables are "found." If I
   do a test on DATATYPE(LIST.Y.COUNT) and Y='HIPPO' to see if there is
   already an entry under 'HIPPO' how is this search conducted? The 
   temptation with a large enough virtual machine is to use larger
   arrays with compound variables instead of writing to temporary files.

3. Are there any CMS commands to assist in taking full advantage of the
   larger virtual machine?

Any help would be appreciated.

DG
Newsgroups: comp.lang.rexx
From: anders@lise3.lise.unit.no (Anders Christensen)
Subject: Re: Blanks, REXX, and portability...
Organization: /home/flipper/anders/.organization
Date: 28 Aug 92 02:13:58

In article <REXXLIST%92082716163624@UGA.CC.UGA.EDU> Dave Gomberg <GOMBERG@UCSFVM.BITNET> writes:

> Maybe the following comprimise on standards handling of white space is
> acceptable:
>
>   1.  The standard thruout uses the word blank.
>
>   2.  This text is added:  "Some operating systems routinely use more than
>       one character as meaning the same [...]

That is the "status quo" solution, It really does not say anything
more than 2nd ed of TRL, except from the note that the concept of
'blank' is likely to differ between operating systems. 

If no other solution is acceptable, then that is the best solution,
since it leaves the TRL as is (most people acknowledges TRL as the
basis of the standard). The same solution should be chosen in other
situations where agreement is impossible to achieve. Many may not
think that is is the _perfect_ solution, since it is not very
specific, but I assume that it at least is the solution acceptable to
most parties.

With this flame-war on REXXLIST/comp.lang.rexx, one thing has at least
been achieved: the probability that the problem is going to be
discussed at the coming ANSI REXX meeting has increased ... :-)

>       If there is no consensus among users as to which characters are
>       equivalent to blanks, then only the blank character should be so
>       implemented."

I am not really sure how to interpret this. As long as "users",
"consensus" and "be implemented" (implemented where? and by whom?) is
rather unspecified, I think that sentence should be left out.

-anders
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Fri, 4 Sep 1992 11:04:04 IST
From:         Moshe Barak <CCSMBRK@TECHNION.BITNET>
Subject:      UNERASE for CMS 7

Hello,
Does anyone knows of an UNERASE program for ESA 1.0 , CMS 7 ?
Thanks,
Moshe
From: martinc@grover.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.lang.rexx
Subject: Re: newbie rexx programmer asks silly questions
Date: 3 Sep 92 22:36:28 GMT
Organization: UNC Department of Computer Science
In-reply-to: COTRSSM@SEA04VM.NAVSEA.NAVY.MIL's message of 3 Sep 92 17:42:52 GMT

Thanks to everyone who has replied: it's clear that my major problem is
a buggy rexx on UNIX.  The other point people mentioned ('/' versus '\')
was a typo I introduced by dyslexing while typing the example.

Now, what about DOS rexx implementations?  personal REXX from Mansfield
Software in CT is the only one I've seen mentioned so far....
--
Charles R. Martin/(Charlie)/martinc@cs.unc.edu/(ne crm@cs.duke.edu) 
O/Dept. of Computer Science/CB #3175 UNC-CH/Chapel Hill, NC 27599-3175
H/3611 University Dr #13M/Durham, NC 27707/(919) 419 1754
----------------------------------------------------------------------
"I am he who walks the States with a barb'd tongue, questioning every
one I meet,/Who are you that wanted only to be told what you knew
before?/ Who are you that wanted only a book to join you in your
nonsense?"  _Leaves of Grass_ xxiii.4.
Newsgroups: comp.lang.rexx