Command processing in an IMSplex

Command routing

Commands that are issued to OM are, by default, routed to all the IMSplex components that are active and have registered interest in processing those commands. If you want to route a command to one or more specific IMS systems in the IMSplex, use the ROUTE() parameter on the command request.

OM selects one IMSplex member (that is, IMS or RM) that is registered for the command to be the command master for each command from the OM API. The command master performs global command actions where applicable. An XRF alternate system is not a command master candidate until it takes over.

Type-2 command responses may differ depending on which IMSplex member was the command master. For example, for a QUERY TRAN NAME(tranname) QCNT (GT 1) SHOW(ALL) command, only the command master returns the global queue counts, unless it does not have access to the shared queues (for example, the command master is local queues enabled).

If a command is routed to multiple IMS systems and the command fails on some of those systems as a result of environmental reasons (such as /DBR to an XRF alternate system), the overall OM return code will not reflect the environmental error.

If a command fails on all systems to which it is routed because of environmental reasons, IRC_LIST and IRSN_LISTNONE are produced. For type-1 commands, any error messages that are associated with the invalid environment errors will also be sent back for display. For type-2 commands, the return and reason code returned by the IMS system are from OM.

Command behavior and the Resource Manager

Depending on whether an IMSplex is defined with a Resource Manager (and there is a resource structure available to RM), command behavior can be affected. When a resource structure is not defined, resource status must be maintained on local IMS systems in the IMSplex. In this case, commands have only a local effect.

If RM is defined with a resource structure and STM is enabled in the IMSplex, RM maintains global resource information, including resource status, for nodes, LTERMS, and users. In this scenario, resource status is maintained both globally and locally. Usually, if a user signs off or a client shuts down, resources status is maintained globally but deleted locally. If you do not want TM resources to be updated in RM, you can specify STM=NO in the PROCLIB member, DFSDCxxx.

As an alternative to STM=NO, users can choose to disable resource sharing for static ISC resources only. If this option is set, the command status for static ISC resources is always considered local as if there were no resource structure. Commands processed for a static ISC node or subpool only modify local status. Status is not updated in the resource structure. The purpose of the option is to remove the unique name restriction for static ISC-related resources so that static ISC LTERM and subpool names can be active multiple times concurrently in an IMSplex.

Another behavior that is worth noting is how command processing clients process type-1 commands (related to nodes, LTERMS, and users) that are routed to the entire IMSplex. In general, OM chooses one of the command processing clients in the IMSplex to be the master to coordinate the processing of the type-1 commands. Whether the master (or a non-master) IMS will process a type-1 command depends on where the command resource status is kept. If the command resource status is kept in a resource structure, the type-1 command will usually be processed by a non-master client where the command resource is active. If the command resource is not active on any of the command processing clients in the IMSplex, OM will still route the type-1 command to all clients in the IMSplex, but only the master client will process the command. If the type-1 command is being routed to all the clients in the IMSplex, command processing clients where the command resource is not active will reject the type-1 command.