Mainframe Playground

Display information about last IPL to find LOAD member location. Right command can be found in "z/OS MVS System Command" document.

Read about IEASYSxx member. Description and possible parameters in this member are described in "z/OS MVS Initialization and Tuning Reference". LOAD member is also described there. You'll need it in order to locate IEASYSxx member.

JES2 parameter member have fixed name so there is no suffix for it in IEASYSxx member. MSTJCL parameter in IEASYSxx is the key here.

Comamnd /D IPLINFO displays name of LOAD member used during IPL:

So we're interested in SYS1.IPLPARM(LOAD00) data set. LOAD member contains links to other most important data sets that are used during IPL. Here are few important parameters in LOAD member: LPARNAME – name of the LPAR. IODF – IODF data set name. SYSPLEX – name of the sysplex (if LPAR is in sysplex). PARMLIB – concatenation of PARMLIBs.

SYSPARM parameter in LOADxx member defines suffix of IEASYSxx member: "SYSPARM 00" tells that IEASYS00 member is used. Note that it is possible that SYSPARM is not coded. In such case SYSPARM can be specified in IEASYMxx member, so instead of SYSPARM you could find IEASYM parameter. IEASYM is often used when LOAD member and PARMLIBs are shared among many LPARs. You can also found there data sets in PARMLIB concatenation, for example: PARMLIB USER.PARMLIB PARMLIB SYS1.PARMLIB Faster way to check PARMLIB concatenation is to simply use command: /D PARMLIB System searches each of these PARMLIBs for required member. If it does not exist in the first one the second PARMLIB is searched, than the third and so one. After the member is found system stops search. So even if the member is present in multiple PARMLIBs first match counts. In this example USER.PARMLIB is first in concatenation so system searches IEASYS00 member in in first. If it does not exists SYS1.PARMLIB is checked. In IEASYS00 defines suffixes for PARMLIB members of many z/OS tasks. DFSMS is one them. In "z/OS MVS Initialization and Tuning Reference" we can found description of them: SMS=01 Description: "This parameter specifies the parmlib member, IGDSMSxx, from which the storage management subsystem (SMS) will obtain its options ..." So we're interested in IGDSMS01 member. As before we search for it in PARMLIBs concatenation. You must know how to find such information but when you simply need to check SMS options the easiest way is to simply issue command: /D SMS,OPTIONS Most of the sub-systems have similar commands. They are best way to check sub-system configuration. Another example for SMF: /D SMF,O Note: Usually there are many parameter members of the same kind, for example IEASYS00, IEASYS01 etc. Because of this we need always check which of those members is actually used by system.

JES2 Parameter member is named JES2PARM and it is not necessarily stored in PARMLIB concatenation. Because of this you must search for it in different way. In IEASYSxx member MSTJCL parameter specifies suffix for MSTJCLxx member. This member is the JCL procedure for starting Master Scheduler. "MSTRJCL=(00,L)" - 00 means that the procedure is called MSTRJCL00. Why we're interested in Master Scheduler? Because this task starts JES2 sub-system. We search for this member in PARMLIB concatenation. Here is example code of the member:

In "z/OS z/OS MVS Initialization and Tuning Reference" you can find description of each DD statement here. We're interested in IEFPDSI concatenation. This data sets contains important procedures that are used during IPL. Among them you'll find procedure for starting JES2 subsystem called "JES2". In JES2 procedure there are two DD statements worth mentioning. First is PROCxx, this DD statement defines concatenation of PROCLIBs that are used by JES2. You can run any procedure from that concatenation from you job without using JCLLIB statement. Second is HASPPARM, this DD statements points to the data set we're looking for. JES2PARM member is stored there.

Check “Introduction to the New Mainframe: z/OS Basics” and “z/OS MVS Initialization and Tuning Guide” documents for details about IPL. You can also check useful presentation “IPL Logic Flow V2”. From technical point of view IPL is only small part System Load but both System Load and System Restart are often refereed to as IPL.

