I suggest the JCL include statement. Much easier to use and less to change (After the initial pain). Change the JCLLIB statement to point to the appropriate STEPLIBS member. Modify the STEPLIBS member as required.
e.g. // JCLLIB ORDER=(PROCLIB1, PROCLIB2) //STEP1 EXEC PGM=SOMETHING INCLUDE MEMBER=STEPLIBS // rest of jcl MEMBER STEPLIBS in PROCLIB1 //STEPLIB DD DSN= SYS3.SOMEPROD.V1R1M0.LINKLIB // DD .... MEMBER STEPLIBS in PROCLIB2 //STEPLIB DD DSN= SYS3.SOMEPROD.V2R1M0.LINKLIB // DD .... HTH. <snip> Now, if the product goes into the LNKLST, implementing on Development is easy. Just update the LNKLST on Development and run. This is because we don't use STEPLIB in this case. But not all products go on the LNKLST. Our shop standard, which is set in stone (at least until we change management again), is that the release level of the product must be included in the DSN so that it is obvious. This means when we upgrade, we do JCL changes to point to the new DSN. Well, my first thought was to have an alias. Suppose the DSN is SYS3.SOMEPROD.V1R1M0.LINKLIB. Make an alias called SYS3.SOMEPROD.PROD.LINKLIB which "points" to the SYS3.SOMEPROD.V1R1M0.LINKLIB. The same for any other DSNs other than LINKLIB. The refer to SYS3.SOMEPROD.PROD.LINKLIB in the JCL. Hum. The problem occurs in that the SYS3 catalog is shared. So if I want to upgrade to V1R2M0 in the Development system only, I have a problem. I need to change the JCL for testing. </snip> ---------------------------------------------------------------------- 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
