HDTenEightyP/NetNews huggingface dataset:
From: anders@lise3.lise.unit.no (Anders Christensen)
Subject: Re: Blanks, REXX, and portability...
Organization: /home/flipper/anders/.organization
Date: 28 Aug 92 00:50:53

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

> Sender:       REXX Programming discussion list <REXXLIST@UGA.BITNET>
> From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
> 
> 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. 

If you bother to state in public that I am wrong, then I think you should 
bother to indicate where I am wrong.

>        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. [...]

At least to me, the Tab/Space problem *is* very real. The original
posting in this tread was a suggestion from Scott Ophof that the ANSI
standard should only have one space character. This, IMHO might have
serious negative effects on ASCII machines. *That* was my concern.

-anders
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Thu, 3 Sep 1992 12:42:52 EST
From:         "Scott (nmi) Mattes" <COTRSSM@SEA04VM.NAVSEA.NAVY.MIL>
Subject:      Re: newbie rexx programmer asks silly questions
Comments: To: Multiple recipients of list REXXLIST <REXXLIST@ucf1vm.cc.ucf.edu>
              3 Sep 1992 14:19:33 GMT from <martinc@GROVER.CS.UNC.EDU>

On Thu, 3 Sep 1992 14:19:33 GMT Charles R. Martin said:

>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"
>
>   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?)

  If you pasted in the exact code you tried then the problem is that
your literal string ends in a back slash and you are parsing on a
forward slash.  When I change 'line =' to 'line = "A*B**D*E*F/"' it
works fine.

--------------------------------------+----------------------------------------
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
Newsgroups: comp.lang.rexx
Date:         Mon, 31 Aug 1992 13:28:12 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: Blanks, REXX, and portability...

On Mon, 31 Aug 1992 14:16:58 GMT Edward T Spire said:
>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.

But Ed, the problem is not one other character, it is a raft (of undefined
size and contents) of other characters.  And implemenation (and even usage
paradigm) specific at that.  Far better each such environment should provide
an "expand" tool, and a place in the language processor for it to fit.  So
that the effect of "expand | rexx" is achieved.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Thu, 3 Sep 1992 09:56:21 EDT
From:         Turgut Kalfaoglu <TURGUT@FRORS12.BITNET>
Subject:      Re: Blanks, REXX, and portability...

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
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Sat, 29 Aug 1992 22:38:03 MSZ
From:         ludger hinners-tobraegel <LHINNER@DGOGWDG1.BITNET>
Subject:      compare a number with a stem

subject: comparing a sorted stem with a given number
platform: cms

hello rexxperts,

I hope my question will be only a little one.

I have a sorted stem. Its elements are numbers (floating point).
Par example 1,000 numbers between 1 and 10.
And I have a single variable, say a=7.
Now I would like to know, how many (percent) of the stem's elements
are bigger than the variable a.

Is there a quicker solution than the code posted below?

Thanks in advance!

Ludger Hinners
Institute of agriculture economics
University of Goettingen
Germany


cnt=0
do i=s.0 to 1 by -1
   if s.i>a then cnt=cnt+1
end i
say cnt
Newsgroups: comp.lang.rexx
From: ets@wrkgrp.COM (Edward T Spire)
Subject: Re: PARSE wishlist/brainstorming
Organization: The Workstation Group
Date: Wed, 2 Sep 92 16:06:05 GMT

ets@wrkgrp.COM (Edward T Spire) writes:
: anders@lise4.lise.unit.no (Anders Christensen) writes:
: : In article <1992Aug20.154822.8057@hou.amoco.com> zjlc12@hou.amoco.com (Jerry Campbell) writes:
: : 
: : > Why not add the STEM keyword to the Parse instruction?  
: : >    Parse Var data STEM  "hello" 1 stem. +3
: :...
: : Btw also files and stems could be used in the same way, instead of the
: : stack: 
: :    ADDRESS 'uni-shell' 'ls -l' TO STEM lines.
: :    do i=1 to lines.0
: :       parse var lines.i perm.i . user.i size.i . . . filename.i .
: :       end
: :...
: : If what you want to do, is to put the output of 'ls' into a stem named
: : "record.", why not the following syntax?
: :    ADDRESS 'uni-shell' 'ls' TO STEM records.
: 
: At the last ANSI discussion the "users" all liked these kinds of
: suggestions, i.e., making formal within the language definition the
: kind of numerically based stem collections that are commonly used
: in many programming applications.  The "implementers" in the group
: were not so sure that we could jump right into that without due
: consideration of the side effects.
: 
: I would not be a good person to discuss the possible side effects
: (I was on the side of the "users" in this...)
: 
: Do we have a volunteer to present the counter-arguements?

