SY.FDC@CU20B.COLUMBIA.EDU.UUCP (12/31/86)
Info-Kermit Digest Wed, 31 Dec 1986 Volume 5 : Number 20
Today's Topics:
Series 1/7171 Support in NIH TSO Kermit
Speed Problem Between ProComm and Kermit-CMS
C-Kermit With Intel Xenix
Fix for Unix Kermit on SCO System V
C-Kermit and Valid Workstations
Where to Send HP-1000 Kermit Requests
----------------------------------------------------------------------
Date: Sat, 20 Dec 86 21:00:25 EST
From: "Roger Fajman" <RAF@NIHCU>
Subject: Series 1/7171 Support in NIH TSO Kermit
Keywords: TSO, MVS/TSO Kermit
One important correction to Info-Kermit V5 #19: NIH TSO Kermit does not
presently have Series 1/7171 protocol converter support. We don't have
those machines. If someone wants to send us the modification, we will be
glad to include it.
[Ed. - Oops! Sorry. It appears that reports of the death TSOS1 were
somewhat exaggerated. Volunteers? Also, note that the "other" new TSO
Kermit, expected in the not-too-distant future, should indeed support both
Series/1 (full screen) and 37x5 (linemode) style hookups.]
Also, I checked the files as they appear on KERMSRV at CUVMA, and found some
erroneous translations between vertical bars and exclamation marks. The
following files contain real exclamation points: TSNKER.ALP (just a
comment), TSNKER.DOC, TSNEDR.DOC, TSNMAC.DOC, and TSNTBL.ASM (in the
translate tables). The last one is the most serious.
[Ed. - Oops again! That's what comes from reading EBCDIC tapes on a Unix
system with 'dd'... We'll try to get clean copies of these files over
BITNET to replace the current copies. It has also been reported that
some files have U and e where square brackets ([) and (]) ought to be.]
------------------------------
Date: 1986 Dec 22 13:52 EST
From: (John F. Chandler) <PEPMNT@CFAAMP.BITNET>
Subject: Speed Problem Between ProComm and Kermit-CMS
Keywords: ProComm, CMS Kermit, Series/1
I have seen reports of the problem from a number of places now, some not
specifically mentioning the use of a 7171, but none mentioning anything
else. The implication of the latest report (in Kermit Digest #19) is clear:
ProComm needs to be fixed. However, I should add that the XON added to the
end of each packet by CMS Kermit is not essential and could be removed if
necessary. It was added as a convenience for the micro Kermit -- the rule
of thumb is: when talking to an IBM mainframe, always wait for an XON before
sending the next packet. The rule is not true for the various protocol
converters (Series/1, 4994, and 7171), but the added XON makes it harmless.
How does ProComm perform when told to wait for the XON?
------------------------------
Date: Mon, 22 Dec 86 21:26 CST
From: Wilkinson@HI-MULTICS.ARPA
Subject: C-Kermit With Intel Xenix
Keywords: Xenix, C-Kermit
I have been running 4D(061) under Intel Xenix(3.3) on an Intel 286/310
system for some time now with no problems. I used "make xenix". I also got
a clean compile/link for an older UniPlus (UniSoft System III) for 4D(061).
It is running, but I have not used it extensively. I used "make sys3".
Richard {Wilkinson@HI-MULTICS.ARPA}
------------------------------
Date: 21 Dec 86 04:30:32 GMT
From: ihnp4!killer!alleng@seismo.CSS.GOV
Subject: Fix for Unix Kermit on SCO System V
Keywords: C-Kermit, SCO Xenix, Xenix
I have some info that may be useful in trying to determine why kermit
(wermit) specifically ckuker does not want to run on Xenix sys V (SCO). I
noticed a discrepancy in the server mode prompt from any other system to an
SCO system. On most systems, the prompt is "# N3". HOwever, on Xenix, the
thing comes up "# N/". A Xenix system will talk to another Xenix system
(SCO), but cannot communicate with any other systems for protocol transfer.
The problem comes from performing functions on unsigned and signed ints.
For some reason (compiler bug), when certain operations are performed on
standard ints, the sign bit gets set (lsb in MS byte). This makes checksums
come out screwy. To resolve this, edit the module 'ckcfn2.c' (by the way,
we are talking about ckuker here) look for the function 'C K U 1'. You will
notice an 'int chk' below the function heading. Simply change it to
'unsigned int chk' and the version should work perfectly.
My thanks to all who helped isolate this... Allen
[Ed. - Hmmm... What version of C-Kermit has everyone been using? This
change was made months ago, either in 4D(061) or 4D(060). Maybe if everyone
with SCO Xenix systems tries the current version - 4D(061) - the problem
will disappear. Could some SCO Xenix users verify this??? By the way, I
think Allen meant to say 'C H K 1' rather than 'C K U 1'.]
------------------------------
Date: Tue, 9 Dec 86 16:12:13 pst
From: hplabs!valid!carolf@gumby.arpa (Carol Fernihough)
Subject: C-Kermit and Valid Workstations
Keywords: C-Kermit, Valid Workstations
I'm unclear as to where to mail bug reports regarding kermit. I'd like my
mail find its way to 1) kermit programmers at Columbia University, and 2) a
network, so that I could receive responses from other users who can suggest
fixes. Would you please forward this mail if necessary, and let me know where
I should send UUCP mail. Although I have access to kermit information via the
mod.protocols.kermit newsgroup on Usenet, I do not have permission to post to
the moderated newsgroup.
[Ed. - UUCP mail can be sent to ...!seismo!columbia!cu20b!info-kermit]
I have tested version 4D(060) of c-kermit quite extensively on Valid's
workstation, which is an S320 running 4.2 BSD UNIX. I compiled c-kermit
using "make valid".
I've found the following problems when transferring files between two S320's:
* Use of the -k option corrupts the file during kermit's transfer:
This problem also arises when transferring files between the S320 and
c-kermit (compiled using "make sys3") on the IBM PC/AT.
machineA# kermit -iwl /dev/ttys0 -b 9600
c-kermit(machineA)> connect
(log onto machineB)
machineB# kermit -ik > file.from_machineA
(escape back to machineA)
c-kermit(machineA)> send file
file -> FILE, Size 50
The text file that arrives on machineB is 52 bytes long since it has a CR LF
at the beginning of the file. Binary files are corrupted in the same manner.
Text files are corrupted when sent using the -k option with no -i option.
[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?]
* Can't use -c option
When I escape (^\c) after starting kermit on machineB, I escape out of
the kermit on machineA. This also happens when kermit is started in server
mode.
c-kermit(machineA)> kermit -cl /dev/ttys0 -b 9600 -iw
(log onto machineB)
machineB# kermit -iw
[Ed. - This is the documented behavior. When you invoke Kermit with action
commands (either protocol or connect, or both) on the command line, it acts
like a normal Unix command, i.e. it exits when done. Leave out the -c
option, and you'll get an interactive Kermit session that you can escape
back to.]
* This problem occurs randomly.
When host to host, and connected to machineB:
c-kermit(machineB)> exit
(logout from csh)
Can't get character: I/O error
[Back at Local System]
c-kermit(machineA)>
(exits directly back to kermit on machineA - should need ^\c first)
The problem also occurs randomly when machineB is running in server mode:
c-kermit(machineA)> finish
c-kermit(machineA)> connect
machineB# logout
Can't get character: I/O error
[Back at Local System]
c-kermit(machineA)>
[Ed. - This probably is caused by your ports and cables. Most likely, you've
got the systems connected by a true null-modem cable, in which one computer's
DTR is connected to the other computer's CD and/or DSR. The remote computer
may be configured to drop DTR upon logout, which would cause the local one to
sense that CD or DSR disappeared, and to return an I/O error the next time
you tried to read or write characters to the port. The Kermit connect command
exits when it gets an i/o error. Solution: trade in your true null modem cable
for a "fakeout" cable in which DTR is connected to CD and DSR within the local
connector, or reconfigure your ports to be less persnickety about modem
signals.]
* When kermit is invoked from a script command, the command line options
are ignored.
machineA# kermit -iwl /dev/ttys0 -b 9600
machineA's /.kermrc file contains:
script gin:--gin:--gin: name ssword: passwd \
machineB#--machineB# kermit~s-iwx
send binary_file binary_file.from_machineA
The attempted transfer simply times out because kermit on machineA is NOT
in server mode, nor have the other command line options taken effect.
Workaround:
Rather than including command line options in a call to kermit from a
script, put the necessary commands in the script or in the remote machine's
.kermrc.
[Ed. - This is just a guess, but maybe the '-' in '-iwx' is the culprit,
since dashes are meta-characters in uucp-style scripts. Try changing
'kermit~s-iwx' to 'kermit~s~055iwx' and see if that works.]
* Finish doesn't always work
When using a server, type finish, then connect. Kermit will sometimes
connect back to kermit on the remote machine rather than the shell on
the remote machine.
[Ed. - This depends upon whether you invoked Kermit with -x on the command
line (in which case it exits to the shell) or with the interactive 'server'
command (in which case it returns to C-Kermit> command level).]
I've also begun to test c-kermit between the S320 and the Microvax, running
VAX version 2.1. I compiled c-kermit on the Microvax using the CKVKER.COM DCL
procedure. I've found the following problems:
S320 -> Microvax
* Can't transfer binary files
Both host to host and server transfers corrupt binary files.
[Ed. - Presumably you gave the -i option or 'set file type binary' on both
ends. Have other users of C-Kermit on VMS found this to be true? I think the
problem is that VMS binary files are not simple streams but are structured
with particular blocksizes, etc. There's no code in C-Kermit to do this. I
hope somebody who's familiar with VMS and VAX-11 C will add this code, or
provide some hints or workarounds to this problem.]
* Bye doesn't work
When running kermit on the microvax in server mode, type bye, then connect.
Bye acts like finish because kermit will connect to the microvax command
interpreter prompt. At this point, type logout (which doesn't echo on the
screen).
[Ed. - Again, sounds like something to do with VMS. Maybe VMS doesn't allow
a program to log out its own job unless the program is started or configured
with some specific capability. Can any VMS experts answer this?]
* Finish doesn't work
When using the microvax as a server, type finish, then connect. Kermit will
connect back to kermit on the microvax rather than the command interpreter.
[Ed. - As in the Unix case, it depends on how the program was invoked.]
* Exit doesn't always work
Sometimes no action will be taken in response to exit. Quit always works
however.
[Ed. - That's strange, because quit is simply a synonym for exit -- both are
associated with exactly the same code.]
Microvax -> S320
* Directory doesn't work
Directory listed only one file in a directory containing several files.
* Cwd doesn't work
Cwd caused an access violation and exited from kermit.
c-kermit(microvax)> cwd
%SYSTEM-F ACCVIO, access violation, reason mask=00, virtual address=00000000,
P4
%TRACE-F-TRACEBACK, symbolic stack dump follows
module name routine name line rel pc abs pc
CKVFIO system 3233 17 15122
CKUUSR docmd 1796 1a2 12F53
CKUUSR parser 1635 182 12B69
CKCMAI main 930 BC D918
$ (could not echo - logged out)
[Ed. - Again, I appeal to VMS experts for help sprucing up the VMS-specific
functions in the CKV*.C modules.]
I also have a question. What is the reason for not reading the .kermrc file
when the command line contains an action?
[Ed. - No special reason except that the structure of the code made it hard
to do. This feature should be added in a future release.]
UUCP address: ucbvax!hplabs!pesnta!valid!carolf
Thanks!
Carol Fernihough
[Ed. - And thanks to you for your detailed reports. This is how Kermit
programs keep getting better. I hope I've answered each point
satisfactorily. If not, let me know. - Frank]
------------------------------
Date: Wed 24 Dec 86 10:56:43-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Where to Send HP-1000 Kermit Requests
Keywords: HP-1000 Kermit, Interex
Paul Schumann has been getting many requests for his version of Kermit
for the HP-1000 but is unable to provide such a service. He has asked
that in the future people please make such requests of Columbia University
or the HP User Groups since these groups are set up to do this kind of
distribution.
If anyone is interested in becoming a member of the HP User Group, the
address is as follows:
Interex
680 Almanor Avenue
Sunnyville, CA 94086-3513
------------------------------
End of Info-Kermit Digest
*************************
-------