On Sat, 19 Sep 2020 09:24:32 -0500, Mike Schwab wrote: >As a microfische job, it is a collection of printouts, not used for input. > ??? Write-only memory? Why bother? And why keep them? Would a temp DSN be suitable?
>On Sat, Sep 19, 2020 at 8:51 AM Paul Gilmartin 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
