info-kermit@ucbvax.ARPA (03/05/85)
From: Frank da Cruz <SY.FDC%CU20B@COLUMBIA.ARPA>
Info-Kermit Digest Mon, 4 Mar 1985 Volume 2 : Number 8
Departments:
ANNOUNCEMENTS -
Commodore-64 Kermit V1.3
Kermit-11 for TSX+
Getting PDP-11 Kermit by Phone
Unix Shell Script for FTP'ing Kermit Files
UNIX KERMIT -
(Next prerelease C-Kermit coming this week, watch Info-Kermit)
MS-DOS KERMIT -
MS-DOS Kermit .BOO Files and Translation Table Troubles
MS-DOS Kermit Key Redefinitions
(Version 2.28 on the way, watch Info-Kermit)
MISCELLANY -
Kermit-32 3.0 vs VMS 4.0
Turbo Pascal Kermit for MSDOS systems.
Kermit vs Sytek LocalNet 20
Kermit and TACs
Crosstalk, Kermit, and India
----------------------------------------------------------------------
Date: 20 Feb 85 17:10:37 EST
From: Eric <LAVITSKY@RU-BLUE.ARPA>
Subject: Commodore-64 Kermit V1.3
To: sy.fdc@CU20B
Version 1.3 is ready for release, along with documentation and a bootstrap
procedure for people who do not yet have Kermit. The bootstrap procedure
was written by Robert Scott Lenoil (Lenoil@Mit-XX) in CLU (available on
DEC-20s' and Vaxen running UNIX, I believe). I hope to have a Fortran
translation of the mainframe end shortly (it is really quite simple). This
version of Kermit includes the following updates and fixes:
1) Full support for 1200 baud communications.
a) Flow control, (XON/XOFF)
b) Correct setting of baud rate, correcting errors
in the standard RS232 Kernel routines.
2) File-Warning has been implemented, a la Apple Kermit.
3) VT52 emulation should work completely in 40 column mode.
This includes printing of tabs!
4) You can set the word-size for communication (7 or 8 bit)
5) You need not exit and restart Kermit to bring into effect
changes made in the communication parameters.
6) Server commands definitely work the *first* time.
Enjoy!
Eric
[Ed. - The files are in KER:C64BOOT.* (the bootsrapping procedure),
KER:C64DXL.* (the hexification program), and KER:C64KER.*. The program
itself is written in CROSS, a derivative of the PDP-11 cross assembler
which runs on the DECsystem-10 and DECSYSTEM-20 and generates code for
various kinds of micros. The bootstrapping procedure consists of a short
CLU program on the mainframe end, and a short Basic program on the C-64
end. Since most sites do not have the CLU language available, it is hoped
that a version in a more common language, like C, Fortran, or Pascal, will
appear soon (the CLU program is quite straightforward and should lend
itself easily to translation). Meanwhile, executable versions of it are
available in KB:C64BOOT.EXE (for the DEC-20) and KB:C64BOOT.VAX (for the
VAX). KB: is the Kermit-Binaries area. Note that there is also another
Kermit program for the Commodore-64 written in FORTH, which is available
in KER:C644*.*; it has no accompanying bootstrap procedure.]
------------------------------
Date: Tue, 26-FEB-1985 11:01 EST
From: <BRIAN@UOFT02>
Subject: Kermit-11 for TSX+
To: dftcu@cuvmb
I am sending a hex file for TSX+ that works. The only restriction is that
it uses virtual overlays.
brian nelson
[Ed. - The file is in KER:K11TSX.HEX.]
------------------------------
DATE: TUESDAY, 26 FEB 1985
FROM: BRIAN AT UOFT02
TO: SY.FDC AT CU20B
SUBJECT: Getting PDP-11 Kermit by Phone
I have been giving out info for people to log into my 11/70 to get current
Kermit-11's. I think I may as well publish this instead of always getting
calls about it.
Number: 419 537-4401
After carrier, hit cr until prompted with a *. At this point type 12
followed by a carriage return. Response is SERVICE 12 START. Within a
couple of seconds login will come up. Account is 254/3, no password.
Instructions follow, this is a captive account running a DCL command file
on RSTS T9.0. If you get SERVICE 12 UNAVAILABLE, try later.
This procedure will change in June 1985 as the PDP 11/70 has been replaced
by an 11/44 and a 11/785.
------------------------------
Date: Thu, 21 Feb 85 12:03:40 est
From: randy@nlm-vax (Rand Huntzinger)
To: info-kermit-request@cu20b
Subject: Unix shell script for ftp'ing Kermit programs
I have a Unix shell script (Bourne shell, sh) which, when given the prefix
of a version of Kermit, or a list of prefixes, goes out and fetches those
versions of the files from CU20B. Thus, the Unix command,
getkermit ck cpm
will start FTP, connect to CU20B, properly fetch C-Kermit and CPM Kermit and
write the files in the current directory with Unix palatable file names. It
properly changes modes from ASCII to TENEX when transferring binary files.
I've found this script very useful in keeping the relevant versions of Kermit
here up to date. I'm sure you at Columbia will appreciate that it encourages
transferring only what you need. [Actually, I think you could transfer the
entire distribution with the command "getkermit ''", but I haven't tried it]
The only problem with this script is that it depends upon a bug in the Unix
FTP program being fixed. In the vanilla 4.2 BSD ftp program, a mget (multiple
get) command issued in tenex (binary) mode fails on the directory read. We've
fixed that here, but it may not be fixed at all other sites.
The text of the script follows, you can do with it what you see fit.
[Ed. - It's in KT:UXFTP.SH. KT: is the Kermit-Tools area.]
------------------------------
Date: Thu, 21 Feb 85 14:14 EST
From: Alan H. Holland <FEAHH@VPIVM1>
To: Frank da Cruz <SY.FDC AT CU20B>
Subject: BOO Files and Translation Table Troubles
In my last note to you, I mentioned that I was having a hard time using
MSPCTRAN.BAS to turn MSIBMPC.BOO into a executable EXE file. In your
reply, you mentioned that the problem could be in a translate table
somewhere. You will be happy to know that the trouble is at my end.
MSIBMPC.BOO gets from KERMSRV thru BITNET to my account on our VM/CMS
system intact. It is when I download it to my IBM PC that it gets hurt.
At our particular VM/CMS site, there is a terrible confusion surrounding
the ASCII tilde, the ASCII carat, and the EBCDIC not characters. During
the download, the characters that were originally tilde and carat all get
turned into tilde characters. Not good, but not your problem.
I solved my problem by having KERMSRV send MSIBMPC.BOO to a VAX/VMS system
to which I have access, and then downloading the file from there. That
also allowed me to discover how the VM/CMS system was damaging the file,
by comparing versions on the IBM PC and working backwards.
--Alan Holland FEAHH at VPIVM1 on BITNET
[Ed. - This sort of thing has proved a common problem on IBM mainframes.
To this day, there is no consistent, "standard", invertible ASCII/EBCDIC
translate table. This raises the interesting question of how Kermit
packets, which themselves may contain any printable ASCII character, will
survive in such an environment (see discussions of "sacred characters" in
previous digest issues). The Kermit User Guide and Protocol manual list
the recommended ASCII/EBCDIC translations.]
------------------------------
Date: 27 Feb 85 18:05:14 EST
From: Ken Burner <KB13@CMU-CC-TE>
To: Info-Kermit@CU20B
Subject: MS-DOS Kermit Key Redefinitions
(Using Version 2.26). I have occasion to use both IBM and DEC systems
frequently. I have a long list of key re-definitions for the IBM that are
not needed on the DEC. Is there an easy way to "clear" all key bindings
to the default setting without exiting and re-running the program?
-Ken Burner
[Ed. - We'll look into putting a command into the next release to do this.
For now, the best thing is to have a key redefinition command file for
each system you want to connect to, or else keeping Kermit in a RAM disk
so that exiting and restarting isn't so painful.]
------------------------------
Date: Thursday, 21 Feb 85 11:04:34 EST
From: rmcqueen (Robert C McQueen) @ sitvxa
Subject: Kermit-32 3.0 vs VMS 4.0
To: Info-Kermit @ cu20b
The Kermit-32 processing of LOCAL commands and incoming REMOTE commands
does not work correctly under VMS 4.0. This is because Digital has changed
how DCL and mailboxes interact. This will be fixed in Kermit-32 3.1 which
we are now working on.
Kermit-32 3.1 will also fix the problem with the CONNECT command when the user
is on an RTA. This is because RTAs don't work exactly like terminals in all
respects.
It is hoped that we will be able to get this out in the next couple of weeks.
------------------------------
Date: Thu, 21 Feb 85 14:03 EST
From: VIC@QUCDN
To: sy.fdc@cu20b
Subject: Turbo Pascal Kermit for MSDOS systems.
I have written a Kermit in Turbo Pascal for IBM PC compatable computers.
It has most of the features of the current MsDos version. Why reinvent
the wheel? Why not build on the MsDos version? Although the current
Kermit-MS has an overwhelming number of features, it is lacking in two
areas which can not be corrected by adding more code. The two short
comings are ease of use and ease of modification.
A full feature Kermit written in turbo pascal can be completely compiled
within 2 mins. Compare that with the 15 to 20 minutes for assembling each
module of the KERMIT-MS. In addition pascal code is much easier to read
than assembler. I am amazed at the amount of effort and coding that has
gone into putting new features into KERMIT-MS. It must be hundreds of
man-hours of effort.
In my version of kermit, I have attempted to minimize the number of
commands and options. I have also minimize the number of keystrokes. For
example all option can be specified with just one command line. We can
also change options as we CONNECT. eg.'CONNECT 9600 Full Odd ' This will
connect modem at 9600 baud in full duplex mode and odd parity. It could be
abbreviated as 'C 96 F O'
An attempt was made to seperate the code into three areas. General
kermit code, MsDos dependent code, and hardware dependent code. I expect
I will have a CP/M version within a month for an KayproII and an Apple2E.
[Ed. - This person has been put in touch with Jeff Duncan, who recently
submitted another Turbo Pascal Kermit, but for CP/M. I hope the result
will be a common Turbo version for MS-DOS, CP/M, and maybe Apple DOS.]
------------------------------
Date: Sunday, 24 February 1985 08:06-MST
From: Jerry Lotto <talcott!lotto%harvard.uucp@SEISMO.ARPA>
Subject: Kermit vs Sytek LocalNet 20
To: Info-Micro@BRL
KERMIT can work over a SYTEK net (LocalNet 20). Some problems though. One
thing that I have found to be reliable is to set all packet sizes to 80
characters. This is especially true of the new C-Kermit and VMS KERMIT.
For MS-DOS KERMIT, receive and send packet sizes are set individually. I
also tell the C-Kermit side that I want file type binary. If I am sending
a 7-bit file the eighth bit does not get set anyway. This setup has worked
transferring a file from a UNIX machine (in server mode) using telnet to
another UNIX machine (a VAX) through a SYTEK connection to a line driver
connected to a VMS vax running "vaxnet" who in turn passed everything to
an IBM-PC AT. The transfer was a wildcard transfer of eight bit files
without quoting in both directions at 9600 baud (slowest connection, and
gave NO errors. Hats off to the KERMIT crew!)
------------------------------
Date: Wed, 27 Feb 85 14:09:34 EST
From: Brian_Borchers%RPI-MTS.Mailnet@MIT-MULTICS.ARPA
To: INFO-KERMIT%CU20B@MIT-MC.ARPA
Message-ID: <229053@RPI-MTS.Mailnet>
Our mainframe supports VT52's, but expects them to have
AUTOWRAP set on. That is, if the cursor is in column 80, and
another character arrives, the VT52 should move to the next
line and put the character there. It turns out that MSKERMIT
in HEATH-19 emulation mode doesn't do this. Is there anyway
to get MSKERMIT to do this, and if not, would it be possible
to include this feature in a future version of MSKERMIT?
[Ed. - MS-Kermit 2.26 and later respond to escape sequences from the host
to control line wrap. ESC v turns on line wrap, ESC w turns it off.
Maybe a future release of the program will include a command to control
this as well.]
------------------------------
Date: Mon, 25 Feb 85 15:49:04 EST
From: Edward Haines <haines@BBNCCI.ARPA>
Subject: Kermit and TACs
To: sy.fdc @ cu20b.arpa
Using Kermit with an InterNet Terminal Access Controller (TAC).
There are some conditions that must be met to successfully use Kermit on a
personal computer through a TAC.
Flow Control
The buffer size for a terminal port on a TAC is typically about 64 bytes.
(The size is a configuration parameter.) Since the default packet size in
Kermit is about 96 bytes it is quite likely that buffer overflow will occur.
Some possible solutions:
1. Enable flow control in Kermit on the PC and on the TAC. Many PC
versions of Kermit implement XON/XOFF flow control. In particular, the
new MS-DOS version does for the IBM PC. To enable flow control on the TAC
issue the TAC commands
@Flow Input Start
@Flow Output Start
These are usually abbreviated @f i s and @f o s. Note that flow control
is not compatible with binary mode (except see note below).
2. Make the packet size on the PC Kermit small enough to not overflow the
TAC buffer, e.g. 60 bytes. I had patched the old MS-DOS Kermit to do
this. On the new MS-DOS Kermit, there is a command to set the packet
size.
3. Increase the buffer size in the TAC. This is not usually practical
and won't be considered further.
TAC Intercept Character.
The default TAC intercept character is the AT-sign. The AT-sign is also
required by the Kermit Protocol.
Solutions
1. Have the PC Kermit automatically double AT-signs on output. This is
probably the best solution in general. This feature is available on some
PC implementations of Kermit. It is not yet available on the MS-DOS
version. [Ed. - It's available in CP/M-80 Kermit 4.0x.]
2. Change the TAC Intercept character with the command
@Intercept <decimal ASCII value>
I generally use @I 6 which sets the intercept character to Ctrl-F.
3. Put the TAC into Binary mode. This has the side effect of disabling
the Intercept character. It also will allow you to transfer binary files
without special encoding. The TAC can be put into Binary mode with the
commands
@Binary Input Start
@Binary Output Start
Some host systems allow you to engage the binary mode from the host.
[Ed. - DEC-20 Kermit has a command for this.]
There are several problems with binary mode:
Some host systems don't support it.
You lose the ability to control the TAC from the PC.
You lose the ability to do XON/XOFF flow control.
Binary Files
It is sometimes desireable to be able to transmit an 8-bit binary file
between a host and a PC. The TAC (which implements the DDN Telnet
Protocol) normally provides just a 7-bit ASCII path.
Solutions
1. Enable binary mode (if possible) as described above.
2. Enable 8th bit prefixing (if available) in both Kermits. (This is
usually done by enabling parity.)
Notes
1. You will probably get the best throughput for ASCII files by keeping
the packet size as large as possible and using flow control.
2. There is not much advantage in increasing the baud rate between the PC
and the TAC beyond 1200 baud because of the realatively long turnaround
time for the acknowledgement packet.
3. You may have problems when going through satellite hops or multiple
gateways due to the occasional very long delays. This may result in
Kermit giving up. I have also seen Kermit get into a sort of resonant
mode where it sends each packet twice but is otherwise succesful.
[Ed. - The resonating packets usually happen when one of the Kermit
programs is not capable of flushing its input buffer. See the BYTE
article for an explanation of this phenomenon. Long delays can be
circumvented to some extent by increasing the timeout interval; many
Kermits have commands to allow this.]
4. Only the first letter of a TAC command is required.
5. It is possible to set binary mode in only one direction. For example
you can set Inbound binary and retain input flow control (XON/XOFF flow is
in the opposite direction). You probably don't need outbound (input to
the PC) flow control when using the Kermit protocol.
Ted Haines
[Ed. - This file will be kept for reference in KER:DDNTAC.HLP.]
------------------------------
Date: Tue 26 Feb 85 06:30:27-PST
From: Richard H. Miller <RMILLER@SRI-NIC.ARPA>
Subject: Crosstalk, Kermit and India
To: Info-Kermit@CU20B.ARPA
Some months ago I read a few messages concerning the use of KERMIT
with Crosstalk XVI. Has anything come of this? Can one use the scripting
features in Crosstalk with Kermit protocols? If so, I'd be very grateful
for any help.
[Ed. - I have no knowledge of any progress. We gave Microstuf our
standard permission to include Kermit with their product (see
KER:COMMER.DOC), but haven't heard anything since an announcement appeared
in PC Week a few months ago.]
Now a testimonial. One of our clients is a consortium of international
agricultural research centers administered by the World Bank. This group
of centers is foremost in the field, and represents the state of the
art in agricultural research. As you might imagine, some of the centers
are located in countries without data network access. One such center
is in Hyderabad, India. During the past month, we have been using KERMIT
(version 2.27) on our IBM PCs and XTs to transfer files to and from
Hyderabad's VAX 780. It would be understatement to say that the use of
international direct dial telephone between California and India
is noisy. It's horrendous. However, by reducing the packet size and
twiddling a few other parameters, we have had very good success.
Thanks for a quality program.
Rich Miller
Telematics International
Palo Alto, CA
[Ed. - Thanks for the kind words; it's good to hear that Kermit may be
involved in actually doing something beneficial for humanity.]
------------------------------
End of Info-Kermit Digest
*************************
-------