Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Distinguishing REXX and CLIST
303 views
Skip to first unread message
Ken MacKenzie
Apr 18, 2012, 6:51:40 AM4/18/12
to
The discussion on whether or not REXX needs a comment to start have become
mixed up with another thread and are, therefore, difficult to isolate, so
I'm starting a new thread.
Here's the deal, as I understand things:
In the beginning there were only CLISTs and they resided on a dataset
concatenated into SYSPROC.
Along came REXX and REXX execs could reside in either SYSPROC or SYSEXEC
(a brand new concept)
CLISTs cannot execute from SYSEXEC
The system needed to be able to distinguish between CLIST and REXX so the
idea of having the word REXX in the first line (embedded in a comment) was
invented
Rules:
If you write a REXX exec and put it in SYSEXEC, you don't need a comment
at the start.
Conversely, if you put a REXX exec in SYSPROC you must have the word REXX
in the first line (as part of a comment)
An alternative way of running a CLIST or REXX is to explicitly type the
command, so if you had an CLIST called FUBAR, on library MY.CLIST you
could type: TSO EXEC 'MY.CLIST(FUBAR)'
If you have an exec called FOOBAR, following the above rules, and you put
it in MY.CLIST, you can type: TSO EXEC 'MY.CLIST(FOOBAR)'
And, if you have an exec called FOOTSPA in MY.CLIST that doesn't have the
appropriate REXX identifier and type TSO EXEC 'MY.CLIST(FOOTSPA)' it will
fail. If however, you add the EXEC keyword at the end, it will work: TSO
EXEC 'MY.CLIST(FOOTSPA)' EXEC works.
Try all of the above scenarios and you will see.
If you break the rules, you will see:
IKJ56479I COMMAND REXX NOT FOUND OR REXX IDENTIFIER IS MISSING+
IKJ56479I SUPPLY '/* REXX */' AS THE FIRST RECORD TO EXECUTE AS A REXX
EXEC OR, FOR AN EXPLICIT EXEC, SUPPLY THE EXEC KEYWORD ON THE EXEC COMMAND
There, the gauntlet has been thrown down ... anyone care to pick it up?
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
mixed up with another thread and are, therefore, difficult to isolate, so
I'm starting a new thread.
Here's the deal, as I understand things:
In the beginning there were only CLISTs and they resided on a dataset
concatenated into SYSPROC.
Along came REXX and REXX execs could reside in either SYSPROC or SYSEXEC
(a brand new concept)
CLISTs cannot execute from SYSEXEC
The system needed to be able to distinguish between CLIST and REXX so the
idea of having the word REXX in the first line (embedded in a comment) was
invented
Rules:
If you write a REXX exec and put it in SYSEXEC, you don't need a comment
at the start.
Conversely, if you put a REXX exec in SYSPROC you must have the word REXX
in the first line (as part of a comment)
An alternative way of running a CLIST or REXX is to explicitly type the
command, so if you had an CLIST called FUBAR, on library MY.CLIST you
could type: TSO EXEC 'MY.CLIST(FUBAR)'
If you have an exec called FOOBAR, following the above rules, and you put
it in MY.CLIST, you can type: TSO EXEC 'MY.CLIST(FOOBAR)'
And, if you have an exec called FOOTSPA in MY.CLIST that doesn't have the
appropriate REXX identifier and type TSO EXEC 'MY.CLIST(FOOTSPA)' it will
fail. If however, you add the EXEC keyword at the end, it will work: TSO
EXEC 'MY.CLIST(FOOTSPA)' EXEC works.
Try all of the above scenarios and you will see.
If you break the rules, you will see:
IKJ56479I COMMAND REXX NOT FOUND OR REXX IDENTIFIER IS MISSING+
IKJ56479I SUPPLY '/* REXX */' AS THE FIRST RECORD TO EXECUTE AS A REXX
EXEC OR, FOR AN EXPLICIT EXEC, SUPPLY THE EXEC KEYWORD ON THE EXEC COMMAND
There, the gauntlet has been thrown down ... anyone care to pick it up?
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
Rob Zenuk
Apr 18, 2012, 1:39:52 PM4/18/12
to
Excellent summary.
My preference is to always put my EXEC's in SYSEXEC. I do this for my
personal stuff and we have both SYSEXEC and SYSPROC "production" libraries.
However, I have some Sysprog's I work with (not all) that insist on moving
my EXEC's to SYSPROC when they are rolled out for the masses and/or
production use (if a "system" tool).
So for these, I use the comment block and intentionally put REXX on the
second line so I find out at implementation/certification time if they moved
it to SYSPROC. This gives me the opportunity to educate them and try to
sway them to change their behavior. If they are un-phased by my arguments,
I simply delete the first line and the REXX comment is on the first line.
During future changes (if necessary), my standard IEBIBOL and SUPERC compare
with my personal copy identifies this immediately. In those cases, I
usually promote it with the extra comment line again in the hopes of getting
someone else that will move it to SYSEXEC...
Rob
My preference is to always put my EXEC's in SYSEXEC. I do this for my
personal stuff and we have both SYSEXEC and SYSPROC "production" libraries.
However, I have some Sysprog's I work with (not all) that insist on moving
my EXEC's to SYSPROC when they are rolled out for the masses and/or
production use (if a "system" tool).
So for these, I use the comment block and intentionally put REXX on the
second line so I find out at implementation/certification time if they moved
it to SYSPROC. This gives me the opportunity to educate them and try to
sway them to change their behavior. If they are un-phased by my arguments,
I simply delete the first line and the REXX comment is on the first line.
During future changes (if necessary), my standard IEBIBOL and SUPERC compare
with my personal copy identifies this immediately. In those cases, I
usually promote it with the extra comment line again in the hopes of getting
someone else that will move it to SYSEXEC...
Rob
Pinnacle
Apr 18, 2012, 3:08:08 PM4/18/12
to
On 4/18/2012 1:39 PM, Rob Zenuk wrote:
> Excellent summary.
>
> My preference is to always put my EXEC's in SYSEXEC. I do this for my
> personal stuff and we have both SYSEXEC and SYSPROC "production" libraries.
> However, I have some Sysprog's I work with (not all) that insist on moving
> my EXEC's to SYSPROC when they are rolled out for the masses and/or
> production use (if a "system" tool).
>
> So for these, I use the comment block and intentionally put REXX on the
> second line so I find out at implementation/certification time if they moved
> it to SYSPROC. This gives me the opportunity to educate them and try to
> sway them to change their behavior. If they are un-phased by my arguments,
> I simply delete the first line and the REXX comment is on the first line.
> During future changes (if necessary), my standard IEBIBOL and SUPERC compare
> with my personal copy identifies this immediately. In those cases, I
> usually promote it with the extra comment line again in the hopes of getting
> someone else that will move it to SYSEXEC...
>
> Rob
I must respectfully disagree with my good friend, the distinguished
> Excellent summary.
>
> My preference is to always put my EXEC's in SYSEXEC. I do this for my
> personal stuff and we have both SYSEXEC and SYSPROC "production" libraries.
> However, I have some Sysprog's I work with (not all) that insist on moving
> my EXEC's to SYSPROC when they are rolled out for the masses and/or
> production use (if a "system" tool).
>
> So for these, I use the comment block and intentionally put REXX on the
> second line so I find out at implementation/certification time if they moved
> it to SYSPROC. This gives me the opportunity to educate them and try to
> sway them to change their behavior. If they are un-phased by my arguments,
> I simply delete the first line and the REXX comment is on the first line.
> During future changes (if necessary), my standard IEBIBOL and SUPERC compare
> with my personal copy identifies this immediately. In those cases, I
> usually promote it with the extra comment line again in the hopes of getting
> someone else that will move it to SYSEXEC...
>
> Rob
gentleman from the great state of Arizona. Putting your Rexx execs into
SYSPROC (or into library concatenated by ALTLIB APPL CLIST) enables them
to be compressed and cached by VLF, whereas placing them in SYSEXEC
disqualifies them from such treatment. That's why I always put my Rexx
execs in SYSPROC, or ALTLIB them. Also be sure to specify the library
name in the COFVLFxx member IKJEXEC class.
Regards,
Tom Conley
Rob Zenuk
Apr 18, 2012, 3:34:34 PM4/18/12
to
Excellent point! Here is another opportunity to use my test harness to
compare the performance difference with and without VLF...
Be back soon with the results...
Rob
compare the performance difference with and without VLF...
Be back soon with the results...
Rob
Paul Gilmartin
Apr 18, 2012, 4:05:32 PM4/18/12
to
On 2012-04-18 11:35, Rob Zenuk wrote:
>
> My preference is to always put my EXEC's in SYSEXEC. I do this for my
> personal stuff and we have both SYSEXEC and SYSPROC "production" libraries.
> However, I have some Sysprog's I work with (not all) that insist on moving
> my EXEC's to SYSPROC when they are rolled out for the masses and/or
> production use (if a "system" tool).
>
> So for these, I use the comment block and intentionally put REXX on the
> second line so I find out at implementation/certification time if they moved
> it to SYSPROC. This gives me the opportunity to educate them and try to
> sway them to change their behavior. If they are un-phased by my arguments,
> I simply delete the first line and the REXX comment is on the first line.
> During future changes (if necessary), my standard IEBIBOL and SUPERC compare
> with my personal copy identifies this immediately. In those cases, I
> usually promote it with the extra comment line again in the hopes of getting
> someone else that will move it to SYSEXEC...
>
This is akin to my own stubborness in keeping my SYSEXEC (and sometimes
>
> My preference is to always put my EXEC's in SYSEXEC. I do this for my
> personal stuff and we have both SYSEXEC and SYSPROC "production" libraries.
> However, I have some Sysprog's I work with (not all) that insist on moving
> my EXEC's to SYSPROC when they are rolled out for the masses and/or
> production use (if a "system" tool).
>
> So for these, I use the comment block and intentionally put REXX on the
> second line so I find out at implementation/certification time if they moved
> it to SYSPROC. This gives me the opportunity to educate them and try to
> sway them to change their behavior. If they are un-phased by my arguments,
> I simply delete the first line and the REXX comment is on the first line.
> During future changes (if necessary), my standard IEBIBOL and SUPERC compare
> with my personal copy identifies this immediately. In those cases, I
> usually promote it with the extra comment line again in the hopes of getting
> someone else that will move it to SYSEXEC...
>
my SYSPROC) in RECFM=VB. But when Rexx was first incorporated in TSO/E
there was an introductory manual that recommended RECFM=VB, no line numbers,
and use of lower case for legibility. IBM failed to follow its own
advice here. Whenever I edit just about any file, the first thing I do is
insert a mixed-case comment. That way, I never have to be concerned with
ISPF changing the CAPS setting on me.
-- gil
Rob Zenuk
Apr 18, 2012, 5:18:04 PM4/18/12
to
So, I learned something and now debate the value of this feature...
I first put together a test using an EXEC that did a REXX call to another
EXEC and ran it from batch. Basically there was no difference. In fact,
the SYSEXEC might have performance slightly better (results below). This
got me wondering if it even worked for batch. So, I read a little and found
a comment that it only works when a REXX EXEC or CLIST is launched from the
TSO EXEC command... So I wrote a new test driver to see that.
Here are my results from my first test using a REXX CALL of a second level
EXEC using traditional REXX methods (not TSO EXEC):
Non-VLF (from SYSEXEC)
STEPNAME PROCSTEP PROGRAM RC EXCP CPU SRB CLOCK SERV
NON0001 TESTVLF IKJEFT01 00 59 .01 .00 .19 542
NON0010 TESTVLF IKJEFT01 00 87 .01 .00 .08 718
NON0100 TESTVLF IKJEFT01 00 369 .04 .00 .30 2729
NON1000 TESTVLF IKJEFT01 00 3182 .37 .02 2.44 24035
VLF (from SYSPROC)
STEPNAME PROCSTEP PROGRAM RC EXCP CPU SRB CLOCK SERV
VLF0001 TESTVLF IKJEFT01 00 62 .01 .00 .07 644
VLF0010 TESTVLF IKJEFT01 00 104 .02 .00 .13 1301
VLF0100 TESTVLF IKJEFT01 00 567 .12 .00 .52 7290
VLF1000 TESTVLF IKJEFT01 00 5182 .92 .02 3.04 57679
I ran 4 SYSEXEC and 4 SYSPROC test and each did the exact same thing.
Loop once, loop 10 times, loop 100 times, loop 1000 times. Each loop did a
bunch of SAY's for SYSVAR stuff and called a second EXEC from the same PDS
that simply did a SAY and returned.
Here are the 2 EXEC's
TESTVLF
/* REXX */
arg loops
if loops = '' then loops = 1
do loops
say 'User Information:'
say 'SYSPREF:' SYSVAR('SYSPREF')
say 'SYSPROC:' SYSVAR('SYSPROC')
say 'SYSUID:' SYSVAR('SYSUID')
say 'SYSTERM:' SYSVAR('SYSTERMID')
say 'Exec Information:'
say 'SYSENV:' SYSVAR('SYSENV')
say 'SYSICMD:' SYSVAR('SYSICMD')
say 'SYSISPF:' SYSVAR('SYSISPF')
say 'SYSNEST:' SYSVAR('SYSNEST')
say 'SYSPCMD:' SYSVAR('SYSPCMD')
say 'SYSSCMD:' SYSVAR('SYSSCMD')
say 'System Information:'
say 'SYSHSM:' SYSVAR('SYSHSM')
say 'SYSLRACF:' SYSVAR('SYSLRACF')
say 'SYSRACF:' SYSVAR('SYSRACF')
say 'SYSTSOE:' SYSVAR('SYSTSOE')
say 'Timing Information:'
say 'SYSSRV:' SYSVAR('SYSSRV')
say 'SYSCPU:' SYSVAR('SYSCPU')
say 'ELAPSED:' TIME('E')
call testvlf2
end
say 'Final Timing Information:'
say 'SYSSRV:' SYSVAR('SYSSRV')
say 'SYSCPU:' SYSVAR('SYSCPU')
say 'ELAPSED:' TIME('E')
TESTVLF2
/* rexx */
say 'Made it here too'
Here is my test JCL:
//jobcard...
//***************************************************************
//* TSO BATCH JOB *
//***************************************************************
//SYSEXEC PROC LOOPS=1
//TESTVLF EXEC PGM=IKJEFT01,PARM='TESTVLF &LOOPS'
//SYSEXEC DD DSN=SYS0.REXX.USER.EXEC,DISP=SHR
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
// PEND
//SYSPROC PROC LOOPS=1
//TESTVLF EXEC PGM=IKJEFT01,PARM='TESTVLF &LOOPS'
//SYSPROC DD DSN=SYS0.REXX.USER.EXEC,DISP=SHR
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
// PEND
//***************************************************************
//* SYSEXEC TIMINGS *
//***************************************************************
//NON0001 EXEC SYSEXEC,LOOPS=1
//NON0010 EXEC SYSEXEC,LOOPS=10
//NON0100 EXEC SYSEXEC,LOOPS=100
//NON1000 EXEC SYSEXEC,LOOPS=1000
//***************************************************************
//* SYSPROC TIMINGS *
//***************************************************************
//VLF0001 EXEC SYSPROC,LOOPS=1
//VLF0010 EXEC SYSPROC,LOOPS=10
//VLF0100 EXEC SYSPROC,LOOPS=100
//VLF1000 EXEC SYSPROC,LOOPS=1000
Here is pertinent section of the COFVLF00 member:
.
.
CLASS NAME(CSVLLA) /* Class name for Library Lookaside @P2C*/
EMAJ(LLA) /* Major name for Library Lookaside @P2C*/
CLASS NAME(IKJEXEC) /* Class name for TSO CLISTs */
EDSN(SYS0.REXX.USER.EXEC)
EDSN(SYS0.REXX.IBM.EXEC)
MAXVIRT(512)
CLASS NAME(IGGCAS) /* Class name for catalogs */
.
.
So, I changed my first EXEC to TESTVLF1 and had it TSO EXEC the same TSTVLF2
from above...
TESTVLF1
/* rexx */
arg loops
if loops = '' then loops = 1
say 'Made it here'
do loops
"EXEC 'SYS0.REXX.USER.EXEC(TESTVLF2)'"
end
Here are the results using the same JCL (just changing the EXEC name from
TESTVLF to TESTVLF1)
STEPNAME PROCSTEP PROGRAM RC EXCP CPU SRB CLOCK SERV
NON0001 TESTVLF IKJEFT01 00 28 .01 .00 .22 575
NON0010 TESTVLF IKJEFT01 00 81 .03 .00 .41 1606
NON0100 TESTVLF IKJEFT01 00 624 .19 .01 4.22 11867
NON1000 TESTVLF IKJEFT01 00 5224 1.84 .05 42.56 113K
STEPNAME PROCSTEP PROGRAM RC EXCP CPU SRB CLOCK SERV
VLF0001 TESTVLF IKJEFT01 00 25 .01 .00 .12 568
VLF0010 TESTVLF IKJEFT01 00 59 .02 .00 .07 946
VLF0100 TESTVLF IKJEFT01 00 419 .09 .00 .24 5371
VLF1000 TESTVLF IKJEFT01 00 4028 .80 .03 2.15 50489
So, significant difference.
BUT, WHO DOES THIS? My conclusion is this is not a player for real REXX
applications that use real REXX subroutines and functions.
My two cents. Maybe I need to be educated... or go on vacation... I'm
actually gone for the next 3 weeks on vacation - one of the reasons I had
time to phutz with this stuff... Short timer attitude...
Rob
-----Original Message-----
From: Pinnacle [mailto:pinn...@rochester.rr.com]
Sent: Wednesday, April 18, 2012 12:07 PM
To: TSO REXX Discussion List
Subject: Re: Distinguishing REXX and CLIST
I first put together a test using an EXEC that did a REXX call to another
EXEC and ran it from batch. Basically there was no difference. In fact,
the SYSEXEC might have performance slightly better (results below). This
got me wondering if it even worked for batch. So, I read a little and found
a comment that it only works when a REXX EXEC or CLIST is launched from the
TSO EXEC command... So I wrote a new test driver to see that.
Here are my results from my first test using a REXX CALL of a second level
EXEC using traditional REXX methods (not TSO EXEC):
Non-VLF (from SYSEXEC)
STEPNAME PROCSTEP PROGRAM RC EXCP CPU SRB CLOCK SERV
NON0001 TESTVLF IKJEFT01 00 59 .01 .00 .19 542
NON0010 TESTVLF IKJEFT01 00 87 .01 .00 .08 718
NON0100 TESTVLF IKJEFT01 00 369 .04 .00 .30 2729
NON1000 TESTVLF IKJEFT01 00 3182 .37 .02 2.44 24035
VLF (from SYSPROC)
STEPNAME PROCSTEP PROGRAM RC EXCP CPU SRB CLOCK SERV
VLF0001 TESTVLF IKJEFT01 00 62 .01 .00 .07 644
VLF0010 TESTVLF IKJEFT01 00 104 .02 .00 .13 1301
VLF0100 TESTVLF IKJEFT01 00 567 .12 .00 .52 7290
VLF1000 TESTVLF IKJEFT01 00 5182 .92 .02 3.04 57679
I ran 4 SYSEXEC and 4 SYSPROC test and each did the exact same thing.
Loop once, loop 10 times, loop 100 times, loop 1000 times. Each loop did a
bunch of SAY's for SYSVAR stuff and called a second EXEC from the same PDS
that simply did a SAY and returned.
Here are the 2 EXEC's
TESTVLF
/* REXX */
arg loops
if loops = '' then loops = 1
do loops
say 'User Information:'
say 'SYSPREF:' SYSVAR('SYSPREF')
say 'SYSPROC:' SYSVAR('SYSPROC')
say 'SYSUID:' SYSVAR('SYSUID')
say 'SYSTERM:' SYSVAR('SYSTERMID')
say 'Exec Information:'
say 'SYSENV:' SYSVAR('SYSENV')
say 'SYSICMD:' SYSVAR('SYSICMD')
say 'SYSISPF:' SYSVAR('SYSISPF')
say 'SYSNEST:' SYSVAR('SYSNEST')
say 'SYSPCMD:' SYSVAR('SYSPCMD')
say 'SYSSCMD:' SYSVAR('SYSSCMD')
say 'System Information:'
say 'SYSHSM:' SYSVAR('SYSHSM')
say 'SYSLRACF:' SYSVAR('SYSLRACF')
say 'SYSRACF:' SYSVAR('SYSRACF')
say 'SYSTSOE:' SYSVAR('SYSTSOE')
say 'Timing Information:'
say 'SYSSRV:' SYSVAR('SYSSRV')
say 'SYSCPU:' SYSVAR('SYSCPU')
say 'ELAPSED:' TIME('E')
call testvlf2
end
say 'Final Timing Information:'
say 'SYSSRV:' SYSVAR('SYSSRV')
say 'SYSCPU:' SYSVAR('SYSCPU')
say 'ELAPSED:' TIME('E')
TESTVLF2
/* rexx */
say 'Made it here too'
Here is my test JCL:
//jobcard...
//***************************************************************
//* TSO BATCH JOB *
//***************************************************************
//SYSEXEC PROC LOOPS=1
//TESTVLF EXEC PGM=IKJEFT01,PARM='TESTVLF &LOOPS'
//SYSEXEC DD DSN=SYS0.REXX.USER.EXEC,DISP=SHR
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
// PEND
//SYSPROC PROC LOOPS=1
//TESTVLF EXEC PGM=IKJEFT01,PARM='TESTVLF &LOOPS'
//SYSPROC DD DSN=SYS0.REXX.USER.EXEC,DISP=SHR
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
// PEND
//***************************************************************
//* SYSEXEC TIMINGS *
//***************************************************************
//NON0001 EXEC SYSEXEC,LOOPS=1
//NON0010 EXEC SYSEXEC,LOOPS=10
//NON0100 EXEC SYSEXEC,LOOPS=100
//NON1000 EXEC SYSEXEC,LOOPS=1000
//***************************************************************
//* SYSPROC TIMINGS *
//***************************************************************
//VLF0001 EXEC SYSPROC,LOOPS=1
//VLF0010 EXEC SYSPROC,LOOPS=10
//VLF0100 EXEC SYSPROC,LOOPS=100
//VLF1000 EXEC SYSPROC,LOOPS=1000
Here is pertinent section of the COFVLF00 member:
.
.
CLASS NAME(CSVLLA) /* Class name for Library Lookaside @P2C*/
EMAJ(LLA) /* Major name for Library Lookaside @P2C*/
CLASS NAME(IKJEXEC) /* Class name for TSO CLISTs */
EDSN(SYS0.REXX.USER.EXEC)
EDSN(SYS0.REXX.IBM.EXEC)
MAXVIRT(512)
CLASS NAME(IGGCAS) /* Class name for catalogs */
.
.
So, I changed my first EXEC to TESTVLF1 and had it TSO EXEC the same TSTVLF2
from above...
TESTVLF1
/* rexx */
arg loops
if loops = '' then loops = 1
say 'Made it here'
do loops
"EXEC 'SYS0.REXX.USER.EXEC(TESTVLF2)'"
end
Here are the results using the same JCL (just changing the EXEC name from
TESTVLF to TESTVLF1)
STEPNAME PROCSTEP PROGRAM RC EXCP CPU SRB CLOCK SERV
NON0001 TESTVLF IKJEFT01 00 28 .01 .00 .22 575
NON0010 TESTVLF IKJEFT01 00 81 .03 .00 .41 1606
NON0100 TESTVLF IKJEFT01 00 624 .19 .01 4.22 11867
NON1000 TESTVLF IKJEFT01 00 5224 1.84 .05 42.56 113K
STEPNAME PROCSTEP PROGRAM RC EXCP CPU SRB CLOCK SERV
VLF0001 TESTVLF IKJEFT01 00 25 .01 .00 .12 568
VLF0010 TESTVLF IKJEFT01 00 59 .02 .00 .07 946
VLF0100 TESTVLF IKJEFT01 00 419 .09 .00 .24 5371
VLF1000 TESTVLF IKJEFT01 00 4028 .80 .03 2.15 50489
So, significant difference.
BUT, WHO DOES THIS? My conclusion is this is not a player for real REXX
applications that use real REXX subroutines and functions.
My two cents. Maybe I need to be educated... or go on vacation... I'm
actually gone for the next 3 weeks on vacation - one of the reasons I had
time to phutz with this stuff... Short timer attitude...
Rob
-----Original Message-----
From: Pinnacle [mailto:pinn...@rochester.rr.com]
Sent: Wednesday, April 18, 2012 12:07 PM
To: TSO REXX Discussion List
Subject: Re: Distinguishing REXX and CLIST
Paul Gilmartin
Apr 18, 2012, 6:11:16 PM4/18/12
to
On 2012-04-18 13:07, Pinnacle wrote:
> I must respectfully disagree with my good friend, the distinguished
> gentleman from the great state of Arizona. Putting your Rexx execs into
> SYSPROC (or into library concatenated by ALTLIB APPL CLIST) enables them
> to be compressed and cached by VLF, whereas placing them in SYSEXEC
> disqualifies them from such treatment. That's why I always put my Rexx
> execs in SYSPROC, or ALTLIB them. Also be sure to specify the library
> name in the COFVLFxx member IKJEXEC class.
>
I believe this is the cause of the phenomenon that <TAB> ('05'x)
> I must respectfully disagree with my good friend, the distinguished
> gentleman from the great state of Arizona. Putting your Rexx execs into
> SYSPROC (or into library concatenated by ALTLIB APPL CLIST) enables them
> to be compressed and cached by VLF, whereas placing them in SYSEXEC
> disqualifies them from such treatment. That's why I always put my Rexx
> execs in SYSPROC, or ALTLIB them. Also be sure to specify the library
> name in the COFVLFxx member IKJEXEC class.
>
characters behave as harmless whitespace if an EXEC is loaded from
SYSPROC but cause Invalid Character errors if the same EXEC is
loaded from SYSEXEC.
I believe compression is not performed if the EXEC contains a
SOURCELINE() reference. (But I can confuse it with EVAL.)
How persistent is the caching? Does it optimize repeated
invocations of an EXEC in a tight loop?
Is there any environmental query (akin to PARSE SOURCE or SYSVAR)
by which an EXEC can determine whether it was fetched from cache?
Are files loaded from UNIX (USS) directories cached?
-- gil
John McKown
Apr 18, 2012, 8:20:00 PM4/18/12
to
A bit off-topic, because it is about REXX under UNIX. But for a UNIX
REXX script, you must have the word REXX (or lower case rexx) on the
first line in a standard comment.
Why care? Because it is good to have one way to write a REXX script
whether it is run via IRXJCL, TSO TMP, or UNIX shell. There's less
confusion. At least for this poor old man.
--
John McKown
Maranatha! <><
REXX script, you must have the word REXX (or lower case rexx) on the
first line in a standard comment.
Why care? Because it is good to have one way to write a REXX script
whether it is run via IRXJCL, TSO TMP, or UNIX shell. There's less
confusion. At least for this poor old man.
John McKown
Maranatha! <><
John McKown
Apr 18, 2012, 8:25:16 PM4/18/12
to
On Wed, 2012-04-18 at 16:08 -0600, Paul Gilmartin wrote:
<snip>
However, z/OS UNIX does the normal in-memory buffering of blocks from
the filesystems. At least as best as I can tell.
>
> -- gil
--
John McKown
Maranatha! <><
<snip>
> Are files loaded from UNIX (USS) directories cached?
I'm not totally sure, but I'd bet that they are not cached in VLF.
However, z/OS UNIX does the normal in-memory buffering of blocks from
the filesystems. At least as best as I can tell.
>
> -- gil
--
John McKown
Maranatha! <><
Paul Gilmartin
Apr 18, 2012, 8:43:48 PM4/18/12
to
On 2012-04-18 18:19, John McKown wrote:
> A bit off-topic, because it is about REXX under UNIX. But for a UNIX
> REXX script, you must have the word REXX (or lower case rexx) on the
> first line in a standard comment.
>
(or mixed case.)
> A bit off-topic, because it is about REXX under UNIX. But for a UNIX
> REXX script, you must have the word REXX (or lower case rexx) on the
> first line in a standard comment.
>
>
> Why care? Because it is good to have one way to write a REXX script
> whether it is run via IRXJCL, TSO TMP, or UNIX shell. There's less
> confusion. At least for this poor old man.
>
code your EXECs to fail under IRXJCL, UNIX shell, API, or any context
other than TSO TMP. And Rob wouldn't care.
As I mentioned before, USS requires that the "/*" appear in
columns 1-2. I discovered this contending with an EXEC
whose author had indented everything by 1 column, perhaps
to avoid problems with "/*" in SYSIN.
The behavior is bizarre; it fails with
BPXW0000I Exec not found
Apparently one layer recognized it as a Rexx "Exec";a
deeper layer failed it. Go figger. PMR submitted,
years ago. WAD.
-- gil
Paul Gilmartin
Apr 19, 2012, 1:55:40 AM4/19/12
to
On Apr 18, 2012, at 18:24, John McKown wrote:
> On Wed, 2012-04-18 at 16:08 -0600, Paul Gilmartin wrote:
> <snip>
>> Are files loaded from UNIX (USS) directories cached?
>
> I'm not totally sure, but I'd bet that they are not cached in VLF.
> However, z/OS UNIX does the normal in-memory buffering of blocks from
> the filesystems. At least as best as I can tell.
>
I've tried various combinations of SYSPROC, SYSEXEC, and UNIX
> On Wed, 2012-04-18 at 16:08 -0600, Paul Gilmartin wrote:
> <snip>
>> Are files loaded from UNIX (USS) directories cached?
>
> I'm not totally sure, but I'd bet that they are not cached in VLF.
> However, z/OS UNIX does the normal in-memory buffering of blocks from
> the filesystems. At least as best as I can tell.
>
directories containing a trivial EXEC called 1000 times with
address MVS. The astonishing results:
13.7 seconds - Running under UNIX shell; called script in UNIX directory
in PATH
1.9 seconds - under TSO; called EXEC in UNIX directory in SYSEXEC
concatenation.
25.3 seconds - Under TSO; called EXEC in PDS in SYSPROC concatenation.
All elapsed times. To be fair, my SYSPROC concatenation contains
SPFCLIB and SPFEXEC, but _after_ my small PDS containing my test
EXEC, so results shouldn't be dominated by SYSPROC directory
searches. Is SYSEXEC searched before SYSPROC? It's pretty hard
to control all the variables.
The test EXECs:
user@MVS:165$ head REXXRC CACHING
==> REXXRC <==
/* Rexx */ return( arg( 1 ) )
==> CACHING <==
/* Rexx */ signal on novalue; /*
Doc: test effectiveness of caching.
*/
trace N
parse source SSS; say SSS
T0 = time( 'E' )
do I = 1 to 1000
address MVS 'REXXRC' right( I, 2 ); end
say time( 'E' ) - T0
-- gil
Höglund Lars
Apr 19, 2012, 4:21:47 AM4/19/12
to
EXECUTIL
-----Ursprungligt meddelande-----
Från: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] För Adrian Stern
Skickat: den 19 april 2012 10:19
Till: TSO-...@VM.MARIST.EDU
Ämne: Re: [TSO-REXX] Distinguishing REXX and CLIST
There's a setting for the system to make it search sysexec first - there's also a local one for the user's own tso - can't remember the name though.
It's very likely it searched sysexec first before looking in sysproc. Once again the system cache can matter in that the pages required for the locate were in the cache at the time - and the block size also affects the speed together with channel contention - unless you're giving us cpu time
-----Ursprungligt meddelande-----
Från: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] För Adrian Stern
Skickat: den 19 april 2012 10:19
Till: TSO-...@VM.MARIST.EDU
Ämne: Re: [TSO-REXX] Distinguishing REXX and CLIST
There's a setting for the system to make it search sysexec first - there's also a local one for the user's own tso - can't remember the name though.
It's very likely it searched sysexec first before looking in sysproc. Once again the system cache can matter in that the pages required for the locate were in the cache at the time - and the block size also affects the speed together with channel contention - unless you're giving us cpu time
0 new messages