I DMSPOL - Load a routing table
The Log File
Notes:
1. Using the CMS TELL facility requires the user to have a SYSTEM NETID file
set up.
2. DMSPOS must not be invoked if the logical operator virtual machine is the
same as the programmable operator virtual machine. Also, a parameter should
not be specified that directs the message to the programmable operator virtual
machine.
If the LGLOPR routine tries to send a message to the the logical operator, but for
some reason the logical operator's network node is unavailable, LGLOPR detects
this condition and stop any further attempts to send that message. The unsent
message, although logged in the current day's log file, is not displayed at the logical
operator's console.
This routine dynamically loads the routing table indicated by the programmable
operator LOADTBL command. The routing table name must be "filename RTABLE", where "filename" can be any name that conforms to CMS file naming
conventions. Although the routing table name specified with the LOADTBL com­
mand takes precedence, it is also possible to specify in a routing table the filename
of the table to be loaded as a parameter to the action routine. (This can be used as
a default.) Therefore, any message selected by the system programmer can cause a
new RTABLE to be loaded. Also, the programmer can change the LOADTBL default of "PROP" to whatever is desired without changing the LOADTBL action
routine.
Note: With the loading of the routing table done by a separate action routine, it is
possible for the other routines, DMSPOR and and any user-written rou­
tines, to be replaced when a LOADTBL occurs. 'T'bs permits changes to action
routines other than DMSPOL to be made dynamically without stopping the pro­
grammable operator.
Every incoming message that the programmable operator facility receives from CP
or other virtual machines is put into a CMS disk file referred to as the log file if LOGGING is not OFF. All error messages and command responses generated by
the programmable operator facility are also put in the log file if LOGGING is set to
ALL. Each message is identified by the date and time received. The userid and
nodeid appear only if the text was sent via a CP MSG, SMSG, WNG or sent using SCIF (Single Console Image Facility). Log entries generated and logged by the
programmable operator have a userid of PROP. The log file has the following for­
mat:
col 1 col 10 col 19 I I I V V V
yy/mm/dd hh:mm:ss[userid
col 28 I V
nodeid] :
col 39 I V
text
The log file contains variable length records. The maximum record length that the
programmable operator facility can place in the log file is 132 characters. Because
the prefix uses 38 of the 132 characters, the text can be only 94 characters long.
Therefore if the text of a message exceeds the maximum length of 94 characters
the overflow is continued on the next record. This continued record has the same
prefix as the preceding record, with no colon preceding the text.
The Programmable Operator Facility 441

Ensuring a Complete Log
A separate log file is started for each day. The name of the file is:
LGyymmdd nodeid AS
where:
yy
mm
dd
nodeid
is the current year
is the current month
is the current day
is the current RSCS nodeid of the system on which the programmable
operator facility is running.
When the programmable operator facility is started, stopped or the debug mode is
changed, a record is written to the log file. The messages written to the file have
the normal log prefix and a text corresponding to the changed function. Generally,
responses to the programmable operator console commands are written to the log
file when LOGGING is set to ON or ALL. It is also possible to have responses
from the programmable operator commands written to the log file. See the LOG­ GING statement of the routing table or the programmable operator SET command
for more information. Note that when LOGGING is set to ALL, the log file may
be used as an alternative to spooling the virtual console. When node-checking is in
effect, by having PROPCHK or HOSTCHK statements in the RTABLE, if a node
changes status from UP to DOWN or vice versa, a message is also written to the
log file.
If a virtual machine resource limit is reached, such as "disk-full", it may not be pos­
sible to write another record to the programmable operator facility log file. If this
happens, a user-written EXEC is invoked to perform whatever recovery action the
user thinks is desirable or necessary. The user EXEC must have the filename of PROPLGER. See "LOG Error Exit" later in this section.
Any user authorized in the active routing table can obtain the log file as a reader
spool file by using the programmable operator GET LOG command. Messages can
be placed in the log file by authorized users by using the programmable operator LOG command with no other action being taken. (See the VM / SP Operator's
Guide for information on the programmable operator facility commands.)
An old log file can be purged by any user authorized in the active routing table to
use the programmable operator CMD command by issuing the CMS ERASE com­
mand.
When the programmable operator facility routes a message to the logical operator,
the message contains the userid of the sender. The operator, in responding to the
message, may choose to send a message directly to the user without going through
the programmable operator facility. However, if this is done, the message is not
logged in the log file. To ensure that these messages are logged, the operator
should send the message to the user through the programmable operator facility by
using the programmable operator facility CMD command. See the "Programmable Operator Pacility Commands" section of the VAI/ SP Opeiatoi's Guide for informa­
tion on the programmable operator facility commands.
442 VM/SP System Programmer's Guide