Interesting, to me, observation.
If I run a job with the following two IDCAMS commands, the second command, DEF ALIAS, fails with IDC3013I DUPLICATE DATA SET NAME IMPORT CONNECT - OBJECTS (( - TSSTV.ICF.VBV0001 - VOL(BV1075) DEVT(3390) - )) CAT(CATALOG.ICF.VI24CAT.MCAT) DEF ALIAS(NAME(TSSTV) RELATE(CATALOG.ICF.VTSTH01)) - CAT(CATALOG.ICF.VI24CAT.MCAT) However, if I run the DEF ALIAS followed by the IMPORT CONNECT, all is wonderful. Does this seem inconsistent to anybody else? I do have the multilevel alias active, with a level of 2. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: Interesting, to me, observation.
When you reverse them, does the USERCAT entry for VBV0001 get created in MCAT as directed or in VTSTH01 per the already defined alias? In the first case, you are trying to create an alias in a catalog when there is already a real entry with the same hlq in the catalog. In the second, you are creating a real entry in a catalog with instructions to ignore normal alias processing, including potential name conflicts. Both seem pathological. -Original Message- From: McKown, John Sent: Monday, February 25, 2008 11:57 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Interesting, to me, observation. If I run a job with the following two IDCAMS commands, the second command, DEF ALIAS, fails with IDC3013I DUPLICATE DATA SET NAME IMPORT CONNECT - OBJECTS (( - TSSTV.ICF.VBV0001 - VOL(BV1075) DEVT(3390) - )) CAT(CATALOG.ICF.VI24CAT.MCAT) DEF ALIAS(NAME(TSSTV) RELATE(CATALOG.ICF.VTSTH01)) - CAT(CATALOG.ICF.VI24CAT.MCAT) However, if I run the DEF ALIAS followed by the IMPORT CONNECT, all is wonderful. Does this seem inconsistent to anybody else? I do have the multilevel alias active, with a level of 2. -- 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
Re: Interesting, to me, observation.
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Schwarz, Barry A Sent: Monday, February 25, 2008 2:23 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Interesting, to me, observation. When you reverse them, does the USERCAT entry for VBV0001 get created in MCAT as directed or in VTSTH01 per the already defined alias? In the first case, you are trying to create an alias in a catalog when there is already a real entry with the same hlq in the catalog. In the second, you are creating a real entry in a catalog with instructions to ignore normal alias processing, including potential name conflicts. Both seem pathological. The ucat is created in the master cat, not in the catalog pointed to by the alias. I do have a CAT parameter on the IMPORT CONNECT to force it into the master cat. This came up and bit me because our storage admin created a UCAT with a bad name. I don't know why. All catalogs are supposed to start with CATALOG. For some reason, this one catalog starts with TSSTV. I consider this a bad mistake because that is a test DSN and is not protected by RACF from some programmer deleting it. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- 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
Re: Interesting, to me, observation.
I have this happen quite frequently. The reason is that the HLQ(s) already exist in the master catalog, so having an ALIAS pointing them to another catalog would cause the existing entries to become non-existent. I view this as a failsafe by VSAM catalog management. On Mon, 25 Feb 2008 14:30:28 -0600, McKown, John [EMAIL PROTECTED] wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Schwarz, Barry A Sent: Monday, February 25, 2008 2:23 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Interesting, to me, observation. When you reverse them, does the USERCAT entry for VBV0001 get created in MCAT as directed or in VTSTH01 per the already defined alias? In the first case, you are trying to create an alias in a catalog when there is already a real entry with the same hlq in the catalog. In the second, you are creating a real entry in a catalog with instructions to ignore normal alias processing, including potential name conflicts. Both seem pathological. The ucat is created in the master cat, not in the catalog pointed to by the alias. I do have a CAT parameter on the IMPORT CONNECT to force it into the master cat. This came up and bit me because our storage admin created a UCAT with a bad name. I don't know why. All catalogs are supposed to start with CATALOG. For some reason, this one catalog starts with TSSTV. I consider this a bad mistake because that is a test DSN and is not protected by RACF from some programmer deleting it. -- John McKown -- 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
