Re: PL/I vs. JCL

[Bob Bridges]

Gil, did you misunderstand me, or I you?  This ASCII-based IPA ~is~ good for 
"audio" in the sense that it defines unambiguously how one is pronouncing a 
word.  I see "slough" and pronounce it /slu/; someone else sees it and says 
/slaU/.  I pronounce "caught" /cOt/ and "cot" /cat/; some people, I'm told, 
pronounce them the same.

You, OTOH, seem to be talking about "audio" in the sense of talking on the 
phone (for example) and ~spelling~ a word unambiguously, which is a different 
matter.  Maybe I misunderstood.

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

/* Just like genetic diversity, which prevents an epidemic from wiping out a 
whole species at once, diversity in software is a good thing.  -Cliff Stoll, in 
_The Cuckoo's Egg: Tracking a Spy through the Maze of Computer Espionage_ */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Monday, October 4, 2021 21:04

But no good for audio.  If I need to spell something out for local authorities, 
I use the modal NATO codes.  I don't carry all their wallet cards.

--- On Mon, 4 Oct 2021 14:46:50 -0400, Bob Bridges wrote:
>... (There's an ASCII adaptation of the IPA that's actually pretty 
> handy.  Only problem is, no one's ever seen it, except a few of us 
> geeks.  If we all understood that you could have written "/aI Ef ti/", 
> without fear of ambiguity.)

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

Somewhere, perhaps in Civil Air Patrol some decades ago, I got the impression 
that one scheme has indeed become pretty standard, and in particular is used by 
air-traffic control the world over, at least where English is spoken (which is 
mostly).  More recently I've read that it ain't necessarily so.  The American 
police used to have their own scheme, based mostly on given names, but I think 
they've mostly adopted the US military version too.

I speak under correction.

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

/* If you will here stop and ask yourselves why you are not as pious as the 
primitive Christians were, your own heart will tell you, that it is neither 
through ignorance nor inability, but purely because you never thoroughly 
intended it.  -from "A Serious Call to a Devout and Holy Life" by William Law 
(1686-1761) */


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of CM 
Poncelet
Sent: Monday, October 4, 2021 20:21

able baker charlie dog easy fox

--- On 04/10/2021 15:10, Paul Gilmartin wrote:
> If the newscaster had been an aviator he couldd have said Alfa Foxtrot Tango.
> But an aviator or a mariner wouldn't have needed to.
>
> I believe he said in defense that it appeared in caps in his script.  
> But if that came off a teletype everything would have been caps.
>
> I once recited a serial number to Tech Support using NATO phonetic alphabet.
> She understood immediately; no request for clarification.  Perhaps she 
> was a veteran.  Why can't local emergency services concur on a phonetic 
> alphabet?

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

[Phil Smith III]

Shmuel wrote:

> IBM has always had a propensity for changing nomenclature, e.g. from Data
Management to Data Administration.

 

Of course.but they didn't change it here: they seemed to decide to use both.
That's even weirder.

 

Changing: zSeries, System z, z Systems, IBM Z, and (sort of) zEnterprise.
That's too many in 20 years.


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

And before that MVS-OE., with MVS before Open.


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



From: IBM Mainframe Discussion List  on behalf of 
David Spiegel 
Sent: Tuesday, October 5, 2021 1:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

Maybe they should've left it as "Open MVS"? (OS/390)

On 2021-10-05 13:08, Tom Brennan wrote:
> I always thought IBM's position on that was pretty silly.  If you make
> up a new three word name, expect it to quickly be turned into an
> acronym.  If they didn't want us to reuse an existing little-known
> acronym they should have named it something else.
>
> On 10/5/2021 9:56 AM, Seymour J Metz wrote:
>>>   USS has always meant Unix System Services.
>>
>>
>> Not unless you have a time machine; Unformatted System Services dates
>> to the 1970s. Further, the last post here from IBM on the issue said
>> that USS was not an approved abbreviation for Unix System Services.
>>
>> --
>> Shmuel (Seymour J.) Metz
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3data=04%7C01%7C%7C66d0453903554718720608d98822bd8d%7C84df9e7fe9f640afb435%7C1%7C0%7C637690505140660718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Lxw1EM03nZsemipAC1ktZCbgKrL%2BedD7%2BDDlG%2Fiwn%2B8%3Dreserved=0
>>
>>
>>
>> 
>> From: IBM Mainframe Discussion List  on
>> behalf of Joe Monk 
>> Sent: Monday, October 4, 2021 9:11 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: PL/I vs. JCL
>>
>> USS is a VTAM term for Unformatted System Services.
>>
>> USS has always meant Unix System Services.
>>
>> Joe
>>
>> On Mon, Oct 4, 2021 at 7:30 PM Mike Schwab 
>> wrote:
>>
>>> U.S.S.  Unformated System Services, until Unix System Services tried
>>> to take it over.
>>>
>>> On Tue, Oct 5, 2021 at 1:24 AM Paul Gilmartin
>>> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>>>>
>>>> On Mon, 4 Oct 2021 17:35:41 +, Seymour J Metz wrote:
>>>>
>>>>> While TSO does not support unambiguous truncation for command
>>>>> names, it
>>> does for keywords. I don't know about ICCF.
>>>>>
>>>> Unambiguous truncation is treacherous.  Addition of new
>>> commands/keywords can break
>>>> legacy art.  For that reason I eschew abbreviations in code and
>>> pedagogy.  The worst
>>>> case occurs when one command is a proper prefix of another command.
>>>>
>>>> I freely abbreviate on a command line.
>>>>
>>>> 
>>>> On Sat, 2 Oct 2021 20:56:43 -0700, Charles Mills wrote:
>>>>> I have no problem with the DD/member ambiguity:
>>>>> \edu with the message: INFO IBM-MAIN
>>>>
>>>> -- gil
>>>>
>>>> --
>>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>>
>>>
>>>
>>> --
>>> Mike A Schwab, Springfield IL USA
>>> Where do Forest Rangers go to get away from it all?
>>>
>>> --
>>> 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
> .

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

The title of that bookshelf is z/OS UNIX System Services, not USS.


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



From: IBM Mainframe Discussion List  on behalf of Joe 
Monk 
Sent: Tuesday, October 5, 2021 3:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

What is the title of this book?

https://www.ibm.com/docs/en/zos/2.3.0?topic=zos-unix-system-services

Joe

On Tue, Oct 5, 2021, 13:58 Ed Jaffe  wrote:

> On 10/5/2021 9:56 AM, Seymour J Metz wrote:
> >
> > Further, the last post here from IBM on the issue said that USS was not
> an approved abbreviation for Unix System Services.
>
> Quite so. If you search for "USS" in IBM z/OS 2.5 documentation:
>
> https://www.ibm.com/docs/en/search/USS?scope=SSLTBW_2.5.0
>
> you will find several hits for Unformatted System Services in the
> CommServer books and no hits whatsoever in the z/OS UNIX books.
>
>
> --
> Phoenix Software International
> Edward E. Jaffe
> 831 Parkview Drive North
> El Segundo, CA 90245
> https://secure-web.cisco.com/1sB3lHoqdwC5gG1Vm_3ay2PVQfBDqx_0oPcM2dfJmlwViS5WuBlCUwwNgUAXk4lIGKPiyjDHJvPhdTygn1m8DgKNrY6s9026fjL3wUJJf5w0s7gnJFC29KPC9els0c9be3fHXPGE-Nu8aCdKcV4e_cfXDl9N4U84lBLRYARCmJY5BMNnbrcZ0wFOi-C2Tfm0O3dnNhgUuz6KyaW2fRfxNMKKF_HzZJR-Ai9Nilg0bmomvqZEoFV-4MWyDqz3-RPYIX_XXk0CoDg1fD_75qSynIAHYjALlMMeUGFTTZL1mVtSRznokiVjdQEBF4ez2KQTqF_N-H509WstmgIdmB7kJnc5vyg9Nbck4WCEZxwpRrco71Ha0z8tJeh3n-tXsW7ngFPHVM8nK5Hm1tB-5Ps0tF1ZWwSedCAy9ZXxcO5XykxQf18gN1hgZixbFVEdKb1Sx/https%3A%2F%2Fwww.phoenixsoftware.com%2F
>
>
>
> 
> 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
>

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

IBM has always had a propensity for changing nomenclature, e.g. from Data 
Management to Data Administration.


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



From: IBM Mainframe Discussion List  on behalf of 
Phil Smith III 
Sent: Tuesday, October 5, 2021 3:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

Joe: Are those eight books the only use of the term in IBM doc? Still
convincing-it's not like it's one isolated RedBook-but perhaps reflecting
that it was perhaps viewed as a mistake (or "Open MVS" was), but one that
was too hard to undo. Guessing we'll never know.



It is curious that "UNIX System Services" is even a term, given that "Open
MVS" and "OMVS" were already around and OMVS is more visible (e.g., you
don't define a "USS segment"). In the Olden Days, I suspect IBM would have
been more careful about such things. Deck chairs at this point.



Also note that those docs talk about "z/OS UNIX", which is yet another
slight variation on the theme! (Yes, probably UNIX System Services is a
subset of z/OS UNIX, but the point is, "USS" stuck.)



...phsiii


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

[Ron Wells]

Gc28-0629-1  vs2 3.7  11/15/76

Vtam unformatted system services (USS)

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Gibney, Dave
Sent: Tuesday, October 05, 2021 2:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

** EXTERNAL EMAIL - USE CAUTION **


>From the 1st abstract:
z/OS UNIX System Services (z/OS UNIX)
Is IBM's preferred terminology

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Joe Monk
> Sent: Tuesday, October 05, 2021 12:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I vs. JCL
>
> What is the title of this book?
>
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fzos%2F2.3.
> 0%3Ftopdata=04%7C01%7CRon.Wells%40OMF.COM%7C7deb7c4c2bc444fbd11e0
> 8d988334ee9%7C57c0053cb5f84a1e8bb6e8afa09f3b82%7C0%7C0%7C6376905762141
> 73198%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB
> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=8Y2OUNnPrMGiP4JS4gv2aNV8qq
> 5uROJAG24eH14Cas4%3Dreserved=0
> ic=zos-unix-system-services__;!!JmPEgBY0HMszNaDT!8tb9V_xzl-
> O2qojJgBt3KsnCxRGI-6He5Al6AhVprIk3GM7yixUGzQiW7wD4mQ$
>
> Joe
>
> On Tue, Oct 5, 2021, 13:58 Ed Jaffe  wrote:
>
> > On 10/5/2021 9:56 AM, Seymour J Metz wrote:
> > >
> > > Further, the last post here from IBM on the issue said that USS
> > > was not
> > an approved abbreviation for Unix System Services.
> >
> > Quite so. If you search for "USS" in IBM z/OS 2.5 documentation:
> >
> >
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fsearch%2FU
> SS%3Fsdata=04%7C01%7CRon.Wells%40OMF.COM%7C7deb7c4c2bc444fbd11e08
> d988334ee9%7C57c0053cb5f84a1e8bb6e8afa09f3b82%7C0%7C0%7C63769057621417
> 3198%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
> iI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=vZxAo2kzYxrk7XyXyjUOgl1GKJb
> BF2q9Q73K%2F7Wl7TA%3Dreserved=0
> cope=SSLTBW_2.5.0__;!!JmPEgBY0HMszNaDT!8tb9V_xzl-
> O2qojJgBt3KsnCxRGI-6He5Al6AhVprIk3GM7yixUGzQjszvUwCQ$
> >
> > you will find several hits for Unformatted System Services in the
> > CommServer books and no hits whatsoever in the z/OS UNIX books.
> >
> >
> > --
> > Phoenix Software International
> > Edward E. Jaffe
> > 831 Parkview Drive North
> > El Segundo, CA 90245
> >
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Fwww.phoenixsoftware.com%2F__%3B!!JmP
> data=04%7C01%7CRon.Wells%40OMF.COM%7C7deb7c4c2bc444fbd11e08d98833
> 4ee9%7C57c0053cb5f84a1e8bb6e8afa09f3b82%7C0%7C0%7C637690576214173198%7
> CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> haWwiLCJXVCI6Mn0%3D%7C1000sdata=W2Dxj74SCrWjSUH0Hpthrc2QhJXw7Ytwj
> VYyER%2FGtT8%3Dreserved=0
> EgBY0HMszNaDT!8tb9V_xzl-O2qojJgBt3KsnCxRGI-
> 6He5Al6AhVprIk3GM7yixUGzQj3ScfQsQ$
> >
> >
> >
> > 
> >  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
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAI

Re: PL/I vs. JCL

[Phil Smith III]

Joe: Are those eight books the only use of the term in IBM doc? Still
convincing-it's not like it's one isolated RedBook-but perhaps reflecting
that it was perhaps viewed as a mistake (or "Open MVS" was), but one that
was too hard to undo. Guessing we'll never know.

 

It is curious that "UNIX System Services" is even a term, given that "Open
MVS" and "OMVS" were already around and OMVS is more visible (e.g., you
don't define a "USS segment"). In the Olden Days, I suspect IBM would have
been more careful about such things. Deck chairs at this point.

 

Also note that those docs talk about "z/OS UNIX", which is yet another
slight variation on the theme! (Yes, probably UNIX System Services is a
subset of z/OS UNIX, but the point is, "USS" stuck.)

 

...phsiii


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

[Gibney, Dave]

From the 1st abstract:
z/OS UNIX System Services (z/OS UNIX)
Is IBM's preferred terminology 

