Tuning Question

[Steve Thompson]

Are there some rules of thumb, or some generic principles for tuning REXX
to cut elapsed time (wall, not necessarily CPU)?

I know that an I/O that one does not have to do cuts down on time. So I
have all my stuff in stems that I can put there. I have logic to detect
when I can do an early out of a DO and so issue LEAVE/ITERATE as soon as I
can.

Anything about REXX that is known to be less efficient that I can attack?

Regards,
Steve Thompson

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

[John P Kalinich]

You can compress a Rexx exec with /*% NOcomment Rexx */ in the first line.
Or compile it if you have the Rexx compiler available.

Regards,
John K

[Bodoh John Robert [Contractor]]

I found that repeatedly calling the same external REXX routine slowed me down a lot.

I also found that some functions, although easy to code take a long time to execute. For example, I used to have code that would add a word to a string if the word was not already there:

IF WORDPOS(NEEDLE,HAYSTACK) = 0 THEN
HAYSTACK = HAYSTACK NEEDLE;

When the above code was executed many times, it slowed the program down a lot. Instead of the above code, I used stems which improved the performance:

IF SYMBOL("HAYSTACK.NEEDLE") <> "VAR" then
HAYSTACK.NEEDLE = "";


John

[Adrian Stern]

If we're talking interpreted rexx than make all external routines internal -
a great saving.
Use literals as much as possible - don't keep resolving variables - do it
once only.

But compiling to a load module will solve those problems for you if I
remember correctly.

And talking of elapsed time then I/O is a big issue since you wait for I/O
channel calls - so optimal block sizes on all files helps a lot.

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Steve Thompson

[Paul Gilmartin]

On Feb 26, 2013, at 11:05, John P Kalinich wrote:

> You can compress a Rexx exec with /*% NOcomment Rexx */ in the first line.
> Or compile it if you have the Rexx compiler available.
>

Does this work in OMVS?

-- gil

[Steve Thompson]

From: Steve Thompson/Dallas/IBM@IBMUS
Date: 02/26/2013 11:41 AM

Are there some rules of thumb, or some generic principles for tuning REXX
to cut elapsed time (wall, not necessarily CPU)?

<SNIPPAGE>

Wow, I had never seen anything said about this: /*% NOcomment Rexx */ .
I put that in immediately for the next test I run to see how it behaves.

And the comment about WORDPOS, yes, that is exactly the kind of thing I
was concerned about. Using a trick like that which allows rapid coding to
get something written, but in the long run causes things to be quite slow
during execution (and I am actually making use of that technique, but in
the batch oriented REXX code).

And I have everything I can as internal routines for the REXX that is
executed under ISPF. I really want to keep a TSO user from getting
penalized with 3rd & 4th period.

The batch executions are not that critical to me, but the TSO execution is
my biggest concern. (Trust me, what I am doing without tuning will be at
least two orders of magnitude faster than the Java it replaces because I
will be running at "z/OS speed", and not at an external system's speed
with having to poll, wait for something, then poll, etc.).

Once we get finished with acceptance testing, I will see if I can get this
code compiled. I know that speeds things up, I just don't know by how
much.

[Hobart Spitz]

I would be cautious about making all modules internal, just as I would be
cautious about making all modules external:

- If they need to be internal because you need access to a variable pool
or for performance, do so. If a module is only called once, or only under
certain conditions, making it internal is unnecessary with little benefit.
- If you don't need to make a module external , don't. It's a
maintenance headache.

I've seen people go to both extremes. They were sorry!

Compiling is generally a good idea from a performance point of view. Under
CMS and TSO, you get the added benefit of seeing all your errors at once,
identifying uninitialized variables, etc., etc. But it's an extra step.
For real fun under TSO, compile using an ISPF edit macro, and merge any
error messages into the edit session at =NOTE= lines just before the line
in error. It's a real productivity boost.

If you want performance benefits while keeping the module external, you
have these options:

- Under CMS EXECLOAD. Compile first, if you can.
- Under TSO, write your own EXECLOAD: If not already allocated,
allocate a dd (e.g. EXECLOAD) to VIO PDS /* else continue */. Compile the
EXEC and place the CEXEC into this DD. See LMCOPY. It will scream and, if
done right, will confuse your capacity planners. :-)
- Under Windows, use SysREXXMacroLoad() /*I think?*/
- Under Linux, I'm not sure.

I would say the advice about literals produces minimal improvement at the
expense of clarity and maintainability.

Note that for PDSEs, the coded BLKSIZE is only the buffer size. The
physical block is always 4096. Strange, but true. There is no need to go
for track optimal blocking. The highest allowed multiple of 4096 will give
you the best I/O performance, possibly at the expense of a larger working
set.

