Management Information › System Overview Display › Initial Program Load

Initial Program Load

Once a system is installed, it is necessary to start the z/OS operating system through a procedure called an initial program load (IPL). IPLs should be scheduled and performed only when necessary. If scheduled IPLs for maintenance activities or changes to the system parameters are performed once or twice per week, particularly during off hours, the impact to system productivity should be minimal. On the other hand, unscheduled IPLs usually indicate system problems. While z/OS provide the capability to dynamically refresh system options after IPL, be aware that there are certain changes that can be introduced only with an IPL, and some changes only with a cold start IPL (CLPA). An example of the latter might be an IPL to recreate the link pack area (LPA).

Remember, each IPL carries some risk that z/OS parameters can be changed or that something can be incorporated into the operating system that introduces a security or integrity problem. Unless OPI=NO is specified in the IEASYSxx members of the logical Parmlib, the computer operator can alter z/OS parameters at IPL. Alternate general logical Parmlib members can be specified in response to the prompt ENTER SYSTEM PARAMETERS. Specifying OPI=NO can reduce the operator’s ability to alter z/OS parameters, but it can also limit the operator’s ability to recover from parameter problems. You can determine if the OPI parameter is used by reviewing the Parmlib IPL Map Display (2.1.1) and by browsing the IEASYSxx logical Parmlib members.

Because any IPL presents the chance to modify the operating system, each IPL should be documented in the operator’s shift log. To ensure that the reason for each IPL is documented, the SMF option IPL=PROMPT should be included in the SMFPRMxx members of parmlib. Operations and technical support should then review the reason for each IPL to verify that no unauthorized changes occurred.

The date and time entered at IPL are critical, and it is necessary to ensure they are correct. If not, it is possible that the data center’s security system could be circumvented, a tape management system or scheduling job can produce undesirable results, or system journals could become damaged. You can verify the date and time of the last system IPL. The first line of the System Overview Display (1.1) identifies the current running date and time, which should be checked against a calendar and a reliable clock.

Also of importance when discussing IPLs are the following items:

• Address and volume of the system residence (SYSRES) volume used to supply the operating system.
• Address and volume of the DASD unit containing the Input/Output Definition File (IODF) produced by the HCD process.
• The contents of the eight-character LOADPARM value specified at IPL via the SYSCTL hardware frame or via the IPL command if using a z/VM Virtual Machine.
• All operator-supplied data, responses to prompts, and so on during the IPL process.

The SYSRES volume should be tightly controlled to protect against undesired modification. Installation procedure should dictate which DASD volume is to be used to perform the IPL and the actual IPL should not deviate from that procedure unless the reason is approved by management and is sufficiently documented.

Similarly, the IODF volume and in particular the IODF data set should be tightly controlled to protect against undesired modification. Again, installation procedure should dictate which DASD volume is to be specified at IPL and the actual address specified at IPL should not deviate from that procedure unless the reason is approved by management and is sufficiently documented. The IODF address is specified as part of the eight-character LOADPARM value supplied by the computer operator when performing the actual IPL.

The eight-character LOADPARM value contains two major items of interest to us here, and these are the address of the IODF volume, and the two-character suffix of the LOAD member to be used during IPL initialization processing. The LOAD member contains critical information which can specify the master catalog, initial IEASYSxx member value, the logical Parmlib data sets, and more. The LOAD member is obtained by first searching through the SYS0.IPLPARM through SYS9.IPLPARM data sets on the IODF volume, and then through the SYS1.PARMLIB data set residing first on the IODF volume, then on the SYSRES volume.

The operator-supplied data specified during IPL is also significant because, as has been mentioned numerous times before, the operator can specify numerous overrides which can affect how the system is IPL’d. Among other things, the operator can override the default master scheduler JCL (MSTJCLxx) member which might in turn be able to supply overrides for critical system libraries such as the procedure library (IEFPDSI), the logical Parmlib library (IEFPARM) and others.

A valuable tool to use during an IPL review is the console log. The console log indicates which, if any, logical Parmlib members were used to tailor the system. Keep in mind, however, that certain information, such as the alternate general member entered at IPL, can be prevented from printing with the Message Processing Facility (MPF). If possible, always use a printout of the disk version of the console log.