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.