Columbia Kermit/kermit.zip/e/mail.86b

Text File | 2020-01-01 | 359KB | 8,021 lines

14-Jul-86 11:58:35-EDT,11600;000000000000
Mail-From: SY.CHRISTINE created at 14-Jul-86 11:57:35
Date: Mon 14 Jul 86 11:57:35-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #1
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Mon, 14 Jul 1986       Volume 5 : Number 1

Today's Topics:

                     Kermit Now Available for Atari ST
                      Info-Kermit-Request ID confusion
                           PDP-11 Kermit Binaries
                        Using VMS Backup with Kermit
                        Swedish characters in Kermit
                      RE: Swedish characters in Kermit

----------------------------------------------------------------------


Date: Thu 3 Jul 86 15:37:22-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit Now Available for Atari ST
Keywords: Atari ST Kermit

This is to announce Kermit for the Atari ST series of personal computers,
contributed by Bernhard Nebel, Technische Universitaet Berlin
([e-mail]).  The program is written in DRI C, and is based upon
the OS9 version of Kermit, which was in turn based on the original (simple)
UNIX Kermit.  The program transfers text and binary files, can do wildcard
sends, and includes the necessary settings for communicating with IBM
mainframes (parity, handshake, 8th-bit prefixing).  IBM communications is
one major advantage of this program over the Kermit program that DRI has
been distributing with their GEM developers kit (and which they never
submitted to Columbia Kermit Distribution), and another is that this one
(unlike DRI's) actually employs the GEM user interface.

GEM Kermit does not provide a terminal emulator, nor does it manipulate
RS-232 parameters itself.  Instead, it relies on existing accessories from
the desk menu to supply these functions.  Bernhard has also supplied a
special IBM line-mode terminal accessory.

The source consists of C and header files, and there are also some
"uuencoded" binary files for the Kermit program itself and various
accessories and resource files.  As originally submitted (via BITNET mail),
the file names had the prefix ST, but since that prefix was already in use
for Software Tools Kermit, I changed the names of the files from STK*.* to
AST*.*.  In most cases this was a simple string replacement, but STKERM.*
became ASTKER.*.  Also UUENCODE.C and UUDECODE.C became ASTUUE.C and
ASTUUD.C, respectively.  I also changed (I hope) all internal references to
these filenames accordingly.

The files are available in KER:AST*.* on CU20B via anonymous FTP on the
Internet, or on BITNET from KERMSRV at CUVMA, and should appear within a
reasonable amount of time at Oklahoma State for UUCP access.  ASTKER.DOC is
the documentation (in English), which includes installation instructions.

------------------------------

Date: Fri 11 Jul 86 13:50:11-EDT
From: Ken Rossman <[e-mail]>
Subject: Info-Kermit-Request ID confusion
Keywords: Info-Kermit-Request

My apologies to those of you who sent mail to Info-Kermit-Request and got
it bounced back to them with a "No such directory" error.  We have been
moving files and directories around on the system lately, and the
redistribution list to which "Info-Kermit-Request@CU20B" points was moved
along with everything else, but the list was not updated.

It is fixed now.  Sorry for any inconvenience.  /Ken

------------------------------

Date: Mon 7 Jul 86 14:08:20-EDT
From: Frank da Cruz <[e-mail]>
Subject: PDP-11 Kermit Binaries
Keywords: PDP-11 Kermit

For those who are able to transfer files from CU20B using FTP or NFT,
and who need the latest release of PDP-11 Kermit (for RSX, RT, or RSTS),
the 8-bit binary .TSK or .SAV images are now available in KB:K11*.*.  These
are considerably smaller than the .HEX files in the main distribution, and
require no postprocessing.  Thanks to Brian Nelson for sending them in on
diskette.

------------------------------

Date: Thu 10 Jul 86 09:19:47-EDT
From: Frank da Cruz <[e-mail]>
Subject: Using VMS Backup with Kermit
Keywords: VMS Kermit

Apparently, VMS Backup cannot create a saveset on disk with a blocksize
of 512, which is the blocksize used by VMS Kermit when you give the
"set file type fixed" command.  To remedy this situation, Gary Stebbins of
DEC wrote a little procedure for converting VMS Backup savesets to and from
blocksize 512, to allow these files to be transferred with Kermit.  Use of
Backup in this way permits convenient transfer of a group of unlike or
complex files in a single Kermit operation, such that all their FILES-11
and RMS attributes are preserved after transfer.  Thanks to Bernie Eiben for
sending it in.  The files are in KER:VMSBAK.DOC and KER:VMSBAK.BAS.

------------------------------

Date: Mon 7 Jul 86 19:32:24-EDT
From: Frank da Cruz <[e-mail]>
Subject: Re: Swedish characters in Kermit
Keywords: Swedish characters

[Ed.- This is in response to those of you interested in getting Swedish
characters on your screen during terminal emulation using Kermit.]

Unfortunately, there's no "standard" version of Kermit that will display
Swedish characters on the screen, because there's no commonly accepted way to
represent Swedish (or Norwegian, or Finnish, or German, or Spanish, or Hebrew,
or...) characters in 7-bit ASCII.  Old versions of IBM PC Kermit (the current
version is 2.29) have been modified to display Swedish characters from a
special font when certain 7-bit ASCII characters are received, but so far there
is no good, general solution to this problem, because of the lack of standards
(or more precisely, the lack of conformity to existing ISO standards).  The
best person to ask about this would be Per Lindberg at the University of
Stockholm (Per_Lindberg_QZ@QZCOM).  He advocates the use of a special console
driver to map between US ASCII and Swedish (or any other) characters.
Unfortunately, doing it this way would interfere with Kermit's built-in VT102
terminal emulation; the only way to get IBM PC Kermit to show Swedish
characters on the screen is modify the program.  But then how do you make the
Norwegians, Finns, Germans, Spaniards, and Israelis happy?  And then what about
the Turks, Russians, Armenians, Japanese, Cherokee, etc etc?

Since it is undesirable to modify the Kermit program for each new "national"
character set to be supported, a better solution might be to adopt a new
mechanism usable at runtime, something like the key redefinition mechanism
(SET KEY).  But such a mechanism would probably be somewhat complicated,
because different systems use different methods to transmit "national"
characters:

(a) Selected 7-bit USASCII characters are redefined, for instance left
square bracket "[" might come out as an umlaut-A on a Swedish terminal.

(b) 8-bit codes are used to represent the national characters.  This might
follow some proposed standard, or it might be completely system dependent
(the IBM PC or DEC Rainbow have built-in 8-bit characters, totally different
from each other).

(c) A shift-in/shift-out sequence might be used to switch between character
sets.  This could correspond with the VT100's ability to switch in and out of
the alternate character set ROM, triggered by ESC ( 1, ESC ( 2, etc.

If anybody knows about a good, general solution to this problem that does not
require the program be modified for every new character set, please speak up.

- Frank

------------------------------

Date: 08 Jul 86 19:39 +0200
From: [e-mail]
Subject: Re: Swedish characters in Kermit
Keywords: Swedish Characters

**KERMIT, IBM PC and national characters.**

Yes, there *is* a standard way to represent national characters with a
7-bit code! Instead of adding more bits, the trick is to shift between
several character sets. The ANSI standard X3.41 escape sequence "SCS"
(Select Character Set) which is implemented in the VT100 and VT102
does this. ANSI X3.41 is related to ANSI X3.64, on which the VT100 is
based. This scheme is also an ISO and SIS (Swedish Institute for
Standards) standard. I suggest that you look up SIS 63 61 27 (ISO ESC
2/8 4/0 and ISO ESC 2/8 4/7 and ISO ESC 2/8 4/8).

My VT100-workalike can shift between vanilla ASCII and SIS using the
ESC ( A, ESC ( B etc. scheme. The characters [ \ ] { | } are umlaut
A:s and O:s (upper & lower case) on the keyboard, and the ANSI ESC
sequence shifts what the screen shows. There is a *big* difference in
difficulty learning which is what: I know without thinking which key
to hit for a left square bracket, but reading a C program with that on
the screen is awful. So I just switch what the screen shows, and no
problem.

BEGIN <flame>

wThe *problem* is IBM, who choose to use a non-standard 8-bit code for
representing national characters. Foo! ALSO they have the WORST
keyboard in history, with *both* USA and Swedish layouts. Double foo!
(They are different, [ is an upper-case letter, so we want it shifted).

END <flame>

To live with this problem, all communications software on their PC has
to talk 7-bit codes with the port and 8-bit codes with the screen and
possibly also with the keyboard. Your (a)-(b)-(c) scheme is sound. To
do this, I suggest you give KERMIT a character translation table for
I/O to COM:, and another table for keyboard layout. This, I beleive,
would solve the problem for all languages on the PC, be they Swedish,
Hebrew or whatever. The tables should be written in assembler (using
MACROs?), and linked with KERMIT giving an .EXE file which works on
swedish-modified PC:s. (Swedish keyboard layout, the right 8-bit codes
to the screen, the corresponding 7-bit codes to/from the port). Thus
nationally flavoured KERMITs can be distributed. (A luser can't hack
and link it, we have to do it and distribute diskettes, which we do
anyway).

The console driver I have been talking about is not a good solution.
However, IBM puts out a program called KEYBSV (KEYBNO for norway etc)
with *all* swedish PC:s which (I think) remaps the BIOS keyboard
driver. But since KERMIT reads the keyboard the hard way (?), this
won't help. (And you don't want to send 8-bit codes to the port!) I
have heard rumours that IBM has a paper with recommendations for
nationalizing software, have you seen it? (I have not). Do try to get
a copy of it, if it exists.

By the way, if you are implementing VT100 in KERMIT (which I think is
a very good idea), you might want to test it with my VTTEST program
which tests all features (and a few bugs...) in a VT100 (VT102). The
program is written in C, and runs under TOPS-10 and Twenex (Sargasso
C) and UNIX. If you don't already have it, I'll send it!

        -- Per Lindberg ([e-mail])
                        QZ - Stockholm U. Computing Center
                        Box 27322
                        S-10254 Stockholm
                        Sweden
                        + 46 8 654500
                        ...enea!suadb!lindberg

        (Im am not with the University of Stockholm, but the Stockholm
        University Computing Center, which is another organisation).

------------------------------

End of Info-Kermit Digest
*************************


-------
18-Jul-86 12:09:47-EDT,31929;000000000000
Mail-From: SY.CHRISTINE created at 18-Jul-86 12:07:51
Date: Fri 18 Jul 86 12:07:51-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #2
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 18 Jul 1986       Volume 5 : Number 2

Today's Topics:

                   Additional BITNET Kermit File Access
                         Amiga Kermit Bootstrapping
                      Extra-Long Packets Specification
                KERMIT Transfer Rates with File Compression
                  MS-Kermit 2.29 Memory Contention Problem
                   Rosetta Stone for MS-Kermit and VT100
                             A Wish List (long)

----------------------------------------------------------------------

Date: Tue, 15 Jul 86 06:19 EST
From: <[e-mail]> (brian nelson)
Subject: Additional BITNET Kermit File Access
Keywords: KERMSRV at Uoft02

Usage of [e-mail]

There is a bitnet server for Kermit files at the node Uoft02. The 'user' is
called KERMSRV and is accessed in the following manner:

from VM/CMS:    CP SMSG RSCS MSG UOFT02 KERMSRV DIR
                CP SMSG RSCS MSG UOFT02 KERMSRV SEND K11*.*

from VMS Jnet:  $ SEND KERMSRV@UOFT02 SEND K11*.*

Please note that any filespec containing wildcard characters will be queued
for a deferred transmission; please do not override this by submitting
multiple requests.  Also, there is no point in sending requests that involve
CUVMA or CUNYVM in the routing. If the traffic is too high, there is a
possibility that requests could be deferred to the next day.

We are connected to Ohio State via 9600 line, then to PSUVM which goes
to CUNYVM when I send you mail. Most of the european traffic seems to go
from PSUVM to GWUVM and then out to EARNET. Anyway, I think we want to
avoid routing that involves CUNYVM. Sorry, if we were farther west then
this thing would be more useful.

The commands are (in Jnet format)

        $ send kermsrv@uoft02 dir FILESPEC
        $ send kermsrv@uoft02 send FILESPEC
        $ send kermsrv@uoft02 vmsdump FILESPEC
        $ send kermsrv@uoft02 help

The 'VMSDUMP' command can be used to avoid EBCDIC translation, thus if you
are running jnet on your vax you can request Kermit-11 binary files.

[e-mail]

[Ed. - Thanks for the information Brian!]

------------------------------

Date:  Wed, 16 Jul 86 16:22 N
From: <[e-mail]>
Subject: Amiga Kermit Bootstrapping
Keywords: Amiga Kermit, Bootstrapping

As I tried to install the Amiga Kermit I found out there was no real
solution for the bootstrap procedure: How could I get the CKIBOO.BAS and
CKIKER.BOO files on our Amiga?

One of the problems was, that if I used a simple BASIC program, buffer
overflows occurred and there was no reliable stop criterium.

That's why I wrote two programs, one for our Vax and one BASIC program for
the Amiga which can do the job.

W. Maessen
Agricultural University,
Wageningen, The Netherlands

P.S.

I didn't have the time to create a composite program which combines
CKIBOO.BAS and this Amiga Basic program, but it sure would save some time.

[Ed. - Thanks!  The programs are listed in the file KER:CKIBOO.MSG.]

------------------------------

Date: Thu 17 Jul 86 13:19:44-EDT
From: Frank da Cruz <[e-mail]>
Subject: Extra-Long Packets Specification
Keywords: Extra-Long Packets, ELP

Recent technological advances have brought high-speed, error-correcting
asynchronous dialup modems into the marketplace, and it won't be long until
they are affordable by ordinary mortals.  The first question some people ask
when they learn of these of these devices is whether their error-correcting
capability has made Kermit obsolete.  The answer is an emphatic no, for at
least two reasons.  First, although error-free transmission may be guaranteed
from modem to modem, it cannot be assurred between modem and computer.
Second, even when the connection between computer and modem is clean, problems
of file delimitation, file representation, and computer-to-computer
synchronization are not solved by these modems.

When new communication technologies provide high-speed, potentially error-free
paths, then file transfer performance is unreasonably hampered by Kermit's
short packets and its stop-and-wait operation.  But (you ask) won't the long
packet extension solve this problem?  Perhaps, for some modems.  But others,
already on the market, will not perform at their peak unless they handle data
in bursts even longer than the 9024-byte maximum provided by this extension.
One such modem, operating in half duplex, wants data in chunks of at least
16K-20K, and others may need even more.

Successful transmission of very long packets, especially at high speeds,
requires effective end-to-end full duplex flow control.  When modems or other
intermediate devices are involved, each device along the chain must be able to
control the flow of data from the devices "upstream."  For instance, if the
receiving computer cannot keep up with arriving data, it must be able to stop
the modem, and when the modem's buffers approach fullness, it must stop the
other modem, which in turn must be able to stop the sending computer, all
without loss of a single byte of data.

But given a virtually error-free path with reliable end-to-end flow control,
Kermit's maximum packet length can be further increased by employing a second
kind of extended header, which is just like the long-packet (LP) header, except
with a 3-byte, rather than 2-byte, extended length field.  The presence of a
3-byte length field is signalled when the LEN field of the packet indicates
(after decoding) a length of one.  The DATA field of such a packet begins with
an extended header in which the first three bytes are the 3-digit base-95
length, and the 4th byte is the header checksum.  This allows for lengths up to
857,374 (95 cubed minus 1).

To ensure that this extension is compatible with Kermit programs that are
unaware of it, we must include it in the negotiations.  Rather than extend the
capability mask into a second byte, we take over one of the reserved bits, and
assign capability #2 (bit 4 of the first capability byte, corresponding to a
value of 16) for extra-long packets (ELP).  The rest of the initialization
string stays the same, but the interpretation of the MAXLX1 and MAXLX2 fields,
which appear at CAPAS+2 and CAPAS+3 respectively, is different.  If the ELP
capability bit is set (regardless of the setting of the LP bit), then the
2-digit base-95 quantity given by MAXLX1 and MAXLX2 should be multiplied by 95
to obtain the intended length.  In other words, MAXLX1 is the "9025's place"
(rather than the 95's place), and MAXLX2 is the 95's place (rather than the 1's
place).  For instance, if the maximum length is to be 30,000, the encoding
could be "#>" (3x9025 + 30x95 = 29,925) or "#?" (30,020).

As with regular long packets, the file receiver tells the sender the maximum
length packet to send.  But now there are more possibilities, since either
Kermit program may support one or the other or both (or neither) long packet
extension.  If the receiver does not support LP or ELP, the sender will send
only normal packets (NP).  If a Kermit program supports ELP, then it should
also support LP, so that it can fall back to LP rather than to NP when the
receiver supports LP but not ELP.

The interesting case arises when the sender supports only LP, but the receiver
supports both LP and ELP.  If the receiver puts the ELP maximum length in
MAXLX1 and MAXLX2, then the sender (which is unaware of the ELP extension) will
interpret these numbers as the LP maximum length, 95 times smaller than what
the receiver intended.  But since the sender goes first in the negotiation, the
receiver sees that the sender does not have ELP capability, and in this case it
can specify a suitably large LP maximum length (like 9024) in its own
initialization string, rather than an ELP maximum length that the sender would
misinterpret.  Without this trick, fallback would occur to a much smaller size.

A few final words of caution are necessary.  First, the longer the packet, the
more rigorous the required error-checking technique; it would be unwise to
transmit packets of thousands of characters guarded by anything less than a
16-bit CRC.  Second, extra-long packets are untried as of this writing; even if
the technique works, performance might be disappointing if the implementation
follows the straightforward path suggested in all the foregoing code.  When
packets are very long, the transmission line can sit idle for extended periods
while packets are being assembled and disassembled.  Although idleness is
unavoidable while the receiver is checking and processing the packet before
ACKing it, the sender can make use of this time to begin assembling its next
packet, so that additional idle time after the ACK is received is avoided.
This trick requires an additional packet transmission buffer, which, for
very long packets, might be hard to find.  Finally, users must know the
required conditions for successful use of long packets, and must request
extended packet sizes explicitly; too many things can go wrong if long packets
are used by default.

------------------------------

Date: Tue, 15 Jul 86 13:19 EDT
From: [e-mail] (Phil Julian, SAS Institute)
Subject: KERMIT Transfer Rates with File Compression
Keywords: Compression

We have found that piping Kermit input through a 'compress' program will
greatly increase the transmission rate when going between a Sperry 5000 Unix
system and an HP 9000 Unix system, using C-Kermit on both ends.  Much of the
improvement may be due to spaces in the original source, and nulls in the
tar format, but the effects of the compression program are much greater than
Kermit's internal space compression.

The first attempt to send the files was

     tar cf - . | kermit -i -s -             on the HP 9000
     kermit -i -k | tar xf -                 on the Sperry 5000

22 megabytes took 8.5 hours to send, with a 31.4% efficiency rate, at 19.2k
baud.

The next attempt to send the files was

     tar cf - . | compress | kermit -i -s -     on the HP 9000
     kermit -i -k | uncompress | tar xf -       on the Sperry 5000

4 megabytes took 1 hour to send, with a 54.6% efficiency rate, at 19.2k
baud.  The improvement was a 74% over using Kermit alone.  The compress
program is in the public domain, and uses the Lempel-Ziv algorithm.

These figures may add to the argument to add space compression algorithms to
the Kermit protocol.  Few systems have Unix-like pipes, so the addition to
the protocol would be useful.

[Ed. - Yep, in fact this technique is suggested in the documentation.  There
are other problems with Unix Kermit performance too, including excessive
copying of data from buffer to buffer, single-character i/o where bulk i/o
would suffice, lack of flow control, etc.  These will be addressed in future
releases.]

------------------------------

From: I. WRENCH <[e-mail]-f>
Date: Wed, 16 Jul 86 09:11:36 BST
Subject: MS-Kermit 2.29 Memory Contention Problem
Keywords: MS-Kermit 2.29 memory contention

In a previous UK newsletter I asked for help with problems using v2.29 of
Ms-Kermit to a DEC 10 system. The symptoms were that files sent from the PC
contained spurious characters on arrival, always in the same places. Several
people replied with sugestions, all of which i tried and seem to have no
success. I managed to get access to kermits on non-DEC machines and tried my
Ms-Kermit out with them - and got exactly the same problem. This lead me to
think that my actual copy of Ms-Kermit (brought down in .BOO form from
Lancaster) might have been corrupted somehow. I brought the .BOO file down
again using a different terminal capture prog than I originally used, and
converted the .BOO file using both the .PAS and .BAS de-hexers - but nothing
changed. This seems to suggest that there was something wrong with the set-up
on the IBM-XT I was using, and with a lot of playing around I traced down the
problem to be a program called INT10 that was being loaded in the AUTOEXEC.BAT
file. This program I believe has something to do with the Hercules graphics
board and I presume was causing workspace contention problems with Ms-Kermit. I
think this was caused as Ms-Kermit was growing in size to the point when the
problem was triggered at the release of v2.29. Incidentally the scroll back
pages function also just stopped working, it just pulled back rubbish onto the
screen. Anyway all is back to perfect working order now, if anyone else was
having similar problems to me i.e a perectly good program just stopped working
properly, and you can't trace it, then look to see what else is resident in
memory. Hope this is of use.

                   Iain Wrench.

[Ed. - See next message.]

------------------------------

Date: 17 JUL 86 13:31-MDT
From: JRD@USU
Subject: RE: MS-Kermit 2.29 Memory Contention Problem
Keywords: MS-Kermit 2.29 memory contention

Iain's difficulties were appearence of strange characters in transferred
files and a trashed roll back screen.  In his most recent note he traced
both to a Hercules supplied Helpful Utility, INT10.COM.

Indeed, Iain. The Hercules display board has characteristics much different
than standard IBM boards. Their INT10 program intercepts Bios Int 10h calls
(video display) and maps them into Hercules compatible form and might also
use memory not belonging to itself. The strange looking characters on the
roll back display were graphics images whereas Kermit expects text and
attributes. I have a legal copy of INT10 here and get similar troubles.
However, Kermit runs well with the EGA boards, in text mode.

Thanks for the specific symptoms. I had seen your original note in the UK
Kermit newsletter, but have not had time to reply.

        Regards,
        Joe D.

------------------------------

Date: Mon, 14 Jul 86 21:51:40 EDT
From: [e-mail]
Subject: Rosetta Stone for MS-Kermit and VT100
Keywords: VT100 Emulation, Keyboard settings

After (too much) hacking around with various other terminal programs and
with Kermit, I've come up with a reasonably useful general reference for
mapping the vt100 keypad with MS-Kermit.

No single keyboard mapping is "best"; it all depends on your particular
application.  In particular, some keyboards are best mapped logically (f1
corresponds to numeric pad 1) and others are best done physically (the one
in the upper corner is the same in both).  Instead of trying to please
everyone, here's a way to roll your own with a minimum of effort.

The first set of diagrams are pictures of the keyboard mappings for all the
vt100 implementations I could find.  There aren't too many, but these few
show the various approaches nicely.

The second set of diagrams should save some time when you build an
initialization file.  In it are the results of SHOW KEY for all the function
keys and all the numeric keypad keys.

(The numeric keypads shown have an enter key on them, since they were done
on a Zenith 158.  With that exception they should be generally applicable.
I don't have an enhanced AT keyboard to play with.)

Edward Vielmetti
Computing Center MicroGroup
University of Michigan
[e-mail]


 +----+----+----+----+
 | PF1| PF2| PF3| PF4|       This is the layout of a real, live
 +----+----+----+----+       VT100 keypad.
 |  7 |  8 |  9 |  - |
 +----+----+----+----+
 |  4 |  5 |  6 |  , |
 +----+----+----+----+
 |  1 |  2 |  3 |    |
 +----+----+----+entr|
 |    0    |  . |    |
 +---------+----+----+


 +----+----+----+----+
 | SF1| SF2| SF3| SF4|       This is the layout of the VT100 emulation
 +----+----+----+----+       for Procomm v2.3.
 | F7 | F8 | F9 | SF5|
 +----+----+----+----+
 | F4 | F5 | F6 | SF6|
 +----+----+----+----+
 | F1 | F2 | F3 |    |
 +----+----+----+ SF8|
 |   F10   | SF7|    |
 +---------+----+----+

 +----+----+----+----+
 | F1 | F2 | F3 | F4 |       This is the layout of the default VT100
 +----+----+----+----+       emulation for MS-Kermit v2.29.
 | F5 | F6 | F7 | F8 |
 +----+----+----+----+
 | F9 | F10| SF1| SF2|
 +----+----+----+----+
 | SF3| SF4| SF5|    |
 +----+----+----+ SF6|
 |   SF7   | SF8|    |
 +---------+----+----+

 +----+----+----+----+
 | F1 | F2 | SF1| SF2|       This is the layout for PC-VT v8.4.  Note
 +----+----+----+----+       the two keys mapped to the same
 | F3 | F4 | SF3| SF4|       VT100 key in the case of 0 and enter.
 +----+----+----+----+
 | F5 | F6 | SF5| SF6|
 +----+----+----+----+
 | F7 | F8 | SF7| SF8|
 +----+----+----+    |
 | F9   F10| SF9|SF10|
 +---------+----+----+

 +----+----+----+----+
 | OP | OQ | OR | OS |       These are the escape sequences sent out
 +----+----+----+----+       by these emulations.  Read "OP" as
 | Ow | Ox | Oy | Om |       <esc>OP.
 +----+----+----+----+
 | Ot | Ou | Ov | Ol |
 +----+----+----+----+
 | Oq | Or | Os |    |
 +----+----+----+ OM |
 |   Op    | On |    |
 +---------+----+----+

 +----+----+----+----+
 | F10| SF1| SF2| SF3|       This is the VT100 emulation
 +----+----+----+----+       defined by PC1:MSKERMIT.INI
 | F7 | F8 | F9 | SF4|       for the University of Michigan's
 +----+----+----+----+       MTS system.
 | F4 | F5 | F6 | SF5|
 +----+----+----+----+
 | F1 | F2 | F3 |    |
 +----+----+----+ SF6|
 |  Grey - | SF7|    |
 +---------+----+----+
1
 Show Key for the function keys:

 +----+----+   +----+----+   +----+----+   +----+----+
 | f1 | f2 |   | 596| 597|   |1118|1119|   |2152|2153|
 +----+----+   +----+----+   +----+----+   +----+----+
 | f3 | f4 |   | 598| 599|   |1120|1121|   |2154|2155|
 +----+----+   +----+----+   +----+----+   +----+----+
 | f5 | f6 |   | 600| 601|   |1122|1123|   |2156|2157|
 +----+----+   +----+----+   +----+----+   +----+----+
 | f7 | f8 |   | 602| 603|   |1124|1125|   |2158|2159|
 +----+----+   +----+----+   +----+----+   +----+----+
 | f9 | f10|   | 604| 605|   |1126|1127|   |2160|2161|
 +----+----+   +----+----+   +----+----+   +----+----+
  unshifted      shifted      with ctrl     with alt

      +----+----+----+----+          +----+----+----+----+
      |Home| Up |PgUp|Gry-|          |  7 |  8 |  9 |Gry-|
      +----+----+----+----|          +----+----+----+----|
      |Left|    |Rght|Gry+|          |  4 |  5 |  6 |Gry+|
      +----+----+----+----+          +----+----+----+----|
      | End|Down|PgDn|    |          |  1 |  2 |  3 |    |
 +----+----+----+----+entr|     +----+----+----+----+entr|
 |   Ins   |   Del   |    |     |    0    |    .    |    |
 +---------+---------+----+     +---------+---------+----+
          cursor pad                   numeric pad


      +----+----+----+----+          +----+----+----+----+
      | 71 | 72 | 73 | 74 |          | 583| 584| 585| 586|
      +----+----+----+----+          +----+----+----+----+
      | 75 |    | 77 | 78 |          | 587| 588| 589| 590|
      +----+----+----+----+          +----+----+----+----+
      | 79 | 80 | 81 |    |          | 591| 592| 593|    |
 +----+----+----+----+ 28 |     +----+----+----+----+ 540|
 |    82   |    83   |    |     |   594   |   595   |    |
 +---------+---------+----+     +---------+---------+----+
         unshifted                       shifted

      +----+----+----+----+
      |1143|    |1156|    |
      +----+----+----+----+
      |1139|    |1140|    |
      +----+----+----+----+
      |1141|    |1142|    |
 +----+----+----+----+1052|
 |         |         |    |
 +---------+---------+----+
          with ctrl

------------------------------

Date: Wed, 16 Jul 86 16:17 PDT
From: [e-mail]
Subject: A Wish List (long)
Keywords: MS-DOS Kermit, MS-DOS 2.29

     For the last year or so I have been using MS-KERMIT on a PC-XT to
connect to a variety of computers.  These include the CRAYs here at
NMFECC and the local VAX running VMS.  I have been collecting a
wish-list, and thought it was time to post it and see if some of the
items might be added to the "official" list in the BWR file.

     Here goes:

1) Any new text coming from the host or typed by the user should appear
at the end of the last screenful, not at the cursor location.  Operator
messages from the host, as well as messages from programs I am running,
often obscure critical text on the screen while I am examing something I
did five minutes earlier.

2) Seven pages (or so) of screen memory is nowhere near enough.  I'd
like to be able to use as much memory as I want, (say) 30 pages of
screen memory.  Better still would be an "infinitely" long memory,
with simultaneous storage into a disk file that would serve as both a
log and the top half of the screen memory.  This might also allow you
to view the screen memory of your last session simply by paging back
during the current session.  The present log is awkward since a) it
isn't available online, and b) it contains a lot of control
characters from backspacing over typing errors, and from screen
editing sessions on the VAX when I forget to turn off the logging.

3) Printing and dumping.  It would be nice if one could somehow "mark" a
section of the screen memory and either print it or save it to a file.

4) The CRAYs do not respond to input characters until the carriage
return is pressed (this is also true of many computers accessed through
networks).  Thus, screen editing is impossible without use of a
"co-editing" program which runs on the PC and the CRAY simultaneously.
It might be a good project to develop standards for such a system.
NMFECC and LCC both support a system called SED which seems to work
well.

5) Again because of the above characteristic, editing of input lines
is limited to backspacing.  A true line-editing capability (as on the
VAX, or in the DOS supplement/shareware program CED) could be
incorporated into the terminal emulator.  This is the natural place
for such a capability, since the line could be echoed locally,
edited, then sent when the return key was pressed.

6) A related wish is command-line recall, either VMS/CED-style (press a
key repeatedly and old command lines reappear in reverse order) or by
highlighting text in the screen memory somehow, then bringing the line
into the current command buffer for editing by pressing a key, then
sending it with a return.  On our system, linefeed characters echo as
exclamation points, and so a facility for translating exclamation points
into linefeeds (and echoing linefeeds as !'s during local pre-
transmission editing) would be useful - of course, the mapping should
be general enough to support a variety of host computer idiosyncrasies.

7) When I assign a character string to a key, then press the key, often
the characters appear too rapidly for our CRAY terminal concentrator to
accept them.  It would be useful if the speed with which character
strings were sent to the host could be selected by the user.  Since when
I talk to the VAX I press the arrow keys a lot, and these send
three-character sequences, I'd like these to be sent at full speed - so
some means of specifying the "speed of paste" when each key is defined
would be best.  (Also, it would be nice if the interactive key
definition procedure were streamlined so that the user need only press
the key they wished to define - why do we need to know the scan code?).

8) It would be nice to have a "bare bones" mode that used DOS for the
keyboard handling.  My text editor has a facility whereby one can
start a command processor, and use the editor commands to paste old
lines, etc.  Thus, one gets command line recall and a log when
running compilers on the pc.  It would be nice if I could run codes
on the CRAY this way.

     Also, I have some questions about what happens when one is not
in connect mode and a message comes in over the serial port from the
mainframe.  When I am at Kermit command level after a ctrl-]c, then I
reconnect, data is missing from the screen (if I had been listing my
files, the list would be garbled).  I have had better luck with
ctrl-]p.  What I'd really like is a full explanation of what happens
- for example, does the disk actually run in a background mode to
update the log when an interrupt comes in over the port?

     Finally, I expect that some of the above wishes might be
answered by use of either a) a windowing program, b) a mouse with
appropriate driver for cut-and-paste, or c) a keyboard enhancer
program, and wonder if anyone has learned any useful tricks.  I use
SIDEKICK all the time with MS-KERMIT, and find it useful to paste
frequently used lines from the notepad; SIDEKICK allows the user to
control the speed of pasting, and so I avoid the problem alluded to
in (7) above.

     In general, I'm very pleased with MS-KERMIT; I would appreciate
any comments on these ideas from either the KERMIT developers or the
user community.  Comments can be posted if of general interest; other-
wise I can be reached at:
              [e-mail]
or some such thing depending on the syntax of your local mail utility;
Im on the LLV VAX on the MFENET at Lawrence Livermore National Laboratory.

------------------------------

Date: 16 JUL 86 21:47-MDT
From: JRD@USU
Subject: RE: Wish List
Keywords: MS-DOS Kermit, MS-DOS 2.29

Mr. Friedman ([e-mail]),

        Your long "wish list" arrived in the mail from Columbia and, since
I have been doing much of the MS Kermit development recently, perhaps I can
comment on some of the points.

        As I understand things, the bulk of the wishes are closely related
to offsetting deficiencies of the mainframe host, full editing facilities
in particular.

Point 1: While in connect mode incoming text should be placed at the end
of previously received text rather than at the cursor position (if the screen
has been rolled back manually). True, but. This would require a healthy amount
of screen and memory management code and employment of multiple pages of video
memory (on what kind of display adapter?) to avoid massive flickering between
old and new screens. And, think about what must be done if the regular screen
scrolls up. Just telling the host Xoff can work wonders most of the time;
exiting connect mode, selecting port 2, and returning to connect mode will
also preserve the old screen (but will lose new incoming text from port 1).

Point 2: Five screens of roll back are too few, 30..inf would be much nicer.
Again, these things can be done, at a stiff price in both runtime code
space and programmer effort. An easy work around is to make a hard copy
listing as you go (Control PrtSc does the trick). Micros are spoiling us.

Point 3: Selectively edit a screen for dumping to a printer. See below.

        Modern full screen editors on micros have many of the characteristics
