IEF240I - TASK I/O TABLE EXCEEDS TIOT LIMIT OF 0032K.

[Akshypal]

Hi,

One of our Job abended with JCL error. The Job is like this:

Code: Select all

//J001   EXEC PGM=IEFBR14                                       
//*                                                             
//DD01   DD  DSN=X.ABC.MNO011.XMLBILL,DISP=(OLD,DELETE,DELETE)  
//*                                                             
//DD02   DD  DSN=X.ABC.MNO012.XMLSHPD,DISP=(OLD,DELETE,DELETE)  
//*                                                             
//DD03   DD  DSN=X.ABC.MNO013.XMLORDD,DISP=(OLD,DELETE,DELETE)  
//*                                                             
//DD04   DD  DSN=X.ABC.MNO014.XMLPKGD,DISP=(OLD,DELETE,DELETE)  
//*                                                             
//DD05   DD  DSN=X.ABC.MNO015.XMLSKUD,DISP=(OLD,DELETE,DELETE)  
//*                                                             
//DD06   DD  DSN=X.ABC.MNO016.XMLSRLD,DISP=(OLD,DELETE,DELETE)  
//*                                                             
//SYSPRINT  DD   SYSOUT=*                                       
//SYSOUT    DD   SYSOUT=*                                       
//*                                                             
//J002     EXEC PGM=IEFBR14                                     
//*                                                             
//DD01     DD DSN=X.ABC.MNO011.XMLBILL(+1),                     
//            DISP=(NEW,CATLG,DELETE),              
//            DCB=(LRECL=837,RECFM=FB,BLKSIZE=0),   
//            SPACE=(TRK,(450,150),RLSE),UNIT=PROD  
//SYSPRINT DD SYSOUT=*                              
//SYSOUT   DD SYSOUT=*                              
//*                                                 

There does not seem to be an error when we do a JEM. But later we find this message in the JESYSMSG:

Code: Select all

IEF240I JOBNAME J001 - TASK I/O TABLE EXCEEDS TIOT LIMIT OF 0032K

Can someone please tell me how can this be solved?

[enrico-sorichetti]

what happened when You looked at the messages and codes manuals
or simply googled for IEF240I ???
the first link returned by the search contains the explanation and the actions to be taken to solve the problem

[Akshypal]

Yes I looked at the message and it told that "A job step specified more DD statements than the system can process and/or a job step specified more units than the system can process."

https://www.ibm.com/support/knowledgece ... 010775.htm

But it tells to create multiple jobs, which does not really look like a solution. If there are more job in oproduction which get this error are we supposed to change all those jobs?? Can not we change it in JCL itself?

[enrico-sorichetti]

why not speak to Your support rather than asking on a forum ?
we do not belong to Your organization,
we do not know the reason for the current ALLOCxx parameter choice
so any advice we could give might be wrong
and,
You posted just a small part of the offending JCL, which as shown has no reason to cause problems,
so really we do not have any information available to give any any advice

[Robert Sample]

Can not we change it in JCL itself?

No, you cannot. The TIOT limit is a hard, fixed limit for the system that you CANNOT overcome. Your site support group could change the TIOT size up to 64K, which IIRC requires an IPL of the LPAR, but you have no choice -- you MUST reduce the number of DD statements, or split the step into multiple steps, or split the job into multiple jobs. If you have not talked to your site support group about this message, you need to do so.

If there are more job in oproduction which get this error are we supposed to change all those jobs??

Only if you want those jobs to execute.

[Akshypal]

why not speak to Your support rather than asking on a forum ?
we do not belong to Your organization,
we do not know the reason for the current ALLOCxx parameter choice
so any advice we could give might be wrong
and,
You posted just a small part of the offending JCL, which as shown has no reason to cause problems,
so really we do not have any information available to give any any advice

Unfortunately support is asking me for a resolution. Support is pretty mechanical.

That's the entire Job. It just deletes all the versions of GDG bases and allocates one version of a GDG.

