Later this year we will be ordering z/OS 3.1 as part of our upgrade from z/OS 2.4. For us, this is an event that happens once every 3-5 years so being engaged in this process is a golden opportunity if you are fairly new to z/OS. Even less frequently is how often we create new z/OS LPARs on our physical machines to support or new workloads. My hope in writing this is to give those new to Z the motivation to get engaged with your senior peers so that you don't miss the opportunity to build something from scratch.
The process of getting a new z/OS image from its newly installed state to operational ready can be a long process depending on the size of your z/OS system and how vigorous testing is performed. This blog is intended to scratch the surface and take you through the early portions of that process - to the point where you have a shiny new z/OS system or LPAR.
In order to IPL a z/OS system a number of required elements need to defined/created. A z/OS system is booted from a SYSRES volume. Now I am not going to cover how a z/OS image (SYSRES volume) is created, but one of the first things that needs to be done is to provide a loader for kick starting the operating system. Kick starting the operating system is provided by something called IPL text and the ICKDSF utility is used by the Systems Programmer for creating the IPL Text on the SYSRES volume.
Once an operating system image has been built the next major step is to associate that operating system to a hardware platform. This is a two-phase effort where first an IODF (I/O Definition) is created which defines something called an LPAR. An LPAR is short for Logical Partition and is just one of the ways in which the mainframe virtualizes the hardware to support multiple operating system images to a single footprint. Once the IODF is built, there are two ways to define the new LPAR to the hardware such that the firmware can support the new OS image. For those infrequent cases where a new machine is being implemented, a standalone utility new is used to read a text version of the IODF (called an IOCP). In cases where a machine is already supporting one or more LPARs and you wish to add another, a dynamic activate can be used using the newly defined IODF containing the definitions for the new LPAR.
Once the operating system is built and ready to be started, the Systems Programmer or Operator logs on to the HMC, selects the LOAD screen to IPL the new (or upgraded) z/OS system. The operator initiating the IPL must provide the 8 byte of Loadparm where the first 1-4 bytes is the Unit address of the IODF volume. The IODF again is THE file which defines the LPAR layout for the physical machine hosting the operating system and I/O connectivity for each LPAR. The next 2 characters of the Loadparm is the Load member suffix, then the IMSI single character (how much do you want to see of the messages during the IPL process, 'M' for all messages, a '.' or blank if you want to see none), and the final character identifies the z/OS nucleus (IEANUC0x suffix), where IEANUC01 is the default. The Operator enters the 4 characters of the Sysres Unit Address volume where the operating system is started from and clicks on Load button.
The initial Console messages can be located from the z/OS master console session for the LPAR. If a console is not available messages can be seen from the HMC by clicking on Daily and System Messages.
Now I will mention briefly the search path for the IPL & IODF volumes, the function of the LOADxx member. If you are like me, you may experience some of the most common errors when the IPL settings are not correct.
First, the IPL process must find several critical I/O attached devices such as disk and the coupling facility if the LPAR is a member of a Parallel Sysplex. The IPL process must find the IODF in the Unit Address Volume specified, or the System enters a B1 Wait State.
After you ReIPL, if the IODF is found and the Load member cannot be found the System enters an 88 Wait State. A ReIPL is then required again. Once the Load member is located either in SYSn.IPLPARM (where n is 0-9) or SYS1.PARMLIB, then the options specified in the Load member are followed. Once the IPL gets underway the first Address Space that is created is the MASTER, Program IEEMB860 creates this and the JCL is found either in the MSTJCLxx in Parmlib or as a Load module in SYS1.LINKLIB. There are 3 Common Areas that are created at this time, the System Queue Areas (SQA/ESQA) where Address Space Ids are found and Unit Control Blocks (UCBs) for all devices. The Link Pack Areas (PLPA/EPLPA) for SYS1.LPALIB and any datasets in the LPALSTxx member providing CLPA has been specified in the SYSPARM member and the Common Service Areas (CSA/ECSA).
At this point the console may roll through several hundred messages. These represent the hundreds of activities take place behind the scenes. This includes starting critical address spaces such as RACF, Sysplex clustering services, TCPIP, System Logger, Unix System Services and other vital components. Once Master Address space and these other critical components are started, JES2 is started followed then by Middleware, automation products such as IBM System Automation and job schedulers where most of the remaining z/OS workload supporting your applications are started/managed. When a new operating system is successfully IPL'd, it is always worthwhile to review the syslog to understand what is being started. This is a good time to review what tasks are being started successfully or what may have failed. It is also a good time to acquaint oneself with the z/OS Health Checker and run the various health checks as part of your QA process.
#IBMChampion #ibmchampions-highlights #ibmchampions-highlights-home