you wish. They cost $200+ when Sold in large quantities and they just edit.
Some serious duty editors of this kind are Brief, Emacs, Epsilon, and Kedit.
For capturing program output to a window have a look at Epsilon by Lugaru;
I'm using Brief. Some day, "real soon now", mainframe editors will catch up,
but at a very hefty price in i/o channel facilities (38 Kbaud+) and scads of
real memory for buffers, etc. My students have remarked to me that because
I have pronounced ideas on what editors should do then why not write my own.
Yes, certainly, but what about all the other interesting things to do?

Point 4: Cray editors are line oriented rather than full screen types. Yep!
Only Real Programmers use Crays and RPs are happy with card images and
patching binaries; I was & did. Try a copy of Emacs. By the way, why are
you burning up Cray time doing editing? Don't you fellows at LLL work into a
mere-computer front end to handle i/o, scheduling, and other routine chores?
(Must be the SDI money.)

Point 5: Line editing Helpful Utilities. These still work under Kermit!
Mouse menus can be very useful for classes of minor tasks, and Kermit loves
the little fellows. Microsoft supplies a very good menu program with their
mouse; I have both.

Point 6: Command line recall buffer and translation of strange input chars.
Kermit already has too many buffers and the command parser is Byzantine
trying to do the present command line editing (in system independent fashion).
Limited translation is being considered, particularly for European characters.

Point 7. Pace sent characters. Either lower the baud rate or have the troops
get a concentrator with typeahead buffering. If we were to pace characters
then most of the other users would hit the overhead. Also, key redefinition
could be much smoother. Sure could, and we are thinking about doing so
when time is available; it will not replace Prokey et al. Also, how do you
get file transfer packets through a slow concentrator?

Point 8: Bare bones keyboard handling (let DOS do it). MS Kermit obtains
keyboard info by both DOS calls and Bios calls; it does not go to the
keyboard hardware and the like. It is about as bare bones as possible. If you
were to use a fancy console handler which passes along scan codes properly
then it probably would be compatible with Kermit. Most such utilities do not
do so yet.

Question: What's with the serial port?
        Kermit returns the serial port to its original owner when Kermit
does not have direct need of it, such as between file transfers. That is
a very good safety feature for a program which uses interrupts for reception.
As you may notice, between file transfers or Connect sessions there is no
implied source/sink for serial port information; thus, Kermit is unaware
of the port at such times. If the port were left active then Kermit would
have to be prevented from accessing conflicting programs or letting the user
Push to DOS, etc just to keep the interrupts from calling a perhaps non-
existant interrupt routine (a disaster) or having a buffer overflow.
When DOS grows up to be a multi-tasking o/s then we can consider letting
Kermit run in the background; WINDOWS/DOS 5.0 does not seem to be there yet.
I also run DECnet-DOS on my micro, and it tries to permanently install itself
as an extension of DOS plus "own" the serial port most of the time. It runs
the port in the background and messes with DOS in a very serious way.

Comment added by me. Kermit as a whole is written and improved by volunteers,
using an enormous number of man hours, and we earn exactly zero for doing so.
Thus, features get added when someone decides to do them (best to let Columbia
know first since others may be doing the same thing). Many of the items on
your wish list fall into the very sophisticated technique department.
Fortunately for all of us, many of the Kermit contributors are adept at such
matters, when they have the time. Suggestions such as yours provide a rich
menu of interesting things to consider. Like to have a go at one or two?
And not least, thanks for the nice words about the existing Kermit; they help.

        Regards,
        Joe D.

------------------------------

End of Info-Kermit Digest
*************************
-------
22-Jul-86 16:21:49-EDT,17314;000000000001
Mail-From: SY.FDC created at 22-Jul-86 16:20:13
Date: Tue 22 Jul 86 16:20:13-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V5 #3
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 22 Jul 1986       Volume 5 : Number 3

Today's Topics:
                  New Kermit for the Commodore Amiga
                            HP1000 Kermit
                      Bug in MS-DOS Kermit 2.29
                             Sanyo Kermit
                          BOO File Problems
                   Extra-Long Packets Specification
              Some Thoughts about Long Packets in Kermit
                          CMS Kermit Problem

----------------------------------------------------------------------

Date: Mon 21 Jul 86 17:31:29-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Kermit for the Commodore Amiga
Keywords: Amiga, Commodore Amiga, C-Kermit

This new version of Kermit for the Commodore Amiga is based on the current
C-Kermit release, 4D(060), and has been sent in by Jack Rouse of SAS
Institute (Cary, NC).  It replaces (by mutual agreement) the Amiga Kermit
previously submitted by Davide Cervone of the University of Rochester.  The
CKI*.* files have been replaced, except for the bootstrapping files, which
remain where they were.  Also, several of the system-independent C-Kermit
modules have been restored to their original condition (the previous Amiga
Kermit release altered them to include "printf2" and "printf3" functions;
these are no longer needed).  The new release includes help, documentation,
beware, and "boo" files, along with source.  The files are in KER:CKI*.* on
CU20B, plus (if you want to build from source) the other C-Kermit source
files (CKU*.C, CKU*.H, CKC*.C, CKC*.H, CKWART.*, CKCPRO.W).  The files are
also available on BITNET from KERMSRV at CUVMA.  For those who cannot get at
these files over the networks, or who have trouble with the bootstrapping
procedure, Jack will send an Amiga diskette including source and executable
program if you send him a check for $6.00:

  Jack Rouse
  106 Rubin Ct., Apt. A-4
  Cary, NC  27511

The CKI*.* files from the previous Amiga Kermit are still available on CU20B
as KO:CKI*.*.  Jack is also working on an adaptation of C-Kermit to Apollo
Aegis.  This will be announced when it is received.

------------------------------

Date: 17 Jul 86 17:20 +0200
From: [e-mail]
Subject: HP1000 Kermit
Keywords: HP1000 Kermit

For a long time I have tried to install Kermit on every machine in our
company's multivendor computer hardware environment.

The biggest problems arose with the HP1000 (RTE-6/VM) we still have, but
finally I could solve them mostly.

The Fortran-Kermit (HPM* files) you distribute contains some bugs, but we
could get it running with an HP150-Kermit, but not with VAX- or
DEC20-Kermit. For a long time we had to use the HP150-Kermit (with debug
mode enabled) as an intermediate for transfers to other hosts. Not good, but
better than nothing.

When the Pascal-Kermit (HPA* files) arrived, we hoped to get it working,
because the Pascal-Compiler is identical on RTE-6/VM and RTE-A. But we ran
into big troubles, and as a regular reader of Kermit Info Digest I wonder
that nobody has complained about this Kermit version.  These were the main
problems:

1. Two source files are missing (PASCAL.PAS, VMAST.PEX).
2. A compiler directive (STANDARD_LEVEL HP1000) is missing in some modules,
   causing lots of compilation errors.
3. The revision number of the Pascal compiler has to be 2440
   (or later) and not 2401 as stated in the instructions.

We did a lot of investigations to find this, but after adding the correct
compiler directive and installing a new version of the Pascal compiler, we
gave up, because of the missing source files. They contain only procedure
headers, and backtracing from the compilation errors it is possible to write
them again. But we did not want to put so much work in it.  I also tried to
phone the author of this Kermit, but he went off in his holidays for 4 weeks
just half an hour before I called him, and nobody else was there to help me.

But finally everything turned into happiness, when I received a new Fortran
version of Kermit distributed at an HP1000 conference in Washington (DC). I
could compile and link it without any problems and it worked instantly.
Later I discovered a bug concerning the time-out setting of the terminal
port, but this was obvious and easy to correct. This Kermit version supports
remote and local (very difficult on a half-duplex machine!) operation as
well as server mode. And, best of all, this Kermit runs on RTE-6/VM and
RTE-A as well, the type and revision(!) of the operating system is
selectable by parameters.

I suggest, that this Kermit version should replace both the HPM* and HPA*
files in the official Kermit distribution.

I am sure that the author will give you the most recent version of this
Kermit (which I do not have, yet) if you contact him:

  Paul Schuman
  E-Systems, Inc., Greenville Division
  P.O. Box 1056 CBN 101
  Greenville, Texas 75401
  Phone [phone]
  Telex 701511 mfogvl ud

In the meantime we got MS-Kermit 2.29 on our ATs, and we discovered that the
HP1000-Kermit does not like it (file transfer with version 2.27 works
perfectly). We have found out, that the 2.29-Kermit precedes every packet
with XON or binary zero depending on the setting of the flow control, and
the HP1000-Kermit seems to have a bug in its packet parsing routine.  Maybe
this is already corrected in the next release, which I will receive in
October presumably, but is now available from Paul Schuman as said above.

Best regards, Michael.

Real Name:     Wolfgang Michael Terenyi
MAILNET:       W._Michael_Terenyi_(SANDOZ)@QZCOM.MAILNET
ARPA/CSNET:    W._Michael_Terenyi_(SANDOZ)[e-mail]
JANET:         W._Michael_Terenyi_(SANDOZ)[e-mail]
G3 Fax:        [phone]
Telex:         132287 sfi a
Real Address:  SANDOZ Research Institute
               Brunner Str. 59
               A-1235 Vienna
               Austria, Europe

[Ed. - Many thanks for the information.  We have written to Paul Schuman and
asked him to send it in.  It will be announced when (if?) it arrives.  Also
thanks for describing the MS-DOS Kermit problem so succinctly (see below).]

------------------------------

Date: Fri 18 Jul 86 11:22:05-EDT
From: Frank da Cruz <[e-mail]>
Subject: Bug in MS-DOS Kermit 2.29
Keywords: MS-DOS Kermit, IBM Mainframe, HP1000, Harris

The new MS-DOS Kermit has a serious problem when used with certain kinds of
host computers, including IBM mainframes, HP-1000's, and Harris minis.  The
symptom is that file transfer doesn't work -- either at all, or else rarely.
The cause is that when flow-control is set to NONE, then Kermit erroneously
precedes each packet with a NUL (ASCII 0) byte.  Most hosts are immune to
NULs on the communication line, but an IBM mainframe with VM/CMS will
discard all following characters up to the break character (CR), in Kermit's
case the entire packet.  On the Harris, a NUL reportedly kills the entire
Kermit process.  See the previous message for what happens on the HP-1000.
A patch is available for those who are affected by this problem.  Since it
is rather long, it has been added to the end of the "beware file".  This
file is available as KER:MSKERM.BWR on CU20B (via anonymous FTP on the
Internet) or MSKERM BWR on CUVMA (via KERMSRV on BITNET).

An updated release of MS-DOS Kermit containing fixes for this and all the
other reported problems, plus a few surprises, should be available in late
summer or early autumn.  In the meantime, source-level patches will continue
to be listed in the beware file.

------------------------------

Date: 1986 Jul 21   19:43 EST
From: Bob Babcock <[e-mail]>
Subject: Sanyo Kermit
Keywords: Sanyo MBC Kermit

The Sanyo release of kermit version 2.29 has a bug which locks it at 300
baud.  I got a copy of the sources over KERMSRV and fixed the problem.  I
will send you the revised MSXMBC.ASM shortly.

I also got copies of the IBM specific routines and created a Sanyo version
with essentially all of the IBM features.  This version requires an optional
video board which only some machines have.  (The board was produced by Sanyo
to make the MBC series sufficiently IBM compatible to run Lotus 123.)  I
have a couple little things which I may work on before sending the sources
off.  I have named the Sanyo specific routines MSX55X.ASM, MSY55X.ASM and
MSZ55X.ASM, but you can change that if you prefer.  Because of the video
board requirement, these do not replace MSXMBC.

[Ed. - Thanks.  The names are fine, though it would be preferable if the
two Sanyo versions could be combined into one, which could tell at runtime
whether the option board was present.  The new stuff will be announced when
it arrives.]

------------------------------

Date: Mon, 21 Jul 86  21:07:57 EDT
From: "Roger Fajman" <RAF@NIHCU>
Subject: BOO File Problems
Keywords: BOO File, Bootstrapping, MS-DOS Kermit, KERMSRV, EBCDIC

I figured out some problems that I encountered with BOO files and the IBM
PC.  There were two:

(1) If you use the PUNCH command of KERMSRV@CUVMA on BITNET, the file comes
with trailing blanks, which will cause the EXE file generated to be
incorrect.  The BOO format doesn't use blanks, so trailing blanks can be
safely stripped before the file is processed.  However, MSBPCT.BAS does not
do this, so you had better.

[Ed. - The MSBPCB and MSBPCT programs should indeed strip trailing blanks.]

(2) When getting BOO files through BITNET, take care with your EBCDIC-ASCII
translations.  Ours is the same as Columbia's, except for curly braces.
Most BOO files don't have curly braces, but MSBPCT.BOO (the C version of the
IBM PC BOO file decoder) does have a curly brace in it that represents a
count of NULs.

BOO files don't contain any kind of internal consistency check, such as a
byte count and/or checksum, so problems such as these just give you EXE
files that don't work.

[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.]

------------------------------

Date: Sat, 19 Jul 86 23:44:48 edt
From: [e-mail] (Roy Smith)
Subject: Re: Extra-Long Packets Specification
Keywords: Long Packets

> The first question some people ask when they learn of these of these [sic]

[Ed. - oops]

> devices [error correcting modems] is whether their error-correcting
> capability has made Kermit obsolete.  The answer is an emphatic no [...]

I know this list is for discussing Kermit, but I couldn't help noticing that
exactly the same question is asked about uucp.  Time and time again I've
seen people suggest that all the overhead of computing checksums that uucp
does could be eliminated if only you had error correcting modems.  Come to
think of it, I've seen it asserted more than once that you don't really need
TCP/IP on an ethernet, since you don't have to worry about mangled packets.
Will people never learn?

As it happens, while I was typing in the first paragraph of this message, a
bunch of "/usr: file system full" messages popped up on my screen.  Kermit,
uucp, and ftp (and presumably Decnet, Appletalk, Xmodem, and so forth) all
deal with full file systems in some rational way.  Error correcting modems
do not.  It doesn't do you much good to move the bits from here to there if
they just get dropped on the floor at the other end without any warning.

