They are mifrofiche tapes, and they are not sent out for processing any more. They exist only on the off chance that "someday" they might be needed to recreate something. When they are needed, they use the DSN=,VOL= to use them.
On Sat, 19 Sep 2020 08:50:50 -0500, 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
