John, We use the symbolic relate with systems symbols and then just use SYMUPDTE to change the symbols as needed w/o IPL on each system. DEFINE ALIAS (NAME(SYS5.DB2.DBP0.SDSNEXIT) - SYMBOLICRELATE(SYS5.DB2.&DBPRL..&DBPSS..&DBPLV..SDSNEXIT) ) Dennis
-----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of McKown, John Sent: Tuesday, February 22, 2011 8:11 AM To: [email protected] Subject: cascading catalog dataset aliases. This is likely another weird idea of mine. We have a two system basic sysplex. One system is designated as Production. The other as Development. We also have a "sandbox" z/OS which is not in the sysplex for sysprogs only. Our method to install a new product or release of an existing product is: (1) install and test on sandbox; (2) install and test on Development; (3) install and test on Production. 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. Now, the SYMBOLICRELATE alias occurred to me. That's where an ALIAS, such as SYS3.SOMEPROD.PROD.LINKLIB can include the &SYSNAME in the actual dataset name. DEF ALIAS(NAME(SYS3.SOMEPROD.PROD.LINKLIB) SYMBOLICRELATE(SYS3.SOMEPROD.SYS&SYSNAME..LINKLIB)) The problem is that I now have two versions of the same DSN. And they don't contain the version number. So it would be nice if I could have the above, and then do: DEF ALIAS(NAME(SYS3.SOMEPROD.SYSDEV1.LINKLIB) RELATE(SYS3.SOMEPROD.V1R2M0.LINKLIB)) and DEF ALIAS(NAME(SYS3.SOMEPROD.SYSPRD1.LINKLIB) RELATE(SYS3.SOMEPROD.V1R1M0.LINKLIB)) Then SYS3.SOMEPROD.PROD.LINKLIB would resolve to the proper DSN dependant on the executing system. I do undertand that I could have a different static symbolic such as &SOMEPROD on each system containing and use the SYMBOLICRELATE using &SOMEPROD instead of SYS&SYSNAME . But I don't know of a supported way to change the value of &SOMEPROD without an IPL. This is on z/OS 1.10. John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * [email protected] * 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 ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
