Re: OMVS - comparing directories for differences

[Bruce Hewson]

My thanks to all who responded, but especially to Bill Schoen for the fscp exec.

Although not being permitted to access guthub from office directly, I was able 
to get a copy of the exec.

I am testing now.

As to original reason, looking at merging the new IBM z/OS  supplied UNIX 
configuration into the existing environment programmatically.

Regards
Bruce Hewson

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OMVS - comparing directories for differences

[Paul Gilmartin]

On Wed, 29 Sep 2021 19:47:59 -0400, James Crudele wrote:

>You can try this:
>
>//LISTDIR  EXEC PGM=IKJEFT01,   
>//  PARM='HFSDIRC / /SERVICE'   
>//* 
>//SYSPROC  DD   DISP=SHR,DSN=SYS1.SBPXEXEC  
>// DD   DISP=SHR,DSN=userid.TEST.REXX  
>//SYSTSPRT DD   SYSOUT=*
>//SYSTSIN  DD   DUMMY   
>//* 
>//*  
>
>Then do some data manipulation. I sort with file manager. 
>
The "du" command is inadequate for what the OP requested.  It gives only
a rough estimate (in blocks) of the total size of the files within a directory.
Thee content can have equal size but differ radically.

HFSDIRC may have served some purpose when iit was written; it's
irrelevant here.

Why do you continue to embellish a travesty when a thorough solution
had been posted hours earlier?  (It's long; I haven't reviewed  it, but
its author has long ago earned my trust.)


>> On Sep 29, 2021, at 16:21, Paul Gilmartin wrote:
>> 
>> On Wed, 29 Sep 2021 15:47:42 -0400, James Crudele wrote:
>> 
>>> /* Rexx HFSDIRC */ 
>>> parse arg dir1 dir2 junk   
>>> dir1  = strip(dir1)
>>> dir2  = strip(dir2)
>>> if dir1 = "" or dir2 = "" then do  
>>>  say "Two directories must be specified" 
>>>  exit 4  
>>> end
>>> "oshell du "dir1" > /tmp/lsdir1"   
>>> "oshell du "dir2" > /tmp/lsdir2"   
>>> "oget '/tmp/lsdir1' 'userid.DIR1'" 
>>> "oget '/tmp/lsdir2' 'userid.DIR2'" 
>>> 
>> Where do you do the compare?
>> 
>> "du" reports only the total number of blocks in each directory.
>> I suspect the OP wanted greater precision.
>> 
>> What if the directories have non-portable names?
>> 
>> This would be more legible with less typing if you omit the TSO commands
>> and run an OMVS exec.
>> 
> On Sep 28, 2021, at 22:22, Bruce Hewson wrote:
 ...
 We are looking for a way to compare 2 filesystem structures, starting at 
 root '/'.
...

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Seymour J Metz]

Or use ALTLIB.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Skip Robinson [jo.skip.robin...@gmail.com]
Sent: Wednesday, September 29, 2021 6:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

I forgot a point I meant to make in this reply. We discussed how to run
CLIST or REXX directly from a source PDS without benefit of SYSPROC or
SYSEXEC. There are several products in a z/OS configuration that are
delivered by the vendor with a self contained package of execs. One of
these is called to start the function. The problem is that the package is
often delivered in an SMP/E target library. This library varies from
release to release and may require running different versions at different
times, Putting this package in either SYSPROC or SYSEXEC for public usage
is both a short and long term management problem. Examples are RACF, SMP/E,
IPCS, and others.

The simplest solution is to create an 'init exec' whose name is fixed and
can be placed in the installation-wide exec library. The code in the iniit
routine can be edited to support varying product levels. It also
concatenates the specific verstion libraries under SYSPROC or SYSEXEC as
appropriate for daily use.

On Wed, Sep 29, 2021 at 3:06 PM Skip Robinson 
wrote:

> Not sure we got here from 'PLI', but so be it. I was deeply embedded in
> CLIST writing by the time REXX made its way to TSO/E. Here are a few points
> I haven't seen from others.
>
> -- CLIST was modeled or at least inspired by the TSO command processor.
> That's the framework that handles most 'native' TSO commands. Very few
> customers these days write or even modify TSO commands. The framework is
> well documented and supported by a host of macros and load modules. It's
> very powerful but very complicated for someone who doesn't do it regularly.
>
> -- Because of this historical connection, one of the most powerful
> features of CLIST is the mechanism by which parameters/options are passed
> by the user: positional or keyword, required or optional, with system
> prompting. I once saw a REXX routine that simulated the old command/CLIST
> parm processing. It was very complicated and hardly worth the trouble
> IMHO.
>
>
>
> On Wed, Sep 29, 2021 at 2:07 PM Charles Mills  wrote:
>
>> That's why we get the big bucks.
>>
>> Charles
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Paul Gilmartin
>> Sent: Wednesday, September 29, 2021 11:01 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: PL/I vs. JCL
>>
>> On Wed, 29 Sep 2021 10:48:53 -0700, Skip Robinson wrote:
>>
>> >Is that operand required?
>> >
>> Only sometimes.  IBM made it as complicated as possible:
>>
>>
>>
>
> --
>
> Skip Robinson
> 323-715-0595
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: EXTERNAL EMAIL: Re: zPDT Learner's Edition

[Seymour J Metz]

> be limited by an 80 column wide editing session

That hasn't been the case for four decades. I was editing on 132-wide and 
160-wide screens long before z/OS existed.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Frenzel [david.fren...@t-systems.com]
Sent: Wednesday, September 29, 2021 5:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: EXTERNAL EMAIL: Re: zPDT Learner's Edition

It took some days for me to put some thought into this pricing aspect. From a 
guy who is fascinated with the entire Z platform and all the things there to 
discover I am totally going to get the license. As long as IBM decides to make 
it available in Germany, of course.

Now, if I put myself 5 years back when I didn't even know the Mainframe existed 
and someone would have told me to pay $120 to be allowed to install an 
operating system I had never heard of on my computer to work on a weird looking 
screen, be limited by an 80 column wide editing session and that it is very 
difficult to set up a connection with a graphical editor.. I am having a really 
hard time to believe I would have said yes to buying it. (I am being a bit 
ironic here.)

Perhaps for everyone who is part of this group it's a different story. I am 
just doubting that this so called "Learner's Edition" will actually attract new 
people (learner?) to the platform. Maybe this is just a move to lower the 
numbers of not-so-legal installations of z/OS on an emulator and controlling 
it. As a newbie I would not be sold and probably move on with all the other 
technologies I can use free of charge and that are still fun. I understand that 
it won't just be free. For university students, however, it should be free of 
charge. For instance, check out the GitHub Student Developer Pack 
https://secure-web.cisco.com/1elqzK885eXCjK0lvCxHqOJeXiOVMDUNV_GIFcZyH8X0auoPEDhozGAf1SnN33DBN6xnl-isUUuB24BUcHMvrFn8F8oAR8vQ1fxTQrjS24mxiUhxpHnffug0jpFruWkd0TNC_92xG8Ol6facMtJiSFd3BtRrzdRXZbFjT9zQXAzr9ybytA8xCEMfUts7H2OztptvMMvqZQ4V9qx3tQs5eMBFbClzjlvZ5VhafxS42WcezVPMrKA7lfdrsVqVMBcYNnh3O4nwsg8vbaFwnw4nOyQaAluHTPPaAanGy0i12kSmQ2Y56U3VVrgfa4hLLtnkXimBg0GukhMcX_nK-LJmA4g3dExxC-fdJ4x9DCY2HMN6fK3UgWX4pH9Dm1F5UdZ0nDYf7ODpdvsBJNLtjKYixIVoF7EKbFcPmoFuvyHLfGEk4vgTr7U4gL_ThBaQM4iJ0/https%3A%2F%2Feducation.github.com%2Fpack.
 So much free stuff.
Put zPDT in there and I bet some folks will dig into it and maybe some day end 
up in this mailing list.

Cheers - David

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List  Im Auftrag von 
Jerry Whitteridge
Gesendet: Freitag, 24. September 2021 18:03
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: EXTERNAL EMAIL: Re: zPDT Learner's Edition

Agreed - $120 is something affordable by most, and I'm really excited to see 
this coming out

Jerry Whitteridge
jerry.whitteri...@albertsons.com
Manager Mainframe Systems & HP Non-Stop
Albertsons Companies

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Grant Taylor
Sent: Friday, September 24, 2021 8:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL EMAIL: Re: zPDT Learner's Edition

On 9/24/21 9:41 AM, Tom Brennan wrote:
> Like Ray, for years I've been advocating something free or nearly free
> with every IBM manager I happen to see.  No effect so far.  If this
> works it could be a big change for future education.

I feel like $120 / year is well within the reach of any student or hobbyist 
that wants to learn.  It's *SIGNIFICANTLY* more approachable than the $5k entry 
point for other options for professionals from IBM.

It seems as if the announcement on IBM's site may have been slightly premature 
(O(weeks)) as it has purportedly been withdrawn and someone else in the 
community has said that it should be available in mid October.

I'm very much looking forward to seeing how this rolls out.  I love the idea of 
having an IBM supported way to run contemporary z/OS along side my well 
seasoned P/390-E.  :-)



--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN 

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.

Re: OMVS - comparing directories for differences

[James Crudele]

You can try this:

//LISTDIR  EXEC PGM=IKJEFT01,   
//  PARM='HFSDIRC / /SERVICE'   
//* 
//SYSPROC  DD   DISP=SHR,DSN=SYS1.SBPXEXEC  
// DD   DISP=SHR,DSN=userid.TEST.REXX  
//SYSTSPRT DD   SYSOUT=*
//SYSTSIN  DD   DUMMY   
//* 
//*  

Then do some data manipulation. I sort with file manager. 

> On Sep 29, 2021, at 16:21, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Wed, 29 Sep 2021 15:47:42 -0400, James Crudele wrote:
> 
>> /* Rexx HFSDIRC */ 
>> parse arg dir1 dir2 junk   
>> dir1  = strip(dir1)
>> dir2  = strip(dir2)
>> if dir1 = "" or dir2 = "" then do  
>>  say "Two directories must be specified" 
>>  exit 4  
>> end
>> "oshell du "dir1" > /tmp/lsdir1"   
>> "oshell du "dir2" > /tmp/lsdir2"   
>> "oget '/tmp/lsdir1' 'userid.DIR1'" 
>> "oget '/tmp/lsdir2' 'userid.DIR2'" 
>> 
> Where do you do the compare?
> 
> "du" reports only the total number of blocks in each directory.
> I suspect the OP wanted greater precision.
> 
> What if the directories have non-portable names?
> 
> This would be more legible with less typing if you omit the TSO commands
> and run an OMVS exec.
> 
 On Sep 28, 2021, at 22:22, Bruce Hewson wrote:
>>> ...
>>> We are looking for a way to compare 2 filesystem structures, starting at 
>>> root '/'.
>>>...
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Seymour J Metz]

No:

