HDTenEightyP/NetNews huggingface dataset:
From: mwm@contessa.palo-alto.ca.us (Mike Meyer)
Subject: Re: Blanks, REXX, and portability...
Newsgroups: comp.lang.rexx
Distribution: world
X-NewsSoftware: Amiga Yarn 3.4, 1992/08/12 15:49:52
Keywords: 
Summary: 
Date: 29 Aug 92 23:07:05 PST
Organization: Missionaria Phonibalonica

A question for all of you using EBCDIC who don't think that arbitrary
whitespace should be allowed to seperate words: Why do you care?

The only argument I've seen is that allowing input data with tabs
makes programs less portable. This is false. It makes programs more
portable; it makes _data_ less portable.

If you think that tabs are evil, you may be right. It doesn't matter.
TAB is an ASCII character that it is perceived of as a long blank, and
people use it as such on a regular basis. Wishing and language
definitions won't make the problem go away; they'll just fail to
generate horses and create headaches for people who want to use the
language.

A similar problem shows up in the ANSI C standard. It has this idiotic
restriction that external identifiers must be unique in the first six
characters, case insensitive. I don't know of _anybody_ who liked
this, but there was a very popular system which had a standard linker
with that antiquated restriction. Removing this brain-dead restriction
meant that you couldn't write an ANSI C compiler for that system,
which was considered a bad thing - so the restriction stayed in.

While requiring that only space can be treated as a blank character
won't prevent people from implemeting "standard Rexx" on any
particular machine, it will make Rexx hard to use, and cause people to
look to other tools.

In <REXXLIST%92082621432914@DEARN>, Otto Stolz <RZOTTO@DKNKURZ1.BITNET> wrote:
> 5. that standard-conforming implementations be required to implement
>    the recognition of white space in a way conforming
>    - to all possible sources for REXX source programs,
>    - to all possible sources for input to REXX programs
>    (cf. note 1);

I like that - that means you have to consider every computer system in
the world as a possible source, including all possible character set
mappings in getting the data from there to here. Not to mention all
tapes/decks/etc. that still exists, even if there are no functioning
computers of the type that created them.

> In a nutshell: REXX language features should be as permissive as
>                possible when accepting white space, and as predictable
>                as possible when generating it.

"Accept permissively and generate strictly" is a good general
guideline whenever portability or interoperability becomes a
consideration.

	<mike
From: imc@comlab.ox.ac.uk (Ian Collier)
Newsgroups: comp.lang.rexx
Subject: Re: NOVALUE (was: Blanks, REXX, and portability...)
Date: 14 Sep 92 15:02:18 GMT
Organization: Oxford University Computing Laboratory, UK
X-Local-Date: Monday, 14th September 1992 at 4:02pm BST
            <19920910194427SEB1525@MVS.draper.com> <5456@unixhub.SLAC.Stanford.EDU>
	    <1686052F.GILMART@LSTC2VM.stortek.com>
Originator: imc@msc8.comlab

In article <16860347.GILMART@LSTC2VM.stortek.com>, GILMART@LSTC2VM.stortek.com (Paul Gilmartin) wrote:

>Ah, but they're making it hard for us!  Compiled Rexx and uni-REXX (perhaps
>others) report SIGNAL ON NOVALUE as a syntax error _prior_to_execution_
>if the NOVALUE: procedure doesn't exist.

REXX/imc doesn't. :-)

And in article <1686052F.GILMART@LSTC2VM.stortek.com>, he quoth:

>But it would be a real pain if this were reported as an error unless there
>were some way to use explicit constants -- better by far, general expressions
>-- as compound variable indices.  Namely:
 
>   say a.'X'   /* so I don't have to assign 'X' to dummy */
>               /* and even:  */
>   say a.(substr('UVWXYZ',4,1))   /* Why not, haven't you wanted it? */
 
>Is anyone proposing this extremely desirable extension?
 
