SY.FDC@CU20B.COLUMBIA.EDU.UUCP (07/25/86)
Info-Kermit Digest Fri, 25 Jul 1986 Volume 5 : Number 4
Today's topics:
IBM PC Kermit 2.29 on Diskette in the UK
Another BASICA Program to DeBOO Kermit Files
Kermit-11, Kermit-32 and Wildcard Send
HP1000 Kermit Saga, cont'd, and MS-Kermit Filespec Parsing
Kermit with Other Terminal Emulators
Emulation Wish
Protocol Manual Potential Changes
Multics Kermit Dialout?
MS Kermit for Epson QX-16?
Kermit with Internal Hayes Modem on the Leading Edge D?
Kermit for General Automation-type Equipment?
More on BOO Files
Problem with Atari UU-encoded Files
----------------------------------------------------------------------
Date: 22-JUL-1986 11:31:21
From: Alan Phillips <SYSKERMIT%vax1.central.lancaster.ac.uk@cs.ucl.ac.uk>
Subject: IBM PC Kermit 2.29 on Diskette in the UK
Lancaster University Kermit distribution can now supply the complete set of
files for MS-Kermit 2.29 on the IBM PC on diskette. Those interested can
contact me at:
Kermit Distribution,
Department of Computing,
Computer Building,
Lancaster University,
Lancaster LA1 4YW
UK
or phone (UK) 0524-65201 x 4881
Diskette supply is offered in the UK and Eire only, and we can't return calls
to other countries. We have a complete set of Kermit files for all current
implementations on a VAX system, and these can be accessed by anyone who can
connect to us, from anywhere. Those wanting details, or who wish to receive
the UK Kermit newsletter, should mail me as
SYSKERMIT @ UK.AC.LANCS.VAX1 (JANET)
SYSKERMIT @ UK.AC.LANCS.VAX1 (BITNET)
SYSKERMIT%LANCS.VAX1 @ UK.AC.UCL.CS (ARPA)
SYSKERMIT%LANCS.VAX1 @ UKC (UUCP - UK *only*)
[Ed. - Many thanks for providing this service, Alan, and for all the
work you've done in promoting and distributing Kermit in the UK!]
------------------------------
Date: Thu, 15 May 86 23:24 EDT
From: Alan H. Holland <FEAHH@VTVM1>
Subject: Another BASICA Program to DeBOO Kermit Files
Enclosed is a BASICA program developed from MSBPCT.BAS that takes 45% to 60%
of the time that MSBPCT.BAS would take. For lack of a better name, I have
been calling it MSBPCT2.BAS. The following comparative times (in min:sec)
were done on an IBM PC XT using PC-DOS 2.1 and IBM BASICA 2.0. In CONFIG.SYS,
BUFFERS=8.
Input File Input Length Type of Disk Used MSBPCT MSBPCT2
------------ ------------ ----------------- ------ -------
MSKERMIT.BOO 47,701 10 MB hard disk 22:45 10:27
(ver. 2.27)
MSJRD5G.BOO 59,394 10 MB hard disk 22:38 12:28
MSJRD5G.BOO 59,394 360 KB floppy 24:09 13:50
[Ed. - Thanks! The program has been added to the Kermit distribution
as MSBPCT.BAA (the old one is still MSBPCT.BAS; our filenames have to be
unique within the 6.3 paradigm...)]
------------------------------
Date: 22-JUL-1986 11:44
From: PENNICK@UK.AC.AFRC.AGRI
Via: SYSKERMIT%vax1.central.lancaster.ac.uk@cs.ucl.ac.uk
Subject: Kermit-11, Kermit-32 and Wildcard Send
Users of Kermit-11(V3.51) under RSX-11M and Kermit-32(V3.1.066 ) under VMS
4.2 may be interested to note the different ways in which these two kermits
treat file version numbers. If you wildcard send multiple generations from
the PDP-11 they arrive with the same version numbers as they left with.
However if you wildcard send them back the VAX sends the latest version
first, thus reversing the generation numbers... Purge then becomes a very
dangerous command..
Cheers
Jonathan Pennick
Animal and Grassland Research Inst.
------------------------------
Date: Wed, 23 Jul 86 10:10 EST
From: <BRIAN@UOFT02.BITNET> (brian nelson)
Subject: Re: Kermit-11, Kermit-32 and Wildcard Send
Kermit-11 always strips the filename down to NAME.TYPE before sending the
name over in the F packet. Perhaps a possible alternative would be to allow
different levels of filename processing, such as a set command to (1) Remove
all but NAME.TYPE (2) To allow the version number, (3) To allow transmission
of the UIC or directory, and (4) To allow retention of the device name. I
am not suggested the actual syntax as I would like to see Kermit maintain
some sort of common command syntax.
It would be quite undesirable to default to anything other than FILE.TYPE
as many other Kermits would reject a name that included a version field.
Lastly, if the version number is sent, then what about collision on the
version number?
[Ed. - The whole business of filename transmission is quite a stumper. If
we could characterize file specifications on every possible system in some
canonic syntax to include every possible field (device, directory or path,
name, type, version, attributes, etc etc), then maybe we could have some
kind of format specification to say just which fields to transmit, how to
fill in defaults for missing fields, etc., plus a selector to tell whether
these fields, once selected, should be translated to canonic form for
transmission, or transmitted literally (e.g. between like systems)...]
------------------------------
Date: 21 Jul 86 17:39 +0200
From: W._Michael_Terenyi%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject: HP1000 Kermit Saga, cont'd, and MS-Kermit Filespec Parsing
We found the bug in the packet parsing routine of HP1000-Kermit in the
meantime; it works now with MS-Kermit V2.29 perfectly.
The old HP1000 file system allows file names starting with ? (question
mark). If you put the HP1000-Kermit in server mode, you cannot transfer such
files, because if you type GET ? on your PC AT, the help feature is
immediately invoked. Is there an easy way to disable the recognition of
question mark for help ?
[Ed. - MS-DOS Kermit always wants to give help if you type a question mark.
Since question marks can be legitimate parts of file specifications (either
as a wildcard character, or as an actual part of the name), the following
compromise was made in the Kermit-MS command parser: If you type a question
mark as the first character in a filespec field, you get help, but if you
type it in a subsequent field, it is taken literally as part of the
filespec. To enter a question mark as the first character of a filespec,
type a pound (sharp) sign (#) instead. Meanwhile, I'm sure everyone with
HP-1000's is waiting anxiously for this new Kermit program...]
------------------------------
Date: Tue, 22 Jul 86 23:57 -0200
From: Jonathan Scott <GUCJS@SEGUC21>
Subject: KERMIT with Other Terminal Emulators
I thought KERMIT was a file transfer protocol until I met KERMIT-MS V2.29
which is obviously a sophisticated terminal emulator but also happens to
have KERMIT file transfer capability. It's great, but it doesn't quite do
everything I want. I already have a terminal emulator which does... except
that it doesn't support KERMIT file transfer.
The terminal emulator which I normally use has features which I don't want
to give up, including graphics and automatic mode switching between full
screen mode and line by line mode when running with an IBM 7171. It's a big
problem switching over to KERMIT in the middle of a session because my
normal emulator is like a DM1520 Elite (for high performance because all the
control codes are 1 byte) but KERMIT emulates VT10x-type terminals and I
can't even enter the command to start the host KERMIT through the KERMIT
terminal emulator.
What I would like to see is a separate KERMIT file transfer facility which
can be used together with any other terminal emulator for a PC. I think it
would be best to have a "hot key" type switch between the terminal emulator
and KERMIT. It might not be easy, but I think it would be more helpful than
any number of special new features in the KERMIT terminal emulator, and file
transfer is after all the primary purpose of KERMIT.
The terminal emulator in KERMIT V2.29 is a very nice product and should
obviously continue to be developed, but terminal emulation is a tricky area
and it is very difficult to satisfy everyone (I know because I wrote one a
couple of years ago "sufficient for all our current needs" which has
resulted in a continuous barrage of enhancement requests ever since). What
I want from KERMIT is a reliable file transfer system without side-effects,
integrated as neatly as possible into my existing work environment - then it
would really be worth the money we don't have to pay for it...
Has anyone done any work in this area before? Does this seem feasible?
Jonathan Scott <GUCJS@SEGUC21.BITNET>
(Gothenburg Universities Computing Centre, Sweden)
[Ed. - A standalone Kermit file transfer program is not a bad idea, but
when you separate your terminal program from your file transfer program, you
have to waste a lot of time feeding them BOTH the same set of communication
parameters. Particularly tedious if you switch between different hosts a lot.]
------------------------------
Date: Tue, 22 Jul 86 13:47:46 cdt
From: dsandrsn@uxe.CSO.UIUC.EDU (David Sanderson)
Subject: Emulation Wish
A good way to provide emulation of nearly any terminal would be to build an
emulator into KERMIT that would configure itself from an entry in a
termcap-style file. What tools exist that might make this addition easier
for micro versions, like MS-KERMIT? Would performance necessarily suffer?
David Sanderson Illinois State Geological Survey
true UUCP: ...uiucdcs!uiucuxa!uiucuxe!dsandrsn (before 15 Aug.)
...wucs!wucec1!dws3014 (after 15 Aug.)
[Ed. - Ron Fowler once attempted a CP/M Kermit implementation that would do
this, but he either gave up or lost interest. Since then, nobody has picked
up the cudgel. In principle it's a great idea. At compile time, the
program only needs to know a bunch of symbols ("cleol" for "clear to end of
line", etc) and program functions associated with each symbol. These
functions could be filled in in a system-dependent way for each system (IBM
PC, Macintosh, etc). Then at runtime, the program reads a termcap file
entry for the desired terminal type (ADM3A, Concept-100, VT-102, DM2500,
etc) to learn the escape sequences associated with each symbol, plus some
global parameters like whether cursor addressing is 1- or 0-based, etc. In
practice, however, writing the code could be quite a chore...]
------------------------------
Date: Wed 23 Jul 86 18:13:17-PDT
From: Bob Larson <BLARSON@USC-ECLB.ARPA>
Subject: Protocol Manual Potential Changes
When using long packets and sliding windows together, the suggestion of
reducing the packet size (long packets section) cannot be done if a later
packet has been sent. (Unless some further protocol extention is done.)
There are also a couple of problems in the attributes system/os field:
Prime/Primos is listed both as G and M4. Tandy (J) should probably be
subdivided, TRSDOS and Disk Extended Color Basic versions of Tandy specific
Kermit exist. (Tandy seems to be migrating away from proprietary os's, they
supply Xenix, MS-DOS and Os9.) The assignment of these seems to be quite
random, UNIX and Os9 have one listing each, while cpm has 4.
The delimiter may be listed in both the type and format attribute packet if
the type is A. It should probablby only be in the format.
Encoding should have a compress 4.0 type (bits in the range 12-16 may also
need to be listed.)
Shouldn't the "1-@ (ascii 49)" be "1 (ascii 49)"?
[Ed. - Thanks...]
------------------------------
Date: Wed, 23 Jul 86 13:35 MST
From: CMRoe@HIS-PHOENIX-MULTICS.ARPA
Subject: Multics Kermit Dialout?
I'm having a real problem using Multics as a local system when dialing out
to just about anything, but most importantly to VMS systems. Kermit works
fine when dialing out of VMS, but refused to work the other way round.
The procedure is fairly simple, dial_out of multics to the VMS system over a
direct line, set up kermit on VMS in server mode. Escape back to Multics
with dial_out escape character and execute the Multics Kermit.After issuing
the command "GET" or "SEND", the Multics kermit will timeout everytime. You
can't get back to the VMS system until you quit the Multics kermit.
An alternate method was to dial_out to VMS, get kermit up, and set the
timeout period to be 60 seconds. You would then issue the Send or receive
commands and escape back to Multics, get kermit running and set it to
receive or send before the VMS side timed out. This gave a 'fatal error on
remote'. All of the parameters are set correctly. ie) sop, eop,
packet_length, parity, etc. If anyone has had this problem or heard of it a
clue would be greatly appreciated.
Cameron Roe University of Calgary Roe@UNCAMULT.MAILNET
[Ed. - I understand there are several different versions of Multics Kermit
out there, of which Columbia has only one (the original from Oakland Univ).
Maybe some versions work better than others in this, and other, respects.
Can anyone shed any light?]
------------------------------
Date: 24 Jul 1986 0906-EDT
From: Don Bach, Sysop, FIDO 18/13
Via: LCG.KERMIT@MARLBORO.DEC.COM>
Subject: MS Kermit for Epson QX-16?
I've installed the MSVCLO on my Epson. It works ok, but is a tad slow and
whenever I return to the Kermit-MS prompt, the baud gets reset to 1800. Is
anyone working on a version for the Epson QX-16?
Don Bach
P.O. Box 631
Vicksburg, MS 39180
(601)634-3163
[Ed. - Not that I know about. Anyone else? The 1800 baud bug occurs on
other systems, too, so it's probably a problem with the code itself.]
------------------------------
Date: 24 Jul 1986 21:23-EDT
Subject: Kermit with Internal Hayes Modem on the Leading Edge D?
From: Charles Davis <CDAVIS@A.ISI.EDU>
A colleague is having difficulty getting MSKERMIT V2.29 to talk to an
internal Hayes modem on his Leading Edge D machine. Are there special
configuration steps he needs to follow to make this work?
[Ed. - There are some problems with the Hayes 1200b even on real IBM
systems; there will be some fixes in the next release. The only way to
know if these fixes will also work for the Leading Edge is to try them
out.]
------------------------------
Date: Thu, 24 Jul 1986 18:26 PDT
From: "Jeffrey Sicherman" <JAJZ801%CALSTATE.BITNET@WISCVM.ARPA>
Subject: Kermit for General Automation-type Equipment?
Though I am still planning (real soon now) to do a Kermit version for the
General Automation architecture machines that I work on (Control and MIBS
operating systems), I have come across mention of an existing implementation
which apparently does not appear in the Kermit listings, possibly because it
is part of a commercial package as opposed to a separate program. The
manufacturer (or distributor?) is a company called GEI Rechnersysteme GmbH,
Aachen, West Germany. Anybody on the other side of the Atlantic know
anything about this software and its availability (or anyone on this side
for that matter) ?
------------------------------
Date: Wed, 23 Jul 86 12:58:48 EDT
From: "Roger Fajman" <RAF@NIHCU>
Subject: More on BOO Files
> [Ed. - It would have been nice to include consistency checks in .BOO files,
> but since checksums or CRCs are based on the numeric, internal
> representation of the characters, you get into trouble when going between
> ASCII and EBCDIC systems. Actually, when you use the MSBOOT.FOR/MSBPCB.BAS
> pair, there is a minimal kind of consistency check -- the length of each
> line is transmitted along with the line by MSBOOT and checked by MSBPCB.
> But you're right, you don't even get this with the MSBPCT programs. That's
> why the recommended technique is to use these bootstrapping programs to
> get a Kermit program that SEEMS to work onto your PC, and then use that
> Kermit program to get another copy of itself, with error checking, etc.]
I don't understand what you are saying here. If I use KERMSRV@CUVMA to get
a copy of a BOO file, say for a new version of MSKERMIT, I must run a
program someplace to decode that file into an executable file. Wherever I
do that, I am open to possibly not having the BOO file exactly right. It
would be helpful if the actual binary executable files were available via
KERMSRV. Then BOO files would really not be needed after the first time, at
least for those of us who have EBCDIC machines on BITNET.
As far as checksums in BOO files are concerned, if they were implemented,
they should be based on the original file. This avoids EBCDIC-ASCII
translation difficulties in computing the checksum and would usually detect
errors that were introduced into the BOO file due to translation problems.
Anyway, now that I am aware of the problems, I can watch for them. It did,
however, take me a while to figure out what was happening.
[Ed. - We've gone through several different encodings for .EXE files, and
.BOO files are simply the most recent. All such encodings have their
faults. Intel HEX format has too much storage (and transmission) overhead,
the BOO files are more compact but not error-checked, and see below about
UUENCODE. Is there another encoding in common use that is (a) error
checked, (b) compact, and (c) easily decoded? By (c) I mean can you type in
a short (1 or 2 page) BASIC program to do the job (this rules out LZW or
Huffman compression, I think). Otherwise, maybe we'll add length and
checksum fields to .BOO files, along with an internal identifier so the
decoding program knows the data is really what it's supposed to be, plus
start and end markers, maybe even an ASCII "test pattern" of the entire
character set near the beginning to allow the decoder to determine in
advance whether any mistranslations have occurred. Some day, we'll get this
right...]
------------------------------
Date: 25-JUL-1986 12:21:04
From: SYSKERMIT%vax1.central.lancaster.ac.uk@cs.ucl.ac.uk
Subject: Problem with Atari UU-encoded Files
There may be a problem with the AST*.UUE encoded files : I've had a report
that the copies I picked up from cu20b over arpa have lost trailing spaces
from the ends of some records, resulting in an unusable object file.
I don't know whether the spaces got lost on the way to me, or from me to the
user here, or whether they aren't on the cu20b files at all, but it sounds
like the sort of problem that may affect a lot of people. Perhaps the author
could modify the encoding technique slightly to end records only with
non-space characters?
[Ed. - These files came to us over BITNET, which trimmed the trailing blanks.
It's always a bad idea when encoding binary files printably to allow spaces
in the encoding. Fortunately, UU-encoded files have lines beginning with a
length field, so the right number of spaces can be restored. Below is a
little program in my favorite screwball language, SNOBOL, to do this. It
must be run on an ASCII system because length fields are ASCII values.]
&TRIM = 1
* Look for beginning
BEGIN LINE = INPUT :F(NOBEGIN)
LINE POS(0) 'begin ' :S(GO):F(BEGIN)
NOBEGIN TTY = 'No begin line' :(ERR)
GO OUTPUT = LINE
* Read encoded lines, get length, pad to that length.
LOOP LINE = INPUT :F(DONE)
OUTPUT = IDENT(LINE,NULL) :S(LAST)
LINE POS(0) LEN(1) . X :F(ERR)
&ALPHABET @P X :F(ERR)
OUTPUT = RPAD(LINE,(((P - 32) / 3) * 4) + 1) :S(LOOP)
* Blank line and 'end' line at end.
LAST LINE = INPUT :F(LAST2)
OUTPUT = IDENT(LINE,'end') LINE :S(DONE)
LAST2 TTY = 'No end line'
* Error and regular exit.
ERR TTY = 'Fatal error' :(END)
DONE TTY = 'Done'
END
------------------------------
End of Info-Kermit Digest
*************************
-------