On Tue, 24 Sep 2013 00:33:57 -0400, Gerhard Postpischil wrote:
>
>> I was at least half-aware of the DOS-compatibility quote-framed DSNAME
>> value loophole, but if I remember correctly there were even more
>> limitations on the use of these quote-framed DSNAME values than Paul
>> Gilmartin has set out, including some contexts in which they could not
>> be used at all.
>
>True, but we were talking about removing data sets, so that how they got
>there may be interesting, but not relevant.
>
Quite true. Long ago, as a novice, I experimented witn quote-framed
DSNAMEs (what "loophole"? It's specified and documented behavior).
I found that I could create, but not catalog, data sets with names
containing interior blanks, NUL characters, long qualifiers, etc. Lazily,
I left them there. Within a few days, our admins came to me,
complaining that their removal process was unable to deal with them.
Similarly, perhaps by oversight, DISABLE(DSNCHECK) was for a while
the default. Now it's ENABLE(DSNCHECK). I asked here, once a site
enables DSNCHECK, will it be able to rename or uncatalog data sets
with uncheckable names, created in the interim while DSNCHECK was
not in force. An IBM answered, no, with DSNCHECK in force an
attempt to manipulate such data sets in any way will be rejected as
a syntax error.
In both case, the design is wrong: the process should first check for
the existence of the object before quibbling about the validity of its
name. In the rename case, it should check the syntactic validity
of the new name, but not the old. But beware:
http://xkcd.com/327/
BTW, I stumbled onto the behavior that even quote-framed in JCL
a DSNAME beginning with a period can not be allocated. What's
the motivation for this? Is it documented?
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
