.PAGE SIZE 55, 68
.RIGHT MARGIN 68
.LAYOUT 2, 3
.TITLE Some Hints about Message Router and ALL-IN-1
.SUBTITLE B.#Z.#Lederman
.CENTER
Some Things I Have Learned
.BLANK.CENTER
About Using the Message Router
.BLANK.CENTER
with ALL-IN-1
.BLANK 2.CENTER
Bart Z.#Lederman
.CENTER
ITT World Communications
.CENTER
New York, NY
.PARAGRAPH
Over the past 9 months or so, using the Message Router which is now
supplied with ALL-IN-1, sending in and receiving answers to SPRs,
working with TSC, and experimenting, I've picked up a few bits of
information which may be useful. One (which was previously published
here) was on automatically re-starting the message queues that move
mail between the Message Router (MR) and AI1.
.PARAGRAPH
There are a number of options on when MR can run. The best one for
most users appears to be that the Talker should run when activated
by a message sent to it, and not as a batch job on schedule.
.PARAGRAPH
I had to install MR so many times in the course of getting it to
work that I got fed up editing the data file (mentioned in the
release notes) to hand-apply the patches that DEC should have fixed
before distributing the product. I finally created this EDT command
file which can be used to make the changes with:
.BLANK.NO JUSTIFY.NO FILL
$ EDIT/COMMAND=FIXFILE.EDT MRINITDEF.DAT
.BLANK
(content of FIXFILE.EDT)
.BLANK
s/DEFDEC/DEFAULT__DECNET/wh
s/ENBLOG/ENABLE__LOGGING/wh
s/COMPULSORY__LOG/COMPULSORY__LOGGING/wh
s/LOGGER__BUFFER/INTERNAL__BUFFER__SIZE/wh
s/EXTEND__NO/INTERNAL__BUF__EXTEND__NO/wh
s/FILE__SIZE/FILE__SIZE__IN__BLOCKS/wh
s/KEEP__NO/PURGE__KEEP__NO/wh
exit
.BLANK.JUSTIFY.FILL
.PARAGRAPH
Don't expect the IVP to work. Because the above mandatory patches,
and the changes to account quotas (mentioned below) are not applied
until after installation, the IVP will probably fail. If you want to
take the time to re-install MR after you have made all of the
corrections, and re-use your existing database (so you don't wipe
out the patches), the IVP may eventually run. It's better to just
send some mail messages from AI1 to VMSmail and vice versa after
installing all of the Message Router products. If the mail gets
through it's just as good a check as the IVP: if it doesn't get
through then something is wrong no matter what the IVP says.
.PARAGRAPH
When you invoke VMSINSTAL, it gives you a warning if DECnet is 
running. Many products can be installed while DECnet is up, but it's 
probably better not to install the Message Router while DECnet is 
running.
.PARAGRAPH
When you install a product on a cluster, the product usually goes
into a node-specific account. If you are running a homogeneous
cluster you can put the product on once in a root directory such as
SYS$SYSDEVICE:[MRMANAGER] and avoid duplicating all of the files for
each node (you normally have only one copy of Message Router running
per cluster anyway) and save disk space, etc.
.PARAGRAPH
There are some restrictions on password lengths which are not clear
in the documentation. MR doesn't restrict password lengths, but
due to a limitation within ALL-IN-1, the password on it's mailbox A1
must not exceed 9 characters. The password on the A1 mailbox in MR
must be the same as in the ALL-IN-1 Messaging Manager (MM) menu
under CMP. Similarly, the password on mailbox MRGATE (used to pass
mail between the Message Router and the VMS Mail Gateway MRGATE)
must not exceed 12 characters. I personally did a
SET#PASSWORD/GENERATE=8 on my account to have the system generate
some long "nonsense" passwords for me to use on these mailboxes. (I
copied down the passwords it generated, then rejected them so my
account password didn't change.)
.PARAGRAPH
When MR is installed, the MRMANAGER account may end up with
insufficient quotas for the product to run. For MR V2.0, the
following quotas are recommended, and you may have to modify the
account by hand to get them:
.BLANK.NO JUSTIFY.NO FILL
PRCLM = 60  BIOLM = 50    ASTLM = 60       ENQLM = 400
FILLM = 60  WSDEF = 1024  WSEXTENT = 8192  WSQUO = 2048
PGFLGQUO = 1600
.JUSTIFY.FILL
.PARAGRAPH
The entire subject of running Message Router on a cluster is one
which is not clear in the documentation (at least I didn't think so,
and the answers to my SPRs state that DEC intends to clarify the
documentation in the future). If you are not trying to do anything
fancy, it turns out not to be too difficult. First, use the
MBMANAGER routines (like MB$START.COM and MB$STOP.COM) to start and
stop MR and MRGATE rather than the individual start and stop command
files. If for some reason you must start MR individually then you
may find, as I did, that there is some confusion about the RESTART
qualifier. Basically, the command file should always be invoked as
.BLANK
@SYS$MANAGER:MRSTART.COM#RESTART
.BLANK
The reason for not using it in a cluster is, apparently, to prevent
a node which is being rebooted from starting the Message Router when
it has been deliberately stopped on the other nodes. How you are
supposed to know at boot time during SYSTARTUP that this is the case
DEC doesn't say: apparently, they expect system managers to stand in
front of the console and perform a conversational boot, whereas in
my environment it is necessary for SYSTARTUP to run unattended. As I
said, I find the best way out is to use MB$START.COM, do not use
MRSTART.COM or MRGATEST.COM, and hope for the best.
.PARAGRAPH
The defaults during installation are to put all batch jobs on the
generic queue SYS$BATCH. If you have a cluster, then the jobs will
run on whatever node is handy: this is OK in a homogeneous cluster
with MR on every node, but not in a heterogeneous cluster, or if you
want to run MR on a specific node. MR$:MRINITUTL.COM can be used to
change the queue name, but it doesn't generate a new MRSTART.COM
(which is needed even if you do use MB$START.COM): if you don't take
the defaults during installation you don't get MRTIDY.COM and the MR
accounts fill up with unneeded log files. The solution is to take
the defaults but edit the command files manually. There are no ill
effects from editing MRSTART.COM, MRTIDY.COM, MRTALK__RUN.COM, and
MRTALK__SCH.COM and changing the SUBMIT commands to use a specific
queue.
.PARAGRAPH
I found the two questions asked during MR installation about access
to mailboxes (access from remote systems, and access to SYSTEM
mailboxes) to be a bit misleading. I was concerned about the
implications of allowing remote access to privileged accounts,
something we don't allow on our systems. The answer from DEC is that
the privileges and /SYSTEM qualifier on mailboxes within MR are not
the same as VMS privileges, and answering YES to the SYSTEM mailbox
account does not give access to the VMS SYSTEM account. The reason
for the second question is if AI1 (or other user agents) are not on
the same node as MR but you still want them to be able to send and
receive messages, then remote access must be allowed: you can
conceivably set up a network where many nodes run AI1 or other types
of mail user agents, but only one node runs the Message Router. If
ALL-IN-1 and Message Router run on the same machine, then neither
kind of remote access is needed.
.PARAGRAPH
If you have a definition in your (the system manager's) account that
defines a symbol such as:
.BLANK
DEL*ETE :== DELETE/LOG
.BLANK
or
.BLANK
DEL*ETE :== DELETE/CONFIRM
.BLANK
you will see errors such as
.BLANK
_%DCL__I__IGNQUAL, qualifiers appearing before this item were ignored
.BREAK
#_\SYMBOL_\
.BLANK
in MRTIDY.LOG and during other command procedures (like AUTOGEN).
This is because these procedures use the DELETE/SYMBOL command to
delete internal symbols. It's a good idea not to define a new symbol
for DELETE in the system manager's account.
.PARAGRAPH
MRMAN currently has no good way to save the internal database (the
list of mailboxes, etc.). You should save all of this information
because you will need it for future installations, or in case the
database becomes corrupted. One possibility is to execute a SHOW
command in a batch job or during a SET#HOST#0::/LOG=logfile to
capture the output, something like this:
.BLANK
$ run sys$system:mrman
.BLANK
        This is MRMAN V2.0
.BREAK
MRM> show */add__format
.BREAK
Add "A1" /Owner=ALLIN1 /System /Run="OA$LIB:OAMTIMAIL.COM"
.BREAK
Add "DEFAULT__DECNET" /Owner=MRMANAGER /Network__node
.BLANK
etc. You can replace the "This is" line with
.BLANK
$ RUN SYS$SYSTEM:MRMAN
.BLANK
to turn the listing into a command procedure to rebuild the
mailboxes. NOTE: this will NOT capture the passwords which are
present on the A1 and other mailboxes. You MUST be certain you have
documented these passwords somewhere if you don't want to have to
re-install all of the Message Router products and ALL-IN-1 in order
to set new passwords.
.PARAGRAPH
I found that OAMTIMAIL.LOG and OAMTISEND.LOG (found in the ALLIN1
account) contained a lot of superfluous information because there
are SET#VERIFY commands in the command files which run on the batch
queue to transfer mail between the Message Router and AI1. DEC says
this is deliberate: I find it a useless waste of disk space. If
there are any errors, the messages come out in the log files, and
are much easier to find if there are only the error and
informational messages: therefore I have removed the SET#VERIFY
commands from OA$DATA:OAMTIMAIL.COM and OA$DATA:OAMTISEND.COM. (I
should point out that the default on my system is for all batch jobs
to be SET#NOVERIFY.)