dealing with the existing tapes is doable via a rexx exec that submits a series of IEBGENER, but it's the JCL that they want (preferably SMS) to deal with. On Fri, 18 Sep 2020 07:12:15 -0500, Paul Gilmartin <paulgboul...@aim.com> wrote:
>On Fri, 18 Sep 2020 17:34:17 +0800, Brian Fraser wrote: > >>Why can't his jobs generate dsns like HLQ.FICHE.TAPE.D091720.T1123 ? >>Can use system symbols to generate the date and time in the JCL output DD. >> >I understand that system symbols are not supported in JCL DSNs because of >o ambiguity between EXECSYS and CNVTSYS >o queue latency -- the job might run at a time not matching the JCL symbols. > >(If the actual date and time values are important I understand they >may be invalid because around midnight date and time might be >fetched on different days, resulting in a 23+ hour error. Murphy >says this will only be a problem when it matters. Rexx can do it >right; why can't JCL?) > > >>On Fri, 18 Sep 2020 at 15:36, Brian Westerman wrote: >> ... So over time, they ended up >>> with about 30,000 tapes from the over 9,000 jobs that CA-1 keeps around >>> until expiration date. >>> >>> The problem is that they want to know if there is a way to automatically >>> catalog datasets at creation time, to which I told them we could, but only >>> 1 of them because you can't catalog two datasets with the same name. But >>> they want to have "the system" which I'm guessing is me :), dynamically >>> rename these datasets at creation time to add a date and time, such as >>> change HLQ.FICHE.TAPE to which I would dynamically make it >>> HLQ.FICHE.TAPE.D091720.T1123, meaning today's date and the current time (if >>> it was 11:23am). >>> >Use the seconds also, as D200917.T112359. With thousands of entries >a collision is likely. And use YYMMDD for the date for easy sorting of >displays. > >Is it possible to rename a tape data set? That would seem to require >overwriting the HDR1 label, but tapes can't be updated in place. > >I'm imagining a sequence such as: > >Momentarily catalog HLQ.FICHE.TAPE > >DEFINE ALIAS HLQ.FICHE.TAPE.D200917.T112359 > SYMBOLICRELATE HLQ.FICHE.TAPE > >Uncatalog HLQ.FICHE.TAPE. I understand that symbolic aliases >remain when the RELATED name is uncatalogued. > >-- gil > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
