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. Because I’m an SQL novice, I like to use the RunSQL function along with the SQL wizard that is part of Mobile iAccess (I run it in a standard browser session). Results from the test I ran tell me I have some cleanup to do after installing a 7.2 update. 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 confirm I am well within the system limit.
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"LAST_CHANGE_TIMESTAMP" DESC
Once you know the SQL (and there are plenty of examples to start from on the developerWorks site), 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
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. The best place to go is the developerWorks page I noted at the beginning of this article and read the articles linked from there. There is so much cool stuff out there that can help you be proactive in managing your i. Don’t hesitate to ask about something specific to your system.
This blog post was originally published on IBMSystemsMag.com and is reproduced here by permission of IBM Systems Media.