We have at least one.  I received the following from an ANSI member
for whom posting to this newsgroup is not convenient...

: You asked on one forum for input on the negative aspects of 
: making stem conventions into language.
:
: 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.  Given where we are, the only thing I can think of
: is some convention like "If STEM.0DIM has a numeric value
: then it is the dimension otherwise STEM.0 is the dimension".
:
: It is not important, but perhaps you might work this concern
: into one of your appends, so see if others think
: zero-indexing is important/solvable.
  
I'll also add that if we get a "do over" construct, that count in .0
is less important (although supporting it anyway may help porting
existing code.)

-Ed
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Thu, 27 Aug 1992 08:44:42 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: PARSE wishlist/brainstorming
              27 Aug 1992 13:46:00 GMT from <SEB1525@MVS.DRAPER.COM>

Sorry, guys.  I really don't see a problem that doesn't have a GOOD
rexx solution NOW.  Not every parsable situation has a one-line parse
solution.  But in 2-5 lines, yes, pretty much.

WHAT IS THE PROBLEM WE ARE TRYING TO SOLVE?
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: comp.lang.rexx
Date:         Thu, 3 Sep 1992 04:52:48 EDT
From:         Scott Ophof <ophof@SERVER.UWINDSOR.CA>
Subject:      Re: Blanks, REXX, and portability...
Comments: To: REXXLIST@uga.cc.uga.edu
              Sep 1, 92 4:18 pm

On Tue, 1 Sep 1992 16:18:42 GMT Edward T Spire <ets@WRKGRP.COM> said:
>SCHMIDT@LSTC2VM.stortek.com (Jon Schmidt) writes:
>: ...
>: I later wrote a little
>: UNIX REXX program (see below) to investigate this anomalous (to me)
>: phenomenon.  I was shocked to discover that this UNIX REXX
>: interpreter considered 41 of the 256 possible 8-bit codes in the
>: range '00'X to 'FF'X to be blanks!  41? Where did this come from?
>I ran your program on an RS/6000 and got 6 white space characters,
>not 41.  Then I ran it on a older Sun and got 48!  On a newer Sun
>I got 7, on an HP I got 10, and on SCO I got 44.
...[program & sub-results deleted]...
>Here are the various outputs with some annotation...
>AIX                            aix 3.2
>total number of white space characters is 6
>SunOS                          SunOS 4.1
>total number of white space characters is 48
>SunOS                          SunOS 4.2
>total number of white space characters is 7
>scotty            SCO 'uname' returns hostname instead of OS name (sigh)
>total number of white space characters is 44
>HP-UX
>total number of white space characters is 10

Running Jon Schmidt's program on an Amiga gave the same results as
my test of it on the PC.  Thanks, Bill Hogsett, for passing on the
result of your test.
Are there any systems which returned such surprising results as
SunOS-4.1 and SCO?  For example OS2/Cyber/VMS/MacIntosh?


Regards.
$$/
From: zjlc12@hou.amoco.com (Jerry Campbell)
Newsgroups: comp.lang.rexx
Subject: Re:      Re: PARSE wishlist/brainstorming
Date: 31 Aug 92 14:03:12 GMT
Reply-To: zjlc12@hou.amoco.com
Organization: Amoco

In article 92082711461997@UGA.CC.UGA.EDU,         Dave Gomberg <GOMBERG@UCSFVM.BITNET> () writes:
>Sorry, guys.  I really don't see a problem that doesn't have a GOOD
>rexx solution NOW.  Not every parsable situation has a one-line parse
>solution.  But in 2-5 lines, yes, pretty much.
>
>WHAT IS THE PROBLEM WE ARE TRYING TO SOLVE?

The same type of problem the inception of the Parse statement solved.  Who wants
to scan a string byte by byte looking for patterns?  I agree that I've probably
pushed the idea beyond its usefulness.  I wasn't trying to solve any particular 
problem, just trying to stimulate discussion.  I believe some of the best thinking
about Rexx and its future is done here.  We don't want to stagnate do we?

---
Jerry Campbell   reply to: zjlc12@hou.amoco.com 
Amoco Corp. ISD  SSS/Graphics
Houston, Tx.     713/556-7036
Newsgroups: comp.lang.rexx
From: eric@sejnet.sunet.se (Eric Thomas)
Subject: Re: Blanks, REXX, and portability...
Reply-To: ERIC@SEARN.SUNET.SE
Organization: SUNET, Stockholm, Sweden
Date: Thu, 3 Sep 1992 00:33:50 GMT

