256 IMS Version 8 Implementation Guide
17.1 Introduction to Operations Manager user interface
The interface to all of the new CSL services provided by the new components, SCI, OM, and
RM, are documented in
IMS Version 8:Common Service Layer Guide and Reference,
SC27-1293.
The Operations Manager (OM) (see Operations Manager (OM) on page 164) provides
services to the IMSplex by allowing user supplied Automated Operator Programs (AOPs) to
send commands to CSL components and then consolidating the responses to those
commands before returning them to the AOP. OM can optionally provide command security
using RACF or a user written command authorization exit.
The IMSplex environment will have been established before an AOP can join the IMSplex
meaning all address spaces are started (SCI, OM, RM, and IMS are required). IMS will have
registered with OM for the commands that it can process (includes both classic commands
and the new IMSplex commands). IMS is called the
command processing (CP) client
.
When an AOP is started, it must join the IMSplex by registering with the local SCI address
space. This is done with a CSL (CSLSCREG) macro described in the referenced manual. SCI
may invoke RACF to authorize that AOPs user ID to join the IMsplex. Once the AOP has
registered with SCI, it can begin submitting commands from end-users and receiving
responses from the CP client(s) through OM using other CSL macros. The following are
typical of the steps that an AOP might take.
1. Register with SCI; join the IMSplex as an AOP.
2. Receive a request from an AOP client to submit a command to one or more IMSs in the
IMSplex. This request might be from a directly connected z/OS user (for example, a TSO
user), from an external (network attached) client, or from another system address space
such as Netview.
3. Submit the command to OM using CSL provided macros (CSLOMI or CSLOMCMD).
Included in the request are the command and any routing (which IMSs) and timeout
(WAIT) values.
4. When OM receives the command, it will (optionally) authorize the AOP user ID for the
command. It will then forward the command to the CP client(s) according to the routing
information provided by the AOP. It will wait for a response for a period of time specified on
the input from the AOP.
5. The CP client will execute the command and return the response to OM encapsulated in
XML tags.
6. When OM has all the responses, or the WAIT interval has expired, it will forward the
responses to the AOP, still encapsulated in XML.
7. The AOP would process the response depending on where the command originated.
a. If it came from a locally (z/OS) attached user with a display device, the AOP should
format the response for display, interpreting the XML tags and putting the response in a
format understandable by a person. An example of this type of AOP is the TSO SPOC
provided with IMS Version 8 and described in detail in Single point of control on
page 235.
b. If it came from a network client, then the AOP can simply forward the response, XML
tags and all, to the network client and let that client format the response.
c. A third possibility is a user written automation program running, for example, as a
Netview EXEC, which would in turn invoke a function to register with the local SCI and
issue commands through OM to any or all IMSs in the IMSplex. In this case, the client
is the Netview EXEC and there is no external client to display a response to. The EXEC
merely examines the response to determine whether the command was successful or
not.

Get IMS Version 8 Implementation Guide A Technical Overview of the New Features now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.