Controlled starting of objects during IPL with IPLLEVEL

TOM allows you to specify objects that you want TOM to start in stages or levels after a system is IPL'd. This allows you to have a combination of using TOM to start up levels of objects while you perform additional tasks between the levels.

You can use the IPLLEVEL feature when you need to perform maintenance or other tasks after the basic objects are active but you need to pause before starting all the objects. For example you might want to start one level of objects, then verify the availability of certain systems during startup or verify that files have the correct values set, and then proceed to start another level of objects. It can also be useful for controlling the shutdown of objects to a specific level for performing maintenance without shutting down the entire system.

To create levels of objects, you must specify IPLL=Y on the EXEC PARM statement of the TOM start procedure and specify a level (or multiple levels) with the IPLORDER parameter in BBPARM member MAMINIxx. Then, to associate the objects to the levels, specify a level in an object's definition with the IPLLEVEL attribute. When the IPL has completed and the TOM PAS completes initialization, TOM automatically starts the objects that have the IPLLEVEL attribute value matching the first (or possibly only) level listed with the IPLORDER parameter.

Note

You do not need to define an IPLLEVEL value for the objects in the last level to be started.

After TOM starts the first level of objects, you can perform maintenance or other tasks. If you have defined additional levels of objects, you can start the next level by issuing the START IPLLEVEL command from the console or writing a TOMEXEC with the START IPLLEVEL command and scheduling the EXEC. When TOM completes starting the second level of objects, you can continue to perform any additional maintenance or tasks before starting the next level. To start each additional level you must issue the START IPLLEVEL command from the console or an EXEC.

Once TOM has started all of the levels, a final START IPLLEVEL command starts the remaining objects that do not have an IPLLEVEL attribute value defined (this is the last level of objects that TOM starts). If you create only one level of objects, you must still issue the START IPLLEVEL command or schedule a TOMEXEC for TOM to start the remaining objects.

TOM also provides a STOP IPLLEVEL command that allows you to stop the objects at the current level (except the first or lowest level, where you must use the SHUTSYS command).

Note

Any object TOM starts in levels must be eligible for starting; in other words, the object's schedule definition and dependencies definitions are satisfied, and object control not in SUSPEND state.

To disable the IPLLEVEL feature, specify IPLL=N on the EXEC PARM statement of the start procedure. This causes TOM to start all of the objects as though there are no values specified with the IPLORDER parameter in BBPARM member MAMINIxx.

You can enable or disable the use of IPLLEVEL with the ACTIVATE IPLLEVEL and SUSPEND IPLLEVEL commands from the operator console or from the TOMEXEC API. These actions are also available from the TSYS view.

Example

The following is an example of how levels specified with the IPLORDER parameter and the IPLLEVEL object attribute affects how TOM starts levels of objects.

In this example, IPLORDER=(MINIMAL,DATABASE,ONLINE) is specified in BBPARM member MAMINIxx. The Definition Base that TOM activates when the TOM PAS starts has the following objects defined with their IPLLEVEL object attribute values:

IPLLEVEL attribute value

Object name

MINIMAL

JES2

MINIMAL

TSO

MINIMAL

TCPIP

DATABASE

DB2MSTR

DATABASE

IMS1

DATABASE

CICS1

ONLINE

FILESRVR

ONLINE

MSGGATE

ONLINE

PAYROLL

(no defined value)

MESSAGES

Note

Note that the MESSAGES object does not have an IPLLEVEL attribute value defined.

After the TOM PAS has started with IPLL=Y specified, when the dependency requirements are met for these objects, TOM automatically starts JES2, TSO, and TCPIP which have the MINIMAL IPL attribute value defined because MINIMAL is the first value specified on the IPLORDER parameter.

The following is an example of the messages TOM might issue to the operator console and the logger after IPL:

MAMOD2293I There are 3 levels defined in IPLORDER
MAMOD2211I There are 3 objects defined with IPLLEVEL MINIMAL
MAMOD2290I 1 of 3 objects are eligible for Start at IPLLEVEL MINIMAL
MAMOD2213I Start initiated for 1 eligible objects with IPLLEVEL MINIMAL
MAMOD2290I 2 of 3 objects are eligible for Start at IPLLEVEL MINIMAL
MAMOD2213I Start initiated for 1 eligible objects with IPLLEVEL MINIMAL
MAMOD2290I 3 of 3 objects are eligible for Start at IPLLEVEL MINIMAL
MAMOD2213I Start initiated for 1 eligible objects with IPLLEVEL MINIMAL

When all objects are in ACTIVE status, TOM issues the following message:

MAMOD2214I Start of IPLLEVEL MINIMAL has completed

At this point, TOM has initiated a start for all of the objects in the level named in the message. When you are ready, you can start more objects with the START IPLLEVEL command.

TOM continues to start the objects whose dependencies are met and have an IPLLEVEL of DATABASE defined (DB2MSTR, IMS1, and CICS1 objects).

Issue another START IPLLEVELcommand and TOM starts the third level of objects with an IPLLEVEL of ONLINE defined (FILESRVR, MSGGATE, and PAYROLL).

Lastly, to start the remaining objects that have no IPLLEVEL attribute defined such as MESSAGES, issue the START IPLLEVEL command.

The following lists the additional actions that you can perform and their consequences:

  • Issue a START IPLLEVEL command without waiting for the current level to complete; TOM stacks the commands and completes the tasks in order as previous levels complete.

  • Issue a STOP IPLLEVEL command while TOM is starting a level of objects and all current and pending START IPLLEVEL commands are canceled.

  • Issue a START IPLLEVEL command while TOM is stopping a level of objects and all current and pending STOP IPLLEVEL commands are canceled.

    TOM issues messages that indicate which levels were canceled to the operator console and the TOM logger.

Important messages for IPLLEVEL processing

You can get information about any message by issuing the MSG primary command in the TOM UI (for example: MSG MAMOD2214). The command displays the reason for the message, any action that the system will take when the message has been issued, and any actions that you might have to take.

One important message involved with IPLLEVEL processing is the MAMOD2214I message:

MAMOD2214I <start|stop> of IPLLEVEL <level> has completed

This message indicates that TOM has either

  • Successfully started a level of objects and the objects in that level have a status of ACTIVE, COMPLETE, LOCKED, BLOCKED, WAIT-START, or FAILURE-xxxx.

  • Successfully stopped a level of objects and the objects in that level have a status of STOPPED, COMPLETE, LOCKED, BLOCKED, WAIT-START, or FAILURE-xxx.

The following messages are issued if one or more objects are not in the desired status after completion of a level:

MAMOD2291I <nnnn> objects not status <active|stopped> after <start|stop> IPLLEVEL <level>:
MAMOD2292I <status>  <object-name>     one for each of nnnn objects

These messages indicate that an unexpected event has occurred during the starting or stopping of a level. To find out more about what might have occurred, issue the MSG command to see the reason for the message and what actions you might be able to take.

For objects that do not have an IPLLEVEL attribute defined, these messages contain the word IPLLEVEL followed by <null>. In the example above, you would issue the START IPLLEVEL command to request TOM to start the last object, MESSAGES, and when MESSAGES has started, TOM issues the following message:

MAMOD2214I Start of IPLLEVEL <null> has completed

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Comments