IPL PROCESS

1 Initialization – Getting a system up and running
Consider a computer with no operating system currently in it. The first necessity is to get a workable operating system in it, so that JOBs can be run. This is not a trivial process: not that there is not program fetch resident in the machine no I/O access method routines, and not even a current set of PSW’s in low core for directing interrupt actions.
For OS/360, the initialization process is composed of two parts: IPL and NIP. IPL (Initial Program Loader) initialized memory and some other things, and bring the nucleus (the core of the OS) into memory. NIP (Nucleus Initialization Program) performs the remaining actions required to set up a specific nucleus to be ready to execute.
1.1 IPL – Initial Program Loader
The process of getting an OS/360 system running is called IPLing, and includes the following main steps:
The operator makes sure the disk pack called SYSRES (System Residence) is mounted on a disk drive. The load unit switches are set to show the device address of the SYSRES disk pack, and the load button is pressed. This causes the control record to be read from the first record on the disk pack, consisting of a PSW and two CCWs, placed at location 0 in memory. PSW is the Program Status Word and in System/360 controls how the computer functions. CCW is the Channel Command Word and is defines how data is read from an I/O device. It ends with a LPDS to give control to the IPL program at memory location 0.
IPL selects which nucleus will be loaded (here may be a choice which can be given by switches on the System/360 operator consoles). The System/370 and System/390 consoles have service frames where the nucleus information is stored.
IPL clears all memory about itself to zero, also obtaining the size of memory; i.e. it stores until an addressing interrupt occurs.
IPL clears the floating-point registers, thus finding out if the floating point is installed. This is only on System/360 machines. Newer machines have a floating-point support as a default.
IPL brings the nucleus into memory; first, it relocates the part of itself not yet executed into high memory (near 252K), so that the nucleus can be placed beginning at memory location zero. It then simulated program fetch, loading the CSECTS of the nucleus load module into memory. The first CSECT loaded is the NIP. Loaded job below IPL, followed by the I/O interrupt handling at zero (0) (which thus defines all of the special PSW’s in low memory). IPL then passes control to NIP.
1.2 NIP – Nucleus Initialization Program
The IPL process described above applies to all version of OS/360. The NIP is generated in different ways, depending on the specific type of system and choice of options desired. Note: NIP is a CSECT, which is Link-Edited with the nucleus, so that it can refer to sections of the nucleus via address constants, and provide efficient, and specific initialization services. It includes the following steps:
The CVT (Communications Vector Table) is initialized, and its location placed at location 16, so that it can be accessed from any routine, whether part of the nucleus or not.
NIP determines whether the System/360 computer has LCS (Large Core Storage) attached to it or not. Yes that memory was truly core storage with little donuts hung between crossing wires!
NIP checks the workability of operator console(s), and also checks the workability of ready direct-access storage devices (DASD) (using test I/O (TIO) instructions. It particularly checks that the SYSRES volume is mounted and contains certain datasets needed by the system.
NIP performs various housekeeping actions, such as checking and setting the timer to make sure it is working correctly, initializing some pointer for storage management, initializing the SVC table (which give a pointer to each routine associated with a defined SVC number. It also sets up to be able to obtain modules from the SYS1.LINLIB dataset, which contains the heaviest-used load modules for the system and also establishes communications with the operator.
For any system having one, NIP loads reentrant modules into the Link Pack. These modules can be used during following executing, and are loaded at the high end of memory. In a system with fast memory and LCS, the Link Pack can be split, residing at both the high end of fast memory and at the high end of LCS. In Virtual systems, the Link Pack can reside below 16Megs and above 16Megs.
With the addition of various other miscellaneous operations, NIP prepares a region, which will contain the Master Scheduler, which is the program doing overall JOB scheduling and operator communication. The system is finally ready to run JOBs.
At this point, memory layout is as follows:

High Address Link Pack Reentrant modules

Master Scheduler

Free Area

SQS (System Queue Space) Dynamic area for problem programs
Low Address Nucleus Control blocks – CVT, TCBs and others



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.