--
OREXXMan

[Adrian Stern]

Actually a literal instead of a function call makes noticeable savings

[Andreas Fischer]

well i'm not an expert at all in this case, but did some testing some time
ago (with uncompiled rexx):

* as it has been mentioned, i use /*% nocomment rexx */ in the first line

* i try to avoid ELSE conditions; it seemed to be much more efficient to
set a variable and then only have one IF statement for a possibly change
of the default variable value instead of an IF... ELSE construction

* also, many builtin functions seems to be slightly faster then a single
IF statement, example giving: A = MAX(A, 10) did faster than IF A < 10
THEN A = 10


BUT: typically, those kinds of things might speed up an EXEC and you won't
even notice because the EXEC finishes right away. those EXECS i run that
take significant amount of time to finish usually slow down to completely
other reasons, example giving issuing RACF commands in the TSO environment
or some ISPF commands in edit macros. actually, i use external functions
extensively, because that has never has been the bottleneck (and i don't
have to write the same or similar code again and again).

one other thing is processing a hugh amount of data. then i recommend to
use batch jobs with SORT instead of REXX EXECS. this is a way to decrease
processing time dramatically.


regards,
andi



TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> schrieb am 26.02.2013
18:29:22:

[Paul Gilmartin]

On Feb 27, 2013, at 01:46, Adrian Stern wrote:
>
> Note that for PDSEs, the coded BLKSIZE is only the buffer size. The
> physical block is always 4096. Strange, but true. There is no need to go
> for track optimal blocking. The highest allowed multiple of 4096 will give
> you the best I/O performance, possibly at the expense of a larger working
> set.
>

For RECFM=FB, that needs to be the highest allowed multiple of
LRECL. E.g, for LRECL=80, that would be 32720.

-- gil

[Steve Thompson]

From: Hobart Spitz <orex...@GMAIL.COM>
Date: 02/26/2013 03:56 PM

I would be cautious about making all modules internal, just as I would be
cautious about making all modules external:

- If they need to be internal because you need access to a variable
pool
or for performance, do so. If a module is only called once, or only
under
certain conditions, making it internal is unnecessary with little
benefit.
- If you don't need to make a module external , don't. It's a
maintenance headache.

I've seen people go to both extremes. They were sorry!

<SNIPPAGE>

I know one of the extremes. There is a certain REXX that was written that
is 23000+ lines (IIRC). There is a book about bad coding techniques. What
should and shouldn't be done for giving variables names, having comment
-less code, or comments that are cryptic, etc.

That particular REXX would have been the reason for writing that book (I
wish I could remember the title, but one look at that book after having to
do maint on that sucker told me they had to have been looking over the
author's shoulder).

At any rate, the one that I've written for running under ISPF control is
designed for doing a particular thing and then a JOB takes over from
there. The batch oriented REXX has both internal and external routines,
and even invokes IBM utilities.

So as I've said before, my main concern is the code that has to run under
TSO/ISPF where a user's terminal could be tied up for a long period. I
want it to be as fast as possible to stay out of 3rd / 4th period.

I think that the ultimate improvement will be compiling that REXX.

[Adrian Stern]

My example of an external routine that had to be internalised was one that
translated names read from a database where they were stored in capitals to
a more natural look where each name started with a capital letter and
continued with small letters. And it had to cope with Irish, Scottish,
French and German quirks. Dead slow when external and interpreted - zipped
along when internal.

I would agree about size though - I think my longest program was 4 or 500
lines and that was because it contained a lot of formatting to emulate
windows forms.

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Steve Thompson

Sent: den 27 februari 2013 18:05
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] Tuning Question

[Paul Gilmartin]

On Feb 27, 2013, at 01:46, Adrian Stern wrote:

> Actually a literal instead of a function call makes noticeable savings
>

You've said that repeatedly. I'm not sure I understand.
Obviuosly:

X = 'A'

will outperform:

X = translate( 'a' )

... but that's pretty trivial.

A colleague once tested and found that for string comparisons:

if A==B ...

slightly outperforms:

if A=B ...

The semantics are different, but often acceptable;
sometimes preferable. I always test:

if RC==0 ...

Someone once claimed that by some optimization, Rexx
performs better with single-character symbols than with
multi-character symbols, perhaps more so than could be
explained by lexical analyzer overhead.

-- gil

[Adrian Stern]

Obviouosly not. But for example you may write:

If pos() then
Do
X=substr(pos())
End

Whereas:

iPos=pos()

if iPos then
Do
X=substr(iPos)
End
Uses fewer resources

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Paul Gilmartin
Sent: den 27 februari 2013 18:46
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] Tuning Question

