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

Text File | 2020-01-01 | 269KB | 6,138 lines

 8-Jul-88 14:38:29-EDT,11330;000000000000
Mail-From: SY.CHRISTINE created at  8-Jul-88 14:37:32
Date: Fri 8 Jul 88 14:37:32-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V8 #1
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri,  8 Jul 1988       Volume 8 : Number 1

SPECIAL ISSUE:

        Announcing MS-DOS Kermit 2.31

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 8 Jul 88 13:39:29-EDT
From: Christine Gianone <[e-mail]>
Subject: Announcing MS-DOS Kermit 2.31
Keywords: MS-DOS Kermit 2.31

This is to announce version 2.31 of MS-DOS Kermit for the IBM PC and PS/2
families and compatibles, the DEC Rainbow, the HP-150 and 110, the Grid
Compass II, and for "generic DOS".  This release replaces version 2.30 of
January 1988.  The majority of the work was done by Professor Joe R. Doupnik
of Utah State University, who also prepared the 2.29 and 2.30 releases.

The program requires DOS 2.0 or later, and 100K+ of memory.  The major new
features include an expanded script language, new communication options, Kermit
File Attribute support, improved user and system interfaces, additional
terminal emulation features, and many internal fixes and enhancements, plus
a new manual and other documentation.  The new features are described more
fully at the end of this message.

The executable files are stored in a special printable format, called "BOO
files", suitable for BITNET file transfer, electronic mail, etc.  These are
decoded into .EXE files using a "BOO-file decoder" program.  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*.*        185K total  BOO-file encoding/decoding programs (many)
 KER:MSVIBM.BOO    113K        IBM PC Kermit, BOO-encoded executable
 KER:MSVRB1.BOO     82K        DEC Rainbow Kermit BOO file
 KER:MSVGEN.BOO     77K        Generic MS-DOS Kermit BOO file
 KER:MSVHP1.BOO     77K        HP-150 (untested)
 KER:MSVHPX.BOO     77K        HP-110 and Portable PC (untested)
 KER:MSVGRI.BOO     77K        Grid Compass II (untested)
 KER:MSKERM.DOC    312K        MS-DOS Kermit manual, plain ASCII text
 KER:MSKERM.MSS    302K        Scribe text formatter source for manual
 KER:MSKERM.HLP     16K        A summary of MS-Kermit commands
 KER:MSKERM.BWR     16K        List of known restrictions, bugs, etc.
 KER:MSS*.*        760K total  System-independent MASM Source files (12 files)
 KER:MSG*.*        120K each   System-dependent source (graphics, IBM only)
 KER:MSU*.*      72-87K each   Sys-depn source (keyboard support, all systems)
 KER:MSX*.*     40-168K each   Sys-depn source (port i/o, etc, all systems)
 KER:MSY*.*        106K each   Sys-depn source (terminal emulation, IBM only)
 KER:MSZ*.*        181K 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, allows
convenient determination of MS-Kermit's keyboard codes on the IBM PC
family.  And the files MSIXSE.* are the XSEND program, contributed by Mark
Zinzow, for constructing MS-Kermit command files that send entire directory
trees from one DOS system to another.

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, HP1, HPX, 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.

3. If you don't have an MSBPCT "BOO-file decoder", also get at least MSBPCT.BAS
   (the slow BASIC version) and MSBPCT.BOO (an .EXE version from C, which
   you can decode with MSBPCT.BAS).

4. 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, DEC Rainbow, and HP-150 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.  The HP-150
version is on 3.5" diskette.

New features for release 2.31 include...


SCRIPT LANGUAGE:

Kermit's script language has been significantly expanded.  It has become a
regular little programming language, similar to what's found in the commercial
packages:

 - Substitutable parameters in macro invocations, similar to DOS Batch.
 - Variables can be defined, referenced, and undefined.
 - GOTO and labels for transfer of control within a TAKE file or macro
 - An IF statement for testing conditions including SUCCESS or FAILURE of the
   preceding  command (like SEND, GET, RECEIVE, INPUT, etc), or the time of
   day, or whether a file exists, or whether a variable is defined, etc.
 - A loop counting mechanism.
 - A way to reexamine text that has already been INPUT.
 - A way to test for the modem signals CD, CTS, and DSR.
 - Limited interaction with user ("Type any key when ready...")


A WIDER RANGE OF COMMUNICATION OPTIONS:

 - SET PORT COMn (n = 1 to 4).  Support for COM1 through COM4 on the IBM PC/AT
   and PS/2 series.
 - SET PORT BIOSn (n = 1 to 4).  Support for communication ports 1 to 4, using
   Bios-level drivers, like those supplied with certain local area networks.
 - SET PORT NET [<nodename>] as in 2.30, for NetBios-based local area networks.
 - SET PORT UB-NET1 for Ungermann-Bass Net/One.

Ungermann-Bass code contributed by Henrick Levkowetz (Philips Kista AG,
Stockholm) and Renne Rehmann (Switzerland)

FILE ATTRIBUTES:

Kermit File Attributes packets are now exchanged with other Kermit programs
that know about them.  This lets MS-DOS Kermit know the size of incoming files
in advance, lets it reject them if there's not enough disk space, and lets
MS-Kermit display the percent done for incoming as well as outbound files.
Attribute packets also allow arriving files be stored with their original
creation dates and times.  This mechanism has been tested successfully with
Kermit-370 on IBM mainframes, PDP-11 Kermit, and with MS-DOS Kermit itself.

A new MAIL command, that lets MS-Kermit send a file to a Kermit server with
instructions (in an Attribute packet) to deliver it as mail to a specified user
(as yet, no Kermit servers can do this).


USER AND SYSTEM INTERFACE:

 - A new HELP command was added (a concise screenful of text, nothing fancy).
 - A new transaction logging feature was added.
 - CD is now a synomym for CWD.
 - Macros can be invoked by name, without DO.
 - Improved operation under MS-Windows (PgUp/PgDn now work).
 - Error messages redesigned to be more helpful.
 - Long Kermit commands in TAKE files can be continued onto subsequent lines.
 - Many new SHOW commands, for different groupings of paramaters.
 - Macro definitions can be shown individually.
 - The Kermit command line interface now permits full 8-bit character inputs.
 - "kermit < todo.lst > todo.log" works.
 - "sort < todo.lst | kermit" works.
 - Kermit's return status code is now user-settable, via SET ERRORLEVEL.
 - ERRORLEVEL now set correctly after SEND.

TERMINAL EMULATION:

 - Tektronix emulation improvements.
 - User can identify graphics adapter explicitly.
 - VGA 640x480 graphics now supported.
 - VT102 scrolling within region speeded up.
 - A new \Kholdscrn verb has been added (VT100 "hold screen").
 - The VT102 emulator now supports escape sequences to control local echoing.
 - Reply to ESC Z "what are you?" query changed from "ESC[?6;2c" to "ESC[?6c".
 - VT52 printer-control escape sequences ESC W and ESC X now work.
 - Ctrl-@ now sends ASCII NUL (0) by default.

OTHER CHANGES:

The SERVER command now accepts an optional time limit, to make the server
shut down after a certain amount of elapsed time or at a given time of day.

The SPACE command no longer requires presence of CHKDSK.COM, and therefore
no longer hangs the MS-Kermit server if it finds something wrong with the disk.

Some internal forward references were juggled so that MS-Kermit 2.31 can
be assembled with Microsoft MASM 5.1 (2.30 could not be...)

Echoed XOFFs are now detected and no longer cause a deadlock.

Under network operation, 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.

The inevitable bug fixes.

FINAL WORDS:

Like any Kermit program, MS-DOS Kermit is for everyone to use and share.
Please take or order the files you need.  If you're getting files over a
network, please be judicious -- don't ask for KER:MS*.*, or the networks will
be choked for months!  Once you get a working copy at your site, share it with
others, rather than having them make further network requests.

