Hi Lizette Apology to ask
I am not still able to understand the calculation of TIOT usage in my case. It was just 1027 GDG members spanning across multiple volume. So how did it exhaust the TIOT ? Is there a formula that would help me to determine? Jake On Jun 21, 2016 3:23 AM, "Lizette Koehler" <[email protected]> wrote: > Why not run with TIOT set to 64K? I know a lot of shops that have set > that to the maximum of 64K > > Lizette > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:[email protected]] On > > Behalf Of Jake Anderson > > Sent: Monday, June 20, 2016 6:35 AM > > To: [email protected] > > Subject: Re: TIOT exceeded > > > > Lizette, > > > > The error message was > > > > IEF240I JOBNAME STEPNAME - TASK I/O TABLE EXCEEDS TIOT LIMIT OF 0048K > > > > I found that the GDG members were created on Multivolume. > > > > On Mon, Jun 20, 2016 at 6:48 PM, Lizette Koehler < > [email protected]> > > wrote: > > > > > Jake, > > > > > > This is a more helpful posting for your question. We can see what > > > your issue is with your question about TIOTs. > > > > > > Next, what error message do you get in your job when it fails? Please > > > post the entire message and not just the message ID. > > > > > > Lizette > > > > > > > > > > -----Original Message----- > > > > From: IBM Mainframe Discussion List > > > > [mailto:[email protected]] On Behalf Of Jake Anderson > > > > Sent: Monday, June 20, 2016 1:18 AM > > > > To: [email protected] > > > > Subject: Re: TIOT exceeded > > > > > > > > Hi, > > > > > > > > The JCL abended even before reaching the Limit of 48k set in our > > > > Shop. on every GDG deletion DD statement, we had 256 generations and > > > > it was same > > > for > > > > 4 DD statements. > > > > > > > > Is there any reason even if the TIOT size is set at 48k But the Job > > > abends > > > > before the DD statement reached 2454 ? > > > > > > > > On Mon, Jun 20, 2016 at 12:30 PM, Jake Anderson < > > > [email protected]> > > > > wrote: > > > > > > > > > Hi > > > > > > > > > > The TIOT started failing when the JCL started deleted a group of > GDGs. > > > > > Using DISP=OLD,DELETE > > > > > > > > > > Jake > > > > > On Jun 20, 2016 2:32 AM, "Greg Dyck" <[email protected]> wrote: > > > > > > > > > >> On 6/18/2016 11:03 AM, Jake Anderson wrote: > > > > >> > > > > >>> Is there a way to know if the DD chain has approached the end or > > > > >>> it has approached the end of Chain. Is there a way to tweak the > > > > >>> JCL to overcome TIOT exceeded values ? > > > > >>> > > > > >> > > > > >> The TIOT is a fixed sized array of entries, not a chain. The > > > > >> size is defined in PARMLIB member ALLOCxx, with a maximum allowed > > > > >> size of 64K. Only when an allocation request fails due to > > > > >> insufficient TIOT space do you know it is full. > > > > >> > > > > >> The primary 'tweak' for SMS managed datasets that can reduce the > > > > >> space used for each DD in the TIOT is to reduce the dynamic > > > > >> volume count (DYNVOL) specification defined for the data class ( > > > > >> http://www-01.ibm.com/support/docview.wss?uid=isg3T1000065). > > > > >> > > > > >> It is possible to dynamically allocated datasets using the > > > > >> extended TIOT (aka, XTIOT). This requires the application be > > > > >> updated appropriately ( > > > > >> http://publibz.boulder.ibm.com/zoslib/pdf/oa34634.pdf). For > > > > >> non-VSAM datasets you must also change PARMLIB member DEVSUPxx to > > > > >> specify NON_VSAM_XTIOT=YES. VSAM datasets may be allocated using > > > > >> the XTIOT > > > without > > > > any changes to PARMLIB. > > > > >> > > > > >> Greg > > > > >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