> -Original Message-
> From: IBM Mainframe Discussion List  On
> Behalf Of Joe Monk
> Sent: Tuesday, October 05, 2021 12:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I vs. JCL
> 
> What is the title of this book?
> 
> https://urldefense.com/v3/__https://www.ibm.com/docs/en/zos/2.3.0?top
> ic=zos-unix-system-services__;!!JmPEgBY0HMszNaDT!8tb9V_xzl-
> O2qojJgBt3KsnCxRGI-6He5Al6AhVprIk3GM7yixUGzQiW7wD4mQ$
> 
> Joe
> 
> On Tue, Oct 5, 2021, 13:58 Ed Jaffe  wrote:
> 
> > On 10/5/2021 9:56 AM, Seymour J Metz wrote:
> > >
> > > Further, the last post here from IBM on the issue said that USS was not
> > an approved abbreviation for Unix System Services.
> >
> > Quite so. If you search for "USS" in IBM z/OS 2.5 documentation:
> >
> >
> https://urldefense.com/v3/__https://www.ibm.com/docs/en/search/USS?s
> cope=SSLTBW_2.5.0__;!!JmPEgBY0HMszNaDT!8tb9V_xzl-
> O2qojJgBt3KsnCxRGI-6He5Al6AhVprIk3GM7yixUGzQjszvUwCQ$
> >
> > you will find several hits for Unformatted System Services in the
> > CommServer books and no hits whatsoever in the z/OS UNIX books.
> >
> >
> > --
> > Phoenix Software International
> > Edward E. Jaffe
> > 831 Parkview Drive North
> > El Segundo, CA 90245
> >
> https://urldefense.com/v3/__https://www.phoenixsoftware.com/__;!!JmP
> EgBY0HMszNaDT!8tb9V_xzl-O2qojJgBt3KsnCxRGI-
> 6He5Al6AhVprIk3GM7yixUGzQj3ScfQsQ$
> >
> >
> >
> > 
> > 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
> >
> 
> --
> 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]

What is the title of this book?

https://www.ibm.com/docs/en/zos/2.3.0?topic=zos-unix-system-services

Joe

On Tue, Oct 5, 2021, 13:58 Ed Jaffe  wrote:

> On 10/5/2021 9:56 AM, Seymour J Metz wrote:
> >
> > Further, the last post here from IBM on the issue said that USS was not
> an approved abbreviation for Unix System Services.
>
> Quite so. If you search for "USS" in IBM z/OS 2.5 documentation:
>
> https://www.ibm.com/docs/en/search/USS?scope=SSLTBW_2.5.0
>
> you will find several hits for Unformatted System Services in the
> CommServer books and no hits whatsoever in the z/OS UNIX books.
>
>
> --
> 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
>

--
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 10/5/2021 9:56 AM, Seymour J Metz wrote:


Further, the last post here from IBM on the issue said that USS was not an 
approved abbreviation for Unix System Services.


Quite so. If you search for "USS" in IBM z/OS 2.5 documentation:

https://www.ibm.com/docs/en/search/USS?scope=SSLTBW_2.5.0

you will find several hits for Unformatted System Services in the 
CommServer books and no hits whatsoever in the z/OS UNIX books.



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

[David Spiegel]

Maybe they should've left it as "Open MVS"? (OS/390)

On 2021-10-05 13:08, Tom Brennan wrote:
I always thought IBM's position on that was pretty silly.  If you make 
up a new three word name, expect it to quickly be turned into an 
acronym.  If they didn't want us to reuse an existing little-known 
acronym they should have named it something else.


On 10/5/2021 9:56 AM, Seymour J Metz wrote:

  USS has always meant Unix System Services.



Not unless you have a time machine; Unformatted System Services dates 
to the 1970s. Further, the last post here from IBM on the issue said 
that USS was not an approved abbreviation for Unix System Services.


--
Shmuel (Seymour J.) Metz
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3data=04%7C01%7C%7C66d0453903554718720608d98822bd8d%7C84df9e7fe9f640afb435%7C1%7C0%7C637690505140660718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Lxw1EM03nZsemipAC1ktZCbgKrL%2BedD7%2BDDlG%2Fiwn%2B8%3Dreserved=0 





From: IBM Mainframe Discussion List  on 
behalf of Joe Monk 

Sent: Monday, October 4, 2021 9:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

USS is a VTAM term for Unformatted System Services.

USS has always meant Unix System Services.

Joe

On Mon, Oct 4, 2021 at 7:30 PM Mike Schwab  
wrote:



U.S.S.  Unformated System Services, until Unix System Services tried
to take it over.

On Tue, Oct 5, 2021 at 1:24 AM Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:


On Mon, 4 Oct 2021 17:35:41 +, Seymour J Metz wrote:

While TSO does not support unambiguous truncation for command 
names, it

does for keywords. I don't know about ICCF.



Unambiguous truncation is treacherous.  Addition of new

commands/keywords can break

legacy art.  For that reason I eschew abbreviations in code and

pedagogy.  The worst

case occurs when one command is a proper prefix of another command.

I freely abbreviate on a command line.


On Sat, 2 Oct 2021 20:56:43 -0700, Charles Mills wrote:

I have no problem with the DD/member ambiguity:
\edu with the message: INFO IBM-MAIN


-- gil

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




--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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


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

[Tom Brennan]

I always thought IBM's position on that was pretty silly.  If you make 
up a new three word name, expect it to quickly be turned into an 
acronym.  If they didn't want us to reuse an existing little-known 
acronym they should have named it something else.


On 10/5/2021 9:56 AM, Seymour J Metz wrote:

  USS has always meant Unix System Services.



Not unless you have a time machine; Unformatted System Services dates to the 
1970s. Further, the last post here from IBM on the issue said that USS was not 
an approved abbreviation for Unix System Services.

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



From: IBM Mainframe Discussion List  on behalf of Joe Monk 

Sent: Monday, October 4, 2021 9:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

USS is a VTAM term for Unformatted System Services.

USS has always meant Unix System Services.

Joe

On Mon, Oct 4, 2021 at 7:30 PM Mike Schwab  wrote:


U.S.S.  Unformated System Services, until Unix System Services tried
to take it over.

On Tue, Oct 5, 2021 at 1:24 AM Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:


On Mon, 4 Oct 2021 17:35:41 +, Seymour J Metz wrote:


While TSO does not support unambiguous truncation for command names, it

does for keywords. I don't know about ICCF.



Unambiguous truncation is treacherous.  Addition of new

commands/keywords can break

legacy art.  For that reason I eschew abbreviations in code and

pedagogy.  The worst

case occurs when one command is a proper prefix of another command.

I freely abbreviate on a command line.


On Sat, 2 Oct 2021 20:56:43 -0700, Charles Mills wrote:

I have no problem with the DD/member ambiguity:
\edu with the message: INFO IBM-MAIN


-- gil

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




--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

[Seymour J Metz]

>  USS has always meant Unix System Services.


Not unless you have a time machine; Unformatted System Services dates to the 
1970s. Further, the last post here from IBM on the issue said that USS was not 
an approved abbreviation for Unix System Services.

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



From: IBM Mainframe Discussion List  on behalf of Joe 
Monk 
Sent: Monday, October 4, 2021 9:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

USS is a VTAM term for Unformatted System Services.

USS has always meant Unix System Services.

Joe

On Mon, Oct 4, 2021 at 7:30 PM Mike Schwab  wrote:

> U.S.S.  Unformated System Services, until Unix System Services tried
> to take it over.
>
> On Tue, Oct 5, 2021 at 1:24 AM Paul Gilmartin
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > On Mon, 4 Oct 2021 17:35:41 +, Seymour J Metz wrote:
> >
> > >While TSO does not support unambiguous truncation for command names, it
> does for keywords. I don't know about ICCF.
> > >
> > Unambiguous truncation is treacherous.  Addition of new
> commands/keywords can break
> > legacy art.  For that reason I eschew abbreviations in code and
> pedagogy.  The worst
> > case occurs when one command is a proper prefix of another command.
> >
> > I freely abbreviate on a command line.
> >
> > 
> > On Sat, 2 Oct 2021 20:56:43 -0700, Charles Mills wrote:
> > >I have no problem with the DD/member ambiguity:
> > >\edu with the message: INFO IBM-MAIN
> >
> > -- gil
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> 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

[Charles Mills]

FSVO "always."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Joe Monk
Sent: Monday, October 4, 2021 6:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

USS is a VTAM term for Unformatted System Services.

USS has always meant Unix System Services.

Joe

On Mon, Oct 4, 2021 at 7:30 PM Mike Schwab  wrote:

> U.S.S.  Unformated System Services, until Unix System Services tried
> to take it over.
>
> On Tue, Oct 5, 2021 at 1:24 AM Paul Gilmartin
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > On Mon, 4 Oct 2021 17:35:41 +, Seymour J Metz wrote:
> >
> > >While TSO does not support unambiguous truncation for command names, it
> does for keywords. I don't know about ICCF.
> > >
> > Unambiguous truncation is treacherous.  Addition of new
> commands/keywords can break
> > legacy art.  For that reason I eschew abbreviations in code and
> pedagogy.  The worst
> > case occurs when one command is a proper prefix of another command.
> >
> > I freely abbreviate on a command line.
> >
> > 
> > On Sat, 2 Oct 2021 20:56:43 -0700, Charles Mills wrote:
> > >I have no problem with the DD/member ambiguity:
> > >\edu with the message: INFO IBM-MAIN
> >
> > -- gil
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> 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

[Joe Monk]

alpha
bravo
charlie
delta
echo
foxtrot
golf
hotel
india
juliet
kilo
mike
november
oscar
papa
quebec ("kay-bec")
romeo
sierra
tango
uniform
victor
whiskey
xray
yankee
zulu

On Mon, Oct 4, 2021 at 7:21 PM CM Poncelet  wrote:

> able baker charlie dog easy fox
>
> On 04/10/2021 15:10, Paul Gilmartin wrote:
> > On Mon, 4 Oct 2021 09:35:39 -0400, Bob Bridges wrote:
> >
> >> Ok, I give up.  I have favorite-newscaster stories, too, but I don't
> get this one.  What's an EFT cargo hatch?  Is this so obvious a failure
> that I'll be required by law to kick myself when it's explained to me, or
> something that only pilots know, or what?
> >>
> > I struggled for vernacular phonetic vowel names and apparently failed.
> >
> > If the newscaster had been an aviator he couldd have said Alfa Foxtrot
> Tango.
> > But an aviator or a mariner wouldn't have needed to.
> >
> > I believe he said in defense that it appeared in caps in his script.
> But if that
> > came off a teletype everything would have been caps.
> >
> > I once recited a serial number to Tech Support using NATO phonetic
> alphabet.
> > She understood immediately; no request for clarification.  Perhaps she
> was
> > a veteran.  Why can't local emergency services concur on a phonetic
> alphabet?
> >
> > -- 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
>

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

USS is a VTAM term for Unformatted System Services.

USS has always meant Unix System Services.

Joe

On Mon, Oct 4, 2021 at 7:30 PM Mike Schwab  wrote:

> U.S.S.  Unformated System Services, until Unix System Services tried
> to take it over.
>
> On Tue, Oct 5, 2021 at 1:24 AM Paul Gilmartin
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> >
> > On Mon, 4 Oct 2021 17:35:41 +, Seymour J Metz wrote:
> >
> > >While TSO does not support unambiguous truncation for command names, it
> does for keywords. I don't know about ICCF.
> > >
> > Unambiguous truncation is treacherous.  Addition of new
> commands/keywords can break
> > legacy art.  For that reason I eschew abbreviations in code and
> pedagogy.  The worst
> > case occurs when one command is a proper prefix of another command.
> >
> > I freely abbreviate on a command line.
> >
> > 
> > On Sat, 2 Oct 2021 20:56:43 -0700, Charles Mills wrote:
> > >I have no problem with the DD/member ambiguity:
> > >\edu with the message: INFO IBM-MAIN
> >
> > -- gil
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> 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

[Paul Gilmartin]

On Mon, 4 Oct 2021 14:46:50 -0400, Bob Bridges wrote:

>I find that a lot, that tech-support people are fine with alpha-bravo-charlie. 
> Most other people have to think about it; one is reduced to saying "em as in 
>mike, vee as in victor, ess as in sierra" and so on. 
>
Emergency responders haven't time for that.

>... I'm long supposed that tech-support people, and their ilk (sysprogs 
> for instance), often have to spell things so they've acquainted themselves 
> with a good way of doing it.
>
When I got in the field, I heard Able, Baker,Charlie, Dog, Eazy, Fox.  (WWII?)
That's all that was needed.

>... (There's an ASCII adaptation of the IPA that's actually pretty handy.  
> Only problem is, no one's ever seen it, except a few of us geeks.  If we all 
> understood that you could have written "/aI Ef ti/", without fear of 
> ambiguity.)
>
But no good for audio.  If I need to spell something out for local authorities,
I use the modal NATO codes.  I don't carry all their wallet cards.

-- gil

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

Re: [EXTERNAL] Re: PL/I vs. JCL

[Seymour J Metz]

The TMP does not run in the TCAS.


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



From: IBM Mainframe Discussion List  on behalf of 
Pommier, Rex 
Sent: Monday, October 4, 2021 5:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [EXTERNAL] Re: PL/I vs. JCL

I believe what Skip was referring to was the actual TSO TMP, i.e. the TSO 
address space or TCAS.  The TSO READY prompt or an edit session are actually 
being run in the separate TSO address space that TCAS created on my behalf.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Joe 
Monk
Sent: Monday, October 4, 2021 3:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: PL/I vs. JCL

"TSO/E OTOH gives each user her own address space with support directly from 
the OS. 'TSO' handles only logon/logoff. Like CICS."

Oh really? So where does the READY prompt come from before you hop into PDF? 
And what happens if you type EDIT 'DSNAME'? Whats running the EDIT program?

Joe

On Mon, Oct 4, 2021 at 1:35 PM Skip Robinson 
wrote:

> I've never actually encountered 'time sharing' in the flesh, but my
> understanding is that it involve(s/d) a single address space that
> multiple users logged on to. The monitor (or whatever the top dog was
> called) would divvy up resources among users and dispatch them. In
> other words, it looked a lot like modern CICS. TSO/E OTOH gives each
> user her own address space with support directly from the OS. 'TSO'
> handles only logon/logoff. Like CICS.
>
> On Mon, Oct 4, 2021 at 6:40 AM Bob Bridges  wrote:
>
> > Just to pick nits, it seems to me that time-sharing is alive and
> > well on all mainframes, and especially in TSO.  The whole point of
> > TSO was that multiple users could be on-line simultaneously, which
> > hadn't always been the case.  TSO allowed us to log on, and stay on,
> > and do foreground work without interfering with each other.  And it
> > still does, although we now take it for granted.
> >
> > ...So I have always understood, at any rate.
> >
> > ---
> > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> >
> > /* ...the Rock Bottom Remaindersemploy two powerful musical
> > weapons when we perform ["Wild Thing"].  One is Roy Blount Jr., a
> > great humor writer who has the raw natural musical talent of a
> > soldering ironwhen we get to the end of the first verse, we
> > stop, and everybody turns expectantly to Roy, waiting for him to say
> > "I love you," and Roy,
> frowning
> > with deep concentration, inevitably says: "You move me."  And then
> > the
> rest
> > of us, in a smooth professional manner, stagger around and try not
> > to wet our pants.  -Dave Barry, rock guitarist */
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of Skip Robinson
> > Sent: Sunday, October 3, 2021 12:37
> >
> > My favorite basket case is 'TSO', which was in ancient history Time
> > Sharing Option. For as long as anyone can remember, TSO has not
> > involved 'time sharing' in any meaningful way. Nor is it remotely optional.
> Spelling
> > out the words contributes nothing to any discussion.
> >
> >
> --
>
> 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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


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

