i can

Dawn May

Dawn May

Bookmark and Share

October 2014

Sun Mon Tue Wed Thu Fri Sat
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

« Suspend My i | Main | IPCONFIG – A Secret Tool for IP Configuration »

April 19, 2011


TrackBack URL for this entry:

Listed below are links to weblogs that reference IBM i 7.1: Jobs Exceeding Their CPU or Storage Limits are now Held:


How does one determine what would be an appropriate Maximum CPU Time in Milliseconds and Maximum Temporary Storage in Megabytes should they decide to change the default class object settings from *NOMAX?

I would assume you would make different changes based upon whether the class object was for batch versus interactive job processing.

Could you expound on this subject?

Knowing that you can set the limits is the easy part; knowing what the limits should be set to is the hard part!

You need knowledge of your environment to know what is typical for the CPU time and temporary storage used by your jobs. You can use the various work management interfaces to review these metrics; Collection Services also has the CPU time used for jobs.

Knowing the temporary storage upper limit is a bit difficult since the interfaces that return information on temporary storage used only provide it for active jobs and the value returned is the current amount used; you can't determine the upper limit of the temporary storage used by a job after it has ended nor can you determine the high-water mark of the temporary storage used by a job.

Regarding the temporary storage limit, it is best to think of this limit as protecting the system, not limiting an individual job. You may want to set the temporary storage limit based upon the total amount of storage on the system and set the limit so that no job uses more than 5% of the maximum storage available. Work with System Status (WRKSYSSTS) can show you now much storage is available. The bottom line regarding the temporary storage used limit is a large limit (but smaller than the total amount of storage available) is much better than *NOMAX, as the large limit will protect the system from a failure whereas *NOMAX does not. A maximum temporary storage limit of *NOMAX is dangerous and I would advise everyone to move away from that default value.

A very quick way to get rid of *NOMAX for the temporary storage used values is to do a WRKCLS *ALL/*ALL and put a 2 on every line and a MAXTMPSTG(xxxxx) on the parameter line.

The nice thing about this new support is that you do not have to accurately set these limits at first - you can experiment with the settings and if jobs are hitting them because they are too low, you can increase the limit for the job and then release the job to allow it to continue to run; you can then modify the class parameters as you determine what the best settings are for your environment.

Once you set these limits, you should pro-actively monitor the QSYSOPR message queue for the new messages that are sent to ensure you promptly react if the system holds a job. You can automate this message monitoring with Management Central Message Monitors or Message Watches.


A Case:-
1. Could be a chance that job still ends, when it hits Max limit?
2. How to determine *NOMAX for a system with respect to temperoray storage?
3. Temporary Storage for a Job and Heap have any relation?

Hi Anoop, here are the answers to your questions:

1. If the MAXTMPSTG setting for a job is *NOMAX, there is no max limit to hit and the system would never end the job based upon temporary storage consumption (unless all of the system's storage is consumed, but that would result in a the whole partition being affected, not just a single job).

2. With the PTFs that have been released for 7.1, a best practice would be to never use *NOMAX, but rather identify an upper limit for the MAXTMPSTG value. As the article explains, what this limit is will depend upon your system's storage - a large value that is smaller than the total amount of storage available.

3. Heap storage that can be allocated and deallocated by programs is temporary storage that is tracked on a job basis.


Hi Dawn,

Is there a PTF equivalent of PTF SI42845 for IBM i6.1?


Hi Argel,

No, this PTF is only available for 7.1. I don't expect to see this same functionality back on 6.1. Sorry.


What if we WANT the job to end if it exceded the max cpu? Can this be specified in the class?

If you want the old behavior where the job will be ended if the maximum CPU or temporary storage limits are held, read this blog:

The comments to this entry are closed.