HDTenEightyP/NetNews huggingface dataset:
From: martinc@grover.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.lang.rexx
Subject: Re: Blanks, REXX, and portability...
Date: 7 Sep 92 02:29:25 GMT
Organization: UNC Department of Computer Science
In-reply-to: GOMBERG@UCSFVM.BITNET's message of 7 Sep 92 00:53:16 GMT

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

   I certainly did not understand what you meant correctly.  I thot that
   a shouldn't match b or c to mean a shouldn't match b and a shouldn't
   match c.   If I understand what you meant, you meant a shouldn't
   match b or else a shouldn't match c.  If the latter is what you mean,
   I just don't understand your point, so I cannot agree or disagree with
   it.  Perhaps you could restate it??   Dave

sure: the position operator should match the true characters: pos("a b"...) 
should hit on the substring "a<blank>b" in the target, not on the
substring "a<tab>b".
--
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.
From: eric@sejnet.sunet.se (Eric Thomas)
Newsgroups: comp.lang.rexx
Subject: Re:      Re: Blanks, REXX, and portability...
Date: 8 Sep 92 15:40:48 GMT
Reply-To: ERIC@SEARN.SUNET.SE
Organization: SUNET, Stockholm, Sweden

In article <19920907131702SEB1525@MVS.draper.com>, SEB1525@MVS.draper.com (Steve Bacher) writes:
> At least with the more reasonable proposals,
> 
>  PARSE VALUE DIAG(something) WITH var1 var2 '15'x var3 var4 '15'x var5
> 
> should continue to work just fine, regardless of whether '15'x is
> considered whitespace or not.  A correct implementation of REXX will
> break up the line at the '15'xes and only then perform the whitespace
> analysis on the resulting pieces.

Yes, that much will work, and it is indeed what people generally code to
process the output of commands which produce a fixed-size answer (like when
extracting the time zone name from QUERY TIME). But there are many commands
which produce variable-size output that one processes in a loop (example: QUERY
NAMES). What bothers me is that we now have '15'x = ' ', a situation most
programmers must NOT have quite expected. My own programs would not be affected
since I always use ==, but the amount of spontaneous religious flames I get
about this usage from people who have read my code for the first time suggests
that most programmers do use = and thus their programs would break.

  Eric
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Fri, 4 Sep 1992 17:14:08 CDT
From:         "Mark R. Williamson" <MARK@RICEVM1.RICE.EDU>
Subject:      Re: newbie rexx programmer asks silly questions

On Fri, 4 Sep 1992 09:56:01 PDT Dave Gomberg said:
>What, please, is the Programmer's Shop Catalog?

It is a catalog of DOS, Windows, OS/2, and Unix tools for programmers,
published by The Programmer's Shop; 90 Industrial Park Road; Hingham,
MA 02043; 1-800-421-8006; 1-617-740-2017; FAX 1-617-740-4233 or -1872.
They also have branches in Germany and Italy.  The catalog is 188pp in
it's most recent incarnation, which just happened to be on top of my
stack of recent incoming mail.

I've never ordered anything from them.  (They don't do Macs or mainframes,
which is where I do most of my work.)  Now I know why I didn't toss it out.

Mark R. Williamson, Rice U., Houston TX; MARK@RICEVM1.RICE.EDU or @RICEVM1
From: SEB1525@MVS.draper.com (Steve Bacher)
Newsgroups: comp.lang.rexx
Subject: Re:      Re: Blanks, REXX, and portability...
Date: 7 Sep 92 18:17:00 GMT
Organization: Draper Laboratory

In article <1992Sep6.022654.1@sejnet.sunet.se>,
eric@sejnet.sunet.se (Eric Thomas) writes:

>Under VM, isspace() is true for X'05' and X'15'. It is logical for isspace() to
>be true for these characters, since they are the EBCDIC equivalents of TAB and
>CRLF, respectively; as far as I know, all the C compilers for VM agree on this.
>I'm not really eager to find out what happens to my tens of thousands of lines
>of code the day X'15' is suddenly treated as a blank. It is used as a
>line-separator in functions like DIAG, and it is common programming practice to
>use it as a line separator when returning more than one line of (non-binary)
>data from a function. I suppose a similar situation exists for \n on unix
>systems, but I've never used REXX on unix so I wouldn't know.

At least with the more reasonable proposals,

 PARSE VALUE DIAG(something) WITH var1 var2 '15'x var3 var4 '15'x var5