Not a coincidence.


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



From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Monday, October 4, 2021 8:47 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

On Mon, 4 Oct 2021 18:41:26 +, Seymour J Metz wrote:

>TSO originally supported up to 15 regions, and had its own swap dataset. This 
>continued with SVS.
>
Is that,  coincidentally, the same as the number of page protection keys?

> ... With OS/VS2 R2, each user had its own address space and the same code 
> handled swapping for batch and TSO.

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

[Paul Gilmartin]

On Mon, 4 Oct 2021 18:41:26 +, Seymour J Metz wrote:

>TSO originally supported up to 15 regions, and had its own swap dataset. This 
>continued with SVS.  
>
Is that,  coincidentally, the same as the number of page protection keys?

> ... With OS/VS2 R2, each user had its own address space and the same code 
> handled swapping for batch and TSO.

-- 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 Mon, 4 Oct 2021 11:34:38 -0700, Skip Robinson wrote:

>I've never actually encountered 'time sharing' in the flesh, but my
>understanding is that it involve(s/d) a single address space that multiple
>users logged on to. The monitor (or whatever the top dog was called) would
>divvy up resources among users and dispatch them.  ...
>
OMVS does that if _BPX_SHAREAS=YES.  (Well, for processes, not users.)
And even ATTACH operates similarrly.

Sophistry, anyone?

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

[Mike Schwab]

U.S.S.  Unformated System Services, until Unix System Services tried
to take it over.

On Tue, Oct 5, 2021 at 1:24 AM Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>
> On Mon, 4 Oct 2021 17:35:41 +, Seymour J Metz wrote:
>
> >While TSO does not support unambiguous truncation for command names, it does 
> >for keywords. I don't know about ICCF.
> >
> Unambiguous truncation is treacherous.  Addition of new commands/keywords can 
> break
> legacy art.  For that reason I eschew abbreviations in code and pedagogy.  
> The worst
> case occurs when one command is a proper prefix of another command.
>
> I freely abbreviate on a command line.
>
> 
> On Sat, 2 Oct 2021 20:56:43 -0700, Charles Mills wrote:
> >I have no problem with the DD/member ambiguity:
> >\edu with the message: INFO IBM-MAIN
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
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 Mon, 4 Oct 2021 17:35:41 +, Seymour J Metz wrote:

>While TSO does not support unambiguous truncation for command names, it does 
>for keywords. I don't know about ICCF.
>
Unambiguous truncation is treacherous.  Addition of new commands/keywords can 
break
legacy art.  For that reason I eschew abbreviations in code and pedagogy.  The 
worst
case occurs when one command is a proper prefix of another command.

I freely abbreviate on a command line.


On Sat, 2 Oct 2021 20:56:43 -0700, Charles Mills wrote:
>I have no problem with the DD/member ambiguity:
>\edu with the message: INFO IBM-MAIN

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

[CM Poncelet]

able baker charlie dog easy fox

On 04/10/2021 15:10, Paul Gilmartin wrote:
> On Mon, 4 Oct 2021 09:35:39 -0400, Bob Bridges wrote:
>
>> Ok, I give up.  I have favorite-newscaster stories, too, but I don't get 
>> this one.  What's an EFT cargo hatch?  Is this so obvious a failure that 
>> I'll be required by law to kick myself when it's explained to me, or 
>> something that only pilots know, or what?
>>
> I struggled for vernacular phonetic vowel names and apparently failed.
>
> If the newscaster had been an aviator he couldd have said Alfa Foxtrot Tango.
> But an aviator or a mariner wouldn't have needed to.
>
> I believe he said in defense that it appeared in caps in his script.  But if 
> that
> came off a teletype everything would have been caps.
>
> I once recited a serial number to Tech Support using NATO phonetic alphabet.
> She understood immediately; no request for clarification.  Perhaps she was
> a veteran.  Why can't local emergency services concur on a phonetic alphabet?
>
> -- 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: [EXTERNAL] Re: PL/I vs. JCL

[Pommier, Rex]

I believe what Skip was referring to was the actual TSO TMP, i.e. the TSO 
address space or TCAS.  The TSO READY prompt or an edit session are actually 
being run in the separate TSO address space that TCAS created on my behalf.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Joe 
Monk
Sent: Monday, October 4, 2021 3:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: PL/I vs. JCL

"TSO/E OTOH gives each user her own address space with support directly from 
the OS. 'TSO' handles only logon/logoff. Like CICS."

Oh really? So where does the READY prompt come from before you hop into PDF? 
And what happens if you type EDIT 'DSNAME'? Whats running the EDIT program?

Joe

On Mon, Oct 4, 2021 at 1:35 PM Skip Robinson 
wrote:

> I've never actually encountered 'time sharing' in the flesh, but my 
> understanding is that it involve(s/d) a single address space that 
> multiple users logged on to. The monitor (or whatever the top dog was 
> called) would divvy up resources among users and dispatch them. In 
> other words, it looked a lot like modern CICS. TSO/E OTOH gives each 
> user her own address space with support directly from the OS. 'TSO' 
> handles only logon/logoff. Like CICS.
>
> On Mon, Oct 4, 2021 at 6:40 AM Bob Bridges  wrote:
>
> > Just to pick nits, it seems to me that time-sharing is alive and 
> > well on all mainframes, and especially in TSO.  The whole point of 
> > TSO was that multiple users could be on-line simultaneously, which 
> > hadn't always been the case.  TSO allowed us to log on, and stay on, 
> > and do foreground work without interfering with each other.  And it 
> > still does, although we now take it for granted.
> >
> > ...So I have always understood, at any rate.
> >
> > ---
> > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> >
> > /* ...the Rock Bottom Remaindersemploy two powerful musical 
> > weapons when we perform ["Wild Thing"].  One is Roy Blount Jr., a 
> > great humor writer who has the raw natural musical talent of a 
> > soldering ironwhen we get to the end of the first verse, we 
> > stop, and everybody turns expectantly to Roy, waiting for him to say 
> > "I love you," and Roy,
> frowning
> > with deep concentration, inevitably says: "You move me."  And then 
> > the
> rest
> > of us, in a smooth professional manner, stagger around and try not 
> > to wet our pants.  -Dave Barry, rock guitarist */
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On 
> > Behalf Of Skip Robinson
> > Sent: Sunday, October 3, 2021 12:37
> >
> > My favorite basket case is 'TSO', which was in ancient history Time 
> > Sharing Option. For as long as anyone can remember, TSO has not 
> > involved 'time sharing' in any meaningful way. Nor is it remotely optional.
> Spelling
> > out the words contributes nothing to any discussion.
> >
> >
> --
>
> 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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


--
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 includes a terminal control address space (TCAS) that handles LOGON/LOGOFF, 
a VTAM I/O control (VTIOC) address space that talks to VTAM, a terminal monitor 
program that runs in the user's address space, a bunch of command processors 
(CPs) that run as subtasks of the TM and service routines used by the CPs and 
TMP.


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



From: IBM Mainframe Discussion List  on behalf of Joe 
Monk 
Sent: Monday, October 4, 2021 4:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

"TSO/E OTOH gives each user her own address space
with support directly from the OS. 'TSO' handles only logon/logoff. Like
CICS."

Oh really? So where does the READY prompt come from before you hop into
PDF? And what happens if you type EDIT 'DSNAME'? Whats running the EDIT
program?

Joe

On Mon, Oct 4, 2021 at 1:35 PM Skip Robinson 
wrote:

> I've never actually encountered 'time sharing' in the flesh, but my
> understanding is that it involve(s/d) a single address space that multiple
> users logged on to. The monitor (or whatever the top dog was called) would
> divvy up resources among users and dispatch them. In other words, it looked
> a lot like modern CICS. TSO/E OTOH gives each user her own address space
> with support directly from the OS. 'TSO' handles only logon/logoff. Like
> CICS.
>
> On Mon, Oct 4, 2021 at 6:40 AM Bob Bridges  wrote:
>
> > Just to pick nits, it seems to me that time-sharing is alive and well on
> > all mainframes, and especially in TSO.  The whole point of TSO was that
> > multiple users could be on-line simultaneously, which hadn't always been
> > the case.  TSO allowed us to log on, and stay on, and do foreground work
> > without interfering with each other.  And it still does, although we now
> > take it for granted.
> >
> > ...So I have always understood, at any rate.
> >
> > ---
> > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> >
> > /* ...the Rock Bottom Remaindersemploy two powerful musical weapons
> > when we perform ["Wild Thing"].  One is Roy Blount Jr., a great humor
> > writer who has the raw natural musical talent of a soldering ironwhen
> > we get to the end of the first verse, we stop, and everybody turns
> > expectantly to Roy, waiting for him to say "I love you," and Roy,
> frowning
> > with deep concentration, inevitably says: "You move me."  And then the
> rest
> > of us, in a smooth professional manner, stagger around and try not to wet
> > our pants.  -Dave Barry, rock guitarist */
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of Skip Robinson
> > Sent: Sunday, October 3, 2021 12:37
> >
> > My favorite basket case is 'TSO', which was in ancient history Time
> > Sharing Option. For as long as anyone can remember, TSO has not involved
> > 'time sharing' in any meaningful way. Nor is it remotely optional.
> Spelling
> > out the words contributes nothing to any discussion.
> >
> >
> --
>
> 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

[Joe Monk]

"TSO/E OTOH gives each user her own address space
with support directly from the OS. 'TSO' handles only logon/logoff. Like
CICS."

Oh really? So where does the READY prompt come from before you hop into
PDF? And what happens if you type EDIT 'DSNAME'? Whats running the EDIT
program?

Joe

On Mon, Oct 4, 2021 at 1:35 PM Skip Robinson 
wrote:

> I've never actually encountered 'time sharing' in the flesh, but my
> understanding is that it involve(s/d) a single address space that multiple
> users logged on to. The monitor (or whatever the top dog was called) would
> divvy up resources among users and dispatch them. In other words, it looked
> a lot like modern CICS. TSO/E OTOH gives each user her own address space
> with support directly from the OS. 'TSO' handles only logon/logoff. Like
> CICS.
>
> On Mon, Oct 4, 2021 at 6:40 AM Bob Bridges  wrote:
>
> > Just to pick nits, it seems to me that time-sharing is alive and well on
> > all mainframes, and especially in TSO.  The whole point of TSO was that
> > multiple users could be on-line simultaneously, which hadn't always been
> > the case.  TSO allowed us to log on, and stay on, and do foreground work
> > without interfering with each other.  And it still does, although we now
> > take it for granted.
> >
> > ...So I have always understood, at any rate.
> >
> > ---
> > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> >
> > /* ...the Rock Bottom Remaindersemploy two powerful musical weapons
> > when we perform ["Wild Thing"].  One is Roy Blount Jr., a great humor
> > writer who has the raw natural musical talent of a soldering ironwhen
> > we get to the end of the first verse, we stop, and everybody turns
> > expectantly to Roy, waiting for him to say "I love you," and Roy,
> frowning
> > with deep concentration, inevitably says: "You move me."  And then the
> rest
> > of us, in a smooth professional manner, stagger around and try not to wet
> > our pants.  -Dave Barry, rock guitarist */
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of Skip Robinson
> > Sent: Sunday, October 3, 2021 12:37
> >
> > My favorite basket case is 'TSO', which was in ancient history Time
> > Sharing Option. For as long as anyone can remember, TSO has not involved
> > 'time sharing' in any meaningful way. Nor is it remotely optional.
> Spelling
> > out the words contributes nothing to any discussion.
> >
> >
> --
>
> 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

[Bob Bridges]

I find that a lot, that tech-support people are fine with alpha-bravo-charlie.  
Most other people have to think about it; one is reduced to saying "em as in 
mike, vee as in victor, ess as in sierra" and so on.  I'm long supposed that 
tech-support people, and their ilk (sysprogs for instance), often have to spell 
things so they've acquainted themselves with a good way of doing it.

I did notice, ~after~ I wrote the question, that you'd written "eh-eff-tee", 
not "ee-eff-tee".  Didn't figure it out, though, even then.  I'd have tried for 
"ay-eff-tee", but that's 'way too likely to be misread as "aye-eff-tee".

(There's an ASCII adaptation of the IPA that's actually pretty handy.  Only 
problem is, no one's ever seen it, except a few of us geeks.  If we all 
understood that you could have written "/aI Ef ti/", without fear of ambiguity.)

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

/* I would as soon write free verse as play tennis with the net down.  -Robert 
Frost */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Monday, October 4, 2021 10:11

I struggled for vernacular phonetic vowel names and apparently failed.

If the newscaster had been an aviator he couldd have said Alfa Foxtrot Tango.
But an aviator or a mariner wouldn't have needed to.

I believe he said in defense that it appeared in caps in his script.  But if 
that came off a teletype everything would have been caps.

I once recited a serial number to Tech Support using NATO phonetic alphabet.
She understood immediately; no request for clarification.  Perhaps she was a 
veteran.  Why can't local emergency services concur on a phonetic alphabet?

--- On Mon, 4 Oct 2021 09:35:39 -0400, Bob Bridges wrote:
>Ok, I give up.  I have favorite-newscaster stories, too, but I don't get this 
>one.  What's an EFT cargo hatch?  Is this so obvious a failure that I'll be 
>required by law to kick myself when it's explained to me, or something that 
>only pilots know, or what?

--
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 originally supported up to 15 regions, and had its own swap dataset. This 
continued with SVS.  With OS/VS2 R2, each user had its own address space and 
the same code handled swapping for batch and TSO.


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



From: IBM Mainframe Discussion List  on behalf of 
Skip Robinson 
Sent: Monday, October 4, 2021 2:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

