From: CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 12-FEB-1991 05:58:14.73 To: ARISIA::EVERHART CC: Subj: Re: VMS Batch Modem Dialing/Scripting Package From: RELAY-INFO-VAX@CRVAX.SRI.COM@SMTP@CRDGW2 To: Everhart@Arisia@MRGATE Received: by crdgw1.ge.com (5.57/GE 1.80) id AA23345; Tue, 12 Feb 91 04:53:53 EST Received: From UCBVAX.BERKELEY.EDU by CRVAX.SRI.COM with TCP; Mon, 11 FEB 91 20:10:01 PST Received: by ucbvax.Berkeley.EDU (5.63/1.42) id AA07845; Mon, 11 Feb 91 20:04:24 -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: 12 Feb 91 01:18:37 GMT From: fernwood!portal!cup.portal.com!Chris_F_Chiesa@uunet.uu.net Organization: The Portal System (TM) Subject: Re: VMS Batch Modem Dialing/Scripting Package Message-Id: <39156@cup.portal.com> References: <154.27B0E424@insight.FIDONET.ORG>, <39075@cup.portal.com> Sender: info-vax-request@kl.sri.com To: info-vax@kl.sri.com Although I have just read a posting from Terry Kennedy (whose message I would ordinarily quote, except that Portal's EDITOR is now down...) stating that the Kermit-32 bug I mentioned has (he thinks) been fixed in version 3.3.128, I present a more-detailed description of my fix for version 3.3.126 on the off chance that someone else out there has as difficult a time as I do, getting the "latest version" of this sort of thing... ----- Greetings, NetLand... In response to popular demand (well, ONE request that gave me an excuse to type something (I LOVE to type)), here's a more-detailed rundown on the newer-version-of-Kermit bug-and-fix I hinted at in a recent posting. KERMIT VERSIONS INVOLVED: ------------------------- In my first posting I spoke only vaguely of "old" and "new" (to us) versions of VMS Kermit, but can now clarify: "old" version: 3.3.111 "new" version: 3.3.126 Depending on what version of Kermit YOU have, and what fixes may or may not have been performed since 3.3.126, the remainder of this text may or may not have any relevance to you. SYMPTOMS OBSERVED: ------------------ Due to the extreme indirectness of routes from this Net to the VAX on which we desired to upgrade Kermit, my colleague and I frequently have occasion to run VMS Kermit as a batch job. That is, we initiate an interactive dial-out "terminal session" on another host, initiate a Kermit "server" on the remote host just as though we were going to tie up our interactive terminal "for the duration," then (being careful first to "disable DTR detection" on our outbound local modem, so that termination of the interactive session does not break the connection) exit the interactive terminal session and crank up a batch job containing lines similar to the following: $ define/user sys$command kermit_commands.txt $ run [util]kermit $ exit (The file KERMIT_COMMANDS.TXT then contains commands which one might type at the interactive "Kermit-32>" prompt, e.g. SET LINE TXB3: SET FILE TYPE FIXED LOCAL CWD [TRANSFER.TAR] GET TAR2VMS_OBJ.EXE FINISH EXIT ) This worked extremely satisfactorily with VMS Kermit 3.3.111, but was a trifle slow due to that version's Kermit-packet-size limitations. We went to a lot of trouble to obtain the newer version 3.3.126, but on trying to use the technique above, found that version 3.3.126, when run in the Batch queue, would not accept the "SET LINE TXB3:" command. (I no longer possess an executable image of the distributed version of the program, so cannot tell you exactly what error message appeared.) FINDING THE BUG: ---------------- Fortunately for us, Kermit 3.3.126 is distributed in SOURCE code form. Unfortunately, that source is in BLISS, for which we do not have a compiler. Fortunately, someone else (the author?) had already compiled it, and even more fortunately the BLISS compiler generates assembleable MACRO-32 source code, for which of course we DO have the assembler! This meant two things: 1) We could track down the bug with help from "high-level" (BLISS) source code (which we could READ even if we couldn't WRITE or COMPILE), and 2) We would have to perform our fix(es), if any, in the intermediate MACRO-32 source code. I set to work with a copy of Kermit 3.3.126 assembled/linked /DEBUG, and the BLISS sources. To make a long story short, I found some logic I didn't agree with in module VMSTRM, routine ASN_WTH_MBX. I won't reproduce all of ASN_WTH_MBX, but the relevant section of BLISS-compilation MACRO source looks like this (wraparound to <80 cols here is mine for the purpose of this posting): ; 1078 2 sts = LIB$GETJPI(%REF(JPI$_TERMINAL),master_pid,0,0, temp_desc,temp_desc); ; 1079 2 IF NOT .sts THEN RETURN .sts; ; 1080 2 IF .(.temp_desc[dsc$a_pointer] - 1 + .temp_desc[dsc$w_length])<0,8> NEQ %C ':' ; 1081 2 THEN The problem is that in a BATCH process, LIB$GETJPI returns a zero-length "terminal name" into temp_desc, but that this condition is never tested and subsequent lines of code continue to process temp_desc as though it contains a valid device name. The ultimate result, I vaguely recall, is that a channel-assignment (using either SYS$ASSIGN or LIB$ASN_WTH_MBX) is attempted (with a null DEVNAM argument) and fails, resulting in the operational error observed previously. FIXING THE BUG: -------------- It was clear to me that if temp_desc held a zero-length string after the execution of line 1079, none of the rest of the procedure should be performed: that is, the remainder of the procedure should be executed only on the condition that temp_desc's length was non-zero. Fortunately, this is something that is easy to fix in the environment available to my colleague and I, namely VAX MACRO assembly language. The entire "patch" to the bug at hand consists of testing the length field of temp_desc, and branching to the end (RET instruction) of the procedure if that length is 0: two additional instructions. We happened to run into the byte-displacement limitation of the VAX branch instruction while we were at it, so had to add two more instructions to address THAT difficulty. The complete bug fix consists of replacing ONE line of the VMSTRM BLISS-compilation listing (aka MACRO source code) which looks like this: BLBC R0, 5$ ;STS, 5$ 1079 ... with the following eleven lines (five if you don't count comments): ; ; Due to the branch byte displacement... ; BLBS R0, 60$ ;STS, 5$ 1079 BRW 5$ 60$: ; ; WHD/CFC fixes the SET LINE command while in a batch job ; TSTW 8(SP) ; Is it a zero length string? BEQL 4$ ; Yes, in batch or other job... To confirm that YOU'VE done this correctly, use the DIFF/PARAL command to compare your original VMSTRM.MAR against a copy patched as shown here, and you should obtain the following output (more or less; I had to truncate some of the right-hand side to get it down to <80 columns for posting): -------------------------- 1257 ---------------------------------------------- BLBC R0, 5$ | ; | ; Due to the branch byte displacement... | ; | BLBS R0, 60$ | BRW 5$ | 60$: | ; | ; WHD/CFC fixes the SET LINE command | ; | TSTW 8(SP) ; Is it a | BEQL 4$ ; Yes, in ------------------------------------------------------------------------------ Number of difference sections found: 1 Number of difference records found: 11 DISCLAIMER: ---------- I have not investigated the entirety of VMS Kermit version 3.3.126 and do not know whether our fix introduces complications in other applications of the program. This fix solves the specific problem, under the specific conditions, described in this document, and should not be construed as anything more nor less. Any questions or comments may be addressed to me at Chris_F_Chiesa@cup.portal.com The Portal System is NOT the machine on which the procedures and programs described in this document were obtained, transferred, used, altered, or otherwise present; the machine on which such activities took place is not part of any network and the patched version of Kermit is not available for downloading by any mechanism. Chris Chiesa Chris_F_Chiesa@cup.portal.com 11-FEB-1991