If you know that the procedure being run is a CLIST, you can code
the CLIST operand. If you know that the procedure being run is a
REXX exec, you can code the EXEC operand. If you do not code the
CLIST or EXEC operand on the EXEC command, the EXEC command
processor examines line 1 of the procedure for the characters
"REXX" within a comment. (The characters "REXX" can be in
uppercase, lowercase, or mixed-case.) This is known as the REXX
exec identifier.  If the EXEC command finds the REXX exec
identifier, the EXEC command runs the procedure as a REXX exec.
Otherwise, it runs the procedure as a CLIST.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Skip Robinson [jo.skip.robin...@gmail.com]
Sent: Wednesday, September 29, 2021 1:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

Is that operand required?

On Wed, Sep 29, 2021 at 10:12 AM Seymour J Metz  wrote:

> By directly, do you  mean explicit use of EXEC? There's an operand to
> distinguish CLIST from REXX.
>
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Skip Robinson 
> Sent: Wednesday, September 29, 2021 12:42 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I vs. JCL
>
> How about invoking a module directly? No SYSPROC is involved here.
>
> EX 'dsn(member)'
>
> I have no way to test it at the moment.
>
> On Wed, Sep 29, 2021 at 7:22 AM Seymour J Metz  wrote:
>
> > TSO SYSPROC is the only case I know of where /* REXX */ is required.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> > of Phil Smith III [li...@akphs.com]
> > Sent: Wednesday, September 29, 2021 10:06 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: PL/I vs. JCL
> >
> > Bob Bridges wrote:
> >
> > >Purely by the way, but I've never really understood why so many REXX
> > modules I see start like this:
> >
> > >  /* REXX */
> >
> > 
> >
> >
> >
> > I think (a) it's documented that way in some places; (b) Some
> environments
> > may even require that; (c) that's how some/many examples have it; and (d)
> > it's bizarre, because these all work in TSO:
> >
> > /* Rexx */
> > /* This rexx program. */
> >
> > /* This is (rexx) */
> >
> > /* This is not(rexx)s */
> >
> > /* Thisisrexxyep */
> >
> > but
> >
> > /* This is a program */
> >
> > does not. So something is parsing the entire first line, looking for the
> > leading "/*" and four letters "rexx" in a row, case-insensitive. Bizarre.
> >
> >
> >
> > Having grown up in VM, I'd never even thought about it, other than
> knowing
> > that I needed the word "rexx" in the first line in TSO. (On VM, just the
> > leading "/*" is sufficient.)
> >
> > --
>
> Skip Robinson
> 323-715-0595
>
>
--

Skip Robinson
323-715-0595

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Seymour J Metz]

No; if you code an explicit DSN then SYSPROC and SYSEXEC are irrelevant. It's 
only whn you code *(member) that EXEC looks in the SYSPROC and SYSEXEC 
concatenations[*]. Also, EXEC doesn't look for DD statements, it looks at the 
current state of the session, which could have been modified by ALTLIB or 
dynamic allocation.

[*] Subject to any active ALTLIB.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of CM 
Poncelet [ponce...@bcs.org.uk]
Sent: Wednesday, September 29, 2021 3:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

An EX 'dsn(member)' would require no /* REXX */ card if 'dsn' is
allocated to DDNAME=SYSEXEC in the user's TSO logon PROC, but would
require it if is allocated to DDNAME=SYSPROC in ditto.

The OS first checks whether a SYSEXEC DD is coded and, if yes, whether
the '(member)' is in it - and, if not, it then checks for a SYSPROC DD
etc. and any REXX '(member)' in it must then have a /* REXX */ card at
its 'top' to indicate that it is a REXX exec and not a CLIST.

On 29/09/2021 17:42, Skip Robinson wrote:
> How about invoking a module directly? No SYSPROC is involved here.
>
> EX 'dsn(member)'
>
> I have no way to test it at the moment.
>
> On Wed, Sep 29, 2021 at 7:22 AM Seymour J Metz  wrote:
>
>> TSO SYSPROC is the only case I know of where /* REXX */ is required.
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>> 
>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
>> of Phil Smith III [li...@akphs.com]
>> Sent: Wednesday, September 29, 2021 10:06 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: PL/I vs. JCL
>>
>> Bob Bridges wrote:
>>
>>> Purely by the way, but I've never really understood why so many REXX
>> modules I see start like this:
>>
>>>  /* REXX */
>> 
>>
>>
>>
>> I think (a) it's documented that way in some places; (b) Some environments
>> may even require that; (c) that's how some/many examples have it; and (d)
>> it's bizarre, because these all work in TSO:
>>
>> /* Rexx */
>> /* This rexx program. */
>>
>> /* This is (rexx) */
>>
>> /* This is not(rexx)s */
>>
>> /* Thisisrexxyep */
>>
>> but
>>
>> /* This is a program */
>>
>> does not. So something is parsing the entire first line, looking for the
>> leading "/*" and four letters "rexx" in a row, case-insensitive. Bizarre.
>>
>>
>>
>> Having grown up in VM, I'd never even thought about it, other than knowing
>> that I needed the word "rexx" in the first line in TSO. (On VM, just the
>> leading "/*" is sufficient.)
>>
>> --
> Skip Robinson
> 323-715-0595
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Seymour J Metz]

There are many TSO command processors. The CLIST operand parsing is a small 
subset of what a command processor can do using IKJPARSE.

I'm not sure what you mean by "framework" in this context, but the macros to 
define the command syntax are not rocket science.

I wish that IBM had included something like XPROC in TSO/E.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Skip Robinson [jo.skip.robin...@gmail.com]
Sent: Wednesday, September 29, 2021 6:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

Not sure we got here from 'PLI', but so be it. I was deeply embedded in
CLIST writing by the time REXX made its way to TSO/E. Here are a few points
I haven't seen from others.

-- CLIST was modeled or at least inspired by the TSO command processor.
That's the framework that handles most 'native' TSO commands. Very few
customers these days write or even modify TSO commands. The framework is
well documented and supported by a host of macros and load modules. It's
very powerful but very complicated for someone who doesn't do it regularly.

-- Because of this historical connection, one of the most powerful features
of CLIST is the mechanism by which parameters/options are passed by the
user: positional or keyword, required or optional, with system prompting. I
once saw a REXX routine that simulated the old command/CLIST parm
processing. It was very complicated and hardly worth the trouble IMHO.



On Wed, Sep 29, 2021 at 2:07 PM Charles Mills  wrote:

> That's why we get the big bucks.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Wednesday, September 29, 2021 11:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I vs. JCL
>
> On Wed, 29 Sep 2021 10:48:53 -0700, Skip Robinson wrote:
>
> >Is that operand required?
> >
> Only sometimes.  IBM made it as complicated as possible:
>
>
>

--

Skip Robinson
323-715-0595

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OMVS - comparing directories for differences

[Lennie Dymoke-Bradshaw]

Is it possible to use "or" as an inclusive or operator? 
My TSO/E REXX Reference document says I have to use the "|" as an inclusive or 
operator.

Lennie Dymoke-Bradshaw
https://rsclweb.com 
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
James Crudele
Sent: 29 September 2021 20:48
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: OMVS - comparing directories for differences

/* Rexx HFSDIRC */ 
parse arg dir1 dir2 junk   
dir1  = strip(dir1)
dir2  = strip(dir2)
if dir1 = "" or dir2 = "" then do  
   say "Two directories must be specified" 
   exit 4  
end
"oshell du "dir1" > /tmp/lsdir1"   
"oshell du "dir2" > /tmp/lsdir2"   
"oget '/tmp/lsdir1' 'userid.DIR1'" 
"oget '/tmp/lsdir2' 'userid.DIR2'" 

> On Sep 28, 2021, at 22:22, Bruce Hewson  wrote:
> 
> Hello all,
> 
> an OMVS question.
> 
> We are looking for a way to compare 2 filesystem structures, starting at root 
> '/'.
> 
> Differences we want to identify:-
> 
> 1.  directory
> 2. file
> 3. symlink
> 
> It is the last we are having trouble working out how to go about it.
> 
> Hoping someone has done this before.
> 
> Regards
> Bruce Hewson
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Seymour J Metz]

> I believe that if a CLIST begins withh a /* Rexx */ comment but that "operand"
> is omitted it will execute as a CLIST regardless.

No: it examines the first line.

> OMVS is worse.  If an EXEC is spawned with a fully-qualified path, spawn
> invokes the Rexx interpreter passing it the filename but not the path.
> The interpreter searches for that name in directories in the PATH environment
> variable.

Ouch! Is that bug documented (BAD)?



--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, September 29, 2021 1:51 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

On Wed, 29 Sep 2021 17:11:50 +, Seymour J Metz wrote:

>By directly, do you  mean explicit use of EXEC? There's an operand to 
>distinguish CLIST from REXX.
>
I believe that if a CLIST begins withh a /* Rexx */ comment but that "operand"
is omitted it will execute as a CLIST regardless.

OMVS is worse.  If an EXEC is spawned with a fully-qualified path, spawn
invokes the Rexx interpreter passing it the filename but not the path.
The interpreter searches for that name in directories in the PATH environment
variable.  If not found, it fails with a message.  If a different instance with
the same name is found it interprets that rather than the one in the specified
path.

IBM does not consider this a problem.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Skip Robinson]

I forgot a point I meant to make in this reply. We discussed how to run
CLIST or REXX directly from a source PDS without benefit of SYSPROC or
SYSEXEC. There are several products in a z/OS configuration that are
delivered by the vendor with a self contained package of execs. One of
these is called to start the function. The problem is that the package is
often delivered in an SMP/E target library. This library varies from
release to release and may require running different versions at different
times, Putting this package in either SYSPROC or SYSEXEC for public usage
is both a short and long term management problem. Examples are RACF, SMP/E,
IPCS, and others.

The simplest solution is to create an 'init exec' whose name is fixed and
can be placed in the installation-wide exec library. The code in the iniit
routine can be edited to support varying product levels. It also
concatenates the specific verstion libraries under SYSPROC or SYSEXEC as
appropriate for daily use.

On Wed, Sep 29, 2021 at 3:06 PM Skip Robinson 
wrote:

> Not sure we got here from 'PLI', but so be it. I was deeply embedded in
> CLIST writing by the time REXX made its way to TSO/E. Here are a few points
> I haven't seen from others.
>
> -- CLIST was modeled or at least inspired by the TSO command processor.
> That's the framework that handles most 'native' TSO commands. Very few
> customers these days write or even modify TSO commands. The framework is
> well documented and supported by a host of macros and load modules. It's
> very powerful but very complicated for someone who doesn't do it regularly.
>
> -- Because of this historical connection, one of the most powerful
> features of CLIST is the mechanism by which parameters/options are passed
> by the user: positional or keyword, required or optional, with system
> prompting. I once saw a REXX routine that simulated the old command/CLIST
> parm processing. It was very complicated and hardly worth the trouble
> IMHO.
>
>
>
> On Wed, Sep 29, 2021 at 2:07 PM Charles Mills  wrote:
>
>> That's why we get the big bucks.
>>
>> Charles
>>
>>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Paul Gilmartin
>> Sent: Wednesday, September 29, 2021 11:01 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: PL/I vs. JCL
>>
>> On Wed, 29 Sep 2021 10:48:53 -0700, Skip Robinson wrote:
>>
>> >Is that operand required?
>> >
>> Only sometimes.  IBM made it as complicated as possible:
>>
>>
>>
>
> --
>
> Skip Robinson
> 323-715-0595
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Skip Robinson]