You can already do this on REXX/imc.  Of course, I'm not asking anyone
actually to use that feature! :-)

A new release of REXX/imc containing some bugfixes will reach
rexx.uwaterloo.ca in a few days. Watch this space...

Ian Collier
Ian.Collier@prg.ox.ac.uk | imc@ecs.ox.ac.uk
From: sip1@ellis.uchicago.edu (Timothy F. Sipples)
Newsgroups: comp.lang.rexx
Subject: Reading inline "code" as input?
Date: 8 Sep 92 16:36:42 GMT
Reply-To: sip1@midway.uchicago.edu
Organization: Dept. of Econ., Univ. of Chicago

Is there any way a REXX program can take data input from itself
(without resorting to QUEUE or PUSH)?

More specifically, say I have a program as follows:

/* Sample Program */
SIGNAL process
Ant Dog Cat Mouse
Donkey Mule Pig Horse
:process
eof = 0
do until eof
/* Input that data here and process. */
end
EXIT

I know I can detect how many lines are in the program -- there's a
function to do that -- but can I actually read the lines in?

Is it kosher to STREAM(...OPEN) the REXX program itself to read in
inline data, i.e. can a REXX program STREAM(...OPEN) itself?  What is
the best way to detect the full pathname to the REXX program itself,
while it is running, for that purpose?

The reason I am asking is that I am working on enhancements to
REXXShip, and a nice one would be to incorporate XXEncode
compatibility, which would mean having an unmodified stretch of bytes
in the middle of the code for purposes of encoding a binary file.  The
REXX "wrapper" would read that stretch of bytes and decode the file.

-- 
Timothy F. Sipples      | The OS/2 FREQ. ASKED QUESTIONS LIST is avail. from
sip1@ellis.uchicago.edu | 128.123.35.151, anonymous ftp, in /pub/os2/all/faq.
Dept. of Econ., Univ.   | Or from LISTSERV@BLEKUL11.BITNET (send "HELP").
of Chicago, 60637       | Family Values Means a Job
Newsgroups: comp.lang.rexx
Date:         Fri, 11 Sep 1992 07:00:56 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: NOVALUE (was: Blanks, REXX, and portability...)
              11 Sep 1992 01:17:32 GMT from <bobcook@UNIXHUB.SLAC.STANFORD.EDU>

On Fri, 11 Sep 1992 01:17:32 GMT Bob Cook said:
>At least, it doesn't on VM/CMS.  In the following piece of
>code, the "say" statement produces "Hi" on the console, even though it uses
>the variable named X, which has never been initialized.
>
>  signal on novalue
>  dummy = 'X'
>  a.dummy = 'Hi'
>  say a.x
>  exit
>Novalue: Say 'Oops'

There is no occurance of a variable named x in this program fragment.  There
is a constant whose value is the single letter X in upper case, and there is
a variable reference to a.x.  This is no more a reference to x then a.2 is
a reference to the number 2.  To see this, notice that the number 2 (or any
number) is to be taken in some base, while the notion of base is completely
irrelevant in the reference to a.2.  There, 2 is just a one character string.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Wed, 9 Sep 1992 09:16:08 EDT
From:         Turgut Kalfaoglu <TURGUT@FRORS12.BITNET>
Subject:      CLIP EXEC 1.2 stored
Comments: To: VM-UTIL@TREARN.BITNET

I just stored a new version of this tiny utility that shrinks notebooks
by removing the unnecessary headers - if you are in the habit of
printing notebooks, you may save a few trees with it (ok, maybe a few
branches :)

It's available from the TREARN FILELIST of Listserv@trearn. Just send a
GET CLIP EXEC command to it.. Enjoy..  Regards, -turgut
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Mon, 7 Sep 1992 14:45:24 EDT
From:         Turgut Kalfaoglu <TURGUT@FRORS12.BITNET>
Subject:      Re: newbie rexx programmer asks silly questions

