DSNAME Syntax (was: IEBCOPY - MOVE)
On Mon, 23 Sep 2013 09:08:25 -0400, Gerhard Postpischil wrote: ... And I think Mr. Gilmore had too many asterisks. The pattern I recall was to prepend *. until a unique name resulted (IIRC, giving things like *.*.*.jobname.other). I had a home-grown utility, run daily, that scratched temporary data sets, and *. was one of the patterns it looked for, in addition to the more common SYSn. Nowadays, might a viable practice be to scratch anything that's neither catalogued nor allocated? Has IBM published a warning that such data set names are reserved for IBM, and not to be used by application programmers, or does IBM rely on common knowledge of programmers to avoid them? Is there a similar part of the name space reserved for ISVs? I know that in UNIX there is a convention (not published as a standard?) that pathnames incorporating a registered domain name (rewritten big-endian) are reserved for the registrant. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DSNAME Syntax (was: IEBCOPY - MOVE)
Historically, the use of a DSN{AME]= value like
*.*.GUBBINS
was not possible for an ordinary application programmer, whose JCL
would have been rejected as in error if it had contained such a DSN=
value. Such practices were once common for member names too. IBM for
long distributed CICS materials as PDS members having formally illicit
names like MCGUFFN¢. The motivation was, of course, to avoid names
that conflicted with those already used by a customer.
The notorious retention date of 99.365 is another, slightly different,
example of the misuse of as coding scheme to encode information it was
not designed to represent.
I should like to think that we were now q
On 9/23/13, Paul Gilmartin paulgboul...@aim.com wrote:
On Mon, 23 Sep 2013 09:08:25 -0400, Gerhard Postpischil wrote:
...
And I think Mr. Gilmore had too many asterisks. The pattern I recall was
to prepend *. until a unique name resulted (IIRC, giving things like
*.*.*.jobname.other). I had a home-grown utility, run daily, that
scratched temporary data sets, and *. was one of the patterns it looked
for, in addition to the more common SYSn.
Nowadays, might a viable practice be to scratch anything
that's neither catalogued nor allocated?
Has IBM published a warning that such data set names
are reserved for IBM, and not to be used by application
programmers, or does IBM rely on common knowledge
of programmers to avoid them?
Is there a similar part of the name space reserved for
ISVs? I know that in UNIX there is a convention (not
published as a standard?) that pathnames incorporating
a registered domain name (rewritten big-endian) are
reserved for the registrant.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
John Gilmore, Ashland, MA 01721 - USA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DSNAME Syntax (was: IEBCOPY - MOVE)
On 9/23/2013 11:07 AM, John Gilmore wrote:
Historically, the use of a DSN{AME]= value like
*.*.GUBBINS
was not possible for an ordinary application programmer, whose JCL
would have been rejected as in error if it had contained such a DSN=
value.
Sorry to disagree, but application programmers had wide leeway in
creating funny names. For DOS compatibility, a DSN was allowed to be
quoted, and could contain a number of special characters that would fail
in JCL unquoted. With a little more work, any character combination
could be used in a DSN when allocating with SVC 32.
Gerhard Postpischil
Bradford, Vermont
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DSNAME Syntax (was: IEBCOPY - MOVE)
On 9/23/2013 10:27 AM, Paul Gilmartin wrote: Nowadays, might a viable practice be to scratch anything that's neither catalogued nor allocated? I didn't want to write a monograph, but keep the response brief. The scratch program in question considers the (installation's) classification of the volume, the allocation or last use date, etc. Some volumes are classified as customer owned, and those either do not get cleaned automatically, or only on request. Storage packs may be used only with known high-level indices, etc. Sort work packs get cleaned unconditionally when not in use, ad nauseam. An uncataloged data set on an SMS volume is a serious problem, better examined on a case by case basis. On a non-SMS volume it's fair game if it has a temporary name, or if it hasn't been used in some time we try to locate the owner and find out what the intent is. Conversely a catalog entry for a non-existent data set is removed during weekly clean up. Has IBM published a warning that such data set names are reserved for IBM, and not to be used by application programmers, or does IBM rely on common knowledge of programmers to avoid them? I'm not aware of a formal declaration, but the format is explained in several publications. But I have run into an analogous problem with unlabeled tapes. IBM documentation (Tape Labels?) states that the system will generate unique serials for NL tapes, in the form Ln, but I've never met a customer who's aware of that. In one case a customer, working for a firm whose name started with L, had a tape overwritten due to bad naming. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DSNAME Syntax (was: IEBCOPY - MOVE)
I was not using the word 'ordinary' in a pejorative or even deprecatory way. I intended only to exclude very savvy people writing application code in assembly language and their like. 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. --jg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
