SY.CHRISTINE@CU20B.COLUMBIA.EDU (Christine M Gianone) (10/07/86)
Info-Kermit Digest Mon, 6 Oct 1986 Volume 5 : Number 12
Today's Topics:
New Release of Kermit-11 Available
Another 2.29a Prerelease
Atari ST Kermit on Diskette in the UK
BOO files vs UUENCODE
Suggestions for MS-Kermit
Screen Saver Feature as part of Kermit.
MS-Kermit on 80386
Found on net.bizarre
----------------------------------------------------------------------
Date: Fri 26 Sep 86 15:31:53-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: New Release of Kermit-11 Available
Keywords: Kermit-11, K-11, PDP-11 Kermit
This is to announce Version 3.54 of Kermit-11 for PDP-11s or Pro-3xx's
running the various DEC operating systems (RSX, RSTS, RT, P/OS, etc) or
TSX+, from Brian Nelson at the University of Toledo (BRIAN@UOFT02.BITNET).
New features since the last release, 3.50 (April 1986), include:
. Command line editing and recall controlled by arrow keys. ";" and "!"
may be used to delimit comments.
. Handling of DEC multinational 8-bit ASCII text files.
. New SET FILE NAMING options.
. New SET SEND [NO]XON command, to prefix every packet with an XON to fight
pathological problems with flow control.
. Minor bug fixes and cleanups.
. Some RT11/TSX+ specific modifications:
Reduction in the size of the root for XM to facilitate running Kermit as a
foreground task.
Complete rewrite of terminal emulation, specifically to enhance the
support of the XL/XC/CL handlers. It is now completely event driven
thus performance should be improved as well as presenting a much lower
load on the CPU. It should also function better under SJ.
Restructuring buffer allocation to (1) Reduce the root size for XM, and (2)
To enable the USR to swap over buffers for SJ and FB. This will eliminate
Kermit crashing on USR requests in 95% of the cases for SJ and FB systems
with minimal background memory available (ie, many devices in the system
and/or large RMON).
Control C delivery has been improved by adding a watchdog timer to check for
control C's as RT11 does not generate an AST on control C.
The new files are available via anonymous as KER:K11*.* on CU20B and over
BITNET via KERMSRV at both CUVMA and UOFT02. The file K11INS.DOC contains
installation instructions, K11AAA.AAA is a read-me file, and K11FIL.DOC is a
(slightly dated) annotated list of the Kermit-11 files (of which there are
about 111, totalling about 3.8 megabytes in size). The file K11CMD.MAC
contains the detailed update history.
------------------------------
Date: Thu 2 Oct 86 10:10:32-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Another 2.29a Prerelease
Keywords: MS-DOS Kermit
A new copy of MSTIBM.BOO is available for testing. This one fixes a bug
with VT100/102 emulation when rubout (DEL) characters are received -- some
screen editors send these as padding, and they were erroneously causing
characters to disappear from the screen during editing. Also, display of
login script text in 8-bit ASCII even when parity is in use or display is
set to 7 bits no longer occurs. The new files are in KER:MSTIBM.BOO and
KB:MSTIBM.EXE on CU20B for anonymous FTP, or in MSTIBM BOO on CUVMA for
BITNET KERMSRV access. Thanks to Walter Bourne of Columbia for pointing
out the problems, and to Joe Doupnik for fixing them. The final release
of 2.29a should be ready in a week or two.
------------------------------
Date: 29-SEP-1986 15:06:20
From: SYSKERMIT%vax1.central.lancaster.ac.uk@cs.ucl.ac.uk
Subject: Atari ST Kermit on Diskette in the UK
Keywords: Atari ST Kermit
A colleague in our Environmental Sciences Department with an Atari 1040ST has
kindly volunteered to do some disc copying, so we're now able to supply the
ST files on Atari format discs. Anyone interested should contact us on
(0524) 65201 x 4881, or to SYSKERMIT@UK.AC.LANCS.VAX1 on JANET.
I'm afraid this offer is to users in the UK and Eire only: we can't return
calls or answer letters from other countries.
------------------------------
Date: Mon 29 Sep 86 11:57:26-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: BOO files vs UUENCODE
Keywords: .BOO files, UUENCODE
[Ed. - The following message is in response to a question from Keith
Petersen about whether BOO file format should be added to the the formats
supported by the SIMTEL20 archive file server.]
The main advantage of BOO files over UUENCODE files (except when Frank W's
trick of putting a printable character on the end of each UUENCODEd line is
applied) is that BOO files don't have blanks in them, so they don't get
truncated by mailers, BITNET file transfer, etc. Also, BOO files don't have
dots, which can cause problems when going through SMTP processes when the dot
occurs in "column 1". Also, BOO files tend to be a little more compact; both
BOO and UUENCODE use 4-for-3 packing, but BOO files also run-length encode
strings of nulls. As Keith points out, neither encoding includes error
checking; BOO files avoided that because of ASCII/EBCDIC considerations.
Both BOO and UUENCODE encodings have a distinct advantage over LZW, Huffman,
and other more efficient, but complicated, techniques: the decoding program is
short enough to be typed in and used by the average PC owner.
The BOO-file maker is written in C; BOO-file decoders are written in PC Basic,
BASICA, MASM, Pascal, and C. These programs are available from CU20B as
KER:MSB*.*.
I'm not sure it's time to design yet another "standard" printable encoding for
binary files, but here are some considerations, in case anyone is interested:
The major reason for encoding binary files printably is to allow transmission
on or through character-oriented media not designed for arbitrary 8-bit data.
In particular, encoded files should pass freely through electronic mail, should
be downloadable via dialup (possibly through public data network), and
should be easily stored on and retrieved from magnetic tape.
The encoding should be compact (to minimize time and expense of transmission)
and simple (to allow the decoding program to be small enough for an individual
to type in), and it should allow errors to be detected during "de-encoding".
Since mail is often used to transmit these files, the decoding process should
be able to skip past mail headers and find the real beginning of the encoded
file. The encoded file should begin with a distinctive header containing at
least the file's name, and possibly other attributes, and it should end with a
distinctive trailer, allowing multiple files to be concatenated (archived?)
together, and picked apart and decoded by a single run of the decoding program.
Did I say "possibly other attributes"? I think we want to avoid anything
system-dependent here. We should be shooting for a way to encode stream binary
data, not structured files. If the file is to have structure (e.g. it is a DEC
FILES-11 file, or a Macintosh application, or a VM/CMS VB-format file), then
that should be imbedded in the data itself, and the encode/decode progam must
know how to handle it.
Did I say "archived"? I don't want to raise the spectre of yet another
SQ/LIBR/SWEEP/ARC/etc/etc system. Especially not one in which (like ARC),
the "archiving" program decides on the most appropriate encoding for each
file (e.g. it would be overkill to turn assembler source into a BOO file).
But the possibility of having more than one file concatenated together at
least suggests that each file's header should contain not only the file's
name, but also the encoding technique (including none).
There should be an error detection mechanism that is independent of the
character set of the host computer. It should be possible to encode the file
on an ASCII system and decode it on an EBCDIC one, and vice versa. It's hard
to imagine how to do this in a transportable way (given the idiosyncratic
nature of most ASCII/EBCDIC translation tables), or in a way that results in
short encoding and decoding programs.
Obviously, control and 8-bit characters should be excluded from the encoding,
as well as those printable characters that are known to cause problems with
networks and mailers (space, atsign, and period spring to mind). And it
should break the file up into "lines" that are short enough (say, 64
characters?) to pass through the most restrictive line-, record-, or
block-oriented mechanisms, but that have no relation at all to the data
itself.
Here is a brief survery of some of the encoding techniques I know about:
HEX: Simple 1/2 packing into hex digits, with CRLFs inserted to break
the file up into lines. No error checking, compression, etc. Very simple
to encode and decode.
BOO: 4/3 packing, null compression, printable, no blanks or dots, no error
checking, no skipping past mail headers, single file only. Tends to survive
mail, raw download, etc., but sensitive to transmission errors.
UUENCODE: 4/3 packing, no compression, printable. Includes blanks, dots, and
atsigns. No error checking. Skips past mail headers, but tends not to
survive mail, card-oriented communication links (like BITNET), or any software
that strips trailing blanks.
BINHEX version 4 (HQX): Macintosh only; 4/3 packing, printable, no blanks.
Includes data and resource fork, allows Mac application to be fully
reconstituted (MacBinary is similar, but is not a printable encoding).
Intel Hex format (HEX, H86): Simple 2/1 hex encoding, error-checked, used
by Intel and compatible loaders.
VMSHEX/VMSDEH: VAX/VMS only. Like Intel Hex format, but includes FILES-11 FAB,
allowing FILES-11 files to be fully reconsitituted.
LZW and Huffman: These are compression, rather than encoding, techniques, but
they are often built into encoding programs. However, the decoding programs
are too long and complicated to be typed in.
All of these have their advantages and disadvantages. The tradeoffs are in
program complexity vs encoding efficiency and tranparency. Further discussion
of the subject would be most welcome, as would a "standard" in this area.
------------------------------
Date: 30 September 1986 17:03:58 CDT
From: George Wiggans <GEORGEW%UIUCVMD.BITNET@WISCVM.WISC.EDU>
Subject: Suggestions for MS-Kermit
Keywords: MS-DOS Kermit
I use Kermit extensively, but do not write code to add to it, therefore, I
wanted to suggest what enhancements I would like.
(1) I would like Kermit to assume all commands are prefixed with RUN unless
they are Kermit commands. Many times I must retype the command because I
forgot the RUN.
[Ed. - Not a bad idea; it's been suggested before. Maybe this will appear
in a future release.]
(2) A recall previous commands feature. I use Norton's DOS Editor (NDE) in
DOS which lets me recall and edit earlier commands. It uses the up and down
arrows to scroll through the previous commands.
[Ed. - You'll probably never see this, because the command parser is
supposed to be machine independent.]
(3) A Tek 4010 emulation for the IBM PC with an EGA card.
[Ed. - This may appear in a future release; several people have expressed
some interest in doing it.]
(4) A raw download from the mainframe using a 7171 terminal emulator so
yokeing the screen to the printer would work for printing files.
[Ed. - You already have this: LOG PRN. The new CMS Kermit release has the
matching feature, XTYPE, which transmits a file raw, in transparent mode,
through the 7171. You could even use this to drive a plotter.]
I am sure that you get many suggestions, but I thought that I would add
mine.
[Ed. - You're right. And one of the suggestions I get is to come up with a
version of MS-Kermit that has been stripped of all its fancy features and
is once again a compact, simple file transfer program. This is becoming an
issue not only because it's getting increasingly difficult for users to deal
with such a feature-laden program, but also because it takes up so much
space on disk and in memory. The latter is a real problem for diskless
laptop portables.]
Thanks,
George
------------------------------
Date: Mon, 6 Oct 86 09:13 EDT
From: David M Chizmadia <Chizmadia@DOCKMASTER.ARPA>
Subject: Screen Saver Feature as part of Kermit.
Keywords: MS-DOS Kermit
Our site uses Kermit as the primary communications program on our IBM PCs.
We would like to have a feature which would allow us to set Kermit to blank
the screen after so many minutes of keyboard inactivity. A command along
the lines of SET SCRNSAVE n (where n is an integer >= 0 and represents the
number of minutes of keyboard inactivity to wait before blanking the screen)
would be optimal. If anyone has implemented or is planning to implement
this feature, I would be interested in hearing about it. If not, I will try
to implement it and pass it back to this digest.
Dave Chizmadia
(ARPA) Chizmadia -at DOCKMASTER.ARPA
[Ed. - It might be a better idea to use another utility to do this.]
------------------------------
From: drilex!dricej%axiom.UUCP@harvard.HARVARD.EDU
Date: Mon, 29 Sep 86 22:06:36 edt
Subject: MS-Kermit on 80386
Keywords: MS-DOS Kermit
I know it's awfully early, but has anyone tried a recent version of
MS-Kermit (2.28 or 2.29) on a Compaq 386 yet? I have somebody who's hot
to buy one, but they need kermit...
I'd try it myself, except I'm not sure when I will get around to getting
a 386.
Craig Jackson
UUCP: {harvard,linus}!axiom!drilex!dricej
BIX: cjackson
------------------------------
Date: Sat, 27 Sep 86 16:24:46 pdt
From: Bob Larson <blarson@usc-oberon>
Subject: Found on net.bizarre
Keywords: Kermit Humor
In article <1482@bucsd.bu-cs.BU.EDU> awc@bucsd.UUCP writes:
>
>You know how I like to spend a day?
>
>When I'm not installing database managers, compilers, graphics
>packages, etc. (and then FOLDING, SPINDLING and MUTILATING them
>so they'll run on our non-standard system), I like to sit by the
>phone and wait for questions about how to use Kermit. I make copies
>for our users who have PC's, and at least half of them call for
>help. The typical conversation goes something like:
>
>"Hello, may I help you?" (In my user-friendliest voice.)
>
>In an aggrieved tone:
>"Yeah, I'm trying to use Kermit and I'm having problems."
>
>(I wait half a second to see if they'll add to that - like;
> *what* problems? No WAY!)
>
>"Yes, what exactly is the matter?"
>
>"It doesn't work."
>
>(I break a pencil between two fingers.)
>"Ah. Did you read the entry in on-line HELP about how to use it?"
>
>"Yes, but I can't get it to do aaanything!"
>
>"Did you execute the file KERMIT.EXE on your PC?"
>
>"What?"
>
>(I'm not a violent person, but I star this user in a Sam Peckinpah movie.)
>"Are you sitting in front of your PC?"
>
>"Yes."
>
>"Type KERMIT."
>
>"... Ok, I did that."
>
>"Type TAKE M-S-K-E-R-M-I-T"
>
>"... ... ... Ok."
>
>(The INI file sets baud rate, etc. and CONNECTS them to the modem.)
>"You see where it says 'Connecting to Host Computer'?"
>
>Triumphantly:
>"Yes! I got this far, and it didn't DO anything!"
>
>"Well, at this point, you're communicating with your modem, NOT with
>VPS (our system). You have to type the dial command, and your modem will
>call the campus network. Then you can sign on as usual."
>
>"OOHHHH! Let me try that!"
>
>The user types the dial command, eventually gets it right, and
>(I'M NOT KIDDING ABOUT THIS) the goddam modem starts dialing on the
>line we're talking on!
>
>I stuff my eyes back into their sockets.
>
>There are a few seconds of silence at this point, during which I draw
>blood from my palms with my fingernails, as the user's brain grinds
>and grinds and comes up with THE QUESTION:
>
>"What do I do then?"
>
>(We're almost home now, I tell myself.)
>"Well, then you just run Kermit on VPS, and you can start transmitting
>files back and forth. It works just like the documentation says it
>does."
>
>Why do I let them go at this point? I KNOW they're going to call back,
>because people who don't know that you still have to dial in even if
>you're using Kermit can't possibly transfer a file with it, but if
>I talk to them much longer, things get red and hazy, and somebody just
>might get killed.
>
>Eventually they give up, and call me again. I establish that they have
>no idea what commands to type after they sign on and run Kermit ("Yes,
>of *course* I read the documentation!"), and have them come in to see
>me. Since I don't have a private phone line, I have to borrow the line
>from the cubicle across the hall, stringing it over the corridor.
>Our Assistant Provost inevitably brushes it with the top of his head (he's
>pretty tall), and visibly wonders why *THIS* goof is still working here.
>
>I hook up the modem and show them, STEP. BY. STEP. how to transfer files.
>The mists part, and BEHOLD! I've initiated yet another user to the mysteries
>of Kermit. They clutch my hand, weep little tears of gratitude, admire my
>plaster of paris Boston Terrier (you don't want to know), and they're off.
>
>Do I sound like a hateful little misogynist weasal, looking for a little
>sympathy? Well, I am, but the point is, you'd be one too if you had to
>do this OVER and OVER and OVER! Is it any wonder I come to work at 11 am,
>smelling of soy sauce? Do you have to ask why I torture small animals in
>the evening? Why I don't wear ties in the office, but DO when I'm lying
>around at home? Shall I tell you about the time
>two people came in the same day at different times for the above described
>help, and I later discovered they SHARE THE SAME PC???!!!
>
>ARRRRGGGGHHHHHH!!!
>
>I'm going to lunch.
------------------------------
End of Info-Kermit Digest
*************************
-------