What information do you need to know to perform IPL? First you must know machine and LPAR image name to identify LPAR in HMC. This information should be included in system documentation. You can also confirm them with command 'D M=CPU': CPC NAME = ZB2046 LP NAME = ZB06 - CPC NAME – Central Processor Complex name identifies “book” that is used by the system. One mainframe can have up to four “books”. Each book have CPC, dedicated to it central storage and many other components. You can see “book” as very sophisticated motherboard with its components. - LP NAME – LPAR image name. Note that LPAR name is not equal to SYSNAME. For the IPL itself you need three parameters: Load type: Normal, Clear, SCSI, SCSI dump. IPL device: XXXX Load parameter: AAAABBCD - Load type – this parameter depends on system configuration. Almost always 'normal' load is done. Clear options will clear all central storage to zeros. This is usually done via Reset Clear option so it's not needed during load. - IPL device – device number of SYSRES volume. As every device number it consists of four hexadecimal characters. - Load parameter has 8 characters and consists of four sub-parameters. ____________________ Describe Load Parameter. Load parameter format: AAAABBCD AAAA – device number of IODF. IODF is basically a data set that stores Hardware configuration for particular system. It is usually shared among LPARs. BB – LOAD member suffix (00 by default). Defines name of LOAD member “LOAD00” for instance. C – IMSI character (Initialization Message Suppression Indicator). It defines what kind of messages will be sent to consoles during system load. D – Nucleus suffix (1 by default). Defines name of nucleus. IEANUC0x is it's name, 'x' suffix is defined in Load parameter. It also depends on architecture type. In case of z/OS system two nucleus members will be used IEANUC0x which is universal one and IEANUC2x which is specific for 64-bit z/OS architecture. ____________________ How often and when IPLs are normally done? There is no rule here, some well configured system can be IPLed once a year or even less often. Others can be even IPLed every week. Test systems are IPLed more often since they don't have to be available to customers. IPLs are most often done because of various system maintenance activities. During time change or for installation of some system updates. Tasks that runs on system can be often updated without IPL. ____________________ Describe structure of SYSRES volume. Each disk used by z/OS must be preformatted. It is done with ICKDSF Utility. Here is universal format of such devices (R = record): R1 = Bootstrap 1 - it defines if DASD is IPL volume. If yes, Bootstrap 2 is read. R2 = Bootstrap 2 - it contains pointer to IPL Text and loads it. R3 = VOLSER - standard volume label. Rx = User VOLSERs (optional). Ry = IPL text (optional) - IEAIPL00 program that initiates IPL. Even if DASD is not SYSRES it has reserved two first records as shown above. ____________________ What is HMC? HMC (Hardware Management Console) is simply PC or laptop connected to the mainframe with installed HMC software. Of course each mainframe have many such PCs in case one of them fails. Because of this you should always have access to many HMCs. HMC provides remote access and this is how it's usually used. It provides many functions related to the machine hardware and LPARs that are defined on it. Most common HMC activities are: - IPLs – reset and load command. - changing MIPS setting. - access to 'Operating System Messages' which provides similar function as Master Console and can be used for problem determination when TSO is unavailable. ____________________ What is SE? SE (Support Element) is a laptop inside mainframe. Each machine has two SEs. It provides the same interface and similar functions as HMC.

IMSI functions: - Display Informational Messages - Prompt for Master Catalog Response - Prompt for System Parameter Response In this example 'YYN' means that first two types of message will appear but not Prompt for System Parameter Response. 1. 31FF01A2 LOAD member: LOAD01 IDOF device: 31FF IMSI: YYY Nucleus: IEANUC02 & IEANUC22 2. 0AACIO LOAD member: LOADIO IDOF device: 0AAC IMSI: NNN (default) Nucleus: IEANUC01 & IEANUC21 (default) 3. 3FG111S2 Invalid – IODF is device number coded in HEX mode. 'G' does not exist in HEX numeric system. 4. 333A..C LOAD member: LOAD00 (default) IDOF device: 333A IMSI: NYN Nucleus: IEANUC01 & IEANUC21 (default) '.' character can be used to skip LOADxx or IMSI value when you need to code some parameter after it. 5. 124399.9 LOAD member: LOAD99 IDOF device: 1243 IMSI: NNN (default) Nucleus: IEANUC09 & IEANUC29 6. ....99A1 Invalid – there is no default IODF value so you cannot use '.' in this case. 7. A323XZB Invalid – there is no 'B' IMSI mode. 8. 0011 LOAD member: LOAD00 (default) IDOF device: 0011 IMSI: NNN (default) Nucleus: IEANUC01 & IEANUC21 (default) You can skip all sub-parameters except IODF without using '.'. This is how IPL is usually done.

