Peter Relson wrote on 12/27/2011 4:49 AM:
What PARMLIB member is it that allows>8 characters between periods?
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2c190/8.6.5.1
As Paul Gilmartin posted, this is a reference to:
MODIFY CATALOG,DISABLE(DSNCHECK)
FWIW, I wouldn't bet that most z/OS componentry pays attention to this.
Back when I was working at the University of Southern California,
which ran many different operating systems, I submitted a "REQUEST"
(essentially a single-customer version of a SHARE requirement) with
the following core: Allow, at installation option, relaxation of most
restrictions on MVS dsnames catalloged in ICF catalogs. IBM should
create an installation-replaceable dsname validity checking routine,
supplied in source form. All MVS components which validity check
dsnames should call this routine.
After a two-hour conference call with the managers of a number of MVS
components, their managers, and their managers, IBM gave USC the
official response "That's a reaonable request but we're not going to
do it." When pressed for "why not?", eventually IBM told us that it's
because there were upwards of a hundred different places that all did
dsname checking. That was the whole point of the REQUEST- centralize
it into one place. Apparently 25 years later we're still no closer to
having it done right. I was willing to let IBM piece-meal it, if they
would just create the routine and then accept and fix apars opened
against each component which didn't call that routine.
IBM was not interested in any way. A few years later USC got rid of
the MVS system. Every other system except VM/CMS allowed nearly
unrestricted dsnames. This may not have been the cause of USC
ditching the MVS system, but it was emblematic of perceived
user-unfriendliness of the system. Most user-unfriendliness of MVS
can be masked by ISPF and REXX wrappers. The dsname problem can't
be. IBM really needs to implement the routine that I asked for;
there's simply excuse for the same function to be independently coded
in 100+ different places.
It
might be entertaining to try if you can make sure not to pollute your
existing catalogs The support says only that it will allow you to create
data sets (it does not actually say that you can necessarily use them
wherever you'd want to use them). And it even warns you that you may not
be able to remove them from the catalog..
If there are catalog entries stuck in a catalog, one can use the
CatalogRecoveryPlus or Advanced Catalog Management MERGECAT command to
move the records to a junk catalog and then just delete the junk catalog.
I'll admit that I didn't even know that this option existed. I know of
many places that validate data set names that have no knowledge of the
state of this option.
See above. Please. Please. Please. Fixing all of those "many
places" is absolutely the wrong way to go. Create the central
callable routine, and change everything to call it.
Peter Relson
z/OS Core Technology Design
/Leonard
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