Send complaints, bug reports, suggestions, comments, or even praise and
testimonials (where they're deserved) to Info-Kermit@CU20B (.CC.COLUMBIA.EDU).
And thanks once again on behalf of the world's thousands or millions of MS-DOS
Kermit users to Joe Doupnik for his skill, generosity, and patience.   And
thanks also to the beta testers.

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

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


-------
14-Jul-88 18:25:59-EDT,22668;000000000000
Mail-From: SY.CHRISTINE created at 14-Jul-88 18:25:11
Date: Thu 14 Jul 88 18:25:11-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V8 #2
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 14 Jul 1988       Volume 8 : Number 2

Departments:

  ANNOUNCEMENTS -
        Announcing CTOS/BTOS Kermit 1.07

  PORTABLE 370 KERMIT -
        Re: Kermit-370 Report

  MACINTOSH KERMIT -
        MacKermit 0.9(40 -Transfer of Mac Applications, How?
        MacKermit Flaw
        MAC <> UNIX Mainframe File Transfer
        Trouble de-BinHexing MacKermit 0.9(40)
        MAC II Session Logging
        MacKermit 0.9(40)
        Suggested Enhancement for MacKermit
        RE: Basic MacKermit Help
        MacKermit Functionality
        Bug in MacKermit?
        Problems with MacKermit 0.9(40)

  MISCELLANY -
        C64 kermit Download Problem (2 messages)
        C-Kermit for Intel 310 Xenix 3.0?
        Proposal for a New 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: Wed, 6 Jul 88 16:27:20 edt
From: Joel Dunn <[e-mail]>
Subject: Announcing CTOS/BTOS Kermit 1.07
Keywords: CTOS, BTOS, Convergent NGEN, Burroughs B20

Last fall I sent you a copy of Kermit that I had ported to CTOS on Convergent
NGEN systems and BTOS on the Burroughs B20.  I just dropped another version
in the mail that adds a few features and fixes a few bugs.  This version I
call CTOS-Kermit 1.07, and the most significant feature is probably its VT100
emulation in terminal mode.  It isn't a perfect VT100, but it works for most
things without blowing up.  I have had this version in distribution since
January, and have have heard positive feedback, and I have not heard from
anyone that was having problems.

--Joel Dunn, UNC-Chapel Hill Administrative Data Processing

[Ed. - Thanks, Joel!  The new version has replaced the old one as KER:CT*.*
in the Kermit Distribution.  The files and naming conventions are listed in
KER:CTAAAA.DOC.  The program is based on an old release of C-Kermit, but Joel
says that when he gets C-Kermit 4E(070) he will try to add the CTOS/BTOS
support to it, so it will be yet another of the regular C-Kermits.]

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

Date: Fri, 1988 Jul 1   22:21 EDT
From: (John F. Chandler)   [e-mail]
Subject: Re: Kermit-370 Report
Keywords: Kermit-370

> Subject: IBM 370 Kermit 4.0 bugs (?), questions
> Keywords: IBM 370 Kermit 4.0
>
> I'm using TSO-Kermit 4.0 on a COMPAREX 7/88 with MVS/XA with VTAM and
> IBM7171 controller. After downloading some files in server mode, I give a
> REMOTE KERMIT TDUMP NAMES command to see the amount of files transferred.
> After that i give a REMOTE KERMIT STATUS command. Now again a REMOTE KERMIT
> TDUMP NAMES command and here the size of the last file is changed to 0K.
> This happens only in server mode, but also with CMS-Kermit 4.0.

Yes, the last file in the list is vulnerable -- this can also happen if
you interrupt a multi-file transfer via ^X/^Z.  Someday, I'll see about
fixing this.

> The REMOTE TYPE command works, but the TYPE command at the prompt level
> doesn't work. I got a "MODULE 'LIST' NOT FOUND" error. The COPY command
> doesn't work either.

TYPE assumes you have a LIST command available on your system -- if you
don't, it should be easy enough to get one.  The same is true of COPY
(IBM and other vendors offer packages including LIST, COPY, MERGE, and
others).

> The DIRECTORY command doesn't work with a parameter or with wildcards as
> DIR *.FOR

Yes, DIR just uses the LISTCAT facility under TSO.  If you want more
sophisticated options than "LISTC" or "LISTC LEVEL(...)", you'll have
to issue the command directly.

> When I'm using long packets, the packet size is at about 995 for a long time
> (many Kbytes) and then suddenly shrinks to about 500 or less. There are only
> 2 or 3 repeat packet for 200K data. So this feature does not satisfy me.

By my calculation, 3 repeat packets at 100K of data will reduce the size
to about 700, but the size will then gradually recover.  The size
shouldn't drop to 500 without at least 7 transmission errors.  All this
aside, the throughput with 1000-byte packets is not a great deal more
than that with 500-byte packets, even with a noise-free line, unless the
the line turn-around time is large.  See the Kermit Newsletter (summer
1988) for a discussion of throughput.

> How does the kermit HELP command work? I only get "HELP NOT AVAILABLE+",
> while the TSO HELP KERMIT command works well.

It seems I left detailed descriptions of the HELP command out of both
the CMS and TSO Kermit documentation!  The syntax is very simple:
for TSO, type either HELP or HELP <subcmd> for information about
Kermit as a whole or about a particular subcommand.  For CMS, type
just HELP.

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

Date: Fri, 10 Jun 88 23:29:11 EDT
From: [e-mail]
Subject: MacKermit 0.9(40 -Transfer of Mac Applications, How?
Keywords: MacKermit 0.9(40)

I had been experimenting with MacKermit 0.9(40) without documentation and
having no success in transferring a binary file to my Mac. Upon perusal of
the newly released documentation, I confirmed a suspicion that my problems
were due to MacKermit's inability to perform MacBinary conversion. However,
it is not obvious to me how to compensate and obtain a binary file. Is there
some arcane process involving ResEdit required to reassemble data and
resource forks transmitted as two separate files? (I assume that is how the
pieces must be sent.) Any help with this problem would be appreciated.

- Maretta Holden

[From Paul Placeway - Since Kermit (and hence MacKermit) is designed to send
only single fork files, the best way to transfer applications is to use
something like BinHex or StuffIt to put the data and resource forks and the
finder info into the data fork of a single file, send that to the other Mac,
and unpack it again.]

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

From: [e-mail] (Dave Thompson)
Subject: MacKermit Flaw
Date: 9 Jun 88 16:57:04 GMT
Keywords: MacKermit 0.9(40)

I just finished a cursory evaluation of Kermit 0.9(40) and found one rather
fatal flaw.  There is no option to make the delete key send a backspace
rather than a delete character.  While many of our mainframes (if not most)
accept, or can be made to accept the delete key, we have a few that require
use of the backspace character.  While I guess you *can* use control-h,
that's sort-of tedious.  For those of you who wrote this program, how about
an option to change this (rather as VersaTerm of MacTerminal does)?

Dave Thompson             uucp:   {ihnp4|hplabs|psivax}!csun!csuna!dlt
CSUN Computer Center         phone:  [phone]
18111 Nordhoff Street, Northridge, CA 91330

[From Paul - Bind a macro of a Control-H to the delete key; the easist way to
type in the macro is either "\^h" or "\010" (don't include the double quotes).]

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

Date: 16 Jun 88 14:24:25 GMT
From: ut-sally!ut-emx![e-mail] (The Mad Hatter)
Subject: MAC <> UNIX Mainframe File Transfer
Keywords: MacKermit, C-Kermit

I have a seemingly simple question:

Whenever I do a file transfer from the unix mainframes to the Mac II, the
text file gets all messaed up. Line sequences are disrupted, square boxes
(what does that character mean?) are inserted at the beginning of lines). I
use kermit via a Red Ryder program.  Any suggestions/solutions for this
problem ? Is there any way I can transfer a file EXACTLY the way it is ?
Also, I use Macwrite to open the file on the MAC II.

Jim The Mad Hatter

[From Paul - The main problem with transfering files between Unix and a Mac is
the newline character.  On Unix, a newline is a Linefeed (Control-J), but on a
Mac it is a Return (Control-M).  If a text file is transfered to a Mac in
binary mode, everything will look fine except that wherever there should be a
newline, there is a little box character instead (indicating a Linefeed
character).  So the real question is do you want the file transfered exactly
as-is, in which case you would use binary mode, or do you want the newlines
converted, in which case you want to use text mode.]

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

Date: Sat, 18 Jun 88 15:49:26 PDT
From: [e-mail] (Sean Patrick Burke)
Subject: Trouble de-BinHexing MacKermit 0.9(40)
Keywords: MacKermit 0.9(40)

  I have downloaded MacKermit 0.9(40) to my Mac, but have had trouble
with the BinHex step:  BinHex version 5.0 says "no checksum error".  The
MacKermit file is stated to be encoded in BinHex version 4 format.

  Do my troubles arise from incompatible versions of BinHex?  Are there other
possibilities I may have overlooked?  Any advice will be appreciated.

Thanx much,
Sean Burke

[From Paul - Make sure the first line of the file says
 "(This file must be converted with BinHex 4.0)"

ckmker.hqx should be 100781 bytes long on a Mac or a Unix box; if it's
too short, re-ftp it.]

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

Date: Thu, 23 Jun 88 08:34:33 PDT
From: [e-mail]
Subject: MAC II Session Logging
Keywords: MacKermit 0.9(36)b4

I am having problems with writing a session log when using MacKermit .9(36)B4
on a MAC II.  When choosing write session log from the settings menu,
Kermit goes through the motions of writing a log; however, after discontinuing
the log, the file Kermit session is nowhere to be found!

Any pointers on where i'm going astray would be greatly appreciated!

Thank you in advance for your time on this one.

Dan Calderwood
Humboldt State University
Academic Computing
BITNET:GDCWOOD@CALSTATE

[From Paul - There seems to be some problems with the log files being created
invisible on some Macs.  I haven't had it happen to me, and the code that
creates the log file looks fine, so I really don't know what is going on.  The
only thing I can say off hand is make sure you have version 0.9(40).]

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

Date: Tue, 05 Jul 88 14:56:27 EDT
From: <[e-mail]>
Subject: MacKermit 0.9(40)
Keywords: MacKermit 0.9(40)

I am running MacKermit 0.9(40) on a Mac II. I am getting older. My eyes
are getting poorer. And MacKermit uses the top left 1/4 or the screen on
my Mac II! Is there a possibility of MacKermit using the full screen
on a Mac II? Before my eyes give out completely?

Larry Bradley
Communications Manager
National Research Council of Canada
Networks Branch
Ottawa, Canada
[phone]

[From Paul - The non-changable MacKermit terminal emulator window is a
problem, but it will take quite a bit of work, because MacKermit knows deep in
its heart that the terminal window is a fixed size and each character is also
a fixed size.  If anyone else does it first, I'll be more than happy to include
it (actually, I'll probably jump up and down 8-)

MacKermit 0.9(40) already does background file transfers under MultiFinder
(although it doesn't unhighlite the top window correctly yet).

Typeing into the file dialog box will take a bit of work; I'll take a look
at it.]

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

Date:  Tuesday, 19 January 1988 19:59 edt
From:  David M. Rosenberg <Rosenberg>
Subject:  Suggested Enhancement for MacKermit
Keywords: MacKermit

The Macintosh normally uses the OPTION key in combination with certain other
keys (E, I, U, N, & `) as dead key accents.  These dead keys produce no
character themselves.  However, when they are followed by certain
(alphabetic) characters, the dead keys apply the specified accent to the
specified alphabetic character.  This behavior is normally desirable.
However, within Kermit's terminal emulator, you may want to use the OPTION
key as a general modifier (as set in the "Set modifiers
..." dialog).  In that case, you would probably like all "OPTION-letter"
combinations to act in a uniform mannor, not have a few of them be dead
keys.

The VersaTerm terminal emulator provides a switch (to be set with ResEdit)
that controls whether "OPTION dead keys" are enabled or disabled while
VersaTerm is running.  If they are disabled, OPTION-E generates a keydown
event with only one keystroke.

I request that you consider adding a similar switch to Macintosh Kermit
(probably in the "Set modifiers ..." dialog) to control whether dead keys
are enabled or disabled while the terminal emulator is running.

 /David M. Rosenberg ([e-mail])

[From Paul - As soon as OSU gets a hold of a real MPW 2.0 (we are running
MPW 2.0 a4, w/o the script manager stuff), I will add exactly this, except
that it will be (yet another) dialog settable option.  Actually, the code is
allready there, but not tested.

I have had a number of different requests for additions to the key mapping
scheme.  I personally would like to use the Option key as a Meta key (sets the
8th bit, for Emacs), but I also know of people who would like to use Option as
a control key, as a way of addressing extended characters (vowels with
accents, for example).  There are probably also thing that no one is
interested in doing, so I am taking a survey: what do you want Kermit to do
with the keyboard?  Please send responses to me ([e-mail]).
I will summarize the results to Info-Kermit, and work on implementing whatever
isn't but needs to be.]

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

Date: Mon, 11 Apr 88 11:55:49 EDT
From: "Robert E. Zaret" <[e-mail]>
Subject: RE: Basic MacKermit Help
Keywords: MacKermit, RedRyder

I just downloaded and then uploaded a text file from CMS-Kermit 3.1 to
RedRyder 10.3 Kermit with no problems.  On the mainframe end, I used
the SEND and RECEIVE commands.  The required settings depend on the
type of connection:
   TTY lines:
        Kermit handshake set to ^Q (ASCII decimal 17)
        general (terminal emulation) flow-control none
   Full-screen lines (via protocol converters such as 7171 or Series/1):
        Kermit handshake set to none
        general (terminal emulation) flow-control XON/XOFF
I generally avoid server mode (my first impression suggested it can be
flakey and error-recovery can be more difficult).

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

Date: Mon, 11 Jul 88 15:46:06 edt
From: [e-mail] (Steve Caldara)
Subject: MacKermit Functionality
Keywords: MacKermit 0.9(40)

Hi,
   I would find the following functionality very useful if it was added to
   MacKermit.

    1. Resizable window with zoom box.  (I've requested this previously)

        2. Background file transfer under MF ( Ditto above )

[Ed. - 0.9(40) has this.]

        3. The ability to 'type' the name of the file in the file dialog box
           when uploading files to a remote host.  I do a lot of uploading of
           postscript files to our unix hosts and then print them to a
       laser writer.  I am trying to semi-automate the process with
           'Quick Keys'  After I've created the postscript file using Clover-F
       I use the 'Find File' DA to locate the folder it is in.  When I
       select the MacKermit Send command under the File menu it pops up
       with the corrent folder selected.  At this point tI would like to
       be able to enter the file name from the keyboard and click open.

                        Thanx,
                    Steve Caldara

P.S.  As is, MacKermit is great.  Thanx to all those who have worked on it.
      These suggestions are requests to make it even betterr
            ( at least for me  :-)   )

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

Date: Wed, 13 Jul 88 15:24:38 PDT
From: [e-mail] (John A. Kunze)
Subject: Bug in MacKermit?
Keywords: MacKermit 0.9(40)

I've noticed a fairly annoying bug in MacKermit when connected to Unix
through several versions.  The terminal emulation (with vt100 or vt102
termcap) has a glitch around column 72 that I suspect has something to do
with internal margin bell handling.  If you edit this message and try moving
the cursor back and forth near the ends of the lines in "vi" (using the
commands w, e, l, etc.), you'll notice that "vi" gets confused about the
state of the screen: characters get overwritten with the wrong information
and the line seems to lose a character.

    John Kunze

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

Date: Thu, 14 Jul 88 10:15:19 EDT
From: [e-mail] (Atul Kacker)
Subject: Problems with MacKermit 0.9(40)
Keywords: MacKermit 0.9(40)

I have been using MacKermit 0.9(40) for some time now.  I like the way
keyboard remapping is done.  The keyboard shortcuts (in place of using the
mouse) are nice, but some of them do not work !  In particular, Command-Q
for quitting and Command-S for sending files don't do anything.  Command-Q
just makes my modem beep...

Is it only me or is there really a bug here ?  My Mac is a Mac+.

Atul Kacker
([e-mail])

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

Date: Thu, 30 Jun 88 11:35:48 PDT
From: [e-mail]
Subject: C64 kermit Download Problem - Digest V7 #15
Keywords: C64 Kermit

Another solution to the C64 download problem short of fixing the hex
file is to run C64DXL.BAS to create the C64DXL.C000 and NOT reset
the 64. Then RUN C64DXL.C000 on the kermit hex file. The end
address will appear but the system will hang. Write the address down,
reset the 64 (power off 'n' on) and run C64DXL.C0000 again to
create the executable.

Ira Graffman    NASA/Goddard Space Flight Center

[Ed. - See message below...]

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

Date: Thu, 30 Jun 88 22:27:12 EST
From: [e-mail] (Ray Moody)
Subject: C64 Kermit Downloading Problem
Keywords: C64 Kermit

RE: Info-Kermit Digest V7 #15
>   Many people have a problem with dowloading and converting C-64 Kermit.

    The part about the RTS vs. BRK instruction is really a matter of taste.
Most monitors will catch the "BRK" instruction, and exit to BASIC if you use
an RTS instruction.

    As to the checksum problem, C64DXL doesn't use the checksum in the last
line anyway.  As soon as it sees the ";00" at the start of the line, it stops.
(Perhaps it should use the checksum....)

    Anyway, I am looking for a better way of distributing Kermit over the
networks.  As anybody who has tried the current method knows knows, it is gross
and ugly.  There will be a new version of Kermit before too much longer.

                                Ray

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

Date: Thu, 7 Jul 88 22:04:22 GMT
From: [e-mail]
Subject:  C-Kermit for Intel 310 Xenix 3.0?
Keywords: C-Kermit

How do I get a copy of Kermit for an Intel 310 running Xenix v3.0?  The
computer does not have a C compiler on it.  Which make file parameters
ckuker.mak?

                                               Rodney B. Roeber

[Ed. - C-Kermit for Unix, Xenix, etc, only comes in source form.  Is it true
that people have Xenix with no C compiler?  If so, is there anyone out there
who would like to volunteer to distribute Kermit on diskette for these
systems?]

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

Date: Mon, 6 Jun 88 15:04:34 PDT
From: [e-mail] (Farhad Arbab)
Subject: Proposal for a New Command
Keywords: Kermit Protocol

I would like to suggest adding a new command to kermit to make
it possible for an arbitrary program to talk to a remote host.
I think this is easy to do for kermits running under Unix, but
it may not be so easy to do for some other systems, e.g. DOS.
My comments, therefore, really refer to C-Kermit under Unix.

What I need to do is this:  I want to connect to a remote host that is
running a program P, and carry out a conversation with P.  Since the
behavior of P is very predictable, the conversation on my part is
mostly mechanical.  I would like to replace me on my end with a local
program, L, essentially a sh script.

I know about script in kermit but script is too restrictive for my
purpose.  (With script, you can specify only a sequence of expect/send
strings.  The optional sends within an expect string basically allow
you to get the remote to a state where the next send would be
appropriate. I need to send different things depending on the string I
receive, and I need to do some "computation" to figure out what I'm
going to send.)

What I need is a new command, say "pipe", which works just as connect,
but instead of connecting the line to /dev/tty, it connects the line to
the standard input and output of a given process: "pipe L" will then do
what I want.  When L terminates, I want to return to the command mode
of kermit.  L can be an arbitrary program (anything that can be
executed via the ! escape).

How easy or difficult is it to add this feature to kermit?  Do you know
of other easy ways to accomplish the same effect?  Is there another
communications program that provides such a feature?

Farhad Arbab
[e-mail]

[Ed. - There are several possible methods that could be added to C-Kermit.
One of them could be a fully elaborated Kermit-style script language,
complete with variables, IF's, and GOTOs, similar to MS-DOS Kermit 2.31.
This is one of the many, many, many items on the "to-do" list for C-Kermit.]

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

End of Info-Kermit Digest
*************************
-------
20-Jul-88 15:56:17-EDT,26914;000000000000
Mail-From: SY.CHRISTINE created at 20-Jul-88 15:55:24
Date: Wed 20 Jul 88 15:55:24-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V8 #3
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 20 Jul 1988       Volume 8 : Number 3

MS-DOS KERMIT ISSUE:
                      MS-Kermit v2.29d for HZ100
                      Scan codes for Kermit 2.30
                          More DG/1 Success
                 Kermit for the DG/1 and Archimedes?
                   Problems with Generic MS-Kermit
              Tek4027 or color calls in MSKERM or QKKERM
            KERMIT-MS: Please Make Special Keys Available!
                  MS-Kermit 2.31-test5 Take File Bug
                 MS-Kermit 2.31-test5 Screen Rollback
                     MS-Kermit and VT100 Printers
      Kermit Key Redefinition of Esc-chr: To Show on Mode Line.
                MS-Kermit (and others) Screen Rollback
                    Selecting MS-Kermit .INI Files
                    Bug in MS-Kermit V2.31-test6 ?
                        MS-Kermit vs Smartcom
                 MS-Kermit Tek-4010 Emulation Colors
                  Bug in Kermit-MS on Tandy 3000HD?
                             Kermit 2.31
              Did AT&T 6300 Graphics Get Canned in 2.31?

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: 9 Jun 1988 22:13-PDT
From: [e-mail]
Subject: MS-Kermit v2.29d for HZ100
Keywords: MS-DOS Kermit 2.29d, Heath-Zenith/100

Now for the main reason for contacting you: I have been using v2.29d
MS-Kermit for Z100s since early april but have been unable to toggle the
printer on/off.  F12 does nothing and SF12 prints the letter L on the
screen.  The documentation I have is for v2.30 for IBMs but I have not found
anything for 2.29d HZ100 Kermit.  Additionally, can we expect to see v2.30
with vt102 emulation for the Z100 sometime or has this project/idea been
dropped?

Thank you for any and all assistance.

Al Holecek
<[e-mail]>

[From jrd - The Z100 code for 2.29 is rather ancient. Drew Derbyshire has
done extensive modifications and updating of the Z100 specific files and
will shortly have a much improved Kermit. He has toyed with the idea of
porting the VT102 emulator but that requires a fair amount of personal time.
A test version of Z100 MS Kermit at the 2.31 level will be available
sometime soon this summer.]

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

Date: Wed, 1 Jun 88 11:04:34 edt
From: Mike Watson <[e-mail]>
Subject: Scan codes for Kermit 2.30
Keywords: MS-DOS Kermit 2.30, Scan Codes

Does anyone have a listing of all the scan codes for PC-AT compatibles?  Or a
program to produce such a listing?  Specifically the scan code I am looking for
at the moment is Control-Space on a Zenith 248.  Show key doesn't even
recognize this as being any different than Alt-Space or Just-Plain-Space.  Is
this a legal keystroke under 2.30?  It worked under 2.29B.

Please send all responses directly to me and I will summarize for the net.

             Arpa:  [e-mail]
         Usenet:  uunet!nswc-oas.arpa!mwatson
 _ _ _                         _ __      _
' ) ) )      /          /)    ' )  )    ' )   /    _/_
 / / / o _. /_  __. _  //      /--'      / / / __. /  _   ______
/ ' (_(_(__/ /_(_(_(<_(/_     /  \ o    (_(_/ (_(_(__/_)_(_) /) )_

[From jrd - the system Bios reports space bar as a plain ascii space, no matter
what other keys are held down.  Since there are plenty of other legal key
combinations available, such as the standard Control-@ for NULL, I'd recommend
using one of them.]

[Ed. - Cute signature!  You can use the program MSUCHK to conveniently
determine scan codes for use with Kermit 2.30 and later (MSUCHK is the Kermit
Distribution name, the real name is SCANCHEK).]

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

Date: Tue, 31 May 88 22:17:32 EDT
From: "Robert E. Zaret" <[e-mail]>
Subject: More DG/1 Success
Keywords: MS-DOS Kermit 2.30, DG/1

I have figured out how to use Kermit with COM1 (internal or external modem).
Specifically, I can use MS-Kermit 2.30 extended development (my copy is dated
23 April 1988) on my DG/1 Model 1 with the version of DOS 2.11 that came with
it.  Issuing the following command before starting Kermit activates COM1 for
use with an external modem:

          mode com1:on

Issuing the following commands before starting Kermit activates the internal
modem:

          mode com1:off
          mode com1:on,int

Either way, Kermit will start up using BIOS1 (the BIOS version of COM1) and
will be able to control the speed of the port.  I tried these commands with
earlier versions of MS-Kermit, but failed.

Problems:

I have had trouble using the MPDA (Monitor, Printer, Display Adaptor) and
external monitor at 1200 bps.  I think the main problem is that performance
when Kermit uses BIOS is borderline at 1200 bps, and adding the adaptor and
monitor slows the DG just enough.  I would probably be willing to put up
with missing characters, but cannot tolerate the problems I have had with
cursor keys.  I will try some experiments, but my current guess is as
follows: The cursor keys do not work when I am connected to an IBM mainframe
via a Series/1 protocol converter.  I believe this particular Series/1 is
set up to switch the mode of the cursor keys when the user says the terminal
type is VT100.  I suspect my DG/Kermit combination never "sees" the command
to switch modes.  Simple problem with agravating results.

I was unable to use MS-Kermit 2.31 - test 4 (25 April 1988).  I sent details to
Joe D., but thought I should let others know.

[From jrd - there is not much we can do if the machine is polling the serial
port via the Bios and its speed is just a hair too slow sometimes.  Normally
the solution is to request the host to pad material, but here the problem
arises at login time.  Could padding be setup as part of the login command file
(if any) or at least have the system repeat the setup soon thereafter?]

[Ed. - Of course, the ideal solution for the DG/1 is for someone to provide
system-specific code to take advantage of its features, bypassing the slow
Bios polling, etc.  Since the DG/1 is apparently IBM-compatible in all respects
but the serial port, probably all that is needed is an MSXDG1.ASM module, based
on the MSXIBM.ASM version, modified for the DG/1's UART & internal modem.
Volunteers?]

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

Date: Mon, 6 Jun 88 21:00:34 EST
From: munnari!latvax8.lat.oz.au![e-mail]
Subject: Kermit for the DG/1 and Archimedes?
Keywords: MS-DOS Kermit 2.30, DG/1, Archimedes

I have a Kermit user who is trying to get MS Kermit 2.30 working with his
DG/1 model 2 with IBM compatible serial port.  He says he has tried various
combinations of set port, baud, etc with no luck.  Apparently 2.29 did work!
Is there anyone else with this problem?  If so, are there any solutions?  I
noticed a message in Info-Kermit Digest V7 #12 stating version 2.30 extended
development (is that one of the new test releases?) sort of worked.

Also, is there a port of Kermit for the Acorn Archimedes?  If it is only on
the very latest distribution tape then can I get a .boo file and unboo
source for the Archimedes?

Thanks

Mark Kosten            ACSNET: [e-mail]
Computer Centre          ARPA: [e-mail]
La Trobe University    BITNET: [e-mail]
Bundoora 3083          or via return address on mail header
Australia              phone:  [phone]

[From jrd - On the DG/1, see the note from Robert Zaret above.  On the Acorn,
I am unaware of such a port but Alan Phillips in the UK knows if anyone does.]

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

Date: Tue 28 Jun 88 21:25:43-EDT
From: Charles Lasner <[e-mail]>
Subject: Problems with Generic MS-Kermit
Keywords: MS-DOS Kermit 2.30, Generic Kermit, Victor 9000
Xref: Sirius, see Victor

MS-Kermit Generic V2.30 8 Jan 88 does not work on a Victor 9000.

I tried using SET PORT FILE-HANDLE
Handle: 3

and only got a screen full of "3" characters! (and it crashed)

using handles 1-4 yield unusable results, but at least I could escape back
from them

Using 4 caused "device error" to appear infinitely.

using 1 and 2 causes console echoing (obviously talking to CON:).

BTW, this never worked before, but at least this generic version warns you
when you put in fantasy values; former versions crashed with higher values of
file-handle value.

Can anyone guess at what's not so "generic" about Victor 9000.  We do have the
Victor-specific modules, so in theory, the generic version should be fixed.

cjl (OC.LASNER@CU20B)

[From jrd - Bryan Peterson is the resident Victor 9000 guru.  Was ANSI.SYS
installed to read that backspace escape sequence?  On Generic Kermit and file
handle 3: goodness knows, that's a "normal" DOS handle but the value is not
enforced by any standard.  Since Generic Kermit polls the serial port device
via DOS it will operate at only low speeds.  Thus, work on Generic Kermit to
cater for the Victor 9000 becomes an academic (sic) exercise.]

[Ed. - Also, if SET PORT FILE-HANDLE doesn't work, you can also try SET PORT
DEVICE <device-name>.]

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

Date: Tue, 24 May 88 12:42:12 pdt
From: Alex Woo <[e-mail]>
Subject: Tek4027 or color calls in MSKERM or QKKERM
Keywords: MS-Kermit, Tektronix Emulation

Has anyone considered putting color calls into either of these programs?
I'm not sure which tekxxxx after 4014 has color, but it would be nice
to display color on an EGA screen.

Alex Woo
[e-mail]

[From jrd - MS Kermit 2.31 uses the ANSI coloring commands ESC [ 3x ; 4x m
(x = 1 - 7) to control coloring of individual dots in Tek graphics mode.
SET TERMINAL COLOR also works when the terminal type is TEK4010.]

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

Date: 31-May-88 at 16:52 MEZ
From: Eckart Meyer <[e-mail]>
Subject: KERMIT-MS: Please Make Special Keys Available!
Keywords: MS-DOS Kermit, VT100 PF Keys

I use kermit connect mode to have a VT100 terminal on a VAX.  It's a great
thing but one is missing:  Please, please find a way to make the upper four
keys of the keypad available in connect mode since they are very frequently
used by DEC software (Keys PF1...PF4) especially by the editor EDT.  I know
it's not a trival thing but it should work.  I have a program (without
sources) which uses these keys just like any other key - the program is an EDT
for MS-DOS.

Eckart Meyer                                     Address:   Schleinitzstr. 23
Inst. f. Nachrichtentechnik                                 3300 Braunschweig
Technical University of Braunschweig                             West Germany
                                                 Phone:      [phone]
BITNET:   I7100501@DBSTU1
Internet: [e-mail]

[From jrd - the four top keys vary considerably from keyboard to keyboard, but
normally involve Scroll Lock, Num Lock, etc.  The system Bios does not regard
these keys as being suitable for reporting individually to Bios callers (such
as MS-Kermit).  The only ways of seeing them individually are to drop down
below the Bios and fight with any other programs grabbing raw keyboard info.
MS-Kermit declines to enter those jousting lists. (I have PC-EDT here too.)
MS Kermit/IBM is shipped with DEC's PF1-4 keys residing on IBM's F1-4 keys.]

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

Date: Tue, 7 Jun 88 17:53 CET
From: Helmut Waelder <[e-mail]>
Subject: MS-Kermit 2.31-test5 Take File Bug
Keywords: MS-DOS Kermit 2.31, Take Files

Have you ever tried the new MS-Kermit 2.31-test5 release with MS-DOS 2.11 ?
I have discovered that kermit doesn't find any TAKE file, not even the
MSKERMIT.INI file. Here is an example session:

C>kermit
 ..
Kermit-MS>take mskermit.ini
?Can't find take-file: ake mskermit.ini
Kermit-MS>

This happend on a Olivetti M24 with MS-DOS 2.11 and on a Sperry XT with
MS-DOS 2.11. There are no such problems with MS-DOS 3.x.

Helmut
Acknowledge-To: Helmut Waelder <ZRWA001@DTUZDV1>

[From jrd - Thanks, the problem has been widely reported, and it's fixed in
the released version of 2.31.  Just in case there is an interest, the problem
related to tagging files opened read-only with access Deny-None so they could
be shared, e.g. on LAN file servers.  Kermit now skips the access condition if
the DOS version is earlier than 3.0.]

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

Date: Wed, 1 Jun 1988 17:30:50 EDT
From: [e-mail]
Subject: MS-Kermit 2.31-test5 Screen Rollback
Keywords: MS-DOS Kermit 2.31, Screen Rollback, CGA

The latest test Kermit is acting differently in the way that it handles stored
screens.  Instead of scrolling smoothly through the lines, it blanks the
screen and puts up the new screen whereever page up or page down is hit.

/k

[From jrd - "test5" had revisions to screen initialization which skipped
sampling the kind of display adapter until the info was needed later.
Consequently, it used the CGA snow removal screen blanking.  The current
material tests the kind of display adapter right away and omits snow removal
for all except CGAs.  MS Kermit 2.30 might produce a disappearing cursor
with some of the new VGA boards for the same reason; works ok in 2.31.
Later conversations with Kenneth indicates his CGA board has pecularities
when asked to scroll a group of lines. Version 2.30 scrolled one line at a
time, but 2.31 does it in large groups, for speed.]

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

Date: Wed, 15 Jun 88 14:49:28 CDT
From: [e-mail] (Moore)
Subject: MS-Kermit and VT100 Printers
Keywords: Ms-Kermit 2.31, Transparent Printing

Is this a known bug in 2.31-test?, or a bug at all?  With older versions of
Kermit (2.29) and all our Wyse terminals here, we can (with a UNIX alias)
issue the command p to print a file: p is aliased to echo ^[[5i cat the file
then echo ^[[4i.  Ever since 2.30 came out (and maybe a little earlier)
we've had to replace those commands with echo ^[[?5i and ^[[?4i; an
unfortunate side effect is that output also goes to the screen (which the
previous string avoids).  Any comments?

Jim

[From jrd - Both forms should work with MS Kermit 2.31.]

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

Date: Thu, 23 Jun 1988 11:39:22 EDT
From: Mohib N Durrani <[e-mail]>
Subject: Kermit Key Redefinition of Esc-chr: To Show on Mode Line.
Keywords: MS-DOS Kermit, Escape Character

I redefined the MS-Kermit Escape Character ^] for the ` (ie. \29) and it works
fine, but the new ` key does not display on the Mode line at the bottom of the
kermit screen, the old ^] continues to be displayed.

    How can I change the        Esc-chr: ^]
    to                          Esc-chr: `

The previous version of kermit used to automatically change the display of the
Esc-chr.

Thanks.

[From jrd - The Kermit escape character must be a control code and version
2.31 rejects non-control codes with an explicit message.  The easy solution
is to assign verb \Kexit to the accent key (ALT X has this definition too)
even though ^] will still show on the status line (as it should in this
case).]

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

Date: Wed, 20 Apr 88 15:00:31-1000
From: [e-mail] (David Lassner)
Subject: MS-Kermit (and others) Screen Rollback
Keywords: MS-DOS Kermit 2.31, Screen Rollback

One of the terminal emulation features included in VersaTerm (an
excellent package for the Mac) which is incredibly useful is the
capability to "scroll the screen on full-screen erase" or similar.
The idea is that before clearing a screen its contents are saved in
the scrollback buffer so that you can see what you've done during
your session, even on a full-screen oriented host where scrolling
almost never occurs.  Would be great to see this in future versions
of MS-Kermit, MacKermit, and others.

David Lassner, University of Hawaii Computing Center, 808/948-7351
INTERNET: [e-mail]   BITNET: david@uhccux
UUCP:     {ihnp4,uunet,ucbvax,dcdwest}!ucsd!nosc!uhccux!david

[From jrd - a good idea David. Next time we'll try to do that. Thanks.]

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

Date: 27 Jun 88 21:10:55 GMT
From: [e-mail] (Robert T. Herbst)
Subject: Selecting MS-Kermit .INI Files
Keywords: MS-DOS Kermit, Initialization Files

#include <stdio.h>
/* C program to allow the selection of a number of .ini files for
* use with mskermit. The .ini file are the users choice.  A file keys
* containing the definitions of set key in the .ini file is displayed
* using the MSDOS type command. This program "select.c" has been
* compiled using POWER C and has run successfully.
* Robert T. Herbst University of North Carolina at Wilmington.
*/
main()
{
    int c;
    for(;;)
    {
    printf("Enter 4 for 2400b 2 for 1200b h to exit\n");
    system("type keys");
    while( ( c = getchar()) != '\n')
    switch(c)
    {
        case '4': system( "kerm230 -f mskermit.ini");
            break;
        case '2': system( "kerm230 -f m1200.ini");
            break;
        case 'k': system("kerm230");
            break;
        case 'h': exit(0);
            break;
        default : break;
    }
    }

}

[From jrd - Thanks Robert.  Neat.  One might also note that a Batch file can
be used with a similar mechanism via %1.  MS-Kermit 2.31 has so many new
control features in scripts and macros that it is possible to merge several
ini files into one, with separate macros defined for each condition and then
use one or another as extended Kermit commmands.  The new User's Manual has
full details.]

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

Date: Wed, 29 Jun 88 17:50 CET
From: Helmut Waelder <[e-mail]>
Subject: Bug in MS-Kermit V2.31-test6 ?
Keywords: MS-DOS Kermit 2.31

When I'm downloading files from an IBM host (CMS-kermit 4.0) with MS-kermit
v2.31-test6 the files don't have a date or timestamp in the directory.
This happens with PC-DOS 3.3 and MS-DOS 3.2, not with MS-DOS 3.1
Greetings
         Helmut

[Ed. - This is fixed in the final 2.31 release.]

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

Date: Tue, 5 Jul 88 13:48 MDT
From: Joe Doupnik <[e-mail]>
Subject: MS-Kermit vs Smartcom
Keywords: Smartcom

        Just a comment on a situation seen locally.  If a person runs the
Hayes Smartcom program SCOM and then runs Kermit the computer may hang.
As best that I can make out SCOM captures the serial port interrupts but
when it exits it leaves those interrupts pointing at itself (or at whatever
occupies the memory next).  Thus, Kermit or another program can come along
and get stung by those loose ends.  So, if some people remark on the situation
we have a probable answer.  There's nothing Kermit can do about it.
        Regards,
        Joe D.

[Ed. - We have had some calls about this too.  The offender is apparently
Smartcom II, not III.  One caller claimed to be able to clear up the problem
by "reconfiguring the modem" in Smartcom.  Failing that, obviously, one can
Ctrl-Alt-Del to put things back...  Also see the comments below on the
Tandy 3000.]

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

Date: Thu, 7 Jul 88 13:19:47 CDT
From: [e-mail] (Brendan B. Boerner)
Subject: MS-Kermit Tek-4010 Emulation Colors
Keywords: MS-DOS Kermit 2.31, Terminal Emulation, Color Graphics

Hello, Does anyone know how to use the different modes with the Tek-4010
emulation in Kermit 2.30?  I saw that depending on memory on the EGA
adpater, one can choose between more resolution/less color vs. less
resolution/more color.  Currently, when I use it, it goes into B/W mode.
How do I change this?

Thank you.

Brendan

[Ed. - Normally, you only get two colors when in Tek mode.  These are
the foreground and background colors you chose in your SET TERMINAL COLOR
command.  As of 2.31, if you have host-resident software that can include the
ANSI color-changing commands in Tek output, then you can have lots of colors,
but the exact number depends upon which display adapter and monitor you have.]

[From jrd - I suspect you are using CGA mode, which has only black and white
graphics. If Kermit senses that you are using an EGA board then it defaults to
16 color 640 by 350 if the board says the monitor type is suitable. If you
have an ordinary CGA monitor (not an EGA monitor or better) then b/w is the
best you can do.  Also, check the switches on the display board.]

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

Date: Sat, 9 Jul 88 18:01:10 pdt
From: steinmetz!unioncs![e-mail] (Richard Boehm)
Subject: Bug in Kermit-MS on Tandy 3000HD?
Keywords: MS-DOS Kermit 2.31, Tandy 3000HD

I would like to report what I believe to be a bug in Kermit-MS 2.31-test5 and
2.31-test6.  When starting the program, exiting the program, or executing a
"take" file, DOS presents the message:

     Unexpected HW interrupt 0C at 0070:0455.

I have used all versions of Kermit since version 2.29b, and this behaviour
manifested itself starting with version 2.31-test5 (I am currently using
2.31-test4).

I have just downloaded Kermit-MS 2.31 (the official release).  This version
also has the bug, but the bug doesn't appear when exiting the program.

My machine is a Tandy 3000HD AT clone.  It uses the Phoenix BIOS, is
an 80286 machine, and runs MS-DOS 3.2.

 ..steinmetz!unioncs!boehmr                      Richard E. Boehm, Jr.
   [e-mail]
   [e-mail]

[Ed. - This does not happen on IBM systems, or any of various other IBM
compatibles we have tested, so it is apparently specific to the Tandy
model.  I assume that the only problem is the appearance of the error message,
and the operation of the program is unaffected?  Anyone with Tandy 3000
expertise is encouraged to track this one down!]

[From jrd - I think we found the root cause of this item, and essentially the
same problem when Kermit is run after running Smartcom II or PC-Talk III.
MSVIBM.BOO, dated 17 July 1988, is issued to cure it.

Here is the technical description: When Kermit resets the serial port
(relinquishes ownership) it tells the UART to disconnect its chip controlling
the interrupt (IRQ) line on the PC bus.  That disconnection can result in a
stray interrupt which appears to Kermit as not related to the serial port.
In such a case Kermit passes the interrupt to the previous owner which is
usually the ROM Bios.  The Phoenix version 1.00 ROM Bios in the Tandy 3000
apparently cannot handle a stray interrupt and issues the message above, but
most machines absorb it without comment.  In the case of Smartcom II and
PC-Talk III, both programs redirect the serial port interrupt to themselves
but do not return it when the program exits!  Thus, they remain the previous
owner; but their memory is used by another program, or worse.  This usually
crashes the system later on when something (noise?) arrives at the serial
port.  The 17 July version of IBM PC MS Kermit absorbs the stray interrupt
when resetting the serial port.  While this keeps Kermit operational, the
Smartcom II and PC-Talk III situations remain dangerous to the system after
they exit; rebooting is suggested.]

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

Date: Sun, 10 Jul 88 17:24:23 EDT
From: elsie![e-mail] (Arthur David Olson)
Subject: Kermit 2.31
Keywords: MS-DOS Kermit 2.31

We've picked up Kermit 2.31; thanks as usual to all involved for a job well
done.

One thing that seems to be missing from the various "change lists" (though
it's described in the mskerm.doc opus) is the addition between version 2.30
and version 2.31 of "-" as a line continuation file in "take" and
"initialization" files.  Might be worth adding a note, since I've seen a fair
number of initialization files with

    set key \330 -

commands in them (for people who don't need different terminal emulations,
and who want to get a minus when they tap the key way over there in the corner
on recent IBM-style keyboards.)  To paraphrase mskerm.doc, change the above to

    set key \330 \45

    [e-mail]            ADO is a trademark of Ampex.

[Ed. - Thanks for the hint!  It's been added to MSKERM.BWR and MSR231.UPD.]

[From jrd - Usually one can add a trailing space to the hyphen since the
space is trimmed off before the string is interpreted. \45 is easier to see
when editing.]

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

Date: Tue, 12 Jul 88 09:34:12 edt
From: [e-mail] (Robert D. Seals)
Subject: Did AT&T 6300 Graphics Get Canned in 2.31?
Keywords: MS-DOS Kermit 2.31, AT&T 6300, Tektronix Emulation

One of the great things about 2.29[bc] and 2.30 was the autodetection
and support for AT&T 6300 graphics - which doesn't seem to be
present in 2.31 (OK, I admit, I haven't reread the documentation...)

rob

[Ed. - This is news to us.  We don't have an AT&T 6300 to try it on, but
the DEC VAXmate has the same kind of adapter, and it is "autodetected" with
no problem.  But 2.31 contains a new feature, SET TERMINAL GRAPHICS <name>,
so that you can specify the actual adapter type in case Kermit guesses
wrong.  On an AT&T 6300, you can include SET TERMINAL GRAPHICS ATT in your
MSKERMIT.INI file.]

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

End of Info-Kermit Digest
*************************
-------
 3-Aug-88 15:06:42-EDT,22784;000000000000
Mail-From: SY.CHRISTINE created at  3-Aug-88 15:05:44
Date: Wed 3 Aug 88 15:05:44-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V8 #4
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 3 Aug 1988       Volume 8 : Number 4

Departments:

  ANNOUNCEMENTS -
        CU20B IP Host Address to Change
        Okstate Dialup Number to Change
        Kermits Needed
        Announcing C-Kermit for OS/2

  MS-DOS KERMIT -
        Automatic Switching Between Text and Graphics in MS-Kermit
        MS-Kermit 2.31-test6
        MS-DOS Kermit 2.30
        MS-Kermit 2.31-test6
        IBMPC Kermit 2.31 UB problem
        MS-Kermit 2.31 -- SET PORT UB-Net1
        MS-Kermit 2.31 Bug (Feature?)
        MS-Kermit v2.31 Scripts

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: Mon, 1 Aug 88 12:00:00 EDT
From: Christine M Gianone <[e-mail]>
Subject: CU20B IP Host Address to Change
Keywords: CU20B, FTP

As of August 15th, 1988, Columbia University Computer Center IP host
addresses will change by replacing the 32 with a 40 in the third octet of
the IP address.  In particular, the host number of CU20B will change from
128.59.32.128 to 128.59.40.128.  If you have trouble FTP'ing Kermit files
from CU20B on or after August 15th, you can specify the new host number until
your site's host tables are updated to reflect the change.

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

Date: Mon, 01 Aug 88 15:46:23 -0500
From: Mark Vasoll <[e-mail]>
Subject: Okstate Dialup Number to Change
Keywords: Okstate

On August 6, 1988 the phone number for the UUCP and Kermit servers at
Oklahoma State University will change:

    Old number:   [phone]
    New number:   [phone]

A "that number has been changed" recording has been promised, but I
don't hold a lot of hope for it.

Mark Vasoll
Computing and Information Sciences   Email:  [e-mail]
Oklahoma State University
Stillwater, Oklahoma

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

Date: Fri 29 Jul 88 17:27:32-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermits Needed
Keywords: Future Kermits

Now that Kermit is about seven years old, it has spread to cover nearly every
major computer and operating system, and many minor ones -- well over 300 in
all.  But there are still some notable systems for which no Kermit programs
exist.  Among them:

 - The IBM System/34, System/36, System/38, AS/400.  Some of these machines
   lack asynchronous communication interfaces, so Kermit file transfer will
   be possible only if the commonly-used protocol converters can be put into
   transparent mode, as the IBM 370-series mainframe Kermits do for their
   3270 protocol converters.

 - Support in IBM mainframe Portable Kermit-370 for DOS/VSE and CICS.

 - Wang VS and other minicomputer systems.

If you know of anyone working on these projects, or are interested in doing
it yourself (for fame but not fortune), please let us know!

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

Date: Fri, 29 Jul 88 14:54:36 -0100
From: PD Software <[e-mail]>
Subject: Announcing C-Kermit for OS/2
Keywords: C-Kermit, OS/2 Kermit

                       Announcing C-Kermit for OS/2

A version of C-Kermit for OS/2 is now available for beta testing.  Any bugs,
suggestions or complaints should be sent to [e-mail].  This
first version is 1.0a - the 'a' indicates it is a pre-release version.

I've used the letter 'O' as the system-specific identifier for OS/2, so
the release files are named as follows:
      CKOKER.EXE      The executable program
      CKOKER.DOC      Documentation
The sources for the program and the Scribe source for the documentation
will be made available when beta testing is over (ie when bug reports
slow to a trickle?).

C-Kermit for OS/2 runs on OS/2 Standard edition 1.0 (or on 1.1 in a
Presentation Manager window, although this is untested).  It makes use of
the COM.SYS (or perhaps COM01.SYS) device driver, which must be loaded in
the CONFIG.SYS file.  There are believed to be no major bugs, but the
following minor problems exist:

*  Stop bits: There is currently no  mechanism for altering the number of  stop
   bits, which is fixed at 1.
*  Server breakout:  There is  no way  of stopping  server operation  from  the
   keyboard, short of Control-Break.
*  Dial: The DIAL command has not  been tested.  It is impossible to  terminate
   the dialling process short of pressing Control-Break.
*  Multiple copies: Multiple  copies of Kermit  accessing multiple comms  ports
   simultaneously has not been tested.
*  Terminal emulation: No  particular terminal is  emulated, and therefore  the
   keyboard has only  the natural key-to-ascii-code  mapping.  This means  that
   (for instance)  the Del  key does  not produce  code 127,  but a  code of  0
   followed by 224.  The only exception  to this "natural" mapping is that  the
   backspace key is  explicitly mapped into  127.  It is  hoped to implement  a
   VT100 emulator and a keyboard remapper  to circumvent these problems.   This
   may also improve the  speed of terminal writing,  which is slow compared  to
   MS-Kermit.
*  Multiple send from command line:  At present, a wildcard file  specification
   cannot be given as the argument to the '-s' command line option.  Thus, only
   a single file can be sent using a command line.
*  Flow control from keyboard: In connect mode, if a Control-S is typed at  the
   keyboard to pause a long file listing, it may or may not work, depending  on
   the state of the device driver's flow control flags.

There are also some further minor bugs or areas for improvement which are
detailed at the end of the documentation.

Chris Adie
26/07/88

[Ed. - Many thanks!  The files are in KER:CKOKER.*.  We normally do not
release programs without source code, but we make an exception in this case
because of the high level of interest in OS/2.  Test at your own risk!]

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

Date: Tue,28 Jun 88 16:24:40 BST
From: [e-mail]
Subject: Automatic Switching Between Text and Graphics in MS-Kermit
Keywords: MS-DOS Kermit 2.31

Someone here is using a package which uses DEC VT100 codes during its text
output and Tektronix 4010 codes for its graphics output.  The package expects
the terminal to automatically switch between text and graphics modes at the
appropriate points.  If MS-Kermit is used with the package, automatic switching
from text to graphics takes place in some cases (for example when the package
sends ESCAPE Control-L) but not in others (for example when the package sends a
Tektronix drawing command).  In comparison, UNITERM on an Atari ST always
switches when necessary.

Should the codes which cause MS-Kermit to automatically switch from text to
graphics mode be expended to include the Tektronix FS, GS, RS, and US commands?
This automatic switching can, of course, be disabled if necessary via the
Kermit DISABLE TEK command.

Phil Wade,
Hull University Computer Centre.

[From jrd - While automatic switching for all Tek commands (there are more
than the FS, GS, RS, US set, clearly) can be convenient for isolated packages
it both adds a lot of code to MS Kermit and exposes users to many unexpected
switches when files are displayed with embedded control codes. Overall, I
think we are better off with the just the current two automatic entry points.]

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

Date: Fri, 01 Jul 88 11:36:28 BST
From: [e-mail]
Subject: MS-Kermit 2.31-test6
Keywords: MS-DOS Kermit 2.31

I've come across a number of peculiarities while using 2.31-6 from batch
files, or MAKE files, with a PS2/60.  When the command

    kermit send dirname\filename.C dirname\filename.C

is entered (having set up a kermit on an EPSON AX in server mode) the
filename used at the other end is

    dirname\filename.CX  (Note the added X in the extension)

I assume that this is a bug -it's certainly annoying!  The addition of the X
does not occur with extension names of 2 or more characters.  If the send
command is not the last on the line then the X is not added either, i.e.

    kermit send dirname\filename.C dirname\filename.C, quit

saves

    dirname\filename.C

at the remote end.  The "sending as" within kermit works fine.

Another quirk is when Control-C is used while a file transfer is in
progress.  This causes the server kermit to hang up waiting for more
packets.  The way I've found around this is to ask it for a "rem dir" a few
times and Control-C out it, producing the "host not receiving" (not
verbatim!) error message.  Eventually the server gets the message and gives
a directory listing.

Yours,
Chris.

[From jrd - Chris, you need to reread the MS Kermit User's Manual. First,
the SEND command can take two arguments: local filname and optionally the
name to use in the outgoing packet. It does not take a list of files to be
sent; use a list of SENDs. Second, Control-C is a non-protocol exit and does
not notify the other side. Hence the host waits for more packets in the file
exchange. Use Control-Z instead, as indicated on the file transfer screen
status line.]

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

Date: Thu, 7 Jul 88 20:02:31 bst
From: Leila Burrell-Davis <[e-mail]>
Subject: MS-DOS Kermit 2.30
Keywords: MS-DOS Kermit 2.30

MS-Kermit is normally pretty good about renaming files that don't conform to
MS-DOS filename conventions, but it is distinctly upset by a file with a
colon in its name, e.g.  episode:1

I found this rather annoying when I left it overnight downloading a lot of
files from a un*x machine, only to discover the next morning that it had
given up as soon as it got to the filename with the colon in.

You may like to pass on details of this `feature' to the program's author
(:-).

Leila Burrell-Davis, Computing Service, University of Sussex, Brighton, UK
Tel: [phone]   Fax: [phone]  JANET: [e-mail]
ARPA: [e-mail]
BITNET: [e-mail]      UUCP: [e-mail]

[From jrd - DOS uses colon as a device name terminator/separator. Try this at
DOS level-

        C> copy oldfile new:name.ext

DOS will tell you that there is an illegal destination (no device "new:").
DOS also uses multiletter device names which may optionally end in a colon.
Kermit cannot determine whether or not you mean use a specific device and
thus does not change the colon to another legal letter.]

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

Date: Thu, 07 Jul 88 15:36:00 BST
From: Mr. A. O. V. Blanc <[e-mail]-a>
Subject: MS-Kermit 2.31-test6
Keywords: MS-DOS Kermit 2.31

We have obtained a copy of MS-Kermit 2.31-test6  for  testing.   I  have
been running it on several PC models (IBM, Opus, and Comcen) and testing
it against our Kermit-CMS version  4.0,  the  IBM  generic  Kermit  with
updates up to SC88092.  During the tests -- which went very well, on the
whole -- the following difficulties appeared:

(1)  The reported size of the packets received never gets larger than 4,
     which is clearly incorrect.

(2)  The file size used to calculate the percentage transferred is quite
     far off, which some files terminating when only 25%  had  allegedly
     been  transferred.   Different  ways  of measuring file size may be
     responsible, but users would surely feel happier if the  percentage
     were changed to 100% when the transfer terminates successfully.

(3)  The  two  Kermits  cooperated  nicely when connected through a 7171
     comms processor, but not when using a CAMTEC PAD.  In this case the
     connection  works normally until the Kermits begin trading packets.
     Then the IBM apparently insists on a fifteen or twenty second pause
     before  accepting  each  line of input.  This results in a transfer
     rate of 3 to 4 packets per minute, which is intolerably  slow,  and
     the  input  problem remains even after Kermit ceases to execute.  I
     know this sounds like a CMS problem, especially since it  seems  to
     occur  under similar circumstances with MS-Kermit version 2.30.  It
     does not happen, however, when I use version 2.29c!

(4)  I am not surprised that MS-Kermit receives only the  date  and  not
     the  time  of a file's creation, since the warning of this appeared
     in the MSTIBM.BWR file.  When files are transferred from the  micro
     to CMS, however, both date and time seem to be ignored.

Thanks to Joe Doupnik for his extensive work improving MS-Kermit and its
script facility.

[From jrd - some of the 2.31test series had a file length arithmetic problem
which lost the high order part of the file size figure sent by the host.
Fixed some time ago.

CMS Kermit apparently sends the date of a file but not the time. In that case
MS Kermit records the time as 00:00:00, which is legal, but DOS then shows
this as blanks on the screen. The release version of MS Kermit 2.31 adds two
seconds to let DOS display some numbers for the time.

The long pause does appear to be either a CMS or a front end processor
problem; see if using regular length packets helps these fellows. You might
say to MS Kermit  SET SEND PAUSE <millisec>  because some IBM systems do not
become ready for reception until long after turning around the line. If this
were the case the mainframe would miss the start of a packet and would have
to wait for a timeout and a repeat; the timeout is normally 13 seconds to
receive an acknowledgement.]

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

Date: Fri, 22 Jul 88 18:00:06 PDT
From: [e-mail]
Subject: IBMPC Kermit 2.31 UB problem
Keywords: MS-DOS Kermit 2.31, Ungermann-Bass

    I recently downloaded IBMPC Kermit v2.31.  An excellent package, as
usual.  The UB NetCI interface looked particularly interesting, since we
currently require a resident BIOS rerouter to use the CI from Kermit.

    Unfortunately, as soon as characters were received from the CI, the PC
hung.  After reducing other software to its bare essentials, I began to
suspect Kermit.  After downloading MSXIBM.ASM and DEBUGing through
KERMIT.EXE, a probable cause appeared.

    The IRET in RPOST would send the CS off to never-never land, causing the
machine to hang.  This was because the "call rpost" in UBRECV assumed a near
(intra-segment) call, and only pushed the IP+2 on the stack, and not the CS.
As a solution, I recommend making UBRECV and all other interrupt routines
type PROC FAR, since that more accurately describes what they are. (IRET =
far RET + POPF).  Then UBRECV would assume a far call.

    I certainly appreciate all the work that you are putting into Kermit.
It fills an essential gap here at Caltech.

    There are a couple more minor problems with the UB NetCI interface in
IBMPC Kermit v2.31.  I downloaded the source this evening and MSXIBM.ASM
required the following changes before the UB CI would work:

    1. Change all interrupt procedures to PROC FAR (mentioned earlier)

    2. Add lines between outch3: and outch3a: as follows -

outch3: cmp     clone,0                 ; real uart?
        je      outch3a                 ; e = yes
        cmp     clone,'N'               ; network?
        je      outch8                  ; e = yes, using netbios
add-->  cmp     clone,'U'               ; UB?
add-->  je      outch8                  ; e = yes, using netbios setup
        jmp     outch6                  ; default for others ('B' clones)
outch3a:push    cx                      ; Save registers

    3. In ubsend, xmtbuf does not contain our info- xmtbufx does; so change

        jcxz    ubsend1                 ; dont send zero chars           [ohl]
        mov     bx, offset xmtbuf       ; buffer address in es:bx        [ohl]
        mov     ax, datas
        mov     es, ax
to
        jcxz    ubsend1                 ; dont send zero chars           [ohl]
changed-->mov     bx, offset xmtbufx    ; buffer address in es:bx        [ohl]
        mov     ax, datas
        mov     es, ax

    These three minor changes appear to fix the interface.  Thank you again
for providing the program and source.

-Doug Schafer
[e-mail]

[Ed. - Thanks for the fixes!  They have been passed along to Joe Doupnik,
and there should be a maintenance release of 2.31 soon, which fixes this and
a couple of other problems.]

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

Date: Fri, 15 Jul 88 15:42:24 EDT
From: cucard!dasys1![e-mail] (Ed Ravin)
Subject: MS-Kermit 2.31 -- SET PORT UB-Net1
Keywords: MS-DOS Kermit 2.31, Ungermann-Bass

I just tried using MS-Kermit 2.31 on our Ungerman-Bass network.  The
MS-Kermit docs say that when I issue the "CONNECT" command after "SET PORT
UB-Net1", I should see the NET-CI prompt and be able to use the usual NET-CI
commands.  Alas, I saw nothing.  Not only that, but when I tried to exit
Kermit, my PC went into a "waiting state", where the PC hangs up, but a
chirp is issued every few seconds to let you know that it is still trying to
access something or someone on the network that can't be found.

I can still use U/B's NET-CI driver (NETCICOM.DRV) without any problem: not
only that, but if I use NETCICOM to redirect a com port (such as COM3), and
then tell MS-Kermit to use port BIOS3, everything works fine and I can
access the NET-CI interface without difficulty.  Any idea why I can't use
the "SET PORT UB-Net1" command?

            Ed Ravin

            [e-mail]
        or
            [e-mail]

[Ed. - See previous message.  The problem will be corrected shortly.]

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

Date: Tue, 19 Jul 88 00:31 PDT
From: CARL FUSSELL <[e-mail]>
Subject: MS-Kermit 2.31 Bug (Feature?)
Keywords: MS-DOS Kermit 2.31

I just downloaded the latest version of MS Kermit (2.31).  There seems to be
some unexplainable behavior when running a script.  We run a typical script
to login to a VAX/VMS system.  The script worked fine under version
2.31-test5 but caused a strange problem when used under the final 2.31
distribution.  The problem that appears is that TAB characters aren't
displayed correctly.  Instead of tabbing to the next tab stop, the display
is tabbed to column 80 with the remaining text wrapping to the next line.
This does not happen using the same script with V2.31-test5.

The script line that causes the problem is the initial CLEAR statement.
Leave it in and the problem described above appears.... remove it (or
comment it out) and it works.  Fortunately for us, everything works ok with
the line removed.

Anyway, just tho't I'd pass this along...  (the script is attached if
interested.)

Carl Fussell
Santa Clara Univ
[e-mail]

[Ed. - We have had one other similar complaint -- i.e. that the CLEAR
command, which is supposed to clear only the serial port input buffer,
also clears the tab stops.  But no matter how hard we try, we can't
reproduce it.  We'll try again to pin it down.  Meanwhile, the workaround
is to put a "SET TERM TAB" command after the CLEAR command.]

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

Date: Mon, 25 Jul 88 13:01:26 -0500
From: Mark Bergman <[e-mail]>
Subject: MS-Kermit v2.31 Scripts
Keywords: MS-DOS Kermit 2.31, Scripts

Many thanks for all the improvements in MS-Kermit v2.31!  Its already making
lives easier here by providing a much-requested auto-dialing capability.  I
do have a question about using the INPUT command as part of a take file
(actually mskermit.ini) to allow the user to choose what number to dial.  I
want to ask the user whether to connect to the Rockefeller University system
or not (expanding to other choices in the future).

I was trying statements in the form:

 echo Connect to the Rockefeller system? (yes or no)\13
 input 45 yes @CON
 if success goto CONTINUE

which fails (according to an "if success" test) when the first key is
pressed, regardless of the input.  No <RETURN> is needed, and the input is
not echoed.

I also tried statements in the form:

 echo Connect to the Rockefeller system? (yes or no)\13
 input 45 @CON yes
 if success goto CONTINUE

This succeeds (according to an "if success" test), in every case.  The input
is not checked, but it always succeeds.  The input text also must be
followed by two <RETURNS> before it is recognized, and the characters are
not echoed while this is run.

I wanted to know if you had an example of a script that read and tested
input from the keyboard.  I also wanted to know if there was any way to
supress the "?Timeout" error message.  The script provides it's own error
message.

                                        Mark Bergman
                    Rockefeller University
                    Computing Services
                    Box 247
                    1230 York Avenue
                    New York, New York 10021

                                        212-570-7510

  BEST PATH==>     [e-mail]
            [e-mail]
            [e-mail]

[Ed. - Version 2.31 does not include a mechanism to do what you want.
INPUT only looks at the communication port, not the keyboard.  A future
release will include this feature.]

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

End of Info-Kermit Digest
*************************
-------
10-Aug-88 12:11:18-EDT,29230;000000000000
Mail-From: SY.CHRISTINE created at 10-Aug-88 12:10:34
Date: Wed 10 Aug 88 12:10:34-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V8 #5
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 10 Aug 1988       Volume 8 : Number 5

Departments:

  ANNOUNCEMENTS -
    Columbia University IP Host Numbers to Change
        Kermit Files Available via UUCP at Oklahoma State U
        Announcing Apple II Kermit Version 3.84

  MS-DOS KERMIT -
    Typo in MSKERM DOC
        Support for AT&T 6300 Graphics Card
        Kermit-MS 2.31 and AT&T Graphics
        MS-Kermit and a Local Printer
        MS-Kermit 2.31 (?More parameters are needed) Message
        MS-Kermit 2.31 Internal Modem Problems
        RE: MS-Kermit 2.31 Bug (Feature?)
        MS-Kermit 2.31 IBM 17 July 1988 Eats nulls
        VT200 Support in MS-Kermit?
        MS-Kermit with Async Servers?
        MS-DOS Kermit 2.31 and Local Printer
        MS-Kermit 2.3x Bug?  2.31 And Z-100's ZPC
        Z-248 COM3 and Kermit
        MSUCHK/SCANCHECK and the Rainbow

  MACINTOSH KERMIT -
        MacKermit Checksums
        MacKermit and Binary File Transfer
        Transferring application via MacKermit 0.9(40)
        MacKermit Escape Sequence Keys

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: Mon, 8 Aug 1988 8:08:08 EDT
From: Christine M. Gianone <[e-mail]>
Subject: Columbia University IP Host Numbers to Change
Keywords: IP Host Numbers, CU20B, Internet, FTP

Effective August 15th, 1988, Columbia University Computer Center Internet
hosts will be moved from subdomain 32 to subdomain 40.  In particular, the
IP host number for CU20B.CC.COLUMBIA.EDU (the host from which Kermit files
can be FTP'd over the Internet) will change from 128.59.32.128 to
128.59.40.128.  This change was posted to the NIC, but Internet sites that
have not updated their host tables, or which do not route through a domain
server, will not be able to reach CU20B by mail, FTP, or other Internet
protocol except by specifying the host number.

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

Date: Mon, 8 Aug 1988 13:55:09 EDT
From: Christine M. Gianone <[e-mail]>
Subject: Kermit Files Available via UUCP at Oklahoma State U
Keywords: UUCP, Okstate

Just a reminder for those who might not know about this already: a complete,
though not necessarily totally up to date, collection of Kermit files is
available via dialup UUCP or Kermit protocol at Oklahoma State University,
courtesy of Mark Vasoll and the folks in the Department of Computing and
Information Sciences.

Full instructions (too long to list here) are in the file KER:AANOKS.HLP on
CU20B, or AANOKS HLP on KERMSRV at CUVMA.  If you're not on the Internet or
BITNET directly, you can send mail to KERMSRV asking it to send you this
file:

    To: [e-mail]
    (through whatever UUCP/BITNET gateway you know about)

    Subject: (doesn't matter)

    Message text:
    mail aanoks.hlp

Thanks once again to Oklahoma State for providing this service.

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

Date: Mon, 01 Aug 88 07:28:02 PDT
From: Ted Medin <[e-mail]>
Subject: Announcing Apple II Kermit Version 3.84
Keywords: Apple II, ProDOS

Kermit-65 is truly a network project with many people sugesting improvements
and reporting bugs & problems. We wont name them all but here are a couple of
major contributors, Murray Sewall & Bob Holley. Again thanks to all.  Here
are the changes:

1. Prodos text files now 8 bits wide.
2. More vt100 fixes (will it ever stop!)
3. Start of packet now variable
4. Multiple protocols (Kermit and Xmodem)
5. TAKE command
6. DOS 3.3 more robust (almost bullet proof?)
7. Lots of little fixes and options

[Ed. - Thanks, Ted!  The new files are in KER:APP*.*.]

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

Date: Sat, 30 Jul 88 14:06:40 EDT
From: Harold Pritchett <[e-mail]>
Subject: Typo in MSKERM DOC
Keywords:  MS-DOS Kermit 2.31 Manual

Found the following in the current version of the MS-DOS KERMIT USERS GUIDE
from KERMSRV at CUVMA.

In Figure 1-3, the first line of the sample script reads:

     if defined % %to start            ; Make sure number specified.

It should read:

     if defined %\1%%to start            ; Make sure number specified.

Just thought you would like to correct it.  (I really don't read with that
sort of accuracy.  I cut the script out and tried to run it and it didn't
work...)

Harold

[Ed. - Hmmm...  Our copy of the manual reads "if defined %\1 goto start".
Don't know where "if defined % %to start" came from, but in any case, it
SHOULD read "if defined \%1 goto start" (\%1 instead of %\1).  There's also
a problem with the previous figure, 1-2.  Namely, the ermsg macro won't
print the entire error message, but only the first word, e.g.  "ermsg No
login prompt!" will only print "No".  Version 2.31 of Kermit doesn't have a
straightforward way to pass an arbitrary string of blank-separated words to
a macro, so the messages have to be made into single "words" like this:
"ermsg No_login_prompt!".  Sorry for the errors.]

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

Date: 19 Jul 88 22:57:00 CDT
From: "DAVID GAY" <[e-mail]>
Subject: Support for AT&T 6300 Graphics Card
Keywords: MS-DOS Kermit 2.31

Version 2.30 of MS-Kermit supports the AT&T 6300 graphics card for the
Tektronix emulation just fine, but version 2.31 does not. The setup shows
that the terminal graphics is set to AT&T 640x400, but the plots are done in
CGA 640x200 mode. I am using the MSVIBM.EXE which was FTPed directly from
Columbia on July 8, 1988.

and more......

After discovering that MSKERMIT 2.31 July 1, 1988 did not correctly support
the 640x400 graphics mode of my AT&T 6300 as v2.30 did, I FTPed waht looked
like an updated version of MSVIBM.EXE from COLUMBIA.  Unfortunately, the bug
is still present. Even though the SHOW TERMINAL lists ATT as the graphics
mode, everything is done in CGA 640x200 (ugh!)  mode. Please inform me when
this bug gets fixed so that i may retrieve a new copy.

Thanks,

David Gay
[e-mail]

[Ed. - We don't have a PC with an ATT graphics board here to test it on,
but we do have a VAXmate, which has an ATT compatible board.  It normally
runs in CGA mode, but if you SET TERMINAL GRAPHICS ATT, then it uses the
higher resolution graphics just fine.]

[From jrd - I wonder if we are encountering a Bios version number effect.
For AT&T machines Kermit looks for the word 'OLIVETTI' in the Bios starting
at locations FC00:0h or FC00:2014H.  It would be worthwhile using Debug to
probe your Bios.]

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

Date: Tue, 26 Jul 88 16:53:05 EST
From: Anne Chetham-Strode <[e-mail]>
Subject: Kermit-MS 2.31 and AT&T Graphics
Keywords: MS-DOS Kermit 2.31

I am testing Kermit-MS 2.31 on an AT&T PC6300.  The PC6300 supports CGA mode
as well as AT&T's "high resolution" 640 x 400 mode.  Kermit-MS 2.30 detected
and supported the high resolution mode automatically.  Version 2.31 does not
seem to support it.  "Set Term Graphic ATT" and "Set Term Graphic EGA" both
produce CGA mode.

Also "Set Term Graphic VGA" on a PS/2 Model 30 produces CGA mode.

If you intend to work on this, I am happy to help with testing.

Thank you for your attention.

[From jrd - see comments above on AT&T 6300's.  Selecting SET TERM GRAPH VGA
in turn selects video mode 17 (11H) for monochrome monitors or mode 18 (12H)
for color monitors, 640x480 by 2 or 16 colors, respectively, provided the
display adapter passes the EGA tests.  My brief PS/2 Model 30 specs show it
to support mode 17 (mono) but not 18 (color) so Kermit must have decided that
a color display was being used or that the adapter did not pass the EGA tests.
If it passed the EGA tests then 640x350 mode would have been employed.  There
is no Model 30 nearby so I can not easily check it.  Help on Model 30's would
be appreciated.]

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

Date: Wed, 20 Jul 88 15:06:25 GMT
From: Dermot O'Beirne <[e-mail]>
Subject: MS-Kermit and a Local Printer
Keywords: MS-DOS Kermit 2.31, Printer, 3COM EtherSeries

Does MS-Kermit 2.3x "talk" to the printer port continually when Cntrl-Prt-Scn
is in use ...... even when there is no input to or output from the Host?

We link to a spooled printer on a LAN by linking PRN: to the network printer.
The spool file automatically closes and writes to the printer if no data is
sent to this file for a period of 30 seconds (3Com EtherSeries !). This works
fine in MS-Kermit Version 2.29 when, with the Ctrl-Prt-Scn activated, and no
keyboard activity for 30 seconds the printer echoes.  With MS-Kermit 2.3x this
is not the case.  Even with no activity (unless Kermit generates some ?), the
print spool file stays open indefinitely or until explicitely closed by
unlinking the printer or dumping a new file at it.  I have read how 2.30 uses
the interrupts etc. but cannot understand why there is this difference.  Is
this a bug or feature?

Any ideas? Is there a SET option to overcome this?

Thanks.
Dermot O'Beirne                <DOBEIRNE@IRLEARN>
Computer Centre
University College Dublin
Ireland

[From jrd - While there seems to be a SET command for almost everything, there
is not one for your case, nor Kermit does send keep-alives to the printer. It
uses just normal DOS writes to the standard printer device (file handle 4)
when characters arrive, and that 'file' is opened and maintained by DOS rather
than by Kermit.  Buffering strategies by DOS will affect when the network
spooler flushes the queue.  Experience here with a similar LAN arrangement
(Novell NetWare) gives unpredictable results with many applications programs,
so you have company but no firm answers.]

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

Date: Thu, 21 Jul 88 08:27 EDT
From: Pete Kanaitis <[e-mail]>
Subject: MS-Kermit 2.31 (?More parameters are needed) Message
Keywords: MS-DOS Kermit 2.31

I just downloaded MS-Kermit V2.31 1 July 1988.  I noticed that certain
commands with a question mark on the command line (without a carriage
return) cause the "?More parameters are needed" error message.  Typing "?"
or "set ?" (no carriage return on either one) as the *FIRST* command after
starting KERMIT from DOS will display the normal help, then the "?More
parameters..." message.

Pete Kanaitis
Allegheny-Singer Research Institute
[e-mail]

[From jrd - Thanks Pete.  This will be fixed in the next rlease.]

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

Date: Mon, 25 Jul 88 14:14:44 +0300
From: Ze'ev (Steed) Shtadler <[e-mail]>
Subject: MS-Kermit 2.31 Internal Modem Problems
Keywords: MS-DOS Kermit 2.31, SmartLink.

I got the new MS-Kermit 2.31 version, translated MSVIBM.BOO and tried it.
Well, it couldn't talk to the internal modem.  I couldn't make it operate in
any way I tried.  MS-Kermit 2.30 had no problems with the same hardware
configuration.

I use an XT Turbo clone (COPAM 401), MS-DOS 3.30, SmartLink 1200B as COM1:,
no other RS232 cards, a real-time clock and 2 parallel ports.

Did anyone experience a similar behavior with this new version?  Using this
modem, Using other modems?

Any suggestions for solving/determining the problem?

                        Thanks in advance,
                                Ze'ev Shtadler.

Ze'ev Shtadler.
Computer Science Faculty,
Technion, Israel Institute of Technology,
Haifa Israel
Phone (work):   ([phone]

BITNET:  steed@techunix
Domain:  [e-mail]
UUCP:    ...!psuvax1!techunix.bitnet!steed
ARPANET: [e-mail]
CSNET:   [e-mail]

[From jrd - I presume the IRQ is set to 4 and the i/o address to 03F8H, for
COM1. If the modem were not found Kermit would say either the port is
unavailable or operates through the Bios.  Otherwise, if the modem can be
dialed but the screen shows nothing then the IRQ jumper is not set to 4 for
COM1.  After that I'd be guessing.]

[Ed. - We have heard that certain internal modems can be configured by the
accompanying software (e.g. Smartcom for Hayes), and that this same software
can leave the modem in a state that is unusable by any other program,
including Kermit.  Sometimes fooling with the modem's configuration program
can clear up the problem.]

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

Date: Thu, 4 Aug 88 14:37 MDT
From: <[e-mail]>
Subject: RE: MS-Kermit 2.31 Bug (Feature?)
Keywords: MS-DOS Kermit 2.31, Tabs

In response to Carl Fussell's message in Info-Kermit Digest V8 #4:

For the life of me I can see no reason why CLEAR and Tab stops
could interact this way. The VT102 will clear all tab stops when it receives
the command ESC [ 3 g from the host.  As a quick check you might add the
STATUS command to the script file in a few places; tabs will be shown at the
end of the display.  Even then, the terminal emulator is not activated until
the Connect command.  A puzzle, or a damaged BOO file.

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

Date: 1 Aug 88 14:01:12 EDT (Mon)
From: [e-mail] (Christopher P. Lent)
Subject: MS-Kermit 2.31 IBM 17 July 1988 Eats nulls
Keywords: MS-DOS Kermit 2.31

Hi,
    Sorry to complain, but MS-Kermit 2.31 17 July 1988 removes nulls from
the terminal session.  Normally this is not a problem, BUT we have an
application which captures binary data from a Perkin-Elmer FT-IR Model 1600
via the LOG SESSION command.  Since MS-Kermit 2.31 eats nulls, we have to
remain at MS-Kermit 2.30 for now.

REPEAT BY:

If you have a UNIX system around an easy way to test this is to go:

$ echo "A NULL \0 <---" >null.lis
$ od -c null.lis
0000000   A       N   U   L   L      \0       <   -   -   -  \n
0000016
$ #                                  ^------- Note the null in the file
$ # at this point turn on debugging with SET DEBUG ON
$ # then reconnect and go
$ cat t.lis

On Version 2.30 the null appears as ^@ and is also put in the SESSION LOG
file, while on 2.31 the null is gone from both the terminal session and the
session log file.

In conclusion, Kermit is wonderful but this problem makes our user rather
unhappy.  Admittedly it's not Kermit's intended use but it would prove
useful from time to time.  Hope a fix will make it into the next MS-Kermit
release.

Thanks,
Chris Lent
[e-mail]
[e-mail]
philabs!phri!cooper!chris

[From jrd - Chris, to increase terminal emulation throughput both NULLs and
DEL characters are filtered out right in the serial port interrupt routine.
DEL is passed if Tektronix emulation is active.  Both were supposed to be
passed when DEBUG was active but a small glitch did not let NULL through
even then.  We dare not let these two characters get into the log file since
they are normally fillers and would make a great mess when the log file
is later edited or manipulated by ordinary tools.  I suppose a case could be
made that both should be passed if transparent printing were active, but
again filler characters from the host would also go to the printer.  Still,
they should not be in the session log.]

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

Date: Wed, 6 Apr 88 15:59:30 EST
From: [e-mail]
Subject: VT200 Support in MS-Kermit?
Keywords: VT200 Support

What we would really like to see Kermit do is emulate at least one feature
of the VT200 - the ability to download soft character sets.  That is, we
would like to use Kermit with an application which manages and down loads
software character sets to the terminal in order to allow a wide variety of
characters to be displayed.

Do you know:

 - if such a feature is planned?
 - if anyone out there have implemented such a feature
 - if, given we have the source and resources, its a big job?

Thanks in advance,
Les Flodrowski
Social Science Computing Lab, U. of Western Ontario.      [e-mail]

[From jrd - VT220 support has been discussed but no one has volunteered to
take on the task.  Once VT220 support starts it needs to be rather complete
because people naturally then expect all the features.  A partial work around
is to load the SET TRANSLATION INPUT table from a Take file, to change in
coming characters, and to use SET KEY for outgoing ones.  In any case, the
displayable characters are restricted to those built into the Bios and display
adapter; i.e., the ordinary ASCII plus IBM extended ASCII set.  Since sources
are available you might wish to know that the job is certainly not small.]

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

Date: Mon, 1 Aug 88 11:54:33 edt
From: Jim Gogan <[e-mail]>
Subject: MS-Kermit with Async Servers?
Keywords: MS-DOS Kermit 2.31

I would like to hear from anyone using MS-Kermit 2.31 over a network to an
async communications server (such as IBM's LAN Async Communications Server
Program or Novell's ACS).  We are looking for something (anything!!) that
will let us attach up to 8 hardwired async lines to a communications server
on a PC network (primarily token ring and Ethernet hardware) without having
to use ASCOM, Smartcom or Crosstalk!!  Is this possible with Kermit 2.31?
What products are any good (not just available) for async server capability?
I don't care about dial-in capabilities; we just want to get access to other
campus hosts for the users on the PC nets.  Please e-mail any and all
success/horror stories & I'll summarize if appropriate.  Thanks in advance.

   Jim Gogan
   Univ. of North Carolina
   Microcomputing Support Center
   Phone: [phone]
   E-mail: ugogan@ecsvax (UUCP or BITNET) or [e-mail]

[From jrd - IBM's Async Comms Server needs a special protocol across the
network, and I suspect so does Novell's ACS. I have the specs on the IBM
item; in fact, I have a MS student doing an analysis of it. However, it
does not mesh well with the current Kermit procedures. There might be some
async servers, such as the updated IBM ASC from Yale, which expect the client
to use the local Bios path to the serial port; Kermit supports that route
via SET PORT BIOSn (n=1-4).]

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

Date: Thu, 21 Jul 88 07:59:00 CDT
From: [e-mail] (Moore)
Subject: MS-DOS Kermit 2.31 and Local Printer
Keywords: MS-DOS Kermit 2.31

Sorry, I should have looked closer before I complained about the local
printer problem a while back.  Seems that, prior to 2.30, parity none
allowed transparent printing with no problem; with 2.31, at least on our
4.3bsd host, parity must be set to space in order to let both transparent
printing and file transfers take place (setting parity to even disables
transfers completely!).

Thanks for the assistance.

Jim

[Ed. - The behavior of parity is rather complicated.  UNIX sends even parity
during a terminal session.  MS-Kermit, by default, strips parity of incoming
characters during CONNECT.  UNIX Kermit, once it is invoked, transfers files
with no parity (uses all 8 bits for data).  Thus normally, you don't need to
SET PARITY to anything when connecting a PC to a UNIX system -- both
terminal connection and file transfer work.  Transparent printing, however,
as of 2.30, is intended to work with full 8-bit binary bytes to allow for
printing of special characters.  If you don't tell MS-Kermit that incoming
characters have parity, it will route them to the printer that way, which of
course produces a messed-up listing.  So for transparent printing with a VAX
on the other end, you should SET PARITY EVEN (or SPACE or anything else),
but then to transfer files, also remember to SET PARITY EVEN (or SPACE
or...) on the VAX Kermit too.]

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

Date: Tue, 2 Aug 88 12:24:21 edt
From: [e-mail] (James A. Lupo)
Subject: MS-Kermit 2.3x Bug?  2.31 And Z-100's ZPC
Keywords: MS-DOS Kermit 2.31, Z-100, ZPC

I have noted a slight bug in MS-Kermit, Versions 2.30 and 2.31, with the
"set term color" command.  If bright foreground colors are specified, as
in:
    set term color 1 37 44

The terminal display does indeed show bright white characters on a blue
background.  However, receipt of a terminal reset sequence, specifically,
<ESC>[0m, causes the display to drop to low intensity white on black.
The screen remains this way until one escapes to the Kermit command mode
and subsequently re-connects to terminal mode.  At that point, new text
is displayed once again in high intensity until the next reset sequence is
received.

Side Note for Z-100 Users

I recently upgraded my Z-100 low profile computer with the Heath User's
Group ZPC IBM-PC emulation software and a Scottie Systems Scottie Board with
COM1 adapter.  I had great difficulty in getting Version 2.30 to run, and
have not isolated all problems yet.  However, Version 2.31 runs hot out of
its BOO file translation with no modification.  The ZPC package emulates a
CGA display, and both the VT102 and TEK4010 modes so far operate flawlessly.
Even though running Kermit in emulation this way does not make use of the
640x480 resolution available on a Z-100, it still makes a very servicable
comm package (at least until the Z-100 Kermit reaches the 2.3x level??).

LtCol James A. Lupo
Assistant Professor of Physics
Air Force Institute of Technology (AFIT/ENP)
Wright-Patterson AFB, OH 45433-6583

E-Mail:  [e-mail]

[From jrd - ESC [ 0 m means reset the display attributes of bold, blink, and
inverse rather than reset the terminal (ESC c), so a dim display is the
natural result.  Color change is not a host command and probably relates to
your non-Connect mode screen attributes (which Kermit uses until told
otherwise).  ZPC emulation: that's good news!]

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

Date: Thu, 4 Aug 88 10:09:35 CDT
From: [e-mail] (Moore)
Subject: Z-248 COM3 and Kermit
Keywords: Zenith Z-248, COM3, MS-DOS Kermit

I know the subject of COM3 on the Z-248 has been beaten to death, but I got
an interesting little program from Zenith called COM3.COM, which is supposed
to map COM[1-2] I/O to COM3.  Well, it works at 1200baud with Kermit, but at
any higher speeds characters get lost regardless of the handshaking.

Has anyone been able to get COM3.COM to work with Kermit?  I'll post results
if they're compelling.

Thanks.

Jim
[e-mail]

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

Date: Mon, 25 Jul 88 18:33:15 EST
From: John C Klensin <[e-mail]>
Subject: MSUCHK/SCANCHECK and the Rainbow
Keywords: MS-DOS Kermit, Rainbow Kermit

I probably should have anticipated this, but the MSKERMIT scan program,
SCANCHECK (distributed as MSUCHK) goes crazy when one attempts to run it
on a Rainbow under MSDOS 2.1.  SHOW KEY from within Kermit, while
tedious, works fine.

This might at least be worth a note in a .BWR file.

[Ed. - Noted.]

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

Date: Fri, 22 Jul 88 11:10:58 EDT
From: [e-mail] (Valerie Mates)
Subject: MacKermit Checksums
Keywords: MacKermit 0.9(40)

Hi!  I'm using MacKermit 9(40) on a Mac II, connected to a Sun running
C-Kermit 4E.  During file transfers when it should be using type 1
checksums, MacKermit's display window says it's using type 0 checksums.  It
also says that the window size is 00.  Several large, binary files have been
corrupted during transfers with "type 0" checksums.  Any idea what's
happening?

Thanks!
Valerie Mates

[Ed. - The block check display is probably a mistake.  Kermit doesn't
transfer files without error checking.  We'd have to know a lot more detail
about the corrupted binary files -- what system was on the other end, what
version of Kermit, what kind of connection, etc.]

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

Date: Fri, 15 Jul 88 00:42:26 EDT
From: [e-mail]
Subject: MacKermit and Binary File Transfer
Keywords: MacKermit 0.9(40), MacBinary

The problem I am trying to work with MacKermit is to transfer a Stuffit
file (which is MacBinary) from the SIMTEL20 archives to my Macintosh via
another, UNIX, ARPANET host.  The master files are being retained in binary
on SIMTEL20 to conserve disk space.  Since I have no disk space there and
am also unaware of a Mac file ASCII conversion program on the DEC20) I
cannot convert it there before transfer. I do have disk space on the UNIX
host but I also am not aware of a conversion program resident there. I
have done XMODEM transfer from there since one of the system people kindly
put it up for me so I am not desperate.  However I was curious as to whether
there exists a technique for double file transfer with subsequent glueing
back together. I would like to suggest that support of MacBinary transfer
would make the program enormously more useful for Mac users.

- Maretta Holden

[Ed. - See the next message...]

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

Date: Fri, 15 Jul 88 10:21:36 PDT
From: [e-mail] (Dave Platt)
Subject: Transferring application via MacKermit 0.9(40)
Keywords: MacKermit 0.9(40), MacBinary

If you wish to transfer a Mac application (or other file containing a
resource fork) with MacKermit 0.9(40), I'd suggest running the file through
BinHex 5.0 (not 4.0).  BinHex 5.0 will translate the file into MacBinary
format; the resulting file is pure data (no resource fork) and can be
uploaded using MacKermit's binary-file transmission option.  The resulting
file can be downloaded in the same way, and then reconverted via BinHex 5.0.

The biggest advantage to using BinHex 5.0, as opposed to PackIt or StuffIt,
is that the uploaded file on the mainframe/BBS is stored in MacBinary
format.  It's therefore compatible with any terminal emulator/downloader
that supports automatic MacBinary conversion; for example, one could
download such a file using MacTerminal 2.0, Red Ryder, MicroPhone, FreeTerm,
or VersaTerm... and all of these programs would automatically convert the
file back into a Mac application as it was received.  Similarly, any of
these programs could be used to upload an application or document to a
mainframe or BBS in MacBinary format; the resulting file can be downloaded
using binary MacKermit and then run through BinHex 5.0 to restore it to its
original form.

Dave Platt                                             VOICE: [phone]
  USNAIL: Coherent Thought Inc.  3350 West Bayshore #205  Palo Alto CA 94303
  UUCP: ...!{ames,sun,uunet}!coherent!dplatt     DOMAIN: [e-mail]
  INTERNET:   coherent![e-mail],    [e-mail],    [e-mail]

[Ed. - And obviously, automatic MacBinary translation is high on the list
for Mac Kermit too.]

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

Date: Tue 26 Jul 88 17:19:30-PDT
From: Mike O'Rourke <[e-mail]>
Subject: MacKermit Escape Sequence Keys
Keywords: MacKermit 0.9(40)

Greetings.  I am a MicroComputer Consultant for the University of Southern
California.  We recently received MacKermit 0.9(40) and MSKermit 2.30 for
our Labs and have a question for you.

Many of our users connect to IBM Mainframes (MVS and CMS) using XVT100
emulation (VT102 really), and have trouble trying to find out the escape
sequences - PF Keys, Break keys, Insert Keys, Clear Screen, etc.  If you
have such mappings, most notably for the Mac, we would dearly appreciate any
info you could offer.

Thanks in Advance,

Mike O'Rourke

[Ed. - Mac Kermit 0.9(40) does not come with a default set of VT100 key
mappings.  Users are encouraged to put together Mac Kermit settings files
for this and send them in, so we can add them to the distribution.]

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

End of Info-Kermit Digest
*************************
-------
18-Aug-88  1:03:43-GMT,26310;000000000001
Received: from cucca.cc.columbia.edu by cunixc.cc.columbia.edu (5.54/5.10) id AA12983; Wed, 17 Aug 88 21:03:34 EDT
Received: from CUVMB.CC.COLUMBIA.EDU by cucca.cc.columbia.edu (5.54/5.10) id AA23801; Wed, 17 Aug 88 21:02:46 EDT
Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Wed, 17 Aug 88 21:02:29 EDT
Received: by CUVMB (Mailer X1.25) id 7562; Wed, 17 Aug 88 21:02:25 EDT
Date:         Wed, 17 Aug 88 21:01:53 EDT
Reply-To: [e-mail]
Sender: INFO-KERMIT Digest <[e-mail]>
From: Christine M Gianone <[e-mail]>
Subject:      Info-Kermit Digest V8 #6
Comments: To: [e-mail]
To: Frank da Cruz <[e-mail]>

Info-Kermit Digest         Wed, 17 Aug 1988       Volume 8 : Number 6

Today's Topics:

                        Announcing the End of CU20B
             Announcing a Maintenance Update for MS-Kermit 2.31
          Announcing MS-Kermit 2.31 for NEC-PC9801 with Kana-Kanji
               Announcing MS-DOS Kermit 2.31 for the Wang PC
                        Binary File Types on the VAX
     Kermit 3.82 and the Applied Eng. Serial Pro Work Together Finally
                   CMS Kermit and 7171 Protocol Converter
                       CMS-Kermit with Commtex Cx-80
              KERMIT through Commtex Cx-80 Protocol Converter
                Kermit Through Protocol Converters Under CMS

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

Date: Tue, 15 Aug 88 19:16 MDT
From: Christine M. Gianone <[e-mail]>
Subject: Announcing the End of CU20B
Keywords: CU20B, CUNIXC, Kermit Distribution, Network, FTP

This will be the final issue of the Info-Kermit Digest that is sent from our
last DEC-20 (once a fleet of four).  DEC-20s were important to the original
development of Kermit -- much of the protocol was designed "around" them, one
of the first Kermit programs was written for the DEC-20, and the DEC-20 style
of "user interface" is found in many popular Kermit programs -- MS-Kermit,
CP/M Kermit, C-Kermit, etc.

Kermit's new "home" will be on CUNIXC.CC.COLUMBIA.EDU, a VAX 8700 running
UNIX (Ultrix).  The IP host number is 128.59.40.130.  You should be able to
get files from it with anonymous FTP, just as you did from CU20B, except that
now you're talking to a UNIX, rather than TOPS-20, FTP server.  The Kermit
files are in directories kermit/a, kermit/b, kermit/c, kermit/d, and kermit/e.
You can also send mail to Info-Kermit and Info-Kermit-Request at the new
address.

The process is roughly like this: FTP to CUNIXC.CC.COLUMBIA.EDU, login
anonymous, any password, and then CWD (or CD) to kermit, which contains a
file read.me, which you should read.  Then CWD (or CD) to a, b, c, d, or e
and GET or MULTIPLE GET (or MGET) the files you want.  The AA*.* files are
still DEC-20 oriented, but will be updated soon.  Report problems to
[e-mail].  Also, remember that Columbia's
Internet host numbers changed on August 15th, as announced in the last
Info-Kermit Digest, so if you have trouble connecting, try using CUNIXC's
host number 128.59.40.130, instead of the host name.

Since CUNIXC is a heavily-used machine, please try not to FTP files from it
during peak hours.  There are presently no formal restrictions, so please
don't overburden the system.  If the response is very slow, cancel your
session and try again later.

During a brief transition period, CU20B will continue to house the Kermit
files, so if you have problems with CUNIXC, you can still return to "old
faithful".

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, 10 Aug 88 19:16 MDT
From: Christine M. Gianone <[e-mail]>
Subject: Announcing a Maintenance Update for MS-Kermit 2.31
Keywords: MS-DOS Kermit 2.31, IBM PC, Ungermann-Bass

This is to announce a maintenance release of MS-DOS Kermit 2.31 for the IBM
PC family only.  This version is being issued in order to correct several
problems in the original 2.31 release.  If you are affected by these
problems, then you should get the update, otherwise you needn't bother.  The
version number remains 2.31, but the date is changed to August 15, 1988 (as
displayed in the startup herald, or by the "version" command).  The items
that were fixed are:

 - Ungermann-Bass Net One support had two fatal bugs, now fixed.

 - The Bios in some machines objected to the stray interrupt generated when
   Kermit disconnected from the serial port.  Also solves problem of
   an earlier task, such as Smartcom II or PC-Talk III, forgetting to replace
   the serial port interrupt it borrowed and causing a crash during Kermit
   operations.

 - A serial port with COM2 addressing (port 02E8H, IRQ 3) placed in the
   COM1 Bios data area, such as happens with some PCjr's, could not be
   found.  Corrected to switch to COM2 addressing if the Bios data area
   for COM1 is 02E8H.  COM1 is normally port 03F8H and IRQ 4.

 - The main Kermit command line parser sometimes gave a spurious message
   "?more parameters are needed" when query mark help was used.

 - A bug in finding labels in scripts, as in the commands

        GOTO end
        :end1
        commands
        :end

   which let label ":end1" be jumped to by mistake if ":end1" appeared first.

 - The test for available disk space when receiving files with attributes
   packets inflated the disk space rather than the file size.  Revised to
   proper form: inflate file size by 17/16, decline file if not enough
   disk space.

 - The script CLEAR command could sometimes interfere with terminal emulation
   (lose tab settings, etc).

[Ed. - Thanks to Joe Doupnik for the rapid work in making these corrections!
The new files are installed in Kermit distribution in the usual places, as
well as in the new place (kermit/a on CUNIXC) and a more detailed description
from Joe of this release has been added to the MSKERM.BWR file.]

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

Date: SAT, 06 AUG 88 17:19:25 JST
From: "H.Fujii" <[e-mail]>
Subject: Announcing MS-Kermit 2.31 for NEC-PC9801 with Kana-Kanji
Keywords: NEC-PC9801, Japan, Kana, Kanji, MS-DOS Kermit 2.31, Fujitsu FMR-60

We (Hirofumi Fujii & Akihiro Shirahasi) have developed MS-Kermit for NEC
PC-9801, the most popular MS-DOS machine in Japan (more than IBM-PC!!).  The
big difference from other machines is Kana & Kanji treatment.  Kana & Kanji
are the Japanese characters developed from ancient Chinese characters. The
number of authorized characters is about 6000 (Level-1: 2965; Level-2:
3388).  These are specified by 2-byte codes.  Our program can handle these
characters in addition to usual MS-Kermit operation (including VT100,
TEK4014 emulation).

For Kana & Kanji treatment, it is very important that the MS-Kermit has the
8-bit display mode.  So, we have set the default mode to 8-bit display.

We have already tested this program with my friends and collaborators.  We
have tried to send Kana-Kanji mail and Kana-Kanji phone on VAX/VMS using
this Kermit.  Of course these utilities caused some problems because these
programs are not designed for 2-byte cahracters.  But many of the problems
are recoverable (e.g., by pressing ^W) and we found this program is very
convenient to communicate using Kana & Kanji.

So, we want to distribute this program as a 'free to use' program.  We have
named the modules as follows:

   MSVP98.BOO  -- BOO file for MSVP98.EXE (MS-Kermit for NEC PC-9801)
   MSVP98.DOC  -- Manual for NEC PC-9801 Kermit

   MSGP98.ASM  -- Macro Assembler source file for TEK4014 emulator
   MSUP98.ASM  -- Macro Assembler source file for Keyboard
   MSXP98.ASM  -- Macro Assembler source file for Machine-dependent interface
   MSYP98.ASM  -- Macro Assembler source file fir VT102 emulator

These are the files for MS-Kermit 2.31 for NEC-PC9801.  Please add these
files to your KERMSRV.

                                             Hirofumi Fujii
                                      KEK On-line group, Dept. of Physics,
                             National Laboratory for High-Energy Physics (KEK)

                                        BITNET address: KEIBUN@JPNKEKVM
                                HEPNET(DECNET) address: KEKVAX::KEIBUN

P.S.
1) I tried to SET KEY xxx <Kana-Kanji characters>. It worked well!  This is
owing to 8-bit character handling at MS-Kermit command level (a new feature
of version 2.31).
2) I have already started to install this program to another Japanese MS-DOS
machine, Fujitsu (mainframer) FMR-60 (their mainframe-machine is IBM
compatible but their peronal computer is NOT! -- Why?  I think it is due to
Japanese character sets).  At the present time, it works without Tek4014
emulation.

[Ed. - Many thanks for the valuable work you have done, and for contributing
it to the Kermit library!  The files have been installed in Kermit
Distribution under the names you listed above.]

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

From: Volker Edelhoff <[e-mail]>
Date: Fri, 22 Jul 88 14:39:42 +0200
Subject: Announcing MS-DOS Kermit 2.31 for the Wang PC
Keywords: MS-DOS Kermit 2.31, Wang PC

I adapted the machine-specific file MSXWNG.ASM for the Wang PC to assemble
and link with the rest of MS-DOS Kermit version 2.31 files correctly.  I did
no improvement to the functionality of it - I just added some externals and
dummy procedures to satisfy the linker.

BUT: the machine independent files of Kermit have been improved immensely
(script file, more comprehensive messages, better SHOW facilities, ...), so
that this adaption will be quite useful for the WANG PC/APC world, anyway!

The new files are as follows:

  Name         Size   Description
  MSVWNG.BAT   1223   Batch file for assembling and linking
  MSVWNG.BOO  71012   BOO-version of MSVWNG.EXE
  MSVWNG.EXE  63616   The WANG PC/APC Kermit Version 2.31
  MSVWNG.LNK    204   Link-script file used by MSVWNG.BAT
  MSVWNG.MAK   1890   MAKE-file for MS-Make
  MSXWNG.ASM  25256   The ASM-source code

                                Volker Edelhoff
                                Hennener Str. 35
                                D-5860 Iserlohn
                                West Germany

[Ed. - Many thanks, Volker!  The Wang PC version of MS-Kermit has not been
updated since 2.29, in May 1986, so this announcement should be most welcome
to Wang PC users!  The files have been added to Kermit Distribution under
the names listed above.  Now if only someone would write Kermit programs for
the Wang VS systems...]

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

Date: Tue, 26 Jul 88 09:34:32 CST
From: Bob Parks <[e-mail]>
Subject: Binary File Types on the VAX
Keywords: VAX/VMS Kermit, SAS

My problem is most likely due to ignorance of VAX file formats but here is
the problem.

SAS has a file format called TRANSPORT format and one uses it to transport
SAS internal data sets between machines (VAX, PC, CMS, etc).  The transport
file is written in ASCII and apparently uses all 256 different 'characters'.

The problem is that the transport data set is 80 characters per record, file
type fixed (e.g., no end-of-record indication - specifically no CR/LF
characters).  If such a transport file is transfered between the VAX
(KERMIT-32) and the PC, then at the end of each and every record there is a
CR/LF on the PC side.  I have tried SET FILE TYPE BINARY and SET FILE TYPE
FIXED and no SET FILE TYPE command and receieved the same files identically.

Possibly the VAX stores the transport data set with CR/LF even though it is
fixed length file (and maybe there is some fixup in SAS / VAX when creating
the transport data set).  BUT what I wanted, and what works between CMS and
the PC is CMS KERMIT's SET FILE BINARY that does not, on the PC side, get
CR/LF on each record.

Any suggestions appreciated.

Bob

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

Date: Thu, 28 Jul 88 09:46:04 CDT
From: "Wayne J. Hauber" <[e-mail]>
Subject: Kermit 3.82 and the Applied Eng. Serial Pro Work Together Finally
Keywords: Kermit-65, Super Serial Card, Apple II

A couple of months ago, I asked about Kermit 3.8* and the Applied Engineering
Serial Pro.  The Serial Pro is supposed to be Super Serial Card compatible but
I was having no luck getting the card to work with Kermit's Super Serial Card
driver.

I enabled interrupts like the Kermit manual (and everyone else) suggested by
closing the dip switches.  Kermit refused to work; when you enter CONNECT at
the Kermit-65 prompt the system freezes with the interrupt switches off and
appears to drop into the monitor with the switches on.

I tried lots of things and even browsed the Kermit source.  However, last
night I got Kermit to work with my Serial Pro.  The fix was unexpected and
seems a little weird to me.  I opened the switches that enable IRQ interrupts
for the 6551 and 6818 (switches 1 and 3) and closed the switches which enable
NMI interrupts (switches 2 and 4).  This should have disabled IRQ and enabled
NMI interrupts.

What is weird is this:  NMI interrupts are not supported on the Apple II
series of computer and IRQ is.  The switches I set should be the wrong
switches.  Non maskable interrupts (NMI) are supposed to crash an Apple II
into the monitor.  This sounds a lot like the symptoms I had.  Most people I
talked with thought it wouldn't hurt to leave all the interrupt switches on;
that was wrong in Kermit's case.  It doesn't hurt some of the other
communication programs on the market though.

My guess is that the AE Serial Pro User's Guide contains a mislabeled diagram
for its switch settings.  The switches labelled as NMI are really IRQ and
vice-versa.

(Ted, Mark or Murph):
With what should be the wrong switch settings, Kermit 3.82 works quite well
with my Serial Pro.  My previous comments about the Serial Pro have been
placed in a .BWR (beware) file at Columbia and have been read elsewhere.
Could someone with the appropriate clout update the .BWR file telling Serial
Pro users to open interrupt switches 1 & 3 and close 2 & 4?

Wayne Hauber
Iowa State University
gawjh@isumvs

[Ed. - Your new message has been placed in APPLE.BWR.]

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

Date: Wed, 3 Aug 88 11:11 EDT
From: <[e-mail]>
Subject: CMS Kermit and 7171 Protocol Converter
Keywords: CMS Kermit, Portable 370 Kermit, Protocol Converters

I am having major difficulties transferring files between a pc and CMS
through a 7171 protocol converter.  After a number of packets has been
transferred, the error message "Unable to receive acknowlegement from host"
appears.  The number of packets varies before this error appears and
sometimes it works perfectly with no error.  Is anyone else having problems
like this?  I have tried different bauds to no avail.  It seems to be an
intermitten problem.  Not only is it happening under CMS, but also on our
MUSIC/SP system which also goes through the 7171.  It leads me to believe
that it is something with the 7171 causing it.  Any information or advice
would be greatly appreciated!

Terry Lewis
University of Tennessee at Martin
TLEWIS@UTKVX1

[Ed. - If the problems are mainly when you're sending from the PC to the
host, they are likely traceable to small or insufficient input buffers on the
7171.  Make sure you're running an up-to-date 7171 system, and up-to-date
Kermits.  We can transfer 1000-byte packets from PCs into our CMS system
through a 7171 without even a hiccup.  And of course, also make sure you have
your communication parameters set correctly -- usually, SET PARITY EVEN is
the only change you have to make to the PC from its defaults.]

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

Date: Fri, 22 Jul 1988   11:52:26   CET
From: [e-mail]
Subject: CMS-Kermit with Commtex Cx-80
Keywords: CMS Kermit, Kermit-370, CX-80

We have a small IBM mainframe, which we got as donation from IBM for the
scientific research in general and in particular for the 600-year-anniversary
of Cologne University.  At the moment, we have a protocol converter named
Commtex Cx-80 as a test device, and we tried in vain to get Kermit running
through that box.  I must confess, I'm not very intimate with IBM mainframes,
with their special vocabulary and their four-digit names, but I'll try to
explain the configuration.

The IBM mainframe is a 4341 running VM/SP Rel.5 (CMS), the communications
controller is a 3705, where several remote cluster controllers are attached
via BSC (not SNA, as I was told). The Cx-80 can be used to attach
asynchroneous terminals and is in turn connected to a local network with
TCP/IP based on Ethernet.  We have installed CMS-Kermit 4.0 on the IBM, the
program runs succesfully through the converter, but the file transfer doesn't
work. I understand that it needs a transparent I/O mode in this
configuration, therefore I quote some lines from the Cx-80 documentation
about their transparent facilities:

>> In addition to the Cx-80's pass-thru mode, which is compatible
>> with many mainframe graphics and file transfer packages (e.g.,
>> products form SAS Institute and ISSCO), pass-thru operation
>> which is compatible with the IBM 7171 Hardcopy/Transparent
>> Write and Write/Read is now supported.

When I compare this with the CMS-Kermit documentation, I assume that the
first mode might correspond to SET CONTROLLER GRAPHICS, and the second mode
to SET CONTROLLER SERIES1.  CMS-Kermit comes up with SERIES1, which ends with
a bit more success than GRAPHICS.  What happens in SERIES1 mode is, that with
both XTYPE and Packet transfer most characters arrive correctly, but a few
are garbled (e.g. 7,- and & all appear as @). When I do a packet dump on the
CMS-machine, I see in the EBCDIC-dump all packets correctly, the RAW-dump
shows the incoming packets ok with their ASCII-code and the high-bit set, the
outgoing packets however, are dumped completely wrong.  So this dump is of no
great help either.  In GRAPHICS mode, I get an immediate disconnect from the
Cx-80, and there is a hint to this behaviour in the Cx-80 documentation:

>> In BSC systems, the Cx-80 will enter Pass-Though mode only if
>> the Command/WCC/X'70' sequence is written immediately following
>> device selection.
>> Any data which follows the X'70'is expected to be in the range
>> X'7F'through X'FE, inclusive. Upon receiving such data, the
>> Cx-80 will strip the most significant bit (resulting in data
>> in the range X'00'through X'7F', the full ASCII-128 set), and
>> deliver them untranslated to the addressed device.  ......
>> ... If any data following the X'70' is in the range X'40'
>> through X'7E'inclusive, the Cx-80 will interpret the data as
>> a host disconnect request and will respond by terminating the
>> connection between the terminal and the Cx-80.

Therefore my question: Does the CMS-Kermit conform to this description or is
it a special convention for the Cx-80 only?  Or do all the problems perhaps
occur, because CMS-Kermit is only designed for SNA-connections instead of BSC
and those two just are different in these places?

Jochen Roderburg
Regional Computing Center
University of Cologne
Robert-Koch-Str. 10                    Tel. :  [phone]
D-5000 Koeln 41                        Email:  A0045 @ DK0RRZK0.BITNET
West Germany

[Ed. - See following messages...]

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

Date: Sun, 17 Jul 1988 14:04 CDT
From: Landy Manderson <USTS034@UABTUCC>
Subject: KERMIT through Commtex Cx-80 Protocol Converter
Keywords: Protocol Converters, CX-80, TSO, 7171

I have a question about version 4.00 of MVS/TSO KERMIT, and I am hoping
this is the right place to send it.

We are using Commtex Cx-80 series 3270-to-ASCII protocol converters here at
UAB.  Our latest version of the Cx-80 software supports 7171 emulation, but
apparently only the Hardcopy/Transparent (115D7F110000) and Transparent
Write/Read (115D7F110001) commands.

Now, when I tried to do file transfer from PC to TSO through the Cx-80 I kept
getting a comm error 531, and it was apparently rejecting the 7171 orders
from KERMIT.  Upon inspection of the code, it appeared to be using the
command (115D7F110005), and it was sending ASCII data without the high-order
bit turned on.

I do not have a recent 7171 book (I do have one from 1984), so I do not have
any idea what command (....0005) is, but I changed our KERMIT to use the
Transparent Write/Read (....0001), and to set the high-order bit on in the
ASCII stream.  This seems to have worked, because now we can file transfer.

Is this a reasonable fix to our problem?  Is there any precedent for this,
and if so, has someone come up with a better way to do this?  Any help on
this would be appreciated.  Of course, this is not a super critical question
since we have gotten it to work as is.

Landy Manderson, Lead Software Specialist
User Services, The University Computer Ctr
University of Alabama at Birmingham (USA)

[From John Chandler - Landy, by coincidence, I have just heard from someone
else on BITNET who tried out Kermit (on CMS) through a Cx-80.  In that case,
it seemed that operation in SERIES1 mode was fine except for a few characters
that unaccountably got translated outbound to "@" signs.  I believe you'll
find that changing the write/read order was unnecessary, since the convention
in the 7171 and its ancestor, the Yale ASCII system, was to treat any buffer
address other than 0000 as a write/read.  I don't know why Kermit uses 0005,
instead of the more obvious 0001, but "that's how it has always been."  As to
the setting of the high-order bits in the ASCII data, we found that to
prevent the odd garbling of characters.  Below is the update I devised to
accomplish it.  It is unfortunate that this is necessary on the Cx-80, since
it is *not* on any other protocol converter that I know of -- in particular,
the 7171 can be configured to give a full 8-bit channel both ways for
convenient binary file transfer without 8th-bit quoting.

One point that interests me is one you did not mention, namely, the graphics
pass-through capability of the Cx-80.  What I heard of its documentation
suggested that you could also transfer files if you set CONTROLLER to
GRAPHICS in Kermit-TSO.  Would you mind trying it to find out?  Thanks.

                                  John
======================================================================
/ I 08511000          $ 8511500 500                  08/02/88 14:59:32
         LA    9,0(5,2)      Save start of ASCII stuff         @SC88215
/ I 08521000          $ 8521500 500                  08/02/88 14:59:32
         LR    3,2           Copy end of transmission          @SC88215
/ I 08523000          $ 8523200 200                  08/02/88 14:59:32
         LR    2,9           Start of ASCII stuff              @SC88215
         SR    3,2           Length                            @SC88215
         LA    15,ON80       Set high bits                     @SC88215
         BAL   14,TRANSLAT                                     @SC88215
/ I 08526500          $ 8526700 100                  08/02/88 14:59:32
         LR    6,8           Set up for log routine            @SC88168
/ I 08575000          $ 8575050 50                   08/02/88 14:59:32
* For setting high bits...                                     @SC88215
ON80     DC    X'808182838485868788898A8B8C8D8E8F'             @SC88215
         DC    X'909192939495969798999A9B9C9D9E9F'             @SC88215
         DC    X'A0A1A2A3A4A5A6A7A8A9AAABACADAEAF'             @SC88215
         DC    X'B0B1B2B3B4B5B6B7B8B9BABBBCBDBEBF'             @SC88215
         DC    X'C0C1C2C3C4C5C6C7C8C9CACBCCCDCECF'             @SC88215
         DC    X'D0D1D2D3D4D5D6D7D8D9DADBDCDDDEDF'             @SC88215
         DC    X'E0E1E2E3E4E5E6E7E8E9EAEBECEDEEEF'             @SC88215
         DC    X'F0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF'             @SC88215
         DC    X'808182838485868788898A8B8C8D8E8F'             @SC88215
         DC    X'909192939495969798999A9B9C9D9E9F'             @SC88215
         DC    X'A0A1A2A3A4A5A6A7A8A9AAABACADAEAF'             @SC88215
         DC    X'B0B1B2B3B4B5B6B7B8B9BABBBCBDBEBF'             @SC88215
         DC    X'C0C1C2C3C4C5C6C7C8C9CACBCCCDCECF'             @SC88215
         DC    X'D0D1D2D3D4D5D6D7D8D9DADBDCDDDEDF'             @SC88215
         DC    X'E0E1E2E3E4E5E6E7E8E9EAEBECEDEEEF'             @SC88215
         DC    X'F0F1F2F3F4F5F6F7F8F9FAFBFCFDFEFF'             @SC88215
]

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

Date: Fri, 29 Jul 88 22:40:53 EDT
From: [e-mail]
Subject: Kermit Through Protocol Converters Under CMS
Keywords: Kermit-370, Protocol Converters

Kermit-370, as released for CMS last winter, contained code designed to allow
file transfer through a variety of terminal emulators other than the "usual"
Yale ASCII type (Series/1, 7171, 4994, 9370 ASCII subsystem).  The code was,
in fact, modelled after similar code that was demonstrated under TSO, but I
haven't heard any reports of success under CMS, and the only negative report
was for a device that hadn't been tried under TSO.  I would like to hear from
anyone who has any kind of 3270 emulator other than the Yale type (and other
than the 3708, which is known to work with Kermit already).  The particular
types of emulators which might be expected to work include the MICOM 7400,
the Datastream/Leedata 8010/8030/874 models, the PCI 1076 and 276, and
possibly the Renex TMS-1.  Any others which claim to support a "graphics
passthrough" mode are also likely candidates.  I would be interested in any
results of trying Kermit with such emulators, whether positive or negative
(be sure to SET CONTROLLER GRAPH to the mainframe Kermit before starting the
transfer).  Actually, I now have an update that automatically detects
non-SERIES1-type terminals and also some other updates that may help in
diagnosing the problems if the existing code should prove not to work "as
is."

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

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


-------

 1-Sep-88 17:44:24-GMT,28049;000000000001
Received: from CU20B.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA08292; Thu, 1 Sep 88 13:44:10 EDT
Date: Thu 1 Sep 88 13:07:26-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V8 #7
To: [e-mail]
Reply-To: [e-mail]
Queries-To: Info-Kermit-Request@CUNIXC
Message-Id: <[e-mail]>

Info-Kermit Digest         Thu, 1 Sep 1988       Volume 8 : Number 7

Special C-Kermit Issue:
                        C-Kermit on the Amiga
                     C-Kermit 4E(070) on Masscomp
                   Lock Files Being Ignored by UUCP
                         C-Kermit and .kermrc
                     Using Kermit from Shell Mode
             C-Kermit on an X-MP Running UNICOS Version 3
                    Performance of Unix Kermit 4E
                 A Piped Connect Command for C-Kermit
                      SCO Xenix Makefile Error?
                    Xenix C-Kermit Makefile Fixes
                Parameters for Using Kermit over X.25?
                     Problem with C-Kermit on VMS
                        Fixes for VMS C-Kermit
             C-Kermit 4E(070) Under VAX/VMS Using Parity

Send digest submissions to Info-Kermit@CUNIXC, requests for addition to or
deletion from the Info-Kermit subscriber list to Info-Kermit-Request@CUNIXC.

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host CUNIXC, CUNIXC.CC.COLUMBIA.EDU, a
VAX 8700 running UNIX (Ultrix).  The IP host number is 128.59.40.130.  You
should be able to to FTP to CUNIXC, login as user ANONYMOUS (any password)
and GET the desired files.  The Kermit files are in directories kermit/a,
kermit/b, kermit/c, kermit/d, and kermit/e.  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 k1/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: Sat, 13 Aug 1988 17:31:22 EDT
From: Frank da Cruz <[e-mail]>
Subject: C-Kermit
Keywords: C-Kermit

In honor of the first anniversary of the release of C-Kermit 4E, this is a
special edition of the Info-Kermit digest devoted to C-Kermit.  Some of the
messages are quite old (but still valid) -- apologies for taking so long to
get around to them!

C-Kermit needs a lot of work.  Besides the obvious improvements that
everyone wants -- sliding windows, a rational script language, etc -- a
massive internal reorganization is necessary.  As some of you may recall,
the program originally ran on a VAX with 4.2BSD UNIX.  Then some conditional
compilation code was added to make it work with ATT System III and V.  Then
more conditional code was added for Venix, Xenix, etc etc etc, and then many
non-UNIX systems like Apollo Aegis, Data General AOS/VS, VAX/VMS, the
Commodore Amiga, the Apple Macintosh, etc etc etc.  As a result, the program
is a big mess, and the slightest change for one system seems to break it for
all the other systems.

The original of breaking the program up into modules that reflected
different kinds of dependencies was a good one, but the lines of demarcation
need to be rethunk.  Only the most basic, primitive, and atomic functions
should go into the system-dependent files.  How this can best be
accomplished is still open to question.  For example, the UNIX-specific
terminal i/o functions file, ckutio.c, is a joke that can only become worse
with the appearance of new UNIX "standards": X/OPEN and Posix are just two
more UNIX environments to add to the list -- they don't make all the others
go away!  Then we have all the "hybrid" systems like Xenix, Ultrix, and
SUNOS whose characters change with every release (is it Sys V? is it BSD?
no, it's both!).

My favorite feature of Unix programming is the way everything is done by
files -- including header files in your program source, making files
with magic names appear and disappear to signal other programs what's going
on, etc etc.  Back in the old days, where there was just one "UNIX", all of
this was fine.  But now, with so many UNIXes to choose from, and so many
releases of each one, we find that the major way in which things change is
where these files are stored and what they are called.  Sometimes it seems
to me that most of the hair in Unix Kermit involves figuring out where
"file.h" is on each release of each version of UNIX, and the rest of it is
devoted to coping with UUCP lock files (where is it? what's it called?
what's its mode?)...

I can't offer any good estimate about when the next release of C-Kermit will
be ready -- "real job" and all that...  But I'm faithfully collecting all
the bug reports, fixes, and suggestions in hopes that a chunk of time will
appear some day.  The file is about 2 feet thick so far.  A sampling appears
below.

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

Date: Tue, 15 Mar 88 17:33:10 PST
From: [e-mail]  (Stephen Walton)
Subject: C-Kermit on the Amiga
Keywords: Amiga, Commodore Amiga, C-Kermit/Amiga

I have a working version of C Kermit 4E(070) on my Amiga using Manx Aztec
C Version 3.6a (latest one).  The diffs from the old version are minimal,
but I did put in the parity stuff.  It seems to work fine, though I've
not tested it 100%--I can't get a completely transparent 8-bit link to
a computer here, and transfers with even and mark parity time out, but
ones with odd or space or no parity go just fine.  I have not tried to
compile it with any version of Lattice C.

I also ran Amiga Lint over it;  this Lint is very picky, but did find
a few things worth mentioning in the main sources:

(1) In ckcmai.c, there are two printf() calls where the number of
    items to print doesn't match the number of formatting codes.
(2) Several items, such as ttname[], are declared as CHAR in some places
    and as char in others.  Since the former is typedef'd to "unsigned
    char" for most systems, there are potential problems here.
(3) The extern item speed will have to be a long if C Kermit is to
    be ported to systems where int=16 bits.  It is an int right now.
    This failing requires compiling Amiga Kermit with int set to 32
    bits, which increases the executable size by 1/3 (from 63 to 85K).

If you're interested in the files, let me know and I'll email context
diffs and a BOO file.

Stephen Walton, formerly of Ametek but now at Cal State Northridge
[e-mail] (preferred) or [e-mail]

[Ed. - Thanks, Steve!  For now, the updated Amiga Kermit is in a "shell
archive" as CKIKER.UPD (it's been there since April)!  Your comments 1-3 are
noted and will be filtered in to the next release.]

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

Date: Wed, 2 Mar 88 02:58:11 CST
From: Stan Barber <[e-mail]>
Subject: C-KERMIT 4E(070) on Masscomp
Keywords: C-Kermit 4E, Masscomp, RTU, BSD 2.10

The latest release of C-KERMIT will run on the MASSCOMP MC5XXX computers
(lockfile problems excluded!) with the application of the following diff to
the makefile (ckuker.mak).

I have also checked the most recent version of kermit out on BSD2.10 and here
are the recommended changes. (version is C-Kermit, 4E(070) 29 Jan 88)

[Ed. - Diffs omitted, but added to CKUKER.BWR.  Thanks, Stan!]

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

Date: 8 Mar 88 14:56:06 EST (Tue)
From: mancol![e-mail] (John Hanley)
Subject: Lock Files Being Ignored by UUCP
Keywords: Lock Files, UUCP Lock Files, C-Kermit

We had a problem with the lock file that kermit creates not being publicly
readable, so that uucico's started by uucp couldn't read the lock file and
therefore didn't think the port was locked.  It turns out that
creat(lockfile,0444) on our 3b2/400 (SVR3) does NOT create a -r--r--r--
file, but rather -r--------.  One workaround we used for a while was to
invoke kermit using a script that sets umask to 0, runs kermit, and then
restores umask.  Eventually I patched ttlock() right after the creat() --
context diffs enclosed below.  I have no idea how widespread this problem is
(or if it even exists beyond our own system).

   --John Hanley
     System Programmer, Manhattan College
     soon to be a former E.E./CS undergrad (got a job for me? :)
     ..!cmcl2.nyu.edu!manhat!jh

[Ed. - This problem is not specific to Sys V.  The mode (protection)
specified in the creat() call is combined by UNIX with the user's "umask".
Therefore, any user who does not like to create files that are publicly
readable will also create UUCP lockfiles that are not publicly readable.
Solution: after creating the lock file, change the mode:

    lck_fil = creat(flfnam, 0444); <-- should really be 0644, right?
    if (lck_fil < 0) return(-1);
    fchmod(lck_fil, 0644);         <-- new

Actually, this will only work if the lockfile didn't exist already.  If it
did, then the mode won't change.  This is a feature of UNIX.  Anybody have a
better idea?]

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

Date: Thu, 17 Mar 88 18:00:08 +0200
From: Ze'ev (Steed) Shtadler <[e-mail]>
Subject: C-Kermit and .kermrc
Keywords: C-Kermit 4E(070)

I use C-kermit 4E(070) on 4.3BSD Unix.

I tried to use a .kermrc init file in one of my subdirectories to override
some setting done by $HOME/.kermrc but it didn't work.  It seems that kermit
doesn't look for .kermrc in the working directory if it finds $HOME/.kermrc.
This is also said in the manual, but I didn't see it even after looking
several times.

I would like to ask and suggest that an attempt to "take" .kermrc in the
working directory will be done even if $HOME/.kermrc was found.  This will
simplify things for me (and hopefully for others) and will be in line with
other programs like vi.  The obvious fix attempt: put "take .kermrc" in
$HOME/.kermrc will cause an infinite loop when kermit is called from the
home directory.

                                        Ze'ev.
Ze'ev Shtadler.
Computer Science Faculty,
Technion, Israel Institute of Thechnology,
Haifa Israel
Phone (work):   ([phone]

BITNET:  steed@techunix
Domain:  [e-mail]
UUCP:    ...!psuvax1!techunix.bitnet!steed
ARPANET: [e-mail]
CSNET:   [e-mail]

[Ed. - This is an interesting idea.  But it could produce some unwanted side
effects.  Anybody who cd'd to somebody else's directory would automatically
and unavoidably be affected by that person's .kermrc.  Better to leave
things as they are, and use explicity 'take' or 'set' commands to override
your $HOME/.kermrc environment.]

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

Date: 21 Mar 88 21:12:04 GMT
From: [e-mail] (Jeff Norden)
Subject: Using Kermit from Shell Mode
Keywords: GNU EMACS, Shell, C-Kermit

I'm not sure, but I think somebody asked about running kermit under shell
mode a while ago.  Anyway, here is some code that I find useful.  The result
is that I can log onto machines with primitive operating systems (VMS and
ATT system V :-), and still have the features of shell-mode available for
command history, etc.  It's also handy to be able to run a file transfer in
an emacs window.  The transfer is in the "background", but you can also
monitor or stop it easily.

[Ed. - Thanks for the idea, Jeff.  The entire text of this long message,
including the GNU EMACS code, have been put with the C-Kermit files, as
KER:CKUGNU.MSG.]

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

Date: Tue, 7 Jun 88 12:01:20 mdt
From: Jim Ivey <isew01![e-mail]>
Subject: C-Kermit on an X-MP Running UNICOS Version 3
Keywords: C-Kermit, Cray X-MP, UNICOS

I have been attempting to bring up C-Kermit on our local X-MP running UNICOS
Version 3.  Unfortunately, it is neither System V nor BSD4.2, but rather a
combination to purportedly "bring you the best of both worlds."  It is
closest to System V, and when I compile it using "make sys5", it compiles
fine, producing "wermit."  However when I try transferring files there are
numerous Timeout errors, and the transfer rate is usually about 10-30 baud.
Yes, 10 baud.  Now obviously this isn't because of the slowness of the
machine.  So far I haven't been able to find the answer, though I did make a
change in the routine msleep (m).  In it, there was a constant called
CLOCK_TICK.  Normally for UXIII, it is set for 17 milliseconds per clock
tick.  However, on the Cray X-MP there are 8.5 nanoseconds per clock tick.
Therefore this conversion comes out to "#define CLOCK_TICK .0000085".  Now,
when I extracted the msleep code from the program and tested it out, this
modification worked and the old code didn't.  Unfortunately, this didn't
solve the problem and I'm still on square one.

Do you know if anyone has already tried to do this?  If you could give me
some help on this I would appreciate it greatly.  Also, any help would
probably have to have some explanation, because I am very new to Kermit,
though I know UNIX and UNICOS well.

As a side note, is there any way to change the packet size to something
above 94?  We have all 9600 lines, and with the I/O speed of the Cray, it
seems like (after we get the program working in the first place) we could
get more performance out of the larger packets.

Anyways, thanks ahead of time for any help you can give me.  I plan on
coming in late tonight to uucp the latest version of C-Kermit in the hopes
that that will help a little.

Jim Ivey                         UUCP: ...!ucbvax!ucdavis!egg-id!miv
Idaho National Engineering Lab.  INTERNET: [e-mail]
POB 1625 M.S. 2603               Phone: [phone]
Idaho Falls, Id. 83415           FAX:

[Ed. - I hope the latest version helped.  It solves the second problem you
mention because it can handle packets up to 1K long (or as long as you want
if you change the symbols MAXSP and MAXRP, defined in ckuker.h.)]

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

Date: Mon, 11 Jul 88 12:57:07 CDT
From: rutgers!cs.utexas.edu!execu![e-mail] (Keith Pyle)
Subject: Performance of Unix Kermit 4E
Keywords: C-Kermit 4E(070) Performance

I have recently attempted to upgrade Kermit from version 4D to 4E on a Prime
EXL 316 (80386) running System V Release 3 Version 2.1.  While I encountered
no difficulities in building 4E, I noticed an obvious difference in
performance as compared to 4D.  Building Kermit without DEBUG and TLOG made
no difference.  For a file of 67429 bytes, the following times (sec.) and
effective baud rates were noted:

                                time        rate
Kermit 4D with DEBUG and TLOG    119        5660
Kermit 4E with DEBUG and TLOG    268        2516
Kermit 4E without DEBUG and TLOG 268        2516

The EXL had no other users during these tests and was communicating with
an IBM PC XT running MS Kermit 2.31 over a direct 9600 baud line using
8 bits, no parity.  I subsequently rebuilt both 4D and 4E with profiling
enabled.  Following is an extract of the prof(1) output for each using
the same test file as above:

Kermit 4D:
 %Time Seconds Cumsecs  #Calls   msec/call  Name
  46.4    7.28    7.28    1040      7.000   read
   7.7    1.22    8.50   72827      0.0167  encode
   6.7    1.05    9.55     834      1.26    write
   6.1    0.95   10.50   69179      0.0137  getchx
   5.0    0.79   11.28   67430      0.0117  zchin
   4.3    0.68   11.96     799      0.85    getpkt
   3.2    0.51   12.47   67432      0.0076  chkfn
   3.2    0.51   12.98                      _mcount
   2.9    0.46   13.44     801      0.57    spack
   2.2    0.34   13.78   77202      0.0044  dopar
   1.6    0.26   14.04                      getuid
   1.6    0.25   14.29    1602      0.156   chk2
   1.3    0.21   14.50     827      0.25    ioctl
   1.1    0.18   14.67                      monitor
   1.0    0.16   14.83                      sighold

Kermit 4E:
 %Time Seconds Cumsecs  #Calls   msec/call  Name
  46.6    6.62    6.62     837      7.91    write
  42.8    6.08   12.70     884      6.88    read
   3.8    0.54   13.24    1602      0.337   chk2
   0.9    0.13   13.37     801      0.16    spack
   0.6    0.09   13.46    1613      0.056   strlen
   0.6    0.09   13.55   77206      0.0012  dopar
   0.6    0.08   13.63                      _mcount
   0.6    0.08   13.71                      sighold

Note that write calls consume more than 5 times as much of the profiled
time in version 4E.  Has any similar behaviour been noted on other versions
of Kermit? (I have tested 4D vs. 4E on a Sun and found no appreciable
difference.)  Any suggestions on what changes leading to 4E might be
responsible?

Keith Pyle          ...!tut.cis.ohio-state.edu!cs.utexas.edu!execu!keith

[Ed. - This is a very interesting report.  Both these C-Kermit versions were
developed on a VAX (with Ultrix and BSD), and also tested on some other
systems (ATT 3B20, PDP-11, etc).  One of the major goals for 4E was improved
performance.  Benchmarks showed a slight improvement when sending files
(about 10%), a large improvement when receiving (something like 40%), and a
dramatic improvement when receiving with parity (greater than 400%) -- but
this is on BSD-type systems, where the fundamental method used for packet
input was changed (the method used in ATT-type systems was not significantly
changed, but some improvements were attempted).  Little work was done on
packet output (write) from 4D to 4E, so it's hard to know how to explain the
observed behavior.  Has anyone observed a similar performance degradation on
other System-V based systems?  If so, then the System-V specific code must
be at fault; otherwise, it's something to do with the particular machine,
OS, or compiler.]

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

Date: Mon, 13 Jun 88 15:04:34 PDT
From: Marco Franzen <[e-mail]>
Subject: A Piped Connect Command for C-Kermit
Keywords: C-Kermit 4E(070)

   Date: Mon, 6 Jun 88 15:04:34 PDT
   From: [e-mail] (Farhad Arbab)
   Subject: Proposal for a New Command

   What I need is a new command, say "pipe", which works just as connect,
   but instead of connecting the line to /dev/tty, it connects the line to
   the standard input and output of a given process: "pipe L" will then do
   what I want.  When L terminates, I want to return to the command mode
   of kermit.  L can be an arbitrary program (anything that can be
   executed via the ! escape).

I have implemented exactly this command a couple of months ago, I named it
"|".  It used some code of the connect command and some of the "!" escape.
We use it to transfer files with the Zmodem protocol via the sz/rz program.
That protocol is more efficient on low-noise lines if either side's Kermit
cannot handle extended-length packets.

   How easy or difficult is it to add this feature to kermit?  Do you know
   of other easy ways to accomplish the same effect?  Is there another
   communications program that provides such a feature?

To simply add this command to the Unix version of C-Kermit was not a big
task.  Most of all is error-handling ("You have to set line/speed first"
messages,...).  For other OSes I can't say.

The only problem on my Version of Unix is with the line-locking ioctl: After
calling the new "|" command, the hard lock vanishes.  But this malfunction
doesn't hurt me, since the uucp-style (/usr/spool/uucp/LCK..line) locking
still works.

The reason for this misbehavior is that the dup2() (and also the dup() and
fcntl(F_DUPFD)) system call releases the lock.  Neither [v]fork() nor
execlp() act this way. However, I don't know, whether this is an error of my
Operating System.

Marco Franzen            | Phone:  [phone]
Inst. f. Betriebssysteme | Fax:    [phone]
    und Rechnerverbund   | BITNET: [e-mail]  (preferred)
TU Braunschweig          | UUCP:   [e-mail] (uunet!infbs!franzen)
D-3300 Braunschweig      | from CSnet:  [e-mail]
Fed. Rep. of Germany     | from ARPA:   [e-mail]

[Ed. - This idea will be looked at for the next release.  It could be used
to build a very generalized script facility to be used with C-Kermit, but
from the outside.]

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

Date: Tue Mar 15 20:51:01 1988
From: yunexus!ists![e-mail] (Mike Clarkson)
Subject: SCO Xenix Makefile Error?
Keywords: SCO Xenix

For Ckermit 4E(070) 29 Jan 88, in the Makefile

    # CKUKER.MAK, Version 2.11, 29 January 1988
    #
    # -- Makefile to build C-Kermit for Unix and Unix-like systems --
    ...
    #SCO Xenix/286 2.2.1, e.g. for IBM PC/AT, PS/2 Model 50, etc.
    sco286:
    make wermit "CFLAGS= -DXENIX -DUXIII -DDEBUG -DTLOG -F 3000 -i -M2le" \
        "LNKFLAGS = -F 3000 -i -M2le"

looks OK, but

    #SCO Xenix 2.2.1 for IBM PC, XT, PS2/30, or other 8088 or 8086 machine
    sco86:
    make wermit "CFLAGS= -DXENIX -DUXIII -DDEBUG -DTLOG -F 3000 -i -Mle" \
        "LNKFLAGS = -F 3000 -i -Mle"

looks suspicious:

    1) SCO Xenix doesn't have 2.2.1 for the 8086.  Their latest (and last?)
release for the 8086 is 2.1.3.

    2) SCO Xenix doesn't have large model (-Ml) for the 8086.


Has this makefile actually been tested?  Last time I tried, it wouldn't work
medium model.

Mike Clarkson                        [e-mail]
Institute for Space and Terrestrial Science
York University, North York, Ontario,
CANADA M3J 1P3                        [phone]

[Ed. - Hasn't been tested at Columbia.  We don't have any Xenix systems
handy to test things on.  It was sent in by somebody.  See below for a
different version that was sent in by somebody else.]

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

Date: 15 Jul 88 17:43:17 EDT (Fri)
From: uunet!jetson![e-mail] (John Owens)
Subject: Xenix C-Kermit Makefile Fixes
Keywords: SCO Xenix

There are some changes to the makefile I made for Xenix.  I added support
for 386 Xenix, and changed the model for 86 xenix from large to medium.
(Large model doesn't run on the 8086 Xenixes.)

# CKUKER.MAK, Version 2.11, 29 January 1988
 . . .
# for SCO Xenix/286 2.2.1 with development system 2.2 on 80286, "make sco286"
# for SCO Xenix/86  2.2.1 with development system 2.2 on 8086/8 "make sco86"
# for SCO Xenix/386 2.2.2 with development system 2.2 on 80386, "make sco386"
 . . .
#SCO Xenix/286 2.2.1, e.g. for IBM PC/AT, PS/2 Model 50, etc.
sco286:
    make wermit "CFLAGS= -DXENIX -DUXIII -DDEBUG -DTLOG -F 3000 -i -M2le" \
        "LNKFLAGS = -F 3000 -i -M2le"

#SCO Xenix 2.2.1 for IBM PC, XT, PS2/30, or other 8088 or 8086 machine
sco86:
    make wermit "CFLAGS= -DXENIX -DUXIII -DDEBUG -DTLOG -F 3000 -i -M0me" \
        "LNKFLAGS = -F 3000 -i -M0me"

#SCO Xenix/386 2.2.2
sco386:
    make wermit "CFLAGS= -DXENIX -DUXIII -DDEBUG -DTLOG -Otcl -i -M3e" \
        "LNKFLAGS = -i"
 . . .

I also changed cku[ft]io.c to print Xenix/86, Xenix/286, or Xenix/386,
instead of always printing Xenix/286:

[Ed. - Diffs omitted, but added to the CKUKER.BWR file.  Thanks!]

John Owens        SMART HOUSE Limited Partnership
[e-mail]    (old uucp) uunet!jetson!john
[phone]        (internet) [e-mail]

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

Date: 16 Jun 88 18:43:23 GMT
From: unido!IAO.FhG![e-mail] (News user)
Subject: Parameters for Using Kermit over X.25?
Keywords: X.25, C-Kermit

I would like to transfer files from a VAX running VAX-Kermit (Don't know
which version) to a UNIX-VAX running C-Kermit.  I connect to the VMS Machine
via our external PAD and get into the VMS-Machine via their X.25 Interface
(PSI). For normal operation, that works like it should, but when I want to
copy files from the VMS to UNIX, nothing works. The Kermit on the UNIX side
prints some of its messages (nothing understandable) and exits because he
couldn't speak to the other machine (timeout).  Can someone give me please
some clues which parameters (Kermit and X.25) to tweak how.

Thanks in advance.

Dieter Woerz
Fraunhofer Institut fuer Arbeitswirtschaft und Organisation
Abt. 453
Holzgartenstrasse 17
D-7000 Stuttgart 1
W-Germany

BITNET: iaoobel.uucp![e-mail]
UUCP:   ...{uunet!unido, pyramid}!iaoobel!woerz

[Ed. - Beyond our stock answer of "set parity even" (or mark, or odd, or
space) to the Kermits on each end, there's not much else to say.  It is very
likely that VMS Kermit (any version -- Kermit-32 or C-Kermit/VMS) must have
explicit VAX-PSI support written into it in order to work over a direct X.25
connection (as opposed to an X.3/X.28 connection through a serial port).  In
fact, there seems to be a big demand for this in Europe.  Can anyone shed
more light?]

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

Date: Tue, 8 Mar 88 00:13:01 est
From: Brendan Reilly <[e-mail]>
Site: Woods Hole Oceanographic Institution, Woods Hole Mass.
Subject: Problem with C-Kermit on VMS
Keywords: C-Kermit/VMS, VAX/VMS

After compiling KERMIT with the latest CC from Digital it appears that both
KERMIT and VMS/CC have a procedure named system.  I've changed the KERMIT
reference to vms_system, but I'm still having a problem with server mode.
When talking to the VMS side in server mode from a PC running the latest
KERMIT and I issue a REMOTE CWD [reilly.a] I'm asked for a password, to
which I reply with a return and then see some garbage characters typed on
the screen.  If I then do a REMOTE DIR it's a surprise to find that I'm
still in the original directory - not [REILLY.A] Has anyone else seen this?

[Ed. - There's definitely some kind of bug in VMS C-Kermit in this area.
When I try this, the VMS C-Kermit server goes into an infinite unstoppable
loop printing messages issued by its "ttinl()" function: "SYS$QIOW:
%SYSTEM-F-EXQUOTA, exceeded quota", and "%NONAME-W-NOMSG, Message number 0".
Another one for the bug list.]

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

Date: Tue, 19 Jul 88 13:54 CDT
From: <[e-mail]> (BARRY ARCHER)
Subject: Fixes for VMS C-Kermit
Keywords: C-Kermit/VMS, VAX/VMS

In working with the VMS version of C-Kermit, I became frustrated with the
problems with hanging subprocesses after exiting the image, as well as the
problems I was having running C-Kermit while connected to a DECserver ( LAT
protocol ).  I finally figured out how to fix those problems and installed
the new version.

[Ed. - The remainder of this (long) message, plus the new ckv*.c files, have
been added to CKVKER.BWR for now.  Hopefully the various people working on
C-Kermit for VMS will be able to reconcile their changes and improvements.
Thanks, Barry!]

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

Date: Wed, 08 Jun 88 10:04:12 EST
From: [e-mail]
Subject: C-Kermit 4E(070) Under VAX/VMS Using Parity
Keywords: C-Kermit/VMS, VAX/VMS

I compiled C-Kermit 4E(070) under VAX/VMS, using version 1.0(013) of the VMS
tty I/O module, CKVTIO.C.  The fixes present to make it work properly when
parity is being used didn't work properly because ttprty was never set in
CKVTIO.C.

Here's a partial fix: [Ed. - Omitted, but added to KER:CKVKER.BWR.]

This doesn't fix things completely since the call to SYS$QIOW in ttinl()
waiting for an end-of-line character waits for an end-of-line character with
high bit 0, but if (say) end-of-line is 13 and parity is even it should
really be waiting for a character with high bit set (X'8D').  However you
can work around this by choosing the end-of-line character so that it is
sent with high bit reset (e.g., eol=15 for even parity).

Another problem is that data overrun errors occur periodically during file
transfer and (at times) during terminal emulation.  Kermit will also
sometimes lock up completely during terminal emulation.  I do not know what
is causing this.  We are running on a MicroVax II with BYTLM=20480.

David Moews                 [e-mail]

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

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

13-Sep-88 23:02:07-GMT,23463;000000000001
Received: from CU20B.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA20841; Tue, 13 Sep 88 19:01:53 EDT
Date: Tue 13 Sep 88 16:55:26-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V8 #8
To: [e-mail]
Reply-To: [e-mail]
Queries-To: Info-Kermit-Request@CUNIXC
Message-Id: <[e-mail]>

Info-Kermit Digest         Tue, 13 Sep 1988       Volume 8 : Number 8

Departments:

  ANNOUNCEMENTS -
        Submission of new version of Kermit-UCSD  (UCPECAN)

  MS-DOS KERMIT -
        MS-Kermit 2.31 Quirks
        Re: MS-Kermit v2.31 Eats Nulls
        MS-Kermit and the Novell File Server
        Re: MS-Kermit 2.31 Tabs Bug (Feature?)
        MS-Kermit: Five Bugs and a Whinge
        Goto Label Bug in 2.31 August 15?
        Problems with MS-Kermit 2.31 Graphics
        MS Kermit 2.31 File Dates

  MISCELLANY -
        Kermit Through Protocol Converters Under CMS

Send digest submissions to Info-Kermit@CUNIXC, requests for addition to or
deletion from the Info-Kermit subscriber list to Info-Kermit-Request@CUNIXC.

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host CUNIXC, CUNIXC.CC.COLUMBIA.EDU, a
VAX 8700 running UNIX (Ultrix).  The IP host number is 128.59.40.130.  You
should be able to to FTP to CUNIXC, login as user ANONYMOUS (any password)
and GET the desired files.  The Kermit files are in directories kermit/a,
kermit/b, kermit/c, kermit/d, and kermit/e.  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 k1/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: Sat Aug 20 08:10:52 1988
From: portal!cup.portal.com![e-mail]
Subject: Submission of new version of Kermit-UCSD  (UCPECAN)
Keywords: UCSD Pascal Kermit, p-System, Pecan

I am submiting my version of Kermit-UCSD (Version 1.0, 17 Aug 88), currently
running on the Atari MEGA ST2 with the Pecan Software Systems Inc p-System,
and adaptable to Version IV p-Systems on other machines.

You should recieve 2 files: 1) a large (about 3300 lines) one containing the
source (UCPECA.PAS) and a smaller (about 300 lines) one containing the
documentation (UCPECA.DOC).

This version does not have everything I was planning on implementing and has
a few known bugs (listed in the .DOC file), but it does work (and is MUCH
better than any of the other versions of Kermit-UCSD I could find currently
in Kermit Distribution).

I hope to be able to provide an upgrade on this within about 6 months to one
Year.

I also hope to be able to send an encoded KERMIT.CODE file and a decoding
program, containing the entire program and implementation parts of the Pecan
Library Units, for people with Version IV p-Systems that can't afford or
don't need to purchase Pecan's Library.  They will still have to go to USUS
to get a REMUNIT for their system though.  The Pecan Licence permits this for
"non-commercial purposes" (but I am still checking with them to make sure
that they are satisified with my attachment of their copyright notice, so
there will be no problems).
                                        R. Tim Coslet

Usenet: [e-mail]
BIX:    r.tim_coslet

[Ed. - Many thanks, R. Tim!  Those who are interested in bringing up this
program on other UCSD p-Systems besides the Atari are encouraged to do so,
and report back the results.  The .DOC file tells how to reach Pecan and
USUS.  The files are in kermit/c/ucpeca.* on CUNIXC, and in KER:UCPECA.* on
CU20B, and also available as UCPECA * from KERMSRV at CUVMA, and also can be
ordered on Kermit Tape C from Columbia.]

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

Date: Wed, 17 Aug 88 10:30 EDT
From: <[e-mail]>
Subject: MS-Kermit 2.31 Quirks
Keywords: MS-DOS Kermit 2.31

Thanks, Joe, Kermit 2.31 is wonderful.  I have noticed some minor problems
with 2.31 though.  First the set up:

  IBM-PS/2 Model 30, DOS 3.3, DEVICE=ANSI.SYS, FILES=20, BUFFERS=20
  Kermit 2.31

We have an IBM 3081 that we connect to via a 7171.  Our script file takes us
to the opening screen and leave us there.  The last 2 lines of our script
file are:

  TAKE IBM.INI    ; Our keybindings file
  CONNECT

The first problem has to do with connect.  After a script executes and it
does a connect it starts with a clear screen.  Apparently any data arriving
while we are defining keys is being stored somewhere besides the screen
buffer.  When it connects we get a clear screen.  To circumvent this
problem, the script file was changed to read:

  TAKE IBM.INI    ; Our keybindings file
  OUTPUT \7       ; ^G causes the 7171 to repaint the screen and make sure
                  ; that the keypad is in application mode.
  CONNECT

In 2.30 this did not seem like a problem.

The second problem is really just an annoyance.  If you have set your screen to
a non-white on black and you get into kermit and take a script file, sometime
between the last input/output command and connect command the screen flickers
white on black and then after the connect command it is ok.  (Probably the
output \7 causes the 7171 to send an escape sequence to Kermit and it
reinstates the colors.  Up to this point, all local kermit i/o was in the
non-white color.  Upon exit of the script (ALT-X from connect) the local
kermit i/o is in white and any subsequent scripts/connects etc. are in white.
Sometimes if I immeditaly execute another script file the connect mode is in
non-white, but sometimes it isn't.  Regardless, when I return to DOS, it is
back to white again.  Like I said, not a problem just annoying.  It may be
tied to the first problem.

The third problem is a bit more severe, but may not be a Kermit problem as
much as a PS/2 model 30 problem, however I have only noticed it in Kermit.
In the unlikely event that I have CTRL, SHIFT down and I press Left arrow and
mis-hit and probably hit several keys with my short stubby fingers, all of the
lights flash on the keyboard and it locks up.  I am thinking that it is a BIOS
problem since it happened last night when I was in Turbo Pascal, but it didn't
lock the keyboard.  I don't know what keys I hit to cause it, but my left hand
was in the vacinity of the LEFT shift, LEFT CTRL area and my right hand was in
the area of the editing keypad.

One other note and question.  I was trying to transfer some stuff between my
PS/2 and my AT&T PC6300 at 115600 baud.  The AT&T could not handle it.  The
machine rebooted once and another time the SERVER on the AT&T would not respond
and we had to reset it.  Slowing it down to the next lower baud rate worked
(56Kbps).  Could it be the wierd AT&T bios?  (By the by, the AT&T has the same
processor as the PS/2 8086 8Mhz)

Thanks,

Rob Miracle              | Bitnet   : RWMIRA01@ULKYVX    CIS: 74216,3134
Programmer/Analyst-II    | INTERNET : [e-mail]
University of Louisville | UUCP     : ...psuvax1!ulkyvx.bitnet!rwmira01
"Incompetence is not an excuse." -- Anton Devious

[From jrd - Quote above is removing my favorite cover!  Scripts and Connect:
These share a common buffer for the serial port but once a script command
draws from it the data are no longer available for Connect displays.  The
OUTPUT and PAUSE commands read from that buffer to helpfully echo material
from the host and they keep doing it until there is 10 milliseconds of no
new incoming characters (10 millisec was needed for some modem responses).
Otherwise, Connect mode and scripts are not related.

Screen coloring: If the host sent an escape sequence such as ESC [ number m
then ANSI.SYS, or equivalent, if installed will see and react to it.  There
is nothing Kermit can do about such DOS level activities.

Multiple keys on PS/2 Model 30s: I agree, it seems like a machine problem.

Superspeed and AT&T 6300's. I can't say much about that machine because one
was available to me for only one evening some time ago. Selected IBM PC clones
can run Kermit at 115KB, and I've never encountered a system corruption
problem with those which can't make that speed. I second the motion that the
Bios may be unusual.]

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

Date: Fri, 19 Aug 88 17:35 MDT
From: Pete Klammer 303/556-3915 <[e-mail]>
Subject: Re: MS-Kermit v2.31 Eats Nulls
Keywords: MS-DOS Kermit 2.31

May I second that emotion?  It may be a misuse of KERMIT, but that's the way
life with tools is.  Many's the time I wish to get a good log of exactly
what's spitting out some serial path, nulls and all.  I respectfully request
that NULL and RUBOUT filtering be selectable.

--poko

[From jrd - Alas, there is no happy middle ground since most people use logs
to record worth while text for later editing and printing but many editors
cannot cope with NULLs. Also, these characters are frequently used as padding
so passing them quickly fills the serial port holding buffer; the reaction to
that was annoyance about performance when it was done as an experiment. We
have the idea that they should be displayed when DEBUG is ON, but not logged;
However, most releases have removed NULLs completely anyway. I'd suggest that
you make the simple changes to the sources to pass all the characters of
interest; see file msxibm.asm.]

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

Date: Tue, 23 Aug 1988 16:27:47 LCL
From: David Boeshaa <[e-mail]>
Subject: MS-Kermit and the Novell File Server
Keywords: MS-DOS Kermit 2.31, Novell File Server

Greetings! and Grief!

I have been working with KERMIT 2.3x for some time and I think it is GREAT!
but I have a small problem with 2.31 15 Aug 1988.

We are running KERMIT from a Novell 2.0a file server and every download
gives the message "Not Enough Disk Space for File" but then downloads the
file anyway. I think this may be related to the new file size checking
(we have not EVER had this problem before and we are still running
2.31 17 July 1988 without grief).

Thanx and Thanx for a GREAT product!!!

   David K. Boeshaar    ACADEMIC COMPUTING SERVICES
              ______    SYRACUSE UNIVERSITY
             /      |         -------
            |       |   BITNET:    [e-mail]
  _________/        |   NOISENET:  [phone]
  |         *       |   SNAILNET:  215 Machinery Hall
 /      SYRACUSE    |              Syracuse, NY 13244-1260 USA
|______________     |
               |_   |  Disclaimer: Any sufficiently advanced technology
                 |__|              is indistinguishable from magic.

[From jrd - a known bug, fixed in the middle August update for IBM PCs.  There
is a similar problem if the file destination is the screen or printer; fixed
recently but not in time for the update above.  Sorry about that.]

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

Date: Mon, 15 Aug 88 21:05 EST
From: "Frank Rens" <[e-mail]>
Subject: Re: MS-Kermit 2.31 Tabs Bug (Feature?)
Keywords: MS-DOS Kermit 2.31, Tabs

I have the same problem with the TABS being cleared by a CLEAR.  Here's the
script...The tabs are OK before the clear but not after.

[Ed. - Script omitted.]

[From jrd - I finally found the bug: an uninitialized register at one place
which could (but never here!) clear the tab storage area when the CLEAR cmd
was issued. Fixed in the middle August maintence release for IBM PCs.]

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

Date: 24-AUG-1988 12:38
From: IN%"[e-mail]"
Subject: MS-Kermit: Five Bugs and a Whinge
Keywords: MS-DOS Kermit 2.31

Syskermit & Columbia:

    I have recently made extensive use of MSKERMIT (various releases)
running on an XT-Clone while developing a new Kermit for a UK (Research
Machines) Micro.  Obviously, I have been putting it through quite a lot of
hoops while testing my own code's reaction to error-situations and various
sequences of events.  I have encountered the following five problems, which
are guaranteed not to be caused by misrunning of my new RM Kermit.  They
have been identified while running at various speeds, on a short direct
"null-modem" wire connecting the two micros, with the MSKermit in normal
(not server or back-port) mode.  Parity has in all cases been set to Even.
The clone is running MSDOS 3.20.

    The different errors have different incidences in different releases
of MSKERMIT.  See table below.

1.  Unable to Resume Binary Mode.

    When first loaded, MSKermit will happily transfer files in binary
with 8th-bit quoting.  If a file is then transferred in 7-bit non-binary
mode, MSKermit will never revert to 8th-bit-quoting.  It simply sticks
an "N" into the spar/rpar packet, no matter what it has been sent or what
command you give it.  Main tests caried out while receiving, but I think
it is true in all circumstances.

[From jrd - I'm a little confused. MS Kermit lacks the concept of a 7-bit
non-binary mode transfer since there is no way within DOS to tag files as
binary or not. The conditions to use 8-bit quoting are the local side uses
parity plus the other side agrees on 8-bit quoting, or the other side requests
the quoting. However, I ran a series of tests and found that indeed Kermit
could remember an old 8-bit quoting state and then later respond with the 'N'
above (for No Can Do). Tracked down and fixed this past weekend. Thanks.]

2.  Not Displaying Early E-Message.

    If MSKermit is receiving and the other end sends an E-packet before
sending the F-packet, then this is not displayed in the "Last Error"
field.  The packet is received OK, and can be seen as "Rpack" if debug
is switched on.  (The error in question is, of course, "File not found";
this does not occur on most Kermits as they check for the presence of the
file before sending the S-packet.)

[From jrd - True, the packet type test had the code to do this but it was
not reached because an earlier test would fail to the file complete code
rather than the error handler code. Safe, but it omitted the error message.
Fixed now. Thanks.]

3.  DEL *. Doesn't Work.

    If the default disk has on it files which have no extension to their
names, then although they are correctly displayed in response to the command
"dir *.",  the command "del *." gives the response "?Protected or no such
file(s).".  "del a:*." gets the same response, but "del x*." works OK
(assuming there are files whose names start with "x").

[From jrd - That's a DOS characteristic since Kermit merely composes a DOS
command line with DEL followed by the user's filespec and submits the works
to COMMAND.COM.  MS Kermit 2.28 and predecessors used FCBs and did deletion
file by file within Kermit; starting with 2.29 all FCB material was removed
and COMMAND.COM was employed.  Compare results of these commands between
giving them within Kermit and then at the DOS prompt.]

4.  F3 Setting Gets Lost.

    When MSKermit is loaded and then cancelled by "Quit", if only Kermit
commands have been entered, then F3 causes MSDOS to repeat the command used
to load Kermit.  However, if a DOS-type command is given at the Kermit-MS>
prompt (e.g. dir or del), then, after quitting, F3 brings up a null command.

[From jrd - DOS again.  Kermit reads the keyboard at both DOS and Bios
levels.  When DOS does the work the DOS typeahead buffer can be flushed.
Kermit, and probably most programs, make no effort to restore the contents
of the typeahead buffer private to DOS. This is not a fault.]

5.  Hitting RTN Kills the System.

    This is caused by hitting RTN [Return, Enter] unneccessarily and
repeatedly during normal running.  Tests were done during a receive, but I
think it happens during send as well.  You have to hit RTN quite frequently,
and MSKermit sends a NAK each time you do.  Eventually an unpredictable loss
of status occurs.  In the table below "Clean" means that you get back to a
Kermit-MS> prompt, and can continue (except you will find that there is a
packet or part of one in the input buffer).  "Bad" means that, if you do get
back to a prompt, then you cannot continue, and when you quit you find MSDOS
won't work; or the display may go wild.  If the display goes wild, then the
keyboard is quite dead.  If you are able to quit, then the MSDOS disk-driver
has been overwritten in such a way that any attempt to use any disk gets the
"not ready error" response.  (The details of this may depend on the nature
of the Clone, since I have had the same trouble with a completely different
communications program on the same machine.)

[From jrd - that's not happened on any of my clones. I can hold down the
Enter key and let it auto-repeat with no ill effects except the packet
retry count goes the exhaustion limit. If a keyboard helper or an unusual
Bios does not preserve registers in a standard way (Kermit is reading keys
via DOS during packet transfers) then disaster can strike any program. DOS
stack overflow can also occur under some versions of MS DOS. Similarly,
'adjusting' DOS's typeahead buffer can lead to wild results when that buffer
overflows. The problem has not been reported by others.]

6.  Where's MSKERMIT.INI?

    This is really a whinge rather than a bug.  If MSKermit is not on the
default disk, i.e. you load it by a command such as "b:kermit", or get it
picked up by being in the PATH, then MSKERMIT.INI is not picked up even
though it is on the same disk as MSKermit has been loaded from.  This is
true of all versions; and for all I know it may be impossible in MSDOS to
find out what disk the program has been loaded from.

[From jrd - Kermit does not know from which disk or directory it has been
loaded.  The manual states that Kermit searches for MSKERMIT.INI, and Take
files, first in the CURRENT directory and then if necessary along the PATH=
string. DOS 2.X lacks the ability to inform a clever program about its
loading source.  Thus, if the current disk were say C: and Kermit were loaded
by C> b:kermit and then the search would not include drive B: unless it were
stated in the PATH= string.]

    Here is the incidence of bugs 1 - 5 in the different releases:-

\.
  \.  Bug:     Text/Bin     E-Message    DEL *.      RTNs       F3
    \.----     --------     ---------    -----       ----       --
      \.
Version \
 ------
2.26             No           OK          OK        Clean      Lost
(undated)

2.28             No           OK          OK        Clean      Lost
(undated)

2.29c            No           OK          No         Bad       Lost
(23 Aug 87)

2.30             No           OK          No         Bad       Lost
(8 Jan 88)

2.31             No           No          No         Bad       Lost
(1 July 88)


     I hope this is of some use to you.  The only one which seems to me to
be at all serious is the inability to revert to binary-quoting after running
in text-mode.

                                               Chris.

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

Date: Fri 26 Aug 88 16:39:07-PDT
From: Ted Shapin <[e-mail]>
Subject: Goto Label Bug in 2.31 August 15?
Keywords: MS-DOS Kermit 2.31, GOTO

I can't get this version of Kermit to recognize labels in loops?

This doesn't work:
set count 3
:TOP
echo Hello\13
if count goto top
echo Goodbye\13

Ted.

[Ed. - Yup, it's another bug in the label-finding code.  A quick workaround
is to append a space to the label, followed by a comment, as in

:TOP ; (of loop)

Thanks also to B. Schneuwly, Joellen Windsor (an early Kermit developer!),
and others who reported this problem.  Joellen also discovered the following
interesting workaround:

define %b loop
:loop
echo test
goto \%b

The problem should be fixed in the next release.]

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

Date: Wed, 31 Aug 88 14:38 GMT
From: <[e-mail]>
Subject: Problems with MS-Kermit 2.31 Graphics
Keywords: MS-DOS Kermit 2.31, Olivetti

We have problems with Kermit 2.31, dated 15 Aug.

[Ed. - Loop label report omitted, see above.]

Graphics is another problem:
On a Olivetti M24 we don't get the same high(er) resolution display
as with MS-Kermit 2.30.

[Ed. - If Kermit can't automatically recognize your screen's resolution, use
the SET TERMINAL GRAPHICS ATT command.  The next release should recognize
the Olivetti automatically.]

Furthermore I'd like to have the possibility to control whether the TEK4010
emulation does merge it's text with already existing pixels or does overwrite
as in 2.30.

[Ed. - Noted.]

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

Date: Wed, 31 Aug 88 12:17 MST
From: <[e-mail]>
Subject: MS Kermit 2.31 File Dates
Keywords: MS-DOS Kermit 2.31, Attributes, File Dates

I am running MSKERMIT 2.31 dated August 15, 1988, on a PS2 model 50 under
MS-DOS 3.30.  I have noticed the following 2 problems:

(1) [Ed. - Loop label problem report omitted, see above.]

(2) All files shipped to my PS2 from my VM/SP mainframe have the correct
creation date but they all have 12:00a for the creation time.  This appears
to have been a problem with the July 1 version, too.

[Ed. - This is because VM/CMS Kermit reports the creation date but not the
time of creation, so MS-Kermit uses midnight.]

Joellen Windsor
Systems Programmer

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

Date: Fri, 29 Jul 88 22:40:53 EDT
From: (John F. Chandler)   [e-mail]
Subject: Kermit Through Protocol Converters Under CMS
Keywords: Kermit-370, Protocol Converters

Kermit-370, as released for CMS last winter, contained code designed to
allow file transfer through a variety of terminal emulators other than the
"usual" Yale ASCII type (Series/1, 7171, 4994, 9370 ASCII subsystem).  The
code was, in fact, modelled after similar code that was demonstrated under
TSO, but I haven't heard any reports of success under CMS, and the only
negative report was for a device that hadn't been tried under TSO.  I would
like to hear from anyone who has any kind of 3270 emulator other than the
Yale type (and other than the 3708, which is known to work with Kermit
already).  The particular types of emulators which might be expected to work
include the MICOM 7400, the Datastream/Leedata 8010/8030/874 models, the PCI
1076 and 276, and possibly the Renex TMS-1.  Any others which claim to
support a "graphics passthrough" mode are also likely candidates.  I would
be interested in any results of trying Kermit with such emulators, whether
positive or negative (be sure to SET CONTROLLER GRAPH to the mainframe
Kermit before starting the transfer).  Actually, I now have an update that
automatically detects non-SERIES1-type terminals and also some other updates
that may help in diagnosing the problems if the existing code should prove
not to work "as is."

[Ed. - John has done an amazing job with Kermit-370, but need help from
people who have equipment that he doesn't have access to.  Any cooperation
will be much appreciated!  Meanwhile, John is preparing a large batch of
updates to Kermit-370 for release -- watch Info-Kermit for announcements.]

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

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

 2-Nov-88 17:05:14-GMT,33872;000000000001
Received: by cunixc.cc.columbia.edu (5.54/5.10) id AA05083; Wed, 2 Nov 88 11:43:07 EST
Date: Wed, 2 Nov 1988 11:43:05 EST
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V8 #9
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Thu, 13 Oct 1988       Volume 8 : Number 9

Today's Topics:

  ANNOUNCEMENTS -
        Announcing MS-DOS Kermit 2.31/A, Beta Test
        Announcing a Beta Test Kermit for MS-Windows
        Announcing EASYK, a Menu-Driven Shell for MS-DOS Kermit
        Announcing Hebrew Kermit, a Test Version for the IBM PC

  MS-DOS KERMIT -
        MSDOS Kermit Script Files Available from SIMTEL20
        Automatic Exit from MS-Kermit?
        Missing the Bell When Using MS-Kermit
        Kermit Across Ethernet
        MS-Kermit with StarLAN
        PC-KERMIT ReGIS Support
        IBM 3174 AEA Ports and Kermit?
        MSDOS BOO Maker/unBOO Bug
        Kermit SET KEY Command and String Capability
        Solution Found to Problem with <ESC>[?3l
        Problem Compiling MSSSET.ASM
        AT&T Graphics in MS-KERMIT 2.31
        OS/2 Kermit Won't Work
        Problem with OS/2 Kermit
        Re: Kermit-MS version 2.31
        MS-Kermit v2.31 Inquiries

Send digest submissions to [e-mail], requests for
addition to or deletion from the Info-Kermit subscriber list to
[e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host CUNIXC, CUNIXC.CC.COLUMBIA.EDU, a
VAX 8700 running UNIX (Ultrix).  The IP host number is 128.59.40.130.  You
should be able to to FTP to CUNIXC, login as user ANONYMOUS (any password)
and GET the desired files.  The Kermit files are in directories kermit/a,
kermit/b, kermit/c, kermit/d, and kermit/e.  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 k1/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, 2 Nov 1988 11:27:34 EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V8 #9 is Sent a Second Time
Keywords: Mailer Problems

Due to mailer problems and reports of the many sites who did not receive this
digest the first time, Info-Kermit Digest V8 #9 is being sent a second time
to all members on the distribution list.  Apologies to those who have already
received this issue.

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

Date: Sun, 2 Oct 88 14:58 MDT
From: <[e-mail]>
Subject: Announcing MS-DOS Kermit 2.31/A, Beta Test
Keywords: MS-DOS Kermit 2.31/A, IBM PC, DEC Rainbow, Rainbow, DECnet/DOS

This is to announce a beta test of a new maintenance release of MS-DOS
Kermit for the IBM PC and PS/2 families, and for the DEC Rainbow.  This
version is numbered 2.31/A.  It fixes a number of problems with 2.31, but
adds no major new functionality.

The most important fixes are in the following areas:

- Calculation of available disk space when receiving files with the size
  attribute.

- SET EOF {CTRL-Z | NOCTRL-Z} now applies also to the TRANSMIT command.

- Correct bug requiring spaces after formal labels and bug clearing VT102
  Connect mode tab stops when CLEAR command is issued.

- Correct long standing problem of local 8-bit quoting requirement not
  following current operating conditions.

- Add REMOTE LOGIN {username {password {account}}} command.

- Automatic identification of AT&T/Olivetti machines in Tektronix graphics
  mode for IBM-PC version of MS Kermit.

- Revise printing strategy within Connect mode to buffer 132 characters and
  to send XOFF/XON to the host while the buffer is written to DOS.  This helps
  prevent serial port overruns noted with slow PCs at high baud rates when the
  printer is attached to a network or similar.

In addition, it was verified that MS Kermit operates across DECnet using the
NetBios emulator supplied with DECnet-DOS 2.0 (aka PSCA).

These changes are in addition to the changes that were made between the July
initial release and the mid-August maintenance release, which included fixes
for the Ungermann-Bass Net/One support, the "stray interrupt" problem, and
a GOTO-label problem.

[Ed. - Thanks, Joe!  The new beta test release has been added to Kermit
Distribution as MSTIBM.BOO (IBM version) and MSTRB1.BOO (Rainbow version).
A more complete summary of the changes is in the file MSR23A.UPD.  Readers,
please get the new version and try it, report any problems to
[e-mail].  If all is well, this will become the
standard version, and sources will be made available.]

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

Date: Thu, 6 Oct 1988 17:08:33 EDT
From: Christine M Gianone <[e-mail]>
Subject: Announcing a Beta Test Kermit for MS-Windows
Keywords: MS Windows, Microsoft Windows

This is to announce a new version of Kermit for Microsoft Windows from Bill
Hall of the Olivetti Advanced Technology Center, who contributed the first
version in early 1987.  Unlike the earlier release, this one includes a
full-fledged Heath-19 terminal emulator, and it should run on any PC that has
version 2.0 or later of MS-Windows, Windows/286, and Windows/386.  Sources
will not be available during the testing period.  If you have comments,
suggestions, bugs to report, etc, you may correspond with Bill as
uunet!oliveb!whall (or oliveb![e-mail]).  The files replace the
old release on "Tape A" as WIN*.* (on CUNIXC, ~kermit/a/win*.*).  Many thanks
to Bill for all his excellent work.

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

Date: Thu, 6 Oct 1988 17:08:33 EDT
From: Christine M Gianone <[e-mail]>
Subject: Announcing EASYK, a Menu-Driven Shell for MS-DOS Kermit
Keywords: MS-DOS Kermit 2.31, EASYK

This is to announce a "shell" for MS-Kermit 2.31, for use on the IBM PC and
compatibles in the IBM mainframe 3270 emulation environment, developed by
Prof. Richard A. Elnicki of the University of Florida College of Business,
$$$[e-mail].  The shell is constructed from a collection of Kermit
command and script files, and provides menu-driven access to IBM CMS and TSO
systems via VTAM.  The package, called EasyK, was designed to provide users
with easy, full-screen access to CMS and TSO services in their homes in a mode
that looks similar to the access they have in their offices on micros with
coaxial cable boards.

Since there are numerous files, some of them containing 8-bit characters (e.g.
for special effects in the documentation), they have been archived using the
PKARC utility, and the resulting EASYK.ARC file was converted to .BOO format
for distribution over networks, on tape, etc, as MSIEAS.BOO (available on
CUNIXC as ~kermit/a/msieas.boo).

Thanks to Prof. Elnicki for contributing his work.  Although some of it is
specific to the University of Florida mainframe environment, it should be
easily customizable for other institutions with similar equipment.

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

Date: Thu, 6 Oct 1988 17:08:33 EDT
From: Christine M Gianone <[e-mail]>
Subject: Announcing Hebrew Kermit, a Test Version for the IBM PC
Keywords: MS-DOS Kermit 2.30, Hebrew

This is to announce a beta-test (binaries only, no source) of MS-Kermit for
the IBM PC, adapted for use with the Hebrew Alphabet, complete with
right-to-left screen presentation, from Baruch Cochavy, IIT, Haifa, Israel,
[e-mail].  The work is based on version 2.30 of MS-Kermit.
Included are KERMITH.EXE, a "readme" file that explains some of the changes
that were made, and a Unix termcap file.

The program may also be used on non-Hebrew PC's, for those who enjoy reading
English (or German, or French, etc) right to left.  The default mode of
operation is left to right, so say "SET TERMINAL DIRECTION RIGHT" to get the
new perspective.

The files are collected into a single file, MSTIBH.BOO, which in turn contains
an .ARC file which can be dearchived using PKXARC.  Thanks to Baruch for
sending this in.  Please send comments or questions directly to him at the
address noted above, and perhaps this new directional capability can become
an integral part of MS-Kermit.

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

Date: Tue, 13 Sep 1988  01:59 MDT
From: Keith Petersen <[e-mail]>
Subject: MSDOS Kermit Script Files Available from SIMTEL20
Keywords: MS-DOS Kermit 2.31, Script Files

Now available via standard anonymous FTP from SIMTEL20.ARMY.MIL...

Filename            Type     Bytes     CRC

Directory PD1:<MSDOS.MODEM>
KER_SCP1.ARC.1            BINARY     17291  D6E5H

Here is the author's description:

KER_SCP1.ARC    - Useful Kermit (v2.29 or above) script files.

        Files include:
          Scripts to log on to a Unix VAX host and two common BBS's
          (TCOMM, ROS)

              A typical initialization file (MSKERMIT.INI) to set baud,
          port, function key macros, command macros, etc.

          An extract from the Kermit user's manual specifically
          discussing scripts.

Other Kermit users are encouraged to contribute scripts that help ease
THEIR communications.  Keith Petersen <[e-mail]> will
collate and incorporate them in this archive.  (So send them to HIM,
not to me!)

          David Kirschbaum
          Toad Hall
          [e-mail]

--Keith Petersen
Maintainer of the CP/M and MSDOS archives at SIMTEL20.ARMY.MIL [26.0.0.74]
Arpa: [e-mail]
Uucp: {att,decwrl,harvard,ucbvax,uunet,uw-beaver}!simtel20.army.mil!w8sdz

[From jrd - Thanks for the public service Keith. Users should be aware of
some small changes to MS Kermit from version to version. The Users Manual,
noted above, has a list of them.]

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

Date: Tue, 13 Sep 88 20:55:40 PDT
From: [e-mail]
Subject: Automatic Exit from MS-Kermit?
Keywords: MS-DOS Kermit 2.31

Our administrative users utilize mskermit 2.31 exclusively as a vt102 terminal
emulator to connect their PCs to a Sun mini-computer.  Currently each user's
mskermit.ini file is set up to log them on to their own account.

QUESTION: Is it possible for Unix to send an escape sequence to mskermit
          which would automatically `quit' the mskermit session after the
      user types `logout'?  This sequence would be echoed from the
      user's .logout file.

Our goal is to make mskermit fully transparent to our administrative users.
(One less thing to teach them.)

Jim Bradley, College of Natural Resources Computer Facility, UC Berkeley

[From jrd - There is no such provision in MS Kermit, and the danger is that
TYPING/cat-ing a strange file could abruptly terminate Kermit. ALT-X is a
rather common key combination to exit a mode, and it is assigned the Kermit
keyboard verb \Kexit. Another keyboard combination can be assigned to the
same verb to satisfy local operating conditions. Both simplify the task
of remembering (and finding) Control-] C. If MS Kermit is started via a nice
batch file to simplify the startup and login process then the EXIT command
can be slipped into the script to exit Kermit whenever Connect mode is
exited.]

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

Date: Tue, 13 Sep 88 21:24:58 PDT
From: [e-mail]
Subject: Missing the Bell When Using MS-Kermit
Keywords: MS-DOS Kermit 2.31

RE: Info-Kermit Digest V8 #8

Re Kermit 2.31.....may I add my thanks and congratulations also on a superb
product.  I use it constantly at 2400 to talk with the UBC MTS system from
my home.

Problem (very minor):
using an Acer710 (IBM-clone) running at 10MHz with lots of TSRs and stuff(!)
or running vanilla DOS (3.1, 2. or 3) I find that after a file transfer in
either direction, I no longer have a bell.  It doesn't sound after the
transfer and can't be made to sound even after exit ( using a norton utility
called beep)

Rebooting solves this problem, but....
Not really important, but mildly annoying.
Thanks again.
Dallas (music teacher)

[From jrd - Must be an ACER bug of some subtle kind or even more likely a TSR
has repeatedly grabbed the timer chip hardware. Kermit makes only very
standard use of the timer chip. Pretty common advice applies here: unload
TSRs etc and then retest with them added back in one at a time.]

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

Date: Tue, 23 Aug 88 19:43:54 -0700
From: Alastair Milne <[e-mail]>
Subject: Kermit Across Ethernet
Keywords: MS-DOS Kermit 2.31

We have recently installed PC-NFS running on Western Digital WD8003E ethernet
cards.  While in general it is running great, Sun's telnet not infrequently
experiences long suspensions of activity.  This is a known bug in telnet, but
it's very irritating.

Having observed that Kermit now allows a SET PORT NET command, I tried it, but
apparently it wants something different from our arrangement.  I've heard that
it's actually intended for a Token Ring net.

Is there any form of the command that would let Kermit work across ethernet?
It's a better terminal emulator than telnet, and it would be nice to be able
to move files without exiting and running ftp every time.  At the moment, the
alternative seems to be a different telnet implementation that runs better,
but requires that NFS not be installed -- which is a nuisance when you have
virtual drives mounted across the net.

Thanks for any help,

Alastair Milne

[From jrd - The SET PORT NET command requires NetBios support from your
network. With that it is independent of the access method (Token Ring,
Ethernet, or anything else). I use the same Western Digital Ethernet boards
with no ill effects. If NFS lacks NetBios perhaps it came with a serial port
Bios "interceptor" which simulates a hardware serial port. In that case SET
PORT BIOSn might work for you. No local copies of PC-NFS here so I'm guessing.]

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

Date: Thu, 25 Aug 88 11:29:14 EDT
From: Caroline Arms <[e-mail]>
Subject: MS-Kermit with StarLAN
Keywords: MS-DOS Kermit 2.31

At the business school (GSB) at the University of Pittsburgh, the IBM PCs
(real IBMs, not compatibles) are on a StarLAN network, which is linked in turn
over an AT&T box called a SLIM-C to an AT&T ISN (9600 baud asynchronous
point-to-point connections) for terminal access to hosts, primarily the
school's 4381 (through a 7171 protocol converter).

The StarLAN was purchased after AT&T "assured" GSB that, in combination with
the SLIM-C (in beta test), this setup would provide good access to the 4381
from the PCs in the lab.  When AT&Ts own terminal emulators proved inadequate
to the task of providing enough special keys for 3270 emulation, someone at
Bell Labs. modified a version of the "clone" MS-Kermit 2.29b to work over
StarLAN.  I assume that it was this work that later was incorporated into an
"official" release, since I remember an acknowledgement to AT&T.

We have been happily using this modified version of MS-Kermit 2.29b with
StarLAN (v 1.1), and getting adequate performance.  The screen does not redraw
as quickly as at 9600, but much faster than at 2400, after an initial hiccup
as the first few lines draw rather slowly, and then the rest is drawn almost
instantly.  This effect was marginally annoying, but you got used to it.
Input was fine, with the screen display keeping up with cursor movements and
deletions.

Then came StarLAN 2.0, and MS-Kermit 2.30.  MS-Kermit 2.30 now officially
supports StarLAN, but only version 2.0, so I can't do the upgrade in two
steps.  The screen re-display hiccup has disappeared, but at an unacceptable
price.  On input, the display gets several characters behind, which makes
using the cursor on a full-screen editor or to correct a typo at the beginning
of a line an exercise in frustration.  If we made the upgrade, there would be
a revolt by 300 MBA students, notoriously intolerant at the best of times!

I had the same problems with the "test" versions of 2.31 that I tried, but
have not yet had a chance to try out the recent 2.31 service release.

I have naturally asked AT&T where they think the problem might be, so far with
no luck.  Is anyone else out there using Kermit with StarLAN, and have they
experienced anything similar?

Caroline Arms
CA0L@CMUCCVMA   (or VMA.CC.CMU.EDU)
      [BITNET]       [Internet]

[From jrd - The STARLAN support in MS Kermit (as contrasted to the AT&T quicky
named STARKERM) is entirely non-AT&T code and unrelated in method or approach
to STARKERM. The AT&T item coupled to their proprietary terminal emulator
package whereas MS Kermit uses the industry standard NetBios API. Paul Fox,
then with AT&T, did a nice job with STARKERM. At his/their request and with
their material assistance I independently developed LAN support in MS Kermit,
using the industry standard NetBios session APIs, and added provisions to
support the published AT&T ISN extensions (if testing by Kermit reveals their
presence). So, any design faults in NetBios support are mine.

        I run STARLAN in my office and notice no such cursor lag time when
talking to locally available hosts (a Unix PC and a DOS AT) on my huge three
node network. If your host(s) or relay boxes attempt to form larger packets
from smaller ones, and wait until full, then lags will develop. Kermit sends
terminal emulation characters one per packet, except when some known escape
sequences occur which go out as one sequence per packet (also solves some
Emacs timing problems on hosts). File transfer material goes out in 256 byte
chunks. It requests reception well ahead of exhausting the buffer of
unprocessed characters and continues to process all available characters. All
this network packet sending and receiving is fully interrupt driven.  Delays
in exporting packets to MS Kermit can result in a slow response time. A simple
test of matters is to observe echos on the PC from typing single keys; lack of
timely echos is a host problem. I do notice a substantial delay when the DEL
key is pressed because my Unix host system imposes that delay; similarly with
XON/XOFF - a host problem. VI runs just fine here, with no noticable lagging.

        If worse comes to worse we need to talk on the telephone: 300 irate
students is cruel and unusual, even for us Prof types. (801)-750-2982 work.]

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

Date:  Wed, 31 Aug 88 15:00:31 EDT
From: Rick Wiggins <[e-mail]>
Subject: PC-KERMIT ReGIS Support
Keywords: ReGIS Color Graphics, MS-DOS Kermit 2.31

We (The University of Akron, Computer Center) would like to have VT241 ReGIS
color graphics support for the PCs we have attached to our VM and Ultrix
systems.  There are several commercial packages available, however, we have
been unable to find one that supports color hardcopy from the screen.  Has
anyone used a system that does support color hardcopy?  Does anyone know of a
PC-KERMIT that supports ReGIS?  If there isn't already a version of PC-KERMIT
that supports ReGIS, would anyone else be interested in one?  Please send
responses directly to me.  Thanx...

[From jrd - MS Kermit supports the DEC VT102 but does not support ReGIS
graphics. There is also the not insignificant problem of matching to the
particular color printer device.]

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

Date: 31 August 88, 13:58:26 CST
From: ZZHS0008@UNLVM
Subject: IBM 3174 AEA Ports and Kermit?
Keywords: MS-DOS Kermit 2.31, IBM AEA Ports

I would like to know if there is any current developement in an enhancement
for MSVIBM or MSVGEN versions of Kermit for file transfer capabilities going
thru IBM 3174 AEA ports ?????  If you are unable to answer this question,
please tell me who I should ask.  Thank you for your time.

Jim Boeckman
University of Nebraska Medical Center
Omaha, NE
[phone]

[From jrd - For MS Kermit to function the host side needs to be able to cope
with async ASCII full duplex communications. MS Kermit recognizes the IBM
line turn character (typically XON) during file transfers if HANDSHAKE is
on, such as by saying DO IBM at the Kermit prompt. I am unfamiliar with 3174
ports so another person is needed to answer that part of your question.]

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

Date: Sat, 10 Sep 1988  13:29 MDT
From: Keith Petersen <[e-mail]>
Subject: MSDOS BOO Maker/unBOO Bug
Keywords: MS-DOS Kermit 2.31, BOO Files

I don't know if it's MAKEBOO or UNBOO but if you make a BOO file from a binary
on MSDOS and then UnBOO it you end up with three binary zeros followed by a 1A
hex (control-Z) in the reconstitued binary file at the very end.  This
shouldn't hurt most programs but I would recommend that you ARC your files
first and then BOO the ARC to send it to your friend.  This way the files he
ultimately extracts from the ARC will be *exactly* the same as your originals.
You will also have the added peace of mind of knowing they arrived error-free
because of the CRC checking that is done when extracting the files from the
ARC.

--Keith

[From jrd - Yes, archiving does preserve both exact lengths and applies a CRC
check as well. However, it now requires two utilities at each end, with the
archive program developer requesting payment. The trailing bytes from unBOOing
are cosmetic in almost all applications. However, Columbia has a long list of
possible improvements to the highly successful BOO process and they have now
seen your suggestion.]

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

Date: Mon, 12 Sep 88 18:19 EST
From: [e-mail]
Subject: Kermit SET KEY Command and String Capability
Keywords: MS-DOS Kermit 2.31

It would be nice to program combined command and strings using SET KEY.  For
example many systems do not have delete keys which delete the character
directly over the cursor.  In such cases one would like to:

SET KEY \339 \Krtarr \127

i.e. jump ahead 1 space then backspace over (thus deleting) the offeding
character.  My reading of the KERMIT manual (and trial and error) indicates
this is impossible in the current version.

Am I wrong?  Please advise. and ... Thanks for a great program!

[From jrd - the current design of the keyboard translator mechanism does not
allow multiple "items" in a key definition, despite the desirability in some
cases. Hosts working with standard terminal types, such as the VT100 series,
normally echo cursor commands to provide such customized Deletes. They
understand that just moving the cursor does not modify the characters on the
screen, but that moving the cursor plus sending spaces does simulate erasure.
It's the host which has to do all this in response to a simple command,
usually the byte BS or DEL, from the "terminal."]

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

Date: 16 Sep 88 13:24:00 EST
From: "OAX::TURPINM" <[e-mail]>
Subject: Solution Found to Problem with <ESC>[?3l
Keywords: MS-DOS Kermit 2.31

I had sent a message earlier......

> I am using Kermit v2.31 dated 8-18-88 and have noticed a problem with
> character attributes in VT102 mode AFTER Kermit has received:

> <ESC>[?3l

> This is the VT control code to go to 80 column mode.  Kermit does that
> fine, but it also turns the bold character attribute on as well.  A real
> VT doesn't do this.

> Has this already been reported?  If so, is there a fix?  If not, does
> anyone have any suggestions on a patch that would fix the problem?

I have located the problem.  I was using Kermit with it's default SET TERM
COLOR.  The default is high intensity foreground.  Apparently when <ESC>[?3l
resets the screen width to 80 columns, it also resets the foreground
intensity.

The solution is to EXPLICITLY set the foreground to low intensity before going
to connect mode (eg., SET TERM COLOR 0 37 44).  Then when <ESC>[?3l is
executed it will set the foreground to low intensity.

Mike Turpin
DDN:  [e-mail]

P.S. The host software that I'm communicating with is DEC's ALL-IN-1 and
with the minor change given above, Kermit works BEAUTIFULLY.

[From jrd - When entering terminal emulation MS Kermit attempts to use the
existing screen coloring and attributes, unless overridden by a SET TERM
command. If bold is on at that time then the screen width change attempts to
restore it. It is useful to realize that DEC and IBM differ about boldness:
DEC means make all displayed dots brighter but IBM hardware says make only
foreground dots brighter but not the surrounding background area of a
character.]

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

Date: Wed 21 Sep 88 11:07:39-EDT
From: Charles Reader <[e-mail]>
Subject: Problem Compiling MSSSET.ASM
Keywords: MS-DOS Kermit 2.31

    I've been trying to built MS-KERMIT V2.31 for my Rainbow, but I get an
"OUT OF MEMORY" error when I try to compile the MSSSET.ASM module.  I'm
running version 2.11 of DOS on the Rainbow and the Rainbow has 704K of
memory.(My memory drive takes up 192K of memory, but I got the same result
when I removed the memory drive.)  Any suggestions on how I compile this
module?

                        Chuck

[From jrd - MASM is running out of symbol table space when it shows that
message. A later version of MASM is the only known cure.]

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

Date: 10 Aug 88 21:44:00 CDT
From: "DAVID GAY" <[e-mail]>
Subject: AT&T Graphics in MS-KERMIT 2.31
Keywords: MS-DOS Kermit 2.31, Graphics

My original bug report:

> Version 2.30 of MS-Kermit supports the AT&T 6300 graphics card for the
> Tektronix emulation just fine, but version 2.31 does not. The setup shows
> that the terminal graphics is set to AT&T 640x400, but the plots are done in
> CGA 640x200 mode.

Reply from JRD:

> I wonder if we are encountering a Bios version number effect.
> For AT&T machines Kermit looks for the word 'OLIVETTI' in the Bios starting
> at locations FC00:0h or FC00:2014H.  It would be worthwhile using Debug to
> probe your Bios.

At your service! Here is what Debug has to say about my Bios, which is
ROM BIOS version 1.43 from AT&T, the last version for the 6300, I'm told,
which replaced the old version 1.21:

-D FC00:0000
FC00:0000  13 00 3C E2 E8 02 20 CB-E8 71 25 CB E8 7A 25 CB   ..<... ..q%..z%.
FC00:0010  E8 82 25 CB E8 8F 25 CB-E8 92 25 CB E8 A2 25 CB   ..%...%...%...%.
FC00:0020  E8 B3 25 CB E8 B7 25 CB-E8 3B 25 CB E8 36 21 CB   ..%...%..;%..6!.
FC00:0030  E8 A1 21 CB E8 68 10 CB-E8 A3 15 CB CA D9 00 00   ..!..h..........
FC00:0040  43 4F 50 59 52 49 47 48-54 20 28 43 29 20 20 20   COPYRIGHT (C)
FC00:0050  4F 4C 49 56 45 54 54 49-20 31 39 38 34 20 20 20   OLIVETTI 1984
FC00:0060  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
FC00:0070  00 00 7E 81 A5 81 81 BD-99 81 7E 00 00 00 00 00   ..~.......~.....
        ...
I don't see "OLIVETTI" at either FC00:0h or FC00:2014H, but it is there
at FC00:0050. After FTPing MSGIBM.ASM from Columbia, I found this bit of
code which checks if we have an AT&T or Olivetti machine.
        ...
Now, I'm no whiz at assembler, but I think I understand why the AT&T isn't
sensed correctly. Do you perhaps need a compare at FC00:0050 ?
But the wierd thing is that it works with 2.30 but NOT with 2.31. Were
there any AT&T-related changes implemented between the two releases?
I cut the following out of the header of MSGIBM.ASM, perhaps it will jog
your memory, or lead to a solution. Unfortunately, I don't have the
source to 2.30 around here.
        ...
I hope this will enable you to track down this problem. Thanks for all your
time and efforts on this project, by the way. MSKERMIT has improved immensely
in the last several releases. The script capability is dynamite, and the
extended length packets make file transfer go faster. Keep up the good work.

If you want somebody to try out possible solutions, send me a message and
I'll gladly be a beta-tester.

David Gay
[e-mail]

[From jrd - Thanks David. A number of people (those with that Bios and a
network connection) have commented upon this item, and it has been fixed in
the forth coming version 2.31/A (in progress for rapid release).]

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

Date: Thu, 11 Aug 88 09:29:55 ADT
From: [e-mail]
Subject: OS/2 Kermit Won't Work
Keywords: OS/2 Kermit

The advent of OS/2 Kermit, even in beta form, is very welcome.  But, when I
retrieved the .BOO file from KERMSRV and de-boo-ed it in the same way as I do
for MS-Kermit releases, the program refused to run.  The error indicates that
Kermit is trying to dynamically load a portion of code and cannot find it.  I
suspect that the problem is in the BOO/unBOO process, do you know if anyone
has succesfully implemented the program in this fashion?  I am running OS/2
from Zenith (Version 1.00.5) on a Z286.

Peter White
Department of Chemistry
University of New Brunswick

[From jrd - The message here and below on OS/2 C Kermit relate to the same
fault in the original CKOKER.EXE file shipped to Columbia. It happens to me as
well, on two machines. The problem needs to be solved by the developer of that
version, Chris Adie [e-mail], since the source code has not been
made available. Here's the status of sources from Chris: "The sources for the
program and the Scribe source for the documentation will be made available
when beta testing is over (ie when bug reports slow to a trickle?)."]

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

Date: Tue, 20 Sep 88 09:38:20 EDT
From: "Pierre Goyette" <[e-mail]>
Subject: Problem with OS/2 Kermit
Keywords: OS/2 Kermit

I ftp'd the new Kermit for the OS/2 system for PC's and I'm sad to say it
doesn't work at all. The program fails to startup. I have had friends at other
universities try it and get the same result.

I get a SYS2070 when trying to load OS/2 Kermit. The message said: "The system
could not demand load the application's segment. WERMIT is in error. For
additional information, see error message SYS0202. The software diagnostic
code (trap number is: 13."

I'm running this on an 8 Mhz IBM AT with IBM VGA Adapter and 8513, using
Microsoft's SDK Version 1.03 (but without the PM shell). 3 Meg memory.

The size of my KERMIT.EXE is 126,220.

I hope that some other folks have reported this problem. Please let me know if
you need any other info.

Thanks,

Pierre Goyette
Network Systems Programmer
McGill University

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

Date: Tue, 20 Sep 88 09:57:16 BST
From: J. M. Hicks Coventry 523262 <[e-mail]>
Subject: Re: Kermit-MS version 2.31
Keywords: MS-DOS Kermit 2.31

Kermit-MS for the IBM PC seems to have had a curious flaw since version 2.28
at least.  The flaw seems to still be there in version 2.31.  If I have a file
called SKY.CON which has "connect" as the last command, I can use "do sky"
in Kermit-MS to invoke the commands in this file, including the "connect"
command at the end.  Everything is fine until I want to get back to Kermit-MS,
whereupon I need to type "ctrl/] c ctrl/] c" instead of just "ctrl/] c".

   If the "connect" command is typed at the keyboard, there is no problem.

   I would be grateful if you'd pass this on to the author of Kermit-MS
for his attention.  I should see any reply in the Info-Kermit Digest, as
I can obtain copies of it here in the U.K.

J. M. Hicks, (a.k.a. Hilary)
Computing Services, Warwick University, Coventry, England. CV4 7AL
On JANET: CUDAT at UK.AC.WARWICK.SKY
On BITNET: [e-mail]
On the Internet: try  [e-mail]  (untested)

[From jrd - I think you might have two CONNECT commands in there somewhere.
If commands were really done from a file one would say TAKE SKY.CON rather
than invoking a macro as DO SKY. So, SKY.CON probably defines a macro and
one can view it via SHOW MACRO.
Here is an example which worked fine here a minute ago:
        File x.tak holds the single line
        define x echo starting,connect

        Then I said
        Kermit-MS> Take x.tak
        Kermit-MS> Do x
        see Connect mode screen ...
        type ALT-X or Control-] C
        Kermit-MS> prompt reappears.]

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

Date: Fri, 12 Aug 88 13:38 N
From: <[e-mail]>
Subject: MS-Kermit v2.31 Inquiries

I have some peculiar problem with Kermit v2.31. After the Kermit> prompt
appears, my PC says: "Unexpected HW interrupt xx at yy. Type R to (R)eboot,
any other key to continue". The first time this happens, xx= 0C, and yy=
0070:0470, all successive times xx= 0B and yy= 0070:03F6.  The message keeps
appearing when going into and from connect mode.  Thing is, that it doesn't
happen with Kermit v2.30. Still, first I blaimed my Smartlink 1200BS modem,
but after removing it (and all other cards except the display adapter) I still
got the HW interrupt message.  So it is either my PC (Commodore PC20-II) which
up until now, has shown to be a perfect IBM-PC compatible, or something
special in the new MS-Kermit. Any ideas?

Enno Van Der Velde
University Hospital Leiden, The Netherlands
[e-mail]

[From jrd - Interrupts 0ch and 0bh refer to the serial port hardware which
your machine says it has. The indications are of a very early version of
the Phoenix Bios where interrupts were not fielded as gracefully as in most
machines. The mid-August maintenance release, and hence the newer 2.31/A
currently in the works, attempts to bypass that problem.]

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

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



11-Nov-88 22:39:00-GMT,26389;000000000001
Received: by cunixc.cc.columbia.edu (5.54/5.10) id AA04652; Fri, 11 Nov 88 16:17:58 EST
Date: Fri, 11 Nov 1988 16:17:56 EST
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V8 #10
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Fri, 11 Nov 1988       Volume 8 : Number 10

Today's Topics:

        Announcing a Partial Re-release of TSO Kermit
           Announcing a new version of Kermit for the Z100
                New OS/2 Kermit Files
            Utilities for Conversion of BOO files
                 EasyK Kermit Package
         Mac Kermit Settings Files for Mac Plus with Series/1
             File Transfer using SIM3278
        Apparent Bug in Long Packet Size on IBM 370 Mainframe
          Using EPSON PX8 without BASIC interpreter
                  EPSON PX8 Support
        Echo Bug in Kermit-80 ver 4.09 for NorthStar Advantage
              Kermit-80 for a Xerox 16/8
            8th-bit Stripping VAX-VMS->PC
               VMS Kermit with an X.29 Module?
               Need Compiled Kermit for VMS 4.3
             Kermit for MVS/Roscoe ETSO?
       VT100 Terminal EMulation for TI Professional Computers?
             A Question about the Kermit Protocol
              Kermit and SysVR3 layers.

Send digest submissions to [e-mail], requests for
addition to or deletion from the Info-Kermit subscriber list to
[e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host CUNIXC, CUNIXC.CC.COLUMBIA.EDU, a
VAX 8700 running UNIX (Ultrix).  The IP host number is 128.59.40.130.  You
should be able to to FTP to CUNIXC, login as user ANONYMOUS (any password)
and GET the desired files.  The Kermit files are in directories kermit/a,
kermit/b, kermit/c, kermit/d, and kermit/e.  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 k1/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, 1988 Sep 8 23:21 EDT
From: (John F. Chandler) [e-mail]
Subject: Announcing a Partial Re-release of TSO Kermit
Keywords: IBM 370 Kermit, 370 Kermit, TSO Kermit, MVS/TSO

This is to announce a number of modifications to release 4.0 of TSO
Kermit-370.  The most noticeable change is in the installation procedure --
the revised IKTKER.INS contains a batch job that can be submitted to install
Kermit from scratch all in one step (after allocating a pair of datasets by
hand).  One by-product of the new procedure is a version of the update
utility GUPI-TSO that can be used either interactively or in batch.  There
is now a HELP file for GUPI.  Numerous bugs in Kermit have been fixed (as
promised in a recent edition of IKTKER.BWR), and several new features have
been added.  Among them are:

1. A subcommand SET LONGLINE, to select the desired processing of lines
   received by TSO that exceed the LRECL -- the options are to fold,
   truncate or simply halt.

2. LRECL is now treated by Kermit exactly the way MVS does -- it must be
   four greater than the actual data length for RECFM=V files.

3. File allocation error messages are now saved in Kermit and reported
   as part of the STATUS text.

4. Kermit-370 automatically detects three types of terminal connections
   and sets CONTROLLER accordingly -- to TTY for line-mode terminals
   (3705, 3708, etc.), to SERIES1 for terminals hooked through protocol
   converters of the Yale ASCII family (Series/1, 7171, 4994, etc.), and
   to GRAPHICS for any other kind of full-screen device.

By the way, items 1 and 4 will soon be available for CMS as well.

This revision of Kermit requires not only a fresh copy of IKTKER.UPD, but
also replacements for four of the source components: IKTDYN.ASM, IKTGUP.ASM,
IK0GUP.ASM, and IKTMAC.ASM.  Note: if you try to install Kermit without
these new sources, the batch job will issue an error message in the update
step.

[Ed. - Many thanks, John.  The new files have been installed in Kermit
Distribution, along with a new file, IK0CON.HLP, that describes the
technical aspects of supporting (or adding support for) the various 370
console devices.]

And now a question: Kermit-CMS and, more recently, Kermit-370 for both CMS and
TSO have offered the option of setting the assumed parity of the incoming data
from protocol emulators (such as the 7171).  Has anyone ever taken advantage
of this option by setting the PARITY to NONE in the mainframe Kermit?  If so,
what hardware was involved?

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

Date: Thu, 3 Nov 88 20:23:53 EST
From: Drew Derbyshire <[e-mail]>
Subject: Announcing a new version of Kermit for the Z100
Keywords: MS-Kermit Z-100 MSTZ10, Zenith Z100, Heath/Zenith Z100

You will find following as separate files my latest test copy of Kermit-MS
2.31 for the Z-100, internally dated 16 October 1988.  Its documentation also
follows, no additional charge.  Please add the program to the Columbia Kermit
archives as MSTZ10.BOO (replacing my earlier test copy of MSTZ10 from January)
and the documentation as MSTZ10.DOC.

These files are also available from clutx.clarkson.edu via anonymous ftp as
pub/mstz10.exe and pub/mstz10.doc.

Very quickly, the highlights of the program include:

        All the new features of base Kermit-MS 2.31
        Improved printer support (in other words, it has some!)
        Improved key pad handling
        Various bug fixes

It does NOT include VT-102 emulation, nor do I have any plans to add it soon.
I write (and retrofit) operating systems for a living, and while retrofitting
the IBM-PC Kermit VT-102 emulation is possible, I have no personal use for it
and only one outside request to do so; thus putting the 100+ hours required
into such a project is not reasonable.

I will be adding VT-52 print through (escape code) processing and making other
changes as listed in the documentation, but not for a few weeks.  In the
meantime, I eagerly (?) await bug reports on the current version.

As for other comments about Z-100 Kermit-MS on various mailing lists in recent
months, Shift F12 (nor BREAK) are processed by Kermit because the BIOS
intercepts the keys.  For additional comments on this and related topics, see
the documentation file.

Drew Derbyshire

[Ed. - Thanks Drew!  The new MSTZ10.BOO has replaced the old one and
MSTZ10.DOC has been added.]

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

Date: 27-SEP-1988 09:50:34 GMT +01:00
From: [e-mail]
Subject: New OS/2 Kermit Files
Keywords: OS/2 Kermit

Sending the following new OS/2 Kermit files to replace the older ones:
CKOKER.DOC
CKOKER.BOO
CKOKER.BWR

[Ed. - Thanks Steve!  These files have been added to the distribution.
Reportedly, this version has some problems with VT100 terminal emulation
when parity is being sent by the host -- the problem is that CR, LF, ESC, and
other control characters are not recognized when they have the parity bit on,
and so do not cause the intended screen formatting to occur.  The typical
symptom is that after the first line reaches "column 80", all subsequent
characters are displayed in the same cell.  Reportedly, the workaround is to
get the host to not send parity (if this is possible).  Sources are not yet
available.  The executable program is encoded in "boo" format, and may be
decoded using any of the MSBPCT programs.  The C version has been included
with the CKO files as CKOPCT.C, but may need some conversion to work under
OS/2.  Please report any problems to Info-Kermit]

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

Date: Mon, 24 Oct 1988 22:16 EDT
From: <[e-mail]>
Subject: Utilities for Conversion of BOO files
Keywords: .BOO Files
Xref: BOO Files, see .BOO Files

I am sending two ASM files for your evaluation which perform the conversion
of BOO to EXE and EXE to BOO files far faster than the utilities you
currently distribute on KERMSRV@CUVMA.  For example, MSBPCT took 6 mins 32
secs to convert MSVIBM.BOO, while the new program MSPC2 took under 16
seconds on a PC XT.

The file names are:
      MSBPC2 ASM  to convert from BOO to EXE or binary
      MSBMKB ASM  to convert from EXE or binary to BOO

William C. Parke
Physics Department, GWU

[Ed. - Many thanks!  Now we have EXE-to-BOO programs in assembler (your new
one), C, Fortran, and Pascal, and BOO-to-EXE programs in Basic, C, Fortran,
Pascal, and assembler (two of them, one of them yours).]

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

Date: Tue, 30 Aug 88 12:07 MDT
From: Joe Doupnik <[e-mail]>
Subject: EasyK Kermit Package
Keywords: EasyK Kermit

The people at the University of Florida, Gainsville have put together an
extensive shell for MS Kermit to IBM mainframe communications. I've taken
their draft floppy disk and archived it with PKARC and boo'd the result as
EASYK.BOO, which follows.

        The package is pretty slick in its way.
        Regards,
        Joe D.

[Ed. - Thanks Joe!  The file has been put in kermit/a/msieas.boo, which after
unbooing (via any of the MSBPCT programs), is an archive of many files which
can be de-archived using PKXARC.]

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

Date: Fri, 02 Sep 88 15:57:58 EDT
From: Joe McMahon <[e-mail]>
Subject: Mac Kermit Settings Files for Mac Plus with Series/1
Keywords: MacKermit 0.9(40), 3270 Emulation, Series/1, 7171

Here's a Mac Plus settings file. It provides a setup useful for IBM 3270
emulation with Series/1-style protocol converters (7171, 4994, etc), along
with a MacDraw file for the keyboard map.

[Ed. - Thanks!  Your files have been put in ~kermit/b/ckmker.set.  Any Mac
Kermit settings files to be contributed in the future will be appended to the
same file.  The ckmker.set file is in Unix mail format, with the settings
files and keyboard maps embedded as BinHex 4.0 text files.]

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

Date: Thu, 11 Aug 88 13:22:42 ITA
From: Angelo De Florio <[e-mail]>
Subject: File Transfer using SIM3278
Keywords: Kermit-CMS, SIM3278

Has someone tried file-transfer using SIM3278/VM or SIM3278/GCS with
Kermit-CMS ?

I didn't be able to obtain it, using the Kermit-CMS command SET SERIES1 ON,
although the SIMWARE software should be compatible with IBM Series/1 YALE
IUP emulation system. Do I need to change some parameters ?

Thanks
Angelo De Florio

[Ed. - To our knowledge, so far no one has succeeded in getting Kermit to work
with SIM3278.  If anyone out there knows the secret, please share it!]

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

Date: Tue, 20 Sep 88 20:08:28 EDT
From: Peter Jones <MAINT@UQAM>
Subject: Apparent Bug in Long Packet Size on IBM 370 Mainframe
Keywords: Kermit-370, Kermit-CMS

There seem to be a small problem with SET RECEIVE PACKSIZE and SET SEND
PACKSIZE. SET RECEIVE seems to be OK, but changes both RECEIVE and SEND size.
SET SEND gives a diagnostic, but the SHOW PROTOCOL command shows that both
sizes have been altered.  These remarks apply to Version 4.0 of mainframe
KERMIT.

When running large packets on a PC with SET DEBUG on, the packets displayed
are so long that they cause the screen to scroll, ruining the status display.

[Ed. - Normally, the SET SEND PACKET command is never needed.  The size of
the packets is controlled by the receiver, via the SET RECEIVE PACKET command.
SET SEND PACKET is used only to override the negotiated value, and then only
downwards.  And you're right, long packets are not suitable for display on the
PC screen during file transfer.  It might be possible to create separate
scrolling regions for them, but this would destroy the system-independence of
this part of the program.  If you need to see long packets on the PC, you
can LOG PACKETS, rather than SET DEBUG ON.]

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

Date: Thu, 15 Sep 88 11:14:35 EDT
From: Peter Jones <[e-mail]>
Subject: Using EPSON PX8 without BASIC interpreter
Keywords: EPSON PX8

     I note with interest that there exists a file CPVPX8 that presumably
allows KERMIT to run on an EPSON PX-8. I have a two professors at UQAM who
would be interested in transferring files from their EPSONs to an IBM PC.
These EPSONs have the Travelling Wordstar PROMs, and do not have BASIC, as
there is not enough room for both.  I wonder how one can get KERMIT onto such
a machine?

     It is possible to use EPSON's TERM program to send and receive files in
8-bit ASCII, but I'm not sure that every ASCII character is in fact
transferred.  I have been able to transfer EPSON Wordstar files to the PC,
pass them through WORDPERFECT's CONVERT program, and read them with
WORDPERFECT.  The formatting commands seem to be transferred correctly.  The
user, however, finds the procedure too complicated and error-prone.  There are
too many manually-initiated steps, each of which must be done a certain way.

     EPSON has given us an QMODEM-compatible program to run on the EPSON, and
a copy of QMODEM to run on the PC. The transfer procedure is as complicated as
using TERM because, without documentation, I have been unable to discover how
to send a batch of files from the EPSON to the IBM PC without manually
starting and stopping each file on both machines.  Moreover, the EPSON
software takes 15 minutes to load from the microcassette --- far too long
because the software has too many features which are useless in this
particular application.

     EPSON does have a built-in program called FILSND, which allows PX-8's to
send files to one another and to EPSON PX-10's.  However, I have been unable
to get specifications from EPSON Canada on this protocol.  Do you have any
idea where this information can be obtained?  The difficulties of loading
executable programs into a PX-8 lead me to believe that any communication
program must be built-in.  I conclude with two methods of transferring files
from a PX-8 to a PC:

1) Write a PC program to emulate EPSON's PX-8 PX-10 protocol
2) Modifiy the EPSON PROMs to hold KERMIT instead on FILSND.

Does anyone have any comments on these ideas?

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

Date: Thu, 29 Sep 88 12:40:49 EDT
From: Peter Jones <[e-mail]>
Subject: EPSON PX8 Support
Keywords: EPSON PX8

     I would like to draw your attention to a letter published in the "Chaos
Manor Mail" section of "Byte" magazine, July 1988, Volume 13, Number 7,page
36, column 1, entitled "Calling All PX-8 Orphans".  This letter gives a couple
of places where one can still get PX-8 support:

1)   Synderscope International
     1594 Hilltop Dr., El Cajon, CA 92020
     (619)-442-3789 (bulletin board)

2)   DAK Industries
     8200 Remmet Ave., Canoga Park, CA 91304

3)   Bulletin board: (313)-538-6968

     I believe people ordering the PX-8 version of KERMIT would appreciate
receiving this information with their documentation.  I personally have not
tried contacting any of these people yet, so I don't know how useful these
addresses are.

[Ed. - Thanks, Peter.  This message has been put with the Epson Kermit hex
file as cpvpx8.hlp.]

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

Date: Wed, 2 Nov 1988  00:12 MST
From: Keith Petersen <[e-mail]>
Subject: Echo Bug in Kermit-80 ver 4.09 for NorthStar Advantage
Keywords: CP/M Kermit, NorthStar Advantage, Kermit-80

Relayed from GEnie's CP/M RoundTable:

 Message 17        Mon Oct 31, 1988
 J.LABUTE [JP]                at 21:42 EST

There seems to be a bug in CP409ADV.COM, the version 4.09 of Kermit-80
for the NorthStar Advantage. This version echos back to the remote
everything it receives.  I have had no problems with the versions for
the Apple II.

Replys to Keith Petersen <[e-mail]> please.
I will relay back to GEnie.

[Ed. - Bertil, are you out there?]

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

Date: Sat, 22 Oct 88 22:41:36 EDT
From: [e-mail] (Otto Miller)
Subject: Kermit-80 for a Xerox 16/8
Keywords: Kermit-80, Xerox 16/8

A little background info...  I am posting this request to both info-kermit and
info-cpm since I am not sure where my problem is.  I have installed several
variations of unix c-kermit and now I am trying to install cpm-80 kermit.

The specifics; I am using a Xerox 16/8 (5.25" floppy + HD).  Since the heart
of the 16/8 is a Xerox 820 (like) board I used the sys-dependent overlay for
the Xerox 820 (cpvxer.hex) with the sys-indep. (cpsker.hex) hex file to
generate the .com file.  All went well up to this point.  The problem appears
when I connect...  I get nothing out the serial port!  I looked at the source
to see if port B was used, but everything points to port A.  I have been
unable to hang a protocol analyzer to confirm no output, but when I hang a
known good modem on the port I get nothing... not even garbage.  WHAT's
WRONG?

Any and all help, pointers, etc. with constructive flames are solicited.
PLEASE email directly to me in that I am not on regular distribution for this
group; Thanks.  Thank you in advance for all the help.

#include std_disclaim.h             In real(?) life: Otto L. Miller
                                                     Contel FSS/ASD
email [e-mail]                        Fairfax, VA 22033
                                                     703-359-7500

[Ed. - Maybe the actual port addresses are different for the two Xerox
machines.  If anybody knows the answer, please send it in!  In a pinch, you
should be able to use the "generic" version of CP/M-80 Kermit.]

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

Date: Thu, 6 Oct 88 10:16:03 EDT
From: A.W.F. Huggins <bhuggins@LABS-N>
Subject: 8th-bit Stripping VAX-VMS->PC
Keywords: VAX/VMS Kermit, MS-DOS Kermit 2.31

IBM-PC Kermit-MS 2.31: 15 Aug 88

Since we installed the latest Kermit, we have had problems transferring binary
files between a Compaq 286 or 386 to a VAX 785 running VMS.  Either sending or
receiving from the PC, the msb is stripped.  We thought at first that it was
some problem with the serial line card in the Compaqs, since the problem did
not arise running the same version of Kermit on an XT.  Then we tried IC, and
8-bit files transferred without problems.  After some poking around, we found
that setting the parity bit to SPACE (instead of NONE) resulted in correct
transfers on the Compaqs, although the transfers were inefficient because all
8-bit bytes were transmitted by quoting.  Finally, we noticed that the
MSKERMIT.INI on the Compaqs had CRC block-checking enabled, whereas the XT did
not.  It appears that CRC checksumming is incompatible with 8-bit
transmissions.  There is no statement to this effect in our copy of the
documentation, and there should be.

[Ed. - 8th bit prefixing is totally independent of CRC block checking.
However, there was a bug in that version of Kermit which would make it
sometimes use 8th-bit prefixing when it was not negotiated.  Try the current
beta-test prerelease version of 2.31A, which is in kermit/a/mstibm.boo on
CUNIXC or MSTIBM BOO from KERMSRV at CUVMA.]

VMS Kermit-32:

And while we are at it, what is the use/purpose of SET FIL TYP BIN on
VMS-KERMIT-32?  If you use this mode instead of FIX, you get CR-LF inserted
after every block.  Can this ever be beneficial?  Why not have BIN map onto
FIX, so people who apply common sense rather than consulting the documentation
win too?

[Ed. - Kermit-32 is no longer actively maintained, and the original authors
are not available to answer your question.  To our knowledge, FIX does not
insert CRLFs, rather it pads the file out with nulls to a multiple of 512
bytes.  Binary files transferred to a VAX from a PC and back using BINARY
come back identical to the original, whereas those sent using FIX come back
with extra nulls on the end.]

Bill

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

Date: Thu, 21 Jul 88 14:02 GMT
From: "Eoin Meehan, EuroKom" <[e-mail]>
Subject: VMS Kermit with an X.29 Module?
Keywords: VAX/VMS Kermit, X.29 Module

Does anyone know of a version of Kermit for VMS which has the ability to
connect over PSI?

What I'm looking for is a command something of the form

                "CONNECT/X29 0272412345678"

We use Kermit extensively for file transfer. Our users with PC's are ok
but some of our users have VAXen and they use  the SET HOST/X29 to connect
to us. This obviously precludes using Kermit file transfer! If a user really
needs kermit file transfer then we suggest using the "kermit loop" whereby
they loop two async ports together, "CONNECT" to one port and log in again,
and then use the SET HOST/X29 command -- kinda messy.

Thanks,

Eoin Meehan

Eoin Meehan                      Bitnet/EARN: [e-mail]
EuroKom                          Voice:       [phone]
Computer Centre                  Telex:       91178 UCDEI
University College Dublin        FAX:         [phone]
Belfield                         PSImail:     PSI%027243159000737::emeehan
Dublin 4
Republic of Ireland

"Why is there only one Monopolies Commission?"
"Who builds DIY stores?"

[Ed. - This is a very popular request, especially from Europe.  Kermit needs
to have special code added to use VAX/PSI.  So far, no one has volunteered to
do this.]

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

Date: Fri, 22 Jul 88 14:00:48 CDT
From: [e-mail] (Moore)
Subject: Need Compiled Kermit for VMS 4.3
Keywords: C-Kermit, VAX/VMS Kermit

Is there anyone out there who would be willing to send me a tape of a
compiled Kermit for a VAX 11/780 running VMS 4.3?  We don't have a C
compiler so we can't grab the source from CU20B.

Thanks for any assistance.

Jim
[e-mail]

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

Date: Thu, 25 Aug 88 15:09:50 CST
From: "Subir Prasad" <[e-mail]>
Subject: Kermit for MVS/Roscoe ETSO?
Keywords: MVS/Roscoe ETSO

To Anyone With Ideas,

We have an Amdahl 470V/8 on which we run MVS/Roscoe ETSO.  We tried
implementing the MVS/TSO version of Kermit-CMS Version 4.0, but we could never
get a file to transfer to or from an IBM PC.  We were, however, able to put
MVS Kermit into server mode and successfully execute the FINISH and HOST DIR
command from the PC's Kermit (which by the way was Kermit-MS Version 2.30).

When we tried file transfer, MVS seemed to acknowledge and receive the file
header, but it never could read or write the actual contents of a file.  It
would give a "BAD COMMAND" error.

We believe the problem is a disk allocation problem that Kermit-MVS has with
ROSCOE ETSO.

Any suggestions? Has anyone successfully implemented a version of Kermit on
ROSCOE ETSO?

One other possible avenue: Does anyone know where we could get XMODEM, YMODEM
or ZMODEM for ROSCOE??

Thanks.
Subir Prasad
The University of Mississippi/Computing & Information Systems
Acknowledge-To: <CCDOC@UMSVM>

[Ed. - Can anyone help?  It is unlikely that Xmodem or any of its derivatives
will work with MVS/ROSCOE or any IBM mainframe operating system, because it
is an 8-bit transparent protocol, and IBM mainframes always do 7-bit i/o with
ASCII devices.]

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

Date: Thursday, 26 May 1988  08:29-MDT
From: "Wayne J. Hauber" <[e-mail]>
Subject: VT100 Terminal EMulation for TI Professional Computers?
Keywords: TI Professional Kermit

Is anyone aware of a communication program for the Texas Instrument
Professional computer that has a reliable VT100 emulation?  I am aware of a
Kermit that is a couple years old but which has a poor emulation.

The TI Pro is a MS-DOS micro that is not fully IBM compatible and does not
work with the usual MS-DOS communication programs.  My university has a number
of TI Pros.  We were wondering if there were alternatives to an aging locally
written communication program.

Please send responses to me directly rather than posting them.

Wayne Hauber
Programming Consultant
Iowa State University
Computation Center
[e-mail]    <-- preferred addresss
[e-mail]  <-- a good alternate
[e-mail]  <-- if you are on CSNET

[Ed. - The TI Pro version of Kermit no longer has anybody working on it.]

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

Date: Thu, 22 Sep 88 08:58:39 +0100
From: J M Hicks <[e-mail]>
Subject: A Question about the Kermit Protocol
Keywords: Kermit Protocol

This is a question about the Kermit protocol itself.

I have been working with two old implementations of Kermit.  When a CR (or, in
one implementation, XON) character arrives in between packets, they seem to
think that a bad packet has arrived and reply with a negative acknowledgement
for the expected packet or another acknowledgement of the previous packet.

I was under the impression that characters between packets should be
completely ignored.

What ought Kermit to do?  If such characters between packets appear often,
one end can give up due to all the bad packets it thinks it has received.

[Ed. - It should ignore any characters that appear between packets.]

J. M. Hicks (a.k.a. Hilary),
Computing Services, Warwick University, Coventry, England. CV4 7AL
On JANET:       [e-mail] (in the U.K.)
>From BITNET:    [e-mail]
>From Internet: try  [e-mail]   (untested)
On Usenet:      ...!mcvax!ukc!warwick!cudat
                                It helps if you spell "cudat" in lower case.

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

Date: Sat, 13 Aug 88 00:28:13 EDT
From: Greg Woods <[e-mail]>
Subject: Kermit and SysVR3 layers.
Keywords: SysVR3 Layers

Is anyone doing, or interested in doing, something about getting kermit
to talk to Sys V R3 layers?  I would find that an EXTREMELY important
feature.

Since a lot of PC's have graphics and mice these days, a graphical
version would be even better.  It would sure cut the entry-level cost of
using layers (for those of us with access to a PC).

                        Greg Woods.

UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods
VOICE: [phone] [h]        LOCATION: Toronto, Ontario, Canada

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

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

15-Dec-88 21:54:15-GMT,20171;000000000005
Received: by cunixc.cc.columbia.edu (5.54/5.10) id AA13261; Thu, 15 Dec 88 15:44:24 EST
Date: Thu, 15 Dec 1988 15:44:23 EST
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V8 #11
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Thu, 15 Dec 1988       Volume 8 : Number 11

Today's Topics:
        Announcing a New Kermit for Microsoft Windows
        Announcing Version 3.1 of Turbo Pascal Kermit
              New xxu.c Utility Program
            Some responses to V8#10 and Kermit-370
             Kermit 370 Trailing Blanks Trimming
                VMS C-Kermit Dialing?
        C-Kermit Problems on SUNs with SUNOS Version 4
            Directory Locking in C-Kermit?
                VAX/VMS Kermit via x25
       Response to Request of vt100 Setting Macro for MacKermit 0.9(40)
             MacKermit vt100 Initialization Files
               MacKermit Settings File
              Kermit for Honeywell DPS-6/GCOS6?
          Kermit wanted for Burroughs B21 (Not B25)?

Send digest submissions to [e-mail], requests for
addition to or deletion from the Info-Kermit subscriber list to
[e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host CUNIXC, CUNIXC.CC.COLUMBIA.EDU, a VAX
8700 running UNIX (Ultrix).  The IP host number is 128.59.40.130.  You should
be able to to FTP to CUNIXC, login as user anonymous (lower case user name
with any password) and GET the desired files.  The Kermit files are in
directories kermit/a, kermit/b, kermit/c, kermit/d, and kermit/e.  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 k1/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, 9 Dec 1988 16:40:00 EST
From: Christine M. Gianone <[e-mail]>
Subject: Announcing a New Kermit for Microsoft Windows
Keywords: IBM PC, MS-Windows, JAR files

This is to announce a new version of Kermit for Microsoft Windows.  The
program is written in Microsoft C and should run on any computer that has
Microsoft Windows version 2.03 or later, or Windows/286, or Windows/386.  It
was written by Bill Hall of Santa Clara, CA, and is a complete replacement for
the earlier, primitive WINKERM contributed by Bill a couple years ago.  This
version includes a Heath/Zenith-19 terminal emulator, fully integrated with
the Windows environment (so you can cut & paste, etc).  This Kermit program
can run in one window while you are doing some other work in another window.
Thus, file transfers can proceed in the background.  In fact, multiple
instances of MS-Windows Kermit can be active at the same time (but of course,
each requires a separate communication port).

As submitted by Bill, the files have names that don't fit into the Kermit
Distribution naming conventions -- He renamed the program from WINKRM to
WKERM, but unfortunately there already is a WKERMIT (the sliding windows
version of Kermit for PC).  But since the names are important (e.g. the
program itself must be called WKERM.EXE to allow code sharing for multiple
instances), the files have been concatenated into "text archives", which we
call "jar" files ("join archive").  The explanation of the format of the jar
file is found at the beginning of the file, along with a C program for taking
it apart again (you can also use a text editor).

Here's a brief description of the archives and the files within them:

WINKRM.JAR:

  README.1ST - A "read me first" file.

  WKERM.EXE - A Windows terminal emulator for the Heath/Zenith H/Z-19 terminal
with the Kermit file transfer protocol added.  (This has been encoded in "boo"
format as WKERM.BOO, and can be decoded back into .EXE form using any of the
MSBPCT programs.)

  HEATH19.FON - An optional ASCII font also containing the original H-19
graphics characters which can be loaded with the Windows control panel and
used with the H-19 Windows terminal emulator.  (This has been encoded in "boo"
format as HEATH19.BOO, and can be decoded back into .EXE form using any of the
MSBPCT programs.)

  DEMO.C - a C-program which can be used to illustrate some terminal functions
and the H-19 font.  Please read the comments in that file for more
information.

  WINH19.DOC - Documentation for the H-19 terminal emulator portion of Windows
Kermit.

  WKERM.DOC - Supplementary information on how to use the Kermit feature of
the emulator.

  WINH19.APP - An appendix to the WINH19.DOC file giving detailed technical
information about keyboard usage.

  TERMCAPS.H19 - a suggested UNIX TERMCAPS file for the H-19 emulator.  Both
24 and 30 line versions are illustrated for ANSI and HEATH modes.

WINSRC.JAR:

  Source files for WKERM in C, plus header files, compile and link procedures.

Thanks to Bill for all the work that went into this package and for
contributing it to Kermit Distribution.  Bill's network mail address (as seen
from Columbia) is:

rochester!ames!olivej.ATC.OLIVETTI.COM![e-mail]

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

Date: Wed, 14 Dec 1988 17:40:00 EST
From: Christine M. Gianone <[e-mail]>
Subject: Announcing Version 3.1 of Turbo Pascal Kermit
Keywords: IBM PC, Turbo Pascal, Tektronix 4100, QK Kermit

Victor Lee, [e-mail], of Queens University, Kingston, Ontario, has
submitted a new release of QK-Kermit, the Turbo Pascal that runs under MS-DOS
on the IBM PC and PS/2 and compatibles.  The new release, 3.1, now emulates
the Tektronix 4100 rather than the 4010, so that it is capable of color
graphics.  Many thanks to Vic for this submission.

The files are in kermit/a/qk3*.* on CUNIXC, available via anonymous FTP, and
as QK3* * from KERMSRV at CUVMA on BITNET.

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

Date: Tuesday, 15 November 1988 09:22-MST
From: steinmetz!crdos1![e-mail] (Wm E. Davidsen)
Subject: New xxu.c Utility Program
Keywords: xxu.c, Unix, Filenames

I was looking at the "xxu" program you posted recently, and I added a few
changes for SysV and Xenix. I also changed the logic to turn blanks into
underscores rather than keep or delete them. I could probably find the info on
ftp upload, but this is small enough to mail and I have to ftp via another
machine anyway.

I don't have problems with my ftp names, but I do get programs which create
really bad filenames at times. This is an easy way to clear them out.

bill davidsen        ([e-mail] -or- [e-mail])
            {uunet | philabs}!steinmetz!crdos1!davidsen

[Ed. - Thanks for the update Bill.  And thanks to Keith Petersen for
submitting the program to Info-Kermit.  The file has replaced the old one in
kermit/b/xxu.c]

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

Date: 1988 Dec 5   22:46 EST
From: (John F. Chandler) [e-mail]
Subject: Some Responses to V8#10 and Kermit-370
Keywords: Kermit-370

Angelo De Florio wrote concerning SIM3278:

> Has someone tried file-transfer using SIM3278/VM or SIM3278/GCS with
> Kermit-CMS ?

Yes, it has been tried, but I don't believe it is possible, since SIM3278
doesn't have any transparent READ capability, only a WRITE.

Peter Jones wrote concerning Long Packet Size on IBM 370 Mainframe:

> There seem to be a small problem with SET RECEIVE PACKSIZE and SET SEND
> PACKSIZE. SET RECEIVE seems to be OK, but changes both RECEIVE and SEND size.
> SET SEND gives a diagnostic, but the SHOW PROTOCOL command shows that both
> sizes have been altered.  These remarks apply to Version 4.0 of mainframe
> KERMIT.

Beyond the editorial response in the digest, I must point out a couple things.
First, SET SEND PACK has only one function in Kermit-370 -- it provides the
default in case the other Kermit leaves the packet size blank in its
negotiations.  If you wish to restrict the size of packets to be sent from a
given Kermit, you may tell the *other* Kermit to insist on a smaller packet
size.  Second, SHOW SEND PACK (like SHOW for other parameters that do nothing
but set defaults) reveals just the latest value defined -- whether by the SET
subcommand or by negotiating with another Kermit.  The diagnostic message for
SEND PACK > 94 is just a reminder that the only functional values are 20-94.

Subir Prasad wrote about Kermit for MVS/Roscoe ETSO:

> When we tried file transfer, MVS seemed to acknowledge and receive the file
> header, but it never could read or write the actual contents of a file.  It
> would give a "BAD COMMAND" error.
>
> We believe the problem is a disk allocation problem that Kermit-MVS has with
> ROSCOE ETSO.

However, I have heard from John Lundberg that "TSO Kermit actually seems to
work rather well in ROSCOE/ETSO as long as one doesn't try to create a host
data set name that violates ACF2's rule."

J M Hicks asked A Question about the Kermit Protocol:

> I was under the impression that characters between packets should be
> completely ignored.
>
> What ought Kermit to do?  If such characters between packets appear often,
> one end can give up due to all the bad packets it thinks it has received.

While the editor pointed out (correctly) that Kermits *should* ignore
characters between packets, half-duplex systems (such as IBM mainframes)
receive RECORDS, rather than PACKETS.  In such circumstances, an extra CR is
evidence of a lost or garbled packet, and, considering that some IBM mainframe
Kermit applications are unable to time out, it is clearly risky to ignore a
bare CR.
                                   John

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

Date: Tue, 22 Nov 1988 10:11:55 +0100
From: Andre' PIRARD <[e-mail]>
Subject: Kermit 370 Trailing Blanks Trimming
Keywords: Kermit-370

A proposal was accepted someday not to trim trailing blanks off variable
length text records sent by 370 Kermit.  I just found a little hitch to this
otherwise sensible decision.

God knows why, the CMS file system hates null-length records (as well as empty
files). CMS Kermit has consequently no other way to store a null line than to
make it a single blank. On its way back, this blank remains.

Software on micros can be sensitive to a record size being null and I used to
be pleased to see my long dated first tests of CMS Kermit get a file back
correctly, as opposed to what we used before.

It's an occasional nuisance only, but I wonder if it wouldn't be nice to
consider a record containing a single blank as the result of the above and, by
exception, send it with null length.  I can't think of another way to bypass
this "feature".  The "other way round" nuisance (single blanks converted to
nulls) should be much less frequent in my opinion.

Andr).

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

Date: Mon, 21 Nov 88 23:35:46 EST
From: Mark F. Proudman <[e-mail]>
Subject: VMS C-Kermit Dialing?
Keywords: C-Kermit 4E(070), setjmp(), C-Kermit/VMS, VAX/VMS

I have been trying to get C-Kermit's dialer (ckudia.c) working under VMS.
VMS does not like the setjmp() call within a setjmp that handles failures
during an exception (ie a failure to close the line after a timeout).  (This
is documented in the VAXC RTL manual).  Has anyone else re-implemented this
for VMS?

Thanks in advance.

Mark Proudman    uunet!attcan!sobeco!mfp
        [phone]
"It is agreed that the ice is thin here" - K&R.

[Ed. - Not us...  Various people have started working on VMS support in
C-Kermit, and no one -- to our knowledge -- has been able to complete the
job.  Is there anyone we don't know about who's working in this area???]

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

Date: Tue, 1 Nov 88 20:26:31 EST
From: ksmith@cubmol (Kenneth Smith)
Subject: C-Kermit Problems on SUNs with SUNOS Version 4
Keywords: C-Kermit 4E(070), SUN, SUNOS 4.0

Hardware:  Sun 3/160, connected to IBM-PC/AT and IBM-PC.

Software:  SunOS 4.0, C-Kermit 4E(70).
       MSKERMIT 2.31 on the IBM-PC/AT,
       MSKERMIT 2.29 on the IBM-PC.

Problem: When I attempt to send a file from either PC to the Sun3, the
transfer hangs at a random point.  When I send a file from the Sun3 to
either PC, transfer is normal.  The problem occurs when the PC's are
connected to the MTI multiplexer card.  The problem DOES NOT occur for a PC
connected to one of the Sun3 hardwired serial ports.  For a PC connected to
the multiplexer, file transfer was tested for failure at baud rates from
2400 to 19200. On the hardwired serial line, file transfer is successful at
19200 baud.

Comment: On a SUN3 running SUN UNIX version 3.4, and using an identical
multiplexer, we have no problems with C-Kermit.  It is possible that the
problem may be something on our multiplexer board, but I would like to know
if you have received any similar complaints about problems under SunOS 4.0,
or perhaps have even found a cure.

                        Ken Smith
                        Dept. of Biology
                        Computer Graphics Facility
                        854-6122
                        [e-mail]

[Ed. - Complaints galore, including from ourselves!  There are bugs in the
MTI and ALM handlers in SUNOS 4.0.  On our SUN-4's, we could only use Kermit
through Ethernet terminal servers.  Release 4.0.1 of SUNOS is supposed to
fix these problems, but we haven't tested it.]

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

Date: 28 Nov 88 22:21:12 GMT
From: execu![e-mail] (Dewey Henize)
Subject: Directory locking in C-Kermit?
Keywords: C-Kermit 4E(070), Directory Locking

Anyone out there have kermit installed on a Sun system, running SunOS4.0.1?

we are currently doing so, and things are basically working well, with
kermit version: C-Kermit, 4E(070) 29 Jan 88, 4.2 BSD

except for one small problem.  We seem to get the actual lock file built
just fine when we select a device [set line /dev/ttyx], but we still get
the message: Warning, write access to lock directory denied

I've checked the protections as well as I know to, and (at least temporarily)
have it set up exactly like tip (which connects fine, but without the
warning message), ie "-rws--x--x  1 uucp     daemon".

I would prefer not to have it suid anyhow, obviously.  Anyone out there
got a pointer for me?  All help appreciated, and thanks in advance.

Dewey Henize
execu!dewey

[Ed. - Like it says in the manual, the lock file directory must be publicly
readable and writable.  The only alternative is the suid business, which in
these days of worms and viruses, is to be avoided.]

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

Date:  Thu, 24 Nov 88 13:44 MST
From: [e-mail] (Rom Kieffer, Academic Computing Services)
Subject: VAX/VMS Kermit via x25
Keywords: VAX/VMS Kermit, X25

I am faced with a remote site trying to use kermit over a packet network, and
not having any idea about how to route traffic to the packet interface card
(DUP11) instead of the standard DZ11.

It is easy to connect via the carrier to the VAX, to start kermit and iniate
transfers, but the reverse has me stumped.  How does one start kermit, then
allocate a DUP11/PSI virtual circuit, connect via the packet carrier to the
remote system?

(decnet is out, the partner system is a NOS/VE Cyber 835, hence the kermit
approach)

If anybody out there has a better idea, we are not proud.

I have tried finding out whether there was a file transfer utility common to
VMS and NOS/VE, but to no avail so far. I have heard of RHF (Remote Host
Facility) but I cannot get any details about cost, availability or
performance.

any pointers are greatly appreciated.

 Rom Kieffer (403)-220-6210
 Manager, datacommunications
 Academic Computing Services
 The University of Calgary
 Calgary, Alberta
 CANADA T2N 1N4

 [e-mail]

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

Date: 11 Aug 1988 00:09:13 EST
From: [e-mail]
Subject: Response to Request of vt100 Setting Macro for MacKermit 0.9(40)
Keywords: MacKermit 0.9(40), VT100 Settings

The following is a Binhexed version of the setting on my SE with extended
keyboard.  The VT100 keypad and cursors are mapped correctly.  In addition, I
have implemented the six-key feature that exists in VT200 mode.  F9-F12
on the top row is encoded as <esc>, <BS>, <LF>, and (ESC>[26~, respectively.
Although this setting violates DEC convention by mixing VT100 and VT200
codes, I found it more powerful than a true VT220 when I am using EVE or EDT.

[Ed. - Thanks!  Your settings file has been added to kermit/b/ckmker.set,
which is a collection of settings files for MacKermit 0.9.]

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

Date: Thu, 11 Aug 88 16:14:36 PDT
From: [e-mail] (Mick Laver)
Subject: MacKermit vt100 Initialization Files
Keywords: MacKermit 0.9(40), Initialization File

Here are two MacKermit 0.9(040) vt100 initialization files to remap the
MacPlus and Mac II keypads, and a short MacWrite doc that explains how the
keys are mapped. All are in Binhex 4.0 format.  The files are:

    macvtdoc.hqx    Macwrite doc (11.2K)
    maciivt.hqx     Mac II vt100 init file (1.3K)
    macplvt.hqx     Mac Plus vt100 init file (1.3K)

Since the files are small I've stuck them one after the other below. I hope
someone finds them useful.

Mick Laver, C-010                 Internet:         [e-mail]
UCSD Academic Computing Center    UUCP:             ...!ucsd!mlaver
La Jolla, CA.92093                BITNET:        [e-mail]

[Ed. - Thanks!  These settings files have also been added to
kermit/b/ckmker.set.]

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

Date: Fri, 12 Aug 88 16:58:25 EDT
From: Bob Rahe <[e-mail]>
Subject: MacKermit Settings File
Keywords: MacKermit 0.9(40), VT100 Settings

  Someone asked for a settings file that would work with MacKermit 0.9(40) and
IBM mainframes as a VT100 through some kind of protocol convertor simulating a
327x terminal.  Here's one that I use to a VM/CMS system through a series-1
front end.  PF1 thru 9 are the keypad 1 thru 9 keys on a Mac+.  The Clear key
(and ENTER key) also work.  Probably not complete but does the (minimal) stuff
I need it to do.

  One source of info I remember using to get the codes right was the sample
init file for the PC version of Kermit.  See what he maps things to and you
can add whatever else you need.  This will give you a head start tho.

     Enjoy,
       Bob

[Ed. - Thanks!  These settings files have been added to kermit/b/ckmker.set
too.]

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

Date: Thu, 15 Dec 1988 09:54:00 EST
From: Christine M. Gianone <[e-mail]>
Subject: Kermit for Honeywell DPS-6/GCOS6?
Keywords: Honeywell, DPS-6, GCOS6

For several years, we have been distributing a version of Kermit for the
Honeywell DPS-6 GCOS6 operating system.  It was donated anonymously and
came without source code or documentation.  Does anyone have, or know of,
the source to this program, or any other Kermit program for the DPS-6?

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

Date: Thu, 1 Sep 88 10:16:35 EDT
From: [e-mail]
Subject: Kermit wanted for Burroughs B21 (Not B25)?
Keywords: Burroughs B21 Kermit

I'm looking for a Kermit that would run on the Burroughs B21 series.  This was
made for them by Convergent Technologies and runs an operating system called
BTOS.

I have used the B20 Kermit already available on a B25, but I don't think this
will work on the B21.

The B20 series is divided into two families, the older B21 and the newer B25.
They both run BTOS, but different versions, because the CPU is different.  I
have heard that the two families are mostly source-code compatible, but not
object-code compatible.

Does anyone know of a Kermit or any other terminal emulation program that will
run on the B21's?  Thanks.

Mike Ciaraldi
University of Rochester
ARPA:  [e-mail]
uucp:  ...rutgers!rochester!ciaraldi

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

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