[Phil Smith III]

Adrian Stern wrote:
>Obviouosly not. But for example you may write:

>If pos() then
>Do
> X=substr(pos())
>End

>Whereas:

>iPos=pos()
>if iPos then
>Do
> X=substr(iPos)
>End
>Uses fewer resources

Hm? This makes no sense: the first format won't work unless POS (which I'm
assuming isn't the POS BIF) only ever returns 0 or 1.

If instead you meant something like:
s = 'asdfsafdsaf'
if pos() <> 0 then
Do
X=substr(s, pos())
End
exit
POS:
return 3

vs

s = 'asdfsafdsaf'
iPos=pos()

if iPos <> 0 then
Do
X=substr(s,iPos)
End
exit

POS:
return 3

Then the answer is "No kidding, you're calling the POS function once instead
of twice". Literal-ness has nothing to do with it: in fact, if you replace
the second operand on the SUBSTR with a literal (thus removing the second
POS call in the first case, and the variable substitution in the second),
the first example is more efficient.

What am I missing here?

[Adrian Stern]

God you need spoonfeeding
If pos(needle,haystack) > 0
Then
Do
X=substr(anystring, pos(needle,haystack))
End
Compared with
iPos = pos(needle,haystack)

if iPos > 0
then
Do

X=substr(anystring,iPos)
End

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Phil Smith III
Sent: den 28 februari 2013 14:09
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] Tuning Question

[Bodoh John Robert [Contractor]]

Before you spoon-feed, make sure that what you are feeding is palatable. The title is tuning. So why the multiple POS function calls and why the extra DO - END.

John

[Adrian Stern]

Dear oh dear!

I was just sketching an example of how one can save resources by not
repeating function call. There is no "extra" do-end pair - it's an example -
just a sketch of what I've seen and how to "tune it up" a bit.

Just like if you know a loop is to execute 10 times then
Do 10

End
Is more efficient than
Do I = 1 to 10
End
Or even
Do forever
X=x+1
If x<10 then leave

[Mickey]

Here I disagree. Do i = 1 to x is more efficient than keeping a counter and
incrementing it for each iteration. Most of my core processing do loops have
something like an I = 1 to input.0, and then I can do all my processing by
accessing the current row as input.i.

[Thomas Berg]

AFAIK there is a special optimization of the code if the "looping" variable is only once char.
E g this loop I optimized:

Do i = 1 To input.0
...
End

But this is not:

Do ii = 1 To input.0
...
End



Regards
Thomas Berg
____________________________________________________________________
Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ)


> -----Ursprungligt meddelande-----
> Fr�n: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] F�r
> Mickey
> Skickat: den 4 mars 2013 02:43
> Till: TSO-...@VM.MARIST.EDU
> �mne: Re: [TSO-REXX] Tuning Question

[Adrian Stern]

I fear you may not actually understand what I write and I can't think of any
other way of putting it - those were examples of inefficiency, compared to
the good example of Do 10!
Would you like me to try another language?

[Phil Smith III]

Adrian Stern wrote:
>God you need spoonfeeding
<trimmed>

Wow, rude much?

My point remains: No kidding, one function call vs. two is cheaper. And as
someone else noted, if you're performance tuning, the extra DO/END isn't
free, either. I know, "I use the compiler". That's great. Not everyone does;
if you're going to claim to offer tuning tips, be clear and complete. That
goes for your example, too, which *wasn't* clear OR complete, since it
didn't work as written.

...phsiii

[Ken MacKenzie]

Hi Adrian,

Maybe you do it deliberately to provoke reaction but you remind me of the
guy driving the wrong way on the motorway (freeway, autoroute, autobahn,
autostrada, autopista, otoyol, snelweg, expressway, thruway) complaining
about all the other idiots who are getting it wrong.

[Adrian Stern]

It was neither an example nor meant to work! It was just a sketch example -
which is why I wrote spoon-feeding - do you really need everything spelled
out?

My whole point was to illustrate how to save on calls - I didn't know you
needed working examples - and there is NO extra do/end since there's no
code! God!

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Phil Smith III
Sent: den 4 mars 2013 12:33
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] Tuning Question

[Adrian Stern]

I cannot understand why a sketched example should be so hard to understand!
Maybe you're all Americans! (That was provocative!)

[Bodoh John Robert [Contractor]]

I didn't know that the Lord subscribed to this list. I'll have to be more careful.

John

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@vm.marist.edu] On Behalf Of Adrian Stern

[Mickey]

Why is it that in this day of perpetual communication, some people cannot
engage in civil discourse, and must resort to being complete assholes? Want
an example? Try the nearest mirror. Fortunately, I can block your email, and
need not see any more of your idiocy on my PC.