I've never actually encountered 'time sharing' in the flesh, but my
understanding is that it involve(s/d) a single address space that multiple
users logged on to. The monitor (or whatever the top dog was called) would
divvy up resources among users and dispatch them. In other words, it looked
a lot like modern CICS. TSO/E OTOH gives each user her own address space
with support directly from the OS. 'TSO' handles only logon/logoff. Like
CICS.

On Mon, Oct 4, 2021 at 6:40 AM Bob Bridges  wrote:

> Just to pick nits, it seems to me that time-sharing is alive and well on
> all mainframes, and especially in TSO.  The whole point of TSO was that
> multiple users could be on-line simultaneously, which hadn't always been
> the case.  TSO allowed us to log on, and stay on, and do foreground work
> without interfering with each other.  And it still does, although we now
> take it for granted.
>
> ...So I have always understood, at any rate.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* ...the Rock Bottom Remaindersemploy two powerful musical weapons
> when we perform ["Wild Thing"].  One is Roy Blount Jr., a great humor
> writer who has the raw natural musical talent of a soldering ironwhen
> we get to the end of the first verse, we stop, and everybody turns
> expectantly to Roy, waiting for him to say "I love you," and Roy, frowning
> with deep concentration, inevitably says: "You move me."  And then the rest
> of us, in a smooth professional manner, stagger around and try not to wet
> our pants.  -Dave Barry, rock guitarist */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Skip Robinson
> Sent: Sunday, October 3, 2021 12:37
>
> My favorite basket case is 'TSO', which was in ancient history Time
> Sharing Option. For as long as anyone can remember, TSO has not involved
> 'time sharing' in any meaningful way. Nor is it remotely optional. Spelling
> out the words contributes nothing to any discussion.
>
>
--

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

[Skip Robinson]

I've never actually encountered 'time sharing' in the flesh, but my
understanding is that it involve(s/d) a single address space that multiple
users logged on to. The monitor (or whatever the top dog was called) would
divvy up resources among users and dispatch them. In other words, it looked
a lot like modern CICS. TSO/E OTOH gives each user her own address space
with support directly from the OS. 'TSO' handles only logon/logoff. Like
CICS.

On Mon, Oct 4, 2021 at 6:40 AM Bob Bridges  wrote:

> Just to pick nits, it seems to me that time-sharing is alive and well on
> all mainframes, and especially in TSO.  The whole point of TSO was that
> multiple users could be on-line simultaneously, which hadn't always been
> the case.  TSO allowed us to log on, and stay on, and do foreground work
> without interfering with each other.  And it still does, although we now
> take it for granted.
>
> ...So I have always understood, at any rate.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* ...the Rock Bottom Remaindersemploy two powerful musical weapons
> when we perform ["Wild Thing"].  One is Roy Blount Jr., a great humor
> writer who has the raw natural musical talent of a soldering ironwhen
> we get to the end of the first verse, we stop, and everybody turns
> expectantly to Roy, waiting for him to say "I love you," and Roy, frowning
> with deep concentration, inevitably says: "You move me."  And then the rest
> of us, in a smooth professional manner, stagger around and try not to wet
> our pants.  -Dave Barry, rock guitarist */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Skip Robinson
> Sent: Sunday, October 3, 2021 12:37
>
> My favorite basket case is 'TSO', which was in ancient history Time
> Sharing Option. For as long as anyone can remember, TSO has not involved
> 'time sharing' in any meaningful way. Nor is it remotely optional. Spelling
> out the words contributes nothing to any discussion.
>
>
-- 

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]

The userid is normally an alias for a user catalog, and I would not expect 
anybody to use it as a dsname in a TSO command. Similarly, most installations 
don't allow cataloging datasets in the master catalog, so I wouldn't expect 
there to be a conflict between dsname and member, only between ddname and 
member.

YMMV


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



From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Saturday, October 2, 2021 9:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

No, I think it's possible (though unlikely) for a string to represent both
at the same time.  If nothing else, the TSO alias that's used to catalogue
my datasets is a dataset, sort of, isn't it?  So if I allocate a DD named
BBRIDGE, and then ask DSDD about BBRIDGE, it would at that time be both a
dataset and a DD.  But even if LISTDSI doesn't see a TSO alias as a dataset,
there can be DSNs with just one node.

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

/* If you think education is expensive, try ignorance.  -Derek Bok,
President, Harvard University */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Seymour J Metz
Sent: Friday, October 1, 2021 10:41

Can you guarant[ee] that there will never be a name that is used for both a
member and a ddname?


From: IBM Mainframe Discussion List  on behalf of
Bob Bridges 
Sent: Friday, October 1, 2021 9:21 AM

a function DSDD that receives a string and returns a code telling
whether the string represents a catalogued DS, an allocated DD, or both, or
neither

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

While TSO does not support unambiguous truncation for command names, it does 
for keywords. I don't know about ICCF.


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



From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, October 3, 2021 9:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

On Sat, 2 Oct 2021 20:56:43 -0700, Charles Mills wrote:

>I have no problem with the DD/member ambiguity:
>
>1. If it's a personal tool and you are happy with the ambiguity, then you
>are happy.
>2. If it's a "product" then you just document which takes priority.
>
o z/VM CP and CMS with their very flat syntax (no delimiters) allow keywords
  to be elided when their values do not overload other keyword names.  And
  some operands are required for admin users and optional or prohibited for
  general users.  And VM nerds delight in abbreviating keywords and command
  names to single characters, baffling novices.  Ugh!

o UNIX command options can be ambiguous with (non-portable?) filenames
  beginning with "-".  The resolution is to qualify with current working 
directory:
  "./-whatever".

I don't abbreviate in documentation or discussion.  I write ALLOCATE, not
ALLOC; TRANSMIT, not XMIT; etc.  (Oops!  I wrote "admin" above.)

>I wrote a (successful!) product that in one very peripheral feature took an
>operand that could represent a member name in a default PDS, a dataset name,
>or a zFS file name. I differentiated among the three based on length and the
>presence or absence of periods and/or slashes. No one ever complained that
>they had a dataset or a zFS file named SHORTNAM and could not reference it.
>I think the convenience and simplicity of being able to say simply
>FILENAME(whatever) outweighed the perils of the ambiguity. Product design
>involves tradeoffs.

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

The ironic thing is that for decades major corporations have been legally 
changing their names to only the initials of the old name.


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



From: IBM Mainframe Discussion List  on behalf of 
Skip Robinson 
Sent: Sunday, October 3, 2021 12:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

Newbie auditors are notorious for 'spelling out' abbreviations that over
the decades have become actual names. And yes, idiocy is only one
consequence. The result can be gibberish.

My favorite basket case is 'TSO', which was in ancient history Time Sharing
Option. For as long as anyone can remember, TSO has not involved 'time
sharing' in any meaningful way. Nor is it remotely optional. Spelling out
the words contributes nothing to any discussion.

Another favorite is 'JES'. Nobody spells it out. Nor 'RACF', which everyone
says as rack+f.

On Sun, Oct 3, 2021 at 6:59 AM Charles Mills  wrote:

> > I don't abbreviate in documentation or discussion.
>
> Hmmm. I think referring to the console command P resonates with people
> more than STOP. I wonder if people do not recognize XMIT better than
> TRANSMIT. The goal in documentation should be clarity,  not pedagogics.
>
> I once had an all-out war (I won! I was the president!) with a tech writer
> who insisted that the documentation should spell out Multiple Virtual
> Systems on the first reference to MVS (in technical documentation for a
> hardcore mainframe product). My position was that it made us look like
> idiots.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Sunday, October 3, 2021 6:23 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I vs. JCL
>
> On Sat, 2 Oct 2021 20:56:43 -0700, Charles Mills wrote:
>
> >I have no problem with the DD/member ambiguity:
> >
> >1. If it's a personal tool and you are happy with the ambiguity, then you
> >are happy.
> >2. If it's a "product" then you just document which takes priority.
> >
> o z/VM CP and CMS with their very flat syntax (no delimiters) allow
> keywords
>   to be elided when their values do not overload other keyword names.  And
>   some operands are required for admin users and optional or prohibited for
>   general users.  And VM nerds delight in abbreviating keywords and command
>   names to single characters, baffling novices.  Ugh!
>
> o UNIX command options can be ambiguous with (non-portable?) filenames
>   beginning with "-".  The resolution is to qualify with current working
> directory:
>   "./-whatever".
>
> I don't abbreviate in documentation or discussion.  I write ALLOCATE, not
> ALLOC; TRANSMIT, not XMIT; etc.  (Oops!  I wrote "admin" above.)
>
> >I wrote a (successful!) product that in one very peripheral feature took
> an
> >operand that could represent a member name in a default PDS, a dataset
> name,
> >or a zFS file name. I differentiated among the three based on length and
> the
> >presence or absence of periods and/or slashes. No one ever complained that
> >they had a dataset or a zFS file named SHORTNAM and could not reference
> it.
> >I think the convenience and simplicity of being able to say simply
> >FILENAME(whatever) outweighed the perils of the ambiguity. Product design
> >involves tradeoffs.
>
> -- gil
>
>
>
--

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]

TSO doesn't do time slicing in MVS; that's up to the dispatcher and SRM (WLM), 
Similar, TSO doesn't do swapping in MVS.

Only in MVT, 65MP and SVS were the first two letters relevant.
























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



From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, October 3, 2021 1:22 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

On Sun, 3 Oct 2021 09:37:00 -0700, Skip Robinson wrote:

>Newbie auditors are notorious for 'spelling out' abbreviations that over
>the decades have become actual names. And yes, idiocy is only one
>consequence. The result can be gibberish.
>
A long time favorite is a local newscaster who read a story attributing
a DC-10 crash to a failure of an "eh-eff-tee cargo hatch."

>My favorite basket case is 'TSO', which was in ancient history Time Sharing
>Option. For as long as anyone can remember, TSO has not involved 'time
>sharing' in any meaningful way.
>
What would you say?  "Time Slicing"?  "Divided Property Ownership"?

>... Nor is it remotely optional. Spelling out
>the words contributes nothing to any discussion.
>
So you pronounce it as in "General TSO's Chicken"?

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

Ignoring the question of whether i and p are mainframes, that doesn't 
distinguish between the OS/360 line, the DOS/369 line, the CP-67 line or the 
defunct lines like AIX, DPPX and TSS.

Wiki has articles OS/360 and successors and DOS/360 and successor, which convey 
the semantics even if they are a bit long winded.


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



From: IBM Mainframe Discussion List  on behalf of 
Skip Robinson 
Sent: Sunday, October 3, 2021 3:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

Having wrestled with this issue for decades, I've come to adopt Mainframe
as a generic term that most people recognize. (Ignoring the technowienies
that debate the term endlessly.) No one argues with the term or even
questions it. It covers hardware and software. You can use other terms if
you need to get more specific.

On Sun, Oct 3, 2021 at 11:34 AM Charles Mills  wrote:

> Agreed. Saying MVS makes you look old-fashioned, even though MVS still
> exists (I guess?) as a component of z/OS. Saying z/OS is limiting.
>
> Ditto for the hardware. It is a little wordy to say "I have been writing
> assembler for the S/360, S370, S/390 and z." (And I guess now Telum?)
>
> Does that name lead to a who's on first dialog?
>
> "What's that new IBM chip called?"
> "Telum"
> "I'd like to tell 'em, but I don't know what it's called."
> "Telum"
> "Tell 'em what?"
> "The name of the chip."
> "I don't know the name of the chip."
> "Telum"
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Sunday, October 3, 2021 10:50 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I vs. JCL
>
> On Sun, 3 Oct 2021 06:58:42 -0700, Charles Mills  wrote:
> >
> >I once had an all-out war (I won! I was the president!) with a tech
> writer who insisted that the documentation should spell out Multiple
> Virtual Systems on the first reference to MVS (in technical documentation
> for a hardcore mainframe product). My position was that it made us look
> like idiots.
> >
> BTW, is there a convenient term embracing the line of OSes, OS/360, MVT,
> OS/390, z/OS,
> and all those others?  I don't like to say "MVS" when I wish to include
> the pre-virtual
> systems, and I don't like to say "OS/360" when I wish to include z/OS.
>
> --

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

[Paul Gilmartin]

On Mon, 4 Oct 2021 10:49:10 -0400, Phil Smith III wrote:
>
>? Limiting how? If you mean "z/OS and predecessors", that's always worked
>for me. Yes, MVS is a component of z/OS, as is USS. (Hey, let's debate "USS"
>again-no, wait, let's not.)
>
USS is a component of z/OS.  And BSD UNIX is a predecessor of USS
(I believe.)  Does that make BSD a predecessor of z/OS?  Can we get
DNA samples?

-- gil

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

Re: [EXTERNAL] Re: PL/I vs. JCL

[Pommier, Rex]

Bob,

Think Canadian - "eh"=A.  :-)  The back door lock either broke or somebody 
forgot to close it.

Rex

On 10/4/2021 6:35 AM, Bob Bridges wrote:
> Ok, I give up.  I have favorite-newscaster stories, too, but I don't get this 
> one.  What's an EFT cargo hatch?  Is this so obvious a failure that I'll be 
> required by law to kick myself when it's explained to me, or something that 
> only pilots know, or what?
> 
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> 
> /* By definition, a government has no conscience. Sometimes it has a 
> policy, but nothing more.  -Albert Camus */
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Paul Gilmartin
> Sent: Sunday, October 3, 2021 13:22
> 
> --- On Sun, 3 Oct 2021 09:37:00 -0700, Skip Robinson wrote:
> A long time favorite is a local newscaster who read a story attributing a 
> DC-10 crash to a failure of an "eh-eff-tee cargo hatch."
> 
> --
> 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

--
The information contained in this message is confidential, protected from 
disclosure and may be legally privileged. If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful. If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format. Thank you.


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

[Tom Brennan]

eh = A
AFT = Aft

On 10/4/2021 6:35 AM, Bob Bridges wrote:

Ok, I give up.  I have favorite-newscaster stories, too, but I don't get this 
one.  What's an EFT cargo hatch?  Is this so obvious a failure that I'll be 
required by law to kick myself when it's explained to me, or something that 
only pilots know, or what?

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

/* By definition, a government has no conscience. Sometimes it has a policy, 
but nothing more.  -Albert Camus */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Sunday, October 3, 2021 13:22

