Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!psuvax1!psuvm!YMIR!NED From: NED@YMIR (Ned Freed, Postmaster) Newsgroups: bit.listserv.pmdf-l Subject: RE: error getting file parameter Message-ID: Date: 4 Feb 90 11:51:00 GMT Sender: PMDF Distribution List Reply-To: PMDF Distribution List Lines: 38 Approved: NETNEWS@PSUVM Gateway Errors-to: postmast@YMIR.BITNET X-Envelope-to: PMDF-L@IRLEARN.BITNET X-VMS-To: IN%"LSCHULTZ@WOOSTER.BITNET" X-VMS-Cc: IPMDF Comments: Warning -- RSCS tag indicates an origin of POSTMAST@YMIR X-To: LSCHULTZ@WOOSTER, INFO-PMDF@YMIR The simple explanation is that the PMDF-VMS MAIL interface could not read the name of the queued file to process off the command line. Why not? Well, what usually happens is that MAIL fires up PMDF, it reads the file name fine, it tries to open the file and gets an error. This is duly reported to VMS MAIL. But then VMS MAIL calls PMDF again. This time, when PMDF goes to read that parameter, it gets an error since it has already been read. This then essentially aborts VMS MAIL. You can get a lot of these if the timing is just right, i.e. one delivery job is following on the heels of another, trying to deliver the messages the other job has already processed. I've piddled around with this code a fair amount, and I have not found any way to fix this problem. I've never seen it last for any great length of time, and as Terry said, the mail always seems to get delivered on the next pass. I think there's a bug in the initialization of the foreign procotol interface on the incoming side, but I've never been able to locate it on the ufiche. There's also a mechanism that forces MAIL to loop and call PMDF over and over again. This would be very useful if it worked properly, since then a single invocation of VMS MAIL would process every message (a considerable savings in overhead). There's expermental code in PMDF_MAIL.PAS to operate this way, but I've never been able to get it to work right -- it always bombs out of mail on the second pass. I don't know why this happens, but it does. I have not seen this problem under VMS 5.3 either, and I have not tried the loop code since 5.2. I'll try to look into this some more in the future, but the technique used now does seem to work pretty well. If the messages are actually stuck in the queue, that's another kettle of fish. I'd recommend turning on slave_debug on the l channel to get an idea of what's really going on if messages are actually stuck and are not being delivered. Hope this helps. Ned