COMMUNICATING WITH OPERATORS AND OTHER USERS There are several commands and programs which can be used for communicating with the operators and other users: MOUNT, SEND, TELL and MESSAGE. The use of each is described in this document along with examples. Some general guidance is given on choosing the most appropriate means of communication. The commands, MOUNT and SEND, are fully described in the DECsystem-10 Operating System Commands Manual. In addition the network mail command POST is described. This issue of this document supersedes that of Mar 80 which should be discarded. 1. GENERAL 1.1 Introduction It is useful and often necessary to facilitate smooth working on the DECsystem-10 to be able to communicate with the operators and other users through the machine itself. There are several ways of doing this which are summarised briefly in Section 1.2 below. 1.2 How to choose the appropriate command The primary factors in choosing a command are purpose of message, immediacy of reply required and length of message. Table 1.2 summarises the possibilities: Message Command Short one-line messages, SEND Brief messages to operators SEND CTY: not requiring a reply. Mail to other users; TELL lengthy messages,
Page 2 Communicating with User TELL SERVICE#BOX Support, Systems Staff or Installation Secretary. Requests for operators MOUNT to mount magnetic tapes or private disc packs. Mail to users on other network POST machines. Table 1.2 Summary of the machine communications methods 2. THE MOUNT COMMAND 2.1 Function The MOUNT command is used to request the operator to assign a device for use with a magnetic tape or private disc pack for the execution of user-specified tasks for the duration of those tasks only. 2.2 General Format The MOUNT command has the following format: MOUNT dev:logical-name/switch1/switch2/.. For use with magnetic tape: - dev MTA: for 9 track magnetic tapes - logical-name (optional) may be any SIXBIT name. - switches must include REELID:name giving the name by which the tape will be dentified when the MOUNTrequest is actioned by the operator, and may include the switch WENABL which permits writing during the user's job (this will be necessary if a tape is to be written). 2.3 Example .MOUNT MTA:TAPE1/REELID:5088MR/WENABL would result in the tape with the label 5088MR being mounted on tape drive, write enabled and with the logical name TAPE1.
Page 3 3. THE SEND COMMAND 3.1 Function The SEND command is used for brief one-way communications to the operators or to another logged-in user whose terminal number is known. 3.2 General format The SEND command has the following format: SEND dev:<text> where: dev is the number of the terminal with which the user wishes to communicate and has the general form TTYn: (or just n) where n is the number of the terminal. Default is to OPR:, the 'operator' of the node to which the user is connected. As some nodes are unmanned, SEND messages can go unheeded. To ensure that any message intended for the ERCC Operations Staff reaches its intended destination, the device CTY: should be specified. <text> is the text which the user wishes to transmit. This text may occupy only the remainder of the command line. If a message is to be sent to anyone other than the Operations Staff, that person's PPN must be known and the SYSTAT command should be used to ascertain that that person is logged-in and to determine their terminal number, before they can be sent any messages. 3.3 Example .SEND TTY62: YOU HAVE THE SYSTEM STAND-ALONE Would send the message to the user logged in at TTY62, and: .SEND CTY: I NEED PRIVATE PACK DSKZ IN APPROX 30 MIN would send the message to the operator's console at ERCC. 4. THE TELL AND MESSAGE COMMANDS 4.1 Function
Page 4 The TELL command is used to send messages to other users; the MESSAGE command is used to receive messages that have been sent to you and may also be used to forward messages to other users. Most usage of TELL and MESSAGE can be demonstrated by the following examples: To send a message to another user any of the following forms will work: .TELL <name> ;<name> is user's name .TELL [p,pn] ;ppn in square brackets .TELL p,pn ;ppn with no square brackets or .TELL ppn ;ppn as 12 digit octal number TELL will respond with the message: Enter message, end with ^Z and will prompt you to enter the message by throwing to the next line. After you have typed the message (as many lines as you want) and have typed the ^Z, TELL will respond with: OK, I told <name>. If, when you log in, there are any messages for you, you will be so informed. To receive your messages, just type: .MESSAGE After the message has been typed, you will be questioned as to the disposal of the message record. The options are discussed in detail in section 4.3. The following paragraphs describe more command options, multiple TELLs, group names, setting default values in initialisation files (or SWITCH.INI files, see 4.5), specifying dates when sending messages, etc. 4.2 The TELL Command The general format of a TELL command is: .TELL/switches user-list (date/time spec) message where: - User-list is a list of names separated by "+" and "-". A "+" specifies that the name following is to be added to the list of users to whom this message is
Page 5 sent; a "-" specifies that the name following is to be deleted from the list of users receiving the message. Names may be abbreviated, so long as they are unique. If they are not, TELL will enter a dialogue, typing out each possible name and asking you if it is the correct one. Names are user names (actually the name given to the account when the account was set up) or one of the following: The string "ME" means yourself. A group name (see GROUP switch in 4.4 below). A project programmer number (brackets are optional). Wild cards, ie: "*" and "?" are legal, but not all users may be allowed to TELL with certain wild card constructions. A system wide mail name as described for POST in section 5.7 below. Some examples: .TELL [120,126]+NEWSLETTER+000120000127 sends the message to to ppns [120,126] and [120,127] and to user NEWSLETTER. .TELL 1,*-DEWOLF sends the message to everyone who has a project 1 account except for DEWOLF. .TELL ME sends the message to yourself (you get it the next time you ask for messages). - (Date-time spec) must be enclosed within parentheses and is the date/time be ore which the message is not to be delivered. The date specification may be a standard date (ie: 15 JUNE 1980) or a mnemonic day of the week (MONDAY) or a keyword (WEEK). The time specification may be in hours in minutes (12:30) or mnemonic (NOON). The date specifications recognized are the following: (1) MM DD YY (2) DD MON YY (3) MON DD YY, where DD is the day number, MM is the month number, YY is the year number and MON is the month name (first three letters only are required although the full month
Page 6 name may be used if desired). Missing numbers are filled in from today's date, except in the case of a mnemonic month with no day following, when the first of the month is assumed. Mnemonic dates are a weekday (SUNDAY, MONDAY, etc), TODAY, TOMORROW, WEEK, MONTH and YEAR. Weekdays are always in the future; if today is Saturday and the mnemonic date SATURDAY is specified, then the message will be delivered in a week's time. "WEEK" specifies the next week (weeks start on a SUNDAY). "MONTH" specifies next month (which of course starts on the first). "YEAR" specifies next year (starting 1 January). The following are considered redundant or 'noise' words: NEXT, AFTER, AT, SINCE. Time specifications are in the form HH:MM, on a 24 hour clock. Mnemonic times are available: BREAKFAST (8:00 AM), LUNCH (12:00), NOON (12:00), TEA (4:00 PM), DINNER (8:00 PM), and MIDNIGHT. Examples: .TELL ME (AFTER LUNCH TOMORROW) will deliver the message after 12:00 tomorrow. .TELL FORTUNE (NEXT WEEK) will deliver the message the first time Fortune asks for messages after next Sunday. .TELL ME (13) will deliver on or after the 13th of the month, all mesages left for you up to the time you first log-in on (or after) the 13th of the month. .TELL ME (16 JUNE 80) will deliver the message the first time the user logs-in on or after June 16 1980. The message can be of any length and is terminated by ^Z. The message text may be in a pre-edited file. To use this feature, type: .TELL namelist (date)".
Page 7 When TELL prompts by throwing a line, respond by typing @file-spec where file-spec is a standard file specification. You can put the file-spec on the same line as the TELL command itself. However, if TELL is forced into a dialogue peculiar things will happen. The switches applicable to the TELL command are: CC if set, a message sent to more than one user will have line with: CC:<list of people receiving message> appended to the end. If more than ten people get the message, the line: [Distribution to more than ten users] will be shown at the end. This is the default setting. NOCC turns off the action of CC, ie: no trailer line is appended. SMART indicates that the user is familiar with the intricacies of TELL commands and need not be prompted with lengthy messages. 4.3 TELL SERVICE#BOX The PPN SERVICE#BOX is used by all Installation staff as a message reception area and: .TELL SERVICE#BOX is the desirable machine-based method of communicating with the Installation staff without the need to specify an individual. SERVICE#BOX is inspected at 1000 and 1500 hrs daily (Mon-Fri) by the Installation Secretary and the messages in it routed to an appropriate member of staff. SERVICE#BOX is intended for all routine requests for service, supplies & documentation; queries and complaints. It should not be used for lengthy discussions of programming problems. Suitable means of communicating with Installation staff in these circumstances are described in 2B01 -
Page 8 Installation Services (1). Note that the # in the string SERVICE#BOX is required, because a space will be treated as a delimiting character between names. The more helpful the information which can be given, the easier it will be for the Installation staff to give a helpful reply. Such extremes as either saying "the machine is giving the wrong answers" or sending a 1000 line assembler language program which will not run are not likely to get speedy or helpful responses. Because the Operations Staff are not exclusively concerned with the DECsystem-10, their direct responsibilities to DECsystem-10 users are necessarily restricted (See reference (1) Section 2.2), and users should in this context find that MOUNT and TELL CTY: (see Sections 2 and 3 above) will cover most needs for communicating with the Operations Staff. Requests for services which require non-immediate operator action such as requests to restore accidentally deleted files should be made via TELL SERVICE#BOX. 4.4 The MESSAGE Command The general format of a MESSAGE command is: .MESSAGE /Switches The switches are described below. The MESSAGE command will type out all messages which have been sent to the user and have delivery dates and times less than or equal to the current date and time. The action of the MESSAGE command depends on the value of the QUERY switch (default value is AFTER). If QUERY:AFTER is set, MESSAGE will type each message, followed by "Dispose:" and wait for a command. If QUERY:BEFORE is set, MESSAGE will type the header of the message and the number of lines in the message followed by the header of the message and the number of lines in the message followed by the prompt "Action:". The commands for responding to either the Action: query or the Dispose: query are: HELP type a brief help message listing some of the options TYPE type the message. If the message has already
Page 9 been typed, it will be typed again. SAVE save the message (will be printed the next time MESSAGE is typed). HOLD puts the message on 'hold'. It will not be printed again until the user explicitly requests that it be printed by specifying the HOLD switch, ie entering the monitor command: .MESSAGE/HOLD The user will be told that he has messages in hold when he types MESSAGE without the HOLD switch. the only way to delete a message in HOLD is to type DELETE in response to the Dispose: query. REPLY This command is used to reply to the sender of the message. It enters TELL and asks for the text of the message. If you want to send your reply to users other than the sender of the message, you can add the names following the REPLY command (using the "+" and "-" constructions of the TELL command), eg: Dispose: REPLY FINKE+DEWOLF sends the message you type to the sender of the message you have just received and to FINKE and DEWOLF. You cannot reply to a message you have sent to yourself, and you cannot add your name to the list of people to whom the reply is directed. FORWARD forwards the message to other users specified by you (as in a TELL command) after the FORWARD command. The line: [Forwarded from <your name>] will be appended to the end of the message. You cannot forward mail to yourself. COPY copies this message to a file. The file specificationcan be specified after the COPY command, eg: Dispose: COPY BUG.FIX copies the message into the file BUG.FIX. Another useful switch which may be employed with MESSAGE is
Page 10 UNREAD, eg .MESSAGE/UNREAD this will display only unread messages. 4.5 Use of TELL and MESSAGE with initialisation (SWITCH.INI) files TELL switches that affect MESSAGE (all of these may appear in SWITCH.INI) are: QUERY determines whether or not the user is queried when typing messages. The possible values are BEFORE, AFTER, NEVER, and BOTH. If QUERY:AFTER is set, the message will be typed and the user will be queried about what is to be done with the message. If QUERY:BEFORE is set, the header message and the number of lines in the message will be typed, and the user queried about what is to be done with the message. If QUERY:BOTH is set, the user will be queried both before and after the message is typed. If QUERY:NEVER is set, the user will not be queried. In this case the disposition of the messages depends on the DISPOSE switch (defaults to SAVE). DISPOSE sets the default value for response to a "Dispose:" request printed by MESSAGE. It is used if carriage return is typed or if QUERY:AFTER is not in effect. The acceptable values are the same as the responses to "Dispose:"; however the only useful ones are DELETE, SAVE and HOLD. HOLD if this is set, messages on hold instead of normal messages will be printed. The default value for this switch is off. SAVE is the same as DISPOSE:SAVE. If specified, all messages typed will be saved. GROUP This switch may appear only in SWITCH.INI. This switch allows you to define "group names". For example, if you find that you are sending messages to the same group of people frequently, you could define a group name for that list. Then rather than explicitly specifying the list of recipients in the TELL command, you can just specify the group name. Group names are defined by enclosing the group name, an "=", and a list of the people in the group, in parentheses following a GROUP switch.
Page 11 For example: TELL /GROUP:(PROJECT=345,*-ME)/GROUP:(STEVE=[1,752]) defines two groups. The first is called PROJECT, which includes all users with project number 345 except for yourself. The second group defines STEVE to be one user. Group names may be nested to any reasonable level (but may not be recursively defined). The TELL at the beginning of this line in SWITCH.INI specifies that this line is applicable to the TELL program and should not be looked at by any other program reading SWITCH.INI (such as DIRECT). The switch MAIL affects messages and may appear in SWITCH.INI files or with the LOGIN program to control the options pertaining to the user's mail. The formats for the MAIL switch are: MAIL:IGNORE will tell LOGIN to ignore any mail that has been directed to you and thus not inform you that it exists. The advantage is that no lookup will be done and LOGIN will be slightly faster. MAIL:INFORM (Default) directs LOGIN to inform you if you have any mail, but the mail itself is not printed (until you type MESSAGE). MAIL:PRINT will start printing your messages at the terminal as soon as you have logged in. MAIL:BRIEF is similar to MAIL:INFORM except that it will not inform you of messages on hold. MAIL:NAMES is a recent development which includes the feature of MAIL:INFORM but also lists up to 3 senders of messages. For example, "You have a message from Smith, Dewolf, Edwards and others."
Page 12 4.6 Example Since the greatest benefit of the various switches is realized by including them in SWITCH.INI,some examples are given. LOGIN/MAIL:NAMES TELL/GROUP:(BILL=ROUSE)/GROUP:(OPRS=7,*-THRONEBURG) TELL/QUERY:BOTH/DISPOSE:SAVE/SMART TELL/GROUP:(STAFF=11,*-EDWARDS+DEW+PAUL) 5. THE POST COMMAND 5.1 Introduction The POST system is a network mail system which conforms to the Joint Network Team's Mail Protocol Standard for the academic community (3). This is in turn based on the ARPA mail standard RFC-733 transmitted over FTP (2). It interfaces to the TELL system on the DECsystem-10. POST is run by entering the monitor command: .POST <mailbox> or .POST (in the second case, the user will be prompted for the <mailbox> specification). where <mailbox> specifies the destination machine and user to whom the message is addressed, and may be either: <name>%<relay> @ <host> or a locally defined alias which translates to a specification as above (see section 5.5 below) The <name> is the name by which the intended recipient of the mail is known to the destination machine (see section 5.2 below), and <host> is the name of that machine. The <relay> is the name of an intermediate switching machine which may be required to transmit the message on to its ultimate destination, (see section 5.3 below). Some examples of POST commands are given in section 5.7 below,sections 5.2 to 5.6 describe the working of the POST command in detail.
Page 13 5.2 Usernames Most machines have two different forms of identification for users: - A mailbox name which is either a person's name or a descriptive identifier which has been registered with the mail system at the destination site, eg: A.Brown, Arthur.Brown, Liaison It is this identification which is meant by <name> in the description of the POST facility which follows. - A user identifier or number, or process name which is in the identifier used by the machines' operating system, eg: [123,456], NSUM06, ERCC44 It is this identification which corresponds with <ppn>, <userid> or <process> in the description of POST which follows. Either one or both of these identifiers may be used by a mail system (although the first is preferable) and both are often printed in the From: field of the message header. A typical message would look as follows: From Mail-System[1,2] on July 7, 1982 at 12:33 PM Via: ykxa ; Wednesday, 7-Jul-82 12:33:36-BST Date: Wednesday, 7-Jul-82 12:32:46-BST From: account name <a.user@ykxa> To: a.n.other at edxa Subject: mail example -------- The message text -------- For DECsystem-10 destinations, the user identifier should be the unique mailbox name, if the user has registered one with that system. If not, then a ppn (with or without square brackets and comma) or the account name associated with each ppn will do, that is, as if one were doing a TELL on the destination machine (see section 4.2 above). Note that account names must be unambiguous, as no questions can be relayed back from remote machines by TELL, and that hash characters (#) should be used in place of spaces in the name. DECsystem-10 users can register the mailbox name by which they wish to be known for inclusion in a local database, by sending a message to the user support staff, specifying the
Page 14 mailbox name required and the ppn with which it is to be associated. The form of the name is recommended to be the user's initial(s) and surname separated by dots. The name may be up to 25 characters long but must be unique within the first 12, eg: A.Brown, A.D.Brown, Arthur.Brown are all valid names. 5.3 Hosts and Relays The host name should be the unique name by which that host is known to the DECsystem-10, for example SERCnet host names are of 4 characters, 2 for the site, 1 for the machine type and 1 for an identifier. eg: RLGB (GEC B at the Rutherford-Appleton Laboratory (RAL) ). Where the mail needs to be forwarded by a mail relay before it reaches its destination, these relays are delimited by percent characters (%) in the username, for example, to POST to a user at CMU-10A on the ARPAnet, the command: .POST <name>%CMU-10A@UCL would be entered. At each relay, addressing information relevant only to that relay is stripped off the address information, that is at UCL in the above example. In the case of messages to the USA, UCL itself relays the mail through a system called ISID in California and mail from the USA should also be relayed through that system. When sending mail via a relay, an attempt is made by the POST program to generate a return address to be used by the mail recipient and the sender is given the opportunity to inspect and alter it. In the example of mail To: name%CMU-10A@UCL, POST would prompt: Reply-To: myname%EDXA%UCL-CS@ISID - is that correct? Type new address or <cr>: For incoming mail, each relay adds a header line to the message containing the name of the host from which the mail has been received which indicates to the recipient which relays the message has been transmitted through. For example, a reply from a user on CMU-10A would have its initial header lines looking like: via:CMU-10A ;Friday, February 12 1982 05:29:02-PST via:ISID ;13 Feb 82 = 12:17-GMT via:UCL ; Saturday, 13-Feb-82 12:20:04-GMT 5.4 The Message Text
Page 15 The POST program will next prompt for a message subject, ie: SUBJECT: ;user types the subject here It will then prompt for the message text which can be typed in directly, or may be copied from a file by typing: @<filename> Messages are terminated with a ^Z. Once the message has been inserted, it is passed to FTP for transmission to the destination machine. 5.5 Locally Defined Names or Aliases It is possible to use locally defined names or aliases to define the <mailbox>. If only a username is given to POST, it will interrogate the SWITCH.INI file in the users area and search for lines of the form: POST/<alias1>=<mailbox1>,<alias2>=<mailbox2>,..... where <alias> is some user defined name for the recipients address, eg: POST/FRED=SGEN @ RLGB, JANE=[100,100]@EDXA would define FRED to be user SGEN on the RAL GEC machine B, and JANE to be user [100,100] on the DECsystem-10 at Edinburgh. Thus, commonly used destinations can be abbreviated. Spaces in the username field are significant and multiple spaces are reduced to a single space. Matching of names is done in a case independant manner. Some more examples are given in section 5.7 below. 5.6 Incoming Mail Users on other machines wishing to transmit mail to the DECsystem-10 should use the mail system implemented on their home machine and should consult the appropriate local documentation for details of how to do this. Messages from users on other network machines will be entered into the ERCC TELL system via the FTP system and a special area on the DECsystem-10 filestore. Users will be notified that they have a message from MAIL-SYSTEM at login time if the MAIL/NAMES option is set on their SWITCH.INI file. Note that because of the way TELL and FTP interface with one another to provide the POST facility, it is not possible to
Page 16 provide an equivalent of the TELL "REPLY" and "FORWARD" facilites to send messages to network users, and POST must be used explicitly for all network mail. 5.7 Examples 5.7.1 POST to ANF-10 users. The only other host on the local ANF-10 network capable of supporting users is the DECsystem-10 at Dundee University. A POST command directing a message to a user there would look like: .POST <name> @ DUNDEE or .POST <ppn> @ DUNDEE where <name> is the name of the user to whom the message is directed and <ppn> is the ppn associated with a name and may be used instead of the name, eg: .POST A.USER @ DUNDEE Alternatively, if the user had in his or her SWITCH.INI file on the DECsystem-10, a line of the form: POST/ALBERT=A.USER@DUNDEE the command: .POST ALBERT would have the same effect. 5.7.2 POST to RCONET users If the user concerned is registered as an RCONET mail recipient, the command may be entered in the form: .POST <name> @ RCO where <name> is the RCONET mail process name for the user concerned and will enable POST to direct mail to the correct user and machine. If the user concerned is not a registered RCONET mail user, a command of the form: .POST <process>%<host> @ RCO should be entered, where <process> is the user number and <host> is the name of the destination machine, eg: .POST ERCA02%2972 @ RCO
Page 17 would direct the message concerned to user ERCA02 on the RCONET ICL 2972. Thus, in the example above, if ERCA02 was a process on the RCONET ICL 2972 and the name associated with that process was A.User, the two commands are equivalent. Again aliases in SWITCH.INI files may be used, for the examples given above, a SWITCH.INI entry might be: POST/AL=A.USER@RCO or POST/ALBERT=ERCA02%2972@RCO Remember though that in practice only one of these alternatives would be used. 5.7.3 POST to SERCnet users POST to registered mail users on SERCnet machines is sent with a command of the form: .POST <name> @ <host> where <name> is the user's name on the destination machine, and <host> is the name of the destination machine, eg: .POST A.USER @ HWGA If the user is not a registered mail user or the name is not known, a POST command of the form: .POST <userid> @ <host> may be used, where <userid> is the user number on the host machine concerned, eg: .POST PMAN @ HWGA Aliases of the form: POST/ALARIC=A.USER@HWGA or POST/AL=PMAN@HWGA may be included in SWITCH.INI files allowing commands of the form: .POST ALAN to be used. 5.7.4 POST to ARPANET users POST to ARPANET users is used as the vehicle for the
Page 18 step-by-step description of the POST command in sections 5.1 to 5.6 above but is described again here for completeness. POST to registered mail users on an ARPA-net host is sent with a command of the form: .POST <name>%<relay> @ <host> or .POST <userid>%<relay> @ <host> where <name>, <relay>, <userid> and <host> have the meanings already defined, eg: .POST E.V.E.RYMAN%CMU-10 @ UCL Again, aliases may be defined locally in a SWITCH.INI file, eg: POST/ERIC=E.V.E.RYMAN%CMU-10@UCL 6. REFERENCES (1) 2B01 - Installation Services (2) 3A55B - FTP - Transferring Files Across the Network (3) Bennet. C.J., JNT Mail Protocol, Jan 82.