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

Reply via email to