[Mickey]

He reminds me of a common UseNet troll

Mickey

[Mickey]

Actually, I am an Israeli by birth, and an American by the grace of God. You
are just a rude, arrogant individual. Frankly, I would bet my life and the
lives of all those I know that I have written 20 lines of production Rexx
code for every line you have, and frankly, the day I need lessons from a
stuffed shirt will be the day I hang up my keyboard and mouse and take up
gardening turnips for a living.

[Adrian Stern]

If you choose not to learn that's entirely up to you

[Adrian Stern]

That's plain abuse Mr Mouse

[Mickey]

Learn? From YOU? Now that is the best joke I have heard in YEARS !!!

[Adrian Stern]

Glad to amuse

[Paul Gilmartin]

On Mar 4, 2013, at 01:52, Thomas Berg wrote:

> AFAIK there is a special optimization of the code ...
>
Also note that any reference to a standard function such as:

X = length( A )

causes the interpreter to scan to the end of the entire program
searching for a possible user-defined function with the same
name, which may be considerable overhead, whereas quoting the
function name, as in:

X = 'LENGTH'( A )

searches only for the standard (or possibly external) function.

But beware! In CMS Rexx, the quoted function name is treated as
case-sensitive; in TSO Rexx, case-insensitive.

Conversely, this behavior is useful in that a call to any
function results in the interpreter's immediately detecting
syntax errors in instructions that otherwise might not be
scanned until much later.

-- gil

[Thomas Berg]

> -----Ursprungligt meddelande-----
> Från: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] För Paul
> Gilmartin
> Skickat: den 4 mars 2013 16:20
> Till: TSO-...@VM.MARIST.EDU
> Ämne: Re: [TSO-REXX] SV: [TSO-REXX] Tuning Question

>
> On Mar 4, 2013, at 01:52, Thomas Berg wrote:
>
> > AFAIK there is a special optimization of the code ...
> >
> Also note that any reference to a standard function such as:
>
> X = length( A )
>
> causes the interpreter to scan to the end of the entire program
> searching for a possible user-defined function with the same name,
> which may be considerable overhead, whereas quoting the function name,
> as in:
>
> X = 'LENGTH'( A )
>
> searches only for the standard (or possibly external) function.

But I would presume that this is only relevant for the first call to the function ?
As it seems that the natural thing for rexx to do is to save the pointer/whatever to the function for further calls to the same routine.

> But beware! In CMS Rexx, the quoted function name is treated as case-
> sensitive; in TSO Rexx, case-insensitive.
>
> Conversely, this behavior is useful in that a call to any function
> results in the interpreter's immediately detecting syntax errors in
> instructions that otherwise might not be scanned until much later.

Can You give an example so I can understand what you are thinking about ?

Regards
Thomas Berg
____________________________________________________________________
Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ)

[Vitonis, Tony]

I wonder how often this is a bottleneck in code performance.

-----Original Message-----
From: Paul Gilmartin
Sent: Monday, March 04, 2013 10:20 AM
To: TSO-...@VM.MARIST.EDU

Subject: Re: SV: [TSO-REXX] Tuning Question

Also note that any reference to a standard function such as:

X = length( A )

causes the interpreter to scan to the end of the entire program searching for a possible user-defined function with the same name, which may be considerable overhead, whereas quoting the function name, as in:

X = 'LENGTH'( A )

searches only for the standard (or possibly external) function.

[Adrian Stern]

Hmmm - does this really matter Paul? I don't know how many times the code is
scanned but it wouldn't be scanned more than once would it? Surely a first
scan would map internal and external calls for future reference? Does anyone
actually know how this works?

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Paul Gilmartin
Sent: den 4 mars 2013 16:20
To: TSO-...@VM.MARIST.EDU

[Phil Smith III]

Paul Gilmartin wrote:
>Also note that any reference to a standard function such as:

> X = length( A )

>causes the interpreter to scan to the end of the entire program
>searching for a possible user-defined function with the same
>name, which may be considerable overhead, whereas quoting the
>function name, as in:

> X = 'LENGTH'( A )

>searches only for the standard (or possibly external) function.

>But beware! In CMS Rexx, the quoted function name is treated as
>case-sensitive; in TSO Rexx, case-insensitive.

>Conversely, this behavior is useful in that a call to any
>function results in the interpreter's immediately detecting
>syntax errors in instructions that otherwise might not be
>scanned until much later.

Or, as others have noted, for overriding a BIF (not recommended for sanity,
of course).

