The initialization process begins when the System Programmer or Operator selects the LOAD function at the Hardware Management Console (HMC).

To successfully IPL z/OS, the system programmer needs to supply the following information:

-    The device address of the IPL volume

-    The LOADxx member that contains pointers to system parameters

-    The IODF data set that contains the configuration information

-    The device address of the IODF volume

z/OS locates all usable central storage that is online and available, and begins creating the various system areas.

Not all disks attached to a CPU have loadable code on them. A disk that does is generally referred to as an ″IPLable″ disk, and more specifically as the SYSRES volume.

IPLable disks contain a bootstrap module at cylinder 0 track 0. At IPL, this bootstrap is loaded into storage at real address zero and control is passed to it. The bootstrap then reads the IPL control program IEAIPL00 (also known as IPL text) and passes control to it. This in turn starts the more complex task of loading the operating system and executing it.

After the bootstrap is loaded and control is passed to IEAIPL00, IEAIPL00 prepares an environment suitable for starting the programs and modules that make up the operating system, as follows:

1. It clears central storage to zeros before defining storage areas for the master scheduler.

2. It locates the SYS1.NUCLEUS data set on the SYSRES volume and loads a series of programs from it known as IPL Resource Initialization Modules (IRIMs).

3. These IRIMs begin creating the normal operating system environment of control blocks and subsystems.

IPL Resource Initialization Modules (IRIMs)

Some of the more significant tasks performed by the IRIMs are as follows:

-    Read the LOADPARM information entered on the hardware console at the time the IPL command was executed.

-    Search the volume specified in the LOADPARM member for the IODF data set. IRIM will first attempt to locate LOADxx in SYS0.IPLPARM. If this is unsuccessful, it will look for SYS1.IPLPARM, and so on, up to and including SYS9.IPLPARM. If at this point it still has not been located, the search continues in SYS1.PARMLIB. (If LOADxx cannot be located, the system loads a wait state.)

-    If a LOADxx member is found, open and read information including the nucleus suffix (unless overridden in LOADPARM), the Master Catalog name, and the suffix of the IEASYSxx member to be used.

-    Load the operating system’s Nucleus.

-    Initialize virtual storage in the Master Scheduler address space for the System Queue Area (SQA), the Extended SQA (ESQA), the Local SQA (LSQA), and the Prefixed Save Area (PSA). At the end of the IPL sequence, the PSA will replace IEAIPL00 at real storage location zero, where it will then stay.

-    Initialize real storage management, including the segment table for the master scheduler, segment table entries for common storage areas, and the page frame table.

The last of the IRIMs then loads the first part of the Nucleus Initialization Program (NIP), which invokes the Resource Initialization Modules (RIMs), one of the earliest of which starts up communications with the NIP console defined in the IODF.

Nucleus Initialization Program (NIP)

During the NIP stage, the system might prompt the system programmer or operator to provide system parameters that control the operation of z/OS. The system also issues informational messages about the stages of the initialization process. IEASYSnn, a member of PARMLIB, contains parameters and pointers that control the direction that the IPL takes. The system programmer or operator may alter these parameters as necessary.

IEASYSnn, a member of PARMLIB, contains parameters and pointers that control the direction that the IPL takes.

The system continues the initialization process, interpreting and acting on the system parameters that were specified. NIP carries out the following major initialization functions:

-    Expands the SQA and the extended SQA by the amounts specified on the SQA system parameter.

-    Creates the pageable link pack area (PLPA) and the extended PLPA for a cold start IPL; resets tables to match an existing PLPA and extended PLPA for a quick start or a warm start IPL.

-    Loads modules into the fixed link pack area (FLPA) or the extended FLPA. Note that NIP carries out this function only if the FIX system parameter is specified.

-    Loads modules into the modified link pack area (MLPA) and the extended MLPA. Note that NIP carries out this function only if the MLPA system parameter is specified.

-    Allocates virtual storage for the common service area (CSA) and the extended CSA. The amount of storage allocated depends on the values specified on the CSA system parameter at IPL.