should continue to work just fine, regardless of whether '15'x is
considered whitespace or not.  A correct implementation of REXX will
break up the line at the '15'xes and only then perform the whitespace
analysis on the resulting pieces.  (Ed, you fixed this in UniREXX,
didn't you?)

Disclaimer:  I'm not a VMer, so don't take my sample syntax literally.

--
Steve Bacher (Batchman)                 Draper Laboratory
Internet: seb@draper.com                Cambridge, MA, USA
From: martinc@grover.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.lang.rexx
Subject: Re: Blanks, REXX, and portability...
Date: 6 Sep 92 22:39:49 GMT
Organization: UNC Department of Computer Science
In-reply-to: GOMBERG@UCSFVM.BITNET's message of 5 Sep 92 19:56:47 GMT

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

   On Sat, 5 Sep 1992 15:44:05 -0400 cultural elite said:
   >PARSE EXPAND is not such a simple solution, as in some situations it will
   >require tracking both the expanded and unexpanded copies of input lines.

   No it wouldn't.  Why would it?   PARSE EXPAND VALUE psrc WITH template means
   the same as $temp=expand(psrc); PARSE VAR $temp template  , right?

I think the problem lies in repeated applications of parse, say with
columnar fields.  Say I parse the string "ab\tc" -- importing a little C
terminology to make clear where the tab lies -- with parse expand.  The
tab char should come out to be some number of blanks, as I understand
it. (Probably 6 for canonical tabs.)  But if I parse off the first
field, THEN parse the resulting "\tc", the tab now wants to expand to 8
characters.  You can't keep the two interpretations straight without
storing information about the line as it was for later use by parse.
--
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.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Delivery-Notice:  SMTP MAIL FROM does not correspond to sender.
X-Mts: smtp
Newsgroups: comp.lang.rexx
Date:         Tue, 8 Sep 1992 12:26:23 -0400
From:         cultural elite <dsr@LNS598.TN.CORNELL.EDU>
Subject:      Re: Blanks, REXX, and portability...
Comments: To: General REXX Language Discussion List
              <REXXLIST@ucf1vm.cc.ucf.edu>

Eric Thomas <eric@SEJNET.SUNET.SE> writes:
>In article <9209051944.AA18020@lns598.TN.CORNELL.EDU>,         cultural elite
><dsr@LNS598.TN.CORNELL.EDU> writes:
>> I agree, that would be ridiculous.  Not even Unix (with the possible
 exception
>> of a few broken utilities) behaves that way.
>
>With the possible exception of, for instance, scanf(), the C formatted read
>routine.

Ok, score one for Eric--I have always thought that scanf() is more than
a bit brain-damaged.

>Ever tried to use scanf() to read a one-word reply from the terminal,
>and use a default value if the user just hits RETURN?

Nope, I avoid scanf().  (See above...)  If I have to, I'll use fgets()
and sscanf().

>The problem is that if you want to change the language definition of all these
>functions, you have to come up with a solution that is clearly defined and
>works for all systems, not just unix. One such solution, which is what I
>understood all the previous postings were proposing, is that positional PARSE
>et al are to treat any character for which isspace() returns TRUE as white
>space.

Using isspace() on all platforms would *not* be a clearly defined, well
thought out solution.  isspace() is not well standardized on Unix platforms,
and isspace() on some non-Unix machines is seriously compromised by the
peculiar requirements of the C standard library, and attempts to make the
system Unix-like.  This makes it a terrible choice for Rexx, which should
do its best to cater to the native environment (which is what this discussion
is all about, right?), not impose some Unix/C biased preconception on every
platform.

So I consider

>Under VM, isspace() is true for X'05' and X'15'. It is logical for isspace() to
>be true for these characters, since they are the EBCDIC equivalents of TAB and
>CRLF, respectively; as far as I know, all the C compilers for VM agree on this.

to be a non-issue.  It is also an implementation detail, not a fundamental
objection.
--
Dan Riley                          Internet:   dsr@lns598.tn.cornell.edu
Wilson Lab, Cornell University     HEPNET/SPAN: lns598::dsr (44630::dsr)
	 "Maybe, leastways is the best way of all" -Caterwaul
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: comp.lang.rexx
Date:         Mon, 14 Sep 1992 16:24:37 EDT
From:         Scott Ophof <ophof@SERVER.UWINDSOR.CA>
Subject:      LINEOUT() behaviour
Comments: To: REXX Discussion list <REXXLIST@uga.cc.uga.edu>

Sub:  LINEOUT() behaviour

From the olden days I remember that doing LINEOUT(name,string,n)
to a file containing more than "n" lines resulted in loss of all
lines past "n", and thus hurriedly dropped its use...

"The REXX Language" (2nd edition) sounds different to what I
remember of the 1st ed.  It now seems to be an implementation-
dependant matter.  Is this feeling of change correct?
Side note:
   And if so, what's stopping IBM from implementing the I/O model as
   defined by TRL for their mainframe REXXes?  It should be a vast
   improvement over EXECIO...  ;-)

