Re: PL/I vs. JCL

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,

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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)

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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 issu

Re: PL/I vs. JCL

, 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

Re: PL/I vs. JCL

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

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

Re: PL/I vs. JCL

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

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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 ta

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

ttp://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 Sys

Re: PL/I vs. JCL

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 Serv

Re: PL/I vs. JCL

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

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 >

Re: PL/I vs. JCL

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

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

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

Re: PL/I vs. JCL

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

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

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

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

Re: PL/I vs. JCL

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

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,

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

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

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

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,

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

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

Re: PL/I vs. JCL

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 XMI

Re: PL/I vs. JCL

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 wh

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

uot; "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 M

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

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

Re: PL/I vs. JCL

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.

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

Re: PL/I vs. JCL

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 pro

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

s 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

Re: PL/I vs. JCL

e 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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

lmartin 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

Re: PL/I vs. JCL

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

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

Re: PL/I vs. JCL

: 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

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

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

Re: PL/I vs. JCL

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:

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

] 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

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

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

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

ainframe 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

Re: PL/I vs. JCL

@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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

me 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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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 compli

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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"

Re: PL/I vs. JCL

muel (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 >&

Re: PL/I vs. JCL

>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

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

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

Re: PL/I vs. JCL

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

  1   2   >