There's a recurring performance myth that quoting your function names is
thus good for performance. It's wrong: Rexx does indeed build a lookaside
table of functions, so if you quote all your functions, all you avoid is
that scan-the-rest-of-the-program pass. BUT quoted function names don't go
into the lookaside, so you lose more than you gain. I suppose in the error
case of a function called on line 3 of a 10,000-line program, the result of
which causes an EXIT, you might save a bit -- but typically that isn't the
path to optimize, of course.

Whoever (sorry, I don't feel like grinding back through the Digest to figure
out who -- it would be nice if folks would TRIM replies!) tested with LENGTH
and 'LENGTH' in a loop already showed this.

And of course as someone else noted, quoting functions is a pain to type and
read -- consider:
SAY 'LENGTH' 'LENGTH'(X) 'IS A SUBSTR OF' 'SUBSTR'(Y,1,'LENGTH'(Z))

...much harder to read, even beyond the all caps!

FTR, all this was analyzed to death in CMS decades ago. Too bad those days
aren't archived (or maybe they are; I leave it as an exercise for someone
else to hunt that down).

...phsiii

[Thomas Berg]

There is one place where quoted built-in functions is good: in signal error routines. You don't want rexx to scan the source (again) when you have catched a NOVALUE or a SYNTAX condition.

So e g:
...
Signal on novalue
Signal on syntax
...
NOVALUE: SYNTAX:
Say sigl "CONDITION"('C') "CONDITION"('D')
...

Regards
Thomas Berg
____________________________________________________________________
Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ)

> -----Original Message-----
> From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On
> Behalf Of Phil Smith III
> Sent: Tuesday, March 05, 2013 3:59 PM
> To: TSO-...@VM.MARIST.EDU
> Subject: Re: [TSO-REXX] SV: [TSO-REXX] Tuning Question
>

[Adrian Stern]

After the incident with the rogue Xedit I seem to remember I did quote
almost every BIF just to make sure I got the BIF and not some sysprog's
version!
That was in CMS

[Paul Gilmartin]

On Mar 6, 2013, at 03:00, Adrian Stern wrote:

> After the incident with the rogue Xedit I seem to remember I did quote
> almost every BIF just to make sure I got the BIF and not some sysprog's
> version!
> That was in CMS
>

Wouldn't it be nice if CMS (and z/OS) allowed you to
select a MODULE by fully qualified path, HFS, MDFS, or
DSN(MEMBER), rather than by directory/STEPLIB search
order? TSO sort of achieves that, but only by putting
the DSN at the head of the TASKLIB catenation for the
duration of the execution.

-- gil

[Phil Smith III]

Thomas Berg wrote:
>There is one place where quoted built-in functions is good: in signal error
>routines. You don't want rexx to scan the source (again) when you have
>catched a NOVALUE or a SYNTAX condition.

Interesting thought...but it's not going to scan it *again*, so unless
you're worried about the SIGNAL getting triggered before the first
non-quoted function call (and what are the odds of that?) it's not really a
very interesting case, I don't think. Unless, as noted earlier, you're
insane enough to override a BIF.

[Adrian Stern]

That's asking for a big change in the os - maybe too big. It's always
surprised me that in the foreground you can't create a "job" as easily as
you can in the background - and altlib I've always felt a little uncertain
about - which has often caused me to make foreground programs write a log
with at leats the name and version of every routine involved - just to be
sure.

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Paul Gilmartin
Sent: den 6 mars 2013 15:26
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] SV: [TSO-REXX] Tuning Question

[Thomas Berg]

> -----Original Message-----
> From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On
> Behalf Of Phil Smith III
> Sent: Wednesday, March 06, 2013 9:01 PM
> To: TSO-...@VM.MARIST.EDU
> Subject: Re: [TSO-REXX] SV: [TSO-REXX] Tuning Question
>

> Thomas Berg wrote:
> >There is one place where quoted built-in functions is good: in signal
> >error routines. You don't want rexx to scan the source (again) when
> >you have catched a NOVALUE or a SYNTAX condition.
>
> Interesting thought...but it's not going to scan it *again*, so unless
> you're worried about the SIGNAL getting triggered before the first non-
> quoted function call (and what are the odds of that?) it's not really a
> very interesting case, I don't think. Unless, as noted earlier, you're
> insane enough to override a BIF.

I got bitten by this a long time ago (no, I did not override any BIF).
The exact circumstances I don't remember but it was cured by quoting the BIF functions.

Regards
Thomas Berg
____________________________________________________________________
Thomas Berg Specialist z/OS\RQM\IT Delivery SWEDBANK AB (Publ)

[Bodoh John Robert [Contractor]]

What a horrible thought. That means that whenever you rename of move it to another data set, you have to find all uses of the module on the entire system and change every occurrence. What a mess.