--- On Sun, 3 Oct 2021 09:37:00 -0700, Skip Robinson wrote:
A long time favorite is a local newscaster who read a story attributing a DC-10 crash to 
a failure of an "eh-eff-tee cargo hatch."

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

[Phil Smith III]

Charles wrote:

>Saying MVS makes you look old-fashioned, even though MVS still exists 

>(I guess?) as a component of z/OS. Saying z/OS is limiting.

 

? Limiting how? If you mean "z/OS and predecessors", that's always worked
for me. Yes, MVS is a component of z/OS, as is USS. (Hey, let's debate "USS"
again-no, wait, let's not.)

 

>Ditto for the hardware. It is a little wordy to say "I have been writing 

>assembler for the S/360, S370, S/390 and z."

 

Same approach: "IBM Z and predecessors".

 

Skip Robinson wrote:

>Having wrestled with this issue for decades, I've come to adopt Mainframe
>as a generic term that most people recognize. (Ignoring the technowienies
>that debate the term endlessly.) No one argues with the term or even
>questions it. It covers hardware and software. You can use other terms if
>you need to get more specific.

 

That assumes z/OS is the only mainframe OS, which it certainly isn't. An
imprecision that leads to confusion-only z/OS folks think it's appropriate,
nobody else does. Plus I keep finding folks who think a CDC system or even
an IBM i is a "mainframe". Nope, I strongly believe in using the correct
term, "IBM Z", for the hardware; "z/OS" (or "z/VM", "z/VSE", "z/TPF", "Linux
for IBM Z") for the OS in question (plus maybe whatever's left of MUMPS
these days, if anything, and a few others, but they're pretty well all dead,
other than the Fujitsu mutant z/OS thing).

 

And of course most people don't come close to getting this right: how often
do you still hear "AS/400", a platform that's been dead for over two decades
AND whose descendants have been renamed repeatedly to boot (iSeries, System
i, now IBM i). Or "PowerPC" for Power. I keep explaining to people that
that's like calling your Core i9 laptop a "386": sorta kinda vaguely
reminiscent of being, but mostly just wrong.


--
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 Mon, 4 Oct 2021 13:41:54 +, Cameron Conacher wrote:

>Honestly, I do not know, but I read it as A F T cargo hatch.
> 
I guess only the Irish can understand each other.


On Mon, 4 Oct 2021 14:05:36 +, Pew, Curtis G wrote:

> ... “MVS datasets” ...
>
ITYM “MVS data sets” 

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

[Charles Mills]

Multiple Virtual Storage
Multiple Virtual Storage
Multiple Virtual Storage
Multiple Virtual Storage
Multiple Virtual Storage
Multiple Virtual Storage

I'm writing that on the blackboard 100 times.

Charles


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

Charles Mills  wrote:
>I once had an all-out war (I won! I was the president!) with a tech writer
who insisted that the

>documentation should spell out Multiple Virtual Systems on the first
reference to MVS (in technical 

>documentation for a hardcore mainframe product). My position was that it
made us look like idiots.

 

Might have been the same writer who we had to order to STOP changing
"filename" to "file name" and "userid" to "user identifier" in
VM documentation. Know your audience!

 

However, I would have stopped yours even earlier on the grounds that MVS
stands for "Multiple Virtual Storage", not ".Systems". Just
sayin'.

--
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 Mon, 4 Oct 2021 09:35:39 -0400, Bob Bridges wrote:

>Ok, I give up.  I have favorite-newscaster stories, too, but I don't get this 
>one.  What's an EFT cargo hatch?  Is this so obvious a failure that I'll be 
>required by law to kick myself when it's explained to me, or something that 
>only pilots know, or what?
> 
I struggled for vernacular phonetic vowel names and apparently failed.

If the newscaster had been an aviator he couldd have said Alfa Foxtrot Tango.
But an aviator or a mariner wouldn't have needed to.

I believe he said in defense that it appeared in caps in his script.  But if 
that
came off a teletype everything would have been caps.

I once recited a serial number to Tech Support using NATO phonetic alphabet.
She understood immediately; no request for clarification.  Perhaps she was
a veteran.  Why can't local emergency services concur on a phonetic alphabet?

-- 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 Oct 3, 2021, at 1:34 PM, Charles Mills  wrote:
> 
> Agreed. Saying MVS makes you look old-fashioned, even though MVS still exists 
> (I guess?) as a component of z/OS. Saying z/OS is limiting.

Lots of IBM manuals still say MVS when talking about that component. I find it 
convenient, for example, to distinguish “MVS datasets” from “Unix files”. 
They’re both part of z/OS.

I’ve explained it to people as being like Darwin and macOS. Every macOS (since 
macOS X) is built on Darwin, Apple’s fork of FreeBSD, so you can’t get macOS 
without getting Darwin too. And since, unlike MVS, Darwin is open source you 
*could* run it without all of macOS, no one ever does.

This was perhaps clearer with OS/390, which IBM explicitly positioned as an 
integrated package of components you previously could get separately.


-- 
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: PL/I vs. JCL

[Cameron Conacher]

Honestly, I do not know, but I read it as A F T cargo hatch.
As in the south end of a north bound developer.

Thanks,

…….Cameron




-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Monday, October 4, 2021 9:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: PL/I vs. JCL

Ok, I give up.  I have favorite-newscaster stories, too, but I don't get this 
one.  What's an EFT cargo hatch?  Is this so obvious a failure that I'll be 
required by law to kick myself when it's explained to me, or something that 
only pilots know, or what?

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

/* By definition, a government has no conscience. Sometimes it has a policy, 
but nothing more.  -Albert Camus */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Sunday, October 3, 2021 13:22

--- On Sun, 3 Oct 2021 09:37:00 -0700, Skip Robinson wrote:
A long time favorite is a local newscaster who read a story attributing a DC-10 
crash to a failure of an "eh-eff-tee cargo hatch."

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

American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a été envoyé par un représentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les expéditeurs par courriel.

Ce courriel est réservé au seul destinataire indiqué et peut renfermer des 
renseignements confidentiels et privilégiés. Si vous n’êtes pas le destinataire 
prévu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez reçu ce courriel par erreur, veuillez en aviser 
l’expéditeur par courriel et détruire immédiatement le courriel et toute pièce 
jointe. Merci.

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

Just to pick nits, it seems to me that time-sharing is alive and well on all 
mainframes, and especially in TSO.  The whole point of TSO was that multiple 
users could be on-line simultaneously, which hadn't always been the case.  TSO 
allowed us to log on, and stay on, and do foreground work without interfering 
with each other.  And it still does, although we now take it for granted.

...So I have always understood, at any rate.

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

/* ...the Rock Bottom Remaindersemploy two powerful musical weapons when we 
perform ["Wild Thing"].  One is Roy Blount Jr., a great humor writer who has 
the raw natural musical talent of a soldering ironwhen we get to the end of 
the first verse, we stop, and everybody turns expectantly to Roy, waiting for 
him to say "I love you," and Roy, frowning with deep concentration, inevitably 
says: "You move me."  And then the rest of us, in a smooth professional manner, 
stagger around and try not to wet our pants.  -Dave Barry, rock guitarist */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Skip Robinson
Sent: Sunday, October 3, 2021 12:37

My favorite basket case is 'TSO', which was in ancient history Time Sharing 
Option. For as long as anyone can remember, TSO has not involved 'time sharing' 
in any meaningful way. Nor is it remotely optional. Spelling out the words 
contributes nothing to any discussion.

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

Ok, I give up.  I have favorite-newscaster stories, too, but I don't get this 
one.  What's an EFT cargo hatch?  Is this so obvious a failure that I'll be 
required by law to kick myself when it's explained to me, or something that 
only pilots know, or what?

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

/* By definition, a government has no conscience. Sometimes it has a policy, 
but nothing more.  -Albert Camus */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Sunday, October 3, 2021 13:22

--- On Sun, 3 Oct 2021 09:37:00 -0700, Skip Robinson wrote:
A long time favorite is a local newscaster who read a story attributing a DC-10 
crash to a failure of an "eh-eff-tee cargo hatch."

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

I have long told recruiters that the generic name for that whole line of 
operating systems is "MVS", in the same way that "Windows" denotes lots of old 
versions and not just the ones with "Windows" in the name.  As an Official Old 
Guy I've said "MVS" for years even when we're talking about z/OS, ESA or 
whatever.

I usually made that assertion with confidence, but the confidence has eroded 
somewhat in the last ten years.  I'm not sure I was ~ever~ right about that; 
maybe I'm the only one who used it that way.

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

/* A thousand pages of hobbits hasn't been enough for three generations of 
post-World War II fantasy fansHence Terry Brooks, Piers Anthony, Robert 
Jordan, the questing rabbits of _Watership Down_, and half a hundred others.  
The writers of these books are creating the hobbits they still love and pine 
for; they are trying to bring Frodo back from the Grey Havens because Tolkien 
is no longer around to do it for them.  -Stephen King on the occasional success 
of a really LONG work, from _On Writing_ */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Paul Gilmartin
Sent: Sunday, October 3, 2021 13:50

BTW, is there a convenient term embracing the line of OSes, OS/360, MVT, 
OS/390, z/OS, and all those others?  I don't like to say "MVS" when I wish to 
include the pre-virtual systems, and I don't like to say "OS/360" when I wish 
to include z/OS.

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

I remember when MVS was affectionately called "Mine's Very Slow".
I'm writing an OS for x86 (as an exercise) which aims to learn some of the
lessons grown-up systems, such as MVS, could have taught x86 systems ever
since MS-DOS.
I'm calling it MES (Mine's Even Slower")  :-)

Roops

On Mon., Oct. 4, 2021, 02:45 Seymour J Metz,  wrote:

> A  good tech writer knows what he does not know. Unless he has a primary
> source for the expansion, he knows the meaning of the word "stet".
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Charles Mills 
> Sent: Sunday, October 3, 2021 9:58 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I vs. JCL
>
> > I don't abbreviate in documentation or discussion.
>
> Hmmm. I think referring to the console command P resonates with people
> more than STOP. I wonder if people do not recognize XMIT better than
> TRANSMIT. The goal in documentation should be clarity,  not pedagogics.
>
> I once had an all-out war (I won! I was the president!) with a tech writer
> who insisted that the documentation should spell out Multiple Virtual
> Systems on the first reference to MVS (in technical documentation for a
> hardcore mainframe product). My position was that it made us look like
> idiots.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Sunday, October 3, 2021 6:23 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I vs. JCL
>
> On Sat, 2 Oct 2021 20:56:43 -0700, Charles Mills wrote:
>
> >I have no problem with the DD/member ambiguity:
> >
> >1. If it's a personal tool and you are happy with the ambiguity, then you
> >are happy.
> >2. If it's a "product" then you just document which takes priority.
> >
> o z/VM CP and CMS with their very flat syntax (no delimiters) allow
> keywords
>   to be elided when their values do not overload other keyword names.  And
>   some operands are required for admin users and optional or prohibited for
>   general users.  And VM nerds delight in abbreviating keywords and command
>   names to single characters, baffling novices.  Ugh!
>
> o UNIX command options can be ambiguous with (non-portable?) filenames
>   beginning with "-".  The resolution is to qualify with current working
> directory:
>   "./-whatever".
>
> I don't abbreviate in documentation or discussion.  I write ALLOCATE, not
> ALLOC; TRANSMIT, not XMIT; etc.  (Oops!  I wrote "admin" above.)
>
> >I wrote a (successful!) product that in one very peripheral feature took
> an
> >operand that could represent a member name in a default PDS, a dataset
> name,
> >or a zFS file name. I differentiated among the three based on length and
> the
> >presence or absence of periods and/or slashes. No one ever complained that
> >they had a dataset or a zFS file named SHORTNAM and could not reference
> it.
> >I think the convenience and simplicity of being able to say simply
> >FILENAME(whatever) outweighed the perils of the ambiguity. Product design
> >involves tradeoffs.
>
> -- 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
>
> --
> 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

[Phil Smith III]

Charles Mills  wrote:
>I once had an all-out war (I won! I was the president!) with a tech writer who 
>insisted that the

>documentation should spell out Multiple Virtual Systems on the first reference 
>to MVS (in technical 

>documentation for a hardcore mainframe product). My position was that it made 
>us look like idiots.

 

Might have been the same writer who we had to order to STOP changing "filename" 
to "file name" and "userid" to "user identifier" in
VM documentation. Know your audience!

 

However, I would have stopped yours even earlier on the grounds that MVS stands 
for "Multiple Virtual Storage", not ".Systems". Just
sayin'.

 

...phsiii


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

A  good tech writer knows what he does not know. Unless he has a primary source 
for the expansion, he knows the meaning of the word "stet".


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



From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Sunday, October 3, 2021 9:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

> I don't abbreviate in documentation or discussion.

Hmmm. I think referring to the console command P resonates with people more 
than STOP. I wonder if people do not recognize XMIT better than TRANSMIT. The 
goal in documentation should be clarity,  not pedagogics.

I once had an all-out war (I won! I was the president!) with a tech writer who 
insisted that the documentation should spell out Multiple Virtual Systems on 
the first reference to MVS (in technical documentation for a hardcore mainframe 
product). My position was that it made us look like idiots.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Sunday, October 3, 2021 6:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

On Sat, 2 Oct 2021 20:56:43 -0700, Charles Mills wrote:

>I have no problem with the DD/member ambiguity:
>
>1. If it's a personal tool and you are happy with the ambiguity, then you
>are happy.
>2. If it's a "product" then you just document which takes priority.
>
o z/VM CP and CMS with their very flat syntax (no delimiters) allow keywords
  to be elided when their values do not overload other keyword names.  And
  some operands are required for admin users and optional or prohibited for
  general users.  And VM nerds delight in abbreviating keywords and command
  names to single characters, baffling novices.  Ugh!

o UNIX command options can be ambiguous with (non-portable?) filenames
  beginning with "-".  The resolution is to qualify with current working 
directory:
  "./-whatever".

I don't abbreviate in documentation or discussion.  I write ALLOCATE, not
ALLOC; TRANSMIT, not XMIT; etc.  (Oops!  I wrote "admin" above.)

>I wrote a (successful!) product that in one very peripheral feature took an
>operand that could represent a member name in a default PDS, a dataset name,
>or a zFS file name. I differentiated among the three based on length and the
>presence or absence of periods and/or slashes. No one ever complained that
>they had a dataset or a zFS file named SHORTNAM and could not reference it.
>I think the convenience and simplicity of being able to say simply
>FILENAME(whatever) outweighed the perils of the ambiguity. Product design
>involves tradeoffs.

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

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

ObOverloadedAcronym VMS is a failed predecessor to MVT. I used to run PCP and 
the police didn't mind. DOS runs on S/360 and S/370.


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



From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Sunday, October 3, 2021 1:50 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

On Sun, 3 Oct 2021 06:58:42 -0700, Charles Mills  wrote:
>
>I once had an all-out war (I won! I was the president!) with a tech writer who 
>insisted that the documentation should spell out Multiple Virtual Systems on 
>the first reference to MVS (in technical documentation for a hardcore 
>mainframe product). My position was that it made us look like idiots.
>
BTW, is there a convenient term embracing the line of OSes, OS/360, MVT, 
OS/390, z/OS,
and all those others?  I don't like to say "MVS" when I wish to include the 
pre-virtual
systems, and I don't like to say "OS/360" when I wish to include z/OS.

(And some of my colleagues ask, "'MVS'?  Don't you mean  'VMS'?"  And I've seen,
"VM is a version of MVS.")

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

Having wrestled with this issue for decades, I've come to adopt Mainframe
as a generic term that most people recognize. (Ignoring the technowienies
that debate the term endlessly.) No one argues with the term or even
questions it. It covers hardware and software. You can use other terms if
you need to get more specific.

On Sun, Oct 3, 2021 at 11:34 AM Charles Mills  wrote:

> Agreed. Saying MVS makes you look old-fashioned, even though MVS still
> exists (I guess?) as a component of z/OS. Saying z/OS is limiting.
>
> Ditto for the hardware. It is a little wordy to say "I have been writing
> assembler for the S/360, S370, S/390 and z." (And I guess now Telum?)
>
> Does that name lead to a who's on first dialog?
>
> "What's that new IBM chip called?"
> "Telum"
> "I'd like to tell 'em, but I don't know what it's called."
> "Telum"
> "Tell 'em what?"
> "The name of the chip."
> "I don't know the name of the chip."
> "Telum"
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Sunday, October 3, 2021 10:50 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I vs. JCL
>
> On Sun, 3 Oct 2021 06:58:42 -0700, Charles Mills  wrote:
> >
> >I once had an all-out war (I won! I was the president!) with a tech
> writer who insisted that the documentation should spell out Multiple
> Virtual Systems on the first reference to MVS (in technical documentation
> for a hardcore mainframe product). My position was that it made us look
> like idiots.
> >
> BTW, is there a convenient term embracing the line of OSes, OS/360, MVT,
> OS/390, z/OS,
> and all those others?  I don't like to say "MVS" when I wish to include
> the pre-virtual
> systems, and I don't like to say "OS/360" when I wish to include z/OS.
>
> --

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]

