Re: AW: Re: TIOT exceeded

Years ago we had an application that needed to sequentially read all generations of a GDG for reason that I've long forgotten. The "read" program would do its process, then delete the input file. The next step would submit itself back to the internal reader. Once the job was submitted we could

Re: AW: Re: TIOT exceeded

On Thu, 23 Jun 2016 11:12:10 +0530, Jake Anderson wrote: >I am little worried as the GDG limits after zOS 2.2 going to be more than >255. So not sure if TIOT limit of 64k is going to help ? IIRC you are running a single IEFBR14 step to delete all of the multi-volume generation data sets for

Re: AW: Re: TIOT exceeded

LISTSERV.UA.EDU > Subject: Re: AW: Re: TIOT exceeded > > I am little worried as the GDG limits after zOS 2.2 going to be more than 255. > So not sure if TIOT limit of 64k is going to help ? -- For IBM-MAIN subscribe

Re: AW: Re: TIOT exceeded

I am little worried as the GDG limits after zOS 2.2 going to be more than 255. So not sure if TIOT limit of 64k is going to help ? On Jun 23, 2016 10:47 AM, "Peter Hunkeler" wrote: > >> > >>Since the TIOT is at task level, the parameter would belong to the EXEC > rather than the DD

AW: Re: TIOT exceeded

>> >>Since the TIOT is at task level, the parameter would belong to the EXEC >>rather than the DD statement, wouldn't it? > >The real difficulty lies is in knowing that the running program, and anything >it calls, can tolerate the use of XTIOT entries vs TIOT entries. A step level switch,

AW: Re: TIOT exceeded

> The DEL 'gdgbase' MASK could take out more datasets than you want. Good catch. Thanks. It seems I wasn't fully awake when I posted my suggestion. >Which is Why I put in an RFE for DELETE "gdgbase.GV##" MASK as an enhancement. I didn't look at your RFE, but I understand your