The idea of writing (say) a line of 20 chars in the middle of a file
and not deleting the remaining (say) 13 chars of the overwritten
line seems rather horrifying behaviour to me.  Same if (say) 40
chars were written, thus overwriting 7 chars (minus EOL chars, of
course) of the next line...
This example assumes the file is a stream of bytes (like - but not
only - in UN*X).
There's no problem with record-oriented systems, I think.

Your views, please?


Regards.
$$/
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Mon, 7 Sep 1992 14:38:59 EDT
From:         Turgut Kalfaoglu <TURGUT@FRORS12.BITNET>
Subject:      Re: Ah Mr Rexx ....
              4 Sep 92 03:15:36 GMT from <ins141f@AURORA.CC.MONASH.EDU.AU>

Rexx is a high-level language that vaguely resembles BASIC or Pascal.
You can virtually program everything with it - even huge programs.
It is a very confortable language. Versions are available for several
platforms including MS-DOS, Amiga, VM mainframes. It also comes standard
with IBM OS/2. -turgut
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Organization: Institut fuer Medizinische Computerwissenschaften
Newsgroups: comp.lang.rexx
Date:         Thu, 10 Sep 1992 09:22:08 CDT
From:         Christian.J.Reichetzeder@AWIIMC12.IMC.UNIVIE.AC.AT
Subject:      Re: Reading inline "code" as input?

On Wed, 9 Sep 92 15:49:30 MEZ Otto Stolz said:
>On Wed, 9 Sep 92 11:27:24 GMT Horst Kiehl said:
>> (Aside, an unmatched "*/", outside comments, is allowed.)
>This is a sloppy implementation. Your interpreter should warn you of
>unmatched closing delimiters, as well.
There is  no "unmatched */"  - if  no comment is  active then it's  a multiply
operator followed  by a divide  operator, and  this should result  in "invalid
expression".

Christian
From: drake@drake.almaden.ibm.com (Sam Drake)
Newsgroups: comp.lang.rexx
Subject: Re: Blanks, REXX, and portability...
Date: 8 Sep 92 05:53:17 GMT
Organization: IBM Almaden Research Center

Excuse me, I'm late to this debate, and frankly the discussion here is
seriously in the ditch.  I've read 42 items in this thread, and it's
pretty clear that y'all aren't quite listening to each other anymore.

Can someone, calmly, explain for my own edification what's wrong with:

In article <MARTINC.92Sep7104222@grover.cs.unc.edu> martinc@grover.cs.unc.edu (Charles R. Martin) writes:
>But I think the point is that in the parse operation, with something
>like
>
>line='foo 	bar 	bletch' /* that's <space><tab> */
>parse var line a b c
>
>it makes sense to have a='foo', b='bar', and c='bletch', and to have
>parse eat both whitespace characters just as it already eats any string
>of blanks between non-blank maximals.  

I'm just a simple guy, but I can't think of anything wrong with this.
What's the argument on this point, if any?  Several folks have suggested
this, and no one has disagreed that I can see, but the issue doesn't 
seem to be closed.  


Sam Drake / IBM Almaden Research Center 
Internet:  drake@almaden.ibm.com    BITNET:  DRAKE at ALMADEN
From: c23mld1@kocrsv01.delcoelect.com (Marc DeWever)
Newsgroups: comp.lang.rexx
Subject: REXX on UNIX?
Date: 8 Sep 92 19:04:46 GMT
Reply-To: c23mld1@kocrsv01
Organization: Delco Electronics Corp.
Originator: c23mld1@kobcsw04


Are there any public domain implementations of REXX available for 
Unix systems, and if so where can they be found?

-- 

Marc L. De Wever                 Domain: c23mld1@kocrsv01.delcoelect.com
S/W engineer, Delco Electronics  UUCP: deaes!c23mld1
From: johnv@acix.DIALix.oz.au (John Verhoeven)
Newsgroups: comp.lang.rexx
Subject: Re: Requesters.. How do i get rid of 'em..
Distribution: world
Date: 9 Sep 92 16:54:18 WST
Organization: ACix - Private UUCP Node, Cloverdale, Western Australia.

