I upgraded my z/OS from ADCD Z24A to ADCD Z24C. This has updates to lots of the software, including z/OSMF. This includes some performance fixes, so z/OSMF start up is much quicker and uses much less CPU. However the newer level of ADCD Z24C now starts z/OSMF automatically. It took a few attempts to stop this.
When z/OS starts, it takes configuration parameters from IEASYSxx. You can see which IEASYSxx you are using with the DISPLAY IPLINFO operator command. You can see which IZU parameter you are using with
d iplinfo,izu
IEE255I SYSTEM PARAMETER ‘IZU’: AS
With the DISPLAY PARMLIB command, you get the parmlib concatenation
D PARMLIB IEE251I 08.34.02 PARMLIB DISPLAY PARMLIB DATA SETS SPECIFIED AT IPL ENTRY FLAGS VOLUME DATA SET 1 S C4CFG1 USER.Z24C.PARMLIB 2 S C4CFG1 FEU.Z24C.PARMLIB 3 S C4SYS1 ADCD.Z24C.PARMLIB 4 S C4RES1 SYS1.PARMLIB
Where the ‘S’ means it came from a LOADxx parameter. A ‘D’ means Default SYS1.PARMLIB.
Look in each data set in turn for the IZUPRMxx member (xx=AS in my case).
Contents of the IZUPRMxx member
Within the member is SERVER_PROC(‘IZUSVR1’) This tells the IPL code which server to start.
Within the member is line with AUTOSTART(…). The value can be
- CONNECT – I think of this as AUTOSTART(NO)
- LOCAL – I think of this as AUTOSTART(MAYBE)
See here for a discussion.
It is a bit more complex than YES|NO. It has capability to allow one of a group of z/OSMF servers to start.
If you have AUTOSTART(CONNECT) specify AUTOSTART_GROUP(NONE).
If you have AUTOSTART(LOCAL) and AUTOSTART_GROUP(COLIN) for more than one IZU servers. Then at IPL it checks to see if a Z/OSM server with AUTOSTART(LOCAL) and AUTOSTART_GROUP(COLIN) is already active. If so – the instance does not start.
The documentation says it checks by having an ENQ on the file system with the AUTOSTART_GROUP value. This implies you need the z/OSMF data directories to be on the same ZFS file system.
Should I use autostart?
This is a tough question. I cannot test it because I only have one LPAR, but I have some thoughts.
Single LPAR, single Z/OSMF instance
This is relatively easy. You can start z/OSMF automatically though commands at IPL, or you can use the z/OSMF IZUPRMxx method, or start it manually.
Multiple LPARs in a sysplex, single Z/OSMF instance.
If you have a shared file system, you can start the z/OSMF instance on any LPAR. If you start the instance more than once, it detects this and will only allow one instance to be active.
You have to plan to be able to starting an instance on different systems. For example the IP address and port for the base system will be different. You’ll need to set up a TCP/IP environment to support this. See HA Liberty web server – introduction to using VIPA to provide high availability connectivity and the z/OSMF documentation
Multiple LPARs in a sysplex, multiple z/OSMF instances.
This is where the autostart may be useful. The first LPAR to be started will start the z/OSMF instance. When other LPARs start, they detect that another z/OSMF in the group is active, and will not start the z/OSMF instance. As with starting a single z/OSMF instance in a multi LPAR environment, you need to plan the connectivity. See HA Liberty web server – introduction to using VIPA to provide high availability connectivity and the z/OSMF documentation.
I struggle to see why starting just one instance is useful. For availability I would want more than once instances to be running at the same time. With only one instance. If you stop it, and restart on a different LPAR, you have a period of a minute or more where you do not have z/OSMF running.
I would have a group_token, so each instance can register the “group name” is active. An application can then ask to be notified when a member of the group becomes active, using standard z/OS services.
Stateless z/OSMF instances
If you are using z/OSMF facilities which save state, the autostart of just one server will not work. For example if you are using any workflow facilities, state is saved in the file system. You need to logon to the same instance to be able to continue working on the workflow. If today you run on LPARA’s z/OSMF and tomorrow you run on LPARB’s z/OSMF you cannot do your workflow.
You need to plan your z/OSMF usage and plan to have “stateless” z/OSMF servers which can use AUTOSTART; and workflow servers – for which you have only one instance (which can be moved around) and do not use autostart.
ColinPaice 