Re: Amusing JCL Oddity
The way JCL processing deals with multiple assignments of values to the same symbolic parameter in a JCL PROC is inconsistent with the way the same construct is dealt with for SET statements. IBM publication z/OS MVS JCL Reference (SA22-7597-13) is clear about the handling of SET statements: -- Chapter 25. SET Statement Purpose Use the SET statement to: . Define and assign initial values to symbolic parameters that are to be used when processing JCL statements. . Change or nullify the values of defined symbolic parameters (those that are defined on previous SET statements) by assigning new values or nullifying current values. The values that you assign to symbolic parameters on a SET statement are used in . Subsequent JCL statements in the JCL stream, and . Statements in subsequent procedures and nested procedures, when you: - Do not assign the values for the symbolic parameters on any PROC statements, or on any EXEC statements that call the procedures - Do not nullify the values for the symbolic parameters on any PROC statements, or on any EXEC statements that call the procedures. Symbolic parameter values that are assigned or nullified by calling EXEC or PROC statements override the values you assign or nullify with the SET statement. -- The following example illustrates the defined behavior of the SET statement when the same symbolic parameter is assigned multiple values, contrasted with the observed behavior of assigning multiple values to the same symbolic parameter on a JCL PROC statement. -- 06.03.00 JOB06223 MONDAY,12 JUL 2010 06.03.00 JOB06223 IRR010I USERID RAICER IS ASSIGNED TO THIS JOB. 06.03.00 JOB06223 ICH70001I RAICER LAST ACCESS AT 06:02:15 ON MONDAY, JULY 12, 2010 06.03.00 JOB06223 $HASP373 RAICERJ4 STARTED - INIT 10 - CLASS A - SYS SYE9 06.03.00 JOB06223 SMF000I RAICERJ4ECHOTSTPARM 06.03.00 JOB06223 $HASP395 RAICERJ4 ENDED -- JES2 JOB STATISTICS -- 12 JUL 2010 JOB EXECUTION DATE 22 CARDS READ 59 SYSOUT PRINT RECORDS 0 SYSOUT PUNCH RECORDS 3 SYSOUT SPOOL KBYTES 0.00 MINUTES EXECUTION TIME 1 //RAICERJ4 JOB (TSS4),'RAICER',MSGCLASS=T,CLASS=A, JOB06223 // MSGLEVEL=(1,1),NOTIFY=SYSUID //* //* -- //* -- //* - BOB RAICER- //* -- //* -- //* IEFC653I SUBSTITUTION JCL - (TSS4),'RAICER',MSGCLASS=T,CLASS=A,MSGLEVEL=(1,1),NOTIFY=RAICER 2 //PROCESS OUTPUT DEFAULT=YES,CLASS=*,JESDS=ALL,OUTDISP=HOLD //* 3 //TEST PROC SP1=100,SP2=200,SP1=800,SP2=900 //* //ECHO EXEC PGM=TSTPARM,PARM='SP1=SP1 SP2=SP2 SET1=SET1' //STEPLIB DD DISP=SHR,DSN=RAICER.PDSE.LOAD //PARMTEXT DD SYSOUT=* // PEND //* 4 //SET1 SET SET1='SET1' 5 //SET2 SET SET1='SET2' //* 6 //TRYIT EXEC TEST 7 ++TEST PROC SP1=100,SP2=200,SP1=800,SP2=900 ++* 8 ++ECHO EXEC PGM=TSTPARM,PARM='SP1=SP1 SP2=SP2 SET1=SET1' IEFC653I SUBSTITUTION JCL - PGM=TSTPARM,PARM='SP1=100 SP2=200 SET1=SET2' 9 ++STEPLIB DD DISP=SHR,DSN=RAICER.PDSE.LOAD 10 ++PARMTEXT DD SYSOUT=* STMT NO. MESSAGE 6 IEFC001I PROCEDURE TEST WAS EXPANDED USING INSTREAM PROCEDURE DEFINITION ICH70001I RAICER LAST ACCESS AT 06:02:15 ON MONDAY, JULY 12, 2010 IEF236I ALLOC. FOR RAICERJ4 ECHO TRYIT IGD103I SMS ALLOCATED TO DDNAME STEPLIB IEF237I JES2 ALLOCATED TO PARMTEXT IEF142I RAICERJ4 ECHO TRYIT - STEP WAS EXECUTED - COND CODE IGD104I RAICER.PDSE.LOAD RETAINED, DDNAME=STEPLIB IEF285I RAICER.RAICERJ4.JOB06223.D101.? SYSOUT IEF373I STEP/ECHO/START 2010193.0603 IEF374I STEP/ECHO/STOP 2010193.0603 CPU0MIN 00.01SEC SRB0MIN 00.00SEC VIRT12K SYS 336K EXT 4K SYS 15212K IEF375I JOB/RAICERJ4/START 2010193.0603 IEF376I JOB/RAICERJ4/STOP 2010193.0603 CPU0MIN 00.01SEC SRB0MIN 00.00SEC 2010-07-12 06:03:00.19 PARM text length: 001Bx SP1=100 SP2=200 SET1=SET2 -- To me, the JCL Reference is about as clear as mud with
Re: Amusing JCL Oddity
In 45e5f2f45d7878458ee5ca6796973355213...@usdaexch01.kbm1.loc, on 07/06/2010 at 07:27 AM, Staller, Allan allan.stal...@kbm1.com said: Why? What is syntactically incorrect with the below? The duplicate keywords. Without observing the procedure being called, it is impossible to determine if a syntax error is in place. No, it is trivial to detect the syntax error. The converter/interpreter will find syntax errors in JCL. Not this one. The classic JCL error. There are many classics. although commonly referred to as a JCL error There are many errors; syntax errors are a proper subset. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Amusing JCL Oddity
In 45e5f2f45d7878458ee5ca6796973355213...@usdaexch01.kbm1.loc, on 07/06/2010 at 08:22 AM, Staller, Allan allan.stal...@kbm1.com said: Again, what is syntactically incorrect? Duplicate keywords. Everything after PROC=A# is a parameter or nullification (V=) passed to the procedure. SP1=3000 is not passed to the procedure. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Amusing JCL Oddity
In 4c332ecc.90...@acm.org, on 07/06/2010 at 08:25 AM, Joel C. Ewing jcew...@acm.org said: This would be a semantic error (dealing with meaning), No, it would be a syntax error that is easier to catch with a semantic constraint than with classical parsing techniques. Do not confuse grammar with, e.g., CFG. Google for W grammar for an example of how to handle complex grammars without resorting to semantic constraints. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Amusing JCL Oddity
Why? What is syntactically incorrect with the below? Without observing the procedure being called, it is impossible to determine if a syntax error is in place. The converter/interpreter will find syntax errors in JCL. The classic JCL error. Job Failed due to file not found,. GDG BASE not found, etc. although commonly referred to as a JCL error is a JCL execution error . snip One would think that the following would generate a JCL error. Well, not on my system (zOS 1.08). Takes the first values for SP1 SP2. Go figure //ALLOC EXEC PROC=A#,SP1=100,SP2=100, // HLVL=USS,MLVL=SMPNTS,LLVL=ZOS108,SP1=3000,SP2=0500,V= /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Amusing JCL Oddity
On Tue, 6 Jul 2010 07:27:01 -0500, Staller, Allan wrote: Why? What is syntactically incorrect with the below? Without observing the procedure being called, it is impossible to determine if a syntax error is in place. //ALLOC EXEC PROC=A#,SP1=100,SP2=100, // HLVL=USS,MLVL=SMPNTS,LLVL=ZOS108,SP1=3000,SP2=0500,V= /snip I believe the OP reasonably expected such as: 07.08.31 JOB02068 IEFC452I jobname - JOB NOT RUN - JCL ERROR 877 ... IEFC009I KEYWORD SP1 IS MUTUALLY EXCLUSIVE WITH KEYWORD SP1 ON THE EXEC STATEMENT IEFC009I KEYWORD SP2 IS MUTUALLY EXCLUSIVE WITH KEYWORD SP2 ON THE EXEC STATEMENT -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Amusing JCL Oddity
Again, what is syntactically incorrect? Everything after PROC=A# is a parameter or nullification (V=) passed to the procedure. snip: Why? What is syntactically incorrect with the below? Without observing the procedure being called, it is impossible to determine if a syntax error is in place. //ALLOC EXEC PROC=A#,SP1=100,SP2=100, // HLVL=USS,MLVL=SMPNTS,LLVL=ZOS108,SP1=3000,SP2=0500,V= /snip I believe the OP reasonably expected such as: 07.08.31 JOB02068 IEFC452I jobname - JOB NOT RUN - JCL ERROR 877 ... IEFC009I KEYWORD SP1 IS MUTUALLY EXCLUSIVE WITH KEYWORD SP1 ON THE EXEC STATEMENT IEFC009I KEYWORD SP2 IS MUTUALLY EXCLUSIVE WITH KEYWORD SP2 ON THE EXEC STATEMENT -- gil /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Amusing JCL Oddity
This would be a semantic error (dealing with meaning), not a syntax error (the physical ordering of symbols). I believe the point is that the semantic error of repeating the same keyword parameter is detected as an error in some cases (like on a DD statement), so it is inconsistent that the same questionable semantics is not detected on an EXEC PROC statement. That the EXEC statement shows questionable intent does not even require expansion of the PROC, although expansion of the PROC would be required in order to determine if even one occurrence of the keyword parameter were valid. With a very quick check of the JCL Reference manual I didn't find an explicit explanation of this behavior for EXEC PROC, but I didn't look exhaustively and could easily have missed it. But even if it is documented, the original poster is correct that the behavior for handling repeated JCL statement keyword parameters is not always consistent. But then or course there are so many other cases where even the JCL syntax appears to have been randomly designed with its mishmash of keyword, positional, and positional-keyword parameters! Consistency in other areas shouldn't be expected! Joel C. Ewing On 07/06/2010 07:27 AM, Staller, Allan wrote: Why? What is syntactically incorrect with the below? Without observing the procedure being called, it is impossible to determine if a syntax error is in place. The converter/interpreter will find syntax errors in JCL. The classic JCL error. Job Failed due to file not found,. GDG BASE not found, etc. although commonly referred to as a JCL error is a JCL execution error . snip One would think that the following would generate a JCL error. Well, not on my system (zOS 1.08). Takes the first values for SP1 SP2. Go figure //ALLOC EXEC PROC=A#,SP1=100,SP2=100, // HLVL=USS,MLVL=SMPNTS,LLVL=ZOS108,SP1=3000,SP2=0500,V= /snip ... -- Joel C. Ewing, Fort Smith, ARjcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Amusing JCL Oddity
John, Actually, it is documented to work that way. According to the JCL reference, if the same symbolic keyword is present multiple time, the value used is that provided by the first occurrence. Checking back through some old manuals, this has been the case since at least OS/360 r21.7. John P. Baker -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Mattson Sent: Friday, July 02, 2010 3:32 PM To: IBM-MAIN@bama.ua.edu Subject: Amusing JCL Oddity One would think that the following would generate a JCL error. Well, not on my system (zOS 1.08). Takes the first values for SP1 SP2. Go figure //ALLOC EXEC PROC=A#,SP1=100,SP2=100, // HLVL=USS,MLVL=SMPNTS,LLVL=ZOS108,SP1=3000,SP2=0500,V= -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Amusing JCL Oddity
It seems to me that it is JCL's job to catch the error because the writer of the PROC has no opportunity to do so. It's an obvious opportunity for a dumb user error -- and it's the job of the system (broadly defined to include JCL, the sysprog who wrote the PROC, etc.) to diagnose it. Quibbling about syntax versus semantics does not help the user mystified why his JCL change did not have any apparent affect. The assembler macro facility -- which uses a syntax that is obviously a first cousin to the JCL PROC facility -- would catch the error at the macro invocation level. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Staller, Allan Sent: Tuesday, July 06, 2010 5:27 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Amusing JCL Oddity Why? What is syntactically incorrect with the below? Without observing the procedure being called, it is impossible to determine if a syntax error is in place. The converter/interpreter will find syntax errors in JCL. The classic JCL error. Job Failed due to file not found,. GDG BASE not found, etc. although commonly referred to as a JCL error is a JCL execution error . snip One would think that the following would generate a JCL error. Well, not on my system (zOS 1.08). Takes the first values for SP1 SP2. Go figure //ALLOC EXEC PROC=A#,SP1=100,SP2=100, // HLVL=USS,MLVL=SMPNTS,LLVL=ZOS108,SP1=3000,SP2=0500,V= /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Amusing JCL Oddity
On Tue, 6 Jul 2010 06:54:54 -0700, Charles Mills wrote: It seems to me that it is JCL's job to catch the error because the writer of the PROC has no opportunity to do so. It's an obvious opportunity for a dumb user error -- and it's the job of the system (broadly defined to include JCL, the sysprog who wrote the PROC, etc.) to diagnose it. Quibbling about syntax versus semantics does not help the user mystified why his JCL change did not have any apparent affect. The assembler macro facility -- which uses a syntax that is obviously a first cousin to the JCL PROC facility -- would catch the error at the macro invocation level. It's a prevalent habit of coders to exploit naive parameter list parsers by writing scripts which simply append overriding key/value pairs to the end of a default parameter string. Historically, Linkage Editor and Assembler H permitted this in PARM strings, allowing the later value of the keyword to prevail. With the advent of Binder (IIRC; perhaps it was HLASM; perhaps both), duplicate keys in the PARM string were treated as errors. This was swiftly reverted to the earlier behavior, likely by APAR. But JCL differs from the mode in using the earlier value rather than the later. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Amusing JCL Oddity
Paul Gilmartin paulgboul...@aim.com wrote in message news:listserv%201007060926010003.0...@bama.ua.edu... On Tue, 6 Jul 2010 06:54:54 -0700, Charles Mills wrote: It seems to me that it is JCL's job to catch the error because the writer of the PROC has no opportunity to do so. It's an obvious opportunity for a dumb user error -- and it's the job of the system (broadly defined to include JCL, the sysprog who wrote the PROC, etc.) to diagnose it. Quibbling about syntax versus semantics does not help the user mystified why his JCL change did not have any apparent affect. The assembler macro facility -- which uses a syntax that is obviously a first cousin to the JCL PROC facility -- would catch the error at the macro invocation level. It's a prevalent habit of coders to exploit naive parameter list parsers by writing scripts which simply append overriding key/value pairs to the end of a default parameter string. Historically, Linkage Editor and Assembler H permitted this in PARM strings, allowing the later value of the keyword to prevail. With the advent of Binder (IIRC; perhaps it was HLASM; perhaps both), duplicate keys in the PARM string were treated as errors. This was swiftly reverted to the earlier behavior, likely by APAR. But JCL differs from the mode in using the earlier value rather than the later. -- gil And then there is also the parsing of parmlib members, where a parameter can occur multiple times in one member or multiple times in several sequentially processed members (IEASYSxx). The rules are as diverse as possible: select the first value, select the last value, add the values of all occurances of the parameter or not accept multiple occurances of a parameter. So you are subjected to the applicatin coder's view on what is desirable. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Amusing JCL Oddity
I've been writing and invoking macros since Assembler D (DOS/360 1968) and I don't believe that duplicated keyword parameters were ever accepted. I could be wrong. Somehow for a parameter *file* like PARMLIB I'm willing to accept that duplicates should be accepted and that the last value should prevail. (If the first value prevails, then the processing software must know that the value has already been provided and should diagnose the duplication.) You should be able to override the values in parmfile.one by appending parmfile.two. It's like real life. In a conversation or an e-mail I might at first say see you next Tuesday at 10 and a little later say I might be running late, so make it between 10 and 11. You would not ignore the latter value because I had already provided an earlier value. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Vernooij, CP - SPLXM Sent: Tuesday, July 06, 2010 7:33 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Amusing JCL Oddity Paul Gilmartin paulgboul...@aim.com wrote in message news:listserv%201007060926010003.0...@bama.ua.edu... It's a prevalent habit of coders to exploit naive parameter list parsers by writing scripts which simply append overriding key/value pairs to the end of a default parameter string. Historically, Linkage Editor and Assembler H permitted this in PARM strings, allowing the later value of the keyword to prevail. With the advent of Binder (IIRC; perhaps it was HLASM; perhaps both), duplicate keys in the PARM string were treated as errors. This was swiftly reverted to the earlier behavior, likely by APAR. But JCL differs from the mode in using the earlier value rather than the later. -- gil And then there is also the parsing of parmlib members, where a parameter can occur multiple times in one member or multiple times in several sequentially processed members (IEASYSxx). The rules are as diverse as possible: select the first value, select the last value, add the values of all occurances of the parameter or not accept multiple occurances of a parameter. So you are subjected to the applicatin coder's view on what is desirable. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Amusing JCL Oddity
I might at first say see you next Tuesday at 10 and a little later say I might be running late, so make it between 10 and 11. You would not ignore the latter value because I had already provided an earlier value. I might if I didn't check my e-mail regularily. Also, relating programming decisions to real life is always subject to reality checks (mine was returned nsf) - I'm a SuperHero with neither powers, nor motivation! Kimota! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