I'd recomment OS/2's Rexx over others. No limitations on memory or anything!
It accepts direct OS function calls (DosSetPrty, DosSleep...anything...),
has a fairly fast interpreter, and  it feels just like VM's, with
'trace i' and even its error messages.  -turgut
Newsgroups: comp.lang.rexx
From: ets@wrkgrp.COM (Edward T Spire)
Subject: Re: Expressions in compound variables (was Re: NOVALUE)
Organization: The Workstation Group
Date: Tue, 15 Sep 92 21:31:17 GMT

LRL@psuvm.psu.edu (Linda Littleton) writes:
: In article <REXXLIST%92091210585300@UGA.CC.UGA.EDU>, Dave Gomberg
: <GOMBERG@UCSFVM.BITNET> says:
: 
: >On Sat, 12 Sep 1992 06:22:02 GMT Paul Gilmartin said:
: >>   say a.(substr('UVWXYZ',4,1))   /* Why not, haven't you wanted it? */
: >>
: >>Is anyone proposing this extremely desirable extension?
: 
: >When the SHARE REXX committee debated this "extension" at great length,
: >it turned out to be next to impossible to define.
: 
: Dave, Maybe you're remembering a different discussion than I do.  SHARE
: did put in a requirement for this back in 1989.  I think it is a useful
: extension and would reduce the "astonishment factor" new users have when
: they find that things like this (especially simpler things like x.(y+1))
: don't work.

Ah, there's the syntax that was discussed.  Yes, it too does have a bit
of breakage, i.e.,

x.=9
x.2=8
say x.(1+1)

would say "8" with this extension, while it says "92" now.  This does
look like less breakage than stem.'X', however (you'd need stem.('X')
in that case... even less likely to be in an existing program)

-Ed
Newsgroups: comp.lang.rexx
From: anders@lise1.lise.unit.no (Anders Christensen)
Subject: Re: regina bug with very long strings
Organization: University of Trondheim, Norway
Date: 9 Sep 92 15:58:53

In article <19920908170207SEB1525@MVS.draper.com> SEB1525@MVS.draper.com (Steve Bacher) writes:

> There appears to be a bug in Regina 0.03d with long strings.
> [...]
> I get a segmentation fault.  Where exactly the fault occurs depends on
> if I run the SunOS version or the AIX version.

