From: MERC::"uunet!DRYCAS.CLUB.CC.CMU.EDU!synful+vmsnet-errors" 17-JUL-1992 10:17:57.40 To: synful+vmsnet@DRYCAS.CLUB.CC.CMU.EDU CC: Subj: Re: MAIL documentation Here is some material from the FOREIGNERS mailing list, about which you may inquire to GOATHUNTER@WKUVX1.BITNET. .....RSS Received: from vms.ecs.rpi.edu by CS.UTK.EDU with SMTP (5.61++/2.5.1s-UTK) id AA19958; Mon, 20 May 91 11:34:29 -0400 Received: from mdmvs.ecs.rpi.edu by vms.ecs.rpi.edu (MX V2.2-2) with SMTP; Mon, 20 May 1991 11:32:07 EDT Received: by mdmvs.ecs.rpi.edu (MX V2.3) id 21024; Mon, 20 May 1991 11:31:30 EDT Date: Mon, 20 May 1991 11:31:30 EDT From: Matt Madison Reply-To: madison@vms.ecs.rpi.edu To: foreigners@vms.ecs.rpi.edu Message-Id: <00948E1E.AA282DA0.21024@mdmvs.ecs.rpi.edu> Subject: MAIL$ in place of inbound foreign protocol - works Status: R At the DECUS symposium two weeks ago, Tom Allebrandi and I discussed using callable MAIL instead of the foreign protocol interface for handling inbound mail deliveries. We weren't sure whether it would work, although I had talked to someone who said he was using callable MAIL for this purpose. As soon as I got back from Atlanta, I modified my local delivery agent so it would use callable MAIL, setting the From: address itself, rather than going through the rigmarole of spawning a subprocess to invoke MAIL_SERVER. The changes took all of about half an hour to complete, and I've been running it ever since. Works great! This makes life much easier - no more subprocess hanging around, no more kludging around to try and catch errors, a much simpler interface... and a much reduced MX_MAILSHR as well. I haven't seen any real problems yet. One minor annoyance was that in order to be able to trap errors on a per-user basis, I still have to generate a temporary file and go through the process of mailing it to each individual local user. But since I had to do that when using MAIL_SERVER, too, it's not that big a deal. -Matt -- (This address information is OLD--Matt is now at TGV.) Matthew Madison, Systems Programmer | Internet: madison@vms.ecs.rpi.edu Engineering Computing Services | Bitnet: MADISON@RPIECSVX Rensselaer Polytechnic Institute | Troy, New York 12180-3590 USA | From list-mgr@vms.ecs.rpi.edu Fri May 24 11:47:18 1991 Return-Path: Received: from vms.ecs.rpi.edu by CS.UTK.EDU with SMTP (5.61++/2.5.1s-UTK) id AA10718; Fri, 24 May 91 11:47:12 -0400 Received: from SLCS.SLB.COM by vms.ecs.rpi.edu (MX V2.2-2) with SMTP; Fri, 24 May 1991 11:44:29 EDT Received: from sndrtr.psi by SLCS.SLB.COM (4.1/SLCS Mailhost 3.13) id AA20848; Fri, 24 May 91 10:45:05 CDT Date: Fri, 24 May 91 10:45:05 CDT From: brydon@asl.SINet.SLB.COM (Eschew Obfuscation) Message-Id: <9105241545.AA20848@SLCS.SLB.COM> To: foreigners@vms.ecs.rpi.edu, kvc@summer.innosoft.com X-Vms-To: INTERNET::"foreigners@vms.ecs.rpi.edu", INTERNET::"kvc@summer.innosoft.com", GEST01::RUNE, EPS::BARBE Subject: Remedy for problem with Carosso-based foreign mail programs Status: R After much anguish and debugging, I have diagnosed a problem with several foreign mail transport programs, including 'most' or perhaps 'all' mailers written in Pascal, with code originally by Kevin Carosso (PMDF, DELIVER, UUCP_MAIL, ...). I posted a problem description in late March/early April 1991 to both 'info-vax@kl.sri.com' and 'foreigners@vms.ecs.rpi.edu', requesting that somebody try a test case and send me the results. The [embellished] problem description is: >I am writing a foreign mail transport (HM%, HM_MAILSHR) and am having a lot of >trouble with it running on PSI machines. The transport works just fine on all >but PSI machines when a particular method of addressing is used. To >summarize, if: > >(1) you are on a VMS system running PSI and >(2) you send a message within the mail utility (not from "$" prompt) and >(3) you send to one or more HM%xxx addresses FIRST followed by >(4) a PSI%yyy address (either on the same line or in CC: field) > >then you get an access violation. For example, the following work fine: > >$ mail nl: hm%node1::brydon,psi%node1::brydon/subj=test >$ mail nl: psi%node1::brydon,hm%node1::brydon/subj=test >$ mail >MAIL> send /noself/noed >To: psi%node1::brydon,hm%node1::brydon ! (PSI% address listed first) >Subj: test >... > >But this generates an access violation: > >$ mail >MAIL> send /noself/noed >To: hm%node1::brydon,psi%node1::brydon ! (HM% address listed first) >Subj: test >Enter your message below. Press CTRL/Z when complete, or CTRL/C to quit: >test >^Z >%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000, PC >=00000000, PSL=03C00000 > > Improperly handled condition, image exit forced. > > Signal arguments Stack contents > > Number = 00000005 00000000 > Name = 0000000C 00070000 > 00000000 00071B6C > 00000000 00071B84 > 00000000 00073BFA > 03C00000 00068C31 > 00002E94 > 00072074 > 00072050 > 00071B58 > > Register dump > > R0 = 00010001 R1 = 00000000 R2 = 80004BA0 R3 = 8034EF00 > R4 = 8034EEB0 R5 = 00000000 R6 = 00000200 R7 = 7FEF3336 > R8 = 00071DFB R9 = 000CDB10 R10= 000CCE08 R11= 7FFDFE70 > AP = 7FEF34F4 FP = 7FEF34B4 SP = 7FEF3530 PC = 00000000 > PSL= 03C00000 > >$ > >The same kind of thing also occurs if a distribution list is used. Usage of >qualifiers such as /CC and /SELF don't matter, except in the order of >addresses as received by MAIL.EXE... > >Anybody have a similar experience? Anybody have any ideas? I'm not sure if >this is the same problem seen by others. Could somebody try this with PMDF, >UUCP or another transport and either confirm or deny the same problem with >that transport? > ... Unfortunately I did not receive a reply from anybody, so I don't know for sure if the problem (which is genuinely there) shows up with these other protocol handlers in the same or similar circumstances. I have determined that the above crash occurs because I/we are incorrectly modifying some fields in the RAB for outgoing delivery, either in routine MAIL_OUT_FILE or in one of the routines it calls. My protocol doesn't do incoming delivery, so I don't know of any problems that exist there. MAIL.EXE allocates a mail$k_inbuffsiz (512) byte buffer within the CNCTDESC, sets RAB$W_USZ and points RAB$L_UBF at it (lines 1670-1671 in MAIL$NETSUBS in the VMS V5.3 listings). When a $read or $get is done in the foreign protocol handler, RAB$W_RSZ and RAB$L_RBF are set. The latter two should be read from the foreign protocol handler, but none of the 4 RAB$x_xxx values should be modified by the foreign protocol handler, except for perhaps RAB$W_RSZ. I found that since I was setting RAB$L_UBF to point to my 'temporary' string, things would work fine while in my protocol, but other foreign protocols (such as PSI or DSNlink) that are called after mine just use the existing RAB.RAB$L_UBF value without setting it. So they expect to use the buffer as provided by MAIL.EXE, and not create their own. The result is that any $READs or $GETs would clobber the stack, resulting in the access violation as above. The order that foreign protocols are called is determined by the addressing order of the list as specified by the user at the terminal. I would recommend all code be changed to treat the RAB the same way as DEC foreign protocols. I have looked at PSI_MAILSHR.EXE in the most detail. Here is what it does: source line# Entry MAIL_SEND_FILE (context, link_flag, node_desc, RAB_ptr, err_rtn) 1189 status := SET_BLOCK_MODE(RAB_ptr, err_rtn) 1190 goto lb_c01 lb_bdc: 1201 if RAB.RAB$W_RSZ = 1 then 1202 if RAB.RAB$L_RBF[1] = 0 then 1203 RAB.RAB$W_RSZ := 0 ! RAB.RAB$W_RSZ modified here 1205 v1 := RAB.RAB$W_RSZ 1206 v2 := RAB.RAB$L_RBF 1208 stat := MAIL_WRITE_QIO(context,, v1,) lb_c01: 1209 if (not stat) return stat 1192 stat := $read(RAB) if stat then goto lb_bdc 1216 stat := MAIL_WRITE_QIO(context,, null_desc,) 1218 return stat Entry SET_BLOCK_MODE(RAB_ptr, err_routine) 1261 if RAB.RAB$V_BIO then 1264 stat := $disconnect(RAB, err_routine) 1265 if (not stat) return stat 1267 RAB.RAB$V_BIO := '1' ! RAB.RAB$V_BIO modified here 1269 stat := $connect(RAB, err_routine) return stat end if 1271 return 1 DSNlink does it in a similar fashion. I have executables for several other x_MAILSHR.EXE's (DSNlink, JANET, PCFS, PSI, ...) but I haven't explored their treatment of the RAB fields. I would assume they work the same way. I have changed my code as above and it doesn't crash PSI machines any more. Surprise surprise. Does anybody have any comments on this? Perhaps reply to 'foreigners@vms.ecs.rpi.edu'. ____________________________________________________________________________ Harvey Brydon | SLB DECnet: ASL::BRYDON Schlumberger Anadrill | Internet: brydon@asl.sinet.slb.com 200 Macco Blvd | FAX: (713)274-8399 Sugar Land, TX | Telex: 1565030001 SINET ASL SLB 77478 USA | P.O.T.S.: (713)274-8000 x8281 or 274-8281 (d.i.d.) Bliss is Ignorance From list-mgr@vms.ecs.rpi.edu Wed Oct 23 13:32:42 1991 Return-Path: Received: from vms.ecs.rpi.edu by CS.UTK.EDU with SMTP (5.61++/2.7s-UTK) id AA07418; Wed, 23 Oct 91 13:32:33 -0400 Received: from mdmvs.ecs.rpi.edu by vms.ecs.rpi.edu (MX V2.3-1) with SMTP; Wed, 23 Oct 1991 13:24:17 EDT Received: by mdmvs.ecs.rpi.edu (MX T2.4) id 101; Wed, 23 Oct 1991 13:24:36 EDT Sender: Date: Wed, 23 Oct 1991 13:24:33 EDT From: Matt Madison Reply-To: madison@vms.ecs.rpi.edu To: foreigners@vms.ecs.rpi.edu Message-Id: <009508C4.4E012D80.101@mdmvs.ecs.rpi.edu> Subject: exec mode dispatch code base for MX_MAILSHRP Status: R I'm nearly ready to field test the latest version of MX, in which I have split off the code requiring privileges into a privileged shareable image. I'm using exec mode dispatch codes -1010 (the negated equivalent of "MX" as roman numerals) through -1004. I don't have any kernel mode routines. The reason I mention this is that in order to prevent conflicts among our VMS Mail foreign protocols, we have to coordinate our dispatch code space so they don't overlap. I just wanted to check to see if anyone out there who has also done a privileged shareable image for use by their foreign mail protocol has already used any of those codes; if so, I'll modify my dispatch vector now. Otherwise, I'll stake my claim to -1010 through, say, -1001. -Matt -- Matthew Madison, Systems Programmer | Internet: madison@vms.ecs.rpi.edu Engineering Computing Services | Bitnet: MADISON@RPIECSVX Rensselaer Polytechnic Institute | Troy, New York 12180-3590 USA | From list-mgr@vms.ecs.rpi.edu Wed Jan 29 08:41:00 1992 Return-Path: Received: from vms.ecs.rpi.edu by CS.UTK.EDU with SMTP (5.61++/2.7s-UTK) id AA24278; Wed, 29 Jan 92 08:39:08 -0500 Errors-To: list-mgr@vms.ecs.rpi.edu X-Listname: VMSmail foreign protocols discussion list Received: from SLCS.SLB.COM by vms.ecs.rpi.edu (MX V3.0A) with SMTP; Wed, 29 Jan 1992 08:37:09 EST Received: from sjosu1.sinet.slb.com ([129.87.118.1]) by SLCS.SLB.COM (4.1/SLCS Mailhost 3.13) id AA27296; Wed, 29 Jan 92 07:35:59 CST Received: from prsrtr.psi by sjosu1.sinet.slb.com id AA05654; Wed, 29 Jan 92 05:36:43 PST Date: Wed, 29 Jan 92 05:36:43 PST From: brydon@asl.SINet.SLB.COM (Eschew Obfuscation) Reply-To: brydon@asl.SINet.SLB.COM (Eschew Obfuscation) Message-Id: <9201291336.AA05654@sjosu1.sinet.slb.com> To: foreigners@vms.ecs.rpi.edu Cc: BRYDON@asl.SINet.SLB.COM X-Vms-From: PSI%ASLVX6::ASLVX6::ASL::BRYDON "Eschew Obfuscation" X-Vms-To: ASLVX6::HM%INTERNET::"vms.ecs.rpi.edu::foreigners" X-Vms-Cc: BRYDON Subject: "problem with call_read_error_text routine" - resolved Status: R I have written a foreign mail protocol (HM%), as have probably most of the people on this list. As other protocols have done, I have generally handled errors in a few routines myself and used LIB$SIGNAL where appropriate rather than figure out the relatively complicated linkage back to the MAIL-11 error handlers. Looking at the MAIL listings, this seems relatively harmless, and the error routines in MAIL are relatively simple and easy to convert to a local routine. However, I have found that other mail user agent(s) such as DECW$MAIL don't like a foreign protocol doing its own handling or LIB$SIGNAL-ling and ugly errors have resulted. I haven't looked at the DECW$MAIL source, but it appears that if a transmission error occurs, DECW$MAIL expects the error routine to be called. Thus began the motivation to determine and implement the 'real' linkage to the MAIL error handler routines. Back in early December I asked if anybody has successfully used the call_read_error_text routine that is supplied with calls to the CKUSER and CKSEND routines. I got no takers, but figured out the solution. I would suggest that everybody implement the same coding strategy for compatibility with all known (and future) user agents. The problem occurs, or at least is made more difficult because of VAX Pascal's policy of insisting on passing everything by reference, including routine addresses. The Pascal lingo for this is 'Bound Procedure Value'. Unfortunately, most routine addresses from the MAIL-11 code (MAIL.EXE, MAILSHR, MAILSHRP) are passed by address. Pascal makes provision for passing parameters to external non-Pascal routines by address, but will not allow passing of parameters in that fashion to Pascal code. In other words, the following mini-program is valid and compiles correctly in VAX Pascal: module blah1; procedure blah( x : [immediate] integer; [unbound, asynchronous, reference] function f1 : integer; [unbound, asynchronous, immediate] function f2 : integer); extern; end. But the following does not compile: module blah2; procedure blah( x : [immediate] integer; [unbound, asynchronous, reference] function f1 : integer; [unbound, asynchronous, immediate] function f2 : integer); begin { Do some stuff here } end; end. All 3 procedure parameters are flagged as 'passing mechanism allowed only on external routine' or some such. The VAX Pascal Reference Supplement for VMS Systems (Section 3.5) says: "When the VAX PASCAL routine requires a formal procedure or function parameter, the parameter list of the calling routine must specify the address of a bound procedure value. This process implements the VAX by-reference mechanism for a routine." which is unfortunate. I am not an expert on Pascal, but that seems to be an artificial limitation imposed on VAX Pascal by your friends and mine at DEC. Library routines and LIB$CALLG to the rescue. LIB$CALLG was written to allow a program to build a parameter list at runtime, but it allows us to send routine addresses by address rather than BPV linkage. Here is a non-debug uncommented version of my MAIL_OUT_CHECK and MAIL_OUT_FILE routines. It has been tested a little over a month on various user agents without problems. If anybody spots any logic errors or linkage problems please post to foreigners@vms.ecs.rpi.edu or send to me and I'll summarize. I believe this code complies with all known mail user agents. [global] function MAIL_OUT_CHECK( var context : [readonly] ctxptr; var link_flag : [readonly] integer; { LNK_C_OUT_CKUSER/CKSEND } var node_desc : [readonly] string_descriptor; var addressee_desc : [readonly] string_descriptor; var call_read_error_text : [readonly] unsigned) : unsigned; var stat : unsigned; ad_string : string; nd_string : string; iobuff : iostring; arglist : array[1..3] of integer; begin copy_descr_to_string(addressee_desc , ad_string); copy_descr_to_string(node_desc , nd_string); with context^, hm_rec do case iaddress(link_flag) of LNK_C_OUT_CKUSER : begin { Check addressee is valid } if (ad_string.length = 1) and { end of list terminated by null } (ad_string.body[1] = chr(0)) then begin { 1778 - mail$$net_end_users } stat := write_link(context, ad_string); end else begin { 1618 - mail$$net_addr } stat := write_link(context, hm_rec.hm_s_tag + ad_string); if not odd(stat) then lib$signal(stat) else begin stat := read_link(context, iobuff, hm_s_firstnode + '::' + hm_s_tag + ad_string, false); {} if odd(stat) then stat := string_to_integer(iobuff); end; end; end; LNK_C_OUT_CKSEND : begin { Check message sent to addressee } { Code similar to above... } end; end; if not odd(stat) then begin arglist[1] := 2; arglist[2] := iaddress(context); arglist[3] := iaddress(read_slave); stat := lib$callg(argument_list := arglist, user_procedure := %ref call_read_error_text); end; mail_out_check := stat; end; [global] function MAIL_OUT_FILE( var context : [readonly] ctxptr; var link_flag : [readonly] integer; var node : [readonly] string_descriptor; var message_RAB : [volatile] RAB$TYPE; var UTIL$REPORT_IO_ERROR : [readonly] unsigned ) : unsigned; label return; var line_desc : string_descriptor; stat : unsigned; line : iostring; sendit : boolean; arglist : array[1..2] of integer; begin if context^.link.lnk_v_blkmode then begin { Block mode I/O } if not message_RAB.RAB$V_BIO then begin { 1677 - send_message } $disconnect(rab := message_RAB, { 1679 - send_message } err := %ref UTIL$REPORT_IO_ERROR); message_RAB.RAB$V_BIO := true; { 1680 - send_message } stat := $connect(rab := message_RAB, { 1681 - send_message } err := %ref UTIL$REPORT_IO_ERROR); if not odd(stat) then goto return; { 1682 - send_message } end; stat := $read(rab := message_RAB, err := %ref UTIL$REPORT_IO_ERROR); while(stat <> RMS$_EOF) do begin if not odd(stat) then goto return; { 1689 - send_message } line_desc.dsc$w_length := message_RAB.RAB$W_RSZ; { 1690 - send_message } line_desc.dsc$a_pointer := { 1691 - send_message } message_RAB.RAB$L_RBF::bigptr; copy_descr_to_string(line_desc, line); stat := write_link(context, line); if not odd(stat) then goto return; { 1693 - send_message } stat := $read(rab := message_RAB, err := %ref UTIL$REPORT_IO_ERROR); end; end else begin { Record I/O } if message_RAB.RAB$V_BIO then begin { 1702 - send_message } $disconnect(rab := message_RAB, { 1704 - send_message } err := %ref UTIL$REPORT_IO_ERROR); message_RAB.RAB$V_BIO := false; { 1705 - send_message } stat := $connect(rab := message_RAB, { 1706 - send_message } err := %ref UTIL$REPORT_IO_ERROR); if not odd(stat) then goto return; { 1693 - send_message } end; stat := $get(rab := message_RAB, err := %ref UTIL$REPORT_IO_ERROR); while(stat <> RMS$_EOF) do begin line_desc.dsc$w_length := message_RAB.RAB$W_RSZ; { 1712 - send_message } line_desc.dsc$a_pointer := { 1713 - send_message } message_RAB.RAB$L_RBF::bigptr; if not odd(stat) then begin arglist[1] := 1; arglist[2] := iaddress(message_RAB); stat := lib$callg(argument_list := arglist, { 1714 - send_message } user_procedure := %ref UTIL$REPORT_IO_ERROR); goto return; end; if message_RAB.RAB$W_RSZ > 255 then begin { 1715 - send_message } lib$signal(rms$_rtb, message_RAB.RAB$W_RSZ); stat := RMS$_RTB; end else begin copy_descr_to_string(line_desc, line); sendit := true; if (line.length = 1) then { null string breaks protocol } if (line[1] = chr(0)) then { 1719 - send_message } sendit := false; if sendit then begin stat := write_link(context, line); if not odd(stat) then goto return; end; end; stat := $get(rab := message_RAB, err := %ref UTIL$REPORT_IO_ERROR); end; end; stat := write_link(context, chr(0)); { 1726 - send_message } if not odd(stat) then if stat <> RMS$_EOF then if stat <> RMS$_RTB then lib$signal(HMAILER__mesreaerr, 1, stat, stat); return: MAIL_OUT_FILE := stat; end; ____________________________________________________________________________ Harvey Brydon | Internet: brydon@asl.sinet.slb.com Schlumberger Anadrill | FAX: (713)274-8399 200 Macco Blvd | Telex: 1565030001 SINET ASL SLB Sugar Land, TX 77478 | P.O.T.S.: (713)274-8000 x8281 or 274-8281 (d.i.d.) Reality is for those who can't handle simulation. From list-mgr@vms.ecs.rpi.edu Wed Jan 29 11:36:41 1992 Return-Path: Received: from vms.ecs.rpi.edu by CS.UTK.EDU with SMTP (5.61++/2.7s-UTK) id AA03132; Wed, 29 Jan 92 11:36:36 -0500 Errors-To: list-mgr@vms.ecs.rpi.edu X-Listname: VMSmail foreign protocols discussion list Received: from TGV.COM by vms.ecs.rpi.edu (MX V3.0A) with SMTP; Wed, 29 Jan 1992 11:32:33 EST Date: Wed, 29 Jan 92 08:30:29 PST From: mcmahon@TGV.COM (John 'Fast-Eddie' McMahon) Reply-To: mcmahon@TGV.COM (John 'Fast-Eddie' McMahon) Message-Id: <920129083029.22e0c721@TGV.COM> Subject: FWD: "problem with call_read_error_text routine" - resolved To: foreigners@vms.ecs.rpi.edu X-St-Vmsmail-To: st%"Foreigners@vms.ecs.rpi.edu" Status: RO > However, I have found that other mail user agent(s) such as > DECW$MAIL don't like a foreign protocol doing its own handling or > LIB$SIGNAL-ling and ugly errors have resulted. I haven't looked at the > DECW$MAIL source, but it appears that if a transmission error occurs, Be advised that with the "switch" to Motif, the DECW$MAIL sources are no longer available. The stuff on the Listings kit is the "XUI" DECW$MAIL, and those sources will probably disappear off of the V5.5(+1) CD-ROM. John 'Fast-Eddie' McMahon : MCMAHON@TGV.COM : TTTTTTTTTTTTTTTTTTTTTTTT TGV, Incorporated : : T GGGGGGG V V 603 Mission Street : HAVK (abha) Gur bayl : T G V V Santa Cruz, California 95060 : bcrengvat flfgrz gb : T G GGGG V V 408-427-4366 or 800-TGV-3440 : or qrfgeblrq ol znvy : T GGGGGGG V -- ....Richard S. Shuford | "When the righteous triumph, there is great elation; ....shuford@cs.utk.edu | but when the wicked rise to power, men go into ....BIX: richard | hiding." Proverbs 28:12 NIV