SY.CHRISTINE@CU20B.COLUMBIA.EDU.UUCP (03/10/87)
Info-Kermit Digest Tue, 10 Mar 1987 Volume 6 : Number 7
Today's Topics:
New iRMX Kermit
Announcing Kermit for Computervision
Announcing Kermit for the TI Explorer
Announcing New FLEX Kermit for the Motorola 6809
Announcing 2 New Apollo Kermit Versions
Announcing Updated C86PRO.A86
CDC Cyber Kermit Version 3 Available Running NOS
Cyber Kermit V3 vs. THE OTHERS
Announcing a new Concurrent/Perkin-Elmer/Interdata 3200 Kermit
Long packets
Problems With VAX/VMS Kermit
VMS Kermit Bug
Occasional loss of trailing newline.
C-Kermit on an AT&T 7300?
Re: SET ETOA/ATOE in CMS KERMIT
----------------------------------------------------------------------
Date: January 23, 1987
From: Robert L. Stanis, Grinnel College, IA
Subject: New iRMX Kermit
Keywords: iRMX, Intel
Here is version 2.41 of iRMX Kermit. With version 2.41, all I/O routines
have been written using system calls so both the 534 and 544 communications
boards should work without problems. Any other communication boards should
work too, but this has not been tested here. This version is an update of
the PL/M version. The current author is still Albert Goodman.
Version 2.42 was updated for the iRMX-286 operating system at the University
of Illinois. We had previously sent them version 2.41, which runs on
8086-based machines. It may make the most sense to refer to these as
separate implementations of Kermit since they are not compatible across CPU
boards/operating systems, even though the sources are similar.
Bob Stanis
Grinnell College
Noyce Computer Center
Grinnell ,Iowa 50112
[Ed. - Since it's not really clear from this letter what we have, this new
version is being installed as KER:IRMX.*, and the old version will remain as
KER:I86KER.*. If indeed these two versions are redundant, would some kind
Intel iRMX system user please let us know?]
------------------------------
Date: Wed 19 Feb 87 12:24:16-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Announcing Kermit for Computervision
Keywords: Computervision Kermit
This is version 1.21 of Computervision Kermit, written in Fortran S,
submitted by Val Jawks, 435 CPB, Bringham Young University, Provo, Utah
84602. This version was converted from John Lee of RCA Lab's HP1000 Kermit.
The files are in KER:CVKER.*. There are two files; source and help.
------------------------------
Date: Wed 19 Feb 87 12:24:16-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Announcing Kermit for the TI Explorer
Keywords: TI Explorer Kermit, Lisp
This is Release 1.0 of TI Explorer Kermit, written in Common Lisp,
contributed by Brian Carb and Steve Ford of UNISYS Corporation, PO Box 500,
Bluebell, PA 19424. This implementation was developed as a joint effort
between Sperry Corporation and Texas Instruments Incorporated. You should
be using Sperry Release 2.1.1 or TI Release 2.1 of Explorer software. When
Release 3.0 is available, this software will probably no longer work, and an
updated version will be distributed by Sperry and TI. This implementation
has been successfully tested in conjunction with Kermit implementations for
Sperry 1100, DEC Vax, DEC 2060, and Sperry and IBM PCs (KERMIT-MS).
The TI Explorer Kermit files have been renamed and are in KER:EXPLRE.*.
Files are separated by *** FILENAME ***, and are available via FTP at CU20B
(login as user ANONYMOUS, any password) and via KERMSRV on BITNET (SMSG RSCS
MSG CUVMA KERMSRV HELP).
------------------------------
Date: Wed 11 Feb 87 11:24:16-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Announcing New FLEX Kermit for the Motorola 6809
Keywords: FLEX Kermit, 6809, Motorola 6809
This is to announce a new version of FLEX Kermit for the Motorola 6809,
written in July 1986, by Jur van der Burg, Nettelhorst 56, 2402 LS Alphen
aan den Rijn, The Netherlands. This is version 3.0, written in C (Compiled
with Introl (c) compiler)
Kermit for FLEX has its roots in the (old) UNIX version. It is enhanced in
several ways, such as data logging, server mode etc.
It should run on about any version of the FLEX-09 (tm) or SK*DOS (tm)
operating system. It requires 48K of memory. Hardware dependent things are
kept in the files FLK.H and FLIO.C .
FLEX-09 KERMIT has most of the features specified in the KERMIT Protocol
Manual.
[Ed. - The new files can be found in KER:FL2KER.*. The old files remain in
KER:FLXKER.*.]
------------------------------
Date: Wed 11 Feb 87 11:24:16-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Announcing 2 New Apollo Kermit Versions
Keywords: Apollo Kermit
This is to announce a new version of Apollo Kermit developed by Control Data
Corporation (Apollo version 2.8) and another new version (Apollo version
2.7) which came in about the same time from Gordon Sands of Marconi Space
Systems. If anyone is interested in putting ALL of these new features into
one Kermit program, please let us know. Until then, please test the new
versions.
The version (2.8) developed by Control Data Corporation implements the
protocol as outlined in the Kermit Protocol Manual, Fifth Edition. The
Kermit version is the Pascal one that Beckman Instruments obtained from
Columbia and fixed some bugs. It will now handle binary files properly.
This implementation of Kermit is designed to run as a "remote" Kermit and
therefore does not implement any of the "local" Kermit commands. Apollo
Kermit 2.8 is particularly suited for running in 'server' mode and
implements QBIN partially. 8-bit quoting is always done in this version; it
is not optional. See the Kermit protocol description where is describes the
use of 'N' and 'Y' in the QBIN field of the initialization packet.
[Ed. - The new files have replaced the older ones as KER:APOLLO.*.
KER:APOLLO.ANN is this file. KER:APOLLO.HLP contains documentation for
running KERMIT on the Apollo and communicating with an IBM-PC. There are
three source files for KERMIT on the Apollo. The source files are
KERMITB.PAS, KERMITIO.PAS, and EXISTF.C. The files are separated by:
/*----- end of file ----- */ and stored as KER:APOLLO.PAS.]
The version (2.7) from Gordon Sands of the Technical Computing Dept.,
Marconi Space Systems has added several facilities to the Apollo (Pascal)
version of Kermit. In particular, the new version can drive a screen without
Graphics Primitives. Gordon developed this to enable a user on one node to
drive an RS232 port on another, but it should also be usable on an attached
terminal (Trevor Wright's query in NEWS01V2).
The main other facilities are:
repeat count processing,
filename hashing,
RECEIVE followed by filename,
more error etc. messages to the screen and
SET TIME and TIMEOUT.
SET parameters GRAPHICS and NORMAL control whether graphics are used to
drive the screen and whether filenames are normalised.
There are further details in a revised .HLP file and in comments at
the start of the source file.
[Ed. - These files have been put in KER:AP2KER.*. Now there are 2 Apollo
versions -- APOLLO.* and AP2KER.*. The old Apollo Kermit is now in
KO:APOLLO.*]
------------------------------
Date: 16-FEB-1987 13:58:40
From: SYSKERMIT%vax1.central.lancaster.ac.uk@CS.UCL.AC.UK
Subject: Announcing Updated C86PRO.A86
Keywords: C86 Kermit
This is to announce an update to C86PRO.A86, by Chris Lock of Nottingham
University. It makes the C86 Kermit resilient to packets being echoed back
to it. Chris did it orginally for a specific implementation talking to a
specific wierd British mainframe, but this part of his code should be of
general use in all the C86 implementations.
Alan
[Ed. - Thanks! The new files have replaced the old ones in KER:C86PRO.*.
This is protocol module for CP/M-86 Kermit. If anyone wants to rebuild
the program for a particular system, this source can now be used.]
------------------------------
Date: Mon 16 Feb 87 18:18:05-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: CDC Cyber Kermit Version 3 Available Running NOS
Keywords: Cyber Kermit, CDC Kermit, CDC Cyber Kermit
A new version of Kermit is available for CDC Cybers running NOS. This
version (3.0) was developed by Steve Roseman, Lead Systems Programmer,
Lehigh University Computer Center (LUSGR@LEHICDC1.BITNET). It is derived
from the U of Texas Fortran 5 Kermit, with NOS/BE and UT2D support removed.
It contains the following new features and changes:
. Wildcard file names on the SEND command and server GET command.
. Local and permanent file SEND and server GET.
. A DIRECTORY command and server REMOTE DIRECTORY command.
. Automatic recognition of DISPLAY CODE, 6/12 ASCII, and 8/12 ASCII file
text modes on SEND. Receives 6/12 ASCII by default.
. The SET FILE-MODE command allows BINARY and TEXT file types.
. Supports repeated character compression (if the micro Kermit allows).
. Supports long file transfer packets up to 1000 characters (if the
micro Kermit allows).
. Cyber Kermit no longer affects the parity of your terminal connection.
[Ed. - The files have been named to KER:CD3KERM.*. The KER:CYBKER.* files
still remain in the KERMIT-2 directory as well, and the old version that
supports NOS/BE is in KERMIT-3. And... we expect yet another version to
arrive someday that will support NOS/VE. See message below for a comparison
of the various Cyber versions.]
------------------------------
Date: 23 FEB 1987 13:32 EST
From: Steve Roseman <LUSGR@LEHICDC1.BITNET>
Subject: Cyber Kermit V3 vs. THE OTHERS
Keywords: Cyber Kermit
Below is a comparison between the 3 Cyber Kermit versions:
CDC KERMIT V2 vs V3:
V2 advantages: Provides NOS/BE and UT2D support; removed in V3.
Slightly smaller memory requirements.
V3 advantages: More features, including long packets, wildcard file names,
repeat prefixing, DIR command and REM DIR server command,
editable HELP file.
CYBER (MANCHESTER) vs. V3:
Manchester Advantages: Much smaller memory requirements (importance reduced
by non-swap code and longer packets).
Faster (less CPU usage).
Probably slightly faster transfer rate with standard
length packets.
Some users think it is the 'greatest Kermit since
sliced bread'.
V3 advantages: See above.
Readable/maintainable code.
63 character set NOS site support (not very important).
If it was my choice, I would keep the CDC Kermit V2 for the remaining
NOS/BE sites. We can't abandon them. I would abandon the Manchester
version. It's a small, fast version, but the unreadable code and, now,
comparative lack of features, make it less desirable. Or keep it around, it
doesn't take too much food. It's up to you.
Steve Roseman
------------------------------
Date: Mon 16 Feb 87 18:18:05-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Announcing a new Concurrent/Perkin-Elmer/Interdata 3200 Kermit
Keywords: Concurrent Kermit, Perkin-Elmer Kermit, Interdata 3200 Kermit
This is to announce a new Kermit version (1.0) configured for
Concurrent/Perkin-Elmer/Interdata 3200 series Super-Minicomputers running
OS/32, by Creighton J. Miller, Department of Speech, Theatre, and
Communication Disorders, Louisiana State University, Baton Rouge, LA.
According to Creighton J. Miller:
This program has been developed and installed on a Perkin-Elmer 3210 system
with 1 Mbyte of memory, under OS32MT72, Revision 0. All program code except
for the I/O modules, has been written in "primitive" FORTRAN which should
prove to be highly portable (even to other machines) compact and fast. All
I/O utilizes system-level versatility through run-time access to PE's SVC1
I/O handler, whose operations could be easily duplicated on most other
mini's in a single added subroutine (image mode read-/write-and-proceed
calls and echoless reads).
In developing this program, much reference has been made to code from
Kermit-PE 2.0, developed by Paul Mamelka and currently available from either
Columbia University or PE-Interchange: The primary reasons for developing
PE-Kermit being a desire to enhance program size/speed/portability issues
and to incorporate binary file transfers (eventually raw transfers as
well...), plus a few added "bells and whistles" I'd had in mind.
Although no warranty of the routine is either expressed or implied, feel
free to use/distribute/alter the code at will --- so long as it is put to no
explicitly commercial applications: I think you'll be impressed by this
Kermit's relatively gentle and forgiving nature. I would be happy to
exchange information, comments or just pleasantries with those of you who
find some use for the logic.
A complete set of installation/development/message files is included
with the code, as an aid to fellow-travelers on the road to intersystem
communications. They'll work as-is on a properly prepared 3200 series PE
system; properly prepared meaning in this case, OS32MT72.0 or higher OS and
BIOC with an enabled, 80 byte (minimum) typeahead cue, plus the sysgened
MASK=X'FF' option. Please note that the interactive message file,
KERMIT.HLP, is an IN-dexed file with an 80 character record length, and
holds binary information. Each line is structured as follows;
1. BYTES 00-03 => length in bytes (binary) of the
message line which follows
2. BYTES 04-[length+4] => message line, in image
form.
Program size ranges from 22k bytes, using FORT7-O, through 25k bytes,
using FORT6 (you'll need assembly access to OS/32 7.2.0's SVC1, like that
included in SYS7IO.FTN), to about 38k bytes, using FORT7-D. You will
discover SIGNIFICANTLY enhanced response times for the program with the
optimizing compilers.
Transfers have been accomplished between both a PE-3210 and a PE-8/32
(as Hosts) and Zenith Z-148 (4.7 and 8 meg clocking), IBM XT, IBM AT and
Kaypro 2000 Pc's, at baud rates ranging from 300 through 9600, over
dedicated and modem links. These have been used for both ASCII and BINARY
data, with full-sized packets (94 bytes). MS-Kermit 2.26 was the usual
Caller routine, but MS-Kermit 2.28, and Procomm 2.1 and 2.3 have also been
used (Procomm 2.1 has quirks which effectively prevent binary transfers).
[Ed. - These files are in KER:PE2KER.*. The old files are still in
KER:PERKIN.*; if anyone can demonstrate why we should keep the old version,
or can say definitively that this new one can replace it, please let us
know. Our Kermit tapes runneth over...]
------------------------------
Date: 1987 Feb 20 09:38 EST
From: (John F. Chandler) <PEPMNT@CFAAMP>
Subject: Long packets
Keywords: Protocol Extensions
One of the concerns in sending long packets is that the communication link
may suddenly change in such a way that the agreed-upon packet size becomes
unsendable. Since checkpointing the I/O on the source file may be awkward
or impossible, the recommended procedure of error recovery by resending only
about half of the failed packet requires a method for cutting the packet
buffer without separating a prefix byte from its suffix. I offer the
following algorithm for finding a suitable cutting point. Assume here that
'#', '&', and '~' are the Control, 8th-bit, and Repeat quote characters and
that M is the desired index into the packet buffer BUF. I use 'ne' for the
Not-equal operator.
1. N = M
2. Go to 5
3. N = N - 1
4. N = N - 1
5. If BUF(N) = '#' then go to 4
6. If BUF(N) = '~' and BUF(N+2) ne '~' then go to 3
7. If N > M - 5 or BUF(N+1) ne '#' or BUF(N+2) ne '#' then go to 10
8. N = N + 2
9. Go to 7
10. N = N + 1
11. If BUF(N) = '#' then return (N+2)
12. If BUF(N) = '~' then return (N)
13. If BUF(N) = '&' then go to 10
14. Return (N+1)
Note that if 8th-bit or Repeat prefixing is turned off, the tests in step 13
or in 6 and 12 would fall through. Also note that steps 7-9 take care of
multiple quoted-control-quotes (if Repeat prefixing is off), but that the
repeat count threshhold will have to be set at 4 (at least for characters
that do not require any other prefixing) in order to avoid another possible
run-back in steps 3-6.
John
------------------------------
Date: Tue, 24 Feb 87 16:30:32 CST
From: "Jeff Balvanz" <GR.JLB%ISUMVS.BITNET@wiscvm.wisc.edu>
Subject: Problems With VAX/VMS Kermit
Keywords: VAX/VMS Kermit
We have been having some problems with VAX/VMS Kermit here at ISU and I'm
wondering if anyone can offer some advice. Here are some of the problems:
1. When uploading to VAX from MS-Kermit 2.29 (Zenith Z-158) using an
eight-bit communications line, SET PARITY NONE on both ends usually results
in 16 retries and no packets sent. Setting parity to EVEN on both ends
causes a file to be uploaded, but often with repeated characters in the file
(as in "This is a miiiiiiiiiiiiiiiiistake.") making the upload unusable.
However, setting the parity back to NONE on both sides after an unsuccessful
upload at EVEN sometimes results in a successful transfer. It drives us
nuts because sometimes no parity works just fine, and some files will
transfer successfully with EVEN parity. The files that give repeating
characters are normal text files, and it is (to me, anyway) impossible to
determine any difference between the files that work and those that don't.
However, a file that doesn't work once usually will repeat the behavior.
2. Downloading files with FORTRAN carriage control to MS-Kermit 2.29 (or, I
suspect, any other local Kermit) results in the message "Illegal file type"
from VMS Kermit. APPENDing the file to a normal file created with the
CREATE command causes it to download just fine. According to the source
code this was supposed to be fixed in VMS Kermit v 3.2.
We are running VMS version 4.5 and VMS Kermit version 3.2.076, just
assembled from MACRO source gotten from Columbia over BITNET since the VMS
upgrade. Any suggestions? I'd be happy to correspond with someone over
BITNET if it will help.
Jeff Balvanz
Manager, Microcomputer Services
Iowa State University Computation Center
GR.JLB@ISUMVS.BITNET
------------------------------
Date: 19-FEB-1987 13:34:51
From: PG_HARE@UK.AC.OPEN.ACS.VAXA
Subject: VMS Kermit Bug
Keywords: VAX/VMS Kermit
Help!
Kermit 3.2.077 keeps crashing out when I use it. I eventually tracked down
the problem to be tied up with the length of the filename involved; rather
than there being something wrong with the file itself.
If the filename is 'too long' Kermit crashes out with an access violation.
This is demonstrated by the two examples below. In the first, I have used a
short-cut to specify the file I want to send, in the second the full file
specification is given.
Paul Hare
PS. This problem is critical where we are concerned since the file transfers
that are causing Kermit to crash are under the control of a third-party
application package; so nothing can be done to avoid long file names.
[Ed. - Thanks for the report. We've sent it to the VMS Kermit authors.]
------------------------------
Date: Mon, 19 Jan 87 09:50:36 PST
From: rutgers!lll-lcc!cae780!videovax.TEK.COM!stever@columbia.edu
Subject: Occasional loss of trailing newline.
Keywords: C-Kermit, VAX Kermit
I have run into an occasional problem with C-Kermit dropping the last
character in a file. This was first observed in old versions of C-Kermit
running on our VAX (a "beta release" from sometime in the Spring of 1985)
and on my Amiga (an early hack of unknown pedigree). I had hoped this
problem would go away with version 4D(060), which we are now running on the
VAX and I am using on my Amiga. Unfortunately, the problem still exists.
In Info-Kermit Digest V6 #1, Gordon Scott reported discovery of a bug
that may be related (I don't know how newlines are transmitted).
The description Gordon gives is consistent with the apparently random
nature of the problem I encounter, although my transfers are in text mode.
An occasional file will lose the trailing newline. If the newline is
appended and the file transmitted again, the newline is again lost.
However, not all trailing newlines are lost. Most files are transmitted
without problems.
[Ed. - Thanks, we'll take a look at all the evidence you've gathered, and
hope we'll home in on the problem & fix it.]
------------------------------
Date: Thu, 26 Feb 87 12:28:40 PST
From: zz1ml%sdcc3@sdcsvax.ucsd.edu (Michael Laver)
Subject: C-Kermit on an AT&T 7300?
Keywords: C-Kermit, AT&T 7300
Has anyone had any luck creating a C-Kermit for the AT&T 7300 (the "Unix
PC"). Both "make sys3" and "make sys3nid" leave me with the error message
Stop. Don't know how to make chcdeb.h
I downloaded the shar files to an IBM PC, read them into the 7300, and
converted the case of the filenames.
Any help would be appreciated.
--Mick Laver
laver@sdcc3.ucsd.edu
[Ed. - The real name of the file is ckcdeb.h, not chcdeb.h -- could that
be the problem???]
------------------------------
Date: 1987 Mar 2 13:17 EST
From: (John F. Chandler) <PEPMNT@CFAAMP>
Subject: Re: SET ETOA/ATOE in CMS KERMIT
Keywords: CMS Kermit
The proposal of having more than two ASCII/EBCDIC tables is not a new
one. The following diagram shows the various translations a file must
undergo in sending and receiving and why Kermit could logically maintain
four tables instead of two in an IBM mainframe environment.
* *
File ---> Buffer ---> Packet ---> Buffer ---> TTY (Sending)
ETOA ENCODE ATOE sys
1 2 3
* *
TTY ---> Buffer ---> Packet ---> Buffer ---> File (Receiving)
sys ETOA DECODE ATOE
4 5 6
Nonetheless, only two tables should suffice in practice, given the
following assumptions:
1. System tables 3 and 4 are invertible for all codes of interest,
2. tables 3 and 4 are mutual inverses for all ASCII codes 32-126 plus
at least two different control characters (such as SOH and CR), and
3. the media marked with asterisks (*) above have only 7-bit data.
Bear in mind that the original reason for allowing the user to modify
Kermit's translation tables was to adapt to operating systems with
peculiar tables 3 or 4, not to permit extended 8-bit ASCII fonts. In
any case, tables 2 and 5 must be the inverses of 3 and 4, respectively,
but, since Kermit uses 7-bit ASCII for making packets, the second half
of table 2 is unused and, thus, might as well be the same as the second
half of table 6. As long as tables 3 and 4 are inverses, I see no reason
why the "used" half of table 2 (which equals the first half of table 4)
should not also match the first half of table 6. In other words, the
system tables should accurately reflect the local standards for
7-bit-ASCII-to-EBCDIC conversion. The same line of reasoning also leads
to the conclusion that tables 1 and 5 can be identical. Half of each
table is invariant at a given installation, being anchored in the local
definition of 7-bit-ASCII-to-EBCDIC, but the other half is free for
tailoring to any purpose -- there could be separate definitions of
8-bit-ASCII codes for different target machines. Suppose that one or
more of the above assumptions are false:
1. If table 3 (or table 4) is not invertible, then Kermit can't work.
2. If tables 3 and 4 are not inverses, then Kermit must have four
different tables after all. Are there, in fact, any installations
where this is the case? If so, why can't the tables be rationalized?
3. If an installation provides 8-bit data lines, then tables 3 and 4
are entirely filled, and tables 2 and 5 are entirely invariant, but
only if Kermit tries to use 8-bit codes in packets. Are there, in
fact, any installations where this is the case? If so, then is the
gain in efficiency from using 8-bit codes (for text) really worth the
trouble of maintaining separate translation tables?
------------------------------
End of Info-Kermit Digest
*************************
-------