But then the job must run on that system. I would like the option to run on any system using the identical JCL, but using the proper system-specific version of the DSN.
OK, I'm being extreme for my needs. But imagine a parallel sysplex running 6 systems. I guess those shops properly design things so that system specific datasets are not needed. Or they exist with the same DSN, but in different catalogs. I'll likely go with the system-specific ALIAS. If someone runs the job on the wrong system, then that's their worry. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Donald Johnson > Sent: Tuesday, February 22, 2011 8:40 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: cascading catalog dataset aliases. > > Another option is to use another alias - > SYS3.SOMEPROD.DEVL.LINKLIB for use > in development, separate from SYS3.SOMEPROD.PROD.LINKLIB in > production. Most > of the time, these both will point to the same base file > name, but in this > case, .DEVL will have the new version, and .PROD will have the current > version. > > *don* > > On Tue, Feb 22, 2011 at 9:21 AM, Staller, Allan > <allan.stal...@kbmg.com>wrote: > > > 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 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 > > ---------------------------------------------------------------------- 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
