Name | Value |
---|---|
NAME | XUDOC SERVERS |
HEADER | SERVERS |
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. |
DATE ENTERED | 1990-01-18 14:10:00 |
AUTHOR | USER,ONE |