SY.CHRISTINE@CU20B.COLUMBIA.EDU (Christine M Gianone) (01/12/87)
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 <alan@curta.columbia.edu>
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 <EC0N@TE.CC.CMU.EDU>
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
<<EXPLANATION>>
+-------------------+
vt_102 equivalent for <SHIFT+FKEY>---> | 3 |
edt equivalent (U/CASE means GOLD)---> | char SPECINS |
ibm keytop---------------------------> |<<<<<<<< F5 >>>>>>>|
vt_102 equivalent for <FKEY>---------> | 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
*************************
-------