The length of strings in Regina 0.03d is bounded by the size of an
(signed) short in C, which is at least 32k (on Crays it's 16384 Tera).
At least it ought to be unsigned short, which enables lengths of at
least 64k. If you change two lines in string.h (change the only two
references of 'short' to 'int') it will work for strings up to 2G.

> Shouldn't Regina recover more gracefully from attempts to create a
> string longer than the maximum value it can handle? 

Yes, it should.
 
>                                                     Is this maximum
> value documented, anyhow?  

I have been searching for the implementation minimum length of values in
variables, but I didn't find it (I seem to remember having read 50000
somewhere, but I don't know where).

TRL 2nd ed states that variable values can have any length (5th
section), but 2nd section states that the limit of length of variable
values should be "much larger" than 50 characters. This is rather
unspecified (and even a contradiction IMHO), does anyone else know
more about this?

>                           It would be less painful if the length of a
> string were held as an int rather than a short (see src/strings.h).

Yes. Using ints instead of shorts eats on an average 4 bytes more pr
string. If you can live with that, apply the changes I outlined above.
It still doesn't detect too long strings, but if you should happen to
need strings bigger than 2 GB, then I think you are going to crash
into practical limits for virtual memory long before that.

Using unsigned int will set the limit to 4GB, but the difference is
hardly of any practical significance. 

There is another problem, in some cases it doesn't sense allocations
of more memory than is available. I have fixed that, and it will be
available in the next version of Regina.

-anders
Newsgroups: comp.lang.rexx
From: richg@hatch.socal.com (Rich Greenberg)
Subject: Re: Curious Question
Organization: Hatch Usenet and E-mail.  Playa del Rey, CA
Date: Fri, 11 Sep 1992 19:28:26 GMT

In article <Leon_Davidoff.04fe@panam.wimsey.bc.ca> Leon_Davidoff@panam.wimsey.bc.ca (Leon Davidoff) writes:
>I whipped up the following code to test something someone was talking 
>about in a message.  During my testing I noticed something strange.
 
 [example code deleted)

>What I would like to know is why b in Test1 is assigned the value ' y'
>while in Test2 the value is 'y'.  I think I ran across this problem 
>before and I found putting a variable Junk (which I never used) on the 
>end of the parse statement made it behave the way I thought it should.
>Any ideas?

This is the documented behavior of the parse statement.  You could get the
same result if you used a period instead of "c" in the parse.
Rexx takes all the stray leading & trailing blanks associated with
the last entry in the parse list and stuffs them there along with
the actual (if any) data.  I have seen the exact same thing in CMS
Rexx.  One of my standard techniques where I an expecting no more
than a given number of values (3 in this example) is:
 
    parse upper arg v1 v2 v3 rest
    if rest /= ''
       then say 'Excess argument(s) "'rest'" ignored.'

-- 
                
Rich Greenberg - N6LRT - 310-649-0238 - richg@hatch.socal.com
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Tue, 15 Sep 1992 10:18:17 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: Expressions in compound variables (was Re: NOVALUE)

Sorry for the confusion, Linda, I meant the CMS REXX committee, not the
Languages REXX Project.  We were not able to find a proper way to express
what we wanted (adequate notation), so we dropped it.  But with the
expanded function of VALUE, I kind of doubt now that it is still important?
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Acknowledge-To: <RZOTTO@DKNKURZ1>
Newsgroups: comp.lang.rexx
Date:         Wed, 9 Sep 1992 15:49:30 MEZ
From:         Otto Stolz <RZOTTO@DKNKURZ1.BITNET>
Subject:      Re: Reading inline "code" as input?
              9 Sep 92 11:27:24 GMT from <kiehl@IBT013.IBT.KFA-JUELICH.DE>

On Wed, 9 Sep 92 11:27:24 GMT Horst Kiehl said:
> If the XXEncoded stuff can include REXX comment delimiters
> ('/*' and '*/'), single or double quotes, you probably have to use a
> different method to include it in the REXX program.

No problem here: XXENCODEd stuff consists entirely of letters "a" to "z",
"A" to "Z", the digits "0" to "9", and the "+" and "-" signs. So, you
can savely put it in a REXX comment.

> Apparently the OS/2
> REXX interpreter scans the whole program before interpreting it,
> detecting any unmatched "/*" or quote. (I don't know if that is
> demanded by the language definition.)

This is required to resolve function names (unless the name is enclosed
in quotes): when the interpreter encounters a statement such as
    say sourceline()
or
    call sourceline, 5
then it has to scan the whole source for a statement beginning with
    sourceline:
before it is allowed to invoce the built-in sourceline function.
Of course, it has to skip comments and strings while scanning for a
statement. Hence, every decent REXX interpreter will alert you from
unmatched comment delimiters, or unmatched string quotes, when you
invoke a function the 1st time in your program.

> (Aside, an unmatched "*/", outside comments, is allowed.)
This is a sloppy implementation. Your interpreter should warn you of
unmatched closing delimiters, as well.

Best wishes,
                    Otto Stolz <RZOTTO@DKNKURZ1.Bitnet>
                               <RZOTTO@nyx.uni-konstanz.de>
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Tue, 15 Sep 1992 00:59:16 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: Relaxing of argument-passing restriction?
              15 Sep 1992 02:56:47 EDT from <ophof@SERVER.UWINDSOR.CA>

On Tue, 15 Sep 1992 02:56:47 EDT Scott Ophof said:
>On Mon, 14 Sep 1992 23:01 PDT Dave Gomberg said:
>>On Tue, 15 Sep 1992 01:25:21 EDT Scott Ophof said:
>>>This restriction has always been a problem in building really good
>>>stuff in REXX.

If I absolutely HAD to pass four strings (A,B,C,D) to an external
routine, I would code:

 'EXTERNALROUTINENAME' RIGHT(LENGTH(A),9)||A||RIGHT(LENGTH(B),9)||B||,
                       RIGHT(LENGTH(C),9)||C||RIGHT(LENGTH(D),9)||D

I assume you can all see how to decode this at the other end.   Dave
From: bobcook@unixhub.SLAC.Stanford.EDU (Bob Cook)
Newsgroups: comp.lang.rexx
Subject: Re: NOVALUE (was: Blanks, REXX, and portability...)
Date: 11 Sep 92 01:17:32 GMT
Reply-To: bobcook@unixhub.SLAC.Stanford.EDU (Bob Cook)

Steve Bacher writes
[Stuff deleted]
>If you use SIGNAL ON NOVALUE, you won't have to put up with this.
>IMHO, REXX programmers should *always* use SIGNAL ON NOVALUE unless
>there is a very good reason (obscure hacks included) not to do so.
[More stuff deleted]

(Somewhat) unfortunately, SIGNAL ON NOVALUE doesn't catch all of the uses of an  
undefined variable.  At least, it doesn't on VM/CMS.  In the following piece of  
code, the "say" statement produces "Hi" on the console, even though it uses the  
variable named X, which has never been initialized.

  signal on novalue
  dummy = 'X' 
  a.dummy = 'Hi'
  say a.x
  exit
Novalue: Say 'Oops'

--
Bob Cook                              bobcook@slac.stanford.edu
Stanford Linear Accelerator Center    NeXT mail okay
From: QQ11@LIVERPOOL.AC.UK (Alan Thew)
Newsgroups: comp.lang.rexx
Subject: portability on Un*x (was Re: Eric's question
Date: 4 Sep 92 18:41:28 GMT
 <1992Aug29.163731.1@sejnet.sunet.se> <1992Aug29.170623.1@sejnet.sunet.se>
Organization: University of Liverpool

In article <1992Aug29.170623.1@sejnet.sunet.se>, eric@sejnet.sunet.se (Eric
Thomas) says:
>
....
>>    * You want to be able to use the program on several platforms,
>
>No, and in my opinion this portability concern is what keeps you guys off
>track
>all the time. Portability between different systems is totally irrelevant, the
>only thing that matters is portability between different REXX interpreters on
>the same type of system. That is, if I write a neat REXX utility for bsd 4.3,
>it would be nice if it worked on all bsd 4.3 systems, regardless of the REXX
>interpreter they are using. I know very well that it won't work on other
>systems regardless of how clever the command trapping syntax comp.lang.rexx
>designed is, because 'ls' won't quite do what my program expects on CMS, VMS,
And given Un*x and different versions of 'ls' (BSD vs SYS 5) the *same*
interpreter on the *same* architecture can bomb just because both versions
are available and it's got the 'wrong' one. :-)

Eric's point is important and seems to have been ignored by others. Yes it's
nice being able to port between CMS and a brand of Un*x but using the same
interpreter on BSD and SYS 5 is also a portability issue.
>MVS, MS-DOS, you name it. I also know that my knowledge of REXX on CMS won't
>help me write anything but simple scripts on unix, because anything beyond the
>format of expressions and if/then/else &co will be different - I'll have to
>forget about DIAG and learn about LINEIN and the like.
>
....
>
>> Regexps are very powerful, and definitively more powerful than the
>> pattern matching of parse. Including regexps into parse' pattern
>> matching would indeed add to its power.
>
>Oh, please. Why not include awk as well, and all the other unix stuff? People
>who want to program in perl can (and do) use perl. REXX is designed to be easy
>to learn by people without a DP background. Regular expressions are not
>precisely intuitive for this type of people :-)
>
In defence of awk, its syntax is not quite as simple as REXX but it's easier
to move to than PERL :-). Regular expressions are not mandatory :-)

