Ended_Job_Info Service and Job’s Temporary Storage Limits

Dawn May explores how the Ended_Job_Info service can help identify limits for temporary storage used by active jobs

Setting limits on resource usage can help protect your system from unanticipated circumstances. One example I see relatively often is when a job consumes an unexpectedly large amount of temporary storage. You can prevent a job from using up your system ASP disk space by setting a limit in the MAXTMPSTG parameter in the class object of your subsystems. The shipped default is *NOMAX, which would allow a misbehaving job to use up large amounts of temporary disk space.

Setting a limit will protect your system, but what should this limit be?

Setting Storage Limits

A simple calculation could be 50% of the remaining disk space in your system ASP. But that could be a large amount of temporary storage—maybe you want a more restrictive limit.

The CPF1164 (Job Ended) message is logged to the history log when a job ends. This message has information about resources that the job used while it was active, one of which is peak temporary storage used. Using the QSYS2.History_Log_Info service, you can create queries to find the typical peak temporary storage that is used by sets of jobs in your environment.

Using the peak temporary storage values that you discover, you can then set a MAXTMPSTG value that is slightly larger than your expected peaks. If a job exceeds that limit, the job will be held, and CPI112E—Job held by the system—will be sent to QSYSOPR. You can monitor or watch for this message and take the desired action.

An Easier Way to Find Peak Temporary Storage

But IBM has made this even easier with the SYSTOOLS.ENDED_JOB_INFO table function. The additional information in the CPF1164 message is hidden away in the message tokens. Using QSYS2.History_log_Info requires that you know how to parse the message tokens to find this buried information. ENDED_JOB_INFO parses out all the message tokens so you can easily get at exactly the information you need. IBM has made the source of this table function available so you can use that as a starting point and create a similar function suited to your specific needs. One example is pulling the results of the CPF1124 and CPF1164 messages into a temporary table to make running the query multiple times over the same data faster; this is something to consider if you need to run this many times for various iterations of job groupings.

Getting the peak temporary storage values for all jobs that ended on July 17, 2024, is as simple as the following query, which organizes the results by the job name and the peak temporary storage used.

SELECT FROM_USER, FROM_JOB_NAME, JOB_INTERFACE, PEAK_TEMPORARY_STORAGE
FROMTABLE (
         SYSTOOLS.ENDED_JOB_INFO(START_TIME =>'2024-07-17-00.00.00.0000',
                                   END_TIME =>'2024-07-18-00.00.00.0000'
             ))  ORDERBY FROM_JOB_NAME, PEAK_TEMPORARY_STORAGE DESC;

You can easily create queries to review peak temporary storage usage by generic job name, subsystem, job user profile or current user profile. Subsystem is particularly nice since the CPF1164 message does not include the subsystem in which the job ran; CPF1124 has that information and ENDED_JOB_INFO pulls everything together for you.

IBM also recommends limiting temporary storage and CPU used by queries. And for SQL, don’t forget about the query supervisor.

Set these limits to protect your system from the unexpected.

---