kermit.columbia.edu/kermit.columbia.edu.tar/kermit.columbia.edu/e/mail.88a

Text File | 1988-08-16 | 340KB | 7,824 lines

13-Jan-88 17:46:00-EST,14271;000000000001
Mail-From: SY.CHRISTINE created at 13-Jan-88 17:44:59
Date: Wed 13 Jan 88 17:44:58-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #1
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 13 Jan 1988        Volume 7 : Number 1

SPECIAL EDITION:

                       Announcing MS-DOS Kermit 2.30
         Announcing version 2.29Z of MSKERMIT ported to RMX86 & RMX286

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

Date: Mon, 11 Jan 88 19:55 MST
From: Joe Doupnik <JRD@USU> and Frank da Cruz <SY.FDC@CU20B>
Subject: Announcing MS-DOS Kermit 2.30
Keywords: MS-DOS Kermit 2.30, IBM PC Kermit 2.30, DEC Rainbow
Keywords: Tektronix Emulation, NetBIOS

This is to announce a major new release of the MS-DOS Kermit communication and
file transfer program, version 2.30, the first major release since version 2.29
appeared in May 1986.  The code has been frozen as of January 8, 1988.  Any
further features or fixes will be deferred for future releases.

The major new features of version 2.30 are:

 . Long file transfer packets (up to 1000 bytes)
 . NetBIOS local area network support
 . A simple script language for automated dialogs with other computers
 . Tektronix 4010 graphics terminal emulation
 . Improved DEC VT102 and Heath 19 emulation
 . ANSI printer control
 . Selectable initialization file names
 . File transfer performance statistics reporting
 . A new, more powerful, more portable key redefinition facility
 . Support for new IBM keyboards
 . A mechanism for installing COM3 and COM4 support
 . Ability to assign Kermit connect-mode "verbs" to arbitrary keys
 . Keyboard and port input character translation during terminal connection
 . Support for both 7-bit and 8-bit (international) character sets
 . Improved interaction with DOS batch programs
 . More flexible command-line invocation options
 . Security features for server operation
 . Ability to operate Kermit through an external console via CTTY
 . Compatibility with most internal modems
 . Modem status report (CD, DSR, CTS)
 . Increased memory for screen rollback, macro and key definitions
 . Garbage collection of macro and key definition memory
 . Improved cooperation with half-duplex hosts
 . Improved DOS error handling
 . Improved debugging and logging functions
 . Improved consistency of command syntax
 . A completely rewritten manual

The program requires DOS 2.0 or later, and 90K+ of memory.  Version 2.30
currently runs on the entire IBM PC family, including the new PS/2 series, on
IBM clones such as the Compaq, AT&T 6300, and DEC VAXmate, and on "semi-clones"
like the Seequa Chameleon and Data General/1, which have different serial port
adapters.  There is also a specific version for the DEC Rainbow (which does not
include Tektronix emulation), and a "generic MS-DOS" version that should run on
any DOS machine, using only DOS calls (no specific terminal emulation).

Thanks are due to James Sturdevant of A.C. Nielson Company for the initial
implementation of the script language, to Joe Smith of the Colorado School of
Mines and Brian Holley of the University of Cambridge (UK) for the original
Tektronix emulation code, to David Knoell of Basic American Foods for the
initial implementation of "Kermit verbs" assigned to keys, and to AT&T for
supporting the NetBIOS development.

And thanks also to the hundreds of Info-Kermit Digest subscribers who tested
the many prereleases of this program, reported bugs, and suggested new
features, and who read and commented on drafts of the new manual.

The new IBM version replaces several previous versions that were distributed
separately, including the MSVCLO version (for IBM near-clones like the Seequa
Chameleon and DG/1) and the Olivetti M24 version.

Untested versions are included for the HP-150, HP-110 and Portable PC, and
the Grid Compass II -- if you have any of these machines, please try out the
new version!

Previous releases of MS-DOS Kermit also ran on a number of other machines,
including the Wang PC, Victor 9000, Sanyo MBC, NEC APC and APC3, etc.  The code
for these non-IBM compatibles will also be to 2.30 level, and released when
available.  Volunteers to test and fix the code for these machines are heartily
encouraged to step forward!

The files for version 2.30 have been installed in Kermit Distribution at
Columbia University.  They are available on the Internet from host
CU20B.COLUMBIA.EDU (a DECSYSTEM-20) as follows: run FTP, log in as user
ANONYMOUS, any password, and GET (or MULTIPLE GET, or MGET, according to the
syntax of your FTP program) the desired files.  They are also available on
BITNET and EARN from host CUVMA (an IBM mainframe) by sending a message to
KERMSRV@CUVMA requesting the desired files.  To learn more about KERMSRV, send
it a message "HELP".  KERMSRV at the University of Toledo (UOFT02) (a VAX/VMS
based Kermit file server) also has the files, and eventually, they will also be
available via UUCP from Oklahoma State University, from and from dialup
bulletin boards around the world.

The executable files are stored in a special printable bootstrap format, called
"BOO files".  These are decoded into .EXE files using a "BOO-file decoder"
program.  These are available written in various languages, including Basic,
MASM, C, and Pascal.  The documentation is available online in plain ASCII text
format, and in Scribe text formatter source format.  Following is a synopsis of
the files.  The KERMSRV name is the same as the CU20B name, except the "KER:"
should be omitted, and the period between the filename and filetype should be a
space, e.g. KER:MSAAAA.HLP on CU20B is MSAAAA HLP on CUVMA.

 CU20B Name        Size        Description

 KER:MSAAAA.HLP      7K        Explanation of file naming conventions
 KER:MSB*.*        130K total  BOO-file encoding/decoding programs
 KER:MSVIBM.BOO     97K        IBM PC Kermit, BOO-encoded executable
 KER:MSVRB1.BOO     68K        DEC Rainbow Kermit BOO file
 KER:MSVGEN.BOO     62K        Generic MS-DOS Kermit BOO file
 KER:MSTHP1.BOO     63K        HP-150 (untested)
 KER:MSTHPX.BOO     64K        HP-110 and Portable PC (untested)
 KER:MSTGRI.BOO     64K        Grid Compass II (untested)
 KER:MSKERM.DOC    263K        MS-DOS Kermit manual, plain ASCII text
 KER:MSKERM.MSS    263K        Scribe text formatter source for manual
 KER:MSKERM.HLP     12K        A summary of MS-Kermit commands
 KER:MSKERM.BWR     11K        List of known restrictions, bugs, etc.
 KER:MSS*.*        638K total  System-independent MASM Source files (13 files)
 KER:MSG*.*        110K each   System-dependent source (graphics, IBM only)
 KER:MSU*.*      70-85K each   Sys-depn source (keyboard support, all systems)
 KER:MSX*.*     39-150K each   Sys-depn source (port i/o, etc, all systems)
 KER:MSY*.*        100K each   Sys-depn source (terminal emulation, IBM only)
 KER:MSZ*.*        183K each   Sys-depn source (term emul, cont'd, IBM only)
 KER:MSV*.MAK        2K each   Microsoft MAKE files for each version
 KER:MSV*.BAT        2K each   Batch files to build each version
 KER:MSV*.LNK        1K each   LINK command files for each version

The utility program MSUCHK.C (and .BOO), contributed by Phil Benchoff of
Virginia Polytechnical Institute, allows convenient determination of
MS-Kermit's new keyboard codes on the IBM PC family.

Be sure to read the MSKERM.BWR file before trying to use the new version, or
reporting any problems with it.

Here are the minimum files needed for the new release ("xxx" stands for the
specific version, IBM, RB1, or GEN):

1. For everybody: The documentation -- MSKERM.DOC, MSKERM.HLP, MSKERM.BWR.

2. For those who already have Kermit on their PC:  MSVxxx.BOO.  If you don't
   have the MSBPCT "BOO-file decoder", also get that.

3. For those who want to make modifications to the sources:
   MSS*.*, MSGxxx.* (if any), MSXxxx.*, MSYxxx.* (if any) ,MSZxxx.* (if any),
   MSVxxx.MAK (or .BAT if you don't have MAKE), and MSVxxx.LNK.

The systems for which we don't yet have the new version ready are still in
the Kermit distribution as before, under the MSV, MSX, and MSY prefixes.  These
will be replaced as the new ones appear.

The IBM PC and DEC Rainbow versions may also be ordered on diskette from
Columbia, along with typeset, printed copies of the manual.  The IBM version
is available on 5.25-inch 360K DS DD diskettes, and on 3.5-inch 720K DS
diskettes for the PS/2 family.  The Rainbow version is on RX50.  Send mail to
[e-mail] or [e-mail] for ordering
information.  The distribution diskette for the IBM PC version will also be
submitted by Columbia to various user groups and diskette services.

New Features -

Of particular interest are the Local Area Network and Tektronix items.  Both
are available only for the IBM PC version of Kermit-MS.

LANs can be used as a communications pathway between cooperating Kermits and
between Kermit-MS and a host which allows direct remote logins from the LAN.
The mechanism is the NetBIOS emulator program supplied with each network, and
thus it works with most LAN systems.  Any station can become a Kermit network
server or a client, without interference with the regular network fileservers,
to allow multiple Kermit to Kermit links on a voluntary peer to peer basis.
The mechanism uses just the NetBIOS and not vendor dependent Asynchronous
Communications software packages (Kermit puts its own packets or Connect
mode characters in NetBIOS packets and uses the NetBIOS protocol in addition
to the standard Kermit protocol).

Tektronix terminal emulation provides standard line drawing, dot, and
character graphics of the 4010 class terminals using true graphics on the PC.
Kermit-MS automatically determines the display and display adapter board in
current use and does high resolution graphics in response to Tek style
commands (which are described in the new Users Manual).  Display adapters
currently supported are EGA, CGA, Hercules, AT&T/Olivetti, and even regular
Monochrome (with text characters rather than dots).  The graphics will be in
color (foreground and background) and will be preserved separately from
ordinary text (VT102, VT52, Heath-19) screens if the hardware permits and one
can switch back and forth from the keyboard.   Tektronix specifications have
been extended slightly to allow the host to switch Kermit-MS into and out of
graphics mode automatically for easy plotting from packages such as SAS.

The IBM PC version now supports the COM3 and COM4 ports available on many
machines with added hardware, provided the user informs the BIOS of their
presence.  The Users Manual shows how to do this.  Kermit-MS/IBM adapts to
screen dimensions found at startup, such as 132 columns or 43 lines, and is
able to switch several popular non-IBM EGA boards to 132 column mode under host
control.

Long packets, up to 1000 bytes, are supported to increase efficiency on long
haul communications circuits.  Efficiency increases by using fewer packets and
thus less overall time waiting for packets to be acknowledged.  Strong three
byte CRC checking is encouraged; it does not degrade local performance.  Long
packets are a reasonable alternative to the sliding windows approach which has
a problem on PCs when they attempt disk i/o while receiving characters on the
serial port (interrupts can get lost and packets need to be repeated).

Translation mechanisms are present to assist multilingual usage of essentially
ASCII or English style machines.  These are not panaceas for a very complex
problem, but testing in Europe indicates it is a step in the right direction.
The mechanisms are conversion of characters about to be displayed, control of
character size (7 or 8 bits), and the new generalized keyboard handler present
for all MS DOS machines.

A sustained awareness of supplementary input and output devices used by
disabled and other individuals is present in many parts of the program.  As we
learn more about such devices Kermit-MS will try to make their use possible and
comfortable.

Overall, the interior technical improvements are numerous.  This gives us added
flexibility and increased performance.

And may we share with you -

Like any Kermit program, MS-DOS Kermit is for everyone to use and share.  Once
you get it, feel free to pass it along to your friends and colleagues.
Although it is copyrighted and not in the public domain, we ask only that you
not attempt to sell it for profit, and that you use it only for peaceful and
humane purposes.  If you have comments, suggestions, improvements, or fixes,
please send them to Kermit Distribution at Columbia University, where they can
be considered for the next release or added to the "beware file".  Happy New
Year, and use Kermit in good health!

  Joe R. Doupnik                               Frank da Cruz
  Center for Atmospheric and Space Sciences    Center for Computing Activities
  & Dept of Electrical Engineering             Columbia University
  Utah State University                        612 West 115th Street
  Logan, Utah  84322                           New York, NY 10025
  [e-mail]                               [e-mail]

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

Date: Wed, 06 Jan 88 19:18:10 PST
From: [e-mail]  (Jack Bryans)
Subject: Announcing version 2.29Z of MSKERMIT ported to RMX86 & RMX286
Keywords: Intel, RMX Kermit

This version was made from the version 2.30 sources of MSKERMIT.  Last minute
fixups of the RMX code to support changes from version 2.29C are included.
If there are no problems in the next couple of weeks, it will be released as
version 2.30.  The RMX86 port is MSTRMX.BOO, the 286 is MSTRX2.BOO.
MSTRMX.DOC is still relevant.

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

End of Info-Kermit Digest
*************************
-------
22-Jan-88 17:08:31-EST,31139;000000000000
Mail-From: SY.CHRISTINE created at 22-Jan-88 17:07:33
Date: Fri 22 Jan 88 17:07:33-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #2
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 22 Jan 1988       Volume 7 : Number 2

Departments:

  ANNOUNCEMENTS -

       MSTZ10.BOO (New version of Z-100 Kermit-MS)
       New Versions of MSBMKB and MSBPCT
       Request to Originators of Kermits on BITNET
       Texas University CDC Kermit No Longer Supported
       TRS-80 Model II Kermit Files?

  MS-DOS KERMIT -

        MSTIBM Tek-Mode Problem
        Re: Observations on new Kermit 2.29C with partial Tektronix emulation
        Use of IBM PC Kermit to Control a Video Disk Player
        Retaining Past Screens
        MSKERMIT ver 2.29C tektronix 4010 won't overlay ALPHA and VECTOR
        Screen Scroll in MS-Windows
        MS-KERMIT V2.29C DATED DEC 16/87 VT102 PRINTER PROBLEM
        Kermit 2.29C
        Tektronics 4010 Kermit
        MS-KERMIT 2.29c Scroll-Back Problem with New Output
        MS Kermit and C language.
        MS-Kermit 2.30 Problem
        Problems with Kermit 2.30
        Kermit 2.30 Lack of Screen Blanking Solved
        Rainbow MS-DOS Kermit 2.30
        Generic MS-DOS V2.3 Problem
        MS-KERMIT 2.30

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

Date: Sun, 17 Jan 88 21:34:58 EST
From: Drew Derbyshire <[e-mail]>
Subject:  MSTZ10.BOO (New version of Z-100 Kermit-MS)
Keywords: Z-100 Kermit, Zenith Kermit

Following this as separate mail you will find a .BOO file for a new version
of Z-100 Kermit-MS.  This version, tagged internally as 2.29d, was created
by me from the system independent 2.30 sources now online at
cu20b.Columbia.EDU and debugged MSxZ10.ASM sources that I got from Joe
Doupnik in October.

This is not my final version, but the program appears stable and I am
mailing it while I have a chance.  (Anything that works better thank Joe
for, anything that is broken blame me for.)  Changes to the program from the
2.29c version of MSTZ10 include:

     Z-200 support is deleted.  This was partially because I am
     using the standard ZDS include files for BIOS and hardware
     specific constants instead of dynamically chosen "magic"
     numbers, and partially because if problems were to arise
     with the Z-200 code I can't recreate them.  (Z-200 users
     can boot their systems in IBM PC mode and use the better
     IBM Kermit-MS.)

     A screen escape sequence output via DOS from the GETKEY
     routine is deleted.  This interfered with the output of
     various escape sequences and also slowed CONNECT mode down
     to where it fell behind at speeds as low at 1200 baud.

     An improperly installed internal queue for the AUX port is
     deleted.  This was causing monitor RAM and other storage
     overlays which in turn resulted in various display problems
     and system crashes.

     Output from within the terminal emulator is now done via
     direct calls to the Z-100 monitor ROM.  File transfer output
     is still done via DOS, so most "screen saver" programs will
     continue to work properly and not blank the screen during long
     file transfers.

     The HANGUP command is added.

     The BREAK command is fixed.   Formerly, it hung up the
     phone.

     The CONNECT mode HELP command no longer improperly enters
     server mode.

     Key values returned by the SHOW KEY command now match the
     values in the Z-100 user's manual.

This version has the following known bugs:

     The SHOW MODEM command returns incorrect information.

     All input on the keypad is taken as alternate keypad mode;
     the VT-52 escape sequence to have the keypad output normal
     numerics will be ignored.  However, the SET KEY command can
     be used to force these keys to output numerics.

     If the host sends the disable scan mode sequence (esc X ?),
     the keyboard translator will be disabled for all function and
     keyboard keys until CONNECT mode is exited and re-entered.

     The unshifted BREAK key is invisible to KERMIT.

These are for most part minor problems, and I consider the program
quite usable while I take my time correcting the bugs and exercising
the code in general.  Once these error are corrected, I will forward
the updated BOO file and sources to Info-Kermit.

Anyone desiring my interim sources may send me a note directly.

Drew Derbyshire

p.s. Don't thank me, thank Joe Doupnik for putting up with my questions
     and lack of results for four months, and thank Clarkson University's
     Educational Resources Center for providing E-mail and technical
     assistance.

Bitnet:    ahd@clgw
Internet:  <[e-mail]>
Voice:     914-339-7425
U.S.Snail: 578 Broadway, Apt 6
           Kingston, NY 12401

[Ed. - Thanks Drew (and more thanks to Joe too).  The file has replaced the
old one in KER:MSTZ10.BOO available thru Arpanet by FTPing to CU20B, user
ANONYMOUS (any password) and thru BITNET using KERMSRV.]

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

Date: 15 January 1988, 18:15:04 SET
From: RECK@DBNUAMA1 (Gisbert W.Selke)
Subject: New Versions of MSBMKB and MSBPCT
Keywords: .BOO Files

I have just sent you MSBMKB.FOR and MSBPCT.FOR.  They are written in as plain
FORTRAN IV as possible to make them better portable; however, some things like
writing/reading binary files are system specific. I have tried to indicate
those places. Also, I have included as much as I knew about BOO format in
comments.  In addition, I am sending MSBMKB.PAS, written in Turbo Pascal
(3.02). It runs quite a bit faster than the C version due to i/o buffering. I
include a boo-ed version of the COM file.

Congratulations on *the* *final* MS-Kermit 2.30!! What I have seen from
it up to now, I'm completely happy with it. Great stuff!

\Gisbert

[Ed. - Thanks, Gisbert!  Your en/de-BOOing programs are now installed in
the Kermit distribution as MSBPCT.FOR, MSBMKB.FOR, along with MSBPCT.PAS,
a Turbo Pascal version you sent us last November.]

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

Date: 14-JAN-1988 17:06:37 GMT
From: [e-mail]
Subject: Request to Originators of Kermits on BITNET
Keywords: Lancaster University

Readers of the Columbia Info-Kermit Digest might be aware that Lancaster
University in England runs a distribution service parallel to that offered
by Columbia on their CU20B system. We have a collection of Kermit files that
is as close to what's available on CU20B as possible and can be accessed on
the British universities network or over dial-up lines. We also write tapes
and discs for people who want them.

Until recently, we've been keeping our set of files up-to-date by FTP'ing
from CU20B, and we've been no more than a few days behind the US.  However,
the FTP service from Britain to Arpa closed last year, so we can't acquire
anything by that route.  We also have no capability to request files from
BITNET servers.  We get sets of tapes from Columbia a few times a year
(thanks very much to Chris and Frank for this) but inevitably we now lag 3
months or more behind.

So here's a plea to Kermit contributors who use BITNET to mail or FTP their
files to Columbia: if you would be prepared to send a parallel set of files
to us at the same time, we'd be very grateful to receive them, and we'll
look after distributing them in this country.  There's a very active Kermit
community over here which we co-ordinate with our own Info-Digest, so
there'll be more timely feedback for developers if we can get hold of
versions quickly.

We can accept files by mail over BITNET addressed to

             syskermit%uk.ac.lancs.vax1 @ ac.uk

at any time.  It should be OK to send up to 100K minimum per file; there will
be no space problems here so people can send without pre-arrangement.  If
mailing files is a problem we can accept them by FTP (we can't *pull* files
from BITNET, so we have to ask people to send): please mail to me for
details of a receiving account.

Traffic to us on Arpa has to be kept to a minimum, I'm afraid, so please
*don't* send stuff to us on this route. But if you have an Arpa-BITNET
gateway you can use.....

My thanks, and those of the British Kermit community, to anyone who can help
us out with this. We hope to hear from you.

          Alan Phillips
          UK Kermit Distribution
          Lancaster University
          United Kingdom

[Ed. - Thanks Alan for your continuing service...]

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

Date: Mon 4 Jan 88 10:43:06-EST
From: Christine M Gianone <[e-mail]>
Subject: Texas University CDC Kermit No Longer Supported
Keywords: CDC Kermit

William P. Reeder of the Comutation Center has just informed us that the
University of Texas is no longer to support Kermit-170 for the NOS and
NOS/BE operating systems.  The Kermit sources which are prefixed KER:CDC*.*
are now unsupported.  He recommends that the KER:CD3*.* version of NOS
Kermit, by Steve Roseman at Lehigh University become the standard version
for our distribution tapes.

Thanks to Jim Knutson and the University of Texas for all the past Kermit
support.

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

Date: Fri 22 Jan 88 11:55:48-EST
From: Frank da Cruz <[e-mail]>
Subject: TRS-80 Model II Kermit Files?
Keywords: TRS-80 Model II Kermit

It has been pointed out to us that the file TR2KER.HEX in the Kermit
distribution is not really a hex file at all, but just garbage. Is anybody
using this version of Kermit on the TRS-80 Model II with TRSDOS?  If so,
could they send in a new, real .HEX file?  Thanks!  - Frank

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

Date: Tue, 29 Dec 87 13:35 EST
From: <[e-mail]> (Shawn Allin - Alcan KRDC Computer Services)
Subject: MSTIBM Tek-Mode Problem
Keywords: MS-DOS Kermit 2.29C, TEK Emulation

I've just briefly tried the new MSTIBM with Tek emulation on a Compaq 386
with EGA. I ran a PLOT 10 program I have and the emulator went into
Tektronix mode upon receipt of a ESC FF properly.  However, when I tried the
ALT = to toggle back to VT102 mode, it cleared the screen but stayed in Tek
mode.  I had to enter command mode and type SET TERMINAL VT102 to get it
back.  Is this a bug, or am I overlooking something?

     Regards,

     Shawn Allin
     Alcan International Ltd.,
     P.O. Box 8400,
     Kingston, Ont.,
     Canada  K7L 4Z4
     [phone]

     Bitnet: ACCESS@ALCANKTN

[Ed. - Yes, it's Alt-Minus, not Alt-Equals]

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

Date: 30 Dec 87 06:48:40 GMT
From: [e-mail] (Phil Windley)
Subject: Re: Observations on new Kermit 2.29C with partial Tektronix emulation
Keywords: MS-DOS Kermit 2.29C, TEK Emulation

In article <[e-mail]> [e-mail] () writes:
>
>    7. Seems to pick up the type of graphics adapter
>    automatically.  I haven't tested this on a Hercules though . . .
>

It works with Hercules as well.

>
>If anyone knows of any new features or how to set keys please post or
>email me.

Here's a few lines from my mskermit.ini file that sets some keys:

set key \338 \Kkp0
set key \335 \Kkp1
set key \336 \Kkp2
...

I found these out mainly by a combination of experimenting and
accident.  I'm still trying to figure out how to write scripts, etc.
Is there documentation for this beast somewhere?

Phil Windley
Robotics Research Lab
University of California, Davis

[Ed. - The new SET KEY feature is thoroughly documented in the new MS-Kermit
2.30 manual, KER:MSKERM.DOC.]

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

Date: Fri, 8 Jan 88 17:11:10 EST
From: [e-mail] (Atul Kacker)
Subject: Use of IBM PC Kermit to Control a Video Disk Player
Keywords: MS-DOS Kermit, Video Disk Player

We have a user here who is currently using a DEC VT102 terminal for a
special application.  He uses the terminal to access a mainframe database,
which is a database of photographs in the George Eastman House archives.  He
also has a video disk player connected to the printer port at the back of
the VT102 terminal.  If he selects a record in the database that has a video
field, a picture of the photograph comes up on his video disk player.  The
mainframe program does this through the use of standard VT102 printer
control escape sequences.

He would now like to do this on his IBM PC using Kermit which supports the
same printer control sequences.  What I would like to know is how to set up
his system to do this.  I understand that the printer port on a VT102
terminal is a serial port.  What does Kermit use - the parallel or the
serial port when it sends the printer control sequences ?  Can he use COM2
to connect his video disk player to and use the DOS MODE command to redirect
the output of LPT1 ?  Any suggestions welcome. Thanks Atul Kacker
..!rochester!ur-tut!akk2

[Ed. - Version 2.30 of MS-DOS Kermit, just announced, supports all the
printer control sequences that the VT102 does, so it should work the same
way, on either a serial or parallel port.]

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

Date: Fri, 08 Jan 88 22:05:17 -0800
From: Alastair Milne <[e-mail]>
Subject: Retaining Past Screens
Keywords: MS-DOS Kermit 2.29C

   I am using Kermit 2.29C on IBM's and compatibles, and among all the useful
   features (including the excellent terminal emulation), there is one that
   sometimes drives me up a wall: the saving of past screens.  Every so often
   I will aim for the RETURN key, miss it, and hit HOME instead.  Everything
   stops in its tracks while n pages of screen scroll past.  And END, of
   course, so that it will all scroll back to where it's supposed to be.

   Obviously, in certain circumstances, this could be enormously useful;
   however, in the general case, I find it simply gets in the way; and in
   fact, with a clone having a slower screen than an IBM, or disabled
   interrupts during refresh, it can become very annoying.  I see no way
   among the commands to turn it off (or perhaps reduce the number of screens
   that are saved).  Is there in fact a way; or is one available in the next
   version?

   Thanks very much,

   Alastair Milne

[Ed. - No, there's no way to turn it off.  You can reduce the number of
screens by changing a parameter somewhere and reassembling.]

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

Date: Sun, 10 Jan 88 20:59:48 PST
From: Ya'[e-mail]
Subject: MSKERMIT ver 2.29C tektronix 4010 won't overlay ALPHA and VECTOR
Keywords: MS-DOS Kermit 2.29C

Possible bug with MSKERMIT version 2.29C:

(Forwarded from: Ya'[e-mail], Dated: Sun, 10 Jan 88 20:56:38 PST)

I have been using MSKERMIT vers 2.29C and have encountered a bug (feature?)
in the Tektroniks 4010 emulation mode.  Specifically, alpha mode characters
will erase and NOT OVERLAY vector mode data.  This frequently causes plot
titles and labels to obliterate the graphed data.

ps:     I have an IBM-PC/xt clone with the CGA adaptor.

[Ed. - This seems to be the behavior on the CGA, but not the EGA...]

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

Date: Mon, 11 Jan 88 11:12:15 est
From: [e-mail]
Subject: Screen Scroll in MS-Windows
Keywords: MS-DOS Kermit, MS-WIndows

I have had problems making Kermit scroll up/down screens under MS-Windows
when in a window*.

Version 2.29b and 2.29c (21 DEC) have been tested with version 1.01 - 1.03
and 2.03 of MS-Windows.  You are only able scroll up one line.

Both Version 2.29b and 2.29c will scroll properly in a window under
Windows/386.

* In a window refers to setting up the PIF file so that Kermit does not
write directly to screen and does not "modify" a com port.

    Stephen Northcutt ([e-mail])

[Ed. - This is a restriction of the program, noted in the MSKERM.BWR
file.  However, you should still be able to scroll up by using the mouse on
the scroll bar.]

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

Date: Tue, 12 Jan 88 11:50 EST
From: <[e-mail]>
Subject: MS-KERMIT V2.29C DATED DEC 16/87 VT102 PRINTER PROBLEM
Keywords: MS-DOS Kermit

We have been testing the new version of MS-KERMIT (V2.29c dated Dec 16) and
found some problems with the VT102 printer function.  When we used the old
version of MS-KERMIT (v2.29b), we where able to use the TPRINT command on a
VM/CMS system to print out files directly to the local printer attached to
the PC.  In the new version the printer goes crazy and all sorts of control
characters appear to have been received by the printer.  Where there any
changes to the printer routines of the VT102 option?  Like I said, the
command on VM/CMS worked on the old version of Kermit, but not in the new.

[Ed. - The new version is supposed to act more like a real VT102 than the
previous version, and supports host-controlled transparent printing.  The
behavior and escape sequences are documented in the manual, MSKERM.DOC.]

The TEK4010 emulation of Kermit V2.29C (dated Dec 16) works great when is
used with the IBM 7171 connected to VM/CMS.  We tested it out using SAS
GRAPH to plot various graphics.  We even had SAS GRAPH send the
startup/termination escape sequence with no problems.  Our next tests will
be on the VAX/VMS systems, also running SAS.

Thanks for all the efforts that went into putting MS-KERMIT together, its a
great product.

Luis Strauch
York University
Toronto, Canada
BITNET: LUIS@YULIBRA

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

Date: Tue, 12 Jan 88 12:07 EST
From: "James A. Harvey" <[e-mail]>
Subject: Kermit 2.29C
Keywords: MS-DOS Kermit 2.30

Jim Griffin gave me a copy of this to test the other day.  It's fantastic!!!
I.U. recently got a site license for a bunch of the Precision Visuals
graphics products (DI-3000, DI-3000 XPM, PicSure Plus, Metafile system,
etc.) and I'm now using the 4010 emulator in Kermit with it as I install and
test stuff.  Sure is a hell of a lot easier than switching back and forth
between PC-PLOT and Kermit, which is what I was doing last month!
Thanks!!!!!

                                - Jim Harvey

PS: It runs rings around PC-PLOT (I have an EGA-compatible system which the
Kermit 4010 emulator seems to make full use of, whereas PC-PLOT didn't
appear to).  I also tried it on a Zenith 151, it worked fine on that too.
The PVI (Precision Visuals) drivers tend to make full use of all the
features of the device they are driving; so any emulator passing off as the
real thing with these drivers is probably quite a good one.

[Ed. - James Harvey is the one who originally added VT100 emulation to Kermit.]

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

Date: Thu, 14 Jan 88 10:47:03 EST
From: Jim Griffin <[e-mail]>
Subject: Tektronics 4010 Kermit
Keywords: Ms-DOS Kermit 2.30, Tektronix

    I've been testing the beta version of the MSKERMIT that performs
Tektronics 4010 emulation. So far the program is working just fine but, I
would like to voice a complaint about one of the MSKermit commands that had
its definition changed. I would like the CLEAR command to clear out the
keyboard redefinitions instead of clearing the serial port buffer.  The
reason I need to clear the Keyboard definitions is that I frequently switch
back and forth between an IBM CMS machine with a 7171 protocol converter and
a VAX8800 with VMS. For CMS I can define the function keys the way the 7171
wants them but, when I go over to the VAX I need to clear out the CMS
function key definitions and have them set back to a TRUE VT100 state. The
old CLEAR command did this for me. Perhaps an EMPTY command could be
implemented to clear the serial port buffer.

[Ed. - The new syntax is "SET KEY CLEAR".  Also see KER:MSIIBM.INI for an
example of setting Kermit up to work with a protocol converter.]

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

Date: Thu, 14 Jan 88 11:56:20 PST
From: [e-mail]
Subject: MS-KERMIT 2.29c Scroll-Back Problem with New Output
Keywords: MS-DOS Kermit

A messed-up screen results when new output is superimposed on old after
using the PgUp key to scroll back.  It's best to always press End key before
getting new output.

[Ed. - This behavior can be controlled by SET TERMINAL ROLL.]

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

Date: Thu, 14 Jan 88 22:12 EST
From: Timothy Stark <[e-mail]>
Subject: MS Kermit and C language.
KeywordsL MS-DOS Kermit 2.30

   Last night, I get mskermit stuffs from kermsrv library after you posted
anncouning information about Kermit 2.30. And I downloaded stuffs into my
IBM PC/AT. It worked fine for both VT100 and Tek4010!!! It is GREAT kermit
terminal! I would like that Tek4010 Graphics Terminal Emulation!  I read a
file called MSKERM.BWR about bugs and missing features. I found that
challaging information at end of MSKERM.BWR said that system-depend machine
language will be replace C-language portable modules in the future.  Who
will rewrite MSkermit 2.30 for C-Language??

[Ed. - Keep watching Info-Kermit... there may be an announcement some day.]

   I found a bug in Kermit 2.30 that SEND command initialized back to 80
packet-lenght after I did SET SEND PACKET 94! I tried to SET SEND PACKET 94
and checked STATUS. It said Sending packet lenght that is 94. I tried to
SEND <file> and Packet-Lenght: 78~79. I rechecked STATUS command.  It said
that 80. I believed that SEND forced to set packet 80 instead 94!  Please
fix it!

-- Tim Stark

[Ed. - It's not a bug.  SET SEND PACKET-LENGTH is used to override the
negotiated packet length, but only if the negotiated one was longer.  In
this case, it's shorter, so what the other Kermit asked for is what it got.
This is described in the manual.]

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

Date: Wed, 20 Jan 88 10:48:01 EST
From: J. P. Letellier <[e-mail]>
Subject: MS-Kermit 2.30 Problem
Keywords: MS-DOS Kermit 2.30

I am presently using a Zenith AT clone (ZWX-248-62) as a remote terminal to
a VAX-750 running Berkley 4.2.  I downloaded kermit 2.30 and started trying
it out.  I have run into the following problem:

I am running my terminal with "set term color 1,10,33,41".  When I page
things through "more" or "page", at the bottom of the screen page, the VAX
sends the sequence "esc[7m" to change the background for the "more XX%"
notification, and an "esc[m" to reset the terminal to the way it was.
Except, it resets the terminal to the non-intense mode and I can no longer
read anything on my screen.  I can program an "F-key" to put out the "set
term color 1" again, which resets my screen to readable, but that makes for
a two-stroke sequencing through "more", and will be a lot of trouble in
writeups which make an extensive use of background switches (because the
screen also erases when I do the "set term color 1").  jp

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

Date: 21 Jan 88 18:01:51 GMT
From: [e-mail] (Jim Greenlee)
Subject: Problems with Kermit 2.30
Keywords: MS-DOS Kermit 2.30

Well, I've been playing around with the new version of Kermit that was
recently announced (thanks, Tom :-) for about 2 days now, and I think I have
discovered a bug (or at least an anomaly) in the VT100 emulation.

First, a little background. I had been using version 2.29 (May, 1986) of
Kermit on my AT&T PC 6300 almost since it was released. One of the fea-
tures that I use the most is the ability to set FG/BG colors on a color
monitor - I normally use "set term color 1 10 33 46", which gives me a
high-lighted yellow FG on a light blue BG. I also almost always use the
VT102 emulation mode.

This works fine with version 2.29, particularly in the case where the host
sends a US (underline start) or UE (underline end) sequence to the terminal.
On a color monitor, this causes the FG/BG colors to be reversed.

So...I ftp-ed and unBOOed version 2.30 of Kermit, carefully read the manual
and help files, changed my MSKERMIT.INI files to match the new format, and
discovered that the US/UE sequences do not produce the same results on my
color monitor. What happens is that receipt of a US causes the video image
to be reversed, and the UE sequence causes it to be restored, but for some
reason the FG high-lighting is turned off. If I drop back into command mode
and do another "set term color", then everything works fine until I get
another US/UE sequence.

This problem does not manifest itself with the Heath/Zenith mode (which is
what I'm using in the interim). I checked the beta version (2.29C) that was
posted recently, and got the exact same results - US/UE causes high-lighting
to be turned off. Is this a genuine bug or did I just get a munged copy of
the software? Is their any way I can fix it short of getting all the sources
and ferreting out the problem myself? Has anybody else noticed this problem?

Any and all { help | comments | suggestions } are welcome.

                        Jim Greenlee
The Shadow...!{decvax,hplabs,ihnp4,linus,rutgers}!gatech!jkg

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

Date: Wed 20 Jan 88 22:01:51-EST
From: Jim Celoni S.J. <[e-mail]>
Subject: Kermit 2.30 lack of screen blanking solved
Keywords: Ms-DOS Kermit 2.30

Recall last month I reported that the December Kermit-MS 2.30 beta didn't
clear the screen for me on going to connect mode.  After your reply, I was
pretty sure Fansi-console was the culprit, whether in its quick scroll mode
(/q1, using extra graphics memory on cga or ega) or not (/q0).  Official
2.30 behaves the same way: cycling through emulation modes cleared things, I
think, but explicit Alt-key clearing didn't.

Imagine, then, my happiness when I discovered that everything works right
when I do a MODE CO80 just before invoking kermit.  Fansi-console is a fine
program with lots of users, and the mode tip might help in other situations
too.  Maybe a word in the .BWR file...

P.S.  I have an IBM 256K EGA and run IBM DOS 3.3 on an Antex AT clone.

> Date: Wed, 20 Jan 88 22:27 MDT
> From: Joe Doupnik <[e-mail]>
> Subject: RE: Kermit 2.30 lack of screen blanking solved

>         The indications seem to be that Fansi-console reports the wrong
> screen size information to callers such as Kermit. The ALT = reset clears
> the known screen size, using ega information stored in the Bios, but
> going through graphics and back to text terminal types does a real live
> mode set (same as MODE xxxx). Mode setting gets back standard screen
> dimensions stored in Command.com and puts everything in proper places both
> in the display board and in the Bios. Apparently, Fansi-console keeps some
> of this to itself so Kermit can't find those parts. Too many chiefs. There
> is not a thing Kermit can do about such a situation, but you might want to
> bring it to the attention of Hersey for their consideration.

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

Date: Fri, 22 Jan 88 11:47 EST
From: <[e-mail]>
Subject: RAINBOW MS-DOS KERMIT 2.30
Keywords: MS-DOS Rainbow Kermit 2.30

Hopefully someone can answer my question.  I have just finished putting
together MS-DOS Kermit 2.30 for the Rainbow 100.  We use Kermit to connect
to a DEC PDP-11/70 system.  On our system, we have a program to print
certain files via the printer port.  This program simply turns the printer
port on, reads a line, writes an line, and when finished, turns the printer
port off with the proper escape sequences.  This works perfect in terminal
mode, but when using Kermit, it does not work.  The supplement for the
MS-DOS Users Guide especially for the extended DEC Rainbow version of
MS-Kermit says that complete support for all printer port functions has been
included in this version of the emulator.  Should this work?  Can I not from
BASIC on a host system turn on the printer port, print a file, and turn the
printer port back off while running Kermit?

I would appreciate any help on this subject!

Thanks,
Terry Lewis
University of Tennessee at Martin
Martin, Tennessee  38238
TLEWIS@UTKVX1  (BITNET)

[Ed. - You should be able to do this, but there's always the possibility
of a bug, either in Kermit, or in its interaction with the Rainbow's VT102
firmware.  Users are invited to peek at the source code and send in fixes
if necessary.]

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

Date: Fri, 15 Jan 88 13:32 CDT
From: Raisin in the mid-dle <[e-mail]>
Subject: Generic MS-DOS V2.3 Problem
Keywords: MS-DOS Kermit 2.30

I downloaded the generic MS-DOS kermit V2.3 to try out on my TI-PC (IBM-
compatible-sort-of).  It runs, but whenever I do a 'SET BAUD xxx' command it
complains "Command not implemented".  What gives?  Did I have a download
problem or are others experiences this problem?

Regards,
Stewart French

[Ed. - Setting the baud rate is a system-dependent function, and therefore
is not implemented in Generic DOS Kermit.]

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

Date: Mon, 18 Jan 88 17:32 N
From: Eberhard Lisse, Abt Verbrennungschirurgie, RWTH Aachen <IUS@DACTH51>
Subject: MS-KERMIT 2.30
Keywords: MS-DOS Kermit 2.30

MS-Kermit has always been among my ten favourite programs and has now moved
up to number one, even beating Don Kneller's NDmake 4.31 for which I now
seriously consider paying the $ 35. :-)

I would like to move its version be renamed to 3.0 as it looks almost a
complete rewrite to me and includes lots of nice new features, not the least
being the Tektronix emulation for which lots of users have longed since some
time.

[Ed. - A sensible idea, but unfortunately, it's been publicized at version
2.30 too far, too wide, and too long.]

I would also like to thank Joe publicly, via INFO-KERMIT, for his time and
effort to produce this marvelous piece of code which I think is better than
most commercial products. And I have tried some ...

regards, el

Eberhard W. Lisse
Burn Unit and Department of Plastic and Reconstructive Surgery
Technical University Aachen
West Germany

BITNET:         ius@dacth51                             preferred
ARPA:           [e-mail]
UUCP:           psuvax1!dacth51.BITNET!ius              from overseas
                unido!dacth51.BITNET!ius                within Europe
                {{uunet!}unido!rmi!}lisse!el            Real Soon Now

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

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


-------
26-Jan-88 17:30:51-EST,24743;000000000000
Mail-From: SY.CHRISTINE created at 26-Jan-88 17:30:06
Date: Tue 26 Jan 88 17:30:05-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #3
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 26 Jan 1988       Volume 7 : Number 3

Departments:

  ANNOUNCEMENTS -
        Announcing C-Kermit 4E(068)
        Updates for CDC Cyber NOS Kermit (CD3KER)
        Announcing DECSYSTEM-20 Kermit 4.2(262)
        German Translation of MSKERM.HLP for V2.30

  VM/CMS KERMIT -
        Installing CMS Kermit 4.0
        Kermit on 9370 using ASCII Subsystem
        CMS Kermit 4.0 Packet Size Anomaly

  UNIX KERMIT -
        Re: Announcing C-Kermit 4E(068)
        Data General C-Kermit 4E(067)
        Kermit on BSD 4.2
        Re: Kermit on BSD 4.2
        C-Kermit 4D(061) and Microport Unix

  MISCELLANY -
        UUCP Lock Files
        VAX -> NASA VAX Problem
        Secure Kermit File Server for VMS?
        Kermit for the Visual 1050?
        Commodore 64 Kermit and GNU Emacs?

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

Date: Sun 24 Jan 88 20:15:25-EST
From: Frank da Cruz <[e-mail]>
Subject: Announcing C-Kermit 4E(068)
Keywords: C-Kermit 4E(068), Unix Kermit

This is to announce another minor release, but this time a "real" release,
of C-Kermit for Unix, VAX/VMS, Data General AOS, the Commodore Amiga, the
Apple Macintosh, etc.  The changes were minor, and only appear in the Unix
versions.  They include:

 . Suspendibility via Ctrl-Z on systems with job control (Bob Brown).
 . Explicit support for SCO Xenix in the Makefile (from D.W. Bettinger).
 . Explicit support for the AT&T 7300, including the ability to dial its
   internal modem (from R.E. Hill, untested).
 . Improved response of the C-Kermit server to 'remote cwd' commands.
 . Miscellaneous small fixes and cleanups.

The major change is that since this is now considered a real release, the
files have been named from XK*.* back to CK*.*, and the XK*.* files are
gone, resulting in a savings of about 2 megabytes in our Kermit distribution
area and on our tapes.

All files' names changed, but the only files whose contents changed are:

 ckuker.upd - Update history
 ckuker.bwr - Beware file
 ckcfns.c   - Functions (better reporting of current directory by server)
 ckcmai.c   - Main program (new version number)
 ckcpro.c   - Protocol module (wart output)
 ckudia.c   - Dial module (ATT 7300 support added)
 ckuusr.c   - New calls
 ckutio.c   - Support for ATT 7300, job control fixes
 ckufio.c   - New zgtdir() function to return current directory
 ckdfio.c   - Ditto (but dummy)
 ckifio.c   - Ditto (but dummy)
 ckmfio.c   - Ditto (but dummy)
 ckvfio.c   - Ditto (but dummy)
 ckwart.c   - Syntax error fixed

These files are in K2: on CU20B.COLUMBIA.EDU, e.g. K2:CKCFNS.C, available
via anonymous FTP.  They are also available on BITNET from KERMSRV@CUVMA as
CKCFNS C, etc.  For information about using KERMSRV to get Kermit files,
send a message to KERMSRV@CUVMA with the message text saying "help".

Please report any problems with this release to Info-Kermit@CU20B.

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

Date: Wed, 30 Sep 87  14:15:20 EDT
From: [e-mail] (Olaf Pors  804-924-0633)
Subject: Updates for CDC Cyber NOS Kermit (CD3KER)
Keywords: CDC Cyber Kermit

The files CD3KER.INS and CD3KER.MOD contain feature addition to CDC NOS
Kermit (the CD3 Kermit).  CD3KER.INS is a replacement for that file on the
Kermit distribution.  CD3KER.MOD is the only source code you need to upgrade
CD3 Kermit from version 3.2 to the one I created (3.3); this file should be
added to the rest of the CD3KER files on the distribution, so it can be
applied using the CDC UPDATE utility.  UPDATE works with a base file
(usually quite large) and applies modifications (usually small) to create a
file for compilation.  This is the way that CDC maintains their system
software, and I think CD3 Kermit should be handled this way too; i.e., have
a large, unchanging base file and a small modification on the distribution.
New changes would be added to the modification file until it gets too
unwieldy, at which time a new base file would be created.  The CD3KER.INS
file I've supplied assumes the (possible) existence of such a modification
file.  See also the comments in CD3KER.INS.  All the documentation needed
concerning my enhancements (upward compatible) is at the beginning of the
CD3KER.MOD file.

[Ed. - Thanks, Olaf!  And apologies for taking so long to bring your
contribution to public light.  Olaf's changes include support for 8/12 ASCII
binary files, optional kinds of EOF conversion, and support for CDCNET.
Unfortunately, in August 1987 (several months before you submitted this
one), Steve Roseman of Lehigh University ([e-mail]) submitted
another, different, version 3.3 of this program, announced in Info-Kermit V6
#17.  Your files have been put in KER:CD3KER.IN2 (so as not to interfere
with Steve's CD3KER.INS), and CD3KER.MOD.  Meanwhile, let's hope someone
will be able to reconcile the two versions and maybe produce a version 3.4?]

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

Date: Tue 26 Jan 88 16:15:25-EST
From: Frank da Cruz <[e-mail]>
Subject: Announcing DECSYSTEM-20 Kermit 4.2(262)
Keywords: DECSYSTEM-20 Kermit

This release corrects problems introduced by the previous release, announced
a few digests ago.  Now, not only does DEC-20 Kermit not prevent you from
issuing GET, REMOTE, BYE, and FINISH commands when in remote mode (e.g. to a
PC Kermit server), but now they also work!  In addition, it is now possible
to execute CWD and REMOTE CWD from a TAKE file (it wasn't before).  The new
version is in KER:K20MIT.MAC and KER:K20MIT.DOC on CU20B, and in K20MIT MAC
and K20MIT HLP on CUVMA.  This may be the final release of DEC-20 Kermit;
the main goal is to get the existing bugs out before our last DEC-20 sails
smoothly into eternity.

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

Date: 01/25 04:02:13
From: Gisbert W. Selke <[e-mail]>
Subject: German Translation of MSKERM.HLP for V2.30
Keywords: MS-DOS Kermit, German Manual

Enclosed is MSGERM.HLP, a German version of MSKERM.HLP.

[Ed. - Thanks, Gisbert!  It's been put in the Kermit Distribution as
MSKGER.HLP, the name change being necessary because the MSG prefix is
already used for something else.]

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

Date: Tue, 29 Dec 87 10:19:17 EDT
From: Terrence Ford <[e-mail]>
Subject: Installing CMS Kermit 4.0
Keywords: IKC Kermit, CMS Kermit 4.0

Two very minor points that may save people some time installing 4.0:

   1) As received from KERMSRV@CUVMA, the following files all proved to have
      a last record beginning with X'00' (which will cause the assembler to
      complain with IFO053 OP CODE NOT FOUND ON FIRST OR ONLY CARD)

                       IKCUTL.ASM
                       IK0CMD.ASM
                       IK0COM.ASM
                       IK0DEF.ASM
                       IK0DOC.ASM
                       IK0MAC.ASM
                       IK0MAI.ASM

   2) In step 2, the HELPCONV command will create IKCKER $HLP A, not IKCKER
      $HLPCMS A as documented.

As I said, very minor.

Terrence Ford

[Ed. - Thanks, Terrence.  Problem (1) was an artifact of our file transfer
process (FTP, not Kermit!), and has been rectified -- the CUVMA copies no
longer have nulls at the end.]

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

Date: Mon, 21 Dec 87 11:03:33 PST
From: [e-mail] (James V. Bys)
Subject: Kermit on 9370 using ASCII Subsystem
Keywords: CMS Kermit

We have been running CMS Kermit 3.1 on an IBM 4381 with a 7171 interface
successfully.  We recently received an IBM 9375 with an ASCII Subsystem.
This IBM supported subsystem acts similarly to the 7171.

Kermit compiles and starts successfully on the 9375.  When Kermit is put in
server mode, the FIRST file transfer occurs successfully.  After this
transfer, the terminal attached to the ASCII Subsystem is completely hung.
None of the local reset characters have any effect.  Needless to say, no
further communication by the local Kermit with the 9375 occurs.

The CMS installation instructions state:

"When CMS Kermit is to be used with a 7171, make sure the 7171 is set
up with its 'keyboard lock delay' parameter set to 0.  Otherwise, the
'terminal' will hang whenever CMS Kermit clears the screen..."

This symptom sounds similar to the one mentioned above using the ASCII
Subsystem.  There, however, is no mention that we could find of a "keyboard
lock delay" parameter in manual SA33-1564 "ASCII Subsystem Customization and
Programmer's Guide".

Could anyone that has successfully installed Kermit through an ASCII
Subsystem please comment?

James V. Bys
California Institute of Technology

Internet address: [e-mail]
Bitnet address:   JIMBYS@CITIAGO

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

Date: Sat, 23 Jan 1988 14:22:08 EST
From: "James H. Coombs" <[e-mail]>
Subject: CMS Kermit 4.0 Packet Size Anomaly
Keywords: CMS Kermit

Thanks for the new version of CMS Kermit 4.0.

I have found many improvements and only one oddity (or two?).

1) The documentation (IKCKER DOC) says:

   "Maximum packet size:               1920"

   But when I try to set the receive packet size to 1920, the executable
   rejects the command and issues the message:

   "Operand must be <1914"

   The same problem occurs when I try to set the send packet size.  In
   addition, when I specify something like '1900', I am told that the
   send packet size is limited to the range '20-94'.


2) This may be a local problem, but I get the following message on startup:

   "Handshake is XON -- not needed"

   CMS Version is "Rel 3 Lev 302.2".

