More on Whether IPLs Help System Performance
April 21, 2010 Hey, Joe
|
In your article on IPLing for system performance, you stated that it’s difficult to find a definitive listing of all the steps that i/OS performs during an IPL. Here’s a link to an older list of IPL status progress codes. While it’s not the most up-to-date list, it should give you a good idea of what’s happening during an IPL. –Dave Flint Thanks, Dave. The only problem I saw with your link was that it only references the C6xx xxxx IPL status codes, which only tells part of the IPL status code story. Many IPL status codes have a format of C9xx xxxx, so we have to use another table to translate those codes. To look up the C9xx xxxx codes, go to the (C9xx) IPL status progress code table. My article, Does an IPL Really Help Improve System Performance, sparked a lot of reaction from Four Hundred Guru readers, with lots of readers checking in with great ideas and tips on how to improve system performance and retrieve disk space without performing an IPL. I got so much feedback that it won’t all fit into one technical tip. So I’m publishing the first half of my reader feedback on this topic this month, and save the rest of it for a later issue. Let’s get started. Reader Jack Kingsley tipped me off to an API called QWCCRTEC that provides some IPL information you can’t get anywhere else. He wrote: QWCCRTEC tells me the last IPL date, how long each step took, as well as all the steps that took place in the IPL. It produces a small spooled file containing this information. QWCCRTEC produces a spooled file of AS/400 dump information. The spooled file is confusing to read because the first 85 characters of the print out contain the hex representation of the IPL information that you’re looking for. To understand QQCCRETC’s output, you have to concentrate on columns 87 to 120 of the print out, where the English translation of the hex code is contained. I called QWCCRTEC on one of my i/OS partitions by running the following Call Program (CALL) command on a 5250 green-screen command line. CALL PGM(QWCCRTEC) In the QPSRVDMP spooled file that QWCCRTEC produced, it displayed the following information about my last IPL in columns 87-120. *XPF PWRDWN 02/07/10 23:16:50* * D900 2740 02/07/10 23:16:50* * D900 2750 02/07/10 23:16:53* * D900 2770 02/07/10 23:16:53* * D900 2780 02/07/10 23:16:54* * D900 2790 02/07/10 23:16:54* * D900 27C0 02/07/10 23:16:54* *End PWRDWN 02/07/10 23:16:57* *XPF IPL 02/07/10 23:23:02* * C900 2810 02/07/10 23:23:03* * C900 2820 02/07/10 23:23:03* * 10 20 0010 02/07/10 23:23:03* * 10 20 0020 02/07/10 23:23:03* * 10 30 0010 02/07/10 23:23:03* * 10 30 0020 02/07/10 23:23:03* * 10 30 0030 02/07/10 23:23:03* * 10 30 0040 02/07/10 23:23:03* * 10 30 0050 02/07/10 23:23:03* * 10 3A 0010 02/07/10 23:23:03* By reading these columns, I can see the history of my last IPL. On February 7, 2010, I began powering down the system at 23:16:50 (as shown in the XPF PWRDWN listing), and the power down ended at 23:16:57 (as shown in the End PWRDWN listing). The IPL began at 23:20:02 (the XPF IPL entry) and all the IPL steps and sub-steps it went through are listed as separate lines following the XPF IPL entry. Each IPL step is individually listed until I see another entry that tells me that the IPL ended at 23:26:30 (the End of IPL listing). While this is a little cumbersome to interpret, you can also cross-reference this information with the C6xx xxxxIPL status progress code table and the C9xx xxxx IPL status progress code table that we looked at earlier in the article. This will help you determine what each step is doing. But it was Pat Woodcock who tackled the key question of my article, which was whether an IPL helped system performance. Pat added this helpful piece of information and a checklist for cleaning up disk storage without an IPL. I think the fact that high disk usage does impact performance is important. Storage usage above 70 percent will impact performance because of the system’s I/O response time. The newest data, which is typically the most often referenced, has longer seek times and thereby longer response times. An IPL does not help there, but there are steps to reduce DASD that may temporarily help performance. Ultimately more or faster drives, and/or more or faster IOPs will be required [to maintain performance]. Here are some steps you can take to clean up your disk drive utilization and hopefully bring your disk utilization below 70 percent. 1. Clean up old spool files by using the Work with Output Queue (WRKOUTQ) command. 2. Clean up old save files by using the Work with Files (WRKF) command, like this: WRKF FILE(*ALL/*ALL) FILEATR(SAVF) 3. Permanently apply your PTFs and then use the Delete Program Temporary Fix (DLTPTF) command to remove any save files containing PTFs. 4. Run the disk collection reports to find large and or old files to purge or delete. Do this by running the Retrieve Disk Information (RTVDSKINF) command, like this: RTVDSKINF RTVDSKINF retrieves current information about your disks and places that information in the QCURRENT member of a file called QAEZDISK in library QUSRSYS. Once that information is collected, you can run the following Print Disk Information (PRTDSKINF) command to produce a disk collection report for old journal receivers. PRTDSKINF RPTTYPE(*OBJ) OBJ(*ALL) OBJTYPE(*JRNRCV) SORT(*LSTCHG) Once you’ve identified the old journal receivers, you can then delete them to retrieve space. On the PRTDSKINF report, be sure to check the area in the summary section titled “Objects not in a library” to see if a Reclaim Storage (RCLSTG) command is justified. My recommendation is if the number of objects not in a library is greater than 1 percent of disk, then a RCLSTG should be done. After you clean up your journal receivers to make more space, you can use the Start ASP Balance (STRASPBAL) command and rebalance and redistribute disk space so that your system and data objects are evenly distributed across your system. This may also help speed up performance. 5. Use the Display Job Tables (DSPJOBTBL) command to check your system’s job table entries to see if they can be compressed. If you determine there is excessive job table usage, you can set your IPL attributes so that the system compresses its job table entries the next time the system IPLs. To do this, type in the Change IPL Attributes (CHGIPL) command and press F4 to prompt. To tell the system to compress the job tables to remove excessive unused entries during the next IPL, change the Compress Job Tables (CPRJOBTBL) parameter under the IPL attributes to *NEXT. CPRJOBTBL will reset to *NONE during the IPL. For more information on i/OS job tables and how they affect performance, see my series on When System Job Tables Attack, Part I and Part II. Pat provided a ton of useful information about reclaiming disk space instead of IPLing to improve system performance. The interesting thing about Pat’s email is complemented the information I published last month in an article Hunting Down Storage Hogs. By reading the two articles in tandem, you should get a pretty decent idea how to hunt system storage issues. –Joe RELATED STORIES Does An IPL Really Help Improve System Performance? When System Job Tables Attack, Part I When System Job Tables Attack, Part II
|
