Info-Kermit Digest Mon, 12 Jan 1986 Volume 6 : Number 1 Today's Topics: CUVMA bitnet link down 1/15 - 1/18 New Rainbow MS-DOS Kermit with VT-220 Emulation C-Kermit and CRLF Bug in C-Kermit Xenix on IBM-PC/AT & SCO Xenix V Kermit and Procomm ASCII uploads using Kermit on the VAX Kermit & DECserver 200's Send/Receive Overlap Implementation Flaw Function key map for PC Kermit ISIS-II Kermit/bootstrap wanted ---------------------------------------------------------------------- Date: Fri, 9 Jan 87 11:46:24 est From: Alan Crosswell Subject: CUVMA bitnet link down 1/15 - 1/18 Keywords: BITNET The communications controller for CUVMA's Bitnet link is scheduled to be down from 7:00AM EST 1/15/86 through 8:00PM EST 1/18/86. Directly connected nodes "upstream" (relative to CUNYVM) of CUVMA: CUVMB, CUVMC, CUCCA, CUCHEM, CUCEVX, CUCSVM, CUGSBVM, CUCSVM, CUTCV1, CUTHRY, GECRDVM1, NYSPI, NYUCCVM, NASAGISS. This also means the BITNET-CCNET gateway at CUVMA will be unreachable during this time. ------------------------------ Date: 19 Dec 1986 2150-EST From: David L. Knoell, Basic American Food Company, Vacaville, CA 95696 Via: EIBEN@MARLBORO.DEC.COM Subject: New Rainbow MS-DOS Kermit with VT-220 Emulation Keywords: MS-DOS Kermit, Rainbow Kermit, Terminal Emulation My company uses multi-vaxen (clustered and DEC-neted) including 8600,780's and mult-micro VAXens. We also have many Rainbows and so have a vested interest in their use as it relates to the VAX. It seemed a shame that DEC's firmware only emulated a VT102 even though the keyboard looks exactly like a VT220. For a while it didn't make much difference since VMS didn't know what a VT220 was anyway. Now we are using SEDT under VMS and it sure does know what a VT220 is. Well, one thing led to another and there were a few bugs in MSXRB1 and also in the Rainbow's firmware which needed fixing and I've never liked software which pre-empts any keys for its own selfish use without giving the user a way to override, so... New & Improved DEC Rainbow MS-Kermit Features: 1 o Full VT220 Terminal emulation including User Defined Keys. All VT220 escape sequences are supported except the down-line loadable character stuff. Insert Characters (ICH) and Erase Characters (ECH) as well as Selective Erase in Line/Display are fully implemented. Enhancements such as "turn off" character attributes are also included. 2 o Full VT102 printer port support as well as a VT240 "printer-to-Host" loop-back enables Kermit to operate as a cheap "line-monitor". 3 o Interactive (during Connect) "Hot-key" definition of any key. Keys can be assigned to ascii strings or to a "special-function). These assignments are temporary for a single connect session but do override all other key assignments except VT220 user defined keys. Over 80 special functions are provided which include all ms-kermit standard functions such as "prev screen,prev line,next screen,dump screen,print screen etc". Many additional functions have been added which can be assigned either temporarily via "connect mode help" or with the standard ms-kermit SET KEY function. This usage is upward compatible with the current 2.29 release. 4 o Kermit functions currently assigned to keys with "embedded code" can be disabled so a user can customize his kermit via SET KEY in a mskermit.ini file. An example "ini" file is included which duplicates the current "hard coded" functions. 5 o A "connect mode" interactive help section was added which contains all sorts of goodies. In fact each of the functions selectable from the "Main Help Menu" are also available as "special functions" and can be assigned to any key. The current funtions include: Show All Keys; Set Key to Special Function; Set Key To Ascii String; Special Interactive Status; Show Kermit Internal; Set File Name. Chars keyed are in reverse video, chars received in normal video. Control chars and sequences as well as escape sequences are brite. In this mode most control/escape sequences are not actually done however there are some exceptions. Down-line loaded user defined key sequences are done as well as shift keys to application mode etc.. 7 o Improved scroll buffer management provides up to 20 screens of 132 chars each. This is 480 lines of video memory and is allocated if enough free memory is available. If not enough is available then less is allocated on a line by line basis. The memory management has been improved so that it always reflects exactally what has been received. All video attributes are supported including double wide/hi stuff. If you scroll back and a character is received to be put on the screen; then the scroll management routines restore the screen before modifying video memory. The dump to printer/disk routines also handle the character set shifts required to use the Rainbow's multi-national character set and VT100 graphics. 8 o Source code has been re-organized along the same lines as the IBM version. Author: David L. Knoell Basic American Food Company PO Box 1140 Vacaville Ca 95696 [Ed. - Many thanks! The .BOO file, sample initialization file, and extensive documentation have been installed in the Kermit distribution areas as MSVRB2.* (to distinguish them from the "mainline" Rainbow version, MSVRB1.*). The program identifies itself as "Rainbow + MS-Kermit V2.29.1 4 July 86". To turn on all the new functions, you have to TAKE the file MSVRB2.INI. Unfortunately, we can't simply replace the old version, because the work done by David duplicates -- incompatibly, of course -- much work that has already been done on the next release of MS-Kermit by Joe Doupnik (yes, David and Joe have now been put in touch with each other). Since the VT-220 emulation and other improvements are so useful, this version is being released as an alternate, more or less dead-end, Rainbow MS-Kermit. It seems to work as advertised (tested on a Rainbow 100B), with one caveat: typing Ctrl-S (for instance, to give a Search command to EMACS) freezes (XOFFs) the Rainbow until a Ctrl-Q (XON) is typed. The source code for this version has been sent to Joe to see if it can be adapted to the new release.] ------------------------------ Date: Thu, 1 Jan 87 17:32:11 PST From: hoptoad!gnu@lll-crg.ARPA (John Gilmore) Subject: C-Kermit and CRLF Keywords: C-Kermit, UNIX Kermit Re: Info-Kermit Digest V5 #20 >[Ed. - We can't reproduce this problem on our 4.2BSD (Ultrix 1.1, really) VAX >750, but it's probably related to the well-known bug which inserts an >extraneous CRLF into standard output every 4096 characters (this only happens >with the -k option). There's nothing in the C-Kermit code that inserts this >CRLF, so it must have something to do with Unix's blocking. Does anybody have >an idea what must be done to convince Unix to leave out the CRLFs -- some >kind of mysterious ioctl or fnctl applied to stdout, maybe?] No such luck -- no Unix stdio that I've seen inserts CRLF's. Certainly not 4.2BSD's. What you write is what you get. Kermit *is* writing the CRLF somewhere; maybe sometime when it thinks it's writing to the user's terminal, it's actually writing to the data stream. Since under the -k option both go to standard output, this would not be hard to do. I looked in the kermit sources (though I don't run it here) and kermit seems to be using stdout for all kinds of things, e.g. printing error messages that should probably go to stderr instead. You can probably debug this using dbx to watch what is happening in the stdout buffer, e.g. "trace _iob[1]._buf" or some such. It'll be slow, since it looks after each instruction or source line, but it should catch it for you. [Ed. - We'll look again, thanks.] ------------------------------ Date: 10-JAN-1987 11:30:56 From: mfmail!nwbuts!gas@uucp.wessex Via: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK Subject: Bug in C-Kermit Keywords: C-Kermit I appear to have discovered a bug in C-kermit. We are currently running version 4C(057) but I have also tried it on (061) with the same effect. The problem occurs in sending files with file-type binary, and results in the file being truncated. If the last sequence is a multiple-character escape, which wont fit into what should be the penultimate packet, then after that packet has been sent the flag (first) says that EOF has been reached and gives up, although there is still a sequence to send. I have looked at this and the problem seems to be in ckcfns.c in the routine getpkt, but I have not yet worked out a fix. I would be grateful to know if anyone else has already fixed the problem. Gordon Scott (Micro Focus, 26 West Street, Newbury Tel - 0635 32646) [Ed. - This appears to be to be a real bug in the getpkt() function. A cursory inspection of the source shows that the solution might be as simple as moving the return() statement like this: } else if (first == -1) { /* EOF from last time? */ first = 1; /* Setup for next time. */ return(size = 0); /* <--- delete this */ } else x = 1; /* Do any leftovers */ for (size = 0; (data[size] = leftover[size]) != '\0'; size++) ; *leftover = '\0'; if (first == -1) return(size); /* <--- and add this */ This is totally unverified; reports welcome. Thanks!] ------------------------------ Date: Wed, 7 Jan 87 00:55:42 EST From: nelson@NLM-VAX.arpa (Gary Nelson) Subject: Xenix on IBM-PC/AT & SCO Xenix V Keywords: Xenix, C-Kermit, SCO Xenix In response to request for users of C-Kermit 4D061 on SCO Xenix: My configuration: IBM-PC/AT SCO Xenix Release 2.1.3 (Update E & F) CRC problems - none, all 3 block checks work fine to any system I use: IBM-PC - MSDOS, MS-Kermit v2.29 Intel 310 Xenix, C-Kermit DEC VAX 11/780 - BSD 4.3 DEC PDP-11/70, RSX11m-Plus I agree, fixed several(??) releases ago. However, the dial command did not work after updating to the release of SCO Xenix V. The following diff file corrects problem in ckutio.c that broke the dial command. Note, if you are on SCO Release 2.1.0 - DO NOT include this fix, leave the 4D061 version as released alone - it works fine. The nap() mod is not neccessary - just saw it and changed it to use an available facility. ********** start of diff file ********** 14a15,27 > /* Modification history: > > 23-NOV-86 Gary B. Nelson, Nelson Associates, Manassas, VA > As a consequence of my new release of SCO Xenix V2.1.3 > breaking kermit: > Mods to msleep to use nap(), note -> add "-lx" to > LNKFLAGS in the makefile. > Mods to tthang to make it work again, with this new release > of XENIX (symptom was that the dial command > stopped working, a problem that was incorrectly > diagnosed by ?? as seen on the usenet a few days ago). > */ > 527d539 < #ifndef XENIX /* xenix cannot do close/open when carrier drops */ 532d543 < #endif 1416,1418c1427 < #ifdef XENIX < #define CLOCK_TICK 50 /* millisecs per clock tick */ < #else > #ifndef XENIX 1420d1428 < #endif 1431a1440,1446 > #endif > #endif > > #ifdef UXIII > #ifdef XENIX > nap( (long) m ); > #endif ********** end of diff file ********** ------------------------------ Date: 16 Dec 86 17:15:00 GMT From: ihnp4!inuxc!pur-ee!uiucdcs!uxc.cso.uiuc.edu!crimmins@UCBVAX.BERKELEY.EDU Subject: Kermit and Procomm Keywords: Procomm Re: Kermit and Procomm /* Written 1:38 pm Dec 15, 1986 by vanzandt@uiucdcsp.cs.uiuc.edu in uxc.cso.uiuc.edu:comp.sys.ibm.pc */ > Would someone please explain (in full detail) to me how to get Procomm 2.4 > to do Kermit transfers. I can get Xmodem to work fine, I can get Kermit to > Kermit to work fine, I just can't get Procomm to Kermit to work... It seems that you do not have your parity set the same on both sides, or your packet lengths are not the same. On the Procomm side, I have usually selected a packet lenght of 90. My guess, however, is that the parity is set different on the two programs. Even if your host is set for no parity, your Kermit might be looking for even parity. Look at the status screen on Kermit to verify that it is set the same as Procomm. The parity on Procomm will always correspond to what you are communicating at. I have had no problems using Procomm to transfer vi Kermit to and from uiucuxc. If you need more help, contact me at the address below or call our office at 244-0608. Good Luck! Dan Crimmins University of Illinois at Urbana-Champaign Computing Services Office - Micro Consulting Dept. ARPA: crimmins@uiucuxc.cso.uiuc.edu BITNET: crimmins@uiucuxc.bitnet CSNET: crimmins@uiucuxc.csnet UUCP: {ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!crimmins ------------------------------ Date: 21 Dec 86 06:22:47 GMT From: MARKS-ROGER@YALE.ARPA Subject: ASCII uploads using Kermit on the VAX Keywords: VAX Kermit, Modems I've never been able to get an error-free ASCII upload to my local VAX; the average is an error about every 20 lines. At first I suspected Flash (would be sad, since it's a fine terminal program) but now I find the same problem with Uniterm. Even Kermit logs a zillion errors, many of which are fatal. Now I suspect my Avatex 1200 (not 1200hc) modem. Can anyone shoot down this theory for me by claiming successful uploads with that model? I should point out that I get nary an error on downloads of any kind to the ST. Finally, to those of you who are waiting for the STEDT I promised, I'll send it as soon as I get this problem licked. Thanks. Roger ------------------------------ Date: Thu 1 Jan 87 15:38:50-EST From: Eric R. Crane Subject: Kermit & DECserver 200's Keywords: DECserver We have just ordered some DECserver 200's and are wondering what special considerations we will need when using KERMIT to transfer files to Vax VMS systems over these lines. Eric R. Crane Carnegie Mellon University Computation Center Systems Software Eric.Crane@TE.CC.CMU.EDU (Arpa) R602EC0N@CMCCVB (Bitnet) [Ed. - We encountered numerous difficulties trying to get Kermit to work on Ultrix and TOPS-20 when connected through DECserver-100s (aka LAT boxes). There are many parameters that have to be set correctly, and in some cases the host's LAT service may have to be modified to allow input in bursts as long as a typical Kermit packet. In TOPS-20's case, Kermit packet sizes had to be cranked down to about 40 until this was fixed. Anyone who has experience using Kermit through the DECserver-200 (or -100) is encouraged to pass along any tips.] ------------------------------ Date: Wed, 7 Jan 87 17:43:49 PST From: gts%violet.Berkeley.EDU@berkeley.edu (Greg Small) Subject: Send/Receive Overlap Implementation Flaw Keywords: Send/Receive Overlap Apparently many Kermit implementations still have the old send/receive overlap flaw. The problem is receiving while sending a packet. The receive buffer should be cleared AFTER the current packet is sent. All implementers should check their implementations and correct them if flawed. The symptom is continuous retries while sending a file, usually resulting in an abort. The retries occur about as rapidly as data packets would be sent, e.g. once a second at 1200 baud (contrasted to 5-10 seconds for a timeout). Normally Kermit sends data packets and receives ACKnowledgements alternately. Abnormal conditions may cause the remote Kermit to send an ACK or NAK while the local Kermit is sending a data packet. Because the local Kermit did not clear its receive buffer or cleared it before sending the packet rather than after, it reads the ACK received while it was sending. This causes the local Kermit to resend the packet while the remote Kermit is replying to the previous packet, so the overlap cycle repeats until an abort or the timing is disturbed. This has an additional twist for half-duplex Kermits such as IBM ASCII 37x5 and the Series/1-4994-7171 (physically full-duplex but logically half-duplex). Because Kermit-CMS controls the channel, its ACK/NAK guarantees that the received data packet will be bad, which in turn guarantees another NAK, which guarantees another overlapped send, etc. repeating the cycle. The problem is more likely at 1200 baud where the packet takes almost a full second to send (96 chars/120 cps) and much less likely at 9600 baud where the packet takes only .1 seconds because the remote Kermit is less likely to respond in less than .1 seconds. It is also more likely for long files because the probability of the triggering event is greater. Since we could not modify all Kermit versions in the field, we modified our Kermit-CMS 2.01 to prefix 120 NULs to any NAK sent. This guarantees that the receiving Kermit will not see the NAK until after it has stopped sending. Greg Small (415)642-5979 Personal Computer Networking & Communications gts@opal.Berkeley.EDU 214 Evans Hall CFC ucbvax!jade!opal!gts University of California, Berkeley, Ca 94720 SPGGTS@UCBCMSA.BITNET [Ed. - A more concrete illustration of this problem would be helpful - which systems & Kermit versions, which one is sending & which receiving, etc. We've never seen this behavior at Columbia, with our mix of IBM (linemode and fullscreen) and DEC (DEC-20 and Unix) mainframes, MS-DOS micros, etc.] ------------------------------ Date: 8-JAN-1987 14:38:56 From: DGM1@UK.AC.YORK.VAXA Via: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK Subject: Function key map for PC Kermit Keywords: MS-DOS Kermit, Key Map Please find enclosed a comprehensible (???) function key map for ibm pc running ms-kermit 2.29 showing the vt-102 keypad. Has anybody had any thoughts on a special version for the new (looks almost like a vt1xx) pc keyboard? Cheers, Doug Doug Moncur, Microsystems Advisor, Computing Service, University of York, Heslington, York YO1 5DD janet: DGM1@uk.ac.york.vaxa :: phone 0904-430000x487/5969 **** here goes... ibm_pc/vt_102 keypad mapping for mskermit_2.29 <> +-------------------+ vt_102 equivalent for ---> | 3 | edt equivalent (U/CASE means GOLD)---> | char SPECINS | ibm keytop---------------------------> |<<<<<<<< F5 >>>>>>>| vt_102 equivalent for ---------> | 7 | edt equivalent (U/CASE means GOLD)---> | page COMMMAND | +-------------------+ +-------------------+-----------------+ | 6 | , | | cut PASTE | del_c UND_C | |<<<<<<<< F1 >>>>>>>|<<<<<<< F2 >>>>>>| | PF1 | PF2 | | gold | help | +-------------------+-----------------+ | 1 | 2 | | word CHNGCASE | eol DEL_EOL | |<<<<<<<< F3 >>>>>>>|<<<<<<< F4 >>>>>>| | PF3 | PF4 | | fndtxt FIND | del_l UND_L | +-------------------+-----------------+ | 3 | enter | | char SPECINS | enter SUBS | |<<<<<<<< F5 >>>>>>>|<<<<<<< F6 >>>>>>| | 7 | 8 | | page COMMMAND | sect FILL | +-------------------+-----------------+ | 0 | . | | line OPEN_LINE | select RESET | |<<<<<<<< F7 >>>>>>>|<<<<<<< F8 >>>>>>| | 9 | - | | append REPLACE | del_w UND_W | +-------------------+-----------------+ | | | | | | |<<<<<<<< F9 >>>>>>>|<<<<<< F10 >>>>>>| | 4 | 5 | | advance BOTTOM | backup TOP | +-------------------+-----------------+ ------------------------------ Date: Mon, 12 Jan 1987 02:28 PST From: JAJZ801%CALSTATE.BITNET@WISCVM.WISC.EDU Subject: ISIS-II Kermit/bootstrap wanted Keywords: ISIS-II Kermit Is there anyone who can provide a copy of ISIS-II (Intel MDS) Kermit on 8" single or double density ISIS-formatted diskette or a cheap and easy bootstrapping method for it. Cable specs would be appreciated for the latter, if provided. Jeffrey Sicherman JAJZ801@CALSTATE.BITNET ------------------------------ End of Info-Kermit Digest ************************* -------