In article <jasienrt.03oi@outb.wimsey.bc.ca> jasienrt@outb.wimsey.bc.ca (Jason Sienart) writes:
>In ARexx.. How can i check if an assign/disk/partion exists. Well what i mean
>is how can i find out if it exists without a requester poping up. I phone my
>computer from remotely and hate crashing my BBS with a requester waiting for me to insert hhh: in any drive..

try:

if ~showlist('V','FOO') then	/* no colon needed, device name must be in uppercase */
	/* do something */
end

'V' shows disk volumes
'A' shows assigns
'H' shows devices

1> "say showlist('V')      
RAM_DISK NEWS DEVELOPMENT RECORDS ANIMATIONS RAD_DISK SYSTEM2.0

1> "say showlist('A')
ENVARC SYS C S LIBS DEVS FONTS L CLIPS T TMP FD AUTODOCS FORTUNE VLT LINT
II1 IH2 IH1 UUCP UUMAN DH0 PROWRITE ANL AMIGAVISION TUTORIAL_2 TUTORIAL_1
SBPRO4 DELUXEPAINTIII DPAINTIV DPAINT QUARTERBACK M2 M2L GCC LOCAL DEV ETC
LIB USR BIN INSTRUMENTS SCORES ENV CONTACT REXX AUTODOC_PAGES II2 IH3
DOWNLOADS UUSPOOL UUPUBW UUPUB UUNEWS UUMAIL UULIB GETTY ARCHIVE

1> "say showlist('H')
MSH CON PIP IXPIPE NULL AUX SPEAK RAM RAW SER PAR PRT WB_2.X DF0 UNIX_BOOT
RAD DF2 DH4 DH1 DH2 DH3

--

John Verhoeven                        johnv@acix.DIALix.oz.au      _--_|\
Treasurer, Amiga Developers           (ALT: johnv@DIALix.oz.au)   /      \
Association of Western Australia      Phone: (+619) 478 1406      *_.--._/

Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Delivery-Notice:  SMTP MAIL FROM does not correspond to sender.
X-Mts: smtp
Newsgroups: comp.lang.rexx
Date:         Tue, 8 Sep 1992 12:32:48 -0400
From:         cultural elite <dsr@LNS598.TN.CORNELL.EDU>
Subject:      Re: Blanks, REXX, and portability...
Comments: To: General REXX Language Discussion List
              <REXXLIST@ucf1vm.cc.ucf.edu>

Dave Gomberg <GOMBERG@UCSFVM.BITNET> writes:
>Well, the Unix folks have rather dug themselves a hole on that one,
>haven't they, Charlie.  It's not just a question of parse, what about
>substr, or left/right.

What about them?  I would think substr(), left() and right() would be
unaffected.

>They will have the same problem.  I guess we
>could say that just because c=a||b doesn't mean expand(c)=expand(a)||
>expand(b).  But we knew that already.  And your parse example is just
>this problem in another guise.  In fact, the Unix folks have a worse
>problem.  You can have c=a||b, but pos(a,c)=0!  Wow!  I don't think
>I want that in MY os.  But there is no accounting for taste!   I would
>really like Anders (I assume the first letter is in fact capitalized)
>and other Unix types to say if they can stand it that:
>
>    c=a||b;  say pos(a,c)
>
>would say 0?  It is not what I mean by REXX.  Sorry this rambles so.  Dave

Ok, call me blind, I but I can't see this hole I seem to be in.  You'll
have to explain how you get c=a||b; pos(a,c)=0 out of any sensible
proposal.

--
Dan Riley                          Internet:   dsr@lns598.tn.cornell.edu
Wilson Lab, Cornell University     HEPNET/SPAN: lns598::dsr (44630::dsr)
	 "Maybe, leastways is the best way of all" -Caterwaul
Newsgroups: comp.lang.rexx
From: stud02@cc4.kuleuven.ac.be (Kris Van Hees)
Distribution: world
Date: Wednesday, 2 Sep 1992 17:51:47 +02
Reply-To: stud02@cc4.kuleuven.ac.be
Organization: K.U.Leuven - Academic Computing Center
Subject: Question about stems and storage...

