ALTER gdg.base.name LIMIT(1) DELETE gdg.base.name(0). ALTER gdg.base.name LIMIT(999)
On Wed, Jun 22, 2016 at 11:40 AM, Paul Gilmartin <[email protected]> wrote: > On Wed, 22 Jun 2016 08:43:18 +0200, Peter Hunkeler wrote: > >>>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.) >> > You need only one at a time: ALLOCATE OLD DELETE; FREE. > >>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. >> > BPXWDYN skirts some rules. For example, it doesn't enforce DYNAMNBR. > I wonder about XTIOT? > >>OTOH, why not deleting the GDSs with IDCAMS "DELETE your.gdg.base.* MASK" >> > It feels as if there should be a catalog service to trim a GDG en masse; > perhaps > simply by setting max generations to a smaller value. (But what about extant > ENQs?) > > Must the TIOT reside below 64 Ki, or only be limited to 64KiB in length? > > CMS experienced its heyday in the twilight of 64-bit addressing because > it didn't keep everyone's stuff in each job's address space. MVS never > learned to truly exploit multiple address spaces. Only hardware advances > rescued it. See "Ye indiscreet monitor", 1963, for sale from ACM Digital > Library. > > Is the JCL limit fundamental or merely to preserve compatibility with legacy > code. If the latter, a DD parameter, XTIOT={Y|N} might be more useful > than a query or a warning. Surely an IEFBR14 step would have no such > compatibility issues. > > - 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