General Tee-esS-Oh is a favorite IT dad joke around here. (Never in front
of a waiter.) BTW that dish has nothing to do with the historical general
nor with Hunan, his home base.

On Sun, Oct 3, 2021 at 10:22 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Sun, 3 Oct 2021 09:37:00 -0700, Skip Robinson wrote:
>
> >Newbie auditors are notorious for 'spelling out' abbreviations that over
> >the decades have become actual names. And yes, idiocy is only one
> >consequence. The result can be gibberish.
> >
> A long time favorite is a local newscaster who read a story attributing
> a DC-10 crash to a failure of an "eh-eff-tee cargo hatch."
>
> >My favorite basket case is 'TSO', which was in ancient history Time
> Sharing
> >Option. For as long as anyone can remember, TSO has not involved 'time
> >sharing' in any meaningful way.
> >
> What would you say?  "Time Slicing"?  "Divided Property Ownership"?
>
> >... Nor is it remotely optional. Spelling out
> >the words contributes nothing to any discussion.
> >
> So you pronounce it as in "General TSO's Chicken"?
>
> -- gil
>

-- 

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

[Charles Mills]

Agreed. Saying MVS makes you look old-fashioned, even though MVS still exists 
(I guess?) as a component of z/OS. Saying z/OS is limiting.

Ditto for the hardware. It is a little wordy to say "I have been writing 
assembler for the S/360, S370, S/390 and z." (And I guess now Telum?)

Does that name lead to a who's on first dialog?

"What's that new IBM chip called?"
"Telum"
"I'd like to tell 'em, but I don't know what it's called."
"Telum"
"Tell 'em what?"
"The name of the chip."
"I don't know the name of the chip."
"Telum"

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Sunday, October 3, 2021 10:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

On Sun, 3 Oct 2021 06:58:42 -0700, Charles Mills  wrote:
>
>I once had an all-out war (I won! I was the president!) with a tech writer who 
>insisted that the documentation should spell out Multiple Virtual Systems on 
>the first reference to MVS (in technical documentation for a hardcore 
>mainframe product). My position was that it made us look like idiots.
> 
BTW, is there a convenient term embracing the line of OSes, OS/360, MVT, 
OS/390, z/OS,
and all those others?  I don't like to say "MVS" when I wish to include the 
pre-virtual
systems, and I don't like to say "OS/360" when I wish to include z/OS.

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

General Tee-esS-Oh is a favorite IT dad joke around here. (Never in front
of a waiter.) BTW that dish has nothing to do with the historical general
nor with Hunan, his home base.

On Sun, Oct 3, 2021 at 10:22 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Sun, 3 Oct 2021 09:37:00 -0700, Skip Robinson wrote:
>
> >Newbie auditors are notorious for 'spelling out' abbreviations that over
> >the decades have become actual names. And yes, idiocy is only one
> >consequence. The result can be gibberish.
> >
> A long time favorite is a local newscaster who read a story attributing
> a DC-10 crash to a failure of an "eh-eff-tee cargo hatch."
>
> >My favorite basket case is 'TSO', which was in ancient history Time
> Sharing
> >Option. For as long as anyone can remember, TSO has not involved 'time
> >sharing' in any meaningful way.
> >
> What would you say?  "Time Slicing"?  "Divided Property Ownership"?
>
> >... Nor is it remotely optional. Spelling out
> >the words contributes nothing to any discussion.
> >
> So you pronounce it as in "General TSO's Chicken"?
>
> -- gil
>
-- 

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 Sun, 3 Oct 2021 13:48:37 -0400, Phil Smith III wrote:
>...
>From the USS side, support DD:ddname as a filename and you're good (from C
>I'm not actually sure you can avoid supporting that). We have such a use
>case and have never had a problem with it.
> 
No.  "date >//DD:SYSPRINT" (or many variations) simply doesn't work.  (It
creates a file in thee root direectory.)  "date | cp /dev/fd/0 //DD:SYSPRINT
seems to work, but it's not supported.  If it breaks, you get to keep both 
pieces.

And "you can avoid supporting that" simply by prohibiting the syntax.  I'd
consider that prudent as long as it's not documented as supported.  An
alternative might be to document it by a citation of the C/C++ RTL  Ref.
IBM has not chosen to do that.  Would an RCF suffice or would an RFE
be necessary?

-- 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 Sun, 3 Oct 2021 06:58:42 -0700, Charles Mills  wrote:
>
>I once had an all-out war (I won! I was the president!) with a tech writer who 
>insisted that the documentation should spell out Multiple Virtual Systems on 
>the first reference to MVS (in technical documentation for a hardcore 
>mainframe product). My position was that it made us look like idiots.
> 
BTW, is there a convenient term embracing the line of OSes, OS/360, MVT, 
OS/390, z/OS,
and all those others?  I don't like to say "MVS" when I wish to include the 
pre-virtual
systems, and I don't like to say "OS/360" when I wish to include z/OS.

(And some of my colleagues ask, "'MVS'?  Don't you mean  'VMS'?"  And I've seen,
"VM is a version of MVS.")

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

[Phil Smith III]

Charles wrote:

>I wrote a (successful!) product that in one very peripheral feature took an
>operand that could represent a member name in a default PDS, a dataset
name,
>or a zFS file name. I differentiated among the three based on length and
the
>presence or absence of periods and/or slashes. No one ever complained that
>they had a dataset or a zFS file named SHORTNAM and could not reference it.
>I think the convenience and simplicity of being able to say simply
>FILENAME(whatever) outweighed the perils of the ambiguity. Product design
>involves tradeoffs.

 

Agreed, this isn't tricky. If it starts with a slash (or possibly a period),
it's a USS file; otherwise it isn't. So a zFS file named SHORTNAM would be
listed as /u/whatever/SHORTNAM or, at worse, ./SHORTNAM and it Just Works.

 

>From the USS side, support DD:ddname as a filename and you're good (from C
I'm not actually sure you can avoid supporting that). We have such a use
case and have never had a problem with it.

 

...phsiii 


--
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 Sun, 3 Oct 2021 09:37:00 -0700, Skip Robinson wrote:

>Newbie auditors are notorious for 'spelling out' abbreviations that over
>the decades have become actual names. And yes, idiocy is only one
>consequence. The result can be gibberish.
> 
A long time favorite is a local newscaster who read a story attributing
a DC-10 crash to a failure of an "eh-eff-tee cargo hatch."

>My favorite basket case is 'TSO', which was in ancient history Time Sharing
>Option. For as long as anyone can remember, TSO has not involved 'time
>sharing' in any meaningful way.
>
What would you say?  "Time Slicing"?  "Divided Property Ownership"?

>... Nor is it remotely optional. Spelling out
>the words contributes nothing to any discussion.
>
So you pronounce it as in "General TSO's Chicken"?

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

[David Spiegel]

Hi Skip,
You said: "... Nor 'RACF', which everyone says as rack+f. ..."

Way back in 2000, when I was working at IBM full-time, I was involved 
with a few ACF2->RACF conversions.

One customer kept driving me crazy by calling IBM's ESM "Ra-KEFF".

Regards,
David

On 2021-10-03 12:37, Skip Robinson wrote:

Newbie auditors are notorious for 'spelling out' abbreviations that over
the decades have become actual names. And yes, idiocy is only one
consequence. The result can be gibberish.

My favorite basket case is 'TSO', which was in ancient history Time Sharing
Option. For as long as anyone can remember, TSO has not involved 'time
sharing' in any meaningful way. Nor is it remotely optional. Spelling out
the words contributes nothing to any discussion.

Another favorite is 'JES'. Nobody spells it out. Nor 'RACF', which everyone
says as rack+f.

On Sun, Oct 3, 2021 at 6:59 AM Charles Mills  wrote:


I don't abbreviate in documentation or discussion.

Hmmm. I think referring to the console command P resonates with people
more than STOP. I wonder if people do not recognize XMIT better than
TRANSMIT. The goal in documentation should be clarity,  not pedagogics.

I once had an all-out war (I won! I was the president!) with a tech writer
who insisted that the documentation should spell out Multiple Virtual
Systems on the first reference to MVS (in technical documentation for a
hardcore mainframe product). My position was that it made us look like
idiots.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Paul Gilmartin
Sent: Sunday, October 3, 2021 6:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

On Sat, 2 Oct 2021 20:56:43 -0700, Charles Mills wrote:


I have no problem with the DD/member ambiguity:

1. If it's a personal tool and you are happy with the ambiguity, then you
are happy.
2. If it's a "product" then you just document which takes priority.


o z/VM CP and CMS with their very flat syntax (no delimiters) allow
keywords
   to be elided when their values do not overload other keyword names.  And
   some operands are required for admin users and optional or prohibited for
   general users.  And VM nerds delight in abbreviating keywords and command
   names to single characters, baffling novices.  Ugh!

o UNIX command options can be ambiguous with (non-portable?) filenames
   beginning with "-".  The resolution is to qualify with current working
directory:
   "./-whatever".

I don't abbreviate in documentation or discussion.  I write ALLOCATE, not
ALLOC; TRANSMIT, not XMIT; etc.  (Oops!  I wrote "admin" above.)


I wrote a (successful!) product that in one very peripheral feature took

an

operand that could represent a member name in a default PDS, a dataset

name,

or a zFS file name. I differentiated among the three based on length and

the

presence or absence of periods and/or slashes. No one ever complained that
they had a dataset or a zFS file named SHORTNAM and could not reference

it.

I think the convenience and simplicity of being able to say simply
FILENAME(whatever) outweighed the perils of the ambiguity. Product design
involves tradeoffs.

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

[Ed Jaffe]

On 10/3/2021 9:37 AM, Skip Robinson wrote:

Another favorite is 'JES'. Nobody spells it out.
IBM spells it out in every JES2 manual e.g., 
https://www.ibm.com/docs/en/zos/2.5.0?topic=jes2-zos-introduction


"This information provides an introduction to the job entry subsystem 2 
(JES2)."


