Kermit-11 known problems 07-Apr-1986 09:37 (Pending) On RT11 FB systems with a large number of devices, Kermit can displace the USR (force it to swap) and crash when accessing the USR from the higher addressed overlays in Kermit. The fix for something like this may not be practical; it can be worked around by UNLOADING and REMOVING unneeded device drivers from lowest address to higher addresses (to prevent fragmentation of background memory). If you run K11RT4.SAV on a FB system and find either (1) The program crashes on file transfers or (2) KMON says the save image is too large, then remove the unneeded drivers and set the USR to swap. 24-MAR-1986 14:23 (Fixed in version 3.49) Attribute processing is incorrect for some attribute types. This dates back to April 1984 when support was first added, but no other versions were available to test against. The correction, made to K11ATR.MAC, will cause V3.49 or later of Kermit-11 to have compatability problems with previous versions of Kermit-11. The main problem will be in informing each other of binary file arrival; the only workaround is to explicitly force two communicating Kermit-11's into binary mode with the SET FILE command. See K11INS.DOC for further information. The specific problem is that the protocol requires the attribute TYPE field to be followed by a LENGTH byte to specify the number of characters following. Kermit-11 was not always inserting the LENGTH field. The new version, 3.49, will be able to tell if an older Kermit-11 is sending in the incorrect format by virtue of the fact that the first attribute packet that is sent is the system id code and operating system. Since this attribute will always be a short one (2 or 3 characters at most) it is a simple matter to detect the presence of a 'D' (for DEC) in the position of the LENGTH field and set a flag accordingly. However, in the case of the corrected Kermit-11 sending to a pre 3.49 version, this will not be the case and all attempts to rely on the transfer of attribute packets will fail. brian@uoft02.bitnet ------------------------------ .sbttl getcm1 check for additional input needed ; G E T C M 1 ; ; input: @r5 current command buffer ; 2(r5) command table address ; 4(r5) index of the current command ; ; output: r0 index of current command or < 0 for error ; argbuf any additional input or rest of the command line .enabl lsb ; /55/ getcm1: save ; Save registers that we destroy sub #100 ,sp ; /55/ Allocate a small buffer for mov sp ,r2 ; /55/ saving the command prompt. tst wasnul ; /45/ Was the command for ? beq 10$ ; /45/ No clr wasnul ; /45/ Not null anymore clr r0 ; /45/ Yes, return index 0 br 110$ ; /45/ Exit 10$: mov @r5 ,r1 ; Get command line address scan #40 ,r1 ; Look for a space that might delimit tst r0 ; the command name from an argument beq 30$ ; Nothing there add r1 ,r0 ; Point to the string after the space COPYZ r0,argbuf,#200 ; Copy the command arg over please br 100$ ; And exit 30$: mov 4(r5) ,r3 ; Get the command index mul #$listl*2,r3 ; If no arg given, see if one is needed add 2(r5) ,r3 ; Add in base address of command table mov .cmdar(r3),r3 ; Get the argument prompt now tstb @r3 ; Anything there that is required ? beq 100$ ; No, so take a normal exit then. STRCPY r2 ,r3 ; /55/ Copy the prompt over now 40$: CALLS kbredi , ; /55/ Read a command from the keyboard tst r0 ; And exit if it failed for whatever bne 90$ ; The read failed (control Z typed). tst cccnt ; No, but is there a Control C? bne 90$ ; Yes, treat as end of file CALLS cvt$$,;Remove junk, convert to upcase tst r0 ; Is there anything left ? beq 40$ ; No, reprompt and try again mov r0 ,r1 ; Something is left, point to the add argbuf ,r1 ; end of the line and null terminate clrb @r1 ; ... br 100$ ; Take normal exit 90$: MESSAGE ; /55/ Insure a carriage return mov #cmd$ab ,r0 ; Control Z on keyboard read. br 110$ ; And exit 100$: mov 4(r5) ,r0 ; Return command index 110$: add #100 ,sp ; /55/ Pop the temporary buffer unsave ; Restore registers we used return ; And exit .dsabl lsb ; /55/ global ------------------------------ Date: Mon, 23 Mar 87 13:00 EST From: Lewis M. Dreblow - PSYCH at UFFSC Subject: Kermit-11 Problem Discovered and Solved Keywords: Kermit-11 I wish to inform the user community of a problem which occurred with the K11 release of Kermit. I was trying to use kermit on a 11/23 running RTV5 and TSXV5. I had no trouble using the release as a server, but kept getting hung whenever I tried to do a get or send to another remote server. It didn't matter what machine was on the server end. After about a month of tearing my hair out I discovered that I had TSGENed IOABT = 0 which caused TSX to wait for IO completion on jobs. This seemed fine at TSGEN time, but due to the .ABTIO MCALL in K11PRT caused kermit to hang for two minutes at every get or send command. Thus, users should be aware that they have to either (1) TSGEN IOABT = 1 or (2) at the command line (or in a command file) prior to running kermit issue the SET IO ABORT command. You may want to remember to SET IO NOABORT after running kermit as well. ------------------------------