Thanks.  --Jim

Dr. James H. Coombs
Software Engineer, Research
Institute for Research in Information and Scholarship (IRIS)
Brown University
[e-mail]
Acknowledge-To: <JAZBO@BROWNVM>

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

Date: Mon, 25 Jan 88 23:01:49 PST
From: [e-mail] (Bob Larson)
Subject: Re: Announcing C-Kermit 4E(068)
Keywords: C-Kermit 4E(068)

In article <[e-mail]> [e-mail] (Paul Vixie Esq) writes:
>In article <[e-mail]> [e-mail] (Frank da Cruz)
>writes:
>>This is to announce another minor release, but this time a "real" release,
>>of C-Kermit for Unix, VAX/VMS, Data General AOS, the Commodore Amiga,
>>the Apple Macintosh, etc.  The changes were minor, and only appear in the
>>Unix versions. [...]
                                 ^^^^^^^^^^^^^^^^^^
>I'm curious, though, as to whether this release includes the long-discussed
>"windowing kermit protocol" which would apparently allow several ACKs to be
>outstanding at one time, thus improving performance on half-duplex and X.25
>connections.

Unfortunatly, I'm rather certain full duplex windows havn't made it into
C-kermit yet.  The only version I know of are for Primos, a semi-functional
(and unmaintainable) one for ms-dos, and commercial ms-dos packages (such as
procomm).  There may of course be others I am not aware of.

The later C-kermits do include long packet support.  This is what is desired
for half-duplex, but is not as good for x.25 or long delay hookups.  I'm
curious as to when, if ever, windows will make it into c-kermit.

Bob Larson      Arpa: [e-mail]      [e-mail]
Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson
Prime mailing list:     [e-mail]
                        oberon!fns1!info-prime-request

[Ed. - Sliding windows are not in C-Kermit 4E(068).  This is high on the list
of things to add to C-Kermit, as are Attribute packets, and support for MS-DOS.
These will appear in future releases, which in turn will appear as time
permits.]

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

Date: Sat, 26 Dec 87 20:02:38 CST
From: [e-mail] (Samudra E. Haque)
Subject: Data General C-Kermit 4E(067)
Keywords: C-Kermit 4E(067)

In your 4E(067) version I believe you have conditional compilation for Data
General machines (== ifdef datageneral), assuming that people who run these
machines want to compile a version for themselves. Well, there is a problem
with that. There are basically two major types of software on DG machines:
AOS/VS and DG/UX, i.e. native AOS with MV/UX subshells and native unix for
the Data General. Unfortunately, on both C compilers the symbol
"datageneral" is defined!  This is of course a problem since both unixes are
*not* identical in file structure and programs.

So: Just using plain "#ifdef datageneral" will tend to break people who try
to compile C-Kermit on DGUX's version.  What I might suggest use the
construct "#ifdef datageneral #ifndef DGUX" etc..

Else: I'm just about finished with 4E(067) for DG/UX.. this version with
proper #ifdef DGUXs. My version of ckuusr.c seems to be broken though,
(symbol line length attribute conflict ? )..and I've been wanting to FTP a
new version over. ... ...

Thanks for your attention.

Samudra E. Haque
Computer Science Systems Group
Computer Science Department
University of Minnesota, Minneapolis, MN 55455.

[Ed. - This message arrived too late for the new release.  But you're more
than welcome to fix the program up for Data General operation and send the
changes back to Columbia, preferably based on the just-announced 4E(068)
release.]

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

Date: 28 Dec 87 00:42:59 GMT
From: [e-mail] (Michael Galassi)
Subject: Kermit on BSD 4.2
Keywords: C-Kermit

I recently wrote a program to deal with idle users on my system and have a
loose end to tie up before I can send it on to r$ for posting to
comp.sources.unix.

The problem is with Kermit.  When users are kermiting files back and forth
stat(2) on their terminal shows that the device has not been accessed since
the file transfer started.  I know perfectly well that data is going across
the link as the lights on the modem blink in the usual kermit fashion, but
looking at the st_mtime, st_atime, and st_ctime entries in the structure
returned by stat(2) shows no change during the course of the file transfer.
I know this is not a problem with my invocation of the stat system call as
who(1) also reports the terminal as idle.  HELP!!!  How is kermit doing its
i/o?

I am running C-Kermit version 4C, when it starts up I get the message:

C-Kermit, 4C(057) 31 Jul 85, 4.2 BSD

If anyone knows exactly how Kermit does it's i/o could you please
send me mail about this?  Also, what other programs have you found that play
the same tricks with i/o that I should look out for?

        -michael

[Ed. - See message below.  C-Kermit opens /dev/tty in rawmode and does
unbuffered read()'s and write()'s to it.]

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

Date: 28 Dec 87 17:37:05 GMT
From: [e-mail] (Eric Gisin)
Subject: Re: Kermit on BSD 4.2
Keywords: C-Kermit

C-Kermit probably opens /dev/tty instead of using stdin and stdout, so the
/dev/tty?? inode times are not updated.  The reason for doing this so one
can send stdin or receive stdout as a file.

One fix is to modify kermit to use stderr instead of /dev/tty.

[Ed. - C-Kermit does indeed use /dev/tty.]

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

Date: Sat, 23 Jan 88 20:39:54 EST
From: Brodsky <[e-mail]>
Subject: C-Kermit 4D(061) and Microport Unix
Keywords: C-Kermit 4D(061)

I'm having difficulties using C-Kermit on a tty port with getty.  Even
though Microport says you can get away with this by running getty on
/dev/ttyM? I have had numerous occasions where the C-Kermit process hangs
while attempting to aquire the port. The process will will linger without
responding to any kill (even kill -9), LCK* file removal, or init state
change.  The only way to get the tty port back is to reboot.  There are no
problems running C-Kermit as long as getty doesn't have the port, however.

This bug is not a consistent one. There are times when running C-Kermit and
getty together works fine and other times when it does not. One thing that
tends to cause the problem to occur more often is when getty has a multiple
speed setting (such as 1200R where it will switch between 300 and 1200 bps).
I suspect some sort of port access confusion in ttyM?, but I haven't yet the
skills to track this beast down. Can anyone help?

Thanks for all the wonderful work Froggers!

                                  Jake Brodsky

"What nature doesn't do to us,
 Is done by our fellow man."     --Tom Lehrer

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

Date: Sat, 5 Dec 87 09:27:35 CST
From: convex!smu![e-mail] (Laurence Leff)
Subject: UUCP Lock Files
Keywords: UUCP, Lock Files

Our version of kermit does not access the lock files correctly so as to
avoid interfering with uucp under 4.3BSD.

The lock file mechanism changed from 4.2BSD to 4.3BSD.  Yet the version of
Kermit that came with the 4.3BSD distribution from Mt. Xinu is using the old
style uucp lockng mechanism appropriate for 4.2BSD systems.

Has anyone fixed this and can send us a patch?

       Laurence Leff
       Coordinator, Computer Science Department Computer Facilities Management
                    Team
       convex!smu!leff leff%smu@csnet-relay  E1AR0002 at SMUVM1 (BITNET)

[Ed. - Let's hear it once again for UUCP lock files, probably the silliest
single feature of Unix.  Why access to tty devices should be shared rather than
exclusive by default is a profound mystery.  So long as every Unix system in
the world (and every new release of each version) must have a different idea of
where the UUCP lock file should be, what it should be called, what should be in
it, who its owner should be, etc etc, communication programs, like Kermit, that
attempt to work on many different Unix versions will remain in a perpetual
state of confusion (end of tirade).  The past few releases of C-Kermit have had
code to deal with 4.3BSD lock files, but it's not activated by default.  Look
in the module ckutio.c for "NEWUUCP".]

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

Date: Thu, 21 Jan 88 16:38:24 EST
From: "Robert E. Zaret" <[e-mail]>
Subject: VAX -> NASA VAX Problem
Keywords: VAX/VMS Kermit

Someone just came in with a problem transferring files from his lab's VAX to
a VAX run by NASA.  Both seem to be VAX 11/750s running Kermit-32.  He calls
an 800 number to connect through Telenet using 1200 bps, 7 databits, and
even parity.  He has no problem using the NASA VAX.  However, when he tries
to transfer a FORTRAN source file, he sees no error messages, but cannot
find the file at the other end.  More specifically: he invokes Kermit on the
NASA end and puts it in server mode; then he uses ^]c to escape back to his
local kermit and tells it to send the file; after 3-5 minutes, he gets a new
Kermit-32 prompt.

I am surprised about the Telenet connection: the 800 number seems curious; I
was unable to use Telenet with 7e (I had to use 8n to connect to Telenet and
let it handle, correctly, the computer at the other end that insists on 7e);
and he never sees the usual Telenet prompts.  He is certain he uses Telenet,
not TELNET.

We would certainly appreciate any hints.  Thanks.

[Ed. - The Telenet variations are not totally inexplicable.
A Telenet host can configure the user's Telenet pad as to parity, etc., using
private X.28 (or is it X.29) parameters.  Thus the behavior of your PAD can
depend on what host you're connecting to.  Meanwhile, can anybody who has
used Kermit in this environment help?]

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

Date: 14 Jan 88 21:19:51 GMT
From: Kral <amdahl!drivax![e-mail]>
Subject: Secure Kermit File Server for VMS?
Keywords: VAX/VMS Kermit

We have a need for a "secure" file server on our VMS machines.  We want
something that would enable our customers to call up, log in, and transmit
or receive files in their home directory.  They should be able to do
directory listings within their own tree as well.  However, they should
not be able to spawn off sub-processes, read or write files outside of their
home directory, etc.  Ideally, the wouldn't be able to have any kind of
access, including directory listings, of anything outside of their home
directory.

Our problem is this:  our machine security is pretty relaxed, leaving
any security up to limiting login access to "trusted" users.  As a result, the
users have gotten used to leaving world read (and sometimes write!) permission
on their home directories.  Most of the users on the machine we wish to
implement this on are Operating System Engineers, so we figured it would be
kind of costly to impose any reasonable security on the system.  We also
figured that permissions probably wouldn't be kept long if we were to require
them to change them.

Now we have customers that want to do file transfer with us, and we need
their accounts secure from each other, as well as our own source code
directories being secure from them.

Right now I am attempting to modify kermit-32 to take out any remote
commands.  I only have the macro sources to work with.  ANy suggestions
are appreciated.

kral                                            [THERE ARE NO ORDINARY MOMENTS]
408/647-6112                                    ...{ism780|amdahl}!drivax!braun

[Ed. - C-Kermit might be easier to work with, but it is not yet truly at
home in the VMS environment.  But it's not clear that changing Kermit is the
answer to the problem.  If they can log in, they can get at other people's
files.  Even if you have a "secure" Kermit on the system, they can use it
to transfer an "insecure" one for their own use.]

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

Date: Wed, 30 Dec 87 19:31:38 PST
From: Michael Marria <[e-mail]>
Subject: Kermit for the Visual 1050?
Keywords: Visual 1050 Kermit

I am looking for further information to get this Visual 1050 transfering
binaries. It has a usable ascii modem and trap system, so I can get .HEX files
to start up.

This thing is somewhat Kapro II and DEC Rainbo compatible.  I down
loaded the HEX file for a Kaypro which runs until I attempt connection which
crashes the machine.

Any help on this will be much appreciated.

Also, if this helps, it runs CP/M3, though I assume the crash problems
relate to the port loction being different then that of a Kaypro.

Anybody out there have one of these things?

                                Thanks much,
                                Michael

[Ed. - If it runs CP/M 3.0, then you should not be using Kaypro Kermit,
you should be using CP/M 3.0 Kermit, which should run as-is on any CP/M
3.0 system.  The system-dependent hex file for this is in KER:CP4CP3.HEX,
which is combined with KER:CP4KER.HEX to produce the complete running
program, according to the instructions in the manual.]

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

Date: 12 Jan 88 16:42:08 GMT
From: [e-mail] (Pete Hsi )
Subject: Commodore 64 Kermit and GNU Emacs?
Keywords: Commodore 64

While using GNU Emacs with C64 Kermit at 1200 baud, I noticed when scrolling
UP ONLY, the screen would get garbled. (Probally overflowing the input
buffer? I haven't notice this happening at 300 baud (300 baud?!? ARGH!))

Anybody out there know the solution to this? I have FLOW-CONTROL ON in C64
Kermit.  I do a re-draw screen command (C-l; no biggie) but I would like a
more elegant (sp?) solution such as resetting TERM-CAP, etc.

More info:
    Host: Ultrix (Dec's Unix) running GNU Emacs 18.49.1 and
          VMS running the ported version of GNU Emacs.
    Local: Commodore 64 running Kermit 2.0 (VT100 emulation), 1200 modem.

If possible, send me mail. Thanks in advance.

  Pete

Univs. of Maryland Baltimore County  (UMBC == "U Must Be Crazee" :-)
    ARPA: [e-mail]   or   [e-mail]
    Bitnet: pete@umbc
"Mis-spellings are the fault of my computer"

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

End of Info-Kermit Digest
*************************
-------
29-Jan-88 19:38:05-EST,21983;000000000000
Mail-From: SY.FDC created at 29-Jan-88 19:37:26
Date: Fri 29 Jan 88 19:37:26-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V7 #4
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 29 Jan 1988       Volume 7 : Number 4

Departments:

  ANNOUNCEMENTS -
        Announcing C-Kermit 4E(070) (Sorry!)
        New Version of Honeywell CP-6 Kermit
        New PDP-11 Kermit Documentation
        CU20B Nears Retirement
        SCANCHEK 4.0 Available

  MS-DOS Kermit -
        MS-Kermit 2.30 Rollback Disable
        Kermit 2.30 for GRiD
        Rainbow MS-DOS Kermit 2.30
        Kermit 2.30 and the Tandy 1000
    IBM PC Convertible Diskettes?

  C-KERMIT -
        C-Kermit Timeout Problem Fix
        Compiling Kermit 4E (068) on BSD 4.3
        A Better Way to Detect Background Execution
        C-Kermit 4E(068) on 4.3 BSD
        Small Problem in ckuusr.c for System V
        Problem with CKUUSR.C on VMS

  MISCELLANY -
        Kermit Support for IBM 3708 Front Ends?
        Re: TRS-80 Model II Kermit HEX File

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

Date: Fri 29 Jan 88 21:25:40-EST
From: Frank da Cruz <[e-mail]>
Subject: Announcing C-Kermit 4E(070) (Sorry!)
Keywords: C-Kermit 4E(070), UNIX Kermit

This is to announce, directly on the heels of C-Kermit 4E(068), another new
version, 4E(070).  I apologize for this.  Edit 68 had two fatal flaws,
which are described in messages below, but briefly:

 . getcwd() not defined in BSD UNIX, breaking BSD versions.
 . Unconditional reference to SIGSTOP, breaking non-BSD versions.

A couple other small fixes were also applied.  One is for the error message
C-Kermit returns when it times out (thanks to Paul Placeway).  The other
finally allows Kermit to determine whether it is running in the background, so
that the "disappearing prompt" problem is fixed...  But only for Berkeley and
Ultrix versions.  See messages below.

Sorry for the inconvenience.  If you want to replace the files that were
"damaged" in the 068 release, they are ckutio.c, ckufio.c, ckuusr.c,
ckcfn2.c, ckucmd.c, and ckcmai.c.

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

Date: January 25, 1988
From: [e-mail]
Subject: New Version of Honeywell CP-6 Kermit
Keywords: Honeywell CP-6, CP-6

I've sent you a tape containing version 1.00 of Kermit that runs on Honeywell
machines running the CP-6 (Control Program 6) operating system.

The following are changes/additions made to CP-6 KERMIT since the original
version (0.95) was sent to Columbia University in December, 1985.  Many
thanks to John Stewart of Carleton University, Tom Erskine of CRC, Mike
Iglesias of UC Irvine, and Mike Schmidt of Honeywell Bull, Canada, for their
help and supplied code.

  . Recognize ARC and LIB as default binary file extensions.
  . Optimize code that strips parity off incoming characters.
  . Block move of packet data to eliminate looping.
  . Eliminate redundant checksum calculation.
  . Handle repeat counts in file name packet.
  . Use FSFA on file that is being received or sent.
  . Added the ability to specify up to two EOR characters instead of
    assuming CR/LF.  This is useful, for instance, when communicating with
    some software on Apples.
  . Fixed bug that caused KERMIT to Memory Fault if a 'LIST' command
    was issued with no fid specified.
  . Enhanced the SHOW command to show some of the SETable things that
    it didn't before (EG, Binary EXtensions) as well as values for
    all the new commands.
  . The PARITY used for a transfer is now logged in the LOG file.
  . The activation character for received packets is now included in
    KERMIT "debug" files.
  . Fixed bug that prevented records with embedded CR's from being
    received correctly.
  . Relaxed syntactical constraints on some commands so optional blanks
    are permitted.
  . Added the SET FILE PREFIX, SET FILE SUBDIRECTORY CHAR and
    SET FILE SUBDIRECTORY { ON | OFF } commands.
  . Made it possible to interrupt multiple file transfers so you can
    quit the current file or the entire group of files.
  . Added the CG and STATION options to allow transfers through ComGroups.

I hope to have another version in about two months that will include long
packets and maybe sliding windows.

- Lee Hallin -
  Honeywell Bull
  5250 West Century Blvd
  Los Angeles, CA  90045
  [phone] x317

[Ed. - Many thanks, Lee!  The new files are in KER:HC6*.*, available via
anonymous FTP from CU20B.COLUMBIA.EDU, and HC6* * available from
KERMSRV at CUVMA via BITNET.]

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

Date: Thu 28 Jan 88 09:59:41-EST
From: Frank da Cruz <[e-mail]>
Subject: New PDP-11 Kermit Documentation
Keywords: PDP-11 Kermit, RSX, RSTS, RT11

Thanks to Dan Graham at NYU, we have a Scribe'd version of the PDP-11 Kermit
manual, suitable for typesetting and inclusion in the next edition of the
Kermit User Guide.  It's in KER:K11MIT.MSS and .DOC.

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

Date: Thu 28 Jan 88 09:59:41-EST
From: Frank da Cruz <[e-mail]>
Subject: CU20B Nears Retirement
Keywords: CU20B, Kermit Distribution, DEC-20, DUMPER Tapes

CU20B only has a few more months to live (exact date of retirement still to
be determined).  So, if anybody wants to order DEC-20 DUMPER or DEC-10 BACKUP
tapes, get those orders in soon!  Once CU20B is gone, we won't be able to
make these tapes any more.  Also, over the coming months, we'll be
converting our network operations to a VAX 8700 with Ultrix 2.0 (which is
like 4.2BSD Unix) system and an IBM mainframe running VM/CMS.  Watch
Info-Kermit for announcements about new procedures.

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

Date: Fri, 29 Jan 88 09:06:00 EST
From: Phil Benchoff <[e-mail]>
Subject: SCANCHEK 4.0 Available
Keywords: SET KEY, SCANCHEK, Key Definition

Finally.  Enclosed is a version of scanchek.c and scanchek.exe that
should match MS-Kermit 2.30.  The enhanced keyboard is supported,
and the program will indicate if a particular key is available on
the enhanced keyboard only.

[Ed. - Thanks, Phil!  For those who don't know, this is an interactive
program that can be used to find the key codes for all the keys on the
IBM PC keyboard, for use with Kermit's SET KEY command.  The files are
kept in KER:MSUCHK.C and KER:MSUCHK.BOO.]

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

Date: Sat, 23 Jan 88 13:54:57 EST
From: "James H. Coombs" <[e-mail]>
Subject: MSKermit 2.30 Rollback Disable
Keywords: MS-DOS Kermit 2.30

Alastair Milne writes:

    Every so often I will aim for the RETURN key, miss it, and hit HOME
    instead.  Everything stops in its tracks while n pages of screen
    scroll past.  And END, of course, so that it will all scroll back to
    where it's supposed to be.

    ...

    I see no way among the commands to turn it off (or perhaps reduce
    the number of screens that are saved).  Is there in fact a way; or
    is one available in the next version?

To disable the roll back, simply remap the relevant keys to other functions.

I have the opposite problem: mapping the roll back functions to new keys.
I tried with 2.29c with no success; I asked and either didn't get an
answer or it slipped by me.  Is there a way to remap this functionality?

Thanks.  --Jim

Dr. James H. Coombs
Software Engineer, Research
Institute for Research in Information and Scholarship (IRIS)
Brown University
[e-mail]
Acknowledge-To: <JAZBO@BROWNVM>

[Ed. - We received an avalanche of messages to this effect.  Apologies for
the thoughtless "Ed." comment.  Of course you can remap your Home key to not
invoke the \Khomscn verb.  You can move that function to some less easily
hit key, e.g. the commands "set key \327 {}" and "set key \1399 \Khomscn"
move it from Home to Ctrl-Home.  And to answer Jim's question, yes, you can
remap the rollback function to other keys, as in "set key \338 \Kupscn" to
move it to the Ins key.]

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

Date: Mon, 25 Jan 88 10:51:59 EST
From: Owen Adair <[e-mail]>
Subject: Kermit 2.30 for GRiD
Keywords: MS-DOS Kermit 2.30, GRiD Kermit

I downloaded 2.30 Kermit for the GRiD (.BOO format) and it tries to run, but
all I get is garbage then it crashes. Has anyone else tested the beast on a
GRiD model 1101? I currently use 2.29 and it works although not all the
features function.

Hope INFO-KERMIT can help!

-owen

Owen Adair, WD4FSU
Digital Signal Processing Lab, Georgia Tech, Atlanta GA 30332
Internet:       [e-mail]
uucp:   ...!{decvax,hplabs,ihnp4,linus,rutgers,seismo}!gatech!gt-eedsp!owen

[Ed. - This would require a Grid assembly-language programmer to look at
2.30 code and debug it.  Anybody?]

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

Date: Wed, 27 Jan 88 10:14 EST
From: <[e-mail]>
Subject: Rainbow MS-DOS Kermit 2.30
Keywords: MS-DOS Kermit 2.30, Rainbow Kermit

I recently put a question here regarding the printer port on the Rainbow.
I had a copy of the documentation for version 2.29.1 which does support
the printer port on a rainbow.  In MSKERM.DOC, it states that the printer
port is not supported and indeed I have found that it does not.  Are there
any plans for the offical distribution of Kermit to support the printer
port, i.e. being able to send the proper escape sequence to the printer port
to turn it on and off and to send files to it from a host such as a vax, or
any host?

Terry Lewis
University of Tennessee at Martin
Martin, Tennessee  38238

[Ed. - This would require an expert Rainbow programmer.  I don't know if
the Rainbow printer port is the same kind of device as the communications
port, with the same interrupt structure, etc.  If so, it might be easy.
Anyone?]

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

Date: Wed, 27 Jan 88 13:05:03 EST
From: "James R. McCoy (CCS-E)" <[e-mail]>
Subject: Kermit 2.30 and the Tandy 1000
Keywords: MS-DOS Kermit 2.30, Tandy Kermit

I have a strange problem with Kermit on a Tandy 1000 -- I have an older
Tandy 1000 with a Monochrome monitor and MSDOS 3.2.  Kermit seems to work
well enough until I hit the ^]c combination.  At that point the screen goes
blank and commands such as quit exit and push fail -- The only thing I can
seem to do is hit a "C" which puts me back to the host, or I can issue a
three-fingered salute and reboot.

In an effort to work around, I renamed mskermit.ini to *.old and reexecuted
-- This got me to the Kermit-MS> prompt.  Everything worked well until I hit
the "c" to connect.  The conection worked well and the session went well up
to the point where I did the ^]c combination and then I went right back to
square 1 --

Is there a special version specifically for the Tandy 1000?

Thanks for your assistance.

[Ed. - No, there's not a special version for the Tandy 1000.  It's allegedly
IBM compatible, but I have heard a lot of stories to the contrary, e.g. that
the Epsilon editor doesn't work at all, etc.  Anybody know the real story?]

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

Date: Thu 28 Jan 88 09:59:41-EST
From: Frank da Cruz <[e-mail]>
Subject: IBM PC Convertible Diskettes?
Keywords: IBM PC Convertible

Can anyone say for certain whether IBM PC Convertible 3.5" diskettes
are compatible with the 720K 3.5" diskettes that are used in the IBM PS/2
Model 30?

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

Date: 27 Jan 88 10:59 EST
From: [e-mail] (John Junod)
Subject: C-Kermit Timeout Problem Fix
Keywords: C-Kermit 4E(068)

The following code was developed about a year and a half ago by Mark A.
Thomas here at David Taylor Research Center to solve the time-out problem as
mentioned in the Info-Kermit Digest, V7 #3.

Hope this helps....

                   L. John Junod
                   junod@dtrc

/* The following fix was made in kermit to prevent the local machine from
timing out the terminal line.  The local machine uses the last access time
of /dev/ttyXX to check for an inactive terminal. Fancy kermit i/o doesn't
update /dev/ttyXX while packets are sent/received. Since a packet doesn't
update the access time of the tty line, The local machine thinks the line is
inactive and times it out after 5-10 minutes.  A call to the routine
check_time() is made in spack() and rpack(), and after 50 packets the tty
time is updated.  60 packets at 300 baud take about 5 minutes to send, so 50
packets is safe. */

/* included to fix local timeout problem */

#include "signal.h"
#include "sys/types.h"
#include "sys/timeb.h"
#define  NULL           0x0

/*  C H E C K _ T I M E  --  Fix timeout during packet sending and
                             receiving.  Since packets don't update the
                             tty access and modify times, we do it.      */

check_time()
   {
   static char *tty_name = (char *) NULL;
   static int i = 0;
   char *ttyname(),*calloc();
   struct timeb tbp;
   time_t t[2];
   if (tty_name == NULL)
      {
      tty_name = calloc(32,sizeof(char));
      strcpy(tty_name,ttyname(0));    /* allocate and get tty name of stdin */
      }
   i++;
   if (i > 50)
      {
      i = 0;
      ftime(&tbp);           /* get system time */
      t[0] = tbp.time;
      t[1] = tbp.time;
      utime(tty_name,t);     /* update tty time */
      }
   }

[Ed. - This would probably do the trick for BSD, but all the time stuff is
system dependent.  BSD, Sys V, Xenix, Venix, V7, etc, have different ways of
getting the time.  Meanwhile, this message has been added to the C-Kermit
"beware file".]

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

Date: Tue, 26 Jan 88 17:11:35 CST
From: David A Rasmussen <[e-mail]>
Subject: Compiling Kermit 4E (068) on BSD 4.3
Keywords: C-Kermit 4E(068)

make wermit "CFLAGS= -DBSD4 -DDEBUG -DTLOG"
cc -DBSD4 -DDEBUG -DTLOG -c ckuusr.c
"ckuusr.c", line 515: KERMRC undefined

I have not changed anything. I copied the new files described by FDC
on Jan 25.

Is this a general problem or perhaps something I did? (all I did was
copy the new files into my older distribution (066?) with the xk* files.

I think perhaps ckuusr.h also changed if I read your .bwr file right.
Of course this wasn't listed in your message to the net...

Anyhow, that could be it, or else I'm totally wrong :-)

[Ed. - I hope so!  KERMRC is defined in ckuusr.h as ".kermrc" for Unix
systems, and that's where ckuusr.c picks up the definition from.  None of
that changed, and it compiles fine on our Unix (Ultrix) systems.  Did
anybody else have any trouble with this?]

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

Date: Tue, 26 Jan 88 16:08:36 PST
From: unisoft![e-mail] (Jeff Bloomfield)
Subject: A Better Way to Detect Background Execution (in ckutio.c)
Keywords: C-Kermit 4E(068)

I currently use C-Kermit 4C(052) on a System V machine.  Perhaps this bug
has been corrected.

I usually invoke kermit with an sh script, which runs my dialing (phone
directory) program prior to invoking kermit.

There were various reasons why I had to use
    :
    trap "args" 1 2 3
    :
    kermit

Naturally, since this version of kermit tests the value that that signal(2)
returns in

    if ( signal( SIGINT, SIG_IGN ) ) {
        backgrd = 1 ;
        :
        :
    }
to detect background execution, kermit would fail with

    Fatal: Kermit command error in background execution.

as soon as I made a typo from the interactive prompt.  A solution that seems
to work (on both BSD and SYS V) is:

    if ( ! isatty(0) ) { /* Is stdin a tty? */
        signal( SIGINT, SIG_IGN ) ;
        backgrd = 1;
        :
        :
    }

Refer to:  ttyslot(3) - SYS V
           ttynam(3F) - BSD

QUESTION:  Has this problem been corrected?  Does this look like a more
           reasonable solution?  Appreciate a reply.

[Ed. - This is essentially what C-Kermit 4D and later do.  Except today's
release does it a different way for BSD, which turns out to work even
better: Kermit's process group is compared with the controlling terminal's
process group (got via an ioctl that's unavailable in Sys V), and if they
differ, then it's in the background (thanks to Fuat Baran of Columbia U for
suggesting this approach).  If anybody else has a definitive test for
background operation under Sys V, BSD, or other Unix systems, please send it
in.  I'm not sure the isatty(0) test is foolproof -- it certainly isn't in
BSD.  Nor is the signal(SIGINT,SIG_IGN) == SIG_IGN test.  Neither one of
these tends to work when the program is invoked with "&", whereas one works
and the other doesn't under various other conditions (e.g. "kermit < foo",
"foo | kermit", "kermit < foo &", etc etc).  Also something very strange
happens to the signals if you take a command file from Kermit, which invokes
a shell escape, e.g. "! date").  Enough...]

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

