home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / bit / listserv / pmdfl / 2566 < prev    next >
Encoding:
Text File  |  1993-01-02  |  6.2 KB  |  124 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!SIGURD.INNOSOFT.COM!NED
  3. Errors-to: epmdf@YMIR.BITNET
  4. X-Envelope-to: PMDF-L@IRLEARN.BITNET
  5. X-VMS-To: IN%"bob@camb.com"
  6. X-VMS-Cc: IPMDF
  7. MIME-version: 1.0
  8. Content-type: TEXT/PLAIN; CHARSET=US-ASCII
  9. Content-transfer-encoding: 7BIT
  10. Message-ID: <01GT0O7RR57690OARS@YMIR.CLAREMONT.EDU>
  11. Date:         Sat, 2 Jan 93 05:37:42 GMT
  12. Sender:       PMDF Distribution List <PMDF-L@IRLEARN.BITNET>
  13. From:         Ned Freed <NED@SIGURD.INNOSOFT.COM>
  14. Subject:      RE: Options for dealing with Mail-11 delivery errors
  15. Newsgroups: bit.listserv.pmdf-l
  16. Lines: 106
  17.  
  18. >  This is a followup to my previous posting regarding problems with
  19. > deliveries to the local channel failing due to one of the various
  20. > problems with VMSmail and/or the Mail-11 protocol.
  21.  
  22. > We have the following situation.  We used to have a set of large
  23. > mailing list (some with several hundred entries).  These used to be
  24. > normal VMSmail distribution lists.  We've changed them to be PMDF
  25. > lists.  We're having an unanticipated problem which may cause us to
  26. > revert back, something I'd prefer not to do.
  27.  
  28. > There have always been occasional problems with these lists. However,
  29. > the impact has changed since the changeover.
  30.  
  31. > Once, one list member on another node forwarded his mail to his
  32. > secretary, who was on some of the same lists.  This caused mail to
  33. > hang when sending to the list.  There have been other problems,
  34. > probably not all caused by exactly the same situations.
  35.  
  36. > The following is my analysis/guess at our current situation.  When a
  37. > problem like the above occured before, the sender would be using MAIL
  38. > interactively, MAIL would hang, and the user would eventually ^C.  At
  39. > that point he/she would figure that the mail had been actually sent,
  40. > possibly noticing his/her own delivery had arrived, and would just go
  41. > on about his/her business.
  42.  
  43. Bob, if you seriously think this is even close to a satisfactory situation,
  44. there's not much we'll be able to do for you. My perspective this is an
  45. absolutely and totally unacceptable state of affairs. The user is left in a
  46. situation where they have no idea whether or not their mail was actually
  47. delivered to any given recipient. Many users won't even realize this is a
  48. problem. Perceptions aside, when this occurs the message will fail to be
  49. delivered to half of the recipients on the average.
  50.  
  51. Even worse, you, the system manager, the only person who can correct this, have
  52. absolutely no knowledge that there's something wrong.
  53.  
  54. Now, if by some miracle you manage to get notified that there's a problem you
  55. now have to track down the problem address. You have to do this with no log
  56. information whatsoever. I wish you luck -- I've used PMDF more than once solely
  57. as a means of tracking down the specifics of such a problem with VMS MAIL
  58. address lists.
  59.  
  60. Net net, by returning to your original setup you achieve a state where the
  61. problem will occur more often (since it is all entirely VMS MAIL based), users
  62. are directly involved in handling the problem but have no way of coping with
  63. it, you have no way of getting notified that there is a problem, and you have
  64. no tools of any kind to assist you in tracking down and correcting the problem
  65. once you do find out about it. This would be a truly wretched state of affairs.
  66.  
  67. > Now, when the same situation occurs, the PMDF batch job is running
  68. > mail/protocol=in_mailshr and it hangs.  Either
  69.  
  70. >     (1) PMDF recognizes the problem and aborts the delivery, or
  71. >    (2) the job hangs forever.
  72. > [I'm not sure how often the first occurs.  I've seen the second.]
  73.  
  74. > Following the second scenario, eventually I notice the hung batch job
  75. > and abort it.  If I forget to rename the problem queue entry, the
  76. > situation repeats, and each time the message is delivered to the list.
  77. > So people get multiple copies of the message.  I suspect that the
  78. > first case is happening also based on the number of cases of people
  79. > reporting receiving many copies of the same message.
  80.  
  81. You're taking the wrong action. When this happens and you notice it happening
  82. you should take steps to correct the underlying cause of the problem, rather
  83. than renaming the files and hoping the problem will go away. These problems
  84. usually don't just fade away and to hope that they will is quite shortsighted.
  85. The PMDF log files will usually tell you everything you need to know to quickly
  86. identify the problem address and fix it.
  87.  
  88. When PMDF recognizes problems like this one it requeues the message without the
  89. recipients it managed to deliver the message to. Result: No duplicates.  In
  90. addition, it puts the problem address last on the list so the next time
  91. delivery is attempted the message won't hang until the last address. Result:
  92. All possible deliveries are done, leaving only the bad addresses in the queue.
  93.  
  94. > My first question:  Is my guess correct that PMDF will time out in
  95. > certain cases (I think this is what you [Ned] posted in response to my
  96. > first question) and treat the delivery as a `temporary failure',
  97. > requeuing it for later?
  98.  
  99. The only reason PMDF can fail to time out is if VMS MAIL hangs either at AST
  100. level or in an elevated mode. And as I have indicated previously, I don't know
  101. of much of anything we can do about this.
  102.  
  103. > My second question:  If that's the case, would it make sense for PMDF
  104. > to provide an option for treating this case differently?  At our site
  105. > we'd prefer to get Postmaster involvement ASAP in cases like this,
  106. > rather than waiting for user complaints about multiple deliveries.
  107.  
  108. Nope. If PMDF is able to detect these problems it is almost always able to work
  109. around them completely.
  110.  
  111. > And my third question:  Short of convincing the other VMS systems to
  112. > run PMDF, are there any suggestions as to how we can deal with this,
  113. > short of going back to VMSmail distibution lists?
  114.  
  115. As I previously indicated, going back to VMS MAIL mailing list seems to me to
  116. have all the elements of being the worst possible choice you can make. There
  117. are nothing but big problems associated with the all-VMS MAIL solution.
  118.  
  119. The all-PMDF solution remains the solution of choice. Failing that, proper
  120. corrective action when you find a problem is the preferred way of dealing with
  121. this situation.
  122.  
  123.                                 Ned
  124.