HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.lang.rexx
Date:         Sat, 29 Aug 1992 14:14:39 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: compare a number with a stem

Here is some very fast code for searching for how many in a sorted stem
are bigger than a:

    $TOP=s.0+1; $BOT=1  -1;                          /* ABOVE HIGHEST  */
    DO WHILE($TOP>$BOT+1);$MID=($TOP+$BOT)/2;        /* TILL NONE LEFT */
        IF a   >=   s.$MID THEN $BOT=$MID; ELSE $TOP=$MID; END;
    /*  Initially, s.$bot<=a<s.$top */
    SAY (s.0-$top+1)/s.0*100 'percent of the values are greater than' a'.'

This is O(LN(S.0)).   Dave
From: pg@sanitas.stortek.com (Paul Gilmartin)
Newsgroups: comp.lang.rexx
Subject: Re: Capturing System Command Output (was: SH Backquote)
Date: 28 Aug 92 23:41:36 GMT
Organization: Storage Technology Corp.
X-Newsreader: Tin 1.1 PL5

Edward T Spire (ets@wrkgrp.COM) wrote:
   
: The nice thing about doing this kind of stuff exclusively with functions
: is that it's easy to test (external functions) and you don't risk the
: chance of damaging the language when you do it that way.

Gee, That's _exactly_ the enhancement I'd like to see in the 'POPEN'
built-in function of your employer's uni-REXX product.  :-)
 
: You would need to firm up this idea of using a program-specified
: filename as a handle on an interprocess communications port, and think
: about it's impact on the file namespace and accessibility to other
: files, etc.

How about:
    Handle = 'POPEN'(command, type)  /* args as in the C function */

The handle returned might well have a form such as:
    /dev/uni-REXX/process-id

this should have minimal impact on the file namespace, since:

    uni-REXX is a registered trademark of The Workstation Group.

: My impression is that it was no small feat to craft REXX so that it is
: easy to use and powerful at the same time.  I would not want to go
: wading off on some large extensions like this without their being
: carefully thought out and field tested.

Agreed.

-gil
From: anders@lise3.lise.unit.no (Anders Christensen)
Newsgroups: comp.lang.rexx
Subject: Re: do over stem
Date: 26 Aug 92 04:16:44 GMT
	<1992Aug26.025338.1@sejnet.sunet.se>
Organization: /home/flipper/anders/.organization

In article <1992Aug26.025338.1@sejnet.sunet.se> eric@sejnet.sunet.se (Eric Thomas) writes:

> [about the  'do i over stem.'  construct]

I don't think there is really any technical problems with implementing
such a construct, either function-based or as part of 'do'.  Some
problems have already been pointed out, but none so big that is
impossible to do.

My main objection is not technical, but "Does it belong in Rexx?"

Eric Thomas posted some pieces of code, which could have been
simplyfied a lot if a 'do i over stem' existed, and I agree that there
is a need for such a construct. But the question is rather, "Does the
need justify adding the feature to the definition of Rexx?". 

For every new feature in Rexx, the definition of the language
increases, and the language becomes more complicated for new users to
learn. For those who already know Rexx well (includes most of the
readers of this group), the addition of a simple feature might not be
a big deal. But for language itself, the accumulation of many simple
features can make Rexx big, complex and difficult to learn for new
users.

As for the construct itself, I like the 'do foo over bar.' best, since
all the function-based solutions I have seem looks like some sort of
kludge to me. 

What about letting 'var over stem." be an alternative 'repetitor' in
do clauses. Then it would be possible to do something like:

   do <var> over <stem.>  { while <exprw> | until <expru> }

then <var> would be the control variable, which could be given as
arguement to 'leave' and 'iterate', or be put after 'end'. Perhaps the
'for <exprf>' should be allowed in the repetitor too? I'm not so sure,
it is just a random thought. Anyway, the only change in the old syntax
would be to have 'OVER' be a reserved word in the repetitor.

It would work something like: <var> is 'iterated through' the tails
which the stem <stem.> had at the moment when the do-loop was entered.
At each iteration, <var> is set to the name of a new tail.  If <var>
is a compound with stem <stem.> it is not included in the list of
stems to be iterated over, unless it was already set before the
do-loop. The 'until' part is checked at the end of each iteration,
before <var> is incremented.  The 'while' is checked at the start of
each iteration after <var> is assigned or incremented. The order in
which the tails are assigned to <var> is arbitrary. Any setting or
dropping of compounds with stem <stem.> during the loop, has no effect
on the looping.