1. Issuing load command via HMC. It can be also done via SE, but this is rarely done this way. To issue load command choose Load option. You'll be prompted with dialog where you'll have to specify IPL parameters. - IPL device - SYSRES device number. - Load paramter – as already mentioned it consists of IODF device number, suffix of LOAD member, IMSI and nucleus suffix. - Load mode: Normal, Clear, SCSI or SCSI dump. 2. Bootstrap module load. Bootstrap is located on first record of first track on SYSRES volume. Bootstrap executes IEAIPL00 program. IPL at the beginning is done by single CPU but the process itself is very fast so it doesn't need more processing power at this stage. 3. IEAIPL00 processing. IEAIPL00 program is also called IPL Text. It clears central storage and prepares Central Storage for Master Scheduler address space. Then it executes IRIMs which are located in SYS1.NUCLEUS. 4. IRIMs processing. IRIMs (IPL Resource Initialization Modules) perform many functions during IPL. 4.1. LOADxx member is located and read. 'xx' suffix is passed in Load Parameter, if not LOAD00 is used. IRIM searches for LOADxx member in following data sets: SYS0.IPLPARM on IODF device SYS1.IPLPARM … SYS9.IPLPARM SYS1.PARMLIB on IODF device SYS1.PARMLIB on SYSRES device 4.2. IODF data set is processed. Name of IODF is defined in LOADxx member, for example: “IODF 99 SYS1” IODF keyword defines HQL and suffix of IODF data set, it always has two segments from which second one is IODFxx. Overall format is “IODF XX YYY” - it points to YYY.IODFXX data set. in this example IODF is called SYS1.IODF99 4.3. System nucleus is loaded. Nucleus is located in SYS1.NUCLEUS. Two nucleus members are used in z/OS: IEANUC0x and IEANUC2x, second nucleus name depends on architecture type. If you specified nucleus suffix in Load Parameter – it defines which nucleus is used. If not, LOADxx member is searched for NUCLEUS keyword which defines this suffix. If it's also not found default suffix is used: IEANUC01. 4.4. Master Scheduler initialization. After that Master Scheduler address space is started by IRIMs. Master Scheduler is always started as first address space so it has ASID=1. 4.5. Central Storage management is started. 4.6. Last thing that IRIMs do is the initialization of NIP (Nucleus Initialization Program). 5. NIP processing. At this point multithreading starts. Earlier only one CPU for used for the IPL process. 5.1. NIP executes RIMs (Resource Initialization Modules) which initialize basic system resources and devices. 5.2. PARMLIBs specified in LOADxx member are read. IEASYMxx, IEASYSxx, IEASVCxx and many other system members. IEASYSxx stores most important system parameters and points to other PARMLIB members. NIP always reads IEASYS00 first and often alternate IEASYSxx which was defined by System Programmer. If the same parameter is defined in both IEASYS00 and IEASYSxx then IEASYSxx overwrites parameter from IEASYS00. 5.2. Load modules are read into PLPA, FLPA and MLPA. PLPA – stores load modules that can be paged out (moved from Central to Auxiliary storage). FLPA – stores load modules that cannot be paged out. That are fixed in Central Storage. MLPA – this is temporary area which is used only during IPL. It can be used if you want to test particular load module during IPL. 5.3. Basic system services start. RIMs start most important address spaces and services used by system, for example: SRM, DUMPSRV, XCFAS, GRS, CATALOG, WLM, OMVS etc. 5.4. At the end RIMs pass control to Master Scheduler. 6. Master Scheduler initialization and processing. Master Scheduler address space already exists but the task itself really starts now. 6.1. Finalization of Master Scheduler subsystem. MSTJCLxx PARMLIB member contains parameter for Master Scheduler initialization. MSTJCLxx code sample:

