Audit Serve, Inc.

The Worldwide Connection for Audit, Security, Control and SOX Professionals

Understanding the MVS IPL Process

By: Mitchell H. Levine, CISA
Audit Serve, Inc.

                                                             

Low Cost & Highly Skilled 
IT Audit and SOX Consulting Resources Available Immediately
Call Mitch Levine at (203) 972-3567 or 
email levinemh@auditserve.com for additional information

Background

The hardware IPL (Initial Program Load) process is just one phase that occurs during the overall operating system initialization process. However, for purposes of this article, the system initialization process will be referred to as the IPL. The actual hardware IPL has remained unchanged throughout the technological advances that have been made in the System/370 architecture. However, the methods to retrieve components used in the system initialization has significantly changed in the last four releases of MVS (MVS/ESA release 4.3, 4.2.2, 4.2, and 4.1).

The main processes performed during system initialization is the creation of the system component address spaces, the initialization of subsystems, and the loading of components which tailor the system. The SYS1.PARMLIB dataset and the SYSn.IPLPARM datasets (i.e., made available in release 4.2), are read by NIP (Nucleus Initialization Program) during the IPL. These datasets are the main components of the system initialization that defines that parameters of a particular system.

Some system software changes require that an IPL be performed in order to install the changes. These types of IPLs are referred to as "scheduled" IPLs. However, the number of scheduled IPLs have been significantly reduced with the MVS/ESA 4.x releases. MVS/ESA 4.x provide facilities (e.g., MVS commands) that can dynamically update system definitions, which previously required an IPL.

Unscheduled IPLs are performed when a major system failure occurs. An unscheduled IPL resets the system software to its initial status before the failure occurred. The commands that are entered by the console operator are the same as are entered for a scheduled IPL. However, the actions that are taken before and after the IPL will differ. When an unscheduled IPL is required because of a system failure, the system programmer will usually request a stand-alone dump to help determine the cause of the failure. During the stand-alone dump, the entire contents of real and virtual storage are dumped.

Description of the IPL Process

There are two types of consoles that are used to support the MVS environment. The 3090 console, which is also referred to as the system console, is used to initiate the IPL. The 3090 console has a series of panels which are referred to as control frames that are used to perform system functions at the hardware level.

The other console is the MVS console which is where most console activity is performed. Operators use the MVS console to issue MVS and JES commands and to receive messages from the system relating to system activity.

The first part of the IPL is performed from the 3090 console. From the System or Operator Control Frame, the operator specifies the UCB address of the volume that will contain IPL dataset. A five character parameter (i.e., PARM) is also entered in the control frame which identifies the two character suffix of the LOADxx member, a one character parameter which determines whether the operator will be prompted to perform overrides during the IPL (i.e., m = not prompted and a = prompted), and a one character suffix for the IEANUC0x.

Once the address of the IPL pack and the PARM is loaded, there is no additional activity performed from the 3090 console to support the remaining part of the IPL. The IPL proceeds by reading track 0 of the IPL pack into a predefined location in memory. Control is then passed to a program which boots the machine and locates SYS1.NUCLEUS from the VTOC of the IPL volume and loads the IEANUC0x load module. This is referred to as the Nucleus Initialization Program (NIP).

The IPL process includes the initialization of other system components such as:

loading the parameters and members defined in the IEASYSxx member (i.e., xx is determined by the SYSPARM statement in the LOADxx member)

building the catalog address space

building the master scheduler

building PLPA

initializing the address space to build virtual storage environment (note: up to this point only real memory was used)

initializing the console address space in virtual storage to support the MVS consoles which allows a dialog to begin between the operator and the machine.

starting the primary subsystem (i.e., JES2 or JES3) and other subsystems (e.g., Netview).

Once JES is started, the IPL is considered completed but the system initialization continues by starting other systems that are required for the processing environment (e.g., VTAM, TSO, security).

Understanding the Changes to PARMLIB Which Impact the IPL

The IEASYSxx member is the focal point of an auditor’s operating system review since it identifies other modules which impact the integrity of the operating system.

The IEASYSxx member is the initialization parameter file which is loaded into the system memory during the Initial Program Load (IPL). IEASYSxx is stored in SYS1.PARMLIB and contains parameters that customizes how the operating system components function s from a performance and processing standpoint. In addition, the IEASYSxx member provides suffix references to other source PARMLIB parameter files which are loaded into system memory during the IPL which also controls system processing. In many cases t hese referenced parameter files define system libraries to MVS.

Prior to MVS/ESA 4.x