Is this more or less the functionality you wanted?

> Now it's too late, I am moving away from REXX as fast as I can.

I'm sorry to hear that. 

-anders
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: comp.lang.rexx
Date:         Thu, 3 Sep 1992 04:50:20 EDT
From:         Scott Ophof <ophof@SERVER.UWINDSOR.CA>
Subject:      Re: PARSE wishlist/brainstorming
Comments: To: REXXLIST@uga.cc.uga.edu
              Sep 2, 92 4:06 pm

On Wed, 2 Sep 1992 16:06:05 GMT Edward T Spire said:
>ets@wrkgrp.COM (Edward T Spire) writes:
>: anders@lise4.lise.unit.no (Anders Christensen) writes:
...
>: One of the negatives that bothers me is that the customary
>: convention uses STEM.0 to hold the dimension.  Whoever
>: invented that was probably not a mathematician nor a C
>: programmer.  Element zero of an array is wanted by some
>: people.

I *like* the imho uncomplicated idea of an array starting at 1 with
the number of elements in element 0. I find it a quite UNsurprising
setup.  The concept of "first element is number 0" bothers *me*...
And the few times I've needed to start at 0, I did the following:

  Do I = 0 to element.0
    J = J + 1
    result = do_something_with_element.J
    End I


Regards.
$$/
From: zjlc12@hou.amoco.com (Jerry Campbell)
Newsgroups: comp.lang.rexx
Subject: Re: Stealing ideas from Unix (was Re: Blanks, RE
Date: 3 Sep 92 20:45:08 GMT
Reply-To: zjlc12@hou.amoco.com
Organization: Amoco

I think one could split the "how do we improve Rexx focus" into the following,
two, general areas.  

   1 - New language elements/features that make Rexx more like a "traditional"
       programming language.  More like what new users are used to using, C
       for instance.  In other words, how can I use my old strategies/algorithms/
       paradigms when solving a problem with Rexx.  

       Personally, I think there is little we can do in this area.  Perhaps
       the Uni* aficionados will disagree.  I mean, you'll never get linked
       list algorithms to directly apply to kinds of things you have to do to 
       handle indexed stems.  My attitude here is, you're using a new language,
       relax, and learn some new approaches/techniques.

   2 - Host/application/process/... to Rexx relationships.  This is where Rexx
       offers some unique advantages over other scripting languages.  This is
       where Rexx can really shine. I believe this is where our focus would be
       most beneficially applied.                   
  
---
Jerry Campbell   reply to: zjlc12@hou.amoco.com 
Amoco Corp. ISD  SSS/Graphics
Houston, Tx.     713/556-7036
From: leb@Hypatia.gsfc.nasa.gov (Lee E. Brotzman)
Newsgroups: comp.lang.rexx
Subject: PARSE dispute -- who is wrong?
Date: 4 Sep 92 01:46:32 GMT
Organization: Goddard Space Flight Center

I am in the process of porting REXX code that was working on VM/CMS REXX and
PC-REXX from Mansfield Software to UniREXX from the Workstation Group.  I have
run across a problem that I would like to get the group's input on before I 
bitch to the Workstation Group.

Given a parse instruction like:

	parse var inline numrec lrecl desc'\'inline

and the contents of inline are:

	'1234 567 File 1\4321 765 File 2'

one can expect that the values of the parsed variables will be:

	numrec=1234 lrecl=567 desc='File 1' inline='4321 765 File 2'

But if the contents of inline are:

	'1234 567\4321 765'

Under VM/CMS REXX and PC-REXX the variable contents are:

	numrec=1234 lrecl=567 desc='' inline='4321 765'

Under UniREXX from the Workstation Group the variable contents are:

	numrec=1234 lrecl='567\4321' desc=765 inline=''

Clearly, my intended result is the one returned under VM/CMS REXX and PC-REXX,
I have put in a work-around to deal with the result from UniREXX.  The way I
interpret the results is that the former two REXXes parse on the literal
strings first (i.e. they see the '\' before assigning to variables) whereas
UniREXX parses on the variables first and the literals second.

My Question:  Does the REXX langauge specify parsing on literal strings in the
pattern first or the variables?  Or is this ambiguous?  I apologize for not
going to Cowlishaw for the answer, but I was stupid enough to loan the book to
someone long ago and I have lost track of my copy.  I would appreciate a rapid
answer because we have a software maintenance contract with the Workstation
Group, and if they are in the wrong they should have this brought the their
attention immediately.
--
-- Lee E. Brotzman                    Internet:  leb@hypatia.gsfc.nasa.gov
-- Hughes STX                         DECNET:    NDADSA::BROTZMAN
-- National Space Science Data Center BITNET:    ZMLEB@GIBBS
-- NASA Goddard Space Flight Center
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Wed, 2 Sep 1992 09:23:43 EDT
From:         Turgut Kalfaoglu <TURGUT@FRORS12.BITNET>
Subject:      Re: VM/REXX Manual

The system's manuals are decent - just grab the System Interpreter
Users Guide (I cant remember the exact name). It has examples,
and good description -- a "readable" IBM manual, wow!

There is always the online help: HELP REXX <keyword> will give you
some reference info too.   Regards, -turgut
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Thu, 27 Aug 1992 07:22:02 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: Blanks, REXX, and portability...
              27 Aug 1992 06:30:35 LCL from <anders@LISE3.LISE.UNIT.NO>

Unix REXX interpreters should do whatever they need to do to overcome the
shortcomings of the underlying operating system, such as a confusion on
the part of the original designers as to what a space was.

It is NOT true that this is an ASCII vs EBCDIC discussion, most PC-DOS and
OS/2 applications don't see tab as whitespace, and almost all of the ones
that do do so only optionally.  And there are MANY more PCs that Unix
machines.

Mutliple space characters (tab) are a typing and disk compression convenience.
Partial space characters are a way to format printed output.

Neither belong in the description of the syntax of a programming language.


Dave Gomberg    GOMBERG@UCSFVM  Internet node UCSFVM.UCSF.EDU  (415)731-7793
Seven Gateview Court, San Francisco CA 94116-1941
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Fri, 28 Aug 1992 09:41:50 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: Blanks, REXX, and portability...
              28 Aug 1992 13:40:19 GMT from <TDTRUE@PUCC.PRINCETON.EDU>

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.
From: martinc@grover.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.lang.rexx
Subject: newbie rexx programmer asks silly questions
Date: 3 Sep 92 14:19:33 GMT
Distribution: comp
Organization: UNC Department of Computer Science

Just discovered rexx in the process of writing some OS 2 tools.

Question 1: Can someone recommend a particular rexx implementation for
DOS? Are there any pros and cons to be considered, or is one as good as
another?

Question 2: Given a string like this

A*B*C*D*E*F/

where the fields represented by cap letters can be arbitrary length, 
where * is a field separator, and / is a message terminator, I would
like to parse it including the possibility that there will be null
fields.  That is, of one message were A*B**D*E*F/, I'd like to parse it
into say an "array"

a.1 = 'A'; a.2 = 'B'; a.3 = ''; a.4 = 'd' and so on.

My first cut at that was
	line = "A*B**D*E*F\"
	ix = 1
	do while line <> ''
	   parse value line with fld'*'line'/'
	   a.ix = fld
	   ix = ix + 1
	end

which didn't quite work.  Any suggestions?  (By the way, there's an
obvious recursive reformulation of this: are there advantages of the
iterative vs recursive expression?)

--
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
From: zjlc12@hou.amoco.com (Jerry Campbell)
Subject: Re: REXXCOMP versus EXECUPDT (NOUPDATE NOCOM
Reply-To: zjlc12@hou.amoco.com
Organization: Amoco
Date: Tue, 25 Aug 1992 16:01:36 GMT

In article 141853CJS@psuvm.psu.edu, CJS@psuvm.psu.edu (Christopher Sacksteder) writes:
>In article <1992Aug21.190236.4733@hou.amoco.com>, zjlc12@hou.amoco.com (Jerry
>Campbell) says:
>>
>>Look at the file sizes of the resulting compressed files.  Whichever is
>>smaller in size and more efficiently blocked for i/o will be interpreted
>>more quickly by Rexx.  The compression utilities don't change any code
>>they just make it more efficient for Rexx to read and scan the program
>
>I don't think this is right.  REXXCOMP doesn't just "compress" the
>source code.  It preprocesses it and produces a tokenized format, just
>as the first stage of the interpreter does.  For large files, parsing
>the source takes a significant amount of time, which REXXCOMP eliminates.
>The output is always 1 fixed-length record.  (What is "efficiently
>blocked"?)
>
>If you had REXXCOMP (we call it REXXOPT because it isn't a compiler or
>compressor) I don't know why you would use EXECUPDT, except for export
>purposes.  Modifications need to be made to the interpreter in CMS to
>run REXXCOMP'ed files (the interpreter has to know to skip the parse
>stage).
>
>We use REXXCOMP for many production EXECs, and often prefer it to
>results from the CMS REXX Compiler, which can be very large.

I was speaking from my experience with CMS Rexx.  I've never heard of a
anything available for CMS Rexx that preprocesses the source in the
way you're talking about.  What does the interpreter do with it?  How does
it recognize that this file has been "tokenized"?  The REXXCOMP we have
around here does nothing but strip out comments and extra blanks and then
block the results into as large a records as it can (so that the interpreter
can read the file more efficiently/quickly (more efficiently blocked)).  
Obviously, you guys have something more sophisticated. 

---
Jerry Campbell   reply to: zjlc12@hou.amoco.com 
Amoco Corp. ISD  SSS/Graphics
Houston, Tx.     713/556-7036

Newsgroups: comp.lang.rexx
From: ets@wrkgrp.COM (Edward T Spire)
Subject: Re: Blanks, REXX, and portability...
Organization: The Workstation Group
Date: Fri, 28 Aug 92 17:28:15 GMT

SEB1525@MVS.draper.com (Steve Bacher) writes:
: In article <ANDERS.92Aug26105620@lise3.lise.unit.no>,
: anders@lise3.lise.unit.no (Anders Christensen) writes:
: 
: [comments on parsing the output of the "who" command]
: 
: As long as we're talking Unix, you can do
: 
:   "who | expand"
: 
: as a portable (from one Unix to another, anyhow) workaround.

Parsing of Unix command output will never be portable from one machine
to another.  I tried Ander's 'who' parser on AIX 3.2, and it didn't
work.  Not because of the tab issue (uni-REXX **does** use isspace()
to determine what AIX classifies as whitespace), but because the AIX
'who' command output just plain doesn't look like the one Anders is 
using!  This crops up all the time on the system administration type
commands you want to use to manage disks, users, tasks, etc.

-Ed
Newsgroups: comp.lang.rexx
From: SEB1525@MVS.draper.com (Steve Bacher)
Subject: Re: Blanks, REXX, and portability...
Organization: Draper Laboratory
Date: Tue, 1 Sep 1992 00:29:00 GMT

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

>...        you have no way in the language to halt on just a SPACE when you
>need to do that. ...

There's always

 parse var something foo " " bar " " baz

Of course, this only works for data separated by single spaces.
Multiple spaces are still a problem.

--
Steve Bacher (Batchman)                 Draper Laboratory
Internet: seb@draper.com                Cambridge, MA, USA
Newsgroups: comp.lang.rexx
From: ins141f@aurora.cc.monash.edu.au (Adam Bradley)
Subject: Ah Mr Rexx ....
Organization: Monash University
X-Newsreader: Tin 1.1 PL5
Date: Fri, 4 Sep 1992 03:15:36 GMT


"Ah Mr Rexx.... we haven't met....."


Well I suppose this is a round a bout way of saying "What is Rexx?"
All I understand it to be is some sort of a (now I guessing..) language
that operates on scripts ?

I am an Amiga owner and constantly see references to Rexx and ARexx (hopefully
a fully compatible version of this popular (?) thingy !

Any help in pointing me in the right direction would be most appreciated !

--
Adam Bradley - 2nd Year Comp Sci            |       ///
 Monash University - Clayton Campus         |      /// Amiga makes it 
  Melbourne Victoria, 3192.                 | \\\ ///    possible ! 
   email - ins141f@aurora.cc.monash.edu.au  |  \XX// #include "std_disc.h"
    "The time will come, one day you'll see, that we can all be friends" Queen89

      "The great thing with standards is that there are so many of them..."
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Thu, 27 Aug 1992 13:11:46 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: Blanks, REXX, and portability...

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, or similar to, a blank.  In those
      operating systems, implementers are encouraged to treat as a blank
      character any of the set of characters which the vast majority of
      users would expect to be treated as a blank in that operating system.
      If there is no consensus among users as to which characters are
      equivalent to blanks, then only the blank character should be so
      implemented."
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Thu, 27 Aug 1992 22:32:04 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: Blanks, REXX, and portability...
              28 Aug 1992 02:13:58 LCL from <anders@LISE3.LISE.UNIT.NO>

On Fri, 28 Aug 1992 02:13:58 LCL Anders Christensen said:
>In article <REXXLIST%92082716163624@UGA.CC.UGA.EDU> Dave Gomberg
><GOMBERG@UCSFVM.BITNET> writes:
>>       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.

A standard mainly tells implementers what to implement, and to a lesser
extent, users what kind of code to write.   If users don't know certain
funny characters are spaces, the implementers in that environment should
not implement them that way.  Seems perfectly straightforward to me.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Thu, 3 Sep 1992 22:53:45 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: PARSE dispute -- who is wrong?
              4 Sep 1992 01:46:32 GMT from <leb@HYPATIA.GSFC.NASA.GOV>

This is a BUG!  Mike long ago clarified that variable lists have no
effect on what the triggers match.  The triggers break up the input
string, then the variable lists are assigned.  Get the other implementation
fixed!  Dave
Newsgroups: comp.lang.rexx
From: zblp02@hou.amoco.com (Barry Puryear (SSS/VM))
Subject: Re:      Blanks, REXX, and portability...
Organization: Amoco
Date: Wed, 26 Aug 1992 14:44:29 GMT

The question of "what is a blank" is deeper than the definition of REXX.
Several years ago, I had the duty to port some Fortran source from a UNIX
system to CMS.  As it happened, the Fortran source was loaded with tab
characters.  The method we used to transfer those files did not convert
the tabs to spaces, but to x'05', as I recall.  Of course, those source
files would not compile on the first try.  I had to convert the tabs to
the correct number of blanks via XEDIT and compile again.

I think that the best way to resolve the "what does REXX call a blank"
question is for CMS (and other environments that use EBCDIC) to start 
treating tab characters more reasonably, rather than updating language
definitions and changing individual language processors.
Newsgroups: comp.lang.rexx
From: eric@sejnet.sunet.se (Eric Thomas)
Subject: Re:      Re: Blanks vs white space...
Reply-To: ERIC@SEARN.SUNET.SE
Organization: SUNET, Stockholm, Sweden
Date: Sat, 29 Aug 1992 18:30:15 GMT

In article <REXXLIST%92082911224924@UGA.CC.UGA.EDU>,         Dave Gomberg <GOMBERG@UCSFVM.BITNET> writes:
> Well, Eric, I have a little problem with your latest.  Suppose I write:
> 
>     DO I=1^TO 10
> 
> where ^ is one of the weird, emm/2*PI to the blank spaces.  Is the
> parser supposed to recognize that too?

No idea, I haven't read the standard in question. I guess the one advantage of
these 32-bit-alphabet standards is that national ambiguities are removed -
there are so many codes that all needs can be addressed with one alphabet. So
whatever emm/2PI means, it will be the same in all countries and for all
operating systems, and I assume the standard would make it clear whether it is
an ornamental blank with no syntactical meaning or an actual separator.

Anyway if this new standard is as successful as the previous ones, all we will
have to concern us with is tab, CR, LF, VT and FF :-)

  Eric
Newsgroups: comp.lang.rexx
Newsgroups: comp.lang.rexx
Date:         Thu, 27 Aug 1992 08:39:48 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: Blanks, REXX, and portability...
              27 Aug 1992 06:30:35 LCL from <anders@LISE3.LISE.UNIT.NO>

Anders, I really think you want to consider a bit more before you write.
Your last posting was so full of things which are wrong, and other things
with which I disagreed that it was too much work for me to bother to
reply.  I think if you tended to focus your thoughts a bit more on the
real issues, and less on U**x, you might attract a wider audience.  But
then U**x folks like C, so maybe I am wrong.   Dave
Newsgroups: comp.lang.rexx