I will write at least three blogs on the temporary storage tracking enhancements in the 7.2 release – there is simply too much to cover in one blog. As you may recall, I briefly wrote about “New accounting method and tools for tracking use of temporary storage”in IBM i 7.2 – Systems Management Improvements.
Temporary storage does not persist beyond the current IPL – when the partition is IPLed, all temporary storage is released. During the life of the IPL, temporary storage is (generally) associated with the job that allocates it and any temporary storage not freed when the job ends is automatically released. However, there are some types of temporary storage that are not associated with a job or storage may be allocated by one job and released by another. Prior to 7.2, if you want to find out which jobs are consuming the most temporary storage it can be a tedious process; you can use Work with System Activity (WRKSYSACT and F11) to display storage allocated and dealloacted by each job, but these values also include permanent storage and they are deltas, not totals. You can look at the job (via work with job) to see the actual temporary storage used, but you have to examine each job individually. I summarized some of the challenges when I wrote the blog Understanding Disk Space Usage.
In the 7.2 release, IBM has made many improvements to address these difficulties. The most significant is how temporary storage is tracked. How temporary storage is allocated (to a job, independent of a job, shared between jobs) does not change, but how the system keeps track of where temporary storage is used is improved. The system now has a concept of temporary storage buckets that can tell you exactly where all the temporary storage is being used.
There is a description of the temporary storage buckets in the Knowledge Center – it’s hidden away under Database topics, IBM i Services, Storage Services (and I’ll write more about the storage services in a future blog…). I’ve copied that text here:
There are two types of temporary storage buckets:
- global buckets that are used to track temporary storage that is scoped to all jobs on the system
- job buckets that are used to track temporary storage that is scoped to a single job
Each bucket has a bucket number. Global buckets managed by the licensed internal code have bucket numbers from 1 to 4095. Global buckets managed by IBM i Work Management have bucket numbers from 4096 to 65535. Job buckets have numbers greater than 65535.
A job temporary storage bucket is assigned when the job starts and does not change for the life of the job. A job temporary storage bucket will normally be empty after the associated job ends and all working storage for the job is deleted or freed. If the job temporary storage bucket is empty after the job ends, the bucket becomes available to be associated with a new job. If the job associated with the job buckets ends and some temporary objects tracked to that job are not deleted, the job bucket will show a status of *ENDED as well as the date and time that the job ended. These job buckets identify jobs that are not deleting all of their temporary storage when the job ends.
Statistics for each job bucket indicate the current amount of storage (in bytes) used for temporary storage tracked by the bucket, the storage limit (in bytes) for disk storage used for temporary storage tracked by the bucket, and the peak amount of disk storage (in bytes) used for temporary storage tracked by the bucket. For job buckets, the storage limit will reflect the MAXTMPSTG value of the class (*CLS) object specified when the job was submitted; a null value is returned if the job has a MAXTMPSTG value of *NOMAX.
These changes for managing temporary storage were driven by requirements from clients small and large; IBM i does a great job at managing storage for you, but if something went wrong, it was challenging to identify the root cause. The changes in 7.2 should make it much easier to determine where your temporary storage is being consumed.
Look forward to future blogs where I’ll write more about how you can now view and manage your temporary storage usage much more effectively with the 7.2 release.
I’d also like to note that the were ultimately 9 posts in the series on temporary storage enhancements. Part 9 has the links to all posts.
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.