🚀 go-pugleaf

Thanks to Hunter Goatley and Carl Lydick, both of whom correctly suggested
that I had a problem with the definition of FLQ_DIR which was causing me to
encounter the following error whenever I tried to SEND using MX 3.1:

>MAIL> send
>To:     mx%"user@site.edu"                 ! dummy user and site, of course
>%RMS-F-DEV, error in device name or inappropriate device type for operation

It turns out that I had defined FLQ_DIR in a nonstandard way which was
perfectly legal as far as VMS is concerned, but unacceptable to MX; thus
DCL commands like $ DIR FLQ_DIR worked normally, leaving me with the false
impression that everything was set up properly.  (I set up the faulty
definition of FLQ_DIR some weeks back, and I'm afraid I can't remember why
I was using a nonstandard definition; it was probably just part of a trial-
and-error process.)

Now I have a new question:  my SMTP process is dying on me as soon as I try
to SEND.  The appropriate *.HDR_INFO, *.MSG_TEXT, *.SRC_INFO and *.SMTP_INFO
files are being created in the (now correctly-defined) FLQ_DIR directory,
but they all end up stranded there because SMTP has died.  The VMS accounting
utility tells me that SMTP is dying with status code 1000043C,

%SYSTEM-F-OPCDEC, opcode reserved to DIGITAL fault at PC=!XL

Does this ring a bell with anyone?  A bug in MX 3.1 (i.e., "Try 3.1C, dummy!),
or am I still doing something wrong?

(A review of my MX environment:  7-node Vaxcluster, all nodes running VMS 5.5
 and CMU-TEK 6.6-5.  MX 2.0 currently running successfully on all nodes with
 the exception of occasional failures to deliver, particularly to CERN in
 Europe (addresses ending in .CH).  ROUTER, LOCAL and MLF run on 3 of the
 7 nodes; SMTP runs on these 3 plus 1 other node, and all 7 nodes run
 SMTP Server.)

- Patrick Walsh
  University of Virginia Department of Physics
  pw@virginia.bitnet, pw@virginia.edu, pat@gomez.phys.virginia.edu