My last blog was an Introduction to IBM i System Limits and Maximum Capacities. In that blog, I introduced System Health Services, which allow you to track system limits. System limits tracking support is provided via Db2 PTFs, so be sure to install the latest Db2 Group PTF when you start to explore this capability. The limits tracked vary by release and Db2 Group PTF level.
System limits tracking is done automatically by the operating system and the data collected is also managed by the system. This week, I’ll provide several examples of how you can easily use this information to gain insight into your system limits.
IFS limits were added to the 7.2 release during the TR1 timeframe. There are various IFS limits that you can track, but perhaps one of particular interest is the number of bytes in a stream file. If you’re starting to have a disk space usage issue, you probably want to find the largest IFS files. Historically, RTV/PRTSYSINF and RTV/PRTDIRINF were used to find information about disk space usage, but those commands can be long running. Also, if updated results are needed a week later, the commands must be run again.
With the System Limits support, I can run an SQL statement to return the largest IFS files and get the results very quickly. Results from my system tell me I have some cleanup to do because of some large log files that were created. I now have an idea why critical storage situation warnings keep happening.
For your reference, here is the SQL statement I used to retrieve this information. Of particular importance is the limit id; 18409 is the maximum number of bytes in a stream file. With the Run SQL function, I can save my SQL statement and easily it run it again.
SELECT LAST_CHANGE_TIMESTAMP, USER_NAME, CURRENT_VALUE, JOB_NAME, IFS_PATH_NAME, ASP_NUMBER FROM QSYS2.SYSLIMITS WHERE ((LIMIT_ID = 18409)) ORDER BY CURRENT_VALUE DESC;
Another limit automatically tracked is the maximum number of jobs on the system. For most of us, this limit is not an issue, but if you get into a situation where there is a runaway job submitting additional jobs, you definitely need to be aware of the situation. Limit ID 19000 is the maximum number of jobs.
The results are a bit misleading; the MAXIMUM_VALUE is the maximum number of jobs possibly allowed on the system (970,000), but that is not the setting of the QMAXJOB system value on my partition. QMAXJOB is set to the default of 163,520. On January 13, 2020, this partition got dangerously close to the maximum number of jobs allowed.
Here is the SQL statement I used:
SELECT SIZING_NAME, CURRENT_VALUE, MAXIMUM_VALUE, LIMIT_ID, LAST_CHANGE_TIMESTAMP FROM QSYS2.SYSLIMITS WHERE ((LIMIT_ID = 19000)) ORDER BY CURRENT_VALUE DESC;
Using the SYSTEM_VALUE_INFO service, I can get the actual value of QMAXJOB and write a more sophisticated SQL statement to determine how close I actually got to the real limit. (Exercise left to the reader).
IBM provides many examples for each of the services in the Knowledge Center. You can build upon those examples and create a variety of SQL statements that you can use to retrieve the information you’re interested in. In addition, you can implement triggers over the System Limits table to be automatically notified when specific limits are being reached.
In the SQL statement above, I pointed out the limit ID of 18409. You can also use SQL to view all of the limits instrumented on your system (since the limits tracked will vary due by the release and Db2 Group PTF installed):
SELECT SIZING_ID, SUPPORTED_VALUE, SIZING_NAME, COMMENTS FROM QSYS2.SQL_SIZING ORDER BY SIZING_ID DESC;
You can learn a lot more about the limits that are tracked and how the system manages the information that’s collected. There is so much cool stuff out there that can help you be proactive in managing your i.
This blog post was edited for currency on April 14, 2020.
This blog post was originally published on IBMSystemsMag.com and is reproduced here by permission of IBM Systems Media.