Automatic Invocation
If you wish, you can set up the programmable operator facility to start running
when the system is IPLed and to restart automatically in the event of CP system
restart. This can be done as follows: Place an "IPL CMS PARM AUTOCR" entry for programmable operator's vir­
tual machine in the CP directory. This can be done even if the programmable
operator virtual machine is the CP system operator. Place the following entry in the PROFILE EXEC of the programmable opera­
tor's virtual machine:
EXEC PROPST rtable-name [DISConn]
You can precede or follow the invocation of the PROPST EXEC by the invo­
cation of any virtual machine commands that you wish to have executed before
or after the programmable operator facility is invoked. Virtual machine com­
mands'that are placed after the invocation of the PROPST EXEC are not exe­
cuted until the programmable operator facility is stopped.
If you want the programmable operator to run in other than the operator's vir­
tual machine, place an AUTOLOG entry for the programmable operator's vir­
tual machine in the PROFILE EXEC of the system operator or the AUTOLOG user.
Once this is complete, if the logical operator is not already logged on, he/she
should do so on the appropriate system.
The following example shows how to place entries in the CP Directory and the PROFILE EXEC of operator's virtual machine. These entries automatically
invoke the programmable operator facility in the operator's virtual machine when
the system is IPLed. The userid of the programmable operator virtual machine is "OPERATOR". The default, "PROP RTABLE", is the name of the routing table
being used. CP directory entries: USER OPERATOR password 512K 1024K ABCDEFG
IPL CMS PARM AUTOCR Entries in the PROFILE EXEC of the Operator's virtual machine:
EXEC PROPST DISCONN
Once these changes (or similar ones) have been made, IPLing the system causes
the programmable operator to be automatically invoked in the disconnected system
operator virtual machine. After the DISCONNECTED message has been written
to the console, indicating that the system operator virtual machine is disconnected,
the operator can log on to whatever virtual machine he/she is normally supposed to
use, for example, the logical operator virtual machine specified in the routing table.
The Programmable Operator Facility 447
I Communications Checking
The programmable operator facility can operate either from the host system or
from a distributed system in a network or from both sides. Special functions can be
performed depending on the ability of the programmable operators to communicate
through RSCS Networking. The purpose of these functions is:
To provide the host operator (logical operator) with timely information and/or
action in the event of a break in communication with the programmable opera­
tor on one of the network's distributed systems. To provide a distributed system with timely information and/or capability for
action in the event of a break in communication with the host system.
A programmable operator can periodically check on the link with another system to
determine whether it is possible to communicate with that system. The systems to
be checked must be identified in the routing table of the programmable operator
doing the checking. This may be either the programmable operator at the host sys­
tem checking on specified distributed systems or a distributed programmable opera­
tor checking on communications with its host system. When the programmable
operator at the host system is checking on the distributed systems, the programma­
ble operator needs another programmable operator running in the system operator
virtual machine on the distributed system. This is not required when a distributed
system is checking on the host system. In other words, for "host checking", no
programmable operator is required at the host system, but for "distributed system checking" programmable operators must be running at the distributed systems.
These various types of checking may be collectively referred to as "node-checking" .
Note that the roles of the 'host' and 'distributed' systems need not be strictly
defined. For example, a programmable operator may use the PROPCHK function
to check communication with any other system (node) running a programmable
operator in it's system operator virtual machine in the network. With the HOSTCHK function, the system being checked is simply the system defined as the
checking system's logical operator, and not necessarily 'the' host system for the
network.
The programmable operator facility that has been instructed to check on its distrib­
uted system(s) periodically attempts to communicate with those systems by sending
a message that causes a response. The programmable operator then waits a speci­
fied time for a response. For checking the host system (HOSTCHK), the
acknowledgement request goes to the RSCS on the logical operator node. For
checking the distributed systems (PROPCHK), it goes to the programmable opera­
tor on the distributed system. No response indicates that something has prevented
communication between the host and the distributed system(s). Getting a response
after being delinquent for a time indicates that communication between the pro­
grammable operators has been restored. With the SET command, the user is able
to set the checking function ON or OFF. Any time that the programmable operator detects that a node has exceeded the
time allowed for responding, that fact is recorded in the programmable operator
log. Also logged is the fact that a node has resumed responding.
448 VM/SP System Programmer's Guide
Previous Page Next Page