John Bodoh

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@vm.marist.edu] On Behalf Of Paul Gilmartin
Sent: Wednesday, March 06, 2013 9:26 AM
To: TSO-...@vm.marist.edu
Subject: Re: [TSO-REXX] SV: [TSO-REXX] Tuning Question

[Phil Smith III]

Adrian Stern wrote:
>After the incident with the rogue Xedit I seem to remember I did quote
>almost every BIF just to make sure I got the BIF and not some sysprog's
>version!
>That was in CMS

Why? That isn't how it works. Having a POS EXEC isn't going to make a POS
function call suddenly invoke that EXEC:

POS EXEC:
/**/ say 'Hi'

From Rexx:
say pos(1, 2)
0
call pos 1, 2
say result
0
'EXEC POS'
Hi

ObAnecdote: A million years ago, I suspected another sysprog was browsing
others' CMS A-disks, using a hack that let him see mode 0 files (this was
well before ACCESSM0). I created an XEDIT EXEC that was mode 0 and would
examine the invoking userid. If it was not one of mine, it would send me a
CP MSG noting that userid x had the disk LINKed and ACCESSed with mode 0
files accessible. Sure enough, I caught him the next day. (I also copied it
as FLIST and BROWSE; it was smart enough to do a PARSE SOURCE to invoke the
REAL, intended command underneath, as well as to include that command in the
message it sent). I still have that EXEC, although it's of no practical use
now.

...phsiii

[Paul Gilmartin]

On Mar 7, 2013, at 07:12, Phil Smith III wrote:
>
> ObAnecdote: A million years ago, I suspected another sysprog was browsing

> others' CMS A-disks, using a hack that let him see mode 0 files ...
>
And did you have a problem with that, or were you just giving
him quid-pro-quo?

> ... I created an XEDIT EXEC that was mode 0 and would
> examine the invoking userid. If it was not one of mine, ...
>
Might someone else have had a problem with your doing that?

> ...; it was smart enough to do a PARSE SOURCE to invoke the

> REAL, intended command underneath, as well as to include that command in the

> message it sent). ...
>
Wouldn't PARSE SOURSE always have returned XEDIT unless the
user had defined a SYNONYM?

-- gil

[Paul Gilmartin]

On Mar 7, 2013, at 06:41, Bodoh John Robert [Contractor] wrote:

> What a horrible thought. That means that whenever you rename of move it to another data set, you have to find all uses of the module on the entire system and change every occurrence. What a mess.
>

Not really. The existing scheme imposes similar requirememts:
you have to find all STEPLIB/TASKLIB/ALTLIB/TSO CALL that might
be involved and change each.

(I did say "allowed", not "required".)

UNIX has long supported a similar construct. No one seems much
bothered by it, and no one is required to use it.

> -----Original Message-----
> From: TSO REXX Discussion List [mailto:TSO-...@vm.marist.edu] On Behalf Of Paul Gilmartin
> Sent: Wednesday, March 06, 2013 9:26 AM
> To: TSO-...@vm.marist.edu
> Subject: Re: [TSO-REXX] SV: [TSO-REXX] Tuning Question
>

> Wouldn't it be nice if CMS (and z/OS) allowed you to
> select a MODULE by fully qualified path, HFS, MDFS, or
> DSN(MEMBER), rather than by directory/STEPLIB search
> order?

[Bodoh John Robert [Contractor]]

I was always taught that JCL was the bridge between the code and the data. The code could process any external data without change just by using JCL. I always thought that was one of the architectural points of MVS - Z/OS.

Everywhere I worked it was always easier to change JCL rather than code. Suppose it was compiled REXX where I distributed the compiled code to customers. Compiled not because of speed but for protection of the source. Requiring a specific data set name for the functions would be a real restriction on the customer.

John

[Paul Gilmartin]

On Mar 7, 2013, at 08:59, Bodoh John Robert [Contractor] wrote:

> I was always taught that JCL was the bridge between the code and the data. The code could process any external data without change just by using JCL. I always thought that was one of the architectural points of MVS - Z/OS.
>

So, in JCL, it might be either:

//STEP EXEC PGM=IEFBR14
or:
//STEP EXEC PGM=SYS1.LINKLIB(IEFBR14)

> Everywhere I worked it was always easier to change JCL rather than code. Suppose it was compiled REXX where I distributed the compiled code to customers. Compiled not because of speed but for protection of the source. Requiring a specific data set name for the functions would be a real restriction on the customer.
>

Once again, I said (twice, so far; this is the third time)
"allowed", not "requiring" (your word). I would not envision
any current capability going away.

> -----Original Message-----
> From: TSO REXX Discussion List [mailto:TSO-...@vm.marist.edu] On Behalf Of Paul Gilmartin
> Sent: Thursday, March 07, 2013 10:25 AM
>