Alan Thew
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Tue, 8 Sep 1992 09:53:56 EST
From:         "Scott (nmi) Mattes" <COTRSSM@SEA04VM.NAVSEA.NAVY.MIL>
Subject:      Fairwell to network, for now

  Today I will be losing my Internet access, for an unknown length of
time.  This is due to the downsizing of our IBM mainframe and
consolidation of certain applications to another IBM data center.

  So, for the time being at least, I bid farewell to the net. I wish
to thank all those who have helped to enlighten me on various things
(work, religion, eating, etc) while I have had access.

  If anyone needs to contact me, my 'home' and voice addresses will still
work.

  Needless to say (I will anyway) the ANONYMOUS FTP account
(144.11.100.1) is going away also.

--------------------------------------+----------------------------------------
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
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: comp.lang.rexx
Date:         Tue, 15 Sep 1992 02:56:47 EDT
From:         Scott Ophof <ophof@SERVER.UWINDSOR.CA>
Subject:      Re: Relaxing of argument-passing restriction?
Comments: To: REXXLIST@uga.cc.uga.edu
              Sep 14, 92 11:01 pm

On Mon, 14 Sep 1992 23:01 PDT Dave Gomberg said:
>On Tue, 15 Sep 1992 01:25:21 EDT Scott Ophof said:
>>This restriction has always been a problem in building really good
>>stuff in REXX.
>>...
>Certainly this restriction didn't hurt CMS folks, who love REXX even
>the way it is.  I guess I don't understand the problem?   Dave