Hello,
I have a question concerning Rexx on the VM mainframe (VM/XA btw).  In my
server I accept multiple socket connections through TCP/IP and a lot of
information about each socket has to be stored.  This information is stored
in a stem.  E.g. the connecting node for socket 5 is stored in G.5.NODE .
Now, when a socket gets closed I would like to release the storage used by
the sockets information stored in the G. stem.  However, as far as I have
been informed, simply dropping all elements of G. which concerned that
closed socket won't free the storage they used.  Only when the complete
stem is dropped storage is free'd.  Normally this wouldn't really bother me
but when considering the size of the stored info (can be several Kb/socket)
free'ing the storage would be quite useful.
Of course, I could use a different stem for each connection, but how could
I address that stem without using interpret (which is slow and therefore not
recommended for this case)?
Regards,
Kris Van Hees.
------
GUTEST6@cc1.kuleuven.ac.be
       @BLEKUL11.BITNET
stud02@cc4.kuleuven.ac.be
Newsgroups: comp.lang.rexx
From: eric@sejnet.sunet.se (Eric Thomas)
Subject: Re:      Re: NOVALUE (was: Blanks, REXX, and portability...)
Reply-To: ERIC@SEARN.SUNET.SE
Organization: SUNET, Stockholm, Sweden
Date: Sun, 13 Sep 1992 01:24:49 GMT

In article <REXXLIST%92091210543821@UGA.CC.UGA.EDU>,         Dave Gomberg <GOMBERG@UCSFVM.BITNET> writes:
> Wait, if you intended to have x have the value 123 but by mistake it was
> undefined, then are you saying that just by lucky accident a.x WAS defined?

No, he intended X to have the value 123, by mistake X was undefined, and A.X
was defined because the stem had received a default value via assignment to
'A.', and he isn't the only one to have had that problem. As usual I don't
agree with the choice made in the language definition, and as usual I'm not on
the majority's side.

  Eric
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
From: eric@sejnet.sunet.se (Eric Thomas)
Subject: Re:      Re: Blanks, REXX, and portability...
Reply-To: ERIC@SEARN.SUNET.SE
Organization: SUNET, Stockholm, Sweden
Date: Sun, 6 Sep 1992 02:26:54 GMT

In article <9209051944.AA18020@lns598.TN.CORNELL.EDU>,         cultural elite <dsr@LNS598.TN.CORNELL.EDU> writes:
> I agree, that would be ridiculous.  Not even Unix (with the possible exception
> of a few broken utilities) behaves that way.

With the possible exception of, for instance, scanf(), the C formatted read
routine. Ever tried to use scanf() to read a one-word reply from the terminal,
and use a default value if the user just hits RETURN? scanf() insists that all
these carriage returns are just white space which should be happily ignored,
and the user wonders what is going on - the more he hits RETURN, the more
nothing happens. Yes, I know, there are ways out, but the least you can say is
that they are unintuitive...

> Mike's question was specifically about word separators, which
> I take to mean the behavior of parse when no explicitly quoted separators are
> given, and the behavior of word() and words() and a few other intrinsics.
> Accepting any whitespace as word separators would have no effect on your
> example, or any other involving explicitly quoted blanks.  Where is the problem
> with that?

The problem is that if you want to change the language definition of all these
functions, you have to come up with a solution that is clearly defined and
works for all systems, not just unix. One such solution, which is what I
understood all the previous postings were proposing, is that positional PARSE
et al are to treat any character for which isspace() returns TRUE as white
space.

Under VM, isspace() is true for X'05' and X'15'. It is logical for isspace() to
be true for these characters, since they are the EBCDIC equivalents of TAB and
CRLF, respectively; as far as I know, all the C compilers for VM agree on this.
I'm not really eager to find out what happens to my tens of thousands of lines
of code the day X'15' is suddenly treated as a blank. It is used as a
line-separator in functions like DIAG, and it is common programming practice to
use it as a line separator when returning more than one line of (non-binary)
data from a function. I suppose a similar situation exists for \n on unix
systems, but I've never used REXX on unix so I wouldn't know.

  Eric
From: kiehl@ibt013.ibt.kfa-juelich.de (Horst Kiehl)
Newsgroups: comp.lang.rexx
Subject: Sorry (Was: Re: Reading inline "code" as input?)
Keywords: inline, sourceline
Date: 9 Sep 92 11:33:25 GMT
Reply-To: kiehl@ibt013.ibt.kfa-juelich.de (Horst Kiehl)
Organization: Forschungszentrum Juelich GmbH (KFA), Germany

Just in case you wonder...

In article <276@zam103.zam.kfa-juelich.de>, I write:

><...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....>

Sorry, I use that to control the line length in my messages
(this simple editor doesn't have a scale), and normally remove it before
selecting Send.

Sorry folks!

All the best,

Horst