The DEL 'gdgbase' MASK could take out more datasets than you want. Which is Why I put in an RFE for DELETE "gdgbase.G####V##" MASK as an enhancement.
If you have things that begin with the GDGBASE - it will delete everything So things it would delete GDGBASE.* MASK Deletes GDGBASE.GxxxxVxx datasets GDGBASE.GooooVoo dataset (GooVoo is alpha here) GDGBASE.BACKUP GDGBASE.TEMP And so forth. So you do need to be careful on how it is specified. For some reason JCL is safer. Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Peter Hunkeler > Sent: Tuesday, June 21, 2016 11:43 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: TIOT exceeded > > >You could also try something a little more sophisticated - like > >dynamically allocating the data sets (take a look at IDCAMS, which can > >access the data sets via dynamic allocation and avoid the batch > >limits.) > > > > Isn't it true that for non-authorized programs dynamically allocating a data > set still adds an entry to the TIOT? Only authorized code is allowed to as for > the entry to be added to the XTIOT. I guess IDCAMS is using the XTIOT, but > user programs, including TSO and ISPF do not. > > > > > OTOH, why not deleting the GDSs with IDCAMS "DELETE your.gdg.base.* MASK" > > > -- > Peter Hunkeler > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
