Admin Alert: i5 IPL Pre-Planning and Post-Planning Checklists

May 23, 2007 Joe Hertvik

Unlike Windows servers, which can be rebooted several times a year, i5, iSeries, and AS/400 partitions are so legendarily reliable that IPLing one can become an event. And like any good event, it takes some planning to prepare for the opportunities and risks an IPL presents. To aid you in that planning, here’s my list of things to consider when you’re ready to restart a partition.

The IPL Roadmap

For the uninitiated, an i5/OS IPL is similar to a Windows reboot, which is when the operating system and machine are taken down and restarted. During an i5 restart, PTFs (operating system updates) are applied, the operating system is reset to its initial state, and subsystems and servers are started and initialized.

i5 system IPLs are performed for several different reasons. Sometimes they are done to apply PTFs or to perform a system upgrade. System power downs and IPLs are also necessary when performing planned hardware maintenance or when adding new hardware to your system. Some IPLs are unplanned, such as when the power is accidentally cut off to your computer room and the outage is long enough such that the system’s UPS batteries run out of juice, triggering a system shutdown. An on some occasions, an i5 partition can crash like a Windows box, forcing you to perform a cold boot in order to get the system up and running after the electricity comes back on. In fairness, however, I have only seen an OS/400-based system crash perhaps five times in my 20-plus years working on the platform, which is my own personal testament to the platform’s reliability.

Whatever the IPL reason, I generally find that it’s valuable to prepare two lists of activities for an i5 system power down and IPL, and to check off the items on each list before and after my IPL.

A pre-planning list, which contains all the activities that need to or can be accomplished before the system is IPLed.
A post-planning list, which contains all the activities and items that should be checked after the system is IPLed.

These lists are presented below. Obviously, you are not going to perform each item on both lists every time that you IPL. Many of these activities are optional, but beneficial. I structured this checklist to present most of your IPL options and obligations in one place. My goal is to provide a framework for an orderly approach to your IPL activities in order to take advantage of the opportunities an IPL presents as well as to warn you of some pitfalls that can trip you up when you shut down and restart the system.

Pre-Planning Your IPL

Here is my list of things to consider before IPLing your system. For involuntary IPLs (such as when an unexpected power outage outlasts your UPS capacity), many of these items cannot be accomplished. For voluntary IPLs, however, you should be able to perform all of the items on this checklist, if you so wish.

1. When should the IPL be performed? Timing may be critical both for servicing your business functions and for servicing your customers. If customers or business partners are interacting with the machine in any way, shape, or form, the IPL may need to be performed during off-hours or even on a holiday. I once worked at a retail-oriented company where the only time we could take down our AS/400 for an upgrade was on Thanksgiving morning before the stores opened. Now, you may not have to (or want to) cut things that close, but there are usually some very practical considerations involved when taking down your partitions.

2. If you are upgrading your i5/OS box or applying PTFs, do you have the necessary installation media and will you have any necessary PTFs loaded in advance of the IPL? Make sure that you have your upgrade or PTF plan in place, and that you have all the necessary media. PTFs are loaded when the system is active and some PTFs can be applied immediately. Many other PTFs need an IPL to be applied. If you’re on a tight IPL schedule and you don’t get the PTF media in time, you may have to IPL your system without applying your PTFs, which can lead to another avoidable IPL later when you do receive the media.

3. Do you want your i5 partition to automatically restart after the IPL? For hardware maintenance or to physically move your computer to another location, you will want to turn off your system and leave it off for a while. To turn off a partition with the Power Down System command (PWRDWNSYS), you would run the command like this:

PWRDWNSYS RESTART(*NO)

If your partitions are being controlled through the Hardware Management Console (HMC), you will also need to turn off the system frame the partitions are defined in, after the partitions are powered down.

To power down and restart the partition immediately, you can run PWRDWNSYS this way.

PWRDWNSYS RESTART(*YES)

4. Should your system come up in restricted mode? For some maintenance functions, such as when you are upgrading your operating system, adding hard drives to the systems, or changing your cache batteries, you will want your system to IPL into restricted mode when it restarts. Restricted mode starts your system without running its associated system startup program (the startup program starts all available subsystems and services at IPL. It can also start many third-party or custom-written applications). To learn more about i5/OS and OS/400 restricted mode, read “Getting In and Out of iSeries Restricted State.” To understand how to IPL a partition into restricted mode, check out an article I wrote called “You Can Re-IPL an AS/400 into Restricted State.”

5. What should your system look like after it is IPLed? Since many i5 boxes are seldom re-IPLed, your i5 startup program (QSTRUPPGM) may not be correctly configured to restart all the servers and subsystems needed to run your business after an IPL. To make sure everything is up and ready after the partition restarts, I usually run the following Work with Active Jobs command (WRKACTJOB) before an IPL to generate a printed copy of all the active jobs on my system.

