Autostart concepts in z/OSMF

z/OSMF is started when you IPL your z/OS system. This behavior, which is referred to as z/OSMF autostart, means that z/OSMF is available for use as soon as the system is up.

To make the best use of the z/OSMF autostart capability, you must plan how to deploy one or more z/OSMF servers in your environment. Generally, having one z/OSMF server active in a sysplex or monoplex is sufficient, but you might choose to have more, based on your workload requirements. The goal is to ensure that at least one z/OSMF server is always active in your environment.

For a monoplex, little or no planning is needed. The z/OSMF server is started when you IPL the system.

For a sysplex, more planning is required. You can choose to have one z/OSMF server autostart on a particular system and be used by the other systems in the sysplex. Or, you can select a subset of systems, or several subsets, and associate each subset with a specific z/OSMF server within an autostart group.

If you do not want to use the autostart capability, some planning is needed to either remove it or to disable autostart, even in a monoplex. For more information, see Scenario 4: The z/OSMF server is not autostarted on any system.

The set of systems that is served by an autostarted server is known as the autostart group. z/OSMF includes one autostart group by default. To have more z/OSMF servers autostarted in a sysplex, you must associate each server—and the systems it serves—with a unique autostart group name.

In your planning, you must decide:
  • What the autostart groups will be in your sysplex
  • Which systems will autostart a z/OSMF server
  • Which systems will share the use of the autostarted server; these systems must be defined to the same autostart group.

Only one z/OSMF server can be active per autostart group in the sysplex. An autostarted z/OSMF server holds an enqueue on the z/OSMF data directory file system, and handles the z/OSMF requests from other systems that are connected to the same autostart group. Based on your planning, you can enable the desired number of z/OSMF autostart groups for your sysplex.

To create one or more autostart groups in z/OSMF, use the following statements in parmlib member IZUPRMxx in combination:
AUTOSTART(LOCAL|CONNECT)
Specifies the capability for autostarting the z/OSMF server on this system.
  • AUTOSTART(LOCAL) indicates that the system is capable of autostarting a z/OSMF server.
  • AUTOSTART(CONNECT) indicates that the system cannot autostart a z/OSMF server. The system will, instead, use the z/OSMF server on another system in the same autostart group.

By default, AUTOSTART is set to LOCAL.

AUTOSTART_GROUP(IZUDFLT|'nnnnnnnn')
Assigns a name to the autostart group. z/OSMF includes one AUTOSTART_GROUP name by default (called IZUDFLT). To associate a group of systems with a different autostart group, ensure that each system specifies the same value for AUTOSTART_GROUP.

By default, AUTOSTART_GROUP is set to IZUDFLT.

If one autostart group is sufficient for your sysplex, it is recommended that you allow each system to use the IZUDFLT autostart group.

The following scenarios are valid in a multi-system environment:

Scenario 1: One z/OSMF server is autostarted for the entire sysplex

In this scenario, the z/OSMF server is autostarted on one system in the sysplex. All systems are associated with the default autostart group, which is named IZUDFLT.
Figure 1. Scenario 1: One z/OSMF server is autostarted for the entire sysplex
Scenario 1: One z/OSMF server per sysplex. Every system is associated with the same autostart group.
In Figure 1:
  1. Each system uses the following default values for autostart: 
    AUTOSTART(LOCAL)
AUTOSTART_GROUP(IZUDFLT)

    With these values set for all systems, the first one to complete IPL is the system on which the z/OSMF server is started.

  2. System A is the first system to complete IPL in the sysplex. Its attempt to autostart the z/OSMF server is successful.
  3. System B, C, and D complete IPL. These systems detect that an autostarted server is active on System A, so they do not attempt a server. Instead, they use the server on System A.

In a sysplex of z/OS V2R3 systems, this scenario is enabled by default. If it is sufficient for your requirements, you can use the z/OSMF defaults. If you care which system in the sysplex autostarts the z/OSMF server, keep the default values for that system and change the AUTOSTART value to CONNECT for all other systems in the same autostart group.

Scenario 2: Multiple z/OSMF servers and autostart groups per sysplex

In this scenario, more than one z/OSMF server is to be autostarted in a sysplex. Suppose, for example, that you have a sysplex of four systems: A, B, C, and D. You plan to have System A autostart a server and share it with System B. Similarly, System C will autostart a server and share it with System D.

In this scenario, each server and the systems it serves are associated with an autostart group, as follows:
  • System A and System B are associated with the autostart group IZUDFLT
  • System C and System D are associated with the autostart group ALTERNATE.
Figure 2. Scenario 2: Multiple z/OSMF servers and autostart groups per sysplex.
Scenario 2: Two autostarted z/OSMF servers in a sysplex of four systems. Each system is associated with one of the two defined autostart groups.
In Figure 2:
  1. Each system uses a different IZUPRMxx member with different settings for AUTOSTART and AUTOSTART_GROUP.
  2. System A autostarts a z/OSMF server. System B uses the autostarted server on System A.
  3. System C autostarts a z/OSMF server. System D uses the autostarted server on System C.

Scenario 3: Some systems belong to an autostart group, and other systems do not

In this scenario, some systems belong to an autostart group, and other systems do not. Suppose, for example, that you have a sysplex of four systems: System A, B, C, and D. In this sysplex, you plan to have System A autostart the z/OSMF server and share it with System B. System C and System D will not use an autostarted z/OSMF server. The z/OSMF server can be started on these systems manually, by using the START operator command with the name of the z/OSMF started procedure (IZUSVR1).

