John Mattson wrote: > Somewhere between OS390 2.10 (our old system) and zos 1.08 (our > new system) the JCL interpreter changed.
Funny you should notice that ... was wondering if anybody would. The change was first introduced in z/OS 1.8. It worked the old way in z/OS 1.7. When I first found this, I tested it all the way back to z/OS 1.4. > So, is this a "bug" or "working as designed"? IBM will have to say, unless someone can find something in the z/OS 1.8+ SRLs that describes this new behavior. The old behavior adheres to the rules of JCL in effect since OS/360 Release 13 MVT (where it was first possible to have multiple in-stream [DD *] data sets). But I have an opinion: it's a WAD, as I will attempt to demonstrate. Regardless, IT'S STILL DOCUMENTED TO WORK THE OLD WAY. Since it is hard for me to believe that this behavior is not intentional, you probably have as your only recourse a Readers' Comments form submission -- but all that will do is just get this new behavior documented. Note that page 12-14 of the "z/OS V1R9.0 MVS JCL Reference" SRL _still_ states: "To override more than one DD statement in a procedure, place the overriding DD statements in the same order as the overridden DD statements in the procedure." That is the OLD rule and behavior, not the NEW (as of z/OS 1.8). This behavior occurs even if you provide a //SYSIN DD * statement in front of the second in-stream data set. Doing so merely causes the statement that would be automatically generated had one not been provided NOT to be generated (obviously, as you would expect). So, the fact that you have a "missing" //SYSIN DD is not relevant, and does not affect its behavior. The results are identical. Thus, if you submit this JCL: //AFITJLMU JOB CLASS=S,MSGCLASS=X,TYPRUN=SCAN //UNVTEST PROC //PS001 EXEC PGM=IEFBR14 //REMOTE DD DISP=SHR,DSN=MSYS.UCMD.REMOTE //SYSIN DD DISP=SHR,DSN=QALC.UNVLIB //MYSCRIPT DD DISP=SHR,DSN=QALC.UNVLIB //SYSPRINT DD SYSOUT=* // PEND --------------------- //* //JS001 EXEC PROC=UNVTEST //MYSCRIPT DD * WHATEVER /* //SYSIN DD * WHEREEVER /* where the overriding DD statements [i.e., MYSCRIPT and SYSIN] are NOT "in the same order as the overridden DD statements in the procedure" then, starting with z/OS 1.8, both DD statements in the PROC _are_ overridden, despite the fact that they aren't explicitly [or implicitly] presented in the "same order." This is clearly an intentional change in behavior, and can only be explained as someone's unthinking idea of "how it should be working" I suspect. The fact that this behavior is not documented (even in the SRL for the next release after the behavior was first introduced) indicates to me that it was not thought to be of any importance. They probably actually thought they were doing us a big favor. But, wait! It's only going to get worse. Hang on to your hats, folks. I had some job streams where multiple in-stream data sets with the same DDname are defined (intentionally). So, I tested this with a few of those jobs. What the converter apparently does is to reach down into the JOB's JCL where it finds the first match on an overriding (it thinks!) DDname and then reorders the JCL to match that in the PROC! Yes, you read that right. I did not make that up. It reorders the input JCL! Programs that depend upon different or matching DDnames in the TIOT in a specific order will now be broken (but only if they are invoked using a "model" [so to speak] PROC). In-stream JCL that does not use a PROC apparently still works as before (no DD statements are reordered). But, I didn't want my existing "SYSIN" DD statement in the PROC to be overridden, WHICH IS WHY I PUT IT AFTER A DD STATEMENT THAT IS IN THE PROC AT THE END, SO THAT THE "NEW" DD STATEMENT IN THE INPUT STREAM WOULD GET _ADDED_ TO THE STEP'S JCL! (Apparently, whoever made this change did not read, nor understand, the distinction between OVERRIDING and ADDING JCL DD statements to a step in a PROC -- a concept that has been cast in concrete [at least until now] since 1965. So, IBM broke the old behavior. Normally, this would make me consider it to be a bug. But it can't possibly be a bug. Too much code had to be written to make it work like this. Thus, it must be a feature. In fact, further testing reveals that this behavior is general and ALL overriding DD statements in the instream JCL are just simply reordered to match those in the PROC. For example, if you submit this JCL: //UNVTEST PROC //PS001 EXEC PGM=IEFBR14 //FIRSTDD DD DISP=SHR,DSN=SYS1.LPALIB //REMOTE DD DISP=SHR,DSN=SYS1.PROCLIB //SYSIN DD DISP=SHR,DSN=SYS1.PARMLIB //MYSCRIPT DD DISP=SHR,DSN=SYS1.LINKLIB //SYSPRINT DD SYSOUT=* // PEND --------------------- //* //JS001 EXEC PROC=UNVTEST //MYSCRIPT DD * WHATEVER /* //SYSIN DD DISP=SHR,DSN=EXPLIC1 EXPLICIT SYSIN 1 IN INPUT JOB //SYSIN DD DISP=SHR,DSN=EXPLIC2 EXPLICIT SYSIN 2 IN INPUT JOB //REMOTE DD DISP=SHR,DSN=REMOTE EXPLICIT REMOTE IN INPUT JOB //FIRSTDD DD DISP=SHR,DSN=LPALIB1 DATA (THIS WILL GENERATE AN IMPLICIT SYSIN 3 IN THE JCL) /* // it will be processed like this: 2 //UNVTEST PROC //PS001 EXEC PGM=IEFBR14 //FIRSTDD DD DISP=SHR,DSN=SYS1.LPALIB //REMOTE DD DISP=SHR,DSN=SYS1.PROCLIB //SYSIN DD DISP=SHR,DSN=SYS1.PARMLIB //MYSCRIPT DD DISP=SHR,DSN=SYS1.LINKLIB //SYSPRINT DD SYSOUT=* // PEND --------------------- //* 3 //JS001 EXEC PROC=UNVTEST 4 ++UNVTEST PROC 5 ++PS001 EXEC PGM=IEFBR14 6 //FIRSTDD DD DISP=SHR,DSN=LPALIB1 +/FIRSTDD DD DISP=SHR,DSN=SYS1.LPALIB 7 //REMOTE DD DISP=SHR,DSN=REMOTE EXPLICIT REMOTE IN INPUT JOB +/REMOTE DD DISP=SHR,DSN=SYS1.PROCLIB 8 //SYSIN DD DISP=SHR,DSN=EXPLIC1 EXPLICIT SYSIN 1 IN INPUT JOB +/SYSIN DD DISP=SHR,DSN=SYS1.PARMLIB 9 //MYSCRIPT DD * +/MYSCRIPT DD DISP=SHR,DSN=SYS1.LINKLIB 10 ++SYSPRINT DD SYSOUT=* 11 //SYSIN DD DISP=SHR,DSN=EXPLIC2 EXPLICIT SYSIN 2 IN INPUT JOB 12 //SYSIN DD * GENERATED STATEMENT As you can see, the converter has "matched up" the overriding DD statements in the input JCL with those in the PROC, even to the point of completely reordering the instream DD statements. This is completely new behavior; I conclude that it MUST be intentional. A bug could not have created this behavior. Unfortunately, it breaks existing JCL. And it's apparently NOT documented. (At least I can't find anything that does so, and the old rule is still stated in the 1.9 SRL, so I doubt that it is documented anywhere.) But, 42 years of experience with IBM tells me that this is how it is going to be, so I'm going to have to find some other way of "hiding" in-stream data sets. (You're not the only one to use this technique. It's not unheard of. I've seen it in many "production" JCL streams. Other folks are going to get burned by this, but I have no clue how many. I would hope not many.) I wonder if anybody at IBM even thought about the possibility that this slick new feature might break existing customer JCL. Probably not. They probably got an award just for their bright idea. Oh, well. -- WB ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html