From: CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 7-APR-1991 01:17:53.32 To: ARISIA::EVERHART CC: Subj: PSI patch and third party mail: How I fixed DECUS UUCP From: RELAY-INFO-VAX@CRVAX.SRI.COM@SMTP@CRDGW2 To: Everhart@Arisia@MRGATE Received: by crdgw1.ge.com (5.57/GE 1.94) id AA20173; Sat, 6 Apr 91 23:01:47 EST Received: From UCBVAX.BERKELEY.EDU by CRVAX.SRI.COM with TCP; Sat, 6 APR 91 05:01:27 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA18251; Sat, 6 Apr 91 04:51:39 -0800 Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-vax@kl.sri.com (info-vax@kl.sri.com) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Apr 91 10:45:44 GMT From: mintaka!think.com!sdd.hp.com!samsung!nstar!inland!allebrandi@bloom-beacon.mit.edu (Tom Allebrandi) Organization: Inland Steel Research Labs; East Chicago, IN Subject: PSI patch and third party mail: How I fixed DECUS UUCP Message-Id: <773.27fc5559@inland.com> References: <9B170695195F0009F0@imimnvx.irfmn.mnegri.it>, <4171@stl.stc.co.uk> Sender: info-vax-request@kl.sri.com To: info-vax@kl.sri.com In article <4171@stl.stc.co.uk>, scott@stl.stc.co.uk (Mike Scott) writes: > Could someone post (accurate) details of the changes please? It would > mean others of us could be prepared for the nasty shock :-} In the DECUS UUCP Mail Handler, the PSI Patches affected only inbound delivery. Here is a synopsis of my research into the problem and the way that I fixed it. Standard disclaimers apply :-) I don't have PSI, so I had people that do send me the patches for MAIL_SERVER.EXE. There were two of them. I did some checking, one of them is in the MAIL_SERVER.EXE that is shipped with VMS 5.4. The other was not. I have not looked at 5.4-1 or 5.4-2 to check the existance of the other patch. I had independant information that my Mail Handler worked on VMS 5.4. That indicated that the patch that is in 5.4 is not the problem, the other one is. So, I looked at what that patch does. The patch causes MAIL_SERVER.EXE to PROBABLY travel down a different path then it did before. Looking at what happens when you travel down that path, I noticed a direct relationship back to the some of the parameters that I was passed in the inbound connect call. Specically, the inbound connect call, which many people call MAIL_IN_CONNECT, has three parameters that control the creation of the inbound message file -- RAT, RFM and ORG. The new path through MAIL_SERVER causes the values you return in these parameters to end up in the FAB used to open the message file. I was not setting these parameters to anything. This was apparently safe prior to the new path through MAIL_SERVER. Now, if these values are garbage, the file create fails. The inbound connection routine, should have the following argument list: context : unsigned long pased by reference link_flag : long passed by value input_tran : string descriptor passed by reference file_rat : byte passed by reference file_rfm : byte passed by reference mail$gl_sysflags : long passed by reference mail$q_protocol : string descriptor passed by reference pflags : byte passed by reference file_org : byte passed by reference I'm noting the list here because my code was somewhat old and did not have the file_org parameter. This parameter has apparently has appeared sometime since Version 5 of VMS. Others may be missing this parameter as well. I added code to set: file_rat := FAB$M_CR; file_rfm := FAB$C_VAR; file_org := FAB$C_SEQ; After doing that, my Mail Handler stopped crashing. By the way, Matt Madison (MX) and I have started a mailing list for developers of foreign mail handlers. (I came up with the idea, Matt is running the list.) We don't expect there to be tons of traffic on the list. We just thought that it would be a nice meeting place for those of developing these beasts. The mailing list is Foreigners@vms.ecs.rpi.edu. To subscribe to the list, send a mail message to Foreigners-Request@vms.ecs.rpi.edu with a body containing the word SUBSCRIBE You will get an acknowledgment that you have been added to the list. --- Tom Tom Allebrandi | Mail guru - DECUS UUCP Development Team Inland Steel Research Labs | Chairperson - VMSnet Working Group, DECUS VAX SIG East Chicago, IN | Internet: allebrandi@inland.com 219 399 6306 | UUCP: ...!uunet!inland!allebrandi | DECUServe: allebrandi BIX: ta2