As a microfische job, it is a collection of printouts, not used for input. On Sat, Sep 19, 2020 at 8:51 AM Paul Gilmartin <[email protected]> wrote: > > On Fri, 18 Sep 2020 23:10:24 -0500, Brian Westerman wrote: > > >I don't see that you can do that with tapes, the hdr1 won't match the new > >DSN. > > > So the tapes are labeled. Alas. > > I'm curious: how do the users access those data sets in subsequent jobs? > Examine the logs of the creating jobs for allocation messages and code > VOL=SER in the later jobs? > > Cataloging unique DSNs hardly alleviates the problem -- it might > aggravate it: 3 times as many keystrokes to modify -- two DSN > qualifiers versus one volser. > > How would you deal with DSN collisions? With "thousands" of > generated names this is highly likely: > https://en.wikipedia.org/wiki/Birthday_problem > > If you do nothing, one job with DISP=(NEW,CATLG) will wait for the > other to complete; write the data set then get NOT CATALOGUED. > > There's a meta-process problem here. At some point programmers > should have been instructed not to create thousands of uncatalogued > data sets with identical names. > > If you adopt unique catalogued DSNs, might DASD be a medium > preferable to tape? > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN
-- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