Not sure we got here from 'PLI', but so be it. I was deeply embedded in
CLIST writing by the time REXX made its way to TSO/E. Here are a few points
I haven't seen from others.

-- CLIST was modeled or at least inspired by the TSO command processor.
That's the framework that handles most 'native' TSO commands. Very few
customers these days write or even modify TSO commands. The framework is
well documented and supported by a host of macros and load modules. It's
very powerful but very complicated for someone who doesn't do it regularly.

-- Because of this historical connection, one of the most powerful features
of CLIST is the mechanism by which parameters/options are passed by the
user: positional or keyword, required or optional, with system prompting. I
once saw a REXX routine that simulated the old command/CLIST parm
processing. It was very complicated and hardly worth the trouble IMHO.



On Wed, Sep 29, 2021 at 2:07 PM Charles Mills  wrote:

> That's why we get the big bucks.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Wednesday, September 29, 2021 11:01 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I vs. JCL
>
> On Wed, 29 Sep 2021 10:48:53 -0700, Skip Robinson wrote:
>
> >Is that operand required?
> >
> Only sometimes.  IBM made it as complicated as possible:
>
>
>

-- 

Skip Robinson
323-715-0595

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

AW: EXTERNAL EMAIL: Re: zPDT Learner's Edition

[David Frenzel]

It took some days for me to put some thought into this pricing aspect. From a 
guy who is fascinated with the entire Z platform and all the things there to 
discover I am totally going to get the license. As long as IBM decides to make 
it available in Germany, of course.

Now, if I put myself 5 years back when I didn't even know the Mainframe existed 
and someone would have told me to pay $120 to be allowed to install an 
operating system I had never heard of on my computer to work on a weird looking 
screen, be limited by an 80 column wide editing session and that it is very 
difficult to set up a connection with a graphical editor.. I am having a really 
hard time to believe I would have said yes to buying it. (I am being a bit 
ironic here.)

Perhaps for everyone who is part of this group it's a different story. I am 
just doubting that this so called "Learner's Edition" will actually attract new 
people (learner?) to the platform. Maybe this is just a move to lower the 
numbers of not-so-legal installations of z/OS on an emulator and controlling 
it. As a newbie I would not be sold and probably move on with all the other 
technologies I can use free of charge and that are still fun. I understand that 
it won't just be free. For university students, however, it should be free of 
charge. For instance, check out the GitHub Student Developer Pack 
https://education.github.com/pack. So much free stuff.
Put zPDT in there and I bet some folks will dig into it and maybe some day end 
up in this mailing list.

Cheers - David

-Ursprüngliche Nachricht-
Von: IBM Mainframe Discussion List  Im Auftrag von 
Jerry Whitteridge
Gesendet: Freitag, 24. September 2021 18:03
An: IBM-MAIN@LISTSERV.UA.EDU
Betreff: Re: EXTERNAL EMAIL: Re: zPDT Learner's Edition

Agreed - $120 is something affordable by most, and I'm really excited to see 
this coming out

Jerry Whitteridge
jerry.whitteri...@albertsons.com
Manager Mainframe Systems & HP Non-Stop
Albertsons Companies

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Grant Taylor
Sent: Friday, September 24, 2021 8:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL EMAIL: Re: zPDT Learner's Edition

On 9/24/21 9:41 AM, Tom Brennan wrote:
> Like Ray, for years I've been advocating something free or nearly free 
> with every IBM manager I happen to see.  No effect so far.  If this 
> works it could be a big change for future education.

I feel like $120 / year is well within the reach of any student or hobbyist 
that wants to learn.  It's *SIGNIFICANTLY* more approachable than the $5k entry 
point for other options for professionals from IBM.

It seems as if the announcement on IBM's site may have been slightly premature 
(O(weeks)) as it has purportedly been withdrawn and someone else in the 
community has said that it should be available in mid October.

I'm very much looking forward to seeing how this rolls out.  I love the idea of 
having an IBM supported way to run contemporary z/OS along side my well 
seasoned P/390-E.  :-)



--
Grant. . . .
unix || die

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN 

 Warning: All e-mail sent to this address will be received by the corporate 
e-mail system, and is subject to archival and review by someone other than the 
recipient. This e-mail may contain proprietary information and is intended only 
for the use of the intended recipient(s). If the reader of this message is not 
the intended recipient(s), you are notified that you have received this message 
in error and that any review, dissemination, distribution or copying of this 
message is strictly prohibited. If you have received this message in error, 
please notify the sender immediately.


--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OMVS - comparing directories for differences

[James Crudele]

I run this in batch and use superc to compare the two inputs. 

> On Sep 29, 2021, at 16:21, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Wed, 29 Sep 2021 15:47:42 -0400, James Crudele wrote:
> 
>> /* Rexx HFSDIRC */ 
>> parse arg dir1 dir2 junk   
>> dir1  = strip(dir1)
>> dir2  = strip(dir2)
>> if dir1 = "" or dir2 = "" then do  
>>  say "Two directories must be specified" 
>>  exit 4  
>> end
>> "oshell du "dir1" > /tmp/lsdir1"   
>> "oshell du "dir2" > /tmp/lsdir2"   
>> "oget '/tmp/lsdir1' 'userid.DIR1'" 
>> "oget '/tmp/lsdir2' 'userid.DIR2'" 
>> 
> Where do you do the compare?
> 
> "du" reports only the total number of blocks in each directory.
> I suspect the OP wanted greater precision.
> 
> What if the directories have non-portable names?
> 
> This would be more legible with less typing if you omit the TSO commands
> and run an OMVS exec.
> 
 On Sep 28, 2021, at 22:22, Bruce Hewson wrote:
>>> ...
>>> We are looking for a way to compare 2 filesystem structures, starting at 
>>> root '/'.
>>>...
> 
> -- gil
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Charles Mills]

That's why we get the big bucks.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Wednesday, September 29, 2021 11:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

On Wed, 29 Sep 2021 10:48:53 -0700, Skip Robinson wrote:

>Is that operand required?
> 
Only sometimes.  IBM made it as complicated as possible:

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Bob Bridges]

Hm, not a bad point, Andrew.  I should maybe keep it in mind when I write for 
others, or when something I write for myself may eventually get into the public 
domain.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Why don't our civics courses teach pupils what the word "usurped" means?  Is 
this a concept that government thinks we can do without?  -Joseph Sobran */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Andrew Rowley
Sent: Tuesday, September 28, 2021 21:07

I guess the first looks like a statement with a purpose, the second looks like 
a comment that can be freely edited e.g.

/* This program converts...

Things may not be as obvious to newcomers as they are to those with more 
experience.

--- On 29/09/2021 6:54 am, Bob Bridges wrote:
> Purely by the way, but I've never really understood why so many REXX modules 
> I see start like this:
>
>/* REXX */
>/* Module: Name
>   Author: Bob Bridges the Magnificent
>   Purpose: Convert ANSI dates to internal format, or whatever. */
>
> ...instead of something like this:
>
>/* This REXX converts ANSI dates to internal format, or whatever. */
>/* Module: Name
>   Author: Bob Bridges the Magnificent */

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OMVS - comparing directories for differences

[Paul Gilmartin]

On Wed, 29 Sep 2021 15:47:42 -0400, James Crudele wrote:

>/* Rexx HFSDIRC */ 
>parse arg dir1 dir2 junk   
>dir1  = strip(dir1)
>dir2  = strip(dir2)
>if dir1 = "" or dir2 = "" then do  
>   say "Two directories must be specified" 
>   exit 4  
>end
>"oshell du "dir1" > /tmp/lsdir1"   
>"oshell du "dir2" > /tmp/lsdir2"   
>"oget '/tmp/lsdir1' 'userid.DIR1'" 
>"oget '/tmp/lsdir2' 'userid.DIR2'" 
> 
Where do you do the compare?

"du" reports only the total number of blocks in each directory.
I suspect the OP wanted greater precision.

What if the directories have non-portable names?

This would be more legible with less typing if you omit the TSO commands
and run an OMVS exec.

>> On Sep 28, 2021, at 22:22, Bruce Hewson wrote:
>> ...
>> We are looking for a way to compare 2 filesystem structures, starting at 
>> root '/'.
>> ...

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OMVS - comparing directories for differences

[James Crudele]

/* Rexx HFSDIRC */ 
parse arg dir1 dir2 junk   
dir1  = strip(dir1)
dir2  = strip(dir2)
if dir1 = "" or dir2 = "" then do  
   say "Two directories must be specified" 
   exit 4  
end
"oshell du "dir1" > /tmp/lsdir1"   
"oshell du "dir2" > /tmp/lsdir2"   
"oget '/tmp/lsdir1' 'userid.DIR1'" 
"oget '/tmp/lsdir2' 'userid.DIR2'" 

> On Sep 28, 2021, at 22:22, Bruce Hewson  wrote:
> 
> Hello all,
> 
> an OMVS question.
> 
> We are looking for a way to compare 2 filesystem structures, starting at root 
> '/'.
> 
> Differences we want to identify:-
> 
> 1.  directory
> 2. file
> 3. symlink
> 
> It is the last we are having trouble working out how to go about it.
> 
> Hoping someone has done this before.
> 
> Regards
> Bruce Hewson
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OMVS - comparing directories for differences

[James Crudele]

I recall a rexx called hfsdirc. Not sure where I found it. I’m sure I can share 
if needed. 

> On Sep 28, 2021, at 22:22, Bruce Hewson  wrote:
> 
> Hello all,
> 
> an OMVS question.
> 
> We are looking for a way to compare 2 filesystem structures, starting at root 
> '/'.
> 
> Differences we want to identify:-
> 
> 1.  directory
> 2. file
> 3. symlink
> 
> It is the last we are having trouble working out how to go about it.
> 
> Hoping someone has done this before.
> 
> Regards
> Bruce Hewson
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[CM Poncelet]

An EX 'dsn(member)' would require no /* REXX */ card if 'dsn' is
allocated to DDNAME=SYSEXEC in the user's TSO logon PROC, but would
require it if is allocated to DDNAME=SYSPROC in ditto. 
 
The OS first checks whether a SYSEXEC DD is coded and, if yes, whether
the '(member)' is in it - and, if not, it then checks for a SYSPROC DD
etc. and any REXX '(member)' in it must then have a /* REXX */ card at
its 'top' to indicate that it is a REXX exec and not a CLIST.