JES2 normally takes care about all JCL processing but Master Scheduler startup procedure must run without JES2. Because of this it is passed directly to Internal Reader (INTRDR) it can execute such procedure without JES2. Another thing to notice is the IEFPDSI DD statement which defines most basics PROCLIBs on the system. Master Scheduler will search them for JES2 startup procedure called simply “JES2”. 6.2. JES2 startup and initialization:

JES2 startup procedure has another PROCLIB concatenation. Every started task procedure must be in this concatenation if it runs under JES2. HASPPARM defines member that contains JES2 setting almost always called JES2PARM. You can see JES2 initialization as the end of the System Load itself but after it many other critical subsystems must start like DB2s, TSO, VTAM etc. they are usually started by Automation Tool but you can also write your own CLIST or REXX script that will perform this function. From technical point of view System Load contains of three main states: - IPL (Initial Program Load); - NIP (Nucleus Initialization Program); - MSI (Master Scheduler Initialization).

1. Requirements – to be done when you are assigned to IPL. Before any IPL you must ensure that you have all the information you need, this of course depends on your site but here are some universal items you should know: - Change number and description of this particular IPL. - CPC and LPAR name. - IPL parameters. If you need to lad system with current parameters check them with '/D IPLINFO' command. - Contact to higher level support. - Contact to customer or SPOC (Single Point Of Contact is a team/person that has direct contact with customer). - If you're doing IPL on particular system for the first time, or you haven't logon to it for a long time, ensure you have appropriate access. 2. IPL preparation – to be done one or two hours before IPL. You should logon to all necessary tools some time before IPL in case some technical or authorization problems will appear. - Logon to TSO. - Logon to Automation Tool if available, for example NetView System Automation. - Logon to HMC. - Logon to Master Console or Operating System Messages in HMC. 3. Pre-IPL checks – to be done 5-10 minutes before IPL. In this step you gather system data that may be useful if any problems appear during IPL. You'll also use this data with Post-IPL checks for comparison of system state before and after IPL. Many commands here depend on tools used at your site. Below, except standard MVS command, NetView System Automation commands are also included, this is one of the most popular automation tool out there. 'F CNMS,DISPTREE CNMS' Shows task dependency tree. Almost always one task can be started only when another is already running. For example you cannot run *DBM1 DB2 address space without *MSTR. The same is true for many other tasks. You need this information in case you'll need to manually close or start some tasks without automation tool. 'F CNMS,DISPSTAT OUTMODE=LINE' 'F CNMS,INGLKUP' First command shows all tasks that are managed by NetView System Automation along with their statuses. Second command shows tasks that are not managed by Automation. You need this data mostly for comparison during Post-IPL checks. This way you know which tasks were up and which down before IPL. Your goal is to ensure that all tasks have the same status after IPL unless you have different instructions. 'D IPLINFO' Information about current SYSRES device, IODF device and LOADxx member. 'D M=CPU' CPC name and LPAR name is what you'll need from this command. '$DI' Status of initiators. 'D A,L' Shows all STC, TSU and JOB active address spaces on the system. System address spaces aren't there, to see them you can use 'D A,A' command although it's not needed in this case. 'D O' Prefixes of important subsystems like JES2, DB2, MQ etc. You'll need those in case you'll need to issue any command to such subsystems. 'D R,R' List of WTORs. You need this list for comparison with Post-IPL checks. Those are few basic checks but depending on your system configuration and customer demands they can be many more of those, for example Lines, Nodes, Printers status in case you'll need to start some of them after IPL, Sysplex status etc. 4. System shutdown – to be done at specific time or after confirmation. z/OS is specific in many ways, one funny characteristic of this system is that it does not have shutdown command. System Automation closes all tasks running on the system and then System Reset is done which you can see as system power off, although it simply clears Central Storage (RAM). - Stop job submission in scheduling tool (like Control-7 or TWS if needed) - Stop initiators controlled by JES2: '$PI' - Stop initiators controlled by WLM (if needed): '$PXEQ' - Check if jobs are running: 'DA OJOB' in SDSF. In case some jobs are running you'll have to either wait until they're done or cancel them. New jobs won't start because initiators are already stopped. Note that some tasks like CICS may run as a job, other jobs may run for days so you cannot wait too long. You should have specific instructions what you can do with running jobs before shutdown. - Issue Automation command (or run script) that will close all running tasks. - During system shutdown monitor tasks closure via Master Console or HMC OSM(Operating System Messages). Use 'D A,L' command. 'D R,R' and '$DJES2' commands are also very handy during shutdown. - If some subsystem is stuck you should try to close it manually from Master Console or HMC OSM. - When all tasks are down you must issue 'Z EOD' command. This command closes System Log and moves SMF records from buffer to SMF data sets. Without this command SMF records stored in buffer will be lost. - Now you can perform System Reset. Double check CPC and LPAR name before reset. Usually Reset Clear is done. 5. System Load – to be done immediately after System Reset unless you have different instructions. - Select Load option from HMC. - There you can specify IPL parameter load type, IPL device number (SYSRES) and Load Parameter (usually only first 4 characters - IODF) - Double check if all parameters are correct and confirm them. - Soon after that Master Console or Operating System Messages in HMC will start working. You must wait a while until system will be ready to process MVS commands. - Now you can monitor system load using the same commands: 'D A,L' and 'D R,R'. Sometimes you'll need to vary your console online before issuing any command. - You should wait for three tasks: VTAM, TCPIP and TSO. When they are up you should be able to logon to TSO and your System Automation tool. Of course during System Shutdown and especially System Load you can face all kinds of errors and problems. Most of them are too rare or installation specific to include them here but you'll also find few exercises later in that category. 6. Post-IPL checks – to be done when all or almost all tasks are up. In that phase system is up but you must check if all tasks and system setting are in correct state. - Again check status of all tasks and compare it with Pre-IPL list. In case of NetView System Automation you'll need to issue two commands: - 'F CNMS,DISPSTAT OUTMODE=LINE' - for tasks managed by NetView. - 'F CNMS,INGLKUP' – for task not managed by NetView. If task is in incorrect status you should probably start/close such task to fix it. But as always it depends on system documentation or other instructions. - Start initiators under JES2: '$SI1-3' (note that when starting initiators you cannot simply issue '$SI' you must specify number of initiators to be started. - Start initiators under WLM (if needed, WLM initiators are usually started automatically): '$SXEQ' - Start job submission in Scheduling Tool (if needed). Those were basic checks, other checks may include: - Checking Lines, Nodes and Printer in SDSF. You may need to start some of them. - 'D R,R' – WTORs, if you're not sure if you should investigate particular WTOR you can compare it with Pre-IPL WTORs. Usually there are some WTORs that are always present on the system. - 'D XCF' – you may need to check if LPAR returned to Sysplex although this should be done automatically. - Jobs in error – it's possible that after starting initiators some jobs will end in error because of problems caused by IPL. Check your scheduling tool is clear of such jobs. - Functionality of some tasks – sometimes customer may need to check certain functions for specific task. Sometimes after each IPL and sometime only after particular changes. This is small list created to give you basic picture of things you need to have in mind. Everything really depends on customer needs and specific installation. Standard IPL action should be included in system documentation while non-standard action should be included in the Change related to the IPL.

Refer to “IPL Basics” Assignment for procedures you should follow during IPL.

Unfortunately, there is no document that gathers commands for all common z/OS subsystems and tasks. It's a good idea to make you're own document that will store such commands for tasks you're working with. Almost all tasks depend on another tasks, for example most task require JES2 to be started. DB2 or MQ address spaces are controlled by *MSTR address space. You need to be aware of those dependencies during System Shutdown and Load.

Refer to checklist you've created in “IPL Basics” Assignment, in short: 1. Gather all useful information from the system. 2. Close job submission and JES2/WLM initiators. 3. Check if jobs are running. Either wait or cancel them. 4. Issue automation shutdown command that will close tasks. 5. Monitor shutdown and fix any problems if they appear. 6. When all tasks are down issue 'Z EOD' command. 7. Perform 'Reset Clear'. 8. Perform 'Load'. 9. Monitor load and fix any problems if they appear. 10. When tasks are up compare tasks status and other system setting(if needed) with data gathered before IPL and fix any problems if they occur.

You should do the same steps as in Task#1, the only difference is that instead of issuing shutdown command you'll close all tasks on system manually. Closure order, task types and name can be different on every installation. Here is list with some universal commands and rules. Most tasks can be closed with use of standard commands: P taskname C taskname FORCE taskname,ARM FORCE taskname Here is proper procedure for closing jobs and tasks. Of course it's best to have access to the task output in SDSF and monitor it there. This procedure can be used from any console: 1. Issue 'P taskname'. 'P' command is not supported by every standard task, if that's the case go to point 3. 2. Check why task isn't closed. - Sometimes you must simply wait a while. Use 'D A,taskname' command, 'CT' parameter there shows amount of processor time used by the task, if this value is increasing task is processing something and most likely it will close soon. - Check if there are any pending messages related to the task: 'D R,L'. Sometimes tasks issue WTOR after receiving stop command. - Check contention: 'D GRS,C'. Sometimes tasks may be stuck because of some unavailable resource. 3. Issue 'C taskname'. If you'll get “IEE841I taskname NON-CANCELABLE” message go to point 6. 4. Issue 'C taskname,A=asid'. Use 'D A,taskname' to display task ASID. 5. Check why task isn't closed (repeat steps described in point 2). 6. Issue 'FORCE taskname,ARM'. This kills task so you shouldn't wait long. 7. Check why task isn't closed (repeat steps described in point 2). 8. Issue 'FORCE taskname'. This is strongest command, use it only if you know you can do it for specific tasks. In some cases issuing it will cause data lost and may be serious problem. To start particular tasks you should simply issue 'S taskname,parameters' commands. Some tasks needs additional parameters (CICS for example), others don't. There can be of course many problems during startup. Use 'D A,taskname' command to check if it's address space is started. Also check WTOs 'D R,L' and contention 'D GRS,C'. Here are instructions for some tasks that are closed/started in non-standard way. AOPD (InfoPrint Server) InfoPrint consists of many tasks so it is closed and started by procedures shipped with the product: 'S AOPSTOP' 'S AOPSTART' CICS: Shutdown: - 'F cicsname,CEMT P SHUT' - 'F cicsname,CEMT P SHUT,I' - 'C cicsname' Startup: - 'S CICSNAME,START=AUTO' – Some CICSes are always started in COLD, but if you don't have specific instructions AUTO mode should be used. DB2: Shutdown: - 'db2pref STOP DB2' - 'db2pref STOP DB2 MODE(FORCE)' - 'C db2name' Startup: - 'db2pref START DB2' These command (except Cancel) should also start/stop main DB2 address spaces so you don't have to close IRLM, DBM1 etc manually. DFHSM: Shutdown: - 'F hsmname,STOP' - 'C hsmname' Startup: - 'S hsmname' JES2: Pre-shutdown: - '$PI' – stop initiators. Also '$PXEQ' if you have some WLM controlled initiators. - 'F BPXOINIT,SHUTDOWN=FORKINIT' – stops UNIX initiators. - '$PLINE1-99' – stops JES2 lines. JES2 wont close until jobs or tasks are running under it. Use '$DJES2' command to check names of those tasks. Shutdown: - '$PJES2' - '$PJES2,ABEND' Startup: - 'S JES2,SUB=MSTR' Certain tasks like JES2 or CNMS(NetView Automation) must run under Master Scheduler address space 'SUB=MSTR' parameter does the trick. Post-startup: - '$SLINE1-99' - 'F BPXOINIT,RESTART=FORKS' - '$SI1-6' and '$SXEQ' VTAM: Shutdown: - 'Z NET,QUICK' - 'Z NET,CANCEL' Startup: - 'S VTAM,,,(LIST=xx)' NET is also used as VTAM name. Other variants may be 'S NET,,,(LIST=xx),SUB=MSTR' or simply 'S VTAM'. As always it depends on the system setting. OMVS: Closing OMVS is more complicated and a lot depends on the installation. Note that OMVS must be closed after TCPIP is down since TCPIP uses OMVS services. It's best to close OMVS just before JES2 as one of the last active address spaces. Shutdown: - 'F OMVS,STOPPFS=NFS' – closes Network File System, it prevents data lost. - 'F BPXOINIT,SHUTDOWN=FORKS' – stops UNIX initiators running under JES2. - 'F OMVS,SHUTDOWN' – standard OMVS shutdown command. Sometimes you may also need to close ZFS although it should be automatically closed during OMVS closure: - 'F OMVS,STOPPFS=ZFS' Startup: - OMVS is always start automatically so there shouldn't be any problems with startup. TWS (Tivoli Workload Scheduler): TWS consist from at least two address spaces: controller (TWSC here) and tracker (TWST). They should be closed/started in specific order. Shutdown: - 'P TWSC' then 'P TWST' - 'C TWSC' then 'C TWST' Startup: - 'S TWST' then 'S TWSC'

IMSI value we're interested in is 'S'. With it you can specify IEASYSxx member prefix. You can also overwrite any initialization parameter in IEASYSxx. Note that no matter what IEASYSxx member you specify in LOADxx member IEASYS00 is always used. So if in LOADxx member you have SYSPARM=(US,99) your system will be initialized with parameters from following members: IEASYS00 IEASYSUS IEASYS99 Each later member in concatenation has higher priority so if the same parameter is coded in all three members the one from IEASYS99 is actually used. When you use IMSI 'S' value you'll be prompted with IEA101A WTOR. It always have number 0. Answer may consist of many sub-parameters for example: '0,SYSP=01,CMD=(01,XY)' The most important parameter is SYSP, you should always remember to specify it. Answer to this WTOR overwrites SYSPARM statement in LOADxx member. This means that if you'll answer without SYSP parameter, for example: '0,CMD=05' you'll simply nullify SYSPARM and in effect system will use only IEASYS00 member. Here are steps needed to finish this assignment: 1. Check which IEASYSxx member are used by your installation. Use 'D IPLINFO' command to find out LOADxx member used by your system. In it you'll have either suffix for IEASYSxx member. If not you should check it in appropriate IEASYMxx member. 2. Check in IEASYSxx which CLOCKxx member is currently used and copy it with different prefix. For example you can use CLOCKST (summer time) and CLOCKWT (winter time). 3. Modify copied clock member so it can be used during time change. Only parameter that needs to be changed is TIMEZONE: TIMEZONE E.01.00.00 – this is value for Polish winter time. 'E' means that your time zone is in the East from UTC time zone (UTC+1 in this example). 4. Shutdown System. 5. Change IMSI to 'S' and load system. 6. You'll be prompted with “IEA101A SPECIFY SYSTEM PARAMETERS FOR z/OS...” WTOR. Answer it accordingly to your system configuration, for example: “0,SYSP=US,CLOCK=WT” In this case system uses only one alternate IEASYSxx member (SYSP=US), parameters from IEASYS00 and IEASYSUS are used. CLOCK=WT overwrites CLOCK parameter from IEASYSxx members. In this case CLOCKWT is used. Note: This is just an exercise, the best way to change time is to use "T TIMEZONE=E.01" command and modify CLOCKxx accordingly, no IPL is needed. Still IPLs are often done during time change to avoid problem with time change for various tasks.