In article <1992Sep2.162052.25264@wrkgrp.COM>, ets@wrkgrp.COM (Edward T Spire) writes:
> 2.  REXX is also used as a general purpose programming language.  Such
> programs are much easier to port.  And...

True. I own one such program, and maybe a thousand that won't work on anything
but CMS. REXX is fine for prototyping or non CPU intensive calculations, but as
soon as you're talking about real math-type programs, REXX is simply out of
question. By the time the interpreter finishes your job, you will have had time
to convert it to FORTRAN (or PASCAL, C, whatever language you know best).

> 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?

> 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.

  Eric
Newsgroups: comp.lang.rexx
From: eric@sejnet.sunet.se (Eric Thomas)
Subject: Re: Stealing ideas from Unix (was Re: Blanks, REXX, and portability...)
Reply-To: ERIC@SEARN.SUNET.SE
Organization: SUNET, Stockholm, Sweden
Date: Tue, 1 Sep 1992 21:04:52 GMT

In article <BtwuwM.CB1@watserv1.uwaterloo.ca>, giguere@csg.uwaterloo.ca (Eric Giguere) writes:
> 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.

I've re-read my posting 3 times and I frankly can't see where it supposedly
says that mine is better than yours. All I see is a statement that it is a
pointless effort to attempt to port a large REXX application from system X to
system Y, because REXX (like all scripting languages) is full of system
commands (like LISTFILE, EXECIO, COPYFILE, ls, grep, mv) which generally work
only on one system. And the reason I pointed it out is that it is not obvious
to many people, especially people with a lot of experience in "traditional"
languages. A 25-30k lines FORTRAN 77 program written for CMS is probably much
easier to port to unix than to rewrite from scratch, this is true of most
standardized languages, but it doesn't work with REXX, no matter how compliant
your interpreters are.

  Eric
Newsgroups: comp.lang.rexx
From: pg@sanitas.stortek.com (Paul Gilmartin)
Subject: Re: Blanks, REXX, and portability...
Organization: Storage Technology Corp.
X-Newsreader: Tin 1.1 PL5
Date: Wed, 2 Sep 1992 21:28:25 GMT

Edward T Spire (ets@wrkgrp.COM) wrote:
 
: 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).   ...

I wouldn't quite say "very nicely".  Here are the problems I encountered
trying to convert some of my XEDIT macros from CMS to uni-XEDIT/uni-REXX:

extract /uniqueid doesn't work

extract /size doesn't work

extract /lscreen doesn't work

extract /update doesn't work

extract /terminal doesn't work

extract /cursor doesn't return cursor.5 ... cursor.8

extract /ring doesn't work

Search for external functions is case-sensitive

command pfile and command pquit not defined

command line is not stacked on entry to PF key macro.  This has been
an undocumented feature of CMS XEDIT.  However, in response to my
Reader's Comment Form ES592, IBM has agreed the feature needs to be
documented.  As soon as the feature appears in IBM doc, I'll report
it as a defect to TWG.
Newsgroups: comp.lang.rexx
From: anders@lise3.lise.unit.no (Anders Christensen)
Subject: Re: Eric's question
Organization: University of Trondheim, Norway
	<ANDERS.92Aug29194248@lise3.lise.unit.no>
	<1992Aug29.233631.1@sejnet.sunet.se>
Date: 30 Aug 92 13:12:27

In article <1992Aug29.233631.1@sejnet.sunet.se> eric@sejnet.sunet.se (Eric Thomas) writes:
> In article <ANDERS.92Aug29194248@lise3.lise.unit.no>, anders@lise3.lise.unit.no (Anders Christensen) writes:
> >>			 Parse var data a b . ' A('c')' d
> > 
> > You use a Space character in the pattern to denote a whitespace.

> [Misinterpretation of above statement deleted]

This was _not_ a suggested solution. It was a statement about your
programming style in that clause.

> 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?

In a parse clause:

  1) If you use a Space in a literal pattern, it should match a Space.

  2) If you use a Tab in a literal pattern, it should match a Tab

  3) If you want to make a character in a literal pattern to match a
     class of characters, then Rexx is not able to do that in one
     parse clause.

If your solution to case 3 is "you should not need to do that", then
let me remind you that you brought the question up in the first place. 

Let me explain it again (yes, I will try to be brief):

  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.

     The former will seek for a particular character, never for a
     class of characters. This is because Rexx does not have a way
     of specifying a pattern containing characters belonging to a
     character class, only single characters.

  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.

  3) As far as I can remember, nobody has suggested that Space and Tab
     should be synonymous in the tails of compound variables. 