On 29/09/2021 17:42, Skip Robinson wrote:
> How about invoking a module directly? No SYSPROC is involved here.
>
> EX 'dsn(member)'
>
> I have no way to test it at the moment.
>
> On Wed, Sep 29, 2021 at 7:22 AM Seymour J Metz  wrote:
>
>> TSO SYSPROC is the only case I know of where /* REXX */ is required.
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> http://mason.gmu.edu/~smetz3
>>
>> 
>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
>> of Phil Smith III [li...@akphs.com]
>> Sent: Wednesday, September 29, 2021 10:06 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: PL/I vs. JCL
>>
>> Bob Bridges wrote:
>>
>>> Purely by the way, but I've never really understood why so many REXX
>> modules I see start like this:
>>
>>>  /* REXX */
>> 
>>
>>
>>
>> I think (a) it's documented that way in some places; (b) Some environments
>> may even require that; (c) that's how some/many examples have it; and (d)
>> it's bizarre, because these all work in TSO:
>>
>> /* Rexx */
>> /* This rexx program. */
>>
>> /* This is (rexx) */
>>
>> /* This is not(rexx)s */
>>
>> /* Thisisrexxyep */
>>
>> but
>>
>> /* This is a program */
>>
>> does not. So something is parsing the entire first line, looking for the
>> leading "/*" and four letters "rexx" in a row, case-insensitive. Bizarre.
>>
>>
>>
>> Having grown up in VM, I'd never even thought about it, other than knowing
>> that I needed the word "rexx" in the first line in TSO. (On VM, just the
>> leading "/*" is sufficient.)
>>
>> --
> Skip Robinson
> 323-715-0595
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Rupert Reynolds]

>From memory, at the time Rexx first came to TSO/E the documented
requirement was that line 1 must have a /* comment that included "Rexx",
not case sensitive. I'm not sure, but I think line 1 could also contain
code!

I can't imagine why z/OS would be more finicky, unless the z/OS people saw
so many "/* Rexx */" first lines that they thought it was always that way.
Or more efficient, perhaps?

Rupert

On Wed., Sep. 29, 2021, 17:59 Ed Jaffe,  wrote:

> On 9/29/2021 7:22 AM, Seymour J Metz wrote:
> > TSO SYSPROC is the only case I know of where /* REXX */ is required.
>
> In my experience, TSO/E is quite forgiving about the syntax of the first
> line in a REXX. You can say /* REXX is a Great Language */" and it works
> just fine.
>
> However, the z/OS UNIX environment is far less forgiving. I've seen
> failures to recognize a REXX that was accepted by TSO/E.
>
> As a result, I now always ensure a REXX begins with "/* REXX */" and
> nothing else.
>
> --
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Paul Gilmartin]

On Wed, 29 Sep 2021 10:48:53 -0700, Skip Robinson wrote:

>Is that operand required?
> 
Only sometimes.  IBM made it as complicated as possible:



-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Paul Gilmartin]

On Wed, 29 Sep 2021 17:11:50 +, Seymour J Metz wrote:

>By directly, do you  mean explicit use of EXEC? There's an operand to 
>distinguish CLIST from REXX.
>
I believe that if a CLIST begins withh a /* Rexx */ comment but that "operand"
is omitted it will execute as a CLIST regardless.

OMVS is worse.  If an EXEC is spawned with a fully-qualified path, spawn
invokes the Rexx interpreter passing it the filename but not the path.
The interpreter searches for that name in directories in the PATH environment
variable.  If not found, it fails with a message.  If a different instance with
the same name is found it interprets that rather than the one in the specified
path.

IBM does not consider this a problem.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Skip Robinson]

Is that operand required?

On Wed, Sep 29, 2021 at 10:12 AM Seymour J Metz  wrote:

> By directly, do you  mean explicit use of EXEC? There's an operand to
> distinguish CLIST from REXX.
>
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Skip Robinson 
> Sent: Wednesday, September 29, 2021 12:42 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I vs. JCL
>
> How about invoking a module directly? No SYSPROC is involved here.
>
> EX 'dsn(member)'
>
> I have no way to test it at the moment.
>
> On Wed, Sep 29, 2021 at 7:22 AM Seymour J Metz  wrote:
>
> > TSO SYSPROC is the only case I know of where /* REXX */ is required.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> > of Phil Smith III [li...@akphs.com]
> > Sent: Wednesday, September 29, 2021 10:06 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: PL/I vs. JCL
> >
> > Bob Bridges wrote:
> >
> > >Purely by the way, but I've never really understood why so many REXX
> > modules I see start like this:
> >
> > >  /* REXX */
> >
> > 
> >
> >
> >
> > I think (a) it's documented that way in some places; (b) Some
> environments
> > may even require that; (c) that's how some/many examples have it; and (d)
> > it's bizarre, because these all work in TSO:
> >
> > /* Rexx */
> > /* This rexx program. */
> >
> > /* This is (rexx) */
> >
> > /* This is not(rexx)s */
> >
> > /* Thisisrexxyep */
> >
> > but
> >
> > /* This is a program */
> >
> > does not. So something is parsing the entire first line, looking for the
> > leading "/*" and four letters "rexx" in a row, case-insensitive. Bizarre.
> >
> >
> >
> > Having grown up in VM, I'd never even thought about it, other than
> knowing
> > that I needed the word "rexx" in the first line in TSO. (On VM, just the
> > leading "/*" is sufficient.)
> >
> > --
>
> Skip Robinson
> 323-715-0595
>
>
-- 

Skip Robinson
323-715-0595

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Seymour J Metz]

By directly, do you  mean explicit use of EXEC? There's an operand to 
distinguish CLIST from REXX.



--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3



From: IBM Mainframe Discussion List  on behalf of 
Skip Robinson 
Sent: Wednesday, September 29, 2021 12:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

How about invoking a module directly? No SYSPROC is involved here.

EX 'dsn(member)'

I have no way to test it at the moment.

On Wed, Sep 29, 2021 at 7:22 AM Seymour J Metz  wrote:

> TSO SYSPROC is the only case I know of where /* REXX */ is required.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Phil Smith III [li...@akphs.com]
> Sent: Wednesday, September 29, 2021 10:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I vs. JCL
>
> Bob Bridges wrote:
>
> >Purely by the way, but I've never really understood why so many REXX
> modules I see start like this:
>
> >  /* REXX */
>
> 
>
>
>
> I think (a) it's documented that way in some places; (b) Some environments
> may even require that; (c) that's how some/many examples have it; and (d)
> it's bizarre, because these all work in TSO:
>
> /* Rexx */
> /* This rexx program. */
>
> /* This is (rexx) */
>
> /* This is not(rexx)s */
>
> /* Thisisrexxyep */
>
> but
>
> /* This is a program */
>
> does not. So something is parsing the entire first line, looking for the
> leading "/*" and four letters "rexx" in a row, case-insensitive. Bizarre.
>
>
>
> Having grown up in VM, I'd never even thought about it, other than knowing
> that I needed the word "rexx" in the first line in TSO. (On VM, just the
> leading "/*" is sufficient.)
>
> --

Skip Robinson
323-715-0595

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Ed Jaffe]

On 9/29/2021 7:22 AM, Seymour J Metz wrote:

TSO SYSPROC is the only case I know of where /* REXX */ is required.


In my experience, TSO/E is quite forgiving about the syntax of the first 
line in a REXX. You can say /* REXX is a Great Language */" and it works 
just fine.


However, the z/OS UNIX environment is far less forgiving. I've seen 
failures to recognize a REXX that was accepted by TSO/E.


As a result, I now always ensure a REXX begins with "/* REXX */" and 
nothing else.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Skip Robinson]

How about invoking a module directly? No SYSPROC is involved here.

EX 'dsn(member)'

I have no way to test it at the moment.

On Wed, Sep 29, 2021 at 7:22 AM Seymour J Metz  wrote:

> TSO SYSPROC is the only case I know of where /* REXX */ is required.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Phil Smith III [li...@akphs.com]
> Sent: Wednesday, September 29, 2021 10:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I vs. JCL
>
> Bob Bridges wrote:
>
> >Purely by the way, but I've never really understood why so many REXX
> modules I see start like this:
>
> >  /* REXX */
>
> 
>
>
>
> I think (a) it's documented that way in some places; (b) Some environments
> may even require that; (c) that's how some/many examples have it; and (d)
> it's bizarre, because these all work in TSO:
>
> /* Rexx */
> /* This rexx program. */
>
> /* This is (rexx) */
>
> /* This is not(rexx)s */
>
> /* Thisisrexxyep */
>
> but
>
> /* This is a program */
>
> does not. So something is parsing the entire first line, looking for the
> leading "/*" and four letters "rexx" in a row, case-insensitive. Bizarre.
>
>
>
> Having grown up in VM, I'd never even thought about it, other than knowing
> that I needed the word "rexx" in the first line in TSO. (On VM, just the
> leading "/*" is sufficient.)
>
> --

Skip Robinson
323-715-0595

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Paul Gilmartin]

On Wed, 29 Sep 2021 02:58:19 +0100, CM Poncelet wrote:

>The "/* REXX */" part is required only if the REXX exec is to be run
>from a PDS allocated to DDNAME=SYSPROC instead of to DDNAME=SYSEXEC.
> 
No, it is also required if the REXX exec is to be run from a UNIX directory.  In
that case the comment must also begin in column 1.  I have not seen
documentation of the latter rule but have been ambushed by it in practice.

If the REXX exec comes from SYSPROC it may use TABs ('05'x) for indention.
From SYSEXEC or contains an INTERPRET, a TAB is a syntax error.
Not documented.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Seymour J Metz]

For OS/2 the first line must be either a comment or an EXTPROC, roughly 
equivalent to a *IX shebang.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Thigpen [t...@vse2pdf.com]
Sent: Wednesday, September 29, 2021 10:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

I used REXX in OS/2, but can't remember if it had any special
requirements for the first line. I can't find any manuals online (yet).

Tony Thigpen

Seymour J Metz wrote on 9/29/21 10:22 AM:
> TSO SYSPROC is the only case I know of where /* REXX */ is required.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Phil Smith III [li...@akphs.com]
> Sent: Wednesday, September 29, 2021 10:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I vs. JCL
>
> Bob Bridges wrote:
>
>> Purely by the way, but I've never really understood why so many REXX
> modules I see start like this:
>
>>   /* REXX */
>
> 
>
>
>
> I think (a) it's documented that way in some places; (b) Some environments
> may even require that; (c) that's how some/many examples have it; and (d)
> it's bizarre, because these all work in TSO:
>
> /* Rexx */
> /* This rexx program. */
>
> /* This is (rexx) */
>
> /* This is not(rexx)s */
>
> /* Thisisrexxyep */
>
> but
>
> /* This is a program */
>
> does not. So something is parsing the entire first line, looking for the
> leading "/*" and four letters "rexx" in a row, case-insensitive. Bizarre.
>
>
>
> Having grown up in VM, I'd never even thought about it, other than knowing
> that I needed the word "rexx" in the first line in TSO. (On VM, just the
> leading "/*" is sufficient.)
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[René Jansen]

A quick search on ‘comment’ does not show such a requirement.

René

