home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / vmsnet / mail / mx / 1223 next >
Encoding:
Internet Message Format  |  1993-01-05  |  2.3 KB
  1. Path: sparky!uunet!paladin.american.edu!howland.reston.ans.net!usc!news.service.uci.edu!unogate!mvb.saic.com!mx-list
  2. From: pat@che.phys.Virginia.EDU
  3. Newsgroups: vmsnet.mail.mx
  4. Subject: Followup to: "error in device name" message on MX 3.1
  5. Message-ID: <009661af.9535cae0.3642@gomez.phys.virginia.edu>
  6. Date: Mon, 04 Jan 1993 11:55:24 EST
  7. Organization: Mx-List<==>Vmsnet.Mail.Mx Gateway
  8. X-Gateway-Source-Info: Mailing List
  9. Lines: 37
  10.  
  11. Thanks to Hunter Goatley and Carl Lydick, both of whom correctly suggested
  12. that I had a problem with the definition of FLQ_DIR which was causing me to
  13. encounter the following error whenever I tried to SEND using MX 3.1:
  14.  
  15. >MAIL> send
  16. >To:     mx%"user@site.edu"                 ! dummy user and site, of course
  17. >%RMS-F-DEV, error in device name or inappropriate device type for operation
  18.  
  19. It turns out that I had defined FLQ_DIR in a nonstandard way which was
  20. perfectly legal as far as VMS is concerned, but unacceptable to MX; thus
  21. DCL commands like $ DIR FLQ_DIR worked normally, leaving me with the false
  22. impression that everything was set up properly.  (I set up the faulty
  23. definition of FLQ_DIR some weeks back, and I'm afraid I can't remember why
  24. I was using a nonstandard definition; it was probably just part of a trial-
  25. and-error process.)
  26.  
  27. Now I have a new question:  my SMTP process is dying on me as soon as I try
  28. to SEND.  The appropriate *.HDR_INFO, *.MSG_TEXT, *.SRC_INFO and *.SMTP_INFO
  29. files are being created in the (now correctly-defined) FLQ_DIR directory,
  30. but they all end up stranded there because SMTP has died.  The VMS accounting
  31. utility tells me that SMTP is dying with status code 1000043C,
  32.  
  33. %SYSTEM-F-OPCDEC, opcode reserved to DIGITAL fault at PC=!XL
  34.  
  35. Does this ring a bell with anyone?  A bug in MX 3.1 (i.e., "Try 3.1C, dummy!),
  36. or am I still doing something wrong?
  37.  
  38. (A review of my MX environment:  7-node Vaxcluster, all nodes running VMS 5.5
  39.  and CMU-TEK 6.6-5.  MX 2.0 currently running successfully on all nodes with
  40.  the exception of occasional failures to deliver, particularly to CERN in
  41.  Europe (addresses ending in .CH).  ROUTER, LOCAL and MLF run on 3 of the
  42.  7 nodes; SMTP runs on these 3 plus 1 other node, and all 7 nodes run
  43.  SMTP Server.)
  44.  
  45. - Patrick Walsh
  46.   University of Virginia Department of Physics
  47.   pw@virginia.bitnet, pw@virginia.edu, pat@gomez.phys.virginia.edu
  48.