[Akshypal]

you MUST reduce the number of DD statements, or split the step into multiple steps, or split the job into multiple jobs.

So if I make multiple steps deleting the versions of the GDG it will work? In test we did not get this error so not sure how do I test it?

[enrico-sorichetti]

I do not remember if an IDCAMS delete will allocate the datasets, but it is worth a try

[Akatsukami]

So if I make multiple steps deleting the versions of the GDG it will work? In test we did not get this error so not sure how do I test it?

Note that the interpreter will internally generate one DD statement for each generation data set, which may be why it worked in test but not in production.

[Robert Sample]

In test we did not get this error so not sure how do I test it?

Was your test environment an EXACT copy of production -- same number of generations in each GDG? If not, then your test was not a full test and hence you got different results in production and test.

[Akshypal]

I do not remember if an IDCAMS delete will allocate the datasets, but it is worth a try

IDCAMS works too but this JCL had been working in production for very long. It's because of the one additional GDG. So even with IDCAMS TIOT problem will remain?

[Akshypal]

Note that the interpreter will internally generate one DD statement for each generation data set, which may be why it worked in test but not in production.

So are you saying that even if we change the JOB to have multiple steps, it will still be same for the interpreter?

What is interpreter, actually?

[Akshypal]

Was your test environment an EXACT copy of production -- same number of generations in each GDG? If not, then your test was not a full test and hence you got different results in production and test.

I can not say for sure that test and production are exact copy but I have created the same number of generations for each GDG. But the generations were empty. So the question is now, will an empty generation and a generation with data will make difference from TIOT angle?

As far I have been told our test and prod environments shared. So that we can locate test datasets in prod and prod datasets in test.

[enrico-sorichetti]

So even with IDCAMS TIOT problem will remain?

what did You understand reading ?

I do not remember if an IDCAMS delete will allocate the datasets, but it is worth a try

I did not mean to use EXEC PGM=IDCAMS instead of EXEC PGM=IEFBR14

but to ...
get rid of the DD ...,DISP=(OLD... statements

provide the proper delete statements in the SYSIN dataset for idcams

and see what happens,
it should not take more than 15 minutes to test

[Akatsukami]

Akatsukami wrote: ↑13 Nov 2017 03:42
Note that the interpreter will internally generate one DD statement for each generation data set, which may be why it worked in test but not in production.
So are you saying that even if we change the JOB to have multiple steps, it will still be same for the interpreter?

What is interpreter, actually?

A TIOT is established for each step, so breaking J001 into multiple steps may resolve the problem (I say "may" because it is possible that a single step might still have so many implicit DD statements as to overflow the TIOT).

When a job is submitted to a MVS system, a piece of system-level software called the interpreter reads the JCL and translates into a set of MVS control blocks. This is a point that often escapes mainframe newbies; the control blocks are created and populated when the job is submitted, and thereafter fixed; it is not possible for the programmer to alter them.

[Akshypal]

Does the TIOT look for the size of the datasets too? I ask this because when I tested it in test I have tested it with empty GDG generations while in production it had data. Please suggest.

[Robert Sample]

The Task Input/Output Table depends upon the number of data sets; it creates one (or more) entries in the table for each DD statement. The system does not adjust the table for the size of those data sets.

[Akshypal]

We had to request to change the size in TIOT table and Support team has done it. We had some space available there. Thanks all for your ehlp.

[prino]

We had to request to change the size in TIOT table and Support team has done it. We had some space available there. Thanks all for your ehlp.

You've applied a Band-Aid, you didn't solve the problem, which will return shortly.

[Robert Sample]

We had to request to change the size in TIOT table and Support team has done it. We had some space available there.

The base problem is that you are attempting to use one job step to do what should be multiple jobs. If you keep adding GDGs to the job to delete generations, sooner or later your problem will return -- and at that time, you will have no choice but to split the job into multiple jobs since the TIOT cannot (as in, there are physical limits in z/OS that prevent it) be increased past 64K.