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
