home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / vmsnet / mail / pmdf / 2787 next >
Encoding:
Internet Message Format  |  1992-12-21  |  3.2 KB
  1. Path: sparky!uunet!cs.utexas.edu!sdd.hp.com!ux1.cso.uiuc.edu!moe.ksu.ksu.edu!mccall!ipmdf-newsgate!list
  2. Newsgroups: vmsnet.mail.pmdf
  3. Subject: Options for dealing with Mail-11 delivery errors
  4. Message-ID: <01GSKLP8W26S8ZDVVS@camb.com>
  5. From: Bob Tinkelman <bob@camb.com>
  6. Date: 21 Dec 1992 09:22:48 -0400 (EDT)
  7. Organization: Cambridge Computer Associates, Inc.
  8. Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
  9. Resent-Date: 21 Dec 1992 09:22:48 -0400 (EDT)
  10. Resent-From: epmdf@YMIR.CLAREMONT.EDU
  11. Errors-To: epmdf@YMIR.CLAREMONT.EDU
  12. Resent-Message-ID: <01GSKG80F74Y8WW5P0@INNOSOFT.COM>
  13. X-Vms-To: IN%"info-pmdf"
  14. X-Vms-Cc: TINKELMAN
  15. Mime-Version: 1.0
  16. Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  17. Content-Transfer-Encoding: 7BIT
  18. Lines: 51
  19.  
  20. This is a followup to my previous posting regarding problems with
  21. deliveries to the local channel failing due to one of the various
  22. problems with VMSmail and/or the Mail-11 protocol.
  23.  
  24. We have the following situation.  We used to have a set of large
  25. mailing list (some with several hundred entries).  These used to be
  26. normal VMSmail distribution lists.  We've changed them to be PMDF
  27. lists.  We're having an unanticipated problem which may cause us to
  28. revert back, something I'd prefer not to do.
  29.  
  30. There have always been occasional problems with these lists. However,
  31. the impact has changed since the changeover.
  32.  
  33. Once, one list member on another node forwarded his mail to his
  34. secretary, who was on some of the same lists.  This caused mail to
  35. hang when sending to the list.  There have been other problems,
  36. probably not all caused by exactly the same situations.
  37.  
  38. The following is my analysis/guess at our current situation.  When a
  39. problem like the above occured before, the sender would be using MAIL
  40. interactively, MAIL would hang, and the user would eventually ^C.  At
  41. that point he/she would figure that the mail had been actually sent,
  42. possibly noticing his/her own delivery had arrived, and would just go
  43. on about his/her business.
  44.  
  45. Now, when the same situation occurs, the PMDF batch job is running
  46. mail/protocol=in_mailshr and it hangs.  Either
  47.    (1) PMDF recognizes the problem and aborts the delivery, or
  48.    (2) the job hangs forever.
  49. [I'm not sure how often the first occurs.  I've seen the second.]
  50.  
  51. Following the second scenario, eventually I notice the hung batch job
  52. and abort it.  If I forget to rename the problem queue entry, the
  53. situation repeats, and each time the message is delivered to the list.
  54. So people get multiple copies of the message.  I suspect that the
  55. first case is happening also based on the number of cases of people
  56. reporting receiving many copies of the same message.
  57.  
  58. My first question:  Is my guess correct that PMDF will time out in
  59. certain cases (I think this is what you [Ned] posted in response to my
  60. first question) and treat the delivery as a `temporary failure',
  61. requeuing it for later?
  62.  
  63. My second question:  If that's the case, would it make sense for PMDF
  64. to provide an option for treating this case differently?  At our site
  65. we'd prefer to get Postmaster involvement ASAP in cases like this,
  66. rather than waiting for user complaints about multiple deliveries.
  67.  
  68. And my third question:  Short of convincing the other VMS systems to
  69. run PMDF, are there any suggestions as to how we can deal with this,
  70. short of going back to VMSmail distibution lists?
  71.