> On 29 Sep 2021, at 16:02, Seymour J Metz  wrote:
> 
> Does the ANSI standard require the first line to be a comment?
> 
> 
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
> 
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Tony Thigpen [t...@vse2pdf.com]
> Sent: Wednesday, September 29, 2021 9:24 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I vs. JCL
> 
> Also of note, z/VM REXX requires that the first thing in a ReEXX program
> *must* be a comment. It does not require the word REXX, just a comment.
> "/* */" is seen a lot.
> 
> z/VSE REXX does not require that the first thing be a comment, but
> suggests that the first thing be a comment starting with "/* REXX 
> */ for compatibility, but it does not state who requires it for
> compatibility.
> 
> Tony Thigpen
> 
> CM Poncelet wrote on 9/28/21 9:58 PM:
>> The "/* REXX */" part is required only if the REXX exec is to be run
>> from a PDS allocated to DDNAME=SYSPROC instead of to DDNAME=SYSEXEC.
>> 
>> SYSPROC is for CLISTs, SYSEXEC is for REXXs.
>> 
>> 
>> 
>>> On 29/09/2021 02:07, Andrew Rowley wrote:
>>> On 29/09/2021 6:54 am, Bob Bridges wrote:
 Purely by the way, but I've never really understood why so many REXX
 modules I see start like this:
 
/* REXX */
/* Module: Name
   Author: Bob Bridges the Magnificent
   Purpose: Convert ANSI dates to internal format, or whatever. */
 
 ...instead of something like this:
 
/* This REXX converts ANSI dates to internal format, or whatever. */
/* Module: Name
   Author: Bob Bridges the Magnificent */
>>> 
>>> I guess the first looks like a statement with a purpose, the second
>>> looks like a comment that can be freely edited e.g.
>>> 
>>> /* This program converts...
>>> 
>>> Things may not be as obvious to newcomers as they are to those with
>>> more experience.
>>> 
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Tony Thigpen]

I used REXX in OS/2, but can't remember if it had any special 
requirements for the first line. I can't find any manuals online (yet).


Tony Thigpen

Seymour J Metz wrote on 9/29/21 10:22 AM:

TSO SYSPROC is the only case I know of where /* REXX */ is required.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Wednesday, September 29, 2021 10:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

Bob Bridges wrote:


Purely by the way, but I've never really understood why so many REXX

modules I see start like this:


  /* REXX */






I think (a) it's documented that way in some places; (b) Some environments
may even require that; (c) that's how some/many examples have it; and (d)
it's bizarre, because these all work in TSO:

/* Rexx */
/* This rexx program. */

/* This is (rexx) */

/* This is not(rexx)s */

/* Thisisrexxyep */

but

/* This is a program */

does not. So something is parsing the entire first line, looking for the
leading "/*" and four letters "rexx" in a row, case-insensitive. Bizarre.



Having grown up in VM, I'd never even thought about it, other than knowing
that I needed the word "rexx" in the first line in TSO. (On VM, just the
leading "/*" is sufficient.)


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [IBM External] Re: The Business Case for BatchPipes in the z/OS Base (was: ... Pipes ...)

[Paul Gilmartin]

On Wed, 29 Sep 2021 06:54:09 +, Martin Packer wrote:
>
>Between steps can't be pipes, can be VIO. Between jobs can be pipes, can't
>be VIO.
>
Pipes could work between steps if the PIPE SUBSYS has an implied ELASTIC
stage.  But that's just reinventing VIO.  PIPE SUBSYS must do some buffering
to handle BSAM RECFM=VB.  Or does it require that RECFM and BLKSIZE
or the producer and consumer be identical?

>That second sentence depends on the ability to schedule two jobs (possibly
>originally steps of the same job) alongside each other.
>
Alas, the Initiator won't do the latter for you.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Pew, Curtis G]

On Sep 29, 2021, at 9:22 AM, Seymour J Metz  wrote:
> 
> TSO SYSPROC is the only case I know of where /* REXX */ is required.

It’s required in OMVS as well. There, by experiment, the ‘/*’ must be at the 
beginning of the first line and the next thing after it, other than spaces, 
must be ‘REXX’.


-- 
Pew, Curtis G
curtis@austin.utexas.edu






--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RMM Extended Format Record Layout

[Jordi Bornay]

hello Robert
I am interested in the subject, since soon I must install the product and use 
cartridges with a capacity of 8000 -> 400.
Any progress you have made (jcl's, installation tips, ... etc) will be very 
helpful.
Regards

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Seymour J Metz]

TSO SYSPROC is the only case I know of where /* REXX */ is required.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Phil Smith III [li...@akphs.com]
Sent: Wednesday, September 29, 2021 10:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

Bob Bridges wrote:

>Purely by the way, but I've never really understood why so many REXX
modules I see start like this:

>  /* REXX */





I think (a) it's documented that way in some places; (b) Some environments
may even require that; (c) that's how some/many examples have it; and (d)
it's bizarre, because these all work in TSO:

/* Rexx */
/* This rexx program. */

/* This is (rexx) */

/* This is not(rexx)s */

/* Thisisrexxyep */

but

/* This is a program */

does not. So something is parsing the entire first line, looking for the
leading "/*" and four letters "rexx" in a row, case-insensitive. Bizarre.



Having grown up in VM, I'd never even thought about it, other than knowing
that I needed the word "rexx" in the first line in TSO. (On VM, just the
leading "/*" is sufficient.)


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [IBM External] The Business Case for BatchPipes in the z/OS Base (was: ... Pipes ...)

[kekronbekron]

BTW, are most of these recommendations still valid?

- KB

‐‐‐ Original Message ‐‐‐

On Wednesday, September 29th, 2021 at 7:34 PM, Martin Packer 
 wrote:

> Thank you KB!
>
> You can imagine my disappointment at finding all the links to it at the
>
> IBM Redbooks site to be broken.
>
> Cheers, Martin
>
> Martin Packer
>
> WW z/OS Performance, Capacity and Architecture, IBM Technology Sales
>
> +44-7802-245-584
>
> email: martin_pac...@uk.ibm.com
>
> Twitter / Facebook IDs: MartinPacker
>
> Blog: https://mainframeperformancetopics.com
>
> Mainframe, Performance, Topics Podcast Series (With Marna Walle):
>
> https://anchor.fm/marna-walle
>
> Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
>
> From: "kekronbekron" 02dee3fcae33-dmarc-requ...@listserv.ua.edu
>
> To: IBM-MAIN@LISTSERV.UA.EDU
>
> Date: 29/09/2021 14:46
>
> Subject: [EXTERNAL] Re: [IBM External] The Business Case for
>
> BatchPipes in the z/OS Base (was: ... Pipes ...)
>
> Sent by: "IBM Mainframe Discussion List" IBM-MAIN@LISTSERV.UA.EDU
>
> Well my friends, I found it for ye.
>
> https://web.archive.org/web/20060224031157/http://www.redbooks.ibm.com/redbooks/pdfs/sg242557.pdf
>
> Saying this to nobody on this thread, but to some kind of people
>
> Now tell me what's important... knowing how to get to stuff or knowing by
>
> memory all the new parmlib members / keywords in zOS 2.5
>
> -   KB
>
> Original Message
>
> On Wednesday, September 29th, 2021 at 6:45 PM, Martin Packer
>
> martin_pac...@uk.ibm.com wrote:
>
> > I think it's gone. Does anyone still have a PDF of it?
> >
> > Thanks, Martin
> >
> > Martin Packer
> >
> > WW z/OS Performance, Capacity and Architecture, IBM Technology Sales
> >
> > +44-7802-245-584
> >
> > email: martin_pac...@uk.ibm.com
> >
> > Twitter / Facebook IDs: MartinPacker
> >
> > Blog:
>
> https://mainframeperformancetopics.com
>
> > Mainframe, Performance, Topics Podcast Series (With Marna Walle):
>
> https://anchor.fm/marna-walle
>
> > Youtube channel:
>
> https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
>
> > From: "René Jansen" rene.vincent.jan...@gmail.com
> >
> > To: IBM-MAIN@LISTSERV.UA.EDU
> >
> > Date: 29/09/2021 09:12
> >
> > Subject: [EXTERNAL] Re: [IBM External] The Business Case for
> >
> > BatchPipes in the z/OS Base (was: ... Pipes ...)
> >
> > Sent by: "IBM Mainframe Discussion List" IBM-MAIN@LISTSERV.UA.EDU
> >
> > Martin,
> >
> > Do you have that book somewhere still? I spent 15 minutes on google but
> >
> > lots of links lead nowhere.
> >
> > NetRexx does have a rather complete CMS Pipelines implementation (
> >
> > www.netrexx.org <
>
> http://www.netrexx.org/
>
> > > ) and I was wondering what I need to do to also have these ’halfpipes’
> >
> > and other batch interfaces, using JZOS or other.
> >
> > Best regards,
> >
> > René.
> >
> > > On 29 Sep 2021, at 08:54, Martin Packer martin_pac...@uk.ibm.com
> >
> > wrote:
> >
> > > Between steps can't be pipes, can be VIO. Between jobs can be pipes,
> >
> > can't
> >
> > > be VIO.
> > >
> > > That second sentence depends on the ability to schedule two jobs
> >
> > (possibly
> >
> > > originally steps of the same job) alongside each other.
> > >
> > > Fun stuff but / and somewhat complex - which is what inspired me to
> >
> > start
> >
> > > writing what would become SG24-2557 Parallel Sysplex Batch Performance
> >
> > in
> >
> > > late 1990. :-)
> > >
> > > I did a lot of presenting on Pipes to individual customers and
> >
> > conferences
> >
> > > in the 1990s. It would be fun to do it again... :-)
> > >
> > > Cheers, Martin
> > >
> > > Sent from my iPad
> > >
> > > > On 29 Sep 2021, at 05:23, Paul Gilmartin
> > > >
> > > > 000433f07816-dmarc-requ...@listserv.ua.edu wrote:
> > > >
> > > > On Mon, 27 Sep 2021 11:39:17 -0500, Hobart Spitz wrote:
> > > >
> > > > > Intra-JOB pipe - This would be similar to VIO; it doesn't exist
> > > > >
> > > > > otherwise.
> > > >
> > > > > I think it would be a great feature.
> > > >
> > > > Between steps? One might just as well use VIO.
> > > >
> > > > -- gil
> > > >
> > > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > >
> > > > send email to lists...@listserv.ua.edu with the message: INFO
> >
> > IBM-MAINUnless stated otherwise above:
> >
> > > IBM United Kingdom Limited - Registered in England and Wales with
>
> number
>
> > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> >
> > 3AU
> >
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > >
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> >
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> >
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > Unless stated otherwise above:
> >
> > IBM United Kingdom Limited - Registered in England and Wales with number
> >
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
>
> 3AU
>
> > 

Re: PL/I vs. JCL

[Phil Smith III]

Bob Bridges wrote:

>Purely by the way, but I've never really understood why so many REXX
modules I see start like this:

>  /* REXX */



 

I think (a) it's documented that way in some places; (b) Some environments
may even require that; (c) that's how some/many examples have it; and (d)
it's bizarre, because these all work in TSO:

