\ The Logical Operator I How it Works
Flow of Operation
Occasionally the programmable operator must send messages to another virtual
machine. To ensure that the programmable operator will function properly, a user
(a virtual machine other than the programmable operator virtual machine on the
local system or in a distributed system) is identified to the programmable operator
to receive these messages. This user is called the logical operator, as opposed to the CP system ·operator. When the programmable operator is started (in the CP sys­
tem operator virtual machine, for example), the logical operator virtual machine
receives an initiation message. The logical operator also receives error messages
for severe errors, such as logging errors, and receives all messages routed to the log­
ical operator explicitly or by default.
The programmable operator facility runs in a CMS virtual machine. Although it
can run in any virtual machine, because of its programmed capability to log, handle,
or redirect messages, it is most commonly run in the CP system operator's virtual
machine.
The programmable operator facility compares all messages directed to it against
entries listed in a routing table (a CMS file). When a match occurs, the prescribed
action is performed. Any messages that require a real operator's response or action
are sent on to the defined operator (system, network, etc.) at another virtual
machine console, a "logical" operator's console. If the logical operator's virtual
machine is in the same system, the programmable operator sends the messages with
either the CP MESSAGE or CP MSGNOH command. If the logical operator's vir­
tual machine is in a different system (network node), a host system for example, it
sends the messages via RSCS Networking.
Consider this example:
The SYSOPR macro in DMKSYS specifies the userid OPERI for the CP system
operator. Set up the programmable operator to run in the OPERI virtual machine
and establish another virtual machine with userid OPERX. In the routing table
file(s), specify OPERX as the logical operator. Now any CP or user messages sent
to the system operator virtual machine can be handled or filtered by the program­
mable operator or routed to userid OPERX. When the programmable operator facility is running in a virtual machine, CP inter­
cepts all messages intended for that virtual machine console. CP then passes these
messages to the programmable operator facility via IUCV. The messages are
logged in a CMS file. The programmable operator facility then uses the active rout­
ing table to analyze the message and determine if further action is needed. Based
on the contents of the routing table (such as message texts, message types, and user
authorizations), the message can be passed to some specified action routine for fur­
ther action. If the message is to be routed to the logical operator, and that person
is on another virtual machine in the same physical machine, the programmable
operator facility routes the message directly to the logical operator via the CP MSGNOH command or the CP MESSAGE command depending on the classifica­
tion of the programmable operator virtual machine. If the logical operator is on a
different physical machine, the programmable operator facility prefaces the mes­
sage with the appropriate tag information and sends the message to RSCS Net­
working via the CP SMSG command.
The Programmable Operator Facility 423

Relationship to RSCS Networking
Routing Table Information
Initialization
The programmable operator facility usually operates in a disconnected virtual
machine. If someone logs on to this disconnected virtual machine with the pro­
grammable operator facility running, no messages are displayed (unless the pro­
grammable operator facility is running in DEBUG mode). All messages are being
intercepted or received by the programmable operator program from IUCV. If that
person should enter a command, the programmable operator facility gets control
and reads the command entered. Only two commands are accepted from this envi­
ronment; the STOP command and the SET command. The programmable operator
facility rejects any other commands.
If a CMS abend occurs while the programmable operator facility is executing, all
files are closed and abend error messages are sent to the logical operator. A dump
of the virtual machine storage is taken using the CP VMDUMP command and the
last system or device that was IPLed is re-IPLed. If the abend occurs while an
action routine is executing, abend error messages are sent to the logical operator
and the requester (if any). Control is returned to the point in the programmable
operator facility immediately following the action routine call.
When the programmable operator facility is running in a network environment, it
is a normal user of RSCS Networking. This means that the programmable operator
facility communicates to RSCS via the CP SMSG command. Any configuration of
systems and networks that are supported by RSCS Networking can use the pro­
grammable operator facility. The time needed for a message to go from the system
at a distributed site to the logical operator at the host system, or vice versa,
depends on the number and type of communications links between the message
sources and destinations.
A programmable operator can check on its ability to communicate with a host or
distributed system. See "Communications Checking" later in this section.
The programmable operator routing table identifies the programmable operator
facility environment, including the logical operator's virtual machine id and nodeid.
It also specifies the action to take for each message, and authorizes certain users to
invoke specific programmable operator commands. For a complete description of
the information contained in a routing table, see "The Routing Table" later in this
section.
The routing table is a separate CMS file that must be tailored for a specific use.
The first routing table to be used is specified when the programmable operator
facility is invoked. If no routing table name is specified, the default filename "PROP" is used.
The installation may define mUltiple routing tables to cover varying situations. For
example, multiple routing tables can be defined to cover shift changes. Only one
routing table can be active at a time. The active routing table may be replaced by
issuing the LOADTBL command. Any person authorized in the active routing
table may issue this command.
The programmable operator facility is initiated by IPLing a CM:S virtual machine of
at least 512K in size and invoking the programmable operator facility. When the
programmable operator facility gets control, it locates the specified or default rout-
424 VM/SP System Programmer's Guide