[Aside: I'm surprised they do not capitalize...]


Nor 'RACF', which everyone says as rack+f.


IBM spells it out in every RACF manual e.g., 
https://www.ibm.com/docs/en/zos/2.5.0?topic=racf-zos-security-server-security-administrators-guide


"This information supports z/OS (5650-ZOS) and describes Resource Access 
Control Facility (RACF), which is part of z/OS Security Server."


[Aside: I'm not surprised they capitalize...]

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

[Ed Jaffe]

On 10/3/2021 6:58 AM, Charles Mills wrote:


I once had an all-out war (I won! I was the president!) with a tech writer who 
insisted that the documentation should spell out Multiple Virtual Systems on 
the first reference to MVS (in technical documentation for a hardcore mainframe 
product). My position was that it made us look like idiots.


Good thing you won that war...

Spelling out Multiple Virtual _Systems_ would *really* have made you 
look like idiots! LOL


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

Newbie auditors are notorious for 'spelling out' abbreviations that over
the decades have become actual names. And yes, idiocy is only one
consequence. The result can be gibberish.

My favorite basket case is 'TSO', which was in ancient history Time Sharing
Option. For as long as anyone can remember, TSO has not involved 'time
sharing' in any meaningful way. Nor is it remotely optional. Spelling out
the words contributes nothing to any discussion.

Another favorite is 'JES'. Nobody spells it out. Nor 'RACF', which everyone
says as rack+f.

On Sun, Oct 3, 2021 at 6:59 AM Charles Mills  wrote:

> > I don't abbreviate in documentation or discussion.
>
> Hmmm. I think referring to the console command P resonates with people
> more than STOP. I wonder if people do not recognize XMIT better than
> TRANSMIT. The goal in documentation should be clarity,  not pedagogics.
>
> I once had an all-out war (I won! I was the president!) with a tech writer
> who insisted that the documentation should spell out Multiple Virtual
> Systems on the first reference to MVS (in technical documentation for a
> hardcore mainframe product). My position was that it made us look like
> idiots.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Sunday, October 3, 2021 6:23 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I vs. JCL
>
> On Sat, 2 Oct 2021 20:56:43 -0700, Charles Mills wrote:
>
> >I have no problem with the DD/member ambiguity:
> >
> >1. If it's a personal tool and you are happy with the ambiguity, then you
> >are happy.
> >2. If it's a "product" then you just document which takes priority.
> >
> o z/VM CP and CMS with their very flat syntax (no delimiters) allow
> keywords
>   to be elided when their values do not overload other keyword names.  And
>   some operands are required for admin users and optional or prohibited for
>   general users.  And VM nerds delight in abbreviating keywords and command
>   names to single characters, baffling novices.  Ugh!
>
> o UNIX command options can be ambiguous with (non-portable?) filenames
>   beginning with "-".  The resolution is to qualify with current working
> directory:
>   "./-whatever".
>
> I don't abbreviate in documentation or discussion.  I write ALLOCATE, not
> ALLOC; TRANSMIT, not XMIT; etc.  (Oops!  I wrote "admin" above.)
>
> >I wrote a (successful!) product that in one very peripheral feature took
> an
> >operand that could represent a member name in a default PDS, a dataset
> name,
> >or a zFS file name. I differentiated among the three based on length and
> the
> >presence or absence of periods and/or slashes. No one ever complained that
> >they had a dataset or a zFS file named SHORTNAM and could not reference
> it.
> >I think the convenience and simplicity of being able to say simply
> >FILENAME(whatever) outweighed the perils of the ambiguity. Product design
> >involves tradeoffs.
>
> -- gil
>
>
>
-- 

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]

On Sun, Oct 3, 2021 at 6:59 AM Charles Mills  wrote:

> > I don't abbreviate in documentation or discussion.
>
> Hmmm. I think referring to the console command P resonates with people
> more than STOP. I wonder if people do not recognize XMIT better than
> TRANSMIT. The goal in documentation should be clarity,  not pedagogics.
>
> I once had an all-out war (I won! I was the president!) with a tech writer
> who insisted that the documentation should spell out Multiple Virtual
> Systems on the first reference to MVS (in technical documentation for a
> hardcore mainframe product). My position was that it made us look like
> idiots.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Sunday, October 3, 2021 6:23 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I vs. JCL
>
> On Sat, 2 Oct 2021 20:56:43 -0700, Charles Mills wrote:
>
> >I have no problem with the DD/member ambiguity:
> >
> >1. If it's a personal tool and you are happy with the ambiguity, then you
> >are happy.
> >2. If it's a "product" then you just document which takes priority.
> >
> o z/VM CP and CMS with their very flat syntax (no delimiters) allow
> keywords
>   to be elided when their values do not overload other keyword names.  And
>   some operands are required for admin users and optional or prohibited for
>   general users.  And VM nerds delight in abbreviating keywords and command
>   names to single characters, baffling novices.  Ugh!
>
> o UNIX command options can be ambiguous with (non-portable?) filenames
>   beginning with "-".  The resolution is to qualify with current working
> directory:
>   "./-whatever".
>
> I don't abbreviate in documentation or discussion.  I write ALLOCATE, not
> ALLOC; TRANSMIT, not XMIT; etc.  (Oops!  I wrote "admin" above.)
>
> >I wrote a (successful!) product that in one very peripheral feature took
> an
> >operand that could represent a member name in a default PDS, a dataset
> name,
> >or a zFS file name. I differentiated among the three based on length and
> the
> >presence or absence of periods and/or slashes. No one ever complained that
> >they had a dataset or a zFS file named SHORTNAM and could not reference
> it.
> >I think the convenience and simplicity of being able to say simply
> >FILENAME(whatever) outweighed the perils of the ambiguity. Product design
> >involves tradeoffs.
>
> -- 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
>


-- 

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

[Charles Mills]

Umm, we can probably blame my memory, not the tech writer, for that one.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Spiegel
Sent: Sunday, October 3, 2021 7:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

Hi Charles,
I guess that nobody bothered to tell the tech writer that the "S" in 
MVS, is an abbreviation for "Storage".

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

[David Spiegel]

Hi Charles,
I guess that nobody bothered to tell the tech writer that the "S" in 
MVS, is an abbreviation for "Storage".


Regards,
David

On 2021-10-03 09:58, Charles Mills wrote:

I don't abbreviate in documentation or discussion.

Hmmm. I think referring to the console command P resonates with people more 
than STOP. I wonder if people do not recognize XMIT better than TRANSMIT. The 
goal in documentation should be clarity,  not pedagogics.

I once had an all-out war (I won! I was the president!) with a tech writer who 
insisted that the documentation should spell out Multiple Virtual Systems on 
the first reference to MVS (in technical documentation for a hardcore mainframe 
product). My position was that it made us look like idiots.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Sunday, October 3, 2021 6:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

On Sat, 2 Oct 2021 20:56:43 -0700, Charles Mills wrote:


I have no problem with the DD/member ambiguity:

1. If it's a personal tool and you are happy with the ambiguity, then you
are happy.
2. If it's a "product" then you just document which takes priority.


o z/VM CP and CMS with their very flat syntax (no delimiters) allow keywords
   to be elided when their values do not overload other keyword names.  And
   some operands are required for admin users and optional or prohibited for
   general users.  And VM nerds delight in abbreviating keywords and command
   names to single characters, baffling novices.  Ugh!

o UNIX command options can be ambiguous with (non-portable?) filenames
   beginning with "-".  The resolution is to qualify with current working 
directory:
   "./-whatever".

I don't abbreviate in documentation or discussion.  I write ALLOCATE, not
ALLOC; TRANSMIT, not XMIT; etc.  (Oops!  I wrote "admin" above.)


I wrote a (successful!) product that in one very peripheral feature took an
operand that could represent a member name in a default PDS, a dataset name,
or a zFS file name. I differentiated among the three based on length and the
presence or absence of periods and/or slashes. No one ever complained that
they had a dataset or a zFS file named SHORTNAM and could not reference it.
I think the convenience and simplicity of being able to say simply
FILENAME(whatever) outweighed the perils of the ambiguity. Product design
involves tradeoffs.

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


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

> I don't abbreviate in documentation or discussion.

Hmmm. I think referring to the console command P resonates with people more 
than STOP. I wonder if people do not recognize XMIT better than TRANSMIT. The 
goal in documentation should be clarity,  not pedagogics. 

I once had an all-out war (I won! I was the president!) with a tech writer who 
insisted that the documentation should spell out Multiple Virtual Systems on 
the first reference to MVS (in technical documentation for a hardcore mainframe 
product). My position was that it made us look like idiots.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Sunday, October 3, 2021 6:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

On Sat, 2 Oct 2021 20:56:43 -0700, Charles Mills wrote:

>I have no problem with the DD/member ambiguity:
>
>1. If it's a personal tool and you are happy with the ambiguity, then you
>are happy.
>2. If it's a "product" then you just document which takes priority.
> 
o z/VM CP and CMS with their very flat syntax (no delimiters) allow keywords
  to be elided when their values do not overload other keyword names.  And
  some operands are required for admin users and optional or prohibited for
  general users.  And VM nerds delight in abbreviating keywords and command
  names to single characters, baffling novices.  Ugh!

o UNIX command options can be ambiguous with (non-portable?) filenames
  beginning with "-".  The resolution is to qualify with current working 
directory:
  "./-whatever".

I don't abbreviate in documentation or discussion.  I write ALLOCATE, not
ALLOC; TRANSMIT, not XMIT; etc.  (Oops!  I wrote "admin" above.)

>I wrote a (successful!) product that in one very peripheral feature took an
>operand that could represent a member name in a default PDS, a dataset name,
>or a zFS file name. I differentiated among the three based on length and the
>presence or absence of periods and/or slashes. No one ever complained that
>they had a dataset or a zFS file named SHORTNAM and could not reference it.
>I think the convenience and simplicity of being able to say simply
>FILENAME(whatever) outweighed the perils of the ambiguity. Product design
>involves tradeoffs.

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

[Paul Gilmartin]

On Sat, 2 Oct 2021 20:56:43 -0700, Charles Mills wrote:

>I have no problem with the DD/member ambiguity:
>
>1. If it's a personal tool and you are happy with the ambiguity, then you
>are happy.
>2. If it's a "product" then you just document which takes priority.
> 
o z/VM CP and CMS with their very flat syntax (no delimiters) allow keywords
  to be elided when their values do not overload other keyword names.  And
  some operands are required for admin users and optional or prohibited for
  general users.  And VM nerds delight in abbreviating keywords and command
  names to single characters, baffling novices.  Ugh!

o UNIX command options can be ambiguous with (non-portable?) filenames
  beginning with "-".  The resolution is to qualify with current working 
directory:
  "./-whatever".

I don't abbreviate in documentation or discussion.  I write ALLOCATE, not
ALLOC; TRANSMIT, not XMIT; etc.  (Oops!  I wrote "admin" above.)

>I wrote a (successful!) product that in one very peripheral feature took an
>operand that could represent a member name in a default PDS, a dataset name,
>or a zFS file name. I differentiated among the three based on length and the
>presence or absence of periods and/or slashes. No one ever complained that
>they had a dataset or a zFS file named SHORTNAM and could not reference it.
>I think the convenience and simplicity of being able to say simply
>FILENAME(whatever) outweighed the perils of the ambiguity. Product design
>involves tradeoffs.

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

[Charles Mills]

I have no problem with the DD/member ambiguity:

1. If it's a personal tool and you are happy with the ambiguity, then you
are happy.
2. If it's a "product" then you just document which takes priority.

I wrote a (successful!) product that in one very peripheral feature took an
operand that could represent a member name in a default PDS, a dataset name,
or a zFS file name. I differentiated among the three based on length and the
presence or absence of periods and/or slashes. No one ever complained that
they had a dataset or a zFS file named SHORTNAM and could not reference it.
I think the convenience and simplicity of being able to say simply
FILENAME(whatever) outweighed the perils of the ambiguity. Product design
involves tradeoffs.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Bob Bridges
Sent: Saturday, October 2, 2021 6:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

No, I think it's possible (though unlikely) for a string to represent both
at the same time.  If nothing else, the TSO alias that's used to catalogue
my datasets is a dataset, sort of, isn't it?  So if I allocate a DD named
BBRIDGE, and then ask DSDD about BBRIDGE, it would at that time be both a
dataset and a DD.  But even if LISTDSI doesn't see a TSO alias as a dataset,
there can be DSNs with just one node.

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

/* If you think education is expensive, try ignorance.  -Derek Bok,
President, Harvard University */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Seymour J Metz
Sent: Friday, October 1, 2021 10:41

Can you guarant[ee] that there will never be a name that is used for both a
member and a ddname?

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

No, I think it's possible (though unlikely) for a string to represent both
at the same time.  If nothing else, the TSO alias that's used to catalogue
my datasets is a dataset, sort of, isn't it?  So if I allocate a DD named
BBRIDGE, and then ask DSDD about BBRIDGE, it would at that time be both a
dataset and a DD.  But even if LISTDSI doesn't see a TSO alias as a dataset,
there can be DSNs with just one node.

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

/* If you think education is expensive, try ignorance.  -Derek Bok,
President, Harvard University */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Seymour J Metz
Sent: Friday, October 1, 2021 10:41

Can you guarant[ee] that there will never be a name that is used for both a
member and a ddname?


From: IBM Mainframe Discussion List  on behalf of
Bob Bridges 
Sent: Friday, October 1, 2021 9:21 AM

a function DSDD that receives a string and returns a code telling
whether the string represents a catalogued DS, an allocated DD, or both, or
neither

--
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 don't find EXEC's handling of positional parameters, keyword parameters with 
value and keyword parameters without value to be complex. But other things in 
CLIST drive me up the wall.


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



From: IBM Mainframe Discussion List  on behalf of 
Skip Robinson 
Sent: Thursday, September 30, 2021 10:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

Even a dead horse needs a tail. Parsing CLIST parms involves more than
sorting out characters and delimiters. There are (my terminology) three
kinds of parms.

1. Positional parms
2. Keyword switch parms
3, Keyword value parms

Positional parms must come first in the order coded in the exec. Each
variable is assigned whatever value the user has entered.

Keyword switch parms must follow positional parms in any order. If the
keyword is present, the variable is assigned the value that matches the
variable name. 'Match' here means an unambiguous (sub)string. If the match
is ambiguous, CLIST prompts for an unambiguous.

Keyword value parms must also follow positional parms in any order, coded
like this: keyword(value). Value can be anything. Keyword entered by the
user must unambiguously match one coded in the CLIST, else CLIST prompts
the user.

So why the complexity? CLIST is very old, predating ISPF. Hence the user
had to supply lots of data at execution time. This framework offers
flexibility.


On Thu, Sep 30, 2021 at 4:14 PM Bob Bridges  wrote:

> I once wrote an external routine that can break a character string into
> various individual parms and return them on the stack.  It correctly parses
> strings with quotes, parens and comment markers.
>
> But as you say, even I hardly ever use it.  Most routines work perfectly
> well with a string of one-word arguments, and if I don't have to remember
> what order they come in and don’t have to label them, anything more is
> almost never required.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* Having your book turned into a movie is like seeing your oxen turned
> into bouillon cubes.  -John LeCarré */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Skip Robinson
> Sent: Wednesday, September 29, 2021 18:06
>
> 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.
>
>
--

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]

Can you guaranty that there will never be a name that is used for both a member 
and a ddname?


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



From: IBM Mainframe Discussion List  on behalf of Bob 
Bridges 
Sent: Friday, October 1, 2021 9:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

I would never have seen this in advance, but one advantage I found when 
switching to REXX is that I'm almost eliminated positional parms from my 
commands.  In all but a few cases, the program can tell what it is by looking 
at it.  Thus every user can enter the arguments in the order that seems most 
logical to him, or (in my case) in the order that occurs to me at the time.  
It's a small convenience, but I cherish it.

