There are 4 other files named ms-mx.bwr in the archive. Click here to see a list.
TOPS-20 DECmail/MS V11
16 Jul 86
COPYRIGHT (c) DIGITAL EQUIPMENT CORPORATION 1986. ALL RIGHTS RESERVED
THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED
ONLY IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE AND WITH THE
INCLUSION OF THE ABOVE COPYRIGHT NOTICE. THIS SOFTWARE OR ANY OTHER
COPIES THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY
OTHER PERSON. NO TITLE TO AND OWNERSHIP OF THE SOFTWARE IS HEREBY
THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT NOTICE
AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL EQUIPMENT
DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY OF ITS
SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL.
TOPS-20 DECmail/MS V11 BEWARE File -- 16 Jul 86 Page 1
1.0 KNOWN PROBLEMS
At this time, we are aware of a few known problems which we have
not yet solved prior to shipping the DECmail/MS product.
Depending on your use of the product, these problems may or may
not impact your use of MS/MX. Unless otherwise noted, SPRs need
not be sent in on these problems as we have a thorough
understanding of these problems and will be addressing them in
updates of DECmail/MS which will be distributed on Autopatch
PLEASE NOTE: At the end of this beware file is a monitor patch
which should be installed.
o WHAT IS LOCAL MAIL ON CFS CLUSTERS - Systems which are
clustered together present some unique problems for
users when they send and receive mail on different
systems within the cluster. For example, user XXX who
receives mail on system A, and reads it and replies to
all on system B, will receive an additional copy of the
message. This is because MS on system B does not know
that XXX@B is the same user as XXX@A.
o OCCASIONAL MISSING <CR><LF> ON MESSAGE RECEIVED FROM A
VAX - Occasionally, a mail message will be delivered to
the system from a system using the MAIL-11 protocol and
a carriage return and linefeed will be missing. There
will be a corresonding 'Missing EOM ... ' message in
the MX.LOG file.
o MAIL RECEIVED FROM AN UNKNOWN NODE - When MX delivers
mail to a TOPS-20 user from a node for which TOPS-20
does not know the node name, the node number will be
used to identify the node which sent the mail. MS will
be able to read the message, but there is no support in
either MS or MX for sending or replying to that node
until a name has been established for that node.
o MX PROGRAM CRASHES - Occasionally the MX program will
crash. We have fixed most all problems with MX
crashing, however there do exist a few unreproducible
crashes that we have not yet solved. If you experience
MX crashing, PLEASE DO submit an SPR with a copy of the
MX crash dump, MX log file, any text displayed by MX on
the console, and any other pertinent information which
might be useful in helping us solve the problem.
o INFO PROGRAM RESTARTS - If the system program INFO is
restarted, the MX program goes into an internal loop.
MX must be restarted.
TOPS-20 DECmail/MS V11 BEWARE File -- 16 Jul 86 Page 2
2.0 OBTAINING A CRASH DUMP OF MS/MX
If you experience problems with MS or MX crashing, crash dumps
can be obtained, which when sent to us, will assist in
determining the problem.
o Patch MS to make dumps in PS:<SPOOL>. NOTE: This will
work only for privileged users unless the <SPOOL> area
is unprotected for write access. (Unprotecting the
<SPOOL> area should not normally be done).
@DEP IB+IB.FLG IP.STP
o Please read the installation doc file for info about
obtaining dumps of MX.
TOPS-20 DECmail/MS V11 BEWARE File -- 16 Jul 86 Page 3
3.0 INTERACTION WITH OTHER MAIL SYSTEMS
MS/MX will provide message services between TOPS-10, TOPS-20, and
VMS via DECnet links. Communication between TOPS-10/20 systems
is accomplished using SMTP (Simple Mail Transfer Protocol
(Arpanet spec. RFC822)). Communication to VMS systems uses the
Due to the previous lack of standard mail systems, MS-20 has a
limited ability to interface to other non-supported TOPS-20 mail
systems. At this time, MS-20 can coexist with the arpanet mailer
called MMAILR provided that it knows about the POBOX: logical
name. MS-20 will also coexist with the old DECnet mailers VMAILR
To give you control over which mailers MS will interface to, a
flags word exists in MS, called NETFLG. These flags are used to
control MS's behavior with mail that MX rejects due to its
restrictions on mail protocols. Such mail can be requeued by MS,
to be processed by MMAILR, DMAILR or VMAILR as appropriate.
However, not all sites may have or desire such requeueing of
mail. By lighting various RJ.nam bits in NETFLG, this requeueing
can be prevented; instead, a warning message is typed to the
user, explaining that MX has rejected the mail and MS is not
allowed to queue it for other potential servers. Of the various
bits defined, only RJ.AMA (reject ARPA mail) and RJ.VMA (reject
mail to VMAILR or DMAILR) are implemented; the rest are
reserved. Bits 0 through 11 may be used as desired by customers.
When MS is started, the value of RJ.FLG is found in NETFLG. The
default setting is RJ.VMA (reject VMAIL, DMAIL queueing, but
attempt to queue mail for an external ARPA mailer if ARPA mail is
given.) The flags are defined in MSCNFG.MAC, and NETFLG is found
ARMAIL is a utility subroutine package provided on the standard
TOPS-20 distribution tape, which allows a customer to interface a
user program to the mail system. It is currently also used by
GALAXY and DUMPER for sending mail about archival requests.
The ARMAIL.MAC found in the MS source area will communicate to
MX. All previously released versions of ARMAIL communicate only
to the MAILER program. Please recompile your version of GALAXY
and DUMPER, and any user programs which interfaced to MAILER,
using this new version of ARMAIL.
TOPS-20 DECmail/MS V11 BEWARE File -- 16 Jul 86 Page 4
The MAIL, MAILER and RDMAIL programs were the supported programs
for sending, receiving, and reading mail on TOPS-20. These
programs will no longer be supported and are replaced by MS and
4.0 REQUIRED MONITOR PATCH
In cases where mail is received from a node which is not known to
the monitor, i.e., whose name is not in the node and address
table ADRTAB, then MX is unable to inform the recipient where the
mail originated. In such a case, when the MTOPR function .MORHN
is performed it fails with error NSPX24 (Node name not assigned
to a network node). MX, as a result, returns with a null node
name which results in the string <USERNAME@>.
It turns out that the monitor does know the node address of a
node even if it does not know the node's name. Therefore, we
have modified the monitor so that in those cases where the node
name is unknown, the node address is returned in the right half
of the word pointed to by AC3 in the MTOPR .MORHN call. MX will
then reformat the address and report the sender as
<USERNAME@AREA .NODE >.
The following is the DDT patch that must be inserted into the
NTRHST+3/ CALL SCTA2N JRST FFF+2
FFF/ 0 MOVADR: MOVE T3,3
FFF+1/ 0 MOVEM STS,0(3)
FFF+2/ 0 PUSH P,STS
FFF+3/ 0 MOVE STS,T1
FFF+4/ 0 CALL SCTA2N
FFF+5/ 0 JRST FFF+10
FFF+6/ 0 POP P,STS
FFF+7/ 0 JRST NTRHST+5
FFF+10/ 0 XCTU MOVADR
FFF+11/ 0 XCTU MOVADR+1
FFF+12/ 0 POP P,STS
FFF+13/ 0 JRST LSCJSY+66
FFF+14/ 0 FFF:
FFF+1/ 0 ^Z
TOPS-20 DECmail/MS V11 BEWARE File -- 16 Jul 86 Page 5
5.0 UNSUPPORTED COMMANDS
MS contains a few commands which are unsupported and invisible to
the user. These commands have been included only for command
file compatibility with older versions of MS. Use of these
commands is not advised as the results can be indeterminate.
The commands are: ANSWER, BBOARD, ECHO, EMACS, PREVIOUS,
REDISTRIBUTE, SHOW INTERNAL-INFORMATION, SSEND, SUMMARIZE, ZSEND