> (I did say "allowed", not "required".)
>
> UNIX has long supported a similar construct. No one seems much
> bothered by it, and no one is required to use it.
>
>> -----Original Message-----
>> From: TSO REXX Discussion List [mailto:TSO-...@vm.marist.edu] On Behalf Of Paul Gilmartin
>> Sent: Wednesday, March 06, 2013 9:26 AM
>>

[Adrian Stern]

As far as I remember that's exactly how it works - the first found with that
name is the one executed - sorry commands not functions perhaps - it was so
long ago

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Phil Smith III

Sent: den 7 mars 2013 15:13
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] SV: [TSO-REXX] Tuning Question

[Phil Smith III]

Paul Gilmartin wrote:
>Wouldn't PARSE SOURSE always have returned XEDIT unless the
>user had defined a SYNONYM?

Your observation is correct, but what I meant is that using PARSE SOURCE let
me determine whether the code was invoked as XEDIT EXEC, FLIST EXEC, et al.
-- that is, which of my traps had sprung. Sorry for being unclear! (as
opposed to "nuclear", which would also be common on the Interwebs...)

[Phil Smith III]

Adrian Stern wrote, re being able to specify a specific EXEC or MODULE,
including filemode:

>That's asking for a big change in the os - maybe too big.

In z/OS, maybe; in CMS, not so much. Long, long ago we had an EXECx command
(part of the CMS nucleus) that would let you invoke the BANANA EXEC on the
Y-disk, overriding the one on the A-disk, as EXECY BANANA.

I've had a MODULE EXEC for 30 years that just does an
ADDRESS COMMAND arg(1)
(OK, it didn't use ADDRESS COMMAND when I first wrote it, since Rexx wasn't
out yet!). A similar MODULEx CMS nucleus facility could do the same.

Extending that further, it's not clear that a JCL extension couldn't
implement EXEC

[Paul Gilmartin]

On Mar 8, 2013, at 08:25, Phil Smith III wrote:

> Paul Gilmartin wrote:
>> Wouldn't PARSE SOURSE always have returned XEDIT unless the
>> user had defined a SYNONYM?
>
> Your observation is correct, but what I meant is that using PARSE SOURCE let
> me determine whether the code was invoked as XEDIT EXEC, FLIST EXEC, et al.
> -- that is, which of my traps had sprung. Sorry for being unclear! (as
> opposed to "nuclear", which would also be common on the Interwebs...)
>

An EXEC ought to be able to know its own name without PARSE SOURCE.
But PARSE SOURCE tells you whether it was invoked as a SYNONYM.
And if you needed a dozen EXECs to front-end a dozen commands,
PARSE SOURCE allows you to make a dozen differently named copies
without the need to tailor each to know its own name.

-- gil

[Paul Gilmartin]

On Mar 8, 2013, at 08:31, Phil Smith III wrote:

> Adrian Stern wrote, re being able to specify a specific EXEC or MODULE,
> including filemode:
>> That's asking for a big change in the os - maybe too big.
>
> In z/OS, maybe; in CMS, not so much. Long, long ago we had an EXECx command
> (part of the CMS nucleus) that would let you invoke the BANANA EXEC on the
> Y-disk, overriding the one on the A-disk, as EXECY BANANA.
>

I believe (without referring to the documentation) that the
API to Rexx allows the programmer to specify, independently:
o DDNAME
o MEMBER name
o Default command environment name.

(Why isn't the default command environment for ISPF EDIT
macros ISREDIT rather than TSO? I suppose the programmers
who (hastily?) ported Rexx to the TSO environment were
alien to the Rexx culture. Likewise why must one access
the parameter string with ISREDIT MACRO rather than PARSE
ARG?)

Even short of EXEC PGM=DATA.SET.NAME(MEMBER), it would
be useful to be able to code EXEC PGM=DDNAME(MEMBER).

And the CMS Pipelines REXX stage allows the programmer to
code each of FN, FT, and FM. But the command environment
is always the Pipelines environment.

And z/OS Unix System Services implements the POSIX exec()
syscall that allows the programmer to specify a fully
qualified path, but when exec() recognizes the program as
a Rexx EXEC, it invokes the Rexx interpreter which searches
again for the EXEC, not in the path specified by the programmer,
but in directories mentioned in the PATH enviromment variable;
a drastic design flaw.

-- gil

[Steve Thompson]

