Filtering Messages
pared to "AS USE". This is not a match. Because "FORCED" is not matched
and is not preceded by the not-symbol, this RTABLE entry and message do not
match.
Here are routing table entries that do match this message: $LOGOFF$.030$FORCED would match because arbitrary characters would be skipped before comparison
for "FORCED" and $LOGOFF$.030/.FORCED would match because the first non blank string after "LOGOFF" is not "FORCED" .
This is the simplest application of the programmable operator facility. Entries can
be placed in the routing table to filter informational messages. The messages are
filtered because no action routine is specified in the routing table entries. For
example, when the programmable operator facility is running in the system opera­
tor's virtual machine, informational messages resulting from commands such as, LOGON, LOGOFF, and DISeONN, can be prevented from being displayed at the
logical operator's console. Although the messages are not displayed at the opera­
tor's console, they can be logged in the current day's log file. The routing table
entries must identify the text(s) in the message that makes it unique and identify
the columns between which the text(s) should be found in the message. With sin­
gle or multiple texts, TEXTSYM characters should be selected accordingly.
Figure 54 shows an example of how entries may be placed in the routing table to
filter unwanted responses directed to the logical operator. For example, using
Figure 54 below as the routing table, the message 12:04:50 GRAF 055 LOGON AS USER1 would match the second routing table entry (/ ...,AUTO$LOGON). This RTABLE
specification means that, starting in column 9 (SeOL) of the message, "AUTO" cannot be the first non-blank string and that "LOGON" must appear somewhere
in the message. The message would be filtered out but logged in the current day's
log file.
However, the message 12:04:28 AUTO LOGON *** USER BY AUTOLOG1 would not match the second routing table entry (/ ...,AUTO$LOGON) because "AUTO" is the first non-blank string in the message appearing in the columns
between the SCOL and ECOL fields. Thus, the message would not be filtered out
and would be routed to the logical operator, as specified in the last entry in
Figure 54.
The Programmable Operator Facility 435

* THIS IS THE DEFINITION OF THE PROP CONFIGURATION. * LOGICAL OPERATOR IS NICKNAME "LOP". SEE "OPERATOR NAMES" FILE. LGLOPR LOP * THE TEXT SEPARATOR CHARACTERS.
TEXTSYM / $ -, * WHICH NODES TO CHECK, AND AT WHAT INTERVAL. PROPCHK 5 1 NODE2A NODE2B PROPCHK 2 1 NODE1A NODE1B * THE ROUTING ENTRIES START ROUTE *------------------------
*T
*E
*X
*T
*------------------------ S C
o
L
E
C
o
L
--------
T U Y S P E
E R
--------
-------- -------- --------
N A P 0 C A
D T R
E N M
-------- -------- --------
* FILTER OUT LOGON AND LOGOFF MESSAGES SO OPERATOR NEEDN'T SEE THEM
*------------------------ $OUTPUT/OF /-,AUTO$LOGON $LOGOFF $DSCONNECT $RECONNECT
$DIAL $DROP *------------------------
19 36 3
9 33 3
19 34 3
19 36 3
19 36 3
19 32 3
19 32 3
* SEND REMAINING ASYNCHRONOUS CP MESSAGES TO LOGICAL OPERATOR *------------------------ ---
3 DMSPOS LGLOPR Figure 54. Example of Entries to Filter Responses to Routine Commands
Controlling Authorization
In Figure 54, the entries that appear in the "TEXT" field (OUTPUT OF, LOGON, etc.) are the texts contained in the messages that are to be trapped by the pro­
grammable operator facility when they are issued by CPo No userids and nodeids are specified for these entries because they are issued by CPo Because no action routine is specified, the only action taken is the logging of
the messages in the current day's log file.
Looking at the last line in Figure 54, you can see that if a type-3 IUCV message is
received that does not have a corresponding entry in the routing table, action rou­
tine DMSPOS together with the LGLOPR parameter routes the message to the log­
ical operator. In this case, this entry has to be placed after the specific text entries
that you want filtered from the message stream. If this entry appeared before the
text entries in Figure 54, all type-3 IUCV messages would be routed to the logical
operator.
The routing table determines who is authorized to issue specific commands in the
programmable operator facility. Programmable operator authorization is based
entirely on the contents of the routing table. Therefore, controlling authorization is
a relatively simple procedure. Authorization checking is done using either the
userid, nodeid, the command text, or any combination thereof. This means that a
change to any of these entries can result in a change in authorization. This allows
an installation to easily tailor the authorization structure to their particular needs
because only the entries in the routing table need to be changed, and not the action
routines.
When a userid and nodeid are not specified for a routing table entry, all users are
authorized to match that entry and to use the function that it describes. Figure 55
436 VM/SP System Programmer's Guide