In an IMSplex environment, IMS commands issued through OM can behave differently than when those same commands are issued to an individual IMS subsystem. IMSplex commands can be issued only through the OM API. Classic IMS commands can be issued through the OM API or to individual IMSs through end-user terminals, master terminals, system consoles, or AOI applications. The following sections describe some of the behavioral differences.
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 IMSs 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.
| IMSplex 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).
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 IMSs in the IMSplex. In this case, commands have only a local effect.
If RM is defined with a resource structure in the IMSplex, RM maintains global resource information, including resource status. So, 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 the DISABLE RESOURCE SHARING FOR STATIC ISC 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. For information about |this option, see the Initialization exit routine, DFSINTX0, in the IMS Version 9: Customization Guide.
Another behavior that is worth noting is how command processing clients process classic 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 classic commands. Whether the master (or a non-master) client will process a classic command depends on where the command resource status is kept. If the command resource status is kept in a resource structure, the classic 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 classic command to all clients in the IMSplex, but only the master client will process the command. If the classic command is being routed to all the clients in the IMSplex, command processing clients where the command resource is not active will reject the classic command.