Dumb question (like I don't know the answer).

How is the current topic of name of an exec, and if it is a synomyn etc.
related to a "Tuning Question"?

So, for the sake of future REXX people, could you change the Subject to
"CMS environmental issues of the 3rd level for operating under TSO" or
some such?

Regards,
Steve Thompson

[Bob Bridges]

I'm just catching up with this discussion, and I've marked a lot of places
to ask additional questions. This is one of them: I've never known about
this "/*% nocomment rexx */ thingy, and I have to guess at what it does.
But surely it does something about ignoring the comments during processing,
which confuses me because at execution time REXX does that anyway...doesn't
it?

If it helps, understand that I've never used the compiler; my experience is
entirely with interpreted TSO-REXX.

---
Bob Bridges
rhb...@attglobal.net, cell 336 382-7313
bbridge...@foodlion.com, 704 310-4526

/* On the international front, President Bush and Russian President Vladimir
Putin sign an arms-reduction treaty under which the U.S. will destroy about
two-thirds of its nuclear arsenal, and Russia will ''make every effort,
within reason'' to try to find out who, exactly, HAS its nuclear arsenal.
-from Dave Barry's 2002 "Year in Review" */

-----Original Message-----
From: Andreas Fischer
Sent: Wednesday, February 27, 2013 04:44

* as it has been mentioned, i use /*% nocomment rexx */ in the first line

[Steve Thompson]

From: Bob Bridges <rhb...@ATTGLOBAL.NET>
Date: 03/11/2013 04:11 PM

I'm just catching up with this discussion, and I've marked a lot of places
to ask additional questions. This is one of them: I've never known about
this "/*% nocomment rexx */ thingy, and I have to guess at what it does.
But surely it does something about ignoring the comments during
processing,
which confuses me because at execution time REXX does that
anyway...doesn't
it?

<SNIPPAGE>

Take a look at TSO/E REXX Reference SA22-7790-09 and search for
%nocomment.

I hadn't read that part of the manual before either, because I didn't
think I needed to read those parts of the manual... So much for
assumptions.

Regards,
Steve Thompson

[John P Kalinich]

I think I am the one that mentioned the nocomment thingy. But as I read more about this compression feature, I have a feeling that it may be tied to VLF (Virtual Lookaside Facility) based on this link.

http://publib.boulder.ibm.com/infocenter/zos/v1r13/index.jsp?topic=%2Fcom.ibm.zos.r13.ikjb600%2Ffilec.htm

Regards,
John K

-----TSO REXX Discussion List <TSO-...@vm.marist.edu> wrote: -----
To: TSO-...@vm.marist.edu
From: Bob Bridges
Sent by: TSO REXX Discussion List
Date: 03/11/2013 04:11PM
Subject: Re: [TSO-REXX] Tuning Question (% NOCOMMENT REXX)

[Bob Bridges]

Adrian, you really are unnecessarily abrasive sometimes -- but only
sometimes -- and you must be aware of it yourself. I think you just let
your frustration get away with you. But for what it's worth, ~I~ knew what
you meant by your example, though I had to think about it a while. (It
wasn't even your example, fully; you just fleshed out someone else's a
little.)

...Oh, and although you and that sabra (Mickey, his name is) brought your
exchange on yourselves, his comments about your abilities are patently
untrue. But then, you knew that.

---
Bob Bridges
rhb...@attglobal.net, cell 336 382-7313
bbridge...@foodlion.com, 704 310-4526

/* On the international front, President Bush and Russian President Vladimir
Putin sign an arms-reduction treaty under which the U.S. will destroy about
two-thirds of its nuclear arsenal, and Russia will ''make every effort,
within reason'' to try to find out who, exactly, HAS its nuclear arsenal.
-from Dave Barry's 2002 "Year in Review" */

-----Original Message-----

From: Adrian Stern
Sent: Monday, March 4, 2013 07:32

It was neither an example nor meant to work! It was just a sketch example -
which is why I wrote spoon-feeding - do you really need everything spelled
out?

My whole point was to illustrate how to save on calls - I didn't know you
needed working examples - and there is NO extra do/end since there's no
code! God!

-----Original Message-----
From: Phil Smith III
Sent: den 4 mars 2013 12:33

Wow, rude much?

My point remains: No kidding, one function call vs. two is cheaper. And as
someone else noted, if you're performance tuning, the extra DO/END isn't
free, either. I know, "I use the compiler". That's great. Not everyone does;
if you're going to claim to offer tuning tips, be clear and complete. That
goes for your example, too, which *wasn't* clear OR complete, since it
didn't work as written.

--- Adrian Stern wrote:
>God you need spoonfeeding
<trimmed>

[Adrian Stern]

It is extremely frustrating to throw out a simple idea, simply put and have
it misunderstood. And I think many people are far too sensitive - it's
possible the media makes sarcasm appear abrasive.

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of

Bob Bridges
Sent: den 11 mars 2013 23:39
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] Tuning Question