The Feedback File
Whether the message was sent through the programmable operator or not has little
significance to the user. However, so that the messages received by the user always
have the same id (the programmable operator facility id), the message should
always be sent from the logical operator through the programmable operator facili­
ty.
The feedback file is another CMS disk file (named FEEDBACK nodeid AS) that
the programmable operator facility manages. The feedback file, unlike the log file,
is not automatically written by the programmable operator facility. Authorized
users can write time stamped notes and complaints about the operation of the sys­
tem to this feedback file. To write a notice to the feedback file, you, as a user,
must explicitly use the FEEDBACK (or FB) command. An example of such a
message is
M OP FEEDBACK RESPONSE TIME WAS SLOW DURING MORNING SHIFT.
Because the feedback file is normally smaller than the log file, it is easier for the
personnel in charge of the programmable operator facility's maintenance to review
the users' comments and identify when and where particular problems occurred.
Each record in the feedback file is prefixed with the date and time the message .was
logged along with the sender's userid and nodeid. The feedback file has the follow­
ing format:
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 feedback file contains variable length records. The maximum record length
that the programmable operator facility can place in the feedback file is 132 char­
acters. 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.
Any user authorized in the active routing table can obtain the feedback file as a
spool file by using the the programmable operator facility GET FB or GET
FEEDBACK command. (See the VM / SP Operator's Guide for information on the
programmable operator commands.)
An old feedback file can be purged by any user authorized by the active routing
table to use the programmable operator CMD command by issuing the CMS ERASE command.
Installing the Programmable Operator Facility
The VM/SP product contains the file PROPLIB LOADLIB which is the basis for
the programmable operator facility. After receiving and installing VM/SP, take the
following steps before running the programmable operator facility.
1. Reserve enough mini-disk space to contain the log file(s) and feedback file for
the virtual machine that the programmable operator facility will be running in.
The amount of space needed depends on the amount of message traffic that
will be going through the programmable operator facility, and on the number
of comments you expect users to place in the log and feedback files.
The Programmable Operator Facility 443

I Routing Table Conversion
The amount of space needed depends on the amount of message traffic that
will be going through the programmable operator facility, and on the number
of comments you expect users to place in the log and feedback files.
2. The sample routing table is located on the CMS 190 mini-disk. In order to use
the sample PROP RTABLE, take the following steps: ACCESS 190 CiA COPYFILE PROP RTABLE C = = A
This places the sample routing table on a read/write mini-disk accessed by the
virtual machine. Edit the sample routing table (PROP RTABLE) to include
the functions and authorizations to meet the various needs of the installation as
described in the previous section, "The Routing Table". Place the edited file
on a mini-disk accessed by the programmable operator facility virtual machine.
3. Optionally, if you have made any changes to the supplied action routines, link
the TEXT file to the PROPLIB LOADLIB. The CMSGEND EXEC, using the
CMSGEND PROP function, allows user-modified routines to be replaced in
the PROPLIB LOADLIB.
If you have written any additional action routines, use the CMS LKED com­
mand to add these routines to the PROPLIB LOADLIB. Copy the PROPLIB LOADLIB from the CMS system disk to a read/write disk because any
changes would invalidate the directory entry on the system disk. For example,
to link a user-written action routine named ACTIONA to the PROPLIB LOADLIB, you would issue:
LKED ACTIONA (LET LIBE PROPLIB Action routines written in Basic Assembler Language must be put in the PROPLIB LOAD LIB. EXEC action routines need not be put in the PROPLIB LOADLIB, but can reside on any minidisk accessible to the pro­
grammable operator.
The format of the routing table is changed from the initial version of the program­
mable operator facility documented in VM/SP Release 2. The new format makes
the specifications easier and the information clearer. VM/SP Release 2 routing
tables are not compatible with the current format and must either be re-generated
by hand or converted using PROPRTCV. PROPRTCV is a utility provided to
convert old routing tables to the current format. This utility is written using the
System Product Interpreter. Using an old RTABLE as input, PROPRTCV creates
a new RTABLE, leaving the old one unchanged. When you issue the PROPRTCV command, the conversion proceeds as follows:
1. Generates the appropriate configuration statements at the beginning of the
new routing table file. See "Routing Table Entry Formats" earlier in this sec­
tion.
A LGLOPR statement is added using the existing logical operator userid
and nodeid. PROPRTCV prompts you to change this information, if you
wish.
A TEXTSYM statement is added. Select the TEXTSYM characters to be
used. The text fields of the file are scanned for these characters. If any of
444 VM/SP System Programmer's Guide