WRKACTJOB OUTPUT(*PRINT)

This produces a printed record of what my system should look like when it’s up, running, and healthy. Besides generating a printed copy for my use, I may also leave a copy of the WRKACTJOB printout in an output queue on my system, so that I can reference or reprint it again later, if I need to.

With the WRKACTJOB printout, I usually review my startup program code to make sure that (as much as possible) there is available code to restart all the critical jobs when I IPL. I then put the WRKACTJOB printout away to be used after my system IPLs (see next section). I also like to make sure that I at least have a passing familiarity with how to manually start most of my critical server jobs, if necessary.

6. Are there any job queues that should be held during an IPL startup? For some heavily used job queues, such as QBATCH, I sometimes hold these queues right before my IPL to make sure that no critical job runs out of sequence or runs before all its available resources are available. If I do this, however, I find that I have to be careful to release the queues after the system is back up again.

7. Did you warn your users that the system will be unavailable for a certain amount of time? With many organizations accessing their i5 machine on 24×7 basis, I usually find that I have to warn my users in advance when the system will not be available, so that they can make plans to either work around the outage or to change departmental work schedules to account for the outage.

Post-Planning the IPL

After an IPL is completed and the system has restarted, it’s important to double-check your partition and make whatever corrections are needed to ensure that all your organization’s subsystems and jobs are up and running. Here’s my post-IPL checklist of things to review after an IPLed system comes back up.

1. If the system came up in restricted mode, did you remember to restart the system? If you’ve performed some maintenance function while in restricted mode, you can restart your system again by performing one of the following three techniques.

You can IPL the system a second time to restart the system immediately by running PWRDWNSYS with the RESTART(*YES) option, as shown above. Your system will run your startup program as it IPLs.

From the system console, you can call the startup program that is listed in the i5/OS Startup Program system value (QSTRUPPGM). Information on how to do this is contained in my article or “Re-IPLing an AS/400 into Restricted State.”

You can restart the partition from the Hardware Management Console (if you have one) by right-clicking on the partition and selecting Restart from the pop-up menu that appears. As the partition restarts, it will activate your startup program.

2. Did you make sure that all necessary i5 subsystems, programs, and devices are up and running. To make sure that my system comes up correctly after an IPL, I usually take the WRKACTJOB printout I generated in my pre-IPL checklist and I compare it item by item to the jobs and subsystems that came up after the system was IPLed. If something is missing, I can quickly locate the problem and restart the process.

Once I locate a job that should have been running after system startup but wasn’t, I will also troubleshoot my startup program, make any changes to the program to start the missing program correctly, and then I recompile the program so that the missed item will restart correctly the next time I need to IPL. For information on changing the i5 startup program, see “How to Change Your OS/400 Startup Program.”

For missing printers that should have been started but weren’t, I also make sure to check the Online at IPL parameter (ONLINE) of the printer’s device description to make sure that it is set to *YES, which will tell the operating system to start up the device after an IPL. If it is set to *NO, I change it to *YES. To find and change a printer’s device description, run the following Work with Device Descriptions command (WRKDEVD) and then select option 2=Change to edit the device and change the ONLINE parameter.

WRKDEVD DEVD(device_name)

For remote output queues, there is a Writers to autostart parameter (AUTOSTRWTR) in the output queue parameters that tells the system to start 1 or more writers for the output queue when the spooled file subsystem (QSPL) is started. If it is set to *NONE, it should reset to the number one (1) or greater.

3. Did you make sure that all moveable IOPs are still attached to the same partition that they were attached to before you IPLed the system? In my shop, we have several network cards, DVD drives, and backup devices that are attached to different partitions through a moveable IOP card (i.e., the IOP can be moved to another partition so that I can share the device with different systems). What I have discovered is that when I am taking down and restarting all partitions for my entire i5 system, there is no guarantee that a moveable IOP will reattach itself to the same partition that it was attached to before I IPLed the system. So as part of my IPL routine, I usually check to make sure that any device that is configured under a moveable IOP is still attached to the same i5 partition that it was attached to when I took down the system.

4. Did you release any job queues that were held in the preplanning stage. If I held a job queue as a result of my preplanning checklist, I have to remember to release it after the system is up and running correctly.

5. If you applied PTFs, were the PTFs applied correctly? You can check PTF application status after an IPL by running option 50, Display log for messages, under the Work with Licensed Programs menu (which is accessed by typing in the GO LICPGM command). This option will show you the results of any PTF processing performed during the IPL.

About Our Testing Environment

All configurations described in this article were tested on an i5 550 box running i5/OS V5R3. Most of the commands used here are also available in earlier versions of the i5/OS and OS/400 operating systems, so the configurations should be usable in prior releases. However, you may notice some variations in pre-V5R3 copies of these commands. These differences may be due to command improvements that have occurred from release to release.