Roy Smith, {allegra,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016

------------------------------

Date: Sat, 19 Jul 86 01:18:10 edt
From: [e-mail]
Subject: Some Thoughts about Long Packets in Kermit
Keywords: Long Packets, Sliding Windows

I see a potential problem with long packets - just because two kermits have
the capability, it might not make sense to use it.  They may be connected
together by a regular modem.  You can have some user selectable option, but
the less the user has to know about the lower levels, the better (getting
all the options set correctly can be difficult now).  One solution might to
use adaptive packet sizing.  They could start small, and rapidly grow larger
as it is determined that the link is error free.  Another nice feature
(which I'm sure has been mentioned before) would be packet stacking and
built in compression.  It might soon become difficult to determine where to
do some of these things - in kermit or in the modem.

  - Jon Zeeff    ihnp4!umich!umix!b-tech!zeeff
         [e-mail]

[Ed. - Well...  There is also a packet-stacking extension to Kermit (called
"sliding windows"), which is independent of, and not mutually exclusive
with, long packets.  However, sliding windows (a) require full duplex
communication, and (b) are complex to program.  Any particular
implementation will depend on peculariarities of the system -- interrupts,
multiprocessing, etc -- in order to achieve full duplex transmission.  Long
packets are the best way to boost performance in a half duplex connection
(and many of these new modems are half duplex), but you're right: long
packets should not be sprung on the user by default.  The user should know
the necessary preconditions -- a very clean connection, large input buffers
at the receiving end, and effective, reliable end-to-end flow control.]

------------------------------

Date: 1986 Jul 21   19:43 EST
From: Bob Babcock <[e-mail]>
Subject: CMS Kermit Problem
Keywords: CMS Kermit

I have always found it difficult to run Kermit talking to an IBM mainframe
running CMS over a straight ascii line.  The problem is that line noise
during a file transfer tends to interrupt the Kermit process and pop you
into CP.  To resume execution of Kermit, you need to send a BEGIN command (b
is enough).  But you can't do this without aborting the transfer at the
local Kermit, assuming that it hasn't already timed out before you noticed
the problem.  This problem does not arise if Kermit is run over a series/1
interface or equivalent, but the IBM mainframe which is our link to BITNET
does not have series/1 software which would allow Kermit to run.  I have
thought about modifying Kermit at different levels, either allowing the user
to hit a key and transmit a B, or making Kermit smart enough to recognize
the problem and automatically send the begin command.  Do you know if anyone
else has attacked this problem?  I don't want to reinvent the wheel.  I
should emphasize that this is not a problem with the CMS Kermit, but rather
is a characteristic of the environment it runs in.

[Ed. - This is only a specific instance of a common problem: what should the
local Kermit do when the remote Kermit "goes away" during file transfer?
When the remote Kermit goes away, you're confronted by some aspect of the
underlying system, or in some cases nothing at all.  The possibilities are
simply too numerous to be accounted for in the Kermit protocol, or any
protocol that attempts to span a large number of systems.  You shouldn't
have to embody specific knowledge about a particular remote system in
another system's Kermit program -- if you did, where would it end?  The best
that can be done is what is currently done: if a packet does not elicit the
expected reply, try again, up to the retry limit, and then give up, but also
allow for manual intervention.  In the case of MS-DOS Kermit, you can type
Ctrl-C at any time during the file transfer to get back to Kermit-MS>
command level instantly, so that you can CONNECT and do whatever you can to
clean up.  Unfortunately, there's no way to tell the local Kermit to resume
the file transfer where it left off.

CMS is a special case.  Luckily, there's a special solution.  Version 3 of
CMS Kermit (due for release Any Day Now, will put the line into a special
mode so that any characters at all that appear to CP will continue the
program, that is, will do what "begin" would have done.]

------------------------------

End of Info-Kermit Digest
*************************
-------
25-Jul-86 13:24:02-EDT,20572;000000000000
Mail-From: SY.FDC created at 25-Jul-86 13:22:50
Date: Fri 25 Jul 86 13:22:50-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V5 #4
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

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 <[e-mail]>
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: [e-mail]
Via:  [e-mail]
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: <[e-mail]> (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: [e-mail]
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 <[e-mail]>
(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: [e-mail] (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 <[e-mail]>
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: [e-mail]
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 [e-mail]

[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: [e-mail]>
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
[phone]

[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 <[e-mail]>

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"  <[e-mail]>
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: [e-mail]
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
*************************
-------
 1-Aug-86 12:47:07-EDT,12869;000000000000
Mail-From: SY.CHRISTINE created at  1-Aug-86 12:46:06
Date: Fri 1 Aug 86 12:46:06-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #5
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 1 Aug 1986       Volume 5 : Number 5

Today's Topics:

                   The First Kermit Newsletter Available
                              Okstate Downtime
              Kermit-80 files on PC-format diskettes in the UK
                          Japanese Kermit Manuals
                KERMIT for Sirius/Victor 9000 under CP/M-86
        Two Kermit-MS 2.29 Implementations for the Sanyo 550 Series
                  Re: KERMIT with Other Terminal Emulators
                    CMS Kermit Problem (making it work)
                                 .BOO files
                Using C-Kermit to dialout on a DF112 modem?

----------------------------------------------------------------------


Date: Tue 29 Jul 86 14:41:54-EDT
From: Christine M Gianone <[e-mail]>
Subject: The First Kermit Newsletter Available
Keywords: Kermit Newsletter

The first issue of the (paper) Kermit Newsletter (July 1986, Vol.1 No.1) is
currently available.  The Newsletter target audience was originally intended
to be those who do not have access to our networks and have asked to be
informed about new Kermit releases and other Kermit news.  Articles in this
issue include: MS-DOS Kermit Version 2.29; Kermit Book Published by Digital
Press; C-Kermit; The Top Five Kermit Questions; Mac Kermit 0.8(34); Protocol
Extensions; VAX/VMS Kermit-32 Version 3.2; Kermit's Early History.  Anyone
who is interested in obtaining a copy of this and future Kermit Newsletters
may do so by sending their postal (not electronic) mailing address to
Info-Kermit-Request@CU20B, Kermit@CU20B, or KERMIT@CUVMA.  Number 1 will
be sent to those who request it this way till our leftover copies run out.

------------------------------

Date: Tue, 29 Jul 86 20:12:34 -0500
From: Mark Vasoll <[e-mail]>
Subject: Okstate Downtime
Keywords: Okstate Downtime

The system Okstate, (home of the UUCP and Kermit Server Kermit
distributions) will be down from August 8th until August 31st while our
machine room is being remodeled.  The uucpker and kermsrv dialin number will
not answer the phone during this period.  Watch for the return of uucpker
and kermsrv shortly after August 31st.

Thanks,
Mark Vasoll
Department of Computing and Information Sciences
Oklahoma State University

Internet:   [e-mail]
Obsolete:   [e-mail]

UUCP:  {cbosgd, ea, ihnp4, isucs1, mcvax, pesnta, uokvax}!okstate!vasoll

[Ed. - Thanks for the information.  The return date of UUCP will be
announced in the digest.]

------------------------------

Date: 30-JUL-1986 17:18:19
From: [e-mail]
Subject: Kermit-80 files on PC-format diskettes in the UK

Having had a number of requests lately for it, we've now set things up so we
can supply a complete set of the CP/M-80 Kermit files (CP4) on IBM PC MS-DOS
format diskettes. Not having any CP/M engines, we can't write diskettes
directly in CP/M format: but this at least will let people get the files
onto their own territory (and it's easier to move files from your own PC to
your CP/M machine than download over a phone line).

The service is offered in the UK and Irish Republic only: the address, as
before, is

           Kermit Distribution,
           Department of Computing,
           Computer Building,
           Lancaster University,
           Lancaster LA1 4YW
           UK

           Phone (UK) 0524-65201 x 4881

We hope before long to be able to provide all the IBM PC Kermits (Xenix, QNX
and so on) on MS-DOS format discs; and in the longer term we intend to offer
all Kermit sources for everything in this way.


Alan Phillips

[Ed. - Thanks!]

------------------------------

Date: Mon 21 Jul 86 09:20:55
From: ken-ichiro murakami <nttlab!NTT-20![e-mail]>
Subject: Japanese Kermit Manuals
Keywords: Japanese Kermit Manuals

   I will give the Japanese Kermit manuals to everyone. The only problem is
that I cannot distribute machine readable code. My favorite workstation is
STAR Japanese version, and all my document files are in this machine. JSTAR
has no way to export files except for FDD, and the number of JSTAR in Japan
is also small. That is, every time the manual is ordered, I must print it
out and send by mail (not E-mail).  However, I'll distribute free manuals as
many as possible. Please forward me, when you receive requests for Japanese
manuals.  I can distribute JSTAR FDD or printed documents.

    Ken-ichiro Murakami
    NTT Basic Research Laboratories
    3-9-11 Midori-cho, Musashino-shi
    Tokyo, 180
    Japan

    Telephone : [phone]
    E-mail address : "nttlab!murakami"@Shasta    (from ARPA)
                or
             [e-mail]   (from JUNET)
                (JUNET is Japanese domestic network.)

[Ed. - Thanks to Ken-ichiro Murakami for all the work he put into
translating the Kermit User's Guide and the Kermit Protocol Manual and for
volunteering to distribute these manuals to others.]

------------------------------

Date:     Tue, 29 Jul 86 10:44 MDT
From:     <[e-mail]> (Eric Zurcher)
Subject:  KERMIT for Sirius/Victor 9000 under CP/M-86
Keywords: Sirius/Victor 9000 Kermit, CP/M-86

This note will be followed by slightly modified versions of A86 and H86
files for KERMIT for the Victor 9000/Sirius under CP/M-86.  This version is
nearly identical to the one I sent to you about 3 weeks ago, and differs
only in that the SET PORT command is now implemented, allowing the user to
select either serial port "A" or "B" - "A" is the default.  I hadn't
originally intended bothering to add this feature, but a freak lightning
strike knocked out the "A" port on one of the Victors in our department, and
it was easier (and cheaper) to implement the SET PORT option than to fix the
hardware.

                                        Sincerely,

                                        Eric Zurcher
                                        Dept. of Biology
                                        Utah State University
                                        Logan, Utah 84322-5305
                                        [e-mail]

[Ed. - Thanks, Eric.  The new files are in the Kermit distribution as
KER:C86XV9.*.]

------------------------------

Date: Wed, 23-JUL-1986 22:26 EST
From: Bob Babcock <[e-mail]>
Subject: Two Kermit-MS 2.29 Implementations for the Sanyo 550 Series
Keywords: MS-DOS 2.29, Sanyo 550 Series

This is to announce two versions of Kermit 2.29 for the Sanyo 555.  One has
a fairly simple machine dependent routine MSXMBC.ASM, in particular, it does
not have any terminal emulation other than responding properly to some
VT-100 escape sequences which the BIOS recognizes.  This version will run
under DOS 2.11 on any Sanyo MBC-550 or 555 which has a serial port.  I
haven't tried it under DOS 1.25, but Kermit does check the DOS version, so
it ought to work.  The other version is derived from the IBM Kermit and
includes almost all of its features including emulation of VT-52, VT-102,
Heath-19 terminals.  This version requires the optional IBM compatible video
board.  Since DOS 1.25 doesn't support the video board, the question of DOS
version doesn't arise for this version.

Most of the work in producing these routines was copied from code written by
Joe Smiley for version 2.27.

Both versions use the standard files:
     mssdef.h msscmd.asm msscom.asm mssfil.asm mssker.asm mssrcv.asm
     msssen.asm mssser.asm mssset.asm msster.asm mssfin.asm

The simple version has one Sanyo dependent-file:
     msxmbc.asm

The video board version has three Sanyo-dependent files:
     msx55x.asm msy55x.asm msz55x.asm

Bob Babcock
Mail stop 63
Smithsonian Astrophysical Observatory
60 Garden Street
Cambridge, MA  02138
617-495-7107  FTS 830-7107

Net addresses:
[e-mail]
[e-mail]

[Ed. - The new files are in KER:MS%MBC.* (simple version) and KER:MS%55X.*
(video-board/vt100 version), including .BOO files for each (% is the DEC-20
single-character wildcard).]

------------------------------

Date: Sat, 26 Jul 86 11:40 AST
From: <[e-mail]> (Eberhard W. Lisse)
Subject: Re: KERMIT with Other Terminal Emulators
Keywords: Terminal Emulation

Apropos of Jonathan Scott's message on this subject in the Info-Kermit
Digest V5 #4...

If one needs both Kermit (MS 2.29) and another Terminal program I would try
to run the other one from within Kermit. (RUN XYTERM)

I do this with a public domaine Tektronix 4010 emulator with no problems at
all. That combination works, in fact, better than a commercial product
(VTERM from Coefficient Systems) we use here as well, as that one does not
leave the keyboard as it is but switches to the US layout which is very
different from the one which comes with the IBM PC when bought in Germany.

------------------------------

Date: Wed, 30 Jul 86 14:34 EDT
From: CCPHIL@TUCC
Subject: CMS Kermit Problem (making it work)
Keywords: VM/CMS Kermit, CMS Kermit

Bob Babcock mentioned a problem with CMS Kermit putting him into CP mode,
where he has to interact with the system by entering a "begin" command to
get back into CMS mode.

The solution is to enter the command "set run on".  This changes your CMS
environment in a few .  One thing that happens is that a carriage return
will return you to CMS mode if you enter CP mode.  S most Kermits will time
out, and send a NAK packet (which is terminate in a carriage return), then
you automatically return to CMS mode where ermi Kermit runs without dropping
a stroke.  Your default environment must be "set run off".  We have used e
"set run on" command hen going to CMS from the HP 900 and other hosts at SAS
Institute.

[Ed. - Version 3.0 of CMS Kermit should return you to CMS mode automatically
if you happen to enter CP mode.]

------------------------------

Date: 30-JUL-1986 15:04:20
From: [e-mail]
Subject: .BOO files

How about using a hybrid Intel-Hex/BOO file format to provide the error
checking? If you were to structure a record as

               :<length><BOO-encoded data><checksum>

where length and checksum are ASCII hex, and checksum is based on the sum of
the byte values after conversion, you'ld add only 5 bytes per record. An EOF
record would have a length value of 0, adding 3 bytes to the grand total. I
would guess an 8-bit checksum would be enough for anyone's needs, and you'ld
have only a 6% or so increase in file size.

That would give you the checking needed: for another 2 bytes per record you
could add a <record-type> ASCII hex field after the <length> field, which then
gives you an expansion path if you ever do a major change in the structure.
The obvious ones here are

    Type 0   Filename record (including such attributes as you might want,
             such as "total length of data you should get when you've done")
    Type 1   Data record
    Type 2   ASCII test pattern
    Type $FF EOF

Having a specific record type for EOF and FileName would let you concatenate
.BOO encodings for multiple files and convert them all in one run of the
converter program.

And, I suppose, if you used record type values not used in Intel hex, you could
produce a universal converter that could do both.....

Alan

------------------------------

Date: Thu, 31 Jul 86 14:57:07 edt
From: Jeffrey Burgan <[e-mail]>
Subject: Using C-Kermit to dialout on a DF112 modem?
Keywords: DF112 Modem

I am having problems getting a DF112 modem to work with C-Kermit.  When I
issue a 'set line /dev/ttyIb' command after the 'set modem df100' command,
kermit does not respond with a prompt. It seems it is waiting for carrier
detect. Has anyone gotten a DF112 to work dialing out and if so, are there
any special switch settings for the modem.  Any help would be appreciated.

Thanks in advance,

Jeffrey Burgan
University of Maryland
[e-mail]

[Ed. - It also depends on which version of C-Kermit -- Sys V, 4.2BSD,
etc.  Sys V has special treatment for modems ("CLOCAL"), which may or may
not be consistently implemented on different System-V systems.]

------------------------------

End of Info-Kermit Digest
*************************

-------
 8-Sep-86 17:40:31-EDT,15879;000000000000
Mail-From: SY.CHRISTINE created at  8-Sep-86 13:05:07
Date: Mon 8 Sep 86 13:05:07-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #6
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>


Info-Kermit Digest         Mon, 08 Sep 1986       Volume 5 : Number 6

Today's Topics:

                           New Kermit for HP-1000
                     New Release of Sperry-1100 Kermit
                 New Kermit for Use with Microsoft Windows
                      More Kermit Diskettes Available
                                 MSBPCT.ASM
                        Amiga Kermit Initialization
                       Kermit Documentation in French
                  Review of MS Kermit 2.29 vs ProComm 2.3
                            Kermit on IBM MVS/XA?
                        Suggestions for Fortran Port

----------------------------------------------------------------------


Date: Wed 3 Sep 86 17:23:51-EDT
From: Christine M Gianone <[e-mail]>
Subject: New Kermit for HP-1000
Keywords: HP-1000 Kermit

This is to announce a new Kermit program for the HP-1000 running either
RTE-6 or RTE-A, replacing both of the two earlier HP-1000 programs, as
discussed in Info-Kermit V4 #xxx and #yyy.  This program was submitted by
Paul Schuman of E-Systems, Inc, Greenville, Texas, who has also contributed
it to the appropriate HP user groups.  The files are in KER:HPM*.*.
Binaries (for RTE-A) are in KB:HPM*.*.  The old versions have been moved to
KO:HP*.*.

------------------------------

Date: Wed 3 Sep 86 17:37:23-EDT
From: Christine M Gianone <[e-mail]>
Subject: New Release of Sperry-1100 Kermit
Keywords: Sperry

This is to announce version 2.5 of Sperry 1100 Kermit from pAaul sTevens at
the University of Wisconsin.  The changes include conditional assembly to
make it easier to port to "standard" Sperry systems, increased maximum
record size from 800 to 2000, and error corrections.  The source file,
in Sperry assembler, is in KER:UNIVAC.ASM.

------------------------------

Date: Sun 10 Aug 86 10:21:58-EDT
From: Bill Hall <[e-mail]>
Subject: New Kermit for Use with Microsoft Windows
Keywords: Microsoft Windows, MS-DOS Kermit

I have developed a simple version of Kermit to run under Microsoft Windows.
I will be sending you the files via the mails on a floppy disk for you to
try.  It is strictly bare bones, but the multitasking aspect is really nice.

If you will put it on the system, I will maintain it and develop it further.

[Ed. - Thanks Bill!  The diskette was received, and the files have been
placed in KER:WIN*.* on CU20B.  Although this program is bare-bones (no
help, only dumb terminal emulation), it runs a lot faster under MS Windows
than regular Kermit does, and it has the advantage that it can be run in
several windows at once, for instance transferring two files simultaneously,
one on COM1 and the other on COM2, all in the background while doing other
work in the foreground.  The program is written in Microsoft C v4.0 (Windows
aware), using the supplemental Windows libraries, the Microsoft Resource
Compiler, and LINK4 v5.02.  It takes advantage of MS-Windows' built-in comm
and screen drivers, and is thus usable on any system that runs Windows.  It
requires a lot of memory and only runs at speeds up to 2400 baud.  It has
several typical Windows menus so a mouse is a near necessity.  This Kermit
program should not be confused with the other "Windows Kermit" for the PC
(WKERMIT), which implements windows in the other sense of the word, namely
the sliding window transport-level protocol.  The executable program is
KER:WINKRM.BOO, in Boo-file format, which can be translated to and .EXE
file using any of the KER:MSBPCT.* programs.  The 8-bit binary .EXE file
is available in KB:WINKRM.EXE, for those sites that can transfer such files
directly from CU20B.]

------------------------------

Date: Sun, 17 Aug 86 17:06:41 pdt
From: Randy Spencer <spencer@usc-oberon>
Subject: More Kermit Diskettes Available
Keywords: Kermit Diskettes

This is a copy of the letter I sent out to net.micro.amiga.  I am sending
it to you because I just noticed the file AADISK.HLP on CU20B and would
like to be included...

I am willing to send you a copy of Kermit for the IBM, C64, or the Amiga.
These are the most recent versions available from Columbia.  Send me $6.00
and your mailing address to:

    Randy Spencer {Keeper of the Kermits}, Box 4542, Berkeley CA 94704
                   ^^^^^^^^^^^^^^^^^^^^^optional

I prefer checks, they make good receipts.  I *will* include the sources for
Amiga Kermit on the disk I send.  I will include the sources for the IBM
Kermit if requested (but it is so hard to keep up with the changes, and I
cannot be sure that it will compile as I have not got all the compilers for
the IBM (I am just using the transformer)).  The sources for c64 Kermit will
not compile on the c64 (they were compiled on a mainframe) so there is
little use in downloading them.  There are some other utilities on the disk
and the .boo file is included if you want to modem someone else a copy of
the file.

                    Randy Spencer

[Ed. - Thank you for offering to distribute Kermit on diskettes, Randy.
Your name and terms have been put in the file KER:AADISK.HLP.  Are there
any other volunteers for micros we do not already have listed?]

------------------------------

Date: 27 Aug 86 14:14 EDT
From: [e-mail] (John Junod)
Subject: MSBPCT.ASM
Keywords: .EXE files

I have just completed a reconstruction of Kermit on a DEC Rainbow using the
MSVRB1.BOO file. The target machine had a Vanilla MS-DOS disk without BASIC
or a Terminal Emulator with file transfer.  It did have MASM and LINK. I was
able to capture the BOO file by using "copy aux mskermit.boo" (and you could
capture the msbpct.asm file by using "copy aux msbpct.asm") and sending a
control-z at the end from another MS-DOS machine connected to the Rainbow's
communication port. Since I was unable to find an assembly version of MSBPCT
I wrote the following to reconstruct MSKERMIT.EXE. (Note: you must have the
source BOO file on the default drive as MSKERMIT.BOO and the output will
always be MSKERMIT.EXE on the default drive.

If necessary do a "copy" or "rename" of your capture file before running the
assembled MSBPCT.ASM)

           Regards,

           John Junod
           Code 1821
           David Taylor Naval Ship R and D Center (DTNSRDC)
           Bethesda, Md 20084-5000

[Ed. - Thanks John!  The file is in KER:MSBPCT.ASM.]

------------------------------

Date: Fri, 05 Sep 86 01:50 EDT
From: CCPHIL@TUCC
Subject: Amiga Kermit Initialization
Keywords: Amiga Kermit
Cross-Ref: Commodore Amiga (see also Amiga Kermit)

I have found the following kermit initialization file useful for the Amiga,
when you want to emulate a standard ANSI terminal (like a VT100).  I have
used this with a PCI protocol converter and also a VAX VMS system.  The PCI
works well, but the VAX has problems in EDT when lines need to be scrolled
up from the bottom of the screen.

Note that the Amiga Kermit will configure itself based on the settings in
the Preferances screen for the serial line.  Insert the following lines into
a file s:.kermrc :

%
% Set up to 80 columns by 24 rows, position to (0,0), & clear screen
%
echo \\033[25t\\033[80u\\033[0x\\033[0y\\014
%
echo Kermit is initialized and 80x24 ANSI screen!

------------------------------

Date: Thu 4 Sep 86 16:12:48-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit Documentation in French
Keywords: French Kermit Documentation

A translation into French of the first part of the Kermit User Guide appears
in CiSi telematique's "Bulletin Technique", numbers 86/05-06 and 86/07-08,
available (I'm not sure how) from CiSi telematique, 35 Boulevard Brune,
75680 Paris CEDEX 14, phone [phone].  Thanks to Gerard Gaye.

------------------------------

Date: 22 Aug 86 05:23:44 GMT
From: [e-mail] (Pete Holzmann, Octopus Enterprises, Cupertino, CA)
Subject: Review of MS Kermit 2.29 vs ProComm 2.3
Keywords: MS-DOS Kermit, ProComm

THANK YOU to the many who responded to my recent request for info on
communications programs that properly handle flow control. This is a summary
of the responses and my subsequent experience:

The responses were almost unanimous in recommending either ProComm (2.3 is
the latest version) or MS-Kermit (2.29 is the latest). A kind soul sent me
MS-Kermit, and I picked up ProComm locally.

A review of the two:

Kermit: lots of options, but not really as flexible as the number of options
might lead one to believe.  Comes with one terminal emulator (VT102) and only
one file transfer protocol (Kermit, no sliding windows).  Can use 38.4
KBaud, a win.  Drives my LCD display at about 6 Kbaud.  User interface isn't
too bad once you know how to use it, but it is not at all intuitive (you
must 'Cancel Connection' to get to command mode, and that doesn't *really*
break the connection, fortunately!).  No dialing directory or other
niceties, although you *can* push into DOS.  File transfers are slooooowwww.
Running between two 8 MHz AT's at 38.4 KBaud, I could only push through
about 300 bytes a second!!!  Rather poor.  However, I didn't find any bugs.
It may not do a whole lot, but it works.

[Ed. - Actually, PC Kermit comes with 3 terminal emulators built in -- VT52,
H19, and VT102 -- plus the ability to run with external terminal device drivers
like ANSI.SYS or whatever.  2.29 is slightly slower than some previous
releases, but not THAT slow!  See below...]

ProComm: Great user interface, lots of terminal emulations, lots of transfer
protocols, lots of niceities including dialing directory that can also link
to destination-specific command files (for auto-login, etc).  Color,
windows, (even sound if you can stand it).  Very fast file transfers (even
good in Kermit, with sliding windows, but slower than the other protocols).
It is a 'shareware' program (kermit is from a University, presumably more
altruistic).  BUT A BIG BOO for all the bugs.  ProComm has a strong tendency
to lock up.  More so on AT's, but also on PC's.  It can happen when you
aren't doing anything, it can happen during file transfer, it can happen due
to problems in terminal emulation, it can happen... you get the idea.  I've
posted another article asking for help with these problems.  I just can't
trust ProComm.  Otherwise, it would be the greatest thing since sliced
bread.

[Ed. - Kermit has color too...]

Actually, there's two wish-list features I wish could be added to
ProComm or some other program:

1) Conditional branching and user-input in command files, similar to
   some of the capabilities of CrossTalk.

2) Putting something like CWEEP into the comm program, so that one
   could easily select the files to be block-transferred.  It would make
   unattended operation MUCH more useful! It would even be better if you
   could grab filenames off the screen (so you could get a remote
   directory, then just point at the files you want to download).

Again, thanks for the help! (My current status: using ProComm in general,
but using MS-Kermit when it is important that the job get done right without
system-reboot hassles).

[Ed. - The following comments about MS-DOS Kermit 2.29 performance on the
IBMs and clones come from Joe Doupnik, who put together version 2.29 and
is working on a new release, 2.29A]

At 38400 baud the effective speed ought to be well above 9600 baud (like
14-16Kb or so).  That's for the new version (2.29a) whereas the release
version (2.29) is the normal slow poke (say 3000 but not quite 300 baud).

MSKermit 2.29 is slower than 2.28 (please speed up if possible).  Well, the
test version of 2.29 on the previous disk is much faster than 2.28.  As an
example, transferring a plain text file, mssscp.asm in fact, between two
regular IBM PC clones at 9600 baud this morning took:
        132 seconds     with MSK 2.28
        67 seconds      with MSK 2.29a/test   same packet length as 2.28
That's a 2:1 speedup! Lower baud rates achieve less dramatic factors since
the transmission time is a greater proportion of the whole.  2.29a
at 38400 baud works, but the higher efficiency did not come cheaply.

Some additional comments since I have focused on that topic recently.  The
measured overhead of new 2.29a to move a character from one ramdisk to
another is close to 350 microseconds per character plus the time sending the
data on the comms link.  The per character time includes the major factor of
time doing (s-l-o-w) DOS file calls. I overlap as much packet construction
and decomposition as possible with i/o without going to extreme measures
(read that as expanded buffering + management code).  Screen writes are time
consuming but are less so now.  The release 2.29 (and earlier releases) had
high overhead associated with clock timing (for timeouts); this version does
not.  Earlier versions had real trouble with the serial port at high speeds;
this version has code written for high speeds.  A problem with all comms
programs is that items hanging on the clock tic block interrupts from the
serial port and cause data loss.  Examples are print spoolers, keyboard
enhancers, screen savers, pop up helpers, and so forth; it is amazing how
much time they eat.  With a scope attached to the comms line I observe a
series of 1000 byte packets to use 1.34 +/- seconds from ACK to ACK at 9600
baud; hence the timing figure above.  This is on a regular 4.77 MHz PC and
translates into an efficiency of 75% on the comms line.  In the test case of
transferring MSSSCP.ASM from hard disk to a ramdisk the new version gave a
throughput of about 507 bytes/sec (5000 baud, 33950 bytes div 67 seconds)
end to end (or about 7200+ on the comms line) including all overhead of
prefix encoding chars, screen updating, packet header bytes, etc.  I think
the new Kermit will beat many or most X-modem implementations (certainly the
ones I have).  So, Kermit's efficiency is up this time around, and it can
run at much higher speeds than before.

------------------------------

Date: Thu 4 Sep 86 10:04:46-EDT
From: Walter V Dixon Jr <[e-mail]>
Subject: Kermit on IBM MVS/XA
Keywords: MVS/TSO Kermit?

Another GE site is trying to use an MVS version of Kermit under XA.  They
are getting an ijkmsg SYSDA not allowed.  Is there anyone they can call to
get help solving this problem?

Thanks

Walt Dixon

------------------------------

Date: Mon, 18 Aug 1986 01:49 PDT
From:   "Jeffrey Sicherman"  <[e-mail]>
Subject: Suggestions for Fortran Port
Keywords: Fortran Port

I would appreciate some advice from anybody who has done a kermit
port/implementation in FORTRAN or who is familiar with one or more of the
FORTRAN implementations.

  The machine is a minicomputer and has an old FORTRAN compiler ... Fortran
IV (which corresponds to FORTRAN 66, I think) and I would like
recommendations on which of the existing versions would be easiest to
convert. I could edit some new IF constructs, etc., but I wouldn't like to
use one if it was rife with such constructs. Maximum facilities would be
nice, but right now ease of conversion is primary. Please reply to me if
possible:

             [e-mail]

Thanks for any help.

------------------------------

End of Info-Kermit Digest
*************************


-------
10-Sep-86 16:54:28-EDT,20102;000000000000
Mail-From: SY.CHRISTINE created at 10-Sep-86 16:52:54
Date: Wed 10 Sep 86 16:52:54-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #7
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 10 Sep 1986       Volume 5 : Number  7

              Converting Kermit Distribution to 3 Tapes
               New (Minor) Release of C-Kermit for UNIX
                    Kermit 2.29 for the NEC APCIII
                 Uuencoded Files and Trailing Blanks
                        Kermit for NCUBE AXIS
                  Timing Problem with TOPS-20 Kermit
                     VAX to PC binary file xfers
             Being thrown into CP while using CMS Kermit
                      CMS KERMIT under VM/XA/SF?
    Kermit through 3708 Front End or WETRONIC Protocol Converter?
                    PRIMOS Kermit v. IBM-PC 2.29?
                  Kermit and Paradise Graphics Card?

----------------------------------------------------------------------

Date: Tue 9 Sep 86 17:26:35-EDT
From: Frank da Cruz <[e-mail]>
Subject: Converting Kermit Distribution to 3 Tapes
Keywords: Kermit Distribution

The collection of Kermit programs and documentation has once again grown
beyond the capacity of our most common distribution, 1600bpi 2400-foot reels
of magnetic tape.  We are now in the process of reorganizing the files from
2 groups (micros and mainframes) into 3 groups (micros, mainframes, and
esoterica).  Our major goal is to keep the most popular stuff on tapes A and
B, so that people who ordered these tapes before the changeover will still
stand a good chance of getting everything they want.  However, we must
create sufficient empty space on tapes A and B to allow the new Kermit
programs recently announced (and others waiting in the wings) to fit.

We'll try to do this as fairly as possible.  In the meantime, we'll be
installing new programs and files on CU20B without necessarily also putting
them in our other distribution areas or on our tapes.  When this rash of
installations (and announcements) is complete, we'll see how to most
equitably distribute the files.  Network access to Kermit files will be
unchanged, but during the transition some of the new files won't necessarily
be available at all of the distribution points.

------------------------------

Date: Tue 9 Sep 86 17:27:50-EDT
From: Frank da Cruz <[e-mail]>
Subject: New (Minor) Release of C-Kermit for UNIX
Keywords: C-Kermit
Cross-Ref: UNIX Kermit (see also C-Kermit)

This is to announce a new, minor release of C-Kermit for UNIX.  Because of
some mixups this past July, the new Amiga Kermit was installed in the Kermit
distribution with an inconsistent set of sources; the major reason for this
release is to remove this inconsistency.  Also, a few minor bugs are fixed.
Significant performance improvements and additional features will come in
future releases.  Here's a brief summary of what's in this new release:

Changes from Jack Rouse and Phil Julian of SAS Institute:
. Commodore Amiga support, replaces that from Davide Cervone of Rochester U.
  All-new CKI*.* files (this was announced in Info-Kermit v5 #3).
  This is the version written up in Jul/Aug 86 Amiga World.
. Revert CKUCMD.[CH] and CKUUS?.[CH] to their old selves (no more printf2,
  printf3, since these are no longer necessary for the Amiga), but add a
  few new Amiga specifics under #ifdef AMIGA conditionals.
. Fix multiline GET parsing to allow get back to top-level prompt if illegal
  local filename given (in CKUUSR.C).
. Supply a missing printf() parameter in CKWART.C.

Other changes:

Fix top-level parse loop in CKUUSR.C to reset any start state that might
erroneously have been set when a parse error has occurred.  Eliminates (for
instance) the spurious "?Sorry, you must set speed first" message if you
specify "foo bar" as the local filespec in multiline GET.

Make sysinit() return -1 if it fails, 0 if it succeeds, and have CKCMAI.C
check the return code.  Corresponding changes to invocation of sysinit in
CK[UVMI]IO.C.

Change references in CKUFIO.C to _file member of FILE structure to more
portable fileno() [suggested by Doug Orr, U of Mich].

In CKUFIO.C, change zclosf() to kill the fork before waiting for it to
terminate.

Fix Sys-V speed setting code (change "," to ";" between tttvt.c_cflag
statements) in CKUTIO.C.

Fix errpkt() function in CKCFN2.C to close open files, so that further
host commands can be done by the server after such a command is interrupted
abnormally [problem pointed out by Gregg Wonderly, Oklahoma State U].

Add Stan Barber's 4.3BSD acu control code to CKUTIO.C, under NEWUUCP
conditional.  I'm not sure if NEWUUCP needs to be defined in the makefile,
or what...

Version 4D(061) has been compiled and tested under Ultrix 1.1 (= 4.2BSD),
Ultrix 1.2 (whatever that may be a hybrid of), 2.9BSD on a DEC Pro/380, and
true 4.3BSD on a VAX 11/750 (4.3BSD includes an earlier version of C-Kermit
-- 4C(057) -- on its distribution tape).  The files that are new to this
version are in KER: on CU20B.  They are:

CKUCMD.C, CKUCMD.H, CKITIO.C
CKUUSR.C, CKUUSR.H, CKMTIO.C
CKUUS2.C, CKUUS3.C, CKVTIO.C
CKUFIO.C, CKUTIO.C
CKCMAI.C, CKUKER.UPD

------------------------------

Date:  Fri, 29 Aug 86 21:16 EDT
From:  [e-mail]
Subject:  Kermit 2.29 for the NEC APCIII
Keywords: MS-DOS Kermit, NEC APC3
Cross-Ref: NEC APCIII (see also NEC APC3 and MS-DOS Kermit)

          As we discussed almost two months ago, I have this version of a
terminal driver for the NEC APCIII which implements almost everything found
in the IBM PC driver plus some little goodies of its own.  Roger Link
(linkr%vtvm1) and I have worked together on debugging the present version;
he is now releasing it to his general (local) universe, which will no doubt
turn up additional bugs, but one cannot wait forever.

          I have put a note in the Boston Computer Society APCIII newsletter
offering to supply disks for users finding it inconvenient to get the source
from Columbia.  The same offer applies to the general world, which you may
publish in whatever manner is common.  The instructions are to send me 1
floppy to get the executable code, 4 floppies to get all the sources.  The
address is:
                    Robert Goeke
                    MIT Center for Space Research
                    Room 37-567
                    77 Massachusetts Avenue
                    Cambridge, MA  02139

[Ed. - Thanks!  We will distribute this stuff as part of the 2.29a release,
since corresponding changes have to be made to all the other incarnations of
MS-DOS Kermit.  Till then, those who are anxious to get it can get floppies
by mail as advertised above.]

------------------------------

Date: Sun, 03 Aug 86 22:35:31 EST
From:  [e-mail]
Subject: Uuencoded Files and Trailing Blanks
Keywords: Uuencoded Files

      If you use KERMIT under VM/CMS, it is hard to use uuencoded files such
as the uuencoded version of ST Kermit, since VM/CMS Kermit removes all
trailing blanks when downloading files.  Here is a solution to this problem;
it is a version of UUDECODE that supplies trailing blanks as necessary,
written to run on the Atari ST.  It is written in 68000 assembly language,
and can be assembled using the public domain assembler, AS68.

                                       David Moews
                                     [e-mail]

[Ed. - Thanks David!  The files are in KER:ASTUUD.*.  The trailing blanks
will be lost, however, if punched across BITnet.  See KER:ASTKER.BWR for
a more complete explanation and a SNOBOL program to restore the blanks.]

------------------------------

Date: Fri, 8 Aug 86 11:02:58 edt
From: couch <@CSNET-RELAY.ARPA,@TUFTS.CSNET (alva l couch):[e-mail]>
Subject: Kermit for NCUBE AXIS
Keywords: NCUBE AXIS

I now have a partially functional adaptation of C - Kermit 4.2 for the
NCUBE parallel processor running the AXIS operating system.

                Sincerely,
                    Alva L. Couch,
                    Dept. of Computer Science,
                    Tufts University,
                    Medford, MA, 02155

[Ed. - As soon as Columbia receives the files, we'll attempt to add
Alva's code to the current C-Kermit release, and announce when it's
ready.]

------------------------------

Date: Tue, 09 Sep 86 13:10:00 PDT
From: Bob Larson <[e-mail]>
Subject: Timing Problem with TOPS-20 Kermit
Keywords: TOPS-20 Kermit
Cross-Ref: KERMIT-20 (see also TOPS-20 Kermit)

After making a few improvements in my specialized kermit used to transfer
mail between USC's primes and other computers, (better timeout handling)
files started being duplicated.  (Cases of up to 26 have been reported.)  I
finaly traced the problem down: Tops-20 kermit (4.2(253)) frequently ignors
a GE (Generic Erase, i.e. Delete File) packet sent immediatly after an ack
to a B packet.  (Is the tops-20 clearing its input buffer before going back
to server wait?)  By adding a delay (20 seconds is probably a bit much, but
works) before sending the GE packet, this problem has dissapeared.  My
kermit implimentation cannot resend the GE packed after a timeout, since it
requests to delete the oldest generation of a file (-2) after it has been
transferred. (If the Ack of the GE packed was lost, repeating the GE packet
would erase a file that has not been transfered.)

A completly different solution to the problem would be to convince the
tops-20 end to tell me what generation of the file it is sending.  I'm not
sure I want to put the work into supporting atribute packets even if the
tops-20 end did.

[Ed. - What the DEC-20 Kermit server actually does in response to a GE
packet is to send back a whole transaction, in which the Data packets list
the actual files (including generation numbers) that were listed.  Thus you
don't get an ACK, you get a "long form response".  If you want to try to
pick out the filenames from the data packets you can do so, but this would
mean the Prime code would have to have special knowledge of the form in
which the DEC-20 sends this information.]

Another problem I have noticed with tops-20 kermit 4.2(253) is it wants a
control-v counted as two characters in a GE packet it receives, which does
not agree with my interpretation of section 8.2.1 of the kermit protocol
manual (sixth edition).  (The case of control characters is not dirrectly
discussed, so it is somewhat left to interpretation.)

[Ed. - If you want to quote a special character in a filespec sent to a
DEC-20 Kermit server, precede it by a Ctrl-V, just as you would do when
typing odd filenames directly to TOPS-20.  The data field of the generic
packet is formed before datalink-level encoding, therefore the little length
fields within the data packet of a generic command reflect the length before
encoding.  For instance, if you want to send a generic command to delete a
file called x.? (where ? is not normally a legal character in a filename),
the data field of the g packet would look like "E$x.#V?" -- $ indicates a
length of 4, AFTER DECODING (and before encoding).  Clear?  (ha)]

Bob Larson <[e-mail]>

------------------------------

Date: Fri 8 Aug 86 21:37:30-PDT
From: Dan Davison <[e-mail]>
Subject: VAX to PC binary file xfers
Keywords: VAX/VMS Kermit, MS-DOS Kermit

Someone asked about doing binary file transfers via kermit from an IBM PC to
a VAX.  A response indicated that it can be done.  I'm sorry to report that
response is wrong in some cases.

We routinely transfer files from VAXEN to uVAXen and other PCs (Pro 350,
Dec Rainbow, IBMPC Portable, a few others).  Vax has a binary file format tha
CANNOT be transfered using KERMIT.  They cannot (1) be transfered via KERMIT
VAX to VAX; (2) uVAX to VAX (or vice versa) and (3) PC to VAX (or vice versa).

It doesn't matter what parity, baud, stop,start etc. you use.  We speak to
a set of 785s, everybody running the same version of kermit.  The thing to
do is a

    DIR/FULL/ALL filename.EXE

If the record size is 512 (the usual for VAX executables and some special
format files made via FORTRAN and PASCAL) you are guaranteed to get garbage
after the transfer.  We have tried all sorts of ways around this, but the only
way that works is to copy the files over DECNET to a machine that has a tape
drive.

We also cannot transfer binary (.OBJ) files with Kermit.  The problem lies n
in KERMIT but the way the VAX keeps information in the file header.  You can
transfer the files, true, but they are useless and cannot be RUN or LINKed.

Non-DEC binary files, on the other hand, can be transferred successfully, re-
loaded and used.  I use our Microvax to backup my hard disk (until its
reacent headache (crash) courtesy of Federal Express.

If anyone wants further info, or knows of a way around this, please get in
touch with me at one of the addresses below.

Dr. Dan Davison, Dept. of Biochemical and Biophysical Sciences, SR-1,
University of Houston--University Park, 4800 Calhoun, Houston, Tx 77004

[Ed. - The normal trick is to SET FILE TYPE FIXED or SET FILE TYPE BINARY.
Did you try either or both of these?  (They are alleged to work, provided
the record length is 512.)  Of course, what VMS Kermit really needs is
attribute packets.  PDP-11 Kermit uses this to transfer the entire
FILES-11 FAB (or whatever it's called) along with the file, so it can be
properly reconstructed on the receiving system, provided it's also FILES-11.
Future releases of VMS Kermit may work somewhat better in this respect.]

------------------------------

Date: Fri, 01 Aug 86 23:19:27 EDT
From: Mark S. Feldman <[e-mail]>
Subject: Being thrown into CP while using CMS Kermit
Keywords: CMS Kermit

Recently, there has been discussion here about the problem of CMS Kermit
falling through to CP.  I've used CMS Kermit a lot, both here at the
University of Maryland and at several comercial sites.  Only one of the
comercial systems that I have used has ever thrown me into CP, and it was
doing it fairly consistently one day.  The problem was not with Kermit, but
with the over-loaded state of the computer.  I don't even think that having
control returned to kermit would have helped that day - the machine was
being thrown into CP because it could not keep up with the input.

What if you want to go into CP?

While preventing CMS Kermit from being thrown into CP might help some
people, I wonder if it might hurt some others.  What if you need to break
out of (server) CMS Kermit and for some reason the pc Kermit is unable to
transmit a finish packet, or any packet for that matter.  Wouldn't the
proposed change to CMS Kermit make it very difficult, and perhaps
impossible, to get out of CMS Kermit server mode if their were a problem
with the pc Kermit?

  Mark

[Ed. - When using the CMS in linemode through a 3705 or equivalent, then
almost any kind of framing or parity error can throw you into CP.  The
proposed change will continue Kermit where it left off, immediately,
whenever this happens -- a fairly frequent occurrence over dialups, etc.
It's still possible to break out if you're coming in as a 3270 through a
Series/1-style front end, and it may also be possible with a 3705 if
you type a lot of BREAKs in a row.]

------------------------------

Date: Tue, 19 Aug 1986 16:04 EDT
From: Nick Gimbrone <NJG@CornellA>
Subject: CMS KERMIT under VM/XA/SF?
Keywords: CMS Kermit

Has anyone succeeded (tried) in using CMS Kermit under VM/XA/SF?

[Ed. - CMS Kermit (any version) should work, provided VM/XA/SF has TTY
support (does anyone know if it does?).  In any case, Kermit should still
work on these systems through Series/1-style front ends.]

------------------------------

Date: Mon, 11 Aug 86 13:04:12 MEZ
From:  [e-mail]
Subject: Kermit through 3708 Front End or WETRONIC Protocol Converter?
Keywords: Protocol Converters

       We (id est: the Computer Center of the University of Bonn, West
Germany, where I work beside my studies), we want to run KERMIT on an
IBM3708 Protocol Converter.  Did anyone of yours already test this
configuration?  Did anyone of yours heard about someone *out in netland* who
has this configuration and/or has tested it and/or is using it.  Any notes
concerning this problem will be very welcome !!!!!!!!

[Ed. - The 3708 makes an ASCII terminal look like an SNA terminal, rather
than a local bisync 327x terminal.  There is no code in CMS or TSO Kermit
to handle these, and it's not clear that there ever can be -- for a protocol
converter to be usable for Kermit file transfer requires that it can be put
into transparent mode (and that the mainframe Kermit program know how to do
this); does the 3708 have a transparant mode, like the Series/1 or 7171?]

Did anyone *out there in netland* already succeded in a filetransfer using
KERMIT for conecting PCs to an IBM/370-series-mainframe via a Protocol
Converter WETRONIC PCI/1076?  We are able to run an emulation on this
configuration, but we still have problems when trying the file transfer
facility.  Any notes concerning this problem will be very welcomed.  Thanks
a lot for all your efforts in advance.  Have a nice day.  Please answer me
directly to:
                 Thorsten Glattki
                 Computer Center,Univ.Bonn,W.-Germany
My netaddress is : <UZR500%DBNRHRZ1.BITNET at WISCVM.WISC.EDU>

[Ed. - Similar considerations apply here.  Does the WETRONIC thingie have
a transparent mode?  If so, code can be added to mainframe Kermit to turn
this on and off, as it does for 7171's, etc.  Otherwise, forget it.]

------------------------------

Date: Fri, 29 Aug 86 11:14:58 BST
From: Chris_K_now-and-then <[e-mail]>
Subject: PRIMOS Kermit v. IBM-PC 2.29?
Keywords: Prime Kermit, MS-DOS Kermit

     Has anyone actually worked IBM-PC Kermit 2.29 against (any) PRIMOS
Kermit successfully?  If so a note as to the settings employed would be much
appreciated.  A friend at Salford is failing utterly.

                                          Chris Kennington.

[Ed. - This combination is in common use between The Source (which has
Primes) and their customers (many of whom have PCs).  However, most
accesses to The Source are through Telenet, which adds an additional
level of complexity.  The magic in that case, however, is simply "set
parity mark".  Do you have the most recent (May 86) version (7.57)?]

------------------------------

Date: Mon, 8 Sep 86 15:40:47 EDT
From: Kenneth Van Camp -FSAC-  <kvancamp@ardec>
Subject:  Kermit and Paradise Graphics Card?
Keywords: Graphics Card

    I recently replaced my old IBM monochrome (non-graphics) display
adapter with a Paradise Modular graphics card (still driving my IBM
monochrome display) on my PC-XT.  For some reason, the text display with
this board is noticeably slower than with the old mono card.  I can live
with this, but when I go into Kermit I am now dropping characters when in
the normal connect mode.  I tried slowing down the baud rate to 4800, and I
even told Unix to put in some fairly long pauses after every line (stty
cr3), to no avail.  I also tried both types of flow-control in Kermit, with
no effect.  It's important that I point out that nothing has changed except
the display adapter -- same modem, same Kermit, etc.  Yet Crosstalk XVI
doesn't seem to have the same problem; no characters are dropped at any
speed.  Does anybody know what's going on?

          --Ken Van Camp <[e-mail]>

------------------------------

End of Info-Kermit Digest
*************************
-------
15-Sep-86 09:40:29-EDT,25093;000000000000
Mail-From: SY.FDC created at 15-Sep-86 09:35:20
Date: Mon 15 Sep 86 09:35:20-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest, V5 #8
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Mon, 15 Sep 1986       Volume 5 : Number  8

Today's Topics:

   Prerelease Version of MS-DOS Kermit 2.29A Available for Testing
     New Release of Kermit for Concurrent (nee Perkin-Elmer) 3200
              New Kermit for Burroughs 7800 and A Series
                    Glut of Kermit Files (A Plea)
                        MS Kermit use of COM3
               CMS Kermit under VM/XA/SF Clarifications
                      Distributing TAKE scripts.
                     Kermit 2.29 for Tandy 2000?

----------------------------------------------------------------------

Date: Fri 12 Sep 86 13:45:15-EDT
From: Frank da Cruz <[e-mail]>
Subject: Prerelease Version of MS-DOS Kermit 2.29A Available for Testing
Keywords: MS-DOS Kermit 2.29A, IBM PC, Rainbow
Cross-Ref: DEC Rainbow, see Rainbow

A prerelease test version of MS-DOS Kermit 2.29A is available for testing
on the IBM PC,XT,AT and compatibles, and the DEC Rainbow.  This test version
is being released at this time mainly to help those who must use the program
for file transfer in half-duplex environments (e.g. with IBM mainframes or
certain HP or Harris minis) where line turnaround handshaking must be used;
version 2.29 has a bug that prevents this from working, and 2.29A fixes the
bug.

2.29A also includes some new features.  These are not necessarily completely
developed or polished in this test release, but they appear to be mostly
functional and usable:

. Performance improvements, particular on the IBM PC family.
. Support for extended-length packets, up to 1000 bytes long.
. A script facility, almost identical to the one in DEC-20 Kermit.
. A TRANSMIT command, for raw uploading.
. An ECHO command.
. VT102 ANSI printer control support (IBM PC family only).

Extended-length packets may be enabled using the SET SEND/RECEIVE
PACKET-LENGTH command, and will be used if the other Kermit program supports
them.  So far, only Kermit-11 (for PDP-11's with RSX, RT, RSTS, etc) does,
but version 3.1 of IBM VM/CMS mainframe Kermit, which will be announced
shortly (next week?) will also support long packets.

The script facility allows you to write "programs" of Kermit commands to
interact with the remote system.  Scripts are typically used for dialing
modems, logging in on remote systems, or performing other routine and/or
complicated interactive jobs.  The Kermit script is not a full-fledged
programming language (with variables, conditional branching, etc), but
differs from other popular script facilities by not differentiating script
commands from other program commands, so that all Kermit commands may be
freely intermixed in a script.  The commands that were added specially to
support script execution include INPUT, OUTPUT, PAUSE, ECHO, plus various
SET options.  The Kermit User Guide chapter for the DEC-20 (KER:K20MIT.DOC)
may be consulted for a complete description of the script facility.

Raw uploading is accomplished using the TRANSMIT command, which sends a
file "raw", a line at a time.  It works like DEC-20 Kermit's TRANSMIT
command, and may (like any other Kermit command) be used in conjunction
with scripts.

The ECHO command includes \ooo escape sequence recognition for including
arbitrary characters in octal notation.  This allows all sorts of fancy
special effects on the Rainbow by including VT100 commands in strings to
be echoed, and also on IBM PCs that have ANSI.SYS or similar console drivers
loaded.

ANSI printer support allows the PC to respond to host escape sequences
for printing selected regions of the screen, turning the printer on and
off, etc.

Version 2.29A is being put together by Joe Doupnik at Utah State University
([e-mail]), who also was responsible for version 2.29.  The performance
improvements, bug fixes, and long packet support were done by Joe, and the
script facility came from James Sturdevant at AC Nielsen in Minneapolis,
and Joe integrated it into the new release.

The files are in KER:MSTIBM.BOO for the IBM family and KER:MSTRB1.BOO for
the Rainbow.  Use any of the BOO-file decoders, KER:MSBPCT.*, to decode into
runnable .EXE files.  A brief guide to the new features of 2.29A is in the
file KER:MST29A.HLP.  No additional major functionality is intended for
2.29A, so please restrict your comments and suggestions to features that are
already in the program.  Note that the MST*.BOO files may be replaced from
time to time as bugs are reported and fixed, up until the final release of
this version.

------------------------------

Date: Thu 11 Sep 86 10:29:15-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Release of Kermit for Concurrent (nee Perkin-Elmer) 3200
Keywords: Concurrent Kermit
Cross-Ref: Perkin-Elmer Kermit (see Concurrent Kermit)

This is to announce version 2.1 of Kermit for the Concurrent Computer
Company (formerly called Perkin-Elmer) 3200 series under OS/32 7.2.1 and
up, by Paul Mamelka, Southwest Foundation for Biomedical Research,
San Antonio, Texas.  The major changes from version 2.0 of June 1985 are:

. Name change from Kermit-PE to Kermit-CO
. Horrible bug fixed caused by typo (RECKPT instead of RECPKT)
. Minor bugs also fixed
. First 3 letters of command or set option now sufficient for abbreviation
. SYSIO style now controlled by parity setting
. Selection of text, binary, contiguous file types
. End of record selection for text file transmission
. "File Warning" added (filename collision avoidance)
. Initialization file
. Automatic error logging

The new files replace the old ones as PERKIN.* in the Kermit distribution
(even though Paul sent them to us with the new prefix CON to denote the
company name change).

------------------------------

Date: Thu 11 Sep 86 11:44:59-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Kermit for Burroughs 7800 and A Series
Keywords: Burroughs Kermit

This is to announce Kermit for the Burroughs 7800 and other Burroughs large
systems (5000/6000/7000 and A series), written in Algol by Larry Johnson,
Dave Squire, and Katie Stevens at the Computer Center, University of
California at Davis.  The program and user manual are in the Kermit
Distribution as B78*.*, alongside the other Burroughs mainframe Kermits,
B68*.* (for the 6800, from Quest Research, Inc), and B79*.* (for the 7900,
from THE--Technische Hogeschool Eindhoven).  If any Burroughs aficionados
out there know if this new program makes either or both of the other two
redundant, please let us know so we can move them to a less critical area.

UC Davis has indicated willingness to supply this version of Kermit directly
to other Burroughs sites that request it directly from them.  The address is:

  David Squire
  Senior Programmer, ID-1023
  Systems Group, Computer Center
  University of California, Davis
  Davis, CA  95616  USA

------------------------------

Date: Fri 12 Sep 86 14:45:15-EDT
From: Frank da Cruz <[e-mail]>
Subject: Glut of Kermit Files (A Plea)
Keywords: Kermit Distribution

As Kermit's popularity escalates, more and more contributions of Kermit
programs show up on our doorstep.  We know what to do with many of them:
new ones simply get installed (though often a good deal of file renaming
is necessary to avoid conflicts), etc.  But what do we do when there are
multiple versions for the same system, or similar systems?  In some cases,
we can't really tell when a version is redundant, because we don't know
enough about the systems involved (like the Burroughs mainframes mentioned
in the previous message).  In other cases, two different people submit
totally different Kermit programs for the same system; should we keep both
(sometimes there are more than two!)?  It would be most helpful if we could
get some feedback from the people who actually use these programs.

Here are a few items we could use some help with, as we try to clean up
our Kermit collection:

Apple II DOS - Does anybody use the native 6502 assembler version that was
  based on an old release of the CROSS version?  (By the way, a new,
  native assembler version is under development at the U of Maryland, and
  work is also being done on a new release of the CROSS version.)

Burroughs - Are all 3 versions (prefixes B68, B78, B79) necessary, or can
  one or two of them be eliminated?

CDC - We have two CDC Cyber Kermits, one in Fortran, one in Compass.  Do we
  need both?  Is one more portable, or clearly better in other ways, than
  the other?

Commodore 64 - The "major" version is in CROSS, based on the Apple DOS version.
  CROSS only runs on DEC-10s and DEC-20s, most of which are not long for
  this world.  Does anybody care enough about the C-64 to translate this
  into a native assembler (if there is such a thing)?  And what about the
  other C-64 Kermit written in FORTH?

Data General MV Series with AOS, AOS/VS - We have several Kermits for these
  systems.  Most of these are quite old, primitive, buggy, and undocumented.
  There are at least 3 or 4 separate efforts underway to replace them.  I
  have urged the various people or groups to get together and settle on a
  single replacement.  Watch Info-Kermit for news, or read the file
  KER:AAWAIT.HLP in case you're interested in contacting any of these people
  directly (this file contains a list of all the Kermit programs that we
  know to be under development).

DEC PDP-11 - We have a main version (Brian Nelson's Macro-11 version) that
  runs on all the DEC operating systems, but there's also an old OMSI Pascal
  version just for RT-11.  Does anyone use the Pascal version any more?

DEC Rainbow - Does anyone out there run QNX on the Rainbow?  Have they tried
  QNX Kermit?  How about on the IBM PC?

DEC VAX/VMS - The main version is the Stevens Inst. of Tech. version written in
  Bliss, but also distributed in Macro-32 source form.  But there's also an
  old Pascal version.  Does anyone use the latter?  Also, is anyone using
  the VMS implementation of C-Kermit?

Gould/SEL 32 MPX-32 - We have two separate versions, both in Fortran, for this
  system, prefixes GM1 and GM2.  Do we need both?  Can GM1 be retired?

Honeywell - All this Honeywell stuff is a mystery to me.  In addition
  to Multics Kermit (we have one version of this, but have heard that there
  are several others floating around), there are two separate versions for
  GCOS (one in B, one in C, prefixes HDP and HG, respectively), and two for
  CP-6 (one in Pascal and one one in PL/6, prefixes HCP and HC6).  Do we
  really need all of these?  How about "Level 6" or DPS-6?  Can anyone who
  really knows the Honeywell world recommend a consistent, minimal set of
  good Kermit programs for the Honeywell line?

IBM 370 MVS/TSO - We have a couple different versions of Kermit for this
  system, but they will all soon be replaced by a new comprehensive release
  from the National Institutes of Health.

ICL/Perq - Does anybody still have Perq workstations?  If so, can they tell
  us if we really need two different Kermit programs for the Perq, both in
  Pascal?  (Prefixes PQK and PQ2.)  If not, which one is better?

Intel - There are literally dozens of Kermit programs for Intel micros,
  many of which we haven't either bothered to install.  Some are for RMX
  (or iRMX), some for ISIS.  Can anybody who knows about Intel development
  systems take a look at these and tell us which ones are redundant?
  In addition to the MS-Kermit 2.29 Intel support modules, we have
  specific Intel Kermit programs with prefixes RMX, I86, MDS, and MD2.

Software Tools - We have a version of Kermit written in Ratfor for use with
  the Software Tools library.  It reportedly runs on at least the HP-3000
  and the Sperry 1100.  Is anyone actually using it?  Does anyone know if it
  runs on any other systems?

Univac (oops, I mean Sperry (oops, I mean Burroughs)) 1100 - We have 3
  Kermits for this one: prefixes ST (Software Tools), UN (Assembler), and
  another UN (Pascal).  Can any of these be sacrificed?  At least, can one
  of them (say, the assembler version) be considered the "main" one?

Victor 9000/Sirius 1 with MS-DOS - In addition to the support in MS-Kermit
  2.29 for this system, there's also a C language version.  Is anyone using
  it?

Comments, comparisons, reviews, suggestions will be appreciated.  The more
redundant material we can retire, the more room we have for new Kermit
programs, and the less often we have to add new tapes to the Kermit
distribution.  Meanwhile, anybody who's considering writing a new Kermit
program or upgrading or fixing an old one, please contact Kermit
Distribution at Columbia before proceeding to make sure that your work
will not be duplicating someone else's.  Thanks!

------------------------------

Date: 10 SEP 86 12:12-MDT
From: JRD@USU
Subject: MS Kermit use of COM3
Keywords: MS-DOS Kermit, COM3

        In response to queries about use of more than two communication
ports with MS-DOS Kermit, I have compiled a few pointers.

        MS Kermit, internally, does allow many serial ports: four directly and
as many as wished through rebuilding. As we all realize MS Kermit tries to
connect directly to the serial port hardware (the UART chip, if possible
so that characters can be read by an interrupt procedure. Hardware details
differ greatly among MSDOS machines so code for serial port specifics
is located in the system dependent module MSX---.ASM.  The number of ports
visible on the Status screen is adjusted to match the kind of machine (model)
being used.

        The system independent part of Kermit has a standard table of four
named ports, expandable to whatever size is needed, which hold nine bytes
of information for each port. That information is the baud rate index, flag
for local echo on/off, parity type flag, flow control bytes and on/off flag,
and handshake (line turn around) character and on/off flag. Expansion thus
uses little space. The system dependent module(s) examine this table to
decide how to setup the particular port. The table is found in file MSSCOM.ASM.

        For IBM PCs and clones MS Kermit knows the hardware addresses
of COM1 and COM2, which have been specified by IBM. Higher comms port addresses
have not been standardized and thus are not mentioned in MS Kermit. However, it
is a simple matter to add new addresses to the list in MSXIBM and to readjust
the couple of tables which support the Set Port command (performed in MSXIBM).

        The most recent (September) issue of PC Tech Journal has an article on
boards offering many serial ports, together with the range of addresses
provided by each board. It is unfortunate that the addresses near standard
comms ports are frequently used by other add-in hardware so that no consensus
exists for COM3 et seq. and hardware conflicts are common.

------------------------------

Date: Thu, 11 Sep 1986 13:47:00 EDT
From: Nick Gimbrone <NJG@CORNELLA>
Subject: CMS Kermit under VM/XA/SF Clarifications
Keywords: CMS Kermit

To clarify my question concerning CMS Kermit under VM/XA/SF.  We currently
have and are running this operating system.  The CMS we are running under it
is esentially identical to CMS R4 under an HPO system (we don't yet have
FILELIST and that ilk of commands up and we have a small mod to XEDIT to
address an LDEV problem).  VM/XA does NOT support any TTY access.  VM/XA/SF
only supports 3270s (real, or fake as with the 7171).  When attempting to
run Kermit over a 7171 or Passthru (which works under VM/HPO and VM/SP
systems) under VM/XA/SF I get an addressing exception.  I will eventually be
looking at this, but if anyone has already solved the problem I'd appreciate
hearing from them via the net.  Thank-you.

------------------------------

Date: Thu, 11 Sep 1986 02:17 PDT
From:   "Jeffrey Sicherman"  <[e-mail]>
Subject: Subject: Distributing TAKE scripts.
Keywords: TAKE command, Script

Since one of the problems of using micro KERMITS with unfamiliar mainframes
is not knowing the necessary protocol parameters that may be required to
interface through front-ends and operating system peculiarities, a standard
way of distributing appropriate TAKE scripts on a system or site specific
basis would be desireable.  Why not bootstrap them?

     In particular, I would propose a

             CONNECT TAKE [filename]

command for the local system.  This would have the effect of CONNECTing to
the the host which should be running KERMIT in non-server mode (by
definition of the problems, we are not ready to send packets yet).  The user
would then enter a new command:

             GIVE [systemname]

on the host. Ignoring the optional name arguments for moment, the effect of
this would be that the local micro would interpret the lines coming from the
host not only as displayable data but as local commands, just as though a
local TAKE had been performed.  Most likely these would be SET commands:
(almost) anything that would be valid in a local TAKE file (it would not be
wise to switch ports or line parameters at this point or invoke any
transfers or change of mode).

[Ed. - Well... It's a good idea, but complicated.  The first pitfall is that
neither the host Kermit program nor the local one necessarily know what
parameters are really necessary -- for instance, if the connection goes
through an X.25 network, or bounces off a satellite, or is very noisy.  The
user is the only one who really knows.]

     Of course, a minimal subset of all possible commands would probably be
most appropriate for consistency across a broad range of micro
implementations; such a list would be sent when the GIVE is issued with no
systemname argument.  It would establish the minimum conditions for a usable
and reasonably efficient exchange.  Where differences are significant with
respect to different local systems, especially with regard to reliability or
efficiency, a systemname specification would send SETtings appropriate to
that combination.  I have stated this as systemname rather than filename
since there is no reason that the responses could not be built into the
program rather than increasing the number of distribution files.  This makes
it somewhat inflexible though, so there are good arguments on each side
(maybe I'm only arguing with myself) and I don't think the choice is
critical; either way will serve the purpose.

[Ed. - The problem here is that there are hundreds of programs to deal with,
and, because Kermit is a volunteer, cooperative, loosely organized effort
(at best), each program's syntax has its peculiariarities, despite the
efforts that have been made to settle on consistent terminology (e.g. in the
User Guide and Protocol Manual).  Does this mean we have to change 50 or 100
programs to make them conform?  Or does it mean that every mainframe Kermit
should have explicit knowledge of the variations in syntax used by all the
other Kermit programs?  Unfortunately, both alternatives are impractical.]

    The optional filename on the CONNECT TAKE command would cause the
received commands to be stored into a local file that could be TAKEn locally
for subsequent uses.  Admittedly, this is not an error-free exchange but the
errors are likely to be noticeable to the operator when rejected by the
command processor and the process can be repeated. By saving an error-free
transmission, it need only be performed once or infrequently.  For this
reason, a remote KERMIT implementation should probably announce the
existence of new values at initialization time when changes of significance
are made. If random (non-syndromatic) single character changes in
transmission are of concern (such as for decimal specifications of
block-check options, maximum lengths, framing character specifications) I
propose the following mechanism:

     Define a new command called VERIFY which takes all the same operands as
SET but merely compares its target value to the current setting. If a
discrepancy exists, display an error message.  By inserting SETs and VERIFYs
in the same GIVE transmission at appropriate intervals, most such errors
should be operator detectable.  The implementation seems rather
straightforward to me since the same parsing could be used with a global
mode switch telling low level logic whether a store/call or compare/error is
to be invoked.  A final possibility to minimize the possibility of an
erroneous transmission being used would to, either by default or command
variation, cause the commands in the take to be checked (and verified), but
only put into effect if no errors occur.  This could be accomplished by
having an edit-only pass on initial receive and rereading the take
destination file if error-free. If the no-file-name variation were used, the
take stream could be stored in a temporary file and/or an internal buffer.

[Ed. - Kermit already has an automatic way for each Kermit program to
"configure" the other one with respect to settings for buffer size, packet
terminator, padding, timeout, etc., namely the Send-Init negotiation.  These
packets provide a common intermediate representation for these parameters
and their values, something you don't get with textual SET commands, which
can vary from program to program (in fact, some programs don't have command
parsers at all, but use menus instead).  Unfortunately, not everything can
be negotiated in these error-checked packets.  Most notable are physical or
datalink settings like baud rate, parity, and flow control, because these
must already be set correctly before the Send-Init negotiation can take
place.  And, still more unfortunately, these parameters are often unknown
(and sometimes unknowable) to the programs themselves.  However, it is
possible to adopt some heuristics to get around some of the other problems,
and these can be fairly simple.  One example would be automatic parity
detection -- when the program gets the first packet (S, I, Y, G, etc, which
will never contain 8-bit data), it can figure out what the parity is, if
any, and then adjust itself accordingly.  This kind of trick seems more
practical and reliable than the proposed method of exchanging SET commands.]

------------------------------

Date: 11-Sep-1986 0946
From: [e-mail] (Gary Hafner, DEC Littleton)
Subject: Kermit 2.29 for Tandy 2000?
Keywords: Tandy 2000 Kermit

1) Does anyone out there know of a version of MSKERMIT V2.29 that's been
modified for the Tandy 2000? If not, could someone take a minute and explain
what it would take to do such a thing? Being a mainframe-type of user rather
than a PC user, I don't really know a heck of a lot about MS-DOS, but I have
a relative that could use this program if there were some way to come up
with it (who knows, between the 2 of us we might even be able to come up
with it ourselves...).

[Ed. - The version of Kermit we have for the Tandy 2000 was based on an
ancient version of IBM PC Kermit, namely 1.20, when it was still a
single-module program just for the PC, adapted by Steve Padgett at the U of
Texas in Feb, 1984.  The Tandy-specific code is under T2000 assembly
conditionals.  It would be great if somebody could look at this code and
churn out MSX, MSY, and MSZ modules from it, to fit in with the current
multi-module MS-DOS Kermit.]

2) I understand there's already 2 files for the Tandy 2000, and one of them,
a file with a ".FIX" extension, appears to be in a form similar to the
"MSxxx.BOO" formats for other machines. Could someone jot down the names of
the programs that both create AND 'unscramble' this format? I'm not familiar
with it at all.

[Ed. - The .FIX file was a precursor to the .BOO file.  It was a simple
4-for-3 (or was it 3-for-2?) encoding, but with no compression.  The program
to decode the .FIX file (this was the only survivor of the species) was in
TA2EXE.BAS.  However, as of now, both the .FIX file and the TA2EXE.BAS
program have been removed and replaced by a TA2000.BOO file, which you can
"un-boo" in the normal way, as described in MSBAAA.HLP.  The .BOO file is
only about 18K long, compared with the 30K .FIX file (and 15K .EXE file).
The 8-bit binary .EXE file is now available in KB:TA2000.EXE, for those who
can FTP it directly from CU20B.]

------------------------------

End of Info-Kermit Digest
*************************
-------
18-Sep-86 16:06:52-EDT,20563;000000000000
Mail-From: SY.CHRISTINE created at 17-Sep-86 12:16:56
Date: Wed 17 Sep 86 12:16:56-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #9
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 17 Sep 1986       Volume 5 : Number  9

Today's Topics:
          Announcing IBM Mainframe VM/CMS Kermit Version 3.1
                    MS-DOS Kermit 2.29A Prerelease
                      Announcing Kermit for DTSS
        CP/M-80 Kermit-80 Version 4.08 on Trial Release in UK
         Comment on MS-DOS Kermit vs Graphics Screen Display
                    Problems with Atari ST Kermit
                   Problems with MacKermit 0.8(34)

----------------------------------------------------------------------

Date: 1986 Sep 9   20:05 EST
From: (John F. Chandler) <[e-mail]>
Subject: Announcing IBM Mainframe VM/CMS Kermit Version 3.1
Keywords: CMS Kermit, IBM Mainframe

   This is to announce CMS Kermit Release 3.1 for IBM 370-series mainframes
running VM/CMS.  The new version has been consolidated into a single source
file, but there is a new, optional, separate program which can be used for
loading Kermit into high memory (thereby allowing Kermit to invoke any CMS
program).  An effort has been made to keep the CMS-dependent parts of Kermit
together (many operations are performed using MACRO's which could be
redefined to fit, for example, TSO), but there are still many spots in the
code which implicitly assume the CMS environment.

Below is a list of the more important additions in Version 3.1:

1.  Massive reorganization and cleanup of source code.

2.  Advanced server functions.

3.  Basic and advanced commands to a local server from remote mode, driven
    by TAKE command file.

4.  Long packet protocol (type 0 extended headers).  Allow arbitrary foreign
    filespec in SEND and GET commands.  Provide optional prefix and suffix for
    outgoing file headers.

5.  CWD and SPACE commands along with SET DESTINATION.  The default filemode
    for SEND is taken from CWD.

6.  TYPE, ECHO, XTYPE, and XECHO commands (the latter two being Series/1
    transparent-mode analogs of the first two, useful for raw downloading).

7.  REMOTE KERMIT commands honored by CMS Kermit server, including SET, SHOW,
    TDUMP, TAKE, CMS, CP, STATUS, and SPACE.

8.  TEST mode for debugging.

9.  Optionally append to, rather than, replace, old files with duplicate names.

10. Optionally keep files even when the transfer is cancelled.

11. Send Attribute packets with file size, host system, and possibly file
    type and record format.  Receive and ACK attribute packets.

12. Option whether to search only the "home" disk and its read-only extensions
    or all accessed disks when the filemode is omitted from filespec.

13. Automatic recovery from line-noise interruptions on TTY lines.

14. Multi-column, two-level selective SHOW display.

15. New help text for HELP command.

[Ed. - Many thanks!  Version 3.1 began as 3.0 (which was never released),
consisting mostly of source-level reorganization, cleanup, bug fixes,
plus new keyword parsing and a new help command, by Vace Kundakci of
Columbia.  John made further contributions, including the new server
functions, Attribute packets, new SET and SHOW commands, the new CMS chapter
for the Kermit User Guide, the new installation procedure, and more.  Bob
Bolch of Triangle Universities added the extended-length packet support,
Clark Frazier of the Harvard B-School added features for raw downloading
through the Series/1 (XECHO and XTYPE).  The new version should also fix
most or all of the bugs that were reported by many sites (particularly by
Greg Small at UC Berkeley) since the release of version 2.  The new files
are in KER:CMS*.* on CU20B.  The old ones will be kept on CU20B for a while
as KO:CMS*.*.]

------------------------------

Date: Tue 16 Sep 86 12:41:47-EDT
From: Frank da Cruz <[e-mail]>
Subject: MS-DOS Kermit 2.29A Prerelease
Keywords: MS-DOS Kermit

The MS-DOS Kermit 2.29A Prerelease that was announced in the previous digest
turned not to work with IBM mainframe Kermits.  It has been fixed in this
respect and replaced.  The new version is dated September 15 rather than
September 10th, and has been tested against VM/CMS Kermit with no problems,
using both 3705 (linemode) front ends and Series/1-style ASCII protocol
converters, and both regular and extended-length packets up to 1000 bytes in
length.  The test versions of MS-Kermit are in KER:MST*.* on CU20B and also
on KERMSRV as MST* * for BITNET access.

Also, as noted in the .HLP and .BWR files, when parity is set to NONE, all 8
bits of incoming characters are displayed on the screen during CONNECT.
This will cause consternation to users of systems (particularly the IBM PC
family) with 8-bit character sets.  This feature was added to accommodate
European and non-Roman-alphabet environments that really do have 8-bit ASCII
character sets, but it was erroneously tied to the PARITY setting.  In fact,
there are systems (like the DEC-20) which have 7-bit ASCII character sets,
but which send parity (e.g.  even) to the terminal, but don't require parity
coming from the terminal, and whose Kermit programs put the line into
transparent 8-bit mode for file transfer.  Until a new SET command is added
to select 8-bit or 7-bit terminal display, the workaround is to SET PARITY
SPACE during terminal emulation and to SET PARITY NONE for file transfer.

------------------------------

Date: Tue 16 Sep 86 13:11:57-EDT
From: Frank da Cruz <[e-mail]>
Subject: Announcing Kermit for DTSS
Keywords: DTSS Kermit

A new version of Kermit has been written for Honeywell 6000 mainframes
running the Dartmouth Timesharing System (DTSS) in "Virtual PL/1" (VPL1) by
Philip Koch of the Dartmouth Kiewit Computer Center.  This is a relatively
esoteric Kermit since there are not very many DTSS installations, and of
them, few have VPL1 compilers.  However, brief instructions are included for
converting to non-virtual PL/1.  There's no manual or help file, but there
are some comments at the beginning of the source file, which is in
KER:DTSS.PL1 on CU20B.  Thanks to Philip Crowell of Dartmouth for sending
the program to us on tape.

------------------------------

Date: 11-SEP-1986 17:01:26
From: [e-mail] (Alan Phillips)
Subject:  CP/M-80 Kermit-80 Version 4.08 on Trial Release in UK
Keywords: CP/M Kermit
Cross-Ref: Kermit-80 (see also CP/M Kermit)

Bertil Schou at Loughborough University in the UK ([e-mail] on
the UK JANET network) has now got his mammoth rewrite of Kermit-80 available
for test release. At the moment the files are available only by FTP in the UK
from his machine, but once the very worst bugs have been cleared we'll be
getting the files to Columbia for wider circulation. Bertil has sent in some
notes on what changes he's made: here they are:

Superficially,  there  is  little  real change  in  operation  of Kermit-80,
but  there  have  been some major jobs  tackled  like trapping BDOS calls and
multiple FCB buffering...

New bits for this version include:

               SET {SEND/RECEIVE} START-OF-PACKET character
               SET DIRECTORY-FILE-SIZE  (Shows  or hides  file  sizes  on
                       DIRectory displays)
               USER to set other user spaces
               RECEIVE to collect a file from a remote SENDer
               GET to collect a file from a remote SERVER
               SEND {local filename} {remote filename}
               TAKE to take command files from disk
               automatic  TAKE  KERMIT.INI  on default  disk  on  loading
                       KERMIT-80 (useful for SET BAUD etc.)
               much improved speed on DIRECTORY
               automatic  CLOSE-ing of a terminal connection if the  line
                       is  DROP-ped  (currently only for  an  Apple,  and
                       Torch  has  a dummy test for cntrl-] D in  connect
                       state)
               improved printer handling. (Kermit-80 sends an XOFF to the
                       host if the characters are comming in faster  than
                       they  are  printed.   This does not work  in  this
                       version,  as another option,  SET FLOW-CONTROL has
                       not been fully implemented - also,  I did not have
                       a printer to test this out on a Torch...)

On  the  negative side,  only LASM can be used  to  assemble  the source files.
I personally see no pont in being able to support several assemblers if LASM
can do the job, but then again, I have not  used  the MAC80 cross assembler...

All  source  files  have  been  renamed,  and  there  are  a  few additions.
All source files are named in the form:

               CPaxxx.ASM

where:

               a=S for system independent source files
               a=X for system dependent source files
               a=other letters for .HEX files etc.   These files have NOT
                       been created as yet.

The  system  dependent code has changed a  litle  too,  hopefully bringing  the
CPXSYS.ASM (formerly CP4SYS.ASM) file a  bit  more toward  a manageable  size.
There  is now the  possibility  for FAMILIES  of  systems,  like APPLE and
NorthStar  (also  Comart), which  contains  code  for computers of a single
type.   I  have immediately  gone against all this by creating a family with
the code for Torches, Cifers, Ithacas and Superbrains.  (This because we have
these systems here at Loughborough)

CPXSYS.ASM is largely unmodfied from CP4SYS.ASM.   Systems now in families
have their code duplicated in the relavent family file. CPXSYS.ASM  LINKs  to
the family file  if  appropriate.   In  due course,  I  hope to split off more
systems into "families" either on  their own,  or grouped  with other similar
systems.   I  know this is a half way step to true independent code for each
system, but  some systems are so close to others that I think it best  to group
them this way.

All VDU and terminal information is now held in CPXVDU.ASM.  This is really the
last section in the older CP4SYS.ASM file.

A quick "schematic" of what happens at assembly time...

        LASM CPXTYP... this then assembles the following:

        CPXTYP
          |
          v
        CPSDEF
          |
          v
        CPXLNK
          |
          v          (CPXSYS acts as a sorter for FAMILY switching)
        CPXSYS-------+----------+-----------+-----------+----
          |          |          |           |           |
          v          v          v           v           v
        (rest  of  CPXTOR     CPXAPP      CPXNOR       CPX???  one of
        CPXSYS)      |          |           |           |      several
          |          |          |           |           |      Families
          +<---------+----------+-----------+-----------+----
          |
          v
        CPXVDU
          |
        <END of assembly>

Users  should  be  aware  of  the  change  both  to  the  linking information
and start of the overlay address.   There are two new entries in the table,
family (offset 6) and lptstat (offset 20h). The  former is a two byte pointer
to a text string for  a  FAMILY (or  null  if not used) and the latter a JMP to
a routine  giving the status of the printer.   This can be done through  BIOS,
but not  through BDOS.   Users with odd sorts of printers may need to add their
own code here.

There  have  also  been some bugs fixed in  some  of  the  system dependent
code, so you would be wise pulling all the source files across.

The overlay address is now 5000h, and will probably change before this
revision  is complete.   The speeding up of  multiple  file handling takes its
toll on memory,  as there are now 64-ish  FCBs buffered.  This speeds up the
DIRECTORY command no end.

With  the overlay address at 5000h there is still a lot of  space free for more
things to be added (about 800h bytes).

Things yet to be done - lots!

There have been moves trying to add other independent modules for other
terminal  emulators  other than  the  VT52.   Demands  for SERVER,  REMOTE
HOST...,  file compression, better TRANSMIT, % of file  sent  and/or Kbyets
sent/received as part  of  the  display diring  transfers,  a lot of cosmetic
tidying up as well as  even more systems to be added.   CP/M-80 is a slowly
dying DOS,  and I feel  inclined to leave some bits out,  like SERVER (how many
use really  large  winchesters  in CP/M-80  systems,  and  want  true
servers?).    Does  anyone  have  a  burning  desire  for   these facilities?
And if so, will YOU be willing to take on the job of implementing them?

        Bertil Schou.

[Ed. - Above you see the future of CP/M-80 Kermit -- comments and
suggestions will be relayed to Bertil -- get them in soon, before it's
too late.]

------------------------------

Date: 14 SEP 86 18:44-MDT
From: JRD@USU
Subject: Comment on MS-DOS Kermit vs Graphics Screen Display
Keywords: MS-DOS Kermit

        In the Kermit Digest V5 #7 Kenneth Van Camp, kvancamp@ardec, said
that his new display board was causing MS Kermit 2.29 (but not Crosstalk) to
drop characters arriving from the serial port.

        The critical things here are: does the display board turn off
interrupts during screen scrolling, does it use the standard color card
display memory address (B800H, vs B000H for the monochrome card), does it
use interrupt request lines reserved for the serial port, and might its Bios
(if any) intercept the normal Int 10h video interrupt to implement things
its own way? An answer of Yes indicates slower processing of screen data.
The slowest screen operation on my EGA equipped system is scrolling (runs
about 16 millisec per text line), and scrolling can be caused by receipt of
a line feed (rather than a carriage return). Loss of characters indicates
the serial port interrupt could not be serviced before another character
arrived at the port. Common delaying items include print spoolers, screen
savers, and many other items, all of which tie on to the system clock tic
interrupt and block interrupts for extended periods. If the display adapter
also keeps interrupts off for milliseconds then things will get lost.

        When the screen is scrolled Kermit has a lot of work to do. Before
scrolling it copies the top (or bottom, as appropriate to the scroll
direction) line to an internal buffer, asks the Bios to do its slow screen
scroll, and then if need be writes a new bottom (top) line from a buffer to
the screen.  MS Kermit 2.29a has a speedier algorithm for all of this; but
still, the limiting factor is the Bios. If the display adapter were to turn
off interrupts during its Bios scroll operation then that's that.

        The MS Kermit command Set Term Color 10 forces a fast screen update
which may aid Kenneth; it causes snow on IBM CGAs.

        Regards,
        Joe D.

------------------------------

Date: TUE, 26 AUG 86 17:10:04 GMT
From: C20228 @ UK.AC.PLYM.B
Subject: Problems with Atari ST Kermit
Keywords: Atari ST Kermit

I have an ATARI 1040 ST with an ATARI C development kit. The kit has a
version of Kermit based on the old VMS/UNIX Kermit. This works but is not
really suitable for the uninitiated ATARI user (ie 1st Year Students). I
therefore set out to implement Bernhard Nebels GEM KERMIT 1.02 which you
have on file store at Lancaster.

1) Use VMS kermit to download the UUENCODED HEX files from LANC, get DECODE
program in C to decode above file. Compile DECODE program and feed it the
UUENCODED HEX files, results in KERMIT.PRG and KERMIT.RSC files now on disk.
Execute KERMIT.PRG it doesn't work !!! ATARI turns up its toes and displays
usual two bombs, then returns to desktop.

2) OK back to LANC file store, new message in 00BULL.TXT there is a new
version of the DECODE program in assembler, to correct missing spaces
problem. Right download it, and another copy of UUENCODED HEX file for good
mesure. Assemble DECODE program OK, now run it and feed it UUENCODED HEX
files, results in KERMIT.PRG etc etc.... execute Kermit ATARI experiences
fatal error, usual two bombs displayed, program returns to desktop.

3) OK now I'm really mad, back to LANC filestore. Transfer whole of ATARI C
source code (didn't really want to do it this way, but!). Write BATCH file
to compile all C source modules, link modules, KERMIT.PRG now appears on the
disk. Execute KERMIT.PRG ATARI treats us to a wonderful display of random
graphics and dither patterns, stand admiring random graphics for a while
before remembering that we are supposed to be running KERMIT. Try to regain
control of ATARI, to no avail, even reset leaves the machine with a duff
hard disk driver, finally resort to powering down and re-booting. Repeat
above three procedures on and off for about a week. finally give up in
disgust!!!!!

CAN ANYBODY HELP!!

Chris Rose
Micro-Support
Plymouth Polytechnic.

[Ed. - This is a good example of the paradox of Kermit -- you can't get
it unless you already have it...  Has anybody succeeded in making this
work?  Maybe a .boo file would be better than a UUENCODE file -- at least
.boo files don't have trailing blanks, and there's a .BOO-file decoder
written in C (KER:MSBPCT.C on CU20B).  It would also be most helpful if
someone could volunteer to ask as a provider of Atari ST Kermit diskettes,
or to induce an Atari user group to do it.  If this happens, please tell
us, so we can refer people who ask us.]

------------------------------

Date: Sat, 23 Aug 86 09:31:28 pdt
From: gould9![e-mail] (Joel West)
Subject: Problems with MacKermit 0.8(34)
Keywords: Mac Kermit

I've been using MacKermit for 1.5 years now and am very pleased overall.  I
use it every day even though I own two commercial (MacTerminal and
Microphone) programs which sit unused.  But... (You knew this was coming)

I'm having trouble with my MacPlus:
    1) The Receive dialog box is not compatible with HFS and
       looks quite bizarre.
    2) I was unable to map keys on the Plus to other values.
       (Has anyone else tried this?) My previous mappings
       from my 512 days work fine, though.

[Ed. - All of our Macintosh programmers disappeared after 0.8(33).
The current version, 0.8(34), consists mostly of VT102 emulation
improvements by Davide Cervone of the U of Rochester.  No work has been
done to accommodate the Mac Plus.  It has been suggested that the resource
file can be edited to make the Receive-file box look right for the Mac+, by
making it the same size as the Send-file box.  The keypad stuff mostly works
fine with the Mac+ (at least on ours), provided you start with the VT100
Keypad startup file that's supplied on our distribution diskette, and on
CU20B as KER:CKMVT1.HQX (and .DOC).]

Also, a lingering nit-pick from day one:
  When starting a new file, the transaction dialog box should
  pull down the "Transferred OK" message from the previous
  file, as it is confusing to tell whether the msg is left from
  the previous file or is a status on the current file.

If there are any lingering key problems on the European macs or the Plus, I
would recommend the article "Be a Keyboard Sleuth" (by Joel West) in the
August 1986 MacTutor.  I can supply a paper copy to anyone who's interested
in doing further work on MacKermit or K-Config.

    Joel West                 MCI Mail: 282-8879

[Ed. - Mac Kermit does indeed need work.  The major thing that needs to
be done to it is translation to a native Macintosh C compiler, so that
a VAX or other Unix system with the SUMACC tools is not required to
modify the program.  Several people have expressed an interest in doing
this, but I don't think anyone has really started.  Also, there doesn't
seem to be any concensus as to the best C compiler for the job.
Suggestions welcome, volunteers even more welcome!]

------------------------------

End of Info-Kermit Digest
*************************
-------
19-Sep-86 17:39:59-EDT,21262;000000000000
Mail-From: SY.CHRISTINE created at 19-Sep-86 17:39:03
Date: Fri 19 Sep 86 17:39:03-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #10
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 19 Sep 1986       Volume 5 : Number 10

Today's Topics:

        Alternate BITNET Kermit Distribution at University of Toledo
                      Os9 Kermit from os9 Users Group
                Using C-Kermit on VAX/VMS for Mail Spooling
                MS-DOS Kermit with Different Character Sets
                   More on Wanted: Kermit for the Apple][
                      Help with Installing VMS Kermit
                        VAX to PC Binary File XFERS
                     MVS/TSO and Apple II Kermit Gluts
                       Problems with Atari ST Kermit
                    Uuencoded Files and Trailing Blanks

----------------------------------------------------------------------

Date: Fri 19 Sep 86 14:31:37-EDT
From: Frank da Cruz <[e-mail]>
Subject: Alternate BITNET Kermit Distribution at University of Toledo
Keywords: BITnet

The collection of Kermit files at the University of Toledo VAX-11/785
is now being updated on a weekly basis.  BITNET sites that have trouble
getting a response from CUVMA (due to congestion) are welcome to try
KERMSRV at UOFT02.  To get started with KERMSRV (at either CUVMA or
UOFT02) give the command:

SMSG RSCS MSG xxxxx KERMSRV HELP (from CMS)
  or
SEND KERMSRV@xxxxx KERMSRV HELP  (from VAX/VMS with Jnet)

where "xxxxx" is either CUVMA or UOF02.  Thanks to Brian and to the
U of Toledo Computing services for helping to ease BITnet congestion.

------------------------------

Date: Fri 19 Sep 86 05:52:04-PDT
From: Bob Larson <[e-mail]>
Subject: Os9 Kermit from Os9 Users Group
Keywords: Os9 Kermit

Os9 kermit is available from the Os9 users group as disk 48.  (The latest
disk listing I have from them has this mislabeled as 68k only and lists disk
37 as the 6809 version.  The version on disk 37 has quite a few bugs that
are fixed in the version on disk 48.)  Since several things are determined
at compile time, it's a good idea to have the C compiler available even if
they claim to supply a compiled version.

Membership in the Os9 users group is $25/year and includes disk 0 and MOTD
their monthly newsletter.  Send Name, address, computer type, os9 type and
level, and disk format to:

The Os9 Users Group
Attn: Membership
9743 University Ave.
Suite 330
Des Moines, IA 50322

Disk orders from members should be sent to the same address, Attn: Disk
order.  Disks are $5 for 5", $8 for 8", $80 for the works on 5" 80 track
DSDD standard os9.  Disk orders are accepted from members only.

[Ed. - Thanks for the information.  This Users Group has been added to our
KER:AADISK.HLP file, with the terms outlined.]

------------------------------

Date: Tue, 16 Sep 86 09:44:36 pdt
From: varian![e-mail]
Subject: Using C-Kermit on VAX/VMS for Mail Spooling
Keywords: C-Kermit, VAX/VMS Kermit, Scripts

We use C Kermit (058) under VMS here.  I wrote some scripts that run kermit
unattended in order to send mail from UNIX to VMS.

[Ed. - Thanks for the scripts!  Since they are rather long, we've put them in
the Kermit distribution as CKVKER.SCR.]

------------------------------

Date: Wed, 13 Aug 86 16:40 N
From: Kimmo Laaksonen <[e-mail]>
Subject: MS-DOS Kermit with Different Character Sets
Keywords: MS-DOS Kermit, Character Sets

The internal translation feature allows MS DOS Kermit user to change
external character codes to MS DOS internal codes within Kermit, and vice
versa. This feature is mainly intended for text display and file transfer in
non-English speaking countries, where "national" characters in a remote host
are assigned to codes that have another graphics representation in a
"standard", ie.  Anglo-American, character set (some "standard" graphics are
replaced with national grahics - in terminals, line printers, etc.). In a PC
there is an extended character set, where both "standard" and "national"
characters can be intermixed in text files. The internal translation
supports full 8 bits, so it can be used to map different 8 bit character
sets to each other, too, like the DEC set (eg. in VT200 series) to the IBM
PC set and vice versa.

Without translation a text file prepared on the remote host will look
strange because the PC will display the "standard" graphics instead of the
national graphics, when the file is typed on PC screen via Kermit terminal
emulator, or when it is transferred to PC as a file with Kermit and then
looked upon with a text editor in PC.  Respectively a text file prepared in
a PC and transferred with Kermit to a remote host looks strange because
different codes are used to represent national characters in remote host
output devices.

MS DOS Kermit internal translation is an elegant solution to this situation.
There certainly exist separate programs to do the necessary code
conversions. One problem with them is that at least twice the file space is
required, which may turn out to be impossible in a PC if the file is large.
Another problem is the extra time required for running a separate conversion
program.  Translation overhead within MS DOS Kermit is negligible.

Translation does NOT affect the Kermit protocol, ie. translation  is
done  outside  Kermit  packet assembly/disassembly. The new commands
for translation are:

 SET XLATION object [parameter(s)]

The following objects are available:

 ALL       Affects all translations. Valid parameter values  are  ON
           or OFF. ON is the default !

 DISPLAY   Controls translation of characters received DURING Kermit
           terminal  emulation, ie. what is displayed on the screen.
           Does not (should not?) affect terminal controls, eg.  ESC
           sequences.

 PRINT     Controls translation of characters received and output to
           printer DURING Kermit terminal emulation.

 SEND      Controls translation when transferring files FROM the PC.

 RECEIVE   Controls translations when transferring files TO the PC.

Parameters:

 OFF       Turns translation OFF for the selected object. Respective
           translations  must  be  OFF  to properly SEND and RECEIVE
           binary files, eg. .EXE, .COM, etc.

 ON        Turns CURRENT translations on for  the  selected  object.
           The   Finnish   convention   is   the  default  for   all
           translations (guess why).

 INITIAL   Resets a translation table to an identity table  ie.  all
           possible 8 bit codes are translated to them selves. It is
           good practice to initialize a  translation  table  before
           starting to build a new translation.

 EXPAND    Copies the lower half, ie. first 128 translations, to the
           upper  half  of the selected translation table. This is a
           useful feature when only the 7 lower bits (as  in  ASCII)
           are meaningful and the 8th bit (ASCII parity) is a "don't
           care".

 CODE base nnn base nnn

           This parameter is  used  to  actually  set  up  a  SINGLE
           translation  in  the selected object's translation table.
           The first pair (base  nnn)  is  the  original  code.  The
           second  pair is the code to which it is to be translated.
           Base can be any of DEC (decimal), HEX  (hexadecimal),  or
           OCT  (octal).  The  actual  code (nnn) is a number in the
           selected base.

In addition there is a new command for terminal emulation:

 SET EIGHBIT value

It controls whether MS Kermit strips the 8th (normally  parity)  bit
(value  =  OFF,  the default) during terminal emulation, or if all 8
bits are used (ON). Passing all 8 bits is  useful  when  2  PCs  are
connected  together,  or when connected to a DEC VAX VMS set to pass
all 8 bits. Note that the DISPLAY and PRINT translations are applied
(if ON) AFTER the 8th bit is stripped off or passed on as it is.

Some notes:

The MS DOS Kermit translation is not intended for a lay operator. It
would  be best if somebody at a site prepared command file(s) to set
up (and enable) the required translations. It is usually too tedious
to give a note listing the necessary Kermit commands that a user has
to  type  in,  although  it's  possible.   TAKE,   or   even   using
MSKERMIT.INI,  is much easier. Anyway, since we didn't touch the SET
KEY  facility,  it  is  customary  to  include   tailored   keyboard
"translation"  command  files in local Kermit distribution floppies,
so adding a few new files (or including  them  in  SET  KEY  command
files) for the translations suits that custom well.

Some may think that the ability to define only a single  translation
for a single object at a time is too slow, but usually there are not
so many of them, well under 10 for the Finnish  character  set,  for
example. Even mapping a full 8 bit set to another, eg. DEC character
set to IBM PC, and vice versa, doesn't require  modification  of all
256  codes.  And when the translations are set up, they are normally
loaded from a file, which doesn't take long.

We have translation files for the Finnish language and  IBM  PC  (of
course!),  including  SET  KEYs,  which  we can send to Columbia for
redistribution. However, we think it's better  to  postpone  sending
anything  yet,  because  our additions to MS Kermit were done on the
2.27 version! We think it's better to wait until we have added  them
to  2.29.  After  that  we  hope that translation becomes a standard
feature in MS Kermit to keep all us non-AngloAmericans happy.

If you REALLY want something fast, send queries to:

  [e-mail], or
  [e-mail]

(We are connected to EARN/BITNET, only.)

[Ed. - Sounds like you've really attacked the problem head-on.  Still,
it's going to be tough to make everybody happy.  On the one hand you've
got all the different character sets -- Finnish, Swedish, German, Spanish,
etc. -- and on the other you've got all the different hardware -- the IBM
character ROM, the DEC version (with its multifarious "country kits"),
presence or absence of all different, incompatible graphics boards, etc.
I can visualize having dozens, maybe hundreds, of character-set files to
adapt each alphabet to each kind of hardware.  And then we have to deal
with people's personal preferences about which key should transmit which
code...  But still, this sort of thing is badly needed in the
non-Anglo-American world.  What do people think?  Kimmo, maybe when you
get your hands on 2.29a (when it's finally released) you can try installing
your translation code, keeping these questions in mind.  Like, maybe there's
a way to combine many mappings into one compact file...]

------------------------------

Date: 4 Sep 86 02:37:48 GMT
From: umcp-cs!cvl!umd5![e-mail] (Ben Cranston)
Subject: More on Wanted: Kermit for the Apple][
Keywords: Apple II Kermit, Uppercase Terminals

Some people suggested that although they have other means of transfering
stuff from their Unix machines to their Apples I should post Kermit
anyway.  So I sat down and started to upload the source.  I didn't get
very far.  The Apple ][ that I use doesn't have lower case.  Unix is
not very friendly to upper-case-only terminals that try to use Kermit.
(To try it yourself, next time you sign on, type your userid in upper
case.)

[Ed. - What Kermit are you using on Unix?  C-Kermit handles the
uppercase environment just fine, at least on 4.2BSD -- uppercase
filenames map to lowercase, etc, and since during file transfer the
line is open in rawmode, the Unix terminal driver's uppercasing does
not interfere with the packets.]

I got it uploaded to the Sperrysaur which is a case insensitive
machine.  Unfortunately it doesn't like lines longer than 132
characters so I'm gonna hafta do moby "join" commands when I get it
FTPed up here.

But this exposes a pathological problem.  It probably works if you
have the lower case stuff, but what should the response of Kermit be
to an unmodified Apple?  Should there be a force-to-lower-case option?
Suggestions?

Oh, the other feature this Kermit has is a 70 column display-to-hires
option.  It doesn't make it on a color TV, but it's barely tolerable
on my B/W set.  On a video monitor it should be better...

                    umd5.UUCP    <= {seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben
Ben Cranston zben @ umd2.UMD.EDU    Kingdom of Merryland Sperrows 1100/92
                    umd2.BITNET     "via HASP with RSCS"

------------------------------

Date: 9-SEP-1986 10:17:43
From: [e-mail]
Subject:  Help with Installing VMS Kermit
Keywords: VAX/VMS Kermit

  We've had some discussions in the UK newsletter lately with people having
trouble installing VMS Kermit and its help files on VMS. A couple of people
have contributed some ideas and command procedures to help the non-VMS
expert: I have them online here as VMSINS.HLP

        Alan

[Ed. - Thanks!  This file is in KER:VMSINS.HLP on CU20B.]

------------------------------

Date: 16-Sep-1986 0539
From: [e-mail]  (Cathy Fulton -- CXO Technical Training)
Subject: VAX to PC Binary File XFERS
Keywords: VAX/VMS Kermit

In response to the recent messages about transferring VMS binary files
with Kermit...

I xfer VMS binary files to and from a PC all the time using Kermit.  Well,
they're not really binaries, but hexified forms of binaries.

There are two programs, VMSHEX.MAR and VMSDEH.MAR, which are used to hexify
and dehexify any VMS binary.  You first hexify the file with VMSHEX and then
Kermit it to the destination.  The hexified file is a normal ASCII file, so
SET FILE TYPE TEXT.  Upon Kermiting the file back to a VMS system, run VMSDEH
on it to restore the file to its original state.

- Cathy

[Ed. - Preprocessing is always a way around this kind of thing.  VMSHEX &
VMSDEH not only hexify & dehexify the file, but preserve & restore the
FILES-11 stuff.  If you're going from VAX to VAX, you can also use Kermit
to send BACKUP save sets back & forth.  Still, it should be possible to
transfer fixed 512-byte-block binaries with Kermit-32, at least that's
what it says in the documentation.  Maybe this could be a hot topic at
the DECUS Kermit session.]

------------------------------

Date: Tue, 16 Sep 86 21:19 EST
From: [e-mail]
Subject: MVS/TSO and Apple II Kermit Gluts
Keywords: MVS/TSO Kermit, Apple II Kermit

We have been using a very nice MVS/TSO version of Kermit written in
assembler by Steve Blankenship of TUCC.  He has modeled this after CMS
Kermit, and it the nicest, most powerful version we have run across for an
MVS/TSO site.  It supports communications both through 3705/3725 front ends
and Series 1/7171 front ends and includes a server mode, initialization and
take files, optional log files, tab expansion, etc., etc.

Steve and Roger [Fajman] (of NIH) have been put in contact with the hope
that the two versions and the two authors could hash things out to come up
with a definitive MVS/TSO standard version.  Let's hope for the best.

[Ed. - Indeed they are in contact, and there will be at least one or two
releases soon, and there's a good chance that one or more of these will
be consolidated with CMS Kermit at some time thereafer.]

As for Apple II Kermits, both Ted Medin and Dick Atlee have been working on
very nice 80-column versions.  Ted's runs under DOS 3.3 and ProDOS and is
just about complete (although some distribution has already started on some
Apple II mailing lists).  From what I have seen of the source, it is being
done with the CROSS assembler.  Dick's version, as far as I know, is only
DOS 3.3, although it is done in Big Mac assembler - an advantage.  He has
been very busy lately, and I don't know how he is coming with it.  Both
myself and two other people I know of have been trying to work with Dick for
ProDOS versions of his work.

Again, in this case it would be very nice to consolidate all of this work to
one, nice version - although the release of the Apple //GS will probably
make that two versions now.

[Ed. - Ted's version has been received at Columbia, where Peter Trei,
the other Apple II Kermit person, has been trying to merge it with his
own latest version.  How this will stack up against -- or eventually be
consolidated with Dick's version remains to be seen.]

A major problem with versions for machines such as the Apple is the
non-communication with Columbia on distribution and availability.  If Apple
II users could follow the example (I hate to say this) of MS-DOS users, the
whole group would benefit.  Take version 2.29A of MS-Kermit as a solid
example of what can happen when people cooperate to produce one, good piece
of software.

Sorry for the verbosity, but this is a subject about which I feel very
strongly, and thus far my efforts to persuade people to work with and
through Columbia for their own sakes and for the sake of the best Kermit
versions possible have been met with much adversity (in the micro world).
Any suggestions on this topic would be appreciated.

Thanks for letting me blow off some steam.

Mark

[Ed. - Yes, people should consult with Columbia before starting work on
a Kermit program to avoid this kind of duplication of effort, not to mention
filename conflicts and other lesser headaches.  However, even when they do,
sometimes things fall through the cracks.  Anyway, we try to keep a record
of everybody who's working on everything in the file KER:AAWAIT.HLP, and
everyone who's interested in forthcoming versions is welcome to take a look
at it.]

------------------------------

Date: 19 Sep 86 09:26:06 EDT (Fri)
From: Michael Fischer <[e-mail]>
Subject: Re: Problems Installing Atari ST Kermit
Keywords: Atari ST Kermit

I had problems installing GEM Kermit, too, but I finally got it to work.
Here in a nutshell are what the problems were:

1.  The UUDECODE program distributed with Kermit (astuud.c) is written
for the Lattice C compiler.  To use it with the Alcyon C compiler distributed
with the Atari Developer's Kit, it is necessary to open the binary output
file with "fopenb" instead of "fopen"; otherwise, the file is opened in
text mode (ignoring the "b" mode flag") and every ^J in the output has a
gratis ^M inserted after it.

2.  Recompiling the sources as Chris Rose did is not sufficient, for
the resource files are *only* distributed in binary form.  A correct
program given a bad resource will crash, just as an incorrect program
will.  Thus, one has no choice but to get UUDECODE to work.

3.  Once I fixed UUDECODE, I successfully decoded both the Kermit
program and resource files and they worked without problem.  I also
rebuilt the program from the sources and it also worked with the
decoded resource file.

4.  There has been a great deal of activity lately on the INFO-ATARI16
bboard discussing the various problems people have been having with
UU-encoded files.  There seem to have been two or three independent sets
of problems:
(a)  Bugs in the UUDECODE program to run on the ST as described above.
(b)  Problems with the encoded file being modified during transmission
such as tab expansion, truncation of trailing blanks, or padding of
all lines to a given length.
(c)  For people who tried decoding on a mainframe and then transmitting
the binary files to the ST (often using the old Developer's kit Kermit),
forgetting to set binary mode on both the transmitting and receiving
Kermit.  After numerous reports of failures and then people bringing
these problems out in the open, success stories such as mine above
began pouring in.  So UU-encoded files *are* usable, but it can be
rather tricky to do it right.

I will contact the "New Haven ST's" user group to see if they would
be willing to copy GEM Kermit onto disks for people.

  Mike Fischer
  <[e-mail]>

[Ed. - See next message for another hint.]

------------------------------

Date: Sat, 13 Sep 1986  12:40 MDT
From: [e-mail]
Subject: Uuencoded Files and Trailing Blanks
Keywords: Uuencoded Files

I made a small experimental change to our version of uuencode to solve
the truncated trailing blank problem and it turns out to be
transparent to uudecode.  That change is simply to insert a "M" to
each uuencoded line just prior to the insertion of the CRLF.  BITNET
users accessing our system through our mail file server have voiced no
complaints since I made that minor change.

--Frank

------------------------------

End of Info-Kermit Digest
*************************
-------
25-Sep-86 18:11:13-EDT,17282;000000000000
Mail-From: SY.CHRISTINE created at 25-Sep-86 18:09:44
Date: Thu 25 Sep 86 18:09:44-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #11
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 25 Sep 1986       Volume 5 : Number 11

Today's Topics:

      New Release of QK-KERMIT (MsDos and CP/M Kermit in Turbo Pascal)
                       New Release 1.6 of KERMIT/TSO
                              Motorola Kermit
              New IBM and Rainbow .BOO Files for MS-DOS 2.29a
                        MS-DOS Kermit 2.29 Question
                       VMS File Attributes and KERMIT
                             Timing out on CMS
                      Re: Kermit BOO for HP Integral?
                       UNIX SYS/V Version of Kermit?
             UUCP and Kermit Server at Okstate returns to life
                              Kermit for C128?

----------------------------------------------------------------------

Date: Mon, 22 Sep 86 16:27 EDT
From: VIC@QUCDN
Subject: New Release of QK-KERMIT (MsDos and CP/M Kermit in Turbo Pascal)
Keywords: QK Kermit, Turbo Pascal

I am sending you version 2.6 of QK-KERMIT (an MsDos and CP/M Kermit program
written in Turbo Pascsal.)
In addition to the new Pascal source, I have sent the following files:
     1. hex file for MsDos (IBMPC) kermit with VT100 emulation.
     2. hex file with overlay file for a kermit with VT100/TEK4010 emulation.
     3. hex file for a KayproII kermit.
     4. updated installation documentation
     5. updated user documentation.
Both the MsDos versions will also contain code to handle the APL character
set.  You should replace the old files with the new files. The old files
which I didn't send are the same for the new version.  There is also a new
QKKER.SCR (Script source for the documentation) will also be sent.

[Ed. - Thanks, Vic.  The new files have been installed in KER:QK*.* on CU20B,
and in BITNET KERMSRV on CUVMA as QK* *.]

------------------------------

Date: 23 Sep 86  14:15 CET
From: Fritz Buetikofer <[e-mail]>
Subject: New Release 1.6 of KERMIT/TSO

Since May 86 some bugs in the version 1.4 have appeared.  And furthermore
some new commands have been implemented:

 * Bugs fixed and error handling improved in the routine which checks
   for the presence of a file (Check_Dsn).
 * New command TAKE to execute KERMIT-commands from within a file.
 * When displaying STATUS screen, you will find a notice, whether
   the INIT-file (KERMIT.SETUP) has been found or not.
 * New command SET ATOE/ETOA to modify the ASCII <-> EBCDIC translation
   tables, while running KERMIT.
 * New command SET INCOMPLETE, to specify what has to be done with a
   file when user aborts the transfer.
 * Update of SEND command, so that the user may specify a filename,
   which is sent to the micro (instead of generating one automatically).

Only the Pascal source file and the documentation were changed.  For the
very near future, I'm going to implement a STATISTICS command, handling of
attribute packets and (maybe) long packets.

Regards to all TSO freaks, F.Buetikofer, University of Bern (Switzerland)

[Ed. - Thanks, Fritz!  The new files are installed as KER:TS2KER.PAS and
KER:TS2KER.DOC, replacing the old version, on CU20B for anonymous Internet
FTP, and TS2KER PAS and TS2KER DOC on CUVMA for BITNET KERMSRV access.  This
version of MVS/TSO Kermit works only on linemode (3705-style) connections,
but it has many more features than the original TSO version.  Meanwhile,
watch Info-Kermit for announcements of at least two other new TSO Kermits on
the way, both with many advanced features, and both able to operate over
both linemode and Series/1-style connections.]

------------------------------

Date: 22 sep 86  17:07 GMT +0100
From: <RBG.XX@GEN>
Subject: Motorola Kermit
Keywords: Motorola Kermit, 68000

     After experimenting the high reliability of the Kermit file transfer
protocol, I promoted its utilization in my department.  Since we make a
heavy use of Motorola microprocessors I am writing a Kermit implementation
for 680xx processors based systems.

     The language used is assembly, and I think it may be processed by most
assemblers following the syntax defined by Motorola (I proved the 2500 A.D.
68000 cross assembler, the Motorola MC68000 cross assembler and the CERN
M68MIL cross macro assembler).  The key principle of this Kermit
implementation is machine independence (obviously stated that the processor
belongs to the 680xx family).  The system dependent part is composed by a
few routines, containing all the knowledge about the system's file structure
and I/O ports.  The program is thoroughly documented, thus allowing the
implementors to modify it easily, according to their need.

     This Kermit implementation has been written in order to be installed
also on those 680xx family based machines, which have no or not-standard
operating system, being often custom built for the solution of specific
processing problems.  At least in the high energy physics field, that
frequently happens.

     I think that the first version of the program will be ready in 1 or 2
months. If you are interested in it, I would be glad to send it to you, so
that you can distribute it.

                  Roberto Bagnara
                  Physics Department
                  Bologna University
                  via Irnerio, 46
                  40126 BOLOGNA
                  ITALY

                  DECnet address: 39948::MICRO
                  Bitnet address: [e-mail]

[Ed. - This will be announced when it is received.]

------------------------------

Date: 21 SEP 86 18:24-MDT
From: JRD@USU
Subject: New IBM and Rainbow .BOO Files for MS-DOS 2.29a
Keywords: MS-DOS Kermit

MSTIBM.BOO  and  MSTRB3.BOO are identified as MS Kermit 2.29 test 21 Sept 1986.

        The items of note are:

- new command to control width (7 or 8 bits) of characters displayed in
 non-file-transfer mode:
        Set Display  Regular | Serial | Quiet | 7-bit | 8-bit
 7-bit is the default width. Any two keywords above can be used together on
 the same command line. The Status display also shows the Regular etc type
 plus the 7-bit or 8-bit tag. 8-bit is ineffective if parity is other than
 None.

- Set Send Packet ### has been modified slightly to use this command to set
 the ultimate upper limit the size of outgoing packets. The default value
 is 1000. The Status screen still shows the active, negotiated, size. In
 practice this means MS Kermit will send packets of size "other end's
 requested size" or the Set Send Packet value, whichever is smaller; thus
 the user need not do anything to send long packets to an appropriate host.
 However, MS Kermit requests only standard 94 byte packets be sent to it
 unless the user specifically requests another length by giving the
 command Set Receive Packet ###. The limit of 1000 bytes is arbitrary and
 can be enlarged by changing the single parameter "maxpack" located in the
 header file and rebuilding; two lines of Help in mssset.asm should also be
 edited to match the readjusted maxpack value.

- Bug fixed: incompletely received files were not deleted when a transfer
 was prematurely terminated.

- Bug fixed: VT102 emulator did not always correctly position the cursor
 within a restricted scrolling region when the escape sequence
 ESC top; bottom r  was received.

        Regards,
        Joe D.

[Ed. - Thanks, Joe!  The new files replace the old ones as KER:MST*.BOO
(and KB:MST*.EXE) on CU20B and MST* * on CUVMA.  This should pretty much
complete the list of new functions for 2.29a; leaving only the tedium of
bringing all the other versions up to this level and testing them, and
then bringing the manual up to date...]

------------------------------

Date: Mon, 22 Sep 86 19:47 EDT
From: Michael G. Chan <seismo!mcnc!duke![e-mail]>
Subject: MS-DOS Kermit 2.29 Question
Keywords: MS-DOS Kermit

Is there any way to patch MSKermit to recognize the 43 lines mode of an EGA?
I can put the display in 43 lines mode but MSKermit always put the status
line on the 25th line when connected.

                        Thanks
                        Michael Chan
                        chan@duke

[Ed. - From JRD: There are no quick patches even though most of the code is
written for arbitrary sized screen. Some parts are specific about line
numbers (location of the status line, for example).  Also, my experience has
been that 43 line mode is such a hybrid (ega vs the rest of the Bios and
DOS) that it may not function well on machines having two display adapters;
I have such a situation. For a while I considered including more specific
ega mode support but quit when the quirks became too much. EGAs were
designed with most registers being write-only. Thus, the ega needs to be
managed; in turn, that is tough to do properly within an applications
program containing an inner program (terminal emulator).]

------------------------------

Date: 19 Sep 1986 2127-EDT
From: "Bernie AT&T:617-467-5664 LDP Workstations" <[e-mail]>
Subject: VMS File Attributes and KERMIT
Keywords: VMS Kermit

With a 'little bit' of trickery it's possible to send any file from VMS to
any other system and back to VMS.

Single files :
Use LZCOMP/LZDECOMP {base language C - an implementation of Lempel-Ziv-
        Welch compression} in {non-portable} VMS-specific mode.
        In this mode RMS-attributes are carried and reestablished
        at decompression. Use KERMIT to move the file.

Collection of files :
Use VMS BACKUP to generate a single 'Backup' save-set and then

        a. LZCOMP/LZDECOMP {see above}

or      b. VMSBAK.BAS {source language BASIC} to 'restructure' the blocking
           of the save-set to KERMIT's 512 bytes fixed records. Then
           use KERMIT to move and VMSBAK again to de-block back to original
           blocking {restriction - original blocking has to be multiple of
           512!!.

.. last {but not least}
single and multiple files

        Use Stevens Institute's VMSHEX and VMSDEH {source language MACRO} -
        and transmit the resultant 'hexified' files via KERMIT. This method
        (although the oldest) will generate the largest files for trans-
        mission via KERMIT and could therefore be the slowest one.

BTW 'standard' VMS executables can also be 'moved' by telling the
'receiving' KERMIT 'SET FILE TYPE FIXED'. However the above three 'choices'
will work in all cases - since LZCOMPRESS, BACKUP and VMSHEX all include RMS
file descriptors in the encoded file and reconstitute same.

[Ed. - Thanks, Bernie!  The VMSBAK.BAS program was already in the Kermit
distribution, and now the LZW-compression programs have also been added, as
KER:VMSLZ*.*; the file KER:VMSLZ.HLP explains the organization and contents
of the files.  The programs are written in C, and may be compiled under
VAX/VMS with VAX-11 C, on PDP-11s with DECUS C, or under Unix.  Thanks to
Martin Minow of DEC for adapting 'compress' to the DEC operating systems.]

------------------------------

Date: Mon 22 Sep 1986 16:26:54 CDT
From: Dan Theriault <DANNO@UIUCVMD>
Subject: Timing out on CMS
Keywords: CMS Kermit

Some of our users here type Kermit Receive on CMS and then realize too late
that they forgot their PC Kermit at home or whatever.  The result is that
they can't get out of Kermit so what they often end up doing is hanging up
their telephone and run disconnected on CMS for days.  They often wind up
using 80 percent of our CPU as Kermit searches and searches and searches for
an incoming file.  I've looked at the source to our Kermit and I found a
variable that claims to be the time-out counter for Receiving, but nothing
I've done causes it to work.

Any help?

Dan Theriault
University of Illinois at Urbana-Champaign

[Ed.- From John F. Chandler <[e-mail]> The normal method of
escaping from a Kermit protocol wait is to type a bunch of CR's at Kermit.
The number required will depend on the context: for the initial packet
exchange, the retry threshhold is 16, but after that the threshhold is
determined by the SET RETRY command (default 5).  There is no need to set
aside some special sequence of characters to abort a transfer "by hand"; all
it takes is the patience to type 16 carriage returns.]

------------------------------

Date: Fri, 19 Sep 86 11:33:29 cdt
From: seismo!uiucdcs!uxc.CSO.UIUC.EDU![e-mail] (Mark Zinzow)
Subject: Re: Kermit BOO for HP Integral?
Keywords: HP Integral Kermit

It seems the only boo files for Ckermit are for machines like the Amiga.
The HP does not come with a c compiler so having a boo file available from
kermsrv would be desirable.

[Ed. - Can anybody send in a Kermit .BOO file for this system?]

I was very happy when MSTIBM.BOO made it over the net.  Does anyone have an
application to run on an IBM mainframe using a 7171 or Series/1 type front
end, that utilizes the new print support for local printing of a mainframe
file (under VM/CMS) with kermit on the PC?

Mark S. Zinzow                        ARPA:  [e-mail]
Research Programmer                   BITNET: [e-mail]
Computing Services Office             UUCP: ihnp4!pyrchi!uiucuxc!zinzow
University of Illinois at Urbana-Champaign

------------------------------

Date: 15 Sep 86 20:25:20 GMT
From: [e-mail]
Subject: UNIX SYS/V Version of Kermit?
Keywords: UNIX Kermit

Does kermit now cooperate with uucp?  That is, does it know how to create
the uucp lockfiles for a device, so that uucp won't wake up and stomp on
kermit's toes?  Of course, if it doesn't, it would be easy enough to modify
kermit, if only we had the source.

[Ed. - Yes, C-Kermit includes code to "cooperate" with uucp.  BUT...  Every
version of Unix wants this to be done a different way, and every site tends
to change it again.  And then come the perennial questions: what is the name
of the lock directory?  what are the lock files called?  should the lock
directory be publicly writeable, or should Kermit be sutuid'd or setgid'd to
it?  Should the lock file be empty, or contain the pid of the process that
has line locked.  A quick look at ckutio.c (yes, the sources are widely
available, e.g. see next message) will show just some of the variations on
these themes, as will a perusal of many past issues of this digest...]

------------------------------

Date: Sun, 21 Sep 86 15:18:51 -0500
From: Mark Vasoll <[e-mail]>
Subject: UUCP and Kermit Server at Okstate returns to life
Keywords: Okstate, UUCP

The UUCP and Kermit Server services at the Oklahoma State University
Department of Computing and Information Sciences are back on the air again.
The information in the okstate.txt blurp still contains the correct access
information.

One side note though, since we reactivated the dial-in line on Sept 16th,
someone's system has been dialing us every 15 minutes, 24 hours a day and
using the uucpker login and password.  Since this type of thing is easily
automated and forgotten, and since the system in question doesn't get far
enough into the UUCP protocol to identify itself (so I could send the system
manager a mail message), I am making this public plea for everyone who even
*might* have something like this set up to go take a look before your phone
bill hits the mega buck level.

Thanks,

Mark Vasoll
Department of Computing and Information Sciences
Oklahoma State University
Internet:   [e-mail]
Obsolete:   [e-mail]
UUCP:  {cbosgd, ea, ihnp4, isucs1, pesnta, uokmax}!okstate!vasoll

------------------------------

Date: Fri, 19 Sep 86  20:47:40 EDT
From: [e-mail]
Subject: Kermit for C128?
Keywords: Commodore Kermit

Are there any plans for a version of KERMIT-65 for the COMMODORE 128 in 128
mode?  I have all kinds of problems with the COMMODORE 64 version, and it
would be very convenient, I think, for all COMMODORE 128 users to have a
128-mode version.  An ideal program would be one similar to the other
kermits, but one that redefined the 128 character set for special unix-type
characters (backslash, curly braces, tilde, etc.), worked in 80-COLUMN mode,
emulated a VT-52, and could take advantage of the 8502 microprocessor's
2-MHZ speed, at least during actual file transfers, and prefereably always
when in 80-column mode.  If anyone has plans for this, I would be happy to
help out.  I don't know 6502 assembly language, but I do know BASIC, Pascal
and C quite well.  If anyone knows of any plans for a 128 version, please
let me know!  Thanks!

Matt Kimmel,
[e-mail]   <BITNET>
[e-mail]  <ARPANET>

------------------------------

End of Info-Kermit Digest
*************************
-------
 6-Oct-86 17:34:20-EDT,18576;000000000000
Mail-From: SY.CHRISTINE created at  6-Oct-86 17:32:22
Date: Mon 6 Oct 86 17:32:22-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #12
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

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 <[e-mail]>
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 ([e-mail]).
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 <[e-mail]>
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: [e-mail]
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 [e-mail]1 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 <[e-mail]>
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 <[e-mail]>
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 <[e-mail]>
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![e-mail]
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 <[e-mail]> [e-mail] 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
*************************


-------
 8-Oct-86 17:25:46-EDT,6730;000000000000
Mail-From: SY.FDC created at  8-Oct-86 17:24:12
Date: Wed 8 Oct 86 17:24:12-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V5 #13
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed,  8 Oct 1986       Volume 5 : Number 13

Today's Topics:
                        Kermit Book Available
                       New C-Kermits on the Way
                     Other New Kermits On The Way
             Re:  Screen Saver Feature as Part of Kermit

----------------------------------------------------------------------

Date: Wed 8 Oct 86 11:35:52-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit Book Available

The Kermit book is finally in print.  Thanks to all the members of the
Info-Kermit community who provided information, responded to queries, read
drafts, and helped in other ways, and especially to Don Knuth for contributing
the Foreword.  And thanks are due, perhaps even more, to all of you who have
kept Kermit alive and growing over the years by generously contributing your
time and effort to its design, development, and distribution, and to the
keepers of the computer networks that have made the rapid spread of Kermit
information and programs so easy.  Kermit is truly a community project.  I
tried to fit as many of you as I could into the acknowledgements, and
apologize in advance to anyone I might have missed.

The book is called "Kermit, A File Transfer Protocol," (author me), published
by Digital Press.  It does not replace the Kermit User Guide, because specific
Kermit programs are not described in detail, but it supplements it by
discussing motivation, commands, operation, and tricks in greater detail, and
filling in more background -- there are tutorials on file systems and on data
communications (RS-232, modems, cable-building, etc), plus many new tables,
diagrams, pictures, summaries, a glossary, etc etc.  There's a troubleshooting
guide, a new bootstrapping technique including a "baby Kermit" program in
BASIC short enough to type in to a PC, hints to programmers for writing and
submitting Kermit programs, etc etc.

The book does, however, replace the Kermit Protocol Manual; it presents the
protocol in more detail, and (I hope) more coherently, than the PM, and
includes program fragments from a bare-bones version of C-Kermit to illustrate
each facet of the protocol, in a much more layered and structured fashion than
was done before (but the PM will still be kept around).

It will take some time before the book reaches the bookstores, since it only
left the bindery this week.  In the meantime, it can be ordered direct from
Digital Press by calling 1-800-343-8321, order number EY-6705E-DP.  It is also
being distributed this week at DECUS in San Francisco, but reportedly it's in
short supply.  Anyone who has checked the book box on Columbia's Kermit order
form should be getting their copies within 2-3 weeks, maybe sooner (we'll send
them out as soon as we get them).

Disclaimer: I am obviously biased about this book.  Reviews, favorable or
not, will be most welcome and will be published in the Info-Kermit digest.
Reports of mistakes, typos, etc, are also welcome (so they can be fixed in
the next printing, if any) as well as suggestions for changes to make in
future editions.

------------------------------

Date: Wed 8 Oct 86 11:45:52-EDT
From: Frank da Cruz <[e-mail]>
Subject: New C-Kermits on the Way

There is a lot of work underway to bring C-Kermit to new systems.  Below is
a brief list of the work in progress; the major intention is to prevent
duplication of effort, and to promote cooperation.  If you are working on a
Kermit program for any of the systems listed below, or know anyone who is,
please have them contact us, so we can put them in touch with the people who
are working on these projects:

Apollo Aegis
Apple II GS, CPW (windows)
Apple Macintosh (convert Mac Kermit to Lightspeed C)
Data General MV series, AOS/VS
MS-DOS
NCUBE parallel processor with AXIS OS
VAX/VMS (add more knowledge about VMS file system)

If you know of anyone adapting C-Kermit to any systems not listed above,
also have them contact us, so we can add them to the list.  Thanks!

------------------------------

Date: Wed 8 Oct 86 10:14:45-EDT
From: Frank da Cruz <[e-mail]>
Subject: Other New Kermits On The Way

Here are some other Kermit development efforts.  Again, if you are (or know
of anyone who is) doing any work along the same lines, please (have him/her)
contact us:

Apple II: (1) New CROSS release for DOS; (2) new release in native assembler.
  ProDOS support may appear in one or both of the above.
Apple III (yes Apple III)
CDC Cyber 170 Series: Various new versions, improvements to current ones.
CP/M-80: New release, will support many more systems more modularly.
CP/M-86, Concurrent CP/M-86: IBM PC
Data General MV Systems, AOS and AOS/VS: versions in Fortran, C, DGL
HP-9000 and 98x6 BASIC systems
Honeywell DPS6/GCOS6
IBM System/370 Series: Major effort underway to integrate CMS and TSO versions
Intel development systems (many separate efforts underway)
Japanese micros - many versions available through NEC or NTT
Motorola 68000 assembler version, OS-independent
Motorola development systems (Xormacs, VME, Versados, etc etc)
MS-DOS: Version 2.29a will be ready soon!
MUMPS-11 (improved version reportedly done, on the way)
Philips development systems
Pick Operating System (IBM PC, etc)

There are also many, many others of a less certain nature.  All of these
efforts are listed in the file KER:AAWAIT.HLP on CU20B (AAWAIT HLP on
CUVMA).

------------------------------

Date: Mon, 6 Oct 86 15:30:20 pdt
From: [e-mail] (Dave Tweten)
Subject: Re:  Screen Saver Feature as Part of Kermit
Keywords: MS-DOS Kermit, Screen Saver Feature

You don't need to put a screen saver feature into Kermit.  There are
several public domain terminate-and-stay-resident screen saver programs
available, any one of which can be started before running Kermit
(perhaps in an AUTOEXEC.BAT file), and which will be effective while
Kermit runs.  The Info-IBMPC source code library at USC-ISIB.ARPA has at
least two.  I wrote another (which has the user-settable time feature
you requested).  I'm sure many others exist in the public domain.  A
little asking around should net you one you like.

------------------------------

End of Info-Kermit Digest
*************************
-------
28-Oct-86 11:16:10-EST,20840;000000000000
Mail-From: SY.CHRISTINE created at 28-Oct-86 11:14:44
Date: Tue 28 Oct 86 11:14:43-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #14
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 28 Oct 1986       Volume 5 : Number 14

New York Mets:
   The Official Baseball Team of the Kermit File Transfer Protocol

Today's Topics:
               Call for IBM Mainframe Kermit Developers
                          Re: File encoding
                     Where to Get HP-1000 Kermit
                 Kermit Server at Bitnet node UOFT02
                          Prime Kermit 7.57
                        RT11 XM Kermit Problem
                           Mac connections
                          MS-Kermit options
                   Two Small Requests for MSKERMIT
                       MSKermit LOG suggestion
                        Kermit on Compuserve?
                   Problem with Kermit and DATAKIT

----------------------------------------------------------------------

Date: Thu 9 Oct 86 13:23:41-EDT
From: Frank da Cruz <[e-mail]>
Subject: Call for IBM Mainframe Kermit Developers
Keywords: VM/CMS Kermit, MVS/TSO Kermit

A lively discussion (and some work) is underway to merge the major IBM
System/370 series assembly-language Kermit programs, so that VM/CMS and
MVS/TSO Kermits can share common OS-independent modules (particularly
the code that implements the Kermit protocol itself).  Any IBM mainframe
Kermit developer or maintainer who wants to be involved in this
discussion should send me a note (as SY.FDC@CU20B, or [e-mail]).
This includes those who have any connection with the Kermit programs for
MVS/GUTS, MUSIC, and MTS, and who might be interested in integrating Kermit
into the various dialects of Wylbur, and possibly also with CICS.

------------------------------

Date: Sat 11 Oct 86 02:08:17-PDT
From: Bob Larson <[e-mail]>
Subject: Re: File encoding
Keywords: File Encoding

Here are a couple of file encoding schemes that Frank da Cruz missed in his
list:

btoa/atob 4.0: 5/4 encoding to printable characters, space not included.
Designed for use with (and comes with) compress 4.0.  Has header and trailer
lines so mail headers may be skipped and multiple files may be sent
together.  (Available for ftp from the mod.sources archives at
seismo.css.gov, I have an os9/68k version if there is interest.)

Motorola S record: 2/1 encoding to printable characters.  Designed for use
with eprom programmers, etc. so includes address specification.  (Number of
address bits vary between various S record formats.)  The only advantage of
this format that I know of is encoding/decoding programs come with os9.
Included for completeness.

Bob Larson

[Ed. - Thanks for completing the encoding form list Bob.]

------------------------------

Date: Wed 15 Oct 86 11:24:44-EDT
From: Frank da Cruz <[e-mail]>
Subject: Where to Get HP-1000 Kermit
Keywords: HP-1000 Kermit

In V5 #3 of the Info-Kermit Digest, a message was posted by Michael Terenyi
describing a new HP-1000 Kermit that solved all the problems of the previous
versions, that was available from Paul Schuman of E-Systems, Inc,
Greenville, Texas.  Some weeks later, we actually received, installed, and
announced this version in the regular Kermit distribution.  However, Paul
has been getting numerous calls, blank tapes, etc, ever since.  Although
Paul was kind enough to contribute his program to Kermit Distribution, he
does not have the time or resources to honor the high volume of requests
he's been getting for this program.  If you need it, please get it either
from Columbia (by mail order, or over the networks as HPM*.*), or else from
the international Hewlett-Packard User Group:

  Interex
  680 Almanor Avenue
  Sunnyvale, CA  94086-3513
  Phone [phone]

You probably have to be a member of Interex before you can order programs
from them.  Paul thinks they have Kermit programs for a large variety of HP
minis, workstations, and PCs, all on native media, which is a service
Columbia has not been able to provide.

------------------------------

Date: Wed, 15 Oct 86 12:43 EDT
From: <[e-mail]> (brian nelson)
Subject: Kermit Server at Bitnet node UOFT02
Keywords: Kermit BITnet Server

For those of you experiencing trouble accessing [e-mail] there
was a problem in the way it sent interactive messages back.  It was acting
as if it were a NODE and not a USER when sending messages.  This has been
fixed.

Also, please note that it responds to interactive messages only, files sent
to it with imbedded commands will not cause it to send files back.

Brian Nelson

------------------------------

Date: Tue, 21 Oct 86 18:35:15 GMT
From: [e-mail]
Subject: Prime Kermit 7.57
Keywords: Prime Kermit

   There is a bug in PR1ME Kermit version 7.57.

   If, when in SERVER mode, the user logs off with a BYE command on the
micro-Kermit, the NEXT user to get that PRIMOS usernumber can have problems
related to the PRIMOS KILL and ERASE characters.  It showed up in the
Sheffield Editor for us.

 The problem arises if other software expects that the PRIMOS routine ERKL$$
returns leading zeros in the words that give the user's KILL and ERASE
characters as documented in DOC3621-190 Subroutines Reference Guide page
10-23.  What is not documented is that when writing the KILL and ERASE the
leading byte of the words should be ZERO.  This is the only reason that
reading returns leading zeros!

   Unfortunately, PRIMOS Kermit uses leading spaces when writing these
values.  This in itself causes no problem as when Kermit exits SERVER mode
in all ways EXCEPT when it receives a BYE command, it restores the user's
KILL and ERASE characters with words it had read previously.  Again this
seems no problem as LOGO$$ restores the System default KILL and ERASE
characters so everything appears OK to the next user.  But logo$$ does not
seem to alter the leading byte of the words holding KILL and ERASE, hence
the problem.

   The simplest fix in PRIMOS Kermit is as follows:-

   In GENERIC_CMD.PLP, before
         call logo$$(0,0,' ',0,0,code);
   insert the line
         call xfer_mode(0,code); /* restore terminal characteristics */

   Ideally, the first call to erkl$$ in XFER_MODE.PLP should be fixed so
that it has leading zeros in the character strings it passes, but this needs
more changes to be made in the source.  The fix given is short and it works!
There may be a problem with forced logouts which this fix obviously won't
cope with.  The QUIT handler calls xfer_mode so there is no trouble there.

   This caused us no end of trouble to track down to Kermit!  It seemed an
epidemic had struck as more and more users hit this problem.  (The PRIMOS
command TERM -kill and TERM -erase fixes a user in trouble).  It didn't help
that we changed from Rev 19.3 to Rev 19.4 at the same time as we released
Kermit 7.57.

  Neil Brooks
  University of Exeter Computer Unit

[Thanks.  We will forward this message to the authors of Kermit.]

------------------------------

Date: Thu, 23 Oct 86 11:51 EDT
From: <[e-mail]> (brian nelson)
Subject: RT11 XM Kermit Problem
Keywords: RT-11 Kermit

 A problem with the RT11 XM version of Kermit-11 (K11XM.SAV) has been
reported. The symptom is that any command that requires additional prompting
for input, such as SHOW and SET, the prompt will be garbage.  Ie, the
command:

        Kermit-11>SHOW <cr>

should reply with:

        What:

The cause is the command table being swapped over by the command line
editor, thus making the pointer to the prompt text invalid. The correction
is made in K11CMD.MAC as follows. The lines commented with /55/ are the
corrections.

Brian Nelson
[e-mail]

[Ed. - Thanks.  The fix is in KER:K11.BWR.]

------------------------------

Date: Fri 24 Oct 86 13:13:29-EDT
From: Frank da Cruz <[e-mail]>
Subject: Mac connections
Keywords: MacKermit

There have been increasing numbers of questions coming in about how to
connect Macintoshes and Mac-Pluses to modems and directly to other
computers.  I hope the following details will help.  I won't go into any
detail explaining terms -- you can look them up in a data communications
book (or the Kermit book!).

The Macintosh serial port is not RS-232, it's RS-422 and uses different
signalling.  The Mac RS-422 port lacks the modem signals CD, DTR, DSR, RI,
and RTS, and any modems that expect to handshake with the Mac using these
signals will not work unless the handshaking can be overriden (e.g. by
setting configuration switches in the modem) or by fakeout wiring in the
modem end of the cable.

The Macintosh serial port connector has 9 pins rather than the customary 25
pins that RS-232 requires.  The Mac-Plus has an 8-pin "Din-8" connector,
which needs a special converter from Din-8 to 9-pin to make it "plug
compatible" with the original Mac.

Here are the Macintosh 9-pin connector assignments, and the corresponding
Din-8 assignments:

9-pin   Din-8    Signal
  1       4       FG     (frame ground)
  2               +5V    (not connected in DB9/Din-8 converter)
  3       4       SG     (signal ground)
  4       8       TD+    (transmit positive)
  5       5       TD-    (transmit negative)
  6       2       +12V
  7       1       CTS    (clear to send, or "handshake")
  8       6       RD+    (receive positive)
  9       3       RD-    (receive negative)

The cable that you need to connect the Mac to a modem or to another Mac may
not be readily available in a store, so you might have to alter or build one
yourself.  The parts (DB-9 and DB-25 connectors, pins, cables, tools, etc)
should be available from computer stores or in computer supply catalogs like
Inmac, Black Box, Misco, etc.

To connect a Macintosh to a modem, you need a male 9-pin (called DB-9, DE-9,
or D-9) on the Mac end.  Only pins 3, 5, 8, and 9 need to be connected.  On
the modem end, a 25-pin male DB-25 connector.  Four wires in the cable
should connect the pins in the two ends as follows:

Mac    DB-25
 3       7    Signal ground
 5       2    Transmitted data
 8       1    Frame ground
 9       3    Received data

Before testing this cable with your modem, be sure it's plugged into to
desired port (the present version of Kermit on the Macintosh, 0.8(34), works
only on the communication port, not on the printer, SCSI, or any other port;
this restriction may be lifted in future releases), and the baud rate is set
appropriately, usually 1200.

You should be able to dial the modem (if it's Hayes compatible) by typing
ATD and the phone number.  If this doesn't work, check the configuration
switches of your modem.  In particular, it must be in originate mode (ATD
puts Hayes-like modems in originate mode automatically), and it may need to
be instructed to ignore DTR (many modems require DTR signals from the PC,
but the Mac doesn't provide one).  For further details, read your modem
manual.

To connect your Mac to another PC, use a "null modem" cable.  Here is how
to set up a null modem cable with a Mac 9-pin (male) connector on one end
and a male DB-25 on the other:

Mac 9-pin     DB-25      The DB-25 end of this cable can be plugged into
                         any computer that has a female RS-232 DB-25 serial
3 SG ---+                port connector.  To connect a Mac with a PC/AT
        |                (which has a DB-9 connector, but with RS-232
        +---- 7 SG       rather than RS-422, signalling), use a regular Mac
        |                modem cable, described above, on the Mac, a regular
8 RD+ --+                PC/AT modem cable on the AT (available in stores
          +-- 6  DSR     and catalogs), and a female-female null modem
          |              (also available in stores and catalogs) to connect
7 CTS <---+-- 20 DTR     the DB-25 ends of each cable.
          |
          +-- 8  CD      To connect two Macs back-to-back, use a similar
                         trick: two Mac modem cables, plus a null modem.
5 TD- ------> 3  RD
                         Building, adapting, and testing connectors is
9 RD- <------ 2  TD      not everyone's dish of tea.  If it's not yours,
                         then take a copy of this message to a computer
         +--- 4  RTS     store and point to what you need.  If possible,
         |               try to test it there on a configuration similar
         +--> 5  CTS     to yours before paying for it.


Back to modem cables.  If your modem requires certain modem signals, and
this requirement cannot be disabled, you should be able to cajole the modem
into operation by using a null modem cable like the one above, but with

5 TD- ------> 2  TD

9 RD- <------ 3  RD

That is, the modem signals RTS, CTS, DTR, DSR, and CD are all faked in
the connectors, but receive and transmit are not cross-connected as in a
real null-modem cable.

------------------------------

Date: Thu 9 Oct 86 12:02:50-EDT
From: [e-mail]
Subject: MS-Kermit options
Keywords: MS-DOS Kermit

(1) - In a recent message to Info-Kermit, someone proposed that the MS-DOS
Kermit subcommand parser incorporate assumption of a "run" prefix for inputs
that are not specifically Kermit subcommands.  I suggest that, unless such
suggested feature is effected as a togglable option via Kermit's "set"
subcommand or as an equivalent togglable function, such proposed feature's
simplistic allure be resisted because the "feature" could potentially have
unintended side effects that would interfere undesirably with Kermit's
otherwise expected proper behavior.

As you are aware, the proposed run prefix assumption feature would send DOS
flying on PATH-related searches for each and every Kermit-level
nonsubcommand input, including typos.  For example, people who park their
harddisks when they run Kermit for long remote sessions would see this
behavior of the proposed feature put their disk in "drive."  The feature
might also necessitate that Kermit macros be named differently from programs
on the PATH which the "feature" would want to run -- clearly a cumbersome
and "nontransportable" requirement.

(2) - I much prefer to see Kermit continue to steer clear away from
special-interest "gimmeckery" such as commandline recall/edit, screensaver,
alarm and calculator functions, etc.  I have seen many users (beginner and
advanced but not intermediate) who often choose to use earlier (even buggy)
versions of MS-Kermit just because they want a bare-bones program without
the fancy-schmancy code even though they have ready access to V-2.29a!

(4) - A universally useful feature would be runnability of MS-Kermit with
DOS-level subcommands, switches, etc. -- e. g.:

   DOS>KERMIT -do MACRO1
or,
   DOS>KERMIT -take INIT1.

(5) - Without implying that Kermit should become a whole O/S with
development tools, compilers and the rest, I ask whether Kermit could indeed
not be modularized so that a core program could be run and then desired
features could be loaded optionally through subcommands that work on
external file contents -- that'll take care of memory size, extra features
and the rest of the complaints and suggestions, wouldn't it?  And, how about
an O/S-(in)dependent Kermit Function Module Protocol?  /Farhad

------------------------------

Date: Sat, 11 Oct 86 08:11:16 EDT
From: John C Klensin <[e-mail]>
Subject: Two Small Requests for MSKERMIT
Keywords: MS-DOS Kermit

With apologies for joining the litany...

1) It would be nice if the key scanning table were expanded so that the two
new function keys (F11 and F12) on the extended keyboards could be used.
Neither their scan codes, nor the function key names are recognized by 'set
key', and 'show key' does not even recognize that they are keys.

[Ed. - There's nothing in Kermit that prevents the new scan codes from
being recognized.  These keys simply are not generating them in the same
way the other keys generate scan codes.  Even on the previous keyboards,
some keys -- like Ctrl-1, Ctrl-3, Ctrl-4, etc, keypad 5, Sys Req, etc --
generate no scan codes.]

2) There is apparently no convenient way to display the [path]name of the
current local directory.  I can set it (with LOCAL CWD ...), or get a
directory of its contents (with LOCAL DIR), but can't just inquire about its
name.  The CP/M-86 versions do an approximation to the job by displaying the
kermit prompt in the form

   KERMIT86 DN>

where D and N are the drive and user number; MSKERMIT should have SOME way
to obtain this info without listing out the contents of the directory.

[Ed. - Right, this should show up in a future release.]

Similarly, it would be nice to be able to ask the thing to tell me to whence
I am logging.  I can, more or less, find out if logging is turned on, but
can't (at least as far as I know) find the name of the file to which logging
is occurring.

Both of these things take on added importance as the presence of scripts and
TRANSMIT make it more possible to tailor the kermit environment to the needs
of a particular [naive] user, introducing more confusion as to what has
happended when something goes wrong.

[Ed. - All good points.  Anything that can be SET should be capable of
being SHOWn.]

------------------------------

Date:    Wed, 15 Oct 86 07:29 EST
From:  [e-mail]
Subject: MSKermit LOG suggestion
Keywords: MS-DOS Kermit, LOG command

Being an avid user of IBM's 7171 controller via an IBM PC and MSKermit, I
might suggest the following modification to MSKermit's LOG feature: allow
one to strip escape sequences if desired.  Session logs of sessions through
a 7171 or Series 1 controller with IBM mainframes can be accomplished with
the escape sequence - F commands, but dumping screen at a time for more than
a few screens is anything but easy.  If an option was available for the LOG
function which would allow the user to choose between keeping the escape
sequences and stripping them, I believe its functionality would be greatly
increased.

Mark

[Ed. - Doing what you ask would introduce a whole new level of complexity
into terminal emulation, slowing it down significantly.  It would also add
dependence on the particular terminal being emulated, and on the system
doing the emulating.  In your particular case, a way around the problem
is to use CMS Kermit's XTYPE and XECHO commands, to send stuff "raw" to
the ASCII terminal, where it can be logged.]

------------------------------

Date: Mon 13 Oct 86 13:12:46-EDT
From: Dan Caldano <[e-mail]>
Subject: Kermit on Compuserve?
Keywords: Compuserve

Does anyone have any info about downloading files from Compuserve using
Kermit on a 512K Mac?  Am new to this sort of thing, and while I've mastered
downloading from our local DEC20 I must admit to being daunted by what I'm
reading on Compuserve (besides it's expensive just "grazing" through Compu-
serve) and in various magazines.  Anyone out there able to point out what
I'm missing?  Any help would be appreciated, thanks.

[Ed. - Good question.  Can some knowledgable Compuserve subscriber post
a message to Info-Kermit telling whether Kermit is available on Compuserve,
and if so, how to get at it?]

------------------------------

Date: Mon, 13 Oct 86 17:19:47 EDT
From: [e-mail] (Vernon Bradner)
Subject: Problem with Kermit and DATAKIT
Keywords: DATAKIT

I am trying to use Kermit over AT&T's DATAKIT packet switched data network.
Kermit file transfers work, but sometimes have many frame retransmits
resulting in much longer file transmit times.

The xmodem file transfer protocol has no such problems over DATAKIT.  Of
course, I would much prefer to use Kermit (especially since with Kermit I
can transmit several files at once, unlike xmodem).

Has anyone else had similar problems with Kermit and DATAKIT? Possibly I
just have the wrong settings in Kermit?

Any ideas you might have would be a big help.

Thanks - Vern Bradner ([e-mail])

[Ed. - Has anyone had experience using DATAKIT packet switched data network?]

------------------------------

End of Info-Kermit Digest
*************************
-------
 3-Nov-86 16:36:28-EST,14520;000000000000
Mail-From: SY.FDC created at  3-Nov-86 16:34:24
Date: Mon 3 Nov 86 16:34:22-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V5 #15
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Mon,  3 Nov 1986       Volume 5 : Number 15

Today's Topics:
                 Kermit Files Split into Three Groups
               New Release of Kermit for TRS-80 Model 4
                  Atari ST Kermit Diskette Volunteer
                       Re: CompuServe vs Kermit
           How to Display Connected Directory in MS-Kermit
                      Kermit vs Datakit Networks
                PROCOMM Kermit File Transfer Problems?
              KermitLANd: Suggestions to Improve Kermit
                Ideas for Kermit Distribution Overflow

----------------------------------------------------------------------

Date: Thu 30 Oct 86 17:08:01-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit Files Split into Three Groups
Keywords: Kermit Distribution, Distribution, Tapes, OK State, UUCP

The Kermits just keep rolling in.  In June 1985, the material became too big
to fit on a single 1600-bpi 2400-foot reel of labeled tape, so we had to
split the files into two groups: A (micros) and B (minis and mainframes).
In August 86, the collection grew too large for two tapes, and intallation
of some new versions was put on hold.  So now a third tape (C) has been
added.  Tape C is for "esoterica" (less popular versions of Kermit,
implementations infrequently requested from us, European and Japanese
versions, etc, and redundant versions) and for large documents -- the Scribe
source for the User Guide and Protocol Manual, the mail archives, etc.  The
AAVERS.HLP file tells exactly which group each implementation is assigned
to.  AAFILES.HLP explains in a bit more detail.

Apologies to anyone who feels slighted by having their favorite Kermit
version assigned to the "esoteric" tape.  The assignments were not totally
arbitrary and capricious, but were made mostly according to the frequency
with which people ask for (or about) these versions, with the goal of having
the three collections occupy about the same amount of disk/tape space (about
15MB each).  The most popular micro and mainframe Kermits remain on tapes A
and B, so that people who order these tapes in the "old way" will still most
likely get what they were expecting.

For network access, the procedures are pretty much unchanged.  FTP, NFT, and
KERMSRV will continue to work as before.  The file KER:AANETW.HLP has been
updated (along with all the other relevant files) to reflect the new layout.
Apologies for the disruption in KERMSRV service from Friday afternoon (Oct
31) to Monday afternoon (Nov 3) while the files were being reorganized.

As we announced a couple months ago, our major tape-making facility (a small
UNIX Vax) could not have its Kermit files updated until this reorganization
took place.  This has now been done.  Oklahoma State University, which keeps
a parallel Kermit collection for UUCP access, updates its files from this
VAX; hence OK State has not been getting new Kermit files since August.  We
will send them a new set of tapes this week, and the automatic updating
should kick in again after they have installed it.

------------------------------

Date: Fri, 31 Oct 86 13:01:26 -0600
Subject: New Release of Kermit for TRS-80 Model 4
From: Gregg Wonderly <[e-mail]>
Keywords: TRS-80 Model 4

This is to announce the newest version of the TRS80 Model 4 KERMIT.  This
version, 5.2, has many small bug fixes, as well as some major additions to
the program.  The changes are listed in detail in the file M4CHGS/ASM, but
the most important ones since the previous release (5.0) are bug fixes,
command restructuring (particularly SET FILE), transaction and debug
logging, and wildcards allowed in SEND and KILL.

Version 5.1 was never released.  There were also some changes in the
H19-filter that is now included in the distribution.  These changes include
the addition of a STRIP8 parameter to SETH19 that will allow the parity bit
to be stripped from characters before they are put on the display.

In this version of KERMIT, I have made some attempts to start reducing the
number of hardware manipulations that do not use the system SVC's.  However,
there are still many Model 4 specific operations.  I would like to begin
replacing the Model 1/3 version of KERMIT with this version, in the interest
of making more of the functionality of Model 4 KERMIT available to Model 1
and 3 owners.  If anybody is interested in taking on the task of doing this
for either machine, the help would be greatly appreciated.  Most of the work
will involve finding replacement code for routines that manipulate the Model
4 hardware (Display, Comm Line, etc...).

Any interested parties should send mail to me at the address below so that
there can be some sort of cordination of efforts.

Gregg Wonderly
Department of Computing and Information Sciences
Oklahoma State University

UUCP: {cbosgd, ea, ihnp4, isucs1, mcvax, uokvax}!okstate!gregg
ARPA:  [e-mail] or gregg%okstate.CSNET@CSNET-RELAY

[Ed. - Thanks, Gregg!  The new version replaces the old one as KER:M4*.*.
In the spirit of consolidating the hundreds of Kermit versions, I'd heartily
encourage anyone who cares about the TRS-80 Model 1 and 3 Kermits to get
together with Gregg and try to hammer together a common version for the
models 1, 3, and 4.]

------------------------------

Date: Mon 3 Nov 86 12:05:59-EST
From: Il H Oh <[e-mail]>
Subject: Atari ST Kermit Diskette Volunteer

I finally got Kermit running on my Atari ST.  I'd be glad to mail ST Kermit
diskettes to other ST users, if they'll send me a preformatted diskette and
a self-addressed, stamped return mailer.  My address is:

  Il Oh
  362 Riverside Dr. Apt. 10B7
  New York, NY 10025.

il

[Ed. - Many thanks!  Diskette volunteers are always welcome, as are user
groups and diskette services that are willing to provide Kermit diskettes by
mail order at low cost (say, in the neighborhood of $10).  If anyone out
there has a Kermit program on a diskette that's not readily available from
Columbia or other sources, you are heartily encouraged to volunteer as Il
has done, or to submit it to an appropriate user group or diskette service.]

------------------------------

Date: Tue, 28 Oct 86 21:40:12 est
From: [e-mail] (John McNamee)
Subject: Re: CompuServe vs Kermit
Keywords: CompuServe

To answer the query from Dan Caldano in Info-Kermit V5 #14: no, CompuServe
does not support Kermit.  They support XMODEM and two of their own protocols
(CIS "A" and CIS "B"), and are working on something like X.PC for concurrent
file transfer and terminal sessions.  I doubt they are going to support
Kermit since it was a major fight to get them to support XMODEM, and a lot
more of their users have XMODEM than have KERMIT.

John McNamee    <[e-mail]>       CompuServe: 70235,1345

[Ed. - Do the current protocols suffice?  Can everybody get at Compuserve
with an 8-bit transparent path, with buffers that never need to be shorter
than 132, etc?  Or do they all have CompuServe A & B on their micros?  If not,
then maybe those who need Kermit could start infiltrating and agitating...]

------------------------------

Date: Wed 29 Oct 86 15:05:29-EST
From: Peter Kanaitis <[e-mail]>
Subject: How to Display Connected Directory in MS-Kermit

In Info-Kermit Digest V5 #14, John C Klensin writes:

>2) There is apparently no convenient way to display the [path]name of the
>current local directory....
>
>[Ed. - Right, this should show up in a future release.]

Why not do a:

Kermit-MS>run cd
 or
Kermit-MS>run chdir

P. Kanaitis
Allegheny-Singer Research Institute
[e-mail]

[Ed. - Where there's a RUN, there's a way...]

------------------------------

Date: Wed, 29 Oct 86 08:02:46 est
From: ulysses![e-mail] (Philip S. Kravitz)
Subject: Kermit vs Datakit Networks
Keywords: Datakit

Unlike Vern Bradner (Info-Kermit Digest V5 #14), I use Kermit all the time
over Datakit networks and have not experienced any problems.  (I primarily
use the Unix version of Kermit although I have had no problems with the
MS-DOS version either).

------------------------------

Date: Wed, 29 Oct 86 16:10:04 PST
From: [e-mail]
Subject: PROCOMM Kermit File Transfer Problems?
Keywords: PROCOMM

I am having problems transfering files from an IBM-PC/XT using PROCOMM V2.42,
to a VAX/VMS V4.4 system running KERMIT-32> V3.1.066.  File transfers seem to
work fine with normal PCKERMIT/MSKERMIT V2.29, but will not work with PROCOMM.
Has anyone out there had any experiences with PROCOMM'S kermit file transfers
to a VAX ???

------------------------------

Date: Thu, 18 Sep 1986 15:28 PDT
From: "Jeffrey Sicherman"  <[e-mail]>
Subject: KermitLANd: Suggestions to Improve Kermit
Keywords: Kermit Protocol, Suggestions

My intention was to link several PCs with on onsite minicomputer.  Since
Kermit is already in the public domain and is implemented on numerous
machines, it seems to me that it could be suitable for this purpose if some
program changes were made to existing implementations and a very few
(perhaps even non-essential) packet/protocol changes were made for a
LAN-only environment.  Some of the considerations that have occurred to me
are indicated below, but I'm sure there are some features and complexities
that I have overlooked.

[Ed. - Jeffrey goes on to point out that a Kermit server is a lot like a
network file server, and then discusses problems of routing, station
identification, topology, media access & contention, file attributes, mail,
etc., at some length.  KERMIT IS NOT A NETWORK.  It's strictly for
point-to-point, user-initiated, temporary connections over serial
communication devices.  Furthermore, Kermit provides terminal emulation, NOT
virtual terminal service -- there's a big difference.  Kermit's design is
simply not amenable to layering of arbitrary kinds of network services --
especially interactive ones like virtual terminal service, SMTP dialogs,
etc.  All these problems have been solved already, and a lot of the software
-- particularly TCP/IP implementations -- is either in the public domain or
else relatively cheap.  Let's remember that the vast majority of Kermit
users are individuals with modems who couldn't care less about these issues,
let alone take the time to work on design and implementation problems that
take huge, PAID, programming teams years to solve.]

------------------------------

Date: Thu, 18 Sep 1986 00:19 PDT
From: "Jeffrey Sicherman"  <[e-mail]>
Subject: Ideas for Kermit Distribution Overflow
Keywords: Files

I noted the request for assistance in cleaning up the Kermit distribution
files in the recent digest (vol 5 no. 8) and the associated difficulties in
maintaining order in the system.  In response to this, I suggest the
following:

It would be useful to have a file that was a matrix of kermit
implementations.  The rows of this matrix would be the various
implementation; the columns would be features implemented.  This could be
restricted only to features defined within the Kermit protocol and standard
or could also include other esoterica but should at least include all the
defined features and such things as mode of operation.  The matrix entries
could be as simple as Y/N or X/- to indicate the compliance, or a level of
support (e.g.  checksum types) or could indicate parametric values (e.g.
maximum packet sizes) or the characters used for implementation (e.g.
prefixes).

     A couple of columns could also include annotations such as latest
version.  Multiple entries might be desirable where there are multiple
implementations or there is a new version in beta test; if so they should be
marked as such.  It would also be nice to have some figure of merit or
rating that indicates the reliability, quality of documentation, and ease of
use; this would probably be not scientific in nature but hell, one of the
advantages of development by controlled chaos is not having to adhere to a
lot of bureaucratic rules.

     Admittedly, a matrix of reasonable comprehensiveness would be rather
large and be difficult to present in printed form.  Therefore there should
be a native, master form of the matrix which is comprehensive.  This, I
expect, would take the form of a spreadsheet file (in native form and/or
some common convertible, importable standard one)...

[Ed. - Jeffrey goes on to describe how the matrix might be implemented, and
discusses some of the attendant problems.  It's a great idea, but one that
will probably never see the light of day.  If it's a spreadsheet, it's
necessarily dependent on some piece of software that not everybody has.  If
it's plain text, we've got a problem in organization and formatting; many
people want to see this information in printed form, which limits it to 80
or 132 columns in width -- our AAV*.* files are the best we've been able to
come up with to date; they fit on the screen, and can be printed 2-up on
landscape paper and/or double-sided for convenient mailing (when you mail 30
or 40 Kermit info packets per day, you have to think of these things).  They
show the most important information (file prefix, system, os, language,
version number, date, contributor) as compactly as possible in the space
that we have.  To reorganize these files all you need is a sorting program,
which every computer should have, and to search them a text editor suffices.
Still, the need for a master list of Kermit versions (available, on-the-way,
and possible) that includes more information than the AAV and AAW files is
real.  I expect we'll have to do something like this one day, and the form
it will take will be some kind of simply structured plain text.  It's just a
matter of finding the time to do it.]

------------------------------

End of Info-Kermit Digest
*************************
-------
12-Nov-86 17:37:49-EST,23422;000000000000
Mail-From: SY.CHRISTINE created at 12-Nov-86 17:36:47
Date: Wed 12 Nov 86 17:36:47-EST
From: Christine M Gianone <[e-mail]>
Subject: INfo-KErmit Digest V5 #16
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 12 Nov 1986       Volume 5 : Number 16

Today's Topics:
                  Announcing HP9845 Kermit in BASIC
                       Updates to Cyber Kermit
                     Oksatate Kermit Distribution
                         Getting Kermit Files
                  F11 and F12 on new IBM PC Keyboard
                            TSO Kermit Fix
                       Fix to os9 Kermit Server
                        Portable 68000 Kermit
                    More on CompuServe vs. Kermit
                        CompuServe and Kermit
                      VAX/VMS Kermit to PROCOMM
                   PROCOMM's Kermit and the VAX/VMS
                PROCOMM Kermit File Transfer Problems
                        Kermit-32 and PROCOMM
               How to Transfer Binary from UNIX to VMS?
                           VAX/VMS & Kermit
                        C-Kermit and Xenix 3.0
                    Re: FIDO - UNIX Kermit problem
                   Rainbow MSKERMIT initialization

----------------------------------------------------------------------

Date: 7-NOV-1986 12:53:27
From: [e-mail]
Subject: Announcing HP9845 Kermit in BASIC
Keywords: HP9845 Kermit

          Please find attached a listing of a minimalist kermit data
transfer program in interpreted Basic (!) for the HP9845. As it's in
interpreted Basic a listing of the source code seemed the best form to
distribute it in.  This implementation was developed by Chris Walker in the
Physics Dept here, and is principally designed for the transfer of
experimental data from a micro functioning as a data logger to a mainframe.
As such it lacks some features of a standard Kermit implementation, but it
works well and does what its supposed to do.

          Cheers,
                    Doug

Doug Moncur, Computing Service, University of York, Heslington, York YO1 5DD
          tel: [phone]x487 :: janet: [e-mail]

[Ed. - Thanks for the new Kermit version.  Many people have asked for this
in the past.  The files are in KER:HP9845.*.]

------------------------------

Date: 12-NOV-1986 10:14:07
From: [e-mail]
Subject:  Updates to Cyber Kermit
Keywords: Cyber Kermit

  A new version of Manchester University's Cyber Kermit (CYB) has just
arrived here: I've attached their release notes below.
                                   Alan

CYBKER.UPD

In addition to several minor alterations and improvements, there are
two major changes to Cyber Kermit  which have been requested by many
users of the program:

A Directory command has been added to list the names and lengths  of
local files.  When an optional filename parameter is specified, only
those files with matching names are listed.   This command is avail-
able both as a local command on the Cyber and as a remote command in
server mode.

The wildcard character '*' is allowed in file names after DIR, SEND,
remote DIR, and remote GET commands.

[Ed. - These files will placed in KER:CYB*.* as soon as they arrive over the
network.]

------------------------------

Date: Tue 11 Nov 86 09:50:49-EST
From: Frank da Cruz <[e-mail]>
Subject: Oksatate Kermit Distribution
Keywords: Okstate, UUCP

For those who may have missed previous announcements about this, here is a
brief description of the dialup Kermit file services available from Oklahoma
State University, Department of Computing and Information Sciences, Stillwater,
Oklahoma.  The OK state collection has just been brought up to date to reflect
the new 3-area organization, and to include the Kermit versions that have been
announced since last August.  OK State provides both UUCP and Kermit dialup
access.

The files from TAPE A are in /usr/spool/uucppublic/kermit-a/*
The files from TAPE B are in /usr/spool/uucppublic/kermit-b/*
The files from TAPE C are in /usr/spool/uucppublic/kermit-c/*

 -- UUCP --

You need to set up "okstate" as a site in your "L.sys" UUCP dialing file
using the information listed below.  You can then issue the following
commands on your system:

   uucp okstate!~uucp/kermit-a/aaaread.me /usr/spool/uucppublic

   (this example will retrieve a general information file about the entire
    Kermit Distribution.  DO THIS FIRST!)

   uucp okstate!~uucp/kermit-b/ck\* /usr/spool/uucppublic

   (this example will retrieve the current version of C-Kermit)

There are several files available that contain information about the entire
distribution.  We recommend that you retrieve these files first.  They are
"aaaread.me" which explains the file name conventions used, "aafiles.hlp"
which explains how to find the different kermit versions, and "aafiles.dir"
which is a complete listing (by name) of all files in the in each kermit
directory.  These files will enable you to choose the right files the first
time.

UUCP Login information:

Site Name    : okstate
Phone number : [phone] (300/1200 baud)
Login name   : uucpker
Password     : thefrog
Hours        : 24 hours per day, 7 days a week
Problem      : okstate!uucp-support                          (UUCP)
  reports    : [e-mail]                 (ARPA)

The following is a sample L.sys line (\r is a carriage return):

okstate Any ACU 1200 405-624-6953 "" \r ogin: uucpker word: thefrog

 -- KERMIT SERVER ACCESS --

Okstate also provides access to the Kermit distribution via a Kermit Server.
The number is the same as above for the uucpker login, so the line may be busy
quite a bit.  This server is a specialized server with controlled access.  At
present, the server is only allowed access to the Kermit directories on our
machine.

You need the following information in order to access the server:

KERMIT login   :   kermsrv
Password       :   piggy
Parity         :   even
Data path      :   7 bit
Available      :   24 hours/day, 7 days a week

When the login is completed, the server will start, and you should escape
back to your local KERMIT to issue further commands.  If the server remains
idle for a period of time around 10 minutes, it will be stopped.

The best place to start after logging on is "REMOTE HELP", followed closely by
the desired "REMOTE DIR" commands.  If you don't include an argument to REMOTE
DIR, you should be prepared for more than 600 lines of output.  It is usually
better to read the 'aaaread.me' file (using REMOTE TYPE perhaps) and then do
the DIR with some kind of wildcard (like "REMOTE DIR ck*").

Mark Vasoll
Computing and Information Sciences       Internet:  [e-mail]
Oklahoma State University                UUCP:  {cbosgd, ihnp4, isucs1,
Stillwater, Oklahoma                            pesnta, uokmax}!okstate!vasoll

[Ed. - Once again, many thanks for providing this service.  A much longer and
more detailed description of how to access the OK State Kermit files may be
found in the file AANOKS.HLP in the Kermit distribution.  There may be a
slight delay before this service is fully available because of a last-minute
foulup (Columbia's fault) with the tapes.]

------------------------------

Date: Wed 5 Nov 86 14:16:29-EST
From: Ken Rossman <[e-mail]>
Subject: Getting Kermit Files
Keywords: FTP, Arpanet

It seems to be a general problem with the ARPAnet backbone these days.
There's been lots of speculation on what the actual problem is and how to
solve it on lists like TCP-IP.  In any case, the only thing I can recommend
at this point in time is to try the file transfer during off hours and on
weekends.  I think I've had my best successes with FTP on Saturday nights/
Sunday mornings.  Submit a batch job to get the files, so you don't actually
have to be there at that time.  /Ken

------------------------------

Date: Wed, 29 Oct 86 08:59:32 PST
From: [e-mail]
Subject: F11 and F12 on new IBM PC Keyboard
Keywords: IBM PC Keyboard

Following is a note from our kermit guru, Greg Small ([e-mail])
regarding patches he made to our version of Kermit to allow use of F11 & F12.
The patches DO NOT specifically apply to any other versions of Kermit, but
may provide a starting point for patching other versions.

   Al Stangenberger
   Forestry & Resource Mgt.
   U. C. Berkeley

[Ed. - Thanks for the patch.  Many people have asked about this.  Greg's
changes have been forwarded to Joe Doupnik for inclusion in the next
release, coming Real Soon Now...]

------------------------------

Date: Mon, 3 Nov 86 18:10:24 pst
From: [e-mail] (Glenn Thobe)
Subject: TSO Kermit Fix
Keywords: TSO Kermit

TSO Kermit v.1.1 appeared to be broken as file transfers would regularly
fail at the same point in the transmission.  I was advised to enter the
following TSO command:

    profile char(bs)

which totally fixed the problem.  Apparently anything other than "bs" for this
profile parameter causes some character translation which interferes with the
incoming data.  I hope this information will be of use to others.

-Glenn Thobe

[Ed. - This message has been added to the TSO Kermit beware file -
KER:TSOKER.BWR ]

------------------------------

Date: Mon 3 Nov 86 23:42:40-PST
From: Bob Larson <[e-mail]>
Subject: Fix to os9 Kermit Server
Keywords: os9 Kermit

After seeing a rather vague bug report in the mod.os.os9 usenet newsgroup
about os9 kermit, I did find the bug in the os9srv.c module of os9 kermit:
It did not allocate space for the receive file name to go into.  I have not
tested this fix for the same reason I never tested the host mode originally:
my system is not set up to answer the phone.  The fix is rather
straitforward (two lines of code) and obviously needed, so I am including
the fixed os9srv.c at the end of this message.

The answer to the question of who should get the os9 kermit bug reports is
probably me, being the person who submited the last two versions to the
columbia kermit archives and the latest to the os9 users group.  Reports
sent to [e-mail] would probably get to me also.

Bob Larson
Arpa: [e-mail]  or  [e-mail]
Uucp: sdcrdcf!usc-oberon!blarson

[Ed. - Thanks Bob!  The new file KER:OS9SRV.C has replaced the old one.  The
old file has been moved to KO:OS9SRV.C.]

------------------------------

From: [e-mail]
Date: 11 nov 86  14:38 GMT +0100
Subject: Portable 68000 Kermit
Keywords: 68000 Kermit

[Ed. - This is from Roberto Bagnara, Physics Department, Bologna University
(Italy), concerning a Kermit program he's developing for the Motorola 68000
family of processors, designed for portability among 68000 operating systems
and assemblers, particularly those of the sort that are sold as turnkey
systems for lab work, with little or nothing in the way of utility software
or operating system support for many of the functions we take for granted.
Anyone who has an interest in such systems, please respond to Roberto's
questions directly, or through Info-Kermit.  Thanks!]

   I'm writing to you, in order to clarify some points about the Kermit
program that I'm developing. Here they are:

a) I'm working hard, because I'd like to carry out my job by
   the end of this month.  The first version of Kermit68K will
   be necessarily a preliminary one, due to the fact that, being
   employed at a department of physics, I haven't the advantage
   of a useful exchange of ideas, suggestions, etc.
   I need strong user/implementor feedback, in order to make the
   program effectively portable to different machines and
   operating systems, and to refine it, so that it works at its
   best.  Having said all that, do you think that it's better to
   include it in the official distribution as a preliminary or
   you know any potential user/implementor, whom I can address
   to, in order to get this feedback?

[Ed. - Any "alpha test" volunteers out there?  If not, then let's just
install the preliminary version for distribution.]

b) Ensuring portability while maintaining, as much as possible,
   a unique source code would be a nice result. Unfortunately
   the assemblers differ, in general, in the syntax of the
   directives, besides some of them produce machine code
   directly, thus not allowing linking with other modules, that
   is separate assembly is impossible.
   Is there a public domain or highly diffused pre-processor
   for files inclusion and conditional text insertion ?

That's all for now.

                       Thank you very much.
                              Roberto

------------------------------

Date: Mon, 3 Nov 86 23:24:09 est
From: [e-mail] (John McNamee)
Subject: More on CompuServe vs. Kermit
Keywords: CompuServe

Most CompuServe users access the service via CompuServe's own network, which
has dialups all over the place.  Very few come in via Telenet, Tymnet, etc.
The CompuServe network nodes are quite smart and have large input buffers,
and CompuServe may even move some or all of file transfer protocol handling
off the mainframes and into the nodes.

------------------------------

Date: Mon 3 Nov 86 22:40:40-EST
From: Russ Forster <[e-mail]>
Subject: CompuServe and Kermit
Keywords: CompuServe

I have used compu-serv rather extensivly in the last little while and have
experenced a number of problems in downloading files.  This is partly due to
going through DATAPAC here in the 'Great White North'.  CIS does not support
KERMIT at all and this can (and does) cause problems for us AMIGA owners.
XMODEM pads out to 256 characters per line, so if the line is less, it gets
filled with nulls.  Because the AMIGA is multi- tasking, It must know the
length of the file to find a place for it in memory.  We AMIGAns have
developed a number of Chomping programs to eat up the null's that XMODEM
insists on putting in.

The bottom line is yes Yes YES!!!! I would love to see KERMIT infiltrate
these networks like CIS and PEOPLE LINK.  Us AMIGIANS need it.

                    /Russ

ps.  This was in response to the latest KERMIT digest.

Disclaimer ..
The above commnets are my own not my employeers.

------------------------------

Date: Thu, 6 Nov 86 18:08:14 pst
From: [e-mail] (Glenn Thobe)
Subject: VAX/VMS Kermit to PROCOMM
Keywords: VAX/VMS Kermit, PROCOMM

In reference to Lawrence Clark's communication (IKD v.5, no.15), I have had
difficulty transferring files from VAX/VMS Kermit-32 v.3.2.077 to Procomm
v.2.4 on an IBM-PC (that's the other direction from what L.C.  was trying to
do).  The transfer of a text file was successful but very slow.  The VAX
would send out a data packet immediately upon receipt of an ack and wait,
time out, send a repeat of the data packet, wait some more, finally receive
the ack, etc.  This is just one experience, not a controlled experiment, so
I wouldn't hasten to make any hard and fast judgements from it.

-Glenn Thobe
[e-mail] (arpa)

[Ed. - See the following messages...]

------------------------------

Date: Fri, 7 Nov 86 16:42:15 est
From: Robert Montante <seismo!iuvax![e-mail]>
Subject: PROCOMM's Kermit and the VAX/VMS
Keywords: PROCOMM, VAX/VMS

In response to Lawrence Clarke's question about ProComm's Kermit and VAX/VMS
Kermit:  I am using ProComm v2.42 for Kermit transfers quite successfully, to
and from a VAX/VMS V4.2 with Kermit-32 (and also with ckermit running under
UNIX on another VAX).  I have noticed that both ProComm and the host Kermits
make some default-setting assumptions that are incompatible (and occasionally
inexplicable).  Something like the "block check type" may need to be adjusted
locally or on the host (or both); this was necessary to get me going on UNIX.
    ...Bob Montante...

 Datclaimer: "[Usual disclaimer: I have no opinion, therefore I don't exist .]"
Disclaimer: I opine, therefore I am.  My employer, however, is a figment.

RAMontante
Computer Science                "Have you hugged ME today?"
Indiana University

[Ed. - Block check type is something that two Kermit programs are supposed
to negotiate between themselves.  It's possible that ProComm isn't doing
this right.]

------------------------------

Date: Wed, 5 Nov 86 14:13:09 est
From: phri!dvm![e-mail] (Frank Wortner)
Subject: PROCOMM Kermit File Transfer Problems
Keywords: PROCOMM

I noticed the last Kermit Digest had a note from Lawrence Clarke about the
difficulty getting PROCOMM and Kermit to speak to eachother.  I've had this
problem also.  File transfers were OK when MSKERMIT 2.29 talked to C-Kermit
4C(58) on the VAX ( an 11/780 running DEC Ultrix ), but when PROCOMM 2.42
took over, the Kermit transfers simply stopped working.

All was not lost, however, since I discovered that if I changed some of
PROCOMM's line settings, everything worked again.  I used the Line-Settings
menu (Alt-P) to set the parity to space, and Kermit then happily resumed
shipping files.  I don't know how or why this worked, but if anyone out
there wants to use PROCOMM to talk to Kermit, experimenting with parity
bit settings is worth a shot.

                            Frank Wortner
                        UUCP: [e-mail]
                      (... allegra!phri!orville!frank )

------------------------------

Date: Tue, 4 Nov 86 08:58:17 EST
From: rmcqueen (Robert C McQueen) @ sitvxb
Subject: Kermit-32 and PROCOMM
Keywords: Kermit-32, PROCOMM

In response to Lawrence Clarke in the Info-Kermit Digest V5 #15:

Try using at least version 3.2 of Kermit-32 to see if the problem still
exists that and PROCOMM.  We have fixed lots of random problems along the
way and could have resolved this problem.

Bob

------------------------------

Date: Tue, 4 Nov 86 12:16:52 pst
From: [e-mail] (Rex Black)
Subject: How to Transfer Binary from UNIX to VMS?
Keywords: C-Kermit, VAX/VMS Kermit, Binary Files

My advice is to archive the file (since that changes format) and try that.
If that fails, you know that it is NOT the data format which is tripping up
the machine, but rather some form of hardware/communications problem between
DEC and Pyramid.

It's always a good idea to isolate your bug.

    Rex

------------------------------

Date: Tue, 11 Nov 86 23:03:16 est
From: Bob Sutterfield <[e-mail]>
Subject: VAX/VMS & Kermit
Keywords: VAX/VMS Kermit

In article <[e-mail]> [e-mail] (Brad Banko) writes:
>Kermit dogs our VMS system down... whenever one of us uses kermit
>to communicate over the modem, it really dogs our 11/750 down... it is
>particularly bad when typing long messages or kermitting files... has anybody
>else had this type of problem, and is there an easy fix?
>    I don't know if the problem is with VMS, or Kermit...  Thanks.

    Yes, I've noted that problem on a 750 running VMS.  Even at
1200 bps on a DMF-32 modem port, filling a screen (like by cat(1)ing a
text file on the remote system) can grab over 90% of an otherwise-busy
CPU (thus saith MONITOR).  Curiously enough, unlike your report, I
only saw the problem while CONNECTed to a remote system, never while
SENDing or GETting a file to/from a remote server.

    The clue to the cause is to look (still via MONITOR) at all
the buffered I/O that's going on in your process.  Think about all
those characters passing through the port drivers, the class drivers,
etc. to get to your screen, generating high-priority interrupts as
they go.  It's pretty gruesome.

    I tried various permutations of the SYSGEN parameters
concerning silo and DMA and typeahead buffer sizes, particularly the
one that controls when the minimum-size thing that triggers a switch
to "DMA mode" from character-by-character interrupt mode - I think
it's TTY_DMASIZE (I no longer have any connection with VMS systems, so
my memory is foggy of its name).  Nothing seemed to help me.

    It seems to me that the only way to improve this problem would
be to make Kermit much more intelligent about VMS guts, in order to
bypass some of the layers that characters have to go through.  This,
of course, would make it much less portable, even to new versions of
VMS, as the terminal driver is wont to change occasionally.  Like,
apparently, with new major releases of the operating system.

------------------------------

Date: Wed 5 Nov 86 16:58:31-EST
From: Christine M Gianone <[e-mail]>
Subject: C-Kermit and Xenix 3.0
Keywords: C-Kermit, Xenix

Has anyone has any experience running C-Kermit under the Xenix operating
system, version 3.0A, on the AT?  If you got it to work, what "make" options
did you use, or what modifications did you make to the source?  We're
getting a lot of questions about this.

------------------------------

Date: Wed, 5 Nov 86 13:59:29 est
From: munnari!latcs1.oz![e-mail] (Philip Lee)
Subject: Re: FIDO - UNIX Kermit problem
Keywords: FIDO, C-Kermit, UNIX Kermit

Found the problem, FIDO kermit allways sends out file with 8th bit quoting
(with '&' prefix), even when you come in with 8 bits and no parity!  I
should've guessed it when the received binary file is bigger than the
original. I've been told that it would be fixed in the next version of FIDO,
the one I've been connected to runs on ver 11W.

Philip P.H. Lee,
La Trobe University,
Dept. of Computer Science,    PHONE:    [phone] ext 2902
Bundoora,            A/CSnet:[e-mail]
Victoria 3083,            ARPA:    [e-mail]
AUSTRALIA.    UUCP:{seismo,hplabs,mcvax,ukc,nttlab}!munnari!latcs1.oz!philip

[Ed. - There have been many complaints from people downloading ARC files
from FIDO BBS's with Kermit that the files cannot be successfully unARC'd.
This could be the problem!  A cursory examination of a packet log shows
that 8-bit quoting was not negotiated, but was used by FIDO anyway, so
that the resulting downloaded file was filled with extraneous & characters.
We'll try to check this in more detail.]

------------------------------

Date: Fri, 7 Nov 86 08:07 ???
From: RLH <[e-mail]>
Subject: Rainbow MSKERMIT initialization
Keywords: MS-DOS Kermit, DEC Rainbow

Does anyone have a good .INI initialization file for the MS-DOS version of
Kermit on a DEC Rainbow?

What I want to do is to get the terminal emulation to look as much like a
VT200 series terminal as I can - particularly as far as having the function
keys transmit the right sequences so that I use the key definition
facilities of VAX/VMS and the TPU editor.

If you have a .INI that does a good job of this, would you send me a copy?

    thanks,

    Bob Haar

[Ed. - Try KER:MSIRB2.INI on CU20B (MSIRB2 INI from KERMSRV). You're welcome.]

------------------------------

End of Info-Kermit Digest
*************************
-------
21-Nov-86 16:34:02-EST,15396;000000000000
Mail-From: SY.CHRISTINE created at 21-Nov-86 16:32:41
Date: Fri 21 Nov 86 16:32:40-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #17
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 21 Nov 1986       Volume 5 : Number 17

Today's Topics:
               WISCVM Arpa/BITNET Mail Relay Congestion
                            HP9845 Kermit
             Okstate Kermit Service Available Once Again
                      Re: C-Kermit and Xenix 3.0
                           FIDO and Kermit
                         Error in CP4KER.DOC
                             Amiga kermit
                           C-Kermit 4D(060)
                 Help needed on Kermit-32 and X25/X29
                        Kermit and CompuServe

----------------------------------------------------------------------

Date: 14 November 86 18:34 EST
From: Larry Landweber  <LHL @ WISCVM.WISC.EDU>
Subject: WISCVM Arpa/BITNET Mail Relay Congestion
Keywords: BITNET, Arpanet

Because of Arpanet congestion problems, our WISCVM mail relay is unable to
keep up with the quantity of mail sent to it for forwarding. While the
problem is particularly acute in the Bitnet to Arpanet direction, the level
of traffic in both directions is a problem.  A large part of this traffic
results from mailing lists.  Furthermore, while we are usually only sent a
single copy of a list mailing, the recipient list is often very long.  A
single message may require the sending of over a hundred copies. This is a
problem for two reasons... Arpanet congesion makes it difficult at times to
establish and keep TCP connections and such connections are slow; second,
the implementation of the gateway at present makes multiple copies for
forwarding (a poor design choice that is being worked on).  At present, the
first problem is far [more] significant.

To alleviate the problems cited above and enable us to provide a reasonable
level of service, we are asking Arpanet list maintainers to provide list
exploders on Bitnet and vice versa.  Your cooperation will be very much
appreciated. Note that in a about a month we will begin limiting the number
of copies we will relay by putting a limit on the number of recipients in
RCPT TO lines in SMTP and BSMTP.  This limit is likely to be 10.

Gligor Tashkovich <[e-mail]> has agreed to help
coordinate the process of putting maintainers on one net in touch with
relevant people on the other list.

Thanks in advance for your cooperation in this matter.

Larry Landweber

cc: NIC @ SRI-NIC.ARPA   CIC @ SH.CS.NET   INFO @ BITNIC
    PEB @ CERNVM

[Ed. - This is a serious problem.  There is not a lot of duplication in the
Info-Kermit list; only a few hosts appear more than twice (they are
VTVM1 (6 times), CALSTATE (5), BROWNVM (3), DACTH51 (3), DBNRHRZ1 (3),
UMKCVAX1 (3), and UREGINA1 (3)).  If the subscribers at those hosts could
arrange to combine themselves into a local redistribution list, that would
be appreciated.  Meanwhile, we'll try to work out some arrangement so that
mail to BITNET subsribers won't be arbitrarily discarded.  But success can't
be promised.]

------------------------------

Date: Fri 21 Nov 86 12:00:35-EST
From: Christine M Gianone <[e-mail]>
Subject: HP9845 Kermit
Keywords: HP9845 Kermit

In Info-Kermit Digest V5 #16 HP9845 Kermit was announced to be in the file
KER:HP9845.*.  Accidentally, the files were placed in KER:HP9KER.* This has
been corrected.  Sorry for any inconvenience.

------------------------------

Date: Tue, 18 Nov 86 16:05:28 -0600
From: Mark Vasoll <[e-mail]>
Subject: Okstate Kermit Service Available Once Again
Keywords: Okstate

I have reenabled the dial-in modem and about 45 seconds after doing that
someone had logged into uucpker and started grabbing stuff.  Looks like
there is still plenty of demand!

Cheers,
Mark

------------------------------

Date: 13 November 1986 0810-PST (Thursday)
From: [e-mail] (Larry Bierma)
Subject: Re: C-Kermit and Xenix 3.0
Keywords: C-Kermit, Xenix

I got kermit running on an AT running IBM's XENIX 1.0 (which is supposedly
the same as Microsoft XENIX 3.0) with no problems.  Unfortunatly I don't
remember what "make" option I used and I no longer have the machine.
If no one else gives you better information let me know and I'll get
access to the machine and check what I did.

  Larry        ARPA: [e-mail]
        UUCP: {decvax,ucbvax,ihnp4}!sdcsvax!sdics!nprdc!bierma
        PSTN: [phone]

[Ed. - Well, there is some feedback.  Does anyone have more information?]

------------------------------

Date: Fri, 14 Nov 86 13:52:40 CST
From: [e-mail] (John Plocher)
Subject: FIDO and Kermit
Keywords: FIDO, Kermit

The Fido kermit problem is deeper than just 8 bit quoting...
  I downloaded an ARC file and ran a simple filter on it to
  expand 8 bit quoting...  BOMB!

  The file became much shorter than the original and would not unarc.
Is this because the 8bit decoding can't be done outside of the kermit
state machine?  I'm confused as to how to fix this problem:

    setting my kermit to use a 7 bit line with 8 bit quoting
    does NOT seem to get rid of the problem!

"Never trust an idea you get sitting down" - Nietzche
            {harvard,seismo}!uwvax!uwmacc!uwhsms!plocher        (work)
John Plocher    {harvard,seismo}!uwvax!puff!plocher                 (school)
            decvax!encore!vaxine!spark!121!0!John_Plocher       (FidoNet)

------------------------------

Date: Mon, 17 Nov 86 11:35 N
From: <[e-mail]>
Subject: Error in CP4KER.DOC
Keywords: CP/M Kermit

Dear Kermit-eers,

There are two tiny little errors in the file CP4KER.DOC.

A small 8080-assembler program is listed which should downline-load the
Kermit-hex-files from a DEC20-system to a CP/M-microcomputer.

line 015A shows:        jm 170          This should be: jc 170
line 0167 shows:        jm 170          This should be: jc 170

Change the above lines and it really works!

A happy Kermit-eer,

                .KeesdeGroot    (DEGROOT@HWALHW50)

[Ed. - Thanks for the bug report and the fix.  This message has been added
to KER:CP4KER.BWR.  This whole program was replaced in the second revision of
the sixth edition of the Kermit User Guide but this file has not yet been
updated.]

------------------------------

Date: Mon, 17 Nov 86 21:55 EST
From: <[e-mail]>
Subject: Amiga kermit
Keywords: Amiga Kermit
Cross-Ref: Commodore Amiga (see also Amiga Kermit)

   This may or may not be of interest to anyone there. I obtained what I
believe is the latest version of Amiga Kermit from the Columbia Kermit
server a couple of months back. (I used the earlier one before that.) This
newer version is rather nice, except that it doesn't seem to be able to
generate even parity. The old version worked fine, this newer one does not
seem to generate even parity (at least, not the even parity that the local
IBM 3081 likes) under release 1.1 of AmigaDos. I've tried it with the 1.2
beta serial.device, but no luck. I haven't made any attempt at fixing it; I
am NOT a C programmer (yet?).
                                                        Rick Pim

------------------------------

Date: Tue, 18 Nov 86 02:01 EST
From: Kuryan Thomas <[e-mail]>
Subject: C-Kermit 4D(060)
Keywords: C-Kermit

[Ed. - The latest version of C-Kermit is 4D(061)]

This is Kuryan Thomas at Virginia Tech Physics department.  Some months ago
I reported a problem with C-Kermit running on my AT&T PC6300PLUS under
UNIX System V.  I couldn't get the dial command to work -- I would always
get an error like "Can't hang up the phone" or "Communications Disconnect."

After some time as a UNIX administrator and programmer, I've managed to
debug the problem.  In function tthang() in ckutio.c, the phone is hung up
by using ioctl() to set the baud rate on the port to 0.  This, I believe,
is standard UNIX procedure.  On my particular system, though, this operation
always fails with ioctl() signalling an error (-1) and setting errno to
ENXIO (No such device or address).  This is definitely a bug, because the
phone IS correctly hung up (DTR line is dropped).  The fix is to simply
ignore error returns from the hang-up ioctl() in tthang() (that's the first
ioctl() call in tthang()).

[Ed. - Since this error might be significant on other systems, maybe the
best thing would be to report any error returned by this ioctl(), but then
proceed anyway.]

I uncovered a few other problems, all of which I found (rather kludgy) fixes
for.  First, the dial command cannot work unless carrier detect is asserted
on the terminal line.  My modem, a Prometheus 1200, refuses to accept the
commands.  (Or my tty port refuses to behave correctly, I'm not sure which.)
The fix is to strap CD high with the DIP switches on the bottom panel.

[Ed. - This sounds like another problem with your system.  Obviously, CD
will not be asserted until the phone call is completed and carrier is
detected.  The system should not require CD to be on while dialing.  Strapping
CD high, of course, prevents Kermit or any other program from telling when
carrier really drops.]

Next, my computer, like the 3BX series, expects its lock files in the
directory /usr/spool/locks, rather than /usr/spool/uucp.  The problem is
that the former, unlike the latter, is writable only by the uid uucp.
It might appear that the solution is to make ckermit owned by uucp and
set the set-uid bit, but ckermit uses the access() system call to check
write access to the lock directory.  access() uses REAL uid's to check
access, not effective uid's.  Therefore, set-uid is ineffective.  The only
fix I could think of was to remove the lines in look4lk() that report an
error if access() says there's no write permission in the lock directory.
If the set-uid trick is used, all is well and the lock file is created.
If you forget to set the set-uid bit or something else goes wrong, the
attempt to creat() the lock file fails with an error like "Couldn't gain
exclusive access of lock file" or words to that effect.

[Ed. - It seems like every variant of Unix on every different kind of
system puts the "lock files" in different places.  And what's more, each
installation sets the permissions differently.  Perhaps the next release
of UNIX Kermit will make the lock file location a makefile option, to
emphasize that it has given up all hope of knowing where to find it.]

Finally, the problem of having Kermit hang up the phone when you return to
the shell (thus terminating the conversation) can be solved by strapping
DTR high with the modem's DIP switches.  Ckermit can no longer hang up the
phone correctly, but if you often return to your local shell in the middle
of a remote session, the convenience is worth it.  And, of course, the
remote end is usually able to hang up the phone correctly when you are done
with it.

[Ed. - Or you can push from Kermit to an inferior shell, leaving the connection
active and all Kermit settings intact -- use the "!"  command at prompt level.
A "push" escape will probably also be added to the 'connect' command in the
next release.  Setting the modem's "ignore DTR" switch prevents the modem from
noticing when your system crashes, and terminating the connection, resulting in
potentially big phone bills if this happens during unattended Kermit or UUCP
operation.]

Hope this will be of help to someone.

------------------------------

Date: Wed, 19 Nov 86 15:32 GMT
From: Jan Peter Stuart <[e-mail]-M> 19-NOV-1986 15:37
Subject: Help needed on Kermit-32 and X25/X29
Keywords: Kermit-32

I was dissappointed to find after my note in newsletter 92, that possibly
no one else uses Kermit-32 on a vax at the end of an X25 line.

So far I have been singularly unsuccessful in getting anything to
function on the outside world!

The problem is now a bit clearer at least. Kermit-32 was designed
to use a vax terminal line. I have no terminal lines to the outside
world, only an x25 connexion that terminates at a DEUNNA board in the
vax. Thus no hardware PAD!

I can certainly establish connections thru the vax X25 without kermit
but does anyone know how to tell kermit-32 to set up an x25/x29 type
of call ????

If I find no other uk users in this position, is there any way I can
request help from the source ? (USA) ?

Yours hopefully,

Jan Stuart.

also direct at uk.ac.rl.gm

------------------------------

Date: Thu, 20 Nov 86 09:18:39 PST
From: Steve Walton <ametek![e-mail]>
Subject: Kermit and CompuServe
Keywords: CompuServe

Adding fuel to the fire...

    I have had the experience of using Kermit over Telenet.  It was not
pleasant.  The remote system was the WELL, a 4.2BSD Vax 750 in Berkeley, and
the local system was my Amiga.  Version 4D(061) of C-Kermit was used at the
WELL end, and a PD terminal emulator at the Amiga end.  Efficiency was 25%.
(Has anyone ever seen C Kermit do better than 65% efficiency?)  I finally
gave up on Kermit, and am now using the 1024-byte-packet version of XMODEM
for WELL communication.

    Compuserve "B" protocol uses 511-byte packets, which seem to work
fine over Tymnet, Telenet, and the CompuServe net.  PeopleLink offers XMODEM
and a new one called "Windowed XMODEM" (!) to get around the delay problems.
When I first arrived on PeopleLink, I suggested windowed Kermit to them as a
new protocol.  I haven't asked why they didn't adopt it, but suspect it was
because windowed Kermit is basically nonexistent (except possibly for some
alpha test versions and the IBM PC-only one from the Source).  So is
windowed XMODEM, but XMODEM is much closer to universal than Kermit, and is
easily modified to add the window support.  After all, we're talking a
strict 8-bit asynch-to-asynch one file at a time protocol.

    I love the little green guy, and use it whenever I have a direct
connect line between two machines.  But it's a big lose on the
packet-switched nets, and when you're paying by the minute, that's
important.

Stephen Walton            ARPA:    ametek![e-mail]
Ametek Computer Research Div.    BITNET:    walton@caltech
610 N. Santa Anita Ave.        UUCP:    ...!ucbvax!sun!megatest!ametek!walton
Arcadia, CA 91006 USA
818-445-6811

[Ed. - Windowed Xmodem is not exactly what you might think -- Since
Xmodem does not have replies (ACKs and NAKs) that are in packet form
so that they can indicate WHICH packet they are ACKing or NAKing,
true sliding windows cannot be supported by any of the MODEM family.
What Windowed Xmodem does is cancel the entire file transfer if any
error is detected.  So it's fast when it works, but "infinitely slow"
when it doesn't.  C-Kermit will eventually have support for both long
packets and sliding windows.]

------------------------------

End of Info-Kermit Digest
*************************
-------
 8-Dec-86 16:40:34-EST,19107;000000000000
Mail-From: SY.CHRISTINE created at  8-Dec-86 16:30:14
Date: Mon 8 Dec 86 16:30:14-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #18
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Mon, 8 Dec 1986       Volume 5 : Number 18

Today's Topics:

                      PERKIN-ELMER 7000 Series Kermit
                         NIH TSO Kermit Version 1.0
                            BITNET Distribution
                          More on FIDO and Kermit
                       SCO Sys V/286 Xenix Kermit 4C
               Use of Unix Kermit on Packet Switched Network
                       VAX/VMS Kermit-32 and X25/X29
                 Micro_Vax II problem with modem interface
                            HP9845 BASIC Kermit
                Kermit for RSX-11/M v3.2 and/or Hyperion PC?
                          Problem with P-E Kermit?
                   PR1ME Kermit with connect capability?

----------------------------------------------------------------------

Date: Mon 8 Dec 86 11:32:34-EST
From: Chris Lent <[e-mail]>
Subject: PERKIN-ELMER 7000 Series Kermit
Keywords: Perkin-Elmer, Concurrent

I've gotten a Kermit for the Perkin-Elmer 7000 Series computers which are
IDRIS based.  It's loosely based on the old C-Kermit from the old Protocol
manual. It has Binary file (8-bit and &-quoting), Repeat quoting and server
mode (GET,SEND,and FINISH).  It has no connect mode, as the 7000 series
comes with the cu(1) command which does the same thing.

I didn't create this version (Dan Eisner of Perkin-Elmer did), but I did
create a bootstrap document. I translated the bootstrap programs so that I'm
using an existing format for encoding the binary files.  For its size it's
one of the most solid Kermit's I've seen so far.

Chris Lent
"phri!cooper!chris"@NYU.ARPA
[e-mail]

------------------------------

Date: Fri, 05 Dec 86  23:33:18 EST
From: "Roger Fajman" <RAF@NIHCU>
Subject: New NIH TSO Kermit Version 1.0
Keywords: TSO Kermit, IBM Mainframe

I would like to announce the availability of the NIH TSO Kermit Version 1.0.
The following summarizes its capabilities:

NIH TSO Kermit Capabilities At a Glance:

       Local operation:  No
       Remote operation:  Yes
       Transfers text files:  Yes
       Transfers binary files:  Yes
       Wildcard send:  Yes
       XX/XY interruption:  Yes
       Filename collision avoidance:  No
       Timeouts:  Yes
       8th-bit prefixing:  Yes
       Repeat character compression:  Yes
       Alternate block check types:  Yes
       Communication settings:  No
       Transmit BREAK:  No
       IBM mainframe communication:  Yes
       Transaction logging:  No
       Session logging:  No
       Debug logging:  Yes
       Raw transmit:  No
       Login scripts: No
       Act as server:  Yes
       Talk to server: No
       Advanced commands for servers:  No
       Local file management:  Yes
       Command/init files:  Yes
       Handle file attributes:  No

I am sending a tape to Frank da Cruz at Columbia so that NIH TSO Kermit can
be included on the regular Columbia distribution tapes.  When the files are
available on KERMSRV, ask for TSNKER.TXT to see the installation
instructions.  There are 8 required files, plus 13 more if you want the
source.

NIH TSO Kermit may also be obtained directly from NIH by sending a letter of
request and a tape to the following address:

   Joseph D. Naughton
   Chief, Computer Center
   National Institutes of Health
   Building 12, Room 2244
   Bethesda, MD 20892

There is no charge.

The NIH version of TSO Kermit is an extensive modification and rewrite of
the University of Chicago TSO Kermit, which in turn was based on an early
CMS Kermit developed at Columbia University.  The external design was done
by Roger Fajman and Dale Wright.  The internal design and programming was
done by Dale Wright.

------------------------------

Date: Wed, 03 Dec 86 13:02:24 EST
From: Harold C Pritchett <HAROLD@uga>
Subject: BITNET Distribution
Keywords: BITNET

Please add:

      [e-mail]

to your distribution list.  This is a BITNET List server which will allow
BITNET users to subscribe and receive copys of your list without having to
transverse the WISCVM gateway.  After this is done, you might want to
announce the availablility of this list as an alternative method for your
BITNET subscribers to receive this list.

For a BITNET user to subscribe to this list, they can issue the command

     TELL LISTSERV AT UGA SUB I-KERMIT Users Name  (from VM/370)

     SEND LISTSERV@UGA SUB I-KERMIT Users Name     (from VAX/VMS)

All other users can send RFC-822 mail to LISTSERV at UGA where the first
of the message text (the line after the blank delimiter line) is

     SUB I-KERMIT Users Name

[Ed. - Thanks.  BITNET subscribers might want to try this new service and if
it works okay, they may want to switch from Info-Kermit at CU20B to
I-KERMIT, in order to relieve congestion at the WISCVM gateway.]

------------------------------

Date: 1986 Nov 21   22:14 EST
From: (John F. Chandler) <PEPMNT@CFAAMP>
Subject: More on FIDO and Kermit
Keywords: FIDO

It should be obvious that if the two Kermits mis-negotiate the state of
8-bit quoting there can be irretrievable garblings.  In particular, assuming
the sender thinks "&" is the 8-bit quote, all occurences of "&" get sent as
"#&", which is garbage if the receiver thinks there is no 8-bit quoting.
The "#&" is probably converted to "f", but it could depend on the
implementation!  If it, in fact, comes out as "&", then a post-reception
filter would try to merge it with the following character anyway.  If there
is garbling even when the two Kermits claim to agree on the quoting state,
it might be a good idea to send a short file with a few mixed 7- and 8-bit
byte values.  Then you'll have a clue as to what's happening.

[Ed. - Actually, translation of "#&" to "f" is improper, because "&" is not
in the range of encoded control characters.  The "#" operator should
"controllify" the following character only if it is in the range 63-95
(decimal), otherwise it means "take the following character literally".  But
you're right, there are some Kermit implementations that do not follow this
rule.]

------------------------------

Date: Sat 29 Nov 86 21:08:53-MST
From: Mike Niswonger <[e-mail]>
Subject: SCO Sys V/286 Xenix Kermit 4C
Keywords: Xenix

Help!!,
    There seems to have been a lot of hassles stirred up about what is
necessary to run which version of C-Kermit on which version of Xenix.  I
would like to compile a full list of users who have Kermit up and running on
a Xenix system.  Please include the following information:

  User name and net address
  Hardware: manufacturer, model, CPU (8086, 80286, etc), configuration
  SPECIFIC Xenix version including:
  . Source (IBM, Microsoft, SCO, Tandy)
  . Sys III, Sys V, V7, "Sys V with Berkeley features", etc.
  . Xenix release version (very important)
  . Development system (compiler) version
  Edit level of C-Kermit used (should be 4D(061))
  Specific fixes, patches, workarounds, actual flags used during compilation
  (please don't just say "see makefile")

I realize that this may require some digging, but please help out.  I have
been working (on and off) trying to bring up Kermit on a friend's SCO Xenix
286 / Sys V AT clone for almost a year, with little success.  From some of
the notes that I have seen, I am not alone.

A compilation of the results will be submitted to CU20B when complete.

            -- Mike Niswonger,
               [e-mail]

[Ed. - As we've noted in previous postings, "Xenix" is almost a meaningless
label, except that it means a operating systems that resembles one or more
versions of Unix.  Thus, it has proven next to impossible for us to tell
people how to bring up C-Kermit under "Xenix".  If we had a list of all the
different incarnations of Xenix along with the parameters that Mike has
listed, it would help a lot.]

------------------------------

Date: Mon, 24 Nov 86 12:49:10 WET
From: Bruce Wilford { 01 387 7050 x 3691 } <[e-mail]>
Subject: Use of Unix Kermit on Packet Switched Network
Keywords: Unix Kermit, C-Kermit, X.25

People connect to our machine from all over the UK via an X25 network.  Some
have to pay for this and therefore need to use message (line) mode.  If they
are in line mode the characters will not be forwarded until the <CR> is
typed at the end.  This would ruin the effect of command completion, with
ESC and things like ? being picked up immediately.

[Ed. - First, note that you do not HAVE to use command completion, ESC, or ?
when talking to C-Kermit.  You can use it as a traditional Unix command,
with command-line options, as documented in the manual (or type "kermit -h"
for a brief summary).  During interactive use, if you configure your PAD to
use only CR as the data forwarding character (X.3 parameter 3, value 3),
then you will simply not have the special features available to you at your
terminal; you can still type the commands.  You can use X.3 PAD commands to
change your data forwarding characters; for instance "SET? 3:14" will allow
forwarding on CR, ESC, DEL and a few other control characters, but not ^U or
"?", which are also used by the interactive command parser.  "SET? 3:72" will
cause forwarding on any control character.  There's no X.3 selector for "?".
You can also configure the PAD to let you do local editing when in line
mode (X.3 parameters 15-18).  During file transfer, Unix Kermit puts the
communication line into "rawmode" which, in some Unix implementations,
causes the Unix system to tell the network to do character-at-a-time i/o,
which means one character per packet, which is unnecessarily expensive when
you're paying by the packet.  Future releases of Unix Kermit may provide
some kind of workaround for this.]

------------------------------

Date: Sun, 23 Nov 86 16:47:10 EST
From: [e-mail]
Subject: VAX/VMS Kermit-32 and X25/X29
Keywords: VMS Kermit, X.25

In Info-Kermit dgest V5 #14, Jan Peter Stuart <[e-mail]-M>
asked about using Kermit-32 to connect out through an X.25 PSI interface to
the outside world.

Unfortunately, I am in the same situation.  However, since our users can
usually loop around in our network (Merit), and come back in to use it as a
remote kermit, our need is not overly pressing.  There are other VAX/VMS
systems attached through X.25 interfaces to Merit, though, and any real,
software solution would bre greatly appreciated.

    Richard S. Conto
    University of Michigan Computing Center
    1075 Beal Ave.
    Ann Arbor, Mi. 48109, USA

    ARPA/Internet:    [e-mail]

[Ed. - Bob McQueen, the author of VMS Kermit, says that he'd be willing to
look into adding X.25/29 PSI support, but (1) he doesn't have an X.25 PSI
system at his site, and (2) he doesn't have any documentation on the
interface.  If someone can provide the details of the VAX/VMS X.25 interface
(does it look like a normal terminal? Do you send special X.28 control
sequences to the PAD? etc) and would be willing to test the results, please
contact Bob as "rmcqueen%sitvxb.CCNET"@CU20B, or through Info-Kermit.
Results cannot be promised.]

------------------------------

Date: 25 Nov 1986 12:07-EST
From: DEC PC BBoard <[e-mail]>
Subject: Micro_Vax II problem with modem interface
Keywords: VMS Kermit

            We have recently got a Microvax II and are facing some problems
in connecting the MUX ports to modem. I am here a faculty member in
Electrical Engineering at North Dakota State University Fargo, North Dakota,
USA.
            The problem is as follows:

1. When the prot, e.g. TXA0 is defined as MODEM port, using SET TERM
command, after a user logs in through that port, he is logged out in about
30 seconds with a message, SYS - E - HANGUP. If the port is not defined as a
modem, by the command SET TERM/NOMODEM then this hangup does not occur, but
if the modem is switched off without the user having logged off, the user is
not logged out and anybody who comes in through that port is in effect
working as the 'old' user. This is a big security risk Did you come across
any such problem. We are here using a PACKSnetwork which uses Gandolf
modems. The operating system is VMS 4.4 and the port controllers are DHV-11.

                 I shall be very thankful for your suggestions.

                                  K.Sankara Rao

[Ed. - Reply from Bob McQueen: "This person is talking about setting VMS
parameters on his terminal lines and is doing it incorrectly from what I read.
I'd guess from the message that the problem he is having is that the device
requires DTR to be raised and the modem he is using doesn't (or the terminal
cable doesn't have the line)."  We get questions like this all the time.
What we need is a quick guide to VMS DCL parameters for using Kermit in
various situations -- direct connect, dialin, dialout, etc.  We'll try to
come up with something like this.]

------------------------------

From: uw-apl!apl-em![e-mail]
Date: Thu, 20 Nov 86 09:46:29 pst
Subject: HP9845 BASIC Kermit
Keywords: HP9845 Kermit, BASIC Kermit

Our HP9845's do not recognize the following:

Mass Storage Unit Specifier ":Q"
CCOM, CMODEL, CCONNECT, CDISCONNECT, CCONTROL, CSTAT, CWRITE, CREAD
Block if: IF THEN, ELSE, END IF on separate lines
Case selection: SELECT, CASE, END SELECT on separate lines

These keywords are in fact in ROMs we don't own.  According to our HP
service engineer:

    > Mass Storage Unit Specifier ":Q"

    This is the msus for the "HP7908" disc.

    > CCOM, CMODEL, CCONNECT, CDISCONNECT, CCONTROL, CSTAT, CWRITE, CREAD

    These commands are found in the Datacomm ROM, which can only  be used
    with the HP98046 Datacomm interface.

    > Block if: IF THEN, ELSE, END IF on separate lines
    > Case selection: SELECT, CASE, END SELECT on separate lines

    These are found in the Structured Programming ROM, along with many
    other useful commands like XREF and INDENT.

Since we don't have the above and have no plans to purchase I am considering
redoing the code a little to use the more common I/O ROM and HP98036 serial
interface.  I already have written a terminal emulator which performs quite
well (keeps up at 1200 bps) so I don't forsee any great difficulty.  On the
down side I cannot say when I can get to it.

In any case there should be some words in the HP9845 kermit distribution
about the above ROMs and I/O cards being required.  I don't think the mass
storage unit specifier (MSUS) problem is serious -- people can change that
to their usual MSUS.

[Ed. - HP has such a variety of products, and so many of them come with
BASIC as the only standard (or only, period) programming language, that it
would be very desirable to have a relatively portable HP-BASIC Kermit, if
indeed there is some subset of the language that is consistent across the HP
line, and which does not require special ROMs and options (Is there???).
Meanwhile, your message has been added to the "beware file" for this version
of Kermit.]

------------------------------

Date: Mon, 24 Nov 86 07:26:18 EST
From: Noah Diesbourg <IND@WINDSOR1>
Subject: Kermit for RSX-11/M v3.2 and/or Hyperion PC?
Keywords: Kermit-11, Hyperion PC

Is anyone running Kermit on a

    PDP 11/34 with RSX 11M ver 3.2
             or a
    Hyperion PC?

[Ed. - According to K11INS.DOC, the minimum version of RSX that Kermit-11
can run under is 4.1.  The author's advice to people in this situation is to
upgrade.  It is recognized, however, that there are many old PDP-11 systems
out there that can't be easily upgraded.  There are rumors of bare-bones
remote-only Kermit programs written in Fortran for earlier releases of RSX,
but none of these programs has yet surfaced.  If anyone wants to send one
in, it would be appreciated.  The Hyperion is an IBM-incompatible MS-DOS
system, and should be able to run "generic" MS-DOS Kermit.]

------------------------------

Date: Tue, 2 Dec 86 11:39 EST
From: <[e-mail]> (brian nelson)
Subject: Problem with P-E Kermit?
Keywords: Perkin-Elmer Kermit

This was sent to me by someone using kermit dialup access here.
Anyone know about Perkin-Elmer Kermit?

[e-mail]

> From:   DRWHO::KERMIT        2-DEC-1986 11:33
> Submission by:
> Richard J. Zirbes
> [phone]
> U.S. Geological Survey
> BOX 25046 MS 516
> Denver, CO.  80225

> Environment:
>       OS/32 Version 8.1.2 (not 8.2)
>       all perkin.* files in my work area.
> Problem 1:
>       Source compiles fine using d and o compilers, links okay
> however; when trying to start up using KERMIT.INI file I get:
>       SVC ADDRESS ERROR
>              INST @17A92
>      SVC PARAMETER BLOCK
>              AT C770
>       MEMORY FAULT ADDRESS Z39C1
>       TASK PAUSED.

> also; when I use another file such as KINIT.DAT in the command
>              line:  KERMIT KINIT.DAT
>       the results are the same.

> The files KINIT.DAT and KERMIT.INI look like:
> SET PARITY EVEN
> SET PACKET 90
> SET FCHEK OFF
> SET 8BIT OFF
> SET SEOR LF
> SET FILE TEXT
> EXIT

> Problem 2:
> I run kermit without an initializer file and enter the parameters
> defined above interactively and send a file to my ckermit I get
> transmission errors and kermit-co times out.  Ckermit has settings:

> mode:                local
> parity:              even
> duplex:              full
> flow:                xon/xoff
> handshake:           none
> packet start:        1
> packet end:          13
> packet length:       90

> block check type: 1, delay: 5
> 8th bit prefix       '&'

> File Names:          converted
> File Type:           text

> Please contact me with any solutions. Thank you.

------------------------------

Date: Tue, 02 Dec 86 09:07:00 PST
From: jfisher@USGS3-VMS
Subject: PR1ME Kermit with connect capability?
Keywords: Prime Kermit

I am in need of a Kermit implementation for PR1ME machines that can be run
in local mode, 'dialing-out' through a comm. port to another mini Kermit, so
as to transfer files between them.  I spoke to Leslie Spira of The Source,
who said she didn't have one, but she had a vague recollection that somebody
else might have modified her PR1ME Kermit to allow it to connect out. Does
anybody out there have such a beast ?

------------------------------


End of Info-Kermit Digest
*************************
-------
19-Dec-86 12:09:28-EST,18669;000000000000
Mail-From: SY.CHRISTINE created at 19-Dec-86 12:07:37
Date: Fri 19 Dec 86 12:07:37-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #19
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 19 Dec 1986       Volume 5 : Number 19

Today's Topics:

           New Kermit Program for IBM 370 Mainframes with MVS/TSO
                           Kermit-MPX version 2.3
                         Misuse of Okstate services
                             C-Kermit and Xenix
                         C-Kermit on Microport Unix
                  Uploading Macintosh Binhexes with Kermit
                        Bug in Apollo Pascal Kermit
                            Prime kermit connect
                              Kermit and X.25
                         Problem with HP9845 Kermit
                       HCP and HC6 Versions of Kermit
                 Need Fast De-BOOing Program for the Amiga
                            Data General MV2000
                 Kermit 3.1 - An interesting speed problem
                           Symbolics V7.0 Kermit

----------------------------------------------------------------------

Date: Thu 18 Dec 86 15:31:12-EST
From: Frank da Cruz <[e-mail]>
Subject: New Kermit Program for IBM 370 Mainframes with MVS/TSO
Keywords: MVS/TSO Kermit

The new IBM 370-series mainframe MVS/TSO Kermit from the US National
Institutes of Health (NIH), announced in the previous Info-Kermit digest, is
now available in the Kermit distribution areas under the prefix TSN.  There
are 21 files, comprising a total of about 3 megabytes, including three
documentation files and a TSO help file.

The program is written in "ALP", which is a preprocessor for 370 assembly
language developed at NIH.  The ALP preprocessor, also supplied, is written
in PL/I.  For those who do not have PL/I or do not wish to bother with the
source programs, a hexidecimal-encoded object file is provided, along with
an assembler program to decode it into a binary object file; this can be
linked with a tailorable module (written in straight assembler) in which
site dependencies, such as the ASCII/EBCDIC translations, are specified.

Before deciding to transfer all 3 MB from Columbia over a network, first get
the file TSNKER.TXT, which explains which files are which, and then only get
the ones you really need.

Thanks to Roger Fajman at NIH ([e-mail]) for submitting this program
to us.  Roger participated in the design with Dale Wright, who then did the
programming.  The new program has many advanced features over previous TSO
Kermit versions, including server mode, binary file transfer, file
interruption, 8th-bit prefixing, run-length encoding, alternate block check
types, and support for both 3705-style line mode and Series/1-style full
screen emulation.  It is hoped that this new version will render the old
University of Chicago (linemode only, circa July 1984) and University of
Toronto versions (Series/1 only, March 85) obsolete.  Reactions from TSO
sites will be appreciated, in the interest of keeping redundant Kermit
versions at a minimum.  Reactions from users of the Pascal/VS version from
the University of Bern (linemode only, Sept 86) will also be appreciated.

For the present, the Chicago, Toronto, and Bern versions remain available in
the Kermit distribution under the prefixes TSO, TSO, and TS2, respectively.
For the future, there may still be another TSO Kermit program on the horizon, a
result of a cooperative effort among IBM mainframe Kermit sites to develop a
Kermit program that is portable among all IBM 370 mainframe operating systems
(no estimate as to when this will be ready, but IBM mainframe system
programmers who are interested in developments in this area may send mail
to IBM-KERMIT@CU20B or IBM-KERMIT@CUVMA).

------------------------------

Date: Sun 7 Dec 86 22:40:44-MST
From: Mike Niswonger <[e-mail]>
Subject: Kermit-MPX version 2.3
Keywords: Gould, SEL, MPX

    The latest version of Kermit-MPX (GM2) for Gould machines is now
available for you to FTP from my directory at Simtel20.  All files are found
in directory PD:<MISC.GOULD-KERMIT>GM2KERM.*.  This release 2.3 of
Kermit-MPX, which is also being submitted to the Gould User's group library.
                    -- Mike Niswonger

[Ed. - Thanks Mike!  The files are also available through KERMSRV at CUVMA
and on CU20B using FTP (user ANONYMOUS), any password.  These files have
replaced the old KER:GM2*.* and the old files are now in KO:GM2*.*]

------------------------------

Date: Mon, 08 Dec 86 18:50:27 -0600
From: Mark Vasoll <[e-mail]>
Subject: Misuse of Okstate services
Keywords: Okstate, Oklahoma State

Fellow Kermiters,

    It saddens me to inform you all that various people have started to
abuse the UUCP login "uucpker" on Okstate by attempting to use us as a
jumping off point for mail.  While we enjoy providing the home for Kermit
access via UUCP, we have no desire to become a major mail relay point for
various random systems.  To this end, I have had to place a restriction on
our UUCP to not accept the "rmail" command from any system using the uucpker
account.  This will, unfortunately, make it more difficult for people to
report problems to okstate!uucp-support, but there is very little I can do
about it.  Please use the following mail paths when reporting problems with
the Kermit distribution (no phone calls please).

Internet:  [e-mail]
      or:  [e-mail]

UUCP    :  {cbatt, cbosgd, ihnp4, pesnta, rutgers, seismo}!okstate!uucp-support


Mark Vasoll
Computing and Information Sciences       Internet:  [e-mail]
Oklahoma State University                UUCP:  {cbatt, cbosgd, ihnp4, pesnta,
Stillwater, Oklahoma                            rutgers, seismo}!okstate!vasoll

------------------------------

Date: Tue, 9 Dec 86 08:05:48 EST
From: [e-mail]
Subject: C-Kermit and Xenix
Keywords: Xenix, C-Kermit

RE: Info-Kermit Digest V5 #18

I recently put the latest C Kermit (4D(061)) up on a Tandy 16/6000 running
Xenix 3.1 with no problems.  I used the make sys5 command to compile; only
changes needed were to include /sys/typedefs.h for the void identifier found
in one file.  Everything seems to be working ok so far.

------------------------------

Date: Mon, 15 Dec 86 10:17:15 EST
From: es![e-mail]
Subject: C-Kermit on Microport Unix
Keywords: C-Kermit

I just compiled 4D(061) using 'make sys3'. It work right from the start.
Many people have sent in messages about trouble getting Kermit to run on
XENIX. I had used XENIX for a time, but found the include files and compiler
contained many errors and incompatibilities with real system V Unix.

Microport Unix is a full System V for the IBM-AT. Unlike XENIX, it is based
on the current Sys V sources and therefore Kermit was easy to get running.
Those of you using XENIX may want to investigate this new package.

Dan Senie

PS. I am not connected in any way with Microport Systems, ATT, etc.

     UUCP:     ...!harvard!anvil!es!Dan_Senie     (case is important!)
     ARPA:     anvil!es![e-mail]

------------------------------

Date: Sun, 7 Dec 86 11:29:35 pst
From: gould9![e-mail] (Joel West @ Western Software Technology)
Subject: Uploading Macintosh Binhexes with Kermit
Keywords: UNIX, MacKermit, hqx

I've been meaning to send this along for a while, but I wasn't sure anyone
was interested.  A query on INFO-MAC prompted this posting.

It is a UNIX csh script (MACKERM) that I use to upload binhexes using
kermit.  If for a file foo.hqx, it first sends the header (before the
binhex) as 'About foo', then sends foo.hqx.  I use the header to later note
the origin on the final unhexed file.

To make this work, you need to take the first file (usually a short About...
file) manually, selecting the target directory.  Then place your MAC in
server mode, since each 'kermit' command at the UNIX side is a separate
session, and the Mac would otherwise quit file transfer mode.

Oh yeah, it also works on ordinary files, preserves actual names ('FooBar'
instead of 'FOOBAR') and NEVER transfers a directory.  So it's real useful
to type
    mackerm *
place the Mac in server mode, and walk away.

    Joel West
    [e-mail]    ihnp4!gould9!joel

==File =====

    #!/bin/csh
    # by Joel West, ihnp4!gould9!joel, 11/14/86
    # Script to send binhexes and other files
    # Also preserves exact upper/lower case name
    set noglob
    foreach f ($*)
        if (-d $f) continue
        set typ=$f:e
        switch ($typ)
          case hqx:
          case hex:
        set r=$f:r
        set T1=/tmp/kermdat_$$
        set T2=/tmp/kermhqx_$$
        rm -f $T1 $T2
        cat $f | cutat '(This' $T1 $T2
        kermit -s $T1 -a "About $r"
        kermit -s $T2 -a $f
        rm -f $T1 $T2
        breaksw
          default:
        kermit -s $f -a $f
        endsw
    end

== EOF ==

[Ed. - Thanks.  This hint has been added to the Macintosh Kermit .BWR
file, CKMKER.BWR.]

------------------------------

Date: Fri 14 Nov 86 10:34:23-PST
From: Ted Shapin <[e-mail]>
Subject: Bug in Apollo Pascal Kermit
Keywords: Apollo Kermit

We found that the Pascal kermit for the Apollo inserts extra line feeds
every 256 characters if there is no line feed carriage return in the file.
We traced it to the I/O in the Pascal program which can only read 256 byte
lines.

[Ed. - Thanks for the information.  This message is now in the file
KER:APOLLO.BWR.]

------------------------------

Date: Wed 10 Dec 86 10:45:54-PST
From: Bob Larson <[e-mail]>
Subject: Prime kermit connect
Keywords: Prime Kermit

I have a partially working one, based on the old version of prime kermit.
I'm not even sure if I have a complete set of sources for it on tape any
more.  Known bugs include dropping characters in connect mode, problems with
some of the message strings (incorect use of ioa$), and not supporting 2400
baud.  (Writen before prime standardized the "optional" speeds at 2400 and
4800 baud for autobaud.)

I have been considering making improvements to the current prime kermit, with
support for amlc lines among them.

------------------------------

Date: WED, 10 DEC 86 17:17:13 BST
From: CJK @ UK.AC.SALFORD.R-D
Subject: Kermit and X.25
Keywords: C-Kermit, X.25

     Points from infodigest 5/17.  First Steve Walton & Telenet:

     We over this side of the pond are quite used to using Kermit over
X.25 networks (posing as an X.29 terminal).  It works fine, at least in
the micro-mainframe mode, with call originated by the micro.  Efficiency
should not be affected much until the ratio:

        time-through-network / front-end-delay

reaches about 5.  The crucial thing is to set up the X.3 parameters in
the PAD so that the whole Kermit packet gets into a single X.25 packet;
it is bound to be shorter than the 128-byte maximum on X.25.
In general you have to use a transparent-type mode to let the SOH get
through, but there is no need at all to forward on every character (which
simply fills up the X.25 window with single-character X.25 packets).
Provided the EoL is a forwarding character, which it will be if it is CR,
all works fine.  What you actually do depends on the user interface
provided by your PAD.  This is in fact all covered in your book.

     Of course, network congestion can slow things down.  Our X.25s, the
public PSS and private JANET, have maximum time-through-networks of about
0.1 sec in all normal circumstances, so no problem.  But I heard last week
in a different context that the congestion on ACCUNET was so severe that
holding transatlantic calls open was very difficult.  If Telenet is in
the same state, then you've got problems.  But blame the sizing of the
network, not X.25 or Kermit.

     Does CKermit really limit you to 65% of line-speed?  I tested
homegrown Kermits here (at up to about 30Kbaud) and found that, with
data-compression on, I always got better than 100% of linespeed.  If
CKermit is really that slow, is it losing time somewhere that it
needn't?

     Incidentally, switching over to Kuryan Thomas' problems with his
autodialler:  Many UARTs will not receive if DCD is not high (it's a
protection against line-noise).  If you have one of these, and an
autodialler which does not hold up DCD while it is trying to talk
to you, then you have no option but to strap DCD to one of the other
pins, e.g. DSR.

                                Chris Kennington.

------------------------------

Date: 11-DEC-1986 09:47:23
From: [e-mail]
Subject: Problem with HP9845 Kermit
Keywords: HP Kermit
Cross-Ref: Hewlett-Packard Kermit

It's not a bug: it's a problem regarding some assumptions regarding the
machine configuration, which I should have spelt out when I sent it in.

We have explained/apologised to one or two people who contacted us directly,
and if in a fit of absent mindedness I had not deleted a note I had from
Chris regarding the configuration assumptions, I would forward it to you for
a BWR file. As I mentioned when I sent it in, it does not pretend to be a
full kermit, more a minmalist bulk data transfer utility conforming to the
kermit protocol.

It is probably possible to bypass the need for specific ROMs and so on by
the use of inline assembler, however, if the ROMs are available, it is
better to use the facilities provided by the HP virtual communication
device.

I'll get the precise details from Chris as soon as possible for you for
inclusion in a BWR

Sorry about the hassle,
                              Doug

------------------------------

Date: 11 Dec 86 13:42:00 EST
From: John Stewart <[e-mail]>
Subject: HCP and HC6 Versions of Kermit
Keywords: Honeywell Kermit

   I was looking at the versions file and noticed that two versions of
Kermit are listed for our machine, HCP and HC6.

   HCP is a Pascal implementation of Kermit that was ported to the Honeywell
Cp-6 operating system by Bucknell University.  It is a very minimal
implementation (it doesn't even do repeat counts, let alone advanced
features like server mode).

   HC6 is much more complete then HCP, and both the original developer and
myself are continuing to enhance it.

   I suggest that distribution of the HCP version of kermit be discontinued.

Regards.. jas

[Ed. - Thanks, this seems to be the concensus of opinion; the HCP version
was indeed retired to Tape C.]

------------------------------

Date:  Wed, 10 Dec 86 10:33 EST
From:  "John G. Ata" <[e-mail]>
Subject:  Need Fast De-BOOing Program for the Amiga
Keywords: Amiga Kermit

Can somebody out there who has a C compiler on the Amiga please compile
CKIBOO.C and then make a BOO file out of it and send it in to Kermit
Distribution as, say, CKIBOO.BOO, so that those of us without a C compiler
only have to run the Basic de-booer once, on CKIBOO.BOO, and then can
subsequently use the compiled de-booer which should be much faster.  It
takes about an hour to de-boo Amiga Kermit with the Basic de-booer.

                    John G. Ata

------------------------------

Date: Tue, 16 Dec 86 16:25:14 est
From: munnari!latcs1.oz![e-mail] (Philip Lee)
Subject: Data General MV2000
Keywords: Data General

Has anyone sucessfully ported the unix kermit to Data General MV2000 running
DG/UX ver. 3.00? We've tried recompiling ver 4D on it.  It compiled without
complaining, but gave link error. However it sort of work. We could do ascii
file transfer, but any compressed file or any of those using all 8 bits would
fail. The DG kermit would accept set file type binary quite happily and
indicate the same, but on file transfer it would just time out and fail.

In generating the DG/UX kermit we used the following:

make wermit \
 "CFLAGS = -D_file=_fd -DUXIII -DDEBUG -DVER2 -DTLOG -O4" "LNKFLAGS ="

Could this be also related to the problem of 8 bit transfers between FIDOnet
Kermit and the Pyramid?

[Ed. - The FIDO question has still not been totally solved, mostly because
of lack of time, but it might help you to know there's a version of Kermit
specifically tailored for DG MV/UX (is that the same thing?), based on an
old release of Unix Kermit, available in the Kermit distribution under the
prefix DGM.  There's also a C-Kermit implementation for AOS/VS on the way.]

------------------------------

Date: Sun, 14 Dec 86 14:56:29 +0200
From: Sam Gamoran <VSSAM@WEIZMANN>
Subject: Kermit 3.1 - An interesting speed problem
Keywords: CMS Kermit, PROCOMM

We just installed CMS Kermit 3.1 - appears to solve our problems with 2.1
particularly the program hanging and binary transfers.

We use CMS Kermit through a 7171 against PCs running either MS-DOS Kermit
2.28 or Procomm 2.3 with the Kermit file transfer option.  Works great with
MS-DOS Kermit 2.28 but file transfer crawls with Procomm 2.3.

Every packet sent by CMS-KERMIT 3.1 ends with an X-ON character.  The old
CMS-KERMIT 2.1 did not do this.  It appears that this X-ON character causes
Procomm to delay a second or so before sending the next packet.  We saw on a
line monitor packets going out from PC to mainframe and an instantaneous
response followed by a delay.  With the old CMS-KERMIT, where the main
difference between packets is the absence of the final X-ON character no
delay occured and transfer throughput was 400% faster!

Do you know of anyone having experience with PC->Mainframe file transfer
using PROCOMM who has encountered similar problems? I am also sending this
query to the procomm folks.  Thanks,

Sam Gamoran

------------------------------

Date: Tue, 16 Dec 86 15:39 CST
From: "David S. Cargo" <[e-mail]>
Subject: Symbolics V7.0 Kermit
Keywords: Symbolics Kermit

Symbolics is upgrading their system software to version 7.0.  The old
Symbolics Kermit no longer works with the new system revision.  Has anybody
upgraded the existing version to run on the new system?  I'm trying to avoid
some wheel reinvention.

------------------------------

End of Info-Kermit Digest
*************************
-------
31-Dec-86 15:55:38-EST,14580;000000000000
Mail-From: SY.FDC created at 31-Dec-86 15:54:33
Date: Wed 31 Dec 86 15:54:33-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V5 #20
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

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)   <[e-mail]>
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:  [e-mail]
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   {[e-mail]}

------------------------------

Date: 21 Dec 86 04:30:32 GMT
From: ihnp4!killer![e-mail]
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![e-mail] (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 <[e-mail]>
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
*************************
-------