Finding why your IBMi system storage is filling up

One of the problems I have with the IBMi is how difficult it is to find out what objects are taking up all the storage on our systems. I have tried the DSPLIB *PRINT and dutifully walked all the way through resulting spool file looking for any objects which are large enough to warrant investigation such as Journal receivers which are one of the biggest offenders on our systems due to the High Availability tools we develop, but there are others such as save files and user spaces which can take up a lot of storage. To be honest, reading through the spool file is not a task for the faint of heart, if only IBM allowed the output to be to a database file..

Having just completed the re-write of our job tracking product JT4i (testing is well on its way to being finished) I was looking for a new project to get my teeth into. I had recently upgraded a number of our systems to 7.2 in preparation for loading the next release (when its available) after which I noticed the DASD utilization had increased significantly. Maybe I had not been checking recently, but it seemed a lot higher than I expected and was wondering if the upgrade had done something which increased the DASD utilization.

I had used IMGCLGs to upgrade the OS but they had already been removed and I had already deleted the downloaded PTF save files from QGPL, so I wanted to find out what else could be taking up a lot of storage. I spent a few hours/days trawling around the documentation and system commands looking for something that would help me, unfortunately nothing jumped out as a viable solution. I then decided to write my own program to look at every object and report those which I felt needed reviewing.

The basic principle is to only show objects which are larger than a specific size (you could use 0 bytes to get everything :-). I also want to be able to look through any number of libraries (*ALLUSR, *IBM, *ALL, LIBNAME) so the program would have to be able to list the relevant libraries and the content of each library. Once I had all of the content I then need to verify if the object size is greater than the minimum size before the object is to be logged. I also added a complete size calculation for the entire library even if it does not have objects which exceed the logging (minimum) size but had lots of small objects it would be logged. The last requirement was a count of the number of objects I had checked. Each record would store the object information, the Time Stamp that the object was last used and the actual size of the object. Hopefully the last used date will help identify the objects which can be moved out of DASD and onto another storage medium etc.

After a little trial and error we now have a program which will generate the list of objects into a file. I used a number of API’s to collect the data such as QUSLOBJ to list all the libraries on the system plus QGYOLOBJ and QGYGTLE for managing the content of each library. I then front-ended the program with a command to make it easier to use. The program took a few seconds to run on our system having checked nearly 42,000 objects (thats impressive) and the file is populated with the objects which are greater than the size we passed in (we only logged 768 objects over 1MB). Below is a sample of the output which was generated after running a simple SQL over the file

Large Object list
Large Object list

Note: If the image is too small to see you can right click and view a larger copy.

The beauty of this method is I can refine the query used to pull segmented data back for me to view such as only show me the *JRNRCV objects which are logged such as below.

Receivers which exceeded the maximum size
Receivers which exceeded the maximum size

As you can see from the above a quick clean up of the QAUDxxxxxx journal receivers could put around 1GB of storage back.. and remember all of these objects are being probably being saved regularly as well taking up your tape storage..
If you are interested in the program let us know, we are now going to develop one which will do exactly the same thing across the wicked step child of the IBMi (the IFS) to see just how long it takes to map the large objects there.

Don’t forget to take a look at the object distribution tool or one of our Availability tools (HA4i,DR4i,LVLT4i,JT4i) while you are browsing the website, free trials of the products are available and the prices will certainly make you smile.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.