The one exception that occurs to me just now is my LOC command, which I use to 
find a module in a DD concatenation of libraries.  Like this:

  ==> tss loc modulenm sysproc
  SYSPROC  XYZ.ISPF.GENERAL.CLIB
  SYSPROC  XYZ.ISPF.COMBINED.V65.CLIB
  SYSPROC  TTP.CAI.V44.CAICLIB
  Member MODULENM found in dataset TTP.CAI.V44.CAICLIB (#3in SYSPROC).

...and then starts that module in View.  (This is a big help when programming 
in ISPF, among other things.)  In this case LOC needs to know which is the 
module name and which the DD name, since they both look the same.

...But wait:  An idea strikes.  I already have a function DSDD that receives a 
string and returns a code telling whether the string represents a catalogued 
DS, an allocated DD, or both, or neither.  So even LOC doesn't need these two 
args to be positional; it can look over the args, determine which DD(s) to 
search, and any other args are module names.  Cool!  I have work to do :).

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

/* if we consider the unblushing promises of reward and the staggering 
nature of the rewards promised in the Gospels, it would seem that our Lord 
finds our desires not too strong, but too weak. We are half-hearted creatures, 
fooling about with drink and sex and ambition when infinite joy is offered us, 
like an ignorant child who wants to go on making mud pies in a slum because he 
cannot imagine what is meant by the offer of a holiday at the sea.  -from _The 
Weight of Glory_ by C S Lewis */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Skip Robinson
Sent: Thursday, September 30, 2021 22:37

Even a dead horse needs a tail. Parsing CLIST parms involves more than sorting 
out characters and delimiters. There are (my terminology) three kinds of parms.

1. Positional parms
2. Keyword switch parms
3, Keyword value parms

Positional parms must come first in the order coded in the exec. Each variable 
is assigned whatever value the user has entered.

Keyword switch parms must follow positional parms in any order. If the keyword 
is present, the variable is assigned the value that matches the variable name. 
'Match' here means an unambiguous (sub)string. If the match is ambiguous, CLIST 
prompts for an unambiguous.

Keyword value parms must also follow positional parms in any order, coded like 
this: keyword(value). Value can be anything. Keyword entered by the user must 
unambiguously match one coded in the CLIST, else CLIST prompts the user.

So why the complexity? CLIST is very old, predating ISPF. Hence the user had to 
supply lots of data at execution time. This framework offers flexibility.


--- On Thu, Sep 30, 2021 at 4:14 PM Bob Bridges  wrote:
> I once wrote an external routine that can break a character string
> into various individual parms and return them on the stack.  It
> correctly parses strings with quotes, parens and comment markers.
>
> But as you say, even I hardly ever use it.  Most routines work
> perfectly well with a string of one-word arguments, and if I don't
> have to remember what order they come in and don’t have to label them,
> anything more is almost never required.
>
> -Original Message-
> From: Skip Robinson
> Sent: Wednesday, September 29, 2021 18:06
>
> 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.

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

[Bob Bridges]

I would never have seen this in advance, but one advantage I found when 
switching to REXX is that I'm almost eliminated positional parms from my 
commands.  In all but a few cases, the program can tell what it is by looking 
at it.  Thus every user can enter the arguments in the order that seems most 
logical to him, or (in my case) in the order that occurs to me at the time.  
It's a small convenience, but I cherish it.

The one exception that occurs to me just now is my LOC command, which I use to 
find a module in a DD concatenation of libraries.  Like this:

  ==> tss loc modulenm sysproc
  SYSPROC  XYZ.ISPF.GENERAL.CLIB 
  SYSPROC  XYZ.ISPF.COMBINED.V65.CLIB
  SYSPROC  TTP.CAI.V44.CAICLIB   
  Member MODULENM found in dataset TTP.CAI.V44.CAICLIB (#3in SYSPROC).

...and then starts that module in View.  (This is a big help when programming 
in ISPF, among other things.)  In this case LOC needs to know which is the 
module name and which the DD name, since they both look the same.

...But wait:  An idea strikes.  I already have a function DSDD that receives a 
string and returns a code telling whether the string represents a catalogued 
DS, an allocated DD, or both, or neither.  So even LOC doesn't need these two 
args to be positional; it can look over the args, determine which DD(s) to 
search, and any other args are module names.  Cool!  I have work to do :).

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

/* if we consider the unblushing promises of reward and the staggering 
nature of the rewards promised in the Gospels, it would seem that our Lord 
finds our desires not too strong, but too weak. We are half-hearted creatures, 
fooling about with drink and sex and ambition when infinite joy is offered us, 
like an ignorant child who wants to go on making mud pies in a slum because he 
cannot imagine what is meant by the offer of a holiday at the sea.  -from _The 
Weight of Glory_ by C S Lewis */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Skip Robinson
Sent: Thursday, September 30, 2021 22:37

Even a dead horse needs a tail. Parsing CLIST parms involves more than sorting 
out characters and delimiters. There are (my terminology) three kinds of parms.

1. Positional parms
2. Keyword switch parms
3, Keyword value parms

Positional parms must come first in the order coded in the exec. Each variable 
is assigned whatever value the user has entered.

Keyword switch parms must follow positional parms in any order. If the keyword 
is present, the variable is assigned the value that matches the variable name. 
'Match' here means an unambiguous (sub)string. If the match is ambiguous, CLIST 
prompts for an unambiguous.

Keyword value parms must also follow positional parms in any order, coded like 
this: keyword(value). Value can be anything. Keyword entered by the user must 
unambiguously match one coded in the CLIST, else CLIST prompts the user.

So why the complexity? CLIST is very old, predating ISPF. Hence the user had to 
supply lots of data at execution time. This framework offers flexibility.


--- On Thu, Sep 30, 2021 at 4:14 PM Bob Bridges  wrote:
> I once wrote an external routine that can break a character string 
> into various individual parms and return them on the stack.  It 
> correctly parses strings with quotes, parens and comment markers.
>
> But as you say, even I hardly ever use it.  Most routines work 
> perfectly well with a string of one-word arguments, and if I don't 
> have to remember what order they come in and don’t have to label them, 
> anything more is almost never required.
>
> -Original Message-
> From: Skip Robinson
> Sent: Wednesday, September 29, 2021 18:06
>
> 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.

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

[Tom Brennan]

More than once I coded short CLIST front-ends to ASM programs in order 
to avoid IKJPARS while still doing the input processing you mentioned. 
The clist would poke the results in a single string for the assembler 
program to easily grab by offsets.


On 9/30/2021 7:37 PM, Skip Robinson wrote:

Even a dead horse needs a tail. Parsing CLIST parms involves more than
sorting out characters and delimiters. There are (my terminology) three
kinds of parms.

1. Positional parms
2. Keyword switch parms
3, Keyword value parms

Positional parms must come first in the order coded in the exec. Each
variable is assigned whatever value the user has entered.

Keyword switch parms must follow positional parms in any order. If the
keyword is present, the variable is assigned the value that matches the
variable name. 'Match' here means an unambiguous (sub)string. If the match
is ambiguous, CLIST prompts for an unambiguous.

Keyword value parms must also follow positional parms in any order, coded
like this: keyword(value). Value can be anything. Keyword entered by the
user must unambiguously match one coded in the CLIST, else CLIST prompts
the user.

So why the complexity? CLIST is very old, predating ISPF. Hence the user
had to supply lots of data at execution time. This framework offers
flexibility.


On Thu, Sep 30, 2021 at 4:14 PM Bob Bridges  wrote:


I once wrote an external routine that can break a character string into
various individual parms and return them on the stack.  It correctly parses
strings with quotes, parens and comment markers.

But as you say, even I hardly ever use it.  Most routines work perfectly
well with a string of one-word arguments, and if I don't have to remember
what order they come in and don’t have to label them, anything more is
almost never required.

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

/* Having your book turned into a movie is like seeing your oxen turned
into bouillon cubes.  -John LeCarré */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf
Of Skip Robinson
Sent: Wednesday, September 29, 2021 18:06

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.




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

It's spelled out in the documentation for the EXEC command.

SYSEXEC is REXX only.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob 
Bridges [robhbrid...@gmail.com]
Sent: Thursday, September 30, 2021 5:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

A number of people have responded but not actually spelled out the reason.  A 
comment in the first line containing "REXX" is required if the module resides 
in a //SYSPROC DD -- and not if it's in the //SYSEXEC DD -- because //SYSPROC 
modules are interpreted by default by the CLIST interpreter and //SYSEXEC by 
the REXX interpreter.  The /* REXX */ marker in a //SYSPROC module gives the 
system a chance to toggle over to REXX.  There is no analogous switch, AFAIK, 
to have //SYSEXEC modules interpreted as CLISTs.

I'm inferring; I don't recall reading exactly this in any documentation.  But 
it makes sense.

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

/* Asked during these last weeks who caused the riots and the killing in LA, my 
answer has been direct and simple:  Who is to blame for the riots?  The rioters 
are to blame.  Who is to blame for the killings?  The killers are to blame.  
-Dan Quayle, U.S. Vice President, after the Rodney King riots in LA */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Wednesday, September 29, 2021 10:22

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Wednesday, September 29, 2021 10:07

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.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of CM 
Poncelet
Sent: Tuesday, September 28, 2021 21:58

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

--
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 tend to use Perl when I need to do complicated parsing of strings. Java, 
Python and Ruby have similar capabilities in that regard.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob 
Bridges [robhbrid...@gmail.com]
Sent: Thursday, September 30, 2021 7:14 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

I once wrote an external routine that can break a character string into various 
individual parms and return them on the stack.  It correctly parses strings 
with quotes, parens and comment markers.

But as you say, even I hardly ever use it.  Most routines work perfectly well 
with a string of one-word arguments, and if I don't have to remember what order 
they come in and don’t have to label them, anything more is almost never 
required.

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

/* Having your book turned into a movie is like seeing your oxen turned into 
bouillon cubes.  -John LeCarré */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Skip Robinson
Sent: Wednesday, September 29, 2021 18:06

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.

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

Even a dead horse needs a tail. Parsing CLIST parms involves more than
sorting out characters and delimiters. There are (my terminology) three
kinds of parms.

1. Positional parms
2. Keyword switch parms
3, Keyword value parms

Positional parms must come first in the order coded in the exec. Each
variable is assigned whatever value the user has entered.

Keyword switch parms must follow positional parms in any order. If the
keyword is present, the variable is assigned the value that matches the
variable name. 'Match' here means an unambiguous (sub)string. If the match
is ambiguous, CLIST prompts for an unambiguous.

Keyword value parms must also follow positional parms in any order, coded
like this: keyword(value). Value can be anything. Keyword entered by the
user must unambiguously match one coded in the CLIST, else CLIST prompts
the user.

So why the complexity? CLIST is very old, predating ISPF. Hence the user
had to supply lots of data at execution time. This framework offers
flexibility.


On Thu, Sep 30, 2021 at 4:14 PM Bob Bridges  wrote:

> I once wrote an external routine that can break a character string into
> various individual parms and return them on the stack.  It correctly parses
> strings with quotes, parens and comment markers.
>
> But as you say, even I hardly ever use it.  Most routines work perfectly
> well with a string of one-word arguments, and if I don't have to remember
> what order they come in and don’t have to label them, anything more is
> almost never required.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* Having your book turned into a movie is like seeing your oxen turned
> into bouillon cubes.  -John LeCarré */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Skip Robinson
> Sent: Wednesday, September 29, 2021 18:06
>
> 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.
>
>
-- 

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

[Bob Bridges]

I once wrote an external routine that can break a character string into various 
individual parms and return them on the stack.  It correctly parses strings 
with quotes, parens and comment markers.

But as you say, even I hardly ever use it.  Most routines work perfectly well 
with a string of one-word arguments, and if I don't have to remember what order 
they come in and don’t have to label them, anything more is almost never 
required.

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

/* Having your book turned into a movie is like seeing your oxen turned into 
bouillon cubes.  -John LeCarré */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Skip Robinson
Sent: Wednesday, September 29, 2021 18:06

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.

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

A number of people have responded but not actually spelled out the reason.  A 
comment in the first line containing "REXX" is required if the module resides 
in a //SYSPROC DD -- and not if it's in the //SYSEXEC DD -- because //SYSPROC 
modules are interpreted by default by the CLIST interpreter and //SYSEXEC by 
the REXX interpreter.  The /* REXX */ marker in a //SYSPROC module gives the 
system a chance to toggle over to REXX.  There is no analogous switch, AFAIK, 
to have //SYSEXEC modules interpreted as CLISTs.

I'm inferring; I don't recall reading exactly this in any documentation.  But 
it makes sense.

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

/* Asked during these last weeks who caused the riots and the killing in LA, my 
answer has been direct and simple:  Who is to blame for the riots?  The rioters 
are to blame.  Who is to blame for the killings?  The killers are to blame.  
-Dan Quayle, U.S. Vice President, after the Rodney King riots in LA */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Seymour J Metz
Sent: Wednesday, September 29, 2021 10:22

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

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Wednesday, September 29, 2021 10:07

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.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of CM 
Poncelet
Sent: Tuesday, September 28, 2021 21:58

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 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: PL/I vs. JCL

[Seymour J Metz]

Of course; that's why you do the heavy lifting under the covers. But you need 
to deal with the nits so they don't have to.


--
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: Thursday, September 30, 2021 3:11 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL

90% of execs are run by general users 90% of the time, either explicitly
from 'command line' or implicitly from an ISPF panel. Some of these folks
may be more or less exec savvy, but most just want an exec to perform some
business task with minimal fuss. They don't know or want to know how the
sausage is made. Just add a touch of mustard and move on. My job as a
sysprog is to install exec updates as transparently as possible with little
fanfare. Users are capable of adapting to change, but they have other
issues to deal with. Let's be kind to them.



On Wed, Sep 29, 2021 at 4:42 PM Seymour J Metz  wrote:

> 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

[Skip Robinson]

90% of execs are run by general users 90% of the time, either explicitly
from 'command line' or implicitly from an ISPF panel. Some of these folks
may be more or less exec savvy, but most just want an exec to perform some
business task with minimal fuss. They don't know or want to know how the
sausage is made. Just add a touch of mustard and move on. My job as a
sysprog is to install exec updates as transparently as possible with little
fanfare. Users are capable of adapting to change, but they have other
issues to deal with. Let's be kind to them.



On Wed, Sep 29, 2021 at 4:42 PM Seymour J Metz  wrote:

> 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

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

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