-anders
Newsgroups: comp.lang.rexx
From: ets@wrkgrp.COM (Edward T Spire)
Subject: Re: PARSE dispute -- who is wrong?
Organization: The Workstation Group
Date: Fri, 4 Sep 92 15:57:27 GMT

GOMBERG@UCSFVM.BITNET (Dave Gomberg) writes:
: 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

The current production version of uni-REXX performs identically to CMS
with respect to this issue.

-Ed
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: comp.lang.rexx
Date:         Thu, 27 Aug 1992 23:37:20 EDT
From:         Scott Ophof <ophof@SERVER.UWINDSOR.CA>
Subject:      Re: Blanks, REXX, and portability...
Comments: To: REXXLIST@uga.cc.uga.edu
              Aug 27, 92 5:55 pm

On Thu, 27 Aug 1992 17:55:21 GMT Eric Thomas said:
>In article <ANDERS.92Aug27063035@lise3.lise.unit.no>, anders@lise3.lise.unit.no
>(Anders Christensen) writes:
>> When taking from an ASCII to an EBCDIC system (or vice versa), you
>> _must_ translate the contents. The clue it that *you* don't parse on
>>...
>Ok, time for the usual stupid question. Say I have a program that does:
>                  Parse var line ':'tagname'.'value' :'line

>Say I run that program on an ASCII system which recognize the 20-odd types of
>blanks Otto showed in his posting. Where does my 'value' variable end, when the
>interpreter encounters a SPACE followed by colon (ancient, despicable, evil
>EBCDIC-type behaviour, surely that must not be the case), or also when it
>encounters TAB followed by colon (nice, modern ASCII-type behaviour which
>happens to break the program because that is not what the programmer wanted
>and thought the interpreter would do).

>In either case you have a problem. If the blank in the search string only
>stands for SPACE, it is very difficult to indicate that you want any of the 20+
>white space characters to match. You would almost need a new WSPARSE command,
>and WSPOS, and so on. If on the other hand the blank stands for any white space
>character, you have no way in the language to halt on just a SPACE when you
>need to do that. OPTIONS is not a solution, a given program may well need both
>functions very often and switching OPTIONS statements is at best impractical.

I just tried to set up the required subroutine for a number of
scenarios with the above PARSE statement, the two which Eric
mentions among them.  What a can of worms!  :-(
The only decent solution I can come up with that would work ANYWHERE
is to require each pair of "tagname"/"value" to be on a separate
line (or record, whatever) starting past column 1, with the initial
pair of an entry starting AT col 1. So the first colon on a line
triggers "tagname", period.  And the first dot after it will trigger
"value".  Any forms of leading whitespace on non-initial pairs will
then be ignored, EFFECTIVELY SIDE-STEPPING THE PROBLEM...

Of course, the PARSE statement would then be:
   Parse var line ':'tagname'.'value

Please read the next para in cynical or serious mode, or a mixture;
both are applicable.  (*grin*)

That the file now needs to be restructured isn't really important.
Same re it possibly becoming a mega-line file; on a record-based
machine more disk space will be eaten, especially if fixed-length.
With variable-length records, or on a byte-stream architecture, the
difference shouldn't prove disastrous.

BUT this is NO solution to the REAL problem.  HELP!  :-(


Regards.
$$/
Newsgroups: comp.lang.rexx
From: TDTRUE@pucc.Princeton.EDU
Subject: Re: Blanks, REXX, and portability...
Originator: news@nimaster
Organization: Princeton University
Date: Fri, 28 Aug 1992 13:40:19 GMT

I'm lost at this point, partly because we're talking about two
distinct questions.  The one is, "What character or characters can
delimit a word?", the other is, "Should a literal blank represent
more than a single kind of space?"
 
 
In the first, it seems to me that you want to pick out what you
regard as a word; what separates words should make no difference.
The CMS version of REXX could even benefit from an OPTIONS parameter
to modify this. I've been bit once or twice trying to parse CP
output that contained a new line (x'15').  The translate function
is useful in this case, but on other systems letting a word be a word
makes more sense.
 
The other question is illustrated by Eric's question.  It seems to
be that in PARSE and elsewhere a literal string should only match
a single character string; literal blank should match just one
character.  If you need to match on more than a single character,
then 'PARSE' needs to be extended, but not just to handle multiple
meanings for a blank.
 
Tom True
Princeton University
CIT - Advanced Applications
TDTRUE@PUCC.PRINCETON.EDU
(609) 258-6064
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU