Google
 

Trailing-Edge - PDP-10 Archives - BB-JF18A-BM - documentation/ms-mx.bwr
There are 4 other files named ms-mx.bwr in the archive. Click here to see a list.


                        TOPS-20 DECmail/MS V11

                              BEWARE File

                               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
   TRANSFERRED.

   THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT  NOTICE
   AND  SHOULD  NOT  BE  CONSTRUED  AS A COMMITMENT BY DIGITAL EQUIPMENT
   CORPORATION.

   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
   tapes.

   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).
                           @GET MS
                           @DEP IB+IB.FLG IP.STP
                           @SAVE MS

         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
   MAIL-11 protocol.



   3.1  MMAILR/DMAILR/VMAILR

   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
   and DMAILR.

   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
   in MS.MAC.



   3.2  ARMAIL

   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


   3.3  MAIL/RDMAIL/MAILER

   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
   MX.



   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
   monitor:
   $GET SYSTEM:MONITR
   $START 140
   DDT
   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

   $SAVE SYSTEM:MONITR
   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