Date: Wed, 27 Jan 88 10:04:59 -0500
From: Dan Grim <[e-mail]>
Subject: C-Kermit 4E(068) on 4.3 BSD
Keywords: C-Kermit 4E(068)

When I say "make bsd" I end up with _getcwd undefined at link time!  There
seems to be a FORTRAN getcwd routine which might actually work 1but the
arguments don't necessary look compatible.  Has this version really been
built successfully under 4.3?

Dan

[Ed. - About 500 people complained about this one.  The assumption was that
getcwd() was a system call available on all versions of Unix.
Unfortunately, it's not.  On Berkeley, it's called getwd().  The reason I
didn't spot this is that I compiled the program on Ultrix, which is supposed
to be like 4.2BSD, little suspecting that it also includes a collection of
"System V Compatibility Functions".  Real BSD 4.2 or 4.3 doesn't have getcwd.

Unfortunately, the name can't simply be changed to getwd() in BSD versions,
because Kermit already has an internal function by that name, which is
defined and used in ckucmd.c.  So in order to use the system's getwd() call,
Kermit's function must have its name changed to gtword().  These changes are
in 4E(070) announced above.]

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

Date:     Fri, 29 Jan 88 13:51:31 EST
From:     Gary P Standorf <[e-mail]>
Subject:  Small Problem in ckuusr.c for System V

I tried compiling C-Kermit 4E(069) on a VAX 11/780 running System V Release
2 and it blew up in the ckuusr.c module.  It seems that an #ifdef is missing
around the stptrap() function.  Since this function is called in response to
a SIGTSTP signal, and that doesn't exist on SVR2, it appears that an #ifdef
SIGTSTP is needed so that the function is only included if SIGTSTP is
defined.

Thanks,

Gary Standorf
<[e-mail]>