OK, I'll 'bite'.  ;-))

Say you have a nice program with a wonderful internal subroutine.
And you want to use that wonderful gem for another program.
Maybe even make it available to your user community, or share it
between more programs.

But more than one arg-string is passed back and/or forth.  And no
way will it work as neatly (if at all) if you compress the stuff
into one single arg-string.  Just think of how much effort & time
is being wasted.  Maybe you have to mess up the syntax into
something even Hitchcock's birds don't want...

Look at the syntax of CMSPipes stages, and just imagine how much
easier easier they would be to work with if multiple arg-strings
were allowed.

One then either sighs and builds the li'l gem into *each* and
*every* one of the programs where one wants to use it (talk about
wasteage!), or one is (popularly said) up the creek without that
paddle...  :-((

Methinks my byte was large enough.  :-)  Next?


Regards.
$$/
Newsgroups: comp.lang.rexx
Date:         Fri, 11 Sep 1992 07:05:04 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: REXX on UNIX?

Personal REXX works swell in DOS 5.0.  There is a low cost upgrade to
REXX 3.0 available to licensed users.  You might want to consider ordering
it.  The author, Charles Daney, is on CServe (75300.2450@compuserve.com).
You might want to ask him about your problem, especially if you are licensed
for Personal REXX.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Subject: (no subject given)
X-Delivery-Notice:  SMTP MAIL FROM does not correspond to sender.
Newsgroups: comp.lang.rexx
Date:         Mon, 14 Sep 1992 14:59:51 DST
From:         VALOREV@DKIBMVM1.VNET.IBM.COM
Comments: To: rexxlist@ucf1vm.cc.ucf.edu

And while you are at it, why don't you also leave out the 'BY 1' since
thise is the default ?

With Kind Regards
Victor Valore
Internet: VALOREV.DKIBMVM1xVNET.IBM.COM
Bitnet:   VALOREV at VNET
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Sun, 6 Sep 1992 17:53:16 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: Blanks, REXX, and portability...
              6 Sep 1992 22:34:14 GMT from <martinc@GROVER.CS.UNC.EDU>

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
Newsgroups: comp.lang.rexx