-    Page-protects the NUCMAP, PLPA and extended PLPA, MLPA and extended MLPA, FLPA and extended FLPA, and portions of the nucleus. An installation can override page protection of the MLPA and FLPA by specifying NOPROT on the MLPA and FIX system parameters.

Address space creation and subsystem initialization

In addition to initializing system areas, z/OS establishes system component address spaces. It establishes an address space for the Master Scheduler and other system address spaces for various subsystems and system components. Some of the component address spaces are: *MASTER*, ALLOCAS, APPC, CATALOG, and so on.

The Master Scheduler address space is the first system component address space to be created (ASID=1). Then, the Master Scheduler may start the primary job entry subsystem (JES2 or JES3). On many production systems, JES is not started immediately; instead, an automation package starts all tasks in a controlled sequence.

Then other defined subsystems are started. All subsystems are defined in the PARMLIB library, in member IEFSSNxx. These subsystems are secondary subsystems.

The private areas are available only to that address space, but common areas are available to all.

After the system is initialized and the job entry subsystem is active, the installation can submit jobs for processing by using the START, LOGON, or MOUNT command. When a job is activated through START (for batch jobs), LOGON (for time-sharing jobs), or MOUNT, a new address space is allocated.

You may use one of three types of initialization: Cold start, quick start, or warm start.

The primary difference between the three types is whether or not certain storage is treated.

Cold start

An IPL that loads (or reloads) the Pageable Link Pack Area (PLPA) and clears the Virtual Input/Output (VIO) data set pages.

The first IPL after system installation is always a cold start because the PLPA is initially loaded. Subsequent IPLs are cold starts when the PLPA is reloaded, either to alter its contents or to restore its contents if they were lost. This is usually done when changes have been made to the LPA (for example, when a new SYSRES containing maintenance is being loaded).

VIO is a method of using memory to store small temporary data sets for rapid access. However, unlike a RAM disk on a PC, these are actually backed up to disk and so can be used as a restart point. Obviously there should not be too much data stored in this way, so the size is restricted.

Quick start

This is an IPL that does not reload the PLPA, but clears the VIO data set pages. The system resets the page and segment tables to match the last-created PLPA. This is usually done when there have been no changes to LPA, but VIO must be refreshed. This prevents the warm start of jobs that were using VIO data sets.

Warm start

An IPL that does not reload the PLPA, and preserves journaled VIO data set pages. This will allow jobs that were running at the time of the IPL to restart with their journaled VIO data sets.

Often, the preferred approach is to do a cold start IPL (specifying CLPA). The other options can be used, but extreme care must be taken to avoid unexpected change or backout of change. A Warm start could be used when you have long-running jobs which you want to restart after IPL, but an alternative approach is to break down those jobs into smaller pieces which pass real data sets rather than use VIO. Modern disk controllers with large cache memory have reduced the need for VIO data to be kept for long periods.

Also, do not confuse a cold start IPL (CLPA would normally be used rather than the term ″cold start″) with a JES cold start. Cold starting JES is something that is done extremely rarely, if ever, on a production system, and totally destroys the existing data in JES.

Sometimes a PDS library needs to be compressed to reclaim the free space caused by member deletions. The recommended procedure for compressing an LLA-managed library is:

1. Create a new CSVLLAxx member that includes a REMOVE statement identifying the library that needs to be compressed (ex: CSVLLA02).

REMOVE(SYS1.EXAMPLE.FILE)

2. Then issue the F LLA,UPDATE=xx command (ex: F LLA,UPDATE=02).

3. Compress the library. You can either use “Z” against the data set you want to compress from the ISPF panel or submit a job to do the compress.

4. Create a new CSVLLAxx member that includes a LIBRARIES statement to return the compressed library to LLA management (ex: CSVLLA03).

LIBRARIES(SYS1. EXAMPLE.FILE)

5. Then issue the F LLA,UPDATE=xx command (ex: F LLA,UPDATE=03).

NOTE:

CSVLLAxx is a member of SYS1.PARMLIB.