> Meticulously distinguishing the case of PARM is absent from PARM='', > possibly because a program could determine that PARM was not > specified and take action different from PARM=''.
No. The only way to distinguish them is to scan the JCL or the internal text. > A competent programmer can know COBOL, C, PL/I, ...m but no Assembler. It helps if the languages that he knows are radically different from each other. As for "adequately", the acid test is to have readers that don't already know OS/360 ... z/OS, and see whether *they* understand that all of the forms are equivalent. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [[email protected]] on behalf of Paul Gilmartin [[email protected]] Sent: Saturday, April 15, 2023 3:49 PM To: [email protected] Subject: Re: JCL EXEC PARM= default? On Thu, 13 Apr 2023 17:01:40 -0600, Robert Raicer wrote: > >The z/OS MVS JCL Reference contains the prose shown below regarding >the PARM parameter of the JCL EXEC PGM statement. Yes, in order to >understand the details you need to look at the referenced >publication (z/OS MVS Programming: Assembler Services Guide). > When you,and slightly later I, entered the MVS arena it was reasonably expected that a competent programmer would know Assembler language (some of our co-workers called it "BAL".) and understand the control blocks it supported. That's no longer true. A competent programmer can know COBOL, C, PL/I, ...m but no Assembler. I've written bash, C, and Rexx for Linux on ARM, but I know not a single ARM machine instruction (I think it's little-endian.) The JCL Ref. should be language-neutral and say: Many programming languages allow a program to access the value of the "subparameter". The details should appear in a User's Guide for the specific language. If the PARM parameter is omitted, that subparameter value will be the empty string, as if PARM='' had been coded. > ... Thus, a length field value of zero >indicates no PARM text is present. > (Pedantic quibble on whether the length of a nonexistent string is defined.) >If the PARM parameter is effectively not present on the JCL EXEC PGM >statement the length field is zero. This is the "default" value. > >The length field is also zero when the PARM parameter is present and >its operand is an empty string, e.g., PARM=''. > Meticulously distinguishing the case of PARM is absent from PARM='', possibly because a program could determine that PARM was not specified and take action different from PARM=''. I'd fail that in a design review. > ... > The area referenced by this 31-bit pointer value resides in > 24-bit addressable storage (this is not clearly documented). > In days of yore it was not necessary to specify such things. COBOL long evaded the problem by not supporting 64-bit. Can you imagine an AMODE=31 Assembler program that would fail accessing PARM where AMODE=24 would succeed? In: Syntax PARM[.procstepname]=subparameter PARM[.procstepname]=(subparameter,subparameter) PARM[.procstepname]=('subparameter',subparameter) PARM[.procstepname]='subparameter,subparameter' Does it specify adequately whether the parentheses, commas, and apostrophes are passed to the program, whether nested sublists are permitted, and that only one parameter string is passed? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
