| TEXT |
OVERVIEW
code (found in field #20 of the Option file), run the routine
o TYPE (#4) - This field must always contain the code "s" for
Server or the request will be denied and an error will
result.
o ENTRY ACTION (#20) - The MUMPS code that is entered in this
field will be executed if the server request is honored.
If, as with other options, the variable XQUIT exists
after the Entry Action is executed, the request will
be terminated at that point and an error will be
generated.
indicated in the Routine field (#25), and execute any MUMPS code in the
o ROUTINE (#25) - If there is a routine name in this field in
the forms PROGRAM, ^PROGRAM, or ENTRY^PROGRAM the
routine will be run.
o EXIT ACTION (#15) - The MUMPS code stored in this field will
be executed just before the server exits.
o SERVER BULLETIN (#220) - This field is a pointer to the
to the Bulletin file which indicates the bulletin that
Exit Action field (#15). A server-type option is similar to a run routine-
is to be used to notify the local mail group of a
server request on their system. If there is no bulletin
entered in this field the default bulletin XQSERVER will
be used. If the mail group(s) pointed to by XQSERVER
(or the bulletin pointed to in this field) do not
contain an active user (i.e., a user possessing a verify code
and no effective termination date) the software will
turn on auditing (see below) and send a MailMan message
to the local Postmaster.
type option. The difference is that a server option is activated by a mail
o SERVER ACTION (#221) - This 'set of codes' field allows the local
IRM staff to decide how a server request is to be treated. The action
codes are:
R - Run immediately. This will cause the server request to be
honored in real time as soon as it is received from MailMan
provided that it is not prevented by a setting in the Times/
Days Prohibited field.
Q - Queue server. This will cause the server request to be honored
message while a run routine option is activated by a user when being chosen
as soon as permitted by the Times/Days Prohibited field.
N - Notify local authorities. This will cause the server software
to create a TaskMan entry which is not scheduled to run, and
notify the local mail group with the task number so that it may
be approved locally and then scheduled to run using TaskMan's
Requeue Tasks option.
I - Ignore any requests. This code will cause the software to ignore
all requests for this server. A bulletin or MilMan message may
from a menu. The form of the mail message that activates the server may be
still be sent, however.
o SERVER MAIL GROUP (#222) - This field is a pointer to
another mail group (the first is pointed to by
XQSERVER and/or the bulletin in field #220) to
which server notifications are to be sent. The
software will notify all legitimate users in all
mail groups pointed to.
o SERVER AUDIT (#223) - This field will cause the server
identical to any other mail message except that it is adressed to S.<option
request to be audited in File 19.081 (Audit Log
for Options). The default is 'YES'. The information
stored for an audited server includes: Option,
User (always Postmaster), Device, Job #, Date/Time,
CPU, message number, return address of sender,
subject of the message, and error message. A
server can also be audited using the normal option
auditing software. Auditing the Postmaster or
the namespace "XQSRV" will capture all server
requests.
name>. The "S." (like the "G." form for sending to mail groups) routes
o SUPRESS BULLETIN (#224) - This field of codes will, if set
to "Y" (YES) prevent a bulletin from being sent
under normal conditions. If there is an error
or a possible security breach, a bulletin will
still be fired. If the field is not filled in
it takes the default of "N", the sending of
bulletins is not supressed.
o SERVER REPLY (#225) - This set of codes controls the
the message to the server request software.
MailMan reply to a server request. If a reply is requested
the software uses the return address of the sender as
supplied by MailMan to send a local or network reply (see
the standard form below). The possible codes are:
N - No reply is sent (the default).
E - A reply is sent to the return address of the sender only in
the event of an error.
R - A reply is always sent.
CUSTOMIZING A SERVER BULLETIN OR MAILMAN REPLY
==============================================
Servers use bulletins and MailMan messages to communicate with the
local IRM staff when a server request is received, or with the sender of a
server request, usually in the event of an error. These two kinds of
documents look very similar and must contain certain key pieces of data.
It is also possible, however, for the sender or the local IRM staff to
append other information to the bulletin or MailMan message by setting that
========
Can server requests be denied?
information into the array XQSTXT, one line per node. In other words, if
this array exists, for example:
|TAB|XQSTXT(1)="Please append these two lines of text"
|TAB|XQSTXT(47)="to the end of the bulletin XQSERVER."
The information in the array will be appended to the bulletin and/or
Mailman reply message. In the case of bulletins, the subscripts of the
array XQSTXT must be integers greater than zero, for the reply mail any
subscripts will be appended. In this example, the default bulletin,
------------------------------
XQSERVER, would then look like this:
Subj: Server request notice
From: <Postmaster>
-----------------------------------------------------
Dec. 21, 1989 3:08 PM
A request for execution of a server option was received.
Only server-type options can be activated by mail messages. They
Sender: <Child,Your@HOME.DOMAIN.EXT>
Option name: ZZUPDATECL
Subject: UPDATE CHRISTMAS LIST DATA BASE
Message #: 136771
Menu system Action: No error(s) detected by the menu system.
Please append these two lines of text
to the end of the bulletin XQSERVER.
must be given the type "s" in the Type field (#4) of the Option file. If
Select MESSAGE Action: IGNORE (in IN basket)//
Please note that the first 6 data elements will always be 1) date and
time the request was received, 2) the sender, 3) requested option's name,
4) subject of the message requesting a server, 5) the message number, and
6) a brief statement of the menu system's action or an error message. If
a customized bulletin is used instead of XQSERVER these data elements will
still be printed first.
the type is not "s" and a request is received it results in an error which,
by default, is recorded in the Audit Log For Options file. The option name
must be complete and exact when a server request is made or the request
will be denied.
What can servers do?
--------------------
Several other things can happen when a server request is received,
depending upon how the fields in the Option file for that server option
are filled in. A server request might trigger a bulletin, send a MailMan
reply, and/or initiate an audit of itself. The programmer or local IRM
staff may also customize the bulletins or MailMan replies.
What variables monitor server activity?
---------------------------------------
Server options are linked to messages in the Message file, stored in
What is a Server?
^XMB(3.9). These messages may have data in them for the program which is
activated by the server. Along with the data, the server supplies an
'unloader' variable XMREC which, when executed, returns the next line of
data from the message in the variable XMRG. The return code variable,
XMER, which will equal 0 for a successful read, and -1 when the end of the
message has been reached.
SETTING UP A SERVER-TYPE OPTION
===============================
-----------------
A server-type option (henceforth called simply a server) has many
fields in common with other option types, and is set up using the Menu
Management option called 'Edit options'. This option calls the FileMan
edit template XUEDITOPT which will prompt for data to be entered in
the following fields:
o NAME (Field # .01) - This should be a namespaced set of 3 to 30
uppercase letters.
A server is a special type of option, found in the Option file, to
o MENU TEXT (#1) - Since there is never a menu prompt for a server
this field should instead contain an accurate description of
what this server does, as it is used by the server software
in error messages, bulletins, and MailMan replies.
It should be be 3 to 50 characters in length.
o OUT OF ORDER MESSAGE (#2) - If this field contains between 1 and
80 characters of text, the server is placed 'out of order'
and will not be activated by a server request. The message
itself will be included in bulletins or MailMan replies
which mail messages can be addressed. Addressing a mail message to
which report the failure.
o LOCK (#3) - Since servers have no on-line user associated with
them, the existence of a lock in this field will prevent
the execution of a server, much like an out of order
message. The 'user' for all servers is the Postmaster.
The originator of a server request is recorded, however,
in the return address variable.
o DESCRIPTION (#3.5) - This word processing field should contain
a server is termed a 'server request', a request that will awaken the
an extensive description of the server intended for the
local Site Manager and IRM staff. The description should
include an exact description of what the server does and
the resources it requires.
o PRIORITY (#3.8) - This field will determine the priority at
which the server runs.
o TIMES/DAYS PROHIBITED (#3.91) - This multiple allows the local
IRM staff to control the days and times during which the
option given certain conditions and cause it to execute any Entry Action
server request is honored. If data is entered which
prevents the server from being honored immediately the
software will determine the next available time slice
which is not prohibited and queue the request for that
time. Servers which are marked 'R' for Run Immediately
in the 'Server Action' field will instead be queued to
run at the next non-prohibited time period. If there
is no time period when the server is not prohibited, an
error results.
|