/* Rexx */
/* This rexx program. */

/* This is (rexx) */

/* This is not(rexx)s */

/* Thisisrexxyep */

but

/* This is a program */

does not. So something is parsing the entire first line, looking for the
leading "/*" and four letters "rexx" in a row, case-insensitive. Bizarre.

 

Having grown up in VM, I'd never even thought about it, other than knowing
that I needed the word "rexx" in the first line in TSO. (On VM, just the
leading "/*" is sufficient.)


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [IBM External] The Business Case for BatchPipes in the z/OS Base (was: ... Pipes ...)

[Martin Packer]

Thank you KB!

You can imagine my disappointment at finding all the links to it at the 
IBM Redbooks site to be broken.

Cheers, Martin

Martin Packer

WW z/OS Performance, Capacity and Architecture, IBM Technology Sales

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: https://mainframeperformancetopics.com

Mainframe, Performance, Topics Podcast Series (With Marna Walle): 
https://anchor.fm/marna-walle

Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   "kekronbekron" <02dee3fcae33-dmarc-requ...@listserv.ua.edu>
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   29/09/2021 14:46
Subject:[EXTERNAL] Re: [IBM External] The Business Case for 
BatchPipes in the z/OS Base (was: ... Pipes ...)
Sent by:"IBM Mainframe Discussion List" 



Well my friends, I found it for ye.

https://web.archive.org/web/20060224031157/http://www.redbooks.ibm.com/redbooks/pdfs/sg242557.pdf
 



*Saying this to nobody on this thread, but to some kind of people*
Now tell me what's important... knowing how to get to stuff or knowing by 
memory all the new parmlib members / keywords in zOS 2.5

- KB

�\�\�\�\�\�\�\ Original Message �\�\�\�\�\�\�\

On Wednesday, September 29th, 2021 at 6:45 PM, Martin Packer 
 wrote:

> I think it's gone. Does anyone still have a PDF of it?
>
> Thanks, Martin
>
> Martin Packer
>
> WW z/OS Performance, Capacity and Architecture, IBM Technology Sales
>
> +44-7802-245-584
>
> email: martin_pac...@uk.ibm.com
>
> Twitter / Facebook IDs: MartinPacker
>
> Blog: 
https://mainframeperformancetopics.com 

>
> Mainframe, Performance, Topics Podcast Series (With Marna Walle):
>
> 
https://anchor.fm/marna-walle 

>
> Youtube channel: 
https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA 

>
> From: "René Jansen" rene.vincent.jan...@gmail.com
>
> To: IBM-MAIN@LISTSERV.UA.EDU
>
> Date: 29/09/2021 09:12
>
> Subject: [EXTERNAL] Re: [IBM External] The Business Case for
>
> BatchPipes in the z/OS Base (was: ... Pipes ...)
>
> Sent by: "IBM Mainframe Discussion List" IBM-MAIN@LISTSERV.UA.EDU
>
> Martin,
>
> Do you have that book somewhere still? I spent 15 minutes on google but
>
> lots of links lead nowhere.
>
> NetRexx does have a rather complete CMS Pipelines implementation (
>
> www.netrexx.org <
>
> 
http://www.netrexx.org/ 

>
> > ) and I was wondering what I need to do to also have these ’halfpipes’
>
> and other batch interfaces, using JZOS or other.
>
> Best regards,
>
> René.
>
> > On 29 Sep 2021, at 08:54, Martin Packer martin_pac...@uk.ibm.com
>
> wrote:
>
> > Between steps can't be pipes, can be VIO. Between jobs can be pipes,
>
> can't
>
> > be VIO.
> >
> > That second sentence depends on the ability to schedule two jobs
>
> (possibly
>
> > originally steps of the same job) alongside each other.
> >
> > Fun stuff but / and somewhat complex - which is what inspired me to
>
> start
>
> > writing what would become SG24-2557 Parallel Sysplex Batch Performance
>
> in
>
> > late 1990. :-)
> >
> > I did a lot of presenting on Pipes to individual customers and
>
> conferences
>
> > in the 1990s. It would be fun to do it again... :-)
> >
> > Cheers, Martin
> >
> > Sent from my iPad
> >
> > > On 29 Sep 2021, at 05:23, Paul Gilmartin
> > >
> > > 000433f07816-dmarc-requ...@listserv.ua.edu wrote:
> > >
> > > On Mon, 27 Sep 2021 11:39:17 -0500, Hobart Spitz wrote:
> > >
> > > > Intra-JOB pipe - This would be similar to VIO; it doesn't exist
> > > >
> > > > otherwise.
> > >
> > > > I think it would be a great feature.
> > >
> > > Between steps? One might just as well use VIO.
> > >
> > > -- gil
> > >
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > >
> > > send email to lists...@listserv.ua.edu with the message: INFO
>
> IBM-MAINUnless stated otherwise above:
>
> > IBM United Kingdom Limited - Registered in England and Wales with 
number
>
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
>
> 3AU
>
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> >
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> Unless stated otherwise above:
>
> IBM United Kingdom Limited - Registered in England and Wales with number
>
> 741598.
>
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
>
>
> 

>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Seymour J Metz]

Does the ANSI standard require the first line to be a comment?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Thigpen [t...@vse2pdf.com]
Sent: Wednesday, September 29, 2021 9:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

Also of note, z/VM REXX requires that the first thing in a ReEXX program
*must* be a comment. It does not require the word REXX, just a comment.
"/* */" is seen a lot.

z/VSE REXX does not require that the first thing be a comment, but
suggests that the first thing be a comment starting with "/* REXX 
*/ for compatibility, but it does not state who requires it for
compatibility.

Tony Thigpen