Starting with MVS/ESA 4.1, IBM provided an automated process to load the system parameter files which reduces and effectively prevents the operator’s ability to override system parameters during the IPL. Prior to MVS/ESA 4.1, the system automatically loa ded the IEASYS00 member and prompted the operator at the MVS console with the "IEA101A SPECIFY SYSTEM PARAMETERS" message to determine if there are other versions of the IEASYSxx member to be loaded or if individual system parameters are to be loaded. Al ternate IEASYSxx member can be loaded by specifying SYSP=xx (i.e., xx is the two character suffix of the IEASYSxx member). If OPI=YES is set in the IEASYS00 member, then individual parameters within the IEASYS00 can be changed. These parameter changes c an include parameters which load in libraries (APF=02 would load in IEAAPF02) or parameters that do not reference other PARMLIB member.

All parameter references within the IEASYSxx member that are loaded would replace or be appended to the parameter settings in the IEASYS00. An example of a replacement would be individual parameters that do not reference versions of other parameter files (e.g., LNKAUTH=LNKLST). An example of parameters that reference other parameter files which would append definitions that were initially defined in the IEASYS00 would be the APF=xx parameter which references IEAAPFxx. The APF=xx reference within IEASYS xx would define additional APF libraries that were originally defined in the APF=xx parameter set in the IEASYS00. However, even parameters that reference other parameter members can override settings in the referenced parameter file (e.g., CONSOLxx whic h specifies console definitions can have settings which change the characteristics of a defined system console). In the past, auditors were mistaken in thinking that an OPI=NO setting would prevent a different version of IEASYSxx from being loaded.

MVS/ESA 4.x

MVS/ESA 4.x introduced extensive changes relating to SYS1.PARMLIB. SYS1.PARMLIB is no longer required to be on the SYSRES volume and is now located through the master catalog. There is a new parameter in the 3090 console control frames that are used to I PL the system, allowing the operator to specify the IPL volume. During the IPL, the IPLPARM volume is searched for SYSn.IPLPARM or SYS1.PARMLIB dataset in order to locate the LOADxx and NUCLSTxx members.

As of version 4.1 of MVS/ESA, the LOADxx PARMLIB member has been added, reducing the operator intervention that is required during the IPL. With the LOADxx member, an installation can specify the volume which contains SYS1.PARMLIB (i.e., the volume to IP L from), the master catalog to use, whether to prompt the operator for additional system parameters, and to specify an alternate IEASYSxx member to use during the IPL.

LOADxx specifies the IEASYSxx version to use, which can be exclusive of IEASYS00. This capability eliminates the need for operators to specify SYSP=xx override in order to load a different IEASYSxx version. However, the operator can override the disable feature which prevents them from entering system parameters during the IPL when using the 3090 console IPL frame.

NUCLESTxx allows an installation to add installation modules to the nucleus (e.g., user SVC) and to delete nucleus resident programs. It should be noted that only module deletions but not module insertions will be recorded to the system log (SYSLOG).

The actual values that are contained in certain PARMLIB members can be written to the SYSLOG when they are loaded during the IPL. This can be done by specifying "L" within the entry for the parameter file within IEASYSxx (e.g., SCH=01,L). This is an im portant feature since there was no method for identifying the actual contents of these modules that were loaded during the IPL. Even products such as CA-Examine/MVS do not provide this information from memory. It only provide the disk-based versions, which could have changed since the last IPL.

IPL Controls

Regardless of whether an automated process has been established to abstract the appropriate PARMLIB members without requiring operator intervention, all scheduled and unscheduled IPLs should be appropriately approved by management. In addition, since it is possible to override the automated IPL process through the 3090 console, the SYSLOG and the view log within the 3090 console (i.e., no file or printout available from functions performed through 3090 console) should be reviewed to ensure that all over rides were appropriate. It should be noted that certain parameters within IEASYS and other parameter files can be dynamically changed after the IPL by using MVS commands. Therefore, an independent review process should be in place to ensure that all changes are appropriate.

Many alternate versions of PARMLIB members are used in order to load the correct environment based on the requirements of an installation for that particular time. Therefore, an installation should have a justification for the use of all versions of the PARMLIB members. The individual PARMLIB members should also be reviewed for their appropriateness as they apply to the individual control areas.

This article was written more than three years ago. Events may have changed since this article was written.

Copyright  2006, Audit Serve, Inc. All rights reserved. Reproduction, which includes links from other Web sites, is prohibited except by permission in writing.

This article appeared in a past issue of the Audit Vision E-Mail Newsletter.

Technical Articles | Conferences | Audit Programs | Audit Serve Seminars | Consulting Services | Audit Vision Newsletter | What's New | Contact US

This website has been optimized for Netscape and Internet Explorer 4.0 and above.  Your comments and suggestions are always welcome, please email webmaster@auditserve.com.
Copyright © 2000  All rights reserved.  27 Pine Street, Suite 700, New Canaan, CT 06840 USA.