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
