Re: cascading catalog dataset aliases.
In 45e5f2f45d7878458ee5ca6796973355b85...@usdaexch01.kbm1.loc, on 02/22/2011 at 08:21 AM, Staller, Allan allan.stal...@kbmg.com said: 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. That's okay if the product only has one library. For the general case I'd advice an INCLUDE of a member with a SET for the appropriate version, with symbolic references in the invoking JCL. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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
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.SYSSYSNAME..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 SYSSYSNAME . 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 * 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 -- 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
Re: cascading catalog dataset aliases.
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
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.comwrote: 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
Re: cascading catalog dataset aliases.
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Staller, Allan Sent: Tuesday, February 22, 2011 8:22 AM To: IBM-MAIN@bama.ua.edu Subject: Re: cascading catalog dataset aliases. 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. I considered that. But the PROCLIB is resolved at JCL read time, not at execution time. So if I submit the JCL on Prod (where CA-7 runs), it uses the Prod version of the PROC. Even if the job is SYSAFF'd to run on Development. This method would work if Prod and Development ran the identical versions at all times. And would save JCL changes for a simple case. But the simple use of an ALIAS would do the same. The desire is to use the correct DSN dependant on the running system at the time of execution. Without any JCL change needed. If fact, to have it run with the system-dependant DSN even if the job's SYSAFF is changed dynamically. In program terms: Late Binding or Dynamic Binding where the DSN name is not resolved until the last possible instant. -- 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 -- 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
Re: cascading catalog dataset aliases.
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:IBM-MAIN@bama.ua.edu] On Behalf Of McKown, John Sent: Tuesday, February 22, 2011 8:11 AM To: IBM-MAIN@bama.ua.edu 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.SYSSYSNAME..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 SYSSYSNAME . 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 * 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 -- 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
Re: cascading catalog dataset aliases.
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.comwrote: 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
Re: cascading catalog dataset aliases.
If management requires the dsnames to include the version number, then doesn't the JCL have to be changed anyway to avoid confusion? For example, if you're running V1R1 and want to upgrade to V1R2, if you use aliases then the JCL would say V1R1 but would resolve to V1R2. And you know who gets the blame when there's a problem. - Don Imbriale On Tue, Feb 22, 2011 at 9:52 AM, McKown, John john.mck...@healthmarkets.com wrote: 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 -- 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
Re: cascading catalog dataset aliases.
John, I think that the aliases can work. Not so sure about the dynamic portion. Seems like it would be easier to create a short procedure for each product that would fix up the aliases by environment that would be used when you are doing maintenance to a product. SYS1.V1R0.LINKLIB might have an alias of SYS1.PROD.LINKLIB SYS1.V1R1.LINKLIB might have an alias of SYS1.DEV.LINKLIB. Ultimately, the migration would have SYS1.V1R1.LINKLIB have 2 aliases .. one for dev .. one for prod. And if you wanted to keep things consistent.. then one for your tech services system(s). I would have the JCL point to some DEV or PROD version as well. 1 JCL change.. lots of alias changes. Although.. is it a pick your poison that works best for you and your environment. If you have strong control of your JCL... maybe JCL change is a better choice. If you need to slide things in... and avoid JCL .. then aliases may be the trick. I like catalog tricks in general .. they are tons of fun. Of course there are those that are driven crazy by them. I used to be a stupid catalog tricks (Dave Letterman anyone?) were always the way kind of person. But I think now that it is better to step back and think about your environment and what will work best for the environment. Cheers, Rob -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Don Imbriale Sent: Tuesday, February 22, 2011 1:11 PM To: IBM-MAIN@bama.ua.edu Subject: Re: cascading catalog dataset aliases. If management requires the dsnames to include the version number, then doesn't the JCL have to be changed anyway to avoid confusion? For example, if you're running V1R1 and want to upgrade to V1R2, if you use aliases then the JCL would say V1R1 but would resolve to V1R2. And you know who gets the blame when there's a problem. - Don Imbriale On Tue, Feb 22, 2011 at 9:52 AM, McKown, John john.mck...@healthmarkets.com wrote: 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 -- 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
Re: cascading catalog dataset aliases.
If management requires the dsnames to include the version number I have two concerns with this: 1. Shouldn't management tell you what to do, not how to do it? 2. What is the benefit of having versions in the Production dsn? - Ted MacNEIL eamacn...@yahoo.ca -- 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
Re: cascading catalog dataset aliases.
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Tuesday, February 22, 2011 1:38 PM To: IBM-MAIN@bama.ua.edu Subject: Re: cascading catalog dataset aliases. If management requires the dsnames to include the version number I have two concerns with this: 1. Shouldn't management tell you what to do, not how to do it? Our manager is also a techie and still needs to do techie stuff because we are short handed. He is still a good techie. 2. What is the benefit of having versions in the Production dsn? - Ted MacNEIL eamacn...@yahoo.ca It is immediately apparent from the DSN which version of the program is running. I.e. we get asked: What version of ... are you running? Instead of needing to look it up in some document (assuming we are not up on the version), we can use ISPF option 3.4 to look at SYS3.product_name and the 3rd node is the VersionReleaseModification level. Also, the job has this in the JESMSGS dataset and JCL so we know what release was run even if we don't have a report. Or if the report does not contain the release information. Not all products put the release information in the report itself. We sometimes keep multiple versions around for backup. -- 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 -- 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
Re: cascading catalog dataset aliases.
On Tue, 22 Feb 2011 08:10:55 -0600, McKown, John wrote: Suppose the DSN is SYS3.SOMEPROD.V1R1M0.LINKLIB. Make an alias called SYS3.SOMEPROD.PROD.LINKLIB which points to the SYS3.SOMEPROD.V1R1M0.LINKLIB 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. You can use any symbol in the name. DEF ALIAS(NAME(SYS3.SOMEPROD.PROD.LINKLIB) SYMBOLICRELATE(SYS3.SOMEPROD.SYSSYSNAME..LINKLIB)) You want: DEF ALIAS(NAME(SYS3.SOMEPROD.PROD.LINKLIB) SYMBOLICRELATE(SYS3.SOMEPROD.SOMEPRD..LINKLIB)) Note that the alias is eight characters, including the ampersand. I don't know of a supported way to change the value of SOMEPROD without an IPL. This is on z/OS 1.10. Dennis mentioned SYMUPDTE. Search the archives for it. It is now called IEASYMUP. I have used it and it works well for this purpose. See: http://www.redbooks.ibm.com/abstracts/SG247328.html -- Tom Marchant -- 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
Re: cascading catalog dataset aliases.
The obvious advantage to #2 is that it gives you the benefit of allowing you to change hundreds or thousands of JCL members for every install. -- Eric Bielefeld Systems Programmer Ted MacNEIL eamacn...@yahoo.ca wrote: If management requires the dsnames to include the version number I have two concerns with this: 1. Shouldn't management tell you what to do, not how to do it? 2. What is the benefit of having versions in the Production dsn? - Ted MacNEIL eamacn...@yahoo.ca -- 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
Re: cascading catalog dataset aliases.
I have been involved with this discussion a few times in the past. I have been fortunate to resolve it by indicating that the install libraries would contain the release/version identifier but the run time libraries would not. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Eric Bielefeld Sent: Tuesday, February 22, 2011 3:25 PM To: IBM-MAIN@bama.ua.edu Subject: Re: cascading catalog dataset aliases. The obvious advantage to #2 is that it gives you the benefit of allowing you to change hundreds or thousands of JCL members for every install. -- Eric Bielefeld Systems Programmer Ted MacNEIL eamacn...@yahoo.ca wrote: If management requires the dsnames to include the version number I have two concerns with this: 1. Shouldn't management tell you what to do, not how to do it? 2. What is the benefit of having versions in the Production dsn? - Ted MacNEIL eamacn...@yahoo.ca -- 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 The information contained in this e-mail may contain confidential and/or privileged information and is intended for the sole use of the intended recipient. If you are not the intended recipient, you are hereby notified that any unauthorized use, disclosure, distribution or copying of this communication is strictly prohibited. If you received this e-mail in error, please reply to sender and destroy or delete the message and any attachments. Thank you. -- 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
