I’m continuing the series of blogs on improved temporary storage tracking in IBM i 7.2 – part 1 covered the changes made to provide improved tracking and part 2 covered the changes made so you can better understand temporary consumption at a system level. You may want to read these blogs if you have not done so already.
This week, I want to review the enhancements that allow you to better view and understand where the temporary storage is being used from a job-specific perspective. If you have discovered a problem with temporary storage consumption on your IBM i partition, you generally detect the issue at the system level but will need to identify the root cause. The problem is often caused by a job (or jobs) that is consuming the storage.
Active Jobs
Using Navigator for i to view Active Jobs (or active jobs by memory pool, or active jobs by subsystem), the temporary storage used column will be displayed by default. Simply click on the column heading (twice) to sort the table by the jobs that are using the most temporary storage. (Yes, I’ve already asked the Navigator development team to add a way to select the sort order with just one click….)
Also, a reminder about using the Active Jobs interface on Navigator – if you want to see updated values displayed in the table, don’t forget to click the “refresh” button – the table is not dynamically updated. (Yes, I’ve already asked the Navigator development team to add dynamic updates….)
The screen capture below shows the Active Jobs display sorted by the temporary storage used column.
Work with Active Jobs (WRKACTJOB)
For those of you who prefer to use the green-screen interface to manage i, you will appreciate the enhancement to WRKACTJOB to provide temporary storage as a column. You can simply use WRKACTJOB and press F11 two times to display the new column. You can sort on the column in the usual way with your cursor placed on the column heading and press F16. In addition, if you prompt the WRKACTJOB command, there is a new value, *TMPSTG, on the sequence (SEQ) parameter that you can use to immediately display the view with the jobs sorted by the temporary storage column.
The screen capture below shows the WRKACTJOB display sorted by the temporary storage column.
Work with Job
There is also a minor change to a job’s run attributes. Prior to 7.2, you could work with a job and see the maximum amount of temporary storage allowed and the current amount used. 7.2 enhances this by including peak usage by that particular job.
Interestingly, this support is only on the green screen WRKJOB (option 3) and not on the job properties GUI. (Yes, I’ve already asked the Navigator development team to add the peak temporary storage used to the GUI….)
As an aside, most of you should already know that you configure the maximum temporary storage allowed by a job on the class object. In 7.2, the MAXTMPSTG parameter on the class object is now in megabytes rather than kilobytes. Read the blog Jobs Exceeding their CPU or Storage Limits are now Held on why you should start setting the maximum temporary storage value.
Temporary Storage Details – buckets per job
In part 2, I wrote about how you can view the temporary storage details to find a table of all of the temporary storage buckets along with their size information. That article noted that there is a bucket for each active job; the temporary storage details view is another way to find the jobs that are using the temporary storage in addition to Navigator’s Active Jobs task.
Remember you can use filters to subset what you see, so you could add a filter on the “Job Status” column to only show those entries that start with “*” – this is a simple way to filter out the global entries and only see the temporary storage information for jobs. You can then sort the bucket current size column to find the job(s) using the most temporary storage. The nice thing about using this approach is that you also can find jobs that have ended but still have temporary storage allocated.
If you discover active jobs that are consuming an unexpectedly large amount of temporary storage, you can take proactive actions by holding or ending them. While you can see if ended jobs had temporary storage that was not released, you cannot take any actions upon those jobs. Diagnostics or debugging will be necessary to determine what the job was doing when it ended that prevented the system from freeing storage.
It looks like I will have at least two more blogs on related topics for temporary storage tacking in the 7.2 release. In future blogs, I will discuss support added to Collection Services and how to set up notification.
This blog post was edited to fix broken links on April 11, 2020.
This blog post was originally published on IBMSystemsMag.com and is reproduced here by permission of IBM Systems Media.