CM Poncelet wrote on 9/28/21 9:58 PM:
> The "/* REXX */" part is required only if the REXX exec is to be run
> from a PDS allocated to DDNAME=SYSPROC instead of to DDNAME=SYSEXEC.
>
> SYSPROC is for CLISTs, SYSEXEC is for REXXs.
>
>
>
> On 29/09/2021 02:07, Andrew Rowley wrote:
>> On 29/09/2021 6:54 am, Bob Bridges wrote:
>>> Purely by the way, but I've never really understood why so many REXX
>>> modules I see start like this:
>>>
>>> /* REXX */
>>> /* Module: Name
>>>Author: Bob Bridges the Magnificent
>>>Purpose: Convert ANSI dates to internal format, or whatever. */
>>>
>>> ...instead of something like this:
>>>
>>> /* This REXX converts ANSI dates to internal format, or whatever. */
>>> /* Module: Name
>>>Author: Bob Bridges the Magnificent */
>>
>> I guess the first looks like a statement with a purpose, the second
>> looks like a comment that can be freely edited e.g.
>>
>> /* This program converts...
>>
>> Things may not be as obvious to newcomers as they are to those with
>> more experience.
>>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [IBM External] The Business Case for BatchPipes in the z/OS Base (was: ... Pipes ...)

[Ron Wells]

Ahh basicsI remember

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
kekronbekron
Sent: Wednesday, September 29, 2021 8:46 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM External] The Business Case for BatchPipes in the z/OS Base 
(was: ... Pipes ...)

** EXTERNAL EMAIL - USE CAUTION **


Well my friends, I found it for ye.

https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fweb.archive.org%2Fweb%2F20060224031157%2Fhttp%3A%2F%2Fwww.redbooks.ibm.com%2Fredbooks%2Fpdfs%2Fsg242557.pdfdata=04%7C01%7CRon.Wells%40OMF.COM%7C5d18d65d03ac481b280408d9834f7854%7C57c0053cb5f84a1e8bb6e8afa09f3b82%7C0%7C0%7C63768520084735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=QrpAr3pkkI4EqsiRBLS8xMBCqEn59a3xvdfeO6woEGk%3Dreserved=0


*Saying this to nobody on this thread, but to some kind of people* Now tell me 
what's important... knowing how to get to stuff or knowing by memory all the 
new parmlib members / keywords in zOS 2.5

- KB

‐‐‐ Original Message ‐‐‐

On Wednesday, September 29th, 2021 at 6:45 PM, Martin Packer 
 wrote:

> I think it's gone. Does anyone still have a PDF of it?
>
> Thanks, Martin
>
> Martin Packer
>
> WW z/OS Performance, Capacity and Architecture, IBM Technology Sales
>
> +44-7802-245-584
>
> email: martin_pac...@uk.ibm.com
>
> Twitter / Facebook IDs: MartinPacker
>
> Blog:
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmain
> frameperformancetopics.com%2Fdata=04%7C01%7CRon.Wells%40OMF.COM%7
> C5d18d65d03ac481b280408d9834f7854%7C57c0053cb5f84a1e8bb6e8afa09f3b82%7
> C0%7C0%7C637685200847310001%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=nYYf
> Xc%2BO%2F4BhKOG9G5yNW5OgSVXUpPSDg1eDT1tBvx0%3Dreserved=0
>
> Mainframe, Performance, Topics Podcast Series (With Marna Walle):
>
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fanch
> or.fm%2Fmarna-walledata=04%7C01%7CRon.Wells%40OMF.COM%7C5d18d65d0
> 3ac481b280408d9834f7854%7C57c0053cb5f84a1e8bb6e8afa09f3b82%7C0%7C0%7C6
> 37685200847310001%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
> V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=6laUrA7rfLQ9FG
> Ion0vaCk8qODQGTGLBs8kcXaNsOfY%3Dreserved=0
>
> Youtube channel:
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> youtube.com%2Fchannel%2FUCu_65HaYgksbF6Q8SQ4oOvAdata=04%7C01%7CRo
> n.Wells%40OMF.COM%7C5d18d65d03ac481b280408d9834f7854%7C57c0053cb5f84a1
> e8bb6e8afa09f3b82%7C0%7C0%7C637685200847310001%7CUnknown%7CTWFpbGZsb3d
> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> 3000sdata=prb%2FQMce629xpliec12VBsH378IG7cbKVc66rA6WW7g%3Dre
> served=0
>
> From: "René Jansen" rene.vincent.jan...@gmail.com
>
> To: IBM-MAIN@LISTSERV.UA.EDU
>
> Date: 29/09/2021 09:12
>
> Subject: [EXTERNAL] Re: [IBM External] The Business Case for
>
> BatchPipes in the z/OS Base (was: ... Pipes ...)
>
> Sent by: "IBM Mainframe Discussion List" IBM-MAIN@LISTSERV.UA.EDU
>
> Martin,
>
> Do you have that book somewhere still? I spent 15 minutes on google
> but
>
> lots of links lead nowhere.
>
> NetRexx does have a rather complete CMS Pipelines implementation (
>
> https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.n
> etrexx.org%2Fdata=04%7C01%7CRon.Wells%40OMF.COM%7C5d18d65d03ac481
> b280408d9834f7854%7C57c0053cb5f84a1e8bb6e8afa09f3b82%7C0%7C0%7C6376852
> 00847310001%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=7G0d%2BLopX5dw7x2O6f
> Imcn83jLCAoRLLJVM0aObRkrg%3Dreserved=0 <
>
> https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.n
> etrexx.org%2Fdata=04%7C01%7CRon.Wells%40OMF.COM%7C5d18d65d03ac481
> b280408d9834f7854%7C57c0053cb5f84a1e8bb6e8afa09f3b82%7C0%7C0%7C6376852
> 00847310001%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
> IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=7G0d%2BLopX5dw7x2O6f
> Imcn83jLCAoRLLJVM0aObRkrg%3Dreserved=0
>
> > ) and I was wondering what I need to do to also have these ’halfpipes’
>
> and other batch interfaces, using JZOS or other.
>
> Best regards,
>
> René.
>
> > On 29 Sep 2021, at 08:54, Martin Packer martin_pac...@uk.ibm.com
>
> wrote:
>
> > Between steps can't be pipes, can be VIO. Between jobs can be pipes,
>
> can't
>
> > be VIO.
> >
> > That second sentence depends on the ability to schedule two jobs
>
> (possibly
>
> > originally steps of the same job) alongside each other.
> >
> > Fun stuff but / and somewhat complex - which is what inspired me to
>
> start
>
> > writing what would become SG24-2557 Parallel Sysplex Batch
> > Performance
>
> in
>
> > late 1990. :-)
> >
> > I did a lot of presenting on Pipes to individual customers and
>
> conferences
>
> > in the 1990s. It would be fun to do it again... :-)
> >
> > Cheers, Martin
> >
> > Sent from my iPad
> >
> > > On 29 Sep 2021, at 05:23, Paul Gilmartin
> > >
> > > 

Re: [IBM External] The Business Case for BatchPipes in the z/OS Base (was: ... Pipes ...)

[kekronbekron]

Well my friends, I found it for ye.

https://web.archive.org/web/20060224031157/http://www.redbooks.ibm.com/redbooks/pdfs/sg242557.pdf


*Saying this to nobody on this thread, but to some kind of people*
Now tell me what's important... knowing how to get to stuff or knowing by 
memory all the new parmlib members / keywords in zOS 2.5

- KB

‐‐‐ Original Message ‐‐‐

On Wednesday, September 29th, 2021 at 6:45 PM, Martin Packer 
 wrote:

> I think it's gone. Does anyone still have a PDF of it?
>
> Thanks, Martin
>
> Martin Packer
>
> WW z/OS Performance, Capacity and Architecture, IBM Technology Sales
>
> +44-7802-245-584
>
> email: martin_pac...@uk.ibm.com
>
> Twitter / Facebook IDs: MartinPacker
>
> Blog: https://mainframeperformancetopics.com
>
> Mainframe, Performance, Topics Podcast Series (With Marna Walle):
>
> https://anchor.fm/marna-walle
>
> Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA
>
> From: "René Jansen" rene.vincent.jan...@gmail.com
>
> To: IBM-MAIN@LISTSERV.UA.EDU
>
> Date: 29/09/2021 09:12
>
> Subject: [EXTERNAL] Re: [IBM External] The Business Case for
>
> BatchPipes in the z/OS Base (was: ... Pipes ...)
>
> Sent by: "IBM Mainframe Discussion List" IBM-MAIN@LISTSERV.UA.EDU
>
> Martin,
>
> Do you have that book somewhere still? I spent 15 minutes on google but
>
> lots of links lead nowhere.
>
> NetRexx does have a rather complete CMS Pipelines implementation (
>
> www.netrexx.org <
>
> http://www.netrexx.org/
>
> > ) and I was wondering what I need to do to also have these ’halfpipes’
>
> and other batch interfaces, using JZOS or other.
>
> Best regards,
>
> René.
>
> > On 29 Sep 2021, at 08:54, Martin Packer martin_pac...@uk.ibm.com
>
> wrote:
>
> > Between steps can't be pipes, can be VIO. Between jobs can be pipes,
>
> can't
>
> > be VIO.
> >
> > That second sentence depends on the ability to schedule two jobs
>
> (possibly
>
> > originally steps of the same job) alongside each other.
> >
> > Fun stuff but / and somewhat complex - which is what inspired me to
>
> start
>
> > writing what would become SG24-2557 Parallel Sysplex Batch Performance
>
> in
>
> > late 1990. :-)
> >
> > I did a lot of presenting on Pipes to individual customers and
>
> conferences
>
> > in the 1990s. It would be fun to do it again... :-)
> >
> > Cheers, Martin
> >
> > Sent from my iPad
> >
> > > On 29 Sep 2021, at 05:23, Paul Gilmartin
> > >
> > > 000433f07816-dmarc-requ...@listserv.ua.edu wrote:
> > >
> > > On Mon, 27 Sep 2021 11:39:17 -0500, Hobart Spitz wrote:
> > >
> > > > Intra-JOB pipe - This would be similar to VIO; it doesn't exist
> > > >
> > > > otherwise.
> > >
> > > > I think it would be a great feature.
> > >
> > > Between steps? One might just as well use VIO.
> > >
> > > -- gil
> > >
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > >
> > > send email to lists...@listserv.ua.edu with the message: INFO
>
> IBM-MAINUnless stated otherwise above:
>
> > IBM United Kingdom Limited - Registered in England and Wales with number
>
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
>
> 3AU
>
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> >
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> Unless stated otherwise above:
>
> IBM United Kingdom Limited - Registered in England and Wales with number
>
> 741598.
>
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
> 
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Tony Thigpen]

Also of note, z/VM REXX requires that the first thing in a ReEXX program 
*must* be a comment. It does not require the word REXX, just a comment. 
"/* */" is seen a lot.


z/VSE REXX does not require that the first thing be a comment, but 
suggests that the first thing be a comment starting with "/* REXX  
*/ for compatibility, but it does not state who requires it for 
compatibility.


Tony Thigpen

CM Poncelet wrote on 9/28/21 9:58 PM:

The "/* REXX */" part is required only if the REXX exec is to be run
from a PDS allocated to DDNAME=SYSPROC instead of to DDNAME=SYSEXEC.
  
SYSPROC is for CLISTs, SYSEXEC is for REXXs.
  



On 29/09/2021 02:07, Andrew Rowley wrote:

On 29/09/2021 6:54 am, Bob Bridges wrote:

Purely by the way, but I've never really understood why so many REXX
modules I see start like this:

    /* REXX */
    /* Module: Name
   Author: Bob Bridges the Magnificent
   Purpose: Convert ANSI dates to internal format, or whatever. */

...instead of something like this:

    /* This REXX converts ANSI dates to internal format, or whatever. */
    /* Module: Name
   Author: Bob Bridges the Magnificent */


I guess the first looks like a statement with a purpose, the second
looks like a comment that can be freely edited e.g.

/* This program converts...

Things may not be as obvious to newcomers as they are to those with
more experience.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [IBM External] The Business Case for BatchPipes in the z/OS Base (was: ... Pipes ...)

[Martin Packer]

I think it's gone. Does anyone still have a PDF of it?

Thanks, Martin

Martin Packer

WW z/OS Performance, Capacity and Architecture, IBM Technology Sales

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: https://mainframeperformancetopics.com

Mainframe, Performance, Topics Podcast Series (With Marna Walle): 
https://anchor.fm/marna-walle

Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   "René Jansen" 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   29/09/2021 09:12
Subject:[EXTERNAL] Re: [IBM External] The Business Case for 
BatchPipes in the z/OS Base (was: ... Pipes ...)
Sent by:"IBM Mainframe Discussion List" 



Martin,

Do you have that book somewhere still? I spent 15 minutes on google but 
lots of links lead nowhere.

NetRexx does have a rather complete CMS Pipelines implementation (
www.netrexx.org <
http://www.netrexx.org/ 
>) and I was wondering what I need to do to also have these ’halfpipes’ 
and other batch interfaces, using JZOS or other.

Best regards,

René. 


> On 29 Sep 2021, at 08:54, Martin Packer  
wrote:
> 
> 
> 
> Between steps can't be pipes, can be VIO. Between jobs can be pipes, 
can't
> be VIO.
> 
> That second sentence depends on the ability to schedule two jobs 
(possibly
> originally steps of the same job) alongside each other.
> 
> Fun stuff but / and somewhat complex - which is what inspired me to 
start
> writing what would become SG24-2557 Parallel Sysplex Batch Performance 
in
> late 1990. :-)
> 
> I did a lot of presenting on Pipes to individual customers and 
conferences
> in the 1990s. It would be fun to do it again... :-)
> 
> Cheers, Martin
> 
> Sent from my iPad
> 
>> On 29 Sep 2021, at 05:23, Paul Gilmartin
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>> 
>> On Mon, 27 Sep 2021 11:39:17 -0500, Hobart Spitz wrote:
>>> 
>>> Intra-JOB pipe - This would be similar to VIO; it doesn't exist
> otherwise.
>>> I think it would be a great feature.
>>> 
>> Between steps?  One might just as well use VIO.
>> 
>> -- gil
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO 
IBM-MAINUnless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: z/OS Dataset Last Date Used Information

[Seymour J Metz]

There are tools on the CBT tape.. If you're licensed for MXG, there are also 
tools there.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Jasi Grewal [ja...@hotmail.com]
Sent: Monday, September 27, 2021 4:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: z/OS Dataset Last Date Used Information

Hi,

I am interested in acquiring information on the DASD Datasets,  which were 
updated recently and to understand the resources utilization.
Is there a Tool available in CBT or somewhere where I could use to provide me 
report on each DASD dataset which were updated today for an example.

I am aware of DCOLLECT and changeid Indicator and LREF,  as I currently extract 
the information from there but interested in other options as well, if they are 
available.
My program checks for CHGID and LREF and if LREF is today's date and CHGID is 
'YES' then probability is that it was changed today for Output.

Any expert advise would be appreciated.
Thank You in advance,
Regards,
Jasi Grewal.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OMVS - comparing directories for differences

[kekronbekron]

Stuff like this from IBM's coffers is pretty neat!

- KB

‐‐‐ Original Message ‐‐‐

On Wednesday, September 29th, 2021 at 6:19 PM, Bill Schoen  
wrote:

> If you want to compare file systems, you can try fscp at
>
> https://github.com/IBM/IBM-Z-zOS/tree/main/zOS-Tools-and-Toys/fscp
>
> Bill Schoen
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OMVS - comparing directories for differences

[Bill Schoen]

If you want to compare file systems, you can try fscp at
https://github.com/IBM/IBM-Z-zOS/tree/main/zOS-Tools-and-Toys/fscp

Bill Schoen

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Seymour J Metz]

>  I recall that the /* is a hardware feature of some card readers. I believe a
> 2540 card reader generated some special status (unit exception?) when it
> read a card with /* in the first two columns,

No, the detection of /*, or whatever DLM specifies, is strictly software, The 
2540 generates a unit exception only when the EOF switch is latched and it 
reads the last card in the hopper.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Charles Mills [charl...@mcn.org]
Sent: Monday, September 27, 2021 6:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

Adding a dummy first line because LISTSERV rejected this post because it
thought it was a command, not a message ...

//SYSIN DD DATA,DLM=xx solves the /* in column 1 problem.

PL/I supports specifiable margins, so PL/I source can start in column 1.

My earliest S/360 memories are from 1968, and both JCL and PL/I were already
around, so no help there. My introduction to S/360 came from PL/I
aficionados, and I remember hearing that the column 2 margin avoided this
conflict, but I don't recall any "which came first" or "my camp versus your
camp" hostility.

I recall that the /* is a hardware feature of some card readers. I believe a
2540 card reader generated some special status (unit exception?) when it
read a card with /* in the first two columns, so one might ask "which came
first: JCL or the hardware feature?"

I don't know the 14xx series at all. Did it use /* as control card
end-of-file?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Phil Smith III
Sent: Monday, September 27, 2021 3:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: PL/I vs. JCL

A friend writes:

In a conversation elsewhere I mentioned the oops between JCL using /* as end
of dataset and PL/I using /* */ for comment brackets - meaning that PL/I had
to start in column 2 to prevent a comment from being interpreted as JCL.
Oopsie. Does anyone remember which came first? There was some rumor that I
no longer remember that one group didn't like the other group so some of
this done on purpose.