[Ed. - Thanks for pointing this one out.  The reference to SIGSTOP in
function stptrap() in ckuusr.c should be surrounded by #ifdef SIGSTSP ...
#endif conditionals.]

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

Date: 28 Jan 88 09:48:00 GMT+109:13
From: <[e-mail]>
Subject: Problem with CKUUSR.C on VMS

The symbol SIGSTOP is not defined on our VMS system(4.5).  The only call to
this routine that I could find was enclosed with the an #ifdef SIGSTSP.  The
program compiled and ran fine on this system after this change was made to
CKUUSR.C.  Thanks for all your efforts, you have a great package.

ken poole
[e-mail]

[Ed. - Thanks, same deal as with Sys V, fixed in 4E(070).]

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

Date: Thu, 1988 Jan 28   17:46 EST
From: (John F. Chandler)   [e-mail]
Subject: Kermit Support for IBM 3708 Front Ends
Keywords: Kermit-370, 3708, IBM 3708, IBM Mainframe Kermit, TSO, MVS/TSO

The release of Kermit-370 4.0 for TSO is approaching, but there are a few
loose ends that need to be tied up.  One of these is the support for the
3708 front end, which has been copied as accurately as possible from the
version known as TS3KER in the Kermit distribution.  Since there has
apparently never been any feedback on TS3KER, I don't even know if this
particular 3708 approach has worked for anybody besides its originator.
Anybody who is running TSO through a 3708 and who would be willing to report
on either TS3KER or a preliminary version of TSO Kermit 4.0 should drop me a
line.  Thanks.
                                     John

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

Date: Sun, 24 Jan 88 17:59:02 EST
From: [e-mail]
Subject: Re: TRS-80 Model II Kermit HEX File
Keywords: TRS-80 Model II Kermit

RE: Info-Kermit Digest V7 #2:

RE TRS 80 MODEL II Kermit hex file: I believe that file is to be used with
Pickles and Trout CPM release 2.2.  I don't believe there was ever a version
done for TRSDOS.  I got the source files about maybe 4 years ago to try and
do such a conversion, but the volume of assembly code was just too much to
try and convert (plus the code at the time was in 8080 and I was versed at
the time in Z80, hence that conversion had to be done first).  Anyway,
TRSDOS was undergoing a slow death at the time, and I just gave up on the
conversion.  If there ever was a TRSDOS version of kermit, I too would be
interested in hearing about it.

[Ed. - There is indeed a native TRSDOS version for the Model II.  It's in
KER:TR2KER.*, announced in Info-Kermit V6 #8, 26 March 1987.]

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

End of Info-Kermit Digest
*************************
-------
 4-Feb-88 16:45:51-EST,22354;000000000000
Mail-From: SY.CHRISTINE created at  4-Feb-88 16:44:46
Date: Thu 4 Feb 88 16:44:46-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #5
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 4 Feb 1988       Volume 7 : Number 5

Departments:

  ANNOUNCEMENTS -
        New Documentation for Old CIE-680 Kermit

  MS-DOS KERMIT -
        MS-Kermit Under OS/2
        Thanks for rollback help!
        The New Tek-Emulating Kermit and SAS
        HP-150 Terminal Program
        Kermit problems with Visual Commuter computer
        Kermit-MS 2.30 & Macintosh II

  MISCELLANY -
        CMS Kermit 4.0
        Problems with Apple Kermit.
        GNU Emacs with C64 Kermit
        First-Time Download of Kermit on Commodore-64 with Only Tape
        Kermit Sources Wanted for iRMX-86
        VME/10 Kermit?
        VT-52 Emulator for Osborn Exec
        One Character Checksum

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

Date: Fri 29 Jan 88 17:26:53-EST
From: Frank da Cruz <[e-mail]>
Subject: New Documentation for Old CIE-680 Kermit
Keywords: CIE Kermit

Sent in by the author, David S. Lawyer, of Irvine, CA, plus a termcap
entry for it.  In KER:CIE680.HLP and .TRM.

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

Date: Thu, 28 Jan 88 13:53 MDT
From: Joe Doupnik <[e-mail]>
Subject: MS-Kermit Under OS/2
Keywords: MS-DOS Kermit, OS/2

[Ed. - A question we're getting a lot these days is "Will (or can) MS-Kermit
run under OS/2?"  As far as 2.30 (and earlier) are concerned, the answer is
"yes, but only in DOS compatibility mode", i.e. taking over the whole machine.
As to the possibility of turning it into a real OS/2 application, we have the
following from Joe Doupnik...]

A switch to OS/2 is possible, even in assembler, but a C version would make
this much easier.  In simple terms, OS/2 is not an interrupt-driven system but
a more conventional "call" type.  So all the Bios/Dos software interrupts get
repackaged to do calls to system functions, much like a C interface.  The tough
part concerns hardware interrupts where either the machine interrupt enable bit
needs toggling (STI/CLI), not permitted under OS/2 full mode, and/or the
physical hardware needs attention from the program.  Rumors and the Microsoft
Journal say that interrupt handler latency is very, very long on 286 machines
and communications programs should expect troubles.  And, naturally, OS/2 runs
only on AT's and above.

So, the short forms are: Yes, it runs now in the DOS box, but a full OS/2
version needs a substantial development effort.  The Presentation Manager specs
are still fluid but when stable will require a second pass at OS/2 Kermit to
adapt to window sizing things.

        Regards,
        Joe D.

[Ed. - Thanks, Joe.  If anybody else has any insight into the issues involved
in bringing Kermit to OS/2, please send a message to Info-Kermit!]

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

Date: Mon, 01 Feb 88 22:04:50 -0800
From: Alastair Milne <[e-mail]>
Subject: Thanks for rollback help!
Keywords: MS-DOS Kermit 2.30

    To James Coombs, Eric Boehm, Doug Brenner, RECK@DBNUAMA1, Gisbert Selke,
    and all the others who were kind enough to respond about accidentally
    hitting HOME:

    Thanks very much for the quick and thoughtful replies.  Though remapping
    the HOME key had never occurred to me, it is obviously the quickest and
    easiest thing to do.  I don't mind having the PAGE UP and PAGE DOWN, since
    those let you move back with some control; and I think the END is a good
    idea, to get you back where you actually are as quickly as possible.  But
    the HOME is just grief.

    It's marvellous what the net can do for you.  The amusing thing is that I
    have not yet seen the info-kermit digest in which my own message appeared,
    and would never have know that the editor included a reply in it if one of
    you hadn't forwarded the copy to me.

    Thanks again to all.
    Alastair Milne

[Ed. - Also, did you know that there's a kind of automatic END feature?  Try
SET TERMINAL ROLL ON.]

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

>>Date: Mon, 11 Jan 88 11:12:15 est
>>From: [e-mail]
>>Subject: Screen Scroll in MS-Windows
>>Keywords: MS-DOS Kermit, MS-WIndows
>>
>>I have had problems making Kermit scroll up/down screens under MS-Windows
>>when in a window*.
>>
>>Version 2.29b and 2.29c (21 DEC) have been tested with version 1.01 - 1.03
>>and 2.03 of MS-Windows.  You are only able scroll up one line.
>>
>>Both Version 2.29b and 2.29c will scroll properly in a window under
>>Windows/386.
>>
>>* In a window refers to setting up the PIF file so that Kermit does not
>>write directly to screen and does not "modify" a com port.
>>
>>    Stephen Northcutt ([e-mail])
>>
>>[Ed. - This is a restriction of the program, noted in the MSKERM.BWR
>>file.  However, you should still be able to scroll up by using the mouse on
>>the scroll bar.]

[ From jrd - MS Windows 1.x, 2.x operates the screen in graphics mode but
has trouble reporting back text written by a program to the shadow text
screen. Thus, manually scrolling a Kermit screen within a shared MS Windows
window reports total gibberish or worse to Kermit as it tries to save text
lines scrolling off the screen. It's really an MS Windows concern.  To
suppress this characteristic roll back is turned off when in MS Windows.  MS
Windows/386 is not available locally and I have no idea of how to test for
versions of Windows.  Those little white lies we tell in the .PIF file
(Kermit does not directly access the screen, does not use serial ports,
etc!) are to make Windows behave itself but not to control Kermit.  What you
see Kermit do in a shared window is accomplished by magic.]

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

Date: Tue, 12 Jan 88 22:22 N
From: Jnet%"STREB@YORKVM1" 12-JAN-1988 19:15
Via: <[e-mail]> (Eberhard W. Lisse)
Subject: The New Tek-Emulating Kermit and SAS
Keywords: MS-DOS Kermit 2.30, Terminal Emulation, TEK

The line that I have used in my SAS routines to start Tek mode and then
turn it off is:

GOPTIONS DEVICE=TEK4010,GEPILOG='18'X,GPROLOG='1B0C'X,GPROTOCOL=GSAS7171

That seems to work just fine....

Jim Streb
Micro Support
York University
Downsview, Ontario
Canada

[Ed. - Presumably, this is when SAS is running on a mainframe, and the user
has a full-screen connection through an IBM 7171 protocol converter.]

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

>>Date: Tue, 26 Jan 88 10:55:52 PST
>>From: David Mendel <[e-mail]>
>>Subject: Kermit 2.30 graphics
>>Keywords: MS-DOS Kermit 2.30A
>>
>>    This is a suggested improvement for msvibm.exe 2.30.  Please forward
>>to the correct person.
>>
>>    I am using msvibm.exe 2.30 on an ATT6300, and I have had the following
>>problem with the graphics mode.  Normally I use the graphics mode to build
>>interactive plots using S which puts the command line near the bottom of
>>the screen.  If I make one typo, it prints an error message, and puts the
>>cursor at the top of the screen.  The problem is that this clears the
>>picture that I have created.
>>
>>    What I would like is an option at the 'More >' prompt to move the
>>cursor to the top of the screen without clearing the screen in the
>>process.  Perhaps pressing n would move the cursor to the top of the
>>screen without clearing the screen, while pressing any other key would
>>clear the screen as it does now.
>>
>>    Several of us use kermit with S here at Stanford and we would find
>>this to be a big improvement.
>>
>>Thanks,
>>David Mendel

[From jrd - The temptation to convert a simple Tek terminal into a modern
one is to be resisted.  My suggestion is to educate 'S' to behave differently
when it knows that it owns the bottom line of a screen (Tek or regular
text).  How about using the top left corner for user text?  'S' appears to be
a Stanford program so sources are likely to be nearby.]

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

>>Date: Sun, 10 Jan 88 20:59:48 PST
>>From: Ya'[e-mail]
>>Subject: MSKERMIT ver 2.29C tektronix 4010 won't overlay ALPHA and VECTOR
>>Keywords: MS-DOS Kermit 2.29C
>>
>>Possible bug with MSKERMIT version 2.29C:
>>
>>I have been using MSKERMIT vers 2.29C and have encountered a bug (feature?)
>>in the Tektroniks 4010 emulation mode.  Specifically, alpha mode characters
>>will erase and NOT OVERLAY vector mode data.  This frequently causes plot
>>titles and labels to obliterate the graphed data.
>>
>>ps:     I have an IBM-PC/xt clone with the CGA adaptor.
>>
>>[Ed. - This seems to be the behavior on the CGA, but not the EGA...]

[From jrd - A complete 8 by 8 dot character cell is written for each
character, so that both foreground and background colors are maintained and
characters can be erased. Supression of the background is being considered
but may not be do-able and still maintain the above characteristics. If
annotation is done first then the problem does not occur. I'd like
overlaying too.]

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

Date: Thu, 17 Dec 87  15:19 PST
From: [e-mail] (Adlai)
Subject: HP-150 Terminal Program
Keywords: HP-150 Kermit

Hi we have about 20 HP 150's (Hewlett packard Micro computers).  We need to
use them as full screen terminals for CMS.  Can You Help Us???

We have a copy of mskermit ver 2.27 for the HP-150, it transfer files great.
But it does not work as a full screen terminal, has someone writen a
terminal emulator for the HP-150 ?  It would be a very big help to use to
get such a program. Any ideas, information or sujestions would be very much
appreciated.

Adlai Jordan
MESA
Mathematics Engineering Science Achievement

[Ed. - HP-150 Kermit doesn't do any terminal emulation at all, but simply
passes incoming characters to the screen.  This goes through the HP-2621
terminal firmware, so you can use HP-150 Kermit for full screen applications
with hosts that know how to drive an HP-2621 terminal.  This means you'd have
to modify your protocol converter (Series/1, 7171, or whatever it is) to know
about the HP-2621 control sequences.  But don't attempt to use HP-150 as a
terminal emulator at speeds above 4800 baud.  It just doesn't work.  Finally,
you might want to pick up the 2.30 version of HP-150 Kermit from KERMSRV
at CUVMA.  It's in MSTHP1 *.]

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

Date: Sat, 23 Jan 88 17:08:20 EST
From: Marshall D. Abrams <[e-mail]>
Subject: Kermit problems with Visual Commuter computer
Keywords: MS-DOS Kermit, Visual Commuter

I am having problems getting Kermit to work on a Visual Commuter portable
IBM compatible computer and would appreciate communicating with someone else
who has been successful with this particular brand.  I am not on the info-
kermit list, so please respond directly.

I have tried both the Kermit in VTERM and stand-alone Kermit Vers 2.28.  Both
work from my office computer, but neither from home on the Visual Commuter.
I don`t think it's the modem or phone line, because I also have an Atari at
home and the Kermit on the Atari works just fine when plugged into the
modem.

I did turn on debug mode.  It took about 6-8 tries to get a file name
accepted for transfer, but no data packets ever got through. It just timed
out.  I tried adjusting the parity; that didn't help either.

I'm open to suggestions and thank you for your consideration.

Sincerely,

 - Marshall D. Abrams, phone: [phone]
   The MITRE Corporation, 7525 Colshire Drive
   Mail Stop Z670, Mc Lean, VA   22102

[From jrd - Marshall. Sorry, but I have no information on the Visual
Commuter.  Is there anyone else who can help?]

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

Date: Wed, 03 Feb 88 22:00 EST
From: "Mark B. Johnson" <[e-mail]>
Subject: Kermit-MS 2.30 & Macintosh II
Keywords: MS-DOS Kermit 2.30 on Mac II, MacKermit

Just as a note, Kermit-MS V2.30 runs standard VT-102 emulation and file
transfer (in background under MultiFinder) just great using the AST286 board
in a Macintosh II.  The new Macintosh version is much faster of course, but
for those people who have to have MS-DOS software, it is quite useable.  I
will give the TEK emulation a try next.  Just thought someone out there
might be able to use this information...

Mark

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

Date: Thu, 1988 Jan 28   14:21 EST
From: (John F. Chandler)   [e-mail]
Subject: CMS Kermit 4.0
Keywords: CMS Kermit

Comments on comments about CMS Kermit 4.0 in recent Info-Kermit Digests...

> 2) This may be a local problem, but I get the following message on startup:
>
>    "Handshake is XON -- not needed"

This startup message is just a friendly reminder to heed paragraph 4 in
section 1.2 of the CMS Kermit User's Guide:

  CMS is different from some other IBM mainframe systems in that allows
  a program  to take control  of prompting  and synchronization  on TTY
  lines.  Kermit-CMS  takes advantage of this option, and it is not, in
  general, necessary  to enable handshaking  on the micro Kermit before
  connecting to CMS.  In other words, handshaking  should be suppressed
  for both  TTY and SERIES1  devices  (the  micro  Kermit  should  have
  HANDSHAKE  set OFF, and Kermit-CMS  should have HANDSHAKE  set to 0).
  Since the generic Kermit-370  default handshake  (XON) is retained in
  Kermit-CMS,  the subcommand  SET HANDSHAKE  0 is a good candidate for
  inclusion in SYSTEM KERMINI.

By the way, I noticed that you didn't "Ed." the comments from Brown in Digest
#3 about trying to set the SEND packet size -- surely, you don't feel that one
Kermit can even try to force another to accept Long Packets; that's what it
would mean if Kermit-CMS accepted the command SET SEND PACKET 1900.  Perhaps
the documentation should explicitly say that one can't do that.

[Ed. - Right...  that one slipped by.]

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

Date: Mon, 1 Feb 88 11:36 N
From: <[e-mail]>
Subject: Problems with Apple Kermit.
Kewyords: Apple II Kermit

I recently got a copy of version 3.79 of Apple II KERMIT.  I experienced
some problems under ProDOS to up/download text files since they are always
handled in 7 bit mode (setting unconditionally the high order bit when
receiving and stripping it off when sending) like under DOS 3.3. This is
incorrect since now the Apple IIgs uses this high order bit to extend the
ASCII character set in the same way as on the Macintosh.  Unfortunately I
have no source code to try to patch the code in order to enable a full 8 bit
text file transfer under ProDOS.  Can you help me?  Thanks in advance & best
regards.

                                Fabio Viviani
                                C.S.E.L.T. - Turin, Italy
                                ([e-mail])

[Ed. - This is certainly a trend.  Your message has been forwarded to the
current developer of Apple II Kermit, who's working on a new release.]

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

Date: Wed, 03 Feb 88 22:05:09 -0500
From: [e-mail] (Ray Moody)
Subject: GNU Emacs with C64 Kermit
Keywords: C64 Kermit

In Info-Kermit Digest Volume 7, Number 3 you write:
>While using GNU Emacs with C64 Kermit at 1200 baud, I noticed when scrolling
>UP ONLY, the screen would get garbled. (Probally overflowing the input
>buffer? I haven't notice this happening at 300 baud (300 baud?!? ARGH!))

    Yes, you are quite right.  Since the Commodore-64 has no built-in
80-column screen, I have to simulate 80-columns with bitmap graphics.
Scrolling a bitmap screen backwards is a non-trivial operation and takes a lot
of time.  If Kermit receives scroll-reverse requests too fast, it will overflow
its input buffer.

    Normally, when Kermit's input buffer is in danger of being overflowed,
Kermit will transmit a ^S to stop the remote host from sending.  The only
problem is that GNUemacs chooses to ignore this stop request.

    There are several ways to solve this problem:

    1) The best solution I can think of is to tell GNUemacs that you wish to
       use flow-control.  You can do this by putting (set-input-mode nil t)
       in your .emacs file.

    2) Ask GNUemacs to provide a delay after scrolling the screen backwards.
       You can do this by adding sr=<XXX>\EM to your terminal description,
       where <XXX> is the number of milliseconds of delay that you want.  I
       experimented a little and found that 200 milliseconds is "about" right.
       This isn't very elegant because it will slow GNUemacs down a lot.

    3) Use a Commodore-128 or wait for Kermit 2.1 to be released and use a
       Batteries-Included 80-column add on card.  If you use one of these,
       Kermit will not be forced to simulate an 80 column screen with graphics.

                   Ray Moody,    Author of Commodore Kermit version 2.0
                    [e-mail]
                    ihnp4!pur-ee!j.cc.purdue.edu!ray
                    [e-mail]

    Many thanks to Jay Vosburgh for providing the magic emacs incantations.

[Ed. - And thanks for passing along the hints.  They've also been added to
the Commodore-64 Kermit "beware" file.]

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

Date: 12 Jan 88 15:12 +0100
From: Alf Christophersen <[e-mail]>
Subject: First-Time Download of Kermit on Commodore-64 with Only Tape
Keywords: C64 Kermit

A friend of me want to get KERMIT on his Commodore 64 with CP/M, but he
has only a tape station.  How do we upload first time, e.g. from a
Olivetti M24 with direct connection over RS232?  I remember there was
a procedure when I loaded first time with our Altos 8000/7, but have
forgotten the procedure.  Does anyone have some idea?  Is there any tape?

Alf Christophersen
Engineer
Dep. of Nutrition Research
PO. Box 1046 BLindern
N-0316 Oslo 3
Norway

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

Date: Fri Jan 15 00:20:02 1988
From: peregrine!imt3b2!seila![e-mail]
Subject: Kermit Sources Wanted for iRMX-86
Keywords: iRMX Kermit

Anyone out there have working C or PLM sources for kermit under release 6+ of
iRMX-86 running on a 310 box?  Please email replies.  Thanks in advance!
According to info from Columbia U., someone at Grinnel College (?) has done
this...

Don Kossman, SEI Information Technology, Los Angeles
usenet: {ccicpg!imt3b2 | peregrine!imt3b2 | sun!tsunama!tsunami}!seila!don

[Ed. - There are two families of Kermit programs for (i)RMX(2)86.  One
consists of variations on a version written in PL/M, and the other is an
adaptation of MS-DOS Kermit by Jack Bryans at Calstate.  Does anyone know
of any reason why the former would still be necessary in the presence of
the latter?  And if there is any reason for keeping a PL/M version, which
of the three that we have should be kept?  Below is a list...]

IRM C  Intel 86/380     iRMX-86    PL/M         2.41  87/03/04  Grinnell Col.
I86 C  Intel 86/380     iRMX-86    PL/M         2.3   85/09/23  Grinnell Col.
RMX C  Intel 86,286     RMX 1.0    PL/M         1.0   85/10/25  Cornell U
MS  A  Intel 300 Series iRMX-86    MASM/ASM86   2.29Z 88/01/07  Cal State
MS  A  Intel 300 Series iRMX-286   MASM/ASM86   2.29Z 88/01/07  Cal State

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

Date: Thu, 31 Dec 87 07:57:23 CST
From: [e-mail] (rod merry)
Subject: VME/10 Kermit?
Keywords: VME Kermit

Does anyone know where I can get a binary copy of Kermit for the Motorola
VME/10 running VERSADOS.  I will supply or pay for the diskettes.

Thanks,

Rod Merry                               [e-mail]
Computer Network Technology             {quest|meccts}!cnt!rod
9440 Science Center Drive
Minneapolis, MN 55428                        [phone]

[Ed. - Try Wm. Pierce, Motorola Semiconductor, 3102 N. 56th St, MS/56-122
Phoenix, AZ 85108.  We have had reports that this person has, and distributes,
a VME/10 VERSADOS Kermit, but we have never received it.  We'd like to carry
a VERSADOS Kermit in our distribution, and would like an "official" source
to refer people to who need it on diskette.  If anybody finds out the status
of this purported Kermit version, please let us know.]

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

Date: 29 Jan 1988 06:18-CST
From:  John A. Wright <[e-mail]>
Subject: VT-52 Emulator for Osborn Exec

Does anyone know of a Kermit program with a VT-52 emulator for the Osborne
Executive.  If one does not exist, does anyone know of a VT-52 emulator for
the same?

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

Date: 20 Jan 88 00:37:50 GMT
From: [e-mail] (John McDaid)
Subject: One Character Checksum
Keywords: Checksum

Can anyone give me a short, CLEAR explanation on how a one character checksum
is derived in Unix Kermit?  Mail me directly with the answer.  I thank anyone
who gives this any effort.

John McDaid
[e-mail]

[Ed. - Add up the 8-bit values of all the bytes from the length field to the
last data byte.  Truncate the sum to 8 bits.  Call this S.  Then:

X = S & 63;         /* Low order 6 bits */
Y = S & 192 >> 6;   /* High order 2 bits, shifted to right */
C = (X + Y) & 63;   /* Add them together, keep low 6 bits of result */
CHKSUM = C + 32;    /* Make it printable */

More concisely (as it is actually done in C-Kermit):

CHKSUM = tochar((s + ((s & 192)/64)) & 63);

This was originally designed, back in the days of 8-bit processors, to work
on machines that could only do 8-bit arithmetic.  The idea was to have all
the bits of an 8-bit sum contribute to a printable ASCII single-character
checksum.]

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

End of Info-Kermit Digest
*************************
-------
17-Feb-88 12:08:08-EST,25795;000000000000
Mail-From: SY.CHRISTINE created at 17-Feb-88 12:07:11
Date: Wed 17 Feb 88 12:07:10-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #6
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 17 Feb 1988       Volume 7 : Number 6

Departments:

    MS-DOS KERMIT -
        MS-Kermit for the GRiD Compass (Six Messages)
        MS-Kermit Tektronix 4010 Graphics Emulation
        Problem Setting Num Lock and Scroll Lock Keys in MS-Kermit
        Kermit 2.30 for HZ100?

    C-KERMIT -
        Bug Report for C-Kermit 4E(070) on Unix PC (3b1)
        Re: Unix Kermit Idle Line Problem
        C-Kermit 4E(070) vs System V R3 vs 3B2
        C-Kermit for Xenix 286?

    MISCELLANY -
        Using TOPS-20 Kermit with 9-Bit Files
        Need Kermit for Microbee?

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

Date: 28 Oct 87 20:54:41 GMT
From: [e-mail] (Owen Adair)
Subject: MS-Kermit for the GRiD Compass
Keywords: MS-DOS Kermit 2.29C, GRiD Compass

I am using kermit for the GRiD. I have difficulty using the BREAK function
while online. It seems to reset the serial port or something. Is there
anyone else out there using MSKermit with the GRiD?

Owen Adair, WD4FSU
Digital Signal Processing Lab, Georgia Tech, Atlanta GA 30332
Internet:       [e-mail]
uucp:  ...!{decvax,hplabs,ihnp4,linus,rutgers,seismo}!gatech!gt-eedsp!owen

[From jrd - Right, we need a Grid guru. Any volunteers?]

[Ed. - See messages below....]

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

Date: Sun, 31 Jan 88 18:14:14 EST
From: David Kirschbaum <[e-mail]>
Subject: Re Grids and Kermit
Keywords: GRiD Kermit

NetLandians,

I keep hearing pleas from Grid users to make Kermit work with the Grids.
I'd be more than glad to give a hack to it (got source for v2.30, much
experience with assembler, comm ports, etc.).  However .. I do NOT have any
details on the stupid serial ports, interrupts, chips, etc. for the Grid
running under MS-DOS.

I tried long ago to get such information, or little smidgens of source code
for Grid's stupid comm program, but discovered I was suspected of trying to
steal the Crown Jewels .. and left Grid to their own just deserts.  If
someone has ANY technical information on exactly what it takes to tweak a
Grid's serial port(s), and can pass that info to me (ANY language!  Just so
it isn't buried in 80Kb of some pirated comm program's binary object file.)
.. will be glad to give it a hack.  Of course I don't HAVE a Grid, so
couldn't test it .. but could send the .ASM source (fully documented) to a
willing volunteer (who had MASM) to assemble and test.

Mail directly to me .. no use inflicting Info-Kermit with this.

David Kirschbaum
Toad Hall
[e-mail]

[Ed. - Thanks for the offer David.  Anyone with a GRiD willing to help?
But first, see following messages.]

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

Date: Mon, 1 Feb 88 13:55 EST
From: RLH <[e-mail]>
Subject: MS Kermit 2.30 on GRID
Keywords: GRiD Kermit

In Vol. 7, No. 4, Owen Adair wrote about not being able to run MS Kermit v
2.30 on a Grid model 1101. I am not familiar with the model 1101, but do
have v 2.30 running on a Grid GRIDCASE 2 PLUS.

I used a copy of the executable that I had put together for a standard
IBM-PC and it worked without changes. I never even tried the Grid specific
code. I have not exercised all Kermit features but I have done considerable
file transfer between the Grid and VAX/VMS as well as with true IBM-PC's -
no problems. Also, the VT102 terminal emulation works great with DEC
software such as TPU, EDT, and LSE.

Version 2.30 is a great package. Thanks to everyone who helped put it
together.

                Bob Haar        ( [e-mail] )
                G.M. Research Labs

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

Date: Wed, 3 Feb 88 10:48:54 EST
From: sundc!hadron![e-mail] (Kurt L. Reisler)
Subject: Re: MS-KERMIT 2.30 for the GRiD
Keywords: MS-DOS Kermit 2.30, GRiD Kermit

>
> Does this mean that you have tested the GRiD version and found it to work?
> I've had reports from other people that it didn't work.  If it does, could
> you send a brief synopsis of your exact system model, OS version number,
> configuration, etc, so that we can pin down what the problem might be, if
> any?  Thanks!  - Frank
> -------
>

Well, I have not tested it extensively, but I have tried it on a 1129, and a
friend has tried it on an 1101.  You need to set port 2 to access the
internal modem.  Then, in uppercase (shift escape to lock) you need to do a
ATZE1 to see your commmands echod.  Problems include the fact that it
appears to run only at 300 baud, and there is an EXTREME amount of internal
buffering going on, until you escape back to the kermit command level.  Then
the buffering seems to go away (?).  I have successfully transfered a file
(at 300 baud GAK!).  I hope to have more time this weekend to play with it
further.  Let me see what version of MSDOS it is running. MSDOS 2-11 Bios
version C

Help that this helps. and I will keep you posted.

(later...)

What a wonderous thing documentation is.  It causes the gloom to lift
like the rising of the sun :-)

Adding the following to the autoexec.bat file on the MSDOS side of the
GRiD will cause the modem port (comm2) to default to 1200 baud:

echo baud=1200 > com2stat

Once in KERMIT, use the SET PORT 2 command to access the modem, and it
will only take upper case commands.  Will be testing it more extensively
over the weekend.

 Kurt Reisler [phone]

 UNISIG Chairman, DECUS US Chapter                       | Hadron, Inc.
 ..{uunet|sundc|rlgvax|netxcom|decuac}!hadron!klr        | 9990 Lee Highway
 Sysop, Fido 109/74  The Bear's Den   [phone]     | Suite 481
 Sysop, Fido 109/483 The Pot of Gold  [phone]     | Fairfax, VA 22030


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

Date: Fri, 5 Feb 88 23:47:35 EST
From: sundc!hadron![e-mail] (Kurt L. Reisler)
Subject: Re: MS-KERMIT 2.30 for the GRid
Keywords: MS-DOS Kermit 2.30, GRiD Kermit

As promised, more information, and ALL of it is posative.  I have a working
copy of "GRiD Compass II Version A MS Kermit V2.30" dated 8 January 1988.  I
got it off of Columbia via anonymous ftp, in the normal boo format.  Used
the utilited from Columbia to convert the boo file to a .EXE file on my 4.2
BSD system, transferred it to my Fido BBS (on a DEC Rainbow) then using
MediaMaster, to a SSSD IBM diskette, to the GRiD.

I have used it sussessfully (am using it at the moment) on a GRiD 1101 and
GRiD 1129.  In both cases, the systems are configured with a GRiD 2101 Hard
disk subsystem.  The GRiDS are setup for GRiDOS, with the MSDOS (2.11-C)
running on a partition of the hard disk.  I also figured out how to get it
to run at 1200 baud (RTFD :-).

Anyway, in the AUTOEXEC.BAT file on the MSDOS partition, I have the
following:

        ECHO BAUD=1200 > COM2STAT
        ECHO V=250 > COM2STAT

To set the baud rate and volume on the modem.  In the MSKERMIT.INI file,
I have the following:

        SET PORT 2
        SET BAUD 1200
        STAT

Once I Connect to the modem, I issue the following command to the modem:

        ATE1Q0V1

So that I can see what I am doing with the standard Hayes modem
commands.

So far, it seems to work fine.  Have been able to upload and download
files between the GRiD and my FIDO systems without problems.

Anyway, hope this has been helpful.  If you think it would be useful, I
can uuencode the copy I have and post it to the net.  In addition, it is
available for download from either of my fido nodes, listed in the
.signature below.

 Kurt Reisler [phone]

 UNISIG Chairman, DECUS US Chapter                       | Hadron, Inc.
 ..{uunet|sundc|rlgvax|netxcom|decuac}!hadron!klr        | 9990 Lee Highway
 Sysop, Fido 109/74  The Bear's Den   [phone]     | Suite 481
 Sysop, Fido 109/483 The Pot of Gold  [phone]     | Fairfax, VA 22030

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

Date: 10 Feb 88 14:07 PST
From: [e-mail]
Subject: Re: Kermit 2.30 for GRiD
Keywords: MS-DOS Kermit, GRiD Kermit

;;;     I downloaded 2.30 Kermit for the GRiD (.BOO format) and it
;;;     tries to run, but all I get is garbage then it crashes. Has anyone
;;;     else tested the beast on a GRiD model 1101? I currently use 2.29
;;;     and it works although not all the features function.


Last night I brought MSTGRI 2.30 up on my Grid and it worked well, except
for baud rate change (I couldn't get 300 baud to work). I called a couple of
systems and performed successful uploads and downloads of ASCII files (I
haven't tried binaries yet).

My system is a Grid Compass-II 1121, which is like the 1101 except that it has
ROM sockets. I was using ROM-based MS-DOS 2.11. I did have to explicitly SET
PORT 2 from inside Kermit. My modem driver is Grid's MODEM.SYS. I dialed out by
typing C, then ATTD 123-4567.

[Ed. - So it seems that the GRiD version of 2.30 sort of works on the GRiD
Compass, which is not IBM Compatible, and that the IBM PC version works on
the GRIDCASE 2 PLUS, which is IBM compatible.  So we have a semisolid base to
work from, in case anyone who is a GRiD expert wants to make improvements.
Volunteers should contact Info-Kermit@CU20B.  Meanwhile, these messages have
been added to the "beware file" for the GRiD, MSVGRI.BWR.]

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

Date: 12 Feb 88 13:55:26 GMT
From: ecsvax.uucp![e-mail] (Robert T. Herbst)
Subject: MS-Kermit Tektronix 4010 Graphics Emulation
Keywords: MS-DOS Kermit 2.30

I have recently installed kerm230 on a pc6300 and a pc6300plus.  Not only is
kerm230 excellent for communications, it also has super terminal emulators.
The vt102 permits keypad editing on VAX/VMS. Better yet the TEK 4010
emulator allows interaction with gnuplot. Now we have the best of several
worlds.

                        R. T. Herbst
                        herbst@ecsvax

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

Date: Fri, 12 Feb 88 10:51:09 PST
From: "Eric Yen  714-856-5244" <[e-mail]>
Subject: Problem Setting Num Lock and Scroll Lock Keys in MS-Kermit
Keywords: MS-DOS Kermit 2.30, Num Lock, Scroll Lock

Is it possible to use the MSKERMIT "Set Key" command to have the IBM PC
NumLock and ScrollLock keys generate escape sequences?  My attempt to do
so failed.

Eric Yen
Systems Programmer

[Ed. - Unfortunately, it is not possible because the IBM Bios does not return
scan codes when these keys are pressed.]

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

Date: Fri 12 Feb 88 15:00:17-PST
From: Mike Dante <[e-mail]>
Subject: Kermit 2.30 for HZ100?
Keywords: Heath/Zenith 100

I note in your Version hlp file that there exists a Kermit Version 2.3 for
the Zenith HZ100. (Or am I not understanding the file?)  But I could not find
a new version under KER:MSVZ10.*.  I tried the generic MS_DOS version on my
Z100 but I could not set the baud rate.  I kept getting the message "Command
not implemented."  Am I having a problem decrypting the .BOO file?  Is there
a KERMIT V2.30 available for the HZ100?

Thanks,

Mike

[Ed. - Generic MS-Kermit doesn't know how to set the baud rate, because it
knows nothing about the PC's specific hardware.  You should be able to set
the baud rate outside of Kermit using some kind of system utility (like MODE
on the IBM PC), and then Kermit should use the port as you've set it up.  The
latest test version of Kermit for the Heath/Zenith 100 is in KER:MSTZ10.BOO
on CU20B, dated January 19, 1988.  H/Z-100 users are encouraged to test it
and report the results, and if there are problems, to apply or suggest
fixes.]

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

Date: Fri, 12 Feb 88 12:34:08 EST
From: David Herron E-Mail Hack <[e-mail]>
Subject: Bug Report for C-Kermit 4E(070) on Unix PC (3b1)
Keywords: C-Kermit 4E(070)

I've gotten a copy of C-Kermit and am trying it out on various machines.
Mainly my Unix-PC since it's advertised to support the UnixPC.

First off, it wouldn't even compile right.  In ckudai.c there is a "static
MDMINF ATT7300" which simply CANNOT be right.  The problem is that you're also
using "ATT7300" as the pre-processor symbol to select UnixPC features, and it
has a null value, and the statement ends up looking like:
"struct mdminf = { ... };" which is a syntax error.

My workaround for the moment is to make all references to that symbol to be
"att7300" and make sure it's "static".  The preprocessor on UnixPC's is of the
style that doesn't allow:

        #define ATT7300 ATT7300

because it complains about macro recursion.  (Oh, BTW, I'm running SYSV r3.51,
the latest version for Unix PC's).

Next, the makefile stuff for supporting the shared libraries is wrong.  When
doing an ld to use the shared libraries, at least on Unix PC's, you pretty
much have to use ld directly like:

        ld {some options} /lib/shlib.ifile {object files}
                {more options} /lib/shlib

I may be off in a detail or two, but the point is that the way it was written
in the makefile was very wrong, as evidenced by all the multiply defined
symbols.  Further, if I undo the stuff for the shared libraries I get
"tgetent" and a couple of other termcap functions as being undefined.  And I
can't find those functions in any of the libraries on the system.  What I
ended up doing was using a "cc" front end which handles loading the shared
libraries properly and has support for programs which use curses.  It was
posted recently in unix-pc.sources and I could forward it to y'all if you
want.  (It's the one named "ccc", there's at least one other of these
scripts).

Using "ccc" I got it pretty close, but there's a routine in /lib/shlib named
"openi" and there was a conflict between it and the one y'all had in ckcfns.c
-- the workaround here is to declare YOUR openi() to be static (which works
because it's not used in any other of your files), and don't forget to put a
"static openi();" at the beginning of the file as well.  There's even a
section reserved up there for local variables.

Now I've got a program that compiles and loads without errors.  In testing
some functionality:

I started with the remote kermit in server mode and transferred /bin/cat to
the remote (a 4.3bsd vax running kermit 4C(057)) and then got it back ("get
cat").  The result is a cat that is one byte shorter, but is otherwise exactly
the same.  Now, this is a real neat trick too, 'cause it starts and ends with
the EXACT same bytes (I looked using od)!  This shouldn't work out like this.
The new copy should be missing a byte at the end, but we've got the same byte
at the end.  There isn't a byte missing in the middle 'cause "cmp" doesn't
find it, and if I "diff" the "od -c" output from each file, the ONLY
difference is the byte count at the very end.

I'm more than a little confused about that one ...

While the remote is in server, the local kermit acts rather strangely.
Possibly when doing ANY command, but definitely when doing send, get, and "!"
commands, to get back to command level from the command I have to type ^R ...
the only other character I've tried is <CR> which didn't get me back to
command level.  Further, I once hit an empty line then started to do a shell
escape and it dumped me OUT of kermit and said something about an invalid
shell command.  (an asice: There's times when I hate command processors which
read what I'm typing and complain before I get a chance to fix typing errors
...)

FINALLY:

In order to successfully connect to the modem and make a phone call I have to
enter this non-intuitive sequence of commands:

        ! rm /usr/spool/uucp/LCK..ph0
        set line /dev/ph0
        set modem att7300
        set speed 1200
        dial <phone number>
        ! phtoggle
        dial <phone number>

If I don't remove the lock file first, the set line command of course will
complain about the lock file being there.  But if I go ahead and phtoggle then
set line, the open in set line never returns and I hang.  Then, there's some
other state where if I phtoggle the getty process that get started starts
looping -- that is, getty exits immediately causing init to start a new one
which exits immediately, and so on.  Anyway -- I haven't tried it without a
dial command before the phtoggle yet.

I've got a kermit around here which'll let you do:

        ! phtoggle
        set line /dev/ph0
        set modem att7300
        set speed 1200
        dial <phone number>

just like you'd expect ... but it's an old copy that someone here made work
and then never told you guys about the changes.  (ARGH!)  Anyway, between the
two versions I should be able to get something working.

Oh, another problem when I exitted kermit ...  I said "quit" and it waited a
little while and said "Problem with hanging up modem".

[Ed. - Unfortunately, we don't have any Unix PCs, or for that matter any
System III or V systems to test C-Kermit on, so we rely on people like
you to tell us what to do, or what we should have done.  You're apparently
the first person who tried the new ATT7300 stuff, so thanks for the feedback
on that.  But I haven't heard complaints from others about multiply defined
symbols, shared libraries, etc, and a lot of people are running this version
on System V, so I can only assume the problem there must be UnixPC-specific.

If you can send me a makefile entry that you have actually used with the
UnixPC, I'll be glad to replace the current one with yours, and add a hint
that if people have trouble w/other ATT Sys III/V based systems, they might
look at the ATT7300 entry for a model.  If this is new stuff, then we have
a slight problem, because up till now (or at least up to Sys V R3), all
Sys III and Sys V C-Kermits could be compiled the same way.

Termcap???  There's nothing in Kermit that uses termcap or curses...
The other stuff will have to be looked in to.  Thanks for the report.  For
now, it's been added to the "beware file", CKUKER.BWR.]

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

Date: Wed, 10 Feb 88 22:29:13 EST
From: rochester!ames!ucbcad!ucbvax.Berkeley.EDU!-
  ucbcad!ames.uux!pur-ee!iuvax!bsu-cs![e-mail] (Rahul Dhesi)
Subject: Re: Unix Kermit Idle Line Problem
Keywords: C-Kermit, Unix Kermit

Re: Info-Kermit Digest V7 #3

This is an answer to a query from [e-mail] (Michael Galassi)
dated 28 Dec 87 00:42:59 GMT, in which he said that users using
"C-Kermit, 4C(057) 31 Jul 85, 4.2 BSD" are timed out for being idle
even though they are doing Kermit file transfers.  Here is my
work-around as it was posted in a local newsgroup.

"By popular demand, here again is the technique for avoiding inactivity
timeouts when doing a long file transfer via Kermit.

Step 1.   At the system prompt, give the command "tty".  This command
will print your terminal name.  It will be of the form /dev/tty15
where instead of 15 you will see the number of your terminal.
Remember it.

Step 2.  Invoke Kermit interactively with the command "kermit" given
without parameters.  (Actually you can give parameters too, so long
as they don't cause Kermit to begin data transfer immediately.)
When Kermit starts up and prints the prompt "C-Kermit", you go to:

Step 3.   To Kermit, give the command "set line /dev/tty15".  In place
of the 15, use whatever terminal number you obtained in Step 1.

Step 4.  Now give Kermit the commands necessary to begin your file
transfer.   You will not get an inactivity timeout.

Users who want to win fame on this system and the gratitude of others
can change Kermit so that the above sequence will not be necessary.
Currently Kermit uses the standard device /dev/tty which is synonymous
with your actual terminal.  However, the operating system treats it
like a distinct device from your actual terminal.  So, even though a
file transfer is going on using /dev/tty, the actual terminal, say
/dev/tty15, seems to be idle to the system, so you can get logged out.
This can be fixed by (a) finding the place where Kermit opens /dev/tty
and (b) replacing that with an open of the actual terminal name, which
can be obtained from the system call ttyname()."

Rahul Dhesi         UUCP:  {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi

[Ed. - We'll consider this for the next release.  Meanwhile, this message
has been added to the C-Kermit "beware file", CKUKER.BWR.]

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

Date: 10 Feb 88 23:09:57 EST (Wed)
From: ames!netsys![e-mail] (Len Rose)
Subject: C-Kermit 4E(070) vs System V R3 vs 3B2
Keywords: C-Kermit 4E(070)

One little note to people setting up this on an ATT 3B2 running under
SYSVR3...  They have two options in the makefile that sort of clash when you
are bringing up this software.. You either have to choose:

make att3bx or make sys5r3

If you don't choose att3bx,the code does not look for the LCK..ttyxx in
/usr/spool/locks ... However if you choose att3bx,it does not handle signals
correctly...  All I did to defeat this was just put a #define in ckutio.c for
att3bx...

Just thought I'd pass this on, no big deal with it...

Len

[Ed. - Sigh, lock files again.  There must be some better approach.  Are
there any Unix experts out there who can suggest a better way to deal with
this problem, than requiring Kermit itself know the directory name, the
filename, the permissions, and the contents of the lock file on every version
of every Unix variant?  Perhaps a separate program that runs Kermit in a
lower fork, or a program that Kermit runs in a lower fork.  Of course,
separate programs have a way of getting lost...]

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

Date: 12 Feb 88 00:38:41 GMT
From: hplabs!sun!texsun!liberty!swatsun![e-mail] (Eiji "A.G." Hirai)
Subject: C-Kermit for Xenix 286?
Keywords: C-kermit

This is a request for help in getting kermit working BUT wait ! - don't
ignore us, please!  Where would this network be if nobody helped each other
with other's problems some of the time?  I usually give help when I can with
a question on the net...  Anyway, here's our problem:

If anyone has had experience with getting C-Kermit 4C to work on Xenix 286
systems, could you divulge to us what you did to get it to work?  We can
compile but cannot work C-Kermit to work on our Sperry's and Intel 286/310.
We would bery bery much like to talk to you!

        Thanks everyone.

                                                -a.g. hirai
                                                a sysadmin for swatsun.uucp

Eiji "A.G." Hirai @ Swarthmore College, Swarthmore PA 19081 | Tel. [phone]
UUCP:   {rutgers, ihnp4, cbosgd}!bpa!swatsun!hirai |  "All Cretans are liars."
Bitnet:       vu-vlsi!swatsun![e-mail] |         -Epimenides
Internet:            bpa!swatsun![e-mail] |         of Cnossus, Crete

[Ed. - The current version, 4E(070), allegedly works OK on Xenix 286, and
there's even a special makefile option for it, "make xenix" (for Microsoft)
or "make sco286" (for SCO Xenix 286).  But that doesn't mean there will be
no problems.  There is tremendous variation among the C compilers, runtime
libraries, etc, among the endless number of products (and versions thereof)
that call themselves Xenix.]

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

Date: Wed 3 Feb 88 18:35:32-PST
From: Bruce Tanner <[e-mail]>
Subject: Using TOPS-20 Kermit with 9-Bit Files
Keywords: TOPS-20 Kermit, DEC-20

I've gotten the MS-DOS 2.30 .BOO files and decided to use the MSBPCT.C
program using the Stanford KCC compiler.  The program ran fine unchanged.
However, opening a file "wb" generates a 9-bit file (four nine-bit bytes per
word).  OK, just use the "SET FILE SIZE AUTO" and let Kermit figure it out,
right?  Wrong.  I had to teach it about 9 bit files also.  So, here are the
REDIT changes I've made to edit 262 (decimal 178):

1. Recognize 9 bit files
2. Clean up the Moon: code (it kept giving me phase errors)
3. Make edit decimal (just remove the vi%dec at Version: if you don't like it)

[Ed. - Thanks!  Code omitted, copied to KER:K20MIT.BWR for now.]

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

Date: Mon 15 Feb 1988 19:06:16 CST
From: Mark S. Zinzow <[e-mail]>
Subject: Need Kermit for Microbee?
Keywords: Microbee Kermit

I have a request from a user on our campus for a copy of kermit for the
following system purchased in Sweden and made in Australia.  Is a native
media version available, or does anyone know if this machine can be coerced
to read any PC formatted disk?  I just thought I'd check before trying to
bootstrap the generic CPM version.

Hardware:
Micro Bee Model II C. 1982
128 k
Expansion unit SBCO1

Software:
Telcom 2.0
CMP 80 C. 1984 copy may 3, 1985

[Ed. - We don't have any record of a Micro Bee in our list of existing
Kermits, or list of Kermits in progress.  Like most CP/M systems, it can
probably use one of the existing CP/M Kermits with a few minor adjustments
to port addresses, etc.  Has anyone had any experience with a Micro Bee
computer?]

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

End of Info-Kermit Digest
*************************
-------
 1-Mar-88 17:07:23-EST,24193;000000000000
Mail-From: SY.CHRISTINE created at  1-Mar-88 17:06:27
Date: Tue 1 Mar 88 17:06:27-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #7
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 1 Mar 1988       Volume 7 : Number 7

Departments:

  ANNOUNCEMENTS -
        Recent FTP (and general TCP/IP) problems with CU20B
        New BOOing and UnBOOing Programs, and German Kermit Documentation
        Keasy - "Easy Kermit" documentation in TeX
        Kermit-CMS Updates

  MS-DOS KERMIT -
        Minor problems in Kermit-MS V2.30
        MSKermit on Zenith eaZy-PC Serial (Mouse) Port
        Kermit & OS/2
        Int 14h, Kermit and Networks
        MS-Kermit Tek 4010 Emulation Typeover -vs- Overlay
        IBM PC MS-Kermit vs Datatronics Internal Modem
        MS-DOS Kermit Using EGA 43 Line Mode
        Toshiba T3100 versus MS-Kermit Tek Emulation

  MISCELLANY -
        C-Kermit on sys-V Based PCs
        Using TOPS-20 Kermit with 9-Bit Files
        Re Mark Zinzow's request for MicroBee Kermit

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

Date: Mon 29 Feb 88 18:13:55-EST
From: Ken Rossman <[e-mail]>
Subject: Recent FTP (and general TCP/IP) problems with CU20B
Keywords: FTP

Recently, there has been an increasing frequency in the number of problems
experienced with FTP file transfers from the Kermit directories on CU20B.
While I am not sure of all of the different possible causes for this recent
set of problems, I do know that we have sorely needed some IP fixes in the
TOPS-20 monitor on CU20B.

Well, the fixes are finally installed!

I'm hoping that the IP free space fixes we've recently installed here will
help FTP performance to/from CU20B.  I'd be interested in hearing from some
of the sites out there who were so recently having FTP performance problems
to CU20B.  Do things appear to be working better now?

/Ken

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

Date: 12 February 1988, 16:21:39 SET
From: Gisbert W. Selke <[e-mail]>
Subject: New BOOing and UnBOOing Programs, and German Kermit Documentation
Keywords: .BOO Files, German

I have converted MSB*.PAS to Turbo Pascal 4.0, and sent them as MSBMKB.PAS
(which makes .BOO files) and MSBPCT.PAS (which decodes them).

I've also sent updated copies of the corresponding Fortran versions,
MSB*.FOR.  I have removed some more system dependencies which I hadn't even
been aware of before (thanks to Stefan Kaufmann for pointing them out), and
also fixed a minor bug in MSBMKB.FOR due to which garbage was added at the end
of a BOO file.

And I have also sent a new, corrected German translation of the MSKERM.HLP
file, under the name MSKGER.HLP.

I just noticed that there is no 63 second restriction on MS-Kermit 2.30's SET
INPUT DEFAULT-TIMEOUT and the like, as I seem to recall there used to be.
That's great, since our host is sometimes *quite* sluggish!

\Gisbert

[Ed. - Thanks Gisbert!  Your contributions have all been installed with the
MS-DOS Kermit distribution.]

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

Date: Mon, 8 Feb 88 16:53 N
From: Barbara Rosi <[e-mail]>
Subject: Keasy - "Easy Kermit" documentation in TeX
Keywords: TeX, LaTeX

Thank you very much for giving us Kermit, it has been a valuable resource and a
pleasure to participate in the community.  Enclosed is a translation of part of
the Kermit User Guide from Scribe into LaTeX.  Thank you very much for your
interest.

[Ed. - Thank you!  It has been put into KER:KEASY.TEX.]

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

Date: Mon, 1988 Feb 29   18:34 EST
From: (John F. Chandler)   [e-mail]
Subject: Kermit-CMS Updates
Keywords: CMS Kermit 4.0

I have forwarded new versions of IKCKER.BWR and IKCKER.UPD covering
all bug reports and complaints to date about release 4.0 of Kermit-CMS.
The updates are largely, but not entirely, to the generic part of the
code, and some have no effect on CMS operation (they were needed for
the TSO version coming out soon).  Only three of the updates touch on
problems that had no simple workarounds in the original release:

 a. Files of RECFM V being downloaded are no longer trimmed of the
    trailing blanks on TEXT transfers,
 b. the user may now explicitly upload a file to a specific filemode
    (and filemode number) through a Kermit-CMS server, and
 c. there is no longer a garbage message when WARNING is ON and the
    automatic renaming facility runs out of names to try.

The details can be found in IKCKER.BWR for the other changes.

                                     John

[Ed. - Thanks John!]

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

Date: Fri, 5 Feb 88 09:05 EST
From: Pete Kanaitis <[e-mail]>
Subject: Minor problems in Kermit-MS V2.30
Keywords: MS-DOS Kermit 2.30

I wanted to point out two minor problems with KERMIT-MS 2.30.

     The first is about using flow of control.  With flow of control
enabled, (which it is by default), some programs on your DEC hosts that use
^S and ^Q as special characters, rather than XOFF/XON, (such as EMACS) will
get an extra ^S or ^Q sent into the input buffer.  In the case of EMACS, a
^S or ^Q gets sent into the editing buffer.  Depending on your baud rate, I
have noticed that ^Q gets sent into the input buffer at faster baud rates,
(9600), and ^S gets sent at slower baud rates (1200).

This problem did not exist in the 2.29b versions.  I noticed that this
started to occur when the Tektronix code was added to Kermit in the later
2.29c versions.  It was mentioned to me that the serial port handling was
changed when the Tektronix code was added.

A work around for this problem is to set flow of control to none.  But by
doing this, I have found that some of my host characters get garbled at 9600
baud, when long lists go scrolling by on my screen.

[Ed. - The real, though painful, workaround is to SET FLOW NONE before you
start EMACS, and SET FLOW XON/XOFF when you exit EMACS, see below.]

I would like to suggest that this be mentioned in the beware file, unless
that there is some solution for this problem.

The second problem is about starting up Kermit in Tektronix mode on a port
connected to a modem (in my case, a Hayes 1200 external).

First starting Kermit by:
C>KERMIT
IBM-PC Kermit-MS: V2.30  8 Jan 1988
Type ? for help

Kermit-MS>set term tek
Kermit-MS>c

Now try to type a few "AT" commands to the modem.  You may find that you may
have to hit Control-Break once to get the "AT" to work.  Even before that,
you are unable to use Alt-Minus to switch terminal types.

If you already have a host connected to the port, you will not experience
this problem.  If you start up on a modem port (with no connection
established) in VT102 mode, hit Alt-Minus a few times to get into Tektronix
mode, the same problem occurs.  You cannot type "AT" until you hit the
Control-Break once.  Even after that, toggling back to VT102, then back to
Tektronix, and typing "AT" sometimes causes a bell to sound.  (This is *NOT*
the keyboard lock high-pitched bell).

If you have an external modem, you can make this observation.  Once
connected, look at the Transmit and Receive lights on your modem when you
switch into Tektronix mode by pressing Alt-Minus.  You will see the Transmit
light flicker every time you enter Tektronix mode.  I am guessing that this
is where the serial port handling is different.  Is the serial port being
reinitialized at this time?  Maybe this is why I cannot type the "AT" from
Tektronix mode.

I have tested these problems with my modem with both DTR turned on and off.
There was no other resident software on my PC at this time.

Thank you for your time.

Peter Kanaitis
Research Systems Analyst
Allegheny-Singer Research Institute
Pittsburgh, PA 15212
[phone]

[e-mail]

[From JRD -- Pete. Once again, thanks for the extended comments.  Emacs and
flow control: what can I say? If Kermit is permitted to do flow control and
Emacs responds to xon/xoff as commands then one must turn off flow control,
or else move the Search and Quote EMACS commands to to some other keys
besides Ctrl-S and Ctrl-Q.

Speed: the speed/baud rate/code sequences are the same for XON and XOFF so I
don't quite understand your observations unless you are referring to lag
time of the VAX responding to our hand-typed XON/XOFFs.  Please note that
changing screen modes to enter or exit Tektronix graphics emulation involves
a full Bios video Mode Set and that takes a long time with interrupts turned
off. To prevent overruns from the serial port I bracket the mode-set with
XOFF/XON to suspend the host.  Some modems will echo these characters and
thus suspend Kermit for Set Receive Timeout (13) seconds unless SET TIMER
OFF is given.  That is the cause of troubles starting the modem. Bell noises
mean characters were lost in an overrun.  Try SET TIMER OFF before starting a
Tek session since the timer is mainly for (a) packet timeouts and (b) to break
XON/XOFF deadlocks of precisely the kind which you encountered (local and
remote sides tell each other XOFF simultaneously); expect lost characters
during text-graphics screen changes.  It's a limitation of the machine's
architecture.]

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

Date: Fri, 5 Feb 88 19:25:22 PST
From: [e-mail]
Subject: MSKermit on Zenith eaZy-PC Serial (Mouse) Port
Keywords: MS-DOS Kermit 2.30, Zenith Kermit, eaZy-PC Mouse Port

On a Zenith eaZy-PC, there is a built-in serial *mouse* port.  Experiments
had shown that ProComm can use it as a communications port at speed up to
19,200 baud without problem, but MS-Kermit will hang the machine at the
first character.  Does anyone know why?

(To rephrase the question, if a serial port works for a serial mouse *and*
ProComm (at high baud rate), why wouldn't it work with MS-Kermit 2.30?)

BTW, the port address of this only serial port is 0x02F8, if that matters.
Any pointers would be appreciated.

..Sam

Internet: <[e-mail]> or <[e-mail]>
UUCP: {ihnp4!alberta,watmath,uunet,uw-beaver}!ubc-vision!ubc-mts!skl
BITNET: <USERSKL@UBCMTSG>

[From JRD - My Microsoft serial mouse does the same thing when I talk to it
from Kermit while in TEKTRONIX mode (for testing, naturally, since the mouse
is a poor conversationalist). The cause for me is the mouse echoes the
XOFF/XON sent while the screen changes to graphics mode, which is a very slow
process partly done with interrupts turned off.  But communications resume
about 13 seconds (SET RECEIVE TIMEOUT interval) later as Kermit breaks the
XON/XOFF deadlock. Another likely situation is the port does not use the same
Interrupt ReQuest line as IBM machines or even that the mouse driver grabs
material away from Kermit.  Release 2.30/A will help resolve the IRQ business
automatically but can do nothing about aggressive drivers.]

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

Date: Mon, 8 Feb 88 14:59:03 est
From: [e-mail]
Subject: Kermit & OS/2
Keywords: MS-DOS Kermit, OS/2 Kermit

I tried to run MS-Kermit 2.29B and 2.30 under OS/2 in the DOS compatibility
box.  It sort of worked.  I think it might be OK at a slower speed, but this
was at 9600 baud.  Problems include "bell sounds" (Ctrl-G's), and data that
should have been arranged in columns not lining up correctly.  I think the
other side of the connection thought I was sending BREAKS as well.

I have seen similar results on an ATT 6300 running Kermit as a DOS task
under UNIX at 9600 baud and a 6mhz AT running Kermit under Wendin's PC UNIX.
I think the problem in each case is the PC is not fast enough to manage 9600
baud and a 'real' operating system.

There was a plan at one point to merge PC Kermit into C-Kermit.  This might be
the best migration path towards OS/2.

    Stephen Northcutt ([e-mail])

[From JRD -- Slowness is the result of all the overhead of context switching
from protected to real mode which must be occuring once for each received
character. The Control-G Beeps mean the UART received a new character before
the last was extracted - an "overrun" situation.  Microsoft warns of this
effect on 80286 based machines due to the design deficiency of that Intel
chip; 80386's are vastly better.  The context switch to real mode involves a
full reset of the cpu chip (yikes!) and, clearly, interrupts are off;
selected 80286 chips have a faster reset pathway but they seem to be present
or used in fast reset mode only in the PS/2 machines.  Conversion to a full
protected mode OS/2 version of C Kermit is indeed on my mind; that is a lot
of work and costs a few dollars.  I have no direct information on Wendin's
O/S products beyond that stated in a few magazine articles.]

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

Date: Mon, 8 Feb 88 15:36:43 est
From: [e-mail]
Subject: Int 14h, Kermit and Networks
Keywords: MS-DOS Kermit 2.30

The documentation for 2.30 Kermit mentions communicating with the BIOS via
Int14h on some clone PCs.  (much improved documentation by the way, many
thanks).

The documentation for my PC's Bridge Communications Ethernet adapter card
mentions communicating with terminal emulation sw via Int 14.

I read and re-read the Kermit documentation, but could not find out how to
tell Kermit to treat my PC as a clone and use the BIOS.  Finally I modified
line 1548 of MSXIBM.ASM to read "jmp chkpor1".  The resulting Kermit used
the BIOS.  When I Connected the Bridge PCS1> prompt appeared.  With Kermit I
was able to telnet to a host computer.  I was even able to use a Kermit
server on the host computer to transfer a file to my PC.  Kermit at 10 mbs
takes a little getting used to, but I am sure I will.

Have I missed something?  Was there a Kermit command to force use of the
BIOS?  The problem with my version of Kermit is that now it always finds the
Bridge board, not the serial port.

If I didn't miss anything is it an option worth having?  I am under the
impression there are several networking boards and software that allow Int
14 interfacing.  Perhaps an addition to the Set Port command to include BIOS
along with 1 - 4 and NET.  I am even willing to attempt the coding, but be
warned, the MSXIBM.ASM change was my first foray into assembler.

        Stephen Northcutt ([e-mail])

[From JRD -- Stephen.  The story here is Kermit uses the Bios only if a
suitable UART is not available, but not by command of the user.  LAN vendors
have invented a variety of interesting extensions to the serial port Bios
interrupt vector but I do not have documentation from them to do anything
about those methods. The best suggestion currently is to do what you did:
get sources and make a local change; that's one of the reasons for sources
being available.  At least Bridge chose to emulate regular Bios calls rather
than using proprietary settings of registers.  Did Bridge really let you run
TCP/IP's Telenet?  If so we'd really like to know!]

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

Date: Mon 08 Feb 1988 15:39:27 EST
From: <[e-mail]>
Subject: MS-Kermit Tek 4010 Emulation Typeover -vs- Overlay
Keywords: MS-DOS Kermit, Terminal Emulation

>>>>Date: Sun, 10 Jan 88 20:59:48 PST
>>>>From: Ya'[e-mail]
>>>>Subject: MSKERMIT ver 2.29C tektronix 4010 won't overlay ALPHA and VECTOR
>>>>Keywords: MS-DOS Kermit 2.29C
>>>>
>>>>Possible bug with MSKERMIT version 2.29C:
>>>>
>>>>I have been using MSKERMIT vers 2.29C and have encountered a bug (feature?)
>>>>in the Tektronix 4010 emulation mode.  Specifically, alpha mode characters
>>>>will erase and NOT OVERLAY vector mode data.  This frequently causes plot
>>>>titles and labels to obliterate the graphed data.
>>>>P.S. I have an IBM-PC/XT clone with the CGA adaptor.
>>>>
>>>>[Ed. - This seems to be the behavior on the CGA, but not the EGA...]
>>
>>[From jrd - A complete 8 by 8 dot character cell is written for each
>>character, so that both foreground and background colors are maintained and
>>characters can be erased. Supression of the background is being considered
>>but may not be do-able and still maintain the above characteristics. If
>>annotation is done first then the problem does not occur. I'd like
>>overlaying too.]

I have already undone this 'improvement' to the Tek 4010 emulator in my copy
of kermit (2.30).  It involved only about a half dozen lines in the
MSGIBM.ASM file.

                                 Stuart Scharf (SS@LL)

[From JRD - Making the change in the code is easy.  The reason for doing it
my way is explained above, mostly erasure (after all, we are a few years
beyond punched cards and paper tape).  The Tek storage tube characteristic
of overwriting everything is messy in today's environment, especially with
my typing skills.  If the Kermit community would rather have the overwriting
then I'll remove the full cell approach and hence erasures.  What's the
consensus?]

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

Date: 10 Feb 88
From: Robert W. Lane, Iowa City, IA (via US mail)
Subject: IBM PC MS-Kermit vs Datatronics Internal Modem
Keywords: MS-DOS Kermit 2.30, Modems

I have a Datatronics internal modem, 1200 baud, and I'd like to configure
it as COM3 at 03E8h using the 8259 interrupt line IRN4 (also used by COM1).
MS-Kermit 2.30 will let me access this modem using SET PORT 3 after running a
short program called SETCOM3 in order to update memory at 40:0000h with the
address of the modem.  Unfortunately, this modem is built around a 8031
microprocessor and when Kermit tries to ascertain whether or not the port found
in 40:0000h has an 8250 async controller, it fails and prints a message that
all calls will go through the Bios.  Is there any way to make Kermit skip this
test and just use the interrupt vector at IRQ4 (at 0030h)?

[From JRD -- Selecting an IRQ (4 in this case) is only part of the story.
Kermit needs to talk with the UART chip to set/get the baud rate, send/receive
characters, and so forth, and thus Kermit needs to know a lot about the UART.
That is why the tests are done before activating a serial port and why the
Bios is used if an 8250 chip is not found. If the Datatronics modem has such a
specialized pseudo-UART then only software tailored to it can be expected to
function. You might wish to query the manufacturer about this situation.]

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

Date: Thu 18 Feb 88 11:43:24-PDT
From: [e-mail]
Subject: MS-DOS Kermit Using EGA 43 Line Mode
Keywords: MS-DOS Kermit 2.30

I've found a couple of bugs in MS-Kermit 2.30 for the IBM when using EGA 43
line mode, I'm going to try to look at the code when I get a chance, but in
case someone else fixes it first (or jrd has already fixed them!):

    1. The cursor is a dash after exiting connect (I saw the note in
    MSKERM.BWR, it's kind of a pain to have to run a program to fix the
        cursor every time you pop in and out of kermit.

    2. The STAT command doesn't clear the screen, it starts from the top
    but leaves stuff at the bottom.

    3. Scroll up doesn't work, it only goes 3 lines and only once. I tried
    to fix this in 2.29, but gave up when I heard 2.30 was imminent, hoping
    it would be fixed.


                    Mike Pawka
                    [e-mail]

[From jrd - Mike, EGA 43 line mode stuff. Thanks.

Cursor is a dash after exiting Connect mode. This appears to be an EGA board
problem. IBM had bugs in their original EGA boards and Kermit takes steps to
avoid it within Connect mode. However, testing here with a Video 7 EGA board
in all kinds of strange screen modes indicates no problems.

Similarly, the lack of screen clearing for the STATUS command does not
appear here. I just check the item by going into 43 line mode to write this
note. If you are letting ANSI.SYS be active then it knows only 25 lines
whereas in Connect mode Kermit takes charge.

Only 3 lines on Scroll Up commands. That means Kermit found insufficient
memory for screen buffers and Command.com together so sacrificed buffer
space to allow subsidary tasks to be run via Command.com.  Use CHKDSK or
Kermit's SPACE command to see the total free memory. However, memory space
is easily fragmented by loading TSR's.

What brand of EGA board and machine are you using?]

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

Date: Monday, 22 February 1988 10:24am EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Toshiba T3100 versus MS-Kermit Tek Emulation
Keywords: MS-DOS Kermit 2.30, Terminal EMulation, Toshiba Kermit

It has come to our attention that Tek Emulation doesn't work on the
Toshiba laptop.  Not only doesn't it work, it hangs the machine so badly
that only powering it off and on will revive it.  It seems that the Toshiba,
although apparently IBM compatible in other respects, requires a special
function call to put it in graphics mode.  The question is, how can MS-Kermit
tell, at runtime, that it is running on a Toshiba 3100, rather than a real
IBM PC?  Is there a ROM location that has a unique machine identifier?

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

Date: Fri, 19 Feb 88 00:56:53 EST
From: [e-mail] (Charles Hedrick)
Subject: C-Kermit on sys-V Based PCs
Keywords: C-Kermit 4C(058)

Re: Info-Kermit Digest V7 #6

Because of the question about Kermit on various sys-V based PC's, I
thought I'd confirm that version 4C(058) works without any
modifications on Microport System V/AT, which is Sys Vr2 for a PC/AT.
I compiled it as sys3nid.  (There is no need to request separate I&D
space.  You always get that effect.)  Microport supplies 4D, which
also works fine, but I built 4C (the most recent source we had lying
around at Rutgers) because I like to have my major applications
programs built from source.  (Of course I have no way to know what
Microport may have done to bring up 4D.)

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

Date: Wed, 17 Feb 1988  23:03 MST
From: "Frank J. Wancho" <[e-mail]>
Subject: Using TOPS-20 Kermit with 9-Bit Files
Keywords: TOPS-20 Kermit

The KCC DEC-20 C compiler defaults to 9-bit files when you create a file
with "wb" for its own reasons - the internal character types are 9-bit, and
four 9-bit quantities on a read will properly pick up all 36 bits in a
PDP-10 word.  However, all you have to do is change the "wb" in the open to
"w8" and you will get the expected behavior, i.e. 8-bit files which DEC-20
Kermit can recognize automatically.

[Ed. - Thanks, Frank!  Your message has been added to the DEC-20 Kermit
"beware file".]

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

Date: Fri, 19 Feb 88 14:13 +1000
From: Andrew Hunt <munnari!rpepping.oz.au![e-mail]>
Subject: Re Mark Zinzow's request for MicroBee Kermit
Keywords: MicroBee Kermit, CP/M Kermit

Yes CP/M Kermit does run on a MicroBee - a colleague of mine has one
and uses kermit betweem it and his PC.  He warned that the only problem
he had found occurred when using the optional dual serial line (SCC)
ports on the memory card in place of the one on the mother board.  In
this case there are 3 serial ports on the machine which confuses the
poor wee beasite - solution is to disable the single mother-board port
and then all performs well up to 38400 Baud.

There exists - somewhere in the vicinity of "Public Domain" - a program
called PC-Alien (incl PC-Alien Jnr and MSA) for reading foreign CP/M and
MS-DOS diskettes on ordinary PCs.  This includes support for MicroBee
format 360KB diskettes and I have successfully used it for reading and
writing such.

Regards ...Andrew HUNT,   CSIRO Radiophysics, Australia.

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

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

-------
18-Mar-88 19:11:26-EST,18173;000000000001
Mail-From: SY.FDC created at 18-Mar-88 19:10:22
Date: Fri 18 Mar 88 19:10:22-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V7 #8
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 18 Mar 1988       Volume 7 : Number 8

  ANNOUNCEMENTS -
        Announcing IBM Mainframe MVS/TSO Kermit Version 4.0
        Announcing Kermit 2.30 for the RMX86 and RMX286 Operating System
        New Release of Harris-100 Kermit
        Announcing a New Kermit for Kaypro I
        C-Kermit Amiga Un-BOOing Bug Fix
        New Kermits on the Way from the UK
        ASCII, ISO, and which EBCDIC?

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

Date: Wed, 1988 Mar 16  16:55 EST
From: (John F. Chandler) [e-mail]
Subject: Announcing IBM Mainframe MVS/TSO Kermit Version 4.0
Keywords: IBM 370 Kermit, MVS/TSO Kermit, TSO Kermit
Xref: IBM Mainframe, Also see IBM 370
Xref: MVS/TSO Kermit, Also see MVS/TSO Kermit, IBM 370

This is to announce TSO Kermit Release 4.0.  The program is now a member of
the generic family Kermit-370 and appears in the Kermit distribution under a
new prefix: all TSO-specific files begin with IKT, while generic Kermit-370
files begin with IK0 (I K Zero).  Kermit-TSO no longer consists of just two
source files.  Instead, the source is split into sub-files, some generic and
some TSO-specific.  The separate pieces are to be recombined into a single
composite source (or made into a macro library) for installation.  See the
file IKTKER.INS for instructions.  Generally, the files formerly known as
TS*.* (except TSN*.*, the NIH version) will be replaced by the new IKTKER.*
files.  This TSO Kermit is still in the testing stage, but most of the
features described in the documentation have already been verified.  Any bug
reports should be sent to John Chandler <[e-mail]>.

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

    --- generic features (same as announced for CMS last December) ---

1.  Code reorganization into generic 370 and system-specific sections.

2.  Optional separate translation tables for counteracting the system
    conversion of terminal I/O.

3.  New GIVE command for saving a modified translation table.

4.  A new, RAW debug mode for recording the packet traffic as actually
    sent and received on "GRAPHICS" and "SERIES1" devices.

5.  Preservation of the case of commands as typed, with uppercase
    conversion of only those words that must be uppercase.

6.  New SET MARGIN command for limiting the width of a file to be sent.

7.  Settable tab stops for Kermit's conversion of tabs to spaces
    (alternative to the default 1, 9, 17, etc.).

8.  Support for multiple terminal controller types.

9.  New DIRECTORY and HOST subcommands following Kermit standard.

10. Combination of file-attribute SET subcommands (FILE-TYPE, LRECL,
    BLKSIZE, and RECFM) into a new group SET FILE.

11. Separate retry limits for initial and subsequent packet exchanges.

12. Pad binary records on disk with nulls, rather than blanks.

13. Automatically tune packet length when sending long packets according
    to heuristic optimum based on sparse Poisson statistics, provided
    that transmission errors do occur.

14. Expand STATUS report to include the number of files in the last
    transfer, throughput statistics, heuristic optimum packet length
    (when long packets are enabled), and the reason for any file
    rejection based on A-packets.

15. New command TDUMP NAMES to display the list of files sent in the
    last transfer.

16. Send and acknowledge attribute packets.  Add file creation date to
    A-packet repertoire.

17. REMOTE COPY and REMOTE RENAME commands to a server at the other end.

18. Allow long packets through a 7171 with VTAM.

19. New type D-BINARY for binary files with undelimited variable-length
    records.

20. SET 8-BIT-QUOTE.  Allow 8-bit data where possible via SET PARITY.

21. SET SYSCMD, so that Kermit can be told to try "illegal" subcommands
    as host system commands instead of just rejecting them.

22. SET PROMPT subcommand.

23. Remember parameters specified by the other Kermit in I-packets.

24. Keep track of truncated records during a RECEIVE operation and
    report the count in STATUS; also call truncation an error after
    everything is received.

25. SET HANDSHAKE subcommand to alter or suppress handshake character
    Kermit-370 sends out after each packet (not available for 3705's).

    --- features new to TSO Kermit ---

Since Version 4.0 is the first release of Kermit-370 for TSO, some of
these "new" features are actually new only to the Columbia distribution
for TSO.

26. Suppression of LINE and CHAR delete functions during protocol mode.

27. Advanced server functions and subcommands for talking to another
    Kermit running in server mode.

28. Long packet protocol.

29. TYPE, ECHO, XTYPE, and XECHO subcommands (the last two being
    Series/1 analogs of the first two.)

30. REMOTE KERMIT commands honored by TSO server, including SET, SHOW,
    TAKE, TDUMP, STATUS, HOST, TSO, CWD, DIR, and TYPE.

31. TEST mode for debugging.

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

33. Optionally append to, rather than replace, old data sets with
    duplicate names.

34. Automatic detection of terminal controller type (TTY or SERIES1).

35. SYNADAF message in cases of disk I/O error.

[Ed. - This a major new Kermit release, one that many sites have been craving
for years.  At last, a single TSO Kermit that brings together most of the
capabilities of TSOKER (linemode only), TSOS1 (full-screen only), TS2KER
(long packets, etc), TS3KER (3708 front end support), etc, etc, plus all the
advanced features of VM/CMS Kermit, plus the ability to easily add support
for other IBM 370 operating systems, like MTS, MUSIC, GUTS, etc.  As John
points out, this version may not yet be fully debugged, especially on the
more esoteric front ends, so reports -- good or bad -- from testers are more
than welcome.  The files are in the Kermit distribution as KER:IK0*.* (system
independent files, shared by VM/CMS Kermit), and KER:IKT*.* (TSO-specific
files), available via anonymous FTP from CU20B.COLUMBIA.EDU, and available on
BITNET/EARN via KERMSRV at CUVMA ("TELL KERMSRV AT CUVMA HELP") as IK0* * and
IKT* *.  Once the kinks, if any, are ironed out, this version will replace
TSOKER, TSOS1, and TS3KER in the Kermit Distribution.]

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

Date: Thu, 17 Mar 88 14:17:42 PST
From: [e-mail]  (Jack Bryans)
Subject: Announcing Kermit 2.30 for the RMX86 and RMX286 Operating System
Keywords: iRMX86, iRMX286, Intel RMX
Xref: RMX, see Intel

This is to announce version 2.30 of Kermit for both the iRMX86 and iRMX286
Operating Systems.  It is the first release for iRMX286 and the first since
late 1985's version 2.26 for iRMX86.

This is the same program, ported to the RMX's, as the Jan. 8,1988 release of
MS-Kermit, version 2.30, for the IBM PC, which is probably the most widely
used and richest Kermit implementation.  A DOS emulator provides enough of
the DOS environment to allow the essentially unchanged MS-Kermit code to run
under both of the RMX Operating Systems.  For a summary of changes on the
MS-Kermit end, see the KERMSRV files MS*.UPD.

From the RMX end, this version includes support for wild cards, full RMX
paths and file names, and removes restrictions on the use of RUN.  You can
now RUN AEDIT from within Kermit.

As a fortuitous fallout to wild card implementation, a list of file names may
be used wherever Kermit accepts a wild card file specification, as long as
all files in the list are in the current default directory.  For example:

SEND READ.ME.FIRST,*X*.A*,*.OBJ,ETC.ETC

works.  Try to say that in DOS!  Similarly, when Kermit is in SERVER mode, it
will respond to a GET file-name-list from the local Kermit.

The SET and SHOW KEY commands have been added.

Configuration has been completely redone, with its implementation separated
from the Kermit initialization file.  To avoid confusion with the previous
version, the .ini file name has been changed to KERMIT.INI.  A good dozen
configuration options are available, reducing the need to obtain the source
code.

Serial ports have been increased to ten, with all requirements and
restrictions on device attachment removed.  Additionally, you can ping-pong
between serial communication ports and the port your terminal (in this case,
presumably, a PC) is attached to, with the file transfer display
automatically set to QUIET mode (necessary for one port operation) and reset
to its previous mode when you select another port.

Performance has been improved in a number of areas, especially in connect
mode.  Improved serial device drivers scheduled for release in forthcoming OS
updates from Intel (RMX286, Release 2, Updates 1 and 2, and RMX86, Release 8)
will improve Kermit performance significantly on both OS's, especially on
faster systems.

A number of timing problems peculiar to '386 based systems have been cleared
up in the past month.  Feedback from '386 beta testers indicates performance
more than impressive enough to make 8086 users, appropriately, green with
envy.

The following files constitute this release:

MSVRMX.BOO  BOO-encoded executable Kermit for RMX86
MSVRX2.BOO  BOO-encoded executable Kermit for RMX286

MSVRMX.DOC  Documentation for both OS's

MSVRMX.HLP  How to build Kermit for either OS from source code
MSVRMX.CSD  The edit pass SUBMIT file.  \ Converts MSSDEF.H & MSS*.ASM
MSVRMX.MAC  The edit pass macro file.   / to MSSDEF.H86 & MSS*.A86
MSURMX.A86  Source code for the keyboard support module for RMX
MSXRMX.A86  Source code for the traditional "X" module for RMX
MSZRMX.A86  Source code for the DOS emulator and Kermit driver
MSVRMX.P86  Source code for the wild card implementing auxiliary command, WC

Note that all files but the enBOOed executables apply to both OS's.  The edit
pass generates submit files for conditional assembly and for linking or
binding the object modules to produce an executable for either OS.

The MS-Kermit files, MSKERM.DOC, MSKERM.HLP, and MSKERM.BWR provide primary
documentation for all version 2.30's.

Acknowledgments:

Joe Doupnik of Utah State University, who has been responsible for MS-Kermit
starting with version 2.29, was most accommodative in making changes to the
DOS code to simplify things for the RMX portings.

Among the beta testers, Steve Cox of Milliken Research Corp., Chris Jamison
of Ransburg Corp., and especially Chris Vickery of Queens College, NY,
provided valuable feedback.  Henning Pangels of Carnegie-Mellon University's
Robotics Institute showed up in the nick of time via e-mail, innocently
inquiring if there was an RMX286 Kermit he could try out on his brand new
'386.  His response to being pressed into guinea pig duty is appreciated.

Mark Aaldering of Intel made the port to RMX286 possible.  Thanks also to
Intel's Paul Cohen, Rick Gerber, and Tom Willis, and, with apologies, to
those overlooked.

[Ed. - Thanks, Jack!  These files are now in the Kermit Distribution under
the names you've listed.]

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

Date: 17 Mar 88 0:0:0
From: [e-mail]
Subject: New Release of Harris-100 Kermit
Keywords: Harris-100

Enclosed is the lastest revision of the Harris 100 Kermit (H100KER.*) which
I sent you last year.  Revisions include miscellaneous minor bug fixes and
better handling of embedded End-of-file marks.  This brings the current
version number up to 1.06 (June 87).  The program has been tested for
compatability with MSKERMIT 2.30.  See the .DOC file for more details.  A
list of the changes made in each version can be found near the end of that
file.  This will be my last version of Harris Kermit, since, tragically, our
Harris is scheduled to expire in a few weeks.

The files are as follows:

   H100KER.DOC  -- documentation file (contains usage info, technical
                   info, revision history, "bewares", etc.)

   H100KER.JCL  -- Harris JCL for compiling

   H100KER.F77  -- Fortran code

   H100KER.ASM  -- Assembler code

   H100KER.HLP  -- On-line help file (sent in response to REMOTE HELP)

To bring your "version" file up to date, the operating system we are using
is now "VOS 5.1.0".

Skip Russell
Division of Biostatistics, Washington University in St. Louis

[Ed. - Thanks, Skip!  The files are now in the Kermit distribution as
KER:H100*.* (H100* * on KERMSRV).]

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

Date: Wednesday, 17 February 1988  05:00-MST
From: "Paul V. Pullen" <[e-mail]>
Subject: Announcing a New Kermit for Kaypro I
Keywords: Kaypro I Kermit

I have successfully completed the creation of a new version of Kermit for my
Kaypro1.  I have an LASMed hex file to be included in the SIMTEL20 Kermit
data that will enable others using the Kaypro1 to work successfully with a
proper (or at least my copy works properly now).  I had to create a special
'log' in the CP4TYP and CP4SYS asm files.  I did it by adding another
defination, being a kp1, and setting terminal type to ADM-3A, which is the
proper look alike for the Kaypro1.  Then, to work properly with my Base Vax,
I used the TERMCAP for an ADM3A and named it a kp1|kaypro1|Kaypro 1|.  The
effect is a fully operational termcap for my system, and support on the VAX.

One requirement to make the upload-download (especially download) to operate
properly was the reduction of the 'maxsec' to 4K from 8K in CP4SYS.  The
requirement to make the kaypro1 kermit to run will be to mload CP4KER,CP4KP1
together, and the resulting kermit works properly here at least.

Paul Pullen
(address: [e-mail])
(Snail mail:  8100 Sagramore Road
              Baltimore, MD. 21237)

[Ed. - Thanks!  The hex file is in KER:CP4KAD.HEX, and some documentation in
KER:CP4KAD.HLP.]

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

Date: 25-FEB-1988 16:50:15 GMT
From: [e-mail]
Via: [e-mail]
Subject: C-Kermit Amiga Un-BOOing Bug Fix
Keywords: Amiga Kermit, Commodore Amiga

I have now successfully installed KERMIT on the Amiga from the CKIKER.BOO
file, using the programs suggested by W.Maessen for initial transfer of the
.BOO file.  To perform the translation of the .BOO file to an Amiga executable
file, I use the C program CKIBOO.C. However, I feel I should point out two
problems with CKIBOO.C which prevented it compiling under Lattice 3.1.

Firstly, the preprocessor IF nesting in lines 26 to 39 is WRONG - the #endif
at line 30 should appear after line 39. The program thus failed to compile as
it ended up looking for <sys/file.h> in line 37.

Secondly, the preprocessor IS cas3 sensitive and all #commands must be in
lower case. Thus the #IFDEF and #ENDIF lines in the last 10 lines of the
program should be in lower case.

I have appended the corrected version of CKIBOO.C and hope this will alleviate
a few hours of frustrating debugging for other users.

Andrew C.R. Martin,
Laboratory of Molecular Biophysics,
University of Oxford,
U.K.

The ammended version of CKIBOO.C was tested under Lattice C V.3.10 and
Kickstart 1.2 on an Amiga 1000.

[Ed. - Thanks!  This program is now in KER:CKIBOO.C in the Kermit
distribution.]

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

Date: 15-MAR-1988 12:36:45 GMT
From: [e-mail]
Subject: New Kermits on the Way from the UK
Keywords:  MINIX Kermit, CP/M-80 Kermit 4.09, Acorn Archimedes

Some good news for you. I have just received a kermit for the MINIX.  It is
based on C-Kermit 4D (061) sources and the author Adria Godwin of Thorne EMI,
has made a commitment to update it when we have all the files for 4E (070).

I am also in the process of getting CP/M-80 Kermit 4.09 files off to you as
they are now on line here with no problems as yet reported.

Last but not least Acorn have at last supplied the Archimedes Kermit. They
have, unfortunately supplied in a format that will take some work to get on
line but I'll forward them ASAP.

                    Regards,
                        Steve

[Ed. - This message published in case anyone else was thinking of working on
any of these items.  There are also some other Kermits due for new releases
shortly, including Apple II, Apple Macintosh, and Os9.]

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

Date: Mon, 14 Mar 1988 08:45:21 +0100
From: Andre PIRARD <[e-mail]>
Subject: ASCII, ISO, and which EBCDIC?
Keywords: Translation Tables, Character Sets, ASCII, EBCDIC

We ASCII or EBCDIC network users must pay particular attention to character
codes standards, now extending to international. Even sites not interested in
in international characters will sooner or later hit the problem because,
albeit the situation is straight in the ASCII world with an ISO standard, it
is far from that for EBCDIC users faced to a choice of several codes whose
differences lies on a few codes, strangely enough not international.

The subject is discussed on a mailing list set up by Edwin Hart. Join with:

  TELL LISTSERV AT JHUVM SUB ISO8859 user-name

Or sending a note on BITNET to: LISTSERV AT JHUVM
Containing:                     SUB ISO8859 user-name

can help the community agree on a viable single code or at least help each
site in finding its most appropriate one and save everybody's time and money.
I'll soon post a summary of the problem to that list.

Please forward this note to anybody interested.

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

End of Info-Kermit Digest
*************************
-------
22-Mar-88 14:05:43-EST,22558;000000000000
Mail-From: SY.CHRISTINE created at 22-Mar-88 14:04:36
Date: Tue 22 Mar 88 14:04:35-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #9
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 22 Mar 1988       Volume 7 : Number 9

Departments:

  ANNOUNCEMENTS -
        Announcing Kermit-65 3.81 for Apple II DOS and ProDOS
        Announcing Os9/68k C-Kermit 4E
        Announcing MS Kermit v2.30 for the NEC APCIII
        Results of Porting C-Kermit 4E and Fixes

  MS-DOS KERMIT -
        MS-Kermit 2.30: Question & Bug?
    MS-Kermit 2.30 vs Internal Qubie Modem
        MS-Kermit Block Check Bug?
    MS Kermit V2.30 Problem on PS/2 Model 60
        MS-Kermit 2.30 Use over Ethernet LAN
        Kermit v2.30 and Hayes Modem Query
        A few Notes on MS-Kermit 2.30

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

Date: Tue, 16 Feb 88 14:09:53 PST
From: Ted Medin <[e-mail]>
Subject: Announcing Kermit-65 3.81 for Apple II DOS and ProDOS.
Keywords: Kermit-65, Apple II Kermit

Ok, here is version 3.81 for the Apple II, DOS and ProDOS.
The significant changes between 3.79 & 3.81 are as follows:

1. gs keypad support for vt100 mode
2. print screen function for //e or better
3. cursor keys can become vt100 cursor keys
4. improved initial prefix get - thanks to Sean Noland
5. file transfer now supports wildcard sends - thanks to Dick Atlee
6. server mode improved
8. new manual, APPLE.DOC (from APPLE.MSS).

[Ed. - Thanks, Ted.  The new release is in the Kermit Distribution as
KER:APP*.* on CU20B.COLUMBIA.EDU, available via anonymous FTP, and on
KERMSRV at CUVMA as APP* *, for BITNET/EARN access.]

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

Date: Mon 22 Feb 88 00:28:49-PST
From: Bob Larson <[e-mail]>
Subject: Announcing Os9/68k C-Kermit 4E
Keywords: Os9 Kermit, C-Kermit

Os9/68k ckermit is functionaly identical to UNIX C-Kermit, with a few minor
problems noted in ck9ker.bwr.  Support for Microcom modems has been added to
ckudia.c.  Thanks to Peter Scholz of the Ruhr Universitaet Bochum for his
incomplete port of an earlier version of C-Kermit, some of which survives in
ck9tio.c and ck9fio.c.

This is the most complete of the three families of Kermit for Os9/68k.  The
original (based on old unix kermit) is still needed for Os9/6809.  (A new
version has been mentioned on Compuserve.)   There's also the assembler
version from Italy, but it's primarily intended as a portable 68000 Kermit,
with Os9 support included as an example of how to implement it for a
particular system.

[Ed. - Thanks, Bob!  Your files are in KER:CK9*.* on CU20B, and CK9* * on
CUVMA.  The diff files have been combined together into a single file,
CK9KER.DIF.  The indicated changes were not applied to mainline C-Kermit, but
will probably be included in the next release of C-Kermit.]

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

Date: Mon, 21 Mar 88 10:45:20 est
From: Robert F. Goeke <[e-mail]>
Site: MIT Center for Space Research, Cambridge Mass.
Subject: Announcing MS Kermit v2.30 for the NEC APCIII
Keywords: NEC APCIII

        I was a little surprised to find out a week ago that v2.30 of MS
Kermit had gotten released in January -- not having heard from anyone since
last summer.  Nevertheless a bit of fast keyboarding brought the NEC community
back up to date.  The current version for the APCIII does everything the IBM
one does -- including the Tektronix emulation -- with the following
elaborations:

        a)  The graphics are 640 x 400 in your choice of green, no
        matter what the text screen color is.

        b)  The graphics are not saved during mode switch.

        c)  The function performed by Shift-Arrow during cursor control
        is done by Control-Arrow on the NEC (shift arrow doesn't emit
        a unique key code here).  I'm not sure this is even mentioned in
        the manual, but the msg code made it clear.  Furthermore, the APCIII
        use the "real" arrow keys for this function, not the 2-4-6-8 set.

The remaining comments in the manual concerning the NEC APCIII implementation
are still all correct.

The files for the APCIII implementation are: available via anonymous

        msgap3, msuap3, msxap3, msyap3, and mszap3 (all .asm)  for source
and
        msvap3.boo                                             for executable

                                        Bob Goeke
                                           [[e-mail]]  or
                                           [...!seismo!space.mit.edu!goeke]
                                        MIT Center for Space Research
                                        Cambridge, Massachusetts  02139
                                        617-253-1910

[Ed. - Thanks, Bob, and sorry for the crossed signals.  The files listed
above are now in the Kermit distribution.]

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

Date: Sun, 28 Feb 88 02:47:21 EST
From: [e-mail] (Charles Hedrick)
Subject: Results of Porting C-Kermit 4E and Fixes
Keywords: C-Kermit 4E

I just finished porting Kermit 4E to my Microport System V/AT.  As usual,
simply typing "make sys3nid" (which is the setting for vanilla System V,
oddly enough) works correctly.  It works correctly in the sense of building
a kermit that works the same as it works on other systems.  Unfortunately,
the major new feature in 4E turns out not to work on any of the systems I
have access to.  This is the long packet size feature.  The two kermits
exchange information about what options they support.  Unfortunately, the
code used for generating the byte that contains the capabilities appears to
be wrong.  It results in having the systems say that they don't support long
packets.  The expression is a long one involving several ? : constructs.  My
C documentation does not make clear what the relative precedence of ?  and |
should be.  However both the Sun 3 and System V 286 compilers take the
opposite view from the authors of C Kermit.  By adding a few ()'s, we avoid
the ambiguity.  There was also a problem that the packet size sent for the
benefit of old systems that don't support long packets was miscalculated.
THey simply took the low-order byte of the full packet size.  What they
wanted was MIN (packetsize, 94), 94 being the maximum size allowed by old
implementations.

The fixes are shown below.

This message is being sent to be info-kermit and the Microport newsgroup.
For the benefit of Microport users, let me note that Microport supplies a
fairly recent version of kermit with the system, version 4D.  The version
being discussed here adds only the long packet support.  (You might still
find it useful to get the files, since Microport doesn't seem to supply
documentation.)  Kermit is available via anonymous FTP from
CU20B.COLUMBIA.EDU.  The files you need are roughly ker:ckc*.*, ker:cku*,
and ker:ckw*, but ker:ckaaaa.hlp will give me information.  Kermit is also
available at Simtel20.  The index I have claims it is pd2:<unix.kermit>,
although today I was unable to get to those files to check them.

[Ed. - Thanks, Chuck!  Always wondered how long it would take to drag you
into Kermit maintenance...  Your changes have been added to the "beware
file" for now, and will appear in the next release.]

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

Date: Tue, 2-Feb-88 19:41:52 WET
From: [e-mail] (Ronald Soo Han Khoo)
Subject: MS-Kermit 2.30: Question & Bug?
Keywords: MS-DOS Kermit 2.30

In comp.binaries.ibm.pc recently:

>From: [e-mail] (27-Jan-1988 1454)
posted a distribution version 2.30 of kermit.

1) QUESTION:

    Does anyone know if its possible to defeat the auto-detect of graphics
adapter type? (we run a service here with lots of m/cs with ega-type cards
emulating hercules, so its kinda inconvenient for the inexperienced users to
keep switching the emulation software around)

2) BUG ???

The documentation posted with it mentions that ctrl-]<space> returns the
terminal emulator to text mode from tektronix emulation mode.  This doesn't
seem to work in the version posted, but oddly, DOES on an older development
version (2.29C@cambridge).  Does anyone know anything about this ?

Duncan White,        |
Dept. Of Computing,  |    Flying is the art of aiming oneself
Imperial College,    |    at the ground and missing.
London, SW7.         |        -- Douglas Adams, So Long and Thanks
England.             |           for all the fish.

[From jrd - Hercules mode on EGAs: see comments below. Escaping from Tek mode
is well documented in the MS Kermit 2.30 manual; the quick way is to toggle
the terminal type via ALT minus (verb \Ktermtype).]

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

Date: Thu 18 Feb 88 14:29:26-CST
From: Clifford A. Wilkes <[e-mail]>
Subject: MS-Kermit 2.30 vs Internal Qubie Modem
Keywords: MS-DOS Kermit 2.30, Internal Modem, Qubie Modem, Sperry PC

I have a Sperry (IBM clone) with an internal Qubie 300/1200 baud modem.
I have been using KERMIT 2.26 which allows me to dial out via:

MS-KERMIT>connect
at
OK  (KERMIT response)
atdt9999999  (simulated number)

With version 2.30 only after booting (warm or cold) the first time entering
AT (capitals only) gets the OK response.  Subsequent attempts receive no
response from Kermit.  And no matter what I do (ATDT in caps for example)
the modem will not 'dial'.  With all of the new features I was wondering if
there aren't some switches that I should set specially.  The modem is Hayes
compatible.  I'm using port 1 and 1200 baud.

Any assistance will be appreciated.

[From jrd - What does SHOW MODEM indicate? Could you have a conflict with
another board using the same address or IRQ (4)? Any messages from Kermit,
such as using the Bios? And, are there any other "Helpful Utilities"
running?  Pretty standard questions, naturally, but version 2.30 does work
with internal modems.]

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

Date: Tue 16 Feb 88 19:29:38-EST
From: Charles Lasner <[e-mail]>
Subject: MS-Kermit Block Check Bug?
Keywords: MS-DOS Kermit 2.30, PDP-8 Kermit

Found a bug in MS-KERMIT (any version):

Set MS-KERMIT to Server Mode (might not be necessary but I found it this way)
using K12MIT which has no options as the local KERMIT I use GET FILESPEC
the MS-KERMIT end had SET BLOCK 3

THE K12MIT end only supports type 1

All transmissions fail with many retries in both directions. It appears the
MS-KERMIT end fails to negotiate down the BLOCK-CHECK TYPE back to 1. If the
BLOCK CHECK is set to one at the MS-KERMIT end, then all works fine. This is
a oneway bug.

The user settings of BLOCK CHECK are not to be the final used value, just the
starting point. When MS-KERMIT presents a 3 and K12MIT presents a 1, the 1
should win!

[From jrd - Tested MS Kermit against C Kermit and VMS/BLISS Kermit with MS
Kermit using Block Check 3 in server mode and the other two as requestors
with Block Check of 1. Files transferred just fine and the logs show type 1
Block Checks, as it should be.]

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

Date: Tue, 23 Feb 88 13:13:53 PST
From: [e-mail]  (Stephen Walton)
Subject: MS Kermit V2.30 Problem on PS/2 Model 60
Keywords: MS-Kermit 2.30, PS/2

I haven't seen this reported before, so here goes: I recently used MS-Kermit
V2.30 on a friend's brand new IBM PS/2 Model 60.  For the record, it has all
IBM equipment: 44 MB hard disk, 1 MB RAM, and VGA.  My own floppy was the
only disk I wrote to.  Everything seemed to go fine with the file transfers,
and I shut off the machine when I was done.  The next morning, to our
horror, the PS/2 wouldn't boot!  A reboot with the IBM-supplied setup
diskette revealed that the system configuration was bad; specifically, the
system time had been corrupted.  A strange problem.  Any ideas?

  Steve Walton, formerly of Ametek, now at Cal State Northridge

[From jrd - Kermit does not mess with (read or write or even know about) the
CMOS setup and clock nor does it even dream of setting a system clock. So,
it is another system effect unrelated to MS Kermit.]

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

Date: Thu, 18 Feb 88 11:13:42 EST
From: [e-mail] (Bob Napier)
Subject: MS-Kermit 2.30 Use over Ethernet LAN
Keywords; MS-DOS Kermit 2.30

I'm configuring a network of IBM PS/2's and a Microvax 3500.  I need to run
an application on the MicroVAX from the pc's over Ethernet with Tektronix
40xx emulation.

The network board I'm considering for the pcs is 3com Etherlink/MC and
Novell Netware software. The MicroVAX will have an Ethernet interface
adapter and the networking software is still up in the air.

Question: Will Kermit 2.3 support MicroVAXen over Ethernet??  That is, is
there a corresponding version of Kermit for the VAX to act as a server to the
PS/2s??

Thanks,

Bob Napier ([e-mail])
615-576-4547

[From jrd -- Bob, joining the MicroVax to PS/2's on a Novell NetWare LAN is
a little more complicated than plugging things together. The main concern is
getting the MicroVax to speak NetWare (IPX packets to be precise) so I
presume you are using a bridge or TCP/IP. MS Kermit readily talks across
NetWare using their NetBios emulator. If you are using 3Com's TCP/IP package
then I'd have to talk with 3Com about their mechanisms of bridging out of
the LAN.  However, the other approach is to make the MicroVax regard the LAN
connection as a regular login port. In that case MS Kermit could speak to
the MicroVax directly as a terminal (across the LAN in packets and all) just
as I do to my Unix box with STARLAN. Check with 3Com and/or have them give
me a call at [phone] (days, MST) to sort out the affair.  If it makes
any difference a lot of people want similar functionality: from PC on a LAN
to their larger host via Ethernet or whatever.]

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

Date: Wed, 2 Mar 88 14:05:16 CST
From: [e-mail] (Moore)
Subject: Kermit v2.30 and Hayes Modem Query
Keywords: MS-DOS Kermit 2.30

I'm having a problem executing a remote command using Kermit; I hope someone
can help:

I have a server on the west coast running MS Kermit 2.30 on a Compaq with a
Smartmodem 2400, and my local machine is a 248 with a Zenith 2400 modem.  My
problem is this: I need to be able to not only shut the server down on the
west coast (no problem there), but also shut the modem off remotely.  I've
tried writing the string ATS0=0 (disable autoanswer) to a file called
SHUT_UP.TXT, then writing to a batch file shut_up.bat the command COPY
SHUT_UP.TXT COM1: I then upload both files to the server, and issue the
kermit command remote host shut_up, which should copy ATS0=0 to com1: Well,
I've tried it locally, and the "server" echoes the command and replies "1
file(s) copied" so the copy is working right, only the modem doesn't come
out of autoanswer, and when I query ATS0? I get back a non-zero number (the
default).  I've also tried directing ATZ to the modem, with no success.  Yet
when I run the batch file on my machine, as well as the "server", it works
fine...

Any help?  (Please!?!)

[From jrd - The modem can be shut down (turning off auto-answer mode) by
first placing the modem in "command" mode with the Hayes " +++ " sequence
(with 1-second pause before and after) and then issuing the ATS0=0 command.
If Kermit is running as a server within a script then the above strings can
be sent to the modem with the OUTPUT command.  Asking DOS to send the command
while Kermit is running is not a good idea because DOS depends on modem lines
DSR and CTS being asserted before its i/o will succeed.  Try this script
example:

        <Kermit setup commands go here>
        Server          ; receipt of FIN command will exit Server mode
        pause 2         ; lead time for +++ sequence
        output +++
        pause 2         ; exit time for +++ sequence
        output ATS0=0\13 ; turn off auto-answer mode
        exit            ; exit Kermit

Seems like the right thing to do anyway.]

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

Date: 04 Mar 1988
From: [e-mail] (Gisbert W.Selke)
Subject: A Few Notes on MS-Kermit 2.30
Keywords: MS-DOS Kermit 2.30

     Here are a few observations on very minor problems with MS-Kermit 2.30
in the 08 Jan version. - I'm running it on a very close AT clone under DOS 3.3,
with *no* compatibility problems so far; but then again, I'm not sure that
there couldn't be compatibility trouble (DOS 3.3). - Anyway, here goes:

[From jrd - I use PC DOS 3.30 locally so any bugs are mine and not IBM's.]

(i) If a host application has written to line 25 of the PC screen by directly
addressing it, the mode line is turned off alright, as described in the manual.
However, a subsequent [clear screen[ sequence (ESC left-bracket 2 J) seems to
clear only lines 1 through 24; line 25 remains uncleared. This is somewhat
disturbing at times.

[From jrd - the bottom/status/25-th line is not part of the regular host
display unless the terminal kind is NONE. Some users employ that line for
host status and hot key legends and a normal screen erasure would be
unwanted.  It can be erased by placing the cursor there first, ESC
left-bracket 25 ; 0 H or the appropriate line number for other display
sizes. Btw, version 2.30/A will finally solve the mode line toggle (fossil
mode line) problem.]

(ii) Is there no way to get reverse blinking text? On our VT102 clones (ECMA
standard, to be exact), this works, but on a PC running Kermit, it doesn't.
(May be a hardware restriction?? I didn't find it in the manual, though.)

[From jrd - my EGA + high res color monitor respond to ESC left-bracket 5 m
as the reverse video signal and to ESC left-bracket 7 m as the inverse video
command. ESC left-bracket 5 ; 7 m will do both together. Kermit does do them
so they should appear on your monitor. Numbers in ESC left-bracket .. m are

    0 (or nothing): clear all attributes
    1: bold
    4: underline
    5: blink
    7: inverse video
    10: fast screen updating (not adjustable by host commands, for CGA only)
    30-37: foreground color = 30 plus sum of 1=red, 2=green, 4=blue
    40-47: background color             same

applied in the order received. Underline is inverse video on color monitors.]

(iii) Is the setting of the DOS errorlevel really working?? It is OK with
receiving files, but I seem to get a non-zero errorlevel on each and every
file transfer. - Note: I have a rather complicated script built along the lines
of your example in the manual (or wherever it was I saw it); stepwise checking
reveals that the error level seems to be set not due to script commands
(like [input xxx[) but during the file transfer proper.

[From jrd - that's a real bug. The code was written to behave properly but
last minute changes made the SEND command always report an error. This is
fixed in version 2.30/A which is in preparation.  Apologies to all.]

(iv) I have problems accessing the F11/F12 keys in combination with
shift/alt/ctrl. Part of this is probably due to the German keyboard adaptor
I use (not IBM's KEYB xx, something called KEY6000), but it occurs even without
any resident keyboard adaptor at all. (I'm not having other TSRs in memory,
either.)  Here is what SCANCHEK 4.0 (22 Jan 88) reports (in keeping with
Kermit's "show key"):

            with KEY6000                          without KEY6000
           "key name"    key ident              "key name"    key ident
F11         C-F12        \394                    A-H          \291
SF11        --- nothing ---                      --- nothing ---
CF11        A-,          \1331                   A-4          \1403
AF11        --- nothing ---                      (graphic)    \207
SCF11       A-,          \1843                   A-4          \1915
SAF11       --- nothing ---                      (graphic)    \207
CAF11       --- nothing ---                      (graphic)    \207
SCAF11      --- nothing ---                      (graphic)    \207

F12         *unknown*    \504                    A-J          \36
SF12        K            \75                     --- nothing ---
CF12        A-.          \1332                   A-5          \1404
AF12        --- nothing ---                      (graphic)    \207
SCF12       A-.          \1844                   A-5          \1916
SAF12       --- nothing ---                      (graphic)    \207
CAF12       --- nothing ---                      (graphic)    \207
SCAF12      --- nothing ---                      (graphic)    \207

The only key combinations with the "extended keyboard flag" were F11, CF11,
SCF11, and CF12, but only under KEY6000.

[From jrd - Hmmm. For the Enhanced keyboard the individual items making the
reported key code are:
scan codes F11, F12 = 133, 134; SF11, SF12 = 135, 136, CF11, CF12 = 137, 138,
AF11, AF12 = 139, 140 plus Enhanced kbd = 1024 plus Scancode = 256 plus Shift
= 2, Control = 4, Alt = 8. All in decimal notation. I don't have an Enhanced
kbd handy to check but something appears strangely, such as F12 showing as
\36. Could it be your keyboard differs from IBM's in some coding details?
Responses from other users would be appreciated.]

So, this sums it up (modulo typos); the "F11/F12" item is *not* meant as
something to worry anyone - I can easily survive without these fancy keys.
I just thought someone might be interested, or maybe encounter similar
problems.

Otherwise, Kermit is working just fine. It's a great thing to use, and we do
use it everyday. I haven't checked the TEK emulation yet, but I most
certainly will.  BTW: no strong feelings about overlaying or not.

\Gisbert

[From jrd - Right, one abstaining vote on the Tek erasure/overlay subject.
I'm counting the few which have arrived. Otherwise, Tek emulation will be
better in version 2.30/A.  Plus other nice additions are being tested now.
Thanks again for the information.]

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

End of Info-Kermit Digest
*************************
-------
 5-Apr-88 12:20:50-EST,24866;000000000000
Mail-From: SY.CHRISTINE created at  5-Apr-88 12:19:53
Date: Tue 5 Apr 88 12:19:53-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #10
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 5 Apr 1988       Volume 7 : Number 10

Departments:

  ANNOUNCEMENTS -
        MS-DOS and C-Kermit Source Diskettes Now Available
        Okstate Kermit Distribution Updated
        Announcing C-Kermit 4E(070) for the Amiga
        Announcing XSEND, a Utility for MS-DOS Kermit

  PORTABLE IBM 370 KERMIT -
        More Updates for CMS Kermit
        TSO Kermit Problems
        MVS/TSO Kermit Packet Size Query (and Answer)

  MS-DOS KERMIT -
        Anybody Like a VT-202 Layout?
        Session Log Bug in MS-DOS Kermit 2.30
        Memory Resident Server
        IBM PS/2 60 Bug

  MACINTOSH KERMIT -
        MacKermit 9(36)b4 Parity Problem
        0.9(36)beta Versions of MacKermit
        Basic MacKermit Help
        MAC Kermit .936

  VAX/VMS KERMIT -
        Problems with Filenames in VAX/VMS Kermit
        VMS Kermit - Sending Filespecs
        VAX/VMS Kermit "SET LINE" Command?

  MISCELLANY -
        CPM Kermit Help
        RE: Setting Flow Control for EMACS in Kermit
        PROCOMM+'s Kermit Feature
        Question on NetBios
        KEASY.TEX

Send digest submissions to Info-Kermit@CU20B, requests for addition to or
deletion from the Info-Kermit subscriber list to Info-Kermit-Request@CU20B.

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host CU20B, CU20B.COLUMBIA.EDU, or
CU20B.CC.COLUMBIA.EDU (a DECSYSTEM-20), as user ANONYMOUS, using any password,
and GET the desired files from logical device KER:.  You can also get Kermit
files over BITNET/EARN; to get started send a message with text HELP to
KERMSRV, the Kermit file server, at host CUVMA.  For detailed instructions,
read the file KER:AANETW.HLP (AANETW HLP on KERMSRV).  To order by mail,
request a complete list of Kermit versions and an order form from Kermit
Distribution, Columbia University Center for Computing Activities, 612 West
115th Street, New York, NY 10025 USA.

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

Date: Thu 24 Mar 88 12:23:36-EST
From: Christine M Gianone <[e-mail]>
Subject: MS-DOS and C-Kermit Source Diskettes Now Available
Keywords: MS-DOS Kermit 2.30, C-Kermit 4E(070)

By popular demand, source diskettes for MS-DOS Kermit version 2.30, and UNIX
Kermit version 4E(070) are now available from Columbia University Center for
Computing Activities Kermit Distribution.

A set of four IBM PC MS-DOS 360K diskettes contains the source files for
MS-DOS Kermit, for the IBM PC and PS/2 families and compatibles.  A $50 fee
is charged for the source diskettes with the MS-DOS Kermit User Guide.
Please specify MS-DOS Kermit Source Diskettes when ordering.

A set of two IBM PC MS-DOS 360K diskettes contains the source files for the
UNIX version of C-Kermit, which can be built for many different UNIX
systems, including Berkeley, AT&T, Xenix, etc.  A $30 fee is charged for the
source diskettes with the C-Kermit User Guide.  Please specify C-Kermit
Source Diskettes when ordering.

We are also looking into providing Kermit programs in other formats.  Here's
a question I hope someone can answer: Is DEC's new diskette drive, the RX33,
able to read diskettes written (by the same operating system, VMS or Ultrix)
on an RX50?

Here's another question: Can Micro-PDP11's read TK50 tape cartridges written
on a MicroVAX with VMS?  In what format?  Will TK70 drives be able to read
TK50 tapes?

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

Date: Fri, 25 Mar 88 08:18:12 -0600
From: Mark Vasoll <[e-mail]>
Subject: Okstate Kermit Distribution Updated
Keywords: Okstate

I just received and installed a new set of Kermit tapes from Columbia.  All
the latest versions should now be available via our UUCP and Kermit server
service.

Mark Vasoll
Computing and Information Sciences   Internet:  [e-mail]
Oklahoma State University            UUCP:  {cbosgd, ihnp4,
Stillwater, Oklahoma                         rutgers}!okstate!vasoll

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

Date: Tue, 29 Mar 88 14:38:49 PST
From: [e-mail]  (Stephen Walton)
Subject: Announcing C-Kermit 4E(070) for the Amiga
Keywords: Amiga Kermit, C-Kermit
X-Ref: Commodore Amiga, See Amiga

Enclosed is a shell archive containing the following files:

    ckiker.bwr--A new version, with my comments on the end.
    ckiker.boo--A BOO file for C Kermit on the Amiga.
    Makefile--A makefile for the Amiga under Aztec C.
    diffs--The context diffs to convert CKI*.C to the new versions.
    msb_diffs--Context diffs which I applied to make msbpct.c and
           msbmkb.c work on the Amiga.

I hope all of this is useful to somebody.

                Steve Walton, 29-Mar-88
                Dept. of Physics & Astronomy
                Cal State, Northridge
                18111 Nordhoff St.
                Northridge, CA 91330

Email to: [e-mail] (will forward)

[Ed. - Thanks, Steve!  The entire shell archive has been added, for now,
to CKIKER.UPD, and the changes will be applied to the next release of
C-Kermit.  In case you're wondering what this does for Amiga users, the
major change since the last Amiga release is the addition of long packets.]

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

Date: Wed 30 Mar 1988 21:04:24 CST
From: Mark S. Zinzow <[e-mail]>
Subject: Announcing XSEND, a Utility for MS-DOS Kermit
Keywords: XSEND, MS-DOS Kermit

Enclosed is a copy of XSEND.C, a program to generate TAKE (script) files for
MS-DOS Kermit to allow it to send files and directories to a server over entire
tree branches or disks.  This version generates commands with absolute path
names, and therefore works only between two MS-DOS systems

Perhaps a useful extension might include passing arguments for remote and
local prefix strings to allow relative paths (e.g. ".") or drive letters
etc.  Suggestions for simple and easy to use command syntax are welcome.

The program compiles with Turbo C and Microsoft C, and possibly others.

[Ed. - Thanks, Mark!  Your program has been added to the Kermit distribution
as MSIXSE.*, including the C source program, a .BOO file based on a Microsoft
C 5.0 compilation, and some help text.]

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

Date: Mon, 1988 Apr 4   16:42 EDT
From: (John F. Chandler)   [e-mail]
Subject: More Updates for CMS Kermit
Keywords: CMS Kermit

I have sent new versions of IKCKER.BWR & IKCKER.UPD, noting and correcting
numerous minor problems in CMS Kermit-370 4.0.

                                        John

[Ed. - Thanks, John!  The files are now available in the Kermit distribution.]

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

Date: Thu, 1988 Mar 24   13:01 EST
From: (John F. Chandler)   [e-mail]
Subject: TSO Kermit Problems
Keywords: TSO Kermit

Concerning the new Kermit for TSO: a few bug reports have come in, and
fixes are in the works.

1. Uploading a member of an existing PDS will force the DCB attributes of
   the PDS to whatever Kermit-TSO has for FILE parameters.  A workaround
   is to SET APPEND ON while uploading members.
2. HELP cannot be invoked twice within the same Kermit session.  More
   generally, TSO commands may leave datasets marked "in use" so that
   they are unavailable for further processing.
3. The DIR subcommand is uninterruptible.  The same is true of any
   TSO command invoked from Kermit which doesn't issue a STAX.  If you
   hit BREAK enough times, though, you can get back to the TMP.
4. Kermit may hang when entering protocol mode over a protocol
   emulator if the screen is already full.  A workaround is to clear
   screen by hand.
5. There are rumors that this version won't work for TTY lines through
   VTAM.  If this is true, a temporary workaround might be to issue a
   SET CON FULL by hand (or that might not work either).  In any case,
   if there is any confirmation of the rumors, I'd like to hear the
   details, and I have two possible fixes ready, just in case.
6. If you invoke a non-existant TSO command from Kermit, there will
   be a sub-task ABEND and a READY message.  Just type a carriage return
   to resume Kermit operation.

The fixes for items 1-4 should be out shortly (in IKTKER.UPD).

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

Date: Wed, 30 Mar 88 09:22:32 SET
From: Peter Bodifee <ESC1467@ESOC>
Subject: MVS/TSO Kermit Packet Size Query
Keywords: MVS/TSO Kermit, Kermit Protocol

Re: Info-Kermit Digest, V7 #8:

After reading the new possibilities of the latest MVS kermit, the following
question popped up.

Why is the maximum receive packet size in Kermit TSO version 1.00 (via 7171)
limited to 60 ? Is this because there is a hardware limitation in the 7171
(that is what I have been told, but I have some strong indications against it)?
The documentation I have on the 7171 does not give me any information in the
input/output buffer sizes.

Any help in this direction will be greatly appreciated.

Regards, Peter Bodifee
          ESA/European Space Operation Centre
          Darmstadt, West Germany
          BITNET:  ESC1467@ESOC
          phone  [phone]

[Reply From John Chandler, author of IBM mainframe Kermit 4.0: Early versions
of the 7171 had an input buffer of only 64 bytes or so.  If a micro Kermit
tried sending packets longer than that, nothing could get through.  As a matter
of fact, I believe the buffer is still fairly small, but the 7171 code performs
flow control so that it can keep up with any packet size from the micro.  Both
the CMS and TSO Kermits used to have a packet size default of 60 for SERIES1
mode, but release 4.0 of Kermit-370 has removed that convention (for both CMS
and TSO).  An informal poll conducted last fall (in the form of a query
broadcast to all subscribers of the BITNET IBM7171 discussion group) failed to
turn up any known 7171's which still need the 60-byte packet limit.]

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

Date: Wed, 23 Mar 88 13:26 MEZ
From: "Eberhard W. Lisse" <[e-mail]>
Subject: Anybody Like a VT-202 Layout?
Keywords: MS-DOS Kermit 2.30, VT-202 Setup, Terminal Emulation

We hacked up a vt202 layout which runs TPU and I felt I should beam it over
right away. (Well before I leave the Burn Unit anyway ...)

regards, el

Eberhard W. Lisse, MD
Burn Unit, Technical University, Aachen, West Germany

[Ed. - Thanks, el!  (VT202?) Since people tend to send in lots of these
special- purpose .INI files, we've decided to collect them all into a single
file, MSIIBM.HLP, and yours is will be at the top.]

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

Date:  4 Apr 88 20:56 +0100
From: Harald Hanche-Olsen <[e-mail]>
Subject: Session Log Bug in MS-DOS Kermit 2.30
Keywords: MS-DOS Kermit 2.30, Session Log

The command 'log session foo.bar' seems to work OK except in the case
when foo.bar exists but is empty (that is, it has zero bytes in it).
In this special case, nothing is appended to the file, and the session
log is lost.

An empty file is easily created by Kermit itself, if you follow the
command 'log session foo.bar' immediately by a 'close' command.  This
is how I happened to create an empty file and subsequently got burnt.
Ouch!

[Ed. - This is obviously a bug that needs fixing...]

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

Date: Fri, 04 Mar 88 11:21:42 CST
From: Arlene Slocum <[e-mail]>
Subject: Memory Resident Server
Keywords: MS-DOS Kermit 2.30

Is there such a thing as server mode only of Kermit that stays memory resident
and checks the serial port for file transfer requests?  We are running version
2.30 Columbia Kermit at 9600 baud over an x.25 network on IBMPC XT compatibles.
We would like a background server capability that is compatible with Kermit and
lets PC users do other work.

Arlene Slocum, Programmer/analyst
Institute for Public Policy and business Research
University of Kansas
607 Blake
Lawrence, Kansas  66045
913-864-3701
send replies to my bitnet address: ARLENE@UKANVM

[Ed. - Currently no.  There is a Microsoft Windows version of Kermit, capable
of background operation, but it doesn't have the ability to act as a server.
MS-Kermit 2.30 can act as a server, but has no particular ability to operate
in the background.]

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

Date: Thu, 24 Mar 88 11:20:45 DNT
From: <[e-mail]>
Subject: IBM PS/2 60 Bug
Keywords: IBM PS/2

The IBM PS/2 60 does have a bug. The local IBM-people should know about the
system time problem, and if they don't, tell them to ask the Danish IBM-team.
We had the same problem here, until some patch-code in the CONFIG.SYS was
installed by an IBM'er.

                       Niels Kristian Jensen.

[Ed. - This is in response to the query from Stephen Walton in V7 #9 about
not being to boot the model 60 after running Kermit...]

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

Date: Wed, 2 Mar 88 12:44:41-1000
From: [e-mail] (David Lassner)
Subject: MacKermit 9(36)b4 Parity Problem
Keywords: MacKermit 0.9(36)b4

Is anyone using MacKermit 9(36)b4 successfully with a host that requires
even parity?  We can't get it to work with ours.

David Lassner, University of Hawaii Computing Center
[e-mail]     [e-mail]

[Ed. - The parity bug will be fixed in the "real" release, coming soon.]

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

Date: Tue, 23 Feb 88 11:43:57 EST
From: [e-mail]
Subject: 0.9(36)beta Versions of MacKermit
Keywords: MacKermit 0.9(36)

I have been using the 0.9(36)b3 version of Kermit for several weeks.
It works very well under Multifinder, although not as a multitasking
application.  I used getinfo to set the size to 128K.  (I don't know
what a MacII size should be).  The only anomalies I have found are that
downloaded files often don't show up with the correct size until opened
from another application and that window update gets confused about whether
text should be bold or not.

On Feb 1, 1988 I downloaded the 0.9(36)b4 version of Kermit from the
University of Toledo server (CKM936.HQX).  This version will set EVEN parity
in the Communications dialog box, will save the setting to a file, will
restore this setting under LOAD settings, but unfortunately will not
set the Mac serial port to even parity.  Persons using an IBM 7171 protocol
converter will not be able to use this version.  It may be useful to make
the 0.9(36)b3 version available until this problem can be resolved.

I have terminal tables for use with a 7171 protocol converter for the four
common Mac keyboards, including the old numeric keypad.  Documentation is in
the form of MacDraw files.  I would be happy to .sit them and send them for
distribution if there is interest and if someone can tell me where they should
be sent.

Thanks to everyone who has worked on the Macintoh versions.  0.8(34) works
today.  There aren't many programs of that vintage thay can make that claim.

[Ed. - Any day now, we'll have a new release that fixes the parity bug,
and is not a step backward.]

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

Date: Wed, 24 Feb 88 21:41:56 PST
From: Dennis Mar <[e-mail]>
Subject: Basic MacKermit Help
Keywords: MacKermit

Greetings far-flung correspondents:  thank you for your kind offers
of advice.

We operate an IBM3033 with VM/CMS.  In November the Kermit release
was upgraded from 2.01 to 3.1.

A MacIntosh SE users says "the difficulty apparently lies between
Red Rider 10.3 and the mainframe KERMIT.  I set the KERMIT carrot-Q
handshake.  However I fell that there may be other parameters that
need to be set.

  1. Is Red Ryder's SEND/RECEIVE Kermit compatible with Release 3.1?
  2. What are the parameter settings required?
  3. Are there more mainframe Kermit commands required than in the past?"

Any advice or direction to the appropriate documentation would be most
appreciated.

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

Date: 1 Apr 88 16:56:52 GMT
From: [e-mail] (Frank Simmons)
Subject: MAC Kermit .936
Keywords: MacKermit

 Has anyone discovered how to send a break with the latest version of
 MacKermit?

[Ed. - The new release will include a manual!]

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

Date: 21 Mar 88 09:20:00 CST
From: "NTVAXB::JAMES" <[e-mail]>
Subject: Problems with Filenames in VAX/VMS Kermit
Keywords: VAX/VMS Kermit

I have a user with a peculiar problem.  When he tries to SEND a file from
VAX Kermit by giving its full file specification, VAX Kermit bombs saying
it couldn't find the file.  Example :

Kermit-32> SEND DUA1:[PUBLIC]NETWORKS.DOC
(now it waits, as it should)
(I get back to local kermit and type RECEIVE)
(and it fails because it could not find file "NETWORKS.DO")
(I CONNECT back to VAX Kermit and do : )
Kermit-32> STATUS
....
Last error : File not found for DUA1:[PUBLIC]NETWORKS.DO

Apparently the VAX KERMIT loses the last character of the filename somewhere
along the line.  This only occurs when a drive or directory name is specified.
Any ideas on this one ?

We are using version 3.3.111...

At any rate, I was wondering when a new version of VMS Kermit could be
expected.  I have thoroughly enjoyed the new MS-DOS version, and would
love to see a new version of the VMS...

James Shoffit                  BitNet: JAMES@NTSUVAX  (POSTMAST@NTSUVAX)
Vax Programmer/Operator        THENET: NTVAXB::JAMES  (NTVAXB::POSTMASTER)
Postmaster for NTSUVAX.BITNET  Inter : [e-mail]
North Texas State University        or [e-mail]
Denton, Texas  76203

[Ed. - Unfortunately...  it looks as if Kermit-32 has some kind of fixed-
length buffer for filenames, or some other kind of limitation or bug.  And
there's not much chance of getting it fixed, since the original authors have
all left Stevens Institute of Technology, and no one else has come forward
to take over responsibility for the program -- small wonder, since it's written
in Bliss-32, a language found almost nowhere.  Meanwhile, much-improved VMS
support is being added to C-Kermit, and there should be an announcement some
time in the not-too-distant future.]

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

Date: Fri, 4 Mar 88 17:41 EDT
From: <[e-mail]>
Subject: VMS Kermit - Sending Filespecs
Keywords: VAX/VMS Kermit

Is the following a known bug of VMS Kermit?

Kermit-32>set file naming untranslated
Kermit-32>send *.*
Sending: DQA0:[MIKE]SCARLETBEGONIAS.TXT;23 as SCARLETBEGONIAS.TXT [OK]
Sending: DQA0:[MIKE]FIREMOUNTAIN.TXT;1T;23 as FIREMOUNTAIN.TXT [OK]
Sending: DQA0:[MIKE]STSTEPHEN.TXT;15;1T;23 as STSTEPHEN.TXT [OK]

The files get sent [OK], but that initial filespec gets annoying...

Mike Rego  <[e-mail]>

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

Date: Thu, 31 Mar 88 15:37:33 EST
From: [e-mail] (David Kobus)
Subject: VAX/VMS Kermit "SET LINE" Command?
Keywords: VAX/VMS Kermit

When trying to use the VAX/VMS "set line" command on KERMIT, I encounter a
"no privilege for attempted operation".  Does anybody know what VAX/VMS
category privilege (e.g. netmbx,share) I must allow a user to enable the
terminal line to be accessible to the user's processes?

(later...)

1.Upon trial and error, it appears that the "READALL" privilege category is
  the least dangerous privilege that you can authorize a user running on a
  MicroVAX II VMS system in order to permit a KERMIT SET LINE command to be
  issued.
2.I invite verification from the VMS KERMIT community.

  David B. Kobus
  Naval Air Development Center

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

Date: Tue, 23 Feb 88 16:21:52 MST
From: [e-mail] (Richard Travsky)
Subject: CPM Kermit Help
Keywords: CPM Kermit

Hi -
  I don't know if you can help me with this or not.

  I and and few others in my department own Kaypro 2X's.  We have a CPM
version of Kermit that we got through the BITNET KERMSRV.  It works fine
file transfer wise.  It has a VT52 emulation mode that doesn't work too well
on the 2X.  Since we recently acquired a pair of VAX 8800s, this emulation
feature is now of more concern to us.  Is there a CPM Kermit version more
suitable for the 2X?  The Kermsrv index is huge and it is hard to tell what
file is what.

  We'll be eternally grateful for any help you could give.

Rich Travsky
Computer Services
[e-mail]    (or [e-mail])

[Ed. - No, there's nothing specific for the 2X.  You're more than welcome
to add support for it to CP/M Kermit yourself!  (Or if anyone else has already
done so, please speak up!]

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

Date: Sun, 6 Mar 88 12:27:46 EST
From: [e-mail] (Jeff Siegal)
Subject: RE: Setting Flow Control for EMACS in Kermit
Keywords: Flow Control, XON/XOFF

Re: Info-Kermit Digest V7 #7

>[Ed. - The real, though painful, workaround is to SET FLOW NONE before you
>start EMACS, and SET FLOW XON/XOFF when you exit EMACS, see below.]

How about some escape sequence the host can send to Kermit to turn
flow-control on and off.  Emacs (GNU Emacs anyway) can be configured
to send such a sequence when entering or exiting.

Jeff Siegal

[Ed. - Unfortunately, the DEC VT102 does not support such a sequence,
and it's often a bad idea to make up new sequences for terminal emulators,
as they may conflict with other new sequences that other people make up.]

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

Date: Tue, 23 Feb 88 08:35:53 PST
From: [e-mail]
Subject: PROCOMM+'s Kermit Feature
Keywords: PROCOMM+

A user at our site has recently solved a problem that has been annoying him
for sometime.  The user uses PROCOMM+ to log on to the Unix mainframe from
home, and loves this product.  However, he has never got its inbuilt kermit
protocol to work correctly.  He recently figured out, however, that if he
resets the communications parameters to N-8-1 in mid-session, although
normal unix prompts etc. go gahgah, kermit then works fine.  Therefore, he
changes the parameters for kermit use and then back again when he exits
kermit and everything works fine.  Do you think this means there is some
misset parameter in our kermit installation?  Any other theories?  The user
uses E-7-1 for normal unix purposes.

Thanks for any help in this matter.

                        Bob Rendler [e-mail]

[Ed. - Many UNIX systems use parity by default, typically even.  When you
run Kermit on the PC, you don't notice this because Kermit strips the parity
bit during terminal emulation by default (you can override this with SET
DISPLAY 8).  However, UNIX Kermit does NOT use parity during file transfer --
it puts the communication line into 8-bit "raw" (binary) mode during packet
operations.  Apparently Procomm does not provide a way, as MS-Kermit does,
to do "no parity" but also to strip the high-order bit during terminal
connection.]

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

Date: Mon, 14 Mar 88 22:17 PST
From: CARL FUSSELL <[e-mail]>
Subject: Question on NetBios
Keywords: NetBios

I am looking for information on Net Bios.  Can anyone suggest references
I might look at?   We were thinking about trying to coerce IBM PC
Kermit talk to our VAX (C-Kermit) over our ethernet.  Any opinions
or comments about the feasibility of this would be welcome.

Thanx in advance...

Carl Fussell
Santa Clara Univ
[e-mail]

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

Date: Mon, 14 Mar 88 16:55 EDT
From: Ted Nieland - SRL <@WPAFB-AAMRL.ARPA:TNIELAND@FALCON>
Subject: KEASY.TEX
Keywords: KEASY.TEX

I just FTPed KEASY.TEX from CU20B, but I am getting many errors when I run it
through LaTeX.  Does KEASY require a special STY file?  Is anyone else having
problems with KEASY.TEX?

Ted Nieland

[Ed. - We received several complaints like this.  Has anybody succeeded in
running it thru TeX?  Directions, fixes, would be appreciated.]

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

End of Info-Kermit Digest
*************************
-------
25-Apr-88 15:56:10-EDT,23869;000000000000
Mail-From: SY.CHRISTINE created at 25-Apr-88 15:53:46
Date: Mon 25 Apr 88 15:53:45-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #11
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Mon, 25 Apr 1988       Volume 7 : Number 11

  ANNOUNCEMENTS -
        Announcing Version 2.31-test4 of IBM PC Kermit
        New Sliding Windows Kermit for the IBM PC
        Announcing Commodore 64/128 Kermit Version 2.1(68)
        Announcing a Version of Kermit for MAI Basic Four (MBF) Minis
        C-Kermit 4E(070) Diffs for Apple Mac II's A/UX
        Masscomp C-Kermit Fixes for RTU 4.0b
        Fixes for C-Kermit 4E(70) for VMS

Send digest submissions to Info-Kermit@CU20B, requests for addition to or
deletion from the Info-Kermit subscriber list to Info-Kermit-Request@CU20B.

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host CU20B, CU20B.COLUMBIA.EDU, or
CU20B.CC.COLUMBIA.EDU (a DECSYSTEM-20), as user ANONYMOUS, using any password,
and GET the desired files from logical device KER:.  You can also get Kermit
files over BITNET/EARN; to get started send a message with text HELP to
KERMSRV, the Kermit file server, at host CUVMA.  For detailed instructions,
read the file KER:AANETW.HLP (AANETW HLP on KERMSRV).  To order by mail,
request a complete list of Kermit versions and an order form from Kermit
Distribution, Columbia University Center for Computing Activities, 612 West
115th Street, New York, NY 10025 USA.

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

Date:     Thu, 21 Apr 88 21:31 MDT
From:     <[e-mail]> (Joe Doupnik)
Subject:  Announcing Version 2.31-test4 of IBM PC Kermit
Keywords: MS-DOS Kermit 2.31, IBM PC Kermit

A new version of MS Kermit is available for testing on IBM PC's and
compatibles.  It is labelled 2.31-test4.  It is an early "alpha test" of the
next release, 2.31, for which a release date can't even be estimated.  Until
then matters are subject to change, but what is present now is most unlikely
to be withdrawn.

Items of interest beyond 2.30 (a subset):

1. Selection of a serial port has been extended to permit specification of
Bios level interaction with Kermit rather than letting Kermit go directly
to the port hardware. The commands are

        SET PORT BIOSn (n = 1 to 4)     for Bios interaction
and
        SET PORT COMn (n = 1 - 4)       for Hardware interaction
and
        SET PORT NET host-name          for NetBios interaction

The Bios spec is present specifically to support networks which intercept the
normal Bios serial port interrupt 14H.  Kermit expects registers to be used
exactly like the IBM Bios, and i/o is not interrupt driven.  If there are
problems I am most interested in fixing them post haste.

Further, when the serial port hardware UART is employed the interrupt
request line (IRQ) parameter is now obtained automatically by Kermit so
that the IRQ may be 3 or 4 for different ports, as the user sees fit.
Previously, IRQ had to be 4,3,4,3 for COM1-4; now PS/2's with 4,3,3,3
should work automatically. An arcane detail, to be sure, but in the past
one causing much user frustration.

Until now MS Kermit checked the Bios work area for port info even if the BIOS
were used for comms.  Since various LAN mfrs do an intercept it could happen
that they leave COM1 and COM2 intact and grab COM3, so to speak. If there were
no hardware for COM3 the Bios work word would be empty, more often than not,
and port 3 would be unusable even for networking. This version skips checking
up on matters if the Bios is chosen (voluntarily by SET PORT BIOSn, or
automatically be lack of a suitable UART chip). Thus, networking intercepts
can be shuffled down to BIOS3 or BIOS4 to free the real serial ports.  The
consequence of selecting BIOSn when there is nothing there is to read lots of
echos of our own characters, harmlessly.

2. File attributes packets are available to transfer the size, creation time
and date of a file to cooperating hosts.  Few Kermits implement attributes
packets but the new IBM CMS Kermit and the PDP-11 Kermits do so.  C-Kermit
will support them in the near future.  Two new commands result from attributes
packets:

        SET ATTRIBUTES ON | OFF         (default is ON)

to suppress attribute negotiations if the host might be confused by them, and

        MAIL filename username@host

MAIL is exactly the same as a SEND command except the file attributes packet
requests the host submit the file to the local Mail utility with the indicated
addressing (can include spaces) rather than store the file on disk.
Presently, the command is unique to MS Kermit; expect selected C-Kermit
support in the near future.  MAIL will fail right away (without sending the
file) if the remote host cannot understand the request.

3. A Transaction log is available to record the filename, direction of
transfer, size, starting time, date, and final status of each regular file
exchange.  The log entry is a terse two line description ready for printing or
automated processing.

        LOG TRANSACTION <optional filename, TRANSACT.LOG is the default>

turns on this logging,

        CLOSE TRANSACTION

turns it off, and

        SHOW LOG

indicates the status of logging.  Material is alway appended to log files to
prevent losing older information.  Similarly, there are separate SESSION
(Connect mode) and PACKET log files.

4. Kermit can be operated directly from DOS files, such as

        KERMIT < todo.lst
or      Preprocessor | Kermit

These files or pipes contain the same information as would be typed by hand,
yet Kermit knows a file is being read and will exit to DOS when the file
becomes empty (it will not hang waiting for keystrokes which never arrive).
Kermit TAKE files can be run this way if desired.

5. The command parser permits definition and use of Kermit "variables" such
as \%1, \%2 and so on.  Variables have names of backslash, percent sign,
character '0' and above (with upper and lower cases merged).  Variables are
defined as Macros of that name and the definition can be any string.  Such
strings can contain other variable names.  These variables substitute the
definition text for their name.  For example

        DEFINE dial AT\13,input OK,pause,output ATDT \%1,inp CONNECT, Connect
        DO dial 1-800-555-1212

places the word "1-800-555-1212" in variable \%1 and that text appears
in the Hayes ATDT command during dialing.

Thus, variables \%1,..\%9 are automatically defined by adding words after
the macro name in the DO command, much like command line arguments to
programs or Batch files.

Other variables are defined by the DEFINE <macro name> <mac definition>
command, as usual. Of note is that when a variable name appears in a Kermit
command it is immediately replaced by its definition; if the definition
contains other variables they are also expanded immediately.  No definition
is the same as a null length string.

        DEF test echo first \%1, second \%2, third \%3,
        DEF \%e  echo first \%1, second \%2, third \%3,

yield the same display, via

        DO test word word word
or      DO \%e this that another
or      \%e foo bar bletch

Macros can be displayed by SHOW MACRO <optional mac name abbreviation>.

6. The Tektronix 4010 emulator has been improved and made more like a real
Tek 4010 terminal. The user may allow Kermit to select the active graphics
display adapter (default) or may override that choice via the command

        SET TERMINAL GRAPHICS Auto-sensing | CGA | EGA | VGA | HERCULES | ATT

ATT includes Olivetti M24/M28/DEC VAXmate/Toshiba T3100/AT&T 6300/6300+.
VGA invokes a 640x480 dot color display but the bottom 79 lines are not
saved due to display adapter memory limits.

7. Screen scrolling in the VT102 emulator has been improved twenty fold for
the case where top and bottom display lines do not scroll. Emacs and many
applications scroll interior lines; this version should do so much faster.
Whole screen scrolling is limited by the display adapter board rather than
Kermit.

8. Error messages have been improved to be more helpful. For example,
typing the command

        Kermit-MS> SAT Timer on

shows the message '?Word "SAT" is not usable here', and

        Kermit-MS> SET Timer on and off and maybe on the table

does indeed Set Timer ON and also shows the message

        ?Ignoring extra characters "and off and maybe on the table"

And so forth.  After all, if the machine knows when an error has been made
then maybe it can fix the safe kind without bothering people.

9. The general screen status display is still present but has been supplemented
by a number of individual "SHOW keyword" displays to assist finding things.
SHOW ? indicates all the current keywords for this command.  Command STATUS
gives a screenful of the most interesting things.  SHOW is under active
development to find decent groupings and display formats.

10. The Kermit command line interface now permits full 8-bit character inputs,
with only NUL, ESC, DEL/BS, ^W (delete word), ^U (delete line), and ^C being
special.  This is to enhance support for various languages and keyboards.

11. A new Kermit verb for Connect mode is \Kholdscrn which acts like the
DEC VT10x Hold Screen key: display is suspended immediately by ignoring
new characters (depends on flow control at the serial port level to XOFF
a chatty host). This verb is not assigned to a key presently. It is a toggle
and is cleared by resetting the terminal (\Kreset, ALT =).

12. The VT102 emulator supports the escape sequence pair ESC [ 1 2 h/l to
control local echoing of outgoing material. ANSI spec.

13. The VT102 "25th" line, or status line, is under better control in that
a fossil of the line (written by the host) does not appear unexpectedly.
The status display indicates when the line is on and owned by the host.

14. Another networking item is that files opened read-only now have the DOS
DENY-NONE bit set so that competing tasks may access them simultaneously,
such as when they are run by Pushing or RUN within Kermit.

15. The command SPACE no longer requires presence of CHKDSK.COM. The disk
space calculation is done internally. Empty disk drives yield a nice message.

16. Script commands have been enhanced. A new command is

        WAIT [timeout] \CD | \CTS | \DSR

        WAIT 04:15 \CD\DSR      ; wait for carrier detect and modem ready

to wait for the presence of one or more of these modem signals, or fail with
a timeout.
Commands WAIT, PAUSE, INPUT accept timeouts of seconds and now HH:MM:SS
(truncate from the right but leave at least one colon) which means essentially
"until" that time of day (24 hour clock). The hh:mm:ss must be less that
12 hours from the present so the software can distinguish early from late. A
carriage return will force a timeout, to avoid rebooting a somnolent machine.

17. If a host echoes our XOFF Kermit now detects the situation and ignores
the arriving XOFF. Also, while waiting for the host to send XON Kermit tests
new characters at a rapid rate to improve response time.

18. CD is now a synomym for CWD (and for SET DEFAULT).

19. PAUSE now stops pausing when characters are typed at the keyboard.
This allows you to put things like this into your script files:

    ECHO Type any character when ready
    PAUSE 1000

20. A HELP command was added -- nothing fancy, just enough to get users
started (memory is a consideration here).

21. Finally, MS Kermit works well under MicroSoft Windows. Previously, it
ran fine under Windows but was unable to show Connect mode material which
was voluntarily rolled back on-screen. Screen scrolling now works perfectly.
Tested on MS Windows 2.03 on AT's and MS Windows 386.

[Ed. - Thanks once again, Joe, for your tireless efforts.  The new test
version is now in the Kermit Distribution as MSTIBM.BOO, along with this
message, MSTIBM.HLP, which can serve, for now, as an addendum to the MS-DOS
Kermit User Guide.]

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

Date: Fri 15 Apr 88 16:06:45-EST
From: Frank da Cruz <[e-mail]>
Subject: New Sliding Windows Kermit for the IBM PC
Keywords: MS-DOS Kermit, Sliding Windows, BIX

This is to announce a version of Kermit for the IBM PC by Terje Mathisen of
Norsk Hydro Data, announced by him on BIX in November 87 (his BIX mail ID is
"terjem").  It's written in Turbo Pascal, and claims to include long packets
AND sliding windows, and a nonstandard "fast mode", in which data fields are
not encoded at all (it can only use this to talk to itself).  There is dumb
terminal emulation, which seems to take place only in a small horizontal
window under the command menu.

The source files arrived with nonstandard naming conventions, and have
therefore been packed into a single file, TP4KER.PAS, with name markers like
<<< KERMIT.PAS >>> at the head of each file.  The executable program is encoded
as TP4KER.BOO (which can be decoded back into TP4KER.EXE using any of the
MSBPCT programs).  There is no manual, but a very short summary is in
TP4KER.HLP.  Comments & reviews welcome, as would be results of testing the
long packet and sliding window features against other Kermit implementations
that have them.

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

Date: Mon, 18 Apr 88 00:54:48 -0500
From: [e-mail] (Ray Moody)
Subject: Announcing Commodore 64/128 Kermit Version 2.1(68)
Keywords: Commodore 64, C64

Commodore 64/128 Kermit Version 2.1 (68) is now available.  This new version
has many new features, improvements, and even some bug fixes.  Here are the
main new features/improvements/bug fixes:

 + Enhanced DEC VT-100 terminal emulation with  support  for
   the  VT-100  keypad.   Kermit  should  now  work  fine on
   operating systems such as  VMS.   V2.1  has  some  VT-102
   features added as well: Insert/Delete Line/Character.

 + Limited Tektronix 4010 graphics terminal emulation.  Ker-
   mit  can plot both graphics and text with a resolution of
   320 x 200 (C-64) or 640 x 200 (C-128).

 + Commodore 128 grey key and numeric keypad  support.   The
   grey keys and the numeric keypad, not normally accessible
   on a C-128 in C-64 mode, are active within Kermit.

 + A special file-type for transferring C Power  (now  Power
   C) source code files.  You can now download C source code
   ASCII files as well as upload C Power source files.   All
   necessary  character  translations  are handled automati-
   cally.

 + A screen driver  for  the  Batteries  Included  BI-80  80
   column  card.  This device gives a display as nice as the
   Commodore 128's 80-column hardware, but lacks many attri-
   butes such as blinking and bold.

In addition to these major improvements, many smaller changes were made.
Several bugs were squashed that affected VT-100 emulation, the STATUS
command, and other things.

Obtaining Kermit on a Floppy Disk:

A copy of Commodore Kermit may be obtained by sending $5.00 postage and
handling to:

                 Dr. Evil Laboratories
                 P.O. Box 190
                 St. Paul, IN 47272

We stress that Commodore Kermit is absolutely free, the $5.00 is only
used to cover the cost of the disk, the mailer, postage, and handling.  The
disk will contain Commo- dore Kermit version 2.1, a copy of the preliminary
documentation broken into several files small enough to be viewed with a
good wordprocessor, an initialization file, and, for C128 users, an autoboot
sector.  (All of the files on the disk are available for download from the
Kermit archives.  There is a program in the Kermit archives that will create
the proper autoboot sector for people that want to have one.)

Sometime this summer a final printed (and maybe even bound) version of
the manual will be available at a reasonable cost.  Stay tuned.

Also available from Dr. Evil Laboratories is a custom ROM for the
Batteries Included 80-column card that provides access to the entire ASCII
character set.  Currently we ask $5.00 for the custom ROM.  This price is
subject to change and installation is required.

Dr. Evil Laboratories is a small software company in which Kent and I
are partners.  The company has the facili- ties to distribute Kermit much
more efficiently than either of us could personally.  Also, Dr. Evil Labs
has a permanent address, something that we, being in college, don't have.

All orders to Dr. Evil Laboratories must be in U.S. funds.  Indiana
residents must add 5% sales tax.

Kermit can also be downloaded from the Kermit archives on ARPANET,
BITNET, and other places.  For complete downloading instructions, see the
file KER:AANETW.HLP.

                           Ray Moody
                            [e-mail]
                            ihnp4!pur-ee!j.cc.purdue.edu!ray
                            [e-mail]

                           Kent Sullivan
                            Qlink: corvairkid

The files are as follows:

        c64ker.ann      - announcement of new kermit
        c64ker.hlp      - how to download from cu20b.  How to get 1541 disk
        c64ker.doc      - documentation (a total rewrite of the old docs)
        c64ker.hex      - the downloadable binary itself
        c64ker.m65      - source code.  Too big to mail, so split into parts
        c64ker.rom      - replacement character rom for BI-80 80-column card
        c64ker.ini      - program to create kermit.ini file
        c64auto.bas     - program to create an autoboot sector


[Ed. - Thanks Ray.  The files have been updated as you suggested.  The new
files have replaced the old ones in KER:C64*.*]

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

Date: Thur 07 Apr 88 14:31:00-PDT
From: Edward V. Wastrodowski, Sphere Holdings Limited (SHL)
Subject: Announcing a Version of Kermit for MAI Basic Four (MBF) Minis
Keywords: MAI, Basic Four

This is to announce the availablity of Kermit for the MAI Basic Four
minicomputers, series model numbers 7000,8000, and 9000; it is
written using the latest release of BOSS/VS Business Basic (tm)
called BB86.

[Ed. - Thanks for putting this together and sending it to us on tape.
It has been installed in the Kermit Distribution as MBF*.*, and available
by mail order on Tape D.  Also included is a short Basic program to read
ANSI-D format tapes (like the ones we distribute Kermit on).]

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

Date: Thu, 07 Apr 88 15:57:22 PST
Subject: C-Kermit 4E(070) Diffs for Apple Mac II's A/UX
From: Marion Hakanson <[e-mail]>
Keywords: C-Kermit, Macintosh A/UX, A/UX

Below are the changes necessary to make C-Kermit 4E(070) compile and run
properly on an Apple Mac II running A/UX (Apple's Unix).  A/UX is mostly
System V, but with BSD compatibility grafted on in some rather unique ways.
Here is a short description of the changes I made (quite minor, really).

ckuker.mak:     Add an "aux" target, which is identical to the "sys3"
                target with an added "-DAUX" flag.  See below.

ckufio.c:       Near the top, in a #ifdef UXIII/#endif pair, is a
                #define MAXNAMLEN DIRSIZ.  Apparently A/UX has its own
                MAXNAMLEN definition, so surrounding the above #define
                in #ifndef MAXNAMLEN/#endif takes care of that problem
                in a "portable" manner.

ckutio.c:       I really wanted to avoid adding an AUX flag, but this
                is quite unique (i.e. "strange").  A/UX has SIGTSTP,
                so the job-control code in C-Kermit gets compiled in
                properly, but C-Kermit expects 4.2bsd signal semantics
                when this happens.  The easiest workaround seems to be
                to add to sysinit() a call to A/UX's set42sig() library
                routine, which enables BSD-style reliable signals, along
                with the corresponding TTY job control.  In other words,
                it allows C-Kermit to be suspended with ^Z and restarted
                with "fg" from the C-shell, instead of being killed when
                you try to restart it.

The only other trick I had to discover to use C-Kermit was that you may need
to "set line /dev/modem" (and not tty0) to use the modem port.  Note that
I'm communicating with a hard-wired port selector, and not a "real" modem,
but modem control lines are used here (perhaps not the correct ones,
though).

Apple seems to distribute A/UX with C-Kermit 4E(066) installed in the
/usr/bin directory (this was the C-Kermit with the serious long packet bug),
and sources in /usr/src/kermit.  Other than a similar, but less portable
than mine, change to ckufio.c, I could detect no modifications they made to
the distribution 4E(066), which of course did NOT do the right thing with
Ctrl-Z, etc.

Please let me know if problems occur with these changes, or if other
modifications are indicated.  We've only had this A/UX system up for a
couple of days, and Kermit was a necessity for connecting it to something
other than itself.  Here are the patches:

[Ed. - Many thanks!  For now, your changes have been added to the CKUKER.BWR
file, and they will certainly be incorporated into the next release, which,
given the number of changes that have arrived in recent weeks, will have to
be pretty soon...]

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

Date: 15 Apr 88 13:59:27 GMT
From: dalesys%lamont.Columbia.edu@lamont (dale chayes)
Subject: Masscomp C-Kermit Fixes for RTU 4.0b
Keywords: Masscomp, RTU, C-Kermit

I have butchered the recent release of C-Kermit to accomodate the notion
of "dir.h" in the beta version of Masscomp's RTU (RTU-4.0.b1) operating system.
(For RTU-3.1, "make rtu" with the distributed sources works fine.)

I did it in a rather crude way. It would be more appropriate to make a new
entry in the makefile "rtu4" and use ifdefs, but that's not how it
happened.... (at least I put in some comments (:-))

Dale Chayes Lamont-Doherty Geological Observatory of Columbia University
usmail: Route 9W, Palisades, N.Y.  10964
voice:  [phone] extension 434    fax: [phone]
usnet:  ...philabs!lamont!dale

[Ed. - Thanks, Dale.  Your changes are in CKUKER.BWR for now, and should
find their way into the next release.  It sure would be nice if makers of
Unix systems could agree on where their header files go, and whether they
must be included or not...]

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

Date: Wed 20 Apr 88 15:42:14-PDT
From: Ted Shapin <[e-mail]>
Subject: Fixes for C-Kermit 4E(70) for VMS
To: [e-mail]
Phone: [phone]; Mail:Beckman Instruments, Inc.
Mail-addr: 2500 Harbor Blvd., X-11, Fullerton CA 92634

Here are some fixes for C-Kermit 4E(70) we made for our VAX VMS system.
The fixes are from Will Wood, Beckman Instruments, Fullerton, CA.

[Ed. - Listings omitted, but added to CKVKER.BWR, and forwarded to Jamie
Hanrahan, who's working on a new release of C-Kermit for VMS.  The fixes
include a more effective way of having the C-Kermit server log itself out when
it gets a BYE command, and a fix for the function that returns the current
default device:[directory], and some terminal i/o improvements.]

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

End of Info-Kermit Digest
*************************
-------
18-May-88 17:22:15-EDT,25678;000000000000
Mail-From: SY.CHRISTINE created at 18-May-88 17:21:17
Date: Wed 18 May 88 17:21:17-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #12
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 18 May 1988       Volume 7 : Number 12

Today's Topics:

                        Kermit News Articles Needed
              Announcing Version 4.09 of Kermit-80 for CP/M-80
                Announcing QK-Kermit Version 3.0 for MS-DOS
                        Announcing Sanyo Kermit 2.30
          Announcing re-release of V2.30, MS-Kermit for iRMX OS's
        Announcing a New MSKermit 2.30 for Apricot F Series Machines
                Announcing C-Kermit 4D(061) Adapted to MINIX
                          Updates for TSO Kermit
                   Error in CD3KER, CDC Cyber NOS Kermit
                                 CDC Kermit
              Clarification of uucp-support address on okstate
                              DG/1 Success!!!
                            Kermit Konfigurator
            C-Kermit 4E(070) and Long Packets under VMS vs X.25
                  DEC PRO350 Terminal Emulation Software?

Send digest submissions to Info-Kermit@CU20B, requests for addition to or
deletion from the Info-Kermit subscriber list to Info-Kermit-Request@CU20B.

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host CU20B, CU20B.COLUMBIA.EDU, or
CU20B.CC.COLUMBIA.EDU (a DECSYSTEM-20), as user ANONYMOUS, using any password,
and GET the desired files from logical device KER:.  You can also get Kermit
files over BITNET/EARN; to get started send a message with text HELP to
KERMSRV, the Kermit file server, at host CUVMA.  For detailed instructions,
read the file KER:AANETW.HLP (AANETW HLP on KERMSRV).  To order by mail,
request a complete list of Kermit versions and an order form from Kermit
Distribution, Columbia University Center for Computing Activities, 612 West
115th Street, New York, NY 10025 USA.

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

Date: Wed 18 May 88 12:00:00
From: Christine M Gianone <[e-mail]>
Subject: Kermit News Articles Needed
Keywords: Kermit News

The next issue of the Kermit newsletter is in progress.  Some of the
articles in the past issue described how Kermit was and is being used in the
U.S. and other countries.  We would like to include a similar section in
the next Kermit News.  Please submit any articles describing how Kermit is
being put to good, interesting or unusual uses as soon as possible since we
hope to go to print sometime in the next month.  We would be especially
interested in stories about how Kermit is used to somehow benefit humanity
(or other creatures), to foster international cooperation, or to make life
easier for the disabled.  For many, Kermit is used for mundane purposes like
saving money.  We'd like to hear about that too.

Thanks again to all those people who have submitted articles in the past.

                                          - Christine Gianone

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

Date: 8 Jan 88 0:00:00
From: Bertil Schou, Loughborough University, UK
Via: [e-mail]
Subject: Announcing Version 4.09 of Kermit-80 for CP/M-80
Keywords: CP/M-80 Kermit 4.09

After an incredibly long gestation period, here is hopefully an updated
version of Kermit-80 V4.05. Kermit-80 V4.08 is issued for testing purposes
only.  Version 4.09 is the release issue of version 4.08.  I still, however,
want any feedback about problems generated in this revision, or others
desperately want fixing.

Superficially, there is little real change in operation of Kermit-80, version
4.05, 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)
     SET       TERMINAL to OFF, VT52, DUMB, EXTERNAL, QUIET, REGULAR.
     SET       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 (including other take files!)
     FCOPY     Copy CP/M files from within Kermit (no wildcard)
     TYPE      Type a file to the console from within Kermit
     PRINT     Print a file to the printer from within Kermit
     -         Updated  TRANSMIT command that waits for a string of characters
                 from the host (default is CR).
     -         Command line commands, eg:
                    KERMIT ;SET FILE BINARY;SEND FOO.BAR
     -         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.

On the negative side, only LASM and Microsoft M80 assemblers can be used to
assemble the source files. I personally see no point in being able to support
several assemblers if LASM can do the job, but then again, I have not used the
MAC80 cross assembler...  Comments on assembler compatabilities, please!

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

     a=A for general information
     a=S for system independent source files and hex file
     a=X for system dependent source files
     a=V for system-dependent hex files

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.)

Bertil Schou.

[Ed. - Many thanks, Bertil!  And also to Alan Phillips and Steve Jenkins at
Lancaster University for sending this new version to us via transoceanic
magnetic tape, and to the many others in the UK who contributed to this new
release.  This version supports all the systems supported by version 4.05,
with the exception of the HP-125, and with the addition of many more, for a
total of something like 52 systems.  The new files have been installed in
KER:CP*.*, and the old ones moved (on CU20B, anyway) to KO:CP*.*.  CP/M
users, please get this new version and try it out, so we can make sure it's
safe to distribute.  And this is also the time to plead ONCE AGAIN for
volunteers to distribute CP/M Kermit on 5.25-inch diskette for different
kinds of systems, and also in "universal" 8-inch diskette format.  Please
come forward if you can do it, or know of a user group that can!]

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

Date: Fri, 29 Apr 88 11:35 EDT
From: [e-mail]
Subject: Announcing QK-Kermit Version 3.0 for MS-DOS
Keywords: Pascal Kermit, Turbo Pascal Kermit, QK-Kermit, Tektronix Emulation

I have a new version of QK-Kermit which was written using Turbo Pascal 4.0
compiler.  This version no longer supports CP/M systems but was specifically
written to run on MsDos systems.  It takes advantage of the new Turbo Pascal
features such as the new Turbo Pascal Units (TPU) and the improved graphics
facility.  It is now no longer necessary to have different version of
QK-Kermit for each of the graphics cards.  The same KERMIT.EXE file will work
on CGA, EGA, Hercules, MCGA, and VGA graphics card.

Last time, I had problems in sending the new version over BITNET, and ended up
sending you the files via floppy disk.  I will send the new version via a 3.5
inch floppy if that is OK with you.

                                Victor Lee

[Ed. - Thanks, Victor!  The disk was received in good order, and the files
have been installed in the Kermit Distribution, replacing version 2.8 from
October 1987.  The files on the disk have been renamed to fit the Kermit
Distribution naming conventions.  They can be restored to their original
names by running the DOS batch file, QK3AAY.BAT.  The executable program is
in the form of a simple hex file, and can be converted back into an
executable .EXE file by running QK3EXE (originally called HEXEXE) on it.]

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

Date: Sun, 1988 May 15   14:10 EDT
From: Bob Babcock <[e-mail]>
Subject: Announcing Sanyo Kermit 2.30
Keywords: MS-Kermit 2.30, Sanyo MBC Kermit 2.30

This is to announce the release of Kermit version 2.30 for the Sanyo 550 and
555.  This version is derived from the IBM 2.30 release, and supports
essentially all of the features of the IBM version which make sense for the
Sanyo.  Unlike previous releases, a single executable will run on machines
with or without the optional CGA-like video board.  (A video board is required
for Tektronix emulation.)

The files being sent to Columbia are:
  MSV55X.BOO - BOO-encoded .EXE file (decode with any MSBPCT program)
  MSG55X.ASM, MSU55X.ASM, MSX55X.ASM, MSY55X.ASM, MSZ55X.ASM - system
      dependent source files (also uses the generic MS-Kermit 2.30
      sources)
  MSV55X.HLP - Sanyo-specific addendum to the MS-Kermit 2.30 manual

Present in the source code, but disabled by conditional assembly statements,
is code to apply a temporary patch to the BIOS keyboard routines to enable
more key combinations to be distinguished.  This will only work if the
keyboard interrupt is not being intercepted by a previously loaded program
such as a print spooler or a TSR.

Anyone interested in working on future releases should contact one of the
current developers for copies of the update files and updating program which
are used to create the Sanyo sources from the IBM originals.

Developers for this release are
  Bob Babcock - [e-mail]
  Joe White - [e-mail]

[Ed. - Thanks to Bob and Joe for all of this!  The files have been placed
in the Kermit distribution under the names listed above.  Now we only have
a few MS-DOS systems remaining whose Kermits haven't yet been upgraded to
2.30 level.]

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

Date: Mon, 02 May 88 12:18:32 PDT
From: [e-mail]  (Jack Bryans)
Subject: Announcing re-release of V2.30, MS-Kermit for iRMX OS's
Keywords: iRMX Kermit, RMX Kermit, Intel, MS-Kermit for iRMX

One out of thirty files sent from RMX with a three byte checksum failed
depending on the length of the last packet modulo sub-packet size.  This
re-release fixes that.  Files updated are MSVRMX.BOO (for iRMX 86), MSVRX2.BOO
(for iRMX 286), MSXRMX.A86, and MSVRMX.MAC.  The latter file was modified to
change the RMX date in the sign-on and version messages to 22 Apr and to
eliminate erroneous and confusing error messages in the edit pass when run on
iRMX 86.

[Ed. - Thanks for the fix Jack!  The old files have been replaced with the
new ones.]

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

Date: 26-APR-1988 15:29:57 GMT
From: [e-mail]
Subject: Announcing a New MSKermit 2.30 for Apricot F Series Machines
Keywords: MS-DOS Kermit 2.30, Apricot Kermit

I have a working version of MSKermit 2.30 for Apricot machines it runs well on
my FP portable and so should run on the rest of the F series. I know of no
reason why it should not run on the PC/XI but I have yet to get feedback on
this. However I felt it better to let you have it as is and then wait for
comments, if any. I have implemented the keyboard translator but only in a
very basic form as yet. Otherwise it performs most of the other features of
2.30 such as script files etc. but no modem support or terminal emulation.

The files are:
               MSVAPR.BOO    BOO-encoded .EXE file;
               MSUAPR.ASM
               MSXAPR.ASM

Dick Carlton
Department of Earth Sciences,
The Open University,
Walton Hall,
Milton Keynes, England KK7 6AA

ps: if anyone wants the whole source plus the working version I can let them
have it on a single 3.5in diskette in self unpacking archive form on receipt
of a diskette.

[Ed. - Many thanks!  The new files have been added to the MS-Kermit files,
replacing the old Apricot version.  Presumably your diskette offer only
applies in the UK?]

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

Date: 26 February 1988
From: Adrian Godwin, 78 Putnoe Street, Bedford, England.
Via: [e-mail]
Subject: Announcing C-Kermit 4D(061) Adapted to MINIX
Keywords: MINIX, C-Kermit, Tanenbaum, IBM PC MINIX

Here is a set of C-Kermit 4D(061) sources, modified for use with Andrew
Tanenbaum's UNIX V7 implementation for the IBM PC family, MINIX.  The source
is derived from the Lancaster VAX/VMS backup format distribution tapes of
20.1.88, and 6 files are modified:

    ckuusr.c    ckuus3.c    ckufio.c
    ckutio.c    ckcmai.c    ckcfns.c

Some additional files containing build information for an MS-DOS (Lattice C)
cross-compilation, fixes to the MINIX kernel and pre-built executable files
(in .BOO format) are also present.  These have names of the form cktker.???,
and are documented in the file cktker.hlp .

Modifying C-Kermit 4D-061 for use under 'MINIX' has required rather more
changes to Minix than to Kermit. The C source files are included; they all
began as the CK---.--- files for the 4D(061) distribution set. Here the names
have been changed to MX---.--- . Hints, fixes and library changes are also
attached - most of these are applicable for anyone implementing a serial i/o
driver for Minix, and many library fixes are useful for porting other
utilities.

C-Kermit cannot be built under version 1.1 Minix, as it compiles to about 85K
and the initial Minix assembler cannot separate I&D model output.  The
executable file was therefore built under MS-DOS using the Lattice 3.10 C
compiler. Some care is needed in cross-compiling : see the notes in
Tanenbaum's book about libraries, and read the enclosed Lattice makefile,
cktker.mak.

A port of this version to the latest C-Kermit version 4E(070) is now underway
and will be released at some future time.

[Ed. - While awaiting arrival of the 4E adaptation, this set of files has
been placed in the Kermit Distribution under the prefix MX, as in KER:MX*.*,
and is on Tape B.  Thanks to the folks at Lancaster University for sending
this in.]

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

Date: Mon, 1988 Apr 25   15:18 EDT
From: (John F. Chandler)   [e-mail]
Subject: Updates for TSO Kermit
Keywords: TSO Kermit, 370 Kermit

Here are the updates I promised a few weeks ago (and some others, too)
for TSO Kermit-370.  I am sending replacements for IKTKER.UPD and
IKTKER.BWR -- the latter gives a bit more elaboration of the bugs fixed
and new features implemented.

[Ed. - Many thanks John!]

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

Date: 09 MAY 1988  09:49 EST
From: Steve Roseman <[e-mail]>
Subject: Error in CD3KER, CDC Cyber NOS Kermit
Keywords: CDC Cyber Kermit

There is an error in CD3KER, the CDC Cyber NOS Kermit (the Fortran one), which
prevents its use with V2.31 of MS-Kermit.  CD3KER's response to an 'F' packet
contains the wrong length, which didn't bother V2.30, but does upset V2.31.
The following code fixes the problem.  Please replace the current CD3KER.BWR
with this message, since the current .BWR file is out-of-date.  Thanks.

*IDENT,MAY0688
*D,KERMLIB.3426
            CALL SNDPACK(Y, NUM, SLEN(FILESTR), FILESTR)

On a related note, I will be negotiating with Olaf Pors of Univ of Virginia
about who gets to incorporate his mods from last September (V7 #3), into the
standard CD3KER.  I don't really have the time, but I will if necessary.

Steve Roseman
Lehigh University Computing Center
LUSGR@LEHICDC1

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

Date: Mon, 9 May 88 16:47:20 EDT
From: Olaf Pors <[e-mail]>
Subject: CDC Kermit
Keywords: CDC Cyber Kermit

I just took a look at the Kermit distribution and noticed that the CD3KER.IN2
and CD3KER.MOD files were the ones that conflicted with Steve Roseman's 3.3
version of Kermit.  Late last year I downloaded Roseman's 3.3 version and
upgraded my mod to correspond (producing version 3.4), and I thought I sent
you the upgraded stuff.

In case something got dropped, here are the two files again.  The first one
should be put in place of CD3KER.INS (get rid of CD3KER.IN2).  The second
should be put in place of CD3KER.MOD.  There's also an updated CD3KER.HLP.

Olaf Pors, University of Virginia

[Ed. - Thanks, Olaf.  The updated files have been put in right places.]

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

Date: Mon, 25 Apr 88 18:33:37 -0500
From: Mark Vasoll <[e-mail]>
Subject: clarification of uucp-support address on okstate
Keywords: OKSTATE

We have recently moved the Kermit distribution at Okstate to another
computer.  A result of this is that the previously stated restriction of not
being able to send mail over this link is now enforced (since the new home
of Kermit is not the "real" okstate.  Questions about the Kermit or UUCP
servers at Okstate should be addressed to:

Domain: [e-mail]
UUCP Path: {cbosgd, ihnp4, rutgers}!okstate!uucp-support

Attempts to mail via the uucpker login to okstate!uucp-support will be
flushed.

Thanks,

Mark Vasoll
Computing and Information Sciences   Domain:  [e-mail]
Oklahoma State University            UUCP:    {cbosgd, ihnp4,
Stillwater, Oklahoma                           rutgers}!okstate!vasoll

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

Date: Mon, 25 Apr 1988 20:37:05 EDT
From: "Robert E. Zaret" <[e-mail]>
Subject: DG/1 Success!!!
Keywords: MS-DOS Kermit 2.30, DG/1

I just tried MS-Kermit 2.30 extended development (received from Columbia 23
April) on my DG/1 and have succeeded. In fact, I am using it to compose this
note.  I still can't use COM1/BIOS1 with either the internal modem or an
external modem.  However, if I set the port to BIOS2, I can use COM2 with an
external modem.  I have only been using it for a few minutes, but 1200 bps
seems to be no problem.  I also tried connecting to an AT with a null modem;
Kermit could switch the port's speed to 2400 bps, and I could talk to the AT,
but I couldn't transfer files (each Kermit kept trying, but did not recognize
the other.)

I got the idea to try BIOS2 from two clues: 1) when I use the STATUS command
right after I start Kermit, the display says the port is BIOS1; and 2) when I
tried SET PORT 2, Kermit said the port was unavailable.

Thank you, thank you.  I've had other options, but was rooting for Kermit; I
know at least one other person around here with a DG/1, who has fewer options
and believes several others in the area have the same problem; and I've been
concerned about the person who wrote to the Kermit digest a few months ago
about communications software that can run on a DG/1 and be used by the blind.

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

Date: Thu, 12 May 88 15:27:03 PDT
From: Ariane Glagowski <[e-mail]>
Subject: Kermit Konfigurator
Keywords: MS-DOS Kermit

We are supporting MS-Kermit here as a method for connecting PC's to VM/CMS via
7171's.  Users at UVic can connect to a 7171 port by having a direct
connection to a Gandalf PACX port or an Ungermann-Bass Net/One port, or
dialing to a PACX port. Another connection method is through DATAPAC, although
that is seldom used.

We tried to set up a Kermit "TAKE" file or an ".INI" file for the Users, with
appropriate keyboard mapping and script commands to automate the connection to
VM. If automatic connection was desired, the User was able to connect to VM by
invoking Kermit and typing "TAKE filename" and waiting until the VM/370 logo
appears on the screen. With all the possible combinations of connection
methods, baud rates, monitors, keyboard layouts, etc., etc. it became
impossible for our User Services to help all the first time users with their
connection problems.  We decided to write a Kermit Konfigurator program which
the User could run and would build a TAKE file according to the User's
requirements.

Before running Kermit for the first time, the User types KKONFIG on his PC.
KKONFIG prompts with questions like "select baud rate", "select communications
port", "do you want automatic connection to CMS", etc., along with simple help
menu's for each possible selection. When KKONFIG terminates, it writes a
"TAKE" file that the User can use when running Kermit or he can rename it to
an .INI file.

KKONFIG is written in Turbo PASCAL and linked into one .COM file.  As it
stands now, it is customized for our environment but the source could easily
be tailored to other environments.

If anyone is interested in trying it out to see how it works, please send a
note to me, Ariane Glagowski, [e-mail], and I will send you the
.COM file over the network. You can then receive the file onto your CMS disk
and download it to your PC using Kermit.  Be sure to set the host Kermit in
binary mode before downloading to your PC.

The Konfigurator works with MS-Kermit 2.29c and 2.30.

Ariane Glagowski <[e-mail]>
Acknowledge-To: <CCARIANE@UVVM>

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

Date: 25-APR-1988 11:34:37 GMT +01:00
From: [e-mail]
Subject: C-Kermit 4E(070) and Long Packets under VMS vs X.25
Keywords: VAX/VMS C-Kermit, X.25, Long Packets, C-Kermit 4E(070)

I've just built 4E(070) under VMS and been trying to use long packets with it
to MS-Kermit 2.30, with distinct lack of success.

We have a (*very* slow) VAX-11/780 running VMS 4.7; terminals are connected to
X25 PADs and make X29 calls into the VAX. We have all our lines set for 9600
baud. C-Kermit works OK with normal packet sizes, and it sends files *to* the
PC with 250 byte packets OK. However, trying to use any packet size about 200
bytes or so *from* the PC results in repeated retries; the log shows that the
VAX is giving "Data Overrun" errors on about 1 in 3 packets.

I tried changing CKVTIO.C to set the line to use HOSTSYNC, which ought (I
think) to allow VMS to exert flow control on data coming from the PC (?), but
no effect. Has anyone seen this problem elsewhere? Is the solution just to
reduce the baud rate to what will work?

   Alan Phillips

[Ed. - The problem is probably in the VAX's network interface.  It seems from
your description that the network is delivering the PC's data correctly to
the VAX, but the VAX cannot keep up.  It may be that VMS's support for
incoming terminal connections over an X.25 network is designed with the
faulty assumption that the host sends large amounts of data, and terminals
only send small amounts.  What is the biggest X.25 data packet your VAX will
accept?  If it is 128 (a typical value), then long Kermit packets will be
segmented by the network, and the VAX must reassemble them.  If the VAX is
very slow, new segments may arrive before it has disposed of previous ones.
As you suggest, there should be flow control between the VAX and the network,
but X.25 is supposed to provide this, no?  But it may be that specific
support is required in VMS Kermit for X.25 connections as opposed to real
terminals.  Any VMS X.25 experts out there?]

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

Date: 5 May 88 21:16:03 GMT
From: chemabs!chemabs![e-mail] (Robert S. Hall)
Subject: DEC PRO350 Terminal Emulation Software?
Keywords: PRO350 Kermit

I am looking for an alternative terminal emulator for a DEC PRO 350.  I am
currently using an in-house written VT102 terminal emulator which works well,
but is not quite as fast as I would like.  What I would like to know is:

        o Is anyone else currently using PRO/Kermit?  If so, have
          you noticed any problems?

        o Has anyone made ANY enhancements to PRO/Kermit.  What I
          am most interested in is PRO/Kermit's 'connect'
          function, i.e.  User Defined Function Keys, etc.

    o Does anyone know of any other VT220/VT102 terminal emulation
          software available for the DEC PC350 other than PRO/Comm
          or PRO/Kermit?

Any input you might have on this subject will be greatly appreciated. Thanks!

Robert S. Hall
Chemical Abstracts Service      Columbus, Ohio 43210    [phone] X2027
cbosgd!osu-cis!chemabs!hall

[Ed. - There are several Pro-Kermits.  The one most people use is probably
the K11 version from Brian Nelson.  The Stevens version gave up the ghost
a while back when new P/OS releases made it stop working.]

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

End of Info-Kermit Digest
*************************
-------
24-May-88 12:53:36-EDT,24454;000000000000
Mail-From: SY.CHRISTINE created at 24-May-88 12:51:17
Date: Tue 24 May 88 12:51:17-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #13
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 24 May 1988       Volume 7 : Number 13

Today's Topics:

         Help Sheet on Recent MS-Kermit 2.31-test5 22 May 1988 Code
             Extended ASCII with Kermit, For Kermit Developers
                   Re: VAX/VMS Kermit "SET LINE" command

Send digest submissions to Info-Kermit@CU20B, requests for addition to or
deletion from the Info-Kermit subscriber list to Info-Kermit-Request@CU20B.

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host CU20B, CU20B.COLUMBIA.EDU, or
CU20B.CC.COLUMBIA.EDU (a DECSYSTEM-20), as user ANONYMOUS, using any password,
and GET the desired files from logical device KER:.  You can also get Kermit
files over BITNET/EARN; to get started send a message with text HELP to
KERMSRV, the Kermit file server, at host CUVMA.  For detailed instructions,
read the file KER:AANETW.HLP (AANETW HLP on KERMSRV).  To order by mail,
request a complete list of Kermit versions and an order form from Kermit
Distribution, Columbia University Center for Computing Activities, 612 West
115th Street, New York, NY 10025 USA.

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

Date: Sun, 22 May 88 21:08 MDT
From: <[e-mail]> (Joe Doupnik)
Subject: Help Sheet on Recent MS-Kermit 2.31-test5 22 May 1988 Code
Keywords: MS-DOS Kermit 2.31-test5

The following MSTIBM.BOO, 2.31-test5 22 May 1987, corrects some problems
and adds some new features.

A quick update on a new script feature, long overdue. Now present are the
new commands:

  IF [NOT] {SUCCESS | FAILURE | ALARM | COUNT | DEFINED | ERRORLEVEL | EXIST}
                                                            <Kermit command>
  GOTO [:]<label>
  :text                               text is a label, a la Batch files
  REINPUT <timeout> <match string>
  SET ALARM <time>
  SET COUNT number
  POP
  STOP

Let's start with labels.  They are like the Batch variety and are identified by
a line starting with a colon and then the label text proper (any non-spacing
text should be ok).  Material following the label on that line is ignored.
GOTO is the way to jump to a label. The label name in a GOTO command may
optionally have the leading colon; however, the labeled line must begin with
a colon to be recognized as a label. A label is known only within it's home
Take file or Macro and cannot be referenced from outside. Thus, nested Take
files or Macros can use labels of the same name without confusion. See the
discussion of IF DEFINED for a way to retain information between Take files
or Macros.

GOTO <label> does pretty much as expected. It goes to the line following the
indicated label.  The technique is to rewind the Take file (or the Macro) and
search for the label, so the GOTO's can be forward or backward.  Since scripts
are relatively short files there is not much time lost.  If no such label then
there is a message saying

        ?Label ":text" was not found

and the current Take file or Macro is exited; i.e., there is no place to
continue the execution thread. (No bomb box, no crashing noises.)

Giving a label by hand to the Kermit prompt is a no op (is ignored without
comment).  This is done to let script control flow run across labels without
producing messages en route. GOTO has meaning only within Take files and
Macros.

REINPUT is very much like the script INPUT command, except it attempts to
reread the 128-character script serial port buffer for material matching the
user's string and does not consume the buffer in the process.  Thus, several
REINPUT commands can have a chance to examine the same buffer.  Regular INPUT
discards buffer characters as they are examined, REINPUT does not.  And,
REINPUT can request newly arrived characters, until the buffer fills, as
needed while seeking the desired pattern; that's where the timeout is
effective.

The IF statements look like

        IF [NOT] <condition> <command>

where NOT is optional (yes, NOT NOT NOT.. flips back and forth)

        <condition> is one of the following:
                FAILURE                 (of previous Kermit command)
                SUCCESS                 ( ditto )
                ERRORLEVEL number       (true when ERRORLEVEL >= number)
                EXIST filespec          (with path and wild cards)
                COUNT                   (decrement COUNT, but not below 0,
                                         then if COUNT is still greater than 0
                                         do the indicated command)
                ALARM                   (true if present time >= alarm time)
                DEFINED macro/variable name  (true if macro/variable exists)

        <command> is any legal Kermit command, including another IF statement.

When an IF statement logical test yields False control passes to the Kermit
command on the next line. IF statments themselves do not produce testable
status so that several IF statements can test a previous main Kermit command.

The command

        SET COUNT number   (0 to 65535 decimal)

presets a variable COUNT to the value of number so that it and the IF COUNT
statement can form a loop. There is an separate internal copy of COUNT for
each nested Take file and Macro. SET COUNT has meaning only when given in
Take files and Macros. COUNT is initialized by SET COUNT and it is both
decreased and then examined by IF COUNT. For example, the loop below executes
the interior commands four times -

        SET COUNT 4                     ; do this loop four times
        :TOP                            ; a label for IF COUNT
        <various commands go here>
        IF COUNT GOTO TOP               ; decrement COUNT. If COUNT is still
                                        ; non-zero then go to label TOP

The command

        SET ALARM time

sets an internal alarm clock for use by IF ALARM. Time can be stated as the
number of seconds from now or as HH:MM:SS to specify a time of day. Trailing
SS seconds and MM minutes are optional; a 24 hour clock is used. Times should
not be more that 12 hours in the future so that Kermit can distinguish early
from late. The alarm time is zero until changed by this command, and IF ALARM
does not modify the alarm time. (Right. Now we need "set coffee-pot on"!)

When an IF statement is typed by hand the line is quietly absorbed if the
conditional test fails; otherwise, the line is broken automatically and the
<command> part is then entered at the normal Kermit prompt.

Examples:

        IF NOT DEF \%3 DEF \%3 FOO.BAR  ; supply a missing filename

        IF DEF IBM DO IBM               ; or "Don't DO nothing" (poor English)

        IF NOT EXIST c:\dumm*.txt  IF EXIST mskermit.ini  RUN copy hither yon

One not so obvious use for the IF DEFINED command is to communicate status
between Take files or Macros. That is, a "DEFINE name text" command executed
in one can let another test that name for existence or not. DEFINE name no-text
undefines the macro. Thus, macro names can be used as semaphores or flags (one
bit variables).

Recall, the command "GOTO label" is needed to jump.

Here is a small example looking for modem text CONNECT 1200 or CONNECT 2400:
        set speed 2400
        output AT\13                    ; awaken modem at desired speed
        pause
        output atdt 555-1212\13         ; dial the telephone
        input 30 CONNECT                ; first part of normal response
        if failure goto hangup          ; here "hangup" is a label
        reinput 3 2400                  ; did we connect at 2400 baud
        if success goto login           ; if so jump to login label
        reinput 2 1200                  ; how about 1200 baud
        if fail goto hangup             ; neither so quit
        set speed 1200                  ; slow down Kermit
        :login
        <do login stuff>
        :hangup                         ; a label rather than a command
        hangup                          ; disconnect telephone
        echo \13That's all folks!\13\10

The commands

        POP
        STOP

provide clear exits from a Take file or a Macro. POP exits the current
Take file or Macro, and STOP exits all of them and gets back to the Kermit
prompt.

Before there are too many helpful suggestions in this area, and we could
use plenty, please note that the construction of Kermit command lines and the
parsing code impose limits on what can be accomplished. The command structure
is inadequate to support the syntax and notions of a modern programming
language without a complete redesign of much of MS Kermit. Plus, simplicity
does have a few benefits.

The INPUT command used to be the only one that began with "I", so many existing
scripts and macro definitions abbreviate INPUT this way.  To preserve and
protect this work, I is recognized as an acceptable non-unique abbreviation for
INPUT.

The constructions shown above also work ok in Macros, given the 128 byte length
limit of a macro.  GOTO produces a warning message if given by hand.  Task
size increase has been reasonably small so far.

I think this is a close enough mimicry of Batch to control most scripts for
communications while avoiding the language development snarl.  I'll let the
Hayes folks bask in the glory of auto-scripting.

On another front, I finally was able to borrow a PS/2 Model 50 for an evening.
First, I too saw the message that COM1 was not available.  Thirty minutes later
everything was fine.  That's the difference of being able to do rapid probes.
The new MSTIBM.BOO works well on the Model 50.

The problem area was in the recent code to automatically detect the IRQ value
for a serial port. Apparently PS/2's have enough differences in the timing
in that section to have confused the test code; the new material passes on
that machine and on my AT clone. Defensive action is indicated below.

The current test MS Kermit, dated 22 May 1988, still performs the automatic
IRQ test to assist unusually configured boards; but if the tests fail it
now reverts to choosing an IRQ value of 4, 3, 4, 3 for ports COM1, 2, 3, 4,
respectively, as was the case in version 2.30. PS/2 machines, Models 50 and
greater, will use IRQ 3 for COM2 in accordance with IBM specifications.

Second, reports of very large transfers not surviving a trip through some
recent test Kermits probably resulted from the receiver section tripping out
when a timeout or similar condition occurred. That produces an internal 'T'
packet but the receiver was not fully educated on them; it is ok now. I sent a
1.2MB file back and forth several times and pushed the Return key many times on
both sides, and so on with no premature failures. That's with recent code;
earlier stuff had the attribute of stopping after the first difficulty.

Third, incoming responses to REMOTE commands are now preceeded by a blank line
prevent some hosts from overwriting the local command line.

This is a good place to remark that some IBM hosts which recognize attributes
packets may send a file with a date but no time field.  MS Kermit records the
time as all zeros and DOS interprets that as no time at all; this is a proper
result under the circumstances.  Recognition of attributes packets can be
turned off by SET ATTRIBUTES OFF.

Fourth, the Tektronix emulator now recognizes ANSI.SYS style escape sequences
to change drawing colors. These are the same as in the VT102 emulator; vis

        ESC [ Pn ; Pn ; .. m

where Pn represents an ascii number:
             0 = set medium intensity white on black
             1 = set high intensity foreground
         30-37 = set foreground drawing color,  30 + sum of colors
         40-47 = set background color, 40 + sum of colors
        colors are 1 for red, 2 for green, 4 for blue, sum to get others.
        Parameters are applied in the order received.

The Tektronix emulator assumes the colors of the VT102 emulator until given
it's own set, as above. Resetting the emulator (\Kreset or ALT =) returns to
the VT102 coloring set. Clearing the screen (reception of ESC Control-L)
employs the new background color.

The following MSTIBM.BOO can be posted for public inspection, with the reminder
that the script enhancements are still under active development and will
hopefully be improved soon.

        Regards,
        Joe D.

[Ed. - Once again, Joe, many thanks for all your careful and patient work.
We hope that the features described in this message, and the previous one
about "2.31-test4" will comprise the major changes for version 2.31, and
a formal announcement will appear soon, once the kinks are worked out of
the new code.  Please test it on IBM PC's, compatibles, and near-compatibles
like the DG/1 and report any problems.  The files are in MSTIBM.BOO and
MSTIBM.HLP in the Kermit distribution.]

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

Date: Fri, 20 May 88 15:26:25 +0200
From: Andre PIRARD <[e-mail]>
Subject: Extended ASCII with Kermit, For Kermit Developers
Keywords: Extended ASCII

ABSTRACT

In the course of implementing our own national character sets with Kermit
for terminal mode and file transfer, my understanding of the problem evolved
from confusion to (near) simplicity and from national to international.  I
think my findings will be of much interest to those having to deal with the
Spanish, French, German, Italian, well, the American continent, Western
Europe and many other languages.  That's, for them, really interconnecting
the majority of computers existing to-day.

On request, I've tried to be as short as possible at the risk of skimming
here and there.  I sure won't blame those getting bored with the subject.
They can skip to the conclusion and see just what it takes in Kermit terms.
Conversely, those really interested will get more information from the
standards and the ISO8859 list of BITNET's LISTSERV @ JHUVM and its
archives.

Finally I take the occasion to praise all those devoting much of their time
to straightening things that had run havoc. It's their ideas I am conveying.
But I am sure glad to help. I just hope my limited English will carry the
message precisely.


DETAIL

In the process of implementing extended characters transfer between micros
and IBM mainframes, I relied on the extended capabilities of Kermit 370
conversion (thanks John!). I came to the conclusion that, for the sole IBM
PC, I should set up to 9 different tables in order to support 3 EBCDIC
tables x 3 "ASCII" tables.  For the Macintosh, that's 3 more tables with the
IBM host.  I was unable to have Kermit do Mac to IBM PC conversion, unless
endeavouring translation on the PC, 3 more tables or so.

I hacked some limited national characters support for IBMPC terminal mode
through the 7171, but our Mac users were left with a dumb nice keyboard and
a deaf screen.


Kermit implements two main files transfer modes.

Binary mode defines how to transport a continuous string of bytes containing
values only required to be meaningful to the originating and receiving final
systems.  No matter how stored on an intermediate one, it should forward or
return the same byte string on the communication line.  The point here is
that each node operation is clearly defined, making it the best method when
appropriate.

Text mode, in contrast, defines how to transport *records* containing codes
for "readable" characters intended to be usable -- and stored as such -- on
any system.  The protocol rules how to, on the line, stream the records in a
system independent manner. Again, every node should forward the data
unaltered, that is equivalent communication line encoding.

The Kermit protocol wisely says that the ANSI X3.4 (ASCII) standard is to be
used to represent these characters.  It is the code used on most computers
and those (IBM, Commodore) not using it have to deal with their own problem
of code conversion.

Most modern computers now implement an 8-bit extended character set in order
to support, to various extents, languages requiring characters not found in
ANSI X3.4 (I intentionally disregard the obsolete 7-bit remapping methods).
Almost each does it its own way however, because there was no standard at
the time they were devised (IBM even has multiple ones within a single
system).

Clearly, translation must occur somewhere to transmit extended text usefully
between them.  If it is done say by running a program in the receiving
system, one must know and use the right table according to the sender.  The
mere at least 7 codes that I have to deal with make for 5040 tables in
theory.  In practice, what was a crystal clear matter as long as only X3.4
was used becomes a real puzzle with extended codes.  As the number of tables
grows, so does the problem factorially.

To a lesser extent, the same problem holds for terminal mode.  It occurs
only when a computer supports remote terminals, but we must fiddle with a
7-bit data path, an issue solved per se by the Kermit protocol in the first
case.

It is evident that the problem lies in each machine's dealing with the
others' own business, and that the solution is to have them talk a common
code on the line, as it is now with X3.4 and for those not using it.
Imposing them to use that code internally is impractical, although
recommendable.  But having each convert the data to/from that common code
before/after transmission reduces the above example to a mere 6 tables
pairs.

What is striking is the technical simplicity of translating every character
data byte that flows on a communication line to a common code everyone
agrees about.  What is sorry is that we have to. What is moot is what common
code should be used on the line.

It is my strong feeling that Kermit itself translating national codes to
make up for the lack of its host system using a standard will be *extremely*
useful for people having to use these codes.  This feature must be optional,
because incompatible with previous use.  It would be a shame to have two
Kermit implementations for the same system corrupt data because one uses
this feature and the other lacks it.

The cause of the problem, a missing standard, does no longer exist.  ISO
8859/1 = ANSI X3.134.2 = ECMA 94 has been defined and gathers every possible
character extension for Latin group 1 users, by far the largest, plus other
common symbols satisfying many computer brands. It looks like a very well
thought out thing and several leading manufacturers have adopted it, or a
pre- release because they couldn't wait, or modified their previous codes to
conform to ISO (have exactly the same graphics, but use other codes points,
in line with this proposition).  That's IBM, DEC, Microsoft and Lotus for
what I gathered.  It looks like the future many, international and US, are
working for.

The on-the-way-ISO8859/x users should not be left out.  The problem is
parallel, but their codes will be untranslatable to ours.  They might be
expected to start with pure ISO right off.  Until the 16 bits (some say 32)
codes sets will be devised, but that's our children's Kermit probably.


CONCLUSION

In summary, a Kermit implementation would be much enhanced for many people
if simply:

- it was optionally translating bytes during text mode file transfer (at the
file I/O or equivalent level). Nothing elaborate is required to start this.
Just a pair of null translation tables, easily found and patched, and a
couple of code lines will cover both the "translation" and "optional"
topics.

- it was doing the same at the communication line I/O level during terminal
mode and, when using 7-bits wide data path, implementing the ISO 2022 SO/SI
feature to use the upper half of the set (shift out) and revert to the lower
one (shift in).  Several already do.

That's all. But a welcome leap further would be to:

- if a particular system does not conform to ISO (like the Mac, misses some
of its graphics or uses others), define a best fit one to one correspondence
between its character set(s) and ISO (there should be total agreement as to
which, up to with the manufacturer). It must involve the 256 codes in a
revertible way.

- have systems supporting terminals do it in ISO mode, preferrably on an
8-bit wide line.

- have these features bundled in options.

Thanks for your patience in reading.

Andr). Oops, not yet. Andre'.

[From Frank - This message is the tip of a large iceberg.  Kermit does
indeed use 7-bit US ASCII with CRLF-terminated lines as the common
intermediate representation, or "transfer syntax", for text files.  This has
been a great strength of Kermit, allowing text files to be transferred in
useful form between arbitrary systems.  But the years since Kermit was
designed have witnessed the growth of widespread computing based on
non-ASCII alphabets, many of them 8-bit or 16-bit character sets that cannot
be mapped to 7-bit ASCII.  Therefore, it would seem appropriate to do as
Andre and many others have suggested: allow for a selection of transfer
syntaxes.  The mechanism would be something like SET TEXT {ASCII, ISO8859/1,
JIS, etc}, where the default would be ASCII, as now.  This command would
select the character set to be used on the communication line during file
transfer.  Similarly, a SET TERMINAL CHARACTER-SET command would govern the
transmission and display of text during terminal emulation.  This would not
necessarily be the same as the one used in file transfer.  Since not all
Kermit programs could be expected to support the same character sets (other
than ASCII), this could be a parameter specified in the Attributes packet
under the "encoding" attribute, which already includes an "A" parameter for
ASCII.  New symbols would have to be defined for each alphabet, such as I1
for ISO8859/1, I2 for ISO8859/2, etc, J for JIS (is there more than one
variety of JIS), etc.  Suggestions and discussion are welcome.]

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

Date: Tue, 5 Apr 88 15:28 EDT
From: [e-mail]
Subject: Re: VAX/VMS Kermit "SET LINE" command
Keywords: VAX/VMS Kermit

Mike Rego asks:

>When trying to use the VAX/VMS "set line" command on KERMIT, I encounter a
>"no privilege for attempted operation".  Does anybody know what VAX/VMS
>category privilege (e.g. netmbx,share) I must allow a user to enable the
>terminal line to be accessible to the user's processes?

READALL is not a privilege that you want to give out casually, as it allows
a user to read *any* file on the system regardless of access protections.
What we do here is to set the protection on the particular device such that
the world has read access. This allows a user with no special privileges to
connect to the device. The command is:

  $ SET PROTECTION=(W:R) ddcu:/DEVICE

where ddcu: is the device you want users to have access to. I do not know of
any major security problems this creates.

Tony Carter
MIT Bates Linac
[e-mail]

[Ed. - We received many replies similar to this one.  Among them was the
suggestion that the above technique might make it possible for one user to
spy on another, with the workaround being something like:

  $ SET PROTECTION=(W:RWLP)/DEVICE/OWNER=[1,4] TXA0:

There was also the idea of using access control lists for the dialout devices:

  $ SET ACL/OBJECT=DEVICE/ACL=(IDENTIFIER=INTERACTIVE,OPTIONS=NONE,-
          ACCESS=READ+WRITE) TXA10:

This technique also allows you to grant access to only certain authorized
users.  In no case should users need to be given special privileges to assign
an external TTY line.]

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

End of Info-Kermit Digest
*************************
-------
 7-Jun-88 17:41:12-EDT,22631;000000000000
Mail-From: SY.CHRISTINE created at  7-Jun-88 17:40:20
Date: Tue 7 Jun 88 17:40:20-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #14
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>


Info-Kermit Digest         Tue, 7 Jun 1988       Volume 7 : Number 14

Departments:

  ANNOUNCEMENTS -
        Announcing Release 3.3.117 of VAX/VMS Kermit
        Announcing Macintosh Kermit Version 0.9(40)
        Tape Utility Programs Available

  MACINTOSH KERMIT -
        Defective S packets from MacKermit 9(36)b4
        MacKermit Questions
        Linefeed problem with MacKermit 0.9(36)B4
        Kermit Between Macintosh and UNIX, Slight Problem

  MISCELLANY -
        8-Bit Asynchronous Communication with Parity Bit
        Does Windowed Kermit Exist?
        Bi-directional Protocols
        Modcomp Kermit - A Bug and Two Suggestions

Send digest submissions to Info-Kermit@CU20B, requests for addition to or
deletion from the Info-Kermit subscriber list to Info-Kermit-Request@CU20B.

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host CU20B, CU20B.COLUMBIA.EDU, or
CU20B.CC.COLUMBIA.EDU (a DECSYSTEM-20), as user ANONYMOUS, using any password,
and GET the desired files from logical device KER:.  You can also get Kermit
files over BITNET/EARN; to get started send a message with text HELP to
KERMSRV, the Kermit file server, at host CUVMA.  For detailed instructions,
read the file KER:AANETW.HLP (AANETW HLP on KERMSRV).  To order by mail,
request a complete list of Kermit versions and an order form from Kermit
Distribution, Columbia University Center for Computing Activities, 612 West
115th Street, New York, NY 10025 USA.

On June 1, 1988 the renaming of CS and CC hosts from .COLUMBIA.EDU to
.CS.COLUMBIA.EDU and .CC.COLUMBIA.EDU domains took place. Please report
any problems to your local departmental network/system manager.

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

Date: Wed 1 Jun 88 12:00:00-EST
From: Christine M Gianone <[e-mail]>
Subject: Tape Utility Programs Available
Keywords: Tape Utility Programs

Tape utility programs are available in the Kermit Distribution on Tape E.
The programs have been collected from various sources, and are being made
available as a public service.  For distribution purposes, they have been
renamed as indicated in KER:TUAAAA.HLP.

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

Date: Wed 1 Jun 88 12:00:00-EST
From: Christine M Gianone <[e-mail]>
Subject: Announcing Release 3.3.117 of VAX/VMS Kermit
Keywords: VAX/VMS Kermit

This is to announce VAX/VMS Kermit-32 Version 3.3.117, submitted by Jonathan
Welch of Amherst College.  This version contains fixes for some of the bugs
that were noted in VMSMIT.BWR, the "beware file" for the previous release,
3.3.111.  Here's the list:

 - Fix the message generated in NEXT_FILE so that the filenames displayed
(e.g. Sending: foo.bar;1 as foo.bar) are always terminated by a null (ASCIZ).

 - Modified SY_TIME to use $GETTIM as opposed to the LIB$timer routines
(which broke when their method of calculating time differences changed in
V4.4?).  Removed the call to LIB$INIT_TIMER in SY_INIT.

 - Modified MAIN_ROUTINE to return the status code from COMND when exiting.
Note: The error message codes returned are internal Kermit-32 error codes.

 - Added the ability to send a BREAK character to the outgoing terminal
session using the sequence esc-chr B.  The break will be sent after the next
character arrives.  This is because there must be no outstanding I/O on a
channel in order to modify terminal characteristics (necessary to send a
break).

 - Modified COMND_HELP to look for the kermit help file called KERMIT_HELP or
pointed to by the logical name KERMIT_HELP.  Thus if a user wants to have the
kermit help file in a directory other than SYS$HELP it is not necessary to
define the logical name KERMIT (which causes problems: i.e. RUN KERMIT will
fail).

 - Calls to LIB$SIGNAL with multiple arguments were not coded correctly.  For
calls with multiple arguments an argument count was added.  Minor changes to
KERM_HANDLER to make use of the changed argument passing method.

The hex file for the new version is in KER:VMSMIT.HEX, which can be converted
into an .EXE file using the VMSDEH program.  The program was linked under VMS
4.4, which means that the .EXE will run under VMS 4.4 and above.  If you have
an earlier release of VMS 4.x, then you will have to rebuild from Bliss or
Macro source.  If you are running VMS 3.x, you won't be able to use the new
version at all, but must continue to run version 3.1 of VMS Kermit, which is in
KER:VMSV31.HEX.

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

Date: Thu 26 May 88 16:42:08-EDT
From: Christine Gianone <[e-mail]>
Subject: Announcing Macintosh Kermit Version 0.9(40)
Keywords: MacKermit 0.9(40)

This is to announce Macintosh Kermit 0.9(40), by Paul Placeway of Ohio State
University and Matthias Aebi of ECOFIN Research and Consulting, Ltd, Zuerich.
MacKermit 0.9(40) runs on all Macs except the 128K original.  If you have a
128K Mac, you should keep version 0.8(34), the last formal release.

As of 0.9, MacKermit has been translated into Apple MPW C, so that it can be
edited, compiled, and built on the Macintosh itself.  This translation was
based on work by Jim Noble of Planning Research Corporation, who converted
MacKermit 0.8(34) from SUMACC C (which had to be cross-compiled on a UNIX
system) to Megamax C.  Matthias converted Jim's version to MPW C, and he also
added many of the new features listed below.  After that, Paul Placeway
integrated the program with version 4E of C-Kermit and added additional new
features, also shown below.

 - Long packet support
 - The cursor with open desk accessories now works correctly
 - New program icon
 - New settings files are no longer TEXT
 - Settings can now be written back to an already existing settings file
 - Key redefinition function built in to Kermit, no more CKMKEY
 - Server mode directory listing feature
 - Multifile (folder) send
 - Server "Delete" file command
 - Server "Space" command
 - Get whole folder content from the server with filename ":"
 - Support of menu command keys (key macros)
 - Terminal settings dialog separated from communication settings
 - Non-transparent terminal mode
 - Display of statistics and protocol version to "About Kermit" dialog
 - Parity problems fixed
 - More efficient file transfer in many cases, especially when parity in use
 - Session logging (screen capture)
 - Transaction logging
 - Multifinder support
 - Additions to the VT102 emulator (smooth scrolling, etc)
 - Rearrangement of menus and displays
 - Program no longer hangs if remote response window gets too full
 - Program now works correctly on 64K ROM machines
 - A new manual

The new files are among those in KER:CK*.* on CU20B.COLUMBIA.EDU, available
via anonymous FTP, and on BITNET, as CK* * from KERMSRV at CUVMA.  In
particular:

 CKMKER.HQX is the MacKermit application, in BinHex Version 4 format
 CKMKER.DOC is the new Kermit User Guide chapter for MacKermit
 CKMKER.MSS is the Scribe source for the manual chapter

If you would like sources, the files you need (using Unix notation for
brevity) are: CK[CMU]*.[CHRW], that is, all files whose names start with CK,
followed by C, M, or U, and then some more characters, with a filetype of C,
H, R, or W.  You also need the file CKMMAK.*, the "makefile" in BinHex v4
format.

The previous version, 0.8(34), will be retained (without source) as CKM834.*
and CKMKEY.HQX for use on 128K Macs.

Thanks to all the Info-Kermit readers who have been beta-testing different
pre-releases of this program since last October.  And many thanks to Paul and
Matthias for putting this release together and making it available.  Please
report any problems to Info-Kermit-Request@CU20B.

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

Date:  Sun, 22 May 88 22:28 EDT
From:  "David M. Rosenberg" <[e-mail]>
Subject:  Defective S packets from MacKermit 9(36)b4
Keywords: MacKermit 0.9(36)b4

I have MacKermit 9(36)b4 configured to send 1000 byte packets.  The first
time I try to send a file from the Macintosh, MacKermit produces a correct S
packet indicating that the maximum length for non-long packets is 90 bytes,
that it supports the long packet capability, and the maximum length for long
packets is 1000 bytes.  After having successfully sent a file with long
packets, on the second and subsequent attempts to send a file, MacKermit
produces defective S packets.  These defective S packets are defective only
in that the character that encodes the maximum length of non-long packets is
not in the permissible range (it is a backspace character - I assume that
MacKermit is trying to encode the value 1000 in a single byte and its
algorithm produced the backspace character).  This defective S packet should
be acceptable to a program prepared to receive long packets - because it
indicates support for the long packet capability and a valid maximum length
for long packets.  But it is a defective S packet.

[Ed. - This is the same bug that was noted by Chuck Hedrick in Info-Kermit
V7 #9, 22 March 88.  It is not particular to MacKermit, but is endemic to
all C-Kermit-based Kermits, therefore MacKermit 0.9(40) will have the same
problem.  A fix from Chuck is listed in CKUKER.BWR, and will be applied in
the next release of C-Kermit.]

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

Date: Tue, 5 Apr 88 13:47:59 EDT
From: Howard Walter <[e-mail]>
Subject:  MacKermit Questions
Keywords: MacKermit 0.9(36)b4, Long Packets

I am using the (36)b4 release of MacKermit on a Mac+ and have been VERY
pleased with it. I have several questions:

I am using a Vadic 9600VP modem which has a 4KB buffer.  Are there any plans
to allow ckermit to use a larger buffer such as 4KB?

[Ed. - MacKermit can receive packets up to 1KB and send packets up to 2KB.
As of today, you can get the sources and increase these sizes, which are
just symbols defined in CKCKER.H, MAXRP and MAXSP respectively, recompile,
and try it out.  Satisfaction not guaranteed (very long packets sometimes
give poorer performance -- you have to find the optimum length for your
setup.)]

Does the vt100 terminal emulation mode honor flow control? I have never had
a problem transfering files but the terminal mode frequently trashes the
screen.

[Ed. - As of today, yes.]

Would you consider changing the terminal mode so that if the user types a
control-S, the terminal immediately stops displaying new characters?  With
the large buffer in the modem, you can type a control-S and then wait for
several screenfuls until the buffer clears.

[Ed. - The new version, 0.9(40), does not do this.  At 9600 baud, anywhere
from a line or two up to nearly a screenful goes by before the XOFF takes
effect, depending on how much the Mac itself has buffered up internally (it
has a biiiig input buffer.  Future versions might have a feature like this,
similar to the VT100 No Scroll button.]

Is there an escape sequence to activate the printer on the Mac and
automatically print whatever is appearing on the screen?

[Ed. - No, ANSI printer control is on the list of ideas for future versions.]

Thanks!!
Howard

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

Date: Wed, 13 Apr 88 20:32:20 EDT
From: Caroline Arms <[e-mail]>
Subject: Linefeed problem with MacKermit 0.9(36)B4
Keywords: MacKermit 0.9(36)b4, Key Redefinition

I don't seem to be able to set a key to the linefeed character () -
or rather the LF looks as though it gets converted to a CR (or CR/LF)
before transmission.  I had no such problem with the earlier version of
MacKermit I had been using - 0.8(35).  Is this is a bug or a feature?

[Ed. - Neither, at least not in the new version.  Maybe you didn't notice
that control characters should be entered as octal, rather than decimal,
numbers.  Also, in the new version, you can enter them symbolically, e.g.
\^J for linefeed, \^M for carriage return, etc.]

Apart from that, the new version seems to be a substantial improvement.

Caroline Arms   CA0L@CMUCCVMA

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

Date: 2 May 88 23:02:41 GMT
From: [e-mail] (Thomas Sj|land)
Subject: Kermit Between Macintosh and UNIX, Slight Problem
Keywords: MacKermit

I tried to use kermit to transfer a (MacWrite-)file from a Macintosh to a
SUN and back again and found some problems:

(I used kermit -u on the sun).

[Ed. - "kermit -u" ???]

1. Kermit lost information present in the Macintosh files without informing
   the user and asking whether that was OK (probably the user is naive, since
   smart users seem to use other protocols according to my minisurvey in
   the surroundings here :-).

[Ed. - The problem is that the user did not tell Unix Kermit to receive the
file in binary, rather than text mode.  Use "kermit -ir", for instance.
You'd need a smart protocol indeed to receive files from a foreign system
and know whether they are text or binary!]

2. Kermit transformed names in upper case letters on the Mac to lower case
   on Unix without informing about this. (Again, Macusers expect more info
   about what is going on than traditional users. The Mac-Kermit should
   be more user friendly here.

[Ed. - Maybe so, but the default action is even friendlier.  If the file
arrived at Unix in mixed case, your naive user might not know that case is
significant, and would not be able to refer to the file until s/he figured
this out.  If you prefer filenames to be transferred literally, you can
give Unix Kermit users an initialization file (.kermrc) that includes the
command "set file names literal".]

3. When transferring the file back to the Mac, Kermit destroyed the
   original file, again without informing the user about what was going on.
   (The mapping of filenames was involved here).

[Ed. - This is NOT the default action.  Someone customized your user's
MacKermit to do this.  Normally, MacKermit will append a dot and a number to
any incoming file that has the same name as an existing file.]

- Are there versions of Kermit for the Mac around that do a better job on
  keeping all information stored in a Mac-file, when transferring to a
  file system like the one of Unix?  Note that one might well want to use
  the Unix system as a buffer for files to be downloaded on another Mac,
  and Kermit ought to be able to handle the situation.

(Yes, I know that one can use PackIt or BinHex before sending files, but
 if that is needed, I think Kermit should warn the user when he is about
 to make a stupid mistake.)

[Ed. - No, not yet.  Something like this is on the list for a future
release.  Probably MacKermit will be able to convert to/from MacBinary while
sending and receiving.  This does not mean you can't transfer Mac
applications directly with Kermit, only that it's a bit cumbersome.]

Opinions ?

[Ed. - Always welcome, as are suggestions, complaints, and praise.  But
remember -- these programs are done by volunteers in their spare time!]

Thomas Sj|land
SICS, PO Box 1263, S-164 28 KISTA, SWEDEN
Tel: [phone]    Ttx: 812 61 54 SICS S    Fax: [phone]
Internet: [e-mail] or {mcvax,munnari,ukc,unido}!enea!sics.se!alf

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

Date: Fri, 15 Apr 1988 11:18:56 IST
From: "Jonathan B. Owen" <[e-mail]>
Subject: 8-Bit Asynchronous Communication with Parity Bit
Keywords: RS-232, Asynchronous Communication, Data Bits, Parity

I keep reading all too often of people writing that 8-bit communication is
mutually exclusive with a parity bit.  Actually, each frame, or character
transmitted over an asynchronous link starts with a Start-Bit followed by 7
or 8 Data-Bits, followed by an optional Parity-Bit, and finally terminated
with 1, 1.5 or 2 Stop-Bits.  In effect, besides the framing bits, a maximum
of 9 bits are possible for each character.

The reason I write this, is because I wanted to use Mac-Kermit 0.9(36) with
an IBM/370.  Apparently, you cannot set 8 bit communication with Mac-Kermit.
Also, I ran across another program on the Mac which lets you select EITHER 8
bit communication or 7 Bit with Parity, which is ridiculous (can't remember
name of program off hand).

I hope this letter clears things up a bit (or 9 bits!).

Email: gdau100@bguvm (bitnet)
Snail: 6/15 Mendelson, Tel-Aviv  Israel
Voice: [phone]
Jonathan B. Owen

[Ed. - I guess it depends on who sets the standards.  According to ANSI
X3.16-1976, "Character structure and character parity sense for
serial-by-bit communication", there are two environments: 7-bit and 8-bit.
In the 7-bit environment, each character should contain 7 data bits, a
single parity bit, plus a start and stop bit (section 3.1).  In the 8-bit
environment, you get the start bit, 8 data bits, and a stop bit.  "There is
no parity bit in the 8-bit environment" (section 3.2).  In real life, of
course, you can transmit whatever you like.  For instance, the 8250 UART in
the IBM PC allows for 5, 6, 7, or 8 data bits, with or without parity.  The
key consideration is that the receiver be programmed exactly like the sender
as to the number of start, data, parity, and stop bits.  Much hardware, and
most software, is designed according to the ANSI standard, and therefore
allows 7 bits with parity, or 8 bits with no parity.  The asynchronous
serial interfaces found on IBM mainframes (3705 TTY lines, 7171 protocol
emulators, etc) all use 7 data bits with parity.  You can definitely use
MacKermit to communicate with IBM mainframes in either mode, but certain
beta test releases of 0.9(36) had bugs relating to parity, which are fixed
in 0.9(40).]

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

Date: Fri, 20 May 88 08:07:33 EDT
From: [e-mail] (Ralph Hyre)
Subject: Does Windowed Kermit Exist?
Organization: Carnegie-Mellon University, CS/RI

I have a 19.2kbps 8-bit-transparent connection from my office to home.
(Bell of PA's Metropolitan Campus Network - I believe it's based on Project
Victoria technology - it will be upgraded to 64 kbps Real Soon Now.)

I sometimes transfer files using Kermit [4D(061) on a 4.3 Vax, MacKermit
0.7(21)], but the transfer times seem unreasonably long.  A minor glitch
is that the Kbyte estimates on the Mac are double what they can (and should)
be in reality.  The main problem is that my effective data rate is around
200 cps, when I'd expect at least 1000 cps.  The seems to be mostly because
there can only be one outstanding unacknowledged packet.  This makes the
effect of other delays in the system (mainly the intermediate routers and
terminal concentrators in between) intolerable.

Is there some Kermit variant that is available for Unix machines and Macs
that will support a 'window' (outstanding unacknowledged data, which is
presumably accounted for at some later time.)

This all makes X/Y/Z/MODEM/7 looks awfully tempting, since I know I have an
8-bit transparent path, except of course the MacTerminal I'm using makes it
practically impossible to download to disk other than the one MacTerminal is
on.  I'd rather fight than switch.

Thanks for any pointer and help you can provide.

                    - Ralph W. Hyre, Jr.

Internet: [e-mail]    Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA

[Ed. - When there are long round trip delays, a full-duplex sliding window
protocol is the best solution.  We hope that sliding windows will be added to
C-Kermit (and therefore Unix and Macintosh Kermits) in the next few months.
But then, we've been saying that for two years.  Meanwhile, long packets are
better than short packets, so try them in the current releases of Unix and
Macintosh Kermits.]

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

Date: 24 Apr 88 20:09:51 GMT
From: [e-mail] (Gadi )
Subject: Bi-directional Protocols
Keywords: Bi-directional Protocol

Does anyone know about a bi-directional protocol?  It seems to me that
having a MODEM or KERMIT type protocol running in both directions over a
phone link would double the thoughput.  I was thinking of this mostly with
respect to passing FIDONET, UUCP, etc mail.  Is there any reason why such a
protocol won't work?

                                          Gadi

uucp:   {ames, cbosgd, harvard, moss}!rutgers!aramis.rutgers.edu!friedman
arpa:   [e-mail]

[Ed. - Kermit and Xmodem would take some massive redesigning to transfer
files bidirectionally, to the extent that they wouldn't be Kermit or Xmodem
any more.  Once you leave the public arena, you can find some protocols that
claim to do this, like Blast.]

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

From: Gisbert W.Selke ([e-mail])
Date: 27 May 1988
Subject: Modcomp Kermit - A Bug and Two Suggestions
Keywords: Modcomp Kermit

I think I found a bug in Modcomp Kermit which sometimes caused it to crash a
file transfer without necessity. I think I've fixed it, and I've written a
letter to the authors for clearance.  The letter is appended below, together
with the fixed routine (SDATA).  In addition, I think one can make Modcomp
Kermit cope better with a particular Modcomp peculiarity (viz., using Ctrl-A
as a signal to the terminal maintenance processor - the standard Kermit
start of packet must be set to something different because every once in a
while TMP saw a Ctrl-A before Kermit could grab it).  One can do without
this change; but I think it's worth it for the sake of conformity to the
rest of the Kermit world.  Finally, an assembly-language subroutine has been
recoded into Fortran.  I'd like to hear suggestions from people more
knowledgeable than myself, though, before I proceed and install this change.

[Ed. - Thanks, Gisbert!  Your letter, with the suggested fixes, has been
placed with the Modcomp Kermit files as MODCMD.BWR.]

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

End of Info-Kermit Digest
*************************
-------
29-Jun-88 19:06:33-EDT,20270;000000000000
Mail-From: SY.CHRISTINE created at 29-Jun-88 19:05:00
Date: Wed 29 Jun 88 19:04:59-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #15
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 29 Jun 1988       Volume 7 : Number 15

Today's Topics:

                      Utility Program for Prime Tapes
                      RE: VAX C-Kermit Over X.25 PADs
                      RE: VME/10 Kermit Under Versados
                Bug in CD3KER vs. 3.4, CDC Cyber Nos Kermit
               Problems with Downloading Commodore 64 Kermit
                             MS Kermit and OS/2
              8-Bit Asynchronous Communication with Parity Bit
                  Bug in Macintosh Kermit Version 0.9(40)
                 Apple II Kermit and the Super Serial Card
                RE: Setting Flow Control for EMACS in Kermit
                            Kermit Over Networks
                       Automatic ISO 8859 Conversion

Send digest submissions to Info-Kermit@CU20B, requests for addition to or
deletion from the Info-Kermit subscriber list to Info-Kermit-Request@CU20B.

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host CU20B, CU20B.COLUMBIA.EDU, or
CU20B.CC.COLUMBIA.EDU (a DECSYSTEM-20), as user ANONYMOUS, using any password,
and GET the desired files from logical device KER:.  You can also get Kermit
files over BITNET/EARN; to get started send a message with text HELP to
KERMSRV, the Kermit file server, at host CUVMA.  For detailed instructions,
read the file KER:AANETW.HLP (AANETW HLP on KERMSRV).  To order by mail,
request a complete list of Kermit versions and an order form from Kermit
Distribution, Columbia University Center for Computing Activities, 612 West
115th Street, New York, NY 10025 USA.

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

Date: Fri, 10 Jun 88 17:51:04 PDT
From: Bob Larson <[e-mail]>
Subject: Utility Program for Prime Tapes
Keywords: Prime, tape utility program

Prime now supplies a utility (ux_tape) to read and write UNIX tar and cpio
tapes with the latest version of primos (21.0.2 and 21.0.3).  The bugs in the
21.0.2 version probably make in unusable, but it looks like tar tapes will be
a reasonable alternative to the program to read ANSI tapes that you currently
are supplying for Prime systems.  (21.0.3 has only been available a couple of
weeks, and most sites are still running pre-21 primos.)

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

Date: Sat, 21 May 88 14:39:59 EDT
From: elsie![e-mail] (Arthur David Olson)
Subject: RE: VAX C-Kermit Over X.25 PADs
Keywords: C-kermit

Re: Info-Kermit Digest V7 #12:

> We have a (*very* slow) VAX-11/780 running VMS 4.7; terminals connected to
> X25 PADs and make X29 calls into the VAX. We have all our lines set for 9600
> baud. C-Kermit works OK with normal packet sizes, and it sends files *to* the
> PC with 250 byte packets OK. However, trying to use any packet size about 200
> bytes or so *from* the PC results in repeated retries; the log shows that the
> VAX is giving "Data Overrun" errors on about 1 in 3 packets.

The same sort of thing happens with PCs connected via DZ11s; the VAX just
can't drain the DZ11's silo fast enough, resulting in silo overflow.

So. . .here at elsie we don't even try; we've set MAXRP to 94.

   *** 1.1/ckcker.h    Sat May 21 14:37:26 1988
   --- 1.4/ckcker.h    Sat May 21 14:37:28 1988
   ***************
   *** 26,31 ****
   --- 26,35 ----

     #define MAXSP 2048            /* Send packet buffer size  */
     #define MAXRP 1024            /* Receive packet buffer size  */
   + #ifndef ASWAS
   + #undef MAXRP
   + #define MAXRP 94            /* ...or suffer buffer overruns */
   + #endif /* !defined ASWAS */
     #define MAXWS 1                /* Maximum window size */

     /* Kermit parameters and defaults */
--
    Canada's program is to spaceflight as the carrier pigeon is to mail.
    [e-mail]            ADO is a trademark of Ampex.

[Ed. - Thanks....  It has been added to KER:CKVKER.BWR.]

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

Date: Thu, 19 May 88 19:53:50 {o
From: [e-mail] (Alan Martello)
Subject: RE: VME/10 Kermit Under Versados
Keywords: VME/10 Kermit

Response to inquiry in digest V& #5 concerning VME/10 Kermit under Versados

Motorola has now included the KERMIT protocol in the TRANSFER command for
release 4.6 of Versados (untested, but according to the 4.6 doc.).  I have
not tried to run this since all the Versados machines I use are frozen at
Version 4.5, but from previous experience with Motorola supplied software, I
would not hold my breath.  I did not attempt to run the executable from 4.6
under 4.5 since the 4.6 documentation indicated that a new device driver
call to handle character I/O more reasonably was added to Versados 4.6,
although it did not mention Kermit explicitly.

(*FLAME ON* I made the assumption that Motorola could not easily port Kermit
without adding the new driver call since Versados handles just about all its
I/O in a brain-damaged fashion. *FLAME OFF*)

I would give Versados 4.6 a try if you have it available, but remember that
Motorola is the same company that provided the tape backup support which I
used to save a corrupted Fujitsu Eagle (150 MB) under Versados only to find
that their restore program could only read the first tape of a three volume
save set!!!  (I guess they never tried to read more than 60 MB of
information).

Good Luck!

Alan Martello
University of Pittsburgh

UUCP: { akgua | allegra | cmcl2 | idis | ihnp4 | mi-cec | pitt
    psuvax1 | sun | sunrise | vax135 } ! cadre ! arm
ARPA: [e-mail]

DISCLAIMER - the views expressed above concerning Versados and Motorola
software are entirely my own after working with their '680x0 development
environment' for three years.

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

Date: Fri, 27 May 88 14:00:48 -0800
From: ames!tis.llnl.gov!lll-tis!lll-crg!lll-winken!uunet!convex!otto!jimi!unsvax.uucp![e-mail]
Subject: Bug in CD3KER vs. 3.4, CDC Cyber Nos Kermit

I have been installing the latest Kermit distribution for CD3KER vs. 3.4
for the CDC Cyber NOS systems and I discovered an error in the CD3KER.MOD
file. The problem concerns the fact that the modified array SETTYP must be
in alphabetical order for the Fortran subroutine MATCH to work correctly.
To fix the file CD3KER.MOD replace the following four lines -

*D 1041
     +    'TEXT-MODE', BIN-MODE', 'EOR-EOF-MODE' /
*D 1046
      GO TO (20,30,40,10,50,70,75,80,90,100,110,120), INDX

with the following six lines -

*D 1039,1041
      DATA SETTYP /  'BIN-MODE', 'DEBUG', 'DELAY', 'DUPLEX',
     +    'EOR-EOF-MODE', 'FILE-MODE', 'INIT-RETRY', 'RECEIVE',
     +    'RDELAY', 'RETRY', 'SEND', 'TEXT-MODE' /
*D 1046
      GO TO (110,20,30,40,120,10,50,70,75,80,90,100), INDX

I should add that I have installed CD3KER vs. 3.4 on an older Cyber NOS
l647 and everthing seems to work except for the CDCNET versus NPU test
in Program KRM0100.

Dave Bartlett
UNS Computing Services
[e-mail], [e-mail],
or via BITNET as AC34U05@UNEV

[Ed. - Thanks.  Your message has been put in KER:CD3KER.BWR.]

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

Date: Sat, 04 Jun 88 23:28:29 MET
From: Jos Grote Punt <[e-mail]>
Subject: Problems with Downloading Commodore 64 Kermit
Keywords: C64 Kermit

Many people have a problem with dowloading and converting C-64 Kermit. The
cause is a bug in the file C64DXL.HEX. In the file C64KER.HLP it says that
with C64DXL.BAS you can convert this hexdump file into a hexdump loader. With
this loader (called C64DXL.C000) you can then convert C64KER.HEX to a running
version of Kermit. The help file states that you should save the file with the
last address displayed by C64DXL.C000. You will never see this address because
of the bug. It works ok if you change $00 on address $C20A in $60 (BRK changed
in RTS).

Besides that there's another problem with C64KER.HEX. This file is in the so
called MINMIC hexdump format, where a every line looks like this:
  1. A ';' that marks the beginning of the line
  2. The number of data bytes
  3. The adress (in HIGH-LOW format) from which this line is to be loaded
  4. The data bytes itself (A-F in uppercase)
  5. Two-byte checksum (HIGH-LOW format), being the sum of all other bytes

The last line has a 00 as the number of data bytes. So, what's wrong with
C64KER.HEX? It has two databytes less than above item 2 says! Result: the hex-
dump file loads ok, but the checksum can't be checked. This means that if you
were lucky and there was no error during the download of C64KER.HEX than the
resulting Kermit will work, in the other case you have a big problem! The
strange thing is that the file C64DXL.HEX is allright.
I hope this info can help some people.

Jos Grote Punt
Faculty of Medicine
University of Nymegen
The Netherlands

[e-mail]

[Ed. - Many thanks for the report!  It's been added to the C64KER.BWR file.]

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

Date: Thu, 21 Apr 88 11:46 PDT
From: [e-mail]
Subject: MS Kermit and OS/2
Keywords: MS-Kermit, OS/2

Has anyone begun development to enable MS-Kermit to be multitasked under
OS/2?  If so, estimated time schedules?  Please CC: me directly as I don't
often read this digest.  Thanks.

David J. Buerger
Santa Clara University
[e-mail]

[Ed. - This is a popular question.  Someone has been working on porting
C-Kermit to OS/2 and this should be available shortly.  In the longer term,
some thought is being given to adapting MS-Kermit to full OS/2 compatibility,
but this will take some time.  Meanwhile, it's possible that "WINKRM" -- the
MS-Windows version of Kermit -- can be used under OS/2 to transfer files
while other processes are active, as it can under Windows itself.  A new
version of WINKRM has just arrived and will be announced as soon as it's
installed.  Meanwhile, the current version of MS-Kermit runs in DOS
compatibility mode under OS/2.  As Joe Doupnik reports "Throughput seems
terrific, given my DOS AT on one side and the Model 80-111 running OS/2 on
the other.  A 9600 baud line yielded about 8400 effective for a long text
file.  The only difference so far is if one asks a Kermit server to write to
a protected disk the OS/2 error menu pops up rather than letting Kermit
manage it; telling OS/2 to let the error flow to the program yields Kermit's
normal graceful recovery."]

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

Date: Fri, 15 Apr 1988 11:18:56 IST
From: "Jonathan B. Owen" <[e-mail]>
Subject: 8-Bit Asynchronous Communication with Parity Bit
Keywords: RS-232, Asynchronous Communication, Data Bits, Parity

I keep reading all too often of people writing that 8-bit communication is
mutually exclusive with a parity bit.  Actually, each frame, or character
transmitted over an async. link starts with a Start-Bit followed by 7 or 8
Data-Bits, followed by an optional Parity-Bit, and finally terminated with
1, 1.5 or 2 Stop-Bits.  In effect, besides the framing bits, a maximum of 9
bits are possible for each char.

The reason I write this, is because I wanted to use Mac-Kermit 0.9(36) with
an IBM/370.  Apparently, you cannot set 8 bit communication with Mac-Kermit.
Also, I ran across another program on the Mac which lets you select EITHER 8
bit communication or 7 Bit with Parity, which is rediculous (can't remember
name of program off hand).

I hope this letter clears things up a bit (or 9 bits!).

Email: gdau100@bguvm (bitnet)
Snail: 6/15 Mendelson, Tel-Aviv  Israel
Voice: [phone]
Jonathan B. Owen

[Ed. - In theory, you're right.  In practice, it depends on the UART.  Many
UARTs simply do not give you the option, or even if they do, the
corresponding device drivers do not.  Nor do most modems, PADs, or other
communication equipment.]

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

Date: Sun, 19 Jun 88 21:53:42 +0100
From: Eamonn McManus <[e-mail]>
Subject: Bug in Macintosh Kermit Version 0.9(40)
Keywords: MacKermit 0.9(40)

There is a trivial but annoying bug in Mac Kermit 0.9(40), as released to
comp.binaries.mac on Usenet.  (The version says it is Kermit version 0.9(40),
04/05/88 11:51.)  The default settings for tab stops place the last one at
column 71 (zero-origin) rather than 72 as it should be.  Most of the time
this doesn't show up (which is presumably why the bug hasn't been fixed so
far) but it is quite noticeable in editors like vi that attempt to optimise
cursor motion, frequently by using tabs.

Here is a patch that fixes the bug.  The version of ckmcon.c is that from
0.9(36)b4 but I assume it hasn't changed.

Since I don't have the 0.9(40) sources, I've had to patch the binary.  This
involves editing block 132(dec) and changing byte 0x19c to a 0, and byte
0x19e to a 1.

Eamonn

[Ed. - Thanks.  Your message has been put in KER:CKMKER.BWR.]

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

Date: Wed, 16 Mar 88 15:54 N
From: [e-mail]
Subject: Apple II Kermit and the Super Serial Card
Keywords: Apple II Kermit

I am attempting to load and run KERMIT on an Apple IIe minicomputer.  The
documentation for KERMIT in the file APPLE.DOC hints about some possible
problems to be encountered in this situation, especially when using the
APPLE SUPER SERIAL CARD.  Please send suggestions and/or newly updated
documentation for the installation of KERMIT on the APPLE IIe.

As a secondary attempt I have installed a Z-80 coprocessor card into my
Apple IIe.  I have then tried to use the Kermit programs: CPMAPPLE, CPMPLUS,
CPMGENER, and KERMIT version 4.3, all without success.  The KERMIT programs
load properly, but will not execute the CONNECT command without hanging up.
Both the SSC card and CPM card and these versions of KERMIT work properly on
an APPLE II+ in our laboratory.

Thank you for your assistance and cooperation.

Sincerly yours,

Timothy Good         Centre de Recherches en Physique des Plasmas
                         Lausanne, Switzerland
Bitnet address: SIEGRIST@CLSEPF51

[Ed. - From Ted Medin, maintainer of Apple II Kermit: The super serial card
and driver are probably the most bullet proof part of kermit-65. Since it
works on the //+ and not the //e i suspect they have hardware problems with
their //e. I use the //e or //e+ all the time and am using it right now with
a super serial card. Is there a difference with export models of the //e????]

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

Date: Tue, 5 Apr 88 17:53:39 EDT
From: [e-mail] (Paul Placeway)
Subject: RE: Setting Flow Control for EMACS in Kermit
Keywords: Flow Control, EMACS

< >[Ed. - The real, though painful, workaround is to SET FLOW NONE before you
< >start EMACS, and SET FLOW XON/XOFF when you exit EMACS, see below.]

< How about some escape sequence the host can send to Kermit to turn
< flow-control on and off.  Emacs (GNU Emacs anyway) can be configured
< to send such a sequence when entering or exiting.

The _best_ way is to make your micro use a real big serial input queue (that
is what MacKermit does).  If you can't do that, then if you are running Gnu
Emacs, there is a _much_ better way to deal with this: In your .emacs (for
Unix system; VMS uses some other name), include:

;;; for stupid ^S and ^Q problems (sets ^^ to be ^Q, ^\ to ^S,
;;; ^S to ^\, and ^Q to ^\, and makes ^\ ignored).
;;; NOTE: the second line of the string must NOT be indented!!
(setq keyboard-translate-table
"\000\001\002\003\004\005\006\007\010\011\012\013\014\015\016\017\
\020\036\022\036\024\025\026\027\030\031\032\033\023\035\021\037")
(global-set-key "\036" 'ignore)

and get used to typing ^\ for I-Search and ^^ for Quote.  I also remember
some way of making emacs actually use ^S and ^Q for flow control, but I
can't remember off the top of my head.

        -- Paul

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

Date: Fri, 24 Jun 88 16:34 CST
From: [e-mail]
Subject: Kermit Over Networks
Keywords: MacKermit 0.9(40), MS-DOS Kermit 2.31

I am looking for communications programs, preferably versions of Kermit,
that can connect from PC compatibles or Apple Macintoshes to VAXen across an
Appletalk (Localtalk) network.  Specifically, our configuration is this: In
several administrative offices at the college, we are adding small Phonenet
networks (running Appletalk protocols) primarily to allow sharing of Apple
LaserWriters.  In the new construction, there is only one data port
connection in the wall for each computer, so connection to the VAXen should
be through the local network.  The VAXen are connected to the Appletalk
(LocalTalk) network through Ethernet via a Kinetics FastPath.  The
microcomputer software will be either TOPS or Appleshare.  The VAX
connection is very simple, just VT100 emulation and standard Kermit server
file transfers.  Kermit-MS version 2.30 has support for NetBIOS local area
networks, but not for Appletalk.  MacKermit 0.9(40) seems to have no LAN
support.  If you have an Appletalk-aware version of Kermit, or if you can
comment on any Appletalk-aware communications packages, please let me know.
I read Info-Kermit regularly, but it may be difficult to reach me through
the network, so please respond to:

        Sande Nissen
        Computer Center
        Carleton College
        One North College Street
        Northfield, MN  55057
        [phone]
    net: [e-mail]

[Ed. - Appletalk support is not in MacKermit currently, but it's on the
"wish-list."  For MS-Kermit, the best solution would be an independent
BIOS-level device driver which Kermit could take advantage of using either
its built-in BIOS or NetBIOS support (SET PORT BIOSx, SET PORT NET).  Is
anyone aware of work going on in this area?]

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

Date: 1 Jun 88 11:47:08 GMT
From: mcvax!rhi.hi.is![e-mail] (Fridrik Skulason)
Subject: Automatic ISO 8859 Conversion
Keywords: ISO Standards, Character Sets
Organization: University of Iceland (RHI)

Regarding a recent note about automatic text conversion to ISO 8859/1.

As a matter of fact, we did just this here in Iceland a few years ago, while
this standard was still known here just as "ECMA code". The reason was of
course, that the first PCs had arrived here, and we often had to transfer
text to/from our VAX, which used modified 7 bit ASCII.

Later we added a translation table to Mackermit, where a small problem
appeared, namely that not all characters in the Mac character set could be
translated into ISO codes. This problem was simply ignored, and all
"untranslatable" characters were just translated into a single "junk"
character. The reason was simply the low frequency of those characters in
normal text ( << 0.1%)

As a matter of fact, we are back to using the original unmodified VAXkermit
(on our two VAXes) and Ckermit (on our HP9000), since we now use ISO 8859/1
on those computers, and therefore no translation is needed there. (Well -
almost unmodified - I think we had to delete one instruction which stripped
off the eight bit somewhere.)

ISO 8859/1 is very popular here in Iceland (Not surprising, since it is the
first major international character set standard which supports all our
special characters) We are getting tired of having to modify everything
else, like the HP Roman8 or the IBM/PC character set, so please make this
change to Kermit (or better still - start using 8859/1 on your computers).

         Fridrik Skulason          University of Iceland
         UUCP  [e-mail]      BIX  frisk

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

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