From: AITGW::"MACRO32@WKUVX1.BITNET" 20-MAR-1992 15:07:55.45 To: CC: Subj: VMS LAT protocol error's in VMS 5.5? Received: by AITGW.DECnet (utk-mail11 v1.5) ; Fri, 20 Mar 92 15:07:04 EST Received: from ukcc.uky.edu by aitgw.ge.com (5.65/GE Gateway 1.5) id AA00450; Fri, 20 Mar 92 15:06:58 -0500 Received: from ukcc.uky.edu by UKCC.uky.edu (IBM VM SMTP V2R2) with BSMTP id 9995; Fri, 20 Mar 92 14:56:33 EST Received: from UKCC by ukcc.uky.edu (Mailer R2.08) with BSMTP id 9817; Fri, 20 Mar 92 14:55:42 EST Received: from WKUVX1.BITNET by ukcc.uky.edu (Mailer R2.08) with BSMTP id 9657; Fri, 20 Mar 92 14:54:30 EST Errors-To: MacroMan@WKUVX1.BITNET X-Listname: "VMS Internals, MACRO, and BLISS Discussions" Received: from CUNYVM.BITNET (MAILER) by WKUVX1 (MX V3.0A) with BSMTP; Fri, 20 Mar 1992 13:23:31 CST Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.08) with BSMTP id 6620; Fri, 20 Mar 92 14:12:24 EST Received: from MVB.SAIC.COM by CUNYVM.CUNY.EDU (IBM VM SMTP V2R2) with TCP; Fri, 20 Mar 92 14:12:21 EST Xref: unogate comp.sys.dec:4080 vmsnet.internals:616 X-Newsgroups: comp.sys.dec,vmsnet.internals From: Subject: VMS LAT protocol error's in VMS 5.5? Message-Id: <1992Mar20.182811.14252@gordian.com> Sender: news@gordian.com Reply-To: MACRO32@WKUVX1.BITNET Organization: Gordian; Costa Mesa, CA Date: Fri, 20 Mar 1992 18:28:11 GMT X-Gateway-Source-Info: USENET Apparently-To: [ Is there a way to directly submit an E-SPR? This is really an internal VMS question...] I have noticed a problem in the VMS implementation of LAT since the new LATmaster code was released (I am currently running V5.5 of VMS). The scenario deals with reverse LAT connections to printers. I'm wondering if DEC knows about this problem, and would care to comment. Scenario: A single virtual circuit between a terminal server and the Vax, with one quiesent terminal session (to maintain the circuit) and one print device. The printer is printing many smallish jobs (the problem is in the solicit code, thus smallish jobs increase the likelyhood...). Setup: ! on terminal server TSERVER: local> SET SERVICE BLAH PORT 3,4,5 ! on VAX host ALEX latcp> SET PORT LTA9000 /node=TSERVER /service=BLAH Initial Requirements: In order to reproduce this problem consistantly, the node-circuit between the VAX and the server must be maintained. The easiest way to accomplish this is to log one session from the terminal server onto the VAX. Network Dialog: Server Vax ___________________________ 1 StartCircuit 2 StartCircuit 3 StartSlot #1 (service = ALEX) 4 StartSlot #1 [log in sequece...] [Start printing a job, queueing up several jobs:] 5 Solicit (service = BLAH, request-id #1) 6 StartSlot #2 (request-id #1 7 StartSlot #2 [dump the job...] 8 Solicit (service = BLAH, request-id #2) 9 StopSlot #2 10a StartSlot #3 (request-id #2) 10b StopSlot #2 11 Acks previous message 12 Solicit (service = BLAH, request-id #3) 13 StartSlot #2 (request-id #3) 14 StartSlot #2 [dumps job...] [Slot #3 is hung, all else proceeds normally...] Analysis: The problem here is that the VAX acknowledged the start slot message in (6), but never acted on it. The Vax then resolicits for the same service using a _different_ request-id as if it never even saw (6). The problem is that this leaves the server with a half open circuit. IMHO, this is a protocol error on the VAX's part. It appears that the server ought to timeout the half open session without much fuss (should it send a stop slot for #2 though??), but the VAX's lossage of this message seems a little odd. As a note, the timing between these messages is _nowhere_ close to retransmit timeout. This does not happen every time: pumping smallish jobs down (10 second jobs @ 9600 baud) takes approximately 20 minutes to reproduce the problem. I have Sniffer traces if anybody at DEC is interested in looking at them. -- Michael Thomas (mike@gordian.com) "I don't think Bambi Eyes will get you that flame thrower..." -- Hobbes to Calvin USnail: 20361 Irvine Ave Santa Ana Heights, Ca, 92707-5637 PaBell: (714) 850-0205 (714) 850-0533 (fax)