In this scenario:
  • System A and System B are defined to autostart group IZUDFLT
  • System C and System D are not defined to an autostart group.
Figure 3. Scenario 3: One z/OSMF server is autostarted for a subset of systems in a sysplex.
Scenario 3: One autostarted z/OSMF server in a sysplex of four systems. Two systems are associated with the same autostart group. The other systems are not defined to an autostart group.
In Figure 3:
  1. Systems A and B specify AUTOSTART_GROUP(IZUDFLT).
  2. Systems C and D specify a non-functioning autostart group name, NONE.
  3. System A autostarts a z/OSMF server. System B uses the autostarted server on System A.
  4. Systems C and D do not use an autostarted z/OSMF.

Scenario 4: The z/OSMF server is not autostarted on any system

In this scenario, no z/OSMF servers are started automatically during system IPL. That is, the autostart capability is disabled. Perhaps, you prefer to start the server manually, with the START operator command, as done in previous releases.

To disable the autostarting of z/OSMF servers in a sysplex, do the following for each system in the sysplex:
  • To prevent a z/OS system from autostarting the z/OSMF server, ensure that the system uses a IZUPRMxx member that specifies AUTOSTART(CONNECT). This setting causes the system to connect to the autostart group that is specified on the AUTOSTART_GROUP statement, rather than autostarting its own server.
  • To prevent a z/OS system from connecting to an autostart group, specify the name of a group on the AUTOSTART_GROUP parameter that is not used by any autostart server in the sysplex. For example, AUTOSTART_GROUP('NONE').
  • Similarly, for each system for which you want to disable z/OSMF autostart, ensure that the AUTOSTART(CONNECT) and AUTOSTART_GROUP('NONE') settings are in effect.
  • In your IZU= specifications, verify that the IZU= parameter identifies the suffixes of the IZUPRMxx members that contain the desired settings.

These actions must be taken if you want to disable the autostarting of z/OSMF servers. Otherwise, the default behavior for each system is to attempt to start the z/OSMF server automatically during IPL.

Figure 4. Scenario 4: No z/OSMF servers are started automatically.
Scenario 4: No z/OSMF servers are started automatically during system IPL.
In Figure 4:
  1. Each system uses the following values for autostart: 
    AUTOSTART(CONNECT)
AUTOSTART_GROUP(NONE)

    With these values set for all systems, no system attempts to autostart an z/OSMF server.

  2. Systems A, B, C, and D complete the IPL process. No z/OSMF servers are autostarted in the sysplex.
  • The JES2 Email Delivery Services (EDS) function in z/OS V2R3 requires a z/OSMF server to be active in an AUTOSTART group that JES2 can access. Specifically, the z/OSMF server must be started with SERVER='AUTOSTART' in the IZUSVR1 started procedure, and JES2 must be running on a system that is included in the AUTOSTART_GROUP specification. Otherwise, if this setup is not done, JES2 cannot send e-mail messages to users who submit jobs.

    The z/OSMF server does not necessarily have to be on the same system on which the JES2 EDS is used. However, you do need to ensure that the system from which you are using JES2 EDS is part of an z/OSMF AUTOSTART_GROUP in which there is an active server in that group. If so, JES2 automatically detects the presence of the z/OSMF server; you do not need to identify the location of the z/OSMF server to JES2.

    For information about configuring JES2 EDS, see the topic JES2 Email Delivery Services in z/OS JES2 Initialization and Tuning Guide.

  • You can start the z/OSMF server manually on any system by using the START operator command with the name of the z/OSMF started procedure. By default, the procedure is IZUSVR1. For more information, see Stopping and starting z/OSMF manually.
  • Changing an AUTOSTART_GROUP name requires an IPL. You cannot change this option with a stop and restart of the z/OSMF server.
  • The z/OSMF autostart capability does not automatically restart a terminated server. If an autostarted server fails, you can resume z/OSMF operations by manually starting the server.
  • Authorized programs can use the event notification facility (ENF) to determine whether the z/OSMF server is up or down. For more information, see Detecting whether the z/OSMF server is available.

Steps to enable or disable the autostart capability

The autostart capability requires that common event adapter (CEA) be configured on your system. For information, see Ensure that common event adapter (CEA) is configured and active.

Plan your use of the autostart capability, based on the preceding scenarios.
  • If you want to use the autostart capability, refer to Scenario 1: One z/OSMF server is autostarted for the entire sysplex, Scenario 2: Multiple z/OSMF servers and autostart groups per sysplex, and Scenario 3: Some systems belong to an autostart group, and other systems do not to plan your z/OSMF environment. Then, do the following:
    1. Customize your parmlib IZUPRMxx to fit the scenario that you select. Add the IZUPRMxx member to your system's parmlib concatenation.
    2. Specify the suffix IZU=xx for IZUPRM in your IEASYSxx parmlib member.
    3. Review the job IZUASSEC in SYS1.SAMPLIB and run it to set up security for the AUTOSTART function.
    4. If your installation uses an external security manager other than RACF, ask your security administrator to create equivalent commands for your environment.
  • If you do not want to use the autostart capability, refer to Scenario 4 to plan your z/OSMF environment. Then, do the following:
    1. Customize your IZUPRMxx parmlib member to fit Scenario 4. Add the IZUPRMxx member to your system's parmlib concatenation.
    2. Specify the suffix IZU=xx for IZUPRM in your IEASYSxx parmlib member.
    3. Do not run job IZUASSEC.