I've never heard this, which proves nothing much, but leads me to ask:
anyone else here ever heard it? I'd've guessed JCL came first, since PL/I
was still in development as of December 1964 per the Wikipedia page. But
this is the right place to get some answers (or at least opinions)!




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Seymour J Metz]

> An earlier ply, not quoted here, asserted that column 1 is reserved for 
> carriage
> control.  That seems to conflate source code with SYSPRINT.

Not at all, and more than C'1' in an assembly program makes the source code 
SYSPRINT.

> Does TSO honor "ALLOCATDE DD(SYSUT1)  DSN(*) DLM('xx')  ... ?

No; DLM is for iinstream data sets, not for input from the terminal. BSAM and 
QSAM for TERM only look for /*, although if you can make a business case you 
could submit an RFE.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Monday, September 27, 2021 8:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

On Mon, 27 Sep 2021 15:42:35 -0700, Charles Mills wrote:
.
>
>//SYSIN DD DATA,DLM=xx solves the /* in column 1 problem.
>
+1
In one case I resorted to an exhaustive search to find a digraph
not occurring in a NETDATA sysin.  Ugh!

>PL/I supports specifiable margins, so PL/I source can start in column 1.
>
Which is small solace to the programmer adopting existing sout\rce code.

An earlier ply, not quoted here, asserted that column 1 is reserved for carriage
control.  That seems to conflate source code with SYSPRINT.

A co-worker once supplied some Rexx, all indented one column, presumably
to avoid the "/*" problem.  Didn't work under OMVS, which appears to have
a restriction (undocumented) that "/* Rexx ..." begin in col. 1.

>I recall that the /* is a hardware feature of some card readers. I believe a
>2540 card reader generated some special status (unit exception?) when it
>read a card with /* in the first two columns, so one might ask "which came
>first: JCL or the hardware feature?"
>
Does TSO honor "ALLOCATDE DD(SYSUT1)  DSN(*) DLM('xx')  ... ?

The DLM must be 2 characters in JES3 and up to 8 in JES2 (Conway again).
Underreaching.  It should be long enough to support a random number of
cryptographic strength.

>-Original Message-
>From: Phil Smith III
>Sent: Monday, September 27, 2021 3:09 PM
>
>A friend writes:
>
(As in: "Doctor, my friend thinks she might ..."?)

>In a conversation elsewhere I mentioned the oops between JCL using /* as end
>of dataset and PL/I using /* */ for comment brackets - meaning that PL/I had
>to start in column 2 to prevent a comment from being interpreted as JCL.
>Oopsie. Does anyone remember which came first? There was some rumor that I
>no longer remember that one group didn't like the other group so some of
>this done on purpose.
>
Conway's Law, an IBM guiding principle, escalated to bitter conflict.

But, yes, fact checking needed.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I vs. JCL

[Joe Monk]

True, but it is a recommended best practice to start all rexx execs with
the /* REXX */ comment. IBM recommends this because REXX execs can be
transported to other SAA environments.

Joe

On Tue, Sep 28, 2021 at 8:58 PM CM Poncelet  wrote:

> The "/* REXX */" part is required only if the REXX exec is to be run
> from a PDS allocated to DDNAME=SYSPROC instead of to DDNAME=SYSEXEC.
>
> SYSPROC is for CLISTs, SYSEXEC is for REXXs.
>
>
>
> On 29/09/2021 02:07, Andrew Rowley wrote:
> > On 29/09/2021 6:54 am, Bob Bridges wrote:
> >> Purely by the way, but I've never really understood why so many REXX
> >> modules I see start like this:
> >>
> >>/* REXX */
> >>/* Module: Name
> >>   Author: Bob Bridges the Magnificent
> >>   Purpose: Convert ANSI dates to internal format, or whatever. */
> >>
> >> ...instead of something like this:
> >>
> >>/* This REXX converts ANSI dates to internal format, or whatever. */
> >>/* Module: Name
> >>   Author: Bob Bridges the Magnificent */
> >
> > I guess the first looks like a statement with a purpose, the second
> > looks like a comment that can be freely edited e.g.
> >
> > /* This program converts...
> >
> > Things may not be as obvious to newcomers as they are to those with
> > more experience.
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [IBM External] The Business Case for BatchPipes in the z/OS Base (was: ... Pipes ...)

[René Jansen]

Martin,

Do you have that book somewhere still? I spent 15 minutes on google but lots of 
links lead nowhere.

NetRexx does have a rather complete CMS Pipelines implementation 
(www.netrexx.org ) and I was wondering what I need to 
do to also have these ’halfpipes’ and other batch interfaces, using JZOS or 
other.

Best regards,

René. 


> On 29 Sep 2021, at 08:54, Martin Packer  wrote:
> 
> 
> 
> Between steps can't be pipes, can be VIO. Between jobs can be pipes, can't
> be VIO.
> 
> That second sentence depends on the ability to schedule two jobs (possibly
> originally steps of the same job) alongside each other.
> 
> Fun stuff but / and somewhat complex - which is what inspired me to start
> writing what would become SG24-2557 Parallel Sysplex Batch Performance in
> late 1990. :-)
> 
> I did a lot of presenting on Pipes to individual customers and conferences
> in the 1990s. It would be fun to do it again... :-)
> 
> Cheers, Martin
> 
> Sent from my iPad
> 
>> On 29 Sep 2021, at 05:23, Paul Gilmartin
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>> 
>> On Mon, 27 Sep 2021 11:39:17 -0500, Hobart Spitz wrote:
>>> 
>>> Intra-JOB pipe - This would be similar to VIO; it doesn't exist
> otherwise.
>>> I think it would be a great feature.
>>> 
>> Between steps?  One might just as well use VIO.
>> 
>> -- gil
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAINUnless 
>> stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> 
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [IBM External] Re: The Business Case for BatchPipes in the z/OS Base (was: ... Pipes ...)

[Martin Packer]

Between steps can't be pipes, can be VIO. Between jobs can be pipes, can't
be VIO.

That second sentence depends on the ability to schedule two jobs (possibly
originally steps of the same job) alongside each other.

Fun stuff but / and somewhat complex - which is what inspired me to start
writing what would become SG24-2557 Parallel Sysplex Batch Performance in
late 1990. :-)

I did a lot of presenting on Pipes to individual customers and conferences
in the 1990s. It would be fun to do it again... :-)

Cheers, Martin

Sent from my iPad

> On 29 Sep 2021, at 05:23, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> On Mon, 27 Sep 2021 11:39:17 -0500, Hobart Spitz wrote:
>>
>> Intra-JOB pipe - This would be similar to VIO; it doesn't exist
otherwise.
>> I think it would be a great feature.
>>
> Between steps?  One might just as well use VIO.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAINUnless 
> stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OMVS - comparing directories for differences

[kekronbekron]

Grep filters as appropriate in the middle, I suppose.
My main point being - make use of git style diff-ing.

- KB

‐‐‐ Original Message ‐‐‐

On Wednesday, September 29th, 2021 at 11:44 AM, Paul Gilmartin 
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Wed, 29 Sep 2021 05:48:25 +, kekronbekron wrote:
>
> > Else, ls -alR on both dirs.
> >
> > Then, create a blank project in PyCharm/IntelliJ and navigate to the dir 
> > containing these 2 listings.
> >
> > Select both and then choose diff/compare.
> >
> > Believe me, git style diff-ing is super neat and convenient, compared to 
> > the standard diff we use on zOS.
>
> Should timestamp, permissions, owner, group be compared? I chose not to.
>
> The OP might feel the opposite.
>
> Must thee method deal with non-portable filenames? In the extreme case, a
>
> filename can mimic a line output by "ls -alR".
>
> > ‐‐‐ Original Message ‐‐‐
> >
> > On Wednesday, September 29th, 2021 at 9:33 AM, Paul Gilmartin wrote:
> >
> > > On Tue, 28 Sep 2021 21:22:29 -0500, Bruce Hewson wrote:
> > >
> > > > We are looking for a way to compare 2 filesystem structures, starting 
> > > > at root '/'.
> > > >
> > > > Differences we want to identify:-
> > > >
> > > > 1.  directory
> > > > 2.  file
> > > > 3.  symlink
> > >
> > > from the file it references. You might isolate the symlinks with:
> > >
> > > find . -type l -exec ls -l {} \; |
> > >
> > > sed -E 's/( [^ ]){8}//' >TheLinks
> > >
> > > ... in each filesystem and compare the generated listings of links.
>
> -- gil
>
> -
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OMVS - comparing directories for differences

[Paul Gilmartin]

On Wed, 29 Sep 2021 05:48:25 +, kekronbekron wrote:

>Else, ls -alR on both dirs.
>Then, create a blank project in PyCharm/IntelliJ and navigate to the dir 
>containing these 2 listings.
>Select both and then choose diff/compare.
>Believe me, git style diff-ing is super neat and convenient, compared to the 
>standard diff we use on zOS.
> 
Should timestamp, permissions, owner, group be compared?  I chose not to.
The OP might feel the opposite.

Must thee method deal with non-portable filenames?  In the extreme case, a
filename can mimic a line output by "ls -alR".


>‐‐‐ Original Message ‐‐‐
>
>On Wednesday, September 29th, 2021 at 9:33 AM, Paul Gilmartin wrote:
>
>> On Tue, 28 Sep 2021 21:22:29 -0500, Bruce Hewson wrote:
>> >
>> > We are looking for a way to compare 2 filesystem structures, starting at 
>> > root '/'.
>> >
>> > Differences we want to identify:-
>> >
>> > 1.  directory
>> > 2.  file
>> > 3.  symlink
>>
>> from the file it references. You might isolate the symlinks with:
>>
>> find . -type l -exec ls -l {} \; |
>>
>> sed -E 's/( [^ ]){8}//' >TheLinks
>>
>> ... in each filesystem and compare the generated listings of links.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN