JOHNSON@NUHUB (I am only an egg.) (02/09/90)
Hi all. Happy New Year!
I have PMDF v3 plugged into JNET. Mostly it works just fine.
However, when JNET is down for some reason the BIT_LOCAL files get
translated into $BITNET files and just sit there. They can't be sent for
some reason and are never retried as far as I know. I'm looking for a
way to force retry on these files but either just re-doing SEND or by
translating them back to BIT_LOCAL files for retry that way. Any other
method that does the same thing would also help.
Is there something else I've missed in GUIDE.MEM again?
Should I go be suitably embarressed or is this a real problem?
I need something. I'm geting tired of users complaining about lost
BITNET mail.
Chris Johnson
Northeastern University.DAN@TOWSONVX (02/09/90)
Chris Johnson writes: > I have PMDF v3 plugged into JNET. Mostly it works just fine. >However, when JNET is down for some reason the BIT_LOCAL files get >translated into $BITNET files and just sit there. They can't be sent for >some reason and are never retried as far as I know. I'm looking for a >way to force retry on these files but either just re-doing SEND or by >translating them back to BIT_LOCAL files for retry that way. Any other >method that does the same thing would also help. > > Is there something else I've missed in GUIDE.MEM again? >Should I go be suitably embarressed or is this a real problem? > > I need something. I'm geting tired of users complaining about lost >BITNET mail. This is caused when PMDF is running but Jnet is not and the Jnet global pages have been removed. I don't know if this is the best solution but what I normally do is log into the Postmaster account and then mail the files with the following type command: $ mail/noed/nosubj/noself $BITNET$000######.00 "in%""user@node""" PMDF then takes the message and sends it on to the recipient as if nothing had happened. I've never really checked into this thoroughly (though I probably should) but I'm pretty sure that the original sender's name is maintained, as well. Give it try. Good luck. Dan Daniel A. Dinkin Network Services Manager BITNET: dan@towsonvx.bitnet Academic Computing Service Internet: dan@toe.towson.edu Towson State University dan@midget.towson.edu Towson, Maryland 21204 MINCnet: toe::e7opdan (301)830-3320 Any thoughts in this message are purely random and my employer had nothing to do with them... especially if I was right.
NED@HMCVAX.CLAREMONT.EDU (Ned Freed, Postmaster) (02/09/90)
There's a cute, but dangerous, trick you can use to reprocess lost $BITNET
files. Copy the files into the JNET receive queue as JMAILER.TXT files, and
let BN_SLAVE reprocess them as if they were incoming mail.
Important caveats:
(1) This will ONLY work with PMDF 3.1. It won't work with earlier versions.
(2) This trick depends on the X-Envelope-to: line being present in the header.
If you've disabled X-Envelope-to: lines on any of your BITNET channels,
don't use this trick.
(3) I have used this a couple of times, and I've directed one or two other
people to do it. It has worked in the cases I've seen. But it may not
work for you. Try it with a couple of messages before you move 10,000
messages in there.
(4) If you use COPY to move the files, don't forget the /NOCONCAT qualifier!
Now, as for the issue of how to prevent these files from popping up in the
first place.
This is a toughie. The problem is that by the time PMDF knows that JNET cannot
deliver the message, the message has already been "delivered". This is sort
of a design flaw in the SMTP module, which I intend to correct in the future.
I've gotten as far in this as activating the necessary JNET code on the
fly using LIB$FIND_IMAGE_SYMBOL (this eliminates the need to relink for new
releases of JNET). I hope to have the rest of this problem worked out soon.
I don't think it will be patchable, however -- the changes are going to be
pretty major.
Ned