In the 7.2 release, IBM made many changes to improve temporary storage tracking. I’ve written about these enhancements in IBM i 7.2 Improved Temporary Storage Tracking Part 1, Part2, and Part 3 blogs. You may also want to reread the blog, Understanding Disk Space Usage, which reviews IBM i temporary and permanent storage concepts.
In addition to improving temporary storage tracking, IBM also made some improvements for permanent storage tracking in the 7.2 release. This post reviews three of them.
Increased Maximum Allowed Storage for a User Profile
Permanent storage is charged to a user profile. In the 7.2 release, IBM added an additional parameter, Maximum Storage Large (MAXSTGLRG), to the user profile. This allows values larger than what could be specified in the MAXSTG parameter. Previous to 7.2, the MAXSTG parameter on CRTUSRPRF and CHGUSRPRF allowed up to 2,147,483,647KB; the new MAXSTGLRG parameter allows up to 9,223,372,036,854,775,807KB – that’s a really big number! The IBM i Knowledge Center has a short page that describes the maximum storage for a user profile.
Warning Message for User Profile Limit
The maximum allowed storage (MAXSTG or MAXSTGLRG) parameter on the user profile prevents a user from consuming all the storage on the system. An object cannot be created or extended once this limit has been reached. In 7.2, a warning message is now sent as the limit is approached. At 80% a message is sent to the message queue associated with the user profile. At 90% and 95% a message is sent to the user message queue and QSYSOPR. Only one warning message for each threshold is sent in the same day.
CPI147B message:Message . . . . : User profile DAWNMAY nearing storage limit. Cause . . . . . : 80 percent of the maximum storage allowed for user profile DAWNMAY has been used. The maximum storage allowed is 3000 kilobytes. 336 kilobytes remain available for use. Recovery . . . : No recovery is necessary at this time. You can use the Work with Objects by Owner (WRKOBJOWN) command to see if any objects should be deleted or have their ownership changed. If additional storage is needed for future use, increase the storage limit (MAXSTGLRG parameter on the CHGUSRPRF command). Or, if you are not authorized, have the system administrator increase your storage limit.Technical description . . . . . . . . : The storage limit is for auxiliary storage pool (ASP) *N. The ASP number is 1.
A system level environment variable can be created to suppress the message: ADDENVVAR ENVVAR(QIBM_MSG_CPI147B) VALUE(*NONE) LEVEL(*SYS)
You can also set up the environment variable to have the message sent to the user profile message queue and not QSYSOPR:
ADDENVVAR ENVVAR(QIBM_MSG_CPI147B) VALUE(*USRPRF) LEVEL(*SYS)
The change to the environment variable takes effect at the next IPL.
You can use your favorite message monitoring solution (or perhaps watches) to build improved automation and notification on this (or any other) message.
QTEMP Library Size
The QTEMP library associated with a job contains both permanent and temporary objects. The permanent objects in QTEMP are not counted under the temporary storage size associated with the job.
See the “QTEMP – Temporary or Permanent Storage?” blog for methods used to view the QTEMP library sizes of other jobs. Starting with 7.2 this information is available on the List Job (QUSLJOB) and Open List of Jobs (QGYOLJOB) APIs: Key Type Description 1701 BINARY(8), UNSIGNED QTEMP library size, in bytes
The link below will take you to a REXX example that you can download and try on your system. It uses the new key to show jobs with the largest QTEMP libraries:
REXX Example
After downloading the file to a member named QTEMPSIZE in the QREXSRC file in QGPL library, you can run the sample with: STRREXPRC SRCMBR(QTEMPSIZE)
The following screen capture is an example of the output from the procedure:
I’d like to thank Mike Russell for his contributions to this blog. Mike is a member of the IBM i work management team and has been a guest “i Can” blog author several times. Thanks, Mike!
This blog post was edited to fix broken links on April 12, 2020.
This blog post was originally published on IBMSystemsMag.com and is reproduced here by permission of IBM Systems Media.