Name Value
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
  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 
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
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. 

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
        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.
DATE ENTERED 1990-01-18 14:10:00