-----Original Message----- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Martin Kline Sent: Tuesday, December 15, 2009 9:40 AM To: IBM-MAIN@bama.ua.edu Subject: Could DSNAME length restriction be bypassed if catalog allowed longer ALIAS names?
I'm just throwing this idea on the table, and expect either little interest or strong opposition. What if catalog support allowed ALIAS names to exceed 44 characters? First, yes, I did search the archives. Second, Yes I understand the implications. The cost and impact of supporting long alias names (though still not small) would be considerably less than the cost of expanding actual data set names. I just came up with this before my second cup of coffee, so the idea is still cooking. Last time I checked, the impact to IDCAMS and catalog records would mostly involve relaxing the syntax restrictions. The impact to JCL conversion would be similar. JCL processing would have to allow for longer names prior to catalog search, and actual (shorter) names could be stored in places like the JFCB. Certain SMF records might have to change. Expanding a little bit, SMS processing could potentially define long names as aliases automatically and generate actual names using some schema like temporary name generation. Doing this would mask the effort of mapping long and short names from the end user, effectively allowing long names without any special user changes. As for a business case to get IBM to implement- oh well. It was just a thought. As a local business case - There are those twice-a-year instances when users can't seem to create a meaningful and acceptable name in under 45 characters. So, I guess I won't be creating any usermods today . . . but if I still had those microfiche . . . >Subject: Re: IDC3203IITEM 'xxx' DOES NOT ADHERE TO RESTRICTIONS >From: "McKown, John" <john.mck...@healthmarkets.com> >Reply-To: IBM Mainframe Discussion List <IBM-MAIN@BAMA.UA.EDU> >Date: Mon, 14 Dec 2009 10:10:14 -0600 >Not likely to be done. That would require a complete rewrite of the VTOC. >The DSN is a 44 byte hardware key in the VTOC. I cannot imagine how IBM >would ever compatibly change the DSN length. Short of creating an entirely >new, incompatable, interface where something (perhaps in the record which >points to the VTOC) indicates that this is a "new VTOC" formatted volume. >And that would require updates to the entire world. Who's gonna pay? I'd >rather they support SAN DASD in z/OS (which means FBA). ---------------------------------------------------------------------- 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 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. ---------------------------------------------------------------------- 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
