Columbia Kermit/kermit.zip/e/info-kermit.txt

Text File | 2020-01-01 | 6MB | 132,434 lines

11-Jul-83 17:52:27-EDT,5881;000000000001
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; Mon 11 Jul 83 17:52:18-EDT
Date: Mon 11 Jul 83 17:49:18-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: KERMIT Available on the ARPANET
To: [e-mail], [e-mail], [e-mail]
cc: SY.FDC@CU20B, SY.DAPHNE@CU20B, OC.WBC3@CU20B, Chris@CUCS20, Hu@CUCS20,
    [e-mail], [e-mail], JS5A@CMCCTA, JO2F@CMCCTE
Keywords: ARPANET

KERMIT is a protocol for transferring files between computers of all sizes
over ordinary asynchronous telecommunication lines using packets, checksums,
and retransmission to promote data integrity.  Microcomputer implementations
of KERMIT (and some of the mainframe implementations) also provide terminal
emulation.  KERMIT is non-proprietary, thoroughly documented, well tested, and
in wide use.  The protocol and the original program implementations were
developed at Columbia University and have been shared with many other
institutions, some of which -- particularly Stevens Institue of Technology --
have made contributions of their own.

* KERMIT Implementations

KERMIT is presently available for the following systems:

    Machine             Operating System    Language
    -------             ----------------    --------
    DECSYSTEM-20        TOPS-20             MACRO-20
    DECsystem-10        TOPS-10             MACRO-10
    VAX-11              VMS                 Bliss-32, Macro-32
    IBM 370 Series      VM/CMS              IBM Assembler
    VAX,PDP-11,SUN,etc  UNIX                C
    PDP-11              RT-11               OMSI Pascal
    8080, 8085, or Z80  CP/M                ASM
    8086, 8088          PC DOS, MS DOS      IBM PC Macro Assembler
    Apple II 6502       Apple DOS           DEC-10/20 CROSS

All but the UNIX version and RT-11 versions use or imitate the TOPS-20 style
of user interface - command keyword recognition and completion, ?-help, etc.

The 8080 version runs on the DEC VT180, DEC Rainbow-100 (speeds up to 1800
baud only), DECmate II (CP/M), Heath/Zenith-89 and 100, Intertec Superbrain,
Apple II with Z80 Softcard, TRS-80 II (CP/M), Osborne 1, Osborne Executive,
Kaypro II, Vector Graphics, Ohio Scientific, Telcon Zorba, and others.  The
8086 version runs on the IBM PC and lookalikes (such as the Compaq portable)
and on the Heath/Zenith-100.

* Distribution Policy

The KERMIT software is free and available to all, sources and documentation
included.  Columbia University has been charging a reproduction fee of $100
for mailing tapes to recover its costs.  Other sites are free to redistribute
KERMIT on their own terms, and are encouraged to do so, with the following
stipulations: KERMIT should not be sold for profit; credit should be given
where it is due; and new material should be sent back to Columbia University
so that we can maintain a definitive and comprehensive set of KERMIT
implementations for further distribution.

* Distribution Mechanisms:

In addition to direct distribution from Columbia, KERMIT (all the versions
listed above, as they existed in June 1983) has been placed on the DECUS
VAX/VMS and RSX-11 SIG tapes, and may, at some point, be added to the DECUS
library for DEC-10's and -20s, and also distributed through IBM SHARE.  In
addition, the KERMIT distribution is available at Columbia to users of BITNET
on host CUVMA.

* ARPAnet Distribution:

Now KERMIT is available in its entirety to the ARPAnet community.  An up-to-
date KERMIT distribution area will be maintained on the Columbia University
Computer Science Department DECSYSTEM-20, a new machine which as just been
added to the ARPAnet.

The KERMIT distribution can be found at ARPAnet host COLUMBIA-20 in the
directory PS:<KERMIT>, accessible via anonymous FTP.  This is a large area,
containing sources (and in some cases binaries or hex) of all implementations,
plus documentation and various utility programs -- presently over 2000 DEC-20
pages in about 170 files -- so you probably don't want to take the whole area
blindly.  First, look at the short file 00README.TXT (starts with two zeros,
always appears at the top of a directory listing), which explains what is
where, and then take the parts that are of interest to you.  The KERMIT area
on COLUMBIA-20 should now be considered the definitive source for KERMIT on
the ARPAnet; other areas where parts of the KERMIT distribution have been
available will not necessarily remain current or complete.

The major documentation for KERMIT is the KERMIT USERS GUIDE and the KERMIT
PROTOCOL MANUAL, on line as USER.DOC and PROTO.DOC, respectively.  The User's
Guide gives an overview, general instructions for use, and details about the
use and installation of each version, including procedures for initially
downloading microcomputer versions from a mainframe host.  The Protocol manual
is supposed to describe the protocol in sufficient detail to allow new
implementations of KERMIT to be written.

KERMIT is an active project.  Features are being added to existing
implementations, bugs are fixed, new implementations are being developed.
Towards the end of August (when I return from vacation), I'll set up a KERMIT
mailing list for reporting bugs, trading information, announcing new versions,
etc.  In the meantime, send comments and inquiries to me at this ID, though I
won't be able to answer for a while.

* Disclaimer

No warranty of the software nor of the accuracy of the documentation
surrounding it is expressed or implied, and neither the authors nor Columbia
University, nor any other contributor, acknowledge any liability resulting
from program or documentation errors.

- Frank da Cruz
  Manager of DEC Systems
  Columbia University Center for Computing Activities
  CC.FDC@COLUMBIA-20
-------
11-Jul-83 18:27:14-EDT,4508;000000000001
Mail-From: CC.FDC created at 11-Jul-83 18:27:10
Date: Mon 11 Jul 83 18:27:10-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit-80 vs binary files
To: [e-mail], [e-mail], PS1.SCOR@CU20B
cc: [e-mail], [e-mail], OC.WBC3@CU20B
Keywords: Kermit-80

Several people have been asking (or complaining) about binary file transfer in
KERMIT-80.  The following comments attempt to explain it, and propose a
possible improvement.

Bill Catchings, the original author of Kermit-80, has explained to me how the
EOF handling business works.  There are really three cases, of which only two
are actually accounted for in the code.  CP/M determines the EOF in one of two
ways -- for a text file, the EOF is at the first ^Z in the last block of the
file; for a binary file the EOF is at the end of the last block, regardless of
the contents of the last block.  There is no way to tell a text file from a
binary file, except perhaps by the filetype conventions.  Applications that
deal with text files -- the TYPE command, text editors, etc, use the ^Z
convention, whereas applications that deal with binary files (like the CP/M
mechanism to run a program) do not.  KERMIT, however, must deal with both
binary and text files.  Since KERMIT cannot distinguish between the two, it
relies on on the user to tell it.  By default, it uses the ^Z convention, but
if the user gives the SET CPM-CREATED-FILE command, it will not.

So far, so good.  But now the problem arises of what to do with incoming files.
An original goal of KERMIT was to allow users of the DEC-20 to send all their
DEC-20 files -- binary and text -- to the micro with a single wildcard SEND
command, and to be able to send them back to the DEC-20 the same way.  Since a
binary file is likely to have a ^Z somewhere in the last block, we can't send
it back as a CPM-CREATED-FILE.  But it would also be wrong to send back the
whole final block, because a CPM block boundary might not correspond the
actual end of file on the foreign sytem.  So a new convention was adopted by
which KERMIT-80 fills out the last block of an incoming file with ^Z's, and
then during normal sending, all ^Z's at the end of the last block are not
sent on the assumption that they are the result of this padding.  This allows
a mixture of binary and text files to be received and sent back in wildcard
transfers with no special action by the user.

This scheme, however, prevents complete transmission of ANY file from the CP/M
system that happens to have any number (1 to 127) ^Z's at the end of its final
block.  Normal transmission will discard them because they're at the END of
the block, and CPM-CREATED-FILE transmission will discard them because they
are IN the block.  Thus, the file options should actually be:

1. TEXT        (i.e. CP/M-created text) First ^Z in last block is EOF.  This
               will apply whether the file is created by CP/M or from outside.

2. BLOCK       (i.e. CP/M binary) Send all blocks in their entirety (can't do
               this now).

3. EXTERNAL    Strip all trailing ^Z's in last block when sending (this is the
               current default).

These all apply when SENDing files from the CP/M system.  When receiving, the
action is always the same -- pad the last block with ^Z's, unless the file
happens to end on a block boundary, in which case the end is unambiguous and no
^Z's are needed.

Explaining this to ordinary users would be pretty tough, but I think the
present default works in most cases.  It might be worth establishing some
mechanism to allow the user to change the default, either by SET command or an
assembly option, in case the user is dealing more commonly with CP/M files
than with host files.  It might even be worth considering having KERMIT-80
attempt the proper mode based on the file type (.COM would use BLOCK mode,
.EXE would use EXTERNAL mode, anything else would use TEXT mode? -- sort of a
Kermit-80 equivalent to Kermit-20's "auto-byte" mode of operation).  This might
be nicely meshed with an INQUIRE option for SEND, in which KERMIT-80 would
prompt the user with the name of each file to send, let the user say whether to
send or skip it, and then allow an opportunity to override the default file
mode.  Actually, this is such a good idea I might go ahead and put an INQUIRE
feature into KERMIT-20... (remember the old /I option on PDP-11 PIP?)

- Frank
-------
11-Jul-83 19:09:19-EDT,1519;000000000011
Mail-From: NOT-LOGGED-IN created at 11-Jul-83 19:09:11
Return-Path: <guyton@rand-unix>
Received: from rand-unix by COLUMBIA-20.ARPA with TCP; Mon 11 Jul 83 19:09:13-EDT
Date: Monday, 11 Jul 1983 16:07-PDT
To: Frank da Cruz <cc.fdc@COLUMBIA-20>
Cc: guyton@rand-unix
Subject: pc kermit & Unix kermit -- bugs!
From: guyton@rand-unix
Keywords: UNIX Kermit, MS-DOS Kermit
Cross-Ref: PC Kermit, IBM Kermit, MS-Kermit (see also MS-DOS Kermit)

Hi,

I just spend many hours tracking down a few problems in
using IBM-PC Kermit to talk w/Unix (4.1BSD).


   1) The "twenex" version of Kermit.c does NOT work if
      compiled with "UNIX" defined.

   2) The old "UX" version of unix kermit does not work with the
      IBM PC implementation.  After some searching, I found the
      problem was that the unix code added a null at the end of
      the filename packet, and the PC rejected it.  Once I commented
      out the line that added the null, everything worked again.  I
      have a suspicion that the unix code assumes the presense of
      an ending null in the filename packet.  I'll track it down
      further if nobody else has already.

   3) The version of kermit.asm on isib:<info-pc>kermit.asm has
      heath/ansi style ins/del line added to the PC version.  Just
      noticed that the columbia:<kermit> seems to be older.

If nobody else is already working on this, I am willing to ...

   a) Find out why the kermit.c program no longer works under Unix.
   b) Change the unix program (and/or kermit.c) to work without the
      trailing null at the end of filenames.

-- Jim
11-Jul-83 19:33:38-EDT,1654;000000000001
Mail-From: CC.FDC created at 11-Jul-83 19:33:35
Date: Mon 11 Jul 83 19:33:35-EDT
From: Frank da Cruz <[e-mail]>
Subject: Yet one more problem with Kermit-80
To: [e-mail]
cc: OC.WBC3@CU20B, [e-mail], [e-mail],
    [e-mail], CU.HDE@CU20B
Keywords: Kermit-80

We noticed this one today on the VT180...  Bernie, since you converted VT180
to run "generically", it no longer handles ^S typed at the keyboard correctly.
Diagnosis: in TELNET, the tight little CHRLUP (character loop) looks like
this:
    chrlup:    call prtchr    ; Check port
        call conchr    ; check console
         jmp kermit    ; (if escape character was typed)
        jmp chrlup    ; more...

The problem is that when lots of characters are coming in the port, the
PRTCHR routine hardly ever returns -- it has its own internal loop and
doesn't return until a character-available test fails.  First I thought
switching the order of the calls in CHRLUP would raise the priority of
console input enough to let ^S's, ^O's, etc, to get through (this trick
worked on IBM PC Kermit), but no...  So then I tried making PRTCHR just
return (RET) instead of looping back on itself -- I figured this might slow
things down a bit, but it should have worked.  It didn't -- I couldn't
even make the program transmit the first character.  I'll fool with it
some more, maybe I made a dumb mistake...  But in case I don't get back to
you about this, add it to the list of things to be fixed in KERMIT-80.

(By the way, the reason this was never a problem before, of course, was that
VT180 Kermit was totally interrupt driven...)

- Frank
-------
11-Jul-83 19:44:38-EDT,1631;000000000001
Mail-From: CC.FDC created at 11-Jul-83 19:44:37
Date: Mon 11 Jul 83 19:44:37-EDT
From: Frank da Cruz <[e-mail]>
Subject: Re: pc kermit & Unix kermit -- bugs!
To: [e-mail]
cc: [e-mail]
In-Reply-To: Message from "guyton@rand-unix" of Mon 11 Jul 83 19:09:19-EDT
Keywords: UNIX Kermit, MS-DOS Kermit

Thanks for the report!  The file KERMIT.C is the result of my taking the
version that's being run by our CS department (which is in the Kermit
distribution as UX*.*, a collection of files), combined all into one file,
fixed several bugs (possibly including the null at the end of the filename?),
added lots of comments (in violation of the spirit of UNIX), and rewrote
the rpack routine, which was so deeply nested in the original that it
broke the PCC compiler on our DEC-20.  I also conditionalized it, and tested
it on our -20 with the TOPS-20 conditional on, and it worked OK.  Our CS
folks then tested it on their VAX UNIX systems and it didn't work, but they
never had a chance to figure out why, and continue to use their old versions.
They, and I, would be grateful if you could make KERMIT.C work under UNIX,
so we could flush the UX*.* source once and for all, and then begin adding
in other parts of the protocol (like error packets, server mode, etc) to the
new common source.

- Frank

P.S. I just took a look, and sure enough I left a "len++;" in sfile under
the UNIX conditional in case UNIX needed that for something -- someone must
have added it for some reason!  UNIX-to-UNIX transfers?  Anyway, that's
the source of the extraneous character at the end of the filename...
-------
12-Jul-83 18:08:14-EDT,5648;000000000001
Mail-From: CC.FDC created at 12-Jul-83 18:08:12
Date: Tue 12 Jul 83 18:08:12-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit-80 problems
To: [e-mail], OC.WBC3@CU20B
cc: [e-mail], [e-mail], OC.SITGO@CU20B,
    [e-mail]
Keywords: Kermit-80

As I prepare to leave for a month on vacation, I leave behind this list of
problems with Kermit-80, in hopes that someone might fix them before I get
back...  I probably didn't think of all the problems that people have
mentioned to me in past months, but if all these were fixed, we'd have a
pretty good program.  I anyone knows of problems I forgot, please add them
to the list...  - Frank

---------

Problems with KERMIT-80.


1. Two separate sources:

   CPMKERMIT.ASM (old, pre-generic)
   CPMGENERI.ASM (incorporates Bernie's generic support, CP/M 3.0 support)

The old one is kept around because

   a. At least one implementation -- Osborne 1 -- doesn't work when built from
      the new one.

   b. Many others have never been tested.

   c. VT180 interrupt-driven support has better terminal emulation than the
      "generic" VT180 support in the new version.

These problems need fixing.  The ARPAnet connection might get some of the
previously untested versions tested.  The author of the Osborne support (Chuck
Bacon at NIH) is looking to see why the Osborne support is busted & will try
to fix it.

2. Mentioned above: VT180 terminal emulation doesn't sample the keyboard often
enough, so when a lot of text is coming in from the host, ^S, ^O, etc, don't
get through, and in fact, they mess things up a lot.  Oddly enough, the exact
same code works ok on the Rainbow, probably because the tight loop inside
PRTCHR fails to find a character more often because of the slow speed of the
Rainbow due to Z80/8088 handshaking.

3. The incredibly ugly IF...ENDIF structure of the program makes it almost
impossible to read.  Bernie has long planned to reorganize it a la MODEM to
make a kind of system-independent core, to which a custom template can be
filled out and appended for each system/terminal/etc.  Doing this is one
thing, documenting it so any CP/M user can construct a working Kermit-80 for a
new machine is yet another, and testing the result on all the previously
supported machines still another!

(so much for the major problems, now some "minor" issues)

4. Local echo doesn't work in 3.2, at least not in certain implementations.

5. Cursor positioning is screwed up in some implementations -- various users
have complained that the "Kermit-80>" prompt after a file transfer overwrites
the filename line.

6. Lower case letters in an incoming file header should be raised to upper
case -- ever tried getting a file from UNIX and then referring to it?
Also, any nulls in the filename should be discarded (UNIX kermit sometimes
sticks a null at the end for some reason).

7. A nak for the next packet is NOT an ack for the current one if the
current one was a Send-Init.

8. Check for packet number wrap-around when checking for things like "is this
a nak for the previous packet?" when comparing packet numbers.

9. May want to verify other side's Send-Init parameters more rigorously and
force them to legal values if illegal.  I recently added this to Kermit-20;
before I did, it wouldn't talk to the Apple, which was sending garbage in
certain fields.

10. Junk in command buffer after a file transfer (or is it just an
unsuccessful file transfer?) always prevents the first command after the
transfer from being parsed.

11. It's presently impossible for Kermit-80 to send ANY file that ends with a
string of one or more ^Z's (right-adjusted on the end of the last block).
Need to be able to specify TEXT files (EOF is at first ^Z in last block), BLOCK
files (send all blocks, ignore any ^Zs), EXTERNAL files (the kind that
KERMIT-80 creates, with the last block padded out with ^Zs).  Perhaps add the
equivalent of "auto-byte", with .COM files being sent in BLOCK mode, .EXE files
in EXTERNAL mode, all others in TEXT mode?  Combined with an INQUIRE feature,
to ask about each file in a wildcard send?

12. File stepping is limited to something like 16 files, because the only way
Bill could figure out how to do it was to chain all the FCB's together in
memory beforehand, and he left space for 16 FCB's.  Better to figure out how
to step through files dynamically, or else make the FCB area bigger.  See what
any of the various public domain directory-listing programs (or MODEM) do.

13. Probably all versions should allow ^C as a synonyn for C when closing a
telnet connection.

14. KERMIT-80 (and all the other micro versions) badly need to be able to send
a BREAK signal.  You need it to talk to IBM systems, and to get the attention
of various kinds of port switchers, multiplexers, etc.

15. Fix logging function.  Most implementations don't have it; those that do
lose characters.  Log to a big area in memory; when buffer gets nearly full,
send ^S, dump it to disk, send ^Q.  Again, look at MODEM, see what it does.

16. Retry count still isn't updated in every case.

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

Once all these problems are fixed, or most of them, we can begin adding
enhancements (printer support, init files, etc) and new protocol features
(8th-bit-quoting, fancier checksums, more interactions with server,
asynchronous events during file transfer, etc).

Naturally, if any one of you feels like tackling any of this, please
coordinate with the others.  Have fun while I'm gone!  - Frank
-------
12-Jul-83 18:55:00-EDT,3333;000000000011
Mail-From: NOT-LOGGED-IN created at 12-Jul-83 18:54:47
Return-Path: <[e-mail]>
Received: from SRI-KL.ARPA by COLUMBIA-20.ARPA with TCP; Tue 12 Jul 83 18:54:49-EDT
Date: Tue 12 Jul 83 15:48:00-PDT
From: [e-mail]
Subject: KERMIT INFO
To: [e-mail]
cc: [e-mail]
Keywords: Kermit Info

    Frank,
        I read your KERMIT message with great interest, though
    of course I have a few hundred questions to ask you about it.
    My fingers will never last, so I'll hit the high points. First,
    I'm  HEINZE@SRI-KL on the ARPANET for return mail. We are currently
    writing the code right now (as I speak or type, so to say) to
    design and implement a microcomputer network of about 200
    Commodore 64 microcomputers. It's a very ambitious project but
    we have some of the most capable people in the Silicon Valley
    area working on it. I have talked to Robert Maas at MIT and
    he was of no help in our effort. He had some incipient code that
    "never did work for us", so rather than pursue that route we went
    else where.
        To the best of my knowledge the only good working network
    available for Commodore microcomputers was writeen by Steve Punter
    in Ontario Canada and presently being marketed by TPUG. I have
    written a letter to Punter asking all the obvious questions. I
    should have written the letter on the net so you could read it
    that would have saved me a lot of time. I won't reproduce the
    letter hear but try to hit some highlights. I asked Steve all the
    basic implementation questions. What hardware configuration is
    needed? Does your "Appple Kermit" run on a 16K Apple? I would
    doubt that it would, how much memory does it take? We will have
    to re-code the Apple code to run on a Commodore 64 micro, any
    info you have on modify KERMIT code would be helpful. How much
    memory does KERMIT require? Is there a Microsoft Basic version
    of KERMIT which will run on the original PET computers? If so,
    what DOS and ROM version (as every good Commodore owner knows,
    there's only a hundread or so implementations of CBM computers!!)
        As you can see, I need a lot more info on KERMIT before
    I can even decide what, how or whether it really does anything
    that we are interested in. I'm supposed to be getting a complete
    listing of the KERMIT info from BILLW @ SRI-KL today. I will need
    to look at the KERMIT USERS GUIDE, etc to get additional info. I
    don't completely understand your $100 tape fee, seems outrageously
    excessive to me.
        After we get our network up and operating I will try to
    remember to pass the phone number and info on to you so that you
    can access the network. We have an extremely hard working group
    on this project (totally unrelated to SRI) and I feel sure that
    we will be successful in the long run.
        Our society is SPHINX SOCIETY Inc. [phone]. POC is
    Bill MacCracken, or my self, Rich Heinze [phone] in Menlo
    Park. MacCracken is the current monitor for SPHINX and is very
    knowledgeable about CBM computers. We have several people up and
    running on-line with 300 baud modems but our network is just being
    designed and the code is being written now. Our immediate goal is
    to get SPHINX up and on-line ASAP and I sincerely hope that this
    will happen prior to Sept 1983.
        More later, Rich
-------
12-Jul-83 19:35:18-EDT,1331;000000000001
Mail-From: CC.FDC created at 12-Jul-83 19:35:17
Date: Tue 12 Jul 83 19:35:17-EDT
From: Frank da Cruz <[e-mail]>
Subject: Re: KERMIT INFO
To: [e-mail]
In-Reply-To: Message from "[e-mail]" of Tue 12 Jul 83 18:55:00-EDT
Keywords: Kermit Info

Kermit is not a network -- it's comparable to MODEM, except it works on a
wider variety of computers, mainframes included.  No special hardware is
required, beyond RS232 serial interface.  The Apple code comes from Stevens
Institute of Technology.  It's written in CROSS language on the -10 or -20
and downloaded.  I have no idea how much memory is required to run it; they
didn't mention anything about that in their documentation.  You can call
Nick Bush at Stevens and discuss it with him; I'm sure he wouldn't mind.  The
number is 201-420-5457 (New Jersey).

You wouldn't think the $100 fee was outrageous if you had just produced over
300 tapes, packed them up, licked the stamps & labels, paid the postage
(including first class postage to places like Sweden, Australia, Chile).  We
couldn't afford the beating any more, not to mention the way our systems
programmers were being turned into highly paid shipping clerks.  Now we can
afford to hire operators & clerks to do the tape sending and let us get on
with the development.

- Frank
-------
13-Jul-83 13:47:24-EDT,1110;000000000001
Mail-From: CC.FDC created at 13-Jul-83 13:47:21
Date: Wed 13 Jul 83 13:47:21-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit distribution mailing list
To: [e-mail]
Keywords: Distribution List

There is now an INFO-KERMIT mailing list at CUCS20.  If you have received
this message, you're on it, and it works.  This list should be for people
who maintain or install KERMIT at their site, or who are interested in
discussing it.  For now, I'm limiting to CCNET members, but when I get back
from vacation and can manage it better, I'll expand it to include the
ARPANET as well.  Here's the contents of the list, which is in the file
CUCS20::<KERMIT>INFO-KERMIT.DISTRIBUTION:

CC.FDC@CUCS20, CC.Daphne@CUCS20, US00@CMCCTF, JS5A@CMCCTA, JO2F@CMCCTF, -
CCIMS.Beecher@CUTC20, OC.WBC3@CU20B, Gumpf@CWR20B, DK32@CMCCTF, GM0W@CMCCTF, -
OC.SITGO@CU20B, OC.Garland@CU20B

If you want to be taken off, or if you know anyone else who wants to be
added, let me know.  Anyone on CCNET can send mail to everyone on this list
simply by sending a message to INFO-KERMIT@CUCS20.

- Frank
-------
13-Jul-83 13:58:35-EDT,677;000000000001
Mail-From: CC.FDC created at 13-Jul-83 13:58:32
Date: Wed 13 Jul 83 13:58:32-EDT
From: Frank da Cruz <[e-mail]>
Subject: Rainbow Kermit
To: [e-mail]
cc: [e-mail], OC.WBC3@CU20B
Keywords: DEC-Rainbow Kermit
Cross-Ref: Rainbow Kermit (see also DEC-Rainbow Kermit)

I have a user with a Rainbow who has some kind of direct-connect modem,
which Kermit won't work with.  It appears to insist on having pin 20 (DTR)
high.  The terminal firmware keeps DTR high, and so does Poly-XFR.  But
Kermit does not.  I advised the user to wire pin 20 to pin 5 or some other
pin that is normally high.  Meanwhile, there's nothing we can do, because
there's no way to talk to the UART, right?  Oh well...  - Frank
-------
14-Jul-83 01:48:12-EDT,865;000000000011
Return-Path: <guyton@rand-unix>
Received: from rand-unix by COLUMBIA-20.ARPA with TCP; Thu 14 Jul 83 01:48:08-EDT
Date: Wednesday, 13 Jul 1983 21:38-PDT
To: Frank da Cruz <cc.fdc@COLUMBIA-20>
Cc: guyton@rand-unix
Subject: Re: kermit.c
From: guyton@rand-unix
Keywords: C-Kermit, UNIX Kermit

Ok, I have kermit.c working again under Unix.  Got it working
under 4.1bsd and just tested it on our V7 system.

The major problem was the ioctl's were just wrong.  Along
with a couple other minor bugs that I fixed while I was at
it (defaults to non-image mode now for Unix, since there is
a command line option to go to image mode, yet none for the
opposite effect).

The next msg to you will be the source.  Let me know if you
don't get all of it (it is getting pretty long).

-- Jim

p.s. I'll send an annotated diff listing when I get back to
work and a 9600 baud connection!
14-Jul-83 10:06:08-EDT,845;000000000011
Return-Path: <[e-mail]>
Received: from PARC-MAXC.ARPA by COLUMBIA-20.ARPA with TCP; Thu 14 Jul 83 10:06:04-EDT
Date: Thu, 14 Jul 83 07:05 PDT
From: [e-mail]
Subject: Re: KERMIT Available on the ARPANET
In-reply-to: "[e-mail]'s message of Mon, 11 Jul 83
 17:49:18 EDT"
To: Frank da Cruz <[e-mail]>
Keywords: ARPANET, MODEM

Frank,

I was interested in any compatibility between KERMIT's protocol and Ward
Christensen's MODEM protocol for file transfer.  Do they have the same
protocol?  Can KERMIT on the VM/CMS system talk to a MODEM program?

I have a Dolphin workstation that I would like to have talk to the IBM
system running VM/CMS.  One approach would be to have the workstation
use the KERMIT protocol and get the IBM KERMIT system.

Any thoughts would be appreciated.

Pete
14-Jul-83 13:10:22-EDT,1226;000000000001
Mail-From: CC.FDC created at 14-Jul-83 13:10:21
Date: Thu 14 Jul 83 13:10:21-EDT
From: Frank da Cruz <[e-mail]>
Subject: Re: KERMIT Available on the ARPANET
To: [e-mail]
cc: [e-mail]
In-Reply-To: Message from "[e-mail]" of Thu 14 Jul 83 10:06:08-EDT
Keywords: ARPANET, MODEM

No, MODEM and KERMIT are not compatible -- KERMIT was developed in ignorance
of MODEM, but we've learned about it since.  One of the shortcomings of MODEM
is that it could never communication with an IBM mainframe because it sends
binary data bare; any binary data that happens to be a CR, LF, DEL, NUL, ^S,
^Q, etc, would be swallowed by the communcation hardware and the application
on the IBM system would never see those characters -- the data would be lost
and the checksum would be wrong (or in the wrong place, which amounts to the
same thing).  KERMIT, on the other hand, sends control characters by
prefixing them & then translating to printable equivalents, and works fine
on every system we've brought it up on.  If you need any more information,
you can dig through the manuals, or else wait a month until I get back from
vacation; I'll be glad to help then.  - Frank
-------
14-Jul-83 13:32:10-EDT,335;000000000001
Return-Path: <SY.FDC@CU20B>
Received: from CU20B by CUCS20 with DECnet; Thu 14 Jul 83 13:32:07-EDT
Date: Thu 14 Jul 83 13:32:51-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Archive
To: Info-Kermit@CUCS20

This is just to test if mail to Info-Kermit gets archived correctly in
CUCS20::PS:<KERMIT>MAIL.TXT.  - Frank
-------
14-Jul-83 14:11:27-EDT,870;000000000001
Mail-From: CC.FDC created at 14-Jul-83 14:11:19
Date: Thu 14 Jul 83 14:11:19-EDT
From: Frank da Cruz <[e-mail]>
Subject: UNIX Kermit
To: [e-mail]
Keywords: UNIX Kermit
Cross-Ref: C-Kermit (see also UNIX Kermit)

In [COLUMBIA-20]PS:<KERMIT>KERMIT.C, you'll find a version of UNIX Kermit that
has fixes from Jim Guyton at Rand-UNIX.  He says it works fine under 4.1bsd and
V7, but we haven't tested it here yet; I send this off now because I'm going on
vacation for a month, will be back Aug 15.  While I'm gone, you might find that
new versions of PC Kermit appear in the same directory from time to time.  The
contact for PC Kermit is CC.DAPHNE@COLUMBIA-20 (Daphne Tzoar); I'll ask her to
keep you informed about new developments.  After I get back, I'll probably set
up an INFO-KERMIT mailing list; the announcement of a couple days ago has
already brought in a lot mail.  - Frank
-------
19-Jul-83 11:08:47-EDT,868;000000000005
Mail-From: CATTANI created at 19-Jul-83 11:08:41
Date: Tue 19 Jul 83 11:08:41-EDT
From: Bob Cattani <[e-mail]>
Subject: Re: Kermit for Vax
To: [e-mail]
cc: [e-mail], [e-mail]
In-Reply-To: Message from "guyton@rand-unix" of Mon 18 Jul 83 17:48:59-EDT
Keywords: UNIX Kermit

Wonderful!  I just tried it and everything worked fine.  Let's consider
this our current "standard" UNIX-C version of Kermit.

You included a good point in one of your suggestions for improvements.
It may be very useful to be able to specify a destination filename or
directory name (compatible with the remote system) where the remote
kermit is to put the files it receives.  Of course, there are a whole
set of related issues concerning what should be done about illegal
characters in filenames - aren't networks terrible?
-Bob
-------
19-Jul-83 22:07:06-EDT,2656;000000000015
Return-Path: <CERRITOS@USC-ECL>
Received: from USC-ECL by COLUMBIA-20.ARPA with TCP; Tue 19 Jul 83 22:06:59-EDT
Date: 19 Jul 1983 1720-PDT
From: Bruce Tanner <CERRITOS@USC-ECL>
Subject: Re: Kermit-80 problems
To: cc.fdc@COLUMBIA-20, EIBEN@DEC-MARLBORO
In-Reply-To: Your message of 12-Jul-83 1512-PDT
Keywords: Kermit-80

Two fixes:

Local echo was broken due to the BDOS trashing reg E in most generic Kermits.
Put a push d/pop d around the "call prtout" at conchr + 12 lines.

Kermit-80 gets confused when sending files that are a multiple of 128 records.
The getfil routine will set filerc to zero in this case, but inbuf expects
filerc to be always positive.

Here's a filcom of the fix:


2)25        sta filerc        ; Save as the file record count.
2)        lda fcb+22H        ; Get R1.
2)        rlc            ; Shift over one bit.
2)        ora b            ; Or in the high order from R0.
2)        sta fileex        ; Save it as the file extent.
**** @gtnfl3 + .5
1)25        mvi c,0            ; [BT] assume no correction
1)        jnz gtnfl4        ; [BT] positive record count
1)        mvi a,80H        ; [BT] make record count 128
1)        mvi c,1            ; [BT] account for new record count
1)    gtnfl4:    sta filerc        ; Save as the file record count.
1)        lda fcb+22H        ; Get R1.
1)        rlc            ; Shift over one bit.
1)        ora b            ; Or in the high order from R0.
1)        sub c            ; [BT] correction if file is multiple of 128 records
1)        sta fileex        ; Save it as the file extent.
*****************************************************************************


This is an alternate fix. I haven't tested it.
*****************************************************************************
1)24        sui 1            ; Decrement it.
1)        sta filerc
1)        jnz rskp        ; If not the last packet then retskp.
1)        lda fileex        ; Any more left?
1)        cpi 0
1)        jz inbuf3
1)        sui 1
1)        sta fileex
1)        mvi a,80H        ; Get a 128.
1)        sta filerc        ; Start the record count over.
1)        jmp rskp
1)    inbuf3:    mvi a,0FFH
1)        sta eoflag        ; Set the EOF flag.
1)        jmp rskp
**** @inbuf2 + 8.5
2)24        ora a            ; [BT] test for zero
2)        jz inbuf4        ; [BT] yes, skip
2)        sui 1            ; Decrement it.
2)        sta filerc
2)        jnz rskp        ; If not the last packet then retskp.
2)        jmp inbuf5
2)    inbuf4:    push b            ; [BT] save BC
2)        mvi b,7FH        ; [BT] account for buffer already read
2)        jmp inbuf6
2)    inbuf5:    push b            ; [BT] save BC
2)        mvi b,80H        ; [BT] reset record count to 128
2)    inbuf6:    lda fileex        ; Any more left?
2)        cpi 0
2)        jz inbuf3
2)        sui 1
2)        sta fileex
2)        mov a,b            ; [BT] get record count
2)        sta filerc        ; Start the record count over.
2)        jmp rskp
2)    inbuf3:    mvi a,0FFH
2)        sta eoflag        ; Set the EOF flag.
2)        pop b            ; [BT] restore BC
2)        jmp rskp

-Bruce
-------
21-Jul-83 18:36:20-EDT,7676;000000000005
Return-Path: <CERRITOS@USC-ECL>
Received: from USC-ECL by COLUMBIA-20.ARPA with TCP; Thu 21 Jul 83 18:36:05-EDT
Date: 21 Jul 1983 1531-PDT
From: Bruce Tanner <CERRITOS@USC-ECL>
Subject: MAC80 6A
To: EIBEN@DEC-MARLBORO, CC.FDC@COLUMBIA-20
In-Reply-To: Your message of 21-Jul-83 0609-PDT
Keywords: MAC80

Is that all you want? Relational operators in expressions and ? @ in symbols
are in the folling .cor files. Other changes:
$ is now non-significant in symbols (this is what MAC does)
local symbols are now ??nn instead of L$$nn (like MAC)
macro handling is fixed up a bit.

These (and probably future) .cor files are based of MAC80 version 6, so
keep it around as a base until the next major release.

Is the VT180 BIOS on the <CPM> tape? I just got it today. It's terrific!

MACLIB reading is a good possibility, I think making a .SYM file is a good
idea. Should it be a seperate switch, made when a listing is made or
made always?

Z80 mnemonics are something I've kinda kept away from; I learned 8080 code
when there was no Z80. Oh well, it's not out of the question, merely a matter
of time and effort and a few compatability problems with the way it works now.

Keep thinking of things. What about removong the restriction of : after labels?
How about a REPT statement? IRP and friends?

-Bruce

;********** M80UNV.COR *************
 REP 29/1
    M80MAJ==6
    M80MIN==0
    M80EDT==67

    ;MACRO TO DO TITLE AND VERSION NUMBER

    DEFINE    .TITLE    (NAME,V,E)<
    TITLE    NAME 8085 Cross Assembler - V(E)
    IFIDN    <NAME> <MAC80>,<
    LOC    .JBVER
    BYTE    (3)M80WHO (9)M80MAJ (6)M80MIN (18)M80EDT
    RELOC>
    >
 WIT
    M80VER==6
    M80MIN==1
    M80EDT==70

 SUM 217297
;*********** MAC80.COR **************
 REP 9/1
        SEARCH M80UNV,JOBDAT
        .TITLE    (MAC80,\M80MAJ,\M80EDT)
 WIT
        SEARCH M80UNV,JOBDAT,MACTEN
        TITLE.    (M80,MAC80,8085 Cross Assembler)
        M80TTL
        M80137

 SUM 120325
;*********** MAC80A.COR *************
 REP 8/1
        SEARCH    M80UNV

        .TITLE    (MAC80A,\M80MAJ,\M80EDT)


 WIT
        SEARCH    M80UNV,MACTEN

        TITLE.    (M80,MAC80A,8085 Cross Assembler)
        M80TTL
        M80PTX
 REP 6/4
        PUSH    T4,["$"]    ;FLAG TOP OF STACK
 WIT
        PUSH    T4,[DOLLAR]    ;FLAG TOP OF STACK
 INS 17/4
        CAIE    I,"<"        ;SPECIAL CASE TEST FOR <=,>=,<>
        CAIN    I,">"
        PUSHJ    P,OP2CH        ;CHECK FOR 2 CHAR OPCODE
 REP 42/4
    DODT20:    CAMN    TOK,[SIXBIT/NOT/]    ;THE OTHER UNARY OPERATOR?
        JRST    DODT23            ;YES
        CAME    TOK,[SIXBIT/HIGH/]
        CAMN    TOK,[SIXBIT/LOW/]
 WIT
    DODT20:    CAME    TOK,[SIXBIT/NOT/]    ;THE OTHER UNARY OPERATOR?
        CAMN    TOK,[SIXBIT/HIGH/]
        JRST    DODT23            ;YES
        CAME    TOK,[SIXBIT/LOW/]
        CAMN    TOK,[SIXBIT/LO/]
 REP 5/5
        CAIN    I,"$"        ;NO LAST OP?
 WIT
        CAIN    I,DOLLAR    ;NO LAST OP?
 REP 10/5
        CAIN    I,"$"        ;NOT THERE?
 WIT
        CAIN    I,DOLLAR    ;NOT THERE?
 REP 11/6
        CAIN    I,"$"        ;ALL DONE?
 WIT
        CAIN    I,DOLLAR    ;ALL DONE?
 DEL 19/6



 INS 51/6

    OP2CH:    PUSH    P,T1
        PUSH    P,T2
        MOVE    T1,I        ;SAVE I
        MOVE    T2,I
        SUBI    T2,40        ;SIXBIT
        LSH    T2,^D30        ;SHIFT TO 1ST BYTE
        PUSHJ    P,SNEAK        ;LOOK AT THE NEXT CHARACTER
        SKIPE    TOK        ;NON-BREAK?
        JRST    OLDI        ;YES, NOT A 2 CHAR OPCODE
        MOVE    I,SNEAKI    ;GET THE BREAK CHAR
        SUBI    I,40        ;SIXBIT
        DPB    I,[POINT 6,T2,11]
        CAIE    I,'>'
        CAIN    I,'='        ;GOOD 2ND CHAR?
        PUSHJ    P,INCH        ;YES, USE IT
    NEWI:    SKIPA    I,T2
    OLDI:    MOVE    I,T1        ;RESTORE I
        POP    P,T2
        POP    P,T1
        POPJ    P,

 REP 8/7
    E    "&",<AND OP,T1>,4
    E    "!",<OR    OP,T1>,5
    E    "_",<LSH OP,(T1)>,2
    E    "#",<SETCM OP,T1>,1
    E    'AND   ',<AND OP,T1>,4
    E    'OR    ',<OR OP,T1>,5
    E    'MOD   ',<PUSHJ P,EXMOD>,2
    E    'XOR   ',<XOR OP,T1>,5
 WIT
    E    "&",<AND OP,T1>,5
    E    "!",<OR    OP,T1>,6
    E    "_",<LSH OP,(T1)>,2
    E    "#",<SETCM OP,T1>,1
    E    'AND   ',<AND OP,T1>,5
    E    'OR    ',<OR OP,T1>,6
    E    'MOD   ',<PUSHJ P,EXMOD>,2
    E    'XOR   ',<XOR OP,T1>,6
 REP 19/7
    E    'HIGH  ',<LDB OP,[POINT 8,T1,27]>
    E    'LOW   ',<LDB OP,[POINT 8,T1,35]>
 WIT
    E    'HIGH  ',<LDB OP,[POINT 8,T1,27]>,7
    E    'LOW   ',<LDB OP,[POINT 8,T1,35]>,7
    E    'LO    ',<LDB OP,[POINT 8,T1,35]>,7
    E    'EQ    ',<PUSHJ P,RELEQ>,4
    E    "=",<PUSHJ P,RELEQ>,4
    E    'NE    ',<PUSHJ P,RELNE>,4
    E    '<>    ',<PUSHJ P,RELNE>,4
    E    'LT    ',<PUSHJ P,RELLT>,4
    E    "<",<PUSHJ P,RELLT>,4
    E    'GT    ',<PUSHJ P,RELGT>,4
    E    ">",<PUSHJ P,RELGT>,4
    E    'GE    ',<PUSHJ P,RELGE>,4
    E    <BYTE (6) 36,35>,<PUSHJ P,RELGE>,4
    E    'LE    ',<PUSHJ P,RELLE>,4
    E    <BYTE (6) 34,35>,<PUSHJ P,RELLE>,4
 INS 16/9
    RELEQ:    CAME    OP,T1
    FALSE:    TDZA    OP,OP        ;0 = FALSE
    TRUE:    SETO    OP,        ;-1 = TRUE
        POPJ    P,

    RELNE:    CAMN    OP,T1
        JRST    FALSE
        JRST    TRUE

    RELLT:    CAML    OP,T1
        JRST    FALSE
        JRST    TRUE

    RELLE:    CAMLE    OP,T1
        JRST    FALSE
        JRST    TRUE

    RELGT:    CAMG    OP,T1
        JRST    FALSE
        JRST    TRUE

    RELGE:    CAMGE    OP,T1
        JRST    FALSE
        JRST    TRUE

 REP 20/9
        PUSH    T4,["$"]    ;DON'T PLOW THROUGH UPPER LEVEL STUFF
 WIT
        PUSH    T4,[DOLLAR]    ;DON'T PLOW THROUGH UPPER LEVEL STUFF
 INS 15/10
        ;REMOVE THE NEXT 2 LINES FOR $ TO BE A SIGNIFICANT LABEL CHARACTER
        CAIN    I,DOLLAR    ;IS IT A DOLLAR?
        JRST    TOKENL        ;YES, THEY ARE NOISE CHARACTERS
 REP 40/10
        CAIN    I,"$"        ;$ IS NOW A LEGAL SYMBOL CHARACTER
 WIT
        CAIE    I,"@"        ;@
        CAIN    I,"?"        ;AND ? ARE LEGAL
        JRST    SCPOPJ
        CAIN    I,DOLLAR    ;$ IS NOW A LEGAL SYMBOL CHARACTER
 REP 13/18
        MOVE    T4,T2        ;SAVE POINTER FOR END OF MACRO
        PUSHJ    P,SNEAK        ;TAKE A SNEAKY LOOK AT THE NEXT TOKEN
        CAMN    TOK,[SIXBIT/ENDM/];END OF MACRO?
        JRST    DOMAC5        ;YES
        JRST    DOMAC7        ;NO, SEE IF A DUMMY ARG
 WIT
        JRST    DOMC2A        ;CHECK FOR ENDM, ETC.
 REP 26/18
        MOVEI    I,177
        IDPB    I,T4
        MOVEI    I,1        ;177,1 IS END OF MACRO
        IDPB    I,T4
        SETZ    I,
        IDPB    I,T4        ;END WITH NULL
        AOJ    T4,        ;POINT TO 1ST FREE WORD
        HRRM    T4,.JBFF##    ;UPDATE JOBFF
 WIT
        LDB    I,T2        ;GET LAST CHAR OF MACRO
        CAIN    I,12        ;END WITH LF?
        JRST    DOMC5A        ;YES, SKIP
        MOVEI    I,15
        IDPB    I,T2
        MOVEI    I,12        ;END MACRO TEXT WITH CRLF
        IDPB    I,T2
    DOMC5A:    MOVEI    I,177
        IDPB    I,T2
        MOVEI    I,1        ;177,1 IS END OF MACRO
        IDPB    I,T2
        SETZ    I,
        IDPB    I,T2        ;END WITH NULL
        AOJ    T2,        ;POINT TO 1ST FREE WORD
        HRRM    T2,.JBFF##    ;UPDATE JOBFF
 REP 44/18
        PUSHJ    P,SNEAK        ;LOOK AT NEXT TOKEN
    DOMAC7:    JUMPE    TOK,DOMAC1    ;NOTHING THERE
 WIT
    DOMC2A:    PUSHJ    P,SNEAK        ;LOOK AT NEXT TOKEN
    DOMAC7:    JUMPE    TOK,DOMAC1    ;NOTHING THERE
        CAMN    TOK,[SIXBIT/ENDM/];END OF MACRO?
        JRST    DOMAC5        ;YES
 INS 32/25
        MOVEM    I,SNEAKI    ;SAVE THE BREAK CHARACTER
 REP 38/25
        CAIL    T2,ENDHGH    ;POINTS TO BAKBUF?? (IF SO, DON'T SAVE)
 WIT
        CAIG    T2,BAKPTR
        CAIGE    T2,BAKBUF    ;POINTS TO BAKBUF?? (IF SO, DON'T SAVE)
 REP 41/28
        MOVEI    I,"L"        ;START THE SYMBOL WITH "L$$"
        DPB    I,INVECT
        MOVEI    I,"$"
        IDPB    I,INVECT
 WIT
        MOVEI    I,"?"        ;START THE SYMBOL WITH "??"
        DPB    I,INVECT
 REP 4/32
        MOVEI    T1,"$"        ;FLAG NON-INTEL RECORD
 WIT
        MOVEI    T1,DOLLAR    ;FLAG NON-INTEL RECORD
 REP 27/33
    TYPE02:    MOVEI    T1,"$"        ;TYPE 2 OR 3 LEADER
 WIT
    TYPE02:    MOVEI    T1,DOLLAR    ;TYPE 2 OR 3 LEADER
 REP 9/39
    PRTS:    SETZB    T1,T2
 WIT
    PRTS:    HRLOI    T1,377777    ;+INFINITY
 REP 20/39
        JUMPE    T1,PRTX        ;DONE
 WIT
        CAMN    T1,[377777,,-1]    ;NO SYMBOLS SMALLER THAN +INFINITY?
        JRST    PRTX        ;DONE
 REP 27/41
        CAMG    T1,(S)        ;GET SYMBOL
        JRST    PRT11
 WIT
        CAMG    T1,(S)        ;GET SYMBOL THAT IS SMALLER
        JRST    PRT11        ;(YES, WE ARE ONLY SORTING ON THE FIRST 6 CHARACTERS)
 REP 19/45
        MOVEI    T2,M80MAJ
 WIT
        MOVEI    T2,M80VER
 REP 32/48
        CAIG    T1,ENDHGH    ;CAME FROM BAKBUF?
        JRST    DOLIN1        ;YES, THAT'S NOT A MACRO
        MOVEI    T1,"M"        ;FLAG AS A MACRO EXPANSION LINE
        PUSHJ    P,LOUCH
 WIT
        CAIG    T1,BAKPTR
        CAIGE    T1,BAKBUF    ;CAME FROM BAKBUF?
        JRST    [MOVEI    T1,"M"    ;NO, FLAG AS A MACRO EXPANSION LINE
            PUSHJ    P,LOUCH
            JRST    DOLIN1]
 INS 23/52
    SNEAKI:    0        ;CONTENTS OF REG I WHEN DONE SNEAKING TOKEN
 SUM 131614
-------
16-Aug-83 14:01:15-EDT,1051;000000000011
Return-Path: <[e-mail]>
Received: from FORD-WDL1.ARPA by COLUMBIA-20.ARPA with TCP; Tue 16 Aug 83 14:01:03-EDT
Return-Path:<>
Date: 15-Aug-83 20:54:51-PDT
From: [e-mail]
Subject: INFO-KERMIT and Kermit-Unix
To: [e-mail]
Keywords: UNIX Kermit

I noticed some files in PS:<KERMIT> that referred to INFO-KERMIT.
If there is such a beast, I'd like to join up.

I've been working with Kermit-Unix (Columbia), trying to de-Berklify the
code.  It now runs on v6/PWB, Onyx v7, and Onyx System III, in addition
to bsd 4.1 (all through ifdef's).  I'll move it to System V, but that
will require a little rework in the ioctl's.  I sped it up a bit, and
added several fixes from Jim Guyton (guyton@rand-unix).  As soon as a
friend does a little beta test work with Kermit-PC, I'll be glad to send
it over.

I've also got a fairly complete Unix man page.  We sort of require that
for public software on our system.

    walter underwood

UUCP:  fortune!wdl1!wunder
ARPA:  wunder@FORD-WDL1
Phone: [phone]
16-Aug-83 20:02:24-EDT,3792;000000000001
Mail-From: CC.FDC created at 16-Aug-83 20:02:08
Date: Tue 16 Aug 83 20:02:08-EDT
From: Frank da Cruz <[e-mail]>
Subject: INFO-KERMIT mailing list available
To: [e-mail]
Keywords: Distribution List

Hi.  I'm just back from a month's vacation and am gearing up to start
maintaining the INFO-KERMIT mailing list, as promised.  If you have received
this message, then the mechanism works, and you have either asked to be put on
the list or have expressed some interest in maintaining KERMIT.  The list is
intended for people who maintain or install KERMIT at their sites, or who are
(thinking about) working on a new implementation, or who have bugs and/or
fixes to report, or are interested in discussing the protocol.  If this
message goes out OK, I'll announce the mailing list on INFO-IBMPC, INFO-CPM,
and INFO-MICRO; KERMIT itself has already been announced on these lists.

Here's how to use the list.  From ARPANET:

  Mail requests to be added/deleted to/from the list to

     INFO-KERMIT-REQUEST@COLUMBIA-20

  Mail messages to be seen by all the participants to

     INFO-KERMIT@COLUMBIA-20

From CCNET (A DECnet network comprising Columbia, CMU, and CWRU), use the same
procedure, but mail to host CUCS20.  The same facility will also be available
from BITnet (a network based on IBM RSCS communication comprising many
universities with IBM systems or VAXes) as soon as we have completed the mail
gateway mechanism at Columbia (within a few weeks, I hope).

An archive of all the messages will be available in the file
PS:<KERMIT>MAIL.TXT, available via anonymous FTP from COLUMBIA-20 (ARPANET)
or anonymous NFT from CUCS20 (CCNET).

Any message sent to INFO-KERMIT from any host will reach all participants, no
matter which network they're on.

We'll try running the list without condensing it into a digest, and see how
the traffic goes.  If traffic gets too heavy (or silly), we'll convert to
digest form.

Since the announcement of availability of KERMIT over the network a month ago,
there have been several new developments:

. UNIX: Everyone has settled on a common source, KERMIT.C, for 4.1bsd, after
some bugs were shaken out by Jim Guyton at Rand-Unix.  This is available from
the Columbia KERMIT area and is the "production" version at the Columbia CS
department, where it runs on a variety of VAXes and SUNs.  Walter Underwood at
Ford is adding support for other varieties of UNIX (v6, v7, Bell System III,
Onyx, etc) which can be selected by conditional compilation.  I expect this
will be available shortly.

. CP/M: Bruce Tanner at Cerritos College fixed half-duplex terminal emulation,
which was broken in the last update, as well as a problem with files that are
a multiple of 128 records.  Bernie Eiben at DEC fixed a problem with files
that are exactly 0K, 16K, 32K in length, and restored terminal session logging
to its previous (imperfect) state; the latter was also broken in the update.
Bruce Tanner also beefed up his 8080 cross assembler for the DEC-10 & -20, by
adding relational operators in expressions and other new features.  None of
this stuff is on line yet; I (or someone) will have to sift it all together.
CP/M Kermit still has a number of other bugs and shortcomings, which are
listed in a previous message, which may be found in the archive.

. TOPS-10 KERMIT has had server mode operation added by Denson Burnum at
Vanderbilt University; this is not on line yet either.

. KERMIT has been adopted by THE SOURCE as their file transfer mechanism;
they're implementing it in PL/I on their PR1ME computer.  Some other dialup
databases are also looking at it.  It will, of course, remain nonproprietary.

Watch this space for further announcements.

- Frank
-------
16-Aug-83 21:31:36-EDT,893;000000000001
Return-Path: <[e-mail]>
Received: from NLM-MCS.ARPA by COLUMBIA-20.ARPA with TCP; Tue 16 Aug 83 21:31:31-EDT
Date: Tue 16 Aug 83 21:30:36-EDT
From: Jon Albers  <[e-mail]>
Subject: Kermit for the OCC-systems
To: [e-mail]
Keywords: OCC-1, Osborne Kermit

Readers,
                  First of all, my thanks to those who put this list together.  I feel
it was well needed.
    Second, thanks to Chuck Bacon at the National Institutes of Health, we
now have KERMIT for the OCC-1 (Osborne 1).  What I would now like to know is if
anyone has comwe up with KERMIT for the OCC-Executive 1.  I don't want to sound
as if I want to sit back and make someone else do the work, but I am not an avid
programmer in anything but BASIC.  I will contribute anything I can to the list,
and I thank again Columbia-U for setting up the list.

                                Jon Albers
                                 ALBERS@NLM-MCS
-------
17-Aug-83 09:28:37-EDT,1691;000000000001
Mail-From: CC.FDC created at 17-Aug-83 09:28:28
Date: Wed 17 Aug 83 09:28:27-EDT
From: Frank da Cruz <[e-mail]>
Subject: Osborne Kermits
To: [e-mail]
Keywords: Osborne Kermit, CP/M Kermit

Any of you who might have plowed through the material on CP/M Kermit,
particularly CPMKERMIT.DOC, may have noticed that the Osborne support is a
special problem.  Chuck Bacon at NIH added the original Osborne-1 support,
which was hairy due to the Osborne's memory-mapped i/o and poor documentation,
but it worked fine.  Meanwhile, support for various other machines and for
"generic" (CP/M calls only) operation was added to the same code, and that
broke the Osborne support.  The older source file can still produce a working
Osborne Kermit and has to be kept around for that reason.  Chuck said he would
look into getting the Osborne support working from the current source, which
he has.

Meanwhile, Bruce Tanner added CP/M-Plus (3.0) support to Kermit-80 for some
machine that he has, and it turns out that it runs just fine on the Osborne
Executive, as it should on any system that fully implements CP/M 3.0.

As you can see, Kermit development and maintenance is a truly distributed
enterprise.  No one has all the supported machines available for testing.
CP/M Kermit poses the biggest problem because 15 (and growing!) different
machines are supported from a single source file, and one never knows when
adding a new feature, fixing a bug, or putting in support for a new machine,
whether the change will break the support for some other machine.  This is
where Info-Kermit can help -- new versions can be tested all over the net in
a short time.

- Frank
-------
18-Aug-83 11:52:01-EDT,1520;000000000001
Return-Path: <[e-mail]>
Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Thu 18 Aug 83 11:51:48-EDT
Return-Path: <PLEHN@MIT-MC>
Received: from MIT-MC by SU-SCORE.ARPA with TCP; Mon 1 Aug 83 18:21:45-PDT
Date: 1 August 1983 21:20 EDT
From: Allan D. Plehn <PLEHN @ MIT-MC>
Subject: KERMIT for IBM 370 running MVS
To: G.DACRUZ @ SU-SCORE
cc: PLEHN @ MIT-MC
ReSent-date: Thu 18 Aug 83 08:51:13-PDT
ReSent-from: Frank da Cruz <[e-mail]>
ReSent-to: [e-mail]
Keywords: MVS Kermit, IBM 370 Series

I have been looking for a means of xmitting files (ASCII) between
the office micros and our IBM 370/158.  I thought KERMIT might
finally be the solution.  Unfortunately, our IBM is not using
VM/CMS but instead uses MVS.  Is anyone working on a KERMIT
implementation to run under MVS?

The IBM world is all foreign to me.  My computer experience is
all on micros, with a little familiarity with MIT's MC (PDP10)
and OZ (DEC20).  I must rely on what the people in our IBM shop
(a little empire that dispenses info grudgingly) for info about
the IBM so I can't tell you anything about MVS.  Maybe your IBM
types recognize this acronym.  Is there anything about MVS that
would make it tough or impossible to implement KERMIT?

Basically, should I forget about KERMIT for this application
due to some inherent problem or is it quite possible that
KERMIT can and will be available to run under MVS?  Any info
you can provide will be keenly appreciated.

            Regards,
                Al Plehn

18-Aug-83 12:37:54-EDT,2404;000000000001
Return-Path: <[e-mail]>
Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Thu 18 Aug 83 12:37:20-EDT
Mail-From: G.DACRUZ created at 18-Aug-83 08:50:47
Date: Thu 18 Aug 83 08:50:47-PDT
From: Frank da Cruz <[e-mail]>
Subject: Re: KERMIT for IBM 370 running MVS
To: [e-mail]
In-Reply-To: Message from "Allan D. Plehn <PLEHN @ MIT-MC>" of Mon 1 Aug 83 21:20:00-PDT
ReSent-date: Thu 18 Aug 83 09:36:57-PDT
ReSent-from: Frank da Cruz <[e-mail]>
ReSent-to: [e-mail]
Keywords: MVS Kermit, IBM 370 Series

Just got back from a month's vacation and saw your message.  The problem
with MVS is that it's a batch operating system -- yes, that's right, cards
and JCL (in the IBM sense, not the ITS sense)...  To achieve a semblance
of timesharing with access from interactive terminals, a batch job is run
under MVS which takes over all the terminals and interprets commands as if
they were JCL.  That batch job is generally something called TSO (Time Sharing
Option), which is just about the most hideous parody of timesharing or a
"user interface" you've ever seen.  Since TSO does support ASCII terminals
(the reason I mention this is that many IBM systems do not), it would be
quite possible to have KERMIT running under TSO under MVS, and many sites
have expressed a craving for this, some have said they would do it.  But so
far we've seen no results.  The latest bunch that said they'd give it a
shot was the government of Saskatchewan; you might try calling Arnie Berg in
Saskatoon at 306-565-3951 to see how serious they are about it.

Our VM/CMS implementation is in assembly language, but I think PL/I would have
been a better approach.  There are at least two PL/I implementations underway
-- one for MULTICS (not at MIT) and another for PR1ME.  I suspect either of
these would serve as a better basis for a TSO/MVS implementation than would
the assembler version.  By the way, there are a few other strange non-IBM
operating systems that run on the same equipment for which there has been some
interest in KERMIT.  These include MTS (Michigan Timesharing System) and
MUSIC (I'm not sure what that is).  Alos, to round out the picture, you
can also run UNIX(*) under VM/CMS -- it's marketed by Amdahl and called UTS.
We run it at Columbia and are working on getting standard UNIX Kermit to work
under it.

- Frank
-------
18-Aug-83 12:45:40-EDT,713;000000000001
Return-Path: <HFISCHER@USC-ECLB>
Received: from USC-ECLB by COLUMBIA-20.ARPA with TCP; Thu 18 Aug 83 12:45:31-EDT
Date: 18 Aug 1983 0944-PDT
From: HFISCHER@USC-ECLB
Subject: KERMIT for IBM's MVS
To:   PLEHN at MC
cc:   Info-Kermit at COLUMBIA-20
Keywords: MVS Kermit, IBM 370 Series

RE: request for information on Kermit for IBM's MVS operating system,

We too use MVS.  I have installed the present Kermit routines
on our 3038's, but they are loaded with errors when attempting to assemble.
We do not have inhouse expertise as to MVS vs VM differences, and are
basically putting the MVS Kermit version on hold.  If anybody has
any suggestions on how to convert, I am willing to try it out.

  Herm Fischer (HFischer@eclb)
-------
19-Aug-83 20:12:04-EDT,1905;000000000001
Mail-From: CC.FDC created at 19-Aug-83 20:11:58
Date: Fri 19 Aug 83 20:11:58-EDT
From: Frank da Cruz <[e-mail]>
Subject: KERMIT mailing list available
To: [e-mail], [e-mail], [e-mail],
    [e-mail]
cc: [e-mail]
Keywords: Distribution List

About 6 weeks ago I announced the availability of the KERMIT package on the
ARPAnet at COLUMBIA-20.  In case you missed it, KERMIT is a file transfer
protocol for use primarily between micros and mainframes over TTY lines, and
is implemented on a wide variety of both.  At that time, I said that if there
were sufficient interest in it, I'd start a mailing list.  Well, there is, and
I have.  The list is intended for people who maintain or install KERMIT at
their sites, or who are (thinking about) working on a new implementation, or
who have bugs and/or fixes to report, or are interested in discussing the
protocol.

Here's how to use the list.  From ARPANET:

  Mail requests to be added/deleted to/from the list to

     INFO-KERMIT-REQUEST@COLUMBIA-20

  Mail messages to be seen by all the participants to

     INFO-KERMIT@COLUMBIA-20

From CCNET (A DECnet network comprising Columbia, CMU, and CWRU), use the same
procedure, but mail to host CUCS20.  The same facility is also available
from BITnet (a network based on IBM RSCS communication comprising many
universities with IBM systems or VAXes), again using host CUCS20.

An archive of all the messages will be available in the file
PS:<KERMIT>MAIL.TXT, available via anonymous FTP from COLUMBIA-20 (ARPANET)
or anonymous NFT from CUCS20 (CCNET).

Any message sent to INFO-KERMIT from any host will reach all participants, no
matter which network they're on.

We'll try running the list without condensing it into a digest, and see how
the traffic goes.

- Frank da Cruz, Columbia University
-------
22-Aug-83 19:11:11-EDT,2765;000000000001
Mail-From: CC.FDC created at 22-Aug-83 19:11:01
Date: Mon 22 Aug 83 19:11:01-EDT
From: Frank da Cruz <[e-mail]>
Subject: New release of MAC80 cross assembler
To: [e-mail], [e-mail]
Keywords: MAC80

Bruce Tanner of Cerritos College has contributed a new release of MAC80, his
8080 cross assember for the DECsystem-10 and DECSYSTEM-20, to the KERMIT
distribution.  This is a CP/M-compatible assembler, written in PDP-10
assembly language, that produces a .HEX file suitable for LOADing on a
CP/M system.  For those of you who may have an earlier copy, here are the
differences:

Changes between MAC80 6A and 7:

    <filename>.SYM is created whenever a list file is requested.
    This can be used by SID and ZSID.

    MACLIB <filename> will read in <filename>.LIB (in your default path)
    as a library of macros and symbol definitions.

    PAGE will force a page eject.
    PAGE n will set the default page size to n.

    NUL FOO will return TRUE if FOO is a null argument to a macro.
    NUL actually checks for an undefined symbol generated for the macro,
    so passing an undefined symbol as an argument to a macro will be
    tested as a null argument.

    REPT <expr> ... ENDM  repeats the code inside the macro <expr> times.
    Local symbols may be used in REPT.

    EXITM may be used to abort a macro or REPT.

    One layer of fuzzy thinking removed from upper/lower case handling.

    One known bug: OPT SMAC and nested macros generate junk in the
    listing. The generated code is OK.


Changes between MAC80 6 and 6A:

    Relational operators in expressions (=,<>,<,<=,>,>=,eq,ne,lt,le,gt,ge),
    returns FF if true 0 if false.

    @ and ? are allowed in symbols.

    $ are considered non-significant in symbols.

    local symbols are now ??n instead of L$$n.

Changes between MAC80 5B and 6:

    Symbols may now be up to 12 characters long

    Symbols (including numbers) may include dollar signs

    The listing file output reflects the actual case of the input file

    The value generated by dollar signs (assembler PC) in EQU statements
    are now correct

    Binary numbers are now legal

    Macros may now be nested

    Local symbols in macros

You can get the new MAC80 via anonymous FTP from COLUMBIA-20 (ARPAnet) or
anonymous NFT from CUCS20 (CCnet), specifying files KER:M*8*.* and
KER:TORTUR.* (the latter being a "torture test" that illustrates all the
features of the assembler.

Bruce's utility HEXIFY, which converts a CP/M .COM file to a .HEX file on the
DEC-10 or -20, remains available as before.  In addition, he has contributed a
complementary program, HEXCOM, to convert a .HEX file to a .COM file.  These
programs can be obtained by specifying KER:HEX*.* to FTP or NFT.

- Frank
-------
22-Aug-83 20:42:55-EDT,5869;000000000001
Mail-From: CC.FDC created at 22-Aug-83 20:42:50
Date: Mon 22 Aug 83 20:42:50-EDT
From: Frank da Cruz <[e-mail]>
Subject: KERMIT work in progress
To: [e-mail]
Keywords: New Implementations

Here's a list of some new implementations of KERMIT that are in the works.
None of these is online at Columbia yet, but I hope this information might
forstall some duplicated efforts.  If anyone wants to be put in touch with the
people doing these implementations (mostly off the ARPAnet), let me know.

- Frank


* STEVENS INSTITUTE OF TECHNOLOGY

Big doings.  They have taken their Bliss implementation for VAX/VMS and
started transporting it piecewise to other machines.  The part that handles
the actual packet construction and transport, the "message" module (VMSMSG.BLI
for the VAX) has had the 8th-bit quoting facility added to allow transfer of
binary files between systems that can't do 8-bit i/o.  They are using this
module in these 3 implementations:

. DECSYSTEM-10:  Upgraded to do 8-bit quoting using the Bliss message module,
with the major part of the program still in MACRO-10.  Also upgraded to
perform some server functions.  (Server functions were added independently at
Vanderbilt University, but the Stevens work will probably be distributed).

. VAX/VMS:  Will soon be released with 8th-bit quoting.

. Professional-350:  A new KERMIT has been written for this machine in
MACRO-11, but using the Bliss message module.  It's in the final stages of
debugging.  There will be a menu/function-key P/OS-style user interface as
well as a normal keyword-oriented KERMIT command parser.  Since Bliss-16 is
not commonly available to compile the message module for the PDP-11, it was
hand-translated into Bliss-11 and compiled on the DEC-10.  Pro-350 KERMIT will
be readily transportable to RSX-11/M, which looks almost exactly like P/OS to
the programmer.  File i/o is done using RMS calls.


* THE SOURCE

SOURCE Telecomputing has adopted KERMIT as its file transfer protocol and has
done an implementation in PL/I for their PR1ME computer.  It implements server
functions (including some that no one else has implemented yet, like remote
directory listings), 8th-bit quoting, and other advanced features.  Some
additional work remains to be done, and then it will be made available to all.

In addition, the SOURCE people have modified IBM PC Kermit to do 8th bit
quoting and to invoke some of the new server functions.  8th-bit quoting is
especially important to The SOURCE because most of their business comes in
over TELENET, which usurps the parity bit, preventing KERMIT (or MODEM or ...)
from sending binary files in the normal way.  The new PC KERMIT will be made
available as soon as possible, after we check it out and merge their work with
our own (and CMU's) recent work.  Incidentally, I was able to KERMIT their new
PC Kermit (170K) to the DEC-20 from their PR1ME system without a hitch.


* CORNELL

Cornell University is doing a UCSD P-System implementation -- like Stevens,
they need it for the Fall semester.  They're doing the initial work on Teraks,
and expect to run it on IBM PCs and others.

A MUMPS implementation is also underway at Cornell.


* OTHERS

University of Oakland in Rochester, Michigan, has done a MULTICS implementation
in PL/I.

    By the way --

    There is a crying demand for more and better IBM mainframe
    implementations, both for IBM operating systems like TSO under OS/VS1
    or MVS, or homegrown systems like MUSIC (McGill University System for
    Interactive Computing), MTS (Michigan Timesharing System), or GUTS
    (Gothenburg University Timesharing System).  The PR1ME and MULTICS
    PL/I implementations might easily be adapted to fit these systems.
    When we (Columbia) get our hands on them, we'll try bringing them up
    under VM/CMS; if this proves successful, we may abandon the IBM
    assembler version.

The UNIX C version is having conditional compilation support added for
non-Berkeley UNIXes by Walter Underwood at Ford.  Conditional support for VMS
was also added to the C version at DEC; this has yet to be merged in and
tested.  Once all this is done, Columbia will be adding error packet
processing and server functions, and getting it work on IBM mainframes under
UTS (Amdahl's versions of UNIX).

Columbia will also be adding 8th-bit quoting and advanced server functions to
the DEC-20 implementation.  We also plan to come up with a native (8088-based)
KERMIT for the DEC Rainbow-100.

Wesleyan University is doing KERMIT for the Corvus Concept workstation in ISO
Pascal; it's in the debugging stages.

CP/M KERMIT: Bruce Tanner at Cerritos College fixed half-duplex terminal
emulation, which was broken in the last update, as well as a problem with
files that are a multiple of 128 records.  Bernie Eiben at DEC fixed a problem
with files that are exactly 0K, 16K, 32K, ..., in length, and restored
terminal session logging to its previous (imperfect) state; the latter was
also broken in the update.  Bruce Tanner also beefed up his 8080 cross
assembler for the DEC-10 & DEC-20.  CP/M Kermit still has a number of other
bugs and shortcomings, which are listed in a previous message, which may be
found in the archive.

University of Texas is working on a Cyber 170 implementation in Cyber C,
later to be converted to FTN5.

Ford Motor Company in Dearborn, Mich, said it would do a Victor 9000 KERMIT;
so have various places in Europe and Scandanavia.

North Carolina State University announced its intention to produce KERMITs for
the Data General MV/8000/AOS/VS and for the Sage II & IV P-Systems.

Many sites, mostly commercial, have said they would contribute a RSTS/E
version in Basic+ or Basic+2, but I've never heard back from any of them.
-------
23-Aug-83 08:55:11-EDT,780;000000000001
Return-Path: <OC.GARLAND@CU20B>
Received: from CU20B by CUCS20 with DECnet; 23 Aug 83 08:55:04 EDT
Date: Tue 23 Aug 83 08:52:59-EDT
From: Richard Garland <OC.GARLAND@CU20B>
Subject: Re: KERMIT work in progress
To: cc.fdc@CUCS20
cc: Info-Kermit@CUCS20, OC.GARLAND@CU20B
In-Reply-To: Message from "Frank da Cruz <cc.fdc@CUCS20>" of Mon 22 Aug 83 21:21:22-EDT
Keywords: RSX11-M, RSX, RSTS

Does anyone out there still use RSX11-M?  I would love to see Kermit
on RSX and on RSTS. (RSTS is very big in the small business world).
Any ideas on easily convertible versions?  Maybe the Bliss-11 can produce
a macro like file.  Will the Pro-350 version really work on RSX.  What
about RT-11 for those of us without the P-system?  (in other words
does anyone use DEC operating systems?)
                    Rg
-------
23-Aug-83 10:04:25-EDT,3256;000000000001
Mail-From: CC.FDC created at 23-Aug-83 10:04:18
Date: Tue 23 Aug 83 10:04:17-EDT
From: Frank da Cruz <[e-mail]>
Subject: Re: KERMIT work in progress
To: OC.GARLAND@CU20B
cc: [e-mail]
In-Reply-To: Message from "Richard Garland <OC.GARLAND@CU20B>" of Tue 23 Aug 83 08:55:15-EDT
Keywords: PRO-350 Kermit

Pro-350 KERMIT will work under RSX-11M with maybe a couple minor changes, and
using an ordinary command parser (as opposed to the NEXT SCREEN; HELP; DO;
INSERT HERE buttons).  Correct, Bliss-11 can generate Macro code, which will
be distributed for the benefit of those sites that don't have Bliss-11 (or a
-10 or -20 to run it on!), much as Macro code is distrubted for VAX/VMS
KERMIT, which is written entirely in Bliss-32.  Anyway, the Pro implementation
might also be rather easily adaptable to RT-11; we'll have to see about that
once it's available.  Several sites have already expressed an interest in
doing the conversion.  At that point we'll have all the DEC operating systems
well covered except RSTS/E, DOS-11 (anybody remember that?), and OS-8.  Of
course, there are still the non-DEC OS's for DEC machines to contend with
(TENEX, WAITS, ITS for the -10, etc).

It would be quite simple to knock off a version of KERMIT for RSTS in
Basic-Plus, but no one has done it, or if they have I haven't heard about it.
The RT-11 version requires OMSI Pascal, which is proprietary (I don't know the
price).  It might also be possible to bend the UNIX version of KERMIT (written
in C) to run under RT-11 and other DEC OS's in DECUS or Whitesmith C.  There
may also be a DECUS Pascal for the PDP-11.

We have no control over what language people outside Columbia to write KERMIT
in.  Often, we have no idea that an effort is in progress until a tape shows
in in our mailbox.  My preference would be for non-proprietary or at least
widespread languages, and in fact most implementations are in assembler, which
is usually distributed as part of any system package (IBM PC is an exception).
There is still no Fortran or Basic implementation, although several sites have
said they might produce these.

This is not to push any particular language or programming style; the idea of
KERMIT is to provide file transfer to the widest variety of machines at the
lowest cost, using existing hardware and software whenever possible.  A
relative of KERMIT, called TTYFTP, was written at Stanford University Medical
Center (SUMEX) a few years ago in MAINSAIL (MAchine INdependent SAIL), which
should have been readily transportable to the wide variety of machines that
MAINSAIL runs on, but MAINSAIL departed from the public domain and TTYFTP
never really caught on because MAINSAIL never became nearly as widespread as
assembler, Fortran, Basic, Pascal, or C (plus there was never a MAINSAIL for
the 8-bit machines).  Maybe it will someday -- it's one of the nicest of the
Algol-like languages -- and then a MAINSAIL KERMIT could be a great boon,
since it would automatically run on TOPS-10, TENEX, TOPS-20, VAX/VMS,
VAX/UNIX, MC68000/UNIX, Apollo Aegis, IBM VM/CMS, RT-11, RSX-11M, and who
knows what else.  (Somebody at SUMEX or XIDAK correct me if I've said anything
wrong here.)

- Frank
-------
24-Aug-83 16:36:19-EDT,1195;000000000001
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 24 Aug 83 16:36:11 EDT
Date: Wed 24 Aug 83 16:37:24-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New members, old messages
To: Info-Kermit@CUCS20
cc: BJN%MITVMA@CU20B, FDCCU%CUVMB@CU20B
Keywords: Kermit Info

I've added 30 or 40 new members to the Info-Kermit mailing list in the last
couple days.  Those of you who are new to the group might want to take a look
at the message archive.  It's not too long (yet) -- about 30 DEC-20 pages,
or 75K bytes.  Some of the more informative messages list known problems or
shortcomings of the CP/M KERMIT implementation, new implementations of KERMIT
in progress, etc.  You can get it via anonymous FTP of KER:MAIL.TXT from
ARPANET host COLUMBIA-20, or anonymous NFT of KER:MAIL.TXT from CCNET host
CU20B.  So far, we don't have an archive accessible from BITNET, and we've
also found that BITNET members can't be included in the Info-Kermit mailing
list because the BITNET mailer does not yet implement the necessary protocols
for mailing list expansion.  Those of you who are receiving this message on
BITNET are getting it via manual intervention.  - Frank
-------
26-Aug-83 10:20:22-EDT,1222;000000000001
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 26 Aug 83 10:20:14 EDT
Date: Fri 26 Aug 83 10:18:48-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: TOPS-20 time bomb breaks KERMIT-20
To: Info-Kermit@CUCS20
Keywords: Kermit-20

On Wednesday, August 24, at 11:53:51-EDT, KERMIT-20 stopped working on
many TOPS-20 systems.  The symptom was that after a certain number of
seconds (KERMIT-20's timeout interval), the retry count would start
climbing rapidly, and then the transfer would hang.  The problem turns
out to be a "time bomb" in TOPS-20.  Under certain conditions (i.e. on
certain dates, provided the system has been up more than a certain
number of hours), the timer interrupt facility stops working properly.
If KERMIT-20 has stopped working on your system, just reload the
system and the problem will go away.  Meanwhile, the systems people at
Columbia have developed a fix for the offending code in the monitor
and have distributed it to the TOPS-20 managers on the ARPAnet.

The problem is also apparent in any other TOPS-20 facility that uses
timers, such as the Exec autologout code.

The time bomb next goes off on October 27, 1985, at 19:34:06-EST.

- Frank
-------
26-Aug-83 23:47:13-EDT,670;000000000001
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 26 Aug 83 23:47:11 EDT
Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Fri 26 Aug 83 23:45:51-EDT
Date: 26 Aug 83 23:34:26 EDT
From: [e-mail]
Subject: Kermit and Commodore??
To: [e-mail], [e-mail]
Keywords: Commodore 64 Kermit

Hi,

  I would like to use Kermit for transferring files with my Commodore 64 to
a DEC-20 and possibly a VAX or other mainframes that implement kermit. Is
anyone out there writing, or thinking of writing such software. Does anyone
know if Kermit for CP/M will run on CP/M for the 64 ??

Thanx,
Eric
-------
30-Aug-83 10:09:43-EDT,2512;000000000011
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 30 Aug 83 10:09:37 EDT
Return-Path: <@LBL-CSAM.ARPA:kpno!brown@LBL-CSAM>
Received: from LBL-CSAM.ARPA by COLUMBIA-20.ARPA with TCP; Tue 30 Aug 83 02:41:49-EDT
From: kpno!brown@LBL-CSAM
Return-Path: <kpno!brown@LBL-CSAM>
Message-Id: <[e-mail]>
Received: by LBL-CSAM.ARPA (3.347/3.35)
    id AA12348; Mon, 29 Aug 83 23:45:15 PDT
Date: 29 Aug 1983 22:41-MST
To: lbl-csam![e-mail]
Subject: problems with vms kermit
Cc: brown@LBL-CSAM
ReSent-date: Tue 30 Aug 83 10:04:58-EDT
ReSent-from: Frank da Cruz <cc.fdc@CUCS20>
ReSent-to: Info-Kermit@CUCS20
Keywords: VMS Kermit

Frank,

    We've just brought up the VMS version of KERMIT in Macro.  The
archive at COLUMBIA-20 is missing a file KERERR.MSG and a Bliss
include file seems to be missing (KERCOM?  I'm not sure we don't have
Bliss here).  I have the Kermit distribution from a local Compuserve
fellow, thats where I found the files that weren't on COLUMBIA-20.

    First, my gripes.   The echo during the connect mode is
abominable, having to wait several seconds to see characters echoed is
ridiculous.  There seem to be some strange side effects while trying
to receive a file via a remote tty (using either server or receive
mode) after having done a "SET LINE TTA6".  I see messages about
device is already allocated to another user and when I retry the
command it seems to be accepted but I have to kill KERMIT, control is
never returned to me.  I haven't tried directly sending or receiving
via the login tty yet, we're not set up to do that easily(at least on
VMS).

    Now some constructive comments.  The biggest problem we had is
that the default device protection under VMS 3.2 is too restrictive,
you must do a:  "SET PROTECTION=(W:RWLP)/DEVICE TTA6" to allow KERMIT
to function properly.

    How soon will you have the VMS changes from DEC for the kermit.c
source?  I've got kermit.c on our unix vax and intend to try compiling
my present version on a VMS machine to see how they talk to each
other (ie. are my problems really due to kermit.c or the macro VMS
KERMIT....)  If possible can I have the name of the person(s) at DEC
doing the work so I can see whats up?  I have a couple of minor mods
of my own to kermit.c....

    regards,
    Mike Brown    Kitt Peak National Observatory
            Tucson, Arizona            [phone]

{...,arizona,decvax,hao,ihnp4,lbl-csam,sdcarl,sdcsvax,seismo,unc}!kpno!brown

30-Aug-83 10:21:52-EDT,3132;000000000001
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 30 Aug 83 10:21:44 EDT
Mail-From: CC.FDC created at 30-Aug-83 09:59:05
Date: Tue 30 Aug 83 09:59:04-EDT
From: Frank da Cruz <[e-mail]>
Subject: Re: problems with vms kermit
To: kpno![e-mail]
cc: [e-mail], [e-mail]
In-Reply-To: Message from "kpno!brown@LBL-CSAM" of Tue 30 Aug 83 01:41:00-EDT
ReSent-date: Tue 30 Aug 83 10:06:03-EDT
ReSent-from: Frank da Cruz <cc.fdc@CUCS20>
ReSent-to: Info-Kermit@CUCS20
Keywords: VMS Kermit

I'll pass your comments along to the people at Stevens.  The following message
talks a little about the echoing.  About the VMS support in KERMIT.C...  I
have it on line.  It's pretty ugly, but maybe that's just VMS.  The real
problem is that they put it into an old version of KERMIT.C (the one that was
broken up into about 6 modules) -- the program has been pretty much rewritten
since then, and right now it's off somewhere (see some previous messages)
having support added for the various non-bsd UNIX clones.  When it comes back
I thought I would try to add the VMS conditionals, as well as some features
that have been sorely missing all along, like error packet processing,
server mode, etc.  The trick is to have one source to work from, rather than
3 or 4 which have to be reconciled and merged later on.  But if you're
anxious for it, I'll gladly let you have it if you would be willing to take
the VMS support DEC put into the old version and stick it into the current
version.  - Frank

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

25-Aug-83 19:10:04-EDT,1493;000000000001
Mail-From: OC.SITGO created at 25-Aug-83 19:10:02
Date: Thu 25 Aug 83 19:10:02-EDT
From: "Nick Bush" <OC.SITGO@CU20B>
Subject: VMS Kermit
To: [e-mail]
cc: SY.FDC@CU20B
Keywords: VMS Kermit

Frank passed on your comments about VMS KERMIT.  The next version will have
the commands for using a remote server (BYE, etc.).  It will probably be
a couple weeks before it is ready to be sent out for trials.  It will
also have a SET FILE-MODE BLOCK, which will allow transfers of any kind
of RMS-32 file to another VAX (or to a DEC Professional-350).

The response of the CONNECT processing is due to a tradeoff between trying
to keep CPU usage to a minimum while allowing usage on a fairly high-speed
line.  We could not find any way of being able to pick up input from the
connected line without using data, except to use large buffers and a timeout.
Unfortunately VMS does not implement the desireable type of timeout, which
would only occur if at least one character was in the buffer, nor does it
allow a small enough time parameter to allow for decent response (minimum
timeout is 1 second).  Therefore, it may take up to a second for a character
to be moved from one terminal line to the other.  If you have (or know of
anyone who has) a better way of doing it, please let me know.  We don't
have much usage for the CONNECT command in VMS KERMIT, but any suggestions
as to how to improve it would be appreciated.

                Nick Bush
                Stevens Institute of Technology
-------
-------
30-Aug-83 10:39:47-EDT,1464;000000000001
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 30 Aug 83 10:39:42 EDT
Delivery-Notice: While sending this message to CU20B, the
 CUCS20 mailer was obliged to send this message in 50-byte
 individually Pushed segments because normal TCP stream transmission
 timed out.  This probably indicates a problem with the receiving TCP
 or SMTP server.  See your site's software support if you have any questions.
Mail-From: CC.FDC created at 30-Aug-83 10:04:21
Date: Tue 30 Aug 83 10:04:21-EDT
From: Frank da Cruz <[e-mail]>
Subject: Re: problems with vms kermit
To: kpno![e-mail]
cc: [e-mail], [e-mail]
In-Reply-To: Message from "kpno!brown@LBL-CSAM" of Tue 30 Aug 83 01:41:00-EDT
ReSent-date: Tue 30 Aug 83 10:06:41-EDT
ReSent-from: Frank da Cruz <cc.fdc@CUCS20>
ReSent-to: Info-Kermit@CUCS20
Keywords: VMS Kermit

Oh, I forgot to mention that the missing files are actually present.  If you
look at the file 00README.TXT, you'll see an explanation of the naming
conventions in the KERMIT distribution area.  Since there are so many
implementations of KERMIT, and since filenames have to be restricted to
VMS and TOPS-10 conventions for tape distribution purposes, files pertaining
to a particular implementation have a unique prefix.  The VAX/VMS modules all
start with VMS (rather than KER as they did originally); thus the files are
VMSCOM, VMSERR, etc...  - Frank
-------
30-Aug-83 15:09:34-EDT,1125;000000000001
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 30 Aug 83 15:09:28 EDT
Mail-From: CC.FDC created at 30-Aug-83 10:04:21
Date: Tue 30 Aug 83 10:04:21-EDT
From: Frank da Cruz <[e-mail]>
Subject: Re: problems with vms kermit
To: kpno![e-mail]
cc: [e-mail], [e-mail]
In-Reply-To: Message from "kpno!brown@LBL-CSAM" of Tue 30 Aug 83 01:41:00-EDT
ReSent-date: Tue 30 Aug 83 10:06:41-EDT
ReSent-from: Frank da Cruz <cc.fdc@CUCS20>
ReSent-to: Info-Kermit@CUCS20
Keywords: VMS Kermit

Oh, I forgot to mention that the missing files are actually present.  If you
look at the file 00README.TXT, you'll see an explanation of the naming
conventions in the KERMIT distribution area.  Since there are so many
implementations of KERMIT, and since filenames have to be restricted to
VMS and TOPS-10 conventions for tape distribution purposes, files pertaining
to a particular implementation have a unique prefix.  The VAX/VMS modules all
start with VMS (rather than KER as they did originally); thus the files are
VMSCOM, VMSERR, etc...  - Frank
-------
30-Aug-83 21:02:20-EDT,862;000000000001
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 30 Aug 83 21:02:18 EDT
Received: from NLM-MCS.ARPA by COLUMBIA-20.ARPA with TCP; Tue 30 Aug 83 21:03:10-EDT
Date: Tue 30 Aug 83 21:01:53-EDT
From: Jon Albers  <[e-mail]>
Subject: Problems with CP/M+ Kermit
To: [e-mail]
Keywords: CP/M Kermit

    I got a copy of CPMGENERI.ASM from Columbia, assembled it with MAC,
 setting the VT180 equate to false (it seems that it is default), and the CPM3
 equate to true.  MAC took it w/o error, but using HEXCOM (the CP/M3.0 loader)
 on the hex file resulted in this:

            LOAD ERROR: START LESS THAN 100
 or something like that.
    What did I do wrong?  Did anyone else have the same problem?

    I think that I must have missed the START equate, or something.  Can
 someone help me?

                                Jon Albers
-------
31-Aug-83 11:34:46-EDT,811;000000000001
Return-Path: <@CUCS20:Nemnich@MIT-MULTICS>
Received: from CUCS20 by CU20B with DECnet; 31 Aug 83 11:34:43 EDT
Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Wed 31 Aug 83 11:35:34-EDT
Date:     31 August 1983 1126-edt
From:     Bruce Nemnich    <Nemnich @ MIT-MULTICS>
Subject:  pckermit.fix
To:       Info-Kermit @ COLUMBIA-20
Keywords: MS-DOS Kermit

It is unfortunate that the pckermit.fix file includes the space among
the 16 characters it uses for printable nibbles.  Some primitive
downloading routines (e.g., IBM ASYNCH under CMS) trim trailing blanks.
I have a version of pckexe.bas which does the right thing under those
conditions, but it would be better to chenge the character set.  A more
logical "base" would be 'A', since all systems should be able to send
the letters 'A' to 'O'.

--bjn
 1-Sep-83 11:23:05-EDT,633;000000000001
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 1 Sep 83 11:22:59 EDT
Date: Thu 1 Sep 83 11:23:38-EDT
From: Daphne Tzoar <CC.DAPHNE@CUCS20>
Subject: Re: Kermit and Commodore??
To: info-kermit@CUCS20
In-Reply-To: Message from "[e-mail]" of Fri 26 Aug 83 23:34:26-EDT
Keywords: Commodore 64 Kermit

 A few people in the systems group at Columbia have Commodore's and
 were talking about writing a version of Kermit for it.  But, it would
 be in their spare time so you might want to go ahead and start on a
 version yourself. You could look at the Apple code as a starting place.
/daphne
-------
 1-Sep-83 11:36:39-EDT,1126;000000000001
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 1 Sep 83 11:36:16 EDT
Delivery-Notice: While sending this message to CU20B, the
 CUCS20 mailer was obliged to send this message in 50-byte
 individually Pushed segments because normal TCP stream transmission
 timed out.  This probably indicates a problem with the receiving TCP
 or SMTP server.  See your site's software support if you have any questions.
Date: Thu 1 Sep 83 11:29:20-EDT
From: Daphne Tzoar <CC.DAPHNE@CUCS20>
Subject: Re: pckermit.fix
To: info-kermit@CUCS20
In-Reply-To: Message from "Bruce Nemnich    <Nemnich @ MIT-MULTICS>" of Wed 31 Aug 83 11:26:00-EDT
Keywords: MS-DOS Kermit

 The choice of 20-2F hex (" " through "/") were rather arbitrary.  We
 simply needed a way to get the EXE file from our CMS system to the
 PC.  We never had problems with the space character but if people
 are having trouble downloading because trailing blanks are being
 trimmed, we could change the FIX file.  Any opinions?
/daphne
P.S. On your CMS system, do you have the problem if the file is
     saved as RECFM = F, LRECL = 64?
-------
 1-Sep-83 19:10:57-EDT,396;000000000001
Return-Path: <@CUCS20:BRACKENRIDGE@USC-ISIB>
Received: from CUCS20 by CU20B with DECnet; 1 Sep 83 19:10:55 EDT
Received: from USC-ISIB.ARPA by COLUMBIA-20.ARPA with TCP; Thu 1 Sep 83 19:11:47-EDT
Date:  1 Sep 1983 1603-PDT
Subject: TAC support
From: Billy <BRACKENRIDGE@USC-ISIB>
To: [e-mail]
Keywords: TAC

Has there been any effort to get Kermit to work through a TAC?
-------
 1-Sep-83 19:46:05-EDT,923;000000000001
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 1 Sep 83 19:46:02 EDT
Date: Thu 1 Sep 83 19:46:38-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: TAC support
To: [e-mail], INFO-KERMIT@CUCS20
In-Reply-To: Message from "Billy <BRACKENRIDGE@USC-ISIB>" of Thu 1 Sep 83 19:03:00-EDT
Keywords: TAC

There's been a lot of talk about it, but I have yet to hear exactly what it
is that a TAC does that prevents Kermit from working.  Does it take over
the parity bit?  If that's all, then use SET PARITY.  Does it do some funny
kind of flow control?  Does Kermit send characters that get interpreted as
TAC escape sequences?

By the way, if TOPS-20 is involved, there's a bug in virtual terminal support
in the TCP monitor that prevents terminals from going into binary mode or
something to that effect; I saw a fix for it on the TOPS-20 mailing list.

- Frank
-------
 3-Sep-83 11:11:26-EDT,829;000000000001
Return-Path: <@CUCS20:b-davis@utah-cs>
Received: from CUCS20 by CU20B with DECnet; 3 Sep 83 11:11:24 EDT
Received: from UTAH-CS.ARPA by COLUMBIA-20.ARPA with TCP; Sat 3 Sep 83 11:12:07-EDT
Received: by UTAH-CS.ARPA (3.343.2/3.33.2)
    id AA27824; 3 Sep 83 09:10:08 MDT (Sat)
Date: 3 Sep 83 09:10:08 MDT (Sat)
From: b-davis@utah-cs (Brad Davis)
Message-Id: <[e-mail]>
To: info-kermit@columbia-20
Subject: KERMIT-86
Keywords: Kermit-86, MS-DOS Kermit, Heath/Zenith-100


    We tried to assemble the MS-DOS version of Kermit
    for both an IBM PC (XT) and for a Z100.  The IBM
    version came up with no problems, but we have had
    problems with the Z100 version.  There are 28
    errors (most seem to be IBM bios interrupts).  Any
    help?

    Also is any one changing Kermit to use 2.0 file
    path names and the Z100 2.0 bios calls.


                    Brad Davis
 3-Sep-83 17:37:00-EDT,1927;000000000000
Return-Path: <@CUCS20:Iglesias%UCI.UCI@Rand-Relay>
Received: from CUCS20 by CU20B with DECnet; 3 Sep 83 17:36:57 EDT
Received: from udel-relay.ARPA by COLUMBIA-20.ARPA with TCP; Sat 3 Sep 83 17:37:38-EDT
Date: 02 Sep 83 19:42:24 PDT (Fri)
From: Mike Iglesias <iglesias.uci@Rand-Relay>
Return-Path: <Iglesias%UCI.UCI@Rand-Relay>
Subject: Problem with KERMIT-10
Received: from rand-relay.ARPA by udel-relay.ARPA ; 3 Sep 83 16:59:46 EDT (Sat)
To: info-kermit.UCI@Rand-Relay
Via:  UCI; 2 Sep 83 19:54-PDT
Keywords: DECsystem-10 Kermit, Kermit-10, DEC-10 Kermit

When using KERMIT-10 to transfer a file from a DECsystem-10 to a 4.1bsd
unix system, if the file on the -10 has an extension that is less than
three characters (i.e. FILE.X), the file on the unix system ends up
being "FILE.X  ".  The enclosed change to KERMIT-10 will make KERMIT-10
not pad the extension with blanks and not put the "." in if there is no
extension.
File 1)    DSKC:10KERM.OLD[15,4]    created: 2118 01-Sep-1983
File 2)    DSKC:10KERM.MAC[15,4]    created: 2055 01-Sep-1983

1)21        MOVEI    T1,"."            ; Insert the 'dot'
1)        MOVEM    T1,DAT(S1)        ; And move it in
1)        MOVE    T1,SFDARG        ; Now get the address of the PDB again
1)        MOVE    T2,3(T1)        ; And fetch the word with the extension
1)    SFIL.3:    SETZ    T1,            ; Clear T1
****
2)21        MOVE    T1,SFDARG        ; Now get the address of the PDB again
2)        MOVE    T2,3(T1)        ; And fetch the word with the extension
2)        JUMPE    T2,SFIL.A        ; Skip putting in 'dot' if no extension
2)        MOVEI    T1,"."            ; Insert the 'dot'
2)        MOVEM    T1,DAT(S1)        ; And move it in
2)    SFIL.3:    SETZ    T1,            ; Clear T1
**************
1)21        ADDI    T1,40            ; Change it to ASCII
****
2)21        CAIN    T1,0            ; Reached end of extension?
2)        JRST    SFIL.A            ; Yes, done with file name
2)        ADDI    T1,40            ; Change it to ASCII
**************
1)21        MOVE    T1,NUMTRY        ; If (Numtry <=
1)        SUB    T1,MAXTRY        ;    Maxtry) Then
****
2)21    SFIL.A:    MOVE    T1,NUMTRY        ; If (Numtry <=
2)        SUB    T1,MAXTRY        ;    Maxtry) Then
**************
 6-Sep-83 10:10:25-EDT,1480;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 6 Sep 83 10:10:18 EDT
Date: Tue 6 Sep 83 10:10:40-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: TOPS-10 dialout programs
To: Info-Kermit@CUCS20
Keywords: Kermit-10

Dan Jones at LLL asked whether anyone on the list had seen or heard about a
program to allow use of a dialout modem on a TOPS-10 system, and thought this
would be a nice feature to have implemented in KERMIT.

KERMIT works very nicely with dialout facilities, but it's not a great idea
to put support for that into KERMIT itself, because the operation of an
autodialer tends to be highly dependent on the system, the particular modem
in use, site policy, accounting & billing, etc.  The way autodialers are
installed at some sites (including ours) require special privileges to control.
Since KERMIT should be an ordinary user program, and should be runnable at
every site (due to the wide distribution it gets), it's best to avoid putting
in this kind of special code.

At Columbia, our autodialer is controlled by a system daemon.  A user program
requests the daemon to make make the call and then assign line; the daemon
also writes billing records, etc.  The user program can then run KERMIT in a
lower fork, starting it up with an appropriate SET LINE command.  A similar
arrangement would be possible in TOPS-10, except for the forking.

Is anyone out there running KERMIT-10 with an autodialer?  - Frank
-------
 6-Sep-83 13:00:00-EDT,2329;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 6 Sep 83 12:59:44 EDT
Date: Tue 6 Sep 83 12:59:51-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: [[e-mail]: TAC support]
To: Info-Kermit@CUCS20
Keywords: TAC

There have been a number of inquiries about the use of KERMIT and similar
programs (i.e. MODEM) over ARPANET TACs.  This is the best explanation I've
seen.  I'll look at the MODEM program mentioned below and see how the TAC
support can be fit into KERMIT-20.  - Frank
                ---------------

Mail-From: NOT-LOGGED-IN created at  6-Sep-83 10:59:08
Return-Path: <[e-mail]>
Received: from SIMTEL20.ARPA by COLUMBIA-20.ARPA with TCP; Tue 6 Sep 83 10:59:09-EDT
Date: 6 Sep 1983  08:57 MDT (Tue)
From: [e-mail]
To:   Frank da Cruz <[e-mail]>
Cc:   [e-mail]
Subject: TAC support
In-reply-to: Msg of Thu 1 Sep 83 19:46:38-EDT from Frank da Cruz <cc.fdc at COLUMBIA-20.ARPA>
Keywords: TAC

Frank,

TACs normally run in 7-bit mode, and either the user or the host can
change it to run 8-bit binary.  If the user changes his input mode to
binary, then he can no longer issue further TAC commads and must
depend on the host being able to change it.  Also, in binary mode, the
host must double any FFH characters as FFH is the TELNET intercept
character.

We have been using host user program negotiated binary mode on ITS
with both LMODEM (in MacLisp) and MMODEM (in MIDAS), and on TOPS-20
with MODEM (in MACRO).  (On TENEX, it is sufficient to set binary mode
with SFMOD and the OS takes care of the negotiations.)

For a properly working example of the code required on TOPS-20, FTP a
copy of [SRI-KL]<BILLW>MODEM.MAC.  The n option forces the ARPANET
binary mode negotiations to occur.  (Note that the TACs support any of
input, output, or both binary modes.  With KERMIT, you may only need
to negotiate binary mode in the direction needed.)  MODEM also has the
code to distinguish among the various types of files stored on
TOPS-20: normal ASCII, binary, and ITS binary.  (ITS binary has a
one-word header byte containing DSK8 in SIXBIT.  This is to permit
auto-recognition of binary files on ITS, which has no other way to let
the user know what type the file is, unlike TOPS-20.)

--Frank
-------
 6-Sep-83 15:33:43-EDT,897;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 6 Sep 83 15:33:41 EDT
Date: Tue 6 Sep 83 15:02:34-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Anonymous FTP
To: Info-Kermit@CUCS20
Keywords: ANONYMOUS FTP

Anonymous FTP access to COLUMBIA-20 was inadvertantly turned off over the
weekend during some TOPS-20 system development.  The service is now restored.
Apologies for any inconvenience that may have been caused, and thanks to those
who pointed out the problem for their patience and understanding.  The
intention of the Columbia CS facility management (among whose number I do not
count myself) is to provide anonymous FTP access to publicly readable files
on this machine; should anonymous access ever stop working again without
warning, please report it promptly, but also bear in mind that any such
disruptions in service are unintentional.  - Frank
-------
 6-Sep-83 17:08:25-EDT,982;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 6 Sep 83 17:08:19 EDT
Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Tue 6 Sep 83 17:08:48-EDT
Date: Tue 6 Sep 83 14:08:06-PDT
From: Mark Crispin <[e-mail]>
Subject: Re: [[e-mail]: TAC support]
To: [e-mail]
cc: [e-mail]
In-Reply-To: Message from "Frank da Cruz <[e-mail]>" of Tue 6 Sep 83 10:42:57-PDT
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: [phone] (Stanford); [phone] (residence)
Keywords: TAC

Frank -

     There is a monitor bug in the TCP-based versions of TOPS-20 that
should prevent 8-bit binary mode from working in the host=>user direction.
The fix is to patch location NVTDOD from SETZ R to SETZ RSKP.  That should
cause the TAC command @B O S to work.

     @B I S to the TAC should work now to cause 8-bit binary mode to work.

-- Mark --
-------
 6-Sep-83 20:33:54-EDT,1220;000000000000
Return-Path: <@CUCS20:GILLMANN@USC-ISIB>
Received: from CUCS20 by CU20B with DECnet; 6 Sep 83 20:33:49 EDT
Received: from USC-ISIB.ARPA by COLUMBIA-20.ARPA with TCP; Tue 6 Sep 83 20:34:25-EDT
Return-Path: <WMT@MIT-XX>
Received: FROM MIT-XX BY USC-ISIB.ARPA WITH TCP ; 6 Sep 83 15:38:29 PDT
Date:  6 Sep 1983 1836-EDT
From: Willie <WMT@MIT-XX>
Subject: about Kermit ...
To: info-ibmpc@USC-ISIB
cc: info-vax-request@SRI-CSL
Remailed-Date:  6 Sep 1983 1734-PDT
Remailed-From: Dick Gillmann <[e-mail]>
Remailed-To: [e-mail], wmt@MIT-XX
Keywords: UNIX Kermit, MS-DOS Kermit

Recently, I installed a copy of Kermit on a VAX running Berkeley Unix
version 4, the program works fine when transporting files from the PC
to the VAX, but does not work in the other direction -- it timed out
on waiting for an initial acknowledgment from the PC. Has anyone out
there encountered such a problem or similar ones? If so, any idea on
fixing it? Would appreciate any infomation on this. If not, I'll have
to read through the Kermit documentation and protocols manual, which
is a little too time consuming for me.

Comments, suggestions etc, please forward to Wmt@MIT-XX.

Happy Hacking !!!

--- Wmt@XX

-------
 7-Sep-83 08:55:03-EDT,2946;000000000001
Return-Path: <@CUCS20:steven@brl-bmd>
Received: from CUCS20 by CU20B with DECnet; 7 Sep 83 08:54:59 EDT
Received: from BRL-BMD by COLUMBIA-20.ARPA with TCP; Wed 7 Sep 83 08:55:34-EDT
Date:     Wed, 7 Sep 83 8:45:07 EDT
From:     Steve Segletes (TBD) <steven@brl-bmd>
To:       Willie <WMT@mit-xx>
cc:       info-ibmpc@usc-isib, info-kermit@columbia-20
Subject:  Re:  about Kermit ...
Keywords: UNIX Kermit, MS-DOS Kermit

Here is a message I sent to a friend of mine who implemented UNIX Kermit
running under JHU UNIX at BRL.  Since then, we have discussed which things
are bugs and which are features.  Regardless, this is how Kermit performed
on our system.  I might point out that the UNIX to PC batch mode download
did not work on our Berkely VAX either, so that the bug, as you seem to have
found, exists in the original coding and not our JHU implementation.

Steven Segletes
<steven@brl>
US Army Ballistic Research Laboratory
--------------------





Date:     Mon, 29 Aug 83 9:27:57 EDT
From:     Steve Segletes (TBD)  <steven@BRL-BMD>
To:       howard@BRL-BMD
cc:       steven@BRL-BMD
Subject:  kermit on BMD-70
Keywords: BMD-70 Kermit

    I will summarize my experiences with Kermit, so as to provide you with
info you might see as valuable.  The usages which I have had success with are
as follows:
kermit -s filename
kermit -r
kermit -so filename        object file transfer
kermit -ro

Uploading***

For a single file transfer, UNIX kermit (Ukermit) should allow a file name to
be specified (which is allowed to be different than the filename being sent).
Example (CAPS specify PC commands):
    kermit -r file1
    SEND TEST.LST
should result in PC file TEST.LST being uploaded as file1 on UNIX.  The
transfer proceeds, but the final Unix file has the name TEST.LST

Downloading***

When multiple files are downloaded, e.g.
    kermit -s *
    RECEIVE
the first file in the transfer is successfully transferred, but all subsequent
files in the batch mode transfer are identical, and comprised of junk from
the first successful transfer.  We spoke of this in the carpool, and you
thought it had something to do the buffer flushing algorithm.

When sending is initiated as follows:
    kermit -s ../filename
    RECEIVE
the PC kermit gasps on the ../ part of the filename.  It seems that Ukermit
should strip off all the filename info up to the final "/", but doesn't.

*************

Finally, the usage statement included with Ukermit is quite confusing, (though
maybe not technically incorrect).  I believe that the "-" is not required when
specifying options:
    kermit s filename
should work, I believe.  However, all options must be specified together:
    kermit -so filename         (works)
    kermit -s -o filename        (tries to send ASCII files -o and
                    filename)
All in all, it is quite usable now in its present state, even without batch
mode download, since object mode download is INCREDIBALLY useful (even one at
a time).

Steve






 7-Sep-83 11:54:43-EDT,2792;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 7 Sep 83 11:54:35 EDT
Date: Wed 7 Sep 83 11:52:58-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: UNIX Kermit vs IBM PC Kermit
To: Info-Kermit@CUCS20
Keywords: UNIX Kermit, MS-DOS Kermit

In response to several messages about Kermit between the IBM PC and UNIX...

First, there are several bugs in UNIX Kermit that have been identified and
fixed, notably the wildcard send business.  The new UNIX Kermit (which also
has support added for various non-Berkeley UNIX systems and some performance
improvements) is being tested and will be announced shortly.  It will not be,
however, the last version we'll see.  Several improvements still have to be
made in the short term -- standardization of file specifications in the file
header packet (case conversion, removal of directory path, etc), addition of
error packet processing, etc.  In the longer term, UNIX Kermit will also have
server mode added.

Somebody suggested that UNIX Kermit should let you say "kermit r foo.bar" to
let the incoming file be stored under a different name than it was sent with.
This is, in fact, a major source of confusion since many Kermits have this
feature.  The confusion arises because different Kermits interpret this
command differently:  Kermits that talk to servers (e.g. the IBM PC and CP/M
Kermits) pass the given filespec to the server in a request for the server to
send it, whereas some other Kermits (like IBM VM/CMS and DEC-20 Kermits) use
the given filespec to override the one that comes in a file header packet.

Could it be that people who are having trouble transferring files from UNIX to
the PC are giving the command "receive filespec" to the PC, rather than just
"receive"?  That would certainly explain the problem, since the former causes
the PC to send a server-mode command to UNIX Kermit, which UNIX Kermit doesn't
understand.

The whole "receive filespec" business was probably a mistake to begin with.
When it's being used to override filenames from incoming file header packets,
it's only effective for a single file (not an entire wildcard batch transfer),
so its usefulness for that purpose is limited.  Since it can also be used to
ask a server to send the specified file, the meaning may not be clear.  For
consistency it would be better to have all versions of Kermit use the
following conventions:

send filespec       send the specified local file

receive             receive remote files, storing them under the name from
                    the file header.

receive filespec    receive a single remote file, storing it under the
                    specified local name.

get filespec        Ask the server to send the specified remote file.

Comments?  - Frank
-------
 7-Sep-83 13:52:53-EDT,900;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 7 Sep 83 13:52:49 EDT
Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Wed 7 Sep 83 13:53:23-EDT
Date: Wed 7 Sep 83 10:52:35-PDT
From: Ted Markowitz <[e-mail]>
Subject: VM Kermit - IBM PC Kermit
To: [e-mail]
Keywords: VM/CMS Kermit, MS-DOS Kermit
Cross-Ref: CMS Kermit (see also VM/CMS Kermit)

I've had trouble with getting a PC version of Kermit to talk to
a VM version. These both work with the latest DEC-20 product, however.
Basically the PC Kermit never seems to get the initiate message from
VM. The IBM hardware is this: a 3705 communications controller running
NCP and NTO (this allows ASCII terminal access). I've tried all the
parity settings allowable and gave the PC Kermit a nudge by typing
several Returns to try to wake the connection up. But, to no avail.

Any help or ideas would be appreciated.

--ted
-------
 7-Sep-83 14:36:45-EDT,1303;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 7 Sep 83 14:36:37 EDT
Date: Wed 7 Sep 83 14:36:24-EDT
From: Daphne Tzoar <CC.DAPHNE@CUCS20>
Subject: New IBM PC Kermit available
To: info-kermit@CUCS20, [e-mail]
Keywords: MS-DOS Kermit

A new version of Kermit for the IBM PC is now available for testing.
The pertinent files are PCKERMIT.TST (source) and PCKERMFIX.TST (the
"FIX" file) on Columbia-20 in the KERMIT directory.  Please try it
out and let me know about any problems you encountered.  Here's a
list of changes for version 1.19:

 [19] (a) Change NOUT to print numbers in decimal instead of hex.
      Routine is based on the one used in Generic Kermit.  Make a
      cosmetic change where print filenames & remove extraneous screen
      output.  (b) Change INCHR to allow timeouts when receiving data.
      In SERINT, change the TEST to a CMP - flag not set as needed.
      Add Set timeout and fix SPAR to get timeout value from init packet.
      Add "nop" in NAK because the jump to ABORT is only 2 bytes.

 [18] A NAK for the next packet is not the same as an ACK for the
      current packet if we're in Send-Init.  Also, account for
      wraparound when comparing packet numbers that are off by one.

/daphne
-------
 7-Sep-83 19:11:36-EDT,482;000000000000
Return-Path: <@CUCS20:CERRITOS@USC-ECL>
Received: from CUCS20 by CU20B with DECnet; 7 Sep 83 19:11:32 EDT
Received: from USC-ECL by COLUMBIA-20.ARPA with TCP; Wed 7 Sep 83 19:12:41-EDT
Date:  7 Sep 1983 1449-PDT
From: Bruce Tanner <CERRITOS@USC-ECL>
Subject: HP 3000 Kermit
To: INFO-KERMIT@COLUMBIA-20
Keywords: HP-3000 Kermit

A friend of mine would like to transfer files from a HP3000 to a Rainbow.
Does anyone know about a version of Kermit that runs on a HP3000?

Thanks,
-Bruce
-------
 8-Sep-83 09:56:49-EDT,1022;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 8 Sep 83 09:56:45 EDT
Date: Thu 8 Sep 83 09:58:05-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: [Bruce Tanner <CERRITOS@USC-ECL>: CPM3 Kermit]
To: Info-Kermit@CUCS20
Keywords: CP/M Kermit

A hint for anyone who has been trying to run CP/M Kermit under CP/M-Plus...
                ---------------

Return-Path: <CERRITOS@USC-ECL>
Received: from USC-ECL by COLUMBIA-20.ARPA with TCP; Wed 7 Sep 83 19:12:25-EDT
Date:  7 Sep 1983 1447-PDT
From: Bruce Tanner <CERRITOS@USC-ECL>
Subject: CPM3 Kermit
To: CC.FDC@COLUMBIA-20
Keywords: CP/M Kermit

One thing that wasn't made clear anywhere was that CP/M+ Kermit uses the
AUXIN: and AUXOUT: (sometimes refered to as AXI: and AXO:) logical devices.
The CP/M+ user must use the DEVICE program (supplied by with CP/M+) to
establish the connection between the AUX devices and some physical device
and to set up baud rates, etc.  This info should be tucked away somewhere
in the documentation.
-Bruce
-------
-------
 9-Sep-83 10:42:45-EDT,619;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 9 Sep 83 10:42:42 EDT
Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Fri 9 Sep 83 10:43:39-EDT
Date: Fri 9 Sep 83 07:42:38-PDT
From: Norm Kincl <[e-mail]>
Subject: CPM/86, TELENET
To: [e-mail]
Reply-To: [e-mail]-West
Keywords: CPM/86 Kermit

Hi-
A friend who is not on ARPAnet or CSnet asked me to bring up these two
questions:

1) Is there a CPM/86 version of KERMIT?
2) Has anyone been able to get KERMIT to work over TELENET (or other
packed switching networks)?

-Norm
-------
 9-Sep-83 11:57:09-EDT,832;000000000000
Return-Path: <@CUCS20:b-davis@utah-cs>
Received: from CUCS20 by CU20B with DECnet; 9 Sep 83 11:57:01 EDT
Received: from UTAH-CS.ARPA by COLUMBIA-20.ARPA with TCP; Fri 9 Sep 83 11:57:58-EDT
Received: by UTAH-CS.ARPA (3.343.2/3.33.3)
    id AA01270; 9 Sep 83 09:52:27 MDT (Fri)
Date: 9 Sep 83 09:52:27 MDT (Fri)
From: b-davis@utah-cs (Brad Davis)
Message-Id: <[e-mail]>
To: info-kermit@columbia-20
Subject: HP 9836 (model 200?) and Z100 Kermit
Keywords: HP-9836 Kermit

We have taken the RTKERMIT and have rewritten it for the HP 9836
(in their derivitive of UCSD Pascal).  It works but still has
some bugs.  We are adding binary support and a more consistant
interface to the serial port.  We will also leave it in a some
what more portable form.

As for the Z100 we will work it over (sometime).

                Brad Davis
 9-Sep-83 14:09:43-EDT,1045;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 9 Sep 83 14:09:38 EDT
Date: Fri 9 Sep 83 14:09:50-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: CPM/86, TELENET
To: [e-mail], Info-Kermit@CUCS20
In-Reply-To: Message from "Norm Kincl <[e-mail]>" of Fri 9 Sep 83 10:43:48-EDT
Keywords: CPM/86 Kermit

Bill Catchings and I are about to embark on a "native" CP/M-86 Kermit for the
Rainbow, either in ASM86, or based on the present UNIX 'C' version.  More news
as it develops.

I have used KERMIT successfully over TELENET; to get it to work, I had to
SET PARITY ODD, which precludes transmission of binary files (at least until
the 8th-bit-quoting mechanism is implemented in your version of Kermit --
The SOURCE, which is accessed over TELENET, has written an 8th-bit-quoting,
server mode Kermit in PL/I for their PR1ME computer, and added 8th-bit quoting
to the IBM PC version, to get around this problem; again, more news about this
as it develops).

- Frank
-------
 9-Sep-83 14:22:08-EDT,863;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 9 Sep 83 14:22:02 EDT
Date: Fri 9 Sep 83 14:14:26-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: HP 9836 (model 200?) and Z100 Kermit
To: [e-mail], info-kermit@CUCS20
In-Reply-To: Message from "b-davis@utah-cs (Brad Davis)" of Fri 9 Sep 83 09:52:27-EDT
Keywords: HP-9836 Kermit

Glad to hear the news about your Kermit in Pascal for the P-System on the
HP 9836; some other places have been asking for that.  It turns out that
Cornell has also done Kermit in Pascal for the P-System, this time on the
Terak; I haven't received it yet.  I hope the two versions can be combined,
perhaps by putting all the system dependent portions in a separate module.
If you want to talk to the people at Cornell and compare notes, let me know
and I'll put you in touch.  - Frank
-------
13-Sep-83 11:24:24-EDT,1121;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 13 Sep 83 11:24:10 EDT
Received: from CISL-SERVICE-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Tue 13 Sep 83 11:24:29-EDT
Received: from SYSTEM-M.PHOENIX.HONEYWELL by CISL-SERVICE-MULTICS.ARPA dial; 13-Sep-1983 11:11:09-edt
Date:     12 September 1983 1730-mst
From:     Kevin B. Kenny    <Kenny.OSNI @ SYSTEM-M.PHOENIX.HONEYWELL>
Subject:  Re: CPM/86, TELENET   (INFO-KERMIT [0030])
To:       CC.FDC @ COLUMBIA-20
CC:       INFO-KERMIT @ COLUMBIA-20
Reply-To: Kenny.OSNI%PCO-Multics @ CISL-SERVICE-MULTICS
Keywords: CPM/86 Kermit

In your message regarding Kermit use over Telenet, you refer to an
8th-bit-quoting mode.  Is there a spec for this?  I'm looking at the
possibility of porting Kermit to some Honeywell systems that have the
same problem of a non-transparent transmission channel.  Also, has any
thought been given to quoting other characters?  Some of our front ends
have character-delete and line-delete sequences that can't be disabled.

thx 1.0e6    /k**2    (Kenny.OSNI%PCO-Multics@CISL-Service-Multics)
13-Sep-83 21:19:25-EDT,1617;000000000000
Return-Path: <@CUCS20:Iglesias%UCI.UCI@Rand-Relay>
Received: from CUCS20 by CU20B with DECnet; 13 Sep 83 21:19:21 EDT
Received: from udel-relay.ARPA by COLUMBIA-20.ARPA with TCP; Tue 13 Sep 83 21:21:01-EDT
Date: 13 Sep 83 08:32:47 PDT (Tue)
From: Mike Iglesias <iglesias.uci@Rand-Relay>
Return-Path: <Iglesias%UCI.UCI@Rand-Relay>
Subject: KERMIT on XT w/DOS 2.0
Received: from rand-relay.ARPA by udel-relay.ARPA ; 13 Sep 83 21:19:05 EDT (Tue)
To: info-kermit.UCI@Rand-Relay, info-ibmpc@Usc-Isib
Cc: grich.UCI@Rand-Relay, sir2!mike%uucp.UCI@Rand-Relay
Via:  UCI; 13 Sep 83 17:41-PDT
Keywords: MS-DOS Kermit

I had problems running KERMIT on an XT with DOS 2.0.  It appears that
KERMIT is sending the first character (^A) repeatedly.  I traced the
problem to the following code (the dashed lines are mine):

outchr: mov al,ah               ; Char must be in al.
    mov cx,0
    call dopar        ; Set parity appropriately.     [10]
outch1: mov ah,1                ; Output it.
    mov dx,0
        int comm
;-------------------------------------------------
    cmp ah,00H
    je outch3
    loop outch1
     jmp r
;-------------------------------------------------
outch3:    jmp rskp

I ran KERMIT with the debugger and found that after the 'int comm',
ah was non-zero.  Looking at the BIOS listing for the XT, ah has the
status of the line unless the character couldn't be sent, in which case
bit 7 is set in ah.  If I remove the code between the dashed lines,
it seems to work.  To all you XT wizards out there:  what code should
be between the dashed lines to make it run properly on an XT?

Thanks for any help you can provide.
14-Sep-83 11:52:11-EDT,1265;000000000000
Return-Path: <@CUCS20:WLIM@MIT-XX>
Received: from CUCS20 by CU20B with DECnet; 14 Sep 83 11:52:04 EDT
Received: from MIT-XX by COLUMBIA-20.ARPA with TCP; Wed 14 Sep 83 11:52:58-EDT
Date: 14 Sep 1983 1151-EDT
From: Willie Lim <WLIM@MIT-XX>
Subject: KERMIT Dialup Problems
To: info-kermit@COLUMBIA-20
Keywords: Dialup

I have problems uploading files from my PC or XT to my host machine
(MIT-XX).  Except for one rare instance many months ago, where I
managed to get something over to MIT-XX, I have not been able to
transfer any files over since.  I also have problems downloading big
files (over 50K bytes or so).  A colleague of mine using exactly the
same software have had no problems at all with the uploading and
downloading of files some as big as PCKERMIT.TST.  The only difference
between the two situations is that I live some distance away from
MIT-XX (about 15 miles) while my colleague lives on campus.
Note: The VT52 terminal emulator works fine for me.

The message that I keep getting for uploading files is:
    "?Kermit-20: Retry count exhausted in RDATA"

For downloading files, the communication hangs frequently and the
percentage of number of retries to the number of packets transmitted
is sometimes as high as 30%.


Willie
-------
14-Sep-83 12:35:01-EDT,1814;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 14 Sep 83 12:34:58 EDT
Date: Wed 14 Sep 83 12:36:18-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: KERMIT Dialup Problems
To: [e-mail], info-kermit@CUCS20
In-Reply-To: Message from "Willie Lim <WLIM@MIT-XX>" of Wed 14 Sep 83 11:51:00-EDT
Keywords: Dialup

It's hard to tell what the problem might be without more evidence to look at.
Kermit-20 includes packet logging features that would provide the necessary
information.  However, the symptoms could certainly be explained by a noisy
connection, or some other phenomenon peculiar to remote lines or the way your
DEC-20 handles them.  In any case, Kermit-20 lets you manipulate the timeout
interval, the retry threshhold, and other quantities, so if the line is truly
noisy (or your DEC-20 front end overburdened) you can change these to fit
the conditions, for instance

SET SEND TIMEOUT 20         ; Allow more time for incoming packets
SET RETRY PACKETS 20         ; Allow up to 20 retries
SET RECEIVE PACKET-LENGTH 40 ; Tell the PC to send shorter packets

Shortening the packets reduces the probability that a packet will be hit by
noise (or will arrive at the DEC-20 front end at a bad time), and reduces the
overhead when a packet does have to be retransmitted.

I've found that certain sites have a lot of trouble with Kermit on the DEC-20,
sometimes only on certain kinds of lines (like remote but not local), and that
these are often the sites that have hacked their monitors or front ends.  One
site was unable to use Kermit (or anything like it) at all because of a change
they made to their scheduler...

Anyway, if none of this helps, do this:

SET DEBUGGING PACKETS
SET DEBUGGING LOG-FILE

and then send me the log.  - Frank
-------
14-Sep-83 17:43:24-EDT,2116;000000000001
Return-Path: <@CUCS20:GILLMANN@USC-ISIB>
Received: from CUCS20 by CU20B with DECnet; 14 Sep 83 17:43:18 EDT
Received: from USC-ISIB.ARPA by COLUMBIA-20.ARPA with TCP; Wed 14 Sep 83 16:11:47-EDT
Return-Path: <WANUGA@MIT-XX>
Received: FROM MIT-XX BY USC-ISIB.ARPA WITH TCP ; 14 Sep 83 05:58:44 PDT
Date: 14 Sep 1983 0124-EDT
From: Thomas S. Wanuga <WANUGA@MIT-XX>
Subject: KERMIT bugs
To: info-ibmpc@USC-ISIB
cc: wanuga@MIT-XX
Remailed-Date: 14 Sep 1983 1309-PDT
Remailed-From: Dick Gillmann <[e-mail]>
Remailed-To: [e-mail]
Keywords: MS-DOS Kermit

I cannot send mail to COLUMBIA-20.  Could you please forward the
following to a relevant person there, and include it in INFO-IBMPC if
you think that would be appropriate.  Thank you very much.

I have tried PCKERMIT.TST (Version 1.19) with my IBMPC and MIT-XX
(TOPS-2).  I seem to be having a slight problem with this version.
Every once and a while (usually when I type ahead fast) things seem to
hang (that is, I stop receiving characters from MIT-XX).  I can get
things back to normal by escaping back to the PC (with <ctrl>]c), then
CONNECTING back to the host.  I never noticed this problem with
PCKERMIT.NEW (Version 1.3).  The version of KERMIT for TOPS-20 that I
am using says "TOPS-20 KERMIT version 3A(62)" when I start it up.

I tried the following experiment with both versions (1.19 and 1.3).  I
connected to TOPS-20 and typed the following as fast as I could:

    "f wanuga<cr>f op".

Note that "f" is short for "finger".  It would take me about three
tries to get the hung problem with Version 1.19, but I could not get
Version 1.3 to hang at all.

Another problem that I have been having is with uploading/downloading
.EXE files (the IBMPC type).  When I upload an .EXE file from my IBMPC
to TOPS-20, the file size remains unchanged.  But when I download an
.EXE file from TOPS-20 to my IBMPC, two bytes are always added to the
end of the file.

Have you noticed these problems at all, and if so, do you know how I
might get around them?  Thanks for your help.

Tom Wanuga
WANUGA@MIT-XX
-------
14-Sep-83 21:38:30-EDT,1326;000000000000
Return-Path: <@CUCS20:CC.DAPHNE%COLUMBIA-20.UCI@Rand-Relay>
Received: from CUCS20 by CU20B with DECnet; 14 Sep 83 21:38:25 EDT
Received: from udel-relay.ARPA by COLUMBIA-20.ARPA with TCP; Wed 14 Sep 83 21:39:59-EDT
Date: Wed 14 Sep 83 12:06:19-EDT
From: Daphne Tzoar <CC.DAPHNE@COLUMBIA-20>
Return-Path: <CC.DAPHNE%COLUMBIA-20.UCI@Rand-Relay>
Subject: Re: KERMIT on XT w/DOS 2.0
Received: from COLUMBIA-20.ARPA by rand-relay.ARPA ; 14 Sep 83 09:05:51 PDT (Wed)
Received: from Rand-Relay by UCI for info-kermit; 14 Sep 83 17:07-PDT
Received: from rand-relay.ARPA by udel-relay.ARPA ; 14 Sep 83 21:25:25 EDT (Wed)
To: iglesias.uci@RAND-RELAY
Cc: info-kermit.UCI@RAND-RELAY, info-ibmpc@USC-ISIB, grich.UCI@RAND-RELAY,
        sir2!mike%uucp.UCI@RAND-RELAY
In-Reply-To: Message from "Mike Iglesias <iglesias.uci@Rand-Relay>" of Tue 13 Sep 83 08:32:47-EDT
Via:  UCI; 14 Sep 83 18:02-PDT
Keywords: MS-DOS Kermit

The problem you mentioned is due to a ROM BIOS error.  The way we got
around it was to not use the INT routine and just write the character
out to the port directly.  The code was modified by the folks at CMU
since the older versions of Kermit were not able to transfer files
with the IBM PC/XT.  All newer versions of the Kermit code have the
correction so maybe you should just get the newer files.

/daphne
-------
15-Sep-83 11:06:11-EDT,1658;000000000000
Return-Path: <@CUCS20:WANUGA@MIT-XX>
Received: from CUCS20 by CU20B with DECnet; 15 Sep 83 11:05:56 EDT
Received: from MIT-XX by COLUMBIA-20.ARPA with TCP; Thu 15 Sep 83 11:07:22-EDT
Date: 14 Sep 1983 1353-EDT
From: Thomas S. Wanuga <WANUGA@MIT-XX>
Subject: IBMPC v1.19 bugs
To: info-kermit@COLUMBIA-20
Keywords: MS-DOS Kermit

I have tried PCKERMIT.TST (Version 1.19) with my IBMPC and MIT-XX
(TOPS-20).  I seem to be having a slight problem with this version.
Every once and a while (usually when I type ahead fast) things seem to
hang (that is, I stop receiving characters from MIT-XX).  I can get
things back to normal by escaping back to the PC (with <ctrl>]c), then
CONNECTING back to the host.  I never noticed this problem with
PCKERMIT.NEW (Version 1.3).  The version of KERMIT for TOPS-20 that I
am using says "TOPS-20 KERMIT version 3A(62)" when I start it up.

I tried the following experiment with both versions (1.19 and 1.3).  I
connected to TOPS-20 and typed the following as fast as I could:

    "f wanuga<cr>f op".

Note that "f" is short for "finger".  It would take me about three
tries to get the hung problem with Version 1.19, but I could not get
Version 1.3 to hang at all.

Another problem that I have been having is with uploading/downloading
.EXE files (the IBMPC type).  When I upload an .EXE file from my IBMPC
to TOPS-20, the file size remains unchanged.  But when I download an
.EXE file from TOPS-20 to my IBMPC, two bytes are always added to the
end of the file.

Have you noticed these problems at all, and if so, do you know how I
might get around them?  Thanks for your help.

Tom Wanuga
WANUGA@MIT-XX
-------
15-Sep-83 13:04:04-EDT,4250;000000000001
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 15 Sep 83 13:03:30 EDT
Date: Thu 15 Sep 83 13:05:01-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Kermit "RFC No. 1"
To: Info-Kermit@CUCS20
Keywords: Kermit Protocol

In the ARPAnet tradition of testing any new idea out on its intended victims
before casting it into concrete (or silicon), here are a couple new ideas for
the KERMIT protocol, presented as a "Request For Comments" (RFC).  If no one
can think of any serious objections to them, I'll add them to the protocol
manual and code them into KERMIT-20 for testing.  Comments will be
appreciated, especially from anyone who has had some experience writing or
fixing some implementation of Kermit (or some other protocol).

1. Interruption of file transfer.  How many times have you transferred a file
you didn't mean to and wished you could stop the transfer gracefully?  Here's
the proposed mechanism:

   a. To interrupt sending a file, simply send an EOF ("Z") packet in place of
the next data packet, including a "D" (for Discard) in the data field.  The
recipient ACKs the Z packet normally, but does not retain the file.  This will
not interfere with older Kermits on the receiving end; they will not inspect
the data field and will close the file normally.  The mechanism can be
triggered by the sender typing an interrupt character.  If a (wildcard) file
group is being sent, it is possible to skip to the next file or to terminate
the entire batch; the protocol is the same in either case, but the desired
action could be selected by different interrupt characters, e.g. CTRL-X to skip
the current file, CTRL-Z to skip the rest of the batch.

   b. To interrupt receiving a file, put an "X" in the data field of an ACK for
a data packet.  To interrupt receiving an entire file group, use a "Z".  The
mechanism could be triggered in the same way as above.  A sender that was aware
of the new feature, upon finding one of these codes, would act as described
above, i.e. send a "Z" packet with a "D" code; an older sender would simply
ignore the codes and continue sending.

2. Putting information in the data field of an ACK packet can be useful
elsewhere too.  One application springs to mind: the ACK for a file header
packet can contain the name under which the recipient will store the file.
This is useful when the recipient must change the file name to suit local
naming conventions or to avoid filename conflicts.  Old senders will not notice
the information in the ACK and will behave as before, but new ones will be able
to display the information on the screen so you'll know where to find the file
on the receiving system.

3. Various server functions have been mentioned in the protocol manual, but
only the most basic ones have been implemented so far: send/receive files,
finish, and bye.  In order to implement other functions successfully,
particularly ones that require information to be transferred -- directory
listings and so forth -- the two Kermits should be able to configure themselves
to one another beforehand, as they do before a file transfer, with respect to
packet size, timeout, padding, the various prefix characters & quoting options,
etc.  There is presently no provision for this.  The proposed addition is an
"I" packet, whose contents are exactly like an "S" (Send-Init) packet, and
which is ACK'd in the same way.  The only difference is that an "S" packet
tells the receiving Kermit (server or not) that one or more files are on the
way, whereas the "I" packet will be strictly informational and will not trigger
transition into another state.  The user requesting a function of a server may
optionally precede any request with an "I" packet; if an "I" is not sent, one
or both sides will use default or previous values for the Send-Init paramaters.
Servers that do not know about the new "I" packet will respond with an error
message but will remain in operation.  Although use of the "I" packet will
(must) be optional, it is recommended before each transaction since one side
has no way of knowing whether the other side has been restarted or had its
parameters reset or changed in some other way.

- Frank
-------
15-Sep-83 16:25:07-EDT,654;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 15 Sep 83 16:25:02 EDT
Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Thu 15 Sep 83 16:26:30-EDT
Date: Thu 15 Sep 83 13:20:44-PDT
From: Ted Markowitz <[e-mail]>
Subject: Batch running of Kermit
To: [e-mail]
Keywords: Batch, Kermit-20

Has anyone tried to use Kermit underneath an auto-dialer
program in a batch environment? What I'm trying to do
is set up an off-hours file transfer capability so as to
avoid higher phone and CPU charges.

I'm referring here to a TOPS-20 Kermit. Any help would be
appreciated.

--ted
-------
15-Sep-83 19:51:03-EDT,1074;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 15 Sep 83 19:50:59 EDT
Date: Thu 15 Sep 83 19:52:07-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: Batch running of Kermit
To: [e-mail], info-kermit%CUCS20@CUCS20
In-Reply-To: Message from "Ted Markowitz <[e-mail]>" of Thu 15 Sep 83 16:26:39-EDT
Keywords: Batch, Kermit-20

Kermit-20 is designed to be runnable under batch, though I've never tried it.
For instance, although it normally traps control-C, it does not try to do so
under batch, which would deny it that capability.  The major problem you'd
encounter (I think) would be the processing of error messages.  Almost any
message will come out with a "?" in first position, which would normally
terminate the batch job; there's presently no distinction between "warning"
messages and "fatal" error messages, nor is it easy to see how there can be
since a message is just as likely to originate from the remote side as from the
local.  Anyway, give it a try and let me know the results.  Good luck!
- Frank
-------
16-Sep-83 11:44:14-EDT,1335;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 16 Sep 83 11:44:08 EDT
Date: Fri 16 Sep 83 11:44:29-EDT
From: Richard Garland <G.GARLAND@CUCS20>
Subject: Apple Kermit configuration
To: Info-Kermit@CUCS20

I have just been through the process of configuring and downloading
Kermit to an Apple for one of my users.  He points out that he often
has to move things around in his machine to different slots.  (his
is a lab system with D/A and other interfaces.)  This shuffling around
is due (he says) since it seems like everyone has fixed ideas about
which gizmo should go where and they all conflict.  (For example
he has 3 interfaces/programs which all want slot 2.)

He says a program could figure out in most cases where the desired
interface is plugged it.  In particular he has another communications
program which he says can find his Super Serial card no matter where
he plugs it.  Could Kermit-65 do this?  It would save us and a lot
of others considerable grief.  Maybe a SET command if not dynamic
configuration.  Also how about a SET command for D.C.Hayes vs.
Serial Card?  That may be too much to ask but it would certainly
be wonderful to have 1 version of Kermit for my 4 Apples, which
at the moment have different slots/cards combinations.

                    Rg
-------
16-Sep-83 14:42:33-EDT,721;000000000000
Return-Path: <@CUCS20:Nemnich@MIT-MULTICS>
Received: from CUCS20 by CU20B with DECnet; 16 Sep 83 14:42:30 EDT
Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Fri 16 Sep 83 14:43:06-EDT
Date:     Fri, 16 Sep 83 14:33 EDT
From:     Bruce Nemnich    <Nemnich @ MIT-MULTICS>
Subject:  Re: Apple Kermit configuration
To:       Richard Garland    <G.GARLAND @ COLUMBIA-20>
CC:       Info-Kermit @ COLUMBIA-20

Yes, in one can determine what slot a given card is in by looking for
specific bytes in the card's ROM.  Depending on what slot the card is
in, the ROM will be mapped to a different address range.  Some care must
be taken to ensure the bytes are unique to the card in question, of
course.
16-Sep-83 17:02:40-EDT,842;000000000000
Return-Path: <@CUCS20:OC.SITGO@CU20B>
Received: from CUCS20 by CU20B with DECnet; 16 Sep 83 17:02:33 EDT
Received: from CU20B by CUCS20 with DECnet; 16 Sep 83 17:02:23 EDT
Date: Fri 16 Sep 83 17:01:53-EDT
From: "Nick Bush" <OC.SITGO@CU20B>
Subject: Re: Apple Kermit configuration
To: G.GARLAND@CUCS20
cc: Info-Kermit@CUCS20
In-Reply-To: Message from "Richard Garland <G.GARLAND@CUCS20>" of Fri 16 Sep 83 11:44:17-EDT

Certainly it would be possible for Kermit-65 to determine where the
card was located.  In fact, it was considered while it was being
written and only left out because of a lack of time.  I don't
know how reasonable it would be for a single copy of Kermit-65 to
have the support for different cards - there might be routine name
conflicts.  I'll pass the comments on to the author.

                    Nick Bush
-------
17-Sep-83 14:10:05-EDT,625;000000000000
Return-Path: <@CUCS20:WANUGA@MIT-XX>
Received: from CUCS20 by CU20B with DECnet; 17 Sep 83 14:10:02 EDT
Received: from MIT-XX by COLUMBIA-20.ARPA with TCP; Sat 17 Sep 83 14:10:00-EDT
Date: 17 Sep 1983 1408-EDT
From: Thomas S. Wanuga <WANUGA@MIT-XX>
Subject: NEC APC
To: info-kermit@COLUMBIA-20
cc: wanuga@MIT-XX, JPRESTIVO@MIT-XX

Does a version of Kermit exist for the NEC APC, or is anyone working
on one?  Since the NEC APC has an 8086, how hard would it be to modify
the IBMPC version to run on the APC?  Would it run without any changes
under MS-DOS 1.1 or MS-DOS 2.0?

Tom Wanuga
WANUGA@MIT-XX
-------
17-Sep-83 19:01:10-EDT,979;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 17 Sep 83 19:01:06 EDT
Received: from FORD-WDL1.ARPA by COLUMBIA-20.ARPA with TCP; Sat 17 Sep 83 19:01:03-EDT
Return-Path:<>
Date: 17-Sep-83 16:00:26-PDT
From: [e-mail]
Subject: KERMIT in WC
To: [e-mail]

I have a KERMIT in Whitesmith's C, running on Idris (Whitesmiths'
imitation v6 Unix).  I hope that there is not much need for this,
since Idris is no fun to use, but if anyone needs it, this will spare
them the work.

This version is based on the Portable Unix KERMIT, but it doesn't
have all the fixes (yet).  The necessary changes were massive enough
that it didn't seem fair to the rest of the world to conditionalize
the Portable KERMIT.  Besides, we just made it run today.

We are running IDRIS-68K on a Chromatics CGC7900.


walter underwood

UUCP:  fortune!wdl1!wunder
ARPA:  wunder@FORD-WDL1
Phone: [phone]

19-Sep-83 10:38:34-EDT,3877;000000000001
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 19 Sep 83 10:38:26 EDT
Date: Mon 19 Sep 83 10:38:12-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: [[e-mail]: KRFC #2 and #3]
To: Info-Kermit@CUCS20

KRFC #2 ("Point of Procedure") seems perfectly reasonable, so let's call
them KRFC's and let's send them to Info-Kermit@COLUMBIA-20.  KRFC #3
(mainframe format for binary files) deserves, and probably will provoke,
more comment.
                ---------------

Date: 16 Sep 1983  18:52 MDT (Fri)
From: [e-mail]
To:   [e-mail]
Subject: KRFC #2 and #3

KRFC #2

Proposed Kermit RFCs should be submitted to INFO-KERMIT-REQUEST at
COLUMBIA-20 for number assignment and redistribution - no other
editing, except to kill extraneous lines from the header, such as
"Received:" will be done.

To avoid *any* possible confusion with Arpanet RFCs, the short name
should be KRFC, with apologies to any radio or TV station with those
call letters.
--------------------

KRFC #3

STANDARD FILE TYPES

Background

In very recent memory, when the public domain files related to CP/M
were stored on MIT-MC, an arbitrary scheme had been developed for a
program to easily distinguish binary files from ASCII text files, as
there is no bit in the FCB to designate file types.

(Note that we are considering WordStar-generated, LU, and SQ files, as
binary files, as well as .COM, .CMD (for you CP/M-86 types), and .REL
files, and miscellaneous others - any that contain bytes with the 8th
(parity) bit set).

On PDP-10s, with 36-bit words, we decided to store binary files in the
following format: a header word, containing "DSK8" in SIXBIT, followed
by the file contents, stored as four 8-bit bytes, left-justified in
each 36-bit word.  The remaining four bits were ignored, and usually
set to zero by the uploading program.  Each 128-byte record was stored
as-is, without any trailing padding, except for padding out the last
36-bit word with ^Cs.

ASCII files were stored as normal ASCII files, except the last record,
containing one or more ^Zs (the CP/M EOF) was stored without the ^Z(s)
and beyond.  The normal convention of padding out with one or more ^Cs
to fill a 36-bit word was used.  Any trailing ^Cs were not used to set
the file size in 7-bit bytes in the FCB.  Downloading programs
automatically pad the last 128-byte record with ^Zs as needed.

The Proposal

To adopt the "ITS Binary" format for storing micro binary files on
mainframes, and to observe the end-of-file conventions for ASCII text
files.

Advantages

Downloading programs to not need to depend on any FCB information,
which may be possibly ambiguous, to determine the file type.  If a
"DSK8" in SIXBIT, or its equivalent transformation of four bytes in
32-bit words is detected, the file is, by definition, a binary file.

There is a very large collection of CP/M public domain files,
including those files formerly kept on MIT-MC, all of the SIG/M
volumes, currently up to Volume 85, and all of the CPMUG volumes,
except those duplicates of SIG/M volumes, up to Volume 90, now stored
on the SIMTEL20.  All of the SIG/M and CPMUG volumes were uploaded
into ITS Binary format files, and all of the binary files in the MC
collection are in ITS Binary format.

The TOPS-20 MODEM and CRC programs automatically recognize and
distinguish between ITS Binary and regular ASCII text files.  CRC
computes the same CRC value that the CP/M CRCK program derives from
the same files.  Binary files uploaded by either KERMIT or MODEM can
be downloaded by either.

Lastly, CP/M (micro) binary files stored as binary files reduces
mainframe storage costs; binary files transmitted, where possible, in
binary mode, save transmission costs, etc.
-------
19-Sep-83 11:40:43-EDT,5655;000000000001
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 19 Sep 83 11:40:19 EDT
Date: Mon 19 Sep 83 11:39:49-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: KRFC #3
To: Info-Kermit@CUCS20
cc: cc.fdc@CUCS20
In-Reply-To: Message from "[e-mail]" of Fri 16 Sep 83 20:54:33-EDT

A few comments about mainframe storage of uploaded binary files:

KERMIT-10 and KERMIT-20 already have the capability to store uploaded files
in either 8-bit (binary) or 7-bit (ASCII) mode.  But someone has to tell KERMIT
which format to use.  Using ITS binary would certainly simplify the job, since
KERMIT could automatically select the right size by inspecting the first 4
characters of an incoming file.  However, someone has to tell the sender to
prepend that special first word.  How is that done?  Is it done automatically
by the program based on the file type (.COM, .CMD, etc)?  That could be
subject to error, as in the case where I send my LOGIN.CMD (an ASCII text file)
from the DEC-20 to the micro and then send it back to the mainframe.  Also,
what if an ASCII text file on the micro happens to start with the ASCII
characters "DSK8"?

This is not to say it's a bad idea.  Compatibility and standardization are
worth a price, especially when the price is not much greater than what we're
paying now, which is that KERMIT on the DEC-10/20 stores all the files in an
incoming batch with the same bytesize, 7-bit by default, or 8-bit if the SET
FILE-BYTESIZE 8 command has been issued.  The proposed method would allow
binary and text files to be mixed in a batch during uploading.

For those outside the PDP-10 world who may be puzzled by this, the problem
occurs only because PDP-10s (DEC-10's running TOPS-10, ITS, WAITS, or TENEX;
DEC-20s running TOPS-20) do not store text in 8-bit bytes, as the micros do,
and as most other mainframes do.  For instance, UNIX systems on VAXes or
PDP-11s store both text and binary files in 8-bit bytes.  I assume that the
proposed standard would only affect PDP-10s and other systems that would store
characters in 7-bit bytes (thus losing the 8th bit) unless explicitly directed
otherwise; systems like IBM VM/CMS, UNIX, VAX/VMS, etc, would not have to
bother with ITS binary format.  Right?

As to ASCII files, why bother padding out the last "word" with ^C's (is that an
ITS convention?)?  I think the primary goal of ASCII file transfer should be to
end up with a useful file on the receiving end, and most PDP-10 users are not
accustomed to finding several ^C's at the end of a text file.  Especially since
one is just as likely to be sending PDP-10 text files (which don't have ^C's at
the end) to the micro as CP/M text files to the PDP-10.

As to binary files, I see two possible problems with the proposal.  First,
since the FCB contains no information about whether the file is binary or
ASCII, the micro side of the file transfer protocol must make that
determination, either by asking the user, or by observing certain filetype
conventions; either method is prone to error, and these will tend to affect the
less sophisticated user.  Second, although SIG/M and CPMUG volumes are stored
in the proposed format, there may be other sites that have similar databases
stored in other formats; would they have any objection to the proposed change?

How about this as a counter-proposal: Let the micro send the characters DSK8 as
the first four characters of any binary file, as originally proposed, but the
host will not store those characters in the file.  Instead, the DEC-10 or
DEC-20 will simply store the actual contents of the file in 8-bit bytes, rather
than 7-bit bytes (as it would normally have done).  When sending files back to
the micro, the DEC-10 or -20 is capable of picking up the bytesize from the
file's directory entry and sending it appropriately; storing the characters
"DSK8" in the mainframe copy of the file is unnecessary.  Hosts other than
PDP-10s, which store characters in 8-bit bytes anyway, upon seeing "DSK8" as
the first 4 characters of an incoming file, can take appropriate action, which
will most likely be to simply discard those 4 characters.  To deal with PDP-10
resident files that DO have "DSK8" in the file, however, KERMIT could have an
option added to ignore (i.e. not send) those characters.  Thus, KERMIT could
work on both kinds of systems.  This flexibility becomes valuable when you
consider that CP/M is not the only system that is going to be uploading binary
files to the PDP-10 -- there's UNIX, MS/PC DOS, CP/M-86, VMS, VM/CMS, etc etc.

Would this cause a problem with MODEM or CRCK, etc?  I suspect not, since they
would ignore the DSK8 characters (i.e. not send them, or not include them in
the CRC) if they were there, and should know how to open the file with the
correct bytesize anyway.

Finally, I think most of the ideas of the MODEM world spring from an
environment where the microcomputer user views the mainframe as an archiving
device, and is primarily concerned with files that originate on the micro.
There is also another world, in which mainframe users view the micro as an
archiving device (providing removable media) for mainframe-created files.  In
that world, a whole new set of questions is raised.  How do you store 36-bit
DEC-10 or -20 .EXE or .REL files on the micro?  How do you deal with a
mainframe file that happens to contain ^Z's in its last "block"?  An earlier
message to the KERMIT list discussed some of these questions.  And every answer
only opens the door to some deeper question...

- Frank
-------
19-Sep-83 11:54:07-EDT,2737;000000000001
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 19 Sep 83 11:53:57 EDT
Date: 17 Sep 1983 1229-PDT
Subject: Re: Kermit "RFC No. 1"
From: Billy <BRACKENRIDGE@USC-ISIB>
ReSent-date: Mon 19 Sep 83 11:49:58-EDT
ReSent-from: Frank da Cruz <cc.fdc@CUCS20>
ReSent-to: Info-Kermit@CUCS20

I like the idea of RFCs for Kermit. I think the idea of aborting a connection
would be particularly useful. Feel free to edit or distribute this as you wish.

I have several things on my wish list:

It would be nice if Tops-20 Kermit had an automatic mode where things like
Receive packet length and pause times could be set dynamically based on
baud rate and load average or perhaps scheduler options.

We had some problems with accountants sending large spread sheet files to
Tops-20 durring peak load hours breaking the front end. Readjusting receive
packet length to a level acceptable to the front end allowed us to run even
at 9600 baud durring periods of high load averages. As these people were not
programmer types the solution to the problem was apparently not obvious,
an automatic Tops-20 Kermit would have saved much running around by the
systems staff to find someone who knew anything about Kermit and could teach
the accountants the correct Kermit command to fix the problem.

I would like to see Kermit-86 re-organised on a more modular basis. I
would be more encouraged to add new features if I didn't have to deal with
a monolithic 186K byte file. I would like to see Kermit-86 divided up
into seperate files and defined interfaces for File I/O, Terminal Emulation,
Command Interpreter, Screen display management, and Kermit protocol modules.

This way we could support a large number of variations for different machines
and different styles of user interaction while maintaining commonality
of the core routines.

Particularly I might want to use a propriatary terminal emulator, or Columbia
may choose to distribute several public domain terminal emulators as they
are donated.

At ISI we have ordered a few mice for experimental purposes. I might want to
replace the Tops-20 style command interpreter with a mouse menu style
interpreter. Someone else might want a Unix style command interface, but
still run under MS DOS.

Similarly screen management and File I/O as seperate modules would allow
the same Kermit to be used under several operating systems, and on multiple
machines with varying display technologies.

Of course this is something that must be done at a central site. The module
interfaces should be defined and published. While I suggested this for
the 8086 Kermit it is also applicable to the C Kermits and Z80 Kermits.
-------
19-Sep-83 12:08:03-EDT,1421;000000000001
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 19 Sep 83 12:07:19 EDT
Date: Mon 19 Sep 83 11:57:01-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: Kermit "RFC No. 1"
To: Info-Kermit@CUCS20
In-Reply-To: Message from "Billy <BRACKENRIDGE@USC-ISIB>" of Sat 17 Sep 83 15:30:22-EDT

About Billy's wish list:

TOPS-20 Kermit does automatically adjust the timeout interval based on load
average.  Adjusting the packet length is another possibility.  However, due to
a shortcoming in TOPS-20, it is not feasible to adjust ANYTHING based on
terminal baud rate.  The reason is that for remote lines, TOPS-20 does not know
what the actual baud rate it.  Yes, you can ask the monitor, and yes, it will
return a reasonable number, but that is the "nominal" baud rate for that line,
not the actual speed, i.e. it is the speed to which the line is reset after it
is hung up.  It does not store the actual speed anywhere, except in a
write-only (yes, write-only) register in the DH-11 multiplexer on the DEC-20's
PDP-11/40 front end.

About organization 8080, 8086, and UNIX Kermits along a more modular basis -- I
couldn't agree more, and I hope we'll be able to do it.  If we had known that
KERMIT was going to grow to the proportions it has, I'm sure we would have paid
a little more attention to these issues when writing the programs originally.

- Frank
-------
19-Sep-83 15:26:36-EDT,1199;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 19 Sep 83 15:26:24 EDT
Date: Mon 19 Sep 83 15:02:03-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New TTLINK for DEC-20
To: Info-Kermit@CUCS20

TTLINK, which DEC-20 KERMIT runs in a lower fork to accomplish outgoing
terminal connections, was not able to run under TOPS-20 batch because the
program wanted to enable ^C capability, and batch won't allow that.  The STIW
JSYS (which must be used to let the characters ^C, ^T, and ^O pass through to
the remote host) requires ^C capability, even if you're not using it to
manipulate ^C itself.  The only solution is to skip the STIW if ^C capability
hasn't been successfully enabled, which means that you can't send ^O or ^T to
the host, and that ^C (typed twice) will terminate the program (continuably).
If you run TTLINK under these conditions, an appropriate warning message will
be typed, but you can continue to run the program with the limitations just
described.

This is edit 15 to TTLINK.  The source and binary can be found at COLUMBIA-20
as KER:TTLINK.*, retrievable via anonymous FTP.  Report any problems to me.

- Frank
-------
19-Sep-83 18:54:18-EDT,1204;000000000001
Return-Path: <@CUCS20:OC.SITGO@CU20B>
Received: from CUCS20 by CU20B with DECnet; 19 Sep 83 18:54:08 EDT
Received: from CU20B by CUCS20 with DECnet; 19 Sep 83 18:38:02 EDT
Date: Mon 19 Sep 83 18:37:32-EDT
From: "Nick Bush" <OC.SITGO@CU20B>
Subject: Re: Kermit "RFC No. 1"
To: cc.fdc@CUCS20
cc: Info-Kermit@CUCS20
In-Reply-To: Message from "Frank da Cruz <cc.fdc@CUCS20>" of Thu 15 Sep 83 13:04:07-EDT

The items in KRFC #1 all seem reasonable.  In fact, they provide some
functionality which we have alread seen a need for when doing version 1
of Kermit-10.

I have one suggestion about the "I" packet.  Rather than using the same
contents as an "S" packet, this would be a chance to redesign the parameter
exchange to get around a few of the problems there have been with the "S"
method of passing parameters.  For example, the "I" packet could include
a bit map of the features that the Kermit supports (which generic commands,
etc.), allowing the other Kermit to determine what it can and cannot do.
This would not affect existing Kermits at all, but would allow a method
of adding features which might otherwise be incompatible with previous
versions of the protocol.
-------
20-Sep-83 11:54:34-EDT,4385;000000000001
Return-Path: <@CUCS20:SY.FDC@CU20B>
Received: from CUCS20 by CU20B with DECnet; 20 Sep 83 11:54:22 EDT
Received: from CU20B by CUCS20 with DECnet; 20 Sep 83 11:53:53 EDT
Date: Tue 20 Sep 83 11:53:11-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit RFC #4
To: Info-Kermit@CUCS20

Kermit RFC #4, regarding calculation of the CRC, from Nick Bush at Stevens
Institute of Technology in Hoboken, New Jersey.  Nick and the people at
Stevens are putting CRC support into several versions of KERMIT (including
VAX/VMS, TOPS-10, PDP-11, CP/M) and will do it as proposed unless serious
objections surface.  In particular, note that the method differs from that
used by MODEM7.  Is there any any reason why KERMIT should produce the same
CRC as MODEM7?  - Frank
                ---------------

Date: Tue 20 Sep 83 11:36:19-EDT
From: "Nick Bush" <OC.SITGO@CU20B>
Subject: Kermit protocol version 3 - CRC usage
To: SY.FDC@CU20B

Proposal for the implementation of the three character CRC specified
in the Kermit protocol version 3.

The version 3 protocol manual defines the existance of a 3 character CRC
option for the "check" field of a message.  It specifies that the
generating polynomial is to be the CRC-CCITT polynomial, but does
not specify the exact method of calculating the CRC.  While the
general method of calculating a CRC based on the CRC-CCITT is well
specified elsewhere, there are a few options in the method of calculation
which need to be specified to ensure that all implementations produce
the same CRC value.  The following defines those options suggested for
use in the Kermit protocol:

1. Treat the checked portion of the message (i.e., the portion between
   the <mark> and the block check, exclusive of the two) as a string
   of bits with the low order bit of the first character first and the
   high order bit of the last character last.

2. Divide the message bit string by the value representing the CRC-CCITT
   polynomial (X**16+X**12+X**5+1).  This is actually done a byte
   at a time by a very straight forward algorithm.

3. The remainder is the block check value that is split up into the 3 pieces
   for packing into the 3 character field.

There are three things to note about this that affect the implementation of
the algorithm for calculating the CRC:

1. The initial value for the CRC is taken as 0.  Some protocols, notably SDLC
   use all ones as the initial value.  This is just an arbitrary choice,
   but is compatible with a number of protocols.

2. The bit string is treated as it will appear on the transmission line (at
   least most async transmissions).  That is, the low order bit of each byte
   is first, with the high order bit of a byte immediately preceding the
   low order bit of the next byte.  This method is typical of that used
   by most protocols, and is the method that is usually implemented in
   hardware.  For example, the VAX has a CRC instruction that treats the
   string in this way.  Any line interface I have seen that allows for
   CRC generation for transmitted characters does so by working on the
   serial stream of bits, which are normally transmitted as low order of
   each byte first.  Note that this is the opposite of how MODEM calculates
   the CRC that it uses.  It treats the string as a stream of bits with
   the high order bit of the first byte coming first and the low order
   bit of the last byte coming last (meaning that the low order bit of
   a byte immediately precedes the high order bit of the next byte).
   I suggest defining the Kermit protocol so that implementations can
   make use of hardware CRC generators that (like the CRC instruction
   on the VAX) use the low-order bit first convention.

3. The remainder of the division is used as the CRC as is.  Some protocols,
   like SDLC, complement it first.  There seems to be no reason not to
   use the remainder as is, without complementing it.

It should be specified that the Send-Init packet and the Ack to the
Send-Init must always be sent using the single character checksum,
since the other Kermit does not know what to expect.  This should probably
be spec'ed this way even if both Kermit's allow a SET of the block check type.
The protocol manual currently seems to imply this, but does not specifically
state it.

-------
-------
20-Sep-83 16:28:22-EDT,685;000000000000
Return-Path: <@CUCS20:knutson@utexas-11>
Received: from CUCS20 by CU20B with DECnet; 20 Sep 83 16:28:14 EDT
Received: from UTEXAS-11.ARPA by COLUMBIA-20.ARPA with TCP; Tue 20 Sep 83 16:27:56-EDT
Date: Tue, 20 Sep 83 15:25:03 CDT
From: Jim Knutson <knutson@utexas-11>
Subject: DEC-20 Kermit chksum processing
Posted-Date: Tue, 20 Sep 83 15:25:03 CDT
Message-Id: <[e-mail]>
Received: by UTEXAS-11.ARPA (3.326/3.7)
    id AA12153; 20 Sep 83 15:27:01 CDT (Tue)
To: info-kermit@columbia-20

Our version of DEC-20 kermit (version 3(40)) does not
send a NAK upon receipt of a packet with a bad checksum.
Is this the latest version or has this been fixed?
20-Sep-83 19:57:33-EDT,1105;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 20 Sep 83 19:57:30 EDT
Date: Tue 20 Sep 83 19:57:09-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: DEC-20 Kermit chksum processing
To: [e-mail], info-kermit@CUCS20
In-Reply-To: Message from "Jim Knutson <knutson@utexas-11>" of Tue 20 Sep 83 16:28:11-EDT

3(40) is a relatively old version of Kermit-20.  A while back, I too discovered
that it did not NAK a bad packet, but rather, just waited for the other side to
time out and send it again.  This can slow things down a lot if the line is
noisy.  That particular omission has been corrected, and some other minor bugs
fixed in recent days.  The version of KERMIT-20 available online at COLUMBIA-20
(as KER:20KERMIT.*) does not yet contain these fixes, but it is considerably
ahead of 3(40) -- it's 3A(62), which has a lot of new debugging features, etc.
A new version that NAKs bad packets immediately and also includes the features
mentioned in "KRFC #1" plus some new server functions will be announced
shortly.  - Frank
-------
21-Sep-83 21:29:01-EDT,2586;000000000001
Return-Path: <@CUCS20:OC.WBC3@CU20B>
Received: from CUCS20 by CU20B with DECnet; 21 Sep 83 21:28:56 EDT
Received: from CU20B by CUCS20 with DECnet; 21 Sep 83 21:30:52 EDT
Date: Wed 21 Sep 83 21:28:26-EDT
From: Bill Catchings <OC.WBC3@CU20B>
Subject: Re: KRFC #3
To: cc.fdc@CUCS20, Info-Kermit@CUCS20
cc: cc.fdc@CUCS20
In-Reply-To: Message from "Frank da Cruz <cc.fdc@CUCS20>" of Mon 19 Sep 83 11:40:44-EDT

As far as I can see there are two problems being addressed here.  Correct
me if I am wrong.  The first is the ability to use "ITS binary" files
that are usable by MODEM, etc.  This is only really of value on the system
or systems that presently use that format (I assume only some Tops-10 sites.)
If this is important enough, I guess that ability could be built in.

The second question is the general one of how to destinquish between "binary"
(8-bit) files and ASCII (7-bit) files on the DEC-20 or DEC-10.  The method
presently used on the -20 for downloading (as explained by Frank da Cruz)
takes care of things quite well.  The problem is that uploading requires some
sort of manual intervention.  On the -20 the solution is straight-forward,
but possibly expensive of computer resourses in the worst case.  In most cases
however, it should be fine.  I shied away from doing this in the past, but
maybe I was wrong.  The thing to do is that unless the user specifies other-
wise (forcing either a 7-bit or 8-bit file) Kermit-20 should assume that
the file is 7-bit and proceed.  If at any time (which is what could be costly)
during the transfer a byte with the 8th bit on is detected the file is remapped
in and changed to 8-bit.  The transfer then continues in 8-bit.  The flaw of
course is that a 100 page file might have just the last byte in 8-bit.  The
previous hundred pages must now be gone through and changed to 8-bit.  In
general, this will not happen, I would think that in almost all cases the
8th bit should be turned on before the first page is even mapped out.

There is one other case that is also possible that must be watched for.  This
does not change what was said before, but just makes the check for "8-bitness"
a little bit tougher.  You must treat an 8th bit in line numbers different.
If this is the bit found, the file stays in 7-bit mode.  This already works
fine, so if some CP/M file just happened to have only those bits on, it should
not cause a problem.

I don't know how this would work under Tops-10, but a similar scheme should
be possible.  What do you think?

                        -Bill Catchings

-------
22-Sep-83 20:22:03-EDT,1874;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 22 Sep 83 20:21:59 EDT
Date: Thu 22 Sep 83 20:23:58-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New UNIX Kermit
To: Info-Kermit@CUCS20

Bob Cattani of the Columbia CS Department has merged the various changes,
suggestions, and bug fixes to Unix Kermit into a single source program, and has
tested it thoroughly under 4.1bsd (talking to itself and to TOPS-20).  It is
now available to the ARPAnet community for testing via anonymous FTP of the
files KER:CKERMIT.* from host COLUMBIA-20.  CKERMIT.C is the source program,
with conditionals added for various non-Berkeley Unix variants; CKERMIT.CHANGES
lists all the changes from the present KERMIT.C (I'm not sure if it lists the
infamous wildcard send bug, in which all but the first file came out null, but
that's fixed too), and CKERMIT.MAN is the Unix man page.  Thanks to W Underwood
at Ford Aerospace for the man page and the non-Berkeley support, to Jim Guyton
at Rand for some bug fixes and suggestions, and to others on this list who
reported problems in the past.

This new release does not incorporate any major new functionality, like server
operation, CRC's, etc.  All that will come later, once we get reports back from
some other sites that tell us that we have a solid base to work from.  Users of
UNIX Kermit are urged to try out the new versions and report any problems or
suggestions (or indeed, any success) to us.

Here's a very quick summary of the changes:

 Ifdef'ed to work on v6/PWB, v7, and Onyx System III, as well as 4.1bsd.
. Major efficiency improvements.
. 2-character user-settable escape sequence for terminal connection.
. Filename case conversion and deletion of Unix pathname.
. Debugging capability enhanced.
. Many cosmetic changes to the code.

- Frank
-------
26-Sep-83 16:04:30-EDT,3607;000000000001
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 26 Sep 83 16:04:14 EDT
Received: from SIMTEL20.ARPA by COLUMBIA-20.ARPA with TCP; Mon 26 Sep 83 15:25:57-EDT
Date: 26 Sep 1983  13:24 MDT (Mon)
From: [e-mail]
To:   Frank da Cruz <[e-mail]>
Cc:   [e-mail]
Subject: KRFC #3

Frank,

I *think* you *may* have missed some critical points:

1.  Yes, it is true, I do consider the mainframes as store-and-forward
devices, rather than the other way around, but see below.  And, to
smooth the mainframe end out, w.r.t. non-ASCII files, my proposal was
designed to provide an unambiguous, machine-independent means to
determine if the stored file is non-ASCII.  Of course, it is up to the
user to declare to the storage process that the file is non-ASCII.

The reason for this came up when we were FTPing ITS Binary files from
MC, and the files were stored "incorrectly" - i.e., the FCB was a
misleading (36), instead of (8) or (7), and MODEM attempted to then
download the file as its default - an ASCII file.  What does KERMIT do
in this case?

2.  The "DSK8" in SIXBIT must be an unfamiliar term.  The entire first
36-bit PDP-10 WORD is occupied by the characters DSK8, six bits per
character.  That is why I referred to its transformation in an
8-bit/32-bit machine, which will NOT end up being "DSK8".  This "word"
is only seen by the program on the mainframe and, and is NEVER
transferred - only used to determine that, if it is there, the file
MUST be in "ITS Binary" format.

3.  The reason for bothering with ITS Binary format at all, is not
"just" for the PDP-10 world; it is for those others who need to
communicate with the PDP-10 world.  For example, when such a file is
FTP'd to a UNIX site from here, people have devised procedures to
pre-strip that "DSK8" - now transformed to four 8-bit bytes, and then
download.  Wouldn't it be nice if the downloading program took care of
that automatically?  How are file types determined on Unix machines?
Are *all* files assumed to be binary or ASCII?  Must the download user
explicitly declare the assumed transfer mode?  For each file?  If so,
then THAT is even more prone to error than depending upon just the
uploader to to get it right!

4.  The ^C padding is done by the system - not the user program - and
that is an ITS convention that I'm not sure migrated to TOPS-20.

Funny you should ask about storing PDP-10 .EXE or .REL files, and
using the micro as the store-and-forward device.  After we brought up
this machine earlier this year, there was a considerable and
unexpected delay in getting connected to the net.  Gail Zacharias
(GZ@MC) devised a pair of programs for me, named BYTIFY and UNBYTIFY,
that respectively convert *any* PDP-10 file to ITS Binary Format, and
back.  I used these programs to get many files off the net and into my
DEC, including two full sets of the MM system while we were waiting!
I will put the sources of those files along with the others of
interest already in [SIMTEL20]MICRO:<MC.TOPS-20>, such as MODEM, CRC,
TYPESQ, USQ, and UNARI.  MODEM is in MACRO, all the others are in
MIDAS.  (At one point, there was also going to be an LU20 to handle
.LBR files - in ITS Binary, of course...)

BOTTOM LINE: I would be content if KERMIT20 would automatically
recognize ITS Binary format, and begin the file transfer with the
SECOND PDP-10 word on download.  It would be even nicer for the other
KERMITs to do something similarly appropriate for their machines.

--Frank
26-Sep-83 16:07:30-EDT,3383;000000000001
Return-Path: <@CUCS20:SY.FDC@CU20B>
Received: from CUCS20 by CU20B with DECnet; 26 Sep 83 16:06:50 EDT
Received: from CU20B by CUCS20 with DECnet; 26 Sep 83 16:07:29 EDT
Date: Mon 26 Sep 83 16:01:08-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Unix Kermit for Amdahl UTS
To: Info-Kermit@CUCS20

Did anyone try out the new Unix Kermit yet?  We tried it out at Columbia on our
IBM 4341 mainframe running Amdahl UTS (= Unix) and found a few changes were
necessary.  Will any of the changes described below adversely effect other
Unixes?  I'd welcome any Unix site trying this version and reporting success
or failure with it.  It's available on COLUMBIA-20 as KER:UKERMIT.C (same as
CKERMIT.C except with fixes for UTS added), via anonymous FTP.  - Frank
                ---------------

Received: from CUVMA by CU20B with HASP; 26 Sep 83 15:22:25 EDT
From: Alan Crosswell <alan at CUUTSA>
Date: 26 Sep 1983 15:21:55-EDT
Sender: UNIXA at CUVMB
To: sy.fdc@cu20b
Subject: Kermit UTS changes
Cc: sy.daphne@cu20b

Frank,
  Following is the differences file for UTS.  In a following letter will be
the source.

I've made the following changes:
        1) Removed IBM_UTS system type.
        2) Added NO_NLWAKEUP #define along the lines of the other UNIX
           tailoring #defines.
        3) Changed a char to an int to make (t = getc(ttyfd)) return -1
           on EOF instead of 255 (-1 trunc'd to 8 bits).
        4) Added an fflush call in printmsg to make messages come out when
           they are printed.
        5) Added a read() in rpack() to eat the eol character,  if this isn't
           done,  the eol character is the next character read by the shell
           when kermit ends.  This has no effect for other Unix kermits since
           they use \n for the eol character and simply see an extra newline
           as if the user typed a cr.  However,  UTS kermit sees a \r which
           it doesn't understand as newline because the tty was in raw mode
           when the character came in.
points 3-5 should work equally well on other systems,  so I didn't bracket
them within a #if.



32d31
< #define IBM_UTS     0       /* Amdahl UTS on IBM systems */
34a34
> /* For Amdahl UTS,  need to set NO_FIONREAD,  NO_TANDEM,  and NO_NLWAKEUP */
37,38c37,39
< #define NO_FIONREAD 0       /* No ioctl(FIONREAD,...) for flushinput() */
< #define NO_TANDEM   0       /* No TANDEM line discipline (xon/xoff) */
---
> #define NO_FIONREAD 1       /* No ioctl(FIONREAD,...) for flushinput() */
> #define NO_TANDEM   1       /* No TANDEM line discipline (xon/xoff) */
> #define NO_NLWAKEUP 1             /* Read does not wake up on NL -- need CR (U
TS) */
68a70,72
> #if UNIX&NO_NLWAKEUP
> #define MYEOL     '\r'    /* End-Of-Line character I need is <cr> */
> #else
69a74
> #endif /* UNIX&NO_NLWAKEUP */
901c906
<     char chksum, t, type;               /* Checksum, current char, pkt type */
---
>     char chksum, t, type, temp;         /* Checksum, current char, pkt type */
947a953
>       read(ttyfd,&temp,1);            /* get EOL character and toss it */
988c994
<     char t,                             /* Char read from file */
---
>     int  t,                             /* Char read from file */
1187a1194
>       fflush(stdout);                 /* make it print now */
-------
26-Sep-83 18:11:00-EDT,5517;000000000001
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 26 Sep 83 18:10:48 EDT
Date: Mon 26 Sep 83 18:12:09-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: KRFC #3
To: Info-Kermit@CUCS20
In-Reply-To: Message from "[e-mail]" of Mon 26 Sep 83 13:24:00-EDT

About ITS binary format -- I think we understand each other OK.  Since Kermit
doesn't want to make any assumptions about whether the mainframe disk is an
archive for the micro or vice versa, I think we can cover all the bases if we
allow -- as you suggest -- handling of ITS binary files by Kermit-20 (and I
guess Kermit-10 also), but we don't require it.  I'd suggest a parameter in
Kermit-10/20 that enables/disables the feature, which can be selected on a
site-wide basis (say, as an assembly parameter), and then overriden on an
individual basis (with a SET command).  How does this sound:

 If ITS-binary-format handling is disabled, then behave as before, i.e. don't
  pay any special attention to the contents of the file.

 If enabled, then:

  - For outgoing files, if the first word is SIXBIT/DSK8/, don't transmit the
    first word.

  - For incoming files, if the first 4 characters are DSK8, then store the file
    in 8-bit mode, even if the prevailing mode is 7-bit (would any system ever
    actually send a binary file this way?)

Recall that if Kermit-10/20 knows that the incoming file is 8-bit-binary (that
is, if you have said "SET FILE-BYTESIZE 8") then the file will be stored that
way, i.e. four 8-bit bytes left justified in each 36-bit PDP-10 word.  If you
didn't say "SET FILE-BYTESIZE 8", then the incoming file will be assumed to be
text (or PDP-10 binary, which is treated the same way, see below) and the 8th
bit will be lost from each byte, and the remaining 7-bit bytes will be stored
left justified, 5 to a word.

Not to beat a dead horse, but since all files - text and binary - are stored in
a uniform way on a CP/M (or MS DOS, or ...) disk, but are stored differently on
the PDP-10's disk, then if you want to send a file FROM a micro TO a DEC-20,
you must tell one side or the other whether the file is binary or text.  If you
tell the micro, then it can send out DSK8 as the first 4 characters of the
file; if you tell the DEC-20, then it knows to store the file in 8-bit mode.
Since the file will be stored in 8-bit mode in either case, there is no point
storing the DSK8 header word with the file -- the DEC-20 will know to read
8-bit bytes rather than 7-bit bytes when sending the file out.  On the other
hand, if there happens to be an ITS binary format file sitting around for some
reason, then KERMIT will not bother to transmit the first word.

Actually, the story may be somewhat different with respect to TOPS-10 (anybody
want to address the question?  For instance, can Kermit-10 rely on the bytesize
the same way Kermit-20 can?).

So much for binary files.  I trust we all agree that TEXT files should be
stored in whatever form is useful on the target system, in particular that
microcomputer text files are stored in 7-bit format on the DEC-20, so that
TYPE, PRINT, EDIT and similar commands work on them normally.  On the DEC-20,
no padding is necessary at the end; a byte count is kept in the FDB that tells
exactly how long the file is.

For symmetry, let me explain how KERMIT-10 and -20 deal with their own 36-bit-
byte binary files.  This is done using the same algorithm that the PDP-10 uses
to write "ANSI ASCII" format tapes: the 36-bit words are sent as five 7-bit
bytes, with the parity set to 0 on the first 4 bytes of each word, and the
parity of the 5th byte set to the value of bit 35 of the word.  Thus, DEC-20
users can "send *.*" to a micro, and then get all the files back again without
ever bothering about whether a particular DEC-20 file is binary or text.  This
is admittedly a hack, but it does the job (and it's hard to imagine how to do
it better).  The upshot is that KERMIT-20 treats a file as 7-bit (with special
handling for "bit 35") unless its bytesize is 8.  And when the bytesize IS 8
(which is never used on DEC-20s except for foreign binary files), the file is
read and sent correctly.

About FTP -- I never used it between a DEC-20 and UNIX, but between two
DEC-20s, FTP preserves the bytesize.  That means that when I send a file out
from the DEC-20, it tells the receiver in some way that the file is text
(bytesize 7), "foreign binary" (bytesize 8), or "image" or "page" (bytesize 36,
a special mode only for TENEX and TOPS-20).  A receiving UNIX (or any other)
FTP should be able to use this information to store the file correctly, without
having to rely on the "DSK8" header.  For Unix, it doesn't matter anyway, since
it stores every incoming byte on the disk as an 8-bit byte -- all files are
streams of 8-bit bytes to Unix; thus sending "DSK8" invokes no function on the
Unix side other than discarding the "DSK8" (or am I missing something?).

Anyway... (sorry to drone on at such length):

BOTTOM LINE: I agree that KERMIT-20 should have the ability to recognize ITS
binary format, and begin the file transfer with the second PDP-10 word on
download, and whatever can be done along similar lines for KERMIT-10 should
also be done.  However, I don't think KERMIT-20 (or -10) should ever actually
have to CREATE ITS format binary files, since the same information is recorded
in the file bytesize.  Agreed?

- Frank
-------
27-Sep-83 10:41:09-EDT,745;000000000000
Return-Path: <@CUCS20:knutson@utexas-11>
Received: from CUCS20 by CU20B with DECnet; 27 Sep 83 10:41:01 EDT
Received: from UTEXAS-11.ARPA by COLUMBIA-20.ARPA with TCP; Tue 27 Sep 83 10:41:43-EDT
Date: Tue, 27 Sep 83 09:35:43 CDT
From: Jim Knutson <knutson@utexas-11>
Subject: Naming conventions in the <KERMIT> area
Posted-Date: Tue, 27 Sep 83 09:35:43 CDT
Message-Id: <[e-mail]>
Received: by UTEXAS-11.ARPA (3.326/3.7)
    id AA00544; 27 Sep 83 09:40:17 CDT (Tue)
To: info-kermit@columbia-20

Would it be possible to include the version number of the program in
the filename?  It is hard to know which version (.MAC, .NEW, .TST) is
the latest version when FTPing files from the <KERMIT> area on
Columbia.
27-Sep-83 14:22:57-EDT,1430;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 27 Sep 83 14:22:47 EDT
Date: Tue 27 Sep 83 14:22:38-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: Naming conventions in the <KERMIT> area
To: [e-mail], info-kermit@CUCS20
In-Reply-To: Message from "Jim Knutson <knutson@utexas-11>" of Tue 27 Sep 83 10:41:59-EDT

Things could be better with regard to naming conventions.  The present scheme
(what there is of it) is to group files pertaining to the same machine or
operating system together by prefix (files are arranged alphabetically within
a directory on a DEC-20), with names being no longer than 9.3 to avoid
confounding any VMS system, and unique within 6.3 to avoid conflicts on TOPS-10
systems.  As to the .NEW, .TST, NEWFOO.BAR, ... business, you're right -- there
should be some more standard way of having new or test versions of programs
coexist with older ones.  The best way around all the problems would be to
organize the KERMIT distribution area into subdirectories, which I will do once
I have determined that all common file access methods will not be tripped up
by this.  Presently, KERMIT itself does ok; NFT/FAL (the DECnet file transfer
system) fails; I haven't yet tested FTP to see how it might be affected.
The old vs new problem would be alleviated somewhat if FTP directory listings
included the date, but...  - Frank
-------
27-Sep-83 21:43:59-EDT,905;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 27 Sep 83 21:43:57 EDT
Received: from HI-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Tue 27 Sep 83 21:44:54-EDT
Date:  27 September 1983 20:40 est
From:  DBrown.TSDC at HI-MULTICS
Subject:  Naming conventions
To:  info-kermit at COLUMBIA-20

  For a good discussion on this whole basket of worms, get a copy of "A
View of Source Text for Diversely Configurable Systems", from the
Mathematics Facility, University of Waterloo, Waterloo, Ontario, Canada.
  This is a tech report by Tom Cargill (now of Bell Labs) on how to keep
things straight when you're trying to keep 5 versions of a portable
operating system (Thoth) and all its utilities on a rather small mini.
  It's one of those "its obvious, why didn't I think of it" papers that
crop up every so often...
 --dave (I thorta like Thoth) brown
28-Sep-83 17:35:30-EDT,8146;000000000001
Return-Path: <@CUCS20:GZ@MIT-OZ>
Received: from CUCS20 by CU20B with DECnet; 28 Sep 83 17:35:20 EDT
Received: from MIT-MC by COLUMBIA-20.ARPA with TCP; Wed 28 Sep 83 17:36:44-EDT
Date: Wed, 28 Sep 1983  04:30 EDT
Message-ID: <[MIT-OZ].GZ.28-Sep-83 04:30:13>
From: Gail Zacharias <GZ@MIT-OZ>
To:   [e-mail]
cc:   [e-mail]
Subject: [[e-mail]: KRFC #2 and #3]
In-reply-to: Msg of 28 Sep 1983  00:36-EDT from Gail Zacharias <GZ at MIT-MC>

I'm not on this list, but since I was one of the people involved in setting
up the "ITS binary file format" on ITS, and maintain a number of programs
which take advantage of it, Frank Wancho forwarded these messages to me.
I'm not familiar with Kermit, but I have some general comments and
clarifications to make.

    Date: 16 Sep 1983  18:52 MDT (Fri)
    From: [e-mail]
                        Each 128-byte record was stored
    as-is, without any trailing padding, except for padding out the last
    36-bit word with ^Cs.

This is not true for binary files.  There is no padding at end of file,
since each record takes exactly 32 complete words.

    ASCII files were stored as normal ASCII files, except the last record,
    containing one or more ^Zs (the CP/M EOF) was stored without the ^Z(s)
    and beyond.  The normal convention of padding out with one or more ^Cs
    to fill a 36-bit word was used.

The ^C's in ascii file are an artifact of the ITS file system.  They are
ITS's EOF markers, and all ITS programs know how to deal with them.
TOPS-20 has a different format for setting EOF (a byte count in the FDB)
which all TOPS-20 programs know how to use.  I suggest that the protocol
only state that for ascii files, the CPM eof mark be replaced by the
receiving operating system's standard EOF convention.

    Date: Mon 19 Sep 83 11:39:49-EDT
    From: Frank da Cruz <cc.fdc at COLUMBIA-20.ARPA>

    what if an ASCII text file on the micro happens to start with the ASCII
    characters "DSK8"?

The identifier word is DSK8 in sixbit, not ascii.  Interpreted as PDP-10
ascii, it is the five characters I N [ ^@ ^@, where ^@ means NULL, ascii
code 0.  Very few PDP-10 ascii files have nulls in them.  On an 8-bit
system (Unix, VMS, etc.) it is the four bytes 93H 3AH D8H 00H, two of which
have the high bit on.  Either way there is very little chance of an ascii
file starting this way.  There might be binary files which genuinely start
this way.  Which might be a good reason to decide to either put the prefix
on all stored binary files, or none of them.

                          The proposed method would allow
    binary and text files to be mixed in a batch during uploading.

I guess it depends on your point of view, but to be precise: the method
allows PDP-10's to automatically determine the format of a local disk file.
As such, it is helpful when downloading from a 10.  That's all.  All the
other stuff is just to allow files to be FTP'ed between systems and still
win - see below.  After all, the whole point of a standard is to allow for
easy communication between systems.  If everybody is only concerned about
their own machine, there is no need for a standard.

                                I assume that the
    proposed standard would only affect PDP-10s and other systems that
    would store characters in 7-bit bytes (thus losing the 8th bit) unless
    explicitly directed otherwise; systems like IBM VM/CMS, UNIX, VAX/VMS,
    etc, would not have to bother with ITS binary format.  Right?

No.  Since binary files FTP'ed from PDP-10's to IBM/UNIX/VMS sites would
start with those leading bytes (93H 3AH D8H 00H), it would be important for
everybody to understand them.  Especially since a major source of CP/M
software on the net will be SIMTEL20, a PDP-10.  In situations where a Unix
etc.  doesn't care whether the file is binary or not, all it need do is
strip those four bytes if it finds them.  In those cases where it might
like to know, it might use them to determine binariness, in place of
requiring the user to specify a -b switch, if it wishes.  But that's a
user-interface issue not really relevant here. All the proposal would
require is that the bytes be recognized and stripped before downloading
(unless the user specifies not to, presumably - again a separate user
interface issue).

    As to binary files, I see two possible problems with the proposal.  First,
    since the FCB contains no information about whether the file is binary or
    ASCII, the micro side of the file transfer protocol must make that
    determination, either by asking the user, or by observing certain filetype
    conventions; either method is prone to error, and these will tend to
    affect the less sophisticated user.

This is irrelevant.  I'm not familiar with Kermit, but I'm sure there have
to be ways to specify/guess that a file is to be stored as binary on a PDP-10,
since storing it as ascii would destroy it.  It's not an easy problem, but
has nothing to do with the proposal.  All the proposal says is that once
it is determined, in whatever way, that the file should be stored as binary,
Kermit should store the identifier before the data so that future attempts
to download the file can do the right thing automatically.  This should
remain true even after the file is FTP'ed to another system, and for this
reason even 8-bit systems like Unix or VMS should store the identifier on
upload. And conversely, this should remain true even if the file is FTP'ed
from another system, and for this reason Unix and VMS should recognize the
identifier before download.

          Second, although SIG/M and CPMUG volumes are stored
    in the proposed format, there may be other sites that have similar
    databases stored in other formats; would they have any objection to the
    proposed change?

Well, if they don't convert, attempting to download them will require the
user to explicitly specify which files are binary and which are ascii, as
the system will not be able to determine this automatically.  It could then
either assume they are ascii, or use whatever method it used in the
pre-KRFC3 days.  Presumably a user can state his preference through a
command or switch.  Of course the user will need to know he's dealing
with such files, and he'll need to know the format of each.  Enough users
might complain to prompt the database maintainers to comply with the
standard.

                           When sending files back to
    the micro, the DEC-10 or -20 is capable of picking up the bytesize from the
    file's directory entry and sending it appropriately;

No, the bytesize in the FDB is unreliable.  In particular transfering a file
over the arpanet or chaosnet in the most efficient way will clobber the
byte size to 36.

    Date: Mon 26 Sep 83 18:12:09-EDT
    From: Frank da Cruz <cc.fdc at COLUMBIA-20.ARPA>
    To:   Info-Kermit at COLUMBIA-20.ARPA
    Re:   KRFC #3

      - For outgoing files, if the first word is SIXBIT/DSK8/, don't
        transmit the first word.

Even more to the point, if the first word is SIXBIT/DSK8/, interpret
the rest of the words as 8 bit bytes. On 8-bit systems, if the first
four bytes are 93H 3AH D8H 00H, ignore them.  (There should be a user
command to say not to do that on a particular transfer).

      - For incoming files, if the first 4 characters are DSK8, then store
        the file in 8-bit mode, even if the prevailing mode is 7-bit (would
        any system ever actually send a binary file this way?)

I don't think this was the intention of the proposal.  Since it's hard for
a micro to determine how the file should be stored on the mainframe, it
doesn't make much sense for it to be making the decision (a PDP-10 can check
a file for 8th-bit-set faster than you can blink an eye). But in any case,
all that's being proposed is that however binariness is determined,
"storing the file in binary mode" on a mainframe would be DEFINED to mean
prefixing the data with SIXBIT/DSK8/ on a 10 or 93H 3AH D8H 00H on an 8-bit
system.

29-Sep-83 12:15:30-EDT,2655;000000000001
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 29 Sep 83 12:15:21 EDT
Date: Thu 29 Sep 83 12:16:14-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: KRFC #3 (ITS Binary Format)
To: [e-mail], Info-Kermit@CUCS20
cc: [e-mail]
In-Reply-To: Message from "Gail Zacharias <GZ@MIT-OZ>" of Wed 28 Sep 83 17:37:06-EDT

Although not all the comments about ITS binary format made it to the mailing
list, sentiments seem to be running strongly both in favor of it and against
it.  To make both camps happy, let's make KERMIT-20 (I won't mention KERMIT-10;
its makers should comment if they have any objection) support of ITS binary
format work as follows:

1. Outgoing files:  Handling of ITS binary format will be OPTIONAL, with the
   default specifiable by the site manager, and overridable by the user.

   a. If the first 36-bit word of the file is SIXBIT/DSK8/, then:

      i.  If ITS format is selected, the first word will not be transmitted,
      and the file will be read from the disk in 8-bit mode, regardless of the
      byte size indicated in the FDB.

      ii. If ITS format is not selected, the entire contents of the file will
      be transmitted, with bytes fetched from the file according to the byte
      size given in the FDB: 8 bit bytes if the FDB says 8; 7 bit bytes
      otherwise, with b8 of every 5th byte set to the value of b35 from the
      PDP-10 word it came from.

   b. If the first word is not SIXBIT/DSK8/, then the file will be sent
   according to the bytesize in the FDB, as above.

2. Incoming files:  ITS binary format handling is an option, as above.

   a. If ITS binary format handling is enabled, then:

      i.  If the first 4 characters of the file are 93H 3AH D8H 00H, then store
      the file with the sixbit DSK8 header in 8-bit bytes, and set the file
      byte size in the FDB to 8.  Do this regardless of the prevailing output
      file bytesize setting.

      ii. If the first 4 characters of the file are anything else, then store
      the entire contents of the file according to the prevailing output
      bytesize.

   b. If ITS binary format handling is not enabled, store the incoming file
   according to the prevailing output file bytesize setting.

I believe this will allow any conceivable style of transmission and storage to
work; for instance, you can use KERMIT-20 to operate automatically on any
mixture of ITS binary, text, and 8-bit binary (without header) files.  You can
send files with or without the header, etc.

Any objections?

- Frank
-------
29-Sep-83 15:19:50-EDT,3098;000000000001
Return-Path: <@CUCS20:OC.GARLAND@CU20B>
Received: from CUCS20 by CU20B with DECnet; 29 Sep 83 15:19:42 EDT
Received: from CU20B by CUCS20 with DECnet; 29 Sep 83 15:21:02 EDT
Date: Thu 29 Sep 83 15:14:57-EDT
From: Richard Garland <OC.GARLAND@CU20B>
Subject: Re: KRFC #3 (ITS Binary Format)
To: cc.fdc@CUCS20
cc: [e-mail], Info-Kermit@CUCS20,
    [e-mail], OC.GARLAND@CU20B
In-Reply-To: Message from "Frank da Cruz <cc.fdc@CUCS20>" of Thu 29 Sep 83 12:15:32-EDT

Several comments on the BINARY/ASCII ITS issue:

There are two real concerns I believe:

    How to interpret the proper mode (i.e. bytesize, BINARY vs. ASCII)
    of a file already resident on a host, presumably so it can be
    transmitted correctly. "How to know what you got."

    and

    How the reciever of a file can be told the type of file and
    how to store it.  "How to tell the other guy."

ITS-binary format is aparently an attempt to solve the first issue on
DEC-10's running various operating systems.  Other systems attempt to
solve it in other ways: viz. the bytsize in the file header on Tops-20.
Other systems don't care (ie. VMS, Unix, IBM) since there is no
mismatch between bytes and words - just save everything as 8 bit bytes
and Binary and ASCII are equivalent.  CPM systems tend to be in the
later category.


On the second issue, generally Kermit and other protocols tend to
guess or ask the user the best way to transmit.  Aparently FTP
defaults to 36 bit mode between 36 bit machines no matter what the
undelying convention is (i.e. whether ITS-binary is in affect or
if the bytesize is set on Tops-20).  This can be overridden by the
user.

My suggestions for Kermit conventions are as follows:

    Let each operating system and Kermit decide how best to
store a file and "remember" its mode.

    Define a Kermit protocol code so a sending kermit can
tell a recieving Kermit the mode.  It can derive this
information from the file system, the header, the user, the
file type convention or anywhere it pleases.  The receiver
can similarly save this information according to its local
convention.  The protocol could specify the mode as ASCII/
BINARY/DONT KNOW/DONT CARE etc. or perhaps 7BIT/8BIT/DONT
KNOW/DONT CARE etc.  Make it open ended to accomodate things
we havn't thought of.

Bottom line
-----------------------------------------------------------------
1.    Define a kermit protocol packet to tell a recieving host the
    mode of the file.

2.    Let each host remember this mode however it likes.

3.    Accomodate ITS-binary on option on 36-bit machines.  This can
    simply be a special case of point 2. and can be done as Frank da
    Cruz suggests.

4.    DO NOT adopt ITS-binary conventions as Kermit transmission
    conventions.  Point 1. is a cleaner and less error prone
    method.  Thus although you may want to STORE the mode information
    in the file itself (as ITS does) you don't want to depend on
    the file contents as a means for Kermit to transmit special
    information.

                    Rg
-------
30-Sep-83 10:39:23-EDT,2330;000000000001
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 30 Sep 83 10:39:10 EDT
Date: Fri 30 Sep 83 10:39:53-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: KRFC #3 (ITS Binary Format)
To: OC.GARLAND@CU20B
cc: GZ%MIT-OZ%MIT-MC@CUCS20, Info-Kermit@CUCS20, WANCHO%SIMTEL20%MIT-MC@CUCS20,
    OC.GARLAND@CU20B, cc.fdc@CUCS20
In-Reply-To: Message from "Richard Garland <OC.GARLAND@CU20B>" of Thu 29 Sep 83 15:21:19-EDT

Unfortunately, it's a little late in the game for changing the protocol in such
a fundamental way by adding file attribute information for each file.  More
to the point, however, there's probably no good way of doing this.  Consider,
for instance, just a PDP-10 and a CP/M-80 system.  We want the sender to tell
the receiver whether a file is binary or text.  The PDP-10 sends a text file.
The micro stores it according to its own convention (^Z in the last block to
mark the EOF).  Then the PDP-10 sends a 36-bit binary file.  The micro stores
it exactly the same way.  Telling the micro that this file is binary does no
good at all, because it has no other way to store files.  To send these files
back to the PDP-10 correctly, the user must tell the micro which is which;
otherwise the micro might stop sending the PDP-10 binary file before the end
(e.g. if there happened to be a ^Z among the data in the last block).  And even
then we have to distinguish between PDP-10 binary files (which could end
anywhere in the last block) and CP/M binary files, which include the entire
last block.  Even if we knew how to correctly distinguish the end of file on
these two kinds of binary files, we'd have to tell the PDP-10 that the PDP-10
binary file was a TEXT file, so it would be stored in 5 7-bit bytes per word
(plus the bit 35 trick) rather than 4 8-bit bytes, whereas the CP/M file would
have to be stored in 8-bit bytes.  These are just SOME of the complications
that arise between a SINGLE PAIR of systems.  When you try to forsee the
complications that can arise between ANY pair of systems, you are hard pressed
to account for them in a simple protocol.  Consider that DECnet Data Access
Protocol, for all its unbelievable hairiness, can still only manage to transfer
sequential ASCII files between a PDP-10 and a VAX...

- Frank
-------
 1-Oct-83 04:04:02-EDT,543;000000000000
Return-Path: <@CUCS20:Elmo@MIT-OZ>
Received: from CUCS20 by CU20B with DECnet; 1 Oct 83 04:03:59 EDT
Received: from MIT-MC by COLUMBIA-20.ARPA with TCP; Sat 1 Oct 83 04:05:03-EDT
Date: Sat, 1 Oct 1983  04:03 EDT
Message-ID: <[MIT-OZ].GREN.ELMO. 1-Oct-83 04:03:41>
To:   [e-mail]
Cc:   Elmo@MIT-OZ
From: Eliot R. Moore <Elmo@MIT-OZ>
Reply-to: Elmo%Mit-Oz@Mit-ML
Subject: Commodore Kermit
Sender: Elmo@MIT-OZ

Has anyone implemented Kermit on the Commodore 64?

Pointers appreciated.

Regards, Elmo

 1-Oct-83 16:52:56-EDT,860;000000000000
Return-Path: <@CUCS20:jalbers@BNL>
Received: from CUCS20 by CU20B with DECnet; 1 Oct 83 16:52:52 EDT
Received: from BNL by COLUMBIA-20.ARPA with TCP; Sat 1 Oct 83 16:53:54-EDT
Date:  1-Oct-83 16:51:56-EDT
From: jalbers@BNL
Subject: Kermit for the Osborne Executive
To: info-kermit@COLUMBIA-20

I'm sorry to open old wounds, but after following all instructions, including
setting the modem port to AUXIN/AUXOUT, and it still won't work!!!  It starts
up, and even goes into terminal mode correctly, but it will not talk to the
modem port.  Has anyone got Kermit working???  Pls help me!!!  I cannot get it
up at all, and soon I will not have a host that will let me download via MODEM7.


                                                                  Jon Albers
                                                                  jalbers@bnl
 1-Oct-83 19:55:51-EDT,686;000000000001
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 1 Oct 83 19:55:47 EDT
Received: from HI-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Sat 1 Oct 83 19:56:48-EDT
Redistributed-Date:  1 October 1983 18:49 est
Redistributed-By:  DBrown.TSDC at HI-MULTICS
Redistributed-To:  Info-Kermit at COLUMBIA-20
Redistributed-Date:  30 September 1983 19:29 cdt
Redistributed-By:  RLee.SysAdmin at HI-MULTICS
Redistributed-To:  DBrown.TSDC at HI-MULTICS
Date:  29 September 1983 15:03 est
From:  DBrown.TSDC at HI-MULTICS
Subject:  Re: KRFC3 (Binary Format)
To:  Info-Kermet at COLUMBIA-20

Re: Richard Garlands suggestion.
  Hear hear!
 -- dave
 3-Oct-83 11:33:28-EDT,1105;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 3 Oct 83 11:32:56 EDT
Date: Mon 3 Oct 83 11:33:33-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New 8085/Z80 cross assembler
To: Info-Kermit@CUCS20
cc: BBoard@CUCS20

A new release of the MAC80 cross assembler from Bruce Tanner at Cerritos
College is available for testing.  The previous version assembled only 8080 or
8085 code; the new version also will assemble Z80 code.  It has been tested
here on the CP/M Kermit source, and it works for that.  Does anyone have any
Z80 programs they'd like to cross-assemble?

The new version is in KER:ZAC80.EXE at host COLUMBIA-20.  A new manual is
available as KER:ZAC80.DOC.  A "torture test" for the Z80 support is in
KER:ZORTUR.MAC.  If no problems are reported within a week or two, the new
version will replace the old MAC80; meanwhile, both versions coexist in the
KER: area -- the old in files starting with M, the new one in files starting
with Z.  Please send any comments directly to me, and I'll forward them to the
author.

- Frank
-------
 3-Oct-83 11:45:08-EDT,751;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 3 Oct 83 11:45:03 EDT
Date: Mon 3 Oct 83 11:36:41-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: Commodore Kermit
To: [e-mail], Info-Kermit@CUCS20
In-Reply-To: Message from "Eliot R. Moore <Elmo@MIT-OZ>" of Sat 1 Oct 83 04:05:10-EDT

No one has implemented Kermit on the Commodore 64, to my knowledge.  A number
of people on the systems staff at Columbia have got these machines, and one of
them might break down and do it as a spare time project, but if someone else
wants to try it first, please do.  If you have a DEC-10 or -20, you can work
from the Stevens Apple Kermit, written in CROSS language for the 6502.  - Frank
-------
 3-Oct-83 12:11:06-EDT,643;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 3 Oct 83 12:10:44 EDT
Received: from MIT-MC by COLUMBIA-20.ARPA with TCP; Mon 3 Oct 83 12:11:36-EDT
Date: Mon 3 Oct 83 12:10:07-EDT
From: Daphne Tzoar <[e-mail]>
Subject: Re: Commodore Kermit
To: [e-mail]
cc: [e-mail], [e-mail]
In-Reply-To: Message from "Eliot R. Moore <Elmo@MIT-OZ>" of Sat 1 Oct 83 04:05:11-EDT

A few people have said they would write a Commodore 64 version of Kermit.
So far, though, I haven't heard any more about it.
/daphne
-------

 3-Oct-83 20:18:29-EDT,559;000000000000
Return-Path: <@CUCS20:HOWALD@USC-ECLB>
Received: from CUCS20 by CU20B with DECnet; 3 Oct 83 20:18:26 EDT
Received: from USC-ECLB by COLUMBIA-20.ARPA with TCP; Mon 3 Oct 83 20:19:26-EDT
Date:  3 Oct 1983 1713-PDT
From: HOWALD <HOWALD@USC-ECLB>
Subject: Telenet connections
To: info-kermit@COLUMBIA-20

Has anyone on the net tried to use KERMIT over Telenet with success?  I
can't get it to run over Telenet--the initial packet transfer is never
successful, so after 15 or 16 tries it gives up.  Thanks in advance
for any help or advice.
-------
 4-Oct-83 00:47:40-EDT,1068;000000000000
Return-Path: <@CUCS20:OC.TREI@CU20B>
Received: from CUCS20 by CU20B with DECnet; 4 Oct 83 00:47:35 EDT
Received: from CU20B by CUCS20 with DECnet; 4 Oct 83 00:48:36 EDT
Date: Tue 4 Oct 83 00:47:06-EDT
From: Peter G. Trei <OC.Trei@CU20B>
Subject: Another Commodore enthusiast...
To: Info-kermit@CUCS20, [e-mail]
cc: mm24@CMCCTF, oc.trei@CU20B
[Permanent Committee to Overthrow the Goverment Next Tuesday after Lunch]

    I pass on the following message from MM24@CMCCTD (one of
CMU's deccnet nodes: mail routed thru CU ought to make it.)

 1-Oct-83 02:32:20-EDT,389;000000000001
Return-Path: <MM24@CMCCTD>
Received: from CMCCTD by CU20B with DECnet; 1 Oct 83 02:32:13 EDT
Received: ID <MM24@CMCCTD>; 1 Oct 83 02:30:13 EDT
Date: 30 Sep 83 21:01:10 EDT
From: MM24@CMCCTD
To: oc.trei@CU20B
Subject: Kermit


I own a Commodore-64: it has a 6502 equivilent.  I'd be interested in
the source for the Apple Kermit
-Michael McInerny, CMU
mm24@cmcctd
   --------

                    Peter Trei
                    <oc.trei>%cu20b@columbia-20
-------
 4-Oct-83 01:06:10-EDT,943;000000000000
Return-Path: <@CUCS20:OC.TREI@CU20B>
Received: from CUCS20 by CU20B with DECnet; 4 Oct 83 01:06:06 EDT
Received: from CU20B by CUCS20 with DECnet; 4 Oct 83 01:07:07 EDT
Date: Tue 4 Oct 83 01:05:38-EDT
From: Peter G. Trei <OC.Trei@CU20B>
Subject: Telenet & Kermit...
To: info-kermit@CUCS20, [e-mail]
[Permanent Committee to Overthrow the Goverment Next Tuesday after Lunch]


    Telenet can be pretty flakey; unless you are
sending datagrams the route taken by each packet is
variable, and it is not unknown for packets to arrive
out of sequence. Also, the response time is not too good:
they claim an average of 1 second line turnaround time,
but 10-15 seconds is not unknown. This might give you
timeouts if you are using the defaults. Between 1 and 3 AM
is especially bad since Burroughs (I think) uses it then for
transfering BIG files.

                    Peter trei
                    oc.trei%cu20b@columbia-20

-------
 4-Oct-83 09:47:01-EDT,585;000000000001
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 4 Oct 83 09:46:56 EDT
Date: Tue 4 Oct 83 09:47:45-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: Telenet connections
To: [e-mail], info-kermit@CUCS20
In-Reply-To: Message from "HOWALD <HOWALD@USC-ECLB>" of Mon 3 Oct 83 20:13:00-EDT

To use KERMIT over TELENET, you have to give the KERMIT command "SET PARITY
MARK", in order to have KERMIT generate bytes with the parity that TELENET
seems to insist upon, and to ensure that the checksums come out right.
- Frank
-------
12-Oct-83 14:28:27-EDT,2446;000000000000
Return-Path: <@CUCS20:SY.FDC@CU20B>
Received: from CUCS20 by CU20B with DECnet; 12 Oct 83 14:28:20 EDT
Received: from CU20B by CUCS20 with DECnet; 12 Oct 83 14:28:22 EDT
Date: Tue 11 Oct 83 19:30:45-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: KRFC #5
To: Info-Kermit@CUCS20
Reply-To: CC.FDC@COLUMBIA-20

KERMIT RFC #5 -- "KERMIT Capabilities Word"

In the Kermit Protocol Manual, it says that fields 10 and 11 of the Send-Init
packet are reserved for future use, and that sites that wish to add new fields
should start at field 12.  To my knowledge, no site has added features
requiring the use of any new Send-Init fields (Cornell University long ago
added checksum options, but these now have an "official" field in the Send-
Init packet).  Thus I propose

(1) using these two fields as a "KERMIT Capabilities Word" (KCW), and

(2) moving the reserved fields to positions 12-15.

The capabilities word will be two six-bit quantities, whose bits tell whether
the Kermit program sending the packet has or does not have the corresponding
capability.  The values for each field will be in the range 0-63, converted to
printable characters by adding 32 (all numbers in decimal).  12 different
capabilities may be thus signified.

The capabilities will be numbered 1 through 12, as follows:

Field 10 (KCWA)                      Field 11 (KCWB)
+----+----+----+----+----+----+    +----+----+----+-----+-----+-----+
| #1 | #2 | #3 | #4 | #5 | #6 |    | #7 | #8 | #9 | #10 | #11 | #12 |
+----+----+----+----+----+----+    +----+----+----+-----+-----+-----+

where the boxes represent bits in the 6-bit quantities, high order being the
leftmost.  If the binary values (i.e. before addition of 32) of the two fields
are "concatenated" to form a 12-bit quantity A, then capability #n is on if

 A AND 2^(12-n) = 2^(12-n)

The values of the quantity A may range from 0 to 4095.  New capabilities will
be added from left to right, so that Field 11 need not be included until Field
10 is used up (i.e. all the bits defined).  If more than 12 capabilities need
be defined, they can be included in subsequently allocated fields (in which
case "12" in the formula above should be replaced by "m", where m is the number
of capabilities represented).

The operation of any pair of KERMITs with respect to any particular capability
will be defined for each such capability.

Comments, suggestions?
-------
12-Oct-83 19:13:45-EDT,7341;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 12 Oct 83 19:13:37 EDT
Date: Wed 12 Oct 83 19:14:23-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: KRFC #6, File Attributes
To: Info-Kermit@CUCS20

The recent discussion of automatic recognition of binary versus text files has
prompted the following proposal for sending file attributes along with a file.
The previous proposal (KRFC #5) gave a mechanism that would allow this major
change to be made to the KERMIT protocol without disturbing older KERMIT
implementations that did not know about it.

KERMIT RFC #6: File Attributes

A major shortcoming of KERMIT is the inability of the sender of a file to
provide the receiver with any information about the file other than its name.
Here is an idea that will allow a certain number of attributes to be provided
to KERMITs that are prepared to deal with this information.

First, define Kermit Capability #1 to be the ability to send and receive a new
packet type, "A" for Attributes.  If both sides set this bit in the Kermit
Capability Word, then the sender, after sending the filename in the "F" packet
and receiving an acknowledgement, may (but does not have to) send an "A" packet
to provide file attribute information.

The attributes will be given in the data field of the "A" packet.  The data
field will consist of 0 or more subfields, which may occur in any order.  Each
subfield is of the following form:

<attribute><length><data>

where <attribute> is a single printable character other than space,

      <length>    is the length of the data characters (0 to 94), with 32
                  added to produce a single printable character, and

      <data>      is <length> characters worth of data, all printable
                  characters.

No quoting or prefixing is done on any of this data.

There may be 93 different attributes, one for each of the 93 printable ASCII
characters other than space.  These will be assigned in ASCII order.  Here are
some suggestions for the first few:

! (ASCII 33) Length.  The data field gives the length in K (1024) bytes,
             as a printable decimal number, e.g. "!#109".  This will allow
             the receiver to determine in advance whether there is sufficient
             room for the file, and/or how long the transfer will take.

" (ASCII 34) Type.  The data field can contain some indicator of the nature
             of the file.  Note that only sequential files can be supported
             by the KERMIT protocol.  Here are some suggested types:

             Axx   ASCII text, containing no 8-bit quantities, logical records
                   delimited by the (quoted) control character sequence "xx",
                   represented here by its printable counterpart (MJ = CRLF,
                   J = LF, etc).  For instance AMJ means that the appearance
                   of #M#J (the normal prefixed CR-LF sequence) in a file data
                   packet indicates the end of a record.

             Bxx   Binary.  "xx" indicates in what manner the file is binary:

                   8  The file is a sequence of 8-bit bytes, which must be
                      saved as is.  The 8th bit may be sent "bare", or prefixed
                      according to the Send-Init negotiation about 8th-bit
                      prefixing.

                   36 The file is a PDP-10 format binary file, in which five
                      7-bit bytes are fit into one 36-bit word, with the final
                      bit of each word being represented as the "parity bit" of
                      every 5th character (perhaps prefixed).

             Dx    Variable length undelimited records.  Each logical record
                   begins with an x-character ASCII length field (similar to
                   ANSI tape format "D").

             Fxxxx Fixed-length undelimited records.  Each logical record is
                   xxxx bytes long.

         I     Image.  The file is being sent exactly as it is represented
                   on the system of origin.  For use between like systems.

# (ASCII 35) Creation Date, expressed as "ddmmyy hhmmss", e.g. 070983 135700.
             The time is optional; if given, it should be in 24-hour format,
             and the seconds may be omitted.

$ (ASCII 36) Creator's ID, expressed as a character string of the given length.

% (ASCII 37) Account to charge the file to, character string.

& (ASCII 38) Area in which to store the file, character string.

' (ASCII 39) Password for above, character string.

( (ASCII 40) Block Size.  The file is to be stored with the given block size.
             This may be useful when sending files to or from IBM mainframes,
             VAX/VMS, or other systems where files may have this attribute.

) (ASCII 41) Access:
             N  New, the normal case -- create a new file of the given name.
             S  Supersede (overwrite) any file of the same name.
             A  Append to file of the given name.

* (ASCII 42) Encoding:
             A  ASCII, normal ASCII encoding with any necessary prefixing, etc.
             H  Hexidecimal "nibble" encoding.
             X  Encrypted.

Well, many of these can be imagined, and can be added later if needed.
However, two important points should be noted:

 The receiver may have absolutely no way of honoring, or even recording, a
  given attribute.  For instance, CP/M-80 has no slot for creation date or
  creator's ID in its FCB; the DEC-20 has no concept of block size, etc.

 The sender may have no way of determining the correct values of any of the
  attributes.  This is particularly true when sending files of foreign origin.

The "A" packet mechanism only provides a way to send certain information about
a file to the receiver, with no provision or guarantee about what the receiver
may do with it.  That information may be obtained directly from the file's
directory entry (FCB, FDB, or whatever), or specified via user command.

The ACK to the "A" packet may in turn have information in its data field.
However, no complicated negotiations about file attributes may take place, so
the net result is that the receiver may either refuse the file or accept it.
The receiver may reply to the "A" packet with any of the following codes in the
data field of the ACK packet:

<null>  (empty data field) I accept the file, go ahead and send it.

Nxxx    I refuse the file as specified, don't send it; "xxx" is zero or more
        of the attribute characters listed above, to specify what attributes
        I object to (e.g. "!" means it's too long, "&" means I don't have write
        access to the specified area, etc).

Yxxx    I agree to receive the file, but I cannot honor attributes "xxx", so
        I will store the file according to my own defaults.

Y       (degenerate case of Yxxx..., equivalent to <null>, above)

How the receiver actually replies is an implementation decision.  A NAK in
response to the "A" packet means, of course, that the receiver did not receive
the "A" correctly, not that it refuses to receive the file.

(End of KERMIT RFC #6)  Any comments, suggestions, additions, deletions?
-------
13-Oct-83 09:40:10-EDT,4763;000000000001
Return-Path: <@CUCS20:SY.FDC@CU20B>
Received: from CUCS20 by CU20B with DECnet; 13 Oct 83 09:40:02 EDT
Received: from CU20B by CUCS20 with DECnet; 13 Oct 83 09:40:32 EDT
Date: Thu 13 Oct 83 09:39:16-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: [J. Ray Scott <JS5A@CMCCTA>: Two PC Kermit issues for development]
To: Info-Kermit@CUCS20

This might be of some interest to the list...  - Frank
                ---------------

   1) 12-Oct J. Ray Scott         Two PC Kermit issues for development
   2) 13-Oct To: JS5A@CMCCT       Re: Two PC Kermit issues for development

Message 1 -- ************************
Return-Path: <JS5A@CMCCTA>
Received: from CMCCTA by CU20B with DECnet; 12 Oct 83 20:22:25 EDT
Received: ID <JS5A@CMCCTA>; 12 Oct 83 20:20:49 EDT
Date: 12 Oct 83 20:20:03 EDT
From: J. Ray Scott <JS5A@CMCCTA>
To: sy.fdc@CU20B
Campus-Phone: [phone]
Subject: Two PC Kermit issues for development

Frank: I have two KERMIT issues for consideration.  We are willing to work
on them but slowly.

First, the last version we got for the IBM PC had the backspace key (the
one above the "return" key) send a control-H.  Previous CMU versions had this
send a delete since TOPS-20 and VAX don't really use control-H very much.
While I was tempted to change it back I did some checking and found that
both IBM and UNIX systems liked ^H much better than DEL and since the
combination of UNIX and IBM uses outnumber the TOPS/VMS users I figured we
should consider have some sort of user settable option?  ...or perhaps an
assembly parameter?  It is easy enough to change but I am afraid that the
terminal emulation part of this may get out of hand if we all go our own
ways.

Second, as we were updating the terminal emulation mode it became clear
that having separate modules is very important.  We eventually ripped out
the terminal emulation code and made a stand alone program.  Even that takes
over 3 minutes to compile.

For general interest, we have put in support for some of the VT52 type
function keys.  We are anxious to be able to run the WORD-11 word processing
package via Kermit.  While this may sound odd, we have a great number of
WORD-11 users who also happen to need or want PC's for other reasons.  We have
not found a word processing package for the PC which is nearly as good as
WORD-11.  This seems like a good way to get people started on PC's while not
losing all the function they have had on mainframes.  When we get our code
debugged and merged back into KERMIT we will make it available.

If time permits, we will look at breaking PC KERMIT up into modules.

                            J. Ray Scott
   --------

Message 2 -- ************************
Mail-From: SY.FDC created at 13-Oct-83 09:35:38
Date: Thu 13 Oct 83 09:35:38-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Re: Two PC Kermit issues for development
To: JS5A@CMCCTA
cc: SY.FDC@CU20B
In-Reply-To: Message from "J. Ray Scott <JS5A@CMCCTA>" of Wed 12 Oct 83 20:20:03-EDT

I agree that it might be desirable to break Kermit-86 up into modules; it would
certainly be a good idea for any Kermit that wants to support multiple systems
(Kermit-80 is the top candidate, UNIX Kermit the next).  The relevant modules
would seem to be: (a) protocol (system independent), (b) command parsing (so
people can substitute function keys for the COMND-style interface if they like,
or substitute a UNIX-style interface, etc), (c) terminal emulation (plug in
your favorite terminal), (d) port i/o, (e) disk i/o, (f) screen i/o.  If these
can be relatively modular and well defined, it would become much easier to add
support for new machines, operating system versions, modems, disk drives, etc
etc.  This has been our plan for some time, though we've yet to get started on
it.  This would be a good time for doing it to PC Kermit, because it contains
explicit support for only two systems, the IBM PC and the Z100.

I also agree that the code the backspace key sends should be made user
settable.  This is actually part of a larger problem.  What we need to have is
a way a user can set KERMIT up for communicating with a particular system.
This would involve at least the addition of a command or initialization file
capability.  Each user's KERMIT.INI could contain definitions of the settings
for each kind of system, e.g.

DEFINE IBM = DUPLEX HALF, HANDSHAKE ^Q, PARITY MARK, BACKSPACE BS
DEFINE UNIX = DUPLEX FULL, HANDSHAKE OFF, PARITY NONE, BACKSPACE DEL
DEFINE DEC-20 = UNIX
DEFINE TELENET = PARITY MARK

and so forth.  The user would then just type SET IBM or SET UNIX to establish
all the right settings (or perhaps simply, CONNECT IBM).

Again, it's planned, but no action yet.  - Frank
-------
-------
13-Oct-83 10:52:33-EDT,1096;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 13 Oct 83 10:52:25 EDT
Date: Thu 13 Oct 83 10:52:28-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: KRFC #5 (capabilities)
To: Info-Kermit@CUCS20

Here's a suggested modification to KRFC #5 (capabilities field) that makes
a lot of sense.  I'd like to incorporate it into the RFC.  (It's from Case
Western Reserve University.)  - Frank
                ---------------

Date: Thu 13 Oct 83 08:24:53-EDT
From: Rob Gingell <GINGELL%CWR20B@COLUMBIA-20>
Subject: Re: KRFC #5
To: CC.FDC@COLUMBIA-20

I may be demonstrating a woeful ignorance of the KERMIT protocol, but
could you encode the capabilities bytes as a bit-field extensible set
a la NSP?  That is, use something like the LSB of each byte as a flag
that another byte with more bits is coming.  The capabilities field would
then end upon receiving a capability byte with a LSB of 0.  That way
the protocol would not have to be updated each time a field ran out
of space, it would extend naturally to any length.

    Rob
-------
14-Oct-83 19:12:23-EDT,765;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 14 Oct 83 19:12:20 EDT
Date: Fri 14 Oct 83 19:13:10-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Two more KRFC's coming...
To: Info-Kermit@CUCS20

I'm in the process of revamping the KERMIT Protocol Manual to incorporate
some of the newly proposed features, and to generally reorganize it into a
more complete and clear working document.  If anyone has any further comments
on the recent "Kermit RFC's", please send them soon, since their prose may
soon turn to code...  Meanwhile, a couple new ones will follow this message --
one suggests a "normal form" for file names, and the other suggests some
standard terminology and names for commands.  - Frank
-------
14-Oct-83 19:25:43-EDT,2822;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 14 Oct 83 19:25:39 EDT
Date: Fri 14 Oct 83 19:17:52-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: KRFC #7, Normal Form for File Names
To: Info-Kermit@CUCS20

KRFC #7, Normal Form for File Names

As the various KERMITs have come into being, an unspoken convention has emerged
with respect to how file names are represented in file header packets.
Although the explicit rule is that it is the responsibility of the recipient
to convert the file name to a form that complies with local conventions, it
turns out that many of the smaller implementations of KERMIT (particularly for
CP/M and other microcomputer systems) took no such measures.

This was not a problem when all the systems that had KERMITs had the same idea
of what a filename looked like, namely "foo.bar", where "foo" and "bar" were
sequences of digits, uppercase letters, and maybe a few special characters,
with no imbedded spaces or control characters.

When IBM VM/CMS and UNIX started speaking KERMIT, however, great confusion
resulted in micro land -- files appeared on CP/M disks that could not be
referred to in any normal fashion, e.g. files with pathnames and lowercase
letters in their names from UNIX, or with spaces from the CMS file system.
Consequently, the mainframe versions were changed to send filenames in the
"normal form".  UNIX strips the pathname and converts to upper case on output,
CMS converts "FILENAME FILETYPE FILEMODE" to "FILENAME.FILETYPE", and so forth.

Shall we codify this practice?  Are the following rules reasonable?

1. Delete all pathnames from the file specification.  The file header packet
should not contain directory or device names (if it does, it may cause the
recipient to try to store the file in an inaccessible or nonexistent area, or
result in a very funny filename).

2. If communicating in "image mode" (see KRFC #6), send filenames as-is.

3. If not in image mode, convert filenames to "normal form", if necessary.
   Normal form is "name.type", with no restriction on length (except that it
   fit in the data field of the F packet), and:

   (a) No more than one dot.
   (b) Digits, uppercase letters only in "name" and "type".

Special characters like $, _, -, &, and so forth should probably be disallowed,
since they're sure to cause problems on one system or another.

The recipient, of course, cannot depend upon the sender to follow this
convention, and should still take precautions.  However, since most file
systems embody the notion of a file name and a file type, this convention will
allow these items to be expressed in a way that an unlike system can
understand.  The particular notation is chosen simply because it is the most
common.
-------
14-Oct-83 19:40:23-EDT,7589;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 14 Oct 83 19:40:14 EDT
Delivery-Notice: While sending this message to CU20B, the
 CUCS20 mailer was obliged to send this message in 50-byte
 individually Pushed segments because normal TCP stream transmission
 timed out.  This probably indicates a problem with the receiving TCP
 or SMTP server.  See your site's software support if you have any questions.
Date: Fri 14 Oct 83 19:20:33-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: KRFC #8, Commands and Terminology
To: Info-Kermit@CUCS20

KRFC #8, Commands and Terminology

As KERMIT spreads and the number of implementations and features grows,
the time has come to suggest some standard terminology for KERMIT, its
environment, and its functions.

An example of how confusion can creep in came up recently when a site added the
capability to IBM PC Kermit to tell a server to change its working directory
(generic "C" command).  The name they chose for the IBM PC command was ATTACH,
because that happens to be the name of the same command on their mainframe.  On
other systems, ATTACH has a different meaning -- for instance, to "connect"
one's terminal to a "detached" (disconnected, disassociated) "job", and another
term, like CONNECT, is used to change one's working directory.  But then,
CONNECT is already used in KERMIT to invoke a virtual terminal connection...

Furthermore, as more functionality is added to Kermit servers, and commands
added to user programs to invoke them, while the same functions are being added
to the user programs themselves, the potential for confusion becomes even
greater.  For instance, a Kermit user program might have a command to delete a
local file and another one to ask a server to delete a remote file.

At first, it seemed desirable to let each implementation preserve the flavor of
its host operating system, but now we are beginning to get different commands
that do the same thing, the same command doing different things, and other odd
situations, and we're getting a user manual that is very thick.  So the
following list of commands and terms is suggested.  It is not intended to
recommend a particular style of command parsing, only to promote a consistent
vocabulary, both in documentation and in choosing the names for commands.

* Who's Who:

LOCAL: When two machines are connected, the LOCAL machine is the one which you
  interact with directly.  The "local Kermit" is the one that runs on the local
  machine.  A local Kermit always communicates over an external device (the
  micro's communication port, an assigned TTY line, etc).

REMOTE: The REMOTE machine is the one on the far side of the connection, which
  you must interact with "through" the local machine.  The "remote kermit" runs
  on the remote machine.  A remote Kermit usually communicates over its own
  "console" or "controlling terminal".

HOST: This term should be avoided, unless preceded immediately by LOCAL or
  REMOTE.

SERVER: An implementation of remote Kermit that can accept commands in packets
  from a local Kermit.

USER: In addition to its usual use to denote the person using a system or
  program, "user" can also refer to the local Kermit, when the remote Kermit is
  a server.


* Basic Commands:

SEND: This verb tells a Kermit program to send one or more files from its own
  file structure.

RECEIVE: This verb should tell a Kermit program to expect one or more files to
  arrive.

GET: This verb should tell a user Kermit to send one or more files.  Some
  Kermit implementations have separate RECEIVE and GET commands; others use
  RECEIVE for both purposes, which creates confusion.


* Terminal Emulation:

CONNECT: This verb, valid only for a local Kermit, means to go into terminal
  emulation mode; present the user with the illusion that s/he is directly
  connected to the remote system.

(Almost every microcomputer implementation of KERMIT has this command.  It
might have been wiser to call it TERMINAL, but it's too late now...)


* Special User-Mode Commands:

(These commands are used only by Users of Servers.)

BYE: This command sends a message to the remote server to log itself out, and
  upon successful completion, the local Kermit program to terminate.

FINISH: This command causes the remote server to shut itself down gracefully
  without logging out its job.


* Commands Whose Object Should Be Specified:

Many Kermit implementations include various local file management services and
commands to invoke them.  For instance, CP/M Kermit recently (announcement
forthcoming) has commands to let you get directory listings, delete files,
switch disks, and inquire about free disk space without having to exit and
restart the program.  Soon, remote servers will also provide such services.  A
user Kermit must be able to distinguish between commands aimed at its own file
system and those aimed at the remote one.  When any confusion is possible, such
a command may be prefixed by:

REMOTE - Ask the remote Kermit server to provide this service.

LOCAL - Perform the service locally.

  If the "object prefix" is omitted, the command will be executed locally.
  The services include:

LOGIN: This should be used in its timesharing sense, to create an identity
  ("job", "session", "access", "account") on the system.

CWD: Change Working Directory.  This is ugly, but more natural verbs like
  CONNECT and ATTACH are too imprecise.  CWD is the ARPAnet file transfer
  standard command to invoke this function.

DIRECTORY: Provide a list of the names, and possibly other attributes, of the
  files in the current working directory (or the specified directory).

SPACE: Tell how much space is available for storing files in the current
  working directory (or the specified directory).

DELETE: Delete the specified files.
ERASE:  This could be a synomym for DELETE, since its meaning is clear.

  (note, it doesn't seem wise to include UNDELETE or UNERASE in the standard
  list; most systems don't support such a function, and users' expectations
  should not be toyed with...)

COPY:   Make a new copy of the specified file with the specified name.

RENAME: Change the name of the specified file.

TYPE:   Display the contents of the specified file(s) at the terminal.

SUBMIT: Submit the specified file(s) for background (batch) processing.

PRINT:  Print the specified file(s) on a printer.

MOUNT:  Mount the specified tape, disk, or other removable storage medium.

WHO:    Show who is logged in (e.g. to a timesharing system), or give
        information about a specified user or network host.

MAIL:   Send electronic mail to the specified user(s).

MESSAGE: Send a terminal message (on a network or timesharing system).

HELP:   Give brief information about how to use KERMIT.

SET:    Set various parameters relating to debugging, transmission, file mode,
        and so forth.

SHOW:   Display settings of SET parameters.

STATISTICS: Give information about the performance of the most recent file
        transfer -- elapsed time, effective baud rate, various counts, etc.

HOST:   Pass the given command string to the specified (i.e. remote or local)
        host for execution in its own command language.

Additions?  Deletions?  Corrections?  Suggestions?  Complaints?  Naming things
is always the hardest part of any computing project, and usually provokes the
most lively debates...
-------
14-Oct-83 20:54:45-EDT,737;000000000000
Return-Path: <@CUCS20:OC.SITGO@CU20B>
Received: from CUCS20 by CU20B with DECnet; 14 Oct 83 20:54:42 EDT
Received: from CU20B by CUCS20 with DECnet; 14 Oct 83 20:55:31 EDT
Date: Fri 14 Oct 83 20:54:19-EDT
From: "Nick Bush" <OC.SITGO@CU20B>
Subject: Re: KRFC #7, Normal Form for File Names
To: cc.fdc@CUCS20
cc: Info-Kermit@CUCS20
In-Reply-To: Message from "Frank da Cruz <cc.fdc@CUCS20>" of Fri 14 Oct 83 19:25:46-EDT

This seems like a very good idea.  One problem with item #2, however,
is that according to KRFC #6, the attributes packet would not get
sent until after the file packet.  Therefore, two Kermits could not
know they could use image mode until after the file name was already
sent.

- Nick Bush
-------
14-Oct-83 21:14:25-EDT,1335;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 14 Oct 83 21:14:19 EDT
Received: from SIMTEL20.ARPA by COLUMBIA-20.ARPA with TCP; Fri 14 Oct 83 21:15:00-EDT
Date: 14 Oct 1983  19:11 MDT (Fri)
Message-ID: <[SIMTEL20].WANCHO.14-Oct-83 19:11:44>
From: Frank J. Wancho <WANCHO@SIMTEL20>
To:   INFO-KERMIT@COLUMBIA-20
Subject: KRFC #7, Normal Form for File Names
In-reply-to: Msg of 14 Oct 1983  17:17-MDT from Frank da Cruz <cc.fdc at COLUMBIA-20.ARPA>

What happens when the receiving end reparses the filename to fit it's
naming conventions?  For example, one would expect the CP/M end to
convert a name of the form n.m to its 8.3 limits, using the first 8 of
the n characters, and the first three of the m characters.

But then, what should it do if it receives a "different" filename n.m
where the first 8 of n and first 3 of m happen to match?  Do you
overwrite, or use some additional convention to bump the .3 part?  Do
you change the .3 part to a fixed name, like .BAK?  What if a third
file comes in?

As for the rest of the KRFC, it looks reasonable, except for the
"special characters" part.  It should be up to the receiving end to
determine if any of them should be ignored or considered significant,
and use whatever quoting mechanism is available.

--Frank
14-Oct-83 22:02:38-EDT,993;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 14 Oct 83 22:02:35 EDT
Date: Fri 14 Oct 83 22:02:48-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: KRFC #7, Normal Form for File Names
To: [e-mail], INFO-KERMIT@CUCS20
In-Reply-To: Message from "Frank J. Wancho <WANCHO@SIMTEL20>" of Fri 14 Oct 83 19:11:00-EDT

Good point about filename conflicts on the receiving end.  But this has to be
an implementation detail, beyond the scope of the protocol.  Certainly it's
desirable to avoid overwriting files one doesn't want to overwrite.  Systems
where that's a particular danger (ones like CP/M and TOPS-10, where filenames
are short and there is no automatic backup of versions or generations) tend
to have a filename conflict avoidance mechanism built in -- e.g. in both of
those implementations, it's the SET FILE-WARNING business (so that the user
also has the option to overwrite files if s/he wants to).

- Frank
-------
14-Oct-83 22:17:40-EDT,5654;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 14 Oct 83 22:17:31 EDT
Date: Fri 14 Oct 83 19:29:26-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Kermit versions status table
To: Info-Kermit@CUCS20

The following table is now available in KER:VERSIONS.DOC on COLUMBIA-20.
It lists, briefly, what KERMIT implementations are available or are being
worked on, and by whom, etc.  I'll try to keep it up to date.

Meanwhile, I talked with some of these people on the phone today.  I hope
to be getting tapes from several of them within a week or two, including
Stevens (VAX/VMS, TOPS-10, Apple II DOS, and maybe Pro-350), Cornell
(UCSD Pascal), and The SOURCE (PL/I for the PR1ME).  Some of these should
provide a good starting point for other implementations that have been long
sought after -- the PL/I version should be easily adaptable to various IBM
mainframes; the UCSD Pascal version should be widely portable (Cornell's
particular implementation is for the Terak, but was written with portability
in mind), the Pro-350 version should be adaptable to RSX-11M, etc.

Anyway, here it is.  If you have any corrections, additions, etc, please
let me know...

Known Kermit Versions, as of 14 Oct 83
--------------------------------------

Legend:

  Status:
    D   Done, no further development going on
    C   Continuing; already released, but a new release is in preparation
    P   Work in Progress on initial release
    G   Good intentions (they said they were going to, but no further word)

  Availability:
    A   Available from Columbia
    W   Columbia is waiting for it

  Level (a very rough indication):
    .   Basic (send & receive files, terminal emulation if micro)
    -   Sub-Basic (works, but missing some features, like error packets)
    +   Advanced (includes server functions &/or data compression, CRCs, ...)
    ?   Unknown

Machine     OS       Language        Status   Who

DEC-10      TOPS-10  MACRO-10/Bliss  C A +    Stevens
DEC-20      TOPS-20  MACRO-20        C A +    Columbia
DEC VAX     VMS      MACRO-32/Bliss  C A +    Stevens
DEC PDP-11  RSX/11   MACRO-11        P W +    Stevens (based on P/OS)
DEC PDP-11  RT-11    OMSI Pascal     D A -    Ontario/CU
DEC PDP-11  RT-11    MACRO-11        P W ?    Peter Moulton, Lincoln Labs/MIT
DEC PDP-11  RSTS/E   Basic+(2?)      G W ?    (many said they would...)
DEC Pro-3xx P/OS     MACRO-11/Bliss  P W +    Stevens
DEC Rainbow CP/M-86  Asm86           P W +    Bill Catchings, Columbia

IBM 370     VM/CMS   IBM assembler   C A +    Columbia
IBM 370     MVS/TSO  ?               G W ?    Arnie Berg, SASKCOMP
IBM 370     MUSIC    ?               G W ?    Ecole Polytechnique, Montreal
IBM 370     MTS      ?               G W ?    U of BC &/or U of Vancouver
IBM 370     GUTS     ?               G W ?    Info Resources Inc, Chicago
("370" means the whole 370 series, including 303x, 308x, 43xx, plus PCMs)

CDC Cyber   NOS      Fortran         D W ?    Jim Knutson, U Texas, Austin
Honeywell   MULTICS  PL/I            D W ?    Paul Amaranth, Oakland U, Mich.
UNIVAC 1100 EXEC     Assembler       D W .    Chuck Hutchins, U. of Wisc.
DG MV/8000  AOS      ?               G W ?    Gary Fostel, NCSU
PR1ME       PRIMOS   PL/I            D W +    Leslie Spira, The SOURCE
HP-1000     ?        Pascal?         G W ?    U of Tennessee, Knoxville
Xerox 1100  (InterLisp-D)            P W ?    Jon L White, Xerox-PARC

Various     MUMPS    MUMPS                    David Rossiter, Cornell U

Various     UNIX     C               C A -    Columbia, with contributions
  VAX         4.1bsd                           from Jim Guyton, Rand Corp,
  SUN         4.1Cbsd                          Bill Underwood, Ford Aerospace
  IBM 370     Amdahl UTS
  Others      V6, V7, Onyx, etc.

Various     UCSD P   Pascal          D W ?    Kate McGregor, Cornell U
  Terak                                       Kate McGregor, Cornell U
  HP-9826/9836                                Mike Gallaher, Rutgers U
  Corvus Concept                              David Todd, Wesleyan U
  Sage II & IV                                Gary Fostel, NCSU

IBM PC      PC DOS   MASM            C A .    Columbia
Zenith Z100 MS DOS   MASM            C A .    Added to IBMPC version by Stevens

Victor 9000 MS DOS   ?               G W ?    Ford Motor Company, Dearborn

Z80/8080    CP/M-80  8080 assembler  C A +    Columbia, w/other contributors:
  DEC VT180                                     Bernie Eiben, DEC
  DEC Rainbow (Z80 side)                        Bernie Eiben, DEC
  DECmate II (CP/M only)                        Someone at DEC
  Heath/Zenith-89                               Someone at DEC
  Heath/Zenith-100 (Z80 side)                   Nick Bush, Stevens
  Apple II (Z80 soft card)                      Scott Robinson, DEC
  TRS-80 II (CP/M only)                         Bruce Tanner, Cerritos College
  Osborne I                                     Chuck Bacon, NIH
  Intertec SuperBrain                           Columbia
  Vector Graphics                               Columbia
  Telcon Zorba                                  Nick Bush, Stevens
  Ohio Scientific                               Columbia
  "Generic" CP/M 2.2                            Bernie Eiben, DEC
  "Generic" CP/M 3.0                            Bruce Tanner, Cerritos College
(All these versions are built from a common source with conditional assembly)

Apple II    DOS      Cross           C A .    Stevens
Commodore 64         Cross?          G W ?    Columbia
-------
15-Oct-83 02:41:15-EDT,1405;000000000000
Return-Path: <@CUCS20:Grich%UCI.UCI@Rand-Relay>
Received: from CUCS20 by CU20B with DECnet; 15 Oct 83 02:41:10 EDT
Received: from rand-relay.ARPA by COLUMBIA-20.ARPA with TCP; Sat 15 Oct 83 02:41:55-EDT
Date: 14 Oct 83 22:21:50 PDT (Fri)
From: John Mangrich <grich.uci@Rand-Relay>
Return-Path: <Grich%UCI.UCI@Rand-Relay>
Subject: PC Kermit backspace/delete key
To: info-kermit.UCI@Rand-Relay, js5a%cmccta@Rand-Relay
Via:  UCI; 14 Oct 83 23:12-PDT

    First, the last version we got for the IBM PC had the backspace
    key (the one above the "return" key) send a control-H.  Previous
    CMU versions had this send a delete since TOPS-20 and VAX don't
    really use control-H very much. While I was tempted to change it
    back I did some checking and found that both IBM and UNIX systems
    liked ^H much better than DEL and since the combination of UNIX
    and IBM uses outnumber the TOPS/VMS users I figured we should
    consider have some sort of user settable option?  ...or perhaps
    an assembly parameter?  It is easy enough to change but I am
    afraid that the terminal emulation part of this may get out of
    hand if we all go our own ways.

Hmm...I use version 1.19 of PC Kermit, and I get a control-H when I press the
backspace key, but I get a real delete (ascii 127) if I do control-backspace
on the IBM keyboard.

    John Mangrich
    grich.uci@rand-relay
15-Oct-83 13:16:13-EDT,623;000000000000
Return-Path: <@CUCS20:DRF@SU-AI>
Received: from CUCS20 by CU20B with DECnet; 15 Oct 83 13:16:09 EDT
Received: from SU-AI.ARPA by COLUMBIA-20.ARPA with TCP; Sat 15 Oct 83 13:16:55-EDT
Date: 15 Oct 83  1015 PDT
From: David Fuchs <DRF@SU-AI>
Subject: Re: KRFC #7, Normal Form for File Names
To:   Info-Kermit@COLUMBIA-20

How about having an option for NOT stripping path names, so KERMIT could
potentially send entire sub-directory trees from Unix to Unix systems?
I'd also be more comfortable if the `image-mode file name' option were
unbundled from the `image-mode data transfer' option.
      -David Fuchs

17-Oct-83 18:44:18-EDT,620;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 17 Oct 83 18:44:12 EDT
Date: Mon 17 Oct 83 18:46:23-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: KRFC #7, Normal Form for File Names
To: [e-mail], Info-Kermit@CUCS20
In-Reply-To: Message from "David Fuchs <DRF@SU-AI>" of Sat 15 Oct 83 10:15:00-EDT

Makes sense.  Let's say that BY DEFAULT, it strips pathnames.  Also agreed
about the unbundling, especially as someone else pointed out, you don't
necessarily know know the file is in image mode until after the file name
has already been sent.  - Frank
-------
18-Oct-83 11:51:06-EDT,1400;000000000000
Return-Path: <@CUCS20:SY.FDC@CU20B>
Received: from CUCS20 by CU20B with DECnet; 18 Oct 83 11:50:53 EDT
Received: from CU20B by CUCS20 with DECnet; 18 Oct 83 11:50:27 EDT
Date: Tue 18 Oct 83 11:50:08-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: [Bob Cattani <CATTANI@CUCS20>: Next Kermit is ready]
To: Info-Kermit@CUCS20

Announcing yet another release of UNIX Kermit.  The major addition here is
error packet processing; this brings UNIX Kermit up to the basic level of
all other Kermits.  All UNIX sites should convert to this latest version.
Please report any problems directly to Bob (CATTANI@COLUMBIA-20) and me
(CC.FDC@COLUMBIA-20).  - Frank
                ---------------

Date: Mon 17 Oct 83 15:52:17-EDT
From: Bob Cattani <CATTANI@CUCS20>
Subject: Next Kermit is ready

Included fixes from Alan Crosswell (CUCCA) for IBM_UTS:
- Changed MYEOL character from \n to \r.
- Change char to int in bufill so getc would return -1 on
  EOF instead of 255 (-1 truncated to 8 bits)
- Added read() in rpack to eat the EOL character
- Added fflush() call in printmsg to force the output
  NOTE: The last three changes are not conditionally compiled
  since they should work equally well on any system.

Changed Berkeley 4.x conditional compilation flag from UNIX4X to UCB4X.
Added support for error packets and cleaned up the printing routines.

-Bob
-------
-------
18-Oct-83 12:58:40-EDT,1319;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 18 Oct 83 12:58:33 EDT
Date: Tue 18 Oct 83 12:58:02-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: FORTRAN-based KERMIT available
To: Info-Kermit@CUCS20

Announcing a major new KERMIT release, written in FORTRAN for the CDC Cyber 170
by Jim Knutson of the Computation Center of the University of Texas at Austin
(knutson@utexas-11, or knutson@UT-NGP).  Although it won't be able to run as-is
on many machines, it should be adaptable to a wide range of systems for which
KERMIT is presently unavailable.

The source for the Cyber Version of Kermit is on COLUMBIA-20 in the file
KER:170KERMIT.FOR, available via anonymous FTP.  The installation information
is in the Fortran source code.  It will need mods for any Cyber site that tries
to run it since there are probably no two Cyber sites anywhere that do ASCII
I/O the same way.  There is also an nroff source for additions to the Kermit
User's Guide in KER:170KERMIT.NR.

The Cyber-170 version of KERMIT has been tested with KERMIT-20 and UNIX Kermit
and runs with either.  It is rather slow (500-900 effective baud on a 2400 baud
line).  It has also been tested with Kermit-86 on a Corona (IBM-PC clone),
IBM-PC and a Z100 and CPMKermit on a Z100.
-------
20-Oct-83 23:48:45-EDT,3641;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 20 Oct 83 23:48:38 EDT
Date: Thu 20 Oct 83 23:48:16-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New Release of CP/M Kermit for Testing
To: Info-Kermit@CUCS20

Version 3.5 of KERMIT-80 for CP/M is available for testing.  Many new
features have been added, bugs fixed, etc.  A list follows.  Users of
CP/M systems on this list are urged to get copies of the new version for
their systems, try it out, and let me know if it works.  When 15 different
systems are being supported from one source file by hairy conditional
assembly parameters (IF this AND that BUT NOT those...ENDIF), it's never
easy to change things, especially when you don't have an example of each
system to test the new stuff on.  The VT180 and DECmate II support have
been tested so far...  If I can get word, one way or the other, on most of
the systems we're supposed to support, I'll announce the new version to
Info-CPM, Info-Micros, etc...

KER:CPMBASE.M80 is now the current, working source file for KERMIT-80.  All the
KER:CPM*.HEX files are generated from it.  See KER:CPMKERMIT.DOC for a
discussion of the status of this and the other source files.

The old .HEX files have been renamed to *.OHX.

All these files are available via anonymous FTP from host COLUMBIA-20, in the
area KER: (or, PS:<KERMIT>).

This file briefly lists the changes and new features of KERMIT-80 version 3.5,
which is generated for each system from CPMBASE.M80.

* Kaypro II support.

* SET FILE-MODE BINARY or ASCII or DEFAULT (DEFAULT is currently BINARY).
  This replaces SET CPM-CREATED FILE, and it works somewhat differently
  (better -- no longer get "ever-growing files").  SET FILE-WARNING changed
  to SET WARNING to reduce typing.

* Session logging bugs fixed, but it's still not perfect.

* Bugs with files of length n*32K fixed.

* Performance improvements.

* SET PORT (VT180 only) allows switching between communication ports.
  Also, VT180 can now transmit a BREAK (presently none of the other CP/M
  implementations can do this; anyone want to add this support for their
  micro?).

* 2 & 3 character block checks (longer checksum, and CRC, respectively).
  Only useful with other KERMITs that support this option.

* ^X/^Z interrupting of file transmission:

  ^X interrupts the current file (of a wildcard group), skipping to next
  ^Z interrupts the whole group

  Works for sending.  For receiving, works only if the other KERMIT knows
  about this new feature.

* Fixes for Osborne 1 support installed but not tested.

* Improved terminal emulation.  Now interrupt characters typed during
  long typeouts from the host should get through.  Also, it's now possible
  to transmit a NUL.  Also, the broken local echoing should now be fixed.

* Wildcard file stepping improved to handle any number of files.  Previously,
  16 was the maximum.  However, the new method is slower (there is still room
  for improvements, which will be installed as time permits).

* Local DIRECTORY and ERASE commands.

* Disk switching via SET DEFAULT DISK.  "Kermit-80>" prompt now includes the
  default disk, as in "Kermit-80 B:>".

* "GET" is a synonym for "RECEIVE filespec", for sending a request to a server.
  More in line with "standard" nomenclature.

* Various cosmetic improvements and minor bugs fixed.

Thanks mostly to Bernie Eiben of DEC (Marlboro, Mass), Nick Bush of Stevens
Institute of Technology (Hoboken NJ), and Bruce Tanner of Cerritos College
(Norwalk, CA) for these improvements.
-------
21-Oct-83 00:02:26-EDT,1148;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 21 Oct 83 00:02:22 EDT
Date: Thu 20 Oct 83 23:56:08-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New KERMIT Protocol Manual
To: Info-Kermit@CUCS20

A new, much expanded fourth edition of the KERMIT Protocol Manual is now
available via anonymous FTP from host COLUMBIA-20 as KER:PROTO.*.  There
are 4 files:

PROTO.MSS - The SCRIBE (TM UNILOGIC, all rights reserved, etc) source file.
PROTO.DOC - Suitable for reading on a computer terminal.
PROTO.LPT - Suitable for printing on a DEC line printer (underline, overstrike)
PROTO.FOR - Like .LPT, but for printers that want carriage control in column 1.

The new protocol manual supersedes the old one -- there are several minor
incompatibilities (hopefully not affecting any features that anyone has
implemented so far).  And it supersedes KRFC's 1-8, which have been incorporated
into it with modifications to reflect suggestions I got from members of the
mailing list.

I hope it's a better document to work from.  Comments, complaints, suggestions,
flames -- all are welcome.
-------
21-Oct-83 00:16:15-EDT,1821;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 21 Oct 83 00:16:10 EDT
Date: Fri 21 Oct 83 00:11:47-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New TTLINK sends BREAK(?)
To: Info-Kermit@CUCS20, [e-mail]

Bill Schilit has added code to TTLINK, the "poor person's TELNET" for making
virtual terminal connections from a DEC-20 to another system over an assigned
TTY line, for sending a BREAK signal.  (TTLINK is run by KERMIT-20 to
accomplish the CONNECT command).  We've tried it with our own IBM systems,
which have many uses for BREAK and expect users to type it all the time, and it
seems to work.  It's a horrible hack, however; since TOPS-20 provides no way to
send a *real* BREAK, so there's no telling if it will work with all systems.
Typical symptoms of it not working would be no BREAK detected by the intended
recipient, too many BREAKs detected, or (worst of all) line hangs up or gets
set to the wrong speed...  Yes, you guessed how it works: it drops the speed
down low, sends a bunch of nulls which result in a framing error since the
speed is wrong (hence BREAK, which is defined roughly as NULs received with a
framing error), and brings the speed back up again.  The problem, as TOPS-20
afficionados know, is that TOPS-20 didn't know what your speed was in the first
place, so restoring it after sending the BREAK can be tricky.  Also, the number
of NULs to send to simulate a BREAK may vary according to the communications
equipment that's being used, and the actual baud rate.  These things (the speed
and the number of nulls) are controlled by new, cryptic, but user-friendly
switches to TTLINK.

If you want to try it, it's in KER:NTTLINK.* at host COLUMBIA-20, accessible by
anonymous FTP.  Comments welcome.
-------
25-Oct-83 10:27:32-EDT,539;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 25 Oct 83 10:27:28 EDT
Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Tue 25 Oct 83 10:26:15-EDT
Date:  25 October 1983 10:22 edt
From:  JPAnderson.DODCSC at MIT-MULTICS
Subject:  kermit on RSTS/E
To:  info-kermit at COLUMBIA-20

Does a version of KERMIT exist to run on 11's (PDP's of course) running
RSTS/e? If not, does any one know of any means of xfering files between
two machines?  thanks in advance Jay
25-Oct-83 16:46:40-EDT,943;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 25 Oct 83 16:46:07 EDT
Date: Tue 25 Oct 83 16:44:07-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: kermit on RSTS/E
To: [e-mail], info-kermit@CUCS20
In-Reply-To: Message from "JPAnderson.DODCSC at MIT-MULTICS" of Tue 25 Oct 83 10:22:00-EDT

There's not yet a KERMIT for RSTS/E (any volunteers?).  Unless there's an
implementation of MODEM, your best bet would probably be to write a simple
terminal emulator that can log to a file, for unguarded capture of remote
files.  It's probably just as easy, however, to write KERMIT itself, working
from the Protocol Manual and one of the existing implementations (in C or
Pascal, for instance).  All these are available on host Columbia-20 in the
area KER: via anonymous FTP.  Look at KER:00README.TXT for a guide to the
files in the Kermit distribution area.
-------
29-Oct-83 17:03:35-EDT,424;000000000000
Return-Path: <@CUCS20:CCVAX.trest@Nosc>
Received: from CUCS20 by CU20B with DECnet; 29 Oct 83 17:03:26 EDT
Received: from nosc-cc by COLUMBIA-20.ARPA with TCP; Fri 28 Oct 83 23:11:09-EDT
Date: 28 Oct 1983 20:01:21-PDT
From: CCVAX.trest@Nosc
To: INFO-KERMIT@COLUMBIA-20

Please Add Me to your List.  THANKS!!

    trest@nosc
    trest@nosc-tecr

    Mike Trest
    4065 Hancock Street
    San Diego, Ca 92110
    [phone]
 2-Nov-83 19:01:21-EST,1363;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 2 Nov 83 19:00:43 EST
Date: Wed 2 Nov 83 18:26:52-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Kermit for UCSD p-System
To: Info-Kermit@CUCS20
cc: KMM%CORNELLA@CU20B

This is to announce the arrival of Kermit for the UCSD p-System, written
by Kate MacGregor of Cornell University Computing Services.  The program
is written modularly, to allow it to be brought up on any machine under
the p-System by supplying some machine-dependent assembly language
procedures.  The implementation we have now is for the Terak, an LSI-11/2
based machine.  The relevent source files are in KER:UC*.* at host
COLUMBIA-20, accessible via anonymous FTP.  First read UCSD.HLP, which
explains how the files were renamed to fit in the KERMIT distribution
area.  UCKERM.HLP contains user documentation and installation instructions.

Work is in progress at Cornell on an implementation for the IBM PC p-System.

If anyone wants to bring up Kermit on some new machine, not under the
p-System, but which has Pascal, this might be a good base from which to
start.  I don't know how close UCSD Pascal is to ISO Pascal, but if they
are not fatally incompatible, it may be possible to adapt this version to
any system by merely filling in the system-dependent routines.
-------
 3-Nov-83 18:58:28-EST,1069;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 3 Nov 83 18:58:22 EST
Date: Thu 3 Nov 83 18:57:23-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New(er) Protocol Manual
To: Info-Kermit@CUCS20

A slightly revised version of the KERMIT protocol manual has been placed in
the KERMIT distribution area as KER:PROTO.* at host COLUMBIA-20 (accessible
via anonymous FTP, as usual).  It corrects some typos (a few of them serious,
like a missing "not", the checksum formula was in octal when all numbers were
supposed to be in decimal), and some minor improvements were made, mostly
cosmetic.  All truncated lines in the non-typeset document types (.DOC,.LPT,
.FOR) were fixed to fit.  A bit was added in the "how to write a KERMIT
program" section about version/edit numbers, and a plea to keep all source
and documentation lines to 80 characters or less, not just so they'll look
nice on a screen, but also because we have to ship these things over
card-image communication links.

Comments welcome.  - Frank
-------
 3-Nov-83 19:44:17-EST,636;000000000000
Received: from CUCS20 by CU20B with DECnet; 3 Nov 83 19:44:14 EST
Received: from LLL-MFE by COLUMBIA-20.ARPA with TCP; Thu 3 Nov 83 19:43:07-EST
Date: Thu, 3 Nov 83 16:42 PST
From: "Jones Dan%LLL"@LLL-MFE.ARPA
Subject: HP9816 Kermit query.
To: [e-mail]



I am looking for a version of Kermit that will run on HP9816 computers. It
seems that I saw something go by about this a while back. Can someone point
me to someone on the net that has sources,documentation, or information about
this version of kermit.

                                Thanks,
                                        Dan Jones
 4-Nov-83 10:03:46-EST,868;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 4 Nov 83 10:03:38 EST
Date: Fri 4 Nov 83 10:02:15-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: HP9816 Kermit query.
To: "Jones Dan%LLL"@LLL-MFE.ARPA, info-kermit@CUCS20
In-Reply-To: Message from ""Jones Dan%LLL"@LLL-MFE.ARPA" of Thu 3 Nov 83 19:43:17-EST

I'm not sure what an HP9816 is.  Is it like a 9826 or 9836?  If so, a guy named
Ray Adams at Oak Ridge National Lab said he would be doing Kermit for them.
I haven't received any progress reports, however, and my notes don't indicate
what the operating system was.  Mike Gallaher at Rutgers (GALLAHER@RUTGERS)
was also looking to get KERMIT going on these machines under UCSD Pascal, based
on the Cornell version just announced.  If I hear any news, I'll post it to the
Info-Kermit list.  - Frank
-------
 7-Nov-83 02:23:20-EST,2126;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 7 Nov 83 02:23:17 EST
Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Mon 7 Nov 83 01:53:18-EST
Date: 7 Nov 83 01:49:44 EST
From: [e-mail]
Subject: HP9816/9826/9836 kermit available
To: [e-mail]

Well, it took a while, but I now have the HP9836 Kermit working well
enough so I'd trust it at other sites.  This version is intended to
work only on the HP9836, so it is heavily dependent on the HP pascal
extensions, mostly the module facility.  It probably will not be easy
to port to non-HP machines.  The actual Kermit protocol routines are
from the RT-11 Pascal version from Ontario/CU.  The user interface has
been completely rewritten - one of our requirements was that it be
reasonably idiot-proof.

The current version is minimal, and at this point is really a
prototype.  It will only transfer text files, only one file at a time,
and the error handling is not the greatest, but it works for
everything it's supposed to do.  I plan to be adding a lot to this
implementation quite soon, to improve the user command interface,
improve error handling, add login packets, and maybe binary transfers.

The important features (marked by +) and misfeatures (marked by -) of
the current version are

    - errors not handled gracefully
    - only transfers one file at a time
    - does not handle wild cards
    - only transfers text files
    + continuous status display during file transfers
    + can talk to a server
    - does not handle timeouts
    - only acts as local Kermit
    + reasonably friendly command interface, modeled after TOPS-20
      COMND facility.

I have made the sources and documentation available on RUTGERS.ARPA in
<Gallaher.Kermit>KRM*.TEXT. There are six source files, which contain
about a dozen modules altogether.  They use only the recommended
library routines and such that HP distributes.  The file KRMDOC.TEXT
summarizes the (mis)features and gives details on how to run this
Kermit.


Mike Gallaher
[e-mail]
-------
 7-Nov-83 12:22:26-EST,574;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 7 Nov 83 12:22:21 EST
Date: Mon 7 Nov 83 12:21:15-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: HP9816/9826/9836 Kermit
To: Info-Kermit@CUCS20

The version of UCSD Pascal Kermit which Mike Gallaher announced from Rutgers
for the HP98xx series is on line at Columbia-20 as KER:HP9*.*.  The file
KER:HP9KERMIT.HLP lists the other files, the renaming conventions, and so
forth.  The file KER:HP9KERMIT.DOC is Mike's documentation for this
implementation of KERMIT.
-------
 7-Nov-83 13:51:56-EST,1099;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 7 Nov 83 13:51:31 EST
Date: Mon 7 Nov 83 13:50:21-EST
From: "Nick Bush" <G.BUSH@CUCS20>
Subject: New Kermit-10 and VMS Kermit available
To: INFO-KERMIT@CUCS20




There are new versions of Kermit-10 and VMS Kermit available
on Columbia-20 KER:.  Kermit-10 files are KER:K10*.*, plus
KER:VMSMSG.BLI and KER:VMSTT.BLI (common sources with VMS
Kermit).  VMS Kermit files are KER:VMS*.* plus
KER:K10VMS.MEM.  These versions include a substantial number
of enhancements and bug fixes.  Both Kermits are now full
servers, can run in both local and remote modes, and can
send commands to servers.  Both Kermits now support
eigth-bit quoting, repeat compression, 2 character checksums
and 3 character CRC-CCITTs.  Both also support aborting (or
skipping) files during transfers by typing control-X (to
skip one file) or control-Z (to skip the rest of the group),
as well as supporting this functionality in the other
Kermit.  For more information on changes see KER:K10VMS.MEM
on Columbia-20.
-------
 7-Nov-83 14:10:55-EST,1429;000000000000
Return-Path: <@CUCS20:OC.WBC3@CU20B>
Received: from CUCS20 by CU20B with DECnet; 7 Nov 83 14:10:48 EST
Received: from CU20B by CUCS20 with DECnet; 7 Nov 83 14:09:40 EST
Date: Mon 7 Nov 83 14:09:58-EST
From: Bill Catchings <OC.WBC3@CU20B>
Subject: Kermit for the Rainbow
To: info-kermit@CUCS20

I've been meaning to send this announcement for about two weeks.
Sorry it took so long in coming.  There is now a preliminary version
of Kermit for the Rainbow running CP/M.  It has the following
restrictions:

 Runs under CP/M-86/80 version 1 only, not tested under version 2.
. Does not run under MS DOS.
. Terminal emulation is sluggish.  Barely keeps up at 4800 baud.
. No wildcard SEND yet.
. Some server commands are supported, but not GET (yet).
. There is code to keep DTR up, but it has not been tested.
. There may be rough edges and bugs here and there.

You should be able to download the program using the old KERMIT on the
Z80 side.  The program is stored in the distribution area as RB*.*.
RBKERMIT.CMD is the executable program.  RBKERMIT.H86 is the hex file
(you can use GENCMD on the Rainbow to build the .CMD file from this).
RB*.A86 are the source modules, written in Digital Research CP/M-88
assembler and assembled on the Rainbow.

Please send any comments or complaints.  I will put in a few more
hours to correct the major shortcomings and bugs.

                    -Bill Catchings

-------
 8-Nov-83 10:27:52-EST,4037;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 8 Nov 83 10:27:45 EST
Date: Tue 8 Nov 83 10:25:58-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: KERMIT for CP/M-80
To: [e-mail], [e-mail]
cc: Info-Kermit@CUCS20

A few months ago, I announced the file transfer protocol KERMIT to the
Info-CPM and Info-Micro lists.  I never got very much feedback about it,
though I have seen it mentioned now and then on both lists.  For those of
you who missed the announcement, the KERMIT distribution area is on host
COLUMBIA-20, in the area KER:, accessible with anonymous FTP.  It's a big
area (but nothing to rival the size of the CPM archives, of course), so
if you're interested, you should look first at the file KER:00README.TXT,
which lists what versions are available and describes the naming conventions.
KERMIT is available for a wide variety of micros and mainframes.

KERMIT for CP/M provides terminal emulation and file transfer.  Versions for
about 15 different systems are built from a common source file, written in
standard DR ASM for the 8080, using conditional compilation, either on the
micro itself or on a DEC-10 or -20 using the cross assembler MAC80 (which is
itself available in the KERMIT area).

A few weeks ago, a new version of CP/M-80 KERMIT, v3.5, was announced to the
Info-Kermit list, with a plea that users of the various systems supported by
KERMIT-80 (as it's called) report back as to whether the new version worked on
their systems.  I had hoped to get the bugs ironed out before announcing it to
the world at large.  Unfortunately, I got very few reports.  Since we lack
examples of most of these systems at Columbia to try the new KERMIT-80 out on,
I'm announcing it now anyway.  If you have any of the systems listed below,
please try to get KERMIT for your machine, try it out, and:

 (a) let me know if it works;
 (b) if it doesn't, describe the symptoms;
 (c) if you can provide a fix, please do so (you'll be given full credit).

Here are the systems:

System:              Filename:            Status:

DEC VT-180           KER:CPMROBIN.HEX     Tested, works up to 4800 baud
DEC Rainbow-100      KER:CPMRAINBO.HEX    Tested, works up to 1800 baud
DEC DECmate II       KER:CPMDMII.HEX      Tested, works up to 9600 baud
Heath/Zenith 89      KER:CPMHEATH.HEX     Not tested
Heath/Zenith 100     KER:CPMZ100.HEX      Not tested
Apple II*            KER:CPMAPPLE.HEX     Not tested
TRS-80 II**          KER:CPMTRS80.HEX     Not tested
Osborne 1***         KER:CPMOSBORN.HEX    Tested, doesn't seem to work at all
Intertec Superbrain  KER:CPMBRAIN.HEX     Not tested
Kaypro II            KER:CPMKAYPRO.HEX    Tested, mostly works OK.
Telcon Zorba         KER:CPMTELCON.HEX    Not tested
Vector Graphics      KER:CPMVECTOR.HEX    Not tested
Ohio Scientific      KER:CPMOSI.HEX       Not tested
Generic CP/M 2.x     KER:CPMGENERI.HEX    Tested OK on Rainbow, DECmate, VT180
Generic CP/M 3.0     KER:CPMPLUS.HEX      Not tested

  *With Z80 soft card, Hayes micromodem II
 **With CP/M 2.25
***Can you fix it?

You can download the .HEX file with MODEM, or your old version of KERMIT,
or any other technique that works, and then load it using the CP/M LOAD
command, to produce a runnable .COM file.

The generic versions are supposed to run on any CP/M-80 system, since they
don't use only CP/M calls for device manipulation.  The 2.x generic version
depends on the system having fully implemented the "option" IOBYTE business,
and the user setting the values of the IOBYTE correctly and re-building.  The
3.0 generic version should run as-is on any CP/M 3.0 system; it has been
reported to work (in an earlier version of KERMIT-80) on the Osborne Executive
and the Micro Mate.

The source for all these versions is in KER:CPMBASE.M80.  There's also a file
KER:CPMKERMIT.DOC which explains the situation in greater detail.

- Frank da Cruz, Columbia University
-------
 9-Nov-83 11:05:26-EST,509;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 9 Nov 83 11:05:19 EST
Date: Wed 9 Nov 83 11:03:17-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: TAC support
To: [e-mail], INFO-KERMIT@CUCS20
In-Reply-To: Message from "Billy <BRACKENRIDGE@USC-ISIB>" of Thu 1 Sep 83 19:03:00-EDT

It should be in the next release of KERMIT-20.  The only thing I have to go on
is what's in the DEC-20 MODEM program; I have no way to test it.  - Frank
-------
 9-Nov-83 16:25:37-EST,800;000000000000
Return-Path: <@CUCS20:INFO-IBMPC@USC-ISIB>
Received: from CUCS20 by CU20B with DECnet; 9 Nov 83 16:24:39 EST
Received: from USC-ISIB.ARPA by COLUMBIA-20.ARPA with TCP; Wed 9 Nov 83 15:38:58-EST
Return-Path: <gjg@cmu-cs-cad>
Received: FROM CMU-CS-CAD BY USC-ISIB.ARPA WITH TCP ; 9 Nov 83 11:50:21 PST
Date: 9 Nov 1983 14:40:16-EST
From: Greg.Glass@CMU-CS-CAD
To: info-ibmpc@usc-isib
Subject: kermit and direct connect modem
Remailed-Date:  9 Nov 1983 1237-PST
Remailed-From: Dick Gillmann <Info-IBMPC@USC-ISIB>
Remailed-To: info-kermit@COLUMBIA-20

Has anyone modified kermit to work with one of the direct connect modems
that plug into the pc bus?  What modem?  Also has anyone used the new modem
that Qubie(?) is selling for about $290 for 1200 baud? (the one with a z8)
                        Greg
 9-Nov-83 17:09:32-EST,735;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 9 Nov 83 17:09:16 EST
Date: Wed 9 Nov 83 17:07:41-EST
From: Daphne Tzoar <CC.DAPHNE@CUCS20>
Subject: Re: kermit and direct connect modem
To: info-kermit@CUCS20
cc: [e-mail]

 I know of two people using Kermit with the Hayes Smartmodem.  One
 uses the plug in board modem, and one uses the external modem.  As
 far as I know, neither has problems.  The only restriction that I know
 of is that you can send the number to dial, but you can't pick a
 number from a stored list of numbers.  They issue the 'connect' command
 and then type in data needed by the modem.  For more details, send me
 mail.
/daphne
-------
10-Nov-83 17:06:07-EST,825;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 10 Nov 83 17:05:59 EST
Date: Thu 10 Nov 83 17:02:54-EST
From: Daphne Tzoar <CC.DAPHNE@CUCS20>
Subject: Filename Bug with DOS
To: [e-mail], info-kermit@CUCS20

I just came across a strange problem.  I had a file on our DEC-20,
LOGIN&.CMD, which is stored as LOGIN^V&.CMD -- that is, with a
Control-V before the special character.  I tried to send it to the
IBM PC using Kermit, which uses the DOS function call (int 21H) to
create a file.  DOS complained with the error DISK FULL.  When I
renamed the file to LOGIN.CMD it worked OK.  It seems, therefore,
that the disk was not full but rather there is a bug in DOS if
there is a non-standard character in the filename.  Has anyone
seen this before?
-------
14-Nov-83 19:25:28-EST,466;000000000000
Received: from CUCS20 by CU20B with DECnet; 14 Nov 83 19:25:20 EST
Received: from LLL-MFE by COLUMBIA-20.ARPA with TCP; Mon 14 Nov 83 16:13:27-EST
Date: Mon, 14 Nov 83 13:11 PST
From: "Jones Dan%LLL"@LLL-MFE.ARPA
Subject: Rsx-11/M kermit
To: [e-mail]

Is there a version of kermit for RSX-11/M available yet? I noticed that Frank
mentioned a version forthcoming that was written in macro-11.

                                Dan Jones
14-Nov-83 19:57:08-EST,754;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 14 Nov 83 19:57:01 EST
Date: Mon 14 Nov 83 19:55:42-EST
From: Nick Bush <G.BUSH@CUCS20>
Subject: Re: Rsx-11/M kermit
To: "Jones Dan%LLL"@LLL-MFE.ARPA
cc: info-kermit@CUCS20
In-Reply-To: Message from ""Jones Dan%LLL"@LLL-MFE.ARPA" of Mon 14 Nov 83 19:25:36-EST

The version of Kermit that Frank mentioned is actually a version that
is being written (at Stevens Institute of Technology) to run on the
DEC Pro-3xx systems under P/OS.  Since P/OS is 99% RSX-11M+, we
fell it should not be very difficult to make it run under normal
RSX-11M.  Note however, that there may be some unforeseen problems
since none of us are RSX-11M people.

- Nick Bush
-------
17-Nov-83 10:26:12-EST,3618;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 17 Nov 83 10:26:04 EST
Date: Thu 17 Nov 83 10:24:01-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New release of KERMIT-20
To: Info-Kermit@CUCS20

It's not all you'd ever want, but it's better than before...

KERMIT-20 Version 3B(122), differences from version 3A(66)
----------------------------------------------------------

MAJOR DIFFERENCES:

1. File i/o completely rewritten to prepare for future addition of new
   server commands.

2. DEFINE command added for definition of SET macros, for instance:

     DEFINE IBM (to be) PARITY MARK, DUPLEX HALF, HANDSHAKE XON

   SHOW MACROS shows the current macro definitions.

3. TAKE command to allow commands to be taken from a file, with nesting.

4. Automatic TAKE of KERMIT.INI upon startup.  KERMIT.INI can contain
   DEFINE commands for the various systems you would be communicating with.

5. Interruption of file transfer in both local and remote mode (KRFC #1)

   In local mode, typing ^X interrupts the current file and skips to the next,
   typing ^Y skips the rest of the batch.  These always work when sending
   files (except that the receiver may still keep the partial transmitted
   file, and work for receiving files only if the sender understands the
   interrupt request.

   In remote mode, KERMIT-20 responds to interrupt requests.

6. Separate remote and local mode top-level command tables.  Since most users
   of KERMIT-20 use it only in remote mode, they will no longer be confused by
   commands like "FINISH" and "BYE".

7. ITS binary files are now handled (KRFC #3).

8. Help text for SET command broken up, so you can say "help set escape", etc.


MINOR IMPROVEMENTS AND CHANGES:

 In local mode, ^A may be typed for a report on the file transfer in progress.
. Server operations may now be recorded in the debugging log.
. Don't parse for initial filespec in SEND if source file not wild.
. SET ABORTED-FILE renamed to SET INCOMPLETE.
. Minor improvements to statistics display.
. Allow ^C to interrupt a stuck BYE or FINISH command.
. Server accepts "I" packets (KRFC #1).
. SET HANDSHAKE allows specification of line turnaround character.


BUG FIXES:

 Mod 64 packet number compares fixed.
. NAK bad packet immediately, don't wait for timeout.
. Various bugs fixed relating to ^C trap, exiting and continuing, etc.
. Proceed gracefully after file i/o errors.
. Correctly assess the file byte size when sending in server mode.
. Release TTY and file JFNs in some places where they weren't before.
. Don't truncate error message in error packet prematurely.


WHAT'S NEXT:

Future releases of KERMIT-20, which should be coming along within a month
or two, will have the following features:

 Transaction logging.

 Support for 8th-bit prefixing, to allow passing 8-bit binary data through
  a 7-bit communications link.

 Repeat count processing to allow compression of repeated characters.

 Support for 2-character checksums and 16-bit CRCs.

 Additional server functions, particularly for file and job management.

 Some file attribute support.

 ARPANET TAC binary mode negotiation.

The new release is available via anonymous FTP from host COLUMBIA-20 in the
files KER:20KERMIT.EXE and KER:20KERMIT.MAC.  It has been tested in a variety
of environments with files of various types and sizes, but our quality control
department is not infallible.  If you discover any bugs, or have any comments,
please report them to me.

- Frank
-------
18-Nov-83 12:46:34-EST,964;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 18 Nov 83 12:46:24 EST
Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Fri 18 Nov 83 12:43:02-EST
Date: Fri 18 Nov 83 09:40:08-PST
From: Ted Markowitz <[e-mail]>
Subject: VT100 emulation for the PC/XT
To: [e-mail]

Not having looked at the code in detail... why can't Kermit support
VT100 emulation rather than just VT52? I just received a PC, so forgive
any obvious lack of knowledge, but I have seen other emulators for
VT100 compatibility.

Also, I've had a strange situation transferring file to my XT. I
was using TOPS-20 Kermit to send a 60-page file to the XT's hard
disk. Everything went smoothly, until I checked the output file.
It had 0 characters in it! There was no problem with files of the
same name, available space on the disk (I tried it on a new diskette
also), etc. Any ideas?

--ted
-------
18-Nov-83 15:39:15-EST,778;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 18 Nov 83 15:38:45 EST
Date: Fri 18 Nov 83 15:36:12-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: VT100 emulation for the PC/XT
To: [e-mail], info-kermit@CUCS20
In-Reply-To: Message from "Ted Markowitz <[e-mail]>" of Fri 18 Nov 83 12:44:05-EST

Full VT100 emulation is quite a big deal, and no one has written the
prodigious amount of code required who is willing to give it away.  You'll
notice there are several VT100 emulation packages for the PC on the commercial
market.

As to your problem with the empty file on the hard disk, contact Daphne directly
with the details; I'm sure she'll be able to figure out what went wrong.

- Frank
-------
23-Nov-83 01:54:32-EST,1460;000000000000
Return-Path: <@CUCS20:DIAMANT@CWRU20>
Received: from CUCS20 by CU20B with DECnet; 23 Nov 83 01:54:24 EST
Received: from CWRU20 by CUCS20 with DECnet; 23 Nov 83 01:56:57 EST
Date: Wed 23 Nov 83 01:54:40-EST
From: John Diamant <DIAMANT@CWRU20>
Subject: Transfers between IBM PC and UNIX
To: info-kermit@CUCS20

I have been trying to get kermit to run on our VAX 11/780 (running
4.1BSD), for file transfers to my IBM PC.  We currently have a version
(about 6 months old) which receives properly, but hangs when I try to
send files (CR's don't help).  This happens before a single packet is
sucessfully sent.  In an attempt to fix that, I copied kermit.c from
the columbia-20 archives in the last few days.  I now have a version
which sends and receives, but when I am receiving a file, it hangs
when it gets to the end of the file.  I have tried running this with
Ricekermit as well (also newest version on columbia-20).  The version
I am running on my IBM is 1.3A (again newest version not including the
one currently being tested).  Is there anything special I have to do
when I compile these? Has anybody else run across similar problems?
By the way, I tried the file transfers from an apple to the vax as
well, and the VAX acted the same in all cases, so I doubt it is the
IBM version causing the problem.


            Thanks,

                John Diamant
                DIAMANT%CWRU20@COLUMBIA-20 (ARPA)
            or    diamant.Case@Rand-Relay    (Also ARPA)
-------
23-Nov-83 04:33:21-EST,903;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 23 Nov 83 04:33:18 EST
Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Wed 23 Nov 83 04:35:49-EST
Date: Wed 23 Nov 83 01:21:43-PST
From: Carl Fussell <[e-mail]>
Subject: kermit-11
To: [e-mail]
Address:  Santa Clara University


We have a number of DEC LSI-11/03's  and 11/23's running RT11 (V.4)
that we would like to run kermit on.  I have obtained a couple
different versions of kermit for 11's but neither work.  Making them
work appears to be more than a 10-15 miniute repair job so before
I spend a large amount of time working on them,  I was hoping to
perhaps find someone out there who already has a version running
under similar conditions.   If you do, I would really appreciate
hearing from you....

                Thanx....
                    Carl
-------
23-Nov-83 04:45:29-EST,1446;000000000000
Return-Path: <@CUCS20:ELWELL@CWRU20>
Received: from CUCS20 by CU20B with DECnet; 23 Nov 83 04:45:25 EST
Delivery-Notice: While sending this message to CU20B, the
 CUCS20 mailer was obliged to send this message in 50-byte
 individually Pushed segments because normal TCP stream transmission
 timed out.  This probably indicates a problem with the receiving TCP
 or SMTP server.  See your site's software support if you have any questions.
Received: from CWRU20 by CUCS20 with DECnet; 23 Nov 83 04:35:52 EST
Date: Wed 23 Nov 83 04:33:37-EST
From: Clayton Elwell <ELWELL@CWRU20>
Subject: problems with kermit.c
To: info-kermit@CUCS20



I uploaded PS:<KERMIT>KERMIT.C from COLUMBIA-20 to my CP/M system
by capturing the typeout text.  I then integrated the code into my
terminal program (written in C).  The code compiled beautifully.
I now can receive files and batches of files from our DEC20 (running
Kermit-20, though not the very latest version) with no problem.

However, when I try to send a file to the DEC20, the Kermit-20
bombs, saying ("retry count exceeded in RDATA") or something similar.

I have not touched the code.  Does anyone have any idea what's
wrong?  It may be related to the problem that DIAMANT@CWRU20
just mentioned on this list...


                Thanks,


                Clayton Elwell
                Elwell%CWRU20@COLUMBIA-20
                    OR
                Elwell.Case@Rand-Relay
                    OR
                {usenet}!decvax!cwruecmp!elwell
-------
23-Nov-83 09:45:49-EST,1263;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 23 Nov 83 09:45:44 EST
Date: Wed 23 Nov 83 09:47:41-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: kermit-11
To: [e-mail], info-kermit@CUCS20
In-Reply-To: Message from "Carl Fussell <[e-mail]>" of Wed 23 Nov 83 04:35:58-EST

Currently, we only have the OMSI Pascal version of KERMIT for RT-11, which
doesn't do much for the majority of RT-11 installations that don't have OMSI
Pascal.  There are currently several other possibilities in the works:

1. Someone, somewhere, is attempting to get the UNIX version to run under
   DECUS C.

2. Brian Nelson at the University of Toledo is writing a version of KERMIT in
   Macro-11 for RSTS/E.  He says he will write it with all the system
   dependencies isolated into small routines so that it will be readily
   adaptable to RT-11 and RSX-11 by plugging in new versions of those routines.

3. Stevens Institute of Technology is writing KERMIT for the DEC Pro-350 with
   P/OS in a combination of Bliss and Macro-11.  This one would be somewhat
   harder to adapt to RT-11.

I don't have any of these in hand yet; (2) seems like the best bet for RT-11.

- Frank
-------
23-Nov-83 10:45:33-EST,1491;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 23 Nov 83 10:45:22 EST
Date: Wed 23 Nov 83 10:47:07-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: KERMIT and TAC
To: [e-mail], Info-Kermit@CUCS20

I've been told by someone who knows about these things (Mark Crispin at
Stanford) that there's no good way to make KERMIT-20 put the TAC in binary
mode, at least not in a way that doesn't depend on a bug in TOPS-20 that may be
present at some sites but fixed at others (the bug being that FF (a byte with
all 1's) is supposed to be quoted by doubling in the monitor, but isn't, so
some application programs do it instead).  Therefore, the way to use KERMIT
over a TAC would seem to be:

1. Set the TAC escape character to be any control character other than ^A or
CR, LF, etc.  ^A is KERMIT's packet synchronization character, and CR or LF
might be used as line terminators at the end of packets (KERMIT never puts any
control characters inside the packets).  Also, choose the character to be
something you're unlikely to type during your timesharing session.  For
instance, as Keith Petersen suggests, use ^E.  Do this by typing "@I 5" (for
^E) to the TAC.  This allows "@" to be transmitted.

2. To send binary files, type "@B O S" and "@B I S" to the TAC (if you already
did step 1, then I suppose you would type "^EB O S" and "^EB I S").

I'm not a TAC user myself, so I can't vouch for any of this.  - Frank
-------
23-Nov-83 11:24:10-EST,2241;000000000000
Return-Path: <@CUCS20:OC.GARLAND@CU20B>
Received: from CUCS20 by CU20B with DECnet; 23 Nov 83 11:23:59 EST
Received: from CU20B by CUCS20 with DECnet; 23 Nov 83 11:26:14 EST
Date: Wed 23 Nov 83 11:22:55-EST
From: Richard Garland <OC.GARLAND@CU20B>
Subject: [Nick Bush <OC.BUSH@CU20B>: Re: VAX kermit]
To: info-kermit@CUCS20

I asked Stevens Institute about a problem with VAX/VMS kermit hanging
up the line on outgoing connects after escaping back to do file trans-
fers.  The reply may be of interest to others:
                    Rg
                ---------------

Mail-From: OC.BUSH created at 22-Nov-83 18:26:48
Date: Tue 22 Nov 83 18:26:48-EST
From: Nick Bush <OC.BUSH@CU20B>
Subject: Re: VAX kermit
To: OC.GARLAND@CU20B
cc: oc.sitgo@CU20B
In-Reply-To: Message from "Richard Garland <OC.GARLAND@CU20B>" of Tue 22 Nov 83 11:35:42-EST

The problem occurs because VMS Kermit does not allocate the terminal
line and deassigns it when returning from the CONNECT command.
It turns out that VMS will drop DTR whenever a terminal line
which was declared to be a modem becomes free (neither allocated
nor assigned).  The solution is to allocate the terminal line before
entering Kermit.  That way the terminal will never become "free" until
it is explicitly deallocated by a DCL command.  I'll think about
putting the code into Kermit to allocate the line when a SET LINE
is given and release it when exiting (or changing lines).  It
would still be a good idea to allocate the terminal line in that case
anyway, since otherwise exiting Kermit would cause the line to hangup
(which is not always desired).  I ran into another version of this problem:
I forgot to allocate a terminal line (non-modem line) and started up
a Kermit in Server mode on the other end.  After returning to VMS Kermit
I had a hard time getting the terminal line back, since the NAK's which
the Server was sending out were being taken as unsolicited input and
causing LOGINOUT to run.  It would eventually time out, just about
in time for the next NAK to show up.

Anyway, at least for the current version of VMS Kermit, the user should
allocate the terminal line from DCL before attempting to use it from Kermit.

- Nick
-------
-------
23-Nov-83 22:12:38-EST,756;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 23 Nov 83 22:12:34 EST
Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Wed 23 Nov 83 22:15:14-EST
Date: Wed 23 Nov 83 19:10:47-PST
From: Mark Crispin <[e-mail]>
Subject: Re: KERMIT and TAC
To: [e-mail]
cc: [e-mail], [e-mail]
In-Reply-To: Message from "Frank da Cruz <[e-mail]>" of Wed 23 Nov 83 09:46:12-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: [phone] (Stanford); [phone] (residence)

     I believe that @ B I S will suffice to disable the TAC escape character,
so the step of setting it with @I should be unnecessary.
-------
24-Nov-83 09:52:52-EST,1518;000000000000
Return-Path: <@CUCS20:ABN.ISCAMS@USC-ISID>
Received: from CUCS20 by CU20B with DECnet; 24 Nov 83 09:52:48 EST
Received: from USC-ISID.ARPA by COLUMBIA-20.ARPA with TCP; Thu 24 Nov 83 09:55:31-EST
Date: 23 Nov 1983 20:52-PST
Sender: ABN.ISCAMS@USC-ISID
Subject: Re: KERMIT and TAC
From: ABN.ISCAMS@USC-ISID
To: MRC@SU-SCORE
Cc: cc.fdc@COLUMBIA-20, Info-CPM@BRL
Cc: Info-Kermit@COLUMBIA-20
Message-ID: <[USC-ISID]23-Nov-83 20:52:55.ABN.ISCAMS>
In-Reply-To: The message of Wed 23 Nov 83 19:10:47-PST from Mark Crispin <[e-mail]>

Talking about disabling (or changing) the TAC escape character..

I just had a (polite but sincere) talking to by my TAC owners...
Seems they don't really like so very much when users start messing about with
their ports!  (I never changed the excape character because I suspected it
would cause people problems.)  I DID leave F O S set a couple of times
(makes XON/XOFF happen at the TAC level for immediate halting of a listing
while my software writes to file) -- usually when the system choked up and
I got thrown off!  Turns out any of those convenient settings we users make
to ports STAY THAT WAY when we leave/sign off unless we specifically reset
them to the way things were -- and that sure can mess up the next guy.

I'd suggest anyone playing with their TAC maybe check with the operators
first to kind of work out an agreement.  If they know what and why you're
doing, they tend to be much more understanding!

David Kirschbaum
Toad Hall
25-Nov-83 09:50:05-EST,830;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 25 Nov 83 09:50:01 EST
Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Fri 25 Nov 83 09:52:44-EST
Date: Fri 25 Nov 83 06:51:08-PST
From: Ted Markowitz <[e-mail]>
Subject: Modifying PC Kermit
To: [e-mail]

A suggestion for a useful modification. A command could be added
to allow a port other than the primary comm port to be used
for data transfers. I ran into this while testing a windowing
piece of software that coopts the primary comm port for a mouse.
I'd like to be able to use the other port I've got on a
memory card to still use Kermit under the window program.
I looked at the source, but am still not familiar enough with
808x code to hack it out myself.

--ted
-------
25-Nov-83 10:26:32-EST,434;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 25 Nov 83 10:26:30 EST
Date: Fri 25 Nov 83 10:28:48-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: Modifying PC Kermit
To: [e-mail], info-kermit@CUCS20
In-Reply-To: Message from "Ted Markowitz <[e-mail]>" of Fri 25 Nov 83 09:52:53-EST

The next release of PC Kermit will be able to switch ports.  - Frank
-------
25-Nov-83 17:40:38-EST,1056;000000000000
Return-Path: <@CUCS20:jalbers@BNL>
Received: from CUCS20 by CU20B with DECnet; 25 Nov 83 17:40:35 EST
Received: from BNL by COLUMBIA-20.ARPA with TCP; Fri 25 Nov 83 17:42:30-EST
Date: 25-Nov-83 17:39:38-EST
From: jalbers@BNL
Subject: I GIVE UP!!!!!!!!!!!
To: info-kermit@COLUMBIA-20



After trying to get KERMIT up on an Osborne Exec for about 3 months, I GIVE UP!

Thanks for all the help I got from the people on the net, but it was no use.  I
want to ask whoever it was who put together that file to get in contact with me
since the host I was using untill October is now down and I still do want to
get it up.

I got contacted by 4 other Exec owners who all had the same problems as I did
getting it up, and the only explanition I can give is there must be 2 different
versions of CP/M 3 out for it.


                                     "...as he groped for the escape key..."

                                                           Jon Albers

                                                             jalbers@bnl
26-Nov-83 12:41:39-EST,971;000000000000
Return-Path: <@CUCS20:w8sdz@brl>
Received: from CUCS20 by CU20B with DECnet; 26 Nov 83 12:41:35 EST
Received: from BRL by COLUMBIA-20.ARPA with TCP; Sat 26 Nov 83 12:44:07-EST
Date:     Sat, 26 Nov 83 12:39:18 EST
From:     Keith Petersen <w8sdz@brl>
To:       Mark Crispin <[e-mail]>
cc:       [e-mail], [e-mail], [e-mail]
Subject:  Re:  KERMIT and TAC

If you do @B I S to the TAC you don't have ANY intercept character
at all and it's then impossible to @C (close) the connection
between the TAC and your host after you're done.  I'm not certain
but I think this may leave a "hanging job" on your host.  The
@I 5 command to set the TAC for control-E intercept works fine
with KERMIT for text files and when you are done the TAC reverts
to the normal "@" intecept for the next caller so no one will be
unhappy with you changing the intercept character for the duration
of your connection.
--Keith
26-Nov-83 15:21:15-EST,1043;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 26 Nov 83 15:21:11 EST
Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Sat 26 Nov 83 15:23:43-EST
Date: Sat 26 Nov 83 12:22:07-PST
From: Mark Crispin <[e-mail]>
Subject: Re:  KERMIT and TAC
To: [e-mail]
cc: [e-mail], [e-mail], [e-mail]
In-Reply-To: Message from "Keith Petersen <w8sdz@brl>" of Sat 26 Nov 83 09:42:56-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: [phone] (Stanford); [phone] (residence)

In my humble opinion, any host which fails to hang up the connection
when the user logs out should be disconnected from the ARPANET until
they fix their software!  @ B I S is the means of getting into binary
mode on the TAC, and no host should make that mode useless.  Disabling
the TAC intercept character is necessary if you want true binary I/O.
Hosts ought to work well enough so this functionality is usable.
-------
26-Nov-83 17:02:51-EST,783;000000000000
Return-Path: <@CUCS20:w8sdz@brl>
Received: from CUCS20 by CU20B with DECnet; 26 Nov 83 17:02:44 EST
Received: from BRL by COLUMBIA-20.ARPA with TCP; Sat 26 Nov 83 17:05:08-EST
Date:     Sat, 26 Nov 83 16:54:27 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Cpm@brl-vgr, Info-Kermit@columbia-20
Subject:  Re:  KERMIT and TAC

If the host software is properly written it should be possible for the
operating system to send instructions to the TAC, telling it to enter
and exit BINARY mode.  UMODEM (for UNIX), MODEM (for TOPS-20) and MMODEM
(for ITS at MIT) all do this sucessfully, making it unnecessary for the
user to "lose control" of his TAC.  I frequently connect to several
hosts during one TAC session and "losing control" is unacceptable to me.
-Keith
27-Nov-83 12:14:21-EST,2753;000000000000
Return-Path: <@CUCS20:ABN.ISCAMS@USC-ISID>
Received: from CUCS20 by CU20B with DECnet; 27 Nov 83 12:14:17 EST
Received: from USC-ISID.ARPA by COLUMBIA-20.ARPA with TCP; Sun 27 Nov 83 12:14:43-EST
Date: 27 Nov 1983 08:52-PST
Sender: ABN.ISCAMS@USC-ISID
Subject: Re:  KERMIT and TAC
From: ABN.ISCAMS@USC-ISID
To: MRC@SU-SCORE
Cc: w8sdz@BRL, cc.fdc@COLUMBIA-20, Info-CPM@BRL
Cc: Info-Kermit@COLUMBIA-20
Message-ID: <[USC-ISID]27-Nov-83 08:52:58.ABN.ISCAMS>
In-Reply-To: The message of Sat 26 Nov 83 12:22:07-PST from Mark Crispin <[e-mail]>

Mark (also also Keith at W8SDZ):

Fully agree with the host properly hanging up/reconfiguring.

The KERMIT patch, though is SO very simple.  Atchd is my patch I recently
sent to a local user who's emulating an IBM PC (kind of) with a Wang PC.
Same problem; same fix outta work.

David Kirschbaum
Toad Hall

To: ABN.20E-SP@USC-ISID
Subject: Re: TAC X/ON X/OFF
In-Reply-To: <[USC-ISID]26-Nov-83 13:42:41.ABN.20E-SP>
------------------------------------------------------------------------
Sir,

I don't have the source code of PCKERMIT available now, so I can't move an
actual patch over to you.

However -- if you can grab the chunk of assembler that actually sends
characters out the port when sending packets (in my version its the
section with OUTCHR, OUTCH0, OUTCH1, etc...) and move/message it to me,
I can put in the patches.

What you do is get the character from a register or memory (wherever
KERMIT put it)(the character you want to send as part of a packet,
that is, and compare it to 40H (the @ sign).  If it isn't an @ sign,
just go ahead and send it.  If it IS -- send it twice!.

In my code (8080), it looks like this...

outchr:    mov a,e        ; get the char into A
        call setpar    ; This is the routine that sets parity on
                ; the char to your desires.  I moved it
                ; up here to keep it out of the TAC loop.
        mov e,a        ; Put the character back into E while we
                ; use A to check port status.
        cpi 40h        ; compare immediate A with the @ sign.
        cz outch1    ; Yep - got an @.  Call the OUT routine to
                ; send it the first time, and fall through to
                ; send it the second time (elegant, no?)

outch1:    in mnprts    ; Get the output ready flat from the Tx
                ; status port.
        ani output    ; Is the ready bit set?
        jz outch1    ; Not ready, loop...
        mov a,e        ; Char back into A register
outch2:    out mnport    ; Put it out the modem port (finally).
        ret        ; Return the first time to the OUTCHR
                ; call, the second time (if there IS a second
                ; time) to whatever called this.


That's all there is to it!  Now your code and registers are going to be
a bit different, but basically the simple idea works.

Have fun...

SGM K
27-Nov-83 13:57:10-EST,2947;000000000000
Return-Path: <@CUCS20:ABN.ISCAMS@USC-ISID>
Received: from CUCS20 by CU20B with DECnet; 27 Nov 83 13:57:05 EST
Received: from USC-ISID.ARPA by COLUMBIA-20.ARPA with TCP; Sun 27 Nov 83 13:57:27-EST
Date: 27 Nov 1983 10:51-PST
Sender: ABN.ISCAMS@USC-ISID
Subject: Re:  KERMIT and TAC
From: ABN.ISCAMS@USC-ISID
To: MRC@SU-SCORE
Cc: w8sdz@BRL, cc.fdc@COLUMBIA-20, Info-CPM@BRL
Cc: Info-Kermit@COLUMBIA-20
Message-ID: <[USC-ISID]27-Nov-83 10:51:12.ABN.ISCAMS>
In-Reply-To: The message of Sat 26 Nov 83 12:22:07-PST from Mark Crispin <[e-mail]>

PCKERMIT users:
Here's a patch to PCKERMIT to hopefully solve the TAC intercept character
problem with no hassles about resetting TACs.  Now, please check this out for
me -- I'm an 8080/Z80 hacker and donno nuttin about 8086/8088 code except
what I reasoned out of the PCKERMIT source.

Regards,

David Kirschbaum
Toad Hall

;************************System Dependent****************************
;       Put a char in AH to the port.
PORT    PROC  NEAR
IF ibmpc
outchr:    sub cx,cx        ; [14 start]
    mov al,ah        ; Parity routine works on AL. [16]
    call dopar        ; Set parity appropriately.     [10]
    mov ah,al        ; Don't overwrite character with status. [16]
    mov dx,03FDH

; Toad Hall note:  hokay - now we got the char in ah.  Need to test and see
;if it's the infamous TAC intercept character (@ in this case).  Sending it
;twice will tell the TAC that it's a true ASCII character for the host: the
;TAC will then send a single @ on to the host, and echo one more back to you.
;If it is, we'll call OUTCH1 to put it out once, and then fall through to
:put it out the second time.  If it isn't, we'll just send one character.
; PS:  Somebody with a manual on this assembler language check this out
; for me - I'm only guessing at the mnemonics since I'm a Z80/8080 hacker.

    cmp ah,40h        ; Is it the @?
    cz outch1        ; Yep, send it the first time..
                ; ...and fall through for the second.
                ; Else just send it once.  [Toad Hall]
;End of Toad Hall TACpatch
outch1:    in al,dx
    test al,20H        ; Transmitter ready?
     jnz outch2        ; Yes
    loop outch1
     jmp r            ; Timeout
outch2:    mov al,ah        ; Now send it out
    mov dx,03F8H
    out dx,al
    jmp rskp        ; [14 end]
ENDIF
IF Z100
outchr:    mov al,ah        ; Yes, get the character into al
    mov cx,0
    call dopar        ; Set parity appropriately.   [10]

; Toad Hall Note:  somebody check this for me -- I assume here that
; ah has not been trashed by the DOPAR call above, and the char is
; still in ah.  I also assume the BIOS-AUXOUT call don't do nuttin
; to ah or al or wherever the char is being accessed so we can in
; fact call and put it out twice in a row.  [Toad Hall]

    cpi ah,40h        ; Is the char an @ (TAC intercept char)?
    cz bios-auxout        ; Yep - send it once...
                ; ...and fall through to send the 2nd...
; End of Toad Hall TACpatch.

outch1:    call bios_auxout    ; Send the character
    jmp rskp
ENDIF

27-Nov-83 14:10:40-EST,1399;000000000001
Return-Path: <@CUCS20:w8sdz@brl>
Received: from CUCS20 by CU20B with DECnet; 27 Nov 83 14:10:37 EST
Received: from BRL by COLUMBIA-20.ARPA with TCP; Sun 27 Nov 83 14:00:54-EST
Date:     Sun, 27 Nov 83 13:54:36 EST
From:     Keith Petersen <w8sdz@brl>
To:       Info-Kermit@columbia-20
cc:       Info-Cpm@brl-vgr
Subject:  Bug fix for Kermit-80 ver 3.5

There is a bug in the CONNECT (dumb terminal) function of CPMBASE.ASM.
It causes continuous NULLs to be sent out to the modem when there
are no characters ready from the console keyboard.  This bug occurs
in all versions except ROBIN or RAINBO or GENER or DMII.  Two lines
of code were mis-placed.  Below is a listing of the corrected area.

CONCHR:
IF NOT (ROBIN OR RAINBO OR GENER OR DMII)
        MVI     C,DCONIO        ; Direct console I/O BDOS call.
        MVI     E,0FFH          ; Input.
        CALL    BDOS
ENDIF                           ; NOT (robin OR rainbo OR gener OR dmII)
IF ROBIN OR RAINBO OR GENER OR DMII
        CALL    BCONST          ; Get the status
        CALL    BCONIN          ; Yes, get the character
ENDIF                           ; robin OR rainbo OR gener OR dmII
        ORA     A               ; Anything there?  <-----corrected
        JZ      RSKP            ; No, forget it    <-----corrected
        ANI     7FH             ; Keep only 7 bits
........
End of corrected area
27-Nov-83 15:24:06-EST,584;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 27 Nov 83 15:23:59 EST
Date: Sun 27 Nov 83 15:23:51-EST
From: Daphne Tzoar <CC.DAPHNE@CUCS20>
Subject: Re: Modifying PC Kermit
To: [e-mail]
cc: info-kermit@CUCS20
In-Reply-To: Message from "Ted Markowitz <[e-mail]>" of Fri 25 Nov 83 09:52:54-EST

 I recently added a command to let user's choose between communications
 port one (the primary one) and port two.  It is in a version of PC
 Kermit that I hope to formally announce in a week or two.
/daphne
-------
27-Nov-83 15:42:21-EST,516;000000000000
Return-Path: <@CUCS20:LIN@MIT-ML>
Received: from CUCS20 by CU20B with DECnet; 27 Nov 83 15:42:17 EST
Received: from MIT-ML by COLUMBIA-20.ARPA with TCP; Sun 27 Nov 83 15:42:34-EST
Date: 27 November 1983 15:43 EST
From: Herb Lin <LIN @ MIT-ML>
Subject:  KERMIT and multiple send-receives...
To: Info-Kermit @ COLUMBIA-20
In-reply-to: Msg of Wed 23 Nov 83 19:10:47-PST from Mark Crispin <MRC at SU-SCORE.ARPA>



is this possible?  thanks.  pls reply to me directly, as I am not on
INFO-KERMIT.

tnx.

27-Nov-83 21:07:50-EST,4634;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 27 Nov 83 21:07:39 EST
Received: from SRI-KL.ARPA by COLUMBIA-20.ARPA with TCP; Sun 27 Nov 83 21:07:49-EST
Date: Sun 27 Nov 83 18:03:13-PST
From: William "Chops" Westfield <[e-mail]>
Subject: TACs and BINARY mode on TOPS20
To: [e-mail], [e-mail]

The problem is that the current implementation of TOPS20 is not
"properly written".  It is broken.  It isnt even clear that it
will work if you give your TAC an @B I S command sequence....
Here is the a description and solution to the BINARY MODE
problem on TOPS20.

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

Date: Mon 1 Aug 83 14:17:59-PDT
From: [e-mail]
Subject: [Frank J. Wancho <FJW @ MIT-MC>: [pditmars: Binary]]
To: [e-mail], [e-mail]

As some of you may know, there are a series of programs for
downloading microcomputers from Tops-20 systems.  Recently, a new
version of TAC code was installed, and these programs stopped working
when used through a TAC.  After much searching, this was finally
tracked down to a bug in Tops-20 (or a mis-feature) that was agravated
by the new TAC code.  A patch has been developed (and is enclosed).
This patch has been tested at SRI and at SIMTEL20, and should be
installed if you have any users who use the MODEM program to download
micros over the ARPANet.

Bill Westfield

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

    Date: 24 June 1983 12:29 EDT
    From: Frank J. Wancho <FJW @ MIT-MC>
    Subject:  [pditmars: Binary]
    To: BillW @ SRI-KL

    Bill,

    Peter patched my TAC port so that he could capture the TCP headers in
    a dump.  I ran MMODEM on MC first, to demonstrate a working version.
    Then I ran your MODEM (still 125) on XX.  Here's is his results so
    far.  I thought you'd be interested...  --Frank
    --------------------

    Date: 24 Jun 1983 11:14:32 EDT (Friday)
    From: Pieter Ditmars <pditmars at BBN-UNIX>
    To:   fjw
    cc:   taccers at BBN-UNIX, pditmars at BBN-UNIX
    Re:   Binary

    Frank,
    Results of the dump proved inconclusive, though something funny
    seems to be going on. Can't see the first IAC from xx but it should
    be a "will binary" cause the TAC responds do binary. Then xx says
    wont binary and the tac gives don't binary. Finally xx sends do
    binary to which the TAC does not reply. Looks like we got a bug here
    new tests in progress will msg you when isolated. Pete


    Date: 27 Jul 1983 18:26-PDT
    From: William "Chops" Westfield <BillW @ SRI-KL>
    To: Wancho@SIMTEL20
    Cc: billw@SRI-KL

    Here is a bug fix that might help fix the downloading through TAC
    problem.  First, the suspected reason it doesnt work:

        The 20 sends "WILL BINARY".  The TAC receives this and,
        if binary is not already set, responds with a positive
        "DO BINARY" (this explains why it will work if you put
        the TAC in binary mode BEFORE you connect to the host).
        The 20 monitor receives the "DO BINARY", and is currently
        set to refuse this option (I consider this a bug, and plan
        to complain to DEC - It will help if other Net heavyweights
        complain also), so it sends "WONT BINARY",and the TAC
        responds "DONT BINARY", leaving things in NON-binary mode.
        The reason this probably worked in older versions of the
        TAC code is that the TAC probably ignored the second "DONT
        BINARY" and just transmitted all 8 bits from the host anyway.
        Thus this is really a bug in TOPS-20, and not in the new TAC
        code.

    Now, here is the fix:

        In module TTNTDV, at location    NVTDOD, change
            NVTDOD:    IFIW!R
        to
            NVTDOD:    IFIW!RSKP
        (This can also be done to the binaries, of course, and
         its relatively safe to do to a running monitor:
        @MDDT
        call SWPMWE$x        ;write enable swappable monitor
        NVTDOD/ SETZ RSKP    ;make the change
        call SWPMWP$x        ; write protect monitor again
        ^Z            ;exit MDDT )

        This will cause TOPS20 to reply "WILL BINARY" whenever
        it receives "DO BINARY", which chould not cause any
        problems.  The PROPER thing to do is to reply positively
        only if the program on the other end is reading from
        the terminal in binary mode, and refuse otherwise. Putting
        the terminal in binary mode should take care of everything.
        Unfortunately, the relevant code (NVTMOD) has been commented
        out of the current monitor.

    Please let me know if this works...

    Bill Westfield
-------
-------
30-Nov-83 10:46:51-EST,4369;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 30 Nov 83 10:46:39 EST
Date: Wed 30 Nov 83 10:45:45-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: KRFC #9, Preserving File Attributes
To: Info-Kermit@CUCS20

The following is from Nick Bush of Stevens Institute of Technology.  Although
the Kermit protocol now provides a way to transmit file attributes, nothing is
said about how to preserve them on the target system so that they can be
restored correctly upon return to the system of origin.  This proposal
addresses the question.  - Frank
----------------
Date: Tue 29 Nov 83 22:42:27-EST
From: Nick Bush <OC.BUSH@CU20B>
Subject: File attribute packet handling
To: SY.FDC@CU20B

After a good bit of consideration of how to handle the file attributes
for Files-11 (VMS and RSX) files, I have come up with a suggestion (one
which will especially impact Kermit-10 and -20).

I think the acceptance of a file attribute should not imply that the
attribute is really used in the destination system, only that if the file
is transmitted by Kermit from that system it will send all the attributes
out the same as it received.  It would be best if a Kermit could handle
as many of the possible attributes as possible, since then files from
any system could be stored on any other system and retrieved without any
modification.  Right now it is not possible to store task files (.TSK)
from an RSX system or .EXE files from a VMS system on a -10 or a -20 and
expect to be able to get the original file back.  This is because some
information about the structure of the file has no corresponding attribute
under either TOPS-10 or TOPS-20, and the original file cannot be recreated
with the additional information.  The file attributes packet does provide
this information, but with the current definition there would still be
no method of storing the attribute information unless the file system
supported the attributes.

Therefore, I suggest the following for Kermit-10 and Kermit-20 (in the
theory that both should do the same thing as much as possible):

1. Some method be devised to store the file attributes (those that are
   not reasonable for -10's and -20's, like block size, etc.).  This
   could possibly be an extension of the "DSK8" kludge, but would not
   need to recognize anything in the incoming data stream.  I don't
   have a proposal for the exact format of the storage, but I think
   it would probably be easiest to store it in a form close to what it
   is like in the attributes message.

2. Kermit-10 and Kermit-20 (once they are taught to recognize the
   packet at all) should be willing and able to store any unrecognized
   attributes in the file using the method described above.  I would
   assume that like other random things there should be a SET command
   to allow the user to enable/disable this.

3. There should be one file type defined for the attributes packet that
   says the file is a text file which must be stored in a format which
   is readable on the destination system as a text file.  I assume that
   this is what you intended file format "A" to be.  I think there needs
   to be some specific mention that this format must result in a file
   which is readable, and does not need to result in an identical file
   when it is transferred back to the original system, only that it
   should be as close as possible within the constraints of the text
   storage conventions of the two systems.  There should probably also
   be an additional file type which specifies a text file which must
   be returnable in identical format.

4. The attributes should be split into attributes which are system
   independent format (or are an attempt at system independence),
   and those which are system dependent.  I think the only system
   dependent item you have at the moment is ' (ASCII 44) protection
   code.  Whether any other will be (or should be) added I don't know.

One other item I just thought of while typing this in:  What time zone
are the date/times expressed in?  GMT?   Might be nice to attempt to
standardize that before anyone does anything with it.  Of couse, some
systems don't really know what time zone they are in (TOPS-10 7.01 doesn't),
so it might be tough to make it GMT.

- Nick
-------
30-Nov-83 11:32:37-EST,1488;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 30 Nov 83 11:32:18 EST
Date: Wed 30 Nov 83 11:31:48-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: KRFC #9, Preserving File Attributes
To: Info-Kermit@CUCS20
In-Reply-To: Message from "Frank da Cruz <[e-mail]>" of Wed 30 Nov 83 10:46:02-EST

The business of storing file attributes in the file itself is, of course, very
much like the "ITS Binary Format" idea.  The major problem is how to
distinguish attributes thus stored from file data.  The answer is probably
very much like the ITS answer: start the file with some kind of header which
is very unlikely to be found among actual file data, but allow the user a way
to override in case of an unfortunate coincidence.  I'd also suggest that a
new attribute be added: operating system and version.  This will allow the
system receiving a file which begins with an attributes header to decide
whether to use (interpret) the attributes when storing the file, or simply to
keep them.  This way, a file can be sent with its attributes through many
different systems, and only a system like the one that originated the file
will attempt to interpret them.  For this to work, there will have to be a
standard list of codes for machines and operating systems.  An alternative,
or perhaps parallel idea, will be to include in the Disposition attribute an
option to store or to keep the attributes.  - Frank
-------
30-Nov-83 13:51:59-EST,617;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 30 Nov 83 13:51:54 EST
Received: from SIMTEL20.ARPA by COLUMBIA-20.ARPA with TCP; Wed 30 Nov 83 13:51:45-EST
Date: Tuesday, 29 November 1983  22:10-MST
Message-ID: <KPETERSEN.11971797634.BABYL@SIMTEL20>
Sender: Herb Lin <LIN@MIT-ML>
From: Herb Lin <LIN@MIT-ML>
To: W8SDZ@SIMTEL20
Subject:   KERMIT and multiple send-receives...
ReSent-From: KPETERSEN@SIMTEL20
ReSent-To: Info-Kermit@columbia-20
ReSent-Date: Wed 30 Nov 1983 11:48-MST

i need kermit for a compupro interfacer 3 board.  must i use generic kermit?
30-Nov-83 18:00:45-EST,1075;000000000000
Return-Path: <@CUCS20:reid@Glacier>
Received: from CUCS20 by CU20B with DECnet; 30 Nov 83 18:00:37 EST
Received: from Glacier by COLUMBIA-20.ARPA with TCP; Wed 30 Nov 83 17:59:34-EST
Date: Wednesday, 30 November 1983 11:47:39-PST
To: Frank da Cruz <[e-mail]>
Cc: [e-mail], Mogul@Navajo
Subject: Re: KRFC #9, Preserving File Attributes
In-Reply-To: Your message of Wed 30 Nov 83 11:31:48-EST.
From: Brian Reid <reid@Glacier>

Jeff Mogul of Stanford, as part of his thesis work, has had very good
luck with representing file attributes as Lisp-like Properties, and
transmitting a series of attribute/value pairs defining file properties
along with the transmission of the file itself.

The issue of system-independent file properties is a very important
one, and I encourage people to think about it a bit before they dive in
and implement something. Perhaps I can persuade Jeff to send around a
short summary of his scheme, which incidentally was presented as a
``short paper'' at the recent SOSP symposium.
    Brian Reid
30-Nov-83 22:52:31-EST,819;000000000000
Return-Path: <@CUCS20:abrams@mitre>
Received: from CUCS20 by CU20B with DECnet; 30 Nov 83 22:52:25 EST
Received: from mitre by COLUMBIA-20.ARPA with TCP; Wed 30 Nov 83 22:14:41-EST
Date: 30 Nov 1983 22:02:26 EST (Wednesday)
From: Marshall Abrams <abrams@mitre>
Subject: Donate computer for tax credit
To: microgroups:@mitre
Cc: abrams@mitre

A charitable organization in the Washington, DC area would like to receive a
donation of a computer. The donor would get a tax credit based on his/her
valuation of the hardware and software.

This would be an excellent opportunity to do a good deed and recover one's
investment so that a newer configuration could be purchased.

Please contact me to discuss this further. My telephone at work is 703/827-6938
and at home is 301/588-1005.

Marshall Abrams

 1-Dec-83 18:00:43-EST,1471;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 1 Dec 83 18:00:38 EST
Date: Thu 1 Dec 83 18:00:04-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: KERMIT in PL/I for MULTICS available
To: Info-Kermit@CUCS20

This is to announce a new version of KERMIT written in PL/I for the Honeywell
MULTICS system by Paul Amaranth of Oakland University, Rochester Michigan.
This is an initial release, and provides basic service, i.e. no server mode of
operation.

Paul will continue to develop this version; he expects to be adding server mode
and other functionality in the coming months.  If anyone wants to modify this
program, it is suggested that you contact Paul first, to make sure that the
work is not already done.  Unfortunately, he's not connected to any networks,
but you can call him at the number given in the source file.  You should also
call him if you have bugs to report.

This is one of two PL/I KERMITs, developed independently.  The other, for PR1ME
computers done by people at The SOURCE, will be available shortly, as soon as I
receive their tape.  The PR1ME version will have server mode and several other
advanced features.

Either of these PL/I KERMITs may serve as a basis for new implementations for
computers that have PL/I, such as the many IBM operating systems (DOS, MVS/TSO,
MTS, GUTS, MUSIC, etc) not currently supported.  Efforts in this direction are
encouraged.

- Frank
-------
 1-Dec-83 18:46:00-EST,1077;000000000000
Return-Path: <@CUCS20:reid@Glacier>
Received: from CUCS20 by CU20B with DECnet; 1 Dec 83 18:45:28 EST
Received: from Glacier by COLUMBIA-20.ARPA with TCP; Thu 1 Dec 83 18:45:07-EST
Date: Thursday, 1 December 1983 15:43:00-PST
To: Info-Kermit@Columbia-20
Subject: next step: Kermit Mail
From: Brian Reid <reid@Glacier>

The obvious next step in the development of Kermit is the design of a
Kermit Mail protocol. Many many people have wanted "uucp" mail on their
personal computers, but in fact all they really need is a way of
participating in mail networks. Now that all of the hard stuff, namely
reliable data transfer and protocol negotiations, is in place, it is
time for somebody to start thinking about a uucp-like Kermit Mail
protocol on top of it.

Other than the startup/wrapup parts of the protocol, it seems to me
that the right way to do is to implement the Arpa SMTP mail protocol or
else the NBS message transmission standard. The world doesn't need yet
another mail protocol, and uucp is more-or-less undocumented.
    Brian Reid
    Stanford


 1-Dec-83 20:22:50-EST,612;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 1 Dec 83 20:22:21 EST
Received: from SIMTEL20.ARPA by COLUMBIA-20.ARPA with TCP; Thu 1 Dec 83 20:21:25-EST
Date: 1 Dec 1983  18:16 MST (Thu)
Message-ID: <WANCHO.11972130354.BABYL@SIMTEL20>
From: "Frank J. Wancho" <WANCHO@SIMTEL20>
To:   Brian Reid <reid@Glacier>
Cc:   INFO-KERMIT@COLUMBIA-20
Subject: next step: Kermit Mail
In-reply-to: Msg of 1 Dec 1983  16:43-MST from Brian Reid <reid at Glacier>

Brian,

Do you remember someone recently making a suggestion that SMTP have a
PROTO command?...

--Frank
 1-Dec-83 21:57:04-EST,795;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 1 Dec 83 21:57:00 EST
Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Thu 1 Dec 83 21:56:48-EST
Date: Thu 1 Dec 83 18:55:04-PST
From: Mark Crispin <[e-mail]>
Subject: Re: next step: Kermit Mail
To: [e-mail]
cc: [e-mail]
In-Reply-To: Message from "Brian Reid <reid@Glacier>" of Thu 1 Dec 83 16:38:12-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: [phone] (Stanford); [phone] (residence)

I have been looking into the feasibility of doing Kermit mail with
SMTP for some time.  No code exists yet.  Some people love Kermit,
others want TOPS-20 UUCP.  I'm hoping the dust will eventually settle.
-------
 2-Dec-83 09:52:40-EST,1283;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 2 Dec 83 09:52:30 EST
Date: Fri 2 Dec 83 09:51:35-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: next step: Kermit Mail
To: [e-mail], Info-Kermit@CUCS20
In-Reply-To: Message from "Brian Reid <reid@Glacier>" of Thu 1 Dec 83 18:45:20-EST

The idea of KERMIT-based mail has come up often in recent months.  Of course, no
version of KERMIT was ever written with this in mind, so to unravel these
programs to support SMTP (or whatever) as an alternate application above the
transport-level stuff would be a major undertaking.  Anyone about to write a
new KERMIT from scratch should design for this.  I'll be thinking about how to
change the protocol manual to allow for multiple applications.

For TOPS-20 in particular, which has extensive mail support already in the form
of MM, MMAILR, MMAILBOX (or however you spell it), etc, it would be silly to try
to incorporate all of that into KERMIT.  It has been suggested that a better
approach would be to isolate the transport-level functions into a library that
could be shared by KERMIT and the mail system.  This could come in handy right
away for mail systems like PhoneNet and MailNet.  - Frank
-------
 2-Dec-83 10:04:17-EST,386;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 2 Dec 83 10:04:08 EST
Date: Fri 2 Dec 83 09:53:29-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: MULTICS KERMIT
To: Info-Kermit@CUCS20

I forgot to say that MULTICS KERMIT is available at host COLUMBIA-20 via
anonymous FTP in the files KER:MU*.* (3 files, 51 pages = 255K).  - Frank
-------
 2-Dec-83 19:20:48-EST,618;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 2 Dec 83 19:20:45 EST
Date: Fri 2 Dec 83 19:20:31-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New Rainbow Kermit available
To: Info-Kermit@CUCS20

Bill Catchings' CP/M-86 Kermit for the DEC Rainbow-100 has a new release.
The major feature is that the port i/o is now interrupt driven, so the program
should be able to handle both file transfer and terminal emulation at 9600
baud.  Also a GET command was added, but still no wildcard SEND.

It's available at host COLUMBIA-20 via anonymous FTP as KER:RB*.*.
-------
 2-Dec-83 19:36:52-EST,1123;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 2 Dec 83 19:36:46 EST
Date: Fri 2 Dec 83 19:31:40-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Another new KERMIT-20
To: Info-Kermit@CUCS20

Several minor bugs that were reported with the recent new release of KERMIT-20
have been fixed (I hope).  These include:

 Fix SHOW ALL command not to say "DEL" at end.
. Make sure init file is taken before processing command line argument.
. Fix command line arguments to work even if no init file.
. Change SET FILE-BYTE-SIZE to SET FILE BYTESIZE.
. Add SET FILE NAMING to elect filename conversion.
. Make sure line is set up correctly after exit and continue.
. Don't send 4 extra characters if file is ITS binary.

Please replace your current copy with this one, try it out, report any
problems to me.  You should still keep version 3A around for backup, since
it's quite stable.

The new version is available at COLUMBIA-20 via anonymous FTP as
KER:20KERMIT.*.  In case you need to get the old version back, it's still here
as KER:20KEROLD.*.

- Frank
-------
 4-Dec-83 02:17:01-EST,1065;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 4 Dec 83 02:16:59 EST
Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Sun 4 Dec 83 02:16:52-EST
Date:  Sunday, 4 December 1983 02:13 est
From:  [e-mail]
Subject:  PC Kermit -- redefining keys?
To:  [e-mail]
Message-ID:  <[e-mail]>

DOS 2.0 includes a device driver, ANSI.SYS, which implements many useful
advanced keyboard and screen handling features. In particular, it
permits easy redefinition of any key on the keyboard to an arbitrary
string (much like proprietary utilities such as PROKEY). This feature is
useful-- I use it with an IBM3101 terminal emulator to change cursor
keys so they send MULTICS Emacs the correct control characters: ^f,^b
etc. Is there any easy way to utilize this built-in feature of DOS 2.0
with PC-Kermit? (I can't get it to work by redefining keys before
running kermit). If not, what is the simplest patch to redefine cursor
keys?
 4-Dec-83 11:30:23-EST,1116;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 4 Dec 83 11:30:20 EST
Received: from UDel-Relay by COLUMBIA-20.ARPA with TCP; Sun 4 Dec 83 11:30:19-EST
Received: From Csnet-Cic.arpa by UDel-Relay via smtp;  3 Dec 83 20:36 EST
Date:     3 Dec 83 11:47-EDT (Sat)
From: Rich Muller <[e-mail]>
Return-Path: <muller%UMass-ECE%UMASS-ECE@CSNet-Relay>
Subject:  VT52 emulation for Kermit-80 and -86.
To: [e-mail]
Via:  UMASS-ECE; 3 Dec 83 19:58-EST

The VT52 emulation mode doesn't seem to work at all on my
version of Kermit-80 for Apple/cpm/videx board.  What might I
be doing wrong?

And on the IBM PC at work, VT52 emulation seems to work fine, but
I can't find the equivalent of the keypad commands ... which makes
it difficult to use, eg, EDT on my VAX.

Rainbow Kermit is superb; glad to hear that there's a version now
for CPM-86 and the Rainbow; any suggestions about sources for
that for those of us who can't FTP stuff from Columbia-20?

    Rich Muller
    Hampshire College

 5-Dec-83 10:16:45-EST,1034;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 5 Dec 83 10:16:38 EST
Date: Mon 5 Dec 83 10:16:01-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: VT52 emulation for Kermit-80 and -86.
To: Info-Kermit@CUCS20
In-Reply-To: Message from "Rich Muller <[e-mail]>" of Sat 3 Dec 83 10:47:00-EST

The CP/M-80 Kermit program has grown so complex that it's not surprising that
some features of some implementations don't work.  The problem is being
addressed now by someone on the Info-Kermit list who is completely reorganizing
the program into modules that isolate the system-dependent features.  This
should make it easier to support new machines or devices or fix support that
doesn't work.  Watch this list for further announcements.

Although PC Kermit claims to emulate a VT52, it's really emulating a Heath-19.
We'll check to see if the two machines use the keypad the same way, and if so,
will look into putting support for that into Kermit-86.
-------
 5-Dec-83 13:45:44-EST,990;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 5 Dec 83 13:45:36 EST
Date: Mon 5 Dec 83 13:44:34-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Another KERMIT for VAX/VMS
To: Info-Kermit@CUCS20

THis one is from Bruce Pinn, University of Toronto.  It's written in a
combination of Fortran and Pascal.  Although the version from Stevens Institute
of Technology (written in Bliss and available in the KERMIT distribution area
as VMS*.*) is recommended, this version might be useful for those who do not
have Bliss on their systems, and feel uncomfortable about running a program
they cannot modify.  The Toronto version is available in source form at host
COLUMBIA-20 via anonymous FTP as KER:VF*.*.  The file VFREADME.TXT explains
what the other files are.

Incidentally, there is still another KERMIT for VAX/VMS -- an old
version of UNIX KERMIT to which VMS i/o support was added -- in the KERMIT
area as VX*.*.

- Frank
-------
 5-Dec-83 14:18:42-EST,1120;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 5 Dec 83 14:18:36 EST
Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Mon 5 Dec 83 14:18:23-EST
Date: Mon 5 Dec 83 11:16:43-PST
From: Jim Celoni S.J. <[e-mail]>
Subject: Re: VT52 emulation for Kermit-86
To: [e-mail]
In-Reply-To: Message from "Frank da Cruz <[e-mail]>" of Mon 5 Dec 83 07:53:19-PST

PC Kermit works perfectly with the RoseSoft's ProKey keyboard enhancer.
I'm using both now with Emacs; ALT is META, and the keypad does what it
should (e.g., Right sends Ctrl-F & Ctrl-Right sends ESC F).  A prokey
script of a dozen lines will make the PC keypad like the H/Z-19's; another
dozen will set up function keys like the Heath's too.  I'm not against
Kermit-86 supporting H19's keypad, but since there are other ways to
provide that support (other keyboard enhancers, some free) without
changing Kermit, the need may not be pressing.

Do any Kermits support a log file (capturing local keystrokes and
remote responses, not packets)?  +j
-------
 6-Dec-83 01:39:16-EST,2705;000000000000
Return-Path: <@CUCS20:ESTEFFERUD@USC-ECL>
Received: from CUCS20 by CU20B with DECnet; 6 Dec 83 01:39:08 EST
Received: from USC-ECL by COLUMBIA-20.ARPA with TCP; Tue 6 Dec 83 01:34:16-EST
Date: 5 Dec 1983 22:01-PST
Sender: ESTEFFERUD@USC-ECL
Subject: Re: next step: Kermit Mail
From: ESTEFFERUD@USC-ECL
To: cc.fdc@COLUMBIA-20
Cc: reid%SU-Glacier@SU-SCORE, Info-Kermit@COLUMBIA-20
Cc: TDomae@USC-ECL, JSweet%uci@RAND-RELAY
Message-ID: <[USC-ECL] 5-Dec-83 22:01:09.ESTEFFERUD>
In-Reply-To: The message of Fri 2 Dec 83 09:51:35-EST from Frank da Cruz
In-Reply-To:              <[e-mail]>

Having looked carefully at the idea of using one of the TTY based FTP
protocols like XMODEM or KERMIT for MAIL transfers, a group of us at
UCI (working on the MZnet Project to link an MMDF based local mail net
to student and faculty PC's at home) have come to the conclusion that
those protocols are rather hopelessly bound to the idea of having a
human intelligence around to deal with things that the protocols
cannot handle, like diskette overflow, et al.  Kermit was found to be
little better about this than XMODEM when we tried to erradicate the
dependence on human intervention.

So, we have fallen back to using the Phonenet packet protocol as the
basis for a session oriented PC Mail Post/Pickup Server attached to
the UCI ZOTnet which is an MMDF based local mail subnet of CSnet and
the Internet.  The Phonenet packet protocol may not be elegant, but it
is able to run roughshod over most of the obstacles that bedevil
XMODEM and KERMIT, such as TELENET or OTHERNETS.  But we don't mind
when 4 wheel drive is what we need.  And, it has been relatively easy
to adapt the Phonenet code, and its higher level drivers to provide
support user controllable transfer sessions.

Another problem has to do with authenication.  XMAILR and MMDF assume
that they are talking to an authenticated peer Mail Transfer Agent (So
does SMTP) when they link up to transfer mail between "certified"
hosts.  PC's are not certifiable, unless you have some way to certify
the diskettes that hold their Operating Systems.

The bottom line on all this is, that kermit may be a reasonable TTY
FTP program, but that has little to do with mail, beyond the need to
transfer text packets.  The entire session concept needs to be
reworked to act as a MAIL SERVER.  I will leave you here with the
observation that a MAIL SERVER is a much more complicated problem to
solve than the as yet unresolved design of the Kermit FTP Server.

A word to the wise:

     "Mail systems are never as simple as they seem."

Just ask Eric Allman if you don't want to believe me.
Enjoy!  Stef
 6-Dec-83 01:49:58-EST,841;000000000000
Return-Path: <@CUCS20:ESTEFFERUD@USC-ECL>
Received: from CUCS20 by CU20B with DECnet; 6 Dec 83 01:49:55 EST
Received: from USC-ECL by COLUMBIA-20.ARPA with TCP; Tue 6 Dec 83 01:36:34-EST
Date: 5 Dec 1983 22:13-PST
Sender: ESTEFFERUD@USC-ECL
Subject: Xenix Kermit Query
From: ESTEFFERUD@USC-ECL
To: Info-Kermit@COLUMBIA-20
Cc: TDomae@USC-ECL
Message-ID: <[USC-ECL] 5-Dec-83 22:13:32.ESTEFFERUD>

Has anyone out there ported Kermit onto Xenix, as for an ALTOS 586?

I get the latest version from Columbia to compile without complaint,
but, in "r" mode, it but cannot see anything from the remote host.
Also, in "c" mode, the escape character mechanism does not interupt,
etc, et al.

So, I gather that something is radically wrong with the way kermit
tries to use the Xenix library routines, or something.

Thanks - Stef
 6-Dec-83 14:31:47-EST,3096;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 6 Dec 83 14:31:39 EST
Date: Tue 6 Dec 83 14:29:54-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: [HFISCHER%USC-ECLB@MINET-CPO-EM: PC Kermit, Heath, and LAN Question]
To: Info-Kermit@CUCS20

The first suggestion, about saying that PC Kermit really emulates a Heath-19,
is noted and will be part of the next release.

About the second point -- server operation would be a desirable addition to
PC Kermit (as it is to any Kermit), and would make unattended usage very
pleasant; this is on our list of things to do (but who knows when we'll get to it?).  Redirecting interactive PC Kermit to use the back port would be
a possibility -- has anyone out there tried it?  Does the suggested method
work?  Are there other or better ways to do it?  - Frank
                ---------------

Return-Path: <HFISCHER@USC-ECLB>
Received: from USC-ECLB by COLUMBIA-20.ARPA with TCP; Tue 6 Dec 83 01:04:36-EST
Date:  5 Dec 1983 2202-PST
From: HFISCHER%USC-ECLB@MINET-CPO-EM
Subject: PC Kermit, Heath, and LAN Question
To:   cc.fdc at COLUMBIA-20
cc:   HFischer at USC-ECLB

Frank,

First, let me thank you for the msg that PC kermit actually emulates a
heath, instead of the VT52.  Kermit was a real dog in the VT52,
especially with EMACS.  With the H19 mode, it nicely does line insert
and delete, and is relatively breezy to use.  I don't think the
average kermit user on an PC realizes that he is working with the H19.
I'd recommend that the on line help, and the user.doc, both reflect
this.

My real question stems from a local area net that my company just
installed to interconnect its horde of PC's.  We find that two
Kermit's can talk if humans attend both and are in phone contact to
coordinate loading, setting into receive/send mode, etc.  But, what
would be desired is like an unattended remote server, like for the
department manager about to write his weekly status report to place
his PC into unattended server state, and let the network users
connect to him and send him files;  or maybe they connect to receive
the company's staff report, or broadcast news files, etc.

For the unattended server to just be a KERMIT program in serving mode
(probably easy to patch into the asm code), it would have to stand for
the local area network's "informational messages", plain ascii
notification of who the caller is, when he disconnects, etc.

Or would it be possible to do a CTTY PC DOS command to redirect
console input to the async line, and then get remote guys to log on,
load kermit themselves, and operate the remote PC remotely (as they
would do for a host?)?  Will KERMIT cooperate with the CTTY console
redirection on the PC?

There must be other places with LAN's and PC's using kermit to do this
sort of thing, without human attendance and voice contact doing each
minor detail.  What ideas would you recommend?  Or could you put me in
touch with other LAN KERMIT users)?

Thanks in advance,

  Herm Fischer (HFischer@ECLB)
-------
-------
 6-Dec-83 15:51:25-EST,956;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 6 Dec 83 15:51:11 EST
Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Tue 6 Dec 83 15:49:54-EST
Date: Tue 6 Dec 83 12:48:01-PST
From: Mark Crispin <[e-mail]>
Subject: Re: next step: Kermit Mail
To: [e-mail]
cc: [e-mail], [e-mail],
    [e-mail], [e-mail],
    [e-mail]
In-Reply-To: Message from "ESTEFFERUD@USC-ECL" of Mon 5 Dec 83 22:01:00-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: [phone] (Stanford); [phone] (residence)

Well, one of the projects that is being started with the MM mailsystem
(including MMailr, the successor to XMailr) is a restructuring of the
code to implement the two-way model.  Perhaps it will also be rewritten
in a semi-highlevel "portable" language.
-------
 6-Dec-83 17:41:13-EST,1264;000000000000
Return-Path: <@CUCS20:uucp@Shasta>
Received: from CUCS20 by CU20B with DECnet; 6 Dec 83 17:41:09 EST
Received: from Shasta by COLUMBIA-20.ARPA with TCP; Tue 6 Dec 83 17:40:09-EST
Received: from decwrl by Shasta with UUCP; Tue, 6 Dec 83 14:38 PST
Date: Tuesday,  6 Dec 1983 14:18:21-PST
Sender: uucp@Shasta
From: decwrl!rhea!atfab!wyman@Shasta
Subject: Problem with VMS-KERMIT
Message-Id: <8312062235.AA16265@DECWRL>
Received: from RHEA.ARPA by DECWRL (3.327/4.09) 6 Dec 83 14:35:46 PST (Tue)
To: [e-mail]

I hate to mention bugs, when I don't have time to dig through
the sources and propose fixes right now, but I think people
should be warned that the current version of VMS-KERMIT seems
to have some problems when sending Print-Format files. It just
keeps sending packet after packet with no data... I found this
when transferring a .LOG file from VMS to Rainbow-KERMIT. The
.LOG file was 4 blocks long but accumulated a traffic of
about 800 packets before I cut it off. The problem is probably
related to the handling of VFC records.

        bob wyman

Point of procedure? Should bug reports go to INFO-KERMIT or to
the actual developer? If to the developer, how do I get his/her
mail address relative to the DECNET?
 6-Dec-83 17:54:35-EST,1274;000000000000
Return-Path: <@CUCS20:BRACKENRIDGE@USC-ISIB>
Received: from CUCS20 by CU20B with DECnet; 6 Dec 83 17:54:19 EST
Received: from USC-ISIB.ARPA by COLUMBIA-20.ARPA with TCP; Tue 6 Dec 83 17:45:39-EST
Date:  6 Dec 1983 1440-PST
Subject: Plea for 8bit mail
From: Billy <BRACKENRIDGE@USC-ISIB>
To: info-kermit@COLUMBIA-20

It looks from recent discussion that people are considering building
a mail service on top of the Kermit file transfer capability. I would
like to plead for real 8 bit mail.

I am working with LPC encoded voice which uses about 250 to 300 bytes
per second of recorded speech. I would like to send this as mail and
don't want to encode this as Hex or 6/8 packing. I don't mind a scheme
that requires that I send several Kermit files. For example I could
send a standard mail parcel that contains a 7bit ACSII text field
similar to "You have voice mail in the file FOO.BAR". I could then transfer
FOO.BAR in 8 bit format.

I understand that all of the Tops-20 sites store mail files as 7 bit ascii
and IBM mainframes do even more unmentionable things.

Currently Kermit is used for passing code and things like spreadsheet
data. It would be shame not to be able to pass these sorts of files off
to your friendly mail server.
-------
 6-Dec-83 18:07:21-EST,780;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 6 Dec 83 18:07:16 EST
Date: Tue 6 Dec 83 17:50:33-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: Problem with VMS-KERMIT
To: decwrl!rhea!atfab![e-mail], info-kermit@CUCS20
In-Reply-To: Message from "decwrl!rhea!atfab!wyman@Shasta" of Tue 6 Dec 83 17:40:19-EST

Point of procedure -- Since the traffic on Info-Kermit is relatively light,
it should be OK to send bug reports to the list in general.  That way, we're
all alerted to potential problems & pitfalls.  Many of the maintainers or
contributors participate in this mailing list and can respond.  Others, who
may not be on any kind of network at all, can be contacted by me, I guess.
- Frank
-------
 6-Dec-83 21:57:29-EST,3484;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 6 Dec 83 21:57:13 EST
Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Tue 6 Dec 83 21:56:11-EST
Date: Tue 6 Dec 83 18:54:08-PST
From: Mark Crispin <[e-mail]>
Subject: Re: Plea for 8bit mail
To: [e-mail]
cc: [e-mail]
In-Reply-To: Message from "Billy <BRACKENRIDGE@USC-ISIB>" of Tue 6 Dec 83 14:40:00-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: [phone] (Stanford); [phone] (residence)

     No!!  There should be a clear separation between the
concepts of:
 (1) text mail
 (2) multi-media mail
 (3) file transfer
 (4) spooled file transfer

     Of these, (2), (3), and (4) are typically 8-bit oriented,
generally because a common processor ISP involves allocating
memory in 8-bit bytes (making, of course, data atoms whose
magnitude is not a multiple of 8 awkward to use).  (1) on the
other hand has typically involved 7-bit ASCII, for a good number
of historical reasons.  The most important reason today is that
ASCII text is 7 bit; the eighth bit is for parity.

     Certain individuals have hit on the idea of using (1) to
implement (2), (3), and (4).  I suspect this is because a great
many people have well-tested well-debugged implementations of
(1).  That doesn't mean that it is anything other than a kludge
to do this!

     If you want file spooling or multi-media mail, the correct
thing to do is to develop new protocols that do this, not layer
them on top of old text-oriented protocols.

-- Mark --

PS: For those of you not familiar with the PDP-10 and/or TOPS-20,
the PDP-10 is a 36-bit processor with "soft" bytes; that is,
memory is addressed by 36-bit word and within each word the
program could use bytes of arbitrary size and position from 1 to
36 bits.  A set of instructions implement these soft bytes so the
programmer can load and deposit them without resorting to
shifting and masking.  Text files are traditionally stored on the
PDP-10 packed 5 7-bit bytes to a word; the extra bit is generally
unused.  Some PDP-10 operating systems (at least 5 exist) have
expanded characters beyond 7 bits, but have generally gone beyond
8 bits to 9, 12, or 18 bits.  This has received limited
application, because VAXen et al would have a impossible task in
coping with 9-bit data but can cope with 7-bit data reasonably
well.

     I strongly suggest to those of you who think that 8 bit
bytes (or some other power of 2, e.g. 32) is somehow wonderful
take a good look at the real applications out there.  It's a myth
that a word or byte size that's a power of 2 buys anything; in
fact, 32 bits makes for quite inadequate floating point and
equally inadequate pointers.  Data structures involving bytes
that do not correspond to the processor byte size are rather
awkward to work with.

     This isn't to say that "36 bits is better than 8 bits", but
rather to point out that not all applications today or tommorrow
are going to be oriented around 8 bits.  Consequently anything
that is going to be binary encoded should use a transport that is
bit-stream oriented (whether or not that bit-stream is encoded
within some flavor of bytes is irrelevant).  A flag day to make
text mail be 8 bits would have to be repeated all over again if
suddenly the industry decides to go with a 9 bit character set.
-------
 7-Dec-83 10:03:02-EST,1998;000000000000
Return-Path: <@CUCS20:OC.GARLAND@CU20B>
Received: from CUCS20 by CU20B with DECnet; 7 Dec 83 10:02:56 EST
Received: from CU20B by CUCS20 with DECnet; 7 Dec 83 10:02:09 EST
Date: Wed 7 Dec 83 10:01:32-EST
From: Richard Garland <OC.GARLAND@CU20B>
Subject: Lets not get carried away!
To: info-kermit@CUCS20
cc: OC.GARLAND@CU20B

Please forgive me if this sounds like flame but ...

I would like to give a general point of view as regards to 2 recent
points of discussion on this list:  the idea that Kermit and it's various
hosts store in some detailed way file characteristics (a'la ITS headers
only more), and the idea of layering some kind of Mail on top of kermit.

Kermit was created as a means to transfer data reliably between micros
and main-frames (the super-brain and the DEC-20 to be exact).  It caught
on and soon began to support lots of big and little systems.  However,
the initial design considerations (such as packet size, acknowledgement
scheme, flow control etc.) were oriented around small systems and low speed
lines.  Its popularity probably attests to its success in meeting its
goals (to say nothing of the fact that it is free).

Now when people say "well I'm thinking of connecting my 2 Cybers with
Kermit and do you think ....", or "Well I don't know if SMTP or UUCP
is the right MAIL scheme for Kermit ..." or "I'm thinking of how Kermit
can reversably download/upload my IBM VSAM datasets to my Apple ...",
I say - hey wait a minute, Kermit is not the end of the world!  Lets get
it to do what it's designed to do real well and on as many systems as
possible and not try to solve all the worlds problems with it!

I would rather see effort put for a SIMPLE and RELIABLE version on
all the systems I use (and anyone else uses) and forget the blue
sky.

If I want to connect my DEC-20's I use DECnet or TCP/IP.  If I want
MAIL I call up my DEC-20 or VAX and read it.  If I want a file on
my Rainbow, I use kermit.

                    Rg
-------
 7-Dec-83 10:42:31-EST,1009;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 7 Dec 83 10:42:18 EST
Date: Wed 7 Dec 83 10:41:23-EST
From: Bob Cattani <CATTANI@CUCS20>
Subject: Re: Lets not get carried away!
To: info-kermit@CUCS20
In-Reply-To: Message from "Richard Garland <OC.GARLAND@CU20B>" of Wed 7 Dec 83 10:02:27-EST

My feelings about some of the proposed expansions to Kermit closely
parallel Rich Garland's.  As far as I'm concerned, Kermit has a place
and it has performed well in that place.  Let's not try to build things
into it that most systems can do just as well without.

If someone needs mail on their computer, let's handle that problem
separately.  What Frank suggested ("isolate the transport-level
functions into a library that could be shared by KERMIT and the mail
system") sounds to me like a more proper way of doing it.  This way,
people who don't need mail, file attributes, etc. won't get what to them
would just be excess baggage.
-Bob Cattani
-------
 7-Dec-83 13:23:59-EST,2054;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 7 Dec 83 13:23:43 EST
Date: Wed 7 Dec 83 13:18:21-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Kermit for Victor 9000
To: Info-Kermit@CUCS20

This is to announce the possible arrival of KERMIT-86 for the Sirius 1,
aka Victor 9000.  There are two versions, one for CP/M-86, another for MS DOS.
The programs arrived on a tape in undecipherable format, which I had to dump
bit-for-bit and then pick apart by hand, removing periodic chunks of imbedded
garbage.  I hope I didn't remove anything that wasn't garbage (I was careful),
and didn't miss anything that was.

These two programs are adaptations of IBM PC Kermit as it existed in May 1983
(edit 13), i.e. before the interrupt-drive i/o was added, terminal emulation
improved, various minor bugs fixed, etc.  The MS DOS support could conceivably
be merged into the current (better still, next -- announcement forthcoming)
release of IBM PC Kermit, and the CP/M-86 support integrated with the new
Rainbow CP/M-86 Kermit.  However, since we don't have any Victor machines to
test them on at Columbia (at least not yet), we're making these programs
available as they are for the benefit (?) of anyone who does.

The programs were supplied in source form only -- no binaries or hex.  It would
be greatly appreciated if someone who has a Victor could download the
appropriate source program (do Victors have a way to do this?  MODEM?  Some
proprietary or vendor-supplied package?), try it out, create a hex (or IBM
PC Kermit-style .FIX) file and make it available, along with any reactions
about if and how well the program works.

The files are available via anonymous FTP from host COLUMBIA-20, as KER:VIC*.*.
KER:VICTOR.DOC is a short message explaining the changes he made to support the
Victor.  KER:VICMSDOS.ASM is the MS DOS version, KER:VICCPM.A86 is the CP/M-86
version.

Thanks to Barry Devlin, University College Dublin (Ireland), for the
contribution.

- Frank
-------
 7-Dec-83 19:37:50-EST,575;000000000000
Return-Path: <@CUCS20:CERRITOS@USC-ECL>
Received: from CUCS20 by CU20B with DECnet; 7 Dec 83 19:37:41 EST
Received: from USC-ECL by COLUMBIA-20.ARPA with TCP; Wed 7 Dec 83 19:36:14-EST
Date:  7 Dec 1983 1433-PST
From: Bruce Tanner <CERRITOS%USC-ECL@MINET-CPO-EM>
Subject: Osborne Executive
To: INFO-KERMIT@COLUMBIA-20

Is there anyone out there who has Kermit running on an Osborne Executive
under CP/M Plus?  I've had people tell me it doesn't work.  If you have
it working or know of someone who has, would you let me know the details?
Thanks,
-Bruce
-------
 8-Dec-83 06:03:36-EST,714;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 8 Dec 83 06:03:34 EST
Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Thu 8 Dec 83 06:02:40-EST
Date: 8 Dec 83 06:02:23 EST
From: Hobbit <[e-mail]>
Subject: Kermit suggestions
To: [e-mail]

How about an interrupt character that will *cleanly* abort a transfer?
And, if one is going to support the FINISH command on one machine,
when does it come to the rest?  I speak here of Kermiting between VMS
Vaxes and 20's.  I can shut down the Vax server from the 20, but not
the other way round.  Leads to some interesting ways of getting
wedged sometimes....

_H*
-------
 8-Dec-83 19:13:56-EST,3230;000000000000
Return-Path: <@CUCS20:OC.BUSH@CU20B>
Received: from CUCS20 by CU20B with DECnet; 8 Dec 83 19:13:52 EST
Received: from CU20B by CUCS20 with DECnet; 8 Dec 83 19:12:46 EST
Date: Thu 8 Dec 83 19:13:04-EST
From: Nick Bush <OC.BUSH@CU20B>
Subject: Re: Lets not get carried away!
To: OC.GARLAND@CU20B
cc: info-kermit@CUCS20
In-Reply-To: Message from "Richard Garland <OC.GARLAND@CU20B>" of Wed 7 Dec 83 10:03:11-EST

The reason I suggested the storing of attributes for a file in such a way
that the file will be reversibly stored is due to the need to be able
to store files from micros on a mainframe and get them back when needed.
The problem we have which prompted the suggestion is due to the file
system used on the DEC Pro-3xx's under P/OS.  In order to be able to
store executable programs for a P/OS system on a DECsystem-10 or
DECSYSTEM-20, there needs to be some way of storing the attributes
of the file as it appears on the P/OS system.  Also, in order to be
able to move a task image (executable program) from a VMS system (where
it may have been generated by DEC's cross compiler(s) and linker) to
a P/OS system, the same attributes are needed, however in this case
it is coming from a file system which does store those attributes.
Until the idea of the file attributes packet was suggested, we were
considering implementing a "FILE-TYPE" in both VMS Kermit and Pro-Kermit
that would cause the Kermit to send (and recognize when receiving a file)
a short header which contained the necessary attributes.  This header
would be sent as part of the data, not as a separate type of packet.
Therefore, Kermit's which did not know about the header (or had not
been told to look for it) would just store it in the file, and would
therefore send it out when asked to transmit the file.  This would have
made the transfer reversible without any need for support from any
other Kermit.  However, since the attributes packet was added, it
made us reconsider the problem.  If we are to support the attributes
packet (which would solve the problem of transfer between VMS and P/OS),
we need some way to store the information when the destination file
system does not store the same attributes as Files-11.  It would
seem that the only alternative (assuming the need to use the attributes
packet) is to teach Kermit's how to store the attributes their file
system doesn't know about.

I don't know that it is really a very good idea to use the attributes
packet in this way.  Perhaps we should just go back to our original
idea of how to transmit the attributes we need to.  In some ways
I like that idea better (means less work for me in Kermit-10), but
it seems contrary to the idea that is embodied in an attributes packet.

Overall, the question seems to be whether Kermit is intended for transferring
files between systems such that they are usable on both systems, or
so that one system may be used as a file store (backup medium, whatever)
for the other.  People are using Kermit for both purposes, and will
continue to do so.  We need a method of handling file systems which
require a little more information than the simple ones Kermit started out
with.

- Nick
-------
 8-Dec-83 19:27:36-EST,1416;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 8 Dec 83 19:27:31 EST
Date: Thu 8 Dec 83 19:14:02-EST
From: Nick Bush <G.BUSH@CUCS20>
Subject: Re: Kermit suggestions
To: [e-mail]
cc: info-Kermit@CUCS20

There currently is an interrupt character which will abort a transfer.
In fact, there are two different options - abort only the current file,
or abort the entire group (if wildcards are being used).  This
is implemented in the newest versions of Kermit-20, VMS Kermit, Kermit-10
and CP/M Kermit-80.  A control-X typed while a transfer is in progress
will cause the current file to be aborted, skipping to the next file if
a wildcard transfer is in progress.  A control-Z will cause the current
file to be aborted and the wildcard transfer to act like it ran out of
files.  If you are using the latest versions of these Kermit's, this will
work regardless of which direction the file transfer is going.  If
you only using a version which supports this on the local side (the side
which owns a physical terminal), you can abort files being sent, but not
those being received.

The latest version of VMS Kermit also supports giving commands to a
server Kermit (FINISH, BYE, LOGOUT, and GET).  The latest versions of
all of these Kermits are available via ANONYMOUS FTP from Columbia-20
on the directory KER: (PS:<KERMIT>).

- Nick
-------
 8-Dec-83 20:26:37-EST,2090;000000000000
Return-Path: <@CUCS20:uucp@Shasta>
Received: from CUCS20 by CU20B with DECnet; 8 Dec 83 20:26:34 EST
Received: from Shasta by COLUMBIA-20.ARPA with TCP; Thu 8 Dec 83 20:25:28-EST
Received: from decwrl by Shasta with UUCP; Thu, 8 Dec 83 17:23 PST
Date: Wednesday,  7 Dec 1983 12:21:22-PST
Sender: uucp@Shasta
From: decwrl!rhea!atfab!wyman@Shasta
Subject: re: Plea for 8-bit mail
Message-Id: <8312090108.AA15720@DECWRL>
Received: from RHEA.ARPA by DECWRL (3.327/4.09) 8 Dec 83 17:08:28 PST (Thu)
To: wyman@Shasta, Shasta![e-mail]

In re: Plea for 8-bit mail.

It was suggested that 8-bits would be inappropriate for use in
text based mail systems... Some comments were made about the
specifics of the TOPS-10/-20 environment..

While it may be difficult for some systems to handle 8-bit mail,
it is very important for us all to recognize that there is a
clear and certain trend towards both 8 and eventually 16 bit
characters. Digital, for instance, has recently created a DEC
Multinational Character Set Standard which uses all 8 bits. This
character set is destined to be supported over time by all DEC
hardware and operating systems. Initial support will come in the
VT2xx family of terminals.

8-bit support is also necessary if one wishes to exchange mail
with the folks in other countries (ie: Europe, Canada).

While KERMIT itself probably won't be used to connect to foreign
countries (there are legal issues involved), any KERMIT based
mail services should avoid being defined in such a manner that
KERMIT will not be useful in the context of a world-wide mail
network.

Because there are a number of 8-bit character sets outstanding,
the important question should not be whether 8-bit is supported
but rather which 8-bit encoding should be KERMIT default. There
should also be consideration of whether character set translation
is appropriate and/or achievable.

I'm prejudiced of course, working for DEC... I would suggest that
the DEC Multinational set be the KERMIT 8-bit default.

        bob wyman

 8-Dec-83 20:57:48-EST,930;000000000000
Return-Path: <@CUCS20:louie@cvl>
Received: from CUCS20 by CU20B with DECnet; 8 Dec 83 20:57:45 EST
Received: from cvl by COLUMBIA-20.ARPA with TCP; Thu 8 Dec 83 20:56:43-EST
Date: 8 Dec 1983 20:59:28-EST
From: Louis A Mamakos <louie@cvl>
Reply-to: louie@cvl
To: [e-mail]
Subject: Re: Plea for 8 bit mail

I think this can get out of hand...  Sure there is a trend to move to 8 bit
character data, but there are vendors that use more than 8 bits already;
Sperry Univac uses 18 bit for 18 bits for its Japanese character sets.
Where will it all stop?


        Louis A. Mamakos

    Internet:  [e-mail]
    CSNet:     louie.cvl@umcp-cs
    uucp:      ..!{seismo,we13,mcnc}!rlgvax!cvl!louie
        phone:     [phone]
        Snail Mail:
                   Computer Science Center - Systems Staff
                   University of Maryland
                   College Park, MD   20742
 9-Dec-83 10:52:11-EST,2643;000000000000
Return-Path: <@CUCS20:knutson@utexas-11>
Received: from CUCS20 by CU20B with DECnet; 9 Dec 83 10:52:01 EST
Received: from UT-NGP.ARPA by COLUMBIA-20.ARPA with TCP; Fri 9 Dec 83 10:50:31-EST
Date: 9 Dec 83 09:50:50 CST (Fri)
From: Jim Knutson <[e-mail]>
Subject: Re: Lets not get carried away!
Posted-Date: 9 Dec 83 09:50:50 CST (Fri)
Message-Id: <[e-mail]>
Received: by UT-NGP.ARPA (3.326/3.7)
    id AA27997; 9 Dec 83 09:50:50 CST (Fri)
To: [e-mail]

Let's look at what we want.  First and foremost, Kermit should be a file
transfer program.  We would like it to not only transfer files but allow
us to use its capabilities to store files on other machines.  These are
two very different things!

Now this leads us to the following conclusions:
1. For transfers between like machines (compatible machine/opsys),
   we probably want exactly what we started out with.  Sort of like
   copying a file on that machine.

2. For transfers between different machines we have:
   a) Text file transfers.  What you see on one machine is what you
      want to see on the other.
   b) Binary transfers.  This should only be usefully for downloading
      cross-compiled programs.  Usually binary executables are useless
      on different machines.  Perhaps this should be called down-load
      transfers.
   c) Store-forward transfers.  Perhaps this is what we really want
      from binary transfers.  The file is not meant to be used on the
      destination, just stored.  Here we want to get back exactly what
      we sent.

How do we accomplish this?
For item number 1, two different kermits need to know if they are compatible.
This could be accomplished through commands, flags, or swithces to the
Kermit program or with parameters to the send-init negotiation.  To accomplish
a copy of a file, we need the originators attributes and the data.

For text transfers, all we need is the data.  No attributes.  Why bother?  The
file is on a foreign system where none of the attributes are likely to have
anything to do with the originators attributes.

Downloading is similar to storing-forward except that instead of storing
the file for later retrieval it is setup to be used on the destination system.

Storing-forward is what needs work.  I suggest that we define some format for
storage such as originators file name, attribute header, data field.  Kermit
should also be modified to distiguish between the different types of transfers.
--
Jim Knutson
ARPA: knutson@ut-ngp
UUCP: {ihnp4,seismo,kpno,ctvax}!ut-sally!ut-ngp!knutson


 9-Dec-83 13:28:20-EST,499;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 9 Dec 83 13:28:14 EST
Date: Fri 9 Dec 83 13:25:59-EST
From: Daphne Tzoar <CC.DAPHNE@CUCS20>
Subject: Re: Kermit suggestions
To: [e-mail]
cc: info-Kermit@CUCS20
In-Reply-To: Message from "Hobbit <[e-mail]>" of Thu 8 Dec 83 06:02:23-EST

The next release of PC Kermit will also support cleanly aborting
the transfer of the current file (^X) or file group (^Z).
/daphne
-------
 9-Dec-83 15:14:35-EST,2535;000000000000
Return-Path: <@CUCS20:Kincl%HP-HULK.HP-Labs@Rand-Relay>
Received: from CUCS20 by CU20B with DECnet; 9 Dec 83 15:14:20 EST
Received: from rand-relay.ARPA by COLUMBIA-20.ARPA with TCP; Fri 9 Dec 83 15:12:44-EST
Date: Fri 9 Dec 83 10:31:21-PST
From: Norm Kincl <Kincl.HP-HULK@Rand-Relay>
Return-Path: <Kincl%HP-HULK.HP-Labs@Rand-Relay>
Subject: Re: Lets not get carried away!
Received: by HP-VENUS via CHAOSNET; 9 Dec 1983 10:31:45-PST
To: info-kermit@COLUMBIA-20, @, Kincl%HP-VENUS.HP-LABS@Rand-Relay
In-Reply-To: Message from "Jim Knutson <knutson@utexas-11>" of Fri 9 Dec 83 09:50:50-PST
Message-Id: <439842706.8390.hplabs@HP-VENUS>
Via:  HP-Labs; 9 Dec 83 11:57-PST

It seems like what you want is something like this:

1. If no file attribute packet is sent, keep things just as they are
now.

2. If a file attribute packet is sent, then there are two possibilities
 a.  The receiving system handles that type of file.  In this case, just
 save it as is.  For example, a VMS system receiving a file from a Pro
 with attribute Files-11 can just save it as a Files-11 file.

 b.  The receiving system does not handle it.  (eg. TOPS-20 receiving a Pro
 Files-11 file).  The receiving system should then be allowed to either
  i. reject the file with a "can't accept this type of file" packet

  ii. store the packet in some operating system dependent way.  This may
  involve pre-pending a sixbit FILES11 to the file, marking some
  user-defined field in the file descriptor, or whatever.  It should be
  up to the operating system to decide how to best do this.  The only
  requirement should be that if the file is sent via Kermit someplace
  else, the original format of the file will be preserved.  This would
  include both the same attribute packet and data as was originally
  sent.  Using this, I could transfer a file from a Pro to a Multics
  system to an IBM to a TOPS-20 to a VMS system and back to a Pro and it
  would end up unchanged.

Implementing something like this in the protocol will take the
responsibility of deciding HOW to store a file away from the file
transfer protocol where it has no business being.  My operating system
that I write some day may have a comment field associated with each file
where I can easily put a DSK8 comment instead of a kludge involving the
data in the first 13 bytes of the file being some special combination of
cryptic bits.  Put the work where it belongs.

-Norm Kincl
HP Labs
Internet: [e-mail]
-------

 9-Dec-83 17:43:06-EST,3836;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 9 Dec 83 17:42:58 EST
Date: Fri 9 Dec 83 17:41:56-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Preserving file attributes, cont'd
To: Info-Kermit@CUCS20

Without going into any great detail (yet), I think we need to differentiate
between sending a file to be used and sending a file to be archived for later
retrieval.  To do this, the attributes packet "disposition" field would have an
"archive" parameter.  In its absence, the receving system would try to store
the file in usable form.  In its presence, the receiver would store the
attribute packet itself along with the file's contents.  For archiving, a new
command be added to KERMIT -- "ARCHIVE".  This would be just like SEND, except
the attributes packet would specify archiving.

When a file is archived, there should be some indicator to distinguish it from
an ordinary file.  Preferably, this would be something outside the file.
Fancy file systems may have some user-definable directory entry fields which
would be perfect for this use, like the TOPS-20 "user settable word" (.FBUSW).
Other less desirable conventions could also be used, like funny protection
codes, modes, special file types, etc.  Only as a last resort should the
indicator be put in the file itself, because there's always the chance that an
ordinary file's data could start with the same sequence.

In cases where the archive status of a file could not be accurately determined
by its sender, there should be an "UNARCHIVE" command to direct that the file
be treated as archived, and to send out the attribute information in attribute
packets rather than as data.  In addition (and this would require a new packet
type) there could be a "RETRIEVE" command, which would send a message to a
KERMIT server to "unarchive" the specified file(s).

When an archived file is sent out, the receiver should be able to decide
whether to "unarchive" it.  For this, the archive information should contain a
code indicating the machine and operating system of origin.  Thus if I send my
FILES11 file to a CP/M system and from there to a MULTICS system, the MULTICS
system should know not to try to interpret the attributes, but rather, to
re-archive them.  In this way, an archived file could float around among all
kinds of systems until it finally found its way back to one that understood its
original file structure and could "unarchive it".

All this depends, of course, on the support for the attributes packet and the
archiving mechanism on each system involved.  Any that don't support these
concepts would operate as KERMITs do now.

An issue still open is how an archived file should be stored.  Since it is not
being sent for use, why not store it in the most compact way possible?  A
simple way to achieve compaction would be to not expand KERMIT repeat-prefixed
sequences, and to indicate in the attributes what the repeat prefix was, so
that the file could be properly expanded upon retrieval.

All this sounds like pie in the sky, and it probably is.  But the whole idea is
necessary when trying to adapt KERMIT to systems whose files are not strictly
sequential streams of bytes.  FILES11 is one example.  Another, perhaps more
demanding one, would be IBM VM/CMS VB-Format binary files (such as executable
modules), where record boundaries of varying length records must be preserved.
The attributes mechanism takes care of this nicely by allowing for file type
"D", where records are each preceded by a length field.  An extension of this
idea could apply to sparsely populated random-access files.  Still, even if we
settle any of these issues, it remains to be seen whether they'll ever find
their way into a KERMIT program...

- Frank
-------
10-Dec-83 17:18:13-EST,834;000000000000
Return-Path: <@CUCS20:iam@cmu-cs-g>
Received: from CUCS20 by CU20B with DECnet; 10 Dec 83 17:18:09 EST
Received: from CMU-CS-G by COLUMBIA-20.ARPA with TCP; Sat 10 Dec 83 17:16:42-EST
Date: 10 Dec 1983 17:05-EST
From: [e-mail]
Subject: VT52 emulation on CPM-APPLE-KERMIT
To: INFO-KERMIT@CUCS20
Message-Id: <439941956/iam@CMU-CS-G>

Will the Kermit program that runs under Apple-CPM using the Hayes micromodem
II emulate a VT52 or a VT100 on a VAX or DEC20?

I already have a terminal program that does file transfer reasonably well
but doesn't allow the necessary cursor control to use the emacs screen
editor.

If the Kermit program does emulate a VT52, what files need to be transfered
and what steps need to be taken in order to get it up and running on my
Apple?

Thanks

--Ira Monarch

11-Dec-83 02:22:36-EST,1247;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 11 Dec 83 02:22:32 EST
Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Sun 11 Dec 83 02:21:35-EST
Date: Sat 10 Dec 83 23:20:51-PST
From: Carl Fussell <[e-mail]>
Subject: Re: Preserving file attributes, cont'd
To: [e-mail]
cc: [e-mail]
In-Reply-To: Message from "Frank da Cruz <[e-mail]>" of Fri 9 Dec 83 16:03:40-PST
Address:  Santa Clara University


This is just a comment on Frank da Cruz's archive/unarchive suggestions.
I think the description outlined is quite good, in particular, the idea
that an archived file be allowed "float" among systems freely until
finding one understanding it.

My main comment (criticism?) is the idea of using directory "user
settable words" in the implementation of future kermits.  As a site
(DECSystem 20) that already takes advantage of this feature for site
dependent things (and I doubt we are unique), it would deny us the
use of the newer versions that become available.   Although I haven't
an alternative to suggest at this point, I would hope that another
mechanism could be decided upon.

. Carl
-------
11-Dec-83 13:01:16-EST,1011;000000000000
Return-Path: <@CUCS20:KLOTZ@MIT-MC>
Received: from CUCS20 by CU20B with DECnet; 11 Dec 83 13:01:13 EST
Received: from MIT-MC by COLUMBIA-20.ARPA with TCP; Sun 11 Dec 83 13:00:06-EST
Date: 11 December 1983 12:56 EST
From: Leigh L. Klotz <KLOTZ @ MIT-MC>
Subject: Retaining file attributes on various systems
To: info-kermit @ COLUMBIA-20

Pardon my ignorance, but why don't you just implement a means for
storing file attributes on top of whatever system you're using, be
it CP/M or ITS.  Make a Kermit "directory" file containing filenames
and info about files Kermit has received or wants to transmit.

This approach solves the problem of separating the format info from the
file contents, while still allowing files to float freely among systems,
provided the Kermit transfer protocol does a lookup of the format
information from the directory file before sending it.

It seems to me if you really want system independent user-settable
words, you might as well implement them.

Leigh.

12-Dec-83 00:49:31-EST,1173;000000000000
Return-Path: <@CUCS20:uucp@Shasta>
Received: from CUCS20 by CU20B with DECnet; 12 Dec 83 00:49:27 EST
Received: from Shasta by COLUMBIA-20.ARPA with TCP; Mon 12 Dec 83 00:48:08-EST
Received: from decwrl by Shasta with UUCP; Sun, 11 Dec 83 21:47 PST
Date: Sunday, 11 Dec 1983 21:14:59-PST
Sender: uucp@Shasta
From: decwrl!rhea!atfab!wyman@Shasta
Subject: Re: Plea for 8-bit
Message-Id: <8312120536.AA19012@DECWRL>
Received: from RHEA.ARPA by DECWRL (3.327/4.09) 11 Dec 83 21:36:53 PST (Sun)
To: Shasta![e-mail]

The Japanese Character sets are clearly defined in JIS-1 and JIS-2.
These are "Japanese Industrial Standard"s which define a 16-bit
character set which includes KANJI, KATAKANA, ROMANJI and a number
of "technical characters". Also, there is no problem with handling
the JIS-1/-2 characters with KERMIT!! Just as a test, I did it
tonight. The 16-bit characters move like quoted 8-bit characters,
and with the proper "shift-handling" it's still easy to get through
the normal "ROMANJI" characters which are essentially ASCII.
PLEASE-- let's not let Japanese worry us here. The question is
8-bits -- not 16!

        bob wyman
13-Dec-83 14:20:15-EST,2948;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 13 Dec 83 14:20:08 EST
Date: Tue 13 Dec 83 14:13:42-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New release of CP/M-80 KERMIT
To: Info-Kermit@CUCS20
cc: [e-mail]

Announcing a new release of KERMIT-80, which provides file transfer and
terminal emulation for CP/M-80 systems.  This release is version 3.6; it has no
new functionality over version 3.5, but several major bugs have been fixed.
These include:

 Cursor addressing errors fixed for various systems.

 During terminal emulation, some systems (the Kaypro II, for instance) would
  output nulls continuously.  This has been fixed.

Thanks to James Grossen at the University of Tennessee at Knoxville for these
fixes.  Users of CP/M Kermit are encouraged to get the new .HEX files (using
their current versions of Kermit), LOAD them, and try them out.  If you do
this, please let me know which system you tried, whether it worked, and if not,
what went wrong.

The .HEX files are available in KER:CPM*.HEX via anonymous FTP from host
COLUMBIA-20.  The systems supported, and the corresponding files, are:

 CPMAPPLE.HEX    Apple II with Z80 SoftCard, DC Hayes MicroModem II
 CPMBRAIN.HEX    Intertec SuperBrain
 CPMDMII.HEX    DECmate II with CP/M option
 CPMGENERI.HEX    "Generic" CP/M-80 version 2.x
 CPMHEATH.HEX    Heath/Zenith 89
 CPMKAYPRO.HEX    Kaypro II
 CPMOSBORN.HEX    Osborne 1
 CPMOSI.HEX    Ohio Scientific
 CPMPLUS.HEX    "Generic" CP/M-80 version 3.0 (CP/M Plus)
 CPMRAINBO.HEX    DEC Rainbow-100, CP/M-80 (Z80 side)
 CPMROBIN.HEX    DEC VT180 "Robin"
 CPMTELCON.HEX    Telcon Zorba
 CPMTRS80.HEX    TRS-80 Model II with CP/M
 CPMVECTOR.HEX    Vector Graphics
 CPMZ100.HEX    Heath/Zenith Z100, CP/M-80 (Z80 side)

 CPMBASE.M80    The single source file for all the above.
 CPMBASE.DIF    Source differences from version 3.5.

There are also various associated .DOC and .HLP files.

KERMIT implementations are also available for many other systems, both micros
and mainframes.  To get an idea of what's available, see the file
KER:00README.TXT.

Those of you who have been using KERMIT-80 version 3.2 or earlier are
encouraged to try out this new release -- in incorporates many new features,
including built-in DIR and ERA commands, a way for switching and logging in
disks, improved wildcard facilities, etc.

Since we do not have examples at Columbia of more than a couple of the systems
listed above, I would be very grateful to anyone who could report to me about
their success or lack thereof in running this new version of KERMIT-80.
In the meantime, an entirely new (and radically different) release of KERMIT-80
is in preparation.  It is expected that this new version will require
considerable testing, so it is very desirable to stabilize the present version.
Your reports will be of great help in doing this.

- Frank da Cruz (Columbia U)
-------
13-Dec-83 19:15:42-EST,1730;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 13 Dec 83 19:15:33 EST
Date: Tue 13 Dec 83 19:12:54-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New KERMIT-20 available
To: Info-Kermit@CUCS20

KERMIT-20 version 3C(133) is available for testing.  There are two changes
since version 3B was announced not too long ago:

1. 8th-bit-prefixing will now be done when requested.  It can be requested:
   a. Explicitly via the SET EIGHTH-BIT-PREFIX command;
   b. Explicitly by the other side in the Send-Init packet;
   c. Implicitly if you SET PARITY to anything other than NONE.

   8th-bit-prefixing allows 8-bit binary data to be sent through a 7-bit
   communication link, such as one that uses parity (examples are TELENET,
   which uses MARK parity, and IBM mainframes, which typically use MARK,
   ODD, or EVEN parity).  The prefixing method is costly in transmission
   overhead, so KERMIT-20 will not use it unless asked to.  Even then, the
   KERMIT on the other side must also know how do do this.  Presently, only
   VAX/VMS and TOPS-10 KERMITs fall in this category, with others soon to
   come (including IBM PC and Apple DOS).

2. Whenever a timeout occurs, KERMIT-20 will clear any XOFF condition on the
   communication line, and transmit an XON.  This will overcome any deadlocks
   that might occur when an XOFF is spontaneously generated on a noisy line,
   and both sides are doing XON/XOFF flow control (as KERMIT-20 does during
   file transfer).

Report any problems to me.  Next comes repeat-count processing.  - Frank

P.S.  The relevant files are in KER:20KERMIT.* at host COLUMBIA-20, accessible
 as always via anonymous FTP.
-------
14-Dec-83 15:17:09-EST,1027;000000000000
Return-Path: <@CUCS20:jalbers@BNL>
Received: from CUCS20 by CU20B with DECnet; 14 Dec 83 15:16:48 EST
Received: from BNL by COLUMBIA-20.ARPA with TCP; Wed 14 Dec 83 15:13:45-EST
Date: 14-Dec-83 14:28:15-EST
From: jalbers@BNL
Subject: Latest version of Kermit
To: cc-fdc@COLUMBIA-20, info-kermit@COLUMBIA-20

Frank, and all:

       The latest version of Kermit works with the OCC-EXEC 1.  I would like to
 know the changes between this and the last.  The last version would not allow
 the PIA time to turn on the communications port's incoming buffer, so instead
 of connecting up to the modem port like it should, the PIA threw up and died,
 making it necessary to reset the osborne.  I don't know how the PIA controlls
 the buffer, but there should be a way to make it either ignore it, or keep it
 on all the time.

      Thanks to those who got this latest version out!

                                                   Jon Albers
                                                   jalbers@bnl


14-Dec-83 16:46:43-EST,1270;000000000000
Return-Path: <@CUCS20:MCNULTY%UCI-20a.UCI@Rand-Relay>
Received: from CUCS20 by CU20B with DECnet; 14 Dec 83 16:46:31 EST
Received: from rand-relay.ARPA by COLUMBIA-20.ARPA with TCP; Wed 14 Dec 83 16:42:48-EST
Date: 14 Dec 1983 1216-PST
From: Dale M. McNulty <MCNULTY.UCI-20A@Rand-Relay>
Return-Path: <MCNULTY%UCI-20a.UCI@Rand-Relay>
Subject: KERMIT for Atari800
To: INFO-KERMIT.UCI-20A@Rand-Relay
Cc: mcnulty.UCI-20A@Rand-Relay
Received: from UCI-20a by UCI-750a; 14 Dec 83 12:28:16 PST (Wed)
Via:  UCI; 14 Dec 83 12:51-PST

Is there a version of KERMIT for the Atari 800?

If so, how can I get a copy?

If not, is it possible to modify a version of KERMIT so that
it will run on the Atari 800? This last question seems to
imply that either:
    1.Source KERMIT is available on the DEC 2020, DEC 10,
      or VAX 750 (since I have immediate access to these).
        a.Atari cross assembler available on one of the
          above.
    or
    2.Source KERMIT available on Atari (or a listing available
      for hand entry). This, in turn, implies that the source be
      in Atari/6502 assembler, macro assembler, or translatable
      to one of these.

Please, send replies to: Dale McNulty <MCNULTY.UCI@RAND-RELAY>.
Thanks for any help you can provide.

Dale McNulty
14-Dec-83 18:57:40-EST,1203;000000000000
Return-Path: <@CUCS20:CC.FDC%COLUMBIA-20%UCI-20a.UCI@Rand-Relay>
Received: from CUCS20 by CU20B with DECnet; 14 Dec 83 18:57:30 EST
Received: from rand-relay.ARPA by COLUMBIA-20.ARPA with TCP; Wed 14 Dec 83 18:54:39-EST
Date: Wed 14 Dec 83 16:53:08-EST
From: Frank da Cruz <cc.fdc@COLUMBIA-20>
Return-Path: <CC.FDC%COLUMBIA-20%UCI-20a.UCI@Rand-Relay>
Subject: Re: KERMIT for Atari800
Received: from COLUMBIA-20.ARPA by rand-relay.ARPA ; 14 Dec 83 13:58:28 PST (Wed)
To: MCNULTY.UCI-20A@RAND-RELAY, INFO-KERMIT.UCI-20A@RAND-RELAY
In-Reply-To: Message from "Dale M. McNulty <MCNULTY.UCI-20A@Rand-Relay>" of Wed 14 Dec 83 15:16:00-EST
Received: from Rand-Relay by UCI-750a; 14 Dec 83 14:08:15 PST (Wed)
Received: from Uci-750a by UCI-20A; Wednesday, 14 Dec 83 14:36:32 PST
Received: from UCI-20a by UCI-750a; 14 Dec 83 15:07:24 PST (Wed)
Via:  UCI; 14 Dec 83 15:14-PST

John Palevich of Atari is working on a KERMIT for Atari machines (on his
own time).  If you want to contact him about what progress he's made,
you can mail to palevich%atari.Atari@Rand-Relay (or something like that;
I think CSnet may have changed its routing since I last corresponded
with him).  - Frank
-------

14-Dec-83 19:09:35-EST,1161;000000000000
Return-Path: <@CUCS20:MRC%SU-SCORE%UCI-20a.UCI@Rand-Relay>
Received: from CUCS20 by CU20B with DECnet; 14 Dec 83 19:09:25 EST
Received: from rand-relay.ARPA by COLUMBIA-20.ARPA with TCP; Wed 14 Dec 83 18:54:58-EST
Date: Wed 14 Dec 83 14:22:10-PST
From: Mark Crispin <MRC@SU-SCORE>
Return-Path: <MRC%SU-SCORE%UCI-20a.UCI@Rand-Relay>
Subject: Re: KERMIT for Atari800
Received: from SU-SCORE.ARPA by rand-relay.ARPA ; 14 Dec 83 14:23:13 PST (Wed)
To: MCNULTY.UCI-20A@RAND-RELAY
Cc: INFO-KERMIT.UCI-20A@RAND-RELAY
In-Reply-To: Message from "Dale M. McNulty <MCNULTY.UCI-20A@Rand-Relay>" of Wed 14 Dec 83 12:16:00-PST
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: [phone] (Stanford); [phone] (residence)
Received: from Rand-Relay by UCI-750a; 14 Dec 83 14:33:19 PST (Wed)
Received: from Uci-750a by UCI-20A; Wednesday, 14 Dec 83 15:08:16 PST
Received: from UCI-20a by UCI-750a; 14 Dec 83 15:36:13 PST (Wed)
Via:  UCI; 14 Dec 83 15:38-PST

Yes, Jack Palevich has written an Atari KERMIT in the ACTION!
programming language.  If you have ACTION!, the source files are
on PS:<G.TANG>K*.* on Score.
-------

15-Dec-83 12:49:51-EST,2357;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 15 Dec 83 12:49:31 EST
Date: Thu 15 Dec 83 12:44:16-EST
From: Daphne Tzoar <CC.DAPHNE@CUCS20>
Subject: IBM PC Kermit Announcements
To: info-kermit@CUCS20, [e-mail]

A new version of PC KERMIT, version 1.20, is now available for testing.
Some additions made to the current version (v1.18) include:

   -  Allow ^X/^Z to interrupt sending/receiving a file or file group,
      respectively.

   -  If get an error when receiving a file, clean up and send an error
      packet.  Allow user to specify whether to keep what made it over
      or to discard it.

   -  Add U. of Arizona changes so Kermit once again compiles on the
      Z100 (Joellen Windsor).  Move IBM specific statements inside
      IBM conditional assembly blocks.

   -  Print packet and retry numbers in decimal instead of hex.

   -  Allow users to choose between COM1 (default) and COM2.  Also,
      remind the user about which communications port they are using
      and at what baud rate when connecting to another system.

   -  Add SET BACKARROW so can set backarrow to backspace or delete.
      (William Dair)  And, set default to ON for renaming files due
      to filename conflicts.  Change VT52 emulation messages to
      Heath-19 since that's what Kermit-86 emulates.

Please report any bugs to Sy.Daphne@CU20B or CC.Daphne@Columbia-20.
Users with Z100's are encouraged to try the test version as we are
not sure all the Z100 compilation problems were fixed.

The files are located in a publicly accessible directory on
Columbia-20 called Kermit, logically defined as KER:.  The relevant
files are PCKERM20.ASM, PCKERM20.HLP, and PCKERM20.FIX (the
printable version of the .EXE file.)  To get a working copy of
Kermit for the IBM PC or the Z100 (running MS DOS), copy the FIX
file to the PC and run the BASIC program PCKEXE.BAS or use the
bootstrapping programs PCKSEND.FOR and PCKGET.BAS.  For more
information, see the Kermit User's Guide (USER.DOC).

Finally, there is a new format for the FIX files.  Therefore, to
reconstruct the .EXE file, make certain that you are using the most
recent versions of PCKSEND.FOR, PCKGET.BAS, PCKEXE.BAS, and
PCKFIX.ASM.

                    Daphne Tzoar
                    Systems Group
-------
17-Dec-83 10:58:29-EST,494;000000000000
Return-Path: <@CUCS20:howard@brl-bmd>
Received: from CUCS20 by CU20B with DECnet; 17 Dec 83 10:58:25 EST
Received: from BRL-BMD by COLUMBIA-20.ARPA with TCP; Sat 17 Dec 83 10:55:53-EST
Date:     Sat, 17 Dec 83 10:55:05 EST
From:     Howard Walter <howard@brl-bmd>
To:       info-kermit@columbia-20
Subject:  Kermit for UNIVAC??

    I would appreciate information on the availability of kermit
for use on a UNIVAC 1100 series machine running Exec 8. Thanks.

Howard Walter
howard@brl
17-Dec-83 12:52:38-EST,964;000000000000
Return-Path: <@CUCS20:louie@cvl>
Received: from CUCS20 by CU20B with DECnet; 17 Dec 83 12:52:34 EST
Received: from cvl by COLUMBIA-20.ARPA with TCP; Sat 17 Dec 83 12:50:00-EST
Date: 17 Dec 1983 12:52:17-EST
From: Louis A Mamakos <louie@cvl>
Reply-to: louie@cvl
To: [e-mail], [e-mail]
Subject: Kermit for UNIVAC??
Cc: [e-mail]

The University of Maryland Computer Science Center is developing a KERMIT
for the Sperry (what used to be Uniac) 1100 Series computer system.  It's
not yet completly working, and there are some strange kludges because of our
terminal concentrators, but work is coming along.  When a stable version
exists, it will be announced on the list.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Louis A. Mamakos - Computer Science Center (Systems Staff) - Univ. of Maryland
Internet: [e-mail]     uucp: ...!{seismo,ihnp4,allegra}!rlgvax!cvl!louie
19-Dec-83 11:29:16-EST,1114;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 19 Dec 83 11:29:10 EST
Date: Mon 19 Dec 83 11:24:48-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: Kermit for UNIVAC??
To: [e-mail], [e-mail], info-kermit@CUCS20
cc: [e-mail], cc.fdc@CUCS20
In-Reply-To: Message from "Louis A Mamakos <louie@cvl>" of Sat 17 Dec 83 12:52:17-EST

There's already a UNIVAC-1100 version running at U of Wisconsin, written by
Paul Stevens &/or Chuck Hutchins.  It has been listed in KER:VERSIONS.DOC for
some time.  I'm still waiting for a tape from them.  I'd hate to suddenly
find two different versions on my doorstep (but that seems to be the way...).
I'd encourage you to give these guys a call at 608-262-2016 or -0280 and
see if your versions can be combined somehow.  Unfortunately, I'm the only one
who keeps records of who's working on what versions of KERMIT, so before
embarking on a new one, it's always a good idea for the prospective implementor
to give me a call to see if anyone else is already at work on the same thing.
- Frank
-------
19-Dec-83 14:10:53-EST,898;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 19 Dec 83 14:10:46 EST
Received: from MIT-XX.ARPA by COLUMBIA-20.ARPA with TCP; Mon 19 Dec 83 14:07:52-EST
Date: Mon 19 Dec 83 14:08:22-EST
From: Paul G. Weiss <[e-mail]>
Subject: Sending and gathering text
To: [e-mail]

I have two suggestions regarding "CONNECT" mode of KERMIT.

It would be nice to be able to prepare a text file locally on the micro,
and then go into CONNECT mode and have the contents of the file sent as if
it were being typed on the keyboard.  This would be terrific for something
like MCIMAIL, which has a really crummy text editor.

Then in the other direction, one should be able to record what comes back
over the line in a local file.  This would be useful for commercial
infomation services, which charge on a connect-time basis.

-------
19-Dec-83 15:17:52-EST,1016;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 19 Dec 83 15:17:41 EST
Date: Mon 19 Dec 83 15:11:21-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: Sending and gathering text
To: [e-mail], info-kermit@CUCS20
In-Reply-To: Message from "Paul G. Weiss <[e-mail]>" of Mon 19 Dec 83 14:08:10-EST

Capturing and sending raw text are nice features, having nothing to do with the
KERMIT protocol, of course, but certainly things that can be stuck into any
particular implementation of KERMIT.  In fact, many KERMITs already attempt,
with varying degrees of success, to log to files during CONNECT.  Sending raw
text is another matter, however; it could probably never be done to everyone's
satisfaction, because everyone would have a different application they might
want to communicate with, and these applications could have very different
requirements as to synchronization (answering prompts, clearing buffers, flow
control, etc).  - Frank
-------
19-Dec-83 18:10:43-EST,708;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 19 Dec 83 18:10:31 EST
Date: Mon 19 Dec 83 18:07:44-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New Release of Apple DOS KERMIT
To: Info-Kermit@CUCS20

Many new features, many problems fixed (some still remain).  The major new
feature is the ability to select communication slot and device via SET
commands, and support for several different serial cards.  The files are
available in KER:AP*.*, via anonymous FTP from host COLUMBIA-20.  The file
KER:APPKER.HLP describes this version of KERMIT for the Apple II with DOS.
Thanks to Stevens Institute of Technology for contributing this new release.
-------
20-Dec-83 14:10:10-EST,3271;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 20 Dec 83 14:09:54 EST
Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Tue 20 Dec 83 14:06:26-EST
Date: 20 Dec 83 14:04:49 EST
From: Hobbit <[e-mail]>
Subject: Merry Christmas!  Have some bugs.
To: [e-mail]

I stand corrected and informed on VMS FINISH and transfer abort [Thank
you Mr. Bush et al].  Having brought up new versions of everything, I
still notice the following remaining problems [to be thrown on the Bug Report
stack]:

What is the standard concerning SEND <filename> [close connection] RECEIVE
<different filename>?  It would seem logical that you could SEND one file,
regardless of name, and have it received on another system under a different
name.  I speak specifically of sending a Tops-20 file with a long name over
to a VMS system.  The VMS side rejects the filename and aborts if you simply
type RECEIVE, and [even worse] if you type RECEIVE <filespec>, it sits for
a moment, returns, and no file was ever written.  This can be lived with
if you're willing to rename or copy a file with a long name before you
transfer it, but can't Kermit be taught to ignore the filename packet and
just use the data and the name you gave it?

I could not find any clearly-labeled documentation on how to build
20 Kermit.  Someone here clued me in about the CMD.MAC subtlety...
The Tops-20 version doesn't show the GET command when you type ?, even though
it's in the table.

In the VMS help file [vmskermit.rnh]: there's an extra ^M in the entry
concerning STATUS, which caused Runoff to hiccup.  Easily fixed.
VMS Kermit still dies with a reserved operand fault if you set DEBUG ON
and try to do something.   Mine was assembled from the BLISS machinecode
listing [we don't have BLISS over here].

I was briefly having some trouble with a vax-vax transfer.  I put the
remote in server mode, and subsequent GETs complained of ''no more files''.
Besides being rather cryptic, this message was wrong, since the file did
indeed exist on the other side.  Later on, it worked.  I don't know what I
did to fix it.  Also, if you GET a bunch of files from a VMS server to a
VMS Kermit, say *.FOR or something, you get
Receiving ATX.FOR [OK]
[OK]
[OK]
[OK]
...  the subsequent filenames aren't stated.

It would also be nice if VMS Kermit typed dots as it handled packets, like
the 20 version.  I'm considering sticking in a small subroutine to QIO a
dot to the terminal after RPACK or SPACK or wherever, but if it's easier to
wait for a new and better version,  I will.  There is also a slightly
annoying misfeature in the interrupt handler.  While Kermit looks for a ^X
or ^Z from the terminal, it throws away all other input.  Therefore you can't
type ahead and give it a bunch of files; you have to babysit it.  Suppose
the extra typeahead were throw into a buffer and then *used*, or better
yet, command file support??  That way you could even use Kermit in batch
jobs [to transfer mail and whatnot.  Command files might be easier than
trying to write mail protocol into Kermit itself.]

We're running VMS Kermit 2.0.011, and Tops-20 version 3B(127).

_H*
-------
20-Dec-83 18:52:50-EST,1876;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 20 Dec 83 18:52:46 EST
Date: Tue 20 Dec 83 18:49:43-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: Merry Christmas!  Have some bugs.
To: [e-mail], info-kermit@CUCS20
In-Reply-To: Message from "Hobbit <[e-mail]>" of Tue 20 Dec 83 14:04:49-EST

Thanks for the bugs.  I'll respond to a couple of them; the Stevens folks can
respond to the others.

There was some discussion a while back about specifying a different name for
the file in SEND and RECEIVE.  Here's what we agreed upon (from the current
Protocol Manual):

Since it can be useful, even necessary, to specify different names  for  source
and destination files, these commands [i.e. SEND, RECEIVE, and GET] should take
operands as follows (optional operands in [brackets]):

SEND local-source-filespec [remote-destination-filespec]
        If  the destination file specification is included, this will go in the
        file header packet, instead of the file's local name.

RECEIVE [local-destination-filespec]
        If the destination filespec is given, the incoming file will be  stored
        under that name, rather than the one in the file header pakcet.

GET remote-source-filespec [local-destination-filespec]
        If  the destination filespec is given, the incoming file will be stored
        under that name, rather than the one in the file header packet.

If a file group is being sent or received, alternate names should not be used.

[end of quote]

Unfortunately, most of us haven't gotten around to putting this into our KERMIT
programs yet.  It's on the list...

About installing DEC-20 KERMIT -- The Users Guide contains a section (4.1)
on installing DEC-20 KERMIT, and it mentions CMD and all the other files you
need.

- Frank
-------
20-Dec-83 21:26:29-EST,2597;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 20 Dec 83 21:26:22 EST
Date: Tue 20 Dec 83 21:23:06-EST
From: Nick Bush <G.BUSH@CUCS20>
Subject: Re: Merry Christmas!  Have some bugs.
To: [e-mail]
cc: info-kermit@CUCS20

A few of the problems you mentioned with VMS Kermit have been fixed, and
at least one should work in the copy you have.

If you desire to have constant reassurance that the transfer is inprogress,
give VMS Kermit the command "SET MESSAGE PACKET ON".  It will then
type out a single character and packet count for each packet sent or
received.  Unfortunately, if your terminal doesn't wrap at end of line, you
end up having the characters printing in the last column - VMS doesn't
keep track of the column and wrap onto the next line.
In the next version, you can also type control-A and get a single
line status message about the transfer.

The file names that were missing in the "Sending..." (or receiving) messages
are typed out in the next version.

There still is a problem with VMS Kermit with respect to received file
names.  Currently, VMS Kermit just attempts to use the file name as
specified in the packet, and if RMS-32 doesn't like the name, you will
get an error.  We haven't fixed this one yet, so for the time being,
you need to restrict any files you send to having names of the form
name.typ, with name being up to nine characters and typ being up to three.
I don't know when this will get fixed, but it is on the list.

The RECEIVE command with a file-specification currently behaves exactly
the same as the GET command.   This also will be changed in a future
version, but again I'm not sure when.  When VMS Kermit was started,
there was no standard at all for the commands, and the RECEIVE command
was put in to correspond more with the RECEIVE command in Kermit-80 than
that in Kermit-20 (at the time it was the preferred way to do things - that
has since changed).

We have not seen the reserved operand fault in a long time, and were
never able to reliably reproduce it.  It may be related to the version
of VMS Kermit is running under.

Finally, the next version of VMS will be able to be run taking input from
a command file (although it still won't accept an indirect file itself).
I have successfully used this to run batch jobs to transfer quite a
few files.  (As part of the same fix, VMS Kermit will also write
the debugging information to a file instead of the terminal.)

The new version should be available within a few weeks.

- Nick
-------
20-Dec-83 21:54:04-EST,2613;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 20 Dec 83 21:53:56 EST
Date: Tue 20 Dec 83 21:51:07-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Yet another new KERMIT-20 available
To: Info-Kermit@CUCS20

Announcing yet another new version of KERMIT-20.  This one is 3.3(140).
The changes since 3C(133) are:

 Repeat count processing will be done automatically if the other side
  agrees (VAX/VMS and TOPS-10 KERMITs are among the other KERMITs that
  can do this, with others to follow).  Repeated sequences of the same
  character will be collapsed into a special prefix, a repeat count, and
  one copy of the character itself.  This tends to dramatically speed up
  the transmission of certain kinds of binary files, particularly small
  executable programs.

 You can't issue the RECEIVE command now if you're running KERMIT-20 in
  local mode, just as you couldn't issue the GET command if you were in
  remote mode.

 The SET EIGHTH-BIT-PREFIX command was removed.  This is now tied to SET
  PARITY.  KERMIT-20 will attempt to do 8th-bit-prefixing if you SET PARITY
  to anything other than NONE.  In addition, KERMIT-20 will do 8th-bit-
  prefixing if the other side requests it.

 Allow a single file to be sent with a specified name, as in:

    SEND MUMBLE.FROTZ (AS) FOO.BAR

  KERMIT-20 will prompt you with the guide word (AS) if you give non-wild
  filespec to send.  If you give a wild filespec, it will still prompt you
  with (INITIAL), since there's no satisfactory simple way to substitute file
  names when sending more than one file.  By the way, the RECEIVE command
  has always had this feature.  The GET command does not, because there's no
  way to tell if the given remote file specification is wild (now I understand
  why in FTP, the GET and MULTIPLE GET commands are distinct!).

 Version number typeout has been changed to conform to the new way DEC does
  it -- 3.3 rather than 3C.

This version has been pretty thoroughly tested and seems to work with both
newer and older versions of KERMIT.  It's available at host COLUMBIA-20 as
KER:20KERMIT.MAC and KER:20KERMIT.EXE via anonymous FTP.

In addition, there is a draft of a new DEC-20 KERMIT manual available for
comment in KER:20KERMIT.DOC or KER:20KERMIT.MSS (Scribe source).  This is a
first step in updating the KERMIT Users Guide and breaking it up into more
manageable pieces.  I'd be interested to what extent people think this draft
would be a useful model for documentation of the other KERMIT implementations.

- Frank
-------
21-Dec-83 06:09:23-EST,619;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 21 Dec 83 06:09:17 EST
Received: from CISL-SERVICE-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Wed 21 Dec 83 06:06:47-EST
Received: from HIS-BILLERICA-MULTICS.ARPA by CISL-SERVICE-MULTICS.ARPA dial; 21-Dec-1983 06:01:34-est
Date:  20 December 1983 13:22 est
From:  Popiel.EMREL at HIS-BILLERICA-MULTICS
Subject:  PASCAL version of KERMIT
To:  info-kermit at COLUMBIA-20
Acknowledge-To:  Popiel.EMREL at HIS-BILLERICA-MULTICS

Please let me know what Pascal versions of Kermit are currently
available.
21-Dec-83 10:36:16-EST,826;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 21 Dec 83 10:36:10 EST
Date: Wed 21 Dec 83 10:29:19-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: PASCAL version of KERMIT
To: info-kermit@CUCS20,
    [e-mail]
In-Reply-To: Message from "Popiel.EMREL at HIS-BILLERICA-MULTICS" of Tue 20 Dec 83 13:22:00-EST

1. RT-11 KERMIT is written in OMSI Pascal with PDP-11 assembler mixed in.
2. HP-98xx KERMIT is written in HP Pascal (similar to UCSD)
3. Terak KERMIT is written in UCSD Pascal with some PDP-11 assember procedures.
4. There's a VAX/VMS version written in a mixture of Pascal & Fortran.
5. The MTS version (I don't have it yet) is written in Pascal/VS.

I think that covers the bases, so far...  - Frank
-------
22-Dec-83 18:52:51-EST,743;000000000000
Return-Path: <@CUCS20:prophet%umcp-cs@CSNet-Relay>
Received: from CUCS20 by CU20B with DECnet; 22 Dec 83 18:52:44 EST
Received: from csnet-cic.ARPA by COLUMBIA-20.ARPA with TCP; Thu 22 Dec 83 18:50:10-EST
Date:     22 Dec 83 17:40:55 EST  (Thu)
From: Dennis Gibbs <prophet%umcp-cs@CSNet-Relay>
Return-Path: <prophet%umcp-cs@CSNet-Relay>
Subject:  Kermit
To: INFO-KERMIT@COLUMBIA-20
Via:  UMCP-CS; 22 Dec 83 18:01-EST


Greetings,
     I have the generic form of Kermit for CP/M.  I thought I would
send a msg asking if there existed a version of it for my Micro before
I started modifying.  I have a Altos 5-15D runs CP/M & MP/M.  It has
two floppies, 192K memory and so on...Thankyou for any comments you
might have..

22-Dec-83 19:48:51-EST,1318;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 22 Dec 83 19:48:46 EST
Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Thu 22 Dec 83 19:46:08-EST
Date: 22 Dec 83 19:32:55 EST
From: Hobbit <[e-mail]>
Subject: Storing attributes
To: [e-mail]

May I suggest that making Kermit handle file attributes between any two
different machines is perhaps asking too much from an already good thing.
I believe the original idea behind Kermit was to transfer 7-bit ascii
files.  This may be opinion, but would it perhaps not be easier to write
a package for any given system to mash up binary files into printable
characters [or the reverse] and then use Kermit to move the text across?
This way, a stored binary file would look like any other text file, which
is the same on any system.   I suggest this because I wrote such a package
for VMS, and have successfully transferred VMS images between machines
with it.  It seems that Kermit is reaching a stage where implementation
of the blue-sky ideas may only lead to massive confusion.  Similarly, a mail
system could simply call Kermit to do its transferring and pass commands to it.
Are there any ideas about this [besides making Kermit cook your breakfast]?

_H*
-------
22-Dec-83 20:02:46-EST,1433;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 22 Dec 83 20:02:42 EST
Date: Thu 22 Dec 83 19:58:10-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: Kermit
To: [e-mail], Info-Kermit@CUCS20
In-Reply-To: Message from "Dennis Gibbs <prophet%umcp-cs@CSNet-Relay>" of Thu 22 Dec 83 17:40:55-EST

To bring CP/M Kermit up on the Altos 5, presumably under CP/M 2.x (as opposed
to 3.x, i.e. CP/M-Plus):

FIrst Make sure you have the latest CP/M Kermit, KER:CPMBASE.M80 (Kermit-80
version 3.6).  Also get the file KER:CPMGENERI.HEX.  You can try LOADing the
latter and running it -- who knows, it just might work!  If not, then look
at the assembler source and check the IOBYTE definitions, and modify them for
your system if necessary (presuming your system fully supports the IOBYTE).

If none of that works, you'll have to add device- and system-dependent code
for your system -- port address, status bits, screen codes, all that, on the
model of the various systems that are present supported explicitly.

BUT...  DOn't put too much effort into it, because some time in the next few
weeks (or months?), an entirely new, rewritten, modularized version of CP/M
Kermit will appear.  At that point, it will be a lot easier to produce support
for new systems, and to enhance the protocol portion of the program.  Watch
this list for announcements.
-------
23-Dec-83 00:47:26-EST,1307;000000000000
Return-Path: <@CUCS20:cbosgd!mddc-b!chris@Berkeley>
Received: from CUCS20 by CU20B with DECnet; 23 Dec 83 00:47:19 EST
Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Fri 23 Dec 83 00:44:45-EST
Received: by UCB-VAX.ARPA (4.22/4.18)
    id AA18901; Thu, 22 Dec 83 21:42:43 pst
Received: by cbosgd.UUCP (4.12/3.7)
    id AA22776; Fri, 23 Dec 83 00:30:59 est
Sent-By: qusavx.UUCP Thu Dec 22 17:51:57 1983
Sent-By: mddc-b.UUCP Thu Dec 22 17:36:47 1983
Received: by mddc.UUCP (4.12/4.7)
    id AA00126; Thu, 22 Dec 83 17:36:47 est
Date: Thu, 22 Dec 83 17:36:47 est
From: cbosgd!mddc-b!chris@Berkeley (Chris Maloney)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: DECmate and WS78 to VAX/4.2 file transfers


I will be asked to provide 'Kermit' service from
a DECmate II to a VAX/4.2 unix machine.  I would rather
not force my users to buy the CPM option.  Do they
have a choose?
Similiarly we need a kermit like service for the
ancient DEC WS78 (the DECmate I).  Any ideas?

Thanks,

Chris Maloney
Management Decisions Development Corp.
Fairfield, Ohio   45014
[phone]

..{ucbvax,decvax,inhp4,mhuxi}!cbosgd!qusavx!mddc!chris        (uucp)
cbosgd!qusavx!mddc!chris@BERKELEY                (arpa)
cca!decvax!cbosgd!qusavx!mddc!chris@SRI-CSL            (arpa)

23-Dec-83 01:01:59-EST,1018;000000000000
Return-Path: <@CUCS20:prophet%umcp-cs@CSNet-Relay>
Received: from CUCS20 by CU20B with DECnet; 23 Dec 83 01:01:55 EST
Received: from csnet-cic.ARPA by COLUMBIA-20.ARPA with TCP; Fri 23 Dec 83 00:59:24-EST
Date:     22 Dec 83 23:17:03 EST  (Thu)
From: Dennis Gibbs <prophet%umcp-cs@CSNet-Relay>
Return-Path: <prophet%umcp-cs@CSNet-Relay>
Subject:  Re: Kermit
To: Frank da Cruz <cc.fdc@COLUMBIA-20>, prophet%umcp-cs@CSNet-Relay,
        Info-Kermit@COLUMBIA-20
Via:  UMCP-CS; 22 Dec 83 23:28-EST

Thankyou for the info, I have CPMGENERI.ASM, I have assembled it
and loaded it, but it didnt work, since then I have started putting
some of the system dependent stuff in it.  I don't know Z80 assembly
so I can't do much other than put in the port numbers in the defines
and some set up some of the other system stuff.  I won't work on it
too much, just to become familar with the kermit system. I will eagarily
await the new CP/M package....And you are right, I do run CP/M 2.2...
Happy Holiday's......
23-Dec-83 12:03:48-EST,1545;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 23 Dec 83 12:03:41 EST
Date: Fri 23 Dec 83 12:00:13-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Announcing KERMIT for UNIVAC 1100
To: Info-Kermit@CUCS20
cc: [e-mail], [e-mail]

Announcing Sperry Univac KERMIT, contributed by

  Paul Stevens
  Madison Academic Computing Center
  1210 West Dayton Street
  University Of Wisconsin
  Madison, Wisconsin  53706
  [phone]

Here is the text of his letter:  "For what it is worth, here is our version of
KERMIT that runs on Sperry 1100/82.  Documentation is meager.  Instructions for
users are in the listing itself in the form of `HELP' strings.  Instructions
for implementing on other 1100 computers amount to a few comments on page 1.
Probably the most helpful comment consists of my name, address, and phone
number.  Good luck!"

A subsequent phone conversation revealed that there actually is a manual, which
you may obtain by sending a self-addressed stamped envelope to the above.  It
is not included with the distribution since there is no plain-text version of
it (it was for a particular photocomposer using a text formatter than cannot
produce plain text).

The program is written in Univac 1100 Exec assembly language.  The unusual use
of alphabetic case in the listing is not a mistake; the author actually typed
it in that way.

The program is available at host COLUMBIA-20 via anonymous FTP in the file
KER:UNIVAC.ASM.

- Frank
-------
23-Dec-83 12:15:26-EST,1056;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 23 Dec 83 12:15:20 EST
Date: Fri 23 Dec 83 12:06:40-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: DECmate and WS78 to VAX/4.2 file transfers
To: cbosgd!mddc-b![e-mail], INFO-KERMIT@CUCS20
In-Reply-To: Message from "cbosgd!mddc-b!chris@Berkeley (Chris Maloney)" of Fri 23 Dec 83 00:44:56-EST

The only way to have KERMIT on a DECmate II is with the CP/M option.  I believe
there is a new "option" for interchanging files between the CP/M file system
and the word processor file system.  Thus if you have one DECmate II with the
CP/M option, it can service WPS-78s and other DECmate II's that don't have CP/M
or KERMIT, since the disks are (or can be) compatible.

I sincerely doubt that anyone will ever write KERMIT to run on the PDP-8 which
is inside the DECmates; I don't even know if it's possible to program it
directly.  There's always DEC's DX package...  Did you know that DEC markets
a version of DX for UNIX?

- Frank
-------
28-Dec-83 14:34:08-EST,808;000000000000
Return-Path: <@CUCS20:OC.AMS@CU20B>
Received: from CUCS20 by CU20B with DECnet; 28 Dec 83 14:34:03 EST
Received: from CU20B by CUCS20 with DECnet; 28 Dec 83 14:32:31 EST
Date: Sun 25 Dec 83 21:49:39-EST
From: Bill Hall <OC.AMS@CU20B>
Subject: Re: PASCAL version of KERMIT
To: info-kermit@CUCS20
In-Reply-To: Message from "Popiel.EMREL at HIS-BILLERICA-MULTICS" of Tue 20 Dec 83 13:22:00-EST

I have written two versions in PASCAL.  One runs on the MTS operating
system (Michigan Terminal System) and is written in Pascal/VS.
The other is written for the DEC-20.  This was just an exercise since
the Macro version is the one to use in practice, but it may provide
a model for other systems.

                -Bill Hall
                 Mathematical Reviews
                 611 Church Street
                 Ann Arbor, MI 48107
-------
29-Dec-83 22:24:09-EST,1067;000000000000
Return-Path: <@CUCS20:uucp@SU-Shasta>
Received: from CUCS20 by CU20B with DECnet; 29 Dec 83 22:24:06 EST
Received: from SU-Shasta by COLUMBIA-20.ARPA with TCP; Thu 29 Dec 83 22:23:58-EST
Received: from decwrl by Shasta with UUCP; Thu, 29 Dec 83 19:20 PST
Date: Wednesday, 28 Dec 1983 17:40:06-PST
Sender: uucp@SU-Shasta
From: decwrl!rhea!atfab!wyman@SU-Shasta
Subject: DECmates and KERMIT
Message-Id: <8312300304.AA04917@DECWRL>
Received: from RHEA.ARPA by DECWRL (3.327/4.09) 29 Dec 83 19:04:46 PST (Thu)
To: [e-mail]

Frank stated recently that he wasn't sure if KERMIT could be
written for a PDP-8... Well, I don't want to sound defensive here,
however, the DX protocol that IS written on the DECmates is very
similar in many ways to the KERMIT protocol. If DEC could write
DX on an 8 then KERMIT should be possible too!

Since there are alot of DECmates, WPS-???, and WS78 systems in the
world, and there are going to be many more... An interesting
project might be the development of a DX-KERMIT server.

        bob wyman
30-Dec-83 09:08:02-EST,1254;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 30 Dec 83 09:07:59 EST
Date: Fri 30 Dec 83 09:07:37-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: DECmates and KERMIT
To: decwrl!rhea!atfab![e-mail], info-kermit@CUCS20
In-Reply-To: Message from "decwrl!rhea!atfab!wyman@SU-Shasta" of Thu 29 Dec 83 22:24:12-EST

Actually a "native" Kermit for the DECmate would be a great idea.  Given that,
you wouldn't need to buy DX for your DEC-10, DEC-20, VAX, etc, and (perhaps
even more significant) you could now exchange files between your DECmate or
WS-78 and your IBM mainframe, CP/M system, IBM PC, Apple, and all the other
systems that speak KERMIT.  To my knowledge, however, the only people who know
how to program a DECmate are within DEC.

Speaking of DX, about 3 years ago I was tracking down one of the persistent
rumors about DEC running DECnet internally on a UNIX system in their internal
engineering net.  When I finally reached the person in Merrimac who ran ran the
alleged system, he said no, it wasn't DECnet, just DX-UNIX, which was a
commercial product developed for DEC by his group.  But after that, I never
heard anything about DX-UNIX.

- Frank
-------
30-Dec-83 13:56:11-EST,1567;000000000000
Return-Path: <@CUCS20:abrams@mitre>
Received: from CUCS20 by CU20B with DECnet; 30 Dec 83 13:56:07 EST
Received: from mitre by COLUMBIA-20.ARPA with TCP; Fri 30 Dec 83 13:55:51-EST
Date: 30 Dec 1983 13:34:41 EST (Friday)
From: Marshall Abrams <abrams@mitre>
Subject: Call for Papers
To: microgroups:@mitre
Cc: abrams@mitre

The IEEE Computer Society has issued a call for papers which I think would be
of special interest to those of us involved with small computers. The
conference title is The Small Computer (R)Evolution.

The call for papers sys that the program will encompass a wide scope of
applications: as tools for managers, professionals, non-professionals, students,
home-users, hobbyists and as embedded elements of other systems. The program
will include tutorials, panels, demonstartions, and technical papers."

The schedule includes:Jan 3 1984  Proposals for tutorials due (these are all-day
tutorials of professional quality with the speaker being paid)
    April 2   Paper, session, and panel proposals due
    April 16  Demonstration descriptions due
The papers (due April; 2) are to be submitted in three copies and should range
from 1000 to 5000 words.

All mail is addressed to:
    Small Computer (R)Evolution
    c/o IEEE Computer Society
    P. O. Box 639
    Silver Spring, MD  20901

I will be happy to supply further information, including a copy of the
physical call for papers, on request. I would especially encourage
formation of sessions concentrating on subjects/applications which from
a group of co-workers.


30-Dec-83 17:38:55-EST,1503;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 30 Dec 83 17:38:51 EST
Date: Fri 30 Dec 83 17:38:31-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New Release of Rainbow Kermit-86
To: Info-Kermit@CUCS20
cc: [e-mail]

This is version 0.2 of KERMIT for the DEC Rainbow 100 (and, hopefully, Rainbow
100+), to run under CP/M-86 version 1.0 or 2.0.  It's still preliminary, and
still missing some important features like wildcard sends.  The major change is
that it corrects a problem with modem signals versus internal modems.  If the
change works (I don't have an internal modem to test it on), you won't have to
run SETDTR before running Kermit-86 on the Rainbow any more.  (But you'll still
have to run SETDTR before running Kermit-80 on the Rainbow, because there's no
way to control modem signals from the Z80 side.)  Thanks to Brian Orr in Idaho
for the fix.

The new release is available at host COLUMBIA-20 via anonymous FTP as:

 KER:RBKERMIT.CMD (executable program, 8-bit binary)
 KER:RBKERMIT.H86 (7-bit ASCII DR-format hex file, loadable with GENCMD)
 KER:RBKERMIT.HLP (short help file)

The source is in KER:RB*.A86.  If anyone has an internal modem, please get this
new version and try it out, and let me know it the problem with DTR has been
solved.  Thanks!

Meanwhile, there may be a version of KERMIT for the Rainbow under MS DOS some
time soon; watch this space for announcements.

- Frank
-------
30-Dec-83 18:28:32-EST,719;000000000000
Return-Path: <@CUCS20:lauren@rand-unix>
Received: from CUCS20 by CU20B with DECnet; 30 Dec 83 18:28:29 EST
Received: from rand-unix by COLUMBIA-20.ARPA with TCP; Fri 30 Dec 83 18:28:24-EST
From: vortex!lauren at RAND-UNIX
Date: Fri, 30-Dec-83 15:09:58-PST
Sender: Lauren Weinstein <vortex!lauren@RAND-UNIX>
Subject: DEC Engineering net
To: info-kermit@COLUMBIA-20

The interface between the Enet (running DECnet) and the outside world
(mostly UUCP) is basically a twisted pair running between a Unix
and VMS machine.  DEC is not running DECnet on UNIX, though they will
soon be running UUCP on VMS (a version of my private UUCP code which
I have to go back to Merrimack to finish up...)

--Lauren--


 2-Jan-84 19:27:49-EST,1303;000000000000
Return-Path: <@CUCS20:iam@cmu-cs-g>
Received: from CUCS20 by CU20B with DECnet; 2 Jan 84 19:27:46 EST
Received: from CMU-CS-G by COLUMBIA-20.ARPA with TCP; Mon 2 Jan 84 19:27:56-EST
Date: 2 Jan 1984 15:06-EST
From: [e-mail]
Subject: Apple CP/M Kermit and Emacs
To: INFO-KERMIT@CUCS20
Message-Id: <441921979/iam@CMU-CS-G>

This is a direct reply to Francis Wilson who I haven't been able to reach
@CUTC20, though I think it will have some general interest.

My current understanding of how to get Apple CP/M Kermit to work with UNIX
Emacs on a VAX is the following:

If your system supports a Soroc IQ 120/ IQ 140 video terminal, then
configure the Hardware Screen Function Table for use with a Datamedia-style
terminal and the Software Table for the Soroc.  This is explained in part V
of the manual supplied by Microsoft.  Once this is done you can "tell" UNIX
that your video terminal is a Soroc by typing "setenv TERM Soroc" after you
login.  You might also want to change some Emacs key-bindings if they are
incompatible with your particular hardware configuration.

In other words the problem is not with Kermit, but with configuring Apple
CP/M for a particular external terminal and getting the system your
communicating with to recognize this.

--Ira
 3-Jan-84 08:51:51-EST,901;000000000000
Return-Path: <@CUCS20:decwrl!rhea!vax4!arson!roberts@SU-Shasta>
Received: from CUCS20 by CU20B with DECnet; 3 Jan 84 08:51:48 EST
Received: from SU-Shasta by COLUMBIA-20.ARPA with TCP; Tue 3 Jan 84 08:51:54-EST
Received: from decwrl by Shasta with UUCP; Tue, 3 Jan 84 05:49 PST
Date: Tuesday,  3 Jan 1984 05:35:42-PST
Sender: decwrl!rhea!vax4!arson!roberts@SU-Shasta
From: DMII 1.0 For: Keith Roberts <decwrl!rhea!vax4!arson!roberts>;
Subject: MS-DOS Kermit
Message-Id: <8401031344.AA14857@DECWRL>
Received: from RHEA.ARPA by DECWRL (3.327/4.09) 3 Jan 84 05:44:55 PST (Tue)
To: [e-mail]

Is it planned that the Rainbow MS-DOS Version of Kermit
will Run on other machines...Such as the Z100 (ZDOS) ?


I'm working DECmate II software development...I don't know if DEC
has any plans of including Kermit Protocol in their DX Option..
But I'll ask.

Keith Roberts
 3-Jan-84 10:57:09-EST,515;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 3 Jan 84 10:56:52 EST
Date: Tue 3 Jan 84 10:56:36-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: MS-DOS Kermit
To: info-kermit@CUCS20
In-Reply-To: Message from "DMII 1.0 For: Keith Roberts <decwrl!rhea!vax4!arson!roberts>;" of Tue 3 Jan 84 08:52:08-EST

The MS DOS version of Kermit already does run on the Z100 under ZDOS, as well as
the IBM PC.  The machine it doesn't run on yet is the Rainbow.  - Frank
-------
 4-Jan-84 17:01:27-EST,1542;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 4 Jan 84 17:01:14 EST
Date: Wed 4 Jan 84 17:00:42-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New KERMITs for DEC Rainbow, NEC APC
To: Info-Kermit@CUCS20

Announcing yet another release of KERMIT for the Rainbow-100, version 2.1,
contributed by Ron Blanford of the University of Washington.  This release
adds many of the features that were missing before, notably:

 Wildcard sends
. SET FILE ASCII / BINARY
. Validation (and conversion if necessary) of incoming filenames
. Proper handling of modem signals like DTR

along with many minor improvements (for instance, packet numbers are displayed
in decimal rather than hex).  In addition, support was added for the NEC
Advanced Personal Computer (APC).

Like the previous release, this version keeps up at speeds up to and including
9600 baud.  It has not been tested at 19,200 baud.

The relevant files are available at host COLUMBIA-20 via anonymous FTP.

  For the Rainbow:

    KER:RBKERMIT.CMD    Executable CP/M-86 program
    KER:RBKERMIT.H86    Hex file loadable by GENCMD
    KER:RBKERMIT.HLP    A brief description of the features & limitations

  For the NEC APC:

    KER:APCKERMIT.CMD    Executable CP/M-86 program
    KER:APCKERMIT.H86    Hex file loadable by GENCMD

The source is in:

    KER:86*.A86        ASM86 source modules.

The file KER:86KERMIT.HLP describes the program in more detail, lists features,
restrictions, and known problems.

- Frank
-------
 5-Jan-84 00:19:11-EST,908;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 5 Jan 84 00:19:06 EST
Received: from MIT-XX.ARPA by COLUMBIA-20.ARPA with TCP; Thu 5 Jan 84 00:18:35-EST
Date: Thu 5 Jan 84 00:18:49-EST
From: Thomas S. Wanuga <[e-mail]>
Subject: Re: New KERMITs for DEC Rainbow, NEC APC
To: [e-mail]
cc: [e-mail]
In-Reply-To: Message from "Frank da Cruz <[e-mail]>" of Wed 4 Jan 84 19:33:26-EST

My friend tried out the newly announced KERMIT on his NEC APC.  He was
able to transfer files with a TOPS-20 machine, but was unable to get
the terminal emulator to work properly.  Specifically, clearing the
screen did not work.  We tried telling TOPS-20 that the terminal was a
H19, and then a VT52.  What kind of terminal does this version of
KERMIT emulate?  Has anyone had similar problems?

Tom Wanuga
-------
 5-Jan-84 11:06:42-EST,451;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 5 Jan 84 11:06:26 EST
Date: Thu 5 Jan 84 11:03:14-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: New KERMITs for DEC Rainbow, NEC APC
To: [e-mail], info-kermit@CUCS20
cc: [e-mail]
In-Reply-To: Message from "Thomas S. Wanuga <[e-mail]>" of Thu 5 Jan 84 00:19:12-EST

I'll try to get an answer for you.  - Frank
-------
 5-Jan-84 11:19:39-EST,502;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 5 Jan 84 11:19:19 EST
Date: Thu 5 Jan 84 11:14:09-EST
From: Daphne Tzoar <CC.DAPHNE@CUCS20>
Subject: PC Kermit version 1.20
To: info-kermit@CUCS20, [e-mail]

Version 1.20 of PC Kermit is now the default and has been renamed to
PCKERMIT.  Version 1.18 is available as PCKOLD.  Both files can be
anonymously FTP'ed from node Columbia-20.  Please report any problems
to me.
/daphne
-------
 5-Jan-84 14:31:56-EST,938;000000000001
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 5 Jan 84 14:31:49 EST
Received: from WASHINGTON.ARPA by COLUMBIA-20.ARPA with TCP; Thu 5 Jan 84 14:27:28-EST
Date: Thu 5 Jan 84 11:26:30-PST
From: Ronald Blanford <[e-mail]>
Subject: Re: New KERMITs for DEC Rainbow, NEC APC
To: [e-mail]
cc: [e-mail]
In-Reply-To: Message from "Thomas S. Wanuga <[e-mail]>" of Wed 4 Jan 84 21:54:31-PST

The NEC APC emulates most of the functions of a VT100.  The only function
which doesn't work right because of a bug in the BIOS is the HOME cursor
function.  The ANSI command for this function is ESC [ H, with the omitted
parameters defaulting to 1;1.  This default does not work correctly on
the APC, so the only solution is to always include the 1;1 specifically.
I don't know how to get TOPS-20 to do this.

                    Ron Blanford
-------
 5-Jan-84 17:32:58-EST,3131;000000000001
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 5 Jan 84 17:32:44 EST
Received: from WASHINGTON.ARPA by COLUMBIA-20.ARPA with TCP; Thu 5 Jan 84 17:29:46-EST
Date: Thu 5 Jan 84 14:28:44-PST
From: Ronald Blanford <[e-mail]>
Subject: NEC APC home cursor bug
To: [e-mail]
cc: [e-mail]


This message is in response to the complaint that the NEC APC does not
clear screen when in terminal mode.

The following patch to the NEC APC CPM.SYS will fix the bug that keeps
it from correctly executing the ANSI HOME CURSOR function ESC [ H.
The addresses for this patch are taken from CP/M-86 version 1.106.013
and although the patch is most likely correct for other versions, the
addresses may differ.  This patch is to the ESCCUP0 routine in the
NEC CBIOS and the correct addresses can be obtained for any version
by displaying the CBIOS.LST file that came with the CP/M-86 release
and adding 80H (hex) to the first address it shows for that routine.

As an elementary precaution, do not patch the release disk, and use a
scratch disk for the initial modification and testing of the patch.

The following sequence is exactly what I used to modify my own CPM.
The computer output is in upper case, and my typing is in lower case.
Don't enter the comments.


A>ddt86                    ;load DDT86
DDT86 1.1
-rcpm.sys                ;read the CPM.SYS file
  START     END
0800:0000 0800:6EFF
-l3505                    ;list the beginning of ESCCUP0
0800:3505 PUSH    SI
0800:3506 MOV    SI,5C68
0800:3509 CMP    BYTE [5C67],00
0800:350E JZ    3517
0800:3510 CMP    BYTE [5C67],02
0800:3515 JNZ    3540
0800:3517 MOV    AX,[SI]
0800:3519 CMP    AL,00
0800:351B JZ    3525
0800:351D SUB    AL,01
0800:351F CMP    AL,18
0800:3521 JB    3525
-a350e
0800:350E nop                ;get rid of the JZ 3517
0800:350F nop
0800:3510                 ;(just enter a RETURN here)
-a3515
0800:3515 ja 3540            ;change the JNZ to JA
0800:3517                  ;(just enter a RETURN here)
-l3505                    ;list it again to verify changes
0800:3505 PUSH    SI
0800:3506 MOV    SI,5C68
0800:3509 CMP    BYTE [5C67],00
0800:350E NOP                ;should be different here
0800:350F NOP
0800:3510 CMP    BYTE [5C67],02
0800:3515 JA    3540            ;  and here
0800:3517 MOV    AX,[SI]
0800:3519 CMP    AL,00
0800:351B JZ    3525
0800:351D SUB    AL,01
0800:351F CMP    AL,18
-wcpm.sys                ;save the modified version
-^C                    ;type CONTROL-C to exit from DDT86

A>

Then reboot your system to load the new version of CPM.  After you've tried
out the new version, copy it to your working disks.

The ANSI-VT100 features that the NEC APC supports are:
    direct cursor addressing (row, column)
    relative cursor addressing (up, down, left, right)
    line erasing (cursor to end, beginning to cursor, entire line)
    screen erasing (cursor to end, beginning to cursor, entire line)
    character attributes (underline, reverse, blink, but not bold)

If your editor requires other features (such as perhaps cursor position read,
reverse scroll, tab setting, or window erase) you'll have to add those to
Kermit or to your CP/M BIOS.

Good luck.
                    Ron Blanford
-------
 6-Jan-84 20:11:32-EST,905;000000000001
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 6 Jan 84 20:11:28 EST
Date: Fri 6 Jan 84 20:12:05-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Announcing KERMIT for MTS
To: Info-Kermit@CUCS20

Just arrived from the University of Michigan, Ann Arbor:  KERMIT for the
Michigan Terminal System (MTS), which is a non-IBM operating system for
IBM 370-series mainframes.  There are two (count them) versions, one in
IBM assembler written by Chris Thomson, and another in Pascal/VS written
by Bill Hall of Math Reviews.  The assembler version has no documentation
beyond some comments at the top of the listing; the Pascal version has a
.DOC file.

MTS KERMIT is available in KER:MTSKERMIT.* (3 files) on host COLUMBIA-20
via anonymous FTP.  Thanks to Gavin Eadie of U. Mich. for rounding up these
implementations and sending them in.

- Frank
-------
 8-Jan-84 20:21:39-EST,1700;000000000000
Return-Path: <@CUCS20:decwrl!rhea!atfab!wyman@Shasta>
Received: from CUCS20 by CU20B with DECnet; 8 Jan 84 20:21:34 EST
Received: from Shasta by COLUMBIA-20.ARPA with TCP; Sun 8 Jan 84 20:20:41-EST
Received: from decwrl by Shasta with UUCP; Sun, 8 Jan 84 17:20 PST
Date: Sunday,  8 Jan 1984 16:49:09-PST
From: decwrl!rhea!atfab!wyman@Shasta
Subject: KERPAC -- An answer to the MAIL need???
Message-Id: <8401090058.AA21291@DECWRL>
Received: from RHEA.ARPA by DECWRL (3.327/4.09) 8 Jan 84 16:58:18 PST (Sun)
To: [e-mail]

Although the discussion of KERMIT-MAIL has died down a bit...
With the consensus seeming to be that such a thing should not be
done, there is still an outstanding requirement for "standard"
mail protocols for the micros which rely not only on predictable
syntax/semantics but also on the availability of some sort of
widely available reliable transport layer.

The existence of the KERMIT packet definition is one of the nice
things about the protocol. The expandablity provided by the
definition as it stands is a great plus... What I would like to
propose is that the packet definition be made to stand
independent of KERMIT itself and that KERMIT the file transfer
program be defined as simply one of potentially many applications
that will one day use the KERMIT Packet (KERPAC) as a base.

What do you think? Is the KERMIT Packet structure appropriate for
general use? Is there a better packet structure that already
exists?

        bob wyman

    (DEC-Enet) ATFAB::WYMAN
    (UUCP) {decvax,ucbvax,allegra}!decwrl!rhea!atfab!wyman
    (ARPA) decwrl!rhea!atfab![e-mail]
           decwrl!rhea!atfab!wyman@SU-Shasta

 8-Jan-84 22:23:35-EST,3529;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 8 Jan 84 22:23:28 EST
Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Sun 8 Jan 84 22:22:53-EST
Date:  Sunday, 8 January 1984 22:17 est
From:  Bruce Nemnich <[e-mail]>
Subject:  Re: KERPAC -- An answer to the MAIL need???
To:  decwrl!rhea!atfab![e-mail]
cc:  [e-mail], [e-mail]
In-Reply-To:  Message of 8 January 1984 19:49 est from "decwrl!rhea!atfab!wyman at SU-SHASTA"
Message-ID:  <[e-mail]>

          Date:  Sunday, 8 January 1984 19:49 est
          From:  decwrl!rhea!atfab!wyman at SU-SHASTA
          Subject:  KERPAC -- An answer to the MAIL need???
          To:  info-kermit at COLUMBIA-20

          Although the discussion of KERMIT-MAIL has died down a bit...
          With the consensus seeming to be that such a thing should not be
          done, there is still an outstanding requirement for "standard"
          mail protocols for the micros which rely not only on predictable
          syntax/semantics but also on the availability of some sort of
          widely available reliable transport layer.

          The existence of the KERMIT packet definition is one of the nice
          things about the protocol. The expandablity provided by the
          definition as it stands is a great plus... What I would like to
          propose is that the packet definition be made to stand
          independent of KERMIT itself and that KERMIT the file transfer
          program be defined as simply one of potentially many applications
          that will one day use the KERMIT Packet (KERPAC) as a base.

          What do you think? Is the KERMIT Packet structure appropriate for
          general use? Is there a better packet structure that already
          exists?

                              bob wyman

                    (DEC-Enet) ATFAB::WYMAN
                    (UUCP) {decvax,ucbvax,allegra}!decwrl!rhea!atfab!wyman
                    (ARPA) decwrl!rhea!atfab![e-mail]
                           decwrl!rhea!atfab!wyman@SU-Shasta




Yes, there is a better protocol already designed called PCNET.  The name
has nothing to do with a product of the same name sold by Orchid
Technologies; the people working on the PCNET I am writing of were using
the name long before Orchid.

The problem is that little work has been done recently on PCNET.  The
protocol was originally designed about 5 years ago (there have been
changes since), but there is only one full implementation I know of (by
Robert Elton Mass on MIT-MC).  There are many implementations partially
completed.

PCNET was designed from the beginning as a link-level protocol; any
desirable application (mail, ftp, telnet/supdup, et cetera) can be
written on top of it.  PCNET provides one or more extremely reliable
8-bit data channels to its applications, even on hosts which can send
only capital letters, numbers, and common punctuation characters.

It is better than Kermit for many reasons; if you want more technical
information, I can supply you with it.  Now, if only we PCNET volunteers
can get going (actually, I have been working on it again for the last
couple of weeks on Multics and my IBM PC).

--bruce

P.S.  -- Bob, I have CC'd this to the Protocols discussion group in hope
of getting more comments therefrom.  Hope you don't mind.
 9-Jan-84 21:51:34-EST,4660;000000000000
Return-Path: <@CUCS20:HFISCHER@USC-ECLB>
Received: from CUCS20 by CU20B with DECnet; 9 Jan 84 21:51:22 EST
Received: from USC-ECLB by COLUMBIA-20.ARPA with TCP; Mon 9 Jan 84 21:46:56-EST
Date:  9 Jan 1984 1846-PST
From: HFISCHER%USC-ECLB@SRI-NIC
Subject: Test version of PC kermit has server function added
To:   Info-Kermit at COLUMBIA-20
cc:   HFischer at ECLB

A number of folks have expressed an interest in a version of the IBM PC Kermit
program which also functions as a server. Intense pressure at my company
(Litton Data Systems) to be able to do something with all of our PC's so that
managers could collect their status reports automatically prompted me to make
an initial test release of the PC (and Heath) Kermit (with server added).

I have succeeded in modifying PCK20.asm to become both the regular local
Kermit and additionally a server.  As a server, the program (the same
identical program) can function as an unattended remote, either controlled by
its own console, or with the DOS-2 CTTY command, over the communications
line.

The modified kermit is in my directory for those who would like to test it.
At Arpanet site "USC-ECLB" FTP file <HFischer>pck20.new for the modified
assembler code, and file <HFischer>pck20.exe for the 8-bit mode .exe file.

If you'd rather have the file some other way, there are two choices;  mail me
a floppy (Herman Fischer, Litton Data Systems, 8000 Woodley, ms 44-30,
Van Nuys, CA 91409) or contact me by net or phone (we could put my PC into
server mode and transmit the .exe file directly).

Please let me know of any problems, or questions in getting it up.  My
telephone number is 213/902-5139 (but I will be out of town next week and the
week after, net accessible next week but not at all the week after).

I have tested it using the resources available in my company (my test setup is
a Sytek local area network with 9600 baud communications between multiple
PC's). Obviously there are many combinations of equipment which are still to
be tried.

If you must run under DOS 1, then you can only load the kermit server on the
serving machine's console (because DOS 1 cannot redirect commands over comm
links).  When you load kermit, after setting the baud rates, parity, or
whatever, issue the command "server".  This places your machine in a receive
state, whereby callers can send to you, receive from you (default directory
only).  Don't let remote callers issue "finish" or "logout" because that'll
return your machine to DOS, and then subsequent callers cannot access kermit
without your presence to reload it.

It is much more sexy to use DOS 2 CTTY to redirect your keyboard to the comm
line. Then the caller can use dir, edlin, type, and just about all programs
which use DOS (not BIOS) calls. (BASIC uses BIOS calls, so it won't cooperate
with CTTY.) If your machine has CTTY COM1 issued, then the caller can do
whatever he wants, including loading and running PC Kermit. For PC Kermit,
your caller must type in a command to load Kermit and override the DOS 2 CTTY
redirection (because your comm line probably needs set baud and other
preparatory commands, and the server command, and because PC kermit uses
BIOS console I/O (lest it not run on DOS 1 any more)). Once the remote caller
is ready, to load kermit, he MUST do it (or invoke batch files) as thus:

    "kermit < yourfile.xx > con:"

where yourfile.xx contains something like:

     "set baud 9600
      server".

He then does his "^]C" and tells his kermit what to send/receive/finish. When
finished, he again can connect and operate the remote PC's DOS (those programs
not using BIOS, of course). Wildcards work as usual. Drive id's work, but are
tricky, for example, because getting a file from a sepecified drive of the
server will stuff the file onto the default drive of the recipient.

If the owner stumbles back into the office with the "serving machine", since
we have ">con:" on the kermit statement he will see the ongoing transactions.
I have modified the program so that a ^C issued at the main console of the
serving machine will abort the program and return to DOS.  Also, that means
now that a ^C at any point while sending or receiving, even if you are not a
server, will abort the program (you might have to follow the ^C by a bunch of
enter depressions, depending on where you caught the program hanging).

I will next try to think of some way to make this Kermit version do some type
of elementary mailing task with unix go-betweens.

  Herm Fischer  (HFischer@eclb)

-------
12-Jan-84 00:31:22-EST,1769;000000000000
Return-Path: <@CUCS20:HOROWITZ@USC-ISIF>
Received: from CUCS20 by CU20B with DECnet; 12 Jan 84 00:31:10 EST
Received: from USC-ISIF.ARPA by COLUMBIA-20.ARPA with TCP; Thu 12 Jan 84 00:28:38-EST
Date: 10 Jan 1984 20:37:13 PST
From: HOROWITZ@USC-ISIF
Subject: kermit - and the spreadsheet
To:   info-kermit@COLUMBIA-20

Hi,
I hope you can help me on this one.  I had been using an H-19 connected
via a Racal Vadic 3451 modem to a VAX750 running Unix 4.1.  I replaced
the h-19 by my ibm pc which has 442K and a color graphics monitor
and ran kermit to connect to the VAX.  All appeared to be well until
i executed my spreadsheet program.  Instead of getting an empty spreadsheet
that looked like:

 a1  a      b     c     d     e     f     g
 1
 2
 3
 4
 5
 6
 7
 8
 9
10

Note that on my h19 the column and row labels appear in reverse video.
I instead get

a1  a      b     c     d     e     f     g
 2
 3
 4
 5
 6
 7
 8
 9
10

For some reason it loses the indicator for row 1.  I believe it is lost
on the far right of the monitor, but i cannot see it.  If i try to place a
number in location a1, it does so in what appears on the screen to be
location a2. Also the arrow keys don't work but other keys behave properly.

Is there some advice or help you can give me?

I did change my terminal type to vt52, but that produced other problems.
(the field cursor was not visible and the arrow keys didn't work)
Besides the spreadsheet doesn't look as nice on a vt52 as that terminal
requires an extra space for reverse video and so the spreadsheet doesn't
display the row and column indicators in reverse video as it
does on my h19.  setting the terminal type to vt100 was also fruitless.

Ellis Horowitz
-------
12-Jan-84 00:52:12-EST,1321;000000000000
Return-Path: <@CUCS20:HOROWITZ@USC-ISIF>
Received: from CUCS20 by CU20B with DECnet; 12 Jan 84 00:52:08 EST
Received: from USC-ISIF.ARPA by COLUMBIA-20.ARPA with TCP; Thu 12 Jan 84 00:50:14-EST
Date: 11 Jan 1984 21:49:00 PST
From: HOROWITZ@USC-ISIF
Subject: kermit and the spreadsheet
To:   info-kermit@COLUMBIA-20

This is my second note on a problem with kermit that i hope you can help
me with.  Since i now understand the problem a bit better i thought i would follow
my first note with this one even before you answered the first.

I am using kermit on my ibm-pc and connecting it to our vax 750
which runs unix 4.1.  kermit is emulating an h-19 according to
its status command.  My problem is that when i run the spreadsheet
program on the vax the number 1 (indicating the first row) does not
appear.  apparently it has disappeared somewhere on the line above.
  this problem also occurred on my h-19 when i first got it.
by going off-line and typing esc v it redefined the wrap so that
the spreadsheet was properly displayed. not knowing how to do this in kermit
 i tried to redefine the
kermit end-of-line character and i set it  to every
value between 0 and 31 without effect.

I hope this clarifies the problem for you.
thanks in advance for your assistance.
ellis horowitz
-------
13-Jan-84 00:37:23-EST,2543;000000000000
Return-Path: <@CUCS20:HFISCHER@USC-ECLB>
Received: from CUCS20 by CU20B with DECnet; 13 Jan 84 00:37:18 EST
Received: from USC-ECLB by COLUMBIA-20.ARPA with TCP; Thu 12 Jan 84 19:36:28-EST
Date: 12 Jan 1984 1633-PST
From: HFISCHER%USC-ECLB@SRI-NIC
Subject: Test Version of PC Kermit has TAKE added
To:   info-kermit at COLUMBIA-20

A  suggestion  by  cc.fdc  for a TAKE command in PC kermit has gnawed at
me, especially now that I am trying to use Kermit here to  do  our  mail
integration  to  Unixes.  (TAKE  redirects  Kermit inputs temporarily to
come from a named file.) We need to be  able  to  set  up  a  number  of
parameters  easily,  and it is a pain to type in the baud, port, parity,
and all that rot every time you load, because if you are  like  me,  you
use  three  different computers, on different networks, different ports,
and at different baud rates. Then  again,  some  others  complain  about
simple  things  like  Hayes  (&Qubie)  modem  dialing  commands, which a
computer should be capable of assisting, and it seemed  related  to  the
take issue.

I  have  added  TAKE  filename to the PC kermit test version on the net,
accessible at node usc-eclb as <HFischer>PCK20.new (assembly  code)  and
<HFischer>PCK20.exe (8 bit mode executable code file).

TAKE  uses  a  full  pathname, so you can place your take files (such as
EMACS and function key definitions) in a  "\bin"  like  directory.  This
function  checks for the presence of DOS 2 to operate. It allows nesting
up to ten levels (unless your CONFIG.SYS restricts open files  count  to
less).  A  take  file  on  the  command line will be executed before the
console is accessed. A special feature allows  a  take  file  to  "take"
from  the  user's  keyboard within its nesting levels, by asking for the
device "<". If a user enters EXIT he pops  back  to  the  nesting  level
from  whence  he was called. Eof on a take file pops nesting levels back
to where it was called from. If a take file has the EXIT command in  it,
it exits directly to DOS.

Additionally  there  now  is  a  SET CONSOLE [xx;xx;p command, for those
with DOS 2's ANSI.SYS  handler.  This  allows  the  PC  user  to  define
keystrokes  (such  as  the arrows and function keys) to be meaningful to
his host computer (EMACS vs INed), and for  his  autodialer  and  login.
The  [xx;xx;p  follows the DOS manual page 13-11. I will distribute TAKE
files with SET CONSOLE commands for EMACS and INed as they get done.

   Herm Fischer

-------
13-Jan-84 10:33:17-EST,1132;000000000000
Return-Path: <@CUCS20:jim@rand-unix>
Received: from CUCS20 by CU20B with DECnet; 13 Jan 84 10:33:09 EST
Received: from rand-unix by COLUMBIA-20.ARPA with TCP; Fri 13 Jan 84 10:29:59-EST
Date: Friday, 13 Jan 1984 07:20-PST
To: HOROWITZ@USC-ISIF
Subject: Re: kermit and the spreadsheet
Cc: info-kermit@COLUMBIA-20
In-reply-to: Your message of 11 Jan 1984 21:49:00 PST.
From: jim@rand-unix

Ellis -
    Remember me?  I haven't seen you around for quite a while.
I switched from an H89 to a PC with Kermit to a Vax runnin 4.1BSD,
and have had no trouble using it with Jim Guyton's termcap entry for
all screen-oriented stuff.  If this doesn't work with your spreadsheet,
at least it may give a starting point.

    Jim Gillogly

# first pass at a termcap entry for the ibm pc kermit
# this is a vt52 emulator with some h19 features added
# to do: check delay on screen clear
# jdg 7/6/83
dv|vt52|dec vt52:\
    :bs:cd=\EJ:ce=\EK:cl=\EH\EJ:cm=\EY%+ %+ :co#80:li#24:nd=\EC:\
    :pt:sr=\EI:up=\EA:ku=\EA:kd=\EB:kr=\EC:kl=\ED:
ii|ibm|kermit vt52 extension:\
    :al=\EL:cd=\EJ:ce=\EK:dc=\EN:dl=\EM:\
    :se=\Eq:so=\Ep:tc=vt52:
14-Jan-84 21:17:56-EST,2026;000000000000
Return-Path: <@CUCS20:BRACKENRIDGE@USC-ISIB>
Received: from CUCS20 by CU20B with DECnet; 14 Jan 84 21:17:52 EST
Received: from USC-ISIB.ARPA by COLUMBIA-20.ARPA with TCP; Sat 14 Jan 84 21:16:46-EST
Date: 14 Jan 1984 1814-PST
Subject: Kermit IP/TCP FTP
From: Billy <BRACKENRIDGE@USC-ISIB>
To: info-kermit@COLUMBIA-20
cc: postel@USC-ISIB

I would like to propose KRFC??? that someone make a program on
either Unix or Tops-20 that combine Kermit and an IP/TCP based
FTP. This program would have the same user interface as the
standard Kermit with the addition of two new commands: CONNECT
(to host) and LOGIN.

CONNECT would establish an IP/TCP FTP session, and LOGIN would
allow a user to login to that remote host and connect to a
particular directory.

Kermit would behave identically to the current implementation
with the exception that the files transferred could be from any
directory on any machine on the internet. Wild carding would be
supported in the same fashion it is currently by Kermit.

This would be particularly useful to those of us who run large
mailing lists. There are many recipients of computer mail who are
not directly connected to the ARPA or MIL-NETS, but who need
to transfer files to or from these mailing list central sites.

This scheme would ensure an orderly controlled access to the
network at minimal cost to the host site. It is important that
the connection between FTP and Kermit be on a packet per packet
basis as the Kermit host site should not be required to store
intermediate temporary files.

To make this scheme useful we would have to publish the phone number
of these Kermit FTP servers. If necessary access could be restricted
to specific hosts or specific directories. Jon Postel has assured me
that if such a program existed he would favor installing such a
public phone number at ISI to aid him in the distribution of his
network RFC mailing list.

As of yet I haven't found anyone willing to do the necessary programming.
-------
16-Jan-84 18:07:09-EST,2762;000000000000
Return-Path: <@CUCS20:ALBERS@MIT-ML>
Received: from CUCS20 by CU20B with DECnet; 16 Jan 84 18:07:00 EST
Received: from MIT-ML by COLUMBIA-20.ARPA with TCP; Mon 16 Jan 84 18:06:07-EST
Date: 16 January 1984 18:06 EST
From: Jon P. Albers <ALBERS @ MIT-ML>
Subject: Setting up KERMIT for the OCC-exec (or CPM+(3.0))
To: kpno!brown @ LBL-CSAM
cc: info-kermit @ COLUMBIA-20

I'm sorry I couldn't get back to you sooner, my host had a lot of problems
handeling and routing the mail..  I'll tell you how I did it (get KERMIT
up on the Exec):

1. I ftp'ed the GENERIC kermit (ker:CPMGENERI.ASM) from columbia-20,
2. transfered it to my micro by modem7.  If you don't have it, you can try
   capturing KERMIT to your disk.
3. I put it, MAC.COM, and HEXCOM.COM (MAC and HEXCOM are on CP/M disk #3 as
   supplied to you from OCC) on a blank, formatted disk.
4. assembled it using MAC.  To do it, put a blank, formatted disk in drive B:,
   and the disk you made in step 3 in drive a:.  Then, I typed the following:

MAC CPMGENERI.ASM $AA HB SZ PZ

   After you type that, and press return, the drive will begin running, and
   alternating.  After a short time, they will stop, and a message will be
   printed on the screen.  You now have CPMGENERI.HEX on drive B:.
5. Now, type:

B:

And return to log on to drive B:, then type:

a:HEXCOM B:CPMGENERI.HEX

And a return.  Again, the drives will spin, and in a moment, you will have
CPMGENERI.COM, and executable at that!

OOPS!  I forgot to tell you, use WordStar, and edit CPMGENERI.ASM as a non-
document (the 'N' option from the 'not editing' menu).  Look down the first
few pages and find something that looks like this:

ROBIN    EQU    TRUE

Change the TRUE to FALSE (If it is FALSE already, leaeve it that way), and
then look for:

CPM3    EQU    FALSE

And change the FALSE to TRUE (If it is TRUE already.........) and save it,
deleteing the file CPMGENERI.BAK.

This should go between steps 3 and 4.

6. Use SYSCOPY, and put a copy of the system on the disk you put CPMGENERI.COM
on (the one in drive B:).
7. Use the program SETUP, get the system from drive B:, and go to the option
   COMMUNICATIONS PORT.  Change the device assignment to AUXIN:/AUXOUT:, and
   the baud rate to what you will be using the Executive in KERMIT at, most
   likely 300 or 1200.  (Note:, when you change baudrates, you must change it
   here (via SETUP) before you can use KERMIT at that baud rate.)
8. Exit the program and save the system setup to drive b:, and press the
   reset button.  Now boot up on the new drive (withCPMGENERI.COM on it) and
   execute CPMGENERI.COM.  You can now use KERMIT.


If you need more info, contact me at:   ALBERS@ML


                        Jon Albers


18-Jan-84 22:01:56-EST,531;000000000000
Return-Path: <@CUCS20:Iglesias@uci-750a>
Received: from CUCS20 by CU20B with DECnet; 18 Jan 84 22:01:48 EST
Received: from UCI-750a by COLUMBIA-20.ARPA with TCP; Wed 18 Jan 84 22:00:14-EST
Date: 18 Jan 84 19:01:25 PST (Wed)
To: info-kermit@Columbia-20
Subject: Kermit for CP-6
From: Mike Iglesias <iglesias@uci-750a>

Is there a KERMIT for a Honeywell CP-6 system?  Is anyone in the
process of writing one?  Is anyone thinking about writing one?

Thanks for any info.

Mike Iglesias
University of California, Irvine
19-Jan-84 09:43:55-EST,734;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 19 Jan 84 09:43:50 EST
Date: Thu 19 Jan 84 09:42:47-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: Kermit for CP-6
To: [e-mail], info-kermit@CUCS20
In-Reply-To: Message from "Mike Iglesias <iglesias@uci-750a>" of Wed 18 Jan 84 19:01:25-EST

To my knowledge, no one has done anything for any Honeywell system except those
that run Multics.  There are implementations of KERMIT in various high-level
languages that would be good starting points -- PL/I, Fortran, Pascal, etc.
Anyone who decides to embark on such a venture should let me know first, so I
can prevent others from duplicating the effort.  - Frank
-------
20-Jan-84 19:41:36-EST,653;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 20 Jan 84 19:41:33 EST
Received: from USC-ECLB.ARPA by COLUMBIA-20.ARPA with TCP; Fri 20 Jan 84 19:41:11-EST
Date: 20 Jan 1984 1636-PST
From: HFISCHER at USC-ECLB.ARPA
Subject: Keyboard Cursor and Function Key Setups for Kermit
To:   info-kermit at COLUMBIA-20

Two sets of files in my directory on ECLB contain console setups for
my test version of kermit (the current one, PCK20.NEW.3).  These are:

  <HFischer>PCINed.* for unix'es INed editor (from Interactive Sys.)
  <  "     >PCemcs.* for emacs keyboard cursor controls

Herm Fischer
-------
21-Jan-84 16:11:38-EST,3145;000000000000
Return-Path: <@CUCS20:gts%G.CC@Berkeley>
Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 16:11:32 EST
Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 16:10:57-EST
Received: by UCB-VAX.ARPA (4.22/4.19)
    id AA29266; Sat, 21 Jan 84 13:10:01 pst
Received: by ucbpopuli.CC.Berkeley.ARPA
    (4.13/4.10) id AA12703; Sat, 21 Jan 84 12:58:47 pst
Date: Sat, 21 Jan 84 12:58:47 pst
From: gts%ucbpopuli.CC@Berkeley
Message-Id: <[e-mail]>
To: INFO-Kermit@COLUMBIA-20
Subject: Kermit CP/M v3.6 Bugs and Modifications (1 of 11)

This is the cover letter for a series of ten (10) modifications and corrections
to CP/M Kermit Version 3.6 (cpmbase.m80 ftped on 83-12-12).

Since we must modify kermit for our use here, it would be nice if kermit
distributions could be set up in such a way that our local mods can be fitted
to new distributions without intensive re-implementation.  Distribution of the
complete new source after heavy modification makes such tools as UNIX diff
virtually unusable.  A simple way to do this would be to sequence the entire
source and use a modification name plus sequence for individual modification
sets.  This serves both to identify the mods associated with a particular
fix or change, and to permanently identify lines that are unchanged.

Below is our current bug list for v3.6:

These are the known bugs in CP/M 80 Kermit Columbia Version 3.6 as modified
and distributed by us.  Version history is:

COL36    Columbia's release version 3.6 of 83-12-12.
UCB3614    Gts reinstall of COL36 as of 84-01-21.

83-11    FIXED UCB3604    partially fixed COL36
    GTS: VT52 emulation does not work properly in most versions.  Caused by
    absence of cursor addressing and errors in the vt52 to terminal table
    (ttab:); entries not all exactly four bytes.

83-11    FIXED UCB3606
    GTS: If a duplicate file name is received kermit crashes with "file r/o"
    if the existing file is $r/o.  This is because the attribute bits are
    not cleared in the file control block (fcb) after the initial open and,
    hence, the modified filename is created $r/o and kermit cannot write it!

83-11    FIXED UCB3607
    GTS: Kermit accepts lowercase filenames on receive; CP/M cannot use.

84-01    unsolved
    GTS: Filenames geinve to kermit cannot contain "-", "&", and probably
    other characters perfectly valid in CP/M.

84-01    unsolved
    GTS: When ^Z or ^X is used to terminate a send or receive, kermit says
    "Unable to receive ack from host" rather than something informative.
    Other circumstances give equally obtuse messages.

84-01    unsolved
    GTS: When ^Z or ^X is used to terminate a send or receive with CMS
    Kermit, it doesnt stop immediately but seems to mimick continuing to
    the end of the file.  Probably our CMS Kermit does not respond to
    EOF under these circumstances????

83-12    NEEDED
    GTS: When talking to UCB cal, a BREAK must be used to interrupt output
    since cal is half-duplex.  Kermit cannot generate a BREAK.


Greg Small    [e-mail]    or gts%ucbpopuli.Berkeley
        [e-mail]    or gts@ucbunixg
21-Jan-84 16:25:35-EST,892;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 16:25:32 EST
Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 16:25:03-EST
Date: Sat 21 Jan 84 13:16:48-PST
From: Carl Fussell <[e-mail]>
Subject: rt kermit
To: [e-mail]
Address:  Santa Clara University


Has anyone done a kermit for RT-11 in macro?  Would like to find out
before I attempt it.   Have been "playing" with the omsi version but
have strange things occuring...    (arbitrarily, it will work fine,
then next time, it destroys the contents of SY:)   problem is I do
not have omsi pascal and perhaps there is some library problems  altho'
ODT seems to show me every thing set up properly....   anyway,
if anyone has a macro version, I would very much appreciate hearing...

thanx...     Carl
-------
21-Jan-84 16:37:48-EST,1306;000000000000
Return-Path: <@CUCS20:gts%G.CC@Berkeley>
Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 16:37:40 EST
Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 16:30:15-EST
Received: by UCB-VAX.ARPA (4.22/4.19)
    id AA29421; Sat, 21 Jan 84 13:29:22 pst
Received: by ucbpopuli.CC.Berkeley.ARPA
    (4.13/4.10) id AA13177; Sat, 21 Jan 84 13:20:58 pst
Date: Sat, 21 Jan 84 13:20:58 pst
From: gts%ucbpopuli.CC@Berkeley
Message-Id: <[e-mail]>
To: INFO-Kermit@COLUMBIA-20
Subject: CPMBASE.M80 Mod UCB3607 (6 of 11)


The following fix or modification is to CPMBASE.M80 Version 3.6 ftped 12-12-83.
The form similar to that of UNIX diff.

Greg Small    [e-mail]    or gts%ucbpopuli.Berkeley
        [e-mail]    or gts@ucbunixg
--------------------------------------------------------------------------------
0a1
>
> ;UCB    36.07asm    83-10-31    gts, CFO            ;UCB3607
> ; Force received file names to upper case (gofil2:, gofil6:).        ;UCB3607
>
2100a
>     cpi    'a'        ; Force upper case            ;UCB3607
>     jm    gofl2a        ;                    ;UCB3607
>     ani    5Fh        ;                    ;UCB3607
> gofl2a:                ;                    ;UCB3607
2133a
>     cpi    'a'        ; Force upper case            ;UCB3607
>     jm    gofl6a        ;                    ;UCB3607
>     ani    5Fh        ;                    ;UCB3607
> gofl6a:                ;                    ;UCB3607
21-Jan-84 16:50:07-EST,1349;000000000000
Return-Path: <@CUCS20:gts%G.CC@Berkeley>
Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 16:50:01 EST
Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 16:31:12-EST
Received: by UCB-VAX.ARPA (4.22/4.19)
    id AA29435; Sat, 21 Jan 84 13:30:13 pst
Received: by ucbpopuli.CC.Berkeley.ARPA
    (4.13/4.10) id AA13155; Sat, 21 Jan 84 13:19:43 pst
Date: Sat, 21 Jan 84 13:19:43 pst
From: gts%ucbpopuli.CC@Berkeley
Message-Id: <[e-mail]>
To: INFO-Kermit@COLUMBIA-20
Subject: CPMBASE.M80 Fixes UCB3605 (4 of 11)


The following fix or modification is to CPMBASE.M80 Version 3.6 ftped 12-12-83.
The form similar to that of UNIX diff.

Greg Small    [e-mail]    or gts%ucbpopuli.Berkeley
        [e-mail]    or gts@ucbunixg
--------------------------------------------------------------------------------
0a1
>
> ;UCB    36.05asm    83-10-23    gts, CFO            ;UCB3605
> ; Changes for assembly under RMAC.                    ;UCB3605
> ; Local is a reserved name and is changed to locall.            ;UCB3605
> ; Title and aseg pseudo ops inserted. Title gives warning in ASM.    ;UCB3605
>
172a
>
>     ASEG                                ;UCB3605
3737c
<     jmp local        ; 06H SET LOCAL
---
>     jmp locall        ; 06H SET LOCAL                ;UCB3605
3925c
< local:    lxi d,ontab
---
> locall:    lxi d,ontab                            ;UCB3605
21-Jan-84 17:02:17-EST,1489;000000000000
Return-Path: <@CUCS20:gts%G.CC@Berkeley>
Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 17:02:13 EST
Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 16:32:13-EST
Received: by UCB-VAX.ARPA (4.22/4.19)
    id AA29453; Sat, 21 Jan 84 13:31:19 pst
Received: by ucbpopuli.CC.Berkeley.ARPA
    (4.13/4.10) id AA13212; Sat, 21 Jan 84 13:22:15 pst
Date: Sat, 21 Jan 84 13:22:15 pst
From: gts%ucbpopuli.CC@Berkeley
Message-Id: <[e-mail]>
To: INFO-Kermit@COLUMBIA-20
Subject: CPMBASE.M80 Fix UCB3609 (8 fo 11)


The following fix or modification is to CPMBASE.M80 Version 3.6 ftped 12-12-83.
The form similar to that of UNIX diff.

Greg Small    [e-mail]    or gts%ucbpopuli.Berkeley
        [e-mail]    or gts@ucbunixg
--------------------------------------------------------------------------------
0a1
>
> ;UCB    36.09asm    84-01-05    gts, CFO            ;UCB3609
> ; Fix misplaced "if debug" at line 2399.                ;UCB3609
> ; Fix split line for "baudtb: ...baud ra","te.." for brain.        ;UCB3609
> ; Change "If debug" for rppos:/sppos: to "IF debug AND brain".        ;UCB3610
>
2399d
< IF debug
2403a
> IF debug                                ;UCB3609
5444,5445c
< baudtb:    db    ('A'-100O),esc,'~kType the letter corresponding with the baud ra
< te desired.'
---
> baudtb:    db    ('A'-100O),esc,'~kType the letter corresponding with the baud rate desired.'    ;UCB3609
5504c
< IF debug
---
> IF debug AND brain                            ;UCB3609
21-Jan-84 17:14:38-EST,1583;000000000000
Return-Path: <@CUCS20:gts%G.CC@Berkeley>
Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 17:14:31 EST
Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 16:33:08-EST
Received: by UCB-VAX.ARPA (4.22/4.19)
    id AA29464; Sat, 21 Jan 84 13:32:16 pst
Received: by ucbpopuli.CC.Berkeley.ARPA
    (4.13/4.10) id AA13171; Sat, 21 Jan 84 13:20:21 pst
Date: Sat, 21 Jan 84 13:20:21 pst
From: gts%ucbpopuli.CC@Berkeley
Message-Id: <[e-mail]>
To: INFO-Kermit@COLUMBIA-20
Subject: CPMBASE.M80 Fix UCB3606 (5 of 11)


The following fix or modification is to CPMBASE.M80 Version 3.6 ftped 12-12-83.
The form similar to that of UNIX diff.

Greg Small    [e-mail]    or gts%ucbpopuli.Berkeley
        [e-mail]    or gts@ucbunixg
--------------------------------------------------------------------------------
0a1
>
> ;UCB    36.06asm    83-10-23    gts, CFO            ;UCB3606
> ; Fix more problems with cp/m 2.2 attribute bits (see also [UTK013]).    ;UCB3606
> ; Trim attribute bits from fcb after each open when file to be received    ;UCB3606
> ; already exists (gofil8:) so that subsequent file creation with    ;UCB3606
> ; modified name does not have attribute bits set (e.g. $r/o)!        ;UCB3606
>
2180a
>     lxi    h,fcb        ; Trim off any cp/m 2.2 attribute bits    ;UCB3606
>     mvi    c,1+8+3        ; so they do not effect the new file.    ;UCB3606
> gofl82:    mov    a,m        ;                    ;UCB3606
>     ani    7Fh        ;                    ;UCB3606
>     mov    m,a        ;                    ;UCB3606
>     inx    h        ;                    ;UCB3606
>     dcr    c        ;                    ;UCB3606
>     jnz    gofl82        ;                    ;UCB3606
21-Jan-84 17:26:50-EST,1824;000000000000
Return-Path: <@CUCS20:gts%G.CC@Berkeley>
Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 17:26:46 EST
Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 16:34:09-EST
Received: by UCB-VAX.ARPA (4.22/4.19)
    id AA29483; Sat, 21 Jan 84 13:33:16 pst
Received: by ucbpopuli.CC.Berkeley.ARPA
    (4.13/4.10) id AA13224; Sat, 21 Jan 84 13:23:50 pst
Date: Sat, 21 Jan 84 13:23:50 pst
From: gts%ucbpopuli.CC@Berkeley
Message-Id: <[e-mail]>
To: INFO-Kermit@COLUMBIA-20
Subject: CPMBASE.M80 Fix UCB3612 (10 of 11)


The following fix or modification is to CPMBASE.M80 Version 3.6 ftped 12-12-83.
The form similar to that of UNIX diff.

Greg Small    [e-mail]    or gts%ucbpopuli.Berkeley
        [e-mail]    or gts@ucbunixg

This bug may have caused some wierdness if received junk overflowed the buffer
and clobbered later stuff used in some versions.  Normally rare....
--------------------------------------------------------------------------------
0a1
>
> ;UCB    36.12asm    84-01-15    gts, CFO            ;UCB3612
> ; Inpkt: prevent recpkt: buffer overflow from clobbering other storage.    ;UCB3612
> ;        If overflow, restart packet collection (see UCB3603).        ;UCB3612
> ; Inpkt: store a cariage-return beyond the received packet to stop    ;UCB3612
> ;        rpack: if some error confuses it.                ;UCB3612
>
2901a
>     lxi    d,-recpkx    ; Start over if packet buffer overflow    ;UCB3612
>     dad    d        ;                    ;UCB3612
>     jc    inpkt        ;                    ;UCB3612
2904a
>     lhld    pktptr        ; Reload packet pointer            ;UCB3612
>     mvi    m,cr        ; Set a carriage-return to stop rpack:    ;UCB3612
2906a
>     inx h            ; Point to next char.            ;UCB3612
2908d
<     inx h            ; Point to next char.
5956a
> recpkx:    db    cr,'$'        ; =       =      =       buffer limit    ;UCB3612
21-Jan-84 17:38:55-EST,1831;000000000000
Return-Path: <@CUCS20:gts%G.CC@Berkeley>
Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 17:38:51 EST
Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 16:35:08-EST
Received: by UCB-VAX.ARPA (4.22/4.19)
    id AA29497; Sat, 21 Jan 84 13:34:15 pst
Received: by ucbpopuli.CC.Berkeley.ARPA
    (4.13/4.10) id AA13112; Sat, 21 Jan 84 13:18:13 pst
Date: Sat, 21 Jan 84 13:18:13 pst
From: gts%ucbpopuli.CC@Berkeley
Message-Id: <[e-mail]>
To: INFO-Kermit@COLUMBIA-20
Subject: CPMBASE.M80 Mod UCB3603 (2 of 11)


The following fix or modification is to CPMBASE.M80 Version 3.6 ftped 12-12-83.
The form similar to that of UNIX diff.

Greg Small    [e-mail]    or gts%ucbpopuli.Berkeley
        [e-mail]    or gts@ucbunixg
--------------------------------------------------------------------------------
0a1
>
> ;UCB    36.03asm    83-08-??    vaf, CS                ;UCB3603
> ; Improve packet receive reliability under error conditions.        ;UCB3603
> ; Inpkt: skip leading junk until soh and restart if another soh.    ;UCB3603
> ; Rpack: did check for imbedded soh's, but this only worked if the    ;UCB3603
> ; buffer was allowed to overflow.  Rpack: not changed to remove soh    ;UCB3603
> ; checks, they do not cost much.                    ;UCB3603
>
2894a
> inpkt1:    call    inchr        ; Get first character.            ;UCB3603
>      jmp    r        ;  Return failure.            ;UCB3603
>     cpi    soh        ; is it the beginning of a packet?    ;UCB3603
>     jnz    inpkt1        ; if not, ignore leading junk        ;UCB3603
>     jmp    inpkt3        ; else go put it in the packet        ;UCB3603
2896a
>     cpi    soh        ; is it a new begining of packet?    ;UCB3603
>     jnz    inpkt3        ; If not continue            ;UCB3603
>     lxi    h,recpkt    ; else throw away what you've got so far;UCB3603
>     shld    pktptr        ;                    ;UCB3603
> inpkt3:                ;                    ;UCB3603
>
21-Jan-84 17:51:05-EST,2045;000000000000
Return-Path: <@CUCS20:gts%G.CC@Berkeley>
Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 17:50:59 EST
Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 16:35:41-EST
Received: by UCB-VAX.ARPA (4.22/4.19)
    id AA29507; Sat, 21 Jan 84 13:34:51 pst
Received: by ucbpopuli.CC.Berkeley.ARPA
    (4.13/4.10) id AA13229; Sat, 21 Jan 84 13:24:19 pst
Date: Sat, 21 Jan 84 13:24:19 pst
From: gts%ucbpopuli.CC@Berkeley
Message-Id: <[e-mail]>
To: INFO-Kermit@COLUMBIA-20
Subject: CMPBASE.M80 Mod UCB3614 (11 of 11)


The following fix or modification is to CPMBASE.M80 Version 3.6 ftped 12-12-83.
The form similar to that of UNIX diff.

Greg Small    [e-mail]    or gts%ucbpopuli.Berkeley
        [e-mail]    or gts@ucbunixg
--------------------------------------------------------------------------------
0a1
>
> ;UCB    36.14asm    83-08-??    vaf, CS and gts, CFO        ;UCB3614
> ; Implement fuzzy timer for inchr: auto-retry, some machines only.    ;UCB3614
> ; Timeout uses a two byte counter giving 65536 repetitions of the    ;UCB3614
> ; inchr: loop.  This gave 13.5 seconds on a TRS-80 Model 16.        ;UCB3614
>
2598c
> inchr:    lxi    h,0000h        ; Reset fuzzy timer            ;UCB3614
>     shld    inchr6+1    ;                    ;UCB3614
> inchr0:    in mnprts        ; Get the port status into A        ;UCB3614
2604c
<     jz inchr        ; If not go look for another char.
---
>     jz inchr6        ; If not go look for another char.    ;UCB3614
2608,2609c
<     jnz inchr4        ; If not go look for another char.
<     ret
---
>     rz            ; If so, return.
2616c
<     jnz inchr        ; No, try for another character
---
>     jnz inchr6        ; No, try for another character        ;UCB3614
2621a
> inchr6:    lxi    h,0000h        ; Increment fuzzy time-out        ;UCB3614
>     inx    h        ;                     ;UCB3614
>     shld    inchr6+1    ; (65,536 * loop time)            ;UCB3614
>     mov    a,h        ; (Retry if not timeout)        ;UCB3614
>     ora    l        ;                    ;UCB3614
>     jnz    inchr0:        ;                    ;UCB3614
>     call    updrtr        ; Count as retry            ;UCB3614
>     ret            ; and return to do the retry        ;UCB3614
>
21-Jan-84 18:03:17-EST,3315;000000000000
Return-Path: <@CUCS20:gts%G.CC@Berkeley>
Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 18:03:12 EST
Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 16:36:37-EST
Received: by UCB-VAX.ARPA (4.22/4.19)
    id AA29515; Sat, 21 Jan 84 13:35:46 pst
Received: by ucbpopuli.CC.Berkeley.ARPA
    (4.13/4.10) id AA13129; Sat, 21 Jan 84 13:18:53 pst
Date: Sat, 21 Jan 84 13:18:53 pst
From: gts%ucbpopuli.CC@Berkeley
Message-Id: <[e-mail]>
To: INFO-Kermit@COLUMBIA-20
Subject: CPMBASE.M80 Mod UCB3604 (3 of 11)


The following fix or modification is to CPMBASE.M80 Version 3.6 ftped 12-12-83.
The form similar to that of UNIX diff.

Greg Small    [e-mail]    or gts%ucbpopuli.Berkeley
        [e-mail]    or gts@ucbunixg
--------------------------------------------------------------------------------
0a1
>
> ;UCB    36.04asm    83-08-??    vaf, CS and gts, CFO        ;UCB3604
> ; Fix Kaypro II ttab: and clrlin: clear to eos + eol.            ;UCB3604
> ; Remove default off for vtflg: now that ttab: fixed.            ;UCB3604
> ; Add clear to end of line to most positioning strings.            ;UCB3604
> ; Fix scrend: to past send/receive display.                ;UCB3604
> ; When ibmflag, do not display null, xon, xoff or del (kpii graphics).    ;UCB3604
>
3283a
> IF kpII                                    ;UCB3604
>     lda ibmflg        ; on the Kaypro II the following chars    ;UCB3604
>     ora a             ; are displayed as greek symbols ...    ;UCB3604
>     jz prtch0        ;                    ;UCB3604
>         mov a,e                 ; Get the char for testing.        ;UCB3604
>         cpi 0                   ; if the char is a null            ;UCB3604
>         jz prtchr               ; ignore it                ;UCB3604
>         cpi xon                 ; likewise for xons            ;UCB3604
>         jz prtchr               ;                    ;UCB3604
>         cpi xoff                ; and xoffs                ;UCB3604
>         jz prtchr               ;                     ;UCB3604
>         cpi del                    ; and deletes                ;UCB3604
>         jz prtchr               ;                    ;UCB3604
> prtch0:                ;                    ;UCB3604
> ENDIF    ;kpII                                ;UCB3604
>
5695c
< clrlin:    db    cr,esc,'T$'        ; Clear line.
---
> clrlin:    db    cr,18H,'$'        ; Clear line.            ;UCB3604
5699c
< scrfln:    db    esc,'=%+',esc,'T$'     ; Place for file name.
---
> scrfln:    db    esc,'=%+',esc,18h,'$'     ; Place for file name.        ;UCB3604
5701,5703c
< scrend:    db    cr,lf,'$'
< screrr:    db    esc,'=& $'        ; Place for error messages.
< curldn:    db    esc,'=$'        ; Cursor lead-in     [UTK016]
---
> scrend:    db    cr,esc,'=( ',17h,'$'    ; Place for prompt after done    ;UCB3604
> screrr:    db    esc,'=& ',18h,'$'    ; Place for error messages.    ;UCB3604
> curldn:    db    cr,esc,'=$'        ; Cursor lead-in     [UTK016]    ;UCB3604
5714,5715c
< tj:    db    esc,'Y$',0        ; Clear to end of screen.
< tk:    db    esc,'T$',0        ; Clear to end of line.
---
> tj:    db    17H,'$',0,0        ; Clear to end of screen.    ;UCB3604
> tk:    db    18H,'$',0,0        ; Clear to end of line.        ;UCB3604
5894c
< IF NOT (robin OR gener OR rainbo OR dmII OR cpm3 OR kpii)
---
> IF NOT (robin OR gener OR rainbo OR dmII OR cpm3)            ;UCB3604
5896,5900c
< ENDIF                ;NOT (robin OR gener OR rainbo OR dmII OR cpm3
<                 ; OR kpii)
< IF kpii
< vtflg:    db    0        ; VT52 emulation flag (default off).
< ENDIF                ;kpii
---
> ENDIF    ;NOT (robin OR gener OR rainbo OR dmII OR cpm3)            ;UCB3604
21-Jan-84 18:16:27-EST,3983;000000000000
Return-Path: <@CUCS20:gts%G.CC@Berkeley>
Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 18:16:21 EST
Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 16:37:50-EST
Received: by UCB-VAX.ARPA (4.22/4.19)
    id AA29527; Sat, 21 Jan 84 13:36:56 pst
Received: by ucbpopuli.CC.Berkeley.ARPA
    (4.13/4.10) id AA13203; Sat, 21 Jan 84 13:21:42 pst
Date: Sat, 21 Jan 84 13:21:42 pst
From: gts%ucbpopuli.CC@Berkeley
Message-Id: <[e-mail]>
To: INFO-Kermit@COLUMBIA-20
Subject: CPMBASE.M80 Mod UCB3608 (7 of 11)


The following fix or modification is to CPMBASE.M80 Version 3.6 ftped 12-12-83.
The form similar to that of UNIX diff.

Greg Small    [e-mail]    or gts%ucbpopuli.Berkeley
        [e-mail]    or gts@ucbunixg
--------------------------------------------------------------------------------
0a1
>
> ;UCB    36.08asm    83-08-??    vaf, CS and gts, CFO        ;UCB3608
> ; Split screen dependant trs-80 code into original for lifeboat cp/m    ;UCB3608
> ; (trs80lb) and newer for Pickles and Trout cp/m (trs80pt).        ;UCB3608
> ; Do not display xon, it is a graphics character for P+T cp/m.        ;UCB3608
> ; Note: trs80 variable must also be set.                ;UCB3608
>
192c
< trs80    EQU    FALSE        ; For TRS-80 model II (Lifeboat CP/M 2.25C)
---
> trs80    EQU    FALSE        ; For TRS-80 model II            ;UCB3608
> trs80lb    EQU    FALSE        ; Lifeboat 2.25C  CP/M Display        ;UCB3608
> trs80pt    EQU    FALSE        ; Pickles + Trout CP/M Display        ;UCB3608
442a
> ;NEEDS display definition (e.g., trs80lb, trs80pt)            ;UCB3608
3282a
>
> IF trs80pt                                ;UCB3608
>     cpi    xon        ; For P+T cp/m, xon is a graphic    ;UCB3608
>     jz    prtchr        ; so ignore it.                ;UCB3608
> ENDIF    ;trs80pt                            ;UCB3608
3632c
< IF (osbrn1 or apple OR trs80 OR kpii);                [UTK016]
---
> IF (osbrn1 or apple OR trs80lb OR kpii);            [UTK016];UCB3608
3639c3546
< ENDIF                ;(osbrn1 or apple OR trs80 OR kpii)[UTK016]
---
> ENDIF    ;(osbrn1 or apple OR trs80lb OR kpii)[UTK016]            ;UCB3608
3640a
> IF trs80pt                                ;UCB3608
> ;P+T CP/M uses the same cursor positioning as the H19 or VT52.        ;UCB3608
> ENDIF    ;trs80pt                            ;UCB3608
>
5632c
< IF trs80
---
> IF trs80lb                                ;UCB3608
5634c
< versio:    db    'Kermit-80 V3.6 [TRS-80 II CP/M]',cr,lf,'$'
---
> versio:    db    'Kermit-80 V3.6 [TRS-80 II Lifeboat CP/M]',cr,lf,'$'
5658c
< ENDIF ; trs80
---
> ENDIF ; trs80lb                                ;UCB3608
>
> IF trs80pt                                ;UCB3608
> outlin:    db    0Ch,cr,lf,tab,tab                    ;UCB3608
> versio:    db    'Kermit-80 V3.6 (UCB%I%) [TRS-80 II P+T CP/M]',cr,lf,'$';UCB3608
> delstr: db    10O,' ',10O,'$'        ; Delete string            ;UCB3608
> clrspc:    db    ' ',10O,'$'        ; Clear space.            ;UCB3608
> clrlin:    db    cr,01h,'$'        ; Clear line.            ;UCB3608
> clrtop:    db    0Ch,'$'            ; Clear screen and go home.    ;UCB3608
> scrnp:    db    esc,'Y#5$'        ; Place for number of packets.    ;UCB3608
> scrnrt:    db    esc,'Y#5',lf,'$'           ; Place for number of retries.    ;UCB3608
> scrfln:    db    esc,'Y%+',01h,'$'     ; Place for file name.        ;UCB3608
> scrst:    db    esc,'Y#T$'        ; Place for status.        ;UCB3608
> scrend:    db    cr,esc,'Y( ',02h,'$'    ; Place for prompt after done    ;UCB3608
> screrr:    db    esc,'Y& $'        ; Place for error messages.    ;UCB3608
> curldn:    db    esc,'Y$'        ; Cursor lead-in     [UTK016]    ;UCB3608
> ttab:    ; Table start location.        ; (MUST be 4 bytes each)    ;UCB3608
> ta:    db    1Eh,'$',0,0        ; Cursor up.        [UTK016];UCB3608
> tb:    db    1Fh,'$',0,0        ; Cursor down.        [UTK016];UCB3608
> tc:    db    1Dh,'$',0,0        ; Cursor right.        [UTK016];UCB3608
> td:    db    1Ch,'$',0,0        ; Cursor left        [UTK016];UCB3608
> te:    db    0Ch,'$',0,0        ; Clear display            ;UCB3608
> tf:    db    11h,'$',0,0        ; Enter Graphics Mode        ;UCB3608
> tg:    db    14h,'$',0,0        ; Exit Graphics mode        ;UCB3608
> th:    db    06h,'$',0,0        ; Cursor home.        [UTK016];UCB3608
> ti:    db    1Eh,'$',0,0        ; Reverse linefeed.    [UTK016];UCB3608
> tj:    db    02h,'$',0,0        ; Clear to end of screen.    ;UCB3608
> tk:    db    01h,'$',0,0        ; Clear to end of line.        ;UCB3608
> ENDIF ; trs80pt                                ;UCB3608
21-Jan-84 18:29:26-EST,10640;000000000000
Return-Path: <@CUCS20:gts%G.CC@Berkeley>
Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 18:29:12 EST
Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 16:40:38-EST
Received: by UCB-VAX.ARPA (4.22/4.19)
    id AA29545; Sat, 21 Jan 84 13:39:42 pst
Received: by ucbpopuli.CC.Berkeley.ARPA
    (4.13/4.10) id AA13218; Sat, 21 Jan 84 13:23:17 pst
Date: Sat, 21 Jan 84 13:23:17 pst
From: gts%ucbpopuli.CC@Berkeley
Message-Id: <[e-mail]>
To: INFO-Kermit@COLUMBIA-20
Subject: CPMBASE.M80 Implement MDI UCB3610 (9 of 11)


The following fix or modification is to CPMBASE.M80 Version 3.6 ftped 12-12-83.
The form similar to that of UNIX diff.

Greg Small    [e-mail]    or gts%ucbpopuli.Berkeley
        [e-mail]    or gts@ucbunixg
--------------------------------------------------------------------------------
0a1
>
> ;UCB    36.10asm    83-10-06    gts, CFO            ;UCB3610
> ; Implement seperate terminal definitions for machines that do not    ;UCB3610
> ; have a built in and therefore standard terminal.            ;UCB3610
> ; Implement tvi925 and adm3a cursor positionable crts.  The tvi925    ;UCB3610
> ; implementation is designed to work acceptably on the adm3a and the    ;UCB3610
> ; adm3a implementation is just a tiny revision to the vt52 emulation.    ;UCB3610
> ; Most other similar crts can either use the tvi925 implementation or    ;UCB3610
> ; be implemented as small changes similar to the adm3a implementation.    ;UCB3610
> ; Implement crt, basic non-positionable crt similar to generic.        ;UCB3610
> ; Implement the Morrow Micro Decision I (mdI).                ;UCB3610
>
199a
> mdI    EQU    FALSE        ; Morrow Micro Decision I        ;UCB3610
>
> crt    EQU    FALSE        ; Basic crt, no cursor positioning    ;UCB3610
> adm3a    EQU    FALSE        ; Adm3a Display                ;UCB3610
> tvi925    EQU    FALSE        ; TVI925 Display            ;UCB3610
496a
>
> IF mdI                                    ;UCB3610
> mnport    EQU    0FEH        ; Morrow Printer UART data port        ;UCB3610
> mnprts    EQU    0FFH        ; Morrow Printer UART command/status    ;UCB3610
> output    EQU    01H        ; Output ready bit.            ;UCB3610
> input    EQU    02H        ; Input ready bit.            ;UCB3610
> ;Note:    ; NEEDS terminal definition (e.g. tvi925 or adm3a above)    ;UCB3610
> ENDIF    ;mdI                                ;UCB3610
>
508a
>
> IF crt OR tvi925 OR adm3a                        ;UCB3610
> defesc    EQU    '\'-100O    ; The default is Control \         ;UCB3610
> ENDIF ; crt OR tvi925 OR adm3a                        ;UCB3610
590a
>
> IF crt OR tvi925 OR adm3a                        ;UCB3610
>     lxi    h,versi0    ; Move machine mame            ;UCB3610
>     lxi    d,versi1    ; to display header            ;UCB3610
>     mvi    c,versi2-versi1    ; (limit to space)            ;UCB3610
> start2:    mov    a,m        ; (get character)            ;UCB3610
>     ani    7Fh        ; (clean ascii)                ;UCB3610
>     jz    start3        ; (stop if end of string)        ;UCB3610
>     stax    d        ; (store it)                ;UCB3610
>     inx    h        ; (increment source pointer)        ;UCB3610
>     inx    d        ; (increment destination pointer)    ;UCB3610
>     dcr    c        ; (continue if not too long)        ;UCB3610
>     jnz    start2        ;                    ;UCB3610
> start3:                                    ;UCB3610
> ENDIF    ;crt OR tvi925 OR adm3a                        ;UCB3610
787c
< IF NOT (gener OR osi OR cpm3)
---
> IF NOT (gener OR osi OR cpm3 OR crt)                    ;UCB3610
790c
< ENDIF ; NOT (gener OR osi OR cpm3)
---
> ENDIF ; NOT (gener OR osi OR cpm3 OR crt)                ;UCB3610
2498c
< IF brain OR vector OR heath OR z100 OR trs80 OR telcon or kpII
---
> IF brain OR vector OR heath OR z100 OR trs80 OR telcon OR kpII OR mdI    ;UCB3610
2506c
< ENDIF ; brain OR vector OR heath OR z100 OR trs80 OR telcon OR kpII
---
> ENDIF ;brain OR vector OR heath OR z100 OR trs80 OR telcon OR kpII OR mdI ;UCB3610
2597c
< IF brain OR vector OR heath OR z100 OR trs80 OR telcon or kpII
---
> IF brain OR vector OR heath OR z100 OR trs80 OR telcon OR kpII OR mdI    ;UCB3610
2630c
< ENDIF ; brain OR vector OR heath OR z100 or trs80 OR telcon OR kpII
---
> ENDIF ;brain OR vector OR heath OR z100 or trs80 OR telcon OR kpII OR mdI ;UCB3610
3274c
< IF brain OR vector OR heath OR z100 OR trs80 OR telcon OR kpII
---
> IF brain OR vector OR heath OR z100 OR trs80 OR telcon OR kpII OR mdI    ;UCB3610
3279c
< ENDIF ; brain OR vector OR heath OR z100 OR trs80 OR telcon OR kpII
---
> ENDIF ;brain OR vector OR heath OR z100 OR trs80 OR telcon OR kpII OR mdI ;UCB3610
3284c
< IF NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3)
---
> IF NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3 OR crt)        ;UCB3610
3288c
< ENDIF      ;NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3)
---
> ENDIF      ;NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3 OR crt)    ;UCB3610
3296c
< IF NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3)
---
> IF NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3 OR crt)        ;UCB3610
3308c
< ENDIF ; NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3)
---
> ENDIF ; NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3 OR crt)    ;UCB3610
3607c
< IF NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3)
---
> IF NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3 OR crt)        ;UCB3610
3611c
< ENDIF    ;NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3)
---
> ENDIF    ;NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3 OR crt)    ;UCB3610
3632c
< IF (osbrn1 or apple OR trs80 OR kpii);                [UTK016]
---
> IF osbrn1 or apple OR trs80 OR kpii OR tvi925 OR adm3a       ;[UTK016];UCB3610
3639c
< ENDIF                ;(osbrn1 or apple OR trs80 OR kpii)[UTK016]
---
> ENDIF    ;osbrn1 or apple OR trs80 OR kpii OR tvi925 OR adm3a ;[UTK016];UCB3610
3641c
< IF NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3)
---
> IF NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3 OR crt)        ;UCB3610
3656c
< ENDIF    ;NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3)
---
> ENDIF    ;NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3 OR crt)    ;UCB3610
3683c
< IF NOT (robin OR rainbo OR gener OR dmII)
---
> IF NOT (robin OR rainbo OR gener OR dmII OR crt)            ;UCB3610
3695c
< ENDIF                ;NOT (robin OR rainbo OR gener OR dmII)
---
> ENDIF    ;NOT (robin OR rainbo OR gener OR dmII OR crt)            ;UCB3610
3938c
< IF NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3)
---
> IF NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3 OR crt)        ;UCB3610
3953c
< ENDIF    ;NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3)
---
> ENDIF    ;NOT (robin OR rainbo OR gener OR dmII OR osi OR cpm3 OR crt)    ;UCB3610
3955c
< IF robin OR rainbo OR gener OR dmII OR osi OR cpm3
---
> IF robin OR rainbo OR gener OR dmII OR osi OR cpm3 OR crt        ;UCB3610
3961c
< ENDIF ; robin OR rainbo OR gener OR dmII OR osi OR cpm3
---
> ENDIF ; robin OR rainbo OR gener OR dmII OR osi OR cpm3 OR crt        ;UCB3610
4109c
< IF NOT (robin OR rainbo OR gener OR dmII OR cpm3)
---
> IF NOT (robin OR rainbo OR gener OR dmII OR cpm3 OR crt)        ;UCB3610
4119c
< ENDIF ; NOT (robin OR rainbo OR gener OR dmII OR cpm3)
---
> ENDIF ; NOT (robin OR rainbo OR gener OR dmII OR cpm3 OR crt)        ;UCB3610
4528c
< IF brain OR heath OR z100 OR trs80 OR telcon OR kpII
---
> IF brain OR heath OR z100 OR trs80 OR telcon OR kpII OR mdI        ;UCB3610
4535c
< ENDIF ; brain OR heath OR z100 OR trs80 OR telcon OR kpII
---
> ENDIF ; brain OR heath OR z100 OR trs80 OR telcon OR kpII OR mdI    ;UCB3610
5422c5386
< IF NOT (robin OR gener OR rainbo OR dmII OR cpm3)
---
> IF NOT (robin OR gener OR rainbo OR dmII OR cpm3 OR crt)        ;UCB3610
5424c
< ENDIF                ;NOT (robin OR gener OR rainbo OR dmII OR cpm3)
---
> ENDIF    ;NOT (robin OR gener OR rainbo OR dmII OR cpm3 OR crt)        ;UCB3610
5728c
< IF gener OR osi OR cpm3
---
> IF gener OR osi OR cpm3 OR crt                        ;UCB3610
5739c
< ENDIF                    ; gener OR osi OR cpm3
---
> ENDIF    ; gener OR osi OR cpm3 OR crt                    ;UCB3610
5739a
>
> IF crt                                    ;UCB3610
> versio:    db    'Kermit-80 V3.6 (UCB%I%) [CRT] '        ;(35)    ;UCB3610
> versi1:    db    '                                        '    ;(40)    ;UCB3610
> versi2:    db    cr,lf,'$'                        ;UCB3610
> outlin:    equ    versi2                            ;UCB3610
> ENDIF    ;crt                                ;UCB3610
>                                     ;UCB3610
> IF tvi925                                ;UCB3610
> outlin:    db    'Z'-64,cr,lf                        ;UCB3610
> versio:    db    'Kermit-80 V3.6 (UCB%I%) [TVI925] '        ;(35)    ;UCB3610
> ENDIF    ;tvi925                                ;UCB3610
>                                     ;UCB3610
> IF adm3a                                ;UCB3610
> outlin:    db    'Z'-64,0,0,cr,lf                    ;UCB3610
> versio:    db    'Kermit-80 V3.6 (UCB%I%) [ADM3A] '        ;(35)    ;UCB3610
> ENDIF    ;adm3a                                ;UCB3610
>                                     ;UCB3610
> IF tvi925 OR adm3a                            ;UCB3610
> versi1:    db    '                                        '    ;(40)    ;UCB3610
> versi2:    db    cr,lf,'$'                        ;UCB3610
>                                     ;UCB3610
> :Note:    These are designed to work on both the tvi925 and the adm3a.    ;UCB3610
> delstr: db    10O,' ',10O,'$'        ; Delete string            ;UCB3610
> clrspc:    db    ' ',10O,'$'        ; Clear space.            ;UCB3610
> clrlin:    equ    tj            ; Clear line.            ;UCB3610
> clrtop:    db    'Z'-64,0,0,'$'         ; Clear screen and go home.    ;UCB3610
> scrnp:    db    esc,'=#3','$'        ; Place for number of packets.    ;UCB3610
> scrnrt:    db    esc,'=#3',lf,'$'      ; Place for number of retries.    ;UCB3610
> scrfln:    db    esc,'=%+',esc,'T',8,' $'; Place for file name.        ;UCB3610
> scrst:    db    esc,'=#T$'        ; Place for status.        ;UCB3610
> scrend:    db    esc,'=( ',esc,'Y',cr,'$'; Place for prompt when done    ;UCB3610
> screrr:    db    esc,'=& ',esc,'T',cr,'$'; Place for error messages.    ;UCB3610
> curldn:    db    cr,esc,'=$'        ; Cursor lead-in (cr 0s lncnt)    ;UCB3610
> ENDIF    ;tvi925 OR adm3a                        ;UCB3610
>                                     ;UCB3610
> IF tvi925 OR adm3a                            ;UCB3610
> ttab:    ; Table start location.        ; (MUST be 4 bytes each)    ;UCB3610
> ta:    db    'K'-64,'$',0,0         ; Cursor up,     stop at top    ;UCB3610
> tb:    db    'V'-64,'$',0,0         ; Cursor down,   stop at bottom    ;UCB3610
> tc:    db    'L'-64,'$',0,0         ; Cursor right,  stop at right    ;UCB3610
> td:    db    'H'-64,'$',0,0         ; Cursor left,   stop at left    ;UCB3610
> te:    db    'Z'-64,0,0,'$'        ; Clear display (2 pad nulls)    ;UCB3610
> tf:    db    esc,'F$',0        ; Enter Graphics Mode NONE    ;UCB3610
> tg:    db    esc,'G$',0        ; Exit Graphics Mode  NONE    ;UCB3610
> th:    db    1Eh,'$',0,0        ; Cursor home.            ;UCB3610
> ti:    db    esc,'j$',0        ; Reverse linefeed, scroll    ;UCB3610
> tj:    db    esc,'Y$',0        ; Clear to end of screen.    ;UCB3610
> tk:    db    esc,'T$',0        ; Clear to end of line.        ;UCB3610
> ENDIF    ;tvi925 OR adm3a                        ;UCB3610
>                                     ;UCB3610
> IF adm3a                                ;UCB3610
>     org    tb                            ;UCB3610
> tb:    db    'J'-64,'$',0,0         ; Cursor down   CTL J        ;UCB3610
>     org    ti                            ;UCB3610
> ti:    db    'K'-64,'$',0,0        ; Reverse linefeed.        ;UCB3610
> tj:    db    '$',0,0,0        ; Clear to end of screen NONE     ;UCB3610
> ti:    db    '$',0,0,0        ; Clear to end of line   NONE    ;UCB3610
> ENDIF    ;adm3a                                ;UCB3610
>
> IF mdI                                    ;UCB3610
> versi0:    db    '[Micro Decision I]',0                    ;UCB3610
> ENDIF                                    ;UCB3610
>
21-Jan-84 18:41:51-EST,518;000000000000
Return-Path: <@CUCS20:wkc@ardc>
Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 18:41:48 EST
Received: from ARDC by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 17:02:11-EST
Date:     Sat, 21 Jan 84 16:58:01 EST
From:     William K. Cadwallender (LCWSL) <wkc@ardc>
To:       [e-mail]
Subject:  Kermit for RSX11 and HP9845b/9845c

Has a kermit been done for a PDP11 running RSX11? We have an 11/24 with 1meg
and 2 RL02 disks. How about an HP9845b or c?

        Bill Cadwallender   wkc@ARDC
21-Jan-84 20:58:21-EST,439;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 20:58:19 EST
Received: from PARC-MAXC.ARPA by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 20:58:02-EST
Date: 21 Jan 84 17:58:54 PST (Saturday)
From: [e-mail]
Subject: Please remove me from this list
In-reply-to: <[e-mail]>
To: [e-mail]

Thanks,

    Bruce
21-Jan-84 21:43:26-EST,522;000000000000
Return-Path: <@CUCS20:wkc@ardc>
Received: from CUCS20 by CU20B with DECnet; 21 Jan 84 21:43:20 EST
Received: from ARDC by COLUMBIA-20.ARPA with TCP; Sat 21 Jan 84 21:43:00-EST
Date:     Sat, 21 Jan 84 21:31:43 EST
From:     William K. Cadwallender (LCWSL) <wkc@ardc>
To:       Info-kermit@columbia-20
Subject:  Kermit for RSX11 and HP9845

Had a Kermit been done for a PDP11 running RSX11? We are using an 11/24 with
1 meg and 2 RL02 disks. How about Kermit for an HP9845b or c?

    Bill Cadwallender   wkc@ARDC
23-Jan-84 11:05:18-EST,1243;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 23 Jan 84 11:03:32 EST
Date: Mon 23 Jan 84 10:59:07-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: Kermit CP/M v3.6 Bugs and Modifications (1 of 11)
To: [e-mail], INFO-Kermit@CUCS20
cc: cc.fdc@CUCS20, [e-mail], G.Bush@CUCS20, G.WBC3@CUCS20,
    [e-mail], [e-mail], [e-mail],
    [e-mail]
In-Reply-To: Message from "gts%ucbpopuli.CC@Berkeley" of Sat 21 Jan 84 16:11:19-EST

Greg, thanks for the fixes and suggestions.  As you know, it's tough to
manage such a widespread distributed voluntary effort as KERMIT, particularly
CP/M KERMIT, which tries to support so many different systems.  We recently
decided to stablize CP/M Kermit, except for bug fixes, and concentrate all
new development in a totally rewritted, modularized version being done by Ron
Fowler, one of the big MODEM people.  Your fixes come at an opportune moment,
since Bernie Eiben, one of the major CP/M Kermit contributors, is in the
process of making one last pass over Kermit-80, and I'll send your work
directly to him; I hope it gets in.   - Frank
-------
23-Jan-84 11:15:05-EST,609;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 23 Jan 84 11:14:46 EST
Date: Mon 23 Jan 84 11:03:53-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: rt kermit
To: [e-mail], info-kermit@CUCS20
In-Reply-To: Message from "Carl Fussell <[e-mail]>" of Sat 21 Jan 84 16:25:13-EST

A MACRO-11 implementation of KERMIT for RSX-11M and RSTS/E has been done by
Brian Nelson of the University of Toledo (Ohio); it's on a tape, in the mail to
me at this moment.  He'll be adapting it for RT-11 over the next several weeks.
- Frank
-------
23-Jan-84 11:36:57-EST,2287;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 23 Jan 84 11:36:49 EST
Date: Mon 23 Jan 84 11:34:09-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New release of KERMIT for HP98xx
To: Info-Kermit@CUCS20

The files are in KER:HP9*.*, accessible via anonymous FTP from host
COLUMBIA-20.  The problem he alludes to is due to an omission in the
KERMIT Protocol Manual, which will be fixed in a new revision: data
fields of all packets EXCEPT the Send-Init (S) or the Info (I) packet,
or the ACK to those packets, or the File Attributes (A) packet, should
go through the encoding and decoding mechanisms for control prefixing,
etc.  - Frank

----------

Date: 20 Jan 84 05:29:39 EST
From: [e-mail]
Subject: New HP Kermit
To: [e-mail]

Frank,

I have a new version of HP-Kermit.  All the source files have been modified,
and there is one new file, KRMVERS.TEXT.

I was going to add a few more things to this version of HP-Kermit
before sending it over, but I discovered a severe bug in the last
version that had to be fixed.  It seems that the old protocol code did
its control unquoting in the receive packet routine.  Not only did
file data packets get unquoted, but ALL packets did!  This did not
cause a problem until 20 Kermit started setting the QCTL and QBIN
fields in its send-init packets to #Y.  Since # happened to be the
same character HP kermit was using for local quoting, HP kermit took
the #Y to mean "use ^Y as the control quote"!  I fixed it so the
unquoting is only done for data packets.

Since I lifted the protocol code from RTKERMIT, this bug is almost
certainly in that version also.  If you want I can try fixing it in
there too, but I have no way to test it.

By the way, I couldn't find any mention of this potential problem in
the protocol document, though I didn't look very hard.  I admit that
quoting is obviously meaningless when the quote characters have not
yet been defined, but some implementations (like this one) might not
account for that...

Besides the bug fix, the new version has nicer error reporting, the
code in the protocol module is a little cleaner, and responds to
interrupt keys ^X and ^Z.

Mike (Gallaher@Rutgers)
-------
23-Jan-84 12:31:58-EST,494;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 23 Jan 84 12:31:53 EST
Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Mon 23 Jan 84 12:30:42-EST
Date: 23 Jan 84 12:29:28 EST
From: [e-mail]
Subject: Apple kermit.
To: [e-mail]


Who is working on the Apple DOS version of kermit?
I have some questions and suggestions.

              -Gadi
              <Friedman@Ru-Blue>

-------
23-Jan-84 16:40:15-EST,700;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 23 Jan 84 16:40:00 EST
Date: Mon 23 Jan 84 16:33:37-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: KERMIT in MicroSoft BASIC
To: Info-Kermit@CUCS20

Well, almost.  This is a version sent to us from Sweden, written by Torbjorn
Alm of the Stockholm ABC-Klubben for the Luxor ABC-800 in a language called
Basic II, which he claims is very close to MicroSoft Basic.  I don't know
anything about this machine, but the Basic code might be adaptable to many
micros.  It's in KER:800*.*, available via anonymous FTP from host COLUMBIA-20.
If anyone does anything with it, please let me know.  - Frank
-------
23-Jan-84 16:54:16-EST,8710;000000000001
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 23 Jan 84 16:54:00 EST
Date: Mon 23 Jan 84 16:47:26-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: IBM PC Kermit
To: Info-Kermit@CUCS20, [e-mail]

We (at Columbia) have decided to make a full blown effort at getting IBM PC
Kermit in shape, and will be working on it full time over the coming weeks or
months.  While the present release, 1.20, is quite adequate, there remain gaps
and problems.  What's worse, 5 or 10 different sites have made significant
modifications to this program -- most of them useful and worthwhile -- and we
are badly behind in fitting all this work into the base version.  What follows
is our list of things to do (it's rather long).  If you have comments on this
list, please send them to me.  And if you have additional suggestions, send
those to me too, rather than changing the program yourself.  Meanwhile,
announcements will be made of test versions of PC Kermit from time to time, as
the various features find their way into the program.  Here's the list:

* Support for multiple systems:

First, the program should no longer be thought of as IBM PC Kermit, but rather
MS DOS KERMIT.  Support has been added to it (at other sites) for at least the
following MS DOS systems:

  . DEC Rainbow 100, 100+
  . Heath/Zenith 100
  . Victor 9000
  . Seequa Chameleon
  . Eagle 1600
  . Ericson Step/One (Panasonic JB3000)

And we'll soon be getting in some IBM Peanuts and HP-150s, which will have to
be supported by this program too.  Currently, only the IBM PC/XT and Z100
support are integrated into the same program.  We need to integrate support for
the other systems too.

By the way, the IBM PC version is known to run without modification on certain
PC-compatibles, including the Compaq portable and the Columbia MPC.

* Program organization:

The program is now a gigantic monolith, with conditional assembly to select the
PC or Z100.  It will only become larger and more tangled (like CP/M-80 KERMIT)
if we support the additional systems in the same way.  So it has to be broken
up into separately compiled modules.  There should be a system-independent
module for the protocol, and system/device/etc-dependent modules for:

  . port i/o
  . modem control, if necessary (for "smart" &/or internal modems)
  . file i/o
  . printer i/o
  . screen display (cursor positioning, screen clearing, etc)
  . terminal emulation (some people have wanted to plug in their own terminal
    emulators)
  . command parsing (some people would prefer a Unix-style command parser, or a
    menu, or function keys, or a mouse, or a pointing finger, or ...)

and so forth.  This cuts down on assembly time, KERMITing time, etc, and -- if
the modules have well-defined specifications and interfaces to the outside
world -- should make it easy to support new systems by plugging in new modules.
Doing it this way requires clear user-level documentation about how to put
together a working KERMIT for an existing or new system.

* I/O structure:

Packet encoding/decoding must be separated from file/port i/o, to allow
non-file data to be encoded/decoded, e.g. to send directory listings.  For
instance, it is now possible for you to type "GET FOO#BAR" (assuming you're
talking to a system that allows "#" in filenames); since the argument for the
server command doesn't go through the normal encoding mechanism, the remote
KERMIT will see "FOO#BAR" and translate the "#B" to control-B.  The data field
of any packet should go through the encoding mechanism to get control & 8th-bit
prefixes, etc.  Obvious exceptions are the init and attributes packets.

* Binary file transfer:

  . Get the 8th bit prefixing working reliably with DEC-10/20, VAX, etc.
  . Get binary file transfer working with CMS KERMIT.  This requires
    implementation not only of 8th-bit prefixing, but also the dreaded FILE
    ATTRIBUTES packet, to allow arbitrary record boundaries to be preserved for
    CMS files sent to the PC and back.

* Herm Fischer's changes:

Test this stuff, integrate it, check it out on non-PC machines:

  . Server mode
  . TAKE command
  . Init file
  . Key redefinitions
  . etc

* Kimmo Laaksonen's change:

  . Filename completion, a la TOPS-20 & TENEX.

* Terminal emulation:

  . Modularize
  . Insert character is too slow when inserting a block of characters.
  . Use 25th line to display current settings -- baud, parity, etc.  Maybe
    toggle (and/or scroll) this display with a function key.
  . SET HANDSHAKE to allow user to specify this.
  . SET FLOW-CONTROL option for XON/XOFF (during both terminal emulation & file
    transfer)
  . Session logging (with big memory buffer, XON/XOFF &/or handshake)
  . Multiple page screen memory (like HP or new Concept)
  . Distinguish between ^H and backarrow (they really are different); make
    SET BACKARROW only affect backarrow, not ^H too.
  . Support VT52/H19 reverse index command -- many editors, like VI, use it.
  . User-defined function keys.
  . SET BELL {VOLUME | PITCH | DURATION}
  . Support for IBM's ANSI.SYS to allow (relatively slow) ANSI terminal
    emulation.  This has already been done by Glenn Everhart in the Seequa
    version (I think the same thing is also in Herm's SET CONSOLE business).
  . Support CTRL/PrtSc during terminal emulation (Shift/PrtSc already works).
  . Fix the getting-stuck-on-25th-line problem.
  . Do bounds checking on all cursor positioning commands.
  . (pie in the sky) Full-speed ANSI terminal emulation, windows, line/char
    insert/delete, etc.

* Add local functions (like in CP/M Kermit 3.6 & above):

  These are especially handy for 1-drive systems (like the Peanut).
  . Directory listings
  . Deleting files
  . Find out how much space is left on disk
  . Change default disk

* Fix existing problems:

  . Always update retry count on screen when there's a NAK or retransmit.
  . MS DOS file byte count includes the ^Z at the end of the file.
    If it's a text file, you don't want to send it; if it's a binary file
    you do.  Find some way to do this right.  Probably need to add SET FILE
    BINARY/TEXT like CP/M KERMIT.
  . COMND simulation -- currently, if any fields are left off, the command has
    no effect (like SET<CR> or SET IBM<CR>).  It should either complain, or
    supply a default.  Also, implement ^R, ^W.

* Missing features from the protocol manual:

  . Timeouts
  . Fancy block check types -- 2 char checksum, 3 char CRC.
  . Repeat counts.
  . Sending file-management commands to server & displaying results.
  . Server-provided file management:  delete, rename, directory, type,
    change directory, login, ...
  . DEFINE command for SET macros.

* Etc:

  . Verify everything in SPAR.
  . Prevent receive-packet buffer overruns.
  . Ability to run in background from a batch file.
  . Ability to send a raw file (like in Kimmo's CP/M Kermit), with prevailing
    handshake/flow control (XON/XOFF, half duplex XON, etc).
  . Special features for PC-to-PC connection.  For instance, sending an
    entire directory tree, to be replicated on the target system.
  . ^C during file transfer sends you straight back to command level.
  . Don't set the baud rate to 4800 when starting up, but leave it at whatever
    it was set at.  If you want it at 4800 (or whatever), put a SET BAUD
    command in your KERMIT.INI file.
  . Appearance -- put some whitespace around "?" help messages.
  . Add a real "help" command that gives a bit more information.
  . Allow redirection of incoming files to devices other than disk:
    - Printer, to let PCs share printers.
    - Memory, to let programs be downloaded and started from remote disk.

* Finally, a manual:

A new manual needs to be written, for use in conjunction with the KERMIT User
Guide, much like the new (draft version of the) KERMIT-20 Manual.  The manual
should contain not only detailed descriptions of the commands, but also hints
about using KERMIT within the PC/MS DOS environment, for instance:

 Using KERMIT in conjunction with key redefinitions (like ProKey).  For
  instance to get a META key for EMACS, to make the arrow keys work with your
  favorite editor.

 Using KERMIT as a terminal (can't transfer files!) over a protocol emulator
  as a 3270 -- inverse video, etc.
. Using KERMIT with a RAM disk.
. Using KERMIT with a "smart" modem.
. Using KERMIT over TELENET, through a TAC, over TYMNET, etc etc
. Nuts & bolts of connected two PCs.

Any other suggestions?
-------
23-Jan-84 17:06:22-EST,1816;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 23 Jan 84 17:06:16 EST
Date: Mon 23 Jan 84 16:50:44-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Release 2.2 of Rainbow KERMIT-86
To: Info-Kermit@CUCS20

This new release of KERMIT-86 for the DEC Rainbow 100 running CP/M-86 version
1.0 or 2.0, submitted by the original author Bill Catchings, corrects several
problems in the previous release, which was 2.1:

 The buffer is cleared at the correct times, so it is now possible to
  communicate normally with a KERMIT server (e.g. on the DEC-20).

 Some changes were made to the port handling which MAY clear up some problems
  people were having with modem signals when using internal modems, especially
  when carrier is dropped while KERMIT is running (e.g. when logging out from a
  dialup connection to the DEC-20).

 It is not possible to type carriage return to "wake up" a stuck file transfer
  in the same way this is possible in other microcomputer implementations of
  KERMIT.

There is still an unresolved problem which prevents KERMIT-86 on the Rainbow
from transferring files with the IBM mainframes.  Terminal connection, however,
works correctly.  This problem will be fixed in a forthcoming release.

The new release is available via anonymous FTP from host COLUMBIA-20 as
KER:RBKERMIT.CMD (executable), KER:RBKERMIT.H86 (hex), KER:RBKERMIT.HLP (short
documentation), and KER:86*.* (source).  Please use your current version of
KERMIT to download this new version.  Report any problems to me; it is
important to get the kinks ironed out of KERMIT-86 since it will soon replace
KERMIT-80 as the standard KERMIT for the Rainbow, because KERMIT-80 no longer
works on the Rainbow under release 2.0 of CP/M-86/80.

- Frank
-------
23-Jan-84 17:19:29-EST,835;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 23 Jan 84 17:19:21 EST
Date: Mon 23 Jan 84 17:03:10-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Bug uncovered
To: Info-Kermit@CUCS20

Greg Small at Berkeley found a bad bug in CP/M-80 Kermit, which is bound to
exist in many other implementations as well.  The bug is in the code that fills
the received-packet buffer.  The problem is that there is no bounds checking.
If a sudden burst of noise (or a system message, or a "[You have mail from...]"
message, etc) appears in the midst of a packet, the characters are deposited
into the buffer past the end, overwriting other important data (or even code,
depending upon how the program is organized).  All KERMITs should deend
themselves against this sort of thing.  - Frank
-------
23-Jan-84 19:48:37-EST,697;000000000000
Return-Path: <@CUCS20:judd%umcp-cs@CSNet-Relay>
Received: from CUCS20 by CU20B with DECnet; 23 Jan 84 19:48:33 EST
Received: from csnet-cic.ARPA by COLUMBIA-20.ARPA with TCP; Mon 23 Jan 84 19:48:12-EST
Date:     23 Jan 84 14:14:39 EST  (Mon)
From: Judd Rogers <judd%umcp-cs@CSNet-Relay>
Return-Path: <judd%umcp-cs@CSNet-Relay>
Subject:  Re:  CPMBASE.M80 Implement MDI UCB3610 (9 of 11)
To: gts%ucbpopuli.CC@Berkeley, INFO-Kermit@COLUMBIA-20
Via:  UMCP-CS; 23 Jan 84 17:40-EST

From: Judd Rogers(judd@umcp-cs)


PLEASE DON'T SEND LONG FILES ON THE NET.  IT WASTS THE TIME OF PEOPLE WHO
DO NOT WANT TO READ THEM..  INSTEAD SEND A SHORT ANOUNCEMENT AND MAKE THE
FILE AVAILABLE.



24-Jan-84 12:40:18-EST,1115;000000000000
Return-Path: <@CUCS20:gts%ucbpopuli.CC@Berkeley>
Received: from CUCS20 by CU20B with DECnet; 24 Jan 84 12:40:08 EST
Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Tue 24 Jan 84 12:39:26-EST
Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by UCB-VAX.ARPA (4.22/4.19)
    id AA13246; Tue, 24 Jan 84 09:36:09 pst
Received: by ucbpopuli.CC.Berkeley.ARPA
    (4.13/4.11) id AA19289; Tue, 24 Jan 84 09:30:44 pst
Date: Tue, 24 Jan 84 09:30:44 pst
From: gts%ucbpopuli.CC@Berkeley
Message-Id: <[e-mail]>
To: INFO-Kermit@COLUMBIA-20, judd%umcp-cs@CSNet-Relay
Subject: Re:  CPMBASE.M80 Implement MDI UCB3610 (9 of 11)

Sorry, I did not realize that stuff to INFO-Kermit was automatically
rebroadcast.  I myself have been inundated with net return messages
reporting machines that could not be reached, obsolte or out of service
accounts, etc.  I am not complaining, however, I need rapid feedback on
Kermit issues in order to fulfill my kermit support fuction here, even
though I may have to skim through many messages about versions I do not support.

25-Jan-84 11:51:20-EST,526;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 25 Jan 84 11:51:11 EST
Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Wed 25 Jan 84 11:48:21-EST
Date: 25 Jan 84 11:47:05 EST
From:   Alexander B. Latzko <[e-mail]>
Subject: Apple Kermit
To: [e-mail]
cc: [e-mail]


As far as I know Apple Kermit (DOS verison) was written by Tony Mione
at Stevens Institue of Technology.

alex
<[e-mail]>
-------
25-Jan-84 13:30:55-EST,1076;000000000000
Return-Path: <@CUCS20:FONGHEISER@CWR20B>
Received: from CUCS20 by CU20B with DECnet; 25 Jan 84 13:30:47 EST
Received: from CWR20B by CUCS20 with DECnet; 25 Jan 84 13:04:41 EST
Date: Wed 25 Jan 84 13:05:09-EST
From: FONGHEISER@CWR20B
Subject: Transferring directory trees
To: info-kermit@CUCS20


Frank da Cruz mentioned the possibility of transferring entire directory
trees with kermit.  There are a few problems with this.  Basically what
would happen is you would have a directory file sitting on the remote system.
However, there is no trace of the files in the directory.  All of the
real information about where the file is stored isn't even in the directory.
A better approach is to use a program such as tar and then transfer the
resulting file via kermit.  The tar format is well documented and can
probably be read by most systems.  This means you wouldn't even have to
worry about transferring say, from a MS-DOS system to a UNIX system.

                    Carl Fongheiser
                    FONGHEISER@CWR20B (CCnet)
                    FONGHEISER%CWR20B@Columbia-20 (ARPA)
-------
25-Jan-84 18:50:07-EST,340;000000000000
Received: from CUCS20 by CU20B with DECnet; 25 Jan 84 18:50:02 EST
Received: from LLL-MFE by COLUMBIA-20.ARPA with TCP; Wed 25 Jan 84 18:46:47-EST
Date: Wed, 25 Jan 84 15:47 PST
From: "Webb Mike"@LLL-MFE.ARPA
Subject: KERMIT FOR TELEVIDEO 802
To: [e-mail]

DOES SUCH A BEAST EXIST??? BEFORE I START.

                MIKE
25-Jan-84 20:11:41-EST,772;000000000000
Return-Path: <@CUCS20:HOWALD@USC-ECLB>
Received: from CUCS20 by CU20B with DECnet; 25 Jan 84 20:11:37 EST
Received: from USC-ECLB by COLUMBIA-20.ARPA with TCP; Wed 25 Jan 84 20:10:06-EST
Date: 25 Jan 1984 1708-PST
From: HOWALD <HOWALD%USC-ECLB@SRI-NIC>
Subject: Kermit for Apple IIe w/Super Serial Card
To: info-kermit@COLUMBIA-20

I am trying to install the 6502 version of Kermit on an Apple IIe with a super
serial card. I'm having problems re-writing APPLBT.BAS so that it will work with the superserial card--I can't seem to get the right combination of IN#2, PR#2,
and CTRL-A TERM MODE.  If someone out there has gotten KERMIT working on
the above setup, I would be grateful for their help.  I am a novice where
Apples are concerned.  *james
-------
26-Jan-84 16:54:59-EST,2851;000000000000
Return-Path: <@CUCS20:OC.TREI@CU20B>
Received: from CUCS20 by CU20B with DECnet; 26 Jan 84 16:54:51 EST
Received: from CU20B by CUCS20 with DECnet; 26 Jan 84 16:54:04 EST
Date: Thu 26 Jan 84 16:53:30-EST
From: Peter G. Trei <OC.Trei@CU20B>
Subject: Apple DOS Kermit.
To: info-kermit@CUCS20
[CU Area Apple/Kermit Hacker]

People trying to use Kermit-65 (Apple DOS Kermit) Version 1.1 with a
Super Serial Card have been running into problems. Here is how to make
it work.

1. Before you start up Kermit, send the SSC the following string: ^AZ
(thats Control-A, followed by Z).  This will disable the SSC's command
recognition. The SSC usually looks for ^A in the terminal input, and
strips it out. It then looks at the next character, and if it is a
valid SSC command, strips it out as well and performs the command.
Trouble arises from the fact that Kermit uses ^A to announce the start
of each packet. Typing ^AZ disables the SSC from seeing further ^A
commands. If you really need to have access to the SSC commands again
before you turn off the Apple, type ^A^W instead, which will change
the command prefix to ^W, which should not appear during Kermit file
transfer.

    There is a bug in the code to support the Super Serial Card,
which must be fixed before it will work at all. If you look in the
source code for Kermit-65 (APPLEK.M65 in <KERMIT>, and search for the
label TL2CP:, two lines further down you will see a line which reads:

AND    #$04

At this point, Kermit is ANDing a status register with a bitmask. If
the result is non-zero, a character has been received from the modem.
the problem is that 04 is the wrong mask; it should be 08, according
to page 54 of the SSC manual.

    To fix this, you can either alter the source, recompile, and
upload the new version, or much more quickly you can patch the binary
version you already have. Here's how to do the patch from Applesoft:

]BLOAD APPLEK.BIN
   (or whatever you are calling your copy).

]POKE 8665,8
   (thats a decimal address)

]BSAVE NEWKER,A$800,L$4900

Thats all. The new version contains the patch. With this, file transfer
using the Super Serial Card has been done at 1200 baud.

3.    Those of you who use 1200 baud modems will have noticed that
you loose characters at the beginning of each line when the screen is
scrolling.  This is not Kermits fault, but rather the slowness of the
software used to scroll the screen image in the Apples memory.
According to the SSC manual, you can eliminate this by slightly
narrowing the scroll window. The following poke does it:

]POKE 35,22

This will make line 22 the bottom of your scroll window, which is
enough.

I would be interested in hearing from anyone on the list who is using
Kermit-65.

                    Peter Trei,
                    [e-mail]
-------
27-Jan-84 13:29:13-EST,861;000000000000
Return-Path: <@CUCS20:decwrl!rhea!vax4!arson!ziemba@su-shasta>
Received: from CUCS20 by CU20B with DECnet; 27 Jan 84 13:28:57 EST
Received: from su-shasta by COLUMBIA-20.ARPA with TCP; Fri 27 Jan 84 13:28:17-EST
Received: from decwrl by Shasta with UUCP; Fri, 27 Jan 84 10:27 PST
Date: Friday, 27 Jan 1984 10:05:29-PST
From:
        decwrl!rhea!vax4!arson!ziemba (DMII 1.0 For: Irene Ziemba) <decwrl!rhea!vax4!arson!ziemba@su-shasta>
Subject: Enclosed file "ZBOX.TXT"
Message-Id: <8401271806.AA10078@DECWRL>
Received: from RHEA.ARPA by DECWRL (3.327/4.09) 27 Jan 84 10:06:57 PST (Fri)
To: [e-mail],
        "[e-mail]"@su-shasta
Cc: ~z~@su-shasta


Sirs/Madams,

Please add me to your KERMIT subscription list.  Can you also send
me your earlier issues which deal with APPLEs?

Much obliged,
Irene
27-Jan-84 13:39:13-EST,801;000000000000
Received: from CUCS20 by CU20B with DECnet; 27 Jan 84 13:39:08 EST
Received: from CISL-SERVICE-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Fri 27 Jan 84 08:21:31-EST
Received: from HIS-PHOENIX-MULTICS.ARPA by CISL-SERVICE-MULTICS.ARPA dial; 27-Jan-1984 08:08:14-est
Received: from HIS-LA-CP6.ARPA by HIS-PHOENIX-MULTICS.ARPA dial; 26-Jan-1984 22:41:47-mst
Date: Thu, 26 Jan 84 21:18 PST
From: DENNIS GRIESSER at HIS-LA-CP6.ARPA
To: INFO-KERMIT at COLUMBIA-20

In reply to Mike Iglesias <iglesias%uci-750a> (01/18/84), some folks
around here would like to bring up KERMIT on Honeywell CP-6, but have
little time to devote to the effort.

We would like to start from a generic FORTRAN version.

Has anybody else shown interest?

Dennis Griesser
Honeywell Los Angeles Development Center
27-Jan-84 21:07:14-EST,1621;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 27 Jan 84 21:07:10 EST
Date: Fri 27 Jan 84 21:06:45-EST
From: Richard Garland <G.GARLAND@CUCS20>
Subject: Apple with SSC & Videx 80 col. card
To: info-kermit@CUCS20

Using Peter Trei's suggestions (in yesterday's Info-Kermit) we now
have Apple Kermit working nicely with the SSC (Super Serial Card).

We have no problem connecting to and doing file transfers with a VAX
running VMS and Steven's VMS Kermit at 1200 baud.

Mark Paczkowski here has worked out how to get the Videx 80 column card
working under Kermit with the SSC.  The Videx must go in slot 3.
Assume the SSC is in slot 1.  The following sequence gets the whole
thing going:

1) Boot the Apple

2) Type "IN#1"            <== this wakes up the SSC

3) Type "<CTRL>A3S"        <== chain SSC to Videx 80 col. card

4) Type "<CTRL>AZ"        <== turn off SSC's interception of ^A's

5) Type "PR#3"            <== turn on Videx 80 col card

6) Type "BLOAD KERMIT"        <== load kermit (patched as per Peter Trei)

7) Type "CALL 7855"        <== Start up Kermit


Then you are off and running.  The 80 col card has faster screen
handling and so Peter Trei's suggestion about reducing the scrolling
region to 22 lines is unnecessary.  The BLOAD is needed rather than the usual
BRUN so that the chaining stuff you set up in the previous steps won't
get reset.  During the above sequence you will get various prompts from
the system and from the cards.  The screen will do various wierd things
but in the end it will all be ok.

[Now back to my Rainbow ...]

                    Rg
-------
27-Jan-84 21:19:43-EST,631;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 27 Jan 84 21:19:40 EST
Date: Fri 27 Jan 84 21:17:09-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: KERMIT for Atari Home Computers
To: Info-Kermit@CUCS20
cc: Ingerman@CWRU20

Jack Palevich has released a version of KERMIT for Atari Home Computers which
requires the "Action!" cartridge to run.  It is available in KER:ATA*.* on
host COLUMBIA-20 via anonymous FTP.  Another implementation will follow that
can run standalone, i.e. without any special cartridges.  The files
ATAKERMIT.HLP and .DOC comprise the documentation.
-------
27-Jan-84 21:31:44-EST,576;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 27 Jan 84 21:31:42 EST
Date: Fri 27 Jan 84 21:19:40-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: KERMIT for Intel Development System
To: Info-Kermit@CUCS20

A version of KERMIT written in PL/M for the Intel MDS system is available
in KER:MDS*.* on host COLUMBIA-20 via anonymous FTP.  This implementation
was donated by a benefactor at Columbia who wishes to remain anonymous.
It is based on the very early C-language "outline" of KERMIT; it's primitive
but it works.
-------
27-Jan-84 21:44:31-EST,1668;000000000000
Return-Path: <@CUCS20:SY.FDC@CU20B>
Received: from CUCS20 by CU20B with DECnet; 27 Jan 84 21:44:28 EST
Received: from CU20B by CUCS20 with DECnet; 27 Jan 84 21:36:20 EST
Date: Fri 27 Jan 84 21:36:02-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Finding versions of KERMIT
To: Info-Kermit@CUCS20

For those of you who are new to the Info-Kermit mailing list, a brief reminder
about how to find out about an implementation of Kermit for whatever system
you're interested in...  All the files are in the directory PS:<KERMIT>, which
you can also refer to as "KER:" (this is logical device name).  You can get at
the KER: area from the ARPAnet using anonymous FTP to host COLUMBIA-20, from
CCnet (the DECnet network of Columbia, Carnegie-Mellon, Case Western, and
(soon) NYU and Stevens) using anonymous NFT (from certain hosts) from DECnet
host CU20B, and from BITnet (an IBM RSCS-protocol based network comprising some
50 universities and research institutions) via a Kermit server at BITnet host
CUVMA.

The first place to look is the file KER:00README.TXT.  The filename starts with
zeros so it will appear at the top of an alphabetical directory listing.  This
file lists the presently available implementations of KERMIT, and the prefixes
for the filenames under which it is stored.

If you don't find what you're looking for in the 00README file, look in
KER:VERSIONS.DOC.  This is a tabular listing of all the known KERMIT efforts,
complete, in progress, or still in the planning stage.

You might also want to peruse the Info-Kermit mailing list archives which, for
the present, are stored in the large KER:MAIL.TXT file.
-------
27-Jan-84 23:53:38-EST,656;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 27 Jan 84 23:53:36 EST
Received: from SU-SIERRA.ARPA by COLUMBIA-20.ARPA with TCP; Fri 27 Jan 84 23:53:17-EST
Date: Fri 27 Jan 84 20:52:47-PST
From: Pardner Wynn <[e-mail]>
Subject: PCjr kermit
To: [e-mail]


Kermit for the IBM PC, version 1.20, does not work with the PCjr.
I just tried it with the disk model, DOS 2.1, built-in serial port and
Hayes Smartmodem 300.

My PC-Talk.exe program (freeware) runs fine.

Let me know if I can be of help trying out new versions...

Pardner Wynn    [e-mail]
-------
30-Jan-84 09:58:14-EST,1396;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 30 Jan 84 09:58:01 EST
Received: from CISL-SERVICE-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Mon 30 Jan 84 09:57:09-EST
Received: from HIS-PHOENIX-MULTICS.ARPA by CISL-SERVICE-MULTICS.ARPA dial; 30-Jan-1984 09:54:13-est
Date:  Mon, 30 Jan 84 07:52 MST
From:  [e-mail]
Subject:  Kermit user manual
To:  [e-mail]
Message-ID:  <[e-mail]>

  I have been trying to get version 1.1 of the IBM-PC Kermit running on
my Compaq.  The VT52 emulation works well (Emacs never looked so good!).
but when I tried to downline load a file using my Kermit, and a Multics
Kermit, I don't even seem to recieve a filename packet.  My biggest
problem, (Being a beginning user to Kermit) is that I don't know wether
I am using Kermit correctly, or Kermit is to blame, or I have been bitten
by the non-compatibility mode of my Compaq.  I have a copy of the Kermit
Protocol document,  and I have heard of a Kermit 'Users Manual', but
have never found this beastie. My question is: does this 'Users Manual'
really exist, and if it does, where can I get a copy of it? (Preferrably
on system "M" in Phoenix, since I can't FTP stuff.)

                    Thanks in advance,
                    Gary Brz...
 1-Feb-84 11:19:01-EST,882;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 1 Feb 84 11:18:55 EST
Received: from CISL-SERVICE-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Wed 1 Feb 84 11:02:44-EST
Received: from HIS-PHOENIX-MULTICS.ARPA by CISL-SERVICE-MULTICS.ARPA dial; 01-Feb-1984 09:27:36-est
Acknowledge-To:  Kevin Kenny <[e-mail]>
Date:  Tue, 31 Jan 84 21:29 MST
From:  Kevin Kenny <[e-mail]>
Subject:  8th-bit quoting and KERMIT-80
Reply-To:  [e-mail]
To:  [e-mail]
Message-ID:  <[e-mail]>

Has anyone else tried to get 8th-bit-quoting into CP/M Kermit? I don't
want to start hacking on it if someone else already has it or is working
on it; that way lies reinvention of the wheel.

/k**2 (Kenny%PCO@CISL)
 2-Feb-84 12:14:25-EST,1992;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 2 Feb 84 12:14:04 EST
Date: Thu 2 Feb 84 12:11:10-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: KERMIT for RSX-11 and RSTS/E
To: Info-Kermit@CUCS20
cc: ATSBDN%UOFT01@CU20B, AP2.L-Lidofsky@CU20A, KMM%CORNELLA@CU20B

This is to announce a major new implementation of KERMIT for the PDP-11, from
Brian Nelson at the University of Toledo in Ohio ([e-mail]).  The
program is written in MACRO-11, and can be configured for RSX-11/M, M-Plus,
or RSTS/E.

Minimum system requirements:

        RSTS    v8.0 or later, with multiple private delimiters and RMS V2
        RSX11M  v4.1 or later, with full duplex terminal driver and RMS V2
        RSX11M+ v2.1 or later, with full duplex terminal driver and RMS V2

This version of Kermit supports server mode and full wildcarding for SEND and
GET.  It also supports the CONNECT command, which can be used to dial out of
the RSTS or RSX system and talk to another Kermit somewhere else.  In addition
to supporting the basic server functions -- SEND, GET, BYE -- KERMIT-11 also
provides such advanced functions as remote directory listing, file deletion,
directory switching, disk space inquiry, and more.  In fact, it's so advanced
that many of these functions can be invoked only by another copy of itself!
(But new releases of MS DOS, DEC-20, and other KERMITs are on the way.)

An adaptation of the same program for RT-11 is expected within a month or so.

The files are available from host COLUMBIA-20 via anonymous FTP (ARPANET) or
host CU20B (CCNET) via anonymous NFT (from certain CCNET hosts) as KER:K11*.*.
There are about 42 files, most of them small, including user documentation,
installation instructions, command and control files for building the program,
and the MACRO source itself.

Congratulations and thanks to Brian for an excellent job on this long-awaited
version of KERMIT.

- Frank
-------
 2-Feb-84 13:41:35-EST,934;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 2 Feb 84 13:41:26 EST
Date: Thu 2 Feb 84 12:12:00-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New release of VAX/VMS Pascal-based KERMIT
To: Info-Kermit@CUCS20

A new release of the Pascal/Fortran VAX/VMS KERMIT implementation has been
received from Bruce Pinn at the University of Toronto in Ontario.  It can
operate in either local or remote mode, but there is no server operation.
This version of KERMIT is an alternative to the Bliss/Macro-32 implementation
from Stevens Institute of Technology (which is more advanced) and the VAX-11
C version from somewhere inside DEC (an adaptation of an early release of UNIX
Kermit).  Comparisons of these three VMS KERMITs would be welcome on the
Info-Kermit mailing list.

This program is available in KER:VF*.* on COLUMBIA-20 (ARPANET FTP) or CU20B
(CCNET NFT).

- Frank
-------
 2-Feb-84 14:15:25-EST,901;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 2 Feb 84 14:15:08 EST
Date: Thu 2 Feb 84 12:16:28-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New Release of RT-11 Pascal-Based KERMIT
To: Info-Kermit@CUCS20
cc: Michael@CUCS20

A new release of the RT-11 KERMIT written in OMSI Pascal has been received from
Philip Murton at the University of Toronto (...!utcstat!utcss!philip).  This
release is more modular, more configurable, and has many improvements over the
earlier version, including a keyword-style (rather than single-character)
command parser.  Perhaps most important, the is now distributed with
configurable "hexified" binaries so that you don't need to have OMSI Pascal on
your RT-11 system to run it.

The files are available from COLUMBIA-20 (ARPANET FTP) or CU20B (CCNET NFT) as
KER:RT*.*.  Comments welcome.

- Frank
-------
 2-Feb-84 14:47:29-EST,934;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 2 Feb 84 14:47:21 EST
Date: Thu 2 Feb 84 12:27:11-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New Release of VAX/VMS Pascal-Based KERMIT
To: Info-Kermit@CUCS20

A new release of the Pascal/Fortran VAX/VMS KERMIT implementation has been
received from Bruce Pinn at the University of Toronto in Ontario.  It can
operate in either local or remote mode, but there is no server operation.
This version of KERMIT is an alternative to the Bliss/Macro-32 implementation
from Stevens Institute of Technology (which is more advanced) and the VAX-11
C version from somewhere inside DEC (an adaptation of an early release of UNIX
Kermit).  Comparisons of these three VMS KERMITs would be welcome on the
Info-Kermit mailing list.

This program is available in KER:VF*.* on COLUMBIA-20 (ARPANET FTP) or CU20B
(CCNET NFT).

- Frank
-------
 2-Feb-84 15:40:41-EST,769;000000000000
Return-Path: <@CUCS20:POLARIS@USC-ISI>
Received: from CUCS20 by CU20B with DECnet; 2 Feb 84 15:40:34 EST
Received: from USC-ISI.ARPA by COLUMBIA-20.ARPA with TCP; Thu 2 Feb 84 15:38:29-EST
Date: 2 Feb 1984 12:34-PST
Sender: POLARIS@USC-ISI
Subject: KERMIT FOR HP3000
From: POLARIS@USC-ISI
To: INFO-KERMIT@COLUMBIA-20
Message-ID: <[USC-ISI] 2-Feb-84 12:34:39.POLARIS>

i REMEMBER READING A MESSAGE a while back about someone at work on
a KERMIT for the HP-3000.  Has there been any progress on this?
If a HP-300 KERMIT is somewhere available, we would appreciate info
on obtaining it, otherwise, we are interested in trying to produce
at least a basic KERMIT (no file SERVER).  Any advice, or help would be
greatly appreciated.

-Mike Seyfrit, Polaris
 2-Feb-84 19:58:52-EST,635;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 2 Feb 84 19:58:48 EST
Date: Thu 2 Feb 84 19:55:53-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: KERMIT FOR HP3000
To: [e-mail], INFO-KERMIT@CUCS20
In-Reply-To: Message from "POLARIS@USC-ISI" of Thu 2 Feb 84 15:34:00-EST

No news since I last checked.  But before you start on anything, check with
Ken Poulton at HP labs, who was going to do a version for the HP-1000 and
-3000 using the Software Tools.  Ken is at kdp.hp-labs@Rand-Relay.  After
doing this, please let me know who's doing what.  Thanks.  - Frank
-------
 2-Feb-84 20:14:17-EST,1065;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 2 Feb 84 20:14:14 EST
Date: Thu 2 Feb 84 20:00:55-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: KERMIT for HP-150
To: Info-Kermit@CUCS20
cc: [e-mail], [e-mail],
    [e-mail]

KERMIT for the HP-150 MS DOS micro is now available.  It is based on IBM PC
Kermit Version 1.3A, circa last June.  It works quite well for both terminal
emulation (HP2621) or file transfer.  Terminal connection loses occasionally at
4800 baud, but this seems to be a feature of the firmware.

The support for the HP-150 come from Frank Heartney at HP.  We'll be
integrating it into the new MS DOS KERMIT in the next few weeks.  In the
meantime, it's available as KER:HP150.* from COLUMBIA-20 (ARPANET FTP) or CU20B
(CCNET NFT).  The .FIX file is a nibble-encoded .EXE file, which you can
download using the same procedure as for IBM PC Kermit (assuming you have
Basic) -- the PCKSEND and PCKGET programs.

- Frank
-------
 2-Feb-84 20:26:49-EST,1004;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 2 Feb 84 20:26:43 EST
Date: Thu 2 Feb 84 20:02:53-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: KERMIT for Data General AOS
To: Info-Kermit@CUCS20

An implementation of KERMIT for Data General machines running AOS has been
contributed by John Lee of RCA Labs, Princeton, New Jersey.  It is written in
Ratfor, and is essentially a translation of the Unix implementation -- a basic
"no frills" KERMIT that runs in both remote and local mode, and can communicate
with IBM mainframes as well as ordinary full-duplex ASCII systems.  In glancing
through the code, I also noticed hooks for running under RDOS.

The files are in KER:AOS*.* available via anonymous FTP from host COLUMBIA-20
(ARPANET) or NFT from CU20B (CCNET).  Thanks to Glenn Everhart of RCA GSD, who
is also the DECUS RSX SIG Tape coordinator, for unearthing this version, doing
the tape conversion, and sending it in.

- Frank
-------
 3-Feb-84 19:32:02-EST,2274;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 3 Feb 84 19:31:58 EST
Date: Fri 3 Feb 84 19:30:42-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: [TS.WALT: Fortran/Pascal "VMS KERMIT"]
To: Info-Kermit@CUCS20

Too many KERMITs for the VAX?
                ---------------
From-the-terminal-of: "Walt Lamia (LAMIA at TOPCAT)"
Subject: Fortran/Pascal "VMS KERMIT"

    I am, sorry to say, disappointed in the release of yet another
Kermit for VMS.  We have had our problems in getting the Bliss version working
well, and this introduces a whole new product to worry about.  Let me
voice my concern and objection to the propagation of this version
anywhere beyond the originating system.  I have no objections to individual
sites writing whatever God-awful versions in whatever languages they think
are "neat" (i.e. let's all wait for some U.K. site to write a CORAL-66
version).  But for general public release and support, let's all of
us in the Kermit community agree on what (one!) version of the product
will be the official, legal, supported, definitive version for each
major system (maybe we should define those, too...I nominate TOPS-20,
TOPS-10, VMS, UNIX, CP/M, MS-DOS, VM(whatever) [IBM], RSX, RT11, RSTS,
and possible a "generic" Fortran (for host systems) and a "generic" Basic
version(for micros) for bootstraping onto new systems.  We should even
consider declaring one host version and one micro version as the "definitive"
version for test, verification, and certification purposes.

    I hope I don't sound too much like the autocratic software engineering
manager, but I foresee moby problems if lots of "slightly" different
versions with slightly different supported protocols are running
around ("Your new release of Version X doesn't work - you didn't
test it with Version Y" ... "But I did test it with Version Z, and it
worked")  (cf. X=Robin 3.7  Y=VMS Bliss  Z=TOPS-20).

    Feel free to forward this message around for comment.  If anyone
on the networks wants to send me mail, please use the following (also
CC. to EIBEN):

         DECnet       TOPCAT::LAMIA
         Usenet       ...decvax!decwrl!rhea!topcat!lamia
    ARPAnet        decwrl!rhea!topcat!lamia@Shasta
-------
 4-Feb-84 00:26:52-EST,958;000000000000
Return-Path: <@CUCS20:judd%umcp-cs@CSNet-Relay>
Received: from CUCS20 by CU20B with DECnet; 4 Feb 84 00:26:49 EST
Received: from csnet-cic.ARPA by COLUMBIA-20.ARPA with TCP; Sat 4 Feb 84 00:25:35-EST
Date:     3 Feb 84 22:56:41 EST  (Fri)
From: Judd Rogers <judd%umcp-cs@CSNet-Relay>
Return-Path: <judd%umcp-cs@CSNet-Relay>
Subject:  Re:  [TS.WALT: Fortran/Pascal "VMS KERMIT"]
To: Frank da Cruz <cc.fdc@COLUMBIA-20>, Info-Kermit@COLUMBIA-20
Via:  UMCP-CS; 3 Feb 84 23:05-EST

Since the fortran/Pascal versions of Kermit work NOW lets make them the
standards (or bring them up to the same functionality of the non-working
Bliss version and then make them standard).  After all, standard programs
should work!  {swat! for people who insist on writing stuff in 'neat'
languages      like Bliss).

Better yet, formalize a functional deffinition of exactaly what any
correct Kermit program will do.  That will be the standard.

Judd Rogers
 4-Feb-84 00:58:04-EST,685;000000000000
Return-Path: <@CUCS20:MOORE.LOSANGEL.IBM-SJ@Rand-Relay>
Received: from CUCS20 by CU20B with DECnet; 4 Feb 84 00:58:00 EST
Received: from rand-relay.ARPA by COLUMBIA-20.ARPA with TCP; Sat 4 Feb 84 00:56:51-EST
Date: 3 Feb 1984 16:07:03-PST (Friday)
From: Jim moore <MOORE.LOSANGEL.IBM@Rand-Relay>
Return-Path: <MOORE.LOSANGEL.IBM-SJ@Rand-Relay>
Subject: KERMIT/VM/CMS
To: info-kermit@columbia-20
Via:  IBM-SJ; 3 Feb 84 20:49-PST

Is there anyone out there on VNET who has a running KERMIT for
VM/CMS?  I tried to assemble it here, but the required MACLIBs
seem to be hopelessly unavailable.

Thanks

Csnet:  MOORE.LOSANGEL.IBM@RAND-RELAY

VNET:  MOORE at LOSANGEL
 6-Feb-84 02:45:53-EST,846;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 6 Feb 84 02:45:48 EST
Received: from USC-ECLB.ARPA by COLUMBIA-20.ARPA with TCP; Mon 6 Feb 84 02:44:35-EST
Date:  5 Feb 1984 2340-PST
From: HFISCHER at USC-ECLB.ARPA
Subject: Draft User's Guide to PC-DOS & MS-DOS Kermit
To:   cc.fdc at COLUMBIA-20, cc.DAPHNE at COLUMBIA-20
cc:   info-kermit at COLUMBIA-20, HFischer at USC-ECLB

Frank and Daphne,

I have made up a first draft of a User's Manual for the KERMIT-86
version which includes the TAKE, SERVER, and SET CONSOLE.

This is available for FTP-ing from Arpanet host USC-ECLB, file
<HFischer>PCK20.LPT (default-style printable on dumb terminal), and
in file <HFischer>PCK20.MSS (Scribe file for use when generating
fancy printout for fancy printers).


     Herm Fischer
-------
 6-Feb-84 11:09:30-EST,1583;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 6 Feb 84 11:09:22 EST
Date: Mon 6 Feb 84 11:06:23-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re:  [TS.WALT: Fortran/Pascal "VMS KERMIT"]
To: [e-mail], Info-Kermit@CUCS20
In-Reply-To: Message from "Judd Rogers <judd%umcp-cs@CSNet-Relay>" of Fri 3 Feb 84 22:56:41-EST

I agree with the need to write a fully-configured KERMIT in some high-level
language, like C, to serve as a basis for any other implementation.  We'll
probably do this.  In the meantime, however, freedom of choice will have to
prevail.  There's no one place in the world that has an example of every
machine/operating system/language for which an implementation of KERMIT has
been done, and can therefore validate or compare all these versions.  In
particular, I've never heard before that the Bliss implementation of KERMIT for
the VAX was "non-working", and in fact have never had verification (except from
the original contributors) that the Pascal/Fortran version DID work.  Some
sites say they would rather run the Pascal/Fortran version because they don't
have Bliss, while others would rather run the Bliss version because they don't
have Pascal -- the latter include sites that also don't have Bliss.

While Bliss might not be our favorite language, I don't think it was chosen
because it was "neat", but rather because it was portable among several
different systems which the authors had to support -- the only such language
they had at their disposal.

- Frank
-------
 6-Feb-84 12:02:46-EST,451;000000000000
Return-Path: <@CUCS20:beattie@bbn-unix>
Received: from CUCS20 by CU20B with DECnet; 6 Feb 84 12:02:39 EST
Received: from mitre-gateway by COLUMBIA-20.ARPA with TCP; Mon 6 Feb 84 12:01:03-EST
Date:  6 Feb 1984 11:55:39 EST (Monday)
From: brian beattie <beattie at mitre-gateway>
Subject: unix kermit server
To: info-kermit at columbia-20

Hi,
    does anyone have/know of a kermit server that will run under
UNIX?

beattie at mitre-gateway

 6-Feb-84 13:16:45-EST,809;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 6 Feb 84 13:16:40 EST
Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Mon 6 Feb 84 13:15:15-EST
Date: Mon 6 Feb 84 10:15:23-PST
From: Ted Markowitz <[e-mail]>
Subject: Re: IBM PC Kermit
To: [e-mail], [e-mail],
    [e-mail]
In-Reply-To: Message from "Frank da Cruz <[e-mail]>" of Mon 23 Jan 84 16:48:23-PST

I'd just like to cast a vote in favor of taking the ANSI (VT100) terminal
emulation out of the 'sky' and putting it in the priority list. Much software
I'm aware of uses this standard and it would make life a GREAT deal simpler
for many folks.

Good luck and thanks for the effort in advance!

--ted
-------
 6-Feb-84 13:41:12-EST,813;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 6 Feb 84 13:41:08 EST
Received: from USC-ECLB.ARPA by COLUMBIA-20.ARPA with TCP; Mon 6 Feb 84 13:39:42-EST
Date:  6 Feb 1984 1038-PST
From: HFISCHER at USC-ECLB.ARPA
Subject: Minor revision made to PC KERMIT-86 User's Manual
To:   cc.fdc at COLUMBIA-20, cc.daphne at COLUMBIA-20
cc:   info-kermit at COLUMBIA-20

Frank and Daphne,

An error in the User's manual was corrected.  The changes indicate that
remote operation of KERMIT-86 over comm lines, using the DOS 2 CTTY
command need to redirect standard output to the remote console so the
informational and error messages don't fight with packets on the
comm line.  The files corrected are [ECLB]<HFischer>PCK20.LPT and .MSS .

  Herm Fischer
-------
 6-Feb-84 14:00:41-EST,642;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 6 Feb 84 14:00:37 EST
Date: Mon 6 Feb 84 13:43:51-EST
From: Daphne Tzoar <CC.DAPHNE@CUCS20>
Subject: Re: KERMIT/VM/CMS
To: [e-mail]
cc: info-kermit@CUCS20
In-Reply-To: Message from "Jim moore <MOORE.LOSANGEL.IBM@Rand-Relay>" of Fri 3 Feb 84 19:07:03-EST

 Three files are required, all of them available in the Kermit directory.
 They are: CMSKERMIT, CMSNXTFST and CMSWILD.  Copy these files to your
 CMS system, rename them to Kermit, Nextfst, and Wild.  They should
 compile without any problems.
/daphne
-------
 6-Feb-84 22:01:56-EST,687;000000000000
Return-Path: <@CUCS20:rag@uw-june>
Received: from CUCS20 by CU20B with DECnet; 6 Feb 84 22:01:52 EST
Received: from uw-june by COLUMBIA-20.ARPA with TCP; Mon 6 Feb 84 22:00:35-EST
Date: 6 Feb 1984 18:46:25-PST
From: David Ragozin <rag@uw-june>
To: beattie@mitre-gateway, info-kermit@columbia-20
Subject: Reply to brean beattie Re: Unix kermit server

I do not know of a unix kermit server, and would like to have such also.
I have, however, adapted the unix kermit.c so that it allows multiple
commands just as most other kermits do.  It is a short change
to the code, which seems to work on Berkeley 4.1 and 4.2. I can send
it in its current state if anyone is interested.
 7-Feb-84 01:44:06-EST,1314;000000000000
Return-Path: <@CUCS20:fox%vpi.vpi@Rand-Relay>
Received: from CUCS20 by CU20B with DECnet; 7 Feb 84 01:44:01 EST
Received: from csnet-cic.ARPA by COLUMBIA-20.ARPA with TCP; Tue 7 Feb 84 01:42:48-EST
Date:     Mon, 6 Feb 84 14:57 EST
From: Ed Fox <fox.vpi@Rand-Relay>
Return-Path: <fox%vpi.vpi@Rand-Relay>
Subject:  Can Kermit be used to build a communications subroutine for IBM PC?
Received: from rand-relay.ARPA by csnet-cic.ARPA ; 7 Feb 84 00:58:51 EST (Tue)
To: info-kermit@columbia-20
Cc: fox.vpi@Rand-Relay
Via:  vpi; 6 Feb 84 19:31-PST

Can some part or parts of Kermit be incorporated in another package?
I need a relatively small subroutine available (or something using
interrupts) that a DOS 2.10 C program can call to:
1)choose and logon to a machine, using direct LAN connection or autodialing
2)send ascii messages
3)receive and store ascii messages

The C program must also communicate with a user via keyboard and monitor.
My interest is in a reliable routine that is easy to use and won't take
too much memory, and is callable by C.  YTERM has been mentioned - is part of
that suitable instead of part of KERMIT?  Sorry for not knowing more about
where to start in this project.

Thanks for the help! - Ed Fox (fox.vpi@rand-relay on ARPANET
   or foxea@vpivm1 on bitnet)
 7-Feb-84 10:10:40-EST,757;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 7 Feb 84 10:10:33 EST
Date: Tue 7 Feb 84 10:08:31-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: Can Kermit be used to build a communications subroutine for IBM PC?
To: [e-mail], info-kermit@CUCS20
In-Reply-To: Message from "Ed Fox <fox.vpi@Rand-Relay>" of Tue 7 Feb 84 01:42:59-EST

Kermit is probably not what you want for choosing and logging in to a machine,
sending and receiving ASCII messages, manipulating autodialers.  These things
are done well by cheap commercial communication packages, but CP/M Kermit (at
least in its present state) concentrates more on terminal emulation and
protocol-driven file transfer.  - Frank
-------
 7-Feb-84 11:14:43-EST,506;000000000000
Return-Path: <@CUCS20:OC.WBC3@CU20B>
Received: from CUCS20 by CU20B with DECnet; 7 Feb 84 11:14:31 EST
Received: from CU20B by CUCS20 with DECnet; 7 Feb 84 11:06:59 EST
Date: Tue 7 Feb 84 11:07:19-EST
From: Bill Catchings <OC.WBC3@CU20B>
Subject: Wang PC
To: Info-Kermit@CUCS20

Has anyone adapted the IBM PC version of Kermit to support the Wang PC?
It runs MS-DOS, so it is at least possible.  Let me know if you have
even tried, otherwise I'll have to do it myself.

                        -Bill

-------
 7-Feb-84 11:46:33-EST,567;000000000000
Return-Path: <@CUCS20:gjg@cmu-cs-cad>
Received: from CUCS20 by CU20B with DECnet; 7 Feb 84 11:46:12 EST
Received: from CMU-CS-CAD by COLUMBIA-20.ARPA with TCP; Tue 7 Feb 84 11:43:50-EST
Date: 7 Feb 1984 11:33:46-EST
From: Greg.Glass@CMU-CS-CAD
To: info-kermit@cucs20
Subject: Kermit on the SUN

I recall sometime back seeing mention of someone getting kermit running
on a SUN.  As I am going to be moving a copy of ckermit.c(the vers. that
I use on our VAX) over to one of these I would like to get in touch with
anyone that has done this.
            Greg



 7-Feb-84 16:31:55-EST,816;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 7 Feb 84 16:31:50 EST
Date: Tue 7 Feb 84 16:30:25-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: CP/M-86 Kermit version 2.3 available
To: Info-Kermit@CUCS20

This is the version that runs on the DEC Rainbow and the NEC APC.  The major
differences from the earlier release are:

 Parity is handled correctly.
. IBM mode (parity, handshake, half duplex) works correctly.
. System dependencies are better isolated.
. Buffer clearing is done between packets to prevent "packet echoing".

Source is in KER:86*.*.  Hex and binary for the Rainbow are in KER:RB*.*, and
for the APC in KER:APC*.*.  All these files accessible at host COLUMBIA-20 via
anonymous FTP (ARPANET) or NFT from CUCS20 (CCNET).

- Frank
-------
 7-Feb-84 21:38:22-EST,1327;000000000000
Return-Path: <@CUCS20:ABN.ISCAMS@USC-ISID>
Received: from CUCS20 by CU20B with DECnet; 7 Feb 84 21:38:18 EST
Received: from USC-ISID.ARPA by COLUMBIA-20.ARPA with TCP; Tue 7 Feb 84 21:40:01-EST
Date: 7 Feb 1984 17:39-PST
Sender: ABN.ISCAMS@USC-ISID
Subject: Re: Wang PC
From: ABN.ISCAMS@USC-ISID
To: oc.wbc3@COLUMBIA-20
Cc: Info-Kermit@CUCS20
Message-ID: <[USC-ISID] 7-Feb-84 17:39:44.ABN.ISCAMS>
In-Reply-To: The message of Tue 7 Feb 84 11:07:19-EST from Bill Catchings <OC.WBC3@CU20B>

Bill,

Hope this reaches you - your original return message choked up my mailer
(HERMES).

I looked at the Wang PC's references and considered porting the IBM PC KERMIT
over to it - but couldn't figure out the right port addresses, and being
fairly new to interrupts...... got scared/felt dumb, and gave it up.  Not
very much information in the standard Wang manuals, at least not for a
relatively inexperienced 16-bit hacker like me.

Rots of ruck - would be most interested if someone does do this thing --
we have several Wang PCs here, and would like KERMIT to get some sort of
compatible protocol for talking with other systems/machines.  The Wang
proprietary communications software is very flexible, but won't error-trap
with other systems.

Regards,
David Kirschbaum
Toad Hall (ABN.ISCAMS@USC-ISID)
 8-Feb-84 13:16:10-EST,785;000000000000
Return-Path: <@CUCS20:OC.GARLAND@CU20B>
Received: from CUCS20 by CU20B with DECnet; 8 Feb 84 13:16:04 EST
Received: from CU20B by CUCS20 with DECnet; 8 Feb 84 13:16:05 EST
Date: Wed 8 Feb 84 13:12:26-EST
From: Richard Garland <OC.GARLAND@CU20B>
Subject: Rainbow Kermit
To: Info-kermit@CUCS20
cc: OC.GARLAND@CU20B

To all Rainbow Kermit developers:

I expect to put a few enhancements into Rainbow Kermit this week.  First
will be some optional flow control (a'la VT100 Auto XON/XOFF), and next
possibly will be integarting the special function keys (HELP, DO, EXIT,
etc.).  I am working on version 2.3 as a base.

If you are or intend to do anything to Rainbow Kermit in the near furure,
please hold off or let me know so we can stay consistant.

                    Rg
-------
 8-Feb-84 14:43:45-EST,648;000000000000
Return-Path: <@CUCS20:johnston@LBL-CSAM>
Received: from CUCS20 by CU20B with DECnet; 8 Feb 84 14:43:41 EST
Received: from lbl-csam.ARPA by COLUMBIA-20.ARPA with TCP; Wed 8 Feb 84 14:43:45-EST
Return-Path: <johnston@LBL-CSAM>
Received: by lbl-csam.ARPA ; Wed, 8 Feb 84 11:44:09 pst
Date: Wed, 8 Feb 84 11:44:09 pst
From: (Bill Johnston [csam]) johnston@LBL-CSAM
Message-Id: <[e-mail]>
To: info-kermit@columbia-20
Subject: IBM/MVS Kermit?

Does anyone know of an MVS/TSO version of Kermit, or how close
the VM/CMS version might be (i.e. how hard would it be to convert)?
Thanks, Bill Johnston
johnston@lbl-csam
 8-Feb-84 18:17:35-EST,1255;000000000000
Return-Path: <@CUCS20:leo@MIT-PAMELA>
Received: from CUCS20 by CU20B with DECnet; 8 Feb 84 18:17:30 EST
Received: from MIT-MC by COLUMBIA-20.ARPA with TCP; Wed 8 Feb 84 17:37:11-EST
Date: Sunday 5 February 1984 09:46:24 EDT
From: Leo Hourvitz <leo@mit-pamela>
Subject: Too many Kermits (Kermi ?)
To: <Info-Kermit%COLUMBIA-20@mit-mc>


I'm afraid I disagree with Walt Lamia's feelings about too many
kermits.  Of course, it ain't up to me, it's gonna be up to
Frank as to what Info-Kermit 'supports', but it seems that there
can indeed be valid reasons for multiple kermits propagating
around.  For instance, the X version uses a feature not available
here, or, we don't have the compiler for the Y version.  I know
that in installing software on systems I have been glad to find
alternate versions of a program, since for some reason the alternate
versions came up much more easily than the first version I got.
I understand Walt L.'s concern with infinite numbers of implmentations
floating around; certainly, we can ask why these people wrote their
own implementation instead of using an existing one.  But often,
they had some reason for doing so...

Leo Hourvitz
Architecture Machine Group, MIT
Arpa: leo%mit-pamela@mit-mc

 8-Feb-84 19:27:34-EST,1686;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 8 Feb 84 19:27:24 EST
Date: Wed 8 Feb 84 19:28:18-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: IBM/MVS Kermit?
To: "(Bill Johnston [csam]) johnston"@LBL-CSAM.ARPA, info-kermit@CUCS20
In-Reply-To: Message from "(Bill Johnston [csam]) johnston@LBL-CSAM" of Wed 8 Feb 84 14:44:06-EST

There have been many rumors of people doing KERMIT for MVS (or OS) / TSO, but
to date none have panned out (somebody please correct me if I'm wrong).  In any
case, I'd venture to suggest that it might be more fruitful to work from one of
the PL/I or Fortran implementations as a base, rather than the VM/CMS version,
which is pretty much "bare bones" at this point.  There's a PL/I version for
Honeywell Multics available in KER:MU*.*, and another one for PRIME computers
is on a tape that's on its way to me in the mail.  A Fortran version for
the Cyber 170 is in KER:170*.*.

The PL/I version is probably the better choice -- it's an easier language to
work with than Fortran, and turns out to be the (or a) system-programming
language on quite a few systems, not just IBM, where a more modern or
"acceptable" high-level language like C or Pascal is not available.

If anybody wants to take a shot at this, please let me know first; I have a
few ideas about how the program should be broken up into modules to isolate
system dependencies, so that the resulting PL/I program could have system-
dependent plug-in modules to let it run under MVS/TSO, VM/CMS, MULTICS,
PRIME, etc etc, so that all these systems could share the most advanced
possible protocol module.

- Frank
-------
 9-Feb-84 11:13:56-EST,1220;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 11:13:49 EST
Date: Thu 9 Feb 84 11:15:11-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: unix kermit server
To: [e-mail], info-kermit@CUCS20
In-Reply-To: Message from "brian beattie <beattie at mitre-gateway>" of Mon 6 Feb 84 11:55:39-EST

We've received a UNIX Kermit server from someone in France, but we haven't had
an opportunity to evaluate it yet.  We've also received many other changes to
Unix Kermit from many other sources, and have quite a lot of checking and
merging to do.  After we get a new MS DOS Kermit release out the door (which
is where we're devoting all our effort just now, except for installing and
announcing new Kermit contributions ever day, it seems, and shipping out about
five tapes per day), we're going to concentrate on Unix Kermit, bringing it up
to the level of what's described in the protocol manual, modularizing it, etc.
In particular, isolating the protocol module will go a long way towards
satisfying the need of having a system-independent file Kermit file service
kernel that can be incorporated into any system that has C.  - Frank
-------
 9-Feb-84 12:49:28-EST,1650;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 12:49:22 EST
Date: Thu 9 Feb 84 12:22:14-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: KRFC #10 (?), database service
To: Info-Kermit@CUCS20

Somebody called me from the Canadian Film Board with an idea that never
occurred to me before, even though it's very simple.  He's got some huge
database on his DEC-20, and wants to use KERMIT from a PC to get selected
records from it.  The protocol does provide for sending things other than
files, like directory listings, etc, so why not records from databases?  How
about a new generic command, say "B", whose argument is a string which you pass
to a database program -- the string being the search or lookup key, relational
expression or whatever.  The Kermit server runs the database program (the user
would have to tell it which database program, and which database, in advance),
for instance as an inferior process -- this is easy under systems like Unix or
TOPS-20 -- and each lookup command would have the server feed the argument
string to the database program, get the result (easy under Unix) and send it
back in packets (the program on the user side would have the option of
displaying this information on the screen or putting it in a file).  This
simple procedure would go a long way towards providing the "integrated micro-
mainframe link" that we read about so much in the business-oriented trade
publications.  Anybody see any problems or pitfalls here?  I have absolutely no
experience with database applications, so I don't want be too glib here.

- Frank
-------
 9-Feb-84 13:02:37-EST,1464;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 13:02:26 EST
Date: Thu 9 Feb 84 13:02:49-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: KRFC # 11, Kermit commands
To: Info-Kermit@CUCS20

Another simple idea.  When communicating with a KERMIT server, particularly a
server running on the DEC-20, you often wish you could send it a command such
as you would type to it if it were running interactively.  For instance, you
were sending text files to it, but now you want to send an 8-bit binary file.
Rather than shut down the server, connect to the remote side, start Kermit up
interactively, and give commands like SET FILE BYTESIZE 8 or whatever, wouldn't
it be a lot easier to type the command from your local system?  This requires a
new packet type, say "K", with the command string in the data field.  This
would be similar to the G (generic command) and C (host command) packets.  K
will be an implementation-specific Kermit command, which the server will
execute as if it had been typed at it interactively.

An example of using this (from, say, an IBM PC) --

Kermit-86>send *.asm
Kermit-86>remote kermit set file bytesize 8
Kermit-86>send *.exe
Kermit-86>remote kermit set file bytesize 7
Kermit-86>send *.txt

You could also use it to turn debugging logs on and off, or to do anything
else the remote KERMIT might be capable of in interactive mode.

Comments?  - Frank
-------
 9-Feb-84 15:34:40-EST,592;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 15:34:19 EST
Received: from RADC-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Thu 9 Feb 84 15:32:54-EST
Date:  9 February 1984 15:31 est
From:  Wiedemann.4506i1808 at RADC-MULTICS
Subject:  KERMIT for MULTICS???
To:  info-kermit at COLUMBIA-20

     Is there an implementation of KERMIT for the MULTICS system
available??  We can "ftp" from virtually anywhere, but transferring
things down to a dial-up user cannot be presently done.
     Thanx for your help!

Wolf Wiedemann
 9-Feb-84 16:07:05-EST,2422;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 16:06:53 EST
Received: from ut-ngp.ARPA by COLUMBIA-20.ARPA with TCP; Thu 9 Feb 84 16:04:32-EST
Date: Thu, 9 Feb 84 15:05:30 cst
From: [e-mail]
Posted-Date: Thu, 9 Feb 84 15:05:30 cst
Message-Id: <[e-mail]>
Received: by ut-ngp.ARPA (4.22/3.14)
    id AA14632; Thu, 9 Feb 84 15:05:30 cst
To: [e-mail]
Subject: Re:  KRFC #10 (?), database service

Please, let's not forget what we are working with here!  Kermit is designed
for reliable data transfer.  If we start adding more to the protocol so that
it can be all things to all people, we may effectively deter others from
using it just because the protocol is so massive.  If anything, I would like
to see the protocol simplified so that there are two levels of the protocol.
One level is the packet transfer protocol which provides a reliable mechanism
for data transfer.  The next level would implement the file transfer protocol.
If we want to add something for database record retrieval, let it replace the
file transfer protocol.  Let's keep the two seperate.

This brings me to another point.  When we say Kermit, what exactly are we
talking about.  The Kermit file transfer programs and the Kermit protocol
are seperate issues.  I see real problems with adding to the protocol and
expecting microcomputers with limited address space to be able to implement
it.  I am not sure that even the current protocol with all the file attribute
mess can be implemented on a fair amount of micros.

Now let's talk about reliability and support.  As an implementor of a
new kermit (Cyber), I am finding it extremely difficult to even keep up with
the current protocol (involving attributes and whatnot).  How many other
Kermit programs are there that need to be brought up to the current
protocol level?  I would imagine almost all of them.  We need to start working
more with support and reliability than changing things.  We have more than
enough work now to keep us all busy for a long time.  If someone else wants
to design and implement protocol layers above Kermit, fine, let them.
It should be done that way anyhow.  Make it be a seperate protocol and program
from Kermit.  Kermit is a good protocol.  Let's not blow it.

From the smoldering fingers of Jim Knutson
knutson@ut-ngp
 9-Feb-84 16:50:31-EST,3189;000000000000
Return-Path: <@CUCS20:OC.WBC3@CU20B>
Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 16:50:25 EST
Received: from CU20B by CUCS20 with DECnet; 9 Feb 84 16:47:55 EST
Date: Thu 9 Feb 84 16:46:48-EST
From: Bill Catchings <OC.WBC3@CU20B>
Subject: Re:  KRFC #10 (?), database service
To: [e-mail],
    [e-mail]
In-Reply-To: Message from "[e-mail]" of Thu 9 Feb 84 16:07:06-EST

I am afraid I must agree with Jim Knutson, this is getting out of hand.
The most important work that remains to be done with the protocol is that
of defining its different levels.  Every six months or so some one comes up
with another great idea for what should be in the Kermit protocol.  It has
grown well beyond its original intention, to provide a simple, easy to
implement, means of reliable file transfer.  Rather than jamming more into
the present protocol it is now time to step back and evaluate.

                KRFC #12

For the sake of argument, I'm going to call what I'm going to talk about
Kermit II.  If it is possible to do this within the existing structure,
then so much the better.  If not, maybe we should look ahead.  Kermit II
would just provide reliable task to task communication.  This is now
usually refered to as packetizing.  At this level some initial negotiation
is done that concerns packetizing, such as padding, quoting etc.  This is
presently done in the Send Init packet.  If a Kermit is restarted or does
not hear from its counter part for a given amount of time then this is
renegotiated.  It may also be necessary to renegotiate on the fly.

The higher level is that of the individual application.  The first one to
be specified would be file transfer.  Another might be remote commands
(presently server remote commands).  Frank's database could be yet another.
An individual program could implement whatever it felt necessary.  The
"normal" one would be file transfer and remote commands (basically today's
Kermit).  A minimal one might just implement file transfer.  On systems
like Tops-20 or Unix the remote server Kermit might just be a packetizer
that would fork up the appropriate application and feed it an unpacketized
stream of data.  The application would then have its own "packetizing" and
higher level protocol as well.

This is just a rough outline, I have thought through "Kermit II" quite a
bit more thoroughly over the last year since I started to muddy the waters
with the "Kermit Server".  The real question is, do people really want to
do this kind of thing, or is file transfer all they care about.  Before you
jump too fast look at PCnet.  It started out sort of as Kermit II, it was
more than people wanted.  If so, lets do it right and then see if when can
get the existing Kermit to fit within that frame work without too much
trouble.  If people really want a more generalize micro to mainframe
communications solution, lets aggressively go at it.  If not, then lets
keep the present Kermit practical and not try to make it all things to all
people.  This is definately a "Kermit Request for Comments".

                    -Bill Catchings

-------
 9-Feb-84 18:21:47-EST,459;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 18:21:41 EST
Date: Thu 9 Feb 84 18:19:57-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: KERMIT for MULTICS???
To: [e-mail], info-kermit@CUCS20
In-Reply-To: Message from "Wiedemann.4506i1808 at RADC-MULTICS" of Thu 9 Feb 84 15:31:00-EST

A Multics Kermit is available in KER:MU*.* on COLUMBIA-20 via anonymous FTP.
-------
 9-Feb-84 18:34:19-EST,864;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 18:34:15 EST
Date: Thu 9 Feb 84 18:25:55-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re:  KRFC #10 (?), database service
To: Info-Kermit@CUCS20
In-Reply-To: Message from "[e-mail]" of Thu 9 Feb 84 16:04:52-EST

I agree, mostly.  But don't forget -- whenever anything new is added to "the
protocol", nobody is forced to add it to any particular implementation.  The
most advanced implementation in the world can still be used by the most
primitive and/or oldest.  The directory listing & similar stuff has been in
the protocol manual for over a year; this database stuff is a very simple
adaptation of the same idea.  As far as Kermit is concerned, there's nothing
about it that's any different from any other kind of file transfer.
-------
 9-Feb-84 19:30:41-EST,1275;000000000000
Return-Path: <@CUCS20:decwrl!rhea!atfab!wyman@Shasta>
Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 19:30:36 EST
Received: from Shasta by COLUMBIA-20.ARPA with TCP; Thu 9 Feb 84 19:30:25-EST
Received: from decwrl by Shasta with UUCP; Thu, 9 Feb 84 16:27 PST
Date: Thursday,  9 Feb 1984 16:15:06-PST
From: decwrl!rhea!atfab!wyman@Shasta
Subject: KRFC #10 (?), database service
Message-Id: <8402100020.AA16068@DECWRL>
Received: from RHEA.ARPA by DECWRL (3.327/4.09) 9 Feb 84 16:20:03 PST (Thu)
To: [e-mail]

I would like to second the concerns expressed by knutson@ut-ngp and
reopen my past suggestion that a KERPAC (KERMIT Packet) specification
be established which is independent of the KERMIT file transfer
protocol. There are all sorts of things which need to be implemented
in a total workstation protocol set. We can't clowd the KERMIT spec
with everything, nor can we accept the requirement that every addition
be cleared through Columbia-20... By locking the "new toys" into the
KRFC approval process, we will be essentially limiting the opportunites
for creativity. Better that we divide the spec into KERPAC and KERMIT
file transfer, then focus on making sure the "capabilities negotiation"
works well.

        bob wyman
 9-Feb-84 19:44:48-EST,623;000000000000
Return-Path: <@CUCS20:leo@MIT-PAMELA>
Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 19:44:44 EST
Received: from MIT-MC by COLUMBIA-20.ARPA with TCP; Thu 9 Feb 84 19:32:51-EST
Date: Thursday 9 February 1984 14:50:44 EDT
From: Leo Hourvitz <leo@mit-pamela>
Subject: Kermit on the SUN
To: <Greg.Glass%cmu-cs-cad%cmua@mc>, <info-kermit%columbia-20@mc>


Greg-

I got uxkermit (Unix Kermit) running on the Suns we have here in
as much time as it took to compile.  (Finding another kermit machine
immediately handy took a few minutes more)...

Leo Hourvitz
Architecture Machine Group
leo%pamela@mit-mc

 9-Feb-84 19:55:19-EST,2236;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 19:55:14 EST
Date: Thu 9 Feb 84 19:34:34-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Fancy stuff
To: Info-Kermit@CUCS20

Ahh, it's been a while since this discussion group has had a real discussion.
I too have the feeling that the Kermit protocol may be getting out of
control, but the two recent suggestions, I think, are quite minor optional
features that don't bend the protocol very much out of shape at all.

Two features that do, however, are file attributes and alternate block
check types.  The alternate block check types were added after I attempted
an analysis of the probability of transmission errors going undetected using
the default 6-bit checksum.  No matter how you figure it (e.g. it's simply
1/2^6, or by counting the number of errors that could cancel each other out
against the total number of possible errors, of 1 bit, 2 bits, 3 bits...),
it always seemed to come out the same.  1/64 is pretty poor odds; I panicked
and wrote the alternate block checks into the protocol.  These turn out to
add an awful lot of hair and complication, especially when used in
conjunction with server operation.  What really throws me, though, is that
I have NEVER heard of an error slipping through when using the single
character checksum.  How can that be?  Any mathematicians or epistimologists
out there?

The file attributes business, which so many people object to, arise -- sad
to say -- out of necessity when dealing with file systems like FILES-11
(RMS) or IBM mainframe systems like CMS, OS, MVS, etc, where a file is
meaningless without its attributes.  In such systems, it is often the
case that the absolute basic, simplest goal of KERMIT, i.e. file transfer,
turns out to be impossible without passing attributes back and forth.  Those of
you on wonderful systems like Unix where a file is a linear sequence of
8-bit bytes just can't begin to "appreciate" the hair that has to be raveled
and unraveled to get, say, a CMS binary file to a PC and back.  But why,
you say, would anyone ever want to do such a thing?  Well, suffice it to say
that they do.  Sigh...

- Frank
-------
 9-Feb-84 20:08:51-EST,522;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 20:08:48 EST
Received: from MIT-XX.ARPA by COLUMBIA-20.ARPA with TCP; Thu 9 Feb 84 19:56:11-EST
Date: Thu 9 Feb 84 19:39:44-EST
From: Thomas S. Wanuga <[e-mail]>
Subject: Kaypro, VENIX
To: [e-mail]
cc: [e-mail]

I am looking for versions of KERMIT that run on the IBMPC running the
VENIX operating system, and the Kaypro.  Do such things exist?  Thanks.

Tom Wanuga
-------
 9-Feb-84 21:00:30-EST,656;000000000000
Return-Path: <@CUCS20:judd%umcp-cs@CSNet-Relay>
Received: from CUCS20 by CU20B with DECnet; 9 Feb 84 21:00:27 EST
Received: from csnet-cic.ARPA by COLUMBIA-20.ARPA with TCP; Thu 9 Feb 84 21:00:21-EST
Date:     8 Feb 84 14:24:55 EST  (Wed)
From: Judd Rogers <judd%umcp-cs@CSNet-Relay>
Return-Path: <judd%umcp-cs@CSNet-Relay>
Subject:  Re:  Reply to brean beattie Re: Unix kermit server
To: David Ragozin <rag@uw-june>, info-kermit@columbia-20,
        beattie@mitre-gateway
Message-Id: <445116237.503.1@umcp-cs>
Via:  UMCP-CS; 9 Feb 84 20:12-EST

Yes,  I would like to see the Kermit server.  You might send it to
net.sources.

Judd Rogers
10-Feb-84 00:28:44-EST,1434;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 10 Feb 84 00:28:40 EST
Date: Fri 10 Feb 84 00:28:52-EST
From: Ken Rossman <cc.Ken@CUCS20>
Subject: Re:  KRFC #10 (?), database service
To: Info-Kermit@CUCS20
In-Reply-To: Message from "Frank da Cruz <[e-mail]>" of Thu 9 Feb 84 18:26:26-EST
Address: 716 Watson Labs, 612 W.115th St, NY, NY 10025
Phone: [phone]

I agree with Frank that Kermit currently is, and can always continue to be
a protocol that can be added to.  The basic functions will always still be
there, and won't change, so even the most simple-minded Kermit will be able
to do it's basic job with the most advanced multi-processing, database-
reading, super-automatic, sock-washing, house-cleaning Kermits.

I'd like to throw in my two cents on the database program idea, though.  I
think that same idea could be extended into a more general case (for
TOPS-20 in any case) where the local Kermit could instruct the remote
(TOPS-20) Kermit to run just about any program and hand it some command
string as a rescan argument.  Why limit yourself only to databases?  Why
not be able to run Finger too, for example?

OK, so that's getting pretty far off base, and is perhaps a poor example,
but I just figure as long as something like database manager fork code
might be added, it's not so hard to generalize it a little more.  /Ken
-------
10-Feb-84 02:51:53-EST,645;000000000000
Return-Path: <@CUCS20:LIN@MIT-MC>
Received: from CUCS20 by CU20B with DECnet; 10 Feb 84 02:51:50 EST
Received: from MIT-MC by COLUMBIA-20.ARPA with TCP; Fri 10 Feb 84 02:52:05-EST
Date: 10 February 1984 02:51 EST
From: Herb Lin <LIN @ MIT-MC>
To: LIN @ MIT-MC, info-kermit @ COLUMBIA-20

dear people

I have the DOC files on generic Kermit for CP/M and Kermit for
TOPS-20.  I have been unable to learn just how I can use the
kermit-cpm/kermit-20 combination to transfer files from a 20 to my
cp/m machine.  I feel really stupid, but can you supply a pointer to
where in the documentaiton this information lives?  many thanks.


10-Feb-84 09:59:16-EST,533;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 10 Feb 84 09:58:54 EST
Date: Fri 10 Feb 84 09:58:14-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: Kaypro, VENIX
To: [e-mail]
cc: Info-Kermit@CUCS20
In-Reply-To: Message from "Thomas S. Wanuga <[e-mail]>" of Thu 9 Feb 84 19:56:22-EST

Kermit for the Kaypro is in KER:CPMKAYPRO.* on COLUBMIA-20 (anonymous FTP).
KER:KERMIT.C is the Unix version, hopefully easily adaptable to the PC with
Venix.  - Frank
-------
10-Feb-84 10:15:45-EST,973;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 10 Feb 84 10:15:38 EST
Received: from CISL-SERVICE-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Fri 10 Feb 84 10:00:49-EST
Received: from HIS-PHOENIX-MULTICS.ARPA by CISL-SERVICE-MULTICS.ARPA dial; 10-Feb-1984 09:57:09-est
Sender:  Charlie Spitzer <[e-mail]>
Date:  Fri, 10 Feb 84 07:45 MST
From:  Charlie Spitzer <[e-mail]>
Subject:  Re: KERMIT for MULTICS??? (INFO-KERMIT [0262])
To:  [e-mail]
cc:  [e-mail]
Message-ID:  <[e-mail]>

Yes, there is a Multics implementation, however it is not very good and
certainly not complete. You can get a version that at least works from
Klensin @ MIT-Multics for the source and a brief description of how to
use the features that do work.
 charlie
 (Spitzer%pco @ CISL)
10-Feb-84 10:28:41-EST,982;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 10 Feb 84 10:28:35 EST
Date: Fri 10 Feb 84 10:01:20-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re:  Reply to brean beattie Re: Unix kermit server
To: [e-mail], [e-mail], info-kermit@CUCS20,
    [e-mail]
In-Reply-To: Message from "Judd Rogers <judd%umcp-cs@CSNet-Relay>" of Wed 8 Feb 84 14:24:55-EST

The Unix Kermit server is in KER:X*.* on COLUMBIA-20.  We haven't really looked
at it yet, and the person who did this made a lot of assumptions about how
things should work that are not necessarily valid, but you're welcome to try
it out & report your findings.  Like I said in an earlier message, our next
project at Columbia, after getting a new release of MS DOS Kermit out, will be
to rework Unix Kermit according to the same modularized scheme, and bring it up
to the level described in the protocol manual.  - Frank
-------
10-Feb-84 10:47:29-EST,3775;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 10 Feb 84 10:47:20 EST
Date: Fri 10 Feb 84 10:47:08-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re:  KRFC #10 (?), database service
To: cc.Ken@CUCS20, Info-Kermit@CUCS20
cc: cc.fdc@CUCS20
In-Reply-To: Message from "Ken Rossman <[e-mail]>" of Fri 10 Feb 84 00:29:02-EST

I agree with Ken.  Rather than scare people off with the word "database",
let's just say there can be a command to tell the Kermit server to start up
a program, and another to give the program a command.  Something like this:

GP~programName~optionalCommandLineArgument

This would let you run Finger, or any Unix-like program and get the results
back in packets, which you could display on the screen, store on the disk,
print on the printer, etc.  If the program is interactive, then the result that
you get back would probably be the program's herald, if any, and its first
prompt.

To run an interactive program, the kind that keeps prompting for commands,
another Kermit packet would let you send a command to the current loaded
program (and get the results back, including the next program prompt):

GJ~command

(the "~" is a length field.)

Not only would implementation of such a facility be optional, it would be
IMPOSSIBLE on many - if not most - systems.

Just to clarify, when a new feature is added to KERMIT:

(a) It doesn't change the basic packet protocol, the format of the packets,
    the rules for connecting and disconnecting, the sequence of events and
    so forth.  KERMIT is basically a file transfer protocol, and all the
    other stuff that it can do -- directory listings, file deletion,
    directory changing, running programs, etc -- use the file transfer
    mechanism to send their commands and results back and forth.  Suggestions
    like the one above only add a new command withing the existing framework,
    The new feature is OPTIONAL, and if implemented, uses the very same
    code for communication that is already there.

(b) If you add the ability to send a new command, and you send this command
    to a server that doesn't know about it, the server will say "Sorry, I
    don't know that command".

(b) If you add the ability to execute a new command to server, and the user
    program doesn't know about it, no harm is done.

Anybody who likes a new idea can implement it if their system gives them the
tools to do so conveniently.  You'd have a tough time implementing this
program-running idea on TOPS-10 or CP/M, and it would be (dare I say) "trivial"
under Unix, and it would be possible but difficult on TOPS-20 or VM/CMS.
But nobody has to do it if they don't want to.  And if they like the idea, but
see some better way to do it, now's the time to say so.

The reason that these new ideas keep cropping up is that an unstated goal of
the KERMIT project is to provide a model (though not necessarily an actual
facility) that will allow users sitting at workstations the greatest possible
access to the facilities of a central system without actually logging in, with
the ultimate goal of getting more users simultaneously "hooked" to the central
system -- with its shared files, etc -- than could possibly be accommodated by
direct login.  Of course, networks will eventually solve this problem, but (a)
they're not here yet, at least not with the capacity and affordability required
for very large sites with limited budgets, and (b) there will always need to
be connections that are made from outside the network.

Well, enough pie in the sky.  The important thing is to kick these issues
around and work out the problems in prose rather than in code.

- Frank
-------
10-Feb-84 14:05:48-EST,497;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 10 Feb 84 14:05:44 EST
Date: Fri 10 Feb 84 14:05:40-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Kermit for PR1ME in PL/I available
To: Info-Kermit@CUCS20

Contributed by Leslie Spira, The SOURCE Telecomputing (McLean, VA), written
in a variant of PL/I which is PR1ME's implementation language.  The files
are in KER:PRIMEK.* at COLUMBIA-20, via anonymous FTP (or CU20B via NFT).

- Frank
-------
10-Feb-84 17:52:40-EST,1058;000000000000
Return-Path: <@CUCS20:kdp.HP-Labs@Rand-Relay>
Received: from CUCS20 by CU20B with DECnet; 10 Feb 84 17:52:35 EST
Received: from rand-relay.ARPA by COLUMBIA-20.ARPA with TCP; Fri 10 Feb 84 17:51:36-EST
Date: Fri, 10 Feb 84 13:20:34 pst
From: Ken Poulton <kdp%HP-LABS.HP-LABS@Rand-Relay>
Return-Path: <kdp.HP-Labs@Rand-Relay>
Subject: Re:  Fancy stuff
Received: by HP-VENUS id AA00955; Fri, 10 Feb 84 13:20:34 pst
Message-Id: <8402102120.AA00955@HP-VENUS>
To: Info-Kermit@COLUMBIA-20, cc.fdc@COLUMBIA-20
Source-Info:  From (or Sender) name not authenticated.
Via:  HP-Labs; 10 Feb 84 14:32-PST

On the adequacy of a 6 bit checksum:

With a 6 bit checksum, if we have two errors in the packet,
the probablity of not detecting that is indeed 1/64.
However, if there is a uncorrected errors per packet rate of x,
the probability of getting two errors in one packet is only x^2.
x is usually a small number (like 1/1000 to 1/1000000).
Thus the net probablility of an undetected double error is x*x*1/64.
This is small!  Don't worry about it.
11-Feb-84 13:11:18-EST,1677;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 11 Feb 84 13:11:11 EST
Received: from USC-ECLB.ARPA by COLUMBIA-20.ARPA with TCP; Sat 11 Feb 84 13:11:42-EST
Date: 11 Feb 1984 1007-PST
From: HFISCHER at USC-ECLB.ARPA
Subject: Kermit 86 Take Files for use with Unix EMACS
To:   info-kermit at COLUMBIA-20

Marco Papa has contributed a set of files which allow Kermit-86 to
fully use the functionality of Unix EMACS from the PC Keyboard.  I
have recommended to Columbia that they incorporate these files as an
additional appendix for the Kermit-86 User's Manual (or whatever those
folks eventually incorporate it into).  Meanwhile, so you Unix EMACS
users can benefit from this contribution, I have placed these files in
my directory for netland FTPing.  On net node ECLB, file
<HFischer>PCUXEMCS.ALL can be split into three files, one for use on
the Unix system, and two for use on the PC.  On the Unix system,
pc-h19-key.ml provides for Unix EMACS macro-key assignment for use
with the built-in Kermit-86 Heath-19 emulator (or a real Heath-19).
On the PC, a batch file, pcuxemcs.bat, is used to load kermit and
"take" console keyboard setup commands from the PC-resident TAKE file,
pcuxemcs.ker.  The procedure "undoes" the keyboard setup after the
user exits from kermit.  Comments in the file explains the
operation.

(If you have an old version of Kermit-86 with the take and server
additions, which gives an error message on the comment lines in take
files, contact me if you want a three line fix; or alternatively the
current version is in my directory under PCK20.NEW.)


   Herm Fischer
-------
12-Feb-84 11:17:42-EST,1340;000000000000
Return-Path: <@CUCS20:ABN.ISCAMS@USC-ISID>
Received: from CUCS20 by CU20B with DECnet; 12 Feb 84 11:17:38 EST
Received: from USC-ISID.ARPA by COLUMBIA-20.ARPA with TCP; Sun 12 Feb 84 11:18:15-EST
Date: 12 Feb 1984 08:06-PST
Sender: ABN.ISCAMS@USC-ISID
From: ABN.ISCAMS@USC-ISID
To: LIN@MIT-MC
Cc: info-kermit@COLUMBIA-20
Message-ID: <[USC-ISID]12-Feb-84 08:06:35.ABN.ISCAMS>
In-Reply-To: The message of 10 February 1984 02:51 EST from Herb Lin <LIN @ MIT-MC>

Herb,

Most of our hosts have KERMIT.DOC in their <DOCUMENTATION> directories, or
you can FTP it down (kind of big, though).  As I remember, COLUMBIA-20 now
has (in <KERMIT> CP/M and other users manuals, to include the TOPS-20/DEC
manual.

The manual was all right, I guess, but KERMIT grows and changes faster than
the manual documents!  If you're just trying to get the rascal running,
I think I can help you.  If you're trying to get the code implemented for
your own system...well, I can maybe help you there if your CP/M system is
one of those documented in CPMGENERI KERMIT.  Did a lot of hacking getting
it up on my Decision I, and studied the other system IF-END's thoroughly
in the process.

What stage are you in, and can you please describe your problems (code OR
running it!).

Regards,
David Kirschbaum
Toad Hall (ABN.ISCAMS@USC-ISID)
13-Feb-84 13:01:33-EST,648;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 13 Feb 84 13:01:25 EST
Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; Mon 13 Feb 84 13:01:45-EST
Date: Mon 13 Feb 84 10:00:13-PST
From: Ted Markowitz <[e-mail]>
Subject: Re: KRFC # 11, Kermit commands
To: [e-mail]
In-Reply-To: Message from "Frank da Cruz <[e-mail]>" of Thu 9 Feb 84 12:18:41-PST

Any thoughts been given to augmenting the VM/CMS version of Kermit
to act as a server also? I don't think there's been an update of
this version to include that functionality.

--ted
-------
13-Feb-84 15:15:40-EST,530;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 13 Feb 84 15:15:31 EST
Date: Mon 13 Feb 84 15:15:13-EST
From: Daphne Tzoar <CC.DAPHNE@CUCS20>
Subject: Re: KRFC # 11, Kermit commands
To: [e-mail]
cc: info-kermit@CUCS20
In-Reply-To: Message from "Ted Markowitz <[e-mail]>" of Mon 13 Feb 84 13:02:00-EST

There are plans for Kermit CMS to act as a server and to allow the
transfer of binary files.  It's merely a question of finding the
time.
/daphne
-------
13-Feb-84 17:01:33-EST,465;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 13 Feb 84 17:01:13 EST
Date: Mon 13 Feb 84 17:00:29-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: KRFC # 11, Kermit commands
To: [e-mail], Info-Kermit@CUCS20
In-Reply-To: Message from "Ted Markowitz <[e-mail]>" of Mon 13 Feb 84 13:02:00-EST

An upgrade of VM/CMS Kermit is pretty high on our list, right after the MS DOS
Kermit work.
-------
13-Feb-84 20:45:42-EST,1629;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 13 Feb 84 20:45:37 EST
Received: from CISL-SERVICE-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Mon 13 Feb 84 20:46:16-EST
Received: from HIS-PHOENIX-MULTICS.ARPA by CISL-SERVICE-MULTICS.ARPA dial; 13-Feb-1984 20:45:38-est
Date:  Mon, 13 Feb 84 18:43 MST
From:  Kevin Kenny <[e-mail]>
Subject:  Re: Fancy stuff
Reply-To:  [e-mail]
To:  [e-mail]
Message-ID:  <[e-mail]>

Ken Poulton's analysis is not really complete.  For one thing, on a 1200
baud link running with the 212A protocol, there's really no such thing
as a single-bit error, since the data go through a scrambler.  If the
comm line drops one bit, the unscrambled data will contain three
erroneous bits.  As it turns out, though, the 6-bit checksum will detect
all of these.

More severe is the possibility of "burst" errors, where the line will
give a whole burst of 0's or 1's instead of whatever it's supposed to be
sending.  Asynchronous lines in this state will only foul up at most two
characters in this case, though, before they encounter either a framing
error or what looks like an idle line.  The unscrambler may make it as
wide as three or four bytes.  In these cases, though, the result is
generally severe enough to cause a framing error (do many Kermits
check?) and kill the packet that way.

In other words, the checksum is probably PERFECTLY adequate on an async
line. Synchronous communication needs more.

/k**2
13-Feb-84 22:20:01-EST,666;000000000000
Return-Path: <@CUCS20:ALBERS@MIT-ML>
Received: from CUCS20 by CU20B with DECnet; 13 Feb 84 22:19:58 EST
Received: from MIT-ML by COLUMBIA-20.ARPA with TCP; Mon 13 Feb 84 22:20:31-EST
Date: 13 February 1984 22:18 EST
From: Jon P. Albers <ALBERS @ MIT-ML>
To: info-kermit @ COLUMBIA-20

I am thinking about adapting the version of KERMIT for the OSBORNE 1
to be used for the OCC-Executive 1.  The CPM3 version of KEMIT works on the
Exec, but a lot of the major features, especially the vt52 emulation,
are cut off.
I need some help from (Bruce Tanner), and anyone else familiar with KERMIT,
in general, or the OCC-1 or CPM 3.


                        Jon Albers



14-Feb-84 04:44:50-EST,1108;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 14 Feb 84 04:44:46 EST
Received: from Ucl-Cs by COLUMBIA-20.ARPA with TCP; Tue 14 Feb 84 04:45:16-EST
Via:  ykxa.ac.uk; to 44d.Ucl-Cs.AC.UK   over Sercnet with NIFTP;
          14 Feb 84 9:38 GMT
Via:    QZCOM; Date:    Monday, 13-Feb-84  20:42:34-GMT
Date:        13 Feb 84 13:29 +0100
From:        [e-mail]
Reply-to:    [e-mail],
             [e-mail]
To:          [e-mail],
             info-kermit <[e-mail]>
Subject:     Let's spread the good news!
Message-ID:  <41569@QZCOM>


It seems to me that there is a lot of people with personal computers
Out There who has never heard of KERMIT, and probably would be very
happy to. And I think KERMIT deserves more publicity. So, who writes
an article in BYTE?

    - Per Lindberg, QZ -

(Text 41569)------------------------------

15-Feb-84 13:47:55-EST,645;000000000000
Return-Path: <@CUCS20:CCIMS.WILSON@CUTC20>
Received: from CUCS20 by CU20B with DECnet; 15 Feb 84 13:47:46 EST
Received: from CUTC20 by CUCS20 with DECnet; 15 Feb 84 13:45:34 EST
Date: Wed 15 Feb 84 05:49:08-EST
From: Francis Wilson <CCIMS.WILSON@CUTC20>
Subject: Re:  KRFC #10 (?), database service
To: knutson%ut-ngp@CUCS20
cc: Info-Kermit%Columbia-20@CUCS20
In-Reply-To: Message from "[e-mail]" of Thu 9 Feb 84 16:08:39-EST

I'm still trying to get Kermit (CP/M version 3.6) to work on an
Apple II+, with an ALS CPM Plus card, and a Videx PSIO, so I'm
all for support, robustness, reliability, etc.

Francis
-------
15-Feb-84 17:24:06-EST,957;000000000000
Return-Path: <@CUCS20:POLARIS@USC-ISI>
Received: from CUCS20 by CU20B with DECnet; 15 Feb 84 17:24:00 EST
Received: from USC-ISI.ARPA by COLUMBIA-20.ARPA with TCP; Wed 15 Feb 84 15:30:50-EST
Date: 15 Feb 1984 12:28-PST
Sender: POLARIS@USC-ISI
Subject: IBM-PC KERMIT[86]
From: POLARIS@USC-ISI
To: info-kermit@COLUMBIA-20
Cc: frank da cruz@COLUMBIA-20
Message-ID: <[USC-ISI]15-Feb-84 12:28:31.POLARIS>

Do I have the most recent version of KERMIT for the IBM-PC?  I
have downloaded your 1.20, but have trouble using it under DOS
2.0.  I have probably missed a fix or a NET NOTE about it, but
the version I have for CP/M works, and this one cannot seem to
pass the INIT packet properly.

An additional question, If one uses a console redirection scheme
(ie, BYE.com) should there be any dificulty in using Kermit
remotely, micro to micro?, or does the local Kermit have to be in
the receive mode before the issuing f the send?

Thanks--
16-Feb-84 11:20:44-EST,894;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 16 Feb 84 11:20:27 EST
Date: Thu 16 Feb 84 11:19:06-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: KERMIT for Tandy 2000
To: Info-Kermit@CUCS20

This is an adaptation of IBM PC Kermit V1.20 (the current version) submitted
by Stephen Padgett at the University of Texas.  This support will eventually
be merged into the new MS DOS KERMIT, but for now it's available in
KER:TA2000.* on COLUMBIA-20 via anonymous FTP (ARPANET) or CU20B via NFT
(DECNET).  The .ASM file is the assembler source, the .FIX file is the
hexified .EXE file, which you can download following the same procedure as
for the IBM PC, described in KER:PCBOOT.HLP (note that all the files
referred to in that document have the prefix "PC" in the KERMIT distribution
area, e.g. KGET.BAS is found as PCKGET).

- Frank
-------
16-Feb-84 13:24:52-EST,2388;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 16 Feb 84 13:24:42 EST
Received: from Ucl-Cs by COLUMBIA-20.ARPA with TCP; Thu 16 Feb 84 13:20:25-EST
Received: from ykxa.ac.uk by 44d.Ucl-Cs.AC.UK   via Sercnet with NIFTP;
          16 Feb 84 18:16 GMT
Via:    UCL-CS; Date:    Wednesday, 15-Feb-84  16:28:40-GMT
Received: from Usc-Isid by 44d.Ucl-Cs.AC.UK   via Satnet with SMTP;
          15 Feb 84 13:17 GMT
Received: FROM MIT-MC BY USC-ISID.ARPA WITH TCP ; 15 Feb 84 01:04:49 PST
Date: 15 February 1984 04:06 EST
From: "Jerry E. Pournelle" <[e-mail]>
Subject:  Let's spread the good news!
To: Per_Lindberg_QZ <[e-mail]>,
    KERMIT_implementation_and_experience <[e-mail]>
cc: info-kermit <[e-mail]>
In-reply-to: Msg of 13 Feb 84 13:29 +0100 from Per_Lindberg_QZ%qzcom at ucl-cs.arpa
Sender: POURNE <[e-mail]>

what's that supposed to mean?  I do not know anything about
KERMIT either.  How should I?  There have been drearily long
expositions on the net at 300 baud;  I have yet to see anything
in print or in my mail.
If Kermit is available for any machine I know of, I'd like to
see it run.  can it work on a Compupro?  Z-80 or Dual Processor?
Ot what does it take to make it run?  Is there a way I can get a
copy  mailed to
J E Pournelle
BYTe
POB 372
Hancock NH 03449
    Or at least some description of what it is?

    Date: 13 Feb 84 13:29 +0100
    From: Per_Lindberg_QZ%qzcom at ucl-cs.arpa
    Reply-To: Per_Lindberg_QZ%qzcom at ucl-cs.arpa,
          KERMIT_implementation_and_experience%qzcom at ucl-cs.arpa
    To:   KERMIT_implementation_and_experience%qzcom at ucl-cs.arpa,
          info-kermit <info-kermit%columbia-20.arpa%columbia-20.arpa%ucl-cs.arpa%ykxa at ucl-cs.arpa>
    Re:   Let's spread the good news!
    Remailed-From: Billy <BRACKENRIDGE@USC-ISIB>
    Remailed-To: pourne@MIT-MC

    It seems to me that there is a lot of people with personal computers
    Out There who has never heard of KERMIT, and probably would be very
    happy to. And I think KERMIT deserves more publicity. So, who writes
    an article in BYTE?

        - Per Lindberg, QZ -

    (Text 41569)------------------------------


16-Feb-84 13:50:11-EST,534;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 16 Feb 84 13:50:04 EST
Date: Thu 16 Feb 84 13:47:56-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Info-Kermit mail archives
To: Info-Kermit@CUCS20

I've broken the mail archive file into two pieces, MAIL.83A (the mail from
1983), and MAIL.TXT (the current, active mail file).  From now on, old mail
will periodically be retired to MAIL.yyx, like MAIL.84A, MAIL.84B, etc.,
and MAIL.TXT will remain the active mail file.  - Frank
-------
16-Feb-84 21:17:24-EST,586;000000000000
Return-Path: <@CUCS20:judd%umcp-cs@CSNet-Relay>
Received: from CUCS20 by CU20B with DECnet; 16 Feb 84 21:17:18 EST
Received: from csnet-cic.ARPA by COLUMBIA-20.ARPA with TCP; Thu 16 Feb 84 21:16:26-EST
Date:     16 Feb 84 13:50:18 EST  (Thu)
From: Judd Rogers <judd%umcp-cs@CSNet-Relay>
Return-Path: <judd%umcp-cs@CSNet-Relay>
Subject:  Take me off Kermit mail list.  Someone else gets it and one is enough.
To: Frank da Cruz <cc.fdc@COLUMBIA-20>, Info-Kermit@COLUMBIA-20,
        G.TJM@SU-SCORE
Message-Id: <445804954.19853.3@umcp-cs>
Via:  UMCP-CS; 16 Feb 84 19:54-EST


17-Feb-84 08:22:19-EST,546;000000000000
Return-Path: <@CUCS20:KEN@JPL-VLSI>
Received: from CUCS20 by CU20B with DECnet; 17 Feb 84 08:22:16 EST
Received: from JPL-VLSI.ARPA ([10.3.0.54]) by COLUMBIA-20.ARPA with TCP; Fri 17 Feb 84 08:21:51-EST
Date: 17 Feb 1984 0507 PST
From: Ken Adelman <KEN@JPL-VLSI>
Subject: Please add
To: info-kermit@columbia-20
Reply-To: KEN@JPL-VLSI

    Me (KEN@JPL-VLSI) to the info-kermit list. I am currently trying
to use kermit on an apple2 and under VAX/VMS.

    Thanx,
                    Kenneth
                        Adelman
                    Califonia Institute of Technology
------
17-Feb-84 10:31:11-EST,729;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 17 Feb 84 10:31:03 EST
Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Fri 17 Feb 84 10:30:12-EST
Received: from RU-BLUE.ARPA by RUTGERS.ARPA with PUP; 17 Feb 84 10:30:42 EST
Date: 17 Feb 84 10:28:54 EST
From: Chris <[e-mail]>
Subject: TAKE & Server for PC DOS Kermit
To: [e-mail]


Hello,

    I remember reading a  message about a proposal  to add a  TAKE
command and  server  capability  to  the PC  DOS  Kermit.   Have  such
modifications been made?  If so, how can I obtain a copy of it..  I do
not have arpanet privileges, so I will not be able to ftp it myself..


                        Chris Tsai
-------
20-Feb-84 16:40:53-EST,1055;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 20 Feb 84 16:40:35 EST
Received: from Ucl-Cs by COLUMBIA-20.ARPA with TCP; Mon 20 Feb 84 16:37:45-EST
Received: from ykxa.ac.uk by 44d.Ucl-Cs.AC.UK   via Sercnet with NIFTP;
          20 Feb 84 21:31 GMT
Via:    QZCOM; Date:    Monday, 20-Feb-84  20:36:39-GMT
Date:        20 Feb 84 17:00 +0100
From:        [e-mail]
Reply-to:    [e-mail], [e-mail]
To:          Info-Kermit <[e-mail]>,
             [e-mail]
Subject:     KERMIT-800
Message-ID:  <42674@QZCOM>



The printout of 00README.TXT included with the distribution tape
(dated 2 February 1984) says that the Luxor ABC-800 has a CP/M-80 like
OS. Correction: it has its own OS called ABCDOS, which has no
similarities with CP/M. The PROMmed BASIC that KERMIT-800 is written
in, is similar to DEC BASIC-PLUS-2.

    - Per Lindberg QZ -


20-Feb-84 16:55:41-EST,939;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 20 Feb 84 16:55:31 EST
Received: from Ucl-Cs by COLUMBIA-20.ARPA with TCP; Mon 20 Feb 84 16:38:08-EST
Received: from ykxa.ac.uk by 44d.Ucl-Cs.AC.UK   via Sercnet with NIFTP;
          20 Feb 84 21:33 GMT
Via:    QZCOM; Date:    Monday, 20-Feb-84  20:37:30-GMT
Date:        20 Feb 84 18:32 +0100
From:        [e-mail]
Reply-to:    [e-mail],
             [e-mail]
To:          [e-mail],
             Info-Kermit <[e-mail]>
Subject:     Kermit for VM/CMS via YALE/IUP (Series/1)
Message-ID:  <42703@QZCOM>

Does anyone know of KERMIT development for the above configuration?



21-Feb-84 10:43:33-EST,1055;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 21 Feb 84 10:43:16 EST
Received: from Ucl-Cs by COLUMBIA-20.ARPA with TCP; Tue 21 Feb 84 10:40:06-EST
Received: from ykxa.ac.uk by 44d.Ucl-Cs.AC.UK   via Sercnet with NIFTP;
          21 Feb 84 13:45 GMT
Via:    QZCOM; Date:    Monday, 20-Feb-84  20:36:39-GMT
Date:        20 Feb 84 17:00 +0100
From:        [e-mail]
Reply-to:    [e-mail], [e-mail]
To:          Info-Kermit <[e-mail]>,
             [e-mail]
Subject:     KERMIT-800
Message-ID:  <42674@QZCOM>



The printout of 00README.TXT included with the distribution tape
(dated 2 February 1984) says that the Luxor ABC-800 has a CP/M-80 like
OS. Correction: it has its own OS called ABCDOS, which has no
similarities with CP/M. The PROMmed BASIC that KERMIT-800 is written
in, is similar to DEC BASIC-PLUS-2.

    - Per Lindberg QZ -


21-Feb-84 10:53:30-EST,1055;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 21 Feb 84 10:53:21 EST
Received: from Ucl-Cs by COLUMBIA-20.ARPA with TCP; Tue 21 Feb 84 10:40:06-EST
Received: from ykxa.ac.uk by 44d.Ucl-Cs.AC.UK   via Sercnet with NIFTP;
          21 Feb 84 13:45 GMT
Via:    QZCOM; Date:    Monday, 20-Feb-84  20:36:39-GMT
Date:        20 Feb 84 17:00 +0100
From:        [e-mail]
Reply-to:    [e-mail], [e-mail]
To:          Info-Kermit <[e-mail]>,
             [e-mail]
Subject:     KERMIT-800
Message-ID:  <42674@QZCOM>



The printout of 00README.TXT included with the distribution tape
(dated 2 February 1984) says that the Luxor ABC-800 has a CP/M-80 like
OS. Correction: it has its own OS called ABCDOS, which has no
similarities with CP/M. The PROMmed BASIC that KERMIT-800 is written
in, is similar to DEC BASIC-PLUS-2.

    - Per Lindberg QZ -


21-Feb-84 15:40:25-EST,1209;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 21 Feb 84 15:39:34 EST
Date: Mon 20 Feb 84 19:21:23-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: Kermit for VM/CMS via YALE/IUP (Series/1)
To: [e-mail],
    [e-mail],
    [e-mail]
cc: Info-Kermit@CUCS20
In-Reply-To: Message from "[e-mail]" of Mon 20 Feb 84 18:32:00-EST

The problem with using KERMIT over the Yale/IUP (Series/1) is that the IBM
VM/CMS host believes it's talking to a "green tube", i.e. IBM 3270-series
synchronous terminal.  If CMS Kermit were to send out a packet, first VM (or
is it CMS) would modify it by putting 3270 commands on it, and then the
IUP would modify it still further by "interpreting" the 3270 commands (by
translating them to escape codes for the particular ASCII terminal) and also
by translating EBCDIC to ASCII (which, of course, has already been done).

We need the ability to use KERMIT over the IUP too, but the solution to this
problem is not easy.  - Frank
-------
21-Feb-84 18:23:51-EST,681;000000000000
Return-Path: <@CUCS20:maples@bbn-unix>
Received: from CUCS20 by CU20B with DECnet; 21 Feb 84 18:23:48 EST
Received: from mitre-gateway by COLUMBIA-20.ARPA with TCP; Tue 21 Feb 84 18:22:11-EST
Date: 21 Feb 1984 18:18:38 EST (Tuesday)
From:  <maples at mitre-gateway>
Subject: Standard (?) Kermit
To: info-kermit at columbia-20

    Iam in search of a semi-standard kermit of reasonable
size and capability.  If such a system exists at your site as
advertized by Dick Gillman at Columbia-20, please send me the
particulars for FTP retrieval of source and documentation, if
you have user manuals or pointers, please inform also.
        Thanks,
            Greg Maples (maples@mitre)

25-Feb-84 19:22:41-EST,864;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 25 Feb 84 19:22:35 EST
Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Fri 24 Feb 84 01:52:30-EST
Date:  Thu, 23 Feb 84 13:46 EST
From:  Barry Margolin <[e-mail]>
Subject:  kermit with real terminal emulator
To:  [e-mail]
Message-ID:  <[e-mail]>

Anyone have a kermit implementation for MS-DOS (specifically, I have an
IBM-PC and a Honeywell MicroSystem 6/10) that includes a real terminal
emulator.  I am looking for something which emulates a common video
terminal, such as an H19; simple "ship the output straight to the
screen" is not really useful.

Please reply directly to me, as I don't read this list.  Thanks.
                                        barmar
27-Feb-84 06:35:43-EST,1106;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 27 Feb 84 06:35:40 EST
Received: from Ucl-Cs by COLUMBIA-20.ARPA with TCP; Mon 27 Feb 84 06:35:51-EST
Received: from ykxa.ac.uk by 44d.Ucl-Cs.AC.UK   via Sercnet with NIFTP;
          27 Feb 84 10:29 GMT
Via:    QZCOM; Date:    Monday, 27-Feb-84  09:48:35-GMT
Date:        24 Feb 84 17:45 +0100
From:        [e-mail]
Reply-to:    [e-mail], [e-mail]
To:          Info-Kermit <[e-mail]>,
             [e-mail]
Subject:     KERMIT for IBM/GUTS
Message-ID:  <43384@QZCOM>


Is there any news from the people who are implementing KERMIT under
GUTS?  We here at QZ (Stockholm Univ. Comp. Center) need one badly.
I want to check with the rest of the KERMIT world before we go any
further. If we get desperate enough, we might try to make one together
with GD (Gothenburg Data center). (But mind you, that's no *PROMISE*!)

    - Per Lindberg QZ -



27-Feb-84 15:20:03-EST,783;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 27 Feb 84 15:19:53 EST
Received: from RADC-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Mon 27 Feb 84 15:16:39-EST
Date:  27 February 1984 15:15 est
From:  Wiedemann.4506i1808 at RADC-MULTICS
Subject:  MULTICS implementation
To:  info-kermit at COLUMBIA-20

     I recently copied the MUKERMIT file from COLUMBIA for installation
on our MULTICS.  I am having problems compiling the PL1 code as it was
copied.
     Is there anyone that has any hints for implementing this version of
KERMIT for MULTICS?  I realize that there are other sources available
for MULTICS, but I find the features on this version to be rather com-
plete.
     Thanx for your help!

Wolf Wiedemann
27-Feb-84 17:31:55-EST,960;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 27 Feb 84 17:31:50 EST
Date: Mon 27 Feb 84 17:29:18-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: MULTICS implementation
To: [e-mail], info-kermit@CUCS20
In-Reply-To: Message from "Wiedemann.4506i1808 at RADC-MULTICS" of Mon 27 Feb 84 15:15:00-EST

I can't help but suspect that there is something wrong with FTP between here
and MULTICS sites; I've had this complaint before.  Yet, when I look at
KER:MUKERMIT.PLI on COLUMBIA-20, it is correct and complete; the pieces which
people say are missing are really there.

On problem is that there are some variables that are initialized in the
PL/I source code with real control characters.  I suspect that this may be
causing some problems for MULTICS FTP?  Let me know the sections you're having
trouble with; maybe I can extract them and mail them to you.  - Frank
-------
27-Feb-84 20:39:34-EST,760;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 27 Feb 84 20:39:27 EST
Received: from ut-sally.ARPA by COLUMBIA-20.ARPA with TCP; Mon 27 Feb 84 20:39:20-EST
Date: Mon, 27 Feb 84 19:39:16 cst
From: [e-mail] (John Quarterman)
Posted-Date: Mon, 27 Feb 84 19:39:16 cst
Message-Id: <[e-mail]>
Received: by ut-sally.ARPA (4.22/4.22)
    id AA15149; Mon, 27 Feb 84 19:39:16 cst
To: [e-mail]
Subject: jsq@ut-sally -> info-kermit@ut-sally
Cc: [e-mail]

Please replace jsq@ut-sally with info-kermit@ut-sally for INFO-KERMIT.
If there are any other users receiving INFO-KERMIT on ut-sally,
I'd like to redirect their feed through the local info-kermit alias.
28-Feb-84 11:55:11-EST,1095;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 28 Feb 84 11:55:05 EST
Date: Tue 28 Feb 84 11:53:58-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Software Tools Ratfor Kermit for HP3000 & Univac 1100
To: Info-Kermit@CUCS20
cc: [e-mail]

Announcing a remote-only version of Kermit (capable of server operation)
written in Ratfor to run under the Software Tools environment.  This version of
Kermit was originally written by Kendall Tidwell & Allen Cole, University of
Utah Computer Center, for the Univac 1100/60, with support added for the HP3000
by Ken Poulton of HP Labs.  It should be readily adaptable to any other system
that has the Software Tools package.

The program is in KER:STKERMIT.RF, and a help file is in KER:STKERMIT.HLP,
available via anonymous FTP from COLUMBIA-20 (ARPAnet) or NFT from CU20B
(CCNET/DECnet).  The program will also be available over BITnet via the
KERMIT server, KERMSRV, at host CUVMA.

Thanks to Ken Poulton at Hewlett-Packard for contributing this version.

- Frank
-------
28-Feb-84 14:27:48-EST,1388;000000000000
Return-Path: <@CUCS20:fenchel@wisc-rsch>
Received: from CUCS20 by CU20B with DECnet; 28 Feb 84 14:27:40 EST
Received: from wisc-rsch.ARPA by COLUMBIA-20.ARPA with TCP; Tue 28 Feb 84 14:27:24-EST
Date: Tue, 28 Feb 84 13:23:28 cst
From: fenchel@wisc-rsch (Bob Fenchel)
Message-Id: <[e-mail]>
Received: by wisc-rsch.ARPA (4.22/3.7)
    id AA07104; Tue, 28 Feb 84 13:23:28 cst
To: info-kermit@columbia-20
Subject: Kermit on Victor
Cc: fenchel@wisc-rsch

I am having difficulty trying to run Kermit on the Victor 9000.
Here are the details:

Retrieved vicmsdos.asm from columbia-20 <kermit> directory,
assembled it on ibm-pc, transferred exe file to victor.
This is apparently a somewhat older version of kermit that
has been modified in Scotland.

The program runs on victor in "connect" mode without difficulty
(in fact I'm using it now), however I don't seem to be able
to transfer files either to or from the victor using the
receive/send modes.  Either the program appears to do nothing,
or it rapidly sends/waits but can not receive the initiate
signal from the other system.  I have tried communicating
with an IBM PC running the newer version of KERMIT and with
a vax/unix system.  In both cases, "terminal" mode works fine
but file transfer does not.

I'd appreciate any assistance you might have to offer.

Bob
(fenchel@UWisc)
29-Feb-84 11:19:33-EST,1079;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 29 Feb 84 11:19:17 EST
Received: from CISL-SERVICE-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Wed 29 Feb 84 11:18:35-EST
Received: from HIS-PHOENIX-MULTICS.ARPA by CISL-SERVICE-MULTICS.ARPA dial; 29-Feb-1984 11:14:33-est
Date:  Wed, 29 Feb 84 09:11 MST
From:  [e-mail]
Subject:  Re: Kermit on Victor
To:  [e-mail]
cc:  [e-mail]
Message-ID:  <[e-mail]>

   I had basically the same problems trying to up/download things from
a Multics system.  My problem was the fact that the parity settings on
my system (a Compaq) was set to even parity (Default), and the Multics
Kermit was set to no parity (It's default). The extra bit caused
Multics-Kermit to refuse anything I sent it (ONLY intransfer mode NOT
in terminal mode). After I changed my kermit to no parity it worked
like a charm.

                    Good luck!
                    Gary Brz...


29-Feb-84 19:57:27-EST,926;000000000000
Return-Path: <@CUCS20:fenchel@wisc-rsch>
Received: from CUCS20 by CU20B with DECnet; 29 Feb 84 19:57:20 EST
Received: from wisc-rsch.ARPA by COLUMBIA-20.ARPA with TCP; Wed 29 Feb 84 19:57:13-EST
Date: Wed, 29 Feb 84 18:53:19 cst
From: fenchel@wisc-rsch (Bob Fenchel)
Message-Id: <[e-mail]>
Received: by wisc-rsch.ARPA (4.22/3.7)
    id AA08262; Wed, 29 Feb 84 18:53:19 cst
To: info-kermit@columbia-20
Subject: Kermit on Victor

Thanks to those who answered my call for help.  I was only able to
get the old version of Kermit running at 300 baud for file transfer;
as noted by several respondents to my message, it is necessary to
have NO parity set.

Frank da Cruz placed a new version of VICMSDOS.ASM in the <KERMIT>
directory on Columbia-20; I am now running this version without any
difficulty at 4800 and 9600 baud for file transfer (sure beats the
heck out of 300 baud!).

Bob
 1-Mar-84 18:58:45-EST,2569;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 1 Mar 84 18:58:39 EST
Date: Thu 1 Mar 84 18:58:47-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New Release of CP/M-86 KERMIT
To: Info-Kermit@CUCS20

Announcing a new release of KERMIT-86 for the DEC Rainbow 100 or the NEC APC
running CP/M-86.  This is version 2.4 of the program, and it was contributed by
Richard Garland of the Columbia University Chemistry Department.  Here are the
new features:

 SET FLOW-CONTROL to allow XON/XOFF flow control to be turned on and off.
  When used, XON/XOFF allows use of smooth scrolling and the HOLD SCREEN
  button on the Rainbow during terminal connection without loss of data,
  even at high speeds, providing the system you're connected to also does
  XON/XOFF flow control (DEC-20s and VAXes do).

 The Rainbow can now transmit a BREAK signal (you must type the CONNECT
  escape character followed by a B to do this).

 File transfers with the DEC-20, VAX, and other systems that have relatively
  advanced KERMITs can now be interrupted by typing CTRL-X (stop this file and
  go on to the next) or CTRL-Z (stop the entire transfer).

 KERMIT-86 will now time out according to the interval requested by the
  KERMIT on the other side of the connection.  This makes file transfer with
  systems that cannot time out (such as IBM mainframes) a lot more robust.

The new KERMIT-86 is available on COLUMBIA-20 via anonymous FTP (ARPAnet), or
CU20B via NFT (DECnet).  The relevant files are:

  KER:RBKERMIT.CMD    The executable KERMIT program for the Rainbow.
  KER:RBKERMIT.H86    The hex file for the Rainbow (load with GENCMD).
  KER:RBKERMIT.HLP    Information about Rainbow KERMIT.

  KER:APCKERMIT.CMD    The executable KERMIT program for the NEC APC.
  KER:RBKERMIT.H86    The hex file for the NEC APC (load with GENCMD).
  KER:APCKERMIT.HLP    Information about NEC APC KERMIT.

  KER:86*.A86        The ASM86 source files for the program.
  KER:86KERMIT.HLP    General information about CP/M-86 KERMIT.
  KER:86KER24.BWR    Some implementation notes for version 2.4.

To obtain the new version on your Rainbow or APC, use your present version
of KERMIT to transfer the appropriate .CMD file.  If you have trouble doing
that, then transfer the .H86 file and build a .CMD file from it using
GENCMD.  If you don't have KERMIT on your Rainbow, read KER:RBKERMIT.HLP
for a helpful hint, or follow the installation directions in the KERMIT User
Guide.  Report any problems directly to me.

- Frank da Cruz
-------
 2-Mar-84 19:55:33-EST,3382;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 2 Mar 84 19:55:25 EST
Date: Fri 2 Mar 84 19:55:35-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New KERMIT User Guide
To: Info-Kermit@CUCS20

The 5th edition of the KERMIT User Guide is now available.  It reflects the new
features added since July 1983, when the 4th edition was released.  The new
edition has been "modularized" (as we are trying to do with many of the KERMIT
programs).  The main section is system-independent, and attempts to describe an
"ideal" KERMIT.  The remaining sections come from separate files, one for each
implementation.  Each site can include sections on only those implementations
they care about.  The manual is written in SCRIBE text formatter language,
suitable for producing documentation for a variety of media, ranging from
online files to be read on a screen, to line printer output (with overstriking
and underscoring), to daisy-wheel printer output (with fractional vertical
spacing and other special effects), to multifont laser printer or photocomposer
output.  SCRIBE is a commercial product from UNILOGIC, Inc, in Pittsburgh PA,
and is available for a variety of systems, including TOPS-10, TOPS-20, UNIX,
IBM mainframe operating systems, Apollo, etc., and the source language is also
compatible in large degree with the formatting language of Perfect Writer and
Final Word on microcomputers.

Some of the documentation is actually ahead of the software.  In particular,
the sections describing DEC-20 and MS DOS KERMITs apply to soon-to-be-released
versions (watch this space for news).

All files are available in KER: on COLUMBIA-20 via anonymous FTP (ARPANET) or
CU20B (DECNET).  The Scribe source files are:

USER.MSS    The system-independent part, and the "root file" for the rest.
20KERMIT.MSS    Description of DEC-20 KERMIT.
VMSKERMIT.MSS    .. DEC VAX/VMS KERMIT.
CMSKERMIT.MSS    .. IBM VM/CMS KERMIT.
UXKERMIT.MSS    .. UNIX KERMIT.
PCKERMIT.MSS    .. IBM PC (and other MS DOS systems) KERMIT.
CPMKERMIT.MSS    .. CP/M-80 KERMIT.
86KERMIT.MSS    .. CP/M-86 KERMIT.

The *KERMIT.MSS files are selected with "@INCLUDE" statements in USER.MSS.
These @INCLUDE statements can be edited or shuffled in any way to easily
customize the manual (if you have Scribe).

Some implementations do not have much documentation to speak of.  Others have
good documentation, but it's not in Scribe format.  Anyone who would like to
produce "Scribified" documentation for any system not listed above should feel
free to volunteer (let me know first, so I can prevent duplication of effort).
Even if you don't have Scribe, you can use the *KERMIT.MSS files as a guide.

In addition to the .MSS files, there are also finished documents in several
formats:

USER.DOC    The entire manual, with all the @INCLUDE files, as plain
        text (no special effects), suitable for reading on line.

USER.LPT    Ditto, suitable for printing on a line printer, with
        boldface (overstriking) and underscoring.

USER.FOR    Like USER.LPT, but with Fortran-style carriage control in
        "column 1".

There are also .DOC files (but not .LPT or .FOR) for each of the @INCLUDE
files listed above.

Comments welcome.  There will also be a new Protocol Manual shortly, containing
no major changes, mainly just clarification of fine points.
-------
 5-Mar-84 17:03:08-EST,1353;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 5 Mar 84 17:03:01 EST
Received: from SRI-KL.ARPA by COLUMBIA-20.ARPA with TCP; Mon 5 Mar 84 16:58:00-EST
Date: Mon 5 Mar 84 14:01:03-PST
From: William "Chops" Westfield <[e-mail]>
Subject: Getting kermit to run on our system...
To: [e-mail]

Hi.  As a staunch supporter of MODEM2 over KERMIT, I have not yet
brought KERMIT up on our 20s.  Alas, however, there are people who
dont have MODEM2 who want to talk to us, so I FTPed over the latest
version of KERMIT, and tried to set it to working.  IT DOESN'T WORK!
I am unable to get it to transfer files even to itself! (This same
KERMIT works fine on other systems.)  What happens (usually), is that
about 5 packets are transferred, and then 5 errors occur (quite quickly,
leading me to beleive that perhaps timeouts arent working properly),
and KERMIT aborts.  Can someone give me a hand tracking the problem
down ?  As far as I know, the only relevant difference in our system
is that we implement a hold key that toggles output, but this is turned
off in binary mode, and is mutually exclusive with DECs XON/XOFF....

Has anyone experience similar problems?  HELP!
(please be sure and CC responses to me.  Im not on INFO-KERMIT)

Thanks
Bill Westfield
-------
 5-Mar-84 22:27:14-EST,2255;000000000000
Return-Path: <@CUCS20:gts%ucbpopuli.CC@Berkeley>
Received: from CUCS20 by CU20B with DECnet; 5 Mar 84 22:27:08 EST
Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Mon 5 Mar 84 22:27:04-EST
Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.25)
    id AA21012; Sun, 4 Mar 84 14:27:56 pst
Received: from ucbpopuli.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA
    (4.14.noSUID/4.14.2) id AA06503; Sun, 4 Mar 84 14:22:42 pst
Received: by ucbpopuli.CC.Berkeley.ARPA
    (4.14/4.14) id AA03045; Sun, 4 Mar 84 14:28:39 pst
Date: Sun, 4 Mar 84 14:28:39 pst
From: gts%ucbpopuli.CC@Berkeley
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Kermit 8-bit Data Problems

It seems that there is a slight inconsistency in computing block-checks.
Please check the following and let me know if I am wrong.

Apparently, UNIX `kermit r' computes the block-check AFTER trimming the
eighth bit but micro kermits compute it BEFORE.  Hence, if any of the
original data bytes had the eighth bit set, the checksum will fail if in
a single packet, an odd number of data bytes had the eighth bit set!
UNIX uses block-check-type 1 (6 bits), hence, a checksum error will be
detected only if an odd number of eighth bits occur in a single packet
(since bits above 8 are discarded and bits 7 and 8 are shifted to the
bottom of the byte and added, the checksum will differ by 2).

UNIX should be changed to compute the block-check BEFORE trimming the
eighth bit in `r' mode.

The micro kermits set the parity on outgoing bytes AFTER computing
the block-check based on the full eight bits of each data byte, hence,
if some data bytes have the eighth bit set and the result does not match
the micro kermit parity mode, the receiver will detect a checksum error,
identically as UNIX above. This prevents using `set parity space' to
trim the eighth bit.

The micro kermits should be changed to set parity before computing the
block-check during send.


Greg Small                [phone]
Microcomputer Communications        [e-mail]
214 Evans Hall CFO            gts%ucbpopuli.CC@Berkeley
University of California        [e-mail]
Berkeley, Ca 94720

 6-Mar-84 11:52:57-EST,2150;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 6 Mar 84 11:52:48 EST
Date: Tue 6 Mar 84 11:52:08-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: Kermit 8-bit Data Problems
To: [e-mail], INFO-KERMIT@CUCS20
In-Reply-To: Message from "gts%ucbpopuli.CC@Berkeley" of Mon 5 Mar 84 22:27:34-EST

The high-order, or "8th", bit is used for two different purposes in KERMIT.
It's preferred use is for data.  But it can't be used for data if a device
anywhere along the communications path demands its use for parity.  When parity
must be used, the user types a command like "set parity odd" (or even, mark, or
space).  Normally, parity is "none".

When the 8th bit is used for data, it figures into the block check.  When
parity is being used, the parity bit does NOT figure into the block check.

Unix Kermit does not do any parity processing at all.  Under normal operation,
it strips the 8th bit of incoming & outbound bytes and maps LF to CRLF & vice
versa.  In "image mode" ("-i" on command line) it leaves the data alone, and
the 8th bit figures in the block check.  Image mode is intended for Unix-to-
Unix transfers, but may also be used for sending microcomputer binary files
to Unix & getting them back.  Normal mode is for transfer of text files, either
Unix-to-Unix, or between unlike systems.

Microcomputer Kermits (CP/M-80, CP/M-86, MS DOS), on the other hand, are
capable of doing parity processing.  In the normal case, no parity is used, the
8th bit may be used for data, and it figures into the block check.  When parity
is being used, an outbound byte should have its 8th bit stripped, the result
added to the block check, and then the appropriate parity bit tacked on; an
inbound byte should have its parity stripped before it is added to the block
check.  Without 8th-bit prefixing (which most micro Kermits don't have yet),
binary files cannot be sent while parity is being done.

We are currently checking CP/M-80 Kermit to make sure it actually works as
described above; we already had reason to believe it wasn't.

- Frank
-------
 6-Mar-84 17:44:30-EST,1734;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 6 Mar 84 17:44:17 EST
Date: Tue 6 Mar 84 17:43:36-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: IBM Portable PC & Kermit
To: [e-mail], Info-Kermit@CUCS20

I'm writing this note on an IBM Portable PC which we have on loan for
a few days, using KERMIT in H19 emulation mode with EMACS.  KERMIT seems to
work just fine on this new machine; I didn't test it extensively, but I
transferred a few files back & forth with no difficulty at all, and the
terminal emulator works fine with EMACS.

A couple impressions about the portable PC -- the 8.5" amber screen is awful.
I have nothing against amber, but the monitor is driven by the IBM color
adapter, so you get the low resolution characters and the disconcerting flicker
during scrolling.  There's no monochrome option.  The keyboard is exactly like
the PC/XT keyboard, except with a different base that folds onto the front of
the unit.  The cord plugs into the front of the unit (hooray!) with a phone
jack and stores inside the keyboard.

I installed an IBM async adapter and it worked fine right away (at 4800 baud).
I notice there are 6 expansion slots.  4 of them are very short, 1 is a little
bit longer, and one appears to be ALMOST long enough for the AST or Quadram
multifunction boards.  There's an annoying high pitched noise coming out of the
vent in back.  The noise plus the flicker would make this machine no fun to sit
in front of all day.  But the compatibility and the keyboard beat the PCjr.

Speaking of the PCjr, we have one of those on loan for a few days too and will
try to get KERMIT running on it if we can.

- Frank
-------
 6-Mar-84 18:58:51-EST,761;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 6 Mar 84 18:58:49 EST
Date: Tue 6 Mar 84 18:57:12-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Current KERMITs List
To: Info-Kermit@CUCS20

In response to the many requests from people who wanted a single file to look
in to see what the current versions of the various KERMIT implementations are,
I've started a current-Kermits list in the file KER:CURRENT.DOC (it's short).
It shows the prefix the file is stored under, the machine/OS, programming
language, version number if any, date installed, and major contact (not
necessarily the author) as a net address when possible.  Available as usual
via anonymous FTP (ARPANET) or NFT (DECNET).  - Frank
-------
 7-Mar-84 19:32:48-EST,1205;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 7 Mar 84 19:32:33 EST
Date: Wed 7 Mar 84 19:32:29-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: CP/M-86 Kermit v 2.5 (yes, another release)
To: Info-Kermit@CUCS20

This is a slight modification to version 2.4, announced last week.  The main
differences are that the features added in 2.4 were made to work on the NEC
APC as well, and the new timeout facility can be turned on and off with a
SET TIMER command.  Also, the SET FILE-WARNING command was renamed to
SET WARNING, to avoid conflict with SET FILE-TYPE.

Timeouts are not used unless you ask for them by typing SET TIMER ON.
You should normally only have to request timeout when transferring files
with the IBM mainframe, since it cannot do its own timeouts.

The new files replace the old ones in the KERMIT areas on COLUMBIA-20 (or
CU20B), for instance KER:RBKERMIT.CMD and .H86 for the Rainbow, and
KER:APCKERMIT.CMD and .H86 for the NEC APC, on the DEC-20s.  The sources and
documentation are in KER:86*.*, as before.  Thanks to Ron Blanford at the
University of Washington and Bernie Eiben at DEC for the updates.

- Frank
-------
 8-Mar-84 10:21:26-EST,1096;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 8 Mar 84 10:21:21 EST
Received: from ut-ngp.ARPA by COLUMBIA-20.ARPA with TCP; Thu 8 Mar 84 10:19:15-EST
Date: Thu, 8 Mar 84 09:20:17 cst
Posted-Date: Thu, 8 Mar 84 09:20:17 cst
Message-Id: <[e-mail]>
Received: by ut-ngp.ARPA (4.22/3.14)
    id AA17966; Thu, 8 Mar 84 09:20:17 cst
From: King Ables <[e-mail]>
To: [e-mail]
Subject: bug in CPMBASE.M80 v3.6

I've been seeing a bug where the ^Zs at the end of a CP/M file
are getting sent as data to the host kermit and I end up with
them in my file after the transfer.  I've looked at the code
but being new to CP/M and fairly new to 8080 code, I'm not too
sure what the fix is.  I think it's happening in getchr.  Has
anybody seen/fixed this?  I have also seen it on our Z-100
(built from PCKERMIT.ASM?) which seems interesting.  I'm using
an H89 on the CPMBASE.M80 version from home.  If someone has a
fix, please let me know, else consider this a bug report.
Thanks,
King
(ables@ut-ngp)
 8-Mar-84 12:57:53-EST,1471;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 8 Mar 84 12:57:46 EST
Date: Thu 8 Mar 84 12:50:17-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: bug in CPMBASE.M80 v3.6
To: [e-mail], info-kermit@CUCS20
In-Reply-To: Message from "King Ables <[e-mail]>" of Thu 8 Mar 84 10:19:40-EST

The problem with seeing ^Z's at the end of a file sent from a micro stems from
the difficulty in determining the end of a microcomputer file.  In CP/M, for
instance, the eof is defined as the first ^Z anywhere in the file, except for
binary files, whose eof is at the end of the last block.  CP/M-80 Kermit
treats files as binary by default (since it's better to send junk after the
end of a text file than to truncate a binary file that may have contained a
^Z in the middle).  You can avoid the junk at the end of text files by typing
SET FILE-TYPE (or FILE-MODE) ASCII (or TEXT) (syntax varies from program to
program) before sending text files.  You can also reassemble the program with
the default file type set for text files.

The situation is a little more complicated for MS DOS (IBM PC & Z100 Kermit),
because it keeps a byte count, which should point to the end of the file.
Unfortunately, some applications also put a ^Z at the end of the file, and this
too is included in the byte count.  So one has no way of knowing whether the
^Z should be considered part of the file.

- Frank
-------
 8-Mar-84 14:37:44-EST,889;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 8 Mar 84 14:37:36 EST
Date: Thu 8 Mar 84 14:06:00-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New RSX-11/M/M+ and RSTS/E Kermit
To: Info-Kermit@CUCS20
cc: BBoard@CU20A, BBoard@CU20B, BBoard@CU20C, BBoard@CU20D, AP2.L-Lidofsky@CU20A

This is a new release of Brian Nelson's Macro-11 Kermit.  The major change is
that procedures are now provided for installing and running the programs on
non-RMS systems, and under releases of RSTS or RSX earlier than the ones
required to actually build the programs -- hexified renditions of the binaries
are provided, along with conversions and installation instructions.  The files
are in KER:K11*.* on COLUMBIA-20, CU20B, and CU20D.  See KER:K11INS.DOC for the
new installation instructions and system requirements.  Thanks Brian!  - Frank
-------
 8-Mar-84 19:10:32-EST,2262;000000000000
Return-Path: <@CUCS20:johnston@lbl-csam>
Received: from CUCS20 by CU20B with DECnet; 8 Mar 84 19:10:26 EST
Received: from lbl-csam.ARPA by COLUMBIA-20.ARPA with TCP; Thu 8 Mar 84 19:06:30-EST
Return-Path: <johnston@lbl-csam>
Received: by lbl-csam.ARPA ; Thu, 8 Mar 84 16:07:02 pst
Date: Thu, 8 Mar 84 16:07:02 pst
From: (Bill Johnston [csam]) johnston@lbl-csam
Message-Id: <[e-mail]>
To: info-kermit@columbia-20
Subject: Kermit/Telnet problem
Cc: fink@lbl-csam, pierre@lbl-csam


Frank,
 We currently have a sabbatical type from Norway in our Dept., and
for the past week or so, we have been trying to establish a Kermit
connection from our 4.2bsd UNIX system to a DEC-10 in Norway, via Telenet.
We have run into a number of things that I would like to pass on, and/or seek
advise on:

1) Telenet, being a packet network, transmits data on (at least) two conditions,
one, when there is enough data to fill a packet, and two,
when a "data forwarding" character is encountered in the data.
The data forwarding character is normally
a CR, and if it is possible to change this, it is not obvious from the
little documentation one gets form Telenet. The UNIX Kermit sets the packet
terminator to LF, in the UNIX style, and the connection through Telenet doesn't
work (since the Kermit packets are usually shorter than Telenet packets).
After studying the UNIX code, I concluded that there is no reason (other
than UNIX convention) to use a LF packet terminator. I suggest that this
be changed (to CR) in the UNIX distribution (for all flavors of UNIX,
not just UTS, as it is now).

2) Even with the helpful advice in the new manual, we couldn't ever get
the two Kermits to pass checksummed packets back and forth. The checksums
were never computed correctly on the UNIX end (that is to match the DEC-10
checksums). We tried all of the different parity settings on the DEC-10
end, still to no avail. We can, however, get packets from UNIX to the DEC-10.
I have fixed this, temporarily, by disabling the checksum checking on the
UNIX end, but this is clearly nonsence in the long run.

I would be grateful for any advise.


    Bill Johnston, Computer Science Research
    UC Lawrence Berkeley Laboratory
 9-Mar-84 08:54:57-EST,1723;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 9 Mar 84 08:54:50 EST
Date: Fri 9 Mar 84 08:54:11-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: Kermit/Telnet problem
To: "(Bill Johnston [csam]) johnston"@LBL-CSAM.ARPA, info-kermit@CUCS20
cc: [e-mail], [e-mail]
In-Reply-To: Message from "(Bill Johnston [csam]) johnston@lbl-csam" of Thu 8 Mar 84 19:07:08-EST

Your suggestion about using CR as the default packet terminator in all versions
of Unix Kermit makes sense -- does anyone out there see any reason for not doing
this?

My understanding about TELENET is that you have to use mark parity to make
things work.  The DEC-10, and most other implementations of Kermit, are capable
of sending any desired parity, including mark, if you give the SET PARITY
command.  Unfortunately, Unix Kermit is not one of these, yet.  But the normal
operation of Unix Kermit is to strip the parity bit from any incoming character
before adding it to the accumulated checksum.  If you have SET PARITY MARK (or
anything other than NONE) on the DEC-10, then it should never include the
parity bit value when accumulating the outgoing checksum, so that the result
SHOULD agree with what Unix computes when the packet arrives.

Future releases of Unix Kermit will be a lot stronger in this area.  Meantime,
if you can record what's going on at both ends (I believe KERMIT-10 has a
packet logging facility like KERMIT-20's, and it should be fairly simple to
add a logging feature to Unix Kermit, or interposing a logging process in front
of it) and mail me the results and the commands you used, maybe I can figure
something out.

- Frank
-------
 9-Mar-84 15:12:38-EST,3174;000000000000
Return-Path: <@CUCS20:gts%ucbpopuli.CC@Berkeley>
Received: from CUCS20 by CU20B with DECnet; 9 Mar 84 15:12:20 EST
Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Fri 9 Mar 84 15:11:18-EST
Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.25)
    id AA23120; Fri, 9 Mar 84 11:50:13 pst
Received: from ucbpopuli.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA
    (4.14.noSUID/4.14.3) id AA08830; Fri, 9 Mar 84 11:45:00 pst
Received: by ucbpopuli.CC.Berkeley.ARPA
    (4.14/4.14) id AA24926; Fri, 9 Mar 84 11:42:26 pst
Date: Fri, 9 Mar 84 11:42:26 pst
From: gts%ucbpopuli.CC@Berkeley
Message-Id: <[e-mail]>
To: info-kermit@columbia-20
Subject: Kermit 8th bit

Frank,

It is an excellent point that the checksum checks the data not the transmission
because the user may have been unaware that the eighth bit existed or that it
was not being passed. For this protection, the eighth bit should NOT BE STRIPPED
before computing the sum when parity is set.  So existing kermits are correct in
this sense.

The problem of the eighth bit is important because many users are unaware of it
and because many word processors and some basics use the eighth bit in what
appears to be a simple text file.

Every kermit should have the option to strip the eighth data bit for SENDING.
In this case ONLY should the eighth data bit be stripped before addinng it to
the sum, because the user has now explicitly asked for seven bits.

Whenever a parity other than "none" is set a warning message should be given
that files with the eighth bit set cannot be sent or received.  AND a send
should be aborted if an eighth data bit is seen while parity is set to other
than "none".  If both ends have implemented the eighth bit escape character,
the warning is unnecessary.

Lets examine the eighth data bit and whether it is adequately checked by the
6-bit checksum.  The lower seven bits are always checked.

The 6-bit check is summed as 16 bits but the upper 8 bits of the sum are
discarded before bits 8 and 7 are stripped and added to bits 6-1.  Because the
upper 8 bits of the sum are discarded, any packet with an even number of eighth
data bits has the same 6-bit sum as if those eighth data bits did not exist.
While this gives some protection against single eighth-bit failures, it gives no
protection against stripping of the eighth bit.  A serious side effect is that
files with eighth data bits send ok sometimes and fail sometimes.

Consider strengthening the 6-bit checksum by stripping bits 12-7 and 16-13 and
adding them to bits 6-1.  The eighth data bit becomes as protected as the other
seven.  Older kermits will still work for 7-bit files because the upper bits
will all be zero.

Obviously this weakness of the 6-bit checksum is avoided if all kermits had
the 16-bit sums!

I will implement these suggestions and see how they work out.


Greg Small                [phone]
Microcomputer Communications        [e-mail]
214 Evans Hall CFO            gts%ucbpopuli.CC@Berkeley
University of California        [e-mail]
Berkeley, Ca 94720

 9-Mar-84 15:38:30-EST,546;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 9 Mar 84 15:38:21 EST
Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Fri 9 Mar 84 15:36:23-EST
Received: from RU-BLUE.ARPA by RUTGERS.ARPA with PUP; 9 Mar 84 15:33:07 EST
Date: 9 Mar 84 15:33:24 EST
From: Matthew J Lecin <[e-mail]>
Subject: MACRO-11 Kermit Query
To: [e-mail]
cc: [e-mail]

Is there a version of KERMIT for RT-11?  (I am running RT11 V4.0, soon
to get V5.0).

Thanks,
{Mijjil}
-------
 9-Mar-84 15:55:03-EST,1549;000000000000
Return-Path: <@CUCS20:gts%ucbpopuli.CC@Berkeley>
Received: from CUCS20 by CU20B with DECnet; 9 Mar 84 15:54:43 EST
Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; Fri 9 Mar 84 15:38:28-EST
Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.25)
    id AA23242; Fri, 9 Mar 84 11:57:10 pst
Received: from ucbpopuli.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA
    (4.14.noSUID/4.14.3) id AA08901; Fri, 9 Mar 84 11:52:03 pst
Received: by ucbpopuli.CC.Berkeley.ARPA
    (4.14/4.14) id AA25218; Fri, 9 Mar 84 11:51:13 pst
Date: Fri, 9 Mar 84 11:51:13 pst
From: gts%ucbpopuli.CC@Berkeley
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re:  bug in CPMBASE.M80 v3.6

Yes there is a problem with deafult file-mode.  It should strip trailing
^Z but it does not.  You can use file-mode ascii if you are sending text.
But that too has a problem if your file has imbedded ^Z's.  In file-mode
ascii, a ^Z causes the remainder of the block (128 bytes) to be ignored
BUT the send continues because cp/m did not report EOF for the file.
Of course it is not clear what an imbedded ^Z means in a cp/m file, it is
not very standard!!!  I have also noticed that the PC kermit sends a trailing
^Z and NULL when I send to UNIX.


Greg Small                [phone]
Microcomputer Communications        [e-mail]
214 Evans Hall CFO            gts%ucbpopuli.CC@Berkeley
University of California        [e-mail]
Berkeley, Ca 94720

 9-Mar-84 18:26:52-EST,2611;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 9 Mar 84 18:26:40 EST
Date: Fri 9 Mar 84 16:34:49-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: Kermit 8th bit
To: [e-mail], info-kermit@CUCS20
In-Reply-To: Message from "gts%ucbpopuli.CC@Berkeley" of Fri 9 Mar 84 15:12:08-EST

Greg, You've obviously put a lot of thought into this.  The real question, I
guess, is what to do when sending files when:

a. Some file bytes have the 8th bit set,
b. Parity is being used on the communication line to prevent the 8th bit
   from being set in the byte being sent, AND
c. The two KERMITs in question can't agree to do 8th bit prefixing.

Obviously, the file can't be sent correctly.  But that doesn't mean that the
file shouldn't be sent at all.  Many word processors (and this is exactly what
prompted all this) set the 8th bit of characters in text files to denote some
kind of highlighting, as you point out.  Many users want to be able to send
these files to a foreign system, and are willing to have the special effects
stripped.  We might as well let KERMIT do the stripping -- it's easier than
running the file through a conversion program first, especially when disk space
is tight.  In other words, the user should be able to decide -- if she wants to
send a file this way, we'll assume she knows what she's doing, provided the
sending program prints a warning message to say what's going on.  Then the
user has the option of typing ^X to "abort" the file if she really doesn't want
to send it (most micro Kermits now support this, or will very soon).

I agree that the checksum may not be adequate.  Unfortunately, it's simply too
late to change how it works -- there are thousands of KERMIT programs out
there.  Even if we changed every single one of them at the distribution point,
there would still be thousands of users running the old ones who will never
hear about the change.  Potential problems with the six-bit checksum (and, as
I've said before, I've yet to hear of an ACTUAL problem with it) are what
prompted the type 2 and 3 alternate block check methods, which are in place in
CP/M-80 Kermit.  If we had it to do over again, though, I think we'd do the
single-character checksum the way you suggest.

If we don't strip the 8th bit before computing the checksum when parity is set,
then the receiver will get a different value and reject the packet.  If you're
not sending the 8th bit as data, you CAN'T include it in the checksum because
the receiver will never see it.

- Frank
-------
 9-Mar-84 19:31:21-EST,984;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 9 Mar 84 19:31:18 EST
Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Fri 9 Mar 84 16:53:54-EST
Received: from COLUMBIA-20.ARPA by RUTGERS.ARPA with TCP; 9 Mar 84 16:50:14 EST
Date: Fri 9 Mar 84 16:37:20-EST
From: Frank da Cruz <[e-mail]>
Subject: Re: MACRO-11 Kermit Query
To: [e-mail], [e-mail]
cc: [e-mail]
In-Reply-To: Message from "Matthew J Lecin <[e-mail]>" of Fri 9 Mar 84 15:33:24-EST

Yes, there is a KERMIT for RT-11.  See KER:RT*.* on COLUMBIA-20.  This version
comes from the University of Toronto; it's written in OMSI Pascal, but a
hexified version of the runnable binary file is available so that you can run
it even if you don't have OMSI Pascal.

Brian Nelson, who wrote the Macro-11 Kermit for RSX and RSTS, will have a
version of that program for RT-11 soon as well.

- Frank
-------
11-Mar-84 03:44:03-EST,1528;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 11 Mar 84 03:43:58 EST
Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Sun 11 Mar 84 03:44:33-EST
Received: from SU-SCORE.ARPA by RUTGERS.ARPA with TCP; 11 Mar 84 03:40:50 EST
Date: Sun 11 Mar 84 00:40:06-PST
From: Carl Fussell <[e-mail]>
Subject: Re: MACRO-11 Kermit Query
To: [e-mail]
cc: [e-mail]
In-Reply-To: Message from "Matthew J Lecin <[e-mail]>" of Fri 9 Mar 84 15:33:24-PST
Address:  Santa Clara University


I am running RT V4.0 (will be getting 5.0 next week).  I am running
the RTKERM distribution set (with modifications) and seems to work
ok.   The distribution set was written in OMSI which I don't have so
minor mods had to be done to eliminate those dependencies.  Secondly,
the distribution set used monitor call .TTYIN for virtual terminal
mode.  I replaced this with an assembly driver so that chars like
^S, ^Q, ^O, etc  could be used without being intercepted by RT11.  This
is working.     Adding code for baud rate selection by program control
(for DLV11-E's), line selection (CSR/VEC) , VT100 style display of
SEND/REC data when transfering files, and so on.    This requires
modification of overlay structure and I have been a little short of
time last couple of weeks.   I intend to submit it back to the
distribution list when completed, but if you are interested in any of
this before then, let me know.

-Carl
-------
12-Mar-84 12:33:49-EST,889;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 12 Mar 84 12:33:39 EST
Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Mon 12 Mar 84 12:30:17-EST
Received: from COLUMBIA-20.ARPA by RUTGERS.ARPA with TCP; 12 Mar 84 12:30:51 EST
Date: Mon 12 Mar 84 12:28:47-EST
From: Frank da Cruz <[e-mail]>
Subject: Re: MACRO-11 Kermit Query
To: [e-mail], [e-mail]
cc: [e-mail]
In-Reply-To: Message from "Carl Fussell <[e-mail]>" of Sun 11 Mar 84 03:44:50-EST

Sounds great, but I'd just as soon wait till you're finished.  You might also
want to contact Brian Nelson at the University of Toledo ([e-mail])
about his Macro-11 based RT11 Kermit, which will most likely have all
imaginable bells & whistles, and not require any Pascal at all.  - Frank
-------
12-Mar-84 13:09:11-EST,462;000000000000
Return-Path: <@CUCS20:mike@logicon>
Received: from CUCS20 by CU20B with DECnet; 12 Mar 84 13:09:03 EST
Received: from LOGICON by COLUMBIA-20.ARPA with TCP; Mon 12 Mar 84 13:06:54-EST
Date: 12 Mar 1984 0934-PST
From: mike@LOGICON
Subject: Name Change
To: INFO-KERMIT@COLUMBIA-20
cc: mike

I am on your kermit mailing list, and need a little help.

Please transmit kermit mail to kermit@logicon and NOT mike@logicon.

Thanks....

Mike Parker
-------


12-Mar-84 14:08:35-EST,483;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 12 Mar 84 14:08:17 EST
Received: from USC-ECLC.ARPA by COLUMBIA-20.ARPA with TCP; Mon 12 Mar 84 14:05:18-EST
Date: 12 Mar 1984 11:03-PST
Sender: SMITH@USC-ECLC
Subject: Kermit for DEC Professional?
From:  Dennis R. Smith <[e-mail]>
To: Info-Kermit@COLUMBIA-20
Message-ID: <[USC-ECLC]12-Mar-84 11:03:43.SMITH>

What is the status of a Kermit for the DEC Professional (P/OS)?
12-Mar-84 14:54:44-EST,650;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 12 Mar 84 14:54:36 EST
Date: Mon 12 Mar 84 14:52:02-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: Kermit for DEC Professional?
To: [e-mail], Info-Kermit@CUCS20
In-Reply-To: Message from "Dennis R. Smith <[e-mail]>" of Mon 12 Mar 84 14:03:00-EST

There are two (2) versions of Kermit for the DEC Professional with P/OS, but
we have yet to devise a way of distributing them, because of problems with the
binary help menus and so forth.  A solution is being cooked up, and an
announcement should be made soon.  - Frank
-------
13-Mar-84 13:35:17-EST,707;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 13 Mar 84 13:35:12 EST
Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Tue 13 Mar 84 11:07:23-EST
Received: from RU-GREEN.ARPA by RUTGERS.ARPA with PUP; 13 Mar 84 10:58:35 EST
Date: 13 Mar 84 10:58:46 EST
From: Brian <[e-mail]>
Subject: MS-DOS KERMIT for the DEC Rainbow
To: [e-mail]
cc: [e-mail]
Home: 506 Birch Dr.  Cherry Hill, NJ.  [phone]
Work: RCA Corp.  Moorestown, NJ. [phone]

I am wondering if there is a Kermit available for the DEC Rainbow
running under MS-DOS.   If not - is there anyone working on it?

Brian Sietz
-------
13-Mar-84 13:38:54-EST,619;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 13 Mar 84 13:38:49 EST
Date: Tue 13 Mar 84 11:17:19-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: MS-DOS KERMIT for the DEC Rainbow
To: [e-mail], info-kermit@CUCS20
In-Reply-To: Message from "Brian <[e-mail]>" of Tue 13 Mar 84 10:58:46-EST

As yet, no Kermit for the Rainbow under MS DOS.  There is one written in C
floating around (I don't have it yet) whose status is uncertain.  The IBM PC
implementation will be adapted to run on the Rainbow by us at Columbia in any
case.  - Frank
-------
13-Mar-84 19:17:54-EST,695;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 13 Mar 84 19:17:50 EST
Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; Tue 13 Mar 84 19:15:57-EST
Received: from RU-GREEN.ARPA by RUTGERS.ARPA with PUP; 13 Mar 84 19:15:40 EST
Date: 13 Mar 84 19:16:03 EST
From: [e-mail]
Subject: kermit manuals.
To: [e-mail]


Scribe drops characters from the kermit manuals User.mss.
Even User.lpt is missing characters at the end of some lines.

                                -Gadi
                                 <Friedman@RU-BLUE>
                                 harpo!whuxlb!ru-blue!friedman

-------
14-Mar-84 02:47:05-EST,1522;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 14 Mar 84 02:47:01 EST
Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Wed 14 Mar 84 01:32:41-EST
Date:  Wed, 14 Mar 84 01:32 EST
From:  "John C. Klensin" <[e-mail]>
Subject:  Rainbow CP/M-80 Kermit warning
To:  [e-mail]
Message-ID:  <[e-mail]>

I suspect that this is not worth fixing, but, for the information of
anyone else who might be surprised, the CP/M-80 Kermit for the DEC
Rainbow has the interesting property that, if it is sent a filename that
contains lower case characters, it creates a CP/M file and directory
entry containing lower case characters.  Unfortunately, resident CP/M
commands and most transient ones cannot find things with lower-case
names.

It might be helpful if the "file names" section of the protocol manual
contained an explicit warning that file-receiving implementations on
machines where the file system is single-case but programs can manage to
create dual-case or "other" case names had better be prepared to map to
the appropriate case.  This mapping is not a "normal form" problem, nor
should it be done in the sender.  The sender will, in general, not know
what case(s) the recipient wants; the latter should figure this out for
itself.

Most of the micro Kermit codes seem to have gotten this right; the
Rainbow-80 version is the first with which we have noticed the problem.
14-Mar-84 09:32:06-EST,648;000000000000
Return-Path: <@CUCS20:OC.GARLAND@CU20B>
Received: from CUCS20 by CU20B with DECnet; 14 Mar 84 09:31:57 EST
Received: from CU20B by CUCS20 with DECnet; 14 Mar 84 09:30:49 EST
Date: Wed 14 Mar 84 09:31:04-EST
From: Richard Garland <OC.GARLAND@CU20B>
Subject: Setting the baud rate for Rainbow Kermit
To: BBoard@CU20B
cc: info-kermit@CUCS20

The reason Rainbow kermit doesn't have a SET BAUAD command (or
some such) is because it's so easy to set it from the keyboard using
the set-up function.  I use rainbow kermit all the time and never
considered using a program to set the baud rate.  I just use the set-up
function.            Rg
-------
14-Mar-84 10:20:30-EST,1163;000000000000
Return-Path: <@CUCS20:POLARIS@USC-ISI>
Received: from CUCS20 by CU20B with DECnet; 14 Mar 84 10:20:22 EST
Received: from USC-ISI.ARPA by COLUMBIA-20.ARPA with TCP; Wed 14 Mar 84 10:19:13-EST
Date: 14 Mar 1984 07:17-PST
Sender: POLARIS@USC-ISI
Subject: kermit on ARPANET
From: POLARIS@USC-ISI
To: info-kermit@COLUMBIA-20
Message-ID: <[USC-ISI]14-Mar-84 07:17:53.POLARIS>

I have been using KERMIT over the ARPANET (actually using it to
transfer files from our "local" host (in California) to or site,
here in Virginia) for about a month.  Up until recently thre has
been no difficulty if I set the TAC interupt character to CTRL-D
before logging on.  (I am transfering text files only).  The
local kermits have been several: 86Kermit, PCKermit, and
CPMKermit for the Heath.  Then suddenly I am unable to use the
process--Kermit chokes on the 1st of second packet (usually the
first).  Has the distribution version of Kermit20 changed, has
the net protocol changed?  (or am I just doing something dumb?)
I can still use PCKermit (with Herm Fischer's server code) in
conjunction with my Heath at home.

--HELP

Mike Seyfrit

--and thanks
14-Mar-84 11:01:30-EST,953;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 14 Mar 84 11:01:16 EST
Date: Wed 14 Mar 84 10:59:38-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: Rainbow CP/M-80 Kermit warning
To: [e-mail], Info-Kermit@CUCS20
In-Reply-To: Message from ""John C. Klensin" <[e-mail]>" of Wed 14 Mar 84 01:32:57-EST

We'll check the code.  I thought the problem with CP/M-80 Kermit creating
lower case filenames was fixed a while back, but maybe not.  If not, we'll fix
it.  By the way, we've pretty much "de-committed" supporet for CP/M-80 Kermit
on the Rainbow because (a) CP/M-86 Kermit is available for it, and (b) CP/M-80
Kermit does not work at all on the Rainbow under the new (2.0) release of
DEC's CP/M-86/80.  The CP/M-86 Kermit runs much faster anyway, although a couple
fancy features remain to be added (local DIR, ERA, etc; fancy block checks; ...)

- Frank
-------
14-Mar-84 13:07:40-EST,474;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 14 Mar 84 13:07:20 EST
Date: Wed 14 Mar 84 11:02:52-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: kermit on ARPANET
To: [e-mail], info-kermit@CUCS20
In-Reply-To: Message from "POLARIS@USC-ISI" of Wed 14 Mar 84 10:17:00-EST

A forthcoming release of Kermit-20 attempts to solve all the TAC-related
problems.  Watch this space for announcements.  - Frank
-------
15-Mar-84 15:06:59-EST,471;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 15 Mar 84 15:06:35 EST
Received: from RESTON.ARPA by COLUMBIA-20.ARPA with TCP; Thu 15 Mar 84 15:04:02-EST
Date:  15 March 1984 15:00 est
From:  JFisher.Help at RESTON
Subject:  Kermit for Sanyo MBC1150
To:  info-kermit at COLUMBIA-20

Has anybody had any experience putting kermit up on a Sanyo MBC1150 (cp/m) ?
Should I assume that generic kermit is the one to try ?
15-Mar-84 16:23:22-EST,703;000000000000
Return-Path: <@CUCS20:LEVYAL@USC-ISI>
Received: from CUCS20 by CU20B with DECnet; 15 Mar 84 16:23:08 EST
Received: from USC-ISI.ARPA by COLUMBIA-20.ARPA with TCP; Thu 15 Mar 84 16:20:12-EST
Date: 15 Mar 1984 13:19-PST
Sender: LEVYAL@USC-ISI
Subject: Help on cpm apple kermit
From: LEVYAL@USC-ISI
To: info-kermit@COLUMBIA-20
Message-ID: <[USC-ISI]15-Mar-84 13:19:44.LEVYAL>

I would like to bring up cpm kermit on my apple . Unfortunetely the
system has a SSC card in slot 2. The cpmapple file is to big for me to
bring down to my apple disk to edit for the SSC and slot changes. Any
help would be appreciated. Also is there a kermit on the Tops-20
at ISI and MIT-Multics?
Thanks,
Allan
15-Mar-84 19:49:10-EST,6401;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 15 Mar 84 19:49:01 EST
Received: from SRI-AI.ARPA by COLUMBIA-20.ARPA with TCP; Thu 15 Mar 84 19:47:11-EST
Date: Thu 15 Mar 84 16:48:02-PST
From: William "Chops" Westfield <[e-mail]>
Subject: How lucky we all are.....
To: [e-mail], [e-mail]
cc: [e-mail]

[Henceforth, copys of my MODEM2 program will be sold for $10000. each.
 Since Kermit also talks to IBM mainframes, I suggest you charge 20K..
 (-:  Are you glad you use DEC?  Dont you wish everybody did? :-)  ]

a006 15-Mar-84  06:31
BC-TECHNOLOGY
(Financial Commentary)
By ANDREW POLLACK
c.1984 N.Y. Times News Service
    NEW YORK - One of the newest computer industry buzzwords is
''micro-mainframe link.'' Dozens of companies are falling over
themselves to announce products designed to allow desktop
microcomputers to exchange information with mainframes, large central
corporate computers.
    No one denies that such connections are a major trend. But as with
other industry buzzwords - such as user-friendly, integrated and
compatible - no one knows exactly what a micro-mainframe link means,
and buyers are becoming confused trying to separate the claims of
vendors from reality.
    ''There's a lot more sound and fury than actual buying going on,''
said Robert N. Healy, senior vice president of Software
International, an Andover, Mass., software company that recently
introduced such a link.
    The need for such links is clear. Personal computers are spreading
through corporations, allowing workers to do their own computer
analyses. But much of the data needed by these workers are still in
the corporate mainframe. A budget analyst who needs last year's
expense figures to do a forecast for next year would find those
figures in the mainframe computer. Similarly, a secretary who wants
to use a word processing program to send out dunning letters would
have to draw on the central computer to find the delinquent accounts.
    The solution until now has been to get a printout of the required
information from the central computer and then retype the information
into the personal computer, which is extremely tedious. It seems much
easier to have the data transferred directly from the mainframe to
the microcomputer.
    But such communication is neither easy nor inexpensive.
Microcomputers communicate at slower speeds than mainframes and use a
different language. Hence, a personal computer must be beefed up with
a special circuit board that can cost more than $1,000. In addition
to this hardware, there must be software in the mainframe that allows
it to recognize the requests from the personal computer. Such
programs can cost $25,000 or more. There must also be software for
the personal computer that allows the user to request information and
to transfer it into the spreadsheet or dunning letter. Thus the link
can cost more than the personal computer itself.
    The simplest link is to have the personal computer emulate a
computer terminal, which is the way most computer users interact with
commercial data bases such as Compuserve. But such a connection only
allows the personal computer user to look at the data, not to store
them and manipulate them.
    One step up is the ability to ''download'' data. This allows the
personal computer user to call information from the mainframe and
store it on a disk. The data, however, are in raw form and the user
must figure out himself how to get the data from the disk into the
spreadsheet or dunning letter.
    An improvement on that is to add software to allow the data to be
formatted correctly, so they can go directly from the mainframe into
the proper rows and columns of the spreadsheet or into the proper
spots in the dunning letter. Yet another approach is to have the
microcomputer and the mainframe run the same programs, so that the
personal computer becomes a miniature version of the mainframe, and
translation of data is not as necessary. One of the early examples of
this is the International Business Machines Corp.'s new XT370
computer, a desktop machine that can run software written for IBM's
mainframes.
    Total sales of the hardware and software needed for the links
totaled $222 million in 1983 and will double to $545 million in 1984,
according to International Resource Development, a Norwalk, Conn.,
market research firm. Most major mainframe software companies have
entered the market. Some are teaming up with microcomputer software
companies. Many of the micro-mainframe links developed by software
companies work only with IBM or IBM-compatible personal computers,
and only with software made by the manufacturer of the link. Some
smaller companies are making the communications circuit boards, the
best known being the IRMA board from Digital Communications
Associates of Norcross, Ga.
    But the biggest provider of links is likely to be IBM, since the
company already is the leading producer of computers at both ends of
the link. Late last year, IBM introduced two desktop machines
designed for this link - the XT370 and the 3270 PC, which doubles as
a computer and as a 3270 family terminal.
    ''That's a strategic direction for IBM,'' said Betty Feezor, manager
of personal computer products for Management Science America, a
mainframe software company that was one of the first to provide such
a link. Other hardware vendors need such connections to compete. One
reason Apple Computer Inc. did not succeed with its Lisa computer
last year was that the machine could not be linked to IBM mainframes,
a situation now remedied.
    But such links pose challenges for users as well as vendors.
Security must be preserved, so that people see only the data they are
entitled to see. An even greater hazard: ''uploading,'' in which data
are sent from the personal computer back to the mainframe. Such a
feature would be useful, for instance, to allow department heads to
prepare their individual budgets on spreadsheets, and then send them
to the mainframe to be consolidated into a single budget. But there
must be strict controls to make sure that errors are not introduced
into the central records, fouling up the company's books.


nyt-03-15-84 0927est
-------
16-Mar-84 17:16:31-EST,2579;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 16 Mar 84 17:16:19 EST
Date: Fri 16 Mar 84 17:14:13-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New DEC-20 Kermit
To: Info-Kermit@CUCS20

This is to announce a new release of the KERMIT file transfer program for the
DEC-20, Kermit-20 version 4(207).  There are many new features; here are a few
highlights:

 Server performs some new file management functions beyond file transfer,
  including directory listings, file deletions, changing directory, etc.
  These will not be useful to most users yet, because most of the micro-
  computer Kermits do not yet know how to ask for these services.  Forthcoming
  releases of IBM PC and other Kermits will have this ability.

 Ability to request file management functions of a remote server when dialed
  out over an autodialer.

 Local file deletion and directory listing commands.
. ARPAnet support for use over TACs and TVTs.
. ITS Binary format file support.
. Transaction logging to record the progress of unattended file transfers.
. A variety of error detection methods, including 16-bit CRC.
. Compression of repeated characters for increased throughput.
. Ability to pass 8-bit binary stream data through a 7-bit communication link.
. A macro definition facility for SET commands.
. Initialization and TAKE command files.
. Graceful interruption of file transfers in progress.
. Improved reporting of settings, performance.
. Improved documentation and internal help messages.
. Many bug fixes, and improvements in performance and robustness.

The new Kermit has been thoroughly tested against most other Kermit
implementations, and is available over ARPANET via anonymous FTP from host
COLUMBIA-20 (or over DECNET via NFT from CU20B) as KER:20kermit.*.  It will
also be available soon over BITNET via KERMSRV at host CUVMA.

For a detailed list of changes since the previous release, see the file
KER:20KERMIT.UPD.  See KER:20KERMIT.DOC for detailed documentation of the
DEC-20 Kermit program.  The file KER:20KERMIT.INI is a sample initialization
file.  The file KER:USER.DOC is the new 5th edition of the Kermit User Guide.
The Kermit protocol is explained in the Kermit Protocol Manual, available on
line as KER:PROTO.DOC (edition of 4 Nov 83).

For those who use KERMIT-20 for dialing out, there is also a new release of
the companion program TTLINK, which corrects some bugs.  The files are in
KER:TTLINK.*.

Report any problems with TTLINK or KERMIT-20 directly to me.
-------
16-Mar-84 20:23:37-EST,515;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 16 Mar 84 20:23:33 EST
Received: from SUMEX-AIM.ARPA by COLUMBIA-20.ARPA with TCP; Fri 16 Mar 84 20:22:01-EST
Date: Fri 16 Mar 84 17:21:26-PST
From: Felix Frayman <[e-mail]>
Subject: KERMIT OR MODEM-7 ON RSX O.S.?
To: [e-mail]

  I am looking for KERMIT or MODEM-7 implementations for RSX operating system on
LSI-11/23. Any information is appreciated.
-- Felix Frayman.
-------
17-Mar-84 11:12:53-EST,1062;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 17 Mar 84 11:12:49 EST
Received: from USC-ISID.ARPA by COLUMBIA-20.ARPA with TCP; Sat 17 Mar 84 11:11:24-EST
Date: 17 Mar 1984 08:10-PST
Sender: [e-mail]
Subject: Re: How lucky we all are.....
From: [e-mail]
To: BILLW@SRI-AI
Cc: info-kermit@COLUMBIA-20, info-modemxx@MIT-MC
Cc: protocols@RUTGERS
Message-ID: <[USC-ISID.ARPA]17-Mar-84 08:10:48.ABN.ISCAMS>
In-Reply-To: The message of Thu 15 Mar 84 16:48:02-PST from William "Chops" Westfield <[e-mail]>

Anybody got MDM7xx or KERMIT running on a DisplayWriter?

Better yet, how about ...what is it ... IBM 3270..3720...whatever?
The new Army automated support for installations is called VIABLE, and it
insists on the IBM 3270..or whatever.. protocol.  I have some utilities
lying around somewhere that are supposed to do that, but it sure would be
nice if they were built in to a modem program!

Regards,
David Kirschbaum
Toad Hall
(ABN.ISCAMS@USC-ISID)
19-Mar-84 02:09:40-EST,1105;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 19 Mar 84 02:09:36 EST
Received: from Ucl-Cs by COLUMBIA-20.ARPA with TCP; Mon 19 Mar 84 02:08:03-EST
Received: from ykxa.ac.uk by 44d.Ucl-Cs.AC.UK   via Sercnet with NIFTP;
          19 Mar 84 7:02 GMT
Via:    QZCOM; Date:    Thursday, 15-Mar-84  20:31:34-GMT
Date:        15 Mar 84 13:29 +0100
From:        [e-mail]
Reply-to:    [e-mail]
To:          Info-Kermit <[e-mail]>
Subject:     KERMIT-10 requires parity?
Message-ID:  <46918@QZCOM>


Some of our KERMIT users has had problems with the new version of
KERMIT-10. It seems that it now requires that you first set the parity
(e.g. to "space") before it works. Parity "none" (the default) doesn't
work. Excuse me if these are trivial questions, but is this a bug or a
feature? Maybe it would be better to have another default parity? Or
isn't the parity "none" mode unforgiving enough?

    - Per Lindberg QZ -



20-Mar-84 17:50:53-EST,1771;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 20 Mar 84 17:50:36 EST
Received: from Ucl-Cs by COLUMBIA-20.ARPA with TCP; Tue 20 Mar 84 17:48:00-EST
Received: from ykxa.ac.uk by 44d.Ucl-Cs.AC.UK   via Sercnet with NIFTP;
          20 Mar 84 22:00 GMT
Via:    UCL-CS; Date:    Tuesday, 20-Mar-84  10:33:39-GMT
Received: from columbia-20.arpa by 44d.Ucl-Cs.AC.UK   via Satnet with SMTP;
          19 Mar 84 15:19 GMT
Received: from CU20B by CUCS20 with DECnet; 19 Mar 84 10:20:12 EST
Date: Mon 19 Mar 84 10:20:44-EST
From: Nick Bush <OC.BUSH@cu20b>
Subject: Re: KERMIT-10 requires parity?
To: Per_Lindberg_QZ <[e-mail]>
cc: info-kermit <[e-mail]>
In-Reply-To: Message from "[e-mail]" of Thu 15 Mar 84 13:29:00-EST
Sender: "OC.BUSH" <[e-mail]>

KERMIT-10 does not normally require a SET PARITY SPACE to work.  The only
time the SET PARITY command should be necessary is if there really is
some parity in use on the communications line.  SET PARITY NONE assumes
that the communications line is a full eight bit path, and that any characters
which are not part of the data portion of a packet will have the parity bit
clear.  If this is not the case, then a SET PARITY command is needed to
tell KERMIT-10 that it should strip the parity bit from every character
it receives, and to generate parity on every character it sends.  I
suspect that either your communications medium is using parity, or else
the "other" KERMIT is generating parity bits on the characters it is
transmitting.

- Nick Bush
-------

21-Mar-84 11:19:59-EST,2092;000000000000
Return-Path: <@CUCS20:OC.GARLAND@CU20B>
Received: from CUCS20 by CU20B with DECnet; 21 Mar 84 11:19:53 EST
Received: from CU20B by CUCS20 with DECnet; 21 Mar 84 11:18:13 EST
Date: Wed 21 Mar 84 11:19:00-EST
From: Richard Garland <OC.GARLAND@CU20B>
Subject: Plea to developers
To: [e-mail]
cc: OC.GARLAND@CU20B

I have a plea to all developers of Kermit to include machine identification
in kermit prompts and messages.

Yesterday I was debugging a dialout program on VAX/VMS while logged onto
the VAX from a Rainbow via Kermit.  I used the dialer program to dialout
to Telenet and thence to a DEC-20 to see if Kermit would work over this
route (from the VAX to the 20).  The dialer program could do session
logging as could the Rainbow-kermit.  I hit "control-(something) L" and
got the message "[Logging started]".  By what?  I forgot what escape
character I hit.  Was I confused.


Suggestion:

> All Micro-kermits should preface their kermit version name infront of
  all messages that can interrupt terminal emulation.  Thus -

[Logging started]        ==>    [Kermit-86: Logging started]
[Connected to remote host]    ==>    [Kermit-86: connected ...]
[Back at micro]            ==>    [Kermit-86: Back at micro]

> All mainframe Kermits should put their node name (DECnet, Arpanet, Usenet,
  whatever-you-got-net etc.] infront of all prompts and messages.  Thus -

Kermit-32>            ==>    CUCHEM::Kermit-32>
Kermit-20>            ==>    Columbia-20::Kermit-20>
[Logging started]        ==>    [CUCHEM::Kermit-32: Logging started]

etc., etc.

Most mainframes can give this information dynamically to a program running
via a logical name, environment variable etc.  For example on VAX/VMS there
is a logical name "SYS$NODE" accesible to a program.

This would be an easy thing to do in most Kermits and would certainly be
a welcome feature in this day and age when we can easily be logged in on
3 or 4 machines on top of one another.  Please don't consider this idea
a joke - I really was confused and things will only get more complicated.

                    Rg
-------
22-Mar-84 04:40:56-EST,1218;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 22 Mar 84 04:40:53 EST
Received: from Ucl-Cs by COLUMBIA-20.ARPA with TCP; Thu 22 Mar 84 04:38:14-EST
Received: from ykxa.ac.uk by 44d.Ucl-Cs.AC.UK   via Sercnet with NIFTP;
          22 Mar 84 9:30 GMT
Via:    QZCOM; Date:    Thursday, 22-Mar-84  04:54:17-GMT
Date:        22 Mar 84 02:25 +0100
From:        [e-mail]
Reply-to:    [e-mail],
             [e-mail],
             [e-mail]
To:          Info-Kermit <[e-mail]>,
             [e-mail],
             [e-mail]
Subject:     KERMIT-10 requires parity?
Message-ID:  <47871@QZCOM>
In-Reply-To: <46918@QZCOM>

I wonder if not some of these problems can be traced back to losing
terminal network eqt, which destroy the parity bit. This makess it
necessary to set the parity to something in order to make KERMIT
use a 7-bit byte size. I have at least had that problem in the past.

22-Mar-84 11:37:30-EST,956;000000000000
Return-Path: <@CUCS20:Iglesias@uci-750a>
Received: from CUCS20 by CU20B with DECnet; 22 Mar 84 11:37:18 EST
Received: from UCI-750a by COLUMBIA-20.ARPA with TCP; Thu 22 Mar 84 11:34:20-EST
Date: 22 Mar 84 08:36:25 PST (Thu)
To: info-kermit@Columbia-20
cc: iglesias@Uci-750a
Subject: PRIME Kermit
From: Mike Iglesias <iglesias@uci-750a>

A group on campus has tried to bring up the PRIME Kermit and is having
a problem.  They built it according to the directions in PRIMEK.HLP.
When they run it, they get

   ERROR: CONDITION "POINTER FAULT" RAISED AT 4001(3)/567.

The person who did the building has never used PL/I (or whatever PRIME
calls it), so he has no idea how to go about debugging this.  I know
nothing about Primes.  Has anybody else made Kermit work on a
Prime?  Any Prime experts out there who can tell us how to go about
figuring out what is wrong?  Thanks for any info.

Mike Iglesias
University of California, Irvine
22-Mar-84 14:42:47-EST,1268;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 22 Mar 84 14:42:37 EST
Received: from RESTON.ARPA by COLUMBIA-20.ARPA with TCP; Thu 22 Mar 84 14:38:24-EST
Date:  22 March 1984 14:38 est
From:  JFisher.Help at RESTON
Subject:  Re: Prime Kermit error
To:  info-kermit at COLUMBIA-20

the Error: condition "condition" raised at "address" msg cited says that
the pointer_fault$ condition was raised in segment number 4001 , word 567
in ring 3 (the user ring, I think). So you first have to find out what
seg 4001 is, and what happens near word 567. Presumably a compliation
listing will tell the latter. The general explanation of the
pointer_fault$ condition is:

    "The process has referenced through an indirect pointer (IP)
    whose fault bit is on, but that pointer did not appear to be a valid
    unsnapped dynamic link. That is, reference has been made to an
    argument or instruction not in memory. This error condition is
    frequently caused by an incomplete load (unsatisfied references), or
    by making a subroutine or function call with too few arguments.
    The condition is raised when the called subroutine attempts to
    access one of its arguments through a faulted pointer."
23-Mar-84 17:14:25-EST,886;000000000000
Return-Path: <@CUCS20:Iglesias@uci-750a>
Received: from CUCS20 by CU20B with DECnet; 23 Mar 84 17:14:21 EST
Received: from UCI-750a by COLUMBIA-20.ARPA with TCP; Fri 23 Mar 84 17:11:37-EST
Date: 23 Mar 84 14:10:25 PST (Fri)
To: info-kermit@Columbia-20
cc: iglesias@Uci-750a, grich@Uci-750a
Subject: Kermit suggestion
From: Mike Iglesias <iglesias@uci-750a>

One feature I would like to see in Kermit (especially the IBM PC Kermit)
is the ability to drop DTR on the serial line.  We have a Develcon
Dataswitch that all of our systems are connected to and to use
Kermit on a PC and move from system to system requires pulling the
connector out of the PC or the wall to tell the Dataswitch that you
want to request another machine.  This would also be handy if one is
using Kermit on a PC at home and you want your modem to drop the line
so you can dial another system.
24-Mar-84 16:03:54-EST,2344;000000000000
Return-Path: <@CUCS20:KLING%UCI-20b@UCI-750a>
Received: from CUCS20 by CU20B with DECnet; 24 Mar 84 16:03:41 EST
Received: from UCI-750a (not validated) by COLUMBIA-20.ARPA; Sat 24 Mar 84 16:01:50-EST
Date: 24 Mar 1984 1249-PST
From: Rob-Kling <Kling%UCI-20B@UCI-750a>
Subject: PC-Talk III and Kermit
To: schutz%UCI-20B@UCI-750a
cc: info-kermit@COLUMBIA-20, fdc@COLUMBIA-20, EASTERLIN%UCI-20B@UCI-750a,
    king%UCI-20B@UCI-750a, rittenHOUSE%UCI-20B@UCI-750a,
    iacono%UCI-20B@UCI-750a, info-ibmpc@USC-ISIB
Received: from UCI-20b by UCI-750a; 24 Mar 84 12:53:37 PST (Sat)
Munged: from uci-750a; 24 Mar 84 13:04:06 PST (Sat)

I've spent some time w/PC-Talk III and find that it has some
real advantages over Kermit in managing the transaction and some real
disadvantages in acting as a terminal emulator.


PC-Talk will store phone numbers and redial automatically.
You can change alot of parameters (including the login drive) during
a session with an Alt-key. You can read files on the PC and
manage PC directories. All the time while logged onto a DEC20,
actively.
(in Kermit, one has to move "back" to Kermit 86, exit,
fiddle with DOS, rerun Kermit, retype "set baud 1200" (why no memory?),
issue a connect command, and then be back in 20 land.


On the other hand, PC-Talk emulates a dumb terminal (Terminal mode TI will do),
rather than a VT52. Also, it displays a help-line in high intensity
at the bottom of the screen (which I find to be a nuisance). A version of
Kermit with PC-talk's session management or a version of PC-Talk which
emulates a VT100 or VT52 and toggles the help-bar on line 25 would be
really useful.

At the moment, Kermit works as a better terminal emulator, and I prefer
it over PC-talk despite PC-Talk's real advantages. If I were
composing  alot of text  on my PC and shipping them to a
larger machine for processing, I might prefer PC-Talk.
(PC-talk seems to communicate more slowly than Kermit, but I have
not tried to benchmark the two carefully.)

Since the terminal emulation is important to me, Kermit is the
more useful. I wish that a next release of PC-Kermit
included the phone-directory and session managing capabilities of
PC-Talk.

PC-Talk comes with the source code.
(from FREEWARE - P.O. Box 862, Tiburon, CA 94920 )


Rob Kling
UC-Irvine
25-Mar-84 04:38:43-EST,1073;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 25 Mar 84 04:38:38 EST
Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; Sun 25 Mar 84 04:36:57-EST
Date:  Sun, 25 Mar 84 04:33 EST
From:  Paul Schauble <[e-mail]>
Subject:  8 bit graphic characters in kermit
To:  [e-mail]
Message-ID:  <[e-mail]>

I am using the IBM PC version of kermit as a terminal emulator to talk
to other PC based systems. Some of these run with the comm port set to 8
data bit, no parity, and send 8 bit data, expecting it to be displayed
as the upper 128 characters, the graphic characters. The present version
of kermit running with "set parity none" strips off the 8th bit.

Is it possible to set up the present version to run this way?

Do you know of a patch or source change to make it run that way? Save me
the problems of digging it out.

Also, I suggest that the next version support this mode through setup
parameters.

          Paul
26-Mar-84 11:11:37-EST,1017;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 26 Mar 84 11:11:21 EST
Date: Mon 26 Mar 84 11:08:07-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: PC-Talk III and Kermit
To: [e-mail], [e-mail], Info-Kermit@CUCS20
In-Reply-To: Message from "Rob-Kling <Kling%UCI-20B@UCI-750a>" of Sat 24 Mar 84 20:13:00-EST

I agree that most microcomputer implementations of Kermit are weak in the area
of session control.  As you point out, the idea is to have a package that works
over a wide variety of machines (many of which may not have PF or ALT keys) in
a relatively consistent way, but on the other hand the desired control should
be provided when feasible.  I expect the next release of PC Kermit will make you
happier -- it'll leave the baud rate the way you left it last time, and it will
have external command files, a toggle-able status line, scrollback of the
terminal session, and many other improvements.  - Frank
-------
27-Mar-84 12:58:47-EST,779;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 27 Mar 84 12:58:39 EST
Received: from SANDIA.ARPA by COLUMBIA-20.ARPA with TCP; 27 Mar 84 12:55:55 EST
Date: Tue 27 Mar 84 10:53:34-MST
From: Tom Linnerooth <[e-mail]>
Subject: Apollo support
To: [e-mail]

We at Sandia Labs are just starting to look at KERMIT as a method
of linking engineering work stations to the DEC-20.  One of the
workstations we have is based on the Apollo computer running the
AEGIS operating system.  Can anyone tell me if any work has been
done to provide KERMIT support for that system?  Thanks.

Please reply directly to me since I am presently not on this list.

    Tom Linnerooth (LINNEROOTH@SANDIA)
-------
28-Mar-84 15:34:14-EST,953;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 28 Mar 84 15:34:01 EST
Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; 28 Mar 84 14:58:44 EST
Date:  Wed, 28 Mar 84 14:46 EST
From:  "John C. Klensin" <[e-mail]>
Subject:  Osborne kermit
To:  [e-mail]
Message-ID:  <[e-mail]>

It appears that this routine does not
  (a) Understand about the modem port and the internal (slide-in) modem
and how to use it.
  (b) Understand enough to be able to work the dialer arrangements of
that modem.
  (c) Understand how to generate a BREAK with either the RS232 port or
the modem port.

  Is anyone thinking about doing anything about these problems, or
should we try making a plan about them?  Note that (b) is likely to be
quite annoying, since the modem has little intelligence and has to be
pulsed by the computer.
28-Mar-84 17:13:42-EST,1483;000000000000
Return-Path: <@CUCS20:jalbers@BNL>
Received: from CUCS20 by CU20B with DECnet; 28 Mar 84 17:13:28 EST
Received: from BNL by COLUMBIA-20.ARPA with TCP; 28 Mar 84 17:09:37 EST
Date: 28-Mar-84 17:07:40-EST
From: jalbers@BNL
Subject: OSKERM
To: info-kermit@COLUMBIA-20
Cc: Klensin@MIT-MULTICS


John,
     Chuck Bacon, who devloped OSKERM, never intended to have it work for the
 Ozzie's modem port, nor for the COMM-PAC modem.
 I think that it would be, though, an easy fix.  (No, I'm not going to do it)
 All that must be done it change the port address.  I will, if someone REALLY
 wants to do the mods, supply the address change.

 On a break and the Osborne 1.  The Ozzie's RS232 is not fully implimented,
thus it can't genetate a break at all (Due to the supreme and holy knowledge
of OCC)!!!  The modem port can, though.  Don't count on dialing the COMM-PAC,
though, because it is done through a combination of an escape sequencs and
making one pin go high.

 If you really want a good communications program, and don't need the KERMIT
protocols, use OTERM405, which is public domain and at SIMTEL20.  It does
allow the use of the modem port, although it does not dial the COMM-PAC
(you have to do it by hand)..

                                               Jon Albers
                                               jalbers@bnl

(P.S.  Any Ozzie owners who would like to get on a digest for Osborne 1 and
Osborne Exec owners, send me a note)

28-Mar-84 21:44:30-EST,794;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 28 Mar 84 18:59:58 EST
Date: Wed 28 Mar 84 18:56:34-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: Osborne kermit
To: [e-mail], Info-Kermit@CUCS20
In-Reply-To: Message from ""John C. Klensin" <[e-mail]>" of Wed 28 Mar 84 14:59:10-EST

To my knowledge, no one has announced any intention to fix the Osborne
problems that you mention.  Osborne Kermit users all over the world would
thank you if you could fix them.  However, first please wait a week or two
for the announcement of CP/M-80 Kermit version 3.9, which contains many fixes
and enhancements, so that your Osborne fixes won't have to be painfully
retrofitted.  Thanks for the offer!  - Frank
-------
29-Mar-84 12:32:47-EST,567;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 29 Mar 84 12:32:36 EST
Received: from SU-SIERRA.ARPA by COLUMBIA-20.ARPA with TCP; 29 Mar 84 12:30:30 EST
Date: Thu 29 Mar 84 09:30:06-PST
From: Gert Slavenburg <[e-mail]>
Subject: add me
To: [e-mail]

  Hi,

Can You add me to the mailing list of kermit.
Since I'm rather new here (just arrived from Europe), is there someone
who can tell me if there exists a kermit running under Apple/UCSD ??
  Gert Slavenburg
-------
30-Mar-84 15:11:57-EST,1518;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 30 Mar 84 15:11:05 EST
Date: Fri 30 Mar 84 15:06:19-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New version of CP/M-86 KERMIT
To: Info-Kermit@CUCS20

There's another new release of CP/M-86 Kermit for the DEC Rainbow 100/100+
and NEC APC.  This is version 2.6 (yes, we skipped 2.5); the work was done by
Ron Blanford at the University of Washington and Rich Garland at Columbia.
The changes are:

 LOG command added for session logging, unguarded file capture.
. Improved interrupt handling
. Improved filename processing; valid special characters are now allowed.
. Improved error messages.
. Files are no longer skipped because of attribute bits.
. Terminal emulation moved to a separate module.
. Other code shuffled around for better modularization.
. SET FILE-WARNING changed to SET WARNING.
. Bug that left junk at end of file is fixed.

And if you failed get version 2.4, note that that one fixed parity processing
and IBM communication, added a local packet timeout facility, and added
XON/XOFF flow control, allowing smooth scroll and hold-screen to work.

The new version is available via anonymous FTP from COLUMBIA-20 (ARPANET) or
NFT from CU20B (DECnet) and will soon be accessible via KERMSRV at CUVMA
(BITNET).  The files are KER:86*.* (sources & documentation), KER:RB*.*
(Rainbow binaries and documentation), and KER:APC*.* (NEC APC binaries and
documentation).

- Frank
-------
30-Mar-84 21:15:23-EST,1035;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 30 Mar 84 21:15:18 EST
Date: Fri 30 Mar 84 21:13:59-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New Edition of Protocol Manual
To: Info-Kermit@CUCS20

The fifth edition of the KERMIT Protocol Manual is available via anonymous
FTP from COLUMBIA-20 (ARPANET), NFT from CU20B (DECNET), and (soon) via
KERMSRV from CUVMA (BITNET).  It incorporates a few new (minor) ideas,
changes a few details in the Attribute packet description (these have never
been implemented anywhere, so that shouldn't cause too much grief), includes
a much more complete state table, and clarifies many of the points that so
many of you requested clarification on.  It's in KER:PROTO.*.  PROTO.MSS
is the Scribe source file, PROTO.DOC is suitable for printing or reading on
the terminal, PROTO.LPT is suitable for printing on a printer, and PROTO.FOR
is for printing on systems that need FORTRAN-style carriage control.  Comments
welcome.  - Frank
-------
30-Mar-84 21:58:34-EST,1176;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 30 Mar 84 21:58:31 EST
Received: from csnet-relay by COLUMBIA-20.ARPA with TCP; 30 Mar 84 21:54:08 EST
Received: by csnet-relay via xusc-cse;  30 Mar 84 21:40 EST
Date: Thu Mar 29 1984 20:32:19
From: Marco Papa <[e-mail]>
To: [e-mail]
Subject: UNIX Kermit with line locking
Cc: [e-mail]
Reply-to: [e-mail]


Peter Vanderbilt of USC has modified Unix Kermit to support locking on the
use of the outgoing line for Berkeley 4.x UNIX.  The change consists of only
8 lines of code.

1.) add one line for conditional compilation (see LOCK_LINE):

#if UCB4X
#define V6_LIBS        0        /* Dont't use retrofit libraries */
#define NO_FIONREAD 0        /* We have ioctl(FIONREAD,...) for flushinput() */
#define NO_TANDEM   0        /* We have TANDEM line discipline (xon/xoff) */
#define LOCK_LINE   1       /* Lock the line when in local mode */
#endif


2) Add the code between #if LOCK_LINE ... #endif LOCK_LINE inside the "main"
program:

30-Mar-84 22:36:41-EST,1176;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 30 Mar 84 22:36:36 EST
Received: from csnet-relay by COLUMBIA-20.ARPA with TCP; 30 Mar 84 21:54:08 EST
Received: by csnet-relay via xusc-cse;  30 Mar 84 21:40 EST
Date: Thu Mar 29 1984 20:32:19
From: Marco Papa <[e-mail]>
To: [e-mail]
Subject: UNIX Kermit with line locking
Cc: [e-mail]
Reply-to: [e-mail]


Peter Vanderbilt of USC has modified Unix Kermit to support locking on the
use of the outgoing line for Berkeley 4.x UNIX.  The change consists of only
8 lines of code.

1.) add one line for conditional compilation (see LOCK_LINE):

#if UCB4X
#define V6_LIBS        0        /* Dont't use retrofit libraries */
#define NO_FIONREAD 0        /* We have ioctl(FIONREAD,...) for flushinput() */
#define NO_TANDEM   0        /* We have TANDEM line discipline (xon/xoff) */
#define LOCK_LINE   1       /* Lock the line when in local mode */
#endif


2) Add the code between #if LOCK_LINE ... #endif LOCK_LINE inside the "main"
program:

31-Mar-84 00:42:34-EST,398;000000000000
Return-Path: <@CUCS20:iglesias@uci-750a>
Received: from CUCS20 by CU20B with DECnet; 31 Mar 84 00:42:31 EST
Received: from UCI-750a by COLUMBIA-20.ARPA with TCP; 31 Mar 84 00:41:36 EST
Date: 30 Mar 84 21:43:01 PST (Fri)
To: info-kermit@Columbia-20
cc: iglesias@UCI-750a
Subject: USER.LPT
From: Mike Iglesias <iglesias@uci-750a>

What happened to KER:USER.LPT?  Is it no longer available?
31-Mar-84 20:38:47-EST,1565;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 31 Mar 84 20:38:37 EST
Received: from csnet-relay by COLUMBIA-20.ARPA with TCP; 31 Mar 84 20:37:01 EST
Received: by csnet-relay via xusc-cse;  31 Mar 84 20:25 EST
Date: Sat Mar 31 1984 11:29:01
From: Marco Papa <[e-mail]>
To: [e-mail]
Subject: UNIX Kermit with line locking (2nd message)
Cc: [e-mail]
Reply-to: [e-mail]


I guess one of the mailers lost the second part of the message.  I you haven't
got it, this is the rest of Peter Vanderbilt's patch for line locking
with UNIX Kermit.

2) Add the code between #if LOCK_LINE ... #endif LOCK_LINE inside "main".

    if (ttyname)            /* If LINE was specified, we */
    {                    /* operate in local mode */
    ttyfd = open(ttyname,2);    /* Open the tty line */
    if (ttyfd < 0)
    {
        printmsg("Cannot open %s",ttyname);
        exit(1);
    }
#if LOCK_LINE                /* Set exclusive-use mode on line */
    if (ioctl(ttyfd,TIOCEXCL,0) != 0)
    {
        printmsg("Cannot lock %s", ttyname);
        exit(1);
    }
#endif LOCK_LINE
    remote = FALSE;            /* Indicate we're in local mode */
    }
    else                /* No LINE specified so we operate */
    {                    /* in remote mode (ie. controlling */
    ttyfd = 0;            /* tty is the communications line) */
    remote = TRUE;
    }

That's all!

Marco Papa
USC CS Dept.

ARPA, CSNET: papa.usc-cse@csnet-relay
UUCP: !randvax!uscvax!papa






 1-Apr-84 04:58:27-EST,1057;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 1 Apr 84 04:58:22 EST
Received: from rice.ARPA by COLUMBIA-20.ARPA with TCP; 1 Apr 84 04:57:14 EST
Received: from tethys by rice.ARPA (AA03682); Sun, 1 Apr 84 03:53:54 CST
Received: by tethys (AA07105); Sun, 1 Apr 84 03:51:26 cst
Date: Sun, 1 Apr 84 03:51:26 cst
From: Stan Barber <[e-mail]>
Message-Id: <8404010951.AA07105@tethys>
To: [e-mail], [e-mail]
Subject: Re:  New version of CP/M-86 KERMIT

This is really in reference to KERMIT-TRS80.
Someone from Columbia called (713) 6609252 to download the
binaray for KERMIT-TRS80 directly. Unfortunately, the BBS
was not ready for this. It is now. Please pass the word to
those there that are interested. The source is on-line at
Rice, but needs the line numbers stripped out. Busy doing
research project at the moment. I will try to get them
ready soon.
Regards, Stan Barber
sob@rice
lbl-csam!rice!sob
Department of Psychology
Rice University
Houston,Tx 77251
 2-Apr-84 17:04:50-EST,780;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 2 Apr 84 17:04:45 EST
Date: Mon 2 Apr 84 17:03:59-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Use of anonymous FTP
To: Info-Kermit@CUCS20
cc: Cower@CUCS20

Due to the great demand for KERMIT and the large size of the "Kermit
collection" at COLUMBIA-20, anonymous FTP accesses to the KERMIT distribution
area have been having a noticable impact on the responsiveness of this
system.  The administrators of COLUMBIA-20 have asked me to request that
anonymous access to the KERMIT area be restricted to hours outside of 6:00 AM
to 6:00PM, weekdays, Eastern time.  Your cooperation will be much appreciated,
particularly by the users of this system.  Thank you.  - Frank
-------
 2-Apr-84 19:58:02-EST,806;000000000000
Return-Path: <@CUCS20:grich@uci-750a>
Received: from CUCS20 by CU20B with DECnet; 2 Apr 84 19:57:55 EST
Received: from UCI-750a by COLUMBIA-20.ARPA with TCP; 2 Apr 84 19:56:27 EST
Date: 02 Apr 84 16:57:33 PST (Mon)
To: info-kermit@Columbia-20
Subject: Anyone running RSTS/E Kermit under V7.1?
From: John Mangrich <grich@uci-750a>

 I got the K11NRS.HEX (etc) file and converted it to a task as per instructions
on our V 7.1 RSTS/E system. When I try to run it, connect works ok but file
commands get something like "ER$WCD WILDCARD ENCOUNTERED DURING FNA/DNA
STRING PARSE" message.  I am not a proficient MACRO/RMS programmer, so I'm
slow in deciphering the source to find out what I might do, so is anyone out
there in a position to suggest what is going on?

  John Mangrich
  UC Irvine
 4-Apr-84 12:39:52-EST,1175;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 4 Apr 84 12:39:46 EST
Received: from csnet-relay by COLUMBIA-20.ARPA with TCP; 30 Mar 84 21:54:08 EST
Received: by csnet-relay via xusc-cse;  30 Mar 84 21:40 EST
Date: Thu Mar 29 1984 20:32:19
From: Marco Papa <[e-mail]>
To: [e-mail]
Subject: UNIX Kermit with line locking
Cc: [e-mail]
Reply-to: [e-mail]


Peter Vanderbilt of USC has modified Unix Kermit to support locking on the
use of the outgoing line for Berkeley 4.x UNIX.  The change consists of only
8 lines of code.

1.) add one line for conditional compilation (see LOCK_LINE):

#if UCB4X
#define V6_LIBS        0        /* Dont't use retrofit libraries */
#define NO_FIONREAD 0        /* We have ioctl(FIONREAD,...) for flushinput() */
#define NO_TANDEM   0        /* We have TANDEM line discipline (xon/xoff) */
#define LOCK_LINE   1       /* Lock the line when in local mode */
#endif


2) Add the code between #if LOCK_LINE ... #endif LOCK_LINE inside the "main"
program:

 4-Apr-84 17:11:57-EST,1036;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 4 Apr 84 17:11:47 EST
Received: from RESTON.ARPA by COLUMBIA-20.ARPA with TCP; 4 Apr 84 17:10:12 EST
Date:  4 April 1984 17:07 est
From:  JFisher.Help at RESTON
Subject:  SuperBrain kermit
To:  info-kermit at COLUMBIA-20
cc:  KLaurent.Help at RESTON

We have recently been experimenting with kermit on the Intertec SuperBrain,
transferring files to/from our local Multics.
We find that with V3.2 of SB kermit, all is as it should be, files go in
both directions and appear at the destination as they were at the origin.
However, with the new V3.6 , things are not quite right. Files sent from the
SB to Multics are fine, as above, but files arriving from Multics on the SB
have the literal string 'MJ' embedded in them in place of the CRLF sequence
sent by Multics. In all cases, the SB is configur-ed with 8-bit character
length, 2 stop bits and no parity.
So, what might we be doing wrong, or not doing that we should be ?
 4-Apr-84 19:23:07-EST,1217;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 4 Apr 84 19:23:00 EST
Received: from csnet-relay by COLUMBIA-20.ARPA with TCP; 4 Apr 84 17:46:05 EST
Received: by csnet-relay via xhp-labs;  4 Apr 84 17:38 EST
Date: Wed, 4 Apr 84 10:25:25 pst
From: Ken Poulton <[e-mail]>
Received: by HP-VENUS id AA26476; Wed, 4 Apr 84 10:25:25 pst
Message-Id: <8404041825.AA26476@HP-VENUS>
To: [e-mail], [e-mail]
Subject: XON handshaking
Source-Info:  From (or Sender) name not authenticated.

We all know that IBM 370's have some i/o peculiarities that
must be specially handled (usually by 'set ibm').
What is not well known is that the HP 3000 shares one of those
peculiarities: it needs to use the XON handshake to communicate
reliably (sigh).

Most kermits seem to allow XON handshaking, but only
bundled together with duplex and parity settings for IBM machines.
The 3000 doesn't want these other settings.

Therefore, I would like to request all kermit implementors to include
XON hanshaking as a separate 'set' option - when you get around to it,
of course.

Thanks!
Ken Poulton
 4-Apr-84 19:38:33-EST,1015;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 4 Apr 84 19:38:29 EST
Date: Wed 4 Apr 84 17:52:15-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: SuperBrain kermit
To: [e-mail]
cc: Info-Kermit@CUCS20
In-Reply-To: Message from "JFisher.Help at RESTON" of Wed 4 Apr 84 17:07:00-EST

That is truly bizarre!  We have a Superbrain here, as well as other CP/M-80
systems, which we use in conjunction with various mainframes (but no Multics
systems) and have never seen such a thing!  The problem is either (a) SB Kermit
recognizes the prefix sequence #M#J (the normal representation of CRLF), strips
out the prefix characters (#), but forgets to controllify the M and J, or (b)
Multics Kermit is sending M and J without the prefix.  (b) could possibly be
explained by something different happening in the Send-Init exchange.  I'd have
to see actual logs of the packets in order to fix the blame better than that.
Strange!  - Frank
-------
 4-Apr-84 19:52:03-EST,747;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 4 Apr 84 19:51:58 EST
Date: Wed 4 Apr 84 17:58:37-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: XON handshaking
To: [e-mail]
cc: Info-Kermit@CUCS20
In-Reply-To: Message from "Ken Poulton <[e-mail]>" of Wed 4 Apr 84 17:46:01-EST

I think you're right; the protocol manual says it this way too.  The new
DEC-20 Kermit unbundles handshake and all the other stuff, and now defines
"IBM" as a macro composed of the appropriate SET commands, rather than as a
hardwired combination of parity, duplicity, and line access.  Also, the
handshake character itself should be SETtable.  - Frank
-------
 4-Apr-84 23:20:51-EST,691;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 4 Apr 84 23:20:41 EST
Received: from USC-ECL.ARPA by COLUMBIA-20.ARPA with TCP; 4 Apr 84 18:02:02 EST
Date: Wed 4 Apr 84 15:02:21-PST
From: [e-mail]
Subject: Fix for Apple-DOS KERMIT
To: [e-mail]

    Does anyone know what modifications have to be made to the Apple DOS
KERMIT to support the Apple 'Super Serial' card instead of the Apple 'Commun-
ications' card?  The current version displays a continuous stream of characters
after the CONNect command.  Or are we simply missing something in the way we
are setting up the Apple KERMIT?
    Jim Neeland
-------
 5-Apr-84 01:01:10-EST,4887;000000000000
Return-Path: <@CUCS20:OC.TREI@CU20B>
Received: from CUCS20 by CU20B with DECnet; 5 Apr 84 01:00:55 EST
Received: from CU20B by CUCS20 with DECnet; 5 Apr 84 00:59:51 EST
Date: Thu 5 Apr 84 00:59:16-EST
From: Peter G. Trei <OC.Trei@CU20B>
Subject: Re: Fix for Apple-DOS Kermit...
To: info-kermit@CUCS20

    I here repost two letters relating to using Kermit under
Apple-DOS with the Super-Serial Card.
 The address specific stuff applies only to the unmodified
'official' version currently distributed.

                        Peter Trei
                        oc.trei%cu20b@columbia-20

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


People trying to use Kermit-65 (Apple DOS Kermit) Version 1.1 with a
Super Serial Card have been running into problems. Here is how to make
it work.

1. Before you start up Kermit, send the SSC the following string: ^AZ
(thats Control-A, followed by Z).  This will disable the SSC's command
recognition. The SSC usually looks for ^A in the terminal input, and
strips it out. It then looks at the next character, and if it is a
valid SSC command, strips it out as well and performs the command.
Trouble arises from the fact that Kermit uses ^A to announce the start
of each packet. Typing ^AZ disables the SSC from seeing further ^A
commands. If you really need to have access to the SSC commands again
before you turn off the Apple, type ^A^W instead, which will change
the command prefix to ^W, which should not appear during Kermit file
transfer.

    There is a bug in the code to support the Super Serial Card,
which must be fixed before it will work at all. If you look in the
source code for Kermit-65 (APPLEK.M65 in <KERMIT>, and search for the
label TL2CP:, two lines further down you will see a line which reads:

AND    #$04

At this point, Kermit is ANDing a status register with a bitmask. If
the result is non-zero, a character has been received from the modem.
the problem is that 04 is the wrong mask; it should be 08, according
to page 54 of the SSC manual.

    To fix this, you can either alter the source, recompile, and
upload the new version, or much more quickly you can patch the binary
version you already have. Here's how to do the patch from Applesoft:

]BLOAD APPLEK.BIN
   (or whatever you are calling your copy).

]POKE 8665,8
   (thats a decimal address)

]BSAVE NEWKER,A$800,L$4900

Thats all. The new version contains the patch. With this, file transfer
using the Super Serial Card has been done at 1200 baud.

[This bug has been fixed in all the copies I hand out now. ]


3.    Those of you who use 1200 baud modems will have noticed that
you loose characters at the beginning of each line when the screen is
scrolling.  This is not Kermits fault, but rather the slowness of the
software used to scroll the screen image in the Apples memory.
According to the SSC manual, you can eliminate this by slightly
narrowing the scroll window. The following poke does it:

]POKE 35,22

This will make line 22 the bottom of your scroll window, which is
enough.

I would be interested in hearing from anyone on the list who is using
Kermit-65.

                    Peter Trei,
                    [e-mail]





Here is Richard garland's method for using the Videx and the
super-serial card.

Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 27 Jan 84 21:07:10 EST
Date: Fri 27 Jan 84 21:06:45-EST
From: Richard Garland <G.GARLAND@CUCS20>
Subject: Apple with SSC & Videx 80 col. card
To: info-kermit@CUCS20

Using Peter Trei's suggestions (in yesterday's Info-Kermit) we now
have Apple Kermit working nicely with the SSC (Super Serial Card).

We have no problem connecting to and doing file transfers with a VAX
running VMS and Steven's VMS Kermit at 1200 baud.

Mark Paczkowski here has worked out how to get the Videx 80 column card
working under Kermit with the SSC.  The Videx must go in slot 3.
Assume the SSC is in slot 1.  The following sequence gets the whole
thing going:

1) Boot the Apple

2) Type "IN#1"            <== this wakes up the SSC

3) Type "<CTRL>A3S"        <== chain SSC to Videx 80 col. card

4) Type "<CTRL>AZ"        <== turn off SSC's interception of ^A's

5) Type "PR#3"            <== turn on Videx 80 col card

6) Type "BLOAD KERMIT"        <== load kermit (patched as per Peter Trei)

7) Type "CALL 7855"        <== Start up Kermit


Then you are off and running.  The 80 col card has faster screen
handling and so Peter Trei's suggestion about reducing the scrolling
region to 22 lines is unnecessary.  The BLOAD is needed rather than the usual
BRUN so that the chaining stuff you set up in the previous steps won't
get reset.  During the above sequence you will get various prompts from
the system and from the cards.  The screen will do various wierd things
but in the end it will all be ok.

[Now back to my Rainbow ...]

                    Rg
-------
 5-Apr-84 09:37:54-EST,611;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 5 Apr 84 09:37:46 EST
Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; 5 Apr 84 09:37:00 EST
Received: from RU-BLUE.ARPA by RUTGERS.ARPA with PUP; 5 Apr 84 09:36:55 EST
Date: 5 Apr 84  06:15 EST (Thu)
From: Mijjil (Matthew J Lecin) <LECIN@RU-BLUE>
To:   Kermit@Rutgers
Phase-Of-The-Moon: NM+4D.17H.40M.24S.
Reply-to: Lecin@Ru-Blue
Subject: Apple-Dos Kermit

currently DOES support the Apple Com Card, The DC Hayes Micromodem
and the Super Serial Card.

Check out the SET DEVICE command...

{Mijjil}
 5-Apr-84 11:40:37-EST,1632;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 5 Apr 84 11:40:12 EST
Received: from RESTON.ARPA by COLUMBIA-20.ARPA with TCP; 5 Apr 84 11:38:15 EST
Date:  5 April 1984 11:34 est
From:  JFisher.Help at RESTON
Subject:  SuperBrain kermit
To:  info-kermit at COLUMBIA-20
cc:  KLaurent.Help at RESTON

Frank: Following your comments to my previous inquiry re SuperBrain kermit
V3.2 vs. V3.6 , I created a small test file on Multics. It contained two lines:

This is the first line.
This is the second (last) line.

and was called TEST. Neither V3.2 nor V3.6 supports logging (?) but Multics
does. So I enabled logging on Multics, and sent TEST to the SB. The V3.2
log looked like this:

09:59 T 
) S~4 @-#!
09:59 R 
) Y~% @-#X

09:59 T 
'!FTEST1
10:04 R 
#!Y?

10:04 T 
a"DThis is the first line.#M#JThis is the second (last) line.#M#JA
10:05 R 
#"Y@

10:05 T 
##ZB
10:08 R 
##YA

10:08 T 
#$B+
10:08 R 
#$YB

Then I sent TEST to the SB using V3.6 , and the log looked like this:

12:36 T 
) S~4 @-#!
12:36 R 
+ Y~% @-#N1W

12:36 T 
'!FTEST1
12:43 R 
#!Y?

12:43 T 
a"DThis is the first line.MJThis is the second (last) line.MJ,
12:44 R 
#"Y@

12:44 T 
##ZB
12:47 R 
##YA

12:47 T 
#$B+
12:47 R 
#$YB

I have not as yet gone to the protocol manual to see what's going on, but
obviously the first packet from the SB is different in the two versions, and
it apparently caused Multics to eliminate the prefix character. So, is
SB V3.6 doing the 'right thing' and Multics kermit screwing up, or is
V3.6 defective ?
 5-Apr-84 18:23:02-EST,2025;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 5 Apr 84 18:22:44 EST
Date: Thu 5 Apr 84 17:16:24-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: Re: SuperBrain kermit
To: [e-mail], info-kermit@CUCS20
cc: [e-mail]
In-Reply-To: Message from "JFisher.Help at RESTON" of Thu 5 Apr 84 11:34:00-EST

The problem with Multics KERMIT seeming to send files containing MJ rather
CRLF appears to be due to an incorrect assumption on the part of the MULTICS
Kermit author, namely that the Send-Init packet should go through the
prefix encoding/decoding mechanism.  The rules about this were not stated
explicitly in the protocol manual at the time he wrote the program (they are
now).  MULTICS Kermit sees "#N" in the Send-Init packet and "decodes" that
to be Control-N, which it then proceeds to use as the control quote in outgoing
packets, when the SuperBrain, of course, is looking for "#" as the control
quote.  The reason this started happening with 3.6 of Kermit-80 is that the
earlier version had no Send-Init fields after the control quote; since MULTICS
Kermit ate the control quote, it found nothing in that field and therefore
defaulted to the correct value.  The fix is to obey the protocol manual and
NOT send the Send-Init (S or I packet) or the ACK to an S or I packet through
the prefix encoding/decoding mechanism.

Also, note that there was another mistake: the contents of the control-prefix
field of the Send-Init denote the character that "I" will be sending to "you",
NOT the character "I" want "you" to send to "me".

I'll call the author and tell him about this.  Meanwhile, anyone with a MULTICS
system is more than welcome to attempt a fix along these lines.  If you
volunteer for this, you should also install the fixes from Wolf Wiedemann
at RADC-MULTICS, which you can find in the file KER:MUKERMIT.BWR.

Thanks to Bill Catchings for figuring out the problem with MJ...  - Frank
-------
 5-Apr-84 19:07:24-EST,1727;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 5 Apr 84 19:07:16 EST
Date: Tue 3 Apr 84 17:41:55-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: KERMIT on the PCjr
To: Info-Kermit@CUCS20, [e-mail]

Well, it took three weeks, but IBM finally came through with a serial
communication port cable for the PCjr (it's a short 16-pin to 25-pin
adpater).  We plugged it in to the serial port and gave KERMIT a whirl.
It worked, sort of.  Details:  IBM PC KERMIT v 1.20 (the current release)
was used.  The serial port corresponds to COM2 on the PC or XT, so you
have to SET PORT 2.  We ran at 4800 baud and signed on to a DEC-20, emulating
a Heath-19.  When typing files or running EMACS, a few characters are lost
here and there, but the terminal emulation is usable.  File transfer worked
just fine, though we only tested it with a few relatively short text files.
One problem is that the KERMIT program assumes the screen is 80 columns wide,
and the Peanut is 40 by default, so the display during file transfer is
out of whack (but the files are still transferred OK).  If you happen to have
a monitor that supports it, you can do MODE 80 to get 80-character lines,
and then the display during file transfer works just like on the PC, XT, or
Portable PC.

We'll fix KERMIT to run more naturally on the Peanut, by taking note of the
current width, and doing whatever buffering or flow control may be necessary
to prevent loss of characters during file transfer, etc.  But even in its
current state, it seems to be perfectly usable.  Meanwhile, work on the next
release continues; there should be an announcement within a few weeks.

- Frank
-------
 5-Apr-84 20:08:28-EST,1727;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 5 Apr 84 20:08:21 EST
Date: Tue 3 Apr 84 17:41:55-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: KERMIT on the PCjr
To: Info-Kermit@CUCS20, [e-mail]

Well, it took three weeks, but IBM finally came through with a serial
communication port cable for the PCjr (it's a short 16-pin to 25-pin
adpater).  We plugged it in to the serial port and gave KERMIT a whirl.
It worked, sort of.  Details:  IBM PC KERMIT v 1.20 (the current release)
was used.  The serial port corresponds to COM2 on the PC or XT, so you
have to SET PORT 2.  We ran at 4800 baud and signed on to a DEC-20, emulating
a Heath-19.  When typing files or running EMACS, a few characters are lost
here and there, but the terminal emulation is usable.  File transfer worked
just fine, though we only tested it with a few relatively short text files.
One problem is that the KERMIT program assumes the screen is 80 columns wide,
and the Peanut is 40 by default, so the display during file transfer is
out of whack (but the files are still transferred OK).  If you happen to have
a monitor that supports it, you can do MODE 80 to get 80-character lines,
and then the display during file transfer works just like on the PC, XT, or
Portable PC.

We'll fix KERMIT to run more naturally on the Peanut, by taking note of the
current width, and doing whatever buffering or flow control may be necessary
to prevent loss of characters during file transfer, etc.  But even in its
current state, it seems to be perfectly usable.  Meanwhile, work on the next
release continues; there should be an announcement within a few weeks.

- Frank
-------
 5-Apr-84 21:13:57-EST,884;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 5 Apr 84 21:13:52 EST
Received: from csnet-relay by COLUMBIA-20.ARPA with TCP; 3 Apr 84 17:47:46 EST
Received: by csnet-relay via xhp-labs;  3 Apr 84 17:30 EST
Date: Tue, 3 Apr 84 10:58:28 pst
From: Ken Poulton <[e-mail]>
Received: by HP-VENUS id AA08839; Tue, 3 Apr 84 10:58:28 pst
Message-Id: <8404031858.AA08839@HP-VENUS>
To: [e-mail]
Subject: Unix line locking
Source-Info:  From (or Sender) name not authenticated.

Has anyone added uucp-compatable lock files to the Unix Kermit?
Line locking works for Berkeley Unix, but other systems rely on
the existence of lock files in /usr/spool/uucp to mediate
access to outgoing lines.  Stealing code from uucp or cu
is apparently not kosher - it's covered by Bell's license agreement.
 6-Apr-84 15:37:33-EST,835;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 6 Apr 84 15:37:28 EST
Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; 6 Apr 84 13:20:17 EST
Received: from RU-BLUE.ARPA by RUTGERS.ARPA with PUP; 6 Apr 84 13:20:52 EST
Date: 6 Apr 84 13:20:34 EST
From: [e-mail]
Subject: Apple kermit.
To: [e-mail]


I was using Apple kermit-65 at 9600 baud (with a direct line).
It seemed to be working fine, no errors, but the file turned out
to be missing characters.  Shouldn't kermit have given an error
message or something ?.  I know 9600 baud is too fast, but with
no error messages I thought it might have worked.

                                              -Gadi
                                               <Friedman@Ru-Blue>

-------
 9-Apr-84 09:56:58-EST,521;000000000000
Return-Path: <@CUCS20:GEOFFM@SRI-CSL>
Received: from CUCS20 by CU20B with DECnet; 9 Apr 84 09:56:20 EST
Received: from SRI-CSL by COLUMBIA-20.ARPA with TCP; 9 Apr 84 09:54:22 EST
Date: 9 Apr 1984 06:49-PST
Sender: GEOFFM@SRI-CSL
Subject: Kermit running under Tenex
From: Geoffrey C. Mulligan (AFDSC, The Pentagon) <GEOFFM@SRI-CSL>
Reply-To: geoffm@SRI-CSL
To: info-kermit@COLUMBIA-20
Message-ID: <[SRI-CSL] 9-Apr-84 06:49:34.GEOFFM>

Does anyone have a version of Kermit running under Tenex?

        geoff
 9-Apr-84 10:57:29-EST,664;000000000000
Return-Path: <@CUCS20:OC.BUSH@CU20B>
Received: from CUCS20 by CU20B with DECnet; 9 Apr 84 10:57:23 EST
Received: from CU20B by CUCS20 with DECnet; 9 Apr 84 10:55:59 EST
Date: Mon 9 Apr 84 10:40:10-EST
From: Nick Bush <OC.BUSH@CU20B>
Subject: VAX/VMS Kermit problem
To: [e-mail]
cc: INFO-KERMIT@CUCS20

There was a problem with one of the MACRO-32 sources produced by BLISS-32 that
caused errors when running Kermit with debug turned on.  This can
be easily fixed in the MACRO source by looking for the line "U.28:" and
moving it down past the .PSECT statement, so it is just before the
.ENTRY DBG_MESSAGE,...

- Nick
-------
13-Apr-84 13:39:24-EST,624;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 13 Apr 84 13:39:14 EST
Date: Thu 12 Apr 84 22:44:48-EST
From: Nick Bush <G.BUSH@CUCS20>
Subject: Apple Kermit
To: INFO-KERMIT@CUCS20

Has anyone succeeded in getting Apple Kermit (Kermit-65) to run
on an Apple IIe?  We have heard conflicting stories (nothing
very specific) concerning whether Kermit-65 works on IIe's.
Anyone who has tried (either successfully, or unsuccessfully) to
get Kermit-65 running on a IIe, please let me know.  If you did get
it to work, was there anything special you needed to do?

- Nick
-------
13-Apr-84 14:10:57-EST,605;000000000000
Return-Path: <@CUCS20:OC.GARLAND@CU20B>
Received: from CUCS20 by CU20B with DECnet; 13 Apr 84 14:10:49 EST
Received: from CU20B by CUCS20 with DECnet; 13 Apr 84 14:03:55 EST
Date: Fri 13 Apr 84 14:02:16-EST
From: Richard Garland <OC.GARLAND%CU20B%CU20B@COLUMBIA-20>
Subject: Re: Apple Kermit
To: G.BUSH@CUCS20
cc: INFO-KERMIT@CUCS20, OC.GARLAND%CU20B%CU20B@COLUMBIA-20
In-Reply-To: Message from "Nick Bush <G.BUSH@CUCS20>" of Fri 13 Apr 84 13:39:29-EST

We have it going on a IIe with SSC.  I'll check further if there were
any problems.  It was a group in our Physics dept.
                    Rg
-------
16-Apr-84 10:00:51-EST,536;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 16 Apr 84 10:00:40 EST
Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; 16 Apr 84 09:58:20 EST
Received: from RU-BLUE.ARPA by RUTGERS.ARPA with PUP; 16 Apr 84 09:58:13 EST
Date: 16 Apr 84 09:58:48 EST
From:   Alexander B. Latzko <[e-mail]>
Subject: apple 65
To: [e-mail]
cc: [e-mail]


does indeed work on the apple //e.

details if requested.
alex
<latkzo.ru-blue.arpa>

-------
16-Apr-84 10:41:17-EST,992;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 16 Apr 84 10:40:55 EST
Received: from Xerox.ARPA by COLUMBIA-20.ARPA with TCP; 16 Apr 84 10:36:55 EST
Received: from Chardonnay.ms by ArpaGateway.ms ; 16 APR 84 07:36:49 PST
Date: 16 Apr 84 07:25:47 PST
From: [e-mail]
Subject: Re-distribution list for INFO-KERMIT@COLUMBIA-20
To: [e-mail]
Cc: [e-mail]

    I have created the re-distribution list Kermit-Info^.pa with
[e-mail] as the Owner, and having the following initial
members:

Ciccarelli.PA, Clark.Wbst, Conrad.Pasa, Ford.PA, JonL.PA, Malasky.PA,
Porcar.PA, Preas.PA, Veizades.PA.

    Would you please add the name Kermit-Info^[e-mail] as a member of
INFO-KERMIT@COLUMBIA-20 and remove the following names from your
memebership list:

Ciccarelli.PA, Clark.Wbst, Conrad.Pasa, Ford.PA, JonL.PA, Malasky.PA,
Porcar.PA, Preas.PA, Veizades.PA.

        Thanks!  Ron...


16-Apr-84 21:28:27-EST,1046;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 16 Apr 84 21:28:12 EST
Received: from USC-ECLB.ARPA by COLUMBIA-20.ARPA with TCP; 16 Apr 84 21:26:43 EST
Date: Mon 16 Apr 84 18:26:41-PST
From: [e-mail]
Subject: Prime Kermit Installation
To: [e-mail]



When getting Prime kermit from Columbia-20 using ftp make sure that
the file does not contain any tabs.  (Pip on a 10 or 20 can do this.)

Here is a prime emacs macro to split primek.plp into the individual files:


; by Jack Heath
; modified by Robert A. Larson 4/16/84
(defcom splitk
  (do_n_times (numeric_argument 1)
    (next_line_command)
    (forward_char 2)
    (setq start (copy_cursor current_cursor))
    (end_line)
    (back_char 2)
    (setq file (point_cursor_to_string start))
    (begin_line)
    (mark)
    (forward_search_command "::::")
    (begin_line)
    (prepend_to_file 2 file)
))



Perhaps these suggestions could be added to primek.hlp

Bob Larson
-------
17-Apr-84 08:02:42-EST,1419;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 17 Apr 84 08:02:37 EST
Received: from csnet-relay by COLUMBIA-20.ARPA with TCP; 17 Apr 84 08:01:31 EST
Received: From usc-cse.csnet by csnet-relay;  17 Apr 84 7:51 EST
Date: Mon Apr 16 1984 15:39:33
From: Marco Papa <[e-mail]>
To: [e-mail]
Subject: Great Kermit Hoax
Cc: [e-mail]


This is an excerpt from an article by Michael N. Huttner in the latest issue
of PC WEEK, entitled "Barnum Would Enjoy Hucksterism in Ads; Buyers Beware":

"... More than likely, it was one of Barnum's cunning descendants who
engineered the legendary "Great Kermit Hoax," by successfully contriving to
fleece Uncle Sam himself for a hefty sum before fading safely away into the
sunset.
    According to our version of the story, our bright friend recently
contracted with an agency of the federal government to develop a personal
computer-to-mainframe communications software package.  It seems the fellow
simply borrowed a working copy of a program called KERMIT from a library
collection of free, public-domain personal computer software.  After making
some very cosmetic modifications, he then neatly proceeded to duplicate and
deliver the package as promised--and collected $ 495 per copy.
    A very smooth job indeed...."


17-Apr-84 12:48:33-EST,826;000000000000
Return-Path: <@CUCS20:INSTIT-STUDIES.WJBALDWIN@CUTC20>
Received: from CUCS20 by CU20B with DECnet; 17 Apr 84 12:47:57 EST
Received: from CUTC20 by CUCS20 with DECnet; 17 Apr 84 08:33:20 EST
Date: Tue 17 Apr 84 08:32:21-EST
From: Bill Balldwin <INSTIT-STUDIES.WJBALDWIN@CUTC20>
Subject: Re: Apple Kermit
To: G.BUSH@CUCS20, INFO-KERMIT@CUCS20
cc: INSTIT-STUDIES.WJBALDWIN@CUTC20
In-Reply-To: Message from "Nick Bush <G.BUSH@CUCS20>" of Fri 13 Apr 84 13:39:36-EST


Have tried; haven't succeeded.  Problem appears to involve the Apple IIe
configuration -- what communications board, which slot, what modem....
I can't get Kermit-65 to "wake-up" the modem.

The kermit-65 contact person, so I'm told, is OC.TREI@B at Columbia.

Let me know if you solve the riddle.  I'll do the same.

-Bill Baldwin
-------
18-Apr-84 01:11:47-EST,603;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 18 Apr 84 01:11:43 EST
Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; 18 Apr 84 01:10:20 EST
Received: from UChicago.Mailnet by MIT-MULTICS.ARPA with Mailnet id <[e-mail]>; 18 Apr 1984 00:52:14 est
Date: Tue 17 Apr 84 18:22:29-CST
From: Stuart Schmukler <[e-mail]>
Subject: CROSS BIN files
To: [e-mail]
cc: [e-mail]

Does anyone know how to generate CROSS 8-bit .BIN files?

SaS
-------
18-Apr-84 03:14:18-EST,620;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 18 Apr 84 03:14:13 EST
Received: from SU-SCORE.ARPA by COLUMBIA-20.ARPA with TCP; 18 Apr 84 03:12:57 EST
Date: Wed 18 Apr 84 00:09:44-PST
From: Carl Fussell <[e-mail]>
Subject: hp kermit
To: [e-mail]
Address:  Santa Clara University



Is anybody working on a version of kermit for the HP 3000  (I didn't
see anything in the current list of kermits)?   If so, would it be
possible to find out the present state of its development.   Thanx
for any information...

carl
-------
21-Apr-84 13:40:11-EST,969;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 21 Apr 84 13:40:05 EST
Received: from csnet-relay by COLUMBIA-20.ARPA with TCP; 21 Apr 84 13:12:50 EST
Received: From hp-labs.csnet by csnet-relay;  21 Apr 84 2:54 EST
Received: by HP-VENUS id AA25606; Wed, 18 Apr 84 09:54:02 pst
Date: Wed, 18 Apr 84 09:40:26 pst
From: Wayne F. Chin <[e-mail]>
Received: by HP-MERCURY id AA06133; Wed, 18 Apr 84 09:40:26 pst
Message-Id: <8404181740.AA06133@HP-MERCURY>
To: [e-mail],
    [e-mail]
Subject: Re:  hp kermit
Cc: [e-mail]
Source-Info:  From (or Sender) name not authenticated.

Yes, there's a version of Kermit for the HP 3000.  Try contacting Ken Poulton
@ HP Labs [phone].  Any other questions, call me at HP Labs [phone].
Good luck,
  Wayne Chin (chin.hp-labs@rand-relay)

23-Apr-84 07:09:07-EST,604;000000000000
Return-Path: <@CUCS20:EXT1.SAMANI@CU20B>
Received: from CUCS20 by CU20B with DECnet; 23 Apr 84 07:09:01 EST
Received: from CU20B by CUCS20 with DECnet; 23 Apr 84 07:07:36 EST
Date: Mon 23 Apr 84 07:07:52-EST
From: SamaniFluidsnAsscts 2028ParsonsNYC113573436 2129398595 <EXT1.SAMANI@CU20B>
Subject: Ward-Christiansen Protocol
To: info-kermit@CUCS20

Can use MODEM on CU20B:: for xmit to my micro, but not back to CU20B::.
 So I try line dump, but CU20B:: dies with long files....
Any suggestions?
Do you know of other MODEM locations with better support (accessible by MM)?
tnx/vjp2
-------
24-Apr-84 22:22:47-EST,1117;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 24 Apr 84 22:22:28 EST
Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; 24 Apr 84 22:20:20 EST
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <[e-mail]>; 24 Apr 1984 22:09:37 est
Date:        20 Apr 84 19:31 +0200
From:        Ingemar_Joelsson_Ume}[e-mail]
Reply-to:    Ingemar_Joelsson_Ume}[e-mail],
 [e-mail]
To:
 [e-mail],
             info-kermit@COLUMBIA-20, "Alexander B. Latzko"
              <[e-mail]>
cc:          "Alexander B. Latzko" <[e-mail]>
Subject:     apple 65
Message-ID:  <52495@QZCOM>
In-Reply-To: <52400@QZCOM>

Thanks! Yes I would like to receive all possible info regarding using
KERMIT on my Apple 2 E. Please write to me here in QZ-Com or use
my address: POBox 414, S-90108 Ume}, Sweden.
Regards, Ingemar Joelsson



25-Apr-84 08:53:05-EST,838;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 25 Apr 84 08:52:57 EST
Received: from ut-ngp.ARPA by COLUMBIA-20.ARPA with TCP; 25 Apr 84 08:51:35 EST
Date: Wed, 25 Apr 84 07:52:39 cst
From: [e-mail]
Posted-Date: Wed, 25 Apr 84 07:52:39 cst
Message-Id: <[e-mail]>
Received: by ut-ngp.ARPA (4.22/4.22)
    id AA27990; Wed, 25 Apr 84 07:52:39 cst
To: info-kermit@columbia-20
Subject: Break on an Apple running kermit???

Is there a way to generate a break on an Apple running kermit or anyway
to generate one at all?  Our MICOM port contention system won't let
you disconnect without sending a break.  Any and all help would be
much appreciated.

Jim Knutson
ARPA: knutson@ut-ngp
UUCP: {ihnp4,seismo,kpno,ctvax}!ut-sally!ut-ngp!knutson
25-Apr-84 13:24:58-EST,437;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 25 Apr 84 13:24:40 EST
Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; 25 Apr 84 13:22:16 EST
Date: 25 Apr 84 13:21:05 EST
From: [e-mail]
Subject: Apple Kermit under ProDOS
To: [e-mail]


Has anyone started working on KERMIT-65 for use under ProDOS.

Keith Sproul
[e-mail]
-------
25-Apr-84 14:47:14-EST,1365;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 25 Apr 84 14:46:38 EST
Received: from FORD-WDL1.ARPA by COLUMBIA-20.ARPA with TCP; 25 Apr 84 14:42:27 EST
Return-Path:<>
Date: 25-Apr-84 11:42:09-PST
From: [e-mail]
Subject: Breaks
To: [e-mail]

Breaks should be pretty easy to make, if you don't mind kludges.
A break is 0Volts for around 250msec.  That is longer than the
longest valid character, which is about 10 bits at 50 Baud (200msec).
Longer breaks should be just fine.

Anyway, you can make breaks by grounding your Transmit Data line for
1/4 second.  If you use a cheap switch, the contact bounce could send
garbage characters.  If you want to be really cool, you could use a
555 one-shot chip.

Transmit Data should be Pin 2 on your terminal or computer, or pin 3
on your modem.

I haven't tried this, but it really ought to work.  If someone tries it,
I'd like to know how it goes.

Good luck,
w underwood

PS:  I've never seen a standard for the Break signal.  If there is such
a thing, I'd like to know about it.


    WUNDERWOOD(tm)  BREAK-O-THING

------- TxD
   |
   |
    /        This is supposed to be a switch.
   /
   |
   |
   5K        RS-232 lines should have a load between 3K and 7K.
   |
   |
 Ground        Signal ground, actually.  Pin 7.
26-Apr-84 10:55:05-EST,801;000000000000
Return-Path: <@CUCS20:Z00.R-GERBER@NYU20>
Received: from CUCS20 by CU20B with DECnet; 26 Apr 84 10:54:54 EST
Received: from NYU20 by CUCS20 with DECnet; 26 Apr 84 10:52:59 EST
Date: Thu 26 Apr 84 10:51:58-EST
From: Robert M Gerber <Z00.R-Gerber@NYU20>
Subject: Re: Breaks
To: info-kermit@CUCS20
Reply-To: Z00.R-Gerber%NYU20@Columbia-20
In-Reply-To: Message from "[e-mail]" of Wed 25 Apr 84 14:42:09-EST

The 'standard' break for use to interrupt something that is running is four
characters in length at 300 baud and above.  This works with IBM mainframes
very well.  A break that is two long can cause the modems to hang up (this
is called a 'long' break).  A long break is about 400 msec long.  As Wunder
suggested 250 msec should work just fine.

-----Robert
-------
27-Apr-84 08:25:31-EST,1206;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 27 Apr 84 08:25:25 EST
Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; 27 Apr 84 08:23:45 EST
Received: from UChicago.Mailnet by MIT-MULTICS.ARPA with Mailnet id <[e-mail]>; 27 Apr 1984 08:16:11 est
Date: Thu 26 Apr 84 14:59:51-CST
From: Stuart Schmukler <[e-mail]>
Subject: [Don Goldhamer <[e-mail]>: KERMIT Ascii-Ebcdic translation]
To: [e-mail]
cc: [e-mail]

Date: Thu 26 Apr 84 14:24:19-CST
From: Don Goldhamer <[e-mail]>
Subject: KERMIT Ascii-Ebcdic translation
To: [e-mail]
cc: [e-mail]

There is one code which is mis-translated in the KERMIT Ascii to
Ebcdic translation on the IBM3081.

At present the tilde (Ascii code HEX 7E) is translated into an
equal-sign (Ebcdic code HEX 7E).  The correct translation should be
in to a tilde (sometimes displayed as a degree-sign) (Ebcdic code
HEX A1).

Could you correct the KERMIT translate table and documentation.

Thanks
  Don Goldhamer

-------
27-Apr-84 10:30:58-EST,4062;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 27 Apr 84 10:30:40 EST
Date: Fri 27 Apr 84 10:24:45-EST
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New release of KERMIT for CP/M-80
To: Info-Kermit@CUCS20
cc: [e-mail], [e-mail]

This is to announce a new release of CP/M-80 KERMIT, version 3.9.  This is not
the long-awaited "modularized" version, but a maintenance release of the
current monolithic version that fixes many bugs and addresses various
shortcomings in the previous release, which was version 3.6.  Here is a brief
list of the changes since version 3.6:

* Fixes & improvements contributed by Greg Small, UC Berkeley, including:
  . A "fuzzy" timer -- imprecise timeouts
  . Some VT52 emulation bugs fixed
  . Bugs with file attribute bits fixed
  . TRS-80 support for both Lifeboat & Pickles & Trout CP/M
  . Morrow Decision I support
  . Separate terminal support for TVI925, ADM3A, "generic CRT" on some systems
  . Buffer boundary checking for recovering from long bursts of noise

* From Kimmo Laaksonen, Helsinki University of Technology Computing Centre:
  . Support for Nokia MikroMikko (a Finnish CP/M system)
  . Filename completion on ESC, a`la TENEX/TOPS-20
  . TRANSMIT command, for uploading a file "bare" (no protocol), with XON/XOFF
  . Miscellaneous fixes & cosmetic improvements

* Contributions from Bernie Eiben, DEC Marlboro, including:
  . Integration of Greg's and Kimmo's changes with working source
  . SET PRINTER ON/OFF during CONNECT (no fancy buffering or waiting)
  . ^C during file transfer returns immediately to command level
  . Source file compaction, removal of update history to separate file
  . Rainbow-100 support removed; use CP/M-86 Kermit from now on.

* From Columbia:
  . 8th-bit prefixing for transferring binary files when parity is in effect
  . Fixed and/or improved communication with IBM mainframes
  . Kaypro II and other display fixes
  . Added code for DECmate-II to transmit BREAK signal
  . SET TIMER ON/OFF, off by default, goes on/off automatically with SET IBM
  . Default file mode as distributed is now ASCII
  . Misc bug fixes

HEX files have been built for all the systems supported by this program.
Here is a list of them:

CPMAPPLE    Apple II, Z80 softcard
CPMBRAIN    Intertec SuperBrain
CPMDMII        DECmate II, Z80 card
CPMGENERI    Generic CP/M-80 2.2
CPMHEATH    Heath/Zenith-89
CPMKAYPRO    Kaypro II
CPMMDI        Morrow Decision I
CPMMIKKO    Nokia MikroMikko
CPMOSBORN    Osborne 1 (serial port only)
CPMOSI        Ohio Scientific
CPMPLUS        Generiac CP/M-80 3.0
CPMROBIN    DEC VT180 "Robin"
CPMTRLB        TRS-80 Model II, Lifeboat CP/M-80
CPMTRPT        TRS-80 Model II, Pickles & Trout CP/M-80
CPMTELCON    Telcon Zorba
CPMVECTOR    Vector Graphics
CPMZ100        Heath/Zenith Z100, CP/M-80 (8085 side)

These files are all stored with the suffix ".HEX" in the area "KER:", for
instance KER:CPMDMII.HEX, in normal ASCII format.  The hex files for the
previous release are still available with suffix ".OHX".  There is also a new
Kermit User Guide chapter for this program, KER:CPMKERMIT.MSS and .DOC.  The
entire group of CP/M-80 Kermit files can be referred to as KER:CPM*.*.  Network
users may obtain KERMIT files from host CU20B via NFT (CCNET), or host
COLUMBIA-20 via anonymous FTP (only after 6:00pm on weekdays, ARPANET).  The
hex files may be downloaded to your micro using your old version of KERMIT (or
MODEM7, or any other downloading procedure) and then converted to runnable .COM
format with the LOAD command.  Your old KERMIT.COM should be renamed to
something like OLDKERM.COM for backup and the new one can then be renamed to
KERMIT.COM.

Since this new release is the result of the work of many people at many sites
on many different machines, there can be no guarantee that it works on all the
systems listed above.  It has been tested thoroughly on the DEC VT-180, the
Kaypro II, and the Intertec Superbrain.  I'd appreciate reports about the other
systems.

-------
29-Apr-84 14:02:04-EDT,454;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 29 Apr 84 14:02:00 EDT
Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; 29 Apr 84 14:01:27 EDT
Date: 29 Apr 84 14:00:10 EDT
From: Eric <[e-mail]>
Subject: C64 Kermit ??
To: [e-mail]
cc: [e-mail]


 Where is it? Is anyone really working on it? ...

Still waiting,
Eric (LAVITSKY@RUTGERS)
-------
30-Apr-84 19:58:01-EDT,730;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 30 Apr 84 19:57:54 EDT
Received: from csnet-relay by COLUMBIA-20.ARPA with TCP; 30 Apr 84 19:57:03 EDT
Received: From hp-labs.csnet by csnet-relay;  30 Apr 84 19:48 EDT
Date: Mon, 30 Apr 84 13:10:39 pdt
From: Ken Poulton <[e-mail]>
Received: by HP-VENUS id AA09249; Mon, 30 Apr 84 13:10:39 pdt
Message-Id: <8404302010.AA09249@HP-VENUS>
To: [e-mail]
Subject: Who has RSX Kermit?
Source-Info:  From (or Sender) name not authenticated.

I remember reading here that someone took the RT-11 Kermit to RSX.
Can anyone give me a current pointer?
I'd like to get a copy.
 1-May-84 19:23:47-EDT,504;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 1 May 84 19:23:36 EDT
Received: from DEC-MARLBORO.ARPA by COLUMBIA-20.ARPA with TCP; 1 May 84 19:22:57 EDT
Date: 1 May 1984 1922-EDT
From: NOURSE at DEC-MARLBORO
To: INFO-KERMIT at COLUMBIA-20
Subject: KERMIT for IBMPC (jr)
Message-ID: <"MS10(2124)+GLXLIB1(1136)" 12011955528.38.122.8268 at DEC-MARLBORO>

I am seeking a copy of KERMIT for the IBM PC jr.
I am told that this is the place
   --------
 4-May-84 19:54:50-EDT,2188;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 4 May 84 19:54:40 EDT
Date: Fri 4 May 84 19:53:51-EDT
From: Frank da Cruz <cc.fdc@CUCS20>
Subject: New release of CP/M-86 KERMIT
To: Info-Kermit@CUCS20

Announcing a new release of KERMIT-86 for the DEC Rainbow 100 or the NEC APC
running CP/M-86.  This is version 2.7 of the program.  New features since the
last release (which was 2.4) include:

 8th-bit prefixing, for transferring binary files over communication links
  or to systems that require character parity.

 Command files, TAKE command, automatic TAKE of KERMIT.INI.

 Reliable session logging for raw capture of remote files or typescripts.

 Improved command parsing and error messages, and miscellaneous
  display improvements and bug fixes.

The new KERMIT-86 is available on COLUMBIA-20 via anonymous FTP (ARPANET,
outside of 6am-6pm weekdays), and on CU20B via NFT (DECNET/CCNET).  The
relevant files are:

  KER:RBKERMIT.CMD    The executable KERMIT program for the Rainbow.
  KER:RBKERMIT.H86    The hex file for the Rainbow (load with GENCMD).
  KER:RBKERMIT.HLP    Information about Rainbow KERMIT.

  KER:APCKERMIT.CMD    The executable KERMIT program for the NEC APC.
  KER:RBKERMIT.H86    The hex file for the NEC APC (load with GENCMD).
  KER:APCKERMIT.HLP    Information about NEC APC KERMIT.

  KER:86*.A86        The ASM86 source files for the program.
  KER:86*.RB,86*.APC    System-dependent support.
  KER:86KERMIT.HLP    Brief information about CP/M-86 KERMIT.
  KER:86KERMIT.DOC    The Kermit User Guide chapter on CP/M-86 KERMIT (new).

To obtain the new version on your Rainbow or APC, use your present version
of KERMIT to transfer the appropriate .CMD file.  If you have trouble doing
that, then transfer the .H86 file and build a .CMD file from it using
GENCMD.  If you don't have KERMIT on your Rainbow, read KER:RBKERMIT.HLP
for a helpful hint, or follow the installation directions in the KERMIT User
Guide.  Report any problems directly to me.

Thanks to Ron Blanford of the University of Washington and Bernie Eiben at DEC
for their contributions to this new release.

- Frank da Cruz
-------
 8-May-84 17:22:53-EDT,2126;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 8 May 84 17:22:47 EDT
Received: from BRL-VGR by COLUMBIA-20.ARPA with TCP; 8 May 84 14:14:37 EDT
Date:     Tue, 8 May 84 14:05:00 EDT
From:     [e-mail]
Sender:   [e-mail]
To:       [e-mail]

Dear  info-kermit@columbia-20

    I have a problem with kermitrb. I have tried to use it at
two locations, with the same result. These are unc and brl-vgr.
Both locations run UNIX.

In both cases I can upload from my Rainbow 100 with no difficulty.
However, at both locations, when I try to download, after
issuing the command 'kermit sdd <filename> >dfile', followed by
^\c and R <filename> at my local machine, dfile contains:

>>>    Debugging level = 2
>>>
>>>    Send command
>>>
>>>    sendsw state: S
>>>      spack type: S
>>>         num:  0
>>>         len:  6
>>>            data: "~* @*#"
>>>    sendsw state: S
>>>      spack type: S
>>>         num:  0
>>>         len:  6
>>>            data: "~* @*#"
>>>      rpack type: R
>>>         num:  0
>>>         len:  7
>>>            data: "ABC.TXT"
>>>    sendsw state: A

A local guru at brl-vgr states that my kermit sent the wrong type
and data having sent R type and <filename>. A correct sequence
on my guru's Apple is:

>>>    Debugging level = 2
>>>
>>>    Send command
>>>
>>>    sendsw state: S
>>>      spack type: S
>>>         num:  0
>>>         len:  6
>>>            data: "~* @*#"
>>>    sendsw state: S
>>>      spack type: S
>>>         num:  0
>>>         len:  6
>>>            data: "~* @*#"
>>>      rpack type: Y
>>>         num:  0
>>>         len:  6
>>>            data: "~* @*#"
>>>
>>>    sendsw state: F
>>>       Opening dfile for sending.
>>>      spack type: F
>>>         num:  1
>>>         len:  5
>>>            data: "DFILE"
>>>      rpack type: Y
>>>         num:  1
>>>         len:  0
>>>            data: ""

etc.

Can you give me any guidance on this. I can find no option to SET
on the implementation of kermitrb  which I got from you early in April.
I know there is a new kermitrb coming along, but  my problem may not be cured
there if it has not occurred before.

                Arthur Wouk
                wouk@brl-vgr
                !unc!wouk
 8-May-84 17:30:09-EDT,1374;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 8 May 84 17:30:02 EDT
Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; 8 May 84 16:04:46 EDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <[e-mail]>; 08 May 1984 15:58:51 edt
Date:        07 May 84 15:51 +0200
From:        [e-mail]
Reply-to:    [e-mail]
To:          Info-Kermit <info-kermit@COLUMBIA-20>
Subject:     Bug in KERMIT-800
Message-ID:  <54422@QZCOM>


There is a bug in KERMIT-800. On line 730:

   730   Spsiz=ASCII(S$)-32 : Timint=ASCII(MID$(S$,2,1))

32 should be subtracted from the last expression:

   730   Spsiz=ASCII(S$)-32 : Timint=ASCII(MID$(S$,2,1))-32

Please correct this in your distribution copy of KERMIT-800
(the file is 800KER.BAS).


Also, there might be a problem with our version of KERMIT-10, 2(106).
When KERMIT-10 is waiting for a init package and times out, it does
something wrong. It seems to give a "Kermit-10>" prompter instead of a
NAK package. (The problem goes away if you either hurry and fire up
your local KERMIT before the default 15 s timeout, or set the timeout
in KERMIT-10 to something more reasonable, like 40 seconds).

        - Per Lindberg QZ -



 8-May-84 18:24:27-EDT,613;000000000000
Return-Path: <@CUCS20:PAWKA@NOSC-TECR>
Received: from CUCS20 by CU20B with DECnet; 8 May 84 18:24:22 EDT
Received: from NOSC-TECR.ARPA by COLUMBIA-20.ARPA with TCP; 8 May 84 18:21:29 EDT
Date: 8 May 1984 1510-PST
From: Pawka <PAWKA at NOSC-TECR>
Subject: Getting started
To: INFO-KERMIT at COLUMBIA-20
Reply-To: PAWKA at NOSC-TECR

    A couple of easy questions, I'm trying to implement the VAX/VMS version
interfacing with the generic CP/M version:
    1) How come VXSERVER.C is empty?
    2) Where is CPMGENERI.ASM
    PLease mail directly as I may not yet be on the list,
        Mike
        PAWKA@NOSC-TECR
------
 9-May-84 10:48:34-EDT,615;000000000000
Return-Path: <@CUCS20:PAWKA@NOSC-TECR>
Received: from CUCS20 by CU20B with DECnet; 9 May 84 10:48:26 EDT
Received: from NOSC-TECR.ARPA by COLUMBIA-20.ARPA with TCP; 9 May 84 10:41:29 EDT
Date: 9 May 1984 0730-PST
From: Pawka <PAWKA at NOSC-TECR>
Subject: Getting started
To: INFO-KERMIT at COLUMBIA-20
Reply-To: PAWKA at NOSC-TECR


    A couple of easy questions, I'm trying to implement the VAX/VMS version
interfacing with the generic CP/M version:
    1) How come VXSERVER.C is empty?
    2) Where is CPMGENERI.ASM
    PLease mail directly as I may not yet be on the list,
        Mike
        PAWKA@NOSC-TECR
------
11-May-84 19:43:58-EDT,1627;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 11 May 84 19:43:53 EDT
Received: from MIT-MULTICS.ARPA by COLUMBIA-20.ARPA with TCP; 11 May 84 19:43:37 EDT
Received: from QZCOM.MAILNET by MIT-MULTICS.ARPA with Mailnet id <[e-mail]>; 11 May 1984 19:24:11 edt
Date:        11 May 84 16:35 +0200
From:        [e-mail]
Reply-to:    [e-mail],
 [e-mail]
To:
 [e-mail]
cc:          Info-Kermit <info-kermit@COLUMBIA-20>
Subject:     KERMIT-20 - letting go of the communication line
Message-ID:  <55091@QZCOM>

When using KERMIT-20 to communicate with another host, KERMIT assigns
the terminal line being used for the communication.

If you leave KERMIT in an orderly fashion (EXIT, BYE), the terminal
line will be released, but if you just leave the program with a ^C,
the line will be left assigned to you. If you forget about it and
leave the job running (possibly detached for a LONG time), nobody
without magical powers can use that line, which may be the only one.

I suggest that ^C be trapped, and that you should get an opportunity
to decide if you want to keep the line assigned, or if the line should
be released before you return to the process level above KERMIT.

KERMIT-10 does not seem to have the same problem, since it does not
ASSIGN the terminal line, just OPENs it. Thus the next RESET will
release the line.



13-May-84 19:49:48-EDT,839;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 13 May 84 19:49:43 EDT
Received: from CMU-CS-G.ARPA (not validated) by COLUMBIA-20.ARPA; Sun 13 May 84 19:48:00-EDT
Date: Sunday, 13 May 1984 19:41:00 EDT
From: [e-mail]
To: [e-mail]
Subject: IBM PC Kermit character ins/del
Message-ID: <[e-mail]>

Can the character insert/delete parts of the Zenith-19 terminal
emulator in IBM-PC Kermit be made faster?  Inserting a character
at the beginning of a crowded line is considerably slower than
1200 baud---painful when in Unix Emacs, which uses these functions
when redisplaying.

I'd be willing to do the modifications myself.  Help and/or pointers
to the relevant code appreciated.

Peter Monta (monta@cmu-cs-g)
14-May-84 19:44:14-EDT,837;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 14 May 84 19:44:04 EDT
Received: from SANDIA.ARPA by COLUMBIA-20.ARPA with TCP; 14 May 84 18:30:59 EDT
Date: Mon 14 May 84 16:30:09-MDT
From: Tom Linnerooth <[e-mail]>
Subject: IBM PC - VMS link
To: [e-mail]

There is a person here at Sandia who is trying to use KERMIT
between an IBM PC and a VAX/VMS system.  He asked me to ask
the following questions to the KERMIT mailing list:

1.  Has anybody implemented VT100 emulation from an IBM PC to
    VMS?

2.  Has anybody successfully uploaded WORDMARC (MUSE) files from
    an IBM PC to a VMS system with the attributes correctly set?

Any information send to me (Linnerooth@SANDIA) will be passed
along.  Thanks.

    Tom Linnerooth
-------
15-May-84 07:48:45-EDT,2069;000000000000
Return-Path: <@CUCS20:decvax!mulga!nemeth.uacomsci@Berkeley>
Received: from CUCS20 by CU20B with DECnet; 15 May 84 07:48:39 EDT
Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; 15 May 84 07:48:20 EDT
Received: by UCB-VAX.ARPA (4.24/4.27)
    id AA19640; Tue, 15 May 84 04:48:15 pdt
From: decvax!mulga!nemeth.uacomsci@Berkeley
Received: by decvax.UUCP (4.12/1.0)
    id AA16828; Tue, 15 May 84 07:45:38 edt
Message-Id: <[e-mail]>
Received: by mulga.OZ (4.3)
    id AA26204; Mon, 14 May 84 19:02:50 EST
Date: Mon, 14 May 84 15:52:00 EST
To: info-kermit%columbia-20.arpa.mulga.UUCP@Berkeley
Subject: Hello (and other problems...)

Hi,
This is mainly in the nature of a test transmission, to let you know that
Kermit is alive and well at the University of Adelaide.  Presently, we are
using it on Apple IIs, Vax(VMS), PDP-11 Unix, IBM PC, MedFly(CPM3), Rainbow,
Robin, Northstar (CP/M) and DEC-10.  We have just received a new tape (via
Melbourne Uni.) dated Feb 29, 1984, and are about to upgrade to it.
  Underway are versions being booted for the Cyber 170 (NOS/BE), DECMate,
NEC APC, PDP 11 RSTS, Intel DevSys, PDP 11 Unix, Kaypro, Vax/VMS,
Rainbow (CP/M 86), and Sanyo MBC 550(MS/DOS). {some of them are updates}

Now to the problems:
1. We DESPERATELY could use a BBC (6502) version; can anybody help?
2. I have personally fixed a number of CRITICAL problems in the Apple 6502
   version (I notice it has not changed in the latest release); I am very
   surprised that nobody has noticed that it does not work...I would be
   happy to forward the corrected version if you want it.  Among other
   things, conditional code has been added to support other comms cards
   (Digitek, Super-serial card, Medfly, Mountain CPS multi-function card,
    and California Comp. Systems serial card), as well as the fixes.
3. Has anybody got a working NOS/BE version?

(with some luck, it might even be possible to get a reply in due course --
 amazing when you consider the contortions involved!)

Cheers,
Tom Nemeth
15-May-84 10:38:34-EDT,1160;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 15 May 84 10:38:24 EDT
Received: from ut-ngp.ARPA by COLUMBIA-20.ARPA with TCP; 15 May 84 10:37:18 EDT
Date: Tue, 15 May 84 09:38:30 cdt
From: [e-mail]
Posted-Date: Tue, 15 May 84 09:38:30 cdt
Message-Id: <[e-mail]>
Received: by ut-ngp.ARPA (4.22/4.22)
    id AA13427; Tue, 15 May 84 09:38:30 cdt
To: allegra!decvax!mulga!nemeth.comsci
Subject: Re:  Hello (and other problems...)
Cc: [e-mail]

There is a NOS/BE version of Kermit ready to go.  Ric Anderson
of the University of Arizona at Tuscon did the mods to
170KERMIT.FOR and sent them to me to merge.  I will be sending
a new version to Columbia as soon as I can get everything
together.  If you are trying to get Kermit-170 Version 1.0 up
then I would suggest waiting for this version.  It should be
much easier to bring up.  There is also some development going
on at CDC to make some mods to the new version for NOS sites.

Jim Knutson
ARPA: knutson@ut-ngp
UUCP: {ihnp4,seismo,kpno,ctvax}!ut-sally!ut-ngp!knutson
Phone: [phone]
15-May-84 12:29:02-EDT,1073;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 15 May 84 12:28:46 EDT
Received: from RUTGERS.ARPA by COLUMBIA-20.ARPA with TCP; 15 May 84 12:09:38 EDT
Received: from RU-GREEN.ARPA by RUTGERS.ARPA with PUP; 15 May 84 12:08:58 EDT
Date: 15 May 84 12:10:36 EDT
From: Brian <[e-mail]>
Subject: Suggestion for Kermit
To: [e-mail]
Home: 506 Birch Dr.  Cherry Hill, NJ.  [phone]
Work: RCA Corp.  Moorestown, NJ. [phone]

I use KERMIT to transfer files between computers whenever possible.
However, when I call RCPM bboards, I usually end up using MODEM to do
the transfers because most do not support KERMIT.  I prefer KERMIT to
MODEM however MODEM has one very nice feature which displays the
number of packets before completion.  This feature is extremely
usefull at speeds lower than 1200 baud!!!  I am only a user of these
programs, so I do not know what it would take to add this feature to
KERMIT, but I think it is something to be considered.

Brian Sietz
-------
15-May-84 18:15:53-EDT,1614;000000000000
Return-Path: <@CUCS20:[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 15 May 84 18:15:45 EDT
Received: from csnet-relay by COLUMBIA-20.ARPA with TCP; 15 May 84 18:14:28 EDT
Received: From hp-labs.csnet by csnet-relay;  15 May 84 17:39 EDT
Date: Tue, 15 May 84 12:23:58 pdt
From: Ken Poulton <[e-mail]>
Received: by HP-VENUS id AA11328; Tue, 15 May 84 12:23:58 pdt
Message-Id: <8405151923.AA11328@HP-VENUS>
To: [e-mail]
Subject: Software Tools Kermit
Cc: ~/[e-mail]
Source-Info:  From (or Sender) name not authenticated.

To anyone thinking about doing a kermit for a new machine:

I have a Kermit written in Software Tools Ratfor which should
run on any machine supporting the Software Tools package.
This kermit is essentially a translation of the C kermit,
although I have made enhancements since then,
notably server mode and binary and repeat encoding.
It currently runs on the HP3000 and the Univac 1100.
(Columbia-20 has a copy, but you should contact me
for the most up to date version.)

The Software Tools package is a set of public domain *portable*
programmer's utilities written in Ratfor.  Software Tools
packages exist on most mainframes and minicomputers.
(There are also CP/M and MS-DOS packages, but these systems
are already well covered by existing Kermits.)

To find out about the Tools on your system contact:

    Software Tools Users Group
    Nancy Deerinck
    Lawrence Berekely Lab
    RTSG-46A
    Univ of CA
    Berkeley, CA 94720
    [phone]  0700 to 1800 PDT
16-May-84 03:01:55-EDT,782;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 16 May 84 03:01:03 EDT
Date: Tue 15 May 84 20:50:25-EDT
From: Nick Bush <G.BUSH@CUCS20>
Subject: Re: Hello (and other problems...)
To: decvax!mulga![e-mail]
cc: INFO-KERMIT@CUCS20
In-Reply-To: Message from "decvax!mulga!nemeth.uacomsci@Berkeley" of Tue 15 May 84 07:48:38-EDT

Some (but probably not all) of the problems in the Apple-DOS version have
been fixed in version 2.0, but we would certainly like to know about any
problems you have found.  One of the major changes in version 2.0 was making
the comm card selection at run time.  There have been other changes made
since version 2.0, but these still need to be integrated into one copy.

- Nick
-------
17-May-84 07:41:24-EDT,920;000000000000
Return-Path: <@CUCS20:BRACKENRIDGE@USC-ISIB>
Received: from CUCS20 by CU20B with DECnet; 17 May 84 07:41:19 EDT
Received: from USC-ISIB by COLUMBIA-20.ARPA with TCP; 16 May 84 15:00:53 EDT
Date: 16 May 1984 11:59:40 PDT
Subject: Kermit for more than Universities
From: Billy <BRACKENRIDGE@USC-ISIB>
To: info-kermit@COLUMBIA-20, info-ibmpc@USC-ISIB

Congratulations on some recognition for Kermit at last.

I was dismayed to hear that Lotus' new product Symphony, which is supposed
to combine data base, with spreadsheet, word processing, and communication
capabilities is basing the communications on the Christiansen modem protocol.

Those of us with PDP-10s who rely on Kermit's variable packet size appear
to be out of luck in this regard. Has anyone seen this product and are
interface specifications described such that Kermit could be replaced as
the communications portion of Symphony?
-------
17-May-84 08:19:06-EDT,1452;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 17 May 84 08:18:59 EDT
Date: Wed 16 May 84 13:27:11-EDT
From: Frank da Cruz <CC.FDC@CUCS20>
Subject: Publicity
To: Info-Kermit@CUCS20

A two-part article about KERMIT, written by me and Bill Catchings, will appear
in the June and July issues of BYTE magazine.  The title was to be "KERMIT: A
Simple File-Transfer Protocol".  However, I just found out that the editors
changed the title at the last minute to "KERMIT: A File-Transfer Protocol for
Universities" to make it fit better with their June theme, education.  The new
title is obviously misleading -- KERMIT is for everyone; I've asked them to
make some kind of correction to this in the July issue.  The article discusses
the motivation for KERMIT, problems of asynchronous communication, and presents
an overview of the protocol.  It was written about a year ago, and may appear
out of date in some respects.

Shorter articles will appear in forthcoming issues of EDUNET NEWS and DEC's
Large Systems News; these talk more about how KERMIT is shared, distributed,
etc, and how contributions have been made.

Also, an award called the CARROLL showed up unexpectedly on our doorstep from
French DECUS; it turned out to be a bottle of champagne and an engraved silver
plate, for the best software contribution of 1983-84.  So even free software
has its compensions...

- Frank
-------
17-May-84 08:26:57-EDT,1312;000000000000
Return-Path: <@CUCS20:ABN.ISCAMS@USC-ISID>
Received: from CUCS20 by CU20B with DECnet; 17 May 84 08:26:51 EDT
Received: from USC-ISID by COLUMBIA-20.ARPA with TCP; 16 May 84 21:49:58 EDT
Date: 16 May 1984 18:07-EDT
Sender: ABN.ISCAMS@USC-ISID
Subject: Re: Kermit for more than Universities
From: ABN.ISCAMS@USC-ISID
To: BRACKENRIDGE@USC-ISIB
Cc: info-kermit@COLUMBIA-20, info-ibmpc@USC-ISIB
Message-ID: <[USC-ISID]16-May-84 18:07:06.ABN.ISCAMS>
In-Reply-To: The message of 16 May 1984 11:59:40 PDT from Billy <BRACKENRIDGE@USC-ISIB>

Billy (et al)

You PDP-10 owners aren't the only ones dependent on Kermit's variable
packet size.  My TAC doesn't seem to want to upload with MDM7nn, despite
flow control (probably disabled by NMODEM on my host) -- I think it's also
the Christensen packet size overflowing the TAC keyboard buffer.  I haven't
fought it out yet because of Kermit's packet size flexibility.  I just
cut uploads down to 64 characters or so, and it works just fine!

I don't have Symphony (still in the 8-bit world), but you have a good point.
Would be nice to have the alternative, especially with the newly gained
Kermit capability to send 8-bit through 7-bit channels!  I get awfully
tired of HEXIFYing things in some situations.

Regards,
David Kirschbaum
Toad Hall
17-May-84 08:27:21-EDT,584;000000000000
Return-Path: <@CUCS20:POLARIS@USC-ISI>
Received: from CUCS20 by CU20B with DECnet; 17 May 84 08:27:15 EDT
Received: from USC-ISI by COLUMBIA-20.ARPA with TCP; 17 May 84 08:25:41 EDT
Date: 17 May 1984 08:26-EDT
Sender: POLARIS@USC-ISI
Subject: congrats
From: POLARIS@USC-ISI
To: info-kermit@COLUMBIA-20
Message-ID: <[USC-ISI]17-May-84 08:26:00.POLARIS>

Dear All:

Congratulations on your CARROLL award, it is well
deserved...KERMIT FOREVER!  (Or at least until everyone runs only
one kind of machine and operating system).

Best Wishes for more KERMITS in the brood.
17-May-84 15:15:48-EDT,1220;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 17 May 84 15:15:36 EDT
Date: Thu 17 May 84 13:07:27-EDT
From: Frank da Cruz <CC.FDC@CUCS20>
Subject: Info-Kermit
To: Info-Kermit@CUCS20

Info-Kermit is not a terribly active mailing list, at least not when you
compare it to Info-Micro, Info-CPM, etc.  We've averaged something like one
message per day since the list was started last August.  However, the list is
rather large, with more than 200 members (many of which are mailing lists
themselves).  It takes our poor mailer something like an hour of elapsed time
to process an Info-Kermit message.

COLUMBIA-20, the Columbia Computer Science Department DECSYSTEM-20 which is
host to the Internet KERMIT distribution area and to Info-Kermit, will be
undergoing extensive hardware work over the summer, and may be unavailable for
periods of time.  When it is available, demand for its services will be high,
to make up for lost time.  Therefore, Info-Kermit mail will no longer be sent
automatically to the list membership, but will be redistributed periodically
by me, perhaps in digest form.

This change will start tomorrow (Friday, May 18).  - Frank
-------
18-May-84 04:21:20-EDT,5016;000000000000
Return-Path: <@CUCS20:decvax!mulga!nemeth.uacomsci@Berkeley>
Received: from CUCS20 by CU20B with DECnet; 18 May 84 04:21:11 EDT
Received: from UCB-VAX.ARPA by COLUMBIA-20.ARPA with TCP; 18 May 84 04:20:11 EDT
Received: by UCB-VAX.ARPA (4.24/4.27)
    id AA29982; Fri, 18 May 84 01:19:31 pdt
From: decvax!mulga!nemeth.uacomsci@Berkeley
Received: by decvax.UUCP (4.12/1.0)
    id AA16072; Fri, 18 May 84 04:08:17 edt
Message-Id: <[e-mail]>
Received: by mulga.OZ (4.3)
    id AA03543; Fri, 18 May 84 10:15:43 EST
Date: Thu, 17 May 84 15:37:00 EST
To: info-kermit%columbia-20.arpa.mulga.UUCP@Berkeley
Subject: Apple Kermit patches

To (would-be) Apple (6502) Kermit users:

The following is a detailed list of problems I have corrected in the Apple
Kermit (as on the Feb 29, 1984 release tape); due to lack of a suitable
means of accurately transmitting the source code, I have removed the pieces
which are relevant.  In practice, I did not reassemble the code, but patched
the binary ON THE APPLE; included in the following are the patches applicable
to (either the Hayes DC Modem or the old Apple serial card) Apple Kermit.

{Note: To do this, boot the Apple, then BLOAD KERMIT (or whatever),
                   and enter the monitor by CALL-151
                   then put in the patches as below (*aaaa:cc cc cc ....<cr>)
                   and finally  BSAVE KERMIT(NEW),A$800,L$3640
                   now you can BRUN KERMIT(NEW)  }

;
;   1A          By: Thomas A. Nemeth, Adelaide University.
;               Add options to support other common serial interface
;               cards:  CPS, SSC, CCS(&Digitek) & Medfly with all of their
;               perversities.
;{I have omitted all except the SSC; others available on request}
;*16c2:e0 3d                    {jump to init routine}
;*3de0:20 00 c2 20 c8 16 60     {init SSC}
;*17d0:ad 89 c0                 {status}
;*17d4:08                       {rx rdy mask}
;*17df:ad 88 c0                 {data in}
;*180c:ad 89 c0                 {status}
;*1810:10                       {tx rdy mask}
;*1814:8d 88 c0                 {data out}

;
;   7A          By: Thomas A. Nemeth, Adelaide University       On: 11-JAN-1984
;               Fix typing error in above, causing garbage at
;               end of transmitted file names (server).
;*1ed1:c9       {should have been \#hspace !!}

;  10           By: Thomas A. Nemeth            On: 18-JAN-1894
;               Create a cursor in connect mode (cheap & nasty, but works)
;*17c7:20 17 3e
;*1803:20 17 3e
;*3e17:aa 20 9c fc 8a 09 80 20 ed fd a9 df 20 ed fd 20 10 fc 60
;(3e2a)

;
;  11           By: Thomas A. Nemeth            On: 18-JAN-1984
;               Delete <lf> at start of file; there is an implied
;               <cr> at the start.
;*198d:20 10 3e
;*3e10:8d 02 15 8d 12 15 60

;
;  12           By: Thomas A. Nemeth            On: 18-JAN-1984
;               On flushing the disk buffer (RECEIVE), indicate it
;               has been emptied.  Also, get correct error status (missing code)
;*2c25:20 04 3e
;*3e04:20 06 ab a9 00 8d 4f 15 ad c5 b5 60
;(3e10)

;
;  13           By: Thomas A. Nemeth            On: 18-JAN-1984
;               Must only check quoting of 8-bit-quote character
;               if 8-bit quoting is ON (BUFILL & BUFEMP) {symptom: loses N-s)
;*2cd0:20 f6 3d
;*3df6:ad 0a 15 c9 01 d0 06 ad 17 15 cd 41 15 60
;(3e04)

;
;  14           By: Thomas A. Nemeth            On: 18-JAN-1984
;               Fix typing error which caused error on file close.
;               {compunded with [12]}
;*1d53:1f

;
;  15           By: Thomas A. Nemeth            On: 27-JAN-1984
;               Checksum error (failure return from RPAK) is NEVER
;               checked if packet sequence number is correct!!!!!! (8 places)
;*3e2a:20 65 28 8d fc 14 c9 00 d0 01 60 4c 82 12
;(3e38)
;*1a31:20 2a 3e 4c 55 1a
;*1ad4:20 2a 3e 4c 0d 1b
;*1c29:20 2a 3e 4c 5b 1c
;*1e2c:20 2a 3e 4c 60 1e
;*1eee:20 2a 3e 4c 23 1f
;*1f81:20 2a 3e 4c b5 1f
;*2029:20 2a 3e 4c 4f 20
;*20ac:20 2a 3e 4c e0 20

;
;  16           By: Thomas A. Nemeth            On: 01-FEB-1984
;               Fix error in FGETC, causing it to lose the last
;               character of every disk buffer (but I still don't
;               understand why EVERY disk read returns EOD status).
;*2e6e:ad b5 c1 8d 50 15 a9 00 8d 4f 15

That's all folks!

I hope this is not garbled too much in transit; the whole thing should take no
more than about 15-20 mins to patch on an Apple (even though it looks, and IS
extremely grotty);  and as I said before, it is amazing that it ran at all!

I will be happy to send you the source code, although any self-respecting
6502 freak should be able to recreate it from the above.  Please don't send
any suggestions to me, but to the author of the original code (the above was
done under sufferance!); all I can say is that it seems to work now.

Tom Nemeth
23-May-84 18:58:43-EDT,9663;000000000001
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 23 May 84 18:58:24 EDT
Date: Wed 23 May 84 18:59:04-EDT
From: Frank da Cruz <CC.FDC@CUCS20>
Subject: Info-Kermit Digest V1 #1
To: Info-Kermit: ;
Reply-To: Info-Kermit@COLUMBIA-20

Info-Kermit Digest           Wednesday, 23 May 1984        Volume 1 : Number 1

Today's topics:
                            Info about Info-Kermit
                   New Release of LCTERM for Rainbow MS DOS
               New Implementation of KERMIT for MUMPS on PDP-11
          New Implementation of KERMIT for IBM PC under UCSD p-System
                         Hayes internal modem question
                         UCSD Pascal Kermit for Apple?
                   KERMIT Enhancement -- Changing Filenames

-------------------------------------------------------------------------------
Date: Wed 23 May 84 12:04:05-EDT
From: Frank da Cruz <CC.FDC@COLUMBIA-20>
To: Info-Kermit
Subject: Info About Info-Kermit

Because of the need to reduce the load on the Columbia University Computer
Science Department DEC-20 (COLUMBIA-20) during a period of heavy use and
hardware & software development, Info-Kermit will be run as a digest for the
next couple months.  This is the first issue.

Another policy that ARPAnet users should be aware of is the recent restriction
on anonymous FTP at COLUMBIA-20, imposed for the same reasons.  Anonymous FTP
logins are not allowed between the hours of 6:00am and 6:00pm eastern time,
weekdays, but are permitted outside these hours.

A reminder about how to get KERMIT.  For ARPAnet/Internet sites, connect to
host COLUMBIA-20, login as user ANONYMOUS with any non-null password.  For
CCnet (DECnet) sites, use NFT to host CU20B; depending upon the arrangements
between Columbia and your site, you may be able to access the files specifying
user ANONYMOUS; otherwise contact your system manager.  In both cases, all the
KERMIT files are in PS:<KERMIT>, which you can also refer to using the logical
device name KER:.  The file KER:00README.TXT contains information on what files
are in the KERMIT distribution area and how to find them.  One file worth
checking from time to time is KER:CURRENT.DOC, a brief tabular listing of each
existing version of KERMIT, showing the version number and date of the latest
release of each version.

KERMIT network distribution is also available to users of BITNET through a
server called KERMSRV set up at host CUVMA, an IBM system at Columbia.  To get
started with KERMSRV, type the following command on your own BITnet host:

  SMSG RSCS MSG CUVMA KERMSRV HELP

For those who cannot obtain KERMIT files over these networks, there remain the
DECUS, SHARE, STUG and other user group tapes, various PC or micro floppy
distribution services, and Columbia itself will send out tapes for a
distribution fee (our tape service is described in KER:FLYER.DOC).

Archives of Info-Kermit are in KER:MAIL.*.  The messages up to March 8, 1984
are in KER:MAIL.83A.  Those from March 8 to May 18 (the last "direct mail"
activity) are in KER:MAIL.83B.  The current mail (starting with this issue of
the digest) are in KER:MAIL.TXT.

- Frank

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

Date: Wed 23 May 84 12:04:05-EDT
From: Frank da Cruz <CC.FDC@COLUMBIA-20>
To: Info-Kermit
Subject: New LCTERM for Rainbow MS DOS

Version 2.14 of Larry Campbell's LCTERM multi-protocol (including KERMIT and
XMODEM) communication program for the DEC Rainbow under MS DOS 2.05 or later is
now available.  There are many fixes since the last release, and enhancements
including a session script facility.

The program is available via anonymous FTP from COLUMBIA-20 (ARPANET, only
outside of peak hours), or NFT from CU20B (DECNET/CCNET), as KER:RBLCTERM.*.
RBLCTERM.EXE is the executable program, in MS-DOS binary format.  RBLCTERM.C is
the source (actually this file contains the concatenation of various C and
ASM86 source files).  Installation instructions are in KER:RBLCTERM.HLP.
Documentation is in KER:RBLCTERM.DOC.  Various other files are also included,
including a .BWR file that lists some bugs & restrictions.

Since there is no "printable" object module, such as the .HEX or .H86 files of
CP/M, or the .FIX file provided with MS DOS (IBM PC) Kermit, you should read
the .HLP file before attempting to download LCTERM for the first time.

By the way, there will also be a version of Columbia's MS DOS Kermit for the
Rainbow, which will appear as part of the next MS DOS Kermit release within the
next few weeks.

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

Date: Wed 23 May 84 12:04:05-EDT
From: Frank da Cruz <CC.FDC@COLUMBIA-20>
To: Info-Kermit
Subject: New Implementation of KERMIT for MUMPS-11

Kermit-M is a version of Kermit that is written in 1982 ANSI Standard MUMPS, by
David Rossiter of the New York State College of Veterinary Medicine, Veterinary
Computing Facility.  This version is designed for PDP-11 computers running
InterSystem's M/11 operating system (version 5), but instructions are provided
for converting to other machines or MUMPS implementations.  The files may be
found in the KERMIT distribution area as KER:MPKERMIT.*.  Some of these files
have very long "lines" (over 200 characters), which are apparently unavoidable
in the MUMPS language.  Thanks to Kate MacGregor of Cornell University for
contributing this Kermit implementation through BITNET.

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

Date: Wed 23 May 84 12:04:05-EDT
From: Frank da Cruz <CC.FDC@COLUMBIA-20>
To: Info-Kermit
Subject: New Implementation of KERMIT for IBM PC under UCSD p-System

This implementation of KERMIT for the IBM PC p-System was submitted by Kate
MacGregor and Steve Pacenka of Cornell University Computing Services.    It
requires version IV.x of the UCSD p-System, and is also intended to be
transferrable to other computers that run the same level of the p-System.
It was developed on the IBM PC using NCI release C1F.

The files are in KER:UCIBMPC.*.  The Pascal source files are concatenated
together into the file KER:UCIBMPC.PAS; there are also .DOC and .HLP files.
The other UCSD Pascal Kermit from Cornell (the one for the Terak) has been
reorganized along similar lines, as KER:UCTERAK.*.

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

Date: Tue 22 May 84 12:04:05-EDT
From: Alan Crosswell <US.ALAN@CU20B>
Subject: Hayes internal modem question.
To: [e-mail], info-kermit@CUCS20

I would appreciate it if somebody who has the Hayes internal modem or who
looked at one and decided against it would let me know what your experience
has been with it.  I have heard a rumor that it is unreliable.  Is this
true?  Is it worth the price difference to get the internal modem instead
of an async card and external one?  The professor who is looking is
absolutely convinced that he will never want to attach to an RS232 line
but will always use a telephone from his home.

Alan Crosswell
User Services
Columbia University Center for Computing Activities

[Editor's note: I don't know if the Hayes modem is good or bad, but there are
several good reasons for avoiding internal modems in general:
. They take up a slot that might be otherwise put to better use
. They can't be easily used on other PCs
. They can't be used at all on different kinds of micros
. They tend to confuse and/or complicate communication software, like KERMIT
People interested in using KERMIT- or MODEM-like programs for transferring
files should avoid internal modems.]

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

Date: Tue 22 May 84 18:06:05-PDT
From: Bruce Tanner <[e-mail]>
Subject: Apple Pascal Kermit?
To: [e-mail]

I see from VERSIONS.DOC that there are several UCSD p-system Kermits
around, but none for the Apple.  Is there one available?

Thanks,
-Bruce

[Not to my knowledge.  But see the above announcement for a UCSD Pascal Kermit
for the IBM PC.  There are now at least three versions -- IBM PC, Terak,
HP-98x6 -- to use as a basis.  Any volunteers?  - Frank]

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

Date: Wed 23 May 84 15:20:05-EDT
From: Dave Weaver <[e-mail]>
Subject: KERMIT Enhancment
To: [e-mail]

I would like to see all flavors of KERMIT offer an option to the
RECEIVE or GET commands to output to a file spec other than the
same one as you are receiving.  Not only would this help with
file name length problems, but it would be a valuable asset on
VAX systems with DECnet, because one could "RECEIVE" a file to
a different node.

Something like:

Kermit-32> get FILE.EXT NODE"user password"::FILE.EXT

and:

Kermit-80> get TOPS20_LONG_FILE_NAME.EXTENSION FILE.EXT

The latter is because TOPS20 supports long file names and it
would be nice to be able to copy them without first copying
them to some shorter named file.

In the former example I could be talking to a 20 from a VAX
which is a DECnet node, but I would like to copy the file to
another node other than the one I am running KERMIT from.

                                        -Dave

[Heartily endorsed.  In fact, the Kermit Protocol Manual recommends this;
see section 9.1 of the 5th edition.  Not many implementations support all
these options; KERMIT-20, for instance lets you send FOO (AS) BAR, but
not GET FOO (AS) BAR.  This should be fixed.  But note that there's always
the problem of delimitation -- some systems (ITS, VM/CMS) have filenames
with imbedded spaces.  FTP takes care of this by having you type the
source and destination filespecs on separate lines.  - Frank]
-------
26-May-84 15:45:29-EDT,6067;000000000001
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 26 May 84 15:45:14 EDT
Date: Fri 25 May 84 20:28:43-EDT
From: Frank da Cruz <CC.FDC@CUCS20>
Subject: Info-Kermit Digest V1 #2
To: Info-Kermit: ;
Reply-To: Info-Kermit@COLUMBIA-20

Info-Kermit Digest        Friday, 25 May 1984      Volume 1 : Number 2

Today's Topics:
                           Info-Kermit Digest Format
                                Kermit at DECUS
                     Kermit on Cyber Machines (2 messages)
                             Kermit on Epson QX10?
              Kermit Enhancement - renaming files in get and send

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

To: Info-Kermit
Date: Friday, 25 May 1984 8:04pm-EST
From: Frank da Cruz <cc.fdc@columbia-20>
To: Info-Kermit
Subject: Info-Kermit Digest Format

There were a few complaints about the format of the first issue of the new
Info-Kermit digest.  Various digest digesters complained of indigestion.  This
issue should be better -- the dashed separators are the "right length", there
are some asterisks at the end, tabs removed, etc.  Let me know of any further
problems.

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

Date: Friday, 25 May 1984 8:04pm-EST
From: Frank da Cruz <cc.fdc@columbia-20>
To: Info-Kermit
Subject: Kermit at DECUS

The new KERMIT releases that were announced in the last issue (UCSD, MUMPS),
this issue (Cyber 170), and the next issue (most likely VAX/VMS, TOPS-10, and
Professional-350) will be available at Spring DECUS.  Brian Nelson will
probably be bringing new releases of his PDP-11 Kermit for RSX, RSTS, and maybe
RT-11.  Attempts will be made to bring all these last-minute releases together
into a coherent collection for the various SIG tapes (particularly VMS and
RSX), and to make them available on whatever machines are provided by DEC for
people to make their own copies.  If you need any of these new releases and
you're going to DECUS, you might want to bring along a tape (a 2400' reel --
the entire KERMIT distrubution won't fit on anything smaller), as well as some
floppies for the Rainbow and Pro-350 versions.  This will save you the trouble
of FTP'ing a large amount of data over the net, or sending for a tape if you
don't have FTP access, as well as avoiding cumbersome bootstrapping procedures
for first-time users of Rainbow and Pro Kermit.

I'm not going to DECUS myself, but I understand a KERMIT session has been set
up for Friday (when most people have left).

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

Date: Fri, 25 May 84 13:24:38 cdt
From: [e-mail]
To: [e-mail]
Subject: New Cyber Kermit

You can get the source for the new Cyber Kermit via anonymous ftp to ut-ngp.
The files you need are 170kermit.for and 170azlib.asm.  These two files
should replace the current 170kermit.for.  The following are a list of
changes made:

Version 2.0 - File name packets send uppercase file names, Error packets
        now handled correctly, modified character tables for CDC 63 and
        64 character sets, merged Ric Anderson's NOS/BE code, added
        push and ! commands, added read delay for performance tuning,
        changed binary data-mode to ignore NEL characters,  OVCAP or
        SEGLOAD version can be produced, reduced field length.

Note that this version now truly supports NOS/BE (aside from differences
in front-ends).  Ric Anderson of the University of Arizona at Tuscon
deserves credit for this.

I'll hopefully have a true NOS version in a couple of months.

Keep up the good work,
Jim Knutson
ARPA: knutson@ut-ngp
UUCP: {ihnp4,seismo,kpno,ctvax}!ut-sally!ut-ngp!knutson
Phone: [phone]

[Ed Note -- The new files are in KER:170*.* on COLUMBIA-20, available via
anonymous FTP in the usual manner.  Note that a good deal of the Fortran code
of the previous release has been replaced by assembler.  Also, there doesn't
seem to be any new documentation beyond what's been said above, but then maybe
none is necessary.]

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

Date: Fri, 25 May 84 10:11:04 EST
From: decvax!mulga!stephenw.murdu@Berkeley (Stephen Withers)
To: [e-mail]
Subject: Kermit on Cyber Machines

You might be interested to know that one of my colleagues has modified
Kermit-170 (Cyber) to run on the 815 - we'll send you a copy when it's
been more thoroughly tested.  Our 815 runs NOS 2.2, by the way, and
Darryl Chivers (the one doing the job) also plans a NOS/BE version for
the 730, but that's further off.

- Steve Withers, University of Melbourne

[Let's hope the different Cyber versions will get back together one day...
- Ed.]

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

Date: Wed, 23 May 84
To: info-kermit@columbia-20
Subject: Kermit on QX10
From: [e-mail]

Has anyone brought kermit up on the Epson QX10?

Bob Fenchel

[Not to my knowledge.  Anyone else heard anything?  - Ed.]

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

Date: Thu, 24 May 84 10:31:20 pdt
From: Ken Poulton <[e-mail]>
To: [e-mail]
Subject: Kermit Enhancement - renaming files in get and send

I agree with the need.  I found kermit-20's "send .. (as) .."  so handy that I
implemented it for Tools and Unix Kermits.  Doing the same for Get would be
nice, too.  [Ed note -- Ken is the author of the Software Tools Kermit, written
in Ratfor.]

A note on syntax: I chose to allow Send to take any number of files (possibly
wildcarded); any filename followed with "-as" is sent with the word following
the "-as" as the name.  Obviously, you don't want to mix wildcards with "-as",
but the "-as" needn't restrict you to one file at a time.  In my opinion, files
with spaces in their names are a pathological case: try to provide a mechanism
to deal with them, but don't restrict your syntax (one file per line) because
of them.

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

End of Info-Kermit Digest
*************************
-------
30-May-84 19:11:31-EDT,8442;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 30 May 84 19:11:07 EDT
Date: Wed 30 May 84 19:06:46-EDT
From: Frank da Cruz <CC.FDC@CUCS20>
Subject: Info-Kermit Digest V1 #3
To: Info-Kermit: ;
Reply-To: Info-Kermit@COLUMBIA-20

Info-Kermit Digest      Wednesday, 30 May 1984     Volume 1 : Number 3

Today's Topics:
               KERMIT for TRS-80 I and III with TRSDOS
                     New Release of DEC-20 KERMIT
                 DEC Pro-350 & IBM PC Kermit Queries
                   KERMIT for Commodore-64 Underway
                        Fix for Kermit-80 V3.9

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

Date: Mon, 28 May 84 16:55:55 CDT
From: Stan Hanks <[e-mail]>
Subject: TRS-80 Kermit
To: Frank da Cruz <[e-mail]>
Cc: Stan Barber <[e-mail]>

Frank,

Stan Barber has finally completed the TRS80 version of Kermit.  Included
is all of the source, plus a BASIC program that, when executed, will
generate a correct binary. The manual entry for the user's guide is also
present.

This implementation of the Kermit is written in Z80 Assembler,
compatible with M80 and EDAS from Mysosys.  It runs under all DOS's
available for the TRS80 Model I or Model III (and the Model 4 running in
Model III mode).  It has been checked out under the following DOS's:
TRSDOS 2.3 (Model I), TRSDOS 1.3 (Model III), NEWDOS/80 V 2.0, LDOS
5.1.3, DOS+ 3.5 and VTOS 3.0 (Model I).

                                Stan Hanks

[Ed. Note: The files have been renamed for grouping together in the
KERMIT distribution as KER:TRS*.*.  The file KER:TRSMIT.HLP contains the
correspondence between the real names and distribution names.  The file
KER:TRSMAKE.BAS is a Basic program that generates the executable binary,
and KER:TRSMIT.DOC is the KERMIT User Guide manual chapter for this
version.  All available from COLUMBIA-20 or CU20B in the normal manner.]

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

Date: Wed 30 May 84 16:47:28-EDT
From: Frank da Cruz <[e-mail]>
To: Info-Kermit
Subject: New Release of DEC-20 KERMIT

There is a new release of KERMIT-20 for the DECSYSTEM-20, 4(222), which
fixes a couple bugs in the previous release, 4(215), and should replace that
version (or any earlier version).  The changes since edit 215 include:

 Fix FILE NAMING NORMAL-FORM (it was broken in the previous release).
. Fix problem with two consecutive ~ chars in data when doing compression.
. Don't create empty debugging log files.
. Change SET DEBUGGING LOG to LOG DEBUGGING, like other KERMITs.
. Add SET FLOW-CONTROL to allow explicit enable/disable of XON/XOFF.
. Add SET EXPUNGE to allow enable/disable of automatic expunge on DELETE.
. Make LOCAL prefix optional on LOCAL commands like LOCAL DELETE, etc.
. Add LOCAL TYPE, LOCAL RUN.
. Change LOCAL/REMOTE DISK to LOCAL/REMOTE SPACE, like other KERMITs.
. Add code to believe remote TTY line speed under TOPS-20 6.0.
. Miscellaneous minor bugs fixed.

The new release is in KER:20KERMIT.* on COLUMBIA-20 or CU20B.  The file
suffixes include:

  .EXE - The executable program
  .MAC - The MACRO-20 program source file
  .UPD - The program update history
  .DOC - A new KERMIT User Guide chapter for KERMIT-20
  .MSS - The Scribe source file for the manual chapter
  .INI - A sample KERMIT.INI file

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

Date: 28 May 84 19:02:01 EDT
From: Chris Koenigsberg <CK0C@CMCCTE>
To: To: info-kermit-request@CUCS20
Subject: DEC PRO 350 and IBM PC KERMIT

Hello, I am a staff technologist here at CMU's School of Urban and
Public Affairs, where they have given us 50 DEC PRO 350 personal
computers to play with.  I wonder if anyone has successfully assembled
a Kermit to run on these beasts.

    Thanks for all the good work you have done.
                Chris Koenigsberg
                Urban Systems Institute
                CMU SUPA MMC204
                [phone]

[Ed. Note --  At least two versions of KERMIT for the Pro-350 have
been done; one by Bob Denny of DECUS C fame, and the other by Stevens
Institute of Technology.  The Stevens version will be released this
week or next week, and will be presented at DECUS.]

p.s. Is there a new version of the Kermit-86 for the IBM running
PC-DOS?? Around here everyone uses version 1.19 or 1.19A....1.19 gets
hung up a lot when running things like Emacs on the host, and 1.19A is
the "brain-damaged" version which they once thought would eliminate
the overloading of the TOPS20 front end by drastically cutting the
speed with which packets are sent during uploads.  (They were wrong,
the front end still gets overloaded, and lots of people are using this
brain-damaged very slow upload for absolutely no reason!!)

[Ed. Note - Columbia is working on a new release of MS DOS KERMIT, far
advanced over the current release, which is 1.20.  It should be ready
within a couple weeks (I've been saying this for months, but this time
I really mean it...).  The new version has much improved terminal
emulation, particularly in the character insert/delete area.  The
special CMU customization for slowing things down, pausing between
packets, etc, has never proven to be necessary at any other site that
I know about, and is probably an artifact of some system modifications.]

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

Date: 30 May 84 16:43:26 EDT
From: Eric <[e-mail]>
Subject: C64 Kermit
To: [e-mail]

Hi Frank,

 Many of us C64 owners are distraught at the lack of a good public
domain communication/file transfer program like Kermit.  We are also
distraught at the lack of attention Columbia has decided to give to
the project of writing Kermit for this machine.  Therefore, I have
decided to start the project myself.  At present the VT52 emulation is
complete, and was written by Frank Prindle (Prindle@NADC) and myself.
The remainder of Kermit will be written by me, and later some will be
done with the help of Brian Beattie (Beattie@mitre-gateway).  If
anyone up there has already started to write anything, or formulate
some ideas as how to approach the project on the C64, we would like to
hear from them.  I will keep you posted as to our progress.  By the
way, we will be writing it in Commodores' Macro Assembler and
maintaining a working copy in Cross format. Due to various time
restrictions, I don't expect the project to be near completion till
the end of the summer.

Eric Lavitsky (Lavitsky@Rutgers)

[Ed. Note - Good for you!  I wish we had been able to do it.  We
announced our intention to do C64 Kermit because one of our
departments had decided to require its students to buy C64s.  We even
went so far as to buy one ourselves to do the work on.  But the
project never bubbled up high enough on our priority list to actually
get started, what with the MS DOS, CP/M, DEC-20, IBM VM/CMS, Unix,
Macintosh, and other implementations that were more important to
larger numbers of Columbia users.  Good luck!]

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

Date: 29 May 1984 0242-PDT
From: Charles Carvalho <CHARLES at ACC>
Subject: Fix for Kermit-80 V3.9
To: CC.FDC at COLUMBIA-20

Kermit-80 v3.9 will always prefix all &'s in the data with #'s.  This should
only be done if 8th-bit prefixing has been requested.  This problem will only
be seen when the other Kermit does not request (or permit) 8th-bit quoting,
since Kermit-80 always agrees to use 8th-bit quoting.  To fix it, replace the
following three lines between gtch4a: and gtch4b:.

    lxi    h,qbchr        ;[jd] point to 8-bit quote char
    cmp    m        ;[jd] is it our quote character?
    jz    gtch4b        ;[jd] yes, have to quote it...

with:

    lda    quot8        ; Are we doing 8th-bit quoting?
    ora    a
    jz    gtch4c        ; if not, skip test and restore char.
    lda    qbchr        ; get 8th-bit quote character
    cmp    d        ; same as current character?
    jz    gtch4b        ; yes, have to quote it...
gtch4c:    mov    a,d        ; no. get character back again.

[Ed. Note - This fix will appear in the next release of CP/M-80
Kermit, which Charles is preparing.  It will include other fixes,
various improvements, but most important it will have the long
heralded modular reorganization.  Anyone with items to add or fix in
KERMIT-80 3.9 should hold off until this new release appears.]

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

End of Info-Kermit Digest
*************************
-------
 1-Jun-84 17:32:10-EDT,9297;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 1 Jun 84 17:31:47 EDT
Date: Fri 1 Jun 84 17:30:12-EDT
From: Frank da Cruz <CC.FDC@CUCS20>
Subject: Info-Kermit Digest V1 #4
To: Info-Kermit: ;
Reply-To: Info-Kermit@COLUMBIA-20

Info-Kermit Digest        Friday, 1 June 1984      Volume 1 : Number 4

Today's Topics:
                  Several Major New KERMIT Releases
                      DEC VAX/VMS KERMIT 3.0.051
                      DEC TOPS-10 KERMIT 3(124)
                   DEC Professional-350 KERMIT 1.0
                     Commercial KERMIT Guidelines

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

Date: Fri 1 Jun 84 13:15:33-EDT
From: Frank da Cruz <CC.FDC@COLUMBIA-20>
Subject: Several Major New KERMIT Releases
To: Info-Kermit

Nick Bush and Bob McQueen of Stevens Institute of Technology have released
several new KERMITs.  New versions of VAX/VMS and TOPS-10 KERMIT include
major improvements in server operation and other areas.  And there is an
entirely new implementation of KERMIT for the DEC Pro-350.  These are
described in the next three messages.

The three new Stevens KERMITs share their system-independent portions,
which are generated from common modules written in BLISS, DEC's
"implementation Language".  Therefore, the descriptions and capabilities
of these three programs will be very similar.  It should be noted that you
don't need to have BLISS in order to run these programs.  MACRO source
files are generated from the BLISS for the PDP-10, VAX, and Pro-350, and
hexified binaries are also supplied in some cases.  The KERMIT User Guide
chapters for these systems are not quite ready, but should be available
soon.

Since the files for the Pro-350 all begin with the prefix "PRO", the
KERMIT Protocol Manual files have been renamed from KER:PROTO.* to
KER:KPROTO.*, and the User Guide from KER:USER.* to KER:KUSER.*, so that
the two appear together (at the end of the K's) in the distribution area
directory listing.

These three KERMIT implementations, along with the TOPS-20 and other
recent releases, will be available at the DECUS symposium in Cincinnati
next week on VAX/VMS and DEC-10/20 systems, so if you're attending, you
might want to bring a tape along.  In addition, new releases for RSX-11/M,
RSTS/E, and RT-11 will be arriving at DECUS in time to be included.  All
of these will also find their way onto the TOPS-10/20, VMS, and RSX DECUS
SIG tapes.

Meanwhile, the new files are all available in the usual manner using FTP
(ARPANET) or NFT (DECNET) or, after the files are moved, KERMSRV (BITNET).

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

Date: Fri 1 Jun 84 13:33:45-EDT
From: Nick Bush <G.BUSH@COLUMBIA-20>
Subject: DEC VAX/VMS KERMIT 3.0.051
To: Info-Kermit

New features and changes in VAX/VMS Kermit-32 3.0.051 are listed in detail
in the file KER:VMSV3.MEM.  Here is a brief summary:

 . "SET PROMPT xxx".

 . When running as a user Kermit  (i.e.,  talking  to  a  server),  it  is
   possible  to  access  all  of  the  generic  command  functions (REMOTE
   commands) that were specified in edition 4 of the protocol manual.

 . Improved local-mode operation (e.g. when dialed out over an autodialer);
   better performance, ^A status reports, ^D debugging toggle.

 . Logical name KER$COMM queried for default line at startup.

 . Kermit-32 will now type out its version number when it starts up.

 . Problems with IBM host communication have been fixed.

 . The file processing should now handle sending any type of file.
   Previously, VFC format files did not work, and certain records from PRN
   or FTN format files would cause infinite loops.

 . The format in which ASCII files are sent has been changed to correspond
   with both the protocol manual and everyone's expectations (instead of
   the way VMS defines things).  Each record from a file with implied
   CRLF's will be followed by a CRLF, not preceded by a LF and followed by
   a CR as VMS claims the records are supposed to be.

 . Kermit-32 will only abort a transfer on the controlling terminal line
   if two control-Y's are seen in sucession (without any other character
   or timeout in between).  This will keep a single glitch of a control-Y
   from killing a transfer.

 . There is a new file type - FIX.  This will cause Kermit-32 to create a
   512 byte fixed record length file.  This is useful for transferring
   .EXE or .TSK files.

 . The SET FILE_TYPE command has been changed to SET FILE TYPE.  This
   change was to allow for the addition of the SET FILE NAMING command
   (FULL, NORMAL_FORM, UNTRANSLATED).

 . Parity problems fixed.

 . The GET and RECEIVE commands are now different.  RECEIVE now allows the
   user to give the name into which the file is to be received.  This is
   the same as the RECEIVE command in Kermit-10 and Kermit-20, and
   conforms to the "standard" format for Kermit commands.

 . All messages output from the CONNECT command are identified by the node
   name of the system Kermit-32 is running on (the translation of
   SYS$NODE, if any).

 . Some new server functions have been added, some by spawning suprocesses
   with DCL commands.  The new functions includ COPY, CWD, DELETE,
   HELP, HOST, RENAME, SEND (a terminal message), SPACE (query), TYPE,
   WHO (show system).

 . The LOG command has been added to support log files for SESSION,
   TRANSACTION, and DEBUG.

 . There is now a PUSH command to spawn a new sub-process.

 . Sites which wish to enforce restrictions on  the  files  which  may  be
   transferred  with Kermit can now supply a routine which will validate a
   file specification.

The file KER:VMSV3.MEM gives greater detail about the new release, and lists
the component files and their functions.

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

Date: Fri 1 Jun 84 13:33:45-EDT
From: Nick Bush <G.BUSH@COLUMBIA-20>
Subject: DEC TOPS-10 KERMIT 3(124)
To: Info-Kermit

New features and changes in Kermit-10 version 3(124) are detailed in
the file KER:K10V3.MEM.  Many of them parallel the new VMS KERMIT.  A
few major changes are:

 . KERMIT-10 can now run on KI10 processors, KL-only instructions removed.
 . Correct operation on non-network (ANF-10) systems.
 . Server can do CWD, DELETE, DIRECTORY, HELP, SPACE, STATUS, and TYPE.
 . During local operation, send full range of commands to remote server.
 . Improved local operation.
 . TAKE command added.
 . DEFINE for SET macros as in KERMIT-20.
 . SET FILE BYTESIZE, NAMING, WARNING.
 . LOG SESSION, TRANSACTION, DEBUG
 . SET PROMPT
 . Bugs in wildcard processing fixed.

The new files are in KER:K10*.*.  KER:K10V3.MEM explains which files are which.

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

Date: Fri 1 Jun 84 13:33:45-EDT
From: Nick Bush <G.BUSH@COLUMBIA-20>
Subject: DEC Professional-350 KERMIT 1.0
To: Info-Kermit

Announcing the first release of KERMIT for the DEC Professional-350 PDP-11
based microcomputer running P/OS.  This version is based on the Common
BLISS modules that are used in Kermit-10 and VAX Kermit, so contains most
of the functionality of Kermit-10 and VAX Kermit.  The user interface is
menu driven in the P/OS style.  Pro/Kermit is not dependent on any Digital
product to do the communications, so Pro/Communications is not required to
run Pro/Kermit.  The following functionality is currently implemented in
Pro/Kermit:

 CONNECT (to host)
. GET (files from server)
. SEND (files)
. Commands for servers: LOGOUT, FINISH, BYE, TYPE, DIRECTORY,
   DISK (space), CHANGE (cwd), STATUS, HELP, HOST, COPY, RENAME, WHO
. Server operation: sends & receives files, honors remote commands like
   TYPE, FINISH/LOGOUT, etc.
. P/OS Services - Enter various P/OS services from Kermit.  These are the
         various services found in the main menu of P/OS.
. SET commands.  A full range of parameter setting is provided.

The files are in KER:PRO*.*.  KER:PROV1.MEM lists the files in detail,
including the files that are necessary in the bootstrapping procedure for
getting Pro-350 KERMIT initially from a mainframe to the Pro.

[Ed. Note - There is also a version of KERMIT for the P/OS, written in
DECUS C by Bob Denny.  We do not yet have this program in distributable
form.  Presumably the Stevens hexification & downloading procedures can be
applied to that program too.]

[Another note - Venturcom's Venix operating system will soon be announced
for the Pro-350.  Unix KERMIT runs adequately on that system, but
performance is very poor.  A new Unix KERMIT specially tailored for the
Pro-350 with Venix will be announced shortly.]

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

Date: Thu 31 May 84 19:42:28-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Commercial KERMIT Guidelines
To: Info-Kermit@CUCS20

I've been getting a lot of requests lately from hardware and software vendors
for permission to include KERMIT in their products.  I've written a new flyer
which I'm sending in response to these queries.  It's in KER:COMMER.DOC in
case anyone is interested in looking at it.

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

End of Info-Kermit Digest
*************************
-------
11-Jun-84 18:44:03-EDT,7483;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 11 Jun 84 18:43:15 EDT
Date: Mon 11 Jun 84 18:39:36-EDT
From: Frank da Cruz <CC.FDC@CUCS20>
Subject: Info-Kermit Digest V1 #5
To: Info-Kermit: ;
Reply-To: Info-Kermit@COLUMBIA-20

Info-Kermit Digest       Monday, 11 June 1984      Volume 1 : Number 5

Today's Topics:
                    Cray-1 Kermit Progress Report
                   Bug fixed in CP/M-80 Kermit 3.9
                 IBM-PC DOS Kermit Terminal Emulation
                      Cyber Kermit Document File
                     TRS-80 Kermit File Problems
                  Macintosh Kermit No-Progess Report

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

Date: 1 Jun 1984 21:09:40-MDT
From: Leah F. Miller C-10 <lfm@lanl>
To: cc.fdc@columbia-20
Subject: Cray Kermit

  Thanks for putting me in touch with Lila Chase at Livermore.
We have agreed that they will give our Cray Kermit (LANL's) a
friendly user tryout, probably next month. They were attempting
to port NOS Kermit to the Cray and finding it difficult because
of the very different character handling capabilities of the
2 machines. In return for this, we get the benefit of their
experience with Unix Kermit on the SUN PC.
  If all goes well, I expect to put Cray Kermit on general release
in late summer, at which time it will have been tested in
communication with at least 2 other Kermits.

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

Date: Wed 6 Jun 84 16:41:54-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Bug fixed in CP/M-80 Kermit 3.9
To: Info-Kermit@CUCS20

CP/M Kermit 3.9 has a serious bug.  When connected to another Kermit (such as
VAX/VMS or DEC-20 Kermit) that agrees to do 8th-bit quoting, but does not
explicitly request it (which is the normal case on communication lines where
the parity bit is not used), any ampersand in an outbound file will have a
spurious pound sign inserted before it.  A fix for this problem was posted
in a recent Info-Kermit digest by Charles Carvalho of ACC.  That fix has been
installed in Kermit-80, and new .HEX files have been built for most of the
systems supported by Kermit-80.  The fixed version is called 3.9A and the new
files are in:

KER:CPMBASE.M80        Source file
KER:CPMBASE.UPD        Update history
KER:CPMKERMIT.BWR    "Beware" file
KER:CPM*.HEX        New hex files, e.g. CPMKAYPRO.HEX, CPMAPPLE.HEX

These files are available in the usual manner from COLUMBIA-20 (ARPAnet) or
CU20B (DECnet).  Kermit-80 3.9A is a stopgap release until the new modularized
version 4 is released by Charles Carvalho.

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

Date: 10 Jun 84 13:46:42 EDT
From: D. M. Rosenblum <DR01@CMCCTE>
Subject: IBM-PC DOS KERMIT TERMINAL EMULATION
To: INFO-KERMIT@CUCS20

When I run IBM-PC Kermit version 1.19 (or C-MU's 1.19A) under DOS 2.0, I tell
the DEC-20 that I am talking to that my terminal type is VT52.  This works
fine.  Some of my friends here tell me that I can tell the 20 that my terminal
type is Zenith-19 (what you call H19 at Columbia), and I have even observed
such people running EMACS through their Kermits and getting things like inverse
video mode lines, use of line insert and line delete functions, and other such
things that Zenith-19s support but VT52s don't.  I know, however, that it can't
emulate every function of a Zenith-19, because it can't use the 25th line.  So
apparently it's emulating something in between a full Zenith-19 and a VT52.
What exactly is that something, i.e. what are the specs for what it is
emulating?

Also, if I am talking to VAX/VMS 3.5 (instead of a DEC-20) I find that there
are many VT52 functions that it cannot emulate.  For instance, SET TERMINAL
/INQUIRE doesn't work, and most of the screen handling of VAX/VMS EDT fails
badly (e.g. downward scrolling, among other things -- of course, the keypad
doesn't work for EDT either, but I have EDT customized to use control
characters for most of the stuff that's usually invoked by the keypad, a la
EMACS).  Could these things be made to work, or are there restrictions in DOS
that cannot be gotten around that explain why they aren't implemented?  Where,
in general, is the precise set of terminal capabilities that Kermit emulates
documented?

Thanks in advance.    -- Daniel M. Rosenblum, Ph.D. candidate, School of
               Urban and Public Affairs, Carnegie-Mellon Univ.

[Ed. Note -- The forthcoming release of MS DOS Kermit will address most of
these complaints.  It will do reverse line feeds and work with EDT on the
VAX.  The documentation will include a list of all the H/Z-19 control
codes showing which ones are supported by MS DOS Kermit.  There will be a
key redefinition facility so you can make the keypad or the functions keys
send anything you like.  I hope to be able to announce it this week.]

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

Date: Mon, 11 Jun 84 13:58:37 cdt
From: [e-mail]
Subject: Cyber Kermit document file

I have put together a .MSS file similar to the others referenced by
KUSER.MSS.  It is available via anonymous FTP from UT-NGP as file
170KERMIT.MSS.  I think for the most part it is formatted correctly.
You might want to take a look at it and check for yourself.

Jim Knutson
ARPA: knutson@ut-ngp
UUCP: {ihnp4,seismo,kpno,ctvax}!ut-sally!ut-ngp!knutson
Phone: [phone]

[Ed. Note -- It's available in KER:170KERMIT.DOC and .MSS on COLUMBIA-20
and CU20B, accessible via FTP and NFT, respectively.]

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

Date: Mon, 11 Jun 84 02:29:30 cdt
From: Stan Barber <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: TRS-80 Kermit File Problems

I have checked some of the code on Columbia-20 and some of the .SRC
files have missing tails.

<KERMIT>TRSMAKE.BAS is correct except for an error on my part.
Line 150 starts
150 ' some code
the ' needs to be removed before running the program.
Stan
sob@rice

[Ed. Note -- Actually, it appears that the *.SRC files are not missing
anything at the end; rather they have a ^Z and then some junk after the
end (sound familiar, CP/M fans?).  The TRSMAKE.BAS file has been
corrected, and the junk has been lopped off the end of TRS*.SRC.  The
TRS-80 I & III Kermit files are available in KER:TRS*.* on COLUMBIA-20
and CU20B.]

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

Date: Mon 11 Jun 84 18:26:34-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Macintosh Kermit No-Progess Report
To: Info-Kermit

In response to the many inquiries I've been getting about this...  We
(Columbia) are totally committed to writing Kermit for the Macintosh, and
probably also for the Lisa.  We're a member of the Apple University
Consortium, and we've submitted a proposal to Apple about adding Kermit as
one of Macterminal's protocols.  So far, no word back from Apple.  The
major hangup, however, is that Apple has been unable to deliver the Lisa II
development systems we have had on order for many, many months (we never
bought any Lisa I systems).  There may be some possibility of using the
SUMEX "sumacc" VAX-based cross development system instead of a Lisa, but
we don't yet have a system to run it on -- Eunice under VMS would be about
the best we could do, but we don't have Eunice yet...  More news as (if)
it develops...

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

End of Info-Kermit Digest
*************************
-------
15-Jun-84 13:16:07-EDT,14229;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 15 Jun 84 13:15:23 EDT
Date: Fri 15 Jun 84 13:12:45-EDT
From: Frank da Cruz <CC.FDC@CUCS20>
Subject: Info-Kermit-Digest V1 #6
To: Info-Kermit: ;
Reply-To: Info-Kermit@COLUMBIA-20

Info-Kermit Digest       Friday, 15 June 1984      Volume 1 : Number 6

Today's Topics:
                     New Kermits, How To Get Them
                     New Release of PDP-11 Kermit
                   New Software Tools Ratfor Kermit
                 New Version of Sirius MS DOS Kermit
                       CMS Kermit and Yale IUP
                       Kermit-80 Status Report
                         DEC-20 KERMIT Review
                          Telenet and Kermit

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

Date: Fri 15 Jun 84 12:00:00-EDT
From: Frank da Cruz <CC.FDC@COLUMBIA-20>
Subject: New Kermits, How To Get Them
To: Info-Kermit

This issue of the Info-Kermit digest contains announcements of several new
KERMITs.  For the benefit of those who are new to the Info-Kermit list,
and to refresh the memories of those who aren't, here's how to get the
KERMIT files:

ARPANET/Internet
  Use FTP, connect to host COLUMBIA-20, login as user ANONYMOUS with any
  non-null password, and GET (or MULTIPLE GET) the files you're interested
  in.  Anonymous FTP access to COLUMBIA-20 is allowed only after 6:00pm and
  before 6:00am.

CCNET (DECNET hosts at Columbia, CMU, CWRU, NYU, Stevens, and (soon) Vassar):
  Use NFT to COPY the desired files from CU20B::KER:.  If you're on a VAX,
  just use the COPY command.  Specify /USER:ANONYMOUS.  If CU20B does not
  grant you anonymous access, ask your system manager to get the files.

BITNET:
  On an IBM VM/CMS system, type the command SMSG RSCS MSG CUVMA KERMSRV HELP
  to get instructions for how to use the Kermit server at host CUVMA.  There
  is usually a delay between the announcement of a new version of Kermit and
  its availability on BITNET, because each file has to be painfully screened
  and possibly processed to fit the requirements of our RJE link.

Other networks like USENET, MAILNET, etc, or if you're not on a network:

  Send mail to Info-Kermit-Request@COLUMBIA-20, or to:

    KERMIT Distribution
    Columbia University Center for Computing Activities
    612 West 115th Street
    New York, N.Y.  10025

  and we'll send you flyers explaining how to order a distribution tape.

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

Date: Fri 15 Jun 84 11:57:22-EDT
From: Frank da Cruz
Subject: New Release of PDP-11 Kermit
To: Info-Kermit

Announcing version 2.16 of PDP-11 Kermit for RSX-11/M and M+, RSTS/E, and
now also RT-11, from Brian Nelson at the University of Toledo, Ohio.  The
major changes since the previous release (2.11, March 1984) include:

 Support for the RT-11 operating system (v4.0 or later)
. Performance improvements in both asynchronous and disk i/o
. Software controlled parity
. Support for half duplex communication
. Ability to transmit a BREAK signal
. Support for attribute packets, mainly for use between FILES-11 systems.
. Support for DECnet (RMS DAP) file access (added by Bob Denny).

Kermit-11 is probably the most advanced version of Kermit presently
available.  It implements practically every feature described in the 5th
edition of the protocol manual, including the full range of server file
management functions.

Although the RSTS and RSX versions use RMS for i/o, you do not have to
have RMS on your system in order to use it, and Kermit-11 does not have to
create RMS files as output.  The installation instructions explain how to
run Kermit-11 on non-RMS systems.

The files for all 3 operating systems are in KER:K11*.*.  There about 59
files, occupying a total of about 1760K (703 DEC-20 pages), so before
taking them all you should first look at KER:K11INS.DOC, the installation
notes, which describe in detail the exact prerequisites for installing or
running this program, and it may give you an idea of which files you might
not need.  A detailed list of changes to the program is in the file
KER:K11CMD.MAC.

The new help files for the program were inadvertently omitted from the
tape I received, but they should be available soon.  Meanwhile, Kermit-11
is very close to the "ideal" Kermit described in the main part of the 5th
edition Kermit User Guide.

This release will also be available on the Sring 84 RSX and other DECUS
SIG tapes.

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

Date: Mon, 11 Jun 84 14:41:37 pdt
From: Ken Poulton <[e-mail]>
To: [e-mail]
Subject: New ST Ratfor Kermit

Here is the latest Software Tools Ratfor Kermit.  I am sending you three
files: the formatted doc, the doc source, and the program source.  The
latter two are in ST 'archive' format; standard format for ST
distributions.

Any Software Tools implementor can install this rather simply on his/her
machine: the machine dependent parts are well flagged and few.  Further
versions will be forthcoming, but this should serve for anyone's initial
implementation.  Implementors should also pick up the standard user's and
protocol manuals.

Ken

[Ed. Note - The files are in KER:ST*.*.  It is configured for the Univac
1100 and the HP3000, and designed to be easily adapted to any other system
that has the Software Tools package, which must be present before you can
run it.  The file KER:STKERMIT.HLP tells more about the program, and also
how to get the Software Tools package.]

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

Date: 18-May-84
From: Barry Devlin, Computer Center, University College, Dublin
Subject: New Version of Sirius MS DOS Kermit

Here is a new version of Sirius MS-DOS Kermit.  I have merged it into
version 1.20 of the IBM PC Kermit, and have added a reasonable degree of
VT100 emulation.  Also, the bootstrapping method has been made to work for
the Sirius.  Considering the demise of the Victor in the U.S. and the much
greater popularity of the Sirius in Europe, I suggest we settle on the SIR
prefix for distribution.  VIC also has some Commodore implications.  I
have not made any attempt to update the CP/M-86 version for the Sirius
although I am aware of some problems in the area of end-of-file handling
and also in wildcarding.  When the Rainbow CP/M-86 version touches these
areas I hope to return to the problem.

[Ed. Note -- The new Sirius MS-DOS version is available as KER:SIR*.*.
The present CP/M-86 Kermit that runs on the Rainbow and NEC APC do handle
wildcards and eof correctly; Barry will receive a copy.]

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

Date: 18-May-84
From: Barry Devlin, Computer Center, University College, Dublin
Subject: CMS Kermit and Yale IUP

Here in U.C.D. we will be moving away from the beloved 2060 towards a more
IBM oriented computer centre.  However, the communications and terminal
base on campus will remain ASCII in character.  It is envisaged that the
Series-1 / Yale IUP with support for VT100s will continue to be the way of
supporting these terminals.  This means that Kermit for CMS is becoming
very important.  Is there a better version now available?  And what do you
think of the chances of running it through the Series-1?  We had a look at
the old CMS Kermit and felt it should be possible to use the transparent
Series-1 mode to do the packet transfer and perhaps full-screen mode
terminal emulation.  We would be interested to hear if anyone has done
anything about it.

[Ed. Note -- We will be working on CMS Kermit this summer, and making it
work with the Yale IUP is one of the areas we'll be investigating.]

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

Date: 13 Jun 1984 0106-PDT
From: Charles Carvalho <CHARLES at ACC>
Subject: Kermit-80 Status Report
To: CC.FDC at COLUMBIA-20
Cc: CHARLES@ACC

Hi.  I'll be away on vacation June 14-24, and my system is not portable
(besides, I would worry about getting sand in the floppy drive).

I sent version 4.00 to David Kirschbaum (abn.iscams@usc-isid); he's put
in support for his Decision I and the TAC trap code; meanwhile, I've
fixed some minor problems and added some documentation and produced v4.01.
We'll have to figure some way to get these two back together.  He also made
everything assemble under LASM, which we ought to be able to supply with
Kermit, it being public domain.  (He also uses MLOAD rather than DDT to
merge the two hex files).

The current delay is documentation.  I've got some very rough notes on
generating Kermits for supported systems, but nothing yet on how to add
support for a new system (which shouldn't be too hard, since there are
about 18 examples).  There's also about 25 Kbytes of notes on what I've
changed.
                        /Charles

[Ed. Note - For those who missed earlier announcements to this effect,
Charles is working on a new, modularized, version of Kermit for CP/M-80.]

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

Date: Thu 7 Jun 84 16:02:02-PDT
From: Ken Harrenstien <[e-mail]>
Subject: DEC-20 KERMIT Review
To: [e-mail]

 [Ed. Note - My comments are indented like this.]

OK, I've looked at the 5th edition stuff a bit and have the following
comments.  Most has to do with the TOPS-20 KERMIT.MAC program, version
4(215).

(1) It is extremely annoying to have a document file with 80 chars per
line.  Please make the default LPT versions something more reasonable
such as 72.  Not all printers can handle 80 chars, and for those which
can, it is nice to have SOME right margin for readability and notes.
NIC documents are limited to 72 chars per line for this reason.  Of
course this will make the documents a few pages longer, but the whole
point of documentation is to convey information in a way which is
clear and easily readable!

  [OK, next time thru the wringer, they'll come out narrower.]

(2) The protocol badly needs a "bare" control-char convention.  You
should define it NOW before various people (eg me) go off and
implement their own.  Of course it should be an option, but still it
should be provided.  A simple start would be an option bit that says
the program has complete control over all input and output -- in other
words, all characters can be sent and received, and you don't have to
pull your hair trying to figure out which ones are ok and which
aren't.

  [In fact, there's nothing in the protocol that says you HAVE to
  transmogrify all control characters.  You can stick bare ones into
  packets right now, and they'll come out correctly on the receiving end,
  provided you don't do this with SOH (Control-A, the normal
  start-of-packet marker), with the XON or XOFF characters if XON/XOFF is
  being done, etc.  However, watch out for the case when both hosts THINK
  they know which control characters they can handle but some piece of
  communication equipment that's somewhere between them knows otherwise.
  Anyway, you're right, this needs more thought.]

(3) KERMIT-20 GET doesn't provide any way to specify different local
filenames (such as RECEIVE and SEND do).  It should.

(4) KERMIT-20 is screwed up after a ^Z or ^X -- SEND complains "no
files to send" even when an argument is specified!  They don't appear
to actually abort a file transfer, either... even when SENDing the file!

(5) KERMIT-20 GET can't get a filespec starting with "!" because that
is the TOPS-20 comment character.  It doesn't help very much to
quote it because the resulting filename is almost certainly going to
be highly unusual, if not illegal -- this because of the problem above
where you can't specify the local filename.

(6) KERMIT-20 has this incredibly brain damaged misfeature where it
quietly turns off the receive-link bit for the user's terminal, and
leaves it off!  I can understand this while it is in SERVER mode, but not
local mode!!!  There is absolutely no justification for refusing links
in local mode -- that should be up to the user, who determines this
with EXEC commands.

(7) TTLINK doesn't appear to ever actually set the terminal speed
to what was specified.  This is a pain because often outgoing lines are
set to speed 0 to prevent noise problems, and hooking up to one with
TTLINK isn't going to do anything (whether or not a speed is specified)
until you realize what is going on (50 points for intuitive flash) and
manually clobber it with ^ESET TER n SPE.  There doesn't seem to be a
good way to pass parameters like SPEED from KERMIT-20 to TTLINK by the
way.

That seems to be all that was on my list at the moment.

  [I'll look at all the Kermit-20 and TTLINK complaints as soon as I
  get a chance.]

Oh!  One other thing I remembered.  TTLINK or KERMIT (I suspect the former)
sends a CR every time you start or resume a connection.  This is
very bad, because sometimes the first char you send should be a
special auto-baud speed set char, and CR is not always the right thing.
Also, during a connection, this makes it extremely annoying if the other
end is talking to a text editor -- you get CR's inserted -- or if the
other end is awaiting some test input such as a filename (CR sets it going
with defaults that you DON'T want!).  Grumble, grumble.  This is a pretty
serious misfeature, I'd say.  I don't see any good reason for it at all.

  [TELNET does this too.  Can anybody think of any undesired consequences
  of removing this behavior?]

--Ken

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

Date: 14 Jun 84 09:46:30 EDT
From: RC0T@CMU-CC-TE <RC0T@CMCCTE>
To: info-kermit@CUCS20
Subject: Telenet and Kermit

We are part of the Telenet network. But if users use Kermit on their PCs
and then connect through Telenet the sending and receiving of files fails
immediately. Would you have any suggestions as to why this is happening?
Thanks.

Rick Costa
User Services

[Ed. Note - I've used KERMIT over TELENET successfully by giving the command
SET PARITY MARK to the Kermits on both ends.]

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

End of Info-Kermit Digest
*************************
-------
18-Jun-84 18:41:28-EDT,5756;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 18 Jun 84 18:41:13 EDT
Date: Mon 18 Jun 84 18:32:08-EDT
From: Frank da Cruz <CC.FDC@CUCS20>
Subject: Info-Kermit Digest V1 #7
To: Info-Kermit: ;
Reply-To: Info-Kermit@COLUMBIA-20

Info-Kermit Digest       Monday, 18 June 1984      Volume 1 : Number 7

Today's Topics:
                    Dialup Access to Kermit Files
                    Looking for Kermit for Pick OS
                           Coco Os9 kermit
                          Kermit On Telenet
                         Cray Kermit Progress

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

Date: 15 Jun 1984 1753-EDT
From: B.Eiben LCG <EIBEN at DEC-MARLBORO>
To: Info-Kermit at COLUMBIA-20
Subject: Dialup Access to Kermit Files

You might want to stick us in too: DEC-Marlboro
                    617-467-7437 (300 / 1200 Baud)
                    two Control-C's
                    LOG LCG.KERMIT KERMIT

                    distribution area is KERMIT:

It's a public account - and has been "pushed" in DECUS and otherwise - to
my knowledge the "only" way to get KERMIT via "Ma Bell" without any other
"special connections".

[Ed. Note -- That's Digital Equipment Corporation, Marlboro,
Massachusetts, USA.  The machine is a DECSYSTEM-20.  Thanks, Bernie!]

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

Date: Fri, 15 Jun 84 11:21:18 pdt
From: Ken Poulton <[e-mail]>
To: [e-mail]
Subject: Looking for Kermit for Pick OS

Does anyone know of a Kermit for the Pick operating system?
Failing that, how about a Kermit written in Basic?

[Ed. Note -- I haven't heard of anyone working on Kermit for Pick, but
there is a Basic implementation for a Swedish micro, the Luxor ABC-800,
in KER:800*.*.  I've been told that it's a rather unusual dialect of
Basic.]

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

Date: Sat 16 Jun 84 00:32:53-PDT
From: Bob Larson <[e-mail]>
Subject: Coco Os9 kermit
To: [e-mail]

I am listed with Good intentions of implementing Trs-80 Color computer
Kermit in an unknown language for an unknown operating system.
I have good intintions of implementing os9 kermit in (microware) C on
my color computer.  Due to os9 doing a very good job of insulating the
user from piculuarities of hardware, it is my belief (and hope) that
this implementation could be run on any 6809 os9 system.  (There is also
a version of os9 for the 68k, I can't tell how easy it would be it convert
to it.)
   There is also someone listed with good intentions of doing a kermit for
a swtp system.  Do you you know what operating system he is using?
   Also note that they have changed my user name from Larson@Usc-Eclb to
Blarson@Usc-Eclb.  (They decided to make user names unique on all Usc-Ecl
systems.)
Bob Larson <Blarson@Usc-eclb>

[Ed. Note - The SWTPc system is running FLEX.  I added this and your info
to KER:VERSIONS.DOC.]

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

Date: Sun 17 Jun 84 20:53:50-PDT
From: Doug Brutlag <[e-mail]>
Subject: KERMIT ON TELENET
To: [e-mail], [e-mail]

Frank,

    Another way to get KERMIT to transfer files on TELENET is to
configure TELENET to transmit the eighth bit.  Most TELENET nodes are
set up for 7 bit communications only.  You can set up eight bit mode, by
connecting to your host, then escape back to TELENET (with cr @ cr) and
giving the command:

SET? 0:33,63:0

    The 0:33 parameter allows you to set certain ITI parameters
normally not used by TELENET users.  The ITI parameter 63 enables the
eighth bit when set to 0 (contrary to what is written in the TELENET
documentation by the way).  I have found this setting useful for both
KERMIT file transfers and for using a terminal with a META key for
setting the eighth bit for EMACS editing commands.  If this fails you
should call the TELENET 800 number to find out how to allow eight bit
communications for your node.  SOme nodes use old TELENET protocols
which require setting parameter 57:1 as well.  If you have many people
using KERMIT via TELENET you can have your TELENET representative change
your local node to make the default setting of parameter 63 be 0.

    By the way I do not encourage people to use KERMIT via TELENET
because of the delay in receiving the ACK/NAK.  Even with an unloaded
network and 1200 baud nodes at either end, the delay in receiving the
ACK/NAK effectively lowers the transmission speed from 1200 baud to less
than 300 baud.

Doug Brutlag

[Ed. Note - We will try to work out a "sliding window" option for the
Kermit protocol over the summer.  This should speed things up a bit,
assuming it can be widely implemented.]

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

Date: 18 Jun 1984 14:24:02-MDT
From: Leah F. Miller C-10 <lfm@lanl>
To: cc.fdc@COLUMBIA-20
Subject: Cray Kermit Progress

  We have a portable pre-release Kermit up and running on both the
Cray-1 and the Cray X-MP. It runs under the CTSS (Cray Time Sharing
System) operating system which was developed at Livermore and is
fairly widely used at gov't laboratories.  I think, however, that
anyone wishing to port it to a COS (the batch OS provided by CRI)
system would find this a matter of replacing a few low-level
subroutines.
  As of today Cray Kermit has been tested only in communication
with one partner, Kermit-86 on the IBM-PC, and in one environ-
ment, the LANL network. Therefore, estimated general release
date remains "late summer".
  Enjoyed your article in Byte and look forward to Part 2 !

Leah Miller

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

End of Info-Kermit Digest
*************************
-------
20-Jun-84 11:20:19-EDT,12638;000000000001
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 20 Jun 84 11:19:31 EDT
Date: Wed 20 Jun 84 11:15:26-EDT
From: Frank da Cruz <CC.FDC@CUCS20>
Subject: Info-Kermit Digest V1 #8
To: Info-Kermit: ;
Reply-To: Info-Kermit@COLUMBIA-20

Info-Kermit Digest     Wednesday, 20 June 1984     Volume 1 : Number 8

Today's Topics:
                     Control-Character Prefixing
    Performance of Kermit over Packet Networks (several messages)
              Server Mode for Micros (several messages)
                      BLAST - KERMIT Lookalike?

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

Date: Mon, 18 Jun 84 14:17:20 pdt
From: Ken Poulton <[e-mail]>
To: [e-mail]
Subject: Control-Character Prefixing

I'm not convinced as to the need for sending "bare" control
characters.  This is one of the beuties of Kermit!  You don't *have* to
worry about who cares about what control characters.  Defining a bit for
"I can take anything without control quoting" is an easy first step, but
anything beyond that would probably add several pages to the protocol
manual which are almost never implemented.

Most of all, though, I don't see any motivation.  Text files contain
only a small percentage of control characters, so there's little
need for efficiency's sake.  Binary files do incur a 25% overhead
due to control quoting, but they incur an additional 50% overhead
due to eighth-bit quoting.  So... why bother?

 [Ed. - Actually, a 25% improvement is nothing to sneeze at.  Also, the
 50% overhead for 8th-bit quoting only occurs over 7-bit channels; most
 Kermit connections are 8-bit, so they don't get this overhead.
 Therefore, the control-character prefixing dominates.  The trouble is,
 you're just not safe eliminating it unless you have a hardwired
 connection whose characterstics are fully known.  Also, not only will it
 add pages to the manual, but it'll add startup overhead, translate tables
 to the program, etc.  But it's still worth looking into.]

Is anyone thinking about a better binary encoding?
It would be nice to use something like the Unix uuencode's 4-bytes-for-3
translation to cut down on the overhead for binaries.
Seems like a way to specify record breaks would be nice,
so as to accomodate those arcane systems (IBM + HP3000, f'rinstance)
that have such things as variable record size binary files.

 [Ed. - We're encoding the new MS-DOS Kermit binaries with 4-for-3, and
 also collapsing adjacent 0 bytes.  We find the result to be smaller than
 the .EXE file itself.  All this will be announced soon.  With Kermit
 attribute packets (unimplemented anywhere except in the PDP-11 versions)
 it is possible to specify the encoding, so certainly 4-for-3 could be
 one of the alternatives.  There's also an attribute that specifies that
 the file is composed of arbitrary records preceded by length fields.]

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

Date: Mon, 18 Jun 84 17:04:55 pdt
From: Ken Poulton <[e-mail]>
To: [e-mail]
Subject: increasing kermit throughput on long-distance lines

We have an interest in using kermit for file transfer
over long lines and packet networks, where the roundtrip
delay may reach several seconds.  Clearly, several
seconds of delay causes some severe throughput problems
with kermit's packet-acknowledge protocol.

In the current protocol manual, under "Unresolved Issues",
mention is made of a "floating window" scheme:
send a bunch of packets and then wait for acknowledgement;
ack for packet N implies ack for all packets < N.

It occurs to me that this could be implemented with nothing more
than some buffering on the sender's side.  No negotiation
is required; the sender must simply be sure that
the number of packets he sends at one time does not exceed
the number of nak's the receiver will send before
quitting (the receive retry limit).

Has anyone tried this?  Does anyone see a hole in my reasoning?

 [Ed. - I think there's got to be some agreement between the two
 sides.  Retries are used to recover from errors, and the same counter
 shouldn't be used to count two different things.  Anyway, there
 has been a lot of talk about adding this to Kermit (see next message
 for another example), and it should be carefully considered.]

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

From: ihnp4!sask!derek@Berkeley
Date: 18 Jun 84 13:58:45 CDT (Mon)
To: [e-mail]
Subject: a plea

First, let me say that the work you are doing with Kermit is fantastic.
It is really a wonderful package unselfishly contributed to the world.

Now, let me ask for a favour.  Presently, the maximum packet size is 80
characters.  I implore you to consider allowing it to be 256 characters.

In Canada, we have a network called Datapac.  It is similar to Telenet.
It is a packet switched network allowing packets to be a maximum of 256
characters.  It costs the same to send a 1 byte packet as it does to send
one of 80 or 256 characters.  Allowing Kermit to send 256 byte lines
would keep the cost of Datapac connections down.

Is it too late to try to incorporate this into the standard?  I would
hate to make a change to Kermit to allow this only to be incompatable
with the myriad of Kermits out there.

Thank you for your time.

Derek Andrew
U of Saskatchewan (Canada)
Arpanet: "sask!derek"@utah-cs

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

Date: Wed 20 Jun 84 09:56:07-EDT
From: Frank da Cruz <[e-mail]>
Subject: Re: a plea

Actually, the maximum Kermit packet length is 96.  This is not an
arbitrary number, but rather a consequence of the fact that the length
field is encoded as a single printable character, of which ASCII has 94
(the length field does not include the SOH or the length itself).  We
designed it this way on purpose, because we found that other protocols
that used longer packets (especially fixed length longer packets) would
not work with certain popular systems that had trouble receiving 256 or
128 characters at once.  By making it impossible for anyone to write a
Kermit that would "overload" any other Kermit, we have kept the protocol
more generally useful.

I agree, however, that the performance is not what it could be.  For
applications in which you know the characteristics of the communication
medium and the two systems involved, you would like to get more
throughput.  This can be done by either lengthening the packets, or
allowing multiple packets to be sent in a stream.  Longer packets incur a
higher cost in retransmission overhead, and would require use of CRC for
error detection, as the current 6-bit checksum would be pretty inadequate
for a 200 (or 1000) character packet.  A stream of packets (the "floating
window" technique) would achieve the same effect, but would work less than
optimally on half duplex connections.

Incidentally, it would be relatively easy to extend the packet length.
Since the length field always includes the type and block check fields, it
can never be less than 3.  Therefore, values of 0, 1, or 2 could be set
aside for special uses.  For instance, 0 could mean that the first 2 (or 3
or 4) characters of the data field were an extended length field.  The
ability of a Kermit program to handle this would be flagged in the
Send-Init capabilities mask, and corresponding special values would
also have to be used in the MAXL field of the Send-Init.

We are looking at the possibility of adding both these options to the
Kermit protocol, but bear in mind that adding things to the protocol
specification and getting them into 50 or 60 implementations are two
different things.

- Frank

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

Date: 18 Jun 1984 23:00-EDT
Subject: pc server code
From: [e-mail]
To: [e-mail]

Have there been any personal computer KERMITS which include
server functions besides Herm Fischer's (excellent!)  additions
to the IBM-PC version?  I am curious to see if the "other end" of
the line code has been done for KERMIT in the same manner as
XMODEM vs.  MODEM7, particularly for CP/M systems acting as
bulletin boards or public domain software distribution points.
mike seyfrit <polaris@usc-isi>

 [Ed. - The forthcoming MS-DOS Kermit release will incorporate Herm's
 server code.  See below for more on this subject.]

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

Date: Tue 19 Jun 84 19:56:16-PDT
From: William Pearson <[e-mail]>
Subject: CPM kermit
To: [e-mail]

    I have just set up Kermit on our VAX, IBM-PC and Heath 89 and am
very impressed, particularly with its batch capability.  I would like to
have a version for a CP/M computer that would have a server mode, so
that after I dial up my Heath using BYE (for remote login with password)
and then upload or download from a remote kermit.

    I could also use a version for a NorthStar Advantage.

    I would have no problem making these modifications myself, but
a 175K source file is a little beyond my capacity.  I wonder if
1) you know of some way to recompile on a VAX/VMS system (using
public domain assembler perhaps) or 2) if you have an uncommented
version which is smaller, along with comments where actual i/o is done
or 3) a modular version with overlays.  (But I suspect that won't
help the server mode).

     Bill Pearson
    Pearson@sumex-aim

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

Date: Wed 20 Jun 84 10:09:31-EDT
From: Frank da Cruz <[e-mail]>
Subject: Re: CPM kermit
To: [e-mail]

The lack of remote, unattended access for CP/M Kermit has long been one of
its shortcomings, and accounts for Kermit's relative disuse on the RBBS
systems.

Charles Carvalho at ACC (CHARLES@ACC) is working on a modularized version
of CP/M-80 Kermit.  This should solve the size problem nicely, allowing
you to work on more manageable chunks at a time.  It should also let you
easily add support for the North Star, and there's always room for a
server module.

- Frank

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

Date: 19 Jun 1984 08:48-EDT
Subject: BLAST - KERMIT Lookalike?
From: [e-mail]
To: [e-mail]

Frank,

Just got some literature on a file transfer program called BLAST that's
VERY reminiscent of KERMIT (adjustable packet sizes, CRC, sliding window
pipelining (isn't that coming this summer?), system-unique file conversion,
8-bit prefixing, settable parity and baud, no master-slave restrictions,
log/status, remote site error condition reporting, etc.  Has some things
I haven't seen in KERMIT (yet), and some I've seen in MDM730 (programmable
function keys, delay between characters, send logon, and a bunch of remote
system command executions).

They have versions for about a hundred different micros, minis, and
mainframes, to include the big Data General machines, PDP-11s,
HP3000s, Honeywell DPS-8s, IBM 360s (no Cray).

Might almost be worth while getting, just to see some of the things they
did.  NOT to pirate the code, just to see how!  (A little backward
engineering, my friends??)

Source is Communications Research Group
          8939 Jefferson Hwy
          Baton Rouge Louisiana  70809
          [phone]

Costs run from $250 for micros to several thousand for the mainframes.
Cheapest is $100 for Compaq and IBM PCs, running PC-D200EM OS (what's that?).

Just for your info.
Regards,
David Kirschbaum
Toad Hall
ABN.ISCAMS@USC-ISID

[Ed. - Actually, BLAST has been around for some time.  I don't know much
about it, but it's probably a lot like Kermit in its capabilities,
probably superior in many areas.  It's only one of many, many Kermit-like
commercial products.  They all have their strong and weak points.  The
commercial products are generally stronger in the area of modem control,
login scripts (built-in options for talking to Dow-Jones, The Source,
etc), etc, and they usually have jazzy function-key menu-driven user
interfaces.  Kermit, on the other hand, tends to run on more different
kinds of systems more consistently than most commercial products, comes
with sources and internal as well as user documentation, invites users to
write versions for new sytems, and the price is right...  But I don't
doubt that Kermit and the commercial products influence each other.]

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

End of Info-Kermit Digest
*************************
-------
22-Jun-84 18:24:13-EDT,15616;000000000001
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 22 Jun 84 18:23:37 EDT
Date: Fri 22 Jun 84 18:18:50-EDT
From: Frank da Cruz <CC.FDC@CUCS20>
Subject: Info-Kermit Digest V1 #9
To: Info-Kermit: ;
Reply-To: Info-Kermit@COLUMBIA-20

Info-Kermit Digest       Friday, 22 June 1984       Volume 1 : Number 9

Today's Topics:
                   Macintosh Kermit Progress Report
               Unix Kermit Problems (several messages)
                           Kermit Comments
                      Current Kermit for IBM PC?
                    Control Characters in Packets
             Micro-Host Transfer Software Recommendation?
                 Comparing Kermit with Other Packages

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

Date: Thu 21 Jun 84 18:19:34-EDT
From: Frank da Cruz <[e-mail]>
Subject: Macintosh Kermit Progress Report
To: Info-Kermit@CUCS20, [e-mail]

Columbia has finally received its Lisa-2/10 development system, though we
haven't actually tried to use it yet for Mac development yet (we just
unpacked it).

We had a rudimentary, receive-only adaptation of Unix Kermit running on
the Mac briefly, bootstrapped with the Sumacc cross development package.
This was painful to do, and only worked once for some reason.  We may
pursue this avenue, or give it up if the Lisa proves to be easier to deal
with.

We submitted a proposal to Apple 2 months ago to add Kermit as one of the
file transfer protocols supported by MacTerminal.  We haven't had a
response yet.  Meanwhile, a review of MacTerminal in the current
(July/August 1984) issue of Macworld compares Kermit favorably to the
XMODEM protocol that is already in MacTerminal (p.69).  I hope someone at
Apple reads the review.

What does all this add up to?  We'll produce a Kermit for the Mac one way
or another.  We'd prefer to see it as an option in MacTerminal, since that's
the natural place to put it, but failing that we'll do a standalone version.
Anyway, at least now we can start.

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

Date: Wed, 20 Jun 84 10:11:26 edt
From: cu-arpa.tesla![e-mail] (Christopher Pottle)
To: cornell![e-mail]
Subject: IBMPC-Unix Kermit Problem

This problem may be well known, but I am a newcomer. With what
I believe to be the latest versions of Kermit for the IBMPC
(1.20) and for Vax-Unix (ca. 2/84), the IBMPC hangs with
the Waiting... message after sending a file to Unix. One
can interrupt out and reconnect, and will find the file safe
and sound on the Unix machine. Is this bug known to you?

[Ed. - Many Unix Kermit users have reported this problem, and I
haven't seen a good solution yet.  I'm not a Unix expert, but as I
understand it, Unix does most things by putting them on lists of
things to do.  When you tell Unix to send a packet, it goes out when
Unix gets around to it.  However, having sent its last packet, an ACK
for the PC's "I'm all done" packet, Unix Kermit then restores the TTY
to "cooked mode" and exits.  This apparently happens immediately, and
interferes with the transmission of that last packet, which is still
waiting on a list somewhere.  A workaround would be for Unix Kermit,
after returning from the protocol, to sleep for a second or two before
restoring the line.]

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

Date: Thu, 21 Jun 84 08:17 PDT
From: "Chase Lila"@LLL-MFE.ARPA
Subject: UNIX Kermit
To: [e-mail]

Frank,
     There is a definite problem with UNIX Kermit on our Sun's with
Berkeley UNIX 4.2.  The phone is hung up or disconnected upon the
second call to open the tty line.  It had worked with the previous
version of UNIX only by luck.  I have been told it is hazardous to
open the line, exit kermit and open it again upon another invocation
of Kermit.  Better to have just one invocation.  To do this quickly,
simply replace if (cflg) by if (!remote) before the connect call.
execution then becomes:
     kermit slb /dev/ttya 1200 filename    (locally)
     kermit r                              (remote)
Evidently this problem does not happen over hardwire connections
(Bob Cattani says).
                                       Lila Chase [phone]
                                       chase@LLL-MFE
------------------------------

Date: Thursday, 21 Jun 1984 14:21-PDT
To: [e-mail]
Cc: [e-mail]
Subject: unix kermit
From: [e-mail]

Having discovered that cu loses characters at 9600 baud, I tried to
bring up Unix kermit on a Callan Unistar 200 running Unisoft System V
Unix. It did not compile since TANDEM and FIONREAD are not defined in
<sgtty.h> in Unisoft system V and simple fixes do not work. The baud
rate is set incorrectly and even if set correctly & ixoff set via
stty, Kermit still gets no response from a known functional VAX Kermit
(& it seems to keep sending garbage to the Vax). Does anyone have an
idea of a way to fix this without drastic rewrites?

reply to gray@su-dsn

[Ed. - System V support has been added to Kermit, along with support
for some of the more arcane versions of Unix.  We have perhaps 15 or
20 Unix Kermit contributions waiting to be reconciled with one another.
Unix Kermit will be one of our next projects, as soon as we finish the
new release of MS-DOS Kermit next week(?).  We aim to have a very
portable, modular, C-based version of Kermit, providing the full-blown
protocol, with support for the various versions of Unix plus some
other systems that have C compilers and Unix-like runtime support.
Any systems not explicitly supported by all this should be easily
adapted by filling in the appropriate i/o primitives.]

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

Date: Wed 20 Jun 84 19:56:33-PDT
From: scott <[e-mail]>
Subject: kermit comments
To: [e-mail]

  i thought your recent byte article did a good job of illustrating the
problems of designing a universal ftp.  it looks like your second article
won't talk about the sociology of kermit development (the distributed
development with columbia coordination via national networks), or the vast
number of available implementations.  was that because you were worried
about being inundated with requests?
   i would hope that your tentative plans for developing a sliding window
protocol would include the option to operate full duplex when available,
but now that i read the byte article i realize that i hadn't thought about
the echoing problem...can't most OS's turn off echoing?

[Ed. - It's too late to worry about being inundated with requests...
we're getting 5-10 tape requests per day!  The second part of the BYTE
article, which appears July 1, tells readers how to get Kermit.  We're
beginning fortification of the mail room now...]

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

Date: Thu, 21 Jun 84 01:05:07 pdt
From: System Mom - root <[e-mail]>
Subject: Current Kermit for IBM PC?

I would like to inquire about the current version of Kermit for the IBM PC.
Sorry, it's late.  What I meant to say is, when is the next version coming
out, how can I get it, and what is the current version number?  I have 1.3A
and have previously asked this question, but have received no reply.  I can
(hopefully) be reached at ..!hplabs!hplabsb!fujinaka.  I don't know how
else.  So much for 2 years at MIT.

Thank you.

Todd Fujinaka

[Ed. - So much for xxx years at Columbia -- I don't know how to reply...
Anyway, I hope we'll have a field test release of the new MS-DOS Kermit
at least for the IBM PC & XT next week.  1.3A is ancient; the current
release, since last October, has been 1.20.  The new release will be
called 2.26.]

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

Date: Wed 20 Jun 84 19:44:13-PDT
From: Bob Larson <[e-mail]>
Subject: Re: Control Characters in packets
To: [e-mail]

Unquoted control characters should not be allowed in kermit without
specific negotiation.  The current prime kermit will NOT allow unquoted
CR or LF.  (It is not feasible on the prime to not quote linefeed... they
are eaten by primos before any user program can get them (including EMACS))

I recommend that any control character in a packet be considered an error,
and a NAK packet sent immediately.  This would catch some errors that are
only handled by timeouts now.

Bob Larson <Blarson@Usc-eclb>

[Ed. - The whole area of performance, including bare control characters,
long packets, sliding windows, full duplex, deserves - and will get - a
lot of thought.  Contribution welcome!]

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

Date: 19 Jun 84 12:23 +0200
From: [e-mail]
To: [e-mail]
Subject: Micro-host transfer software recommendation

The universities of the Netherlands, technological as well as other,
formed a committee for the recommendation of a file tranfer
protocol between micro and mainframes of all dutch universities.
Although all of the members had heard of KERMIT, some of them even had
some experience with it, the committee started to set up a list of
requirements for such a protocol. Together with KERMIT there are
two other candidates, both commercial packages. Although KERMIT is
the most likely candidate, I, as a member of the committee, would like
to know if someone has experience with non-private packages other
than KERMIT. In concrete:
What can KERMIT do that these packages cannot and what can these packages
do that KERMIT cannot?
                       May the best win, Edgar.

[Ed. - That's a tall order; I'll give it a try below.  Other replies
are welcome, too.]

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

Date: Fri 22 Jun 84 18:19:34-EDT
From: Frank da Cruz <[e-mail]>
Subject: Comparing Kermit with Other Packages
To: Info-Kermit@COLUMBIA-20

First let me say that there seem to be two major kinds of commercial
packages: the kind that use some variation of MODEM protocol, and the kind
that use their own proprietary protocols.  First, MODEM (please, any MODEM
aficionados feel free to correct any of this)...

MODEM and Kermit are similar in that they both use back-and-forth
ACK/NAK protocols over asynchronous telecommunication lines.  However,
MODEM sends fixed-length packets with 128 8-bit data bytes, KERMIT sends
variable length packets (up to 96 characters in length) with either 7- or
8-bit data bytes.  The MODEM packet control fields use all 8 bits; Kermit
control fields only use 7.  There are several consequences of all this:

 MODEM can't work at all over a 7-bit channel, even for text files, because
  the checksum and other control fields will be wrong.  This means that
  MODEM can't be used over public packet-switched networks like TELENET,
  or with hosts that require use of character parity, like IBM mainframes.
  Kermit can send both text and binary files over either 7-bit channels
  or 8-bit channels, but the data gets longer if you have to squeeze it
  through a narrower hole.

 Certain computing or communication equipment cannot accept 128 characters
  at a time.  Their buffers aren't that big.  Kermit can accommodate these
  systems, but MODEM cannot.

 Many systems cannot accept all ASCII characters, particularly control
  characters, transparently (see the message about PRIME above for one of
  many possible examples).  MODEM provides no mechanism for encoding
  otherwise taboo characters.

 Non-CPM systems, which do not necessarily allocate files in units of 128
  bytes or follow the CTRL-Z end-of-file convention, will often have junk
  at the end of a file received by MODEM.

MODEM, to the best of my knowledge, does not have a good mechanism for
transmitting a group of files; Kermit has it built into the protocol.
Kermit protocol also includes optional features for management of remote
files -- directory listings, file deletion, quota checking, etc.  Many of
the Kermit programs support these optional features.

MODEM sends the file bytes exactly as is, whereas Kermit gives you some
options for reformatting and compressing.  A "text" file is transformed to
"canonical form" by Kermit, i.e. a stream of ASCII characters with the
"records" (lines) separated by (encoded) CR/LF sequences, so that it may be
stored in useful form on the target system.  Thus, Kermit may be used on
record-oriented systems (like IBM VM/CMS) or on stream-oriented systems like
Unix where there record boundaries may be different (LF instead of CRLF);
Kermits on those systems that don't store text files in the canonical manner
do the appropriate conversions.  In addition, Kermit may also be told to
send files as-is.

On the other hand, MODEM works nicely between like systems (especially CP/M
systems) -- it's more efficient than Kermit because it doesn't have to
encode and decode the data, and the packets are somewhat longer.  Also, much
greater attention has been given in MODEM programs to modems themselves, and
MODEM programs are typically able to control dialout modems from various
manufacturers, and to run in "remote mode" when dialed up from the "back
port" of a micro (but the forthcoming MS-DOS Kermit will have this ability
also).  MODEM provides the ability to dynamically switch between 8-bit and
16-bit block checks depending on the error rate; KERMIT provides 6, 12, and
16 bit block checks, but one of these must be selected ahead of time and
will be used throughout the transfer.

There's more, but in short I think that, on balance, Kermit is more
flexible and more easily adaptable to new systems; hence its rapid
spread to a wide variety of micros, minis, and mainframes.

Now, as to commercial packages with proprietary protocols -- well, who
knows?  In some cases, these protocols may be superior to Kermit in every
way.  But you have certain problems with any commercial package:

 Are implementations available for all the systems you want them for?
  If not, will the vendor write the missing implementations?  When?
  For how much money?

 Does the protocol make assumptions (like full duplex communication,
  8-bit data path) that would lock out certain classes of systems?

 Do you have enough money to buy the software licenses for your mainframes
  and each and every one of your micros?  Some sites have thousands of
  micros.  A typical commercial file transfer package costs $500-$5000
  dollars for the mainframe end and $50-$500 for each micro.

 Can your vendor fix bugs in a timely fashion?  If you had sources, you
  could fix them yourself, but most vendors don't provide sources.

Many commercial packages are very fancy, both in the protocol and the user
interface.  But they often tend to be specially tailored to a certain
combination of systems and/or applications.  Kermit is not as fancy as a
commercial product that knows how to dial up Dow-Jones and look up your
stocks, reformat the data as it comes in, and display it in a color pie
chart, all upon a single keystroke.  But then that package probably can't
exchange text and binary files with 50 or 60 different kinds of systems in a
relatively uniform and consistent way.

Comments, rebuttals, are invited.  - Frank

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

End of Info-Kermit Digest
*************************
-------
26-Jun-84 11:15:54-EDT,10161;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 26 Jun 84 11:15:19 EDT
Date: Tue 26 Jun 84 11:15:10-EDT
From: Frank da Cruz <CC.FDC@CUCS20>
Subject: Info-Kermit Digest V1 #10
To: Info-Kermit: ;
Reply-To: Info-Kermit@COLUMBIA-20

Info-Kermit Digest      Tuesday, 26 June 1984     Volume 1 : Number 10

Today's Topics:
                          Begging for Mercy
                      IBM-PC Kermit & Ctrl-PrtSc
                      Kermit for the DEC-Pro 350
                          Unix Kermit Hangs
                        Call for Unix Kermits!
                             Many Things
                       Kermit for the Macintosh

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

Date: 22-JUN-1984  09:07 CST
From: [e-mail]
To: [e-mail]
Subject: Begging for Mercy

I am quite sure that your heart is in the right place so I say all
this only to reinforce what you already know.

   !!!!!!!KEEP THE MINIMUM KERMIT SIMPLE!!!!!

After playing with KERMIT for years it is easy to see how 12th bit
binary escape compression ECC re-encoding would fit nicely and be a
big help for people using the Mars/Jupiter data link.  But to the poor
soul reading the protocol manulal for the first time, such notions can
only result in despair.  He will give up.  Let KERMIT be a simple
(possibly expensive, possibly slow, possibly "un-friendly") way to get
information from any machine to any other machine.  Something I can
count on.

[Ed. - I agree.  The minimum Kermit IS simple.  You can still write a
Kermit program in a few pages of C or other high-level language.  Look
at the current (5th) edition of the protocol manual.  It's divided
into two sections, one describing the mandatory features, the other
discussing the optional ones.  The mandatory features haven't changed
at all from the very beginning.  The most rudimentary Kermit will
always be able to communicate with the most exalted, automatically.
Things were a bit more confused in earlier editions of the manual,
which was the main reason for the 5th edition.]

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

Date: 24 Jun 84 14:13:00 EDT
From: D. M. Rosenblum <DR01@CMCCTE>
Subject: IBM-PC KERMIT & CTRL-PRTSC
To: INFO-KERMIT@CUCS20

About three and a half weeks ago, someone here (C-MU Comp. Center)
posted a message (only locally, which is why you didn't see it)
complaining that when using an IBM-PC as a terminal through Kermit
1.19, one couldn't get a hard copy (on the PC's printer) of what one
was doing by using the Ctrl-PrtSc combination.  (Ctrl-PrtSc toggles
hard-copy printing of everything that appears on the screen on an
IBM-PC as it appears.  It is different from shift-PrtSc, which merely
prints the current screenful.)  Apparently Kermit didn't know about
slowing down its output to make this work.  He asked if anyone had any
other terminal emulation programs that did have this feature, and he
found that a guy in the Comp. Sci. department here (C-MU) had in fact
written such a thing.  Unfortunately, it is not available as cheaply
as Kermit.  This leads to two questions: (I) Do newer versions of
Kermit (somehow) support the Ctrl-PrtSc mechanism, and (II) if not is
it planned or could it be planned to implement this feature?

[Ed. - The forthcoming release of MS-DOS Kermit will do Ctrl-PrtSc.]

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

Date: 24 Jun 84 14:17:24 EDT
From: D. M. Rosenblum <DR01@CMCCTE>
Subject: KERMIT FOR THE DEC-PRO 350
To: INFO-KERMIT@CUCS20

The School of Urban and Public Affairs at C-MU is getting some DEC-PRO
350s running RSX-11 (for the time being, anyway -- they may switch to
some Unix look-alike or other).  Does the PDP-11 Kermit run on these?
In particular, does the documentation of PDP-11 Kermit include
information on how to install it on a DEC-PRO 350?  If the PDP-11
Kermit doesn't run on these, is there a version that does?

[Ed. - I assume that when you say RSX-11M, you really mean P/OS with
the DCL front end?  Kermit for P/OS was written by Stevens Institute
of Technology, and is available in KER:PRO*.* in the Kermit distribution
area.]

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

Date: Sun, 24 Jun 84 17:47:23 pdt
From: sdcsvax!sdccsu3!brian@Nosc (Brian Kantor)
To: cc.fdc@columbia-20
Subject: unix kermit hangs

Here at UCSD we're not running a recent version of the unix kermit, but
one of the changes we found out needed to be done was to ensure that
flushing gets done.  In Berkeley (4.2) we have not only to fflush the i/o
buffer, but also call the ioctl() function to flush the output buffer.
And then, when transfers are completed, we wait about 3 seconds before
resetting the tty modes back to normal.

We discovered that this was necessary in getting the Christensen protocol
programs to work properly; it seemed prudent to put all the same stuff into
kermit too just in case it might avoid a load-dependent hang.  Since our
machines run with load averages anywhere from 0.2 during quarter and summer
break and up to 35 or so (with a record of over 100 processes contending
for the processor once!!!!), load-dependent "funny noises" kind of hangs
are something we look for.

    ihnp4 \        Brian Kantor, UC San Diego
    decvax \
    akgua   >----  sdcsvax  ----- brian
    dcdwest/
    ucbvax/        Kantor@Nosc

[Ed. - Thanks for the hints; we'll make sure to heed them while working
on the new release of Unix Kermit; see below.]

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

Date: Mon 25 Jun 84 18:31:27-EDT
From: Frank da Cruz <[e-mail]>
Subject: Call for Unix Kermits!
To: [e-mail]

While the Kermit folk at Columbia are busy putting the last(?) touches
on the new release of MS-DOS Kermit, I'm trying to gather together all
the Unix Kermit suggestions and contributions that have come in since
the last (unnumbered) release, in October 1983.  I have a pretty good
stack of them, but if there's anyone out there who has some additional
suggestions or contributions to make, now's the time!

I expect that we'll have a minor new release very soon, whose major
new feature will be the ability to communicate with IBM, HP, and other
half duplex mainframes, and which (I hope) will have the system-
dependent conditional compilation code moved into separate modules.

After that, I hope we'll have a full-blown server that does most of
what's described in the protocol manual, along with some options for
local operation, including an interactive command mode as well as the
tar-style command line one-shot mode.

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

Date: Mon, 25 Jun 84 10:06:13 EST
From: decvax!mulga!stephenw.murdu@Berkeley (Stephen Withers)
Subject: Many Things
To: [e-mail]

Glad to hear your Lisa arrived - our Lisas and Macintoshes turned up
about 10 days ago.  We haven't decided whether or not to go in for the
Mac in a big way, but a Kermit would be very useful for the ones we have.

Many users here have expressed their appreciation of Kermit, so would you
pass on their thanks to all involved in the project (we're using VAX/VMS,
Unix, CP/M-80, CP/M-86, MS-DOS, RSTS, Apple-DOS, and Cyber Kermits, so
there's a lot of people to thank!)

Re CP/M Kermit servers and CBBSs - you don't need a server for this
purpose.  All that is necessary (I think) is to suppress Kermit's
send/receive displays, and make all its i/o go through the port that
is connected to the modem.  Server mode would be useful, but it's
definitely in the 'bells and whistles' category.  There's no reason
why a CP/M Kermit couldn't be used in the same way as a mainframe
Kermit that doesn't have Server functions.  I have been thinking about
producing a version of Kermit for a CBBS that I'm (very) loosely
involved with - I'll let you know if anything happens, but I'll wait
for the modularised version before I do any work on it.

Getting back to Macintosh, Kermit has two big advantages:

1) it works (at least as well as anything else I've seen)
2) it is (effectively) free
If you build Kermit into MacTerminal, point 2 no longer applies.  Apple's
University Consortium is on a smaller scale here (after all, with a total
population of 15 million, Universities are smaller too), so say we buy
120 Macs per year.  Virtually everyone will need comms software, so if
MacTerminal costs $A150 (Lisa Terminal is priced at $A245), that's
$A18,000, compared with about $A125 for the Kermit distribution tape.
Even if MacTerminal turns out to be cheaper, we are still talking about
thousands rather than hundreds of dollars.

[Ed. - About Macintosh Kermit -- We would ensure that there would be a
free version available, one way or another.  What we hoped to do was
to fix Macterminal so it could dynamically "load" the protocol module
of your choice (XMODEM, KERMIT, MICROCOM, whatever).  Macterminal
would still be a product, but Kermit would still be free, but
hopefully distributed by Apple with Macterminal.  But it seems this
problem has been solved before we really had to deal with it; see the
next message.]

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

Date: Mon, 25 Jun 84 21:19:05 CDT
From: Don Johnson <[e-mail]>
To: [e-mail]
Subject: Kermit for Mac

Frank,

    If you trust our implementation, we are writing and are fairly close
to being finished with a Kermit for Mac. It is being developed under the
Lisa Workshop environment. It will include prefixing and handling of
attributes (i.e., some, if not most of extended Kermit will be implemented).
We knew that Columbia was going to work on it, but we have to have running
code by August. We intend to submit it to the Kermit catalog of implementations
when done.
    Hope that this is useful to you.

    Don Johnson
    dhj@rice
    [phone]
    EE Department
    Rice University
    Houston, TX 77251

[Ed. - What luck.  More news about this will appear as it arrives.]

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

End of Info-Kermit Digest
*************************
-------
27-Jun-84 12:48:11-EDT,11663;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 27 Jun 84 12:47:24 EDT
Date: Wed 27 Jun 84 12:46:29-EDT
From: Frank da Cruz <CC.FDC@CUCS20>
Subject: Info-Kermit Digest V1 #11
To: Info-Kermit: ;
Reply-To: Info-Kermit@COLUMBIA-20

Info-Kermit Digest     Wednesday, 27 June 1984    Volume 1 : Number 11


Today's Topics:
                     New Release of DEC-20 Kermit
                     New Release of PDP-11 Kermit
                           Unix Kermit Fix
                  Floating Windows & Graphical Views
                  Kermit Supported by Crosstalk XVI
                           Kermit for PCjr?
             IBM 3270 Protocol Emulators and Unix Kermit

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

Date: Tue 26 Jun 84 18:32:29-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Release of DEC-20 Kermit
To: Info-Kermit@CUCS20

A minor new release of DEC-20 Kermit is available, 4(224), incorporating
several fixes and features suggested by Ken Harrenstien (KLH@SRI-NIC):

 The GET command allows source & destination filespecs to be given separately.
  Type GET ? to see how this works.

 Characters like ?!;@ can be included in the remote filespec in GET by
  prefixing them with CTRL-V (which is stripped before sending the name
  to the remote host).  This is the normal TOPS-20 way of quoting funny
  characters in commands.

 Refuse links on file-transfer tty, not controlling tty!

 Restore advice and links to former state after file transfer.

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

Date: Tue 26 Jun 84 19:24:26-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Release of PDP-11 Kermit
To: Info-Kermit@CUCS20

Announcing a new release of PDP-11 Kermit, 2.17, from Brian Nelson at the
University of Toledo ([e-mail]).  This release cleans up some
minor problems with the one distributed at DECUS in early June.  Included
are some performance improvements, some fixes for adapting to new releases
of RSX-11/M and M+ (4.1 and 2.1, respectively), and improvements in the
support for RT-11, particularly in terminal i/o.  Also, the new release
will run on the PDT-11 RT-11 system, whereas the previous release would not.
The files (61 of them) are in KER:K11*.*.  KER:K11INS.DOC describes the
files, operating system requirements, etc.  KER:K11CMD.MAC contains the
edit history, which describes the changes in detail.

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

Date: 25 Jun 84 21:40 PDT
From: [e-mail]
To: cc.fdc@COLUMBIA-20
Subject: UNIX KERMIT fix

Howdy...

Just wanted to confirm something you stated earlier in one of the KERMIT
digests.  This concerns a UNIX problem, which this site is having as well.
It seems that when you are transmitting a file from an outside micro to
the UNIX kermit, the micro never seems to get the word to stop.  Although
the file is transfered ok.

You stated in a recent digest, that the fix was to put a sleep(1) call
in before the terminal parameter change (UNIX call is stty()).  This
really works!  I have installed your suggested correction with no
apparent side effects, except the elimination of the micro sending problem.

Thanks again...

Mike Parker
{alias [e-mail]}

[Ed. - Thank you.  I've also been receiving lots of comments and code
in response to "Call for Unix Kermits"; keep them coming!]

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

Date: 26 Jun 1984 14:13:30-MDT
From: Leah F. Miller C-10 <lfm@lanl>
To: cc.fdc@COLUMBIA-20
Subject: Floating Windows & Graphical Views

Frank,

  Would you summarize the recent Info-Kermit debate on optimizing Kermit
performance,  for those of us who came in late?  I've received several
calls in the last few days from people who work on different projects
but have the same question :  could they use Kermit to send graphics
output to other states and/or Canada?  Do you know of anyone who is
shipping graphics data,  if only on a workstation-host basis?

Leah Miller

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

Date: Wed 27 Jun 84 10:01:50-EDT
From: Frank da Cruz <[e-mail]>
Subject: Re: Floating Windows & Graphical Views
To: [e-mail]

Well...  I think there is general agreement that Kermit should provide some
performance options, like sliding windows (multiple unacknowledged packets)
and longer packets, and perhaps ways for the two sides to agree to send
certain control characters "bare".  However, the exact mechanisms for doing
these things have yet to be specified.  In the meantime, Kermit can be used
for sending any kind of data over any kind of link, though you may find
yourself paying more in packet charges over public networks, and you may have
to adjust packet length or timeout intervals when long delays are involved,
like you have with satellite links.  If your graphics files are vector
encoded, then you won't see any particular savings from the repeat count
compression, but bit maps might get compressed a lot.  - Frank

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

Date: Tue Jun 26 1984 14:44:09
From: Marco Papa <[e-mail]>
To: [e-mail]
Subject: Kermit supported by Crosstalk XVI

>From the latest issue of PC-WEEK:

"Crosstalk XVI version 4.0, which will be shipped in August, will support the
Kermit protocol.  Crosstalk will contain hooks for Kermit, which users will
be required to individually license from Columbia."   Crosstalk XVI is a
product of Microstuf.

Congratulations you guys at Columbia.

Marco

[Ed. - We agreed to let Microstuf do this with our normal stipulations,
namely that they don't raise the price just because they put Kermit in it,
and they give credit to Columbia for the protocol.  These stipulations
are spelled out in greater detail in KER:COMMER.DOC.]

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

Date: 26 Jun 84  2322 PDT
From: David Fuchs <[e-mail]>
Subject: Kermit for PCjr?
To:   [e-mail]

Are folks running Kermit on the PCjr with the IBM built-in modem?  I
haven't been able to get SEND or RECEIVE to work at all, and regular
terminal emulation only works after some irreproducible set of
"<control-N>F <digit>" commands are given.  It can't be that the modem is
flakey, because the communications program on the JR Sampler disk works
fine talking to the same target TOPS-20 system.  I must be missing something.
Does anyone have a definitive set of magic incantations that make things
work?  Is there some Kermit command that must be given (other than SET
BAUD 300) before CONNECTing?  Is there some "latest version" of Kermit
that must be used?  Are all users this clueless?  My only excuse is that
COLUMBIA-20 has been closing all FTP connections before it manages to send
a complete copy of any documentation file...

[Ed. - IBM PC Kermit 1.20 works just fine on the PCjr serial port,
except that the screen display during file transfer looks strange on a
40-column screen.  However, Kermit doesn't work at all on the modem
port.  Internal modems are poison.  We'll try to get it workin on the
modem port as time permits (many things are higher on our list),
meanwhile, contributions will be gratefully accepted.  I don't know why
FTP should be having trouble, except that COLUMBIA-20 is field testing
a new version of TOPS-20.]

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

Date: Tue, 26 Jun 84 12:34 PDT
From: "Chase Lila"@LLL-MFE.ARPA
Subject: ibm3270 Protocol Emulators and Unix Kermit
To: [e-mail]

Has anyone had any experience getting the CMS Kermit to work
through this protocol emulator?

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

Date: Wed 27 Jun 84 11:02:17-EDT
From: Frank da Cruz <[e-mail]>
Subject: Re: ibm3270 Protocol Emulators and Unix Kermit
To: [e-mail]

A protocol emulator is a device that allows ordinary ASCII terminals or PCs
that emulate them to be connected to IBM systems that only know how to drive
3270 series EBCDIC terminals, which are normally connected via coaxial cable to
a 3274 cluster controller, which is either locally or remotely connected to an
IBM channel.  The 3270 is the only kind of terminal that VM/CMS really
understands; it is a full-screen block-mode terminal with lots of function
keys.

Protocol converters are popular at sites that have a mixture of IBM and non-IBM
timesharing systems.  They allow the same terminal to be used with both kinds
of systems.  They interpret the host's 3270 screen formatting commands into
appropriate escape codes for various ASCII terminals, do EBCDIC/ASCII data
conversion, and translate the terminal's function key output or other keystroke
sequences into 3270 function key signals.

A wide variety of protocol emulators is available on the market.  They may be
cards you plug into your PC (like the Irma board), little boxes on your desk,
bigger boxes (like the Datastream) near your mainframe or terminal switch,
minicomputers like the IBM Series-1 based Yale IUP, or IBM host resident
software like SIM3270.  Their operation can vary from straightforward
translation and interpretation to highly optimized screen management, in which
only those characters on the screen that need to be changed actually are
changed.

Kermit works on the assumption that data -- at least printable 7-bit ASCII
characters -- will be received exactly as they are sent.  Protocol converters
violate this assumption by doing EBCDIC/ASCII conversion on the data, inserting
escape sequences, and possibly reformatting it.  Therefore, Kermit (in its
present form) cannot operate through a protocol converter.

For now, there are several other options.  If you have an Irma board, you don't
need Kermit, because you get software with the Irma board to do file transfer.
Same for the Yale IUP.  The same may be true of some other protocol emulators.

One of our projects this summer will be CMS Kermit.  In addition to bringing it
up to a more advanced level, providing server functions, etc, we will be
looking at this problem.  It won't be easy, because the changes have to be made
not only in CMS Kermit (and ultimately also MVS/TSO Kermit, whenever that
appears), but also in any PC Kermit that wants to talk to it.  The PC, rather
than dealing with sequential streams of ASCII characters clearly delimited into
packets, will be receiving perhaps randomly ordered screen formatting commands.
A possible approach would be to have CMS Kermit send a clear-screen command to
signal the beginning of a packet, send the contents of the packet as line 1
(with awareness that the protocol emulator might "optimize" it by converting
spaces to tabs or cursor positioning commands), and signal that the packet is
finished by putting something on line 2.  Meanwhile, the PC builds its screen
interally, interpreting any escape codes (which it presumably already knows how
to do because of the VT52 or H19 emulation code in most PC versions of Kermit),
and then goes back to read the result as a packet when it gets the completion
signal.  Well...  we'll try doing something like this with the CMS and MS-DOS
Kermits.  Who knows, maybe it'll work.  If it does, then there's the task of
getting the same functionality into all the other Kermit implementations.

Comments or suggestions about this would be most appreciated.

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

End of Info-Kermit Digest
*************************
-------
 3-Jul-84 09:56:45-EDT,4107;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 3 Jul 84 09:56:21 EDT
Date: Tue 3 Jul 84 09:55:30-EDT
From: Frank da Cruz <CC.FDC@CUCS20>
Subject: Info-Kermit Digest V1 #12
To: Info-Kermit: ;
Reply-To: Info-Kermit@COLUMBIA-20

Info-Kermit Digest      Tuesday, 3 July 1984       Volume 1 : Number 12

Today's Topics:
                        MVS/TSO Kermit Coming
                    BYTE Article Available On Line
                     Kermit for the Morrow MD-11?
                          Bug in Kermit-20?
                           Wang PC Kermit?

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

Date: Thu 28 Jun 84 22:09:47-CDT
From: RON RUSNAK <[e-mail]>
Subject: TSO-KERMIT
To: [e-mail]

I am currently putting the finishing touches on a TSO-KERMIT which
is based on the CMS version.  Where would you like me to send it?
We have a BITNET connection here, if that helps.  I should be ready to
ship it out next week.

                                            Ron Rusnak
                                            [e-mail]
                                            [e-mail]

[Ed. - It will be announced as soon as it shows up.]

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

Date: Fri 29 Jun 84 20:24:10-EDT
From: Frank da Cruz <[e-mail]>
Subject: BYTE Article Available On Line
To: Info-Kermit@CUCS20

The July issue of BYTE Magazine is published, so now I'm allowed to
make the text of the article (at least as it was when we submitted it)
available on line.  It's in KER:BYTE.*.  BYTE.DOC is readable at the
terminal, BYTE.MSS is Scribe source, which can be run through Scribe
to produce output for a variety of devices, including multifont laser
printers.  - Frank

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

Date: Wed, 27 Jun 84 18:28 GMT
From: [e-mail]
Subject: Kermit for the Morrow MD-11
To: [e-mail]

Has anyone brought up a version of Kermit on the Morrow MD-11? The
generic CP/M 3 version did not seem to work when I tried it out. The
MD-11 runs CP/M 3.0 and is very different as far as communications from
the MD-1,MD-2, and MD-3.

                    Thanks,
                    Dan Jones

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

Date: Sat 30 Jun 84 17:51:33-PDT
From: Jim Lewinson <Jiml@Score>
Subject: Bug in Kermit-20?
To: [e-mail]

I have noticed the following behaviour wich I don't think
is quite correct.

1) Start up your favorite version of Kermit-20.

2) Tell it to go into server mode.

3) Type "^A# N3" at it.  This looks to me like a NAK for
    packet 0, with a length of 3.  This is the same packet that
    many Kermits throw at me when they start up, so I think the checksum
    is correct.

Kermit-20 produces a big ugly error about "un-implmented server command".
Surely this is not correct.  It should simply NAK back at me if it doesn't
make sense.

I don't know if this is related, but I have gotten a similar error when
I have disconnected (briefly) the rs232 link to the modem when Kermit-11
and Kermit-20 were talking back and forth.  needless to say, the transfer
failed.  (I was playing to see if it could handle lost packets.)

                    Jim

ARPA: Jiml@Score

[Ed. - Good point.  You're right, it should ignore NAKs when in
server command wait.  I'll fix it in Kermit-20 next time around.]

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

Subject: WANG Kermit
From: [e-mail]
To: [e-mail]
Message-ID: <[USC-ISID.ARPA] 3-Jul-84 09:30:50.ABN.20E-548>

Has anyone seen or heard of Kermit to run on the Wang PC under
MS-dos?  I have tried to modify the IBM-PC version but cant get
it to work.  Too many diferencies in things like port addresses
and screen escape sequences.

Walt

[Ed. - Kermit for the Wang PC with MS-DOS is on the way.  You're
right, the port and screen stuff is very mysterious.]

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

End of Info-Kermit Digest
*************************
-------
 9-Jul-84 12:39:25-EDT,19350;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 9 Jul 84 12:38:42 EDT
Date: Mon 9 Jul 84 12:00:28-EDT
From: Frank da Cruz <CC.FDC@CUCS20>
Subject: Info-Kermit Digest V1 #13
To: Info-Kermit: ;
Reply-To: Info-Kermit@COLUMBIA-20

Info-Kermit Digest       Monday, 9 July 1984      Volume 1 : Number 12

Today's Topics:
               RSX-11 Kermit Terminal Emulator Problem
            Bad Kermit-11 Files K11ASM.M41, K11*.XRF Fixed
                          Kermit-11 & RT11
                         Kermit File Servers
                         Kermit for HP-1000?
               What is the Kermit Protocol Named After?
               [Little] CP/M-86 Kermit Progress Report
                     Kermit-Based Network at Rice
         Conversion of CROSS Apple Output from Hex to Binary
                Problem Installing DECsystem-10 Kermit
                            Apollo Kermit

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

Date: Tue, 3 Jul 84 16:31 GMT From: [e-mail] Subject:
k11rsx term emulator problem.  To: [e-mail]

   I just installed the new kermit-11 on my 11/23 (128kw rsx11m v4.1B)
and have experienced some peculiar problems with the terminal emulator.
  Terminals are driven with an MBD 8-line DZ11. This behavior occurs
when trying to talk to our dec-20 or just looping back(plugging in the
output into another line on the distribution panel). When typing in
characters, what's on the screen is always one character behind what I'm
typing. To end a line it frequently takes either an extra cr or something
like an xon. When receiving characters, It stops after 4 or 5 characters
and I must keep hitting xon to get more groups of 4 or 5 characters.
Occasionally I lose characters when receiving. I've had no problem with
transferring files either way. Maybe the problem is related to the way
a dz buffers characters. Any suggestions would appreciated.

thanks,
-randy-                - [e-mail]-

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

DATE: TUES, 05 JUL 84
FROM: ATSBDN AT UOFT01
TO: SY.FDC AT CU20B
SUBJECT: RSX TERMINAL EMULATION

Don't know about being one character behind for RSX on his 11/23.
I have never seen that happen, and can't really think of why it would
do that. I will try some tests and see if I can come up with anything.

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

DATE: FRI, 07 JUL 1984
FROM: ATSBDN AT UOFT01
TO: SY.FDC AT CU20B
SUBJECT: KERMIT-11 AND RT11

hate to do this to you, but I found the reasons for my flakey problems
in the rt11 file create and open code. I had the agr list for a macro
called .DSTAT (it looks to see if a driver is resident) swapped. This
would sometimes succeed (based on garbage on the stack) and proceed to
overwrite the rt11 parsed filename and device block for the open. I
can send something next week to fix your stuff. Sorry about that, but
perhaps you can see why I took so long to do the RT11 conversion. I/O
under RT is a royal pain.
                                               brian nelson

[Ed. - Will announce new stuff when it arrives.]

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

Date: Thu, 5 Jul 84 09:07 PDT
From: "Hammon Randy"@LLL-MFE.ARPA
Subject: munged kermit file
To: [e-mail]

  I just discovered that the copy of k11asm.m41 is munged.
-randy-                   [e-mail]

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

Date: Thu 5 Jul 84 18:30:46-EDT
From: Frank da Cruz <[e-mail]>
Subject: Re: munged kermit file
To: "Hammon Randy"@LLL-MFE.ARPA

Thanks for pointing it out, there's a fixed one now.  Also the two K11*.XRF
files were bad and have been replaced.  - Frank

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

Date: Mon 2 Jul 84 14:46:19-PDT
From: Bruce Tanner <[e-mail]>
Subject: Kermit File Servers
To: [e-mail]

Frank

I read the second part of the BYTE article this weekend - good work.
I was pleased to see the college acknowledged at the end.

The article also touched on a subject I have been thinking about the last
few weeks, Kermit file servers.  The goal of micro-mainframe communications
is transparency; the user (or even the user's program) doesn't know
that the information is not at the micro, but at the mainframe.

It seems that a Kermit server on the mainframe is 90% of what is needed
to service requests for data, although the protocol would need to know
about logical sectors or even records of a file.

The micro side of the problem is tricky, you could either have a general
purpose subroutine to put into all your programs (practical for very few
applications) or modify the operating system.

Luckily, MS-DOS has device drivers that can be installed.  If I can have a
driver that makes MS-DOS thing a chunk of memory is a virtual disk, I would
think that a Kermit driver could make requests to another virtual disk
ship requests for logical sectors to the server.

I seem to recall that the Macintosh has hooks in it for a 'smart' file
server.  Perhaps the same type of thing could be done there.

I'm not sure this is a Kermit topic or not, since applications based on the
Kermit protocol (e.g. SMTP servers) were frowned upon as topics for discussion.
This is just a bit of 'blue sky' to see what you think.

[Ed. - You're right, it's sort of beyond what most people like think
Kermit is for.  But it sounds a lot like a project we're working on as
an outgrowth of Kermit.  It also sounds a bit like a project at Rice
University -- see below.]

Different topic:

KERMIT - KL Error free Reciprocal Micro computer Interface over Terminal lines
(or something like that)
Initial Kermit release

Kermit - Celtic for 'free'
Various Kermit sources

Kermit is not an acronym, it was named after Kermit the frog.
BYTE

What gives?

-Bruce

[Ed. - See below.]

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

Date: 3 Jul 1984 1442-GMT
From: CAROFF at Ames-VMSB
Subject: Kermit
To: cc.fdc at columbia-20

Is there a software tools available for the hp1000 that you have
heard of?  I have not unfortunately.  But I will look into that
version.

[Ed. - The Software Tools version of Kermit contributed by Ken Poulton
runs on the HP3000.  Ken says it should also run on the HP1000.  In
both cases, you need the stuff from the Software Tools tape for your
system.  Call the Software Tools User Group at 213-647-0272 for
further information about getting the "tools" for the HP1000, or write
to

  Software Tools User Group
  1259 El Eamino Real #242
  Menlo Park, California  94025

]

By the way, I just finished reading your kermit article and noticed
that kermit is NOT an acronym.  What the hell did you name it after
a frog, I just do not quite get it??  There must have been a reason!

Thanks much,
    Mike

[Ed. - What do you have against frogs?  In fact, we called the protocol
Kermit in honor of Kermit the Frog.  However, once we started exporting
Kermit programs, we became a little bit worried about getting in trouble
with the name, so we thought we'd better make it an acronym.  The "KL10
Error-free..." etc was the best we could come up with, but it was pretty
lame.  Later, Bill Catchings, while looking through name books for
his new baby (who is not named Kermit) noticed that the name Kermit
comes from the Celtic word for "free".  We liked that a lot better than
the acronym.  Then when we went to publish the article in BYTE, the
editors suggested we contact the Muppet people to settle the matter.  It
turns out that "Kermit" is a registered trade mark of Henson Associates
Inc, and no product may be called "Kermit" without their blessing.
Well, fortunately, "our" Kermit is not a commercial product since we
don't sell it for profit, and Henson Associates Inc kindly granted us
permission to use the name, provided we acknowledge them in our
publications, as we have begun to do.  It's not easy being green...]

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

Date: Fri, 6 Jul 84 09:37:51 CDT
From: Don Johnson <[e-mail]>
To: [e-mail], ...
Subject: kermit-based network at Rice

To the Kermit world:

    We at Rice are writing a Kermit protocol package as part of a network
we are developing. Thought I would describe what we are doing.

    We are bringing up a campus-accessible mail system and file storage
facility. The presumption is that most user nodes on the network are personal
computers which are not multiprocess machines. Consequently, they cannot be
assumed to be at a physical location at any one time, cannot accept mail
which arrives at a random instant of time, and the user could be anybody. A
good model for our system is that of a post office. To send/receive mail and
packages, the PC user must explicitly go (connect) to the post office to
access mail services. Our post office is an IBM 4341 and the communications
medium is a CBX (made by ROLM). Thus, we communicate with RS-232, with a
defined datarate of (hopefully) 9600 baud.
    We assume (and have to because of the IBM) that the datapath is only
seven bits wide. As we want to send Mac files (both resource and data), we
needed a protocol that would support 8-bit transfers in this environment. In
an attempt not to reinvent the wheel, we settled on Kermit as our 'data-link
layer' protocol and are writing same for the Mac, the IBM PC, and the 4341 as
well as one for MVS. We do NOT support time sharing services on this net, so
we do not do anything in regards to what could be termed 'terminal emulation'
other than for a dumb tty.
    'Mail' for us is straight ASCII that can be read on any PC regardless
of what it may be. 'Packages' can be most anything, including operating
system specific (like applications). The system will prepend a header to
each packages explaining its contents. We know what goes in this 'content'
field, but no specific format has been laid out.
    Thus, we are not writing what most of the world refers to as a
'Kermit'. Rather, we are writing the protocol portion of it as a module which
looks like a device driver (open, read, write, etc.). The 4341 side is a
server Kermit. We are supposed to have the net up (walking, maybe crawling)
by August 17. We will probably make that deadline. If any of you want this
stuff, you are welcome to it when completed. By the way, the MacKermit is
being written in Pascal under the Workshop environment on the Lisa.

    Don Johnson
    dhj@rice

[Ed. - Sounds a lot like the project we're working on, except with a VAX
at the center and DEC PCs (Rainbows with MS-DOS and Pro-350s with
Venix), with Macs to be added later.  We too have a deadline...]

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

Date:  Fri, 6 Jul 84 10:27 EDT
From:  "John C. Klensin" <[e-mail]>
Subject:  [little] CP/M-86 Kermit Progress Report
To:  Frank da Cruz <[e-mail]>

Sorry for the long delay in getting back to you on my CP/M-86 Kermit
struggles.  I have been working on it on and off, with repeated
interruptions to get a new multinational research project in place (the
joys of soft money).  In any event, the state of things at the moment is
as follows:

Overall changes required and made:
  - A few lines of conditional assembly code have been placed into
module 'kermit.a86' to identify the version for Concurrent differently
and to (for Concurrent) narrow down the displays so that they fit in in
a reasonable window.  Also added support for a new SET command to set
the width of a tab.  I hope this is acceptable, I needed it because
Multics (along with some UNIX implementations, so this is not completely
site-specific) is a "tab every 10" machine, rather than the DEC and
imitators "tab every 8".  The SHOW piece is in KERMIT (since the width
is always determinable), SET is in kerio so that people don't need to
support it where it does not make sense (e.g., rainbow).
 - modifications to "kertrm" for tab widths, mostly a few variables that
seemed logically to belong there.
 - everything else is in KERIO, including SET TAB-WIDTH for the PC.

Versions of KERIO I seem to have spread out here:
 - IBMPC, CP/M-86, semi-generic:  seems to work, using
character-at-a-time retrievals, rather than an interrupt-driven ring
buffer.  Seems to mostly work, as long as the speeds are moderate
(<=1200 Baud), and then not well at 1200.  This is all as one might
expect.  I did it in frustration at the next one in order to have
something to work with/from.
  -- IBMPC, CP/M-86, interrupt driven:  code has been assembled, tested,
and extensively desk-checked.  I am now on a hunt for something that
will explain in a way that my weak mind (which has not tried to write
assembly language in anger for maybe 16 years but which was writing
channel programs and real time interrupt handlers for years before that)
can understand what the relationship is between programming for the 8250
and for the 8259 and what it is that I am saying to, and expecting from,
the latter.  I have managed to figure out what seems like it ought to be
enough from studying the code in PCDOS pckermit, and from the Tech Ref,
and bits from the several "IBMPC esoterica" books I have around here,
but the books stop before that and that part of pckermit is probably
clear only when people know what it is doing.  Anyway, the thing loads
successfully, initializes the ports, and dies in a mode in which
(jodging from the lights on the modem) successfully sends characters in
terminal mode, but cannot manage to discover them when they come back
and get them to the terminal emulator.  It also leaves the PC in that
state, even across warm boots (PCDOS kermit resets it correctly).
  -- Concurrent CP/M-86:  now that I have a full set of documents
(Digital Research has a new trick, they send you a manual with the OS
that is strictly user-oriented and tell you in it that there is a
programmers guide, which you need to order, pay extra for, and (more
important) wait for.  That one tells you about yet another manual which
contains the esoterica that you then have to try to order.  Of course,
they have gone out of the retail business, and their retaillers have not
heard of manual set 2, much less the esoterica book), it looks quite
easy, given that all of the work is managed by the operating system,
including buffering, parity (if wanted), and XON/XOFF processing.  I
have a version desk-coded, but have not tried to assemble it yet, for
two reasons:  (a) I have been too busy getting frustrated by the CP/M-86
version.  (b) the size of their serial buffers, as delivered, is 16
characters.  I don't fancy trying to run kermit with 16-char packets,
and Concurrent runs only on fairly large machines (256K absolute
minimum) anyway.  So I have been trying to find out how to make the
queue sizes larger.  I was assured when I finally got a technical person
at DRI that it was possible to do so, I am still trying to figure out
how.  If I can get the queue sizes up over 96, things should go very
nicely.

  -- Since Barry Devlin seems to understand the Serius/Victor, and since
the availability of technical documentation on it here is photocopies of
engineering documents with handwritten notes in the margins, and since
he seems (from kermit-info) to be about to take on the CP/M-86 version,
I hereby will it back to him.  The IBM is clearly more than I can handle
right now without taking on another machine, especially as an
uncompensated activity (MIT considers my fussing with this stuff an
'outside professional activity' which translates as hobby for which I
can't bill salary).

- I also have (trivial) SET TAB-WIDTH code for the rainbow and apc
versions of KERIO to maintain compatability.

        john

[Ed. - If any of the CP/M-86 Kermit contributors would care to comment
on what John has done so far, feel free.]

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

Date: Mon 9 Jul 84 01:13:55-EDT
From: Peter G. Trei <[e-mail]>
Subject: CROSS hex -> binary conversion.
To: info-kermit@CUCS20

    I realise that there are only a limited number of people out
there working on Apple DOS Kermit, but I would like to spread the use
of a handy programming tool, which may be adaptable to use with other
micros.
    When you compile a micro source code file using the CROSS
compiler, the output is either one of a number of binary
representations, or one of a number of hexadecimal representations.
Frequently, the binary representation is nothing like that which your
micro's kermit expects to upload. This is a problem with Apple kermit,
and I have created a program, APPLEB.SAI, which converts one of the
hexadecimal outputs of the CROSS compiler into an 8-bit file which can
be directly uploaded to an Apple using kermit, and run.  This is a
considerable aid not only to developers, but also to people wishing to
upload updates. Directly uploading the binary form is at least twice
as fast as uploading, then converting, a hexadecimal representation.
    APPLEB.SAI is written in the SAIL language, which may not be
available at all sites. However, the source is heavily commented, and
it should be easily adaptable to PASCAL. It should also be fairly
trivial to cause it to output a number of different binary formats
appropriate for different micros.

                    Peter Trei
                    oc.trei%cu20b@columbia-20

[Ed. - The program is in KER:APPLEB.SAI.]

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

[Ed. - I lost the original message, but it was from someone who complained
of having trouble building DECsystem-10 Kermit because of a missing file,
B361LB.REL...]

Date: Fri 6 Jul 84 22:24:03-EDT
From: Nick Bush <OC.BUSH@CU20B>
Subject: Re: [LCG.KERMIT: TOPS-10 KERMIT]
To: [e-mail]

B361LB.REL is distributed along with RMS-10 on the Digital supported
CUSP tape.

- Nick

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

Date:  Thu, 28 Jun 84 17:05 CDT
From:  Tom Linnerooth <[e-mail]>
Subject:  Re: Apollo KERMIT
To:  [e-mail]

Frank slightly misinterpreted my intent.  I am not actively working on
KERMIT for the Apollo.  We simply don't have the manpower at the present
time to work on that problem.  If it were available, however, I would
probably install it.  The Apollo's we have were purchased from Mentor
with CAD software.  Mentor provided a simple protocol written in Pascal
that handles file transfers to and from the Apollo over a TTY line.
It checks the transfer by a simple checksum.  We were able to adapt their
program to our needs in just a couple of days, and we are reliably
transferring quite large files now.  That satisfied our immediate need.

I have not heard of anybody else who is interested in an Apollo
implementation of KERMIT, but I think it's a matter of time since
Apollo rings are becoming quite popular.  There is an Apollo mailing
list on the net, and a message broadcast there might bring some help.
I didn't try that.  Good luck, and I would be interested in what you
find out.

          Tom

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

End of Info-Kermit Digest
*************************
-------
12-Jul-84 10:31:24-EDT,14576;000000000000
Return-Path: <[e-mail]>
Received: from CUCS20 by CU20B with DECnet; 12 Jul 84 10:30:40 EDT
Date: Thu 12 Jul 84 10:29:02-EDT
From: Frank da Cruz <CC.FDC@CUCS20>
Subject: Info-Kermit Digest V1 #14
To: Info-Kermit: ;
Reply-To: Info-Kermit@COLUMBIA-20

Info-Kermit Digest      Thursday, 12 July 1984     Volume 1 : Number 14

Today's Topics:
                 Incorrect Issue Number on Last Digest
                Kermit on a DG MV/x0000 running AOS/VS?
             Bug in Kermit-10, VMS Kermit, and Pro/Kermit
             Re: RSX-11 Kermit Terminal Emulator Problem
                           RSX TT EMULATOR
                       AT&T PC Kermit Problems
                       Kermit, DCA and the DDN
                         Kermit Boot Program
                          Kermit for MVS/TSO
               Kermit-11 Problem Between RSTS/E Systems
                      Software Tools for HP-1000

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

Date: Thu 12 Jul 84 09:32:56-EDT
From: Frank da Cruz <CC.FDC@COLUMBIA-20>
Subject: Incorrect Issue Number on Last Digest
To: Info-Kermit

Sorry, the last issue was number 13, not number 12.  Thanks to all of you
who pointed out the mistake.  - Frank

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

Date: Mon 9 Jul 84 09:32:56-PDT
From: Michael A. Haberler <[e-mail]>
Subject:  Kermit on a DG MV/x0000 running AOS/VS
To: [e-mail]

I am interested in bringing up Kermit on a DG MV series machine running
AOS/VS. Has anybody out there done that before?

- mike

[Ed. - Kermit is available for DG machines running AOS, but first you must have
the Software Tools Package.  For futher information about the Software Tools
package, contact:

    Software Tools User Group
    1259 El Camino Real #242
    Menlo Park, CA  94025
    213-647-0272

The AOS implementation of Kermit is available in KER:AOS*.*.  There's
also a newer, more advanced Software Tools Kermit implementation which
has been done for the HP3000 and Univac 1100 -- it would be desirable to
adapt any system- dependent parts from the AOS-specific version to the
newer version and use that.  Anyone who does this is encouraged to
contribute it to the Kermit collection so we can discard the older
program.  The newer one is in KER:ST*.*.]

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

Date: Mon 9 Jul 84 13:35:40-EDT
From: Nick Bush <[e-mail]>
Subject: Bug in Kermit-10, VMS Kermit, and Pro/Kermit
To: INFO-KERMIT@CUCS20

There is a minor bug in these three Kermits (the joys of a common
source).  The problem will only show up when sending files to a Kermit
which has requested 94 character messages with an even valued ASCII
character as the end of line character (like line feed = 12octal).  One
Kermit implementation which requests this set of parameters is LCTERM.
The problem is easily avoided by using the SET SEND PACKET-LENGTH command
(PACKET_LENGTH in VMS Kermit) to set the maximum packet size to something
less than 94 characters.

This will be fixed in the next versions of these Kermits.

- Nick

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

Date: 9 Jul 84 17:54:09 EDT
From: Glenn J. Joyce <GJ0F@CMCCTE>
To: Info-Kermit@CUCS20
Subject: Re: RSX-11 Kermit Terminal Emulator Problem

    I've seen the same behavior that he is talking about and the
solution to the problem (at least in my case) was pretty simple.  If
you have a full duplex terminal driver and have your lines set to half
duplex, you will get the results that he reports.  If you set the line
that you will connect over to full duplex (via the MCR command SET
/FDX=TTnn:) and set the line to which your terminal is connected to
full duplex, the terminal emulator will work just fine.  If either of
those lines are in half duplex mode, the terminal emulator appears to
work, but is always a few characters behind.  You can clear the
pending typein/typeout with a few CR's or XON's.  (You can see the
line characteristics if you do a DEV TTnn: to the > prompt)

                - Glenn Joyce

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

DATE: TUES, 10 JUL 1984
FROM: ATSBDN AT UOFT01
TO: SY.FDC AT CU20B
SUBJECT: RSX TT EMULATOR

Sounds reasonable (?). This may have been caused by an edit accidently
removing the sf.smc for fdx on the connected line in k11con.mac, which
will be there when the next tape goes out tomorrow.

[Ed. - New Kermit-11 will be announced as soon as it arrives.  See below
for another problem with this program when it's running under RSTS/E.]

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

Date: Tue 10 Jul 84 07:22:01-PDT
From: Ted Markowitz <[e-mail]>
Subject: AT&T PC problems
To: [e-mail]

I'v just received a model of the new AT&T PC and tried it with the standard
IBM PC version of KERMIT since it claims to be 'compatible'. Well, no such
luck. After a few lines of output in terminal emulation mode it garbles the
text something fierce.

It is 8086 based and does have a faster clocking (8Megahertz). Any ideas
to get this to work? Another version of KERMIT perhaps?

--ted

[Ed. - The forthcoming release of MD-DOS Kermit will have a small module
in which the system-dependent primitives are defined.  We will have such
modules for the IBM PC & XT, DEC Rainbow, HP-150, Wang PC, and "generic"
MS-DOS.  You can start with the generic MS-DOS Kermit; it may work as is,
or you may have to twiddle an address or two.  However, since it goes
through DOS for all services, it will be slow.  If it's too slow for you,
then you can write system-dependent primitives for your new AT&T system.
The new release will be available Real Soon Now.]

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

Date: 10 Jul 1984 09:29-PDT
Subject: KERMIT, DCA and the DDN
From: Geoffrey C. Mulligan (AFDSC, The Pentagon) <GEOFFM@SRI-CSL>
To: Info-Kermit@COLUMBIA-20

While I was out at DCA I heard talk that they working to upgrade
the C/30 TACs.  This upgrade would be both hardware (ie a new
C/50) and software (ie user friendly).  Along with the software
upgrade they are considering implementing some protocols in the
TAC for PC <-> DDN file transfers (recognizing that
character-at-a-time is very wasteful of DDN resources).  On the
top of the list of protocols is KERMIT!  I am not sure (nor are
they) exactly how it will all work, but the initial idea is that
the TAC would receive the whole file and then use FTP to pass it
on to the host.  Does anyone have any comments or ideas?

DCA also has quite a number of IBM-PCs with integral Hayes 1200B
modems.  Is there a version of KERMIT that will drive the modem.
Even if it does not dial (another program could do that), it has
to be modified to use the Hayes modem as opposed to the serial
port...  help?!?!?

        geoff

[Ed. - Most Kermit programs, including MS-DOS Kermit, do not contain
explicit code for modem control.  We have always advised Kermit users to
steer clear of internal modems.]

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

Date: Tue 10 Jul 84 23:51:27-PDT
From: Jim Lewinson <x.Jiml@[36.40.0.209]>
Subject: Kermit Boot Program
To: [e-mail]

KerBoo is a small Fortran program that implements the Kermit
Protocol to allow you to receive files.

The idea is that you already have both a Kermit on one machine and a
somewhat featureful Kermit in "HEX" format for the other.  The
purpose behind the program is to allow you to send the HEX file to
the machine with nothing with some sort of error detection and
recovery (By using the Kermit on the machine you have one running
on.)

This program is VERY dumb.  It has no timeouts, no 2 or 3 character
checksums, no eighth bit quoting, and no protection. It doesn't even
try to turn off echoing.  In fact, I could spend all day telling you
the things it does not do.  It does do one thing, it lets you send
using Kermit to a machine that doesn't have anything.

I have tried it under VMS, and Versions 3.2 and 4.0 of RSX-11M, and
it seems to work.  If it doesn't, it will most likely be obvious why
it is failing.  ("Hmmm - This Fortran Doesn't allow file names in
opens.")  I have tried to write very generic Fortran.

Happy Kermiting,

Jim Lewinson
Breuer & Company
Bedford, Massachusetts

[Ed. - The files (3 short ones) are in KER:KERBOO*.*.]

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

Date: 9 July 1984, 13:18:27 CST
From: SYSRONR  at UCHIVM1
To:   DFTCU at CUVMA
Subject: Kermit for MVS/TSO

I have completed a version of Kermit for MVS/TSO.  I have been able to
test it out in our environment, but I have not tested it on a raw TCAM.
In our environment we are using a mod to the 3705 to make everything look
like a 2741.  This means that everything is translated from ASCII to 2741
code to EBCDIC before it reaches KERMIT.  It also supplies XON codes when
the host has put up a read.  It is my belief that normal TCAM will handle
ASCII to EBCDIC translation just fine, and I believe that TCAM will also
supply XON codes when it has a read up.  However, I have been unable to
gen a TCAM here with raw Teletype 33-35 support to test it out.

If you wish I will sendfile you the the following pieces.

IBMKERM ASSEMBLE
IBMDYNA ASSEMBLE
IBMKERM DOC

I would like to put in a word for adding support to all of the micro
KERMITs for the SET START-OF-HEADER command.  In our MVS/TSO environment
the host cannot receive a CNTRL-A.  We have therefore added the SET
START-OF-HEADER command to the IBM-PC version and to the APPLE II version.

                        Ron Rusnak

[Ed. - Chicago's MVS/TSO Kermit will be announced as soon as it arrives.
The forthcoming release of MS-DOS Kermit will have commands to changes
the packet-start character.]

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

DATE: WED, 11 JUL 84
FROM: ATSBDN AT UOFT01
TO: SY.FDC AT CU20B
SUBJECT: KERMIT-11 PROBLEM BETWEEN RSTS/E SYSTEMS

May as well send the following note out on info-kermit. A problem has
been found with sending binary files on RSTS/E with attributes when
the file sent never had any on the sender's system. It's unusual and
should not normally cause a problem.

;       update to the last procedure in K11ATR.MAC

        .sbttl  finish up the update of rms file attributes to output

;       A T R F I N
;
;       If the file was send in image mode, and we have been sent
;       valid attributes (basically, the sender's IFAB), then call
;       PUTATR to place these attributes into our output file's
;       IFAB so they will get updated.
;
;
;       Note: 11-Jul-84  17:12:49  BDN,  edit /19/
;
;        Note that for RSTS/E, we have an unusual problem in that if
;       the sender sent a stream ascii file (most likely a file with
;       NO attributes)  over and the sender  said it's binary,  then
;       RMS-11 sends GARBAGE for the VFC header size. When this data
;       is wriiten  into the output file's IFAB, RMS11 finds invalid
;       data in the IFAB and writes attributes to disk with the last
;       block field (F$HEOF and F$LEOF)  equal to ZERO.  Such a file
;       would thus be unreadable to PIP, RMS and other programs that
;       look at the file attributes.  The fix  is one of two things.
;       One, we can clear the invalid  VFC size and fudge the record
;       size and maximum record size to something usable (like 512),
;       or  we can simply ignore  the senders attributes and let the
;       file  stand as a  FIXED, NO CC, recordsize 512 file.  Rather
;       than to try to fix the attributes, we will simple ignore the
;       attributes  if the sender said that the file is stream ascii
;       with a garbage VFC.  Since  the attributes  are only used if
;       the transfer was in image moed, this will not  affect normal
;       files, only files like DMS-500 files that have no attributes
;       but must be sent in image mode.
;       Of course, the sending Kermit-11 can always be given the SET
;       ATT OFF and SET FIL BIN and the receiving Kermit-11 be given
;       the SET FIL BIN and the issue will never arise.
;
;       The mods are noted with /19/ after the statement.

atrfin::save    <r1,r2,r3>              ; just in case please
        tst     @r5                     ; lun zero ?
        beq     100$                    ; yep
        tst     at$val                  ; valid attributes to write ?
        beq     100$                    ; no
        cmpb    at$typ  ,#binary        ; did we get this as a binary file?
        bne     100$                    ; no
        mov     #at$fab ,r1             ; yes
        tst     (r1)+                   ; valid data present ?
        beq     100$                    ; no
        cmp     @r1     ,#2000          ; /19/ stream ascii ?
        bne     30$                     ; /19/ no
        cmp     16(r1)  ,#177400        ; /19/ garbage for the vfc header size?
        beq     90$                     ; /19/ yes, forget about the attributes
30$:    calls   putatr  ,<@r5,r1>       ; /19/ update the ifab for the file
90$:    clr     at$typ                  ; /19/ no longer valid please
        clr     at$fab                  ; no longer valid please
        clr     at$val                  ; no longer valid please
100$:   unsave  <r3,r2,r1>              ; output file and exit
        return

200$:   .byte   40,0

        .end

[Ed. - This fix will not be in the next release (the situation where it
occurs rarely comes up), but in the one after that.  Until then, anyone
who is effected by the problem can install the fix themselves.]

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

Date:        11 Jul 84 10:16 +0200
From:        [e-mail]
To:          "Frank da Cruz" <[e-mail]>
Subject:     Software Tools for HP-1000

I have found out in the meantime that there are two implementations
of the Software Tools Package on a HP1000, but I had not the time
to contact the implementors yet.
Larry Dwyer   [phone] x 2095
John Campbell [phone]

I try to receive the Software Tools Package for the HP1000 as fast as
possible. Then I will take a closer look at the HP3000 Kermit.

Regards,
                        Michael

[Ed. - This is in regards to running the Software Tools implementation of
Kermit on the HP-1000.]

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

End of Info-Kermit Digest
*************************
-------
16-Jul-84 12:12:02-EDT,21753;000000000000
Return-Path: <CC.FDC@CUCS20>
Received: from CUCS20 by CU20B with DECnet; 16 Jul 84 12:10:19 EDT
Date: Mon 16 Jul 84 11:53:26-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #15
To: Info-Kermit: ;
Reply-To: Info-Kermit@COLUMBIA-20

Info-Kermit Digest       Monday, 16 July 1984     Volume 1 : Number 15

Today's Topics:
                   New Kermit Available for HP-1000
                New Kermit Available for Apollo Aegis
                           Sirius Kermit(s)
                           BREAK Indication
                       Kermit for DEC Pro-350?
            Other Kermits - Sanyo, Toshiba, BBC 6502, ...
                          Kermit-32 Problem
                Kermit and Modem Binary File Transfers
                       Kermit with Knowledgeman
                            Kermit's limit
               Problems with Kermit-10 RECEIVE Command

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

Date: Fri 13 Jul 84 13:33:49-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Kermit Available for HP-1000
To: Info-Kermit@CUCS20

Announcing version 1.0 of Kermit for the HP-1000/RTE-6/VM system from John Lee
of RCA Laboratories, written in Fortran, capable of remote (dialin) but not
local (dialout) operation.  The source file is in KER:HPMKERMIT.SRC (the HP
name space in the distribution area is getting tight; "M" is Roman for 1000),
the documentation is in KER:HPMKERMIT.DOC.

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

Date: Fri 13 Jul 84 13:34:26-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Kermit Available for Apollo Aegis
To: Info-Kermit@CUCS20

Announcing version 1.0 of Kermit for the Apollo Aegis system from John Lee
of RCA Laboratories, written in Fortran, capable of both remote (dialin) and
local (dialout) operation.  The source file is in KER:APOKERMIT.SRC,
the documentation in KER:APOKERMIT.DOC.

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

Date: Sun Jul  8 1984 10:58:02
From: Marco Papa <[e-mail]>
To: [e-mail]
Subject: UNIX Kermit problem

Now that we are using XTs connected to our Vaxes running Berkeley UNIX, we
are experiencing the following problem.  When transfering a file from the XT
running Kermit-86 V. 1.20 to the VAX running UNIX Kermit at 9600 bauds the
transfer is aborted after the first packet is sent.  PC Kermit says that it
is unable to receive an acknowledgement from the host.  The PC screen looks
like this:

Number of Packets: 2                Failed
Number of retries: 5

?Unable to receive acknowledgement from the host

Instead, if we make the transfer at low speed, say 300 bauds, everything is
OK. Also we have no problems when transfering files in the other direction
(from the VAX to the XT), no matter which speed we use.

Has anyone experienced this before?  It seems that this might be a problem
similar to the one that requires to insert a sleep(1) at the end of the
transfer code, so that the last acknowledgement is not lost.

Marco Papa
ARPA, CSNET: papa.usc-cse@csnet-relay
UUCP: ..!randvax!uscvax!papa

[Ed. - Anyone out there who can help?  As far as I know, this combination
has been working for many months.]

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

Date: Thu 12 Jul 84 14:26:43-EDT
From: JUNGER@CWRU20
Subject: Internal Modems
To: info-kermit@CUCS20

In the last Info-Kermit I noticed the following statement:

  [Ed. - Most Kermit programs, including MS-DOS Kermit, do not contain
  explicit code for modem control.  We have always advised Kermit users to
  steer clear of internal modems.]

Perhaps it would be well to point out to those who are running
non-generic Kermit for CP/M-80 that they can use an internal modem if
they modify Kermit to look for the ports used by the modem instead of
the external serial port.  At least this works for my North Star
Horizon, for which I have two versions of Kermit, one for the external
printer port and one for a Hayes Micro Modem 100 connected to the S-100 bus.

Peter D. Junger
CWRU Law School

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

Date:  Thu, 12 Jul 84 14:28 EDT
From:  [e-mail]
Subject:  Packet retransmissions.
To:  [e-mail]

I have recently installed the MULTICS Kermit from MIT-MULTICS on our
system (the MUKERMIT from COLUMBIA-20 had many bugs).  I am talking to
this with the PCKERMIT from COLUMBIA.  Using either 1200 or 300 baud, my
retransmission rate runs about 95%!  What am I doing wrong?  Are there
any parameters on either end that affect retransmission?  I assumed that
this was primarily due to communications equipment or line quality.  Any
suggestions are welcomed.

Wolf Wiedemann RADC-MULTICS

[Ed. - I haven't heard that complaint before, but I don't have any
experience with MULTICS machines.  I assume other MULTICS Kermit users
have had better experience, or else I would have heard!  Anyway, the
author of MULTICS Kermit, Paul Amaranth of the Oakland University in
Michigan, just sent me a tape with a new release of the program.  I'll
announce it as soon as it's on line.]

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

From: decvax!mulga!nemeth.uacomsci@Berkeley
Date: Thu, 12 Jul 84 13:14:00 EST
To: info-kermit%columbia-20.arpa.mulga.UUCP@Berkeley
Subject: Sirius Kermit(s)

Hi, hope you got the hex file of the CP/M-86 Sirius version I sent a few
days ago... it was quite a struggle getting it ON the damn thing, because
its disc format is totally incompatible with everything!  And to complicate
things further, MS-DOS can't write CM/M-86 files (but it can read them).

Anyway, having used the two (ie MS-DOS and CP/M-86) versions on the Sirius,
we have decided to all but forget about the MS-DOS version; it is VERY slow
(barely runs @1200, even loses chars in connect mode; highest speed it seems
to run reliably is about 600 bps); and it has some bugs, apparently (gets very
confused talking to a server).  The CP/M-86 version does not seem to have any
such problems -- it runs faster (tested at 4800 bps), does not need padding
characters in connect mode, and seems to work fine with a server (although it
produces a strange diagnostic, which is ignored, using wildcards).

[Ed. - I've heard wildly conflicting reviews of Victor/Sirius Kermit,
both the CP/M-86 and MS-DOS versions.  Some say it performs flawlessly
at 9600 baud; others say it doesn't work at all.  I've also heard that
the systems themselves vary a lot -- different i/o chips, different
BIOSes, etc.  Can anyone out there shed any light?]


Subject: Break indication

(new subject, not a comms problem): I believe this should be an ESSENTIAL
facility for all Kermits to provide in connect mode; it has all sorts of
uses. In our environment (via a port selector) it is the only means for the
user to disconnect his line and select another host; the ability to send a
break indication is really missed on the CP/M-80 versions!

[Ed. - Obviously, I agree.  Most of the KERMITs that come from Columbia
have this.  It's up to each person who installs support on a new
microcomputer to include this functionality.  The method varies from
system to system -- system calls to send BREAK, direct serial i/o chip
device manipulation, BREAK simulation by sending several nulls at 50
baud, etc.]


Subject: Kermit for DEC Pro 350?

What's happening about it?  Has it been released yet?  We have some users who
would like to use it (we also have the DEC PFT, but that only talks to VAXes..)

[Ed. - It's released.  It was done by Stevens Institute of Technology,
sharing common code with their VAX/VMS and DECsystem-10 versions.  P/OS Kermit
is available as KER:POS*.* in the Kermit distribution area, and it will
be on the Spring DECUS VAX and RSX SIG tapes.]


Subject: Other Kermits - Sanyo, Toshiba, BBC 6502, ...

Work is progressing on a few other implementations: the Sanyo is almost there,
should be done in about a week; a Toshiba version is being looked at; likewise
for RSX-11 and RT-11 (appears to be non-trivial to install), and Cyber(NOS/BE);
BBC 6502 still working on it; and 3 or 4 other local CP/M based micros.


Keep up the good work! Will advise further when some of these are completed.

Tom Nemeth

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

Date: Thu 12 Jul 84 17:46:22-PDT
From: Lawrence L. Wu <[e-mail]>
Subject: Kermit-32 problem
To: [e-mail]

I am writing on behalf of the system people at the Hoover Institution's
VAX/VMS.  A few weeks ago, I helped them acquire a copy of Kermit-32
(Version 3.0.051) for their VAX.  Today, Kermit caused a system problem
that caused them to disable Kermit until the problem can be fixed.
It appears that some user was using Kermit in local mode and exited
abnormally from the VAX, probably by hitting break or turning off their
terminal.  The problem that occurred was that Kermit didn't drop the
dial-out modem and the remote computer effectively tried to login
through the remote port, which had been dedicated to Kermit.  This
wrote login failure messages to the system disk every few seconds
and, according to the system people, would have crashed the system if
not caught in time.

I have just pulled the protocol manual over from Columbia via Arpanet
and will look through it with the system people at Hoover; this may
help us solve our problems.  However, I qualify only as a dumb user
(and also have less than complete confidence in the abilities of the
system people at Hoover.)  Have other people have encountered similar
problems, or can you (or others) offer suggestions?  Any help would be
greatly appreciated.

Larry

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

Date: Fri 13 Jul 84 08:26:00-EDT
From: Nick Bush <[e-mail]>
Subject: Re: Kermit-32 problem
To: [e-mail]

If Kermit is really aborted abnormally, there is little it can
do to hang up a modem.  However, the problem can be avoided by
setting the terminal line with the dial-out modem to enable automatic
hangup.  This is done by "SET TERM TTxn:/PERM/HANGUP".  With the
line set this way, it will hangup the phone whenever the terminal
line is either released by a program or deallocated by user command
(if it was allocated to a process).

- Nick

PS:    It is actually possible to recover from the situation you
    described without reloading the system.  I keep a command
    file around the simply attempts to allocate the terminal
    specified by its parameter and loops until it is sucessful.
    Since it takes some amount of time to create a process
    to run LOGINOUT to attempt the login, you can ususally
    grab the terminal fairly quickly (within one or two login
    attempts).

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

Date: Fri 13 Jul 84 09:32:04-PDT
From: Ted Shapin <[e-mail]>
Subject: kermit and modem binary file xfers
To: [e-mail], [e-mail]

One of our main requirements for micro to mainframe communication
is to be able to archive programs on the large systems disks.
This includes binary files that may be .COM, .EXE, .CMD and
"squeezed" files.

KERMIT for TOPS-20 only saves files as 7-bit ASCII, which loses
the eigth bit.

Under MS-DOS files can have a length that is not an even multiple
of 128 bytes.  MODEM loses because a file that is transferred
up to the HOST and then back to the PC will be rounded up to the
next even number of sectors.

I know there are programs that will expand binary files to 7-bit
files but I do not think that extra translation is a good solution.

Comments?

Ted.

[Ed. - Au contraire...  You can tell Kermit-20 to "SET FILE BYTESIZE 8"
when receiving files and it will store them as you desire.  If a file is
stored with bytesize 8 on a DEC-20, Kermit-20 will automatically send it
correctly.  It even recognizes "ITS Binary" format.  Read the manual.
The most current documentation is in KER:20KERMIT.DOC.]

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

Date: 13 Jul 84 08:12:28 EDT
From: J. Ray Scott <JS5A@CMCCTA>
To: sy.fdc@CU20B
Subject: Kermit with Knowledgeman

Just a caution.  If you are creating files with the Knowledgeman CONVERT
verb KMan pads the output file out to even multiples of 128 bytes.  It
puts a ^Z in at the end of its data and then just junk after that.

If you send this file with PC Kermit, Kermit will go ahead and send the
junk since Kermit relies on the MS-DOS file size and not any data in the file.

I think Kermit is right.  This is just another in a very long list of
problems with KMan.  I would NOT recommend Kman to anyone.
                    J. Ray Scott

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

Date: 13 Jul 84 21:23:19 EDT
From: G.W. van Mook <GM04@CMCCTA>
To: js5a@CMCCTA
Subject: KERMIT'S limit

I attempted to download the AP vendor file from TOPS-A to the XT, and like
it did last time I did this, it died at KERMIT packet 32767.  It seems that
KERMIT's limit is around 2.8 megabytes per file transfer, unless something
else is causing this.

Good night...gvm

[Ed. - Sounds like some 16-bit counter overflowed unexpectedly in PC/XT
Kermit.  We'll look into the problem.]

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

Date: Wed, 11 Jul 84 11:24:38 EDT
From: Dave Swindell <dswindel@bbn-labs-b>
Subject: Problems with KERMIT-10 Receive command??
To: info-kermit@columbia-20

Recently, I have had problems sending files from KERMIT-86
(version 1.20) on an IBM-PC to KERMIT-10 (latest version) on our
TOPS-10 computer.  I want to be able to rename the files as they
are sent by using the RECEIVE <TOPS-10 file spec> on KERMIT-10
command and the SEND <file spec> command from KERMIT-86.  When I
do this, I get an error message from KERMIT-10 about illegal
wildcard characters in file specification.  The file specs I am
using in KERMIT-10 contain no wildcard characters (*,%, or ?).
What am I (or what is it!) doing wrong?

Dave Swindell, @bbn-unix

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

Date: Fri 13 Jul 84 22:38:06-EDT
From: Nick Bush <[e-mail]>
Subject: Problems with Kermit-10 receive command
To: [e-mail]
cc: [e-mail]

The following patch corrects a problem with Kermit-10 v3(123) in the
RECEIVE command.  This makes RECEIVE file.ext work correctly.  Previously
if an extension was given, an error message was generated when the file
was received.

File 1)    DSKB:K10MIT.MAC[10,52,KERMIT,DST,10]    created: 2248 24-May-1984
File 2)    DSKB:KERMIT.MAC[10,52,KERMIT,10]        created: 1753 11-Jul-1984

1)1        MITVER==2            ; Major version number
1)        MITMIN==0            ; Minor version number
1)        MITEDT==123            ; Edit level
1)        MITWHO==0            ; Customer edit
****
2)1        MITVER==3            ; Major version number
2)        MITMIN==0            ; Minor version number
2)        MITEDT==126            ; Edit level
2)        MITWHO==0            ; Customer edit
**************
1)3    |
****
2)3    Start of Version 3(124)
2)    126    By: Nick Bush        On: 11-July-1984
2)        RECEIVE FOO.BAR would not work correctly.
2)              It thought the extension was
2)        wild-carded.
2)
2)        Modules: KERMIT
2)    |
**************
1)28    > ; End of TOPS10
****
2)28    ; Determine if we are logged in.
2)        PJOB    S1,            ;[125] Get our job number
2)        MOVNS    S1            ;[125] Set up for JOBSTS
2)        JOBSTS    S1,            ;[125] Get status for us
2)         MOVX    S1,JB.ULI        ;[125]  Old TOPS-10 maybe?
2)        TXNN    S1,JB.ULI        ;[125] Logged in?
2)         SETZ    S1,            ;[125] No, remember that
2)        MOVEM    S1,LOGDIN        ;[125] flag file creation time
2)    > ; End of TOPS10
**************
1)29         $CALL    I%EXIT            ; And exit
1)    TOPS10<
****
2)29         $CALL    C$EXI0            ;[125] And exit
2)    TOPS10<
**************
1)33        GETPPN    S1,            ; Get our logged in PPN
****
2)33        MOVX    S1,<<SIXBIT |INI|>>    ;[125] Try INI:KERMIT.INI first
2)        MOVEM    S1,INIFD+.FDSTR        ;[125] for global defs
2)        MOVEI    S1,INIFD        ;[125] Get the FD address
2)        SETZ    S2,            ;[125] No log file FD
2)        $CALL    P$TAKE            ;[125] Set up the take
2)        JUMPF    REDIN0            ;[125] If not there don't worry
2)        MOVEM    S1,INIIFN        ;[125] Found file, save IFN
2)        $CALL    PARL.1            ;[125] Parse the file
File 1)    DSKB:K10MIT.MAC[10,52,KERMIT,DST,10] created: 2248 24-May-1984
File 2)    DSKB:KERMIT.MAC[10,52,KERMIT,10]        created: 1753 11-Jul-1984

2)    REDIN0:    MOVX    S1,<<SIXBIT |DSK|>>    ;[125] Now we will use
2)        MOVEM    S1,INIFD+.FDSTR        ;[125] DSK:KERMIT.INI[,]
2)        GETPPN    S1,            ; Get our logged in PPN
**************
1)39        XMOVEI    S1,MYTERM        ; Point to the block
1)        $CALL    T$SBRK            ; Set the PIM mode break set
****
2)39        XMOVEI    S2,MYTERM        ;[125] Point to the block
2)        $CALL    T$SBRK            ; Set the PIM mode break set
**************
1)39        CAIN    P1,"E"            ; In escape sequence?
****
2)39        MOVE    S2,S1            ;[125] Copy of the character
2)        ANDI    S2,177            ;[125] Keep only 7 bits
2)        CAIN    P1,"E"            ; In escape sequence?
**************
1)39        CAME    S1,ESCAPE        ; Is this escape?
1)         JRST    CN.SND            ; no, just send it
****
2)39        CAME    S2,ESCAPE        ; Is this escape?
2)         JRST    CN.SND            ; no, just send it
**************
1)39    CN.ESC:    CAIE    S1,"C"            ; Is is C
1)         CAIN    S1,"c"            ; or lower case c?
1)          JRST    CN.END            ; Yes done
1)        MOVEI    P1,"S"            ; Assume not send control chr
1)        CAMN    S1,ESCAPE        ; Another escape?
1)         JRST    CN.SND            ; Yes, send a real one
1)        CAIN    S1,"?"            ; want help?
1)         JRST    CN.HLP            ; Yes, do it
1)        CAIE    S1,"S"            ; Want status?
1)         CAIN    S1,"s"            ; or lower case "s"
1)          JRST    CN.STS            ; Yes
1)        CAIE    S1,"O"            ; Clear buffers?
1)         CAIN    S1,"o"            ;  .  .  .
1)           JRST    CN.CLR            ; Yes, go clear terminal buffers
1)        CAIE    S1,"Q"            ; Quit logging?
1)         CAIN    S1,"q"            ;  .  .  .
1)          JRST    CN.QUT            ; Quit logging
1)        CAIE    S1,"R"            ; Resume logging
1)         CAIN    S1,"r"            ;  .  .  .
1)          JRST    CN.RSM            ; Yes, do it
1)        CAIE    S1,"^"            ; Want control chr?
1)          JRST    CN.ESE            ; No, bad
****
2)39    CN.ESC:    CAIE    S2,"C"            ; Is is C
2)         CAIN    S2,"c"            ; or lower case c?
2)          JRST    CN.END            ; Yes done
2)        MOVEI    P1,"S"            ; Assume not send control chr
2)        CAMN    S2,ESCAPE        ; Another escape?
2)         JRST    CN.SND            ; Yes, send a real one
2)        CAIN    S2,"?"            ; want help?
2)         JRST    CN.HLP            ; Yes, do it
2)        CAIE    S2,"S"            ; Want status?
2)         CAIN    S2,"s"            ; or lower case "s"
2)          JRST    CN.STS            ; Yes
File 1)    DSKB:K10MIT.MAC[10,52,KERMIT,DST,10] created: 2248 24-May-1984
File 2)    DSKB:KERMIT.MAC[10,52,KERMIT,10]        created: 1753 11-Jul-1984

2)        CAIE    S2,"O"            ; Clear buffers?
2)         CAIN    S2,"o"            ;  .  .  .
2)           JRST    CN.CLR            ; Yes, go clear terminal buffers
2)        CAIE    S2,"Q"            ; Quit logging?
2)         CAIN    S2,"q"            ;  .  .  .
2)          JRST    CN.QUT            ; Quit logging
2)        CAIE    S2,"R"            ; Resume logging
2)         CAIN    S2,"r"            ;  .  .  .
2)          JRST    CN.RSM            ; Yes, do it
2)        CAIE    S2,"^"            ; Want control chr?
2)          JRST    CN.ESE            ; No, bad
**************
1)39        ANDI    S1,37            ; make a control chr
1)        JRST    CN.SND            ; and send it
****
2)39        CAIL    S1,"`"            ;[125] Lower case range?
2)         XORI    S1,240            ;[125] Toggle Parity & case
2)        XORI    S1,300            ;[125] Convert to control
2)        JRST    CN.SND            ; and send it
**************
1)39    CN.SND:    XMOVEI    S2,XFRTRM        ; Get terminal control block
1)        $CALL    T$CCOT            ; Send char down line
****
2)39    CN.SND:    BLSCAL    GEN%PARITY##,<S1>    ; Generate correct parity
2)        XMOVEI    S2,XFRTRM        ; Get terminal control block
2)        $CALL    T$CCOT            ; Send char down line
**************
1)39        XMOVEI    S2,MYTERM        ; Yes, output to our tty also
****
2)39        $CALL    CN.PAR            ; Even parity unless PR%NONE
2)        XMOVEI    S2,MYTERM        ; Yes, output to our tty also
**************
1)39    CN.TYP:    XMOVEI    S2,MYTERM        ; Point to the terminal block
1)        $CALL    T$CCOT            ; Output the character
1)        $RETT                ; and return
1)40        SUBTTL    Command execution -- DEFINE command
****
2)39    CN.TYP:    $CALL    CN.PAR            ;[125] Even parity if needed
2)        XMOVEI    S2,MYTERM        ; Point to the terminal block
2)        $CALL    T$CCOT            ; Output the character
2)        $RETT                ; and return
2)    ;[125] Here to put even parity on a character.
2)    CN.PAR:    MOVE    S2,PARITY%TYPE##    ;[125] Get the parity type
2)        CAIN    S2,PR%NONE##        ;[125] No parity?
2)         $RET                ;[125] Yes, leave it alone
2)        ANDI    S1,177            ;[125] Keep only 7 bits
2)        MOVEI    S2,(S1)            ;[125] Get a copy
2)        LSH    S2,-4            ;[125] Shift back 4 bits
2)        XORI    S2,(S1)            ;[125] Combine halves
2)        TRCE    S2,14            ;[125] Left bits both 0
2)         TRNN    S2,14            ;[125] Or both 1?
2)          XORI    S1,200            ;[125] Yes, change high bit
2)        TRCE    S2,3            ;[125] Right bits both zero
2)         TRNN    S2,3            ;[125] Or both one?
2)          XORI    S1,200            ;[125] Yes, change high bit
2)        $RET                ;[125] All done
File 1)    DSKB:K10MIT.MAC[10,52,KERMIT,DST,10] created: 2248 24-May-1984
File 2)    DSKB:KERMIT.MAC[10,52,KERMIT,10]        created: 1753 11-Jul-1984

2)40        SUBTTL    Command execution -- DEFINE command
**************
1)41    C$EXI0:    $HALT                ; Exit to the monitor
1)        $RETT                ; Allow continues
****
2)41    C$EXI0:    SKIPN    LOGDIN            ;[125] Are we logged in?
2)         JRST    [$TEXT    (,<.KJOB^M^J.^A>) ;[125] No, make a nice msg
2)            LOGOUT    1,        ;[125] And quit
2)            JRST    .+1]        ;[125] Shouldn't get here...
2)        $HALT                ; Exit to the monitor
2)        $RETT                ; Allow continues
**************
1)52        HLLOS    USRFX+.FDEXM        ; . . .
1)        SETOM    USRFX+.FDDIM        ; . . .
****
2)52    ;[126];@C$RECEIVE + 9
2)        HRROS    USRFX+.FDEXM        ;[126] . . .
2)        SETOM    USRFX+.FDDIM        ; . . .
**************

[Ed. - Some of the comments in the above FILCOM listing were edited to
make them fit on the screen.  The patch will be in the next release
of DECsystem-10 Kermit.]

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

End of Info-Kermit Digest
*************************
-------
18-Jul-84 22:05:36-EDT,15014;000000000000
Return-Path: <CC.FDC@CUCS20>
Received: from CUCS20 by CU20B with DECnet; 18 Jul 84 22:04:59 EDT
Date: Wed 18 Jul 84 22:03:37-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #16
To: Info-Kermit: ;
Reply-To: Info-Kermit@COLUMBIA-20

Info-Kermit Digest       Wednesday, 18 Jul 84     Volume 1 : Number 16

Today's Topics:
                     Reminder - How to Get Kermit
                      New Kermit for IBM MVS/TSO
                    New Apple II Kermit-65 Release
                     New Release of DEC-20 Kermit
                       Kermit on Otrona Attache
            Victor Kermit and Problems Transferring to VAX
                         Kermit over Arpanet
                           Kermit and TACs
           Kermit Between IBM PC and Host -- 8 Bit Transfer

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

Date: Wed 18 Jul 84 21:33:15-EDT
From: Frank da Cruz <[e-mail]>
Subject: Reminder - How to Get Kermit
To: Info-Kermit@CUCS20

This issue of the Info-Kermit digest contains announcements of several new
KERMITs.  For the benefit of those who are new to the Info-Kermit list,
and to refresh the memories of those who aren't, here's how to get the
KERMIT files:

ARPANET/Internet:
  Use FTP, connect to host COLUMBIA-20, login as user ANONYMOUS with any
  non-null password, and GET (or MULTIPLE GET) the files you're interested
  in.  Anonymous FTP access to COLUMBIA-20 is allowed only after 6:00pm and
  before 6:00am, eastern time.

CCNET (DECNET hosts at Columbia, CMU, CWRU, NYU, Stevens, and (soon) Vassar):
  Use NFT to COPY the desired files from CU20B::KER:.  If you're on a VAX,
  just use the COPY command.  Specify /USER:ANONYMOUS.  If CU20B does not
  grant you anonymous access, ask your system manager to get the files.

CCNET and ARPANET:
  All KERMIT files are in the area KER:.  Several short files are of particular
  interest:
    KER:00README.TXT
      Guide to what's available, showing file name conventions.
    KER:VERSIONS.DOC
      List of all known KERMIT versions, both available and in progress.
    KER:CURRENT.DOC
      Reverse chronological list of available versions, showing release
      date and version number.

BITNET:
  On an IBM VM/CMS system, type the command SMSG RSCS MSG CUVMA KERMSRV HELP
  to get instructions for how to use the Kermit server at host CUVMA.  There
  is usually a delay between the announcement of a new version of Kermit and
  its availability on BITNET, because each file has to be painfully screened
  and possibly processed to fit the requirements of our RJE link.

Other networks like USENET, MAILNET, etc, or if you're not on a network:

  Send mail to Info-Kermit-Request@COLUMBIA-20, or to:

    KERMIT Distribution
    Columbia University Center for Computing Activities
    612 West 115th Street
    New York, N.Y.  10025

  and we'll send you flyers explaining how to order a distribution tape.

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

Date: Wed 18 Jul 84 18:21:15-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Kermit for IBM MVS/TSO
To: Info-Kermit@CUCS20

Announcing Kermit for MVS/TSO on IBM 370-series and compatible mainframes
from Ron Rusnak of the University of Chicago Computation Center
([e-mail] or [e-mail]).  This is an
adaptation of Columbia's VM/CMS implementation, and it has about the same
characteristics -- a no-frills Kermit, no server operation, no binary
file transfers, and so forth.  The source and documentation files are in
KER:TSO*.* (4 files).  The CMS and TSO versions of Kermit will be
upgraded to a more advanced level in the future.

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

Date: Wed 18 Jul 84 15:49:46-EDT
From: Anton Mione <OC.MIONE@CU20B>
Subject: New Apple II Kermit-65 Release
To: sy.fdc@CU20B

Version 2.1 of Apple II DOS KERMIT-65 is finished.  APPREAD.ME is the usual
'quick summary' of changes.  APPHXL has been changed to be more 'Terse' in
providing information.  It now prints the count and load address for each line
of the .HEX file followed by an '[OK]' if things went well or a '[CHECKSUM
ERROR]' if they did not.  APPDXL has not changed but a .BIN file is now
included.  APPLEK.M65, APPLEK.HEX, and APPLEK.BIN are the new source/object to
release 2.1.

APPLE.MSS is the new format documentation.  This is a first draft and I may
have to make some minor changes before it is really ready to be included in the
user manual.

Some new functionality has been added to KERMIT-65, especially in relation to
CONNECT mode support.  A cursor is now displayed when connected to a remote
host.  Upper case characters appear in inverse so the user can now distinguish
between upper and lower case characters.  Also, characters which can not be
directly generated from the Apple ][ keyboard can now be generated by using a
right-arrow as a prefix character.  The connect-escape processing now has more
options.  Break signals can be sent, etc.  Some bugs have been fixed in the GET
and SEND commands.  KERMIT-65 no longer runs out of buffers in long sessions.
The GET command uses file names out of the File-header packets sent from the
remote Kermit.  There is now an easy way to change the drive which KERMIT-65
uses for file transfers.

Anton:<miONE>

[Ed. - The program now supports the Apple II, the II+, and the IIe (with
certain limitations on the IIe), and the Apple Comm Card, the Apple Super
Serial Card, and the DC Hayes Micromodem II.  The files are available in
KER:APP*.*.]

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

Date: Wed 18 Jul 84 18:51:09-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Release of DEC-20 Kermit
To: Info-Kermit@CUCS20

Announcing a new release of DECSYSTEM-20 Kermit, 4.1(236).  The major change in
this version is to move the code for connecting to a remote system into the
Kermit-20 program itself, rather than running another program (TTLINK) in a
lower fork.  The connect code now runs in two forks (a`la TELNET), and is not
interrupt driven, unlike TTLINK which ran in one fork and was interrupt driven.

This was done for several reasons --

. It allows Kermit-20 to run in local mode under TOPS-20 version 6.0, which
  does not allow multiple simultaneous opens of a TTY device.

. It gives the user greater control over communication options, like line
  speed, BREAK simulation, flow control, etc.

. It allows Kermit-20 to run in local mode under batch, for instance to
  dial a remote system at midnight and send or get files.  This was not
  possible with TTLINK, which did not send the appropriate "pty-hungry"
  signals to BATCON.

As a consequence of this change, several new commands have been added --
CLOSE (to explicitly close the various kinds of log files), SET SPEED,
SET BREAK, PUSH.  The files are in KER:20KERMIT.*, including a new
20KERMIT.DOC.

- Frank

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

Date: 16 Jul 1984 0759 PDT
From: Richard B. August <[e-mail]>
Subject: Kermit on Otrona Attache
To: info-kermit-request@columbia-20

I have been successful in getting Kermit up on my Otrona Attache, however,
I am experiencing some "difficulties" in transfering .COM (IMAGE) files
from my VAX. Additionally I have had "NO LUCK" transfering files (IMAGE)
from SIMTEL20. Does anyone have a KERMIT working on an Otrona Attache? If
not I will FTP the source I have (along witmy changes) to see what mistakes
I have made.

Thanks in advance.

Regards, Richard

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

Date: Mon 16 Jul 84 14:37:14-EDT
From: JUNGER@CWRU20
Subject: Victor Kermit and problems transferring to VAX.
To: info-kermit@CUCS20

    I noted to queries in the current INFO-KERMIT which may relate
to the same experience which I had.  One was about Sirius/Victor.  We
have just gotten the MSDOS version of Kermit up on a Victor 9000, and,
though we have not done much experimenting, it seems to work fine.  We
transferered the Kermit .COM file itself to a DEC 20 and returned it to
the Victor and it ran just as it should upon its return.  But!!! we had
trouble getting the DEC to receive if from the the Victor using the receive
command on the DEC.  The symptoms were that the Victor showed exactly
the same symptoms as were reported by Marco Papa when trying to send
a file to a VAX at 9600 baud.  We were only running at 1200 baud.  The
solution was to put the DEC in the server mode.  I don't know if the VAX
version allows it to be run as a server, but it might be worth trying.

P. Junger

[Ed. - That's a strange one.  DEC-20 Kermit does nothing different in server
mode, except that it parses its commands from packets rather than the keyboard.
The communications line conditioning and protocol should be exactly the same.
I'd tend to chalk it up to coincidence.  But just to make sure, get the latest
version of DEC-20 Kermit - 4.1(236) - announced above, and see if the problem
persists.]

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

Date: Tue 17 Jul 84 17:44:41-EDT
From: J. Eliot B. Moss <[e-mail]>
Subject: Kermit over Arpanet
To: [e-mail]

I regularly log in through a TAC from a Z80 based machine to MIT-XX, a
TOPS-20 site.  I have used the MODEM7xx program for file transfer in the
past, and typically have had success only in downloading.  I run at 1200
baud.  I understand a lot about the Arpanet protocols, etc., having done
some work to get a version of MODEM running on the 20.  I have had no success
getting Kermit on XX to talk to my local Kermit.  The TOPS-10 compatibility
stuff is a crock to begin with; but mainly it would appear that characters
just do not flow, even though I can type (as in the CONNECT command) through
my local Kermit.  Any hints on what to do?

[Ed. - See next message.]

For your info, I have downloaded the CP/M version of Kermit, and created
versions for the following:
    Molecular SuperMicro (terminal type selectable by EQU)
    Altos 8000-10 running MP/M (terminal type by EQU)
    Altos 8000-10 running CP/M (terminal type by EQU)
    my home micro (Morrow Design Mult I/O board)

In the process, I made it easy for people using the Z80CTC to set the
baud rate, and for those using the NS8250 asynch chip to init and set
the baud rate.  Of course, some systems vary baud rate clocks, so adjustments
may have to be made, but code works out well.

[Ed. - Charles@ACC, are you listening?  You might want to incorporate this
code into version 4.]

I want to suggest that future versions be done in Turbo Pascal -- you can
do up insert files to adjust system specific things, achieve modularity,
etc.  It would be much easier to maintain, though likely lead to bigger
com files.

[Ed. - Any volunteers?]

Anyway, thanks in advance for any assistance you can give me.
                Eliot

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

Date: 17 Jul 1984 10:41-EDT
Subject: Kermit and TACs
From: [e-mail]
To: [e-mail]

NetLandians,

Hard keeping up with what KERMITs can do, with all the wizards improving all
the time.  However, I learned a new trick with my host's KERMIT-20 and my
own KERMIT-80 (CP/M) for working through a TAC.

The TAC, as you may know, is a purely 7-bit medium and does a real job on
any binary files going through it.  Some KERMITs have the ability to "prefix"
binary characters to enable you to pass data through such 7-bit media.
However, the trick is how to make your KERMIT do that!

By setting my host's KERMIT-20 with parity (I used a nice innocuous "Even"),
that forces KERMIT-20 to prefix binary characters.  It KNOWS it has to fiddle
that 8th bit, so it changes everything to its 7-bit prefixed equivalent.

The TAC is gonna strip off that parity bit anyway, but no harm done!

Down at the micro, you don't have to do anything!  Just do your normal receive,
and KERMIT-80 DOES know how to change prefixed data back to real 8-bit.

You will truly get an effective 8-bit data download through a 7-bit medium.

For uploads, a little more trickiness.  Tell your KERMIT-20 on the host to
SET FILE to BYTESIZE 8, so it knows it'll be getting true binary.

Tell your local KERMIT-80 you're sending in FILE-MODE BINARY, and SET
PARITY EVEN, so YOUR KERMIT will know to prefix binary.  Again, the TAC
will strip that 8th bit during upload, but who cares?  The host KERMIT-20
changes things back to a nice 8-bit character and files it correctly as
8-bit files, and all is well.

For a test, I downloaded an ITS-binary formatted file from my host through
the TAC, and then uploaded it again as a pure 8-bit file.  Then downloaded
it again as a pure 8-bit file (no ITS-binary this time).  The two versions
on my micro (the converted ITS-binary one and the new 8-bit one) matched
exactly.

Damn, these KERMITs are clever!

Regards,
David Kirschbaum
Toad Hall
ABN.ISCAMS@USC-ISID

[Ed. - As a matter of fact, DEC-20 Kermit has a command "SET TVT-BINARY",
which should take care of all this for you, provided your TOPS-20 monitor
is set up for it.  This command will tell the TAC to put itself in binary
mode, and then will take the TAC out of binary mode when the transfer is
over.  But if your TOPS-20 monitor is not set up to do this -- several
patches popular among ARPAnet TOPS-20 sites are necessary -- then your method
is a good alternative, except that you shouldn't SET FILE BYTESIZE 8, etc,
for ASCII (text) files if you want them to be usable on the DEC-20.  All this
is described in the DEC-20 Kermit manual, KER:20KERMIT.DOC.]

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

Date:  Tue, 17 Jul 84 23:57 EDT
From:  [e-mail]
Subject:  Kermit between IBM PC and host -- 8 bit transfer
To:  [e-mail]
ReSent-To: [e-mail]

Previous messages have (correctly) noted that the host is capable of
receiving 8 bit files from Kermit if it is instructed to expect them.
I believe that it is impossible to download them back to the IBM PC,
however.

The transfer mysteriously "hangs", with the host Kermit still trying to
send the file, but the PC end reports a message and aborts the transfer.
I actually have to disconnect (turn my modem off, redial up again) and
abort my old process, or the Multics Kermit will continue to spew out
garbage.  Apparently, the problem is that 8 bit quoting doesn't work
properly on IBM-PC Kermit.  Hopefully, that shortcoming will be
corrected in the new, fully modularized MSDOS Kermit which will be
released real soon now.

[Ed. - MS-DOS Kermit 1.20 cannot do "8th-bit quoting" and so cannot
transfer binary files over a 7-bit connection.  The forthcoming release
will be able to do this.]

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

End of Info-Kermit Digest
*************************
-------
23-Jul-84 12:43:27-EDT,12455;000000000000
Return-Path: <CC.FDC@CUCS20>
Received: from CUCS20 by CU20B with DECnet; 23 Jul 84 12:42:55 EDT
Date: Mon 23 Jul 84 12:42:04-EDT
From: Frank da Cruz <CC.FDC@CUCS20>
Subject: Info-Kermit Digest V1 #17
To: Info-Kermit: ;
Reply-To: Info-Kermit@COLUMBIA-20

Info-Kermit Digest       Monday, 23 July 1984     Volume 1 : Number 17

Today's Topics:
                      Kermit Directory Listing
                       Apple II Kermit-65 V2.1
                           KERMIT-80 vs TAC
                    More About UNIX Kermit Problem
         Wierd Things with Kermit-11 RT11 and CONNECT Command
                             FLEX Kermit?
                      Kermit for Cromemco OS's?

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


Date: Mon 23 Jul 84 11:47:51-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit Directory Listing
To: [e-mail]

Users at some network sites have complained that their FTP implementations
do not support the MULTIPLE GET function.  Therefore, they need to know
the exact name of each file before in order to GET the desired files one
by one.  Starting now, there will be a new file in the Kermit network
distribution area on COLUMBIA-20, KER:FILES.DIR.  It contains an
alphabetical listing of all the Kermit files, including their sizes and
dates.  The directory listing will be updated automatically each morning
at 3am, eastern time.  Here are the first few lines to illustrate the
format:

   PS:<KERMIT>
          PGS Bytes(SZ)  Write

 00README.TXT.50    5 12347(7)   18-Jul-84
 170AZLIB.ASM.1    27 66670(7)   25-May-84
 170KERMIT.DOC.3    9 22498(7)   11-Jun-84
   .FOR.2          67 170230(7)  25-May-84
   .MSG.1           1 1453(7)    25-May-84
   .MSS.1           8 18347(7)   11-Jun-84
   .NR.1            4 8914(7)    18-Oct-83
 20CMD.DOC.1        4 9229(7)    14-Aug-78
   .MAC.1           4 7794(7)    10-Jun-81

PS:<KERMIT> is the name of the directory, for which we normally use the
"logical device name" KER:.  00README.TXT.50 is the name of the first file
in the directory, which is a text file containing an explanation of what
is available and the naming conventions used.  "00README" is the file name,
"TXT" is the file type (text), and "50" is a generation number, which should
normally not be used explictly.  Note that for files of the same name, but
differing types and generations, the listing omits the name on subsequent
lines, although you must supply it in order to refer to the file.  For
instance,

 20CMD.DOC.1        4 9229(7)    14-Aug-78
   .MAC.1           4 7794(7)    10-Jun-81

denotes two files, 20CMD.DOC and 20CMD.MAC.

The number in the PGS column shows the size in DEC-20 "pages" (units of
512 36-bit words, or 2560 7-bit ASCII characters, or 2048 8-bit bytes).
The next two numbers show the length in bytes, and the size of the bytes.
Normally, the bytesize has the following significance:

7   ASCII text (program source, documentation, hex files)
8   "Foreign" 8-bit binary files (from micros and other 8-bit-byte systems)
36  PDP-10 or DEC-20 36-bit binary files

The final column shows the write date for the file.  A chronological
listing of the currently available Kermit versions can be found in
KER:CURRENT.DOC.

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

Date: 18 Jul 1984 2208 PDT
From: Ken Adelman <[e-mail]>
Subject: Apple Kermit V2.1
To: Info-Kermit@COLUMBIA-20

    After I received digest #16, announcing the new apple kermit, I
ftp'd KER:APPLEK.HEX from columbia-20 (between 9 and 10pm pdst jul 18) and
kermit'd it to my apple useing V2.0 of kermit. The file APPLEK.HEX contains
the old version V2.0 rather that the new version V2.1. Did someone forget
to update something?
    Frustration is maximized since the load address moved by a byte from
$800 to $801 in the version change, which gives the appearence of trash when
one saves from $801 (for V2.1), and because I have a Super Serial Card, which
requires a bug-fix for V2.0 and not V2.1.
    Please update the file.

                        thanx,

                        Ken Adelman
                        Caltech

[Ed. - Sorry!  Thanks for pointing it out.  The error was corrected soon
after the announcement was made.]

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

Date:  Fri, 20 Jul 84 09:25 CDT
From:  "David S. Cargo" <[e-mail]>
Subject:  Apple II Kermit-65
To:  [e-mail]

I don't know how often people plan for future versions of Kermit, but I
thought it would be worthwhile pointing out some problems that have just
been created.  There are two major sources of incompatibility between
the Apple IIc and the other earlier Apples.  One is the disk drive; this
is a major concern only of you are producing or using copy protected
software.  The other is the character set displayed on the screen.  The
inverse video characters have been replaced by graphics characters at
least in some cases.  This means that when Kermit for the IIc is done by
somebody, there will be problems (or perhaps might be).  I don't own any
kind of Apple, so I can't verify the problem.  My information comes from
an article recently published in InfoWorld.  If you are interested in
minimizing differences between versions of Kermits for Apples, somebody
might want to experiment and develop a common solution.

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

Date: 19 Jul 1984 02:00-EDT
Subject: KERMIT-80
From: [e-mail]
To: [e-mail]

A recent input to our Info-Kermit Digest commented on several new I/O drivers
for CP/M systems.  The 8250, as used on the Morrow Multi I/O board, is
already implemented (Charles has it too), and works fine at 300 to (I guess!)
52000 - just kidding, but for sure 9600.  No parity fiddling on the board -
just baud rate.

I too work through a TAC with my Decision I, and have no problems up or down.
I understand there are many bells and whistles on the KERMIT-20 to permit
binary transfer, disabling TAC intercept char, etc., but my local wizards
frown on too much fiddling with their TAC, so I've done most of it within
KERMIT.  The World Famous Toad Hall TACTrap handles intercept characters
(just screens for them during packet or straight upload transfers, and
sends the designated intercept character twice!  That takes care of the TAC!).
TACs usually have kind of small input buffers, so you have to set the host
(or local) KERMIT to maybe 50 or 60 character packets during upload.

Any kind of flow control engaged messes things up:  I leave it up to the
KERMIT-20 to take care of all that.

I too have problems with MDM7nn uploading, specifically because the TAC
can't handle those 128-byte packets, so I use KERMIT exclusively for uploads
when I'm doing binary.  For normal text, I usually just engage Xon/Xoff
flow control and use MDM7nn (or my new patched KERMIT 4.0 with a MDM7nn-
like Xon/Xoff straight upload) to move ascii into an editor.

If that gentleman can't work out KERMIT for uploads, please contact me
directly and I'll send you parts of source, whatever, to make your system
work through the TAC.

Last point -- can someone give me pointers to the wizards playing with
floating windows and KERMIT.  I'm curious as to their approach, having
several ideas myself but no practical knowledge.

Regards,
David Kirschbaum, Toad Hall
ABN.ISCAMS@USC-ISID

[Ed. - We'll be looking into a windowing option for Kermit this summer at
Columbia, but no guarantees that we'll accomplish anything!]

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

Date: Thu Jul 19 1984 16:36:18
From: Marco Papa <[e-mail]>
To: [e-mail]
Subject: More about UNIX Kermit problem

For background on this problem, please read Vol. 1, number 15.

I used debug mode on both sides of UNIX and PC-DOS kermits and these are the
results:

The 3 packets that are sent by PC-DOS Kermit for a text file of name
TEST.FOR are as follows (each packet is preceded by the SOH char that on the
PC appears as the small face):

1.    ) S~% @-#R    (Send Initiate)

2.    +!FTEST.FORJ    (File header)

3.    |"DTEST.FORJ    (Data packet)

After trying 5 times on the third packet PC Kermit aborts saying that cannot
receive acknowledgement from the host.  If I connect back to UNIX now I
get the following data (I run it with dd mode):

spack type: N, num: 2, len: 0, recstate: D, data: SOH followed by #"N5

This seems to me as the standard NAK packet.  This packet is sent a number
of times, until UNIX kermit finally aborts and exits.

What is not clear to me is why PC Kermit sends the filename into a Data
packet after having sent it in the File Header packet, since the filename
was not in the text file at all.

Also, you there Kermit hackers, are the various fields in the packets
correct?

Marco Papa
USC Computer Science Dept.
ARPA, CSNET: papa.usc-cse@csnet-relay
UUCP: ..!randvax!uscvax!papa

[Ed. - Very strange...  We've been running PC Kermit 1.20 heavily for a
long time and have never seen such behavior.  Rather than try too hard to
track it down, better to just get the new release, which should come out
any day now.  Really!]

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

Date: Thu 19 Jul 84 00:53:50-PDT
From: Carl Fussell <[e-mail]>
Subject: rt kermit from Stevens...
To: [e-mail]
Address:  Santa Clara University

I recently got the new Stevens release of kermit-11 and from k11rt4.com
(the linker command file if I remember correctly) figured out most of
the necessary files to compile it.   I am doing this on an 11/23 running
RT-11   V5.0  with multi term support.    All compiled correctly after
locating the .Included files but when I linked it, got a multiple
definition on labe DIRER$.    It appears that routine is coded into
2 modules...  K11CMD.MAC and K11RT4.MAC. (???)   I commented out one
of them (K11RT4 arbitrarily) and all compiles and links ok.  Just wanted
to let someone know this duplication was there.

The resulting kermit still does not work properly unfortunately.  I can
start it and (after setting line and speed) connect to host and work.
This moment I "escape" back to local kermit, I get the prompt but then
appears to cease all output to terminal.   As soon as I type a couple
of ^C's, then any and all output that was generated while kermit was
"frozen" appears and kermit terminates (from ^C's).   Has anyone else
run into any problems that you are aware of?  If so, can you let me
know who so I can contact them...  perhaps they have fixed them.

thanx...

        Carl Fussell
        G.FUSSELL@SU-SCORE

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

DATE: MON, 23 JULY 1984
FROM: ATSBDN AT UOFT01
TO: SY.FDC AT CU20B
SUBJECT: KERMIT AND RT11

The RT11 problem about Kermit-11 not accepting input after returning
from the connect command has been solved.  Kermit-11 will not run under
the SJ (single job) monitor.  There must be some call that gets lost
on the SJ exec, or else there is a bug in doing the .MTDTCH call to
release the terminal from MT service.  If anyone has any ideas, I will
be glad to look into it but for now, simply run FB or XM.  Since this
problem is trivial to work around, getting Kermit-11 to run under SJ
will be placed on the back burner.
                                              Brian Nelson

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

Date: 18 Jul 84 16:27 +0200
From: [e-mail]
To: [e-mail]
Subject: FLEX Kermit?

Is there anyone outthere who can reach John Guidi Jackson lab? He is working
on a FLEX-implementation of Kermit. I would like to give him some mental
support and if necessary any other help.

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

Date: Sat 21 Jul 84 17:50:16-PDT
From: Phillip W. Barth <[e-mail]>
Subject: KERMIT for Cromemco OS's?
To: [e-mail]

Has anyone put together versions of KERMIT to run under Cromemco's operating
systems (CDOS, C-10 CDOS, or Cromix)? As I understand it, the I/O byte is
different for the CDOS systems so that generic CP/M KERMIT won't work
directly. Any info will be appreciated.

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

End of Info-Kermit Digest
*************************
-------
27-Jul-84 17:54:20-EDT,13732;000000000000
Return-Path: <CC.FDC@CUCS20>
Received: from CUCS20 by CU20B with DECnet; 27 Jul 84 17:53:48 EDT
Date: Fri 27 Jul 84 17:51:32-EDT
From: Frank da Cruz <CC.FDC@CUCS20>
Subject: Info-Kermit Digest V1 #18, Special MS-DOS Edition
To: Info-Kermit: ;
cc: [e-mail], [e-mail]

Info-Kermit Digest       Friday, 27 July 1984     Volume 1 : Number 18

Today's Topic:
                   New Release of Kermit for MS-DOS

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

Date: Fri 27 Jul 84 17:45:00-EDT
To: Info-Kermit
From: Frank da Cruz <[e-mail]>
Subject: New Release of Kermit for MS-DOS

This issue of the Info-Kermit Digest is devoted to the long-heralded (and
overdue) announcement of version 2 of Kermit for MS-DOS systems (Kermit
is Columbia University's file transfer protocol for use over
telecommunication lines, and it runs on a wide variety of systems).  We
announced our intention to provide this new release back in January, and
have been working on it ever since.  The previous release was 1.20, 28
November 1983.

The new version is called "Kermit-MS" rather than "Kermit-86" and the
version number is 2.26.  It is available for several systems:

    System                      DOS Versions
    ------                      ------------
    IBM PC, PPC, and XT         1.1, 2.0 & above
    DEC Rainbow 100 and 100+    2.05 & above
    HP-150                      2.0
    Wang PC                     2.01
    Others (Generic DOS)        1.1, 2.0 & above

Versions for the IBM PCjr and Heath/Zenith 100 are soon to be added
(version 1.20 already run on these machines).  If your MS-DOS system is
not on this list, you are invited to add support for it by supplying the
appropriate system- and device-dependent modules (described below).

The IBM version has been tested on IBM PCs with the old and new
motherboards and ROMs, as well as on the XT and Portable PC, on hard
disks, floppy disks, and RAM disks, and on color and monochrome monitors.
It has NOT been tested on the Compaq, Columbia, or other "PC compatible"
product; there is some chance that it might not work on the compatibles
even when the previous release (1.20) did, because of greater dependence
on the display hardware.

Version 2 of MS-DOS Kermit has been tested successfully up to 9600 baud on
the IBM, DEC, HP, and Wang micros, in communication with full duplex
systems like the DEC-20 and VAX, and half duplex systems like IBM
mainframes.  Kermit-MS requires about 80K RAM, and certain functions like
PUSH and RUN will need additional memory.  Thus, for DOS plus Kermit, you
will need a machine with at least 128K.  Version 1.20 can run on a 64K
machine.

Version 1.20 will remain available indefinitely because it has proven
quite stable, runs on a variety of PC-compatible systems, and is
considerably smaller than version 2.

Here is a summary of the changes:

* Program organization:

The program has been broken up into separate source files, assembled
separately, and linked together.  The modules are:

System/Device Independent:

    MSKERM.ASM - Main program
    MSSEND.ASM - File sender
    MSRECV.ASM - File receiver
    MSSERV.ASM - Server operation
    MSFILE.ASM - File i/o
    MSCMD.ASM  - Command parser
    MSTERM.ASM - CONNECT command
    MSCOMM.ASM - Communications port buffering & flow control
    MSSET.ASM  - SET, SHOW, and STATUS commands
    MSDEFS.H   - Data structure definitions and equates

System/Device Dependent:

    MSXxxx.ASM - System-dependent code for system xxx
    MSYxxx.ASM - System-dependent screen and keyboard code
    MSZxxx.ASM - Modem control (modem-dependent)

    MSXSYS.DOC - Description of system-dependent modules

The modular organization allows easier modification of the program,
quicker transfer of modified portions from system to system.  The modules
are designed to be well-defined and self-contained, such that they can
be easily replaced.  For instance, someone who prefers windows and mice
to typing commands could replace the command parsing module without having
to worry about the effect on the other modules.

* Kermit Protocol Improvements:

Kermit-MS now supports:

. 8th-bit prefixing for passing binary data through 7-bit communication links
. 12-bit checksums and 16-bit CRCs as alternate block check types
. Compression of repeated bytes
. Server operation
. Advanced commands for servers, including:

    REMOTE DELETE
    REMOTE DIRECTORY
    REMOTE HELP
    REMOTE HOST
    REMOTE SPACE
    REMOTE TYPE

These advanced protocol features can be used in conjunction with other
advanced Kermit implementations, including itself, as well as the current
Kermits for the DECsystem-10, DECSYSTEM-20, VAX/VMS, PDP-11 (RSX, RSTS, RT),
DEC Pro-350, and others, and soon to include IBM VM/CMS and UNIX.

* Local command execution:

The following new commands provide access to DOS functions from within the
Kermit-MS program:

    DELETE
    DIRECTORY
    SET DEFAULT DISK
    PUSH (to DOS)
    SET DESTINATION (device - disk or printer)
    SPACE (runs CHKDSK)
    RUN (a program)

* Command parsing:

The command parser has been improved in many areas.  For instance, "?" now
works much better than before (though still not perfectly).  ESC now
provides completion not only in keywords, but also in filenames.  CTRL-W
deletes the previous "word" on the command line.  CTRL-C always returns to
the Kermit-MS> prompt.

There is a command macro facility; DEFINE lets you build macros by
combining Kermit-MS commands, DO executes them, SHOW displays them.

DOS command line arguments are accepted, and may be strung together
separated by commas, e.g. "kermit set baud 9600, set timer on, connect"

Kermit-MS now reads an initialization file, MSKERMIT.INI, and can process
(nested) command files with a TAKE command.

* Terminal emulation:

On IBM micros, the speed of Heath-19 terminal emulation has been improved
by using direct screen memory access.  Functions like insert and delete
character now execute very rapidly.  Heath-19 emulation functions, such as
reverse index, missing from earlier releases are now supplied.  H19
emulation may be disabled to allow the use of other console drivers, like
ANSI.SYS, in conjunction with Kermit-MS.

On systems with 25 lines, the 25th line is an inverse video mode line,
displaying current settings, which may be kept or turned off.  On the IBM
and DEC systems, there are pop-up help and status screens, and the screen
is saved and restored between remote/local context switches.

The terminal session can be logged to disk to provide unguarded capture of
remote files or session typescripts.

On the IBM, DEC, and HP systems, the screen can be rolled back several
pages, on a per-line or per-screen basis.

On most of the systems, print-screen (screen dump) and CTRL-print-screen
(toggle printing on/off) work as they do in DOS.

On the IBM and DEC systems, a key redefinition facility is available to
allow the layout of the keyboard to be altered to suit individual tastes,
to set up keypads or function keys for specific applications, or to
construct "keystroke macros".  On IBM micros, the ALT key can be set up
for use as a META key for use with EMACS-like editors.

All versions of Kermit-MS except the generic DOS version are capable of
transmitting the BREAK signal.

The functions that are missing from the Wang and/or HP micros -- key
redefinition, pop-up menus, screen rollback, screen print -- were omitted
due to lack of information about how to get at the scan codes, screen
memory, printer interrupts, etc, and may be added at a later time.
Meanwhile, anyone out there who has the information and feels inclined to
add missing features is invited to do so.

* Communication options:

The port characteristics are left alone when Kermit-MS starts (in the
previous release, Kermit-MS always set the baud rate).  The program allows
settings for speed, duplex, flow control, handshake, and parity on a
per-port basis, to allow convenient switching between ports.

* File Transfer:

You can now supply new names for files in SEND and GET commands.

A timeout facility has been added to allow automatic recovery from
deadlocks when communicating with systems (like IBM mainframes) that can't
time out.

The file transfer display has been reformatted, and includes more useful
information, including a percentage for outbound files.  The various
counts are updated more reliably.

Several options are available for interrupting file transfer, including
^X (cancel current file), ^Z (cancel entire batch), ^E (user-generated
"error"), ^C (return immediately to command level), CR (simulate a timeout).
The options are displayed during file transfer.

There is a new end-of-file option to allow selection of DOS-style (believe
the DOS byte count) or CP/M-style (file ends at first CTRL-Z) EOF detection.

* Remote operation:

Kermit-MS may be run from the back port in either interactive or server mode.
This allows micro-to-micro file transfer without requiring an operator on
both ends.

* New Bootstrapping Procedure:

The Kermit .EXE files for the various systems are now encoded using a
printable 4-for-3 encoding, with compression of repeated 0 bytes.  The
result tends to be smaller than the original .EXE file.  A new set of
bootstrapping programs has been provided:

MSMKBOO.C      Encode.  Can be used on any binary file.   Written in C.
MSBOOT.FOR     Send the encoded file from the mainframe.  Fortran.
MSPCTRAN.BAS   Decode the encoded file on the micro.      MS Basic.
MSPCBOOT.BAS   Receive on the micro, decode on the fly.   MS Basic.

* Documentation:

There's an entirely new manual, available now as a separate document,
soon to be incorporated into the Kermit User Guide.  It describes
operation of the program in detail, along with the new bootstrapping
procedure.

* How To Get It:

Kermit is available for a wide variety of systems -- micros, minis, and
mainframes.  It is distributed by Columbia University via network or on
magnetic tape.  For further information about Kermit, send network mail to
INFO-KERMIT-REQUEST@COLUMBIA-20, or write to the Kermit Distribution
address below.  To be added to the Info-Kermit network mailing list, mail
to INFO-KERMIT-REQUEST@COLUMBIA-20.

The new MS-DOS Kermit files are available from COLUMBIA-20 via anonymous
FTP after 6pm daily (ARPANET), though KERMSRV at CUVMA on BITNET (BITNET
users should type "SMSG RSCS MSG CUVMA KERMSRV HELP" for information about
the Columbia Kermit file server), and on all the Columbia DEC-20 systems
in the KERMIT area.  The file names all begin with "MS" (on BITNET, omit
the "KER:" prefix).

The executable programs have the suffix .EXE and are in 8-bit binary
format.  The corresponding 7-bit ASCII encoded files have the suffix .BOO.
The system-specific programs are available in both .EXE and .BOO formats.

    KER:MSIBMPC -- IBM PC, XT
    KER:MSIBMJR -- IBM PCjr (not yet availble)
    KER:MSRB100 -- DEC Rainbow 100, 100+
    KER:MSHP150 -- Hewlett-Packard 150
    KER:MSHZ100 -- Heath/Zenith 100 (not yet available)
    KER:MSWANG  -- Wang PC
    KER:MSGENER -- Generic DOS

KER:MS*.ASM, KER:MS*.H are the assembler source files.
KER:MSBUILD.HLP tells how to build the program.

KER:MSKERMIT.DOC is the new MS-DOS section for the Kermit User Guide.
KER:MSKERMIT.MSS is the Scribe source for the .DOC file.

Those without network access may write to the following address for
details of how to order a complete Kermit distribution on 9-track
magnetic tape:

    KERMIT Distribution
    Columbia University Center for Computing Activities
    612 West 115th Street
    New York, NY  10025

Version 2 of MS-DOS Kermit will be submitted to PC-SIG so that it can be
ordered on IBM PC floppy disks.  Inquiries should be directed to

    PC Software Interest Group
    1556 Halford Avenue, Suite #130
    Santa Clara, CA  95051
    Phone [phone]

Be sure to wait until they have version 2, because they are presently
distributing version 1 on their disks numbers 41 and 42.  It may take
some time for them to update their distribution.

* Credit:

The bulk of the work was done by Daphne Tzoar and Jeff Damens of the
Columbia University Center for Computing Activities.  Many ideas (and
"existence proofs") were contributed by Herm Fischer of Litton Data
Systems -- key redefinitions, remote and server operation, etc, but those
who have been using Herm's modified 1.20 will find that some of the
features he added have been done differently in this release.  8th-bit
quoting was originally added by Leslie Spira and her staff at The Source
Telecomputing to allow Kermit to transfer binary files over Telenet.  The
new bootstrapping procedure and the new file transfer display were done by
Bill Catchings of Columbia.  Filename completion came from Kimmo Laaksonen
at the Helsinki University of Technology.  Some corporate support and
encouragement was provided by Digital Equipment Corporation, Wang
Laboratories, and IBM.

* Disclaimer:

Although we have been using the new version on several different kinds
of systems for a good while and have done extensive testing, some bugs
may have slipped through.  Please hang on to your old release (1.20),
and don't hesitate to report any problems to Info-Kermit@COLUMBIA-20.
Suggestions and contributions are also welcome.

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

End of Info-Kermit Digest
*************************
-------
31-Jul-84 10:25:11-EDT,16952;000000000000
Return-Path: <CC.FDC@CUCS20>
Received: from CUCS20 by CU20B with DECnet; 31 Jul 84 10:23:23 EDT
Date: Tue 31 Jul 84 10:23:34-EDT
From: Bill Catchings <CC.WBC3@CUCS20>
Subject: Info-Kermit Digest V1 #19
Sender: CC.FDC@CUCS20
To: Info-Kermit: ;

Info-Kermit Digest       Mon, 30 July 1984       Volume 1 : Number 19

This week's editor:  Bill Catchings

Today's Topics:

                New Release of PR1ME Kermit Available
                   Several New Documents Available
                      Kermit in Modula-2 or Ada?
                        Kermit in Turbo Pascal
                Franklin CPM Kermit, Apple Kermit 2.1
                  Kermit Distribution Unfairness (2)
                      Problems loading Kermit-10
                             UNIX Kermit
                        Kermit for rsx11m+ (2)
                        Kermit-MS for NEC APC
                             SDS Kermit?
            Bug fix for new MSPCTRAN.BAS bootstrap program

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

Date: Fri 27 Jul 84 18:01:15-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit
To: Info-Kermit@CUCS20

As many of you may have noticed, COLUMBIA-20 was down for several days.
During that period of relative calm, we were able to get the new MS-DOS
Kermit put together sufficiently for release.  I'm sure we'll be getting
many reports about it, and we'll collect them all for the next release
which will be dedicated to incorporating fixes for reported problems.

Meanwhile, I'll be going on vacation for the month of August, so some of
the other Kermit folks will be running the Info-Kermit digest.  This issue
is a trial run.  Keep addressing your comments, contributions, requests,
complaints to Info-Kermit or Info-Kermit-Request at COLUMBIA-20, but not
to me personally, because I won't be here to read them until September.

- Frank

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

Date: Mon 23 Jul 84 15:05:24-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Release of PR1ME Kermit Available
To: Info-Kermit@CUCS20

This is to announce a new release of Kermit for PR1ME computers running
PRIMOS R18 and R19.  It was submitted by Nancy K. Morrison of SPSS, Inc,
in Chicago and includes bug fixes and enhancements to the original version
contributed by The Source, as well as a special conversion facility for
SPSS "portable files".  The new files are in KER:PRIMEK.*.  Some of the
changes are:

1. Break handler fixed so quits are done cleanly.

2. Received files are now renamed when they already exist on disk.

3. The compiling and linking files were modified to ran at PRIMOS rev 18,
   and a new CPL program was added to copy the tree structure with rev 18
   commands.  Kermit does run at rev 18, but not with the server command
   "attach" (CWD).

4. New PORTFILE command for SPSS files.

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

Date: Wed 25 Jul 84 11:13:16-EDT
From: Frank da Cruz <[e-mail]>
Subject: Several New Documents Available
To: Info-Kermit@CUCS20

Several new documents are available in the Kermit distribution area.

KER:K11FIL.DOC contains a description of what all the PDP-11 Kermit
files are (Brian Nelson, U of Toledo).

KER:KINTRO.DOC is an introduction to Kermit for the inexperienced computer
user, with emphasis on micro-to-micro file transfer (Norman Weatherby of the
Columbia University Center for Population and Familty Health).

KER:APPLE.DOC (Antonino Mione, Stevens Inst of Tech, and Peter Trei,
Columbia U) is an update of the new Apple DOS Kermit manual in which several
minor errors are corrected.  KER:APPLE.MSS is the Scribe text formatter
source for this file.

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

Date: Monday, 23 Jul 1984 14:19-EDT
From: munck@Mitre-Bedford
To: Info-Kermit@Columbia-20
Subject: Kermit in Modula-2 or Ada?

  I haven't seen any mention of a kermit in either of these "languages of
the future."  Is anyone out there working on either?  Failing that, which
of the various Pascal kermits would be "best" to translate/re-code into
one or both? By "best" I mean (priority order):

   o a clean implementation; modular, readable, untricky, uniform.

   o complete with as many of the standard features and optional goodies
     as possible.

   o makes good use of Pascal extensions that are in the direction of
     Modula-2 and Ada; strings, units, etc.

  Eventually, of course, we'll need only the Ada implementation, as Ada will
be supported everywhere on everything.  Those of you still in your teens may
live to see that, if you take very good care of yourselves.
            -- Bob Munck

ARPA: munck@mitre-bedford
uucp: {allegra,genrad,ihnp4,utzoo,philabs,decvax}!linus!bccvax!munck
USPS: The MITRE Corporation, MS A134, Bedford, MA 01730
      [phone]

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

Date: Wed, 25 Jul 84 08:40:04 EST
From: decvax!mulga!stephenw.murdu@Berkeley (Stephen Withers)
To: [e-mail]
Subject: Kermit in Turbo Pascal

I think the idea of rewriting Kermit in Turbo Pascal is a very good one
for the following reasons:
* It will allow more Kermit users to contribute to the development and
  maintenance of the program (everyone can afford Turbo Pascal, especially
  with their new educational licencing)
* It will allow greatly increased commonality between the CP/M-80, CP/M-86,
  and MS-DOS versions
* Borland might let us use their "general installation program" which
  would make Generic Kermit look nicer (as screen formatting would be
  possible without editing and recompilation).

As always, the problem is finding someone prepared to do the work...

Steve

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

Date: Tue, 24 Jul 84 10:59:39 EDT
From: Dave Swindell <dswindel@bbn-labs-b>
Subject: Franklin CPM Kermit, Apple Kermit 2.1
To: info-kermit@columbia-20

I have a Franklin 1200 computer with a PCPI  CP/M  card  and  and  ASIO  II
serial/parallel card.  Are there any versions of Kermit that have been used
with the PCPI CP/M card?  Are the source .ASM files available on  line  for
either  the  Apple  CPM  or  generic  CPM Kermits?  Any help in obtaining a
workable CPM kermit for the Franklin would be appreciated.

Thanks, Dave Swindell

P.S. The new Apple 2.1 Kermit works fine.  I had problems  downloading  the
HEX via APPHXL at 1200 baud, but none at all at 300 baud.

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

Date:     Fri, 20 Jul 84 16:00 EST
From:     Mark Scherfling <[e-mail]>
To:       [e-mail]
Subject:  new kermit distribution

We are interested in the Kermit versions for IBM/TSO and the new
version for the Apple II. From the notices explaining how to
receive new versions of the protocol, we seem to be left with
sending you a tape and $100 while those more fortunate on other
networks can just transfer the source to themselves without any
cost incurred. I feel that this selective policy of who pays for
updates is unfair.
We have already paid for the first distribution and I feel, as with
the others, we should not have to pay for subsequent updates.
I feel strongly about this and wish to have a clearification on
this matter from yourselves.

regards,
-- mark

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

Date: Wed 25 Jul 84 13:06:18-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit Distribution Unfairness
To: Info-Kermit@CUCS20

In response to Mark Scherfling's comments, I agree that it seems unfair
that network sites get new Kermits for free whereas unconnected sites
have to pay.  But if you look at the situation a little more closely,
I think you'll understand the policy.

We're a university, not a business.  Since the BYTE and EDUNET news
articles were published, we've been sending out about 10 tapes PER DAY to
sites all over the world, answering about 30 letters of inquiry daily, and
the phone never stops ringing.  Several systems programmers are putting in
nearly full time hours as shipping clerks, and have to work extra hours in
order to do their REAL jobs.  What little money we take in from the
distribution fee goes to pay for some part time clerks to help with the
shipping, and for supplies like magnetic tape (no, you don't send us a
tape, we supply the tape), mailers, printing, and postage.

Now, why should network users get it free while unconnected sites pay?
Well, first of all, network sites have made large investments in order to
get connected -- after all, this is just the sort of thing that networks
are for!  Second, how would you want us to charge them?  Networks just
aren't set up for that.  Third, it costs us little effort for a network
site to drag new Kermit versions away by FTP, whereas it costs us A LOT of
effort to make and mail a tape.  The only special network-related work
comes in updating the Kermit network distribution areas and running the
Info-Kermit mailing list.  But tape users benefit from this effort too,
because they receive Info-Kermit mail on their tapes, along with
everything else.  In any case, without the network connection, many
valuable additions to the Kermit collection would never have been made.

A couple years ago, our policy was "send us a tape and return mailer and
we'll send you Kermit".  We had to give that up when the demand got so
high that our offices were filled up with tapes and mailers, our mail
room was in utter chaos, having to call Federal for this one, UPS for
that one, explain to the post office that the postage meter sticker for
this one with a San Francisco postmark really wasn't used already, etc
etc, and there was no money to hire anyone to help do all this extra
work.  Now we have a uniform and relatively automated way of handling
orders, with fairly rapid turnaround, and a mechanism for handling
increased demand.

Why not send automatic free updates?  In less than two years, we've sent
out nearly 800 Kermit tapes.  If you keep up with Info-Kermit, you know
that new releases or implementations appear a few times EACH WEEK.  To
send free updates, we'd have to send out tapes to some 800 sites several
times a week, or else do massive database searches for who cares about
what version, and make hundreds of custom tapes a week.  The sad fact is
that we're so swamped sending tapes and responding to inquiries that we
haven't even been able to find the time to send a mailing to our "tape
customers" letting them know about the new releases that are available.
And if we had, we'd have even more orders to fill!

Finally, you don't have to get Kermit from Columbia.  Go to one of your
neighbors, or to DECUS, SHARE, STUG, PC-SIG, etc etc, and get a tape or
disk from them -- we submit Kermit to these user groups regularly for
redistribution to their membership.  But they'll charge you a nominal
distribution fee just like we do, because time and materials don't cost
them any less than they cost us, and you'll also find that they update
their distribution files much less frequently than we do.

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

Date: Fri 27 Jul 84 11:41:25-EDT
From: Robert C. McQueen <OC.MCQUEEN@CU20B>
Subject: Problems loading Kermit-10
To: SY.FDC@CU20B

It has been reported by several sites that they are having problems loading
Kermit-10.  The problem is multiply defined symbols loading the Galaxy
library.  To fix the problem people should use the CCL file in KER:.

- Bob

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

Date: 25 Jul 1984 02:18:21-PDT
From: [e-mail]
To: [e-mail]
Subject: UNIX Kermit

Hello,
    What is the current status of UNIX Kermit?  (I don't currently get
INFO-KERMIT).  Also, if it is possible, could I be added to the INFO-KERMIT
mailing list?  I don't have access to the DEC-20's over the summer.

                Thanks,
                Carl Fongheiser
                cmf%Case@CSnet-relay

 [Ed. We are presently cleaning up UNIX Kermit and adding a few minor
  features such as the ability to talk to IBM hosts.  This version
  should be available fairly soon (we're in the debugging stage).  A
  more advanced UNIX/C Kermit (written in LEX) with full server
  capablities has been started and will be available at a later date.]

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

Date: 26 Jul 1984 1537-PDT
From: HAL.DOVE at Ames-VMSB
Subject: Kermit for rsx11m+
To: cc.fdc at columbia-20

I took the kermit for rsx11m+ and have been having nothing but probs.
I took the executable version over the source, for its ease.

I got it into executable form with no problem.  I tkb'ed it, and I
did have a problem locating f4pots, even though it was there.  The
exact error was:

--DIAG-- Error locating file F4POTS

Something like that, so I ignored it, and got no undefined externals.
I installed it, and right now it does not have the /ckp=no for the
installation.

I position myself on my pc running kermit, i get onto the rsx via
remoting to it from a vax, so therefore I am on an ht#: line.

I fire up kermit, the first thing I notice, it can not seem to find the
time, SHOW TIME gives : "The time is ".  I set the port to
ti: which kermit then replies he is in remote mode now.  I then tell
him to "SEND FILE", get back to the pc kermit, type recieve, and
it never responds.  Could it be it can not do a delay since it can`t
find the clock.

If I set a recieve on the rsx kermit, and do a send down below, it
always fails.

Now one also notcies that you bang on any key while kermit it in
receive mode, you get the nice mcr or dcl prompt depending what
you are using.  Is kermit listening on the wrong line, or is it just
getting interrupted?  Is that why the pc kermit fails, because it sends
stuff up, and gets > or # as a reply.

I hope I have given you enough information.
Please reply to me directly here...

Thanks
Mike

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

Date: Fri 27 Jul 84 19:03:51-EDT
From: Brian Nelson <OC.BRIAN@CU20B>
Subject: the decnet thing
To: sy.fdc@CU20B

error locating f4pots? kermit-11 is macro, not fortran perhaps he
tried to link k11hex.ftn and got a task build error.

remote user's should use the node name for the file they want rather
than to get layers deep into terminal emulation in decnet.  since I
can't possibly test decnet m+, this one will have to wait a response
from someone who does have it.  I never got around to the sho tim for
rsx or rt.

The problem is simple. Kermit-11, for rsx, never pays any attention to
the device name, it ALWAYS uses either TT or TI. Thus, a set line HT2:
would actually end up assigning TT2:. This will be fixed in the next
release. For the time being, user's who have to use a HTnn: line
can call me and get information on how to downline load a new RSX task
image from one of my systems. The number is [phone]

                        brian

 [Ed. This response was culled from a number of letters from Brian.
  Thanks, Brian, for all the trouble you went to.]

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

Date: Fri 27 Jul 84 20:24:54-PDT
From: Ronald Blanford <[e-mail]>
Subject: Kermit-MS
To: [e-mail]

I'll be adding support for the NEC APC to Kermit-MS this weekend.  We've
all been waiting a long time for this release, as I know you have too.

I haven't figured out a general way to boot Kermit on the APC either under
CP/M-86 or MS-DOS.  As a stopgap, if people will send a diskette and a
stamped return envelope I will provide them with the source and object
for either version.  My address for this purpose is:

    Ron Blanford
    4200 Aurora Ave. N.
    Seattle, WA  98103
    [phone]

-- Ron

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

Date: Wed 25 Jul 84 14:28:26-PDT
From: [e-mail]
Subject: SDS Kermit?
To: [e-mail]


Frank:  This is a stab in the dark, but do you know of anyone
who may have developed even a kludged version of Kermit for the
Scientific Data Systems (SDS) dedicated word processing system?
(Ah, "SDS" reminds me of 1968 at Columbia!!!)

We have a huge data base that needs to be transferred from the
SDS to the IBM PC.  As life would have it, SDS is now out of
business, so we can't even call them up.  Help!

--vince alfieri
   alfieri@usc-eclb

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

Date: Mon 30 Jul 84 14:28:26-EDT
From: [e-mail]
Subject: Bug fix for new MSPCTRAN.BAS bootstrap program
To: [e-mail]

There is a bug in the new MS-Kermit .BOO file decoder.  Line 400
should read

400 if len(x$) < 4 goto 300

rather than

400 if len(x$) = 0 goto 300

                    -Bill

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

End of Info-Kermit Digest
*************************
-------
 2-Aug-84 12:38:46-EDT,7508;000000000000
Return-Path: <CC.DAPHNE@CUCS20>
Received: from CUCS20 by CU20B with DECnet; 2 Aug 84 12:38:13 EDT
Date: Thu 2 Aug 84 12:37:55-EDT
From: Daphne Tzoar <CC.DAPHNE@CUCS20>
Subject: Info-Kermit Digest V1 #20
To: Info-Kermit: ;
Reply-To: info-kermit@columbia-20

Info-Kermit Digest       Thursday, 2 August 1984       Volume 1 : Number 20

This week's editor:   Daphne Tzoar

Today's Topics:

                  Problems with MSFILE (4 messages)
                 Kermit-MS Status Line with ANSI.SYS
                           Kermit for PC/IX
                            Apollo errors
                Problem with UNIX Kermit and MS Kermit
                        MSKERMIT (2 messages)

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

Date:     Tue, 31 Jul 84 13:27:38 EDT
From:     G B Reilly <[e-mail]>
To:       [e-mail]
Subject:  Re:  Info-Kermit Digest V1 #19

I tried to compile the 'msfile.asm' from the latest distribution, and
the following was the result:


The Microsoft MACRO Assembler , Version 1.25
 Copyright (C) Microsoft Corp 1981,82,83

 00E2  8D 06 01B1 R                 lea ax,outbuf        ; Where to put data when buffer gets full.
 E r r o r   ---    57:Illegal size for item
 0271  8D 1E 03AB R             gtchr0:    lea bx,inbuf
 E r r o r   ---    57:Illegal size for item

Warning Severe
Errors    Errors
0    2

Brendan Reilly

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

Date: Tue 31 Jul 84 20:14:00-MDT
From: Carl Diegert <[e-mail]>
Subject: Problem in MS-Kermit MSFILE under MASM 1.25
To: [e-mail]
cc: [e-mail], [e-mail]

Microsoft's MASM version 1.25 gobbled up all modules for IBM PC version
MS Kermit EXCEPT for choking on two lines in MSFILE:
 lea ax,outbuf
 gtchr0: lea bx,inbuf
with a "57:Illeagal size for item" (severe error).
How about replacing these lines with
 mov ax,offset outbuf
 gtchr0: mov bx,offset inbuf
??

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

Date: Tue 31 Jul 84 17:45:20-EDT
From: Jeff Damens <[e-mail]>
Subject: Re: [G B Reilly <[e-mail]>]
To: CC.DAPHNE@CUCS20

inbuf and outbuf are declared as byte labels (not words)... I guess
it's looking for a word address.  We can just stick a "word ptr"
in front of the operand.  Maybe we should get a later version of
the assembler.

                        Jeff

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

From: lhasa![e-mail]
Date:     2 Aug 84 08:57 EDT
To: harvard!info-kermit@columbia-20
Subject:  MSFILE.ASM

There is a minor bug in MSFILE.ASM. Please insert the line:
    mov    cl,6        ; Adjust high order word for OR
directly before the first (and only) shl instruction.
Without this change, routines will wrap reports of Kb transferred
from 63 to 1024.
Jerry Lotto
(lotto@harvard)

[It's already been fixed but thanks for pointing out the error and
 supplying the solution.  -ed]

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

Date: 31 Jul 84 14:57:03 EDT
From: Peter Kanaitis <PK0P@CMU-CC-TD>
To: Info-Kermit@CUCS20
Subject: Kermit-MS Status Line with ANSI.SYS

Another thing I noticed about Kermit-MS V2.26 (IBM-PC version) is
the send/receive status line. With the ANSI.SYS driver loaded,
the line appears in normal video up to the end of the text,
where the remaining part of the status line is in reverse video.
With ANSI.SYS loaded, the entire send/receive status line is in
reverse video. I'm guessing this is the way it should appear with
the ANSI.SYS driver loaded.

Peter Kanaitis
PK0P@CMU-CC-TD

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

Date: 31 Jul 84 19:34:26 EDT
From: DA2A@CMU-CC-TE
To: info-kermit-request@CUCS20
Subject: Kermit for PC/IX

I've quickly looked over some of the C sources for Kermit.  Is there
one that takes advantage of the features (crufts) of PX/IX?  At the
very least, it should have all the features of the latest version of
the IBM-PC Kermit.  If it could have server capability as well, my
life would be complete.

            Thanks in advance,
            David Artman (DA2A@CMU-CC-TE)

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

Date: Tue 31 Jul 84 17:23:04-PDT
From: Ted Shapin <[e-mail]>
Subject: Apollo errors
To: [e-mail]
Postal-address: Beckman Instruments, Inc.
Postal-address: 2500 Harbor X-11, Fullerton, CA 92634
Phone: [phone]

I tried FTPing APOKERMIT.SRC twice.  The FORTRAN code has errors.
There are continuation statements following a commented line and
other syntax errors in many of the subroutines.  I think it
needs to be reloaded.

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

Date: Tue, 31 Jul 84 20:27:11 cdt
From: [e-mail]
To: [e-mail]
Subject: Re: mskermit

[I don't have original message for the reply below but essentially
 it said that PC Kermit 1.20 worked with his UNIX version and
 MS Kermit 2.26 didn't. -ed]


I figured out my problem.  With version 1.2, I used the command
% kermit sdlb ...
This doesn't work with 2.26.  I have to use the command
% kermit slb ...
Not that this is any great loss.  The d is for debugging mode, which is of
limited usefulness since the new mskermit has a debugging mode.  Still,
it's curious that this happens with UNIX Kermit.

I do run mskermit with the timer off--at least the status information
says the timer is off.  What happens is that two packets are received,
enough for the name of the file to be recorded on disk.  Then, after
six retries, mskermit quits, "unable to receive data."

Sebastian
------------------------------

Date:  1 Aug 1984 15:57:37 PDT
Subject: MSKERMIT
From: Billy <[e-mail]>
To: [e-mail]

The new MSKERMIT is really great! There are several problems however.

If I abort a single file while receiving a series of files the disk gets
messed up. This is because Kermit probably does not close and delete the
aborted file before starting the next file. If this is indeed the problem
the fix should be pretty simple.

I know nobody does this, but it is supposed to be a MS-DOS or even IBM-PC
standard to be able to BREAK from a program by use of the control break
key. I find it best to hook the CTL-BREAK processing code to BIOS as
opposed to DOS. Both provide for CTL-BREAK processing, While the BIOS
level processing may not be as portable it can handle situations the
DOS level can't.

It is possible to hang any program and we have done it with a Kermit that
we ran on a wierdly configured PC. I hate to have a CTL-ALT DEL reboot
when CTL-Break would be more convenient.

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

Date: Thu 2 Aug 84 11:13:59-EDT
From: Daphne Tzoar <[e-mail]>
Subject: Re: MSKERMIT
To: [e-mail]
cc: [e-mail]

 How did you abort the incoming file?  If you type ^X or ^Z Kermit
 closes and deletes the file (unless you did a SET INCOMPLETE KEEP
 in which case whatever portion of the file that made it over is
 kept).  Checking for ^C was also added to the new version.  If
 someone typed ^C to stop the transfer, we didn't want them abruptly
 returned to DOS.  Typing ^C will return you to the Kermit prompt
 and if you really want to get to DOS, you can EXIT Kermit.
/daphne

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

End of Info-Kermit Digest
*************************
-------
 7-Aug-84 19:24:35-EDT,13788;000000000000
Return-Path: <[e-mail]>
Received: from COLUMBIA-20.ARPA by CU20B.ARPA with TCP; Tue 7 Aug 84 19:24:15-EDT
Date: Tue 7 Aug 84 19:23:04-EDT
From: Daphne Tzoar <[e-mail]>
Subject: Info-Kermit Digest V1 #21
To: Info-Kermit: ;
Reply-To: info-kermit@columbia-20

Info-Kermit Digest       Tuesday, 7 August 1984       Volume 1 : Number 21

This week's editor:   Daphne Tzoar

Today's Topics:

                              Mackermit
                       Bugs with Apollo Kermit
                    Problems with TRS-80 Kermit...
               SWITCHAR in MS-DOS Kermit   (4 messages)
            Kermit and Debug:  They won't work together..
                CPMBASE needs revising for more micros
                        Perkin-Elmer kermit ?
                           Internal modems
                             Apple-kermit
                              10 Kermit

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

Date: Fri, 3 Aug 84 13:18:04 edt
From: [e-mail] (Stephen Engel)
To: CC.FDC@COLUMBIA-20
Subject: Mackermit

I have a working version of kermit for the macintosh.
It is an adapted version of the UNIX kermit, and  can
be compiled and run using the SUMACC package.
I have tested it against UNIX kermit and a VMS one,
and the file transfer appears to work fine.   A few
bugs remain in the terminal part though, most notably
its bombing upon typeing large amounts (more than 3
or 4 screenfulls) of text.  I would be happy to
mail it to info-kermit, if you could advise me
on what format to provide the material.

Steve
(engel@harvard)

[We received the version for the Macintosh and will be testing it.  If
 all goes well, we'll release it some time next week.  Thanks to
 Steve!!  -ed]

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

Date: Tue 7 Aug 84 17:58:56-EDT
From: Daphne Tzoar <Sy.Daphne@CU20B>
Subject: Bugs with Apollo Kermit
To: info-kermit@CUCS20

 We received a new tape from the author and will start distributing
 the corrected version as soon as I can get it to the DEC-20.
/daphne

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

Date: 29 Jul 84 21:41:39 EDT
From: Brian <[e-mail]>
Subject: Problems with TRS-80 Kermit...
To: [e-mail]
cc: [e-mail]
Home: 212 Massachusetts Ave.  Cherry Hill, NJ. [phone]
Work: RCA Corp.  Borton Landing Rd. Moorestown, NJ. [phone]

These are not necessarily things wrong with the code, just things
wrong with the distribution of it.  Let me start at the beginning...

First, I downloaded the basic program (TRSMAKE.BAS) using kermit to my
Rainbow, then using a non protocall transfer program to get it to my
TRS-80.  The program is rather clever in that it computes a checksum,
however running the program on the TRS-80 and my Rainbow show the same
(wrong) checksum!  Also, there is a commented out line (250).
Thinking that I had a bad version on my Rainbow, I uploaded the file
back to the DEC-20 only to find them to be the same!

The next obvious thing to try is to compile it from the sources.
There are seven files on the distribution for the TRS kermit program
(the main program and six modules).  It turns out that there are
supposed to be eight source files because the main program includes
seven of them - COMND/SRC is missing!

Now come on guys - I can't believe the amount of carelessness!  I
have downloaded five different version of Kermit with no problems
before - why start now?

Very dissapointed,
Brian Sietz

[ Stan - Could you send us the missing file and another copy of
  TRSMAKE.BAS?  -ed]

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

Date: 2 Aug 1984 2321-EDT
From: Larry Campbell <LCAMPBELL at DEC-MARLBORO>
To: Info-Kermit at COLUMBIA-20
Subject: New MS-DOS KERMIT

MS-DOS KERMIT does not behave well if you set SWITCHAR=- in your
CONFIG.SYS.  Now, I understand why it can't fork commands (so none
of the LOCAL xxx commands work, and PUSH doesn't work), but it also
doesn't accept pathnames with either forward or backward slashes.

1) Is it supposed to support pathnames?

2) Please support SWITCHAR...

Since I develop software that runs under both Unix and MS-DOS, it makes
my life a lot easier if I can run with SWITCHAR=- ...

- Larry Campbell

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

Date: Fri 3 Aug 84 14:57:10-EDT
From: Jeff Damens <[e-mail]>
Subject: SWITCHAR in MS-DOS Kermit
To: [e-mail]

I did try to handle SWITCHAR... The problem I ran into is that there
isn't any way (that I know of) to get the path separator character
from DOS.  You can obtain the switchar, but I wasn't sure about the
relationship between switchar and the path separator.  Empirically, it
seems that if you set switchar to - (or anything else but /) then both
forward and backward slash are taken as path separators.  Do you think
that Kermit should accept either slash when switchar is something
other than dash?  Is there some way to read the path separator?  Am I
missing something here?

                        Jeff
------------------------------

Date:  3 Aug 1984 2027-PDT
From: [e-mail]
Subject: V2.26 MSKERMIT problem
To: .note:
cc: mike@logicon

I have a PC/XT system running DOS v2.10 and I have noticed a VERY interesting
problem.  Since installation of the new version, I could never get the
file MSKERMIT.INI to be successfully read.  Oh yes, it did always seem
to try but it never executed any of the commands.  Another interesting item
is that I could not get the 'DIRECTORY' command to work.

After a couple of hours of experimenting with different operating systems
(v2.00 and v2.10), I discovered the problem.  It seems that there is some
problem related with the setting of the PATH environment variable.

For MSKERMIT to successfully read and execute all commands in the MSKERMIT.INI
file, the PATH variable MUST include the current directory for initialization
to work.  This is nothing harder than putting a ';.' at the end of your
declarations.

However, it also seems that MSKERMIT only searches the ROOT directory of
a given disk for the DIRECTORY command and completely ignores the PATH
specification.  I have all my system binaries stuck in a subdirectory
and I guess this version of Kermit cannot handle that situation at present.

A final note, I tried this utilizing '\' directory seperators (standard
SWCHAR setting) and '/' directory seperators (SWCHAR = -) and they work
identically.  However, I have not looked through the code, but Kermit
I hope that Kermit would be smart enough to allow UNIX style filenames.

Mike Parker
{alias mike@LOGICON}

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

Date: Mon 6 Aug 84 22:40:11-EDT
From: Jeff Damens <US.JD%CU20B@COLUMBIA>
Subject: Re: [[e-mail]: V2.26 MSKERMIT problem]
To: [e-mail], [e-mail]

Kermit searches the directories in the current PATH environment
variable when looking for the MSKERMIT.INI file, or when looking for a
file in the TAKE and RUN commands (this is documented in the MSKermit
Manual, under the TAKE and RUN commands).  If the PATH is empty, or
the file isn't found in one of the PATH directories, the default
(connected) directory is tried.

To use the PUSH and DIRECTORY commands (under DOS 2.0 and higher),
Kermit tries to EXEC COMMAND.COM.  To find COMMAND.COM, it looks at
the COMSPEC environment variable.  If you put COMMAND in some other
directory, you must change COMSPEC to reflect this; give the command
"set COMSPEC=\foo\command.com"

The present version of MSKermit only accepts backward slash as the
directory delimiter at present; this is definitely a deficiency, and
will be fixed, hopefully this week.

                        Jeff

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

Date: Mon 6 Aug 84 18:22:56-PDT
From: Ted Shapin <[e-mail]>
Subject: New MSDOS Kermits
To: [e-mail]
Postal-address: Beckman Instruments, Inc.
Postal-address: 2500 Harbor X-11, Fullerton, CA 92634
Phone: [phone]

The version 2 Kermit for the IBMPC is very good.  I like the save and restore
of the screen during file transfers.  It meets the objection I had to
unsolicited screen clears.

There seem to be a problem with the WANG-PC version.  It doesn't run at all
under DOS 2.  Is it supposed to?

[ Kermit for the Wang was developed under MS-DOS version 2.01.  Does
  anyone know what features were added? -ed]

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

Date: Fri, 3 Aug 84 10:54:43 mdt
From: brownc@utah-cs (Eric C. Brown)
To: info-kermit@columbia-20
Subject: Kermit and Debug:  They won't work together..

I was attempting to bring up Kermit V. 2.26 on a Zenith Z-100 when I found
a truly wonderful bug.  DEBUG (at least the 2.0 version) breaks the Kermit
command processor.   When Kermit is run without the debugger, the command
processor works fine.  When Kermit is run under DEBUG, the command processor
will no longer accept commands.  All it will do is print

?Illegal command

and nothing else.   I believe that what is happening is that the code
around cmky2x is being trashed (discovered by tracing through the command
processor).

So.   Does anyone have a working version of DEBUG, and if not, does anybody
know of a debugger that will debug Kermit??

Thanks,
    Eric C. Brown

    brownc@utah-cs

    ..!harpo!utah-cs!brownc

Hacking.. It's not just a job, it's an obsession.

[ Does that mean MS Kermit v2.26 works with the Z100 -- we couldn't
  test the new version since we have no such animal.  -ed]

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

Date: Fri 3 Aug 84 11:14:46-PDT
From: Ted Shapin <[e-mail]>
Subject: CPMBASE needs revising for more micros
To: [e-mail]
Postal-address: Beckman Instruments, Inc.
Postal-address: 2500 Harbor X-11, Fullerton, CA 92634
Phone: [phone]

KERMIT versions currently exist for about 21 different micros.

There are versions of MODEM for about 79 different micro systems.
The MODEM people learned a long time ago that it is a good idea
to put system dependent code in a separate overlay and keep the
main program separate. The first instruction is a jump over the
overlay code and the main program calls fixed locations in the
overlay for all versions to perform functions such as send a
character to the modem, etc.

It is easy to support a new system by writing the small overlay
and linking it into the main program.  This scheme is also used
by the recent MEX program which even will work with the same
overlays used with MODEM7xx.

I looked at CPMBASE.ASM to see what what be involved in supporting
some of our in-house micro systems.  It is a MESS. There is
hardware dependent code scattered thruout and parochial comments
such as "only ROBIN can send a break" which is untrue.

I just did a rough edit to remove hardware specific code from
CPMBASE and found I removed 30% of the source lines.

I know the people who are presently running on a micro are happy,
but there are three times as many micro systems that COULD run
KERMIT and the present arrangement will become absolutely
unmanageable.  I would like to suggest that the next major
revision of the micro code follow the lead set by the MODEM
people and remove all of the hardware dependencies to a separate
front overlay.

Ted Shapin.

[Some ambitious soul had volunteered to break up CP/M Kermit but
 hasn't done so yet. -ed]

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

Date:  Fri, 3 Aug 84 10:07 MDT
From:  [e-mail]
Subject:  Perkin-Elmer kermit ?
To:  [e-mail]

I am in need of a kermit for the Perkin-Elmer Model 3200-MPS, operating
under OS 7.2 . Languages available on it are CAL (assembler), Fortran
(and Cobol).  Is there such a thing available or in progress, to your
knowledge ?

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

From: ihnp4!sask!derek@Berkeley
Date: 2 Aug 84 23:08:22 CDT (Thu)
To: [e-mail]
Subject: Internal modems

What is the story on internal modems.  I know that Kermit has some trouble
in using them in the IBM-PC and am curious why.

Derek Andrew, U of Saskatchewan, sask!derek

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

Date: Mon, 6 Aug 84 21:43:14 CDT
From: Stan Barber <[e-mail]>
To: [e-mail]
Subject: apple-kermit
Cc: [e-mail], [e-mail], [e-mail], [e-mail]

Some more comments on proceedure to get KERMIT-65 to work.

I had to change APPLEBT.BAS line 203 to the following to get
it to work.
202 GET A$:L$=L$+A$:Y2%=Y2%+1:IF A$<>CHR$(13) THEN 202

Otherwise, it all worked just fine. I even used my TRS-80 to boot it on my apple.
If anyone is interested in how I did it, let me know here
or in a message to me on the sobbs test board at [phone]

Stan Barber
Rice University

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

Date: 6 Aug 84 22:20:08 EDT
From: *Hobbit* <[e-mail]>
Subject: 10 Kermit
To: [e-mail]
cc: [e-mail]

Yow, have you guys hacked up Kermit to do things while logged out???
If so, what does/can it do in that state?

_H*
    -----------------------
From: Nick Bush <[e-mail]>
Subject: Problems with Kermit-10 receive command

...
2)41    C$EXI0:    SKIPN    LOGDIN            ;[125] Are we logged in?
2)         JRST    [$TEXT    (,<.KJOB^M^J.^A>) ;[125] No, make a nice msg
2)            LOGOUT    1,        ;[125] And quit
2)            JRST    .+1]        ;[125] Shouldn't get here...
2)        $HALT                ; Exit to the monitor
2)        $RETT                ; Allow continues

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

End of Info-Kermit Digest
*************************
-------
17-Aug-84 15:12:59-EDT,14566;000000000000
Return-Path: <[e-mail]>
Received: from COLUMBIA-20.ARPA by CU20B.ARPA with TCP; Fri 17 Aug 84 15:11:44-EDT
Date: Fri 17 Aug 84 15:11:26-EDT
From: Daphne Tzoar <[e-mail]>
Subject: Info-Kermit Digest V1 #22
To: Info-Kermit: ;
Reply-To: to Info-Kermit@columbia-20

Info-Kermit Digest       Friday, 17 August 1984      Volume 1 : Number 22

This week's editor:  Daphne Tzoar

Today's Topics:

                      Kermit for PC/IX
                      New version of CP/M Kermit
                           MSKermit for APC
                        New version of Kermit
                     Bug in version 2.26 receive
                       SWITCHAR and directories
                        Problem with MSKERMIT
                            MS-DOS Kermit
         Wanted:  Kermit for the Kaypro 4 with built in modem
          Osborne-1 kermit and the Comm-Pac (internal) modem

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

Date: Tue 14 Aug 84 17:40:37-PDT
From: Herm Fischer <[e-mail]>
Subject: Kermit for PC/IX; works with connect
To: [e-mail], [e-mail]
cc: [e-mail]

I have modified the latest "kermit.c" as distributed by Columbia
University:

     -  It now has conditional compilations for Unix System III,
        (which includes PC/IX), and TALKER options for interactive
        features in the connected state and for cooperation with
        PC/IX's connect facilities.

     -  Its "connect" state allows interactively "escaping" and
        (without exiting kermit):

               Entering receive state,
               sending specified files,
               asking for reassurance,
               executing shell commands,
               quitting/disconnecting,
               getting a help menu, and
               sending the escape character itself.

     -  It can be loaded and run from a shell as usual with the
        unix kermits

     -  It can work as a "talker" for the connect command, which
        then properly sets up and clears lock files, uses connect's
        autodialers, etc, and prevents uucp from crashing onto
        kermit's port.  As a talker, you just say
               "connect talker=kermit somehost"
        or put the talker=kermit line into connect.con.

     -  When using kermit as connect's talker, you get vt100 screen
        cursor controls (see PC/IX display(4) man page) minus line
        insert/delete.  (Connect's default talker, "atalk", gives
        you NO cursor emulation.)

     -  Kermit also works as a "network" program under connect.
        When connecting using the default talker, if you decide
        to send/receive a file, enter ^Vu^M rkermit s myfile to
        send, or ^Vu^M rkermit r to enter kermit's receive state.
        The r command automatically tells kermit which line to use.

This new kermit is in my directory on eclb, <HFischer>kermit.c.
When I get to it, I will also provide a man page and some
instructions, in files which will also begin with the name kermit.

   Herm Fischer

[Herm, let me know when it's ready for us to copy over. -ed]

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

Date: 7 Aug 1984 19:11 PDT
From: Charles Carvalho <CHARLES@ACC>
Subject: I'm not dead yet!
To: CC.DAPHNE@COLUMBIA-20
Cc: CHARLES@ACC
Reply-To: CHARLES@ACC

    Hello...

    I'm the latest (no, make that "most recent") ambitious soul working
on CP/M Kermit, and it looks like a progress report is in order.  The
long-awaited modular Kermit-80 does exist, and is currently in beta test.
(I sent a note to Frank, but it seems I just missed him).  Unfortunately,
we don't provide FTP server access, but I can mail you a copy if you have
some victims (er, test subjects).  Do you have an extra-large mailbox
available? Sources and documentation total ~270Kbytes.

                            /Charles

some changes (not all mine; see [credits]):
.   Modularized (but you knew that already...)
.   May be assembled with LASM (aka LINKASM), as well as M80 and MAC80.  I've
    tested M80 and LASM, but don't have a DEC-10 or -20 to test MAC80 on.
.   Disk space calculated correctly for CP/M 3 systems. [Bruce Tanner]
.   "break" capability added for Kaypro and BigBoard II.
.   TACtrap added for running through ARPA/MILnet TACs [David Kirschbaum
    at Toad Hall]
.   SET DEBUG command added to display packets sent/received
.   VT52 emulation improved
.   SET PORT supported under generic CP/M 2.2 (6, count'em, 6 ports!)
    [Ronald Blanford]
.   "Fuzzy" timer support generalized for all systems
.   New systems:
    Cal-Tex/Ferguson BigBoard II,
    Apple II with 6551 ACIA (Apple Super Serial Card, Videx PSIO)
        [Jon Beeson, Francis Wilson]
    Morrow Decision I [Toad Hall]
.   New terminals: VT52, VT100
.   TRANSMIT command fixed (I think)
.   Fixed a couple of bugs in protocol module.

[ We've got it.  We'll get back to y'all after we test it. -ed]

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

Date: Tue 7 Aug 84 20:51:35-PDT
From: Ronald Blanford <[e-mail]>
Subject: MSKermit for APC
To: [e-mail]
cc: [e-mail]


I've finished the system-dependent part of MSKermit for the NEC APC.
If you are handling distribution now, the source file is available for
anonymous ftp from my account, and is called MSXAPC.ASM.  The
executable code is in MSAPC.EXE, and a brief help file specific to the
APC is in MSAPC.HLP.

I also found one bug in (I guess) the documentation to the effect that
the POSCUR routine must not trash register SI.  It messes up file reception
if it does.

-- Ron

[We'll get a hold of this version too. -ed]

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

Date: 8 Aug 1984 13:56-EDT
Subject: New version of Kermit
From: [e-mail]
To: [e-mail]
Cc: [e-mail]

Mike Seyfrit from Polaris ported a version of kermit for DARPA to use on its'
IBM-PCs.  What is the differance between the new and last version of Kermit.

Also, please add my name to info-kermit since Mike now works for someone else.

Rich. ^ ^
      0 0
       >
      \-/

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

Date: Wed 8 Aug 84 00:41:37-PDT
From: Michael A. Haberler <[e-mail]>
Subject: Bug in version 2.26 receive
To: [e-mail]


When I try to download a file from a host with the receive command, sometimes
Kermit seems to hang. It will <not> show the filename on the screen, as usual
during transfer; it seems to do nothing, but can be aborted by Control-C.

When I exit to DOS and try version 1, things work fine (same connection/server).
Does anybody have a fix for that?

The host is SU-Sierra, a Tops-20 machine. However, the problem seems to be in
Kermit; as I said, it <always> works with the old version after 2.26 failed.

I'll try to get a more exact picture of the problem and let you know.

Send always works. I use a vanilla IBM PC with the Hayes Smartmodem card.

Sincerely,

Michael

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

Date: Thu, 9 Aug 84 08:11:07 mdt
From: brownc@utah-cs (Eric C. Brown)
To: info-kermit@columbia-20
Subject: SWITCHAR and directories

According to my pre-release copy of the ms-dos progammer's manual, the
path separator can be either forward slash or back slash; the OS doesn't
care.  However, if the switchar is /, then most programs must parse /
as a switch and \ as the only directory separator.  If the switchar is not
/, then either / or \ should be accepted as directory separators.


    Eric C. Brown

    brownc@utah-cs

    ..!harpo!utah-cs!brownc

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

Date: 9 Aug 84 11:06:38 EDT
From: PK0P@CMU-CC-TD
To: CC.DAPHNE@CUCS20
Subject: Problem with MSKERMIT

This may have gotten lost over the net, so I'm sending it again...

While testing out the new Kermit-MS, I found the following bug:

C>kermit            ;Get into Kermit

IBM-PC Kermit-MS V2.26
Type ? for help

Kermit-MS>Set Bau<ESC><ESC>?    ;Type "SET BAU" followed by an escape
                ;The "D " will print. Type another escape,
                ;The bell will ring, signifying that the
                ;command has no more defaults. Type a
                ;question mark at this point

                           ? One of the following:  ;lists the options
?Program error    Invalid COMND call

                ;plus some unreadable characters are echoed.

I've noticed similar occurrences with the DO command, and
SET HEATH19-EMULATION.

On a second note, has the control-R facility been removed from
version 2.26?

Peter Kanaitis (PK0P@CMU-CC-TD)
Allegheny General Hospital
Pittsburgh, Pennsylvania

 [ It's been fixed but thanks for pointing it out -- we accidentally
 trashed a register. -ed]

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

Date: Wed 15 Aug 84 18:35:29-PDT
From: Bruce Tanner <[e-mail]>
Subject: MS-DOS Kermit
To: [e-mail]

We've just gotten MS-DOS Kermit version 2.26 for the Rainbow.  We can
communicate over the comm port just fine, but file transmission fails
on the first packet to both Kermit-10 and Kermit-20.

Is there a problem with this version of Kermit, or is it just us?

-Bruce

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

Date: Fri, 10 Aug 84 09:12:03 CDT
From: Stephen M. Padgett <[e-mail]>
To: info-kermit@columbia-20
Subject: Wanted:  Kermit for the Kaypro 4 with built in modem

A friend would like a copy of Kermit for the Kaypro 4 with the built in
modem.  Has anyone modified the Kaypro version to talk to the built in
modem?  Please send mail to me, as I get the mailing list indirectly.
Thanks!
--Steve Padgett
  smp@ut-ngp

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

Date:  Fri, 17 Aug 84 13:03 EDT
From:  "John C. Klensin" <[e-mail]>
Subject:  Osborne-1 kermit and the Comm-Pac (internal) modem
To:  [e-mail]

Since we do not have the facilities to reassemble CP/M-80 kermit (source
too big to fit on the machine), but have succeeded in getting it to work
with the internal modem, I thought it might be useful to pass the kludge
along for others with these unfortunate modems.

For anyone contemplating doing this right, or for anyone speculating
about the operation of the Ozzie, the bits that go to the "modem port"
are the same as those that go out the RS232C port.  Note "the same":
port selection is meaningless, as these are, in essence, wired in
parallel (the voltages differ, but who cares).  The modem is dialed by
connecting and disconnecting it in a timing loop -- the equivalent to
dialing a standard telephone by pushing on the hangup button with the
right timing pattern.  The internal (Comm-Pac) modem is "connected" by
turning the DTR line on and disconnected by turning it off (more on that
later).

In the interim, use the following strategy:
  a) Use AMCALL (the software that comes with the modem) or something
equivalent to initialize the UART and dial the telephone.
  b) Escape from AMCALL (or whatever) to CP/M without disconnecting.
For AMCALL, this is done by the sequence ESC-Z.
  c) Run Osborne kermit, modified as indicated below.
     Now, Osborne kermit will work fine, except that it tries to
initialize the UART, and the initializing process drops DTR and,
consequently, hangs up the modem--a bad idea.  But the port is already
initialized, so bypassing that code works fine.  If one can assemble
generic CP/M-80 kermit, find the STA instruction about two statements
after OSSTST (about line 6691) and get rid of it.  If not, use DDT to
convert the three locations starting at 2C31h to NOPs.  And, presto, a
version of Osborne kermit that works with the Comm-Pac.  Note that, when
you exit Osborne kermit, it de-initializes the port, resulting in
hanging up the phone.  You don't need to go back to AMCALL or manually
disconnect.

It is possible to construct a SUBMIT file that will walk through this
process from invocation of AMCALL to having kermit connected; if it is
not obvious to anyone who cares, let me know and I will forward a copy
to the net.

Things that will get done when either CP/M-80 kermit is restructured and
becomes small enough to fit or we discover an appropriate machine and
copy of MAC80:
  - Making this generate breaks.  This will definitely work for the
Comm-Pac; it looks from the drawings and the technical manual as if it
will work for the RS232C also, but we will have to see experimentally.
  - Making it dial directly, avoiding the kludge.

This exercise has pointed out two things about Kermit implementations in
general, and CP/M-80 kermit in particular, that probably deserve some
priority.
  1) As implementations of the various descendants of Multics (and
Multics itself), with their case-sensitive file system names
proliferate, it is very important that versions of kermit running on
systems that cannot cope with lower-case names translate those names
into upper case before storing them.  With CP/M-80 kermit at present,
lower case names are stored in the file system but, since the CCP maps
everything that is typed to it to upper case, it is very difficult to
use, rename, or get rid of such files.  As I read the protocol manual,
this problem is a bug and should be fixed; versions of kermit that
support operating systems that do case mapping in their command systems,
but are internally case sensitive, should be checked for this problem
also.
  2) The kludge above points out something that has, I think, been
discussed before, which is that it would be very advantageous to provide
the various micro-kermits with
  - an exit/quit command that does not de-initialize the port.  In the
general case, this is required to access commands in the micro's
operating system without dropping the line (although some modems are
smart enough (or dumb enough) not to hang themselves up when DTR goes
off).
  - some sort of command-line argument ("command tail") that would
disable attempts to initialize the port.  In the general case, this is
probably needed to permit getting back to kermit after suspending it
without disconnecting as above.  It is also needed for cases like this
one, where two communications programs are being used in the same
connection and the second one should not undo what the first one has
done.

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

End of Info-Kermit Digest
*************************
-------
 5-Sep-84 18:25:22-EDT,26409;000000000000
Mail-From: SY.FDC created at  5-Sep-84 18:24:58
Date: Wed 5 Sep 84 18:24:58-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #23
To: [e-mail]

Info-Kermit Digest   Wednesday, 5 September 1984  Volume 1 : Number 23

Today's Topics:
                   Info-Kermit Moving to a New Host
                    Unix Kermit (Several Messages)
                           New Unix Kermit
                  MS-DOS Kermit 2.26 Works on Compaq
                      Problem with MS-DOS Kermit
               Text Upload and Auto LF in MS-DOS Kermit
                  New Kermit Implementation in LISP
                     Cray Kermit Progress Report
                          Attribute Packets
                         Kermit Over Telenet?
                 Use of Kermit in Commercial Products
             DEC-20 Kermit Control Character Interference
                      TRS-80 Kermit Author Moves
                      Apple CP/M and DOS Kermit?
                     Kermit to TOPS-20 over TAC?

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

Date: Wed, 5 Sep 84 17:00:00-EDT
From: Frank da Cruz <SY.FDC@CU20B>
To: Info-Kermit
Subject: Info-Kermit Moving to a New Host

Hi everyone, I'm back from vacation.  Thanks to Daphne and Bill for
running Info-Kermit while I was away.

Kermit is maintained and distributed by the Columbia University Center
for Computing Activities (i.e. Computer Center), an entity distinct from
the Columbia Computer Science Department.  The CS department has
graciously acted as host for Internet Kermit distribution this past year,
including maintaining a very large file archive and handling all the
Info-Kermit and other Kermit-related mail.

One of the DEC-20s at the Computer Center, CU20B, is now connected to
the Internet, and so it is no longer necessary to burden the CS DEC-20
with our mail and file transfer traffic.  As a first step in the
transition, I'm moving the mailing list from COLUMBIA-20 to CU20B.
Mail to Info-Kermit or Info-Kermit-Request should now be directed to
CU20B (or, if your host does not yet know about CU20B, which was entered
in the NIC host tables last month, then to %CU20B@COLUMBIA).  Such mail
sent to COLUMBIA-20 will be routed automatically to CU20B during the
transition period.

Over the next few weeks, we'll be moving the Kermit file archive to
CU20B, so please check with your system manager to make sure CU20B is
known to your host for both mail and FTP purposes.  CU20B's Internet
host number is [192.5.43.128] (this may change at some time in the
future).

Don't worry about file transfer yet, but please try to use the new host
when sending mail -- one of the following formats should work:

  Info-Kermit@CU20B
  Info-Kermit%CU20B@COLUMBIA
  Info-Kermit@[192.5.43.128]

Sorry for any confusion this might cause, and many thanks to the Columbia
CS Department for putting us up (and up with us) this past year.

- Frank

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

Date: Mon, 3 Sep 84 13:42:14 pdt
From: jak%ucbopal.CC@Berkeley ( Nhoj Eznuk )
To: info-kermit@columbia-20
Subject: Unix Kermit at UC Berkeley

On our Computer Science Department and Computer Center machines
we are running your version of Unix Kermit with modifications
we would like to see incorporated into Columbia's next release.
The "diff" file below has comments indicating the scope of the
changes; the file itself specifies all the changes.  The actual
C source follows under separate cover.
    John Kunze

[Ed. - "diff" file omitted.  See below.]

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

Date: Wed, 5 Sep 84 00:28:31 cdt
From: Perry Emrath <[e-mail]>
To: [e-mail]
Subject: unix kermit

Hello, my name is Perry Emrath.  I am a research professor at the
University of Illinois.  Earlier this summer, I obtained a copy of Kermit
for unix from Lee Hollaar at the University of Utah.  I wrote my own
version for a pdp-11 which is running a home grown operating system that I
wrote.

I have made some changes to the unix kermit and plan to make a few more.
Reasons are given in the following list describing the changes.  I would
like to know if you are interested in these changes or if somebody else
has already done (or is doing) something similar.

1)  Read into a buffer of 100 bytes instead of 1 byte at a time.
    For a file of 18k bytes, it now uses cpu times of .8 seconds
    user and 3.5 system, whereas it used to use something like 2.0-2.8
    user and 20.0-28.0 system.  This works out to about 250
    CPU microseconds per byte, instead of 1+ milliseconds, and is
    now acceptable for a 9600 baud line, which is what we're using.
    Even when the system is somewhat busy, it achieves 450-500 data
    chars per second using 10-15% of the CPU.
    I have yet to add such a buffer in the connect mode routine.

2)  When kermit executes as a remote, get the terminal's interrupt char,
    and if this is received, exit.  This way, you don't have to wait
    for it to time out or go to another terminal to kill it.

3)  The receive routine returns an error message if the file exists.
    I prefer "no clobber".

4)  IBM-CMS support.  Sending stuff between our pdp-11, vaxen (4.2bsd), a
    Cyber 175, and ibm equipment was the main reason for obtaining
    kermit.  It appears that the only distinctions for the IBM version
    are to wait for a ^Q and handle even parity.  I have the cms version,
    but we haven't gotten it assembled yet.

5)  Ability to use the send and receive routines from inside the connect
    routine, somewhat like the other kermits.  This is important for
    us, because we want to use a local resource allocation program
    that can allocate lines to remote machines, can handle groups
    of lines to the same machine in a "rotary" fashion.  Once you connect
    to somewhere, you don't want to exit kermit to do a send or receive,
    thereby freeing the line.  We already have a local connect program,
    and I would make kermit look just like it with two new commands for
    sending and receiving files.

6)  Other minor bug fixes and changes.

Numbers 1, 2, and 3 are already done and I am about to start working on
5 and 4.

Kermit has generated a lot of interest here and a number of different groups
are looking to start using it.  I was out to Utah during my vacation in August
and Lee helped me grab a bunch of versions from Columbia via the Arpanet and
write them on a tape.

I have two other questions:

1) Since flushing the input buffer before starting is very useful (based on my
    experience with my pdp-11 version), I thought it would make sense to
    have the "receiver" flush the buffer and immediately send a NAK,
    rather than remaining passive.  Then, no matter which direction
    you're going, things would start up right away instead of waiting
    until a time out.  Is there any problem with this idea?

2) Why was ^A selected instead of a printing character as the start-of-packet
    character?   (I don't really expect an answer, it clearly can't be
    changed now.)  The entire kermit protocol seems oriented toward
    systems that can only work in a "cooked" mode, like the cyber.
    I in fact keep my pdp-11 in line mode and it works fine, but I had
    to change the OS because ^A used to mean something and didn't come
    through.  Oh well, I guess you need raw mode for talking to the ibm
    anyway, in order to pick up the ^Q.  Except for that, though,
    using a "cooked" line mode seems possible and more efficient.

Thanks much,

Perry Emrath    ...{ihnp4|pur-ee}!uiucdcs!emrath
DCS, U of IL    emrath.uiuc@csnet

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

Date: Wed 5 Sep 84 12:44:01-EDT
From: Frank da Cruz <[e-mail]>
Subject: Re: Unix Kermit
To: [e-mail]

Hi, thanks for the note.  You're about the 50th person to make these and
similar changes to Unix Kermit.  A couple months ago, we tried to notify
the network community that we would be working on an upgrade of the
program ourselves and everyone else should hold off for a while, but the
contributions continue to pour in...

The buffered reads are a good idea, and we'll probably do something along
those lines because performance is becoming increasingly important to us.
There should also be an option to specify how to handle filename conflicts.

We have IBM VM/CMS support already working in Unix Kermit (XON line
turnaround, use of selected parity).  See below...

Eventually Unix Kermit will have a command parser, so that once started it
can do repeated commands (send, connect, get, etc) without having to be
restarted.

The only problem with having the receiver send a NAK immediately is that
if it's remote, the user will not have had enough time to escape back to the
local Kermit and start it sending, and the NAK will appear on the user's
screen.  This is disconcerting to users who don't know what it is.  If the
receiver is local, then it can send a NAK for packet 0 immediately, and that
may or may not wake up the sender, depending on the mechanism it uses for
delaying transmission of the first packet.

Kermit data can include any printing character, and Kermit packets include ONLY
printing characters.  A distinguished character is needed to mark the beginning
of the packet.  Control-A was chosen for various reasons (it's the ASCII "start
of header" character, and most systems accept it as input, even in "cooked
mode").  The protocol manual and BYTE article explain this more detail.  If
your system won't pass the Control-A through to the program, than you can use
some other non-printing character.  Many Kermits have commands to redefine the
start-of-packet character.

- Frank

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

Date: Wed, 5 Sep 84 11:03:28 EDT
From: Edward Haines <[e-mail]>
Subject: Automating Kermit transfers
To: cc.fdc @ columbia-20.arpa
Cc: [e-mail]

Frank:

We are interested in running Kermit transactions from a batch file (or a
program) on an IBM PC talking to a Unix host.  We need to be able to issue
Unix commands such as 'kermit r' and then local Kermit-MS commands such as
'send \etmail\'.  Do you know of any way to do this with any available
version of Kermit for the IBM PC?  It is easy enough to put the local
commands in the batch file but I haven't been able to issue terminal mode
commands or exit back to local mode with the new Kermit-MS.

[Ed. - You can write a program in your favorite language to issue the
desired commands to Unix from the PC, and use the Kermit-MS "RUN" command
to execute it.  Then, using the new long "command tails" or TAKE files
(or any combination thereof),  you can write batch files to make Kermit do
whatever you like.]

Is there a useable version of a Kermit Server for Unix?

[Ed. - There will be soon; see below.]

Is there any version of Kermit for the IBM PC in a higher level language
such as C or Pascal?

[Ed. - No, but the C or one of the Pascal versions could probably be
adapted.  But why bother?]

What we really want to do is to transfer a set of files in each direction
between the PC and the Unix host and to do a few related Unix commands
without any interaction from the user ...  something that could be made
into a deamon process once we get multitasking in PC-DOS.

[Ed. - I think this will all work pretty soon.]

Thanks for all you have done so far; Kermit is alive and well.

Ted Haines

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

Date: Wed 5 Sep 84 14:164:01-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Unix Kermit
To: Info-Kermit

A new version of Unix Kermit is available.  This is not the totally
souped-up version everyone would like to have, but an interim release to
bring some more systems into the fold while we continue work on the more
ambitious version.  Here is what's new:

. Parity options (None, Odd, Even, Mark, Space) (-p)
. Line turnaround handshake option (XON)        (-t)
. Half duplex terminal operation                (-h)

These three items allow the program to communicate with IBM and similar
mainframes. Also, various small bugs or problems have been fixed.

In addition, work has begun on decomposing the program into modules
(there's still a long way to go).  In this release, the system-dependent
i/o and terminal emulation code has been separated out into special modules
for:

. Unix (most systems)
. VAX/VMS (remote only, no terminal emulation)
. Venix on the DEC Pro-350

All the other features which people have asked for (or sent us) have yet
to be incorporated into the new LEX-based version we're working on.  The
new release, and the continuing development, are being done at Columbia
by Bill Catchings and Jeff Damens.

The new files are in KER:UX*.* on COLUMBIA-20 or CU20B, available via
anonymous FTP after 6pm eastern time.  The comments at the head of
UXKERMIT.C explain what the modules are.  The .NR and .MAN files have been
updated to describe the new switches.

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

Date:  Fri, 31 Aug 84 20:30 MST
From:  [e-mail]
Subject:  Kermit-MS 2.26 Works on Compaq
To:  [e-mail]

I have just gotten a copy of Kermit 2.26 for MS-DOS for my Compaq.  I
assembled it like an IBM-PC and I have had no problems with it.  I have
tested the terminal emulation on Multics Emacs configured as an h19, and
it works great!!!  I just wanted to let you and Jeff Damens know that
that you have done an excellent job!  (I also wanted to let you know that
it appears to work well on a Compaq too.)  Keep up the fantastic work!

                    Gary Brz...

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

Date: Tue 21 Aug 84 14:10:40-PDT
From: ALFIERI@ECLD.#ECLnet
Subject: Problem with MS-DOS Kermit
To: [e-mail]

I love the new version of Kermit for the IBM PC, but I have been having a
small problem.  Whenever I transfer a file either to or from the TOPS-20,
Kermit inserts a long string of Control-Z's at the end of the file.
These can be easily deleted, but the earlier version of Kermit did not do
this.

I assume others have had this problem?

--vincent alfieri
  computing information services
  university of southern california
alfieri@usc-eclb

[Ed. - There is an end-of-file option for Kermit-MS 2.26 that determines
whether Control-Z's are used at the end of a file.  Normally, they are
not.  You must have asked (either explicitly, or in your MSKERMIT.INI
file) to use them.  See the manual.]

-------

Date: Tue 21 Aug 84 17:18:51-PDT
From: L. Brett Glass <[e-mail]>
Subject: Text Upload and Auto LF in MSKERMIT
To: [e-mail]

I have been using the IBM PC version of MSKERMIT for a few weeks now,
and like it a lot. However, there are two semi-essential features that
it does not have -- and I would like to find out if anyone out in Net-land
has implemented them already. These are:

1) Text Upload (that is, dumping straight text from a file to the
   serial port);

[Ed. - There are so many variations on how to do this that we didn't even
try; instead, we included a RUN command in Kermit-MS that you can use to
run your own Basic or Pascal or C (or ...) program that does it whatever
way it wants (XON/XOFF, look for prompt, look for handshake, etc etc).]

   and

2) Auto linefeed (i.e. going to the next line when the host tries to
   type past column 80).

[Ed. - Linewrap works in the H19 emulator in IBM PC Kermit-MS.  The host
has to first send the escape sequence to enable it; it's off by default.
The escape sequence is ESC v to turn on line wrap, ESC w to turn it off.
See the Kermit User Guide.]

I have been able to do text upload on the HP 150 version by doing a "push"
and then a "copy" to the seral port; unfortunately, the IBM version
produces a "write error" when I try this technique.

[Ed. - We'll look into the write-error problem.]

As for the auto-linefeed, I need it to emulate the terminals I use at
work, whose software expects this option to be enabled.

Any help with these queries would be MUCH appreciated. Please respond to
<[e-mail]>, and I will post results if there is sufficient
interest.

--Brett Glass
<[e-mail]>

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

Date: 1 September 1984 11:54-EDT
From: George J. Carrette <GJC @ MIT-MC>
Subject: New Kermit Implementation in LISP
To: cc.fdc @ COLUMBIA-20

A full-function kermit with H19 terminal emulator has been part of the
standard LMI lispmachine software release since June. We have used it in
house extensively as the way to get files from tops-20 and multics sites
and to and from our vax before we had TCP.  It is also used by customers
to deposit bug notes and snarf fix files from our vax. Also implemented is
a SERVER/LOGIN feature, where one can log into the lispmachine through a
serial line and get a kermit command loop. This has been used by people
uploading and downloading lisp programs from IBM pc's. At some sites
kermit fills a real "network gap" where management has not decided on the
"right network" yet but programmers need to transfer files.

The implementation is kind of hairy. As soon as we have it up in another
lisp dialect ourselves (NIL on VAX) we can release it as a COMMON-LISP
standard kermit, which would be a good thing indeed.

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

Date: 30 Aug 1984 13:46:53-MDT
From: Leah F. Miller C-10 <lfm@lanl>
To: cc.fdc@COLUMBIA-20
Subject: Cray Kermit Progress Report

  An initial version of Cray Kermit went onto in-house friendly user
release on the last day of June.  This was a rudimentary "advanced"
Kermit with a Server and timeout capability, but nothing fancy.
It immediatedly gained user acceptance and began to be used on a daily
basis, talking exclusively to Kermit-86 on the IBM PC.

  A week or so later, Lila Chase began porting it to a rather similar
Cray environment at Livermore. She had some success in getting it to talk
to Kermit-86 and to a Version 1 Unix Kermit on the SUN computer.

  Extensive use soon revealed an inadequacy in end-of-file detection.
This was a very minor problem at LANL, but much more serious at Livermore
where a variant compiler put a trailer after the end-of-file character.
At the same time, our users began to request a binary file transfer
capability. This required 8th bit quoting, as our network hardware usurped
the 8th bit to impose even parity.  Since I was doing revisions anyway, I
decided to add repeat prefixing.  The resulting version of Cray Kermit,
called Kermit-CR, now appears to work successfully with both Kermit-86 &
MSKERMIT on the IBM PC.  A new period of "friendly user" testing is about
to begin. If all goes well, I expect to release Kermit-CR in September.

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

DATE: MON, 13 AUG 1984
FROM: ATSBDN AT UOFT01
TO: SY.WBC3 AT CU20B
SUBJECT: ATTRIBUTES PACKETS

the ascii 33 attr packet (file length) would be more convenient of the
units were in 512 bytes rather that 1024. All DEC pdp11 exec's store
allocations in chunks of 512 in the directory entry, thus going to
1024 in the attribute packet can cause trouble. The reason this came
up was the need for kermit-11 to be able to tell a RT11 kermit-11 how
big the file should be, since RT files are always contig and need to
be allocated at create time. No problem for small files, but if the
file is to be larger that 1/2 of the largest free contig space then
pre-allocation for RT11 is required. For binary files, a length error
of +/- one block (due to the rounding in mapping 512 to 1024) could
cause problems to an rt11 application needing to read the resultant
file.
                                                       brian nelson


[Ed. - Right, it would be better for PDP-11's if the length were expressed
in "blocks" instead of K.  But there are lots of systems out there that
have "blocks", "pages", etc, of different sizes, but K-bytes is the best
understood unit.  The intention of this field is not to give the exact
size of the file, but to let the receiver of a file have some idea in
advance of how big it is before it starts to arrive.  The EXACT size (byte
count) may be specified in another field, which will be listed in the next
edition of the Protocol Manual -- "1" (ASCII 49) Byte Count, and "2" (ASCII
50) Byte Size.]

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

Date: 29 Aug 1984 1126-PDT
From: HAL.DOVE at Ames-VMSB
Subject: Kermit Over Telenet?
To: cc.fdc at columbia-20

Sorry to bother you with this, but I rmemeber that you mentioned about
kermit over telenet.  Have you ever had the problem while you are on
telenet where your spaces are sometimes echoed and sent as @.  It is a
real annoying problem.  If you do not know, do you possibly know someone
who does know?

Thanks
Mike

[Ed. - Do you have your parity set right?  To the best of my knowledge,
Telenet expects you to use Mark parity.  Any Telenet users out there?]

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

From: Paul McNabb <[e-mail]>
Date: 22 Aug 1984 0831-EST (Wednesday)
To: [e-mail]
Subject: Use of Kermit in Commercial Products

I also have a question.  I have heard of people using kermit in a product
to be sold.  I have been working on a project that may require some sort
of file transfer package.  Do people frown on kermit being included in
a commercial product?

Thanks.
Paul McNabb
Director of Research Facilities
Department of Computer Science
Purdue University
(pam@purdue)

[Ed. - Our policy ("feelings", really) on the subject have been written
down in a special document which we send to people -- and there are many --
with such requests.  It's in KER:COMMER.DOC.]

--------

Date: Wed 22 Aug 84 15:36:46-PDT
From: Ed Pattermann <[e-mail]>
Subject: DEC-20 Kermit Control Character Interference
To: [e-mail]

Frank,

You can disregard my previous message about troubles with MSKERMIT and
TOPS20 Kermit.  Please accept my apologies for cluttering your mailbox with
'one more message'.

The problem I uncovered was the following, and feel free to post to
INFO-KERMIT (after editing a bit) if you feel it is appropriate. The
SUMEX exec, as well as many other Tops20 execs, has built in a command
editor, usually gotten into by typing '^' as the first character. You can
also arm a control character to get into the command editor. I choose ^A.
Well, if you use a Tops20 system as a server, and have ^A armed for the
line editor, KERMIT will hang no matter what you try to do. I assume this
has something to do with Kermit using ^A as a status interrupt.

Anyway, that's it. I'm glad I solved it, and I hope someone else doesn't
have to waste the time I did.

-- Ed

[Ed. - Thanks, Ed.  Yes, some sites have command editors or daemon forks
that are armed to do things when you type certain control characters.
Kermit uses ^A as the packet delimiter, so it couldn't transfer files
very well if the ^A's were being trapped by some other process.  The next
release of Kermit-20 will do something about this -- at the very least,
it will warn you that another process has a terminal interrupt enabled
for ^A.  Meanwhile, you can kill your daemon while running Kermit, OR you
can redefine the start of packet character to be something other than ^A
(SET RECEIVE START-OF-PACKET).]

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

Date: Wed, 22 Aug 84 20:34:26 CDT
From: Stan Barber <[e-mail]>
To: [e-mail]
Subject: TRS-80 Kermit author moves

Hi there.

I am now at Baylor College of Medicine.  For TRS-80 Kermit users who want
to write, the address is

Stan Barber
Deparment of Neurology
Baylor College of Medicine
Houston, Tx 77032

sob@rice still works for mail.

We also use kermit here on MASSCOMP under Unix and on PDP-11/23 using
RT11.

Cheers.
Stan

[Ed. - Good luck, Stan.  By the way, we're still missing the complete set
of source files for TRS80 Kermit.  Could you, or someone, please send
them to us on tape?  We have not been able to get them with ftp.]

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

Date: Wed, 22 Aug 84 23:43:08 cdt
To: info-kermit@columbia, info-kermit@columbia-20
Subject: Apple CP/M and DOS Kermit?
From: [e-mail]

I'm looking for a version of kermit for an apple 2e with microsoft
premium softcard and ssc serial interface card.  I would prefer
a CP/M version, but will settle for a working Dos version if necessary.

Is anyone willing to send me a diskette? or to give me clear instructions
on how to download the object file (or source) via ftp from columbia-20
to a unix / vax system.  I have a temporary path to download from the unix
to the apple under DOS, but am looking for a more permanent and reliable
one using KERMIT.

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

Date: 26 Aug 1984 0205-PDT
From: [e-mail]
Subject: Kermit to TOPS-20 over TAC?
To: Info-Kermit@COLUMBIA-20

I have no end of of troubles in using kermit to communicate with tops20
via the arpanet/milnet.

There must be some trick that I am missing.

Currenntly I am going through a Tac via remote dialup and no matter what
combination of parity/no parity/even parity etc. I used I get a tremendous
number of retries when attempting to send files from the tops20 ECLB
machine to my IBM PC at home.

One trick that I discovered was that the @ character in the packets was
being intercepted by the net, so I had to chage the interrupt character
via a @i 2, which makes ctl B the new interrupt character.

Normally the number of retries is at least half the number of packets
recieved.

Any help would be greatly appreciated.

Thanks in advance,
Reed

[Ed. - TOPS-20 Kermit needs to be told that you are talking to it through
a TAC.  It will then put the TAC in "binary mode" and all will be well.
When the file transfer is done, it will take it back out of binary mode.
The command is SET TVT-BINARY ON.]

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

End of Info-Kermit Digest
*************************
-------
10-Sep-84 13:49:46-EDT,20500;000000000000
Mail-From: SY.FDC created at 10-Sep-84 13:49:23
Date: Mon 10 Sep 84 13:49:23-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #24
To: [e-mail]

Info-Kermit Digest          Mon, 10 Sep 84        Volume 1 : Number 24

Today's Topics:
                   New Cyber-170 NOS, NOS/BE Kermit
                 MS-DOS Kermit Available for NEC APC
                    New Release of Multics Kermit
               Another Kermit for Victor/Sirius MS-DOS
                 TRS-80 Kermit Source Problems Fixed
               Getting UNIX Kermit Session Transcripts
              V2.26 MS-DOS Kermit Heath-19 Emulation Bug
                    MS-DOS Kermit on Eagle PC-Plus
                      Bugs in MS-DOS Kermit 2.26
              Rainbow CP/M-86 Kermit Printer Interrupts
                       Kermit for Epson QX-10?
                   Apple Kermit on Quadlink Board?
                      Question about RSX Kermit

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

Date: Thu, 6 Sep 84 14:33:25 cdt
From: [e-mail] (Jim Knutson)
To: SY.FDC@CU20B
Subject: New Cyber-170 NOS, NOS/BE Kermit

Version 2.2 of Kermit for the Cyber-170 is ready.  The files are:

    170kermit.for
    170azlib.asm
    170tape.ltr

The tape letter is what I have been sending out with tapes I have written
for others.  You may or may not want to include it with the others.  The
only change to the document file is the version number.

Version 2.2 contains the following modifications from 2.0:

    Changes from Bill Russell ([e-mail]):
      Added NOS 2.2 support (up through level 602).  Add timeout
      during reads (NOS 2.2 level 602 or above only).

    Changes from Ric Anderson (U of Arizona, Tucson):
      Add UPDATE IFDEFs for character set, operating system and site
      selection.  Fix EXECMD to work under NOS/BE.  Fix CFE for use
      under NOS/BE.

I'll include the 8th bit prefixing from Olaf Pors at the U of Virginia
along with with the other mods I've done on the next release I send to you.

Jim

[Ed. - The new files are in KER:170*.* on COLUMBIA-20 and CU20B.]

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

Date: Tue 7 Aug 84 20:51:35-PDT
From: Ronald Blanford <[e-mail]>
Subject: MS-DOS Kermit Available for NEC APC
To: [e-mail]

I've finished the system-dependent part of MS-DOS Kermit 2.26 for the NEC
APC.  The source file is called MSXAPC.ASM.  The executable code is in
MSAPC.EXE, and a brief help file specific to the APC is in MSAPC.HLP.

I also found one bug in (I guess) the documentation to the effect that
the POSCUR routine must not trash register SI.  It messes up file reception
if it does.

-- Ron

[Ed. - Thanks Ron!  The files are available in KER:MS*APC.* on CU20B and
COLUMBIA-20.  Anybody else want to contribute similar modules for some of
the other MS-DOS systems (Victor/Sirius, Tandy 2000, Seequa, Z100, etc)
so we can get rid of the redundant files?]

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

Date: Fri 7 Sep 84 16:28:38-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Release of Multics Kermit
To: [e-mail]

A new release of Multics Kermit has been received from Paul Amaranth of
Oakland University.  This is version 2.0g, and replaces the earlier
version from May 1983.  Various problems with the earlier version have
been corrected (for instance, the source code no longer contains any
"hard" control characters), and many improvements have been made (server
mode, logging and metering facilities, etc).

Comments and critism may be directed to Paul at the following address; he
may also be reached at [phone].  With any luck Oakland U will be on
MailNet in the not too distant future and communications will improve.

     Paul Amaranth
     Oakland University
     Academic Computer Services
     Rochester, MI
     48063     USA

The files are in KER:MU*.* on COLUMBIA-20 and CU20B, including PL/I
source files, user help files, installation instructions, and program
call tree listings.

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

Date: Fri 7 Sep 84 16:58:51-EDT
From: Frank da Cruz <[e-mail]>
Subject: Another Kermit for Victor/Sirius MS-DOS
To: [e-mail]

This version of Victor Kermit is written in Computer Innovations 'C' by W.
Hertha of Victor Technologies (Canada) and Dr. Joe Angel of the Department of
Biochemistry of the University of Saskatchewan.  There is no hex file format of
the binary currently available, so you must have Computer Innovations 'C' to be
able to compile it on a Victor.  It should work with other complete 'C'
compilers as well.  It has been tested at 9600 baud with no problems.  The help
file describes any variations from the standard kermit implementations.

Thanks to David Emigh of the University of Saskatchewan for this contribution.
The files are in KER:VICKERMIT.* on CU20B and COLUMBIA-20.

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

Date: Fri 7 Sep 84 17:37:11-EDT
From: Frank da Cruz <[e-mail]>
Subject: TRS-80 Kermit Source Problems Fixed
To: [e-mail]

Thanks to the many, including Brian Sietz of Rutgers, who pointed out the
problems with the TRS-80 Kermit source files.  We now have what we hope is
a complete and correct set of files in KER:TRS*.* on CU20B and COLUMBIA-20.

- Frank

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

Date: Thu 6 Sep 84 16:51:21-PDT
From: Daniel H. Miller <[e-mail]>
Organization: Litton Data Systems; Van Nuys, CA; [phone]
Subject: Getting UNIX Kermit Session Transcripts
To: [e-mail]

I found an interesting method of obtaining UNIX Kermit transcripts:

              kermit clb /dev/tty0 1200 | tee transcript

Kermit sets up its session in CONNECT mode over line tty0 at 1200 baud
and then every time a character is received from the line it is sent
via a pipe to tee which sends it to the terminal and to the transcript
file.  The transcript file contains what the user types and what is
sent via the machine, since Kermit is operating in full duplex and all
characters come back over the line.  This works as long as Kermit only
outputs via standard output.

                                        --- Dan Miller

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

From: Bruce Nemnich <godot!bruce@cca-unix>
Date: 29 Aug 1984 0445-EDT (Wednesday)
To: [e-mail]
Subject: v2.26 heath emulation bug

There is a heath emulation bug in v2.26 in that tabs are destructive, i.e.,
they wipe out characters under the range of their motion.  I assume this is
a bug; I don't have a real heath at hand, but all drivers I have seen assume
heath tabs aren't destructive.

For those of you using Unix, that means you will want to add the "xt" flag
to the termcap and/or terminfo entries for your kermit terminals until the
bug is fixed.

--Bruce Nemnich, Thinking Machines Corporation, Cambridge, MA

[Ed. - Anybody out there have a real Heath-19 to check this?]

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

Date: Fri, 07 Sep 84 20:59:14 EDT
From: Jeff Kimmelman <[e-mail]>
Subject: MS-DOS Kermit on Eagle PC-Plus
To: [e-mail]

I am having problems with MS-Kermit on my Eagle PC-plus.
It seems that I lose about one out every 10 characters when I am
in terminal emulation connected to a host.  I suspect that there
are stop bit problems but am not sure.  I haven't been able to
get the manual yet and can find no command which alleviates the
problem.  If you can help I would greatly appreciate it.  I am
using generic Kermit by the way.

Thanks in advance--

Jeffrey Kimmelman

[Ed. - Generic Kermit can't be expected to work flawlessly on a new
machine, only just barely.  The solution, of course, is to add explicit
system-dependent support for the Eagle, as we have for the IBM PC,
Rainbow, Wang, HP150, etc.  Any volunteers?]

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

Date: Sat 8 Sep 84 11:57:02-PDT
From: Roland Hutchinson (r.rdh@su-lotsa)
To: Info-Kermit@COLUMBIA-20
Subject: Bugs in MS-DOS Kermit 2.26

Congratulations to the implementors of the new MS-DOS Kermit!!!

The following bugs and curious features have come to my attention in
    version 2.26 on the IBM-PC.

CAVEAT: I HAVE NOT HAD TIME TO REASSEMBLE AND TEST THE FIXES SUGGESTED
FOR THE FIRST TWO ITEMS BELOW.  PLEASE REGARD THEM AS SUGGESTIONS
ONLY!!   I have thought it more important to report these to you quickly
than to try to fix them myself with my limited experience in 8086
assembler!

1. Status line displays incorrect information.

    The status line (line 25) shows local echoing when echoing is in
    fact remote, and vice-versa.  This is, to say the least,
    confusing.  (The STATUS command, however, continues to give the
    correct information.)

    This one appears to be easy to fix:  In the file MSTERM.ASM, make
    the following change:

              test     flags,lclecho          ; echoing?
              jnz     modl4                    ; no, keep going
           ;[ ^^^  THIS WAS JZ INSTEAD OF JNZ, IN ERROR]
              mov     si,offset remmsg
   modl4:     mov     cx,3                    ; size of on/off
              mov     di,offset modbuf.m_echo
              rep     movsb


2. Problems with command prompting.

    Typing "?" after certain commands yields an incorrect reprompt--the
    question mark is not removed from the line, thus:

        Kermit-MS>defi? Specify macro name followed by body of macro
        Kermit-MS>defi?

    Typing ESC at this point produces

        Kermit-MS>defiINE

    (note the two i's).

    This problem seems to affect the commands:

        DEFINE
        LOG
        SHOW MACRO
        SET PROMPT
        SET KEY SCAN

    This might be fixed by making the message strings FILHLP through
    SK2MSG in MSSET.CMD have the same format as the strings which
    proceed them, i.e., remove the leading space and insert cr and lf
    in the last six lines listed below.

erms23     db     cr,lf,'?0 or null scan code not allowed$' ;[jd]
erms24     db     cr,lf,'?Capture file already open (use close command)$' ;[jd]
filhlp     db     ' Input file specification for session logging$'
macmsg     db     ' Specify macro name followed by body of macro $'
shmmsg     db     ' Confirm with carriage return $'
prmmsg     db     ' Enter new prompt string $'
sk1msg     db     ' Decimal scan code for key $'
sk2msg     db     ' Redefinition string for key $'


    The proposed change would also have the benefit of making the "?"
    behave uniformly in different commands. (ALWAYS starting the help
    message on a new line.)

[I have noticed a few other problems with command prompting &
completion--if memory serves, typing the name of a command complete,
but without a space, and following it immediately with a "?" was one
situation.  Sorry I don't have time to test and report at length just
now, but my impression is that the whole command-parsing code needs
a good systematic test!!!]


3. 8th-bit characters typed from the keyboard can cause a system crash!!

    This is rather a bad problem and I am afraid I have no idea how to
    fix it.

    Do the following:

Kermit-MS>set key f1
Enter key definition:
                      ^^Here, hold down the alt key and press 147 on
    the keypad (this is the normal way of entering characters 128 to
    255 decimal from the IBM keyboard).  Type a few more of 8-bit
    characters in this way, if you like.  Then press RETURN.

    The screen will fill with stray bits of text, and seem to go into
    a loop.  The floppy disk may start to spin after a while
    (fortunately, no damage seems to be done to the disk.)  The only
    way out is to power down.

    I suspect that this problem occurs because CMGTCH (in the file
    MSCMD.ASM) sets the 8th bit to mark an "action character", and
    something in SETKEY or DEFKEY is unprepared to deal with other
    hi-bit characters.

    This is going to be a bit tricky to fix absolutely properly.
    Since ESC+80H, "?"+80H, " "+80H are  all valid characters in IBM's
    extended character set, it should be possible to enter them from
    the keyboard.  I don't see how this would be possible without
    rewriting COMND and much of the code that uses it.  In the
    meanwhile, a fix that simply keeps the system from crashing and
    ignores these characters (or lets only some of them through, or
    whatever) would be a very good thing to have!!!!!!

4. SET KEY SCAN doesn't parse it's input correctly.

        SET KEY SCAN<space><space><return>

    doesn't realize it should generate the same error as

        SET KEY SCAN<return>
    or
        SET KEY SCAN<space><return>

    You have to use ctrl-C to get out.  I don't know what scan number
    it thinks it's getting or what it does if you give it a
    redefinition. (It accepts it, but where does it put it?)

5. Suggested improvement in SHOW MACRO command.

    It would be nice if this could reconvert the tabs (displayed as
    "\015") back into a printable character--preferably the comma, so
    that  SHOW  MACRO  would show a definition string that looked like
    the one DEFINE originally read.

6. File transfer status line isn't sufficiently informative.

    The RETURN key is active during file transfers, and nothing on the
    screen warns the user about this.  Pressing return carelessly
    during a transfer can get the transmission out of synch, and abort
    the current file being transfered. (It happened to me!!!!)

    The role of the RETURN key should be displayed somewhere on the
    screen (maybe on line 24, in reverse video to match line 25?).

    Would it be possible to fix it so that stray RETURN's can't break
    the file transfer?  (Perhaps by making the return key active only
    if the comm port hasn't been busy for a while--the purpose of the
    RETURN is to do a "wakeup" as if the line had been timed out,
    isn't it?  (If I have misunderstood the niceties of the protocol,
    kindly ignore this suggestion!!!)).

7. Undocumented command.

    The grey plus key (on the keypad) toggles the status line on and
    off.  This isn't documented anywhere, or have I missed it?

8. Missing scan codes.

    Scan codes for ctrl with certain keys on the keypad don't seem to be
    passed along to the program.  (Shift+keypad codes work fine.)
    Everything but ctrl-uparrow, ctrl-downarrow, and ctrl-5-on-the-
    keypad does work properly.  These don't work because of IBM's
    somewhat perverse BIOS.  It would be easy enough to slightly
    rewrite the BIOS routines in question and replace them either at
    boot time or while running Kermit only.  I could even volunteer
    to do the job myself--but IBM's copyright police probably
    wouldn't care to let us distribute the resulting source code or
    object code!!!!!  In short, it probably isn't worth the effort
    just to fix this.  But if we could get ctrl-alt-stuff to return a
    different scan code from alt-stuff (there seem to be just about
    enough scan codes left, if we agree to ignore the state of the
    Shift key--sorry, LEDIT users!), now there would be something
    worthwhile.  (Unfortunately, the same copyright problems apply.)

Thanks to all involved in creating and maintaining this program!  I hope
the above is helpful to you.

Roland Hutchinson

[Ed. - Thanks for the informative report; it'll be reflected in the next
release.]

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

Date: Thu, 6 Sep 84 08:48:01 EST
From: decvax!mulga!stephenw.murdu@Berkeley (Stephen Withers)
To: [e-mail]
Subject: Rainbow CP/M-86 Kermit Printer Interrupts

I was interested by the note in RBKERMIT.HLP concerning the problem
caused by "certain printer interrupts".  I have had Kermit-86 freeze
on me quite often, and I'm fairly sure it's happened when my printer
has not been switched on.

Assuming the problem is to do with the printer interrupts, how about
this as a kludge:  a command that disables all other printer-related
commands and options, and points all the printer interrupt vectors to
an IRET.  You would also want the ability to reverse this process.
Can anyone familiar with the internals of Kermit-86 suggest whether
this is likely to succeed, and if so how big a job it would be?

Another problem I've experienced is that at 2400 baud (our default
line speed), the time taken between disk writes is approximately
equal to the Rainbow's disk motor time-out period.  This sometimes
leads to drive-not-ready errors.  There are several ways round this,
(e.g using SET DELAY at the transmitting end, or changing the line
speed), but they are not always convenient.  How difficult would it
be to vary the number of packets/characters received before the
buffer is written to disk?

I'm not asking for someone else to do the work, but I'd appreciate
some advice about where to start.

Steve Withers, University of Melbourne Computer Centre.

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

Date: Sun, 9 Sep 84 23:27:47 EDT
From: John Wiggins <[e-mail]>
Subject: Kermit for Epson QX-10?
To: [e-mail]

  Is there a version of KERMIT to allow me to transfer files between UNIX
system and my micro, Epson QX-10 using CPM?  If so, I would appreciate
help or direction.                         Thanks,

                        John Wiggins
                        Room 3/162
                        BBN Communications, Inc
                        50 Moulton Street
                        Cambridge, MA 02138
                        617-497-3390

[Ed. - Neither the current version (3.9A) nor the soon-to-be-announced
modular version (4.?) of CP/M-80 Kermit contains explicit support for the
Epson.  Support for new systems will be easier to add to the forthcoming
modular version than to the current monolithic one.  In the meantime,
does anyone have a custom-made Epson Kermit?]

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

Date: 10 Sep 84 09:14:10 EDT
From: Bdale Garbee <AG0B@CMU-CC-TE>
To: Info-Kermit
Subject: Apple Kermit on Quadlink Board?

Does anyone have any experience getting Kermit v2.1 for the Apple ][ family
of computers working on the Quadlink "Apple-emulation" board for the IBM
PC?  If so, how did you do it?  Quadram's documentation is mighty sparse...

Bdale Garbee
CMU Software Staff

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

Date: 5 Sep 1984 1555-PDT
From: HAL.DOVE at Ames-VMSB
Subject: Question about RSX Kermit
To: info-kermit at cu20b

I have been having a peculiar problem with the RSX Kermit Connect when
remoted:

Situation:
    I am on a VAX running VMS, I connect to our PDP running RSX-11m+.
    I start up kermit, set line to tt7: (a line going to another computer)
    Do a connect, get the "this is not a remote line message" and then
     it kicks me back to the vax real quick.

Other Info:
    When I am logged into the PDP directly, no remoting involved.  The
    connect seems to work fine.  Is this a problem with the older
      version not supporting ht#: lines?

Thanks in advance,
Mike a.k.a. hal.dove@ames-vmsb

P.S. It was announced a few kermits back that the new RSX Kermit would
be ready shortly with the HT#: fix, among others.  When is the tenative
date for that??

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

DATE: THURS, 06 SEP 1984
FROM: ATSBDN AT UOFT01.BITNET
TO: SY.FDC AT CU20B
SUBJECT: KERMIT AND RSX

rsx q
1. do a set/tt7:=remote
2. can not test HTx:, but kermit-11 works fine in the pro/350 using XK0:
so one would assume that doing a set line htn: would now work. I will
send a tape today or tomorrow, I just sent one to Bernie for taking to
Decus Europe.
                                                 brian

[Ed. - Will announce new PDP-11 Kermit when it's installed.]

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

End of Info-Kermit Digest
*************************
-------
13-Sep-84 17:35:29-EDT,14142;000000000001
Mail-From: SY.FDC created at 13-Sep-84 17:35:10
Date: Thu 13 Sep 84 17:35:10-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #25
To: [e-mail]

Info-Kermit Digest          Thu, 13 Sep 84        Volume 1 : Number 25

Today's Topics:
                    Macintosh Kermit #1 Available
                     New Release of PDP-11 Kermit
                    Kermit on RSX-11M Version 3.2?
                      Obtaining Apple DOS Kermit
                       Apple II Kermit-65 V2.1A
                         Franklin CPM Kermit?
                 Rainbow MS-DOS Kermit Bootstrapping
            Rainbow Printer Interrupts and CP/M 86 Kermit
     Screen Scroll Bug in MS-DOS Kermit V2.26 for the DEC Rainbow
               MS-DOS Kermit V2.26 Heath Emulation Bug
             Destructive Tab Fix for MS-DOS Kermit V2.26

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

Date: Thu 13 Sep 84 14:21:44-EDT
From: Frank da Cruz <[e-mail]>
Subject: Macintosh Kermit #1 Available
To: [e-mail], [e-mail]

This is to announce Macintosh Kermit #1.  It's one of several different
Macintosh Kermits under development, but this was the first one to reach
us.  It's from Stephen Engel at Harvard University (engel@harvard),
written in C for the Sumacc Unix-based Macintosh cross development system.
The files are collected together into a Unix shell archive, as
MC1KERMIT.SH.  They include source files, a makefile, and some sketchy
documentation.

In Steve's words, "This is an `alpha' release of the program.  Much of the
code is sloppy and buggy, but I believe that all the program's
funadmentals work adequately.  This program is chiefly an adaptation of
Columbia's Unix kermit."

It has been tested in conjunction with Unix Kermit and DEC-20 Kermit.  The
program is far from complete and has many rough edges, but it's the first
out the door and so should prove useful to the many sites that need some
kind of Kermit capability for the Mac.

You must have the Sumacc cross development system and a VAX-resident 68000
C cross compiler to make use of these files (anybody out there want to make
a hex file suitable for use with the FROMHEX utility?).  To get MacKermit
onto a Mac, you must:

1. Get MC1KERMIT.SH to your VAX Unix system, preferably in its own directory.
2. Connect your Mac to the VAX using Macterminal 0.5 or later.
3. Be sure your search path includes the Sumacc tools.
4. CD to the directory where you've put the mc1kermit.sh file.
5. Type "sh < mc1kermit.sh" to let the shell pick the file apart.
6. Type "make" to build the program from the source.
7. Type "macput -r kermit" to send the Kermit program to the Mac.
8. On the Mac, use SetFile to set the "bundle bit" (optional).

The VAX directory will contain the various source and header files, as
well as the Mac-format resource file, and a brief document "kermitdoc",
explaining the operation of this version of Macintosh Kermit.

The shell archive file is available as KER:MC1KERMIT.SH on COLUMBIA-20 and
CU20B via anonymous FTP (it seems to contain multiple versions of some of the
files, but I didn't want to tamper with it).  Comments, suggestions, bug
reports should be directed to engel@harvard with cc to Info-Kermit@CU20B (or
@COLUMBIA-20 if your host doesn't know how to mail to CU20B yet).

Thanks, Steve, and congratulations on being the first to do it.  - Frank

P.S. This is probably just the first in a long series of Macintosh Kermit
announcements.  Independent implementations are expected from Rice, Brown*,
Dartmouth, and elsewhere (maybe even Columbia, which was supposed to have
done it in the first place), and new releases of the Harvard implementation
will probably also appear from time to time.

*I'd like to see these two get together and produce a Brown-Rice version...

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

Date: Wed 12 Sep 84 12:47:38-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Release of PDP-11 Kermit
To: [e-mail]

Brian Nelson of the University of Toledo in Ohio ([e-mail]) has
contributed a new release of his PDP-11 Kermit, version 2.22, which supports
RSX-11/M/M+, RSTS/E, RT-11, and (now) P/OS systems.  New features since the
previous release (2.18) include:

. 8th-bit quoting for passing binary files through 7-bit communication links;
. Various improvements in RT-11 support;
. "IBM Mode" -- handshake, parity, for communicating with IBM mainframes;
. Support for Pro-350 P/OS systems.

The new P/OS support is DCL only (no menus), but it differs from the current
Stevens version of P/OS Kermit by supporting Files-11 attributes.

The files (72 of them!) are in KER:K11*.* on COLUMBIA-20 and CU20B.  The file
KER:K11FIL.DOC (slightly out of date) explains what all the files are.  The
file KER:K11INS.DOC (also slightly dated) contains installation and
configuration information.  Binaries built for various configurations are in
KER:K11*.HEX in "hexified" format, decodable by the programs KER:K11HEX.*.
There's also a new document, KER:K11ART.MEM, an article describing the PDP-11
implementation of Kermit in some detail.

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

Date: Wed, 12 Sep 84 10:34:43 EDT
From: mattis@NBS-SDC
Subject: KERMIT ON RSX-11M VERSION 3.2
To: INFO-KERMIT@COLUMBIA-20

I have FTP'd the K11FIL.DOC file which lists all the files relating to
installation of Kermit on a PDP-11.  Before I start, can anyone tell me right
off whether I can use these files to install Kermit on an LSI-11/23 running
RSX-11M version 3.2?  We do not have RSX 4.1 and because the system uses
proprietary software supplied by a third party there is little chance of
getting it.

[Ed. - Sorry, no, as it says in the installation instructions, K11INS.DOC,
you must have version 4.0 of RSX-11M, or version 2.0 of RSX-11M+.]

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

Date: Wed 12 Sep 84 00:36:37-EDT
From: Peter G. Trei <[e-mail]>
Subject: Obtaining Apple DOS Kermit.
To: [e-mail]

    Hi!
    I'm Peter Trei, one of the maintainers of Apple DOS Kermit.
Recently, some people have been asking questions about obtaining this
version. For some time, I have been supplying copies to the Columbia
community at a nominal fee, since booting it up from a mainframe is a
non-trivial task.

    If you can meet me in the CU area, I will trade the disk
in return for a new, blank one. If not, for $5 I will mail out a
copy. I can also give a certain amount of help over the phone if
you are really stuck.

    My address is:            My daytime phone is: 212-8153711
        Peter Trei,
        15 Sickles Street,
        New York, NY  10040
                    Peter Trei
                    [e-mail]

[Ed. - Thanks for volunteering to perform this service, Peter!  The
Apple II Kermit bootstrapping technique is one of the most difficult,
and you'll be saving many people lots of time and trouble.  Readers of
Info-Kermit should bother Peter only on a per-site basis, and then
distribute copies themselves within their own site.]

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

Date: Tue 11 Sep 84 16:41:22-EDT
From: Anton Mione <[e-mail]>
Subject: Apple II Kermit-65 v2.1a
To: [e-mail]

Frank,

Peter Trei has made some changes to allow Kermit-65 to print
real lowercase for //e's and //c's.  We are calling it version 2.1A.
The three APPLEK files in my directory represent the new stuff.

Anton:<miONE>

[Ed. - The new files are in KER:APPLEK.*.]

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

Date: Tue, 11 Sep 84  9:36:26 EDT
From: Dave Swindell <dswindel@bbn-labs-b>
Subject: Franklin CPM Kermit
To: [e-mail]


I have a Franklin 1200 computer with a PCPI  CP/M  card  and  and  ASIO  II
serial/parallel card.  Are there any versions of Kermit that have been used
with the PCPI CP/M card?  Are the source .ASM files available on  line  for
either  the  Apple  CPM  or  generic  CPM Kermits?  Any help in obtaining a
workable CPM kermit for the Franklin would be appreciated.

Thanks,

Dave Swindell
BBN Labs

[Ed. - Anybody out there have Kermit running on a Franklin?]

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

Date: Thu 13 Sep 84 16:32:44-EDT
From: Frank da Cruz <[e-mail]>
Subject: Rainbow MS-DOS Kermit Bootstrapping
To: Info-Kermit@CU20B

Users of DEC Rainbow 100s have complained that there's no bootstrapping
procedure they can use for getting the new MS-DOS Kermit onto the Rainbow
over the communication line.  The problem was that Basic was not available
for MS-DOS on the Rainbow (or else it was so new that no one had it yet),
so the Microsoft Basic program we provided for decoding the .BOO (4-for-3
encoded) binary file could not be used on the Rainbow.

Now, thanks to Bernie Eiben at DEC, we have a version of the Basic program
that will run on the CP/M-86 side of the Rainbow, under Microsoft MBasic-86.
It's a reworking of MSPCTRAN.BAS, which assumes that you already have the
.BOO file on your CP/M disk.  It builds an .EXE file, which you can then
move to the MS-DOS side of your Rainbow by booting MS-DOS and then using
RDCPM to get the file from the CP/M-format disk.  How you get the .BOO file
onto the CP/M disk in the first place is another question.  Either you use
some file capture utility -- commercial or otherwise -- or else you go
through the DDT bootstrap procedure given for CP/M-80 Kermit (since the
Rainbow is also a CP/M-80 system).

Bernie's program is in KER:MSRBBOO.BAS.

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

Date: Mon 10 Sep 84 16:42:41-EDT
From: Jeff Damens <[e-mail]>
Subject: Rainbow printer interrupts and CP/M 86 Kermit
To: decvax!mulga![e-mail]
cc: [e-mail]

[Ed. - This is in response to a suggestion in the previous issue of
the Info-Kermit digest that the problem with printer interrupts
hanging CP/M-86 Kermit could be solved by zapping the interrupt
vector.]

Unfortunately, it's not that easy.  There are two separate problems:
the first is that the printer and the comm port share the same
interrupt vector, so the printer interrupt can't be handled
separately.

The second problem is that the communications chip needs to be
told that processing for certain kinds of interrupts (notably status
change) is over; just doing an IRET will hang the machine (presumably
because the interrupt keeps on occurring until the chip is told the
interrupt has been taken care of).

MS Kermit gets around this by handling status change interrupts for
the COMM port and reflecting all interrupts from the printer port back
to DOS.  Paul Ford of U. Chicago graciously fixed CP/M Kermit to do
the same thing; his changes should appear in the next release.

                            Jeff Damens

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

From: Ira Winston <[e-mail]>
Subject: Bug in MS-DOS Kermit V2.26 for the DEC Rainbow
To: [e-mail]
Date: Wed, 12 Sep 84 08:01 EDT

This is a great program!  Everyone here really likes it.

However, there is one small problem.  When using the PREV SCREEN and
NEXT SCREEN keys to page through the text, line are occasionally
deleted from the screen.  For example, when I type prev screen
twice and then next screen twice, the cursor appears one line below
its original location and one line on the previous two screens is
missing.  If you fix this problem, please let me know and I will
transfer the new version.  Thanks.

[Ed. - Thanks for the report; we hope to have this problem fixed in the
next release.]

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

Date: 10 Sep 84 18:10:28 EDT
From: D. M. Rosenblum <DR01@CMU-CC-TE>
Subject: Re: v2.26 heath emulation bug
To: SY.FDC@CU20B

This concerns the message of Wednesday 29 Aug 1984 0445-EDT from Bruce
Nemnich <godot!bruce@cca-unix> of Thinking Machines Corporation,
Cambridge, MA.  I checked on a real Heath-19 (actually a Zenith-19,
which I am typing on right now, in fact) to see if tabs are
destructive, and I found that indeed they are not destructive.  So if
Kermit's Zenith-19 emulation is indeed doing destructive tabbing, as
he suggests, then it is indeed incorrectly emulating the Zenith-19.

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

From: Bruce Nemnich <godot!bruce@cca-unix>
Date: 10 Sep 1984 1644-EDT (Monday)
To: [e-mail]
Subject: destructive tab fix for IBM v2.26

Here is the diff of a fix for the descructive tab bug I reported
earlier.  It also makes the default to have wrap set on by default,
which some h19 drivers also assume. (How about a command SET HEATH
WRAP [OFF | ON]?)

The modified file is MSYIBM.ASM.  First, set line wrap on by default:

334c334
<     jz    term1            ; no, forget this part
---
>     jz    term0            ; no, forget this part
335a336,337
>     jmp    term1            ; don't reset wrap mode
> term0:    or    flags1,lnwrap        ; start out in wrap mode

Fix the destructive tab bug:

786c788
<     xor    dl,dl
---
> wrap:    xor    dl,dl
837,848c839,846
< outtab:    mov    dl,byte ptr cursor    ; get initial column
< outta1:    mov    dh,dl            ; save column ptr
<     push    dx
<     mov    al,' '            ; output a space
<     call    outtty            ; convenient, huh?
<     pop    dx
<     mov    dl,byte ptr cursor
<     cmp    dh,dl            ; is it moving?
<     je    outta2            ; no, forget this
<     test    dl,7            ; is it a multiple of 8?
<     jnz    outta1            ; no, keep going
< outta2:    ret                ; else return
---
> outtab:    add    dl,8            ; tab width
>     and    dl,0f8h            ; round up to next tabstop
>     cmp    dl,79            ; have we gone too far?
>     jle    setcur            ; ...nope, go ahead
>     test    flags1,lnwrap        ; ...yes, are we in wrap mode?
>     jnz    wrap            ; ......yes, do the wrap
>     mov    dl,79            ; ......no, sit at end of line
>     jmp    setcur            ; and that's that

--Bruce Nemnich, Thinking Machines Corporation, Cambridge, MA
  {astrovax,cca,harvard,ihnp4,ima,mit-eddie,...}!godot!bruce, [e-mail]

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

End of Info-Kermit Digest
*************************
-------
14-Sep-84 18:57:37-EDT,5065;000000000000
Mail-From: SY.FDC created at 14-Sep-84 18:57:20
Date: Fri 14 Sep 84 18:57:20-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #26
To: [e-mail]

Info-Kermit Digest          Fri, 14 Sep 84        Volume 1 : Number 26

Today's Topics:
                           Macintosh Kermit
               New Kermit for Data General RDOS Systems
          New Release of Kermit for Data General AOS Systems
            New Release of Kermit for HP-1000 RTE Systems
                  New Release of Apollo Aegis Kermit
                   MS-DOS Kermit on a Zenith Z-150?

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

Date: Fri, 14 Sep 84 11:51:55 pdt
From: Bill Croft <[e-mail]>
Subject: Macintosh Kermit
To: sy.fdc@cu20b

After transfering over the ker:mc1kermit.sh archive, I discovered it
contains 2 complete copies of the programs.  You should edit this
archive to remove the first half;  this will reduce confusion and
storage space.  (I'm probably not the first to mention this...)

The 2nd half of the archive also contains a kermit.dl, ready to
download or convert with fromhex.  I have posted kermit.dl and
kermit.rsrc (and kermit.doc) on <info-mac> at SUMEX.

[Ed. - Thanks Bill, and to the many others who sent similar messages.
I've fixed the file, and also moved the hex to a separate file,
MC1KERMIT.HEX.  Sorry for confusing everyone the first time around.
The files are on KER:MC1*.* on CU20B and COLUMBIA-20.]

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

Date: Fri 14 Sep 84 18:05:03-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Kermit for Data General RDOS Systems
To: [e-mail]

This is to announce Kermit for Data General systems running RDOS, written
by John Lee at RCA Labs in Princeton (no network address).  The program
was written on a Data General Nova/4 running RDOS Rev. 7.0 and Fortran 5
Rev. 6.14.  The source code is written in Ratfor, which compiles into
Fortran 5.  The Ratfor source code was not provided to Columbia University
for redistribution; the author felt that most Nova sites would not have
Ratfor or the necessary support libraries.   The program is provided in
Fortran form, complete with the necessary library routines.  The files,
including the Fortran program and some documentation, are in KER:RDOS*.*
on CU20B and COLUMBIA-20.

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

Date: Fri 14 Sep 84 18:05:30-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Release of Kermit for Data General AOS Systems
To: [e-mail]

This is to announce a new release of Kermit for Data General systems
running AOS, written by John Lee at RCA Labs in Princeton (no network
address).  The program was written on a Data General S/250 running AOS
Rev. 5.0 and Fortran 5 Rev. 6.14.  The source code is written in Ratfor,
which compiles into Fortran 5.  The Ratfor source code was not provided to
Columbia University for redistribution; the author felt that most Nova
sites would not have Ratfor or the necessary support libraries.  The
program is provided in Fortran form, complete with the necessary library
routines.  The files, including the Fortran program and some
documentation, are in KER:AOS*.* on CU20B and COLUMBIA-20.

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

Date: Fri 14 Sep 84 18:06:08-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Release of Kermit for HP-1000 RTE Systems
To: [e-mail]

This is to announce a corrected version of HP-1000 Kermit from
John Lee at RCA Laboratories in Princeton NJ.  The program is written
in Fortran (FNT7X) and runs under the RTE-6/VM operating system.
The files are available in KER:HPM*.* on CU20B or COLUMBIA-20.

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

Date: Fri 14 Sep 84 18:06:32-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Release of Apollo Aegis Kermit
To: [e-mail]

This is to announce a new release of John Lee's Apollo Aegis Kermit,
incorporating a minor change from Ted Shapin at Beckman Instruments
to allow the program to operate from any node in the Domain network.
The files are in KER:APO*.* on CU20B and COLUMBIA-20.

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

Date: 13 Sep 84 16:45:31 PDT (Thu)
To: info-kermit@cu20b
Subject: MS-DOS Kermit on a Zenith Z-150
From: Mike Iglesias <iglesias@uci-750a>

A user on campus tried the IBM-PC version of the old MS-DOS Kermit
on a Zenith Z-150.  He was using the terminal emulation mode with
a screen editor, and when the screen editor send the H-19 code for
'insert character', his cursor disappeared.  Does this happen on the
new MS-DOS Kermit?  He tried the same thing on an IBM-PC and everything
worked correctly, so I figure it's some incompatability in the
Z-150.

[Ed. - Anybody out there want to contribute MS-DOS Kermit system-dependent
modules for the Z-150?]

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

End of Info-Kermit Digest
*************************
-------
21-Sep-84 16:08:08-EDT,9592;000000000000
Mail-From: SY.FDC created at 21-Sep-84 16:07:30
Date: Fri 21 Sep 84 16:07:30-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #27
To: [e-mail]

Info-Kermit Digest        Fri, 21 Sep 1984        Volume 1 : Number 27

Today's Topics:
                   New Kermit for Heath/Zenith-100
                     Bug fixed in Multics Kermit
               MS Kermit V2.26 Key Translation Problem
         MS-Kermit V2.26 Heath Emulation Bug (Inverse Video)
        Another Patch for Kermit-MS V2.26 Heath Tab Emulation
                 Commodore-64 Kermit Progress Report
                      Apples and 80-Column Cards

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

Date: Fri 21 Sep 84 14:44:15-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: New Kermit for Heath/Zenith-100
To: Info-Kermit@CU20B
Cc: Info-HZ100@RADC-TOPS20, Heath-People@MIT-MC, Info-Micro@BRL

This is to announce a release of Columbia University's KERMIT file transfer
and terminal emulation program for MS-DOS systems (Kermit-MS v2.26), adapted
for the Heath/Zenith-100 with ZDOS 1.x (not tested on 2.x systems) by Jim
Knutson of the University of Texas at Austin (knutson@ut-ngp).  File
transfer and other protocol features work identically as in other machines
supported by v2.26 (such as the IBM PC & XT, DEC Rainbow, HP-150, Wang PC,
and NEC APC); terminal emulation includes most of the fancy Kermit-MS
features: Heath-19 emulation, session capture, mode line, key redefinition,
and printer control, but not screen rollback.  The files for MS-DOS Kermit
2.26 are available via anonymous FTP at hosts COLUMBIA-20 and CU20B as
KER:MS*.*.  Those who already have the MS-DOS Kermit files may specify the
new H/Z100 files alone as KER:MS*Z100.*.  The file KER:MSZ100.HLP describes
the system-dependent aspects of the H/Z100 implementation of Kermit-MS.
Please note that anonymous FTP access to COLUMBIA-20 is only available after
6:00pm eastern time.

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

Date: Fri 21 Sep 84 13:54:03-EDT
From: Frank da Cruz <[e-mail]>
Subject: Bug fixed in Multics Kermit
To: [e-mail]

A new version of Multics Kermit, 2.0h, has been installed to replace 2.0g,
which had a problem transferring files at 300 baud.  The new PL/1 source
files are in KER:MU*.PL1 on COLUMBIA-20 and CU20B.  Thanks to Paul Amaranth
of Oakland University, Rochester, Michigan.

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

Date: Tue, 18 Sep 84 22:28:01 cdt
From: [e-mail] (Jim Knutson)
To: cc.daphne@columbia-20
Subject: MS Kermit V2.26 Key Translation Problem

I ran into a problem while trying to set up the Z100 device dependent .ASM
files.  The problem is in the translation table handling.  Apparently, the
TELNET routine in MSTERM.ASM sets the HAVTT flag true whether or not the
table is being used.  This results in bizarre behaviour in my version if
the SET KEY command is not run to define something.  The IBM-PC version
probably never runs into this problem since the lclini routine in
MSXIBM.ASM redefines the backspace key to a rubout.  I would appreciate it
if you could look into the problem.  I would rather not dive into the
entire source code to figure out a fix.  I would imagine that just having
the DEFKEY routine set a flag would be good enough.

Thanks,
Jim Knutson
ARPA: knutson@ut-ngp
UUCP: {ihnp4,seismo,kpno,ctvax}!ut-sally!ut-ngp!knutson
Phone: [phone]

[That is a problem... I'd say we can get around it for now by testing the
length of the translation table (it's initialized to 0) and skipping the search
if it's 0.  Hope that's easy...  I'll make msterm set havtt correctly in the
next release.  - Jeff Damens]

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

Date: Tue Sep 18 1984 20:39:36
From: Marco Papa <[e-mail]>
To: Info-Kermit@CU20B
Subject: MS-Kermit V2.26 Heath Emulation Bug (Inverse Video)

It seems that the new version of MS-Kermit does not properly handle inverse
video in some situations.  We used it with a spreadsheet program (QCALC),
running under Berkeley UNIX.  This program makes heavy use of changes
between normal video and inverse video when displaying cells and moving
around the spreadsheet. The top row, that displays the cell names (A,B,C,
etc..) in inverse vedeo gets clobbered very often when jumping from one
position to another in the spreadsheet.

If we run Kermit V. 1.20 instead, everything is just fine.

Where any changes made to the way Kermit emulates the inverse video feature
of the H19?

Marco Papa
USC - Computer Science Dept.

[I haven't seen that happen, but I'll look into it.  If it's at all possible,
could you send me a (preferably short) session log that demonstrates it
(you can just use the "log" command in kermit)?  Thanks.  - Jeff Damens]

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

Date: Fri, 21 Sep 84 16:14 GMT
From: [e-mail]
Subject: Another Patch for Kermit-MS V2.26 Heath Tab Emulation
To: [e-mail]

I did a little research on a real H-19 to see how tabs behave.  First, the
tabs stops are at 8 column intervals, however once past column 72, each
additional tab only moves the cursor one space forward.  Also, tabs do not
wrap at end of line, independent of the setting of the "wrap at end of
line" switch.  As has already been suggested, tabs are non-destructive.
The following is an REDIT file which shows a patch I made to MSYIBM.ASM
to exactly emulate these behaviors:

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

REDIT 1(103) COMPARE by user BRENGLE, 20-Sep-84 15:40:14
File 1: PS:<KERMIT.IBMPC>MSYIBM.ASM.1
File 2: PS:<KERMIT.IBMPC>MSYIBM.ASM.2
***** CHANGE #1; PAGE 1, LINE 838; PAGE 1, LINE 838
        jle     setcur                  ; col 0, can't back up
        dec     dl                      ; back up col
        jmp     setcur                  ; and use if reasonable

outtab: mov     dl,byte ptr cursor      ; get initial column
outta1: mov     dh,dl                   ; save column ptr
        push    dx
        mov     al,' '                  ; output a space
        call    outtty                  ; convenient, huh?
        pop     dx
        mov     dl,byte ptr cursor
        cmp     dh,dl                   ; is it moving?
        je      outta2                  ; no, forget this
        test    dl,7                    ; is it a multiple of 8?
        jnz     outta1                  ; no, keep going
outta2: ret                             ; else return

 ---------------------------------
        jle     setcur                  ; col 0, can't back up
        dec     dl                      ; back up col
        jmp     setcur                  ; and use if reasonable

outtab: mov     dl,byte ptr cursor      ; get initial column
outta1: inc     dl                      ; move cursor right
        cmp     dl,crt_cols             ; are we still in range?
        jnb     outign                  ; no, then don't update cursor
        cmp     dl,72                   ; yes, then at or past column 72?
        jge     setcur                  ; yes, don't check tab stop
        test    dl,7                    ; no, then is it a multiple of 8?
        jnz     outta1                  ; no, keep going
        jmp     setcur                  ; yes, then go set cursor

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

Date: 20 Sep 84 18:10:05 EDT
From: Eric <[e-mail]>
Subject: Commodore-64 Kermit Progress Report
To: SY.FDC@CU20B

Hi Frank,

Well, I ran out of time at the end of the summer. Brian Beattie
(beattie@bbn-unix or beattie@mitre-gateway) has since been working on it.
As it stands right now, he has a working command parser which at present,
can only call a working 80 column VT52 terminal emulator (which has been
extensively field proven).  Work is just now beggining on the actual
communication protocol & disk I/O routines.  I really wish we had more
time to work on it.  If you know of people who want to put time in on the
project, have them send mail to Brian or me...

Eric

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

Date: Fri 21 Sep 84 00:40:25-EDT
From: Peter G. Trei <[e-mail]>
Subject: Apples and 80-column cards...
cc: [e-mail]

Here is a quick and dirty (emphasis on the latter) way to get kermit-65 to
work with most 80 column cards. It should work with all cards, but does
have some problems. The following code must be placed in kstart:, just
after the line 'sta basws+1' near the end of the section:

; 1st attempt to use 80 column cards. use 80 column card entry vector stored
; within dos to print to screen, by moving it to csw; [48]
    pha
    lda    $AA53
    sta    cswl
    lda    $AA54
    sta    cswh
    pla
; end of 80 column code

Compile kermit with Cross, and move the result up to your Apple. Now, if
you start up Kermit while you have your 80-column card active, Kermit
should use it.  You should set display-type to 2e so that lowercase shows
properly.

There are some problems; As it stands, there seem to be extra line feeds
between lines.  Terminal emulation no longer works well (at all).

I am working on making better accomodation for use of the Apple 80 column
card and the Videx card.  This is probably as good as it will get for other
cards.
                    Peter Trei
                    oc.trei@cu20b

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

End of Info-Kermit Digest
*************************
-------
27-Sep-84 17:08:01-EDT,16617;000000000000
Mail-From: SY.FDC created at 27-Sep-84 17:06:46
Date: Thu 27 Sep 84 17:06:46-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest v1 #28
To: [e-mail]

Info-Kermit Digest         Thu, 27 Sep 1984       Volume 1 : Number 28

Today's Topics:
                           VAX Kermit Bugs
                  Comments From a New MS-Kermit User
                    Kermit on Uniplus+ System III?
                    Posting Unix Kermit to Usenet?
                 IOBYTE support in Generic Kermit-80
             Rainbow CP/M 86 Kermit Wildcard Send Problem
          Bug in IBMPC/XT Kermit-MS 'set destination print'
                  MacKermit Problems with Kermit-10
                      MS-DOS Kermit 2.26 CRC Bug
                          MS Kermit vs BF160
                      Kermit-MS DOS 1.1 Support?

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

Date:    Fri, 21-SEP-1984 17:40 EDT
From:    Ronald A. Jarrell <JARRELLRA@VPIVAX3>
To:      Info-Kermit@cu20b
Subject: Vax Kermit bugs

We've run into a couple of problems with Vax Kermit.  Were using it
from MS-Kermit, over both rainbows, and ibm pc's.  With the Vax in server
mode, doing a remote help from the micro causes it to die consistently
on the description of the last command.  We also found a neat bug
that seems to cause on IBM-PC's a core dump, and on Rainbows a re-boot.
Do a REMOTE HOST DELETE FOO.BAR.1  (where the file name is a legal,
existing file, and specifying an existing version number). Or create
a com file of the following form:

        inquire "Foo" foo

and then to a REMOTE HOST @comfilename

Neat stuff.  I have no idea of where to look in the code, and don't have
Bliss to recompile it with anyway..

        -Ron
Bitnet: JarrellR@VPIVAX3
Arpa:   [e-mail]

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

Date:     Wednesday, 26 Sep 84 10:19:09 EDT
From:     rmcqueen (Robert C McQueen) @ sitvxa
Subject:  Problems reported by JarralR@VPIVAX3
To:       sy.fdc @ cu20b

Pro/Kermit talking to Kermit-VMS works find for the cases given in the mail
message.  I would assume that it has something to do with the MS/DOS Kermit.

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

Date: Mon 24 Sep 84 10:41:04-EDT
From: Jeff Damens <[e-mail]>
Subject: Re: [Ronald A. Jarrell <JARRELLRA@VPIVAX3>: Vax Kermit bugs]
To: [e-mail]

There was a bug in the remote host MS-DOS Kermit code the very first week we
released Kermit (before we'd made any tapes, I think).  I thought it was a vax
problem until I put remote host commands into unix kermit and had the same
thing happen to me!  Anyway, it turned out to be an MS kermit bug... if he
replaces the MSFILE module with the one on CU20B, the problem should go away.

                        Jeff

[Ed. - The current MS-DOS collection is available on CU20B and COLUMBIA-20
(Arpanet/Internet and CCnet) and via KERMSRV (BITnet).]

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

Date: Tue, 25 Sep 84 00:36:30 pdt
From: Dave Tweten <[e-mail]>
To: [e-mail], [e-mail]
Subject: Comments From a New MS-Kermit User

I have a variety of questions and comments concerning recent Kermit
events.  I'm running the PC version of MS-Kermit on a Zenith Z-151, and as
a new convert to Kermit, let me congratulate you on a frog well done.

In Digest no. 27, Marco Papa discussed an H-19 inverse video problem
you aparently found new.  I too have experienced strange inverse video
behavior using Kermit, with 4.2 bsd UNIX.  Our H-19 termcap generates
inverse video for underlines in "man" displays.  When the last thing on a
line is inverse, the spaces after the next line turn inverse too.  This
behavior is independent of whether or not my system is configured with
ANSI.SYS (which someone had earlier stated caused an inverse video problem
on the Kermit file transfer "escape character" line).

    [Ed. - We've had a lot of comments and suggestions about the inverse
    video business; it should be fixed in the next release.]

In Digest no. 26, Mike Iglesias discussed Zenith Z-150 problems
running the PC version of MS-Kermit.  In addition, the editor requested
volunteers to do Z-150 specific modules for Kermit.  I don't believe that
should be necessary.  My friendly local Heathkit store manager assures me
that Heath/Zenith regards any such behavior as a bug.  Perhaps Mike should
check the revision level of his BIOS ROMs.  The same store manager informs
me that the most recent revision is level 4 (the ones that came with my
Z-151, delivered in May, were level 2).

    [Ed. - Can anybody confirm this from a real Z-150 with the new ROM?]

In Digest no. 20, Carl Diegert discussed assembly errors in MSFILE,
using MASM revision 1.25.  I have revision 1.27, and the same errors.  I
wholeheartedly endorse his solution.  It is even suggested by Intel's
ASM86 Language Reference Manual.  About LEA, it says, "You should use this
instruction only if EA requires run time calculation ...  Otherwise, you
should use MOV reg,OFFSET variable."

    [Ed. - The LEA's will be replaced by MOV's in the next release.]

After I made Carl Diegert's mod to MSFILE, and assembled and loaded
everything, I ran into a bug which is unique to the build-it-yourself
version.  Whenever I do anything which requires Kermit to crank up another
COMMAND.COM (PUSH, LOCAL DIRECTORY, etc.), the system goes into a tailspin
that only a warm boot will cure.  It endlessly repeats "Specified COMMAND
search directory bad".  I repeat, this does NOT happen with the
Columbia-provided .EXE file.  Could someone have debugged Kermit by
patching the .EXE without modifying the source?  No!

    [Ed. - Our .EXE is consistent with our source files.  A few corrections
    were made in the first couple days of the current release - late July -
    and some people may have an earlier source file.]

In your announcement of MS-Kermit, and in the User Guide, you mention
(the name of) a modem-specific module, yet I can't find any mention of it
in the System-Dependent Code Specification.  What's the rest of the story?
In my opinion, "smart" modem management is the only department in which
Kermit does not already surpass its $100 competition.

    [Ed. - It's the "null module".  People with internal modems are invited
    to contribute modem-specific modules for their particular modems.]

Again, many thanks for a job well done.

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

Date: Sat, 22 Sep 84 18:56:27 edt
From: colossus!barmar@mit-eddie
Subject: Kermit on Uniplus+ System III
Apparently-To: info-kermit@columbia-20

I tried compiling the recently announced revision of Unix Kermit on my
Honeywell microSystem NX, which is a 68000 workstation running Unisoft's
Uniplus+ System III.  The file UXKERUNX.C failed to compile, complaining
about the symbol TANDEM being undefined.  I thought this version was
supposed to work on System III; I believe that TANDEM is a Berkleyism.

Has anyone else had this problem?
                    barmar

[Ed. - Actually, the new Unix Kermit doesn't claim to run under System III
or System IV.  That'll be the NEXT release.]

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

Date: Sun, 23 Sep 84 14:29:11 EDT
From: hart%cp1 at BRL-BMD
To:   Info-Kermit@COLUMBIA-20
Subject: Posting Unix Kermit to Usenet

Hi Frank! Are you guys going to post a Unix kermit on Usenet someday?
I DON'T need the whole distribution, just the Unix source.  Evidentally
every micro user already has a copy.

Rod Hart

[Ed. - I've looked into posting Unix Kermit on Usenet.  Turns out that I
just don't have a way to do it.  Any volunteers?  The current release is
in KER:UX*.* on CU20B and COLUMBIA-20.  There will be a newer release in
a few weeks, I hope, so it might make sense to wait a bit.]

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

Date: Tue 25 Sep 84 09:41:34-CDT
From: John Otken <[e-mail]>
Subject: IOBYTE support in Generic Kermit-80
To: SY.FDC@CU20B

Your message provided a good opportunity for me to flame for a while
concerning a particular aspect of Kermit which could use some improvement.

The problem (at least with the version of Kermit I used) was the way that
the generic version is implemented.  This version manipulates the IO byte
to switch the console to and from the serial port.  Kermit insists that
it knows the correct values to set the IO byte to and although they may
be correct according to the CP/M documents it is NOT the way I have seen
many systems impelment it.  The way I implemented IO byte control on a
file transfer program we use here at UT is to provide a command to set
the value of the IO byte used for the serial port.  The value used for
the console is obviously just remembered from when the program was started.

This makes it very easy for people to use because they can try each of
the four possibilites in terminal mode.  Once the correct value is found
it is entered into an initialization file.  Now I am not suggesting that
you provide a command for this but I am suggesting that you have a
single byte at the beginning of the program which includes clear instructions
on patching (changing, whatever).  As it stands, it took me a serveral
hours to go through the source and find all the places which had the
IO byte code hard coded in.  And I am very confident with 8080 assembler --
I hate to think what a novice programmer might do.  BTW, just in case
some hot shot sez, "Oh, that guy doesn't know what he is talking about...
You can just change the equates.."  Well, that doesn't work.  I tried that
first.

Just a suggestion.  I think you have done pretty good job wrt kermit.

John Otken.

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

Date: 25 Sep 1984 17:15 PDT
From: Charles Carvalho <CHARLES@ACC>
Subject: Re: IOBYTE support in Generic Kermit-80
To: CC.OTKEN@UTEXAS-20, SY.FDC@CU20B

The "generic" Kermit-80 for CP/M 2.2 (assembly switch GENER) supports six
port selections, to improve the chances of finding one that works.  Kermit
reads from PTR: and writes to PTP: by default;  if this does not work, try
"SET PORT TTY".  The following table lists the CP/M devices used for each
option:

    SET PORT xxx    input from    output to
        CRT           CRT:           CRT:
        PTR           PTR:           PTP:
        TTY           TTY:           TTY:
        UC1           UC1:           UC1:
        UR1           UR1:           UP1:
        UR2           UR2:           UP2:

In all cases, the console (CON:) and list (LST:) devices used are those
selected when Kermit is started.

                        /Charles

[Ed. - The new version of CP/M-80 Kermit will be announced shortly.]

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

Date: Tue, 25 Sep 84 16:29:44 edt
From: fryback@nlm-vax (Dennis Fryback)
To: info-kermit-request@columbia-20
Subject: Rainbow CP/M 86 Kermit Wildcard Send Problem

In trying to send a group of files to the remote using a wildcard (for
example, "send g:q*.pas") it seems that the rainbow kermit sends the first
file to match just fine.  But then it signals "completed" and returns to
the kermit 86 prompt.

I thought this might be a problem with the receiving kermit on our VAX,
but when I used mskermit to send a group of files from my PC to the VAX it
worked just fine.

Is this a bug in rainbow kermit (CP/M-86, version 2.7)?  Is there a later
version than this one available?

Thanks for the help.

                          Dennis Fryback
                          National Library of Medicine
                          (fryback@NLM-VAX)

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

Date: Tue 25 Sep 84 15:31:03-PDT
From: Ronald Blanford <[e-mail]>
Subject: Re: Rainbow CP/M 86 Kermit Wildcard Send Problem
To: SY.FDC@CU20B

I haven't experienced this problem at all, but it may be related to
the DMA segment initialization which also affected the new directory
command.  If so release 2.8 would fix it.

I use wildcard uploads all the time.  Don't Rainbow users do this?
Why hasn't the problem surfaced before?

-- Ron

[Ed. - Actually, the problem occurs in both 2.7 and 2.8, whenever you do
a wildcard send from any drive other than your currently logged-in one.
Wild sends from the current drive work fine.  This problem may be fixed
before 2.8 is released, which should be soon.]

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

Date: Tue 25 Sep 84 13:55:49-PDT
From: Ted Markowitz <[e-mail]>
Subject: Bug in IBMPC/XT Kermit-MS 'set destination print'
To: [e-mail]

When using Kermit to dump directly from the host (TOPS-20) to a printer
rather than routing it through an intermediate PC file, the next to last
packet seems be printed twice. Once in it's normal progression and then
again after the last packet has been printed.
This happened when downloading a number of files using a wildcard GET
command from a server.

--ted

[Ed. - We'll look into this one, and will try to have it fixed in the
next release.]

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

Date: Wed, 26 Sep 84  9:13:19 EDT
From: Dave Swindell <dswindel@bbn-labs-b>
Subject: MacKermit Problems with Kermit-10
To: [e-mail]
Cc: [e-mail], [e-mail],
    [e-mail]

I recently FTP'd the hex file for MacKermit over to one  of  our  UNIX
machines  dehexified  it, and used macput to transfer the output .rsrc
file to a Macintosh.  When I tried to use  the  resulting  program  to
connect to a DEC 10 running TOPS 10, I had the following problems:

    1)  In  terminal  emulation mode, MacKermit would occationally
    'forget' where received characters should be displayed.   Fre-
    quently,  MacKermit  would  overwrite  the  last  line  and/or
    character it displayed.

    2) While in terminal emulation mode, MacKermit would bomb  out
    leaving me with the message: System error id=2 (and the little
    bomb).

    3) When I tried to send or receive files to Kermit-10  on  our
    DEC  10,  MacKermit  would simply hang.  I would have to press
    the reset switch and reboot.

I was running at 4800 baud, 8 data bits, 1 stop bit,  no  parity,  and
with   Xon/Xoff  support.   I  specified  'Macwrite'  format  for  all
attempted file transfers.

Any help which you could  provide  in  helping  us  get  MacKermit  to
perform  correctly  would  be  appreciated.  If you have any questions
concerning this message, please let me know.

Dave Swindell
BBN Labs
dswindell@bbn-unix

[Ed. - Steve, are you out there?  We have been able to transfer files
with a DEC-20, which is very similar to a DEC-20, although when
selecting MacWrite format, we get an awful lot of junk mixed in.]

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

Date: Wed 26 Sep 84 16:43:25-EDT
From: Frank da Cruz <[e-mail]>
Subject: MS-DOS Kermit 2.26 CRC bug
To: [e-mail]

When you download a file to the PC and the packets are 94 characters long,
with CRC's being done, the PC will erroneously detect a bad CRC.  If the
packet length is 93 or anything less, the CRC is fine.  Thanks to Paul
Amaranth of Oakland University for the report; he detected it while testing
a new release of his Multics Kermit against the IBM PC.  - Frank

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

Date: 26 Sep 84 23:44:04 EDT
From: J. Ray Scott <JS5A@CMU-CC-TA>
To: sy.fdc@CU20B
Subject: MS Kermit vs BF160

We've found that the new MSKermit does not work with the BUF160 program from
the INFO-PC program library.  Using the two together hangs the PC.

In general, the new MSKERMIT is great.  Thanks for a great product!!

                J. Ray Scott

[Ed. - I assume BUF160 is one of those programs that expands your DOS
typeahead buffer.  Another bug to be fixed in the next release...]

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

Date: Thu 27 Sep 84 16:46:35-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit-MS DOS 1.1 Support
To: [e-mail]

Are there any users of Kermit on MS-DOS or PC-DOS systems who have any
good reasons why pre-DOS-2.0 support should be maintained in Kermit-MS?
Making the next release of Kermit-MS require DOS 2.0 or above would
simplify the program a lot, and it would dramatically decrease the size
of the .EXE file (since many of the present static buffers could be
allocated dynamically at runtime).  Isn't it true that many of the most
popular software packages, like Lotus, require 2.0 and above?

- Frank

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

End of Info-Kermit Digest
*************************
-------
 4-Oct-84 21:57:17-EDT,30719;000000000000
Mail-From: SY.FDC created at  4-Oct-84 21:57:00
Date: Thu 4 Oct 84 21:57:00-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #29
To: [e-mail]

Info-Kermit Digest         Thu, 4 Oct 1984        Volume 1 : Number 29

Today's Topics:

                     New Release of DEC-20 Kermit
                Kermit-80 for Compupro Interfacer 3/4
             Bugs in MS-DOS Kermit Bootstrapping Programs
                       Kermit-MS 2.26 on PC/AT
                        Kermit-MS 2.26 on PCjr
             Kermit-MS DOS 1.1 Support (several messages)
                Kermit-MS V2.26 Bug Reports (several)
                 CP/M-86 Kermit Wildcard Send Problem
                     CP/M-86 Kermit Enhancements
                    Posting Unix Kermit to Usenet
                        GCOS KERMIT On the Way
                   170Kermit on NOS 2.3, Bug Fixes
                    DEC Pro-350 Kermit Suggestions

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

Date: Thu 4 Oct 84 09:34:48-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Release of DEC-20 Kermit
To: Info-Kermit@CU20B

A new release of DEC-20 Kermit is now available which includes a simple
"login script" facility.  This new feature allows those who use Kermit-20
in local mode -- out an autodialer, or hardwired TTY port connection to
another system -- to automate the procedure for connecting to and logging
in on the remote system, either from an interactive terminal or under
TOPS-20 Batch.  It consists of three new commands: INPUT, OUTPUT, and
PAUSE, plus a SET INPUT command to control the characterics of the INPUT
command.  These may be combined with other Kermit-20 commands in TAKE
command files.  Nesting of command files provides a way to conditionally
execute commands depending on input.  Here's a sample script file for
logging into a Unix system, sending a file, and logging out.

    output \15
    input login:
    output myuserid\15
    input 10 password:
    output mypassword\15
    input 20 %
    out kermit r\15
    send foo.bar
    in %
    out \4

"\15" is a carriage return, "\4" is a Control-D (that's how you log out
from Unix), "%" is the Unix system's prompt.  The number following the
INPUT command is the number of seconds to wait for the requested input
before timing out and proceeding to the next command.  SET commands are
provided for the default INPUT timeout interval, timeout action (quit/pop
or continue current command file), and alphabetic case sensitivity in
INPUT string matching.  Also, CLEAR (buffers) and ECHO commands have been
added, for use with this facility, and there are some fancier features for
"if-then-else" simulation, allowing you to input data from the terminal
during script execution, etc.

In addition, this release now includes a TRANSMIT command to perform "raw
upload" of a file without packet protocol to a remote system that doesn't
have Kermit.  The file is sent line at a time, using the desired parity
and handshaking, and synchronized with any specified "prompt" (e.g. from
a line editor) on the target system, or manually by the user.

The script and transmit features will serve as as models for other Kermits.
In particular, they will probably find their way into the next release of
MS-DOS Kermit.

The new Kermit-20 is available via anonymous FTP on CU20B and COLUMBIA-20
as KER:20KERMIT.MAC and KER:20KERMIT.EXE.  The new manual chapter, which
explains the script and transmit features in detail, is in
KER:20KERMIT.DOC (with Scribe text formatter source in KER:20KERMIT.MSS).
This chapter has not yet been merged with the Kermit User Guide.

- Frank

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

Date: Thu 4 Oct 84 16:05:50-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit-80 for Compupro Interfacer 3/4
To: [e-mail]
cc: [e-mail]

This is to announce KERMIT-80 for Compupro Interfacer 3/4 with CP/M-80 2.2,
based on version 3.9A of CP/M Kermit.  It includes support for:

. Interfacer 3/4 board I/O.
. Terminal control sequences for Wyse Technology WY-100.
. Racal-Vadic Auto Dial VA212 modem
. US Robotics Password modem
. Sending break with <ESC> B while CONNECTed.

Contributed by:

    Guy Valiquette, M.D. (PS1.YAAGC@CU20B)
    Black Bldg. Rm 322
    Dept. of Neurology
    College of Physicians & Surgeons
    Columbia University
    630 W. 168th Street
    New York, NY 10032

The source is in KER:CPMPRO.M80.  The hex file is in KER:CPMPRO.HEX, and a
help/installation file is in KER:CPMPRO.HLP.  These files are available via
anonymous FTP from CU20B and COLUMBIA-20 (after 6pm Eastern time).

No attempt was made to build all the other CP/M Kermits from this source, so
for now it will have its own.  It is expected that Compupro IF 3/4 support will
be added to version 4 of CP/M-80 Kermit, the "modular version", soon after
version 4 is released.

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

Date: Fri 28 Sep 84 12:48:34-EDT
From: Frank da Cruz <[e-mail]>
Subject: Bugs in MS-DOS Kermit Bootstrapping Programs
To: [e-mail], [e-mail]

The Fortran-Basic program pair that is used for bootstrapping MS-DOS Kermit
initially from a mainframe to a PC does not work in certain cases.  There
were two small problems -- one caused the Fortran program to hang waiting for
input (in Fortrans that do not supply default values for missing variables on
a READ statement), the other an erroneous GOTO that had the unfortunate
quirk of not breaking the program on systems whose Fortran happened to
initialize arrays with blanks...  Anyway, the fixed versions are available
in KER:MSBOOT.FOR and KER:MSPCBOOT.BAS on CU20B and COLUMBIA-20.  If you can't
(or would rather not) get the new files, the changes are small:

In MSBOOT.FOR, after the statement 200 FORMAT(4A1), change

    GO TO 30
to
    GO TO 20

In MSPCBOOT.BAS, change line 100 to:

100  print#1,"O ,2"            ' Char constants Oh,Space,Comma,Two.

Thanks to Jeff Ramsey of DGM&S, Delran NJ, for pointing out these problems.

An additional problem has been noted, but not yet fixed.  Those who use a
file capture facility to download a .BOO file and then run MSPCTRAN
directly on the .BOO file should beware of extraneous characters inserted
by the host.  In particular, some hosts may insert NUL or DEL characters
as padding after a carriage return or linefeed.

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

Date: Wed Oct  3 1984 12:33:51
From: Marco Papa <[e-mail]>
To: [e-mail]
Subject: MS-Kermit 2.26 on PC/AT

Has anybody tried to run MS-Kermit 2.26 on a PC/AT ?  What are the results?

Marco
USC - Computer Science Dept.

[Ed. - It sort of works.  We had an AT on loan here for a short while.
At first Kermit seemed to work on it -- we could run our video editors
while CONNECTed as an H19, we could transfer files, etc.  Later, it was
discovered that if you issued any REMOTE commands from the AT, the
program would bomb with messages like "Drive A not ready" when drive A
was not being used at all.  Subsequently, we got a floppy disk in the
mail from Dale Smith at the University of Oregon Computing Center
containing "the single modification necessary to make KERMIT run on the
new IBM AT."  Here is the change:

University of Oregon modifications to the MSRECV module of MS Kermit

(01) Modify to work on IBM AT
     (Version 2.26/UO.01 -- Dale Smith -- 10 Sep 84)

     A. On the IBM AT, there are a few things that are different.  One
    of them is that on all REMOTE commands, the AT gets an error
    reading drive A: at the end of the text from the remote host.
    The problem is apparently that DOS is changed enough that
    one cannot issue a DOS call to close a file that is not open (?).
    Anyway, we need to be a little more selective about what we
    do when we are receiving text from a REMOTE command on a remote
    host.  This edit does just that so Kermit will run unchanged from
    an IBM-PC/XT to an IBM-AT (two lines added, marked by [UO.0]).

rdat35: mov cx,chrcnt
    mov temp,cx
    call outbuf        ; Output the last buffer.
     jmp abort        ; Give up if the disk is full.
    mov ax,temp        ; Prepare for the function call.
    cmp flags.xflg,1    ;[UO.0] Writing to screen?
    je rdat37        ;[UO.0] Yes, skip a bunch of stuff.
    call fixfcb

This fix is as yet untested by us, so we can't guarantee that it works,
or that it's the only fix necessary for the AT.  Any volunteers?]

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

Date: 29 Sep 84 10:50:59-PDT (Sat)
To: info-ibmpc @ Usc-Isib.arpa
From: hplabs!hao!seismo!harvard!wjh12!bbncca!sdyer @ Ucb-Vax.arpa
Subject: PCjr and Kermit

[Ed. - This is an except of a message that appeared on Info-IBMPC
from someone who's had some experience running Kermit on the PCjr.]

Enter the PCJr.  I was immediately able to purchase a good VT100
emulator/XMODEM program (Mark of the Unicorn's PC/Intercomm).  The IBM PC
Kermit distribution works fine, too.  Either makes a fine remote terminal,
and I have had NO problems with XMODEM or KERMIT file transfers at 1200
baud; techies at first worried about the non-DMA disk drive--it locks out
interrupts during transfers, meaning that many comm programs might have
trouble.  Though I grant this, it hasn't been an operational problem.

I have noticed one problem with using PC/Intercomm (though not Kermit) at
1200 baud.  A nonmaskable interrupt is generated upon receipt of the start
bit of a character generated by the keyboard; the BIOS then acts as a
software UART, polling for bit transitions to generate the full scan code.
This seems to cause occasional problems when I type ahead of the display:
PC/Intercomm seems to get out of sync, and generates several characters
worth of fully filled white space (VT100 DEL chars.)  This may be due to
its handling of UART overruns; I can't say yet.

I am using version 2.26, and yes, I need to set the RS232 port to COM2.
Every now and then I seem to get some anomalies in H19 emulation,
but I haven't chased them down methodically, and I never ascribed them to
problems with the PCJr, per se.

Other than that, file transfers work just fine at 1200 baud without
any data loss.  I am quite impressed!

/Steve

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

Date: Sat 29 Sep 84 23:42:21-EDT
From: Peter D. Junger <[e-mail]>
Subject: Support for MSDOS 1.1
To: info-kermit@CU20B

[Ed. - This and the next several messages are in response to my query
about continued support for MS-DOS 1.1 in Kermit-MS.]

    Here at CWRU Law School we have a large number of Victor 9000's
and a few IBM PC's which use only DOS 1.1.  These machines are used
for word processing and there is simply no reason to upgrade them.
At the moment we do not make much use of Kermit with those machines,
but that situation is likely to change fairly soon since our faculty
will probably have more occasion to make use of some facilities
on the CWRU DEC20's.  I would not suggest, however, that you continue
support for 1.1 only for us.  I suspect, however, that we are not
alone in this conservatism.

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

Date:  Sun, 30 Sep 84 11:43 EDT
From:  "Eric J. Swenson" <[e-mail]>
Subject:  Kermit-MS DOS 1.1 Support
To:  [e-mail]

I, for one, would be disappointed if MSDOS 1.1 support were removed.  I
haven't yet been able to get a version of MSDOS 2.0 for my Zenith-100.
But if it presents a real programming obstacle to maintain support for
both, as long as you still provide a (the current) version of Kermit 2.26
(which supports both) then we 1.1 users can survive.  But please, don't
make us have to use Kermit 1.20.  -- Eric

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

Date: Sun 30 Sep 84 16:21:24-PDT
From: Ronald Blanford <[e-mail]>
Subject: MSDOS 2.0
To: [e-mail]

In response to your last question in the info-kermit digest, on the
APC the only versions of MSDOS that are available are 2.0 or above,
so in this particular case there is no reason to retain pre-2.0 support.
I agree that loading 80-some K to bring up Kermit is excessive.  Even
the 18K for 86kermit seems too long at times.

-- Ron

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

Date:  1 Oct 1984  8:46:24 EDT (Monday)
From: Earnie Boyd DRSTE-CM-F 4377 <[e-mail]>
Subject: 1.1 Support
To: Frank da Cruz <SY.FDC@CU20B>

Frank,
    For the H/Z100, LOTUS 123 runs under either version of Z(MS)-DOS.  Under
the GEA contract, Zenith is still delivering version 1.2.  I don't know
what is being delivered to the AF and Navy.
                                Earnie

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

Date:  Thu, 4 Oct 84 15:24 EDT
From:  [e-mail]
Subject:  MS DOS version 1.1 support for kermit
To:  [e-mail]

I would suggest that you forget about version 1 for any new work.  Keep
a copy of the last version that handles version 1 and freeze it.  There
are very few people still using version 1, it's not even available for
some of the newer machines.

[Ed. - Our current plan is to fix all known bugs in 2.26 and release the
result as, say, 2.27 with continued DOS 1.1 support.  After that, we'll
strip out the 1.1 support before adding any new features.  The program
is simply much too big the way it is now.]

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

Date: Thu 4 Oct 84 02:14:25-PDT
From: Ronald Blanford <[e-mail]>
Subject: MSKermit bug
To: [e-mail]

I haven't seen this one reported so I will.  The counter for number of
Kbytes transferred has a couple of problems, the first of which is that
the display is not cleared between files in a wildcard transfer, so that
the early (single) digits of the new file are followed by the last digits
registered for the previous file.  The second problem is that when
the count passes 63 Kbytes, instead of 64 the count jumps to 1024 Kbytes
and continues from there.

These are only minor annoyances and don't adversely affect the program's
operation.

-- Ron

[Ed. - These are the most widely reported bugs in 2.26; I probably forgot
to post any of the reports to Info-Kermit.  The Kbytes display will be fixed
in the next release of Kermit-MS.]

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

Date:  1-Oct-84 11:50:11-PDT
From: [e-mail]
Subject: Inverse video problems with MS-Kermit
To: [e-mail]

About inverse video in the MS-Kermit H19 emulation:

You might check this against some program other than Unix "more" (the
pager used to display man pages, among other things).  Our copy of
"more" does a bad and buggy job of handling inverse video.  I have seen
it highlight an entire line following a highlighted word.  It also ignores
some termcap fields (like "leaves extra space when entering/leaving standout").
This may be due to misuse of termcap, or general braindamage.

In short, test the H19 emulation with something more reliable than "more"
before you try to fix a problem.

walter underwood

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

Date: Fri 28 Sep 84 10:14:08-EDT
From: Susan Zayac <[e-mail]>
Subject: ^Z EOF in MSKERMIT
To: [e-mail]

I just tried KERMITing a FinalWord file from the XT/370 to the DEC20B
with EOF set to CTRL-Z and the ^Z at the end of the file still came over.
All the otehr settings were teh defaults.  Any advice?

Sue/

[Ed. - It's a bug, see below.]

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

Date: Tue, 2 Oct 84 08:02:39 pdt
From: dual!islenet![e-mail]
To: Info-Kermit@CU20B
Subject: Kermit-MS V2.26

Aloha - After a couple of weeks with V2.26 of Kermit-MS, here's
a collection of comments.  First, from one of my most serious Kermit
users (he adapted V1.18 for his NEC APC under both MS-DOS and CPM-86):

/////////
* David - The MSFILE module has two rather substantial bugs:
*
*    1. When sending, it puts an unquoted 00H byte in the first position
*       of the data field of all F and D (data) packets. This extraneous
*       byte  screws up the chr count for file closing because it is
*       usually (but not always) compensated for by a second bug that
*       miscounts the chars - depending on the exact file length. At
*       the receiving end the unquoted `null`s get filtered out and do
*       not usually get in the way. They do not show up when debug is
*       set on, since they are also filtered out by the display routine,
*       although you can detect them if you look at the charcount char
*       in the packet.
*
*    2. Possibly as a consequence of the above, the EOF CTRLZ file
*       closing routine gives unreproducible results during both recceiving
*       and sending , and it does not perform at all as described in the
*       new MSKERMIT section of the users-guide.
*
* I have identified the source of the first bug as in the
* ENCODE routine in MSFILE, but I don't have a fix yet. The second
* I don't consider worth looking at until the first has been fixed.
*
* Naturally I would prefer taking ready-made fixes if they are available, but
* if not they are not I am prepared to put in a modest ammount of time myself.
*
* Ian
\\\\\\\\

I advised him to hold off until I hear back as to whether these are problems
you might already be working on (Bill mentioned that there were some bugs that
had already been fixed).

[Ed. - The CTRLZ business definitely doesn't work right, but we're not
sure the diagnosis above is correct, though we'll certainly check it.
Another possible problem is that ENCODE is checking for a Control-Z AFTER
it has been encoded to #Z, so naturally it won't find it.  See next message.]

Second,  I've done the following simple mods which I can send if you're
interested:

1) Moved the "plus key thing" which toggles the status line in MSYIBM to
AFTER the key translate table consultation, so that the plus key can be
redefined if desired.  Then I can use SET KEY to redefine the keypad plus
to be H19 ENTER, since it's in the perfect location.

[Ed. - Good idea, we'll move it.]

2) Added a module to MSXIBM and code in MSTERM for an ESCAPE-D command to
drop the communication line for 3 seconds.  This hangs up on our Gandalf PACX
(and many modems) so that I can select another computer without turning off
my PC or pulling the connector out of the comm port.  Code to drop DTR was
added in the style of the existing BREAK (ESCAPE-B) code.

[Ed. - Good idea, we'll add it.]

3) Added code to MSYIBM to make the IBM PC F10 key, if not redefined, behave
like the SCROLL/NO SCROLL key on DEC terminals; it sends ^S and ^Q on alternate
keypresses.  Note that this is NOT how the H19 scroll key behaves (but I wish
it were).

[Ed. - Tough to make that one machine independent; better just to use two
keys, defined with SET KEY commands.]

4) I also have an mskermit.ini file which makes the shifted keypad behave
like the H19 keypad.

[Ed. - I'm sure lots of people would find this useful.]

Finally, another question: is there any way to put a SET KEY SCAN command
into a macro?  The macro seems to terminate at the end of line, and SET KEY
SCAN seems to require 2 lines.  Would be nice for when I switch between systems
that use DEL and BS for rubout.  Current I TAKE a file to redefine the
backarrow, but I'd like to eliminate the disk access.

[Ed. - Yes, just separate the two parts of the command by a comma.]

With this release I now use Kermit as my standard terminal package, replacing
my $100 VT-100 emulator.  I drag that out only for file transmits to our as
yet un-Kermitted systems: an HP-3000 (no Software Tools) and MVS/TSO (see next
note).

Thanks!
David Lassner,
University of Hawaii Computing Center

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

Date:        26 Sep 84 17:47 +0200
From:        [e-mail]
To:          Info-Kermit <info-kermit@COLUMBIA-20>
Subject:     Bug (?) in MSSEND.ASM

Someone here found a bug in MSSEND.ASM -- End-Of-File is not
correctly treated.  Here's a FILCOM listing of his hacks:

File 1) DSKA:MSSEND.ASM[5,61]   created: 0056 24-Jul-84
File 2) DSKG:MSSEND.ASM[60,203] created: 1213 19-Sep-84

1)1             cmp al,'Z'-40H          ; is it a ctl-z?
1)              je sdata5               ; yes, break loop
1)              stosb                   ; else copy it
1)              loop sdata4             ; and keep going
****
2)1     ;       cmp al,'Z'-40H          ; is it a ctl-z?
2)      ;       je sdata5               ; yes, break loop
2)      ;       stosb                   ; else copy it
2)              cmp al,trans.squote     ;* Bug fixed 84-09-18 CB/Paralog
2)              jne sdat41              ;* if not quote carry on
2)              stosb                   ;* else store quote character
2)              dec cx                  ;* decrement size
2)              lodsb                   ;* get next byte
2)              cmp al,'Z'              ;* have we detected a ctl-z?
2)              jne sdat41              ;* no, continue loop
2)              inc cx                  ;*
2)              inc cx                  ;* dont send quote character
2)              jmp sdata5              ;* break loop
2)      sdat41: stosb                   ;* no, copy it
2)              loop sdata4             ; and keep going
**************

[Ed. - Actually, the check could be made earlier, before/during the encoding.
The CTRLZ bug will be fixed in the next release.]

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

Date: Tue Oct  2 1984 14:25:17
From: Marco Papa <[e-mail]>
To: [e-mail]
Subject: Re: received floppy

Jeff,
Glad you got the floppy.  Since I'm here, I'll report another bug of
MS-Kermit 2.26 (I don't recall of having seen it yet in the digest).
My XT has MSKERMIT.INI that does a SET BAUD 1200.  I usually use COM1:,
but use COM2: sometimes.

When I execute the command SET PORT 2 (or COM2), the new port is chosen but
the baud rate is screwed up, and a STAT command will say:

Baud rate is unknown

If then I SET PORT 1, the baud resets back to the original 1200 bauds.

Marco

[Ed. - We'll check this one, too, and fix it in the next release if it needs
fixing.]

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

Date: Wed 26 Sep 84 15:53:07-PDT
From: Ronald Blanford <[e-mail]>
Subject: Re: Kermit-86 wildcard send problem
To: Info-Kermit@CU20B

The problem does indeed occur on the APC as well.  Good work in pinpointing
it, Frank.  I found the bug; a minor omission in the code of finding the
next file.  The new version of 86KERFIL.A86 containing the correction is
now on my account for uploading.  There are also new versions of APCKERMIT.H86
and APCKERMIT.CMD which work correctly.

-- Ron

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

Date: Sun 30 Sep 84 16:05:27-PDT
From: Ronald Blanford <[e-mail]>
Subject: 86kermit
To: [e-mail]

Frank,

Sorry if this causes you extra trouble.  I've taken advantage of the
delay in releasing version 2.8 to improve it somewhat.  In particular,
the directory list has been changed to appear in sorted columns with
the size of each file displayed next to the name.  There is also a
total of number of files and Kbytes listed.

A second change is the addition of the local DELETE (or synonymously
ERASE) command for removing files.  Each file that matches the wild
filespec entered is displayed for verification before deletion.  At
that time, a 'Y' entry deletes the file, 'N' skips to the next file,
and ESC aborts the delete routine.  Entry of a '?' displays a help
message listing the available options.

Also, in view of the comments in the last info-kermit digest about the
8086 LEA command, I've changed all the occurrences of LEA xx,yy to
MOV xx, OFFSET yy in all of the modules of 86kermit.  There were no
occasions whatsoever where the address needed to be computed at run time
rather than compile time.

The source files and APC assembly files are available as usual on my
account.  You should upload all of the files, since there has been
some reorganization of the code to equalize file sizes.

-- Ron

[Ed. - Version 2.8 of CP/M-86 Kermit will be announced shortly.]

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

Date: Fri, 28 Sep 84 11:15:20 cdt
From: [e-mail] (Jim Knutson)
To: sy.fdc@cu20b
Subject: Re: Posting UNIX Kermit for usenet

I posted a copy of it to usenet for you.

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

Date: Fri 28 Sep 84 18:19:52-PDT
From: Bob Larson <Blarson@Usc-Ecl>
Subject: Posting Unix Kermit
To: [e-mail]

I belive if you mail the source to unix-sources@brl it will be
forwarded to net.sources on uucp.  Notices of posting to info-unix
and unix-wizards would probably be nice.  Someone just posted it so
don't repost until you have a new version.

Bob Larson <Blarson@Usc-Ecl>

[Ed. - Thanks, Jim, Bob, and everyone else who responded.  Now I know how
to do it next time.]

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

Date:  Thu, 27 Sep 84 07:41 MST
From:  Terry Carlin <[e-mail]>
Subject:  GCOS KERMIT
To:  [e-mail]

Frank, I just put the GCOS versions of KERMIT in the mail.  It includes
a 'PRINTABLE' version and an assembly language program to recreate the
system loadable file.  If you have any problems reading the tape etc,
please yell.  Terry

[Ed. - Will announce it as soon as it arrives.  Also included is the C
language source.  It runs on DPS/8 and DPS/6 systems with either GCOS8
or GCOS3.  There's also an adaptation of IBM PC Kermit 1.20 for the
Honeywell MicroSystem 6/10.]

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

Date: Tue, 2 Oct 84 21:17:19 pdt
From: Dave Tweten <[e-mail]>
To: [e-mail]
Subject: 170Kermit on NOS 2.3, Bug Fixes

     In a selfish attempt to get Kermit implemented on a machine I
occasionally use, some time back I gave a copy of the latest 170Kermit
to a friend at CDC's Sunnyvale installation, Ted Brown.  I succeeded
beyond my greatest expectation.  Not only does it work well on the
Sunnyvale CDC machines, but Ted offered to let me relay what he learned
about 170Kermit back to Info-Kermit.

     If you wish to communicate to Ted through the net (CDC Sunnyvale
isn't connected), feel free to relay the message through me.

     What follows is Ted's message:

Date:  2 October 1984
To:    [e-mail]
       [e-mail]
       [e-mail]
From:  Ted Brown, Control Data Corporation
Subject:  Corrections to Kermit-170 Version 2.2 for NOS

I recently received a copy of Kermit-170 Version 2.2 and encountered
some problems when installing and executing it in the standard release
of NOS Version 2.3 (PSR Level 617).  Following is a description of each
problem, and attached to this letter is a NOS CCL procedure that
properly installs Kermit-170 with corrections for all the problems.
The procedure assumes the existence of a direct access permanent file
named KERMITS that contains the UPDATE source for the Kermit PL in the
first logical record and the source for the AZLIB PL in the second.

1.  The installation instructions in the documentation file are missing
    some parameters and control statements.
2.  Assembly errors occur due to incorrect usage of quotation marks and
    apostrophes in micro definitions.
3.  The default data mode (DISPLAY) is inconvenient.  ASCII would be
    more appropriate for the majority of file transfers.
4.  The terminal parameters for PW, PG, and EB are not restored after
    terminating binary mode.  Although it is not possible to determine
    their original values, they could be set to something with less
    negative impact for the majority of users.
5.  Subroutine CONBUFF aborts if Kermit is not compiled with OPT=0 due
    to an instruction that is overwritten by subroutine CFE when it
    clears the FET that is adjacent to CONBUFF's entry point.
6.  Single-character inputs are incorrectly processed.  Specifically, a
    question mark for help is not recognized due to a parsing error in
    subroutine CONBUFF.

Please feel free to contact me if you have any questions about my code.
Thank you very much for the excellent job that you are doing to support
and distribute Kermit!

Ted Brown
Central Software Support
Control Data Corporation
215 Moffett Park Drive
Sunnyvale, California  94089

Let me add that if you accept Ted's proposed change of the default
character code, a change will be required in the documentation for SET
DATA-MODE.

[Ed. - The updates are rather long, and were omitted from this message for
brevity's sake.  They can be found in KER:170KERMIT.BWR on CU20B or
COLUMBIA-20.  Also, note that this message, including the updates, were
sent directly to Jim Knutson, the original author of the program.]

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

Date: 4 Oct 84 16:54:04 EDT
From: Chris Koenigsberg <CK0C@CMU-CC-TE>
To: info-kermit-request@CU20B
Subject: DEC Pro-350 Kermit suggestion

I work in an office with an IBM PC and a DEC/PRO 350. The Kermit-MS for
the PC is fantastic. The Kermit for the PRO is better than the DEC
Communications package, but it would be really nice to have the key
redefinition feature added to PRO 350 Kermit, so we could put the Escape
key back where it belongs (I see from the Kermit-MS manual that this
feature is used on the DEC Rainbow, which shares the awful new keyboard
with the PRO).

Another feature from Kermit-MS, which is also available in Dec/Pro
Communications but not Pro Kermit, is the log file. If there were
capability to open a log file for host output, we would delete the
PRO/Communications package entirely from our PRO disk and just use Kermit
instead.  As it is, we need both packages, simply because of the need to
log a terminal session once in a while using the DEC-supplied program.

            Chris Koenigsberg
            Urban Systems Institute
            MM204 SUPA [phone]
            Carnegie Mellon University

[Ed. - The Stevens folks have been pretty swamped lately supporting their
Pro-350's -- something like 1400 of them! -- so don't expect any enhancements
any time soon.  Still, I'm sure they'll appreciate the suggestion.]

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

End of Info-Kermit Digest
*************************
-------
 8-Oct-84 18:10:18-EDT,17385;000000000000
Mail-From: SY.FDC created at  8-Oct-84 18:08:35
Date: Mon 8 Oct 84 18:08:35-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #30
To: [e-mail]

Info-Kermit Digest         Mon,  8 Oct 1984       Volume 1 : Number 30

Today's Topics:
                     Kermit Arpanet Distribution
                      Kermit for Honeywell GCOS
                Kermit for Honeywell MicroSystem L6/10
                   Oh no, Another Kermit! (Sperry)
                         CP/M-80 Kermit Tools
                 MS-DOS Kermit Bootstrapping Problem
                   MS-DOS Kermit Set Baud/Set Port
                       Unix Kermit Suggestions

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

Date: Mon 8 Oct 84 15:15:39-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit Arpanet Distribution
To: [e-mail]

I'd like to phase out network Kermit distribution from COLUMBIA-20 as soon as
possible.  I've been advertising new versions available from CU20B for the past
month or so, and have seen anonymous users from many sites connected to our FTP
server.  Unless I hear of serious problems with our FTP service, I will be
deleting the Kermit files from COLUMBIA-20 on Monday, October 22.  If there are
problems with FTP, of course we will attempt to fix them.  But bear in mind
that the files have to be removed from COLUMBIA-20 anyway; the owners of that
machine need the space back.  For those who missed previous announcements to
this effect, and have not yet placed CU20B in their host tables, CU20B is
Internet host 192.5.43.128.

FTP to CU20B works in the normal way.  Connect to host CU20B (or use the
host number if the name is not known), login as user ANONYMOUS, supply any
non-null password, and then use the DIRECTORY, GET, and MULTIPLE GET
commands in the normal fashion.  CU20B is a DECSYSTEM-2060 at the Columbia
University Center for Computing Activities.  Currently there are no
restrictions on the number or time of anonymous FTP logins, but since CU20B
is a busy system such restrictions may become necessary if FTP access
interferes with normal operations.  Please be selective about what files you
take, since the current collection takes up about 20 megabytes and is still
growing.

The CU20B Kermit directory is organized a little bit differently from the one
on COLUMBIA-20.  COLUMBIA-20 has all the Kermit-related files in a single
monolithic directory, <KERMIT>.  CU20B maintains several directories, as
follows:

Directory Name     Logical Name      Contents

<KERMIT>           KER:              Kermit programs: source and hex,
                                     manuals, help files, and other
                                     printable ASCII files.

<KERMIT-BINARIES>  KB:               Executable program images for various
                                     Kermit programs (not hex, real binary).

<KERMIT-TOOLS>     KT:               Cross assemblers and similar utilities
                                     used in building or maintaining
                                     Kermit programs on DEC-20s or DEC-10s,
                                     sources and binaries.

<KERMIT-EXTRA>     KE:               Extra, redundant, old, or variant versions
                                     of Kermit.

A "logical name" serves as an abbreviation for the longer directory name.  For
instance, KB:FOO.EXE is a short way to type <KERMIT-BINARIES>FOO.EXE.

The logical name KER: is defined to search all of these directories in order,
so that KER:20KERMIT.EXE will still find the DEC-20 Kermit executable program
file.  However, KER:20*.* will find the sources and documentation (which are in
a directory higher in the search order) but skip the binary.  If you want to
get all the files for a Kermit version that comes with both text and binary
files, you'll have to look in both places.  To get all the DEC-20 Kermit files
with FTP, for instance, you should "MULTIPLE GET KER:20*.*" and then "MULTIPLE
GET KB:20*.*".

Why are the files organized in this inconvenient way?  And since we're
discussing how the files are organized, why not break them up even further into
directories or subdirectories for each Kermit implementation, as many have
suggested?  It's because this same system (CU20B) is where Kermit distribution
tapes are made, most of them in ANSI format.  An ANSI tape is structureless --
there are no directories or subdirectories; every file on the tape must have a
unique name.  Furthermore, many of these tapes are destined for systems that
have flat file systems and/or short or otherwise restrictive filenames.  For
instance, many DEC operating systems allow filenames with only 9 characters
(6-dot-3) and forbid punctuation characters like dash.  Therefore, all the
files in the distribution have:

 . Names that are unique within 6-dot-3 format.
 . A period between file name and file type.
 . Only letters or digits in the name and type.

Each implementation has its own prefix, e.g. "20" for the DEC-20, "MS" for
MS-DOS, etc.  Since files are stored in alphabetical on the DEC-20, all
files for a particular implementation will be grouped together in directory
listings, or on a distribution tape, or when sent by FTP in response to a
MULTIPLE GET command.

The binaries have been separated from the printables because binary files
and ANSI tapes do not mix well.  The tools and extras have been moved to
separate areas simply because they no longer fit on a 1200' reel of tape at
1600 bpi.  As the size of the collection continues to grow, further measures
along these lines may be necessary.

Here's a reminder about some special files designed to cut down on network
traffic by answering the most common questions about Kermit:

KER:CURRENT.DOC - Lists in reverse chronological order all the versions of
  Kermit that we have "in stock" -- new additions at the top.  Answers
  questions like "Has there been a new release for VMS since last November?"

KER:VERSIONS.DOC - Lists all knows implementations of Kermit, whether we
  have them or not.  Answers questions like "Is anybody working on a Kermit
  for the Widget-8000?"

KER:00README.TXT - Tells what files are available in the Kermit distribution
  and lists the prefixes for each implementation; answers "How do I find
  Kermit for the Luxor ABC-800?"  Note the two leading zeros in the file name;
  this ensures that this file comes first in a directory listing or on a tape.

KER:FLYER.DOC - Explains our tape distribution policy; answers "How do I order
  a Kermit tape?"

KER:COMMER.DOC - Explains our policy toward commercial use and distribution
  of Kermit; answers "Can I include Kermit in my terminal emulation package
  that I want to put on the market?"

All these files are kept up to date.

Please try FTP to CU20B before Oct 22.  If you can't reach CU20B from FTP,
complain to your site manager.  If there turns out to be some "structural"
reason why your site can't FTP from CU20B (e.g. too many internet hops),
there's not much I can do.  If you have any other problems, please convey them
directly to me.

- Frank

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

Date: Fri 5 Oct 84 18:37:09-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit for Honeywell GCOS
To: [e-mail]

This is to announce KERMIT-GCOS for the Honeywell DPS 66 and DPS 8, running
either GCOS8 or GCOS3.  The program is written in the C language, adapted from
Columbia University Unix Kermit, and is distributed in both source and
printably-encoded binary form, so that GCOS sites without the appropriate C
compiler can still run the program.  Contributed by:

 Terry Carlin, Carlin%pco@MIT-MULTICS
 Honeywell Information Systems Inc
 7900 Westpark Dr.
 McLean, Virginia 22102
 [phone]

The files are in KER:HG*.* accessible via anonymous FTP from CU20B or
COLUMBIA-20 (after 6pm eastern time).  KER:HGKER.HLP lists the files and tells
what each is for.  All files in KER:, no binaries.

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

Date: Fri 5 Oct 84 18:37:51-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit for Honeywell MicroSystem L6/10
To: [e-mail]

This is to announce Kermit for the Honeywell MicroSystem L6/10 with version
2.11 of MS-DOS, contributed by Terry Carlin of Honeywell, McLean Va.,
Carlin%pco@MIT-MULTICS.  It's an adaptation of version 1.20 of MS-DOS Kermit,
but it comes with a ".BOO" file in the style of version 2.26 of Kermit-MS, and
with a special adaptation of MSPCTRAN.BAS to decode the .BOO file.  Terry is
still working on an adaptation of 2.26 for the 6/10; he says he's having
problems with the file system interface and server mode, possible due to the
6/10 using an 8086 instead of an 8088 (hints, anyone?).

The files are in KER:HL6*.*, available as usual via anonymous FTP from CU20B or
COLUMBIA-20.  All files in KER:, no binaries.

------------------------------
Date: Thu, 04 Oct 84 14:51:26 EDT
From: Edgar B. Butt <[e-mail]>
To: sy.fdc@cu20b
Subject: Oh no, another Kermit!

Here is a Kermit implementation for the Sperry 1100 systems written
in Pascal.  It has been run successfully here at the University of Maryland,
College Park, and at SUNY, Albany.  Please add it to your selection
of Kermits.  I would appreciate feedback from anyone who tries it.

The first page of code consists of comments explaining how to
use and generate Kermit1100.

Hope someone finds it useful,

Edgar Butt ([e-mail])
Computer Science Center
University of Maryland
College Park, Maryland 20742
[phone]

   KERMIT1100 is yet another Kermit written to run on the Sperry (Univac)
   1100 series of computers.  It is written in Pascal to be compiled on
   the NOSC Pascal Compiler, version 2.2 or later.  This compiler is
   available from the Computer Science Center of the University of
   Maryland, College Park, for a nominal service charge.

   Kermit aficianodos may notice that the structure of this version
   differs from other versions in that packets are read and sequence
   checked in the main program loop and are then dispatched to the
   proper input or output state with a single case statement.
   This structure has allowed the various state processes to be
   relatively uncluttered.  While doing this implementation I
   discovered that NAK's are like tadpole tails.  They seem like
   a neat idea at first, but as the frog emerges, they serve no
   useful purpose.  Likewise, I have been unable to find a case
   in which NAK's are necessary.  Sending an ACK for the last
   good packet received is just as good.  If I'm wrong, I am sure
   that some swamp dweller out there will let me know.
   (Not to worry, I handle incoming NAK's even though they are not
   necessary.)

   By way of a quick synopsys of features, this version of Kermit has:

      Simple server mode - processes S and R packets
      8-bit quoting (Turned on by Q-option)
      Repeat count prefixes
      Error packet generation and processing

[Ed. - It's in KER:UNIVAC.PAS on CU20B.]

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

Date: Mon 20 Aug 84 13:28:00-PDT
From: Bruce Tanner <[e-mail]>
Subject: CP/M-80 Kermit Tools
To: [e-mail]

I have new versions of HEXIFY and HEXCOM for both TOPS-10 and -20.

The -20 versions do long file names and wild-cards and all that good
stuff (I think - check them out and let me know).  HEXIFY also
now does zero compression. See 10HEXIFY.MAC 20HEXIFY.MAC 10HEXCOM.MAC
and 20HEXCOM.MAC.

LINK80 will now merge absolute .HEX files.  I'd like to try out the
new Kermit-80 and modify MAC80/LINK80 to do the right thing.

Also, I got tired of trying to figure out which INCLUDE file the MAC80
listing was showing, so I modified MAC80 to display the included file
name in the page heading.  MAC80 version 10F is in <CERRITOS>.

-Bruce

[Ed. - A complete new set of Bruce's 8080/Z80 cross development tools for
the DEC-10/20 is in KT: on CU20B, named as shown above.  KT:M*80*.* will
get all the MAC80 files.  KT:*HEX*.* will get the hexifier and dehexifier.
KT:*ORTUR.* will get the "torture" tests for MAC80.  CP/M users who have
access to a DEC-10 or DEC-20 should try these out -- they are fast!]

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

Date:  Thu, 4 Oct 84 18:36 EDT
From: Frank da Cruz <[e-mail]>
Subject:  MS-DOS Kermit Bootstrapping Problem
To: [e-mail]

I have received a number of calls from MS-DOS Kermit users who have been
attempting to bring up the new version by using a file capture utility (for
instance, the 3101 emulator you get with the IBM async communication package)
to get the new .BOO file and then convert to .EXE format with MSPCTRAN.BAS.

There is a potential problem with downloading a .BOO file using a non-protocol
(e.g. not Kermit, Modem7, etc) method.  The host may be sending padding or
screen formatting characters, the screen capture program may be doing things
behind your back, etc.  Unfortunately, the MSPCTRAN program is not very robust
in terms of screening out invalid characters; we'll have to fix it.  This mightinvolve a slight change in the .BOO file format.

- Frank

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

Date: Fri 5 Oct 84 12:43:20-EDT
From: Jeff Damens <[e-mail]>
Subject: MS-DOS Kermit Set Baud/Set Port
To: [e-mail]

The problem mentioned in the latest Kermit digest (setting baud, setting
port, having baud be undefined) is sort of a feature... the ports have
different baud rates, so that setting the baud rate only affects the
current port.  If you set the port first, it works fine.

                        Jeff

[Ed. - Sorry, I should have caught this.  Yes, we designed it this way on
purpose.  The SET BAUD and other comm-line related SET commands refer to the
currently selected port.  If you have two ports on your PC, for instance, your
MSKERMIT.INI file can set different parameters for each, e.g.

    set port 2
    set baud 1200
    set parity mark
    set port 1
    set baud 9600
    set parity none

This file sets up the two ports as shown, leaving your current port to be
COM1 at startup.  You can then switch back & forth simply by issuing SET
PORT commands, and the parameters for each port will be remembered.  This
is all documented in the manual.]

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

From: ukma![e-mail] (David Herron)
Date: Thu, 4 Oct 84 16:24:07 edt
Subject: Unix Kermit Suggestions
To: anlams![e-mail]

Frank,

I have some comments to make about a UNIX kermit.  I have had kermit for a
couple of years now and am happy with it as is (for the most part).  I would
like to see a server of course, and support of the newer (fancier) parts of the
protocol.  Other people here would like to have it be like the other kermits
(i.e. a command level and modes and such like).

On the other hand, I have a shell file that looks like this:


    #! /bin/csh
    kermit clb /dev/tty$1 300 <<!
    send $2
    ~.
    !
    kermit rlb /dev/tty$1 300

and is driven by another script like this:

    #! /bin/csh
    get ha file.1
    get ha file.2
    kermit clb /dev/ttyha 300 <<!
    ^C^C
    quit
    k/n
    !

I have been using this to transfer batches of files from a DEC-10
at the University of Louisville to here.  I would like to be able
to do this kind of thing.  Another thing that would be nice is to
use the server as a file server.  (I envision something like the
PCinterface program that AT&T has for the 3B series...They have
drive C be a serial (or ethernet) link to a process logged in on
a 3B, file accesses to drive C access files on the 3B.)  To do this
using kermit I would have to have the server as a seperate module.
(have the server be their login shell... much like uucp has uucico
as its' login shell).

What I propose is to have 3 seperate processes making up the UNIX
kermit.  One is a command interpretor which would be used in most
"normal" situations where one just wants to interact.  The other two
are the server and file transferer.  The command interpretor would call
the other two as necessary.  One question in my mind is "Is the
protocol to transfer one file self-contained enough to allow it to be
off in another process?"  I understand most of the protocol, but have
never used a server and have never had reason to understand what this
has done to the protocol.  The little bit I have looked at it says this
can be done......

Another way to implement this would be with conditional compilation
from one (group of) source...  (On little machines I see problems
with starting up a new process for each file transfered.)

Thank you,
David Herron

Arpa:    ukma!david@ANL-MCS
uucp:    ...{ucbvax,boulder,research,unmvax}!anlams!ukma!david
    ...decvax!ucbvax!anlams!ukma!david
Snail:    University Station
    PO Box 780
    Lexington, KY  40506
Phone:    [phone] (work, phone will usually be answered as "Vax Lab").

[Ed. - More good ideas for the "real" Unix Kermit...]

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

End of Info-Kermit Digest
*************************
-------
10-Oct-84 17:33:53-EDT,12124;000000000000
Mail-From: SY.FDC created at 10-Oct-84 17:29:40
Date: Wed 10 Oct 84 17:29:40-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #31
To: [e-mail]

Info-Kermit Digest         Wed, 10 Oct 1984       Volume 1 : Number 31

Today's Topics:
               Version 2.8 of CP/M-86 Kermit Available
                       New Apple II DOS Kermit
                   Apple-Cat Support in Kermit-65?
                           Macintosh Kermit
       Help Wanted Making MS-Kermit Work on the TI Professional
                            Venix Kermit?
                         Pro/Kermit and TMS?
                       Getting Connected vs EOL

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

Date: Wed 10 Oct 84 13:25:02-EDT
From: Frank da Cruz <[e-mail]>
Subject: Version 2.8 of CP/M-86 Kermit Available
To: [e-mail]

This is to announce version 2.8 of CP/M-86 Kermit for the DEC Rainbow and
the NEC APC.  Most of the work was done by Ron Blanford at the University
of Washington (CONTEXT@WASHINGTON).  The substantive changes are as follows:

The current defaults of drive and user number are now displayed in the
command line prompt, for example:

    Kermit-86 B3>

The SET DEFAULT-DISK option has been implemented to allow specification
of the default drive and user number for subsequent file reception and
transmission.  The specification following the command must be in one
of the following forms:

    d:    = go to drive d (A through P) without changing user
    u:    = go to user u (0 through 15) without changing drive
    du:    = go to drive d and user u
    :    = go to the defaults when Kermit was loaded

Whenever a drive is specified, even if it is the same as the current
default drive, the drive is logged in so that disks can be swapped
without exiting Kermit to type control-C.  Kermit restores the original
drive and user upon termination.

LOCAL commands added: DELETE, DIRECTORY, SPACE.  The DIRECTORY command
shows both the name and the size of each file.  The "LOCAL" prefix is
optional.

"RECEIVE filename" was changed to behave the way it's supposed to -- it
passively waits for a file to arrive, then stores it under the given name,
rather acting like "GET filename" as it did in previous versions.  If a
wildcard is given in the filename, it is used as a mask for incoming
filenames.

A couple fixes were made that apply only to the DEC Rainbow:

A BREAK now lasts exactly 250 milliseconds, as it's supposed to (from Bernie
Eiben at DEC).

The system no longer hangs when the printer is turned off or on or has its
hood lifted.  However, Print Screen and CTRL-Print Screen still don't cause
any printing to occur during CONNECT.  (Fix contributed by Paul Ford, U. of
Chicago Graduate School of Business.)

The files are available via anonymous FTP from CU20B as:

KER:86*.*        Source, documentation.

KER:APC*.*        Hex (.H86), and help files for the NEC APC.
KB:APCKERMIT.CMD    Binary, executable program for NEC APC.

KER:RB*.*        Hex, help for DEC Rainbow 100
KB:RBKERMIT.CMD        Binary executable program for Rainbow.

The documentation includes a revised help file and a new Kermit User Guide
chapter (not yet incorporated into the manual itself).

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

Date: Tue 9 Oct 84 21:39:46-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Apple II DOS Kermit
To: [e-mail]

A new version of Apple II DOS Kermit has been received from Olaf Pors,
University of Virginia.  This version is a hand translation of the Stevens
version, which is written in the DEC-10/20 CROSS language, to the
Apple 6502 Editor/Assembler, allowing the program to be assembled directly on
the Apple II.  This should prove enormously handy for those Apple II Kermit
users who don't happen to have a DEC-10 or DEC-20 handy.  In addition to the
translation, Olaf made the following changes (this is verbatim from his
documentation):

 Several bugs were fixed:

 1. Allow for noise characters which could cause the packet
    to be larger than the maximum expected size.  Previously,
    important cells would be overwritten.

 2. Incorrect file headers were being sent due to bad code
    at SFILE1E.

 3. 8-bit quoting was not working due to a problem at SPAKDC.
    The parity bit on characters received from the communications
    line was not being cleared before being added into the checksum.
    Also, apparently an N received in the 8-bit-quote character
    field of an ack-init was being misinterpreted as the
    actual 8-bit-quote character to be used.    Some work
    was done to attempt to get 8-bit quoting to work, but
    the work was not completed.

 4. The CONNECT command was not in the HELP display.

 Several changes were made for convenience :

 1. The SHOW command now only shows all parameters at once.

 2. The FILE-TYPE keyword was changed to FILE-MODE.

 3. ASCII was made a synonym for TEXT.

 4. The screen was not cleared for every packet transmission.

 5. The communication line access primitive routines were
    changed to work with a CCS 7710A or SSM AIO board, and
    were moved to the start of the object file with some extra
    space, in order to allow the machine code to be changed
    by hand for other serial cards, rather than having to
    reassemble all the source.

The program comes in two files, one for reading, the other for assembling.
The reading file contains comments, punctuation, etc; the assembling file
has all these stripped out, resulting in a much smaller file.  The reading file
is in KER:AP2KER.TXT, the assembling file is in KER:AP2KER.ASM.  Since this
program closely parallels the Stevens version, it is hoped that something
can be done about reconciling their differences.  On the one hand, it's nice
to be able to assemble it quickly on the -10 or the -20, but on the other it
may be nicer to have it portable (especially since it looks like the Apple II
line will outlive the DEC-10/20 line).

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

Date: Wed 10 Oct 84 07:16:26-EDT
From: Anton Mione <[e-mail]>
Subject: Re: New Apple II DOS Kermit
To: [e-mail]

    First chance I get, I will check into the bug fixes and changes,
however, it seems that #2, #3, and possibly #4 have already been fixed.
Also, several of the 'convenience' items have already been corrected or
changed. I will also see if there is a way to maintain both versions
conveniently.

Anton::

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

Date: 10 Oct 84 13:10:28 EDT
From: Bdale Garbee <AG0B@CMU-CC-TE>
To: oc.trei@CU20B, oc.mione@CU20B, sy.fdc@CU20B
Subject: Apple-Cat support in Kermit-65?

Hi -- has anyone added support to Kermit-65 (Apple) for the Novation
Apple-Cat internal modem?  I've had several requests, and might add the
code myself if noone else has already.

Another request... this one more urgent.  How about a new option for 'set'
to specify whether to force upper case display of incoming text?  The problem
stems from many owners of Apple-2+ machines wanting to use the 2+ option so
they get the keyboard translation, but who own lower-case chips and want
real lower case.  I've solved the problem so far by separately assembling
a version with the upper-casification stuff commented out.  But that's a
drag....

Bdale
CMU Software

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

Date: Tue, 9 Oct 84 15:57:19 edt
From: [e-mail] (Stephen Engel)
To: [e-mail]
Subject: Macintosh Kermit

Hello,
    Yes I'm still around, although suffering from the blitz of classes
starting.  I should be able to mail you a new version early next week,
which if it doesn't fix the old one's problems will at least have the
debugging capabilities to track them down further.  Thank you for your
patience.

Steve

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

Date: 9 Oct 1984 2158-EDT
From: Frank da Cruz <[e-mail]>
To: Info-Kermit@CU20B
Subject: Help Wanted Making MS-Kermit Work on the TI Professional

[Passed along from the Colorado School of Mines; if anyone can help with
this, please call Joe directly -- he's not on any net.]

The generic MSKERMIT does not work on a Texas Instruments Professional
PC because MS-DOS version 2.11 will not allow you to receive characters
via COM1:.

We tried configuring the Sync/Async Comm Card using:
    A>CONFIG COM1=P1,DATA=8,PARITY=NONE,SPEED=1200,BUSY=NONE
and that allowed us to transmit characters out COM1: or AUX:, but a bug
in TI's BIOS does not allow characters to be received.

I am working on the machine-dependent code for MSXTIPRO.ASM, but I'm having
problems getting information.  The Technical Reference Manual says that TI
uses a Zilog 8530 chip, gives the port addresses, and some of the bit
definitions, but does not describe all the bits in all the registers.  I
have been unable to locate a Z-8530 spec sheet, if anyone could tell me how
to program the durn thing I would be grateful.

Joe Smith, CSM Computing Center, Golden, CO 80401  [phone].

[Ed. - This plea also sent to Info-IBMPC.]

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

Date: Tue 9 Oct 84 21:19:20-PDT
From: mark thompson <[e-mail]>
Subject: Venix Kermit?
To: [e-mail]

Supposedly, there is a variant of the unix kermit for PRO/Venix. The
source mentions a 'uxkercnv.c' file. We don't have it, but would
very much like to. Do you know where this file is, or what has to
be changed to get the thing to run on the besotted pro?

-mark

[Ed. - Sorry for the oversight.  The file is now in the Kermit distribution
area on CU20B as KER:UXKERCNV.C.  It speeds things up by adding a separate
fork for displaying incoming characters on the screen.  But it's still
pretty slow because of the way serial i/o is implemented in Pro/Venix.]

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

Date: Wed 10 Oct 84 12:17:31-EDT
From: SCHUBOT@CWRU20
Subject: Pro/Kermit and TMS?
To: SY.FDC@CU20B

Has anyone figured out how to use PRO/KERMIT with the TMS modem on PRO 350s?

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

Date: Wed 10 Oct 84 14:24:30-EDT
From: Frank da Cruz <[e-mail]>
Subject: Getting Connected vs EOL
To: [e-mail]

We've been fooling with Unix Kermit under 4.2 BSD and have found that we can
speed it up dramatically by doing packet i/o in "cooked mode" rather than
"raw mode" because the latter wakes up on every character, whereas the former
reads everything up to a linefeed  --  Kermit packets contain only printable
characters plus ^A, all of which get through a "cooked" line unmolested.
(By the way, this is not a recommendation that everyone change their Unix
Kermits -- this trick probably only works for ASCII files, but not 8-bit binary
files.)

However, since most Kermits use carriage return and not linefeed as their
default packet termination character, one must be careful to SET END-OF-LINE 10
(or whatever the syntax of your particular Kermit is), or else Unix Kermit will
not receive a linefeed and will therefore never come back from the read.  Since
we're always forgetting to issue the appropriate SET command, we're always
getting stuck.

So...  Here's something that should be added to every Kermit:  When sending an
S or an I packet, i.e. packet 0, the initial packet in a "transaction",
terminate that packet with a carriage return AND a linefeed (and maybe also an
XON for good measure).  The other side is much more likely to read it that way.
Once the other side has read it, it will be able to tell you in its reply the
termination character it really wants, and since it has already read your S or
I packet, it knows the one you want; everything should work automatically from
that point on.  Note that one can insert any characters at all -- except ^A --
between packets with impunity, so this trick should never do any harm.

- Frank (and Bill C)

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

End of Info-Kermit Digest
*************************
-------
15-Oct-84 17:44:29-EDT,24941;000000000000
Mail-From: SY.FDC created at 15-Oct-84 17:43:55
Date: Mon 15 Oct 84 17:43:55-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit-Digest V1 #32
To: [e-mail]

Info-Kermit Digest         Mon, 15 Oct 1984       Volume 1 : Number 32

Today's Topics:

          Kermit for Harris 800 Systems from U of Wisconsin
           New RT-11 and VAX/VMS Kermits from U of Toronto
                      CP/M-86 Kermit v2.8 Review
                   Unix Kermit, Cooked vs Raw Mode
                        Building MS-DOS Kermit
              MS-DOS Kermit in Multi-Tasking Environment
                   Changing CP/M-80 Kermit Defaults
               Improvements for CP/M-80 Heath-89 Kermit
                   Use of IOBYTE in CP/M-80 Kermit
                     Displaywriter Kermit Sought
       RFC 916, Reliable Asynchronous Transfer Protocol (RATP)

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

Date: Thu 11 Oct 84 18:26:11-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit for Harris 800 Systems from U of Wisconsin
To: [e-mail]

Harris 800 Kermit is an adaptation of the University of Toronto's RT-11 Pascal
Kermit, with machine dependent subroutines written in assembler.  It was
converted by David Wilson at the Academic Computing Center of the University of
Wisconsin - Madison (MACC).  There are 3 files:

H800KER.PAS - Pascal Source
H800KER.ASM - Assembler Support Routines
H800KER.JCL - Installation JCL

Submitted by Paul Stevens, MACC (STEVENS%MACCWISC.MAILNET@MIT-MULTICS).  The
files are available via anonymous FTP from CU20B.

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

Date: Thu 11 Oct 84 12:46:53-EDT
From: Frank da Cruz <[e-mail]>
Subject: New RT-11 and VAX/VMS Kermits from U of Toronto
To: [e-mail]

This is to announce new releases of the Pascal-based Kermits from the Bruce
Pinn and Philip Murton at the University of Toronto for RT-11 and VAX/VMS.

RT-11 Kermit is up to version 2.2C, and includes only minor changes in
messages and displays.  The previous version was 2.2.  The program is written
on OMSI Pascal 2.1 with Macro-11 subroutines.

The new VMS Kermit is version 1.1E; it fixes a serious bug in packet data
prefixing, and also adds some features.  While the bulk of the program is in
VMS Pascal, some modules are also in VMS Fortran.

Since these versions are "redundant", they have been placed in <KERMIT-EXTRA>
rather than the main Kermit area.  The more popular RT-11 version is Brian
Nelson's Macro-11 implementation (which also can be built for RSX, RSTS, P/OS),
and the more popular VAX/VMS Kermit is the Bliss/Macro version from Stevens
institute of technology.

The new Toronto files are in KE:RT*.* (RT-11) and KE:VX*.* (VMS), available via
anonymous FTP from host CU20B.  Hex files are included, so that you don't need
to have Fortran or Pascal in order to run these programs.

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

Date: Wed 10 Oct 84 14:10:31-PDT
From: Ronald Blanford <[e-mail]>
Subject: CP/M-86 Kermit v2.8 Review
To: [e-mail]

I've found a couple of minor bugs in the directory function.  Files which
contain no data are listed with length 0K, but even these files have a
data block allocated so the correct figure should be the size of one block.
Files which are larger than 512K are listed with length 512K.

I've got a fix for the first one, and I'm still working on the second.
I think these fixes can wait for version 2.9.

Kermit-86 works acceptably under Concurrent CP/M-86 on the APC with three
exceptions:

    1. A KERMIT.INI file must be present, even if empty. Concurrent
       CP/M-86 aborts the program if it tries to close a nonexistent
       file.
    2. The set default-disk command causes subsequent directory and
       file access to be brain-damaged.  I'm not sure why this is.
    3. The serial port is accessed directly, bypassing the operating
       system locks against concurrent use.  If another partition is
       using it as console 4 or as a serial printer there will most
       likely be garbage as a result.

And one other problem:

    4. Other partitions slow to a crawl when Kermit is in use, since
       Kermit loops checking the serial port status for input and
       uses up its full time slice each time it gets the processor.

-- Ron

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

Date: 11 Oct 1984 00:16:29-PDT
From: [e-mail]
To: [e-mail]
Subject: Unix Kermit, cooked vs raw mode

Using cooked mode for packet input for ASCII files seems like a fairly good
idea, but there is an error in your statement.  You CAN use carriage-return as
your end-of-line character.  All you have to do is turn on the terminal's
CRMOD bit, and a carriage-return looks just like a line-feed.  From stty, this
would look like 'stty -nl'.  Most people have this bit set anyway, because
typing <return> is more "natural" than typing <linefeed>.

                    Carl Fongheiser
                    [e-mail]

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

Date: Thu, 11 Oct 84 11:44:54 pdt
From: Ken Poulton <@csnet-relay.arpa,@hplabs.CSNET:[e-mail]>
To: #[e-mail],
Subject: 4.2 kermit and cooked mode

There is a way to make the Unix kermit smarter about end-of-line:

Set the CRMOD bit in sgttyb.sg_flags on 4.2BSD (and V7, I think).
(Set ICRNL in termio.c_iflag for Syetem III and V.)
This has the effect of making Unix respond to CR in the same way as NL.
Clearly, this is easier than modifiying every other kermit.

(Another way: Set the "alternate end-of-line" char to CR.  (See tchars.t_brkc
for 4.2 (and 4.1, and V7, I think) and termio.c_cc[EOL] for System III and V.))

Also, as long as the control-character quoting is happening,
it seems like cooked mode should work just fine, even for binaries.
The large gain in speed might argue for at least using cooked mode
for ascii transfers (i.e., non-"image" mode).

I hope that you are putting the terminal mode munging code
in separate routines and adding ifdef's for System III-derived verions.
The terminal i/o handling is completely different under System III,
and some of the compatibility libraries went away under System V.
You might just take my version's setraw and unsetraw routines.

[Ed. - The real question in this cooked-vs-rawmode discussion is whether the
"parity" bit makes it through intact in cooked mode, in each of the various
Unix implementations.  If not, then the overhead introduced by "8th-bit-
prefixing" for 8-bit binary files would tend to offset the advantage of
eliminating single-character wakeups (assuming Unix Kermit could do 8th-bit-
prefixing, which it can't yet).  Any comments?]

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

Date: Thu 11 Oct 84 18:19:10-EDT
From: Jeff Damens <[e-mail]>
Subject: Building MS-DOS Kermit
To: [e-mail]

    It looks like some combination of the new MASM and the new
LINK make segments load in a different order than the older versions.
The effect is that any command that has to fork something up (e.g.
directory, push, run) doesn't work, and usually hangs the machine.
This is because kermit tries to release some memory before forking
anything up... if the stack isn't the last segment in memory, as
kermit thinks it is, it ends up deallocating something crucial, like
the code segment.

This only happens to people who build their own versions, since the
binaries I made are ok.  However, it seems like a number of people are
having problems with the .BOO files and are building their own
binaries, so...

The solution is to load MSXDMB as the first object file.  This is just
a dummy module that specifies the order of the segments.

                            Jeff

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

Date: 12 Oct 84 14:38:16 EDT
From: Michael D. Gillinov <MG1F@CMU-CC-TC>
To: info-kermit@CU20B
Reply-to: MG1F@CMU-CC-TC
Subject: Kermit in multi-tasking environment

I appreciate the significant benefits of by-passing DOS for video output,
but as a result Kermit v2.26 has become a program which can only run in the
foreground in Topview.  This result imposes unfriendly restrictions on use
of the program in Topview and probably in most other multi-tasking
environments for the PC.

Will you be supporting a more "well-behaved" version which uses standard DOS
calls for this i/o?

Keep up the good work!

Michael.

[Ed. - This is a tough one.  We have to access the screen memory to get
acceptable performance out of functions like insert/delete character.  I
believe the previous version, 1.20, is "well behaved" in this respect, and
we'll keep it around indefinitely for reasons such as this.  Also, you
should be able to run 2.26 with some other terminal driver -- for instance
ANSI.SYS, assuming it does everything through DOS -- without interfering
with your windows.]

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

Date: 17 September 1984, 10:43:57 CDT
From: U09279 at UICVM (Neil W. Rickert /312/996-3055)
To:   DFTCU at CUVMB, DAPHNE at CU20B
Subject:  Changing CP/M-80 Kermit Defaults

The following is a suggested addition to the KERMIT-80 documentation.

I am using the Heath H89 version.  The following suggestion works with this
version, and presumably works just as well with other versions.

                     Changing defaults for Kermit:

Any of the options of KERMIT which may be changed with the SET command can
also have the default setting changed.  For example, the default parity is
NONE.  You can change it so that the default parity, when KERMIT is first
loaded, is, say, EVEN.

Here is a simple way of making this change:

First use the STAT command, to find out how large KERMIT is.  For example,
in my version KERMIT is 101 blocks, and 13K in length.  We take the number
of records (101), halve it, and round it up to the next integer.  In my case
that gives 51.  Remember this value.  You will need it for the SAVE command.

Now go into KERMIT.
Use the SET command to set the options you desire.
Use the EXIT command to return to CP/M.
Use the SAVE command  ("SAVE nn KERMIT.COM") to save the modified KERMIT.

For example, to set the default parity to EVEN, I would do the following:

     A>kermit
     Kermit-80 A:>set parity even
     Kermit-80 A:>exit
     A>save 51 kermit.com

Of course it is a good idea to keep a backup copy of the unmodified KERMIT on
another disk, just in case of problems.  I believe you can preset all options
except the default disk, using this method.

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

Date: Mon 15 Oct 84 18:26:11-EDT
From: Frank da Cruz <[e-mail]>
Subject: Improvements for CP/M-80 Heath-89 Kermit
To: [e-mail]

Neil Rickert, who sent the above message, also sent code to be added to CP/M-80
Kermit 3.9A to allow the Heath 89 to send a BREAK signal and to control modem
signals like DTR and RTS, for instance for hanging up a Hayes modem.  The
messages containing this code are in KER:CPMHEATH.BWR.

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

From: Joe Smith, Colorado School of Mines Computing Center
Address: Golden CO 80401, [phone]
To: CHARLES@ACC
Subject: Use of IOBYTE in CP/M-80 Kermit

PROBLEM: KERMIT-80 does not work on a North-Star Horizon if the modem is
     plugged into socket #2 or #4.

DIAGNOSIS: KERMIT-80 assumes that the BIOS implements the IOBYTE the way
    that Digital Research suggests:  1) CON=BAT console input comes
    from the RDR and console output goes to LST, and 2) doing a punch
    output to TTY is the same as doing a console output to the TTY or
    doing a list output to the TTY.

CURE:    Make all 4 fields of IOBYTE independent, with useful synonyms.

Generic KERMIT-80 currently allows for 6 of the 8 possible modem ports, TTY,
CRT, UC1, PTR, UR1, and UR2.  However, there are 2 cases it does not handle:

  1) System has 4 consoles.  CON=BAT goes to CON2, therefore BDOS cannot
     check if a character is available at any of the RDR ports but can check
     if a character is available at CON2.

  2) System has 3 console ports and 16 modem ports.  CON=BAT does test for
     input available on the currently selected modem port, but the RDR and
     PUN fields of the IOBYTE are not independent.  Together they select one
     of 16 different bi-directional serial ports.  Setting RDR=TTY and PUN=TTY
     does not do I/O to the same port as setting CON=TTY.

To be completely flexible, KERMIT-80 should accept all 20 of the "SET PORT"
arguments listed below, and all 5 "SET PRINTER" arguments.  In this way, the
command "SET PORT UR1" does NOT imply "SET PORT UP1" (but "SET PORT AUX2"
does).

      SET PORT    Read    Write    IOBYTE
    -----------    ----    ----    --------
    TTY or CON0    CON:    CON:    xxxxxx00
    CRT or CON1    CON:    CON:    xxxxxx01
    BAT or CON2    CON:    CON:    xxxxxx10 (serial card in slot #2)
    UC1 or CON3    CON:    CON:    xxxxxx11
       CON        CON:    CON:    xxxxxxXX (value remembered at startup)

    TTR or PTR0    RDR:    PUN:    xxxx00xx (different from CON0 mode)
    RDR or PTR1    RDR:    PUN:    xxxx01xx
    UR1 or PTR2    RDR:    PUN:    xxxx10xx
    UR2 or PTR3    RDR:    PUN:    xxxx11xx
       PTR        RDR:    PUN:    xxxxXXxx (value remembered at startup)

    TTP or PTP0    RDR:    PUN:    xx00xxxx (different from CON0 mode)
    PUN or PTP1    RDR:    PUN:    xx01xxxx
    UP1 or PTP2    RDR:    PUN:    xx10xxxx
    UP2 or PTP3    RDR:    PUN:    xx11xxxx
       PTP        RDR:    PUN:    xxXXxxxx (value remembered at startup)

      AUX0        RDR:    PUN:    xx0000xx (TTR+TTP, different from TTY)
      AUX1        RDR:    PUN:    xx0101xx (RDR+PUN)
      AUX2        RDR:    PUN:    xx1010xx (UR1+UP1)
      AUX3        RDR:    PUN:    xx1111xx (UR2+UP2)
       AUX        RDR:    PUN:    xxXXXXxx (value remembered at startup)


    SET PRINTER    Read    Write    IOBYTE
    -----------    -----    -----    --------
    TTY or LST0    can't    LST:    00xxxxxx (LST=TTY not same as CON=TTY)
    CRT or LST1    can't    LST:    01xxxxxx (LST=CRT not same as CON=CRT)
    LPT or LST2    can't    LST:    10xxxxxx
    UL1 or LST3    can't    LST:    11xxxxxx
       LST        can't    LST:    XXxxxxxx (value remembered at startup)

[Ed. - Poor Charles Carvalho, who is working on the "modularized" release 4 of
Kermit-80, has been getting a lot of suggestions like this, plus the new code
for the Heath i/o mentioned above, plus the new support for the Compupro, etc.
I'm not sure how much of this he can assimilate before he gives up.  Therefore,
all such information is provided to Info-Kermit with no assurrance that it will
appear in the new release of Kermit-80.  Let's wait and see.  If not, then
perhaps someone else will do it.]

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

Date: 14 Oct 1984 22:31-EDT
Subject: Displaywriter Kermit Sought
From: [e-mail]
To: [e-mail]

We are looking for an implimentation of KERMIT for the IBM Displaywriter
or for anyone who is doing work in the area of porting KERMIT to the
Displaywriter.  Any information will be appreciated.  If someone is
now working on a version and needs help we would be glad to assist in
any way that we can.

Thanks in advance

Gene Cartier
ARPA: [e-mail]
BELL: [phone]
USPS: POLARIS INC.,1400 Wilson Blvd, Suite 1100,Arlington VA, 22209

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

Date: Mon 15 Oct 84 14:01:11-EDT
From: Frank da Cruz <[e-mail]>
Subject: RFC 916, Reliable Asynchronous Transfer Protocol (RATP)
To: [e-mail]
cc: [e-mail], [e-mail]

[Ed. - The remaining messages in this issue are about some fine points of
Kermit and other asynchronous protocols, and may be skipped with no ill
effects...]

RFC 916 includes an appendix which compares the proposed protocol (RATP) to
several existing protocols, including DDCMP, MODEM, and KERMIT.  As the RFC
points out, DDCMP is "too complex for consideration" as an asynchronous
protocol.  On the other hand, MODEM and KERMIT are "toy protocols", not
designed to provide an error-free transport layer for a network based on
asynchronous telecommunications, but rather as simple standalone programs
intended to provide file transfer and management over that medium.

Several valid criticisms are raised about Kermit, but there are also some
misconceptions:

      KERMIT combines both the reliable transfer and file transfer into
      a single package.  Extension to other applications and higher
      level protocols would be possible but the boundary between the
      reliable transfer and application layers is very indistinct.  It
      violates the layering design strategy the Internet employs.

This is true.  Packet control fields and state tables are pretty much hardwired
to reflect file transfer and management functions, although it is possible to
fit other functions into this paradigm.  For instance, a user Kermit process
can ask a Kermit server to send a list of who's logged in ("finger"), and will
receive the listing back as though it were a file, but for display on the
screen rather than storage on the disk.

      There is a limitation of transmission to the restricted printable
      ASCII set for certain computers but not for others.  This leads to
      confusion.  KERMIT allows both restricted ASCII and 8-bit
      transmission.

Not exactly right.  The entire 7-bit ASCII set is supported by all Kermit
implementations, and unprintable characters (ASCII 0-31 and 127) are
translated to prefixed printables to ensure that they get through (for
instance Control-B becomes "#B").  This is because KERMIT is designed to work
under the most unfavorable conditions, for instance those in which one end
of the connection is a timesharing job's controlling terminal, sensitive to
a certain set of control characters.

8-bit transmission is possible in two cases:

1. The data path is 8 bits wide, i.e. there is no entity upon it which is doing
   parity or otherwise interfering with the "8th" bit.

2. The data path is 7 bits wide and both Kermits have implemented the optional
   "8th-bit-prefixing" method.  In the initial connection dialogue, the two
   Kermits will automatically decide whether they have to resort to this
   method, which adds overhead, and will do so only by mutual consent.

The 8th-bit-prefixing method is "enabled" when either Kermit "knows" that
parity is being done on the communication line.  This knowledge is either
hardwired (as in IBM mainframe or PR1ME Kermits), or else it is set manually by
the user (for instance when both systems are capable of 8-bit i/o, but they are
communicating through a 7-bit channel like TELENET).  The ability to
automatically make this determination, as RATP does, is currently lacking.
Incidentally, the 8th-bit prefixing method tends to be somewhat more efficient
than RATP's 8-for-4 encoding; if the 8th bit is on randomly, Kermit will only
double 50% of all characters, whereas RATP will double 100%.

      The KERMIT protocol does not appear to make provision for both
      sides of a connection attempting an active open simultaneously.
      One side must be an initial "sending Kermit" and the other a
      "receiving Kermit".  The code published as a KERMIT implementation
      guide cannot recover from simultaneous active opens, it
      immediately ABORTs.  This reflects a bias towards unidirectional
      data flow.

True.  Kermit is designed for use over user-initiated connections.  It is
assumed that a human is sitting at one end, who starts the Kermit processes on
each end.  Kermit is only intended for use over a single physical channel, and
provides a single logical channel.  It is also true that transactions are
unidirectional.

      The KERMIT packet type (similar to RATP control flags) specifies
      whether an ACK/NAK is contained in the packet, or data, etc.
      These are mutually exclusive and piggybacking an ACK on a data
      packet is not possible.  This can be a source of overhead.  In
      addition KERMIT restricts the sender to a single outstanding
      unacknowledged packet as does RATP.  It allocates an entire byte
      to the sequence number which is unnecessary.

True.  The full-byte packet number is there to allow the protocol to be
expanded to accommodate multiple outstanding packets.  This extension has not
been made yet.

      On the subject of error recovery, the size of a packet is
      contained in the second byte of the packet and is not protected by
      a header checksum.  If the length field was in error due to noise
      on the link, it could be longer than the correct packet size.  The
      code published as the KERMIT implementation guide relies upon the
      detection of the <SOH> character anywhere in a packet to indicate
      the beginning of a packet header.  It re-SYNCHs using this
      technique.  This is only possible if binary data in a packet is
      quoted.  If full eight bit data is transmitted it does not appear
      that the KERMIT protocol rescans for a new MARK (SYNCH) character
      within the bad packet data just consumed.  It will under these
      circumstances throw away the retransmitted packet or portions
      thereof.  Re-SYNCHing under such conditions is problematical.

Mostly true.  The header checksum is good idea, and if we had it to do over
again this might be one of the things we'd change (another would be a field to
specify what kind of block check is used for the data, so that checking
techniques could vary dynamically over a transaction with the condition of the
line).  However, it should be pointed out that the SYNCH character is a "real"
ASCII Control-A ("8th" bit ignored).  Any Control-A's that appear in the data
are represented as "#A" and will never cause re-SYNCHing.  If a length field is
corrupted upwards, then presumably one side or the other will time out and
resynchronization should occur within the next packet time.

Also, one comment about the MODEM protocol: since it does not bother to encode
data printably, it tends to be simpler and more efficient than Kermit.  But as
a consequence, it can't operate at all over 7-bit channels -- even if only
7-bit ASCII data is being transmitted, the checksum (or CRC) and the block
number involve all 8 bits of an octet.  Thus operation over TELENET or with IBM
mainframes is not possible.

Finally, you can add the following references to Kermit to your bibliography,
if you like:

  da Cruz, F., "KERMIT Protocol Manual", Columbia University Center for
  Computing Activities, April 1984.

  da Cruz, F., and Catchings, B., "Kermit: A File Transfer Protocol for
  Universities", BYTE Magazine, June and July, 1984.

P.S. Don't blame us for the title of the BYTE article; the editors changed our
title at the last minute without consulting us, to make it fit with the
educational theme of the June issue.  The original title was "KERMIT: A Simple
File Transfer Protocol for Microcomputers and Mainframes".

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

From: "Frank J. Wancho" <WANCHO@SIMTEL20>
To:   Frank da Cruz <SY.FDC%CU20B@COLUMBIA>
Cc:   Finn@USC-ISIF, INFO-KERMIT@CU20B, INFO-MICRO@BRL
Subject: Comments on MODEM

    Also, one comment about the MODEM protocol: since it does not
    bother to encode data printably, it tends to be simpler and more
    efficient than Kermit.  But as a consequence, it can't operate at
    all over 7-bit channels -- even if only 7-bit ASCII data is being
    transmitted, the checksum (or CRC) and the block number involve
    all 8 bits of an octet.  Thus operation over TELENET or with IBM
    mainframes is not possible.

Not universally known or published, but several clever independent
implementations of MODEM have a "7-bit" mode to transfer ASCII data.
Thus, that is not a real limitation.  The problem with MODEM is that
it is not currently possible to anticipate when the single-character
EOT is to be received amongst the 132/133-character packets.  This
make it difficult, if not impossible, to implement on machines which
have no capability to timeout a READ.

MODEM, of course, has many other "problems", but it is pragmatic, even
though it may not be elegant.

What is unfortunate about the analysis of the "other" protocols at the
end of RFC916 is that it dismisses the file transfer aspects.  The
analysis of MODEM is based on an ancient document, and that document
does not even begin to cover the many enhancements made over the last
two years in what has known to be the MODEM7/MDM7xx extensions for
batch mode and considerably improved reliability with the timeout and
error recovery mechanisms.

Now, let's move this discussion over to PROTOCOLS@RUTGERS.

--Frank

[Ed. - Good idea, and thanks for the clarification about MODEM.]

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

End of Info-Kermit Digest
*************************
-------
18-Oct-84 18:55:38-EDT,10534;000000000000
Mail-From: SY.FDC created at 18-Oct-84 18:54:45
Date: Thu 18 Oct 84 18:54:45-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #33
To: [e-mail]

Info-Kermit Digest         Thu, 18 Oct 1984       Volume 1 : Number 33

Today's Topics:
                  Kermit for the Cray-1 and Cray-XMP
                   New release of Macintosh Kermit
                  Cooked vs Raw Mode in Unix Kermit
              MS-DOS Kermit in Multi-Tasking Environment
              Additional Heuristics for Kermit Protocol
                           Kermit on Tenex?
                   Use of IOBYTE in CP/M-80 Kermit
                        Making TSO Kermit Work

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

Date: 18 Oct 1984 10:40:18-MDT
From: Leah F. Miller C-10 <lfm@lanl>
To: sy.fdc@CU20B
Subject: Kermit for the Cray-1 and Cray-XMP

Kermit-CR  -  LANL Cray Kermit

Kermit-CR is an implementation of the Kermit protocol on the Cray-1 and Cray
X-MP computers.  It is written in CFT, the Cray version of Fortran-77, and runs
under the Cray Time-Sharing System (CTSS) operating system.  Kermit-CR is an
advanced Kermit, including all required features plus server mode, timeout
capability, data compression, and 8th bit quoting.

Author :  Leah Miller,
          Computer User Services Group (C-10)
          Los Alamos National Laboratory
          Los Alamos, New Mexico  87545

          Arpanet address :  lfm@lanl

[Ed. - Cray Kermit is available on host CU20B via anonymous FTP in the files
KER:CRAY.*.  CRAY.CFT is the Fortran source, CRAY.DOC is the documentation.
The Fortran source consists of 7 files concatenated together in alphabectical
order; each file begins with a line of the form

!-name-!

where "name" is the name to be used for that file in the Cray file system.
These names are:

   cr.filing
   cr.kermain
   cr.kfutil
   cr.kutcmds
   cr.pktio
   cr.receive
   cr.send
   cr.stdutils

All operating-system dependent code is encapsulated in the modules cr.kfutil
and cr.pktio.]

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

Date: Mon, 15 Oct 84 21:39:08 edt
From: [e-mail] (Stephen Engel)
To: [e-mail]
Subject: New release of Macintosh Kermit

Here is the new version of mackermit.  It differs from the old version
in the following ways:

    1) It has debug option which displays the contents
       of each packet until a key is pressed.

    2) It remembers terminal settings.

    3) Pressing a key during transfer causes Mackermit to
       resend the last packet (useful if the packet length
       is distorted during transmission).

Again, I apologize for taking so long on this, and please let me know
how Mackermit is or is not working.

Steve

[Ed. - The new version is in KER:MC1KERMIT.SH, in Unix shell archive format,
accessible via anonymous FTP from CU20B (Internet host [192.5.43.128] for those
who still don't have CU20B in their host tables).  There's no hex file this
time.]

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

Date: Mon, 15 Oct 84 18:58:11 pdt
From: Ken Poulton <@csnet-relay.arpa,@hplabs.CSNET:[e-mail]>
To: #[e-mail],
Subject: cooked vs raw mode in Unix kermit

The answer (from tty(4)) seems to be that 4.x BSD (and V7, I guess) systems
cannot get all 8 bits without raw mode.  System III (and V) can get all 8 bits
in cooked mode.

Given the large performance gains possible for text files, it would seem to
make sense to have System III always use cooked mode, and V7 and 4.x BSD use
raw mode only when in 'image' transfer mode.  This shouldn't be too hard to
implement, since these two major branches of Unix need separate
tty-mode-setting code anyway.  To really gain from this, though, the read and
write calls should be replaced by buffered i/o, probably stdio.

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

Date:  Tue, 16 Oct 84 18:39 EDT
From:  [e-mail]
Subject:  Re: MS-DOS Kermit in Multi-Tasking Environment
To:  [e-mail]

It is realitively easy to modify an MS-DOS program to work in a multitasking
environment.  All one needs do is a sequence like the following:

     mov  es,display_segment
     mov  di,0
     mov  ah,0feh             ; get video buffer
     int  10h
     mov  display_segment,es
     mov  video_base,di       ; instead of assuming 0

If the result is not 0b800h, then you do not need to do retrace synching.  Note
that when not running under Topview the registers are unchanged and thus
returns 0b800:0 (of 0b000:0).

One other change is necessary, one must post changes to the screen.  This can
be done when one cares about the result (such as when reading the keyboard).
In worst case, one posts the whole screen.  The post call is

     INT 10H, AH = 0FFH

     ES:DI points to the start of modified area in video buffer
     CX    is the count

One can just repost the whole screen on any change.  Or simply
note the lowest and highest byte numbers modified and post the
region.  Anything other (like multiple regions) is probably not
worth it.

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

Date: Wed 17 Oct 84 03:05:39-PDT
From: Bob Larson <[e-mail]>
Subject: Additional Heuristics for Kermit Protocol
To: [e-mail]

Here are some suggestions that would improve kermit under noisy conditions:

1. Any control character received in a packet terminates that packet.
If the terminating character is the start-of-packet character, the original
packet should be discarded without a nak and the new packet should be received.
Otherwise, the expected packet should be naked.  This helps detect corrupted
packets, and avoids timeouts when characters in the middle of a packet are
dropped and the packet is terminated by a control character.  (i.e. return)

[Ed. - Good idea, but not necessarily recommended, because the Kermit protocol
actually allows bare control characters (other than SOH and EOL, whatever they
are defined to be) in the data packets.  While no version of Kermit I know of
will actually send bare control characters in data packets on purpose, most
Kermits upon receiving them will store them as is.  It may be worth reserving
the ability to send a negotiated set of control characters bare in order to
improve performance.]

2. On noisy lines, the terminator character should be sent twice in case one
gets dropped or corrupted.  Determining what is a noisy line is another
problem....

[Ed. - Another good idea.  A line could be deemed noisy if the number of
retries (timeouts or bad checksums) exceeded a certain threshhold for a certain
number of consecutive packets.  Under those conditions, you might also want to
decrease the packet length to reduce the probability of a noise hit and the
retransmission overhead when one occurs.  On the other hand, the overhead of
keeping all that history around and making such decisions on a per-packet basis
might offset any advantage gained.]

3. A nak should be sent as early as possible.  If the packet being received
is not the expected one, or the length exceeds the requested maximum, the
nak may be sent as soon as the header is received.  Does this require
negotiation to see if the other side is so dumb it can't talk and listen at
the same time?

[Ed. - This could work for full duplex systems.  Again, added hair for deciding
whether or not to do it based on whether communication is full or half duplex.]

What should the sending side do when it receives a nak while still sending?
My choice is flush the output buffer and any outstanding output, and resend
the naked packet.  Hopefully the other side has implemented (1) above,
and the nak was not due to a timeout.

[Ed. - All the Kermits I know of are deaf to input while they are sending, and
rely on the system, or their own interrupt handlers, to buffer arriving data.
Kermit was originally designed to work uniformly on half and full duplex
systems, which means it's really a half duplex protocol.]

Bob Larson <Blarson@Usc-ecl>

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

Date: Sunday, 14 October 1984  15:59-MDT
From: Rem%IMSSS@SU-SCORE
To: PROTOCOLS%RUTGERS@SCORE
Subject: Kermit on Tenex?

We have source for Kermit on IBM-PC and Tops-20, but we need Kermit on
Tenex and the Tops-20 version doesn't assemble on Tenex because it
needs a macro package that doesn't exist on our Tenex.  Does anybody
have a Tenex version of Kermit or know how to fit the Tops-20 version
onto Tenex? (We have a direct RS-232 link between Tenex and the room
where the IBM-PC is located, and the IBM-PC has an RS-232 interface,
so we think the hardware problem has been solved, leaving only the
software problem.)

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

Date: 15 Oct 1984  18:10 MDT (Mon)
From: "Frank J. Wancho" <WANCHO@SIMTEL20>
To:   INFO-KERMIT@CU20B
Subject: Use of IOBYTE in CP/M-80 Kermit

The real problem is that not all of the versions of CP/M for the N*
even have IOBYTE implemented.  In particular, N*'s own implementation
does not!  Considering the extra overhead in making BIOS calls in the
first place, much less going through the even higher overhead of an
IOBYTE interpreter, it is far better to simply modify the remote I/O
to directly address the ports in question, if you can find *all*
instances of remote I/O...

--Frank

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

Date: Wed, 17 Oct 84 08:03:53 pdt
From: dual!islenet![e-mail]
To: Info-Kermit@CU20B, [e-mail]
Subject: Making TSO Kermit Work

Finally got KERMIT-TSO working here.  Here's a summary of the changes
we had to make.  Perhaps this will save someone else some energy.

1) We had to severely edit the ASCII-EBCDIC translation tables.  We
use our own TCAM tables here (slightly modified versions of the
TEKTRONIX tables), and edited KERMIT-TSO to agree with them.  This
is not a job for the faint-hearted or poor-of-vision, since it
involves reversing all the ASCII hex codes to decipher the TCAM tables.

2) The default device (DASD group) for creating new files is hard-coded
as SYSDA.  If your installation does not allow users to catalog
datasets on SYSDA they will not be able to RECEIVE to a new dataset.
Easy change.

David Lassner,
University of Hawaii

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

End of Info-Kermit Digest
*************************
-------
22-Oct-84 18:04:56-EDT,18062;000000000000
Mail-From: SY.FDC created at 22-Oct-84 18:04:28
Date: Mon 22 Oct 84 18:04:28-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #34
To: [e-mail]

Info-Kermit Digest         Mon, 22 Oct 1984       Volume 1 : Number 34

Today's Topics:
                  Kermit Network Distribution Moved
          New Documentation for VAX/VMS and Pro-350 Kermits
                         New Kermit-11 Coming
       Changes and fixes for Kermit-MS 2.26 (Several Messages)
        Kermit-80 for Compupro Interfacer 3/4, Bug Correction
                     Kermit-80 for IMCS CPX-48000
                Kermit for TRS80-M100 or NEC PC8201A?
                          Kermit for HP2000?

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

Date: Mon 22 Oct 84 12:04:32-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit Network Distribution Moved
To: [e-mail]

The Internet and CCnet Kermit distribution area has been moved from
COLUMBIA-20 to CU20B effective today, as previously announced.  Many
thanks to the Columbia University Computer Science Department for
playing host to the Kermit collection over the past year.  During that
time it grew in size from about 5 megabytes to more than 20, and shows
no sign of slowing down.

CU20B is a DECSYSTEM-2060 in the Columbia University Center for
Computing Activities in New York City, reachable via anonymous FTP as
CU20B if your site has this name in its host table, or as Internet
host [192.5.43.128].  There are currently no restrictions on the hours
during which anonymous FTP access is available, but since the system
is very busy during prime time (about 10am - 6pm weekdays, eastern
time), please do large transfers outside those hours.

For those who may have missed recent announcements of new Kermit releases,
here are the top few lines of KER:CURRENT.DOC, for the month of October:

Code  Machine/OS        Language     Ver #   dd/mm/yy  Author or Contact

CPM   Compupro IF 3/4   ASM           3.9A   20/10/84  PS1.YAAGP@CU20B
20    DEC-20/TOPS-20    MACRO-20    4.2(251) 18/10/84  SY.FDC@CU20B
CR    Cray-1,Cray-XMP   Fortran77      -     18/10/84  lfm@lanl
MC1   Apple Macintosh   C (SUMACC)     -     16/10/84  engel@harvard
H8    Harris 800       Pascal/Asm      -     11/10/84  [e-mail]
VX    VAX/VMS          Pascal/Fortran 1.1E   11/10/84  P.Murton, U Toronto
RT    PDP11/RT11        OMSI Pascal   2.2C   11/10/84  P.Murton, U Toronto
86/APC NEC APC/CPM-86   ASM86         2.8    10/10/84  CONTEXT@WASHINGTON
86/RB Rainbow/CPM-86    ASM86         2.8    10/10/84  CONTEXT@WASHINGTON
AP2   Apple II/DOS     AppleAssembler 2.?     9/10/84  Olaf Pors, U of Va.
UN    Sperry/Univac1100 NOSC Pascal   2.0     8/10/84  Butt@UMD2
MAC80 8080 Cross Asmblr MACRO-10    10F(121)  8/10/84  CERRITOS@USC-ECL
HL6   Honeywell L6/10   MASM          1.20A   5/10/84  Carlin%pco@MIT-MULTICS
HG    HoneywellDPS8,66  C             3.0     5/10/84  Carlin%pco@MIT-MULTICS

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

Date: Mon 22 Oct 84 12:06:52-EDT
From: Frank da Cruz <[e-mail]>
Subject: New documentation for VAX/VMS and Pro-350 Kermits
To: [e-mail]

New manual chapters are available for two of the Stevens Institute of
Technology Kermits, VAX/VMS and DEC Pro-350 P/OS.  The programs themselves
have not changed, but the Kermit User Guide manual chapters describing
them have been updated to reflect the current versions.  The files are in
KER:VMSMIT.DOC and KER:PROMIT.DOC; Scribe text formatter source for the
two are in corresponding .MSS files.

Thanks to Bob McQueen and Nick Bush of Stevens for the contribution.

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

DATE: MON, 22 OCT 1984
FROM: ATSBDN AT UOFT01.BITNET
TO: SY.FDC AT CU20B
SUBJECT: NEW KERMIT-11 COMING

New release of Kermit-11:

. Support for P/OS and PRO/RT11.
. Smaller task image due to splitting some modules up with new overlay.

The PRO/RT11 version uses the distributed XC handler for i/o.  This
handler does NOT support 8-bit data, so binary transfers will have to
use 8th-bit prefixing.  At some point in the near future, I will write a
handler for Kermit-11 on PRO/RT.

This new Kermit-11 is currently in FT1 and will be made available in
one to two weeks.
                                                brian nelson

[Ed. - It will be announced on Info-Kermit when it arrives.]

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

Date: 18 Oct 1984 2324-EDT
From: LCG.KERMIT@DEC-MARLBORO
To: EIBEN@DEC-MARLBORO
Subject: Problems with Kermit-MS on Rainbow

I've been using Kermit-MS with a Rainbow 100A and observed the following
behavior tonight for the first time while using STI's SMARTQUERY on a
VAX:

1. Kermit-MS did not obey the sequence that sets application cursor
   keys, i.e. the cursor keys should have been sending out ESC O A, but
   were still sending ESC [ A.  I checked with the pure terminal mode
   and with CPM-86 Kermit 2.8, and both of these get the application
   cursor keys set when the sequence (not sure what it is) is sent.

[Ed. - We'll look into the possibility of responding to host commands to
change keypad mode, with particular attention to how that might interact
with user-defined key redefinitions.]

2. After putting the status or help message overlay on the screen, video
   attributes that were there (reverse video, bold) are not restored
   when the screen is restored.  Also, if the graphics character set was
   selected, the bottom of screen prompts are written in graphics
   characters.

[Ed. - This should be fixed in the next release.]

Now, for a question: is there any work currently proceeding on a
Tektronix 4010 emulation as part of either Rainbow Kermit for those of
us with graphics options?  I could certainly use the graphics capability
of our VAX while Rainbowing at home.  If no one is looking into this, I
am willing to start on it as a part of CPM-86 Kermit.  Please let me know
if there is interest or work already proceeding on this.

[Ed. - Answer, no -- be my guest!]

        Carl Houseman
        GENICOM Corp.
        1 General Electric Drive
        Waynesboro, VA 22980
        703-949-1323

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

Date: Fri, 19 Oct 84 16:45:32 EDT
From: Edgar B. Butt <[e-mail]>
To: [e-mail]
Subject: Changes and fixes for MSKERMIT 2.26

Here is a copy of a message that must have been lost several weeks ago.

Ed (that's -gar, not -itor)

Congratulations on the new modular MS-KERMIT.  It is much easier to work with
and has many features we like here at the University of Maryland, College Park.
We have used it successfully (with some changes) on IBM, Zenith, and Sperry
PC's connected to our IBM (VM/CMS) and Sperry 1100 systems.

I am sending changes to MS-KERMIT 2.26 we have made.  Version 2.26, as
distributed did not work very well with our Sperry 1100 systems for several
reasons.  First, MS-KERMIT is not very good at ignoring the extraneous EOL
characters that some operating systems transmit between the end of one packet
and the beginning of another.  Second, when running in full duplex during file
transfer, MS-KERMIT is confused by the echo of the packets it sends.

The change information that follows is divided into three parts:

    1.  A narrative of the changes.
    2.  Changes with line numbers relative to the 2.26 release.
    3.  Changes in context, that is, changes with hunks of the
        original code around them.

Lines beginning with '.' provide a guide to the sections.

Yours for better frogs,

Edgar Butt ([e-mail])
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
. Begin narrative of changes.
.
[UMD1] mscomm

     In subroutine INPKT, do not begin putting characters in the packet
     buffer until the SOH is encountered.  This will prevent extraneous
     EOL characters transmitted by the remote kermit between the EOL
     for the previous packet and the SOH for the expected packet from
     terminating packet input before it really gets started.
     For example, the Univac 1100 sends CR-LF in response to the packet
     it receives.  It also terminates the packet it sends with CR-LF.
     This means that between the checksum in one packet and the
     character SOH in the next packet, the other kermit finds
     CR-LF-CR-LF.  The first CR terminates the packet and the
     second CR makes PCKERMIT think it has received a bad packet.

[UMD2] mscomm

     In subroutine INPKT, whenever a SOH is encountered, discard all
     characters already input and start filling the buffer again.

[UMD3] mscomm

     Discard echoed packets when the remote Kermit is echoing characters.
     When LOCAL-ECHO is off, the type of each packet received is compared
     with the type of the last packet sent.  If the types are the same,
     the input packet is discarded.  A previous attempt to discard echoed
     packets by flushing the input buffer immediately after transmitting
     a packet failed because concentrators, 1200 baud modems, and UART
     buffers introduced so much delay that the echoed SOH from short
     packets did not always arrive in time to be discarded.

[UMD4] mscomm

     Enlarge the input packet buffer (recpkt) and provide space after
     the input packet buffer for the dollar sign which is appended for
     debug purposes.  The buffer was enlarged because the protocol allows
     miscellaneous characters to occur between the checksum and the EOL
     character.  If subroutine INPKT did not have space for those characters
     it would discard a possibly good packet.  The 'slop' area after the
     buffer was provided because the debug routine stored a dollar sign
     after a received packet before sending it to MS-DOS for display.
     Without the slop area the dollar sign goes over the CRC table.

[UMD5] msyibm

     Correct 'Echo' portion of mode line when in terminal mode.

[UMD6] msyibm

     Correct processing of TAB character when in H-19 mode.  The H-19
     manual specifies that a TAB character is to move the cursor (without
     erasing) to the next tab stop or to the next column if the cursor
     is on or beyond the last tab stop.  Tab stops are fixed in columns
     9, 17, 25, 33, 41, 49, 57, 65, and 73.

[UMD7] msyibm

     Implement H-19 cursor save and restore functions.
     "ESC j" causes the current cursor position to be saved.  "ESC k"
     causes the cursor to be moved to the positon it was in the last
     time it was saved.

[UMD8] msdefs mscomm msset msterm

     Make the appearance of the mode line settable in command mode and
     hence settable by MSKERMIT.INI.  Also, display the status
     of the mode line.  The following commands control the mode line:

               SET MODE-LINE ON
               SET MODE-LINE OFF

[UMD9] msset

     Decouple HANDSHAKE and FLOW CONTROL.  The usefulness of being able
     to set HANDSHAKE and FLOW CONTROL independently is considerably
     reduced by having one set when the other is cleared.  These
     changes prevent the clearing of one from setting the other.  The
     restriction that they can't be set simultaneously remains.

[UMD10] msfile

     Detect CTRL-Z in disk file when EOF MODE is CTRL-Z.
     Code to detect CTRL-Z in disk file was in MSSEND, routine SDATA.
     Unfortunately, by the time disk data gets to MSSEND, the character
     CTRL-Z has been quoted to the two characters "#Z".  This change
     looks for the CTRL-Z in its undisguised form.  The result of not
     detecting the CTRL-Z is to have an extra "line" transmitted
     containing only the CTRL-Z.  Files sent to the PC and back picked
     up an extra line

[UMD11] msdefs

     Set Kermit version to 2.26e to identify the above changes.

[Ed. - Code omitted, fixes will appear in next release.]

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

Date: Sat, 20 Oct 84 03:38:29 pdt
From: dual!islenet!david@Berkeley
To: Info-Kermit@CU20B
Subject: Kermit-MS V2.26 Hawaii Patches

Here's a summary of the changes we made to Kermit-MS V2.26 that haven't
shown up in Info-Kermit.  Hope you find them useful.

David

; g1    Fix file renaming code not to overwrite original name unless
;    unavoidable, but to do 'Pacman' ampersands if necessary.
;    Ian Gibbons, Univ of Hawaii 10/2/84
; g2    Change 'cmp chrcnt,00H' to 'cmp chrcnt,0FFFFH' in ENCOD2 so that
;    files of length (integer X 80H)+1 will be sent correctly. Adjust
;    other file send code using 'chrcnt' to be consistent.
;    Ian 10/4/84
; g3    Move EOF CTRL-Z code from MSSEND to 'encode' in MSFILE, so that it
;    can look for unquoted unprefixed ctrl-z's. Also terminate file send
;    only when we find a ctrl-z in the final sector that is followed
;    solely by ctrl-z's or 00H's. (Kermit does not seem an appropriate
;    place to do major file editing based upon a stray ctrl-z). MSRECV
;    has been fixed to add a CTRL-Z to incoming file (with EOF CTRL-Z)
;    only if the final char of the received file is not already a CTRL-Z.
;    The EOF CTRL-Z file closing now does what user-guide says it does.
;    (with the added choice of sending or not sending an EOF CTRL-Z to
;    the remote host).
;    SET EOF RCTRL-Z puts a ^Z at end of both incoming and outgoing files
;    SET EOF CTRL-Z puts a ^Z onto incoming files, but does not send one
;            on files going out to remote host.
;    SET EOF NOCTRL-Z works solely from file size in directory and pays
;             no special attention to ^Z's.
;    Ian 10/4/84
;
[Ed. - Code omitted, fixes will appear in next release.]

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

Date: Fri 19 Oct 84 23:36:58-EDT
From: Guy Valiquette <[e-mail]>
Subject: KERMIT-80 for Compupro Interfacer 3/4, bug correction
To: [e-mail]

Dear Frank,

I just found out why KERMIT-80 for the Godbout Interfacer 3/4 did not work with
the U S Robotics Password modem.  It's got nothing to do with the modem, but
rather with the testing environment!!!  Turns out that when disabling the modem
UART to hand up the communication (in subroutine "hangup"), I forgot to select
the proper UART.  This was inocuous when the console was on the System Support
1 board, but disastrous if the console also is on an Interfacer 3/4 UART: since
the last selected user most likely (with MP/M) or certainly (with CP/M) the
console, disabling the UART effectively kills the console serial channel.
Sorry for all of you out there who got this bugged KERMIT, but I'm just a
working physician and research scientist who plays with computers....

Please pass the fix along with my appologies:
;
; Problem:
;    Kermit hangs if console is on an Interfacer 3/4 port
;    and the EXIT or BYE commands are executed.
;
; Cause:
;    EXIT and BYE call the "hangup" subroutine.
;    "hangup" disables the UART by sending a 00H byte to the
;    UART command port.  I unfortunately had forgotten to...
;    select the user.  Since the last UART accessed on the Interfacer 3/4
;    was most likely the console, "hangup" hangs the console rather
;    than the phone!!!
;
; Patch:
;    replace the original "hangup" routine by this corrected one.
;
IF cproif4
    cpi    'D'        ;Disconnect modem?
    jnz    intc00        ;no
hangup:    di            ;quietly...
    mvi    a,user
    out    usersel        ;select our UART
    xra    a        ;get a null byte
    out    command        ;disable UART
    sta    ckdialf        ;pull down flag to reinitialize UART
    ei            ;safe now
    ret            ;most smart modems will hang up on loosing DTR
intc00:
ENDIF;cproif4

[Ed. - The patch has been installed and a new hex file built on CU20B,
in KER:CPMPRO.*]

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

Date: 22 Oct 1984 0901-PST
From: Pawka <PAWKA at NOSC-TECR>
Subject: Kermit-80 for IMCS CPX-48000
To: CC.FDC at COLUMBIA-20.ARPA

Frank: Got KERMIT working between VAX/VMS and a Z-80 based machine, an
Intercontinental Micro Systems Corp. CPZ-48000, using the generic CP/M version.
Seems to work fine. I had to make a few additions to the assembly file, I
thought someone might want to add them in, just in case someone else might buy
one of these obscure machines. The system supports direct IN / OUT handling of
ports, so after

    mdI   EQU     FALSE

I added

    imsc  EQU     TRUE

and added

    OR imsc

to the next IF statement to set 'inout' TRUE.

Next, in the port assignments I added:

    IF imsc
    mnport  EQU     80H  ; modem data port
    mnprts  EQU     81H  ; modem status port
    output  EQU     4H   ; transmitter buffer empty
        input   EQU     1H   ; receive data available
    ENDIF;imsc

Lastly, down near the end for the program herald I added:

    IF imsc
    versi0: db    '[IMSC CPZ-48000]',0
    ENDIF;imsc

Thanks for your help in pointing me to the correct files for FTP'ing in
the first place,

                Mike Pawka
                Naval Ocean Systems Center
                [e-mail]

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

Date: Sun 21 Oct 84 17:29:34-PDT
From: Doug <[e-mail]>
Subject: KERMIT for TRS80-M100 or NEC PC8201A?
To: info-kermit%CU20B

Are there any such out there, or in the works?
        faunt%hplabs@csnet-relay
        ....!hplabs!faunt

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

Date: 19 Oct 1984  19:55 MDT (Fri)
From: Keith Petersen <W8SDZ@SIMTEL20>
To:   Info-Kermit@COLUMBIA-20
Subject: Kermit for HP2000?

Is anyone working on a Kermit for the HP2000?  I have a request from a friend
who needs it.  It's a time-sharing mainframe that runs Hewlett-Packard Extended
BASIC.

--Keith

[Ed. - There is a BASIC implementation in KER:800KER.*.  It's reportedly in
an unusual dialect of BASIC, and it's pretty rudimentary, but it might be
a starting point.]

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

End of Info-Kermit Digest
*************************
-------
29-Oct-84 17:31:17-EST,26372;000000000001
Mail-From: SY.FDC created at 29-Oct-84 17:28:50
Date: Mon 29 Oct 84 17:28:49-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #35
To: [e-mail]

Info-Kermit Digest         Mon, 29 Oct 1984       Volume 1 : Number 35

Today's Topics:
                        New Kermit for HP 3000
              MS-DOS Kermit 2.26 for the TI-Professional
         MS-DOS/IBM-PC Kermit Runs on Sperry PC & Zenith 150
                     MS-DOS Kermit Misuse of PATH
                     MS-DOS Kermit Screen Glitch
                   Kermit vs Concurrent PC DOS 3.2
     Hex and Binaries Available for 2nd Macintosh Kermit Release
              Problem with 2nd Macintosh Kermit Release
                    Kermit Underway for Elxsi 6400
                     Potential Bug In Unix Kermit
                     Comments from UK on C Kermit
                       Problem with TSO Kermit
              IBM Mainframe Kermit vs Series 1 Question
            Kermit Series 1 Filter for Use with CMS Kermit
                   Thinwire SLIP Protocol Withdrawn
                           TurboDos Kermit?

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

Date: 25 Oct 1984 16:17-EDT
Subject: New Kermit for HP 3000
From: [e-mail]
To: [e-mail]

This is to announce a new KERMIT version for the HP 3000.  It is written
in SPL specifically for an HP 3000 running MPE.  Features include:

     o Binary and text transmission/reception
     o Server mode
     o 8th-bit prefixing
     o Repeat count prefixing
     o Numerous commands for control of MPE file system parameters

Some Questions and answers:

  What is SPL ?

SPL stands for Systems Programming Language.  It's the moral equivalent
of assembly language on the HP 3000 (there is no assembler).  Since SPL
is not included when you purchase a 3000, ALL sites don't have it (extra
cost option from HP).  On the other hand, SPL is practically a requirement
for serious development on the 3000.  It may be the most commonly available
language (other than COBOL) in the HP 3000 community.

  Why not modify the Software Toolworks version ?

When I started work on this version (6 - 8 months ago), the Software Toolworks
version was not available.  When we got a copy of the ST version, I stopped
work on this one.  Why re-invent the wheel?  I didn't have a PC to test it with
anyway.  The ST version is a fine product and the only real limitation was the
inability to handle binary files.  This was due to the bizarre way that MPE
(the HP 3000 operating system) stores files, its (MPE's) inability to transfer
8 bit characters, and the fact that MS DOS KERMIT did not support 8 bit
quoting.  Since then, things have changed: MS DOS KERMIT does 8 bit quoting, I
have a PC to test with and we still need binary file transfer.  I found myself
with a RATFOR KERMIT that worked and an SPL KERMIT that almost worked.  I am
not too familiar with RATFOR but I am very familiar with SPL.  RATFOR (Software
Toolworks flavor) is somewhat rare on the 3000.  SPL is quite common.  The
choice was obvious.

I would like to make KERMIT and the associated manuals/documentation available
to the INTEREX (HP international users group) Contributed Software Library.
Please let me know if this is OK with you.

[Ed. - It is, please do!]

Finally, thanks to Columbia University for providing KERMIT to us in the
first place.  It's a useful tool and I've had a lot of fun working with
it.

       - Ed Eldridge
         Polaris, Inc.
         1400 Wilson Blvd.  suite 1100
         Arlington, Virginia  22209
         [phone]

[Ed. - The files are in KER:HP3000.* on CU20B, available via anonymous FTP.]

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

Date: 29-Oct-84 08:36:42 EST
From: Joe Smith, CSM
To: EIBEN
Subject: MS-DOS Kermit 2.26 for the TI-Professional

Bernie and Frank:

I uploaded MSXTIPRO.ASM and MSTIPRO.EXE.  I still have some work left
to do on it, but at least it runs!

Joe Smith, Colorado School of Mines Computing Center, Golden CO 80401;
[phone]

[Ed. - The files are available on CU20B.  KER:MSXTIPRO.* are the source
and "boo" files, along with some brief notes about the implementation.
KB:MSTIPRO.EXE is the 8-bit binary .EXE file.]

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

Date: Tue, 23 Oct 84 09:17:01 EDT
From: Edgar B. Butt <[e-mail]>
To: Frank da Cruz <SY.FDC@CU20B>
Subject: MS-DOS/IBM-PC Kermit Runs on Sperry PC & Zenith 150

IBM PC version of MSKERMIT 2.26 with U. of Md. changes runs without
modification on Sperry and Zenith (150 series) PC's.  Sperry's PC is made by
Mitsubishi -- except for the label it looks like the Leading Edge PC, also
by Mitsubishi.

[Ed. - The U of Md changes were for system-independent bugs, so I presume
that the program also runs on these systems without the U. of Md. changes.]

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

Date: Sat 20 Oct 84 16:46:13-CDT
From: Steven Shevell <[e-mail]>
Subject: MS-DOS Kermit Misuse of PATH
To: [e-mail]

I found in the Kermit BB a message about the PATH problem on the XT.  The
response was that this is the way that Kermit should work: follow the PATH
designation without looking at the current directory.  This is wrong, and
should be fixed.

I quote from the IBM DOS documentation regarding the PATH command: [PATH]
causes specified directories to be searched for commands or batch files THAT
WERE NOT FOUND BY A SEARCH OF THE CURRENT DIRECTORY (manual for DOS V2.00, page
6-117; caps added).  Therefore, Kermit should search the current directory for
.INI files before looking to other directories specified in the path command.

I got Kermit to work on the hard disk by adding the current directory to
the PATH (I believe the following is an undocumented feature of PC-DOS V2.00:
the path name "." (a single period) specifies the current directory, so if
the current disk is C:, the current directory is  C:.).  Still, this should
not be necessary; the way Kermit handles PATH is inconsistent with DOS.

Unless you disagree, please forward to the appropriate person at Columbia.

[Ed. - You're right that Kermit should search things the way DOS does, at least
in most cases.  This will probably be fixed in the next release.  However, it's
not true that Kermit never looks in the current directory; it just looks there
last instead of first.  It's also supposed to look there if PATH is not
defined.]

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

Date: 25 Oct 1984 1437-EDT
Forwarded-By: B.Eiben LCG Ext 617-467-4431 <[e-mail]>
Subject: Re: MS-DOS Kermit Screen Glitch

    The "glitch" reported in Kermit Digest 34 about a trashed Rainbow
screen reminds me of a similar problem we found when using TOPS-20 Kermit.
HOWEVER, the problem was tracked down not to Kermit but to Final Word ---
when Final Word exited, it did not properly reset the screen.  (The same
problem would occur if you were using EMACS on TOPS-20 and would interrupt
your work there to do something on the Rainbow.)

    The MSDOS solution most of us chose to implement was to change our
MSDOS prompt to include the reset automatically ...  a la'

        A>prompt $e7$e[?6l$e8$n:

This seems to work.  (Of course popping back and forth between EMACS-20,
FW configed with EMACS.BIN and TURBO emacsified is enough to cause
anyone's screen to start scrolling sideways...)

Steve Cavrak
Academic Computing Center
University of Vermont
Burlington Vermont, 05405

[Ed. - By the way, did you know that if the Rainbow firmware attempts to
"display" certain sequences on the screen, the system will hang or crash?  Two
of these are ESC 9 and ESC c (lowercase c).  This has nothing to do with
Kermit; it will happen if a host sends you those sequences in terminal mode, or
if you type them in half-duplex terminal mode, etc.  Kermit will have to fix
this problem by checking for them explicitly and never feeding them to the
firmware.]

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

Date: Sat 20 Oct 84 14:51:14-PDT
From: Jim Celoni S.J. <[e-mail]>
Subject: Kermit vs Concurrent PC DOS 3.2
To: [e-mail]

[Ed. - This is an excerpt from a much longer message that was posted to
Info-IBMPC.]

At long last I can transfer files (w/ Kermit) to the Vax while editing others!
My copy of Digital Research (DRI) Concurrent PC DOS version 3.2 (free upgrade
to Concurrent CP/M with Windows version 2.0) arrived this week, and now each
of four windows can run a DOS or CP/M-86 application.

I've edited with The Final Word 1.17, sent and received files with Kermit
2.26, and run the system file manager concurrently.  FW wants the whole screen
while editing.  Cdos stops FW from running in another window when FW tries to
open the swap file but properly allows another FW in a different directory.
Kermit made 55 (instead of the usual zero) retries while sending over 1000
packets at 1200 baud.  Kermit slows FW down but not much.  Kermit uses the
full screen in terminal mode when I'm in Emacs, but it's well-behaved when in
command and file transfer modes.  There are a few irregularities, like bogus
help after "set heath ?" and mixed normal and reverse video in the ^]S status
display, but then the file manager has reverse video glitches on the lower
right of its object panel too.

    +j

P.S.: I'm not related to any of the companies whose products and trademarks
appear in this note except as customer.

[Ed. - It's nice to hear that Kermit 2.26 works under Concurrent DOS.  You
should be able to get around Kermit taking over the screen while you're in
Emacs by shutting H-19 emulation off and loading something "well-behaved" like
ANSI.SYS as your console driver.  Same for Topview or other window managers.
Of course then you get less performance, but those are the tradeoffs.  Rumor
has it that IBM will eventually come out with a way to access the screen
efficiently from DOS, and when that happens Kermit will use it.]

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

Date: Thu, 25 Oct 84 20:49:47 pdt
From: Bill Croft <croft@safe>
Subject: Hex and Binaries Available for 2nd Macintosh Kermit Release
To: [e-mail]

Steve Engel's (engel@harvard) new kermit is filed on kermit.rsrc and
kermit.dl.

[Ed. - They are also available on CU20B as KER:MC1KERMIT.DL (this is the
printable 7-bit ASCII "hex"-format file, downloadable to the Macintosh with
the "fromhex" utility) and (KB:MC1KERMIT.RSR the downline-loadable 8-bit
binary resource file, which you can download to the Mac with the previous
version of Kermit, provided you change its name to back KERMIT.RSRC).
The source continues to be available in KER:MC1KERMIT.SH.  For those who
want Macintosh Kermit but don't know about this version yet, please note
that it is written under the Berkeley-Unix-based SUMACC Macintosh cross-
development system.  Thanks to whoever at SUMEX built the .RSRC and .DL
files from the new shell script.]

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

Date: Sun 28 Oct 84 16:47:39-PST
From: Doug Brutlag <[e-mail]>
Subject: Problem with 2nd Macintosh Kermit Release
To: [e-mail]
cc: [e-mail], [e-mail]

Steve,

    Using the new version of MacKermit from [SUMEX]<INFO-MAC>KERMIT
.RSRC or .DL I have had trouble getting MacKermit to communicate
properly.  Although this new version saves the BAUD setting in the
controls from one run to the next, I have found it necessary to reset
the BAUD setting from 1200 to 9600 and then back to 1200 again before
MacKermit uses the appropriate setting.  Although the program saves the
settings, it appears to not use the saved settings until they are
changed from within controls.

    I have also noted previously mentioned problems in CONNECT mode
that delete still deletes one to many characters on the screen and
MacKermit often hangs while receiving a large number of short lines
(like after a DIR command).

    The new Executable option is very nice, allowing one to download
8-bit .RSRC files from TOPS-20 directly to an application file.

Doug Brutlag

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

Date: 29 Oct 84 13:48 EDT
From: "David H M Spector" <[e-mail]>
To: [e-mail]
Subject: Kermit Underway for Elxsi 6400

Here at NYU, we have a brand new Elxsi 6400, which is a kinda nifty 64 bit
multiprocessor.  Since we have no networking code/hardware for it, I thought
I'd try and bring Kermit to it.  It has both fortran and C, so I will
probably try to use one of those languages.

For a first shot I'll try to bring over the generic C kermit, and then proceed
from there.  The name of the operating system is EMBOS, Elxsi Message Based
Operating System.  It's not much like unix, but does sport a C compiler.  The
OS is more like a cross between VMS and Unix, with a *Really* Verbose command
language.  Its main virtue is that it is really fast.  Our configuration has 2
CPUs ( Expandable to 5 CPUs; 1 CPU = 4 Vax 11/780s ), 16Mb of Memory and,
currently, 32 ports.  The machine does have a Unix emulation that runs under
Embos and is currenly an implemenation of Bell System 5.2, the only thing it
lacks is (*Sigh*) UUCP.  (Even under EMBOS there is no networking facility,
although they say they are working on IP/TCP.)  Elxsi says they will eventually
have it up to Berkeley 4.2...  I will be doing this as a midnite project, so
it'll be on a time available basis for now.

            David HM Spector
            NYU/acf Systems Group
            251 Mercer St. Rm. 329WWH
            NY, NY 10012
            [phone]

[Ed. - Good luck.  Recommend you work from the current C version, adding only
the minimum system-dependent code for your system.  That code can later be
fitted into the new full-functioned modular C Kermit when that's ready.]

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

Date: 17 Oct 84 13:10:53 EDT
From: tpsc-irt @ DDN2.ARPA
Subject: Potential Bug In Unix Kermit.
To: info-kermit @ cu20b.arpa

There is a bug in the latest (and earlier) versions of Unix Kermit which will
affect machines in which the pointer and integer size is different.  The bug
occurs in two locations in the program. First, in the "connect" function, at
about line 895, wait is called with an argument of "0".  The proper form is
wait((int *)0). This forces the argument to be sized as a pointer.  The second
occurs in the spack function at about line 965.  The write system call is given
the difference in two pointers as its third argument

    write(ttyfd,buffer,bufp-buffer+1)

however, write expects an integer. A fix for this is to put the difference
"bufp-buffer+1" into an integer (such as the i already used as a counter) and
call write with the integer instead.  Again, these problems occur only in
machines (such as the CCI 5/20) which have different sizes for pointers and
integers. Symptoms of this bug are bus errors (caused by a bad pointer passed
to wait) and kermits which can't send packets (caused by the pointer passed to
write).

[Ed. - Thanks for the pointers; they'll be reflected in forthcoming releases.]

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

Date:     Fri, 26 Oct 84 9:37:59 BST
From:     Chris-on-Fridays <[e-mail]>
To:       [e-mail]
Subject:  Comments from UK on C Kermit

     Having no background other than the Manuals, no contact with other Kermit
users, and a non-standard unix, I decided to work from the "demonstration"
version "kermit.c".  Has this ever been run in anger?  I think I've spotted at
least 1 flaw:-

  In rpack(), when reading data, an SOH won't break you to the end of the
while; suggest the statement

      if (t == SOH) continue;

in the for loop for data characters be replaced by

      if (t == SOH) break;

with a "if (t == SOH) continue;" placed immediately after the for statement.

[Ed. - Good idea; the mistake is probably due to overuse of the unkill
feature of our editor...]

Also, the code is sufficiently neat and clever that you have to be quite
careful when removing "unneccessary" bits; they tend to have side-effects which
are used later on!

     Anyway, having cut this about to become a remote-only and stripped out all
the UCB4X system calls, it is on the verge of working.  Got a unix system
problem for the wizards to sort out (dumps core on input).

     The RML Z80 micro (480Z) has an unusual i/o architecture in that it uses a
single (asynchronous) port for both disks and wideworld communications;
therefore no iobyte.  Also we use the DRI assembler code, not M80, so I didn't
feel like tackling the very large generic CPM80 version.  Cutting up "kermit.c"
to replace the user interface, make it reentrant, and slot in existing
high-performance communications-code has produced a version which runs quite
sweetly at up to 4800baud.  If you are interested, and subject to commercial
considerations (I am a consultant, not an employee of the firm), this could
probably be supplied and documented as a generic version for any micro which
runs a C-compiler, and can supply a limited set of machine-dependent routines
for handling screen and comms line faster than CP/M called from C.  It does not
try to be any particular VDU terminal; RML already has a high-performance VT100
emulator, which will probably have Kermit protocol slotted into it in due
course.  (We are using the Aztec compiler - which doesn't implement "#if".)

     For any other UK users who may see this, we have the tape (date: August
1984) at UCL Computer Science, and about a third of it is online and accessible
by Blue-Book NIFTP.  It'll be accessible by Kermit itself as soon as I stop the
program coredumping.  We've also got most of the documentation, and the
info-kermit digests as they appear.  On request, we could extract other files
from the tape.  I'll be glad to give details personally; if you're on JANET
mail, I am cjk@ucl-cs; else phone me Monday-Wednesday @ RML, Oxford (0865)
249866.  Or NIFTP out the file "/44d/kermit/read.me" using userid GUEST and no
passwords.  [Note that this availability of Kermit is a limited-life thing.
UCL does not have funding/resources to get and distribute updated sources.  But
I would hope to keep it online through this academic year.]

    I would in any case be glad to hear from any other UK Kermits in order to
prove interworkability.

     Keep up the good work!

                        Chris Kennington  (cjk @ UK.AC.UCL-CS).

[Ed. - Thanks; your generic microcomputer C version would be most welcome.]

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

Date: 25 Oct 1984 1319 PDT
From: Joe Wieclawek <[e-mail]>
Subject: Problem with TSO Kermit
To: [e-mail]

Can any TSO Kermit users offer some help?  The program seems to run as it
should, but no characters ever get sent to the micro. The micros run MS and
CP/M versions of Kermit and have no problem talking to each other or VMS and
UNIX Kermit.  The DEBUG in TSO Kermit tells me:

  (When TSO is the receiver and the micro is the sender)
    > TGET gets the send init packer
    > The ACK packet is formed
    > TPUT is called
    > TPUT returns no-error status
   *> NO characters are sent out (no ACK)
        (The micro's port was monitored and nothing gets there)
    > TGET gets a send init packet again etc, until max retries

  (When TSO is the sender)
    > The send init packet is formed
    > TPUT is called
    > TPUT returns no-error status
   *> no characters are sent out
??????????????????

Joe Wieclawek
Jet Propulsion Laboratory
Pasadena California
[phone]
[e-mail]

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

Date: 29 October 1984, 11:58:30 CST
From: ("Ron Rusnak [phone]") SYSRONR at UCHIVM1
To:   SY.FDC at CU20B.BITNET
Subject: Re: Problem with TSO Kermit

I'm the guy unfortunately.  The problem that this guy is having is probably
related to either his terminal handler (TCAM or VTAM or whatever), or the
translate tables.  As far as, I know the only complaints I have heard come from
folks who have ASCII translate tables.  It is neccessary that TPUT control send
all ASCII characters.

Given what this person said, I would suspect something wierd with whatever
acess method they're using.

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

Date: Fri 26 Oct 84 15:39:12-PDT
From: ALFIERI@ECLD.#ECLnet
Subject: IBM Mainframe Kermit vs Series 1 Question
To: [e-mail]

We are planning to mount Kermit on the IBM mainframes (soon, I hope), but we
would appreciate any information about whether there are any problems using
Kermit through the Series 1 mini.  Has anyone else done this yet?

asbed bedrossian
computing information services
university of southern california

[Ed. - See below.]

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

From: [e-mail] (bjerke)
Date: Fri, 26 Oct 84 15:51:45 CDT
To: [e-mail]
Subject: Kermit Series 1 Filter for Use with CMSKERMIT

I have written a "filter" to enable CMSKERMIT to talk to PCKERMIT 1.20 when
the mainframe/micro link is a SERIES/1 running the Yale Ascii Terminal
Communications System 2.1 (5796-RKJ) or the Host Loaded Yale Ascii
Communications System II (5798-RRJ). It should also work with the new 7171;
it requires only that the transparent ascii read/write feature be supported.
My main design point was to avoid any modifications to the micro-resident
KERMIT and to restrict CMSKERMIT modifications to a minimum number of trivial
changes.

I think I have achieved this goal. The main changes to CMSKERMIT are:

1. Since Yale-supported devices look like 327x terminals, checking for ascii
   terminals is removed

2. In SPACK and RPACK, the return codes from WRTERM and RDTERM are checked,
   and if non-zero an appropriate error condition is flagged to abort file
   transfer

The filter works by installing a nucleus extension that traps WAITRD and
TYPLIN svc's.  During the normal command-level interaction with KERMIT these
calls are passed on to CMS for handling. When file transfer begins, the
filter processes the calls as transparent read/write sequences (first
translating the buffer back to ascii when sending, and to ebcdic before
passing a received buffer back to KERMIT). Transition to file-transfer mode
is detected when WAITRD is first entered with EDIT=PHYS, or TYPLIN is first
entered with a buffer that begins with X'01'. Transition back to command mode
is detected when TYPLIN is in file-transfer mode and is entered with a
buffer that does not begin with X'01'. Both entry points pass back non-zero
return codes to RDTERM/WRTERM when errors occur.  These return code are
distinct from the standard codes.

The above considerations mean that the following restrictions must be obeyed by
CMSKERMIT:

1. Reads and writes in file-transfer mode must always alternate; if they do not
   the transparent read/write facility may not function correctly. In practice
   this implies that CMSKERMIT can never be modified to include a timeout,
   since that could result in two or more successive writes. Micro-based KERMIT
   can timeout, since if a packet is lost CMSKERMIT is still waiting to receive
   (if CMSKERMIT lets micro-based KERMIT timeout even though a packet has been
   received, then something is probably seriously wrong anyway).

2. No additional RDTERMS with EDIT=PHYS may be introduced into CMSKERMIT

3. The default start-of-packet character (SOH) and end-of-packet character (CR)
   must not be changed if the filter is being used

I have not tested the filter extensively yet, and what testing has been done
has involved only PCKERMIT 1.20. I hope that the filter will also work with any
ot other micro-based version of KERMIT, including MSKERMIT. I am trying to
arrange to test MSKERMIT here (I don't have enough memory in my PC) and also to
test the 7171 connection. I don't think the program is ready to distribute, but
I would like to make it available to a limited number of other sites for
testing. I wo would like to know if the restrictions I posed above are
reasonable ones for CMSKERMIT to live with, if there is any interest at all in
distributing a n addon utility like this one, and if you can give me some help
in arranging testing with other sites.  Thanks in advance!

[Ed. - We will definitely take a look at this for the next release of CMS
Kermit, which we're working on now.  Packet transmission through a 3270
protocol emulator is a hard problem to attack, but for the Series 1 there
seems to be this simple workaround of putting it in "transparent mode".
Since the Series 1 is so common, it's worth handling as a special case,
possibly with SET commands in KERMIT-CMS itself so that the restrictions you
mentioned could be lifted.]

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

To: [e-mail]
Subject: Thinwire SLIP Protocol Withdrawn
Date: 23 Oct 84 13:36:58 EDT (Tue)
From: Gary_Delp <delp@udel-ee>

Please Post:

The authors of RFC914 (the Thinwires) thank all and sundry for the comments
they have received, directly and otherwize.

For those who scan only the tops of messages, and for those who read the whole
things, we would like to retract from consideration SLIP, the Serial Line
Interface Protocol.

[Ed. - Rest of message omitted, see ProtocolS or Info-Micros for details.
The authors retired SLIP in favor of RATP, which was discussed briefly in
Info-Kermit #32 because it compared itself to Kermit protocol.  There's also
another message on ProtocolS, further discussing Kermit vs PCnet vs RATP etc]

Signed,
    Gary Delp
    Dave Farber
    Tom Conte

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

Date: Fri 26 Oct 84 10:40:43-PDT
From: ALFIERI@ECLD.#ECLnet
Subject: TurboDos
To: [e-mail]

Is there a version of Kermit for TurboDos?

Thanks in advance.

vince alfieri
computing information services
university of southern california

alfieri@usc-eclb

[Ed. - Not that I know about.  Anybody out there working on one?]

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

End of Info-Kermit Digest
*************************
-------
 3-Nov-84 11:11:58-EST,9969;000000000001
Mail-From: SY.FDC created at  3-Nov-84 11:11:38
Date: Sat 3 Nov 84 11:11:38-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #36
To: [e-mail]

Info-Kermit Digest         Sat,  3 Nov 1984       Volume 1 : Number 36

Today's Topics:
                        Problems with MSPCTRAN
                        Kermit-11 for PRO/RT11
                 Kermit Micro-to-Micro Documentation
                    Sirius/Victor Kermit Question
                     Kermit for Apple // ProDOS?
                          MacKermit Problem
                           Bugs in kermit.c
                      KERMIT for the BBC micro?
                            WYLBUR Kermit?

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

Date:  Tue, 30 Oct 84 07:28 EST
From:  [e-mail]
Subject:  Problems with MSPCTRAN
To:  [e-mail]

Is there someone out there with whom I can establish direct contact on
this net that has successfully installed CU20B's Kermit V 2.26 on a
Z-100???  I have tried, on-and-off, time permitting, to use MSZ100.BOO
and MSPCTRAN to make an MSKERMIT.EXE file for my Z-100.  Both files were
received using the earlier version of Kermit for the Z-100.  The
conversion of the ".BOO" file was uneventful.  When I tried to execute
it, the sign-on message was displayed, followed by continually scrolling
garbage.  I've gone through this complete procedure (starting with new
ftp'd files) three times in an effort to eliminate random errors.  The
results were consistent.

If you can lend a hand here, I'd appreciate it.  We now have Kermit on
our MULTICS system and more Zeniths are arriving every day.

Wolf Wiedemann RADC-MULTICS

[Ed. - Our fault, sorry!  There was a bug in MSPCTRAN.  It went undetected
for a long time because the bug didn't surface on the .BOO files we tested
it on.  See next message.]

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

Date:  Wed, 1 Nov 84 07:28PM EST
From:  Sy.WBC3@CU20B
Subject: Re: Problems with MSPCTRAN
To:  [e-mail]

Fix for MSPCTRAN:

    change line 400 from:

400  if len(x$) < 4 goto 300        ' Is the input buffer empty?

    to:

400  if len(x$) < 2 goto 300        ' Is the input buffer empty?

    and insert at line 425:

425  if len(x$) < 3 goto 300        ' Is the input buffer empty?


This was tested and works fine, though it takes over 25 minutes.

                    -Bill Catchings

[Ed. - The new MSPCTRAN.BAS is in KER: on CU20B.]

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

Date: Thu 1 Nov 84 10:59:42-EST
From: Brian Nelson <[e-mail]>
Subject: Kermit-11 for PRO/RT11
To: [e-mail]

The following files are the minimum to get kermit-11 onto the PRO/RT11:
KER:K11PRT.MAC, KER:K11PRT.HEX, KER:K11HEX.MAC and KER:K11HLP.HLP. The file
K11HEX.MAC is assembled and linked into K11HEX.SAV and then run to get
the save image created. The file K11PRT.MAC has notes in the beginning
re 2 mods that should (almost MUST) be made to the DEC-supplied XC handler.
Failure to do so will result in internal handler buffer overruns.

A complete Kermit-11 will be forthcoming soon, meanwhile some Pro/RT
users can try this out. The new Kermit-11 also does repeat count stuff.

Note: Requires XM, use VTCOM to download the files from the host.

                            brian nelson

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

Date: Thu, 1 Nov 84  14:39 EST
From: [e-mail]
To: SY.FDC@CU20B
Subject: Kermit Micro-to-Micro Documentation

Frank--

GLAD YOU LIKED THE DOCUMENTATION.  WOULD IT BE POSSIBLE TO ADD THE ARTICLE TO
THE KERMIT DOCUMENTATION AREA ON YOUR TAPES AND IN YOUR FILES?

NORMAN

[Ed. - Yes, Norman's article on micro-to-micro use of Kermit is in
KER:KMICRO.DOC on CU20B.  It's primarily a tutorial on using "primitive"
Kermits between two micros; server operation -- which is now available in
MS-DOS Kermit -- is not discussed.]

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

Date: 29 Oct 1984 1623-PDT
From: HAL.DOVE at Ames-VMSB
Subject: Sirius/Victor Kermit
To: info-kermit at cu20b

I have the MASM version of the Sirius kermit.  Are there any others
out there that use this version on UN*X.  The problem I am having
is that the vt100 emulation does not work too well.  It does not
open and close lines too well.  If I use vi, open line or delete line
in the middle of the page does not work.  Is there anyone out
there who has a corect termcap to make this work correctly.  If not,
I plan to modify the code to have the kermit emulate vt52 when vt100
is off.  This would be trivial except I would still like the function
keys defined as break and exit as they are when in vt100 mode.

Has anyone made this fix?  If so I would like to get a hold of it.

Any help would be more than appreciated!

Mike
hal.dove@ames-vmsb
ucscc!emacs@berkeley

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

Date: 25 October 1984, 16:32:26 CST
From: Ben E. Colley             882-7686             C1453Y   at UMVMA
      103D Lefevre Hall
To:   Frank da Cruz                                  FDCCU    at CUVMB
Subject: Kermit for Apple // family

Hello from central Missouri..  I work here at UM-Columbia in Computing
Services, Micro Support, and am trying to track down some information
about Kermit and the Apple // family.  Particularly, are you aware of
a version that runs under ProDOS, and runs with VM??  Perhaps
you know of someone else who might shed some light on this topic.

HELP.... and Thanks.

Ben....

[Ed. - Anybody working on a ProDOS Kermit?]

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

Date: 31 Oct 1984 15:06-EST
Subject: MacKermit Problem
From: [e-mail]
To: [e-mail], [e-mail]

Steve, I just got a copy of the second MacKermit release.  Thanks for
providing the "Rest Of Us" with an alternative to MS-Basic and MacTerminal.

I am having a problem with getting MacKermit to send pad characters.
Looking at the source, I think the problem is in the "spack" routine.
When sending the pad characters, "count" is not initialized.  This causes
MacKermit to "go away" for a long time (it appears to be sending LOTS of
characters).

Thanks again for all the effort it took to get this thing together in the
first place.
            Ed Eldridge

[Ed. - By the way, there is now a copy of the file in BINHEX format on
CU20B, as KER:MC1KERMIT.HEX.]

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

Date:     Thu, 1 Nov 84 10:07:53 GMT
From: Chris-on-Fridays <[e-mail]>
To: "sy.fdc" <sy.fdc@cu20b>, info-kermit@cu20b
Subject:  Bugs in kermit.c

Frank & Info:

     In process of implementation I have found 2 more bugs in
both kermit.c & uxkermit.c:-

  1.  In the receive routines, rinit() rfile() & rdata(),
        case 'E' of the switches, an error-message is printed
        from "recpkt" whereas it has actually been received
        into "packet".
  2.  The debug packet-printing routines in spack() & rpack()
        both test for no-data by testing that the pointer
        "data" is NULL.  In many cases the pointer itself is
        valid, but points to a null string.  A better test
        is if "len" in spack() or *len in rpack() is zero.

     Incidentally, the UCL 11/44 unix, which I termed
"non-standard", is in fact a standard Berkeley 2.8.  I have got
working code including timeout and flushinput, if you're
interested. Currently embedded in the simple remote-only
version which I hacked up because asked not to spend much time
on it, but could obviously be transferred to the a.s.a.d.
version on which you are working.

     In connection with the Aztec-C / CP/M version which I have
implemented for the RML 480Z micro, I had some trouble with
stacked NAKs (the well-known problem, which I was intentionally
triggering).  To stop Kermit entering and staying in a stable
state of sending each block several times, I tried several
stategies and eventually found that flushing input
automatically at the end of every packet read is a complete
cure.  In the C-version this means replacing the "get and toss
EoL character" call in rpack() by a call to flushinput();
which in any case seems more sensible, since once you've got
the checksum you are home-and-dry (give or take any problems
about speed of line turnaround, which can be solved by
padding).  Comments?
                        Chris Kennington.

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

Date:       Thursday, 1-Nov-84  15:32:08-GMT
From:       RICK (on SXKL10 DEC-10) <[e-mail]>
To:         "cc.fdc" <[e-mail]>
Subject:    KERMIT for the BBC micro

Frank - do you know if anyone has produced (or is working on) a KERMIT for
the BBC micro? A contact name would be useful. I have already posted this
notice on the COM systems at QZ, UCD and York, so there's probably no need
to put it in the Info-Kermit Digest unless you particularly want to. I felt
that you might, being at the centre of things, have access to information
about implementations about which I don't know.

[Ed. - Anybody?]

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

Date: 2 Nov 84 15:22 EDT
From: "David H M Spector" <[e-mail]>
To: [e-mail]
Subject: WYLBUR Kermit??

Hello,

Does anyone have any knowledge of a version of kermit designed to run under
WYLBUR (a sub-system under MVS) on IBM systems?  The only other version
that might work would be the TSO version, but our local IBM systems folks
tell me it would need some large mods.

        any pointers gratefully accepted!
        (Please mail to me, I'll summarize if I get any replies.)


            David HM Spector
            NYU/acf Systems Group
            Arpa:  [e-mail]
            uucp:  ...!allegra!cmcl2!cmcl1!spector


[Ed. - I don't think so, but it's an interesting idea...]

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

End of Info-Kermit Digest
*************************
-------
 9-Nov-84 18:12:05-EST,21594;000000000001
Mail-From: SY.FDC created at  9-Nov-84 18:11:47
Date: Fri 9 Nov 84 18:11:47-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #37
To: [e-mail]

Info-Kermit Digest         Fri,  9 Nov 1984       Volume 1 : Number 37

Departments: (hope this new format doesn't cause any problems...)

  ANNOUNCEMENTS -
    UUCP Kermit Access Now Available
    BITNET KERMSRV Disk Updated

  UNIX KERMIT -
    Unix Kermit Bugs and Problems (several messages)

  MS-DOS KERMIT -
    MS-DOS Kermit Disks Available from PC SIG
    Problems Assembling MS-DOS Kermit with Different Assemblers
    MS-DOS Kermit V2.26 Key Definition
    MSDOS (PCDOS) Kermit vs 8251 Chip
    MS-DOS Kermit CRC Problems
    MS-DOS Kermit 2.26 Bug List
    More on Concurrent PC DOS 3.2
    Kermit for Convergent Technologies C3

  CP/M KERMIT -
    Kermit on the NEC 8800
    TurboDos Kermit

  MISCELLANY -
    Kermit for Compugraphic Photocomposer?

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

Date:     7 Nov 84 9:49:20-CST (Wed)
From:     Mark Vasoll <[e-mail]>
To:       Frank da Cruz <SY.FDC@CU20B>
Subject:  UUCP Kermit Access Now Available

I have won approval from our administration to allow UUCP access to the
Kermit sources on our system from 10:00pm until 10:00am CST, 7 days per
week.  A command like: "uucp okstate!/u/kermit/ux* dir" should transfer the
UNIX Kermit distribution to the requesting system. The file names are the
same as those distributed on the Columbia Kermit tape.

We would appreciate a short "plug" anywhere that you distribute the login
information.  Something like this would be nice:

    UUCP distribution of Kermit is provided as a public service of:

    Oklahoma State University
    Department of Computing and Information Sciences
    Stillwater, Oklahoma

I hope that this helps promote your Kermit project, we are certainly
excited about it.

UUCP login information for site:  okstate

Phone number :  [phone]  (one line only)
Login name   :  uucpker
Password     :  thefrog
Hours        :  10:00pm - 10:00am central time (7 day per week)
Problem      :  okstate!uucp-support  (UUCP)
  reports    :  uucp-support%okstate@csnet-relay  (ARPA)

The phone number is for 300/1200 baud (bell compatible).  The tape that we
received was dated (by Columbia) as Sep. 28, 1984.  The newest version of
MS-DOS Kermit has replaced the version that was on the tape, other than
that things are as they were when you made the tape.

- Mark Vasoll

[Ed. - Thanks!  We'll add this information to our flyers and blurbs.]

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

Date: Thu 8 Nov 84 11:51:35-EST
From: Frank da Cruz <SY.FDC@CU2OB>
Subject: BITNET KERMSRV Disk Updated
To: Info-Kermit

After a long hiatus, the BITNET Kermit distribution area is being updated
again.  The entire distribution area from CU20B was transferred to CUVMA,
and will be incrementally updated on a regular basis from now on, I hope.
Kermit files are available to BITNET sites via a server at host CUVMA.  For
information about this service, type the following command on your own
BITNET host:

    SMSG RSCS MSG CUVMA KERMSRV HELP

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

Date: Mon 5 Nov 84 11:55:23-EST
From: Bill Catchings <[e-mail]>
Subject: UNIX Kermit bug
To: [e-mail]

There is a problem with UNIX kermit that if you use the line command and
the baud command with a speed different from that of your controlling
terminal Kermit seems to hang.  This is actually caused by setting both
the assigned line and the terminal line to the speed requested.  The
following will fix this problem.

In module uxkercnu.c make the following changes:

    From:

extern int remote, ttyfd, lecho;

    To:

extern int remote, ttyfd, lecho, speed;

    After:

    if (remote)                /* Nothing to connect to in remote */
    {                    /* mode, so just return */
    printmsg("No line specified for connection.");
    return;
    }

    Add:

    speed = 0;                /* Don't set the console's speed */

Hopefully this change will make using UNIX Kermit a little bit more useful!

                    -Bill Catchings

[Ed. - This change is installed in the Columbia Kermit distribution files,
KER:UX*.* on CU20B.  Also, the connect command modules have been renamed
to make their names unique within 6.3 filename format:

old           new
UXKERCNU.C -> UXCONU.C    (Connect command for Unix)
UXKERCNV.C -> UXCONV.C    (Connect command for Pro-350 Venix)
]

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

Date:     Fri, 9 Nov 84 10:24:10 GMT
From:     Chris-on-Fridays <[e-mail]>
To:       [e-mail]
Subject:  Unix Kermit Bug and Problem

There's another bug in kermit.c & uxkermit.c.

If you are using a transmission medium which slaps in even parity bits to
your characters, SOH becomes 0x81.  This won't match with the test at the
beginning of rpack(), so you never read a block ....

The same applies to all the tests "if (t == SOH) ..."  inside the main
"while".  All these ought to be relocated AFTER the stripping by "if
(!image) t &= 0177"; it stands to reason that if you are using this sort of
awkward medium, you aren't in "image".

Being purist, all except the data bytes ought always to be stripped.  You
could get some uncomfortably long blocks if you had a garble in "image" ...

[Ed. - Good idea.]

And now for a problem.  This awkward medium also eats "%" as an escape
character.  It does permit you to change the escape, but only to a
printable.  I've been using reverse-quote, which doesn't occur in the
sequence-characters or in my init parameters, and is an oddity in data; but
there is nothing to stop it occurring in the length unless I set down the
far end's max blocksize.  Any suggestions?  Should an optional feature be
to double a specified character (at the char-to-line level, not affecting
length or checksum)?  Of course this only affects the implementation, not
the protocol, so it could in fact be implemented in any specific Kermit as
a private extra feature.
                                Chris Kennington.

[Ed. - We already have encountered media where the escape character has to
be doubled, and some Kermits already have this code.  There's no reason not
to include a facility for this in an implementation, though it's hard to
devise a natural syntax that doesn't conflict with existing commands.
Maybe "SET DOUBLED x" where x is the character that must be doubled during
transmission.  A more general solution would involve changes in the
protocol.]

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

Date: Fri, 9 Nov 1984 2:36pm EST
From: Frank da Cruz <SY.FDC@CU20B>
To: Info-Kermit
Subject: MS-DOS Kermit Disks Available from PC SIG

MS-DOS Kermit 2.26 may be ordered on IBM PC format floppy disk from:

    PC SIG
    1556 Halford Avenue, Suite #130
    Santa Clara, CA  95051
    [phone]

on disks number 41 and 42, for $6.00 per disk.  I believe (but am not
certain) that one disk contains the source and the other contains the
.EXE for the IBM PC only, plus documentation (User Guide manual
chapter for MS-DOS Kermit), and system-dependent source for some of
the other MS-DOS systems, like Wang PC, HP-150, and DEC Rainbow.

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

From: [e-mail] (Mark Mendel)
Subject: Problems Assembling MS-DOS Kermit with Different Assemblers
Date: Thu, 1-Nov-84 14:21:13 CST

Apparently kermit is supposed to be compiled with IBM's MASM, not
MicroSoft's.  I have fixed the incompatablitiy that generates compile
errors and it runs.  However, perhaps it is responsible for the problems I
still have:

None of the `sub-process' commands work: DIR, RUN, etc.

I end up in a sub-COMMAND processor that complains `Ilegal COMMAND path' or
some such.  The environment is not being passed.  I have traced through
the bloody thing to the EXEC command.  And it looks IDENTICAL to calls that
work in some of my programs.

Does anyone have it working?  Does anyone have a version that compiles
with Microsoft MASM and works?

                    ---Mark Mendel
                    ---ihnp4!umn-cs!digi-g!mark

[Ed. - First, make sure that your PATH environment variable is set to
include the areas where the sub-process are to be found.  If the problem
persists, it may be that your assembler/linker combination orders the
segments differently from the IBM assembler/linker; try including the dummy
module MSXDMB in your linking sequence, to ensure that the segments are
ordered correctly.]

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

Date: 6 Nov 1984 14:14-EST
From: [e-mail]
Subject: MS-DOS Kermit V2.26 Key Definition
To: Info-Kermit@CU20B

I am currently using Kermit V2.26 and would like to know if there is
any way to define a key using the SET KEY command within a TAKE file.

Thus I would like

SET KEY SCAN 83
\177

The problem is that take uses the backslash itself.  Quoting the
backslash with another one does not work.  Also, \134177 does not work
for the obvious reason.  \134 177 does not do what I want.

(The 134 is octal for the backslash, 177 for delete.  I am trying to
have the delete key send a delete.)

Any help would be appreciated.

Israel Pinkas ([e-mail])

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

Date: 6 Nov 1984 14:14-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Re: IBM-PC Kermit V2.26 Key Definition

First of all, there's nothing wrong with your first SET KEY definition.
It works just fine for us on a variety of machines, and should work for you.
TAKE doesn't do anything special with backslashes.

Here are a few fine points about the current operation of MS-DOS Kermit 2.26
key redefinition:

. Unlike Unix, MS-DOS Kermit does not accept "\\" as a quoted backslash.  To
  include a backslash, specify \134.

. Backslash-quoted quantities cannot be concatenated directly with digits,
  because the boundary is ambiguous.  For instance, to specify a backslash
  followed by the characters "177x", you could not use \134177x.  Nor could
  you use \134 177x, because the space would be included.  Instead, you must
  use:

    \134\61\67\67x

  (the digit "1" is ASCII 61 octal, the digit "7" is ASCII 67).

. You may include a SET KEY SCAN command in a macro definition this way:

    SET KEY SCAN 270,foo

  The macro expander interprets literal commas as carriage returns.  To
  include a comma as part of your macro definition, use \54 as in

    SET KEY SCAN 271,foo\54bar

  which defines the key to send "foo,bar"

Although the next release of MS-DOS Kermit might fix the key redefinition
code to "break" after the 3rd digit following a backslash, the procedure
shown above would still be preferable, since it is unambiguous to the reader
as well as to the program.

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

Date:  Thu, 8 Nov 84 20:00 EST
From:  [e-mail]
Subject:  MSDOS (PCDOS) Kermit vs 8251 Chip
To:  [e-mail]

Are there any PCDOS implementations that use the 8251 instead of the 8250 chip?

The DG/One is a portable (i.e., lapsize) IBM clone except that the
communications processor is an 8251 rather than an 8250 as in the IBM PC.

[Ed. - This doesn't make the DG/One very compatible with IBM PC software like
Kermit that has to handle interrupts from the serial i/o chip...]

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

Date: 3-NOV-1984  21:47 CST
From: [e-mail]
To: [e-mail]
Subject: MS-DOS Kermit CRC Problems

I have found what appears to be a bug in MS-KERMIT ver 2.26.  Talking to VMS
Kermit ver 2.0.027 with server mode, I downloaded files to MS-KERMIT using the
CRC block check (I set the packet size down to 93 chars as you suggested).  It
worked ok until I turned debug mode on in MS-KERMIT; then all downloads failed
by exceeding max retry count in packet 2.  Downloads continued to fail even
after turning debug mode back off.  However, when I told the Vax not to use the
CRC, downloads worked.  Downloads with CRC also resumed working when I brought
up a fresh copy of MS-KERMIT on the PC.

There seem to be other circumstances that cause MS-KERMIT to fail similarly,
but I haven't determined what exact parameter settings or sequence of events
produce them.

Is there a file of known bugs in MS-KERMIT that I can get access to?  It would
help my implementation task considerably.  Also, are you planning a new release
in the near future?

                                                            Dave Slate

[Ed. - See below.]

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

Date: Wed 7 Nov 84 10:32:44-EST
From: Daphne Tzoar <[e-mail]>
Subject: Re: [[e-mail]: MS-KERMIT problems]
To: [e-mail]

It sounds like debug mode overwrote the end of the buffer for the incoming
packet in packet number 2, the first data packet (init and filename packets
weren't long enough to do that).  And the buffer just happens to be followed by
the CRC table.  So, even though he turned off debug mode, the damage was
already done and the CRC table was overwritten with the dollar sign used to
print the packet (or so is my guess).  Then when he stopped using the CRC or
started the new MS Kermit, it was all OK.  That problem will hopefully go away
when we enlarge the buffer size for incoming packets.  I will verify that this
really was the problem though.  /daphne

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

Date: Fri 9 Nov 84 10:32:44-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: MS-DOS Kermit 2.26 Bug List
To: Info-Kermit

Here's a very brief summary of the known or reported bugs in MS-DOS Kermit,
version 2.26.  Most of them will be fixed in 2.27, coming soon.  This list
is also available in the file KER:MSKERMIT.BWR.

LEA's should be changed to MOV ..,OFFSET or to LEA ..,WORD PTR in msfile.

Build instructions should include linking with MSXDMB module to ensure
segments are arranged in the right order.

Must build all versions with MSXDMB module to ensure segments correctly
ordered.

Set dest printer should be fixed to use PRN, not LPT1.

In Rainbow, should save character attributes in prev/next screen.

In Rainbow, prev/next screen sometimes overshoot.

In IBM H19 emulation, tabs shouldn't be destructive.

on IBM, Insert/Delete line can mess up the screen because scrolling
one line with the ROM calls does funny things.

on IBM, carriage returns in inverse video mode shouldn't scroll
inverse lines onto screen (? this is why MORE acts funny)

On Rainbow, break should really be 275 msec.

On IBM, echo in status line display is backwards.

On IBM, when reading from keyboard, should strip eighth bit, since
these can make command parser crash.

Set key scan <space><space><return> doesn't work properly.

Make \ooo interpreter break after 3 digits (it already breaks at the
first non-digit).

Return key to retransmit packet undocumented in display.

At RDAT33, should check to see if dest is printer and put a ^Z if so,
regardless of EOF mode, so buffer isn't printed twice (someone sent
this one in; we should make sure it's really the problem).

No way to set Heath wrap on/off.

Rainbow set baud command missing.

SET EOF CTRLZ doesn't work.

Someone claims that an unquoted 0 byte gets put into the data field of
all F and D packets, because of a bug in encode.

On IBM, the checking for the keypad plus key should be moved so it can
be redefined.  Also, use of the + key to toggle the mode line is undocumented.

Kermit should keep the rainbow out of VT52 mode.  Also, it should
resist attempts to send $8 and $c to the firmware, since they crash
it.

On rainbow, Cursor keys should be fixed - they get changed as well as
the keypad with esc =.

In inpkt, don't start filling the buffer until the SOH is detected, to
protect against buffer overruns.

When an SOH is detected, make sure packet is started again.

Discard packets if they're the same type as what we just sent in case
hardware echoed it back.

Enlarge the input buffer size to prevent "off-by-one" errors that
can overwrite critical data, like the CRC table.

Renaming code sometimes overwrites original name?

Abort code should close open files if set incomplete keep is on.

SHOW MACRO should be SHOW MACROS.

Check table overflow code in set key.

Generic DOS Kermit doesn't always ask for port numbers on new machines;
need to add SET PORT [device|file-handle] ...

[We have also kept all the bug reports we've received by mail, so if
your pet bug doesn't appear in this list, we still have it.]

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

Date: Wed 24 Oct 84 07:57:12-PDT
From: Jim Celoni S.J. <[e-mail]>
Subject: More on Concurrent PC DOS 3.2
To: [e-mail]

To correct what I said Saturday:  Concurrent PC DOS 3.2's REDOES command *is*
documented, at the end of the file hdmaint.doc on one of the distribution
disks.  While reading my mail yesterday, I discovered that when run under
CDOS, Kermit 2.26 drops many incoming characters (5-10%?)--my guess is that
the screen writes via "DOS" don't all work but the direct ones (more common
in Emacs) do.  File transfers work fine, though two have ended early with
a message about "F" not being a valid server command.

I regret the error.  +j

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

Date: 8 Nov 1984 1720-EST
From: LCG.KERMIT
To: EIBEN
Subject: Kermit for Convergent Technologies C3

I HAVE BEEN USING A VERSION 1.0 KERMIT HERE BETWEEN IBM PC/XT AND OUR DEC-10
FOR A WHILE.  I BUILT A C3 (CONVERGENT TECHNOL.) KERMIT FROM THE PC VERSION AND
IT WORKS WELL WITH DEC-10 VERSION HERE.  MY PC/XT VERSION SUPPORTS HAYES WITH
AUTO-DIALING AND HAS A AUTO-LOGIN FEATURE (FOR OUR DEC-10). THE C3 VERSION
WORKS WELL AND HAS BEEN LOADED ONTO A BURROUGHS B-20 AND WORKS (B-20, C3 ARE
ALL CONVERG. TECH. MACHINES).IF I GET MY KERMIT TO WORK WITH YOURS I WILL
SUBMIT THEM.

        JEAN R. ROY, DOT/TSC, KENDALL SQ., CAMB. MA.
                494-2064 OR 494-2344
                TSC COMPUTER CENTER

[Ed. - Will announce this if it ever shows up.]

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

Date: Tue 6 Nov 84 15:21:29-EST
From: [e-mail]
Subject: Kermit on the NEC 8800
To: [e-mail]

I've been trying to get kermit-80 v3 up.  I've changed the defio to 81H and
batio to 42H in the generic version.  It seems that I can send stuff to
the COMM port OK, but that I do not get anything back.

Any help, ideas, working versions of kermit for NEC etc would be
appreciated.

thanks in advance.

[Ed. - See next message]

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

Date: Tue 6 Nov 84 21:50:59-PST
From: Ronald Blanford <[e-mail]>
Subject: Re: Kermit on the NEC 8800
To: [e-mail]

I used Kermit with an older version of the 8800 and had no problems, but
later when I was doing it with a more recent model I found that the BAT:
device as implemented by the new version of CP/M did not support the
console status call.  In other words, the status always returns not ready
for the serial port so no input occurs.  It was necessary to patch
CP/M to get it to work.

Your numbers for batio and defio are fine, although the defio is not
critical since that is replaced by the current iobyte value when Kermit
is loaded.

-- Ron

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

Date: Tue, 6 Nov 84 10:22:55 EST
From: decvax!mulga!stephenw.murdu@Berkeley (Stephen Withers)
To: [e-mail]
Subject: TurboDos Kermit

A couple of issues ago there was a request for a TurboDos Kermit - well,
one of our users (Rod Van Cooten) has modified Kermit-80 to run on
TurboDos versions 1.22 and 1.3.  The modification assumes that the
implementation of TurboDos includes the communications driver calls.

If this is of interest, let me know and I should be able to arrange for
a copy to be sent to you.

Steve Withers
Computer Centre, University of Melbourne.

[Ed. - Will announce this when it arrives.]

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

From: decvax!mulga!robin.deakcm@Berkeley
Date: Thu, 8 Nov 84 14:14:38 EST
To: Info-Kermit-Request%CU20B%COLUMBIA.ARPA.mulga@Berkeley
Subject: Kermit for Compugraphic Photocomposer?

Does anyone out there in the swamp have a version of Kermit that will run on
an MCS COMPUGRAPHIC photo-typesetting system? Everybody and his dog here is
writing their theses, books, lecture notes etc. etc using bloody Wordstar on
CP/M systems, and they seem to expect the Compugraphic to be able to somehow
magically read their wierdo disk formats (and Wordstar format files to boot
- but that's another story) so they can get the stuff photoset.  An MCS
Kermit would at least solve the filetransfer problem!

[Ed. - Is it possible to program this thing?  The only Compugraphic
I've heaard about (the 8600?) was designed to communicate only with
its own built-in "data entry stations", with only a paper tape reader
for the outside world, and was not programmable.]

Thanks for all the good work! I hope we can make some contribution next year
- possibilities are Hitachi Peach and S-1 versions (8-bit systems that I
understand aren't on the US market, but are reasonably common here.)

Regards,

Robin Simpson
Computer Centre
Deakin University
GEELONG, Victoria
Australia

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

End of Info-Kermit Digest
*************************
-------
16-Nov-84 19:21:37-EST,10073;000000000001
Mail-From: SY.FDC created at 16-Nov-84 19:21:14
Date: Fri 16 Nov 84 19:21:14-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #38
To: [e-mail]

Info-Kermit Digest         Fri, 16 Nov 1984       Volume 1 : Number 38

Departments:

  MS-DOS KERMIT -
    Kermit 1.20 for ACT Apricot
    Second Version of TI-Pro Support for MS-DOS Kermit 2.26
    Enhanced NEC-APC Module for MS-DOS Kermit 2.26
    Kermit for Sanyo PC

  MISCELLANY -
    New DEC-20 Kermit
    Kermit for BBC Micro
    UUCP Login to okstate

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

Date: Wed 14 Nov 84 16:41:44-EST
From:
 Johan Ph. Kelders
 Rekencentrum der Rijksuniversiteit
 Postbus 800
 9700 AV Groningen
 The Netherlands
Subject: Kermit for ACT Apricot
To: [e-mail]

Recently I have adapted Kermit for the ACT (Applied Computer Techniques)
Apricot computer, using the IBM-PC/Z100 version (1.20).  The program has been
used by several people for some time now and has been functioning very well,
with speeds up to 9600 baud.

There are many small changes and only a few larger ones, so it seems the best
if I describe in general what the changes are along with sending you a floppy
disk with the complete source text.  There are four kinds of changes:

- The Apricot has a software interface to access its devices (or the drivers)
which is called the Control Device.  It can be used to set baud rate,
bits/character, etc, at the serial port.  It can also be used to input
characters from the serial port or to return a code indicating no character is
present.  The calls to the Control Device you will find in a separate setup
routine APRSET at the end of the source, in the baud rate setting routine and
in two places where input from the serial port is done.  For output to the
serial port, the DOS function 4 (auxiliary port output) is used.

- The escape sequences for screen cursor control are the same for the Apricot
as for the Z100, so these conditionals have been combined (IF Z100 OR
APRICOT...).

- Sending a BREAK is not possible when using the Control Device, so this has
been suppressed (the command has no effect).  To send a BREAK could be doine by
controlling SIO directly, but then the whole serial port driver would probably
have to be rewritten.

- The "standard" keyboard cannot generate CTRL-] or CTRL-\ and some other codes
like that.  However, you can completely redefine every key, so at startup of
Kermit the appropriate escape sequence is sent which defines CTRL-] to send
just that.

An adaptation which has been done but left out of this version is the setting
of the modem control lines, such as DTR, CTS.  This can be done outside Kermit
by changing the BIOS parameters on disk with a setup program or by using a
program called SERIAL.

I hope the descriptions together with the source code will enable you to
include the changes in the next version of Kermit.

[Ed. - The source is in KER:APRICOT.ASM.  There is also an APRICOT.BOO file,
for downloading with MSBOOT.FOR/MSPCBOOT.BAS or MSPCTRAN.BAS.  The 8-bit
binary file is in KB:APRICOT.EXE.  Any volunteers to adapt all this into
the version 2 MS-DOS Kermit modular style?]

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

Date: 12 Nov 1984 2127-EST
From: LCG.KERMIT
To: EIBEN
Subject: REV 2 of TI-PRO KERMIT

I uploaded MSXTIPRO.ASM, .BWR; MSTIPRO.HLP, .EXE, .BOO.  This one has the
previous bugs fixed, I am still working on revision 3.

Joe Smith, CSM Computing Center, Golden CO 80401 [phone]

[Ed. - It's available on CU20B.  The .ASM, .HLP, .BOO, and .BWR files are in
KER:, the .EXE file is in KB:.  According to the implementation notes, revision
3 of the TI support will include faster port i/o (interrupt-driven rather than
polled) and graphics terminal emulation (Tek 4010 and/or Regis).]

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

Date: Wed, 14 Nov 84 06:24:12 pst
From: dual!islenet![e-mail]
To: Info-Kermit@CU20B
Subject: Enhanced NEC-APC module for MSKERMIT

    Here is an enhanced MSKERMIT 2.26 system module MSXAPC.ASM for the
NEC-APC. I took Ron Blanford's fine working module for a start, and then
added full key scan-code redefinition, auto-determination of color/monochrome
for CRT formatting, direct video access for faster help menus, and a
scroll/noscroll key that sends ^S and ^Q alternately.

To make things compatible with the APC operating system, I had to make two
minor changes to the MSTERM module - these are detailed below. Also I picked
up what appeared to be a bug in MSCMD that causes a system crash if the user
attempts to enter a key definition string longer than 127 characters -
a fix that catches the problem and gives an error message is given below.

The full code for the MSXAPC module and a brief updated APC help file are
appended.

Ian Gibbons, U of Hawaii

[Ed. - Since changes to the other modules are involved, I can't install it
just yet.  It should be part of the next release, 2.27, soon to appear.  This
announcement is included as a public service to anyone else who may have been
contemplating doing these things.]

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

Date: 09 Nov 84 21:30 +0100
From:
 [e-mail]
To:
 [e-mail]
Subject: Kermit for Sanyo PC

Has anybody heard of a Kermit for the Sanyo?  I would endeaver to modify the
IBM PC version but I can get no documentation on the Sanyo except for a very
superficial user's guide.  This is not enough to do a Kermit.  I would be glad
(and so would a lot of users here) if this had already been done.

[Ed. - See below for an answer.  By the way, it's not usually a good idea to
mail directly to "Info-Kermit-Members", since this makes the message go to each
of the several hundred individuals, bboards, and mailing lists on the
Info-Kermit distribution list, and ties up many mailers for a good while.  The
"To:" address of this message apparently includes Info-Kermit-Members@CU20B;
better to mail to Info-Kermit.]

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

Date:         Tue, 13 Nov 84 18:13:12 EST
From:         Peter DiCamillo <CMSMAINT@BROWNVM>
To:           Info-Kermit@CU20B
Subject:      Kermit for Sanyo PC

The same day I read the mail requesting Kermit for the Sanyo, I received in
the mail a letter from

     Solution Software
     3421 N. 1st Ave. #120
     Tucson, AZ 85719
     [phone]

It begins:

"We would like to bring your attention to a new micro-mainframe
communications program for the IBM PC, Sanyo MBC 550 series, and
compatibles. This program, called VersaCom, includes the following:

VT100 Emulation
     [description]
Large Capture Buffer
     [description]
Programmable Keys
     [description]

Kermit
     This is a file transfer protocol for transfers between different
types of systems. It includes eighth-bit quoting for transferring
binary files, and repeat-count quoting which allows compression of
data as it is transmitted.

Xmodem
     [description]
System Requirements
     Versacom is available for the IBM PC and the Sanyo MBC 550
series. It requires 128 Kbytes of RAM and a standard serial port.

     VersaCom, along with 45 pages of documentation, is available from
Solution Software at the above address. The cost is $35 plus $5 postage and
handling. Demo copies are available for $10."

I've never heard of Solutiion Software or VersaCom before. I hope you will
find this information helpful.
                                              Peter

[Ed. - We've granted permission to a number of companies to include Kermit
in their terminal emulation or multi-protocol file transfer packages under
the conditions listed in KER:COMMER.DOC.  However, this is one company I
don't recall.  Thanks to everyone who responded with messages about this
product.]

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

Date: Thu 15 Nov 84 19:14:37-EST
From: Frank da Cruz <[e-mail]>
Subject: New DEC-20 Kermit
To: [e-mail]

Two minor changes:

(1) A bug with ITS binary files is fixed (thanks to Keith Peterson for
    tracking it down).

(2) The (local) CWD command now behaves exactly like the Exec CONNECT
    command -- it doesn't prompt you for a password unless it really needs one.

Source in KER:20KERMIT.MAC, binary in KB:20KERMIT.EXE on CU20B.  The new
version is 4.2(253) and replaces 4.2(251).  - Frank

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

Date:     Mon, 12 Nov 84 10:52:31 GMT
From:     [e-mail]
To:       [e-mail]
Subject:  Kermit for BBC Micro

     UCL is intending to use Kermit to a substantial extent for file transfers
between unix (11/44 & VAX) and various micros, including BBC.

     We have every intention of putting up a Beeb version.  The job has been
assigned to a chap starting work tomorrow (13th).  I am not in charge of this -
it comes under C/S's communications group, headed by Rob Cole.  If you want to
know more about the status of this, I suggest you mail him as "robert@ucl-cs".

                    Chris Kennington.
                    University College London

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

Date:     14 Nov 84 22:26:37-CST (Wed)
From:     Mark Vasoll <[e-mail]>
To:       Frank da Cruz <SY.FDC@CU20B>
Subject:  UUCP Login to okstate

It seems that there may be some confusion about the UUCP login account on
our system.  The account is for UUCP connections, not regular human users
(i.e. you will not receive a command prompt, you will be placed into the
UUCP protocol).  I have had several login attempts where no work was
exchanged, I suspect that people are trying to "look and see" what's here.

You might want to pass this along to the Info-Kermit members.

Mark

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

End of Info-Kermit Digest
*************************
-------
28-Nov-84 22:09:44-EST,26722;000000000000
Mail-From: SY.FDC created at 28-Nov-84 22:09:26
Date: Wed 28 Nov 84 22:09:26-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #39
To: [e-mail]

Info-Kermit Digest         Wed, 28 Nov 1984       Volume 1 : Number 38

Departments:

UNIX KERMIT -
  Unix Kermit Update
  Kermit UUCP Downloading Update
  USENET Distribution of Info-Kermit

MS-DOS KERMIT -
  PCDOS/MSDOS Kermit suggestion
  Kermits For Weird Semi-IBM Compatible Machines
  Kermit bugs/inconsistencies (several messages)

VAX/VMS KERMIT -
  DIAL command for VMS KERMIT
  Bug Reports, Questions, Answers (several messages)

MISCELLANY -
  TELENET PAD Parameters for Kermit
  CMS Kermit and Non IBM Controllers?
  VersaCom
  ITS Binary Files vs Kermit
  Kermit for Burroughs XE-520 / B25 (BTOS op sys) wanted
  MacKermit connect mode
  Mac Kermit initialization & other bugs
  Apple 2c design flaw.
  Commodore 64 Kermit V1.1 on the way

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

Date: 28 Nov 84 21:15:00-EST
From: SY.FDC@CU20B
To: Info-Kermit
Subject: Unix Kermit Update

Although far from ready for release, some progress has been made on the
new (version 4) Unix Kermit.  Repeated-character compression and 8th-bit
prefixing have been added, along with server mode and execution of host
commands.  The program has been partially decomposed into modules.  The
development has been done so far only under 4.2BSD and Pro/Venix, but the
support code that was contibuted for Sys III, Sys V, v6, etc, is on hand
and will be parcelled out into system-dependent support modules.


This program differs radically from other Kermit programs in structure;
the protocol module is an actual state table written in the input language
of the Unix lex program, with statements of the form

<current-state>input {action}

allowing the operation of the program and the protocol itself to be clearly
laid out in several pages of text.  The actual release will use a similar
technique, but will not use lex because it's proprietary.

As soon as we have a version that's ready to test, it'll be announced.

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

Date:     16 Nov 84 17:50:12-CST (Fri)
From:     Mark Vasoll <[e-mail]>
To:       Frank da Cruz <sy.fdc@cu20>
Subject:  Kermit UUCP Downloading Update

I have created a file on our system that contains a directory of /u/kermit
(the Kermit distribution area) since many uucp users do not have a list of
the available files.  The file is /u/kermit/00directory and can be uucped
from our system (it seems like a very boring thing to post...).  We were
having some trouble with the wildcard transfers (they aren't working...),
so things like "uucp okstate!/u/kermit/ux* dir" were failing.

The problems with wildcard transfers to systems that are not in our L.sys
file have now been solved.  The UUCP Kermit distribution should be able to
proceed without problems now.

Mark Vasoll
Oklahoma State University

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

Date: Sat, 24 Nov 84 19:31:21 pst
From: fair%ucbarpa@Berkeley (Erik E. Fair)
To: [e-mail]
Subject: USENET Distribution of Info-Kermit

Add

    [e-mail]

and let your readers know that as of now, INFO-KERMIT is being
gatewayed to the USENET, so they don't have to (in fact, shouldn't)
directly subscribe to the digest if their host is on the USENET.

If there are any problems, please let me know.

    Mr. USENET for UCBVAX,

    Erik E. Fair    ucbvax!fair    [e-mail]

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

Date:  Mon, 19 Nov 84 22:40 EST
From:  [e-mail]
Subject:  PCDOS/MSDOS Kermit suggestion
To:  [e-mail]

In looking at how to implement support for the 8251 chip in the
DG/One, it would be simpler if the MSXIBM module attempted to
use the IBM BIOS calls whenever possible.

This would allow variations to be more easily supported.

I realize that the BIOS does not allow full initialization when
one is using interrupts, but it does allow standardization of
the baud rate setting (except for 19200 and 38400 which the
program doens't support anyway (why not?)) as well as other
basic initialization.

This would be a useful change for 2.27 if it is not too late.

[Ed. - See next two messages.  There were some other problems with
the BIOS too, like not letting you choose all the common baud rates,
e.g. 1800.]

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

Date: Tue 20 Nov 84 11:09:37-EST
From: Daphne Tzoar <[e-mail]>
Subject: Re: PCDOS/MSDOS Kermit suggestion
To: [e-mail]

 I disagree -- the whole point of the system independent modules is
 to take advantage of the best way to do certain functions in each
 micro.  That's why we don't just use DOS for i/o -- it's too slow
 to run at anything faster than 1200 and why we need system dependent
 interrupt driven routine for reading in characters.
/daphne

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

Date: 20 Nov 1984 1222-EST
From: LCG.KERMIT
To: EIBEN
Subject: Kermits For Weird Semi-IBM Compatible Machines

I saw on the kermit news some queries about Kermit for DG/1.  While
this isn't really very good, it'll have to do.  The version of Kermit
I did for Seequa Chameleon is from an old (v1.18) pckermit, but is
super generic.  It calls the ROM BIOS (int 14) to do all serial
communications.  This was needed because the Seequa machine uses an
8274 multi protocol controller instead of an 8250, so is totally
different from IBM.  (At the time I did the Kermit, I had no specs
on the 8274.)

Therefore I did everything via int 14h so as long as the BIOS
used emulates the IBM BIOS (which it pretty much must to allow print),
the Kermit will work.  You have to use MODE first to set the port
baud rate, and then establish the connection (or fake it with Smartmodem
switches), and then run the Kermit to use same, and the Kermit assumes
ANSI.SYS is loaded.  But it will work at up to 1200 baud.  It will even
run on an IBM PC.  But anybody with one of these near-compatibles
can use it (KER:SEEQUA.ASM) until I get around to modifying
the 2.26 version for similar operation.  I've tried the generic Kermit
on the Chameleon withoug too much luck (under PC-DOS 2.0).  I may try
again with 2.1, but I get easily frustrated by having to power down
and back up to continue, so I will more likely just fix the new
Kermit.  I have a need VT52 initializer now for 2.26 that sets up the
whole VT52 keypad, allowing me to TECO etc.

    Thanks.
            Glenn Everhart


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

Date: 24 Nov 1984 1408-EST
From: LCG.KERMIT
To: EIBEN
Subject: Kermit-MS bugs

Persons:

We have several IBM ATs and XTs running Kermit-MS V2.26 connected to
a Vax 750 running Kermit-32 V3.0.052.

We are running the newest version of Kermit-MS V2.26, the one that
doesn't go from 63K to 1024K on file transfers. This was downloaded
from DEC.

We have found several bugs and inconsistencies in the Kermit-MS V2.26:

    1. Take requires a full pathname even though all other references
       to files (in send and get) only take filenames.
        Example:    Kermit-MS>take foo        ; FAILS
                Kermit-MS>take \usr\mth\foo    ; SUCCEEDS

    2. Running Kermit-MS piping from stdin works partially. Stdin gets
       disconnected whenever you go into the terminal emulator or when
       you get prompted for a password (REMOTE CWD).
           Example:    Kermit-MS>remote cwd [foo.bar]
                 Password:
       Additionally, Kermit-MS does not quit on end of file. You must
       put in a QUIT command at the end of the file, or reboot the
       system.

    3. REMOTE commands touch the floppy disk drive for no apparent
       reason.
           Example:    Kermit-MS>remote dir    ; spins up A:
       This means that you have to have a floppy in the drive or MSDOS
       gives you an "Abort, Retry, Ignore?" message.

    4. If a REMOTE HOST command executes without doing any output,
       Kermit-MS does a core dump to the screen and the system must
       be rebooted.
           Example:    Kermit-MS>remote host set def [foo.bar]

Thank you,
Michael T. Howard

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

Date: Tue 27 Nov 84 16:37:00-EST
From: Daphne Tzoar <[e-mail]>
Subject: Re: MS ? KERMIT bugs/inconsistencies
To: [e-mail]

  I think the problem with the path is that we don't check the current
  directory at all if it's not in the path.  That has to be fixed. And
  the last problem is fixed for release 2.27.  We did a "close file"
  call at the end of every receive (and remote commands that write to
  the screen.)  Well, the PC and the XT never complained about a close
  call for a file not physically on the disk and the AT does.  I'm not
  sure about the second problem though.
/daphne

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

Date:        27 Nov 84 18:55 +0100
From:        [e-mail]
To:          Info-Kermit <info-kermit@COLUMBIA-20>
Subject:     Bug in MS-KERMIT?

There seems to be a bug in IBM PC Kermit ver 2.26 that makes
it bomb with "?Program error   Invalid COMND call" after dumping
some garbage on the screen.

To conjure the bug, have a line like

        define foo take foo.cmd

in MSKERMIT.INI (where FOO.CMD contains a couple of

        SET KEY F1
        DoThisCommand
        SET KEY F2
        DoThatCommand
etc.)

To conjure the bug, DO FOO a couple of times, and say
SHOW KEY
<f1>
after each try.

[Ed. - This is probably the SET KEY buffer overflow problem, which should
be fixed in 2.27.]

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

Date: Thu, 22 Nov 84 05:53 PST
From: [e-mail]
Subject: DIAL command for VMS KERMIT
To: [e-mail]

Frank:

Some time ago I implemented a DIAL (and REDIAL and HANGUP) command for
VMS KERMIT and the DEC DF03 modem.  These commands are probably only of
marginal use to other sites, but I thought I'd share them with you.

Since I'm not directly on the ArpaNet (and thus people cannot FTP the
files) I have included the output from the VMS DIFFERENCES utility here.
I have also mailed (in a seperate message) the appropriate SLP command
files to make the changes.

If you'd like, I will mail you the updated sources.

Enjoy...

gkn

[Ed. - The files, which are too long to be included in mail, are in
KER:VMSDIAL.DIF and KER:VMSDIAL.SLP.]

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

From: lhasa!mghccc![e-mail]
Date:     21 Nov 84 09:57 EST
To: lhasa!harvard![e-mail]
Subject:  BUG IN VMS KERMIT

I have found what appears to be a bug in the VMS version of KERMIT (version
3.0.051) which occurs when it is attempting to SEND a file, in my case, to the
UNIX C KERMIT (uxkermit on the distribution tape, running on a Masscomp MC500
system). The transfer proceeds to completion, the end-file packet is processed
on the receiver (and the file is OK there).  The sender then runs into an RMS
problem and displays the message

KERMIT-E-RMS32, %RMS-F-IFI INVALID INTERNAL FILE IDENTIFIER. (IFI)
This is the result of a RMS $SEARCH operation just after entry point NEXT_FILE.

This occurs irrespective of whether the sending KERMIT is local or remote.

I reassembled and linked KERMIT with DEBUG (from the MACRO sources, since
we don't have BLISS) and found that the call to NEXT_FILE is not preceded by a
call to CLOSE_FILE ; since the $SEARCH operation has to be done on a FAB with
an inactive (closed) file I assume this is the cause. Oddly enough,
VMS-Kermit to VMS-Kermit works just fine (!), and there I do
see a call to CLOSE_FILE at the end of the file transfer on the sending
KERMIT, just prior to the NEXT_FILE call.

    I performed file transfers with the UNIX Kermit and an earlier
version of VMS KERMIT (6/83 or so) and there are no problems there .


I guess this is a request to anyone out there using VMS KERMIT for help.
It's not easy to unravel the MACRO code that BLISS generates so I'd
appreciate any leads.

            Thanks in advance,

            Simon Rosenthal
            Cardiac Computer Center
            Massachusetts General Hospital, Boston MA

Phone: [phone]
ARPA: lhasa!mghccc![e-mail]
USENET: harvard!lhasa!mghccc!simon


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

Date:     Monday, 26 Nov 84 10:23:05 EST
From:     nbush (Nicholas Bush) @ sitvxb
Subject:  Re: [lhasa!mghccc![e-mail]: BUG IN VMS KERMIT]
To:       <SY.FDC@CU20B>, lhasa!mghccc!simon%harvard @ cu20b

There is a problem in version 3.0.051 of VMS Kermit which shows up as
RMS IFI errors when talking to some other Kermits.  The problem is due to
the buffer for packets being sent is too short if the maximum size packet is
in use.  A simple work around is to do a SET SEND PACKET_LENGTH command before
doing a transfer.  To fix the problem in the souce, the length of the buffer
SND_MSG must be increased.  This can be done in the BLISS source by increasing
the value of MAX_MSG by 5.  In the MACRO-32 source, the length in the .BLKB
psuedo-op for SND_MSG can be increased by 5.

This problem is fixed in the next version of VMS Kermit.

- Nick

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


Date: 26 Nov 1984 0117-EST
From: LCG.KERMIT
To: EIBEN
Subject: VMS Kermit (BLISS version)

I have run into couple of bugs in the VMS kermit. Here they are:

1. Often I set host from one machine to another over decnet and run kermit
on the latter machine because the latter has an internal modem. When I tell
kermit to CONNECT to the line that has the modem, it puts out the message
stating that it is connecting. But then instead of establishing and maintain-
ing the connection, it immediately comes back with the message "returning
back to vms kermit". If I attempt connecting again, kermit aborts with an
opcode fault and the vms runtime message "NOMSG, message number 000000".
Here's the sequence of DCL commands that illustrate the problem:

    $! Assume that I am logged on machine A, I do a set host to
    $! machine B. B has an internal modem.
    $ SET HOST B::
    $ KERMIT
    kermit-32>connect txa7:
    [ connecting to b::txa7: type cntl-] C to return to kermit ]

    [ returning to b::tta0: ]
    kermit-32>connect txa7:

    KERMIT32-E-NOMSG message number 000000
    <trace back shows up next>

    $! back to DCL.

If I log on B directly, i.e, not through decnet, after I issue the connect
command, everything works as it is supposed to: I am able to talk to the
modem and tell it dial a specific number, and the rest. It is only when I
am going through decnet, the problem arises.

2. During file transfers, if I tell vms kermit to send a file and the file
description has some kind of an error in it, e.g,directory name that is
too long, or the file has world read permission while the directory the file
resides in does not have world read permissions, kermit aborts with a
forced exit by vms. Try the send command like:

    $ kermit-32>send dra0:[guest.tomdickandharry]foo.bar

"tomdickandharry" is too long for a subdirectory name. Kermit will catch the
error in the directory name. Instead, it'll abort.

3. I sometimes log on one of our pdp's running ultrix-11 and use the unix
kermit to tranfer things between vaxes running vms. When I log on ultrix and
then log on a vax using ultrix kermit (i.e, kermit clb /dev/cua0 1200, where
/dev/cua0 is an auto-dial modem), and then tell vms kermit to send a file, the
file comes over fine, but something causes an RMS IFI (Invalid internal file
identifier error) in the vms kermit. I can ignore the error when I tranfer
one file at a time. The error however prevents me from using the wildcard
option when sending files, e.g, "send *.pas", or sending a bunch of files
as in "send prog.pas prog.dat prog.lis". The error occurs after vms kermit has
sent over "prog.pas" which then inhibits kermit from sending over the remaining
fils. The most recent version of unix kermit, and the one before it, both cause
the error. However when I send a bunch of files from ultirx to vms, everything
works fine.

Thanks,
    Nancy Prohaska
    KS1


[Ed. - Bob McQueen of Stevens says:
"Problems 1 and 2 should be fixed in the current field image of Kermit-32.
Problem 3 is fixed and it is my understanding that you have a work around
for it.  We will work toward getting a Kermit-32 3.1 out which contains the
fix to the RMS IFI problem and also has a TAKE command."]

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

Date:     Tue, 20 Nov 84 11:20:10 CST
From: Paul Milazzo <[e-mail]>
Subject:  PAD Parameters for Kermit?
To: [e-mail]

Can anyone tell me the exact PAD (and ITI?) parameters necessary to
make Kermit work over Telenet?  I've had no luck at all with it.  If it
matters, I'm connecting to a UNIX host from a CP/M system, and have the
latest Kermit for each.

                Thanks,
                Paul G. Milazzo <[e-mail]>
                Dept. of Computer Science
                Rice University, Houston, TX


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

Date:  Tue, 20 Nov 84 13:20 EST
From:  "John C. Klensin" <[e-mail]>
Subject:  Re: PAD Parameters for Kermit?
To:  Paul Milazzo <[e-mail]>

There are several combinations that appear to work under various
circumstances, and some Telenet PADs have historically been more fussy
than others, resulting in some confusion.  Usually, if your host can
tolerate it (UNIX can, I would think), you want to set Xon/Xoff to the
PAD and in kermit.  For the PAD, that is

   SET 5:1,12:1

in order to get both input and output flow control.

The other little trick, which has nothing to do with PAD settings, is
that Telenet does not get on well with the transmission of binary data,
and seems to like parity=mark in many cases.  For some reason, it often
also accepts even, odd, and space parity, as long as you don't try using
the high bit to pass information.

This is the sort of situation that leads to LOTS of superstitious
behavior.  Good luck.

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

DATE: THURS, 15 NOV 1984
FROM: ATSBDN AT UOFT01
TO: SY.FDC AT CU20B
SUBJECT: CMS KERMIT AND NON IBM CONTROLLERS

Does anyone have any info on using CMS Kermit with a CCI controller that
emulates a 2705, except that it runs the ASCII lines in full duplex?
Also, how's the Yale IUP modifications coming along?  For our system
we really need the Yale interface.
                                            Thanks, Brian

[Ed. - As reported here, a couple sites already have Kermit working through the
Series 1, apparently using different techniques.  We are looking into their
approaches, and hope to have a version of CMS Kermit that does this at some
point in the future.  I don't see why the CCI controller would present any
special problem, since full duplex operation (i.e. host doesn't echo) is just
right for Kermit file transfer.]

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

Date: Wed 21 Nov 84 13:38:09-EST
From: Frank da Cruz <[e-mail]>
Subject: VersaCom
To: [e-mail]

I've received a letter from Solution Software, which is selling a product
called VersaCom that does VT100 terminal emulation on the IBM and Sanyo
PC's, screen capture, and Kermit and Xmodem file transfer.  They say they
adapted the current Unix Kermit code, added 8th bit quoting, repeat
counts, and keyword style command parsing, and they will submit the
result back to us, but without the terminal emulation.  Their current
brochure gives credit to Columbia, mentions that other versions of Kermit
are available, etc etc.

Thanks to the many people who brought this product to my attention and
who evidently brought me to Solution Software's attention.

- Frank

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

Date: Wed 21 Nov 84 12:48:24-PST
From: Ted Shapin <[e-mail]>
Subject: ITS Binary Files vs Kermit
To: [e-mail]

I have a problem with uploading files.  I use KERMIT and I know
TOPS-20 KERMIT can read ITS binary files and when I use it with
KERMIT on the IBM-PC the ITS header is stripped and the file
converted to a uasable .LBR file, but I don't think KERMIT has
a way of writing an ITS binary file.

Why not use 8-bit format to store binary files on SIMTEL, which
both KERMIT and TOPS-20 modem can write?
Ted.

[Ed. - There's a program in <KERMIT-TOOLS> on CU20B called ITS.  It
will create an ITS header.  You can then append any 8-bit binary file
to the resulting header to produce an ITS binary file, for instance

    @its ; (make the header if necessary)
    @append its.hdr,foo.com (to) foo.com.-1

The result will have the same bytesize as the original, but regardless
what the bytesize is, programs that understand ITS binary format will
do 8-bit-byte input from it.

Alternatively, you can use the program 8COM at SIMTEL20, which apparently
does about the same thing.]

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

Date: Thu 22 Nov 84 01:30:36-EST
From: Mark Becker <[e-mail]>
Subject: Kermit for Burroughs XE-520 / B25 (BTOS op sys) wanted
To: [e-mail]

Hello -

     Has anyone ported Kermit to a Burroughs XE-520 Megaframe or
B25 workstation?

    Thanks in Advance -

Mark Becker
Cent.Mbeck%Mit-Oz@Mit-MC

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

Date: Wed 21 Nov 84 00:03:13-PST
From: Jyh-Jye Yeh <[e-mail]>
Subject: MacKermit connect mode
To: [e-mail], [e-mail]

I found what is wrong with MacKermit connect mode in dialing out at 1200 baud.
I have to choose 9600 baud at first and then choose 1200 baud in the control
options in order to link to Apple modem. If I don't point to 9600 baud and
click it, but fix at 1200 baud, then MacKermit won't send out commands to the
modem.  This is not a major problem since I know how to get around with it
already. The other problem is that "backspace" dose not seem to work neither
when I try to dial out nor when I am talking to the host computer. Also, Emacs
can not work via MacKermit because the mode line is at the top instead of the
bottom

J.J. Yeh
[e-mail]

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

Date: Fri 23 Nov 84 00:49:44-EST
From: Michael Rubin <RUBIN@CUCS20>
Subject: Mac Kermit initialization & other bugs
To: [e-mail]
cc: sy.fdc@CU20B

The reason MacKermit release 2 doesn't use the remembered setup parameters
until after you call up the Control window is that the line
    config=0x4c0a;
in main(), which sets default parameters, is AFTER the initial SetupControls()
call which reads the remembered values.  I've also noticed a pile of other
apparent bugs, such as typos in the window size #define's which may explain
some off-by-one errors in the terminal emulator.  Are you working on a release
3 or should I make a go at it?

--Mike Rubin <rubin@columbia-20>

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

Date: Mon, 26 Nov 84 16:51:13 EST
From: [e-mail] (Stephen Engel)
To: [e-mail], [e-mail]
Subject: Re:  Mac Kermit initialization & other bugs
Cc: sy.fdc@CU20B

You can not imagine the relief with which I read your letter.  I have been
aware of the problem with configuration, and also another with sending out
padding for a while, but have not had the time to correct them.  Meanwhile
unanswered mail and requests have been piling up, any university funding I
might get for working on Mackermit has dissapeared, and my lif has been
generally frantic.  Please feel free to make any corrections you wish.  I would
appreciate being sent a list of the bugs and fixes.

I am still willing to try to do it myself, but if you were to take it
on, I would be very grateful.

Steve

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

Date: Fri 23 Nov 84 20:44:34-EST
From: Peter G. Trei <[e-mail]>
Subject: Apple 2c design flaw.
To: [e-mail]

    A recent article in Creative Computing indicates that many of
Apple 2c's have a serial port problem; do to a design fault, they
transmit about 3% too slow. This is not a major problem at 300 baud,
but at 1200 many modems will not work properly. (The Apple modem DOES
work though). Apparently, if you have this problem, you can get the
dealer to swap the motherboard for you, and future 2c's will have this
problem fixed.
    Maybe this is why so many people are having trouble with
Kermit on the 2c.

                        Peter Trei
                        [e-mail]
------------------------------

Date: 28 Nov 84 14:48:55 EST
From: Eric <[e-mail]>
Subject: Commodore 64 Kermit V1.1 on the way
To: [e-mail]

 Well, it's finally here. I have  in my posession a working  version
of Kermit and sources for the Commodore 64. I am working on  putting
together an initial  release now  (hopefully in a  week). There  are
some small  bugs  and  improvements  I want  to  make  first.  Later
releases will  include major  fixes/ improvements.  This version  is
very limited in what it will do as it is a pretty direct translation
of Apple  V1.0 (or  1.1).  The text  transfer  seems to  be  working
flawlessly though!

C-64 Kermit-65 Capabilities At A Glance:

  Local operation:                  Yes
  Remote operation:                 No
  Transfers text files:             Yes
  Transfers binary files:           No
  Wildcard send:                    No
  ^X/^Y interruption:               No
  Filename collision avoidance:     No
  Can time out:                     No
  8th-bit prefixing:                No
  Repeat count prefixing:           No
  Alternate block checks:           No
  Terminal emulation:               Yes (VT52)
  Communication settings:           Yes; local echo, parity, baud
  Transmit BREAK:                   Yes
  IBM communication:                No
  Transaction logging:              No
  Session logging (raw download):   No
  Raw upload:                       No
  Act as server:                    No
  Talk to server:                   No
  Advanced commands for servers:    No
  Local file management:            Yes
  Handle file attributes:           No
  Command/init files:               No
  Printer control:                  No

Please don't flood me with requests: the *only* way to get this will
be after its' 'official' release...

[Ed. - Note, there's also a Forth implementation of Kermit for the C64
on the way from the University of Vermont.  It's either feast or famine...]

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

End of Info-Kermit Digest
*************************
-------
30-Nov-84 19:45:24-EST,7396;000000000000
Mail-From: SY.FDC created at 30-Nov-84 19:45:10
Date: Fri 30 Nov 84 19:45:09-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #40
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To:: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 30 Nov 1984       Volume 1 : Number 40

Today's Topics:
                          New PDP-11 Kermit
                   New Kermit for Tandem Computers
                New Kermit for the Apollo Workstation
                   CP/M-80 Kermit for the Heath H8
            Revision 3 of TI-PRO Support for MS-DOS Kermit
                PCDOS/MSDOS Kermit Suggestion, cont'd
                         Victor 9000 Kermit?


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

Date: Thurs, 29 Nov 84
From: ATSBDN at UOFT01.BITNET
To: SY.FDC at CU20B.BITNET
Subject: New PDP-11 Kermit

This should be the last mail from uoft01, my 11/785 has jnet on it now
and it works very nicely.  Once you get the new routing tables, the node
is uoft02 and user is BRIAN.

Anyway, who's bringing what to decus? I sent you a tape yesterday that is
current, so will you merge that in for decus or should I bring a tape?

                                           brian

[Ed. - The tape was received and installed at Columbia, and the new PDP-11
files, as well as anything else that arrives before Dec 7 (including the
other new Kermits announced below) will be on the Kermit tapes at DECUS in
Anaheim, Dec 9-14, and all the latest Kermits will be submitted to the
various DECUS SIGs, one way or another.

Version 2.24 of PDP-11 Kermit for is now available for RSX-11/M/M+, RT-11,
RSTS/E, P/OS, TSX+.  This release supersedes version 2.22 from September
1984.  New features include Pro-3xx P/OS support, Pro/RT11 support, error
logging, repeat compression prefix, virtual overlays.  The files are in
KER:K11*.* on CU20B.  There are many files; if you want to pick & choose,
first look at KER:K11FIL.DOC (somewhat out of date, but mostly correct).
You should also look at KER:K11INS.DOC, which describes the different
implementations, system requirements, etc.]

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

Date: 30 Nov 84 20:10:25 EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: New Kermit for Tandem Computers
To: Info-Kermit

A Kermit server for the Tandem computer has been submitted by

    Charles J. Cantor
    Cantor Consulting
    116 Dickerman Rd.
    Newton, MA 02161

It sends and receive ASCII files only, one at a time (no wildcards).
It includes repeat counts and 8th-bit quoting.  It's written in TAL, the
Tandem implementation language.  It's in KER:TANDEM.TAL.  The documentation
is at the top of the program.

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

Date: 30 Nov 1984 1850-EST
From: Frank da Cruz <SY.FDC@CU20B>
To: Info-Kermit
Subject: New Kermit for the Apollo Workstation

A new Kermit implementation for the Apollo workstation has been developed
at Control Data Corporation and submitted by:

    Duane Jergens
    Magnetic Peripherals, Inc,
    7801 Computer Ave. S.
    Minneapolis MN  55435

This implementation is written in Pascal; it supports local, remote, and
server operation, it implements most of the commands from the protocol
manual, and includes Cyber-722 terminal emulation.

The files are in KER:APOLLO.PAS (source), KER:APOLLO.HLP (help file), and
KER:APOTERM.PAS (terminal emulation).

This version of Kermit is independent of the Apollo Fortran implementation
by John Lee of RCA Laboratories, which remains available as KER:APOKERMIT.*.

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

Date: 30 Nov 1984 1900-EST
From: John Mealing, Intecom Inc, Allen TX
To: Info-Kermit
Subject: CP/M-80 Kermit for the Heath H8

Here is a modification of CP/M Kermit to allow setting and display of baud
rates, a bug fix in telnet, and an extension of the HELP to show GET (which
works in this release, on the H8).  Look for the new symbol "h8quad" (for
the heath quad i/o board that it uses) in the conditionals. Note that the
Heath H8 is NOT the same machine as the H89!  The H89 code does not run 'as
is' on the H8, and does NOT initialize the UART.  Also there was a bug in
the telnet section that is fixed here, though I expect that it has already
been found and fixed by now - this is from the DECUS FALL 83 tape.  The
comments were stripped out of this file to make it small enough for my H8
to assemble, however, I have put the first section back in to make it
easier for you to identify.  Thanks for a nice product to use and work on.
Major insertions are heavily commented, edit as needed.

This modification done by John Mealing, InteCom Inc, 601 Intecom Dr.,
Allen, TX 75002 [phone], x-2493, 5 Nov 84.

[Ed. - Based on CP/M-80 Kermit v3.5.  The files are in KER:CPMH8.M80
and KER:CPMH8.HEX.]

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

Date: 30 Nov 1984 0034-EST
From: Joe Smith, Colorado School of Mines
Forwarded-By: B.Eiben LCG <[e-mail]>
To: Info-Kermit@cu20b
Subject: Revision 3 of TI-PRO Support for MS-DOS Kermit

This version works with the TI internal modem and has built-in Tektronix 4010
terminal emulation.

If anyone wants to add interrupt handling to MSXTIPRO.ASM, be my guest.  I
intend to add more to MSXTEK.ASM to turn it into an ESCape sequence processor
general enough to handle HEATH/VT52, ANSI/VT100, and both TEK and ReGIS
graphics.

NOTE: You must edit MSCOMM.ASM to add PORT3 and PORT4 - See MSXTIPRO.BWR for
details.

        Joe Smith
        CSM Computing Center
        1500 Illinois Street
        Golden CO 80401

[Ed. - The files are KER:MSXTIPRO.ASM, .BOO, .BAT, .BWR, and KER:MSXTEK.ASM.
use MSXTIPRO.BAT to assemble and link the program for the TI Pro.  MSTIPRO.EXE
is in KB:.]

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

Date:  Thu, 29 Nov 84 23:57 EST
From:  [e-mail]
Subject:  Re: PCDOS/MSDOS Kermit suggestion
To:  Daphne Tzoar <[e-mail]>, [e-mail]

 [This was a suggestion in V1 #39 for using the BIOS whenever it was
 feasible].

Since I generally run at much over 1200, the ability to use the BIOS is
quite limited.  I only meant to suggest that for the 8 supported baud
rates, setting speeds using the BIOS was more robust than going to the
chip.  Admittedly, this doesn't go very far in solving the problem with the
8251. A related problem with the 8251 and the BIOS is the inability to read
out the current baud rate.

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

Date: 29 Nov 84 10:10:25 EST
From: Gadi <[e-mail]>
Subject: Victor 9000 kermit?
To: [e-mail]

We recently got a Victor 9000 donated to us in the MICROLAB, The only
software it came with was MS-DOS 1.1 and CPM/86.  Since the
diskdrives are not compatible with the IBM-PC (they hold over 600k
each), is there any way I can get a version of vickkermit to a victor
format disk?

                              -Gadi
                         Friedman@Ru-Blue
                    harvard!topaz    \
                       friedman
                    allegra!ru-blue  /

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

End of Info-Kermit Digest
*************************
-------
 4-Dec-84 18:29:18-EST,9352;000000000000
Mail-From: SY.FDC created at  4-Dec-84 18:27:06
Date: Tue 4 Dec 84 18:27:06-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #41
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue,  4 Dec 1984       Volume 1 : Number 41

Departments:

  ANNOUNCEMENTS -
        Kermit for the ICL/Three Rivers PERQ
        Kermit for the Pascal Microengine
        CP/M-86 Kermit Version 2.9
        CP/M-86 Kermit for Tektronix 4170

  MISCELLANY -
        How to Bootstrap Kermit for the Victor 9000
        MS-DOS Kermit RUN Command

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

Date: Tue 4 Dec 84 12:44:00-EST
From: Peter Thew, Computer Centre, RMC Duntroon, Australia
Subject: Kermit for the ICL/Three Rivers PERQ
To: Info-Kermit

The Pascal version of Kermit for RT-11 systems, written at the University of
Toronto,  has  been  heavily  modified  for  the ICL/Three Rivers PERQ.  The
command parsing has been improved by using the PERQ's parsing routines which
allow  pop-up  menus  and  command  files.   Binary  file  transfer has been
included (but it is rather simple and needs to be improved).

Some features that are to be added in the future are:

     .    Server commands
     .    VT100 emulation during CONNECTS.
     .    Pop-up menus for all commands
            (eg. SET --> SPEED --> baud-rates)
     .    General  code clean up, including faster disk I/O using FileSystem
          routines.

                                        Peter Thew
                                        Computer Centre
                                        Australian Defence Force Academy
                                        ACT   2600   Australia


[Ed. - The files are in KER:PQ*.* on CU20B, available via anonymous FTP.]

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

Date: 27 Nov 84 21:22:31 PST (Tue)
To: SY.FDC@CU20B
Subject: Pascal Microengine kermit implementation
From: "Tim Shimeall" <[e-mail]>

I have adapted the UCTERAK version of kermit to run on a Western Digital Pascal
microengine.  It was not a difficult translation (your protocol designers are
to be complemented on its clarity) and the Microengine is not a common system.

To get everything working properly I had to make rather widespread (but not
extensive) changes to the Cornell Terak version, such that it would be
difficult to tie it down to just a few files (every file in the program has
been changed at least slightly).

In the process of converting over, I spotted a few bugs in Terak Kermit.  The
most serious is that it does *no* timed waiting for packets; it just checks
10000 times to see if SOH has arrived.  From a colleague here, I understand
that UCIBM-PC kermit has problems as well.  I have corrected this bug in the
transported version (can I suggest calling it UCMICRO?)  The following is the
list of changes I've made in UCTERAK kermit to make UCMICRO kermit:

- Added device declarations copied from Microengine hardware documentation
- Replaced external assembly language routines with Pascal versions
- Modified debug messages to be label values printed
- Changed format of packetwrite display to show header fields
- Implemented machine-dependent packet timeout
- Added debug packetwrites in recsw
- Added wrap-around debug info region
- Added legality check in showparms
- Removed lf elimination check in echo procedure
- Unitwrite calls replaced by calls to device driving routines
- Most uses of char_int_rec replaced by ord and chr
- Removed queue (no interrupts)
- Used sets for integer ops to getaround Microengine bug
- Changed parser from a unit to a segment procedure to allow swapping
- Eliminated "sendbrk" procedure (couldn't determine its use)
                Tim

[Ed. - The program is in KER:UCMICRO.PAS and KER:UCMICRO.DOC on CU20B.]

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

Date: Sun 2 Dec 84 15:49:29-PST
From: Ronald Blanford <[e-mail]>
Subject: CP/M-86 Kermit Version 2.9
To: [e-mail]

I've been making changes off and on to 86kermit, but the next month or two
looks slack so I'll give you the current version for testing and possible
release.  The files are in my account as usual with the source in
86KER*.* and the hex and binary in APCKERMIT.*.

The specific features that have been implemented in version 2.9 are:

    o  LOCAL DIRECTORY command now computes file sizes correctly
       for all files.  The size given is the actual allocation on
       disk, and not the logical size (which might differ for
       non-sequential files).

    o  LOCAL TYPE command has been implemented to display (text) files
       on the screen.  A wildcard filespec is accepted and files displayed
       alphabetically.  The display is paged in Unix fashion with --more--
       displayed on the last line.  Typein options at that point can be
       obtained by hitting a '?'.

    o  Wildcard SENDs now send files in alphabetical order by name, and
       accept an optional initial filename in the command line to allow
       transmission of partial groups in the manner of TOPS-20 Kermit.

    o  Problems with use under Concurrent CP/M on the APC have been fixed.
       In particular, a KERMIT.INI file is no longer required, the
       SET DEFAULT-DISK command works correctly, and a process dispatch
       is performed each time a call to the serial port status routine
       returns negative, vastly improving the response of other jobs.
       There is still no provision for mutual exclusion on the serial
       port.

[Ed. - The files are in:

KER:86*.*           source, documentation.
KER:APCKERMIT.H86   hex for NEC APC
KB:APCKERMIT.CMD    8-bit binary for APC
KER:RBKERMIT.H86    hex for DEC Rainbow
KB:RBKERMIT.CMD     8-bit binary for Rainbow

The old files will be set aside for a while in case problems appear.
Also see next message...]

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

Date: Tue 4 Dec 84 18:00:00
From: Frank da Cruz <SY.FDC@CU20B>
Subject: CP/M-86 Kermit for Tektronix 4170
To: Info-Kermit

CP/M-86 Kermit 2.9 also includes support for the Tektronix 4170.  The
support comes from a system-dependent module, like the ones for the Rainbow
and the APC, contributed by Robert Raymond, TransEra Corporation, Provo, Utah.
He says it works just like the APC and Rainbow versions.  His module compiled
and linked with the other modules with no apparent problems.

The Tektronix 4170 i/o module is in KER:86KERIO.TX4.  The hex is in
KER:TX4KERMIT.H86 and the binary in KB:TX4KERMIT.CMD.

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

Date: Sat 1 Dec 84 12:51:06-EST
From: Peter D. Junger <JUNGER@CWRU20>
Subject: How to Bootstrap Kermit for the Victor 9000
To: info-kermit@CU20B

        In response to the recent request for a way to get the
Victor 9000 Kermit onto the Victor without having a Kermit
already on that machine, I can explain what we did.  We used
Kermit on another machine (I forget whether it was a North Star
Horizon or an IBM PC) which did run Kermit to download the Victor
Kermit source code.  We then used Crosstalk to transfer the code
to the Victor and then assembled it on the Victor.  As I recall
it took more than 128 K of memory to get the program to assemble.
For the assembler we used the one--I assume that its
Microsoft--that comes with the Victor Programmer's Toolkit (which
Victor didn't supply without cost).

        Crosstalk isn't magic, as long as there is some file
transfer program which exists on the two micros.  If there is no
communications program on the Victor in question--as I suspect
may be the case--I can send a floppy disk with the version which
works for us to the person who needs it.  (I can't look at his
message while I am typing this.)  I am very disorganized, so the
best way to reach me is over CCNet:  JUNGER@CWRU20.  I do not
believe that I can be reached directly or indirectly from
ARPAnet, so the sender may have to request you to relay it.

        I hope that this is of some help.  I will not quarantee
that our copy works very well, we hardly ever use it, since I am
the only one here that makes much use of Kermit and I do not use
the Victor as my main machine.

Peter Junger

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

Date: Mon, 3 Dec 84 15:04:08 cst
From: allegra!noao!utastro!nather@Berkeley (Ed Nather)
To: carina!allegra!ucbvax!info-kermit@Berkeley
Subject: MS-DOS Kermit RUN Command

The "run" command in mskermit is very useful in feeling around for a file
under MS-DOS 2.0, and for doing a few other things.  It has a couple of
peculiarities, though: it requires the full name, with extension, for the
executable file; usual ms-dos procedure executes a .com, .exe or .bat file
if the extension is left off, and most users are used to it.  It took me a
long time to guess what Kermit wanted.

By the way, it may not be obvious to some users that Kermit can't handle
a .bat file at all; the usual symptom is a hang that requires a power-off
reset to get the computer's attention again.  A warning to this effect in
the next version of the manual might save someone a headache.

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

End of Info-Kermit Digest
*************************
-------
 6-Dec-84 13:33:59-EST,8733;000000000001
Mail-From: SY.FDC created at  6-Dec-84 13:33:33
Date: Thu 6 Dec 84 13:33:32-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #42, Special CP/M-80 Edition
To: [e-mail], [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu,  6 Dec 1984       Volume 1 : Number 42

       Special Issue: Announcement of CP/M-80 Kermit Version 4

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

Date: Wed 5 Dec 84 15:28:40-EST
From: Charles Carvalho <[e-mail]>
Subject: New Release of Kermit for CP/M-80
To: [e-mail]

This is to announce version 4.03 of CP/M-80 Kermit.  This is a "beta test"
of a major new release, and will not replace the current version (3.9A),
until it has proven to be stable.

The major change is the decomposition of the program into a collection of
modules, a`la MDMxxx, with a new procedure that allows combining custom
"configuration overlays" with the system-independent portions of the
program.  This allows fixes or new features to be added to the protocol
without requiring reassembly of the program for each system supported, and
conversely, allows support for new systems to be added (or old ones fixed)
without reassembly for the other systems.  An added benefit of the breakup
of the old monolithic source file into smaller files is managability on
systems with limited disk storage -- at 176K, the version 3.9A source file
exceeded the capacity of many common floppies.

The modular decomposition is not quite complete, however, since the
system-dependent code for all systems is still combined in one module,
with assembly time conditionals for each system.  A future release will
break this module, CP4SYS.ASM, into separate, unconditionalized modules
for each system.

Here are some of the new features of version 4:

* Support for New systems:

Support has been added for several new systems or configurations:

    Apple II, Z80 Softcard, 6551 ACIA
    BigBoard II
    CPT-85xx word processer
    Digicomp Delphi 100
    Morrow Micro Decision I

Support that was recently added to version 3 of CP/M Kermit for systems
like the Heath H8 and Compupro Interfacer 3/4 is not included; volunteers
are needed to do the conversions.

* Terminal support:

For micros without integral consoles, one of several terminals may be
chosen (among them VT100, VT52, and ADM-3A), as well as the generic "CRT".

* Debugging aids:

SET DEBUG ON will add two fields to the SEND/RECEIVE display, labelled
"Spack" and "Rpack".  These display the last packet sent or received.
Of course, this slows down the transfer, especially if the console is an
external terminal.  SET DEBUG OFF removes these fields.

The VERSION command displays the name, edit number, and edit date of
several of the modules that make up Kermit.

* TAC support:

ARPAnet TACs (and probably some other communication devices like modems,
multiplexers, port contention units) use a printing character (normally
"@") as an intercept character, to allow commands to be issued to the TAC.
In order to send this character to the host, it must be typed twice.  The
command "SET TAC CHARACTER" to Kermit enables the TACtrap and asks the
user to specify the TAC intercept character.  This character will be
automatically doubled when it appears in Kermit protocol messages (sent by
the SEND or RECEIVE commands) or when it appears in a file being sent with
the TRANSMIT command.  It is not automatically doubled when typed by the
user in CONNECT mode.  "SET TAC ON" enables the TACtrap but does not
change the TAC intercept character, which is initially "@".  "SET TAC OFF"
disables the TACtrap.

* File buffering:

Previous versions of Kermit-80 buffered only one sector (128 bytes) at a
time during file transfer operations.  This version buffers 16Kbytes at a
time, reducing the number of times the floppy drive must be spun up and
down, and increasing the effective throughput of the link.  If the disk
transfer rate is too slow, howver, the remote Kermit may time out and
retransmit packets.  This will show up on the screen in the "Retries:"
field; if this occurs after disk activity, you may want to increase the
timeout value on the remote Kermit, or reassemble Kermit with a smaller
value for MAXSEC (in CP4SYS.ASM).  This buffer is also used by the
TRANSMIT command; the log file enabled by the LOG command is still written
a sector at a time.

* Baud Rate Setting:

The format of the SET BAUD-RATE command has been changed for several
systems.  Rather than requesting the user to enter a letter for the speed,
the desired baud rate is supplied on the command line (e.g. "SET BAUD
1200").  A list of supported baud rates may be obtained by typing "SET
BAUD ?".  If Kermit cannot change the baud rate for your system, it will
reply "(not implemented)".

* Generic CP/M 2.2 Support:

The "generic" Kermit-80 for CP/M 2.2 (assembly switch GENER) supports six
port selections, to improve the chances of finding one that works.  Kermit
reads from PTR: and writes to PTP: by default; if this does not work, try
"SET PORT TTY".  The following table lists the CP/M devices used for each
option:

    SET PORT xxx    input from    output to
        CRT           CRT:           CRT:
        PTR           PTR:           PTP:
        TTY           TTY:           TTY:
        UC1           UC1:           UC1:
        UR1           UR1:           UP1:
        UR2           UR2:           UP2:

In all cases, the console (CON:) and list (LST:) devices used are those
selected when Kermit is started.

* How to Get It:

The files are in KER:CP4*.* on CU20B, available via anonymous FTP.  CU20B
is Internet host [192.5.43.128].  The source files have the extension
(file type) .ASM, the hex files .HEX.  There is also a new Kermit User
Guide chapter in KER:CP4KER.DOC and .MSS (Scribe text formatter source).
A list of known bugs and deficiencies is in KER:CP4KER.BWR (this file will
be updated as reports come in).  The edit history and internals are
documented in KER:CP4KER.UPD.

Note that a new, somewhat more complicated, installation procedure is
required.  Two hex files -- the system-dependent part, and the
"configuration overlay" -- must be combined and then loaded.  Detailed
instructions are given in KER:CP4KER.DOC.

The program may be built with the public-domain assembler and linker,
LASM and MLOAD, or on the DEC-10 or DEC-20 with Bruce Tanner's MAC80 and
LINK80.  Unfortunately, it can no longer be built with ASM and LOAD because
multiple files are used (this is the price we pay for modularity).
LASM, MLOAD, MAC80, and LINK80 are all in the <KERMIT-TOOLS> area on CU20B,
for those who need them.  <KERMIT-TOOLS> can be referred to as KT:, as in
KT:MLOAD.HEX.

The following systems are supported:

Symbol  Filename System
------  -------- ------
AP6551  CP4APL   Apple II, Z80 Softcard, 6551 ACIA in serial interface
APMMDM  CP4APM   Apple II, Z80 Softcard, Micromodem II in slot 2
BBII    CP4BB2   BigBoard II (terminal required)
BRAIN   CP4BRN   Intertec SuperBrain.
CPM3    CP4CP3   "generic": CP/M 3.0 (CP/M Plus) systems (terminal req'd)
CPT85XX    CP4CPT     CPT-85xx word processors with CompuPak CP/M
DELPHI  CP4DEL   Digicomp Delphi 100 (terminal required)
DMII    CP4DM2   DECmate II with CP/M option
GENER   CP4GEN   "generic": CPM 2.2 systems with IOBYTE (terminal req'd)
HEATH   CP4H89   Heath/Zenith H89.
KPII    CP4KPR   Kaypro-II (and 4; probably supports all Kaypro systems)
MDI     CP4MDI   Morrow Decision I (terminal required)
MIKKO   CP4MIK   MikroMikko
MMDI    CP4UDI   Morrow Micro Decision I (terminal required)
OSBRN1  CP4OSB   Osborne 1
OSI     CP4OSI   Ohio Scientific
ROBIN   CP4ROB   DEC VT180
TELCON  CP4TEL   TELCON Zorba portable
TRS80LB CP4TLB   TRS-80 model II with Lifeboat 2.25C CP/M Display
TRS80PT CP4TPT   TRS-80 model II with Pickles + Trout CP/M Display
VECTOR  CP4VEC   Vector Graphics.
Z100    CP4Z00   Z-100 under CP/M-85

The "symbol" is used in CP4SYS.ASM for assembly purposes.  The filename
shows where to find the .HEX file in KER: on CU20B, e.g. KER:CP4Z00.HEX.

Please try out the new version and report any bugs to Info-Kermit@CU20B.
Also, please feel free to add support to CP4SYS.ASM for systems that are
not supported, and to make enhancements to those that are; for instance,
most systems are still not able to send a 250ms BREAK signal.

Version 3.9A of CP/M-80 Kermit continues to be available as KER:CPM*.*
on CU20B, but will eventually be phased out.

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

End of Info-Kermit Digest
*************************
-------
 7-Dec-84 17:13:33-EST,7918;000000000001
Mail-From: SY.FDC created at  7-Dec-84 17:11:46
Date: Fri 7 Dec 84 17:11:45-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #43, Special MS/PC-DOS Edition
To: [e-mail], [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri,  7 Dec 1984       Volume 1 : Number 43

     Special Issue: Announcement of MS/PC-DOS Kermit Version 2.27

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

This is to announce version 2.27 of MS-DOS Kermit.  This release is
primarily intended to fix some of the problems that surfaced in version
2.26.  Some minor new functionality has also been added.  The work was
done by Daphne Tzoar and Jeff Damens of the Columbia University Center
for Computing Activities -- some original, and some based on code
contributed from other sites, such as the University of Maryland.

MS-DOS Kermit has been implemented for the following MS/PC-DOS systems:

  . IBM PC and PC/XT and compatibles (Compaq, Z150, ITT Xtra, etc)
  . IBM PC/AT (new)
  . IBM PCjr (serial port only)
  . DEC Rainbow 100 and 100+
  . Heath/Zenith 100
  . HP-150
  . Wang PC
  . NEC APC (from Ron Blanford, U of Wash & Ian Gibbons, U of Hawaii)
  . TI Professional (from Joe Smith CSM, includes Tek 4010 emultation)

and there is a "generic MS-DOS" version for systems not explicitly
supported (the generic version runs slower and doesn't take advantage
of any machine-specific features).

New Features of Version 2.27
----------------------------

. SET PORT DEVICE and SET PORT FILE-HANDLE commands to allow generic DOS
  Kermit more flexibility in finding the communication port on new systems.

. DEC Rainbow now has SET BAUD command.

. SET DESTINATION SCREEN command - directs incoming files to the screen
  rather than to the disk (for displaying files from those systems whose
  Kermits don't support the REMOTE TYPE command).

. Escape character command <esc-char>P to push to DOS during CONNECT.

. Includes the enhanced NEC APC support from Ian Gibbons, U of Hawaii  --
  full key scan-code redefinition, auto-determination of color/monochrome
  for CRT formatting, direct video access for faster help menus, and a
  scroll/noscroll key that sends ^S and ^Q alternately.

Problems Fixed in Version 2.27
------------------------------

Version 2.27 attempts to fix the following problems from version 2.26 (thanks
to those who reported them, and especially to those who also sent fixes):

* Program Design:

  Some code that proved to be system-dependent (like structure definitions
  that assumed only two communication ports) has been moved into the
  system-dependent sections.

  LEA's have been changed to MOV ..,OFFSET or to LEA ..,WORD PTR in msfile,
  so that program can be built by non-IBM assemblers.

* File Transfer:

  Incoming packets are now discarded if they're the same type as the packet
  just sent, in case some hardware in the communication path is echoing them
  back.

  SET DEST PRINTER now uses PRN device, not LPT1.

  An extraneous partial final buffer should no longer be printed printed during
  direct transfers to printer ('SET DEST PRINTER').

  Use of Return key to retransmit current packet is now documented in the
  file transfer display.

  SET EOF CTRLZ has been fixed to work as described in the manual.

  New precautions have been taken to guard against packet buffer
  overrun.  Buffer overruns caused various symptoms in v2.26 -- CRC's would
  stop working, memory dumps would appear on screen, etc.

  Open files are now closed if a fatal error occurs during file transfer
  and 'set incomplete keep' is in effect.

  Empty responses to REMOTE HOST commands no longer crash the program.

  Some early copies of 2.26 displayed the number of Kbytes transferred
  incorrectly during file transfer; this was fixed in later copies, and
  is also fixed in 2.27.


* Terminal Emulation:

  In IBM H19 emulation, tabs are no longer destructive.

  IBM H19 emulation problems with Insert/Delete bottom line of screen
  are fixed.

  On IBM, H19 cursor save/restore function is now supported.

  On IBM, carriage returns in inverse video mode no longer scroll
  inverse lines onto screen (Unix MORE users will appreciate this).

  On IBM, Remote/Local Echo status line is now correctly displayed.

  On IBM, the keypad "+" key may now be redefined using SET KEY (this
  key normally has the undocumented function of toggling the mode line
  during CONNECT).

  On the Rainbow, various problems have been fixed with screen scrolling:
  . Character attributes are now displayed correctly in previous screens
     (except for double height/width attributes)
  . Prev/Next Screen no longer overshoots.
  . Lines are no longer lost from prev screen when autowrap is in effect.
  . 132 column display works with Prev/Next screen.
  . VT52 emulation mode entry/exit no longer hangs the program.

  On the Rainbow and the IBM PC, BREAK now should last exactly 275 msec.

  The Rainbow now resists attempts to send ESC-8 and ESC-c to the firmware,
  since these codes will crash the machine (firmware bugs).


* Command Parser:

  The current directory is now searched for files before the PATH, in
  the same way DOS searches for files.

  'Set key scan <space><space><return>' now works properly.

  SHOW MACRO should have been SHOW MACROS; now it is.

  Table overflow for 'set key' definitions is now detected.  Undetected
  overflow had unpredictable (but always bad) consequences.

  Trailing comments are now illegal in commands typed at the keyboard;
  they still may be used in command files.  This allows the ";" character
  to be used in commands like "get foo.bar;2" or "remote host cd ; pwd".

  The eighth bit is stripped from incoming characters; previously,
  entering characters from the keyboard with the high-order bit on
  would crash Kermit.

* PC/AT support:

  Some minor problems introduced by DOS 3.0 when the PC/AT appeared have
  been fixed, and Kermit 2.27 should operate correctly on the AT.


Documentation:
-------------

The manual has not yet been updated.  Many of the changes were made in order to
make the program conform to the manual.  An updated manual will follow shortly.


Future Versions:
---------------

Future plans for MS-DOS Kermit include:

. Removal of DOS 1.x support.  Dynamic memory allocation features of DOS 2.0
  and above would allow the program to be much smaller on disk.

. Addition of a login script facility, similar to the one recently added to
  DEC-20 Kermit.


How To Get Version 2.27:
-----------------------

Version 2.27 of MS-DOS Kermit is available via anonymous FTP from host CU20B,
Internet host number [192.5.43.128].  It is in the files KER:MS*.*.  The
executable programs are encoded in ASCII ".BOO" format -- those who don't know
what that means should get the MS-DOS Kermit chapter of the Kermit User Guide
(available as KER:MSKERMIT.DOC) and read about bootstrapping MS-DOS Kermit.
Those who may have gone through this before are exhorted to obtain the current
copy of KER:MSPCTRAN.BAS, the .BOO file decoder, in which a serious bug was
recently fixed.

The sources are in KER:MS*.ASM and KER:MS*.H.  KER:MSBUILD.HLP tells how to
build the program.

Binaries, for those who can transfer them directly, are in KB:MS*.EXE.

This new release will be available at DECUS in Anaheim, Dec 10-14, and should
appear on the resulting DECUS SIG tapes.  It will also be submitted to PC-SIG
for distribution on floppy disk.  And it will appear for BITNET distribution
in the near future.

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

End of Info-Kermit Digest
*************************
-------
18-Dec-84 10:41:18-EST,15358;000000000000
Mail-From: SY.FDC created at 18-Dec-84 10:40:49
Date: Tue 18 Dec 84 10:40:49-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #44
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue, 18 Dec 1984       Volume 1 : Number 44

Departments:

  ANNOUNCEMENTS -
        Kermit for the Commodore 64 Written in Assembler
        Kermit for the Commodore 64 in FORTH
        Corrected Copies of MS-DOS Kermit 2.27 for Z100 and NEC APC

  CP/M-80 KERMIT -
        CP/M Kermit v4: CP/M 3 Support and H89
        CP/M Apple Kermit v4.03
        Kaypro Version of Kermit 4.03
        Kermit-80 Status

  MISCELLANY -
        Columbia Kermit with Port 3?
        Multics Kermit and X.25 Connections
        Additional Heuristics for Kermit
        Kermit vs 4705?

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

Date: 14 Dec 84 00:41:50 EST
From: Eric <[e-mail]>
Subject: Kermit for the Commodore 64 Written in Assembler
To: [e-mail]

Here is Kermit for the Commodore 64, written in CROSS (almost exactly like
the Apple version).  I have bootstrap programs, but the BASIC version for
the C64 end doesn't yet do what it's supposed to.  The bootstrap is supposed
to work just like the Apple version; since it isn't quite working yet, one
must have Kermit or Modem to get Kermit over to his/her machine.  I hope
to have this problem corrected soon.  The files are on CU20B, available
via anonymous FTP:

        KER:C64DXL.BAS  ; A BASIC version of C64DXL
        KER:C64DXL.HEX  ; The hex file for C64DXL (nulls removed!)
        KER:C64DXL.M65  ; The source for the disk hex loader
        KER:C64KER.DOC  ; Incomplete Documentation
        KER:C64KER.HEX  ; The Hex file for C64KER (with nulls removed!)
        KER:C64KER.INS  ; One page installation instructions
        KER:C64KER.M65  ; The source, however mixed up it may be
        KER:C64KER.MSG  ; Proposals for improvements (like an RFC)
        KER:C64KER.MSS  ; The Scribe source for C64KER.DOC

I am calling this release of Kermit a Beta-Test for several reasons.
This version was slapped together from the sources I received from
Dave Dermott and my improvements, updates from the latest Apple
version.  I wanted to get this out ASAP. As a result, there are
several untested features, unimplemented features or some features
which may be better if implemented in a different way.  See C64KER.MSG
for a list of these.

ARPA:   Lavitsky@RUTGERS
UUCP:   ...harpo!whuxlb!ru-blue!lavitsky
 or     ...allegra!ru-green!ru-topaz!eric
SNAIL:  CPO 2765, CN 700
        New Brunswick, NJ  08903
 or     14 Rock Ave.
        Swampscott, MA  01902

Phone:  (201) 932 - 2443 (RUTGERS: Operators' Cubbyhole: leave a message)
        (617) 593 - 4841 (Real Home: leave a message)
        (201) 745 - 8143 (Campus Home during school semesters only)

[Ed. - CROSS is a cross assembler that runs only on the DEC-10 and DEC-20.
For bootstrapping, I'd suggest that the MS-DOS method be adapted -- run
MSMKBOO on the binary to produce a 4-for-3 encoded .BOO file (with
zero-compression), use MSBOOT.FOR to send the .BOO file, and adapt
MSPCBOOT.BAS to run on the C64 to receive the file.  These days, every
Kermit seems to come with its own unique bootstrapping procedure; since
most of them do the same thing, let's start standardizing.  Meanwhile,
send comments and suggestions about this new Kermit implementation to Eric
and to Info-Kermit.]

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

Date: Wed 12 Dec 84 15:46:38-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit for the Commodore-64 in FORTH
To: [e-mail]

Announcing Kermit for the Commodore 64 with Commodore 1541 disk drive,
from Robert W. Detenbeck, University of Vermont.  The program was written
to be used with version A of C64-FORTH, sold by Performance Micro
Products, 770 Dedham Street-S2, Canton, MA 02021.  Slight modifications
would be required to use the screens with the newer version B, a pure
FORTH-79 standard.

The files (slightly modified for distribution, as indicated) are available
on CU20B via anonymous FTP:

KB:C644TH.PRG -- core-image 8-bit binary "PRG" file.

KER:C644TH.HEX -- hex (nibble) encoding of C644TH.PRG, with CRLF inserted
 after every 78 characters.

KER:C644TH.DOC -- brief explanation of the program
KER:C64495.SCR -- help screen SCR95, with CRLF inserted after every 40 chars.
KER:C64496.SCR -- help screen SCR96, ditto
KER:C64497.SCR -- help screen SCR97, ditto
KER:C64498.SCR -- help screen SCR98, ditto

Source not included.  The author says "I would be glad to provide the
FORTH source screens to anyone who could use them, but it is awkward to
transmit 90 Kbytes on a 300-baud Kermit, so a mailed disk might be a
better answer to the probably small number of requests."  Send a
self-addressed mailer to the author, Prof. Robert W. Detenbeck, Department
of Physics, University of Vermont, Burlington, VT 05405.

We'll also try to scare up the source ourselves.

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

Date: Tue 18 Dec 84 10:13:56-EST
From: Frank da Cruz <[e-mail]>
Subject: Corrected Copies of MS-DOS Kermit 2.27 for Z100 and NEC APC
To: [e-mail]

A forthcoming issue will be devoted to the reaction to MS-DOS Kermit v2.27.
In the meantime, it should be noted that serious problems were discovered
with the Heath/Zenith-100 version, and it has been replaced.  Minor problems
were also discovered with the NEC APC version and it too has been replaced.
The new files are in

KB:MSZ100.EXE, KER:MSZ100.BOO, KER:MSXZ100.ASM  --  Z100
KB:MSAPC.EXE,  KER:MSAPC.BOO,  KER:MSXAPC.ASM   --  NEC APC

on CU20B, available via anonymous FTP.

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

Date: Tue, 11 Dec 84 23:51:18 CST
From: Paul Milazzo <[e-mail]>
Subject: CP/M Kermit v4: CP/M 3 support and H89
To: Charles Carvalho <[e-mail]>, [e-mail]

One of the many nice things about the beta-test version of CP/M Kermit
is that it contains code that correctly calculates disk free space
under CP/M 3.  Unfortunately, this code is only assembled in when you
select the "cpm3" flag, which results in a generic (pronounced "slow")
CP/M 3 Kermit, as if CP/M 3 were mutually exclusive with the supported
system types.  Since I have an H89 running CP/M 3, I wanted to take
advantage of the H89-specific support and still be able to tell how
much free space there is on my disks.

Rather than double the number of supported system configuration flags
just for this one function, I chose to save the BDOS file system
version (from BDOS function 12) at startup, check it whenever sysspc is
called, and branch to the correct algorithm.  That way, a configuration
for hardware which supports both CP/M 2 and 3 will work in either case.

If this approach is seen as a Good Thing, I'll be happy to contribute
it to the distribution.  If not, what should I have done instead?

I've also added some additional H89 support (speed selection, sending
breaks, etc.), and fixed a minor bug in the delay subroutine used by
"kpii", "bbII", and "cpt85xx".  It ignores its argument.

                                Paul G. Milazzo
                                Dept. of Computer Science
                                Rice University, Houston, TX

ARPA:   [e-mail]
UUCP:   {cbosgd,convex,cornell,hp-pcd,shell,sun,ut-sally,waltz}!rice!milazzo

[Ed. - When any of this finds its way into the distributed version, a
notice will be posted.]

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

Date: 13-Dec-84 03:13:51-EST
From: decvax!ncoast!stuart@Berkeley  (Stuart Freedman,C.W.R.U.,368-8860)
To: .include.fdc@Berkeley
Subject: CP/M Apple Kermit v4.03

I just put together this version (snarfed it over and ddt-ed it) and find
it great (esp. the greater time between disk accesses).  The only problem
I have discovered so far is that when I do a ctrl-] D to disconnect (I am
using the Micromodem II version), the system just hangs.  Also, is there
any chance of making the logging feature better (i.e. enlarging the buffer
size and allowing more time for ^S-^Q so that no characters would be
lost)?

Thank you very much for putting Kermit together and coordinating the
ongoing efforts to improve it.

Stuart Freedman                         decvax!cwruecmp!ncoast!stuart
Case Western Reserve University      or [e-mail]

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

Date: 14 Dec 84 13:38:49 EST
From: Dave Zubrow <DZ05@CMU-CC-TD>
To: info-kermit@CU20B
Subject: Kaypro Version of Kermit 4.03

Dear Kermit:

I have been trying to use version 4.03 and can't get it to work with files
larger than the 16K buffer.  After it writes the buffer to disk I get the
message "?unable to receive data".  I've tried various settings for the
send and receive timeout parms on the Dec-20 but they were not successful
in eliminating the problem.  Could it be that the 16K buffer is not being
flushed after the disk write?  Do you have any remedies or suggestions?

Thanks,

Dave Zubrow

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

Date: 17 Dec 1984 12:59 PST
From: Charles Carvalho <CHARLES@ACC>
Subject: Kermit-80 status
To: SY.FDC@CU20B

Frank and Bernie -
    I've got the new H89 stuff here, and will merge it with the FILCOM for
the Northstar CP/M version.  I'm curious about the bug Hal found in the
receive packet routine (but not surprized).  I thunk about the disk
buffering problems this weekend, and am puzzled why increasing the
send/receive timeouts at the other end didn't fix the problem.  (It worked
here, between a Kaypro and VMS Kermit; the Kaypro takes about 15 seconds
to transfer 16Kbytes to disk, so 20 seconds ought to be adequate.  I used
30 seconds).  Anyway, a possible solution is to check the line for more
data after receiving the packet terminator, and if a control-A is seen,
forget the received packet and accumulate the next one.  (Doesn't the
MSDOS Kermit do something like this?)  This should work for any number of
complete buffered messages, as well as the final partial message, if any,
for a micro such as the Robin that flow-controls if nobody is taking the
received data.  What I'm not sure about is what happens if the middle of a
message is dropped (for instance, a SIO chip will keep the first two and
the last byte of a message that comes in while nobody is looking).  I
guess we'd usually recover after a timeout.  The problem with the Apple
Micromodem configuration is that control-] D no longer terminates connect
mode, it just hangs up the phone (oops...)  For now, following control-] D
with control-] C should do the right thing.
                                                /Charles

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

Date: 14 Dec 1984 12:34:56-EST
From: [e-mail]
To: [e-mail], [e-mail]
Subject: Columbia Kermit with Port 3?

Does anybody has a version of kermit that runs on the Columbia using COM3
instead of COM1 or COM2?  It seems to me that all that needs changing are
the port addresses in MSXIBM.ASM.
-- Ivan Auger --   (augeri@rpi  for csnet)
                   (augeri%rpi@csnet-relay for arpanet)

[Ed. -- Look at MSXTIPRO.ASM for an example of how to increase the number
of ports.]

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

Date:  Tue, 11 Dec 84 02:20 CST
From:  Jerry Bakin <[e-mail]>
Subject:  Multics Kermit and X.25 connections
To:  [e-mail]

I have noticed some peculiar behavior in Multics Kermit; I was hoping to
pass this on to the maintainers of Multics Kermit (I know of at least
four versions!) and through Info-Kermit.

I have been connecting to Multics through a VAX using the DEC PSI
program which creates an X.29 virtual terminal over an X.25 circuit.

I notice that if the first thing I try to do in Kermit is "receive" a
file, I get an error complaining about setting "improper modes" for this
device.  If I first try a "send" then things work ok.  Indeed, if I
first send, and then try to receive, the receive works as well.

Could it be that you are setting modes differently for send then
receive, and trying to set modes for receive that do not really need
setting?

Jerry Bakin. <Bakin at HI-Multics>  [phone]

[Ed. - This message was passed along to the author of MULTICS Kermit.]

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

Date: Sun 9 Dec 84 07:59:30-PST
From: Bob Larson <BLARSON%ECLD@ECLA>
Subject: Re: Additional Heuristics for kermit
To: [e-mail]

This is in response to Frank da Cruz's response to my message of Oct 17,
both of which are published in info-kermit V1 #33.  Since we agreed on
idea #2, I have omitted it.

1. Any control character received in a packet terminates that packet.
        What I meant by this was any control character not agreed
        on as going through unharmed.  If the sending kermit won't
        send a control character, the receiving kermit should NAK
        a packet containing one.

3. A nak should be sent as early as possible.
        I should have been more explicit here too.  This thought
        was mainly important for kermits that send multiple packets
        at a time.  (Not yet part of the kermit protocol.)  Many systems
        have output buffers, so the amount of time they spend not
        waiting for input is trivial.  (I'm more used to large systems
        where this is true, and I like micro's to imitate this.  I
        hate systems without typeahead.)

Bob Larson <[e-mail]>

[Ed. - No problem with any of these.  But note in (3) that because of
the layered nature of the protocol, the program does not (or should not)
know the packet type or number until the packet reader has read the entire
packet and returned it to the entity awaiting the packet; thus it would not
fail and send a NAK as soon as a bad header was read.]

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

Date: Tue, 4 Dec 84 19:55:19 pst
Subject: Kermit vs 4705?
From: Steve Reynolds <[e-mail]>
To: [e-mail]

     After implementing a Kermit on my NCR Tower (version III with Berkley
enhancements) and successfully communicating with a VAX Kermit I decided to
widen my horizons and try to communicate with an Amdahl 470.  This is the
general configuration of the machines:

   TOWER          PAD        AMDAHL 4705        VM          UTS
                x.28           pp04

After some attempts I decided to ask the 'cloud' about this.   Does the 4705
eat any control characters???   Does anyone else have this type of config???
If so, how did they get it working.  If anyone has any ideas and/or ways
of attacking the problem I would surely like to here from them.

                                             steve reynolds

[Ed. - Note that Unix Kermit, as distributed, operates correctly on 370-
series mainframes running UTS, with 3705-style front ends.]

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

End of Info-Kermit Digest
*************************
-------
28-Dec-84 12:28:51-EST,17258;000000000000
Mail-From: SY.FDC created at 28-Dec-84 12:28:33
Date: Fri 28 Dec 84 12:28:33-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest, V1 #45
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 28 Dec 1984       Volume 1 : Number 45

              Special MS-DOS Kermit 2.27 Feedback Issue:

                  2.27 Broken (then fixed) for Z100
                       Display Problems on Z100
                Bug in File Transfer Filename Display
                        H19 Emulation Problem
                    File Transfer Display Problem
                   Fixes for NEC APC Support Module
                 Re: Fixes for NEC APC Support Module
                             Various Bugs
                         Problems on Wang PC
                 Kermit Can't Always Find COMMAND.COM
                       TI Professional Support
                          Mode Line Control
                         (More) Various Bugs
                        MS-DOS Kermit and DTR

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

From: Frank da Cruz <SY.FDC@CU20B>
Date: 28 Dec 84 12:00:00 EST
To: Info-Kermit
Subject: Special MS-DOS Kermit 2.27 Feedback Issue

This issue of the Info-Kermit digest is devoted to feedback received on
the recent release of version 2.27 of MS-DOS Kermit, announced in V1 #43
of the digest on December 7, 1984.

A few major problems were reported, which prevented certain systems from
working at all (notably the Z100) under 2.27; these were promptly fixed.
Remaining problems are left for the next release, 2.28.

All known problems with version 2.27 are listed in the file
KER:MSKERMIT.BWR which, like all Kermit files, is available via anonymous
FTP from host CU20B.

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

Date: Sat 8 Dec 84 01:23:28-PST
From: [e-mail]
Subject: 2.27 Broken for Z100
To: [e-mail]

        Just FTP'ed the new 2.27 version of MSZ100 (the .EXE file), and
Kermited it (via version 2.26).  It works for the most part, so I don't
think anything went wrong with the file transfer.  However, I've encoun-
tered the following serious flaws this evening -

1.) The STATUS command immediately crashes the system - must be rebooted.
2.) The SET PORT command responds with: not implemented (which I expected)
and then crashes the system; certainly one way to emphasize the 'not
implemented' status.

        Other commands which do work include: REMOTE, PUSH, SPACE, LOCAL,
HELP, DIRECTORY, GET, EXIT, RUN, FINISH, and CONNECT.

        /Jim

[Ed. - Thanks for pointing out the problem; some fast action by Jim
Knutson (UT) and Jeff Damens (CU) seems to have fixed the problem -- the
fixed files are in KER:MSXZ100.ASM and KER:MSZ100.BOO, and KB:MSZ100.EXE
(binary) on CU20B, as of December 11.]

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

Date: Tue, 11 Dec 84 14:19:44 cst
From: [e-mail] (Jim Knutson)
To: Info-Kermit@CU20B
Subject: Display Problems on Z100

MS-DOS Kermit 2.27 now seems to work on the Z100.  But here remain a couple
minor problems:

The SPACE command doesn't echo CRLF before CHKDSK runs.  This causes the
prompt and command to be overwritten.

The return from push assumes a screen redraw/switch.  It looks funny without
it since the space you type to continue does nothing.  Perhaps checking to
see if screen switching is taking place and then blow out a message like
[Back in connect mode.] if the switch won't occur.

Jim

[Ed. - next release.]

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

From: ihnp4!islenet![e-mail]
Date: 7 Dec 84 20:12:54 CST (Fri)
To: Info-Kermit@CU20B
Subject: Bug in File Transfer Filename Display

Using MS-DOS Kermit 2.26, if I do a SEND MSWANG.BOO at the remote Kermit,
then escape back to my local Kermit-MS and RECEIVE B:MSKERMIT.BOO, the
status display puts the B: in front of the wrong filename:

        Filename:  B:MSWANG.BOO  AS  MSKERMIT.BOO

[Ed. - This same behavior persists in v2.27, and may be fixed in the
next release.]

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

Date: Mon, 10 Dec 84 12:55:28 pst
From: Dave Tweten <[e-mail]>
To: [e-mail], [e-mail]
Subject: MS-Kermit 2.27 H19 Emulation Problem

     I picked up a copy of MS-Kermit 2.27 the afternoon of Friday,
December 7, as soon as I received the announcement.  Over the weekend,
I tried it out, and concluded that one of its advertized fixes didn't.

     I used 2.27 to log onto our UNIX 4.2 BSD system and "man kermit"
(what else?).  Kermit still has the old problem of inverse blanks beyond
the end of the line following one which ends in an inverse character.
Incidently, I am sure the problem resides neither in our termdef files,
nor in the "more" utility.  I have borrowed a real H-19 long enough to
confirm that our "more" and our termcap do not produce this effect on
a real H-19.

     I inserted fixes for the inverse video problem into MSYIBM.ASM for
MS-Kermit 2.27.  They seem to do the trick.  They are based on my belief
that a real H-19 will provide black blanks for a scroll or a clear
command, regardless of whether inverse video is on.  The changes are
presented below as "fc" output.

[Ed. - Code omitted.  Next release.]

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

Date: Mon, 10 Dec 84 12:55:28 pst
From: Dave Tweten <[e-mail]>
To: [e-mail], [e-mail]
Subject: MS-Kermit 2.27 File Transfer Display Problem

The "non-blanking of K bytes transferred" problem (fixed in 2.27) also
affected the retry count, when in server mode.  When you aren't in server
mode, each new command produces a whole new status display, but when you
are in server mode, only the retry count is restarted - without first
blanking the line.  I fixed that the same way 2.27 fixed the K-bytes
display - by inserting a blank-to-end-of-line call in the positioning
routine.  2.27 doesn't seem to have it.

Thanks again for providing an excellent product.

[Ed. - Code omitted, next release.]

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

Date: Wed, 12 Dec 84 07:16:22 pst
From: dual!islenet![e-mail]
To: SY.FDC@CU20B
Subject: Fixes for NEC APC Support Module

The problems reported with the display on the NEC APC seem to be due
to an instability in the video memory that varies from one NEC APC to
another.  One of the two APC's that I have access to behaved just as he
described, while the other showed it hardly at all.

I have fixed the instability in these two APC's by adding a couple of delay
loops in the module. Hopefully this will take care of the problem in all
cases, although I feel a little unsettled by the difference between the
two here.

I have also added the two delay loops to the UART mode setting code as
Ron Blanford requested. Not having the optional second serial port
myself, I am unable to verify this aspect of his code.

Ian

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

Date: Thu 13 Dec 84 13:43:16-PST
From: Ronald Blanford <[e-mail]>
Subject: Re: Fixes for NEC APC Support Module
To: [e-mail]

I've checked out Ian's fixes and added one of my own, and now all the
problems have been fixed.  The new versions of MSXAPC.ASM and MSAPC.EXE
are on my account and available for anonymous ftp.

-- Ron

[Ed. - Thanks!  The new files are in KER:MSXAPC.ASM, KER:MSAPC.BOO,
and KB:MSAPC.EXE on CU20B, as of December 13th.]

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

Date: 14 Dec 1984 1615-EST
From: (Joe Smith, Colorado School of Mines, via) LCG.KERMIT@DEC-MARLBORO
To: EIBEN@DEC-MARLBORO
Subject: Various Bugs

1. BUG: MS-KERMIT cannot send packets while SET LOCAL-ECHO ON.

  CURE: Ignore the setting of LOCAL-ECHO when transmitting packets.



2. BUG: Problems in RECEIVE FILENAME.EXT when FILENAME.EXT exists.

I told KERMIT-10 to SEND MSKERM.HLP and KERMIT-MS to REC MSKERMIT.HLP when
MSKERMIT.HLP already existed on the floppy.  It tried to rename the incoming
file, but got confused as to which name to add the "&" to.  MSKERMIT said
"File name: MSKERM.HLP AS MSKERMIT.HLP", then "Renaming file to MSKERMITHLP"
(note no period), then aborted with "?Unable to create file".  Even stranger
things happen when both MSKERM.HLP and MSKERMIT.HLP exits.  Then MSKERMIT
says "Renaming file to MSKER&IT.HLP".  The ampersand is in the wrong position,
and it should have never checked for the existance of MSKERM.HLP when I tell
it to store the incoming file as MSKERMIT.HLP.



3. PROBLEM:  Using SET LOCAL-ECHO ON does not work too well with 2 micros.
        There is no automatic linefeed when the RETURN key is pressed.

 CURE:  When a CR is typed at the keyboard while LOCAL-ECHO is on, echo it
        as CR and LF, and set a flag signifying that an automatic LF was sent
        to the screen.  If the host then sends a LF while this flag is set,
        ignore the 2nd LF (to avoid unwanted double spacing).

  ALTERNATIVE:  Define a new command, SET REMOTE-ECHO ON.  When this flag is
        set during a CONNECT operation, input from the keyboard and from the
        modem are logically "OR"ed together and echoed to both the screen and
        the modem, with LF after CR.  This feature will be designed to allow
        two micros to be used as conversational terminals, when one is in
        SET ECHO REMOTE and the other in SET ECHO OFF.



5. SUGGESTION:  Replace HEATH19 keyword with TERMINAL-EMULATION.

With proper synonyms, SET TERMINAL-EMULATION ON would be same as the command
SET TERMINAL HEATH-19.  I feel the phrase "TERMINAL-EMULATION" is more
descriptive, and would allow additional keywords, such as VT102, VT125, and
TEKTRONIX.  This has been partially implemented in MSXTIPRO.ASM
Better yet, SET TERMINAL TYPE HEATH-19 and SET TERMINAL ID-SEQ VT100 and
SET TERMINAL WRAPAROUND OFF, etc.

6. The portion(s) of the manual showing how to bootstrap using the
FORTRAN program on a DECsystem-10 are wrong.  Under TOPS-10, only one
logical name can be assigned to a TTY at a time; the Fortran side of the
bootstrap has to be changed.


Joe Smith, CSM Computing Center, Golden CO 80401 [phone]

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

Date: Mon 17 Dec 84 13:33:47-PST
From: Ted Shapin <[e-mail]>
Subject: Problems on Wang PC
To: [e-mail]

I found what was causing the "Write fault error writing device AUX"
error message.

I had copied the WANG config.sys file which loaded the SER1DRVR.  This
driver is for a printer and interferes with using the serial port for
communications. Once I removed it, MSWANG worked.

The following does not work:

STATUS cuases a loop sending blanks to the screen. RUN filename gives
a message "unable to execute program".

(This is for version 2.27.)

Ted.

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

Date: Mon 17 Dec 84 13:35:12-PST
From: Ted Shapin <[e-mail]>
Subject: Kermit Can't Always Find COMMAND.COM
To: [e-mail]

I think MSKERMIT has a problem finding COMMAND.COM when it is not in the
root directory. (This applies to versions 2.27 and 2.26.)

I have command.com in a separate sub-directory with the following in
CONFIG.SYS:

shell=c:\bin\ibm\command.com c:\bin\ibm /p

If I type DIR, I get the error message "Unable to execute program".

DIR will work if I use a vanilla DOS system with command in the root dir.

Ted.

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

Date: Sunday, 9 December 1984 14:59:56 EST
From: [e-mail]
To: [e-mail]
Subject: TI Professional KERMIT

Recently, you posted on CMU's Info-Kermit bboard that a version of KERMIT
for the Texas Instruments Professional Computer is available.

MSTIPRO.EXE (converted from .BOO) behaves strangely on the Portable
TI-PPC.  On either the desk-top or portable model it sets the initial
baud rate strangely; on the desk-top it accesses the disk briefly, but on
the portable is has a divide overflow and bombs.  If you know any owners
or users groups for the TI who use KERMIT, I would like to meet them.

Lastly, I am in need of a KERMIT for the NCR Decision-Mate V.  The
generic MS-DOS Kermit did not work.  I've heard rumors that a version
already exists.  If you are not aware of one, can you post this request
on your next Info-Kermit digest?

Thank you.         -Josh ([e-mail])

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

Date: Thursday, 27 December 1984 21:25:55 EST
From: [e-mail]
To: Frank da Cruz <SY.FDC@CU20B>
Subject: Re: TI Professional KERMIT

Thanks for your help with TI Pro KERMIT.  The Tektronix emulation is
fantastic!  I have forwarded a copy of MSTIPRO.EXE to the Washington DC
TI Professional user group for distribution.

I am still having trouble with my NCR Decision Mate V, however.  Even the
new generic KERMIT refused to work.  In the MS-DOS documentation for the
system, it refers to the COM port as \dev\aux and the error KERMIT gives is
that it cannot get a  handle on the communications port.  I think this may
be the cause.  Can you think of an easy way to fix it?  If not, I have heard
that a version for the NCR already exists.  Can you post a request for
information on your next info-KERMIT bboard?

Thanks a lot.    -Josh

[Ed. - Generic DOS Kermit 2.27 has several ways to let you try to get at
the communications port -

SET PORT n        (n is 1 or 2 or 3 ... for COM1, COM2, COM3, ...)
SET PORT DEVICE s (s is the device name, e.g. AUX, \dev\aux, etc.)
SET PORT HANDLE n (n is a small integer corresponding to the DOS device handle)

If you try enough of these, you should be able to hit one that works.]

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

From: Doug Brutlag <[e-mail]>
Subject: Mode Line Control
To: [e-mail]

        I FTP'd the IBMPC version of KERMIT 2.27 when it was released and
have found no bugs in a couple of weeks of work.  I am particularly happy
with how well it interacts with PROKEY allowing me to use that function
for general key redefinition (as I did with 1.20) as well as defining keys
in MSKERMIT.INI files.

        I only have one suggestion for improvement.  One can remove the
MODE line only with the control-] M command in terminal mode.  I would
suggest that there be both a SET MODE-LINE ON/OFF toggle command and that
the setting of the toggle be included in the STATUS report.  The main
reason for the suggestion is that then one could include SET MODE-LINE OFF
in a KERMIT.INI file so that the user not have to ever see the mode line
if he wanted.  Of course I would leave the default value of this parameter
to ON so that one would specifically have to turn it off with the command
or in the INI file.  Is there a way to do this now without control-] M?

[Ed. - On the list for the next version.  For a quick fix, see below.]

        Congratulations on the best piece of public domain software that
I have ever seen.

Doug Brutlag

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

Date: Wed, 19 Dec 84 12:21:34 cst
From: allegra!noao!utastro!nather@Berkeley (Ed Nather)
To: noao!allegra!ucbvax!info-kermit@Berkeley
Subject: Various Bugs

MS-DOS Kermit v2.27 always adds the "." character to an uploaded filename
if it originally had no extension.

Kermit v2.27 for the IBM-PC fails to show the mode line in inverse video on the
file transfer display.  Apparently the DOS function 6 (write a string) does not
preserve the attribute byte, set to inverse video before the call to `dos' --
so the text was displayed normally (bright on dark) but the rest of the mode
line, at the far end, was inverse video.

Kermit v2.27 attempts to accomodate Unix buffs who have changed the default
path separator from `\' using the (undocumented) configuration command
"switchar=\", thus reversing the use of `/' and `\' in MS-DOS, and almost
succeeds.  The directory command gets confused, however, by the switch
character reversal.  [BEWARE!  The "switchar=" command has disappeared from
MS-DOS 3.0 and may never appear again. (*sigh*)]

[Ed. - Code omitted, next release.]

Kermit, by default, connects to the host with the mode line displayed.
This can be changed to suppress the mode line, by default, by making the
following change in msterm.asm:

targ    termarg <4,1,80,24,cptchr,2dch,0,scntab,deftab,0,,parnon>
                 |
                 `---(was 0)

Ed Nather
Astronomy Dept., U. of Texas
{allegra,ihnp4}!{noao,ut-sally}!utastro!nather

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

Date: 18 Dec 84 09:21:40 PST (Tue)
To: info-kermit@cu20b
Subject: MS-DOS Kermit and DTR
From: Mike Iglesias <iglesias@uci-750a>

Can MS-DOS Kermit toggle DTR?  We have a Develcon Dataswitch that uses DTR
to tell when to get a new connection to a different computer.  If it
doesn't have it, can it be added in a future release?

[Ed. - On the list for the next release.]

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

End of Info-Kermit Digest
*************************
-------
31-Dec-84 10:18:42-EST,10238;000000000000
Mail-From: SY.FDC created at 31-Dec-84 10:18:25
Date: Mon 31 Dec 84 10:18:25-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #46
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Mon, 31 Dec 1984       Volume 1 : Number 46

Departments:

  ANNOUNCEMENTS -
        Kermit for MUSIC
    More Kermit Articles
        UUCP Kermit Distribution Instructions

  MISCELLANY -
        Kermit over Arpanet/Milnet TAC's
        P/OS Kermit V1.0 Terminal Emulation
        Suggestions for CP/M-80 Kermit

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

Date: Wed 26 Dec 84 15:08:18-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit for MUSIC
To: [e-mail]

A version of Kermit for the McGill University System for Interactive
Computing (MUSIC), a timesharing system for IBM 370-series mainframes, has
been contributed by Marie Schriefer of Indiana/Purdue University.  It is
based on the VM/CMS version of Kermit and has about the same capabilities
(lacking only the ability to do wildcard SENDs).  The files are available
via anonymous FTP from host CU20B, under KER:IMUSIC.ASM (source) and
KER:IMUSIC.DOC (documentation).

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

Date: Fri 28 Dec 84 11:08:18-EST
From: Frank da Cruz <[e-mail]>
Subject: More Kermit Articles
To: [e-mail]

PC TECH JOURNAL has a feature article on Kermit by Augie Hansen, starting
on page 110 of the January 1985 issue.  This article came as a surprise to
us, but considering that we weren't asked about the material it's
unexpectedly accurate (if somewhat dated).  It's mostly a rehash of
material from our BYTE article (June and July 1984), the manuals, and some
tidbits gleaned from source code.  There are just a few nits worth
picking:

. Kermit is not in the public domain.  Most Kermit programs are
  copyrighted, but come with permission to copy and redistribute them
  freely, so long as it's not for profit.

. Most major Kermit implementations are now capable of user/server
  operation.

. Figure 4 is a "transaction diagram", but it omits one of the most
  important features of a Kermit transaction -- the epilogue, in which the
  EOT packet tells the recipient that the transaction has ended (e.g. that
  all files in the group have been sent).

An accompanying article on p.130 describes a product called "Telios", one
of the many commercial programs appearing on the market that include
Kermit, Xmodem, terminal emulation, and modem control (dialing, scripts,
etc).  A similar product, "MLink", was announced on page 221 of December
1984 Data Communications.

PC Magazine for January 1985 has a feature article on Micro-Mainframe
communications by Bill Catchings (SY.WBC3), and an accompanying article
"The Async Link" by Frank Derfler surveys several asynchronous protocols,
including Kermit, and even provides a reader service number to circle on
the bubble card (gasp!).

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

Date:     19 Dec 84 11:41:42-CST (Wed)
From:     Mark Vasoll <[e-mail]>
To:       Frank da Cruz <[e-mail]>
Subject:  UUCP Kermit Distribution Instructions

   You need to set up "okstate" as a site in your "L.sys" UUCP dialing file
using the information listed below.  You can then issue the following
command on your system:

    uucp okstate\!/u/kermit/cpm\* /usr/spool/uucppublic

   (this example will retrieve the CP/M version of Kermit)

I chose "/usr/spool/uucppublic" as the destination on your system since
the destination must be WIDE OPEN (drwxrwxrwx) to everyone.  You should
not remove files from your uucppublic until the entire transfer is complete
including any redials that are necessary.  If you do remove some files
our system may retransmit them, resulting in a higher phone bill for
you.

   There are 2 files available that contain information about the entire
distribution.  We recommend that you retrieve these files first.  They
are "00readme.txt" which explains the file name conventions used, and
"00directory" which is a complete listing (by name) of all files in the
distribution.  These files will enable you to choose the right files
the first time to save those high dollar phone bills.

- UUCP Login information -

    UUCP distribution of Kermit is provided as a public service of:

    Oklahoma State University
    Department of Computing and Information Sciences
    Stillwater, Oklahoma

UUCP login information for site:  okstate

Phone number :  [phone]  (one line only)
Login name   :  uucpker
Password     :  thefrog
Hours        :  10:00pm - 10:00am central time (7 day per week)
Problem      :  okstate!uucp-support  (UUCP)
  reports    :  uucp-support%okstate@csnet-relay  (ARPA)


The phone number is for 300/1200 baud (bell compatible).

Mark Vasoll
Department of Computing and Information Sciences
Oklahoma State University

       ...!ihnp4!umn-cs!isucs1!\
UUCP:     ...!ucbvax!mtxinu!ea! > okstate!vasoll
       ...!convex!ctvax!uokvax!/

ARPA:  [e-mail]

P.S. -- The system Okstate will be down from 8 a.m. on January 8th until 5 p.m.
on January 9th to make some changes in our configuration.  When services resume
on January 9th no changes should be evident to our UUCP connections.

Please note that UUCP Kermit distribution will not be available during this
time, but will resume on January 9th at 5 p.m.

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

From: Jim Guyton <guyton@rand-unix>
Date: 23 Dec 84 22:17:32 PST (Sun)
To: Info-Kermit-request@columbia-20
Subject: Kermit over Arpanet/Milnet TAC's

Excuse me if this is already documented, but it might be worth a
note in the Kermit user's manual on how to run kermit over TAC's.

What I've read / figured-out is  ...

 1) Use the "@B O S" and "@B I S" commands to the tac
    to get into binary mode, and

 2) Reduce the size of the send buffer (by "set send packet-size 25"
    to the ibm pc version of kermit).

This combination just worked over a two-network hop (milnet-arpanet-randnet)
but that a packetsize of 96 was too big for the tac took me by surprise.

Anyway, just fyi ...

-- Jim

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

Date: 21 Dec 84 19:46:25 EST
From: D. M. Rosenblum <DR01@CMU-CC-TE>
Subject: P/OS Kermit V1.0 terminal emulation
To: Info-Kermit@CU20B

Several months ago I included a question about a problem with P/OS Kermit V1.0
terminal emulation in a long message asking various Kermit questions.  I never
heard anything more about it.  I'm wondering if you could either include this
message in the next Info-Kermit digest, or pass it on to the folks at Stevens
who take care of P/OS Kermit.  (Note to anyone at Stevens who is reading this
as a result of either method of transmission: the system I work on here at
C-MU is on the same DECNET as the Stevens machines, so anyone who is qualified
and willing to discuss this should be able to send me mail, to DR01@CMCCTE.)

The problem is that if I am doing terminal emulation in P/OS Kermit V1.0 and I
connect to a VAX-11/780 running VMS V3.7, and I do a SET TERMINAL/INQUIRE, I
get a "%SYSTEM-W-DEVREQERR Device request error" message, and the terminal
type is not set (it remains at the system default, viz. Unknown).  I have to
do a SET TERMINAL/DEVICE=VT100 to set the device, which is annoying because my
LOGIN.COM is set up to do an automatic SET TERMINAL/INQUIRE.  Is it possible
that I have some parameters set incorrectly?  The settings that I use (for the
ones that seem to be at all possibly relevant) are:

Line: Receive speed    4800    Terminal: Local echo            Off
      Transmit speed    4800          Transparent function keys    Off
      Parity        None          IBM-Flag            Off
      XON/XOFF        ENABLED          7-Bit character codes        On

Any advice that anyone reading this can give would be much appreciated.
Thanks.

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

Date: Wednesday, 26 Dec 84 10:48:12 EST
From: rmcqueen(Robert C McQueen)[e-mail]
Subject: P/OS Kermit v1.0 terminal emulation
To: dr01@CMU-CC-TE, SY.FDC@CU20B

Problem:
        SET TERMINAL/INQUIRE gives an error message under VMS version 3.7
        for PRO/Kermit terminal emulation.

Diagnosis:
        PRO/Kermit always responds that it is a Pro350 to the terminal id
        request.  PRO/Communications has the option of responding as if it
        were a VT102, VT125 or Professional.

Cure:
        [Sorry, but...]  It is my understanding that VMS 4.0 will support the
        new terminal types (VT2xx and Professional).

- Bob McQueen

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

Date: 27 Dec 1984 0520-EST
From: LCG.KERMIT
To: EIBEN
Subject: Suggestions for CP/M-80 Kermit

      Suggestions for KERMIT-80:

Send XON before any NAK packet.

Read 64 file names at a time.

Change INTCHR in CP4TT.ASM to not ignore modem when waiting for ^\S.

If "P" or ^P is typed after the ESCape char, toggle SET PRINTER ON/OFF ala CPM.

Add "DELete" as synonym for "ERA".

Call the DIR routine in ERAse to tell user what files were deleted.

Add "REMOTE DIR" and related commands.

Add "REMOTE SET FILE BYTE-SIZE 8" command (for talking to KERMIT-10/20).

Put 8080/Z80 test in init code, MOVER in independent part.

      Suggestion for VT180:

When DEBUG is on, set the limited scrolling region to lines 13-24 and set
jump scroll.  Show the text of the file being transmitted or received in
this area, with all characters execpt TAB, CR, and LF in # form.
Because the serial line to the VT100 screen is always faster than the
line to the modem, it is possible to send 1 character to the VT100 each
time through the loop that checks on the modem and not lose any characters
from the modem (provided that the user does not type Control-S).

Joe Smith, CSM COmputing Center [phone] [phone]

[Ed. - Good suggestions; most of these have been on the list for some time.]

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

End of Info-Kermit Digest
*************************
-------
 5-Feb-85 16:10:21-EST,5392;000000000001
Mail-From: SY.FDC created at  5-Feb-85 16:09:41
Date: Tue 5 Feb 85 16:09:41-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #1 -- New Unix Kermit
To: [e-mail]
cc: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue,  5 Feb 1985       Volume 2 : Number  1

  ANNOUNCEMENTS -
      New Unix Kermit Available for Testing

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

My apologies for the long delay since the last issue of the Info-Kermit
Digest, which was Vol.1, No.46, dated 31 December 1984.  This first issue
of Volume 2 is to announce a test release of the new Unix Kermit.  In
subsequent issues, I'll attempt to catch up on other overdue items.

A new Kermit program has been written in C, initially for 4.2 Berkeley Unix.
The features of this program include:

. Full implementation of the Kermit protocol, except for Attribute packets:
  - Acts as server
  - Talks to server
  - All packet encoding and error checking options are provided
  - File transfer interruption
  - Filename collision avoidance
  - Binary and text file transfer
. Modular construction for easy portability to other systems
. An interactive command parser as well as Unix-style command line arguments
. Command and initialization files
. Piped operation
. Improved terminal connect, with optional logging
. Logs for debugging, packets, and transactions
. Communication with IBM mainframes

Several items on the wish list were not done for lack of time.  They will
probably be added in the future:

. File attributes
. Command macros
. Login scripts
. Raw file transmit

The new program is called "C-Kermit" because it is intended as a basis for
Kermit programs for any systems that have C compilers.  Its version number
is 4.0, to distinguish it from earlier releases of Unix Kermit, the most
recent of which was 3.0.

This prerelease test version of the program runs only under Berkeley Unix 4.2.
We also intend to bring it to the following systems within the coming weeks:

. DEC Pro-350 and Pro-380 with Venix (a Unix v7 derivative)
. Amdahl UTS on IBM 370-series mainframes
. Apple Macintosh (maybe)

Support for other systems will have to be added elsewhere.  The program is
being "pre-released" at this time for two reasons:

1. It seems to be perfectly usable on Berkeley 4.2 systems, and is an
   improvement over the previous version.

2. The modular design may need some adjustment to accommodate certain systems.
   Before a great deal of additional coding is done, it is highly desirable
   to get the design and specification of the system-dependent modules stable.

Therefore, please take the files, read the documentation, try running the
program on your Berkeley Unix system if you have one, and send comments or bug
reports to me as soon as you can.  If you have a Unix system that is not
Berkeley Unix, or a non-Unix system with a C compiler, please take a look at
the system-dependent modules to see how they could be adapted to your system;
again, if you have any suggestions or criticisms of the design, please let me
know.  I'm particularly interested in issues of portability.  After a round or
two of this, perhaps the design can be agreed upon, and then those who would
like to contribute support for Version 6, System III, System V, Xenix, PC/IX,
etc etc, can do so without fear of running into other people's changes for
other systems.  Before attempting to adapt C-Kermit to a new system, please
let me know so I can tell you whether someone else is already at work on the
same thing, and perhaps put you in touch.

The files are on CU20B as KER:CK*.*, available via anonymous FTP.  The file
CKERMI.DOC provides user-level documentation as well as a description of the
program organization and hints for adapting it to new systems.  Within several
days the files should also be available on BITNET via KERMSRV (to get started
with KERMSRV, type SMSG RSCS MSG CUVMA KERMSRV HELP), and to Unix systems via
UUCP from Oklahoma State University, Stillwater, OK.

Here's how to UUCP to OK State:

You need to set up "okstate" as a site in your "L.sys" UUCP dialing file
using the information listed below.  You can then issue the following
command on your system:

    uucp okstate\!/u/kermit/ck\* /usr/spool/uucppublic

   (this example will retrieve the new Unix version of Kermit)

The "/usr/spool/uucppublic" is chosen as the destination on your system since
the destination must be WIDE OPEN (drwxrwxrwx) to everyone.  You should
not remove files from your uucppublic until the entire transfer is complete
including any redials that are necessary.  If you do remove some files
our system may retransmit them, resulting in a higher phone bill for you.

-- UUCP Login information --

Site Name    :  okstate
Phone number :  [phone]  (one line only)
Login name   :  uucpker
Password     :  thefrog
Hours        :  10:00pm - 10:00am central time (7 day per week)
Problem      :  okstate!uucp-support  (UUCP)
  reports    :  uucp-support%okstate@csnet-relay  (ARPA)

The phone number is for 300/1200 baud (bell compatible).

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

End of Info-Kermit Digest
*************************
-------
 7-Feb-85 17:58:46-EST,4098;000000000001
Mail-From: SY.FDC created at  7-Feb-85 17:58:12
Date: Thu 7 Feb 85 17:58:12-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #2
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu,  7 Feb 1985       Volume 2 : Number  2

Topics:
                  Unix Kermit 4.0 for Other Systems
                        New Kermits on the Way

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

Date: Thu 7 Feb 85 11:21:54-EST
From: Frank da Cruz <[e-mail]>
Subject: Unix Kermit 4.0 for Other Systems
To: [e-mail]

Responses to the Unix Kermit 4.0 announcement have started to come in.
As many of you pointed out, the makefile (ckermi.mak) did not work
"out of the box", due to some last minute name changes.  The errors were
obvious, and most people got around them.

There have been tentative volunteers to take care of support for various
systems.  Volunteers for systems not listed here should contact me so I
can add you to this list, which will be kept up to date in KER:CKWHO.TXT
on CU20B.  If you're interested in contributing to any of the implementations
listed below, be sure to coordinate with the contact, cc to me.

What                             Who

DEC VAX, 4.2 BSD                 SY.FDC@CU20B (Frank da Cruz)

DEC VAX, Ultrix-32               SY.FDC@CU20B (Frank da Cruz)

DEC Pro-350/380, Venix           SY.FDC@CU20B (Frank da Cruz)

IBM 370-series, Amdahl UTS       SY.FDC@CU20B (Frank da Cruz)

Apple Macintosh                  SY.WBC3@CU20B (Bill Catchings)

Masscomp RTU 2.2                 sob@RICE (Stan Barber)

Coherent                         vortex!lauren@RAND-UNIX (Lauren Weinstein)

Callan UniStar 300 with
 Unisoft 68000 System V Unix     EBM@MIT-XX (Eliot Moss)

ATT 3Bx, System V                Chris@COLUMBIA-20 (Chris Maio)

IBM PC, etc, PC/IX               HFISCHER@USC-ECLB (Herm Fischer)

IBM PC, etc, Xenix               HFISCHER@USC-ECLB (Herm Fischer)

Xenix                            HFISCHER@USC-ECLB (Herm Fischer)

Os9                              BLARSON@USC-ECLD (Bob Larson)

Version 7                        vasoll%okstate.csnet@CSNET-RELAY (Mark Vasoll)

2.9 BSD                          hipl!tony@NYU-CMSL2 (Tony Movshon)

4.2 BSD UUCP Line Locking        hipl!tony@NYU-CMSL2 (Tony Movshon)

By the way, there's some question as to whether UUCP line locking can
actually be included in a program that distributed without any kind of
license.

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

Date: Thu 7 Feb 85 17:42:42-EST
From: Frank da Cruz <[e-mail]>
Subject: New Kermits on the Way
To: Info-Kermit@CU20B

Quite a number of new Kermits have arrived in recent weeks, but have not
yet been installed for distribution.  They will be installed and announced
over the next week or two.  Here is a list:

. Alpha Microsystems AM-1000, AM-100L and ELS super-micro systems, written
  in Alpha Micro 68000 assembler (which is different from the Motorola
  assembler) by Bob Rubendunst, Soft Machines, Champaign IL.

. A new release of Kermit for the Cray supercomputer from Leah Miller at
  Los Alamos National Laboratory.

. Sanyo MBC-550 support for MS-DOS Kermit, from Joe Smiley, Du Pont Co.,
  Wilmington DE.

. Burroughs 6800 Kermit from Scott Bertilson at Quest Research,
  Burnsville MN.

. The source for the FORTH version of Commodore-64 Kermit, from Bob
  Detenbeck at the University of Vermont.

. A new release of Harris 800 Kermit from Dave Wilson at University of
  Wisconsin.

. Fujitsu Micro-16S support for CP/M-86 Kermit from C. Barker at
  World Institute for Science & Technology, Long Island City NY.

. DG Dasher terminal emulation for MS-DOS Kermit from Duane Galbi,
  Maine-Endwell High School, Endwell NY.

. Kermit in SP/Pascal for DG AOS and AOS/VS systems, also from Duane Galbi.

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

End of Info-Kermit Digest
*************************
-------
 8-Feb-85 19:07:23-EST,14924;000000000001
Mail-From: SY.FDC created at  8-Feb-85 19:07:03
Date: Fri 8 Feb 85 19:07:03-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #3
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri,  8 Feb 1985       Volume 2 : Number  3

Departments:

  ANNOUNCEMENTS -
        MS-DOS Kermit for Sanyo MBC-550
        New Cray Kermit
        Commodore-64 FORTH Kermit Source Available
        Kermit in Pascal for DG AOS, AOS/VS Systems

  UNIX KERMIT -
        More Unix Kermit Volunteers

  MISCELLANY -
    New MVS/TSO Kermit in PL/I
        Multics Kermit Fix
        Polo Kermit??
    Sacred Characters, a Protocol Issue
    Kermit for PCjr

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

Date: Fri 8 Feb 85 11:32:55-EST
From: Frank da Cruz <[e-mail]>
Subject: MS-DOS Kermit for Sanyo MBC-550
To: [e-mail]

This is to announce MS-DOS Kermit for the Sanyo MBC-550 from Joe Smiley,
Du Pont Co, Wilmington DE.  It requires DOS 2.11 or above.

He has supplied the MSXMBC.ASM system-dependent module, plus an executable
program file built from the version 2.26 sources (any volunteers to try
building a 2.27 version?).

He says he's still working on it, and will submit another version with
full VT100 emulation at some future time.  The files are on CU20B in:

    KER:MSXMBC.ASM - System-dependent module source
    KER:MSMBC.HLP  - Help file
    KER:MSMBC.BOO  - "boo" file for downloading
    KB:MSMBC.EXE   - 8-bit binary program image

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

Date: Wed, 30 Jan 85 16:52:46 mst
From: lfm@LANL (Leah F. Miller)
To: sy.fdc@CU20B
Subject: Cray Kermit

 ... has, to my knowledge, a current grand total of 4 installations: Los
Alamos, Livermore Natl Lab, Sandia in Albuquerque, and Cray Research in
Chippewa Falls, Wisc. So, that makes it rather a curiosity compared to some
others which must have many hundreds of installations.  But user acceptance has
been immediate.  No further updates planned.  It's been a pleasure being
associated with your activities.  Leah Miller

[Ed. - This is by way of announcing a new release of Cray-1 Kermit, which
is now available on CU20B as KER:CRAY.*.]

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

Date: Fri 8 Feb 85 11:37:24-EST
From: Frank da Cruz <[e-mail]>
Subject: Commodore-64 FORTH Kermit Source Available
To: [e-mail]

Bob Detenbeck of the University of Vermont has sent in the FORTH source
screens for his Commodore-64 Kermit.  They are in KER:C644TH.SCR on CU20B.
There is also a short help file, KER:C644TH.HLP.

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

Date: Fri 8 Feb 85 16:55:09-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit in Pascal for DG AOS, AOS/VS Systems
To: [e-mail]

This is to announce a version of Kermit for Data General machines running
AOS and AOS/VS, written in SP/Pascal, contributed by Duane Galbi of
Maine-Endwell High School, Endwell, NY.  The files are in KER:AOSK2.*.

The same person also contributed DG Dasher terminal support for MS-DOS
Kermit, but this cannot be installed for distribution yet because changes
were made to several modules, and these must be reconciled with other
people's changes to the same modules.

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

Date: Fri 8 Feb 85 16:55:09-EST
From: Frank da Cruz <[e-mail]>
Subject: More Unix Kermit Volunteers
To: [e-mail]

Since yesterday, several more volunteers have come forth, and some errors
in the addresses of previous volunteers have been corrected.  Below is the
list as it stands.  It continues to reside in KER:CKWHO.TXT on CU20B...

Meanwhile, there seems to be agreement that the "UUCP line locking" business
can be included in the Kermit program without legal entanglement if the code
is original, and not lifted from a proprietary program like UUCP itself.
Such code has already been contributed by Tony Movshon (see below), but is
not installed for distribution yet.

Another issue that is reported frequently is the length of the character string
constants, particularly in ckuser.c.  These will need to be shortened.  What is
the minimum longest string constant that the smallest C compiler will allow?
Now I know why so many C programs print long messages using a printf for each
line...

DEC Pro-350/380, Venix           SY.FDC@CU20B (Frank da Cruz)
IBM 370-series, Ahmdah UTS       SY.FDC@CU20B (Frank da Cruz)
Apple Macintosh                  SY.WBC3@CU20B (Bill Catchings)
Masscomp RTU 2.2                 sob@RICE (Stan Barber)
Coherent                         vortex!lauren@RAND-UNIX (Lauren Weinstein)
Callan UniStar 300 with
 Unisoft 68000 System V Unix     EBM@MIT-XX (Eliot Moss)
ATT 3Bx, System V                Chris@COLUMBIA-20 (Chris Maio)
IBM PC, etc, PC/IX               HFISCHER@USC-ECLB (Herm Fischer)
IBM PC, etc, Xenix               HFISCHER@USC-ECLB (Herm Fischer)
Xenix                            HFISCHER@USC-ECLB (Herm Fischer)
Os9                              BLARSON@USC-ECL (Bob Larson),
                                  bdale@cmu-cs-g (Bdale Garbee)
Version 7                        vasoll%okstate.csnet@CSNET-RELAY (Mark Vasoll)
2.9 BSD                          hipl!tony@NYU-CMCL2 (Tony Movshon)
4.2 UUCP Line Locking            hipl!tony@NYU-CMCL2 (Tony Movshon)
Prime                            BLARSON@USC-ECL (Bob Larson)
HP9000 Series 200 (HP9836)
 with HP-UX System III           b-davis@utah-cs (Brad Davis)
CP/M (Small C or BDS C)          bdale@cmu-cs-g (Bdale Garbee)

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

Date: Wed, 16 Jan 85 15:58:40 CST
From: [e-mail]
To:   [e-mail]
Subject: New MVS/TSO Kermit in PL/I

Rice has now completed implementing KERMIT under IBM MVS/TSO.  This is a new
implementation of KERMIT for the TSO environment rather than a rework of the
VM/CMS code.  It was written in IBM PL/I and a locally developed TSO command
writing package (which is as of yet unreleased).  Rice TSO KERMIT has been
tested in MVS/SP 1.1.1 environment at Rice and the MVS/SP 1.3 environment at
University of Chicago.

This KERMIT is based on the version 5 protocol manual.  It has been tested
with PCKERMIT 1.20, MSKERMIT(IBM) 2.26, Rice MacKermit (in beta test), and
MSKERMIT (IBM) 2.27.  Server mode is also supported.

We are ready to send an MVS load module, the source, and limited
documentation.  Because we have not yet released the command writing package
used in the source, it is not possible for other users to compile the
source.  (We may decide to submit the package to the SHARE Library which
would solve this issue.)  Both Chicago and Notre Dame were able to install
without modifications to the code containing calls to the command writing
package.

Thanks,
Farrell Gerbode
Rice University Computer Center

[Ed. - Note, we've also received other MVS/TSO contributions, but these
are based on the Chicago assembler version.  A recent arrival from the
University of Toronto has Series 1 support.  This one will be announced
when it arrives, and of course any news about the Rice MacKermit will
also be passed along.  Meanwhile, if somebody at the U. of Chicago (which
produced the original MVS/TSO Kermit) could comment on how this version
should be viewed -- a replacement for theirs, an alternate version that's
only useful for PL/I sites, etc...]

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

Date: Wed 23 Jan 85 09:13:18-EST
From: Paul Amaranth <[e-mail]>
Subject: Multics Kermit Fix
To: [e-mail]

I think I got a fix for that strange problem that was reported in [V1 #44 of
Info-Kermit].  This should work:

The following code should be inserted into the procedure setup_terminal which
is just before the end of the kermit_ module.  My best guess is that an attempt
was being made to change the fnp modes (which included half duplex) before the
current transmission of text was completed.  This code prevents that from
happening.  I talked to the fellow who experienced the problem and he said
that it sometimes happened when receiving, but never sending.  It also depended
on system load.  The only difference in the code is that on SEND, there is a
time delay before the modes are changed, which would let any transmission
complete.

Oh well.  This code has no effect on normal operation.

[Ed. - For now, the patches are in the file KER:MUKMT.BWR.]

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

Date: Wed, 30 Jan 85 16:23:50 EST
From: Dave Swindell <dswindel@bbn-labs-b>
Subject: Polo Kermit??
To: [e-mail]

Does anyone know if a Kermit version exists for a Polo PC??  The Polo is
supposedly 'IBM compatable' (what isn't), however, V2.26 IBM Kermit doesn't
work on it.  We haven't tried generic MS-DOS Kermit yet.  I wanted to see if
anyone else had any 'Polo' experience before I dive in any deeper!

Dave Swindell
BBN Labs

[Ed. - Bill Catchings had a Polo for a evaluation.  He says it is not in any
way IBM compatible.  They claim to be IBM compatible at the data file level;
in other words they can both use the same 1-2-3 files.  Let us know if generic
MS-DOS Kermit works -- by the way, 2.27 generic Kermit has better support for
fooling around with the port designators and file handles than 2.26 did.]

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

Date:  Fri, 1 Feb 85 13:23 CST
From:  "David S. Cargo" <[e-mail]>
Subject:  Sacred Characters, a Protocol Issue
To:  [e-mail]

Here at Honeywell we are running into an issue that I'm sure others have
encountered.  I'll explain what we see happening and then ask for some
discussion about what can be done.

We have a number of systems which, for what ever reason, preempt certain
printing characters.  Sometimes these are the computer systems, and
sometimes it is the network control hardware.  Some of the typical
characters that cause problems are the backslash (hex 5C, "\"), the
pound sign (hex 23, "#"), the at sign (hex 40, "@"), and the tilde (hex
7E, "~").  These symbols are either escape characters (in which case
they can make it through the network if they are doubled), hardwired
editing characters, or network hardware command prefix characters.  Some
of the networks over which we want to use Kermit get very convoluted.
There isn't any way we can see that would allow the problem characters
to be doubled, or escaped in an adequate way.  The only way we can see
that avoids collision with "sacred" characters is to avoid using these
characters at all, in much the same way that avoiding use of the control
characters avoids problems.

The questions that I see this presenting are:  how to specify the
characters that must be avoided, how to communicate the set of
characters to be avoided from one Kermit to another, how to agree on the
set, and how to handle the presense of such characters in the file (or
data) being transmitted.

The last question relates to another problem we have encountered, where
the transmitted file contains characters used by the protocol ("#" for
example).  We can't always pick the protocol characters to match
characters which are not used in the source file.  What is a workable
way to avoid that problem?

Ideally, agreeing on the set of characters would be straight forward.
Each side would be told what characters won't make it through if they
are transmitted to the other end, so it won't transmit that set.
Another alternative would be to not transmit any character in either
set.

The problems I see are in specifying the packet length (which is a
number encoded into a character) and the checksum (which is a number of
various size encoded into one or more characters).  If some characters
must be avoided some values become unrepresentable.  That clearly isn't
satisfactory.

One possibility would be to add a character encoding mechanism which
would take a packet, encode any of the forbidden characters before
transmission, and reconstitute them upon receipt.  This has the
disadvantage of adding another layer to the protocol, requiring the
negotiation of another character, and complicating the packet structure
further (since its length on transmission would grow depending on the
number of characters which had to be encoded).

I am not sure that cure isn't worse than the disease.  Still, it would
provide a way for Kermits to communicate through even more hostile
territory than they can now.  We (at Honeywell) have pragmatic reasons
for wanting some way of setting the characters that must be avoided.
Others probably face the same problem.  I want to open the issue up so
it can be discussed, and ideally a solution agreed upon.  It isn't an
easy issue, but it is an important one.

[Ed. - Kermit was designed on the usually correct assumption that any
printable ascii character can make it from one end to the other unscathed.
In the rare cases when a certain printable is sacred, like the '@' that is
normally used as the TAC escape character, one can either change the Kermit
programs involved to double the character (the normal method for passing
escape characters through a device that looks for an escape character), or
change the escape character to a nonprintable character that differs from
Kermit's packet start, packet end, turnaround, and padding characters (if
any), or put the device in "transparent mode".  Beyond that, I'm afraid that
the cure is indeed worse than the disease -- the likelihood that the
required extra layers of protocol could be added to scores of existing
Kermit programs (3 or 4 scores at last count) is pretty small.  What's worse,
the poor user would have to know to tell Kermit to do this!]

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

Date: Wed 6 Feb 85 18:08:05-EST
From: Bdale Garbee <AG0B%CMCCTE@CMU-CC-TE>
Subject: kermit for pc jr.
To: sy.fdc%CU20B@CMU-CC-TE

Frank -- what is the status of kermit on the PC jr.?  I keep getting
asked about it, and it's getting harder to turn people away.  I haven't
done anything with the MSDOS version before....  reading back issues of
info-kermit pointed me to msibmjr.*, which don't exist.  Does v2.26 work,
and if so, does it work only on the rs232 port?  I think the guy who's
really griping is using some sort of internal modem?

Bdale

[Ed. - The PCjr comes with a built-in modem and an RS232 port.  Kermit 1.20
and later work on the PCjr's RS232 port but not on the modem.  To use the
RS232 port, you have to say 'set port 2', because it's COM2.  We have no
plans to make it work on the modem -- we don't have a PC to play with any
more.  Any volunteers?]

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

End of Info-Kermit Digest
*************************
-------
11-Feb-85 17:33:39-EST,14560;000000000000
Mail-From: SY.FDC created at 11-Feb-85 17:32:57
Date: Mon 11 Feb 85 17:32:57-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #4
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Mon, 11 Feb 1984       Volume 1 : Number  4

Departments:

  ANNOUNCEMENTS -
    Kermit for Alpha Micro 68000 Systems
    New Release of Harris 800 Kermit

  UNIX KERMIT -
    Data compression for C-Kermit fans
    System III Unix Kermit
    Bugs in C-Kermit 4.0

  MISCELLANY -
    Kermit-MS in Color
    Sacred Characters, Cont'd

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

Date: Mon 11 Feb 85 16:43:17-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit for Alpha Micro 68000 Systems
To: [e-mail]

This is to announce Kermit for Alpha Microsystems AM-1000, AM-100L, and
ELS super-micro computer systems, running AMOSL 1.2 or later, written
in Alpha Micro 68000 assembler, contributed by Bob Rubendunst of Soft
Machines, Champaign IL, and also contributed to the Alpha Micro User's
Society and to the on-line AMUS network in Boulder CO.  The files are in
KER:AM*.* on CU20B, available via anonymous FTP.

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

Date: Mon 11 Feb 85 17:05:52-EST
From: Frank da Cruz <[e-mail]>
Subject: New Release of Harris 800 Kermit
To: [e-mail]

This is to announce a new release of Harris 800 Kermit from Dave Wilson
at the University of Wisconsin Academic Computing Center.  It's written in
Harris Pascal.  For those Harris sites that do not have Pascal, a ready-
to-execute load module is available from the Harris User Exchange.  Thanks
to Paul Stevens of MACC for sending it in.  No mention was made of what
the differences are between this version and the first one (September 84).
The files are in KER:H800*.* on CU20B.

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

Date: Fri, 8 Feb 85 16:59:10 pst
From: James Woods <[e-mail]>
To: info-kermit@Berkeley
Subject: Data compression for C-Kermit fans

#  "Shrivel up!" -- DEVO, from their American debut

     Taking advantage of the Lempel-Ziv data compressor now making
the rounds on USENET/ARPANET, C-Kermit users may easily invoke the pair

    compress file | kermit -is -
    kermit -ik | uncompress

for faster file transfer.  How much faster?  Well, the code, which
runs wherever C compilers are sold, typically yields 50-60% reduction
for text, 65-80% for formatted ASCII numerical data, and good rates for
bitmaps.  So, coupled with the fact that compress runs much faster
than typical modem rates (> 60K baud on a VAX 11/750), we have a tidy
savings, even after the 26.6% expansion induced by Kermit's "quoting"
of control characters.  The rates are somewhat less (5-10%) for machines
limited to a 16-bit address space.

     The Kermit designers should be commended for not designing
fancy data compression into the protocol itself.  (This is tough to
do with short packets in any case.)  Of course, the Tinkertoy nature
of UNIX pipelines is also indispensible for this clean separation
of function.  Advise for non-UNIX Kermit users -- weep!

     For a copy of the public domain compress code, contact Joe Orost at
vax135!petsd!joe@berkeley.

     -- James A. Woods    {ihnp4,hplabs}!ames!jaw     (or jaw@amelia)

[Ed. - I agree, pipes are neat.  The 26.6% figure is not a fixed overhead
of Kermit, by the way.  Since 33/128 of the ASCII characters are
non-printable, the 26.6% control-character prefixing overhead will occur
only in files where all ASCII characters occur with equal frequency.  In
fact, most text files have only about 5% control characters.  Kermit's own
dumb data compression also pays off quite well sometimes -- most
dramatically in short binary program files, where lots of contiguous memory
is intialized to 0's.]

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

Date: Sun 10 Feb 85 23:46:41-PST
From: Herm Fischer <[e-mail]>
Subject: System III Unix Kermit
To: [e-mail]

Frank,

ckmain:  String length problems (134 & 1541).  (512 max on Xenix)

[Ed. - I've received reports of various maximum string constant
or fprint argument sizes; the smallest so far is 128.]

ckwart(178): index used in OR (arithmetic) expression... uncool.
can only compare pointers to "NULL" for equality or lack thereof.

index is called strchr in System III versions.

[Ed. - Index will have to be defined inside wart, perhaps
renamed to avoid lawsuits...]

ckwart/main() lacks exit(0) which prevents System III make from
going onto next make step automatically. Add exit(0) call at end
of main().

[Ed. - Fixed.]

ckuser:  obesely oversized... break apart... many strings too long...

[Ed. - Sigh... Let's only do this once.]

ckxbsd and ckzbsd now outfitted with conditional compilations for: system
III, bsd, Xenix, and PC/IX.  I strongly support having only ONE set of
"unix" modules.  Anyway, that is how I did the System III (and PC/IX and
Xenix 3.0 ) port.  Am in final cleanup stages on it.

re uucp Line Locking, I have already found two different System III
versions which do it two different ways.  Will compare your furnished
example code to mine.

Main problems are with ckuser right now: too large to handle with some
compilers!  several strings too long too!

  Herm

ps - am getting messages from Xenix users with OLD version 7 based
Tandy-distributed versions.  It is highly doubtful that the C-Kermit for
Xenix 3.0/Sys III will be retrofittable to V.7 based Xenixes.  That early
one was highly deficient in "unix-like" features...

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

Date: 9 February 1985 15:27-EST
From: Ed Schwalenberg <ED @ MIT-MC>
Subject: Bugs in C-Kermit 4.0
To: sy.fdc @ CU20B

I am attempting to bring up C-Kermit 4.0 under 68000 Xenix.  So far, I've
encountered the following bugs:
1. ckxbsd.c function ttxin does a read(foo,bar,&count) instead of
                  read(foo,bar,count).
   I don't see how this could ever have worked.

[Ed. - Me neither...  It's fixed now.]

2. ckxbsd.c functions ttinl and ttinc declare int c; and int ch; respectively,
   then do read(foo,&c,1), followed by c &= 0377.  This doesn't work on
   machines like the 68000 that have bytes in the opposite order from VAXen.
   Declaring c (or ch) unsigned char fixes it, and obviates the need for the
   masking instruction which follows (assuming 8-bit chars).  The function
   coninc does it right, though.

[Ed. - Thanks for pointing this out; it's fixed now.]

3. ckxbsd.c function ttflui has the comment "What's this???" which agrees
   with the code, anyway.  I see that you use one file descriptor for read
   and write; this code seems to think that by specifying FREAD as the
   argument to ioctl(TIOCFLUSH) you'll only flush input.  I think it would
   be lots more clear and portable to have separate read and write channels.
   In any case, the Xenix documentation claims that the arg is ignored for
   TIOCFLUSH.

[Ed. - 4.2BSD allows you to specify which queue's buffer to flush, read or
write.  For now, I just changed to comment.]

4. "C-Kermit> dir /usr/ed" results in ?File not readable, which seems to be
   deliberate.  Is it?  Why?

[Ed. - Not deliberate; cmifi() checks to see if the specified file is
readable, /usr/ed is a directory file, hence not readable.  This will have
to be fixed.  Meanwhile, use "dir /usr/ed/*" or replace cmifi() with cmfld().]

Other than that, it has gone very smoothly and well.  Congratulations on
a fine piece of work, especially the TENEX-style command completion.  (I
don't care for it as a user interface myself, but I'd much rather have ONE
user interface than 2 (or 3, or 4...).

[Ed. - Everybody wanted an interactive command parser, so I put in the one
I liked best.  I tried to make it easy for others to substitute other parsers
to suit their tastes.]

So now it works for 68000 Xenix, though I want to attack it with prof(1) and
see if I can improve the performance (it loses packets over 2400 baud).

[Ed. - C-Kermit works fine on a VAX with 4.2BSD at 9600 baud, using
xon/xoff.  It'll work even better when someone does a DMF32 driver that
will support DMA.  If you don't have xon/xoff, then tweaking performance is
desirable so long as it doesn't interfere with portability.]

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

Date: Sun 10 Feb 85 00:53:26-PST
From: Jim Celoni S.J. <[e-mail]>
Subject: Kermit-MS in color
To: [e-mail]

Minor glitch in MS-DOS Kermit 2.27:  When on a color display with
foreground/background colors set, Kermit seems to ignore them and
always write to the screen white on black, and the grey + key
replaces the mode line with a black hole instead of writing
background-colored spaces.  +j

[Ed. - Noted.]

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

Date:  8-Feb-85 20:26:40-PST
From: [e-mail]
Subject: Sacred Characters
To: [e-mail]

The "MMDF Dial-up Link Protocol" had a fairly complete mechanism for
handling sacred characters.  I use past tense because I think that CSNET
is using MMDF II these days, and I have no information about that
protocol.  Anyway, here is a quick description of the MMDF sacred
character (and packet length, and escape character) negotiation.

This description is based on an April 1980 document called "MMDF Dial Up
Link Protocol" by Ed Szurkowski.  It is U. of Delaware report
ud-nsf-csnet-81-002.  Parts of this message are taken almost straight
from that report, particularly the big diagram.  This was the second
version of a carefully designed protocol, and I think that Kermit could
get some goodies here ("If you are going to steal, steal good.").

MMDF uses a limited character set for the negotiotiation:  0-9, A-F.
16-bit packet checksums are always sent as four hex digits.  The packet
type is one hex digit, and the flags (Origin, EOF, and a two-bit sequence
number) are in one hex digit.  MMDF can actually work over a link that
allows only hex digits, one escape character, and a way to send a delimited
record (like following the packet with a CR).

These are the packet types for the sacred characters (SC) negotiation:

    XPATH        SC's in my transmit path (and my xmit packet size)
    XPATHACK    acknowledge XPATH
    RPATH        SC's in my receive path (and my rcv packet size)
    RPATHACK    (guess)
    ESCAPE        I will use this escape character
    ESCAPEACK    (guess again)

An XPATH packet looks like this:

+-----+-----+-----+-----+-----+-----+-----+-----+-----+----//----+-----+
|      Checksum         |  2  |Flags|Max. Packet| Illegal Input Chars. |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+----//----+-----+
   1     2     3     4     5     6     7     8     9                40

Max. Packet is two hex digits which are the longest packet that this
host can send.

Bytes 9 through 40 are 32 hex digits which are an encoding of the illegal
output characters for the host.  The hex number is interpreted as a 128
bit vector (one bit for each ASCII character).  If the bit is on (1) in
the vector, that charcter cannot be transmitted by the host.

An XPATHACK packet carries no data.  It just acknowledges an XPATH packet.

The RPACK packet looks exactly like an XPATH.  It describes the limitations
of a hosts receive path.

After a host has successfully sent an XPACK and an RPACK, and received
one of each from the other host, it chooses an escape character based on
all this great information.  The ESCAPE packet contains the normal
header (checksum, type, and flags) and also has the chosen escape
character encoded as (you guessed it!) two hex digits.  This is the
escape character that this host will use to transmit data.  The other
host chooses its own escape character.

All illegal characters are sent escaped, either with special control
character forms (like <ESCCHAR>M for carriage return) or with the general
<ESCCHAR>## form, where ## is two hex digits corresponding to the ASCII
value of the character which has been escaped.

The protocol is used like this:

Host A        Host B
---- -          ---- -
         <--- XPATH    [Host B's xmit limitations]
XPATHACK --->
         <--- RPATH    [Host B's rcv limitations]
RPATHACK --->
XPATH    --->        [Host A's xmit limitations]
         <--- XPATHACK
RPATH    --->        [Host A's rcv limitations]
         <--- RPATHACK
         <--- ESCAPE    [Escape character that Host B will use]
ESCAPEACK--->
ESCAPE   --->        [Escape character that Host A will use]
         <--- ESCAPEACK

DATA     --->
         <--- DATAACK    [repeat as necessary]

         <--- DATA
DATAACK  --->        [repeat as necessary]

QUIT     --->
         <--- QUITACK


I threw the DATA and QUIT stuff in there so that all this wouldn't
seem so pointless.  DATA and QUIT are legal MMDF, of course.

This shouldn't be that hard to add as an attribute (or maybe a
capability bit) with some restructuring of the packet exchanges to keep
the strict packet-ack rhythm of Kermit.  Since Kermit philosophy forbids
negotiations, the ESCAPE/ESCAPEACK might not fit in too well.  The
ESCAPE/ESCAPEACK must be done somehow, though, because the normal Kermit
escape characters cannot escape arbitrary printing characters.

In my opinion, the MMDF escaping is much much cleaner than the Kermit
foobar-quoting approach, but compatability overrides elegance.  Perhaps
the Hex-quoting would be a separate mode.  Sort of a "low gear" for
weird communication paths.

walter underwood

[Ed. - This is undoubtedly a good approach.  Too bad we didn't think of it
when we designed Kermit.  Again, the problems are: (1) getting the code
into a significant subset of the Kermit implementations, and (2) educating
users about it.  The second problem is the worst -- how does a "naive" user
know that if you are connected to Datex-P via a satellite link from Tymnet
gatewayed via X.25 from an Internet host accessed through a TAC dialed
through a (vendor-name-omitted) "smart" modem, ..., what the sacred
characters are?  It's hard to tell whether the effort to handle bizarre
situations like this would be worth it.  Maybe a good first step would be
to learn exactly what roadblocks people are actually running into where
an approach like this might help.]

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

End of Info-Kermit Digest
*************************
-------
13-Feb-85 18:02:00-EST,3269;000000000001
Mail-From: SY.FDC created at 13-Feb-85 18:01:09
Date: Wed 13 Feb 85 18:01:08-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #5
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Wed, 13 Feb 1984       Volume 2 : Number  5

Today's Topics:
                        Kermit in Turbo Pascal
                        6800/6809 FLEX Kermit
                        Color vs IBM PC Kermit
                          Kermit 64 Problem

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

Date: Wed 13 Feb 85 15:01:06-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit in Turbo Pascal
To: [e-mail]

A preliminary version of Kermit written in Turbo Pascal is now available.
It was written by Jeff Duncan (LSM.DUNCAN@DEC-MARLBORO) with an eye toward
portability to the many systems that run Turbo Pascal, but the initial
implementation is for the DEC VT-180 with CP/M-80.  Kermit and/or Turbo
aficionados are encouraged to comment upon it or send support for
additional systems to Jeff.

The files are in KER:TP*.*, available via anonymous FTP from host CU20B.

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

Date: Tue, 12 Feb 85 10:19 MET
From: Decus <@csnet-relay.arpa,@germany.CSNET:[e-mail]>
To: [e-mail]
Subject: 6800/6809 FLEX Kermit

The "D68 User Group" has a Kermit for the 6800 and 6809 porocessors
under the FLEX operating system.

At present it is at the Alpa-Test stage.  It is a minimal system
(connect send receive exit) and has only been tested against a VAX/VMS
Kermit by local users.

If anyone has another 68xx version, is interested in comparing
notes, or wants a copy when it is fit for release, they can contact:

    Peter Bendall
    Post Box 1313
    2359 Hensted-Ulburg
    West Germany

for more details.

[Ed. - This will be announced when it arrives.]

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

Date: Mon 11 Feb 85 22:00:37-PST
From: David L. Pike <[e-mail]>
Subject: Re: Color vs IBM PC Kermit
To: [e-mail]

    I thought I'd comment on the issue of color for ibmpc kermit
v 2.27. The reason for the white on black for the color display is that
the variable 'curattr' is set at 07h in the file msyibm.asm, so that
even if the ansi driver had a different setting this code would override
it.  It's fairly easy to insert your favorite value in there.....

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

Date:     Tue, 12-FEB-1985 01:25 EST
From:     ALLAN TEO <USERLIB@YULEO>
Subject:  kermit 64 problem
To:       KERMSRV@CUVMA

TO whom it may concern,

    I believe the current hex file for c64ker hex is corrupted
in some way.  The program will boot up on the commodore 64 but
will crash after it has been properly saved and re - loaded.
will some one in charge re-assemble another copy of c64ker m65?
Thank You. (Many others have had this strange problem)

[Ed. - The author of Commodore 64 Kermit (the CROSS version, not
the Forth version) indicates that a new, more complete release
will be available soon.]

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

End of Info-Kermit Digest
*************************
-------
15-Feb-85 18:30:42-EST,12221;000000000000
Mail-From: SY.FDC created at 15-Feb-85 18:30:18
Date: Fri 15 Feb 85 18:30:18-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #6
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 15 Feb 1984       Volume 2 : Number  6

Today's Topics:

              Kermit for Fujitsu Micro 16s with CP/M-86
                      Kermit for Burroughs 6800
                     Guide to MS-DOS Kermit Files
                      New Unix Kermit Bug Report
                     Feedback on "ckwart.c", etc.
                      Sacred Characters, Cont'd

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

Date: Fri 15 Feb 85 13:25:22-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit for Fujitsu Micro 16s with CP/M-86
To: [e-mail]

This is to announce Fujitsu Micro 16s support for CP/M-86 Kermit contributed by
Chris Barker, World Research Institute for Science & Technology, Long Island
City, NY.  The program makes use of the Fujitsu's built-in ADM3A firmware for
terminal emulation, and runs at speeds up to 9600 baud.  The 86KERIO module
submitted was for version 2.7 of CP/M-86 Kermit; I compiled it with the current
version, 2.9, without apparent problems.  The files are:

  KER:86*.A86  Source (all unchanged, except for addition of 86KERIO.FUJ)
  KER:FJ*.*    Help and hex files

available via anonymous FTP from CU20B.  The author says he is also working on
MS-DOS Kermit support for the same machine.

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

Date: Fri 15 Feb 85 13:25:45-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit for Burroughs 6800
To: [e-mail]

This is to announce Kermit for the Burroughs 6800, written in Algol by
Randy McLaughlin, Metro-II, St Paul MN.  The following files are included:

  KER:B68KERMIT.ALG     Source of the B6800 Algol program.
  KER:B68KERMIT.NDL     NDL "request sets" to replace READTELETYPE and
                        WRITETELETYPE and associated DEFINE's.
  KER:B68KERMIT.DOC     Documentation for B6800 Kermit.

They may be anonymously FTP'd from CU20B.

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

Date:        05 Feb 85 19:54 +0100
From:        [e-mail]
To:          Info-Kermit@CU20B
Subject:     Guide to MS-DOS Kermit Files

Hi, Frank (and all the rest of the Kermit crew at Columbia)!

I miss very much a file with a complete breakdown on all the MS-prefixed
files.  Their number has grown beyond what is easy to manage. So, I made
such a file.  Here it is. My apologies for any mistakes.  Hope you can keep
it updated and include it in forthcoming releases of the tape.  Share and
enjoy!  -Per Lindberg

[Ed. - This very useful file, which guides your way through the
bewildering array of dozens of MS*.* files, is available in KER:MSAAAA.HLP
on CU20B -- the A's are so it will appear at the top of the MS*.* files in
an alphabetical listing, hopefully attracting some attention.]

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

Date: Thu, 14 Feb 85 16:13:46 est
From: Paul Placeway <[e-mail]>
To: [e-mail], [e-mail]
Subject: New Unix Kermit Bug Report

This may be old news, but I had problems bringing up Unix Kermit on a Sun
Microsystems (BSD 4.2) computer.  (This is ckermit as of Feb. 13 on BITNET.)
Kermit would compile just fine, but would dump core when run.  The fix is
simple: change line 751 of ckuser.c from

       while (feof(tfile[tlevel]) && (tlevel > -1)) { /* If end of take */
to
       while ((tlevel > -1) && feof(tfile[tlevel])) { /* If end of take */

The problem is that the Vax cc(1) changes the order of the check in the if
statement, but the Sun cc(1) dosn't, and so it trys to feof(tfile[-1]) which
gives a core dump.
                                        Paul W. Placeway
                                        The Ohio State University
                                        (UUCP: cbosgd!osu-eddie!paul)
                                        (CSNet: paul@ohio-state)

[Ed. - Thanks.  The same thing happens on Pyramid and probably other Unix
systems too.  This fix now appears in the distributed copy of ckuser.c.
Glad to hear that so little is required to make it work on the SUN.]

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

Date:     Fri, 15 Feb 85 16:14:16 GMT
From:     Chris (K) <[e-mail]>
To:       [e-mail]
Subject:  Feedback on "ckwart.c", etc.

Info & Frank:

1.  WART Preprocessor:

     This does not compile as it stands on 11/44 under Berkeley 2.8
due to use of compiler extensions:
   -   "unsigned char" not supported;
   -   the same member-name may not be used in two different
       structure declarations unless the offset is the same.
Fix is to delete line 44 and change all /CHAR/char/; and to change the
member ->nxt of struct sym to ->next in lines 537, 596, 609.

    After these changes, it compiles but bombs with core-dump due to
overlength printf string (see below).  The culprit is "char *warning" on
lines 66-70.  Split this into 3 separate single-line strings and output by
three fprintf's at line 137.

[Ed. - I ran into the same problems with Wart under Venix and they're
fixed in the current distribution copy, along with a replacement for
the index() function, which turns out not to be portable.]

2.  "printf()" lengths.

     The reason that wart bombed on Berkeley 2.8 is that printf() and its
derivatives use a 128-byte buffer, for unpacking the formatted string
into, before output.  You are in dead trouble (with a core-dump) it any
printf formats to longer than this.  I suspect that this is a more
stringent restriction than you will find in any of the micro-compilers.
For what it's worth, Aztec-C for Z80 rejects strings of more than about
150 bytes.

     Please restrict the format strings used in printf() (& derivatives)
to a single line of text; and think carefully about the resulting
formatted length when strings are inserted by %s.  In particular, you
cannot expect to include the whole of a kermit data block and always get
away with it.

[Ed. - Everyone who's been working on moving C-Kermit to
peanut-whistle Unix systems (like PDP-11's without I&D space) has been
bitten by the printf buffer problem.  As a newcomer to Unix, I must
admit I was shocked that (a) there's any limitation at all, (b) the
limit is so small on some systems, and (c) no checking is done for
overflow.  Various measures are necessary -- reducing the length of
string constants, mostly in ckuser.c; using (f)puts instead of printf
wherever possible.  Some people are already working on this.]

3.  End-of-File Markers (Visual).

     I don't think I trust file transfers in general.  It's very nice to
have some confirmation (apart from a matching closing brace) that the file
you have in your hand is the whole of the one that the remote should have
sent you.  Could we have, as standard, something like a row of 30
asterisks at the end of every kermit source file?

[Ed. - Good idea.  Some day when I have time to add them to the end of
1000 files...  30K of asterisks!]

4.  Menu for Parameters.

     The nicest way (at least to some minds) to set parameters on a micro
is an interactive menu.  I've written one (in C) for the RML 480Z Kermit;
do you want it?  It's not wholly transportable, but I can clean it up
before sending.  It uses up & down arrows to select parameter, right and
left to toggle through up to 10 preassigned settings, alters a variable
(displaying individually assigned value-description) and optionally calls
an action routine as each is changed.  5 lines of help-text available on
each parameter.  Not yet implemented is a facility to enter a hex or char
value for a parameter.  No limit (except storage) to the number of
parameters it will handle.  I'd have to get RML's permission to release
it, since they paid for the work; but I think it would be given.  Of
course, this is not a practical way to set parameters in Server mode; but
I don't see Server being of much use on a single-user micro.  I expect to
make the 480Z answer an incoming PSTN call and respond to GET/SEND; and
that's all.

[Ed. - ckuser.c does attempt to provide menus for commands and settings by
allowing you to type '?' any time in a command.  This is "menu on demand"
-- the experienced user need not be constantly confronted with menus, but
inexperienced users can get them when needed.  'set ?' gives a menu of
parameters; 'set parity ?' gives a menu of the parity settings, 'help set
parity' gives a fuller explanation of parity, etc.  All this works without
knowing anything about the terminal -- no termcap, curses, no reliance on
terminal-dependent function keys.]

5.  General.

     It'll be some time before I can do anything much with the new
C-Kermit, but it looks a fine job.  In particular, it should be very easy
to extract the whole of the protocol and parameter handlers for use on
systems whose architecture and command-language differ markedly from unix.
I will feed back info as I get on with it.  Thanks.

                                        Chris Kennington.

[Ed. - Thanks -- that's the idea.  We hope to use ckprot.w and ckfns.c as
the core of a new Macintosh Kermit -- the user and system interfaces will
be totally different.

There are a few other problems that have to be resolved, too.  Perhaps the
biggest one is reworking the logic used in switching between connect and
protocol to prevent some Unix implementations from releasing and possibly
hanging up the line whenever one escapes back to command level.  Herm
Fischer (HFISCHER@USC-ECLB) is working on this, plus some of the problems
listed above, while creating versions of C-Kermit for System III, PC/IX,
Xenix, etc.  There should be some results to announce soon.]

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

Date:  Fri, 15 Feb 85 02:21 EST
From:  Paul Schauble <[e-mail]>
Subject:  Sacred Characters, Cont'd
To:  [e-mail]

About two years ago I did a study for Honeywell on all of the then current
asynchronous communications protocols.  The conclusion was that Kermit
could not be implemented on their mainframes because they reserved @ as a
non-changeable character delete.  I believe that ARPANet users also have
problems with this character.

Because of the problems with various networks, forbidden characters have
to be specified by the user.  Just provide a SET that can be put in the
start-up and assume that the implementor will build in those that are
sacred to the operating system.

You still have to communicate them to the other end.

What I would like to see is a Kermit II protocol, that can be
non-compatable with Kermit I.  There is a lot of useful accumulated
experience now, and it would be a real shame to not be able to use it.
Kermit II would have windowing, sacred character negotiation, packet size
negotiation, and maybe multiple logical channels.  Is this politically
possible?

          Paul

[Ed. - I agree that these issues should be addressed by Kermit II --
there's not much chance of fixing all the Kermit I's out there.  And while
we're at it we could add some other things too: dynamically changing block
check types (each packet tagged with its block check type, to avoid all
the stupid negotion and confusion presently required to switch among them,
and to allow Kermits to adapt themselves on the fly to changing line
conditions), automatic detection of parity, allowance for negotiations
occuring at any time during a transaction, a mechanism to allow a file
transfer to be interrupted and continued (e.g. when a diskette fills up),
etc, etc.  But who has the time to write the specification, and who has
the time to write the many implementations?  Actually, it might not be so
bad if the new C-Kermit is used as a starting point...]

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

End of Info-Kermit Digest
*************************
-------
19-Feb-85 11:51:07-EST,8058;000000000001
Mail-From: SY.FDC created at 19-Feb-85 11:45:51
Date: Tue 19 Feb 85 11:45:51-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #7
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue, 19 Feb 1985       Volume 2 : Number  7

Departments:

  ANNOUNCEMENTS -
        New Release of CP/M-80 Kermit

  UNIX KERMIT -
        Os9 C-Kermit Informal Work/Dicussion List
        C-Kermit Filenames, Dialing
        Problems With C-Kermit Options

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

Date: 18 Feb 1985 23:39 PST
From: Charles Carvalho <CHARLES@ACC>
Subject: New Release of CP/M-80 Kermit
To: Info-Kermit@CU20B

Version 4.05 of CP/M-80 Kermit is ready for testing.  Basically, all I did
was merge the changes I've received, with minor modifications.  There will
still be further releases after this (see below).  Here are some quick notes
on what's in v4.05:

From Hal Hostetler:
    Remember the current port, and display it in the output from the
    STATUS command.
    Fix some screen positioning errors in the file transfer commands;
    clear the screen when file transfer is aborted with ^C.
    Support Lobo MAX-80 computer.

From Paul Milazzo, Rice University:
    Extend H89 support (add SET SPEED and ability to send BREAK).
    Use BDOS version number to determine proper algorithm for disk space
    calculation.  (CPM3 users no longer have to run the generic
    version)

From Joe Smith, Colorodo School of Mines:
    Support the Northstar Horizon with Northstar CP/M and SIO-4 board.

From Vanya J. Cooper,  Pima Community College:
    Fix the checks for valid characters in CP/M filenames.  The characters
    <>.,;:?*[]_%|()/\ are not permitted; lower case letters are
    converted to upper case.  If the flag "ffussy" in the linkage
    section is set (at compile time, or by patching), we are more
    liberal.  The other special characters are always permitted;
    this means you can erase those filenames with ampersands from
    within Kermit.
    Fix problems with reparsing "?" in filespecs; also check for legality
    of wildcards.
    Add a fairness count to the input loop in CONNECT mode, so that the
    keyboard doesn't get locked out when the printer is running the
    same speed as the modem line.
    Major improvements in logging: use the large buffer; allow logging
    to be suspended (<esc>Q) and resumed (<esc>R) during CONNECT mode;
    retain the logging status and filename across multiple CONNECT
    sessions, incidentally fixing the horrendous bug where a file
    could be overwritten if the FCB was reused between the LOG command
    and the CONNECT command; add the SET LOGGING ON/OFF commands to
    control logging (LOG <filespec> enables logging and specifies the
    name of the logfile; SET LOGGING ON uses the last specified logfile
    or KERMIT.LOG if none was given).  If the logfile already exists,
    it will be appended to, rather than overwritten.
    Add connect mode <esc>P command to toggle printer on and off.
    Add separate conditional for the Xerox 820; it's just different enough
    from the Kaypro to be a pain.

    The large buffer size has been dropped to 8K bytes (from 16K); this
should help the systems that counldn't transfer larger files because of
protocol timeouts while the buffer was being written to disk.  I haven't
implemented the commands to change the timeouts yet, which is the ideal
solution.  I received a fix for the DECmate to IBM problem (where the
DECmate swallows the turnaround character), but it's not in this version.

    I also have a CP4SYS for multitudes of Apple configurations, from
Jonathan Beeson and Francis Wilson of Columbia Teachers College, but it
has persuaded me that it is time to split up CP4SYS.ASM.  Not one version
per system, yet, just per family.  Most of the "inout"-type systems could
stay together, for instance; with another file for the "iobyt" systems.

    I haven't tested version 4.05 extensively, but I have verified that it
compiles for all machines.  (I've also tried assembling some configurations
with MAC80).

    The files are available via anonymous FTP from CU20B as KER:CP4*.*.
A list of the specific files is in KER:CP4AAA.HLP.  The previous version,
4.03, will still be available for a limited time as KO:CP4*.*.  Users of
Kermit on the various CP/M systems are encouraged to get the new version,
try it out, and report how or whether it works to CHARLES@ACC, cc to
Info-Kermit.

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

Date: Sat 16 Feb 85 00:54:02-PST
From: Bob Larson <BLARSON%ECLD@ECLA>
Subject: Os9 C-Kermit Informal Work/Dicussion List
To: info-kermit@CU20B

Due to the interest in os9 kermit recently generated by the new Unix
Kermit, I have created a redistribution list for people working on os9
kermit.  If you want to be added or deleted from this list, send me mail.
(There are currently six people on this list... pretty big for an obscure
os.)  To mail to the list, send it to me and I will remail it to the list
if it is of general interest.

Systems currently represented:  3 coco's, 2 non-coco 6809 (1 level 1,
1 level ?), and 1 os9/68000.  Locations range from Los Angeles to Germany.
Networks include arpanet, csnet, and usenet.

Bob Larson
Arpa: [e-mail]
Csnet(?): Blarson%Usc-Ecl.Arpa@Csnet-relay
Uucp(??): {ucbvax,seismo,harvard,uw-beaver}!blarson{@,%}Usc-Ecl.Arpa
Others: Your guess is probably better than mine

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

Date: Sat, 16 Feb 85 11:09:53 pst
From: Mark Seager <[e-mail]>
To: SY.FDC@CU20B
Subject: C-Kermit Filenames, Dialing

    I put the new version of C-Kermit up on our Vax 11/780 running
UNIX 4.2 bsd last week.  A few users have complained that kermit is
messing around with the file names and they would like the ability to turn
this "feature" off.  Could another option be added so that no filename
translation is done?

[Ed. - You can disable the filename conversion with "set file naming literal"
-- see the documentation.]

    Also, how does one establish a connection with another host
with kermit over a modem line?  I know how to get tip to dial another host
and so forth, but when you exit tip our system hanges up the line.

[Ed. - To do dialing, just give the "connect" command, then type the
appropriate dialing commands directly to your modem (e.g. "ATD765-4321"
for a Hayes-like modem), wait for a successful return code (for Hayes, a
"1") then you're connected.  No support is included for manipulating
dialers, since there are too many different kinds, and the program is big
enough (too big) already.  By the way, even Kermit may give you some
trouble with hanging up.  The next release (this week or next, I hope)
should work better -- no hanging up until the program terminates, or the
line is changed.]
            Thanks,
            Mark ([e-mail])

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

Date:     Fri, 15 Feb 85 23:30:25 CST
From: Paul Milazzo <[e-mail]>
Subject:  Problems With C-Kermit Options
To: [e-mail]

I really like the new C Kermit, but I have a small problem with it.  At
first glance, there doesn't seem to be any way to set block check type
on the command line, or binary mode in the interactive mode.  I finally
tried "kermit -i", and then set block check type to 3 in interactive
mode, and sent a file to my CP/M system.  Sadly, the resulting file was
somehow garbaged.

Am I missing something?

                Thanks,
                Paul G. Milazzo <[e-mail]>
                Dept. of Computer Science
                Rice University, Houston, TX

[Ed. - It's true, there's no block-check changing option on the command
line.  Easy to add, but the line has to be drawn somewhere.  In
interactive mode, use "set block-check 3" and "set file type binary".
It's in the documentation.]

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

End of Info-Kermit Digest
*************************
-------
 4-Mar-85 18:06:52-EST,18796;000000000001
Mail-From: SY.FDC created at  4-Mar-85 18:06:28
Date: Mon 4 Mar 85 18:06:28-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #8
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Mon,  4 Mar 1985       Volume 2 : Number  8

Departments:

  ANNOUNCEMENTS -
    Commodore-64 Kermit V1.3
    Kermit-11 for TSX+
    Getting PDP-11 Kermit by Phone
    Unix Shell Script for FTP'ing Kermit Files

  UNIX KERMIT -
        (Next prerelease C-Kermit coming this week, watch Info-Kermit)

  MS-DOS KERMIT -
    MS-DOS Kermit .BOO Files and Translation Table Troubles
    MS-DOS Kermit Key Redefinitions
    (Version 2.28 on the way, watch Info-Kermit)

  MISCELLANY -
    Kermit-32 3.0 vs VMS 4.0
    Turbo Pascal Kermit for MSDOS systems.
    Kermit vs Sytek LocalNet 20
    Kermit and TACs
    Crosstalk, Kermit, and India

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

Date: 20 Feb 85 17:10:37 EST
From: Eric <[e-mail]>
Subject: Commodore-64 Kermit V1.3
To: sy.fdc@CU20B

Version 1.3 is ready for release, along with documentation and a bootstrap
procedure for people who do not yet have Kermit. The bootstrap procedure
was written by Robert Scott Lenoil (Lenoil@Mit-XX) in CLU (available on
DEC-20s' and Vaxen running UNIX, I believe). I hope to have a Fortran
translation of the mainframe end shortly (it is really quite simple). This
version of Kermit includes the following updates and fixes:

    1) Full support for 1200 baud communications.

        a) Flow control, (XON/XOFF)
        b) Correct setting of baud rate, correcting errors
        in the standard RS232 Kernel routines.

    2) File-Warning has been implemented, a la Apple Kermit.

    3) VT52 emulation should work completely in 40 column mode.
    This includes printing of tabs!

    4) You can set the word-size for communication (7 or 8 bit)

    5) You need not exit and restart Kermit to bring into effect
    changes made in the communication parameters.

    6) Server commands definitely work the *first* time.

Enjoy!
Eric

[Ed. - The files are in KER:C64BOOT.* (the bootsrapping procedure),
KER:C64DXL.* (the hexification program), and KER:C64KER.*.  The program
itself is written in CROSS, a derivative of the PDP-11 cross assembler
which runs on the DECsystem-10 and DECSYSTEM-20 and generates code for
various kinds of micros.  The bootstrapping procedure consists of a short
CLU program on the mainframe end, and a short Basic program on the C-64
end.  Since most sites do not have the CLU language available, it is hoped
that a version in a more common language, like C, Fortran, or Pascal, will
appear soon (the CLU program is quite straightforward and should lend
itself easily to translation).  Meanwhile, executable versions of it are
available in KB:C64BOOT.EXE (for the DEC-20) and KB:C64BOOT.VAX (for the
VAX).  KB: is the Kermit-Binaries area.  Note that there is also another
Kermit program for the Commodore-64 written in FORTH, which is available
in KER:C644*.*; it has no accompanying bootstrap procedure.]

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

Date:     Tue, 26-FEB-1985 11:01 EST
From:     <BRIAN@UOFT02>
Subject:  Kermit-11 for TSX+
To:       dftcu@cuvmb

I am sending a hex file for TSX+ that works. The only restriction is that
it uses virtual overlays.
                                                brian nelson

[Ed. - The file is in KER:K11TSX.HEX.]

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

DATE: TUESDAY, 26 FEB 1985
FROM: BRIAN AT UOFT02
TO: SY.FDC AT CU20B
SUBJECT: Getting PDP-11 Kermit by Phone

I have been giving out info for people to log into my 11/70 to get current
Kermit-11's. I think I may as well publish this instead of always getting
calls about it.

Number: 419 537-4401

After carrier, hit cr until prompted with a *.  At this point type 12
followed by a carriage return.  Response is SERVICE 12 START.  Within a
couple of seconds login will come up. Account is 254/3, no password.
Instructions follow, this is a captive account running a DCL command file
on RSTS T9.0. If you get SERVICE 12 UNAVAILABLE, try later.

This procedure will change in June 1985 as the PDP 11/70 has been replaced
by an 11/44 and a 11/785.

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

Date: Thu, 21 Feb 85 12:03:40 est
From: randy@nlm-vax (Rand Huntzinger)
To: info-kermit-request@cu20b
Subject: Unix shell script for ftp'ing Kermit programs

I have a Unix shell script (Bourne shell, sh) which, when given the prefix
of a version of Kermit, or a list of prefixes, goes out and fetches those
versions of the files from CU20B.  Thus, the Unix command,

        getkermit ck cpm

will start FTP, connect to CU20B, properly fetch C-Kermit and CPM Kermit and
write the files in the current directory with Unix palatable file names.  It
properly changes modes from ASCII to TENEX when transferring binary files.

I've found this script very useful in keeping the relevant versions of Kermit
here up to date.  I'm sure you at Columbia will appreciate that it encourages
transferring only what you need.   [Actually, I think you could transfer the
entire distribution with the command "getkermit ''", but I haven't tried it]

The only problem with this script is that it depends upon a bug in the Unix
FTP program being fixed.  In the vanilla 4.2 BSD ftp program, a mget (multiple
get) command issued in tenex (binary) mode fails on the directory read.  We've
fixed that here, but it may not be fixed at all other sites.

The text of the script follows, you can do with it what you see fit.

[Ed. - It's in KT:UXFTP.SH.  KT: is the Kermit-Tools area.]

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

Date:         Thu, 21 Feb 85 14:14 EST
From:         Alan H. Holland <FEAHH@VPIVM1>
To:           Frank da Cruz <SY.FDC AT CU20B>
Subject:      BOO Files and Translation Table Troubles

In my last note to you, I mentioned that I was having a hard time using
MSPCTRAN.BAS to turn MSIBMPC.BOO into a executable EXE file.  In your
reply, you mentioned that the problem could be in a translate table
somewhere.  You will be happy to know that the trouble is at my end.

MSIBMPC.BOO gets from KERMSRV thru BITNET to my account on our VM/CMS
system intact.  It is when I download it to my IBM PC that it gets hurt.
At our particular VM/CMS site, there is a terrible confusion surrounding
the ASCII tilde, the ASCII carat, and the EBCDIC not characters.  During
the download, the characters that were originally tilde and carat all get
turned into tilde characters.  Not good, but not your problem.

I solved my problem by having KERMSRV send MSIBMPC.BOO to a VAX/VMS system
to which I have access, and then downloading the file from there.  That
also allowed me to discover how the VM/CMS system was damaging the file,
by comparing versions on the IBM PC and working backwards.

            --Alan Holland     FEAHH at VPIVM1 on BITNET

[Ed. - This sort of thing has proved a common problem on IBM mainframes.
To this day, there is no consistent, "standard", invertible ASCII/EBCDIC
translate table.  This raises the interesting question of how Kermit
packets, which themselves may contain any printable ASCII character, will
survive in such an environment (see discussions of "sacred characters" in
previous digest issues).  The Kermit User Guide and Protocol manual list
the recommended ASCII/EBCDIC translations.]

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

Date: 27 Feb 85 18:05:14 EST
From: Ken Burner <KB13@CMU-CC-TE>
To: Info-Kermit@CU20B
Subject: MS-DOS Kermit Key Redefinitions

(Using Version 2.26).  I have occasion to use both IBM and DEC systems
frequently.  I have a long list of key re-definitions for the IBM that are
not needed on the DEC.  Is there an easy way to "clear" all key bindings
to the default setting without exiting and re-running the program?

-Ken Burner

[Ed. - We'll look into putting a command into the next release to do this.
For now, the best thing is to have a key redefinition command file for
each system you want to connect to, or else keeping Kermit in a RAM disk
so that exiting and restarting isn't so painful.]

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

Date:     Thursday, 21 Feb 85 11:04:34 EST
From:     rmcqueen (Robert C McQueen) @ sitvxa
Subject:  Kermit-32 3.0 vs VMS 4.0
To:       Info-Kermit @ cu20b

The Kermit-32 processing of LOCAL commands and incoming REMOTE commands
does not work correctly under VMS 4.0.  This is because Digital has changed
how DCL and mailboxes interact.  This will be fixed in Kermit-32 3.1 which
we are now working on.

Kermit-32 3.1 will also fix the problem with the CONNECT command when the user
is on an RTA.  This is because RTAs don't work exactly like terminals in all
respects.

It is hoped that we will be able to get this out in the next couple of weeks.

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

Date:    Thu, 21 Feb 85 14:03 EST
From:    VIC@QUCDN
To:      sy.fdc@cu20b
Subject: Turbo Pascal Kermit for MSDOS systems.

I have written a Kermit in Turbo Pascal for IBM PC compatable computers.
It has most of the features of the current MsDos version.  Why reinvent
the wheel?  Why not build on the MsDos version?  Although the current
Kermit-MS has an overwhelming number of features, it is lacking in two
areas which can not be corrected by adding more code.  The two short
comings are ease of use and ease of modification.

A full feature Kermit written in turbo pascal can be completely compiled
within 2 mins. Compare that with the 15 to 20 minutes for assembling each
module of the KERMIT-MS.  In addition pascal code is much easier to read
than assembler.  I am amazed at the amount of effort and coding that has
gone into putting new features into KERMIT-MS. It must be hundreds of
man-hours of effort.

    In my version of kermit, I have attempted to minimize the number of
commands and options.  I have also minimize the number of keystrokes.  For
example all option can be specified with just one command line.  We can
also change options as we CONNECT. eg.'CONNECT 9600 Full Odd ' This will
connect modem at 9600 baud in full duplex mode and odd parity. It could be
abbreviated as 'C 96 F O'

    An attempt was made to seperate the code into three areas.  General
kermit code, MsDos dependent code, and hardware dependent code.  I expect
I will have a CP/M version within a month for an KayproII and an Apple2E.

[Ed. - This person has been put in touch with Jeff Duncan, who recently
submitted another Turbo Pascal Kermit, but for CP/M.  I hope the result
will be a common Turbo version for MS-DOS, CP/M, and maybe Apple DOS.]

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

Date: Sunday, 24 February 1985  08:06-MST
From: Jerry Lotto <talcott![e-mail]>
Subject: Kermit vs Sytek LocalNet 20
To: Info-Micro@BRL

KERMIT can work over a SYTEK net (LocalNet 20). Some problems though.  One
thing that I have found to be reliable is to set all packet sizes to 80
characters.  This is especially true of the new C-Kermit and VMS KERMIT.
For MS-DOS KERMIT, receive and send packet sizes are set individually. I
also tell the C-Kermit side that I want file type binary.  If I am sending
a 7-bit file the eighth bit does not get set anyway.  This setup has worked
transferring a file from a UNIX machine (in server mode) using telnet to
another UNIX machine (a VAX) through a SYTEK connection to a line driver
connected to a VMS vax running "vaxnet" who in turn passed everything to
an IBM-PC AT.  The transfer was a wildcard transfer of eight bit files
without quoting in both directions at 9600 baud (slowest connection, and
gave NO errors. Hats off to the KERMIT crew!)

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

Date: Wed, 27 Feb 85 14:09:34 EST
From: [e-mail]
To: [e-mail]
Message-ID: <[e-mail]>

 Our  mainframe  supports  VT52's,  but  expects them to have
 AUTOWRAP set on. That is, if the cursor is in column 80, and
 another  character arrives, the VT52 should move to the next
 line and put the character there. It turns out that MSKERMIT
 in  HEATH-19 emulation mode doesn't do this. Is there anyway
 to get MSKERMIT to do this, and if not, would it be possible
 to include this feature in a future version of MSKERMIT?

[Ed. - MS-Kermit 2.26 and later respond to escape sequences from the host
to control line wrap.  ESC v turns on line wrap, ESC w turns it off.
Maybe a future release of the program will include a command to control
this as well.]

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

Date: Mon, 25 Feb 85 15:49:04 EST
From: Edward Haines <[e-mail]>
Subject: Kermit and TACs
To: sy.fdc @ cu20b.arpa

Using Kermit with an InterNet Terminal Access Controller (TAC).

There are some conditions that must be met to successfully use Kermit on a
personal computer through a TAC.

Flow Control

The buffer size for a terminal port on a TAC is typically about 64 bytes.
(The size is a configuration parameter.)  Since the default packet size in
Kermit is about 96 bytes it is quite likely that buffer overflow will occur.

Some possible solutions:

1.  Enable flow control in Kermit on the PC and on the TAC.  Many PC
versions of Kermit implement XON/XOFF flow control.  In particular, the
new MS-DOS version does for the IBM PC.  To enable flow control on the TAC
issue the TAC commands

  @Flow Input Start
  @Flow Output Start

These are usually abbreviated @f i s and @f o s.  Note that flow control
is not compatible with binary mode (except see note below).

2.  Make the packet size on the PC Kermit small enough to not overflow the
TAC buffer, e.g.  60 bytes.  I had patched the old MS-DOS Kermit to do
this.  On the new MS-DOS Kermit, there is a command to set the packet
size.

3.  Increase the buffer size in the TAC.  This is not usually practical
and won't be considered further.


TAC Intercept Character.

The default TAC intercept character is the AT-sign.  The AT-sign is also
required by the Kermit Protocol.

Solutions

1.  Have the PC Kermit automatically double AT-signs on output.  This is
probably the best solution in general.  This feature is available on some
PC implementations of Kermit.  It is not yet available on the MS-DOS
version.  [Ed. - It's available in CP/M-80 Kermit 4.0x.]

2. Change the TAC Intercept character with the command

  @Intercept <decimal ASCII value>

I generally use @I 6 which sets the intercept character to Ctrl-F.

3.  Put the TAC into Binary mode.  This has the side effect of disabling
the Intercept character.  It also will allow you to transfer binary files
without special encoding.  The TAC can be put into Binary mode with the
commands

  @Binary Input Start
  @Binary Output Start

Some host systems allow you to engage the binary mode from the host.
[Ed. - DEC-20 Kermit has a command for this.]

There are several problems with binary mode:
   Some host systems don't support it.
   You lose the ability to control the TAC from the PC.
   You lose the ability to do XON/XOFF flow control.

Binary Files

It is sometimes desireable to be able to transmit an 8-bit binary file
between a host and a PC.  The TAC (which implements the DDN Telnet
Protocol) normally provides just a 7-bit ASCII path.

Solutions

1. Enable binary mode (if possible) as described above.

2. Enable 8th bit prefixing (if available) in both Kermits.  (This is
usually done by enabling parity.)

Notes

1.  You will probably get the best throughput for ASCII files by keeping
the packet size as large as possible and using flow control.

2.  There is not much advantage in increasing the baud rate between the PC
and the TAC beyond 1200 baud because of the realatively long turnaround
time for the acknowledgement packet.

3.  You may have problems when going through satellite hops or multiple
gateways due to the occasional very long delays.  This may result in
Kermit giving up.  I have also seen Kermit get into a sort of resonant
mode where it sends each packet twice but is otherwise succesful.
[Ed. - The resonating packets usually happen when one of the Kermit
programs is not capable of flushing its input buffer.  See the BYTE
article for an explanation of this phenomenon.  Long delays can be
circumvented to some extent by increasing the timeout interval; many
Kermits have commands to allow this.]

4.  Only the first letter of a TAC command is required.

5.  It is possible to set binary mode in only one direction.  For example
you can set Inbound binary and retain input flow control (XON/XOFF flow is
in the opposite direction).  You probably don't need outbound (input to
the PC) flow control when using the Kermit protocol.

Ted Haines

[Ed. - This file will be kept for reference in KER:DDNTAC.HLP.]

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

Date: Tue 26 Feb 85 06:30:27-PST
From: Richard H. Miller <[e-mail]>
Subject: Crosstalk, Kermit and India
To: [e-mail]

Some months ago I read a few messages concerning the use of KERMIT
with Crosstalk XVI.  Has anything come of this?  Can one use the scripting
features in Crosstalk with Kermit protocols?  If so, I'd be very grateful
for any help.

[Ed. - I have no knowledge of any progress.  We gave Microstuf our
standard permission to include Kermit with their product (see
KER:COMMER.DOC), but haven't heard anything since an announcement appeared
in PC Week a few months ago.]

Now a testimonial.  One of our clients is a consortium of international
agricultural research centers administered by the World Bank.  This group
of centers is foremost in the field, and represents the state of the
art in agricultural research.  As you might imagine, some of the centers
are located in countries without data network access.  One such center
is in Hyderabad, India.  During the past month, we have been using KERMIT
(version 2.27) on our IBM PCs and XTs to transfer files to and from
Hyderabad's VAX 780.  It would be understatement to say that the use of
international direct dial telephone between California and India
is noisy.  It's horrendous. However, by reducing the packet size and
twiddling a few other parameters, we have had very good success.

Thanks for a quality program.

Rich Miller
Telematics International
Palo Alto, CA

[Ed. - Thanks for the kind words; it's good to hear that Kermit may be
involved in actually doing something beneficial for humanity.]

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

End of Info-Kermit Digest
*************************
-------
 6-Mar-85 21:53:45-EST,3104;000000000001
Mail-From: SY.FDC created at  6-Mar-85 21:53:20
Date: Wed 6 Mar 85 21:53:20-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #9, C-Kermit Release #2
To: [e-mail], [e-mail],
    [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Wed,  6 Mar 1985       Volume 2 : Number  9

               Second Pre-Release of C-Kermit for Unix

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

Date: Wed 6 Mar 85 21:43:12-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Second Pre-Release of C-Kermit for Unix
To: Info-Kermit@CU20B

This is to announce the second "pre-release" of C-Kermit.  The first
pre-release (version 4.0) occurred a month ago; the program included
support only for Berkeley Unix.  This new release (4.2) includes support
for:

. 4.x Berkeley Unix (VAX, SUN)
. Generic AT&T System III, System V
. Microsoft Xenix for the PC/AT
. Interactive on the PC/XT (PC/IX) and other systems
. DEC Professional 3xx with Venix 1.0
. NCR Tower

All reported bugs have been fixed (or at least fixes have been
attempted), and many of the restrictions lifted.  "Dial" and "script"
commands have been added, along with code to support modem control and
dialers, uucp line locking, and the like.  The program itself has been
somewhat reorganized to be more adaptable to small environments: the
larger modules have been split; long character strings have been
shortened.

Most of the new work was done by Herm Fischer of Litton Data Systems, Van
Nuys CA (HFISCHER@USC-ISIB), and there were also contributions from many
others in the form of bug reports and/or fixes.  NCR Tower support came
from John Bray at Auburn University.  The new makefile (distributed as
CKERMI.MAK) embodies procedures for building all the different versions.

Since the program now runs on a variety computers, large and small, it
would seem relatively safe to begin adding support for other systems
without fear that the program will have to be completely reorganized
(again).  The only systems supported by C-Kermit so far are Unix systems;
rather than create a separate ckx and ckz module for each such system
(since these systems tend to differ in small places, but still have much
in common), conditional compilation was used within these modules.  If
C-Kermit is to be adapted to non-Unix systems, then a full replacement of
the ckx and/or ckz modules is probably indicated.  This is what we will
probably do in bringing the program up on the Macintosh.

The files are available via anonymous FTP from Internet host CU20B
(Internet number 192.5.43.128) as KER:CK*.*.  They will appear at
okstate (for uucp'ing) and on KERMSRV (BITnet) shortly.  If you plan to
adapt this program to a new system, be sure to let me know quickly so I
can prevent duplication of effort and can put people with similar
interests in touch with each other.

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

End of Info-Kermit Digest
*************************
-------
 7-Mar-85 18:47:41-EST,12788;000000000001
Mail-From: SY.FDC created at  7-Mar-85 18:46:59
Date: Thu 7 Mar 85 18:46:59-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #10
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu,  7 Mar 1985       Volume 2 : Number 10

Departments:

  ANNOUNCEMENTS -
    Old Files Moved

  UNIX KERMIT -
    C-Kermit Modules for Regulus
    Unix Shell Script for ftp'ing Kermit Programs, Cont'd
    Bug in C-Kermit
    C-Kermit 4.2 Problems

  MISCELLANY -
    TSX+ Kermit-11 Clarification
    MS-Kermit and TopView
    Series-1 Support in IBM Mainframe Kermit
    Resonating Packets, Satellite Delays to India

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

Date: 7 Mar 1985 1853-EST
From: Frank da Cruz <SY.FDC@CU20B>
To: Info-Kermit
Subject: Old Files Moved

Since the Kermit distribution area on CU20B has grown sufficiently large
that it will no longer fit on a single reel of tape in ANSI D format at
1600 bpi, several old versions of Kermit have been moved to KE:, the
Kermit-Extra area.  These are:

KER:PC*.*  -  Version 1.20 of IBM PC Kermit.  Replaced by KER:MS*.*.
KER:CPM*.* -  Version 3.9A of CP/M-80 Kermit.  Replaced by KER:CP4*.*.
KER:UX*.*  -  Version 3.0 of Unix Kermit.  Replaced by KER:UX*.*.

The old files are still accessible, but now they're in KE: instead of KER:.

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

Date: 1 Mar 1985 0953-EST
From: Joe Smiley, Du Pont Co.
Via: [e-mail]
To: Info-Kermit
Subject: C-Kermit Modules for Regulus

I have transferred two source files for C-Kermit ckzreg.c and ckxreg.c
for using C-Kermit under the Regulus (Version 4.2) operating system.
These were created from the Berkeley versions and have been tested
(although not extensively). The modifications were minimal.

[Ed. - These changes arrived too late to be included in C-Kermit 4.2, and
would have been hard to add in any case, given the reorganization that the
program has suffered in the meantime.  I hope Joe can add the Regulus
support to the new release and send these modules to us again.  Meanwhile,
if anybody needs them, they're available for anonymous FTP from
KE:CK%REG.* -- note, KE:, not KER:.]

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

Date: Tue, 5 Mar 85 14:58:27 est
From: randy@nlm-vax (Rand Huntzinger)
To: Info-Kermit
Subject: Unix Shell Script for ftp'ing Kermit Programs, Cont'd

The following patch, applied to the 4.2 BSD ftp program, will allow mget
to work in TENEX mode, as required by my shell script to retrieve Kermit
versions from Columbia.  It isn't a particularly elegant solution, but
it's functional.

[Ed. - The shell script (announced in V1 #8), along with the ftp patch
(which is too long to include here) are in KT:UXFTP.* on CU20B (The
Kermit-Tools area).]

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

Date: Wed, 6 Mar 85 19:13:15 cst
From: Rusty Haddock <[e-mail]>
To: [e-mail]
Subject: Bug in C-Kermit

Problem:
    With C-Kermit (on Ultrix/BSD4.2) in server mode talking to
MS-Kermit on a TI Professional a "REMOTE DIR" command from the TIPC
will be displayed without carriage returns - just line feeds.
All of the REMOTE commands act this way.

Cause:
    What appears to be the cause is that the C-Kermit command
"SET FILE TYPE BINARY" affects ALL output from the UNIX system.
whether it's file transfer or REMOTE command.  Unfortunately,
you must terminate the SERVER, do a "CONNECT", and then
"SET FILE TYPE TEXT" to have the server output the CRLF pair for
the REMOTE commands.

Fix:
    Sorry, I have none (yet) as I'm not that familiar with
the C-Kermit source code but it may very well be easy to fix.
I would think that all that would need to be done is to have the
BINARY TRANSFER flag (or some such indicator) unset when transmitting
REMOTE command output and restored upon completion.

Your time and consideration would be appreciated.  Thanks, Rusty

ARPA:   [e-mail]
    Rusty@Maryland
CSNet:  Haddock@TI-CSL
USENET: {ut-sally, convex!smu, texsun, rice} ! waltz ! haddock

[Ed. - Diagnosis correct.  This problem will be fixed in the next release.]

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

Date:  7-Mar-85 12:29:17-MST
From: [e-mail]
To: [e-mail]
Subject: C-Kermit 4.2 Problems

I have just compiled the new ckermit on my 11/70 running Sys V. There is
one problem in ckdebu.h. The typedef unsigned long LONG caused a compile
error "misplaced long". Changing this to 'typedef long LONG' resulted in
a clean compile. I have not completly tested, but a preliminary test seems
to work o.k.

While trying to compile it on my VAX running 4.1bsd I also encountered an
error. In ckxunx.c there is a line '#include <sys/time.h>' and references
to two structures 'timevalue and timezone' that are expected to be in this
include file. I do not have that include file although I do have a <time.h>
and a <sys/times.h> neither one has either of the two referenced structures.
I don't have time at the moment to work on tracing the problem further.

Keep up the good work. Kermit is the best "free" software I have seen in
many years.
                Gene Wester

[Ed. - Thanks!  I haven't heard complaints about the typedef from other
Sys III/V places.  But that's what the typedefs in ckdebu.h are for --
change 'em to fit what your compiler can do.

This is the first I've heard about the time stuff on 4.1; sys/time.h is
used for a couple things -- getting the current date/time string (e.g. for
time stamps in the various logs) and for operation of the millisecond
timer in the function msleep.  If anyone can supply these functions for
4.1, please send them in!  Especially if there's a way to do it that works
in both 4.1 and 4.2.]

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

DATE: THURSDAY, 07 MAR 1985
FROM: BRIAN AT UOFT02
TO: SY.FDC AT CU20B
SUBJECT: TSX+ Kermit-11 Clarification

To clarify a point, there is NO such thing as K11TSX.HEX or K11TSX.SAV.
TSX+ users need to use K11XM or K11RT4, the first uses virtual overlays
the later does not. The RT version of Kermit-11 ALWAYS determines at run
time if it is on RT11, PRO/RT11 or TSX+ and loads the appropiate overlay
for terminal i/o correspondingly.
                                   brian nelson
                                   [e-mail]

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

Date: Thu Feb 28 1985 21:19:09
From: Marco Papa <[e-mail]>
To: info-kermit@CU20B
Subject: MS-Kermit and TopView

What are the recommended values of the parameters for MS-Kermit's PIF
(Program Information File) to work under TopView?

Marco
USC Computer Science Dept.

UUCP:  ...!sdcrdcf!uscvax!papa
CSNET: [e-mail]
ARPA:  [e-mail]

[Ed. - We fooled with it a little bit, but then lost our TopView disk.
Here's the best we can remember:

  Program size 100K
  Does map screen
  Can't run in background
  Doesn't use 8087
  Usurps all interrupts

It's really a little smaller than 100K, and it really doesn't usurp ALL
the interrupts.  It would be nice if it could run in the background while
transferring files, but since it fields interrupts from the port, you
can't do it.  And it can't run inside a window during connect mode because
it writes directly to screen memory (at least if you have H19 terminal
emulation "on").  If anybody wants to try this out and send back exact
instructions on how to install Kermit-MS under TopView, we'll include them
with the distribution.]

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

Date: Thu, 07 Mar 85 09:32:37 PST
From: KARL@USCVM        (Karl P. Geiger)
To:   (many people)
Subject: Series-1 Support in IBM Mainframe Kermit

[Ed. - This messages summarizes answers to a query broadcast over much of
BITnet.]

Greetings GentleBeings:

Thank you all for your answers to my letter.  I received many "I can
help" and "Please help me!" replies.

Briefly, UMDB people sent me a KERMIT module, VIC@QUCDN claims to have
a running KERMIT written in Pascal, SPGGTS@UCBCMSA has a running version
he is willing to send along, and NJG@CORNELLA has sent me some code
plus mods to CMS in UPDATE format.  Finally, Daphne Tzoar at Columbia
(DFT@CUVMA) sends word that she is incorporating all the interesting
mods for S/1 or 7171 support into Kermit and intends to release the
new version in three to four weeks.

Yale people have asked "Why aren't you using YTERM?  We wrote it to
support just what you want."   My answer, and reason for annoying
so many people on the net, is Yes, we are running YTERM in our IBM
PCs, but we have DEC-20s, VAX/VMSs, Unixes (Unices?), and PR1ME
Rabbits all which must talk to DEC Rainbows, PRO 350's, and CP/M
machines.  I use YTERM in my PC and PCTRANS to up/down load files
to VM frequently, but I would like a more general tool to gain
access to other systems.  Kermit has become the standard by consensus.

Personally, I intend to wait for Daphne to complete her work and
release the new Kermit.  I thank everyone else for their assistance,
contributions, and hard work to get Kermit running at their sites.
It makes more sense to me to use the 'standard' code which springs
from the fountainhead, however.

I will distribute the code I have received from UMDB and CORNELLA
to those who want it.

Thank you all again...

:Karl

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

Date: 6 Mar 1985 1820-EST
From: Joe Smith ([e-mail])
To: Frank da Cruz
Via: LCG.KERMIT@DEC-MARLBORO
Subject: Resonating Packets, Satellite Delays to India

I too have noticed this problem, where KERMIT sends each packed twice.  I
have seen it between KERMITs that do clear the input buffer.  It is not a
deficiency in a particular implementation of KERMIT, but instead is a
problem in the KERMIT protocol.

The current operation, that of resending the entire packet when there is a
timeout in getting an ACK, works only if the original packet got lost.  It
fails when the packet gets to the other end intact and was merely delayed
in transit.

What I have observed is the following:

  KERMIT-20 sends packet of data (call this 1A)
  KERMIT-PC sends an ACK, but it is delayed in the network
  KERMIT-20 times out, and sends a duplicate of the original (packet 1B)
  KERMIT-20 sees the delayed ACK 1A, sends packet 2A
  KERMIT-PC gets duplicate packet 1B, sends ACK 1B

At this point, the delay in the network is not present.  Therefore KERMIT-20
gets ACK 1B immediately after sending packet 2A.  Since this is not what it
was expecting, KERMIT-20 resends the data as packet 2B.  KERMIT-PC may be
confused as to why KERMIT-20 keeps sending every data packet twice, but it
stores the right data on disk and ACKs both packets.  For every other packet
that KERMIT-20 sends, it gets an ACK for packet "N-1" when expecting the
ACK for packet "N", and sends a duplicate packet "N".

The KERMIT protocol needs to be revised.  Whenever an ACK for packet "N-1"
is received, it should be thrown away, the SEND TIMEOUT value be increased
if possible, and KERMIT should resume waiting for ACK "N".

This would allow the two KERMITs to get back in sync.

I would like to make a suggestion for the KERMIT II protocol.  Only send
duplicate packets when an explicit NAK has been received.  Send a different
type of packet for timeout or user hitting the RETURN key.  This packet must
be distinct from all other packets, and come in at least 5 flavors.

  1)  HELLO, ARE YOU RECEIVING, THE LAST DATA PACKET I SENT WAS #123
  2)  YES, I AM RECEIVING, THE LAST DATA PACKET I GOT WAS #122
  3)  HELLO, ARE YOU STILL SENDING, THE LAST DATA PACKET I GOT WAS #456
  4)  YES, I AM SENDING, THE LAST DATA PACKET I SENT WAS #457
  5)  HI, I AM AS SERVER WAITING FOR YOUR COMMAND

With this mechanism, KERMIT would not have to blindly clear the input buffer.

[Ed. - Your diagnosis is correct.  But rather than wait for Kermit II, it
would be sufficient to employ the heuristic "discard redundant ACKs" which
you suggest, and which was also suggested in the BYTE article.  This is
not really a protocol issue; it's more like an implementation decision,
and can be added to any Kermit program.  The worst that can happen is that
the second ACK will not arrive within the timeout interval (which you are
free to adjust on a per-packet basis), causing retransmission of the last
data packet, which is what happens now.  Maybe this trick will show up
in the next release of C-Kermit.]

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

End of Info-Kermit Digest
*************************
-------
 8-Mar-85 17:00:29-EST,15582;000000000000
Mail-From: SY.FDC created at  8-Mar-85 16:59:24
Date: Fri 8 Mar 85 16:59:23-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #11
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri,  8 Mar 1985       Volume 2 : Number 11

Departments:

  UNIX KERMIT -
    C-Kermit 4.2 ready for UUCPing from okstate
    Oklahoma State UUCP Information
    C-Kermit vs Line Locking (2 messages)
    C-Kermit Remote Host Commands vs Binary Mode (2 messages)

  MISCELLANY -
    Resonating Kermit Packets

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

Date: 7 Mar 85 23:40:01-CST (Thu)
From: Mark Vasoll <[e-mail]>
To: Info-Kermit
Subject: C-Kermit 4.2 ready for UUCPing from okstate

    Well, pre-release version 4.2 of C-Kermit has arrived safely from
Columbia and is ready for UUCP downloading.  We are planning to post this
version to Usenet's "net.sources" newsgroup tomorrow (3/8/85).  We hope
to prevent another outbreak of postings by providing this *one* posting
while C-Kermit V4.2 is hot off the presses.  We will take all possible
precautions to prevent some overzealous mailers (or News handlers) from getting
hungry.

    Please direct all questions and problem reports regarding this
message, the C-Kermit 4.2 posting, and the UUCP Kermit Distribution
service to the following address.  Your message will be routed to the
person maintaining the distribution at that time.  Mail sent to my
personal login will be answered, but could be delayed several days.

    Our UUCP line will now be available on a 24 hour basis.
Unfortunately, we still can offer only one line....  Of course we would
welcome donations of equipment.... :-)

UUCP Kermit Distribution Assistance:

UUCP:  {cbosgd, ea, ihnp4, isucs1, mcvax, pesnta, uokvax}!okstate!uucp-support
ARPA:  [e-mail]

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

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

Date: 8 Mar 85 10:00:00-EST
From: Frank da Cruz <SY.FDC@CU20B>
To: Info-Kermit
Subject: Oklahoma State UUCP Information

Here again is the information about UUCP access to the Kermit distribution
from Oklahoma State U:

UUCP access to the complete Kermit distribution is available from the
Department of Computing and Information Services, Oklahoma State University,
Stillwater, Oklahoma.

You need to set up "okstate" as a site in your "L.sys" UUCP dialing file
using the information listed below.  You can then issue the following
command on your system:

    uucp okstate\!/u/kermit/ck\* /usr/spool/uucppublic

   (this example will retrieve the Unix version of Kermit)

I chose "/usr/spool/uucppublic" as the destination on your system since
the destination must be WIDE OPEN (drwxrwxrwx) to everyone.  You should
not remove files from your uucppublic until the entire transfer is complete
including any redials that are necessary.  If you do remove some files
our system may retransmit them, resulting in a higher phone bill for
you.

There are 2 files available that contain information about the entire
distribution.  We recommend that you retrieve these files first.  They
are "00readme.txt" which explains the file name conventions used, and
"00directory" which is a complete listing (by name) of all files in the
distribution.  These files will enable you to choose the right files
the first time to save those high dollar phone bills.

-- UUCP Login information --

Site Name    :  okstate
Phone number :  [phone]  (one line only)
Login name   :  uucpker
Password     :  thefrog
Hours        :  24 hours per day, 7 days a week
Problem      :  okstate!uucp-support  (UUCP)
  reports    :  uucp-support%okstate@csnet-relay  (ARPA)

The phone number is for 300/1200 baud (bell compatible).

The following is a sample L.sys line (\r is a carriage return).
You might want to put a time restriction on Any. ("Any2100-900" in
Illinois)

okstate Any ACU 1200 405-624-6953 "" \r ogin: uucpker word: thefrog

Just a few notes on how to best retrieve parts of the Kermit distribution
using UUCP...

  -  Install the proper L.sys entry and test it using the debugging option
     of UUCICO (-x).  Repeat this step until you successfully complete a
     "no work" connection, this will verify that your L.sys entry is correct
     and will minimize frazzled nerves.

  -  Retrieve the files `00readme.txt' and `00directory' with the following
     commands:

          uucp -c -d okstate!/u/kermit/00readme.txt /usr/spool/uucppublic
          uucp -c -d okstate!/u/kermit/00directory /usr/spool/uucppublic

     You will have to escape the exclamation point if you are using the
     C shell (i.e. ...okstate\!/u/kermit...).

  -  Choose the versions of Kermit that you wish to transfer and issue the
     proper UUCP command.  Some systems don't seem to like wildcards, but
     in any case the wildcards will have to be escaped from your shell. The
     following command would retrieve the files relating to C-Kermit:

          uucp -c -d okstate!/u/kermit/ck\* /usr/spool/uucppublic

     PLEASE NOTE THE USE OF /usr/spool/uucppublic!  Unless you *really*
     understand how UUCP's protections work you should not change this!  A
     number of people have queued >100 files and had their systems refuse
     to store them in out of the way places.  This results in wasted phone
     time!

  -  If you are having problems connecting to our system PLEASE send mail
     to {cbosgd, ea, ihnp4, isucs1, mcvax, uokvax}!okstate!uucp-support

  -  Kind words also make my day!

Thanks,

Mark Vasoll
Department of Computing and Information Sciences
Oklahoma State University

UUCP:  {cbosgd, ea, ihnp4, isucs1, mcvax, uokvax}!okstate!vasoll
ARPA:  [e-mail]

[Ed. - This file is online at CU20B as KER:OKSTATE.TXT.]

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

Date: Fri, 8 Mar 85 01:23:45 est
From: Ken Yap  <[e-mail]>
To: [e-mail]
Subject: C-Kermit vs Line Locking

I like the new C Kermit but I wonder if a couple things could be made
options instead of hardwired.

The scenario: we use "tip" to do our dialing out, we are not even
allowed to know the phone numbers. After reaching the other system and
starting up a remore Kermit there, we suspend "tip" with ~^Z, then
start up a local Kermit.

Unfortunately the new Kermit gets in the way by: (1) checking for the
absence of a lock file in /usr/spool/uucp and (2) requiring a "set
speed" after the "set line" command.

Could a new settable option called say, "pre-connected", be added to
circumvent these checks? I believe others might be in the same
situation.

Thanks for a good piece of software.

    Ken

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

Date: Fri 8 Mar 85 07:51:07-PST
From: Herm Fischer <[e-mail]>
Subject: Re: C-Kermit vs Line Locking
To: SY.FDC@CU20B

I like the idea of having a "preconnected" test.  But that probably
is a site-level thing, rather than a end-user level thing.

I'd not like end-users able to set preconnected and then access lines in
an unlocked fashion.

So, I'd recommend some -D flag when compiling kermit for that, say
an augmentation to make which adds a "-DPRECONNECT" flag when it
is compiled.

Of course, this is hip-shooting, and may need some tweaking to work...

  Herm

[Ed. - Before putting this line-locking code into C-Kermit, the Unix
experts (including Herm) involved had a lengthy discussion of whether and
how it should be done.  There are many issues, and many strong opinions;
the readership of Info-Kermit was mercifully spared.  The resulting code
is a compromise, which, as Ken points out, doesn't work at sites that do
not allow users direct access to the line or modem.  Since this
arrangement is likely to be site-wide, then Herm's suggestion is probably
the best way out.  Note that the goal of this line-locking feature is to
prevent two (or more) processes (like uucp, tip, or kermit) from using the
same line at the same time, for reasons of security and data integrity.
At the same time, it is important that the line-locking feature not deny
access to a line which is actually free.  There is a fine line separating
these two requirements, and strong opinions about which side to favor in
ambiguous situations.]

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

Date: Fri 8 Mar 85 13:28:31-EST
From: Jeff Damens <[e-mail]>
Subject: C-Kermit Remote Host Commands vs Binary Mode
To: [e-mail]

In the last Kermit Digest, there was a suggestion that commands like
REMOTE HOST always do newline conversion instead of obeying the image
(set file type binary) flag.  This will make it impossible to use
kermit as a filter for binary files - for instance, one might wish to
pipe kermit output to a plot filter and issue the command "remote host
graph | spline | ..." to generate a graph on a mainframe and plot it
locally.

A more general solution to the problem would be to allow the remote
kermit to receive commands from the local kermit.  Then the user could
say something like "remote command set file type text" to change the
image setting without connecting back to the remote system and
restarting kermit.

[Ed. - This is the "remote kermit" command, which has been in the protocol
manual for a long time, but never implemented.  Maybe next release...
Meanwhile, the problem reported by Rusty Haddock in the last digest will
not be solved as easily as I thought.]

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

Date:     Fri, 8 Mar 85 14:22:25 GMT
From:     [e-mail]
To:       [e-mail]
Subject:  Resonating Kermit Packets

     A few further points on pervasive packet duplication (or, for that
matter, triplication etc.), following on Joe Smith's analysis in
info-digest 10.

     This sort of problem (caused by network congestion, satellite delays
etc.) is quite well understood by mainframe networking buffs.  There are
other ways it can get going as well as the route set out by JMS.  Once
started, with a Kermit-type protocol (which always retransmits on
timeout), it is stable and will continue until there is a network error
(which fixes it, since the lost packet will be replaced by its duplicate).

     The most authentic way to avoid it (without changing the
packet-sequences) is to ensure that the sender, acknowledger and network
have timeout/delay periods related so that:

           (2 * Tnet) < Tsend < (Tack - 2 * Tnet)

for all expected values of Tnet.  Unfortunately this is going to result in
rather long delays when a send packet is lost unless Tnet is quite small
(which it isn't).

     What happens on the network concatenation I use regularly (one X25
and one LAN with a low-performance gateway) is that there is a
transmission delay in both directions, both ends time out, and there are
then two complete sets of packets circulating.  It so happens that I am
dialling in to the X25 @ 300baud, so reception is quite slow.  The modem
lights show that reception is actually continuous, the duplicate ack being
received while the next data packet is going out (the micro has
interrupt-driven read).

     A simple and effective recovery mechanism is to flush the input
buffer at the end of the block-transmit as well as at its beginning.  This
will destroy the head of the duplicate block, which is all that is needed.
With variable network delay, it doesn't always work at once, but will in
due course.  There is a risk that this algorithm will destroy a needed
block if the other end turns around very fast, so perhaps it's better as
an option than always on.  This way the timeouts do not need to be long,
so recovery from lost data still takes place quite quickly.  Note,
incidentally, that if the micro was doing a half-duplex transmit, it would
not see the incoming duplicate block; perhaps file transfer for micros
should always be arranged to be in a pseudo-half-duplex mode!

     What seems essential to me is that the micro-Kermit keep its user
informed of the arrival of duplicate blocks.  Then at least he/she can
either take evasive action or curse and start rewriting Kermit.

                                Chris Kennington.

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

Date: 8 Mar 85 12:37:00-EST
From: Frank da Cruz <SY.FDC@CU20B>
To: Info-Kermit
Subject: Re: Resonating Kermit Packets

Timeouts are a complicated issue.  You want the timeout interval short
enough to catch missing packets without inducing undue delays, but long
enough to avoid spurious timeouts.  In order to set the optimum timeout,
you must know the speed of the communication line (the baud rate), the
length of the packet being timed, the current network delay, the packet
processing time (assembly/disassembly, data fetch/store), the load on the
host, and maybe other factors as well.  The problem is that not all of
these quantities are knowable at a given time, and on some systems not at
all -- for instance some systems provide no function to tell you the baud
rate of a line.  Network delays can appear and disappear suddenly, so a
timeout adjusted on this basis will tend to be wrong at the endpoints of
such events.  A host which can monitor its load can adjust its own timeout
accordingly (as DEC-20 Kermit does), but the Kermit on the other end has
no way of knowing about this.  A micro may have a small constant packet
processing time for n K worth of packets, but when the next packet comes,
it must take time out to dump its buffer to disk (CP/M-80 Kermit).  Etc.

The packet input buffer can be cleared at various times:

1. At the beginning of a transaction:  Important for clearing out stacked
   up NAKs from an idle server.

2. Before reading a packet:  Obviously a poor idea.

3. After reading a packet:  Can't hurt.  It will tend to work beneficially
   when the network delay or the remote system load is decreasing, and have
   no effect at other times.  Most Kermit programs do this, and it is
   often sufficient for getting resonating Kermits back in sync.

4. Before sending a packet:  Equivalent to the previous case, except that
   additional time has passed in processing the packet just received, so
   the likelihood of finding something in the buffer (like the beginning of
   an unwanted packet) is increased.

5. After sending a packet:  The likelihood of finding characters in the
   buffer is still higher, but so is the likelihood that they will be
   characters from the packet you're looking for.

The length of the switching delay between writing and reading is crucial.
If the delay is negligible, it won't hurt to clear the input buffer after
sending, providing the clear function can be executed quickly.  If the
delay is long, or unpredictable, then case 5 would be equivalent to case
2, and you'd never be able to read a packet.

C-Kermit is an excellent vehicle for experimentation with these
heuristics -- it's written in a high level language and runs on a variety
of systems from small PC's to large timesharing systems, and the next
release will most likely embody the results of our combined experience
(experiments and results welcome!).

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

End of Info-Kermit Digest
*************************
-------
12-Mar-85 19:32:17-EST,12945;000000000000
Mail-From: SY.FDC created at 12-Mar-85 19:31:56
Date: Tue 12 Mar 85 19:31:56-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #12
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue, 12 Mar 1985       Volume 2 : Number 12

Departments:

  ANNOUNCEMENTS -
    Info-Kermit Mail
    Corrected Apollo (Pascal) Kermit

  UNIX KERMIT -
    C-Kermit and RTU 2.2
    C-Kermit for Unix Version 7
    C-Kermit vs 8-bit Files vs Parity
    HP 9000 Series 500 Kermit, suggestions...
    New C-Kermit for VMS

  MISCELLANY -
    Resonating Packets, Cont'd
    Wanted: Disk-Full Handling for Floppy Based Kermits

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

Date: Tue 12 Mar 85 18:48:24-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Info-Kermit Mail
To: Info-Kermit@CU20B

Apologies to those who received several issues of the Info-Kermit Digest
twice.  The duplication was not caused by mail delivery problems; these issues
were directed at Info-Micro and Info-Unix as well as Info-Kermit because they
contained announcements relevant to the new Unix Kermit, which has been the
subject of some discussion on those two lists in recent weeks.

BITnet members of Info-Kermit are now addressed through the Wisconsin gateway,
WISCVM, rather than the Berkeley gateway, UCB-VAX, which is being phased out.
If you're a BITnet subscriber and did not receive this message, let me know!

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

Date: Sun 10 Mar 85 20:04:45-EST
From: PHY1.J-GROVES@CU20B
Subject: Corrected Apollo (pascal) KERMIT
To: [e-mail]

The corrected version of the apollo (pascal version) kermit, as per our
conversation of the past week, is ready.  I have been using it for about a
week now and it seems to work properly, within its original bounds.  I
expect to add a number of useful features to the present code, such as
terminal emulation (the Cyber terminal that is presently emulated is not
useful to me) and remote capabilities. I will forward these additions to
you as soon as they are complete.

                    Phil Kravitz

[Ed. - The original copy of Apollo Kermit (Pascal version) a number of
lines truncated in the source file.  Phil has figured out what the missing
characters must have been and restored them.  The updated copy is in
KER:APOLLO.PAS on CU20B, available via anonymous FTP.]

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

From: Stan Barber <neuro1![e-mail]>
Date: Sat, 9 Mar 85 14:50:03 cst
Subject: C-Kermit and RTU 2.2
To: sy.fdc@cu20b

The generic SYSIII/SYSV version of kermit 4.2 seems to compile up just
fine on RTU 2.2. I will examine the code more closely to see if there are
refinements that might take better advantage of the system.

Line locking seems to be the only problem when the /usr/spool/uucp file
is writable by UUCP and root only.

Stan

[Ed. - I've received a lot of complaints about the uucp line locking.
Before release of this version, all Unix experts agreed that
/usr/spool/uucp would be publicly writable on all Unix systems.  It turns
out not to be true.  In fact, on some systems it may not even be readable!
This whole business is a can of worms.  Why Unix did not, from the
beginning, in all its forms, allow a tty device to be opened with
exclusive access is beyond me...  The next release of C-Kermit will come
with some kinds of options as to how to handle line locking.]

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

Date:     9 Mar 85 16:43:30-CST (Sat)
From:     Gregg Wonderly <[e-mail]>
To:       [e-mail]
Subject:  C-Kermit for Unix Version 7

Frank,

   I have the Version 7 mods made to the new C-KERMIT (Release #2).  The only
necessary mods seem to be in the ck[xz]unx.c files.  I still would like to do
more testing, to make sure it really works properly.

Gregg Wonderly
Department of Computing and Information Sciences
Oklahoma State University

[Ed. - This will be incorporated into the next release.]

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

Date: Sat, 9 Mar 85 17:38:07 est
From: hipl!tony@nyu-cmcl2 (Tony Movshon)
To: [e-mail]
Subject: C-Kermit vs 8-bit Files vs Parity

If the 4.2bsd C-Kermit file-type is set to binary, parity is set to
anything other than none, and the remote kermit (in this case, the old
Unix Kermit 3.0) does not accept 8th-bit prefixing, C-Kermit goes ahead
and sends the file anyway, despite the fact that it must know that it's
stripping and throwing away all the high bits. Surely it should report an
error?

[Ed. - The behavior is correct, but you're right, C-Kermit should report
an error in order to give the user the chance to interrupt or cancel the
file transfer if this effect is not desired.  The next release will issue
a message when this happens.]

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

Date: 10 March 1985 22:57-EST
From: Yekta Gursel <YEKTA @ MIT-MC>
Subject: HP 9000 Series 500 Kermit, suggestions...
To: sy.fdc @ CU20B

I managed to get the new C-Kermit running on the HP 9000 Series 500
computers.  This is a completely different machine than HP 9000 Series
200.  The version of Unix we have is HP-UX 3.25 bqa.  We will soon get the
HP-UX version 4.  I'll make it run on that as well.  I do not mind
supplying kermit support for HP 9000 Series 500 machines.

I'll outline the changes that have to be made:  I used the "make sys3"
option with the following changes.

1) Remove the "-i" option from the CFLAGS and LNKFLAGS in the makefile.

2) In the line "wart ckprot.w ckprot.c; cc ... " replace "wart" with
"./wart" in the makefile. The reason for this is that if "." is not
in the current PATH, make will fail unable to find "wart".  We have
an open system, and "root" does not have "." in its path in order to
prevent "trojan horses".  People sometimes do funny things in an open
system.  Sigh.

3) In the file "ckxunx.c", on line 125: Comment out, or conditionalize out
the line "#include <sys/file.h>".  This file does not exist in HP-UX, the
definitions are in the kernel.  Similarly, in the same file on line 138:
Comment out, or conditionalize out the line "#include <sys/ioctl.h> for
the same reason.

4) In the file "ckzunx.c", on line 93: Comment out, or conditionalize out
the line "#include <sys/file.h>", for the same reasons stated above.

After these changes, C-Kermit will compile and run just fine.

Finally, a suggestion:  How about making the string "C-Kermit" which
appears in all error messages, disconnect messages, default prompt, etc..
user specifiable at compile time, with "-D" flag for example, so that
one can "customize" C-Kermit for a given machine by replacing it with
something that identifies the machine?  This will make life easier if
one is going through a whole bunch of kermits. Even with two of them,
it is sometimes confusing if both of the machines are running C-Kermit.

Best, Yekta  ( YEKTA@MIT-MC )

[Ed. - Good idea; perhaps the string could also be tied to "set prompt"
at runtime.  I expect your HP-9000 changes will be incorporated into the
next release.]

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

From: [e-mail]
Date: 10 Mar 85 22:52 EST
To: harvard![e-mail]
Subject: New C-Kermit for VMS

OK, everything appears to be working.  I would say it is ready for
an alpha test release.  Following is a complete list of the changes
I had to make:

CKCMD.H
    Added a #define for CR.

CKCMD.C
    Changed all putchar's to conoc's.  We want unbuffered output here,
    and that means conoc, no?  Likewise getchar -> coninc.
    conoc(CR) added under #ifdef vax11c at the end of the input line.

[Ed. - This will not necessarily be in the released version; it might
break the take command, and also interactive operation on certain versions
of Unix.]

CKCONU.C
    Wrote a version of conect() that doesn't use fork().  What it does
    instead is call a system specific function, contti(c, src), which
    returns when a character is available from either console or comm.
    line.  Also, a function, cancio(), is called at the end of the
    NO_FORK version of conect().

CKDEBU.H
    Added the parameters GOOD_EXIT and BAD_EXIT.  On VMS, exit(1) is the
    success exit, not exit(0).

CKDIAL.C
    Used a timed ttinc() rather than alarm().  On VMS, an alarm will not
    break through a pending read, so this method of timing out will not
    work.

CKFNS2.C
    Used GOOD_EXIT rather than 0 in a couple of exit()'s.

CKLOGI.C
    Used a timed ttinc() rather than alarm().  See CKDIAL.C.

CKMAIN.C
    Used GOOD_EXIT rather than 0 in a couple of exit()'s.

CKUSER.C
    Added a #define KERMRC ".kermrc" or "kermit.ini" under an
    #ifdef vax11c.  Also changed some exit()'s.

CKUSR2.C
    Added 19200 baud to the help string under #ifdef vax11c

CKUSR3.C
    Added 19200 baud under #ifdef vax11c

CKXVMS.C
    New file.  Originally, I had this combined with CKXUNX.C.  The result
    was 40K.  The original CKXUNX.C was 30K and CKXVMS.C is    under 19.5K.
    What do you think?

CKZVMS.C
    New file.  Figures are 27K (est.), 22.5K and 14.5K.

Stew

[Ed. - C-Kermit for VMS will be incorporated into a future release,
depending upon when it arrives.]

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

Date: Mon, 11 Mar 85 17:50:26 pst
From: Ken Poulton <@csnet-relay.arpa,@hplabs.CSNET:[e-mail]>
To: cc.fdc@columbia-20
Subject: Resonating Packets, Cont'd

I ran into a problem with buffer flushing which was intended to avoid this
resonating packet problem.  Kermit-32 already does a flush-after-read
operation.  However, when talking to the HP 3000, we found that it was
flushing out the XON handshake character from the 3000, causing the
transfer to go very slowly.  (It was never discovered when talking to IBM
systems because they apparently always had sufficient delay on the IBM
side to let the VAX flush before the XON came.  The 3000 can send the XON
soon after sending out a packet.)

Flushing is, of course, not needed when talking to half-duplex machines
like IBMs or HP 3000s, so the temporary fix was simple: I now have a
hacked version of Kermit-32 which simply omits the flush.

The moral of the story: if you add flushing on every packet (in addition
to the normal flush-at-start-of-transaction) PLEASE PLEASE PLEASE turn it
off when in HANDSHAKE XON or IBM_MODE.

And while I'm at it, here's another request to Kermit implementors: please
separate HANDSHAKE XON from the PARITY and ECHO options commonly lumped
into IBM_MODE.  The HP 3000 needs HANDSHAKE XON, but not the others!

Ken Poulton

[Ed. - Buffer flushing and line turnaround handshake can coexist, using
the trick found in the new C-Kermit -- If handshaking is being done, then
just redefine the packet terminator to be the handshake character.  Then,
once the packet is read, you can go ahead and clear the buffer.

"IBM-MODE" is a hack appearing in the early Kermits -- the ones that
didn't have command macros or take files or lots of different SET commands
-- to allow them to talk to IBM mainframes.  It's shorthand for "set
parity mark", "set duplex half", "set flow-control off", "set-handshake
xon", "set timer on".  It's site-dependent in that not all IBM mainframes
use mark parity, but otherwise it tends to do the trick.  More advanced
Kermits have separate SET commands for all these parameters, and also may
have TAKE commands and/or command macros to let you modify them
appropriately or set up new macros, like "SET HP3000".  Getting these
features into older Kermits is just a question of somebody doing the work.]

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

Date: 10 Mar 1985 0415-EST
From: LSM.SMITH at DEC-MARLBORO
To: SY.FDC at CU20B
Subject: Wanted: Disk-Full Handling for Floppy Based Kermits

I would like to see a new feature in KERMIT which would allow the receiving
KERMIT to tell the sending KERMIT to pause indefinitely.  If properly
implemented, this would allow the receiver to tell the sender to pause, exit
to the Operating System, format a new floppy, run KERMIT again, and allow the
sender to resume.  (This last step would probably require the user to supply
the name of the file to store the incoming data.) This way very large text
files could be stored.

[Ed. - I'd like to see it, too.  This is a tough issue because it requires
new protocol to be defined and implemented.  A workaround using present
apparatus is to "set incomplete keep" on receiving kermits that have that
feature.  When a disk fills up, go back to the sender, copy the unsent
portion of the file into a new file, and then send that.  Clumsy, but if the
file was 300K long, and 299K was sent successfully, it beats having to
resend the whole thing...]

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

End of Info-Kermit Digest
*************************
-------
15-Mar-85 17:27:57-EST,19023;000000000000
Mail-From: SY.FDC created at 15-Mar-85 17:27:11
Date: Fri 15 Mar 85 17:27:11-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #13
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 15 Mar 1985       Volume 2 : Number 13

Departments:

  UNIX KERMIT -
    C-Kermit for NCR Tower
    C-Kermit v 4.2 Bug Summary

  MS-DOS KERMIT -
    Kermit for DG One?

  MISCELLANY -
    Resonating Packets + Handshaking
    To Ack or to Write ...
    Kermit Packet Length

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

Date:     Wed, 13 Mar 85 22:58 EST
From:     Larry Afrin <[e-mail]>
To:       [e-mail]
Subject:  C-Kermit for NCR Tower

I am pleased to report that C-Kermit compiles almost perfectly and runs
beautifully on our NCR Tower System V machines.  (The minor compilation
error was due to a global variable being defined in one place and being
redefined and initialized at a later point in the same module.)  Of
course, this compilation required the "make sys3" command, not the "make
tower1" we used for the 1.02 machines.

A note on the documentation: we're novices to Kermit, and the
documentation didn't explain too well (in our opinions, anyway) what the
relationship is between server mode and file transfers and remote
commands.  Briefly, what we were doing with Kermit was to login on two
different machines, bring up Kermit on both, have one of them dial in to
the other system's dial-in modem to which the other Kermit has already
"allocated."  Then one of us would try to "get" or "send" a file to the
other, or one of us would enter "server" and the other would try "get" or
"send".  Needless to say, this did not work.  What we finally did was to
dig out an old issue of Byte magazine, which told us that a user on one
machine should call up Kermit, dial in to another machine, call up Kermit
on the remote machine, enter "server" to the remote Kermit, escape back to
command mode in the local Kermit, and then try the "get" or "send" or
whatever.

                    -- Larry Afrin
                       Dept. of Computer Science
                       Clemson University

[Ed. - Larry also reported, and sent fixes for, many problems with the NCR
Tower OS 1.02 support.  The fixes should appear in the next release.  The
problems resulted from my attempts at fitting John Bray's Tower code for
release 4.0 into what had become 4.2, without being able to test it.

The documentation is just a chapter from the Kermit User Guide, the first
couple chapters of which are devoted to a general explanation of Kermit.
The remaining chapters, of which the Unix Kermit manual is an example,
give information for each major implementation, concentrating on the areas
where it differs from the general description.  I thought everybody had a
Kermit User Guide...]

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

Date: Fri 15 Mar 85 14:02:40-EST
From: Frank da Cruz <[e-mail]>
Subject: C-Kermit v 4.2 Bug Summary
To: [e-mail]

Many people have reported problems with (and suggested cures for) C-Kermit
version 4.2.  These reports have been (greatly) condensed into a file
CKERMI.BWR ("beware"), which is reproduced below, and which will be kept
up to date in the Kermit distribution area.  Some of the people who sent
reports or comments are John Bray (who supplied the Tower OS 1.02 support
for v 4.0, which I broke), Gregg Wonderly (okstate), James Matheson
(somewhere in England), Herm Fischer (Litton Data Systems), Monty Solomon
(Creative Concepts), Marco Papa (USC), Yekta Gursel (MIT), John Zsarnay
(CMU), Steve Grandi (NOAO), Dan Schullman (DEC), Larry Afrin (Clemson),
Scott Weikart (Stanford), Dave Robinson (JPL).  There were others too; the
pile is pretty thick.


-- SUPPORT FOR ADDITIONAL SYSTEMS: --

VAX/VMS: Added by stew%lhasa.uucp@harvard, not available yet (see below).

4.1BSD: C-Kermit built with "make bsd" does not work under 4.1.  The date/
  time stuff and line locking stuff are completely different from 4.2.
  Also, the directory format is different, so traverse() doesn't work.
  Specific support needs to be added for 4.1.  (John Zsarnay@CMUA)

Regulus: Submitted by Joe Smiley, DuPont Co.  Extensive changes to 4.0
  were too hard to fit into 4.2; hope Joe can add the Regulus support to 4.2.

NCR Tower, OS 1.02: Submitted by John Bray, based on 4.0, fitted into 4.2,
  but it doesn't work in 4.2; it will be fixed.

NCR Tower, System V: Works ok -- "make sys3"

HP9000 Series 500: (from YEKTA@MIT-MC):  Use "make sys3", but
  1. Remove -i from CFLAGS & LI
  2. In ckxunx.c, don't #include<sys/file.h> or ioctl.h.
  3. In ckzunx.c, don't #include<sys/file.h>.

Plexus P-60
  Works ok with "make sys3", but doesn't always hangup even when hupcl
  is on (Scott Weikart, Stanford).

Masscomp/RTU 2.2:
  Works ok with "make sys3" (Stan Barber, neuro1!sob@rice).

Pro/Venix 2.0 (field test):
  Works ok with "make sys3", except the "unsigned long" has to be changed
  to "long" in ckdebu.h; may be a bug in the new compiler (Dan Schullman, DEC).

SUN:
  C-Kermit 4.0 with 4.2bsd support was reported to run OK on the SUN after
  some bugs with long strings, char vs int, etc were fixed.  There is now
  a report that version 4.2 doesn't even compile on the SUN because of the
  ^L's in the source file (can this be true???), and that once compiled
  (by removing ^L's) it doesn't transfer files at all, but just times out
  after many retries of the first packet (this report from daver@cit-vax).
  Has anyone had any luck with C-Kermit 4.2 on the SUN?


-- BUG LIST --

General problems:

- Conditionalizations are not done clearly.  In some cases it might be
  better to have compile-time flags for features, rather than systems, or
  generic system names, rather than specific vendor/machine names, to
  avoid excessive nesting or OR'ing of compile-time variables.

- It might also be better to have a -D in the makefile for the system name,
  rather than hard-coding it into the ck[xz]*.c modules.

- Program's return code might be wrong in some cases (in 4.0, it was always
  zero; in 4.2 some attempt is made to return correct codes for failure and
  success).

- "quiet" (-q) flag does not turn off all error messages.  Direct use of
  fprintf(stderr,...) should be replaced by invocations of ermsg().

- The error messages should use the current prompt (changed via 'set prompt')
  rather than "C-Kermit" as a prefix, to make it easier to see which Kermit
  a message is coming from, if you have a C-Kermit on both ends of the line.

- Interrupt handling is not done particularly well, and if the program
  crashes or is halted while it has the terminal in a not-normal mode
  during command parsing or file transfer, the terminal mode is not restored.
  Code should be added to trap quit or panic interrupts and restore the
  terminal before quitting or panicking.

- Many people have asked for a system-wide startup file similar to
  the user's .kermrc file, perhaps with a conditional way to escape from
  it if the user has her own .kermrc file.  This notion might be extended
  to include the entire hierarchy system -- home -- current directory.

- A deeper problem with the initialization files is that the file is only
  taken when the program enters interactive command dialog.  To be consistent,
  it should also be taken when the program is run via command line arguments.

- Moving the program to VAX/VMS uncovered a few remaining Unixisms:
  . VMS uses program return codes with opposite sense from Unix; return
    code values must be conditionalized.
  . ".kermrc" doesn't work as a file name on most non-Unix systems.
  . There should be a more portable way of handling baud rates tables.

ckzunx.c:

- In zsout() & friends, "fprintf(fp[n], s);" should be "fputs(s, fp[n]);"
  or 'fprintf(fp[n], "%s", s)', to prevent core dumps when s happens to
  contain a '%'.

ckxunx.c:

- Many problems reported with "uucp line locking" --
  . On some systems, uucp apparently ignores the lock and breaks in anyway.
  . On some systems, the lock directory is write-protected.
  . On some systems, the lock directory is read-protected.
  . Reportedly on some systems (Sys III?), using dial commands and a login
    script pointed at a line already in use by uucp will hang up the line
    on uucp.

  Unfortunately, a lot of code will have to be added to take care of the
  many different ways that sites are set up to handle line contention and
  assignment, probably selectable by makefile compiler switches (see below).

ckdial.c:

- Some systems do not allow users to manipulate dialers directly.
- Not easy to add support for new dialers.
- Some systems never return from the 100-character rawmode read (it is assumed
  return is immediate, indicating how much was obtained from the input buffer).
- Timed read for connect/no carrier message from modem within a general timer
  on the whole operation does not work on some systems.
- Some systems need to have the modem explicitly hung up; close() isn't enough;
  e.g. ioctl(ttyfd,TIOCCDTR,0) on 4.2bsd.
- On some systems, the entire output from the dialer (e.g. "CONNECT") cannot be
  read in a single gulp, so the buffer should be appended to between successive
  reads, not overwritten.

ckus*.c:

- Some help messages still produce core dumps on some systems.  Diagnosis: the
  strings in these messages ('help remote', 'help set' are mentioned most
  frequently) are still too long for some systems.  Cure: shorten them some
  more, and maybe replace

    for (i=0; *s[i]; ++i) fputs(s[i], stdout);
  with
    while (*s[0]) fputs(*s++, stdout);

  in hmsga() to prevent possible references to tender memory.  Also, replace
  all printf(msg) with printf("%s", msg);

- The "directory" command produces a full recursive directory listing.  It
  should only list the current directory.  On bsd systems at least, the listing
  can be interrupted with a single ^C, which returns you to C-Kermit> command
  level.  Diagnosis: ???  The program just does a system("ls -l").  Why doesn't
  this behave the same as "ls -l" typed at the shell?

- Parser for the 'get' command doesn't respond well to editing; can go into
  infinite loops under some conditions.

- The filename 'transaction.log' is too long for some systems, and gets
  truncated (no harm is done, but the user is not informed and may not be
  able to find the file).

ckcmd.c:

- Some systems (such as Venix/11) swallow the erase and kill characters
  when the terminal is in cbreak mode.  If the erase and kill characters are
  are ^U and DEL, then these can't be used to edit C-Kermit interactive
  commands.  Ditto for ^R.  Diagnosis: sigh, let's hear for portability.
  Cure (if you can call it that):  Add new SET commands to allow the
  erase, kill, and redisplay characters to be redefined.

- There's no way to break a command line and continue on the next line.
  Cure: add code to allow "\" followed by CR (or LF, or FF) to accomplish
  this.  Nobody really wants to put a real CR (LF, FF) in the middle of a
  command anyway, right?  This will make take files and login scripts a
  lot more readable.

- No way to put comments in take files.  Cure: Add a ";" or "#" command?
  Trailing comments will be harder.

Protocol (ckprot.w, ckfns*.c):

- No way to interrupt a protocol transaction until after it starts
  successfully.  For instance, no way to interrupt the timeouts and
  retransmissions of the initial packet when the other side is not
  responding, except for killing the whole program.  Cure: check for
  keyboard "interrupts" during the send-init process.

- When receiving from a non-timed-out Kermit and missing the Send-Init
  packet, no NAK is ever sent, and a deadlock occurs.  Diagnosis: resend()
  is called to resend the previous packet; there was no previous packet,
  so it sends an empty line.  Cure: Initialize the packet buffer with a
  NAK for packet 0?

- When parity is in use and the other Kermit cannot do 8th bit prefixing,
  the user is not warned that binary files will not be transferred correctly.

- 'set file names literal' does not work at all.

ckconu.c:

- Doesn't do any particular kind of terminal emulation.  It wasn't meant to.
  Filters can be used for this.
- Performance is poor on systems that can't check the input buffer.
- As structured, connect mode can't include commands to toggle logging on
  and off or to change settings, because forks can't share variables.

ckwart.c:

- Has typedef for CHAR as "unsigned short" or "unsigned char".  Cure:
  Have ckwart.c use the typedefs from ckdebu.h, like the regular Kermit
  modules do.

makefile:

- Replace "wart ckprot.w ckprot.c" with "./wart ckprot.w ckprot.c" because
  "." might not be in the current path.

- It was suggested that the compound entry for making ckprot.o should be
  broken into two entries, one for ckprot.o, one for ckprot.c, to prevent
  unecessary recompilations.

- Some of the problems caused by access restrictions on the uucp lockfile
  directory might be addressed by having the makefile check and then setting
  an appropriate compile switch, e.g.

    if [ -w /usr/spool/uucp ]
    then make bsd "... -regular flags"
    else make bsd "... -DNOLOCKING"
    fi

[Ed. - This bug list will be kept up to date in KER:CKERMI.BWR on CU20B,
available via anonymous FTP.  Also, the list of who's working on what is
also updated frequently; it's in KER:CKWHO.TXT.]

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

Date: Fri, 15 Mar 85 09:17:57 mst
From: unmvax!wampler@LANL (Bruce Wampler)
To: lanl![e-mail]
Subject: Kermit for DG One?

    I have been having great success with the IBM PC version of
Kermit, then tried to run it on my new Data General One portable.  It
seems that the DG One is ROM call IBM compatible, but they apparently have
used different serial port hardware than the 8250 - thus kermit (or
Cross-Talk or ASCOM for that matter) will not run on the DG One.  I
haven't been able to get the DG tech ref manual yet.  Has anyone done the
port to the DG yet?  Does anyone know what hardware they are using at the
serial port?  I'll try the port if no one has done it when/if I get the
scoop on the hardware.  Thanks.

Prof. Bruce E. Wampler, UNM CS Dept.

[Ed. - According to previous issues of the Info-Kermit digest, the DG/1
uses an 8251 communications processor instead of an 8250 for serial i/o.
The "generic DOS" version of MS-DOS Kermit does not access the i/o chip
directly, but rather uses only DOS calls.  Thus one might expect it to
work on the DG/1, but very slowly (can anyone confirm this?).  Glenn
Everhart at RCA, who modified an old version of IBM PC Kermit to run on
the Seequa Chameleon, says that the Seequa version uses IBM ROM BIOS calls
for this, so the Seequa version (KER:SEEQUA.ASM) might work on the DG/1 if
the DG/1 emulates the IBM ROM BIOS.  Has anyone tried this?  Is anyone
working on DG/1 support for MS-DOS Kermit?]

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

Date: Wed, 13 Mar 85 12:24:37 pst
From: Ken Poulton <@csnet-relay.arpa,@hplabs.CSNET:[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Resonating Packets + Handshaking

>[Ed. - Buffer flushing and line turnaround handshake can coexist, using
> the trick found in the new C-Kermit -- If handshaking is being done, then
> just redefine the packet terminator to be the handshake character.  Then,
> once the packet is read, you can go ahead and clear the buffer.

If the read of the line terminator char is done in the packet reading
routine, I suspect that this will cause poorer performance.  Once the
packet is read, C-kermit should start preparing the next packet it will
send, so it is *ready* when the XON handshake character comes.

I will let you know whether this is a problem when I can get
the new C-Kermit running on my 4.1BSD system (it doesn't, right now).

Ken Poulton

[Ed. - This would only be a consideration in Kermits that are totally
interrupt-driven in packet processing; I don't know of any that are.
See above about C-Kermit vs 4.1bsd.]

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

Date:     Fri, 15 Mar 85 15:53:37 GMT
From:     [e-mail]
To:       [e-mail]
Subject:  To Ack or to Write ...

     A minor point which arises from the discussion of timeouts &
resonating packets.  Have you thought carefully about whether a data
packet should be ack'd before or after the data is written to disk?  The
main consideration seems to be that if the OS overlaps disk I/O with other
work, then the "write-to-disk" call will complete quickly and it's safe to
ack early; if the disk can occupy real time (during which the
communications are dead), safer to delay the ack, write to disk & risk a
remote timeout.  There is a case for a switch, either dynamic or
compile-option.
                                        Chris Kennington.

[Ed. - The decision on when to ACK varies from system to system.  Ideally,
one should only ACK a data packet after one has processed it successfully.
If there is a failure to write to disk, an error packet should be sent
instead of an ACK.  In practice, a disk write might take such a long time
(e.g. on a slow floppy with a lot of data buffered for it in memory) that
the ACK should go out first to reduce the chance that the other system
will time out before the write is completed.]

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

Date:    Thu, 14 Mar 85 12:12:13 EST
From:    Steve Carmody <STC@BROWNVM>
To:      Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit Packet Length

With the advent of high speed, extremely reliable LAN's, has there been
any discussion of increasing the maximum length packet size beyond 94?
Because of the large number of existing kermit implementations, I'm
assuming that any such change would have to "negotiated" by the two
kermits during the SEND INIT sequence, in much the same way that other
optional features are negotiated.

[Ed. - It would be nice to allow longer packets, but since the packet
length is expressed as a single character, there's no way to increase it
without changing the protocol.  This could be accomplished rather
painlessly by (for example) using the currently unused lengths - 0, 1, and
2 - to specify that the first 2, 3, or 4 bytes of the data field give the
actual packet length.  This would, as you suggest, have to be negotiated
at Send-Init time.  This is just an idea; if the protocol is actually
changed to allow a mechanism like this, some more thought will have to go
into it.]

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

End of Info-Kermit Digest
*************************
-------
20-Mar-85 16:50:46-EST,20487;000000000001
Mail-From: SY.FDC created at 20-Mar-85 16:49:53
Date: Wed 20 Mar 85 16:49:53-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #14
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Wed, 20 Mar 1985       Volume 2 : Number 13

Departments:

  ANNOUNCEMENTS -
    New Release of PDP-11 Kermit
    Full-Featured MVS/TSO Kermit in PL/I from Rice University
    MVS/TSO Kermit Has Series/1 Support

  UNIX KERMIT -
    Manual Page for C-Kermit
    C-Kermit 4.2 comments
    Bad Bug in C-Kermit?
    C-Kermit on Pyramid?
    Making C-Kermit Work on the SUN
    C-Kermit on Four Phase 6300
    C-Kermit on Callan Unistar 300
    Want C-Kermit on PDP-11 with RT11

  MISCELLANY -
    Offer to Provide C-64 Kermit Diskettes
    CP/M KERMIT and Start-of-Packet
    Apple II Kermit for ProDOS?
    Please help - Tandy 2000 Kermit

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

DATE: WEDNESDAY, 20 MAR 1985
FROM: BRIAN AT UOFT02
TO: INFO-KERMIT AT CU20B
SUBJECT: New Release of PDP-11 Kermit

There is a new version of Kermit-11 available, version 2.26.  The main
reason for this release is TSX+ support. The changes from v2.24 are:

1. 35% thruput improvement for RSTS/E from changes in packet reading.
2. Added ^E,^X and ^Z aborts for sending files.
3. Added SET CONSOLE 7/8 for stripping the high bit off of characters
   in terminal emulation for P/OS to avoid odd characters.
4. More info in help file, particularily for binary file transfer.
5. Fix server replies (some replies had imbedded control characters.
6. Change default output record format to stream ascii for RSTS/E
7. Support is finished for TSX+. Sorry it took so long, but I do not
   have a TSX+ system. Others had to do the work (Ned Rhodes and Tony
   Movshon)
8. Changes % to ? in filenames for RSTS/E for GET and REMOTE DIR.
   Needed since some Kermits mangle the filename if you say GET MS???.*

                                                brian nelson
                                                [e-mail]

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

Date: Tue 19 Mar 85 19:42:29-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Full-Featured MVS/TSO Kermit in PL/I from Rice University
To: Info-Kermit@CU20B

There is an advanced version of Kermit for MVS/TSO written in PL/I (tested
in MVS/SP 1.1.1, MVS/SP 1.3, and MVS/XA) available from Rice University.
It is not included in the Columbia Kermit distribution because full source
is not provided, and the program cannot be built from the incomplete
source that is provided.  While Rice is willing to furnish the load
module, this cannot be accommodated in our most common tape formats, like
ANSI Format D, nor on non-IBM file systems (such as the DEC-20 and
VAX/Unix systems from which Kermit is distributed).  Therefore, those who
would like to obtain this version of Kermit should order it directly from:

    Andrea Martin
    P.O. Box 1892, Dept ICSA
    Rice University
    Houston, TX  77251
    Phone [phone]

If the full source becomes available, then this version of Kermit will be
included with the Columbia Kermit distribution.

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

Date: Tue 19 Mar 85 16:37:54-EST
From: Daphne Tzoar <[e-mail]>
Subject: MVS/TSO Kermit Has Series/1 Support
To: [e-mail]

The assembler version of IBM MVS/TSO Kermit, which is an adaptation by the
University of Chicago of Columbia's original VM/CMS implementation, has
had support added by Charles Painter, University of Toronto Computing
Services, for the Series/1 front end running the Yale ASCII Terminal
Communications System V2.1.  This allows PCs to transfer files using
Kermit even when they are connected to IBM MVS/TSO systems that believe
they are talking to 327x-style synchronous terminals, provided the
protocol emulation is done by the Yale IUP.

[Ed. - This replaces the Chicago TSO Kermit, since it is the same but with
the addition of Series/1 support.  It's available in the files KER:TSO*.*
on CU20B and on BITNET via KERMSRV at host CUVMA.  The documentation has
not been updated at all, and is somewhat dated.  Thanks to Philip Murton
of U of T for submitting this new release.  The forthcoming release of
VM/CMS Kermit will also have Series/1 support.]

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

Date: Mon, 18 Mar 85 16:09:43 CST
From: Stan Barber <neuro1![e-mail]>
Subject: Manual Page for C-Kermit
To: sy.fdc@cu20b

Here is a possible manual page for Unix Kermit...

Stan

[Ed. - Stan's man page is available as KER:CKERMI.NR.  We still don't have
the single source that generates both Scribe and Nroff input, but this
supplies the real man page that has been lacking up till now.  Thanks, Stan!]

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

Date: Fri, 15 Mar 85 20:22:04 pst
From: Ken Poulton <hpl-opus![e-mail]>
To: Info-Kermit
Subject: C-Kermit 4.2 comments

I brought up C-Kermit 4.2 on my HP 9000 Series 500, at last.

First of all, wow!  This is a great package.  My complements, especially
on the command interface.  It's really quite whizzy.  In fact, I like it
more than I expected I would (being a Unix die-hard).

I also have a large number of comments on things that could go smoother.
Although the list is long, remember that you have really done the job
well, and I'm just working on perfection now.

Rather than wait for time to make this a lengthy letter, I'm going to send
you my notes on C-Kermit.  Most of them are reasonably self-explanatory
(famous last words).  I expect some of them are being addressed already,
and others I will be interested in doing.

send cmd
    "send file [name]" is confusing syntax and precludes "send file file2..."
        which is what the Unix user expects
    "send file [-as name] [file [-as name]]..." more general

[Ed. - True, but the command package does not have a facility for parsing
alternates.  I had to stop somewhere...]

wildcards
    why not just use a shell to expand wildcards?
    Then wildcards are complete and consistent with normal usage.
    Surely speed is not an issue here.

[Ed. - No special reason.  The current way is more efficient, but you're
right -- you miss the compatibility with the shell.  Maybe somebody can
try writing zxpand() and znext() functions that do it with a shell.  On
systems without shells or pipes, the present do-it-yourself model will
still have to be followed.]

! cmd
    should use the shell defined by the env var SHELL, if defined
    "!cmd"     should work for Unix consistency (not just "! cmd")
    "!"        should get an interactive shell

[Ed. - The "!" command just does a system() of its argument.  Rather than
write all the code to fork and pipe the desired shell, maybe users can
just live with typing "! csh xxx" or "! ksh yyy" if they want these
effects.  A space is needed after "!" because "!" is a command keyword,
and whitespace must separate command fields.  Removing this limitation
would probably make the command package a lot hairier.  Maybe to alleviate
the confusion that this causes, the "!" should be renamed (back) to "shell".
Good point about this command invoking an interactive shell when no arg is
given -- just like it does now if you say "! sh" or "! csh".]

stat cmd
    can't we get timing info to get effective baud rate?

[Ed. - If you have given a "set speed" command (or -b option), then this
would be reasonable.  Otherwise, the program would not necessarily have a
reliable way of determining the baud rate.  I really tried to avoid all
this kind of system-dependent hair (system clocks, baud rates, etc)
because it tends to make the program grow out of proportion to its
functionality.]

space cmd
    should do a du for space used

[Ed. -  Maybe; du can produce a lot of unwanted output if there are many
subdirectories.  If you really want it, say "! du" instead of "space".]

command interface
    Use the user's line kill char rather than hardwire to ^U.
    Use the user's backspace char rather than hardwire to DEL/BS.
    Respond to the user's interrupt char rather than hardwire to ^C.
    Kermit not observing these is very annoying, since being able to
    choose them is a nice (and often used) feature of Unix.  This also
    confuses novices.

[Ed. - But the last guy said you should use something OTHER than the
user's line and char kill characters; can't please everyone.  Also,
again the point about system independence.  C-Kermit 4.0 was a pretty
clean program.  4.2 already has tons of hair added to the system-dependent
portions, and every time we add a system-related feature like this, it's
got to be added for n systems, and soon the program will be an enormous
pile of verbiage, buried somewhere in the middle of which will be the Kermit
protocol.]

interrupts
    behavior now is correct for interrupt in command-line mode
        (error packet, close line, exit)
    - you should not have to turn off interrupts in background -
        the shell is supposed to do that for you
    respond to the user's interrupt char rather than hardwire to ^C
    interrupts should be caught when running interactively !!
        (except in connect mode)
        - should act as ^B when transfer running
        - should *always* return to C-Kermit prompt after the first C-Kermit
        prompt (setjump/longjump does this rather trivially)
    - nearly every interactive program on Unix responds this way
    ^B doesn't work when send-init is failing

[Ed. - I'm not an expert on Unix interrupts.  But I don't believe the program
is hardwired to trap ^C -- rather, it tries to catch SIGINT.]

prompt
    default should be settable with cc -DPROMPT
    does "set prompt" affect error messages - especially those sent
        in error packets?
    all error messages should use the prompt-string (maybe without the >)
        to make errors easier to track down when running in the background

[Ed. - Agreed.]

line locking
    locking upon startup for -l argument is more intuitive than waiting for
        first connect command
    should allow you to connect if you own the lock file
    - maybe ask first in this case?

[Ed. - Line "locking" aficionados are enouraged to carry on this
discussion among themselves until the end of time.  I already have a stack
of correspondence on the subject about an inch thick.  It's impossible to
please everybody.  In this case, you can't please ANYBODY.]

script
    add ~d - delay for one second before sending next char
        for talking to slow network controllers (w/o typeahead)
    add ~x - XON (needed as the prompt char when talking to HP 3000 or IBM)

[Ed. -  The ~d (and maybe also a ~w for wait-for-input timeout) escapes
are being added somewhere.  Good idea about ~x.]

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

Date: Sun, 17 Mar 85 04:50:13 est
From: Ken Yap  <[e-mail]>
To: [e-mail]
Subject: Bad Bug in C-Kermit?

I have discovered that if C-Kermit is sending a file and it is interrupted
with ^C for example, that file gets deleted.  Surely this should only
happen if the file is being received and "keep incomplete" is off?

    Ken

[Ed. - You're right about what should happen, but on my 4.2 bsd system I
can't reproduce the problem.  Has anyone else seen this happen?]

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

From: trwrb!trwspp!spp3!kurisaki@Berkeley (Lance R. Kurisaki)
Date: Mon, 18 Mar 85 09:36:24 pst
To: [e-mail]
Subject: C-Kermit on Pyramid?

Am I the only one who has had problems getting C-kermit V4.2 running on the
Pyramid 90x (under 4.2 bsd)?  It compiles fine, but doesn't do transfers.

                Lance Kurisaki
                {ucbvax|decvax}!trwrb!trwspp!kurisaki

[Ed. - See the next message.  I thought this had been fixed, but apparently
it wasn't.  Sorry!]

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

Date: Wed, 20 Mar 85 14:59:12 est
From: [e-mail] (Mike O'Connor)
To: info-kermit@cu20b
Subject: Making C-Kermit Work on the SUN

I am in the process of installing 4.2 Kermit on my SUN system. There were no
problems in compilation or in using Kermit to login to our local VMS system.
File transfers, however, did not work. Kermit would send out the "send init"
packet and then time out waiting for a reply. The problem turned out to be
the definition of a local variable in the routine "ttinl". The variable "c"
is defined as an integer instead of a char.

Apparently when a byte is read and put into "c" the byte is placed in the
high order byte of the integer. But when "c" is assigned to "dest[x]" the low
order byte is used, filling "dest" with NULLs.

After making the change to "ckxunx.c" (which is where "ttinl" is located) I
used "make bsd" and am apparently up and running.

I've used this version of Kermit to move half a dozen ASCII files from the
SUN to the VMS system so far without any problems.

                Mike O'Connor

[Ed. - Thanks, Mike!  Presumably, this will also fix the Pyramid.]

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

Date:  Tue, 19 Mar 85 13:45 MST
From:  "Kevin W. Laurent" <[e-mail]>
Subject:  C-Kermit on Four Phase 6300
To:  Frank da Cruz <[e-mail]>

I just wanted to drop you a short note to let you know that we got the
new C-Kermit running on a Motorola Four Phase 6300 under UNIX.  I've
never seen a port go as smoothly as this one.  We used `make sys3' and
only had two problems--3 doubly defined variables (ncmd, nprm, nrmt) in
ckcmd, and the problem in the makefile with ckprot mentioned in Digest
#13.  Thanks for doing such a fine job, everyone!

[Ed. - Thanks to Herm Fischer for adding the Sys III/Sys V support, and
to the manufacturers for providing fairly consistent implementations.]

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

Date: Tue 19 Mar 85 17:49:40-EST
From: J. Eliot B. Moss <[e-mail]>
Subject: C-Kermit on Callan Unistar 300
To: sy.fdc@CU20B

The second pre-release version seems to work fine on a Callan Unistar 300,
which uses the Unisoft System V port to the 68000.  I have noticed nothing
strange (beyond the bugs already reported), and it compiled fine as received.
Thanks for the good work, everybody!
                Eliot

[Ed. - I assume that one builds it with "make sys3", since it runs a System V
variety of Unix.]

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

From: Dave Yost <day@rand-unix>
Date: 19 Mar 85 16:36:30 PST (Tue)
To: info-kermit-request@cu20b
Subject: Want C-Kermit on PDP-11 with RT11

Is anyone doing this port?  Thanks.

[Ed. - Somebody may try to produce a DECUS C version, nothing definite yet.]

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

Date: Sun, 17 Mar 85 20:48:14 est
From: Robert Scott Lenoil <[e-mail]>
To: [e-mail]
Subject: Offer to Provide C-64 Kermit Diskettes

I just posted the following message to USENET.  Briefly, I offered to
provide copies of diskettes containing Kermit for the Commodore 64
for seven dollars, to defray my costs (diskette, mailer, postage,
wear and tear, and my time - which will be a lot, considering that I
only own a single disk drive, and therefore will have to swap disks
back and forth to perform a copy.)

To address your problem (how to obtain Kermit) I thought I'd let you know
that I am willing to provide Kermit diskettes to those people who are
reluctant or unable to go through the downloading procedure.  For $7.00
(U.S. funds), I will provide a diskette containing the executable code and
documentation file.  (Outside North America, please enclose an extra $1.00
to cover additional mailing expense.)  Send requests and inquiries about
Commodore-64 Kermit disks to the address below.

Note that Kermit is written using the CROSS cross assembler which runs
only on DEC-10's and DEC-20's; hence enclosing the source code would not
be of much help.  An additional problem is that the source code is larger
than an entire 1541 diskette, and therefore would be too much trouble for
me to copy.

Please note that I am not conducting a business.  I am making this offer
to increase the availability of Kermit, which I hold to be a fine program.
I must stress that Kermit may be copied free of charge, so long as this
copying is not for "explicitly commercial purposes"  (Taken from Columbia
University's policy document on Kermit distribution), and those of you who
wish to do so may download it free of charge from Columbia University
machine CU20B (on ARPANET), using BITSERVE (from BITNET), or via UUCP from
host OKSTATE.

If people have questions, they can contact me by sending mail to
lenoil@mit-eddie.  Mit-eddie is on both the DoD internet and USENET, so
I'm fairly accessible.  Also note that I will not be at my present U.S.
mail address for this summer, but my network mail will forward.
Therefore, starting in June, it would be a good idea to first send me
computer mail to obtain my current mailing address, rather than suffer the
problems of delay and lossage of forwarded U.S. mail.

Yours truly,
            Robert Lenoil
            229 Commonwealth Avenue
            Boston, MA  02116  (USA)

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

Date: Fri 15 Mar 85 21:55:14-CST
From: Stuart Schmukler <STAFF.SAS@UChicago>
Subject: CP/M KERMIT and Start-of-Packet
To: sy.fdc@CU20B

I have finished modifing the CP/M 4.04 kermit to support SOP
(Start-Of-Packet) setting.  The syntax I have chosen is:

        SET START-OF-PACKET <cr>
        enter character:                !You type ^C, ^A etc.

The additional code adds about 1KB to the CP4KER.HEX file so that the
variable OVLADR is now 3600 for the CP4TYP.ASM file.

Now that I have a KERMIT that is working for our IBM, the users want to
be able to generate a BREAK.  So I'll add BREAK code to the CP4TYP.ASM
file for the MORROW MICRO DECISION I (UDI in the TYP defines) and
others _IF_ some one sends me the code to do it.  I have not been able
to findout from Morrow's doc what UART they use (the KERMIT code does
not help either).

SaS

PS: I have noticed that the RICE TSO KERMIT calls SOP 'marker'. Is there a
"standard" syntax?

[Ed. - "mark" is the term used for this field in the Kermit Protocol
Manual, chosen primarily for its shortness.  "Start-of-Packet" is a better
phrase for users.  Stuart's SOP changes for CP/M Kermit will be provided
to Charles Carvalho, the current CP/M Kermit keeper, when they arrive;
meanwhile, if anyone can help with the BREAK-sending code for the Morrow
or any other CP/M systems whose Kermits still can't send BREAK, please do.]

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

To: [e-mail]
Subject: Apple II Kermit for ProDOS?
Date: 18 Mar 85 10:31:00 PST (Mon)
From: Stephen <[e-mail]>

Is there a ProDOS version of Kermit running about somewhere?

            -- Stephen Willson

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

Date: 18 Mar 1985 23:32:31 EST
From: [e-mail]
Subject: Please help - Tandy 2000 Kermit
To: [e-mail]

Anyone feel charitable?
    I am a novice Kermit user actually attempted user that owns a new
micro (TANDY 2000 w/256K,MASM,SOFTERM2000 comm package,BASIC,LOTUS, &
MULTIMATE) on the Arpanet via ABN.BOYD@usc-isid. I have had virtually no
success with either TA2000.ASM or MSGENER.ASM (modular) Kermit versions. I
downloaded these two versions from CU20B, assembled, linked and attempted
to download text and binary files with no success. TA2000.ASM would fail
but clearly attempt to execute via timeouts. Repeated tries with KERMIT-20
in server mode were not successful. MSGENERIC assembled and linked (I
double checked to insure all files were included) but it failed to
properly open or identify the com port each time. Not sure I understand
correct response to handle: prompt, but took program prompt/suggestion to
use "3" each time. No success.
    Are there any Tandy 2000 users out there that could offer some
advice or assistance. I do have SOFTERM 2000 comm package that correctly
transfers micro to micro w/XMODEM protocol. I'll glady pay any phone
charges if someone has an executable (.EXE) version that will use MSDOS 2.0
capable kermit.

    Joe Boyd
    2109 Elvira St. Apt #902
    Fayetteville, NC 28303
    (919)-494-2203

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

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

-------
22-Mar-85 18:25:13-EST,15565;000000000000
Mail-From: SY.FDC created at 22-Mar-85 18:24:29
Date: Fri 22 Mar 85 18:24:29-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #15
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 22 Mar 1985       Volume 2 : Number 15

Departments:

  ANNOUNCEMENTS -
    Corrections, Reminders, Notes
    New MVS/TSO Kermit Recalled
    New Kermit for Honeywell DPS-8 with GCOS
    New Kermit for TRS-80 Model 4
    New Kermit for TRS-80 Color Computer with Radio Shack DOS

  UNIX KERMIT -
    C-Kermit Suggestions, Comments
    Installing Kermit on CADMUS (system V)
    C-Kermit Comments Revisited
    More C-Kermit Line Locking Problems

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

Date: Fri 22 Mar 85 13:45:54-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Corrections, Reminders, Notes
To: Info-Kermit

The previous issue of the digest was V2 #14; it was correctly labeled in
the message "Subject:" field, but internally it said V2 #13.  Sorry.

I fell behind a little bit in mailing list additions, deletions, changes.
They should be up to date now.  There are currently 315 addresses in the
Info-Kermit list, and many of them are themselves distribution lists.  If
you get this message and didn't want it, or didn't get it but did want it,
then let me know.  Some of the people who asked to be removed were not on
in the first place, which means they must be getting Info-Kermit through a
local redistribution list.

In the previous issue I forgot to say that the new release of Brian
Nelson's PDP-11 Kermit is available, as usual, via anonymous FTP from host
CU20B.  The files are KER:K11*.* (there are about 88 of them!); the file
KER:K11FIL.DOC explains what they are.

For those who haven't seen the following information before, or for a long
time, here it is again, briefly:

A complete collection of Kermit programs, documentation, and other files
is available on CU20B, a DECSYSTEM-20, Internet host number 192.5.43.128,
using the Internet FTP (File Transfer Protocol) facility: login via FTP
(not TELNET) as user anonymous, any password will do, and GET or MULTIPLE
GET the file or files you want.  Several files are of special interest:

KER:00README.TXT tells what files are available and how they are named.
KER:VERSIONS.DOC lists existing versions and those in preparation.
KER:CURRENT.DOC  lists current versions chronologically.
KER:FLYER.DOC    gives ordering information for Kermit on magnetic tape.

Kermit files are also available via BITnet ("SMSG RSCS MSG CUVMA KERMSRV HELP")
and UUCP (from host okstate; see recent Info-Kermit messages).  New files
usually take a few days to find their way to these alternate sources.

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

Date: Fri 22 Mar 85 11:45:54-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: New MVS/TSO Kermit Recalled
To: Info-Kermit

The TSO Kermit modified at the University of Toronto for Series/1 front
end support announced in the previous issue of the Info-Kermit digest has
been recalled.  It turns out that the modification allows it to work ONLY
with the Series/1, and does not allow it to work over ordinary asynchronous
connections.  So now, we have three MVS/TSO Kermits:

1. The original, from U of Chicago:   KER:TSOKERM.*, KER:TSODYNAL.*
2. (1), modified for Series/1:        KER:TSOS1.ASM
3. The Rice University PL/I version:  KER:TSORICE.HLP tells how to get it.

Sorry for the confusion.

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

Date: Thu 21 Mar 85 18:56:20-EST
From: Frank da Cruz <[e-mail]>
Subject: New Kermit for Honeywell DPS-8 with GCOS
To: [e-mail]

Contributed by John Huxtable of the University of Kansas in Lawrence, this
new Kermit (unrelated to the other Honeywell GCOS Kermit donated by Terry
Carlin of Honeywell) operates in remote mode only, is capable of acting as
a Kermit server, and provides options supporting the different communications
modes used on Honeywell mainframes, and all GCOS file formats.  The files,
including B language source, the executable program in packed-text form
along with a Fortran unpacker, documentation, and ROFF documentation source,
are available via anonymous FTP from CU20B as KER:HDPS8.*.

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

Date:     20 Mar 85 13:43:35-CST (Wed)
From:     Gregg Wonderly <[e-mail]>
To:       [e-mail]
Subject:  New Kermit for TRS-80 Model 4

Here, finally, is the Model 4(p) Kermit for TRSDOS 6.1.  I decided to go
ahead and let you have it before I got all of the stuff that I really want
to add, added.  I named all of the files M4* noting that this did not
confilict with any of the files we have in the distribution.

[Ed. - Thanks, Greg!  It looks like a very complete implementation,
including VT52 emulation with key mapping and session logging, a full
complement of SET commands, command and initialization files, and a script
facility based on the INPUT/OUTPUT/PAUSE/CLEAR model with some
extensions.  The files are in KER:M4*.*, available via anonymous FTP.]

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

Date: Thu 21 Mar 85 19:01:49-EST
From: Frank da Cruz <[e-mail]>
Subject: New Kermit for TRS-80 Color Computer with Radio Shack DOS
To: [e-mail]

Contributed by Wes Hubert of the University of Kansas, this new Kermit
implementation runs on the TRS-80 CoCo with the Radio Shack disk operating
system.  It requires a machine with at least 16K memory and one disk drive,
and the Radio Shack disk ROM 1.0 or 1.1.  The program is available via
anonymous FTP from CU20B as KER:CC*.*.

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

Date:     20 Mar 85 21:15:59-CST (Wed)
From:     Gregg Wonderly <[e-mail]>
To:       sy.fdc@cu20b
Subject:  C-Kermit Suggestions, Comments

    Just got a few more ideas of improvements to C-Kermit, and would also like
to hear of anything that others have sent your way since you last posted the
Bugs report.

1)  How about making SET LINE look in a file for valid devices.  We would like
    to let certain students go out through the network, and get onto other
    machines to use KERMIT.  Since you can really create a LCK.. file for
    more devices than we would like, it would seem natural to limit the valid
    outbound lines, based on a file similar to /etc/passwd, where you have
    login names, passwords, and other info.  This way, someone can not lock
    up the UUCPKER, UUCP, or CSNET lines.

[Ed. - Several objections: (1) Adds yet more hair, and associated startup
time to the program; (2) Doesn't really accomplish anything, since none of the
other programs that use tty devices would honor this convention; (3) Starts
moving Kermit into the category of software that can only be installed and
maintained by the system manager -- something I want to avoid.]

2)  After much frustration, I have decided that there probably really should
    be complete trapping of all interupts.  It seems that Mark Vasoll, and my-
    self have this habit of hitting delete (Our ^C) in the middle of a command
    line when we mistype.  If SIGINT is traped in the parser, and results in
    a parse error, than operation would be smoother.  I have said something
    to you before about this, but now I think it is manditory that it be done.

[Ed. - Yet more hair to be added to the program, but in this case, I'm
afraid I have to concur; it's really bad to leave the user with an
unusable terminal.  I hope that we can let this question ride for a while,
until after the next release.  I have to do a huge amount of work to get
the next release out -- merging in the VMS support, your own forthcoming
V7 support, and much else -- and would prefer to have the interrupt stuff
added on top of that by people who know more about these things than I do.]

3)  I have already changed all printf's, that did not require any format
    translations, i.e. no "%s", "%d", etc...  to calls to a function that I
    added in the chusr3.c module.   This function is quite simply:

outstr(s)
    char *s;
{
    while (*s)
        putc(stdout, *s++);
}

    This completely eliminates the problems associated with various systems
    different size buffers used in the printf() function.

BUGS:

    There seems to be some problems with recognition of error packets when get
    is used to retrieve a file from another server.  I found that when I asked
    for a file that did not exist, C-KERMIT kept retrying, while clearly there
    was a sequence of E%E%E%E%E% characters appearing on my screen.  Haven't
    looked at this one yet, but hope to by this weekend.

[Ed. - Strange.  I can't reproduce this one.  Please send more details.]

    Get also seems to be retrying an abnormal amount of times on certain files.
    This may be related to the double packet exchange that was recently
    discussed in the INFO-KERMIT digest.

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

Date: Thu, 21 Mar 85 14:51:12 est
From: decvax!ittvax!long@Berkeley (H. Morrow Long [Systems Center])
To: [e-mail]@sy
Subject: Installing Kermit on CADMUS (system V)

    We have been using the Unix Kermit Server Program with our
    other kermits and have found it to be very useful.  I sent you
    some implementation notes on the 4.1bsd versus 4.2bsd problem.
    Here is a new note on porting to the CADMUS.  We using 'make
    sys3' on the CADMUS the software will compile with a warning
    about truncating a pointer to an integer in the files ckwart.c
    and ckzunx.c.  When 'wart' (and 'wermit') are run they will die
    with 'segmentation violations' and core dump.

    The reason for this is the fact that the CADMUS C compiler uses
    16 bit integers and 32 bit pointers.  The routine malloc() was
    not declared as returning a character pointer (char *) and was
    therefore taken as returning a 16 bit integer (the default).
    The following change clears up the situation:

  char    *malloc();    /* Needed by CADMUS, and probably many 68000's */

                H. Morrow Long
                ITT-ATC Systems Center,
                1 Research Drive Shelton, CT  06484

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

Date: Thu, 21 Mar 85 14:55:16 pst
From: Ken Poulton <@csnet-relay.arpa,@hplabs.CSNET:[e-mail]>
To: [e-mail], [e-mail]
Subject: C-Kermit Comments Revisited

Well, I have a few responses:

> ! cmd
>     should use the shell defined by the env var SHELL, if defined
>     "!cmd"     should work for Unix consistency (not just "! cmd")
>
> [Ed. - The "!" command just does a system() of its argument.  Rather than
> write all the code to fork and pipe the desired shell, maybe users can
> just live with typing "! csh xxx" or "! ksh yyy" if they want these
> effects.  A space is needed after "!" because "!" is a command keyword,
> and whitespace must separate command fields.  Removing this limitation
> would probably make the command package a lot hairier.  Maybe to alleviate
> the confusion that this causes, the "!" should be renamed (back) to "shell".

Using the right shell is common courtesy for interactive programs on Unix.
The UW version of old C-Kermit does this, with one routine which works
on all systems, I think.

I understand about the parser, but "!cmd" is completely common on Unix.
This may be worth special-casing if the parser can be short-cicuited on just
this special case.  Seems like it might be an easy bypass.

> stat cmd
>     can't we get timing info to get effective baud rate?
>
> [Ed. - If you have given a "set speed" command (or -b option), then this
> would be reasonable.  Otherwise, the program would not necessarily have a
> reliable way of determining the baud rate.  I really tried to avoid all
> this kind of system-dependent hair (system clocks, baud rates, etc)
> because it tends to make the program grow out of proportion to its
> functionality.]

Fine, if it doesn't know, then it can't say, but *effective* transfer
speed (not line baud rate) is the main use of the stat command anyway - I
still have to use a stopwatch to figure out if it's running up to snuff,
so the stat command may as well not exist.

> command interface
>     Use the user's line kill char rather than hardwire to ^U.
>     Use the user's backspace char rather than hardwire to DEL/BS.
>     Respond to the user's interrupt char rather than hardwire to ^C.
>     Kermit not observing these is very annoying, since being able to
>     choose them is a nice (and often used) feature of Unix.  This also
>     confuses novices.
>
> [Ed. - But the last guy said you should use something OTHER than the
> user's line and char kill characters; can't please everyone.  Also,
> again the point about system independence.  C-Kermit 4.0 was a pretty
> clean program.  4.2 already has tons of hair added to the system-dependent
> portions, and every time we add a system-related feature like this, it's
> got to be added for n systems, and soon the program will be an enormous
> pile of verbiage, buried somewhere in the middle of which will be the Kermit
> protocol.]

A question of user-friendly versus "let's all use DEC-20 control chars".
The other guy had the right diagnosis, but the wrong cure: His problem
goes away if you *turn off* the line kill and backspace in the tty driver
(simple enough, while you're setting cbreak mode) and use the user's
control chars *since they are doing the same things*.

Ken Poulton

(I think we're making progress - this is shorter than my last letter.)

[Top-Level Ed. - I tend to agree with all this, but there are tradeoffs.
One is that the program has to be maintainable, and the more system
dependent features creep in, the less maintainable it becomes.  Another is
that the bigger it gets, the harder it is to shoehorn it into little systems
(in several senses -- memory segmentation a`la Pro/Venix, memory occupation,
disk space, time to load from disk, time to start up once loaded, etc etc.
Let's see how the next release turns out, if I ever get time to work on it.]

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

Date: Fri 22 Mar 85 10:34:23-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: More C-Kermit Line Locking Problems
To: Info-Kermit

Two recently reported problems with C-Kermit "line locking" --

Problem 1:

User tries to use a given line; ttopen() opens it, then calls ttlock(), which
finds it locked, gives the appropriate message, and returns failure.  User
then exits from program.  However, the ckx module still has a valid ttyfd for
the line, so when doexit() is called, the line is closed.  This tends to hang
up the line on whoever was really using it.

Problem 2:

User does connect, which calls ttopen(), which reports the line is in use.
However, since a valid ttyfd is left around, the next time the user does
connect, it works even though someone else is using the line.

Easy cure:

If ttopen fails to get exclusive access, put the ttyfd back to -1.

Better cure:

Don't open the tty before calling ttlock.  The only reason it's opened
first is for the benefit of flock().  Just get rid of flock(); it doesn't
do anything anyway.  After calling ttlock, THEN open the tty, and then do
the ioctl(ttyfd,TIOCEXCL,...) for those systems that support it.

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

End of Info-Kermit Digest
*************************
-------
 2-Apr-85 18:49:00-EST,9759;000000000000
Mail-From: SY.FDC created at  2-Apr-85 18:48:23
Date: Tue 2 Apr 85 18:48:23-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #16
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue,  2 Apr 1985       Volume 2 : Number 16

Departments:

  ANNOUNCEMENTS -
    New Edition of the Kermit User Guide Available
    Commodore-64 Kermit Bootstrap Program in C
    PDP-11 Kermit Problems and a Fix

  UNIX KERMIT -
    Problem with C-Kermit 4.2 Connect Command
    C-Kermit 4.2 on 4.1 BSD

  MISCELLANY -
    VTAM Translate Tables for TSO-KERMIT?
    Prime Kermit Bug
    MS-KERMIT 2.26/MULTICS-KERMIT and LU.EXE (binary file)
    Kermit for DG Eclipse running Calma DOS?

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

Date: Mon 1 Apr 85 17:58:50-EST
From: Frank da Cruz <[e-mail]>
Subject: New Edition of the Kermit User Guide Available

The sixth edition of the Kermit User Guide is now available.  The major
difference is that most of the chapters describing the specific
implementations have been brought up to date.  The introductory and main
sections have also been fleshed out a little.  The result, unfortunately,
is substantially bigger than the previous edition.  The new User Guide can
be obtained via anonymous FTP from CU20B as KER:KUSER.DOC.  The Scribe text
formatter source is in KER:KUSER.MSS (and in all the files it "@includes").

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

Date: Tue, 2 Apr 85  16:53 EST
From: [e-mail]
Subject: Commodore-64 Kermit Bootstrap Program in C

Here's "c64boot.c", a program to download files to the C64, modelled on
C64BOOT.CLU, for those who don't have CLU.  Although written on a Unix
system, the C code contains no kernel calls and should be fairly portable.
Written by: Alastair Mayer, U. of Guelph, 2-Apr-85

[Ed. - It's in KER:C64BOOT.C on CU20B, available via anonymous FTP.]

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

Date: Sun Mar 24 1985 13:52:17
From: Marco Papa <[e-mail]>
Subject: Problem with C-Kermit 4.2

I have encountered the following problem more than once now and on two
different versions of C-Kermit (the Berkeley and PC/IX).  While in
"connect" mode, using an Hayes-compatible modem, randomly the program
stops accepting input from the keyboard.  Sometimes I can at least escape
back locally and get the C-Kermit prompt, but sometimes there is no way to
get out of it.  On the other hand characters can continue to arrive from
the line and are correctly displayed on the screen.  Very distressing
under PC/IX, most of the time I cannot escape back to the C-Kermit prompt,
and the only thing that I can do is rebooting the system.  I have seen
this to happen at least once when garbage was coming in from the line. Has
anybody experienced a similar problem?

Marco Papa

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

Date: Wed, 27 Mar 85 02:58:08 pst
From: Ken Poulton <[e-mail]>
Subject: C-Kermit on 4.1 BSD

I put C-Kermit up on 4.1 BSD.  Doing it was really pretty easy: it turns
out that the Tower OS must be a 4.1 port.  Defining a general 4.1 version
was mainly a question of selecting from the Tower, BSD4, and UXIII code
already there; I only wrote two lines of C (but did lots of ifdef changes).

I'll be sending those changes along with my other changes, hopefully next
week.

[Ed. - Once these changes arrive, it will take a good amount of time to
fit them together with all the other changes -- I've got pile of notes and
contributions over an inch thick...]

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

Date:        24 Mar 85 17:35 +0100
From:        [e-mail]
Subject:     VTAM translate tables for TSO-KERMIT?

I have assembled TSO-KERMIT for MVS/XA and have now run into exactly
the problem described in the .BWR file: packets from TSO-KERMIT are
just not getting through to the terminal.

Our communications people know very little about the support of ASCII
terminals under TSO. They tolerate rather than support these as the
majority of our terminals are 3270s or compatibles, with no protocol
converters. If KERMIT is going to work, I will have to do most of the
work myself.

We are using pure IBM communications products under MVS/XA on a
3081-KX or a 3084-QX. We have very recent releases of ACF/VTAM and
ACF/NCP. I can find out the exact releases if this is needed to solve
the problem. The ASCII terminals connect either directly to the 3725
TP controllers using the NTO software or via X25 networks using the
NPSI software.

And now my question: which translate tables must be altered in order
that KERMIT will work ? I assume that we are using vanilla IBM-
supplied tables throughout. There are just so many places where
something could be going wrong that I would appreciate help in
pointing the probable places to be changed.

The TSO command TERMINAL has an operand CHAR which allows specific
translations to be specified. However setting values with this does
not seem to have the desired effect. The only hint is in the TSO
Command Language Reference which under the CHAR operand says "Do not
select characters which may be device control characters". I assume
this refers to CTRL-characters such as <CTRL-A>.

[Ed. - The IBM mainframe Kermit programs contain their own EBCDIC/ASCII
translate tables.  Data goes in and out of the program in EBCDIC, but ASCII
is used internally so that the checksum can be computed correctly.  When
the IBM system sends Kermit's EBCDIC packets out an ASCII line, it
translates from EBCDIC to ASCII (and conversely for incoming packets).
Thus, Kermit's translate table must agree with the system's.  If it
doesn't, then the Kermit translate table can be changed.  But note that
Kermit's table is invertible; if your system's table is not invertible,
you could have big trouble.  Kermit's table corresponds to the one given
in the IBM System/370 Reference Summary, GX20-1850-5.]

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

Date:     Fri, 29 Mar 85 12:08:07 PST
From:     [e-mail]
Subject:  PDP-11 Kermit

The version of Kermit-11 currently sent by KERMSRV is T2.24.  I have
installed this on our PDP-11/44 running RSX-11M-Plus version 2.1, and have
two bugs to report, one of which I fixed.

(1) In the subroutine assdev::, the starting label $1 is attached to the
statement after the save registers statement.  It should, of course, be
attached to the save statement, otherwise the subsequent unsave sticks
garbage into the registers and corrupts the stack pointer.  Unfortunately,
this did not fix the other problem, which is:

(2) Packet receiving is totally dysfunctional when Kermit-11 is operating
in local mode.  We have a hard-wired dialout modem connected to one of our
terminal lines (without the DSR and DTR lines hooked into our DZ11).
Version 2.11 of Kermit-11 sent and received files just dandy over this line,
but its terminal emulation was awful.  Version 2.24 fixed up the terminal
emulation and added several more Kermit commands, but in the process
broke the file transfer.  Debug mode of both Kermits confirms that packets
sent by Kermit-11 are received by the remote Kermit, but the reverse is
not true.

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

DATE: FRIDAY, 29 MAR 1985
FROM: BRIAN AT UOFT02
TO: SY.FDC AT CU20B
SUBJECT: kermit and rsx

Thanks for forwarding the note.  The thing regarding rsx ASSDEV:: routine
is odd, it must have been there since summer and no one caught it.
Regarding packet transfer, that's the first I've heard of it; too often
RSX systems seem to have quirks that are unique to the site -- it could be
a config problem.  After fixing the stack register save junk, I ran
Kermit-11 under RSX-11/M+ v2.1 on an 11/44 hardwired to a Rainbow at 9600
baud.  No problems were encounted using either the 11/44 or the Rainbow as
servers.

For those who need to know, in ASSDEV: move the 1$: to the save <r1,r2,r3>
line.  Only affects RSX (not P/OS) and only when the SET LINE command is
used.  File is K11M41.MAC

                                                brian nelson
                                                [e-mail]

[Ed. - The aforementioned fix is installed in K11M41.MAC on CU20B and
on BITNET KERMSRV.]

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

Date: Sun 24 Mar 85 23:14:41-PST
From: Bob Larson <BLARSON%ECLD@ECLA>
Subject: Prime kermit bug
To: [e-mail]

Prime Kermit is quoting the 8-bit character even when 8-bit quoting is not
being done.  Using defaults, this causes ampersands ('&') to be received
as lower case f's by some versions of kermit, e.g. the old Unix Kermit
that is the base of the current os9 kermit effort.

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

Date:  Sat, 23 Mar 85 14:32 EST
From:  "Eric J. Swenson" <[e-mail]>
Subject:  MS-KERMIT 2.26/MULTICS-KERMIT and LU.EXE (binary file)

I cannot seem to be able to transfer LU.EXE (on Multics) to my Z100
using MS-KERMIT 2.6.  MULTICS-KERMIT claims "wrong packet type" and
MS-KERMIT claims "unable to receive data".  I have indicated to
MULTICS-KERMIT that it should use binary mode, rather than text mode.

What am I doing wrong?

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

Date: 24 Mar 1985 2135-PST
From: FAE.WU at Ames-VMSB
Subject: Kermit for DG Eclipse running Calma DOS?
To: INFO-KERMIT at CU20B

Does anyone have a version of kermit for a Data General Eclipse running
Calma DOS?

Alex Woo

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

End of Info-Kermit Digest
*************************
-------
 3-Apr-85 15:32:32-EST,16357;000000000000
Mail-From: SY.FDC created at  3-Apr-85 15:31:44
Date: Wed 3 Apr 85 15:31:43-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #17, C-Kermit Bug List
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Wed,  3 Apr 1985       Volume 2 : Number 17

                           C-Kermit Bug List

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

Here is the current bug list for C-Kermit Version 4.2, along with a list
of implementations.  This file is kept on line in the Kermit distribution
areas as KER:CKERMI.BWR, but is being sent to Info-Kermit for the benefit
of the many subscribers who don't have access to FTP or KERMSRV.  The next
release, which will incorporate fixes for most of the reported problems
and support for most of the additional systems, will still be several weeks
in coming; still plenty of time to send in more bug reports and suggestions.


-- SUPPORT FOR ADDITIONAL SYSTEMS: --

4.2BSD: "make bsd" works.

4.1BSD: C-Kermit built with "make bsd" does not work under 4.1.  The date/
  time stuff and line locking stuff are completely different from 4.2.
  Also, the directory format is different, so traverse() doesn't work.
  Specific support needs to be added for 4.1.  Apparently very similar to
  the TOWER1 support.  4.1 support being added by Charles Brooks
  (brooks@edn-vax), and also by Ken Poulton ([e-mail]).
  4.2 can be differentiated from 4.1 with "#ifdef MAXNAMLEN".

ATT 3Bx systems: works ok with "make sys3", but works better if TCSETA
  changed to TCSETAW to allow i/o to drain before changing terminal modes;
  probably applies to all sys3/sys5 systems (chris@columbia-20).

VAX/VMS: Added by stew%lhasa.uucp@harvard, not available yet (see below).

Regulus: Submitted by Joe Smiley, DuPont Co.  Extensive changes to 4.0
  were too hard to fit into 4.2; hope Joe can add the Regulus support to 4.2.

Motorola Four Phase 6300 - works fine with "make sys3" (KLaurent@DENVER)

Callan Unistar 300 (68000) with Unisoft System V -- works fine with
"make sys3" (EBM@MIT-XX).

Cadmus 68000: Compiles ok with "make sys3", but core dumps because malloc()
  not declared (in wart and in ckzunx) as returning a char pointer; see below.

NCR Tower, OS 1.02: Submitted by John Bray, based on 4.0, fitted into 4.2,
  but it doesn't work in 4.2; it will be fixed in next release.

NCR Tower, System V: Works ok -- "make sys3" (except some problems reported
  when connected to IBM mainframes; see below).

HP9000 Series 500: (from YEKTA@MIT-MC):  Use "make sys3", but
  1. Remove -i from CFLAGS & LI
  2. In ckxunx.c, don't #include<sys/file.h> or ioctl.h.
  3. In ckzunx.c, don't #include<sys/file.h>.

HP9836U Series 200, HP-UX 2.0.0, rev B (BLO2@CMU-CC-TC):
  "make sys3", but need to add the following in ckxunx.c functions ttpkt()
  and conbin();
    ttraw.c_cflag |= CS8;              /* 8-bit chars */
    ttraw.c_cflag &= ~(PARENB|CSTOPB|ISTRIP); /* no parity, 1 stop bit */
  (This probably should be done in all sys3/sys5 systems).

Plexus P-60
  Works ok with "make sys3", but doesn't always hangup even when hupcl
  is on (Scott Weikart, Stanford).

Masscomp/RTU 2.2:
  Works ok with "make sys3", except for line locking (Stan Barber,
  neuro1!sob@rice).

Pro/Venix 1.x:
  Performance improvements and ability to interrupt transfers in progress
  need to be (and will be) added.  Currently there is no "line locking"
  to prevent interference with/by uucp.  Anybody know how Venix does this?

Pro/Venix 2.0 (field test):
  Works ok with "make sys3", except the "unsigned long" has to be changed
  to "long" in ckdebu.h; may be a bug in the new compiler (Dan Schullman, DEC).

SUN, 4.2bsd:
  C-Kermit 4.0 with 4.2bsd support was reported to run OK on the SUN after
  some bugs with long strings, char vs int, etc were fixed.  There is now
  a report that version 4.2 doesn't even compile on the SUN because of the
  ^L's in the source file (can this be true???), and that once compiled
  (by removing ^L's) it doesn't transfer files at all, but just times out
  after many retries of the first packet (this report from daver@cit-vax);
  oconnor@cdn9 reports that changing the definition of the local variable
  "c" in function "ttinl" from integer to char fixes the problem.

Pyramid 90x, 4.2bsd:
  Apparently same problem (and same fix?) as reported for SUN, above.

-- BUG LIST --

General problems:

- Unnecessary timeouts occur at low baud rates when parity is being done;
  in ckfns.c, inchr() is being called by inlin() with a timeout interval
  so small that MAXTRY could be exceeded before the whole packet was read.

- Conditionalizations are not done clearly.  In some cases it might be
  better to have compile-time flags for features, rather than systems, or
  generic system names, rather than specific vendor/machine names, to
  avoid excessive nesting or OR'ing of compile-time variables (do all C
  compilers support ORing?).

- It might also be better to have a -D in the makefile for the system name,
  rather than hard-coding it into the ck[xz]*.c modules.

- Program's return code might be wrong in some cases (in 4.0, it was always
  zero; in 4.2 some attempt is made to return correct codes for failure and
  success).  Also see note about VMS return codes, below.

- "quiet" (-q) flag does not turn off all error messages.  Direct use of
  fprintf(stderr,...) should be replaced by invocations of ermsg().

- The error messages should use the current prompt (changed via 'set prompt')
  rather than "C-Kermit" as a prefix, to make it easier to see which Kermit
  a message is coming from, if you have a C-Kermit on both ends of the line.

- The default prompt should be set from the makefile with -DPROMPT.

- Program still core dumps from time to time because of (f)printf(string)
  statements; "help remote" and "help set" tend to exhibit this behavior.
  These printf's must be replaced by (f)printf("%s",string), or puts()
  statements, or something like "while (*s) putc(xxx, *s++);".

- Local mode file transfer display could be improved.  First, for systems
  like Macintosh that have fancy screen management, the screen() function
  should be provided additional information as to what the arguments are --
  filenames or whatever -- so it can display them more intelligently.
  Second, on tty-style displays, the "percent done" could be shown by
  doing something like "0...1...2...3...4...5...6...7...8...9...".

- Interrupt handling is not done particularly well, and if the program
  crashes or is halted while it has the terminal in a not-normal mode
  during command parsing or file transfer, the terminal mode is not restored.
  Code should be added to trap quit or panic interrupts and restore the
  terminal before quitting or panicking.

- The shell's interrupt, delete, and kill characters can interfere with
  those used by the Kermit command parser.  C-Kermit should use those already
  set up in the user's environment (how to get them?).

- status command needs timing info, maybe also effective baud rate.

- "!" command should not require a space after, should use the user's
  customary shell rather than sh, and if issued without an argument should
  start an interactive shell.

- Many people have asked for a system-wide startup file similar to
  the user's .kermrc file, perhaps with a conditional way to escape from
  it if the user has her own .kermrc file.  This notion might be extended
  to include the entire hierarchy system -- home -- current directory.

- It would also be desirable to have a way of specifying alternate startup
  files on the command line, so that aliases could be defined for running
  Kermit on certain lines, at certain speeds, etc.

- A deeper problem with the initialization files is that the file is only
  taken when the program enters interactive command dialog.  To be consistent,
  it should also be taken when the program is run via command line arguments.

- Moving the program to VAX/VMS uncovered a few remaining Unixisms:
  . VMS uses program return codes with opposite sense from Unix; return
    code values must be conditionalized.
  . ".kermrc" doesn't work as a file name on most non-Unix systems.
  . There should be a more portable way of handling baud rates tables.

ckzunx.c:

- ckzunx currently goes to a lot of trouble to traverse the directory in
  order to expand "*" and "?" in wildcards.  Maybe it should just fork the
  user's customary shell and have it do the expansion.  This would allow
  fancier filespecs to be given, like "~/ck*.[cwh]".  But it would slow down
  features like filename completion and menus in the interactive command
  parser.

- malloc() should be declared "char *malloc()" for systems that have pointers
  and integers of different lengths.

- In zsout() & friends, "fprintf(fp[n], s);" should be "fputs(s, fp[n]);"
  or 'fprintf(fp[n], "%s", s)', to prevent core dumps when s happens to
  contain a '%'.

- In zltor(), dc (dot count) is incremented for all dots in the filespec;
  not good if filespec is something like "../foo.bar".  Reset dc to zero
  whenever a "/" is encountered.

ckxunx.c:

- Many problems reported with "uucp line locking" --
  . On some systems, uucp apparently ignores the lock and breaks in anyway.
  . On some systems, the lock directory is write-protected.
  . On some systems, the lock directory is read-protected.
  . Using dial commands and a login script pointed at a line already in use by
    uucp will hang up the line on uucp.  Cure for this and some other similar
    problems: tty should not be opened before calling ttlock.

  Unfortunately, a lot of code will have to be added to take care of the
  many different ways that sites are set up to handle line contention and
  assignment, probably selectable by makefile compiler switches (see below).

- Under certain conditions, alarms used to timeout blocked reads are not
  cleaned up after a timeout occurs.

- There's no good way to select baud rates higher than 9600.  Most Unix systems
  don't supply symbols for them (unless you use EXTA, EXTB), and even when they
  do, the program has no way of knowing whether a specific port serial
  controller supports those rates.

- 4.2 bsd systems with dialout modems should do ioctl(ttyfd, TIOCCDTR, 0);
  sleep(1); to hang them up upon close.  Other systems that don't have a
  hangup function might need a trick like setting the speed to 0.

- Venix/11 version 1 does have a nondestructive way to inspect a tty input
  buffer after all, so the ttchk() and conchk() functions can be provided
  for Venix to speed up connect mode significantly.

ckdial.c:

- Some systems do not allow users to manipulate dialers directly.
- Not easy to add support for new dialers.
- Some systems never return from the 100-character rawmode read (it is assumed
  return is immediate, indicating how much was obtained from the input buffer).
- Timed read for connect/no carrier message from modem within a general timer
  on the whole operation does not work on some systems.
- Some systems need to have the modem explicitly hung up; close() isn't enough;
  e.g. ioctl(ttyfd,TIOCCDTR,0) on 4.2bsd.
- On some systems, the entire output from the dialer (e.g. "CONNECT") cannot be
  read in a single gulp, so the buffer should be appended to between successive
  reads, not overwritten.

ckus*.c:

- Some help messages still produce core dumps on some systems.  Diagnosis: the
  strings in these messages ('help remote', 'help set' are mentioned most
  frequently) are still too long for some systems.  Cure: shorten them some
  more, and maybe replace

    for (i=0; *s[i]; ++i) fputs(s[i], stdout);
  with
    while (*s[0]) fputs(*s++, stdout);

  in hmsga() to prevent possible references to random memory.  Also, replace
  all printf(msg) with printf("%s", msg);

- The "directory" command produces a full recursive directory listing.  It
  should only list the current directory.  On bsd systems at least, the listing
  can be interrupted with a single ^C, which returns you to C-Kermit> command
  level.  Diagnosis: ???  The program just does a system("ls -l").  Why doesn't
  this behave the same as "ls -l" typed at the shell?

- Parser for the 'get' command doesn't respond well to editing; can go into
  infinite loops under some conditions.

- The filename 'transaction.log' is too long for some systems, and gets
  truncated (no harm is done, but the user is not informed and may not be
  able to find the file).

- The variables ncmd, nprm, nrmt are doubly defined.

ckcmd.c:

- Some systems (such as Venix/11) swallow the erase and kill characters
  when the terminal is in cbreak mode.  If the erase and kill characters are
  are ^U and DEL, then these can't be used to edit C-Kermit interactive
  commands.  Ditto for ^R.  Diagnosis: sigh, let's hear for portability.
  Cure (if you can call it that):  Add new SET commands to allow the
  erase, kill, and redisplay characters to be redefined.

- There's no way to break a command line and continue on the next line.
  Cure: add code to allow "\" followed by CR (or LF, or FF) to accomplish
  this.  Nobody really wants to put a real CR (LF, FF) in the middle of a
  command anyway, right?  This will make take files and login scripts a
  lot more readable.

- No way to put comments in take files.  Cure: Add a ";" or "#" command?
  Trailing comments will be harder.

Protocol (ckprot.w, ckfns*.c):

- No way to interrupt a protocol transaction until after it starts
  successfully.  For instance, no way to interrupt the timeouts and
  retransmissions of the initial packet when the other side is not
  responding, except for killing the whole program.  Cure: check for
  keyboard "interrupts" during the send-init process.

- When receiving from a non-timed-out Kermit and missing the Send-Init
  packet, no NAK is ever sent, and a deadlock occurs.  Diagnosis: resend()
  is called to resend the previous packet; there was no previous packet,
  so it sends an empty line.  Cure: Initialize the packet buffer with a
  NAK for packet 0?

- When parity is in use and the other Kermit cannot do 8th bit prefixing,
  the user is not warned that binary files will not be transferred correctly.

- 'set file names literal' does not work at all.

ckconu.c:

- There have been reports that on some systems (e.g. NCR tower with Sys 5)
  C-Kermit stops listening for the escape character during connect.
  In one case, it was reported that this happened only with IBM mainframes
  with "set flow none".

- Doesn't do any particular kind of terminal emulation.  It wasn't meant to.
  Filters can be used for this.

- Performance is poor on systems that can't check the input buffer.

- As structured, connect mode can't include commands to toggle logging on
  and off or to change settings, because forks can't share variables.

cklogi.c:

- Script facility needs ~d for send-delays, ~x for XON, ~w for wait-for-
  input timeout; these will probably be added.

ckwart.c:

- Has typedef for CHAR as "unsigned short" or "unsigned char".  Cure:
  Have ckwart.c use the typedefs from ckdebu.h, like the regular Kermit
  modules do.

- Should declare malloc "char *malloc()" for systems that have pointers and
  integers of different lengths.

makefile:

- Replace "wart ckprot.w ckprot.c" with "./wart ckprot.w ckprot.c" because
  "." might not be in the current path.

- It was suggested that the compound entry for making ckprot.o should be
  broken into two entries, one for ckprot.o, one for ckprot.c, to prevent
  unecessary recompilations.

- Some of the problems caused by access restrictions on the uucp lockfile
  directory might be addressed by having the makefile check and then setting
  an appropriate compile switch, e.g.

    if [ -w /usr/spool/uucp ]
    then make bsd "... -regular flags"
    else make bsd "... -DNOLOCKING"
    fi

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

End of Info-Kermit Digest
*************************
-------
 4-Apr-85 18:35:51-EST,9641;000000000001
Mail-From: SY.FDC created at  4-Apr-85 18:34:37
Date: Thu 4 Apr 85 18:34:37-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #18
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu,  4 Apr 1985       Volume 2 : Number 18

Departments:

  ANNOUNCEMENTS -
    New Kermit for Honeywell CP6
    New Release of Kermit for Intel ISIS MDS System
    New Release of Apollo/Aegis Pascal Kermit
    Kermit for Sanyo 1100 MBC with CP/M-80 2.2

  MISCELLANY -
    UK Kermit Resposibilities
    Need KERMIT for DG/One
    Unix Questions
    MS-KERMIT 2.26/Multics-KERMIT
    KERMIT on M6800

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

Date: Thu 4 Apr 85 17:05:13-EST
From: Frank da Cruz <[e-mail]>
Subject: New Kermit for Honeywell CP6

Contributed by Cheryl Ann Poostay of Bucknell University, this new Kermit
implementation is based upon the University of Toronto Pascal VMS Kermit,
and provides the basic remote Kermit services.  The files are in
KER:HCP6*.*, available, as usual, via anonymous FTP from host CU20B.

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

Date: Thu 4 Apr 85 17:02:50-EST
From: Frank da Cruz <[e-mail]>
Subject: New Release of Kermit for Intel ISIS MDS System

Submitted by Teresa Koo of Intel in Santa Clara, this releases fixes some
problems in the previous release (for instance, the previous release could
not send files to VMS), and adds some new documentation (the previous
release had none).  The files are in KER:MDS*.* on CU20B.

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

Date: Thu 4 Apr 85 17:06:59-EST
From: Frank da Cruz <[e-mail]>
Subject: New Release of Apollo/Aegis Pascal Kermit

From Steve Case of Control Data, this new release fixes some bugs and adds
a SET FILE_TYPE command to allow transfer of binary files.  The new
version (2.6) replaces the old one (2.3) as KER:APOLLO.* on CU20B.

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

Date: Thu 4 Apr 85 18:06:17-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit for Sanyo 1100 MBC with CP/M-80 2.2

Contributed by Randall Simmons of Southwest Texas State University, this
implementation is based on version 3.6 of CP/M-80 Kermit.  Since the main
Kermit distribution area is very tight on space, the files have been
placed in KE:CPMSYO.* (note, KE:, not KER:) on CU20B.  Perhaps someone who
has a Sanyo 1100 will move this support into the current version of
CP/M-80 "modular" Kermit (version 4.05).

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

Date:     Wed, 3 Apr 85 11:50:32 BST
From:     Chris-on-Fridays <[e-mail]>
Subject:  UK Kermit Resposibilities

Kermiteers:

     A meeting was held in the bar at Sheffield last Monday evening, at
which there were a number of Kermit-interested people present.  We
threshed out some policy about who looks after what.  The effect is:-

1.  Lancaster will look after Kermit sources and try to keep a list of
who-has-what.  They will get new tapes from Columbia about 4 times a year,
and pull in other stuff by ARPA-ftp.  They will keep all this (or as much
as possible) online and available by NIFTP or Kermit.  The "who-has-what"
is really a list of names of those who have running binaries on
transferrable media, and are willing to supply floppies etc.

2.  I will keep a mailing-list here (info-kermit@ucl-cs) of all known
interested parties in UK (and possibly Europe if we have connectivity).
Anybody who wants his/her name added to or deleted from this list, mail me
(cjk@ucl-cs).  Anybody who wants to distribute info to the UK Kermit
fraternity, mail it to info-kermit@ucl and our mailing system will expand
and forward.

3.  I will serve as a relay for info from Columbia which is not new
versions of Kermits. This principally means the information digests.  As
each one comes in I will move it into /44d/kermit/infodig and send a copy
of its contents-header to info-kermit@ucl-cs; you can then extract it
either by NIFTP or by Kermit.

     In line with this, I am removing the majority of the source texts
from the /44d/kermit directory.  They are in any case now about a year
old.  I will try to hold as much text information online as possible.

     If anyone has trouble importing the larger documents, let me know.  I
could split them up into chapters.

                                        Chris K.

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

Date:  Wed, 3 Apr 85 08:55 EST
From:  [e-mail]
Subject:  Need KERMIT for DG/One
To:  [e-mail]

We have need for a KERMIT for our new Data General/One portable.  These
are IBM clones with the exception of the communications UART.  In an
effort to keep power consumption to a minimum, DG opted for an 82C51
UART instead of the 8250 the IBM uses.  This precludes the DG/One from
using IBM communi- cations software.

If necessary, I can provide a driver routine (in 8086 assembler) from
the DG/One programmers manual which details the command structure for
the 82C51 as well as the DG/One power management scheme.

Thanx for your help!

Wolf Wiedemann RADC-MULTICS

[Ed. - Many have expressed interest, but no one has offered the driver
routine before.]

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

Date: Wed 3 Apr 85 16:18:25-EST
From: Frank da Cruz <[e-mail]>
Subject: Unix Questions

A couple possible solutions for C-Kermit problems:

1. Recursive directory listings produced by "directory" command, or by
server when given "remote directory" with no argument or "*" -- use "ls
-ld" rather than "ls -l".  I checked in 4.2bsd, ATT System V, and Venix
manuals, and all support "ls -ld".  Are there any Unix systems that don't?

2. It is considered desirable to use the user's shell for any system
commands, or executing "!" commands.  Can this be done in all versions of
Unix by making a string of the form "$SHELL -c " concatenated with the
desired command, and then feeding it to system()?  Not elegent, but then
neither is fork/pipe creation/deletion.

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

Date:  Wed, 3 Apr 85 18:53 EST
From:  "John C. Klensin" <[e-mail]>
Subject:  MS-KERMIT 2.26/Multics-KERMIT

Well, MS-KERMIT works, but you have probably gotten into the midst of
the Multics kermit mess.  Without reciting the history and boring
everyone else, there are four known versions of Multics kermit on the
MIT Multics machine, none completely satisfactory.  They are, in no
particular order:

   Oakland version I, as modified by MIT (the one you find if you don't
do anything special).  This version does not do binary transfers
correctly, and sometimes randomly decides that it is in eighth-bit
quoting mode, resulting in some arbitrary character being consistently
garbled.  This version understands something about Multics text files,
and translates names to lower case, and so forth.  The MIT
modifications, in addition to the text handling, include making the
thing work satisfactorily with the X.25 PDNs.

   A further modification of Oakland version I, with the 8th bit bug
fixed and some additional code to properly canonicalize text to Multics
standards.

   Oakland version II, which is believed to have a few of the same
problems for MIT use as version I, including difficulties with the X.25
PDNs and mode-setting problems for some other devices.  It also lacks
the extensive transaction-tracing facilities that were added to the
versions above in the process of getting them working.  This version is,
we believe, the version that exists as the official Multics kermit at
Honeywell.

   Calgary/Honeywell "official" kermit prerelease.  This version, which,
unlike the others, has a user interface consistent with other Multics
subsystems and quite similar to the ARPANET user ftp program on Multics,
is the precursor of what will eventually be released.  It does not have
the special text canonicalizing features of the first and second
versions listed above and is arguably not too bright about the handling
of names.  It does binary downloads correctly ONLY in seven-bit mode,
with eighth-bit quoting on; it will not do them when told to use an
eight-bit data path.  This bug is claimed to be fixed in the official
release, which will certainly get here someday.

At MIT, we are ignoring Oakland II, and have stopped work on the MIT
modifications to Oakland I (we have not even bothered to install the
second version mentioned above).  We are concentrating our efforts on
trying to find problems and suggest fixes to Calgary/Honeywell Multics
kermit, which seems to work if you are careful.

If you have further problems, or cannot figure out which version here is
which, the IS Microcomputer Center has official responsibility for
kermit on MIT-Multics and you may want to contact them.

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

Date: 23 March 1985, 20:32:28 MEZ
From: Bernhard Nebel            +49/30/314-5494      NEBEL    at DB0TUI11
      TU-Berlin
      Sekr. FR 5-8
      Franklinstr. 28/29
      D-1000 Berlin 10
Subject: KERMIT on M6800

Dear Daphne,
I've written a KERMIT for a M6800 running under MDOS (a operating
system written by myself), which is similar to MINIFLEX V1.0 (Technical
Systems Consultant). But anyway, it should be possible to rewrite
the operating system interface. Are you interested to receive the
KERMIT?

- Bernhard

[Ed. - Anyone interested?  Send him mail.]

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

End of Info-Kermit Digest
*************************
-------
 9-Apr-85 20:11:08-EST,13772;000000000000
Mail-From: SY.FDC created at  9-Apr-85 20:10:25
Date: Tue 9 Apr 85 20:10:25-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest, V2 #19
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue,  9 Apr 1985       Volume 2 : Number 19

Departments:

  ANNOUNCEMENTS -
    ANSI Tape Program for Prime Computers
    Commodore-64 Boostrap Program in SIMULA

  IBM MAINFRAME KERMIT -
    CMS Kermit and Linemode
    EBCDIC, ASCII, and All That
    ASCII in Kermit Docs
    Re: EBCDIC, ASCII, and All That

  MISCELLANY -
    Text vs Binary Files in Kermit
    Another CP-6 Kermit on the Way
    B6900 Version of Kermit Using NDL2?

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

Date: 9 Apr 1985 1829-EST
From: LSM.DUNCAN at DEC-MARLBORO
Subject: ANSI Tape Program for Prime Computers

  Attached is a program written in Fortran-66 which will read variable
record length ANSI (Format D) tapes on a Prime computer.  Since Fortran-66
is provided with all Prime machines, all Prime customers should be able to
compile and run it.

  I have only briefly tested it, but it appears to work as advertised.
Much thanks should go to the Prime New York office.  Ron Couch, a senior
analyst there wrote it, and Dave Tichane provided me with a copy to send
to you.

  In order to help you out, I am willing to send a (paper) listing of it
to anyone who needs it.  Please send a request to LSM.DUNCAN at
DEC-MARLBORO, Prime X.MAIL DUNCAN -ON EN.C6, or U.S. mail to:

    Jeff Duncan
    Prime Computer Inc.
    492 Old Connecticut Path  MS 21-02
    Framingham, Ma. 01701

  I hope this new program will help out the many Prime people who have had
difficulty with your tapes.

  Jeff

[Ed. - Many, many thanks to Jeff, Ron, and Dave.  Prime computer sites
have had a terrible time reading the ANSI tapes we sent them up till now.
The program is in KER:PRIMET.FTN, available via anonymous FTP from CU20B.]

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

Date:        08 Apr 85 14:19 +0100
From:        [e-mail]
Subject:     Subject: Commdore-64 Boostrap program in SIMULA

Here is a version of the C64BOOT program written in SIMULA for DEC-10/20
computers. I have commented this version a little more than previous
versions of C64BOOT in other languages, to make it simpler for someone who
needs to re-write it into yet another language.

Note two important points: ALL echoing of characters from the CBM by the
HOST must be suppressed. Also the echoing of a line feed when the CBM
sends a carriage return.

The delimiter between lines sent to the CBM-64 should be only carriage
return, not carriage return-line feed.

[Ed. - Thanks, Jacob!  The program is in KER:C64BOOT.SIM, available
via anonymous FTP.]

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

Date: Fri, 5 Apr 85 10:11:03 est
From: KRAMER <[e-mail]>
Subject: CMS Kermit and Linemode

Has anyone tried to get the VM/CMS Kermit working using the LINEMODE
patches from Queens Univ with a YALE ASCII/Series 1 front end (or an
IBM4994)?  Better yet, does anyone have KERMIT working useing the
Transparent mode options with the YALE Ascii package?

[Ed. - The soon-to-be-released version 2.00 of VM/CMS Kermit will include
the ability to operate transparently through the Series/1 front end with
the Yale ASCII package.  The U of Chicago's MVS/TSO Kermit was modified at
the U of Toronto to do the same thing, but the Toronto version ONLY works
through the Series/1-Yale front end; it's in KER:TSOS1.*.]

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

Date: Thursday, April 4, 1985 at 9:36 PM EST
From:   Norman Ramsey <[e-mail]>
Subject: EBCDIC, ASCII, and all that

I am at my wits' end trying to cope with CMS, CMS-KERMIT, and the godawful
problem of ASCII/EBCDIC translation. I am working with two sites, CORNELLA
and MITVMA, that use DIFFERENT translation tables. I believe that BOTH
tables are noninvertable, and I am ready to flog the engineer who designed
EBCDIC.

All this notwithstanding, I would be happy (nay, ecstatic), if I could
somehow just send the RAW BITS from an ASCII machine (such as my IBM PC)
and an IBM mainframe. I would be happy with seven bits. I would be happy
with eight bits.  I'm beginning to think the best I can hope for is six
bits, and that only be encoding everything as alphanumeric, comma, period,
blank, and such characters as we hope will always be translated *RELIABLY*
independently of the vagaries of the various sites.

Such as, f'rinstance: my site (CORNELLA) translates an ASCII backslash
into an EBCDIC cent sign (hex 4A) and back again. Too bad no other site
seems to do that. But you don't want to hear this...

                                            Norman Ramsey
                                            [e-mail]

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

Date: 04/09/85 17:39:11 EDT
From: TS0013@OHSTVMA
Subject: ASCII in Kermit docs

I am curious about which version of ASCII is really the one on which
Kermit is based.  The KERMIT PROTOCOL MANUAL says that The 1968 version of
ASCII, X3.4, is used.  Appendix V of the same manual shows X3.4-1977.  The
major point I am aware of in the 1977 version is that the broken or
"split" vertical bar has been "fixed" back to a solid vertical bar.  The
name for it is now just "vertical bar".

Locally on our IBM systems, we have a homegrown standard for the
translation of ASCII to EBCDIC and EBCDIC to ASCII.  This local standard
is based on the fact that early development and standard- ization of PL/1
insisted on using the exclamation point, stylized like a vertical bar, for
logical OR.  A compromise was reached at some point making the code for
exclamation to be either a solid vertical bar or an exclamation.  I still
see documents around that describe this mess.  I think this was
implemented in 1968.  In 1977 ANSI decided to fix the mess and make the
broken vertical bar into a solid one, and the exclamation was to be only
that.  What resulted here was that the translations still change the CODE
for character number (octal)21 into a vertical bar in EBCDIC.

This has led to much confusion around here.  The management here was only
recently aware that there were even any such changes in ANSI.  I guess
they will learn that "standards never are".

What I am curious of is just what standard is Kermit based on.  Is it
using some specific standard, or perhaps trying to track a moving target
(ASCII) ?

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

Date: Fri 5 Apr 85 10:49:27-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Re: EBCDIC, ASCII, and all that

My sympathies to all.  ASCII/EBCDIC translation will always plague us.
Those who are interested in the sordid history -- and there's a lot of it
-- are referred to the book "Coded Character Sets, History and
Development" by C.E. Mackenzie, Addison-Wesley (1980).  There are two
"standards" for translation between ASCII and EBCDIC:

[CACM] "Correspondences of 8-Bit and Hollerith Codes for Computer
  Environments -- A USASI Tutorial", a working paper of the ANSI X3
  Committee, published in CACM, vol.11, no.11, pp.783-789 (Nov. 1968)

[IBM] "System/370 Reference Summary", GX20-1850-5, IBM Corporation,
  6th ed. (1984) (earlier editions presumably have the same table)

The former more closely approximates a formal standard since it comes from
the appropriate ANSI committee, but the latter is used more commonly in
practice, since it is promulgated by the major manufacturer of equipment
for which ASCII/EBCDIC translation is necessary.  To complicate matters,
both ASCII and EBCDIC went through many fundamental changes over the
years; EBCDIC went through a long evolution from Hollerith and BCD to its
present state, and there have been at least four distinct ASCII alphabets:
those of 1963 (no lower case letters), 1965 (lower case letters added,
some new graphics added, others switched around), 1967 (ANSI X3.4-1968:
several graphics moved and/or redefined), and the current 1977 version
(X3.4-1977: vertical bar plugged).  Many translation tables are relics
from these early days of rapid change; they were correct (i.e. useful) in
the context in which they were created but now cause problems, most
commonly with the following characters:

            ASCII   CACM    IBM
  ASCII     value  EBCDIC  EBCDIC
 graphic   decimal   Hex    Hex   Comments

    !        33      4F      5A   4F in IBM is a solid vertical bar
    [        91      4A      AD   4A in IBM is a cent sign
    ]        93      5A      BD   5A in IBM is an exlamation mark
    ^        94      5F      5F   Listed in IBM as a "not sign"
    |       124      6A      4F   IBM has 3 vertical bars -- 4F, 6A, and FA

The Kermit translate table corresponds to the IBM table (with either 1968
or 1977 ASCII) and works at most sites.  Unfortunately, this is not to say
that sites at which it does not work are using the CACM table; many sites
have reported problems with the translation of characters where IBM and
CACM agree, including curly braces "{}", backslash "\", and tilde "~".  It
seems to be a relatively common practice for sites to "customize" their
translate tables, for reasons such as those mentioned above.

The IBM (and hence the Kermit) table is invertible, provided one sticks to
using only the EBCDIC 4F vertical bar, which is solid in EBCDIC and 1977
ASCII, and broken in 1968 ASCII (and on most current ASCII terminals and
printers).

The only way to get IBM systems (VM/CMS systems, anyway) to allow raw data
in and out a TTY line is to modify VM by adding the null translation table
along with an appropriate CP command to invoke it.  It does not
necessarily do any good to preprocess your data (e.g. hexify it), because
Kermit packets contain not only data, but also control fields which may
contain any printable ASCII character.

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

DATE: TUESDAY, 9 APRIL 1985
FROM: BRIAN AT UOFT02
SUBJECT: Text vs Binary Files in Kermit

A proposal to assist in Kermit binary file transfers.

A  common  problem  in Kermit file transfers is that of having to switch
between 'bin' (or 'fixed') modes and 'text' modes. While  some  Kermits,
such  as the MS/PC DOS and Kermit-11/RT11 versions don't care what about
this (RT makes no distinction), Kermit-11, Kermit-20 and  Kermit-32  do.
This  problem  becomes  acute when one sets up a BB for downloading text
and exe (tsk,sav,...) files to micros. We need a means to  automate  the
switching  from  text  mode  to image mode. Kermit-11 currently uses two
methods to do this, one, if the file is not sequential implied  CR  then
Kermit-11  sets  itself  to  'binary'  mode,  ie,  it uses RMS-11 direct
access macros to read the file. Also, it will check the filetype to  see
if  a match occurs, and if so, sets itself to binary mode for that file.
This is done since RSTS/E and RT can have  files  that  ARE  binary  but
have no ufd data to say so.

Additionally,  if  Kermit-11  finds that a file is 'binary' it will tell
the other Kermit (if it said it can  handle  attributes  via  the  CAPAS
field)  such.  Also,  if  Kermit-11  finds  itself  talking  to  another
Kermit-11 it will (for RSTS/E and RSX and P/OS) send a copy of the  file
header (the RMS-11 IFAB).

Now, for the problem.

We need a consistant means of setting 'binary' xfer mode.  Kermit-11 has
in it a hardwired list of filetypes that shoud be  sent  'binary'.  This
is  ok most  of  the  time,  exceptions do occur.  Like a .COM file is a
command procedure under VMS and RSTS V9 (which I am field  testing)  but
under CPM it is quite another thing.

The proposal is this:

The  Kermit  program  should  look  for  a  file that contains a list of
filetypes that the system manager considers to be  'binary'.  If  found,
switch  to image mode. Also, we should think about attribute packets, at
least in so far as 'I' format file.

                                                brian nelson
                                                [e-mail]

[Ed. - Brian's note points out a fundamental problem with Kermit, and in
fact with any file transfer mechanism, especially between unlike systems.
Brian's scheme would help a lot, but it would have to be combined with
all sorts of other heuristics, different on each system, to behave as
desired.  For instance, to tell the difference between a VMS .COM file
(a textual command file) and a CP/M .COM file (an 8-bit binary file), one
would have to examine the data itself.]

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

Subject: Another CP-6 Kermit on the Way
Date: 04 Apr 85 20:19:50 PST (Thu)
From: Mike Iglesias <iglesias@uci-icsa>

Lee Hallin at Honeywell LADC (in Los Angeles) has also got a KERMIT for
Honeywell CP-6 systems.  His has SERVER mode, some fancy debugging
features, etc.  It's not completely done yet.  He's planning on submitting
it to the KERMIT distribution when it's done.  We've been testing it for
him for about 3 weeks.  Just thought you'd like to know.

Mike Iglesias
University of California, Irvine

[Ed. - When it rains, it pours...]

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

Date: 5 Apr 1985 12:32-PST
Subject: B6900 Version of Kermit Using NDL2?
From: Geoffrey C. Mulligan <GEOFFM@SRI-CSL>

We have a B6900 running NDL2 and I am interested in getting Kermit
running.  Has anyone written a version of Kermit using NDL2?

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

End of Info-Kermit Digest
*************************
-------
17-Apr-85 10:40:34-EST,10107;000000000000
Mail-From: SY.FDC created at 17-Apr-85 10:40:05
Date: Wed 17 Apr 85 10:40:05-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #20
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Wed, 17 Apr 1985       Volume 2 : Number 20

Departments:

  ANNOUNCEMENTS -
    New Macintosh Kermit on the Way
    Kermit for GUTS

  MISCELLANY -
    Changes to DEC-20 Kermit for TVT's, TAC's under Panda Monitor
    More Comments on Binary Files
    PCjr Peculiaries
    Kermit for GE Timesharing?
    CPM3 Generic Kermit on Osborne Executive?

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

Date: Tue 16 Apr 85 12:17:35-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: New Macintosh Kermit on the Way
To: Info-Kermit@CU20B, Info-Mac@SUMEX-AIM

Just to forestall any parallel development, this is to announce that
Columbia University is about to release a new Macintosh Kermit.  The
program is written in C using the SUMACC Unix-based cross development
tools, and is based on the new C-Kermit protocol modules.  It includes
VT102 terminal emulation with line and character insertion and deletion.
The terminal emulator and file transfer functions are done; the rest of
the user interface (dialog, display, and control windows) is being done
now.  We expect to announce an initial release within several weeks.

Columbia's Macintosh Kermit will be distributed on Columbia's Kermit
distribution tapes and via computer network, like other Kermit programs.
We recognize that Macintosh Kermit will be difficult to bootstrap,
especially at sites that do not have the SUMACC tools, so we would like to
place a few diskettes at sites where they will be most widely reproduced
and circulated, such as the member schools of the Apple University
Consortium.  Any other suggestions?  Unfortunately, Columbia simply does
not have the resources to get into the diskette production business, so
we are looking for sites that are willing to act as distribution centers.

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

Date: Wed 10 Apr 85 18:00:44-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit for GUTS

This is to announce an implementation of Kermit for IBM mainframes running
GUTS (the Gothenburg Universities' Terminal System), a TSO-like timesharing
system installed at about 80 sites in Europe, Africa, and the USA.  It was
adapted by Stefan Lundberg of the Gothenburg Universities' Computing
Centre, Gothenburg, Sweden (STEFAN_LUNDBERG_GD%QZCOM@MIT-MULTICS) from the
University of Chicago's MVS/TSO Kermit, which was in turn adapted from
Columbia's VM/CMS version.

The files are available via anonymous FTP from CU20B as KE:GUTS.*.  Note,
KE:, not KER:.  Unfortunately, we are no longer able to fit all the Kermit
implementations in one place, or on one tape.  At some point in the coming
months, the Kermit distribution will have to be split in two with one
area (and one tape) containing the more popular versions, the other the
more esoteric.

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

Date: 10 Apr 1985  22:17 MST (Wed)
From: "Frank J. Wancho" <[e-mail]>
Subject: Changes to DEC-20 Kermit for TVT's, TAC's under Panda Monitor

Frank,

The following are the changes I made to 20KERMIT.MAC.255 to add
support for a MONITR that doubles IACs and has new MTOPR% calls to
negotiate network binary mode.  Such support is in MRC's PANDA MONITR
which we are running now, and the MTOPR% codes are of MRC's making,
not yet DEC's.  I have made similar changes in MODEM available in the
usual place here (MICRO:<CPM.TOPS-20>).

--Frank

[Ed. - Thanks, Frank.  Rather than incorporating these changes into the
base version, I've left them in KER:20KERMIT.BWR on CU20B.  When and if
DEC ever makes up its mind how to handle this problem, Kermit-20 will be
changed to accommodate.]

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

DATE: 10-APR-1985
FROM: BRIAN AT UOFT02
TO: SY.FDC AT CU20B
SUBJECT: More Comments on Binary Files

I agree that filetype confusion will occur, thus the suggestion  that  a
system  and  user  INI file could define those types. The reason I would
like to see this is for a proposal here to archive  msdos  libraries  on
the  785  (amounting  to  several  tens of thousands of blocks) so users
could download things as they need them from the vax. The use of a  user
ini  file  with  filetype info for binary files would be able to set bin
mode for, say .COM files, only for that user.  While  it  clear  that  I
should  be able to set the attributes on the VAX side of the msdos files
and all should work right, that in itself could still be a mess.

The reason I implented  switching  to  binary  mode  via  filetype  (and
attributes)  in  the  first place was because the rt11 file system knows
nothing of attributes. Additionally, RSTS/E Basic+ 'compiled' files  are
stored  w/o  attributes,  though,  of course, RSTS/E supports the entire
FSC/RMS file structure when desired or needed. I did include a SET  FILE
NOAUTO command to disable checking for binary file transmission.

It  would  be  really  nice  if  Kermit-32  and  MSDOS  Kermits  support
attribute packets in at least the "I,"B and "A packets so the  recipient
could  decide  what action to take. I do this on Kermit-11 and it really
makes loading my PRO/350 from  my  23+  easy.  As  an  example,  William
Youngs  of  DEC/LDP  has  a  bulletin  board  on  a  730 where he places
scientific and eng software, his users that dial in  find  it  confusing
to be switching modes to get a .SAV image vs a .MAC or whatever.

One last note  (about VMS Kermit).   One problem that  comes up is  with
binary files that are fixed 512  with carriage control. These files  are
typically sav and task images loaded  onto the VAX via FLX or  EXCHANGE.
It would seem that the only (simple) way to be able to Kermit them is by
using CONVERT  on them  to remove  the 'carriage  control' attribute  to
none. I don't really care, but it may account for problems I have  heard
about from others running Kermit-32.

                                                brian nelson

[Ed. - Of course, what's needed -- and what we'll never get -- is a
"standard" for determining file attributes in a heterogeneous environment.
File types are one way, but Brian's own classic example -- VMS .COM files
(textual) vs CP/M .COM files (binary) -- points out the pitfalls of this
approach if used in isolation.  Another prominent example is TOPS-10/20
.EXE files (36-bit binary) vs MS/PC-DOS .EXE files (8-bit binary).
However, extending the file-type idea a bit might do the trick: a list
of file types and corresponding attributes such as Brian suggests could be
kept on a per-site basis, along with private lists for individual users,
but in addition a particular file could be stored along with a parallel
file having a special file type, say .KFA (Kermit File Attributes), which
would contain attribute information -- perhaps formatted according to the
Kermit Attribute Packet description in the Kermit Protocol Manual.  If
such a file were present, Kermit would use the specified attributes; if
absent, Kermit would use attributes from the user's or site's type list.
The obvious measures would also be necessary to allow a user to override
all of this on a per-file or per-file-type basis.  Specification and
coding of all this would be quite a job, but perhaps trivial compared with
explaining it to users...]

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

From: Paul Fishwick <[e-mail]>
Subject: PCjr Peculiaries
Date: Wed, 10 Apr 85 21:02 EST

I called you the other day asking a question or two about the
peculiarities of the PCjr with respect to my emulator.  After "carefully"
reading the Junior Doc. which someone sent me, it is quite clear why
Kermit works fine and mine did not: Page 2-126 tells all: "Without the
Internal Modem installed, the RS232 serial port is logically addressed as
COM1 in BIOS,DOS, and BASIC even though its address is still hex 2f8 using
interrupt level 3."

No wonder they canned the machine.  Personally, my design philosophy is to
use BIOS whenever possible then digress to lower depths if someone
specifies mark,space parity and for general interrupt handling - this is
what got me!

-paul

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

Date: Thursday, 11 Apr 85 09:37:53 PST
From: vax135!cornell!uw-beaver!tektronix!iddic!dhs@Berkeley
Subject: Kermit for GE Timesharing?

I'm looking for anyone who knows if a Kermit is running on GE
timesharing.  Apparently they use some sort of Honeywell processors with
a proprietary, non-standard operating system.  I would like to use
Kermit to upload messages for a Bulletin Board system I'm setting up.
My intuition is that somebody, somewhere has a Kermit running.  I made
the suggestion to GE, and they suggested that they are looking into what
it would take to make a Kermit available.

Thanks in advance,

Dave Straayer

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

Date:  Fri, 12 Apr 85 10:33 EST
From:  "Paul E. Woodie" <[e-mail]>
Subject:  CPM3 Generic Kermit on Osborne Executive?
To:  [e-mail]

I have gotten a copy of CPM3 generic kermit and am trying to use it on
my Osborne Executive through Telenet to a Multics machine.  I am having
trouble getting it to work at all -- it will send the first character I
type after I go into Connect mode and then die.  Is anyone using generic
cpm3 kermit sucessfully at 1200 baud on the Osborne Executive?  If there
is someone, or if you would like to share "war stories" with me, please
respond to me directly at MIT-Multics.  If the results of this episode
are successful an there is something useful resulting from this, I will
be happy to post it to Info-Kermit.

Thanks in advance,

Paul Woodie (Woodie.DODCSC at MIT-Multics)

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

End of Info-Kermit Digest
*************************
-------
25-Apr-85 16:38:05-EST,10330;000000000001
Mail-From: SY.FDC created at 25-Apr-85 16:36:48
Date: Thu 25 Apr 85 16:36:48-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #21
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu, 25 Apr 1985       Volume 2 : Number 21

Departments:

  ANNOUNCEMENTS -
    New Macintosh Kermit Prerelease Available for Testing
    VMS Kermit 3.1.066 Available
    Kermit-11 BITnet Server Available

  MISCELLANY -
    S-1 Mark IIA Kermit
    Commodore-64 KERMIT - a problem
    Kermit for Royal Alphatronic PC?
    Apple II Kermit Support for CCS7710 Serial Card?
    Looking for Kermit for GOULD

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

Date: Thu 25 Apr 85 14:27:09-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: New Macintosh Kermit Prerelease Available for Testing
To: Info-Kermit@CU20B, Info-Mac@SUMEX-AIM

This is to announce a pre-release version of Columbia Macintosh Kermit.  This
program is equivalent to the new C-Kermit in its capabilities, implementing the
full range of encoding, compression, and block check options, and includes a
fairly complete VT102 terminal emulator and a Macintosh-style user interface.

The program is based on C-Kermit, and shares the same C language source for the
protocol-related modules (but the version of these protocol modules is later
than the currently released version of Unix Kermit).  Macintosh Kermit is
presently built using the SUMACC Unix-based cross development environment; a
future release might also allow it to be built using a Macintosh-resident C
language development system.

This pre-release is intended primarily for evaluation at sites familiar with
Kermit.  We are soliciting helpful and constructive comments, suggestions, and
detailed, specific bug reports.  There are some features we haven't put in, but
MAY add in later releases; these are listed just so that everyone won't feel
compelled to suggest them:

. A manual (currently only short help and beware files are included)
. Key mapping, including redefinition/relocation of control and meta keys
. Somewhat more intelligence about Macintosh file attributes & structure
. XON/XOFF
. Server operation (Macintosh acts as server)
. Screen save/rollback (maybe)

The program is currently about as big as a program can get on a 128K Mac (the
SUMACC system does not provide dynamic segment loading).  Some of the missing
features, particularly screen save/rollback and key mapping, could put it over
the edge.

The files are available for anonymous FTP from CU20B as <MACKERMIT>*.*.  The
file CKAAAA.HLP tells what the files are.  The file CKMKER.HLP contains user
documentation (just a little) and installation instructions (most people will
want to simply download the binhex'd MacKermit resource), and CKMKER.BWR lists
the known bugs and limitations.

This prerelease is not really intended for wide distribution.  It is mainly to
get what we've done so far into the hands of those on the net who will be
able to make useful contributions (in the form of bug reports, criticisms, and
suggestions) which will be filtered into the first "real" release of MacKermit
for general consumption.  Please send all such reports to Info-Kermit@CU20B.

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

Date:     Monday, 22 Apr 85 21:17:41 EST
From:     nbush (Nicholas Bush) @ sitvxb.ccnet
Subject:  VMS Kermit 3.1.066 Available

I have finally put together a copy of VMS Kermit which should be suitable
for release.  This fixes all the bugs I know of (unless I forgot some minor
ones) as well as adding a couple of new features.  Here is a summary
of the changes (also found in VMSV31AN.RNO/MEM):

There have been  a  number  of  new  features  and  fixes  to  VAX/VMS
Kermit-32 3.1.065.

     1.  Send packet buffer size was increased to  allow  for  maximum
         size Kermit packets.  It was previously 4 bytes too short.

     2.  When sending FORTRAN carriage control  files,  if  the  first
         character  is not a valid carriage control character, it will
         be passed along instead of thrown out.

     3.  CONNECT no longer fails in strange ways on DECnet terminals.

     4.  Two (or more) RECEIVE commands in a row now work.

     5.  Kermit-32 now has a TAKE command (also "@").  Kermit-32  also
         performs  an automatic TAKE of VMSKERMIT.INI or whatever file
         is pointed to by the logical name VMSKERMIT.

     6.  LOCAL and REMOTE commands which spawn a subprocess  now  work
         correctly under VMS 4.x.

     7.  Terminal names longer than 7 characters now work  (VTAnnnnn).
         The  limit  for a physical terminal name is now 16 characters
         (I hope DEC doesn't up it anymore).

     8.  VMS 4.x added more bits  to  the  field  where  the  terminal
         parity was.  Ensure we only change the parity.

     9.  STATUS command had the headers  backwards.   Fix  headers  to
         correspond to data values being output.

    10.  SET IBM_MODE now  simply  sets  the  individual  items.   The
         values for IBM mode can be specified at link time by defining
         the global symbols:

         1.  IBM_MODE_CHARACTER  =  character   value   of   handshake
             character

         2.  IBM_MODE_ECHO = 1 for local echo, 2 for no local echo

         3.  IBM_MODE_PARITY = (0 = none), (1 = mark), (2 = even),  (3
             = odd), (4 = space).

         If not specified, Kermit will continue to use DC1, local echo
         and odd parity for IBM_MODE.

    11.  Kermit-32 now has a SET HANDSHAKE  nnn  command  to  set  the
         handshaking  character.   This  is  any  octal  value  or the
         keyword NONE to turn off handshaking.

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

Date: 24 APR 85 10:58-EST
From:  [e-mail]
Subject: Kermit-11 BITnet Server Available

There is a BITNET Kermit server running on node UOFT02 with username
of KERMSRV. This is intended to facilitate transfer of fixes or mods
to Kermit-11 over Bitnet. It is a very simple-minded server, all  it
can do is return file(s) and directory listings. The system is a VAX
11/785 running VMS 4.1 with jnet.  All file naming  conventions must
follow VMS rules, as in:

VMS requestor:  $ SEN/REM UOFT02 KERMSRV SEND K11CMD.MAC
CMS requestor:  CP SMSG RSCS MSG UOFT02 KERMSRV SEND K11CMD.MAC

Wildcarding is available. No directory names or logical names can be
present in the filename.  No binary files (.sav and .tsk) files  are
available via bitnet.

As always, the Kermit-11 edit history is in K11CMD.MAC.


                                                [e-mail]

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

Date: Wed, 17 Apr 85 19:36:02 pst
From: John Bruner <[e-mail]>
Subject: S-1 Mark IIA Kermit

Here at the S-1 Project at Lawrence Livermore National Laboratory
we are doing supercomputer research.  We have completed our
current generation machine, the S-1 Mark IIA and we recently
brought up multiuser UNIX on it.

The S-1 talks to the outside world through attached I/O processors.
At the present time there are no network connections and we haven't
finished debugging the magnetic tape.  We were forced to use a very
contorted path to transfer files to the S-1 from our VAXes.

Recently, however, we were successful in bringing up a very
simple KERMIT on a serial line.  Now we transfer source files in
and out via a 9600 baud link to our VAX.

The S-1 Mark IIA is probably the largest machine so far to run
KERMIT, and almost certainly is the largest machine which depends
upon KERMIT for access to the outside world.  (The S-1 Mark IIA
has an 80ns cycle time, a very complex instruction set, and
128 megabytes of main memory.)

The availability of KERMIT made life much nicer for us as we
finished our UNIX port.  While I anticipate that UUCP will supplant
KERMIT, I wanted you to know how much we appreciated having it.
(Besides, I thought you might find it amusing that such a large
machine benefitted greatly from it.)

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

Date: 21 Apr 85 14:48 +0100
From: [e-mail]
Subject: Commodore-64 KERMIT - a problem

I have been testing Commodore-64 KERMIT version 1.3 with mixed
success. Two problems ocurred:

(a) 1200 baud did not work for file transfer (but worked OK in
CONNECT mode).

(b) After having started Commodore-64 KERMIT, the SEND command
did not work. If however, I first made a GET command, then
SEND did work after that.

My test were made against a computer with CP/M-86 KERMIT.

[Ed. - Your message has been relayed to the author, who is working on a
 new release of the program.]

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

From: pur-ee!pur-phy!duncan!mike@Berkeley
Date: Thu Apr 18 15:44:19 1985
Subject: Kermit for Royal Alphatronic PC?

Does anyone know where I could get a copy of Kermit for the Royal PC?
I would really appreciate any info.
                    Mike

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

Date: 22 Apr 1985 10:08:22 EST (Monday)
From: John Shaver STEEP-TM-AC 879-7602 <jshaver@apg-3>
Subject: Apple II Kermit Support for CCS7710 Serial Card?

Is there a Kermit for the Apple CCS7710 serial card?  If not is there
an assembly source for another similar source which might be adapted?

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

Date: Mon 22 Apr 85 17:16:14-EST
From: Peter G. Trei <[e-mail]>
Subject: Re: Apple II Kermit Support for CCS7710 Serial Card?

The CCS7710 card should be supported in the next release, which is getting
near. We hope to add a number of cards in this one.
                                peter

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

Date: Mon, 22 Apr 85 14:40:50 EST
From: Pamela J. Saia <[e-mail]>
Subject: Looking for Kermit for GOULD

    I am looking for KERMIT which runs on a
    GOULD Concept 32/27 computer  operating
    system:mpx  rev 3.2A

    Prefer Fortran 77 but any information would
    be appreciated.

    Please respond to this address or call
    Gary Gustafson at [phone]  (Hanscom Airbase)


    Thank you

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

End of Info-Kermit Digest
*************************
-------
30-Apr-85 17:05:53-EDT,16209;000000000000
Mail-From: SY.FDC created at 30-Apr-85 17:04:48
Date: Tue 30 Apr 85 17:04:48-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #22
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue, 30 Apr 1985       Volume 2 : Number 22

Departments:

  ANNOUNCEMENTS -
    Second Pre-Release of Columbia Macintosh Kermit
    Kermit for the Burroughs B7900
    Minimum files for running VMS Kermit 3.1

  MACINTOSH KERMIT PRERELEASE #1 FEEDBACK -
    .HQX file for new Mac Kermit
    Clarification on version #'s
    Comments on MacKermit Prerelease
    MacKermit Bug Report
    Problem and question re Mackermit

  MISCELLANY -
    Rainbow 100+ Kermit-MS vs MS-DOS 2.11?
    Kermit for Grid Compass?

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

Date: Tue 30 Apr 85 15:37:44-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Second Pre-Release of Columbia Macintosh Kermit
To: Info-Kermit@CU20B, Info-Mac@SUMEX-AIM

This is to announce the second pre-release of Columbia Macintosh Kermit,
version 0.6(4).  It fixes a few problems with the first pre-release that
were reported to Info-Kermit.  These are discussed in detail in the messages
below, but briefly they are:

. Version number incorrect -- 0.5(0) should have been 0.6(1)
. Bare CR's rather than CRLF's in .HQX file
. Saved settings files not correctly closed in all cases
. Transferred files not correctly closed in all cases
. Can't get back to Switcher using Apple menu
. Outgoing filenames not converted to uppercase
. Certain limitations and features not documented

The files are available via anonymous FTP from CU20B as <MACKERMIT>*.*,
and replace the earlier files in the same area.  These are the new or
changed files:

 CKAAAA.HLP    List of files
 CKMFIO.C      Macintosh file i/o
 CKMKER.BLD    (new) Instructions for building
 CKMKER.BWR    Beware file -- list of bugs, edit history
 CKMKER.HQX    Binhex'd MacKermit resource file
 CKMKER.MAK    Makefile
 CKMKER.RC     Resource Compiler input
 CKMKER.RSRC   MacKermit resource (8-bit binary)
 CKMSAV.C      Settings Saver
 CKMSUM.C      (new) SUMACC fiddling
 CKMUSR.C      User Interface
 CKMUTL.C      Utilities

The first "real" release of this program will coincide with the next
release of Unix C-Kermit, upon which it is based.  This will probably be a
few weeks hence, so in the meantime, keep sending comments and suggestions
to Info-Kermit@CU20B.

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

Date: Tue, 23 Apr 85 09:36:02 EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit for the Burroughs B7900

This is to announce a new Kermit implementation written in Algol for the
Burroughs B7900 computer, contributed by Drs. B.J.M. Morselt, Technische
Hogeschool Eindhoven, Netherlands.  The files are in KER:B79*.*, available
via anonymous FTP from CU20B.

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

Date:     Friday, 26 Apr 85 17:34:04 EST
From:     nbush (Nicholas Bush) @ sitvxb.ccnet
Subject:  Minimum files for running VMS Kermit 3.1
Reply-to: SIT.BUSH @ CU20B
To:       Info-Kermit @ CU20B

It is not necessary to have all of the VMSxxx files in order to put up VMS
Kermit 3.1.

If there is no reason for the site to rebuild Kermit from sources, the only
files needed are:

    VMSMIT.HEX - "Hexified" copy of the .EXE file for Kermit-32
    VMSDEH.MAR - Source for dehexifying program
    VMSMIT.RNH - RUNOFF source for .HLP files.  Alternately,
             VMSUSR.HLP and VMSSYS.HLP can be retrieved.
    VMSV31AN.MEM - Description of changes between v3.0 and v3.1

If there is some need to rebuild Kermit from the Macro-32 sources, you will
need to include VMS*.MAR, VMS*.COM and VMS*.MSG.

If Kermit is to be rebuilt from the Bliss sources, retrieve VMS*.BLI, VMS*.MSG,
VMS*.REQ, VMS*.COM and VMSGEN.MAR.

Note:    If you do not have a Bliss compiler, there is no reason to
    get copies of the .BLI and .REQ files, since the .MAR files include
    the Bliss source listing.  Likewise, if you have a Bliss compiler
    there is no reason to get copies of the .MAR files (except VMSGEN.MAR),
    since they are just built from the Bliss sources.

Hopefully, this will cut down on the file transfer times for those who
need a new copy of Kermit-32.

- Nick

[Ed. - Note that several files were either missing or were left over from
the old version when the announcement of this new version first appeared in
the last digest; they are now correct.  The files are KER:VMSGLB.MAR,
KER:VMSMIT.MAR, and KER:VMSSYS.MAR.  Also, apologies for not mentioning in
the initial announcement that the files are available as KER:VMS*.* via
anonymous FTP from CU20B.]

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

Date: Mon 29 Apr 85 09:14:29-CDT
From: Bob <[e-mail]>
Subject: .HQX file for new Mac Kermit
To: sy.fdc@CU20B

This may be a problem on my side, but both times I transferred copies
of CKMKER.HQX to our DEC-20 here, the file came over with ONLY CR's at
the end of each text line.  A quick TECO job (showing my age) fixed it
but thought I'd mention it--just in case there's something wrong on
your side.

I've only used the new Kermit a couple of times so far and really like
what I see.  Thanks for all the good "stuff" you and your people do.

Bob Paver

[Ed. - Sorry, the .HQX file has been fixed to have CRLFs rather than just
bare CR's between the lines.]

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

Date: Mon, 29 Apr 85 01:21:44 pdt
From: Harry Saal <hjs@Lindy>
Subject: Clarification on version #'s
To: [e-mail]

I ftp'd the mackermit.hqx file from <mackermit> on cu20b and the .hlp
file that is there also. The .hlp file refers to a version V0.6(1), but
looking at the About Mackermit screen on the Apple Menu says that the
version available for beta-test is V 0.5(0). Thought you would like
to know about this so you can track down problems against the current
version.

[Ed. - The first pre-release contained all the advertised features and
bugs, but the version number was wrong.  The new release has an
appropriate version number.]

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

Date: Sat 27 Apr 85 09:19:33-PST
From: Doug Brutlag <[e-mail]>
Subject: Comments on MacKermit Prerelease
To: info-kermit@CU20B

    After using MacKermit to communicate with both a TOPS-20 system
at 1200 BAUD and MSKERMIT on an IBM PC at 9600 BAUD I have noted the
following problems which were not mentioned on CKMKER.BWR.  I should
mention that I got KERMIT.HQX from CU20B Thursday evening the day of the
announcement and I am running it on a 512 K Mac but configured with
Switcher to be in 128 K.

1)  KERMIT does not SEND/RECEIVE files from the DEFAULT disk.  Instead
it always looks at the disk from which it has been launched.  This is
inconvenient since you must always have a copy of MacKermit on the disk
which contains your data.

|    We tested SENDING from a second disk to DEC and VAX Kermit, it
|    works.  Select the file and volume you want in the SFGetFile
|    dialog.  Please Supply further information if this is still a
|    problem.
|
|    For GET you can specify the disk name when you specify the
|    file name -- "Startup:foo.c" -- this is a MAC standard done by
|    the file manager.

2)  SAVED SETTINGS files are not actually closed until after you QUIT
MacKermit properly so if you SAVE SETTINGS and then reboot and try to
RESTORE SETTINGS from that file you get an Error reading file -39.  If
you actually QUIT MacKermit and then relaunch it, you can then RESTORE
from a SETTINGS file.

|    This problem has been fixed in MacKermit V0.6(4), a FlushVol
|    was added after a close.

3)  There also seems to be a problem with properly closing transferred
files.  If one downloads a series of files to the MacKermit and then
uses switcher to move to the FINDER those files are not visible on the
desktop or in the opened Disk window.  If you RELAUNCH a new finder the
files appear.  The files are present in File Selection menus and hence
it is just their icon that appears missing from the finder.  Most other
applications I have used that create new files set something in those
files that cause the FINDER to generate their icon when you switch to it
in Switcher.

|    This has been fixed in MacKermit V0.6(2), we added a FlushVol
|    in the file close routine and now all works well.

4)  In the communications SETTINGS menu the PORT and AUTOWRAP settings
do not darken when selected.

|    Will document.  These are not supported.

5)  If one starts a file transfer and something is wrong at the other end
(like forgot to start kermit) it takes a long time for KERMIT to time
out.  It would be nice if in addition to the CANCEL FILE and CANCEL
GROUP buttons there was an ABORT button like Control-C in MSKERMIT.
Either this or to document the Command-. on the file transfer progress
window would be helpful.

|    Will display Command-. message.

6) If one types in a filename in lower case in the file transfer window
when sending to a TOPS-20 system, the file name on TOPS-20 comes out in
lower case!!  This makes it very difficult to reference the file to
delete or to type it.  One has to type control-V before every character
of the name in order to reference filenames in lowercase on TOPS-20.  Is
there any way one could prevent MacKermit from sending TOPS-20 a lower
case filename but still allow this for UNIX systems?

|    There is code to uppercase outgoing filenames.  When the "AS"
|    filename is specified in the SEND dialog MacKermit does not do
|    file name conversion.  We changed the dialog to no longer
|    stuff the "AS" filename.  Also we found a bug in the file name
|    conversion routine which failed to deposit a NULL at the end
|    of the converted name.  These two changes made to MacKermit
|    V0.6(1) should solve your problems.
|
|    We had not noticed this problem because TOPS-20 is doing
|    conversion for us, it can for you too by using the most recent
|    version of 20 kermit, 4.2(255).

7)  The Close box in the MacKermit window does nothing.  It might make a
nice way to Quit the program.

|    Matter of taste.

8)  Sending DATA files to and from other kermits worked fine but
whenever I tried to send a Resource fork (I tried sending BINHEX 4.0) it
always hung (and always on the same packet, 9 for BINHEX 4.0).

|    We tried sending Binhex 4.0 and other resource files from
|    MacKermit to a VAX/Unix and DEC-20 Kermit and could not reproduce
|    this problem.  What version Kermits are you using, what are
|    the parity settings?  Does anyone else have this problem?

9)  Terminal emulation:  The display supports all VT100 commands I tried
and works well with display programs on TOPS-20, but key board support
is lacking.  The Numeric keypad does not send standard VT100
characters, nor is the command=numeric keypad setting implemented.  Also
MacKermit does not respond to the ALTERNATE KEYPAD APPLICATION command
from the host.  The Command key works nicely for the rest of the
keyboard even with shifted characters and unshifted ones.  It would be
nice if the OPTION key worked like a META key, either setting the eighth
bit OR sending an escape character before each character typed.  The
latter implementation has the advantage that it works over 7 bit
networks.

|    All known.  Some of this may be addressed in future versions.

In general MacKermit works very well and I think you have another
winner on your hands.

Doug Brutlag

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

Date: 28 Apr 1985 1534-PDT (Sunday)
From: Elgin Lee <ehl@Navajo>
To: Info-Kermit@cu20b
Subject: MacKermit Bug Report

I just picked up MacKermit -- it looks very good!  I think I've found a couple
of bugs, though:

    1.    Double-clicking on a settings file doesn't work -- I
        get system error 02 on startup.

|    We haven't seen this problem and can't reproduce it.  It
|    sounds like your finder is running the settings file instead
|    of the CKMKER file.  This would occur for example if you
|    modified your settings file to be type APPL instead of type
|    TEXT; or you forced the finder to run the settings file by
|    using the magic command-option-shift-capslock-double-click.


    2.    With Switcher 2.0, using the Apple menu to get back to the
        Switcher doesn't work.  Command-\ does work, however.  I
        have no problem getting the Apple menu route to work
        in other applications.

|    This problem has been fixed in MacKermit V0.6(3).

    3.    Trying to switch between active MacKermit and
        MacTerminal programs doesn't work.  I either get
        system code 02, continuous rampaging through memory,
        or a never-ending sequence of alert boxes telling
        about error at the Serial Port -- error -28.  I'm
        not sure if this is a Switcher bug or MacKermit bug,
        but I thought I'd mention it anyway.  I've
        had no trouble switching between two active MacTerminal
        programs.

|    Not totally true.  If one of the two programs closes the port
|    on the other these things can happen, but otherwise we've used
|    that combination fine.  Definitely a proceed-at-your-own-risk
|    situation.  Maybe we'll install some recovery for the error
|    that occurs when the serial port is closed from beneath
|    MacKermit.

Well, that's about it.  Other than that, MacKermit looks very good.

            Elgin Lee
            [e-mail]

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

Date: Mon, 29 Apr 85 01:25:57 pdt
From: Harry Saal <hjs@Lindy>
Subject: problem and question re Mackermit
To: [e-mail]

1. I tried using MacKermit 0.5(0) (??) when I had the analog watch desk
accessory running in the corner (it is on info-mac..). I did not get
any characters from the keyboard handled by mackermit. When I closed
down the accessory, all was ok. SOmeone is guilty...

|    MacKermit only accepts input if the terminal emulator is the
|    front window.  We decided at one point that this would be
|    a good thing because otherwise typein to desk accessories is
|    accepted by Kermit.  A better solution would be to check for
|    active rather than front window.  This will be inserted in
|    our to do list.

2. Question about 9600 baud operation. Can I use it for server/host
file xfers, if I do not have a response window open, and am just
going from file to file and not the screen? The comments about 9600
baud being a problem in the HLP and BWR documents put me off....

|    9600 baud is fine, just loses some chars if a number of
|    screens are sent continuously.  No problems during protocol.

3. By the way: THANKS A LOT for this. I was struggling with the old
simple buggy MacK and this seems to do what I was looking for. Now I
am about to see about using the IBM PC-Kermit for a server implementation,
driven by MacKermit as Users. It looks like MacKermit running against
UNIX C-kermit was fine when I tried it. Next to beat on the PC.,..
wish me luck!!!!!!!!!!!!!

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

Date: Mon 29 Apr 85 08:09:06-EDT
From: Harry Berger <[e-mail]>
Subject: Rainbow 100+ Kermit-MS vs MS-DOS 2.11?
To: info-kermit@CU20B

I tried using version 2.27 of kermit on a Rainbow 100+ under MS-DOS 2.11
without any success.  Once I entered the CONNECT command nothing further
will happen.  Has anyone else come across the same problem? If so what
needs to be done to get around the problem.

[Ed. - I have had confirmation that 2.27 MS-DOS Kermit works OK on the
Rainbow under MS-DOS 2.11 on a hardwired connection.  The only problems I
can imagine would involve the pesky business of DTR dropping, detection,
etc, which seems to change with every DOS version.  Anybody out there with
DOS 2.11 and Kermit 2.27 that can shed some light on this?]

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

Date: Sun, 28 Apr 85 00:07:55 est
From: Alan Parker <parker@nrl-css>
To: [e-mail]
Subject: Kermit for Grid Compass?

Are you aware of a kermit for Grid Compass 1101?

-Alan

[Ed. - Not me.  Anyone out there working on one?]

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

End of Info-Kermit Digest
*************************
-------
 3-May-85 19:10:57-EDT,18128;000000000000
Mail-From: SY.FDC created at  3-May-85 19:10:30
Date: Fri 3 May 85 19:10:30-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #23
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri,  3 May 1985       Volume 2 : Number 23

Departments:

  ANNOUNCEMENTS -
    New Minor Release of DEC-20 Kermit

  MACINTOSH KERMIT -
    Mac Kermit bomb
    New Mackermit problem
    MacKermit V0.6(4) Comments
    MacKermit and Disk Default

  C-KERMIT -
    C-Kermit for Amdahl UTS?
    C-Kermit under Xenix? (Several Messages)
    C-Kermit with Compressed Files
    Bug in C-Kermit

  MS-DOS KERMIT -
    Kermit 2.27/Rainbow MS-DOS 2.11
    Data General D200 Terminal Emulation for IBM-PC Kermit?
    KERMIT for TI-PRO with TI Internal Modem?

  MISCELLANY -
    To Ship Files up to a Cray

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

Date: Thu 2 May 85 14:31:52-EDT
From: Frank da Cruz <[e-mail]>
Subject: New minor release of DEC-20 Kermit
To: [e-mail]

This is to announce a minor new release of DEC-20 Kermit, version 4.2(256),
which fixes several small problems:

. Kermit-20 would ACK an EOF packet even if it couldn't close the incoming
  file.
. Remote directory commands with no arguments to Kermit-20 server sometimes
  crashed Kermit-20.
. I/O errors (e.g. quota exceeded) while writing debug log file would crash
  Kermit-20 .
. Incoming filenames that started with dot could not be reasonable renamed
  by Kermit-20.
. The "push" command message was misleading if "push" command issued from
  prompt level.
. The "server" command message was misleading if Kermit-20 in local mode.

The source file is in KER:20KERMIT.MAC, the binary in KB:20KERMIT.EXE, and a
list of known bugs and restrictions for this version in KER:20KERMIT.BWR, all
available from CU20B via anonymous FTP.  Other files (documentation, etc) have
not changed.

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

Date: Wed 1 May 85 01:16:37-PDT
From: Richard Furuta <[e-mail]>
Subject: Mac Kermit bomb

I have a Mac Kermit configuration file in which all I've done is set
the speed to 1200 baud.  I can start Kermit without trouble by double
clicking on that file.  If, however, I duplicate the file with the
Macintosh clover-D command and then try double clicking the copy to
start Kermit, I get a system error, ID=03.  This is repeatable.

[Ed. - The problem was that SUMACC had an erroneous definition.  A
workaround has been installed in the current release, 0.6(5), and the
problem reported to the SUMACC folks.]

I am also having difficulty convincing a VM/CMS Kermit to talk to this
one but that is probably my own fault for not being comfortable on the
IBM machine.  I can't get anything at all to happen.  We speak to the
IBM 4381 thorugh an "IBM 7171 ASCII Device Control Unit."  What should
the proper settings be on both ends?  What settings correspond to the
"IBM" setting mentioned in the Kermit User's Manual?

[Ed. - We use Mac Kermit to talk to our VM/CMS Kermit all the time.
HOWEVER...  we're not going through a 7171 (equivalent to a Series/1 with
the Yale IUP).  The reason you can't transfer files through it is that the
7171 is merrily converting your packets into the ASCII equivalent of 3270
screen commands.  The solution: wait until version 2.00 of VM/CMS Kermit
comes out (next week, I hope), which will include code to communicate
through front ends like this.]

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

Date:     Wed, 1 May 85 08:47 CDT
From:     Stewart_French <[e-mail]>
Subject:  New Mackermit problem

I am attempting to use the New Mackermit and am having an interesting problem.

I have the following setup that I use to communicate with our VAX/VMS system.
I have Kermit version 3.0.052 for VAX/VMS.

[Ed. - Diagram omitted.]

The Novation talks to the Mac at 8-bit no parity, then converts it to
7-bit odd parity to talk with the LAN  (Novation command "%F 2" converts
to 7-bit odd parity) over the phone lines.
The novation intercepts '%' characters, the LAN intercepts '~' characters.
Both can be changed.

I want to transfer simple ascii text files (at least for now).  The old
MacKermit worked just fine when I made the attention characters CONTROL-G
for the novation.  I did not have to change the LAN attemtion character '~'.
The new MacKermit will not talk at all through this set up.
It immediately attempts retransmissions until it fails.

Can you help me??

-Stewart French
 french%ti-eg@csnet-relay

[Ed. - The problem is that the new Mac Kermit does data compression using
tilde ('~') as the lead-in character for a compressed sequence.  If the
old Kermit worked at all, it was only because your data never happened to
contain a '~' character.]

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

Date: Thu, 2 May 85  9:31:32 EDT
From: Dave Swindell <dswindel@bbn-labs-b>
Subject: MacKermit V0.6(4) Comments

I just finished installing MacKermit V0.6 on a thin Mac and thought I
would pass on a few comments.  All of the major commands I tried, such
as SEND FILE, RECEIVE FILE, GET FILE, and the REMOTE commands worked
as advertised.  I was a little supprised to see that I had to open a
special window on the MAC in order to see the output from the remote
servers (I tried MacKermit with a Tops-10 Kermit as well as CKermit).
Might it be better to offer distinct 'CONNECT' and 'CLOSE Connection'
menu items on the Mac?  This would make the program more similar to
its counterparts on other microprocessors.

[Ed. - You're right about the remote command window -- it should pop up
automatically for remote commands that cause text to be sent back.
Mac Kermit is connected by default mainly because there's no reason not
to be, and this seems more in keeping with the Macintosh style.]

The VT102 (?) terminal emulation worked well, for the most part.
MacKermit correctly processed the ANSI codes for screen erase, cursor
positioning, video attributes, and scroll region select.  I was not
able to generate any of the special line drawing characters which are
present on a VT1xx terminal equiped with AVO (advanced video option).
Will these characters be supported in the final release??

[Ed. - Mac Kermit uses an ordinary system fixed-width font for terminal
emulation; no VT100 drawing characters, nor double-width/height equivalents
are available in that font, and won't be added to Kermit in the forseeable
future because of space restrictions.]

As a final comment, I noticed that when I used the RECEIVE FILE
command, I could not specify a new file name for the received data, as
is possible with Kermit-65 and MS-Kermit.  You are given this option
when you GET files from a remote server.  I think that the ability to
specify a new name for received files is important and hope that the
this feature will be added to the 'real' release of MacKermit.

[Ed. - Agreed; this will be in a future release.]

All in all, I was very pleased with the New MacKermit.  I was able to
transfer resource and data files with no problems.  Thanks for all of
the hard work!

Dave Swindell
BBN Labs

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

Date: Fri 3 May 85 10:34:14-PDT
From: Doug Brutlag <[e-mail]>
Subject: MACKERMIT AND DISK DEFAULT

    I am still having difficulties with MacKermit 0.64 not receiving
files onto the default disk.  When you use GET.. from a server at the
other end, MacKermit always saves all the files on the disk from which
Kermit was launched.  If you change the DEFAULT disk from internal to
external using DISKINFO disk utility MacKermit still stores files on the
internal disk.  Most other Mac software respects the setting of Default
disk and does all of its file i/o to the default disk.

    I tried your suggestion of GETing files and specifying the disk
name in the AS box like this:  GET *.INIT AS EXT-DISK:*.INIT.  MacKermit
stored the first file on the EXT-DISK but with the filename *.INIT (!).
Then it stored all subsequent files with there normal file names on the
internal disk.  Maybe I should have just specified EXT-DISK: with no
filename but it sure would be nice if MacKermit would save to the
default disk like WORD, FILE, MacWrite, MacDraw etc...

Doug Brutlag

PS.  I noticed that the Command-. abort was still not documented in the
file-transfer progress box, nor did the number of Kilobytes register
when GETing files from a server.

[Ed. - We're working on new send/receive dialog boxes, but they won't be
ready for a while.]

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

Date:  2 May 1985, 18:38 EDT
FROM:  ACDMAYER%UOGUELPH.BITNET@WISCVM
Subject: C-Kermit for Amdahl UTS?

    What is the state of the UTS version of C-Kermit (4.2)?  If it is
    going to be a while before it's released, maybe I will do the conversion
    myself.  (At least as best as UTS will allow).

  (ALASTAIR MAYER  <[e-mail]>)

[Ed. - We have UTS version 2.4 at Columbia, but we're about to retire it
in favor of their new system V version.  I gather that everyone else will
be doing the same, since Amdahl is "desupporting" the old one after six
months, and it doesn't cost much (at least to universities) to upgrade.
Since they seem to be shipping the new one now, it would be a waste to
adapt C-Kermit to the old one.  If you want to adapt C-Kermit to the old
UTS, be my guest.  But wait until the new C-Kermit comes out (version 4C,
probably next week).]

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

Date: Wed, 1 May 85 08:09:37 pdt
From: Bob Rendler <ren@lbl-ux4>
Subject: C-Kermit under Xenix?

Does anyone have Ckermit running on an IBM PC/AT under Xenix?  Following
the instructions in the makefile we did a "make xenix" to make kermit on
the PC.  We are having problems with 'connect'.  When the carriage-return
is typed to get the prompt to log into the remote we get "Communications
Line Failure".  We are using the same line for MSkermit and do not
experience this problem.  Thank you.

Bob Rendler

[Ed. - See below.]

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

Date: Monday, 29 April 1985  14:47-MDT
From: Jim Scardelis <ihnp4!timeinc!wcom!frodo@Ucb-Vax>
Subject: C-Kermit under Xenix?

Has anyone gotten C-kermit successfully running under Xenix 3.0?
I have given up trying to get it to run on an IBM PC/AT Xenix system...

                    Jim Scardelis

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

Date: Fri 3 May 85 09:32:57-PDT
From: Herm Fischer <[e-mail]>
Subject: C Kermit and Xenix for the IBM PC/AT

C Kermit does indeed run on the IBM PC/AT Xenix.  You should have no
problem if you use "make xenix" to make it.  The IBM PC/AT has
been one of the prime development machines for the recent versions
of C Kermit, and thus your query surprises me.

If you totally fail to be able to get C Kermit up, the only suggestion I
could make is to obtain a binary copy directly from another PC/AT which is
using it.  It has been tested on "stock AT's", "xtal-speedup AT's",
modems, modems using the old serial cards, and LANs with flow control.

  Herm Fischer

[Ed. - Versions prior to 4.2 lacked the data-carrier-detect/CLOCAL code
that overcomes the most commonly reported problems.  The next release,
version 4C, will have additional improvements in this area.]

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

From: trwrb!trwspp!spp3!kurisaki@Berkeley (Lance R. Kurisaki)
Date: Fri, 3 May 85 08:00:46 pdt
Subject: C-Kermit with Compressed Files

In volume 2 number 4 of Info-Kermit, James Woods tells us how we can use
the kermit to transfer compressed files, and increasing the effective
transfer rate.

I have been trying to use kermit in the way described and have been having
some problems.  When I receive a file "passively" with the "-k" option,
kermit seems to be adding a leading CR, so that when this is piped to
compress, it comes back with "not in compressed format".  This happens
even on text files.

Has this behavior been noticed by others, or am I doing something wrong
here?

By the way, I'm using 4.2 C-Kermit to transfer files between two Pyramid
90x's under the 4.2bsd universe.

                Lance Kurisaki
                {ucbvax|decvax}!trwrb!trwspp!kurisaki

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

Date: Thu, 2 May 85 21:16:29 edt
From: xp!tony@nyu-cmcl2 (Tony Movshon)
Subject: Bug in C-Kermit

This one may be known, but it should be fixed. A user under the
misapprehension that it is necessary to "set line" to his home tty (i.e.
if you are already on /dev/tty05, "set line /dev/tty05") will be
permitted to do this. He may also "set baud" to something other than the
current line rate. At that point, "connect" connects you to your own
terminal, at a different baud rate. !>poof<!

Fix: C-Kermit should trap the case when the argument to a "set line" command
is the same as /dev/tty (this can be done by checking the device numbers).

Tony

[Ed. - It's a bug all right, but it's not obvious to me how to determine
that /dev/tty is the same device as /dev/tty05 (in a way that will work on
most or all Unix systems).  If anybody knows, let me in on it.]

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

Date: Wed, 1 May 85 13:37:33 edt
From: xp!tony@nyu-cmcl2 (Tony Movshon)
Subject: Kermit 2.27/MS-DOS 2.11

A quick note about the problem with MS-Kermit V2.27 and DOS 2.11 on the
Rainbow that came up in the Info-Kermit newsletter, vol. 2 no. 22. I have
been using this setup happily for several months without problems, both
using hard-wired and modem lines. I suspect that you are correct in
suspecting the DTR control stuff, since I use my modems with DTR detection
disabled (DTR control has been a problem on the Rainbows all along, so I
long ago just decided to bag it).

Recommendation: don't try to use DTR on the Rainbow at all. Then everything
will work fine.

A second beware: DOS 2.11 is fussier than 2.05 about the way in which
resident utilities load themselves -- the problem may not be directly
related to Kermit, but to some other utility interfering with things.
Be sure to check out all resident utilities that used to work with 2.05
specifically for 2.11.

Tony

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

Date: 3 May 85 18:15:29 EDT
From: RL0Q@CMU-CC-TD
Subject: Data General D200 Terminal Emulation for IBM-PC kermit

I would like to connect to a Data General MV/4000 using my IBM-PC as a
terminal.  Is there any ms-dos version, out there in kermit land, that
would allow my PC to emulate a D200 terminal instead of a Heath-19?

                                                Rich Lunak

[Ed. - I'm sure there are Dasher emulators out there in PC land.  The
trick is not to put them in Kermit -- where will it end, after all? -- but
to write them as loadable console drivers (like ANSI.SYS), which can be
run in conjunction with Kermit (SET HEATH OFF).  We expect (hope) to see a
high quality VT102 driver in this vein pretty soon, lawyers willing.]

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

Date:     Fri, 3 May 85 15:59 CDT
From:     Richard_Berke <[e-mail]>
Subject:  KERMIT for TI-PRO with TI Internal Modem?

I have looked on the DEC-Marlboro system CURRENT.DOC file, but I don't
find a TI-PRO version of KERMIT for the TI-INTERNAL
modem.  Joe Smith's version 2.27 is for the normal sync/async card,
and using an external modem.

If you know of any version for the TI internal modem, please let me know.
If there is no official notice of a version, can you include my query
in a future issue of KERMIT DIGEST?

Also... I have tried Joe Smith's TI-PRO v.2.27 with Tek4010 emulation.
When I run a SAS job on our IBM4341, specifying a device type of TEK4010,
I get rows of horizontal bar characters across the top of the screen in
addition to my graphics, and if the SAS job results in normal text characters
as part of the output (such as labels on a pie chart), the text gets printed
on the screen right after the two rows of horizontal bars.  It appears that
real cursor positioning, and intended cursor position requests are not
working so good.

[Ed. - I trust you told the PC that you were talking to an IBM system,
using "do ibm" or the appropriate "set" commands.]

I understand that Joe Smith has left CSM.  Is anyone else aware of the
problem I have described?  How can a fix be pursued?

(I am not familiar with internals of the KERMIT programs.  I just enjoy
its functionality in my work with mixed computer systems at TI.)

Richard Berke
Texas Instruments
Equipment Group
PO Box 405   MS 3454
Lewisville, Texas 75067

[phone]

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

Date: Wed, 1 May 85 13:48:56 mdt
From: [e-mail] (David Wade)
Subject: To Ship Files up to a Cray

I have been getting a lot of long distance phone calls from people trying to
talk to the crays with kermit.  They don't have our mskermit.ini file to
make a few simple changes to make the cray kermit work better.

Therefore, here it is:

set baud 1200
set parity even
define cray set end 23, set send padch 26, set send padding 1

This makes a few adjustments to the "end, padch, & padding" characters.
If you adjust your kermits to:

set the "end of packet" character to ^W (Control W)  i.e. 23
set the "padding" character to ^Z (Control Z) i.e. 26
set the number of padding characters to 1

These changes will allow you to talk with the Cray kermits directly.

There is a special case at Los Alamos that applies to people coming in
over arpanet.  The front end machine runs an abbreviated Unix(tm) system
and that includes the Unix kermit.  Use that one to get your files to
Los Alamos if you are on Arpa.  Then convert the files to "Standard
Text format" and "Move" them to the Cray of your choice.

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

End of Info-Kermit Digest
*************************
-------
 7-May-85 19:42:44-EDT,2135;000000000000
Mail-From: SY.FDC created at  7-May-85 19:42:02
Date: Tue 7 May 85 19:42:02-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #24
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Mon,  7 May 1985       Volume 2 : Number 24

                Announcing Version 2.00 of CMS Kermit

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

Date: Mon 6 May 85 17:49:51-EDT
From: Daphne Tzoar <Sy.Daphne@CU20B>
Subject: Announcing Version 2.00 of CMS Kermit
To: [e-mail]

Version 2.00 of Kermit-CMS is now available.  Some of the new
features are:

- Prefixing of the "8th bit".  This allows CMS Kermit to send or
  receive fixed format binary data, such as microcomputer binary files.

- The maximum record length allowed has been increased to 64K for
  both incoming and outgoing files.

- Repeat count prefixing has been added to speed up transmission.

- Support for two character checksum and three character CRC.

- New debugging mode to log packets.

- Input to command parser allowed from command line.  Multiple commands
  should be separated by the linend character.  After execution of these
  commands, Kermit returns control to CMS.

- Support for Series/1 front end with Yale ASCII package.

- Server operation.

- Upon startup, read commands from two init files: SYSTEM KERMINI and
  (USERID) KERMINI (that is the userid of the person running Kermit).
  Add TAKE command.

- Allow system manager to change ASCII/EBCDIC translation tables to
  conform to the various specifications of different systems.  Also,
  bypass user translate tables when sending and receiving data.

Work on CMS Kermit continues.

Daphne Tzoar
Columbia University Center for Computing Activities

[Ed. - The files are available on CU20B as KER:CMS*.* via anonymous FTP,
and on BITnet via KERMSRV at CUVMA.  Included is a new Kermit User Guide
chapter for CMS Kermit.]

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

End of Info-Kermit Digest
*************************
-------
10-May-85 19:11:10-EDT,8090;000000000001
Mail-From: SY.FDC created at 10-May-85 19:10:35
Date: Fri 10 May 85 19:10:35-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #25, C-Kermit 4C Announcement
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 10 May 1985       Volume 2 : Number 25

       C-Kermit 4C Available for Unix, Macintosh, and VAX/VMS

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

Date: 10 May 1985 7:01pm
From: Frank da Cruz <SY.FDC@CU20B>
Subject: C-Kermit 4C Available for Unix, Macintosh, and VAX/VMS

Release 4C of C-Kermit is now available.  It does not embody major
functional changes over the previous version, 4.2 (note, the version
number style was changed to avoid confusion with Berkeley Unix version
numbers), but has many bugs fixed and includes support for many more
systems, including:

  . Berkeley Unix 4.2 (Columbia U)
* . Berkeley Unix 4.1 (Charles Brooks, EDN)
* . ATT System III and System V (Herm Fischer, Encino CA)
* . Unix Version 7 (Gregg Wonderly, Oklahoma State U)
* . Berkeley Unix 2.9 (based on V7)

  . Some "custom" Unix-like systems, including:
*   - PC/IX on IBM PC/XT (Herm Fischer)
*   - Xenix on IBM PC/AT (Herm Fischer)
    - DEC Pro/Venix Version 1 (improved performance & functionality) (Columbia)
*   - NCR Tower OS 1.02 (didn't work before, allegedly fixed) (John Bray)

  . And two major non-Unix systems...
    - Apple Macintosh (Columbia U)
*   - VAX/VMS (Stew Rubenstein, Harvard; Martin Minow, DEC)

Adding support for all these new systems has been a network-wide effort.
Although every attempt has been made to ensure that adding support for
system B did not break the program for system A (and adding support for C
did not break A and B, etc etc), some of the key contributors have become
unavailable since sending in their code and have not been able to test it.
The implementations marked with an asterisk above have not been tested
in the very latest edit; they worked recently and should work now, but this
cannot be guaranteed.  I would appreciate it if users of each of these
systems could report back to Info-Kermit indicating whether the program
works on their system, and if not, what the symptoms are and if possible
include fixes.

* Legalisms

Copyright notices have been added to all the source modules to reduce the
possibility that restrictions upon distribution and redistribution of the
Kermit source code could be imposed by ATT or ATT sublicensees.

* Distribution File Names

Since so many more systems are now supported, it has become necessary to
devise a more sensible naming scheme for the source files.  This was done,
and is described in the file CKAAAA.HLP.  The files have all been (re)named
accordingly.

* Protocol

Many changes have been made to the protocol modules and header files shared
by all the systems that run C-Kermit.  The changes are listed in detail in the
CKUKER.UPD file; a few of the major ones are:

. Organizational changes to allow better support for mouse/window systems.
. The method for mapping between CRLF and a system-dependent newline character
  is now selectable at compile time, rather than hardwired into the program.
. In the last release of this program, files transfer would occasionally
  omit bytes and the end of a file; this no longer happens.
. R, X, or F packets sometimes had garbage characters preceding their
  intended contents; this no longer happens.
. The file output function did not return a failure code upon i/o error or
  disk full, so failed transfers were reported as OK; this no longer happens.
. Unix-specific symbols or values (like init file name, program return code)
  that were hardwired are now compile-time symbols.

* Unix

In addition to the support for extra Unix and Unix-like systems, several
functional changes were made to the program:

. Interactive command lines and lines in take files may now be continued
  on new lines by putting a single '\' character at the end.  This can
  make long script commands more readable.
. Some attempt is made to recover from i/o or disk full errors when writing
  to the session log during connect.
. Support for new modem dialers added - Racal-Vadic, Penril, Cermetek, etc.
. Script command has a few new escapes: ~d(elay), ~w(ait), ~x(on).
. Long strings and/or (f)printf arguments have been shortened enough for
  them to work on all systems (let's hope!)
. File renaming and name collision avoidance is improved.
. Directory command is no longer "recursive".
. '!' command now invokes user's login shell instead of always using sh.

* VAX/VMS:

C-Kermit has been adapted to VAX/VMS; the result has been tested
successfully, but not extensively.  The main deficiencies are probably in
the areas of performance and intelligence about the VMS/RMS file system.
C-Kermit for VMS should not be regarded as a replacement for the Stevens
Institute of Technology Bliss implementation, but reports as to its
usefulness are solicited.

* Macintosh:

A prerelease of this program appeared a couple weeks ago.  Since then, thanks
to many helpful bug reports from the net, many improvements have been made:

. Parity settings should now mostly work.
. Improved file dialog boxes, available now for GET, RECEIVE as well as SEND.
. Many new file settings available (text/binary, data/resource, supersede/
  preserve, etc), savable in the settings file  (Note, settings files have
  new format, old ones can no longer be used).
. ASCII text files now stored correctly, so Mac applications can use them.
. Remote command window pops up automatically when needed.
. Mac Kermit can be a limited server, responding to SEND, GET, BYE, FINISH,
  and REMOTE HELP commands.
. Various changes relating to selection/specification of disk/volume/folder.
. The beginnings of a manual (CKMKER.DOC).

Several major areas will have to be attacked in subsequent releases (in order
of priority):

. Key redefinition, support for function keys, keypad, etc.
. Saving screen contents into a file.
. Support for XON/XOFF during terminal emulation.
. Support for additional VT102 features.
. Modem dialer support.
. Login scripts.
. Raw file upload.
. Printer support.
. Translation to a native Macintosh C compiler so you don't need a VAX
  to build the program (with conditional support for SUMACC left in), and
  so that the program can grow by taking advantage of dynamic segment
  loading, which SUMACC doesn't support.

We are working on the first two items ourselves; contributions in other
areas would be welcome.

Macintosh C-Kermit has been successfully tested in conjunction with DEC-20s
and VAXes (full duplex mainframes) at speeds up to 9600 baud, with IBM
mainframes (half duplex, handshake, various kinds of parity) on both ASCII
async ports and 3270-emulation ports at speeds up to 4800 baud, and with
another Macintosh in server mode at speeds up to 57.6K baud.  It runs on 128K
and 512K Macs and on the "Macintosh-XL", standalone or with the switcher.

* Distribution

The files have been placed on CU20B in the area <CKERMIT>.  The <MACKERMIT>
area has been removed.  The previous releases of C-Kermit (4.2) and MacKermit
(Steve Engel's original from Harvard) will remain in KER: until we receive
reports verifying that the new version installs and works as advertised on
all the systems listed above.  Prompt reports would be appreciated, so that
we can start putting the new C-Kermit on our distribution tapes.  The files
may be obtained via anonymous FTP from Internet host CU20B as <CKERMIT>*.*.
The file <CKERMIT>CKAAAA.HLP explains what all the files are.  Be sure to
read the appropriate "beware" (.BWR) file before installing or running the
program -- these files list all known bugs, restrictions, and peculiarities
of each implementation.

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

End of Info-Kermit Digest
*************************
-------
13-May-85 19:37:17-EDT,7482;000000000000
Mail-From: SY.FDC created at 13-May-85 19:36:47
Date: Mon 13 May 85 19:36:47-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #26
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Mon, 13 May 1985       Volume 2 : Number 26

Departments:

  C-KERMIT 4C
    Bug in New Macintosh C-Kermit
    C-Kermit 4C Bugs

  DIALUP DISTRIBUTION
    Kermit Distribution Available via Kermit Server
    Change Of Kermit-11 Update Procedure

  MISCELLANY -
    Computer Vision Kermit?

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

Date: Fri 10 May 85 21:38:53-EDT
From: Bill Schilit <SY.BILL@CU20C>
Subject: Bug in New Macintosh C-Kermit
To: sy.fdc@CU20C

I sent a file from the Mac, I started a new transaction and emergency-
exited with Command-.; C kermit deleted my file.

[Ed. - Oops, sorry.  This bug effects Mac Kermit only, even though the guilty
code appears in the common protocol module -- only the Mac can cancel a
transaction before the first data packet has been sent.  The emergency exit
code should not delete any files.  The code is now fixed, see below.]

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

Date: Sun, 12 May 85 15:46:35 pdt
From: [e-mail] (Dave Tweten)
Subject: C-Kermit 4C bugs

I got a copy of C-Kermit 4C, Friday evening, May 10.  I built it on both
our 4.2 bsd Vax and on one of our System V Vaxes.  I found three new
problems, and noticed that a fourth problem I've been trying to find in
C-Kermit 4.2 is still present, though in a slightly changed form.  They
follow, in no particular order.

1.   When getting a binary file, if the local kermit is the 4C bsd
     version, all will go well except that at the end, "Z [discarded]"
     will appear.

[Ed. - This problem was introduced by adding code to zchout() to check
when putc returns an error code -- the old char/int/sign-extension mixup.]

2.   In server mode, remote commands issued by C-Kermit cause version 4C
     to hang the transfer with a continuous stream of NAKs.  The remote
     commands I tried were "rem dir" and "rem host ls -l".  The tests
     below were conducted with "rem dir".  I tested the following
     combinations:

[Ed. - This problem was introduced by adding code at the last minute to make
the Macintosh version work better and then assuming it still worked on Unix.]

3.   C-Kermit 4C Racal-Vadic modem support doesn't work with our
     Racal-Vadic modem on the System V machine.  The bsd machine's modem
     line has been munged by uucp and needs superuser service, so I
     can't test that over the weekend.  The gross behavior is the same
     behavior I observed with an early version of the dialer code, which
     was sent to me by Herm Fisher: it always times out.

     With Herm's code running on our bsd machine, I inserted prints to
     stderr, and observed that the conversation with the modem went as
     expected, until the actual dialing began (modem says "DIALING:  "),
     at which point the modem seemed to go to sleep.  My version of
     Racal-Vadic support (inserted into version 4.2) works.  As I told
     Herm, by reading his code, I couldn't see why his shouldn't work.
     It did use the input buffer flushing routine (which was a no-op
     under 4.2's Vax bsd version) whereas my code does reads, but I
     modified the 4.2 buffer flushing routine to actually do something,
     and that didn't seem to help.

[Ed. - Herm's away for the month, and I don't have a Racal-Vadic modem to
fool with.  If you or anyone can offer code that works, please send it in!]

4.   Sending a binary file to C-Kermit often doesn't work. This isn't
     new with version 4C.  I've been trying to track it down in version
     4.2.  Though it isn't entirely new, as you can see below, the
     variety of behavior has become richer.

[Ed. - Same problem with zchout().]

That's the C-Kermit bug picture as I see it.  Unfortunately, I won't be
able to pursue them further, in the immediate future.  Other deadlines
approach, you understand.  For the time being, I think we'll continue
using version 4.2.  It has fewer bugs which impact us.

[Ed. - Thanks for the quick report.  We've fixed (I think) all but the
Racal-Vadic modem support problem.  The new files are in <CKERMIT> as
CKCFN*.C, CKUFIO.C, CKVFIO.C, CKMFIO.C, CKCPRO.W, CKCKER.H, CKCMAI.C, and
CKMKER.HQX (and .RSRC) available from CU20B via anonymous FTP.  Some
reorganization was required to fix bug number 2, and it has not been tested
in the VMS version.  Again, everyone who's interested please take these
files away and try them out and report back whether they work on all the
various systems and machines.  Once the major kinks are out, C-Kermit v4C
can be added to the normal distribution -- tapes, okstate (see below), etc.]

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

Subject: Kermit Distribution Available via Kermit Server
Date: 10 May 85 12:03:41 CDT (Fri)
From: Mark Vasoll <[e-mail]>

    We have set up a specialized version of the C-Kermit server that
will allow access *only* to the Kermit Distribution area on our system.
This service will be sharing the phone line with the UUCP account, so the
line will probably be busy quite a bit.

    Anyway, access to the Kermit Distribution area is now available
using the following dialing/login information:

              UUCP                                  KERMIT SERVER

     Phone:   [phone]                 Phone:   [phone]
Login name:   uucpker                   Login name:   kermsrv
  Password:   thefrog                     Password:   piggy

The UUCP distribution will function as before.  The KERMIT SERVER login
will drop you right into a conversation with the server.  The best place
to start after logging on is "REMOTE HELP", followed closely by "REMOTE DIR".

Mark

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

Date: 13 MAY 85 11:12-EST
From:  [e-mail]
To:  info-kermit@cu20b
Subject: CHANGE OF KERMIT-11 UPDATE PROCEDURE

This to announce that Kermit-11 updates should now be obtained from  the
University  of  Toledo's  VAX  11/785 instead of the PDP 11/70, which is
being removed from service. The dialup  number  for  the  VAX  is  (419)
537-4411.  The  front  end is a Dual PACX 4, which will autobaud on a CR
and then prompt for 'Service Class ', which is VX785A. The VMS  username
is  KERMIT  with  a password of KERMIT. All source files are in KER: and
Kermit-11 binaries are in KERBIN:. Please note that  the  VMS  Kermit-32
server  should  be  set to FILE TYPE FIXED in order to transfer any .SAV
or .TSK files.  This also means that a Kermit-11 getting  files from the
VMS server should have SET FIL BIN set for task and save images.

                                                brian nelson
                                                [e-mail]

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

Date:  Thu, 9 May 85 21:58 CDT
From:  "David S. Cargo" <[e-mail]>
Subject:  Computer Vision

Does anybody out there have a version of Kermit working for Computer
Vision computer aided design systems?

David S.  Cargo (Cargo@HI-Multics)

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

End of Info-Kermit Digest
*************************
-------
14-May-85 19:36:33-EDT,7039;000000000000
Mail-From: SY.FDC created at 14-May-85 19:36:08
Date: Tue 14 May 85 19:36:08-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #27
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue, 14 May 1985       Volume 2 : Number 27

Departments:

  C-KERMIT 4C -
    C-Kermit 4C Bugs (Still)
    Missing File for C-Kermit VMS Make Procedure
    VMS C-Kermit 4C Works
    LCK files, parity, "backing out", aborting FINISH, make errors

  MISCELLANY -
    VM/CMS Kermit 2.00 vs IBM 7171
    MSTIPRO Kermit with Internal Modem and TEK-4010

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

Date: Tue, 14 May 85 16:15:21 pdt
From: [e-mail] (Dave Tweten)
Subject: C-Kermit 4C Bugs (Still)

I just finished getting the changed source files you recommended in the
latest digest, and rebuilding on both a 4.2 bsd Vax and a System V
Vax.  I retested for the "rem dir"-hangs-on-NAKs problem.  It's still
there.  I used the bsd Vax as the local Kermit, and the System V Vax as
the remote.

[Ed. - Dave reports the other problems fixed for these systems -- binary
files transfer ok, etc.  But sending any "remote" command to the C-Kermit
4C server on the System V VAX times out.  The 4.2bsd VAX C-Kermit 4C server
handles "remote" requests just fine, no matter what system they come from,
even from itself.  Anybody who can figure this one out will be a hero.]

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

Date: 13 May 85 14:05 EDT
From: (David H M Spector) <[e-mail]>
Subject: Missing File for C-Kermit VMS Make Procedure

I found a problem with the distribution kit for C-Kermit. The VMS
com file called "ckvmak.com", which becomes "CCMAKE.COM" is a copy
of ckver.com,  the 'makefile'.  Attempting to run the make file will
cause lots of errors as the com file goes into an endless loop.

                David Spector
                NYU/acf Systems group

[Ed. - Sorry!  The correct file is now installed as <CKERMIT>CKVMAK.COM,
available via anonymous FTP from CU20B.]

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

Date: Tue, 14 May 85 13:04:15 EDT
From: [e-mail] (Stew Rubenstein)
Subject: VMS C-Kermit 4C Works

Seems to work OK;  I have not tested it extensively, but things mostly
work.  There are some problems with file name canonicalization (it doesn't
strip off version numbers before sending).  This is with the new modules
announced Monday.

[Ed. - Thanks, Stew.  I'm glad I didn't break your code too badly...]

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

Date: Monday, 13 May 1985 13:26:55-PDT
From: [e-mail]  (Dan Schullman)
Subject: LCK files, parity, "backing out", aborting FINISH, make errors

    Is it possible to clear the LCK* files on an interrupt?  When
    I accidentally leave the line as a "modem" line and can't open
    it, an interruption leaves the LCK* file for the line around.

Yes, and it is done in many cases -- e.g. when ^C is typed, when various
fatal errors occur -- the program goes through doexit(), which is supposed
to clear any lock file.  But some other interrupts are not presently caught,
and some can never be (e.g. if the process is killed from another process,
or the system crashes).  I agree this is an area that needs improvement.
The new manual (CKUKER.DOC) discusses the perils of lock files in greater
detail than the previous one did.

    I had trouble copying a binary file (but not a text one), and
    thought it was a KERMIT 4C/4.2 incompatability.  Eventually
    turned out to be a parity problem.  I don't understand why
    text files copy okay but binary ones don't.  I thought KERMIT
    "packaged" the transmission so that only ASCII graphics would
    be used.  Both "ends" were set for the same parity ("none"),
    and as stated I WAS able to copy text files.

This should be fixed in the current (circa Monday, May 13) release of
version 4C of the program.

    There seems to be some interactions with quoting from the command
    line.  For example, try:
        ! echo "this should \07 ring"
    Even escaping the backslash doesn't help.

This will have to be looked at.  Meanwhile, you can always use a real
control-G in the string -- it works both in shell commands and in Kermit's
own echo command.

    Is there a way to "abort" questions if one has "gone down the
    wrong path"?  For example, if one has answered the "from file"
    question and wants to get out of the "to file" question.  I
    tried EOF (Control-D) but that didn't work.

Currently no, short of typing Control-C, which gets you out of the program
entirely.  This too will have to be looked at.

    I often "hang" trying to do a FINISH, BYE, etc.  Is there a way
    to abort these operations without exiting KERMIT?  As mentioned
    in previous mail, this is sometimes because the remote server
    has returned to command mode for some unknown reason.

Currently, there is no way to "abort" a protocol operation before data packets
start to flow, short of typing ^C.  This is true of most Kermits.  Macintosh
Kermit is an exception.  Unix Kermit will have to have a more powerful
interrupt facility added to it to fix this and several of the other problems
you've mentioned.

    In building KERMIT on a SYS-V VAX, I got the following in addition
    to problems caused by multiple includes of types.h by ckxunx.h.
    "ckuser.c", line 916: warning: illegal combination of pointer and
         integer, op =

These problems should be fixed in the current release.

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

Date: 14 May 1985 0954-EDT
From: LCG.KERMIT@DEC-MARLBORO
Subject: VM/CMS KERMIT 2.00 vs IBM 7171

I installed CMS kermit on our 3032 system that uses a 7171 front-end.
I had to comment out two lines to get everything to work.  At
OKDEV - 3, remove 2 lines:

*    clc    cons772,temp
*    bne    baddev

After that change, everthing worked.

Thanks to Columbia for another great version,

Wade Missimer
Abbott Labs

[Ed. - Thanks; this hint has been added to the CMSKERMIT.BWR file.]

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

Date: Thu 9 May 85 21:41:48-EDT
From: Joe Smith [phone] <[e-mail]>
Subject: MSTIPRO Kermit with Internal Modem and TEK-4010

In reference to Richard Berke's questions, 3-May-85.

1) The file KERMIT:MSTIPRO.HLP on MARKET tells how to use the internal modem
   on a TI Professional.  This functionality was added before version 2.27
   was released, but appearantly did not make it to VERSIONS.DOC.

2) The Tektronix emulation is for line drawing only.  Since the system I
   developed it on drew labels using pen strokes, no attempt was made to
   make the alpha cursor track the graphics cursor.

3) Full HEATH-19 emulation is being added.  The new maintainer is:

    Dan Smith    [phone]
    Colorado School of Mines
    Computing Center
    1500 Illinois Street
    Golden, CO 80401

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

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

-------
16-May-85 19:58:58-EDT,25017;000000000000
Mail-From: SY.FDC created at 16-May-85 19:58:30
Date: Thu 16 May 85 19:58:30-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #28
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu, 16 May 1985       Volume 2 : Number 28

Departments:

  C-KERMIT 4C -
    C-Kermit 4C Changes
    Problems with the V7 version of C-Kermit 4C
    C-Kermit 4C for 2.9bsd/xproc
    C-Kermit 4.2 OS9/68000, First Implementation Report
    C-Kermit File types, file transfer problems
    UNIX Kermit 4C Comments

  MISCELLANY -
    New mackermit--double-clicking on a saved settings file
    Re: New mackermit--double-clicking on a saved settings file
    Kermit hangs on bye/finish
    Re: Info-Kermit Digest V2 #27
    Using Kermit to back up your micro's hard disk
    Update on the OK State Kermit Server
    Kermit for TI-990?
    HP Portable (HP110) Kermit?

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

Date: Thu 16 May 85 19:36:17-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: C-Kermit 4C Changes

A few changes have been made to C-Kermit 4C to solve some of the recently
reported problems.  The new files are in <CKERMIT>*.* on CU20B, available via
anonymous FTP.  The biggest modification changes the way the program determines
whether it's in local or remote mode.  Rather than just comparing strings,
which doesn't work in many cases, the program now asks the system.  This should
allow C-Kermit to function correctly in remote mode when invoked by a user
logged in on the "back port" of a workstation (like the Pro-350/380 under
Venix) which is normally used from its console in local mode.  Some other bugs
concerning "set line" were fixed at the same time -- the program now puts the
speed back to -1 when going from local to remote mode; it no longer erroneously
sets the tty name string when the desired line can't be opened (e.g. because
"Permission denied").  These changes affected many modules, because the calling
convention to ttopen() had to be changed.

The following messages mention other bugs and fixes in today's version of the
C-Kermit files.  Note that the problem reported by Dave Tweten that the
C-Kermit server on System V systems does not respond to "remote" commands
(other than "remote help") has not yet been fixed; Dave is still trying to
track it down.  On the other hand, only Dave has complained about this.  Are
there other users of C-Kermit 4C under System V that are also experiencing this
problem?  Are there any who aren't???

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

Date: Thu, 16 May 85 15:41:27 edt
From: randy@nlm-vax (Rand Huntzinger)
Subject: Problems with the V7 version of C-Kermit 4C

I had some difficulty getting the C-Kermit 4C to compile and run on our Codata
Version 7.  Here are the diffs of the ckutio.c file and the Makefile which I
ended up using.  The main problems were:

    1.    The absence of the xproc variable definition.
    2.    The nlist stuff had to be changed for our system.
    3.    A bit of fluff in the makefile.

We have a binary license, so I didn't have direct access to the name of a
variable which is a pointer to the proc table, so I had to use the address of
the proc table (which I knew from the bit of source we have to be called proc).
I also had to change the name of nproc for our version 7.  Yuk, there has got
to be a better way.

Also, why is makefile in the object list for making "wermit"?  It seems that
this would crash every make for any kind of system.

[Ed. - Oops, a mistake, now fixed.]

Here are the diffs I used.
                        Rand Huntzinger
                        randy@nlm-vax
[Ed. - Diffs omitted.]

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

Date:     Thu, 16 May 85 16:29:36 CDT
From:     Gregg Wonderly <[e-mail]>
Subject:  Re:  Problems with the V7 version of CKermit 4C

    What Randy did looks reasonable.  Seems that there is some difference
in whether his "_proc" value is the address of a pointer to the proc array,
or the address of the array itself.  Anyway, this situation makes it get
real hairy when you don't have the source I suppose.  On our system, the header
file <sys/proc.h> has the definiton of what "_proc" or "proc" really is.  I
put the documentation in the MAKEFILE for this reason.  Damn I wish someone
would choose a standard version of UN*X and use it.  Maybe SYS5R2 will help.
As soon as we get what Randy has off of your VAX, I will add a good solid
description of what is really happening, and the possible exeptions.  Maybe
this will clear some things up.  Go ahead and add his diffs to ckutio.c.
They will probably be necessary on some systems.

[Ed. - Randy's diffs added to ckutio.c.]

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

From: Paul Graham <unr70!unrvax![e-mail]>
Date: 15 May 1985 1011-PDT (Wednesday)
Subject: C-Kermit 4C for 2.9bsd/xproc
Cc: [e-mail]

Our version of the 2.9bsd <sys/proc.h>:

/*    $Header: /usr/include/sys/RCS/proc.h,v 1.2 85/01/17 11:31:30 root $ */
/*    $Log:    proc.h,v $
 * Revision 1.2  85/01/17  11:31:30  root
 * Distribution version, RCS integrated
 *      */

indicates that the struct xproc has been superseded by the union p_un.

This is an informational message at this time.  If time permits we may
undertake the changes to ckutio.c.  However after short reflection it seems
this may require a -D for 2.9 as well as V7.

Paul Graham 702/784-6007
University of Nevada Reno
UUCP (seismo, ucbvax!menlo70)!unr70!unrvax!pjg ARPA unr70!unrvax!pjg@seismo

[Ed. - Maybe the changes added above for V7, which seem to address this
proc business, might help.  In any case, any changes to make C-Kermit
actually work under 2.9bsd would be most welcome, the sooner the better so
that 4C can become the real, distributed version.  If anyone wants to help
these folks out, don't hesitate to volunteer!]

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

Date: Wed, 15 May 85 19:21 MET
From: Matthias Bohlen <[e-mail]>
Subject: C-Kermit 4.2 OS9/68000, First Implementation Report

These are the first things I noticed when trying to compile
C-Kermit 4.2 on my OS9/68000 system. If I only had time...

1.   I wrote a new makefile, because OS9 "make" is different
     from UNIX "make".

2.   Form feeds had to be eliminated (C compiler reports
     errors), back-slash for line continuation was accepted
     by the C preprocessor.

[Ed. - Presumably these can be removed by a filter in the os9 makefile?]

3.   I shortened many strings in ckmain.c, ckusr2.c

[Ed. - So have we in version 4C.]

4.   Possible programming error found in ckcmd.c (line 959,
     deals with word-delete):

         *bp++ == NUL;

     as a single statement has little effect (68000 C gives
     a warning message here), but "*bp++ = NUL;" would be an
     erroneous cure, if bp<cmdbuf after the preceding for-
     loop! I suggest:

         bp++;

[Ed. - Thanks.]

5.   Strange construct (similar to 4.) in ckuser.c:
     "*xargv++;" as a single statement; what is intended?
     Maybe only xargv++, but maybe "(*xargv)++" ?
     My compiler gives a warning here (same as 4.).

[Ed. - Thanks again -- it should be simply argv++.]

6.   Return value type mismatch in ckuser.c:
     "return(sstate);" returns a char as a default "int"
     result of "parse". Similar situations in ckfns.c and
     ckfns2.c. My compiler gives a warning here.

[Ed. - I don't think this does any harm since sstate will never be set to
a value that can be sign-extended as a result of char/int conversion.]

7.   Strange construct in ckuser.c:

        if (x = (cmcfm()) < 0) return(x);

     My compiler gives a warning here: "possible degenerate
     assignment in test". Hope, it performs the assignment!
     There are similar constructs in ckusr2.c and ckusr3.c.

[Ed. - Thanks, should be "if ((x = cmcfm()) < 0) return(x);".]

8.   ckusr3.c: Expressions with little effect:

        turnch == y;
        *s2--;

     both as single statements. Again the question: What is
     intended?

[Ed. - Again, thanks.  Changing to "turnch = y" allows the "set handshake"
command to work as advertised.  Before, it always set the handshake character
to XON, no matter what your command said.]

9.   ck?unx.c: The whole conditional compilation stuff con-
     fuses me. I think, I'll remove it and write special
     OS9/68k files ckxo9k.c and ckzo9k.c. ckz does not re-
     quire much change.

[Ed. - Good idea.  I suggest using "9" to designate os9-specific files,
as in "ck9tio.c", in the nomenclature of version 4C (in which the file names
were changed).]

10.  ckdial.c and cklogi.c need SIGALRM (undefined in all
     OS9/68000 header files).

11.  Assembler reports errors about the C-generated code,
     if a variable of storage class "extern" is called
     "cc". The compiler gives the name directly to the
     assembler, where it collides with the name for the
     condition code register of the 68000! Really funny!

[Ed. - I assume you can handle this by doing something like "-Dcc=xcc" in
the makefile.]

I have much work to do in the next weeks, so I cannot
continue on C-Kermit for some time, but I keep trying.

Matthias Bohlen <Mattes@Germany>

[Ed. - The changes marked by "thanks" above are reflected in the files
currently in <CKERMIT> on CU20B, available via anonymous Internet FTP.
The files also include some other minor changes, noted below.

Please send reports to Info-Kermit regarding either problems or success
building and/or running C-Kermit version 4C under 4.1bsd, Xenix, PC/IX, and
other as-yet unreported systems, so that I'll know when the program is
stable enough to be declared a "real" release.  Thanks!]

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

Date: Wednesday, 15 May 1985 05:48:25-PDT
From: [e-mail]  (Dan Schullman  223-7468)
Subject: C-Kermit file types, file transfer problems

    It would be real nice if I could do something like:
        REMOTE SET FILE TYPE ...
    so that as I alternate file types, I don't have to keep
    FINISHing, CONNECTing, and reSERVing in order to change
    the file type.

[I agree.  This would be an extension to the protocol that we'll probably
have to make.]

    Running VMS KERMIT V3.1.66 today with C-KERMIT 4C on
    VENIX V2 FT2 and trying to transfer a binary file on
    a line that VMS thought was /NOEIGHTBIT, I was able
    to send it to VMS okay, but kept getting Q%Q%Q's when
    trying to get it from VMS.  Eventually I told C-KERMIT
    to use "space" parity and that got it working.  Can
    you explain this?  Is this more confusion over number
    of data bits versus parity?

[To get VMS Kermit to work on a /NOEIGHTBIT line, you have to give VMS
Kermit an explicit SET PARITY command.  In your case, telling the opposite
Kermit worked too, because it told VMS Kermit that parity was being done,
and therefore to use 8th-bit prefixing.]

    Yesterday (and previously) while trying to get or send
    text files between KERMIT 4C on a Sys-V VAX and VENIX V2 FT2,
    I had problems with file specifications of "*", whereas
    "*.*" seemed to work.

[I believe that this problem can be explained as follows: The C-Kermit send
command expands its argument into a list of all files that match.  If you give
it the "*" argument, then the list will include the files "." and "..", which
are really directories.  When going through the list, C-Kermit checks each file
to make sure it's readable ("ordinary") using stat(), and it skips files (like
directories) that are not.  The trouble comes in because System V has two ways
of saying whether a file is ordinary, whereas Kermit was only checking one way.
In the file ckufio.c, function zchki() makes the following check:

    x = buf.st_mode & S_IFMT;        /* Isolate file format field */
    if (x != S_IFREG) {
    debug(F111,"zchki skipping:",name,x); /* Not readable */
    return(-2);
    }

System V will also return a 0 for a readable file, so the check should be

    if ((x != 0) && (x != S_IFREG)) {

This change is in the latest CKUFIO.C in <CKERMIT> on CU20B.  System V
experts, please speak up if there is a better way to do this!]

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

Date: 15 May 1985 1059-EDT
From: LCG.KERMIT @ DEC-MARLBORO
Subject: UNIX Kermit 4C Comments

A few remarks on Kermit 4C, which I downloaded from Market and compiled on my
Masscomp RTU 2.2 system.

1) using the "make sys3" command, the 4C kermit appears to
   work just fine on my Masscomp, no problems encountered so
   far, but all I've really tried is the "connect" mode,
   and ascii/binary file transfers to/from a DEC-20 and a VAX.
2) The new Kermit works just fine with my Racal-Vadic modem, contrary
   to what was indicated in the latest Digest?  Maybe the problem
   is in the bsd vs. sys3 compilations?
3) The only peculiarity I noticed with the new version so far is
   if I "set modem-dialer racalvadic" and then do a "show parameters",
   it still lists the modem-type as "direct" rather than "racalvadic",
   even though the "dial" command works fine?  If I set the modem
   type to something else, e.g. "hayes", and do a "show parameters",
   then the modem-type is reported as "hayes".  A bug somewhere,
   but certainly minor.

[Ed. - Code has been added to the "show command" to know about the
various modems, in <CKERMIT>CKUUSR.C on CU20B.]

Here in this building at Ford we have a DEC-20, a dozen or so
Masscomp's, about 40 assorted PDP-11's, several IBM PC's, about
50 Victor's, 2 VAX 780's, 5 VAX 730's, two Prime's, 3 Apollo's,
and several Computervision systems.  We have Kermit installed
on most of these systems and find it quite adequate for low-volume
file transfers.  Best of all, it's free!!  Keep up the good work!!

[Ed. - Which Kermit are you running on your Victors?  It would be a
great help if someone could make the necessary system-dependent modules
for MS-DOS Kermit to support the Victor, so we could discard some of
the hokey old versions that are now in use.]

        Steve Kaberline
        Ford Motor Company
        Scientific Research Labs, room S-3061
        P.O. Box 2053
        Dearborn, MI  48121
        [phone]

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

Date: Wed, 15 May 85 17:15:41 EDT
From: edwards%h-sc4@HARVARD
Subject: New mackermit--double-clicking on a saved settings file

It complains that it can't find an application to open.

                Bill Edwards
                Harvard Arts and Sciences
                Computing Services
[Ed. - See answer below.]

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

Date: Wed 15 May 85 21:28:59-EDT
From: Bill Schilit <Sy.Bill@CU20B>
Subject: re: New mackermit--double-clicking on a saved settings file
To: edwards%h-sc4@HARVARD

The problem is that either the bundle bit is not set in the kermit
application or the creator is not set to KERM -- or both of these.

If you downloaded your kermit application from the RSRC file then
you will need to set these values using the set file utility.  This
is outlined in the doc file that comes with the distribution.

You should be seeing two different icons, one for the settings file
and one for kermit itself.  If you don't see these then you need to
run setfile.

- Bill

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

Date:     Wed, 15 May 85 11:47:10 CDT
From:     Gregg Wonderly <[e-mail]>
Subject:  Kermit hangs on bye/finish

    In the latest info-kermit, I noticed some talk about kermit hanging on
a bye or finish command.  We had this problem talking to the VMS KERMIT on
our 11/780.  The problem seems to be that the server gets the bye/finish
packet ok.  It then sends an ACK.  Immediately following this, the program
terminates.  At slow baud rates, we believe that the system does some clean
up and buffer flushing before the entire packet gets sent.  This tends to
keep the entire packet from being sent.  Might be wise to get some of the
authors to put "sleeps" into the code where applicable.

[Ed. - C-Kermit has the appropriate sleeps.]

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

From: dual!ptsfa!abm@Berkeley
Date: Wed, 15 May 85 13:50:36 pdt
Subject: Re: Info-Kermit Digest V2 #27

RE: Kermit CMS & Sim3278 & Profs & PCdos Kermit 2.26

I have been using PCDOS Kermit to access PROFS with moderate success.  We
have just installed a major LAN & related network facilities that
allows a large group of users who were using Simware's AZPC2 @ 1200 baud
to move up to 9600.  Unfortunately, AZPC2 is written in basic ... and you
can guess the results at the higher line speed.  I am hoping that this will
provide an opportunity to overcome "not a supported product" phobia on a
large scale, because I don't think anything but kermit can satisfy all our
requirements in the near term.

Here are the questions/problems:

1. One requirement is the ability to download/upload from the PROFS (read
3270) environment.  This presently doesn't work because CMS release 1.0
supports only tty terminals.  Does release 2.0 use standard 3270 calls,
or does it talk specifically to the Series 1/Yale package?  What are the
odds 2.0 will work with Sim3278 and how much work do you think it will take?

[Ed. - It talks specifically to the Series/1 Yale package.  CMS Kermit will
not work with an unmodified Sim3278, but if you have source, you can modify
Sim3278 to accept the same escape codes for entering "transparent mode" that
the Series/1, 7171, and 4994 accept.  Making Kermit work over 3270-like
connections in general is a much harder problem, requiring major extensions
to the Kermit protocol itself.  This was discussed at some length in
Info-Kermit Digest V1 #11, June 84.]

I am assuming that you know more about Sim3278 than I know about the Yale
package.  Sim3278 runs on the VM host as a "diconnected process" (I think
that's the terminology), so we come through the Comten front ends like
normal async terminals until we get to CP and "dial sim3278".

2. I am using vt52 emulation under Sim3278.  I have done 'set key ~' for my
functions, etc. but since local echo is on, the escape sequences garbles
the screen.  In order to get around this problem, I plan to install the
following kludge:
    module: msyibm.asm @ trnou2:

    if the first byte of the macro sequence is a sentinal (probably 0ffh),
    check if local echo is on, and, if so, turn it off and set a flag.
    Check the flag after sending the macro, and, if on, turn local
    echo back on.  (I also plan to include a second sentinal to allow
    a macro starting with a sentinal to be echoed -- I don't know why
    you would want to do this, but its best not to fool with mother
    nature (or Bell or Blue or ...).)

I think this can be done with 20 or so statements in this one function.
Please let me know if you think there is a better way to handle this.  I
will send you the code fragment when it is working.

[Ed. - No need to add code to MS-Kermit; this is addressed by Sim3278 code
already -- each terminal definition has a flag indicating whether a
character is left by hitting a function key; if so, Sim3278 will erase it
after CR is entered.]

3. I don't have a good environment to test kermit at 9600 baud.  My limited
testing looks OK.  Do you anticipate any problems?

[Ed. - No.]

4. Sim3278 doesn't support highlighting for the vt52 (bless their hearts),
which makes PROFS' calendar system unusable (not quite everyone considers
this an improvement).  We probably have the clout to get this fixed on
our own, but do you happen to know of any easy answers.  I don't know
much about VM, and at this point our support people are very supportive
about solving kermit problems ... but thanks to them I'm starting to get
"good" at vm/cms.

[Ed. - The Heath-19 emulation in IBM PC MS-DOS Kermit will have highlighting
in the next release, 2.28, coming soon.]

I hope I haven't overloaded you with questions.  Any guidance you can
provide will be greatly appreciated.

Al Margolis
Pacific Bell, 120 Montgomery Street, Room 330, San Francisco, Ca. 94104
ihpn4,dual!ptsfa!abm

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

Date: Wed, 15 May 85 18:04:54 edt
From: xp!tony@nyu-cmcl2 (Tony Movshon)
To: [e-mail]
Subject: Using Kermit to back up your micro's hard disk

Since the prospect of backing up even a modest (10 mbyte) hard disk onto
floppies is unpleasant, I have taken to using Kermit for backups. I use a
Rainbow (MS-DOS 2.11, MS-Kermit V2.27) and a VAX 750 (4.2BSD, C-Kermit, now
version 4C), hooked over a 9600 baud line. Backing up the (full) hard disk
takes about 8 hr, and can comfortably be done overnight. This process
worked just fine after I made one small change in MS-Kermit.

As you will realize, the most convenient way to handle this particular
backup is to make an image of the MS-DOS directory tree at the Unix end,
and to make a giant MS-DOS batch file using local "cd" commands and
MS-Kermit "remote cwd" commands to move stuff. That is, the process
involves

  o Building (manually) a copy of your micro's hard disk directory tree at
    the Unix end,
  o From the top of this tree running C-Kermit (with file type binary) as a
    server, and
  o Using the command-line control available in MS-Kermit by means of a big
    batch file that looks like

    cd \
    mskermit send *.*
    cd dir1
    mskermit remote cwd dir1
    mskermit send *.*
    cd ..
    mskermit remote cwd ..
     ...
    and so on through the tree until
    mskermit finish

    Building the batch file is much eased by having a program like "tree"
    to lay out all the directory names. It is in any case easier than just
    sitting for an hour changing floppies every 3 minutes.

You will realize, however, that the impediment to all this is the fact that
the "remote cwd" command in MS-Kermit demands a password for the new
directory and will not accept input from a batch file for that purpose.
This may be a limitation in the protocol, but it seems to me that "remote
cwd" should request a password only if the other Kermit demands it (Unix,
of course, does not password-protect directories).

To solve this problem, I simply removed the code in MS-Kermit that requests
and processes the password. This is easily done, although the code is not
in front of me so I don't remember exactly where it lives. Perhaps there
should be an option in future versions of micro kermits to omit the
password request (or two commands: "remote cwd" to skip password, "remote
cwdp" for password-based systems).

In any case, backing up this way is a pleasure beyond words compared to the
bad old days, and I commend it as YACUK (Yet Another Creative Use of Kermit).

Tony Movshon

[Ed. - The next release of MS-DOS Kermit will fix the Password prompt and
input to work the same way as the rest of the command parsing, so that the
REMOTE CWD command will be usable from batch files and Kermit command files.]

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

Subject: Update on the OK State Kermit Server
Date: 15 May 85 11:19:26 CDT (Wed)
From: Mark Vasoll <[e-mail]>

I have notice some people (already) having problems with getting our server
to talk to them.  The problem is that they *must* use EVEN parity due to a
limitation of our communications equipment.  Sorry I forgot to mention this
earlier....  UUCP bypasses this limitation in a rather gross way with which
I will not clutter up the C-Kermit code.

I also forgot to mention that when people issue a REMOTE DIRECTORY command
on our system, they should be prepared for more than 600 lines of output.
It is usually better to read the 00README.TXT file (using REMOTE TYPE
perhaps) and then do the REMOTE DIR with some kind of wildcard (like
"REMOTE DIR ck*").

Mark

[Ed. - The file KER:OKSTATE.TXT now contains an up-to-date summary of how
to get Kermit files from Oklahoma State U using either UUCP or Kermit.]

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

Date: Wed, 15 May 85 11:55:23 cdt
From: ihnp4!umn-cs!ncs-med!bi@Berkeley (Bob Isch)
Subject: Kermit for TI-990?

Does anyone have a version of kermit available for TI-990 mini-computers
running DNOS or DX10?  Any pointers or ideas would be helpful.  Thanks, -bi

Bob Isch                      -bi [phone]   ihnp4!umn-cs!ncs-med!bi

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

Date: Tue, 14 May 85 19:08:42 pdt
From: Todd H. Ogasawara <ogasawar%cod@Nosc>
Subject: HP Portable (HP110) Kermit?

Is there a Kermit for the HP Portable (aka HP110) lap portable?
Thanks in advance for any leads?


Todd Ogasawara, Computer Sciences Corp.
NOSC-Hawaii Laboratories
UUCPmail: {akgua,allegra,decvax,ihnp4,ucbvax}!sdcsvax!noscvax!ogasawar

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

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

-------
17-May-85 18:35:52-EDT,11036;000000000000
Mail-From: SY.FDC created at 17-May-85 18:35:13
Date: Fri 17 May 85 18:35:13-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #29
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 17 May 1985       Volume 2 : Number 29

                         Here is HP110 Kermit
              Omnet gives very silly criticism of KERMIT
                        C-Kermit 4C for 2.9BSD
                  Minor Kermit-11 Update On The Way
                    Printing Kermit Docs on X2700?
                          KERMIT for BBS's?

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

Date: Fri, 17 May 85 14:30:34 mdt
From: [e-mail] (Dave Forslund)
Subject: Here is HP110 Kermit

Attached is the file MSXHP110.ASM which is the system-specific source for
MS-KERMIT running on the HP110 Portable.  It should be used in place of
MSXGEN.ASM in making the executable.  We have used this code for about 2
months.  The MSXGEN.ASM file from CU20B was modified by Chuck Aldrich here
at Los Alamos and allows the changing of baud rates and the selection of
the serial port or the internal modem.  However, we have not tested the
internal modem code.  The default setting is the serial port (Port 1) and
9600 baud.

The HP110 does not have built-in Basic, so the .BOO file bootstrapping
technique won't work.  But it does have a built-in terminal program which
can be used to capture a file.  The terminal program also has the XMODEM
protocol built in.  This can be used to capture binary files.

The way we brought the source over was to download it with MS-KERMIT on an
IBM-PC and move the file to the HP110 with the special IBM board that HP
makes which allows the two machines to communicate directly to each other's
disks.  We have also modified the Turbo-Pascal Kermit to run under MS-DOS
on the HP110.  If you have Turbo-Pascal, then you could use it to ship over
the MS-Kermit source, or executable.

David Forslund ([e-mail])

[Ed. - Thanks!  The source file has been placed in the Kermit distribution
area as KER:MSXHPX.ASM, and the above message (plus some parts that were
left out) in KER:MSXHPX.HLP.  Note the strange filename -- Unfortunately,
MSXHP110 is not distinguishable within six characters from MSXHP150, which
was already there.]

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

Date: 16 May 85 13:22 +0100
From: [e-mail]
Subject: Omnet gives very silly criticism of KERMIT

The following very silly and mean criticism of KERMIT was given in a
newsletter called "Sciencenet/news" published by Omnet, Inc., 70 Tonawanda
Street, Boston, MA 02124.

First a picture is given of a princess, frightened by an ugly frog, and
saying the words: "YYYYYUK! You're incompatible!".

Then comes the following text:

    Software of the Month: KERMIT The Incompatible

Trying to adjust to the fast-paced world of micro-computers instills its own
brand of future shock on everyone. What we long for is simplicity and
consistency, byt instead seem to get arbitrary rules and conventions.

Recently, a new group of users, who had been using the public comain
communications software KERMIT, signed on with SCIENCEnet.  They hoped to be
able to continue use this software package, which they had already mastered.
KERMIT is a perfectly good communications package, - providing that you
limit yourself to communicating with other systems which are also using
KERMIT!  And that's where the catch is.

Some communications software packages, KERMIT among them, only allow files
to be sent between computers using the same software.  The advantage is that
it allows for a certain amount of error checking to take place. This is
advantageous because it eliminates problems introduced by bad phone lines
over long distances. (Since calls to SCIENCEnet are local, this isn't likely
to be a problem.)

Many commercial communication packages offer the best of both worlds. For
instance, using a micro software package such as Crosstalk, micro-to-micro
file transfer with error checking over phone lines is possible. But, and
this is the critical point, with most commercially available communications
software packages, it is also possible hook up to SCIENCEnet to talk with
all other systems.

And herein lies the difference: with KERMIT, alas! the package only talks to
other KERMITs; it won't talk to SCIENCEnet -- or anybody else!

--- --- ---

My comment on the above: No file transfer protocol with error correction
facilities will be able to talk to any computer except a computer which
implements the same file transfer protocol.  The only possible way to do
something more would be to write a file transfer program which can switch
between several different protocols, and there is nothing in KERMIT which
forbids such implementations.  Because of its wide acceptance in the
scientific community, KERMIT is however certainly the protocol which has
largest changes of being possible to use between different makes of
computers.

The correct formulation of the above message in "Sciencenet/news" should
perhaps read like this "We have not implemented KERMIT on our computer,
therefore we think KERMIT is bad for you (and us)!".

[Ed. - Thanks for the kind words, Jacob.  The silliest part about the
article is that Kermit is a particular file transfer protocol -- it's not
commercial a product like Crosstalk that may embody several different
protocols -- so of course it's incompatible with other file transfer
protocols.  There are indeed many commercial and public domain programs that
provide Kermit alongside one or more other protocols, usually in conjunction
with a fancy terminal emulator and lots of menus.  In addition, many of the
Kermit programs in the Columbia distribution allow "raw file capture" for
getting files from systems that don't have Kermit; some allow "raw file
transmission" as well.  I wonder what system SCIENCEnet runs?  Kermit is
available at last count for about 120 machine/operating system combinations.]

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

From: Paul Graham <unr70!unrvax![e-mail]>
Date: 16 May 1985 1713-PDT (Thursday)
Subject: C-Kermit 4C for 2.9BSD

Ok, when I first sent in the report on the 2.9 problem I was in debug mode
and hadn't looked at ckutio.c from a global perspective.  I have since, and
understand the initrawq() stuff.  It is completely unecessary in 2.9 which
has the same tty-i/o as 4.2.  So unless someone else is looking at the
problem I will convert the 2.9 version to use 4.2 style i/o (FION etc.).
This still may require a change to the makefile (which I had no problems
with BTW).

PS - The proc table is the in-core table of process info, which can be
examined in V7 to find out how many characters are in the input queue
(yuck).

[Ed. - I guess this means we'll soon have a BSD29 conditional, which takes
the BSD4 path for tty i/o and the V7 path for everything else.]

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

Date: 17 MAY 85 09:40-EST
From:  [e-mail]
Subject: Minor Kermit-11 Update On The Way

A minor update of Kermit-11 will be sent to Columbia on 20-May.  It fixes a
problem in requesting 8bit quoting with parity, minor TSX+ problems again
(fixes thanks from Ned Rhodes), and a couple of new SET options to control
file creation superceding and determination of 'binary' files. As soon as I
put P/OS back on my pro and test it this weekend I will send it along. This
is the version that will be on all the SIG tapes at spring Decus.

Meanwhile, updates can be obtained as described earlier from my 11/785 via
either UOFT01 KERMSRV (bitnet) or the dialup procedure stated last week.

                                                        brian nelson

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

Date: Fri, 17 May 85 11:13:11 EDT
From: poole@NUSC-ADA
Subject: Printing Kermit Docs on Xerox 2700?

Does anyone know of or have public domain fonts for the XEROX 2700II laser
printer?  The Kermit docs  don't format properly with a 10 cpi font, which is
all we have.  We will be ordering more fonts form XEROX, but the internal
paperwork takes a couple of months.  Thanks for your time,
 Ken Poole
 401-841-2648.

[Ed. - Maybe this question should be sent to Laser-Lovers.  I thought that
the Scribe device drivers provided by Unilogic for any particular device
supported the minimal font set for that device and did not require you to
have any special fonts.  If the Kermit docs don't format properly with the
fonts you have, maybe your Scribe database is messed up -- wrong width
information, for instance.  By the way, at Columbia we print our Kermit
manuals and other Scribe MSS files on the Xerox 9700 in Univers10 font, on
the Imagen LBP-10 with CMR10, and on various less interesting devices --
lineprinters, Diablos, plain text for online doc files, etc -- with very
little trouble.  Of course, the fancier the device -- and the Scribe support
for it -- the better the results.  This brings up a related question: why do
we use Scribe, rather than, say, a public-domain formatter like TeX?  The
reason is simply that TeX can not produce plain text doc files for online
reading or for printing on ordinary terminals and printers.  Scribe is
widely available (implementations exist on DEC-10/20's, VAXes (UNIX and
VMS), IBM mainframes, etc), and Scribe-like formatters are also included
with various microcomputer word processing systems like Final Word, Perfect
Writer, etc.]

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

Date:     17-MAY-1985  14:58 EST
From:     [e-mail]
Subject:  KERMIT for BBS's?

Has anyone implemented KERMIT in an electronic BBS ? We would be interested in
obtaining a copy.  Here at IUPUI we have an BBS that is written in BASIC, and
runs on an IBM PC-XT and uses XMODEM.  Since we are giving KERMIT programs away
free we feel it would be nice if our BBS also allowed file transfers using
KERMIT.

Jim Griffin
Microcomputer Systems Group
IUPUI
799 W. Michigan  ET-1023
Indianapolis,  IN  46202

Incidently, we use KERMIT on all our mainframes and are very pleased with its
operation.

[Ed. - The only one I know about is FIDO, which supports Kermit, Modem7,
Xmodem, and some other protocols, and provides electronic mail via FIDONET,
using dialup between nodes at prescheduled times.  FIDONET mainly runs on
MS-DOS systems (like the DEC Rainbow, the IBM PC family, etc). The
FIDO-related files are available on ARPANET from SIMTEL20 via anonymous FTP
from the directory MICRO:<CPM.FIDO>; if you don't have FTP access to
ARPANET, I can't say how to get them, but you can mail to Douglas Good or
Scott Aschcraft, [e-mail] (FIDO SYSOPs) for more
information.]

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

End of Info-Kermit Digest
*************************
-------
27-May-85 19:35:57-EDT,27690;000000000001
Mail-From: SY.FDC created at 27-May-85 19:35:29
Date: Mon 27 May 85 19:35:29-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #30
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Mon, 27 May 1985       Volume 2 : Number 30

Departments:

  C-KERMIT VERSION 4C -
    More Changes to C-Kermit Version 4C
    File Sizes Reported by C-Kermit
    C-Kermit v4 to Apollo
    C-Kermit 4C Comments/Bugs
    C-Kermit on TRS-Xenix
    Kermit 4C Broken "Dial" Command for PC/IX 1.1
    C-Kermit 4C (16 May) Local-Remote Bug?
    Status of 4C on 2.9bsd
    Wart Mods
    C-Kermit for Eunice

  MISCELLANY -
    Lisp Machine KERMIT
    Kermit-11 BITnet Distribution: Correction
    IBM PC/AT Serial Port Compatibility
    AT Serial Port Compatibility
    IBM Asynch Adapter at 19.2Kb and Beyond
    Appeal to the Netherlands
    Kermit for IAS?
    IAS AND KERMIT
    Need Help with Kermit-TSO and 7171
    Converting New VM/CMS Kermit to MVS/TSO?
    Kermit for the NorthStar horizon and USR S-100 modem.
    Formatting documentation for Xerox 2700
    Commodore 64 Kermit Diskette Availability
    Kermit for Wang VS or OIS?
    Two Faces of Kermit

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

Date: Mon 27 May 85 16:41:12-EDT
From: Frank da Cruz <[e-mail]>
Subject: More Changes to C-Kermit Version 4C

Quite a few minor changes have been made to the working (but not yet really
released) copy of version 4C of C-Kermit.  The major functional change is
that several of the 'set' parameters have been separated into 'set send'
and 'set receive' pairs to allow inbound and outbound packet parameters to
be set separately.  Some changes have been made to the command parsing
functions -- the major result is that the multiline local-mode 'get' command
now works as advertised, and in addition can be escaped from if you change
your mind in the middle of it.  Many minor bugs were fixed, some of which
are reported in the messages below.

Reportedly, problems still exist on ATT System III and System V based
systems in the areas of dialing, modem control, and so on.  A special "3bx"
makefile option was added for ATT 3B-series systems to accommodate their
special handling of uucp lock files.  Users of these System III/V systems
are encouraged to try out the new files and report problems (and fixes?), so
we can finally make version 4C "real".

The files are on CU20B, in <CKERMIT>CK*.*, as of 7:30pm EST 27 May 85.  Only
the Unix and VMS versions have been affected by the recent changes; a new
Macintosh release should be ready shortly.

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

Date: Monday, 20 May 1985 08:26:04-PDT
From: [e-mail]  (Dan Schullman)
Subject: File Sizes Reported by C-Kermit

When SENDING a file, the displayed size of the file being sent is wrong.
It appears that 32kb-->63.99kb, 96kb-->127.99kb, etc. are shown as zero.
And that 64kb-->95.99kb, 128kb-->159.99kb, etc. are shown as ( size mod 64kb ).
The actual size of the transferred file is fine.

[Ed. - The problem is that zchki() returns the size of the file as its value,
but zchki() is not declared to be long.  Also, it uses a regular int internally
to hold the size.  The files ckufio.c, ckvfio.c, ckcfns.c, and ckucmd.c have
been changed to use longs where necessary, so that file sizes will look right
on machines that have short ints.]

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

Date: Sun, 19 May 85 15:48:00 pdt
From: Neal Holtz <[e-mail]>
Subject: C-Kermit v4 to Apollo

I finally got around to doing what I said I would in early March - port
C-kermit to Apollo (Aegis) environment.  I waited for a newer version,
4.2(030).

As of this writing, I have only had it running for a few hours, so obviously
I have a lot of testing to do yet, but early results are very encouraging.
The standard Apollo C-library is very compatible with most Sys III (and some
4.2) -- the only exception is configuring serial lines and the console.  I
probably could have added about 100 lines to ckxunx.c and ckzunx.c, but I
thought they were getting unmanageable with all the IFDEF's, so I made
equivalent ckxaeg.x and ckzaeg.c mostly by ripping out most of the compile
time control.  There were couple of very trivial changes in a couple of
other places, but it went very smoothly.  When I have had a chance to do
more testing, I will forward a few comments.

Currently, the TOPS-20 style command parser is being used.  That doesn't fit
in with the Apollo environment as well as I would like (though it certainly
is usable).  Haven't decide whether I will retain it.  Will probably decide
to do whatever causes the least work and disruption (i.e. retain it).

Will gladly supply my changes to whoever wants them.

[Ed. - The modules other than ckufio (formerly ckzunx) and ckutio (formerly
ckxunx) that need modifications to accommodate Apollo Aegis now have them,
and the Apollo-specific modules will be announced when they arrive.]

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

Date: Wed, 22 May 85 09:55:41 -0100
From: hans@oslo-vax (Hans A. ]lien)
Subject: C-Kermit 4c Comments/Bugs

I had no trouble building v.4c on our vax 11/780 running 4.2bsd unix.
However, i have recognized a few problems / minor bugs.  I must apologize
for not being very familiar with neither unix nor c, so I have no definitive
fixes to offer.  But anyway:

1) It seems as some terminal output isn't printed to the terminal while the
file transfer is proceeding in the background.  As a result, the process
stops waiting for terminal output.

First of all, there are messages of the kind "Warning: ...", which are
printed on stderr. I would very much appreciate that such messages be output
similarly to messages like "filename => FILENAME ...", WHICH come through
nicely.

[Ed. - These messages only appear at the start of a transaction, and they
are generally important enough that you should want to see them -- like,
"Warning, problem getting exclusive access", meaning that somebody else
might be using the same communication line at the same time.  Once the
line is assigned to you, no further warning messages are issued.]

The other problem I have noticed, concerns indication of naks.  They are
indicated by "N", but unlike ".", they demand the process in the foreground
to proceed.  Once again, I think such output should be allowed to a job in
the background.  Hopefully, this works OK if -q (quiet) is set, but I
haven't tried.

[Ed. - I can't reproduce this, nor can I find any code that seems to exhibit
this behavior.]

2) I have recognized a minor error in the Tops20-like command parser, which
results in repetition of default items by pressing several <esc> characters.
Try for example CKermit>log trans<esc><esc><esc><esc><esc>.

[Ed. - It was an error, all right.  It's fixed now.  Thanks for spotting it.]

3) Regarding command line options, my opinion is that a "bye" option should
be included, in addition to, or if the number of options should not grow
further, instead of the "finish" (-f) option.  I think most people use such
an option to end a file transfer session, typically performed with a simple
list of commands making up a script.  Does anyone (dis)agree?

[Ed. - The major restriction on the number of command line options is that
the command line help message should fit on one screen.]

        [e-mail]
        Hans A. ]lien, Institutt for informatikk,
          University Of Oslo, Norway.

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

Date:  Tue, 21 May 85 16:04 MDT
From:  [e-mail]
Subject: C-Kermit on TRS-Xenix

I now have kermit 4C(044) running on TRS-Xenix, a Unix v7 system.
Both startup and file transfer are much slower than with kermit version 3.
The makefile parameters required are:

PROC=_proc
DIRECT=-DDIRECT
NPROC=_Nproc
BOOTFILE=/xenix

A fix was required in ckutio.c.

Robert Mark, USGS, Menlo Park, CA

[Ed. - Fix installed in ckutio.c, and the makefile (ckuker.mak) edited
accordingly.]

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

Date: Tue May 21 1985 14:11:11
From: Marco Papa <[e-mail]>
Subject: Kermit 4C broken "dial" command for PC/IX 1.1

I encountered the following problems with installing and running Kermit 4C
for PC/IX 1.1 on a PC/XT with Hayes compatible modem.

1. Makefile problem.

  PC/IX's "make" does not seem to like \'s to continue lines.
Taking out the \'s at the end of lines, and making one long line, fixes it.

[Ed. - A warning to this effect has been inserted in the .bwr file, but it's
funny we didn't here this one before, especially since a lot of development
was done on a PC/IX system.]

2. Dial feature broken.

  The "dial" command does not work any more.  Executing the following set of
commands:

> set line /dev/tty1
> set speed 1200
> set modem-dialer hayes
> dial 743-0000

will work up to the setting of the modem type.  The dial command ALWAYS
returns with the message:

"Sorry, can't hang up the line"

I have not looked up in ckdial.c yet, but I believe the message comes from
there.  I know that there is no problem with my modem switch settings,
since Kermit 4.2 runs just fine.  Also, since dial does not work, I cannot
test the script command.

[Ed. - This has been fixed.  There are still reportedly problems with DTR
during dialing on some systems.]

3. Lock file left around.

  This is related to the "dial" problem above.  When dial fails, the "exit"
command leaves the lock file around (/etc/locks/tty1 for example), so that
one has to manually delete it, before set line will work again.  The lock
file is correctly deleted on exit, when dial is not executed.

Connect, send and receive seem to work just fine.

[Ed. - The ttopen() code in ckutio has been reworked to be more careful
about leaving lock files around.]

Also, ckuus2.c makes the C optimizer run out of space under PC/IX.

Marco Papa
UUCP:  ...!sdcrdcf!uscvax!papa
CSNET: [e-mail]
ARPA:  [e-mail]

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

Date: Sat, 25 May 85 11:29:07 pdt
From: [e-mail] (David Ragozin)
Subject: C-Kermit 4C (16 May) local-remote bug?

Running C-kermit, 4C (16 May) on 4.2 BSD Unix.
Problem:
    Issue "set file type bin"
    Then  "send file" and on completion do "show para"
        mode now shows as "local" instead of "remote"

Now when I get mode back to remote by "set line", then do a send of a text
file, on return the mode is local.  Apparantly going into binary file mode
flips some flag which controls the mode setting on returns from at least the
send type transaction.

[Ed. - Oops - this bug was introduced into 4C (the 16 May version) and has
just been fixed.  It actually had nothing to do with binary mode.]

(By the way, I could find no way to "document" this via any of the log
functions, since the "session logging" only works for local mode logging
while this bug requires that I record what appears on my screen from a
remote kermit.)

[Ed. - Try "kermit | tee xxx" -- the transcript will go into file xx.  Or use
script on systems that have it.]

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

From: Paul Graham <unr70!unrvax![e-mail]>
Date: 23 May 1985 1218-PDT (Thursday)
Subject: Status of 4C on 2.9bsd

As I suspected in my heart of hearts the transition from the 7th Ed. is not
going to quite as simple as I might have liked.  Currently the 2.9 version
will not act as server or in the remote mode.  Nor will it receive files in
the local mode (it will get a file from a server).

If anybody has solved all of these problems please let me know.  Else
sometime next week it should percolate to the top of the stack, and I should
have some time for it once again.

Please drive carefully.

Paul Graham 702/784-6007
University of Nevada Reno
UUCP (seismo, ucbvax!menlo70)!unr70!unrvax!pjg ARPA unr70!unrvax!pjg@seismo

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

Date: Sat, 25 May 85 18:24:36 cdt
From: [e-mail] (Jim Knutson)
Subject: WART mods

The following are a couple of context diffs for getting wart running on an
MS-DOS machine with the CI-C86 C compiler.  The problems that were fixed
had to do with 1) not ignoring trailing text on #else and #endif 2) Stripping
comments within quotes and 3) not recognizing \f as a whitespace.

[Ed. - diffs omitted, changes installed in ckwart.c.]

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

Date:     Wed, 22 May 85 23:01 EST
From:     Larry Afrin <[e-mail]>
Subject:  C-Kermit for Eunice

I don't remember if I explained this in an earlier message, but Eunice 3.2 is a
hybrid of 4.1bsd and 4.2bsd (with a touch of Version 7 thrown in, from what I
can deduce from how the time-of-day functions work), that runs under VMS.

A new version of Eunice, version 4.0, is coming out "VERY soon", sort of in
conjunction with the brand new release of VMS 4.1.  Eunice 4.0 is reputedly
going to be a full 4.2bsd implementation under VMS.  Now, seeing as how Kermit
4C can be installed under VMS directly, and seeing as how Eunice 4.0 is
supposedly going to be 4.2bsd straight up and down the line, you may want to
defer from adding any Eunice-specific support into the next Kermit version,
which I understand from you will be version 4C.  You may especially want to
avoid using *my* mods since they're meant for Kermit 4.2, which I think you've
indicated is now obsolete, sort of.

                    -- Larry Afrin
                       Dept. of Computer Science
                       Clemson University

lbafrin@clemson                         if you're on CSNet
lbafrin.clemson@csnet-Relay             if you're on ARPANet

[Ed. - I agree with Larry -- Eunice support is probably not worth including.
This is very much the same situation as Amdahl UTS, whose new version is pure
system V, and whose old version is some kind of hybrid.  If anyone is desparate
for Larry's Eunice Kermit, they may want to contact Larry directly.]

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

Date:  Fri, 24 May 85 14:53 CDT
From:  "Mark L. Ahlstrom" <[e-mail]>
Subject:  Lisp Machine KERMIT

I now have the Lisp machine Kermit running "pretty well" on
Symbolics Lisp machines.  I should be shipping it back to George
Carrette at LMI in a couple of weeks to have him retest it on LMI Lisp
machines and incorporate some recent LMI changes.  Hopefully, the first
release to Columbia is within a couple months of being "real".

By the way, your information should be updated to show that the lmkermit
will be written in Zetalisp rather than Common Lisp.  The info that it
was Common Lisp evidently came from an earlier plan that George Carrette
had to develop the code on another machine.
  --Mark

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

Date: 21 MAY 85 10:46-EST
From:  [e-mail]
Subject: Kermit-11 BITnet Distribution: Correction

I just noticed that I said UOFT01 KERMSRV in my note about getting the
new Kermit-11. It should have been UOFT02 KERMSRV.  See Kermit Digests
numbers 2-21 and 2-26.

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

Date: 15 May 85 06:52:09 GMT
From: Pat Chewning <patch%nsc-pdc.uucp@brl>
To: Info-IBMPC@USC-ISIB
Subject: IBM PC/AT Serial Port Compatibility

I am having trouble with my AT receiving serial data at baud rates over
1200.  I suspect that it has something to do with the incompatibility of the
serial controller used on the AT versus the PC.  Here's the set-up:

    IBM AT
    AST ADVANTAGE! multifunction board that has the serial port.
        (Uses 16450 chip?)
    Kermit Software (Also tried-out a copy of Crosstalk with same results)
        [Both these software packages were written for PC]

Using the same physical RS232 line, I have no problem doing data transfers
at 9600 baud using a Compaq [IBM PC Clone].

The problem shows up at baud rates greater than 1200 (although occasionally
at 1200 baud as well).  The characters are not wrong, but the problem is
missing characters.  Transmitting characters works fine, its only on
receiving that I have a problem.

The manual that came with my serial card indicates that some incompatibility
exists between the serial controller chip used in the AT and the controller
chip used on the PC.  It suggests that some software written for the PC may
not operate properly on the AT.

Does anyone know what those differences are, and in particular, what
specific changes need to be made to Kermit [I have a source] so that it will
work on the AT?

                Pat Chewning

[Ed. - See below.]

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

Date: 16 May 1985 10:22:14 PDT
Subject: AT Serial Port Compatibility
From: Richard Gillmann <[e-mail]>

Sounds like you have the Professional Graphics display.  This has the
unfortunate effect of interfering with the serial ports at speeds over 1200
baud.

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

Date: Thu 16 May 85 13:57:53-EDT
From: Charlie C Kim <US.CCK@CU20B>
Subject: IBM Asynch Adapter at 19.2Kb and Beyond

Using an interrupt based system, as has been indicated, it is definitely
feasible to run the IBM serial card at speeds greater than 9600 baud.  (In
fact, you'll probably need an interrupt based system at any speeds above
1200 or so).  On an AT, I've been using Kermit, which is interrupt driven
for the serial IO, for file transfer to and as a remote terminal for a 4.2
Unix system (Vax 750 with DMF's--the DMF is a serial/parallel board for the
VAX which has a maximum speed ot 19.2KB on serial lines) at 19.2KB without
any problems.  I've also tried it at 56KB between two PC's (one AT, one
PC-1) and between a PC-AT and Macintosh without any problems.

I've also be able to use the COM_PKG/INT_PKG pair in the IBMPC library to
communicate from a PC-AT to the above mentioned VAX at 19.2KB; again
without any problems.

So, empirical evidence supports the results.  As as side note, I should
note that I've used communications packages which were incapable (on a
PC/XT) of going above 1200 baud without losing characters; I suppose these
were not interrupt driven.

Charie C. Kim
Columbia University
Center for Computing Activites

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

Date:     Thu, 23 May 85 14:26:27 BST
From:     [e-mail]
Subject:  Appeal to the Netherlands

To anyone in Holland (= The Netherlands):

     Is there anyone in the Netherlands running Kermit who could help
me by providing a mainframe Kermit for demonstration purposes?
This would be to demonstrate that a micro-Kermit actually works.
If so, please mail me soonest as "cjk @ ucl-cs", on either ARPA
or JANET.
                    Chris Kennington.

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

Date: 24 MAY 85 14:50-N
From: DEGROOT@HWALHW5
Subject: Kermit for IAS?

1.      Some users keep asking for a KERMIT version for the operating system
        IAS on the PDP11. I understand that IAS is an obsolete operating
        system. Previous KERMIT-versions for RSX could be generated for IAS.
        The current versions of PDP11 KERMIT give not any notice of IAS.
        Is there a KERMIT for IAS?

[Ed. - There is some hope that Kermit-11 will be adapted to IAS.  There is
at least one very large IAS site that has indicated some willingness to do
this, but there is no definite commitment or timetable -- see below.]

2.      The file CURRENT.DOC indicates version 3(124) for K10-KERMIT.
        The right version number for the DEC10-KERMIT should be 2(124).

[Ed. - Thanks for pointing out the mistake.]

                                        Kees de Groot   (DEGROOT@HWALHW5)
                                        Computer Centre
                                        Agricultural University
                                        Wageningen
                                        The Netherlands

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

Date: 24 MAY 85 09:30-EST
From:  [e-mail]
Subject: IAS AND KERMIT

I just got a call yesterday from the EPA  about  IAS  and  Kermit.  They
have  some  30  systems  running IAS version 3.1 and have volunteered to
port it to IAS. The main problem with IAS is that RMS-11  version  2  is
only  supported on IAS 3.2, which many sites seem to have decided not to
install. I expect that these  folks  at  the  EPA  will  have  Kermit-11
running  on  IAS  soon, so I would suggest that others interested in IAS
Kermit to wait a couple of weeks until I get more info on the progress.

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

Date: Fri 17 May 85 19:34:39-PDT
From: Wing Lee <WingLee%ECLD@ECLA>
Subject: Need Help with Kermit-TSO and 7171

I am experiencing a problem with the Series/1 version of TSO-KERMIT.  It
works fine with the Series/1, but here at USC we are replacing the Series/1
with an IBM 7171.  I am having problems trying to upload files through the
7171.  I am able to download files just fine, but when I upload, TSO-KERMIT
stops at the first bad packet.  I used the debug option on TSO-KERMIT and
when I looked at the debug file, it shows that TSO-KERMIT stops right after
a CHECKSUM error.  It appears that TSO-KERMIT is unable to notify the micro
KERMIT that it has received a bad packet and have the micro resend it, and
since the micro KERMIT hasn't received an acknoledement from TSO-KERMIT
telling it to that the last packet was good, a transmission lock up occurs.

I've tried everything I can think of to solve this problem, and would
appreciate any suggestions you can think of.

Thanks

Wing Lee
University Computing Services
University of Southern California

[Ed. - This is presumably the Version of TSO Kermit whose genealogy is
Columbia VM/CMS Kermit v 1.0 -> U of Chicago MVS/TSO support -> U of Toronto
Series/1 support.  Anyone else out there using it?  Also, see next message.]

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

Date: Mon 20 May 85 16:26:52-EDT
From: Frank da Cruz <[e-mail]>
Subject: Converting New VM/CMS Kermit to MVS/TSO?
To: Ron Rusnak <[e-mail]>

Hi Ron -- Do you think anybody at U of Chicago will be working on TSO Kermit
any time soon?  Ideally, I think it would be good if the new CMS release
(2.00, which has server mode, binary file transfer, CRC's, etc) could have
TSO support added to it in such a way that either TSO or CMS Kermit could be
built from it.  I don't know much about IBM assembler, but I would hope that
this would be possible using macros or conditional assembly for the system-
dependent parts.  This would simplify life a lot for both of us, not to mention
the hundreds of sites that are running TSO &/or CMS Kermit, allowing each
to benefit immediately from improvements in the system-independent areas.
What do you think?  - Frank

[Ed. - I never got a reply to this, but maybe someone else who might be
interested in TSO Kermit -- U. of Toronto, maybe? -- would be willing to take
on the task.]

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

Date: Sun 19 May 85 19:49:20-MDT
From: Jon Albers <[e-mail]>
Subject: Kermit for the NorthStar horizon and USR S-100 modem.
To: [e-mail], [e-mail], [e-mail]

I am looking for a version of Kermit that will work on a Northstar horizon
with either the second printer port, or better yet, the US Robotics S-100
internal modem.  If you have or know of such a beast, or can perhaps give
some help with writing the code to make Kermit work with an S-100 modem
board, please reply to me at the below addresses:


                        Jon Albers
                    ARPA: JALBERS@SIMTEL20
                    /..seismo!dolqci!irsdcp!albers
            UUCP: ---------<...seismo!dolqci!irsdcp!dcp1!albers
                    \..philabs!sbcs!bnl!bnl44!jalbers

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

Date: Sat 18 May 85 23:01:53-PDT
From: Bob Larson <BLARSON%ECLD@ECLA>
Subject: Formatting documentation for Xerox 2700

I had problems formatting the kermit documentation for our xerox 2700 also.
The verbatim portions of the manuals have lines to long to print at 10 cpi
with the default margins used for the 2700.  By making sure that all verbatim
areas were printed at 12cpi, and modifying "italics" to do underlining
(the only italic font we have is 10cpi)  I was able to format the manual
so only a few characters where lost.

It might work if formatted with a one character left margin.

Hope this helps.

Bob Larson <[e-mail]>

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

Date: Tue, 21 May 85 03:02:17 edt
From: Robert Scott Lenoil <[e-mail]>
Subject: Commodore 64 Kermit Diskette Availability

     Enclosed is the text of my message to USENET, re: my ability to
supply Commodore 64 Kermit diskettes this summer.  Please update the
00readme.doc file and the information that you give out over the
phone to reflect this new status.  Note that my work phone number this
summer will be [phone], effective June 1.

    Subject: Kermit diskette availability
    Newsgroups: net.micro.cbm
    Distribution: net.micro.cbm

As you may know, I have been providing copies of Commodore 64 Kermit for
$7.00 as a service for those who couldn't otherwise obtain the program.
However, I will be leaving shortly for the summer and have decided not to
take my Commodore with me.  Therefore, I do not anticipate being able to
fulfill any orders until my return August 25th.  There is always a
possibility that I find somebody at work with a 64, so if you do need a
diskette, send me netmail, and I'll let you know if I can accommodate
you. (Send to this address - my mail will forward).

Robert Lenoil
[e-mail]
[e-mail]
[e-mail]

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

Date: Friday, 17 May 1985  14:26-MDT
From: ritcv!husky!pma%rochester.uucp@Seismo
Subject: Kermit for Wang VS or OIS?

Does any one know of a "kermit" for a Wang(tm) VS or OIS system ?
Please respond to me by email.

        Thanks,
         Philip Abram, Eastman Kodak Co., Rochester, N.Y.

PATH:
     {allegra,seismo}!rochester!ritcv!-------\
                           >------husky!pma
    {eagle,astrovax,netword}!sun!sunrise!----/

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

From: tektronix!stever@Berkeley
Date: Tuesday, 21 May 85 13:01:22 PDT
Subject: Two Faces of Kermit

Kermit is both a protocol and a communications program.  One should not
ridicule people for their confusion about this point.

All communications programs whether commercial or not should be able to do
*raw* (i.e. ASCII) data file transfers using system level commands of the
computer they are talking to, as well as supporting one or more file transfer
protocals.

Kermit should not be an exception.  This feature should be a part of the Kermit
protocal definition.  Kermit implementations should not be included in the
distribution system of Kermit software unless they have the *raw* file transfer
function.

steven d. rogers
...ucbvax!tektronix!stever

[Ed. - In principle, I agree.  In practice, Kermit programs are donated by
individuals who are free to implement whatever features they like, so long as
the minimum protocol features are present.  We're not going to turn down
desparately needed contributions (we know when a Kermit implementation is
desparately needed when the number of phone calls asking about it exceeds
a hundred per day) because they lack a particular optional feature.]

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

End of Info-Kermit Digest
*************************
-------
30-May-85 17:29:15-EDT,11900;000000000001
Mail-From: SY.FDC created at 30-May-85 17:28:02
Date: Thu 30 May 85 17:28:02-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #31
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu, 30 May 1985       Volume 2 : Number 31

Departments:

  C-KERMIT 4C -
    C-Kermit Parity
    More Problems on Kermit 4C?
    System V C-Kermit 4C Works
    System V 4C C-Kermit Racal-Vadic Control Fixed!
    C-kermit on 4.1bsd

  MISCELLANY -
    Kermit for Atari ST
    TRS-80 III Kermit Users Wanted
    PC/AT Serial Adaptor problems
    CP4KERMIT on Superbrain

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

From: <hplabs!amdahl!drivax!alan@Berkeley>
Date: Tue, 28 May 85 22:48:33 PDT
Subject: C-Kermit Parity

I hope that this is the right place to send this. I am using C-Kermit 4.2,
and I noticed that it does not set the parity on the com. line when a set
parity even/odd/mark/space command is issued.  This is a problem for me
because our VAX (System V) defaults differently than the other machines here
(iNTEL 310 w/System V, VME/10 w/System V).

Thanks,
Alan Fargusson.
DIGITAL RESEARCH INC.
60 GARDEN COURT
BOX DRI
MONTEREY, CA. 93942

[Ed. - C-Kermit certainly makes every attempt to transmit the desired
parity.  The question is whether the System V implementation sets the tty up
in an appropriate mode to allow the C-Kermit software to do this.  Some
changes have been made in this area since release 4.2 -- you may find that
release 4C does it right.  I hope so.]

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

Date: Mon May 27 1985 10:57:27
From: Marco Papa <[e-mail]>
Subject: More Problems on Kermit 4C?

I am sorry to say, but the problem reported by Yigal Arens on Kermit 4C
about timeouts on large files under System V is present also in the Berkeley
version.  I run the following test: I tried to transfer the new ckuker.mss
(34 TOPS-20 Pages) from ECLC (TOPS-20) to uscvax (Berkeley-UNIX 4.2).
Everything went well until after about 160-200 dots(.) were on the screen.
Then suddenly a sequence of T%T%T%T%T%T%T% started coming. Only way to get
out was to abort the batch transfer.  The UNIX kermit was saying it had
timed out, and the TOPS-20 kermit was back to the KERMIT-20 prompt. I tried
this twice with the same result.  Both machines were totally unloaded (I was
the ONLY user on TOPS-20 and there were 5 other users on the VAX).  This
seems to be a bug of the new 4C version of Kermit, not present in the
preceding 4.2 version (which I used to transfer all 4C files between the
above mentioned machines).

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

Date: Tue 28 May 85 13:19:16-EDT
From: Frank da Cruz <[e-mail]>
Subject: Re: More Problems on Kermit 4C?
To: [e-mail]

Were you running the very latest release, 4C(049), circa 8:00pm EST Monday?
I just used it to transfer ckuker.mss from the DEC-20 to a 4.2bsd system and
didn't get a single timeout.  Then I did it again.  Then, just to make sure
this wasn't a fluke, I sent my mail.txt file -- 205 DEC-20 pages, or 514453
characters, or 502.4K, or half a megabyte (that's about a week's worth of
mail for me).  There were 70 jobs on the 2060, the 15 minute load average
was about 6.00; there were 8 users on the VAX-11/750, load below 1.0.  The
two systems are connected by a direct line between the DH11 on the DEC-20
and a DMF32 on the VAX, running at 9600 baud.  The transfer took about 38
minutes; there were 6 timeouts -- one burst of three (%T%T%T), one of two,
and one single timeout.

I don't think a file this big could be transferred if there were some
intrinsic flaw in the program.  Maybe you're running a slightly older
version, and were hit by a bug that has since been fixed.  More likely, it's
just something in 4.2bsd.  We have seen terminals hang quite often on our
4.2bsd systems (the longer the system is up, the more it happens), and
recently installed a patch (from Usenix?) to the DMF driver that may have
alleviated the situation somewhat.

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

Date: Mon, 27 May 85 21:46:43 pdt
From: [e-mail] (Dave Tweten)
Subject: System V C-Kermit 4C Works

Good news!  The latest version has cleared up the problem with remote
commands for System V C-Kermit.  I tested them all and they now all
work.  Unfortunately, the dialer problems are still there for System V
and Racal-Vadic modems, but progress is being made!

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

Date: Tue, 28 May 85 15:49:27 pdt
From: [e-mail] (Dave Tweten)
To: [e-mail]
Subject: System V 4C C-Kermit Racal-Vadic Control Fixed!

I have found a fix for the System V Racal-Vadic modem problem.  The problem
was that tthang was dropping DTR for the modem AND LEAVING IT LOW.  After I
examined the code for ttopen, tthang, and ttpkt, I concluded that if ttopen
needed the "close(open( . . ." magic, tthang probably did too.  The magic is
there, but it is surrounded by "#ifdef PCIX".  I removed the "#ifdef PCIX",
and the problem went away!

[Ed. - Good news!  Change installed.]

By the way, while playing with C-Kermit 4C, I noticed that the bsd version
is compiled without optimization.  I tried compiling it with optimization,
and it seems to work well, while generating a somewhat smaller executible
file.  Why no "-O" for bsd?

[Ed. - You're free to add -O if you want; I'd rather distribute without it
so there's one less thing to blame when things break.]

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

Date:           Tue, 28 May 85 10:06:38 PDT
From:           Dave Flamm <[e-mail]>
Subject:        C-kermit on 4.1bsd

The latest version of C-kermit still won't "make" successfully on our 4.1
bsd.  It still looks for "time.h" without success.  It would seem that
whatever means is used for detecting 4.1 versus 4.2 is not foolproof?

> I think I see the problem.  It's in ckutio.c...  all the nested #ifndefs
> around "#include <sys/time.h>" need an additional #ifndef BSD41...#endif.
> Try that and let me know if everything else is ok for 4.1bsd.  Thanks!

(later...)

That seems to have done it.  Thank you.

Dave

[Ed. - It looks now as if 4C pretty much works as advertised on all systems
except 2.9bsd.  The next issue of Info-Kermit will announce it "for real".]

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

Date: Tue 28 May 85 13:52:27-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit for Atari ST
To: [e-mail]

I got a call from someone in Canada who said that Atari is distributing what
appears to be the old Unix Kermit (command line operation only) in the
developer kit for the new ST computer system, source not included.  The caller
wanted to know why it wouldn't transfer binary files in "image mode" -- it
seems it stops sending as soon as it hits a control-Z in the file.  Sounds
like the file system must be in the CP/M style.  It's nice that Atari is
promulgating Kermit, but if they also included the source then maybe some of
their developers could fix the bugs, or even adapt the new C-Kermit...

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

Date: Tue 28 May 85 13:55:52-EDT
From: Frank da Cruz <[e-mail]>
Subject: TRS-80 III Kermit Users Wanted

John A Ball of the Northeast Radio Observatory Corporation, Haystack
Observatory, Westford MA 01866, 617-692-4764, would like to make contact
with users of TRS-80 Model III TRSDOS Kermit.

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

Date: Tue, 28 May 85 09:35:36 PDT
From: [e-mail]
To: [e-mail],    [e-mail]
Subject: PC/AT Serial Adaptor problems

There is a lot of misinformation going around about the serial ports on a
PC/AT and their compatibility with the PC. The 16450 chip (and 8250A chip
from National Semiconductor) has quite a few bug fixes compared to the 8250
and 8250B. One of those bug fixes breaks many interrupt-driven PC
communications programs.  The typical result is missing characters at speeds
of 1200 bps and above.

Now, the bug is that the 8250 pulses (low) its interrupt line when the
condition causing the interrupt is satisified even if there is another
interrupt condition pending. NatSemi thought that action was incorrect so
they fixed it in the 8250A and 16450 - for those chips the interrupt line
will stay high until ALL pending enabled interrupts are satisfied.

The problem this causes with PC communications programs is that many of them
assume the interrupt handler will get entered for every interrupt
individually. This happened because the pulsing interrupt line would make
the PC's 8259 interrupt controller think there was a new interrupt pending,
so it would present it to the CPU chip immediately upon receiving the EOI
(end of interrupt) for the previous interrupt. With the interrupt line not
pulsing on the new chips, the 8259 doesn't think there is a new interrupt
pending even though the 16450's interrupt line remains high. That is because
the 8259 is in edge-triggered mode.

Now, the solution is to poll either the 8250 status register or the
interrupt identification register before exiting from the interrupt handler.
For instance, the following logic works for the receiver data ready
interrupt:

    Interrupt handler:
        save whatever is necessary
        while status register says data ready
           process data
        whend
        send EOI to 8259
        restore whatever was saved
        exit

You might now be saying "But I only enable received data interrupts so there
can never be more than one interrupt pending at a time so I don't need to
worry about this." Well, I thought so too, but the situation is that if the
next received character is ready to be transferred to the receiver buffer
register by the time the CPU reads the receiver buffer register, then the
receiver data ready interrupt will remain pending. Hence you need logic like
the above.  (I've tried this and it does solve the problem.)

There are other bug fixes in the 8250A/16450 which can cause troubles, but
they are much more obscure and much less likely.  They have to do with
transmitter interrupts but I can't recall the details right now and I don't
have my copy of the NatSemi errata sheet handy to refer to.

I hope this helps all you people out there. For those who seem to think all
these problems are caused by the IBM Professional Graphics Controller,
please note that while it may cause some, it is not the ONLY cause, as
should be evident from the above description.

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

Date:  29 May 1985 08:03:15 IST (GMT+2)
To:  [e-mail]
From: [e-mail]
Subject: CP4KERMIT on Superbrain

Hello Frank !

I was delighted with Version 4 which together with Version 2 under CMS makes
the use of KERMIT even more efficient than it was before.  Also I was very
happy to find a version tuned to my Lobo MAX-80, although I had been happy
before with the CPM-Plus version.  The availability of server mode is great,
and I take this occasion to thank you again.

The version running on Superbrain does not generate a break.  I did not look
into the source code to see why, but I thought that the following listing of
a tiny dumb terminal program I have written here may help clear out the
problem, IF there is a problem (perhaps I missed something).

                                            Regards \ Jacques

[Ed. - Jacques' code forwarded to Charles Carvalho for inclusion in the next
release of CP/M-80 Kermit.  No estimate when it will appear.]

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

End of Info-Kermit Digest
*************************
-------
30-May-85 19:29:35-EDT,5278;000000000001
Mail-From: SY.FDC created at 30-May-85 19:29:10
Date: Thu 30 May 85 19:29:10-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #32
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu, 30 May 1985       Volume 2 : Number 32

         C-Kermit Version 4C for Unix, VMS, and the Macintosh

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

This is to announce version 4C of C-Kermit for Unix, the Apple Macintosh,
and VAX/VMS.  C-Kermit is a version of Kermit written modularly in C,
implementing the entire Kermit file transfer protocol (except for attribute
packets), designed for modularity and transportability.

This version of Kermit has been in "field test" for about a month, and
is being released at this time because most of the major goals for it have
been met, namely:

. Most known bugs in release 4.2 fixed
. Support for new systems added and tested
. A few new functions incorporated

At this point, C-Kermit should be considered a fairly stable base upon which
to add support for new systems -- the interface between the system-dependent
and portable modules seems to have settled down -- and to add new features.

A few highlights:

Systems Supported:
  . Berkeley Unix 4.1 and 4.2 (but not yet 2.9)
  . AT&T Unix System III and derivatives (Xenix/286, PC/IX, etc)
  . AT&T Unix System V and derivatives
  . Bell Unix Version 7
  . DEC Pro-350 with Venix Version 1
  . NCR Tower 1632, OS 1.02
  . VAX/VMS
  . Apple Macintosh

New features since version 4.2, common to all implementations:
  . Many features redesigned to promote portability.
  . Compile-time options to eliminate debugging and logging code to reduce
    size and boost performance.
  . Packet parameters separately settable for inbound & outbound packets.
  . Protocol operation improved here & there, many bugs fixed.

New features for Unix implementation (and VMS):
  . Command line continuation
  . Support for additional modem-dialers
  . Improved performance for Pro/Venix
  . Better (but still not perfect) determination of local vs remote mode
    in 'set line'
  . User's preferred shell is used for "!" commands, rather than always sh.
(A complete list of Unix/VMS updates is in CKUKER.UPD.)

New Features (since 0.7) for Macintosh:
  . A key redefinition package is now provided.
  . I/O errors, such as disk full or write protected, now handled better.
  . Separate boxes for inbound & outbound packet parameters in protocol
    settings dialog.
(A complete list of Macintosh updates is in CKMKER.UPD.)

The Macintosh implementation is built using the Stanford University Medical
Center's SUMACC cross development system, which runs on VAX computers under
Unix (or VMS with Eunice).  MacKermit fits on a standard 128K Mac, but just
barely.  The key configurator is a separate program, because this additional
functionality added to Kermit itself would not fit into a 128K Mac.  The memory
restriction is a problem only because the SUMACC system cannot produce
swappable segments.  If someone wants to take the trouble to translate the
Macintosh-specific modules to one of the native Macintosh C development systems
that supports segment loading, then additional functionality can be added
without worrying about exceeding memory.  (If you want to volunteer to do this,
please contact us first!)

The VAX/VMS implementation is more an exercise in portability than a real
Kermit implementation.  It mostly works, but does not possess the intimate
knowledge of the VMS environment that the Stevens Institute of Technology
Bliss language implementation has.  Still, it may be useful to sites that
do not have a Bliss compiler but do have the VAX-11 C compiler.

Documentation includes a Unix Kermit manual (CKUKER.DOC, Scribe source
CKUKER.MSS), a Macintosh Kermit manual (CKMKER.DOC,.MSS), various help files
(CK*.HLP), program update histories (CK*.UPD), and "beware" files (CK*.BWR).
The Unix and Macintosh manuals are new chapters for the Kermit User Guide,
but the Guide itself has not yet been reissued to include these chapters;
a new revision of the manual will appear after MS-DOS Kermit 2.28 is announced.

The files are in KER:CK*.*, available from host CU20B via anonymous FTP
on the Internet.  Within a few days, they will also be available from BITnet
via KERMSRV at CUVMA.  In addition, Macintosh Kermit diskettes will be sent
out to selected sites (Apple University Consortium schools and a few others;
our capacity to reproduce diskettes is limited, so we can't do mass
mailings).  And of course, the new files will be included henceforth on our
Kermit distribution tapes.

The files that had been in <CKERMIT> for testing purposes have been removed.
Thanks to all the folks on the network who participated in the test and helped
to work out the bugs, particularly Dave Tweten (AMES-NAS), Marco Papa (USC),
Dan Schullman (DEC), Lawrence Afrin (Clemson U), and many others too numerous
to mention.

Please report any problems to Info-Kermit@CU20B.

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

End of Info-Kermit Digest
*************************
-------
 7-Jun-85 15:42:40-EDT,17134;000000000001
Mail-From: SY.FDC created at  7-Jun-85 15:41:57
Date: Fri 7 Jun 85 15:41:57-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #33
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri,  7 Jun 1985       Volume 2 : Number 33

Departments:

  ANNOUNCEMENTS -
    Kermit Distribution Reorganized
    Kermit for Perkin-Elmer OS/32
    Corrections to Burroughs 6800 Kermit

  C-KERMIT 4C -
    Problem with Remote Commands to C-Kermit Server in Binary Mode
    Problem with C-Kermit for Version 7 on PDP-11

  MISCELLANY -
    FTP'ing from CU20B
    Formfeeds, tabs, etc in C programs
    DEC-20 Kermit in Local Mode
    CPM-86 Kermit Dies after 64K
    Need Kermit for NCR WS-300
    Kermit for Cromemco?

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

Date: Fri 7 Jun 85 15:18:29-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit Distribution Reorganized

As contributions of Kermit programs continue to arrive, the Kermit
distribution area grows larger and larger.  This week, the collection finally
grew so large that it would not fit on a 1600bpi labeled tape.  The past
several days have been spent reorganizing the entire Kermit distribution
operation.

The biggest change is that there are now two major Kermit distribution areas,
which correspond to two Kermit distribution tapes (Tape A and Tape B).
Area/Tape B contains all the mainframe and minicomputer ("host")
implementations; Area/Tape A contains everything else -- the microcomputer
(PC, workstation) implementations, the manuals, and miscellany.  Splitting up
the files this way allows room for a good amount of growth, and also lets
several versions (notably the U of Toronto Pascal Kermits for RT-11 and
VAX/VMS) be resurrected from the "Kermit-Extra" area.

Even though the files have been split into two directories, they still all
have (and must have) UNIQUE PREFIXES.  No files with the same prefix will
appear in more than one directory (except the new AA files, about which see
below).

Many files have been renamed in a more sensible way.  Previously, all the
"bureaucratic" files like VERSIONS.DOC, 00README.TXT, etc, were mixed in with
all the other files.  Now (in addition to being rewritten), they have new
names, all starting with AA.  In fact, all filenames now start with a letter,
since it turns out that some systems require that.

Old             New          What

(none)          AAAREAD.ME   Explains what all the AA files are.
00README.TXT    AATAPE.HLP   Talks about tapes (replaces ANSITAPE, OSSLTAPE)
(none)          AANETW.HLP   Instructions for getting Kermit via network
00README.TXT    AAFILES.HLP  Explains what the Kermit files are
CURRENT.DOC     AAVNEW.HLP   List of current versions, chronological
VERSIONS.DOC    AAVSYS.HLP   List of current versions, alphabetical by system
(none)          AAWAIT.HLP   List of versions we're waiting for
FLYER.DOC       AAXFLY.DOC   Flyer (now also includes order form)
COMMER.DOC      AAXCOM.DOC   Commercial policy, only the name has been changed
KLTR.TEX        AAKLTR.TEX   Cover letter, rewritten

The files that used to be VERSIONS.DOC and CURRENT.DOC been combined into
AAVERS.HLP.  This is a list of versions, one on each line, showing the
following information:

Prefix,                 Operating  Program   Program  Released
 Tape  Machine          System     Language  Version  yy/mm/dd  Contributor

for example:

CMS B  IBM 370 Series   VM/CMS     Assembler    2.01  85/05/20  Columbia U

Whenever a new version is installed, this file is updated and then sorted
several different ways to produce the following files:

AAVNEW.HLP -- Listed in reverse chronological order of release date
AAVOPS.HLP -- Listed alphabetically by operating system only
AAVPFX.HLP -- Listed alphabetically by prefix, regardless of tape
AAVSYS.HLP -- Listed alphabetically by machine and operating system
AAVTAP.HLP -- Listed by tape (A or B), then alphabetically by file prefix

The AA*.* files will appear in both Kermit distribution areas/tapes.  A glance
at the appropriate file will make it easy to answer questions like "Is there a
Kermit for xxx?", or "Has there been a new release of Kermit for xxx since
yyy?", or "What is the prefix for zzz Kermit?", or "What tape is such-and-such
a Kermit on?"

Some Kermit program files were renamed:

    Old             New

  20KERMIT        K20MIT (needed to start with a letter)
  170KERMIT       CDCKER    "
  800KER          LUXKER    "
  86KERMIT        C86KER    "
  CMSKERMIT       CMSKER (so Scribe could deal with the .MSS better)

Those who use the Internet, CCnet, or BITnet to get Kermit files from Columbia
should read KER:AANETW.HLP for details about network access.  The BITnet area
(KERMSRV@CUVMA) is not yet reorganized -- that will take another week or two.
Those who use FTP or NFT to get files from CU20B should notice no difference
in the procedure, since the "logical name" KER: has been redefined to include
the new area in its search path; the fact that no prefix (except AA) appears
in more than one area should allow network file transfer to work as before,
except when you try to get ALL the Kermit files (would anybody really do
that?) -- if you tried to "MULTIPLE GET KER:*.*", you would wind up with only
the files from area A.  If you need to refer to the B area explicitly, its
logical name is K2:, as in "MULTIPLE GET K2:*.*".

And a minor complication -- Macintosh Kermit is part of the CK*.* files, which
are on Tape B.  But since the Mac is a micro, people will be upset if they
order the "micros" tape (A) and there's no Mac Kermit on it.  So just the .HQX
files for CKMKER and CKMKEY have copies KER:, along with the CKMKER.DOC file.
However...  since these files were also in K2:, their names have to be
something that doesn't start with CK; otherwise, people who tried to FTP CK*.*
would only get those three files and nothing else (because DEC-20 logical names
don't step).  So they are called KER:MCKER and MCKEY...

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

Date: Mon 3 Jun 85 15:58:29-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit for Perkin-Elmer OS/32

From Paul Mamelka, Genetics Dept, Southwest Foundation for Biomedial Research,
San Antonio, Texas:

[Here is] "Kermit-PE" for the Perkin-Elmer 3200 series computer under OS/32
operating system.  We've been using the program for the past 3-4 months to
transfer data files between our various micros and a PE-3210, with good
success.  It's also currently in distribution through the Perkin-Elmer
INTERCHANGE library, and we've had no reports of any serious problems yet.

As noted in the .DOC file, revision level 7.2.1, or higher, of OS/32 is
required to run Kermit-PE successfully, and any difficulties people have
with it will probably be related to the OS level they're using, or to some
special customization they've done to OS/32's BIOC device driver.  Questions
relating to this might best be directed to:

    Ron Stordahl
    c/o INTERCHANGE Library
    Perkin-Elmer Data Systems
    2 Crescent Place
    Oceanport, NJ  07757

Ron is fairly knowledgeable on the subject of BIOC, having implemented some
of the "unofficial" upgrades to the driver which let Kermit-PE run much more
efficiently under OS/32.  He's distributing these upgrades through the
INTERCHANGE Library, along with Kermit-PE.  I'll also be happy to answer
whatever questions I can from P.E. users who receive Kermit through your
channels.

                Paul Mamelka
                512-674-1410 x353

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

Date: Mon 3 Jun 85 16:00:23-EDT
From: Frank da Cruz <[e-mail]>
Subject: Corrections to Burroughs 6800 Kermit

The first release of Burroughs 6800 Kermit that was released 15 Feb 1985 had
a few bad lines.  The following changes are necessary to the original
version; the version being distributed currently (KER:B68KERMIT.ALG, as of 3
Jun 85) incorporates them:

1) Delete the three lines containing the following sequence numbers:
    12010600, 12012900, 12013000

2) Add the following lines between those numbered 12099000 and 13000000:

      END                                                          12099200
    UNTIL  RM:=*-CTS  = 0                                          12099400
  END   D E B U G W R I T E ;                                      12099600

This should allow a clean compile of Kermit.

    Randy McLaughlin
    MetroII
    360 Colborne St
    St Paul, MN 55102
    [phone]

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

Date:     Tue, 4 Jun 85 08:46:49 PDT
From:     [e-mail]
Subject:  Problem with Remote Commands to C-Kermit Server in Binary Mode

We have set up a PC/AT running Xenix as a file server using C Kermit server
mode.  Users on our LAN can login and retrieve public domain software , etc.  I
have set kermit server up using the switches "iwx" so binary files can be
xferred.  The problem I now have is since no LF to CR LF conversion is done,
when PC-DOS machines connect and issues commands to the server ( like remote
help, etc. ) they get output with no CRs and hence get a jumbled display.  Any
ideas on how to work around this?
Thanks..
Richard Fagen
Caltech Computing Support Services
rich@hamlet

[Ed. - Unfortunately, you can't have it both ways.  C-Kermit could be changed
to always insert CR's when responding to remote commands (temporarily turn off
the "binary" flag), but unfortunately, it's impossible for the program to know
WHY the user put it in binary mode.  It may be that she wants to run a program
that sends binary data to the screen for cursor control or even graphics.  If
you're sure your users will never do that, then you can add a couple lines of
code to save and turn off the binary flag before doing a remote command, and
restore it when done.]

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

Date: 5 Jun 1985 15:21-PDT
Subject: Problem with C-Kermit for Version 7 on PDP-11
From: Geoffrey C. Mulligan (USAFA) <GEOFFM@SRI-CSL>

I compiled the 4C version of c-kermit under my v7 system on an 11/70 and when I
tried to run it I got a program too big error.  Can anyone help?

        geoff

[Ed. - The Pro/Venix version runs on what amounts to an 11/23 with no i&d
space with no problem, but it uses the "core-mapping" feature provided by the
Venix compiler and linker, which may or may not be available under V7 on the
PDP-11.  If not, then you'll probably have to resort to overlays.]

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

Date: Sat, 1 Jun 85 00:32:00 PDT
From: Dave Flamm <[e-mail]>
Subject: FTP'ing from CU20B

I have a question regarding my ftp'ing from cu20b on the arpanet: I would
like to use "mget" to save effort, but it seems that I need a password to
change directories to <KERMIT>.  Otherwise the filenames prefixed with
"<KERMIT>" are what get written to my directory, and these are so long that
the ends get truncated.  The result is that the files overwrite each other.

I'd appreciate any advice in this regard.

Thanks,
Dave

[Ed. - You can't CD to a DEC-20 directory when logged in as ANONYMOUS through
FTP -- CD means something different to a DEC-20 than it does to UNIX (on a
DEC-20 CD, or "connect", gives you ownership rights).  I'm having our network
gurus look into making FTP send only NAME.TYPE, rather than
DEVICE:<DIRECTORY>NAME.TYPE.N;P775252;AFOO etc etc.  Does anyone know any
reason why the FTP server should send the fully qualified name?  Of what
possible use could it be to a foreign system?]

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

Date: Fri 31 May 85 14:30:07-PDT
From: Bob Larson <BLARSON%ECLD@ECLA>
Subject: Formfeeds, tabs, etc in C programs

One of the unportabilities of C-kermit is formfeeds and tabs in the source
code.  They aren't hard to remove, but it can be slightly painful if such
a utility does not exist on the machine of interest.  Here is a short program
to expand tabs, replace formfeeds with newlines, and remove line continuation
from C programs.  (The line continuation is removed due to a documented lack
in Microwares Os9 C compiler, and should not be needed for other systems.)
It's not fancy, but it works.  Input is from standard input, and output is
to standard output.  (Please make sure not to convert spaces to tabs if you
make this program available.)

Bob Larson  <[e-mail]>

/* dpp.c by Robert A. Larson */

/* dumb pre processor */

/* designed to convert C programs to a more usable format for Os9.
   Microware C (6809) accepts tabs and formfeeds, but they make the
   file hard to edit.  Microware C does not accept macro or string
   continuation.
*/

/* Expands tabs to spaces (tab=1 to 8 spaces, same as dec terminals)
   Replaces FormFeeds with Newlines
   Removes Backslash Newline sequences  (Macro or string continuation)
*/

#include <stdio.h>

main(){
  int c;    /* c is the character being processed */
  int p=0;  /* p is the count of the number of characters in the current line */
  while((c=getchar())!=EOF){
    switch(c){
      case('\\'):
        if((c=getchar())!='\n'){
          putchar('\\');
          ungetc(c,stdin);
          ++p;
        }
        break;
      case('\n'):
      case('\f'):
        putchar('\n');
        p=0;
        break;
      case('\t'):
        do{
          putchar(' ');
        } while(++p&7);
        break;
      default:
        putchar(c);
        ++p;
    }
  }
}

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

Date: 06/02/85 22:12:56 EDT
From: TS0013@OHSTVMA
Subject: 20KERMIT in Local Mode

I am running TOPS-20 Kermit version 4.2(254)-1 in local mode talking to a
VM/CMS system.  When I connect to the other host (VM) and after that host
sends a XOFF but before it sends a XON, I cannot seem to transmit a BREAK to
it using ^\B.  This works fine when VM is reading input, but when VM is
doing output, it sends an XOFF to hold back input data.  BREAK should not be
among that held back.  Is this problem in Kermit or in our system, which is
version 5.3(5721)-5, front end version unknown.  This problem is NOT
experienced with MS-DOS/IBM-PC Kermit.
                                  ...Phil Howard

[Ed. - Right, Kermit-20 should clear any XOFF'd condition when the user
tells it to send a BREAK.  This will be in the next release.]

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

Date:     Mon, 3 Jun 85 17:36:46 CDT
From:     Gregg Wonderly <[e-mail]>
Subject:  CPM-86 Kermit Dies after 64K

While trying to transfer a rather LARGE file from our VAX to a rainbow with
a hard disk, we keep getting an abort with a message saying that the disk
directory space is full.  There is over 2 Meg free when this message is spit
out.  A STAT of the file reveals that the file is 64Kbyte long.  Could this
be the evil 64K segment problem that the Intel chip is so widly known for???

Gregg Wonderly
Department of Computing and Information Sciences
Oklahoma State University

[Ed. - Answer from Ron Blanford, CONTEXT@WASHINGTON: "If the message says
the directory space is full, then this has nothing to do with the amount of
room left on the disk.  Depending on how the Rainbow defines the hard disk,
there is probably an upper limit of 512 or 1024 directory entries that can
be used, each mapping 32 or 64K of disk storage.  A large number of small
files on the disk could explain the problem; getting rid of some would
probably fix it."]

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

From: Bob Paver <PAVER@DELILAH>
To: info-kermit%cu20b@mcc
Subject: Need Kermit for NCR WS-300

We've got some NCR Worksaver 300's that need to talk to our VAX.  NCR's
solution is something called ATE-2 which requires extra VT-100 modules and
which doesn't support RELIABLE file transfers.  Therefore I'm looking for a
Kermit.

The hardware is actually made by Convergent Technologies.  The OS is a
modified version of CTOS.  The processor is an Intel 80186.  Supposedly the
system will run MS-DOS, but we don't have it and I'd rather not mess with
another operating system in this application.

Any suggestions?

Bob Paver, MCC, 9430 Research Blvd., Austin, TX 78759, [phone]

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

Date: Thu 6 Jun 85 21:55:43-PDT
From: L. Brett Glass <G.GLASS@[36.48.0.2]>
Subject: KERMIT for Cromemco?

Does anyone know of a KERMIT (especially, one with a server) which will run
on a Cromemco System 300 under Cromix or CDOS?  In particular, it would be
useful to get a version which already knows how to use the Z-80 front-end
cards supplied with these systems (Quadart, Octart, etc.).  Please send
ANY information to <[e-mail]>....

[Ed. - Isn't Cromix a kind of Unix?  Maybe C-Kermit could be tricked into
doing the job.  Has anyone tried it?  Is anyone working on Kermit for CDOS?]

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

End of Info-Kermit Digest
*************************
-------
10-Jun-85 17:31:47-EDT,4162;000000000001
Mail-From: SY.FDC created at 10-Jun-85 17:31:21
Date: Mon 10 Jun 85 17:31:21-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #34
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Mon, 10 Jun 1985       Volume 2 : Number 34

               MS-DOS Kermit Version 2.28 Now Available
               Need Pointer to Victor 9000 Kermit Disk
                       Kermit-MS under Topview?

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

Date: Mon 10 Jun 85 17:22:15-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: MS-DOS Kermit Version 2.28 Now Available
To: Info-Kermit@CU20B, Info-IBMPC@USC-ISIB

This is to announce Version 2.28 of MS-DOS Kermit.  MS-DOS Kermit provides
terminal emulation and Kermit protocol file transfer for the following
systems:

. IBM PC, PC/XT, PC/AT and compatibles
. IBM PCjr (RS232 port only)
. DEC Rainbow Series
. Hewlett-Packard 150
. Hewlett-Packard 110
. NEC APC
. Sanyo MBC
. Texas Instruments Professional
. Wang PC
. Heath/Zenith 100
. Generic MS-DOS

The program has been tested at Columbia on the IBM PC, XT, and AT, the DEC
Rainbow, and the HP-150.  Since the system-dependent modules were not noticably
altered, it is expected that it will work on the other systems too -- but
confirmation (to Info-Kermit@CU20B) would be appreciated.

The changes are in several major areas:

1. Bug fixes (many)
2. Size -- new version is much smaller on disk, at the cost of DOS 1.x support.
3. New commands - CWD, TYPE, VERSION
4. Better unique-filename manufacturing algorithm.
5. Additional Heath-19 terminal emulation features and controls.

The files are in KER:MS*.* on CU20B, available to Internet via anonymous FTP:

KER:MS228.UPD  -- List of specific changes from 2.27 to 2.28
KER:MSAAAA.HLP -- List of all the MS*.* files, with brief explanations
KER:MS*.BOO    -- .BOO-format programs for downloading (see documentation)
KER:MSKERM.DOC -- New Kermit User Guide manual chapter for V2.28
KER:MSKERM.BWR -- "Beware File" (list of known bugs & limitations)
KB:MS*.EXE     -- 8-bit binary format Kermit programs for the various systems

The files will also appear at the other Kermit distribution points within
a week or two (BITnet KERMSRV, okstate, etc) and will be submitted to PC SIG
for the benefit of those who want to order MS-DOS Kermit on floppy disk.

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

Date: Sun, 9 Jun 85 14:25:52 cdt
From: ihnp4!shell![e-mail] (Lester Buck)
Subject: Need Pointer to Victor 9000 Kermit Disk

Could you direct me to a source for a version of kermit that runs on a Victor
9000 that is actually on a Victor 9000 format disk?  I would gladly pay some
$$$ to anyone and I am not in a terrific hurry (next three or four weeks).  I
would like to avoid downloading the versions I have on the distribution tapes.
I note that the Victor versions have changed around alot from the distribution
tape last August to the tape this March - no more vic*.* files for msdos, but a
bunch of new ones called sir*.* which I guess are identical (?).

Thanks for any pointers,

A. Lester Buck @ Shell Development Co.
{ihnp4, pur-ee, ut-sally}!shell!buck

[Ed. - There were actually several different Victor/Sirius Kermit
implementations, based on various releases of Version 1.x IBM PC Kermit.
We're only distributing the latest one.  Can anyone help him out?]

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

Date: Mon 10 Jun 85 13:28:03-PDT
From: Jim Celoni S.J. <[e-mail]>
Subject: Kermit-MS under Topview?

What are the correct program parameters to give Topview so that Kermit-MS 2.27
runs best under it?  Is there a .pif file for Kermit?  If Kermit can transfer
files in the background and not mess up the screen, that would be great...

Thanks.  +j

[Ed. - Has anybody really gone through the bother of doing this?  If you have,
please feel free to contribute your work to Info-Kermit!]

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

End of Info-Kermit Digest
*************************
-------
14-Jun-85 20:00:33-EDT,11944;000000000001
Mail-From: SY.FDC created at 14-Jun-85 20:00:11
Date: Fri 14 Jun 85 20:00:11-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #35
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 14 Jun 1985       Volume 2 : Number 35

                     Known Bugs in MS-Kermit 2.28
     Fixes to C-Kermit 4C Available for Unix, VMS, and Macintosh
                       Why is C-Kermit So Slow?
                      Kermit for Fortune 32/16?

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

Date: Fri 14 Jun 85 18:30:52-EDT
Subject: Known Bugs in MS-Kermit 2.28
To: [e-mail]

There are two major problems with MS-Kermit version 2.28:

1. When doing a GET command, incoming filenames are randomly truncated.

2. On the IBM PC family only, when escaping back from a terminal connection,
   the system hangs.

We have a fix for problem 1 -- it's just a coding error (thanks to Dave
Tweten at NASA for pointing out the error and the fix).  Problem 2 is more
serious: it comes from the use of incompatible assemblers and linkers.  The
program depends upon its segments being in a certain order, and it instructs
the linker to put them in that order using the MSDMB and MSFINAL dummy
modules.  However, it seems that certain assemblers defeat this technique.  A
method is needed for insuring that the segments are in the desired order, no
matter what assembler and linker are used.  While this problem is being
worked on, it should be noted that a version of the program that does not
have this bug is available in the .EXE and .BOO files we distribute, which
were built with an assembler/linker combination that ordered the segments as
desired.

A new release fixing problems 1 and 2 should appear within a few days.
Meanwhile, here's Dave's prescription:

    Change 1 --

    (original msfile.asm)
        jne gofil4              ; No - get the filename.
    ; this bogusity copies the filename from the fcb into the data

    (modified msfile.asm)
        jne gofi4a              ; No - get the filename.
    ; this bogusity copies the filename from the fcb into the data

    Change 2 --

    (original msfile.asm)
        cmp flags.destflg,0     ; writing to printer?
        jne gofil5              ; no, go on

    (modified msfile.asm)
    gofi4a: cmp flags.destflg,0     ; writing to printer?
        jne gofil5              ; no, go on

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

Date: Fri 14 Jun 85 19:35:21-EDT
Subject: Fixes to C-Kermit 4C available for Unix, VMS, and Macintosh
To: [e-mail]

The many messages reporting bugs in and/or suggesting fixes for Unix Kermit
4C(050) will not be reproduced here.  Thanks to all those who sent them in,
particularly (in no special order) Bradley Smith at UCLA, Jim Bernard at U of
Delware, Kelvin Nilsen at U of Arizona, Larry Afrin at Clemson U, Dan Schullman
at DEC, Randy Huntziger at NLM, Frank Prindle at NADC, Martin Minow at DEC,
Marco Papa at USC, Jim Knutson at U Texas, Chris Maio at Columbia CS, Robert
Mark at USGS, Neal Holtz at UBC(?), David Ragozin at U of Washington, Dave
Tweten of NASA, and (of course) Herm Fischer (I think that's all of them;
apologies to anyone I missed).  If you think this list is long, you should see
the messages themselves...

It should be apparent that this program has not settled down as much as was
hoped, and still further releases may appear over the summer.  So if anyone
was thinking of posting it to net.sources... please don't!


C-KERMIT FOR UNIX, CHANGES FROM 4C(050) TO 4C(052), 14 JUNE 85:

. Fixed 8th-bit prefixing negotiation; sometimes C-Kermit would agree to do
  it and then not really do it (applies also to Macintosh Kermit).

. Added minimal 2.9bsd support (further improvements solicited!).

. Trap and ignore QUIT signal, trap SIGHUP and handle like SIGINT.
  This prevents lock files from being left behind after hangup or quit.

. Ignore SIGQUIT and SIGINT signals while inferior shell active -- let
  inferior shell handle them.

. Allowed "-a name" to work when sending from stdin.

. Change hlptxt[] to contain less than 256 characters (for Xenix)

. Fixed bugs in determination of remote vs local mode.

. When stdin redirected, and remote/local status cannot be definitely
  determined, assume local rather than remote so that local-mode commands can
  still be used.

. Fixed bug that was making 16-bit machines erroneously report files not found.

. Change makefile symbol 3BX to ATT3BX (has to start with letter)

. Remove line continuations in the middle of strings in makefile.

. Fixed a couple errors in the Tower OS 1.02 support.

. Fixed a minor problem in V7 support.

. Got rid of the (void) casts in strxxx() invocations.

. For Sys III/V, open terminal in 7-bit, parity-enabled mode rather than 8-bit,
  no-parity mode (some sites actually use parity).

. Change message "status report..." to "status report:" to avoid dot confusion.

. Replace Herm Fischer's ckudia.c with Dan Schullman's reworking of it, which
  features support for more modems (in particular, the DEC DFxxx modems) and
  more structured organization of the modem info, so support for new modems can
  be added by making relatively straightforward table entries.

. Script command now accepts scripts that were continued on the command line
  using \ (as advertised).

. Fixed minor syntactic problems in ckvtio.c for VAX/VMS.


The files are in KER:CK*.* on CU20B, available via anonymous FTP.  Also
included is a new release of Macintosh Kermit, described briefly
below.  Thanks to Doug Brutlag at SUMEX and Mike Meyer at U of
Wisconsin for pointing out the problems, and in some cases offering
fixes, and of course to Bill Schilit, now of Columbia CS, for doing
the work:


C-KERMIT FOR MACINTOSH, CHANGES FROM 0.8(28) TO 0.8(31), 14 JUNE 85:

. Built with new protocol modules from C-Kermit to fix 8th-bit-prefixing
  negotiation.

. Added dragging and selecting of main window, for better coexistence with
  desk accessories.

. Fixed COMMAND-SHIFT-1..COMMAND-SHIFT-9 problem.  Since these keys are
  special (they eject the diskettes, dump screens to files/printer, etc)
  they were being ignored.  This caused things like Control-@ and Control-^
  to be ignored also.  Add a new item to the SETTINGS menu that allows you
  to enable or disable this action.  The default is disabled.

. Fixed some default keymap definitions: Control-Y and Control-T were mapped
  incorrectly.  Control-' was mapped incorrectly.  Functions were defined for
  VT52 instead of VT100 keypad: Changed "?" to "O" in function definition
  strings.

. Errors during and/or after CKMKEY save, decompile now handled better.

WARNING: A serious bug exists in Macintosh Kermit (this new release as well
as previous ones) which should be fixed in a forthcoming release (soon, I
hope): parity operations simply do not work correctly.  Example: when parity
is set to "mark", Macintosh Kermit will discard any incoming underscore
characters; this prevents the Mac from receiving a file that requires more
than 63 packets, or from sending one that requires more than 33, assuming
said files contain no underscores (if they do, the hangup may occur sooner).
The problems fixed above were distracting enough to warrant early fixing, but
those who can live with them for another week or two are encouraged to wait
until an announcement can be made that the parity problem is fixed.

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

Date: Tue, 11 Jun 85 21:09:08 edt
From: xp!tony@nyu-cmcl2 (Tony Movshon)
Subject: Why is C-Kermit So Slow?

I've just been timing my backup from the Rainbow to the VAX (lightly loaded).
It's on a 9600-baud line, but is only transferring characters at about 140/sec.
By my lights, that's 14.5% efficient. Where'd the other 85.5% go?

I realize that the Kermit protocol expands the bytecount by about 25%, but
where's the rest of the time going?

Specifics:

to    VAX 11/750, 2 MB memory, RA81 disk, 4.2BSD, no fancy
    floating-point hardware, DMF32 port (DMA). Load average
    about 1.7, 3-5 users. C-Kermit 4C (049), file type binary,
    no parity.

from    Rainbow 100A, 512k memory, RD51 10 MB Winchester. MS-Kermit
    2.28.

I haven't timed it, but transfers seem to go considerably faster to my
11/24 running TSX-Plus using Kermit-11 V2.29.

Yours in puzzlement ...

Tony

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

Date: Wed 12 Jun 85 10:08:00-EDT
From: Frank da Cruz <[e-mail]>
Subject: Re: Why is C-Kermit so slow?

You have exactly the same setup as I do, except my VAX has more memory.  I've
seen the speed vary a lot, and can't always explain it.  In some cases, it's
appropriate to point the finger at 4.2bsd.  Sometimes, the longer our system
is up, the slower it gets.  Also, there are bugs in the DMF drivers that need
fixing (fixes are available from Usenix if you don't have them).  Also,
sometimes the system will get VERY slow if one of the idle tty lines is being
blasted by noise -- that seems to happen to us a lot.  The reason I mention
these items is that my measurements are a lot different from yours -- using
4.2bsd Kermit 4C(050) on a VAX-11/750 with load around 1.00 (with no special
line discipline, see below) against the Rainbow 100B running Kermit-MS 2.28,
transferring a 11372 character file with few repeated characters (so as not
to deceptively boost throughput because of run-encoding compression), I get:

    Unix to PC:  28 seconds, or 406.0 cps (42% efficiency)
        PC to Unix:  42 seconds, or 277.4 cps (29% efficiency)

These figures are not great, but they're better than your 140 cps by a good
bit.

Beyond the possible problems mentioned above, there's one inherent design
problem in BSD and probably most other Unixes as well -- the line is open in
raw mode for file transfer, but raw mode also turns on cbreak mode, which is
very expensive (more so when receiving data packets than when sending them).
BSD provides an alternate line discipline called "Berknet", which would have
been a LOT better for Kermit except that (a) it strips the 8th bit of
incoming characters, preventing efficient transfer of binary files, and (b)
it's hardwired to use LF as its only break character, whereas all the Kermit
programs in the world use CR.  At Columbia, we fooled with modifying the
Berknet discipine to not strip the 8th bit, to be double-buffered, and to
allow specification of the break character; you can see some code in ckutio.c
under the KERLD conditional that evokes this line discipline.  We found the
result was a Kermit that indeed ran a lot faster, but unfortunately we can't
really distribute the kernel modifications because we're too busy sending
ordinary Kermit shipments to get into the "send me your ATT and Berkeley
source licenses and we'll send you the code" business.

Short of fooling with the kernel, you should be able to speed C-Kermit up
perceptibly by recompiling with DEBUG not defined, to eliminate the many calls
to DEBUG that occur during normal operation, even when debugging information is
not being logged (and if you want to see sloooow, try transferring files with
debug logging turned on!).

- Frank

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

Date:  Thu, 13 Jun 85 09:22 MDT
From:  "Kevin W. Laurent" <[e-mail]>
Subject:  Kermit for Fortune 32/16?

We have a user with a Fortune 32/16 running FORPRO (similar to UNIX
version 7) who wants to use Kermit.  Unfortunately, he doesn't have a C
compiler.  Do you have a contact running Kermit on a Fortune?  Thanks.

- Kevin Laurent <KLaurent@DENVER>

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

End of Info-Kermit Digest
*************************
-------
21-Jun-85 20:17:55-EDT,9177;000000000001
Mail-From: SY.FDC created at 21-Jun-85 20:17:23
Date: Fri 21 Jun 85 20:17:23-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #36
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 21 Jun 1985       Volume 2 : Number 36

Departments:

  ANNOUNCEMENTS -
    Another New C-Kermit for Unix (4C(53)) and Macintosh (0.8(32))
    New FTP server up on CU20B: CWD fixed
    Okstate Dialup Repaired

  C-KERMIT -
    C-Kermit Very Slow on TRS-Xenix
    C-Kermit Runs on Heurikon Mini-Box
    Mapping Keys in Mac Kermit

  MS-DOS KERMIT -
    Generic MS-DOS Kermit Runs on the DG/1
    Kermit-MS under Topview

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

Date: Fri 21 Jun 85 20:00:27-EDT
From: Frank da Cruz <[e-mail]>
Subject: Another New C-Kermit for Unix (4C(53)) and Macintosh (0.8(32))
To: [e-mail]

C-Kermit 4C(053) fixes a major problem for both Unix and the Macintosh:
it now does parity right.  There were two areas in which problems showed
up:

1. Macintosh Kermit could not transfer files using mark or space parity.
Furthermore, when using any kind of parity other than none, occasional
incoming characters would be lost during terminal emulation.  This was
because Mac Kermit was letting the serial i/o chip handle parity, and the
chip is simply not flexible enough to be relied upon.

2. Unix Kermit could not transmit odd parity correctly.  If you "set parity
odd", it was equivalent to "set parity mark".

The Unix Kermit software parity generation function dopar() was fixed to
generate all kinds of parity correctly.  Then Macintosh Kermit was changed
to use dopar() rather than its chip to generate parity.

Several other minor changes were made to Unix Kermit, in particular in the
determination of whether it is in local or remote mode.  The changes are
detailed in KER:CKUKER.UPD and KER:CKMKER.UPD; known bugs are listed in
KER:CKUKER.BWR and KER:CKMKER.BWR (U for Unix, M for Macintosh).  The
complete collection of C-Kermit files for Unix, VMS, and the Macintosh are
in KER:CK*.*.

These files are all accessible via anonymous Internet FTP from host CU20B.
A message about CU20B's FTP server follows.  Also, the file KER:AANETW.HLP
has been updated to provide more complete information on access to CU20B's
Kermit distribution area.

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

Date: Thu 20 Jun 85 23:39:51-EDT
From: Ken Rossman <[e-mail]>
Subject: New FTP server up on CU20B: CWD fixed
To: [e-mail]
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: [phone]

CU20B is now running a new version of the CMU TOPS-20 FTP server.  The
major enhancement which will be important to most users is one which
(indirectly) makes multiple file transfers easier in some cases.

One problem (particularly with originating Unix systems) was that an mget
would return a list of files with fully qualified TOPS-20 pathname
prefixes, which in turn would be the way those files were created on disk
(i.e. the Unix filenames would contain the entire TOPS-20 path prefix).
While this is merely annoying on Berkeley 4.2 systems, this is a real
problem with 4.1 systems (and perhaps others), which have shorter file
names and can lose some of the name information.

Due to the new enhancements to the FTP server, a CWD command may now be
issued to connect the user to the desired Kermit directory (with or without
a password), so that the file list that FTP retrieves for a multiple file
transfer will not contain the entire directory path (just the filenames).
If no password is supplied at the time the CWD command is issued, no "owner
access" is granted to the target directory, and files are only accessible
according to their individual file protections (in the case of the Kermit
directories, this translates to read-only access).  If a password is
supplied, full owner access is granted to the target directory.

Many thanks to Vince Fuller of CMU for the new FTP server.  /Ken

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

To: [e-mail]
Subject: Okstate Dialup Repaired
Date: 11 Jun 85 18:14:52 CDT (Tue)
From: Mark Vasoll <[e-mail]>

Some of you have been reporting problems with the dialup access that we
provide to the Kermit Distribution.  The problem has been traced to a
flakey modem and the offending unit has been replaced with a new unit.
Please continue to direct problem reports and suggestions to one of the
"uucp-support" addresses.

UUCP:  {cbosgd, ea, ihnp4, isucs1, mcvax, pesnta, uokvax}!okstate!uucp-support

ARPA:  [e-mail]

Mark Vasoll
Department of Computing and Information Sciences
Oklahoma State University

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

ARPA:  [e-mail]

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

Date:  Mon, 17 Jun 85 09:38 MDT
From:  [e-mail]
Subject:  C-Kermit very slow on TRS-Xenix
To:  [e-mail]

I just installed 4C(052) on TRS-XENIX and timed a file transfer to a
very lightly loaded VAX/VMS.  With a 4800 baud connection, the transfer
averaged 13 chars/sec.

[Ed. -- Wow, does everybody else with TRS-Xenix have the same performance?]

------------------------------

Date: 18 Jun 85 08:28:10 PDT (Tuesday)
From: [e-mail]
Subject: C-Kermit Runs on Heurikon Mini-Box
To: [e-mail]

C-Kermit has been sucessfully installed on two Heurikon Mini-Boxes.
  (68010, Unisoft System V 5B 4/85;  HK68 CPU - 10 MHz)

only two minor problem areas:

1.  Tabs were converted to spaces at some point along the transfer route.

2.  the " \ " characters had to be removed in the initial Make line.

Recommendation:

Since there are so many entries for a "3" type installation, change the
name of sys3 to sys5.  I found that some non-unix types had trouble with
this as they have System 5 Unix and all through the documentation Unix V
is the more common term used.

Note:    Time to complete the make process 27 minutes.

Thanks to all for a fine job on the software.

------------------------------

Date: Thu, 20 Jun 85 11:22:09 EDT
From: Greg Lauer <glauer@srn-vax>
Subject: Mapping Keys in Mac Kermit
To: [e-mail]

I used the kermit key map program to put control characters on the Option key
and meta characters on the Command key.  The problem is that Option-e,i,u,n
still act like option keys: they "expect" another character.  Thus to send a
control-n requires typing option-n option-n.  Otherwise, this seems like a
great program.

Greg

[Ed. - The lowercase vowels "aeiou" are treated specially in the translation
routine /usr/mac/ws/local/init0.  init0 is also the routine which was doing the
shift-clover-1..9 stuff.  Mac Kermit currently has a command for disabling
the shift-clover-1..9 keys, but adding one for the option-vowels would be a
lot harder.  For now, this goes into the .BWR file.]

------------------------------

Date: Wed 12 Jun 85 14:08:13-CDT
From: Aaron Temin <[e-mail]>
Subject: Generic MS-DOS Kermit Runs on the DG/1
To: [e-mail]

We have a copy of MSGENE.EXE running on our Data General/One.  File transfers
work fine at 1200 baud through an external modem.  Internal modem doesn't seen
to respond, and screen emulation, even with the vt100 ansi.sys installed,
doesn't seem to work.  But this is entirely satisfactory until someone can
modify Kermit appropriately for the beast.

Hope this is helpful.  Thanks.
Aaron Temin

------------------------------

From: Jim Gillogly <jim@rand-unix>
Date: 12 Jun 85 14:38:00 PDT (Wed)
Subject: Re: Kermit-MS under Topview?

Yes, MS-Kermit v. 2.27 will run under Topview.  I haven't bothered with
a .PIF file, but it works fine in the background.  For 2.27 on the IBM PC
I used 96K for the min memory, 96K for max, and 7K for system.  I left
the interrupts at 00-FF, although I'm sure they don't all need to be swapped
(if any) ... keep it simple.  Use "n" for "program writes to screen", since
writing to the screen and running in the background are linked.  The
disadvantage of telling it "n" is that it intercepts everything, giving you
a "galumphing" scroll.  However, "n" is necessary for background, and if
you're transferring long files it's worth it.

I used 2.27 in background mode to pull Webster's 2nd over while doing a
half-day's worth of real work on my PC in the foreground.  I normally don't
use Topview because it's not compatible with the Tall Tree RAMdisk ... and
since I have 2.5 meg of RAMdisk, that's a big loss.

It also works with MS-Kermit v.2.28, which needs only 85K for min/max size.

    Jim Gillogly (jim@rand-unix)

[Ed. - Thanks for the information.  Since 2.28 does dynamic memory allocation,
it will probably have to be defined differently to TopView.]

------------------------------

End of Info-Kermit Digest
*************************
-------
24-Jun-85 18:19:09-EDT,5902;000000000001
Mail-From: SY.FDC created at 24-Jun-85 18:18:37
Date: Mon 24 Jun 85 18:18:37-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #37
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Mon, 24 Jun 1985       Volume 2 : Number 37

                       Commodore-64 Kermit V1.6
               MS-Kermit Support Module for ACT Apricot
                    Kermit for the Acorn BBC Micro
                  New Release of Sperry 1100 Kermit
                  Kermit for ND Series Minicomputers
            Another Kermit Implementation for the ICL/Perq
                        New HP-3000 SPL Kermit

----------------------------------------------------------------------

Date: 8 Jun 85 17:59:50 EDT
From: Eric <[e-mail]>
Subject: Commodore-64 Kermit V1.6

Is ready for distribution.  There are a few minor annoyances, like the disk
command parsing routine not working entirely correctly and the timeout
implementation is far from complete (though it can timeout), and not
handling the lack of an init file on the disk elegantly.  The documentation
describes all the features of this new Kermit, I'm sure people will find it
a major improvement over previous versions.  All known bugs in the
communications routines have been fixed and eight-bit-quoting works.

ARPA:    LAVITSKY@RUTGERS
UUCP:    ...{harvard,seismo,ut-sally,sri-iu,ihnp4!packard}!topaz!eric
SNAIL:    CPO 2765, CN 700
    New Brunswick, NJ  08903

[Ed. - The new files are in KER:C64KER.* on CU20B, available via anonymous
FTP, as are all the other new files announced below.]

------------------------------

Date: Mon 24 Jun 85 17:05:20-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: MS-Kermit Support Module for ACT Apricot

The file KER:MSXAPR.ASM contains the system-dependent functions for the ACT
Apricot, suitable for inclusion in MS-DOS Kermit 2.27 or later.  It comes
from Ralph Mitchell, Computer Centre, Brunel University, Uxbridge UK.  There
is no documentation to speak of, so nothing can be said at this point about
its capabilities (maximum baud rate, screen scroll, printer control, key
redefinition, etc).  Reviews, contributions of documentation (or a .BOO
file) welcome.  Note that there was already a version of the old IBM PC
Kermit version 1.20 that was modified for the Apricot at the
Rijksuniversiteit Groningen, which has been available as KER:APRICOT.* since
November 1984.  If anyone knows any reason why this new version should not
replace the old one, please speak up.  Thanks to Alan Phillips of Lancaster
University for sending it on tape.

------------------------------

Date: Mon 24 Jun 85 17:15:47-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit for the Acorn BBC Micro

This is to announce the initial release (version 0.53) of Kermit for the Acorn
BBC micro under the operating system OS1.20, by Alan Phillips, Department of
Computing, Lancaster University, UK.  The source, in 6502 assembler, is in
KER:BBC*.ADE, and a binary dump of the compiled code is in KER:BBC053.ROM.
KER:BBCBUILD.HLP describes how to construct a BBC Kermit, and KER:BBCKERMIT.BWR
lists known problems with this release.  A printable form of the user guide is
in BBCKERMIT.DOC.  Inside the UK, this program will be available on diskette
and via the UK university network from Lancaster University.

------------------------------

Date: Mon 24 Jun 85 18:05:55-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: New Release of Sperry 1100 Kermit

Version 2.2 of Sperry (Univac) 1100 Kermit (the assembler version, not the
Pascal or the Ratfor version) has been sent in by the author, Paul Stevens
of the University of Wisconsin.  Version 2.2 includes 8th-bit and repeat-count
prefixing, server operation, and supports wildcards in filenames (server and
wildcard code mostly from Grant Gilmour of Guld Canada Resources Inc).  The
program is in KER:UNIVAC.ASM on CU20B.

------------------------------

Date: Mon 24 Jun 85 17:21:39-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit for ND Series Minicomputers

Announcing the initial release of Kermit-ND (version 3.1b) for the
Norwegian ND family of minicomputers (ND-10/100/500), by H. Eidnes and A.
Lie, Norwegian Institute of Technology and others, written in ND Pascal
version J / MAC.  The files are in KER:ND*.* on CU20B.

------------------------------

Date: Mon 24 Jun 85 17:28:55-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Another Kermit Implementation for the ICL/Perq

Here is a second Kermit program for the ICL/Three Rivers Perq workstation.
This one is by A. Lie, formerly of the Norwegian Institute of Technology,
written in POS Pascal for POS version D6/R2.  Like the other Pascal-based
Perq Kermit (from Peter Thew in Australia), it has a pop-up menu user
interface.  This new version of Perq Kermit is in KER:PQ2*.* on CU20B (the
old one is in KER:PQK*.*).  Unbiased comparisons by Perq users of the two
programs would be welcome, so that the less favored one can be retired to
make space.  Thanks to Frithjov Iversen of the Computing Centre at the
University of Trondheim for sending this to us on tape.

------------------------------

Date: Tue, 4 Jun 85 08:29:49 edt
From: Steve Archer  <[e-mail]>
Subject: New HP-3000 SPL Kermit

Here is a new version of HP-3000 Kermit in SPL, version 1.1, to replace
version 1.0 originally from Ed Eldridge, Polaris Inc. (POLARIS@USC-ISI).
It adds the capability to show parameters, changes the "serve" command to
"server".  Help messages have been added, and some short-form commands.
Also added parity, a FINISH command, and a very primitive connect mode.

steve archer

------------------------------

End of Info-Kermit Digest
*************************
-------
26-Jun-85 19:42:39-EDT,14990;000000000000
Mail-From: SY.FDC created at 26-Jun-85 19:42:11
Date: Wed 26 Jun 85 19:42:11-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #38
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Wed, 26 Jun 1985       Volume 2 : Number 38

                           C-Kermit Issue:

                    C-Kermit 4C for Amdahl UTS 2.4
                    C-Kermit 4C for Fortune 16:32
           Fixes to C-kermit for the Valid Scaldstar System
             C-Kermit on Whitechapel MG-1 with Genix 1.3
               Unix-Like Systems Supported by C-Kermit
             Transporting C-Kermit to Eurosys-16 with Os9
                   Dialing from C-Kermit on a 3B2?
                   C-Kermit 4x vs Line Locking, etc

----------------------------------------------------------------------

Date: Thu 20 Jun 85 02:23:04-PDT
From: Jean-Pierre Dumas <[e-mail]>
Subject: C-Kermit 4C for Amdahl UTS 2.4

We have compiled Kermit 4.2 on UTS 2.4. It works very well (with "make v7";
we use a dummy function that always return 0 for initrawq in ckutio.c )

[Ed. - Thanks for the news!  I've added a comment to this effect to the
makefile.]

------------------------------

Date: Wed 26 Jun 85 04:32:52-PDT
From: Jean-Pierre Dumas <[e-mail]>
Subject: C-Kermit 4C for Fortune 16:32

Frank,

I insert ckuker.mak ckufio.c ckutio.c as modified for the fortune 16:32 by
Gerard Gaye.

[Ed. - The Fortune support has been fitted into KER:CKUKER.MAK, KER:CKUTIO.C,
and KER:CKUTIO.C.  It's mostly the same as 4.1bsd.]

As we are connected through an x25 network it should be possible to safely
by-pass some packet assembly/deassembly/coding... of kermit and rely on the
x25 pad to do the work...anybody working on that ???

[Ed. - The Kermit protocol is not layered well enough to do things like this.]

Jean-Pierre Dumas

------------------------------

Date: Thu, 20 Jun 85 17:32:51 pdt
From: psivax!woof (Hal Schloss)
To: ttidca!randvax![e-mail]
Subject: Fixes to Ckermit for the Valid Scaldstar System

We have a VAX 11/750 running BSD 4.2 that we talk to with Intel MDS's and
VALID Scaldstars.  We use the VAX to develop code that we download to the
MDS's and to provide remote services for the Scaldstars. In the course of
getting these to work I had to make changes to existing kermits to allow
communication to C-kermit on the VAX.

For the VALID systems I had to change all references to the variable cc in
the file ckucmd.c.  These were changed to ccx, the problem is that cc is
an internal variable for the VALID's assembler which blows up in an ugly
fashion if you declare a second time. I also had to replace a reference
to FREAD in ckutio.c as the VALID does not have this in it's include files.
I hope this works, it seems to so far.  To compile for the VALID include
the changes listed in diff -c format below (using patch?) and make bsd.

[Ed. - diffs omitted.]

By the way, I have implemented a remote line printer server for the VALID on
our vax, but I have to run kermit at 300 baud as the VALID has problems
above that speed. I don't know why though.

        Hal Schloss
        (from the Software Lounge at) Pacesetter Systems Inc.
{trwrb|allegra|burdvax|cbosgd|hplabs|ihnp4|sdcsvax|aero|uscvax|ucla-cs|
 bmcg|sdccsu3|csun|orstcs|akgua|randvax}!sdcrdcf!psivax!woof
 or {ttdica|quad1|scgvaxd|nrcvax|bellcore|logico}!psivax!woof
 ARPA: ttidca!psivax![e-mail]

[Ed. - This can be handled by adding an entry like this to the makefile:

#Valid Scaldstar
valid:
    make wermit "CFLAGS= -DBSD4 -Dcc=ccx -DFREAD=1"

I've added this to KER:CKUKER.MAK.  At some later time, perhaps some
of the commonly-objected to variables, like "cc" and "data" can be
renamed.]

------------------------------

Date:     Fri, 21 Jun 85 18:33:06 BST
From:     [e-mail]
Subject:  C-Kermit on Whitechapel MG-1 with Genix 1.3

I have managed to compile and run C-Kermit 4C(050) on a Whitechapel MG-1
workstation (See Byte magazine from first quarter '85).  This machine is
basically a Unix engine running Genix-1.3 which is essentially a bsd 4.1
system.  Only hitches were:

1) single call to getppid in ckufio.c was hardwired to 0 due to
   lack of this system call in Genix.

[Ed. - Sounds a lot like the Fortune support mentioned above.]

2) wart compiles fine but refuses to process ckcpro.w  stating
   that one of the defined dynamic states is undefined.  Older
   version of wart from c-kermit 4.2 also gives a similar error
   but a couple of states later.  Lex also wouldn't process it.
   I suspect that it is an obscure bug in my operating system.
   I haven't had the time or energy to chase it down.  Instead
   I worked around the problem by using the distributed ckcpro.c.
   I haven't the foggiest idea of what is wrong since wart seemed
   happy on a vax running bsd 4.2 and previous versions (4.2) of
   wart and ckprot.w worked fine.

Thus far, I have done only basic send/receive functions on the
Whitechapel using only text files.  Everything for the present
seems to be in order.   THanks for kermit!

Les J. Wu

[Ed. - I've added Les's hints to the makefile comments section.]

------------------------------

Date: Wed 26 Jun 85 17:45:38-EDT
From: Frank da Cruz <[e-mail]>
Subject: Unix-Like Systems Supported by C-Kermit
To: [e-mail]

The following list shows all the systems that C-Kermit has been reported to
work on (the Fortune, Valid, and Whitechapel changes announced above are
confined to the files KER:CKUKER.MAK (makefile), KER:CKUTIO.C, and
KER:CKUFIO.C).  I'd appreciate hearing from anyone who has it working on any
systems not listed here, so that I can add their machines and operating
systems to the list:

   Machine          Operating System      Machine          Operating System
    AT&T 3B Series   Unix Sys V            IBM PC/AT        Xenix/286
    Cadmus 68000     Unix Sys V            IBM 370 Series   VM/UTS 2.4
    CallanUnistar300 Unix Sys V            IBM 370 Series   VM/UTS v5
    Codata           Unix V7               NCR Tower        OS 1.02
    DEC VAX          Ultrix-32             NCR Tower        Unix Sys V
    DEC VAX, ...     Unix 4xBSD            PerkinElmer 3200 Unix V7
    DEC PDP-11       Unix 2xBSD            Pyramid 90x      Unix 4xBSD
    DEC PDP-11, ...  Unix V7               Masscomp         RTU 2.2
    DEC Pro-3xx      Venix V1              Motorola 4 Phase Unix Sys V
    DEC Pro-3xx      Venix V2              Plexus P60       Unix Sys V
    Fortune 16:32    For:Pro1.7            SUN              Unix 4xBSD
    HP-9836 S/200    HP-UX 200B            TRS-80 Model 16  Xenix
    HP-9000 S/500    HP-UX 3.25            Valid Scaldstar  Unix 4xBSD
    IBM PC/XT        PC/IX                 Whitechapel MG-1 Genix 1.3

Also, if anyone can claim that the current version does NOT work on any of
these systems, I'd also like to find out about that.  Thanks!  - Frank

------------------------------

Date: Fri, 14 Jun 85 13:20:15 -0300
From: mcvax!hut![e-mail] (Kimmo Laaksonen, Helsinki U of Technology)
Subject: Transporting C-Kermit to Eurosys-16 with Os9

Hi,
I'm forwarding the following mail (excerpt of) for your info:

    Date: 14 Jun 1985 1006
    From: SAHKOL.TAKALA
    To: LK.LAAKSONEN

    We are planning to transfer CKERMIT into a system called EUROSYS-16.  The
    operating system is OS9/68000.  The C-compiler we have running is done by
    Microware.  The version of CKERMIT we have got is 4.2(030).

    Petri Alhola, Lauri Aarnio
        Robcon OY
        Hankasuontie 9
        P. O. Box 9
        SF - 00391 HELSINKI
        Finland

    Juha Takala
        Helsinki University of Technology
        Power Systems Engineerin Laboratory
        Otakaari 5
        SF - 02150 ESPOO
        Finland

Electronic mail can be routed to the implementors through me.
Kimmo Laaksonen, mcvax!hut![e-mail].

[Ed. - Bob Larson, BLARSON%ECLD@USC-ECLA, is coordinating an effort to bring
up C-Kermit under Os9 on a variety of systems.  Maybe these two groups can
make contact, especially since Bob has access to the up-to-date C-Kermit
sources.]

------------------------------

Date:     Wed, 26 Jun 85 11:50:42 EDT
From:     Dr. Joseph M. Leonard <jmleonar@crdc>
To:       info-kermit@cu20b
Subject:  Dialing from C-Kermit on a 3B2?

This, hopefully, will be an easy one.  I have C-Kermit going on our 3B2, but
cannot get the dialer feature to work.  The "set modem racal" seems to work
(with the addition of an extra \r), but the "instant" that dialer tries to
do its stuff, DTR is dropped by the 3B2.  What I need is anybody who has
set up the /etc/inittab file to do this.  OR, if somebody using SysV.2.2 has
used racal modems to dial out, please let me know what I've missed...

                                                Joe Leonard
                                            <[e-mail]>

[Ed. - Has anyone done this?  If not, a new dialer module is expected soon
that might help in this area.]

------------------------------

Date: Tue, 28 May 85 11:53:40 pdt
From: hpl-opus![e-mail] (Ken Poulton)
Subject: C-Kermit 4x vs Line Locking, etc

Questions:
   1)     How does kermit do uucp line locking on 4.2 systems that
    (I understand) generally have /usr/spool/uucp owned by uucp
    and protected as 755 ?  Our system manager suggests that
    we should make kermit setuid uucp; is this commonly done?

   2)    Some of my uses of Kermit (a spooled print server, for instance)
    require that one script do the login, the next does a transfer,
    more transfers occur if they are queued, and then a script
    logs out.  Obviously, there needs to be a way to leave the
    line locked and open *between* Kermit invocations.
    I have addressed this with an eXIT command, (like berkeley mail)
    which exits the program without unlocking the line or dropping DTR.

    To make this work, I changed look4lk to swallow an existing lock
    file if the user is the owner.  (This, however, provides no
    protection if kermit is setuid!  This may require some id inside
    the lock file.)

[Ed. - This is probably a good idea, provided Kermit not setuid'd.  If I were
a Unix system manager, I'd think twice about making a program as big and
complex as C-Kermit setuid'd anyway.]

    To alleviate the problem of users leaving the line locked,
    I print a warning message and create a script in the user's home
    dir ("UNLOCKtty04") which can delete the lock and drop the line.
    To avoid confusion, I have disabled the 'exit' command.

[Ed. - Well...  Not to rehash all the old arguments, but there's simply NO GOOD
WAY to handle this situation over the entire family of Unixes.  Unix stupidly
lets anyone assign an appropriately protected tty, regardless of whether
someone else may also have it assigned.  Reasonable multiuser operating systems
allow access to devices like terminals and tape drives to one job or process at
a time, since there's no practical way that serial devices such as these can be
shared.  Many operating systems even have a tough time letting users share disk
files!  Anyway, because Unix blithely grants a tty device to as many users who
ask for it, the whole business of "line locking" came about.  Whoever it was
that invented uucp decided for the rest of us how lines should be locked: by
writing a file into a particular directory like /usr/spool/uucp or /etc/locks.
This requires that the user's process must have write access to that directory.
This is accomplished by (a) protecting the directory so that the public can
write into it (which opens the door to potential security problems); (b)
protecting the directory so that members of certain groups can write into it
(which requires the system manager to keep track of who's in what group); (c)
setting the process's user id to a privileged id or one that has owner access
to the lock directory (more security loopholes).  All of these approaches
require some action of the system manager in order to install a program that
wants to create locks, meaning that such a program is not user installable,
at least not unless condition (a) already prevails.  If one wants to find out
who is currently using a device, option (c) is not viable, since the user's
name will not appear as the creator of the lock file.

Assuming that all this can be set up, there still remain ___ major problems
with line locking:

1. Programs will always appear that do not honor the locking conventions,
defeating the entire purpose of the locking mechanism by simply ignoring it.

2. Programs that do honor the locking convention will occasionally leave lock
files behind (because the process was killed, the system crashed, or the
program itself crashed), preventing other users from using the device even when
it is free.

The trade-off, then, is whether it is better to err on the side of security
or on the side of letting users get their work done.  C-Kermit, in its present
form, makes various compromises.  If read or write access to the lock
directory is denied, the program issues a warning but allows the user to
proceed.  If a lock file exists for the specified device, the user is not
allowed to proceed, but is given an "ls -l" listing of the lock file to show
the file's creator and creation time.  Since C-Kermit does not allow access to
a locked line, it is very careful to get rid of lock files whenever it exits,
whether because a command-line invocation was completed, an "exit" command was
given, or an interrupt or quit signal was raised.

If users are given the ability to exit Kermit without releasing the line or
closing the lock file, many lock files will be left behind.  This is especially
likely because the intention of this feature is to facilitate running Kermit
from unattended scripts.]

    The other problem is that on Bell systems,
    we have no job control (sigh).  This means that we can't
    put a long transfer into the background after it starts.
    The eXIT command allows you to be using Kermit CONNECT
    for doing work, eXIT and do a transfer in the background,
    and re-CONNECT when the transfer is done.
    Perhaps Kermit should support background transfers directly...

[Ed. - I can see that the proposed eXIT command has its uses, but it really
supposes a friendly environment where everyone knows everyone else and can
chase them down when they leave a lock file behind.  But what happens when you
have Unix running on some huge timesharing system like a VAX 8600 or an IBM
3081 with 5000 users, and they're all leaving lock files behind, perhaps even
on purpose (maybe they're premed students...)?]

------------------------------

End of Info-Kermit Digest
*************************
-------
27-Jun-85 18:39:37-EDT,23374;000000000000
Mail-From: SY.FDC created at 27-Jun-85 18:39:12
Date: Thu 27 Jun 85 18:39:12-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #39
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu, 27 Jun 1985       Volume 2 : Number 39

Departments:

  ANNOUNCEMENTS -
    BITNET KERMSRV Reorganized
    IBM VM/CMS Kermit in Pascal

  MISCELLANY -
    MS-Kermit 2.28 H-19 Emulation for IBM
    Kermit Talk at National Prime Users Group
    Kermit-TSO and the IBM 7171 Front End
    About Commodore 64 Kermit V1.6
    Apple II Kermit Status
    C-Kermit Line Locking Problems, Cont'd
    C-Kermit Problems: HP-9000, Racal-Vadic Modems, etc

----------------------------------------------------------------------

Date: Thu 27 Jun 85 13:50:57-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: BITNET KERMSRV Reorganized

BITNET users who get files from the Kermit file server, KERMSRV at CUVMA,
will notice that the BITNET Kermit distribution area has been split in two
in the same way as the CU20B area, as described in Info-Kermit V2 #33.

Those who may have missed the announcement are encouraged to read the file
KER:AAAUPD.HLP on CU20B (AAAUPD HLP on KERMSRV) to see what was done.  In
particular, it should be noted that all the "bureaucratic" files (like lists
of versions, flyers, order forms, etc) have all been renamed to have names
starting with AA.

------------------------------

Date:    Fri, 7 Jun 85 16:47 EDT
From:    [e-mail]
Subject: IBM VM/CMS Kermit in Pascal

I have just sent you an updated version of my Pascalvs version of
KERMIT-CMS.  This version eliminates the use of the LINEMODE call and
thus can be run as a self-contained module and should work with any
other Kermit without modification.  There is a quick comparison of the
Assembler and Pascal version below.

COMPARING ASSEMBLER AND PASCALVS KERMIT FEATURES.

CMS Kermit Capabilities :        ASSEMBLER            PASCALVS

  Local operation:                   No                Yes
  Remote operation:                  Yes               Yes
  Transfers text files:              Yes               Yes
  Transfers binary files:            Yes               Yes
  Wildcard send:                     Yes               Yes
  ^X/^Y interruption:                Yes               Yes
  Filename collision avoidance:      Yes               No
  Can time out:                      No                No
  8th-bit prefixing:                 Yes               Yes
  Repeat count prefixing:            Yes               Receiving only
  Alternate block checks:            Yes               Yes
  Terminal emulation:                No                No
  Communication settings:            No                No
  Transmit BREAK:                    No                No
  Transaction logging:               Yes               No
  Session logging:                   No                No
  Raw transmit:                      No                Yes
  Act as server:                     Yes               Yes
  Talk to server:                    No                Yes
  Advanced server functions:         No                Yes  ****
  Advanced commands for servers:     No                No
  Local file management:             Yes               Yes
  Handle Attribute Packets:          No                No
  Command/init files:                Yes               No
  Command macros:                    No                No

 **** Advanced server commands DIR,ERASE,and TYPE have been
      implemented.   All of the advance server functions will
      respond if only to tell you it has not been implemented.

[Ed. - The files are in KER:CM2*.* on CU20B available via anonymous FTP
and as CM2* * via BITNET KERMSRV.]

------------------------------

Date: Wed, 19 Jun 85 17:36:58 pdt
From: [e-mail] (Dave Tweten)
To: Info-Kermit@CU20B
Subject: MS-Kermit 2.28 H-19 Emulation for IBM

MS-Kermit 2.28 msyibm.asm seems to have a bug, and what I interpret as
two "misfeatures".

The bug is that a line-wrap which requires a scroll-up does not produce
the scroll.  As a result, the wrapped portion of the line overwrites
the first part for as many wrappings as are required.  I observed this
by running "vi" on our 4.2 bsd system, using MS-Kermit 2.28 in H-19
emulation mode.  I viewed a file with long lines.  Line-wrap in the
middle of the screen worked properly.  So did scroll-down (backward)
through multi-line lines.  However, when I had "vi" scroll-up (forward)
through the file, each multi-line line that entered at the bottom of
the screen overwrote itself.  When I used ^L to tell vi to repaint the
screen, overwritten lines were displayed correctly.  When I repeated
the test, using MS-Kermit 2.27, everything worked correctly.  I haven't
yet had time to find the source of the problem.

The first of the "misfeatures" is the addition of line-wrapping backspace.
My copy of the H-19 Operation Manual says clearly (on page 12) that
backspace:

    Moves the cursor one space to the left.  If the cursor is at
    the start (left end) of a line, it will not move when you type
    a BACK SPACE.

I believe that if Kermit is going to be advertized as emulating an
H-19, it ought to do so.  I don't think this is a very serious
deviation, though, because I can't imagine a program sending a useless
backspace, confident that the H-19 will ignore it.  Still, why
introduce incompatibilities?

The other "misfeature", though, is serious.  H-19s will work in either
native or ANSI mode.  Almost all of Kermit's escape sequences are from
the native set.  Kermit's new "Enhanced Character Support" sequence
(ESC [ p1 ; . . . ; pn m) is the sole exception, being an extension of
one from the ANSI set.  Unfortunately, it conflicts with the native set
"ESC [" sequence (Enter Hold Screen Mode), which is not implemented in
Kermit.

Both sequences are correctly interpreted by a real H-19 because it has
two more sequences which are not implemented in Kermit, "Enter ANSI
Mode" (ESC <), "Enter ZDS Mode" (ESC [ ? 2 h).  To implement "Enhanced
Character Support" correctly, without stumbling over "Enter Hold Screen
Mode", the sequence should be honored only in ANSI mode.  That would
require it to become "ESC < ESC [ p1 ; . . . ; pn m ESC [ ? 2 h".  I
don't think the sequence is worth it without a general implementation
of ANSI mode.

One very good reason for Kermit to emulate an H-19 is that many systems
believe they already know about H-19s.  If this advantage is not to be
lost, Kermit must stay as close to the H-19 as possible.

------------------------------

Date: Thu 20 Jun 85 13:50:57-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Re: MS-Kermit 2.28 H-19 Emulation for IBM

One of our problems is that we don't have a real H19, and the H19 manual
that we once had has disappeared (anybody want to donate one to the cause?).
Our PC's get used a lot as terminals to our IBM mainframes, and it is common
on those machines to display files that contain lines a full 80 characters
long, with a CRLF at the end.  If you don't suppress LF after autowrap, then
these come out looking double spaced.  We made the change mainly to make our
IBM mainframe users happy.  Since this is inconsistent enough with the H19
definition to break "vi", we'll have to back out of this change; the next
release (2.28a, which contains fixes to the most glaring problems with 2.28,
namely the "get" filename truncation and the segment reordering) will
have this feature put back the way it was -- should be ready within a week
or so.

Having backspace wrap to the previous line was a suggestion from Greg Small
at Berkeley; I don't remember his motivation (Greg?).  Aside from the the
fact that this deviates from the H19 definition, can you think of any
functional reason not to do it?

We thought about the ANSI mode business a bit before we put it in.  It was
added because we needed the different kinds of highlighting for use with
3270 protocol converters (front ends for our IBM mainframes).  We noticed
that there was a potential conflict between native ESC [ and the ANSI
lead-in sequence.  But, we reasoned, since we don't support native ESC [
(can you think of any software that would send a hold screen command?), and
since we ignore unknown escape sequences (like Enter and Exit ANSI mode),
and since we're not trying emulate an ANSI terminal in all its glory, we
figured that no harm would be done.  If some software wants to use the
character highlighting and does that by sending "ESC < ESC [ p1 ; ... ; pn m
ESC [ ? 2 h" then it will work just fine.  It will also work if they just
send ESC [ p1;...;pn m by itself.  If they really want to send a hold screen
command, it will have no effect (unless, I guess, the following characters
can be interpreted as p1;...pn m).  But then, will any software that exists
ever actually send a hold screen command?  You'd think that if the software
did not want additional characters to be displayed on the screen, it would
simply not send them, but perhaps I'm naive...

I realize these are touchy issues, but in my view the H19 emulator in Kermit is
just a stopgap.  Soon, we expect to have a fully functional ANSI (VT102)
emulator available in the form of a loadable console driver, separate from
Kermit but distributed with it on the same terms.  At that point, I think the
H19 code will become superfluous and will eventually wither away.

- Frank

------------------------------

Date: Sat 22 Jun 85 04:00:45-PDT
From: Bob Larson <BLARSON%ECLD@ECLA>
Subject: Kermit Talk at National Prime Users Group
To: info-kermit@CU20B

A talk was given at the National Prime Users Group (NPUG) in Saint Louis
this week entitled "Kermit on the Prime: One shop's experience" by
Harvey J. Friedman of the International Pacific Halibut Commission.

The bug in Prime Kermit discussed in the talk was configuration dependant,
it only affects systems with printing characters for erase and or kill.
(It is also documented at Columbia in a .bwr file, but that file is not
in the distribution from Pulse (Prime users library...))

Apparently there is a need to cooridante the Pulse distribution with the
Columbia distribution.  I have heard that there is a new version on Pulse
that supports assigned lines.

Bob Larson <[e-mail]>

[Ed. - Prime Kermit has always been one of the most difficult to manage.
Another problem has been that Prime computers can't read any of the tape
formats in which we distribute Kermit, including ANSI labeled ASCII (the
standard format for information interchange agreed upon by all major
manufacturers).  Finally, in desparation, people in Prime's New York office
wrote a short Fortran program to read ANSI tapes, and we have to include a
copy of it on paper every time we send a tape to a Prime site.  Even if
Prime refuses to support industry standard tape formats, you'd think the
user group (Pulse?) could solve problems like this.]

------------------------------

Date: Wed 25 Jun 85 11:51:32-EDT
From: Wing Lee <WingLee%ECLD@ECLA>
Subject: Kermit-TSO and the IBM 7171 Front End
To: [e-mail]

I have the TSOS1.ASM file and it works fine with the Series/1.  But when we
replaced the S/1 with an IBM 7171, we started having problems.  The problem
was that when you were uploading to the TSO host, the file transfer would be
hung at random places.  When I used the debug option, on TSO kermit, I found
that the transfer would stop right after the first CHECKSUM error.
Downloading works fine, and KERMIT is able to handle CHECKSUM errors just
fine, but when uploading, it just stops.  I was wondering if anyone else was
experiencing problems similar to my, and if so, if anyone was going to add
support for the 7171 in the next release of KERMIT-TSO.

wing

------------------------------

Date: Wed 26 Jun 85 11:51:32-EDT
From: Daphne Tzoar <[e-mail]>
Subject: Re: Kermit-TSO and the IBM 7171 Front End
To: [e-mail]

It sounds like the problem you are having should be a protocol issue and
shouldn't be related to whether you are using a S/1, 7171 or 4994.  I'm not
sure why a bad checksum should affect the upload to TSO and not the download
from it.  But, I will forward your message to Info-Kermit and the author of
the S/1 TSO Kermit.  /daphne

[Ed. - To the best of our knowledge, the new VM/CMS Kermit works equally
well through straight ASCII async tty connections through 3705 and
equivalent front ends, through the Series/1 (4994?) front end doing 3270
protocol conversion, and likewise the 7171 front end.  We hope that someone
at a TSO site will find a way to convert VM/CMS Kermit to TSO in such a way
that it can be built for either VM/CMS or MVS/TSO, either by conditional
assembly or by moving system-dependent primitives to a special module,
like C-Kermit or MS-DOS Kermit.  Then, whenever the program gets fixed or
improved, everyone will benefit at once.]

------------------------------

Date: 26 Jun 85 19:08:07 EDT
From: Eric <[e-mail]>
Subject: About Commodore 64 Kermit V1.6

I neglected to include a suitable .INI file in the kermit distribution,
which is losing since it really needs an init file right now to startup in a
sane manner.  You can instruct people with older versions of kermit to
download this file as an ascii seven-bit file before starting up the new
Kermit.

[Ed. - This file is now in KER:C64KER.INI on CU20B.  It contains a strange
looking sequence of control characters -- don't be alarmed when you see them.]

By the way I thought I'd take this opportunity to address some of the
questions you've been sending my way lately (I've been really busy with a
new job and all):

Using C64 Kermit with a tape drive:

Very simply put, you can't.  That is not without adding to the program and
not without huge delays in transmission.  The C64 operating system uses the
same memory locations for the RS232 routines and the tape drive timing (both
of which are critical).  I do *not* plan on adding any support whatsoever
for the tape drive.

Using Kermit with the C128 (no one's asked yet, but just in case):

It should be easy to use Kermit in C64 mode on the C128.  There *should*
also be no problem with using it in 128 mode, but it would make more sense
to use the native screen mode for 80 columns.  Since I don't have a 128 (and
don't plan on getting one), I cannot evaluate what is necessary to take
advantage of this.  Anyone else who is interested in doing this should feel
free to give it a crack.  The C128 should work nicer in native mode due to
the faster disk drive.  On the other hand, you may just want to use CP/M
Kermit on it.

Eric

------------------------------

Date: Thu 27 Jun 85 00:20:45-EDT
From: Peter G. Trei <[e-mail]>
Subject: Apple II Kermit Status

>Date:  Mon, 24 Jun 85 14:09 MDT
>From:  "Mike Armstrong {mba}" <[e-mail]>
>Subject:  Apple 2 kermit

>Would you please tell me the current status of the Apple 6505 version of
>kermit.  The latest version I have is V2.1 (V2.1A??) updated 30-JUL-84
>by Peter Trei (original by A.N.J. Moine)

Version 2.1a is still the latest released version. Development has is
currently rather slow: both Anton's and my real-world workload have
substantially increased in the past year, and I have been able to do rather
little for 4-5 months, and Anton none. (I am still distributing several
copies a week by mail).

If you feel like contributing code, my only request is that you inform me
and Anton about it before you start, to advoid duplication of effort.
Outstanding desired features and bugfixes include:

[Ed. - Anton indicates that he is out of the Apple II Kermit business now
and Peter should be regarded as the sole proprieter.]

    1: On Apple 2c's, the cursor produces a bogus character when placed
       over a lowercase alpha character. (Its ok after you move again).
    2: Command files, so you can set up and dial your kermit more easily.
    3: Support for the Videx and Apple 2c/e 80-column cards. (This is more
       easily said than done. If you want to know why, ask me.)
    4: Support for more varieties of serial interface (my current project).
    5: A better bootstrapping procedure.
    6: Server capability (a real toughie, since most apples have no clock).
    7: VT102 emulation.
    8: ProDos kermit. I am currently awaiting the arrival of my
       order for a 'native code, optimising, ProDos Pascal compiler'.
       6502 assembler can be macho, but its also a pain in the b*tt.

If you feel like taking any of these on, please tell me about it. I have a
number of ideas (and some code) for most of them.  Everything being equal, I
expect to have a release out late summer/early fall with at least 3 and 4
fixed, more if possible.

>I am looking for a version that, in addition to the capability of V2.1,
>also handles the 80 col screen card and has the "insert-line",
>"delete-line", "delete-chars" and the "insert-chars"/"end-insert-chars"
>capability in the terminal emulation (for use with Multics full screen
>editing and menu features).  Kermit65 acting as a server would also be
>very nice.  However I don't have access to a Dec Tops/20 system to run
>the CROSS assembler so I cannot modify the source.  (And I'm not
>convinced of my capability of doing it properly anyway.)

This is the VT102 emulation I mentioned earlier. I agree, it would be nice,
and I would like to include (I use Emacs too).

>Mike Armstrong - Honeywell, Canada (from University of Calgary's Multics
>                 system).

                Peter Trei
                oc.trei@cu20b
                h: 212-5692371
                w: 212-8153711

------------------------------

Date: Wed, 26 Jun 85 20:52:43 pdt
From: Scott Weikart <cdp!scott@Glacier>
Subject: C-Kermit Line Locking Problems, Cont'd

Instead of setuid, I think it would be much better to operate setgid.  Then the
ownership of the lock file would be intact.  I put uucp, cu, kermit, etc in a
group called dialer, for such situations.  But then you have to convince your
administrator to allow /usr/spool/uucp to be writable by group (in my opinion,
this is much safer than making kermit setuid, especially if you keep regular
users out of the group).  This has one annoying side-effect; kermit will no
longer be able to create a file in a directory that's not writable by the user
but is writable by the group that the user's shell is in [this is fixable for
system 3 and 5 - i'll send the code along - but not in v7 or BSD].

Another thought; if you did something like the above which would allow the user
to own the lock file (or if you write the uid into the lock file), then maybe
you could do the following to do a multi-stage kermit.  start up a kermit,
connect, pop back to kermit and fork a sub-shell, then allow the user to start
up another kermit as long as she owns the lock file.  I think this will work,
even though the original kermit still has the tty open.  The user would not be
able to log out without exitting the original kermit.  Of course, once the user
pushes a subshell she might forget about the open line until she logs out; it
would be nice to change the prompt in the subshell, but i'm not sure how to do
it in an exec.

[Ed. - Further contributions to this discussion are welcome.  If the WHOLE
WORLD can come to a concensus about how Unix line locking should work, we can
make the program abide by it.  But then somebody has to write the installation
manual, the user manual, and the environmental impact statement...]

------------------------------

Date:  Thu, 27 Jun 85 15:22 EDT
From:  [e-mail]
Subject:  C-Kermit Problems: HP-9000, Racal-Vadic Modems, etc

I was able to get the kermit package working on our HP-9000's.  They
have a problem, however.  I can call a foreign host (even myself),
login, run kermit on the foreign host and get files from the foreign
host OKAY.  However, when I try to send stuff to the foreign host, I
have problems with packet sizes larger than 70 characters.  I viewed the
data flow through the modem with a protocol analyzer and it seems that
everything looks okay:  the sender keeps resending packets that are
NAK'ed by the foreign host.  Even with packet sizes of 70, the sender
has to resend each packet something like ten times.  At packet sizes of
around 40, the situation is much better.  i don't THINK my lines are
excessively noisy (running "log packets" on either machine seems to
support this), but I'm confused.

[Ed. - Sounds to me like HP-UX has small input buffers for its serial
ports, and can't accept bursts longer than 40-70.  Not much you can do about
this short of fooling with the kernel, or complaining to the vendor.]

Another thing:  we have racal-vadic modems that do not conform to the
protocol that ckudia.c employs.  Apparently, the old Racal Vadic's used
to send "ON LINE", and the new ones (at least the Maxwell series, as
well as the -PA and -PAR series) send "ONLINE" (your code searches for
"ON LINE").  Secondly, your code "acknowledges printout of dialing string"
by sending an extra <CR> after "(number)<CR>" when dialing the number.
The old Racal Vadic's required the extra <CR> --- the NEW ones, however,
do not.  IN FACT, the new ones abort the dialing sequence when they
receive the extra <CR>.

Obviously, I had to change these two things when I wanted to get kermit
working -- I felt you might want to pass some of this information on to
others.  The "ON LINE" vs.  "ONLINE" discrepancy is not guaranteed by
Racal Vadic to be cleared up:  some models MIGHT use one, and others
might still use the other.  The business with the extra <CR> will go
away:  I was guaranteed that Racal Vadic's won't require it from now on
(the newer models, that is).

[Ed. - Yuk.  I guess this means we another modem type has to be added to
ckudia.c -- "NewRacalVadic".  Alternatively, the code can be changed to do
something like what is done for the Hayes, which also has two ways of
answering ("verbal" and "nonverbal") -- feed it some innocuous command whose
response will tell you if it's a new or old style modem, and then set a flag
to that effect, which is used to control further interactions with it.  This
method is preferable to simply adding "NewRacalVadic" as another modem type,
because how is the poor user to know whether her Racal-Vadic is new or old?]

One question:  is there any effort by you folks to support Codex short-
haul modems in the near/distant future?  Is there any perceived need?
(actually, I guess that's two questions)

[Ed. - The new ckcdia.c module is much easier to add new modems to than the
old one was, thanks to reorganization by Dan Schullman.  Dan is currently
working on yet another release of that module; when that's ready, I'd
encourage you to add support for "NewRacalVadic" and "Codex" to it and send
it back to us.]

Thanks for your help.  ---Matt G.

------------------------------

End of Info-Kermit Digest
*************************
-------
28-Jun-85 18:10:53-EDT,10393;000000000000
Mail-From: SY.FDC created at 28-Jun-85 18:10:22
Date: Fri 28 Jun 85 18:10:22-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #40
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 28 Jun 1985       Volume 2 : Number 40

Departments:

  C-KERMIT -
    Yet Another Unix Kermit Release (minor)
    MacKermit Observations

  MS-DOS KERMIT -
    Bug in MS-Kermit 2.28 and Tandy 2000 support
    MS-Kermit Reverse Wrap at Column 1

  MISCELLANY -
    FTP Problems on CU20B

----------------------------------------------------------------------

Date: Fri 28 Jun 85 17:12:33-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Yet Another Unix Kermit Release (minor)
To: Info-Kermit@CU20B

This is to announce C-Kermit 4C(055).  No major changes, mainly just some
enhancements to the dial command, support for a some additional systems and
modems.  Here, for those who understandably have a hard time keeping up with
all this, is a list of changes since 4C(052) was announced on June 18:

C-KERMIT FOR UNIX, CHANGES FROM 4C(054) TO 4C(055), 28 JUNE 85:

ckudia.c (all changes by Dan Schullman, DEC):
. Add support for US Robotics modem (untested) from Joe Orost at Berkeley.
. Reorganize MDMINF data structure to accommodate US Robotics (some char
   fields had to become strings).
. Allow interrupts (SIGINT, e.g. ^C) to cancel dialing in progress.
. Ring bell when connection made successfully.
. Close line on failures.
. Allow stored numbers with DF100 and 200 modems.

ckudia.c now supports the following modems:
. Cermetek Info-Mate 212 A
. DEC DF03-AC
. DEC DF100 Series
. DEC DF200 Series
. General Data Comm 212A/ED
. Hayes Smartmodem 1200 & compatibles
. Penril
. Racal Vadic
. US Robotics 212A
. Ventel
Plus "unknown" modems and direct (modemless) connections.

C-KERMIT FOR UNIX, CHANGES FROM 4C(053) TO 4C(054), 25 JUNE 85:

ckuker.mak (makefile):
. Add "make ft17" for Fortune 16:32 For:Pro 1.7.
. Add "make uts24" for Amdahl UTS 2.4
. Add "make valid" for Valid Scaldstar CAD system
. Add "make c70" for BBN C/70 IOS 2.4

ckcmai.c:
. Add call to sysinit()

ck[uvm]tio.c:
. Add sysinit() function.  For VMS, open console.  For others, null for now.

ckutio.c, ckufio.c:
. Add support for Fortune 16:32, mostly like 4.1bsd.
. Ditto for Amdahl UTS 2.4, mostly like V7.

ckuus2.c:
. Expand a couple tabs in hlp1 (-h help message) so things line up right.


C-KERMIT FOR UNIX, CHANGES FROM 4C(052) TO 4C(053), 21 JUNE 85:

ckcfn2.c:
. Change dopar() to be of type CHAR.
. Fix dopar() to calculate odd parity correctly.

ckucon.c, ckuscr.c:
. Add "extern CHAR dopar();" declarations.

The files, as usual, are in KER:CK*.* on CU20B, available via anonymous FTP.
There's no real need to get them unless one or more of the changes listed
above is of use to you.

------------------------------

Date: Fri 28 Jun 85 10:32:33-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: MacKermit Observations
To: manis%ubc.csnet@CSNET-RELAY
In-Reply-To: Message from "Vincent Manis <manis%ubc.csnet@csnet-relay>"
 of Thu 27 Jun 85 22:49:46-EDT

    >Date: Thu, 27 Jun 85 19:42:15 pdt
    >From: Vincent Manis <manis%ubc.csnet@csnet-relay>
    >To: info-kermit@CU20B
    >Subject: MacKermit
    >
    >I've been using MacKermit for a week or so (0.8 (28)), and would like
    >to know whether the following are intended to be fixed:

We're up to 0.8(32) now...

    >1) If I tell my local Unix that I'm a VT100, emacs has difficulty
    >   refreshing the screen properly. Is the VT102 emulation imperfect,
    >   or simply different enough from the VT100 that I should make a new
        >   termcap entry?

We use Mac Kermit with EMACS (both CCA and GNU) at 9600 baud on our VAX/Unix
system and have not seen this problem.  We tell it we're a VT100 since our
EMACS's (or termcaps) don't yet have support for VT102.  See if 0.8(32)
exhibits the same behavior.

    >2) I'd like the ability to include an initial character string to send
    >   automatically when I fire up a settings document. This would
    >   provide some modem support (even if not terribly well).

A reasonable idea; we'll add it to the list of things to do.  A lot of other
things have higher priority though, like screen save/print, saving lines off
the top, cutting/pasting the screen, sizing the screen, allowing international
character sets, etc.

    >3) Any possibility of mouse support (clicking the mouse somewhere away
    >   from the current cursor position would send the requisite cursor
    >   positioning string)?

I doubt it.  The program is already straining the limits of a 128K Mac.

    >4) Why doesn't KerKey have the ability to create a new settings
    >   document?  Why can't the settings menu from MacKermit be included
    >   in KerKey as well?  This would allow one to create a complete
    >   settings file at one time.

Simply a question of not having enough time to write the code.

    >5) I've had some sort of transient behaviour in which the first file
    >   transfer in a session works ok, but subsequent ones just hang.
    >   Firing up MacKermit again seems to cure the problem, but it's a
    >   nuisance. (On the Unix end, this happens with both CKermit and the
    >   old Unix Kermit, but not with enough regularity for me to pin it
    >   down).

You're not using parity, are you?  If so, get 0.8(32), which fixes problems
with parity.  Otherise, it's hard to know what to say about this without more
details about what machine, what Unix, what version of C-Kermit, what kind of
connection, what baud rate, etc etc.  This kind of behavior is always a
possibility between any two Kermits and usually has more to do with the
operating systems or communications equipment that Kermit itself.  For
instance, if you're running 4.2 bsd on a VAX with DMR's, you might be suffering
from problems in Berkeley's DMR driver.  Some other systems just get tired of
allocating tty buffers after a while...  We've used MacKermit to transfer very
large batches of files at high baud rates without observing any consistent kind
of failure.

    >6) The key in the upper right hand corner is labelled ``Backspace''.
    >   By default it should generate a backspace.

Matter of taste.  You can always type a backspace using CTRL-H, but how do you
type a DEL if there's no DEL key?  Anyhow, that's what KerKey is for -- so
people who don't like the defaults can change them.

To be perfectly honest about the situation, Mac Kermit is "between maintainers"
just now.  The last two people who worked on it have both left, so I expect it
will stay pretty much as it is for quite some time.

- Frank

------------------------------

Date: Thu, 27 Jun 85 19:04:46 cdt
From: [e-mail] (Phil Goldberg)
Subject: Bug in MS-Kermit 2.28 and Tandy 2000 support

When you type 'C?' from the command prompt, instead of getting a 'Confirm with
CR' message as in 2.27, you get a list of all commands from C-Z displayed.
Since C is a valid command, isn't this a bug.  I looked, but I couldn't figure
it out.

[Ed. - Hmmm... must have something to do with C being a synonym for CONNECT
(necessary because of the addition of the CLEAR command).  Added to the list of
bugs, KER:MSKERM.BWR.]

Steve Alexander has done mods to MSX/YIBM to get a Tandy 2000 module for
v2.28.  He swears up and down that this time he will send them in.

                    Phil Goldberg
                    goldberg@Uiuc
[Ed. - Hope so...]

------------------------------

Date: Thu, 27 Jun 85 17:44:22 pdt
From: gts%ucbpopuli.CC@Berkeley (Greg Small)
To: info-kermit@cu20b
Subject: MS-Kermit Reverse Wrap at Column 1

The backspace from column 1 to column 80 of the previous line was added for
UNIX.  For normal input echoing, UNIX assumes that the terminal handles all
margin wraping.  This includes both the normal forward wrap at the right margin
and the less known reverse wrap at column 1.  Many newer terminals do both.
ANSI X3.64 enumerates some margin actions but does not specify any.

Of course this only impacts those who enter and then wish to erase characters
from lines longer than 80 characters.  I had thought than no one would care,
but our beta test release of MS-Kermit 2.27 turned up a number of users who
complained that they could not erase characters accross the line wrap.

I confess that I am not overly concerned with exact emulation of the
limitations of the H19, our priority is delivering functionality.  However we
do try to avoid extensions which are likely to cause dificulties.  Actually,
we have abandoned pretending that a particular program emulates a real
terminal.  We now treat each emulator and version thereof as a seperate
terminal type.


Greg Small                              [phone]
Microcomputer Communications            [e-mail]
214 Evans Hall CFO                      ucbvax!ucbpopuli!gts
University of California                [e-mail]
Berkeley, Ca 94720

------------------------------

Date: Thu, 27 Jun 85 17:16:57 pdt
From: [e-mail] (David Ragozin)
Subject: FTP problems on CU20B

Today I tried to FTP some of the vms*.mar files on k2:.  None of them
would come.  Each time I tried (with "TYPE ASCII") I received the
error message: File not 7-bit - not text file.  That sounds to me like
a problem at your end, not mine.  Could you have someone check it out?

[Ed. - Oops!  The bytesize was indeed 36, rather than 7.  This is fixed
now.  Surprised nobody reported this before.  In fact, all the following
files had 36-bit bytesizes, which are now changed to 7:

    AP2KER.ASM
    AP2KER.TXT
    APPLEK.M65
    CP4CPT.HEX
    CPMH8.HEX
    CPMPRO.HEX
    K10MIT.CCL
    K10V3.MEM
    MTSKERMIT.ASM
    MTSKERMIT.DOC
    MTSKERMIT.PAS
    PROV1.MEM
    RTED.TXT

Sorry for the confusion; most of these files were created by TOPS-10
utilities that run on our DEC-20 system.]

Also, is there some reason you know why I haven't been able to get any
response from KERMSRV on BITNET for many days?

[Ed. - KERMSRV has been undergoing reorganization the last few days.
Should be up now.]

------------------------------

End of Info-Kermit Digest
*************************
-------
2-Jul-85 19:54:13-EDT,10370;000000000000
Mail-From: SY.FDC created at  2-Jul-85 19:53:39
Date: Tue 2 Jul 85 19:53:39-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #1
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue,  2 Jul 1985       Volume 3 : Number  1

                  New Release of Kermit-11 Available
        Unix Program for Converting CU20B FTP Server Filenames
                      Mac Kermit & Caps Lock Key
              IBM PC Kermit and National Character Sets
                  MS DOS Memory Allocation in Kermit
                         More about ND-Kermit
                       Kermit Versus 9600 Baud

----------------------------------------------------------------------

Date: Tue 2 Jul 85 19:50:57-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: New Release of Kermit-11 Available
Keywords: Kermit-11

Brian Nelson of the University of Toledo (BRIAN@UOFT02) has sent in version
2.29 of Kermit-11, replacing version 2.26 of March 1985.  The changes include:

. Fix losing attribute packets in case timed out or nak'd.
. Fix ASSDEV: for stack problem
. Added SET BINARY-TYPE .xxx for overriding the built-in binary file type list.
. Kludge if RT system does not have a clock.
. Ignore TYPE in SET FILE [TYPE] arg.
. Final mods by Ned Rhodes for TSX+
. Add support for server REM DIR command for RT and TSX+.
. Fix bug for setting 8bit prefixing (quite noticable on PRO/RT version).
. Add SET FIL [NO]SUPERCEDE to protect files that already exists.
. Update packet types to symbolic names

The files are available via anonymous FTP from CU20B as K2:K11*.* (many files).
General information is in K2:K11AAA.AAA.  The files are listed and explained
in K2:K11FIL.DOC.  Installation instructions are in K11INS.DOC.

------------------------------

Date: Tue 2 Jul 85 15:50:57-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Unix Program for Converting CU20B FTP Server Filenames
Keywords: FTP Server, UNIX

Many have complained that when getting (especially "mget"ing) files to a Unix
system from the CU20B FTP server, the resulting filenames are not what would
be desired.  This problem is partially fixed by the installation of a new FTP
server that allows users to CWD (CD) to a given directory for read access, so
that the fully qualified file name need not be sent back for each file gotten
with an "mget".

However, even if you CWD to KER: or K2: before issuing an mget command, the
files will still show up with uppercase names and will include "generation"
(version) numbers.  And of course, if you fail to CWD first, you still get
the directory name too, so that you are likely to find files with names like

<KERMIT>CKUFIO.C.3

in your Unix directory, rather than the ckufio.c you might have wanted.

A new program, xxu (20-to-Unix filename converter), is available in KER:XXU.C
which will fix the names of all files sent to a Unix system from a DEC-20 FTP
server.  It should work on VMS and DEC-20 filenames alike -- it strips DECnet
node names, device names, directory names, generation numbers, and it
lowercases the uppercase letters.  When renaming to the name thus formed, it
takes care not to write over any existing files.  See comments in the source
for further details.

------------------------------

Date: Fri 28 Jun 85 15:52:03-EDT
From: Mauricio Matiz <US.MATIZ@CU20B>
Subject: Mac Kermit & Caps Lock Key
Keywords: MacKermit

Now that Kermit for the Macintosh has a keymap program that allows mapping of
the control key to the caps lock key, the locking mechanism becomes a
nuisance.  There have been postings about taking the whole keyboard apart and
using a soldering gun, etc. in order to remove the locking mechanism.  I have
come up with a simpler and easier method that does not void your warranty.

Remove the key using a small screwdriver.  There is a spring and the end of
it goes through the plastic that supports the key. Stick a piece of paper or
soft putty (very small) between the tip and the bottom of the keyboard.  This
will prevent the key from depressing all the way and locking, but still allow
contact of the key.  It even works for repeating control characters.  If you
come up with a better substance to stick in there let me know (or the Kermit
people at Columbia).  I have been using this for some time with no problems.
I imagine that after a while I will need to change the paper because of the
continued pressing on it.

Maurice Matiz
Columbia University
User Services

[Ed. - As usual, neither the author of this message nor Columbia University
acknowledges any liability for damage or loss of warranty incurred by anyone
who follows these directions.]

------------------------------

Date: Sat, 29 Jun 85 14:43:27 -0200
From: Frithjov Iversen <iversen%vax.runit.unit.uninett@NTA-VAX>
Subject: IBM PC Kermit and National Character Sets
Keywords: MS-DOS Kermit

A suggestion for IBM PC Kermit: You must be aware of that many european
characters have a different internal representation on the IBM PC and other
computers.  The norwegian alphabet, for example, has 3 extra characters,
which in normal ASCII replaces [\] (upper) and {|} (lower case).  On the IBM
PC, all these characters are represented with values in the range 128-255.
This means that every terminal emulation program (to have a chance on the
Norwegian market) must include an option to convert between the two
standards, both when acting as a terminal and when transferring files.

We have a local mod to MSSET and MSYIBM which fixes the terminal problem,
and provide a converting program on the Kermit diskette to convert the text
files.  However, I feel that this must be a problem in other European
countries, and I was hoping for a more general solution.

The SET KEY feature will make it possible to do terminal emulation with a
"national" keyboard, but the right characters will not appear on the screen.
Why not include a SET FONT command?  For Norway, all that would be needed,
was 6 SET KEYs and 6 SET FONTs in a macro defined in MSKERMIT.INI, and we
could do without the local mods.  As to transferring files, I prefer the
"raw" approach, and leave conversion to the user.  When transferring MASM or
PASCAL programs, I do not like to see my square brackets turn into
you-know-what.

[Ed. - Good idea, though I'm not sure if you mean "set font" or "set
character".  A font would be a whole character set, presumably some
alternate character set in ROM, invokable by changing some pointer.  This
would probably be easy to implement, though the details would be very
system-dependent.  Changing how individual characters display would be
harder, not so much to implement, but to design the command -- the user
would need to say something like "if I get a character whose ASCII value is
x, then display character y from font z in its place..."]

------------------------------

From: [e-mail]
Date:   30 Jun 85 14:19 EDT
Subject:  MS DOS Memory Allocation in Kermit
Keywords: MS-DOS Kermit

Well, I finally found the problem with memory allocation and (Microsoft) I
was missing something crucial. KERMIT as part of its memory initialization,
gives extra memory back to DOS explicitly. Unfortunately, the calculation of
the image end assumes that the stack segment is not last.  My apologies to
those people that I confused from an incomplete investigation of the
problem. I still object to the IBM versions of Micro- softs programs being
built with new defaults, but in this case it only confused matters instead
of being the root of the problem.

To address the issue of memory allocation directly, if segment ordering
becomes so important, perhaps the required space should be calculated from
the load module image size and not from the offset of a specific object file
in KERMIT.  Is there some reason why this is undesireable?

Jerry Lotto     [e-mail]      inhp4!harvard!lhasa!lotto

------------------------------

Date: Sat, 29 Jun 85 14:43:27 -0200
From: Frithjov Iversen <iversen%vax.runit.unit.uninett@NTA-VAX>
Subject: More about ND-Kermit
Keywords: ND Kermit

The operating system of the ND series computers is SINTRAN III.  Versions are
numbered with the letters A,B,..  The Kermit I sent you runs under version J,
and needs the Pascal-J compiler and library.  The binary program,
KERMIT:PROG, should run under previous versions, at least back to H.

Anyone who sends us a self-adressed diskette envelope with one 148-page 8" ND
diskette (two if you need source code), will receive the latest version of
ND-Kermit for free.  There are plans to include SERVER and CONNECT later this
summer.

          Frithjov Iversen
          RUNIT Brukerkontakt
          N - 7034 Trondheim-NTH
          NORWAY

------------------------------

Date:  Sat, 29 Jun 85 22:56 EDT
From:  [e-mail]
Subject:  Kermit Versus 9600 Baud
Keywords: Modem, Sliding Windows Kermit

I've been experimenting with a 9600 bps dialup modem.  It is cheap (about
$800).  It is really a half duplex modem that provides a full duplex
interface and a reliable byte stream.  This is fine, except when one uses
protocols such as Kermit and Xmodem which have only a single packet in the
stream at a time.  It takes .5 seconds or more to turn around the line.  Thus
sending a packet, acking and sending the next one reduce one to 1 second/
package or about 900 bps for kermit and about 1200 for Xmodem.  This is the
same as the problem of satellite links.

Given that such modems make a lot of sense since they make more effective use
of the bandwidth for file transfering than true full duplex modems, what
thought has been given to upgrading Kermit to allow for a protocol that can
have multiple packets active at once?

I presume that there has already been much discussion of this, but now that
it is my ox being gored, I have a special interest in this issue.

[Ed. - For a couple years, people have been asking for (a) a sliding window
extension to the Kermit protocol, and (b) a way to have longer packets.
Some people are working on a sliding window protocol, and a proposal will
be posted to Info-Kermit some time soon.  At the same time, I'll also post
a proposal for a way to allow longer packets.]

------------------------------

End of Info-Kermit Digest
*************************
-------
 9-Jul-85 18:04:18-EDT,20303;000000000000
Mail-From: SY.FDC created at  9-Jul-85 18:03:13
Date: Tue 9 Jul 85 18:03:13-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #2
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue,  9 Jul 1985       Volume 3 : Number  2

                 KERM and KERK Registered with Apple
                           Okstate Downtime
               Re: MS-Kermit 2.28 Wraparound Backspace
                            MASM & Kermit
                       C-Kermit on HP-9000 S500
                        C-Kermit Line Locking
                          UUCP Line Locking
              Running Pro-3xx P/OS Kermit from Tool Kit
                         Bug in Prime Kermit
                      More about 9600 bps Modem
             More about PC-Kermit and National Characters
                   Z100 Comunications Program Query
                        Kermit on MicroVAX-1?

----------------------------------------------------------------------

Date: Mon 8 Jul 85 18:04:31-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: KERM and KERK Registered with Apple
Keywords: Macintosh

The Macintosh application names KERM and KERK have been registered with
Apple for Macintosh Kermit and for the Macintosh Kermit Keyboard
Configurator, respectively.  These names allow "documents" (e.g. settings
files) created by these programs to be associated with the programs
themselves so that double clicking such a document will invoke the program
with the indicated settings.

------------------------------

To: [e-mail]
Subject: Okstate Downtime
Date: 09 Jul 85 06:43:11 CDT (Tue)
From: [e-mail]
Keywords: Okstate

The system `Okstate' will be down for hardware and software upgrade from
8:00 a.m. July 17th until 5:00 p.m. July 22 (all times central).  During
this time the UUCP and Kermit Server line used for the Kermit Distribution
will not be available.

Mark Vasoll
Department of Computing and Information Sciences
Oklahoma State University

UUCP:  {cbosgd, ea, ihnp4, isucs1, mcvax, pesnta, uokvax}!okstate!vasoll
ARPA:  [e-mail]

------------------------------

Date: Tue, 2 Jul 85 18:20:31 pdt
From: [e-mail] (Dave Tweten)
Subject: Re: MS-Kermit 2.28 Wraparound Backspace
Keywords: MS-DOS Kermit, UNIX

In Info-Kermit Digest, volume 2, number 40, Greg Small writes:

    The backspace from column 1 to column 80 of the previous line
    was added for UNIX.  For normal input echoing, UNIX assumes
    that the terminal handles all margin wraping.  This includes
    both the normal forward wrap at the right margin and the less
    known reverse wrap at column 1.  Of course this only impacts
    those who enter and then wish to erase characters from lines
    longer than 80 characters.

That confuses me.  My impression is that bsd UNIX uses curses and termcap
entries to perform terminal independent smart terminal operations.  This
includes simulation of wrap-around backspace for terminals whose termcap
entries do not contain the "bw" ("backspace wraps") specifier.

My impression is reinforced by observation of "vi" behavior with long lines.
I used MS-Kermit 2.27 (which correctly emulates H-19 backspace behavior) in
linewrap mode.  On multi-row lines, right arrow and space moved me from
column 80 on one row to column 1 on the next.  Left arrow and backspace
moved me from column 1 to column 80 of the previous row.

    Actually, we have abandoned pretending that a particular
    program emulates a real terminal.  We now treat each emulator
    and version thereof as a seperate terminal type.

This seems to me to be a sad commentary on the current state of design and
implementation of most terminal emulation packages.  It is also a little
frightening to consider what this means if you multiply the number of
available terminal emulators (say, for just the vt-100) times the number of
different operating systems which think they know about the terminal being
emulated.

Particularly in the case of Kermit, where Columbia and the user community
have control over the quality of the emulation, it seems to me to make much
more sense to emulate the H-19 well enough that it fools (almost) all the
systems which think they know about it.  Users whose systems require a more
faithful emulation than is currently provided should be encouraged to
contribute Kermit code modifications.

Finally, let me reiterate that though I believe strongly in faithful
emulation, and though I can't see how UNIX could require wrap-around
backspace, I don't think wrap-around backspace represents a serious
deviation from the ideal H-19 emulation.  I can't imagine that it is common
for programs to send column-1 backspaces to H-19s, realizing that they will
be ignored.

[Ed. - We have received a couple H-19 (Z-19) manuals in response to our plea a
couple issues ago (thanks to those who sent them!), so we should now be able to
emulate this terminal more faithfully...]

------------------------------

From: [e-mail]
Date:   28 Jun 85 11:18 EDT
To: harvard![e-mail]
Subject: MASM & Kermit
Keywords: MASM

If you are building KERMIT with the Microsoft assembler (any version) or the
IBM release (pre 2.0) all will work as written.  If however, you are using
MASM 2.0 or later (IBM release) you must specify the /S switch on the command
line for MSXDMB.  Be sure the Linker you are using does not predate the
version of DOS by too much.  Also, make sure you actually DO have enough
memory to run KERMIT in.  A fairly significant chunk of RAM is used by the
new KERMIT, but unlike the previous version, it is allocated by the program.

Gerald Lotto - Harvard Chemistry Dept.

 UUCP:  {seismo,harpo,ihnp4,linus,allegra,ut-sally}!harvard!lhasa!lotto
 ARPA:  [e-mail]
 CSNET: lotto%harvard@csnet-relay

------------------------------

Date:  Wed, 3 Jul 85 12:16 EDT
From:  [e-mail]
Subject:  C-Kermit on HP-9000 S500
Keywords: C-Kermit, HP9000

I solved that packet-size problem I was having (calling out and trying to
send from my HP9000 Series 500).  Apparently, I have to tell the remote host
that I am a vt100, or I get into problems.  At least, when I did call myself
a vt100, I was able to send with no problems.

The obvious inconvenience hewith this is that since I really am using an
HP2392A terminal, fun things like EMACS die big if I'm trying to use Kermit
in the same login session.  Oh, well.

[Ed. - Could it be that by telling the host you are a VT100, you turn on
its XON/XOFF flow control?  Maybe you could tell it you're an HP terminal,
and also tell it to use XON/XOFF, and all will work well.]

A note to HP9000 users out there ( if there are any!):  Kermit cannot
use an ASI card interface to a modem if it is to call outside.  It needs
to be talking to a MUX board port (properly addressed by read-writeable
ttyxx, cuaxx and culxx files in /dev).  Since the ASI board took care of
neat items such as telling the modem to hang up when it's done with it
(using signal lines), and the MUX board cannot, we installed new chips
in our Racal-Vadic's (from them) to interpret a ^C^D sequence flanked by
3 seconds of dead air on either side as a "hangup".  Thus, I modified
the Kermit code to echo a "^C^D" to the communications port when exiting
Kermit.  Perhaps the best way to do this, would be to modify the
ckudia.c MDMINF struct to include a "hangup_str" parameter.  Unless of
course, this is too obscure a scenario...

One further note: ^\^F still doesn't abort a file transfer that is hung up;
neither does ^\^B, for that matter.  Does the transfer have to be at least a
little successful ( a few packets here and there) for this to work?  If so,
perhaps it is suboptimal?

[Ed. - Right, interrupting a transfer with [^\]{^F,^B} only takes effect
after the first data packet has passed.  So there's no good way to interrupt
a Unix Kermit that's stuck trying to start a file transfer, short of ^C'ing
it to stop the program all together.  This is noted in the .BWR file.]

------------------------------

Date: Sun, 7 Jul 85 10:14:48 pdt
From: [e-mail] (Dave Tweten)
Subject: C-Kermit Line Locking
Keywords: C-Kermit

In Info-Kermit Digest, volume 2, number 39, Scott Weikart writes about
Kermit line-locking:

     Instead of setuid, I think it would be much better to operate
     setgid.  Then the ownership of the lock file would be intact.  I
     put uucp, cu, kermit, etc in a group called dialer, for such
     situations.

I agree that the group mechanism is the appropriate tool to use.  On our Vax
780, 4.2 BSD system, the system administrator has established a similar
group.  The dial-out ttys are owned by the group and are given owner and
group access, and so is /usr/spool/uucp.  That way, using /etc/groups, we can
admit users to the group who have a valid need to dial out.  We thereby
reduce our exposure to the phone bills which would result from someone
dialing into his favorite Timbuktu bulletin board all day.

To make this system as consistant as possible, we have modified C-Kermit
to make the /usr/spool/uucp "no read access" and "no write access"
warning messages be preventive messages instead.  That way, if an access
specification mistake has been made, there is less likelyhood of Kermit
users, tip users, uucp, etc. stomping on one another.

As I see it, the problem can be resolved for all sizes of systems.  In a
small system, with a tight group of users, make /usr/spool/uucp and the ttys
publicly accessible.  With a larger system, make them group accessible, and
only admit to the group those with a legitimate need to contribute to the
size of the phone bill.

The concern over users' ability to get their work done is resolved by
realizing that on a system which is small and tight-knit enough for public
access to be appropriate, the "system administrator" is likely to be very
accessible (if "he" is not, in fact, just a hat worn by any of several users
when doing system administration tasks).  In a larger system, the
administrator has a legitimate need to control access.

I do believe, though, that Kermit's /usr/spool/uucp access warnings should be
made preventive.  I believe this for the very reason you (the Info-Kermit
Digest editor) stated in volume 2, number 38:

     Assuming that all this can be set up, there still remain ___ major
     problems with line locking:

     1. Programs will always appear that do not honor the locking
        conventions, defeating the entire purpose of the locking
        mechanism by simply ignoring it.

With its current access warnings, C-Kermit is just such a program.

------------------------------

Date: Sun, 7 Jul 85 14:53:48 pdt
From: "Scott Weikart; Community Data Processing; 415-322-9069"
 <cdp!scott@Glacier>
Subject: UUCP Line Locking
Keywords: UUCP, C-Kermit

Ken Poulton had talked about wanting to have one kermit process open a
circuit, and then have other kermit processes use that same circuit.  His
scheme was to have a kermit exit command that wouldn't close the line.  This
scheme has the problem that people will forget to release the tty.  I had
suggested an alternative scheme of having subsequent kermits run in a
subshell of the kermit that opened the circuit, so that when you tried to
log off you would pop back into the parent kermit and then exit it and
release the line.  I had also suggested that on those systems where
lock-file directories are not accessible by the world, that kermit be run
setgid in a group which has write accesss to the lock-file directory, so
that a) kermit wouldn't have to be setuid and b) the lock file would be
owned by the user account so that subshell kermits could see if their user
owned the tty lock-file.  If people wanted kermit to run setuid, I had
suggested writing the account name into the lock-file, so that subshell
kermits would just read the lock-file to see if their user had reserved the
tty.

What follows is a discussion in usenet about a similar problem.  The last
note indicates that Honey Danber UUCP uses a similar scheme: it writes
the process ID (PID) into the lock-file.  So if kermit used this scheme,
a subshell kermit could read the lock-file and see if its contents match
kermit's PPID (parent PID), as gotten by getppid().

[Ed. - Kermit actually does write the PID into the lock file, but currently
does not use it for anything.  Note that not all Unix systems have getppid().]

>>The problem with tip is that, after locking the modem port, it
>>setuid's back to the original invoker's uid/gid.  This is
>>supposed to patch the security hole surrounding shell escapes
>>and file transfers.  Fine but; alas; it doesn't read /etc/phones...

    Another problem this causes involves /usr/spool/uucp security and LCK
    files.

    It is desirable to have /usr/spool/uucp NOT WRITABLE by the world, as
    this leaves a hole for (admittedly clever) vandalism.

    However, with the 4.2BSD version of `tip', this causes the LCK files to
    be left around after `tip' exits, preventing use of the port until
    manual intervention by a "privileged user".

    `tip' creates the LCK file while SUID, and no longer has write
    permission in /usr/spool/uucp once it changes the UID.  The LCK
    file therefore remains.

    For binary sites the only "solution" seems to be to leave this
    directory writable.  Yuck.

    /+\ Keith F. Pilotti

        (UUCP) {decvax,ucbvax}!sdcsvax!telesoft!pilotti
        (ARPA) Pilotti@UCSD

a possible solution is to follow honey danber's lock file treatment.
assuming tip's lock files have the same format as uucp's, the lock file
contains the pid of the process that created it.

write a program that reads the lock file and issues signal 0 to the named
pid.  if the return is 0 or EPERM, the lock file is valid, otherwise it
should be removed.  if binary license is a problem, make tip a shell script
that calls tip, then this program.  i leave the details to your imagination.

    peter

[Ed. - Let's keep this discussion going until some kind of concensus is
reached.  My concern is that whatever mechanism is settled upon is rational,
humane, simple, installable, maintainable, and explainable.]

------------------------------

Date: 7 Jul 85 19:01:41 EDT
From: D. M. Rosenblum <DR01@CMU-CC-TE>
Subject: Running Pro-3xx P/OS Kermit from Tool Kit
Keywords: Pro-3xx P/OS Kermit

Users of PRO/Kermit may be interested to know that PRO/Kermit can be run from
PRO/Tool Kit, instead of from the main P/OS menu.  This is useful if you are
in the habit of going directly into PRO/Tool Kit and doing everything from
there.  Here's how to do this.

Suppose you have installed PRO/Kermit in a menu on a hard disk system.
KERMIT.TSK will be in a directory of the form [ZZAPnnnnn], where nnnnn is a
system-dependent five-digit number (you will have to do some hunting to find
which such directory KERMIT.TSK is in).  PRO/Tool Kit's START.CMD and
EXIT.CMD files will also be in a directory of the form [ZZAPmmmmm] (where
mmmmm is not equal to nnnnn).  You should APPEND the following lines to
[ZZAPmmmmm]START.CMD, replacing [ZZAPnnnnn] throughout by the name of the
directory in which KERMIT.TSK resides.

;
;    Install PRO/Kermit Version 1.0
;
;    Note that the reference to [ZZAPnnnnn] in the line that installs
;    KERMIT must be changed if PRO/Kermit is removed from the menus and re-
;    installed there.
;
    .DISABLE QUIET
    .IFNINS KERCON INSTALL [ZZKERMIT]KERCMN
    .IFNINS KERCON INSTALL [ZZKERMIT]KERCON/NOREMOVE
    .IFNINS KERFIL INSTALL [ZZKERMIT]KERFIL/NOREMOVE
    .IFNINS KERMIT INSTALL [ZZAPnnnnn]KERMIT
    .ENABLE QUIET

(the PRO DCL indirect command processor has no way of testing to see whether a
common region has been installed, so you have to instead check to see whether
some task, that you're careful to have installed if and only if that common
region is installed, has been installed in order to determine whether the
common region has been installed -- this makes the order of the commands in the
START.CMD file important).

You should also append the following lines to [ZZAPmmmmm]EXIT.CMD.
;
;    Remove PRO/Kermit Version 1.0
;
;    Note that we do not remove KERCON, KERFIL, or KERCMN (which is a
;    common region), since the first two are normally installed with the
;    /NOREMOVE option (when Kermit is run from the menu in P/OS), and the
;    third is not normally removed when Kermit is exited.
;
    .DISABLE QUIET
    .IFINS KERMIT REMOVE KERMIT
    .ENABLE QUIET

If you are on a diskette system, all references to directories [ZZAPmmmmm] and
[ZZAPnnnnn] should be replaced by [ZZAPPL].  Otherwise, as far as I can tell,
the procedure is the same (I don't have access to any diskette-based PROs, so
I can't tell if this really works -- in other words, it's untested).

Once you have made these additions to the .CMD files, all that you have to do
in Tool Kit to run PRO/Kermit is issue a RUN KERMIT command.  You will then be
in Kermit's top-level menu, and you may proceed as usual.  When you exit
PRO/Kermit, you will be back in Tool Kit.

------------------------------

Date: Wed 3 Jul 85 00:13:21-PDT
From: Bob Larson <[e-mail]>
Subject: Bug in Prime Kermit
Keywords: Prime Kermit

Testing the new os9 kermit, I found another bug in Prime kermit.  When in
server mode, Prime kermit will Ack an 'R' packet, then send a Send-Init
packet.  According to the protocol manual, it is not suposed to send the
'Y' (Ack) packet.  I had to modify the os9 kermit to ignore the extra Ack.

[Ed. - If Prime Kermit really does this, it's a bug.  I've forwarded Bob's
message to the Prime Kermit authors.]

------------------------------

Date:  Wed, 3 Jul 85 21:24 EDT
From:  [e-mail]
Subject: More about 9600 bps Modem
Keywords: Modem

Since a few people are asking me about the modem I mentioned, I will pass on
the information.  This is for informational purposes only and is not a
comment pro or con:

It is the UPTA96 modem from Electronic Vaults, Inc.  Their phone number is
703-883-0332.  It presents a full duplex interfaces but transmits half duplex
using its own error correcting protocol.  It can drop back to 7200 or 4800
under program control.  It uses either XON/XOFF or CTS/DTR flow control.

It is available as a standalone modem or as a board for the IBM PC.  It uses
a standard RJ11 jack.

------------------------------

Date: Fri, 5 Jul 85 15:46:22 -0200
From: Frithjov Iversen <iversen%vax.runit.unit.uninett@NTA-VAX>
Subject: More about PC-Kermit and National Characters
Keywords: MS-DOS Kermit

What I had in mind, is what you refer to as SET CHARACTER.  Anyway, the
feature need not include the ability to switch between different font sets in
ROM.  It could be implemented as a simple 256-byte lookup-table.  When ASCII
<xxx> comes in,look it up, and it turns into <yyy> before sending it to the
screen.  One may assume that the National character ROM already is in effect.

-fi

------------------------------

Date: Tuesday, 2 July 1985  11:43-MDT
From: Dave Shanks <[e-mail]>
Subject: Z100 Comunications Program Query
Keywords: Z100 Kermit

Does anyone out there know of a good communications program for the
Heath/Zenith H/Z100 under MS-DOS which supports both the serial ports?
I am specifically looking for a program which will allow me to switch
ports on the fly.  It would be nice if the program were in the public
domain, but not necessary.  Thanks in advance.

Dave Shanks    ..!tektronix!reed!teneron!shanks
Teneron Corp.
6700 SW 105th   Suite 200
Beaverton, OR  97005
[phone]

[Ed. - Does anyone have experience using MS-DOS Kermit on the Z100 with
two ports?]

------------------------------

Date: Mon, 8 Jul 85 11:56:14 EDT
From: John Shaver STEEP-TM-AC 879-7602 <jshaver@apg-3>
Subject: Kermit on MicroVAX-1
Keywords: MicroVAX-I

Is there any experience with Kermit on the MicroVAX-1?

[Ed. - Comments appreciated, of course, about either VMS or Unix on the
MV-I, or the MV-II for that matter.]

------------------------------

End of Info-Kermit Digest
*************************
-------
12-Jul-85 18:01:20-EDT,10612;000000000000
Mail-From: SY.FDC created at 12-Jul-85 18:00:56
Date: Fri 12 Jul 85 18:00:56-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #3
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 12 Jul 1985       Volume 3 : Number  3

Departments:

  ANNOUNCEMENTS -
    Another Release of C-Kermit 4C for Unix, VMS, and Macintosh
    Commodore-64 Bootstrap Program in Fortran
    Assembling Apple II Kermit (AP2KER) with Apple Assembler?
    New Apple II Cross Assemblers

  OLD QUERIES ANSWERED -
    Re: Kermit on MicroVAX-I
    Re: Z100 Communications Program Query

  NEW QUERIES -
    IBM 3270/PC and Kermit?

----------------------------------------------------------------------

Date: Fri, 12 Jul 85 16:58:22 EDT
From: SY.FDC@CU20B (Frank da Cruz)
Subject: Another Release of C-Kermit 4C for Unix, VMS, and Macintosh
Keywords: C-Kermit, UNIX Kermit, VMS Kermit, MacKermit

Yet another release of C-Kermit 4C, this one is 4C(056), for Unix, VAX/VMS,
and the Apple Macintosh.

Major differences from 4C(055), affecting all systems:

. Various file transfer performance improvements.
. Another bug with 8th-bit-prefixing negotiation fixed.
. Some bugs fixed concerning interrupted file transfers.
. Incoming Z (EOF) packet now ack'd only after file successfully closed.
. Allowance made for ACK to F packet containing alternate file name.
. "Blank lines" in packet stream no longer NAK'd.
. Test for echoed packets fixed.
. Input buffer now flushed only after desired packet is read.
. Many minor fixes and cleanups.

Unix and VMS only:

. "statistics" and transaction log now include timing information.
. "set incomplete {keep,discard}" is now implemented.
. "show parameters" redesigned and has some inaccuracies fixed.
. "echo" now accepts \ooo octal escapes, e.g. "echo foo\007bar" will now beep.
. "set prompt" now accepts argument in doublequotes to allow blanks.
. Command parser now accepts comment lines starting with "%".
. It is now possible to exit protocol at any time by typing ^A^C^C<CR>.
. Manual chapter updated to reflect above changes.

Unix only:

. 4.xBSD performance improved by doing nonblocking reads, own buffering
  (Herm Fischer's Sys III/V code adapted to work for BSD).

VMS only:

. Version numbers should now be stripped from outbound file names.
. Improved build procedure (CKV*.COM).

Macintosh:

. No Mac-specific changes were made, but the changes made to the system-
  independent protocol modules should fix a couple problems that reportedly
  prevented all C-Kermits from communicating with systems that send "blank
  lines" between packets, with systems that echo packets, and with Kermits
  that know about 8th-bit prefixing but refuse to do it.  The new Mac Kermit
  release is numbered "0.8(33)".

The new release has been tested under 4.2bsd, Pro/Venix V1, and on the
Macintosh against normal systems like DEC-20's and VAXes as well as against
IBM mainframes both in line mode and with full screen 3270 protocol
conversion (thru Series/1).  The VMS version has not been tested (feedback
welcome).

Thanks to Larry Afrin, Gary Algier, Todd Booth, Kelvin Nilsen, Ken Poulton,
Dan Schullman, Ed Schwalenberg, and others for reporting problems and/or
suggesting fixes since the last release of C-Kermit 10 days ago.

The new files are in K2:CK*.* on CU20B, available via anonymous FTP.
The updates are listed in greater detail in the files K2:CK*.UPD.  The files
K2:CK*.BWR list known bugs and restrictions.  K2:CKUKER.DOC is the new
Kermit User Guide chapter for Unix Kermit (not yet integrated into the
monolithic Kermit User Guide, KER:KUSER.DOC).

Since C-Kermit continues to change, it is not recommended that you get these
files unless:

(a) You are having problems with your present version that might be fixed
    by the changes listed above;
(b) You are doing development work based on the C-Kermit source (always try
    to work from the latest sources!).

It is expected that these new files, along with others recently announced,
will be available via uucp at okstate shortly after okstate comes back up on
July 22 or thereabouts, and will also be available on BITnet via KERMSRV at
CUVMA probably next week.

As usual, send comments, suggestions to Info-Kermit@CU20B.

------------------------------

Date:      10:23:48 07/11/85 (85.192)
From:      Jeff Balvanz <GM.JLB @ ISUMVS>
Subject:   Commodore-64 Bootstrap Program in Fortran
Keywords: Commodore 64

This is a Fortran version of the download program C64BOOT designed to
bootstrap the Commodore-64 version of Kermit from our VAX system.  It should
work with minor modifications with any system running Fortran-77.

[Ed. - Thanks, now we have one in each of Fortran, C, Simula, and Clu --
quite a collection -- in KER:C64BOOT.* (.FOR, .C, .SIM, .CLU; pick your
favorite.)]

------------------------------

Date: Fri, 12 Jul 85 08:52:18 MST
From: slesh@FTH-1
Subject: Assembling Apple II Kermit (AP2KER) with Apple Assembler?
Keywords: Apple II DOS Kermit

    Assembling and using the Apple Assembler/Editor version of Kermit
is NOT a straightforward proposition.  (The following comments are based
upon as little expertise with Apple 3.3 DOS and the assembler as I could
acquire in the process of getting an Apple DOS Kermit.)  A few of the little
quirks I have discovered THE HARD WAY follow:

    1-     if you obtain the source ( ap2ker.asm ) using a
    communications program which runs under another operating system
    and permits text files larger than 32K (e.g. CP/M 80), you will not
    be able to convert the resulting file to an Apple text file without
    splitting it.  My Applicard file conversion utility ADOSXFER
    converted the first 32K all right then went right on cheerfully
    whirring disks and flashing text on the screen.  When I attempted to
    assemble the resulting product there were 81 errors.

    2-    the Apple Assembler documentation mentions something about
    'chaining' - "CHN" - but I couldn't get that to work.  What did
    work was naming two source files on the "asm" command line.  I
    couldn't find anything in the documentation to indicate WHY it
    worked.  (The binary file takes the name of the second source file
    named - an undocumented feature of the Apple Assembler?)

    3-    the 'ap2ker' version does NOT have some of the features
    documented in the DEC 20 version (e.g. talking to servers, setting
    slots or defining keyboard type).

    A little help from anybody out there who really knows what's going
on would be appreciated.

[Ed. - AP2KER is a "hand crafted" translation of the original Stevens
Institute of Technology "CROSS" cross-assembler source into Apple assembler,
done by Olaf Pors of the University of Virginia.  It is, indeed, based upon
an older version of Apple Kermit; the CROSS version continued to change
after Olaf contributed this version, and Olaf made a few changes during
translation that may or may not have shown up in the "master copy".  CROSS,
for those who don't know, is a general-purpose cross assembler written in
PDP-10 assembly language (and hence can be run only on DEC-10 and DEC-20
systems).  The input syntax closely resembles PDP-11 Macro assembler,
perhaps because CROSS is based upon MACY11, the DEC-10 PDP-11 cross
assembler.  Unlike MACY11, however, CROSS can generate output for a wide
variety of micros from basically the same input syntax.  But since CROSS
only runs on PDP-10 style processors, these benefits are not widely enjoyed.
To complete the cycle, it would be interesting if someone could write a new
CROSS that accepts PDP-10 Macro-10 for input and produces output in a
variety of formats; then CROSS itself could be CROSS-assembled to form a new
CROSS that could then cross-assemble APPLE.M65 on other machines.  But wait,
maybe there's a better way ... ]

------------------------------

Date:  08 Jul 85 AT 15:37:30
From: Ted Medin <MEDIN-T%cc82@NOSC>
Subject: New Apple II Cross Assemblers
Keywords: Apple II DOS Kermit

I have two Apple II cross assemblers written in C.  One can handle the M65
CROSS-format source for Apple II DOS Kermit and the other can handle Apple II
assembler (AP2KER).  These assemblers are available in source asis if any one
wants them; I got them from the net and then hacked them.  I will mail them in
three parts each as Unix shell archives; cut and execute to produce the files
which include test cases.  The test cases are the best documentation on what
the syntax is.

[Ed. - Thanks!  The files are available in the Kermit-Tools area on CU20B as
KT:APX*.* (Apple II assembler) and KT:M65*.* (CROSS M65 format), via anonymous
FTP, along with CROSS which is also still there.]

------------------------------

Date: Wed 10 Jul 85 23:12:09-EDT
From: Richard Garland <[e-mail]>
Subject: Re: Kermit on MicroVAX-I
Keywords: MicroVAX-I Kermit

Kermit was the first means we used to load stuff into our microVAX-I last
October under microVMS V1.0.  We down-loaded the Stevens Kermit .HEX file
(using raw terminal capture with XON/XOFF flow control), did the same with
the DEHEXIFY Macro source, assembled DEHEXIFY, dehexified KERMIT, and used
it for weeks getting our applictions down from our VMS VAX 780.  It was a
mainstay until DECnet over Ethernet got installed.  It was hardwired
port-to-port at 9600 bpi.  The current version of Kermit works equally well
with microVMS V4.1
                    Rg

------------------------------

Date: Wed, 10 Jul 85 09:58:22 cdt
From: [e-mail] (Jim Knutson)
Subject: Re: Z100 Communications Program Query
Keywords: Z100 Kermit

I had thought long and hard about a way to access both ports when I was
getting the Z100 version up.  The problem has to do with using the BIOS
routines for character output.  These only support one AUX device.  To be
able to use the other serial port, a rewrite of the I/O module would need to
be done and some interrupt driven I/O routines would have to be written.
Unfortunately, I don't have the time to do this but it shouldn't be too hard
if you use the IBM-PC I/O module as an example.

Jim Knutson

------------------------------

Date: Fri 12 Jul 85 11:00:54-PDT
From: Wing Lee <WingLee%ECLD@ECLA>
Subject: IBM 3270/PC and Kermit?
Keywords: IBM 3270/PC

Will the IBM-PC kermit work on an IBM 3270/PC using its RS-232 port?  We
currently have version 2.26 of IBM-PC Kermit.

wing lee

[Ed. - Anybody have experience with this?  My guess is that it would work
just fine, but have never had any reports either way.]

------------------------------

End of Info-Kermit Digest
*************************
-------
15-Jul-85 16:27:31-EDT,11222;000000000001
Mail-From: SY.FDC created at 15-Jul-85 16:26:36
Date: Mon 15 Jul 85 16:26:36-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #4
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Mon, 15 Jul 1985       Volume 3 : Number  4

                 Kermit Protocol Extension Proposals
                 Proposal for Extended Packet Lengths

----------------------------------------------------------------------

Date: Mon 15 Jul 85 16:12:15-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit Protocol Extension Proposals
To: [e-mail]
Keywords: Kermit Protocol

This week, two new extensions to the Kermit file transfer protocol will be
proposed.  Both address one of Kermit's weakest areas: performance.  Both
extensions are designed to allow extended Kermits to work transparently with
older Kermit programs that are ignorant of the extension; this has always
been the rule for extensions added to the protocol.

The two extensions are:

1. Longer packets.

2. Continuous transmission of packets in a "sliding window".

As originally designed, Kermit is a "stop and wait" protocol; each packet has
to be acknowledged before the next one is sent.  A Kermit packet includes a
single-byte length field expressed as a printable ASCII character, limiting
the packet length to 94.  The original design has been quite effective for
several reasons:

   a. Kermit programs are simple to write.

   b. The restriction on packet length guaranteed that Kermit would work on
      practically every system, including the many whose terminal input buffers
      cannot tolerate long bursts of input.

   c. The stop-and-wait strategy gives the operating system time to consolidate
      its input buffers.

As Kermit grows in popularity, it has found use in situations where its basic
design results in poor performance.  Two examples:

   a. Connections with built-in delays, like public networks or satellite
      links.  Unlike direct or dialup connections, these connections do not
      have a dedicated channel; response varies with the current load on the
      medium, and also with the "diameter" of the network.  Delays can slow
      down the performance or stop it all together if they exceed Kermit's
      timeout parameters.

   b. Direct, clean connections, to systems with big input buffers.  When
      the error rate is very low, throughput is unreasonably impeded by
      stop-and-wait for short packets.

At first glance, it would seem that a single solution could address both
situations.  First, note that any performance extension must require the
receiver of a file to have big input buffers (and since many many systems
don't, any extensions will have to be negotiable).  The question is whether to
send one long packet or a bunch of short packets end-to-end (or both).

Assuming that each packet must be acknowledged, the advantage would seem to
go to long packets, since fewer acks would be required per unit data.  But
when errors occur the amount of data to be retransmitted is less with short
packets, so a sliding window with short packets would be better in a
potentially noisy environment.  But sliding windows work best on a full
duplex communication channel, which certain key systems do not provide.

It is still possible to do packet windowing on half-duplex connections, but
in this case the windows lurch rather than slide -- a batch of packets can be
sent, responded to by a batch of ACKs and NAKs.

Some random observations:

Longer packets are simpler to specify and program.

Windowing is harder to specify and program, and for true full duplex operation
also requires either multiprocessing (e.g.  separate input and output forks) or
else interrupt-driven i/o.

Long packets need a rigorous error-detection mechanism like the 16-bit CRC.
The normal 6-bit checksum just won't do.  Windowing with short packets, on the
other hand, should work well even with short block checks.

Currently during initial connection, two present-day Kermits tell each other
the longest packet they are prepared to accept, up to the maximum of 94.
Each computer bases this number on some knowledge about its input buffers.
But there are also external factors which may be unknown to the computers;
for instance, the connection has been made through a public packet-switched
network or a local area network whose interface devices might have smaller
buffers than the computers themselves.  These factors have rarely interfered
with original ("classic"?) Kermit, because even its biggest packets are
acceptable to most of these devices.  But if Kermit is extended to allow
transmission of much longer bursts of continuous data, all bets are off.  The
burden will shift to the (often naive) user to understand the communications
environment enough to elect the best parameters and options.

The biq question is:  Are the benefits in performance worth the cost in
complexity for specification, programming, and "user education"?  Especially
in view of the likelihood that even if adopted, the extensions will
probably not be made to more than a few of the existing Kermit programs.

Assuming extension is desirable, which extension should be made: long packets,
sliding windows, or both?

The first proposal follows.  The next one will appear in a forthcoming
Info-Kermit (most likely the next one).  By the way, it should be noted that
long packets and windowing should probably be mutually exclusive, since the
proposal for windowing (in its present form) expresses window sizes in numbers
of packets, assuming the current maximum length.

------------------------------

Date: Mon 15 Jul 85 16:12:44-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Proposal for Extended Packet Lengths
To: [e-mail]
Keywords: Long Packets

A method is proposed to allow the formation of long Kermit packets.
Questions as to the desirability or appropriateness of this extension to the
Kermit protocol are not addressed.  All numbers are in decimal (base 10)
notation, all arithmetic is integer arithmetic.

In order for long packets to be exchanged, the sender must set the LONGP bit
in the CAPAS field of the Send-Init (S or I) packet, and also furnish the
MAXLX1 and MAXLX2 (extended length 1 and 2) fields, as follows (the value for
the LONGP bit and the position of the MAXLX1,MAXLX2 fields have not yet been
settled):

    ---+-------+-     -+--------+--------+
       | CAPAS |  ...  | MAXLX1 | MAXLX2 |
    ---+-------+-     -+--------+--------+

where MAXLX1 and MAXLX2 are each a printable ASCII character in the range SP
(space, ASCII 32) to ~ (tilde, ASCII 126), formed as follows:

    MAXL1 = char(m / 95)
    MAXL2 = char(m MOD 95)

    (where m is the intended maximum length),

to indicate the longest extended-length packet it will accept as input.  The
receiver responds with an ACK packet having the same bit also set in the CAPAS
field, and with the MAXLX1 and MAXLX2 fields set to indicate the maximum length
packet it will accept.

The maximum length expressible by this construct is 95 x 94 + 94, or 9024.

Since the sender can not know in advance whether the receiver is capable of
extended headers, the Send-Init MAXL field must also be set in the normal
manner for compatibility.

If the receiver responds favorably to an extended-length packet bid (that is,
if its ACK has the LONGP bit set in the CAPAS field), then the combined value
of its MAXLX1,MAXLX2 fields is used.  If the the LONGP bit is set but
MAXL1,MAXL2 is missing, then the value 500 will be used by default.

If it responds unfavorably (the LONGP bit is not set in the CAPAS field),
then extended headers will not be used and the MAXL field will supply the
maximum packet length.

After the Send-Init has been sent and acknowledged with agreement to allow
extended headers, all packets up to and including the B or E packet which
terminates the transaction (and its acknowledgement) are allowed -- but not
required -- to have extended headers; extended and normal packets may be freely
mixed by both Kermits.

The normal Kermit packet length field (LEN) specifies the number of bytes
to follow, up to and including the block check.  Since at least 3 bytes must
follow (SEQ, TYPE, and CHECK), a value of 0, 1, or 2 is never encountered
in the LEN field of a valid unextended Kermit packet.  When extended packets
have been negotiated, the LEN field is treated as follows for the duration of
the transaction:

    If unchar(LEN) > 2 then the packet is a normal, unextended packet.
    If unchar(LEN) = 0 then the packet has a "Type 0" extended header.
    If unchar(LEN) = 1 or 2, the packet is invalid and should evoke an Error.

"Lengths" of 1 and 2 are reserved for future use in Type 1 and 2 extended
headers, yet to be specified.

A Type 0 extended packet has the following layout:

+------+-----+-----+------+-------+-------+--------+----       ----+-------+
| MARK |     | SEQ | TYPE | LENX1 | LENX2 | HCHECK |  DATA ....    | CHECK |
+------+-----+-----+------+-------+-------+--------+----       ----+-------+
                          | Extended Header        |


The blank length field (SP = char(0)) indicates that the first 3 bytes of
what is normally the data field is now an extended header of Type 0, in which
the number of bytes remaining in the packet, up to and including the block
check, is

    extended-length = (95 x unchar(LENX2)) + unchar(LENX2)

and HCHECK is a header checksum, formed exactly like a Type-1 Kermit block
check, but from the sum of the ASCII values of the SEQ, TYPE, LENX1, and
LENX2 fields:

     s = SEQ + TYPE + LENX1 + LENX2

     HCHECK = char((s + ((s AND 192)/64)) and 63)

Since the value of the extended length field must be known accurately in
order to locate the end of the packet and the packet block check, it is
vital that this information not be corrupted before it is used.  The header
checksum prevents this.

The extended header, like the normal header itself, is NOT prefix-encoded.
This implies that the entity responsible for building packets must leave 3
spaces at the beginning of the data field, form the rest of the packet
(encode the data), and then go back and fill in LENX1, LENX2, and HCHECK
based upon the data actually entered into the packet, after encoding.
Similarly, the packet receiver must allow the extended header to be treated
as prefix-encoded data.

The packet block check is formed in the usual manner, based on all packet bytes
beginning with LEN and ending with the last character in the data field.  The
block check may be Type 1, 2, or 3, depending upon what was negotiated, but
longer packets are more likely to be corrupted than shorter ones and should
therefore have higher-order block checks if possible.  This proposal does not
change the way block check type is negotiated, and does not require that Type
2 or 3 block check be implemented.

------------------------------

End of Info-Kermit Digest
*************************
-------
18-Jul-85 19:24:33-EDT,13170;000000000001
Mail-From: SY.FDC created at 18-Jul-85 19:23:23
Date: Thu 18 Jul 85 19:23:23-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #5
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu, 18 Jul 1985       Volume 3 : Number  5

Departments:

  KERMIT PROTOCOL EXTENSIONS -
    Kermit Extension Proposal Feedback
    Re: Proposals
    Checksum versus CRC
    Kermit Extensions
    Kermit Extended Packet Lengths Proposal
    Kermit Protocol Enhancements
    New vs Classic Kermit

  MISCELLANY -
    Re: IBM 3270/PC and Kermit
    RSX Kermit Warning
    Kermit for Mac L Running Unix
    Terminal Emulator w/Kermit:  Beta-test Site Query
    MS-Kermit 2.26 and Hercules Graphik Card

----------------------------------------------------------------------

Date: Thu 18 Jul 85 19:09:55-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit Extension Proposal Feedback
Keywords: Kermit Protocol Proposal

The following messages are in response to the first Kermit extension
proposal, presented without comment.  The second proposal (sliding windows,
an effort which is being coordinated by people at The SOURCE Telecomputing)
is not quite ready yet, but should appear shortly.  If you sent a response
that doesn't appear below, send it again -- we lost our file system on CU20B
last night and some messages may have been lost.

------------------------------

Date: Tue, 16 Jul 85 02:12:32 pdt
From: Scott Weikart <cdp!scott@Glacier>
Subject: Re: Proposals
Keywords: Kermit Protocol Proposal, Sliding Window Kermit, Long Packets

I would definitely like to have either sliding window protocol or long
buffers, but I'm not sure which one (or if I need both).  We're working with
some other non-profits to setup long-distance telecommunications between UN*X
and MS-DOS machines, and would like to use kermit as our transport mechanism,
but we're worried about kermit efficiency with long round-trip times (eg
packet-switched networks) or long-distance high-speed modem connections.  The
packet-networks should be error- corrected so that long packets would seem to
make sense, but I don't know if you'll get hing up by buffer sizes in the
network (the nets I'm thinking of are Uninet, and maybe Tymnet or Telenet).
We may also be using some of the new high-speed pseudo-full-duplex modems,
and I don't know enough about their error rates or buffer size factors
either; if it's error rate is high and and it doesn't do partition a block
and use its own sliding window protocol, it might be good to use half-duplex
lurching window with small packets.

I'm not so worried that many/most kermits won't be able to handle either
extension.  For people like us who are interested in using kermit for the
transport mechanism of sophisticated telecommunications services, probably
only the more capable machines will be considered as part of the system
(although one may argue that an MS-DOS machine is not very capable).

As for user education about large packets, people could maybe implement an
adaptive mode that would try a 1/3 or 1/2 smaller packet each time a
transport media truncated a packet.  But that's more hairiness.

------------------------------

Date: 15 Jul 1985 1941-EDT
From: B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO.ARPA>
Subject: Checksum versus CRC
Keywords: Kermit Protocol Proposal, Checksums

I haven't seen a single clear review of the above - I STILL BELIEVE THAT
Checksumming of mostly analog based circuits is SUPERIOUR. CRC [ and all
quasi-mathematical "analysises" assume BIT-drops] is SUPERIOUR in catching
missing BITS [one typically can be "reconstructed" depending on the "polynom"
- two or [sometimes more] can be "detected". CHecksumming is good for
"detecting" single-bit changes [no chance to "reconstruct" - since the
position of the "change" is not known - and [obviously.. only a 50% chance to
"catch" double-bit errors].... HOWEVER - and here lays the "settle"
difference -- ANALOG CIRCUITS TEND NOT TO DROP BITS - THEY DROP MINIMALLY
WORDS and TYPICALLY "SENTENCES" -- AND CHECKSUMMING HAS A HIGH CHANCE TO
"catch" these DROPS or MODIFICATIONS - since typically [on ANALOG CIRCUITS]
FULL [either ON- or OFF-Bit sequences are substituted] -- this [by the way]
also explains my long-standing objection to CRC-protocol in MODEM
[acknowledged by the experience - that ON "BAD" lines switching from
CHECKSUMMED PROTOCOL to CRC-PROTOCOL DOESN't make a "bit of a difference". -
Yeah, I know; there's an even more serious flaw in MODEM- protocol - in that
ACK/NAK msgs are NOT encased into "message-protocol" and thereby on a "bad"
line MODEM looses typically in ACK/NAK traffic.]

Let me clarify [after re-reading] the above SUPERIOUR - it summs up the
"expended CPU-time {and number of program instructions}" - as compared to the
achieved results {I.e. probability to detect an ERROR}.

Rgds,
Bernie.

------------------------------

Date: Tue 16 Jul 85 21:07:07-EDT
From: Richard Garland <[e-mail]>
Subject: Kermit Extensions
Keywords: Kermit Protocol Proposal, Long Packets

I perked my ears up at one statement in your introduction to the extensions
you outlined:  "Each packet must be ACKed" and you even gave an example of
a half duplex "lurching" window where a bunch of packets are sent and then
a bunch of ACKs are returned.

I would suggest two ideas for ACKs that DECnet uses:

    o  ACKing only the last good packet and
    o  piggyback ACKing.

In the first case if, packets 9, 10, 11, and 12 are sent successfully, the
receiver ACKs 12 and this *implies* 9, 10, and 11 were also good.  If 9, and
10 were good and 11 was bad on the other hand, the receiver NACKs 11, and
this implies 11 is bad, but 9 and 10 were good.  Then the sender resends
starting at 11.  This scheme allows a lot less reverse traffic.  Usually
there is a limit on the number of packets that will be sent before getting
some ACK but that is the sliding window protocol which you are working out
and I won't bother about that part of it. (DECnet uses about 3 versions of
it).

piggyback ACKing simply means that an ACK or a NAK can be combined with
another packet going in the right direction and is relavent for full duplex
data streams.  Perhaps Kermit will never have full duplex data (as opposed
to packets) so this idea may be irrelavent.  But if on the other hand you
want to send a bunch of packets, then send an END packet, a type of
piggybacking would allow the receiver to ACK the last n packets and the END
packet all at once.

By the way, I don't think sliding windows and large packet extension ideas
are mutually exclusive ways to improve performance.

------------------------------

Date: Tue, 16 Jul 85 20:24:42 PDT
From: [e-mail]
Subject: Kermit extended packet lengths proposal
Keywords: Kermit Protocol Proposal, Long Packets

Overall this looks pretty good, but I'd recommend a couple of small changes:

1. Change the extended length specification to be simply 12 bits transmitted
   the same way as the 2-byte checksum. This limits the maximum packet size
   to 4096 bytes, but that is plenty when the best checksum is CRC-CCITT.
   It is also as big as any host's usual input buffer as far as I know.

2. Include the LEN byte in the header checksum so that both checksums start
   at the same byte. Having the header one start 1 byte later than the packet
   one doesn't make any sense and will confuse the implementator.

I believe that the last sentence of the second-to-last paragraph is missing a
"NOT". As it stands, it contradicts the first sentence of the same paragraph.
(That is the paragraph about the extended header not being prefix-encoded.)

Finally, I think there is a small bug in the advanced state table shown in
the 3 April 84 protocol manual (there may be a newer one but that is the
newest I have). The Send_Gen_Cmd state should allow for receiving an F packet
in the case that it was entered from the Send_Server_Init state and sent a R
command. That is because the server will, I expect, conclude that it doesn't
need to send a S(0) because of receiving and Acking the I(0). (I haven't
tried this with a server to be sure, but the Rec_Server_Idle state
description sure implies to me that is how the server will work.)

------------------------------

Date: July 17, 1985, 09:15 CEST
FROM:  <#[e-mail]>
Subject: Kermit Protocol Enhancements
Keywords: Kermit Protocol Proposal

Hi,
 I hope my questions are not too late for this stage of the
discussion.
 1.) which kind of systems would be able to use the large
     packets?
 2.) which kind of systems can afford (pgm size, complexity)
     the necessary changes to the software?
 3.) how does the proposal fit the rules of the early days
     of Kermit development (to have a simple, cheap to implement
     protocol for connecting especially small systems)?
 4.) where are the ends, or in other words, wouldn't it be better
     to develop a new protocol with enhanced performance (e.g
     larger packet, high speed lines, parallel activities on the
     lines)?

Martin Knoblauch
TH-Darmstadt, D-6100 Darmstadt, West Germany
EARN/BITNET: #D15 at DDATHD21 (the number sign is really part of my UID)

------------------------------

Date: 17 JUL 85 09:34-EST
From:  [e-mail]
Subject: New vs Classic Kermit
Keywords: Kermit Protocol Proposal

The proposals for large packets (and likely sliding windows) are not going to
work out well on pdp-11's as the buffers in all the execs are fairly small,
ranging from a max of 36 for rsx, 255 for rsx11m+, 140 for rt, ??? for p/os,
and max of about 500 for rsts/e (depending on available small buffer pool).
Thus xon/xoff would come into play rather soon.  Of course, xonxoff control
is no better (much worse,really) that send/ack for each packet.

------------------------------

Date: Mon, 15 Jul 85 12:42:33 edt
From: Paul Placeway <[e-mail]>
Subject: Re: IBM 3270/PC and Kermit
Keywords: IBM 3270/PC

We have been running kermit for IBM PCs and clones for 6 months on our 3270
PC with no problems whatsoever.  We run a 9600 baud line between the 3270 PC
and our Vax to do file transfers (9600 is very nice, but the Unix version is
too slow (no, we havn't gotten the latest version of Unix kermit)).  I have
one suggestion, however: get a normal PC keyboard for your 3270 PC.  The
position of ESC, Control, and some other keys is a PAIN.

                Paul Placeway
                OSU CIS Dept. Lab
                ...!cbosgd!osu-eddie!paul
                paul@ohio-state  (CSNet)

------------------------------

Date: 16 JUL 85 09:28-EST
From:  [e-mail]
Subject: RSX Kermit Warning
Keywords: Kermit-11, RSX Kermit

A problem with RSX Kermit-11 has been  resolved  in  that  the  outgoing
line  (via  SET  LINE) must NOT have the /RPA setting enabled (read pass
all). If set, it must be disabled via  the  mcr  command  SET/NORPA=TTn:
The  characteristic is not one that would be normally set. The effect of
having it set is to force the terminal driver to pass all  flow  control
(xon   and   xoff)  characters  directly  to  Kermit,  which  is  highly
undesirable. The call to disable /RPA will be added to Kermit-11  source
in the future.

------------------------------

Date:  Tue, 16-JUL-1985 08:55 EDT
From:    Ronald A. Jarrell  <[e-mail]>
Subject:  Kermit for Mac L Running Unix
Keywords: MacKermit

Our CS department is going to be having all incoming freshman purchasing
Macintosh-L's with Unipres System V.  Has anyone tested, or suspects that
one of the flavors of kermit will work under that combination?  We plan on
setting up some semi-automated software for file transfer for them, and the
most desirable alternative would be for them to connect to a VMS Vax that
has Kermit on it.

-Ron Jarrell
 Systems Programming Dept,
 Va Tech

------------------------------

17-Jul-85 11:36:50-EDT,869;000000000001
Mail-From: EXT1.FUCHS created at 17-Jul-85 11:36:47
Date: Wed 17 Jul 85 11:36:46-EDT
From: Michael Fuchs <[e-mail]>
Subject: Terminal Emulator w/Kermit:  Beta-test Site Query
To: [e-mail]
Keywords: Terminal Emulation

Would anyone in net.land be interested in beta-testing the latest release
of a commercial terminal emulator (full VT102) for the IBM PC incorporating
a complete implementation of Kermit?

Features include:

    * Kermit including CRC, server commands, etc.
    * XMODEM, Proprietary protocols with host software provided
    * Software (and hardware) 132 column support
    * Scrolled-off screens capture buffer (80 screens' worth)
    * Terminate-stay-resident Hot key feature
    * Programmable softkeys

Anyone interested please contact me through net mail or at 212-777-6707.

Michael Fuchs
Coefficient Systems Corp.

------------------------------

Date: Thu 18 7 85 23:30 GMT
From: Eberhard W. Lisse <[e-mail]>
Subject: MS-Kermit 2.26 and Hercules Graphik Card
Keywords: MS-DOS Kermit, Hercules Card

Have you heard of any problems caused by the Hercules monochrome graphik card
on an XT DOS 2.11 ?

Since they installed it on our XT, Kermit does not connect any more.

[Ed. - Can anyone help?]

------------------------------

End of Info-Kermit Digest
*************************
-------
22-Jul-85 15:18:45-EDT,8780;000000000001
Mail-From: SY.FDC created at 22-Jul-85 15:08:51
Date: Mon 22 Jul 85 15:08:51-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #6
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Mon, 22 Jul 1985       Volume 3 : Number  6

Departments:

  ANNOUNCEMENTS -
    Kermit-11 User Manual
    Kermit Distribution Updated on Okstate

  MISCELLANY -
    Long Packets and Sliding Windows
    Kermit Problem with Z100 MS-DOS2 Solved
    MacKermit 0.8, UNIX C-Kermit Problems
    Tools for Ascii/Ebcdic Conversion Tables for TSO Kermit
    MS-DOS Kermit vs Professional Graphics Adapter?

----------------------------------------------------------------------

Date:     Thu, 18-JUL-1985 16:53 EST
From:     <BRIAN@UOFT02>
Subject:  Kermit-11 User Manual
Keywords: Kermit-11

I will send two files, K11USR.DOC and .RNO, to you after this; this is the
Kermit-11 User Manual, shaped like a Kermit User Guide chapter but written
using Runoff rather than Scribe.  You folks can do with them what you may,
though they should be placed with the rest of the k11 files on cuvma, cu20b,
and your vax that you make the tapes on.

[Ed. - The files are installed with the other K11 files in K2:K11USR.* on
CU20B, and on CUVMA for KERMSRV.  Thanks, Brian! ]

------------------------------

Date: 20 Jul 85 00:23:32 CDT (Sat)
From: [e-mail]
Subject: Kermit Distribution Updated on Okstate
Keywords: Okstate

I have received and installed the latest Kermit tapes (thanks for sending
them) on our system.  I have moved the distribution area into a more
"normal" location (/usr/spool/uucppublic) on our system and I have split it
into two areas, one for each tape.  The area that was generated from TAPE A
(the micro Kermits) is called /usr/spool/uucppublic/kermit-a and the area
that was generated from TAPE B (the mainframe Kermits) is called
/usr/spool/uucppublic/kermit-b.

The default directory for our "kermsrv" login will be changed to
/usr/spool/uucppublic/kermit-a and users will be allowed to CWD to
/usr/spool/uucppublic/kermit-b.  UUCP users will just have to specify the
full path (although ~uucp/kermit-a and ~uucp/kermit-b should also work on
most systems...).  To summarize:

 -  The files that were on TAPE A are in /usr/spool/uucppublic/kermit-a/*

 -  The files that were on TAPE B are in /usr/spool/uucppublic/kermit-b/*

 -  The Kermit server login "kermsrv" has been modified to use the kermit-a
    area as its default directory and

    REMOTE CWD /usr/spool/uucppublic/kermit-b

    will take you to the other area.  For those systems not supporting
    REMOTE commands, the server will also accept full pathnames in GET
    requests.

Mark

[Ed. - Thanks Mark, and thanks again for providing this service.]

------------------------------

Date: Fri, 19 Jul 85 09:19:04 EDT
From: [e-mail]
Subject: Long Packets and Sliding Windows
Keywords: Sliding Windows Kermit, Long Packets

We use Kermit here for host to host transfers over Telenet and Datapac, and
the long packet extension seems ideal for this purpose.

Unfortunately, our operating system (MTS) doesn't really allow asynchronous
reads, which might cause problems with a sliding window scheme.  I'm
interested in seeing the actual proposal.

[Ed. - It will appear in the next digest.]

------------------------------

Date: Fri, 19 Jul 85 10:17:49 PDT
From: klee@sri-spam (Ken Lee)
Subject: Kermit Problem with Z100 MS-DOS2 Solved
Keywords: Z100 Kermit

Thanks to all those who responed to my request for help with Kermit on
MS-DOS2.  My version of Kermit worked fine on ZDOS, but failed when I
tried to use it with DOS2.  Apparently, DOS2 causes the Z100 to drop
the data terminal ready (DTR) signal to the modem when Kermit attempts
to receive a file.  The modem interpets this as a signal to quit and
drops the telephone line.  By optioning the modem to ignore the DTR
signal from the Z100, I now have kermit working properly.

Ken Lee

[Ed. - Thanks for the pointer; I've placed it in MSZ100.BWR so others can
benefit from it.]

------------------------------

Date: Sun, 21 Jul 85 12:24:17 pdt
From: westjw%frog@Nosc (Joel West c/o NOSC San Diego)
Organization: CACI, Inc. (home of SIMSCRIPT II.5)
Subject: MacKermit 0.8, UNIX C-Kermit Problems
Keywords: MacKermit, C-Kermit, UNIX Kermit

Before I nit-pick, I'd like to say how much I like the keymap program, even
if it was only designed for EMACS hackers. :-) I've chosen the assignment
BS=^H; Shift-BS=DEL; Ctl-BS, Enter=<esc>; although I may change this for vi
later.  (in BSD, you use ~ and ` a lot, and the Ctl-Shift-~ of MacTerminal
is a real pain).

[Ed. - Of course, you can have as many different settings files as you like;
just double-click the one you want to start up Kermit with the appropriate
settings and key map.]

Two problems with MacKermit:

    #1  files never go into folders, always desktop.  This must
    be a "feature", since it's easier to default the file to
    the disk (FlFldr=0) than to the desktop (FlFldr=-2)

[Ed. - Like it says in the manual, they go into whatever folder the settings
file was in that you started Kermit from, otherwise on the desktop.]

    #2    if you receive a file (interactive), toggle disk drives
    and insert a new disk, it bombs during initialization.
    The only time this happened was using RAM Disk "RamStart"
    off of net.sources.mac.

[Ed. - This will be added to the beware file.]

Also, I'm using the April C-Kermit (BSD 4.2) off of mod.sources.  When I
upload files from UNIX to the Mac, I'm not getting a size packet -- or at
least, the Mac isn't printing the expected size.  This is the only thing I
like better about MacTerminal than Kermit -- but the keymap and more
reliable transfers means I've thrown MacTerminal away.

[Ed. - Unfortunately, this requires the sender to include an "attribute
packet", which C-Kermit does not yet do.]

Keep up the good work.

    Joel West    CACI, Inc. - Federal

------------------------------

Date: Thu, 18 Jul 85 21:18:22 PDT
From: VSS7853@UCLAVM
Subject:  Tools for Ascii/Ebcdic Conversion Tables for TSO Kermit
Keywords: TSO Kermit, ASCII/EBCDIC Translation Tables

Enclosed are three Fortran 77 programs I wrote as aids to installing TSO
Kermit when non-standard TCAM tables are used by MVS to communicate with
Ascii terminals.

The first two programs, ATOE.FOR and ETOA.FOR take the actual tables used by
TCAM, which are obtained from the communication's people at one's
installation, and generate assembler source code to replace the tables in
Kermit.  The third, TCAM.FOR, takes the output of the first two and checks
whether the ETOA table is indeed the inverse of the ATOE on the printable
subset as required for Kermit to operate.

If the test fails, Kermit will not run with the existing TCAM tables.  I
suspect, however, that so long as all of the Ascii printables map to
distinct Ebcdic representations, and so long as the range of the Ebcdic-
to-Ascii contains all the Ascii printables, that Kermit could still be made
to work by employing an ETOA which is the inverse of TCAM's Ascii-to-Ebcdic,
an ATOE which is the inverse of TCAM's Ebcdic-to-Ascii, and an additional
ETOA with range contained in the printable subset (and null).  This would
require a bit of analysis and a modest amount of reprogramming on someone's
part but it might add to the number of mvs systems which support Kermit.

The listings include actual output which includes an echo of the input.  The
programs were developed on VAX but the language should be standard 77 except
for the Z format extension.

I hope this helps someone.

 Glenn E. Thobe
 EE dept. UCLA
 iva3get.uclamvs (bitnet)

[Ed. - Listings omitted; they're collected together in K2:TSOETOA.FOR.]

------------------------------

Date: 22 Jul 1985 1354-EDT
From: LCG.KERMIT@MARKET
Subject: MS-DOS Kermit vs Professional Graphics Adapter?
Keywords: MS-DOS Kermit, Professional Grpahics Adapter

We are having trouble with MS-DOS Kermit V2.27 on an IBM AT with the
professional graphics adapter/display.  At speeds above 1200 baud characters
are lost in terminal emulation mode.  Has anyone else seen this problem?

Carl Houseman
GENICOM Corporation
703-949-1323

[Ed. - On the IBM PC/AT, terminal emulation is very slow if EGA card is
present because the program waits for the vertical retrace operation to
complete, which should not be done with the EGA.  Apparently the same is true
of the Professional Graphics Adapter.  Until this is fixed in the next
release, EGA (and PGA?) users can patch the routine SCRWAIT in MSYIBM to
just return.  If anyone with the PGA tries this, please report the results
to Info-Kermit.]

------------------------------

End of Info-Kermit Digest
*************************
-------
23-Jul-85 11:22:17-EDT,23765;000000000001
Mail-From: SY.FDC created at 23-Jul-85 11:21:26
Date: Tue 23 Jul 85 11:21:25-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #7
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue, 23 Jul 1985       Volume 3 : Number  7

                    Kermit Sliding Window Proposal

----------------------------------------------------------------------

Date: Tue 23 Jul 85 10:30:00-EDT
From: Frank da Cruz
Subject: Kermit Sliding Window Proposal
Keywords: Sliding Windows Kermit

This digest presents a proposal from a group at The SOURCE Telecomputing in
McLean, Virginia, for a sliding window extension to the Kermit protocol
(if you're not interested in protocol issues, skip the rest of this digest).
Like other extensions, this one is designed for "upward compatibility" with
Kermits that do not support this extension.  It may be viewed as an
alternative to the long-packets extension proposed in V3 #4, or as
complementary to it.  The question raised by the latter proposal also applies
here: Is the cost in complexity worth the improvement in performance? --
complexity not only in program size and logic, but also in explaining the
options to the user: even when Kermit programs implement windowing, when and
to what degree should it be used?  When must it not be used?

The following proposal is not the only way to do sliding windows or to adapt
windows to Kermit.  The method outlined is certainly not cast in concrete,
although Leslie's group is working on some prototype implementations.  The
proposal is being put forth now to solicit ideas, suggestions, and opinions
from the world at large.  Some areas to think about include:

. What is the effect on the portability of current Kermit programs?  Since
  windowing implies packets flowing in both directions at once, it will be
  necessary to run separate input and output forks or else to handle packet
  i/o at interrupt level.  Neither of these techniques will be as portable
  as the simple input-output sequences now used by most Kermit programs.

. What will be the effect in the many and varied environments in which
  Kermit operates, and will operate in the future?  These include public
  networks, satellite links, local area networks, terminal concentrators,
  TACs, PBX's, high-speed full-duplex error-correcting modems, ATT 56Kb
  digital service, etc etc.  In some cases windowing (or long packets)
  could boost performance dramatically, in others it could prevent Kermit
  from working at all.

. Does the particular method suggested strike the best balance among
  improved performance, upward compatibility, and simplicity?  Are there
  obvious simple improvements to the proposed algorithms and heuristics?

. Can sliding (lurching) windows be done on half-duplex channels?  Are
  any modifications to the proposal required?

This digest will be followed closely by another, which will contain some
questions and answers about this proposal.  Please read both digests before
responding.

------------------------------

Date: Mon 22 Jul 85 11:29:46-EDT
From: Leslie Spira <OC.SOURCE@CU20B>
Subject: Kermit Sliding Window Proposal
Keywords: Sliding Windows Kermit

                      KERMIT WINDOWING PROTOCOL

                         DRAFT SPECIFICATION

                Hugh Matlock, The SOURCE Telecomputing

                            June 12, 1985


1 INTRODUCTION

The windowing protocol as defined for the Kermit file transfer protocol
is based on the main premise of continuously sending data packets up to
the number defined by a  set  window  size.   These  data  packets  are
continuously acknowledged  by  the  receive side and the ideal transfer
occurs as long as they are transmitted with good  checksums,  they  are
transmitted in  sequential  order and there are no lost data packets or
acknowledgements.  The various error conditions define the  details  of
the windowing protocol and are best examined on a case basis.

There are  five  stages that describe the overall sequence of events in
the Kermit protocol.  Three of these stages deviate from  the  original
protocol in order to add the windowing feature.  Stages 1 through 5 are
briefly described on the following page.  The three stages (1, 3 and 4)
which deviate  from the original protocol are then described in greater
detail in the pages that follow.


2 OVERALL SEQUENCE OF EVENTS

STAGE 1 - Propose and Accept Windowing

The send  side  requests  windowing  in   the   transmission   of   the
Send-Initiate (S)  packet.   The  receive  side  accepts  windowing  by
sending an acknowledgement (ACK packet) for the  Send-Initiate  packet.

STAGE 2 - Send and Accept File-Header Packet

The send  side  transmits  the File-Header (F) packet and waits for the
receive side to acknowledge it prior to transmitting any data.

STAGE 3 - Transfer Data

The sending routine transmits Data (D)  packets  one  after  the  other
until the  protocol  window  is  closed.   The receiving side ACKs good
data, stores data to disk as necessary and NAKs bad data.

When the sender receives an ACK, the window may be rotated and the next
packet sent.  If the sender receives a NAK, the data  packet  concerned
is retransmitted.

STAGE 4 - Send and Accept End_of_File Packet

As the  sender is reading the file for data to send, it will eventually
reach the end of the file.  It then waits until  all  outstanding  data
packets have  been  acknowledged,  and  then  sends  an End-of_File (Z)
packet.

When the receive side gets the End-of-File packet it stores the rest of
the data to disk, closes the file, and ACKs the End-of_File packet.

The protocol then returns to Stage 2,  sending  and  acknowledging  any
further File-Header (F) packets.

STAGE 5 - End of Transmission

Once the  End-of-File  packet  has been sent and acknowledged and there
are no more files to send, the sender transmits the End-of-Transmission
(B) packet in order to end the ongoing transaction.  Once the  receiver
ACKs this  packet,  the transaction is ended and the logical connection
closed.


3 PROPOSE AND ACCEPT WINDOWING (STAGE 1)

The initial connection as currently defined  for  the  Kermit  protocol
will need  to change only in terms of the contents of the Send-Initiate
packet.  The receiving Kermit waits for the sending Kermit to  transmit
the Send-Initiate  (S)  packet  and the sending packet does not proceed
with any additional transmission until the ACK has been returned by the
receiver.

The contents  of  the  Send-Init  packet,  however,  will  be  slightly
revised.  The data field of the Send-Init packet currently contains all
of the configuration parameters.  The first six fields of the Send-Init
packet are fixed as follows:

   1        2        3        4        5        6
  +--------+--------+--------+--------+--------+--------+
  | MAXL   | TIME   | NPAD   | PADC   | EOL    | QCTL   |
  +--------+--------+--------+--------+--------+--------+

Fields 7  through  10  are  optional  features  of  Kermit and fields 7
through 9 will also  remain  unchanged  as  defined  for  the  existing
protocol:

   7        8        9        10
  +--------+--------+--------+--------+
  | QBIN   | CHKT   | REPT   | CAPAS  |
  +--------+--------+--------+--------+

Field 10  is  the  capability  field  and  requires  N  number of bytes
depending on the number of capabilities defined for kermit.   Each  bit
position of these 6-bit fields corresponds to a capability with the low
order bit  used  to  indicate  whether  or  not another capability byte
follows.  If the low order bit is  "1"  then  another  capability  byte
follows.  If the low order bit is "0" then the current byte is the last
capability byte.   The  second  through  sixth  bit positions represent
capabilities in the same way.  If a bit position is set to 1  then  the
capability it  represents  is present.  If the bit position is set to 0
then the capability it represents does not exist.  Currently, there are
only 3 capabilities defined for Kermit as follows:

    #1  Reserved
    #2  Reserved
    #3  Ability to accept "A" packets (file attributes)

The windowing capability will constitute a fourth  capability  and  the
fourth bit  of  the  capability  field  will  be set to 1 if the kermit
implementation can handle windowing.

    #4  Ability to handle windowing.

The remaining fields of the Send-Init packet are  either  reserved  for
future use  by  the standard Kermit protocol or reserved for local site
implementations.  The four fields following the  capability  field  are
reserved for the standard Kermit protocol.  We propose the use of field
11 to be used to specify the "Window Size" for all kermits

   11       12       13       14       15       16 - N
  +--------+--------+--------+--------+--------+------------------+
  | WINDW  | RESV1  | RESV2  | RESV3  | RESV4  | LOCAL Reserved   |
  +--------+--------+--------+--------+--------+------------------+

11. WINDW - The window size to be used encoded printably using
    the char() function.  The window size may range from 1 to 31
    inclusive.

The sender  will  specify  the  window  size  it  wishes to use and the
receiver will reply (in the ACK packet) with the window size it  wishes
to use.   The window size actually used will be the minimum of the two.
If the receiver replies with a window size of 0 then no windowing  will
be done.


4 TRANSFER DATA (STAGE 3)

The sequence  of  events  required for the transmission of data packets
and confirmation of receipts  constitute  the  main  functions  of  the
windowing protocol.   There  are  four  main  functions  which  can  be
identified within this stage.  These are:

     - the sender's processing of the data packets,
     - the receiver's handling of incoming packets,
     - the sender's handling of the confirmations,
     - the error handling on both sides.

The following discussion details the specific actions required for each
of these functions.  Refer to the  state  table  at  the  end  of  this
document for  the  specific  action taken on a "received message" basis
for the full protocol.

   4.1 The Sender's Processing of Data Packets

   The sender instigates the transmission by  sending  the  first  data
   packet and  then  operating in a cyclical mode of sending data until
   the defined window is closed.

   Data to be sent must be read from the file, encoded into the  Kermit
   Data packet, and saved in a Send-Table.  A Send-Table entry consists
   of the  data  packet itself (which makes convenient the re-send of a
   NAKed packet), a bit which keeps track of  whether  the  packet  has
   been ACKed (the ACKed bit), and a retry counter.  The table is large
   enough to hold all the packets for the protocol window.

   Before each transmission, the input buffer is checked and  input  is
   processed, as  described  below.   Transmission  is  stopped  if the
   protocol window "closes", that is, if the Send-Table is full.

   4.2 The Receiver's Handling of Incoming Packets

   The receiver keeps its  own  table  as  it  receives  incoming  data
   packets.  This  allows  the  receiver  to receive subsequent packets
   while it is waiting for a re-send of an erroneous  or  lost  packet.
   In other  words,  the incoming packets do not have to be received in
   sequential order and can still be written to disk in order.

   A Receive-Table entry consists of the data packet, a bit which keeps
   track of whether a good version of the packet has been received (the
   ACKed bit), and a retry counter for the  NAKs  we  send  to  request
   retransmissions of  the  packet.   The table is large enough to hold
   all the packets for the protocol window.

   The different possibilities for a received packet are:

      1. A new packet, the next sequential one (the usual case)
      2. A new packet, not the next sequential one (some were lost)
      3. An old packet, retransmitted
      4. An unexpected data packet
      5. Any packet with a bad checksum

   These are discussed separately below.

   1.  The next new packet has sequence number  one  past  the  <latest
   table entry>.  The packet is ACKed, and the Receive-Table is checked
   for space.   If  it  is  full (already contains window_size entries)
   then the oldest entry is written to disk.  (This entry  should  have
   the ACKed  bit set.  If not, the receiver aborts the file transfer.)
   The received packet is then stored in the  Receive-Table,  with  the
   ACKed bit set.

   2.  If the packet received has sequence number  in  the  range  <two
   past the  latest  table entry> to <window_size past the latest table
   entry> then it is a new packet, but some have been lost.  (The upper
   limit here represents the  highest  packet  the  sender  could  send
   within its  protocol  window.  Note that the requirement to test for
   this case is what limits the maximum  window_size  to  half  of  the
   range of  possible  sequence numbers) We ACK the packet, and NAK all
   packets that were skipped.  (The skipped packets are those from <one
   past the latest table entry> to <one before  the  received  packet>)
   The Receive-Table is then checked.  The table may have to be rotated
   to accomodate the packet, as with case 1.  (This time, several table
   entries may  have  to  be written to disk.  As before, if any do not
   have the ACKed bit set, they will trigger an abort.)  The packet  is
   then stored in the table, and the ACKed bit set.

   3.  A retransmitted packet will have sequence number  in  the  range
   <the oldest table entry> to <the latest table entry>.  The packet is
   ACKed, then placed in the table, setting the ACKed bit.

   4.  A packet with sequence number outside of  the  range  from  <the
   oldest table  entry> to <window_size past the latest table entry> is
   ignored.

   5.  If the packet received  has  a  bad  checksum,  we  must  decide
   whether to  generate  a  NAK,  and if so, with what sequence number.
   The best action may depend on the configuration  and  channel  error
   rate.  For  now,  we  adopt  the  following heuristic:  If there are
   unACKed entries in our Receive-Table, we send a NAK for  the  oldest
   one.  Otherwise  we ignore the packet.  (Notice that this will occur
   in a common case:  when things have  been  going  smoothly  and  one
   packet gets  garbled.   In this case, when we later receive the next
   packet we will NAK for this one as described under Case 2 above.)

   4.3 The Sender's Handling of Confirmations

   The sender's receipt of confirmations controls the rotation  of  the
   Send-Table and  normally returns the sender to a sending state.  The
   sender's action  depends  on  the  packet  checksum,  the  type   of
   confirmation (ACK  or  NAK),  and whether the confirmation is within
   the high and low boundaries of the Send-Table.

   If the checksum is bad the packet is ignored.

   When the sender receives an ACK, the sequence  number  is  examined.
   If the  sequence  number is outside of the current table boundaries,
   then the ACK is also ignored.  If the sequence number is  inside  of
   the current  table  boundaries then the ACKed bit for that packet is
   marked.  If the entry  is  at  the  low  boundary,  this  enables  a
   "rotation" of  the  table.   The low boundary is changed to the next
   sequential entry for which the ACKed bit is  not  set.   This  frees
   space in the table to allow further transmissions.

   When the sender receives a NAK, the table boundaries are checked.  A
   NAK outside  of  the  table boundary is ignored and a NAK inside the
   table boundary indicates that the sender must  re-send  the  packet.
   The sender  first tests the packet's retry counter against the retry
   threshold.  If the threshold has been reached, then the transfer  is
   stopped (by going to the Abort state).  Otherwise, the retry counter
   is incremented and the packet re-sent.

   4.4 Error Handling for Both Sides

   Three situations  are  discussed  here:   Sender  timeout,  Receiver
   timeout, and invalid packets.

   If certain packets are lost, each side may "hang", waiting  for  the
   other.  To  get  things  moving  when  this  happens each may have a
   "timeout limit", the longest they will wait for something  from  the
   other side.

   If the sender's timeout condition is triggered, then  it  will  send
   the oldest  unACKed  packet.   This  will  be  the  first one in the
   Send-Table.

   If the receiver's timeout condition is triggered, then it will  send
   a NAK  for the "most desired packet".  This is defined as either the
   oldest unACKed packet, or if none are unACKed, then the next  packet
   to be received (sequence number <latest table entry plus one>).  The
   packet retry  count  is  not  incremented  by  this NAK;  instead we
   depend on the timeout retry count, discussed next.

   For either the sender  or  receiver,  the  timeout  retry  count  is
   incremented each  time a timeout occurs.  If the timeout retry limit
   is exceeded then the side  aborts  the  file  transfer.   Each  side
   resets the retry count to zero whenever they receive a packet.

   In addition, as with the existing Kermit, any invalid  packet  types
   received by either side will cause an Error packet and stop the file
   transfer.


5 SEND AND ACCEPT END_OF_FILE PACKET (STAGE 4)

There are  several  ways  to  end  the file transfer.  The first is the
normal way, when the sender encounters an  end-of-file  condition  when
reading the  file  to  get  a  packet  for transmission.  The second is
because of a sender side user interrupt.  The third  is  because  of  a
receiver side user interrupt.  Both of these cause the received file to
be discarded.   In  addition  either side may stop the transfer with an
Error packet if an unrecoverable error is encountered.

   5.1 Normal End of File Handling

   When the sender reaches the end of file, it must wait until all data
   packets have been acknowledged before sending  the  End-of-File  (Z)
   packet.  To  do this it must be able to check the end-of-file status
   when it processes ACKs.  If the ACK  causes  the  Send-Table  to  be
   emptied and  the  end-of-file has been reached, then a transition is
   made to the Send_Eof state which sends the End_of_File packet.

   When the  receiver  gets  the  End_of_File  packet,  it  writes  the
   contents of  the  Receive-Table  to  the file (suitably decoded) and
   closes the file.  (If any entries do not have the ACKed bit set,  or
   if errors  occur  in  writing the file, the receiver aborts the file
   transfer.)  If the operation is successful, the  receiver  sends  an
   ACK.  It  then  sets  its  sequence number to the End_of_File packet
   sequence number and goes to Rcv_File state.

   5.2 Sender User Interrupt

   Whenever the sender checks for input from  the  data  communications
   line, it  should  also check for user input.  If that indicates that
   the file transfer should be stopped, the sender goes directly to the
   Send_Eof state and sends an  End_of_File  packet  with  the  Discard
   indication.  It  will not have to wait for outstanding packets to be
   ACKed.

   When the receiver gets  the  End_of_File  packet  with  the  Discard
   indication it  discards  the  file,  sets its sequence number to the
   End_of_File packet sequence number, and goes to RcvFile state.

   5.3 Receiver User Interrupt

   Whenever the receiver checks for input from the data  communications
   line, it  also  should check for user input.  If that indicates that
   the file transfer should be stopped, the receiver sets an "interrupt
   indication" of X (for "stop this file transfer") or of Z (for  "stop
   the batch  of  file  transfers").   When the receiver later sends an
   ACK, it places an X or Z in the data field.

   When the sender gets this ACK, it goes to  the  Send_Eof  state  and
   sends the  End_of_File packet with the Discard indication, as above.

   When the receiver gets  the  End_of_File  packet  with  the  Discard
   indication, it  discards  the  file, sets its sequence number to the
   End_of_File packet sequence number, and goes to RcvFile state.

   5.4 LOW LEVEL PROTOCOL REQUIREMENTS

   The Kermit windowing protocol, as defined in  this  document,  makes
   certain assumptions  about the underlying transmission and reception
   mechanism.

   First, it must provide a full-duplex channel so that messages may be
   sent and received simultaneously.

   Second, it will prove advantageous to  be  able  to  buffer  several
   received messages  at  the  low  level before processing them at the
   Kermit level.  This is for two  reasons.   The  first  is  that  the
   Kermit windowing  level  of the protocol may take a while to process
   one input, and meanwhile several  others  may  arrive.   The  second
   reason is  to  support XON/XOFF flow control.  If Kermit receives an
   XOFF from the data communications line, it  must  wait  for  an  XON
   before sending  its  packet.   While  it  is  waiting, the low level
   receive must  be  able  to  accept  input.   Otherwise  a   deadlock
   situation could  arise  with  each side flow controlled, waiting for
   the other.

   5.5 KERMIT WINDOWING PROTOCOL STATE TABLE

   The following defines the inputs expected,  the  actions  performed,
   and the  succeeding  states for proposed new Send_Data_Windowing and
   Rcv_Data_Windowing states.

   If both sides agree on windowing in the  Send  Init  exchange,  then
   instead of  entering  the  old  Send_Data  or  Rcv_Data  states from
   Send_File or Rcv_File,  we  enter  the  new  Send_Data_Windowing  or
   Rcv_Data_Windowing.


   SEND_DATA_WINDOWING

   Rec'd Msg  Action     Next State
   ---------  ------     ----------

   No input/Window closed  (1) Wait for input     SDW
   No input/Window open    (2) Read file, encode packet, SDW
   Place in table, mark unACKed,
   Send packet

   ACK/ X or Z      (3) set interrupt indicator (X/Z)  Send_Eof
   ACK/outside table -ignore-SDW
   ACK/inside table (4) mark pkt ACKed,  SDW or Send_Eof
   if low rotate table,
   if file eof & table empty
      then goto Send_Eof

   NAK/outside table -ignore-SDW
   NAK/inside table (5) test retry limit,  SDW
   re-send DATA packet

   Bad checksum     -ignore- SDW

   Timeout   (6) re-send oldest unACKed pktSDW

   User interrupt   (7) set interrupt indicator (X/Z)  Send_Eof

   Other     (8) send Error Abort


   RCV_DATA_WINDOWING

   Rec'd Msg  Action     Next State
   ---------  ------     ----------

   DATA/new  (1) send ACK    RDW
   if table full: file & rotate
   store new pkt in table
   DATA/old  (2) send ACK, store in table  RDW
   DATA/unexpected  -ignore- RDW

   Z/discard (3) discard file     Rcv_File
   Z/ (4) write table to file & close    Rcv_File
   if OK send ACK, else Error     or Abort

   Bad checksum     (5) send NAK for oldest unACKed      RDW

   Timeout   (6) send NAK for most desired pkt    RDW

   User Interrupt   (7) Set interrupt indicator X or Z   RDW

   Other     (8) send Error pkt    Abort

------------------------------

End of Info-Kermit Digest
*************************
-------
23-Jul-85 17:11:31-EDT,16806;000000000001
Mail-From: SY.FDC created at 23-Jul-85 17:10:57
Date: Tue 23 Jul 85 17:10:57-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #8
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue, 23 Jul 1985       Volume 3 : Number  8

Departments:

  PROPOSAL FEEDBACK -
    Sliding Window Proposal, Cont'd
    Sliding Window Proposal Q & A

  MISCELLANY -
    Conversion Tables, Liberalized Requirements
    More about IBM Professional Graphics Controller (several msgs)
    Using Kermit with Ungermann-Bass Net One?

----------------------------------------------------------------------


Date: Tue 23 Jul 85 13:12:23-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Sliding Window Proposal, Cont'd
Keywords: Sliding Windows Kermit

The proposal in Info-Kermit V3 #7 should have been dated July 19, not June
12, and the formatting of the state table at the end appears to have been
messed up -- apologies.

The next message (about 10K long) gives some informal information about
the proposal in the form of questions and answers.  Comments, reactions,
suggestions on both the long-packets and the windowing proposals encouraged.

------------------------------

Date: Mon 22 Jul 85 09:30:00-EDT
From: Leslie Spira <OC.SOURCE@CU20B>
Subject: Sliding Window Proposal Q & A
Keywords: Sliding Windows Kermit


                           KERMIT WINDOWING PROTOCOL

                 DRAFT PROPOSED DEFINITION DATED JULY 19, 1985

                             QUESTIONS AND ANSWERS

                    John Mulligan, The SOURCE Telecomputing

                                 July 19, 1985

Q.  What is the purpose of the "windowing" extension?

A.  The object is to speed up file transfers using KERMIT.  The increase
    will be especially noticeable over the data networks (such as Telenet
    and Tymnet) and over connections using satellite links.  This is
    because there are long communications delays over these connections.


Q.  How does it work?

A.  Basically, it allows you to send several packets out in a row before
    getting the first acknowledgment back.  The number of packets that can
    be sent out is set by the "window size", hence the name windowing.


Q.  Could you explain in more detail?

A.  Right now, a system sending a file transmits one packet of data, then
    does nothing more until it gets back an acknowledgment that the packet
    has been received.  Once it gets an acknowledgment, it sends the next
    packet of data.  Over standard direct-dial land-based phone lines, the
    transmission delays are relatively small.  However, the public data
    networks or satellite links can introduce delays of up to several
    seconds round trip.  As a result, the sending system ends up spending
    much more time waiting than actually sending data.

    With the new windowing enhancement, the sending system will be able to
    keep sending data continuously, getting the acknowledgments back
    later.  It only has to stop sending data if it reaches the end of the
    current "window" without getting an acknowledgment for the first
    packet in the current "window".


Q.  What size is the "window"?

A.  The window size can vary depending on what the two ends of the
    connection agree on.  The suggested standard window size will be 8
    packets.  The maximum is 31 packets.

    The KERMIT sequence numbering is modulo 64 (it "wraps" back to the 1st
    sequence number after the 64th sequence number).  It is helpful to
    limit the maximum window size to 31 to avoid problems (ambiguous
    sequence numbers) under certain error conditions.


Q.  Is windowing in effect throughout a KERMIT session?

A.  No, it is only in effect during the actual data transfer (data
    packets) portion of a file transfer.  Windowing begins with the first
    data packet (D packet type), and stops when you get an End-of-File
    packet (Z packet type).


Q.  Why does it stop when you get to the End-of-File packet?

A.  This is done primarily to avoid having more than one file open at
    once.


Q.  Why will windowing be especially helpful at higher baud rates over
    communications paths that have delays?

A.  As you increase the baud rate, the transmission speed of the data
    increases, but you do not change the delay caused by the
    communications path.  As a result, the delay becomes more and more
    significant.

    Assume, for example, that your communications path introduces a delay
    of 1 second each way for packets, for a total delay of 2 seconds round
    trip.  Assume also that your packets have 900 bits in them so it takes
    you 3 seconds to send a packet at 300 baud (this is roughly equivalent
    to a typical KERMIT packet).

    WITHOUT windowing, here is what happens:

    If at 300 baud you transmitted data for 3 seconds (sending 900 bits),
    then waited 2 seconds for each acknowledgment, your throughput would
    be roughly 180 baud.  (Total time for each transmission = 5 seconds.
    900/5 = 180).

    Howver, if you went to 2400 baud, you would transmit data for 3/8
    second, then wait 2 seconds for an acknowledgment.  (Total time for
    each transmission = 2 and 3/8 seconds).  The throughput would increase
    only to about 378 baud. (900 / 2.375 = 378).

    The delay becomes the limiting factor; in this case, with this packet
    size, the delay sets an outside limit of 450 baud (900 / 2 second
    delay = 450), no matter how fast the modem speed.

    WITH windowing, the throughput should be close to the actual
    transmission speed.  It should be possible to send data nearly
    continuously.  The exact speed will depend on the window size, length
    of transmission delays, and error rate.


Q.  Are there any new packet types introduced by this extension?

A.  No, the only change is to the contents of the Send-Init packet, to
    arrange for windowing if both sides can do it.  If either side cannot,
    KERMIT will work as it does now.  Adding an extension such as this was
    provided for in the original KERMIT definition.  See section 3 of the
    windowing definition for details.


Q:  On the receive side, in section 4.2, why does the definition say that
    writing to disk is done when the Receive-Table becomes full rather
    than as soon as you get a good packet?

A:  The definition was phrased this way because it makes the logic of the
    receive side clearer and simpler to implement.

    Actually, you could also write a packet to disk when it is a good
    packet and it is the earliest entry in the receive table.  This
    approach has the disadvantage that you don't know at this point that
    the sender has received your ACK, so you have to be prepared to handle
    the same packet later on if the sender never gets the ACK, times out,
    and sends the same packet again.  Thus you have to be prepared to deal
    with packets previous to the current window; you will have to ACK such
    a packet if it has been received properly before.

    By writing packets to disk only when the receive table becomes full,
    (the oldest packet) you know that the sender has received your ACK
    (otherwise the sender could not have rotated the window to the n+1
    position to send the current packet, where n is the window size).
    This makes it very easy to stay in synch with the sender.  The
    disadvantage of this approach is that when you receive the End-of-File
    packet, you have to take the time to write all the remaining packets
    in the Receive-Table to disk.


Q.  Could you briefly explain what happens if a single packet gets
    corrupted?

A.  In essence, the receiver will ignore the bad packet.  When it gets the
    next good packet, it will realize (because packets are numbered) that
    one or more packets were lost, and NAK those packets.  The receiver
    continues to accept good data.

    As long as the sender's window does not become "blocked", the only
    loss of throughput will be the time it takes to transmit the NAKed
    packets.

    For a full description, see section 4.2 of the windowing definition.


Q.  There are currently two proposals for KERMIT extensions: the Windowing
    extension and a proposal for extended packet lengths.  What are the
    relative advantages and disadvantages of sliding windows and extended
    packet lengths?

A.  What is best depends on the exact conditions and systems involved in a
    particular file transfer.  There are some general rules however.

    Windowing helps more and more as the communications path delays get
    longer.

    Windowing is also more and more helpful as the baud rate goes up.

    Increased packet length is most helpful on circuits with low error
    rates.  If the error rate is high, it is difficult for a long packet
    to get through uncorrupted.  Also, it then takes longer to re-transmit
    the corrupted packet.

    On some machines, the CPU time to process a packet is relatively
    constant no matter what the packet length, so longer packets can
    reduce CPU time.


Q.  Are extended packet lengths and sliding windows mutually exlusive?

A.  No, there is no real reason that they would have to be.  As a
    practical matter, it is slightly easier to implement windowing if you
    know the maximum packet size ahead of time, since you can then just
    use an array to store your data.  In standard KERMIT, you know
    automactically that your maximum packet length is 94, so you can just
    go ahead and dimension an array at 94 by Window-size.

    If you are going to use both extended packet length and windowing, you
    need to select the maximum packet length and window-size so that the
    combination does not exceed the available memory for each side of the
    transfer.

    In addition, it is possible to see the desired relationship between
    packet size and windowing for various baud rates and communications
    delays.  For the common case of an error corrected by one
    retransmission of the corrupted packet, the minimum window size needed
    for continuous throughput (the window never gets "blocked") can be
    calculated by:

                    4 x delay x baud rate
      WS  >   1 +  ------------------------
                       packet-size x 10           ;(this is the # of bits)


    Windowing always helps (the minimal continuous throughput window size
    is always greater than 1).

    In the above equation, the "4" derives from the fact that a corrupted
    packet has 4 transit times involved:

         Original (bad checksum) packet
         NAK for the packet
         Retransmission of packet
         ACK for retransmission.

    All of this must happen before the window becomes blocked.

    The "delay" is the effective maximum one-way communications path
    delay, which includes any CPU delays.

    Strictly speaking, the "packet-size" should have the length of the ACK
    packets added to it.

    As an example, if you assume a 2-second (one-way) delay, at 1200 baud,
    with a packet size of 94, the minimum window size for continuous
    throughput would be:

              4 x 2 x 1200
       WS  >  ------------    =   10.2
                94 x 10

    Under these circumstances, a window size of at least 11 should be
    chosen, if possible.


------------------------------

Date: Sat, 20 Jul 85 10:47:19 PDT
From: VSS7853@UCLAVM
Subject: Conversion Tables, Liberalized Requirements
Keywords: ASCII/EBCDIC Translation Tables

Regarding the message I sent the other day with the programs for
constructing and analyzing ATOE and ETOA tables, I think I could have
expressed my thesis a bit more clearly.

Kermit-TSO and Kermit-CMS require that the TCAM (or whatever) tables
be, loosely speaking, inverses of one another.  I claim that this
requirement is too restrictive and prevents Kermit from working on
systems where it otherwise might.

On Ebcdic machines, Kermit performs the following four translations:

1. (e to a) predict the Ascii form of an outgoing message so that a packet
            can be constructed in Ascii.
2. (a to e) map the packet back to Ebcdic for outputting and final
            reconversion by TCAM.
3. (e to a) reconstruct the Ascii form of an incoming packet already
            converted by TCAM, so that the packet can be analyzed in Ascii.
4. (a to e) map the incoming message back into its final Ebcdic form.

Presently these four internal transformations are done with only two tables,
each identical to the corresponding TCAM table.  Whence the requirement that
the two TCAM tables be inverses of one another.

I claim that by constructing four tables, one for each of the above numbered
functions, two benefits would accrue:

1. The requirements on the TCAM tables would be weakened.  Each table would
   have to be invertable separately, but they would no longer have to be
   inverses of each other.

2. Kermit could guarantee a standard correspondance between the two character
   codes for messages transmitted from Ascii machines to Ebcdic and vice
   versa, instead of accepting the correspondance imposed by the local TCAM
   tables.

In the other message I attempted to give precise weakened mathematical
requirements for the TCAM tables so that this method would work.

Also tools would have to be developed to construct the necessary translation
tables to be used by Kermit.  These tools ought to be included in the
distribution.

What do you think?

Glenn Thobe
EE dept., UCLA
818-888-8434

p. s. Please address replies to both IVA3GET@UCLAMVS and VSS7853@UCLAVM
(BITNET).

------------------------------

Date: Mon 22 Jul 85 16:55:26-EDT
From: Charlie C Kim <US.CCK@CU20B>
Subject: IBM Professional Graphics Controller
Keywords: Professional Graphics Card

It's called a Professional Graphics Controller (not Adapter).  Waiting for
the vertical retrace on the EGA isn't a bad thing to do--it's just
unnecessary in the enhanced mode.  It isn't so clear that it's the wrong
thing to do when it is emulating the CGA.

The problem with losing characters above 1200 baud on the PGC is well known.
The following message from the IBM-PC bulletin board should clarify the
issue:

  Date:  Thu, 4 Jul 85 13:54 EDT
  From:  "Roger C. King" <[e-mail]>
  Subject:  Professional Graphics Controller Fix

We have had IBM replace more than a dozen Professional Graphics controllers
with corrected units which work correctly with previous communications
packages at 9600 baud. The old unit did not work correctly at all, but sort
of worked on an AT at 2400 baud (sort of means some dropped characters) and
sort of worked on an XT at 1200 baud. It takes an individual, case by case,
interface with IBM to get this resolved, but it is possible for a field
office to get someone at Boca to send out corrected boards for a swap. A
good controller can be recognized as follows:

    Looking at a controller with the output on the right, the top left
    corner of the board has a 'REV' number, probably 6323698, whited out
    with white paint or something similar. A bad board(s), does not have
    this number modified.

As an aside, we have found the Professional Graphics Controller to be an
almost perfect emulator of the old Color Graphics controller. Even
low-res software seems to work correctly.

Roger King

------------------------------

From: Herm Fischer <hermix!fischer@RAND-UNIX>
Subject: Professional Graphics Controller
Date: Mon Jul 22 16:02:42 1985
Keywords: Professional Graphics Card

Carl Houseman reports problems over 1200 baud with this display.  He should
be aware that the async ports dont work over 1200 at all unless he gets
replacement PGA cards from IBM.  The original cards had hardware/firmware
problems which interfered with comm activity; IBM has "recalled" those
cards.

I am using the EGA on Xenix and on MSDOS with kermit.  So far no problems,
but have not tried EGA with MSDOS above 1200...

------------------------------

Date: 23 July 1985 1350-PDT (Tuesday)
From: [e-mail] (Marcelo Germar)
Subject: Using Kermit with Ungermann-Bass Net One?
Keywords: Ungermann-Bass Net One

Does anybody have experience using ibm pc kermit with ungermann-bass net one
to transfer files between a vax with 4.2bsd unix and an ibm pc?

What should be the configuration of the ungermann-bass hardware/software
to enable a successful file transfer?

All your help will be sincerely much appreciated.

thanks,
marcelo

------------------------------

End of Info-Kermit Digest
*************************
-------
26-Jul-85 17:53:40-EDT,15845;000000000000
Mail-From: SY.FDC created at 26-Jul-85 17:53:06
Date: Fri 26 Jul 85 17:53:06-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #9
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 26 Jul 1985       Volume 3 : Number  9

Departments:

  ANNOUNCEMENTS -
    Kermit for the PDP-8

  PROPOSAL FEEDBACK -
    Lurching Windows?
    About the New Proposals
    Kermit Windowing Questions and Answers...Continued

  MISCELLANY -
    Tranferring a MacPaint or MacDraw Document
    MS-Kermit and the Hercules Monochrome Graphics Card

----------------------------------------------------------------------

Date: Fri 26 Jul 85 17:07:42-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit for the PDP-8
Keywords: PDP-8 Kermit

This is to announce Kermit-8 for the DEC PDP-8 with OS8 or RTS8, written in
the PAL-8 assember by Jerry Sands and Randy Hippe of the Bureau of
Engraving, Inc., Minneapolis, MN.  It works in local mode only, includes
CONNECT, BYE, EXIT, SEND, GET, and RECEIVE commands, and can do wildcard
sends.  There is no documentation to speak of.  The program is in
K2:K08MIT.PAL (and .HLP) on CU20B, available via anonymous FTP.

This means that Kermit is now available for every single existing DEC
machine operating system, with the exception of IAS-11 (soon to be
contributed, I hope).  (I hope there aren't any PDP-1's, -4's, -6's, -7's,
9's, -12's, or 15's left out there...  If you have one, why haven't you
written Kermit for it?)  And if you count WPS-8 as an operating system,
maybe someone who knows something about it could convert this program for
the benefit all the poor DECmate users who need to transfer their WPS
"documents" to systems that don't have DX.

------------------------------

Date: Thu, 25 Jul 85 12:49:49 pdt
From: hpl-opus![e-mail]
Subject: Lurching Windows?
Keywords: Lurching Windows

I didn't see any discussion of how to extend this to half-duplex lines
("lurching windows").  Is any forthcoming?

Ken Poulton

[Ed. - See below.]

------------------------------

Date: 24 Jul 1985 1257-EDT
From: B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO.ARPA>
Subject: About the New Proposals
Keywords: Kermit Protocol Proposal

Yes, I have seen the stuff only "fly by" on the screen - so my comments will
be "fast and [maybe] not fully founded".  [By the way, I like both proposals
and believe, they both will work together.]

I would like to introduce the "bulk" ACK from the Receiver [didn't see that
mentioned - or "lost it on the screen"], i.e. the Receiver has the freedom
to "ACK" every X packets, where X can be between 1 and the agreed upon
maximum window-size.

Receipt of the "BULK" ACK forces a "sliding" of the SENDER's window, so that
it "starts" after receipt with the next packet.

The Receiver will discard packets with packet-nr's LESS than current "BULK"
ACK and "BULK" ACK minus MAX Window-size.  I will regard receipt of packets
with even smaller numbers a "serious errror" - i.e. stop receiving.

[To be "discussed more" : It might be also a good rule to FORCE an ACK on the
last two PACKETS BEFORE crossing the 64-magic to make sure, that the SENDER's
window slides nicely..]

I believe, that the above rules "get rid" of the receivers duty to keep a
"table" plus a relatively large buffer - it also leaves it open for the
receiver to "write to the 'disk' whenever he feels necessary"

It doesn't complicate SENDER behaviour - but the hightest overall "gain" is
anyhow at the 90% of down-loads from distribution-points, which typically
are slightly larger than "micro's" - and can afford the "extra" coding.

It also [as a side effect] eases handling of "larger packets" on the micro
[I just hate to debug the logic of a "floating table" depending on memory-
limits {relatively easy} plus "agreed upon" package size {slightly more
muggy} aggravated by [either] unexpected RE-Sends because I was too long
occupied didling the floppy or expected - i.e. I saw a bad packet , sent
a NAK but was not allowed to "throw away the rest".

Which leads to an "addendum" for the SENDER - all in the view of keeping
the coding EASY for all the micro-versions...

On receipt of a NAK - all PACKETS INCLUDING the NAKed one and [maybe already
sent other ones] will be re-sent.

If we are clever - remember the "bulk" number for the ACK didn't have to be
established - we can "train" the receiver to "trim down" the "bulk" number
depending on the amount of NAKs per X packets - thereby allowing a "macro"
adjustment to line-quality.

I will not go into "calculations" - but as a rule of thumb:

On SLOW channels [300 Baud] - there typically will be only ONE MORE packet
sent after the receiver sees the NAK - and its NOW the msg "Lets redo it
after the last good one" - so thats tolerable.

On "faster" channels [4800 Baud and UP] - there "might be" another packet
"sneaking in" - but "channel quality" typically tends to be better anyhow,
so "better quality" and "higher speed" make the overhead of above
simplification tolerable again.

... and last not least - one probably can even under CP/M with ist 64K
limitation handle both LARGER PACKETS and "floating ACKs"

Rgds,
Bernie.

--------------------------------------

Date: Fri 26 Jul 85 16:50:48-EDT
From: Leslie Spira <[e-mail]>
Subject: KERMIT Windowing Questions and Answers...continued.
Keywords: Sliding Windows Kermit

FORWARD:

The two proposed extensions to KERMIT, Windowing and Extended Packet
Length, are both useful.  They seem to me to be complementary, and each
solves certain problems that the other cannot.

The purpose for the development of the windowing protocol was to solve the
problem of how to increase throughput over circuits with long delays that
also had a potentially noisy section of the circuit.

The discussion of the Windowing protocol, and of Extended Packet Lengths,
should keep in mind the environments in which each would be useful.  In
some cases, a combination would provide optimum performance.

The extensions will only be implemented for situations that make sense.
In all cases, KERMIT Classic will still be available, with all its utility
of being able to handle varied enviroments.

While reading the following questions and answers, keep in mind that this
windowing definiton was developed to handle a common situation of long
circuit delays with possible moderate error rates.  KERMIT does not need
this type of extension for clean lines with insignificant delays - KERMIT
could be left alone, or use Extended Packet Lengths, in such environments.

Long delays with significant error rates will occur under two obvious and
common conditions:

    A.   Local phone line (of uncertain quality) to Public Data Networks
         (such as Telenet).

    B.   Satellite phone links.  These often occur with the lower-priced
         phone services, which often also have noisier lines.  In
         addition, satellite links will increase as more people need to
         transfer data overseas.

The above conditions will become more common, as well increased baud
rates, which make the delays more significant.

As an aside, note that the benefit of Extended Packet Lengths over the
Public Data Networks is limited by the number of outstanding bytes the PDN
allows.  (Internally, the PDNs require end-to-end acknowledgement.  They
use their own windowing system within the network.)  I don't currently
know the exact impact of this.

Now on to the questions...

Q.  Can sliding windows be done on half-duplex channels?  Are any
    modifications to the proposal required?

A.  An underlying assumption in the development of windowing was that
    there was a full-duplex channel.  (See section 5.4, "Low Level
    Protocol Requirements")

    The intent of windowing is to try to keep the sender continuously
    sending data.  Obviously, this is not possible on a half-duplex
    channel.  A better solution for half-duplex channels would be to use
    an extended packet length.

    An attempt to use windowing on half-duplex really is just a way of
    doing extended packet lengths.  The sender would send out a group of
    packets, then wait and get a group of ACKS.  It would be better to
    simply send out a large packet, which would have less overhead.


Q.  Is the cost in complexity for sliding windows worth the increase in
    performance?

A.  Under the conditions described above (long delays and possibly
    significant error rates) windowing can increase performance by a
    factor of 2, 3, or more, especially at higher baud rates.  This
    increase is necessary to make KERMIT viable under some conditions.
    With classic KERMIT over the Public Data Networks, I have had
    througput as low as 250 baud over a 1200 baud circuit (with a
    negligible error rate).  Windowing should allow throughput close to
    the maximum baud rate.

    Windowing is most helpful when the delay is significant in relation to
    data sending time.  Any delay becomes more significant as users move
    to higher baud rates (2400 baud and beyond).

    The complexity of implementing windowing has yet to be fully
    evaluated.  The first implementation (for the IBM PC using C-KERMIT)
    proved to be fairly manageable.  It appears that the windowing logic
    can be implemented so that KERMIT Classic uses the same code, but with
    a window size of 1, which should avoid having to keep separate
    sections of code.

    The windowing definiton was developed with the idea of keeping changes
    to KERMIT to a minimum.  No new packet types were developed, ACKs and
    NAKS were kept the same, and windowing is in effect only during actual
    data transfer (D packets).  We tried to define the protocol so that a
    window size of 1 was the same as the current classic KERMIT.

    These factors should help reduce the complexity of implementing
    windowing.  We currently have a working implementation of KERMIT for
    the IBM PC going through testing.

    It's fun to see the modem "Send" light stay on constantly!


Q.  Why doesn't the Windowing proposal use a "bulk ACK"?

A.  There are a couple of possibilities for ways to use some sort of
    "bulk" or combined ACK.  We looked at them when developing the
    Windowing definition.  We did not see any advantages that outweighed
    the disadvantages.

    Here are two possible ways of changing how ACKs would work:

    1.   An ACK for any packet would also ACK all previous packets.

    2.   A new "Bulk ACK" (BAK?) packet could be developed.

 1. The concept that an ACK would also ACK all previous packets seems
    attractive at first, since it would appear to reduce overhead.
    However, it has a major drawback in that you then must re-synch when
    you get errors.  This is because, once you have an error, you have to
    send a NAK, then stop and wait for a re-transmission of the NAKed
    packet, before you send out any more ACKs.  (If you sent out an ACK
    for a later packet, it would imply that you had received the NAKed
    packet.  Not until you safely get the re-transmission can you go ahead.)

    This would negate one of the nicest parts of windowing as it is
    defined now, which is that the sender can transmit continuously,
    including during error recovery, as long as the window does not become
    blocked.

    It does not appear to us that the reduction in the number of ACKs sent
    is worth this penalty.

    In addition, this is a departure from the way ACKs in KERMIT work
    now.  It seemed best to make as few changes to KERMIT as possible.  If
    this facility turns out to be useful, it would be better to introduce
    a new packet type (or other means of distinguishing regular ACKs from
    "Bulk ACKS").

 2. A new "Bulk ACK" packet type could be developed.  This did not seem to
    us to be a good idea, since it required defining a new packet type.
    We were trying to fit windowing in with as few changes to KERMIT as
    possible.

    A "Bulk ACK", in which one packet could contain a whole string of ACKs
    and NAKs, also seems like a good idea at first.  The penalty here is a
    little more subtle.  First, if you lose a "Bulk ACK" packet, you lose
    more information and it takes longer to get things flowing smoothly
    again.

    Second, and probably more importantly, efficient windowing depends on
    the window never becoming "blocked" (i.e., the sender can always keep
    sending).  A "Bulk ACK" interferes with this to some extent, because
    if you have a long delay, the "Bulk ACK" with its multiple individual
    ACKs may not get back to the sender in time to prevent the window from
    becoming blocked.

    With the current definition of windowing, returning an ACK for each
    packet gets the ACKs (or NAKs) to the sender as soon as possible.
    This provides the best chance for keeping the window open so that the
    sender can transmit continually.

    Once again, remember the conditions under which windowing is most
    useful: long delays with significant error rates.  Under these
    conditions, individual ACKs have advantages.

    If these conditions don't apply, it may not be necessary to use
    windowing, or it may be better to use extended packet lengths.

------------------------------

Date: Thu, 25 Jul 85 16:41:22 PDT
From: ucsfcca.ucsf![e-mail] (Joe DeBattista)
Subject: Tranferring a MacPaint or MacDraw Document
Keywords: MacKermit

I have a question about whether it is possible to upload and/or download a
MacPaint or MacDraw document.  When I use macput or macget with Versaterm or
MacTerminal this works ok, as it seems to grab the data and resource files
together.  When I try to upload to our VAX 750, I can only specify the data
or resource from the settings menu.  When I try to download a macpaint
document, I tried sending the data file first and then the resource, but
that didn't work.  I've checked the MacKermit documentation for hints, and
have asked people around here if they have a solution.  I am currently
running version 08(32).  Thanks.

                               Joe DeBattista
                               BITNET: jd9014@ucsfcca
                               UUCP: ucbvax!ucsfcgl!ucsfcca.ucsf!jd9014

[Ed. - It says somewhere in the Mac Kermit documentation that you can only
send one fork of a file at a time.  I think what you need to do is send each
fork separately, giving each a different name (like FOO.DATA and FOO.RSRC).
When bringing them back to the Mac, get the two files separately, each into
the appropriate fork of the same file.  I realize this is less than
satisfactory, but Kermit was not designed to anticipate that a file could
actually have more than one part; the other programs you mentioned are
Mac-specific and designed to know about this.  In general, I think the
safest way to treat arbitrary Mac files is to run them through Binhex before
transmitting to a foreign system, and unBinhex them upon return.]

------------------------------

Date:     Tue, 23 Jul 85 19:17:35 BST
From:     [e-mail]
Subject:  MS-Kermit and the Hercules Monochrome Graphics Card
Keywords: MS-DOS Kermit, Hercules Graphics Card

In response to query on MS-KERMIT with the Hercules card (vol 3
#5), I must say that I have encountered no problems, at least with
version 2.27.  Our configuration is an XT, DOS 2.10, and a fully
populated QuadRam expansion card.  We dedicate 360K to a RAM disk
using AST support though.  Good luck!

Les Wu

------------------------------

End of Info-Kermit Digest
*************************
-------
31-Jul-85 12:01:33-EDT,11240;000000000000
Mail-From: SY.FDC created at 31-Jul-85 12:00:20
Date: Wed 31 Jul 85 12:00:18-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #10
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Wed, 31 Jul 1985       Volume 3 : Number 10

Departments:

  ANNOUNCEMENTS -
    Summer Vacation
    Release 4C(057) of C-Kermit for Unix
    Update of Pascal/VS Kermit for IBM VM/CMS

  PROPOSAL FEEDBACK -
    Windows Considered Harmful
    Re: The New Proposals

  MISCELLANY -
    DDJ Article on Asynchronus Protocols
    TTSynch in VMS kermit
    VMS-Kermit and VMS 4.0
    Bug in Prime Kermit Shows Up with Kermit-MS 2.28
    Generic CP/M-80 Kermit Question (& Answer)
    Kermit-11 and IAS

----------------------------------------------------------------------

Date: Wed 31 Jul 85 11:18:21-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Summer Vacation

After this week, I'll be on vacation until the first week in September.
While I'm gone, some of the other people at Columbia will moderate the
Info-Kermit digest as time permits (we're all quite busy on other projects).
Let's keep the discussion of long packets and sliding windows going and see
if some concensus will emerge.  Meanwhile, address all Kermit-related
correspondence to Info-Kermit@CU20B or Info-Kermit-Request@CU20B, not to me
personally, so that it can be routed to whoever is handling the digest while
I'm gone.  - Frank

------------------------------

Date: Mon 29 Jul 85 20:15:03-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Release 4C(057) of C-Kermit for Unix
Keywords: C-Kermit, UNIX Kermit

This is to announce Yet Another Release of C-Kermit for Unix, 4C(057).
The changes, like last time, are minor:

. "set send packet-length" now overrides negotiated value, so that
  packet lengths in both directions can be controlled from one side.

. The Unix Kermit server now responds to all generic commands (but not
  "remote host" commands) in text mode, even if the file type is
  currently set to binary.  Remote host commands continue to obey the
  file type setting.

. Support for 4.1BSD, 2.9BSD, and BBN C/70 that was apparently broken
  in recent edits is (or should be) fixed again.

. A bug that sometimes prevented 14-character filenames on non-4.2bsd
  systems from being recognized is fixed.

. Several other bugs fixed relating to modem control, dialing, etc.  But
  reportedly some problems still remain -- see the .BWR file.

Thanks to Herm Fischer and Dan Schullman for reporting and/or fixing the bugs
corrected by this release.  The files are in K2:CKU*.* and K2:CKC*.* on CU20B,
available via anonymous FTP.  CKUKER.UPD lists the changes in greater detail,
CKUKER.BWR lists the known bugs and restrictions, CKUKER.DOC (and .MSS) is an
updated Kermit User Guide manual chapter.

This should be the last release of C-Kermit until some time in September.
In the meantime, send suggestions, comments, complaints, bug reports and fixes
to Info-Kermit@CU20B, as usual.

------------------------------

Date:    Mon, 29 Jul 85 11:23 EDT
From:    [e-mail]
Subject: Update of Pascal/VS Kermit for IBM VM/CMS
Keywords: VM/CMS Pascal Kermit

I have made a few changes to the Pascal/VS version of Kermit-CMS to correct a
few bugs.  So I am sending you updated source code for it.

Victor Lee, Queen's University

[Ed. - The updated program is in K2:CM2MIT.*.]

------------------------------

Date: Tue, 23-Jul-85 11:44:51 xDT
From: (anonymous)
Subject: Windows Considered Harmful
Keywords: Sliding Windows Kermit

The windowing stuff looks far too complex; I think it will greatly
decrease one of the Kermit's main points -- its fundamental simplicity.
The interrupt stuff to make such things work can be a tremendous pain on
many systems, and it really is probably not worth the effort.

Large packets are OK, but I don't think people are going to see as much
of an advantage as they think, even on long hauls.

With every one of these mods, things get a little less compatible and a
little less universal.  I personally think that efforts in this area are
starting to show signs of "feature-itis" that would best be avoided.

------------------------------

Date:  Sat, 27 Jul 85 00:48 EDT
From:  [e-mail]
Subject:  Re: The New Proposals
Keywords: Kermit Protocol Proposal, Sliding Windows Kermit, Long Packets

Hi.  I vote for both proposals, in my environment I can use both, though
probably separately.  The sliding window proposal would be great for our
communications Boston -> Tymnet -> Transpac -> Versailles which is plagued
by long long delay ... and won't allow long packets either.  Meanwhile, in
house our poor VAX is swamped when Kermit is going at 9600 baud due to
its lousy TTY input interrupt handling (per character) and at least long
packets would reduce the number of task switches and I suspect lead to
better interactive performance for the non-Kermit users.  Assuming of course
it'll eat a long package without losing characters ... that remains to be
tested.  [Anyway, the easiest way to test it would be for someone else
to implement long packets in Kermit and then ...]

I wanted to point out that although in kermit-digest V3 #9 it
was mentioned that long packets wouldn't be good given fast error-free
communication I disagree:  I think timesharing hosts would benefit by the
fewer task switches from OS read to application Kermit.

-- Dave (Bakin -at mit-multics)

------------------------------

Date: Wed 31 Jul 85 01:28:11-PDT
From: Bob Larson <BLARSON%ECLD@ECLA>
Subject: DDJ Article on Asynchronus Protocols
Keywords: Asyncronous Protocols

Kermit is mentioned in the article "Asynchronous Protocols" in the
August 1985 issue of Doctor Dobbs Journal.  The article is an overview
of several asyncronous protocols.

It does state "It [Kermit] may become a widely used standard in the near
future," but devotes much more space to discussing versions of [x]modem[7].

Bob Larson <[e-mail]>

------------------------------

Date: Mon, 22 Jul 85 09:11:50 edt
From: Steve Archer <[e-mail]>
Subject: TTSynch in VMS kermit
Keywords: VMS Kermit

We find here locally, that we have to do a 'set term /noTTSynch' before
we use the VMS kermit with any half duplex machine that uses Xon/Xoff
protocol.  Apparently the machines that VMS kermit was written for are that
way by default.  Having to do the set term confuses many of our casual
users of kermit.  Kermit could very easily do this automatically for the
user.  Could this be incorporated in the next VMS kermit release?

steve {seismo,allegra}!rochester!kodak!archer

------------------------------

Date: Thu, 25 Jul 85 09:33:31 edt
From: <decvax!cincy![e-mail]>
Subject: VMS-Kermit and VMS 4.0
Keywords: VMS Kermit

VMS-Kermit (Version 3.1.066) was running fine under VMS 3.6, but shows
annoying habits under 4.0: in connect mode, long outputs from the remote
host are echoed by ^G (BEL) (going to the remote host). This obviously
confuses the remote host. I conjecture that the bell is the same as
the one now heard on logging in. (We set the line protections of regular
terminal lines so that they can be allocated by WORLD.)

I would be grateful for any suggestions.

Henning Schulz-Rinne
Univ. of Cincinnati

------------------------------

Date:     Friday, 26 Jul 85 17:11:47 EDT
From:     rmcqueen (Robert C McQueen) @ sitvxb.CCNET
Subject:  Re: VMS Kermit Problems
Keywords: VMS Kermit

Ok, noted.  First person to have free time will look into them.

------------------------------

Date: 26 Jul 85 09:15:06 ADT
From: CGP@UNBMVS1
Subject: Bug in Prime Kermit Shows Up with Kermit-MS 2.28
Keywords: Prime Kermit, MS-DOS Kermit

Prime Kermit can not be used in server mode with Kermit-MS 2.28.
The problem is that Prime kermit NAKs the Init-Info packet, instead of
responding with an Error packet as specified in the Protocol Manual.

Kermit-MS 2.26 does not seem to use the Init-Info packet, and did
work with Prime Kermit.  I have not tested it with 2.27.

I have modified Prime Kermit to honor the Init-info packet.  What is the best
way to forward the corrected source?

                             Carl Pottle
                             University of New Brunswick
                             Saint John, N.B.
                             Canada
                             CGP@UNBMVS1

[Ed. - Just send the new code by electronic mail to Info-Kermit@CU20B.]

------------------------------

Date: 16 Jun 1985 11:33:08 EDT (Sunday)
From: Tom Reid (MS W932) <treid@mitre-gateway>
Subject: Generic CP/M-80 Kermit Question
Keywords: CP/M-80 Kermit

To make a long, sad story short, I have an Ithaca Intersystems Z80/CPM
system with an interrupt driven serial board.  This makes the usual
direct port addressing schemes of communication packages impossible
to install.  Generic Kermit's only requirement of an installed IOBYTE
seemed a perfect solution.

However, Kermit goes direct to the devices crt:, tty:, etc. rather than
at the virtual CON:, RDR:, and PUN:.  I have tried to hook the II to a
Kaypro 2x direct connect through the modem port and with the KP being the
II's terminal.  (As a terminal, it is fine, but cannot establish
communication when a file transfer is initiated).

Any ideas of how to proceed from here?  Thank you in advance for your
help.  Please reply directly to me as I am not on the info-kermit mailing
list.  If there is interest, I will summarize and post any replies
and solutions to info-kermit.  Tom Reid.

------------------------------

Date: 27 Jul 1985 00:12 PST
From: Charles Carvalho <CHARLES@ACC>
Subject: Re: Generic CP/M-80 Kermit Question
Keywords: CP/M-80 Kermit

Generic Kermit has to know what physical devices are in use because the
only way it can test the modem port for data available is to make it the
console and use the "get console status" bdos call.

The console port and the modem port must be different ports; if your
system doesn't have a builtin console, you'll need a terminal connected
to the console port, and the Kaypro connected to the serial port.

Given the physical device names (TTY/CRT/UC1/PTR/etc) of the console port
and the serial port, the proper argument for the SET PORT command may
be found in the CP/M Kermit chapter of the User's Manual.  /Charles

------------------------------

Date: 30 JUL 85 10:52-EST
From: [e-mail]
Subject: Kermit-11 and IAS
Keywords: Kermit-11, IAS

Status of Kermit-11 for IAS v3.1:

I have just talked with an EPA site and they plan to have Kermit-11
running on IAS 3.1 by Sep 1. This version of Kermit-11 will not be able to
do wildcard file operations (at least at first) and some of the mcr/dcl
interface will be lost. Addtionally, sources will be separate from
Kermit-11's source as IAS 3.1 does not support some of the assembler
directives I used thus forcing the EPA to merg some source files and make
other minor (but very numerous) changes.  They are working from a very
recent copy of Kermit-11, so there should otherwise be a good measure of
compatibility.

                                                brian nelson
                                                [e-mail]

------------------------------

End of Info-Kermit Digest
*************************

-------
 1-Aug-85 14:51:21-EDT,23882;000000000001
Mail-From: SY.FDC created at  1-Aug-85 14:48:27
Date: Thu 1 Aug 85 14:48:26-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #11
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu,  1 Aug 1985       Volume 3 : Number 11

SPECIAL SLIDING WINDOWS ISSUE --
    Comments on Comments on Lurching Windows
    Sliding Windows -- When to Write to Disk?
    Mutual Exclusivity of Sliding Windows and Long Packets?
    Implied ACKs, Half Duplex Windows
    Full-Duplex Windowing vs CP/M, et al
    Proposal for Half Duplex Windows
    Examination of Proposals
    Full Duplex Sliding Windows -- Let's Give Them a Try

----------------------------------------------------------------------


Date: Sun, 28 Jul 85 21:32:40 pdt
From: "Scott Weikart; Community Data Processing;
 415-322-9069" <cdp!scott@Glacier>
Subject: Comments on Comments on Lurching Windows
Keywords: Sliding Windows Kermit

> Date: Fri 26 Jul 85 16:50:48-EDT
> From: Leslie Spira <[e-mail]>
> Subject: KERMIT Windowing Questions and Answers...continued.
>
>     The intent of windowing is to try to keep the sender continuously
>     sending data.  Obviously, this is not possible on a half-duplex
>     channel.  A better solution for half-duplex channels would be to use
>     an extended packet length.
>
>     An attempt to use windowing on half-duplex really is just a way of
>     doing extended packet lengths.  The sender would send out a group of
>     packets, then wait and get a group of ACKS.  It would be better to
>     simply send out a large packet, which would have less overhead.

Actually, this is not quite true.  If the channel is noisy, then longer
packets won't increase the data rate.  Tha advantage of a lurching window
scheme is that the receiver could NAK all the small packets that didn't
make it, and then the sender could resend the NAKed packets plus some new
packets in the next bundle.

I think that lurching windows would be a good idea.

-scott

------------------------------

Date: Thu, 850725 15:11:20-EDT
From:   Peter Marshall  <[e-mail]>
Subject: Sliding Windows -- When to Write to Disk?
Keywords: Sliding Windows Kermit

I would like to add a question to the group produced by John Mulligan
produced in a recent Kermit-digest.  I wonder if someone could explain
why it would be so much more difficult to write a received packet to
disk, when you have correctly received it?  His explaination does not
make sense to me.  Just because you write a packet to disk does not mean
that you have to clear it from the receive table at that time.  When you
actually clear the oldest message from the receive table for a new
message, then you can be assured that the sender has received the ACK.
So I don't see his argument about keeping things synchronized.  The ACKed
flag  in the table could also act as a "written to disk" flag.

Is it not a little unsafe to assume that you have received a packet
correctly (and send off an ACK to that effect) until you have actually
got it safely to disk?

------------------------------

Date: Tue, 30 Jul 85 20:41:16 EDT
From: [e-mail]
Subject: Mutual Exclusivity of Sliding Windows and Long Packets?
Keywords: Sliding Windows Kermit, Long Packets

I'm not sure that I understand what was meant by long packets and sliding
windows being mutually exclusive.  If it means that both would not be used
at the same time, that seems fairly reasonable (although packets a bit longer
than 96 characters wouldn't seem to be especially harmful).  If it means that
only one of the two proposals should be adopted, I disagree.  They are not
technically incompatible and each solves some problems that the other does not.

Sliding windows are best if the environment can support them.  However, some
major systems, such as the IBM 370 (TSO and, I think, CMS), do not support
the necessary full duplex channel.  TSO, at least, will support long packets.
The UCLA File Transfer Package sucessfully uses a 1K packet size on TSO and
CMS (using their own protocol).  We very much want improved Kermit performance,
but will never be able to support sliding windows on our TSO system.  On the
other hand, we also have a DECsystem-10, which can support sliding windows.
Those users would benefit from the extra performance of sliding windows over
long packets.

Lurching windows for half duplex channels were not addressed in the sliding
windows proposal.  It seems like sender and receiver would have to agree on
how many packets would be sent before the receiver would acknowledge.  The
sender would have to know not to try to send more packets until the previous
group was acknowledged.  I suppose that this number could be the window size.
Also, in a lurching windows environment, a way to acknowledge multiple
packets would be beneficial, as acknowledgements are not overlapped with
data.  The main difference between lurching windows and long packets seems
to be that lurching windows have more overhead bytes and that less data
might be retransmitted in case of an error.

One further point on lurching windows: I'm pretty sure that TSO would require
a delay of a charcater time or more between packets so that they would be
recognized as separate "lines" of input.  Otherwise, I think that everything
after the carriage return at the end of the first packet would be lost.
Also, when TSO detects a parity error it sends out a transmission error
message, which means that it would not be listening for the following packet,
so it would be lost too.  All in all, I think long packets are better for
half duplex channels and sliding windows are better for full duplex.

In the sliding windows proposal, I do not understand why the sending of
the end of file packet is delayed until all previous packets have been
acknowledged.  It seems to introduce an unnecessary delay.

Both proposals are optional -- no one would have to implement either, if they
don't care about the improved performance or want to defer the additional
complexity to a later version of their Kermit.

------------------------------

Date: Sat, 27 Jul 85 18:18:19 pdt
From: hpl-opus![e-mail]
Subject: Implied ACKs, Half Duplex Windows
Keywords: Sliding Windows Kermit, Long Packets

I have two comments on Leslie's Q+A in info-kermit #9.

On implied-ACKing:
    Leslie states that getting a NAK forces the protocol to
    stop sending.  I don't agree.  There's no reason for the sender to stop
    sending just because a NAK came.  The retry for the NAK'ed
    packet can be inserted (ASAP) into the stream of first-try packets.

    ACK's for packets successfully received after the NAK'ed packet
    will have to wait until the NAK'ed packet is successfully received.
    But this does *not* change window requirements: the window has to be
    long enough to cover the time for NAK and retransmission of packets anyway.

    Note that although ACK's must wait until all packets up to that point
    have been received correctly, NAK's for unsuccessful packets can
    be sent as soon as they are detected as being unsuccessful, i.e.
    upon successful receipt of the following packet.  This will help
    keep the protocol running smoothly.

    The only penalty is that since ACKs will be bunched by the receiver,
    the window must be longer by the number of packets implied by each
    ACK to keep the window from filling.

On windows in a half-duplex environment:

    This is dismissed as being just long packets, with the implication
    that one should just use long packets in a half-duplex environment.

    This is not true!  Half-duplex connections have exaclty the same problem:
    how to get good efficiency over long-delay + moderate error rate
    connections.

    I would like to have half-duplex sliding windows seriously considered!

Ken Poulton
hplabs!poulton

I know it's dumb, but half-duplex is the way many systems work...

------------------------------

Date: 27 Jul 1985 1334-EDT
From: B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO.ARPA>
Subject: Full-Duplex Windowing vs CP/M, et al
Keywords: Sliding Windows Kermit, CP/M-80

Since KERMIT-protocol has been invented and is successfully used in data
transfer between "micro's" and larger machines, let me take a look at the
"windowing" proposal as seen from the "micro's".

As is probably known, none of our current 'Van Neuman' machines can handle
more than one task at any given instant of time.  The illusion of
'time-sharing' and 'multi-tasking' or even 'multi-processing' are only
possible with the existence of a sophisticated interrupt-structure
[typically combined with 'hardware assisted' context-switching] and software
delivering the book-keeping services.

The currently most 'popular' micro-systems [CP/M and MSDOS or derivatives]
are SINGLE-tasking systems.  Although the used micro-processors typically
support a basic interrupt-structure, the lack of buffered and hardware
assisted I/O devices limits the interrupt-structure basically to ERROR
intercepts and clock-service.  -- Or in laymans terms, "A typical micro
CANNOT accept characters on the Input-port, as long as its reading or
writing to the floppy".

How, might You ask, did MODEM or KERMIT survive this basic flaw at higher
communication speeds ??  -- Very easily with a "trick" in ACKing a received
packet ONLY AFTER it had been written to storage [ - thereby making sure,
that NOTHING {except NOISE} could arrive at the input-port - and therefore
nothing could be lost ].

In view of these "basics", I would like to treat a "Window of Packets" as
one Very Large Packet, which just happens to be sliced into smaller packets
for ease of error-recovery.  And the micro only has to make sure, that it
can store the combined DATA-content of the Window in a buffer.

Following Frank's concerns of portability, I would like to propose "fixed"
windows ["fixed" in their "agreed upon" starting packet-Nr and their size -
in contrast to "sliding windows" , where an ACK for the first packet in a
window of packets can slide the starting-point downwards].

In comparison to the "large packet" proposal this technique is probably of
more immediate interest to micro-users since:

    a. Most Communication media are NOT totally error-free

    b. Most micros are quite limited in sustaining any baud-rate above
       4800 Baud between Communication-Port and File-storage [ infact
       some have even problems to sustain above rates between Comm-Port
       and terminal].


Here the "changes" in detail:

1.  Extend current KERMIT-Heuristic that "A NAK for the current packet is an
implied ACK for the previous one" to "A NAK for the current packet is an
implied ACK for all previous packets inside the current window".

2.  Introduce a rule, that the next [ fixed ] window of packets can ONLY be
sent, AFTER receipt of the LAST packet of the previous window has been
ACKed.  [This will guarantee the needed "silence on the input-port" during
'buffer-write to file-storage' on the micro.]

3.  Change the proposed Error-Recovery rule to "On a receipt of a NAK the
SENDER will re-send packets starting with the NAKed one".  [This will remove
the need to keep a "transfer-table" AND make re-synchonisation possible for
the micro without hefty recoding].

I believe, that with above changes, we only encounter a minimal "extra
overhead" in case of error-retransmission - probably NO extra overhead
time-wise at all , if the MAIN-Kermit can be written to be effectively
"interrupted" by receipt of a NAK from the micro - if he only can check for
NAK's between sending of packets, we'll incur a slight degradation timewise
as compared to the current protocol - since the NAK probably will arrive in
the middle of a not fully sent packet, which has to be re-sent again
according to the above changed rules.

We will however enjoy even "faster" transmission in the more prevailing case
of having NO ERRORS, since the single ACKs for each packet collapse into a
single ACK per window - and we will enjoy the same savings [or better] on
packet-based channels.

Rgds,
Bernie.

------------------------------

Date: Sat, 27 Jul 85 18:18:41 pdt
From: hpl-opus![e-mail]
Subject: Proposal for Half Duplex Windows
Keywords: Sliding Windows Kermit, Long Packets

A quick proposal for half-duplex sliding windows:

    Kermit negotiates both packet size and super-packet size
    (i.e., N packets per super-packet, where
    N should be less than half the window size).
    The sender then sends <=N packets, then the end-of-line character
    to delimit end-of-super-packet (NO end-of-line chars inside
    the super packet - this is a must for half-duplex receivers).

    The receiver sends back a super packet of
    ACKs and NAKs.  This could use either the implied-ACK scheme
    discussed above, or an explicit ACK or NAK for each packet
    in the super-packet.  The implied-ACK scheme has the advantage
    that, on clean lines, the returning super-packet consists of just
    one ACK packet.

    The sender then sends the next super-packet, starting with the
    outstanding NAK'ed packets, and filled up (to N packets max) with
    new (first-time) packets.

    This kind of protocol can't obtain the efficiency of the
    full-duplex sliding window protocol, since it must incur
    an overhead of one round-trip delay per super-packet.
    This can, however, still gain a factor of 2 or 3 over the
    current situation with 1200 baud lines with 2 second round trip
    delays.  It's *essential* for improvement over poor half-duplex
    connections where the error rates preclude getting long
    packets to work at all.

    I think what I have outlined is close enough to the
    full-duplex sliding windows to allow them to coexist in the same
    code.  All the full-duplex version needs to do is:
    1) negotiate half-duplex status and super-packet size along
        with window size (maybe we can negotiate handshake at
        the same time?)
    2) bunch packets without end-of-lines to form a super-packet
    3) wait for the replying super-packet before sending the next.

    Another advantage to allowing this half-duplex option is that
    this opens up greater flexibility for the implementation of
    sliding window Kermits, since this protocol can be implemented
    without multiprocessing.  This might make it a good choice
    for non-multi-processing systems or systems which make that difficult.

Ken Poulton
hplabs!poulton

------------------------------

Date: Thu 1 Aug 85 12:44:55-EDT
From: Leslie Spira <[e-mail]>
Subject: Examination of Proposals
Keywords: Sliding Windows Kermit, Long Packets

Dear Frank,

    Hugh Matlock and I sat down last night and studied in detail the
discussion about the proposed extensions.

    It seemed to us once again that there is a fundamental difference
between full-duplex environments and half-duplex environments.

    Looking at it, it appears that the problems in half-duplex can best be
solved by a large packet size with smaller sub-units that can be NAKed and
retransmitted as necessary.

    The attempts to modify windowing all ended coming around to this
concept.  We looked at three things that indicated this:

    1. Ken Poulton's suggestion of a way to do "super-packet" half-duplex
    (message dated July 27).  This is a effectively a super-packet with
    segmentation.  Hugh agrees with Ken Poulton that the coding on this
    suggestion would parallel well with the full-duplex coding.

    2. Bernie Eiben's "rewritten" reply dated 27 July.  As he notes: "...
    I would like to treat a 'Window of Packets" as one Very Large Packet,
    which just happens to be sliced into smaller packets for ease of
    error-recovery."

    3. The original extended packet length proposal, which could be
    modified so that checksums are placed after every 94 characters.  If
    you look at that definition, MAXLX1 simply becomes the number of
    sub-units in this view.


    Note what happened as people looked at "windowing" in the half-duplex
environment:  the choice of terminology was confusing at first, but
gradually sorted itself out into the fact that true sliding windows only
works in a full-duplex environment, and the equivalent in half-duplex is a
long packet with sub-units for ease of error-recovery.  This suggests that
the extended packet length proposal can be modified to include sub-units.

    I believe there is something of a philosophical turning point in
KERMIT's development appearing.  The Sliding Windows proposal provides
"high-end" performance for those higher capability environments (operating
system and communications channel) that are truly able to be full-duplex.
This "high-end" situation generally reflects the capabilities of later
systems on the market, which deserve to have their power taken advantage
of.

    On the other hand, I think that a Super-Packet with segmentation
proposal could reflect Classic KERMIT's concern with being able to operate
in all environments.  This proposal would need to take more enviroments
into account.  In some ways it is harder to define, because it may require
more changes to the existing KERMIT definition since it is more dependent on
KERMIT and less dependent on the operating system environment for
performance gains.

    This philosophical difference is just a way of analyzing the fact that
the two proposals have somewhat different intents, both of which I think
are valid.

    With this in mind, I think it might be helpful to change the name of
our proposal to "Full-Duplex Windowing Extension", in order to make it's
intent clear.  This definition is more dependent on the operating
environment, but its changes to the KERMIT definition are limited, in
that windowing is only in effect during transfer of data packets, there
are no new packet types, and the ACK and NAK stay pretty much the same.

    The criticisms of our proposal have been with our underlying decision
to operate in a full-duplex environment, rather than with the internal
consistency of the proposal.

    I'm putting the following points forward in our favor:

    1.   We have a complete, usable definition.

    2.   We have a working implementation for the IBM PC, and it is based
         on CKERMIT.  We are about to finish the PRIME implementation.

    3.   We will be making the code available to Columbia, and will be
         actively distributing it to communications software producers.

    4.   We have put lots of hard work into this. (Does that count??)

    5.   We have some unfortunate, but real, deadlines.

    6.   The sliding window definition can starting making some very great
         improvements in transfer times over the public data networks,
         where there currently is no other good solution to the throghput
         problem.

    7.   We (at The Source) currently have a chance to build additional
         momentum for KERMIT.  In a lot of ways, this opportunity
         (or window?) is much better now than it will be later.

    We would like to have the definition approved this week.  In
addition, we would then like to continue to contribute to the definition of
"super-packets with segmentation".

    I also would like to apologize for not having more time to approve
this; it was not our intent.  This is not a casual proposal however; it
has been pretty carefully thought through (indeed, the refinement of the
definition delayed it).

                                       Sincerely,

                                       John Mulligan

------------------------------

Date: Thu 1 Aug 85 14:17:00-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Full Duplex Sliding Windows -- Let's Give Them a Try
To: OC.SOURCE@CU20B, OC.Jordan@CU20B, Info-Kermit@CU20B
Keywords: Long Packets, Sliding Windows Kermit

John, Hugh, Leslie, Larry... Your arguments are persuasive.  You've clearly
done a lot of work (in a project like Kermit, that's usually what counts
most!).  I'd like to state my misgivings for the record, and then go ahead
grant you permission to use Bit #4 in the CAPAS field to indicate Full Duplex
Sliding Window Capability, and the field immediately after the CAPAS field
(remembering that the CAPAS field can grow) to designate window size, as you
have proposed.

My biggest misgiving is that we (you, I, and the Info-Kermit community) have
not had sufficient time to consider the proposal, and I will always have
nagging doubts that there may have been ways to improve it that would have
made more people happy.  As proposed, this capability requires true full
duplex operation.  In order for any computer to support this style of i/o,
it must be capable of EITHER multiprocessing OR fully interrupt-driven i/o
(or both).  Multiprocessing is something most micros can't do; it requires
certain hardware features like memory protection.  On the other hand, almost
any operating system allows access to its interrupt structure by the
programmer.  Unfortunately, the mechanisms for getting at interrupts vary
considerably among machines, operating systems, and even operating system
versions.  So a Kermit program that manages to "steal" the system's
interrupt vector in order to work correctly under version x of the operating
system might suddenly stop working when the user installs version y...  To
make matters worse, information about interrupt programming tends to be hard
to come by -- it's missing from the manuals, it's proprietary, or whatever
-- so when this is true, it makes it tough for even the motivated programmer
to do the work.

It's unfortunate that you have such pressing deadlines, and that I will be
gone for a month.  It may well be that your proposal is exactly what is
needed to kick Kermit protocol into the big leagues, but it might have been
possible to refine it in such a way that continuous full duplex transmission
would be possible for those systems capable of it, while provision was made
for those systems (CP/M-80 springs to mind) that have to turn their backs
on the communication port from time to time in order to write to the disk.

As you suggest, systems like CP/M along with the systems that really have
half duplex communication channels might be accommodated by the long-packet
extension, especially if modified to allow segmented long packets (this
reminds me of SMTP vs BSMTP...).  But it would be a lot cleaner if a single
Kermit extension could take care of everyone.

A final misgiving is that allocation of a CAPAS bit and Send-Init field is
irrevocable.  Once Kermit programs are out in the world that use them, they
can never be used for anything else.  Therefore, I'd like to emphasize that
the full duplex sliding window feature specified in Info-Kermit V3 #7 should
still be considered EXPERIMENTAL.  The group at The SOURCE will be tuning it
as they work on their new implementations, and I'm sure that some of the
comments and suggestions from Info-Kermit will be in the back of their
minds.  I expect that all this activity will settle down in a month or two,
and a "final" copy of the sliding window specification will be available
then.  Until then, no one should attempt to work from the current
specification without first contacting the people at The SOURCE (mail to
OC.SOURCE@CU20B).  Since the CAPAS bit and the window size field will be
allocated to their windowing method, it is essential that the protocol
invoked by them is clearly, completely, and unambiguously specified before
any programs using them are distributed to the public.

- Frank

------------------------------

End of Info-Kermit Digest
*************************
-------
 2-Aug-85 17:40:38-EDT,9111;000000000000
Mail-From: SY.FDC created at  2-Aug-85 17:40:04
Date: Fri 2 Aug 85 17:40:04-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #12
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri,  2 Aug 1985       Volume 3 : Number 12

Departments:

  ANNOUNCEMENTS -
        C-Kermit 4C(057) Hurriedly Replaced

  PROPOSALS -
        Attribute Packets, Windows
        A Vote FOR Long Packets
        Sliding Windows vs. Long Packets vs. Segmentation

  MISCELLANY -
        VMS Kermit and VMS V4
        Problem with Stevens' Kermit for Apple //
        Bugs in Version 2.28 of MS-DOS Kermit

----------------------------------------------------------------------

Date: Wed 31 Jul 85 18:07:00-EDT
From: Frank da Cruz <[e-mail]>
Subject: C-Kermit 4C(057) Hurriedly Replaced
To: [e-mail]
Keywords: C-Kermit

One of the edits in 4C(057) apparently broke C-Kermit on 68000's and
possibly other non-VAX, non-PDP-11 machines -- the old int/char pitfall.
Anyone who ftp'd C-Kermit from CU20B between 8:00pm-EDT July 29 and
6:00pm-EDT July 31 should pick up a new copy of K2:CKCFNS.C.  Too bad I
didn't have a 68000 to test this on -- apologies, and thanks to Philip Jeuck
<[e-mail]> for pointing out the problem.  You'll know if you have
the bad version if it announces itself with the date 29 Jul 85; the
(hopefully) fixed one is dated 31 Jul 85.

Also, there was a minor error in conditional compilation for 4.1BSD which
should also be fixed (K2:CKUTIO.C) and there was a minor change to the
makefile (K2:CKUKER.MAK), and a minor problem with subshell invocation
on systems with ints and pointers of different sizes (K2:CKUUSR.C).

This should REALLY be the last release of this program for at least a
month, so those who have not been getting new versions because they keep
changing so often should pick up this one.

------------------------------

Date: Fri 2 Aug 85 15:14:57-EDT
From: Frank da Cruz <[e-mail]>
Subject: Attribute Packets, Windows
To: [e-mail], [e-mail]
cc: Info-Kermit
Keywords: Sliding Windows Kermit, Attribute Packets

I was just looking at the protocol manual and realized that the current edition
does not contain something which might be useful to you, namely two new
attribute fields:  "1" specifies the exact byte count of the file, and "2"
specifies the byte size (e.g. "7" or "8").  This will be in the next edition.
Many people have asked for a somewhat finer-grained way to report the file
size than the number of K (e.g. some systems need to preallocate space, but in
some unit other than K).  - Frank

P.S. Bye till September.

P.P.S. I was waiting for a message to this effect from someone who called,
but it hasn't arrived, and I'm leaving now, so here it is in a nutshell:

If you have tested your sliding window algorithm with a slow (1200b or less)
line and a fast (hard or RAM) disk and it works as expected, please verify
that it ALSO works with a FAST (9600b or more) line and a SLOW (floppy) disk
before finalizing the protocol and releasing any programs that implement it
to the public.

P.P.P.S. To everyone -- please keep sending comments on the new proposals to
Info-Kermit@CU20B, even while I'm gone -- they'll appear in the digest on
a weekly basis, approximately.

------------------------------

Date: Thu, 1 Aug 85 14:04:13 pdt
From: hpl-opus![e-mail]
Subject: A Vote FOR Long Packets
Keywords: Long Packets, Sliding Windows Kermit

I'd like to cast a vote FOR the long-packet proposal.

It seems to me to be a simple enough extension that it can be implemented
and debugged quite quickly, without massive program changes.  There are a
number of situations where it will definately help; I have one user of
ST-Kermit who has already "rolled his own" long packets, and another
champing at the bit.

I see long packets as complementary to (and even compatible with) sliding
windows; there is no reason to have to choose only one.

If someone would specify the extra bits and bytes in the send-init packet
(very clever to have left those out of the proposal), we could get some
implementations going soon.  (Anyone want to volunteer for C-Kermit?)

Ken Poulton
hplabs!poulton

[Ed. - Let's leave the proposal open for discussion, but if you want to play
with an experimental implementation, let's say that the long packets bit is
bit #5 and the length fields are the 2nd and 3rd bytes after the CAPAS
field.]

------------------------------

Date: Fri, 2 Aug 85 09:42:58 cdt
From: [e-mail] (Jim Knutson)
Subject: Sliding Windows vs. Long Packets vs. Segmentation
Keywords: Sliding Windows Kermit, Long Packets

Something that hasn't been addressed in this, is the protocol negotiation.
In the past, both sides have not needed to negotiate because it was not
necessary.  Each side always transmitted what the other wanted.  If there
was disagreement over an option, the lowest common denominator was used.
Now we have several transmission schemes.  There is the normal packets
transmission with packet lengths up to 96 characters, extended packet
lengths, extended packet lengths with segmentation and sliding windows with
all the above options.  How will the correct scheme to use be decided
between the two Kermits.  Will a disagreement always bring you back to 96
character packets?  For example, if a user selects sliding windows on a
kermit that can have either sliding windows and/or extended packets and the
remote kermit can only do extended packets, will they both revert to 96
character packets?  Will extended packets be used?  What if both could have
done extended packets with segmentation but not sliding windows?  Are we
going to have a build in a priority CAPAS to prioritize the decision between
transfer schemes?

Jim Knutson

------------------------------

Date: Thu, 1 Aug 85 14:04:13
From: LCG.KERMIT
Subject: VMS Kermit and VMS V4
Keywords: VMS Kermit

Some of the folks at RCA have been using the new VMS Kermit on VMS V4.x and
noticed odd echoing which was traced to differences in the V4 terminal
driver's echo from V3. Characters like control-O were getting screwed up and
leaving local terminals in graphics mode, as a symptom.

It turned out there was a workaround. The procedure to use is as follows:

        Set line <whatever>
        local host set term <whatever> /PASTHRU
        connect

The result is that things then work OK. VMS V4 users may want to take note.
Charles Garman reported this to me.

        Glenn Everhart

------------------------------

Date:     Wed, 31 Jul 85 20:26:19 PDT
From:     [e-mail]
Subject:  Problem with Steven's Kermit for Apple //
Keywords: Apple II DOS Kermit

When sending a file (specifically, a text file in 7 bit mode) from either an
Apple ][+ or //e, to a Vax/Vms machine running V4 [with the V4 version of
Kermit], the Apple kermit gets a "WRITE PROTECTED" error AFTER the transfer
of the file (and the Vax deletes the file if the appropriate option is left
as the default) if the disk is write-protected.

It seems silly that write-protecting a disk should prevent the proper
reading of a file. Anyone have a fix for this before I delve into the file
manager?

                                                -Ken
Adelman, Caltech
                                                 [e-mail]
                                                 [e-mail]

[Ed. - Anybody out there who can help?]

------------------------------

Date: 2 Aug 1985 0653-PST
From: Pawka <PAWKA@NOSC-TECR>
Subject: Bugs in Version 2.28 of MS-DOS Kermit
To: [e-mail]
Keywords: MS-DOS Kermit

I found a couple of minor bugs in the Z-100 version of MS-Kermit,
Version 2.28, here are the fixes:

1) The STATUS command causes the program to wander off into never-
   never land, module MSSET.ASM had 2 instuctions missing, in routine
   BAUDPRT a push and a pop of di were missing:

        Was:
                BAUDPRT   PROC   NEAR
                call getbaud        ; read baud rate first

        Should be:
                BAUDPRT   PROC   NEAR
                push di             ; preserve this
                call getbaud        ; read baud rate first
                pop di

 2) The delete, backspace or Ctrl/H keys were not erasing characters
    in the command line. The routine that gets characters from the
    keyboard now, for some reason, puts out a space when it reads one
    of these characters. I fixed this by changing a string in
    MSXZ100.ASM:

        Was:
                delstr  db  BS,' ',BS,'$'

        Now:
                delstr  db  BS,BS,' ',BS,'$'

I hope this doesn't foul up something else, it seems o.k. for the stuff I do.

                                Mike Pawka
                                [e-mail]

[Ed. - Provided only for information to H/Z-100 folks; we'll check it out and
include in the forthcoming release if ok.]

------------------------------

End of Info-Kermit Digest
*************************
-------
 9-Aug-85 13:37:30-EDT,16925;000000000001
Date: Fri 9 Aug 85 13:34:34-EDT
From: The Mailer Daemon <[e-mail]>
To: [e-mail]
Subject: Message of 9-Aug-85 13:21:37

Message failed for the following:
*<KERMIT>[e-mail]: No such mailbox
        ------------
Date: Fri 9 Aug 85 13:21:37-EDT
From: Jeff Damens <[e-mail]>
Subject: Info-Kermit Digest V3 #13
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-to: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 09 Aug 1985       Volume 3 : Number 13

Departments:

  ANNOUNCEMENTS -
    Kermit directories/files have moved

  KERMIT ENHANCEMENTS DISCUSSION -
    Sliding windows on micros should work
    ANY-duplex Windows
    Half-duplex windowing and large packets

  UNIX KERMIT -
    CKermit Statistics

  MS-DOS KERMIT -
    Warning: Unrecognized Baud Rate

  MISCELLANY -
    How do you edit pc-ix sources?
    RT-11/TSX+ Kermit
    Wanted: Kermit for the Burroughs B-20s,B-25s,B-26s running BTOS.


----------------------------------------------------------------------


Date: Sat 3 Aug 85 09:02:08-PDT
From: Douglas Edwards <[e-mail]>
Subject: "Warning: Unrecognized Baud Rate"
Keywords: MS-DOS Kermit

I use MS-DOS Kermit for the IBM PC (actually I have a Compaq, but they
seem interchangeable).  I have one minor problem.  When I start up
Kermit I always get the message "?Warning: Unrecognized Baud Rate"
even though my init file clearly specifies 1200 bps.  (It works
fine--the message seems to have no significance, it's just annoying.)
What causes this?

    Douglas Edwards
    (edwards@su-csli)

[Ed. - When it starts up, MS-DOS Kermit looks at the baud rate the
  serial port is set to and tries to identify it (so that the status
  command will print the correct value if the baud rate isn't
  explicitly set).  If it can't figure out the baud rate, the message
  is printed.  This has nothing to do with what's in your init file -
  it is printed even before the init file is read.  The message won't
  affect anything else; it should probably be removed. ]

------------------------------

Date: Sun, 4 Aug 85 15:08:17 pdt
From: "Corwin Nichols; Community Data Processing; 415-322-9069" <cdp!corwin@Glacier>
Subject:  sliding windows on micros should work
Keywords: Sliding Windows Kermit

In a July 27 note, B.Eiben writes:

>As is probably known, none of our current 'Van Neuman' machines can handle
>more than one task at any given instant of time.  The illusion of
>'time-sharing' and 'multi-tasking' or even 'multi-processing' are only
>possible with the existence of a sophisticated interrupt-structure
>[typically combined with 'hardware assisted' context-switching] and software
>delivering the book-keeping services.

>The currently most 'popular' micro-systems [CP/M and MSDOS or derivatives]
>are SINGLE-tasking systems.  Although the used micro-processors typically
>support a basic interrupt-structure, the lack of buffered and hardware
>assisted I/O devices limits the interrupt-structure basically to ERROR
>intercepts and clock-service.  -- Or in laymans terms, "A typical micro
>CANNOT accept characters on the Input-port, as long as its reading or
>writing to the floppy".

It is true that the current crop of popular micros run MSDOS, CP/M, or
AppleDos, and that these are singletasking operating systems.  However
it is NOT necessary to have a "sophisticated interrupt-structure" or
fancy hardware in order to process a single stream of incoming characters
while performing other tasks such as monitoring the incoming stream,
calculating checksums, transmitting ACKs, etc.  All that is required is
a simple interrupt routine which captures the incoming stream in a buffer,
and which is enabled throughout disk i/o operations.

All machines which claim to be close to IBM PC compatibility meet this
simple criteria.  Many CP/M machines also meet these requirements, ei
Radio Shack models 2, 4, 12, and 16; all Compupros, Altos's, Cromemcos and
any other machine which uses a dma chip for disk i/o and has a serial
chip that is on an interrupt line.

Since most of the CP/M and MSDOS implementations are already machine dependent,
I don't foresee any major problems implementing the sliding window code
on most of the popular micros.

------------------------------

Date: Fri, 2 Aug 85 20:18:22 pdt
From: hpl-opus![e-mail]
    hplabs![e-mail], hplabs![e-mail]
Subject: ANY-duplex Windows
Keywords: Sliding Windows Kermit, Long Packets

I agree with Leslie et al, that they have a viable, apparently
well thought-out proposal for full-duplex sliding windows.

Where we differ is in whether half-duplex windows
belong to Sliding Windows or to Long Packets.  They argue that
the various half-duplex proposals all filter down to long,
segmented packets.  At the link level (what passes down the
wires, and how to synchronize it) this is true.

But NOT AT THE PACKET LEVEL, where most of the programming
is involved.  The major part of the implementation of full-duplex
windows is in the handling of a window of "active" packets
(except when the opsys doesn't support multi-processing).
At the packet level, the handling of half-duplex windows is
nearly the same, as Leslie agrees:

    1. Ken Poulton's suggestion of a way to do "super-packet" half-duplex
    (message dated July 27).  This is a effectively a super-packet with
    segmentation.  ********************************************
    ************* Hugh agrees with Ken Poulton that the coding on this
    suggestion would parallel well with the full-duplex coding.
    ***********************************************************


PROPOSAL: Have the full-duplex windows allow for half-duplex
operation.  All implementations with full-duplex
windows should be able to run in half-duplex mode also, so that
we don't end up with two (probably incompatible) versions of
windows/long-packets running around.

I don't think this requires adding much to a full-duplex window scheme.
To repeat from my earlier proposal:

     All the full-duplex version needs to do is:
    1) negotiate half-duplex status and super-packet size along
        with window size
    2) bunch outgoing packets together (without end-of-lines)
        to form a super-packet
    3) wait for the replying super-packet before sending the next.

My immediate concern is with point (1): unless this negotiation
is added to the full-duplex windows NOW, it never will.
But once that part is defined, the implementation is easy.

In fact, it might be a positive benefit for future full-duplex
implementations: one could bring up half-duplex windows
first to debug the window algorithm and worry about the low-level
interrupt/process handling stuff later.  (Half-duplex windows
have got to be easier to debug than full-duplex...)

Adding a half-duplex option to sliding windows also makes them
more portable: half-duplex windows might still work across
operating system revs or different hardware (e.g., PC-almost-clones)
when a full-duplex implementation (that munged the interrupt
vector, or whatever) broke.

To argue by the numbers:

    1) half-duplex windows are a SIMPLE extension of
    the proposed full-duplex window proposal

    2) half-duplex windows ADD portability and robustness,
    even for full-duplex machines

    3) The only critical need *right now* is to *define* the
    bits and bytes for negotiating half-duplex windows
    and add that part of the negotiation to the
    full-duplex window specification.  In the interests of
    allowing Leslie, et al to move along, implementation
    can wait.

If full-duplex windows go ahead without a half-duplex provision,
it seems likely that we will eventually agree to a separate segmented
long packet proposal, which may go the way of File Attribute Packets.
(Almost no one has implemented these because there is almost no
one else to exchange them with.)  Momentum is key here!


Leslie & co have made a large contribution here, and I thank
them for that.  I agree that this window proposal is indeed a
critical moment for Kermit.  We *all* benefit by making it
useful to more machines.

After all, isn't that what Kermit is all about?

Ken Poulton
hplabs!poulton

------------------------------

Date: Wed 7 Aug 85 03:20:06-EDT
From: Ken Rossman <[e-mail]>
Subject: Kermit directories/files have moved
Keywords: Kermit DIR

Due to space shortages on our PS structure, all Kermit directories and
files have been moved to the PX/PB structure.  All system-wide logical
names have been correspondingly redirected, so if you use the system-wide
logicals for all file references, you should not notice any difference.

Mail questions and/or problems to info-kermit@CU20B.

------------------------------

Date: 7 Aug 85 18:11:49 EDT
From: BL02@CMU-CC-TC
Subject: how do you edit pc-ix sources?
Keywords: Editor

Help!
    I have a pc-xt running pc-ix.  I can't live with INed (the editor)
anymore.  Since ckermit is a rather large program, and it has been
made to run under pc-ix, I gather someone out there has a nice editor
that runs under same.  Can someone give me a pointer to where I can
get one?  I really am looking for an emacs clone (thief, fine, jove, etc.)
or even real emacs, etc., etc., etc.  I do have some sources to thief
and jove, but not for pc-ix, and I just don't have the time right now
to fix them up.

Can anyone help me??  or am I just stuck with INed?  Thanks SO MUCH for
any replies or comments.

        Bryan Lally
        bl02@cmcctc
------------------------------

Date: Tue, 6 Aug 85 11:59:46 PDT
From: [e-mail]
    [e-mail]
Subject: Half-duplex windowing and large packets
Keywords: Long Packets, Sliding Windows Kermit

I'd like to make a proposal which essentially adds some details
to Ken Poulton's proposal for half-duplex sliding windows with
super-packets (Info-Kermit #11).  Extend the protocol to
negotiate both the maximum window size and the super-packet size,
using the byte following the window size for the super-packet
size.  Now, if the super-packet size is 0 or 1 (treat 0 as
equivalent to 1), then we have full-duplex windowing as in the
Source's proposal.  If the super-packet size is the same as the
window size, then we have half-duplex windowing.  If somewhere in
between, then we have full-duplex windowing using super-packets.
Note that if window size is super-packet size times 2, then
although we strictly have full-duplex windowing, we can consider
it to be half-duplex with type-ahead.  I believe that will work
on a few half-duplex systems.  It will certainly work on my MTS
system.  In this proposal the window size in terms of number of
super-packets outstanding at once is (window size)/(super-packet
size).

Keep the rule in the original windowing proposal that explicit
ACKs and NAKs are required for each packet.  Note that implicit
ACKing must be disabled if the environment is full-duplex,
because you really don't know if the missing packet is an ACK or
a NAK (you could change it to implicit NAKing).  The other rule
that differs between half- and full-duplex environments is that
in a half-duplex environment one should do something with a
packet with a bad checksum - sender treats it as a NAK and
receiver sends a NAK.  That prevents having to wait for a timeout
every time a packet gets mangled.  As the windowing proposal
correctly states, in a full-duplex envorinment one must simply
ignore packets with a bad checksum.  That is because one cannot
guess the correct packet number as one can in the half-duplex
environment.

I'd also like to propose one more extension to save money on
public data networks.  Many of those networks charge by the
packet and packet sizes are typically up to 128 or 256 bytes.
I'd like to extend the packet length field to 2 bytes when the
first length byte (decoded) is 1 or 2.  That will allow packet
sizes from the current minimum up to 284 with no loss of
efficiency on short packets.  It will allow a super-packet of
26696 (284*94) bytes which seems more than long enough.  Two more
bytes are needed in the Init packet to negotiate the maximum
packet size just as in the original long packet proposal.

Note that I haven't used packet size 0 so this doesn't conflict
with the large packet proposal.  However, I'd like to see this
proposal supercede that one because it is superior in several
respects.  It allows ACKing and NAKing parts of large packets and
it fits in with the windowing proposal.

Now, this idea complicates the negotiation process a bit, because
if one side wants to be half-duplex and the other side doesn't
care, the negotiation must be sure to end up in a half-duplex
state.  I believe the following rules will work: 1.  Use the
minimum value of window size (or smaller, see 3).  2.  Be
half-duplex (super-packet size equal to window size) if either
side requests that.  3.  Make super-packet size divide (no
remainder) window size and make super- packet size be such that
the resulting quotient is the minimum of the two quotients
requested, by adjusting the window size downward if necessary.

The biggest drawback to this proposal is that it doesn't allow
very large packets when one really wants a window size of 31
(since in that case one cannot use super-packets).  Nonetheless,
the 284 byte maximum packet size in that case seems sufficient.

I'm a bit out of touch for the next week and have been for a few
days so this proposal may not take into account everything it
should and I won't be able to respond until next week.

------------------------------

Date: Mon, 5 Aug 85 14:19:56 pdt
From: seismo!decvax!ucbvax!ucdavis!deneb![e-mail] (Michael Shulman)
Subject: RT-11/TSX+ Kermit
Keywords: RT-11 Kermit

We understand that there is a version of Kermit available
for the TSX+ system.  It is far easier for us to obtain a
copy of this system on 8" disk than it would be to bootstrap
it ourselves.  Are there any sites that have such a system
running and would be willing to make us a copy on 8" disk?

Thank you,

Michael Shulman
Computer Center
UCDavis ... ucbvax!ucdavis!deneb!ccrms


------------------------------

Date: Thu, 8 Aug 85 03:29:24 pdt
From: Neal Holtz <[e-mail]>
Subject: CKermit Statistics
Keywords: C-Kermit

A statistic regarding performance of C-Kermit:

       source:  Vax 11/750 4.2 BSD
       dest:    Apollo DN320, Aegis SR8
       line:    9600 baud
       type:    text
       # files: 53
       # chars: 684206
       time:    29 min. (+/- 1 min.)
       effective rate:  393 chars/sec

Notes:
1) Apollo versions:
    C-Kermit 4.2(030) PRERELEASE # 2, 5 March 85
    C-Kermit Protocol Module 4.2(015), 5 Mar 85
    C-Kermit functions, 4.2(026) 5 Mar 85
    Unix cmd package V1.0(015) 27 Feb 85
    User Interface V4.2(038), 5 Mar 85
    Apollo Aegis tty I/O, 4C(023), 20 May 85 for Apollo Aegis SR8
    Aegis file support, 4C(024) 20 May 85 for Apollo Aegis SR8
    Connect Command for Unix, V4.2(006) 5 March 85
2) Vax versions:
    C-Kermit 4.2(030) PRERELEASE # 2, 5 March 85
    C-Kermit Protocol Module 4.2(015), 5 Mar 85
    C-Kermit functions, 4.2(026) 5 Mar 85
    Unix cmd package V1.0(015) 27 Feb 85
    User Interface V4.2(038), 5 Mar 85
    Unix tty I/O, 4.2(016), 5 Mar 85 for 4.2 BSD
    Unix file support, 4.1(015) 28 Feb 85 for 4.x BSD
    Connect Command for Unix, V4.2(006) 5 March 85
3) All compiler optimizing turned off on Apollo
4) Used about 25% of CPU on Vax
5) Used about 70% of CPU on Apollo

------------------------------

Date:     Fri, 9 Aug 85 9:46:06 EDT
From:     David Roth (Ft. Benj. Harrison) <[e-mail]>
Subject:  Wanted: Kermit for the Burroughs B-20s,B-25s,B-26s running BTOS.
Keywords: Burroughs B2x, BTOS

This Sept.15 we are expecting shipment to arrive of dozens of Burroughs B-20s,
B-25s & B-26s. The operating system they run is called BTOS. We are in need
of a version of KERMIT for these systems. Anyone have a version or enough
experience in using BTOS to suggest what existing version of KERMIT we
should start with.
The Army refers to these systems as: TACCS.
Thanks in advance.
                                David A. Roth
                                droth@brl-bmd
                        US Mail:
                                COMMANDER
                                USA Soldier Support Center
                                ATSG-DTU-S
                                Attn: Mr. David A. Roth
                                Fort Benjamin Harrison, IN
                                                46216-5590
                        AUTOVON:699-4298
                        FTS:335-4298
                        COMMERCIAL:[phone]
------------------------------

End of Info-Kermit Digest
*************************
-------
-------
30-Aug-85 18:31:41-EDT,21691;000000000001
Mail-From: US.JD created at 30-Aug-85 18:31:00
Date: Fri 30 Aug 85 18:31:00-EDT
From: Jeff Damens <[e-mail]>
Subject: Info-Kermit Digest V3 #14
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 30 Aug 1985       Volume 3 : Number 14

Departments:

  UNIX KERMIT -
    Bug (?) in C-Kermit 4C


  MS-DOS KERMIT -
    Concurrent DOS KERMIT


  CMS/TSO KERMIT -
    CMS Kermit Improvements?
    KERMIT-TSO and 7171 (2 messages)
    CMS KERMIT and Yale 2.0 (2 messages)


  MISCELLANY -
    More on sliding windows
    Kermit for the PRO
    Getting K11 on floppies
    6809 Kermit
    BTOS Kermit
    Kermit for TI 99/4A
    CompuPro KERMIT version wanted to work with Hayes Micromodem.
    CROSS and other queries
    Prime Kermit
    Plea for help
    Kermit/milnet
    Kermit over TELENET: Help Needed
    Kermit for Fortune 32:16
    Kermit on VMS


----------------------------------------------------------------------

Date: 9 Aug 1985 1612-EDT
From: B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO.ARPA>
Subject: More "sliding WINDOWS"
Keywords: Sliding Windows Kermit, Long Packets

The gist for micro's lays NOT in the fact, that they have [or haven't] an
interrupt-structure [infact having none is cleaner then having "something"].

The PROBLEM typically is the "floppy-controler" i.e FD17xx , which delivers
data "fast" enough , so that one has to TURN OFF interrupts during READ/WRITE
but SLOW enough to lead easily to character-loss during floppy-processing.

The typical coding sequence [very innocent] looks like
    DI
    Call Write/Read Sector
    EI
... that alone makes "sliding WINDOWS" impossible - since one eventually HAS
to write the stuff to the disk - and there's NO TRICK to stop the SENDER from
sending - except for "holding back ACKs" - and that takes away most of the
advertised speed-improvements.

Obviously the "sector-time" window is dependant on the media-speed [floppies
will be LOOSERs compared to winnies] and the amount of 'character lossage'
depends on the channel-speed [ at 1200 baud one might loose NOTHING , since
the window is about one char-time, and thats hanging around in the USART ...
at higher speeds it'll be one or more lost char's - i.e. a full NAK/resend
packet cycle ] - so as seen from the "innocent bystander" we now have
introduced a feature , which might "work for me" but "not for You" - i.e.
the same MICRO connected to the same Mainframe will "win" or "fail" depending
on storage medium and/or channel-speed == in my mind NOT A GOOD IDEA .

Rgds,
Bernie.
------------------------------

Date: Wed 7 Aug 85 17:58:06-PDT
From: Wing Lee <WingLee%ECLD@ECLA>
Subject: KERMIT-TSO and 7171
Keywords: TSO Kermit, 7171 Protocol Converters

I hate to keep on bugging you about KERMIT-TSO and the 7171, but
my boss keeps on asking me if there is any news.

This is our situation.  We installed the Series/1 version of KERMIT-TSO
on our 3081, in March of 1985.  Everything worked fine, and everybody
was happy.  In May, we replaced our Series/1 with an IBM 7171, so
that we could have more lines going into TSO.  That's when our
problems started.  Going through the 7171, we were able to
download but not upload.  When we tried to upload, the file transfer would
hang at random places.  When I used DEBUG mode to look at the packets,
I saw that the tranfer would always stop right after a file transfer.
As soon as I discovered this, I sent a message to Columbia asking for
help.

In the meantime, we have put together a makeshift way to get KERMIT-TSO
to work.  On our 3081, we run both MVS/TSO and VM/CMS.  Our ascii interface
to TSO is an IBM 7171, our ascii interface to CMS is a SERIES/1.  We
have been able to have users who wish to do file transfer to TSO, to
use the CMS Series/1.  Then they would DIAL MVSA and connect to
our MVS system.

That works. But now our Systems people are thinking of replacing the CMS
Series/1 with another 7171.  When we told them that this would disable
are ability to use KERMIT altogether, they said that our TSO KERMIT is
not supported by Columbia, and we should not be using TSO Kermit on our
TSO system until Columbia has a supported version.  Thus we should not
even have the package on our system.

My question is, does Columbia support the Series/1 version of KERMIT-TSO?

[Ed. - No.  We don't run TSO.]

wing
------------------------------

Date: Wed 7 Aug 85 19:10:07-PDT
From: Wing Lee <WingLee%ECLD@ECLA>
Subject: kermit-tso and 7171
Keywords: TSO Kermit, 7171 Protocol Converters

in my last message i said, that when uploading, the transfer stops
right after a file transfer.  i meant that the transfer stops right after
a bad packet.  i should have reread my message more carefully before
i sent it out.

wing

------------------------------

From: Gary Mills <[e-mail]>
Subject: 6809 Kermit
Keywords: 6809 Kermit

Does anyone have a version of Kermit for the 6809 CPU, with Flex-9 or OS/9
operating systems?  C or assembler languages would be suitable.


------------------------------

Date:     Sat, 10 Aug 85 13:04 EST
From:     Larry Afrin <[e-mail]>
Subject:  Bug (?) in C-Kermit 4C
Keywords: C-Kermit

Hi,

    I just got the latest version of 4C a few days ago (the one
the Digest swore would be the "absolute last" release of 4C).  I compiled
it for a System V system, and the problem I noticed occurred when I
was "get"ting some stuff from SIMTEL20.  The files on SIMTEL that I was
transferring had names like ABCDEF. and GHIJKLMN.  (the point here being
that they're all upper-case, as you would expect from a TOPS-20 system).
I wanted to transfer them to my UNIX system and give them the same,
upper-case filenames, just without the dot.  I knew that if I told my
local Kermit "get ABCDEF." or "get ABCDEF", it was going to do some
funky translation of the name (for what reasons, I don't know; I just
remember seeing somewhere that Kermit adjusts filenames for the
"conventions" of your system, which in UNIX usually means all lower-case),
which isn't what I wanted.  So I figured I would just type in "get" and
let it prompt me for the remote filespec and the local filespec.  For
the remote filespec I entered "ABCDEF.", and for the local filespec I
entered "ABCDEF".  The transfer then started up ... "IRSF" and wham! my
local Kermit told me "ABCDEF. => abcdef", which wasn't what I wanted.

    My whole point here is, if Kermit goes to the trouble of asking
you exactly what you want your local filespec to be, shouldn't it
refrain from translating that name (in this case from uppercase to
lowercase)?  In fact, why can't the "get" command be set up so that
(1) if you don't give a command line filespec and it goes ahead and prompts
you, it shouldn't translate either the remote or local filespecs; and (2)
if you do give a command line filespec, it should be interpreted as the
*exact* filespec for the local system, but it should be "appropriately"
translated to make the remote Kermit happy.

    I'm not 100% sure that (2) is "right", but I do feel that (1) is
right.

    Oh, yeah, one more thing:  Also during this transfer operation with
SIMTEL20, I tried this command: "get *.c".  Assuming my SIMTEL filenames
matching this spec were ABC.C, DEF.C, GHI.C, and JKL.C, this is what my
local Kermit reported to me during the transfer:

        ABC.C => *.c
        DEF.C => def.c
        GHI.C => ghi.c
        JKL.C => jkl.c

and yes, sure enough, my local Kermit really did create a filename called
"*.c".  Now, is this a bug, or did I just specify my "get" command
incorrectly?

    Thanks for any info, advice, etc., you can provide.

                    -- Larry Afrin
                       Dept. of Computer Science
                       Clemson University

Please send replies, if any, to:
lbafrin@clemson                         if you're on CSNet
lbafrin.clemson@csnet-Relay             if you're on ARPANet

------------------------------

Date: Mon 12 Aug 85 09:15:36-EDT
From: Bill Catchings <[e-mail]>
Subject: BTOS Kermit
Keywords: Burroughs B2x Kermit, BTOS

The best version of Kermit to work with for the Burroughs BTOS is probably
C Kermit.  I do not know for a fact that Burroughs supplies C for BTOS, but
Convergent Technologies (the maker of the B-20 series) supplies a C for CTOS
(The "parent" of BTOS).  My knowledge of BTOS is limited, but I believe that
CTOS and BTOS are pretty close.  The C for CTOS is pretty poor, based on
Mark Williams C, and the terminal/file transfer product that CT supplies is
terrible.  After 40 screens it starts over at the first screen.  Very annoying.
I plan to be working on a CTOS version of C Kermit in the next few weeks.  If
I succeed in getting one working it will be announced on Info-Kermit.  If not
you'll have to try yourself.

                    -Bill Catchings

------------------------------


Date: Tue, 06 Aug 85 19:58:34 EDT
From: Peter DiCamillo  <[e-mail]>
Subject: CMS Kermit Improvements?

The latest version of CMS Kermit includes features which make it very
attractive to users at Brown. These include support for Series/1
connections, binary data transfer, and server mode. As a result,
the Computer Center plans to recommend Kermit as the standard file
transfer program between CMS and  IBM PCs, Macintoshes, and other micros.
In evaluating CMS Kermit, we noticed that, as documented, server mode
only supports GET, SEND, FINISH, and BYE. This is very obvious to
the Macintosh user who has a menu of server commands, most of which
are not supported by CMS Kermit. Also, it would be useful to us if
CMS Kermit could preserve the date and time of files whenever possible.
Is any work planned or in progress to add these features? If not, I
may attempt to add them myself.

[Ed. - Kermit allows you to create the file on the destination
       computer with the same write date and time as on the source
       computer.  This requires however supporting attribute packet.
       At this time, CMS Kermit does not support attribute packets
       although it may do so in the future.  If you'd like to add the
       support, let us know so there won't be a duplication of effort
       on the part of some other ambitious soul. ]


------------------------------

Date: 14 Aug 1985 23:45-EST
From: Sanjay Kapur <[e-mail]>
Subject: kermit for the pro
Keywords: DEC PRO300 Kermit

Is there a version of kermit available for the DEC PRO350 running
the Professional Operating System? Where can I get a copy of it?


[Ed. - yes.  It's the k11 version, available on the distribution tape
       or in numerous other ways (see following message).]

------------------------------

Date: 10 AUG 85 12:04-EST
From:  [e-mail]
Subject: GETTING K11 ON FLOPPIES
Keywords: Kermit-11

In Response to Kermit Digest re RX0x dist.


Getting K11 on various media

K11AAA.AAA     Updated 14-JUN-1985 09:22  Brian Nelson


Kermit-11 Edit history:  K11CMD.MAC
Kermit-11 Installation:  K11INS.DOC
Kermit-11 Documentation: K11HLP.HLP  (no separate user manual)
Kermit-11 Files:         K11FIL.DOC



Please note that while Kermit-11 uses RMS11 for all versions (RT11 excluded)
you do not need RMS on your system unless you opt to use the versions linked
to RMSRES (K11.TSK for RSTS/E and K11POS.TSK for M/M+ and P/OS).
For further information, please read K11INS.DOC



To get Kermit-11 and all the other Kermits:

  KERMIT Distribution
  Columbia University Center for Computing Activities
  7th Floor, Watson Laboratory
  612 West 115th Street
  New York, N.Y.  10025


There is also a fairly current copy of Kermit-11 available  from  DECUS,
order  number  11-731.  As  of June 1985 the DECUS library has Kermit-11
available on RX01's and RX50's (in RT and  P/OS  format).  Additionally,
the SIG tapes almost always have a current version on them.


To get Kermit-11 from the author:


Mail:

800bpi          DOS-11 format
1600 bpi tape   DOS-11, ANSI or VMS Backup
RX01            RT format, binaries only
RX50            RT or P/OS (readable on Micro/RSX), delays are possible
                since I have only one PRO/350 and one hard disk.

For tapes,  VMS Backup format is preferred (default if not specified).
For RSTS/E, V9 Backup format is preferred. V9 backup is NOT compatible
with previous releases of RSTS/E, but IS compatible with VMS backup.

You must supply the media (extras are nice to offset the cost).


Brian Nelson
Computer Services
University of Toledo
2801 West Bancroft
Toledo, Oh 43606
[phone]   or   [e-mail]


Bitnet:

from VM/CMS:    CP SMSG RSCS MSG UOFT02 KERMSRV DIR
                CP SMSG RSCS MSG UOFT02 KERMSRV SEND K11*.*

from VMS Jnet:  $ SEN/REM UOFT02 KERMSRV SEND K11*.*


 Columbia University maintains a BITNET Kermit server also,
username KERMSRV node CUVMA.  Command format is similiar to
the VMS KERMSRV on node UOFT01.

Dialup:

        [phone]
        Service class  VX785A
        User: KERMIT
        Password: KERMIT

Source and hex files are in KER:, binaries are in KERBIN:

------------------------------

Date: Mon 19 Aug 85 05:33:45-PDT
From: [e-mail]
Subject: Kermit for TI 99/4A
Keywords: TI 99/4A Kermit

Gentlemen

    I  am  trying  to  locate  a  version  of  Kermit  for  the  Texas
Instruments 99/4A Home Computer.  I have been informed that one exists
or  is  currently  under  implementation.   I  would  appreciate   any
information that you may have regarding Kermit for the TI 99/4A.

Anthony Gargaro.

------------------------------
Date: Mon, 19 Aug 85 12:23:44 EDT
From: David Roth (Ft. Benj. Harrison) <[e-mail]>
Subject: CompuPro KERMIT version wanted to work with Hayes Micromodem.
Keywords: CompuPro Kermit, Hayes Modem

We need help on getting a version of KERMIT for the CompuPro running
CP/M 2.2LD to work with a Hayes Micromodem 100 using the microcoupler.
We have the source to KER:CPMPRO.M80 from Columbia University but it is
for use with Compupro Interfacer 3/4.
Thanks in advance.
                                David A. Roth
                                droth@brl-bmd
                        US Mail:
                                COMMANDER
                                USA Soldier Support Center
                                ATSG-DTU-S
                                Attn: Mr. David A. Roth
                                Fort Benjamin Harrison, IN
                                                46216-5590
                        AUTOVON:699-4298
                        FTS:335-4298
                        COMMERCIAL:[phone]

------------------------------

Date: Mon, 19 Aug 85 13:44:28 edt
From: jax-lab!jng (John N Guidi)
Subject: Concurrent DOS KERMIT
Keywords: MS-DOS Kermit, Concurrent Kermit

I would like to run KERMIT on a Concurrent DOS, IBM PC/AT system.
Is there a separate Concurrent DOS distribution? If not, can one
use the PC-DOS KERMIT while running Concurrent DOS? If this is the
case, are there any caveates to keep in mind?
Thanks.

John Guidi
The Computing Service
The Jackson Laboratory
Bar Harbor, ME  04609
phone: [phone]
uucp:  ...!decvax!unh!jaxlab!jng
bitnet: jaxlab@maine

------------------------------

Date: Friday, 16 August 1985  15:51-MDT
From: [e-mail]
Subject: CROSS and other queries
Keywords: CROSS Assembler

NetLandians,

Could someone please point me to the documentation/instructions for
CROSS - the cross assembler available on some TOPS-20 hosts, and used
extensively for KERMIT applications.

[Ed. - Take a look in psb:<micros>cross.* on Cu20B.]

Second:  Is CROSS proprietary or public domain?

[Ed. -  I think it's public domain.]

Third:  What happened to CU20B as a host?  The KERMIT archives are out there
(Columbia University), and I saw the msg they were moving the archives to
another disk... but when trying to FTP to CU20B, I get an unknown host error.
Can anyone point me right?

[Ed. - Cu20b underwent some disk reshuffling, but it should be back online
       now. ]

Thanks in advance,
David Kirschbaum
Toad Hall

------------------------------

Date: Tue, 20 Aug 85 07:53 PDT
From: "Chase Lila"@LLL-MFE.ARPA
Subject: Prime Kermit
Keywords: Prime Kermit

Can the Prime Kermit transfer binary files?       [e-mail]

------------------------------

From: [e-mail] (Larry Bierma)
Date: 20 August 1985 0953-PDT (Tuesday)
Subject: CMS KERMIT and Yale 2.0
Keywords: VM/CMS Kermit, Yale ASCII Communications Program

Is CMS KERMIT supposed to work through a Series/1 running version 2.0
of the Yale software?  Whenever we start the server it hangs up the
line.  Everything works fine in line mode through a 3704, and in page
mode through a 7171, it's just the series/1 that hangs up.

[Ed. - We use CMS Kermit through a Series/1 running the version 2.0 of
       the Yale Ascii code and version 3.2 of EDX all the time without
       any problems.  The way this works is Kermit puts the S/1 into
       transparent mode.  It sounds like you don't have the most
       up-to-date software for the S/1. ]


--Larry        ARPA: [e-mail]
        UUCP: {decvax,ucbvax,ihnp4}!sdcsvax!sdcsla!nprdc!bierma
        PSTN: [phone]

------------------------------

Date: Tue 20 Aug 85 15:34:52-CDT
From: [e-mail]
Subject: plea for help
Keywords: VAX/VMS Kermit, HP1000 Kermit

Hi

I am trying to find a way to connect my Vax (VMS 4.1) to our HP
1000 running the RTE-A operating system.  Is there a Kermit out
there for this OS.  I looked and found the one for a previous
HP1000 operating system (RT6/vm or some such moniker)

Please respond to [e-mail], as I am not on the
INFO-KERMIT discussion.

Steve Kneuper
Lockheed Austin Division
[phone]

------------------------------

Date: 14 Aug 1985 1541-PST
From: Contr36 <CONTR36 at NOSC-TECR>
Subject: kermit/milnet
Keywords: C-Kermit, MILNET

from: Paul Attermeier
      Sandia National Labs
      Albuquerque, NM
      [phone]

I am trying to transfer some files from a VAX at the Naval Ocean
Systems Center back to my machine using Kermit. I have had no success
so far and the problem seems to lie somewhere in the MILNET
connection.

I'm running Kermit on a VAX/780 under Ultrix.  (The header reads
'C-Kermit 4.2 (030) Prerelease #2, 5 March 85, 4.2 BSD).  I've been
able to transfer files from another local 780 running VMS and a
version of Kermit (VMS Kermit-32 version 3.0.052) that appears to be
older than the one on the NOSC machine, (VMS Kermit-32 version
3.1.062) so I don't think there is a Kermit version incompatibility
problem.

Whenever I try a Kermit file transfer across MILNET, it just tries
for a minute or two and then times out. Do you know of any Kermit
or MILNET parameters which need to be changed from their defaults?

------------------------------

Date:     Fri, 23 Aug 85 09:57 EST
From:     Larry Afrin <[e-mail]>
Subject:  Kermit over TELENET: Help Needed
Keywords: TELENET

Fellow Frog Lovers,

    I would like to use Kermit for file transfer between my IBM PC and an
NCR Tower running System V UNIX.  Both machines are running the latest
versions of Kermit available for them.  The only problem is that GTE TELENET
is in the middle.  (From the PC's Kermit I dial TELENET's local number and
then give the connect code (host address) by which TELENET knows the Tower.)
Something with TELENET is preventing file transfer from working (the
initialization packets don't even make it through).  Does anyone out there
have either (1) a proven method for using Kermit over TELENET or (2) an
explanation of why such may be impossible?  Any help, advice, pointers, etc.
would be greatly appreciated.  Thanks in advance...

                    -- Larry Afrin
                       Dept. of Computer Science
                       Clemson University

Please send replies, if any, to:
lbafrin@clemson                         if you're on CSNet
lbafrin.clemson@csnet-Relay             if you're on ARPANet

------------------------------

Date: Wednesday, 21 August 1985  08:59-MDT
From: Steve Westfall <ihnp4!gargoyle!sphinx![e-mail]>
Subject:   Kermit for Fortune 32:16
Keywords: Fortune 32:16 Kermit

The Bulletin of the Atomic Scientists at the University of Chicago has
a Fortune 32:16 computer.  The system administrator has had problems
getting kermit to work with his Fortune and would like to get in touch
with anyone who has helpful information about this.  Please get in
touch with the following person, not me:

            Barry Bowen
            Bulletin of the Atomic Scientists
            5801 S. Kenwood
            Chicago, Illinois 60637
            312-363-5225
            UUCP:  ...ihnp4!gargoyle!xeno

Thanks.


Steve Westfall                Uucp:  ihnp4!gargoyle!sphinx!west
Senior Staff Analyst          Bitnet:  [e-mail]
U. of Chicago Computation Center  Mailnet: [e-mail]

------------------------------

Date: 22 Aug 1985 12:32-EDT
Subject: kermit on vms
From: [e-mail]
Keywords: VAX/VMS Kermit, C-Kermit

     I am trying to connect a VAX/VMS system to a VAX/UNIX 4.2 system
using KERMIT.  The UNIX side is running version 4C (CK*) and the VMS
side is running the MACRO version (VMS*.MAR).  The link is made up of
ports of DMF32s on both machines.  If someone else has tried this before,
I need to talk to them because I may not have set up the VMS environment
correctly.  From the UNIX side I can CONNECT to VMS just like a terminal
with no problems.  On the VMS side though, when I CONNECT to UNIX,
I have a problem with data overrunning buffers, as though there were no
flow control.  Any help would be appreciated.

  Joe Zakar
Zakar at USC-ISI

------------------------------

End of Info-Kermit Digest
*************************

-------
 5-Sep-85 18:44:47-EDT,21422;000000000001
Mail-From: SY.FDC created at  5-Sep-85 18:44:24
Date: Thu 5 Sep 85 18:44:24-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #15
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu,  5 Sep 1985       Volume 3 : Number 15

Departments:

  SLIDING WINDOWS -
    Sliding Windows Work on Fast Line with Slow Disk
    Re: ANY-duplex Windows (2 messages)

  MS-DOS KERMIT -
    POPDOS2 and Kermit Problem
    Problem with MS kermit on DEC Rainbow 100+
    Leading Edge & Corona Portable -- Kermit Fit?
    Kermit for the Hyperion?

  IBM MAINFRAME KERMIT -
    Solution to TSO Kermit vs 7171 Problem
    Kermit with Yale ASCII?

----------------------------------------------------------------------

Date: Thu 22 Aug 85 15:42:46-EDT
From: John Mulligan <[e-mail]>
Subject: Sliding Windows Work on Fast Line with Slow Disk
Keywords: Sliding Windows Kermit

Frank - I tried the windowing direct connect at 9600 baud with a standard
IBM PC (Floppies) and had no problems.

------------------------------

Date: Thu 22 Aug 85 15:46:43-EDT
From: John Mulligan <[e-mail]>
Subject: Re: ANY-duplex Windows
Keywords: Sliding Windows Kermit, Long Packets

Dear Ken,

   I would like to thank you for your messages on the windowing proposal.
They were well thought out and written, and helped us a great deal in
refining the proposal.  I have been meaning to reply before, but I was
still learning the mail system on Columbia.  Frank was the only one I
knew how to send messages to!

   Anyway, we have been thinking about the half-duplex situation.  I'm
sending our current thoughts to you before we go public with them.

   First, the Send-Init packet.  Define an additional bit in the capabilities
mask indicating half-duplex windowing:

   Bit        1     2     3     4     5
             reserved  ATTRIB  FULL  HALF

  Do a bitwise "AND" of the sender pair with the receiver pair.

  Full  Half
  0     0       Kermit Classic
  1     0       Full-duplex as defined now
  0     1       Half-duplex extension to be elaborated
  1     1       Either full or half *
                 *If both, default to half; shouldn't happen because
                  second send-init should pick one.

Second, half-duplex itself:

   Create a new data packet type that says "this data packet is not the
   last in this group; don't answer yet".  Thus the current standard
   DATA packet can be answered right away, and our current full-duplex
   definition is consistent.

   I'm suggesting the new packet type be called the WATA packet, and it
   would be just like a DATA packet except that it would mean
   "WAiT A minute, I'm not done sending this group, don't reply yet".

   A DATA packet (as in "DAT's All for this group, go ahead and reply")
   would signal the end of a particular group of packets.

   The above definition is consistent with both classic KERMIT and with
   the full-duplex windowing.

   As the receiver processed WATA packets, it would compose the ACKs and
   NAKs in the same manner as for full-duplex windowing, but buffer
   them for sending when the half-duplex line was turned around (indicated by
   receipt of a DATA packet).

   This system should use almost identical code for both full and half
   duplex windowing, and would (as you mentioned) make it very
   easy to debug in half-duplex and then move to full-duplex.

   Error handling, window rotation, etc. appear to remain the same,
   at least at first glance.

   We think the maximum half-duplex window size could be 63, instead
   of 32, but we aren't totally sure.

Thanks again for your very helpful thoughts.  Let me know what you think of
the above.
                     -John Mulligan

------------------------------

Date: Mon, 26 Aug 85 23:19:52 pdt
From: hpl-opus![e-mail]
Subject: ANY-Duplex Windows
Keywords: Sliding Windows Kermit, Long Packets

Glad to hear from you, John!

Here are my thoughts:

Repeated for the benfit of others:
>
>    First, the Send-Init packet.  Define an additional bit in the capabilities
>     mask indicating half-duplex windowing:
>
>    Bit        1     2     3     4     5
>              reserved  ATTRIB  FULL  HALF
>
>
>   Do a bitwise "AND" of the sender pair with the receiver pair.
>
>   Full  Half
>   0     0       Kermit Classic
>   1     0       Full-duplex as defined now
>   0     1       Half-duplex extension to be elaborated
>   1     1       Either full or half *
>                  *If both, default to half; shouldn't happen because
>                   second send-init should pick one.

Yes, but I think that "1 1" should default to full duplex.
Both sides are capable, so why not use full-duplex?
(If you want to choose half-duplex with a pair of Kermits
capable of either, "SET WINDOW HALF-DUPLEX" or some such command
should cause only the half-duplex bit to be sent.)


Both sides should also send a super-packet size (S) in the
next byte following the window-size (W) byte.
If half-duplex windows are selected, then the super-packet size
used is the lower of the two super-packet sizes.

Super-packet size must be less than or equal to half the window size
(S <= W/2) :
    1) We must have window size (W) >= 2x super-packet size (S) in case
    the first packet of a super-packet is lost (then the next super packet
    contains packet 1 plus packets S+1 through 2S-1).
    2) We can only make use of W > 2*S in the case of multple retries
    for a particular packet.  (This could be useful in very noisy
    environments...)
The normal case (the program default) should probably be for S = W/2.
Note that S may be more limited by a machine's input buffer size
than by W (=~ memory size).   It might be less than W/2 even for full
duplex machines (i.e., how *long* can a full-duplex machine sustain
a full speed input without any pauses?).

Note that super-packet size is a maximum only.

More repeated stuff:
>
>
> Second, half-duplex itself:
>
>    Create a new data packet type that says "this data packet is not the
>    last in this group; don't answer yet".  Thus the current standard
>    DATA packet can be answered right away, and our current full-duplex
>    definition is consistent.
>
>    I'm suggesting the new packet type be called the WATA packet, and it
>    would be just like a DATA packet except that it would mean
>    "WAiT A minute, I'm not done sending this group, don't reply yet".
>
>    A DATA packet (as in "DAT's All for this group, go ahead and reply")
>    would signal the end of a particular group of packets.
>
>    The above definition is consistent with both classic KERMIT and with
>    the full-duplex windowing.
>
>    As the receiver processed WATA packets, it would compose the ACKs and
>    NAKs in the same manner as for full-duplex windowing, but buffer
>    them for sending when the half-duplex line was turned around (indicated by
>    receipt of a DATA packet).

I'm not convinced that we gain by adding a new packet type.

Note that we cannot send an EOL character to the half-duplex host
between packets, because this causes the host to finish the read
and probably miss the start of the next packet.  On my system,
at least, the system not only can't send while it's receiving,
but, after completing a read, it doesn't buffer until a new
read is issued for the line.
System call overhead ensures that the next read will not be issued
until well after several characters of the next packet have gone
by, even if no processing is done on the packet in the meantime.

(The alternative is XON handshaking between packets, which
will defeat the whole pupose of super-packets.
Note also, that we have not gotten away from XON handshaking
between super-packets.)

This means that when the kermit program on a half-duplex host
gets the packet, an EOL has been received.  EOL is a de-facto
super-packet delimiter.
As soon as the end of the super-packet (the EOL) is processed,
the program knows it can proceed to reply.

If one side is full-duplex, it can queue up ACKs and NAKs as it reads
packets, but it must wait for the EOL (and probably XON) before
sending them.  I suppose that for a full-duplex host,
WATA/DATA is a way of providing the higher-level protocol
with the end of super-packet data which the half-duplex host
gets implicity by the nature of its i/o system.

It seems to me that making the send-packet routine wait for
receiving routine to get an XON is sufficent, although this
hides the super-packets from the packet-level protocol.
Is there a reason to tell it?
If so, perhaps the full-duplex kermit can implement a WATA
packet internally: a DATA packet received without an EOL gets
reported internally as a WATA,
but only DATA packets are actually sent over the wires.

I'm not real strong on this one way or the other;
I'm just wary of adding packet types.

As Bruce Cowan points out, a half-duplex receiver can NAK
bad-checksum packets since it *knows* which packets were supposed
to be sent (including which ones resent).
I'm not sure whether this helps or not, since the absence of an ACK
is just as sure an indication to the sender.  *Something* (at least one
ACK/NAK) does have to be sent, however, to let the sender know
to retransmit.
The best policy is probably to send only ACK's unless no good packets
are received, in which case a NAK for the lowest-numbered outstanding
packet may be sent.
This has the advantage of agreeing with the full-duplex case,
for best commonality of coding.

It seems to me that where super-packets are most vulnerable is if
the EOL (or the XON) is lost.  In that case, my system, at least,
will time out and throw away the whole super-packet!
Some simple kluges will help here: send some padding followed by a
second EOL character *after* each super packet if the padding
parameter is non-zero.

As long as we don't get into a situation where the end of the super-packet
(and the EOL) is lost on every transmission, though, we still gain:
the critical EOL characters are a lower percentage of the
total characters sent.

>    This system should use almost identical code for both full and half
>    duplex windowing, and would (as you mentioned) make it very
>    easy to debug in half-duplex and then move to full-duplex.
>
>    Error handling, window rotation, etc. appear to remain the same,
>    at least at first glance.

I believe so, too.

>    We think the maximum half-duplex window size could be 63, instead
>    of 32, but we aren't totally sure.

I'm not sure that the gain would be worth making it different
from the full-duplex case.  Ease of coding and all...

One thing I have not thought about yet is how to integrate long packets
with windows.  Bruce makes a good case for allowing packets to be
close to 128 or 256 characters to take advantage of public data network
packet sizes.  I lean towards using the published long-packet
extension rather than his proposed special case for up to triple-size
packets, though.
It seems that the easy solution is to state that window and super-packet
negotiations are really for windows of 94*W *characters*;
when using longer packets, you must scale W and S down accordingly.
This is not as flexible as one might wish for, though.

Your turn!

Ken Poulton

Bit by bit, byte by byte, we'll figure it out...

------------------------------

Date: Tue 13 Aug 85 13:45:37-EDT
From: Fuat C. Baran <[e-mail]>
Subject: POPDOS2 and Kermit Problem
Keywords: MS-DOS Kermit, popdos2

I have been testing some of the popups (Bellsoft) recently and I have
found one problem.  The problem occurs when I use Kermit (v2.28) and
popdos2.  Here is what happens:

I install the popup and go into kermit.  Until I use popdos2 (calling
it up with ALT-U) I have no problems.  Then I call popdos2 and do the
following: I cd to a subdirectory and a dir *.* of the subdirectory.
I then exit from popdos2 and continue with Kermit.  I try transferring
more files but later when I look at the files I see that they are all
filled with garbage.  The garbage looks like random characters and,
here and there, file names of the subdirectory that I had done the dir
on.  I tried this several times and with different files and got the
same results.  Kermit works fine until I do the cd and dir sequence in
popdos2.  Any files transferred after that point come out as garbage.

So far that is the only major problem I have encountered with popups.
I minor irritation is the alarm clock feature in continuous display
mode.  Every time the screen scrolls up a line it moves the clock (I
keep the display in the top right hand corner of the screen) up with
it and then it redisplays it where it should be.  (If you put the
clock in some other place, on the bottom for example, then it scrolls
up with the page and you get multiple displays on your screen.)

Note: I have an IBM-PC with 256K and two disk drives.  I use a TAXAN
monochrome display with a Paradise Color Card (yuk!  [The Paradise
card has been giving me problems like substituting characters on my
screen ("S." -> "S*" with the "*" flickering, etc...)])

                                        --Fuat Baran
                                          [e-mail]

------------------------------

Date: Fri, 23 Aug 85 10:38:21 mdt
From: [e-mail] (Richard Thomsen)
Subject: Problem with MS kermit on DEC Rainbow 100+
Keywords: MS-DOS Kermit, DEC Rainbow

I have (am currently) using MSKERMIT on my Rainbow 100+, connecting to a
Berkley 4.2 UNIX system on a VAX.  When I run the Rand Editor under Kermit,
the cursor arrow keys do not work.  When I run the Rand Editor using the
Rainbow built-in terminal emulator, then the arrow keys work.  I suspect
that the Kermit program does not change the normal cursor keys to the
application cursor keys, but it does so with the keypad keys, which work
as expected.

I have not had a chance to look extensively at the code, but I guess I could
if that is desired.

                        Richard Thomsen
                        [e-mail]

[Ed. - In a pinch, you can always make a file that does "set key" commands
for the cursor keys, and "take" the file whenever you want to run the
editor.]

------------------------------

Date: 25 Aug 1985 0040-PDT
From: Rob-Kling <Kling%UCI-20B@UCI-ICSA>
Subject: Leading Edge & Corona Portable -- Kermit Fit?
Keywords: Leading Edge D PC, Corona Portable PC

For reasons explained below, the new Leading Edge D machine
might be an attractive PC compatable. As might also a Corona portable
at about $1250.

Has anybody had experience using recent MS-Kermits (2.27 or 2.28) with
either of these machines. [I would also appreciate any comments on the
compatability or ruggedness of these machines if anybody has relevant
experience.]

Some dealers in Southern California are pricing the Leading Edge D Machine
rather aggresively -- with 640K, parallel & seriel port, Hercules-like board,
hefty power supply, monitor & 2 DSDD drives ... about $1300-$1400.
About $700 more for a 20MB Seagate or Rodine hard disk w/WD controller.

They will also take off about 25% for universities...... making the
floppy machine about $1150 and the hard disk machine about $1700.

These are attractive prices..... if the machine works well, is
about as compatable as anything else on the market, etc. (And if Leading
Edge doesn't go under in its endless suits with Mitsubishi.)

BTW. The machine has a small footprint and also comes with a 1 year warranty.
Processor is an 8088 at 4.77 MHz. No speed demon, but the aim seems to
be to aim at the highest cmpatability possible (Phoenix BIOS, ...).

I would apprecaite any comments on the compatability, ruggedness of the Leading
Eedge D machine from people who can share some recent experience.

I am told that this machine is just coming to market and that it is better (?)
than the earlier M machine which Mitsubishi manufactured for Leading Edge.

I'll summarize key responses for the net.

Rob Kling
Department of Information and Computer Science
University of California, Irvine
kling@uci-ics-a

PS. Corona has also recently dropped prices. I would also appreciate
comments on the IBM compatability & general value of the Corona portables
manufactured in the last year (since the ROM BIOS was changed because of the
suit by IBM).

------------------------------

Date: Wed, 4 Sep 85 11:48:05 pdt
From: Peter Ludemann <[e-mail]>
Subject: Kermit for the Hyperion?
Keywords: Hyperion Kermit

Does there exist a version of Kermit for the Hyperion
(also sometimes known as Bytec Hyperion or Anderson-Jacobson
Ajile) running DOS2.11 (DOS1.x is acceptable)?

The generic MS-DOS Kermit gets a "write error while reading from
COM1" error - I suspect the problem is that the Hyperion uses
a Zilog SIO chip instead of whatever the IBM-PC uses.

Thanks in advance,

Peter Ludemann
    [e-mail] (ubc-vision!ubc-cs!ludemann)
    [e-mail]  ([e-mail]@ubc.mailnet)
    [e-mail]   ([e-mail])

[Ed. - Generic MS-DOS Kermit should be able to work on any DOS machine.
It uses only DOS calls for i/o, and has no knowledge of any chip.  Try
fooling with the SET PORT command, and maybe you'll stumble upon a device
designator that will work.]

------------------------------

Date: Wed 14 Aug 85 08:52:52-PDT
From: Wing Lee <WingLee%ECLD@ECLA>
Subject: Solution to TSO Kermit vs 7171 Problem
Keywords: TSO Kermit, 7171 Protocol Converters

Good News!  The problem we had with the Series/1 version of TSO-KERMIT
has been solved.  The problem we were having was that TSO-KERMIT would
hang at random places whenever you tried to upload to TSO.  One of
our Systems Programmers, Valaine Saito, discovered what we think
the problem is.  What follows is Valaine's message to me.

>    i looked at the kermit through the 7171 problem again since it appears
>that it really HAS to work if we're going to lose a s/1.  i stumbled through
>the assembler program, it looks like the logic is okay.  after determining
>that, i went to the s/1 and 7171 manuals to see what the difference was.  it
>turns out that there is NO logical difference, but there clearly is a
>functional difference.
>
>    both the s/1 and the 7171 have 64 char type ahead buffers.  the s/1 must
>handle it differently.  when i have both the host and micro kermits sending
>packet lengths of 60 (less than the 64 char buffer size), everything works
>fine.  when either of the kermits sends > 64 packet lengths, the familiar
>"failure to receive ackn from host" msg appears on the micro and the transfer
>stops.  (all this pertains to file transfer from micro to host, i assume the
>other way works since no one has said otherwise.)  at 9600 baud, i ran a
>largish file (60+ kb) through a number of times (10 or so) and it worked
>every time with BOTH kermits sending packet sizes of less than 64.
>
>    so the solution is to send packets of size X, where x is less than 64
>(i always tried sizes of < 64, i didn't try 64).  the practical options
>are:
>
>    tell users about the packet length problem and have them set both
>    lengths themselves.
>
>    re-code the host kermit to accept a max packet size of 63 or 64.
>    (this isn't too cool because only the receive section has the
>     problem.  changing the max packet size would affect all
>     sections.)
>
>    re-code the host kermit to utilize the RPSIZ variable correctly
>    and change the value to F'64' (or 63).  RPSIZ is the max receive
>    packet size.

I have tried sending packet sizes of 64 bytes and that works.  When I tried 65
byte packets, the upload failed, so it looks like 64 is the magic number.

wing lee

[Ed. - For CMS Kermit, we will look into the possibility that the program
can determine if it's a 7171 (it's not clear that it reports itself
differently from a Series/1) and in that case use the smaller packet size.]

------------------------------

Date: Wed, 28 Aug 85 17:12 EST
From: Jim Ennis  <[e-mail]>
Subject: Kermit with Yale ASCII?
Keywords: Yale ASCII Communications Program

What is the oldest version of the YALE ASCII communication package that
can be used with Kermit for upload download (i.e. transparency)?
We have an old turkey implementation using Yale ASCII V2.0 running
under EDX V3.2.....    It is my understanding that I need to go to a
more recent version of the Yale ASCII support in order to utilize the
transparency capabilities of that later version.  Furthermore, I need
to go to a more recent version of EDX before I can go to the more
recent version of the Yale package.  Information on this subject will
be greatly appreciated...... The only reason this is an issue is be-
cause we have only floppies on the box (no hard drive) and I want to
get it right the first try.  Sincerely.

[Ed. - We run version 2.0 of the Yale ASCII package, and version 3.2 at
update level P0A of the EDX Supervisor, and have experienced no problems.
There was, however, a complaint from Larry Bierma@NPRDC in the last Info-Kermit
digest, who claimed that file transfers through the Series/1 would "hang up"
even though they worked fine through the 7171 or 3704.]

------------------------------

End of Info-Kermit Digest
*************************
-------
 6-Sep-85 18:08:45-EDT,15713;000000000001
Mail-From: SY.FDC created at  6-Sep-85 18:08:13
Date: Fri 6 Sep 85 18:08:13-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #16
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri,  6 Sep 1985       Volume 3 : Number 16

Today's Topics:

             Downloading .EXE Files Which Destroy Monitor
                           CR/LF Processing
   How to Make Kermit Work over European Packet Switching Networks
                          Kermit on NEC 8001
                        Concurrent DOS Kermit
                  New BITNET KERMSRV Command Syntax
       Kermit for Japanese Microcomputers and NTT Lisp Machine
                     Kermit for Sharp PC 1500 A?

----------------------------------------------------------------------

Date: Thu, 15 Aug 85 11:58:49 pdt
From: [e-mail] (Don Reynolds)
Subject: Downloading .EXE Files Which Destroy Monitor
Keywords: .EXE File Transfer

Welcome to a new user of Kermit on an IBM compatible!  We like the frog
a lot here, but he sometimes croaks!  This may not be your problem, but
the symptoms happened to me before.  By mistake I used the host command:

    kermit s filename.ext

which sends 7-bit ascii text files, but will not send 8-bit (image mode)
executable (.COM & .EXE) files, Wordstar format files, or other binary
files.  The command for image mode is

    kermit si filename.ext

If you try it without the "i" switch it really trashes the files, and gives
the results Brzozowski states a couple messages down from your message.
However, the file size still looks reasonable using the DOS DIR command.

Question for the net:

People have noted in this digest problems burning out the IBM monochrome
display trying to execute such a file.  I wonder if something like Norton's
Utilities, U-File, or some other utility that looks at disk sectors or one
that looks at memory can easily look at the header to see if the file has
been trashed?  Will DEBUG work?  What do you look for?  Note that I person-
ally have only academic interest since we have mostly color monitors here,
but someday I may have to download executables to a monochrome system.

Best,
Don

[Ed. - The Kermit protocol allows file transmission in both text and binary
mode.  Text mode means that any necessary conversions are done on the file
-- by both the sender and the receiver -- to make the file useful and
readable on the target system.  Binary mode means no conversions are done.
Unfortunately, most Kermit programs have to rely on the user to specify
whether a file is text or binary, because (a) the sending Kermit program
usually can't tell because most systems (e.g. MS-DOS) don't provide this
information in the file descriptor, and (b) the receiving Kermit certainly
doesn't know (unless the sender informs it using the almost universally
unimplemented Attribute packet).  Now, it might be observed that text files
tend to contain bytes whose high-order bits are all off, whereas binary
files tend to have many bytes with this bit on.  However, for the sending
Kermit program to determine whether a file is binary by this method would
require it to make a preliminary pass through the file (the WHOLE file if it
turns out to be text) which would be undesirable for many reasons (e.g.
timeouts when files are long).  Many operating systems require executable
programs to be in a certain format or to be tagged in a certain way, and
will therefore not attempt to execute text files.  But since not all OS's
guard themselves in this way, users should also take precautions.  On a
case-by-case basis, heuristics can be added to some of the Kermit programs
but they will never be foolproof.  For instance, PDP-11 Kermit allows the
use to specify a list of filetypes to determine the mode of the file -- but
how can it know whether a .COM file is a DCL command file (text) or, say, a
CP/M-80 program image (binary)?]

------------------------------

Date:     Fri, 23 Aug 85 15:06:18 BST
From:     Chris-on-Fridays <[e-mail]>
Subject:  CR/LF Processing.
Keywords: CR/LF

Info:

     Is there an accepted policy about when Kermit should and should not do
CR/LF (logical-end-of-record) processing?

     Obviously it is wanted in text-files and not in binaries.  By default
any 7-bit file is probably text, and any file sent as 8-bit image is
probably not; but what assumption do you make if 8th-bit-prefixing is
switched on?

     If the answer to the previous is "binary", shouldn't Kermits in general
make it rather difficult to accidentally switch on 8th-bit-prefixing?  And
if the answer to that one is "yes", then is it wise for a Kermit server, or
in fact any mainframe Kermit, to regularly offer 8th-bit-prefixing in its
I-exchange?  (This is suggested in the protocol manual.)

     Those of us who live on unix (with its LF as record-terminator) are
keenly aware of the problems of files which come in with CR instead.
Unsophisticated users tend to get absoultely floored; and it's they who are
most likely to get into trouble if the two Kermits they are using do not,
between them, pick sensible defaults.

     As an extension, what about the filing-systems which expect to find
carriage-control-characters either at the start of each line (as per
Fortran), or even at the end (older IBM formats)?

                                Chris Kennington (cjk@ucl-cs)

[Ed. - 8th-bit prefixing is totally unrelated to text vs binary mode.  The
prefixing mechanism is just a trick to squeeze 8-bit bytes through a 7-bit
link.  Most Kermit programs do (and should) enable 8th-bit prefixing
automatically if parity is not none (i.e. is even, odd, mark, or space); it
is a transmission technique akin to TELNET IAC doubling.  All Kermit
programs I know about run in text mode by default, and 8th bit prefixing is
off by default except in systems (like IBM mainframes, or Prime computers)
that always use parity.  In Unix, text mode means LF/CRLF conversion is
done, and it works Unix-to-anything, anything-to-Unix, so long as the
"anything" Kermit is also in text mode.  But see the discussion after the
previous message about the perils of automatic mode selection.  Systems that
have carriage control or other "structured text" formats bear the
responsibility for converting them to canonical (CRLF) format before
transmission; VAX/VMS Kermit (the Stevens Bliss version) does this.]

------------------------------

Date: Fri, 30 Aug 85 10:12 MET
From: Peter Bendall, DECUS VAX SIG Europe
  <[e-mail]>
Subject: How to Make Kermit Work over European Packet Switching Networks
Keywords: European Networks

Since I started distributing 6800 and 6809 FLEX Kermits I have received MANY
calls to say that Kermit is not able to work over the European packet
switching networks.

The following "work around" does however work for the German DATEX-P system
and will probably work for other systems also:

For Kermit-32 on VAX/VMS systems:

Call the VAX using CONNECT and start Kermit-32, and issue the commands:

SET RECEIVE START_OF_PACKET 7
SET SEND START_OF_PACKET 7

and then start the server if required.  Then escape to your own Kermit and
issue the equivalent commands:

SET REC SOP=7
SET SEN SOP=7

(or whatever they look like)

and then it works.

[Ed. - Apparently DATEX-P does not pass through Control-A's, which are
used by Kermit as the start-of-packet character.]

In the case of the VAX systems, we have checked that the control-As are
still in the packet when they reach our machine but we have found no
simple way to get them into the packets...  If anyone knows the proper
workaround please let me know!

------------------------------

Date: Wed 28 Aug 85 11:17:59-PDT
From: Ronald Blanford <[e-mail]>
Subject: Kermit on NEC 8001
Keywords: NEC 8001

Some time ago there was a complaint that the Generic version of Kermit
only partially worked on the NEC 8001.  I had reason to need it recently
and found the following fix which works quite well.

Generic Kermit uses the iobyte to switch to the BAT console (which takes
its input from the RDR device) so that it can check the serial port input
status using the Console Status BIOS call.  The BIOS therefore must check
the iobyte twice in this situation, once to determine that the BAT console
is in use, then again to decide which physical device RDR is set to.  The
NEC 8001 does this for the Console Input routine, but not for Console Status.
The default Console Status routine always returns No Input Available, so
that Kermit never tries to receive a character even though it can send them
just fine.

The solution is to patch the dispatch table for the Console Status routine
so that it proceeds to the serial status routine instead of the default.
It might be hard to determine the address of the status routine if RDR is
set to the PTR, UR1, or UR2 device, but for the TTY device the address is
just two entries earlier in the table to be patched.  Fortunately Kermit
uses the TTY device by default.

On the NEC 8001, the serial driver is loaded dynamically, and the address
of the status routine varies depending on which driver is used.  Therefore
this patch must be made each time the system is cold-booted, after installing
the serial device driver but before running Kermit.  It's easiest to make
the patch into a simple program using DDT as follows:

A>DDT
DDT VERS 2.2
-A100
0100 LHLD 1        ; get the address of the BIOS jump table
0103 INX  H        ; step forward to the Console Status entry
0104 INX  H
0105 INX  H
0106 INX  H
0107 MOV  A,M        ; get the address of the Console Status dispatcher
0108 INX  H
0109 MOV  H,M
010A MOV  L,A
010B INX  H        ; step past the dispatcher's initial JMP instruction
010C INX  H
010D INX  H
010E MOV  C,M        ; pick up the address for the TTY Status routine
010F INX  H
0110 MOV  B,M
0111 INX  H
0112 INX  H        ; step forward to the BAT entry
0113 INX  H
0114 MOV  M,C        ; save the TTY address in the BAT entry
0115 INX  H
0116 MOV  M,B
0117 RET        ; return to CP/M
0118 .
-^C            ; Now get out of DDT
A>SAVE 1 KPATCH.COM    ;  and save the patch as a COM file

With this patch program available, perform the following sequence of
actions after cold boot to bring up Kermit:

A>INSTALL8 IRS232A TTY: [,,,,O]        ; install the driver as device TTY
                    ; set up for Object files.  The driver
                    ; name may vary.
A>KPATCH                ; Patch the BAT status routine
A>KERMIT                ; Start Kermit

With the interrupt-driven serial driver in place, this has worked perfectly
for me at up to 9600 baud.  Good luck.

-- Ron

[Ed. - Thanks, Ron!  I've stored this message in the Kermit distribution as
CP4NEC.HLP.]

------------------------------

Date:  Wed, 4 Sep 85 03:14 EDT
From:  "John C. Klensin" <[e-mail]>
Subject:  Concurrent DOS Kermit
Keywords: Concurrent DOS, MS-DOS Kermit

PC-DOS Kermit seems to work fine under Concurrent DOS, with a few
qualifications, as you expect.  First, most of the 'internal' commands
that require PC-DOS interactions don't work, e.g., LOCAL DIR (wildcard
SENDs work fine).  This is, of course, less of a problem under
Concurrent than it would be under PCDOS, since, with Concurrent, you can
switch processes and do anything of these things (or even keep the
current directory or whatever in a handy window).  Second, you must use
SUSPEND=OFF if you expect to do transfers in background.  Third,
experience with the PC indicates that you may want to arrange a bit more
waiting time and/or retry count maximum with your mainframe kermit if
that is possible -- things sometimes get a little slow if there is a lot
of other stuff going on in the machine, especially if kermit is a
background, rather than foreground, process.  I would suspect that this
would be less of a problem on the AT, but haven't tried.

I keep fussing with a CDOS-specific version of Kermit, based on the
CP/M86 version when I manage to be around for more than a couple of
weeks (not frequent in the last year).  It is, of necessity, heavily
dependent on the operating system, and is quite slow when it works.  But
this message is coming to you from a Concurrent DOS 4.1 system, using
PC-DOS kermit, for whatever that is worth.  If someone else would like
to take that on, I would be happy to transfer everything I have done,
and try to transfer everything I know/have found out, otherwise I will
keep fussing as I have time.

The combination of MSDOS kermit and Concurrent also worked fine under
version 3.2 of the latter; versions before 3.2 are hopeless, since they
don't support PCDOS mode.

------------------------------

Date: Fri 16 Aug 85 11:03:59-EDT
From: Daphne Tzoar <[e-mail]>
Subject: New BITNET KERMSRV Command Syntax
Keywords: BITnet KERMSRV

 The syntax of Kermsrv commands has changed slightly so the file
 AANETW.HLP should be modified.  Here is the command format:

?
HELP
SEND { DIR | fn ft | ?}
PUNCH { DIR | fn ft | ?}

Send returns information in netdata format.  Punch uses punch format.
If PUNCH is used, files with LRECL 80 or under will be punched Class
A.  The others will be disk dumped Class N.  The DIR (directory
command) has been replaced by SEND DIR or PUNCH DIR.  File names may
contain wildcards.  Requests to Kermsrv can be either in the form of
messages or reader files, where the file contains a single line with a
valid Kermsrv command.

/daphne

------------------------------

From: ihnp4!kddlab!nttmecl!nttmecl!NTT-20![e-mail]
Date: 27 Aug 1985 2023
Subject: Kermit for Japanese Microcomputers and NTT Lisp Machine
Keywords: Japanese Micro Kermit, NTT Lisp

 Kermit for Japanese micro computers is supported.  Kermit for the
following computers is available:

   (1) NEC PC8800 on CP/M-80
   (2) NEC PC9800 on CP/M-86
   (3) FUJITSU FM-8 on CP/M-80
   (4) FUJITSU FM-11 on MS-DOS
   (5) IBM5550 on MS-DOS

In addition to these computers, Kermit for NTT Lisp Machine ELIS
was written by its language TAO. TAO is a dialect of Lisp which
unifies an object-oriented programming paradigm and a logic
programming paradigm with a procedural programming paradigm.
NTT Lisp Machine (interpreter) runs 1.3 times faster than SYMBOLICS
LISP MACHINE (compiler).

If you are interested in these Kermits, please send me mail to

           hplabs!kddlab!nttmecl!murakami@Berkeley

Is it useful for you to get Kermit sources for Japanese computers?
I hesitate to send these sources because of the following reasons.
 (1) These Kermits will not be widely used in your country.
 (2) Kermit on CP/M-80 is based on the old Kermit version.

We are translating an important part of the Kermit manuals into Japanese.
I would appreciate if you'd allow me to distribute these manuals in Japan.

                    Thank you for your attention

[Ed. - Does everyone agree that the programs listed above are not of general
interest outside of Japan?  If not, I'll try to get them into the Kermit
distribution.]

------------------------------

DATE: 26 Aug 85 1735 WEZ
FROM: [e-mail]  (Franklin A. Davis)
SUBJECT: Kermit for Sharp PC 1500 A?
Keywords: Sharp PC 1500 A Kermit

Anyone know of a Kermit for the Sharp PC 1500 A?  A colleague needs it, and
unfortunately isn't even sure if it uses CP/M, but our guess is that it may
be a close clone.  Please answer directly.

Thanks -- Franklin  <[e-mail]>
Institute for Informatics and Applied Mathematics
University of Bern
Laenggassstrasse 51
CH-3012  Bern
Switzerland

------------------------------

End of Info-Kermit Digest
*************************
-------
10-Sep-85 17:43:14-EDT,21796;000000000001
Mail-From: SY.FDC created at 10-Sep-85 17:42:02
Date: Tue 10 Sep 85 17:42:01-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #17
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue, 10 Sep 1985       Volume 3 : Number 17

Special C-Kermit Edition:

                        New C-Kermit Bug List
               C-Kermit on a 3B2 - Secure Line Locking
                Kermit/cu Incompatabilities on the 3B2
                     C-Kermit Speed on TRS-Xenix
                   C-Kermit Performance with Parity
                            C-Kermit Ideas
         C-Kermit Remote Server Commands Fail After an Abort
       Possible Missing Code in C-Kermit 4C(056)/ckutio 4C(032)
  Cancel File Forces Discard of Remaining Files in C-Kermit 4C(057)
                     Bug in C-Kermit Line Locking
                   Bug Report For C-Kermit 4C(057)
                      Problem Installing 4C(057)
         C-Kermit Take File Control and Background Operation
                   C-Kermit on UTS vs the IBM 7171?
                  Exiting "Protocol Mode" Gracefully

----------------------------------------------------------------------

Date: 10 Sep 85 17:00:00 EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: New C-Kermit Bug List
Keywords: C-Kermit

Most of the messages in this issue report bugs and problems with C-Kermit
4C(057), the current (since July 31) release for Unix.  The problems are
not urgent, so a new release has not yet been prepared.  The problems have,
however, been noted in the "beware" file, KER:CKUKER.BWR, available via
anonymous FTP from Internet host CU20B.  Some of the messages below are
over a month old -- apologies; I'm still catching up from the backlog of
mail after a long vacation.

------------------------------

Date: 16 Aug 85 23:01:39 GMT
From: Robert Vidua <gatech!gitpyr![e-mail]>
Subject: C-Kermit on a 3B2 - Secure Line Locking
Keywords: C-Kermit, 3B2 Kermit

I just recently got C-Kermit 4C(055) and brought it up on a 3B2 running
System V Rel 2.  I'm trying to use it on a line that uucp also uses and
I'm not sure how to do this without making a potential security problem
and still giving ordinary users full access to the line.  I don't want
to modify the code.  That leaves me with a two other solutions: 1) make
kermit setuid to something (it doesn't handle this correctly (i.e. no
'setuid (getruid ())' or equivalent), so this isn't a valid solution)
and 2) make the tty line as well as /usr/spool/locks readable and writable
by everyone (nasty if someone decides to get malicious).  I'm not too
concerned about the 3B2, since I know/trust all the users on it (it's
a intra-departmental machine), but I'll soon be bringing up the same
kermit on a couple of 3B20s that's open to the whole campus and I'd like
to solve the security problem first.

About two or three months ago, there was a discussion on this very topic
in fa.info-kermit which I, silly me, neglected to pay attention to.  Now
I need the information.  Does anyone have an archive of those messages
and is willing to send me a copy?

Robert Viduya
Georgia Institute of Technology

UUCP:   {akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert
        {rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert
BITNET:    CCOPRRV @ GITVM1

[Ed. - The discussions are in the Info-Kermit Digest V2 #11-12, #38-39, and V3
#2.  You should be able to pick up the archives over BITNET via KERMSRV at
host CUVMA -- V2 should be called "MAIL 85A" and V3 should be "MAIL TXT".]

------------------------------

Date: 3 Aug 85 16:00:12 EDT
From: Eliot Lear <[e-mail]>
Subject: Kermit/cu Incompatabilities on the 3B2
Keywords: 3B2 Kermit

I am running kermit on an At&T 3B2 running System V.2.  I don't know if I am
repeating what someone said but we have discovered that cu requires a line
be owned by uucp while Kermit requires that the line be owned by root.
Since the everyday average user is not allowed to root, this presents
problems.  I imagine that this has something to do with checking to see if
the line is active but I don't know.  I figured I'd mention it to you,
though.

                    eliot lear

[Ed. - See previous discussions of line locking.]

------------------------------

Date:  Mon, 26 Aug 85 14:46 MDT
From:  [e-mail]
Subject:  C-Kermit Speed on TRS-Xenix
Keywords: C-kermit, TRS-Xenix Kermit

After compiling the latest ckermit on TRS-80 Model 16b (v. 7 Xenix), I
timed a transfer from VAX/VMS:  16 chars/sec.  I then removed the
-DDEBUG and recompiled.  Now over 200 chars/sec at 4800 baud.

[Ed. - As predicted in V2 #35, building the program without the debugging
feature can result in a perceptible speed improvement -- but 1250% is more
than just perceptible!  I wonder if the difference is as great on other
systems.  In light of this report, it might make sense for every site to
build the program both ways -- use the non-debugging version for production
and the debugging version for tracking down & reporting problems.]

------------------------------

Date: 28-AUG-1985 12:17:47
From: [e-mail]
Subject: C-Kermit Performance with Parity
Keywords: C-Kermit, Parity

    Here's a relayed note on C-KERMIT from Tim Green, Computer Unit,
Warwick University UK. If you want to reply send it to me and I'll forward it.

          Alan Phillips
            Lancaster University

Forwarded message:

I've just put up C-Kermit 4C(057) and have some comments to make regarding
its performance. The performance of C-Kermit on a VAX is fine when you use
it with no parity.  Typically I can get 480ch/s on a 9600 baud line.
However due to the local net we have here we can't use it with no parity for
binary files.  As soon as you start to use parity the performance is greatly
degraded.  This is due to the way C-Kermit tries to detect whether parity is
correct.  If you do a profile of it while it is running you find that it is
spending most of its time setting and unsetting a timer.  There are two
posible solutions to this.  One: Do not test the parity, just assume that it
is correct (leaving error detection to the checksum).  Two: provide an
option to set 7bit data when using no parity.  We are using a VAX 780 with
4.2 Unix.

[Ed. - You're right about the poor performance when parity is "on".  It's
because the program is doing single-character reads rather than reading an
entire "line" (up to a carriage return).  It does this because the
terminating CR might have its parity bit on and therefore won't be
recognized as a CR.  A more clever scheme will used in a future release to
speed things up.  By the way, parity is not used by Kermit for error
checking; rather, Kermit (unlike some other protocols) "tolerates" parity
that is imposed upon it by the communication medium or one of the hosts
involved.]

------------------------------

Date: Sat, 3 Aug 85 00:18:04 pdt
From: "Scott Weikart; Community Data Processing; 415-322-9069"
 <cdp!scott@Glacier>
Subject:  C-Kermit Ideas
Keywords: C-Kermit

Here's are some comments on items in the recent ckuker.bwr file.

> - When connecting back to C-Kermit after a transaction, or after finishing
>   the server, it may be necessary to type a ^Q to clear up an XOFF deadlock.
>   There's not much the Kermit program can do about this...

If XON/XOFF is enabled, why couldn't Kermit send an extra ^Q before exitting?

[Ed. - The problem is in the other direction.  The local PC needs to send a
^Q to the remote end.  But you don't want the PC to do this automatically,
because it might mess things up -- e.g. suppose the remote Kermit was invoked
from within EMACS, which uses ^Q as a command, and has popped to EMACS upon
exit...]

> - ckufio currently goes to a lot of trouble to traverse the directory in
>   order to expand "*" and "?" in wildcards.  Maybe it should just fork the
>   user's customary shell and have it do the expansion.  This would allow
>   fancier filespecs to be given, like "~/ck*.[cwh]".  But it would slow down
>   features like filename completion and menus in the interactive command
>   parser.  (Find out how Unix FTP does it...)

How about forking a shell that's kept around, and communicating
with it through pipes.  This way you would only incur the fork and exec
overhead the first time a file name is specified.  Various EMACS's use this
technique.  In fact, it seems like this could also be used for the
"!" command.

[Ed. - Right, that's the idea.  Any volunteers to submit some code for this
that fits in the current framework and works for all versions of Unix?
Would this technique work on small systems, e.g. small-memory PDP-11's?]

------------------------------

Date: Tue, 6 Aug 85 10:46:07 PDT
From: [e-mail] (David Ragozin)
Subject: C-Kermit Remote Server Commands Fail After an Abort
Keywords: C-Kermit

Running C-Kermit, 4C(057) under 4.2BSD connected to MS-DOS 2.27 Kermit.
With the C-Kermit side in server mode it responds properly to remote and
remote host commands from the MS-DOS side.  However, if I interrupt a remote
command by typing a Control-C on the MS-DOS side, all further remote or
remote host commands fail, except for "remote help". For instance, "remote
dir" elicits the message "Can't list directory", "remote space" gives back
"can't check space", "remote host...." leads to "can't do system command".
Apparantly something on the C-kermit side has been left in a strange state
by the abort.

[Ed. - If you read the MS-DOS Kermit chapter of the Kermit User Guide,
you'll see the explanation.  ^C typed to MS-DOS Kermit during a file
transfer returns to MS-DOS Kermit command level "immediately without sending
any kind of notification to the remote system"; it's for use when, for
instance, you give a "send" command but then realize you forgot to start up
a Kermit on the other end.  This means that the remote Kermit blithely
continues with what it was doing, in this case sending data packets.  If you
waited for a couple minutes (after the other side timed out the maximum
number of times) the situation would have cleared up by itself.  If you have
a real transaction in progress that you want to interrupt, then you should
use ^X or ^Z, which most any Kermit server will honor.  MS-DOS Kermit also
provides a ^E interrupt, which sends an error packet to the remote side,
which is guaranteed to stop any transaction (assuming it arrives).]

------------------------------

Date: Mon, 12 Aug 85 23:30:16 BST
From: [e-mail]
Subject: Possible Missing Code in C-Kermit 4C(056)/ckutio 4C(032)
Keywords: C-Kermit

I had a friend of mine in the US snork a copy of C-Kermit and post it to me
on floppy disks.  He must have grabbed 4C(056) just before 4C(057) was
released and re-released (see Info-Kermit Digest v3 #10/12).  Unfortunately,
the ckctio file seems to lack rtime and gtime routines.  I managed to patch
together a working ckctio by including the appropriate lines of code from
ckvtio.c.  I hope that this oversight has been remedied in 4C(057).
Script Command, V2.0(006) 14 Jun 85

[Ed. - It has.]

As a footnote, the problem reported earler with wart on a Whitechapel
(Info-Kermit Digest v2 #38) seems to have disappeared.

                 Les J. Wu - [e-mail]

------------------------------

Date: Tue, 13 Aug 85 17:37:10 PDT
From: [e-mail] (David Ragozin)
Subject: Cancel File Forces Discard of Remaining Files in C-Kermit 4C(057)
Keywords: C-Kermit

Setting: C-Kermit 4C(057) BSD version on VAX-11/7xx's under BSD4.2.
Problem: When receiving multiple files a Ctrl-F discards the current file, and
   all subsequent files in the same batch. (The transfer of each subsequent
   file is started, and then aborted with a discarded message.)

(I seem to remember a report of a problem of this sort a long time ago, but
find no mention in the .bwr file.  I have also reproduced the same behavior
between 4C(056) versions.)

[Ed. - Sure enough, it's a bug.  Will note this in the .bwr file and fix in
the next release.]

------------------------------

Date: 20-AUG-1985 10:29:51
From: [e-mail]
Subject: Bug in C-Kermit Line Locking
Keywords: C-Kermit

Forwarded message from Dave Osborne, Cripps Computing Centre, Nottingham U, UK

There is a bug in the the Version 7 unix version of the program. The
ckutio.c module, when opening the line (such as /dev/tty), in its
"ttopen" routine, does an 'ioctl' call with parameter TIOCEXCL, to hold the
line for exclusive use.  Unfortunately, it doesn't bother to
unset this condition before closing the line.

[Ed. - This is fixed in the current release.]

------------------------------

Date: 28-AUG-1985 09:58:17
From: [e-mail]
Subject: Bug Report For C-Kermit 4C(057)
Keywords: C-Kermit

   I've had a bug report passed to me from Icarus Sparry, Electrical
Engineering Department, Bath University UK.

Bug in C-Kermit 4C(057) and previous releases:

File CKCFN2.C, routine SPACK

If padding is in operation then it is inserted at the start of the packet
before the ^A, as well as at the end of the packet before the EOL. However the
values at the start of the packet are counted for the checksum, (except for the
first) and the ^A is also included in the checksum.

The workaround is to remember where the ^A is or to start the checksum after
npad+1 characters.

[Ed. - Oops!  You're absolutely right.  This will be noted in the .bwr file,
and will be fixed in the next release.  By the way, padding should only be
sent before the packet, not after the end before the terminator -- I have no
idea how that line of code got in there...]

------------------------------

Date: Wed, 4 Sep 85 16:42:51 cdt
From: Dave Rasmussen <uwmacc!uwmcsd1![e-mail]>
Subject: Problem Installing 4C(057)
Keywords: C-Kermit

I have the version that supposedly corrects the 68000 architectural bugs
mentioned by Frank da Cruz on Usenet, the one marked as: C-Kermit, 4C(057)
31 Jul 85, 4.2 BSD

When I tell it to "set line /dev/t1570" where t1570 is owned by uucp and mode
666, kermit just hangs there.  The problem is on a 68000 based Integrated
Solutions box running 4.2bsd.  I tried running as the superuser in case there
were any file conflicts, but this doesn't change things.

I do have this version running on a Vax 750 with 4.1bsd and it talks to remote
lines with no problems or other modifications.

Any suggestions, or anyone else had these problems? It may well be our
environment, but I think I've looked it over thoroughly.

Dave Rasmussen, CSD University of WI - Milwaukee

[Ed. - Can anyone with a similar system offer any advicde?]

------------------------------

Date: Tue, 3 Sep 85 18:22:15 pdt
From: [e-mail] (Dave Tweten)
Subject: C-Kermit Take File Control and Background Operation
Keywords: C-Kermit

When I read the contents of the current ckuker.bwr file, with particular
attention to the two items I have previously commented on, I noticed
someone had added editorial comment to each item indicating that this
message is necessary.  Though my original message, which included code,
also covered my reasons for the suggestions, I'll repeat the reasons
here.

     Some users report that it would be more desirable to have an error
     during execution of a take file return directly to command level,
     rather than pop to the invoking take file (why?).

Kermit has no flow-of-control commands to be used in TAKE files.  It is
therefore impossible to write a TAKE file which does something
intelligent if a file IT TAKEs should die.  The result of that fact, and
of the way the unmodified Kermit works, is that multiply nested command
files with an error at the bottom level die a slow and painful death,
wasting the user's time until they work their way back up to the top
level.  In background, this is particularly wasteful, since there is
noone to hit ^C to end the nonsense.

My proposal, which I have implemented at our site, is simply a matter of
euthenasia for terminal TAKE files.  Where the Columbia-issue command
processor closes the current TAKE file and pops one level, I have put in
a while statement which makes it keep closing and popping until interactive
command level is reached.

[Ed. - Actually, what is needed is a "set" command to control whether this
is done, with which users can "declare" some errors fatal and others not.
The DEC-20 Kermit script facility has something like this.]

     Some users report that the program should make no internal
     distinction between running in foreground or background (why?).

Release C-Kermit attempts to determine if it is in background by
checking if its parent has set SIGINT to SIG_IGN.  That is not a
completely reliable indicator of being in background, and furthermore,
why would it want to know if it is in background?

[Ed. - So it would know whether or not to issue messages to the user's
screen.  If in background, attempting to print a message to the screen
freezes the the process.]

The release version changes its behavior in a couple of ways as a
function of whether it thinks it is in background.  It sets several
signals to be ignored (which are ignored by default for background
anyway), and it decides to abort immediately on any command failure from
standard input (which prevents graceful termination of a remote server).
Incidently, this is the only way release C-Kermit generates a return
value of BAD_EXIT.

Because C-Kermit's changed behavior in background made it difficult to
debug scripts intended to run in background, I changed ours so it
doesn't try to be different in background.

Ours ALWAYS returns a status value on exit.  The status value is always
GOOD_EXIT if no commands have failed, and BAD_EXIT, otherwise.  That
makes it easy to debug a shell script which uses a while loop to retry
Kermit a number of times.  When a command from standard input fails, our
C-Kermit sets the eventual returned status value to BAD_EXIT and keeps
going, so later commands can gracefully shut down a remote server, if
any.

Over all, I believe our two changes have made C-Kermit much more
civilized, particularly when run from a script.  If Columbia would like
diffs for our changes, I would be happy to send a more recent set.

[Ed. - Dave has sent the diffs; does anyone else have any opinions on these
issues?  Meanwhile, I'll add a little more in the way of rationale to the
comments in the .bwr file.]

------------------------------

From: ihnp4!inmet!ada-uts![e-mail]
Date: 9 Aug 85 17:08:39 CDT (Fri)
Subject: C-Kermit on UTS vs the IBM 7171?
Keywords: C-Kermit, UTS Kermit, 7171 Protocol Converters

I am under the impression that the CMS version of Kermit knows how to talk
through the IBM 7171 protocol converter.  The 7171 allows ascii devices
(terminals or pc's running terminal emulation programs) to look to the IBM
host like an IBM 3270 type terminal.

We (at Intermetrics Inc 733 Concord Ave Cambridge Mass 02138) are running
UTS on a 3083 IBM host with a 7171 attached.  We would love to run a Kermit
that knew about the 7171 and was able to send files back and forth through
it.  So:

    * Is it true that the CMS kermit knows how to do this ?

[Ed. - Yes.]

    * If so, how hard would it be to add this capability to UTS Kermit ?

[Ed. - I believe Philip Murton at the University of Toronto
([e-mail]) has done this, or knows someone who did.  The
UTS code uses a different technique (escape sequences) than CMS Kermit
(CCW programming).]

    * Are there any plans to do so?

[Ed. - Philip, do you have this code for the current, or a recent, release
of C-Kermit?]

    * Would you like us to take a shot at it (and where do we go for
      help when we need it) ?

[Ed. - Let's see if/how Philip responds.  If we don't hear from him, we'll
try to dig up the code he sent us long ago for the old Unix Kermit.]

Thanks,

        Fred Mueller   [phone]

PS Thanks in general for devoting so much energy on such a worthwhile
   cause.  I hope you get lots of kudos for it.

------------------------------

Date: Sat, 7 Sep 85 02:49:35 edt
From: ukma!sean@anl-mcs (Sean Casey)
Subject: Exiting "Protocol Mode" Gracefully
Keywords: C-Kermit

I think that C-kermit should have some provision for completely aborting
the protocol from the terminal.  When one is trying to figure out which
parity, flow control, handshaking, etc. settings to use with new computer,
a considerable amount of time may be spent waiting for the local kermit to
give up on the transfer.  CTRL/F and CTRL/B are provided to abort a
transfer in progress, but there is no way to abort the protocol without
also exiting kermit (and losing dtr on the line). I'd like to see another
control sequence, perhaps CTRL/X, that would cause the local kermit to
immediately exit the protocol and give the command prompt.  Then, when one
is debugging a kermit conversation, the protocol could be easily aborted
as soon as the debugger sees that the two kermits aren't talking
correctly.

-  Sean Casey                        UUCP:   [e-mail]   or
-  Department of Mathematics                 {cbosgd,anlams,hasmed}!ukma!sean
-  University of Kentucky            ARPA:   ukma![e-mail]

[Ed. - I agree, this has been noted in the .bwr file for some time.  MS-DOS
Kermit has a couple options for this which are missing from C-Kermit.  They
should be added in future releases.]

------------------------------

End of Info-Kermit Digest
*************************
-------
12-Sep-85 18:40:09-EDT,17249;000000000001
Mail-From: SY.FDC created at 12-Sep-85 18:39:42
Date: Thu 12 Sep 85 18:39:42-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #18
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu, 12 Sep 1985       Volume 3 : Number 18

Today's Topics:

        Announcing LM-KERMIT for Lispmachine Lisp Environments
                     Kermit Diskette Distribution
           HP110 Kermit Binaries & MSIBMP.BOO Name Problem
       NEC PC8800 (not 8001), APC III, & other Japanese Kermits
                       Kermit and the Far East
          Kermit and the European Packet Switching Services
                 Kermit on X.25 and Similar Networks
                         Kermit over Networks
                        CMS Kermit with 7171's
           Behaviour of MS-Kermit 2.28 on a COMPAQ Portable
                 Kermit for Exxon Office Systems 500?
                  Kermit for Cromix and the NCR DMV?
                  MS-DOS Kermit for the Gavilan PC?

----------------------------------------------------------------------

Date: Wed, 11 Sep 85 19:04:27 EDT
From: George J. Carrette <[e-mail]>
Subject: Announcing LM-KERMIT for Lispmachine Lisp Environments
Keywords: LM-Kermit, Lisp

                              LM-KERMIT
               KERMIT and terminal emulation capability
                   for ZetaLisp based lispmachines.

LM-KERMIT was implemented by Mark David of LMI (Lisp Machines Inc).  The
use of KERMIT on a lispmachine can fill the gap between sophisticated (and
expensive) networking hardware and software available on lispmachines and
the other extreme, NO NETWORKING.  What we found is that many mainframe/
minicomputer installations take a long time to purchase and install
something like ethernet TCP-IP, but that KERMIT shows up almost everwhere,
already installed or in some users directory.

There are presently available two versions:

* bundled with the LMI-LAMBDA. It supports terminal emulation, KERMIT,
  and serial connections via RS-232, TCP-IP (TELNET), etc. Also
  provided is a HOST/MAINFRAME emulation capability so that PC's
  can log into the machine and use SERVER mode.

* A port to the Symbolics 36xx machines done by Mark Ahlstrom of Honeywell.
  It supports terminal emulation, KERMIT, and serial connections via
  RS-232.

The source is conditionalized in the usual manner, #+LMI, #+SYMBOLICS.
There are a few #+TI conditionalizations although they have not been
tested. A user of the TI (Texas Instruments) Explorer should be able to
bring LM-KERMIT up by changing most of the #+LMI conditionalizations to
#+(OR LMI TI).

A word about the programming style used.  Don't expect anything exemplary.
Parts of the code are a quick hack off of KERMIT.C, and much of the window
system code is a mix of "doing while learning" combined with later added
sophistication and hair. Compiling the source gives style warnings of
various severities on both the LMI and Symbolics machines. However, the
number of phone calls I've been getting on this has forced us to either
tell people to go away or provide what we have now. The port that Ahlstrom
did to Symbolics Release 6.0 was also of the "conditionalize into the
source the equivalent Symbolics function name or feature" rather than the
other more slow route of "rewrite things to use mainline Common-Lisp
functions."

However, now that it is out people will no doubt be improving things.

-gjc

[Ed. - The files are in KER:LM*.*, available via anonymous FTP from CU20B.]

------------------------------

Date: Thu 12 Sep 85 12:43:33-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit Diskette Distribution
Keywords: Kermit Diskettes

As anyone who has received a Kermit tape knows, bootstrapping the
microcomputer versions from the tape is a tricky, frustrating business.
It's even trickier if you don't have a computer with a tape drive.  To ease
the pain, we are preparing to make it easier for people to get Kermit
programs on diskette; we expect to be able to distribute IBM PC and Apple
Macintosh diskettes ourselves, and we'd like to compile a list of other
sources for diskettes or other "native media".

If you know of a user group or other organization that distributes Kermit
on native media for a particular system (e.g. a Heath-89 user group, a
TRS-80 user group, etc), please send me the information that would be
needed to order Kermit from that organization -- Address, pricing, order
number, etc, plus phone number (so I can verify the information and their
willingness to act as distributor).  Also, if you belong to a user group
that could be distributing Kermit but isn't, maybe you could submit it.
Individuals are also welcome to volunteer to distribute diskettes -- as
some already have been doing for the Apple II and Commodore 64 -- but when
addresses and ordering information are published, the demand might exceed
the ability of a single individual to meet it.

Of course, any person or group that distributes Kermit should not be doing
it for profit; the cost should be designed only to recover expenses for
media, postage, packaging, etc, plus a little margin to allow for expansion
when demand outstrips capacity.

P.S. If you can't reply by netmail, send it to me at

    Columbia University
    Center for Computing Activities
    612 W. 115th Street
    New York, NY  10025

------------------------------

Date: Wed 31 Jul 85 19:25:38-PDT
From: Jim Lewinson <[e-mail]>
Subject: HP110 Kermit Binaries & MSIBMP.BOO Name Problem
Keywords: HP110 Kermit

According to the documentation, KER:MSIBMP.BOO is supposed to be
MSIBMPC.BOO.  I suppose it got truncated to make it 6 characters, but
AAFILES.HLP should be updated.

[Ed. - Thanks for pointing this out, will change AAFILES.HLP.]

Also, you find an (old) .EXE file for the HP-110 MS-DOS kermit on
[SU-GSB-WHY] WHY:<KERMIT>MSHP110.EXE.  It is based on an old version of the
source code, and I'm not sure how well tested it is, but maybe it will help
someone more than nothing.  Maybe when I get back to the west coast I can
get someone working on rebuilding it with the latest sources.

                    Jim

[Ed. - Thanks.  The 8-bit binary .EXE file is now available as
KB:MSHP11.EXE, and a hex encoding (straight two-hex-digits per 8-bit byte)
is in KER:MSHP11.HEX.  There is also source and documentation which may or
may not correspond to the binaries in KER:MSXHPX.*.]

------------------------------

Date: Fri 6 Sep 85 22:33:03-PDT
From: Ronald Blanford <[e-mail]>
Subject: NEC PC8800 (not 8001), APC III, & other Japanese Kermits
Keywords: Japanese Micro Kermits, NEX PC8800 Kermit, APC III Kermit

The NEC 8001 Generic Kermit-80 patch had a slight error, not in the patch,
but that the machine is in fact the NEC PC8800.  I got confused by the
multiplicity of models I deal with.  (I don't believe there is an 8001.)

As for the offer of source for Japanese computer Kermits, the NEC PC8800
has been extensively sold in this country so that source may be useful.
The PC9800 is sold here (with differences) as the APC III, which supports
only MS-DOS, making a CP/M-86 Kermit of no use.  I don't know about the
other models mentioned.

I received an MS-Kermit system module for the APC III (MSXAPC3.ASM) from
someone at Virginia Tech (VPI&SU).  I haven't seen it included in your
lists, so I wonder if you ever got a copy.  It seems to work acceptably
with version 2.28.  I can make it available if you wish.

-- Ron

------------------------------

Date: Sat, 07 Sep 85 16:50:22 cet
From:  [e-mail]
Subject: Kermit and the Far East
Keywords: Japanese Micro Kermits

There are some Fujitsus and NECs over here in Germany.  I would appreciate if
you could put at least the MS-DOS version on CUVMA.

I have requested Mr. Murakami to send it direct, but I don't know, really if it
will work. (usenet-BITNET)

Eberhard W. Lisse

[Ed. - I tried too, but got mailer replies back with messages like "Too
many hops"...]

------------------------------

Date: Sat, 07 Sep 85 16:21:39 cet
From:  [e-mail]
Subject: Kermit and the European Packet Switching Services
Keywords: European Networks

I have no problems at all with the European packet switching service.
I have had no trouble on the Datex-P after setting both Kermits to

         SET PARITY EVEN

I have used the following hardware:

    IBM-PC     DOS 2.11 KERMIT 2.28
    OSBORNE 1  CP/M 80  KERMIT 4.05
    RAINBOW    DOS 2.?? KERMIT 2.26
    VAX 11/780 VMS 3.7
                   4.1  KERMIT 3.0.055
                               3.0.066.
    CYBER 175   NOS     KERMIT ???

    IBM         VM/CMS  KERMIT 2.??

( If I dial my BITnet host [the IBM] through Datex-P I have to set
  my local parity to even. I don't set anything on the IBM.

  If I do it from any machine through at the Technical University
  or from the University Hospital I have to set the local parity to
  MARK.

  This indicates that Datex-P forces the parity to EVEN.

  I can't get our PDP-11/44 RMS-X11M with the new KERMIT to file
  transfer.  CONNECT works, but now way of getting one single packet
  over to the IBM or back.  Doesn't bother me though, as I'm doing
  the file transfer with the VAX anyway due to a faster line.)

[Ed. - I believe newer versions of PDP-11 Kermit handle IBM communications
a little better.]

Same thing works for Telenet I am told by [e-mail] who
had a mail the other day.

Eberhard W. Lisse <[e-mail]>

------------------------------

Date: Wed, 11 Sep 85 11:15:18 BST
From: "Chris.K.Now-and-Then" <[e-mail]>
Subject: Kermit on X.25 and Similar Networks
Keywords: European Networks

     Peter Bendall's suggestion (infodig 16) of substituting BEL (07) for
SOH (01) as Kermit start-of-packet is an interesting kludge, but not quite
the canonical way of dealing with the problem (of how to work Kermit across
text-line-oriented networks).  Admittedly almost any (terminal) network will
pass BEL, for obvious reasons; but bridges, PADs etc. often feel free to
add BELs if they see fit.  What about a PAD which stuck a BEL into any
"overlength" line?

     I regularly Kermit large files over UK JANET, which uses XXX (X.3,
X.28, X.29) above X.25.  In normal terminal (line) mode, SOH will be
stripped.  The easy answer is to switch to character (transparent) mode, in
which case all control characters are passed through "as sent".  For XXX
this is in fact overkill, since there are parameters to specify which
control chars are to be passed; but it is straighforward and always
supported on the user interfaces; it also switches off local echo, which is
desirable.  In principle character-mode could result in Kermit packets being
sent as several blocks each; this does not in fact happen when using a
standard JANET PAD, due to the forward-on-timeout strategy employed.

     I believe that every terminal network protocol includes a transparent
mode, so the solution is generally applicable.

                                        Chris Kennington.

------------------------------

Date: Sat, 7 Sep 85 13:52:05 edt
From: Mike Ciaraldi <[e-mail]>
Subject: Kermit over Networks
Keywords: MILNEY, TELENET

Two messages in Info-Kermit digest volume 3, number 14 asked about file
transfers over Milnet and Telenet.  I haven't used either of these, but the
symptoms sound like a problem I have run into before.

Sometimes you are able to log on, start up Kermit on the remote machine, and
give it commands like "DIR" with no trouble.  But when you try to do a file
transfer your local machine just sits there until it times out, as if no
packets are being received either way.

When this has happened to me, I can usually get it to work by EXPLICITLY
setting the parity of both Kermits, local and remote.  Naturally, if your
communications channel (e.g. Telenet) enforces a particular parity (e.g.
even), you have to set the Kermits to match each other and the comm channel.

Parity being slightly off doesn't seem to affect commands like DIR, but file
transfers and other things that use packets cannot handle it because the
checksums, 8th-bit prefixing, and so on are thrown off.  Thus no packets get
through.

Mike Ciaraldi
ciaraldi@rochester
seismo!rochester!ciaraldi

------------------------------

Date: Tue, 10 Sep 85 09:03:52 EDT
From: ostrove@umd5 (Steve Ostrove)
Subject: CMS-KERMIT with 7171's
Keywords: VM/CMS Kermit, 7171 Protocol Converters

We are in the process of testing out our 7171's with CMS.  Although I haven't
done extensive testing, yesterday I transfered a 65K file using KERMIT-MS
on one side and KERMIT-CMS on the other (versions 2.28 and 2.01 respectively).
The transfer was using a packet size of 94 (default).  I had no problems.
It would seem therefore that the problem with packet size and TSO, may be
a problem unique to TSO and the 7171's.  I will attempt to do more extensive
testing of them soon.

On a different note.  When we put KERMIT-CMS into server mode, it does not
seem to respond to any terminating command with the exception of FINISH.
Neither LOG or BYE works.  Is this normal??

Sincerely,
Steve Ostrove
User Services Staff
The University of Maryland Computer Science Center
[e-mail]

[Ed. - Thanks for the information.  No, CMS Kermit is supposed to log itself
out upon receipt of a BYE request, and it does so nicely on our CMS system.
No one here can think of a reason why it would fail to do so.  Can anyone
else?]

------------------------------

Date: Mon, 9 Sep 85 13:40:34 BST
From: [e-mail]
Subject: Behaviour of MS-Kermit 2.28 on a COMPAQ Portable
Keywords: MS-DOS Kermit, COMPAQ Portable

     I have encountered a slight bios incompatability between a real IBM
PC/XT and a "Compatable" Compaq Portable.  In short, MS-Kermit v2.28 with
bug fixes as advertised in .BWR file work fine on the XT.  The problem,
however, is that when sending or receiving files, the Compaq displays a
blank inverse video mode line with a single spurious character ('s') above
the transfer status displays.  The mode line displayed during connection
appears normally.

     The information normally contained in this mode line is rather
important in that it gives the user information on how to abort an active
file transfer.  After some digging, I traced the problem to the routine
'putmod' in MSXIBM.ASM.  As I don't have documentation on the bios
interfaces I did a simple backout to the putmod routine in version 2.27.
Below are the affected lines:

Original version 2.28 code:
             call    poscur
             pop     si              ; get message back
     putmo1: lodsb                   ; get a byte
             cmp     al,'$'          ; end of string?
             je      putmo2
             mov     ah,14           ; write to screen
             mov     bx,07000h       ; inverse video, page one
             int     bios
             jmp     putmo1
     putmo2: ret                     ; and return
     putmod  endp

Version 2.27 backout:
             call    poscur
             pop     dx              ; get message back
             mov     ah,prstr
             int     dos
             ret
     putmod  endp

        This fix works fine for the COMPAQ.  On a real PC, however, the
information line is displayed in normal video.  At least this backout
provides the user with the necessary information in all cases.  Has anybody
else experienced this anomolous behaviour with a Compaq or have an
explanation for the incompatability?

                        -- Les J. Wu <[e-mail]>

------------------------------

Date: Fri, 6 Sep 85 15:19:48 edt
From: Bob Sutterfield <[e-mail]>
Subject: Kermit for Exxon Office Systems 500?
Keywords: Exxon Office System 500 Kermit

The secretary across the hall has recently been blessed with an Exxon Office
Systems 500 Series word processor.  It apparently crunches words nicely
enough, but its facilities to talk to the outside world are severely
limited.  It has some sort of asynchronous communications software, but this
won't do the job for us.

I don't know what kind of processor it has, nor what operating system it
runs.  We really need to get several hundred pages of publications off this
beast, and onto a usable machine.  Does anybody know of pointers to a Kermit
for this beast?

------------------------------

Date: Mon, 09 Sep 85 03:37:14 cet
From:  [e-mail]
Subject: Kermit for Cromix and the NCR DMV?
Keywords: Cromix Kermit, NCR DMV Kermit

Any information regarding Kermit for Cromemco Cromixor the NCR
Decision MATE V ?

Eberhard W. Lisse  <zdv626%djukfa11.bitnet%wiscvm.arpa>

------------------------------

Date: Tue, 10 Sep 85 14:08:18 PDT
From: [e-mail]
Subject: MS-DOS Kermit for the Gavilan PC?
Keywords: MS-DOS Kermit, Gavilan PC

A professor here has the Gavilan PC with the 3" drives.  Has anyone
successfully run MS-DOS Kermit on one of these, and if so, can we possibily
get a copy of the disk?

Thanks is advance,

Rich Fagen
Caltech Computing Support
[e-mail]
[e-mail]
(818)-356-3896

------------------------------

End of Info-Kermit Digest
*************************
-------
13-Sep-85 18:16:56-EDT,17716;000000000001
Mail-From: SY.FDC created at 13-Sep-85 18:16:20
Date: Fri 13 Sep 85 18:16:20-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #19
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 13 Sep 1985       Volume 3 : Number 19

Departments:

  MACINTOSH KERMIT -
    New Macintosh Kermit Bug List
    Macintosh Kermit VT100 Emulation Bottom-of-Screen Bug
    Garbage in Upper Left Corner on MacKermit
    MacKermit Comments
    MacKermit/ScreenSaver Incompatibility
    MacKermit Transfer Command
    Macintosh Kermit Key Configurator Limitation
    Mac Kermit Show-Response Window Too Narrow
    Bug and Nit in Macintosh Kermit
    Terminal Emulation Bug In Mac Kermit
    Double Keying Option-Keys in Mac Kermit
    Mac Kermit vs Yale ASCII

  IBM MAINFRAME KERMIT -
    Kermit for UTS with Series/1
    CMS Kermit with 7171's (two messages)
    Kermit-11 vs IBM VM/CMS

  MISCELLANY -
    Kermit Distribution in the UK


----------------------------------------------------------------------

Date: Fri 13 Sep 85 17:24:56 EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: New Macintosh Kermit Bug List
Keywords: MacKermit

The following messages report bugs in the current release of Macintosh
Kermit, or suggest improvements.  These have been noted in the new "beware"
file, KER:CKMKER.BWR, which is available via anonymous FTP from CU20B.  For
now, no changes are being made to the program, mainly because Mac Kermit is
still "between maintainers".

Although not mentioned specifically in conjunction with Mac Kermit, the
C-Kermit bug reported by Icarus Sperry (Bath Univ, UK) in Info-Kermit V3
#17, namely that checksums are computed incorrectly if padding is selected,
applies also to Macintosh Kermit.

------------------------------

Date: Thu 15 Aug 85 11:12:12-CDT
From: Don Nash <[e-mail]>
Subject: Macintosh Kermit VT100 Emulation Bottom-of-Screen Bug
Keywords: MacKermit, Terminal Emulation

I just found found this simply wonderful bug in Macintosh Kermit.  Here's how
to do it:

        1)  Set MacKermit 0.8(33) for 9600 baud, no parity, remote echo.

        2)  Connect to a VAX 11/780 running VMS 4.1 and Eunice and log in.

        3)  Set your terminal type by having the following lines in your
            LOGIN.COM file:

                $define TERM "vt100"
                $set term /dev = vt100 /line

        4)  Type out a file which is long enough to fill the screen more
            once using the following command:

                type /page filename.ext

        5)  When you are prompted to hit return, type ^C.  The word "Cancel"
            should appear, but it should be partially below the screen.

        6)  Type <CR> several times.  If you get the same results I did, then
            the screen of the Mac should go crazy.  It looks like snow on a
            TV set, except that it is black snow on a white background (which
            seems logical, since the Mac's screen is white).  The Mac is now
            completely wedged, the cursor does not respond to mouse movements.
            The only way out is to reset the Mac and restart MacKermit.

Also, the number zero and the capital letter oh were identical on MacKermit,
and the same applies to the capital letter "I" (the letter after "H"), and
the lowercase letter "l" (the letter after "k").  They are also *exactly*
the same.
                                        Don Nash

[Ed. - Thanks, noted in the beware file.]

------------------------------

Date: Thu 15 Aug 85 12:25:26-CDT
From: Don Nash <[e-mail]>
Subject: Garbage in Upper Left Corner on MacKermit
Keywords: MacKermit

I read the file CKMKER.BWR.8.  In the section UNDIGESTED, item #3 said that
Dan Tappan from BBN reported garbage in the upper left corner of the terminal
emulator window which eventually went away.  I have the same problem, but
it won't go away.  It is nothing serious, but it does seem to be permanent on
my copy of MacKermit 0.8(33).  It does not interfere with the display in any
way.  Hope this aids in digestion.

                    Don Nash

------------------------------

Date:     Mon, 19 Aug 85 11:45:56 PDT
From:     [e-mail]
Subject:  MacKermit Comments
Keywords: MacKermit

I'm very pleased with the new MacKermit release.  I use it now in
preference to MacTerminal.  I like the speed:  both initialization and
operation are much better than MacT.  I have set up the key map to send
the right characters for EDT.  File transfer with VMS is very smooth.

- Martin Ewing

Comments on 0.8(33) Kermit for Macintosh:

SERIOUS

1. The VMS TYPE/PAGE command types a page of output from a file and
types "Type enter to continue" (or some such) in reverse video on bottom
line of screen.  If you ^Y at that point to terminate, Kermit writes the
next line ("Interrupt" in reverse video) on what appears to be line 25.
Kermit often dies shortly thereafter.  I don't have the exact character
sequence that VMS is putting out.

[Ed. - Same as Don Nash's bug.  Temporary workaround: don't use VMS
(just kidding...)]

NUISANCE

2.  Screen is not thoroughly wiped by erase screen command.  Garbage
characters left at right of screen (sometimes).  This may have been
documented before.

3.  A blinking cursor, or, better, a blinking solid cursor would be a
great help.  It's nearly impossible to find the underscore in a page
full of text.  A user-selectable cursor format would be preferable.

[Ed. - Good idea.]

SUGGESTIONS

4.  It would be handy to distribute a standard VT100/numeric keypad
definitions file.  This is important for running the VMS EDT editor.
I'll donate such a file if requested.

[Ed. - Please do.]

5.  Apparently the VT10x graphics characters are not emulated.  At least
the MONITOR command on VMS does not produce the desired line and block
characters.  This would be a useful addition for those of us who like to
stare at these status displays.

6.  Emulate the VT102 printer port commands.

------------------------------

Date: Thu, 8 Aug 85 10:14:02 mdt
From: [e-mail] (John De Vries)
Subject: MacKermit/ScreenSaver Incompatibility
Keywords: MacKermit

I have received a report that while making long uploads from MacKermit while
ScreenSaver (a desk accessory) is active will cause the upload to bomb and
will indeed screw up the Mac's system, necessitating a reboot. It happens
when ScreenSaver goes and blanks the screen...

Zoz

------------------------------

Date: Fri 9 Aug 85 16:55:15-EDT
From: Don Lanini <Us.Dcl@CU20D>
Subject: MacKermit Transfer Command
Keywords: MacKermit

Whenever I try to use the transfer command under the transfer menu to launch
an application from another disk (a disk other than the one Kermit is on), it
blows up the machine with an ID = 26 error and hangs.

The version is 0.8(32)

------------------------------

Date: Wed 19 Jun 85 16:30:52-EDT
From: Bill Schilit <[e-mail]>
Subject: Macintosh Kermit Key Configurator Limitation
Keywords: MacKermit

I just read a message on the net... you might want to configure a system
disk with the Dutch or German, or French international resources and check
out the results of this on MacKey...

I think the result will be an incorrect keyboard (check this out in
relation to the KEYCAPS display).  Since the key names are hard
coded in an array in the program...

------------------------------

Date: Tue, 9 Jul 85 18:43:58 edt
From: Mike Ciaraldi  <[e-mail]>
Subject: Mac Kermit Show-Response Window Too Narrow
Keywords: MacKermit

When you give a remote command (e.g. Directory) to a server, the results
come up in a window.  You can scroll the window from side to side, but even
if you move it all the way to the left (i.e. the little box in the
horizontal scroll bar is all the way to the right), you still can't see the
right end of the line of text.  You have to stretch the window to see it.

[Ed. - I agree this might not be intuitively obvious to the user...]

When you do a "Get file from server", after the transfer is complete the box
that keeps you informed of the progress of the transfer still stays on the
middle of the screen until you click on it.  This is not really obvious as
the way to continue.  What makes it bad is that the mouse pointer still
shows as the little clock face indefinitely, implying that you ought to wait
before proceeding (maybe while it closes the file or something).

[Ed. - Right, this has been noted in the .BWR file all along.]

------------------------------


Date: 23 Jul 1985 02:04 PST
From: Charles Carvalho <CHARLES@ACC>
Subject: Bug and Nit in Macintosh Kermit
Keywords: MacKermit

A friend pointed out a bug and a nit in the Macintosh Kermit:

bug: if you call SFGetFile with the numTypes argument equal to zero,
it apparently doesn't find all files; numTypes should be -1 instead.

[Ed. - From one of the authors: "I haven't noticed any problems, and I
believe the code reflects the documentation."  Has anyone actually observed
files being skipped over?]

nit: the Close box at the left of the MacKermit window doesn't do anything;
it ought to be left out (define the window with the NoGoAway attribute).

                        /Charles

------------------------------

Date: Wed 31 Jul 85 15:18:44-EDT
From: Ben Fried <UI.Ben@CU20C>
Subject: Terminal Emulation Bug In Mac Kermit
Keywords: MacKermit, Terminal Emulation

I don't know if i can reproduce this, but i definitely found a bug in mac
kermit 0.8(33)

I was in emacs, typing a command into the echo area, when a send came in.  the
first few scan lines of the text showed up at the bottom of the screen, then
it froze--i had mouse control, but the event handler must have frozen,
because i got no response to any sort of update event -- keydowns, clicking
the mouse, whatever.

it looks like it didn't handle the scrolling of the text i was sent correctly,
and died somewhere in there.  but i'm not sure.

[Ed. - "Doubt it was the event handler, more likely it is a scroll problem with
the characters being drawn off the screen."  Noted in .BWR file.]

------------------------------

Date:  Sat, 7 Sep 85 19:10 MST
From: Barry Margolin <[e-mail]>
Subject: Double Keying Option-Keys in Mac Kermit

I think I've figured out why certain characters have to be doubled in
order to send them in MacKermit.  These characters are normally set to
nonspacing diacritical marks.  For instance, Option-e is normally a
nonspacing accent grave.  In the normal Macintosh text input
environment, nothing gets sent until you type the next character after a
diacritical, so that it can send the appropriate accented character.  If
you type the diacritical twice, it sends just the diacritial character.
If you type a character that cannot be used with that diacritical, it
sends the diacritical followed by the character.  This is all consistent
with the behavior I have seen when I use the Option key as a Control
key.  I suspect that the same problems would exist if I used the Option
key as a Meta key, which I believe is the default.

[Ed. - This was also noted in the .BWR file that originally went out with
0.8(33).]

------------------------------

Date: Thu, 22 Aug 85 19:47:45 edt
From: Mike Ciaraldi <[e-mail]>
Subject: Mac Kermit vs Yale ASCII

We just started using MacKermit to talk to our IBM 4381, which uses a Series
1 front end with the Yale Ascii package.  On the other end we installed the
version of TSO Kermit from U of Toronto.

File transfers work OK, it seems.

Big problem with terminal emulation.  The packages we use on MVS use lots of
boldface.  The CKMKER.BWR file says that boldface characters are the wrong
size, but for us it's worse than that.  The cursor proceeds along, putting
stuff on the screen, then skips back and erases several characters, leaving
a series of gaps in the line of text.  If you open up a window over the
affected area, then close it again, the text is OK.  It's not in boldface,
but it is perfectly readable and in the right place.

[Ed. - The problem is still probably due to the characters being a different
size from what they program thinks they are.  Some IBM/Yale-ASCII sites have
found the problem so annoying that they define a new terminal type for the
Macs, which is basically a VT100 without boldface.]

We tried opening up the SHOW RESPONSE window, stretching it to almost fill
the screen, then switching back and forth between it and the main window to
force refreshing of the screen image in the main window.  This works, but
the lower right corner of the SHOW RESPONSE window is "dead", i.e. clicking
on it will not bring the window to the front.  The dead area is the part
where the size-changing icon usually appears.  When the main window is in
the background, there doesn't seem to be this problem getting it back.

Mike Ciaraldi
ciaraldi@rochester

[Ed. - Mike mentioned in a subsequent message that they would try to come up
with a fix for the boldface problem.]

------------------------------

Date: 12 September 1985, 15:31:45 EDT
From: Philip Murton <[e-mail]>
Subject: Kermit for UTS with Series/1

We are no longer running UTS under VM here so that only version
of Kermit for UTS I have is based on the old UNIX Kermit.

[Ed. - This is the KERMIT.C from the Protocol Manual, with modifications
to support the Series/1, presumably it will also work with the 7171, 4994,
and other systems that run the Yale ASCII package.  I've put it in
K2:UTSS1.C on CU20B.]

------------------------------

Date: Fri, 13 Sep 85 02:07:01 EDT
From: Peter DiCamillo <CMSMAINT@BROWNVM>
Subject: CMS Kermit with 7171's

I can confirm Steve Ostrove's experience that CMS Kermit through the 7171
does not log itself out, and only responds to FINISH.  Even with FINISH, CMS
Kermit doesn't respond with "R;" until after I enter a carriage return back
in the terminal session.

From what I have heard, the packet size problem with 7171s is a performance
problem which only shows up when a 7171 is loaded.  If Steve was testing
with only one or two users on the 7171, then a larger packet size would
work.  I haven't had a chance to confirm this myself yet.

Kermit should be able to distinguish a Series/1 from a 7171 because a
Series/1 emulates a 3277 terminal, but a 7171 emulates a 3278 terminal. This
device type information is available to a program by using DIAG X'24' to
obtain information about the virtual console.

Peter DiCamillo

[Ed. - Can anyone provide a clue as to why CMS Kermit might refuse to log
itself out when run from a 7171, but log out OK when run from a 3705???]

------------------------------

Date: 13 September 85 14:35 EDT
From: [e-mail]
Subject: CMS Kermit and 7171s

The problem with Kermit (CMS at least, and I expect the same with TSO) and
7171s should only show up if the 7171 can not field the incoming characters
as fast as they are sent. This forces the 7171 to use a 64 character long
circular type ahead buffer. Once this buffer fills up the 7171 will not
accept further input until the buffer starts to empty.  As long as a set of
8 terminal ports is not 'over worked' it should be able to handle input from
a terminal at 9600 baud. It is only when more than one of the terminals on a
set of 8 ports is sending large data buffers at high data rates that there
will be overrun problems. I do not know at what data rates or how many
active terminals it takes to actually cause the problems, but 1 terminal at
9600 baud (plus the rest doing normal terminal type output traffic, not file
transfer) should not exhibit the problem. This problem has been discussed
with the IBM development team for the 7171. Personally I doubt that the
problem will be corrected in future versions of the device as it appears
that IBM does not intend to have the device support file transfer, but
rather to support attachment of dumb-terminals only.

":-)" Nick Gimbrone <[e-mail]> [phone]

------------------------------

Date: 13 SEP 85 07:39-EST
From:  [e-mail]
Subject: Kermit-11 vs IBM VM/CMS

The most recent Kermit digest had a comment regarding Kermit-11 and CMS.
Here is an explanation (?)

I should point out that Kermit-11 has never worked well with CMS  Kermit
(before  the  S/1  support) as the U of Toledo does not use standard IBM
half duplex lines, thus making testing impossible. The  controller  here
is  a  CCI  which  fakes  a FDX link. Kermit-11 does, however, work fine
with the S/1 support in the newest CMS kermit, as long as one  remembers
to set parity to anything other than the default, none.

brian nelson

------------------------------

Date: 10-SEP-1985 10:39:01
From: [e-mail]
Subject: Kermit Distribution in the UK

Lancaster University (UK) have just installed Columbia tapes written there
on August 3. The files are all online on a VAX 11/780 and can be accessed
freely by anyone who wishes using NIFTP or KERMIT. We can also send out
files on 9 track tape, and on floppy for some versions. The collection is
regularly updated with new tapes and files pulled from cu20b direct. For
details mail to Alan Phillips, SYSKERMIT @ LANCS.VAX1 (JANET address
000010404000.FTP.MAIL, or PSS address 23425240101.000010404000.FTP.MAIL), or
phone [phone] x 4881. Distribution is free to all educational
establishments: a small handling charge is made to commercial users.

------------------------------

End of Info-Kermit Digest
*************************
-------
20-Sep-85 17:58:08-EDT,14460;000000000001
Mail-From: SY.FDC created at 20-Sep-85 17:57:35
Date: Fri 20 Sep 85 17:57:35-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #20
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 20 Sep 1985       Volume 3 : Number 20

Departments:

  ANNOUNCEMENTS -
    Kermit Available for Os9
    Commodore 64 Kermit V1.7 Available
    NEC APC III Kermit Available

  IBM MAINFRAME KERMIT -
    CMS Kermit Server Logout Problem Solved
    CMS Kermit 2.01 Init File Problem

  MISCELLANY -
    Kermit Diskette Distribution
    Kermit Diskette Distribution in UK
    Kermit-11, P/OS, and TMS
    Problem with C-Kermit on IS 68000 Q-Bus System with 4.2BSD
    C-Kermit on Xenix on PC/AT?
    C-Kermit for SUN on 1/4" Tape Cartridge?
    MacKermit Beware Addition
    Apple Kermit & CCS Card
    Kermit as Mail Server?
    Kermit for Victor 9000?
    Octopus / Flex Kermit?

----------------------------------------------------------------------

Date: Wed 18 Sep 85 00:57:23-PDT
From: [e-mail]
Subject: Kermit Available for Os9

Os9 kermit is ready for distribution.  It is based on old Unix Kermit, and
also has limited server functions.  Read the .doc, .hlp, and .bwr files for
known limitations.  (It should work on all os9 versions, but connect mode
has a problem with the CoCo bit banger port.)

I am willing to make a "s" format (hexadecimal) file available, but due to
numerous compile time options, its usefulness would be limited.

Bob Larson <[e-mail]>
UUcp:  ihnp4!sdcrdcf!oberon!blarson

[Ed. - The files are available for anonymous FTP from CU20B as KER:OS9*.*.]

------------------------------

Date: 8 Aug 85 10:02:53 EDT
From: Eric <[e-mail]>
Subject: Commodore 64 Kermit V1.7 Available

C64 Kermit V1.7(52) is ready for release. The new edits are bug fixes to the
command parser that screwed up the disk commands, a fix to make 1200 baud
file transmission work at a full 1200 baud, and a fix to the ASCII/PETSCI
conversion tables. All fixes were done by Frank Prindle (Prindle@NADC).

------------------------------

Date: Thu 19 Sep 85 18:40:42-PDT
From: Ronald Blanford <[e-mail]>
Subject: NEC APC III Kermit Available

Here is the MSXAP3.ASM module for the NEC APC III.  I have only used this
briefly once, but as far as I can tell it does not implement keyboard
redefinition, does not implement any type of terminal emulation, and only
works with the standard serial port.  Terminal mode does not have backward
paging.

The author is RAL from Virginia Polytechnic Institute, more than that I
don't know.

-- Ron

[Ed. - Thanks, Ron.  The source file is in KER:MSXAP3.ASM on CU20B.]

------------------------------

Date: Tue, 17 Sep 85 00:19:12 EDT
From: Peter DiCamillo <CMSMAINT@BROWNVM>
Subject: CMS Kermit Server Logout Problem Solved

I think I've figured out why CMS Kermit doesn't log itself out correctly
through a Series/1 or 7171.  There are two problems.  First, when CMS
Kermit sends an ack to the logout or finish command, it uses transparent
write/read, as if it expected a response.  The micro doesn't send a
response, which I believe matches the Kermit protocol, so the user
has to complete the read.  The following update to CMS Kermit corrects
this problem by sending the final ack with just a transparent write:

./ R 00846000       $ 846290 290                   09/16/85 22:44:58
         DC     X'40',AL1(SBA),X'5D7F',AL1(SBA)             UPDATE1  00846290
S1ORDAD  DC     X'0001'             addr. -> 0 for write    UPDATE1  00846580
./ I 01601000       $ 1601500 500                  09/16/85 22:44:58
         XC     S1ORDAD(2),S1ORDAD  just write when ending  UPDATE1  01601500
./ I 02869000       $ 2869300 300                  09/16/85 22:44:58
         CLC    S1ORDAD(2),=H'0'    was write/read done?    UPDATE1  02869300
         BE     SPRET               no: return now          UPDATE1  02869600

             ^
[Ed. - I've removed some spaces so this will fit on the screen.]

The second problem affects only the logout command.  Before issuing the CP
LOG command, CMS Kermit uses the sequence of WRTERM and WAITT to send an XON
to the micro and wait for the write to complete.  However, if the console is
a Series/1 or 7171, CMS Kermit's own console interrupt handler is still in
control, so CMS hangs when the WAITT is executed.  Also, to send an XON in
this case would require another transparent write, since WRTERM cannot send
control characters through a full-screen interface.  The following update
solves this problem by bypassing the calls to WRTERM and WAITT for Series/1
and 7171 connections.  It seemed safe to skip them since they weren't
working in this case anyway.

./ I 01607000       $ 1607300 300                  09/16/85 22:44:58
         TM     S1FLAGS,ISS1        Is console a S/1?       UPDATE2  01607300
         BO     SERVLOG             Yes: skip line mode I/O UPDATE2  01607600
./ R 01611000       $ 1611490 490                  09/16/85 22:44:58
SERVLOG  LA     1,=C'LOG'                                   UPDATE2  01611490

These updates are for CMS Kermit Version 2.01, and assume serialization
starting at 1000 with an increment of 1000.  I've tested them with success
on both a Series/1 and a 7171.

Peter

[Ed. - Thanks, Peter -- I've included your message in CMSMIT.BWR until the
next release comes out.]

------------------------------

Date: Wed, 18 Sep 85 9:11:17 BST
From: Andrew J Cole <[e-mail]>
Subject: CMS Kermit 2.01 Init File Problem

CMS Kermit 2.01 works very well with one small exception (non-feature?).
If server mode is entered directly from the CMS command line Kermit seems
to fail to read the KERMINI files.

Many thanks for such a useful system for a real pig of a system!

[Ed. - Thanks for the report; it's been added to the .BWR file.]

------------------------------

Date: Tue, 17 Sep 85 11:47:16 EDT
From: [e-mail]
Subject: Kermit Diskette Distribution

I'd be willing to distribute Macintosh Kermit at RPI if you send me a copy
on diskette. There aren't many Macs at RPI, but there are a few. We support
Kermit on several mainframes on campus, and distribute it for IBM PCs and
some compatibles.

  Don Porter
  Assoc. Dir., Information Technology Services

[Ed. - I got a lot of responses like this to my query about Kermit diskette
distribution.  I guess I wasn't clear enough...  What I'm looking for are
organizations or individuals willing to distribute Kermit on diskette in some
particular format to the general public, e.g. by mail order, not just within
their own organizations.  I haven't received reports of any of these.  Can
anyone tell me about, say, Heath or Atari or Apple or ... user groups that
provide this kind of service, like PC SIG does for the IBM PC?]

------------------------------

Date: 19-SEP-1985 11:17:29
From: [e-mail]
Subject: Kermit Diskette Distribution in UK

  Lancaster University is able to distribute some KERMITs on native media. We
can currently handle Aculab Z80B, Sirius 1 (CP/M-86 and MS-DOS), BBC micro,
DEC Rainbow (CP/M-86) and IBM PC. We also maintain a freely accessible
contact list of other UK native media suppliers for machines we don't have,
and can broadcast enquiries to the UK Kermit community at large.
  Distribution is free in the UK to educational users, but there's a small
handling charge for others: we don't supply the discs ourselves. Interested
users should contact me BEFORE sending discs, to check availability.
  The service is one person, so response might be a few weeks, especially if I
have to pass discs on to others who actually own the machines.
  We are willing to co-ordinate supply in the UK : anyone who wishes can be put
onto our contact list if they let me have details.

              Alan Phillips
                Department of Computing
                  Lancaster University UK

E-mail to     SYSKERMIT @ LANCS.VAX1
JANET address 000010404000.FTP.MAIL
PSS   address 234252400101.000010404000.FTP.MAIL
Telephone  to 0524-65201x4881

(I cannot reply over UUCP and only unreliably over ARPA)

------------------------------

Date: 18 SEP 85 12:11-EST
From: [e-mail]
Subject: Kermit-11, P/OS, and TMS

I may interest you to know that someone is adding to Kermit-11 for P/OS
to support TMS.  I, as is often the case, will be unable to test such as
I do not hav TMS on the PRO but it does sound like the mods to Kermit-11
should be quite minimal.

brian

------------------------------

Date: 18 Sep 1985 1046-PDT (Wednesday)
From: Paul Graham <unr70!unrvax![e-mail]>
Subject: Problem with C-Kermit on IS 68000 Q-Bus System with 4.2BSD

A nearby site using an Integrated Solutions (IS) q-bus 68000 board under
4.2bsd has been unable to get Kermit to open the phone line.  Monitoring the
line shows behavior similar to cu and tip when the the line is first opened
(some lines are pulsed briefly) but after that kermit hangs.  It works in
remote mode just fine.  Anybody out there using an IS system successfuly?

Thanks for your time.

Paul Graham 702/784-6007
University of Nevada Reno
ucbvax!decvax!seismo!unr70!unrvax!pjg
unr70!unrvax!pjg@seismo[.CSS.GOV|.ARPA]

[Ed. - There seems to be a lot of this going around, see below...]

------------------------------

Date: Fri, 20 Sep 85 15:15:11 edt
From: [e-mail] (Young Etheridge)
Subject: C-Kermit on Xenix on PC/AT?

Am encountering problem with "connect".  After connecting /dev/tty00
to a null-modem line, then "set line /dev/tty00" followed with
"set baud 4800" then "connect", results in a deadly silence thereafter.

The communications channel is okay since "cu" works as advertised.

[Ed. - Can anyone who has this working offer some tips?]

------------------------------

Date: Mon 16 Sep 85 13:41:12-EDT
From: Frank da Cruz <[e-mail]>
Subject: C-Kermit for SUN on 1/4" Tape Cartridge?

Anyone willing to provide a working C-Kermit program for the SUN with 4.2BSD
on quarter-inch tape cartridge, please contact

    Peter Hiscocks
    416-979-5000 x6109
    Center for Advanced Technology (Ryerson Polytech), Toronto

------------------------------

Date: 19 Sep 85 20:05:07 CDT (Thu)
From: ihnp4!islenet![e-mail]
Subject: MacKermit Beware Addition

Minor addition to your Mackermit BWR file: when a Settings file is saved,
it does not store the Command-Shift-1...Command-Shift-9 flag, so we have
to set it every session if we want it active.

[Ed. - Thanks, I've added it.]

------------------------------

Date: Fri, 20 Sep 85 11:19:17 BST
From: Chris_K_Now-and-Then <[e-mail]>
Subject: Apple Kermit & CCS Card

     This note has circulated in UK.  It's obviously of general interest,
so I send if on to you.
                        Chris Kennington.
  Date: Wed 18 Sep 85 19:40:36-GDT
  From: Alan Greig <[e-mail]>
  Snail-Mail: Computer Centre / Dundee College of Tech / Dundee / Scotland

On the subject of Kermit for various Apple serial cards, the most notable
ommision (to my mind anyway) is the lack of support for the California
Computer Systems Card (CCS) which seems to be almost universely used in the
UK. At DCT we added support for this card to the sources and as we have
CROSS can provide hex files with this change. The original changes were made
by Colin Bruce ([e-mail]) who has now left to work with Data
General and involve only a few additions to some tables. The only known bug
is that the the card needs to be specifically reset by sticking some value
in its command register before running Kermit. (PR#n,IN#n RESET will do
this). This initialisation could/should really be inside apple kermit but
I've never got round to recompiling it.

Anyway it works and if anybody wants it let me know or I can send down
the changes to Lancaster.

            Alan Greig
             ([e-mail])

------------------------------

Date: Thursday, 19 September 1985  10:05-MDT
From: <crash![e-mail]>
Subject: Kermit as Mail Server?

I've seen several messages lately about people allegedly using Kermit as a
mail gateway to Unix systems.  Do you know how that is being done?  Seems
like there would have to be a lot more Kermit than I've ever seen to
accomplish it.  The implications are that of an almost uucp-like server.

Enlighten me, please?

--Bill

[Ed. - It is possible to run a Unix Kermit server as a login shell; OK
State is doing this.  Presumably, you can then have other systems dial it
up, transfer queued mail to it, and then issue the appropriate "remote
host" command to it to deliver the mail.  I don't know if anyone is actually
doing this -- is anyone???  However, I have heard of Kermit servers being
used as print spoolers, etc.]

------------------------------

Date: Friday, 13 September 1985  14:40-MDT
From: hao!nbires!isis!galon![e-mail]
Subject: Kermit for Victor 9000?

A friend has a Victor 9000 and is trying to talk with some IBM PC's.

I've been trying to get him a suite of Kermit Programs but todate have
been unsuccessful.  A tape won't do him any good and I haven't found
it on floppies.  I did locate it at Okstate, but was unable to pull it
using their uucp instructions either in kermit-a or kermit-b
directories.

Anyone knowing of or having a copy please contact me via email.

Thanks.

Pat Gallivan @                   UUCP: ..!seismo!hao!nbires!isis!galon!fmg
Galon Exploration, Inc.
7122 S. Fillmore,                       [phone]
Littleton, CO  80122             Data:  [phone]

------------------------------

Date: Tue, 17 Sep 85 17:26:34 BST
From: Chris_K_Now-and-Then <[e-mail]>
To: [e-mail]
cc: [e-mail]
Subject: Octopus / Flex Kermit?

Kermiteers:
     Anyone working on Kermits for either Octopus or Flex
machines?  Both wanted in the UK.
     Reply to "cjk@ucl-cs", a valid arpanet address.
                                        Chris Kennington

------------------------------

End of Info-Kermit Digest
*************************
-------
24-Sep-85 17:48:54-EDT,18487;000000000000
Mail-From: SY.FDC created at 24-Sep-85 17:48:17
Date: Tue 24 Sep 85 17:48:17-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #21
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 24 Sep 1985       Volume 3 : Number 21

Departments:

  ANNOUNCEMENTS -
    Kermit for QNX
    Kermit for Intel System 86/380 with iRMX-86
    Kermit for HP-1000 A-Series with RTE-A
    Kermit for Zilog System 8000 Zeus (Sys V)
    Kermit for the HP Integral PC
    Update of Fujitsu Micro-16s CP/M-86 Kermit

  UNIX KERMIT -
    Kermit for UUCP Mail
    Changes to C-Kermit 4C(057)
    Bug Fix for C-Kermit User Interface
    C-Kermit on Masscomp Systems?

  MS-DOS KERMIT -
    Problem with Sanyo 555 Kermit
    MsKermit Linking Idea

----------------------------------------------------------------------

Date: Mon, 23 Sep 85 13:14:33 edt
From: Frank da Cruz <fdc@cucca>
Subject: Kermit for QNX

A version of Kermit for the Quantum Software QNX operating system has been
contributed by Anthony J. Starks, Merrell Dow Research Institute,
Indianapolis IN; although he doesn't mention what system it's supposed to
run on in his transmittal letter, I believe it's for 8088-based systems like
the IBM XT or AT and/or the DEC Rainbow.

The program based on the "old" Unix Kermit, but the QNX-specific support is
sufficiently different from any other Unix code I've seen that I've
installed it as a separate set of files, rather than attempting to merge it
with C-Kermit.  The files are in KER:QNX*.* on CU20B, available via
anonymous FTP.

------------------------------

Date: 23 Sep 85 13:44:04-EDT
From: Frank da Cruz
Subject: Kermit for Intel System 86/380 with iRMX-86

This is to announce Kermit for the Intel System 86/380 running iRMX-86,
written by Albert J. Goodman, Grinnell College, Grinnell, Iowa.  The program
is written in PL/M-86.  The source files (including built-in help) are
concatenated together into the file KER:I86KER.PLM, and a short external
help file is included as KER:I86KER.HLP, available from CU20B via anonymous
FTP.

------------------------------

Date: Mon 23 Sep 85 13:46:33-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit for HP-1000 A-Series with RTE-A

Announcing Kermit for the HP-1000 A-Series with RTE-A, written in
Pascal/1000, contributed by Tor Lillqvist, Technical Research Centre of
Finland.  Here is his cover letter:

This is a Kermit implementation for the HP1000 A-series machines running the
RTE-A operating system (HPAKermit). It will probably also work on the older
E-series machines running RTE-6/VM.

The file HPAKERMIT.SRC is a large text file into which is merged all the
source files needed to build HPAKermit (just to keep the number of files
down).

HPAKermit is written in the Pascal/1000 dialect. (A note to Pascal purists:
this has many "useful extensions" which makes it more suitable to "Real
Programming", but of course removes any chance of an easy port to some other
Pascal system.) I would certainly prefer 'C', but the 'C' compiler for
HP1000 seems rather oldfashioned, and in any case, we don't have it.
HPAKermit must be compiled with the Pascal/1000 compiler of revision 2410
(or later).

HPAKermit is based on the (old) Unix Kermit, and has only basic features
(Send, Receive and Get). Connect mode is missing, as it is very hard, maybe
impossible, to implement successfully on a HP1000. Server mode is also
missing, but that is only a "Not-Yet-Implemented" issue.

HPAKermit has been tested extensively with MSDOS-Kermit version 2.27 and
HP3000 Kermit.  Using 9600 bps and an IBM PC/XT a transfer rate of 470
chars/s is achieved.

Best regards,

Tor Lillqvist
Technical Research Centre of Finland
Lehtisaarentie 2 A,
SF-00340  HELSINKI, FINLAND

Phone:  [phone]
Telex:  122972 vttha sf

I have no net address, but you can reach me through a friend of mine:
mcvax!hut!jtv

[Ed. - The files are in K2:HPA*.*, available via anonymous FTP.]

------------------------------

Date: Mon, 23 Sep 85 12:43:29 edt
From: Frank da Cruz <fdc@cucca>
Subject: Kermit for Zilog System 8000 Zeus (Sys V)

I received a tape from Mark E. Sunderlin, Internal Revenue Service,
containing C-Kermit 4C(057) revised to include support for the Zilog System
8000 with Zeus 3.20 and later.  This will appear in the next release.
Meanwhile, if anyone can't wait, the trick seems to be to build it for
System III/V ("make sys3") in the normal way, but first change all
occurrences of "setjmp" to "setret" and "longjmp" to "longret".  This might
be accomplished in the makefile without changing the program source by doing
something like...

zilog:
    make wermit "CFLAGS = -DUXIII -Dsetjmp=setret -Dlongjmp=longret -i" \
    "LNKFLAGS = -i -w"

(and also including -DDEBUG, -DTLOG, -O if desired); no one has tested doing
it this way, but the same trick works for some of the other systems.

------------------------------

Date: Mon, 23 Sep 85 12:43:29 edt
From: Frank da Cruz <fdc@cucca>
Subject: Kermit for the HP Integral PC

I received a tape from Robert Raymond of TransEra Corp, Provo Utah, with a
version of Kermit for HP Integral PC.  It's based on the old Unix Kermit,
but a cursory inspection of the code suggests that he's simply added System
V support to it.  Can anyone verify that the present C-Kermit runs on the HP
Integral via "make sys3"?  If so, I'll simply include that system on the
list of those supported by C-Kermit; if not, I'll be glad to make Robert's
code available to anyone with an HP Integral who would like to adapt it to
the current C-Kermit.

------------------------------

Date: Mon, 23 Sep 85 12:43:29 edt
From: Frank da Cruz <fdc@cucca>
Subject: Update of Fujitsu Micro-16s CP/M-86 Kermit

This fixes an error in baud rate setting/selection.  Submitted by the
original contributor, Chris Barker, WRIST Inc, Long Island City, NY.  The
source file is in KER:C86XFJ.A86.  Would anyone on the net would care to
build and test the result and supply a hex (.H86) file?

------------------------------

Date: Sat 21 Sep 85 14:35:52-EDT
From: Bdale Garbee <[e-mail]>
Subject: Kermit for UUCP Mail

I haven't finished doing it yet, but I am one of the people using/planning
to user Kermit on a UUCP host to move mail to other places.

The system in question is an Intel 86/330 running Xenix V2.2N, currently
working on getting implementation-specific bugs out of the latest C-Kermit.
More details when I'm done.

The idea is very simple.  Just create a user on the Unix/Xenix system named
something like 'kserver'.  Then build a .login or .profile for that user in
that user's home directory that fires up kermit in server mode, and then
terminates the process and hangs up when kermit exits.  A remote machine
that wants to do file transfer, either of UUCP mail or anything else, just
dials in, logs in as user kserver, and issues the appropriate kermit server
commands.  When done, he issues a server terminate command, which causes
Kermit on the Unix box to exit and kill the process... which should also
hang up the phone.

Using cron and shell scripts makes for easy packing and unpacking of bundles
of mail to/from the UUCP mail directory.  The remote system just has to have
a similar sort of batch facility to use to do the dialup.

Bob Hartman of ...!vaxine!spark!bob fame is using this technique to
implement a UUCP/Fidonet bridge.  I'm working on duplicating and then
expanding his work.  Will pass along details when it works, and would
be most interested in talking to other people who have this sort of
thing working, or want help on making it work...

Bdale Garbee
arpa: [e-mail], soon to be [e-mail]
uucp: ...allegra!pitt!rensys!bdale

[Ed. - Thanks for the news.  You may be interested in a customized Unix
Kermit server that they run at OK State as a login shell if you dial a
certain number -- have you been in touch with them...
vasoll%okstate.csnet@csnet-relay?  Of course, none of this addresses the
real questions of mail since (I assume) you're just sending mail in batch
mode and not control information in interactive messages, like SMTP would
do.  How do you handle the various situations that SMTP or UUCP would
handle, like bad routing information, can't connect to host, no such user,
etc etc?]

------------------------------

Date: Mon, 23 Sep 85 14:06:51 pdt
From: Ken Poulton <hpl-opus![e-mail]>
Subject: Changes to C-Kermit 4C(057)

[Ed. - Ken Poulton has submitted code for the following changes to C-Kermit.
Some of them are obviously desirable, some are in "sensitive" areas (where
opinions are divided); I'd like to solicit a concensus in these areas, if
possible.]

Fixes for HP 9000:
    added "make s500" which does the things formerly listed in the make file
    added code to disable HP's enq-ack handshaking (#ifdef IENQAK) in connect

Connect:
    changed use of XON/XOFF slightly (now it works like BSD, and better
    with HP terminals)

Set Handshake:
    now turns off XON/XOFF (-t already does this)

!
    merged ! and other uses of fork to call new routine zexecl in ckufio
    zexecl does an exec, using 1) the shell defined by environment variable
    SHELL, if any, or else 2) the user's login shell from /etc/passwd, or
    failing that, 3) /bin/sh.

[Ed. - I guess this is better than the current method, which ignores the
SHELL variable because some Unix systems do not set it automatically.]

control chars
    added conchr to ckutio and changes in ckucmd to support using the
    user's predefined control characters as he expects
[Ed. - Seems like a good idea, assuming the method used works for the
systems the program tries to support.  For Sys III/V, it does
ioctl(0,TCGETA,&x), and then sets the interrupt, character delete, and
line delete characters to x.c_cc[0], x.c_cc[2], and x.c_cc[3] respectively;
for all others it does gtty(0,&x) and ioctl(0,TIOCGETC,&y), and sets
interrupt, chardel, linedel to y.t_intrc, x.sg_erase, and x.sg_kill.  In
the first case, x is a struct termio; in the second, x is a struct sgttyb
and y is a struct tchars.  How many systems will this break?]

    added code for VENIX11 to turn off driver's recognition of these
    characters.  Most Unices (BSD, SysIII, etc) do this anyway in raw mode.

[Ed. - I've heard reports about this before, but never saw this behavior
in Pro/Venix, which I thought was the same.]

prompt
    settable with -DPROMPT=

startup files
    1) ./.kermrc   2) ~/.kermrc   3) /usr/local/lib/kermrc
    settable with -DKERMRC (as before) and -DSYS_KERMRC
    Note that order of first two is intentionally changed

[Ed. - This looks like a touchy one.  First, it might be argued that most
people would like the program to behave consistently, no matter what
directory you're connected to.  Second, if there is to be a "system-wide"
startup file, does everyone agree that it should be in /usr/local/lib?
Third, the program searches for the startup file as above, and executes the
first one it finds.  Maybe it should execute all of them?  If there is to
be a system startup file, should the program ALWAYS execute it?  Should
there be user-selectable options to specify the order in which startup files
are executed, and how many???  How to explain all this to users?]

eXIT command
    added eXIT command - allows leaving Kermit w/o unlocking or dropping line
    added ttnohu to close the tty w/o hangup
    creates ~/UNLOCKttyxx to remind user
    EXIT deleted to avoid confusion
    (maybe this should be disabled on BSD systems as not needed)

[Ed. - This is the most controversial area of all.  First of all, case-
sensitive commands are not in the spirit of Kermit.  Second, giving the
user the power to lock a line permanently might be fine on a small friendly
system, but not on a big one with many users.  The risk of a user leaving
a line locked (intentionally or not) is much higher with this method, and
the inconvenience to other users must be weighed against the advantages
of doing this.  Opinions?  (Here we go again...) ]

scripts
    commented out most of the messages
    user can use echo to write messages if he *wants* to

[Ed. - Opinions from script command users?]

#
    added comment command
    for documenting scripts
    (done with % by 4C(057))

[Ed. - I used "%" for this to avoid confusion with shell scripts.]

locking
    now accepts existing lock files owned by the user (to support eXIT)

[Ed. - This is probably not a bad idea, when it works...  But some sites
keep the locks directory write-protected (or even read-protected), and
other sites want to run Kermit, UUCP, CU, TIP, etc, set[ug]id'd, so there's
no good way to tell for sure whose lock file it is.  I truly believe that
"lock files" are the WORST thing about Unix...  It continues to amaze me
that the system was designed NOT to give exclusive access by default to
serial devices automatically upon open().]

VOID
    defined to null for V7, "(void)" for all others to avoid all the
    V7 ifdefs

[Ed. - I thought I had removed all those (void)s; they were just there for
lint's benefit, but I guess a couple are still there (in ckutio.c and
ckuus3.c); they should go too.]

-g rfn -a name
    changed ckcfns.c to try treating "-a name" as a directory name
    bug: zopeno gives an err msg if the name is a directory
[Ed. - This is a little tricky, not sure it's worth it...]

logging
    added better debug and transaction messages to clsif and clsof in ckcfns.c
[Ed. - Good messages are always nice.]

get
    fixed to strip newline off of -a name in take script
[Ed. - Obviously desirable.]

------------------------------

Date: Sat, 21 Sep 85 21:28:25 PST
From: !![e-mail]
Subject: Bug Fix for C-Kermit User Interface

We just got a new giant Amdahl machine, running the System V flavor of UTS.
So far, its only connection to the world is through 9600 baud lines.
Needless to say, my first order of business was building C-Kermit on it,
followed by Compress, followed by most of my files (it also has mucho disk).
It went mostly OK, though the lintish feature of the UTS C compiler fussed a
bit.  That's not the story for today, though.  While sending files to UTS, I
got fed up with Kermit's habit of double-spaceing between lines of dots.

I decided to fix it while waiting for the transfer.  The context diff below,
for ckuus3.c, is the result.  The problem arose from some confusion over
whether "p" was the position of the last character or of the next character
to go into the buffer.  I tried to make everything consistant.  My rules
were as follows: 1) "p" is the zero-based position of the next character to
be put on the line, 2) It is each message type's responsibility to determine
if there is enough space for it, and to leave "p" pointed at the next
available space when it is done.  I also parameterized the line length, and
set it to 79 for our C-Kermit, so terminals with linewrap won't.

[Ed. - diffs omitted, but will be included in next release.  Kermit was
also brought up recently on our own UTSV system, and worked ok, except for
some cosmetic problems with command echoing, which I think we can fix.]

------------------------------

Date: 23 Sep 85 16:34:00 EDT
From: STEVE KABERLINE <kaberline@ford-vax>
Subject: C-Kermit on Masscomp Systems?

Can you tell me, please, who is/has been working on the Masscomp specific
implementation of Unix Kermit?  I have a few comments/suggestions I would
like to forward (A network address, if available, would be nice) to them.  I
recall, at one time, seeing a list on CU20B of who-is-doing-what as far as
Kermit work goes, is there still such a file I can ftp over and look at?

[Ed. - I've lost the specific reference, but have had reports that Masscomp
systems can run the current release of C-Kermit just fine, when built with
"make sys3".  Anyone know otherwise?]

------------------------------

Date: Fri 20 Sep 85 21:39:02-EDT
From: Andy R Raffman <EN4.AR-RAFFMAN@CU20A>
Subject: Problem with Sanyo 555 Kermit

I thought that I should tell you that I have tried the new Kermit 2.28 for
the Sanyo 555, and it has a bug: the backspace key does not move the cursor
back or erase the previous character in command mode.  Given that many of
the other improvements in Kermit haven't helped the Sanyo version much (no
H-19 or VT-100 emulation, no set key, no mode line), unless you have fixed
some larger bugs in v.2.26 (I know that the log function doesn't work right),
you might consider going back to it until the backspace bug is fixed.

[Ed. - If any Sanyo users out there have a fix for this, please let us know.]

------------------------------

Date: Mon, 23 Sep 85 23:48:58 PDT
From: [e-mail]
Subject: MsKermit Linking Idea

The following is the relevant part of a response in our local electronic
conference (*Forum) which I think may be of interest to part of the Kermit
community.

2723. MTS Kermit Now Available
      Bruce Jolliffe          16:23 Mon Aug 13/84

2723/60. CORRIE KOST          21:16 Mon Sep 23/85      12 lines

   I would like to suggest that all versions of KERMIT be linked
   with Microsoft's LINK version 3.XX, so that they can be packed
   with Microsoft's EXEPACK utility.  This procedure can cut the
   size of the .EXE file by up to 50 %, and the .EXE file is still
   directly runnable from MS-DOS (...and it loads faster, too)
   Note that EXEPACK will produce garbage (no warning !) if you
   try to pack a file linked with LINK version 2.XX, or the
   default IBM-PC linker supplied with PC-DOS 3.0 and PS-DOS 3.1

                                  - Ya'akov

[Ed. - Does anyone know if a thus-packed file can be run transparently
under earlier versions of DOS?  Also what would the expected savings be
on a program like MS-Kermit 2.28, which has got rid of most of its static
buffers and does memory allocation at runtime?  Any other pitfalls to be
wary of?]

------------------------------

End of Info-Kermit Digest
*************************
-------
 7-Oct-85 18:50:21-EDT,20104;000000000000
Mail-From: SY.FDC created at  7-Oct-85 18:49:38
Date: Mon 7 Oct 85 18:49:38-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #22
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Mon, 7 Oct 1985       Volume 3 : Number 22

Departments:

  MISCELLANY -
    Half-Duplex Windowing vs Long Buffers
    Use of Kermit by the Blind (Several Messages)
    Hint for VMS Binary File Transfer using Kermit

  UNIX KERMIT -
    Ken Poulton's C-Kermit Changes (Several Messages)
    C-Kermit Works on HP Integral Kermit
    C-Kermit EOF Bug
    C-Kermit Does Not Compile on AT&T 3B20 SysVR2 - And the Fix
    Masscomp Kermit
    TI NU Machine Kermit
    Bug in C-Kermit Remote Commands under VAX/VMS

----------------------------------------------------------------------

Date: Thu, 3 Oct 85 19:35 EDT
From: [e-mail]
Subject: Half-Duplex Windowing vs Long Buffers

Is everyone agreed that in half-duplex windowing, the EOL character should
not be sent until the end of a group of packets?  If an EOL character is
sent after each packet, my 370 TSO and WYLBUR systems will require some
delay before the next packet is sent.  Otherwise following packets will be
lost.  Also, if a packet received in error results in a parity error (likely,
but not certain), the resulting error message from the system will cause
the following packet to be obliterated also.  For my systems, I think it is
best not to send an EOL until the end of a group of packets.

However, if the EOL is not sent until the end of a group, there is another
problem which may be common to systems that check incoming parity.  Since
the whole group of packets is considered to be one "line" by the system,
an error in any packet that also results in a parity error (highly likely,
although not guaranteed), will cause the entire line (group of packets)
to be discarded.  Thus the half duplex windowing scheme results in extra
overhead for multiple packets per "line" with little corresponding benefit
in reduced retransmission when compared to the big packet proposal.

Therefore I prefer big buffers to half-duplex windowing.


                                 Roger Fajman <[e-mail]>
                                 Computer Center
                                 National Institutes of Health

[Ed. - Last chance to get your comments in...  The tide of opinion seems to
be favoring long packets, distinct from sliding windows.]

------------------------------

Date: Tue 1 Oct 85 14:17:51-EDT
From: Frank da Cruz <[e-mail]>
Subject: Use of Kermit by the Blind
To: [e-mail]
cc: [e-mail], [e-mail]

I've had a call from Kenneth Reed at NASA in Greenbelt, MD (phone [phone])
asking how Kermit can be used effectively by blind people.  Back in the days
when computers had terminals, you could put a device like a Votrax or DECtalk
or whatever between the terminal and the computer, and it could try to speak
the letters and numbers, or words, as they went by.  But microcomputers don't
generally have a place to attach such a device.  Kenneth says his Apple II
has a special card that somehow gets characters just before they're about to
be put on the screen and presumably can transmit them to a speaking device,
but that's just for the Apple.

I'm sure there has been a lot of discussion about this elsewhere, but I must
have missed it.  How can blind people use microcomputer applications in
general?  Obviously, graphics-oriented stuff is mostly out (and therefore,
presumably, also the Macintosh).  In MS-DOS, maybe there are console drivers
that can intercept characters, strip out (or interpret) formatting information,
and send the text out the serial port to, say, a Votrax, or maybe there are IBM
PC boards that "speak the screen" directly.  Anyhow, Kenneth's department is
selecting microcomputers and he'd like to see them pick one that text oriented
applications (like Kermit) can be adapted to give comprehensible audible
output.  If you have any information, please post it and also give Kenneth a
call at the number listed.

By the way, the way the Kermit file transfer display is done is important here.
On MS-DOS systems, a "form" is put up on the screen at the beginning of the
file transfer, and then numbers and messages are filled in and updated
randomly throughout.  If one were to read this stuff in sequence as it appeared
on the screen, it would be a pretty confusing jumble.  Also, you'd need a
pretty fast talker at high baud rates...  The serial output of local-mode Unix
Kermit or DEC-20 Kermit would be a lot more comprehensible when interpreted
by a voice device.

------------------------------

Date: Wed, 2 Oct 85 06:21:51 MDT
From: [e-mail] (Henry M. Halff)
Subject: Re: Use of Kermit by the Blind
References: <[e-mail]>

Let me suggest that your friend contact the following firm.

    Talking Computers, Inc.
    6931 North 27th Road
    Arlington, VA 22213
    703-241-8224

The fellow that runs the firm is Doug Wakefield.  His business is putting
speech synthesizers on computers for blind people.  He pretty much specializes
in IBM PC's, but he might be able to help with Apples.  The software that he
uses should have no problem with a screen display like Kermit's since the
user can, at any time, get a readout of the entire screen or any line
on the screen.

Hope this helps.

Henry M. Halff
Halff Resources, Inc.
[e-mail]

------------------------------

Date: Sat, 5 Oct 85 10:28:24 mst
From: Kelvin Nilsen <[e-mail]>
Subject: Kermit for the Blind

[Ed. - This is from the author & proprietor of VersaCom, a communication
program that includes Kermit.]

versacom does not run windows!  all i/o to the terminal is serialized through
the bios, write tty (except of course when it comes to terminal emulation).
this makes it possible to run versacom on a pc from a terminal and connect
to another system to transfer files.  for example:


      vt100                   dumb tty emulation
    +-------------+             +---------+            +----------+
    |home terminal|- 1200 baud -|office pc|-19200 baud-|office vax|
    +-------------+             +---------+            +----------+

xon/xoff handshaking is supported on both ports, in both directions and works
independently.  the amount of information reported by file transfers can be
each packet, or each file transfered.

anyway, this capability makes possible two solutions to the problem you
mentioned.  first, attach a votrax-type terminal to one of the com ports
of the pc.  second, modify versacom to send bios tty output to an internal
voice synthesizer instead of or in addition to the bios tty output.

kelvin nilsen

------------------------------

DATE: October 07, 1985 11:29:44 EDT
FROM: [e-mail]
SUBJECT: TERMINAL FOR THE BLIND

WE ARE TRYING SEVERAL DIFFERENT PRODUCTS FOR THE BLIND HERE AT VA. TECH
ONE IS A PACKAGE ON THE IBM PC CALL ED FREEDOM. VERY NICE PACKAGE.
WORKS OUTSIDE OF ALMOST ANY OTHER PACKAGE ON THE PC. WE USE THE TERM
EMULATOR YTERM WITH IT NO PROBLEMS.
WE ALSO USE THE AUDIOTRONICS TALKING KEYBOARD FOR THE PC. HAVING SOME
SPEED INTERFACE PROBLEMS. QUESTIONS CALL 703-961 5961.

------------------------------

Date:  5 Oct 1985 1454-PDT (Saturday)
From: [e-mail] (William Randy Day)
Subject: Re: Use of Kermit by the Blind

I am part of a research project here at the University of Washington aimed
at developing software for deaf-blind (both deaf and blind) users.  The
presentation problem is severe. As you say, graphics-oriented software is
out.  As you describe in you posting, even ``non-graphics'' programs like
kermit can prove incomprehensible if a straight screen output to speech
translation is made. We have come to the conclusion that a simple
hardware/software translation unit sitting on top of normal software is
inadequate, particularly for our severely handicapped target group. We have
taken the custom software approach.

Randy Day.
UUCP: {decvax|ihnp4}!uw-beaver!uw-june!randy
ARPA: randy@washington
CSNET: randy%washington@csnet-relay

------------------------------

Date: 3 Oct 85 17:20:20 GMT
From: [e-mail]
Subject: Hint for VMS Binary File Transfer using Kermit

If one has two VMS Vaxes connected together with RS-232 ports, binary files
will transfer OK, using 8-bit data.  The catch is that Kermit cannot possibly
be taught about all of the wild and wonderful RMS file formats (how many are
there?  1.0e10?), so making a BACKUP set (which contains the RMS formats) and
transferring it via Kermit will work fine.  Do a SET FILE TYPE FIXED in the
Kermits at both ends.  This allows .EXE files to be transferred directly, and
BACKUP save sets to be transferred and read from after fixing up the block
size.

------------------------------

Date: Wed, 25 Sep 85 11:38:25 pdt
From: hpl-opus![e-mail]
Subject: More Kermit Changes Comments

> -g rfn -a name
>     changed ckcfns.c to try treating "-a name" as a directory name
>         bug: zopeno gives an err msg if the name is a directory,
>                  even though it works.
> [Ed. - This is a little tricky, not sure it's worth it...]

It is consistent with other file transfer facilities such as uucp (and I
*needed* it for that reason).  The code *is* a bit messy because I didn't dare
change the machine-dependent primitives like zopeno (I can't write or test new
VMS or Mac versions).  I think adding an argument to zopeno will allow having
it do this operation (if appropriate for that opsys).

> eXIT command
>
> [Ed. - This is the most controversial area of all.  First of all, case-
> sensitive commands are not in the spirit of Kermit.  Second, giving the

The typed command is 'x' or 'xit'.

This is sometimes an essential feature, but not always desirable.  How about
making this feature depend on a compile-time ifdef?  Then the system manager
can control the use of this as appropriate.

Ken Poulton

------------------------------

Date: Tue, 24 Sep 85 18:43:32 pdt
From: "Scott Weikart; Community Data Processing" <cdp!scott@glacier>
Subject: Info-Kermit Digest V3 #21: Ken Poulton reactions

Here's my reactions to Ken Poulton's changes.

> !
>    merged ! and other uses of fork to call new routine zexecl in ckufio
>    zexecl does an exec, using 1) the shell defined by environment variable
>    SHELL, if any, or else 2) the user's login shell from /etc/passwd, or
>    failing that, 3) /bin/sh.

I like it.

> control chars
>     added conchr to ckutio and changes in ckucmd to support using the
>     user's predefined control characters as he expects

I like it, for those systems that support it (and leave ^W as backward
delete word on SYSIII, etc).

> startup files
>     1) ./.kermrc   2) ~/.kermrc   3) /usr/local/lib/kermrc
>     settable with -DKERMRC (as before) and -DSYS_KERMRC
>     Note that order of first two is intentionally changed

I would like to have two system files, kermrc.1st and kermrc.lst.
.1st would be done first, then a user's (if any) would be done (i.e. either
1) or 2) above), then .lst.  Basically, I want both defaults and mandatory
values, and this seems to be the only way to do it.

I think /etc might be a better place for the system-wide files, like
/etc/profile and /etc/cshprofile.

I'm not sure I like 1); it seems like a take file in the appropriate
directory would be safer.

> eXIT command
>     added eXIT command - allows leaving Kermit w/o unlocking or dropping line
>     added ttnohu to close the tty w/o hangup
>     creates ~/UNLOCKttyxx to remind user
>     EXIT deleted to avoid confusion
>     (maybe this should be disabled on BSD systems as not needed)

I don't like it.  I still think that pushing a subshell is the only reasonable
way to do it, with /usr/spool/uucp group accessible and kermit setgid (as I
described at length a while back).  Of course, I can't bitch too much since
I'm not offering to implement it.

> #
>     added comment command
>     for documenting scripts
>     (done with % by 4C(057))
>
> [Ed. - I used "%" for this to avoid confusion with shell scripts.]

But I'd *rather* have it be like shell scripts; my Emacs already assumes
that files with no or unknown extionsions use # as comment, and most
UNIX types will recognize # as comment.  And I doubt that a kermit
script will often look like a shell script.

> locking
>     now accepts existing lock files owned by the user (to support eXIT)

This seems good as long as it doesn't break when files or directories
or unreadable.  At least some people could have it right.

------------------------------

Date: Thu Sep 26 1985 17:55:58
From: Marco Papa <[e-mail]>
Subject: Comments on C-Kermit new features

These are my comments about the possible additional features or chhanges to
current features of C-Kermit.

1. SHELL stuff.  OK.

2. Control chars. OK.

3. Startup files. BAD!!! Much better like it is now.

3. Exit command.  BAD too!! I do not like case sensitivity, but much more
important I do not want users to leave locked lines around. There is really
no real advantage, and the risks are enormous.

4. Scripts with no echo. OK. In fact I hate to have my login script to show
right on the monitor the password I am using to login on another system.
Logging transactions is enough.  After one has found the correct login
sequence there is absolutely no need to show it everytime.

5. comment command for shell scripts.  OK together with 4.

6. locking. It won't work in most systems.  System managers are becoming
more restrictive in letting users create locks owned by them.


Marco Papa
USC - Computer Science Dept.

UUCP:  ...!{{decvax,ucbvax}!sdcsvax,hplabs,allegra,trwrb}!sdcrdcf!uscvax!papa
CSNET: [e-mail]
ARPA:  [e-mail]

------------------------------

Date: Wed, 25 Sep 85 10:43:58 pdt
From: hpl-opus![e-mail]
Subject: Use of '%' and '#' in Scripts

On the use of '%' or '#' for comments in scripts:

*Many* Unix programs allow '#' to introduce comments, not just shells.

In addition, some Unix systems allow "#! program" at the beginning of a file
to indicate that that file is a script for 'program' and should be executed
as such.  This is usually used for csh scripts ("#! /bin/csh") but would
allow one to write executable kermit scripts by writing

    #!/usr/local/bin/kermit

at the head of the file.  Then (on systems which support this) one need only
type the script's filename to execute it with kermit.

Ken

------------------------------

Date: 25 Sep 85 09:22:11 EDT
From: GH0N@CMU-CC-TC
Subject: C-Kermit Works on HP Integral Kermit

This is in regard to whether C-Kermit 4C runs on the HP Integral.  I have
gotten C-Kermit to run on the Integral with very little trouble.  Make sys3
does get the job done, but you need to either remove the code that sets up
lock files, or have the lock files put in a directory that is guaranteed
to be there (such as /tmp).  Another thing that crops up is that the C
compiler for the Integral has a bug in it (at least the version I have does)
that will cause it to report the sizeof() an array as being 0.  Sizeof() on
lone variables and structures (including structures containing arrays) work
fine.  The biggest hassle with making C-Kermit for the Integral is the fact
that you can't use make if you don't have either LOTS of memory or a hard
disk.  To compile and link all the code takes about an hour.

    Hope this helps.

Gordon Haverland
GH0N % CMU-CC-TC @ Carnegie    Mailnet }
GH0N @ CMU-CC-TC        BITnet  } soon to be GH0N.TC.CC.CMU.EDU ?
...!cmu-cs-pt!cmu-cc-tc!gh0n    uucp?

------------------------------

Date: Tue, 1 Oct 85 11:31:06 -0100
From: mcvax!philmds!duvel![e-mail]
Subject: C-Kermit EOF Bug

I've encountered a bug in C-Kermit v57.

The bug is that in ckcpro.c (and .w) a test is done on the return value of
reof.  However reof() does *never* return a value.  This makes ckcpro.c barf
sometimes that a file cannot be closed, but evidently there is no problem at
all.  By the way reof() is declared in ckcfns.c. I could not find other
calls except for the one in ckcpro.c

    Frans Meulenbroeks, Philips Microprocessor Development Systems
           ...!{seismo|philabs|decvax}!mcvax!philmds!frans

[Ed. - Right you are -- reof() should return the value that was returned to
it by clsof(), indicating whether the file was closed successfully or not.
Will be fixed in next release; noted in "beware file" till then.]

------------------------------

Date: Thu, 3 Oct 85 11:07:42 PDT
From: [e-mail] (Brian Kantor)
Subject: C-Kermit Does Not Compile on AT&T 3B20 SysVR2 - And the Fix

The routine 'unchar' in ckcker.h has a name conflict with the unsigned
character typedef included from sys/types.h.  Changing it to 'myunchar'
permits Kermit to compile.

    Brian Kantor    UC San Diego

    decvax\     [e-mail]
    akgua  >---  sdcsvax  --- brian
    ucbvax/        Kantor@Nosc

[Ed. - Thanks, will change this in the next release, and note it in the beware
file until then.]

------------------------------

Date: Sat, 5 Oct 85 02:19:30 CDT
From: Stan Barber <neuro1![e-mail]>
Subject: Masscomp Kermit

I submitted an version of 4.2 C-Kermit to the Masscomp Users Group that had
line-locking that would work (I hope) for most environments.  I have not had a
chance to get the most recent release of 4C to add those features to it that
deal with the line-locking problem effectively.

make sys3 does just fine, if line-locking is not an issue. If it is, then my
mods would probably satisfy most.  It is fortunate that the new version of UUCP
(BSD 4.3) supports a read/write by the world LCK directory to remove the need
for setuid programs.

I will be making the 4C version work on masscomp sometime soon, but 4.2 seems
to work for most people even with the bugs it has.

I will be happy to field any comments on the masscomp users group version.

Stan Barber
Baylor College of Medicine
[e-mail]
ihnp4!shell!neuro1!sob

------------------------------

Date: 20-Sep-85 14:33:10EDT
From: "KENNETH POOLE" <poole@nusc-ada>
Subject: NU-Machine Unix Kermit

I have done a simple mod of 4c(57) of the unix kermit for the NU-machine
unix from TI.  This Unix is the one on the LMI Lambda-Plus machines.
Please indicate how you would like me to send you the mods for adding
to the main source.  I modified ckutio,ckufio and ckuker.mak.  Also,
please add my name to the list for the info-kermit digest.  I was on
before, but we lost our arpanet software fo a while and i think i was
taken off the list.  Thanks,
            Ken Poole  849-6270

[Ed. - I tried to respond to this message, but couldn't seem to push a
message through.  Ken, please send me context diffs...]

------------------------------

Date: Thu, 26 Sep 85 15:21:32 GMT
From: John Rainbow Messenger <[e-mail]>
Via: [e-mail]
Subject: Bug in C-Kermit Remote Commands under VAX/VMS

We have found a bug in the remote command execution code for the VMS version
of C-Kermit.  The symptom was a complete failure to execute remote commands,
with a message of the form %F - Can't delete file (for instance).
The enclosed fix enables remote commands to be executed.

The patch is a context diff, and can be installed with the patch command.

[Ed. - Patch omitted, but listed in KER:CKVKER.BWR on CU20B.]

------------------------------

End of Info-Kermit Digest
*************************
-------
 8-Oct-85 13:03:52-EDT,20102;000000000000
Mail-From: SY.FDC created at  8-Oct-85 13:03:14
Date: Tue 8 Oct 85 13:03:14-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #23
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue,  8 Oct 1985       Volume 3 : Number 23

Departments:
                    New BOO-file Maker for MS-DOS
          Further Problem with MS-DOS Kermit 2.28 GET Command
                    About MS Kermit and EXEPACK...
   Communication Problems with MS-DOC Kermit 2.28 on Leading Edge PC
               MS-DOS Kermit vs "Desk Accessory" Clocks
             How to Build Z100 MS-DOS Kermit from Source?
                       Terminals for the Blind
                   The Claimed C-Kermit Bug for VMS
          Four-Table ASCII/EBCDIC System for EBCDIC Kermits
           Request for Osborne and Kaypro Kermit Diskettes
                        MacKermit TAC Problem
                  Re: Kermit 1.7 Loses at 1200 Baud
                        Kermit for Wang 2200?
                       Kermit for DG Machines?
                         Kermit for CDS 4000?

----------------------------------------------------------------------

Date: Thu 26 Sep 85 11:39:58-EDT
From: Frank da Cruz <[e-mail]>
Subject: New BOO-file Maker for MS-DOS

Alan Phillips at Lancaster University (UK) added Lattice C support to
MSMKBO.C, so that now MS-DOS Kermit .BOO files can be made directly on the
PC.  The new version replaces the old one, as KER:MSMKBOO.C on CU20B.

If you don't know what a .BOO file is, it's yet-another-printable-encoding
for binary files, the format that we distribute MS-DOS Kermit binaries in.
It features 4-for-3 encoding and 0-compression so that the resulting .BOO
file is often shorter than the original .EXE.

------------------------------

Date: 24 Sep 1985 2221-EDT
From: Stephen H. Owades, c/o EIBEN@DEC-MARLBORO
Subject: Further Problem with MS-DOS Kermit 2.28 GET Command

I have had some problems with MS-DOS Kermit 2.28 on my IBM PC/AT, as I
described in a mail message some weeks ago.  I downloaded the MSKERM.BWR
file, which offered a solution to the faulty file-name truncation (in
multi-file GETs) problem.  I made the suggested changes, reassembled and
relinked, and tested the resulting program.  Apparently no truncation
whatever is performed on a GET; DOS truncates the file name passed to it by
KERMIT.  This does eliminate the problem of badly truncated file names
(wherein KERMIT was doing something bizarre to the name of the first
incoming file), but it has created a new, perhaps worse, fault.  Now
collisions (incoming file name the same as a file name already presen are
only detected when the incoming file name is valid under DOS; if the
incoming file name is longer than XXXXXXXX.XXX, KERMIT doesn't know there is
a conflict and the system hangs.  I had to reboot my AT!  Collisions are
detected and avoided with the "0-1-2-..." naming method described in
MSKERM.DOC if the incoming file name is valid under DOS--evidently KERMIT
doesn't realize that there is a collision when the incoming file name was
truncated by DOS.

Stephen H. Owades

------------------------------

Date: 27 Sep 1985 0912-EDT
From: LCG.KERMIT
Subject: About MS Kermit and EXEPACK...

I have used EXEPACK on MS Kermit 2.26 through 2.28 and it produces workable
code (note I relink from source). In the 2.27 and older versions the .EXE
file went from 80+ K to around 36K.  In V2.28 however the savings was minimal
(10% if I recall right).  Thus EXEPACK is of marginal use with V2.28.  Can't
say much about backward compatibility; it looks OK on PCDOS V2.0 on, but
could break some compatibles.  Since MSDOS Link V3.XX is not commonly
available I believe its a mistake to use it in distribution; people should
be able to recreate the distributed .EXE via source with more common tools...

Glenn Everhart

------------------------------

Date:  2 Oct 1985 1152-PDT
From: Rob-Kling <Kling%UCI-20B@UCI-ICSA>
Subject: Communication Problems with MS-DOC Kermit 2.28 on Leading Edge PC

I normally use Kermit through COMM1 on my IBM-PC. I was trying it on a
Leading Edge PC last night which was configured to communicate through COM2.
It wouldn't send commands to the modem.

The Status command indicated that 1200 baud was illegal [even though we could
use PC-TalkIII to dial out on COM2].

I could not get Kermit to accept any baud rate (e.g., 110, 300, 1200) as
legal for COM2.  That is, the Status command indicated an error at any baud
rate when I set the port to COM2, but it would accept 1200 baud on COM1.

When I came home, I tried setting Kermit to use COM2 on my IBMPC at home.
I have only one serial port on this machine, but tried to set COM2 as the
active port. I received the same error messages re inappropriate baud rate
["Baud rate not recognized" or equivalent message].

I couldn't find any information in the Kermit 2.28 manual to help me decide
where the problem might lie.

1. What may be the problem?

2. Do you know if anyone has tried to use MSKermit on one of the new leading
Edge D machines?

Thanks

Rob Kling
UC-Irvine

[Ed. - I'm pretty sure you can set the baud rate on COM2, as many people at
Columbia have two serial ports and use both.  If the second serial board isn't
there, the status command would not be able to figure out the baud rate, since
reading the (non-existent) baud rate status port would return something
meaningless.  I don't know anything about the Leading Edge machines, but it
sounds like they're another 'almost' compatible, at least in terms of the
second serial port.  Does anyone out there know something about Leading Edge?]

------------------------------

Date: Mon, 7 Oct 85 10:21:49 PDT
From: [e-mail]
Subject: MS-DOS Kermit vs "Desk Accessory" Clocks

Any program which accesses the IBM PC timer interrupt to place a real-time
clock on the screen seems to put a real strain on Kermit.  Continuous-update
programs basically trash Kermit.  I have a shareware program called Deskmate
on my PC right now, which updates the time on the screen every 10 seconds or
so.  It still badly interferes with Kermit.  I don't want to have to reboot
my system in order to use Kermit effectively.

Does anyone have a solution to this problem, or is it inherent in the IBM PC
architecture?

                    Steve Walton
                    Caltech Solar Astronomy
                    [e-mail]
                    [e-mail]
                    ...!psuvax1![e-mail]

[Ed. - Thanks for the report; I've noted it in the "beware" file.  There may
be a way to get two or more programs that use timers to coexist, we'll have
to look into it.]

------------------------------

Date: Mon 7 Oct 85 13:20:34-MDT
From: Dick Dysart <[e-mail]>
Subject: How to Build Z100 MS-DOS Kermit from Source?

I have downloaded the MS*.ASM files for Kermit for the Z-100, 13 of them..
I have run them thru MASM , each with no errors from MASM..(not sure if or
what I should modify for MY machine)..

Then when I LINK them, the linker responds -> I/O run error in EXE, and
aborts without creating the .EXE file...

I thought that I should try from the beginning as my Besterm still won't work
properly, and MAYBE a version of Kermit compiled on MY machine would work..

With the LINKER aborting this way, and I cant find that error message in the
MS-DOS manual as yet, I don't know what's wrong, nore do I have any idea
what to fix..

Any help would be appreciated......................Dick

[Ed. - Can anybody who has experience with MS-DOS Kermit on the Z100 offer
any help?]

------------------------------

Date: Mon, 7 Oct 85 20:31:19 EDT
From: Doug Gwyn (VLD/VMB) <[e-mail]>
Subject: Terminals for the Blind

I don't know why nobody seems to be mentioning the VersaBraille (another
company makes a similar device).  I used to have a blind programmer working
for me, and we tried various talking terminals, optical scanners, and so
forth.  Her conclusion was that the VersaBraille (with communications
software cassette) was much easier and faster, although for graphics (yes!)
she resorted to an optical scanner (sorry, I forget the trade name).

This topic really seems orthogonal to KERMIT, other than to the extent to
which it points out the silliness of fancy user interfaces in what was
supposed to be a file transfer program.

[Ed. - So true.  By the way, I can't find any other forum for discussion
of these issues in the "list of lists", so I don't mind if the topic
continues in Info-Kermit for a while.]

------------------------------

Date: Mon 7 Oct 85 21:47:01-EDT
From: Jin Au Kong <[e-mail]>
Subject: The Claimed C-Kermit Bug for VMS

The problem with "! XXX" in VMS is related to the BYTLM in user authorization
file, as we discovered soon after we installed C-kermit on our system.   For
VMS to create a subprocess, the BYTLM must exceed 4096 (which is our previous
setting), and of course, PRCLM must be at least 1.  I don't know the exact
minimum for BYTLM, but after we set it to 6144, it worked.

But note that the created subprocess will not be stopped after you get out
from Kermit.  Hope somebody can fix the problem.

[Ed. - Thanks, noted in the CKVKER.BWR file.  Does this mean that the
previous report is wrong and that no change needs to be made to the code,
or that both are necessary?  Anybody want to contribute "installation
instructions" for C-Kermit under VMS, and/or a review of its usefulness?]

------------------------------

Date: Sat, 27 Jul 85 15:55 PDT
From: [e-mail]
Subject: Four-Table ASCII/EBCDIC System for EBCDIC Kermits

[Ed. - This message was recently excavated and is now belatedly published.
It was apparently provoked by the new ASCII/EBCDIC translation feature of
VM/CMS Kermit v2.]

The two ATOE's and two ETOA's would differ in the following way.

First let us denote the system tables ATOE0 and ETOA0.  We will construct
ETOA1 to be the left inverse of ATOE0, i.e. for every printable ASCII
character x, ETOA1(ATOE0(x)) = x.  Similarly, we will construct ATOE1 to be
the right inverse of ETOA0, i.e. for every printable ASCII character x,
ETOA0(ATOE1(x)) = x.  The -1 tables are used to postmap incoming packets
back to ASCII and to premap outgoing packets out of ASCII.  They form an
outer layer to Kermit so it can analyze and build packets in ASCII.  If the
-0 system tables are nonstandard, then the -1 will be too.  Note that the
right inverse may not be unique and that either inverse may fail to exist.

The other function of translation tables is to map text messages back and
forth between ASCII and EBCDIC as packets are analyzed and synthesized.
Call these ETOA2 and ATOE2.  Ideally these should be based on the "standard"
in the IBM System 370 Reference Summary or the Appendix of the Kermit User's
Manual, and thus would differ from the -1 tables in the nonstandard
situation.  Currently, -1 tables do double duty as they perform the text
message translation function as well.  The result is various distortions in
text as it is transmitted to and from EBCDIC systems, including undesirable
substitutions and swallowing of characters.  In a four-table system as I
have outlined, these distortions would not occur.

What is left is to state mathematically the conditions under which the
-1 tables can be constucted, and to present the appropriate algorithms.

. ETOA1 exists iff ATOE0 is 1-1 (unambiguous) on the printable set.

. ATOE1 exists iff the range of ETOA contains the printable set.

With standard tables, these questions do not arise since in this case
the system tables are both left and right inverses of each other.

This is all I have time for now.  Hopefully, I can sketch the algorithms
later.  I ran into the problem of distorted characters at UCLA where TSO
Kermit has recently been installed with modified translation tables.  I
wanted to download Kermit-MS in the .BOO format as well as the Basic program
to decode it.  I noticed that the tilde (or degree sign) was getting
swallowed and that the backslash was being blanked out.  It would have been
easy enough to hand patch the Basic, but hardly the .BOO file.  I hope I
have convinced you that there is a problem.

Ciao -

Glenn Thobe
iva3get@uclamvs and vss7853@uclavm (bitnet)

[Ed. - Given the number of calls I get every day from IBM mainframe sites
who have "customized" their translate tables, I don't need convincing that
there's a problem.  But I'm not sure I understand how a 4-table system will
necessarily solve it.  Your level 1 tables that invert the system's tables
will only work if the system's tables are already unique and invertible --
in many cases they are not.  If 2 different printable ASCII characters are
mapped by the system to the same EBCDIC character, then the even the low
level stuff won't work -- some packets will be perceived has having wrong
checksums.  In such cases, the only solution is to fix the system's tables.]

------------------------------

Date: Wed, 25 Sep 85 13:10:12 PDT
From: [e-mail]
Subject: Request for Osborne and Kaypro Kermit Diskettes
To: [e-mail]

I have been in touch with Frank da Cruz regarding our local (Los Angeles
area) Osborne club acting as a distribution house for Osborne and Kaypro
Kermit diskettes and documentation. the details are all worked out, but
I do require copies on disk of latest versions and doc or library files
for these programs.  I would also like to obtain a copy of the Kermit
User Guide.

Anyone who can assist in this matter may reply directly to this message or
contact me also via:

                       1) [e-mail]

                       2) BOB DANTAS
                          % JET PROPULSION LAB
                          4800 OAK GROVE DRIVE
                          MAIL SLOT T-LL
                          MAIL SLOT T-1180 (CORRECT ONE)
                          PASADENA, CALIF.  91109

                       3) [phone]

[Ed. - I'll send a User Guide.  Could someone who has Kermit on Kaypro or
Osborne diskette please send in a copy?  Thanks!]

------------------------------

Date: Tue 1 Oct 85 09:07:52-PDT
From: Steve Dennett <[e-mail]>
Subject: MacKermit TAC Problem

The NIC has gotten several calls lately from users having trouble getting
Macintosh Kermit to work through a TAC.  I've tried doing file transfers
and have been equally unsuccessful.  The odd thing is that it's a one-way
problem.

Going through a TAC, files can be downloaded from host to Mac without
difficulty.  But when uploading, MacKermit sends three packets then
starts re-trying until it finally times out.

I've read the general information about using Kermit through a TAC and
have successfully moved files in both directions through a TAC using the
IBM PC version of Kermit, so the problem is something specific to MacKermit.
Also, I've tried all the different TAC twiddles (BIS/BOS, flow control,
varying packet sizes, etc.) but no combination seems to make a difference.

The version of MacKermit I'm using is .8(33) July 1985.  Since you're listed
as one of the authors, I hope you can help.  With the growing number of net
users and the popularity of the Mac, this question is certain to come up
with increasing frequency.

Thanks for your help.

Steve Dennett  (  [e-mail]  )
DDN Network Information Center

[Ed. - Well...  You've got the latest version of Mac Kermit, so that's not
the problem.  I've never used a TAC personally, so all my information is
second hand.  @B I S/@B O S makes the TAC transparent, so once you've done
that, you should be able to rule out any interference by XON/XOFF (which the
Mac doesn't do anyway), atsigns, etc.  The fact that you can download files
to the Mac seems to confirm this.  Therefore, I'd look again at the TAC's
buffers.  If there's a way to make them bigger, do that.  If not, you've got
to get the Mac to send shorter packets; to do this, tell BOTH Kermits to
reduce their packet sizes.  What may be happening is that the effect of
commands like "set send packet-length" might be the opposite of what you
expect -- some Kermits take this to mean that you want to override whatever
the other Kermit asks for, and while others do the opposite.  Let me know
how it works.  If you still have problems, find out as much as you can from
the two Kermits involved -- note all the current communications and protocol
settings, get debug and/or packet logs if possible.]

------------------------------

Date: Wed 2 Oct 85 21:30:17-EDT
From: Robert S. Lenoil <[e-mail]>
To: [e-mail]
cc: [e-mail], [e-mail]
Subject: Re: Kermit 1.7 Loses at 1200 Baud

I tried your suggested fix of setting the RS-232 registers to 8 so that my
modem could autobaud correctly, and then resetting them to zero.  This worked
in that my modem did autobaud correctly and go into high-speed mode.  However,
when I reset the rs-232 regs to zero, the host could no longer understand me.
Of course, if I left the registers at 8, I dropped characters.  The symptoms
are this: my transmit data light goes on, but the host does not return any
character (I am in full duplex).  After restarting with Kermit 1.5 (what I'm
using now), I saw that the DEC-20 was receiving nothing but back-quotes ("`").
I've rejected the possibility that my download went poorly, since I used
Kermit, and because the hex file has its own checksums.  Again, my modem is a
ProModem 1200, by Prometheus.  Has anyone else seen this behavior exhibited?

------------------------------

Date: Wednesday, 18 September 1985  17:43-MDT
From: [e-mail] (Paul Johnson)
Subject: Kermit for Wang 2200?

Does anybody have the source for Kermit on a Wang 2200?

paul johnson
{akgua,allegra,dcdwest,decvax,ihnp4,helios,ucbvax}!sdcsvax!pjohnson

[Ed. - To my knowledge, no Kermit program exists for any Wang systems other
than the PC, and no one is working on any.  Does anybody know something to
the contrary?]

------------------------------

Date: 26 Sep 1985 1331-EDT
From: LSM.DUNCAN at DEC-MARLBORO.ARPA
Subject: Kermit for DG Machines?

Is there ayone who could provide a copy of a Data General Kermit for an
MV4000 system in binary form?  We have a system with no compilers and a
cartridge tape.  Alternatively, is there a way to get a binary version
from a system so it could be downloaded with a 'crude' transfer program?

  Thanks,
     Jeff Duncan (lsm.duncan@dec-marlboro)

------------------------------

Date: 2 Oct 85 22:13:21 EDT
From: Steven Christensen <SC1K@CMU-CC-TE>
Subject: Kermit for CDS 4000?

Is anyone working on a Kermit for ComputerVision's CDS-4000 computer?  It's
basically a FORTRAN generic machine, with some strange idiosyncronicities.

    Steven Christensen
    Phone: [phone]
    Address: 728 Stuart Lane  Cincinnati, Oh  45245

------------------------------

End of Info-Kermit Digest
*************************
-------
17-Oct-85 17:51:15-EDT,21893;000000000000
Mail-From: SY.FDC created at 17-Oct-85 17:50:28
Date: Thu 17 Oct 85 17:50:28-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #24
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 17 Oct 1985       Volume 3 : Number 24

Today's Topics:

               MS-DOS Kermit for the DECmate II and III
               Crosstalk XVI 3.6 Kermit Implementation
         Kermit Throughput Problems with "Smart" Multiplexer
                          MacKermit and TACs
                        VMS Kermit 3.1.066 Bug
                     Re: VMS C Kermit problem...
                Commodore-64 Kermit 1.7 1200 Baud Fix
                   CP/M Kermit on a Remote Machine
     File Transfer Between VAX (Unix 4.2) and IBM 3081 (VM/370) ?
          File Transfer Between VAX And IBM PC Through LAN ?
         Victor 9000 CP/M-86 Kermit Binary Wanted (On Floppy)
                         MS DOS Kermit vs DTR
                  Kermit for 1750A, MOS, or Jovial?

----------------------------------------------------------------------

Date: Thu, 17 Oct 85 10:02:47 EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: MS-DOS Kermit for the DECmate II and III

An implementation of MS-DOS Kermit 2.28 (the current release) is now
available for the DECmate-II and III with the XPU (MS-DOS) option, from an
anonymous donor at DEC.  The files are in KER:MSDM2.BOO (printably encoded
.EXE file, use KER:MSPCTRAN.BAS or KER:MSPCBOO.BAS to decode it, if indeed
DECmate MS-DOS has a Microsoft-like Basic), KER:MSDMII.BAT (for building from
source), KER:MSXDM2.ASM (system-dependent source module), and KB:MSDM2.EXE
(8-bit binary).  No documentation is available, but it is said to work, and
to use the DM-II/III's built-in VT100/200 firmware for terminal emulation.

------------------------------

Date: Wed, 9 Oct 85 08:57:06 cdt
From: [e-mail] (R. Blake Farenthold)
Kermit: Kermit on The Source

The Source (a commercial time sharing service) has just set up their
SIGS (Special interest groups) containing discussions & downloads for
people with various interests.  Aside from straight ASCII up and down
loads they offer Kermit transfers.

A couple of days ago I sent a 110K file to the Source using Kermit. At
1200 baud this should have taken about 15 minutes. IT TOOK OVER AN
HOUR!  Is Kermit that inefficent, is it horribly hampered when using
a packet switching network (I used Telenet), or has The Source slowed
things way down so they can collect more per-minute connect time!

In otherwords who do I yell at?

Blake Farenthold      |    CIS: 70070,521   |  UUCP: {ut-sally,ut-ngp,noao}
P.O. Box 3027         | Source: TCX023      |        !utastro!blake
Austin, TX 78764-3027 | Delphi: blake       |  Intr: [e-mail]
BBS: 512-442-1116     |    MCI: BFARENTHOLD |   ESL: 62806548

[Ed. - The people at The Source are well aware of the problem, which is
twofold: (a) TELENET, and the Prime computer itself (which is what you are
talking to) provide only 7-bit channels, so you incur the overhead of
8th-bit prefixing for binary files, and (b) any packet-switched wide-area
public network like TELENET has its own built-in delays, which, due to the
stop-and-wait nature of the Kermit protocol in its present form, will tend
to dominate any file transfer over TELENET.  To cope with these problems,
The Source has proposed (in Info-Kermit v3 #7, with discussion in following
issues) a sliding window protocol to allow multiple packets to be sent back
to back, which can result in a dramatic performance improvement under these
conditions.  Prototype programs are running now, and should be announced
before the end of the year.  By the way, don't complain too much -- most
other protocols don't work in this environment at all!]

------------------------------

Date: Wed, 16 Oct 85 20:02:47 EDT
From: RAF@UMDC
Subject:  Crosstalk XVI 3.6 Kermit Implementation

I just received a copy of Crosstalk XVI 3.6, which includes KERMIT support.
I gave it a quick try and encountered two problems.  One is that when I send
a text file from the PC to my TSO KERMIT, Crosstalk does not stop at the
Control-Z.  Thus I get a Control-Z plus some additional garbage at the end
of the file.  Microstuf customer support confirms that there is no way to
get Crosstalk to stop at the Control-Z.  Since Control-Z for end of file is
a PC convention, it seems to me that Crosstalk should support it.  Customer
support said they would pass the suggestion on for consideration.

The other problem is much more minor: after a Crosstalk KERMIT LIST command
is done to list KERMIT protocol options, everything put on the screen after
that is in high intensity.

Roger Fajman  <RAF@UMDC>
National Institutes of Health

------------------------------

DATE: 16-OCT-1985
FROM: [e-mail]
SUBJECT: Kermit Throughput Problems with "Smart" Multiplexer

A note to those of you who support a Kermit implementation on odd modems and
muxes:

I recently had a call from a Kermit-11 user who found that a download from
the host to the RT11 system for a given file took 2 minutes, whereas the
upload of the same file to the host took 14 minutes.  Solution: the mux they
were using severely downgrades the uplink bandwidth in an ill conceived
attempt to improve the host to local link bandwidth.  From what I have seen
recently in the various trade rags, this seems to be an approach that some
vendors are trying out.  Beware...

brian

[Ed. - One of the hardest problems Kermit or any similar protocol has to
cope with is that so much communication equipment is designed under the
assumption that input from a "terminal" will only be human keystrokes.
Another example follows...]

------------------------------

Date: Thu, 10 Oct 85 21:35:27 EDT
From: Dave Swindell <[e-mail]>
Subject: MacKermit and TACs

I've found that you have to explicitly set the send-packet length to
something less than 64 when uploading data from ANY PC over a TAC.  The TAC
input buffer just isn't big enough to handle the 90 (or is it 94?) character
default send-packet size used by MacKermit.  As was mentioned in the digest,
you also have to use the TAC commands @ B O S and @ B I S (in that order) to
allow the Kermit protocol to function correctly over a TAC.

Dave Swindell
BBN Laboratories

------------------------------

Date: Tue 8 Oct 85 16:15:54-EDT
From: Michael Fuchs <[e-mail]>
Subject: VMS Kermit 3.1.066 Bug

I don't know if 3.1.066 is state-of-the-art, but it can't handle CRCs and
8bit data simultaneously in server mode.  One can't set the micro to CRC and
send a binary file to the VAX unless one explicitly makes the micro
*request* 8-bit-prefixing.  CRC works fine with non-8bit-files, and 8bit
files can be sent micro to VAX with Checksum error detection.

The VAX puts a "3" in the appropriate place in the init packet.  Then, if
the data packet has bytes with the eighth bit high, it sends NAK packets
back to the micro.  (Indeed, the NAK packets correctly have CRCs.)  The only
way to use CRC error detection is to also have the micro request
8-bit-quoting (if one is sending 8bit data to the VAX).

------------------------------

From: Ivan Auger <[e-mail]>
To: info-kermit <@csnet-relay.arpa:[e-mail]>
Subject: Re: VMS C Kermit problem...

There is a default mailbox buffer size on any VMS system (mailboxes are used
for process communication).  You can have kermit set the size of mailboxes,
change the defaulf mailbox size, or you can indeed increase BYTLM quotas.
(By theway on our system you can do a SET HOST with a BYTLMC quota of 4096).
Ivan Auger, NYS Dept. of Health.

------------------------------

Date: Tue 8 Oct 85 17:20:07-EDT
From: Robert Lenoil <[e-mail]>
Subject: Commodore-64 Kermit 1.7 1200 Baud Fix

You must download the .INI file as a SEQ file. The proper parameters for the
kludge baud rates are contained in that file. 1200 baud will not work without
it.  That was the problem.  There is no way (from within Kermit) to set the
optional baud rate parameters in the .INI file, so you better download
KERMIT.INI properly, or 1200 baud won't work.  As as alternative, you might
wish to create KERMIT.INI with this small program:

10 open 8,8,8,"0:kermit.ini,s,w"
20 for i=1 to 45 : read b : print#1,chr$(b); : next
30 close 8
40 data 25,1,0,0,0,0,1,0,5,0,1,0,1,1,0,0,0,60,1,56,0,38,38,0,0,0,0,13,10,8,10
50 data 93,93,4,0,35,0,0,0,0,0,0,0,0,0

------------------------------

Date: Thu, 10 Oct 85 17:37:27 edt
From: Mike Ciaraldi  <[e-mail]>
Subject: CP/M Kermit on a Remote Machine

I sent this before, but I think it got lost:

Is there any way to run CP/M Kermit as the "remote" kermit rather than the
"local" kermit?  e.g. Suppose you had a computer bulletin board system
running under CP/M, and you wanted to use Kermit to upload and download
files.  You would use the Kermit on your own micro to call the BBS, and
could then run Kermit on the remote machine.  But when you told the remote
Kermit to, say, SEND, it would try to send the data out some communication
port, and would send only the status reports about the transfer to the
console (which is REALLY the modem ultimately connected to your local
machine).  Even if you use Generic Kermit and have it communicate with the
TTY or CRT device, it will still be sending both file data and the status
reports to the same device.  I know the IBM PC version has a flag you can
set to disable displaying the status, and the mainframe versions of Kermit
must be able to tell when to send status reports to the console and when not
to (by looking at the SET LINE perhaps?), but I couldn't find anything like
this in the CP/M Kermit 4.05 manual.

Thanks for your help.

Mike Ciaraldi
ciaraldi@rochester
seismo!rochester!ciaraldi

[Ed. - For now, there's no way to do this.  I've been forwarding messages
regarding CP/M-80 Kermit to the current maintainer, Charles Carvalho
(CHARLES@ACC), but haven't had a response in months.  Charles, are you
there???]

------------------------------

Date: 11 Oct 85 02:14:56 GMT
From: [e-mail] (P Wei)
Subject: File Transfer Between VAX (Unix 4.2) and IBM 3081 (VM/370) ?

We have vax running UNIX 4.2BSD , ckermit program, modem (/dev/tty18), vcu
(to use modem).  The ibm3081 also has cmskermit program.  the question is:
is it possible to transfer ascii file between this two system via that
modem?  I tried to use vcu to connect to ibm3081, but when I type 'kermit'
in CMS , I got 'an ascii terminal must be used' error message.  Even if i
didn't get that message, I couldn't get (escape) back to vax to invoke
ckermit because vcu doesn't allow me to 'escape'.  Then I tried to use
'kermit -l /dev/tty18 -b 1200'. The phone line was connected. However, when
ibm ask my terminal type, whatever I answer it warned me to check parity
etc...  I don't have time to go through further. I would like to ask if any
one knows my intention (file transfer) is possible.  If anyone has
experience, would you please mail me some sample session (as detail as
possible)? (e.g. the parameter settings...)  thanks a lot !

HP Wei

[Ed. - It is entirely possible to use Kermit to transfer ASCII text as well as
binary files between a 4.2BSD VAX and an IBM 370-Series mainframe running
VM/CMS.  Very briefly, here's how:

If you have a Series/1 style front end (7171, 4994, etc) running the Yale
ASCII package, you must also have version 2.00 or later of CMS Kermit on the
IBM mainframe (if you don't, you'll get the "An ASCII terminal must be used"
message.  If you're going through some other kind of 3270 protocol emulator,
then you can't use Kermit.  If you're going through a 3705-style front end
as an ordinary line mode TTY, you can use any version of CMS Kermit.

You should have version 4C(057) of C-Kermit on the Unix system -- certain
earlier versions had bugs that might have prevented them from working with
IBM mainframes.  To C-Kermit you should give the following commands if you're
coming in as a line-mode TTY:

set duplex half    (half duplex = local echo)
set flow none      (no full duplex xon/xoff flow control)
set handshake xon  (use half duplex line turnaround handshake)
set parity mark    (use whatever parity your IBM system expects)

or else the following commands if you're coming in through a Series/1 style
front end:

set parity even    (or whatever)

And of course you must also include whatever "set" commands are necessary
to set up the communication line ("set line", "set modem", "set baud", etc).

If all this seems a little strange, you can blame the IBM style of data
communications, which is different from everyone else's. ]

-----------------------------

Date: 11 Oct 85 04:49:02 GMT
From: [e-mail] (P Wei)
Subject: File Transfer Between VAX And IBM PC Through LAN ?

We have several ibmpc's connected to ETHERNET LAN with the communication
program 'yterm'. I can connect the ibmpc to the vax (running UNIX 4.2) using
yterm. Therefore , the ibmpc serve as a terminal for the vax.  Now , I escape
the yterm program to DOS and invoke MSKERMIT and then type 'connect'. I get
back to the unix shell. CKERMIT is then invoked.  Then type 'send filename
<CR>'; escape (^]C) back to MSKERMIT ; type 'receive <CR>'. However, there is
no packet coming in. The screen just display 'transfer in progress......'
message forever!

(1) Am I totally wrong ? The kermit doesn't work on LAN ??? (only on tel
    line ? )
(2) Or I forgot to set some parameters ??? Can someone mail me sample session
    if same attempt has been done?

Thanks in advance.
HP Wei

[Ed. - Kermit can indeed be used over LANs, so long as the PC's connection to
the LAN looks like a serial communication port to the PC.  This would seem to
the case in HP Wei's query, since a terminal connection can be made.

In general, when the Kermit CONNECT command works but file transfer does not,
the culprit is usually (a) parity, (b) flow control, (c) packet size, or
(d) interference:

(a) Check to see if your LAN terminal interfaces are using some kind of parity
and if so, tell BOTH Kermit programs about it, using the SET PARITY command.

(b) It is command for LAN terminal interfaces to want to do xon/xoff flow
control with the PC.  Make sure you PC is set up for this (MS-DOS Kermit
does this by default in most cases).  If some other kind of flow control is
required (like RTS/CTS) you could be in for trouble.

(c) Some LAN terminal interfaces have small buffers and can't accept a normal
Kermit packet (90-95 characters) at 9600 baud.  Try using SET SEND/RECEIVE
PACKET-LENGTH for smaller packets, or else reducing the baud rate.

(c) Some LAN terminal interfaces intercept a certain character for control
purposes.  If this is a printable character, a Control-A, or a carriage return,
then this will prevent Kermit file transfers from taking place.  In this case,
try to find out how to change the box's intercept character to a control
character other than ^A or CR.  If the ^A or the CR are at fault, you can use
Kermit's SET START and/or SET END to change these.  If it's a printable
character, and it can't be changed in the LAN box, you're out of luck.]

------------------------------

Date: Sunday, 13 October 1985  06:56-MDT
From: Gijs Mos <[e-mail]>
Subject: Victor 9000 CP/M-86 Kermit Binary Wanted (On Floppy)

I want to get some files from our Victor 9000 computers to various other
machines. The best program to use seems to be kermit. The problem is how to get
Kermit running on the Victor.  I have a recent kermit distribution with a
V9000-CP/M 86 kermit on it. But I don't have an assembler, nor a way to get the
sources on the Victor 9000's disks.  So I guess I'm looking for a kermit CP/M
86 executable in Victor 9000 format.  Can somebody provide such a beasty at
media/handling costs?

Gijs Mos
Dept. of Biology
Free University
De Boelelaan 1087
1081 HV  Amsterdam
The Netherlands
{seismo,philabs,decvax}!mcvax!vu44!gijs

------------------------------

Date: 14-OCT-1985 11:41
From: Heather Holmback <[e-mail]>
To: Problems with MS-DOS Victor Kermit

We have been unsuccessful in using Kermit for a connection between a VICTOR
PC with operating system MS-DOS and the VAX, at the Max-Planck-Institut for
Psycholinguistics in Nijmegen, The Netherlands.  We are using Sirius version
1.20 by Barry Devlin, University College Dublin, April 1984, translated by
SIREXE.BAS (by Daphne Tzoar, CUCCA).  Could you please send information on
any later versions of Kermit or any recent solutions to problems.  Our main
problem is that only one file can be successfully uploaded without exiting
and reloading Kermit.  Also MSKERMIT.INI does not work as indicated in the
documentation.  Thanks.

[Ed. - Unfortunately, this is still the latest version of MS-DOS Victor/Sirius
Kermit.  No one has ever taken the trouble to write an MSXSIR.ASM module so
that Victor support would be included automatically in new MS-DOS Kermit
releases.  Any volunteers?]

------------------------------

Date: Wed, 16 Oct 85 19:11:05 CDT
From: <uwmacc!uwmcsd1!u1100u!os1100!Mark=[e-mail]>
Subject: MS DOS Kermit vs DTR

MS DOS Kermit leaves the modem signal DTR high upon exit.  This is useful
if a person wishes to exit kermit and then resume an online session, however
there are times when it is useful to drop DTR when running Kermit or when
finished with Kermit.  For instance some modems will answer the phone only
when DTR is high, so you might want to drop DTR after a Kermit session so
that YOU can answer the phone rather than your modem.

On our campus a great many of our computers are linked together by a Gandalf
PACX communications switch.  Our switch polls all ports not in use that have
DTR high.  Since we have hundreds of micro's hard-wired to the switch, if
they keep DTR high when the switch has no active connection on that port to
a given system, they bog down the polling and after a short period produce
copious timeout error messages on the switch console.  For this reason it is
important that our users drop DTR when finished with a session.
Furthermore, on some lines it is impossible to reconect or change systems
without dropping DTR first.

Ideally, it would be nice to have another SET parameter called DTR or DTR-
EXIT or DTR-QUIT or DROP-DTR that could be set ON or OFF so that when Kermit
is terminated it would dictate what state DTR would be left in.  It would
also be nice to just have a command like RESET COMx or DROP-DTR COMx.

In lieu of this facility in Kermit I have written a short COM program
which I call OFFCOM1.COM or OFF.COM for short.  The commands to create this
8 byte COM file follow.  I suggest typing them in without the comments
(things beggining with a semicolon).

DEBUG OFFCOM1.COM
A
; PROGRAM OFFCOM1
;       by Mark Zinzow
;
; Provides an external DOS command to clear
; the serial port.
; This has been tested on a Zenith Z150 running MS Dos 2.11 and an
; IBM PC AT running PC Dos 3.1.
; Note that this program is hardcoded for the address of the RS232 port.
; A better way would be to use an offset on the base address normally
; found in memory at location 40H:0.
;
    MOV DX,3FC   ; Port address for serial modem register.
                 ; (Use 2FC for com2 rather than com1)
    MOV AL,0     ; Store a zero as the value to output.
    OUT DX,AL    ; SEND the zero to the port.
                 ;
    INT 20       ;return to DOS

RCX
8
W
Q

After typing the Q you should get the DOS prompt back.  A DIR should
show the 8 byte com file OFFCOM1.COM.  This program can be run after
exiting kermit or from kermit using the run command.  I use a macro to
drop DTR with the command do off.  The macro definition looks like this:
DEFINE OFF RUN A:OFF.COM

The first program of this kind at our site was written by Mitch Blank for
the Zenith Z100.  Here's the MASM source:

[Ed. - Source omitted, stored in KER:MSXZ100.DTR.  Adding DTR control for
every system that MS-DOS Kermit runs on (not to mention all the different
internal modems in use on them) would be a very big job, so little programs
like this are probably the best approach.]

------------------------------

Date:  Thu, 10 Oct 85 13:47 CDT
From:  "David S. Cargo" <[e-mail]>
Subject: Kermit for 1750A, MOS, or Jovial?

Has anybody seen or heard of a version of Kermit written in Jovial, or
the assembly language of the 1750A for MOS (the MATE Operating System)?
We have some parts of the company that want such a thing.

[From "Burton J. Ewing" <[e-mail]>: By the way, MOS is a
derivative of Unix (by way of IDRIS?). This might be more useful info to the
Kermit community than MOS. Our people who have been peering about in MOS's
innards tell me that it is largely identical to Unix in most respects. Same
structure, same subroutine names, arguments, etc. Therefore, if we could
find another Unix hosted Kermit that was written in something we can compile
to 1750A code we are in business. The last time I checked, that meant JOVIAL
- but, who knows what will happen in the future?]

------------------------------

End of Info-Kermit Digest
*************************
-------
18-Oct-85 18:06:14-EDT,13892;000000000000
Mail-From: SY.FDC created at 18-Oct-85 18:05:42
Date: Fri 18 Oct 85 18:05:42-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #25
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 18 Oct 1985       Volume 3 : Number 25

Departments:

  KERMIT (ETC) FOR THE BLIND -
    Equipment for the Blind
    Use of Kermit by the Blind

  VM/CMS KERMIT -
    CMS Kermit V2.01
    CMS KERMIT bugs
    Kermit-CMS Fixes
    Bug Fixes for CMS-Kermit 2.01

  MISCELLANY -
    Dropping DTR on VMS
    Victor/Sirus Support on the Way for MS-Kermit 2.28

----------------------------------------------------------------------

Date: Wednesday, 9 Oct 85 07:59:43 PDT
From: Robert Jaquiss <[e-mail]>
Subject: Equipment for the Blind

[Ed. - Some people have complained that this discussion is inappropriate
to Info-Kermit (and/or Info-IBMPC, Info-Micro, etc), but there's no
mailing list specifically for this topic.  And a lot of useful information
is coming in.  So please tolerate this digression for a while.  I'll also be
archiving all of these messages into a special file, KER:AABLIND.HLP.]

     I am a blind programmer at Tektronix Inc.  I have used Kermit on
several occations.  For my work I use a Thiel braille printer from Maryland
Computer Services.  To the computer it looks like a teletype that can send
and receive upper and lowercase.  Of course graphics are useless cursor
movement is impossible.  It is possible to deal with numbered or lettered
menus where you select the item you want by entering some character.  I have
a Versabraille as a backup terminal on which I have also used kermit it
worked fine.  The micro I am using runs CP/M so I don't have to contend with
menus.

     Here are some equipment sources that have reliable hardware.  Maryland
Computer Services sells a very good braille printer.  They have a specially
modified HP150 that talks and a accessory for a PC that will allow users to
use screen oriened software.  Telesensory Systems Inc. sells the
Versabraille (a refreshable braille display) and the Optacon (a hand held
scanner that will show you the shape of letters).  Vtek sells a tactile
display device for use on a ibm PC or Apple.

        Maryland Computer Services Inc.
        2010 rock Springs Road
        Forest Hills, Md. 21050
        Phone [phone]

        Telesensory Systems Inc.
        455 N. Bernardo
        Mountainview, Ca. 94039
        Phone [phone]

        Vtek
        1610 26th
        Santa Monica, Ca. 90404
        Phone [phone]

     If you need moe help call me at (503)  627-6346  (work).

        Robert S. Jaquiss

ucbvax!tektronix!robertj (uucp)
robert jaquiss@tektronix (csnet)
robert jaquiss.tektronix@rand-relay (arpanet)

------------------------------

Date: Fri, 11 Oct 85 9:34:53 EDT
From: Robert I. Isakower (IMD-SEAD) <[e-mail]>
Subject: Use of Kermit by the Blind

The following letter was sent to Kennith Reed 10/10/85 at your request.
9 October 1985

Dear Mr. Reed,

Recently  a request was forwarded to me from Frank da Cruz asking if I
had any information on the use of Kermit or the MS-DOS system by the Blind.

Perhaps this request was directed to me because I have tunnel vision (Retinitis
Pigmentosa).  I also have a degenerative hearing problem which places very
demanding requirements on any voice synthesizers used with visual aids for my
eyesight problems.  I have found SMOOTHTALKER on the Mac difficult to
understand.  DECTALK provides, for my personal use, the best voice output.
Please realize that I am not a judge of what constitutes good speech because
everything sounds to me as if it were coming from a distorted radio receiver.

The following information that I am including in my letter are my notes and
results of my own findings of a computer show that I attended in Ewing, New
Jersey this past September.  I have no corporate nor financial interest in any
of the company products and the information and comments that I am offering is
my personal opinion.

I sincerely hope that my enclosure will be of some assistance to you in your
research.  If I can be of any further assistance, please feel free to contact
me.
        Robert I. Isakower
        C,  Technical Systems Division

Four vendors featuring "talking computers" were at the show for aids for the
blind and the visually impaired.  I was unable to get prices for all the
equipment.

VTEK (formerly VISUALTEK)
1625 Olympic Boulevard
Santa Monica, CA   90404
1-800-345-2256

     VOYAGER Electronic Magnifiers:  $2,395 to $2,895

     Large Print Display Processor  (*) :  $2,695
(This device magnifies, up to 16X, whatever is on the screen, with
character enhancement.  It recognizes the ASCII code and redraws it as
a solid line vector, instead of an enlarged matrix of dots and spaces.)

     MBOSS-1 Braille Printer:  $3,225

     Braille Display Processor (*):  $3,495
This is a neat paperless braille output with a 20 cell tactile refreshable
braille readout.  It will provide the braille equivalent of 20 contiguous
character spaces on the computer display.  Audio signals indicate the
"position" of the 20 cell braille window on the video display.

     (*) for APPLE II, II+, IIe and IBM PC, PC-XT, PC-AT

COMPUTER CONVERSATIONS
2350 N. Fourth St.
Columbus, Ohio   43202
[phone] (after 6 PM)

     ENHANCED PC TALKING PROGRAM:  $500

     Written by a blind programmer, (Ronald Hutchinson), this is interfacing
software only, and requires the user's own computer, voice synthesizer, and
application progams.  Application programs are the programs that you wish to
use in a speaking mode and would be an additional expense with all talking
computers.  This company's program interfaces with the most used computers,
speech synthesizers and application software in the marketplace.  The company
will offer to recommend the configuration best suited to your needs and budget.

MARYLAND COMPUTER SERVICES
2010 Rock Spring Rd
Forest Hill, Maryland    21050
[phone]

     TOTAL TALK PC (microcomputer, display, speech synthesizer, keyboard)

AUDIODATA/IBM PC KEYBOARD (2 slider keys, speech synthesizer, speaker, and
display magnification with optional low cost monitor)-provides audio output
from your IBM PC.  The vertical slider key locates the desired line and the
horizontal key locates the character on the line. In this manner, the user can
hear the screen, one line at a time, character by character.

     THIEL BRAILLE (high speed-120 cps) EMBOSSER

     CRANMER-PERKINS BRAILLER (4000 character memory typewriter, braille
printer, plotter, smart terminal, portable):  $2,350.

     READY READER optical character reader (typewritten material to braille
or voice):  $11,500.

     MCS computer systems are based upon Hewlett-Packard computers which are
very well constructed.  Unfortunately, none of the above equipment was
demonstrated to me, for one reason or another.

A fourth vendor was demonstrating a speech synthesizer that works with
the APPLE II.  I wasn't stirred by it and left early, not being offerred
any literature.

COMMENTS: VTEK and MCS have been around a long time, know the business of
electronic visual aids, have the most varied product line and are probably
my best bet for the future.  They have equipment for both the visually
impaired and the totally blind.  MCS's AUDIODATA/IBM KEYBOARD promises the
simplest, cheapest and quickest fix for IBM PC users. Although it is a very
competitive computer marketplace, a small software manufacturer and system
iterfacing company such as Computer Conversations, probably with lower
production costs and more self-motivating talent, cannot be discounted.
Another company that should be investigated is the one that manufactures a
portable tactile (pins) readout device called the OPTICON.  I've watched
this used with great success and speed on printouts and teletypewriters (on
line), and I heard of some sort of adaptation to a computer display.  Note
that the OPTICON is difficult to learn to use.

------------------------------

Date: 9 October 1985, 13:36:52 EDT
From: Philip Murton             [phone]       MURTON   at UTORONTO
Subject: CMS Kermit V2.01

I think I found a small bug that is related to your edit [25],
if you have FILE set to BINARY and have compression ON.  Here's the fix:

[Ed. - Thanks!  Code omitted, but included in KER:CMSMIT.BWR.]

------------------------------

Date: Wed, 9 Oct 85 23:04 CDT
From: Brick Verser <BAV@KSUVM>
Subject: CMS KERMIT bugs

Here is another small CMS KERMIT problem.  If running on the 7171 (or
Series/1, I think), CMS KERMIT 2.x doesn't work if the virtual machine
console is not at address 9.  While all of the diagnoses know to use
the dynamically determined console address, the HNDINT SET has address
9 hard coded.  The fix is simple and obvious, except that HNDINT doesn't
allow a register for the console address field, so the HNDINT macro
has to be replaced by the hand coded equivalent.

[Ed. - See below.]

------------------------------

Date:         Tue, 15 Oct 85 09:13 EST
From:         Dave Elbon  <[e-mail]>
Subject:      Kermit-CMS Fixes

I have some fixes for Kermit-CMS 2.01.

1) Kermit-CMS is confused when TERMINAL LINESIZE is set to OFF.

2) The actual virtual console address is not used in a call to HNDINT,
   which prevents Kermit-CMS from working if the address is not 009.
   (Many, many thanks to Brick Verser of KSU for this.)

3) CP SET ACNT should be turned OFF along with MSG, WNG, and IMSG.

When Series/1 mode is on it might be possible to set TERMINAL BREAKIN to
GUESTCTL rather than changing all of the message settings.
Acknowledge-To: Dave Elbon <SYSDAVE@UKCC>

[Ed. - Thanks, the code that was included with this message has been added
to KER:CMSMIT.BWR.]

------------------------------

Date: Wed, 16 Oct 85 14:25:24 pdt
From: [e-mail]
Subject: Bug Fixes for CMS-Kermit 2.01

[Ed. - Each of these paragraphs came with code to correct the reported
problem.  The code has been omitted here, but has been added to
KER:CMSMIT.BWR.]

Fix bug at RPACK4. Calculation of crck (block=3) must begin at the first
actual packet character not at RECPKT+1. Leading pad or junk characters move
it further down.  Use pointer RECPKTP.

Fix confusion and conflicts in use of MAXOUT and LRECL.  MAXOUT controls the
amount of data collected for a write and LRECL is used only during padding
of recfm F records.  During SET FILE BIN, MAXOUT was set to LRECL and during
SET FILE TEXT it was set to MAXTXT!  This is clearly wrong.  Also, MAXOUT
was set to LRECL during SET LRECL which causes recfm V writes to be blocked
to LRECL.

This fix removes the MAXOUT change during SET FILE. SET LRECL is changed to
set MAXOUT to MAXTXT for recfm V or to LRECL for recfm F.  SET RECFM is
changed to do the same.

Fix maximum LRECL to 65535 not 65536.  CMS allows only 65535 (64k-1). CMS
aborts the write if lrecl 65536 for recfm V.  And although CMS allows the
write if lrecl 65536 for recfm F, most products cannot handle such records.

Fix MAXTXT to be 65535 not 64536 (typo)!  Remove unused MAXBIN.

Change receive to expand tabs each 8 spaces (unix,cp/m,pcdos) for text file
receives.

Redisplay the send or receive command at completion, followed by the status
message, then the completed or failed message.  This gives the user
everything they need to know at one glance.  Initial status is "No send /
receive done yet".

Fix recfm f to pad lines with spaces not nulls.

Change DECODE to interpret CR and LF from the EBCDIC after translation with
ATOE instead of from the seven bit ASCII. This allows receive of text files
that contain characters with the eight bit set with the normal ATOE table,
or by altering the the ATOE table allows receipt of text in any eight-bit
code.  Also CR LF LF gives two lines based on CR LF then LF.

Fix receive to discard the trailing control-Z for text files This catches
all cases except where the control-Z has already been written to disk, e.g.
the 65535th character of the last recfm V record or the lreclth character of
the last recfm F.

Greg Small                                    [phone]
Microcomputer Networking & Communications     [e-mail]
214 Evans Hall CFC                            ucbvax!ucbjade!ucbopal!gts
University of California                      [e-mail]
Berkeley, Ca 94720

------------------------------

Date: Thu, 17 Oct 85 21:53:16 edt
From: faron![e-mail]
Subject: Dropping DTR on VMS

We have the latest VMS Kermit running under VMS 4.whatever, talking to
an autodial modem through a DMF-32 mux. The only way the VAX can get
the modem to hang up the phone is by dopping DTR. Can anyone help with
a way to do that, perhaps with a little program like the one that was
in the last info-kermit digest for MSDOS? Are there any VMS SET TERM
parameters that are involved?

                    Sidney Markowitz

------------------------------

Date: 18-OCT-1985 13:58:48
From:[e-mail]
Subject: Victor/Sirus Support on the Way for MS-Kermit 2.28

Brian Steel of Logic Programming Associates (UK) is doing an MSXSIR.ASM at the
moment - no idea when it will be ready though.  Will let you know as soon as I
hear from him.

        Alan

------------------------------

End of Info-Kermit Digest
*************************
-------
24-Oct-85 16:16:36-EDT,18062;000000000000
Mail-From: SY.FDC created at 24-Oct-85 16:14:36
Date: Thu 24 Oct 85 16:14:36-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #26
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 24 Oct 1985       Volume 3 : Number 26

Departments:

  ANNOUNCEMENTS -
    CU20B Internet Address Changed

  MS-DOS KERMIT -
    MS-DOS Kermit Files Reorganized
    Request for Kaypro 2000 Information
    Revised HP 110, Portable Support for MS-DOS Kermit 2.28
    New TI Pro Support for MS-DOS Kermit 2.28
    Fix for Z100 MS-DOS Kermit
    MS-DOS Kermit Key Definitions for EDT
    MS-DOS Kermit and DTR

  MISCELLANY -
    C-Kermit 4C(056/057) and MacKermit 0.8(33)
    2400 Baud Modems with MNP "Protocol"
    Update on Crosstalk Problems
    CMS Kermit "Enhancements"
    Kermit for the Blind
    Kermit for the Texas Instruments 99/4A??
    Kermit on Diskette for Terak?

----------------------------------------------------------------------

Date: Thu, 24 Oct 85 15:33:59 edt
From: Frank da Cruz <SY.FDC@CU20B>
Subject: CU20B Internet Address Changed

Because Columbia is splitting its overburdened campus network into several
discrete but interconnected chunks, the Internet host address for CU20B
has changed, effective yesterday (23 Oct 85, 7:00PM EDT), from
[192.5.43.128] to [128.59.32.128].

The change has been reported to the NIC in hopes that they will get out a
revised host table in a day or so.  Until CU20B's new address is in your
host table, you can refer to it numerically (but then you don't get the
automatic recognition of what type of host it is; e.g. people coming in
from other DEC-20s will have to explicitly tell FTP "STRUCTURE PAGE",
"TENEX", or something to that effect.)

------------------------------

Date: Wed 23 Oct 85 14:13:21-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: MS-DOS Kermit Files Reorganized

Several recent submissions of MS-DOS Kermit material (see below) have
prompted me to reorganize the MS-DOS Kermit files a bit, so now they have
more consistent names.  The names are now in the following form:

    MScxxx.typ

The file name is no longer than six characters, the file type is 3 or less.
MS is the common prefix for all the file names.

"c" is a single-letter code that categorizes the file:

  A - General information, "read me" files, etc. (like this file)
  B - Files related to Bootstrapping
  I - Initialization or command files to be read by Kermit
  K - General program documentation (Kermit User Guide chapter, etc)
  R - Release notes
  S - System-independent Source code
  V - Binaries, .BOO files, documentation for a particular Version
  X - System-dependent source code & related documentation
  Y - System-dependent terminal emulation code
  Z - System-and-modem-dependent modem control code

"xxx" is a 3 letter code to designate which system an MSV, MSX, MSY, or MSZ
file applies to:

  AP3 - NEC APC-3
  APC - NEC APC
  APR - ACT Apricot
  DM2 - DECmate II or III with MS-DOS Option
  GEN - "Generic" MS-DOS (DOS calls only)
  HP1 - HP-150
  HPX - HP-110 and HP Portable Plus
  IBM - IBM PC, XT, AT, and PCjr (note, only works on RS-232 port of PCjr)
  MBC - Sanyo MBC-550
  RB1 - DEC Rainbow-100 series
  TIP - Texas Instruments Professional
  WNG - Wang PC
  Z10 - Heath/Zenith 100

"typ" is the file type, e.g.

  ASM - Assembler source (for Microsoft or IBM Assembler)
  H   - An assembler header file (included at assembly time)
  C   - A C language source file (e.g. Lattice C)
  BAS - A Basic language source (e.g. Microsoft Basic)
  BOO - An .EXE file encoded into printable characters for bootstrapping
  BWR - A "beware" file - list of known bugs or limitations
  HLP - A help file
  DOC - A longer documentation file
  MSS - Scribe text formatter source for a HLP or DOC file
  INI - An initialization or command file to be read by Kermit
  BAT - An MS-DOS Batch file (e.g. for building from source)
  UPD - A program update history file

KER:MSAAAA.HLP has been updated to reflect the changes, as well as the new
releases.  No changes were made to the programs themselves (except as
reported below), but I expect a new release of MS-DOS Kermit to be ready in
about a month.

------------------------------

Date: Tue, 22 Oct 85 16:30:24 pdt
From: Harvey A. Iwamoto <[e-mail]>
Subject: Request for Kaypro 2000 Information

I have been patching the Generic Kermit for the built-in modem in the HP 110
with minor success.  I was able to get the modem port in the Grid Compass
working with yet another patched Generic Kermit but the file transfer would
not work.  There is some problem with either parity, number of stop or data
bits.  It seems that each one of these built-in modems behave differently
and are located in differently addresses.  I am currently trying to get a
version of Kermit working for the Kaypro 2000 but I lack address information
about the modem port.  I called Kaypro directly but they would like users to
ask their dealers.  The only Kaypro rep got fired so there is no direct line
to information.  I need to know where the modem is located (memory or
ioport) and what the busy bits are.  Also, if it must be initialized.  In
short, the type of modem if any does it emulate.  If and when I get the
patched version working, I will make it available to any or all interested
parties.

Harvey Iwamoto

[Ed. - Internal modems are poison, but if you're stuck with one I guess this
is what you have to do.  Meanwhile, see below about HP-110 modem port.]

------------------------------

Date: Tue, 22 Oct 85 21:17:23 mdt
From: [e-mail] (Dave Forslund)
Subject: Revised HP 110, Portable Support for MS-DOS Kermit 2.28

Attached is the assembler source for the HP110 Kermit (MSHPX.ASM).  It works
both on the HP110 and the new HP Portable Plus.  Port 1 is the serial port
and Port 2 is the internal modem.  Defaults are even parity and 9600 baud on
the serial port and 1200 baud on the internal modem.  We should have a
version shortly which will also drive the HP-IL RS-232 interface as Port 3.
This new code correctly handles different parity settings and works without
modification on both the HP110 and the Portable Plus.  All of the work on
this code was done by Chuck Aldrich here at Los Alamos.  The separate
assembler source is assembled with MicroSoft MASM and linked with LINK just
has described in the MSKERMIT documentation.  This executable has also been
compressed with MicroSoft's EXEPACK utility before being processed with
MSBMKB.C into a .BOO file.

[Ed. - Thanks Dave!  The files are in KER:MS*HPX.*, available via anonymous
FTP from CU20B (by those who have fixed their host tables as shown above).]

------------------------------

Date: Sun 20 Oct 85 22:13:21-EDT
From: Joe Smith [phone] <[e-mail]>
Subject: New TI Pro Support for MS-DOS Kermit 2.28

About 6 months ago, my colleague Dan Smith tried sending you the updated
versions of the sources for MS-DOS Kermit 2.28 running on the Texas
Instruments Professional.  Apparently they did not get there.  The version
in question has H19 and Tektronix emulation and works at 9600 baud.  I have
uploaded them again. Please delete KER[MIT]:MSXTEK.ASM on both MARKET and
COLUMBIA - that file has been replaced by MSYTIP.ASM.  Please update
MSAAAA.HLP and MSBUILD.HLP to reflect the new name.

                Joe Smith

[Ed. - Thanks, Joe!  The files are available on CU20B as KER:MS*TIP.*.]

------------------------------

From: John Voigt, Tulane Univ. Systems Group <[e-mail]>
Date: 10/20/85 13:02:43 CDT
Subject: Fix for Z100 MS-DOS Kermit

August Treubig of Middle South Services discovered a bug in the Z100
version of KERMIT.  It caused MS-DOS to crash.  The fix is in the GETBAUD
routine; the call to bios_auxfunc should be surrounded by "push di" and
"pop di".

[Ed. - Thanks; the change has been made in the source file, MSXZ10.ASM, and
added to the Z100 Kermit beware file.  The .BOO file is still based on the
original source until the next release of MS-DOS Kermit.]

------------------------------

Date: 11 Oct 1985 0118-EDT
From: (Carl Houseman, GENICOM Corp., via) EIBEN@DEC-MARLBORO
Subject: MS-DOS Kermit Key Definitions for EDT

I've uploaded two files which make life for the IBM-PC/Kermit user
who also uses EDT a little easier.  Together they provide all the keypad
editing functions of EDT to the PC user.  They are:

MSIVT1.EDT    - An EDT initialization file which defines the numeric
                keypad functions to match a VT-100 layout.  Use of this
                file when editing on a VT-100/VT-220 is harmless, but
                those using "real" VT-52's should not invoke it.

MSIVT1.INI    - Defines the numeric keypad and function keys as to
                match VT-100 function keys as closely as possible, as
                follows:

                F1=PF1  F2=FP2  F3=PF3  F4=PF4  F5=backspace  F6=linefeed
                F7=up-arrow  F8=down-arrow  F9=left-arrow  F10=right-arrow

                The numeric keypad is the same as a VT-100 where the keys
                are the same, with the PRTSC key acting for the VT-100
                keypad comma, and the "+" key acting for ENTER.  The
                8, 4, 6 and 2 keys become cursor keys when SHIFT is held.

If the 5 key fails to work correctly (can't effect BACKUP while in EDT),
press the NUM-LOCK key.  Also note that an "=" will appear at the top left
of the screen after starting EDT; this is a problem with Kermit's VT-52
(Heath-19) emulation, and the "=" is not really in the file.  It does
not re-appear after scrolling off the screen.

Carl Houseman
GENICOM Corp.
703-949-1323

[Ed. - These files available in KER:MSIVT1.* on CU20B.]

------------------------------

Date: Sun 20 Oct 85 13:08:20-PDT
From: Carl Fussell <[e-mail]>
Address: Santa Clara University
Subject: MS-DOS Kermit and DTR

If anyone is interested, we have added a SET DTR ON/OFF command to the IBM
PC version of Kermit...  we also found that it was needed for some of the
communication we do.  We did not submit it back to Columbia since it was
only added to this one version.  If you would like a copy, contact me.  If
anyone is interested, I will upload it to my guest account at Score where it
can be ftp'd.  As I recall, the changes were only in a couple modules.

Carl

[Ed. - Again, the problem here is that in inordinate amount of research and
effort would be required to add DTR control to all the different versions of
MS-DOS Kermit; the MSX*.ASM system-dependent modules would have to be
redesigned, possibly resulting in damage to systems that the new design
could not be readily tested on, etc.  Far better to supply a trivial little
program for toggling DTR, and define macros in Kermit for running it with
Kermit's RUN command.]

------------------------------

Date: Mon, 21 Oct 85 20:06:40 est
From: George Wyncott <[e-mail]>
Subject: C-Kermit 4C(056/057) and MacKermit 0.8(33)

Two of our staff members with Macintoshes reported the following problem:

C-Kermit 4C(056/057) seems to fail when used with MacKermit 0.8(33).
C-Kermit version 4.2(030) PRERELEASE #2 works correctly under normal
conditions.  Here's what happens with versions (056) and (057):

1. C-Kermit is executed interactively and given the "r <file>" command.

2. MacKermit is directed to send the file.

3. C-Kermit receives the file completely.

4. MacKermit continues to resend the end-of-file packet (B) continuously.

It appears that C-Kermit is not acknowledging the B packet correctly,
causing MacKermit to cycle endlessly and preventing the end-of-transmission
(Z) packet from being exchanged.

HERE'S THE STRANGE PART: If you give C-Kermit the "log debug" command
before the "r <file>", the exchange takes place without error - C-Kermit
gets the Z packet.

NOW HERE'S ANOTHER STRANGENESS: C-Kermit 4.2(030) works the opposite.
You get a correct transfer UNLESS "log debug" is commanded.  Then it
hangs up just like versions (056) and (057).

     George Wyncott
     [e-mail]

[Ed. - The problem can probably be traced to how C-Kermit sends out the ACK
to the B packet, and then closes the line.  Unfortunately, Unix tends to
close the line while sending out the packet is still on its list-of-things-
to-do-when-it-gets-around-to-them...  Solution: flush the output queue
before closing the line.  Or if that adds too much system-dependent hair,
sleep(n) before the close.  The program currently does a sleep(1), but it
may be that more than a second is needed for busy systems and/or low baud
rates, so maybe n should be some function of these.]

------------------------------

Date: Mon Oct 21 21:55:09 1985
From: Herm Fischer <hermix![e-mail]>
Reply-To: HFischer@USC-ECLB
Subject: 2400 Baud Modems with MNP "Protocol"

I looked (briefly) into the new 2400 baud modems for use with my Xenix
system.  The dealers all push versions with a built-in protocol called
MNP.  This protocol handles retries of bad characters, BUT (e.g., beware)
it is not really suitable for use on communications where the underlying
software already has a protocol.

With uucp, the MNP flow control will be incompatible, and thus one will
have to disable MNP.

With Kermit, MNP is likely to play havoc particularly where the end-to-end
flow control needs to be preserved (likely at 2400 baud on systems which
might become busy), because MNP only appears to support modem to computer
flow control.

For interactive computer access, if you need control-s or control-q, e.g.,
if you use an editor like emacs ever, then again you might have difficulties.

The people who produced the MNP protocol, and whose marketing has caused the
modem suppliers to energetically advertise its features (without being
knowledgable of its operation), ended up recommending that I buy some other
modem without the feature.

Finally, be aware that MNP is only a retry on error protocol; it is not a
forward error correction device with Hamming codes (as I expected from its
sales literature).

[Ed. - Thanks for the comments, Herm.  Any further discussion of MNP and/or
X.PC in relation to Kermit would be most welcome here.]

------------------------------

Date: Fri, 18 Oct 85 19:42:31 EDT
From: RAF@UMDC
Subject: Update on Crosstalk Problems

The latest word from Microstuf customer support is that both problems
that I encountered with Crosstalk XVI 3.6 Kermit support will be fixed
"soon".  The two problems are not stopping at the Control-Z in a text
file and setting the wrong screen intensity in the KERMIT LIST command.

Roger Fajman  <RAF@UMDC>
National Institutes of Health

------------------------------

Date: Sat, 19 Oct 85  23:07 EDT
Subject: CMS Kermit "Enhancements"
From: ("Bob Shields <VBOB@UMDB>") <@UMD2.UMD.EDU:[e-mail]>

In one of the latest "info-kermit" digests I read that someone had modified
CMS Kermit to "automatically" expand tab characters to 8 column boundaries.
If this is being considered as a standard operation, I would like to cast my
vote against it.  I have found that XEDIT will expand tabs just fine (see
the "EXPAND" and "COMPRESS" commands), and will do it to whatever columns
*I* specify, not just every *8*.  I more often use a tab setting of every 4
columns, and sometimes use ones that are not at fixed intervals (like 10,
16, 30,...  for CMS ASSEMBLE files).  Maybe this can be resolved with "yet
another SET command" in CMS Kermit.

[Ed. - You're right, it shouldn't be hardwired into the program.]

------------------------------

From: Sheldon Talmy <[e-mail]>
Date: 19 Oct 85 18:36:58 PDT (Sat)
Subject: Kermit for the Blind

In response to your msg about "Kermit for the blind", there is a great deal
being done for the visually handicapped in conjunction with computers.

One company I suggest is IRTI:

Innovative Rehabilitation Technologies Inc.
26699 Snell Lane, Los Altos Hills,Ca, 94022
415-948-8588

They have a huge catalog of products for the visually impaired, including
synths & entire turn-key systems.  If nothing else, the man who owns
the company is an excellent resource for info on the latest products.

I've been writing articles on computers for the handicapped for the last couple
of years, & have gathered several sources for products, that are ready to go
now.  If I can be of any help, send me a msg, & I'll be happy to assist you.

I note from other messages on the subject, that some research is going on that
could conceivably come under the heading of "re-inventing the wheel".
As i'm involved in the field, I might possibly be able to save time & effort,
so contact me if you like.

Shel Talmy<>Talmy@Rand-Unix

------------------------------

Date: Sat, 19 Oct 85 09:07:59 EST
From: pur-ee![e-mail] (Mike Spitzer)
Subject: Kermit for the Texas Instruments 99/4A??

I've heard someone mention this... does Kermit exist for the 99?  If not,
why not?

          Mike

------------------------------

Date: Wed 23 Oct 85 16:01:10-EDT
From: [e-mail]
Subject: Kermit on Diskette for Terak?

     I have a Terak which I am trying to use as terminal for the flourscence
center vax.  I would like to be able to transfer Kermit to the Terak.  If you
know of anyone who has(had) a Terak and has Kermit on 8 inch single density
floppies, please send me mail.

                     Thank you,
                          Miriam Gulotta  ( MG1k@cmcctc)

[Ed. - Can anyone help?]

------------------------------

End of Info-Kermit Digest
*************************
-------
28-Oct-85 15:45:11-EST,8780;000000000000
Mail-From: SY.FDC created at 28-Oct-85 15:43:16
Date: Mon 28 Oct 85 15:43:16-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #27
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Mon, 29 Oct 1985       Volume 3 : Number 27

Departments:

  ANNOUNCEMENTS -
    CU20B Address, Info-Kermit-Request Mail Trouble
    New Release of BBC Acorn Kermit
    Kermit for GEC-4000 Minicomputers
    New ACT Apricot Support for MS-DOS Kermit 2.28
    Kermit for RMX86

  MISCELLANY -
    MacKermit vs Cray
    C-Kermit 4.2(030) Source Wanted
    VMS Kermit-32 bug fix
    CMS-Kermit Expanding Tabs on Receive
    C-Kermit on Diskette for Chromatics 7900?

----------------------------------------------------------------------

Date: Mon 28 Oct 85 12:42:42-EST
From: Frank da Cruz <[e-mail]>
Subject: CU20B Address, Info-Kermit-Request Mail Trouble

Apologies to all who have had trouble with the host address change for CU20B.
It was announced correctly in the last issue of Info-Kermit, but unfortunately
it was reported incorrectly to the NIC, which had CU20B listed as [128.59.32.1]
rather than [128.59.32.128] for several days.  Apologies also to those who
had trouble mailing to Info-Kermit or Info-Kermit-Request at CU20B, even when
the host address was right -- it all started when a disk filled up...
Everything should be back to normal now.

------------------------------

Date: Mon 28 Oct 85 12:42:30-EST
From: Frank da Cruz <[e-mail]>
Subject: New Release of BBC Acorn Kermit

This is to announce Version 1.02 of BBC Acorn Kermit from Alan Phillips of
Lancaster University, UK.  It includes significant improvements and bug
fixes over the current release, and is in extensive use in the UK.  The files
are in KER:BBC*.* on CU20B, available via anonymous FTP.

------------------------------

Date: Mon 28 Oct 85 12:45:02-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit for GEC-4000 Minicomputers

This is to announce Kermit for the British GEC 4000 Series minicomputers with
OS4000/RAL from Martin Loach of Rutherford-Appleton Laboratories.  The files
are in KER:GEC*.* on CU20B.

------------------------------

Date: Mon 28 Oct 85 12:50:08-EST
From: Frank da Cruz <[e-mail]>
Subject: New ACT Apricot Support for MS-DOS Kermit 2.28

This is to announce a new release of the ACT Apricot support for MS-DOS
Kermit 2.28 from Ralph Mitchell of Brunel University, Uxbridge, Middlesex,
UK.  The files are in KER:MS*APR.* on CU20B.

------------------------------

Date: Mon 28 Oct 85 12:52:52-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit for RMX86

This is to announce a second Kermit program for Intel x86/xx systems with
the RMX86 operating system.  This one is written in PL/M by Robert Schamberger,
Wilson Lab, Cornell University, Ithaca NY 14583.  It is available on CU20B as
KER:RMX*.* (the other one is in KER:I86*.*; they are completely different
programs -- reviews or comparisons would be appreciated).

------------------------------

Date: Tue, 22 Oct 85 12:18 pst
From: "pugh jon%b.mfenet"@LLL-MFE.ARPA
Subject: MacKermit vs Cray

I have been trying to use the MacKermit version 0.8(33) with our Cray
supercomputers and it has failed to go.  I have an earlier version of
Kermit from Stanford that does work.  The PC Kermit also works, but only
version 2.27 which is because it ignores an echoed packet, or so I am told.

I have tried using Kermit-PC version 2.26 with our Crays and it exhibits
the same symptoms MacKermit does.  I was wondering if MacKermit could be
modified by the creator there at Columbia to ignore the echoed packet that
gets returned.  Perhaps an investigation into the changes between the two
versions of Kermit-PC would be helpful.  I am willing to help in any way
that I can, including lots of testing.

For information purposes, I am a consultant at the National Magnetic Fusion
Energy Computer Center in Livermore, California, and we have users all over
the country using our four Crays.  It would be beneficial if we could have
Kermit working for all the physicists trying to use their Macs with our
Crays.  I would personally hate to see people forced to use a PC.  Yuck!

                                                Yours Truly,
                                                  Jon Pugh

[Ed. - MacKermit suffers from a bug endemic to all the current releases of
C-Kermit, having to do with padding.  The problem is that whenever padding
is being used, and the padding character is not null (0), the checksum is
calculated incorrectly, and seems to only effect the Crays, since they are
the only ones that need non-null padding on Kermit packets.  The problem
will be fixed in the next release.]

------------------------------

Date: Wed, 23 Oct 85 10:34:39 CDT
From: Gregg Wonderly <[e-mail]>
Subject: C-Kermit 4.2(030) Source Wanted

We want to update our Kermit server to the current release level, but have
misplaced the original source we worked from, preventing us from getting
diffs to show the changes we have to install to the current release.  Does
anyone out there have vanilla source for the C-Kermit which announces itself
as "C-Kermit 4.2(030) PRERELEASE # 2, 5 March 85"?

------------------------------

Date: Fri, 25 Oct 85 16:35:33 edt
From: [e-mail] (John Owens)
Subject: VMS Kermit-32 bug fix

Here is code for two changes to VMS Kermit 3.1.066.  In the diffs I changed
the version number to 3.1.067, but you should do whatever is appropriate with
that.  The first change is to the VMSMSG module to correct a bug with CRC mode.
Previously, if you sent 8 bit data without 8 bit quoting, the CRC would be
computed incorrectly, since the code stripped the high bit if parity was none.
The fix is just to reverse the condition and strip the high bit if the parity
is NOT none.  Diffs to the .MAR file are enclosed, but you should rebuild it
from the .BLI file instead - my changes are just hacks by hand, since I don't
have a BLISS compiler.

[Ed. - Code omitted, but added to KER:VMSMIT.BWR.]

The second change is optional, and is just my preference.  This change, to
the VMSMIT module, makes FINISH not cause the program to exit, but just to
return to the Kermit-32 prompt, so that, for example, statistics could
be printed.  This agrees with what C-Kermit does, but I believe Kermit-20
exits the program on a FINISH....  Remember not to even bother with the diffs
to the .MAR file if you have access to a Bliss-32 compiler - my changes are
definitely not what the compiler would do.

[Ed. - Code also omitted, but added to KER:VMSMIT.BWR.]

John Owens                UUCP:
General Electric Company          ...!decvax!mcnc!ncsu!uvacs!edison!jso
Factory Automated Products Division    Compuserve: 76317,2354
Charlotesville, VA            Phone:    [phone]

------------------------------

Date: Sun, 27 Oct 85 21:44:59 pst
From: [e-mail]
Subject: CMS-Kermit Expanding Tabs on Receive

I struggled over whether to expand tabs during receive or not.  Clearly
leaving the file alone is more flexible for the experienced CMS user.
However, most of our users do not want to bring up XEDIT and EXPAND tabs on
every file they upload.  Most of the systems that use Kermit to send to CMS
use the tab8 convention and use it freely without the users direct knowledge
of it (msdos,cpm,unix).  I have decided to make tab expansion on receive the
default and use a modeless prefix to disable it.

Also, that mod I submitted (UCB09) is flawed because it depends on being
able to overflow the ARBUF by 8 characters which is only OK because
CMS-Kermit 2.01 misallocates the buffer in the first place.  Please remove
UCB09 until I fix it.

Greg Small                                    [phone]
Microcomputer Networking & Communications     [e-mail]
214 Evans Hall CFC                            ucbvax!ucbjade!ucbopal!gts
University of California                      [e-mail]
Berkeley, Ca 94720

------------------------------

Date: Fri 25 Oct 85 13:14:50-EDT
From: Frank da Cruz <[e-mail]>
Subject: C-Kermit on Diskette for Chromatics 7900?

Gina Morinaka of Hercules Aerospace in Utah needs to get C-Kermit on an
8" diskette for the Chromatics 7900 workstation.  If you can help her,
please call 801-250-3776.

------------------------------

End of Info-Kermit Digest
*************************
-------
 1-Nov-85 17:11:24-EST,12809;000000000000
Mail-From: SY.FDC created at  1-Nov-85 17:10:48
Date: Fri 1 Nov 85 17:10:48-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit-Digest V3 #28
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri,  1 Nov 1985       Volume 3 : Number 28

Departments:

  ANNOUNCEMENTS -
    Pascal/VS Kermit/CMS
    7171 Support for IBM Mainframe MUSIC Kermit
    Another Kermit for Intel Micro Development Systems

  MISCELLANY -
    We Are Working on a Robust Kermit for IBM MVS/XA TSO
    7171/Series 1 and Kermit-MS interaction
    Problems with New HP-110 MS-DOS Kermit Support
    Commodore-64 Kermit V1.7

  QUERIES -
    Need Kermit Diskette for IBM PC with Xenix
    Need Kermit 3.5" Diskette for HP-9816
    Need Kermit Diskette for HP-9000/S500 HP-UX System

----------------------------------------------------------------------

Date:    Thu, 31 Oct 85 10:06 EST
From:    [e-mail]
Subject: Pascal/VS Kermit/CMS

I am sending you an updated source for my Pascal KERMIT/CMS along with an
updated FULLSERV ASSEMBLE file.  The new source will handle some additional
server commands and fixes some minor bugs.  A major bug shows up when using
the old KERMIT source with the newer version of the PASCALVS compiler which
does a more careful checking of strings.  The updated source will correct
this fault.

[Ed. - The files are in KER:CM2*.* on CU20B, available as usual via
anonymous FTP.]

------------------------------

Date: 24 October 1985, 16:58:52 EST
From: [e-mail]
Subject: 7171 Support for IBM Mainframe MUSIC Kermit

Here is a new version of KERMIT for MUSIC (IMUSIC), based on the
Indiana/Purdue original, but with support for the 7171 front end added,
approved by the original author Marie Schriefer at INDYVM.
                                                    J.V.

[Ed. - The files are on CU20B as KER:IMUSIC.*.]

------------------------------

Date: Fri 1 Nov 85 4:21pm EST
From: Frank da Cruz <[e-mail]>
Subject: Another Kermit for Intel Micro Development Systems

This is to announce yet another version of Intel Microcomputer Development
System (MDS) Kermit, for the ISIS operating system, written in PL/M.  It's
an upgrade to the original version, and adds the ability to talk to a Kermit
server (GET, FINISH, BYE, (remote) CWD) and a way to send multiple files
using a special command LSEND that reads the list of files to send from the
specified file.  It was submitted by

  Hanh Tuan Truong
  Leigh Instruments ltd.
  2680 Queensview Dr.
  Ottawa, Ontario
  K2B-8J9 CANADA

The files are in KER:MD2*.* on CU20B.  The MDS*.* files are still there too.
It seems that this new version is based on the original release of MDS
Kermit, which in the interim was updated & fixed at Intel's DSSO department.
If anyone who cares about these systems would care to do a comparitive
review for Info-Kermit, it would be most welcome.  Better still would be an
integration of the two programs into a single one.

------------------------------

Date: 29 Oct 85 1500 WEZ
From: [e-mail]  (Franklin A. Davis)
Subject: We Are Working on a Robust Kermit for IBM MVS/XA TSO

We have a robust version of Kermit for TSO systems that is adapted from the
CMS Pascal Kermit.

It includes server mode with most of the possible remote commands.  In local
mode you can execute TSO commands from within Kermit.  Coming soon will be
wildcards, though that is tough on an IBM...

MVS and CMS are so different that it will not be possible to have a single
version for both systems.  However, Fritz will be maintaining it for at
least the next couple of years.

Anyone interested in 'Beta test' of TSO kermit, please contact us directly.

-- Fritz & Franklin <[e-mail]>
Institut fuer Informatik und angewandte Mathematik
Universitaet Bern
Laenggassstrasse 51
CH-3012  Bern
Switzerland

[Ed. - How about Series/1 (4994, 7171, ...) front-end support?  We're
getting such a proliferation of MVS/TSO IBM mainframe Kermits -- versions in
assembler, Pascal, and PL/I, with and/or without Series/1 support, ...

1. U of Chicago's, based on Columbia's original (primitive) CMS Kermit, only
   for use on line-mode TTYs.

2. U of Toronto's, based on Chicago's but only for use thru Series/1 or 7171.

3. Rice University's, supposedly fancy, in PL/I, but you have to buy their
   support functions from them.

4. University of Maryland is working on yet another completely different,
   fancy TSO Kermit (in assembler?).

5. And now this one.  Not to mention the two versions for VM/CMS; when it
   rains...]

------------------------------


Date: Fri, 01 Nov 85 11:05:31 cet
From: [e-mail]
Subject: 7171/Series 1 and Kermit-MS interaction

We have found that our new 7171 protocol converters work much less well for
us than the Series 1 boxes for Kermit file uploading with the newer
generation of IBM-like PCs.  The symptoms are a 7171 hang up when uploading
files from the PC AT or Zenith 158s over 9600 bps direct connect lines.  We
have been using Kermit heavily for about a year, and normally these devices
upload fine, but if the Kermit-MS 2.28 they are running is YAKing faster
than normal due to (1) use of a mono screen (2) use of a faster crystal (3)
use of FANSI-CONSOLE to speed screen writing, then the 7171 hangs in a
pretty big way.  Multiple master resets must be sent to the 7171 to get
session control back again.  If one SETs DEBUG ON in Kermit-MS, then the
time spent writing the packets to a color screen slows things down enough
to work unless FANSI-CONSOLE is in there speeding things up again.  The
evidence is as follows:

Connected through 7171 to Kermit-CMS 2.01:
IBM PC AT, 8mhz, EGA & ECD, with DEBUG OFF --> failure
IBM PC AT, 8mhz, EGA & ECD, with DEBUG ON  --> success
As above w/ FCONSOLE, DEBUG ON or OFF      --> failure
Zenith 158, 8mhz, monochrome, DEBUG ON|OFF --> failure
Zenith 158, 8mhz, color, DEBUG OFF         --> failure
Zenith 158, 8mhz, color, DEBUG ON          --> success

Connected through a Series 1 all of the above succeed.  The SEND PACKET in
all cases was 64 since the 7171's won't work from my AT under any
conditions with a larger size.  The only conclusion I have been able to
draw is that the slow screen writing routines of the color BIOS slow
Kermit-MS down enough such that when DEBUG is ON the YAK packet from
Kermit-MS does not go back until the 7171 is ready.  I assume this is
because the incoming packet is being written to the screen before the YAK
is sent (though I have not checked the Kermit code to verify this).  I am
inferring that the problem is due to the 7171 because (1) it works through
the Series 1 (2) many Master Resets are required to wrest control back, but
conceivably the issue is one of CMS Kermit's control of the 7171 rather
than the box's internals.

Any suggestions or relevant experiences would be appreciated.
Michael Palmer
Washington University Computing Facilites
Bitnet address:  PCSC@WUVMD

------------------------------

Date: 26 Oct 1985 2242-EDT
From: LCG.KERMIT@DEC-MARLBORO
Subject: Problems with New HP-110 MS-DOS Kermit Support

Took the new version of MSXHPX.ASM last night.  Unfortunately, in being
compatible with both the 110 and the PLUS, it develops several problems on
the plus.  In particular:

1. PORT 2 is set to AUX.  On the plus, this is not the INTERNAL MODEM
necessarily, but is the default modem set in the system configurator.  To
insure that the internal modem is used, the PORT selection logic should
select COM3, not AUX.

2. All character output is being sent to the punch via MSDOS PUNOUT call.
This is slow, and, worse, will direct output to AUX even if the serial port
is in use.

3. Minor points: the program starts with even parity and 7 bit words.  This
causes chaos in every situation we tried.

Changes are shown below by giving at least one line before and after each
change.  Would appreciate your forwarding to appropriate authority.

Also, leaving DTR on on the PLUS is not just a nuisance, it is deadly, since
you also leave on the MODEM or SERIAL interface, which eats the battery at
incredible rates.  I have attached to the end of this a short program to
turn those off.  I run KERMIT on the plus from a command file KERMIT.BAT
which contains the following:

    MSXHPX 1%
    MODEMOFF

This guarantees modem/serial port doesn't run down battery.

Mike Mellinger  800-325-0888

Modified MSXHPX follows:

[Ed. - Code omitted, included in KER:MSXHPX.BWR for now; see next message.]

------------------------------

Date: Mon, 28 Oct 85 23:08:28 mst
From: [e-mail] (Dave Forslund)
Subject: Re: Problems with New HP-110 MS-DOS Kermit Support

In response to the problems with MSXHPX on the Portable Plus:

1. We felt the choice of the AUX port was an advantage because one could
also choose the HP-IL loop RS-232 interface from the PAM without having to
add an additional port in kermit itself.  It is true to use the modem with
Kermit one must have selected it in the PAM.  However, if it is selected
then port 1 is the serial port and port 2 is the modem (or HP-IL RS-232).
Choosing COM3 for the Portable makes the code incompatible with the HP-110.

2. We used this call as it was in the generic Kermit.  We will try this
suggested fix.

3. Our choice of even parity and 7 bit words is what works on our network
here at Los Alamos and avoided us having to have a .ini file to modify the
defaults.  If others like other defaults, so be it.

4. Thanks for the modemoff file.  It will be a big help.

By the way, for this code to work properly on the internal modem in the
HP110 still requires some work, as the modem does not respond
conversationally but requires special ioctl commands to dial, etc.  We have
not pursued this any further.

Dave ([e-mail])

------------------------------

Date: Sat 26 Oct 85 13:05:13-EDT
From: [e-mail]
Subject: Commodore-64 Kermit V1.7
To: [e-mail]

Kermit 1.7 for the Commodore 64 is completely non-functional.  There is a
bug in the VT52 emulation routines which crashes the program every time I
attempt to use Emacs.  This same bug crashes the program whenever I try to
send or receive a file, since the current packet, number of packets sent,
etc, are displayed on the screen using the same routines.  Does a quick fix
exist for this problem, or do I have to wait for the next version of Kermit
for the problem to be fixed.  As it stands, Kermit 1.7 is completely useless
for file transfer.  HELP!!!!

                Roger Preisendefer
                RP0Q @ CMU-CC-TD


[From Eric <[e-mail]> - C64 Kermit-65 V1.7 works fine at
300 baud or 1200 baud.  There are no bugs in the VT52 emulation, and no
'serious' (or well known) bugs in the file transfer routines.  Chances are
this person did not download the files correctly to his C64 - I use Kermit
with Emacs extensively and send files all the time with much sucess.  I
suggest that this person send away to Robert Lenoil for a C64 Kermit
diskette -- 229 Commonwealth Ave, Boston MA 02116 -- $7.00 incl postage.]

------------------------------

Date: Tuesday, 29 October 1985 07:30:30 EST
From: [e-mail]
Subject: Need Kermit Diskette for IBM PC with Xenix

I would like to have a kermit on my IBM PC running under Xenix (and
talk to the MS-DOS PC).  Where can I get a copy of one?

Sriram

------------------------------

Date: Tue 29 Oct 85 14:28:43-EST
From: Frank da Cruz <[e-mail]>
Subject: Need Kermit 3.5" Diskette for HP-9816

Marilyn Evans, Polaroid Corp, Cambridge MA, 617-577-3662 or -2262, needs
Kermit for the HP-9816.  She thinks the HP-Pascal version that was written
for the 9836 a while back might work.  Could anyone send it to her on a
3.5" diskette so she can try it out?  Thanks!

------------------------------

Date: Tue 29 Oct 85 11:39:33-PST
From: David Liu <[e-mail]>
Subject: Need Kermit Diskette for HP-9000/S500 HP-UX System

Is there anyone ever installed and run Kermit on HP-9000/500 computer (which
runs HP-UX)?  This is what I am trying to do and may save me some of the
efforts if I can get some advise.

Dave Liu@SIERRA-SU

[Ed. - Again, the best thing would be for someone to send him a diskette.
Any volunteers?  (Contact Dave directly)]

------------------------------

End of Info-Kermit Digest
*************************
-------
13-Nov-85 17:53:13-EST,16634;000000000000
Mail-From: SY.FDC created at 13-Nov-85 17:52:28
Date: Wed 13 Nov 85 17:52:27-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #29
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 13 Nov 1985       Volume 3 : Number 29

Today's Topics:
                           Kermit the Frog
                           Kermit the Book
                         New Kermit-11 Coming
                         Kermit for NEC APC-3
           C-Kermit 4C(057), Mackermit 0.8(33), and 2.9BSD
                 Okstate's Kermit Server Active Again
       Binary File Transfer Between C-Kermit and VMS Kermit-32
                  Kermit Problems, Notes and Praises
                      Osborne Executive Kermit?
                          Kermit & MUSIC SP

----------------------------------------------------------------------

Date: Tue 12 Nov 85 15:26:44-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit the Frog

The new (December 1985) MACWORLD Magazine features a cover story on Kermit
-- no, not Kermit the file transfer protocol, but Kermit the Frog, the
proprietor of a whole new line of Muppet-based educational software.
"Kermit" is a trade mark for some of this software, like "Kermit's
Electronic Story Maker."  This is one among the many good reasons why "our"
Kermit should (and can) not become a commercial product.

------------------------------

Date: Wed 13 Nov 85 17:02:22-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit the Book

I'm writing a Kermit book for Digital Press.  I hope it will be out in
Spring or Summer 1986, and I hope the price will be relatively low (it
can't be set yet, because the manuscript isn't done, but there is general
agreement that it should not be a high-priced item).  I hope the book will
be a big improvement over the Kermit User Guide and Protocol Manual; it
will contain all the information from these manuals, plus a lot more --
background in data communications, file organization, etc; more cohernet
organization, lots of illustrations, tables, code fragments, etc etc.  But
it will lack the detailed descriptions of the various Kermit programs found
in the User Guide; that information will continue to be supplied along with
each program.  Anyhow, the idea is for the book to "work" for everyone from
the utter novice to the Kermit programmer, pehaps in conjunction with a
program-specific handout, and to promote Kermit a little more as a serious
protocol and maybe encourage future Kermit program contributors to stick to
the "standard" command syntax a little better and provide code examples to
make it easy for them to include server mode, 8th-bit quoting, etc etc.

Preparing the manuscript, plus doing my "real job," is keeping me pretty
busy, which partly explains the lag between Info-Kermits (the rest of the
explanation is that there hasn't been a lot of activity recently anyway).
Occasionally I might bother someone for a bit of specific information to
round out some table or other.  Here's one tidbit I haven't been able to
dig up anywhere -- what multiplexing technique is used by VA-3400 1200bps
modems (frequency division?) and at what baud rate does it transmit (some
1200bps modems actually transmit at 600 baud).  Here's another one -- does
anyone know the etymology of "D-Connector" or "DB-xx" (as in DB-25)?

Also, if anyone wants to fill in the following questionnaire and send it
back to me, I'd be most grateful.  This is just for purposes of filling in
some illustrative tables, contrasting the diverse communication and
file architectures of various machines and OS's.  I've already got info
for the common ones, like DEC-20, VAX/VMS, IBM VM/CMS, MS-DOS, etc etc, but
am looking more for the "strange" ones -- HP minis, DG minis, P-E minis,
Prime computers, mainframes of Burroughs, Honeywell, Sperry, CDC, etc.

Machine, Model(s):
Operating System:
Version of OS following info applies to, if it makes a difference:
Machine Word Size:

Text Byte Size, and how many bits within byte are used for a character, and
what happens to any leftover bits:

Directory structure (flat file system, 1 level of directory, hierarchical):

Filespec format (indicate punctuation and max length of each field, e.g.
DEV:[DIR]NAME.EXT;n with DEV=6, DIR=12, NAME=8, EXT=3, n=numeric generation.

Text code: (7-bit ASCII, 8-bit extended ASCII, 8-bit EBCDIC, etc):

Normal record separation technique for text files (CRLF, LF, CR, RCW, fixed
block, etc):

EOF indication (nearest character, word, block); what happens at EOF if
EOF not recorded exactly (e.g. CP/M ^Z trick):

Asynchronous Communications (But first please indicate if the system
normally prefers some other style, like IBM-style synchronous block mode
terminals):

Duplex (full, half):

Flow Control (half duplex line turnaround handshake char, XON/XOFF, ENQ/ACK,
ETX/ACK, etc):

Required or default parity:

Special or unusual characteristics worth noting about file system,
text representation, or communications:


Thanks to anyone who responds!  Also, any suggestions of a general (or
specific) nature would be most welcome, especially from people who have had
problems with some aspect of Kermit that could have been avoided by better
documentation.

- Frank

------------------------------

Date: 8 Nov 1985
From: [e-mail]
Subject: New Kermit-11 Coming

 There currently is a version 2.38 of Kermit-11 available.  The version will
only be available via Bitnet or dialup to UOFT02 until December 85 as I am
waiting for modifications from some other people regarding M+ v3 and also
PRO/TMS support. As always, the file K11CMD.MAC has the edit trail.

How to get it:

Bitnet:

from VM/CMS:    CP SMSG RSCS MSG UOFT02 KERMSRV DIR
                CP SMSG RSCS MSG UOFT02 KERMSRV SEND K11*.*

from VMS Jnet:  $ SEN/REM UOFT02 KERMSRV SEND K11*.*

Dialup:

        [phone]
        Service class  VX785A
        User: KERMIT
        Password: KERMIT

Source and hex files are in KER:, binaries are in KERBIN:

[Ed. - I imagine Brian will be sending the successor to 2.38 to Columbia
when it's ready; will announce it when it arrives.]

------------------------------

Date: Fri, 8 Nov 85 13:55:55 est
From: Phil Johnson <[e-mail]>
Subject: Kermit for NEC APC-3

Since you had the source but not the binary for NEC APC-3 Kermit,
I built the binary for you.

Phil Johnson

[Ed. - Thanks!  It's in KER:MSVAP3.BOO ("boo" file) and KB:MSVAP3.EXE
(8-bit binary).]

------------------------------

From: Vic Abell <[e-mail]>
Date:  8 Nov 1985 1438-EST (Friday)
Cc: [e-mail], [e-mail], [e-mail]
Subject: C-Kermit 4C(057), Mackermit 0.8(33), and 2.9BSD

C-kermit 4C(057) does not work properly with 2.9BSD, as distributed
by Berkeley.  It may work with the Harvard, Seismo distribution, but
I haven't tested that.

One problem is that the Berkeley 2.9BSD distrubution does not support
the 4.2BSD timeval and timezone structures and the functions that
surround them.  Thus, all of the #if tests in ckutio.c that assume
2.9 to 4.2 equivalence in that area must be undone.

A second problem is that the protocol rule for <rdata>Z in ckcpro.w
tests for a return value from the function reof() in ckcfns.c  Reof()
does not return a value.  The protocol rule works on 4.2BSD out of
happenstance - apparently the return value register happens to be
non-negative.  Under 2.9BSD it doesn't work - apparently because
the return value register happens to be negative.

I am enclosing diffs that show the changes necessary to eliminate
these two problems.  The diffs for ckcpro.w also include a fix to the
<rfile>B protocol rule that I reported earlier to this mailing group.
It prevents the EOT ack from being lost in interactive mode when the
terminal is switched from cbreak to cooked.  Note that the sleep time
was raised to five seconds on the slower 11/70s.

Vic Abell, [e-mail]

[Ed. - Thanks!  Diffs omitted, appended to KER:CKUKER.BWR, will be
included in the next release.]

------------------------------

Date: Sun, 10 Nov 85 17:42:19 CST
From: Gregg Wonderly <[e-mail]>
Subject: Okstate's Kermit Server Active Again

    Due to an obscure bug in some modifications made to the KERMIT SERVER at
OKSTATE, the server has not been able to service GET requests from users.
This problem has been located, and fixed.  We appologize for any headaches
caused (We had a few here in finding this one).  Thanks to those who pointed
the problems out initially.

Gregg Wonderly
Department of Computing and Information Sciences
Oklahoma State University

UUCP: {cbosgd, ea, ihnp4, isucs1, mcvax, uokvax}!okstate!gregg
ARPA:  [e-mail]

------------------------------

Date: Fri, 1 Nov 85 21:55:26 pst
From: [e-mail] (David Robinson)
Subject: Binary File Transfer Between C-Kermit and VMS Kermit-32

I am having troubles transfering files to and from a SUN-2/170 running
Ckermit 4C(57) and a VAX/VMS3.7 running Kermit-32(66).

Transfering both ways one side or the other is mapping ALL ^J's to ^M's
which reaks havic on my binary data.  I have set file type to binary on
both machines with no success.  When I set file type fixed on the VAX (A
suggestion from a friend) The file makes it thru the data transfer part but
dies on the final handshaking with an error "unimplemented server command".

We are constrained to use only the VAX as a server, our connection allows
logins only on the VAX side.

Any and all help on this problem would be appreciated.

"How to get raw binary files from Ckermit to kermit-32?"

                David Robinson
                [e-mail]

[Ed. - I've heard complaints like this before, but don't have a VMS system
to track them down with, and the folks at Stevens Inst of Tech are badly
bogged down in other work for the time being.  Anybody out there can help?]

------------------------------

Date: Wed 6 Nov 85 21:25:42-EST
From: Christopher Lent  ([e-mail])
Subject: Kermit Problems, Notes and Praises

PROBLEMS:
*****
MSRVRB1.BOO - MS-DOS Rainbow-100 boot file.
The first line of KER:MSVRB1.BOO contains:
    KER:MSRB10.EXE
rather than
    MSVRB1.EXE
A minor oops but it could give a first time user a problem.

[Ed. - Thanks, I fixed it.]

*****
MSSDEF.H - MS-DOS KERMIT macro assembler (MASM) source header file.
    Perhaps a stronger warning should be included that KER:MSSDEF.H
must be renamed to MSDEFS.H before compiling.

[Ed. - Thanks, I put warnings in appropriate places.]

*****
MSIBMP.EXE - Compiling your own:
I compiled MSIBMP.EXE on an IBM/PC-XT using V2.0 MASM with the suggested /S
option and have experienced no problems with the resultant V2.28 IBM-PC KERMIT.
*****

notes:
+++++
MSIBMP.EXE - IBM/PC KERMIT through a DECServer 100:
    I have been using KERMIT V2.27 and now V2.28 through DEC's new
DECServer 100 terminal server.  All I can say is WOW!!  The configuration
consists of a VAX-11/780 with VMS 4.1 running KERMIT-32 V3.1.066 and IBM/PC's,
and XT's running PC-DOS 3.1 and KERMIT V2.27 and V2.28.

    Kermit works fine with the initial settings on the terminal server.
The server doesn't interfere with the KERMIT protocol.  KERMIT file transfers
exhibit no visible loading of either the terminal server or VMS, even at 19.2K
baud.  The local CWD command has greatly aided doing incremental PC/XT backups
to corresponding VMS directories.
+++++
Note - Converting "BINARY" Text files on VAX/VMS created by KERMIT-32.

    Most users doing backups of PC's to our VAX use the KERMIT-32 SET
FILE TYPE BINARY option so the .COM and .EXE files will transfer properly.
This results in a minor problem when text file transferred as "BINARY" files
are to be edited or revised on the VAX.  A workaround procedure for this
follows using the age-old editor TECO.  Since TECO's calling sequence has
changed in VMS 4.x two versions are given.

VMS 3.x:

$ ! Untested
$ TECO :== $SYS$SYSTEM:TECO.EXE
$TOP:
$if "''p1'" .eqs. "" then inquire p1 "Binary file to be converted to text"
$if "''p1'" .eqs. "" then goto TOP
$WRITE SYS$OUTPUT "Converting file ''p1' to text format."
$! the line after edit/teco 'p1' should contain EX<ESC><ESC>
$! where <ESC> is the escape character (decimal 27, octal 33, hex 1B)
$TECO 'p1'
EX$$
$write sys$output "File ''p1' converted to text format."
$exit

VMS 4.x

$! Works!
$TOP:
$if "''p1'" .eqs. "" then inquire p1 "Binary file to be converted to text"
$if "''p1'" .eqs. "" then goto TOP
$WRITE SYS$OUTPUT "Converting file ''p1' to text format."
$! the line after edit/teco 'p1' should contain EX<ESC><ESC>
$! where <ESC> is the escape character (decimal 27, octal 33, hex 1B)
$edit/teco 'p1'
EX$$
$write sys$output "File ''p1' converted to text format."
$exit

Usage:
    If the above file is called CVT.COM in the current directory
simply type type following to convert the "BINARY" text file FILE.BIN
    $ @CVT.COM FILE.BIN
and the new version of file.bin will be in VMS's default text file format.

Beware:
    If the "BINARY" text file has lines which exceed 255 characters,
VMS's EDIT/EDT editor will truncate these lines during editing.
+++++
Praises:
#####
Ckermit - general praises
    Nice Job!!!  I was previously using the version now relegated to the
to the documentation.  The new version work fabulously on our AT&T 3b5
computer.   I've even managed to get a version running on a V6 UNIX system.
The V6 version was compiled using a modified V7 compiler so I doubt it would
be of any use to others.  With quite a bit of emulating V7 system calls,
I produced a working version of Ckermit.  Just a warning, in split I/D spaces
on the PDP-11, some V6 system calls do NOT work.
#####
Final comments:
    Kermit is fabulous.  I now try to get it to friends as a matter of
course.  At first they're a little confused as to why they need Kermit, but
about a month after they come back and say "Wow, how can I get Kermit for
machine XYZ-123/X?" and we figure out how to load the initial copy.
    I must admit I'm a convert.  When I originally read about Kermit in
BYTE, I thought "Oh, yet another ASCII file transfer package".  Reading on I
thought, "Hmm, sounds pretty easy to implement".  Then I put these thoughts on
the back burner for a few years.
    In March of 1985, I found Kermit source on a FIDO BBS system and tried
it on the PC.  It worked wonderfully. They also had 'C' source for a Unix
Version of Kermit. I loaded it on our 3b5 and our V6 system and it worked with
only minor modifications. The BYTE articles made the debugging much more
simple.
                    Keep up the good work!
                    Chris Lent
                    [e-mail]
                    Care of:
                    oc.pedhem@cu20b

------------------------------

Date: Wed, 6 Nov 85 20:38:02 pst
From: George Cross <[e-mail]>
Subject: Osborne Executive Kermit?

Can someone inform me of the status of the Osborne Executive version
of Kermit?  Browsing through the mail archives (83/84 Epoch) one finds
a flurry of interest when the OE  was alive but it seems to have faded
out.  My questions are:

1. Does the Osborne 1 version work on the Osborne Executive?
2. Does the Generic CPM version work on the Executive? If so how?

I don't receive this list regularly, so a mail reply to me would be preferred.
Thanks,

 George R. Cross        [e-mail]
 Computer Science Department    [e-mail]
 Washington State University    [e-mail]
 Pullman, WA      99164-1210    Phone: [phone] or 509-335-6636

------------------------------

Date: Fri, 08 Nov 85 08:57:21 cet
From:  [e-mail]
Subject: Kermit & MUSIC SP

Does anyone know if Kermit-MUSIC 1.0 is compatible with the new
release of MUSIC (MUSIC SP)?  I realize that it contains its own
communications program PCWS, but sites with several operating systems
like ours would prefer to use one program (Kermit!) for all
micro to mainframe communication if possible.

Michael Palmer, Washington University Computing Facilities
BITNET address:  PCSC@WUVMD

------------------------------

End of Info-Kermit Digest
*************************
-------
20-Nov-85 19:26:06-EST,6349;000000000000
Mail-From: SY.FDC created at 20-Nov-85 19:25:31
Date: Wed 20 Nov 85 19:25:31-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #30
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 20 Nov 1985       Volume 3 : Number 30

                            BITNET Things
                     Kermit Over Public Networks?
                        Kermit for the HP-87?
                MVS/TSO Kermit with Protocol Converter?
                        Kermit for Tandy 6000?
                           Cromix Kermit???

----------------------------------------------------------------------

Date: Wed 20 Nov 85 18:44:10-EST
From: Frank da Cruz <[e-mail]>
Subject: BITNET Things

Due to a change that was made in CU20B's host tables some time between Oct 24
and Oct 29, Info-Kermit mail destined for BITNET was lost.  The affected
issues were V3, Numbers 27, 28, and 29.  The problem is now fixed.  I will
remail these three issues to all the BITNET members after this issue goes out.
Sorry for the inconvenience.

Speaking of BITNET, those who access the Kermit file collection via the
BITNET Kermit file server, KERMSRV at CUVMA, may have noticed two things, one
good, one bad: (a) the KERMSRV server itself has been behaving a lot better
lately, and (b) the Kermit files have not been updated in several weeks to
reflect recent announcements.  (a) is because our IBM systems folks have
been working on KERMSRV, mostly in an effort to reduce network overhead by
queuing files according to length, discarding duplicated requests etc.  An
announcement about exactly what was done should appear shortly.  In the
meantime, send the HELP command to KERMSRV to learn about any changes or
new commands.  (b) is because the person who used to keep the BITNET area up
to date has changed jobs and has not been replaced yet; I hope the situation
will be remedied soon.

------------------------------

Date: Wed 20 Nov 85 18:44:10-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit Over Public Networks?

I know this has been hashed over before several times in the past, but I'd
like the gather all the relevent information together into one place
(the Kermit book)...  What experiences have people had using Kermit over
the public networks?  These include Tymnet, Telenet, Uninet, Datapac,
Transpac, Datex-P, and all the ones I don't even know about.  Here's a short
questionnaire:

Name of Network (spelled and capitalized as the vendor prefers):

Company or Organization that "owns" it:

Country or Area covered:

What are the characteristics and peculiarities of the network?  Sacred
characters, delay, transmission wakeup (does a Kermit packet correspond to
a network packet?), etc...

Could you make Kermit file transfer work at all?  If not, what was the fatal
impediment?  If so, what tricks were necessary?  These include SET commands
to Kermit itself (for parity, packet length, retry threshold, timeout, flow
control, handshake, etc; what particular parameters and values are necessary?),
and commands to the network (the local or remote node or PAD).

If anyone would like to answer the same questions as they apply to RS-232
connections through local area networks -- Sytek, DEC LAT, etc -- please do.

Thanks in advance!

P.S. And thanks to all those who responded to my previous questionnaire about
computer file systems and communications -- I learned about Honeywell/MULTICS;
Sperry 1100/OS 1100; HP-1000 (partly); PDP-11/RT/RSX/RSTS/POS; UCSD p-System;
Prime/Primos; Os9.  Any more out there?  HP-3000?  Data General?  CDC?  Cray?
Gould?  Perkin-Elmer?  PDP-8?  Burroughs?  Honeywell GCOS?  Lisp Machine?  Etc?

------------------------------

Date: Thu, 14 Nov 85 02:18:55 -0100
From: hans@oslo-vax (Hans A. ]lien)
Subject: Kermit for the HP-87?

Kermit for Hewlett Packard Series 80 is needed by a colleague.
A version working on the CP/M-extension card would also be of some help...

------------------------------

Date: Thu 14 Nov 85 11:39:37-EST
From: Michael Fuchs <[e-mail]>
Subject: MVS/TSO Kermit with Protocol Converter?

Does anyone have any experience using either the U of Chicago or the
U of Toronto MVS/TSO Kermit in the following enviroment (or similar):

    AMDAHL V8470
    MVS/SP3 (will have MVS/XA)
    using TSO
    through protocol converter (asynch to SNA) to COMTEN

Any tips, assurances, bewares, "no problem, pal"'s, or "won't work"'s
gratefully appreciated.

Michael Fuchs
Coefficient Systems Corp.

[Ed. - If the protocol converter is a Series/1 or equivalent running the
Yale ASCII Communication system or equivalent, then the Toronto version
should do the trick.  Other sites are reportedly adding support for additional
protocol converters to MVS/TSO or VM/CMS Kermit or both.  Again, recall that
this can only be done for those protocol converters that all the host to
put them in transparent (pass-through) mode and take them out again.]

------------------------------

Date: 12 Nov 85 01:52:34 GMT
From: Yosef Gold <ihnp4!aecom![e-mail]>
Subject: Kermit for Tandy 6000?

I am looking for the tandy 6000 version of Kermit.  The Tandy is running
Xenix.  I have no way to load it off tape.  The ideal would be either a
floppy or email.

      Yosef Gold
      ...{ihnp4,rocky2,philabs,esquire,cucard,pegasus,spike}!aecom!gold

------------------------------

Date: 20 November 1985, 17:08:08 MEZ
From: Eberhard W. Lisse <[e-mail]>
Subject: Cromix Kermit???

Has anybody got a net-adress for the

           Losinger, AG in Berne/Switzerland

who are according to a rumor ( AAWAIT HLP on CUVMA.BITNET ) working
on an implementation for CROMIX?

As I am based in Germany a surface mail adress would do as well.

Also does anybody know about an implementation for an ICL 2900 under TME ?

Thanks in advance,

el


Eberhard W. Lisse  <zdv626%djukfa11.bitnet%wiscvm.arpa>
                   <psuvax1.uucp!djukfa11.bitnet!zdv626>

------------------------------

End of Info-Kermit Digest
*************************

-------
27-Nov-85 11:55:40-EST,18568;000000000001
Mail-From: SY.FDC created at 27-Nov-85 11:54:55
Date: Wed 27 Nov 85 11:54:55-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #31
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 27 Nov 1985       Volume 3 : Number 31

Departments:

  ANNOUNCEMENTS -
    PDP-11 Kermit Now Available for IAS 3.1
    Kermit in C for DG MV Series with MV/UX
    New Release of Burroughs B7900 Kermit
    Another Kermit for Intex RMX Systems
    VMS Hexify/Dehexify Fix
    IMUSIC - MUSIC Kermit w/7171 support

  UNIX KERMIT -
    More notes on C-Kermit 4C(057)
    More on Masscomp Running C-Kermit 4C(057)
    Zilog Zeus Kermit, Os9 Kermit Warning
    Problems with MacKermit for the Macintosh version 0.8(33)

  MS-DOS KERMIT -
    MS-DOS Kermit V2.28
    Hardware Upgrade for some Professional Graphics Controllers
    ROMing MS-DOS Kermit

  MISCELLANY -
    ETX/ACK Flow Control?
    Problem Downloading Files with Apple II Kermit

----------------------------------------------------------------------

DATE: 25-NOV-1985
FROM: BRIAN@UOFT02
SUBJECT: PDP-11 Kermit Now Available for IAS 3.1

This is to announce that a version of Kermit-11 for IAS 3.1 is available.
Due to source incompatibility, only the task image and hexified task image
will be made generally available.  The complete sources will be archived at
UOFT02 in directory KERIAS: available from dialup access, and a copy of the
sources will be sent to Frank when I send the K11 update the first week of
December.  Doc and HEX files are in KER: as K11I31.* and KERBIN:K11I31.TSK.

Many thanks to Gene Costello and Bruce Wright of the EPA for this version of
Kermit-11.

Brian Nelson

[Ed. - This was the last current DEC operating system that did not have
a Kermit program -- now they all do.  The hex, odl, cmd, and doc files are
in KER:K11I31.* on CU20B.]

------------------------------

Date: Wed, 27 Nov 85 09:44:53 est
From: John Sambrook <uw-beaver!entropy!gandalf>
Subject: Kermit in C for DG MV Series with MV/UX

This is a Kermit for Data General MV Series computers.  In order to use this
Kermit you need the MV/UX product installed on top of your AOS/VS system.

If you don't have the MV/UX product but do have Data General's C compiler
you can modify the source to eliminate all calls to the UNIX emulator.
While this should not be too difficult, it will require some work.  I would
have done it for you but my schedule is just too tight.

If you don't have a C compiler feel free to translate this to another language.
Note that you will need to provide a multitasking environment.

This version of Kermit was created from an older version of Kermit.  It may or
may not be up to date.  It was tested at our site with a Kermit on a 4.2BSD
system and seemed to work fine.  As our site is moving to native UNIX (DG/UX)
we will not be using this Kermit for very long.  I will answer questions about
this version as my schedule permits.

John Sambrook
Department of Bioengineering WD-12
University of Washington
Seattle, Washington  98195
Work: [phone]
UUCP: uw-beaver!entropy!gandalf

[Ed. - Thanks!  The files are in KER:DGM*.* on CU20B, available via
anonymous FTP.  The program is based mostly on the old Unix Kermit.]

------------------------------

Date: 24 Nov 85 09:44:53 est
From: J.M.H. Smeets, Technische Hogeschool Eindhoven (THE), Netherlands
Subject: New Release of Burroughs B7900 Kermit

Enclosed is a tape containing our final implementation of Kermit for
the Burroughs B7900.  It includes file compression and binary transport.

[Ed. - The program, which is written in Burroughs Algol, is available on
CU20B as KER:B79*.*.]

------------------------------

DATE:    85/11/25
FROM:    [e-mail]
SUBJECT: Another Kermit for Intex RMX Systems

I'm releasing RMXKERMIT this week.  I'll get a tape off to you as soon as I can
get DP to do it.  Our campus bookstore will send out 5 1/4" DSDD RMX format
disks for $6/disk.  Disk 1 contains the executable program & documentation.
Disk 2 contains source code for those who want it.  Orders can be sent to:

     University Bookstore
     6049 E. 7th St.
     Long Beach, CA 90840

     Attn: Lyle Bartlett

[Ed. - This yet-another-RMX-Kermit will be announced again when it shows up
at Columbia.  This one differs from the others in being an adaptation of
MS-DOS Kermit, rather than a PL/M implementation.]

------------------------------

Date: 29 Oct 85
From: Andrew L. Burke, Tektronix MS 63/196, Wilsonville OR 97070
Subject: VMS Hexify/Dehexify Fix

Here are fixed versions of the VMS HEXIFY and DEHEXIFY programs.  While
these programs worked correctly on small files (files with less than 65535
lines, or thereabouts), failed on large files.  The problem was as follows:
the programs both used a longword (four bytes) internally to record the
current line number while reading/ writing the hexified file.  However, both
only read/wrote a word (two bytes) to/from the hexified file.  So, when it
came time for the VMSDEH program to read a line past the 65535th, it found
that the line number had wrapped back to line one.  This causes prolems
because the program uses the line index to decide whether to expand
compacted nulls or not, and when it found the next line index not equal to
the current plus the current line length, it starts writing out nulls
(counting from 65535 to 1, or therabouts...).  To make a long story short,
it didn't work.  The fix is simply to read and write a longword.  The other
modification is to VMSDEH is that it reports an end of file error when it
finished reading the hex file.

[Ed. - The fixed versions replace the old ones as KER:VMSHEX.MAR and
KER:VMSDEH.MAR on CU20B.  This came up because Tektronix is including Kermit
with its TekniCAD product on its 4100 series systems with CP/M-86.]

------------------------------

Date: Sat, 23 Nov 1985 18:06 CST
From: John Voigt - Systems Group Tulane <[e-mail]>
Subject: IMUSIC - MUSIC Kermit w/7171 support

We have discovered a bug in the new version of KERMIT for MUSIC which
supports the 7171 and Series/1 protocol converters.  This bug does not
always seem to cause a problem but it should be fixed in your code.  The
error is a result of a non-initialized control block field when sending
the first packet.  If you are trying to use this version of KERMIT with
the 7171 and you get a message FSIO ERROR - 0B1000 then this fix should
correct the problem.

In routine INTRINI find the following lines: (near line number 2565)
         LA    R1,RECPKT
         ST    R1,KERMFSRB
add the following lines after the above two:
         LA    R1,L'RECPK2     GET LENGTH OF INITIAL SEND PACKET
         ST    R1,KERMFSRL     SET RECORD LENGTH IN CONTROL BLOCK
This should correct the above error.

We have also found that if the terminal is defined to MUSIC as a "B" model
(with APL graphics characters) the 7171 will incorrectly translate data
causing KERMIT to fail altogether.  This is a permanant restiction and
should be noted in a BWR file.

[Ed. - Noted, along with above fix.]

Also, in answer to several questions from other MUSIC sites, I would like
to let everyone know that KERMIT is running on MUSIC/SP without any
modifications so if you are considering a software upgrade it should not
cause any proplems for your KERMIT users.

------------------------------

Date: Sun, 24 Nov 85 04:16:02 CST
From: Stan Barber <neuro1![e-mail]>
Subject: More Notes on C-Kermit 4C(057)

One more suggestion:

I would provide some mechanism to allow SYSIII compatible sites to
configure what signal that might like to use to allow the child and
parent to notify each other of problems. At my site, SIGUSR1 can not
be used by kermit, so I modify ckucon.c by replacing SIGUSR1 with
SIGUSR2. That fixes everything just fine.

At least a warning should be noted somewhere (in the .bwr file, I guess)
so that people will know to change it.

Alternatively, I would suggest a unique name (SIGKERMIT) that the
installer can define in the makefile (e.g. -DSIGKERMIT=SIGUSR2) to
keep people from mucking in the source file.

------------------------------

Date: Sun, 24 Nov 85 23:07:42 CST
From: Stan Barber <neuro1![e-mail]>
Subject: More on Masscomp Running C-Kermit 4C(057)

There is one more difference that masscomp users should check if they make
Ckermit. Using the masscomp FIONREAD (when in connect mode) my cause characters
to be dropped.  Using myread generally works better. This is certainly true if
the masscomp has the imux or jmux installed on it. It may not be true with the
new HPSMux installed. We don't have one yet, so I don't know.

In any case, I suggest a line for masscomp be added to the makefile of this
form:

rtu:
    make wermit "CFLAGS= -UFIONREAD -DUXIII -DDEBUG -DTLOG -O" "LNKFLAGS ="

[Ed. - Thanks Stan, both your messages have been added to the .BWR file, and
are on the list for the next release.]

------------------------------

Date: Tue Nov 26 11:45:41 EST 1985
From: dolqci!irsdcp!scsnet![e-mail]
Subject: Zilog Zeus Kermit, Os9 Kermit Warning

I am the contributer of the Zilog Zeus support for C-Kermit.  Kermit WILL NOT
WORK with the newest version of the Zeus operating system, i.e. 3.21.  We have
gotten C-Kermit to run under this new release but we had to rewrite ckutio.c.
Do you want us to submit this new mod?

[Ed. - Sure, especially if the new ckutio.c also works with the old release
of Zeus.  Or do we have to have two separate compile-time options for Zeus
systems?]

Also we think(!?) we have found two bugs in ckermit.  One is in ckcpro.c.  In
this module, C-Kermit sends an initial NAK to the other system rather than
waiting for the other side to make the first move.  We simply commented this
line out and now C-Kermit will talk to older Unix kermits.  Could this be made
public so that C-Kermit can be made a little more universal?  Some systems may
never be able to port C-Kermit (ala Os-9 Level I) and need to be able to talk
to C-Kermit.  Can this be done without losing any other comapatibility?

[Ed. - Are you talking about when C-Kermit is given the RECEIVE command,
or the SERVER command?  In the former case, I don't see how we can get
around sending NAKs -- if the expected first packet doesn't come, Kermit
has to NAK it, in case it was lost on the way and the sender of it doesn't
do timeouts.  If your local Kermit does timeouts, you can turn C-Kermit's
timer off all together with SET RECEIVE TIMEOUT 0.  In the latter case,
you're right, there should be a SET SERVER TIMEOUT command to turn off the
periodic NAKing function of the server, but still let it time out during
a protocol transaction.  Something like this should appear in a future
release.]

  The 2nd bug is in ckutio.c  In this mod, ckermit waits to get the other
side's eol char but then ignores it and expects its own: see the following

#ifdef ZILOG
    seol = (len-- > 0) ? unchar(data[4]) : '\r';      /* Terminator  */
    if ((seol < 2) || (seol > 037)) seol = '\r';
#else
    eol = (len-- > 0) ? unchar(data[4]) : '\r';            /* Terminator  */
    if ((eol < 2) || (eol > 037)) eol = '\r';
#endif

the ifdef ZILOG is our correction.  It was our experience that C-Kermit
would not work with any system that did not use <CR> as eol or would
convert eol to <CR>.  Hope this helps!

[Ed. - Thanks.]

------------------------------

Date: 26 November 1985, 08:43:52 CST
From: Tim Klosowski, Argonne National Laboratory <[e-mail]>
Subject: Problems with MacKermit for the Macintosh version 0.8(33)

I have been testing version 33 of the Kermit program for the Macintosh
computer prior to its release to our users.  I have encountered no problems
using the program on a 9600-baud X.25 line hookup to our IBM 3033 mainframe.
The problems surfaced when using a 1200-baud line.  I found three cases
during the course of my testing.

FIRST, normal execution and normal completion.
The file transferred sucessfully, the message stating this appeared and, after
a mouse-click, returned to the KERMIT-CMS prompt.

SECOND, normal execution and abnormal completion.  The file transfers
successfully and the message appears.  Instead of the KERMIT-CMS prompt
after a mouse-click, the program displays odd characters (such as %B..) and
necessitates several carriage returns to get action on the screen.  The
characters continue until a file transfer error message appears followed by
the KERMIT-CMS prompt.  The error message states that the transfer did not
complete, but closer examination indicates that the files did indeed
transfer successfully.

THIRD, abnormal execution and completion.  The program stalls after a few
packets are transferred.  The emergency exit is the only recourse.

The first case is what should ideally happen.  The third is a known problem
(occurring after an emergency exit is invoked).  The one that truly puzzles me
is the second.  If this is a known problem or if there is something I can do to
eliminate the problem, please let me know.

[Ed. - Thanks for your report.  I think that problem #2 has something to do
with closing down the line before the acknowledgement of the B (Break
Transmission) packet has been completely sent.  This would only occur during
uploading, and can be cured by using an even longer delay between sending
the ACK and closing the line.  It could also occur if this final ACK were
lost for some reason; again, a delay could cure this too.  The problem
should be fixed in the next release.]

------------------------------

Date: Monday, 25 November 1985  13:46-MST
From: Dick McGee (MMW) <[e-mail]>
Subject: MS-DOS Kermit V2.28

Has anyone successfully ported kermit v2.28 to a Z100?  I fixed the reported
bugs in the source code and assembled it.  I can upload and download with it
okay.  If I do a DIRECTORY, PUSH, SPACE or any command that temporarily exits
to DOS it goes into the twilight zone and I have to hard reset.  I'm running
MS-DOS 2.18.

I'm quite satisfied with the 2.26 version of Kermit, but since like
Mt. Everest, version 2.28 was there I thought I would try it.

s/Richard McGee    [e-mail]

[Ed. - Sounds like another casualty of version 2.28's new dynamic memory
allocation.  Did you use the /S switch on the assembler?]

------------------------------

Date: 17 November 85 15:46-PST
From: Don Pelton [phone] x2901 <[e-mail]>
Subject: Hardware Upgrade for some Professional Graphics Controllers

[Ed. - Excerpted from a posting on Info-IBMPC.]

If you have bought, or plan to buy, IBM's Professional Graphics Controller
and Display, you may be interested in this.  Several of us who bought this
board early this year discovered, through some painstaking research, that
there was a hardware bug on the board that caused it to interfere with ANY
terminal emulation program making use of the asynch port.

The old PGC cards have the numbers 6323697 and 6323698 on the top left of
the memory card. The new cards have these two numbers inked out and the
number 6448811 replaces them.  The two old numbers are not always inked out
and if your board has the 6448811 number, you have a new board.

------------------------------

Subject: ROMing MS-DOS Kermit
Date: 25 Nov 85 10:38:57 EST (Mon)
From: [e-mail]

[Ed. - This message picked up from Info-IBMPC in response to a query from
ad0r@cmu-cc-te about installing Kermit ROMs in IBM PCs...]

It's probably not worth it.  If you are willing to forgo the file upload/
download functions of KERMIT and use it to emulate a dumb terminal, it
shouldn't be too difficult to replace the screen and keyboard interfaces
with BIOS calls (I think that KERMIT uses DOS calls for these functions,
but I don't have the code at hand).

If you do this, why bother with KERMIT?  There are several other packages
around which provide X3.64 interfaces; the real advantage to KERMIT is the
popularity of its file transfer capabilities.

If you want the file transfer capabilities, on the other hand, you will
have to write your own file subsystem and burn it on the PROM.  For all
its faults, DOS does provide a mechanism for device-independent disk
access.  Unless you are going to dedicate significant staff time (spelled
with dollar signs) to the project, you will wind up with a package which
will support only a few device types.

I see occasional articles in the press which describe central-server systems
where the node PC's have no hard disk (or sometimes no DASD at all).  The
nodes, when booted, go to the central server for their copy of DOS; this
might be a better technique for you.

Ciao.

Joe Morris (jcmorris@mitre)

------------------------------

Date: Thu 21 Nov 85 11:11:21-EST
From: Frank da Cruz <[e-mail]>
Subject: ETX/ACK Flow Control?

Does anybody know what ETX/ACK flow control is, and what systems use it?
Is it like XON/XOFF, or ENQ/ACK, or is it something completely different?

------------------------------

Date: 24 Nov 85 00:07:26 GMT
From: Jeff Hollingsworth <[e-mail]>
Subject: Problem Downloading Files with Apple II Kermit

I am having trouble using kermit to transfer files between an Apple IIe, and
UNIX. When I try to send files from UNIX to my Apple, all occurences of the
"&" (ascii 38) character are removed.  This happens in both the image and
text mode.  However, all goes ok when I transfer a file from the Apple TO
UNIX.  Does anyone have an idea what is happening.  The Apple has a Super
Serial card if that helps.

Thanks in advance.

Jeff Hollingsworth    UUCP:   ucbvax!cory!hollings
            ARPA:   [e-mail]
            AT&T:   [phone]

[Ed. - Sounds like the two sides are not agreeing about 8th-bit prefixing.
The Apple thinks it's doing it, Unix doesn't.  You didn't say what versions
of Kermit you're running, so the problem may be fixed by now.  In any case,
you might be able to work around it by saying SET PARITY ODD on both sides
to force 8th-bit prefixing.]

------------------------------

End of Info-Kermit Digest
*************************
-------
 5-Dec-85 16:50:34-EST,20014;000000000000
Mail-From: SY.FDC created at  5-Dec-85 16:49:00
Date: Thu 5 Dec 85 16:48:55-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #32
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu,  5 Dec 1985       Volume 3 : Number 32

Departments:

  ANNOUNCEMENTS -
    New MS-DOS Kermit Available for Evaluation
    VT-220 .INI File for MS-DOS Kermit

  MISCELLANY -
    Forthcoming NIH TSO Kermit
    Apple Kermit Problem
    Fix for Apple Kermit Problem
    Os9 Kermit on Os9/68000
    Xenix Kermit Modem Control
    MULTICS Kermit?
    Professional 350 Kermit w/o Hard Disk?
    HP 9836 Kermit Diskette Needed
    Osborne 1 SD Kermit Diskette Needed
    Kermit Praises and Uses

----------------------------------------------------------------------

Date: Thu 5 Dec 85 15:55:21-EST
From: Frank da Cruz <[e-mail]>
Subject: New MS-DOS Kermit Available for Evaluation

I have the following letter from Joe R. Doupnik, Professor, Center for
Atmospheric and Space Sciences, Utah State University:

The enclosed tape ... holds an updated version of Kermit for MS-DOS
microcomputers.  This version is based on your MS-DOS Kermit 2.28 [the
current version]... and is identified internally as "version 2.28 jrd".
The updates include full DOS 2.0 file support thoughout, a nearly complete
set of advanced server functions, much cleaned up displays (Help, Status,
Set, etc), a much better file renaming algorithm, and quite a few bug
fixes.  All of the problems known [in 2.28 as of August 85] have been fixed
and some unreported ones were as well.  Internally the code has been
strengthened and cleaned up generally.

Kermit 2.28 jrd was built for IBM PC clones (a Zenith 151 here) and for
generic machines (I have one like this using a terminal and it is not at
all close to an IBM PC).  However, my updates affect the modules common to
all versions, [and there are also minor changes to] MSXIBM and MSYIBM.
There is a READ.ME file as well.

[End of letter.]  I have put these files in a special place on CU20B,
PS:<KERMIT-MS>*.*, available on the Internet via anonymous FTP.  I only
received the source files, but I built a version on the Rainbow, which (so far)
seems to work just fine.  The file names are the old ones, not the new
consistent ones (see KER:MSAAAA.HLP).  Since the people who used to take care
of MS-DOS Kermit here have quit, I am inclined to make this the new base
version.  It seems to be better than July-vintage 2.28 in all respects, but I'd
appreciate it if people could check it on different machines to verify this,
including the IBM family (with various graphics adapters), the Wang PC, the
HP-150 and 110, TI Pro, NEC APC, etc, and report back as to whether it would
be a good idea to switch to this version (and point me at an .EXE and/or
.BOO file).  The PS:<KERMIT-MS> directory includes 8-bit binary .OBJ files
(assembled with MASM 1.10 on the Rainbow) and MSVRB1.EXE, the 8-bit binary
Kermit .EXE file for the Rainbow.  The binary files are *.OBJ, *.EXE; the
text files are *.ASM, *.H, *.ME.

I still have a version of MS-Kermit laying around that has built-in VT100
(102?) emulation, but it's based on 2.27, and the emulation only works on the
IBM PC family, but effects all the others.  I figure we'd better first get a
clean base to work from, and then worry about how to add new stuff to it.

------------------------------

Date: Mon, 2 Dec 85 18:17:58 pst
From: Joel West <[e-mail]>
Subject: VT-220 .INI File for MS-DOS Kermit

I'm not the original author, but I'm told that if this is made
the KERMIT.INI for MS-DOS kermit on the Rainbow, it will make the
keyboard act like that of a DEC VT-220.

You might wish to include it in the FTP directory at Columbia-20.

    Joel West    CACI, Inc. - Federal
    [e-mail]
    {decvax,ucbvax,ihnp4}!sdcsvax!noscvax!westjw

[Ed. - It's in KER:MSIVT2.INI, the author is listed as Ken Bass
<[e-mail]>]

------------------------------

Date: Mon, 2 Dec 85  19:46 EST
From: RAF@UMDC
Subject: Forthcoming NIH TSO Kermit

I would like to correct an error that appeared in a recent Info-Kermit.
It is not the University of Maryland that is doing a TSO KERMIT, but
rather the National Institutes of Health in Bethesda, Maryland.
The confusion most likely arose because my BITNET mailing address is at
the University of Maryland until we get our BITNET connection running.
A description of our TSO KERMIT follows:

I spoke to you about our KERMIT on the phone some time ago.  It is based
on the University of Chicago TSO KERMIT, but we have really ripped it
apart - so it wouldn't be recognizable.  I spoke to Ron Rusnak about it
before we started development.  He said that they had no plans to do any
further development and planned to go to the Rice TSO KERMIT.  I tried
to get a copy of that KERMIT, but they were unwilling to send me one at
that time (but did later for $75).  Since we were unwilling to wait some
unspecified period of time just to look at the Rice KERMIT, we went ahead
with our plans.  Our TSO KERMIT has server mode, CRC, wildcard send and
receive, ability to issue TSO commands, timeout (without polling),
compression, 8th bit quoting, optional tab removal on upload, optional tab
insertion on download, support for NIH WYLBUR edit format, a SET
VOLUME command, binary file support, handling of line errors that
generate a break signal, multiple records per packet, handling of lines
500 or more characters long.  We also plan support for PDS members
and are reworking the help info to make it more helpful.  Another item
is an interface to the TSO CLIST facility for KERMIT command lists.
I'm no expert on CMS, but I'm not sure that TSO and CMS aren't different
enough to make separate programs the most reasonable way to go.  An awful
lot of the program is concerned with the system interface rather than the
KERMIT protocol.  Anyway, ours is almost done.  We will make it available
to you when it is finished

Roger Fajman
National Institutes of Health
[phone]
[e-mail]

------------------------------

Date: Saturday, 23 November 1985  17:07-MST
From: Jeff Hollingsworth <[e-mail]>
Subject: Apple Kermit Problem

I am having trouble using kermit to transfer files between an Apple
IIe, and UNIX. When I try to send files from UNIX to my Apple, all
occurences of the "&" (ascii 38) character are removed.  This happens
in both the image and text mode.  However, all goes ok when I transfer
a file from the Apple TO UNIX.  Does anyone have an idea what is
happening?  The Apple has a Super Serial card if that helps.

Thanks in advance.

Jeff Hollingsworth    UUCP:   ucbvax!cory!hollings
            ARPA:   [e-mail]
            AT&T:   [phone]

[Ed. - See next message.]

------------------------------

Date: Wed, 27 Nov 85 15:18:06 PST
From: [e-mail]
Subject: Fix for Apple Kermit Problem

In this message I've enclosed an update to your Apple Kermit program.
Versions 2.0 and 2.1 of the program do not handle eighth bit quoting
correctly. A student, Sam Lam, who was working for me during the
summer found the error. Below is the correction.

In the procedure Rpar three operands have to be changed from "rparrt"
to "rpar8" as indicated by the arrows.

                        -- Bruce Jolliffe

[Ed. - Thanks!  Code omitted, added to KER:APPLE.BWR.]

------------------------------

Date: Wed 4 Dec 85 15:05:39-PST
From: Bob Larson <[e-mail]>
Subject: Os9 Kermit on Os9/68000

The current version of os9 kermit can't be compiled by the current version
of os9/68k C (1.3) because "remote" is a reserved word.  (What version of
os9/68k C introduced this "feature"?)  Even after this problem is solved,
kermit doesn't work properly.  I'll be fixing this asap.  (I now have a
QT+ 68000 system.)

Bob Larson
Arpa: [e-mail]
Uucp: ihnp4!sdcrdcf!oberon!blarson

[Ed. - This message added to KER:OS9KER.BWR.]

------------------------------

Date: Mon 25 Nov 85 17:10:21-EST
From: Yoram Eisenstadter <[e-mail]>
Subject: Xenix Kermit Modem Control?

I'm trying to bring up Unix Kermit on my PC/AT running XENIX, but
I'm having difficulties.

I got ahold of the source, and compiled everything successfully using
"make xenix".

First problem: the machine hung when I tried to do a "set line /dev/tty00".
I was able to do a set line only after saying "set modem-dialer hayes",
even though I have a direct connection and not a modem.

2nd problem: after set line, I did a "set speed 9600".  Then I did a connect.
Kermit immediately came back with the message "Communication Disconnect",
and returned me to the C-Kermit> prompt.

I know that the hardware is O.K.  I use the same communication port with
MSKERMIT under DOS, and it works just fine (I'm using it now...)
I was also able to use the port (/dev/tty00) from Unix with the "cu"
command, by saying "cu -s 9600 -l /dev/tty00 dir".

What am I doing wrong?

[Ed. - See next message...]

--------------------

Date: Wed Nov 27 12:10:47 1985
From: Herm Fischer <hermix![e-mail]>
Subject: Re: Xenix kermit difficulties

Ahh, the saga of carrier detect, clear to send, and data set ready continues...

If you fire up kermit, when you do a set modem-dialer, you place kermit into
the "clocal" (ignore carrier detect absence) state.  If you fire up kermit on
a direct connection without a modem, then be sure carrier detect is present
on the pins of the cable before firing kermit up.

I suggest purchasing one of those widget connectors with the led's which
goes between the rs232 cable and the computer to see which signals are present.
Often on direct connections, it is common to hot-wire carrier detect to some
other signal to get it to come up.  If you're on a LAN, then there might
be a LAN option to raise the carrier signal...

Your communications disconnection message comes from the UNIX operating
system notifying kermit that the carrier signal has dropped!  Same problem.

cu may override the "clocal" flag; I haven't looked at its code.  kermit
cannot override that flag because it must know when a remote modem hangs
up, lest it tie up a system or hang it...

  Herm Fischer
  [e-mail]; {ihnp4, decvax, randvax}!hermix!fischer

[Ed. - Herm not only wrote the Xenix modem support in C-Kermit, but he
also uses it all the time -- an existence proof that it works.]

------------------------------

Date:  Fri, 29 Nov 85 12:24 EST
From:  [e-mail]
Subject:  MULTICS Kermit

I have recently moved to Maui and been out of touch with my usual
MULTICS machine for about two months.  In that time, a new release of
the operating system was installed.  This came with KERMIT.  The new
KERMIT does not respond to my PC KERMIT, even though I have successfully
used this repeatedly with the previous version of MULTICS KERMIT.  I
have made every effort to ensure that the file parameters match at both
ends.

Could the fact that I'm now using a TAC have something to do with it?
Transfer has failed both ways using either an ASCII or binary file.

Anyone have a systematic approach to a solution??  I'd appreciate the
help as Maui is a veritable computer "wasteland"!

Wolf Wiedemann RADC-MULTICS

[Ed. - TACs are always a pain.  But I also keep hearing about all these
different versions of MULTICS Kermit that are in use "out there" that I
have never seen personally, so it might just as likely be the culprit.
Anybody care to clear up the MULTICS Kermit confusion?  Which is the
"real" one, and where does it come from?]

------------------------------

Date: Mon, 2 Dec 85 17:20:32 EST
From: [e-mail]
Subject: Professional 350 Kermit w/o Hard Disk

  I presently use Kermit on my Digital Pro-350, however I don't have a
hard disk on this system thus it operates as a Pro-325.  While Kermit
functions just fine with the obvious exception on interfacing with the
other utilites which it expects on disk, I can not get kermit to retain
its communications settings so it ALWAYs uses the defaults.
  The problem seems to be that Kermit wants to store its settings in
a file somewhere, but I can't figure out what that file is named or
where it is supposed to be;  if I could, then I could create it and
suspect all would be fine!
  Any help with this would be greatly appreciated.
  --chris

------------------------------

Date: Thu 5 Dec 85 08:44:31-EST
From: Frank da Cruz <[e-mail]>
Subject: HP 9836 Kermit Diskette Needed

If anybody has HP9836 Kermit on a diskette and is willing to send a copy
to someone who can't get it any other way, please call Steve Masticola
at RCA, Somerville NJ, 201-685-6594, collect if desired.  And if you're
willing to send Steve a disk, how about also sending one to the HP98x6
user group (is there such a thing?) so they can handle these requests?

------------------------------

Date: Thu 5 Dec 85 11:27:12-EST
From: Frank da Cruz <[e-mail]>
Subject: Osborne 1 SD Kermit Diskette Needed

I got a letter from Norway that was addressed like this:

    Columbia University
    Columbia, USA

It actually, came to me...  Somebody in Norway figured out that CU was in
New York, and then somebody at Columbia opened it up and saw the word Kermit
in it...  Anyhow, this guy lost his only copy of Kermit because of a power
hit, and can't find a single-density copy of it anywhere in Norway.  If some
kind soul would send one to

    Einar
    Norway

I'm sure he'd appreciate it.  Just kidding, his full address is

    Einar Fredriksen
    Edvard Griegsvei 34
    N-5037 Solheimsvik
    NORWAY

Thanks!

------------------------------

Date: Thu 5 Dec 85 13:46:34-EST
From: Chris Lent <[e-mail]>
Subject: Kermit Praises and Uses

KERMIT in the trenches:
    We've been using KERMIT down at Cooper Union quite a bit.
(We're at 3rd Ave and East 8th Street).
After I bought a copy of the tapes,  I put it on our systems
down at Cooper.  These are:
    VAX 11/780 VMS 4.2
    ATT 3b5 System V UNIX R 2.0.211
    PDP-11/45 UNIX V6 (plus)    ! This took a good bit of work
    PDP-11/23 UNIX V6 (plus-more)    ! Same as 11/45
    IBM-PC's, and PC-Jr's PC-DOS 2.0,2.1,3.0,3.1
    ATT 6300 (Very IBM compatible AND FAST!!!)
    Apple Mac's ! The VT102 emultator comes in very handy.
    Intel Blue Boxes "MDS-80" (ISIS-II)(8" Floppy only)
        ! We transfered this via a block-by-block copy
        ! from our VAX RX01 Console Floppy
    Intel 310's    ! DON'T EVEN THINK ABOUT BUYING THESE TURKEYS!!!!
        ! The 310's run MS-DOS BADLY (We had to write drivers
            for the serial port and winchester that Intel put in!!)
        ! Intel also foists IRMX-86 on you (Everyone needs an
            archaric multi-user Operating System on a
            machine that one person uses?)
        ! Kermit is having a hard time here only because the
        ! port drivers still are bug-infested. We tend to
        ! transfer to an IBM-PC and take the MS-DOS floppy
        ! and read that instead.
    Intel 380's ! BIGGER Multi-User TURKEYS!!
        ! Intel hasn't managed to port MS-DOS to these yet!!!!

Now we do a multitude of daily and regular transfers like:
STUDENT USE:
        Student archiving of programs.  This works wonderfully as
    we don't have to hunt through age-old backups for their stuff.
    It also has the added benefit that if the programs are written
    portably in 'C', Fortran, Pascal or Basic, they can do development
    work on PC's and other micros around the school or at home.
    The archiving is done at local PC's. This is necessary as our
    money for dialin facilities is limited and our computers are
    brought down each night because the building is closed.

        Students talking to FIDO bulletin board systems from home.
    This way they can get the latest shareware utlities.

        Students talking to each other's systems.  One interesting
    case is a lab group where the guy with the MAC did the diagrams,
    and printed the final version of the paper while another
    member typed the paper on his IBM. The third member
    proof-read the text on his Commodore-64.  Let's hear it for
    two wonderful standards: ASCII and KERMIT!!!!

COURSE AND PROJECT USE:
        Sending GTSTRUDL plotting files from our VAX to the 11/45
    where our CALCOMP plotter is.  This lets our civil engineers
    make giant plots of their structures and how they will deform
    under load.

        Sending Digitized maps and data from the 11/45 to IBM-PC's and
    the VAX. There a lot of this.  The students in the CAD/CAM
    course have to design a simple packeage and many of them
    digitize their intial shape library on the 11/45 before moving
    them to the final machine.

        Sending sample bitmapped image data from RT-11 format tapes
    read in on our VAX to Intel 380's for work in developing medical
    imaging systems.

MORE STUDENT USE:
        Sending and receiving programs under development from grad and
    undergrad students machines out at Bell Labs (and AT&T clones) for
    course work (complier design, programming languages, data structures,
    and of course the infamous Master's thesis).  Bell Labs
    machines at Whippany, Homdel, and Parsippany get the new
    versions from us as we get them from you.  Once Kermit'ed
    to a Usenet machine, the programs flow over Usenet to the
    apporiate machines.  Most times they just type
        % make sys3
    or the make for Berkley 4.2 and the Kermit works perfectly
    right away.  Many times the user DOESN'T know what type of
    machine he's running on (VAX, 3bx or whatever) and it STILL
    works well even though the "RIGHT" version wasn't used.
        The first version when over via the UNIX 'cu'(CALL UNIX)
    utility which talked through the VAX's modem via KERMIT in CONNECT mode.
    After fixing up the transmission errors,  we compiled it and
    got a reliable version of KERMIT via our 'cu'ed version.

FACULTY USE:
    The faculty computer program.  Professor's develop programs
    at home that the students use in their classes on the main
    computers.  The number of these programs we support now is getting
    huge.

    Faculty work on remote machines in places like Texas and Califonia.
    Usually they have older versions of KERMIT, so we ship a new
    version to our faculty member's account via the old KERMIT
    and then tell the remote staff where to find it for system-wide
    installation.


    And even more every day.


It seems like every third word out of my mouth is KERMIT.
My policy is now whenever someone has a machine or an account on
a machine which doesn't have KERMIT, we find some way of moving
KERMIT to them.  I must admit I thought the demand would be large
but it just seems to be growing in leaps and bounds.


The thing is that I've learned about so many strange operating
systems while installing KERMIT, but I rarely (once a month)
have to examine individual KERMIT packets when porting a new
KERMIT version.

We just seems to be trashing more old file transfer programs
every day.  It doesn't matter if they we purchased or hacked
together,  KERMIT is in general better and makes MUCH more
sense to maintain.  We usually keep the old one around until
we figure out how to send strange file formats (VMS is famous
for these.)

Well, I'll keep KERMITing the rest of the Universe.

                Thanks,
                Chris Lent
                Care of:
                [e-mail]
                (VAXmail) CUPHOA::LENT
(I'm working on tailoring utilities and EUNICE for them up here)

------------------------------

End of Info-Kermit Digest
*************************
-------
11-Dec-85 11:00:48-EST,9532;000000000000
Mail-From: SY.FDC created at 11-Dec-85 10:59:58
Date: Wed 11 Dec 85 10:59:58-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #33
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 11 Dec 1985       Volume 3 : Number 33

Departments:

  MS-DOS KERMIT 2.28 JRD -
    MS-DOS Kermit 2.28 jrd Not on BITnet
    MS-DOS Kermit 2.28 jrd Bug with X Packets
    Bug Report on MS-DOS Kermit 2.28 jrd on 18MHz PC/AT
    Suggestion for MS-DOS 2.29
    Minor Mod to New MS-DOS Kermit

  MISCELLANY -
    Apple-II Kermit Bugs
    Multics Kermit

----------------------------------------------------------------------

Date: Wed 11 Dec 85 10:13:20-EST
From: Frank da Cruz <[e-mail]>
Subject: MS-DOS Kermit 2.28 jrd Not on BITnet

In response to numerous requests from BITnet for Joe Doupnik's improved
version of MS-DOS Kermit 2.28, I'm sorry to say I can't put it on BITnet
just yet, for a variety of reasons which are too complicated to explain.
It looks as though this version will wind up replacing the current one --
one or two minor bugs need fixing, plus checkout is still required on the
Wangs, HP's, NECs, etc -- and at that time it will replace the current
version on BITnet.

I'm also sorry I mentioned the MS-DOS Kermit 2.27 that had VT100 support
added to it.  In response to numerous requests for it, let me just say that
in order to avert utter chaos, I would prefer to get the fixed 2.28
installed as the standard, base version, and then call for volunteers to
take the VT100 support and fit it into the new base version.  If we don't do
it that way, we'll have multiple proliferating divergent versions of the
program which will be impossible to support.  Those of you who whose phone
doesn't ring 500 times a day with MS-Kermit questions might not appreciate
why this is important, so you'll just have to take my word for it.

Once again, I apologize for the reduced level of support for MS-DOS Kermit
and the BITnet Kermit files.  Like I said before, it's because the people
who used to take care of these things have left Columbia.  They will be
replaced, but I can't say when.  Soon, I hope.

------------------------------

Date: Tue 10 Dec 85 18:02:07-EST
From: Frank da Cruz <[e-mail]>
Subject: MS-DOS Kermit 2.28 jrd Bug with X Packets

First real bug -- if you send a generic command to a server which the server
does not support, and it sends back an error packet (which is the proper
behavior for servers under the circumstances), then the next file sent by
MS-DOS Kermit has its name in an X packet rather than an F packet, which of
course the server is not prepared to handle.  MS-DOS Kermit is apparently
setting its "X flag" in anticipation that the generic command will elicit a
X packet or a data-bearing ACK from the server, and then not resetting it
when the transaction is terminated by an error.  In fact, it should not set
this flag until such a response actually occurs, and it should reset the
flag at the beginning of each transaction.  Reportedly, the same behavior
crops up randomly (not reproducibly) at other times.

Thanks also to others who reported this problem.  If anybody develops a fix
(it should be real simple, something like setting the X-Flag to 0 at the top
of the command loop), please send it in.

------------------------------

Date: 9 Dec 85 08:57:00 PST
From: ALEX WOO <wu@ames-aero>
Subject: Bug Report on MS-DOS Kermit 2.28 jrd on 18MHz PC/AT

The new MS-DOS kermit seems to work fine on a 4.77MHz PC but it coughs on a
18MHz PC AT with the error message
    "? Not enough memory to run kermit"
The PC AT has about 2MB of memory.

[Ed. - Beats me, anybody have any ideas?  Doesn't sound like anything that
would involve timing loops...  Do all your other programs work on your
souped up AT???  Does the old Kermit?]

Also, if there a Makefile for the MS-DOS version of Kermit, perhaps using
one of the Info-IBMPC makes.

[Ed. - There isn't, sorry.  Does anyone know if there is a "make" that will
support command line arguments, so you can say "make ibm", "make rainbow",
"make tipc", etc?  If so, which one is it, where is it?]

Alex.

------------------------------

Date: Mon 9 Dec 85 04:18:07-EST
From: Joe Smith [phone] <[e-mail]>
Subject: Suggestion for MS-DOS 2.29

If you do plan to use MSKERMIT 2.28 jrd as the basis of the next release of
MS-DOS KERMIT, please add "SET TERMINAL mumble" and "SET DTR mumble" to the
system independent code.  Define dummy entry points in all the system
dependent modules so they can parse "mumble" or say "not implemented".  Then
the developers could add system specific arguments to these commands, such
as:

    SET TERMINAL NO-WRAPAROUND
    SET TERMINAL WIDTH 132
    SET TERMINAL ID VT125
    SET DTR ON
    SET DTR OFF
    SET DTR HANGUP-ON-EXIT

We need a general way to get to system-specific functions thru KERMIT's
command scanner.

/JMS

[Ed. - These sound like useful hints for whoever is going to volunteer to
fit the VT100 support into 2.28 jrd.]

------------------------------

Date: Sun, 8 Dec 85 01:23 EST
From: Larry Afrin <[e-mail]>
Subject: Minor Mod to New MS-DOS Kermit

The new MS-DOS Kermit (jrd's rewrite/mod of 2.28) has a minor problem when
it invokes COMMAND.COM to do stuff like TYPEing out files, DELeting files,
running CHKDSK, and RUNning any other program: when you type in the command
line in response to the "Kermit>" prompt, and then hit Enter, only a
carriage return is echoed.  No line feed.  This means that the first line of
output (either from COMMAND.COM or from the program loaded in by
COMMAND.COM) overwrites the "Kermit>" prompt and the command you typed.
Trivial, I admit, but aesthetically displeasing.  I made the following mod
in the location of the "run3" label in the MSKERM.ASM module in
PS:<KERMIT-MS> to output the needed line feed.

[Ed. - I've appended your code to the MSKERM.BWR file, but I can't reproduce
the problem, either on a PC/AT or a Rainbow.]

Other than this minor problem, I haven't found anything wrong yet with
jrd's version.  I'm running PC-DOS 3.10 on a plain vanilla PC.

Still waiting for a VT100 emulator to replace the Heath-19, though... (hey,
we can dream, can't we?)

[Ed. - Yes, but can we volunteer?]

P.S.  I'm running MASM version 1.00 (from the Dark Ages of 1981), and in
order to get the segments in the right order for the linker, I had to change
all references to segment name STACK to segment CTACK.  These references are
in modules MSKERM.ASM (4 references) and MSXDMB.ASM (2 references).  If you
don't make this change, the machine winds up taking a long walk off a short
pier when you hit Control-] C to come back from on-line mode to command
mode.

[Ed. - Anyone else have this problem?  I assembled the files with Microsoft
MASM 1.10 (1981,82) using no switches, and not renaming any segments, and
the result worked fine.  Also, has anybody ever heard of the /DOS switch
that Joe mentioned in his letter?]

------------------------------

Date: Fri 6 Dec 85 01:25:39-EST
From: Peter G. Trei <[e-mail]>
Subject: Apple-II Kermit Bugs

In reference to Sam Lam and Bruce Jolliffe's fix for the Apple ][ Kermit's
8th bit quoting bug, here is a way to install it in version 2.1a without
doing another download. I have not yet had the opportunity to perform
thorough checking and testing of this fix, so be cautious!

[This patch only works for version 2.1a]
Make a copy of your kermit-65 disk.
Boot with the new disk.
Enter the following DOS commands:

] UNLOCK KERMIT
] BLOAD KERMIT
] POKE 17303,35
] POKE 17317,21
] POKE 17329,9
] POKE 17399,194
] DELETE KERMIT
] BSAVE KERMIT,A$801,L$4E9B

As soon as I have finished checking this fix, I will ask Frank to put the
updated source and hex files into the download area on CU20B for
distribution. This may be related to the bug that strips out '&' on
reception of files.

                            Peter Trei
                            oc.trei@cu20b

------------------------------

Date:  Fri, 6 Dec 85 17:20 EST
From:  "John C. Klensin" <[e-mail]>
Subject:  Multics Kermit

As of approximately now, the 'real' Multics kermit is the one with which
problems were reported in V3#32.  It is a version created at Calgary and
being distributed with the system and supported by Honeywell (it is,
consequently, unlikely to be released to the Columbia archives).

It supports many options that the various older versions and kludges do not,
incluing server mode, 8th-bit-quoting, etc., and is structured much more
like other Multics commands that do similar things, such as the Internet FTP
command.  Its default option settings, however, tend to be a little more
optimized for Multics<->Multics transfers over X.25 and dial circuits than
for PC->Multics or Internet TAC use.  Users with problems should probably
bug Honeywell over conventional channels, as this is a supported product.

Does that help?

[Ed. - I guess.  Columbia, by the way, has never received this version of
Multics Kermit.  I suppose if all Multics sites get it automatically, no
harm is done.]

------------------------------

End of Info-Kermit Digest
*************************
-------
19-Dec-85 12:28:31-EST,20252;000000000000
Mail-From: SY.FDC created at 19-Dec-85 12:27:49
Date: Thu 19 Dec 85 12:27:48-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #34
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 19 Dec 1985       Volume 3 : Number 34

Departments:

  ANNOUNCEMENTS -
    New Honeywell CP-6 Kermit
    New version of IMUSIC

  MS-DOS KERMIT -
    MS-DOS Kermit 2.28 jrd Problems and Fixes
    IBM-PC Kermit V2.28 jrd Display Problems
    TopView Support for MS-DOS Kermit
    More MS-DOS Kermit 2.28 jrd Problems
    MSBOOT.FOR for Unix f77

  MISCELLANY -
    DEC-20 File Naming Problem
    Os9 kermit warning!
    Bugs in the CP/M Turbo-Pascal Kermit V1.00
    Re: Apple-II Kermit Bugs

----------------------------------------------------------------------

Date: Thu, 18 Dec 85  10:50 EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: New Honeywell CP-6 Kermit

This is to announce a new Kermit program for Honeywell CP-6 systems from Lee
Hallin at Honeywell (Lee-Hallin%LADC@CISL).  This one is written in PL/6, a
PL/I-like language, and includes text/binary file transfer, wildcards, all
the prefixing options, server and client operation, command files, etc, but
lacks CRC, file interrupt, attributes.  (The other CP-6 Kermit is written in
Pascal and comes from Bucknell University.)

Lee's new CP-6 Kermit is available from CU20B via anonymous FTP as KER:HC6*.*.
Again, apologies to everyone on BITNET for the hiatus in getting new files
on KERMSRV; we should be back in business on that end after the holidays.

------------------------------

Date: Mon, 16 Dec 85  20:14 EST
From: John Voigt - Systems Group Tulane <[e-mail]>
Subject: New version of IMUSIC

I have a new version (1.2) of IMUSIC KERMIT available.  This version
incorporates several fixes as well as enhancing the set ? function.  I have
sent you the complete source with all the new changes.

JV/

[Ed. - Thanks!  This replaces the previous version (1.1) on CU20B.  It's
in KER:IMUSIC.ASM.]

------------------------------

Date: 12 Dec 85 21:23:04 PST (Thu)
Subject: MS-DOS Kermit 2.28 jrd Problems and Fixes
From: donovan@aero

   I've attached a fix to MS-DOS Kermit v2.28 rjd for a problem in the send
protocol.  The problem occurs when a send command follows a Kermit generic
command which causes flags.xflg to be set.  This happens whenever a remote
server displays output on the local screen.  The GENRIC procedure in MSSSER
is the culprit, but the simplest fix is to reset xflg in the SEND command
processor just before the server entry point at SEND11.  Here are diffs for
MSSSEN.

..........mssend.old
;    Send command

..........msssen.asm
;    Send command - protocol handler to send a file
; Normal entry - SEND does file transfer preceded by "F" packet
;         resets xflg
; Server entry - SEND11 does file transfer preceded by "X" packet
;         set xflg = 1 before call

..........mssend.old
send11:    mov flags.nmoflg,0    ; Reset flags from fn parsing. [21a]
    mov ah,setdma        ; set dta address [jrd]

..........msssen.asm
    mov flags.xflg,0    ; Reset flag for normal file send [mtd]
SEND11:    mov flags.nmoflg,0    ; Reset flags from fn parsing. [21a]
    mov ah,setdma        ; set dta address [jrd]

[Ed. - Thanks!  This was the most glaring bug in this version.]

Also, the Z-100 version has had a bug in backspace processing since v2.27.
When entering Kermit commands at the prompt, backspace (^H) won't back up
over characters on the screen.  The problem is caused by a change made to
MSSCMD.ASM near the label "cmge11".  Backspace was removed from the set of
characters which are echoed.  The fix is to change MSXZ10.ASM to send an
extra backspace.  "diff"s below.

..........msxz10.old
delstr  db    BS,' ',BS,'$'     ; Delete string. [21d]
home    db    ESC,'H$'

..........msxz10.asm
delstr  db    BS,BS,' ',BS,'$'     ; Delete string. [21d]
home    db    ESC,'H$'

The MS-DOS version with Joe Doupnik's modifications works with both HP150
and, with this fix, Z-100 modules.  Joe's modifications are a major
improvement to MS-DOS Kermit.  I suggest that once the documentation catches
up with the programming, the revised Kermit should be accepted as MS-DOS
Kermit v2.29.

[Ed. - Well, a couple more problems remain, and the contributions keep
pouring in.  But you're right, we have to draw the line somewhere.
See below...]

------------------------------

Date: Sat 14 Dec 85 05:33:09-EST
From: Kathleen Connors <[e-mail]>
Subject: IBM-PC Kermit V2.28 jrd Display Problems

I tried the new 2.28 version of Kermit for the IBM PC tonight.  It still has
some of the same problems (2 out of 3) that the old 2.28 version had, which I
reported to you last June.

1) When you GET a file the file transfer screen puts an "s"
   in upper left hand corner of the screen.

2) The mode line under the same conditions displays nothing
   except a single "^" in the first position.

The truncation of the file name upon receiving a file has been fixed.  I am
using a IBM PC I (64k motherboard), 512k of memory, DOS 3.0 and a internal
Qubie (Hayes compatible) modem. Since these problems, albeit cosmetic, still
exist I will probably continue to version 2.27.

[Ed. - Has anyone else ever seen this?  I haven't, and I've been running
both 2.28 and 2.28 jrd on an IBM PC for a couple weeks.]

Suggestions for future Kermits:

1) A means of clearing the terminal screen buffer from the local Kermit.

2) The Kermit initialization file should be allowed to be
   called KERMIT.INI instead of MSKERMIT.INI.

[Ed. - The reason it's called MSKERMIT.INI is that if you accidentally
transfer your KERMIT.INI file from a mainframe, you'd be in for some nasty
surprises the next time you started Kermit up on your PC.]

3) The ability to send a file "raw" without the Kermit protocol just xon/xoff.

[Ed. - Everybody wants this, along with login scripts and a DIAL command.
Maybe someday someone will write the code.]

------------------------------

Date: 12/16/85  6:10:45 E.S.T.
From: [e-mail]
Subject: TopView Support for MS-DOS Kermit

Here is a new MSYIBM terminal emulation module; the following changes
were made:

. ANSI set graphics rendition support extended to handle color attributes
   in addition to monochrome

. Direct moves to and from the video buffer modified to use TOPVIEW
   interrupt codes, so that KERMIT can run in the background under
   TOPVIEW and take advantage of TOPVIEW windowing support.

The following parameters are used in a TOPVIEW Program Information File to run
KERMIT under TOPVIEW with the MSYIBM TOPVIEW support added.

Memory:  Variable.  Suggest min and max be set to 128K to allow 'run' support.
 Set system memory to about 20K

Screen type: D
 Pages: 4
 Window size: 25 by 80
 Offsets:     0     0

Writes directly to screen:   no
 Accesses system keyboard buffer:  no
 Runs only in the foreground:   no
 Uses math coprocessor:    no

[Ed. - Thanks!  I haven't had a chance to try this out, but if these are the
only changes, then it should be compatible with JRD's new stuff, except for
one minor change that JRD made about Heath line wrap.  If anybody wants to
try this out, the file is with JRD's Kermit, stored as
PS:<KERMIT-MS>MSYIBM.TOP on CU20B only -- If you take it, please report back
about how/if it works, and whether it's safe to distribute as the standard
version.]

------------------------------

Date: Thu 19 Dec 85 09:24:23-EST
From: Frank da Cruz <[e-mail]>
Subject: More MS-DOS Kermit 2.28 jrd Problems

Beyond the bugs reported already (like the X-Flag bug), there are at least
two subtle problems with the new MS-DOS Kermit.  First, even when assembled
correctly with the "right" assembler and switches, it will sometimes (very
rarely) start executing garbage after a CONNECT command.  This happened to
me exactly once in several weeks of constant use -- I had escaped back from
a connection to the DEC-20, gave the DO IBM command, switched my port
contention unit to the IBM mainframe, gave the CONNECT command, and poof --
system totally dead, had to be rebooted.  A few other people have reported
similar occurrences.  I can't reproduce it; can anybody else?

The second problem applies to earlier releases as well, but only shows up
on a PC/AT, and (for us at least) only when communicating with a half duplex
system at 9600 baud using handshake.  The sympton is that, after the end of a
file transfer session from the mainframe to the PC, after the mainframe sends
the B (Break transmission) packet, the AT responds with its ACK, but the ACK
shows up as garbage at the mainframe.  If on the AT you SET DEBUG ON, the
problem goes away.  When the connection is run through a line monitor,
everything appears normal; the AT responds to each packet from the mainframe
immediately as the XON handshake appears, and ACK is in correct format.

The speculation is that the AT is somehow ACKing the B packet "too fast".
Even though we haven't caught it sending the ACK prematurely on the line
monitor, the behavior is exactly what you'd expect if a transmission
occurred before the line was fully "turned around".  Why would this happen
after a B packet, but not after any other packet?  Several possible
explanations suggest themselves: (a) unlike most other packets, the B packet
requires no processing, and can be ACK'd immediately; (b) MS-DOS Kermit
somehow forgets about handshaking after the B packet; (c) MS-DOS Kermit is
handling the UART incorrectly.

I think (b) is unlikely; we never saw any supporting evidence on the line
monitor.  While (c) is a possibility, it would take a lot of digging through
the low-level code to show up a problem; a cursory inspection reveals
nothing obvious (the UART's output holding register is always tested for
emptiness before giving it the next character).

If (a) is true, it would imply that the host is sending its XON before it is
really and truly ready for input.  Unlikely as this may seem (it's a
lightly-loaded IBM 3083), the fact that the problem only happens with the AT
-- which is much faster than the PC or the Rainbow -- lends some credence to
this theory.  If this is the real explanation, then the thing to do would be
to insert a brief sleep in MS-DOS Kermit before ACKing the B packet.  But
there are also some other packets that don't require any processing, namely
those that arrive with bad checksums; thus we might have to sleep before
retransmitting or NAKing as well.

If anyone can offer any insight or evidence to support any of these
theories, it would be much appreciated.  But beyond that, we may have here a
presage of things to come.  As microcomputers get faster and faster, they
may begin to strain the assumptions underlying the design of our
communications equipment.

------------------------------

Date: 13 Dec 1985 1427-EST (Friday)
From: Tom Putnam <[e-mail]>
Subject: MSBOOT.FOR for Unix f77

The subject FORTRAN program is supposed to be run on a host machine in
conjunction with MSPCBOOT.BAS on a target MS-DOS machine to download
MSKERMIT.BOO and similar binary files.  The program requires several
modifications to operate under UNIX.  (We are running UNIX 4.2 BSD).
In particular:

 * The variable ACK is declared as a 4-element array, but only the
   first element is ever used.  The initial READ statement:
          READ (5,200) OK, SPACE, COMMA, ACK
    200   FORMAT(4A1)
   implies that the whole array ACK will be read.  Since the format does
   not allow enough elements, a second "line" or "record" of input is
   requested, so file transfer never gets off the ground.

 * The write statements include a blank for carriage control.  Although
   some systems strip this character on output to the terminal, UNIX terminal
   output includes the blank and thus fouls up the character count check.

I corrected these problems, converted the program to FORTRAN-77, and
cleaned-up the logic a little so that we could use it on our systems.
The modified version of the program is available via anonymous ftp from
ASC.PURDUE.EDU in the "kermit" subdirectory, file name "msboot.f".

[Ed. - It's also on CU20B as KER:MSBOOT.F.]

Tom Putnam, Manager of User Services
Purdue University Computing Center

ARPANET: [e-mail]
     or  [e-mail]
BITNET:  PUTNAMT@PURCCVM
CSNET:   ac4@purdue-asc-tn
USENET:  [e-mail]
USMAIL:  Mathematical Sciences Bldg.
     West Lafayette, IN 47907
PHONE:     [phone]

------------------------------

Date: Tue, 17 Dec 1985  13:34 EST
From: [e-mail]
Subject: DEC-20 File Naming Problem

I am using TOPS-20 Kermit version 4.1 and running into the following problem:

The filenames that I am using on my microcomputer are in the same format as
TOPS20 filenames, that is, "<name>.<type>.<version>".  The software system
maintains the version numbers in the usual way.  As we have quite a few of
these computers, which are not tied together with a network, we use Kermit
to transfer files to and from MIT-OZ, our DEC 20.  This gives us all a
shared file system to work from.

Now, my problem is that I want to transfer files from my local machine to the
20, retaining the version number (note that this works fine when transferring
from the 20 to the local machine).  This is so the version numbers on the 20
will match the version numbers on the local machine.

Unfortunately, TOPS20 Kermit doesn't have an option to do this.  As far as I
can tell, the only options I have are "set file naming unconverted" and "set
file naming normal-form".  In neither case is the version number I specify
used to write the output file on the 20.  Instead, the file is forced to be
a "newest" generation -- either "FOO.BAR.34.0" (where the <type> is
"BAR.34") or "FOO.BARX34.0", respectively.

Could this be changed?  It seems to me that if the version number is
explicitly specified, it does no harm to open the output file under that
name if one does not already exist.  Or, if that is not reasonable, could
you add an option, say, "set file naming literal", that does what I want?
It is really a pain for me to have to rename all my files after I transmit
them.

Thanks,
Chris Hanson

[Ed. - Thanks for the suggestion.  I'll try to add another file-naming
option to Kermit-20 in the next release.]

------------------------------

Date:  Mon Dec 16 10:58:59 EST 1985
From: dolqci!irsdcp!scsnet![e-mail]
Subject: Os9 kermit warning!

   A warning about using kermit under os9 on a tandy CoCo: If you use kermit
with the multi-pak and the delux rs-232 pak, that is you intend to use /t2
as your outgoing device you MUST have the rs-232 pak in slot 1 of the
multi-pak. In fact the device driver for /t2 requires that the rs-232 pak be
in slot 1. ANY program that uses /t2 will only run if the rs-232 is in slot
1. Also it appears that you must have the carrier forced on BEFORE you run
kermit if you are using sometype of smartmodem. (maybe some os9 wizard out
there can find a patch to the device driver to let /t2 look for the rs-232
pak in another slot).

  Kermit on the CoCo is still (as far as I know - maybe bob larson knows
more) untested using device /t1, the so called "bit banger" port.

~ Addresses:  USmail: IRS, 1111 Constitution Ave. NW    Washington, DC 20224 ~
~             Atten: M. Sunderlin PM:S:D:NO             Office Phone:        ~
~ UUCP:  ...seismo!dolqci!irsdcp!scsnet!sunder          [phone]       ~
~        ...decvax!philabs!ubbs!sund                    (FTS) 634-2529       ~
~ CIS:   74026,3235                                                          ~

------------------------------

Date: Wed, 18 Dec 85 13:32:59 cst
From: Jeff Woolsey <[e-mail]>
Subject: Bugs in the CP/M Turbo-Pascal Kermit V1.00

I have found and fixed a few bugs in the Turbo Pascal Kermit for CP/M-80,
and made some simple but useful enhancements.

Bug #1: Binary file transfers "worked" (everybody was happy with checksums)
but the file was missing the 8th bit sometimes.  &X would not get the 8th
bit set, but &#X would.  The code that checked for control characters in
this case forgot that this was an &-quoted character if it wasn't also
#-quoted.  The fix in the else clause should be obvious.  See procedure
expand_packet in file KREC1.PAS here:

[Ed. - Code omitted.]

Bug #2: This first showed up as filenames listed by the DIR command being
separated by linefeeds.  The solution eluded me until I realized that I was
in user area 10 (= ASCII linefeed) at the time.  Fix it by not writing the
first "character" of the file name.  See procedure writefilename in file
KDIR.PAS.

Bug #3: The scourge of all machines using 16-bit signed integers.  The
displays of bytes (remaining to be) transferred wrap to negative integers
above 32767.  Since this number is calculated by multiplying blocks by 128
(an integer), you really only get 9 bits of information there.  This can be
remedied by multiplying by 128.0 (a real) and formatting the result.  See
procedure update in file KDISPLAY.PAS.  See procedure open_file in file
KOPEN.PAS.

Enhancement #1: I got tired of having to tell the host explicitly the name
of each file I was downloading when I should have been able to use
wildcards.  The impediment here is that Turbo Kermit goes to receive_init
state when it gets the EOF packet, and expects a send_init packet from the
host. Instead, it gets a file_header packet, and aborts.  A two-line change
allows Kermit to receive multiple files in this case.  Find the
repeat/case/until block that processes the incoming packets.  Only one of
the cases ever sets the state variable (to receive_init). Change it to
receive_header, and add a clause to the until condition checking for state
<> receive.  See procedure rfile in file KREC1.PAS here

[Ed. - Code omitted.]

Enhancement #2: Especially in conjunction wtih Enchancement #1, I wanted to
be able to see the name of the file being transferred along with all the
other statistics being displayed.  I stuck "gotoxy(58,2); write(fileref);"
at the front of procedure open_file in file KOPEN.PAS.

The above should be of general interest.  What follows summarizes the other,
more machine-specific changes that I needed to make.

I undid the IOBYTE stuff so that I could support all 4 of the serial ports
on my system.  I have a 1200 bps autodialing modem and a dumb 2400 bps modem
and I wanted to be able to autodial 2400 bps systems.  I support searching
through the various PAMS/PDSE/et.al. BBS lists and extracting the phone
numbers.  I rewrote pieces of the command processor to make it easier to add
new commands while retaining the ability to abbreviate them to uniqueness,
and I implemented meaningful semantics for commands like CONNECT 1 or
RECEIVE FRED.PAS .  I have a text capture mode, and if I desire the terminal
handler converts ANSI escape sequences into H19 sequences for my console.
...
The aim of Nuclear Freeze is to prevent Nuclear Winter.

                Jeff Woolsey
                ...ihnp4{!stolaf}!umn-cs!woolsey
                [e-mail]

[Ed. - Thanks. I've put this message in full (with code) in KER:TURBO.BWR on
CU20B, and have also passed it along to the Turbo Pascal Kermit authors.]

------------------------------

Date: Wed, 11 Dec 85 16:55:16 PST
From: [e-mail]
Subject: Re: Apple-II Kermit Bugs

>This may be related to the bug that strips out '&' on reception of files.

This IS the bug that strips out '&' on reception regardless of the setting
of text/binary and 7/8 bit data path.  When it sees an '&' in the incoming
data stream, it just unconditionally strips it and turns on the 8th bit of
the next character.

Sam Lam

------------------------------

End of Info-Kermit Digest
*************************
-------
24-Dec-85 14:12:09-EST,12480;000000000000
Mail-From: SY.FDC created at 24-Dec-85 14:11:39
Date: Tue 24 Dec 85 14:11:39-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #35
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 24 Dec 1985       Volume 3 : Number 35

Departments:

  MS-DOS KERMIT -
    Kermit 2.28 jrd Bug Report
    Fast Kermit for AT?
    IBM-PC Kermit v2.28 Display Problems
    Kermit for Victor

  MISCELLANY -
    Kermit for Apples with StarCard
    Request for KERMIT binary for Radio Shack 6000 Xenix
    Set File 8-Bit in Kermit-20

----------------------------------------------------------------------

Date: 23 DEC 85 13:15-MST
From: [e-mail]
Subject: Kermit 2.28 jrd Bug Report

1. Thanks for the mail messages and nice words. Using Bitnet here is magic
of a rather dark hue, alas.  Given that you seem to have a shortage of
MS-DOS folks perhaps I can get the mail via Bitnet and help solve the sundry
bugs as they arrive and then send responses to you for editing.

2. Bugs of various kinds in "MS Kermit 2.28 jrd" are discussed below.

3. Rare computer hangups when engaging IBM mode and then entering the
Connect state. Peering at the interrupt level code in file MSXIBM shows
several places of difficulty if the mainframe were to have sent a char
before Kermit was ready to accept one. Some changes were made to hopefully
avoid problems; all involve completing work before interrupts can interfere.
The hangup problem seems to be like a corrupted segment register (ds?),
which could happen I suppose if a char arrived during serial port
initialization.  Actually, I or someone needs to have a hard look at the
code in SERINT to see if all UART conditions are properly serviced and if
the 8259 interrupt controller chip is attended to in an manner consistent
with both IBM PCs and ATs. ISRs are such fun! My quick changes are as
follows.

  Procedure SERINI:
   - flush UART received character BEFORE turning on interrupts,
   - change allowable UART interrupting conditions to avoid interrupts on
     TX Holding Buffer Empty (a nonsense interrupt for us) but allow them
     on Data Available, RX Line Change, and Modem Change,
   - move push/pop es to allow quicker procedure exit,
   - replace call to proc Clrbuf with separate code since Clrbuf turns on
     interrupts within the body of SERINI (a likely culprit).
  Procedure SERRST:
   - move push/pop es to allow quicker procedure exit.
  Procedure SERINT:
   - send 8259 chip End-of-Interrupt signal as almost last item in the proc,
   - remove strange Enable Interrupts (sti) instruction within proc body;
     after all, we got here via an interrupt.

4. Data overrun when turning around line between IBM mainframe and IBM
PC/AT.  An obvious thing to do here is insert a small wait interval before
sending a packet (sending filler chars could still upset the host during
line turn around); this is usually called pacing.  In terms of fast micros
and sluggish mainframe terminal handlers, pacing seems to be one of the
solutions.  I added a 3 millisecond wait routine at the very beginning of
procedure OUTPKT in file MSCOMM; it may not be enough, but the delay is
easily adjusted.  If it's too long then we will lose the time slice, if too
short then mainframe loses the first part of a packet.

5. Files sent while in server mode do not use repeat prefixing.  My goof due
to misunderstanding the non-standard protocol of setting the prefix char.  Two
lines of code were added in procedure SERVER (in file MSSERV) to force the
default prefix char into the active prefix after each server command.

6. Items not clearly explained in original read.me file for 2.28 jrd.
 -- GET allows both file names to be on the same line; ex. GET theirs mine.
 -- GET allows ? chars in filenames after the first char, but I forgot to
    invoke the # --> ? translation. I think earlier versions omitted this
    also. Similarly, I parse both file names on whitespace (can be fixed)
    which is probably painful for IBM users.

7. All these changes affect three files: MSXIBM, MSCOMM, and MSSERV. Below is
the output of MSDOS utility FC on the new and original "2.28 jrd" files. The
complete files, with extension of .NEW, are being sent as well.

8. Happy holidays.  Joe

[Ed. - Now that we have established network connection with Joe, we can send
files back and forth rather quickly.  There may well be a few more
contributions from him in the coming weeks.  I've put the new files in
PS:<KERMIT-MS> on CU20B, in case anybody wants to check them out -- feedback
solicited and appreciated!]

------------------------------

Date: Thu 19 Dec 85 16:51:47-PST
From: Ed Pattermann <[e-mail]>
Subject: Fast Kermit...

Does anyone have a patch for MS-KERMIT that allows it to work with IBM AT's
that have faster crystals installed, like a 18MHZ crystal? Kermit fails
to work after installing the new crystal.

[Ed. - Some of the changes mentioned in the previous message might go a long
way towards helping here.]

------------------------------

Date: 19 Dec 85 16:39:48 PST (Thu)
From: Mike Iglesias <[e-mail]>
Subject: IBM-PC Kermit v2.28 Display Problems

I've seen the display problems that Kathleen Connors has seen with the original
v2.28 Kermit on both a IBM PC-I and a Compaq.  It appears to only happen on the
old motherboard PCs (we have only one of those here) and the Compaq (which must
do something the same way that the PC-I does).  It does not happen on the newer
PCs (PC-II; 256k motherboard) or a Compaq 286, so I suspect it may have
something to do with the ROM BIOS.

Mike Iglesias
University of California, Irvine

------------------------------

Date: 20 Dec 85 02:13:23 +0100
From: [e-mail]  ([e-mail])
Subject: Kermit for Victor?

I'm using a Vicky with "BIOS Version 2.9 February 4,1984 for V9000" and
MSDOS 2.11. I've tried to run the SIRIUS ASM available from KERMSRV
at CUVMA but it doesn't work. The CONNECT corrupts a lot of keys
(I'm using a German keyboard) and the RECEIVE doesn't work at 2400 baud.
The generic MSDOS kermit is running up to 2400 baud.

Has anyone a special kermit version for the Vicky (Victor 9000) PC?

Thanks

Reinhard Goeth (Techn. Univ. of Darmstadt/Fed. Rep. of Germany)

P.S. I wish you a merry chrismas and a happy new year.

------------------------------

Date:     Fri, 20-DEC-1985 08:53 MST
From:     Eric Zurcher <[e-mail]>
Subject:  KERMIT for Apples with StarCard

        I thought I'd pass along a few things that I've learned while trying
to implement KERMIT on an Apple ][+ with a StarCard CP/M board.  All of this
may already be familiar to you, but I provide it to you on the chance that it
may keep someone else from having to reinvent the wheel.

        "Official" versions of KERMIT exist for Apples using the SoftCard CP/M
board, but I could not locate any for the StarCard.  The SoftCard versions do
not work, since the two CP/M boards use quite different approaches in gaining
access to the Apple's ports.  I have found that the "generic" CP/M KERMIT can
be made to work quite well with the StarCard, but only after making a minor
alteration in the BIOS of the operating system provided with the card.  In its
standard configuration, the BAT: device is identical to the CRT: device, both
refering to the Apple's monitor and keyboard.  However, changing a single byte
in the BIOS will cause the BAT: device to refer to a serial card in slot 2 of
the Apple, which is of course the sort of arrangement that generic KERMIT
needs.  The byte in question is located at an offset of 63H from the start of
the JMP tables of the BIOS (that is, it can be easily located by adding 60H to
the address pointed to by the JMP instruction at address 0).  This address
normally contains the value CC - changing it to C8 will result in the
definition of the BAT: device being changed to slot 2 of the Apple.  (I have
not seen this "feature" documented anywhere, though I have not requested
technical documentation from the manufacturers of the StarCard.)  Once this
change is made, generic KERMIT works quite well.

        I'm currently working (though not very hard) on the rather simple task
of developing a KERMIT that will handle the task of modifying this byte, if
necessary.  At present, I get around the problem by booting the system with a
disk that contains a version of the BIOS in which I have already modified the
byte.  I've also managed to combine a few features of the SoftCard KERMITs with
the generic KERMIT, to allow VT52 emulation to work and to "tidy up" the
display during file transfers.  It works reasonably well.  If you wish, I will
send a version to you once I get everything working the way I'd like.

        There are a few caveats (aren't there always?): (1) an 80-column
display enhancer is almost a necessity for reasonable terminal usage;  the
StarCard can try to produce a 70-column display using software, but this is too
slow to keep up at even 1200 baud.  (2) I have not thoroughly tested this, but
I suspect that a DC Hayes MicroModem II will not work with this arrangement -
the problem is that you can't dial a number.  It does appear to be possible to
first dial and establish the connection under Apple DOS, then reboot the
machine to run CP/M.  In any case, whatever serial interface is used must be in
slot 2 of the Apple.  (3) I have not tested this arrangement at speeds above
1200 baud, but I suspect that faster speeds will not work well.  (4) Most of
the VT52 emulation features work as they should, but the "home and clear
screen" operation is a bit slow - at 1200 baud I usually lose the next dozen or
so characters received after this operation.  (5) It appears that data is
restricted to 7-bit, and not 8-bit bytes.  For transfer of non-ASCII files,
parity should be set to space.

        I hope somebody, somewhere, finds some of this useful.  In the long
run, it would be preferable to have a KERMIT for this system which accesses
the serial port a bit more directly, rather than through twiddling the IObyte,
but I will leave that task to someone else.

                                        Regards, and Merry Christmas!
                                        Eric Zurcher
                                        Dept. of Biology
                                        Utah State University
                                        Logan, Utah 84322-5305
                                        REHABIV@USU

[Ed. - Thanks for the information; I've added your message to the APPLE.BWR
file for the time being.  USU seems to be a beehive of Kermit activity these
days...]

------------------------------

Date: Sun, 22 Dec 85 11:41:56 EST
From: Glenn Ricart <[e-mail]>
Subject: Request for KERMIT binary for Radio Shack 6000 Xenix

I'd like to run KERMIT under Xenix on a Radio Shack 6000 (previously
known as the 16B before some magic happened).  Unfortunately, this
system does not have a C compiler so I can't start from the sources.
Could someone contribute the binary?  . . . . Thanks!

------------------------------

Date: Sun, 22 Dec 1985  13:29 MST
From: Keith Petersen <[e-mail]>
Subject: Set File 8-Bit in Kermit-20

Request for change in next update of Kermit-20:  Because I do a lot of
uploading to Simtel20 and frequently use SEND *.* to do it, I have my
KERMIT.INI do SET FILE BINARY.  No problem so far, as I can use ASCIFY
later to fix the ascii files - meantime I can go away from the
computer and let things transfer automatically (of course my Kermit-80
is set to default to SET FILE BINARY).

Now the problem: When downloading from Simtel20, that INI is still in
effect and I get garbage on ascii files sent to me.  I need to be
able to tell Kermit-20 to use SET FILE 8-BIT for sends from me to
Simtel20, and SET FILE AUTO for sends from Simtel20 to me.

Suggest it might be added as SET FILE SEND AUTO and SET FILE RECEIVE
8-BIT.

--Keith

[Ed. - Good idea, will probably be added to the next release.]

------------------------------

End of Info-Kermit Digest
*************************
-------
 6-Jan-86 16:37:34-EST,18350;000000000001
Mail-From: SY.FDC created at  6-Jan-86 16:36:44
Date: Mon 6 Jan 86 16:36:44-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V4 #1
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Mon,  6 Jan 1986       Volume 4 : Number  1

Departments:

  MS-DOS KERMIT -
    New C-Kermit with Sliding Windows for PC-DOS
    Revised Modules for MS-Kermit 2.28 jrd
    Re: Fast PC/AT Kermit
    My Two Cents on the MS-Kermit 2.28 jrd "Display Problem"
    MS-DOS Kermit Terminal Emulation Query

  MISCELLANY -
    Apple DOS Kermit Bug
    Kermit for NCR Decision-Mate V?

----------------------------------------------------------------------

Date: Fri 20 Dec 85 00:05:05-EST
From: Jan van der Eijk <[e-mail]>
Subject: New C-Kermit with Sliding Windows for PC-DOS
Keywords: C-Kermit, Sliding Windows, MS-DOS Kermit

I just finished a C version of Kermit for the IBM PC/XT/AT and DOS.  It
supports the following:

    Server
    Dial command
    Script files
    Sliding window (full duplex only)
    File Attributes
    and the majority of the features from the Unix C-Kermit.

The file is called WKERMIT.EXE and the current version is 012.  The sliding
windows part is not widely supported yet but the following systems/programs
do:

     PRO-YAM      Communication package for the PC
     The SOURCE   Public info
     TCOMM        Unattended bulletin board system.

Any updates will be posted on the following TCOMM system:

   data only [phone]

If you have any questions direct them to OC.JAN@CU20B or to JAN VANDEREYK on
the previous mentioned TCOMM BBS.  To upload WKERMIT to this system took
an effective rate of 63 CPS, while using sliding windows it would have been
around 100 CPS.

[Ed. - This is the first implementation of Kermit with windows that we have
received at Columbia.  It is based on a previous release of C-Kermit,
version 4.2, edit number unknown; the current version of C-Kermit is
4C(057).  Windows-Kermit is compiled in Lattice C and uses the Greenleaf
communication libraries (which do not support XON/XOFF).  The source, .EXE,
and .BOO files are in PS:<KERMIT-W>, available via anonymous FTP from CU20B,
for evaluation only.  You may use the .BOO or .EXE file even if you don't
have the Greenleaf libraries or Lattice C.

This is not a polished product -- it needs to be integrated with the
"mainstream" C-Kermit, the DOS interface fixed up a bit, and so on.  The
reason for this posting is to get some experience and data on the windowing
option, especially when used over public networks like Telenet (which is the
normal way of getting to The Source, whose Kermit also does windows).  I'd
be very interested in any performance measurements -- e.g. the transfer of a
particular file with and without windowing, over direct or dial connections
vs over public networks, with various window sizes, etc (the baud rate, the
size of the file in bytes, and the elapsed time required to transfer it in
each case).

I would appreciate it if everyone would refrain from fixing or changing the
program on the source level until a coherent release of C-Kermit can be
produced covering not only MS-DOS, but also Unix, the Macintosh, and VMS.
Also, an up-to-date version of the windowing specification and some
supporting documentation is available in PS:<KERMIT-W>KW*.*.]

------------------------------

Date: 2 JAN 86 13:15-MST
From: JRD@USU
Subject: Revised Modules for MS-Kermit 2.28 jrd
Keywords: MS-DOS Kermit

         Updates to MS Kermit 2.28 jrd/2 as of the end of Dec 1985
                            From Joe R. Doupnik
                        CASS and EE, Utah State Univ
               [phone] (days) Bitnet user JRD node USU

    MS Kermit 2.28 jrd has undergone some internal and external upgrading
since its original posting to Columbia Univ in late November.  The responses
of numerous people testing it have helped a lot.  Thanks guys.  The significant
changes are listed below.  Oh, yes.  Files have renamed to current standards:

  mssdef.h, and the .asm files msscmd,msscom,mssfil,mssker,mssrcv,msssen,
  mssser,mssset,msxibm,msyibm,mssfin. (mssdmb.asm is gone.)

1. The single character command, C for Connect, is back.
   Also fixed the parser to allow keywords within Kermit to be in mixed case.

2. X-packet problems -- fixed, I hope.

3. Interrupting reception of a file by typing ^C, at last, deletes or keeps
   incomplete files as it should.

4. SET End-of-Line # command has been fixed to remove the suprious message
   of "?Not confirmed"; the command actually worked despite the message.

5. A bug in server mode's (lack of) use of repeat prefixes has been fixed.

6. RUN whatever now displays a leading cr/lf before DOS's response.

7. The server mode display screen has been freed of stray messages and
   retry counts, or so I hope.

[Ed. - One big problem with the MS-DOS Kermit server is that the DOS
programs it invokes -- and often DOS itself -- will put a message on the
screen and wait for the user to reply from the Keyboard; a disk problem will
evoke the familar "Abort, Retry, Ignore?" message, CHKDSK will ask you if you
want it to repair your disk if it finds something wrong (and REMOTE SPACE
invokes CHKDSK).  So if the server hangs, it's probably stuck in this
manner, and there's not much one can do about it if the server is unattended.]

8. Filenames are not automatically expanded to be ???????.??? by typing the
   escape key since the complete filename string is now a rather complicated
   object (drive and path fields, etc).

9. Half duplex systems (eg, IBM mainframes) had a problem of not hearing a
   packet if it were received too quickly after its own last transmission
   (such as an EOF response).  A new workaround waits 3 millisec (adjustable in
   the code) before sending any packet in the hope of giving the other end time
   to switch contexts from send to receive.

[Ed. -- 3 msec is about 3 character times at 9600 baud; this should be more
than adequate -- it certainly made the problem disappear for us, with our
own IBM mainframe.  Ideally, the delay should be adjustable, and should be
zero for full duplex connections.]

10. A much more serious I/O problem has been displayed (machines going poof
   or worse especially when Connecting).  My best guess is timing problems in
   the serial port interrupt handling code.  This has been revised and
   tightened considerably.

11. How to build Kermit from sources with various versions of MASM and
   LINK.  Worry no more; Kermit handles that now.  Brief tutorial (yawn):
   Kermit uses three program sections, CODE, CSTACK (was STACK), and DATAS.
   My simple changes were to rename the old STACK section to be CSTACK (sorts
   to later than CODE and earlier than DATAS) and place references to each,
   arranged alphabetically, in the assembler header file, MSSDEF.H, where they
   will be seen before any other code and hence also be in the desired
   order-of-encounter.

   One may link Kermit modules in any order at all, provided that MSSFIN is
   mentioned last.  A typical Link command file might look like this:

        msscmd+msscom+mssfil+mssker+mssrcv+msssen+
        mssser+mssset+msster+msxibm+msyibm+mssfin
        kermit;      or     kermit/map, kermit.map;

12. Internally, code for the "% completed" message has been rewritten to
   run more accurately and to work with files as large as 32 MB. Number of
   Packets still turns over at 64586; that's a lot of packets.

13. The LOG command will now supply a filename of KERMIT.LOG if you don't
   specify one, and logging now appends to the desired file (won't destroy
   old text).  One small comment on this version of Kermit is that in the
   confusion of sending stuff hither and yon I apparently did both

        Kermit> Log Prn (OK by itself), and
        Control-PrtSc (ditto)

   while within VMS Mail. My printer went into grahpics mode and slept hence
   forth.  Seems like both VMS and double printing is not a good combination.
   Mail does bad things by itself due to the escape sequences emitted, but
   double printing certainly is bad news for unknown reasons.

14. All filename handling has been strengthened.  When attempting to write
   to disk all read-only, hidden (system), and volume label files are "fully
   protected" from Kermit.

15. Get and SEND. I have had to back off a little on GET's command line to
   accomodate various filename constructions.  We are back to the manual
   whereby Get can have just one filename on its command line and that name
   can have embedded whitespace and other printable characters. If a local
   override filename is wanted invoke Get with an empty command and then
   remote and local filenames will be requested by prompts. SEND, however, has
   been modified slightly to also prompt for both names if its command line is
   empty. For both commands, the remote name has leading whitespace trimmed,
   but trailing whitespace is retained, and local filenames get full local
   inspection.

   GET and SEND permit the first character of a string to be a wild card by
   saying "#" rather than "?"; the "#" will be translated to a "?". After the
   first character of a string a "?" can be used as needed.

16. Disk I/O buffer sizes have been moved to the header file so you can
   easily change them to suit local conditions.  The logging (capture) buffer
   is set to 256 bytes, up from 128, but the main data disk buffer ("buff") is
   left at 128 bytes to keep the "% completed" display lively; note that DOS
   does full sector buffering anyway.

17. An item of note. Giving the command REM DEL B:\JUNK to an MSDOS remote
   server can lead to trouble if JUNK is a subdirectroy rather than a file.
   DOS interprets this to mean DEL B:\JUNK\*.* (oops!) and asks the server
   "Are you sure?". At this point the server Kermit hangs displaying the
   message above and the server's operator must say something on the keyboard.
   If he/she says N then DOS leaves the user in subdirectory B:\JUNK.  It's a
   DOS "feature" in at least version 2.11.  On the other hand, simply sending
   another file also named JUNK on B: results in a new file named B:\JUNK0001
   if WARNING is on or a complaint if WARNING is off.

18. Z100 backspace bug fixed in MSXZ10.ASM.

19. A new version of the IBM screen handling module, MSYIBM, updated by Bob
   Bolch for operation of Kermit under IBM's TopView has been heavily used by
   me for a while with no problems. However, I don't have TopView (IBM's TV
   demo disk works fine here).  My system is a Zenith 151 PC and a composite
   video monochrome monitor.

[Ed. - MSYIBM.TOP -- please try this if you use TopView, or even if you
don't, to make sure it does no harm on ordinary DOS systems.  TopView setup
parameters are documented in MSVIBM.TOP.]

20. I haven't yet obtained a copy of Purdue's VT100 emulator package so this
   version of Kermit still uses the Heath-19 emulation.  A VT100 module which
   works like a real VT100 sure would be nice!

                    Joe Doupnik
                                        JRD on Bitnet node USU

[Ed. - This message has been considerably shortened for the digest.  The
complete text, along with the new modules and any files mentioned above, are
in PS:<KERMIT-MS> on CU20B, available via anonymous FTP.  Sorry, they are
not available on BITNET via KERMSRV -- after one or two further go-rounds,
the final result of all this will be installed as the official version
(probably 2.29) in all of the normal Kermit distribution areas.

The source files (ASCII text) are in PS:<KERMIT-MS>MSSS*.*.  The object
files (8-bit binary) are in PS:<KERMIT-MS>MSSS*.OBJ.  Documentation, in
the form of the messages we've had from Joe D., are in PS:<KERMIT-MS>MSA*.*.
8-bit binary .EXE files for the IBM PC/XT/AT are in PS:<KERMIT-MS>MSV*.EXE,
and corresponding ASCII .BOO files (decodable with KER:MSBPCT.BAS) are in
PS:<KERMIT-MS>MSV*.BOO.  If you have trouble FTPing the .EXE or .OBJ files,
then either get the source and build from that, or else get the file
KER:AANETW.HLP, which gives hints about FTP'ing binary files from CU20B.

If you have other MS-DOS systems, like the HP-110 or -150, Wang PC, TI Pro,
Z-100, etc, please get the source files and try building and testing the
resulting .EXE, and pointing me at the .EXE if you can put it in a place I
can FTP it from.  Copies of all the MSX*.ASM and MSY*.ASM modules have been
placed in PS:<KERMIT-MS>, but no object files yet.

Finally, I've added the fix for CR at column 80 that Joe added to MSYIBM
to the file MSYIBM.TOP.  Therefore, I'd appreciate it if anyone who is using
TopView could try this module in place of MSYIBM.ASM and report if/how it
works, both under TopView and "up front".  Is the performance any worse than
the TopView-less version?  Should this become the regular terminal emulation
module for the IBM PC/XT/AT?

Thanks again to Joe Doupnik for the tremendous amount of work he's put in
and generously contributed.]

------------------------------

Subject: Re: Fast PC/AT Kermit
Date: 24 Dec 85 16:26:33 EST (Tue)
From: [e-mail]
Keywords: MS-DOS KERMIT

I don't know what you're talking about.  I regularly use MS-KERMIT on an AT
running DOS 3.1 with an 18.4mhz crystal (yielding an effective rate of
9.2mhz.)  I haven't yet seen any problems related to this.  I might mention
that my COM1: is located on the IBM serial/parallel card.

[Ed. - There seems to be a difference of opinion about whether Kermit
works on a souped-up AT.  Can anyone suggest why it works for some people
and not others?]

------------------------------

Date: Tue, 24 Dec 85 22:01 EST
From: Larry Afrin <[e-mail]>
Subject: My Two Cents on the MS-Kermit 2.28 jrd "Display Problem"
Keywords: MS_DOS Kermit

   I saw in the Digest a couple of msgs, one from Kathleen <last name?> and
one from Mike Iglesias, re "display problems" with MS-Kermit 2.28 jrd on old
(16K/64K motherboard) and Compaqs.  I don't know about the Compaq side of
the issue, but I'm also running 2.28 jrd on a 16K/64K vintage 1981 IBM PC,
and I have had no hint of any display problems since I first assembled and
installed the program.  For what it's worth, I'm running PC-DOS 3.10 with
ANSI.SYS installed, and I assembled 2.28 jrd with MASM 1.0 along with that
trick I documented in a msg you included in the Digest one or two issues
back.  Maybe the display problems have something to do with how 2.28 jrd is
assembled and/or linked.  (Hey, for a shot in the dark, it ain't so bad an
idea!)  Oh, I'm also running a monochrome monitor off the standard IBM
monochrome monitor/ parallel printer adapter card.

                                        -- Larry Afrin
                                           Dept. of Computer Science
                                           Clemson University

[Ed. - Another difference of opinion; "jrd/2" should link and assemble the
same way for everybody.  Can someone pinpoint the problem?]

------------------------------

Date: Tue 31 Dec 85 13:39:13-EST
From: Frank da Cruz <[e-mail]>
Subject: MS-DOS Kermit Terminal Emulation Query
Keywords: MS-DOS Kermit

If a forthcoming release of MS-DOS Kermit were to include VT-100 emulation,
would anyone have any objection to removing the Heath-19 emulation?  If so,
would the objections disappear if a VT-102 (with character insert and delete
functions) were emulated?  Since code has been written at several sites to
make Kermit emulation a VT-10x, the question is whether to include it
alongside the H19 code, or to replace the H19 code altogether.  In the
former case, the program would be that much bigger, and the implication
would be that other sites are invited to add emulation for still other kinds
of terminals (DG Dasher, IBM 3101 have already been suggested).  I have a
vague preference for emulating only one kind of terminal, and allowing
others to be supported by turning Kermit's emulation off and loading a
console driver to emulate the desired terminal.  What does everyone else
think?

------------------------------

Date: 30 DEC 85 AT 11:23:27
From: <[e-mail]>
Subject: Apple DOS Kermit Bug
Keywords: Apple II Kermit

 Well my fears are confirmed.  File xfer doesnt care what the checksum
received is. I dont know how this bug has continued this long either we
usually have very good com lines or nobody is using this kermit.

 The bug is "very little attention is being paid to false returns from rpak"
In the case of received data no attention is being paid. Sigh!

The fix:

the stmt after label "rdat2" should be "beq rdat2d" since false is zero.
the 3 stmts starting with label "rdat2c" should be removed but the label
should be retained.

 After looking at all the returns from "rpak" I am supprised that
the packet is used befor checking the checksum. It seems to me that the
whole packet is suspect if the checksum is in error. Anyway you probably
know more about this than I do.
                                     Ted
                                     milnet address "medin@nosc"

[Ed. - This message, and some further, more detailed information, has been
passed along to the Apple Kermit maintainers to see, and has been appended
to the Apple Kermit "beware" file, KER:APPLE.BWR.]

------------------------------

Date: Fri 3 Jan 86 14:09:50-CST
From: Bob Paver <[e-mail]>
Subject: Kermit for NCR Decision-Mate V?
Keywords: NCR

I'm looking for a version of Kermit that will run on a NCR Decision-Mate V.
This system runs MS-DOS, but uses a 2651 UART rather than the more standard
8251.  (MSGENER assumes the presence of the 8251 UART.)

Any help would be appreciated.

Happy New Year!

Bob Paver    [phone]

Microelectronics and Computer Technology Corp. (MCC)
9430 Research Blvd, Echelon Building #1
Austin, TX  78759-6509

ARPA:  [e-mail]
UUCP:  {ihnp4,seismo,harvard,gatech}!ut-sally!im4u!milano!paver

------------------------------

End of Info-Kermit Digest
*************************


-------
 8-Jan-86 09:48:12-EST,7671;000000000001
Mail-From: SY.FDC created at  8-Jan-86 09:46:05
Date: Wed 8 Jan 86 09:46:04-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V4 #2
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed,  8 Jan 1986       Volume 4 : Number  2

Departments:

  MS-DOS KERMIT -
        Feedback on H19 vs VT102 Support in Kermit-MS (several messages)

  MISCELLANY -
    C-Kermit VMS
    IBM VM/CMS Kermit vs VM Optimizer
    Kermit for Epson HX-20?

----------------------------------------------------------------------

Date: 7-Jan-1986
From: [e-mail]
Subject: H19 Support
Keywords: Terminal Emulation
Cross-Ref: H-19, VT-100, VT-102 (see also Terminal Emulation)

H19 and vt102's -- The consensus here [at the University of Toledo] is that
since there are no H19's on campus H19 support would not be missed.  In
light of the s/1, 7171 and VAX TPU support of vt1xx's and the lack therein
of h19 support, my users would certainly prefer vt1xx emulation.

brian

------------------------------

Date: Tue 7 Jan 86 13:16:53-EST
From: D. M. Rosenblum <[e-mail]>
Subject: Re: MS-DOS Kermit Terminal Emulation Query
Keywords: Terminal Emulation

Personally, I prefer H-19 emulation.  But I'm not much of a heavy MS-DOS
Kermit user these days.  My reasons may nevertheless be of some interest.

If VT1xx emulation is fast enough to avoid the incessant XON/XOFFing that
goes on with real VT1xx's (or, e.g., PRO/350's running PRO/Kermit or
PRO/Communications and emulating VT102s), then I have no objections.  But
there's some software that isn't too kind to XON/XOFF flow control, notably
old versions of Gosling emacs on VAX/VMS's, which we run here at C-MU.  If
the VT1xx emulation tended to generate lots of XON/XOFFs, this could be a
problem.  H-19 emulation doesn't do this any more than real H-19s do, so it
might be good to keep H-19 emulation around.

On the other hand, though, as should be clear, I've had no experience working
with VT1xx emulators, so my concerns may be about non-existent problems.

Daniel M. Rosenblum,
Ph.D. candidate
School of Urban and Public Affairs
Carnegie-Mellon University

------------------------------

Date: Tue 7 Jan 86 14:48:35-EST
From: [e-mail]
Subject: KERMIT terminal emulations
Keywords: Terminal Emulation

In reply to your request for comments re KERMIT terminal emulation:

I would like to see a single terminal with character/line/block
insert/delete capability as the emulation standard in all KERMIT vanilla
issues.  Ideally, this capability could be supplemented with an option to
load any one of a number of independent terminal emulation drivers (residing
separately on disk) either via a switch at initial KERMIT load time or via
an internal KERMIT subcommand.  The capability to switch among
(text/graphics) terminals while KERMIT is loaded would truly be a luxury.

/Farhad

------------------------------

Date: Mon, 6 Jan 86 17:06:35 pst
From: "Scott Weikart" <cdp!scott@glacier>
Subject:  Re: MS-DOS Kermit Terminal Emulation Query

We definitely want insert/delete line/character; we use kermit a lot for
dialup access.  I'd be happy to give up H-19 for VT102, but not for VT100.
Actually, I'd prefer VT102 over H19 (VT102 is more verbose, but more
standard).  I don't have strong feelings about whether there should be one
or n terminal emulators built in.

-scott

------------------------------

Date: Tue, 7 Jan 86 17:02 EST
From: [e-mail]
Subject: Re: your digested query about dropping H-19 and adding VT102

Go for it!  I say drop the Heath-19 emulation like hot lead and replace it
with a good VT102 emulator.  If we're going to do something, let's do it
right, so choose the VT102, not the namby-pamby VT100.  As for including a
bunch of different emulators in Kermit, forget it.  The VT102 is so standard
nowadays that if you connect to a system that doesn't understand what a
VT102 is, then you're connected to either (1) a system that should have been
scrapped so long ago that the gold on its circuit boards is worth more than
it is, or (2) an IBM mainframe (not including the 1 or 2 of such beasts
which run that IBM abomination of UNIX), or (3) both (1) and (2).

A VT102 is all the emulation capability Kermit will need for the forseeable
future.  ("Forseeable" in this industry being <= 10 years (maybe 5).)

                                        -- Larry Afrin
                                           Dept. of Computer Science
                                           Clemson University

[Ed. - I wouldn't be quite so hard on the H19 -- it does most of what the
VT102 does, and it did it first, and it does it more simply and without all
the XON/XOFF craziness.  It's just too bad it never "caught on" in the sense
that popular operating systems (other than Berkeley Unix) or front ends
support it as a standard terminal type.  Are there any setups where dropping
Heath emulation in favor of VT102 (assuming it didn't send XOFFs all the
time) would do serious damage?]

------------------------------

Date: Mon 6 Jan 86 21:14:45-EST
From: Jin Au Kong <[e-mail]>
Subject: Feedback on MS-DOS Kermit 2.28 and C-kermit VMS

Since VT100 is industrial standard, I would support VT100 emulation
in various implementations.

On VMS C-Kermit:

 1) Terminal response is faster than Kermit-32, and requires less
    BYTLM quota.   We have Kermit-32 v3.1066 and C-kermit 4C present
    on our system.  While C-kermit suffer from data overrun problem
    more often, one cannot type too fast when "connect"ed through
    Kermit-32, or it will kick you back to kermit prompt level.

 2) I like the script feature provided by C-Kermit.  We have
    implemented fileserver and printer server between two 750's
    with this feature.  Wish to learn of some other applications, such
    as mailserver.

 3) It would be great if somebody can incorporate a better
    interruption capability for C-Kermit.  Quite often we have user
    tied up the line because of an incorrect operation in C-Kermit.

[Ed. - The VMS support was added to C-Kermit by some volunteers at DEC who
probably don't have time to do much more with it.  I'm sure that C
compilers are pretty common at VMS sites (much more common, at least than
Bliss compilers), so VMS experts are more than welcome to add whatever
improvements they like to the VMS system-dependent modules.]

------------------------------

Date: 7-Jan-1986
From: [e-mail]
Subject: IBM VM/CMS Kermit vs VM Optimizer

The systems group for the IBM system here recently installed a package from
BMC Corp. called VM Optimizer, one feature of which is compression of data
to 3270 type terminals.  Using this will cause CMS S/1 Kermit to fail.  If
something like this is used, it should be disabled for 7171 and S/1 lines.

brian

[Ed. - Swell, I hope it comes with instructions about how to do that...]

------------------------------

Date: 8 Jan 86  9:26:00 EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit for Epson HX-20?

Does anyone have Kermit running on an Epson HX-20?  I assume (but don't know
for sure) that this is a CP/M-80 machine (and if it is, I don't know if it
runs CP/M 2.2 or 3.0).  I would be very grateful for information about this
system, or better still, a pointer to where to find Kermit for it, or still
better, an Epson HX-20 diskette with Kermit on it!

------------------------------

End of Info-Kermit Digest
*************************
-------
13-Jan-86 12:10:24-EST,12945;000000000001
Mail-From: SY.FDC created at 13-Jan-86 12:08:58
Date: Mon 13 Jan 86 12:08:58-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V4 #3
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Mon, 13 Jan 1986       Volume 4 : Number  3

Departments:

  ANNOUNCEMENTS -
    Bitnet Files Updated

  MS-DOS KERMIT -
    H19 vs VT102 Emulation (many messages)
    Kermit under MS Windows

  MISCELLANY -
    Looking for Apple II CP/M Kermit Diskette
    XON/XOFF Deadlock between vt100 and Hayes Modem
    Bug fix for Prime Kermit server mode

----------------------------------------------------------------------

Date: Mon 13 Jan 86 11:22:40-EST
From: Christine Gianone <[e-mail]>
Subject: Bitnet Files Updated

    The Bitnet Files have finally been updated.  The Kermsrv File
Server on CUVMA should now be able to supply Bitnet Users with
up to date Kermit Files.  JRD's MS-DOS Kermit is still an
exception;  it will be installed on Bitnet when it becomes the
real MS-DOS Kermit.

    The way to get started with Kermsrv is to issue the following
command to CMS:  "SMSG RSCS MSG CUVMA KERMSRV HELP".  If you
haven't used Kermsrv for a while, you may notice that some recent
improvements have been made.

------------------------------

Date: 9 Jan 86 00:24:09 EST
From: John McNamee <[e-mail]>
Subject: H19 and VT10x emulation

VT10x emulation would be nice, but not at the expense of H19. When you're
talking to a host at 1200 baud the goal is to reduce the number of characters
sent. VT10x is so verbose that operation at low speeds is painful. So go
ahead and add VT10x emulation, but leave H19 for those of us still using
dialup lines.

------------------------------

Date: Thu, 9 Jan 86 12:25:20 EST
From: Ivan Auger <[e-mail]>
Subject: VT102 vs H19 support...

I never use kermit's H19 support, instead I use a VT102 emulator that allows
me to run kermit without exiting the program.  So, if H19 support is dropped,
we won't suffer at all.  (By the way, I also use emacs and haven't had any
trouble with VT100 emulators except that it is a good program to find bugs
in this emulators).
Ivan Auger, NYS Dept. of Health

------------------------------

Date:     Thu, 9 Jan 86 19:11 EST
From:     [e-mail]
Subject:  More on VT102 emulation in MS-Kermit

Hmmmm... Just read the latest digest.  Seems I came out sounding more
vehement than I intended.  Now that I've had a chance to put my brain in
gear *first* (before my fingers take off), I can say what I meant to say in
my previous msg: MS-Kermit would be much better off with the VT102's set of
capabilities rather than the H-19's set.  Uh, that means "conceptual set,"
as in, "Make the Kermit emulator do what DECL claims the VT102 can do
*minus* all the implementation deficiencies in DEC's VT102, such as the
XON/XOFF problem."  I was unaware that the XON/XOFF business is a problem to
some users, and now that I am aware of it, I have to agree that if the
Kermit implementation of VT102 is going to include deficiencies such as
that, then we're better off with H-19.

There!  Doesn't that sound nicer?

                                        -- Larry Afrin
                                           Dept. of Computer Science
                                           Clemson University

------------------------------

From: Roy Stehle <stehle@sri-tsc>
Date: 10 Jan 1986 1519-PST (Friday)
Subject: h19 support necessary

I would like to request that h19 support remain in MS-Kermit.

I am working on a VAX running 4.2 BSD UNIX.  The text editor that I use (e)
does not have a termcap for the VT-10X.  There may be some time in the
future that the editor will be enhanced to use the standard UNIX termcap,
but I can't count on that.

We have many h19 terminals in our company and rely heavily on their
compatibility with existing software.

------------------------------

Date: Fri, 10 Jan 86 15:31:02 pst
From: gould9![e-mail] (Joel West @ CACI)
Subject: MS-Dos terminal emulation

VT100 is fine.  VT102 is better, and the standard for Terminal emulators.
Junk the H-19.  Any system that can handle it can handle the VT100, but not
vice versa.

If only a partial emulation is done, make sure it is an innocuous one.  The
MacKermit 0.8 is unreadable when switched to "bold"; fortunately, most
systems don't use this.

Also, for VMS users, a VT100-style keypad mapping would be real handy.  I
have a public domain Macintosh desk accessory (off the net) for those times
I need one under VMS.

    Joel West     CACI, Inc. Federal, La Jolla
PS:

> Date: Tue, 24 Dec 85 22:01 EST
> From: Larry Afrin <[e-mail]>
> Subject: My Two Cents on the MS-Kermit 2.28 jrd "Display Problem"
>
>    I saw in the Digest a couple of msgs, one from Kathleen <last name?> and
> one from Mike Iglesias, re "display problems" with MS-Kermit 2.28 jrd on old
> (16K/64K motherboard) and Compaqs.  I don't know about the Compaq side of
> the issue, but I'm also running 2.28 jrd on a 16K/64K vintage 1981 IBM PC,
> and I have had no hint of any display problems since I first assembled and
> installed the program.

This is probably what we have on our Compaq 286, and it's no figment of our
imagination.  We used the straight IBM .exe (nothing to do with source)
under MSDOS 3.x, and other than that, have no problems.

------------------------------

Date: Sun, 12 Jan 86 20:11:04 PST
From: [e-mail] (David Ragozin)
Subject: H19 emulation in ms-dos kermit

Although I can't speak for the comuputing center here at the University of
Washington, I can say that our instructional computing system is heavily
dependent on h19 and z-29 terminals.  Most instructional computing uses a
screen editor, which has been optimized for this h19 environment.  As a
result, the h19 emulation in kermit has been a very appealing aspect.

Although I personally think the vt102 emulation would be quite nice to have,
and it is desired by our Engineering College computing group, I would hope
that some options could be maintained.  The idea of having some generic
terminal emulator modules, which could then hook into specific terminal
emulator modules at compile time might be a way to go.

As you also may recall, some of our staff created a very bare bones
tektronics 4010 emulator which is invoked when heath mode is off, and the
tektronics graphics code is received.  I forwarded this code to you some
time ago. Hopefully we will be able, without too much change, to repeat this
graphics terminal extention with whatever new version you release.

------------------------------

Date: Thu, 9 Jan 86 16:45:32 PST
From: [e-mail]
Subject: Kermit under MS Windows

Since Microsoft Windows claims to allow programs to run which are TopView
aware, I thought I would try the version of MS-Kermit V2.28 jrd which
supports TopView.  I used the PIF file entries advised in
PS:<KERMIT-MS>MSVIBM.TOP.  The resultant program runs fine under Windows,
except for the fact that the update to the screen after a CONNECT command is
painfully slow--about equal to the speed of a 300 baud modem connection.
Oddly enough, the program does not exhibit this behavior in local mode,
after a DIR command to Kermit-MS for example.  I have looked at the source
code, but don't know enough about the TopView interface to understand how it
works.  Both the TopView and normal versions of MS-Kermit run equally
quickly when run as standalone programs under normal DOS, so I would have no
objection to the TopView version becoming the standard one.

By the way, I built my Kermit from source using MASM Version 4.00.  Using
EXEPACK reduced the size of the executable file from 43,000 bytes to
32,000 (when the modules were linked in the order given in MSKERM.MAK).

                    Steve Walton
                    Caltech Solar Astronomy
                    [e-mail]
                    [e-mail]
                    ...!ucbvax!cithep!hamlet#walton@deimos

------------------------------

Date: Thu, 09 Jan 86 01:32:47 CST
From:  [e-mail]  (Dr. Michael J. Dyrenfurth)
Subject: Looking for Apple II CP/M Kermit Diskette

Although I have REALLY tried in this region, I have been unable to
secure a working copy of Kermit-80 that runs on my Apple IIe (c/w PCPI CPM
card, Videx Ultra-term 80/160 column card, Hayes 1200 smartmoden, Apple super
serial card).  I desperately need to get 1200 baud CPM communication up.
Is there any way that I can buy a working disk from someone?  I also need
a version that works with a II+ (cw the ALS Smartterm 80 column card, the
Micro-soft CPM card, and Apple Super serial card)

------------------------------

Date: 8 Jan 86 05:15:29 GMT
From: Dennis Bednar <rlgvax![e-mail]>
Subject: XON/XOFF Deadlock between vt100 and Hayes Modem

Kermit XON/XOFF Deadlock Bug Caused by Hayes Command Echo Enabled

    I recently ran into a problem of kermit "locking" up sometimes
when using a Hayes Smartmodem, and I thought I would share it with the
net.

    Well, I looked into this problem and found that it was caused
by me connecting to the Hayes modem directly, and and accidently
typing control-s (XOFF).  The ^S was passed through as data to the
modem.  At this time, I had set the Hayes dip switch to enable echoing
during Hayes command mode, merely for convenience to me. This led to
an XON/XOFF deadlock problem between the vt100 and the Hayes
Smartmodem.

Repeat by:
    # this is a comment
    # enter C-Kermit command mode
    set modem dir    # kermit command to say direct hardwired line
    # I know, I know, C-kermit's dial command will interact
    # with the Hayes, and this problem will not occur if I
    # use the kermit "dial" command, but I was just experimenting.
    set esc 1
    connect
    # kermit connects your terminal to the modem now
    # Now type AT several times, and verify that the OK prompt appears.
    # Now type control-s.
    # Now type AT, but you don't see OK.
    # In fact nothing you type is sent.  This problem assumes that your
    # terminal understands that ^S inhibits the terminal kb's from
    # sending on the tty line.

You MAY NOT BELIEVE THIS, BUT THE THE HAYES ALSO ECHOED the control-s!!!!!!!
Therefore the ^S typed on my keyboard was passed through kermit, echoed by
the modem, and passed back through kermit, and sent to my terminal screen.
This caused my vt100 terminal's KBD LOCKED (Keyboard Locked) LED to turn on.
If you try typing ^Q to break the problem, your terminal does not transmit
it, because output is inhibited until ^Q is received from the host, which
cannot happen, so you are deadlocked.  Fortunately, since I was using a
vt100 terminal, I merely pressed the SET-UP key twice, which turned off the
KBD LOCKED light. For an ignorant user, this could be bad.

Best solution: Disable Hayes echoing during command mode, and this problem
cannot occur.

Dennis Bednar    Computer Consoles Inc.    Reston VA    703-648-3300
{decvax,ihnp4,harpo,allegra}!seismo!rlgvax!dennis [e-mail]

------------------------------

Date: 10-JAN-1986 16:39:18
From: [e-mail]
Subject: Bug fix for Prime Kermit server mode

Here's a fix I had sent in for bug in Prime Kermit causing it to NAK an I
packet instead of sending an Error. Will get through the backlog of bug reports
and such over the next week or so if the link stays going!

         Alan

  Date : 10 January 1986
  From : Rick Burne, Ealing College of Higher Education, London UK
  Subject : Bug in Prime KERMIT in server mode

In server mode PRIME KERMIT responds to an I packet with a NAK rather than
anything sensible such as a qualified ACK or an error packet. This should be
fixed in the next release from The Source, but in the meantime here is a quick
edit to make it respond with an error packet.

File MSG_TYPES.PLP

Around line 24, insert a line
           MSG_INIT by 'I'         /* Init-info packet */
after the line
           MSG_EOF by 'Z'          /* End of file (EOF) */

File SERVER.PLP

Around line 225, insert a new clause in the main do while loop:
          when (MSG-INIT) do;
            snd_msg = 'Unimplemented server command';
            call send_packet('E',length(snd_msg),msg_number);
          end;
before the line
          end;    /* select */

File REC_MESSAGE.PLP

Around line 72, insert a line
         msg_init,
before the line
         msg_rcv_init) return ('1'b);

------------------------------

End of Info-Kermit Digest
*************************
-------
17-Jan-86 20:08:32-EST,16830;000000000001
Mail-From: SY.FDC created at 17-Jan-86 20:08:03
Date: Fri 17 Jan 86 20:08:03-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V4 #4
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 17 Jan 1986       Volume 4 : Number  4

Departments:

  MS-DOS KERMIT -
    New Kermit for Olivetti M24 PC (and IBM PC) with VT100 Emulation
    MS-DOS Kermit Available for RMX-86
    HP-Portable Kermit 2.28 jrd/2
    Don't Drop H-19 Emulation
    Feedback on W-Kermit
    Kermit Versus Cermetek Modem (212PC) and Modem-Mate Software
    TI Pro Kermit at 9600 Baud

  MISCELLANY -
    Contacting Lancaster University for Kermit Distribution in the UK
    Kermit Diskette Wanted for HP-9836
    CMS Kermit 2.01 bugs fixed

----------------------------------------------------------------------

Date: Wed 15 Jan 86 10:45:55-EST
From: Frank da Cruz <[e-mail]>
Subject: New Kermit for Olivetti M24 PC (and IBM PC) with VT100 Emulation

This is to announce MS-DOS Kermit support for the Olivetti M24 PC, which is
IBM compatible except for the keyboard, contributed by Andrew J. Hunt of
CSIRO, Division of Radiophysics, Epping NSW (Australia).  It includes VT100
emulation, and extensive support for the Olivetti keypad.  The new support
is embodied in the files KER:MSXM24.ASM and KER:MSYM24.ASM.  A "boo" file
(encoded .EXE file, decodable using the KER:MSBPCB.BAS or KER:MSBPCT.BAS
programs) based on version 2.27 of MS-DOS Kermit is available in
KER:MSVM24.BOO, and the .EXE file itself (for those who can FTP 8-bit binary
files) in KB:MSVM24.EXE.  I tried it briefly on a PC/AT, and it seemed to
work as a VT100 emulator, at least for EMACS purposes.  Andrew claims it
also simulates the VT100 graphic set sufficiently to produce EDT help
screens.

This code will probably not be used as a basis for any VT100 emulation that
may appear in the forthcoming release, 2.29, but it will certainly be
looked at to see if there is anything there that might be missing from the
Indiana/Purdue VT100 code.  In the meantime, those who are desparate for
VT100 emulation in IBM PC Kermit might be able to get by using this version.

The program is thoroughly documented in KER:MSVM24.HLP.  As usual, all files
mentioned above are available on the Internet using FTP login to host CU20B,
user ANONYMOUS, any password.

------------------------------

Date: Fri 17 Jan 86 16:14:04-EST
From: Frank da Cruz <[e-mail]>
Subject: MS-DOS Kermit Available for RMX-86

This is to announce an implementation of MS-DOS Kermit for iRMX-86 on the
Intel 300 Series from Jack Bryans, California State University, Long Beach
([e-mail]).  This is a rather unusual addition to the MS-DOS
Kermit family, in that the underlying operating system is not MS-DOS at all.
As Jack puts it, "MS-Kermit (essentially unchanged) has been placed in a
cradle which leaves it blissfully unaware that it is not running under DOS".
When he says "essentially unchanged" he means that a few minor syntax
changes were necessary in some of the system-independent modules, which
should be reflected in the forthcoming release 2.29.  The files relating to
this version are in KER:MS%RMX.* ("%" is DEC-20 wildcard notation to match
any single character), available using anonymous FTP from CU20B.

Included is a .BOO file, which will be of use only if the Intel system has a
Basic interpreter that can run one of the .BOO file decoders --
KER:MSBPCB.BAS or KER:MSBPCT.BAS.  The 8-bit binary executable program is in
KB:MSVRMX.EXE; if there is some more standard way of representing it
printably (an Intel HEX file maybe?) then I'd appreciate it if someone
would create one from the .EXE and send it in.  It's probably not possible
to recreate this program from the sources in KER:MS*.* at this point because
of inconsistencies between the current version (2.28) and the version upon
which Jack's work is based (2.26), the name changes, etc, plus the fact that
the current source does not reflect Jack's suggested syntax changes (see
KER:MSVRMX.BWR about this).  If all this sounds too complicated to deal with,
the program may be ordered on diskette from:

     California State University, Long Beach
     University Bookstore
     Attn: Lyle Bartlett
     6049 E. 7th St.
     Long Beach, CA 90840

$6.00 per 5 /14" DSDD RMX format diskette.  Thanks to Jack for this submission.

------------------------------

Date: Wed, 15 Jan 86 19:58:50 mst
From: [e-mail] (Dave Forslund)
Subject: HP-Portable Kermit 2.28 jrd/2

The new jrd/2 version of Kermit works fine on the HP Portable Plus.  I've been
testing it for a few days and have noticed no problems.

Since the last submitted version of MSXHPX.ASM, we have fixed the problem of
leaving the modem/serial port on.  The context diffs follow:

[Ed. - Thanks, Dave!  Code omitted; the updated module is available in
KER:MSXHPX.ASM.]

------------------------------

Date: Mon 13 Jan 86 23:13:46-EST
From: Joe Smith [phone] <[e-mail]>
Subject: Don't Drop H-19 Emulation

Removing H19 emulation won't make the terminal emulator smaller.  Because if
you are doing full VT102 emulation, then you have to respond to <ESC>?2l which
puts a real VT10x terminal in VT52 mode.  Given all the routines to do VT102
functionality, adding H19 features to the VT52 dispatch table is trivial.

In other words, it costs almost nothing to have VT102 and H19 emulation both.

I strongly recommend ripping out the "SET H19" command and replacing it with
a new command, such as "SET TERMINAL xxx" with the default of xxx=ANSI.
People that need H19 response need only "SET TERMINAL H19" or have the host
computer send <ESC>2l to get the VT102 out of ANSI mode and into VT52/H19 mode.

[Ed. - This is the most succinct and sensible statement on the subject to
date, and 2.29 will probably wind up structured along these lines.  Thanks
to all who sent their opinions -- I think this approach will make everyone
happy.]

------------------------------

Date: Fri, 17 Jan 86 08:52:35 PST
From: [e-mail]
Subject: Feedback on W-Kermit

I downloaded WKERMIT.EXE (C-Kermit with windows for MS-DOS) yesterday, the
16th.  Works like a charm on my Zenith Z-151 under MS-DOS version 3.10.  I
connected two machines together directly via the serial ports.  At 9600 baud,
the time to transfer a 33,000 byte executable file was 128 seconds for the
latest version of MS-Kermit, and 90 seconds for WKERMIT.  Since no delays were
involved, this 45% improvement is presumably due to WKERMIT's compression.

Now if we can only convince CompuServe to use windowed Kermit instead of
XMODEM...

                    Steve Walton
                    [e-mail]
                    [e-mail]

[Ed. - Good news!  I would be very interested in any statistics that people
who use the public networks could provide about W-Kermit's performance.  If
anyone is in a position to do some benchmarking, we could really see if the
windowing extension lives up to expectations in the environment it was
designed for.  The idea would be to pick a group of MS-DOS files, say a .COM
file, an .EXE file (preferably unpacked), a plain text file, and a highly
indented text file (like C program source, untabified) -- all of nontrivial
size, say 10K-50K -- and transfer them at 1200 baud over a link having no
built-in delays (say, a direct dialup or hardwired connection) and again
over a public data network (like Telenet or Tymnet), both with windowing and
without.  And maybe even with several different window sizes.  All other
options should remain constant.  Note the elapsed time to transfer each file
in each case.  The test could be conducted between two PCs (XTs, ATs)
running W-Kermit (one of them might be at the TCOMM BBS mentioned by Jan van
der Eijk in his Windows Kermit announcement in Info-Kermit V4 #1), or
between a PC running W-Kermit and the Kermit at The Source (if you have an
account there).  The latest release of Profession YAM is also reported to
support the windowing extension.  Any reports will be reproduced in
Info-Kermit, naturally, and may also make it into the Kermit Book (with full
credit) if I get them in time.  Here's a sample table to fill in:

               (No  windowing)   (Full Duplex Windowing..........)
               Xmodem   Kermit   Kermit   Kermit   Kermit   Kermit
Window Size:      0        0        4        8       16       31

File      File    Elapsed time to transfer at 1200b, in seconds:
Name      Length  Direct connection:

???.COM   ?????   ?        ?        ?        ?        ?        ?
???.EXE   ?????   ?        ?        ?        ?        ?        ?
???.TXT   ?????   ?        ?        ?        ?        ?        ?
???.C     ?????   ?        ?        ?        ?        ?        ?

                  Public network (which one?):

???.COM   (same   ?        ?        ?        ?        ?        ?
???.EXE   files   ?        ?        ?        ?        ?        ?
???.TXT   as      ?        ?        ?        ?        ?        ?
???.C     above)  ?        ?        ?        ?        ?        ?


It's more important to fill in a whole column than a whole row.
Thanks in advance to anyone who undertakes to do any of this!]

------------------------------

Date: 17 Jan 1986 10:21:41 CST
Subject: Kermit Versus Cermetek Modem (212PC) and Modem-Mate Software
From: [e-mail]

What is the latest word on Kermit and internal modems?  Is it possible to
get Kermit to run on PC's with internal modems such as the Cermetek (212PC)?
If the answer is yes I would surely be interested in how, if the answer is
no I would be most appreciative of a laymen's explanation as to why.

Regards,
Sam DelaTorre

[Ed. - This is an oft-asked question.  MS-DOS Kermit includes absolutely no
code to deal explicitly with internal modems.  If it did, the program would
rapidly become unmanageable.  Rather, we depend -- so far, at least -- upon
the modem manufacturer to make the modem behave exactly as the regular
asynchronous adapter does.  Many internal modems do (like the Hayes); others
emphatically do not (like the PCjr's built-in modem).  Those that don't
would require very hardware-specific code to support, and this code would
tend to reduce the transportability of the program (e.g. among IBM
compatibles) as well as its robustness and longevity.  So the party line
remains "avoid internal modems!"]

------------------------------

Date:  Thu Jan 16 11:41:27 EST 1986
From: dolqci!irsdcp!scsnet![e-mail]
Subject: TI Pro Kermit at 9600 Baud

Has anyone had any experience with TI kermit version 2.28 revision 5
transfers at 9600 baud?  I am trying to get my TI to transfer files to my
Unix System III box over a direct line at 9600 baud.  It work MOST of the
time, but intermittently my C-Kermit thinks it got a ^C and aborts, and then
Unix gets a ^D and logs me out.  Any thoughts, suggestions, or messages of
condolance please sene to me via uucp and/or to the digest.  Thanks.

UUCP:    (1) seismo!dolqci!irsdcp!scsnet!sunder        [phone]
    (2) decvax!philabs!ubbs!sund                (voice)
CIS:    74026,3235
Mail:    IRS 1111 Constitution Ave. NW  PM:S:D:NO
    Washington, DC 20224  Atten: Mark E. Sunderlin

------------------------------

Date: 16-JAN-1986 10:18:44
From: [e-mail]
Subject: Contacting Lancaster University for Kermit Distribution in the UK

Lancaster University maintains a collection of almost all Kermit files
online on a VAX, and keeps it as in-step with CU20B as possible.  The files
are in a public access username, which can be logged in to from the JANET or
PSS networks or by dial up at any time.  To access the distribution service,
users should do the following:

From PSS:   1. Call 23425240010104
               to get to our PSS gateway using X29. Depending on what PAD you
               are using the first few digits may need replacing with, eg, "A"
            2. Call 000010404000
               from the gateway to get to our VAX11/780 system (running VMS)
            3. Log in to user KERMIT, password KERMIT.

From JANET: 1. Call 000010404000 using X29
               (The system's NRS name is LANCS.VAX1 which you might have
               already configured and available to match this address)
            2. Log in as (3) above

By Dial-up: 1. Call one of 0524-63423, 0524-67754 or 0524-67671. These are all
               V21/V23 autosense modems: put your modem online as soon as ours
               answers, rather than waiting for carrier. Lines are set for full
               duplex, 8 data bits, no parity, XON/XOFF flow control.
            2. Press RETURN a few times to wake up the pad and get a "PAD>"
               prompt
            3. Type CALL LANCS.VAX1 to connect to the VAX
            4. Log in as above.

News of the day will appear, as well as pointers to the help files and indexes.
The system is rather overloaded and slow, so please be patient when logging in.

I can be contacted in several ways:

By letter:  Alan Phillips
            Communications Group
            Department of Computing
            Computer Building
            Lancaster University
            Lancaster LA1 4YW
            UNITED KINGDOM

By phone :  [phone] x 4881

By e-mail:  To user SYSKERMIT @ LANCS.VAX1
               PSS address   234252400101.000010404000.FTP.MAIL
               JANET address 000010404000.FTP.MAIL
            Please give your own full mail address and site name.  Reply over
            ARPA is unreliable and slow.  I cannot reply over uucp, or anything
            other than JANET and ARPA.

I would prefer contact by e-mail if at all possible. Response may be slow as
this is a one-person operation and it stops when I'm away.

All users can collect files from us by Kermit or by file transfer at no
charge.

I can write tapes in DEC ANSI D or VMS BACKUP formats, and supply some
Kermits on floppy disc (contact me for availability).  Supply is free to all
educational establishments, but there is a handling charge to others.  I
can't, I'm afraid, generally undertake to supply outside outside the UK/Eire
as the work load would become too great.

[Ed. - Many thanks for providing this service within the UK!]

------------------------------

Date: Thu 16 Jan 86 15:19:08-PST
From: David Liu <[e-mail]>
Subject: Kermit Diskette Wanted for HP-9836

Is there anyone who has a copy of HP-9836 Kermit?  I would like to arrange to
get a disk.

[Ed. - This is a frequent request.  Can anyone help David out?  Better
still, does anyone know of the existence of an HP-98xx user group?  If so,
could someone who has this version of Kermit on an HP-98xx-format diskette
please submit it to the user group so that others could order it from there?
If there's no such user group, maybe HP itself would be willing to
distribute it to their customers.

Anyone who manages to set up something like this, please let me know so I
can refer future inquiries of this kind to the user group (or HP).  In fact,
this goes for every microcomputer, PC, workstation, etc, version of Kermit.
If you have a working version, please submit it on native media, with any
appropriate documentation, to a user group that accepts mail orders.
Thanks!]

------------------------------

Date: 16 January 86 17:57 EST
From: NJG@CORNELLA
Subject: CMS KERMIT 2.01 bugs fixed

I have discovered (and corrected!) a couple of bugs in CMS KERMIT version
2.01:

If CMS KERMIT is executed more than once from an EXEC without returning
to CMS command level any attempt to 'take' a file more than once will
fail as the file has been left open.  This can be fixed by closing the file.

Update 2 to version 2.00 of CMSKERM does not pad RECFM F files
with spaces as it claimed, it pads with hex 0's.

When processing a SERVER 'bye' request on a 7171 (or Series/1) line
no XON should be sent before issuing the CP LOGOFF command. If it is
the CONWAIT following the WRTERM will wait forever.
The content of file CMSKERM FIXBYE are:

"8-)" Nick Gimbrone <[e-mail]> [phone]

[Ed. - Thanks, Nick!  The listings are omitted, but have been added to
the KER:CMSMIT.BWR file, and will be included (in one form or another) in
the next release of CMS Kermit.]

------------------------------

End of Info-Kermit Digest
*************************
-------
22-Jan-86 17:15:48-EST,19044;000000000001
Mail-From: SY.FDC created at 22-Jan-86 17:14:00
Date: Wed 22 Jan 86 17:14:00-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V4 #5
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 22 Jan 1986       Volume 4 : Number  5

Departments:

  MS-DOS KERMIT -
        Victor 9000 Support for MS-DOS Kermit 2.28
        APC MS-Kermit
        Info-Kermit
        Olivetti M24 Kermit: VT100 Split-Screen Scrolling Problem

  MISCELLANY -
        MacKermit from Rice?
        SuperKermit File Transfer Times
        Tandem Running Guardian OS Kermit?
        Novation Apple-Cat II?

----------------------------------------------------------------------

Date:     Mon, 20-JAN-1986 20:31 MST
From:     <[e-mail]>
Subject:  Victor 9000 Support for MS-DOS Kermit 2.28

This is to announce Victor 9000/Sirius 1 Support for MS-DOS Kermit 2.28,
contained in two assembly-language files, MSXV90.ASM and MSYV90.ASM.  The
support includes the full option list of baud rates (45.5 to 38400 baud),
the use of either serial port, full HEATH emulation, and restoration of the
screen to its previous condition when reconnecting to the same port after
disconnecting.  The SET KEY option has not been supported since that does
not seem to be necessary with the Victor's soft keyboard.

For those who would like to get more out of the Victor 9000, there is also
a version of MSYV90.ASM which gives full Tektronix 4010 emulation.  This
module provides full text, graphics, and graphics input (GIN) emulation.
The graphics are good quality, thanks to the quality of the Victor's screen,
and the graphics input appears to be adequate for most needs.  However, the
text leaves a little to be desired in terms of readability.  The font is
home grown (my home) and I didn't have a lot of time to put into fine tuning
the different characters for readability, but they can be deciphered with a
little practice.

There are three Victor-specific modules required to generate the Tektronix
version.  These are
      MSZV90.ASM - replaces MSXDMB to get the segments in the right order
      MSXV90.ASM - same one used for the regular KERMIT
      MSYV9T.ASM - provides the Tektronix emulation
The first module is required to get the segment containing the graphics
screen region as low as possible in memory.  The Tektronix emulation mode is
entered by setting the HEATH mode off (i.e., SET HEATH OFF).

                                  Bryan G. Peterson
                                  PETERSONB@BYUVAX

[Ed. - Thanks!  This should allow us to get rid of some of the old Victor
versions that have been cluttering up the Kermit Distribution the last few
years, and allow the Victor to benefit from new MS-DOS Kermit releases.
Since there is no .BOO or .EXE file, the program will have to be built from
the source, following the directions in the documentation.  The files are
in KER:MS%V9*.* on CU20B, available via anonymous FTP on the Internet, and
from KERMSRV at CUVMA on BITNET.  If anyone manages to build a working .EXE
in a place I can FTP it from, I'll add it to the distribution and make a
.BOO file from it.]

------------------------------

Date: Sun 19 Jan 86 17:30:14-PST
From: Ronald Blanford <[e-mail]>
Subject: APC MS-Kermit

The corrected versions of MSXAPC.ASM and MSAPC.EXE are ready for ftp
from my account <CONTEXT>.

This latest version fixes a bug in which MS-Kermit incorrectly handled
the function keys on the APC during Connect mode.  When programmed
using the operating system KEY command rather than from within Kermit,
only the first character would be sent when the function key was pressed,
and the rest would wait until the next keystroke.  This has now been
corrected.  Thanks to Ian Gibbons for the fix.

-- Ron

[Ed. - Thanks, Ron.  The new files are in KER:MS%APC.*, including a new
.BOO file.  The 8-bit binary .EXE file is in KB:MSVAPC.EXE.  These files
are available, as usual, via anonymous FTP from CU20B on the Internet.
All but the .EXE file are also available on BITnet from KERMSRV at CUVMA.]

------------------------------

Date:    Mon, 20 Jan 86 13:58 EST
From:  [e-mail]
Subject: Info-Kermit

I have been archiving the Info-Kermits from the MAIL files on KermSrv.  I
have been putting Volume 1 - 4 into partitioned datasets with an index of
all the subject lists.  This is great and very useful, but unfortunately all
the pre-volume information was not digested into any specific format so I am
at a lost for the best way to break them into smaller chunks.  I was
wondering if you had any ideas on this?  Do you think anyone would be
interested in the digests as partitioned datasets?  I would be more than
happy to send them to you for distribution if you think it a worthwhile
thing.

Thanks again for your time,

mark

[Ed. - If anyone out there is interested in an Info-Kermit PDS, please
respond to Mark directly; if there is sufficient interest, maybe some way
can be devised to distribute it.]

------------------------------

Date: Tue 21 Jan 86 14:30:28-EST
From: PK0P@CMCCTD
Subject: Olivetti M24 Kermit: VT100 split-screen scrolling problem

I downloaded the Olivetti M24 version of Kermit-MS and noticed a problem
with split-screen scrolling in VT100 emulation mode.

I'm using an IBM PC/XT, DOS 2.1, EGA, and Enhanced Color Display.  I'm also
using the ANSI.SYS device driver.

When talking to a VAX/VMS system, I noticed the problem with the VMS PHONE
facility.  From PHONE, one can do DIR to see a list of users on the system,
or on another VAX/VMS system connected through DECNET.  If there are more
than 18 users on the system, PHONE will do a split-screen scroll to list
them (provided the terminal is one of the VT1xx or VT2xx series).  The first
time through, the list will be displayed correctly with split-screen
scrolling.  If you then issue a second DIR command from PHONE, all the lines
with be displayed on top of each other on the status line (on about the 5th
line from the top). Then if you exit from PHONE, you will find your cursor
on line 1, with only a one line scrolling region!  To correct the problem,
you can issue the escape sequence to reset the scrolling region, or escape
back to Kermit-MS and type:

SET HEATH ON
SET HEATH OFF (to get back to VT100 Emulation)

(Note: this is only noticeable if the VAX system has 18 or more users logged
in.  PHONE does not use split-screen scrolling when it can list all the
users on one screen.)

Peter Kanaitis
Research Systems Analyst
Allegheny Singer Research Institute
Allegheny General Hospital
Pittsburgh, PA 15212

Voice: [phone]
Net: [e-mail]

[Ed. - Thanks for the report -- it has been passed along to Joe Doupnik to
make sure the forthcoming version 2.29 will not have the same problem.]

------------------------------

Date: Sat, 18 Jan 86 14:12:11 pst
From: Joel West <[e-mail]>
Subject: MacKermit from Rice?

Frank,

Since I doubt you were at the MacWorld expo this week, I thought I'd pass it
along...

"The Rice University Macintosh Development Project has developed several
public domain products for Macintosh computers.
...
Rice Mac Kermit
        ...It will also allow you to send full applications as
        well as text only documents.  Eighth-bit prefixing
        is supported.  This program is currently in beta test.
...

Rice University
Institute for Computer Services and Applications
POB 1892
Houston, TX 77521

Unfortunately, the guy at the Rice booth didn't know much about it, and said
I had to come back and speak to the woman in charge.  I never made it.

[Ed. - According to the new issue of "Wheels for the Mind" (V2 #1, Winter
1986) the status of Rice Univerity's Macintosh Kermit is "Currently on
hold".  Rice has never been terribly communicative about the various Kermit
programs they've been working on -- they also have a pretty fancy TSO Kermit
written in PL/I, but which requires a proprietary support package which they
sell; hence we don't distribute it.]

If you find out any more about this (either through INFO-KERMIT or whatever
channels you have), I'd like to know.  I'm a heavy Mac and Kermit user, and,
if this is better than the 0.8 C-Kermit, would be glad to add it to our
user-group distribution.

[Ed. - I'll be glad to add it if Rice sends it in.]

At this point, the most interesting issue is whether MacKermit will support
the Hierarchical File System.  The main reason why some programs don't is
that they take the volume ref no, convert that to a disk volume name, and
then make a string of the form "Disk Volume:File Name".  Instead, all file
names MUST be internally stored as volrefno,filename.  (the volrefno now
gives a volume and directory under HFS) If you follow the rules, code can
work under old or new systems.

[Ed. - Reportedly Mac Kermit works just fine under HFS; that is, it works
as well as it does on pre-HFS systems.]

Also, MacKermit does not support out-going wild-cards.  This would be real
useful.

[Ed. - Yup.  So would saving the screen or lines scrolled off the top,
a mouse-positioned cursor, the ability to deal with Mac Binary format, etc.
I hope we'll be able to do some more work in this area some day.]

        Joel West       CACI, Inc. - Federal
        [e-mail]
        {decvax,ucbvax,ihnp4}!sdcsvax!noscvax!westjw

------------------------------

From: Chuck Forsberg WA7KGX <[e-mail]>
Subject: SuperKermit file xfer times
Date: 20 Jan 86 10:46:37 GMT

To answer some questions in INFO-KERMIT, I ran some tests transferring
files with a variety of protocols, including SuperKermit (Kermit with
Sliding Windows).  Here are the results.

        SuperKermit: Some File Transmission Time Comparisons
                        Chuck Forsberg 1-20-86

Two files were used for this series of tests.

A 112070 byte .EXE file produced by the Xenix to DOS cross development
system was used to test the transfer of binary files.  Of the 19886
nulls in the file, many were in buffers, giving a chance to test
Kermit's run length compression.

A 11456 byte document produced by nroff contained no special characters
save CR and LF.  The document used little or no indentation.

Transmissions were from a 9 mHz PC-AT running DOS 3.1 or SCO SYS V Xenix, to
a PC with a NEC V20 at the standard 4.77 mHz.  Ramdisks were used on the DOS
machines.  The 9600 bps transfers used a direct connection between the
adjacent machines.  1200 bps transfers used a Hayes 1200 and MI-2 212a modem
dialup.  Software used was Professional-YAM 15.24, Crosstalk 3.6, and Unix
sb(1).  Pro-YAM to Pro-YAM SuperKermit transfers used 3 byte block check
(CRC-16), eight bit transfers (no quoting), and compression.

Transfers with The Source used the Portland OR Uninet node.  Source Kermit
transfers used 1 byte block check, eight bit transfer, and no compression.
Previous tests have indicated Telenet gives similar results on downloads
from The Source but was very much slower on uploads thanks to poor network
buffering.

.EXE File (112070 bytes)
Time    Speed   Conditions

2:00    9600    Xenix to Pro-YAM YMODEM-g
2:00    9600    Pro-YAM to Pro-YAM YMODEM-g
2:11    9600    Pro-YAM to Pro-YAM XMODEM/CRC
3:54    9600    Pro-YAM to Pro-YAM SuperKermit
4:10    9600    Xenix to Crosstalk XMODEM
5:20    9600    Pro-YAM to Pro-YAM Kermit (NO Windowing)
15:55   1200    Pro-YAM to Pro-YAM YMODEM-k
22:33   1200    Pro-YAM to Pro-YAM SuperKermit
25:22   1200    Pro-YAM to The Source SuperKermit
25:95   1200    The Source to Pro-YAM SuperKermit

Nroff output file (11456 bytes) (all at 1200 bps)
Time    Conditions

1:49    Pro-YAM to Pro-YAM YMODEM-k
1:53    Pro-YAM to Pro-YAM SuperKermit
1:59    Pro-YAM to The Source SuperKermit
5:32    Pro-YAM to The Source Kermit (NO Windowing)

DISCUSSION

Between two directly connected microcomputers, XMODEM protocol gives
good results, 855 bytes per second throughout out of 9600 bps.  The
1024 byte blocks used by Pro-YAM's YMODEM-k and YMODEM-g give a throughput
of 933 bytes per second (97 per cent efficiency).

Pro-YAM's Kermit/SuperKermit routines are based on the code developed at
The Source, which in turn is based on C-Kermit.  Compared to the earlier
Unix Kermit, C-Kermit uses extra layers of processing which limit performance
at high speeds.  The .EXE file should transfer in 2:49 but in fact takes
3:54.  Most of this delay was enforced by the PC stopping the transfer
with XOFF flow control.  A PC-AT or AT&T 6300 should be able to receive
data with SuperKermit at 9600 bps with little or no flow control.

[Ed. - Sigh... Layering is the price we pay for portability.  The old
version didn't run under System III, System V, VMS, or on the Macintosh...]

SuperKermit does allow the receiver (in this case the slower PC) to overlap
serial transfers with its processing.  Without SuperKermit, all the processing
must be done sequentially, resulting in a 5:20 transfer time for the same
file.

The advantage of Sliding Windows or other means of sending multiple blocks
can be seen by comparing the timing for the Xenix to Crosstalk XMODEM
download (4:10) with YMODEM-g download (2:00).

When national or global packet switched networks introduce delays,
the difference becomes significant even at 1200 bps.  The 1:52 transmission
time between two SuperKermits only loses six seconds when uploading to
The Source.  Regular Kermit (no windowing) takes more than twice as long
at 5:32.  Standard XMODEM transfers with Compuserve suffer from similar
delays.

[Ed. - And of course you can't do MODEM transfers with The Source at all,
because an 8-bit path is required.]

The size of the sliding window has little effect on performance as long
as it is large enough to contain the outstanding packets.  The maximum
possible is 31, but it appears that 8 are sufficient for normal conditions.
Of course, if the timesharing system or the network restricts the flow
of data, no amount of windowing is going to help.  I did notice a slight
amount of network flow control when uploading files to The Source.

In the non window transfer with The Source, round trip delay time was
about 1.6 seconds according to my calculations (it seemed longer).
YMODEM-k under these conditions would have uploaded the .EXE file in
19 minutes compared to SuperKermit's 25 minutes.  A Kermit transfer
with 1024 byte packets without windowing would have taken 27 minutes
(losing 3 minutes from the delays, gaining a minute from decreased overhead).

The benefits derived from Kermit's run length encoding form of compression
are greatly dependent on the nature of the files being transmitted.  It
appears most of the difference between the 22:33 minute Pro-YAM to Pro-YAM
SuperKermit transfer and the 25:22 Pro-YAM to The Source transfer is related
to compression available in the Pro-YAM Kermit but not The Source.

However, long files downloaded from bulletin boards are often SQueezed or
compressed before transmission, reducing the value of Kermit's compression.
Most compression programs emit all 8 bit codes, resulting in an average
25 per cent Kermit efficiency loss from control character quoting.

The main Kermit inefficiency in transferring binary files is control
character quoting, which increases transmission time by 25 per cent average.
A useful Kermit extension would be a way to allow most control characters to
be transmitted without quoting.

[Ed. - Right, but this is the same quoting that allows Kermit to work in
environments where MODEM can't.  Extending Kermit to allow a set of control
characters to be transmitted "bare" seems like a good idea, but since it is
just as often the intervening communication hardware or software that is
sensitive to control characters as it is the computers themselves, a great
deal of expertise -- and often "manual intervention" -- would be required
of the user.  Better to pay the price of the overhead.]

A lesser source of overhead comes from the characters that frame Kermit
packets.  It is unfortunate that Kermit does not provide for longer
packets.

[Ed. - But it does -- see the long packet extension, proposed in Info-Kermit
V3 #4.  Some implementations will soon see the light of day.]

                SuperKermit: Unfinished Business

The main item of unfinished business in SuperKermit is to determine the
best criteria with which to force a windowing transfer to abort in a timely
fashion without compromising the robustness of the protocol.  A window
size of 31 means up to 3100 bytes can be sent to the wrong program if one
end of a SuperKermit transfer exits prematurely.  A series of noise bursts
such as dialing crosstalk can generate dozens of spurious packets.  The
normal method of stopping until the line quiets cannot be applied when
the window is open.

[Ed. - Good point!  And thanks for all the work you put into getting
these measurements.]

   Chuck Forsberg WA7KGX  ...!tektronix!reed!omen!caf   CIS:70715,131
   Author of Professional-YAM communications Tools for PCDOS and Unix
 Omen Technology Inc     17505-V NW Sauvie Island Road Portland OR 97231
Voice: 503-621-3406 TeleGodzilla: 621-3746 300/1200 L.sys entry for omen:
omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp

------------------------------

Date: Tue, 21 Jan 86 11:52:43 EST
From: [e-mail]
Subject: Tandem running Guardian OS Kermit?

Do you know of a version of kermit for the Tandem running the Guardian OS?
Or do you know of one under development?

Thanks in advance.

David A. Roth
...decvax!pur-ee!isrnix!pugsly
...ihnp4!inuxc!isrnix!pugsly
Indianapolis,IN

[Ed. - I've received several of these messages lately.  Does anyone know if
Tandem computers have more than one operating system?  We have a version of
Kermit for Tandem, but I think the operating systme is called "Nonstop" --
is that the same thing?  It's written in a language called TAL.  Anybody
know anything about this?]

------------------------------

Date: Tue, 21 Jan 86 21:33:45 EST
From: CHRISTOPHER CHUNG <[e-mail]>
Subject: Novation Apple-Cat II?

Does anyone know of a way to make the Novation Apple-Cat II work with
Kermit?  Is there a version of Kermit that I could get to work with my
Novation modem and my Apple //e or is there a way to modify an existing
version of Kermit to make it work with the Novation?  Any help would be
greatly appreciately!

------------------------------

End of Info-Kermit Digest
*************************
-------
24-Jan-86 14:57:22-EST,12918;000000000001
Mail-From: SY.FDC created at 24-Jan-86 14:56:04
Date: Fri 24 Jan 86 14:56:04-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V4 #6
Sender: [e-mail]
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 24 Jan 1986       Volume 4 : Number  6

Today's Topics:
                         Windows over Telenet
                               TIMINGS
                            Frogs in Space
               Problems/suggestions with/for M24-Kermit
     Workaround for VMS V3.7 vs. LAT-11 vs. MSKERMIT V2.28jrd ...
                  More on Tandem's running Guardian
                   Is anyone running HP3000 Kermit?
                    MODEM7/MEX/KERMIT for UTS-30?
                        Ti kermit H19 Question

----------------------------------------------------------------------

Date: Fri 24 Jan 86 13:46:21-EST
From: Christine M Gianone <[e-mail]>
Subject: Windows over Telenet

Below are the results of a test done using WKERMIT.EXE (C-Kermit with windows
for MS-DOS).  Both an .EXE and a .TXT file were transferred.  The speed in all
cases was 1200 baud and mark parity was used, which in turn causes 8th-bit
prefixing in the .EXE file.  The packet size was 90.  This was done at 5:30PM
on a weekday.  The typical network delay was 1-2 seconds (strictly a guess
based on watching modem lights).  Columns A and B show file transfers between
an IBM AT and 'The SOURCE', using a Hayes modem over Telenet; Column A is from
the IBM AT to 'The SOURCE' and Column B is the other direction.  Column C shows
the time it took to send those files from 1 IBM AT to another.  The first time
shown in each column is the result without windowing; the second time shown (in
parenthesis) is the result using a window size of 16.  This test shows a 2-3
fold improvement in speed when windowing is used over Telenet.


File          File     Elapsed time to transfer at 1200b, in mins:secs;
Name          Length
                                      A             B            C

MSKERMIT.HLP  9371                4:15(1:35)    3:04(1:35)   1:45*(1:30)
SHARE.EXE     8896               7:50(2:30)    7:00(2:40)   1:45*(1:30)

* No matter how hard we tried we could not make WKERMIT work between 2
directly conncted PC/ATs.  These numbers are estimates.

------------------------------

DATE: 24-JAN-1986
FROM: BRIAN@UOFT02
SUBJECT: TIMINGS

 Some sample timings for Kermit-11 and long packet support.  The  packet
size  in  the  RSTS/E  to  P/OS  was  500 bytes, the size from RSTS/E to
RSTS/E was 700 bytes. These sizes are somewhat  arbitrary,  they  depend
more on the system's buffering capabilities than anything else.

Host buffering capabilities:

P/OS                    500 (estimated)
RSTS/E 9.0 or later     up to 7000, given sufficient system pool
RSX11M+                 255 (I/D space CPU only)
RSX11M                  34
RT11                    134 (could be larger with simple mod to XC/XL)

 As it can be seen, large packets make sense only for RSTS/E,  P/OS  and
RSX11M+  if  one  wishes  to  avoid XON/XOFF overhead at high speeds. It
should be possible to run  larger  packets  on  M+  and  RT11  at  lower
speeds.


File transfered: K11POS.TSK, size 102,400 bytes (200 disk blocks)
Actual data packet characters AFTER prefixing was 120,857

Time    Speed   Data rate       Comments
seconds baud


1436    1200    84/sec          11/44 to PRO/350, 'Classic' Kermit
                                local phone call
1237    1200    97/sec          11/44 to PRO/350, 500 Char packets
                                local phone call

2915    1200    41/sen          11/44 to PRO/350, 'Classic' Kermit
                                local call, 1 second ACK delay.
1492    1200    81/sec          11/44 to PRO/350, 500 Char packets
                                local call, 1 second ACK delay.

304     9600    397/sec         11/44 to 11/44, 'Classic' Kermit,
                                connected locally via Gandalf switch.
245     9600    493/sec         11/44 to 11/44, 700 char packets,
                                connected locally via Gandalf switch.

 The last two timings are much lower than the  line  speed  due  to  the
fact  the  the  PDP  11/44  is  running 100% busy trying to keep up with
character interupts using a normal terminal driver.  A  special  purpose
driver,  such  as the XK driver found on P/OS, would have lower overhead
and allow somewhat faster data rates.

 Long packets were chosen for Kermit-11 due  to  the  lack  of  suitable
interupt  driven  i/o (at this time) under one of the operating systems,
RSTS/E. The Sliding  windows  would  likely  function  better  in  those
situations  where  the circuit delay is much higher, or when the circuit
can not accomodate large packet sizes.

brian nelson

[Ed. - The long packet specification is in KER:KPROTO.UPD]

------------------------------

Date: 23 January 1986, 16:38:18 SET
From: Richard J Waite           [phone]       C0       at DDAESA10
      VM/CMS S.P.O.D
      European Space Operations Centre
      Robert Bosch Str 5
      6100 DARMSTADT, West Germany.
Subject: Frogs in Space

Good Day,
         For interest only, the little green chap is now helping in
the joint USA - European - USSR "Giotto" project. The data from the
USSR satellite's is being sent from Moscow to us here at Darmstadt
by means of "Kermit". This data is being used by us and also a USA
university. We are using the Turbo pascal Kermit over there on an
IBM clone at 4800. He is doing very well.

Regards.

------------------------------

Date: January 24, 1986, 12:40 CET
FROM:    <#[e-mail]>
Subject: Problems/suggestions with/for M24-Kermit

Hi,
    I've build M24-Kermit from the assembler sources and I've
got some problems:

1.) In module MSYM24.ASM the symbol LNWRAP is defined. This
    symbol is also defined in MSDEFS.H. To compile MSYM24 I've
    commented out the definition line for LNWRAP in MSYM24.ASM.
    (the definitions in the two files are different).
2.) The delete key (<--) does not work in kermits' command mode.
    When I type DEL nothing happens. When I repeat typing DEL the
    whole line disappears. In terminal emulation mode the DEL key
    works perfect.
3.) I can reproduce the scrolling problem in VMS/Phone reported
    earlier this week.
4.) I would prefer to have the ALT/CTRL/F2 active at initalization
    time (see also 5.). Is it possible to do the keyboard mapping
    on a dynamic basis. In this case you can have your standard
    keyboard driver outside of Kermit and a VT100-like driver
    when using Kermit.
5.) This is a suggestion rather than an problem. We have the
    german keybord (type 2) and it would be great to have the
    modified keyboard driver for this type of kb.

    a.) I would be happy to patch the standard KEYBGR.COM
        if someone could tell me what exaxtely is to do.
    b.) I would send a hexified version to KERMSRV.
    c.) Is there anywhere a description (with sources) of
        a keyboard driver (I know it's the wrong list, but...)?


Martin Knoblauch
TH-Darmstadt, D-6100 Darmstadt, West Germany
EARN/BITNET: #D15 at DDATHD21 (the number sign is really
                               part of my UID)

------------------------------

Date: 21-Jan-1986 2320
From: [e-mail]  (SKIN THE BEARS!!!)
Subject: Workaround for VMS V3.7 vs. LAT-11 vs. MSKERMIT V2.28jrd ...

After poking/playing around with all kinds of parameters on both our LAT-11
terminal and our VMS V3.7 system from a Rainbow running MSKERMIT V2.28jrd, and
trying all the suggestions that Frank sent to me (thanx, by the way), the only
solution to all those LAT terminal overruns is to turn down the baud rate on
the Rainbow's comm port, and subsequently the LAT terminal speed as well, to
4800 baud (I had been receiving lots of re-xmit's and buffer overruns on the
LAT line at 9600, more often than not causing the transfer to fail, or else get
roughly one re-transmit for every packet sent- yuucchhhh!!). However, this
behavior does NOT appear when using the same Rainbow, MSKERMIT, LAT port, and a
VMS V4.2 system. THAT works just fine.  I have a feeling that VMS V4.2 has a
lot more intelligence built into its handling of the LAT than VMS V3.7 does.

    Please note, for all those that sent possible fixes, that the LAT
involved here is not a DECSA (or Pluto box as it's sometimes called), nor
is it a DECserver-100; it's "LAT-11", which runs on a Unibus-based -11
with DZ11's, a DEUNA, and 128KW of memory. In this software, you cannot
modify or change flow control; you're stuck with it (maybe to make writing
the application easier?). Turning HOSTSYNC off had helped a bit for a while
on the VMS V3.7 machine, until the machine being used had its LTDRIVER up-
graded to the proper level. Once that happened, turning off HOSTSYNC was
FATAL (i.e., 2 packets get sent, then a timeout occurs), but leaving it on
displayed the same behavior as it did before the LTDRIVER was upgraded.

    Hope this helps anyone getting bitten by this combination.

    Gerry Hafner, DEC LTN (Littleton, MA)

UUCP:    {decvax|ihnp4|allegra|ucbvax|...}
       !decwrl!dec-rhea!dec-wookie!hafner
ARPA:    [e-mail]

------------------------------

Subject: More on Tandem's running Guardian
Date: 23 Jan 86 14:43:43 CST (Thu)
From: ...decvax!pur-ee!isrnix!pugsly
      ...ihnp4!inuxc!isrnix!pugsly

Since I have sent that to you I have talked to the local Tandem sales office
and from what there salesman tells me...  "If it was written in TAL for a
non-stop then it will run on the EXT Tandem under Guardian".  He was in sales
though :-) .

Thanks again!

David A. Roth

------------------------------

Date: Thu, 23 Jan 86 15:55:42 pst
From: amdcad!amdimage![e-mail] (chris moore)
Subject: Is anyone running HP3000 Kermit?

I have been trying to get HP3000 Kermit running, and so far
haven't had any luck.  In the Connect mode, kermit will
accept a line of input, send it out, and then do a read
to get the response back from the other system.  The read
always either timesout with nothing read, or it never returns
at all and kermit hangs.  Is anyone running this version of
Kermit that could give some pointers as to what I may be doing
wrong?  Thanks.
                Chris Moore
                amdimage!cmoore

------------------------------

Date: Thu, 23 Jan 1986  23:54 MST
From: "Frank J. Wancho" <[e-mail]>
Subject: MODEM7/MEX/KERMIT for UTS-30?

I have a number of users in need of a MODEM7/MEX/KERMIT already
configured on a floppy disk for use on a UTS-30 system running CP/M
3.0.  For one user, the need is urgent.  He has been trying in vain to
upload a file for the last month using Sperry's TTY program, and that
file is a report that is growing daily!

Please contact me directly via net mail, or call my office and leave
your name and number and I will return your call.

Thanks,
Frank

AV: 258-6257
FTS:898-6257
505-678-6257

------------------------------

From: dolqci!irsdcp!scsnet![e-mail]
Date:  Wed Jan 22 11:23:45 EST 1986
Subject: Ti kermit H19 Question

I am running my TI PRO to access my UN*X sys III system and am
having trouble with the h19 emulation.  All works well execpt
for the reverse video.  When my screen should go into
reverse video, nothing changes.  Here is the /etc/termcap
entry I use:
# entry for h19 emulation under TI kermit version 2.28 Revision 5
kb|h19|heath|h19-b|heathkit|heath-19|z19|zenith|heathkit h19:\
    :cr=^M:do=^J:nl=^J:bl=^G:\
    :al=1*\EL:am:le=^H:bs:cd=\EJ:ce=\EK:cl=\EE:cm=\EY%+ %+ :co#80:dc=\EN:\
    :dl=1*\EM:do=\EB:ei=\EO:ho=\EH:im=\E@:li#25:mi:nd=\EC:as=\EF:ae=\EG:\
    :ms:ta=^I:pt:sr=\EI:se=\Eq:so=\Ep:up=\EA:vs=\Ex4:ve=\Ey4:\
    :kb=^h:ku=\EA:kd=\EB:kl=\ED:kr=\EC:kh=\EH:kn#8:\
    :k1=\ES:k2=\ET:k3=\EU:k4=\EV:k5=\EW:\
    :l6=blue:l7=red:l8=white:k6=\EP:k7=\EQ:k8=\ER:
Anyone see any faults with this?  I DO have heath 19 on (Just
eliminating the obvious question -:).  Or does kermit h19
not support reverse video?   Thanks to all who helped me with
my last TI problem.   Please mail replies to uucp(1) and+or the
digest.

UUCP:    (1) seismo!dolqci!irsdcp!scsnet!sunder        [phone]
    (2) decvax!philabs!ubbs!sund                (voice)
CIS:    74026,3235
Mail:    IRS 1111 Constitution Ave. NW  PM:S:D:NO
    Washington, DC 20224  Atten: Mark E. Sunderlin

------------------------------

End of Info-Kermit Digest
*************************

-------
28-Jan-86 16:38:26-EST,8106;000000000001
Mail-From: SY.FDC created at 28-Jan-86 16:37:51
Date: Tue 28 Jan 86 16:37:51-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V4 #7
Sender: [e-mail]
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 28 Jan 1986       Volume 4 : Number  7

Departments:

  ANNOUNCEMENTS -
    MS-DOS Kermit Support for GRiD Compass
    New Wang PC support module for MS-DOS Kermit
    Victor 9000 Kermit

  MISCELLANY -
    Kermit on the Mac Plus
    Rice TSO and Mac Kermits
    Bug in Wildcard Get in C-Kermit 4C(057)
    HP-3000 Connect Mode (2 messages)
    Tandem Nomenclature Clarification
    FC Tape Format?

----------------------------------------------------------------------

Date: Mon 27 Jan 86 17:21:06-EST
From: Frank da Cruz <[e-mail]>
Subject: MS-DOS Kermit Support for GRiD Compass

This is to announce (belatedly!) support for the Grid Compass II computer
in MS-DOS Kermit, contributed by Jim Noble, Planning Research Corporation,
McLean, VA.  It was found on a tape that he sent us last May, unearthed
during recent excavations.  Only the source file is available for now.  If
anyone out there has a GRiD Compass, please take the file and try it out.
If it works, please point us to an .EXE or .BOO file that we can distribute.
The file is in KER:MSXGRI.ASM, available via anonymous FTP from CU20B.

------------------------------

Date: Mon 27 Jan 86 17:47:26-EST
From: Frank da Cruz <[e-mail]>
Subject: New Wang PC support module for MS-DOS Kermit

Also from Jim Noble -- improved Wang PC support for MS-DOS Kermit, including
key redefinition, ANSI.SYS compatibility, etc.  It's completely untested,
so I'm putting in PS:<KERMIT-MS>MSXWNG.ASM, rather that in the regular
distribution, so as not to overwrite the standard version.  Could somebody
with a Wang PC please grab this new version, try it out (with either
regular 2.28 or else 2.28 jrd), and let me know if & how it works, and
whether the original MSXWNG.ASM can be replaced?  An .EXE or .BOO file would
be appreciated too.

------------------------------

Date: Sat, 25-JAN-1986 11:54 MST
From: <PETERSONB@BYUVAX>
Subject: Victor 9000 Kermit

As is usual with software, immediately after sending in the sources for the
Tektronix version of kermit for the victor, I found a subtle error.  I have
fixed it now and am forwarding a new copy of MSYV9TEK.ASM to you.


                                Bryan G. Peterson
                                PETERSONB@BYUVAX

[Ed. - The new file is in KER:MSYV9T.ASM.]

------------------------------

Date: Mon 27 Jan 86 09:49:41-EST
From: Christine M Gianone <[e-mail]>
Subject: Kermit on the Mac Plus

Had a chance to sample the Mac Plus last week.  It is just as simple as the
Macintosh but much faster in response.  Kermit 0.8(33) works just fine from
both the distribution disk (non-HFS) and the hard disk (HFS).  Files were
easily transmitted from the DEC-20 mainframe to the Macintosh and vise versa
using the Kermit server mode on the DEC-20.

------------------------------

Date: Fri, 24 Jan 86 10:15 EST
From: [e-mail]
Subject: Rice TSO and Mac Kermits

In response to the mention of Rice's Kermits in the last issue of Info-Kermit:

1) TSO Kermit - We are currently running their latest TSO version and
   find it quite capable of binary and text file transfers in both
   interactive and server mode.  Although the installation is a bear, it can
   be done.  It does NOT need the proprietary support package for
   installation and use.  The only reason for these proprietary utilities is
   for recompiling the source.  Although local source modifications to the
   source would be nice, they are not necessary.  The necessary local
   modifications (translate table and local command names) may be made to
   two assembly language routines which have nothing to do with the
   proprietary PL/I software.  Any other needed modifications can be fudged
   in the program call.

2) MacKermit - We had used Rice's MacKermit until the distribution of 0.8
   C-Kermit and found the two leagues apart.  The Rice version was workable,
   but the C version is has so much more in the way being user friendly and
   ease of transfer for either text or application files - it also includes
   better documentation.  Left with the choice, we have chosen C-Kermit
   V0.8(52).

I hope this is of some help to TSO and Mac users with similiar questions.

mark

------------------------------

Date: 23-JAN-1986 16:50:25
From: Kevin Ashley ([e-mail])
Subject: Bug in Wildcard Get in C-Kermit 4C(057)

There is a bug in wildcard get when using C-Kermit under Xenix on a PC/AT (and
possibly in other implementations) causing it to fail after one file. In
CKCPRO, reof() is called to close a file on receipt of an EOF packet. Its
return value is tested to see if this was done successfully. However reof (in
file CKCFNS.C) does not return a value, so what is tested is undefined. When we
compiled C-Kermit with the debug flag on it seemed to work anyway - presumably
the right garbage was being left in the right register - compiling with debug
off, however, caused different garbage to be tested. The cure is relatively
simple, as reof() calls clsof() which does return the value that reof's caller
wants to see. The changes are:

In reof in CKFNS.C:
     After opening {, add
            int  x;

     Change line containing call to clsof to read
            x = clsof(....

     Before the final } add the line

            return(x);

This percolates the return value through corectly.

      Kevin Ashley,
      ULCC Network and Comms Support

      [e-mail], mark f.a.o. Kevin Ashley

[Ed. - Thanks; this change will be in the next release.]

------------------------------

Date: Sat, 25 Jan 86 20:30:41 est
From: Steve Archer  <[e-mail]>
Subject: HP-3000 Connect Mode

I'll take credit for adding the connect mode of the HP3000 Kermit.  Not
knowing hardly anything of SPL, I admit the connect mode is barely usable.
But I do not know any better way to do it.  I would encourage a SPL guru to
step forward and improve the connect mode for the betterment of HP3000
Kermit users. The source does document my assessment of the connect as it is
presently.

steve archer

------------------------------

Date: Mon, 27 Jan 86 11:18:24 pst
From: Sys manager <[e-mail]>
Subject: HP-3000 Kermit

Try disabling xon/xoff on your HP3000. We had problems with HP3000 sending an
xoff right after parsing the password.

Mike

------------------------------

From: tektronix!mako.TEK![e-mail]
Date: Fri, 24 Jan 86 10:02:10 PST
Subject: Tandem Nomencalature Clarification

(I worked for Tandem in '81.)  Guardian is Tandem's only supported OS, which
almost everyone uses.  TAL (Transaction Application Language) is a systems
language, similar to C and ALGOL.  Guardian, and all the other Tandem-supplied
programs, are written in TAL.  NonStop is a trademark of Tandem, used to
describe their computers, i.e. NonStop I, NonStop II, etc.

When you say you have a Kermit for the "NonStop" operating system, you probably
mean for "Tandem NonStop computers, under the Guardian OS".  Hope this helps.

------------------------------

Date: Mon 27 Jan 86 18:17:16-EST
From: Frank da Cruz <[e-mail]>
Subject: FC Tape Format?

Anybody ever heard of FC tape format?  I have a new version of HP-1000
Kermit (the original Fortran version with bug fixes) on an "FC-format" tape
that I can't read -- it's full of ASCII characters mixed with binary data.
Does anyone know of a utility to read it on Unix or a DEC-20?

------------------------------

End of Info-Kermit Digest
*************************
-------
30-Jan-86 12:03:04-EST,9628;000000000001
Mail-From: SY.CHRISTINE created at 30-Jan-86 12:01:49
Date: Thu 30 Jan 86 12:01:48-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V4 #8
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 30 Jan 1986       Volume 4 : Number  8

Today's Topics:
                             7171 warning
                            Strange cursor
                            Hercules Card
      Problem with Issuing Remote Host Commands from VMS Kermit
                    Kermits on the way to you.....
                  Modem7/Kermit for Vector V3-5030?
                 KERMIT for CPM3.0 Osborne Executive
                       Kermit/Osborne Executive
                          Alpha-Micro Kermit
                            Proper credit

----------------------------------------------------------------------

Date: 28 JAN 86 17:19-EST
From: [e-mail]
Subject: 7171 warning

Just a note on using MSKERMIT 2.28 and CMS Kermit thru a 7171 - I thought
I was going nuts!  Everybody's been saying how great it is, etc, etc...
Well, the first thing I HAD to do was setup the ports of the 7171 to what
I thought was 8 data, no parity, 1 stop bit.  Then setup MSKermit in the
same manner (no parity) - all looked fine, till I tried to transfer files,
then NOTHING!!!  All it did was hang - no communication at all.  Then I tried
it on Port 0 (this is always even parity) and everything was fine. To make
a short story long, I set parity SPACE in MSKermit and all was ok from there.
In fact its great! I've defined all the function keys, etc. to my liking - by
the way, did you know that putting comments in a TAKE file effects the define
key area (as in eats ups space!), I found out the hard way (Again).
Hope I can save someone some time with this note....
     [e-mail]

[Ed. - We have also found that 7171's do not like bursts of characters
longer than about 60.  Kermit programs should have their packet lengths
set accordingly.]

------------------------------

Date: 29 Jan 1986 10:58-EST
From: [e-mail]
Subject: Strange cursor

I am running MS-Kermit 2.28 on an IBM-PC with a Hercules card.  A
number times I have noticed that my underline cursor has changed to a
minus sign.  This behavior is very annoying.  Does anyone know what
might be causeing this?  I should point out that exiting and running
most programs will not fix the problem.  The only fix I know is running
MODE or rebooting.  Also, using the commands to change to a block
cursor and back will change to a block cursor, but return to the minus
instead of the underline.  The switchover always occurs when connected,
but I have not discovered what will cause the change.

-Israel ([e-mail])

[Ed. - See next message.]

------------------------------

Date: 29 JAN 86 10:09-MST
From: JRD@USU
Subject: Hercules Card

Hercules graphic adaptor and minus sign cursor. That appears very much like
the bug in DOS itself whereby at startup time the cursor characteristics are
copied from ROM to RAM, but not consistently. The RAM copy can be bad for
a while; if a program picks up the characteristics it may see a minus sign
rather than an underline. There was an article (note really) on exactly this
problem published in PC Tech Journal about one or two months ago. The root
of the problem is the scan line numbers of the cursor are smaller on color
boards (&compats) than on the monochrome adapter. Thus, color board cursor
line numbers end up as a minus sign on the monochrome adapter. How one boots
will determine the presence or absence of the minus sign cursor. A patch is
in the PC Tech note.
        Regards,
        Joe D.

------------------------------

Date: Tue, 28 Jan 86 20:48:37 est
From: biomed![e-mail] (Simon Rosenthal)
Subject: Problem with Issuing Remote Host Commands from VMS Kermit

I am having some trouble with VMS Kermit (3.1.066), running under VMS
3.7. When using it in local mode to talk to C-Kermit running in server
mode on a Masscomp system - (basically SYS V Unix), VMS Kermit insists
on uppercasing the text of any command sent to the server using REMOTE
HOST, according to the debugging log.  Needless to say, the Unix end
doesn't like this at all ...  Is there a Kermit-32 command I'm missing
which will force VMS Kermit to send out exactly what I type, or is this
a misfeature I'll have to live with?

Simon Rosenthal <[e-mail]>

[Ed. - I'm pretty sure this is a feature you have to live with.  I'll
pass your message on to the Stevens folks.]

------------------------------

Date: 28-JAN-1986 10:07:47
From: [e-mail]
Subject: Kermits on the way to you.....

A tape is on its way to you today with a good crop of new Kermits on it.
There's a letter with the tape, but briefly here's what to expect:

   Version 1.30 of Kermit for Acorn BBC micro
   Version 2.1 of Kermit for GEC 4000 series
   New Kermit for Joyce-Loebl Magiscan 2 image processor. This is a UCSD
     p-System machine: the Kermit is based on UCT for Terak, and has had
     8 bit prefixing and some other things added that will be of interest
     to UCSD Kermit users in general
   Kermit for Honeywell MultiSystem Executive and clones under Concurrent
     CP/M-86
   Kermit for a U-Microcomputers U-MAN 1000 micro under CP/M-68k
   Updated version of Chris Kennington's high-portability C Kermit
   A number of new CP/M-80 Kermits, (CP4SYS, TYP and HEX files) for
          Acorn BBC micro with Z80 processor
          North Star Horizon using onboard serial ports rather than SIO board
          North Star Advantage
          Cromemco
          Apple II with Z80 Softcard and CPS card
          Superbrain using auxiliary port, and using main port
          Torch series
          Cifer 1886
          Research Machines RM380Z

Kermit for Amstrad series micros running CP/M-80 is on the way but hasn't
arrived in time to make this tape.

Full details will be in with the tape.

Have passed your message re CP/M to Bertil. Am having mailer trouble (again)
but will try hard to get his reply to you.

           Alan

[Ed. - We will announce these versions when they arrive.]

------------------------------

Date: 20 Jan 86 15:36:52 PST
From: [e-mail]
Subject: Modem7/Kermit for Vector V3-5030?

Does anyone have modem7 and/or kermit for the Vector V3-5030 (CP/M 2.2)
on the ferschlugginer 16-sector (hard) 5.25" floppy?  Please reply to

------------------------------

Date: Mon, 6 Jan 86 10:19:08 est
From: Hal Carter <[e-mail]>
Subject: KERMIT for CPM3.0 Osborne Executive?

 Is there a version of KERMIT that works on an Osborne Executive.
I've tried the generic CPM 3.0 version, but nothing goes out the
AUX port to my modem.  (I have a Prometheus ProModem, and Modem 740
works fine).

Thanks for any leads.

[e-mail]

[Ed. - See next message.]

------------------------------

Date:  Wed, 8 Jan 86 12:28 EST
From:  "Paul E. Woodie" <[e-mail]>
Subject:  Kermit/Osborne Executive

I recently noticed a request on this mailing list for a version of
kermit to run on the Osborne Executive.  I have an Executive and tried
unsuccessfully to get several different cpm3 'generic' versions to run.
I don't know if my failure was due to equipment bugs in my particular
system, operator error on my part, or what.  In any case I finally got a
'generic' version from simtel20 written in turbo pascal.  That also (of
course) did not run completely on my system.  However, I modified it to
directly address the SIO ports instead of using the built-in AUX port of
the 'generic' versions.  Now it runs just fine.

I would be happy to share it with anyone interested.  I haven't so far
because I thought that maybe I had a flaky piece of hardware and my
problems were unique.

--Paul Woodie (Woodie.CPE at dockmaster)

[Ed. - Hope you can submit this to an Osborne User's Group?]

------------------------------

Date:    Wed, 29 Jan 86 07:39 EST
From:  [e-mail]
Subject: Alpha-Micro Kermit

Is anyone running Kermit on an Alpha-Micro with AMOS
V1.3(123)?  Assembly was no problem, but it just refuses
to recognize the AMOS version as valid.  I would appreciate
any patches or comments on this frustrating problem.

mark johnson,
university of notre dame

------------------------------

Date: Wed, 29 Jan 86 07:25 EST
From: [e-mail]
Subject: Proper credit

For the record, I would like to remind Info-Kermit that the bug in
C-Kermit 4C(057) CKFNS.C regarding reof()'s forgetting to return a
value (as reported by Kevin Ashley ([e-mail].w) in the latest
Info-Kermit) was first reported several months ago by a colleague of
mine here at Clemson University, William Faulkner ([e-mail]).
Frank da Cruz had noted that Faulkner's suggested fix would be installed
in 4C(057).  Was this not done?

As an aside, I find it amusing that both Faulkner and Ashley used *exactly*
the same fix, derived independently of each other, I am sure.

                                        -- Larry Afrin

------------------------------

End of Info-Kermit Digest
*************************
-------
 6-Feb-86 12:03:53-EST,12350;000000000001
Mail-From: SY.CHRISTINE created at  6-Feb-86 12:03:00
Date: Thu 6 Feb 86 12:03:00-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V4 #9
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu,  6 Feb 1986       Volume 4 : Number 9

Today's Topics:
                       TSO and VMS Kermit fixes
                  List of commercial KERMIT products
         VMS C-Kermit fails to provide interactive subprocess
        7171 Entry for Macintosh (VT100 without highlighting)
                       Kermit over LAN gateways
                         MS-Kermit Suggestion
                       Olivetti Keyboard Layout
                       Kermit for Victor/Sirius
                         Re: Strange Cursors
                         Osborne Exec Kermit

----------------------------------------------------------------------

Date: Wed 5 Feb 86 18:56:38-EST
From: Frank da Cruz <[e-mail]>
Subject: TSO and VMS Kermit fixes

Received from Jim Noble, Planning Research Corp, McLean VA -- some fixes
for VMS Kermit and MVS/TSO Kermit.  In KER:VMSMIT.BWR and KER:TSOKERM.BWR,
respectively.  The TSO fix is allow assembly under IFOX00 (whatever that is).
The VMS changes are mostly bug fixes.

------------------------------

From [e-mail]  Sat Feb  1 09:44:01 1986 remote from angel
Date: Saturday, 1 February 1986, 09:42-EST
From: George Carrette <angel![e-mail]>

A new kermit is on the way, derived from LMI KERMIT: MACLISP KERMIT for
PDP-10 Maclisp. (Runs under the ITS and TOPS-20 operating systems).
More info to follow. -gjc (GJC-AT-LMI@MIT-MC)

------------------------------

Date: Sun 2 Feb 86 12:25:30-EST
From: [e-mail]
Subject: List of commercial KERMIT products

I submit the following list of commercially avaiable MS-DOS VT100/TK4010 (&
Macintosh) terminal emulation programs with KERMIT protocol.  Nearly all
support also XModem.  Not all available features of each product are listed,
and some listed options are $EXTRA.  Nearly all are written to run on PC/XT/AT
and compatibles, and some may run additionally specifically on PCjr, Zenith,
Wang, etc.  Some support internal modems.  One product may zoom/pan, another
may save/restore graphics screens, still another may autoswitch text/graphics
modes, etc.

For more info about any of these products, one should call the vendor(s)
directly, but I would welcome comments from people here at Columbia or
elsewhere who have actually used these or similar products.

- Farhad
Nuclear Science & Engineering
Columbia University, NYC
[e-mail]

Caveat-&-Disclaimer: This short list is based on preliminary data and is
submitted for informational purposes only.  It is extracted from recent data
published elsewhere and is by no means claimed to be complete or accurate.

TELEPHONE    LIST VENDOR                 PRODUCT     EMULATION(S)

[MS-DOS:]
608-273-6000 $295 Persoft                SmarTerm240 VT52/100/125/220/240, and
                                                     TK4010/4014
303-690-6279  250 Henson Systems         CRTXE       VT52/100, 20 others, and
                                                     (soon:) TK4010, ReGIS
212-777-6707  249 Coefficient Systems    VTerm/4010  VT100, TK4010
617-367-6846  195 Boston Software Works  LC-Term     VT100
212-777-6707  160 Coefficient Systems    VTerm III   VT100
615-376-4146  150 Scientific Endeavors   VTEK        VT52/100, TK4010,4014
604-732-7411  150 KEA Systems            ZSTEMpc     VT100, TK4010
617-576-2760  124 Mark of the Unicorn    PCIntercom  VT100
617-659-1571   85 Solution Systems       ZAP         VT52/100, TK4010
215-664-4914   70 Cheshire Cat Software  Zap         VT52/100

[Apple Macintosh:]
603--673-8151 $195 White Pine Software   Mac240      VT100/220, ReGIS

[Ed. - Kermit is appearing in more and more commercial communications programs,
and soon we'll have quite a few of them with sliding windows too -- Crosstalk
among them.  Most of these companies have agreed in writing to comply with the
conditions given in our "Policy on Commercial Use and Distribution of Kermit"
flyer (KER:AAXCOM.DOC), which means that purchasers of these products should be
getting the Kermit component "free".]

------------------------------

Date: 4 Feb 86 15:08:00 EST
From: "NUNN, JOHN C." <[e-mail]>
Subject: VMS C-Kermit fails to provide interactive subprocess

The VMS implementation of C-Kermit does not provide an interactive
subshell (subprocess for VMS) for the "!" command.  This problem can
be corrected by making the changes shown below.

[Ed. - Code omitted, added to KER:CKVKER.BWR.]

------------------------------

Date: Wed 5 Feb 86 08:24:29-EST
From: Frank da Cruz <[e-mail]>
Subject: 7171 Entry for Macintosh (VT100 without highlighting)

BY popular demand, here is the 7171 code to support Macintosh
Kermit's VT-102 emulator:

**************************************************************
* MODULE NAME = VT100                         *
**************************************************************
VT-100     TERM  GENI,ORIGIN=X'01',RCHRS=GENSRCHS,FLAGS=X'0C00'
VTCSS1     CSS   ESC,LBRACK,(CHARY),SEMI,(CHARX),H    * POSITION
VTCSS2     CSS   ESC,LBRACK,K        * ERASE EOL
VTCSS3     CSS   ,            *
VTCSS4     CSS   BEL            * TONE
VTCSS5     CSS   BS            * CURSOR LEFT
VTCSS6     CSS   ESC,LBRACK,C        * CURSOR RIGHT
VTCSS7     CSS   ESC,LBRACK,A        * CURSOR UP
VTCSS8     CSS   ESC,LBRACK,B        * CURSOR DOWN
VTCSS9     CSS   ESC,LBRACK,@1,LCQ    * SIGNAL INSERT MODE
VTCSS10     CSS   ESC,LBRACK,@0,LCQ    * SIGNAL END INSERT MODE
VTCSS11     CSS   ,            *
VTCSS12     CSS   ESC,LBRACK,H,ESC,LBRACK,J    * CLEAR
VTCSS13     EQU   *
     CSS '\=\<\[H\[J\[?1h\[?3;6;7l\[20l\[0q\[0m'
VTCSS14     CSS COLON            *
VTCSS15     CSS   ,            *
VTCSS16     CSS   ,            *
VTCSS17     CSS   ,            *
VTCSS18     CSS ESC,LBRACK,(CHARFLD),LCM    *
VTCSS19     CSS   ,            *
*
**************************************************************
* Macintosh PC running Kermit (VT100 w/out highlighting         *
**************************************************************
MAC     TERM  GENI,ORIGIN=X'01',RCHRS=GENSRCHS
     CSS   EQU=VTCSS1
     CSS   EQU=VTCSS2
     CSS   EQU=VTCSS3
     CSS   EQU=VTCSS4
     CSS   EQU=VTCSS5
     CSS   EQU=VTCSS6
     CSS   EQU=VTCSS7
     CSS   EQU=VTCSS8
     CSS   EQU=VTCSS9
     CSS   EQU=VTCSS10
     CSS   EQU=VTCSS11
     CSS   EQU=VTCSS12
     CSS   EQU=VTCSS13
     CSS   EQU=VTCSS14
     CSS   EQU=VTCSS15
     CSS   EQU=VTCSS16
     CSS   EQU=VTCSS17
     CSS   EQU=VTCSS18
     CSS   EQU=VTCSS19
*

------------------------------

Date:         Mon, 3 Feb 1986 15:51 EDT
From:         Bill Seeley <WAS@UMAB>
Subject:      Kermit over LAN gateways

I think the fundamental problem with using Kermit across a LAN gateway
will not be with Kermit per se.  The basic problem seems to be that
most gateway systems require the user to run an application in his/her
workstation in order to communicate across the LAN to the gateway server.
Once a port is allocated on the gateway server, there must be some way
to re-direct Kermit's I/O from COMn: to the communication channel provided
by the server.  I believe Bridge Communications has a product for 3COM
Ethernets in beta test which claims to support "COM1 re-direction."
Ungermann-Bass' Net/One also claims to support a similar function using
a variant of MS-NETWORKS.  I'm curious to know if anyone else out there
has experience using Kermit with these or similar products.  If you would
publish this in your Info-Kermit newsletter I'd be most grateful.

Thanks,
Bill

------------------------------

Date: Sun, 2 Feb 86 23:14:30 PST
From: [e-mail]
Subject: MS-Kermit Suggestion

It would be nice if MS-Kermit would use an DOS environment variable to locate
it's profile (MSKERMIT.INI), so that Kermit can be invoked from various
sub-directories of a hard disk with only *one* copy of the profile stored on
the hard disk.  Alternately, MS-Kermit could employ the search PATH used by DOS
for it's command files.

An example of how the former scheme would work is:

A>SET MSKERMIT=C:\COMM\KERMIT

The above should make MS-Kermit use C:\COMM\KERMIT as its profile if
C:\COMM\KERMIT is a file, but use C:\COMM\KERMIT\MSKERMIT.INI if C:\COMM\KERMIT
is a sub-directory.  This shceme would allow the user to specify not only a
sub-directory, but optionally also the exact name of the profile, all in one
DOS environment variable.

The specification of the scheme may sound complicative at first glance, but it
really is quite intuitive when it is in use.

...Sam Lam

[From jrd -- Path searches really ought to be done I suppose; it just takes
some time to write the code to a) test if DOS found a file on its own and b)
chugging down the PATH= string trying the selections. I sort of put this into
category B, do when time is available, together with things like redefinable
keys at the Kermit prompt level. A directly usable Kermit seems more important
than waiting for the endless series of 'frills' to be added.]

------------------------------

Date: Wed, 5 Feb 86  11:00 EST
From: E. Thaler, Swiss Federal Institute of Technology ( ETH Zuerich )
Subject: Olivetti Keyboard Layout

Hello

We got and installed your Kermit Version 2.27 for Olivetti M24 with
VT 100 emulation. It works fine.

We are using a keyboard of swiss-german type with a different keyboard
layout. To display the appropriate characters, we need to adapt
the keyboard-driver program (KBDVT100).
Is it possible to get the source of the keyboard-driver?

[Ed. - Sorry, this version came via slow boat from Australia.
It would take longer to get this program then it would be to
wait for the next version of MS-DOS Kermit (2.29).]

------------------------------

Date: 29-JAN-1986 13:19:14
From: [e-mail]
Subject: Kermit for Victor/Sirius

It may not be a good idea to remove SIR files just yet. Over here there
have been a lot of changes in Sirius/Victor dealerships, resulting in long
periods when no-one seemed to want to sell anything for them. Result is that
MS-DOS 2 is not, I think, that common - and MS-Kermit won't support MS-DOS 1.
I've put out a question in our UK info digest asking Sirius users for comments,
and I'll get back to you.
                  Alan

[Ed. - Don't worry, we won't delete the old stuff until we're sure it's safe.]

------------------------------

Date:         Fri, 31 Jan 1986 10:33 EST
From:         Nick Gimbrone <NJG@CORNELLA>
Subject:      Re: Strange Cursors

Can someone append the fix for the minus sign cursor seen on MSKermit for those
of us that do no have access to PC Tech J.?

------------------------------

From: dolqci!irsdcp![e-mail]
Date:  Wed Feb 5 17:26:01 EST 1986
Subject: Osborne Exec Kermit

I have managed to get Kermit running on the Exec via generic CP/M 3.0, and I
will try over this weekend to duplicate it, although it was done useing an
older version of Kermit.  I will forward the results to the list.

I am, however, VERY interested in the Turbo Kermit mentioned, and if the
sender of that note would contact me, I would like to get a copy.  I will
submit it to the local OUG (Capitol Osborne User's Group), and I am sure
CapOUG will forward it to FOG (First Osborne Group).

                                                         Jon

~ Addresses:  USnail: IRS, 1111 Constitution Ave. NW   Washington, DC 20224  ~
~             Atten: Jon Albers, Room 6335 D:C:P                             ~
~          Office Number Down Under: [phone]   (FTS)566-5240           ~
~      UUCP:  .....seismo!dolqci!irsdcp!albers (3rd floor Zilog: Down Under) ~
~      ARPA:  [e-mail]                                          ~

[Ed. - If you do manage to track it down and submit it to the User Group,
please let us know so we can add it to the list of diskette sources.]

------------------------------

End of Info-Kermit Digest
*************************
-------
11-Feb-86 14:16:12-EST,13745;000000000001
Mail-From: SY.CHRISTINE created at 11-Feb-86 14:13:35
Date: Tue 11 Feb 86 14:13:35-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V4 #10
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 11 Feb 1986       Volume 4 : Number 10

Today's Topics:
                         MS-Kermit Suggestion
                            MSKERMIT-JRD/2
              Mail Using Kermit; Protocol Clarifacations (2 msgs)
                            TELENET KERMIT
                    Tapes, GEACs, Victors, etc....
                       PROCOMM Freeware Package
                Undocumented Microsoft LINK Option: /E
                   Dashed Cursor Problem on IBM PC
                      THE FROG for 64-bit CDC's?
                           MS-DOS kermits?

----------------------------------------------------------------------

Date: Thu, 6 Feb 86 10:20:28 PST
From: prandt![e-mail] (David E. Tweten)
Subject: Re:  MS-Kermit Suggestion

From: [e-mail]

    It would be nice if MS-Kermit would use an DOS environment variable to
    locate it's profile (MSKERMIT.INI), so that Kermit can be invoked from
    various sub-directories of a hard disk with only *one* copy of the
    profile stored on the hard disk.  Alternately, MS-Kermit could employ
    the search PATH used by DOS for it's command files.

My copy of MS-Kermit version 2.28 (with some local mods which don't affect
this behavior) already does that.  I ordinarily keep both Kermit and its
initialization file in a directory which is on the MS-DOS PATH.  To confirm
that it works more generally than that, I just moved Kermit itself, to yet
another directory on the PATH, and that worked too.  From a third directory,
I invoked Kermit, which MS-DOS found in one directory on the path, and Kermit
read MSKERMIT.INI from yet another directory on the PATH.

    [From jrd -- Path searches really ought to be done I suppose; it just
    takes some time to write the code to a) test if DOS found a file on its
    own and b) chugging down the PATH= string trying the selections. I sort
    of put this into category B, do when time is available, together with
    things like redefinable keys at the Kermit prompt level. A directly
    usable Kermit seems more important than waiting for the endless series
    of 'frills' to be added.]

In my opinion, for those of us who have hard disks (more and more, lately),
searching the PATH for MSKERMIT.INI is not a frill.  It is basic function.
If the (soon to be) 2.29 version of MS-Kermit doesn't do this, I have no
intention of using it until it's modified.

[From JRD: MSKERMIT.INI is sought with paths after all.  The procedures have
not been changed by me from the original Columbia 2.28 release for this item
nor for Take file searchs.  Kermit does find MSKERMIT.INI if it is on the
environment PATH= list.  The RUN command and its Server counterpart REMOTE
HOST command work similarly.]

------------------------------

Date: Thu, 06 Feb 86 17:00:00 EST
From: Edgar B. Butt <[e-mail]>
Subject: MSKERMIT-JRD/2

I FTP'd MSKERMIT-JRD/2 from CU20b on 2/6/86.  Although I haven't had a
chance to test it extensively, it seems to work fine on my Zenith 151.
There are two minor problems which I don't see in the BWR file that are not
hard to solve.

First, when I type SEND with no file specified, MSKERMIT asks for LOCAL
DESTINATION FILE.  I now know that LOCAL is correct and DESTINATION is
wrong.  The REMOTE SOURCE FILE is equally confusing.  Different messages
from those used for GET should be used.

Second, when MSKERMIT is sending a file with a non-ascii character (8-th bit
set) over a 7-bit data path with no 8-bit quoting, it issues a warning and
then proceeds to send the data in a packet with a parity error causing the
transfer to come to an eventual halt.  Below is code to issue the warning,
strip the 8-th bit and continue the transfer.

Regards,
Edgar Butt ([e-mail])

[Ed. - The changes you sent will be in the next version of MS-DOS Kermit
(2.29).  Thanks!]

------------------------------

Date: Wed 5 Feb 86 15:05:40-PST
From: Bob Larson <BLARSON@usc-ecld>
Subject: Mail Using Kermit; Protocol Clarifacations

I have written a mail transport system from our Primes to our Tops-20
systems (and visa-versa) using the kermit protocol for the file transfer.
It uses the existing tops-20 kermit and a special purpose kermit subset I
wrote for this use on the prime.  (I could send this to you, but it does not
pretend to be a general purpouse kermit.)

What is the proper response to a Send-init ("S") packet (acknolaged)
followed by a Break-Trasmission ("B") packet?  Should the break-transmission
packet be acknolaged (as tops-20 kermit does) or should an error packet be
sent?

I think a couple of clarifications could be made to section 6.2 of the
protocol manual (fifth edition, which I think is current):

A sentence to the effect: "The 8th (parity) bit should be taken into account
on the checksum if and only if an 8-bit data channel is known to exist."
would probably be appropriate here, even if though it is stated elsewhere.

An alternate checksum calculation for languages/machines that do not allow
bitwise logical operations but do have integer division (/) and modulus (%)
is:

    check = char ((s + ((s / 64) % 4)) % 64)

(This results in identical checksums as the other calculation.)

Bob Larson
Arpa: [e-mail]
Uucp: ihnp4!sdcrdcf!oberon!blarson

------------------------------

Date: Fri 7 Feb 86 09:07:17-EST
From: Frank da Cruz <[e-mail]>
Subject: Re: Mail using kermit; Protocol clarifacations

An S-B sequence is perfectly valid -- it's the "null transaction".  Depending
on the implementation, it could happen if none of the specified files was
read-accessible.  The B packet should be acknowledged, although the sender
of the B packet should not be overly stringent in waiting for the ACK, because
there's always the situation in which the receiver gets the B packet, ACKs it,
and then exits, but meanwhile the ACK is lost.  (Although the S-B sequence
is valid, it might be a little kinder to the user to send an Error packet
when no files can be sent...)

All the protocol issues you raise are (I hope) clarified in the Kermit book.

- Frank

------------------------------

Date: Fri 7 Feb 86 10:42:20-EST
From: [e-mail]
Subject: Re: TELENET KERMIT

My request for advice on tips for network transfer should have been for
TYMNET, and not TELENET.

I fiddle with parameters, REC timeout and PARity but can only achieve about
a 15% success rate with no pattern for successes or failures.  KERMIT will
usually hang on initial packet, or time out with repeated sends <RET's>.

Any help appreciated.

 joe

[Ed. - Anybody who can help, please reply to Info-Kermit so that others with
similar problems can see the solution.]

------------------------------

Date: 6-FEB-1986 15:23:13
From: [e-mail]
Subject: Tapes, GEACs, Victors, etc....

 I asked around about GEAC - it's a Canadian machine used for specialised
Library work. No-one's heard of a Kermit for it.  For your info, address is
GEAC Computer Corp, 350 Steel Case Road West, Markham, Ontario, Canada. OS
is totally unique but will shortly be UNIX-clones- there is a machine in New
York University library, I'm told. Here endeth the GEAC saga.
 On new Kermit front: both Manchester U. and Imperial College London are doing
new/inproved Kermits for Cybers running NOS (one in Pascal, one in Compass).
Will pass them on when they get finished.
  Your next message will contain a .BOO file for MS-DOS Kermit for the
Victor 9000/Sirius 1.

      Alan

[Ed. - Thanks.  The .BOO file is in KER:MSVV90.BOO.]

------------------------------

From: <decwrl!decvax!mcnc!rti-sel!ethos![e-mail]>
Date: Sat, 8 Feb 86 14:54:49 est
Subject: PROCOMM Freeware Package

    I just picked up a communications package from one of the local BBSs
here in Research Triangle Park, NC.  It's called PROCOMM, a freeware package by
PIL software systems.  This program is probably the best one I've seen at *any*
price for MS-DOS.  It's fully as good as MEX on CP/M.  It supports both xmodem,
and kermit protocals, terminal emulation, keyboard macros, and scripts.  Its
rather large, so I won't post it on the net unless there is enough interest.  I
will however put it on my BBS.  The reason I mentioned it is that it supports a
env variable called PROCOMM which contains the path for the parameter files,
it searches this if it doesn't find them on the current directory.  Highly
recommended.

Jay Denebeim                "One world, one egg, one basket."
  {seismo,decvax,ihnp4}!mcnc!rti-sel!ethos!jay
  Deep Thought, ZNode #42 300/1200/2400 919-471-6436

------------------------------

From: Ya'[e-mail]
Subject: Undocumented Microsoft LINK Option: /E
Date: Mon 10 Feb 1986 13:44-MST

There exists an undocumented(?) switch to Microsoft LINK.EXE ver 3.XX,
which will cause an automatic compaction during binding.  This process
will eliminate storage for uninitialized arrays from the .EXE file
produced by the linker, reducing the .EXE file size by up to 300
percent!  To use this feature, specify the /E option to the command
line, eg

        LINK myprog/E;

should work.  For example, PCKERMIT.EXE ver 2.27 was 80K when linked
normally but shrunk down to 33K when linked with the /E option...

[Ed. - The question is will any arbitrary DOS machine be able to execute
an .EXE file that was produced this way?]

------------------------------

Date: 7 FEB 86 10:51-MST
From: JRD@USU
Subject: Dashed Cursor Problem on IBM PC

In response to the minus sign as a cursor problem reported in recent Digests
the PC Tech Journal article discussing the problem is "The Dashed Cursor",
by Paul Pierce, PC Tech J., Dec. 1985, page 47. His code goes like this:
...................................
;
; Program FIXCURS.ASM by Paul Pierce, PC Tech Journal, Dec 1985, page 47.
;
code    segment public 'code'
        assume cs:code, ds:code, es:nothing
;
;       This program is set up to be made into a COM file
;
        org     100H
;
; First check for the monochrome adapter.
;
start:  int     11H             ; set ax = equipment flag
        and     al,30H          ; mask off all but video bits
        cmp     al,30H          ; test for monochrome adapter
        jne     exit            ; jump if not monochrome
;
; Now check for incorrect cursor mode returned from the Bios
;
        mov     ah,3            ; call bios to get cursor type
        int     10H             ;
        cmp     cx,0607H        ; check for invalid (color) type
        jne     exit            ; jump if not a bad value
;
; At this point we know that the monochrome adapter is in use and that
; the bios cursor mode is incorrect.
; Call the bios to set the cursor type correctly.
;
        mov     cx,080cH        ; use correct cursor type
        mov     ah,1            ; call bios to set cursor type
        int     10H

exit:   mov     ah,0            ; exit back to DOS
        int     21H

code    ends
        end     start
............................................
[Reproduced without anyone's permission.]
        Regards,
        Joe D.

------------------------------

Date: Mon, 10 Feb 86 14:18:00 pst
From: Joel West <[e-mail]>
Subject: THE FROG for 64-bit CDC's?

Is anyone aware of a version of kermit for one of the following
two machines (I'm told the software would be similar):
    * Cyber 205 running VSOS
    * Cyber 170 running NOS/VE
The existing CDC kermit for NOS, NOS/BE likely won't work for several
reasons:
    * different, yet another semi-compatible CDC OS
    * 60- (old) vs. 64-bit (new) machine word size
    * 6- (old) vs. 8-bit (new) characters
    * CDC character set vs. ASCII

One last hope is that every 205 has a 170 as a front end, so if the
one I'm going to use has NOS, then I can use the existing kermit.
Otherwise, it sounds like I'll have to do a port of C-Kermit or the
mini-kermit in the protocol manual...

    Joel West    CACI, Inc. - Federal
    [e-mail]
    {decvax,ucbvax,ihnp4}!sdcsvax!noscvax!westjw

[Ed. - See message above from Alan Phillips.]

------------------------------

From: hplabs!seismo!mcvax!wcwvax![e-mail]
Date: Sun 9 Feb 1986 12:51:05 GMT
Subject: MS-DOS kermits?

There seems to be a vast number (spawn?)  of Kermits available for different
operating systems and machines; in particular, several different versions
for MS-DOS have been mentioned in this digest.  Can someone publish a list
of all the variants that are available currently in the public domain?

A friend of mine is looking for an MS-DOS kermit: is the source code of such
available from anyone in the U.K. (on tape, perhaps)?

[Ed. - Alan Phillips (see message from him above) at Lancaster University
distributes Kermit on magnetic tape & other media in the U.K. as time permits
him:  his postal address and phone number are:

    Alan Phillips
    Communications Group
    Department of Computing
    Computer Building
    Lancaster University
    Lancaster LA1 4YW, ENGLAND
    Phone [phone] x 4881
]

------------------------------

End of Info-Kermit Digest
*************************
-------
13-Feb-86 17:04:33-EST,11120;000000000001
Mail-From: SY.CHRISTINE created at 13-Feb-86 17:03:50
Date: Thu 13 Feb 86 17:03:50-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V4 #11
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 13 Feb 1986       Volume 4 : Number 11

Today's Topics:
                MS-DOS Kermit 2.29 Not Forgotten
                  Re: MS-Kermit path suggestion
                     Problems with MSKERMIT?
                        Okstate Downtime
                            C-Kermit
                   THE FROG for 64-bit CDC's?

----------------------------------------------------------------------

Date: Wed 12 Feb 86 09:51:36-EST
From: Frank da Cruz <[e-mail]>
Subject: MS-DOS Kermit 2.29 Not Forgotten

In case you've been wondering what ever happened to MS-DOS Kermit 2.29,
or missed the earlier announcements of 2.28 jrd, 2.28 jrd/2, etc, here's
a brief status report.

Joe Doupnik at Utah State University (connected to us by BITNET), has been
putting an incredible amount of work into the forthcoming release (considering
that he, like all of us, has a "real job" to do as well).  He now has a
remarkably complete VT102 emulator built in to the program, without having
sacrificed the Heath-19 emulator.  In fact, since VT52, H19, VT100, and VT102
are all so closedly related, he's got them all in there.  Several test versions
of this have gone back & forth (well, mostly forth), and the last remaining
nits are being picked, with the terminal emulation as well as fine points
relating to operation under TopView, MS Windows, PC Network, with EGA board,
etc.  It seems that the fine points are what take the time (the old 80/20
rule) and raise the most hackles.

Once the nits are quelled (parents of young children will understand this
allusion), the final job will be to get the program working again on the
non-IBM MS-DOS systems -- Rainbow, etc.  I think the best idea is for us to
provide .EXE and .BOO files for those systems we can test (IBM family,
Rainbow, HP-150), and leave the others alone (at 2.27 or 2.28 level) until
somebody sends us new, tested ones.  So if you have any of the other MS-DOS
systems Kermit claims to support -- NEC APC & APC3, Victor/Sirius, HP110,
Wang, Apricot, Grid, Heath/Zenith, Sanyo, TI Professional, etc. -- please
be prepared to grab the source or object files when they become available,
build and test the new release, and send us a .BOO and/or .EXE file by
electronic mail (or postal mail on IBM PC format diskette), or put them
somewhere where we can get them with FTP.

And I might as well make my usual pitch about diskettes -- when you have a
new version of Kermit working on your system, PLEASE send it on diskette
to an appropriate user group, "public domain" diskette service, or other
entity capable of reproducing and selling it by mail order at low cost
(what's low?  I'd say under $10 or $20 for a diskette) for the benefit of
all the PC/micro users in the world who don't have tape drives, network
access, or other "traditional" ways to get Kermit on their machines.

------------------------------

Date: Tue 11 Feb 86 10:59:22-PST
From: Ted Shapin <[e-mail]>
Subject: Re: MS-Kermit path suggestion

I don't think KERMIT is the proper place to make up for missing DOS functions.
I use the public domain DPATH30.COM which lets me search the path for files
to open so I only need one copy of MSKERMIT.INI.  There are other programs
that do the same thing, e.g. IBM`s File Facility in their personally developed
software line.

------------------------------

Date: 0  0 00:00:00 EST
From: "Steven Kaberline [phone]" <kaberline@ford-vax>
Subject: Problems with MSKERMIT?

I just recently built MS-KERMIT for my Victor.  It works
great, with the exception that the status line at the bottom
of the screen is trashed during a "SEND" or "RECEIVE"
command??  The status line is correct during the "CONNECT"
mode.  I've tried both the 2.28 and 2.28(jrd) versions,
they both seem to have the same problem.  The IBM-PC version
I'm also using does not do this, so it appears to be Victor
specific?

I also downloaded (from CU20B) the MSVV90.BOO file described
in the latest Kermit Digest.  When converted to the .EXE file
and run, it demonstrates the same symptoms.

This is not a serious problem, but it is annoying.  Does
anyone have any suggestions??

Thanks.

            Steven Kaberline
            Kaberline@FORD-VAX

------------------------------

Date: 11 Feb 86 20:24:58 CST (Tue)
From: [e-mail]
Subject: Okstate Downtime

The Oklahoma State University Kermit Distribution service will not be available
from Saturday, February 15 until Monday, February 17 (if all goes well).  We
are in the process of changing from UNIX Version 7 to UNIX System V (actually
Perkin-Elmer's port of S5 called XELOS).  We anticipate some problems with
the Kermit Server portion of the Kermit service since the server code that we
use is based on C-Kermit 4.2 and the code that we added for path restriction
has never been tested on System V.  The real problem may be in the UUCP portion
of the service.  As I understand it System V is really picky about only talking
to systems that are in your L.sys (or Systems) file and I have not yet received
my System V source license (paperwork!) so I don't yet have the source to "fix"
this "problem" (actually it requires breaking a few features.... sigh..).

I will report back to this list when various parts of the service start working
again (hopefully within a week or so).

Mark Vasoll
Department of Computing and Information Sciences
Oklahoma State University

UUCP:  {cbosgd, ea, ihnp4, isucs1, mcvax, pesnta, uokvax}!okstate!vasoll
ARPA:  [e-mail]

------------------------------

Date: 11 Feb 86 18:38:26-MET (Tue)
From: Karl Kleine -- F Z I Karlsruhe <[e-mail]>
Subject: C-Kermit

  We invested some work in C-Kermit.  base is 4C (050).  though this is
not the very latest, we hope it still is relatively current.

first:  bugs found in porting it to pcs / cadmus.  these are 68010 based
Unix machines running MUNIX, an adoption of System III by PCS.  PCS is a
Munich based German manufacturer of micros, so you know what the M stands for.
its american branch is CADMUS (Boston).  there were no real problems !!!
congratulations to the quality of your code !!! except for some places where
the authors obviously lived on a vax: the old pointer/int problem in C.
arguments to libary routines / system calls were 0 terminated instead of
(char *)(0). this made a difference on our system.  these places were
corrected to use the proper NULL constant.

second: brevity.  we shortend some of the strings printed, particularly in
the connect message.  we also suppress printing script lines unless logging
is active for the following reason:  we regularly connect from a local machine
(pcs) thru a local net (ungemann/bass net/1) to a couple of other different
machines.  mechanism: take files with scripts making the connection and
initiation of logins.  as this often occurs with visitors present we do not
like to have it all echoed on the screen -- there are some malvolent hackers
around, i'm afraid.

third: for the same setup as explained above we added the feature to supply
an alternate startup file instead of .kermrc as last [and usually only]
command argument.  i just type  kermit U750  which connects me from my pcs
to a unix vax.  very handy when you have lots of different hosts you connect
to -- i even use it to go thru various (local and public) networks to an
arpa machine in la right from my desk.

forth: another feature we missed in 4c(050) was file inclusion as typed
from the local terminal.  not all of the remote hosts have a kermit (yet)
and there are some utilities which do not like files, but only terminal
input.  furthermore, you need something for a 'pushing bootstrap'when
you want to bring kermit source over to the other system!  so we added
`ESCAPE I' in connect mode. It asks for a filename {we didn't do anything
fancy here -- maybe we could reuse code from other parts we didn't look at
-- this part certainly has to be redone, particularly to make the thing
the same for all target systems of C-kermit} and passes the chars in the
file tothe other side.  newlines are converted to carriage returns
(as you TYPE it) and a little delay was added.  the latter feature
was a pragmatic implementation hack to give the remote side a little
pause for digestion of the line sent.

these changes were made by a student of mine ond some by me myself.
all the code is made available to the public as is your policy, and
for all legal purposes we herewith transfer rights to columbia university.

if you wonder: the FZI of the mail header is "Forschungszentrum Informatik",
a non-profit research institute for applied research in computer science.
we are associated with (but independent of) the Technical University of
Karlsruhe.  I'm a scientist / project leader in the software engineering dept.

the rest of the message is a summary of all the changes, and we would like
that you incorporate them in newer kermit versions. the list was prepared
by the student; maybe the english isn't perfect.  if you wish, we can also
send the files, but hope this mail is in essence sufficient.

Karl Kleine
    csnet:        kleine@Germany
    usenet/eunet:    mcvax!unido!uka!kleine


[From Frank -- Some of these changes are already in 4C(057).  Most of the
others should wind up, in some form, in a forthcoming release.]

------------------------------

Date: Wed, 12 Feb 86 12:08:33 cst
From: [e-mail] (Jim Knutson)
Subject: THE FROG for 64-bit CDC's?

I am no longer working with Cybers anymore so my support of Cyber Kermit
has become rather limited.  I would like to see support for it continue
on a "real" Cyber site (not this homegrown OS stuff).  Basically, the
support needed is finish server support and be willing to write tapes
for other CDC sites.  Perhaps a general cleanup of all the nasty
conditional code is in order also.  Anyone willing to take this on should
contact me to obtain all the materials I have.

It is interesting to see that other sites are writing Kermits to run
on CDC equipment.  I can understand writing in Pascal but writing one
in Compass makes me shudder.  I have had to support several Compass
programs in the past and it is a nightmare when trying to make mods.
I wish them all the luck in the world in that endeavor.

Jim Knutson
ARPA: [e-mail]
UUCP: {ihnp4,seismo,kpno,ctvax}!ut-sally!ut-ngp!knutson
Phone: [phone]

------------------------------

End of Info-Kermit Digest
*************************




-------
14-Feb-86 17:35:32-EST,7199;000000000001
Mail-From: SY.CHRISTINE created at 14-Feb-86 17:34:50
Date: Fri 14 Feb 86 17:34:50-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V4 #12
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 14 Feb 1986       Volume 4 : Number 12

Today's Topics:
                       Kermit Valentine Message
                   QK-KERMIT, a Turbo Pascal Kermit
                       Kermit for Flex 9 System
                       Two More New Kermit-80's
                More CP/M-80 Implementations of Kermit

                        HAPPY VALENTINE'S DAY

                             (  \   /  )
                            (    \ /    )
                             ( Kermit & )
                              (  You   )
                                (    )
                                  \/

----------------------------------------------------------------------

Date: Tue, 11 Feb 86 09:57 EST
From: Victor Lee <[e-mail]>
Subject: QK-KERMIT, a Turbo Pascal Kermit

I would like to submit our version of Turbo Pascal Kermit which runs on both
the MS-DOS and CP/M systems.  It is named QK-Kermit after our SHARE
installation name, QK (Queen's Kingston).

I made some attempt to get together with Jeff Duncan, but it was not very
successful.  The files we sent back and forth to one another kept getting
lost.  And I got somewhat confused as to which files went together. At
Queen's the developement of the MsDos Kermit features had to take priority
over any CP/M features.  Consequently this Turbo Pascal KERMIT is primarily
our own Kermit.

[Ed. - Jeff Duncan at Prime Computer has also been working on a Turbo Pascal
Kermit, but concentrating on CP/M.  His previous Turbo Pascal CP/M-80
Kermit remains available as KER:TURBO.*.]

The Turbo Pascal Kermit which we call QK-KERMIT has been widely used on
campus to tie in with Kermits on the VM/CMS, VAX systems, RT11 system and
micro to micro systems.  In addition to the features found in the Kermit-MS,
QK-KERMIT has added the following:

    1. VT100 emulation, with definable function keys.
    2. VT100/TEK4010 graphics terminal emulation.
       We are also currently developing  a TEK4105 version.
    3. APL character set for those that have an APL character ROM.
    4. Automatic Server mode for send and receive files.

Because this Kermit is easy to use and modify, it has been used by others
who have added there own particular modifications such as file encription,
data compression, and Greek terminal emulation.

There are about 3000 lines of code contained in several source Pascal files.

[Ed. - Thanks, Victor!  This program runs on the IBM PC,XT,AT; the Apple II,
and the Kaypro II.  A simple hex file (2-for-1 encoding of the binary .COM
file) is provided for the IBM PC family (with and without graphics).
Additional hex files for other combinations of PCs/terminals/graphics may
appear from time to time.  The files are in KER:QK*.* on CU20B.  The binary
.COM files are in KB:QK*.COM on CU20B.  Hexify/dehexify programs are in
KER:QKCOMH.PAS and KER:QKHEXC.PAS.  The source files are concatenated
together into KER:QKKER.PAS; KER:QKKER.DOC is the manual; there are various
auxilliary files for key definition, etc.  To run the program, you need to
have a key definition file on your current disk.]

------------------------------

Date: Thu, 13 Feb 86 08:17:02 n
From: <[e-mail]>
Organisation:   European Molecular Biology Laboratory
Postal-Address: Meyerhofstrasse 1, 6900 Heidelberg, W. Germany
Phone: [phone] [switchboard]
Subject: Kermit for Flex 9 System

I have just mailed the Flex Kermit source code to the address which
succeeded last! I hope that it arrives OK...

The program was written by D. J. Rowland, Brighton Polytechnic Computer
Centre, Watts Building, Lewes Road, Brighton, Sussex, UK.  Here are the
comments from the author, which seem to comprise the sum total of the
documentation:

"This program is a very basic kermit, the basic code is based on the Apple
version of Kermit and modified to run on the 6809 cpu.  I don't guarantee
its operation!  It's a bit crude but it does work!  It has be run with the
DEC VAX Kermit server and the DEC Pro Kermit server.

[Ed. - I assume this means it will only work with a Kermit server on the
remote end, but it shouldn't matter which server.]

"It will get a file, send a file, and close down the server.  It operates
with text files only and does not have 8 bit quoting.  There are no set and
show commands; to change the values modify the source!  There is a receive
data timer (for packet receive); this can be modified or deleted!  It's a
simple timing loop round the recieve-data subroutine."

regards
peter bendall

------------------------------

Date: 13-FEB-1986 16:49:18
From: [e-mail]
Subject: Two More New Kermit-80's

  Here's a couple more towards the Great 200 Mark. First off is the hex for
Kermit-80 for the Epson PX8 portable, sent in by Tony Addyman of Salford
University ([e-mail].E). Then comes the hex for a Research Machines
RM380Z with 5-1/4 inch single density discs, from Brian Robertson of Aberdeen
University ([e-mail]). There was a Kermit-80 hex file for this system
on the tape I sent you- belatedly it was found that this ran on systems with 8
inch single density discs only (the addresses of the UART changes between the
models). Can you install the one on the tape as CP4380.HEX, and have this new
one as CP438M.HEX, please (the "M" is apparently meaningful to Those Who Know
These Things). The SYS and TYP files for these are being done by Bertil now,
and will be on a PC disc to you before long.
                 Alan

[Ed. - Thanks, Alan!  The Epson hex file is in KER:CP4PX8.HEX, and the RM380Z
version in KER:CP438M.HEX, available, as usual, via anonymous FTP from CU20B
and on BITNET via KERMSRV at CUVMA.  The others will be installed when they
arrive.]

------------------------------

Date: 13 Jan 1986 1423-EST
From: Robert LaFara, Indianapolis 317-353-7750
Via: LCG.KERMIT@DEC-MARLBORO
Subject: More CP/M-80 Implementations of Kermit

The following files contain the machine dependent code for the
Access-Matrix, Action Computer Enterprise Discovery, and the Personal Micro
Computer MicroMate.  Although I have included source code for two others, I
no longer have the HEX files.

          CP4ACC.HEX
          CP4DISC.HEX
          CP4MM.HEX

I also uploaded the file: CP4SYS.DIF which contains (I hope) all the
differences between the CP4SYS.ASM on the distribution tape and my versions
of the file.  Included are comments about two errors that we have found in the
distributed code and I have included comments about EQU's to be used in
CP4TYP.ASM.

Sincerely, Bob LaFara

------------------------------

End of Info-Kermit Digest
*************************
-------
20-Feb-86 15:01:00-EST,9693;000000000001
Mail-From: SY.FDC created at 20-Feb-86 15:00:06
Date: Thu 20 Feb 86 15:00:06-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V4 #13
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 20 Mar 1986       Volume 4 : Number 13

Today's Topics:
                       MS-DOS Kermit 2.28/jrd5b
              CP/M Kermit Announcements from Last Digest
       MS-Kermit for Sirius/Victor on Available Disc in the UK
                        QK-Kermit Reports (and Answers)
       IBM PC - Tek 4010/4014 Emulation Beta Offer (w/ Kermit)
                     Mac Kermit vs Printer Port?
                     C-Kermit Bug on Pyramid 90x

----------------------------------------------------------------------

Date: 20 Feb 1986 1400-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: MS-DOS Kermit 2.28/jrd5b

If anybody wants to try out the current iteration of Joe Doupnik's MS-DOS
Kermit, for the IBM PC family (& clones) only, with VT52, H19, VT100, VT102
emulation built in, plus the ability to set foreground & background color
on color monitors.  No real documentation is available yet, but you can use
question mark at command level to find out what the new commands are.  A
couple commands have changed, so your MSKERMIT.INI file might need some
changes:

SET AUTOWRAP has become SET TERMINAL WRAP (but see below)
SET HEATH has become SET TERMINAL HEATH (or VT100, or VT102, etc)

The following bugs have been observed, so you don't need to report them:

1. SET TERMINAL WRAP command doesn't work (doesn't parse).
   The actual wrap mechanism seems to work OK, but can only be turned on
   and off by escape sequences.

2. There's no help for SET TERMINAL COLOR command (it takes two numbers
   in the range 0-7 as arguments, e.g. SET TERM COLOR 4,2).

3. Insert char in H19 or VT102 mode displays garbage instead of the inserted
   characters.

4. When you change colors, the background color is not set until after the
   screen is cleared the first time, but the foreground color is set.

This version is in PS:<KERMIT-MS>MSJRD5B.BOO (and .EXE for those who can
transfer 8-bit binary files), available, as usual via anonymous FTP from CU20B.
Please report any additional bugs to me, and I'll relay them to Joe.
Meanwhile, the program seems to be highly usable on the IBM PC family for most
applications, emulating any of the above terminals, so those of you who have
been hankering for VT10x emulation might be able to get by with this version
until the final release.  I'll also put the MSJRD5B.BOO file in KERMSRV on
CUVMA for BITNET access.

------------------------------

Date: 20 Feb 1986 0900-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: CP/M Kermit Announcements from Last Digest

Apologies to everyone who tried to get any of the five new CP/M Kermit .HEX
files announced in the last digest.  The first group, from Bob LaFara, was
there, but not as advertised; the filenames were changed somewhat from those
listed in Bob's message:

Machine          Bob's Name      Stored As:

Access-Matrix    CP4ACC.HEX      CP4ACC.HEX   (no change)
ACT Discovery    CP4DISC.HEX     CP4DIS.HEX   (shortened to 6.3)
PMM Micromate    CP4MM.HEX       CP4PMM.HEX   (to avoid confusion)

The source for these files has been added to the "beware" file, KER:CP4KER.BWR.

The other two,

Epson PX8 Portable               CP4PX8.HEX
Research Machines 380Z           CP438M.HEX

were lost somehow.  They have been restored (thanks to Alan Phillips for
sending them again).  Since we're without a real CP/M-80 Kermit maintainer,
all new CP/M systems will have to be supported this way, i.e. installation
of the .HEX files, without corresponding change to the source.  I hope to
inveigle someone into taking over CP/M-80 Kermit maintenance to the extent of
making one last pass through the source, so that the program can be organized
in such a way as to take advantage of the MODEM overlays.  Any volunteers?

------------------------------

Date: 14-FEB-1986 16:03:28
From: [e-mail]
Subject: MS-Kermit for Sirius/Victor on Available Disc in the UK

I can now supply MS-Kermit 2.28 on disc for the Sirius/Victor to anyone
wanting it in the UK. As before, e-mail address is [e-mail]1, phone
is 0524-65201 x 4881.
              Alan Phillips

[Ed. - Thanks!  Are there any other public spirited volunteers willing to
supply Kermit on native media for their machines, or to submit them to user
groups who can?]

------------------------------

Date: 18 FEB 86 09:58-PST
From: [e-mail]
Subject: QK-Kermit Report

Problems and bug report on the new QKERMIT in turbo pascal:

   VT100 terminal emulation has some problems
     Does not respond to DEC VMS set term/inquire.
     Has problems with the "TAB" character expansion.

   Something is wrong with the kermit handshaking (program waits until
   host times out then sends next packet) (each packet took about
   5 seconds to send).

            Don Jenkins  DON@UCRVMS (bitnet)
            University of California, Riverside
            Academic Computing Center

[Ed. - See below.]

------------------------------

Date: Wed 19 Feb 86 20:22:01-CST
From: Pete Galvin <[e-mail]>
Subject: QK-Kermit Report

I transfered the sources for QKKERMIT and compiled a version under MSDOS 3.1,
trying to build a VT100 version.  The compile went fine, and on startup
QKKERMIT claims I have VT100 emulation.  Unfortunately, when I dial in to the
DEC-20 on campus, almost no VT100-hood can be seen in the program: blanking the
screen and deleting characters works fine, but invoking any editor produces
"random" results.  Mostly, the screen blanks a lot during the display of text
or prompts, and the cursor stays near the top of the screen.

I'm hoping someone will point out the silly mistake I made an tell me how to
get a working VT100 emulator up.

                                        Thanks,
                                        Pete Galvin, U of Texas

------------------------------

Date: Wed, 19 Feb 86 14:06 EST
From: VIC@QUCDN
Subject: Reply to QK-Kermit Bugs

     I think my choice of names for the various protocols was bad. You
should not be using the Xon-Xoff with a Dec20. The Xon-Xoff refers only to
the funny IBM way of using Xon-Xoff. What I called "SERIES/1" protocol
should be used by most computers.  I am considering to change the name
of the protocol to something less confusing; but I am afraid that the
name may also have to be quite meaningless.

     It appears that my VT100 emulation is not complete enough for most
DEC users, although it is sufficient our needs. I will try add some of
the missing features as soon as possible.  Your feed back of the problems
will help me decide what features are most needed.

[Ed. - Victor has also sent in a hex file for the Kaypro II since the
last digest.  It's in KER:QKCPK2.HEX.  Remember, this is a straight
hexadecimal encoding of the .COM file, not an Intel format .HEX file to
be used with the CP/M LOAD command.]

------------------------------

Date: Tue 18 Feb 86 10:39:09-EST
From: Michael Fuchs <[e-mail]>
Subject: IBM PC - Tek 4010/4014 emulation beta offer (w/ Kermit)

Would anyone be interested in beta testing our latest version of a product
that does Tektronix 4010/4014 emulation (with EGA support) as well as VT102,
VT52, file transfer (Kermit, Xmodem, propietary protocols), 132 columns in
software (or optional hardware), old screen recall, programmable softkeys,
etc.?

If so, please contact (by voice only, please):

John Bailin
Coefficient Systems Corporation
212/777-6707

Please do not mail replies to this account (it's his project!)

Michael Fuchs
Coefficient Systems Corp.

------------------------------

Date: 16 Feb 1986 0825-EST
From: [e-mail]
Subject: Mac Kermit vs Printer Port?

There is a bug in MacKermit 0.8(33).  If the modem port is in use by a hard
disk (Tecmar for example), there is no way to use MacKermit as it generates
an error message indicating that the port is in use and then exits.  It does
not permit the user to use the printer port instead.  Do you have a patch to
get around this problem???

[Ed. - From one of the authors of Mac Kermit: "The ability to use the printer
port is not supported -- it was something we were going to put in but never got
around to.  Since I ordered a Tecmar I'll probably get around to fixing this.]

------------------------------

Date: Mon, 17 Feb 86 16:29:36 EST
From: munnari!moncskermit.oz![e-mail] (John Carey)
Subject: C-Kermit bug on Pyramid 90x

I have discovered a bug sending more than one file using C-Kermit 4c(056)
on a Pyramid 90X, e.g.

        kermit -s file1 file2 ...

The first file is sent ok - but the others are not.

Here is the fix to "ckcpro.w" - sfile() has a parameter which was not used:

<sseof>Y  { if (gnfile() > 0) {         /* Got ACK to EOF, get next file */
                if (sfile(xeof)) BEGIN ssdata;  /* <---- parameter added */

This may cause problems on other machines that a have different
stack aritecture from the VAX.

                                John Carey.
                                [e-mail]

------------------------------

End of Info-Kermit Digest
*************************
-------
28-Feb-86 10:32:51-EST,8094;000000000001
Mail-From: SY.CHRISTINE created at 28-Feb-86 10:31:21
Date: Fri 28 Feb 86 10:31:20-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V4 #14
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 28 Feb 1986       Volume 4 : Number 14

Departments:

  ANNOUNCEMENTS -
        Kermit for the HP2647
        New Kermit-11
        Victor 9000 Kermit Updates

  MISCELLANY -
        ProComm
        C-Kermit Bug for Pyramid 90x
        Uucpker and Kermsrv Are Back
        Bug in C-Kermit

----------------------------------------------------------------------

Date: 1986 Feb 27   19:31 EST
From: John F. Chandler <[e-mail]>
Subject: Kermit for the HP2647

There is now a Kermit available for the HP2647 "Rover" programmable graphics
terminal, with or without tape units, written in 8080 assembler.  It
supports data compression and interaction with servers.  The executable
module is in the form of a long ESCAPE sequence that drives the resident
loader.  After being loaded it can be invoked as needed by typing 'kermit'
in command mode.  This Kermit can probably be adapted to run on other HP264x
models.  Source and documentation are available through KERMSRV.

John F. Chandler
Harvard/Smithsonian Center for Astrophysics

[Ed. - The program, hex file, and documentation are in KER:HP264X.* on CU20B
(anonymous FTP) and HP2647X * on KERMSRV at CUVMA (BITNET).]

------------------------------

DATE: 21-FEB-1986
FROM: BRIAN@UOFT02
SUBJECT: NEW KERMIT-11

New Kermit-11 on dialup and bitnet from U of Toledo

 A new version (2.45) of Kermit-11 is available.  The  literal  list  of
changes  is  too long, but major things are: long packets, dial command,
set dial  commands  (for  adding  modems),  set  phone  number  command,
further  TSX+  mods,  new  install  and  user  doc.  Edit  history is in
K11CMD.MAC

 This  version  should  not  be  sent  to  Columbia  yet as it is highly
desirable  to  test  long  packet  support  against  a  different  Kermit
implementation.  Additionally,  there  are  a  couple of very soon to be
resolved issues regarding P/OS v3. I am also awaiting a task  image  for
IAS 3.2 update C.

Bitnet access:
from VM/CMS:    CP SMSG RSCS MSG UOFT02 KERMSRV DIR
                CP SMSG RSCS MSG UOFT02 KERMSRV SEND K11*.*
from VMS Jnet:  $ SEN/REM UOFT02 KERMSRV SEND K11*.*

dialup: [phone]
        Service class  VX785A
        User: KERMIT
        Password: KERMIT

[Ed. - Thanks!  We will announce Brian's new release when we
receive it at Columbia.]

------------------------------

Date:     Sat, 22-FEB-1986 15:32 MST
From:     <PETERSONB@BYUVAX>
Subject:  VICTOR 9000 KERMIT updates

I apologize to anyone who may be using the VICTOR 9000 Kermit for the bug
in the mode line during file transfers.  It was a severe oversight on my
part.  I am forwarding corrected versions of MSXV90.ASM, MSYV90.ASM, and
MSYV9T.ASM to Columbia U. to replace the ones with the bug.

[Ed. - The new files in KER:MS*V9*.* on CU20B and on BITNET
(without the KER:)]
In addition, since I was working on it anyway, I have cleaned up the
character set on the Tektronix emulation a little bit to make the lower-case
letters more readable.  By popular demand I have also added code in the
Heath emulation mode of both versions to swallow up any ANSI escape
sequences that may come along.  No action is taken when an ANSI sequence is
received, but there are apparently many devices (such as the IBM 7171
protocol converter) that send these sequences and they are very annoying.
Also, the receipt of the sequence ESC [ is supposed to activate the hold
screen mode on the VICTOR - not an entirely desirable characteristic if the
host is merely trying to tell the VICTOR to switch text characteristics.

I appreciate all who have called bugs in the VICTOR version to my attention.

                                        Bryan G. Peterson
                                        (BITNET PETERSONB@BYUVAX)
                                        Telephone:  [phone]

P.S. - I will be sending the corrected codes on VICTOR format disks to the
VICTOR PULSE public domain library in the next few days.  If anyone wishes
to contact them the address is:

                        Victor PULSE
                        c/o Brad Chase
                        P.O. Box 705
                        Exeter, NH  03833-0705

[Ed. - Thanks for fixing these bugs, for sending us the source,
and a SPECIAL thanks for submitting this version to a Users
Group. If you could also send us a .BOO file, it would be greatly
appreciated.]

------------------------------

Date: Tue, 25 Feb 86 09:06:12 CST
From: C346595@UMCVMB (Bruce Barkelew)
Subject: ProComm

PIL Software Systems
PO Box 1471
Columbia, MO 65201
[phone]

I am the co-author of the communications program ProComm.  I noticed
our program mentioned here, so I thought I would let you know some
more information.  ProComm is a user supported product.  We have just
released version 2.2 (02/21/86).  Version 2.2 has many improvements
and additions.  We now emulate 10 popular async terminals.  The VT-100
emulation has been greatly improved.  We support XMODEM, YMODEM, TELINK,
MODEM7 and KERMIT file transfer protocols.  Our KERMIT implementation
has been completely re-coded from the ground up, and now supports all
the latest features such as data compression, file attributes, and the
new Sliding Window (full duplex) extension.  Our script command language
has been expanded also.  ProComm runs under MS-DOS 2.0 or greater, and
requires 128k of RAM.  We have a 24 hour support BBS running at (314) 449-
9401.  The latest version is always available there.

I don't mean this to sound like a commercial, but I saw messages here
inquiring about us, so I thought I would supply the information.  I can
be reached at the above address or at C346595 at UMCVMB.

-Bruce Barkelew

[Ed. - We do not usually put commercial announcements in our
digest, but this may be a way for people to try windows kermit.]

------------------------------

Date: Thu, 27 Feb 86 09:02:10 EST
From: munnari!moncskermit.oz![e-mail] (John Carey)
Subject: C-Kermit bug for Pyramid 90x

Sorry my last article had a typo.
                if (sfile(xeof)) BEGIN ssdata;  /* <---- parameter added */

Should have been :-
                if (sfile(xflg)) BEGIN ssdata;  /* <---- parameter added */
                          ^^^^
Thanks to John F. Rovert (jrover@nswc-g) for pointing out my mistake

                                                John Carey.
                                                [e-mail]

[Ed. - Thanks for the correction.]

------------------------------

Date: Thu, 27 Feb 86 0:02:20 CST
From: Mark Vasoll <[e-mail]>
Subject: uucpker and kermsrv are back

Both the uucpker and kermsrv logins are back in working order on
okstate.

------------------------------

Date: 28 Feb 86
From: Frank da Cruz <[e-mail]>
Subject: Bug in C-Kermit

I just discovered a bug in C-Kermit that might explain some problems that
have been reported recently.  If you ever send it an ACK, but the ACK is
lost somehow, and then you time out and send it a NAK (as I believe the PC
will do if its timer is on) before C-Kermit times out, the two Kermits get
into a deadlock, in which Unix Kermit sends packet n and the PC sends a NAK
for packet n+1, up to the retry limit.  The cure, in the case of Unix
Kermit, is to add a test in the input() function.  If it receives a NAK for
packet (n+1)%64, then it should return('Y'), i.e. behave as though it got an
ACK for packet n.  - Frank

------------------------------

End of Info-Kermit Digest
*************************
-------
 5-Mar-86 16:28:02-EST,10108;000000000001
Mail-From: SY.CHRISTINE created at  5-Mar-86 16:26:29
Date: Wed 5 Mar 86 16:26:29-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V4 #15
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed,  5 Mar 1986       Volume 4 : Number 15

Departments:

  ANNOUNCEMENTS -
    Kermit for Gould/SEL 32/8750 with MPX 3.2A
    New os9 Kermit (68000 and 6809)

  C-KERMIT -
    Kermit for Ultrix-11?
    Pixel Support for C-Kermit
    C-Kermit and TACs

  MS-DOS KERMIT -
    Tektronix Emulator in QK-Kermit
    Re: Tektronix Emulator in QK-Kermit
    PCjr w/Tecmar memory vs 2.28/jrd Kermit-MS

  MISCELLANY -
    Minor Problem with VMS Kermit (BLISS/MACRO) V3.1.066:

----------------------------------------------------------------------

Date: Wed 5 Mar 86 09:50:14-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit for Gould/SEL 32/8750 with MPX 3.2A

Announcing SEL-Kermit Version 1.0 for the Gould/SEL Concept 32/8750 with MPX
3.2A, written in Fortran-77+ by Marlon Gordon and Dave Durand, Singer/Link
Houston.  According to the documentation, it works in both remote and local
mode, and can run as a Kermit server.  The file arrived on some crazy kind
of tape, which we read the best way we could.  It all seems to be intact.
The files are in KER:GM1*.* on CU20B, available as usual via anonymous FTP
on the Internet, and also via KERMSRV at CUVMA on BITNET.

------------------------------

Date: Fri 28 Feb 86 18:04:22-PST
From: Bob Larson <[e-mail]>
Subject: New os9 Kermit (68000 and 6809)

Since someone finally confirmed that I didn't break the 6809 support
when I added 68000 support to kermit, the new version should be made
standard.  (Thanks Mark Sunderlin, scsnet!sunder.)

The new version is on usc-eclb.arpa as ps:<blarson.os9>os9*.* .  The
files that have changed are second generation, so os9*.*.2 will get
you only the new files.

The only real changes for 6809 users are in the .hlp and .bwr files
and some code to make connect mode on a bit-banger port easier to
implement.  (A special device driver is needed, any volunteers?)

Bob Larson <[e-mail]>
Uucp: ihnp4!sdcrdcf!oberon!blarson

[Ed. - Thanks!  The new files are in KER:OS9*.* on CU20B, and in
OS* * on KERMSRV at CUVMA.]

------------------------------

Date:     Fri, 28 Feb 86  10:44 EST
From:     Mark Katsouros <[e-mail]>
Subject:  Kermit for Ultrix-11?

 I've had no luck in getting Kermit working on our Ultrix-11 system.  Tried
making several different versions, and fooled around with mixing up the flags,
but was unsuccessful in coming up with anything even close.  If you happen to
hear of a way to get what I have (ck*.*) made for Ultrix-11, please let me
know.  Also, I'd really appreciate it if you would let me know if you hear of
anyone else on the net using Ultrix-11.  (Perhaps they have some sort of Kermit
protocol.)  Thank you for your time,

Mark Katsouros
University of Maryland, College Park

[Ed. - Does anybody have any hints about making C-Kermit work in
Ultrix-11?  What is Ultrix-11, anyway?  A 2.9 derivative?  A version
7 derivative?  Venix in disguise?]

------------------------------

Date: Fri 28 Feb 86 11:15:39-EST
From: Chris Lent <[e-mail]>
Subject: Pixel Support for C-Kermit

    Just put C-kermit on a Pixel 1000 which is a 68000 based Berkley
Unix box.  Make bsd almost works but it seems the getppid() function
which is used to determine the parent process id of the shell running
C-kermit is missing from the run-time library.  So I made a
change to ckufio.c adding an #ifdef PIXEL and substituted a
kill(0,9) for kill(getppid(),1).
The unix diffs of the current version of ckufio.c and ckuker.mak follow:
$ diff ckufio.c ckufiopix.c
198a199,201
> #ifdef PIXEL
>     return(kill(0,9));
> #else
199a203
> #endif
$ diff ckuker.mak ckukerpix.mak
174a175,179
> #Pixel 1000 (Almost) Berkeley Unix 4.1 or 4.2 (and presumably also 4.3)
> #Pixel 1000 V2.1 (Has no getppid() function)
> pixel:
>     make wermit "CFLAGS= -DBSD4 -DDEBUG -DTLOG -DPIXEL"
>

------------------------------

Date:  2 Mar 1986 12:26:45 EST
Subject: C-Kermit and TACs
From: Glen Foster <[e-mail]>

Has anybody set up C-Kermit on a VAX running Unix (4.2bsd in this case)
to get it to perform the proper Telnet protocol negotiations with a
TAC so the TAC doesn't interfere with a file transfer?

I know what Telnet sequence to send, I'm just not familiar enough with
C-Kermit and Unix to know how to do it.  I'm sure it could be done
relatively easy with a Kermit script file, perhaps someone has done
something a little fancier with a shell script the "knows" whether the
remote is coming through a TAC or not and sets binary mode if it is.

The Tops-20 Kermit at ISI does this, surely C-Kermit and Unix must have
this capability!

Thanks in advance.

Glen Foster - [e-mail]

[Ed. - There is no code in C-Kermit to put TACs in binary mode, though there
is no reason why it couldn't be added.  For now, just use TAC commands like
@b i s and @b o s.]

------------------------------

Date: 26 Feb 86 06:50:00 PST
From: ALEX WOO <wu@ames-aero>
Subject: Tektronix Emulator in QK-Kermit

Has anyone got the tek4014 emulator in qk-kermit to work?  I don't have
a Zenith but a Hercules card so I tried to recompile the relevant
modules.  Here is a summary of my failed efforts.

1.  It was necessary to overlay the source.  I chose to overlay the local
and definewords procedures since they are not critical for terminal
emulation.

2.  There was a definite error in the DefineWorld(1,0,779,1023,0) call.
I changed it to either
            DefineWorld(1,0,0,779,1023)
or            DefineWorld(1,0,0,3120,4095)
depending on which tektronix driver I'm using on the mainframe.

After fixing these errors, I find that when the terminal goes into tektronix
mode the screen blanks out.  It recovers correctly but nothing is ever painted
to the screen.  It almosts looks as if the vectors are drawn on a RAM screen
(but I set that boolean to be false).  Any suggestions?

Alex.

P.S.  I was surprised that turbo-pascal could drive the serial ports at
19,200 baud.

------------------------------

Date:    Tue, 4 Mar 86 11:03 EST
From:    VIC@QUCDN
Subject: Re: Tektronix Emulator in QK-Kermit

    Since we don't have the Hercules board, I can only guess at what
your problems might be.  Here are some possibilities to consider:
  1. QK-KERMIT emulates a TEK4010 which is slightly different from a
     TEK4014 terminals.  You maybe sending TEK4014 sequences that are
     not interpetted the same on a TEK4010.
  2. Make sure that you are using the Hercules routines from the Turbo
     tool box.
  3. Do not change the  DefineWorld definition. Although it appears to
     be backwards it is fixed up with some other code. ( Two wrongs
     make it right?)
  4. Try leaving the RamScreen definition unchanged.  We changed it to
     false to reduce the amount of memory used.  I am not sure how this
     affects the Hercules routines so you may leave it alone.
  5. Are you running at 19.2 baud? I have never tested it out at that
     rate. May I suggest you run your test at a lower baud rate  to
     insure that your problem is not a baud rate problem.

------------------------------

FROM: EGRJN@TUCC
Date:     Tue, 04 Mar 86 08:52 EST
Subject: PCjr w/Tecmar memory vs 2.28/jrd Kermit-MS

I got version 2.28 of the IBM PC Kermit from KERMSRV and I discovered a
problem that few others may have found, and which I hope you can report to
the right folks.  I have a PCjr with TECMAR memory which brings my system
memory to 640K.  When I run KERMIT 2.28, the program bombs with a message
indicating "insufficient memory".  If I disable the TECMAR memory, the
program runs fine.  Version 2.27 runs fine in either case.  Something was
done to 2.28 which creates this incompat- ibility with my system.  Disabling
the extra memory is inconvenient because it prevents me from using RAM disks
or programs like Sidekick. Perhaps if they knew of it, the KERMIT wizards
could avoid this improvement in future versions.

[Ed. - Has anyone else experienced this problem?  If so, did it go away when
you tried jrd/2 or later?  Joe Doupnik found some problems with the dynamic
memory allocation and fixed them.]

------------------------------

Date: Fri 28 Feb 86 11:15:39-EST
From: Chris Lent <[e-mail]>
Subject: Minor Problem with VMS Kermit (BLISS/MACRO) V3.1.066:

   If you didn't recompile KERMIT under VAX/VMS 4.X from the MACRO (or BLISS
I assume) a version compiled under VAX/VMS 3.2 to 3.7 may stall in what
looks like a CTRL/S-CTRL/S (XOFF-XOFF) standoff when using DEC's VT220
terminals.  I assume the terminal sends a CTRL/S between the time you type
the escape character and the time you type the C to close a CONNECT session.
It might also be that PASSALL mode (rather than VMS 4.X PASTHRU) mode is
used and the terminal's incessant CTRL-S/CTRL-Q sequences eventually lock up
KERMIT.

   Recompiling under VAX/VMS 4.X seems to solve thsi problem.  Note that
this hangup problem did NOT occur on VT100's or IBM-PC's using KERMIT
to be terminals.

   To determine what version your kermit was linked under do a

$ ANALYZE/IMAGE SYS$SYSTEM:KERMIT.EXE

and look at the linker identification under the heading Image Identification
Information.  If the string starts with a 3 you probably should rebuild your
KERMIT.EXE.

                Chris Lent
                The Cooper Union for the Advancement of Science and Art.
                ihnp4!allegra!phri!cooper!chris
or care of:
                [e-mail]

------------------------------

End of Info-Kermit Digest
*************************
-------
10-Mar-86 16:52:37-EST,15189;000000000001
Mail-From: SY.CHRISTINE created at 10-Mar-86 16:50:36
Date: Mon 10 Mar 86 16:50:36-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V4 #16
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Mon, 10 Mar 1986       Volume 4 : Number 16

Departments:
                      New Kermit-32.Hex Enclosed
           Kermit for Heath/Zenith 100 with UCI EZPC Board
                           Zenith-100 Bugs
                         C-Kermit on HP9000s
                       Suggestions, C-64 Kermit
                              Ultrix-11
                         Kermit on Ultrix-11
                        Setting TAC Parameters
                     Kermit/TACS and Other Hosts
                       Bug in Kermit for VM/CMS
                            Unix C-Kermit
      Problem with Kermit-11 and Intel MDS Kermit (Kermit-Isis)
                         Altos Oasis Kermit?

----------------------------------------------------------------------

Date: Sun, 9 Mar 86 20:49:36 CDT
From: Stan Barber <drillsys![e-mail]>
Subject: New Kermit-32.Hex Enclosed

So that others won't have to suffer as I did, here is a freshly hexed
verion of kermit-32. Enjoy.

[Ed. - Thanks!  For those who don't know why we needed a new hex file for
VMS Kermit, it's a long story.  But now it agrees with the VMSHEX and VMSDEH
programs we distribute with it, and the warning messages can be (and have
been) removed.  VMS Kermit itself has not been changed; it's still version
3.1(066).  The new hex file is in KER:VMSMIT.HEX on CU20B and in VMSMIT HEX
on CUVMA for BITNET.]

------------------------------

Date: Thu 6 Mar 86 16:48:29-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit for Heath/Zenith 100 with UCI EZPC Board

From Marvin Hamdan, UCI Corporation, 948 Cherry Street, Kent, OH  44240,
a version of IBM PC MS-DOS Kermit 2.27 modified to run on the H/Z-100 with
UCI's EZPC board, which is supposed to make H/Z-100 IBM compatible (oh
well).  Before trying to run this, you have to pry off a couple chips
and bend some pins (it's explained in the directions).  The files are
in KER:MS*EZP.* on CU20B and MS*EZP * from KERMSRV via BITNET at CUVMA.

------------------------------


Date: Fri 7 Mar 86 00:03:44-EST
From: "Gordon C. Holterman" <[e-mail]>
Subject: ZENITH BUGS

HELP!!!

I recently grabbed a copy of the kb:msvz10.exe file to run kermit on my
Zenith 100.  However, I am experiencing two major bugs.  First, receiving or
getting files doesn't work.  It starts to work and says it gets the first
packet, but then hangs (the cursor sits at thge end of the file name) and
the only way out is to reboot.  The connection is fine and the remote system
is definately sending data--just no receiving.  Second, the status command
causes a similar lock.  No information gets printed--the cursor runs to the
edge of the screen prints an E and then locks.  Rebooting is the only out.

I would love to get these bugs fixed as soon as possible or get an old
version that works.

        Thanks,
            Gordy Holterman@MIT

[Ed. - The old version is in PB:<KERMIT-OLD>MSZ100.BOO (or .EXE) on CU20B.
Has anyone else had similar problems with the current version, or can give
some hints about making it work right?  This could be an instance of 2.28
being built from source, with the segments coming out in the wrong order,
as described in the .BWR file.]

------------------------------

Date: Thu, 6 Mar 86 11:57:31 PST
From: Arvind Kumar <hpcea![e-mail]>
Subject: C-Kermit on HP9000s

Has anyone else had difficulties trying to make C-Kermit work in terminal
emulation mode on HP9000 computers?

I am trying to use it to go out to a hardwired port (actually an Infotron
port selector) but have had no luck, either on the Series 500 or the Series
220.  In each case, the command 'set line /dev/sw0' takes forever to come
back with 'unable to lock device' or some similar message.  Setting
modem-dialer to racal-vadic allows me to proceed until the Connect step,
which terminates terminal emulation immediately, saying 'host closed
connection' or something similar.

Any clues?

Arvind Kumar
  kumar@hplabs@csnet-relay
  ucbvax!hplabs!kumar

[Ed. - The stupid UNIX "lock files" are the bane of UNIX Kermit.  Read the
section in the Kermit User Guide (the C-Kermit chapter of which is on
line as ckuker.doc) about this.  If all else fails, comment out the code
that looks for the lock file and rebuild the program.  - Frank]

------------------------------

Date: Wed, 5 Mar 86 20:25:53 pst
From: Joel West <[e-mail]>
Subject: Suggestions, C-64 kermit

I have the C-64 kermit 1.7(52).  I'm happy with using it with another
local micro, but thus far have failed with a remote host (probably
due to modem status controls, etc. in the cable).

In c64ker.doc, the authors make comments about suggestions and improvements.
Responding to their ideas, I'd like to offer my 2 cents:
     1.    SET BAUD needs 2400 baud, if said throughput is feasible
    on the C-64
     2.    Slower cursor blink is needed.
     3.    The authors suggest RENAME and SCRATCH command.  I think
    the existing DISK works fine:
        DISK S0:scratched
        DISK R0:new=old
    Perhaps they could modify DISK ? to prompt these options.
     4.    Screen colors would be nice, but B/W is quite readable.
     5.    "Implement wildcard send -- need info on 1541 DOS!", to quote
    from the manual.  According to my 1541 manual,

DIRECTORY
Track 18, Sector 1
    0-1    track, sector next directory block
    2-31    1st entry
    34-63    2nd entry
    66-95    3rd entry
    98-127    etc.
    226-255    last entry

DIRECTORY ENTRY:
    0    128+type 0=Deleted, 1=SEQ, 2=PROG, 3=USER, 4=REL
        128 indicates file properly closed
    1-2    T/S of 1st data block
    3-18    file name padded with shift-space (0xA0 ?)
    19-20    T/S first side sector for relative file
    21    record size, relative file
    22-25    filler
    26-27    T/S replacement file when OPEN@ in use
    28-29    # of blocks in file: low byte, high byte
It would seem that only 0-18 are really needed for kermit applications.

One last comment.  I have two commercial word processors, but neither
seems to use plain CBM ASCII text. If the SpeedScript editor
is really public domain, maybe it could be distributed with kermit
--or a comparable replacement.

    Joel West    CACI, Inc. - Federal
    [e-mail]
    {decvax,ucbvax,ihnp4}!sdcsvax!noscvax!westjw

------------------------------

Date: 7 Mar 1986 0422-EST
From: [e-mail]
Subject: Ultrix-11

Ultrix-11 V2 is a Digital product based on V7 and 2.9.  Ultrix-11 V3 will
have some Sys 5 compatibilities (was announced at Fall Decus) and should be
out soon.  The respondent didn't indicate what version of Ultrix-11 he was
using and what machine he was running it on.

I plan to bring up C-Kermit under Ultrix-11 V2 (and V3 when available) on an
11/73 and will post any diffs necessary to get it to work.

Venix and Pro/Venix are products of Venturcom and are independent of Ultrix-11.

When will a windows version of C-Kermit be available?  Is anyone working on
such a beast?

[Ed. - A version of C-Kermit with windows was announced in Info-Kermit V4 #1.
It's based on an earlier version of C-Kermit (4.0 rather than the current 4C).
It's not in our regular Kermit distribution because of the name conflicts
with the regular release, but it can be FTP'd from PS:<KERMIT-W>*.* on CU20B.
Sorry, it's not available on BITNET.  Eventually, the windowing code will be
added to the distributed version of C-Kermit.]

------------------------------

Date:  86/03/06. 09.28.49.
From:  [e-mail]
SUBJECT: Kermit on Ultrix-11

  In regards to Mark Katsouros question on Kermit for Ultrix-11, we run an
Ultrix-11 system and have installed a working host version of Kermit.  The
Kermit version that we installed was the Unix Kermit from a tape written at
Columbia on 11-12-84.  Identified in the sccsid as version 3.0(1) mod date
11/5/84.

[Ed. - This was our old, pre-C-Kermit version of UNIX Kermit.  It didn't
do much, but it was quite transportable among V7 and Berkeley-based UNIX
systems.]

Ultrix-11 is Digital's version of Unix for the VAX line of computers.
Ultrix-11 is basicly Berkley 4.2 Unix.

[Ed. - Ultrix-11 runs on PDP-11s.  Ultrix-32 runs on VAXes.  Are we talking
about the same thing?]

Ryan Popken
University of Nebraska, Lincoln

BITNET: RYAN@UNLCDC
CSNET:  kermit@unl

------------------------------

Date: Thu, 6 Mar 86 22:25:44 EST
From: Dave Swindell <[e-mail]>
Subject: Setting TAC parameters

In the last digest (V4#15), there was a message from a user wanting to use
C-Kermit over a TAC.  The digest editor gave the correct TAC commands to use
(@ b o s and @ b i s), but gave them IN THE WRONG ORDER!  You must use the @
b o s command (binary output suppress, or something like that) BEFORE you
issue the @ b o s command (binary input suppress).  If you issue the @ b i s
command first, the TAC will not accept the @ b o s command.  Also, if you
are sending data to a host system connected via a TAC, you may need to set
the send packet-length parameter to a value of 64 or less to keep from
over-running the TAC input buffer.

Hope this helps,

Dave Swindell
BBN Laboratories

------------------------------

Date:  6 Mar 1986 15:30:39 EST
Subject: Kermit/TACS and other hosts
From: Glen Foster <[e-mail]>

"Thanks" to all the people who sent me information on TAC commands.  Perhaps
my request was not specific enough.  What I am looking for is a way to have
a Unix host running C-Kermit send the telnet sequence:

IAC WILL BIN    (wait for: IAC DO BIN) then send:
IAC DO BIN      (wait for: IAC WILL BIN)

Then (without the remote user ever having been aware of anything) Kermit
will take over and the user will see the C-Kermit> prompt or whatever.
Another negotiation should be performed upon leaving Kermit to return
control of the TAC to the user although this is not crucial.

IAC is the character 377 octal (Interpret As Command), this is the telnet
"escape" character and is never sent by Kermit (I am told) because octal 177
(ASCII DEL) is not "printable."  It (octal 377) has to be doubled to get
through a TAC even in binary mode.

Telnet negotiation between hosts uses special characters 376 (DONT), 375
(DO), 374 (WONT) and 373 (WILL).  The character that follows one of these
four indicates which option is being negotiated, which for binary is 0
(BIN).

This should only occur if the user is coming over a TAC and not telnetted
host to host, local hard-wired or dialup.  Of course, error detection and
recovery should be taken care of in the best of all possible worlds.

The important thing is that it remain transparent to the users, they should
only have to type "kermit server" ("kermit -x" under UNIX), escape to
command level and transfer files with the greatest of ease.  What do they
know about TAC commands?  I have a key programmed to tell the TAC to jump
and whinny but this causes all sorts of "funny" output that confuses my
users.

Again, TOPS-20 can do it, why can't UNIX.  (Maybe that should rile enough
UNIX gurus so I'll get an answer!)

Glen

[Ed. - It's just a matter of someone writing the code.  It's one of many
items on the list of things to do.]

------------------------------

From: mcvax!eurifb![e-mail]
Date: Fri, 7 Mar 86 12:12:27 +0100
Subject: Bug in Kermit for VM/CMS

A problem erupted when we tried to send lots of packets from a UNIX machine
via a 7171 over a 70-foot line. The 7171 guarantees only 50 foot, and lots
of acknowledgement-packets were garbled, and UNIX-kermit did a retry.  This
was all OK, exept when the old packet-number was 63 ('_').  VM/CMS kermit
wrapped around to 0 (' ') and didn't recognise the resent packet as a retry.
It appeared that masking was forgotten on several occasions. I have tried to
locate all the spots where it should be needed, and inserted them (see the
lines with BN-860227).  It works fine now (upto now for approx. 100 MB).

Ben Noordzij,
Erasmus University, Rotterdam, The netherlands
......!mcvax!eurifb!benno

[Ed. - Thanks for the report.  We've omitted the code from the digest, but
it has been added to the CMS Kermit beware file.  The problem will be fixed
in the forthcoming release (version 3.0).]

------------------------------

Date: 12 February 1986, 10:35:10 SET
From: Wolfgang Hake             0521-106-4941        UHRZS007 at DBIUNI11
Subject: Unix C-Kermit

wir haben probleme, den c-kermit unter der amdahl unix-version UTS V
zu installieren. in der versionsliste ist die UTS V zwar mitaufgefuehrt,
aber im make-file ist dafuer kein spezieller eintrag vorgesehen. die
eintraege fuer fruehere UTS-Versionen (UTS 2.4) sind unter UTS V nicht
lauffaehig. Unter UTS V fehlt der CBREAK-Modus.
Gibt es eine neuere version fuer den C-Kermit, der dem UTS V tribut
zollt? falls sie eine solche haben, schicken sie sie bitte an mich
via EARN.

[Ed. - Der "sys5" Eintrag im make-file gilt auch fuer UTS V.  Kermit
versionen koennen von KERMSRV@CUVMA nachgefragt werden durch BITNET
(EARN) -- z.B. "SMSG RSCS MSG CUVMA KERMSRV SEND CK* *" (CMS).
Excuse my fractured German.  - Frank]

------------------------------

DATE: 7-MAR-1986
FROM: BRIAN@UOFT02
SUBJECT: Problem with Kermit-11 and Intel MDS Kermit (Kermit-Isis)

 Problem: ISIS Kermit can get files from Kermit-11 server but can't send
them. Reported Mar 1986 by [e-mail]

 I know exactly what's wrong, if you would get the current save image from
my Vax it would go away.  The problem in older k11's is when kermit-11 gets
a short (6 char) S packet (ie, the absolute minimum) it stuffs a literal
null into the QBIN field of it's reply, which is a field that does not get
encoded. Please get a new version as described.  The same thing happened to
FidoNet Kermit with Kermit-11. This problem was fixed on 01-Nov-1985 version
2.37.

[e-mail]

[Ed. - Brian will be sending his new release to Columbia shortly.  Until
then, it's available on his VAX at the U of Toledo via BITNET or dialup,
as announced in Info-Kermit V4 #14.]

------------------------------

Date: Thu, 6 Mar 1986 13:06 EST
From: [e-mail]  (Eloise Kleban)
Subject: Altos Oasis Kermit?

Is there a version of Kermit for the Altos running Oasis?  We would
appreciate information and/or a diskette if anyone out there can supply us!
My BITNET address is ELOISE@MAINE.  My US mail address is:

                     Eloise Kleban
                     Computing Center
                     University of Maine
                     Orono, ME 04469

------------------------------

End of Info-Kermit Digest
*************************
-------
13-Mar-86 17:50:54-EST,14063;000000000000
Mail-From: SY.FDC created at 13-Mar-86 17:49:50
Date: Thu 13 Mar 86 17:49:50-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V4 #17
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 13 Mar 1986       Volume 4 : Number 17

Today's Topics:
                    BOO File Encoding and Decoding
            Kermit for the Apple ][ Pascal System (Q & A)
                        TI PC Kermit Ommisions
                          MSZ100.BOO Kermit
                 Kermit on HP Integral Problem (csh)
                     DEC-20 LAT Service vs Kermit
                 Kermit vs Telebit TrailBlazer Modem
                        Kermit on Epson QX-16?
                          Kermit & Wang PC's
            Kermit Diskettes for Atari 800XL or Macintosh?

----------------------------------------------------------------------

Date: Tue 11 Mar 86 14:46:09-EST
From: Howie Kaye <[e-mail]>
Subject: BOO File Encoding and Decoding

I have added UNIX support to the C-language .BOO file maker, MSBMKB.C,
so now it can be compiled for UNIX, MS-DOS, or TOPS-20.  On UNIX and MS-DOS,
it now does efficient blocked i/o, rather than character-at-a-time.  The
DOS version compiles under either Lattice or Microsoft C.

I've also written a .BOO file decoder in C, equivalent to MSBPCT.BAS.  It runs
in about 10 seconds on a PC, rather than 20 minutes.  There is a bug in this
program, which adds extra bytes to the end of the file every time it gets run.
This should not affect anything, as the data is all past what the program
thinks is it's end...If you encode/decode twice though, you do not get
identical files.

/Howie

[Ed. - Thanks, Howie!  The files are in KER:MSBMKB.C (and .BOO), KB:MSBMKB.EXE
(the .BOO and .EXE file are for MS-DOS), and KER:MSBPCT.C (and .BOO), and
KB:MSBPCT.EXE.  All these are available on the Internet from CU20B via
anonymous FTP.  The C and BOO files are also available on BITNET from KERMSRV
at host CUVMA.]

------------------------------

Date: 10 Mar 86 21:11:12 +0100
From: [e-mail] ([e-mail])
Subject: KERMIT for the APPLE ][ PASCAL system

I'm looking for a KERMIT that runs on an APPLE ][ under the (UCSD-)PASCAL
system. Any pointers are very welcome.  Please respond to me directly, as I'm
not on all the lists I'm sending this to.

Thank you very much

Ralf Bayer
Computing Center @ the Technical University of Darmstadt, West Germany

Arpanet address:   [e-mail]
BITNET  address:   xbr1yd22 @ ddathd21

[Ed. - See next message (yes, I responded to him directly too).]

------------------------------

Date: Thu 13 Mar 86 13:24:01-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit for Apple II UCSD p-System

I have a letter from Ph. P. Visser, Rekencentrum der Rijksuniversiteit,
Groningen, Netherlands:

"Enclosed you will find two diskettes concerning a Kermit version for
Apple II (e) and (+).

"The version is made by P. Terpstra of the Laboratory of Biochemics of the
State University of Groningen.  The version is written in UCSD Pascal.
It concerns Apple DOS 3.3 with several interface cards such as:
- Apple Communication Card (ACC)
- California CCS 7710 ASI Card (CCS)
- Hayes Micromodem Card (HMC)
- Apple Super Serial Card (SSC)
- IBM AP2 Serial Card (AP2)

"It is a corrected version of the Stevens version."

Unfortunately, I can't read the diskettes, which are in Apple II Pascal
format, 5.25 inch, double sided.  Could someone who has an Apple p-System
volunteer to read these diskettes and send the contents to Columbia?
Preferably someone on one of the networks, but failing that, someone who'd
be willing to send the files back to us on IBM PC or AT DOS diskettes,
Rainbow DOS diskettes, or 9-track magnetic tape.  Thanks!

------------------------------

Date: Wed, 5 Mar 86 20:33:34 cst
From: Rusty Haddock <seismo!ut-sally!im4u!ti-csl!tilde!haddock>
Subject: TI PC Kermit Ommisions

I've checked the sources for version 2.28 revision 5 and found that the things
that have been asked about are UNIMPLEMENTED!  Things like local echo, inverse
video, auto wrap, and the like are just not there (in file MSYTIP.ASM).  Local
echo should check the 'ecoflg' flag in some data structure and display the
outgoing character accordingly.  Inverse video is a "stub" that just returns.
These should be trivial to actually code *OR* you can take the old MSXTIP and
MSYTIP from a previous version of Kermit, assemble, and link them in as the old
version at least had local echo.

Unfortunately, hacking with MS Kermit is very low on my list of things to do
but... who knows, I might get to it.

            -Rusty-

------------------------------

Date: 11 Mar 86 17:00:00 EST
From: "M. COOK" <[e-mail]>
Subject: MSZ100.BOO KERMIT

Gordan C. Holterman indicated in his message of 7 March that he was unable
to successfully use the STATUS command inthe KB:MSVZ10.EXE version of
Kermit.  The same problem exists in the MSZ100.BOO version.  On the contrary
I have had no problems Receiving or Getting files.  I have however
experienced hangups while reading Mail on the MILNET; but this seems to
occur only when a capture file is open. Usually, all that needs to be done
is to depress the RETURN Key. But, even at that some information is dropped.
                                    Regards,  MHE COOK  (NORDET)

------------------------------

Date: Tue 11 Mar 86 05:26:16-EST
From: [e-mail]
Subject: Kermit on HP Integral Problem (csh)

    I recently installed the new operating system ROMs in my HP Integral
PC.  Since then I have had a minor problem with C-Kermit (050) while running
under csh.  It is likely a problem with either the OS and/or csh, but since
C-Kermit is the only effected program (so far), I thought that I would inquire
here for suggestions.

Situation:    Connecting to a Hayes compatible modem to dial a number.  Line
        set to /dev/tty00 and baud set to 1200.
Behavior:    Running under sh and either the old HP-UX ROMs (System III?)
        or the new HP-UX ROMS (S5R2) kermit works normally.  Running
        under csh and the old HP-UX ROMs kermit also works normally.
        Running under csh and the new ROMs, the echo from the modem
        does not appear on the screen.  Typing the pulse dial command
        (ATDPxxxxxxx) and hitting a carriage return results in having
        the modem dial the number xxxxxxx.  Even after a connection has
        been made, no echo appears on the screen.  Escaping (or
        attempting to) to local control (^\-C) results in csh being
        logged off (SIGINT or SIGKILL is being sent?).  Attempting to
        log session, packets, debugging and transactions is sort of
        futile, only the debugging log shows anything.  The following
        is the tail end of the debugging log complete with initial
        header:

    Does anyone out there have any idea as to why C-Kermit works with sh
under both versions of the ROMs and only with the old version of the ROMs if
csh is used?  I plan to look into this this summer, but getting a note back as
to the cause and fix may be difficult as I will no longer have access to any
networks.  Also I don't have ADB so debugging is going to be fun.  This summer
I will try to get C-Kermit to work with the shell PAM, right now the system
locks up badly if kermit is started up from PAM as opposed to sh or csh.

                        Gordon Haverland
                        GH0N @ TC.CC.CMU.EDU
                        Box 596
                        Dawson Creek, B.C.
                        Canada
                        V1G 4H5

[Ed. - I asked Gordon to try the current version of C-Kermit, 4C(057), to
see if the problem persists.  Anybody else have any hints or experience with
this?]

------------------------------

Date: Thu 13 Mar 86 14:40:53-EST
From: Frank da Cruz <[e-mail]>
Subject: DEC-20 LAT Service vs Kermit

When you are connected to a DEC-20 through a DEC Ethernet terminal concentrator
(like DECserver-100) using the LAT protocol, you will find that you can't
transfer files of any kind into the DEC-20 using Kermit or MODEM or any similar
protocol.  You can, however, transfer files from the DEC-20 to the PC with no
problem.  Logging packets during uploading reveals that a typical Kermit data
packet (80-90 characters) is truncated by the LAT box to 30-40 characters.  If
you reduce the Kermit packet size to, say, 37, then everything works.

The problem occurs because TOPS-20 LAT service defines the LAT input buffer
length to be 40 instead of the recommended 127 (133 would be better for MODEM).
The problem does not occur with Ultrix-32 LAT service.  For now, those who want
to use Kermit to send files to a DEC-20 through a LAT box must set their packet
size to 37 or less.  Those who want to use MODEM will have to use Kermit
instead, since MODEM packet sizes cannot be changed.

------------------------------

Date: Thu 13 Mar 86 15:16:03-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit vs Telebit TrailBlazer Modem
Keywords: Telebit

We had the chance to try out a pair of Telebit TrailBlazer modems recently.
These modems use a proprietary packet protocol to provide error-free
transmission up to 10,000 baud over ordinary dialup lines.  They include the
regular Hayes command set, augmented by a lot of special settings.  We used the
"old ROM" version -- apparently there is a "new ROM" that makes things better.

The short story is that Kermit works over these modems, but the performance is
awful.  The modem's algorithm for sending a packet seems to be to wait until
its buffer is full, or else until its timer goes off.  Unfortunately, its
buffer is bigger than a Kermit packet, so it will never send a Kermit packet
until it times out.  The timeout interval seems to be something like 5 seconds,
and there's no way to change it.  Furthermore, there's no concept of "data
forwarding characters" like you have in an X.25 PAD, so you can't tell it to
transmit whatever it has in its buffer whenever it sees a carriage return.
As you might imagine, interactive terminal use is pretty bursty.

For "classic" Kermit between two PC/AT's at 9600 baud over a local phone call,
the effective data rate was something like 40 baud.  Windows-kermit on the same
connection did a lot better: about 3700 baud.  But even with windowing, there
were many pauses and delays; the throughput should have been more like
7000-8000 baud.

The manual doesn't say anything about its packet buffering and forwarding
technique, except to imply that its buffer is about 10,000 characters long.
There is a sentence, however, to the effect that "many communication software
packages (especially those using half duplex protocols such as XMODEM) may not
be optimized for use the TrailBlazer."  Later on they say "The TrailBlazer's
packetizing and retransmission behavior must be accommodated by any protocol
that contains timers for inter-character delays or response limits."

Some commercial software packages, like Crosstalk, have added explicit
TrailBlazer support.  It would have been better if Telebit had used the power
of the 68000 to make the operation of the modem a little more flexible by
letting the user specify the timeout interval and break mask.

------------------------------

Date: Mon, 10 Mar 86 15:33:14 PST
From: arch%renoir@berkeley (Arch Turner)
Subject: Kermit on Epson QX-16?
Keywords: Epson

Has anyone made Kermit work on an Epson QX-16?  Can it be set up as if the
QX-16 were an IBM PC?

                Thanks,
                    Arch Turner, CSSG Staff
                    467 Evans, 2-1319
                    arch@renoir

------------------------------

Date: 11 Mar 86 23:33:00 EST
From: <dana@bbnccr>
Subject: Kermit & Wang PC's
Keywords: Wang PC Kermit

I tried to load KB:MSVWNG.EXE using FTP and then KERMIT and got a 'not
enough memory' error (on a 640k machine).  So I downloaded MSVWNG.BOO and
MSBPCT.BAS and built the executable.  The STATUS command printed a few
thousand spaces, a few random bytes of memory, and then the system died.
Not too long ago (a few months at least) a new version of the operating
system was received from wang. The version numbers are:

    Wang professional computer: V2.40
    Bios:                V1.21
    MS-DOS:                V2.01

Also, I tried the generic KERMIT and it worked fine (it's not the ASM or
LINKER, as thats how I built the generic version. Bothe the ASM and LINKER
are version 1.10). HELP!!!

                Thanks,
                    Eric Dana
                    dana@bbnccr
                    BBNCC/MIS

[Ed. - Can anybody out there help?  If you have a working version of Wang
PC Kermit, could you send in, or point us at, an .EXE or .BOO file for it?
I know Wang PC Kermit worked at one time, because it was written here at
Columbia.  Unfortunately, the person who wrote it and the PC itself are both
long gone.]

------------------------------

Date: 12 Mar 1986 1453-EST
From: LCG.KERMIT@DEC-MARLBORO
Subject: Kermit Diskettes for Atari 800XL or Macintosh?
Keywords: Mac Kermit, Atari Kermit

I would like to obtain a copy of Kermit both for the Atari 800XL and for the
Apple Macintosh.  However, I have no communication software whatever on either
machine, and on the Atari I have only Basic (so KERBOO does not help).
Can anyone out there in Kermit-Land help me?  If so, please contact me
as follows:
    Paul Liebow
    W.R.Grace & Co.
    1114 Avenue of the Americas
    New York, NY 10036
    212/819-6963
... And thanks!

[Ed. - We sent him a note about how to order Mac Kermit on diskette from
us.  Can anybody help with Atari Kermit?  If so, would that person care to
volunteer as a general Atari Kermit diskette distributor?  Or to submit the
Kermit diskette to some kind of Atari user group that could distribute it,
and then tell us about it so we could refer future inquirers there?]

------------------------------

End of Info-Kermit Digest
*************************
-------
18-Mar-86 15:30:28-EST,10216;000000000000
Mail-From: SY.CHRISTINE created at 18-Mar-86 15:28:00
Date: Tue 18 Mar 86 15:28:00-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V4 #18
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 18 Mar 1986       Volume 4 : Number 18

Today's Topics:

           MS-DOS Kermit 2.29 Almost Ready, Testing Needed
                          KERMIT on the Z100
                    I have a working AMIGA KERMIT
                  MACKERMIT Terminal Emulation Fixes
                 Kermit on LAT with VMS (2 messages)
                  Re:Kermit(057) on the HP Integral

----------------------------------------------------------------------

Date: Tue 18 Mar 86 13:51:43-EST
From: Frank da Cruz <[e-mail]>
Subject: MS-DOS Kermit 2.29 Almost Ready, Testing Needed
Keywords: MS-DOS Kermit

Joe Doupnik has begun the task of adapting the system-dependent support
modules for the various non-IBM system to the current prerelease of MS-DOS
Kermit, 2.28 jrd/5e.  This is very close to the final 2.29 release.  The
Rainbow version has already been built and seems to work just fine (a neat
trick for Joe, considering he didn't have a Rainbow to test it on, and the
memory management code had to be redone).

The files are on CU20B, in PS:<KERMIT-MS>.  Included are a complete set
of system-independent sources (MSS*.ASM and .H), objects (MSS*.OBJ), and
system-dependent sources (MSX*.ASM, MSY*.ASM, and MSZ*.ASM).  The objects
were produced using MASM 1.10 on a DEC Rainbow.  The .EXE and .BOO files
are already built for the IBM PC family and the Rainbow.

I would appreciate it if anyone on the Internet who has access to any of the
following systems would FTP the necessary source &/or object files and try
to build 2.28 jrd/5e for their systems, and give it a good workout.  If there
are problems, please report them.  If it works, please send a .BOO file, or
point us to where we can FTP an .EXE file from.  Here are the systems to be
tested:

PS:<KERMIT-MS>

 MSXAP3.ASM  NEC APC 3
 MSXAPC.ASM  NEC APC
 MSXAPR.ASM  Apricot
 MSXDM2.ASM  DECmate III with MS-DOS option
 MSXEZP.ASM  Z100 with UCI EZ PC card
 MSXGEN.ASM  Generic DOS
 MSXGRI.ASM  Grid Compass
 MSXHP1.ASM  HP150
 MSXHPX.ASM  HP 110, and (or?) Portable
 MSXIBM.ASM  IBM PC, XT, AT, etc, and compatibles (.BOO and .EXE available)
 MSXM24.ASM  Olivetti M24
 MSXMBC.ASM  Sanyo
 MSXRB.ASM   DEC Rainbow (.BOO and .EXE available)
 MSXTIP.ASM  TI Pro (not quite ready yet)
 MSXV90.ASM  Victor 9000
 MSXWNG.ASM  Wang PC
 MSXZ10.ASM  Heath/Zenith 100

These files are not available on BITNET, since the only way to make them
available via KERMSRV would be to overwrite the current release, which should
not a be done until the new release is checked out for all these systems.

Anyone using FTP to get the binary (.OBJ and .EXE) files from CU20B might have
to take special measures.  If you're coming in from a system that's not a
DEC-20, you'll have to give special FTP commands to get the binary files,
like TYPE L 8.

------------------------------

Date:  Sun, 16 Mar 86 23:20 EST
From:  [e-mail]
Subject:  KERMIT on the Z100
Keywords: Z-100 Kermit
Cross-Ref: Z100, Zenith Kermit, Heath/Zenith (see also z-100 Kermit)

In reponse to the request for Z-100 kermit problems, I'd like to add my
observations:

1)  The new version 2.28 does indeed do nasty things when certain
    commands are executed.  Status, for one, hangs the machine.

2)  The problem added after PC-KERMIT, that of hanging up the modem
    with a change from connect to send or receive, has not been fixed
    with version 2.28

3)  The misbehavior of KERMIT with VI has been fixed with 2.28;  it
    seems that the terminal emulator can finally keep up with the
    modem without long delays after screen refreshes, etc.

4)  The DELSTR for the Z100 KERMIT is different than for 2.27;  it must
    be changed from the source 'bs,' ',bs to require another bs.
    The reason for the change is not entirely clear, but if not fixed, it
    makes KERMIT appear not to erase its input.

I would like to have a totally working version of KERMIT past 1.27j, but
until problem 2) is fixed, my transfers must be done with that old version.

A question is, WHO is current with KERMIT for the Z-100?  I have sent
mail to both INFO-HZ100 and INFO-KERMIT and not received any responses.
Can it be that the Z100 KERMIT is up for grabs?

My best to the lucky ones, and a thanks to Catchings, da Cruz, Tzoar, et. al.
for giving us a fun protocol to hack at......

[Ed. - Try the new version of MS-DOS Kermit 2.28/jrd5e from the previous
message and see if the same problems occur.]

------------------------------

Date: 14 MAR 86 17:02-EST
From: DPVC@UORDBV
Subject: I have a working AMIGA KERMIT
Keywords: Amiga Kermit

I am a long-standing fan of KERMIT, so when by brother bought an AMIGA
micro-computer recently, bringing up KERMIT for it was one of my first
projects.  I have a working AMIGA KERMIT, based on the UNIX C-KERMIT
version.  It is line-oriented, not menu-oriented, as is the MACKERMIT, but I
felt that getting a solid, tried-and-true KERMIT working was more important
than a slick look, at least to start with.

There have been a number of requests for AMIGA KERMIT on INFO-AMIGA and
net.micros.amiga, so I feel that it would be a good product to add to your
list of available KERMITs.  I am still developing some of the less important
features, but all the file transfer parts work very well.  I have NOT
implemented local shell commands (directory, cd, etc.), nor thier
server-mode equivolents, though, SEND, GET, HELP, FINISH and BYE are
supported in server-mode.  I do not support wildcard file look-ups (yet),
and have no special terminal emulation (VT100 is planned); at the moment,
when you CONNECT you just get a dumb terminal.

I have had a number of requests to distribute my version.  I would like your
advice on how best to do this, and on whether I should distibute myself, or
if you would rather route it through KERMSERV on BITNET.  I would be happy
to send you the sources to you, but I hesitate to send them to too many others,
as they amount to quite a bit (CKUCMD, CKCFNS, etc.).

I plan to continue to develop AMIGA KERMIT, though I feel that it is well
enough along for many people to benefit from it.  I was able to bring it up in
less than three weeks (working evenings only), which I attribute to the
excellent design of the common C-KERMIT modules.  It is a pleasure to work with
your code.

Please let me know whether you are interested in this as soon as possible, as
there are people waiting for AMIGA KERMIT to be released.

[Ed. - Kermit for the Amiga is on the way and will be announced as soon
as it arrives. ]

                                Davide P. Cervone
                                University of Rochester
                                Computing Center
                                Taylor Hall
                                Rochester, NY  14627

                                [e-mail]
                                seismo!rochester!ur-tut!dpvc.UUCP
                                [phone]

------------------------------

Date: 14 MAR 86 17:02-EST
From: DPVC@UORDBV
Subject: MACKERMIT Terminal Emulation Fixes
Keywords: Mac Kermit

Sometime in November, I sent you a message about enhancements to the
MACKERMIT VT100 emulator that we have made here ate the U of R.  Did you
ever receive it?  We have been using these corrections here since then
throughout the University, and find them very helpfull.  The VT100 emulation
is much better than the current release version.  If you are interested in
these, please let me know, and I will send them, too.

[Ed. - Nope, I must have missed this message somehow!  Davide has since sent
along the Mac Kermit changes, and they fix most of the problems with VT100
terminal emulation (like the notorious boldface problem), and add some highly
desirable new features too, like using the mouse to send arrow-key cursor
positioning commands.  In a couple hours of testing, the only problems I
found with it were that it incorrectly reported itself to be a VT100 with AVO
rather than a VT102, and that the control keys no longer autorepeat.  Since
this version has not yet been thoroughly tested, it won't become the standard
one just yet, but it has been placed KER:MC2*.* for now, alongside the regular
version.  Please try it out.]

------------------------------

Date: Thu 13 Mar 86 20:49:41-EST
From: Richard Garland <[e-mail]>
Subject: Kermit on LAT with VMS
Keywords: VMS Kermit

FYI - Kermit works fine using LAT under VMS.  I use it every day.
                        Rg

[Ed. - This message and the following one are in response to the note in the
last Kermit Digest V4 #17.]

------------------------------

Date: 14 Mar 86 12:53:00 PST
From: [e-mail]
Subject: Kermit on LAT with VMS
Keywords: VMS Kermit

    I have had the same problem with VAX VMS LAT ver 1.0.  Supposedly the
new version 1.1 or 2.1 will fix the problem.  I found your discussion very
useful.  Thanks.

Alex.

------------------------------

Date: Sat 15 Mar 86 17:13:07-EST
From: GH0N@CMCCTC
Subject: Re:Kermit(057) on the HP Integral
Keywords: HP Intregal, C-Kermit

    This note is in reply to my previous post about an incomptibility
between C-Kermit and csh on the HP Integral that has the new (SVR2) ROMs.
Installing the latest version of C-Kermit(057) did not have any effect on
the supposed incompatibilty.  Running with csh alone or sh on top of csh
resulted in the loss of communication from the modem to kermit.  When escape
to local control (^-\C) was attempted the csh process stopped.  It is not
known whether csh is recieving EOF or some signal such as SIGINT or SIGKILL.
Sometime in the near future (hopefully) I will get the oportunity to run
C-Kermit from debug to find out what is happening.

                        Gordon Haverland

------------------------------

End of Info-Kermit Digest
*************************























-------
21-Mar-86 19:51:11-EST,14994;000000000000
Mail-From: SY.FDC created at 21-Mar-86 19:50:33
Date: Fri 21 Mar 86 19:50:33-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V4 #19
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 21 Mar 1986       Volume 4 : Number 19

Today's Topics:
           New C-Kermit Release Available for UNIX and VMS
                 Printable Encodings for Binary Files
               Re: Printable Encodings for Binary Files
                          Kermit & Telebits
                          Sperry 1100 Kermit
                   Spooling Prints from an IBM/PC?
                  Re: Spooling Prints from an IBM/PC
                 Problems with Kermit on SCO Xenix V
               MS-DOS Kermit on ATT 6300 vs VMS Kermit?

----------------------------------------------------------------------

Date: Fri 21 Mar 86 11:11:21-EST
From: Frank da Cruz <[e-mail]>
To: Info-Kermit@CU20B, info-unix@brl-sem
Subject: New C-Kermit Release Available for UNIX and VMS
Keywords: C-Kermit
Cross-Ref: VAX Kermit, UNIX Kermit (see also C-Kermit)

This is to announce a new release of C-Kermit.  It is only a minor release,
and incorporates no new functionality.  The only intention is to fix the
more serious bugs.  Future releases will involve more serious reworking of
the code to improve organization and performance, and to add missing features,
like extended packets, sliding windows, and attribute packets.

The new release is called 4C(058), for UNIX and VMS.  The fixes that
apply to all (or most) systems supported by C-Kermit include:
. Bug with set send/receive padding fixed.
. Bugs that interfered with wildcard sends fixed.
. Bug that mixed up send and receive packet terminators fixed.
. Bug with single-file cancellation (^F or ^X) fixed.
. NAK for next packet now handled correctly as equivalent to ACK for current.
. NAK is no longer immediately sent after RECEIVE or SERVER command given.
. Long bursts of incoming data no longer crash the program.
. Longer sleep done at end of file transfer to prevent other side from hanging.
. ^S removed from among CONNECT escape character arguments.
. Dial pause of 0 no longer causes problems.

The fixes specific to UNIX include:
. Fixed support for 2.9 BSD (tested on DEC Pro 380).
. New makefile entry for Masscomp (untested).
. Some 0's in system calls changed to NULLs.
. SET SEND/RECEIVE TIMEOUT 0 no longer prevents file transfer from working.

VMS changes (untested):
. '!' should now spawn an interactive DCL.
. REMOTE commands to VMS C-Kermit server should now work.

The new version of Macintosh Kermit that is based on C-Kermit is not ready
yet because it's too big for our SUMACC cc68 cross-compiler to handle.
We're trying to dig up a version of cc68 with an expanded symbol table
(anybody have one we can FTP?).

The new C-Kermit files are in KER:CKC*.*, KER:CKU*.*, KER:CKV*.* on CU20B,
available via anonymous FTP, and in CKC* *, CKU* *, and CKV* * on CUVMA
via KERMSRV over BITNET.  They should also find their way to uucp host okstate
at Oklahoma State University within a day or two.

------------------------------

Date: Tue, 18 Mar 1986  09:12 MST
From: "Frank J. Wancho" <[e-mail]>
Subject: Printable Encodings for Binary Files
Keywords: Binary Files

Apparently the Intel HEX format, which HEXIFY generates, is not usable
on the PCs.  What do you use?  Is it those .BOO files?  If so, how do
you generate them?  Can they be generated on the 20?  And, what is
used on the PC side to recreate the original?

------------------------------

Date: Thu 20 Mar 86 08:53:10-EST
From: Frank da Cruz <[e-mail]>
Subject: Re: Printable Encodings for Binary Files
Keywords: Binary Files

We have a couple programs on the DEC-20 for doing this kind of stuff.

KT:HEXIFY.* and KT:HEXCOM.* convert CP/M .COM files to Intel hex format
& vice versa.  These were written by Bruce Tanner of Cerritos College, and
run on the DEC-10 or DEC-20.  But I believe Intel hex format is of little
use on MS-DOS systems.

KT:HEXE.* and KT:UNHEXE.* convert between 8-bit binary files and straight
2-for-1 hex encoding (with CRLFs inserted for readability).  I wrote these in
about 10 minutes one day.  They only work on the DEC-20.

The .BOO file format is something we invented for distributing MS-DOS Kermit,
but it should work for any 8-bit binary file.  It's sort of like Macintosh
BinHex (but .BOO came first): 4-for-3 printable ASCII encoding, with
compression of repeated zero bytes.  A typical .BOO file is shorter than the
corresponding .EXE because of the zero-compression.  Here are the relevant
programs:

KER:MSBMKB.C turns an 8-bit binary file into a .BOO file.  KB:MSBMKB20.EXE is
a version that runs on the DEC-20; KB:MSBMKB.EXE is for MS-DOS.  It can also
run on Unix.

KER:MSBOOT.FOR is a Fortran program that runs on a mainframe that downloads
a .BOO file to a PC.  It runs on DEC-10, DEC-20, VMS, even IBM mainframes.
KER:MSBPCB.BAS is the corresponding Microsoft Basic program that receives the
.BOO file from MSBOOT, decodes it on the fly, and stores the resulting binary
file on the disk.

KER:MSBPCT.* are the programs that translate a file from .BOO format back to
.EXE (or whatever).  They assume you have already downloaded the .BOO file.
The C version can run on Unix or MS-DOS (it takes a few seconds to process a
40K file).  The .BAS version is in Microsoft Basic for MS-DOS -- it takes about
20 minutes to do the same 40K file.

------------------------------

Date: Thu, 20 Mar 86 07:54:29 EST
From: [e-mail] (Scott Brim)
Subject: kermit & Telebits
Keywords: Telebit

Frank, some mail you sent to Don Porter has wended its way to me.  I'm
surprised you got even that much throughput running Kermit with the
Telebits.  The answer is to use the new "interactive mode" PROMs - much
smaller delay times and a few other changes for tuning for real
terminal use.  I think you'll see much better performance.

[Ed. - We might be getting some of these next week.  If so, will give
them a spin.]

------------------------------

Date: Wed, 19 Mar 86 17:00:47 cet
From: [e-mail]
Subject: Sperry 1100 Kermit
Keywords: Sperry

We are running the Sperry Kermit by Paul Stevens, dated june/july 1985.
If anyone is interested, here is a report of some of our problems with
this Kermit, and our fixes for them.   Apart from these minor annoyances,
Kermit has been a pleasure to use!

       (1) There is no need for Kermit to assign the Sperry work file
           exclusively, apart from the risk that someone else writes to
           the file during transmission.   To me, this was more annoying
           than useful, so I changed the file assignment as shown.

       (2) As distributed, Kermit will not treat program file elements
           with multiple cycles (indicated by fieldata S in S3 of the
           label control word), unless the data part of the label conforms
           to the SDF standard (*SDFF* in first word).   As a result,
           elements written by the system line editor ED, will not be
           transmitted correctly.   That is, if our fix is not applied...

       (3) When ACK'ing a previous data packet, Kermit as distributed put
           the first 6 characters of the ACK'ed packet into the data part
           of the ACK.   I haven't seen any Kermit do that before, but it
           looks straight enough.   However, after receiving a couple of
           those 'long ACKs', IBM PC-Kermit (2.28) fills the next one or
           two packets with garbage (typically, a lot of zeros - nicely
           encoded, though, so the receptor does not notice).   The result
           is an apparently successful transmission, with a few 'black holes'
           in the element on the Sperry host.   Changing the data size to
           zero in these ACKs seemed to eliminate the problem.

These are the fixes in Sperry correction card format

  (1) -3177,3177
                sTrng     '@ASG,A  K$E$R$M$I$T$ . ' . Not exclusive
  (2) -4287,4288
  (3) -4713,4715
                sz,h2     prline           . Do a normal ack of length 0
                l,u       a2,prline        . Seems to confuse PC-Kermit

-fi
Frithjov Iversen
Trondheim University Computing Center, Norway

[Ed. - Taksgardeha!  (Did I spell that right?  Not a chance...)  I've added
your note to the .BWR file.  I trust that pAul sTevens will see it himself
one day.]

------------------------------

Date: Thu, 20 Mar 86 12:22:20 est
From: Ken Mandelberg <[e-mail]>
Subject: Spooling Prints from an IBM/PC?
Keywords: PC Kermit

Is there any combination of kermits, that would allow spooling of files for
printing from an IBM/PC to a Unix host, without any operator interaction?
The normal steps of terminal emulation for login, escape to command mode,
initiating a file transfer, back to terminal emulation to issue some unix
print command, escape and terminate, seems to frustrate our secretaries. In
fact anything short of typing a one line command, or better yet a function
key, seems to be a problem.

I am a little out of date on what is available in each kermit version. The
server mode for Unix kermit would seem to speak to the question, but I think
PC kermit does not exploit it. Even if available, the server approach might
not be a great solution. The logistics of starting, stopping, the server,
and dealing with any malfunction would be very frustrating to these users.

Any suggestions and information would be appreciated. If there is a better
approach then kermit for this problem, that too would be appreciated.

Ken Mandelberg
Emory University
Dept of Math and CS
Atlanta, Ga 30322

{akgua,sb1,gatech,decvax}!emory!km   USENET
km@emory                      CSNET
km.emory@csnet-relay          ARPANET

------------------------------

Date: Fri 21 Mar 86 09:01:37-EST
From: Frank da Cruz <[e-mail]>
Subject: Re: Spooling Prints from an IBM/PC
Keywords: PC Kermit

What you really need is a script facility in MS-DOS Kermit.  But there
isn't one.  The release after next will probably have it.  With a script
facility, you could put all the commands for logging in to Unix and
starting up the server into a command file, and the user could "take unix"
or whatever (you could even define a command macro for this to make it
easier, or use a utility like ProKey to bind it to a function key).

Without a built-in script facility in MS-DOS Kermit, you might still be
able to accomplish the same effect by writing a little program to log them
in and start the Kermit server.  It could be run from their autoexec.bat
file, or whatever.

Then, when they wanted to print a file, they could say "xprint foo.bar",
where xprint was a .bat file which simply translated the command into
"kermit send foo.bar".

On the Unix end, you could have server cd'd to a special spooling directory
(publicly writable), and then you could have a separate daemon process that
would wake up every so often, and print and delete any files that showed up
in this directory.

Finally, to let the user finish up for the day, you could have them type
simply "kermit bye".  If that's too complicated, you could bind this string
to another function key, or write a little .bat file with a more suggestive
name that does the same thing.

The users could not be entirely oblivious of what was happening.  The amount
of time to transfer a file from the PC to Unix could be significant if the
file is long.  In 2.29 of MS-DOS Kermit, you could include "set display off"
on the command line, which would disable the screen display during file
transfer.  Then, if they were using one of the "multitasking" systems like
DesqView, TopView, MS Windows, etc, they could continue with other work without
being bothered.  In the future, there may be a version of Kermit for MS-DOS
that can be installed as a device driver.  Once connected to a Kermit server
on the other end, it would work just like the PRINT command -- you could say
"send foo.bar", and it happen by itself, leaving even an ordinary DOS system
free to do other work during the transfer.  But don't hold your breath for
this one.

------------------------------

Date: Fri, 14 Mar 86 09:55:15 EST
From: [e-mail] (John Yatteau)
Subject: Problems with Kermit on SCO Xenix V
Keywords: Xenix Kermit

I obtained source for C-Kermit 4C(057) 31 Jul 85 from the harvard vax and
compiled it under SCO Xenix Sys V Rel 2.0 on both an IBM PC/AT and an
IBM PC.  The result was a dialect of Kermit in which the PC's can
communicate normally with each other, but not with the vax or any other
normal Kermit.  The Xenix Kermits appear identical to C-Kermit on the vax
in every other way.  The debug log shows the transfer hanging up on the
packet check ("rpack: chk_      should be [").  I had to modify the
makefile slightly to use the "middle model" option of cc, and tried all
likely makefile options (sys 3's and 5's).  I even recompiled C-Kermit
on the vax to insure that the sources were identical.

Any ideas?

    Jack Yatteau
    [e-mail]
    617-495-9663
    Pierce Hall/CEPP
    29 Oxford St.
    Cambridge, MA 02138

[Ed. - Beats me!  This program is known to work on at least some versions
of Xenix on the IBM PC family.  Has anyone out there seen anything like
this?]

------------------------------

Date:     Fri, 21-MAR-1986 11:22 MST
From:     KEVIN GRAY <GRAYK@BYUVAX>
Subject:  MS-DOS Kermit on ATT 6300 vs VMS Kermit?
Keywords: MS-DOS Kermit, VMS Kermit

I am running MSDOS-KERMIT version 2.28 on an AT+T PC6300 and have experienced a
few problems that I hope you can help me remedy.  While transferring files to a
Vax-8600 KERMIT-32 I have an inordinate number of retries-approximately 1 retry
for every 10 packets sent.  I have also had difficulty transferring files of
20Kbytes or more to KERMIT-32.  With the KERMIT-32 in server mode I have been
able to download files of up to 200Kbytes with 0 retries but when uploading
large files I very rarely have a successful transfer.  Sooner or later I get
a KERMIT-32 device timeout error or a KERMIT-32 receive error.  Smaller packet
sizes have made no difference.  I have spoken to other users on the same system
who use different micros and none have reported the same problem so I am not
sure if the error is in my machine or not.  I would greatly appreciate any help
you could give me regarding this problem.

                                        Thank You,
                                        Kevin Gray "grayk@byuvax"

[Ed. - Another "beats me".  Does anyone else have any experience
transferring very large files between these two systems?]

------------------------------

End of Info-Kermit Digest
*************************
-------
25-Mar-86 16:25:44-EST,6651;000000000000
Mail-From: SY.CHRISTINE created at 25-Mar-86 16:24:05
Date: Tue 25 Mar 86 16:24:05-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V4 #20
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 25 Mar 1986       Volume 4 : Number 20

Today's Topics:
                       Amiga Kermit Executable
                            New Kermit-10
                          MS-DOS Kermit 2.29
                       Kermit-11 Known Problems
                           OK State Access
                       Request for Epson QX10?

----------------------------------------------------------------------

Date: 24 MAR 86 15:41-EST
From: [e-mail]
Subject: Amiga Kermit Executable
Keywords: Amiga Kermit

I am sending you a file called CKAKER.BOO, which is the Amiga Kermit executable
in BOO format.  I also include my version of MSBPCT.C, which should translate
it back into the executable.

This version is a PRE-RELEASE version.  I am sending it so that you can test
it, and send me any comments you may have.  I am getting the sources in shape
to send, but it is taking longer than I thought it would (doesn't it always?).

Right now, the known problems/deficiencies are:

        1)  Wildcards are not allowed in filenames
        2)  No LOCAL commands are supported (DIRECTORY, CWD, etc.)
        3)  No DIAL or login scripts
        4)  The SERVER mode only does GET, SEND, BYE, FINISH and REMOTE HELP
        5)  No XON/XOFF flow control
        6)  REMOTE HELP messages go to the DOS window, not the KERMIT window
            (in fact, they don't show up until you exit from Kermit)
        7)  The program thinks the window is 80 columns wide, when, in fact,
            it is only about 76 columns wide (it can be resized to be even
            smaller)
        8)  No terminal emulation (just a dumb terminal in CONNECT mode)
        9)  File transactions all report elapsed time of 0 seconds (although
            timeouts work properly)

That's all I can think of right now.  Please let me know if you come up with
any other problems or improvements.

You should receive 2 files:  CKAKER.BOO and MSBPCT.C

                                        Davide

[Ed. - Thanks!  These files are in KER:CKAKER.* and KER:MSBPCT.C.]

------------------------------

Date:     Tue, 25 Mar 86 14:03:48 EST
From:     dstevens (David L Stevens) @ sitvxb
Subject:  New Kermit-10
Keywords: Kermit-10

The latest version of KERMIT-10 is now available.  The changes made are
documented in K10133.MEM.  The K10V3.RNO documentation is still valid.

Please note that you must rename K10MIT.HLP to KERMIT.HLP if you wish to
have KERMIT give you online help.  If there are any problems with this
release please let me know.

 - David L. Stevens
 - Stevens Institute of Technology
 - DSTEVENS@SITVXB

[Ed. - Thanks!  The new files are in KER:K10*.*.  The .EXE file, for those
who can FTP binary files, is in KB:K10MIT.EXE.]

-------------------------------------

Date: 25 MAR 86
From: SY.CHRISTINE@CU20B
Subject: MS-DOS Kermit 2.29
Keywords: MS-DOS Kermit

2.29 is almost ready for release.  It has been tested on the IBM PC family
and the DEC-Rainbow but not on anything else.  It's all there, just waiting
for people to try it out for the NEC, Sanyo, Victor, Apricot and all the
other non-IBM compatible systems.  Please test this and send reports back to
us.  If it does work, please send us a .BOO file.  If it doesn't, please
report the bugs.  We will just continue to distribute the old .BOO files
with the new source for those systems we do not get reports about.  The
files are in PS:<KERMIT-MS>*.* .  Thanks!!

                                      -Chris

------------------------------

Date: 25 MAR 86 09:04-EST
From: BRIAN@UOFT02
Subject: Kermit-11 Known problems
Keywords: Kermit-11

 Attribute processing is incorrect for some attribute types. This  dates
back  to  April 1984 when support was first added, but no other versions
were available to test against.  The  correction,  made  to  K11ATR.MAC,
will  cause  V3.49  or later of Kermit-11 to have compatability problems
with previous versions  of  Kermit-11.  The  main  problem  will  be  in
informing  each  other of binary file arrival; the only workaround is to
explicitly force two communicating Kermit-11's  into  binary  mode  with
the SET FILE command. See K11INS.DOC for further information.

 The  specific  problem is that the protocol requires the attribute TYPE
field to be  followed  by  a  LENGTH  byte  to  specify  the  number  of
characters  following.  Kermit-11  was  not  always inserting the LENGTH
field. The new  version,  3.49,  will  be  able  to  tell  if  an  older
Kermit-11  is sending in the incorrect format by virtue of the fact that
the first attribute packet that is  sent  is  the  system  id  code  and
operating  system. Since this attribute will always be a short one (2 or
3 characters at most) it is a simple matter to detect the presence of  a
'D'  (for  DEC)  in  the  position  of  the  LENGTH field and set a flag
accordingly. However, in the case of the corrected Kermit-11 sending  to
a  pre  3.49 version, this will not be the case and all attempts to rely
on the transfer of attribute packets will fail.

The dialup service on the VAX 11/785 will be updated on 26-Mar-1985.
Columbia will be sent a tape on 27-Mar-1986.

[e-mail]

------------------------------

Date:     Mon, 24 Mar 86 15:18:00 CST
From:     Mark Vasoll <[e-mail]>
Subject:  OK State Access
Keywords: Okstate

Some of the files recently announced on Info-Kermit (like the new C-Kermit
files) may have been delayed in getting to okstate for UUCP access because
the system that okstate gets them from was down for a couple days.
Everything should be back to normal by the time you read this.

------------------------------

Date: Mon, 24 Mar 86 16:59:02 cet
From:  [e-mail]
Subject: Request for Epson QX10?
Keywords: Apple III, Epson

I am supporting Kermit at the university of Liege, Belgium.  I have a
request from a guy who owns an Epson QX10 (both CP/M 2.2 and 3).  Do you
have a ready version or information for that machine?

Thank you for getting me on the mailing list, I also long await the promised
Apple III version.

A. Pirard
SEGI
Universite de Liege
15, avenue des Tilleuls
4000 Liege  BELGIUM

------------------------------

End of Info-Kermit Digest
*************************
-------
 3-Apr-86 18:45:43-EST,6779;000000000000
Mail-From: SY.CHRISTINE created at  3-Apr-86 18:44:49
Date: Thu 3 Apr 86 18:44:49-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V4 #21
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 03 Apr 1986       Volume 4 : Number 21

Today's Topics:

                     Macintosh Kermit 0.8(34) Available
                           New KERMIT-10 Release
                       Supported Protocol Converters?
                       Datastream Protocol Converters?
                     Using Kermit With FASTLINK Modems?

----------------------------------------------------------------------

Date: Thu 27 Mar 86 17:40:23-EST
From: Frank da Cruz <[e-mail]>
Subject: Macintosh Kermit 0.8(34) Available
Keywords: Mac Kermit

This is to announce Macintosh Kermit 0.8(34).  It includes the fixes that
were made to the system-independent parts of C-Kermit, announced recently,
plus the fixes to the VT102 emulation made by Davide Cervone of the
University of Rochester ([e-mail]), including:

. Blinking block cursor
. A new consistent VT100 font, including boldface & VT100 graphics characters
. Mouse-directed cursor movement with "arrow keys", a`la MacTerminal.

The new version has been tested with IBM 3270 full screen emulators, like
the 7171 running the Yale ASCII package, and with the Mac Plus.  Mac Kermit
seems to work satisfactorily as a full-fledged VT100, boldface included.

The protocol bugs with single-file interruption and packet padding have been
fixed.  The new files are in:

KER:CKMKER.HQX - Macintosh Kermit resource file, in BinHex V4 format.
KER:CKMKER.DOC - New manual chapter (Scribe source in KER:CKMKER.MSS).
KER:CKMKER.BWR - Known bugs & limitations
KER:CKMKER.UPD - List of changes since last release
KER:CKMFNT.HQX - VT100 font in BinHex V4 format
KER:CKMVT1.DOC - List of VT102 features supported and not supported

These files are available via anonymous FTP from CU20B on the Internet,
and via KERMSRV at CUVMA on BITNET, and should be available within a few
days via UUCP from host okstate.  Macintosh Kermit diskettes can also be
ordered for $10.00 each (prepaid) from

Kermit Distribution
Columbia University
Center for Computing Activities
612 West 115th Street
New York, NY  10025

The diskette includes the documentation in plain text format.  The old
version is still available in KO:CKM*.*.

------------------------------

Date: Tue, 25 Mar 86 14:03:48 EST
From: dstevens (David L Stevens) @ sitvxb
Subject: New KERMIT-10 Release
Keywords: Kermit-10

This is to announce the latest version of KERMIT-10.  The changes made are
documented in KER:K10133.MEM.  The KER:K10V3.RNO documentation is still valid.
Please note that you must rename K10MIT.HLP to KERMIT.HLP if you wish to
have KERMIT give you online help.  If there are any problems with this
release please let me know.

 David L. Stevens
 Stevens Institute of Technology
 DSTEVENS@SITVXB

[Ed. - All the Kermit-10 files are in KER:K11*.* and can be obtained via FTP
and KERMSRV (see previous message).]

------------------------------

Date: 21 Mar 1986 11:53:18 PST
From: Billy <[e-mail]>
Subject: Re: Supported Protocol Converters?
Keywords: Protocol Converters

This reader of INFO-IBMPC wants to send files from his PC to a 370 through a
protocol converter. I know there must be Kermits that do this, but don't
know enough to steer him to the right versions.  Is there an "out of the
box" solution to his problem?

[Ed. - The protocol converter must be the Series/1, 7171 or equivalent
running the Yale ASCII Communication Program.  If this user is not using a
supported protocol converter, he will need to use a line-mode TTY
connection.]

------------------------------

Date:     Mon, 31 Mar 86  20:15:38 EST
From:     RAF@NIHCU
Subject:  Datastream Protocol Converters?
Keywords: Protocol Converters

We are going to be getting some Datastream ASCII/3270 protocol converters.
I would like to find out if anyone has any experience using Kermit with such
devices and either MVS or CMS on the IBM 370.

Roger Fajman  <[e-mail]>
National Institutes of Health

[Ed. - Has anyone ever used the Datastream protocol converter?]

------------------------------

Date: Tue, 25 Mar 86 00:28:26 CST
From: Chet Murthy <[e-mail]>
Subject: Using Kermits With FASTLINK Modems?
Keywords: Modems

I have a pair of FASTLINK modems from DCA which support 9600 baud usage..
However, they use an adaptive duplex encoding method to basically avoid
errors completely.  This basically involves packetizing within the modem so
that errors are handled via retries, etc, in the modem.  This is really
nice, but it makes interactive use, and use for file transfer protocols a
real pain in the <expletive deleted>.  The big problem is that it takes a
while to turn the line around when you want to transmit an ACK.  I would
like to run KERMIT thru this modem, and take advantage of the higher
throughput possible with this modem.  There seem to be two possibilities:

    1) use windowing (sliding window protocol)
        This does not seem to be available at the present time.
    2) modify C-KERMIT to support the longer packet size.  This seemed
to be the way to go, and so I did this.  It worked, but there seem to be
more places in the code than I can find where the program uses the fact that
the maxpacksiz is 94.  I modified the #defines in ckcker.h, and recompiled
the whole thing.  I also modified the protocol to where it uses 2 characters
to encode the length.  All of this worked, and I got efficiencies of 87% on
a 1200 baud line thru a pair of Hayes modems.  However, the program seems to
be writing over some of the user interface keyword tables in the process of
running.  I can't seem to find any other places in the code where it could
be using an array, but I'm not sure.  If anyone knows of places in the code
where the packet size is assumed to be small, I would appreciate it if they
could notify me by mail ([e-mail] or [e-mail]).

In addition, if ANYONE has ANY information about using FASTLINK modems for
file transfer on UNIX, I would appreciate hearing from you.  I LOVE mail.

Thanks in advance,

Chet Murthy ([e-mail])

[Ed. - The next version of C-Kermit is expected to include both sliding
windows and long packets.  Release time is not known at this time however.
In the meantime, you can use FTP to GET the file KER:KPROTO.UPD describes
the conversion to long packets in great detail.]

------------------------------

End of Info-Kermit Digest
*************************
-------
 9-Apr-86 16:55:38-EST,24002;000000000000
Mail-From: SY.CHRISTINE created at  9-Apr-86 16:51:46
Date: Wed 9 Apr 86 16:51:46-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V4 #22
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed,  9 Apr 1986       Volume 4 : Number 22

Departments:

  ANNOUNCEMENTS -
    New Kermit-10, BITNET, etc
        Kermit-32 version 3.2.075
        New Release of Tandem Kermit
        Kermit for Apple II UCSD p-System
        Re: Apple Kermit (Pascal and CP/M)

  UNIX KERMIT -
        C-Kermit on HP Integral Problem Solved
        Installing 4C(58) on 2.9BSD
        Kermit and 4.xBSD rlogin
        C-Kermit 4C(58) on the Sequent BALANCE 8000
        Curious Observation re C-Kermit 4C(058)

  MACINTOSH KERMIT -
        MacKermint 0.8 (34) & Mac Plus
        New MacKermit Problems
        Mouse-Activated Cursor in Mackermit 0.8(34): HOW TO..

  MS-DOS KERMIT -
        MS-DOS Kermit and Zenith Z-158
        Problems with Kermit v2.28 jrd/5e

  MISCELLANY -
        Re: Kermit with FASTLINK modems
        C64 Kermit installation experience

----------------------------------------------------------------------

Date:     Wed 9 Apr 86 0:0:0
From:     Anonymous
Subject:  New Kermit-10, BITNET, etc
Keywords: Kermit-10, BITnet

The new DECSYSTEM-10 Kermit release announced in the last digest is in the
files KER:K10*.*, not KER:K11*.*, as stated.  Hope nobody took it seriously
(April Fool, ha ha).

Also, contrary to what it might say below, some of the new files announced
in this digest might not have made it to BITNET KERMSRV by the time you read
this, since we have been having some trouble with our CU20B-CUVMA link.

------------------------------

Date:     Tue, 8 Apr 86 14:17:05 EST
From:     rmcqueen (Robert C McQueen) @ sitvxb
Subject:  VAX/VMS Kermit-32 version 3.2.075
Keywords: VMS Kermit
Cross-Ref: VAX/VMS Kermit, VAX Kermit, Kermit-32 (see also VMS Kermit)

A maintenance/minor developmental release of Kermit-32 is now available.
Kermit-32 version 3.2 provides bug fixes for some of the known problems.

BEWARE:  Version 3.2 only runs on VAX/VMS version 4.0 or later.

The edits in this version include:

      o  Fixed processing of CRCs without 8-bit quoting.

      o  Fix various problems in the help file.

      o  Fixed problems with restoring of the terminal's <CR> and  <LF> fill
         counts.

      o  Fixed a problem  reading  files  with  FORTRAN  carriage  control.

      o  Changed the functionality of the  FINISH  command.   It  will  now
         return to the prompt level, and not exit to DCL.

Robert McQueen
Stevens Institute of Technology

[Ed. - The new files are in KER:VMS*.*, available via anonymous FTP from
CU20B, or via BITNET from KERMSRV at CUVMA.  KER:VMSMIT.HEX is the hexified
task file for the new version.  KER:VMSV31.HEX is the previous version,
which can be used with VMS version 3.]

------------------------------

Date: 27 Mar 1986 0319-EST
From: Tony Camas
Via: LCG.KERMIT@DEC-MARLBORO
Subject: New Release of Tandem Kermit
Keywords: Tandem Kermit

I've uploaded an updated version of the Tandem (yes Tandem) kermit server
as TANDEM.TAL.  It is intended as a replacement for current version.  This
version does three things the old version didn't:

(1) It adds an option, "NOBREAK", which can be of use on noisy lines.
(2) It supports kermit "I" packets, which evidentally did not exist when it
    was created.  This makes it talk to MS-Kermit v2.27 (previously it would
    only talk to v2.26 and before).
(3) It has a prettier banner with a version number, etc.

I've tested this pretty extensively (been working on a tandem project for
several months now) and it works fine.  It's quite possible that the
original author and I are the only people who've ever used this
implementation, but nevertheless, the one being distributed by Columbia
ought to work with current versions of PC kermits.

   Tony Camas
   [phone]

------------------------------

Date: Thu 13 Mar 86 13:24:01-EST
From: Ph. P. Visser, Rekencentrum der Rijksuniversiteit, Groningen, Netherlands
Subject: Kermit for Apple II UCSD p-System
Keywords: Apple II Kermit

Enclosed you will find two diskettes concerning a Kermit version for
Apple II (e) and (+).

The version is made by P. Terpstra of the Laboratory of Biochemics of the
State University of Groningen.  The version is written in UCSD Pascal.
It concerns Apple DOS 3.3 with several interface cards such as:
- Apple Communication Card (ACC)
- California CCS 7710 ASI Card (CCS)
- Hayes Micromodem Card (HMC)
- Apple Super Serial Card (SSC)
- IBM AP2 Serial Card (AP2)

It is a corrected version of the Stevens version.

[Ed. - Thank you, and thanks to Francis Wilson of Columbia Teachers College
for deciphering the disk for us, and to the many other people all over the
world who volunteered to do the same in response to our plea several issues
ago.  The files are in KER:UCA*.* on CU20B (Internet), and UCA* * on CUVMA
(BITNET).  But before you rush off to get this new version, read the
following message.]

------------------------------

Date: Tue 8 Apr 86 17:00:48-EST
From: Francis Wilson <CCIMS.WILSON@CUTC20>
Subject: Re: Apple Kermit (Pascal and CP/M)
Keywords: Apple II Kermit

After having no trouble in the morning using the Pascal Kermit as a terminal
emulator, I did not expect any (bad) surprises, but there were two.

1) The Apple 2e in the Micro Center at TC has a Videx ASIO card; this card
has the same 6551 ACIA as the Apple Super Serial Card, and uses the same
addresses; we have written (Apple CP/M) routines interchangeably for these
cards.  When I tried to use the program, the Kermit would not even change
the baud rate from 19,200, so I couldn't very well use a modem.

[Ed. - Maybe there's a way to set the baud rate outside Kermit, and then
have Kermit use the serial card as it finds it?]

2) On another Apple (with a real Super Serial Card), I tried file transfer
to a PC (unsuccessful) and via modem to a DEC mainframe (also unsuccessful);
in both cases, I successfully used terminal emulation immediately prior to
the attempted file transfer, so it was not a matter of bad connections.

[Ed. - Maybe it's something with parity, and SET PARITY ODD (or whatever)
will make it work.]

In other words, I have followed the instructions as best I can, but I am
not able to make the Kermit program work.  It emulates a (glass) terminal
ok, but does not transfer files.

To make matters worse, for others who want to try do a better job, from
looking at the documentation, specifically, the third documentation file,
it seems that there are files needed to assemble a working version that are
not included in source form (see the .DOC file).


[Ed. - If anyone out there has better luck, let us know!  The address of
the contributors (in Holland) is in the documentation, and they have offered
to provide diskettes.]

------------------------------

Date: Sun 6 Apr 86 11:40:15-EST
From: [e-mail]
Subject: C-Kermit on HP Integral Problem Solved
Keywords: C-Kermit, HP Integral Kermit

        This is part 3 in the ongoing saga of an incompatibility between
C-Kermit (now (057)) and csh when a HP Integral is running the SVR2 ROMs.

        The reason for the C-Kermit crashing when an attempt is made to
escape back to local control has been found.  When C-Kermit connects to tty
it needs to generate a child process (why I don't know).  On the HP Integral
with the new operating system ROMs, the fork to generate the child process
always fails if csh is running, either in the active window or any other
window.  The pid returned by this failed fork is -1.  When escape to local
control is attempted, C-Kermit sends out a kill(-9) to the child process.
Since the pid is -1, the effect of this kill is to kill ALL processes except
0 (the kernel) and 1 (init).

        I think that this is a possible bug in C-Kermit, the not checking
for a failed fork after a child process is created.  Granted it is not
very likely that this situation will occur, but if it did happen on a
system where there are a large number of users it could be quite harmful.
For now the only fix that I have is that people running C-Kermit on
HP Integral's with the new ROMs, is that they do not have csh running
anywhere on that machine when C-Kermit is going to be used.

                                                Gordon Haverland
                                                Box 596
                                                Dawson Creek, B.C.
                                                V1G 4H5
[e-mail]                              Canada

[Ed. - Thanks for finding the problem.  It will be fixed in the next
release.  Meanwhile, those who find their systems unable to create forks
can change the file ckucon.c to check if the pid returned by the fork()
invocation is -1, and if so, to report failure and return.]

------------------------------

From: Vic Abell <[e-mail]>
Date:  8 Apr 1986 1519-EST (Tuesday)
Subject: Installing 4C(58) on 2.9BSD
Keywords: C-Kermit

The standard 2.9BSD distribution and some of the redistributions of 2.9BSD
accomplish 4.2BSD directory compatibility with simulation that is based on
the header file "ndir.h" and the library "libndir".  The current C kermit
distribution, 4C(58), does not follow those conventions.  Of course, one must
also add -lndir to some make rule.  Since we don't use the distributed
Makefile, I am omitting diffs for it and leaving that exercise to the
interested reader's imagination.

As always, I am grateful to Columbia for their efforts with Kermit.

Vic Abell
Purdue University Computing Center
[e-mail]
...!pur-ee!pucc-j!abe

[Ed. - In some cases, it's true that ndir.h should be used.  In others, it's
dir.h.  In either case, the library reference should be made in the makefile
(and it is).  If your 2.9BSD system uses ndir.h rather than dir.h, then in
ckufio.c, the section

> #ifdef        BSD29
> #include <ndir.h>

should be changed to refer to <ndir.h>, or possibly <sys/ndir.h>.  Let's
hear it for consistency.  A warning has been put in the makefile about this.]

------------------------------

Date:  9 Apr 1986 1105-EST (Wednesday)
From: Vic Abell <[e-mail]>
Subject: Kermit and 4.xBSD rlogin
Keywords: C-Kermit

There is an undocumented option on the 4.xBSD rlogin call that must
be used when C Kermit is at the end of a TCP/IP rlogin connection.
The option is "-8" and should be used in the following fashion:

        % rlogin hostname -8
        % kermit

Vic Abell, Purdue University Computing Center
[e-mail], ...!pur-ee!pucc-j!abe

------------------------------

Date:  8 Apr 1986 1935-EST (Tuesday)
From: Vic Abell <[e-mail]>
Subject: C Kermit 4C(58) on the Sequent BALANCE 8000
Keywords: C-Kermit, Balance 8000

I just finished installing C Kermit 4C(58) on the Sequent BALANCE 8000.
It transported without modification, compiled under the -DBSD4 option,
and functions correctly.  I am really impressed with the quality of the
4C(58) release and the ease with which 4.2BSD software can be transported
to the BALANCE 8000.

My compliments to Columbia and Sequent for jobs well done.

Vic Abell, Purdue University Computing Center
[e-mail], ...!pur-ee!pucc-j!abe

------------------------------

Date:     Mon, 7 Apr 86 21:06 EST
From:     [e-mail]
Subject:  Curious observation re C-Kermit 4C(058)
Keywords: C-Kermit

Well, the new Kermit survived its testing period, and as I was installing it
today as our new production version, I noticed that 4C(057)'s executable
image was 168K bytes, while 4C(058)'s image was only 128K bytes.  Both
versions were compiled on the same compiler and the same system, an NCR
Tower running Tower OS version 2.01.  (Both versions were put together
with a "make sys3" command.)

Any idea where the 40K went?

                                        -- Larry Afrin
                                           Dept. of Computer Science
                                           Clemson University

[From Frank - Beats me!  I think I might have made some buffers a little
smaller in some versions, but not 40K worth.  On VAX 4.2BSD, the old and new
versions come out exactly the same size.  On PDP-11 versions, particulary
2.9BSD, some buffer sizes (like for filename expansion) had to be reduced.]

------------------------------

Date: Tue, 1 Apr 1986 16:01 EST
From: Dave Elbon  <[e-mail]>
Subject: MacKermint 0.8 (34) & Mac Plus
Keywords: Mac Kermit

MacKermit (and the keyboard configuration program) don't recognize the
cursor keys and the Enter and Clear keys on the Mac Plus.  I also can't
get the mouse to move the cursor.  Any ideas?  Wait for the next release?

[Ed. - Anybody out there with a Mac Plus to check this on?  Maybe it's
just that the configurator program doesn't know the layout of the new
keyboard, so it works in this case like it does with the keypad -- you can't
see it, but you can still set it.  Anyone want to try this approach and
report back?]

------------------------------

Date: Thu 3 Apr 86 00:42:15-EST
From: Subba Shankar <[e-mail]>
Subject: New MacKermit Problems
Keywords: Mac Kermit

        I recently downloaded the new MacKermit from CU20B with my old
MacKermit, ran Binhex v4 on it, and happily telecommunicated away.
While I find the new font and the terminal emulation features to be a
great improvement, I have found some problems.  MacKermit causes the
system error message with the restart button enabled to be shown
whenever I try to call up the Control Panel Desk Accessory, and the
Transfer to Application menu option causes the Mac to hang.  This is
highly reproducible.

[Ed. -- Hmmm... not by us!  Maybe you have some other programs loaded
(in Switcher, maybe?) that figure into this somehow?  Anybody else out
there seen a problem like this?]

------------------------------

Date:  8 Apr 1986 1949-EST (Tuesday)
From: Vic Abell <[e-mail]>
Subject: Mouse-Activated Cursor in Mackermit 0.8(34): HOW TO..
Keywords: Mac Kermit

The mouse-activated cursor code in Mackermit 0.8(34) is a welcome addition.
I had a little trouble getting it to work, so I am sending this hint to help
others with it.  Here are the steps needed to activate it:

1. Create a settings file.
2. Edit the settings file with CKMKEY.
3. Define the following functions:
        100: \033[A
        101: \033[B
        102: \033[D             (yes, 'D' is correct!)
        103: \033[C             (yes, 'C' is correct!)

To use the mouse-activated cursor from within Mackermit, move the arrow to
the place to which you want to move the cursor; hold down the option and
cloverleaf keys together (the cursor should change to an open box around
the target character); and press the mouse button.  You can press the
option and cloverleaf keys before you move the open box cursor, if you want.

Vic Abell, Purdue University Computing Center
[e-mail], ...!pur-ee!pucc-j!abe

[Ed. - Thanks!  Also, the program comes with a VT100-keypad startup file,
which starts up Mac Kermit for you with the keys configured for you this way
when you double-click on it.  It's in KER:CKMVT1.HQX.  Unfortunately, we
forgot to include it with the other files when the new version was first
announced.  It's there now.  Sorry!]

------------------------------

Date: Wed, 2 Apr 86 00:49:54 EST
From: [e-mail]
Subject: MS-DOS Kermit and Zenith Z-158
Keywords: MS-DOS Kermit, Zenith

I've been having problems with kermit/jrd v.2 and 5e on a Zenith Z-158 with
Hayes 1200B (board) modem. Whenever I escape to local kermit, the connection
is dropped from my end. I have tried connecting to different hosts a Z-150
with a 1200B, and neither has worked. Jrd/2 works fine on a freestanding
modem though, I've heard. It also works fine on a hardwired port at 9600
bps.

The connection problem also happens when I transfer files to the host, at
around the moment when the status screen appears at the local station.

[From JRD: I tried and tried to get this to happen with a real Hayes 1200B
in a Columbia portable and the darned thing just kept working fine. Guessing
time on Hayes switches.  Kermit works 100% on my Hayes 2400 external modem
and I pump maybe 0.5 Mb per day through that combination with never a
problem. My computer is a Zenith 151 too. The 2400 has no switches,
everything is in software, and I tried many combinations to make Kermit drop
DTR. Finally, I wrote a new Kermit command, HANGUP, to save testing time.
Try those switches.  Further thought on the matter, but not much further.
When Kermit is not using the serial port it returns the previous interrupt
address to the UART to leave things tidy. DTR and RTS are left high (on).
Could it be that code at that previous address was reacting to the modem and
dropping DTR? Put another way, could the Hayes 1200B implementation of a
UART and modem adversely react to a change of interrupt address; hardware
troops make those kinds of boo boo's.]

------------------------------

Date:     Fri, 4 Apr 86 11:43:53 EST
From:     Dave Swindell <[e-mail]>
Subject:  Problems with Kermit v2.28 jrd/5e
Keywords: MS-DOS Kermit

I have been using MS-Kermit version 2.28 jrd/5e on and off for the
past few weeks and have observed a few possible bugs.  The first one
is that the local buffering of one's session doesn't seem to work
correctly.  When I try to scroll back through my session (by using the
pg up key), I get a very strange display composed of IBM graphics
characters.  The second problem I noted occured while I was
transmitting a text file from a "functioning" Kermit-10 to my pc.  The
transfer proceded normally, but when I edited the transmitted file, I
noticed several imbedded control-m characters interspurced in the file
which did not appear in the original file.

On the plus side, the VT100 emulation looks real good!  I've tried
running several full screen editors that support the VT100 using
Kermit with great success.  The support for video attributes and the
AVO character set all work nicely.  I also like being able to use the
IBM (or in my case Leading Edge) cursor keys as VT100 cursor keys.  I
have used the new version of kermit both at 1200 and 9600 baud with
sucess, outher than the problems noted above.

[From JRD: Several people with Leading Edge machines report video
difficulties when scrolling back the Connect mode screen.  The model M at
least has a dip switch selecting L.E. Enhanced video or regular.  A friend
had similar video garbage until he switched the machine from unleaded to
regular.]

As a final question, when do you anticipate that sliding window
support will be incorporated into the "production" version of IBM
Kermit?  I've tried to use WKermit over Telenet, but have not had
success.  WKermit seems to get confused when displaying the Telenet
prompts; graphics characters are interspurced into the display.  My
guess is that Telenet is setting the eighth bit of some or all of its
prompt characters to high, and that this is confusing WKermit.

[Ed. - It'll be a while before sliding windows gets into C-Kermit,
maybe a few months.  Meanwhile, you should be able to use WKermit over
Telenet by doing SET PARITY MARK.  Works fine for us.]

Thanks for all your work,

Dave Swindell
BBN Laboratories Incorporated

------------------------------

Date: Tue, 8 Apr 86 21:51:59 pst
From: Gary Mills <[e-mail]>
Subject: Re: Kermit with FASTLINK modems
Keywords: Modems

I have no experience with FASTLINK or any other error-correcting modems,
but there does seem to be a trend to shifting parts of the communication
protocol to hardware.  I use Kermit with 212A modems over switched lines
with variable amounts of noise, and it does perform very nicely, and gets
my files from one machine to another.  However, it seems to me that if a
pair of sophisticated modems are providing error-free transmission, that
Kermit does not need to be used at all.  You should be able to just
"copy" the file from one machine to the other.  Of course, it's unlikely
that normal system commands would do this.  Also, the Kermit user
interface is quite attractive.  Maybe some variation of Kermit with
relaxed error-checking could be used in this instance.  It would also
likely be useful for hard-wired connections.

[Ed. - Maybe this will happen some day.  YMODEM already has such an option.
You still have to be a bit cautious about errors that slip in between the
modem and the computer (wiggly cables, buffer overruns, etc).  But it may
turn out that removing Kermit's errror checking wouldn't speed things up
much anyway, since the bottleneck in many of these modems relates to line
turnaround, in which case only long packets or sliding windows will help.]

------------------------------

Date: Wed, 26 Mar 86 15:07:24 cet
From:  [e-mail]
Subject: C64 Kermit installation experience
Keywords: Commodore 64 Kermit
Cross-Ref: C-64, Commodore 64, (see also Commodore 64 Kermit)

Can you please take note and forward to the authors of C64 Kermit?  I've
just generated version 1.6(49) of C64 Kermit and have some remarks:

1) The kludge factor you use for 1200 bauds is valid only for U. S.  machines
(NTSC). So called International machines (PAL) have other requirements.
Assuming the correction is subtracting 10 decimal from CBM values, this
yields the following values:

1200: 301=$012D
1800: 164=$00A4
2400:  95=$005F
1200 and 1800 bauds have successfully been tested with these values,
but 2400 bauds resisted file transfer.

Also you might include the kluge factor in each speed definition to make all
high speed available through the SET BAUD command.

2) You plan using the serial bus for disk access (TALK ...). I would
strongly advise you against that. Some drives interface cartridges work by
re-vectoring the high level access interface (CHROUT ...) and using their
own low level bus for disk parallel access. You would miss those busses.
Also better not restore the vectors! If your complaint is speed, I'd
recommend to transfer disk data by chunks of say 16 bytes to minimize the
talk-untalk overhead.

3) The DISK command refused service. Patching the module to store a
carriage-return (not a null) at the end of the buffer in routine DOSPRS,
puts things right.

4) The last SET values byte is not correctly SAVEd/RESTOREd.  CPY
#QUOTE+1-ESCP should be +2 or better some equated SETSLEN.

5) If you consider wildcard sends valuable, may I suggest the following
solution. A) open a drive input file whose name is
$:user-specifiled-file-pattern (a la CBM DOS), and secondary address 0.

B) Read this file (BASIC format like) using the following algorithm,
   extracted from COMforth, a wonderful Forth development system
   available here in Belgium.
   Skip 2 bytes.

   BEGIN
     Read 2 bytes, OR <> WHILE ( not double null )
     Skip 2 bytes ( containing file blocks count )
     BEGIN Skip 1 byte ASCII " = UNTIL
     BEGIN Read 1 byte, ASCII " <> WHILE
       copy it to filename buffer
     REPEAT
     BEGIN Skip 1 byte null = UNTIL
     not first block IF ( not drive name )
       Use filename to drive file transfer
     ENDIF
   REPEAT

C) Close file.
Never buy what you can steal. (They say).

I hope to have contributed to a work of patience to which we are heartfully
grateful.
                                        A. Pirard
                                        SEGI
                                        Universite de Liege
                                        15, avenue des Tilleuls
                                        4000 Liege

------------------------------

End of Info-Kermit Digest
*************************
-------
11-Apr-86 12:07:01-EST,13807;000000000000
Mail-From: SY.CHRISTINE created at 11-Apr-86 12:05:30
Date: Fri 11 Apr 86 12:05:30-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V4 #23
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 11 Apr 1986       Volume 4 : Number 23

Departments:

  ANNOUNCEMENTS -
        Many New Kermit Versions from the UK
        Kermit for Sperry 90/60 with VS9 from WPI

  MISCELLANY -
        Setting Kermit-32 Up As A Server
        Kermit-11 Known Problems Update
        Kermit v2.28 jrd/5e on the Leading Edge Model D
        Modems and Error Correction, etc.
        New Source for OS9 and Tandy CoCo Kermit Diskettes
        File Renaming Problem in C-Kermit?

----------------------------------------------------------------------

Date: Thu 10 Apr 86 18:23:01-EST
From: Christine M Gianone <[e-mail]>
Subject: Many New Kermit Versions from the UK
Keywords: England Kermits

This is to announce new Kermit versions submitted by Alan Phillips of
Lancaster University, UK.  The files are described by him as follows.
Each group is indicated by the wildcard file specification that will fetch
the files via FTP or NFT from CU20B, except they should be preceded by KER:.
On BITNET, they may be fetched from KERMSRV at CUVMA with the names
indicated (without the KER:, but also without the dot).

BBC*.*
        These files are version 1.30 of Kermit for the Acorn BBC Micro.  Old
files have been replaced.  BBC130.ANN contains the announcement details.
There are 2 HEX files for this version, covering disc based and EPROM based
variants.  The .ADE file contains a concatenation of the individual source
files.

C86XFU.*
        These files are the Kermit-86 for the Future FX20/FX30 machines sent
in by Toby Chabot of Birmingham University.  The code will run under either
CP/M-86 or Concurrent CP/M-86.

C86XR2.*
        These files are a variant of the existing Kermit-86 for the DEC
Rainbow, sent in by Mark Woollard of the Animal and Grassland Research
Institute.  A SET BAUD command has been added.

CKMKB*.*
        These files are two separate UK keyboard settings files for the
Macintosh.  CKMKBD.* is from Sak Wathanasin of Sussex University; CKMKB2.*
is from Phil Jimmieson of Liverpool University.  The latter set of files
includes an introductory guide to Mac Kermit 0.8(33) in MacWrite format.

CN8*.*
        These files form a Concurrent CP/M-86 implementation for the
Honeywell Multi System Executive and clones (Argos Pro PC, Daisy PCi, Fallon
2000, FTS PCi, and Orion PCi) sent in by Mark Hewitt of Birmingham
University.  This set is based on the existing Kermit-86, with a new device
dependent file and a lot of changes to the UTL file.  The version uses
the PRO, FIL, TRM, and CMD files from Kermit-86 unchanged.

CP4*.*
        Kermit-80 implementations:

CP4380.HEX      Research Machines RM 380Z
CP4ADV.HEX      North Star Advantage
CP4APC.HEX      Apple II with Z80 Softcard/CPS serial card
CP4BBC.HEX      Acorn BBC Micro with Z80 second processor
CP4BRA.HEX      Superbrain, using auxialiary port
CP4BRM.HEX      Superbrain, using main port
CP4COM.HEX      Comart Communicator
CP4CIF.HEX      Cifer 1886
CP4CRO.HEX      Cromemco
CP4HOR.HEX      North Star Horizen without SIO board
CP4TOR.HEX      Torch series

        The CP4SYS.ASM and CP4TYP.ASM files contain all the system dependent
code for the above versions.  Authorship of the versions is as follows:

380, APC, BBC, ADV      Brian Robertson, Aberdeen University
CRO, HOR, COM           Andrew Cole, Leeds University
BRA, BRM, TOR, CIF      Bertil Schou of Loughborough University

        Bertil Schou of Loughborough performed the Herculean task of
co-ordinating the developments and putting the results together into the SYS
and TYP files.  Some further implementations are on the way.

GECKER.*
        These files are version 2.1 of Kermit for the GEC 4000 series from
Martin Loach of Rutherford Appleton Laboratories.  These replace the old
GEC*.* files.

MDS*.*
        These files are some updates and fixes to the MDS set for Intel MDS,
sent in by Paul O'Hare of the Open University.  Bugs have been fixed and the
documentation has been expanded.  The other files for this version are
unchanged.

CUC*.*
        These files are the latest versions of a C-Kermit from Chris
Kennington, University College London.  Based on the original Kermit of the
protocol manual, the code has been adapted to be extremely portable with
little work needed.  The diagnostic facilities have been expanded
considerably too.  File CUCLKV5.C is a system dependent module for UNIX
system V, added by Icarus Sparry of Bath University.

UCJ*.*
        These files from Henry Balen of Lancaster University, are an
adaptation of the Terak UCSD p-System Kermit for the Joyce Loebl Magiscan 2
image processor.  8th bit prefixing has been added and a number of other
features.  The result should be easily ported onto other UCSD systems.  The
.TXT file contains a concatenation of the sources.

UMKERMIT.*
        These files are a version of the original Kermit in the Protocol
Manual for a U-Microcomputers U-MAN 1000 under CP/M-68k.  The files are
contributed by Icarus Sparry of Bath University.  Work on this version is
still in progress, so currently the implementation is not perfect and is
supplied very much on an "as is" basis.  Icarus would welcome contact from
anyone interested in this implementation and will co-ordinate any
developments:  his UK network address is [e-mail]63.

[Ed. - Many thanks to Alan for these versions, and for his dedicated work
in coordinating the Kermit goings-on of the UK, and for distributing Kermit
on UK networks, and on diskettes and tapes in the UK.]

------------------------------

Date: Wed 9 Apr 86 17:24:45-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit for Sperry 90/60 with VS9 from WPI
Keywords: Sperry

SP9KER is Kermit for the Sperry 90/60, written by Ben Thompson of
Worcester Polytechnic Institute, Worcester, MA.

The program only runs as a server since the SPERRY 90/60 can not initiate use
of an RTIO line other than the terminal line itself.  It accepts no interactive
commands, just escape to to your computer's command mode and initiate a
command.  Implemented commands are: GET, SEND, and BYE.

KER:SP9KER.SRC is the IBM-like assembler source file, KER:SP9KER.DOC is the
documentation.

Thanks to Al Johannesen for submitting the program.

------------------------------

Date: Thu, 10 Apr 86 20:38:59 EST
From: rmcqueen (Robert C McQueen) @ sitvxa
Subject: Setting Kermit-32 Up As A Server
Keywords: Kermit-32

Kermit-32 can be set up as a server in the following manner:

$ KERMSRV := $SYS$SYSTEM:KERMIT SERVER

Then just issue the KERMSERV command.  Kermit-32 will accept any legal
Kermit command in this manner.  You could just define a KERMIT command
in your LOGIN.COM file and then give a DCL command of the format:

$ KERMIT command

Which will cause Kermit-32 to be invoked and the command processed.

Kermit-32 has had initialization file processing and a TAKE command since
version 3.1.  When Kermit-32 starts it will automatically process
VMSKERMIT.INI;0 or if that does not exist it will process the file that the
logical name VMSKERMIT points to.  If you have a command procedure that you
would like Kermit-32 execute you can give either the TAKE command followed
by the file specification or "@" followed by the specification.

Robert McQueen
Stevens Institute of Technology

[Ed. - Thanks, Bob!  We'll add this hint to the beware file, too.]

------------------------------

Date: Mon, 7 Apr 86 12:57 EST
From: <[e-mail]> (brian nelson)
Subject: Kermit-11 Known Problems Update
Keywords: Kermit-11
Cross-Ref: K-11, PDP-11 Kermit (see also Kermit-11)

On RT11 FB systems with a large number of devices, Kermit can displace the
USR (force it to swap) and crash when accessing the USR from the higher
addressed overlays in Kermit. The fix for something like this may not be
practical; it can be worked around by UNLOADING and REMOVING unneeded device
drivers from lowest address to higher addresses (to prevent fragmentation of
background memory). If you run K11RT4.SAV on a FB system and find either (1)
The program crashes on file transfers or (2) KMON says the save image is too
large, then remove the unneeded drivers and set the USR to swap.

------------------------------

Date:     Thu, 10 Apr 86 21:31:36 EST
From:     Dave Swindell <[e-mail]>
Subject:  Kermit v2.28 jrd/5e on the Leading Edge Model D
Keywords: MS-DOS Kermit, Leading Edge

In the last digest, I reported a problem scrolling back through displayed
text using Kermit V2.28 jrd/5e on my Leading Edge Model D.  As it turns out,
Kermit appears to work just fine; the problem appears to be due to some kind
of interaction between the new Kermit and a resident program named INT10
used in conjunction with the Hercules graphics card (and clones!).  When I
install INT10 on my LE, I can't use the scrolling features in the new
Kermit.  When this program is removed, things work fine.  In that INT10, as
its name implies, affects interrupt processing, I assume that it some how
gets in the way of the mechanism jrd/5e uses to scroll through displayed
text.

Other than this problem, I have had no other display-oriented problems using
the new release on my LE model D.  The model D comes complete with two
graphics adaptors on the motherboard; a monochrome/Hercules port and a
standard IBM CGA port.  I have tried jrd/5e using both ports (at different
times!) and have had no problems (once INT10 was removed).

Sorry I didn't think to remove the memory resident programs I was using
before I reported the problem!  By the way, I am using NANSI.SYS as my
console driver on the LE.  It does not appear to interfere with Kermit.

Dave Swindell
BBN Laboratories Incorporated

------------------------------

Date: Thu, 10-Apr-86 10:54:14 PST
From: vortex![e-mail] (Lauren Weinstein)
Subject: Modems and Error Correction, etc.
Keywords: Modems

It is a fallacy to assume that when error correcting modems are in place you
don't need error detection/correction in the software.  In practice, not
only do noise errors creep in between the modems and the computers, but the
problems of buffer overflow and flow control related errors, on both sides,
can be quite serious, particularly at "higher" speeds.

In my own experiments with various software, I've found that removing or
even relaxing the per-packet error checking characteristics of software when
using error-correcting modems generally does little or nothing to increase
throughput, and in fact you frequently end up with decreased throughput
since flow control problems (and the resulting need to resend large
quantities of data) can be intense on even slightly noisy phone lines or
when dealing with even moderately loaded systems.

--Lauren--

------------------------------

Date:  Thu Apr 10 09:57:06 EST 1986
From: dolqci!irs3!scsnet![e-mail]
Subject: New Source for OS9 and Tandy CoCo Kermit Diskettes
Keywords: Os9 Kermit, Tandy Kermit

This is to announce that disks containing the Tandy/Radio Shack RS-DOS
kermit and os9 kermit can be obtained by sending $5.00 for
each version to:

  Mark E. Sunderlin
  1430 Greystone Terrace
  Winchster, Va. 22601

The RS-DOS version is provided on standard RS-DOS format. The os9 version
is provided on either 35 or 40 track CoCo os9 format.  Please state which
versions you want and for os9, what format.

Each disk contains complete source as up to date as possible, currently
RS-DOS kermit version 1.1 and os9 version 1.6.  Also on each disk is the
full documentation.  Binaries will be placed on the disks on request.

The RS-DOS verson in in EDTASM+ assembler, but EDTASM+ is not needed to
create a binary as BASIC program is provided to generate the binary.  The
os9 version in written in Microware 'C'.  An 'S' record file for os9 level I
will be placed on the disk on request for those who do not have the 'C'
compiler.

Please note that this is a PRIVATE project and is in no way related to the
IRS or any other government agency.

------------------------------

Date: 6 Apr 1986 0306-EST
From: [e-mail]
Subject: File Renaming Problem in C-Kermit?
Keywords: C-Kermit

I have discovered a problem when sending files from a BSD 4.2 system
to a V7 system with both machines running C-Kermit version 4C(057).

The file names on the BSD system were greater than 14 characters and the
first 14 characters of several of the file names were the same.

The BSD Kermit was running in server mode and was set for literal file names.
The V7 Kermit was set for literal file names and file warning on.

The first file came over ok, but when the second file came over, Kermit
discovered that the file existed and renamed it by replacing the end of
the file name with ~1.  The new file name was still longer than 14 characters
and the new file clobbered the previous file!

Was this fixed in version 4C(058)?  Should Kermit check for the existence of
the altered file name before doing the create?

[Ed. - If the behavior you report is true, the cause isn't obvious.  The
"make-new-name" function, znewn(), chops the last 3 characters off the name
before adding the "~1" suffix.  In any case, the behavior wasn't changed in
edit 058.  We'll look into in more detail later.  For now, your message has
been added to the beware file.]

------------------------------

End of Info-Kermit Digest
*************************
-------
15-Apr-86 18:07:03-EST,8308;000000000000
Mail-From: SY.CHRISTINE created at 15-Apr-86 18:06:18
Date: Tue 15 Apr 86 18:06:18-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V4 #24
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 15 Apr 1986       Volume 4 : Number 24

Departments:

  ANNOUNCEMENTS -
    MS-DOS Kermit 2.29 Is Even Closer To Being Ready
    New Release of TRS-80 Model 4 Kermit

  MISCELLANY -
    Sending Break on Mac+ from Kermit (several messages)
    DEC-10 Kermit Files

----------------------------------------------------------------------

Date: Tue 15 Apr 86 14:25:17-EST
From: Frank da Cruz <[e-mail]>
Subject: MS-DOS Kermit 2.29 Is Even Closer To Being Ready
Keywords: MS-DOS Kermit

Joe Doupnik's latest prerelease of MS-DOS Kermit 2.29 is available for
evaluation.  It is called "2.28 jrd/5g 13 April 85".  It has been tested by
us on the IBM PC family and compatibles (not including the new PC
Convertible, which is probably NOT compatible), the DEC Rainbow, and the
HP-150, and by Ron Blanford at the University of Washington on the NEC APC,
and also on the Intel RMX system by Jack Bryans at Cal State.

Aside from fixes for the bugs that have been reported in earlier
prereleases, 5g includes dynamic memory sizing in the IBM PC version -- it
uses whatever memory is available for scrolling memory, rather than
requiring that a certain amount be available, so that it can fit in smaller
memories, like on the PCjr (does anyone have a real PCjr to test this on?).
It also has a new screen-dump feature (again, on the IBM version only),
activated by <esc-char>F.  In case you have missed earlier postings about
this new release, it also incorporates nearly complete VT102 terminal
emulation for the IBM PC family, and full DOS 2.0 compatibility (a full
DOS path can be used in any file specification).

The .BOO file for the IBM version is available on CU20B via anonymous FTP as
KER:MSJRD5G.BOO, and it is also available on BITnet from KERMSRV as CUVMA as
MSJRD5G BOO.  The other versions are available on CU20B only, via FTP, in
the directory <KERMIT-MS>.  BOO files have been built for the Rainbow
(MSVRB1.BOO) and the HP-150 (MSVHP1.BOO).  The <KERMIT-MS> directory also
contains 8-bit binary .EXE files for these versions.  The new documentation
is not ready yet, but use of "?" in commands will produce menus whenever
needed.

The operation of the new version on the other IBM-PC-Incompatibles supported
by previous releases of MS-DOS Kermit has not been tested; these include:

 MSVAP3  NEC APC 3
 MSVAPR  ACT Apricot
 MSVDM2  DECmate-II or III with MS-DOS option
 MSVEZP  Z100 with EZPC board
 MSVHPX  HP 110, Portable
 MSVM24  Olivetti M24
 MSVMBC  Sanyo MBC
 MSVTIP  Texas Instruments Professional
 MSVV90  Victor 9000/Sirius 1
 MSVWNG  Wang PC
 MSVZ10  Z100

If you have one of these PCs, and can make an FTP or DECnet connection to
CU20B, or you are directly on BITnet, and you're willing to try out the new
release on your system, please send a note to Info-Kermit-Request (or simply
Kermit) at CU20B, and we'll get the necessary files to you.  You should be
able to mail directly to CU20B from both the Internet and BITnet.  Those
versions that have not been tested within the next week or two will be
distributed with the old .BOO files until positive reports are received.

P.S. The network and disk problems that have prevented us from updating the
Kermit collection on BITnet have been fixed, and KERMSRV at CUVMA is again
up to date.

------------------------------

Date: Mon 14 Apr 86 17:28:04-EST
From: Frank da Cruz <[e-mail]>
Subject: New Release of TRS-80 Model 4 Kermit
Keywords: TRS Kermit

Announcing TRS-80 Model 4(p) KERMIT version 5.0 for TRSDOS 6.x, from Gregg
Wonderly at the Oklahoma State University Department of Computing and
Information Sciences.

This is an advanced Kermit derived from TRS-80 Kermit, which was in turn
derived from CP/M-80 Kermit.  Several new features were added since version
4.0 (March 85), including Remote Server Commands, and lots of cleaning up
and rewriting.

The files are in KER:M4*.*, including source in KER:M4*.ASM, and:

M4MIT.HEX -- Hexified object module
M4MIT.NR  -- Nroff source for M4MIT.DOC
M4MIT.DOC -- Documentation
M4MIT.HLP -- This file
M4BOO.BAS -- Basic program for converting the hex file to a runnable program

------------------------------

Date:  Sun, 13 Apr 86 01:36 MST
From: Barry Margolin <[e-mail]>
Subject:  Sending Break on Mac+ from Kermit
Keywords: Mac Kermit

What do I have to do to Macintosh Kermit 0.8(33) (I'll be upgrading to
0.8(34) soon, if that helps) so that I can send a break.  The Mac+ does not
have an Enter key next to the Space bar, and the keypad's Enter key sends a
Line Feed.

On a related topic, it would be nice if someone would update KermKey so that
it detects whether it is being used on a Mac+, and display correct keyboard
layout.
                                        barmar

[Ed. - See following messages.]

------------------------------

Date:     Mon, 14 Apr 86 16:49 EST
From:     (Davide P. Cervone, User Services Consultan ...) <[e-mail]>
Subject:  Break key for MacKermit
Keywords: Mac Kermit

I don't have a Mac+ to try this on, but on a Mac, if you bind F126 or F127
to any key, that key will send a "break".  F127 is a longer break than F126
(in version .8(34) the cursor should stop flashing for a few seconds).

About the Kermit keyboard reconfigure program, I agree that it would be nice to
be able to detect the different keyboards.  It would also be nice to have a
keypad diagram.  I'm not sure whether it is possible to detect which kind of
keyboard/keypad configuration is being used however.

                                        Davide P. Cervone

------------------------------

Date: Mon 14 Apr 86 15:39:27-EST
From: Robert Cartolano <[e-mail]>
Subject: Re: Sending Break on Mac+ from Kermit
Keywords: Mac Kemrit

For now, you may still use the CKMKEY 0.8 (6) to configure the Mac Plus
keyboard.  I have done it myself.  The function F126 has been defined as the
break, and you can define it as the enter on the older Macs with no problem.
For the Mac Plus, do the following:

    - Run CKMKEY 0.8 (6), and open a file.
    - Select KEYS... from the SET menu.
    - Press the Enter key on the Mac Plus keyboard.
    - Insert the cursor into the keyboard map number, and
      type 126.
    - Click on the SET FUNCTION KEY button.
    - Quit and Save.

I have been able to configure every key on the MacPlus keyboard, including
the cursor keys, in this manner.  You just have to make sure you are hitting
the right key, since you can't see the key on the screen.

Rob Cartolano
CUCCA User Services.

------------------------------

Date: Mon, 14 Apr 86 10:25:58 est
From: Mike Ciaraldi  <[e-mail]>
Subject: DEC-10 Kermit Files
Keywords: DEC-10 Kermit
Cross-Ref: DECsystem-10 (see also DEC-10 Kermit)

I tried to access DEC-10 Kermit over the Arpanet today.  There was no "DOC"
file.  All the "MAC" and "BLI" files, which I assume are the source code in
Macro and Bliss, are messed up.  I tried to get them in ASCII mode, and was
told they are not 7-bit files.  I then tried to transfer them in Tenex mode,
and got something that wasn't human-readable.  The only ASCII file I could
find was the "MEM" file, which was a list of patches.

Is this a mistake, or is DEC-10 Kermit being retired or updated?

I need to bring Kermit up on a DEC-10.  Can I use the DEC-20 version
instead?  I checked the 20 documentation, and it doesn't say it will run on
the 10.

Thanks for any help you can give me.

Mike Ciaraldi
University of Rochester
ciaraldi@rochester

[From Frank - Whoops, you're right.  In fact, the files were stored in a
strange way, that was perfectly OK for our system, but that confused our FTP
server.  I've changed the bytesize from 36 to 7 for all these files, and you
should now be able to FTP them without further problem.  And no, you cannot
run DEC-20 Kermit on a DEC-10 machine.]

------------------------------

End of Info-Kermit Digest
*************************
-------
21-Apr-86 17:49:49-EST,9608;000000000000
Mail-From: SY.CHRISTINE created at 21-Apr-86 17:48:51
Date: Mon 21 Apr 86 17:48:50-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V4 #25
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Mon, 21 Apr 1986       Volume 4 : Number 25

Departments:

  ANNOUNCEMENTS -
        New Kermit Versions from Lancaster University

  MISCELLANY -
        Kermit-MS 2.28 jrd/5g on PCJr
        BOO Files
        Bug in MacKermit VT102 Emulation
        Multiple Parameters in MacKermit VT100 Emulation
        Macintosh Kermit Recieve Dialog Box

----------------------------------------------------------------------

Date: Wed 16 Apr 86 16:56:06-EST
From: Christine M Gianone <[e-mail]>
Subject: New Kermit Versions from Lancaster University
Keywords: England Computers

This is to announce more new Kermits from Alan Phillips of Lancaster
University, England.

VME*.*
        These files are the Kermit version 1.00 for ICL 2900 systems running
the VME Operating System (also known as VME2900 and VME/B - all identical).
The version comes from the South West Universities Regional Computer Centre
(SWURCC) at Bath University, UK.  The source is written in "S3".

CYB*.*
        These files are a new Kermit version 1.00 for the CDC Cyber systems
running NOS 2.2, sent in by A.V. Le Blanc of the University of Manchester
Regional Computer Centre (UMRCC).  The version is written in Compass, and is
supposedly more useful to other sites than the Texas University version,
which is highly site specific.

        Cyber Kermit is a version of Kermit which runs on a CDC mainframe
under the NOS-2 operating system.  It runs only as a remote Kermit and has
moderately advanced server capabilities.  File transfer uses a 7-bit line;
binary files can be transferred only by using a bit-prefix.  The program is
in assembler (COMPASS 3.6) and requires a field length of 2,922 (decimal)
words, including all system library routines and I/O buffers.

FLX*.*
        These files are a Kermit for the Flex 9 systems, written at Brighton
Polytechnic and sent in by Peter Morgan.  The source is written in assembler.

[Ed. - These files are available in KER: via ARPANET on CU20B, and via
BITNET at CUVMA through KERMSRV.  Thanks once again to Alan Phillips of
Lancaster University, UK and to those who have contributed these Kermit
versions.]

------------------------------

Date: Wed 16 Apr 86 08:20:45-CST
From: Rob Pettengill <[e-mail]>
Subject: Kermit-MS 2.28 jrd/5g on PCJr
Keywords: MS-DOS Kermit
Cross-Ref: IBM PC Kermit, PC Kermit, MS-DOS (see also MS-DOS Kermit)

I have tried out the new Kermit on:
* 640k IBMPC with NEC V20
* 128k IBMPCJr
And found normal operation at 1200 baud in Tops20 emacs, and both
ascii and binary file transfers.  The only anomaly that I have observed
so far is that when the new kermit starts up on the PC jr, a warning
message, "unrecognized baud rate" is displayed.  My mskermit.ini file
sets the baud rate to 1200 and that works fine.  I haven't checked but
I assume that msjrd5g.exe was compiled with a default baud rate (9600?)
higher than the Jr's serial port can handle.

Thanks for the good work - I had been about to send off a message asking
if anyone knew how to get the new ms-kermit running on the jr!

-rob

[Ed. - Kermit leaves the serial port alone.  It may be that setting the baud
rate to something specific initializes the serial port the first time after
you turn the machine on.]

------------------------------

Date: Mon, 21 Apr 86 13:27:30 est
From: Doug Snow <[e-mail]>
Subject: BOO Files
Keywords: BOO files

I hope this ends up being a question of general interest.  I recently
obtained the beta version of mskermit 2.29 from kermsrv at cuvma on bitnet.
However, this comes in boo file format and this is something that I'm not
familiar with. A bit of exploration on kermsrv found me a file called
m4boo.bas.  I tried to run this program on a number of copies of msjrd5g
only to consistently get 'unexpected eof encountered' (+/- ) Well, I'm
really just guessing as to whether or not this is the program I want... can
you help? How do I get the boo file to exe format, what does boo represent
(bootable?).  Any help would be greatly appreciated.

[Ed. - BOO-format is an encoding we use for making an 8-bit binary file,
such as an MS-DOS .EXE file, printable so that it can be sent through
electronic mail, put on ANSI or OS labeled tapes, etc.  The encoding is more
efficient than straightforward 2-for-1 hex encoding.  A BOO file (BOO is
short for bootstrap) has a 4-for-3 encoding, and in addition repeated zero
bytes are compressed.  The result for a typical executable program image is
about the same as -- and often smaller than -- the orginal binary file.  BOO
files are made using the program MSBMKB.C, and are decoded in one of two
ways: (1) On the fly, during download, using the pair of programs MSBOOT.FOR
on the mainframe and MSBPCB.BAS on the micro, or (2) after download by some
other method, using MSBPCT.C (fast) or MSBPCT.BAS (slow).  Downloading of
BOO files is described in detail in the MS-DOS chapter of the Kermit User
Guide.]

------------------------------

Date: Tue, 8 Apr 86 16:29:29 -0200
From: Bj|rn Larsen <[e-mail]>
Subject: Bug in MacKermit VT102 Emulation
Keywords: Mac Kermit, Terminal Emulation

There is a bug in the way that the MacKermit VT102 emulator handles the SGR
escape sequence.

If MacKermit receives the escape sequence "<ESC>[7m", it sets the graphic
rendition to reverse. If it receives "<ESC>[;7m", it does not.

I don't have the ANSI standard available, but in the VT100 Users Guide,
p. 3-14 it says:

        Character Attributes

        ESC [ Ps;Ps;Ps;...;Ps m

        Ps refers to a selective parameter. Multiple parameteres are
        separated by the semicolon character (073 octal). The parameters
        are executed in order, and have the following meanings:

        0 or None       All attributes off
        1               Bold on
        4               Underscore on
        5               Blink on
        7               Reverse video on

        Any other parameters are ignored.

This implies that "<ESC>[m" should be interpreted as "All Attributes off".
This is also the way MacKermit works.

But then, "<ESC>[;7m" should first turn off all attributes, then turn on
reverse.  MacKermit doesn't.

This misfeature makes it difficult to use a Mac as a terminal against a VAX
if you wish to use the EVE editor (or other VAXTPU programs).  Since EVE
uses reverse video to display your select region, you are in for some big
troubles.

Since we use both EVE and VAXTPU heavily, a new version of MacKermit would
be most welcome.

[e-mail]         Bj|rn Larsen
                                                System Manager,
                                                Unversity of Oslo,
  Computers never make misteaks  ;-)            Norway.


[Ed. - See message below...]

------------------------------

Date:     Tue, 15 Apr 86 15:23 EST
From:     (Davide P. Cervone, User Services Consultan ...) <[e-mail]>
Subject:  Multiple Parameters in MacKermit VT100 Emulation
Keywords: Mac Kermit, Terminal Emulation

This is a known bug.  The documentaion I sent to columbia states:

     o  In escape sequences where multiple parameters are allowed, only the
        first is used; that is, ESC[p1;p2;...pn c  will process only p1 (e.g.,
        ESC[0;7m is processed as ESC[0m; this is not consistent with VT100
        specifications). [apparently, this never made it into the BWR file]

In the escape sequence ESC[;7m, the first parameter is 0 (by default),
hence MacKermit only does ESC[0m and ingnores the second number.  This is
a problem, and I know it affects TPU.

The problem was inharent in the original design of the VT100 emulator for the
MAC, which made no provisions for more than two parameters for any of its
commands, and only used one for those that usually only supply one.  At the
time I re-worked the VT100 emulator, I noted the problem, and debated whether
to fix it, but it would have required re-writing of a major sort.  We did not
have VMS4.2 running at that time, and MacKermit worked with EDT, so I figured
it would be "safe" for a while.  Alas, I should have know.  I like to use TPU,
too, so I expect I'll fix it sometime, but not in the immediate future.  There
may be an easy fix to accept TWO parameters for ESC[p1;p2m, which would fix
your current problem, but not the general one. I will look into it...

                                        Davide P. Cervone

P.S. this is not a new bug, it existed in the old version of MacKermit as well.

------------------------------

Date: 14 Apr 86 18:55 EDT
From: (David HM Spector) <[e-mail]>
Subject: Macintosh Kermit Recieve Dialog Box.
Keywords: Mac Kermit
Cross-Ref: MacKermit, Macintosh Kermit (see also Mac Kermit)

The Recieve-file dialog box in the current (and previous) versions of Macintosh
Kermit needs to be increased to the size of the send-file dialog box (or
larger).  Currently, the dialog box is mal-formed and won't work with HFS too
well.  That is not to say that Macintosh Kermit doesn't work with HFS,
as far as I can tell it works very well, just the dialog box is too small.

                        David

[Ed. - Noted.]

------------------------------

End of Info-Kermit Digest
*************************
-------
24-Apr-86 17:28:07-EST,15658;000000000000
Mail-From: SY.CHRISTINE created at 24-Apr-86 17:26:24
Date: Thu 24 Apr 86 17:26:24-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V4 #26
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 24 Apr 1986       Volume 4 : Number 26

Departments:

  ANNOUNCEMENTS -
     New PDP-11 Kermit
     Prerelease Test Versions of MS-DOS Kermit 2.29 More Widely Available

  MS-DOS KERMIT -
     MSJRD5G on Olivetti-M24 with Keyboard 2
     Bugs in MS-DOS Kermit jrd5g
     Kermit's Mode Line: A Treatise.

  MISCELLANY -
     SmartTeam Modem Problem.
     New PC Compatible (Laptop) Modem
     SCO XENIX V AND C-KERMIT 4C(58)?
     Apple II CP/M Kermit Diskette?
     Kermit-10 Problem and Fix
     Re: Info-Kermit Digest V4 #25, PCJr Baud Rate Detection

----------------------------------------------------------------------

Date: Tue 22 Apr 86 11:45:27-EST
From: Frank da Cruz <[e-mail]>
Subject: New PDP-11 Kermit
Keywords: PDP-11 Kermit

Announcing version 3.50 of PDP-11 Kermit for RSX-11/M, RSX-11/M-Plus, IAS,
RT-11, RSTS/E, TSX+, P/OS, and Pro/RT from Brian Nelson of the University of
Toledo, Toledo Ohio ([e-mail]).  The major changes include
addition of support for long packets and a mechanism for controlling dialout
modems.  In addition, many commands have been added, many bugs fixed, etc
etc, since the last release, 2.29, July 1985.

The new files are in KER:K11*.*, available via anonymous FTP from host CU20B
on CCnet and the Internet, and via KERMSRV at CUVMA on BITNET.  There are
107 files, occupying a total of about 3.7 megabytes.  The hexified task
images (or otherwise runnable program images) are in KER:K11*.HEX, one for
each system.  The manual is in KER:K11USR.DOC (and .RNO for the Runoff
source).  The file KER:K11FIL.DOC lists all the files and explains what they
are.  You might want to read this file before transferring any of the
others, to avoid swamping the networks with files you don't really need.

Brian will be running a session on Kermit at Dallas DECUS, Tuesday, April
29, at 10:00am concentrating on the PDP-11 and other DEC versions.  He has
also written an article which will be in the June issue of The DEC
Professional.

------------------------------

Date: Tue 22 Apr 86 11:45:27-EST
From: Frank da Cruz <[e-mail]>
Subject: Prerelease Test Versions of MS-DOS Kermit 2.29 More Widely Available
Keywords: MS-DOS Kermit

By popular demand, prerelease test versions of Joe Doupnik's new release of
MS-DOS Kermit are being placed in the regular Kermit distribution.  For now,
only the .BOO files will be available, and only for those versions we have
.BOO files for, which have been tested to some degree.  They will be placed
in KER:MST*.BOO ("T" for Test), and from there they will make their way to
BITNET and other distribution areas.  For starters, we have MSTIBM.BOO for the
IBM PC family and compatibles, MSTRB1.BOO for the DEC Rainbow, and MSTHP1.BOO
for the HP-150.  The sources are not available in this way.  Those who wish to
try out the new versions are encouraged to do so, and report any problems back.
Our goal is to have a final release as soon as possible, and we hope that these
programs are very close to final form.  Any additional commands or enhancements
will have to wait till a subsequent release.

------------------------------

Date: Thu, 22 apr 1986, 08:45 B
FROM: <[e-mail]>
Subject: MSJRD5G on Olivetti-M24 with Keyboard 2
Keywords: MS-DOS Kermit, Olivetti-M24

Hi, we are using MSJRD5G on an Olivetti M24 with keyboard 2. It works very
fine on all speeds up to 9600 Baud. Terminal Emulation (VT102) is ok and
works without problems with the VAX/PDP-EDT editor and a 3270 protokol
emulator. Long live the FROG and his supporters !!!!

I've got only two questions. The first is more important than the second:

 1.) On the Olivetti "keyboard 2" the cursor-keys and the keys
     2 4 6 8 on the separate numeric keypad seem to be "hard/soft-
     wired" to send the same SCAN-codes. Also the keys "SCTPRT" and
     "HELP" doesn't seem to send any SCAN-Code at all.
     This is the only point that prevent the VT102 Emulation to be
     complete (from my point of view). My request (very urgent) is:
     Has anybody out there got the source code for the MS-DOS 2.11
     terminal drivers (esp. KEYBGR) and is willing to send it to
     me?

 2.) I thought that MS-Kermit V2.29 would have long packet and or
     sliding windows. Since I haven't seen them on MSJRD5G I may
     have been wrong all the time. Anybody to confirm?

    Thanks a lot in advance

     Martin Knoblauch
TH-Darmstadt, D-6100 Darmstadt, West Germany
EARN/BITNET: <[e-mail]>

[Ed. -  Long packets and sliding windows will not be included in MS-DOS
2.29.  These features will probably be implemented in C-Kermit first, which
in turn may eventually absorb MS-DOS Kermit.]

------------------------------

Date: 21-APR-1986 14:37:00
From: [e-mail]1
Subject: Bugs in MS-DOS Kermit jrd5g
Keywords: MS-DOS Kermit

Two points about the latest mskermit:

   a) (this is rather obscure) if you SET MODE OFF, then SET MODE ON,
       then SET MODE OFF again, the mode line does not disappear, it just
       becomes normal, rather than inverse video, text.

   b) in reply to the person saying that the vt100 emulation doesnt work
      properly on a unix system, may I suggest he examines his termcap
      again, as I have had no trouble with vi on any of the 4 unix systems
      here. I have redefined the arrow keys to send hjkl instead of esacpe
      sequences (then there is no trouble with the machine failing to keep
      up when i lean on arrow key), redefined backspace to send ctrl-H and
      redefined Del to send a unix kill.

What is the difference between vt102 and vt100? I notice that vt100 isnt
an option. But whoever Joe Doupnik is, hes doing a good job....


sebastian rahtz
southampton

[Ed. - See next message.]

------------------------------

Date: 22 APR 86 17:07-MST
From: [e-mail]
Subject: Kermit's Mode Line: A Treatise.
Keywords: MS-DOS Kermit

        In response to the comment from Peter Kanaitis regarding the 25th
line usage in IBM Kermit. Peter is correct in stating the 25th line is part
of the active display with a terminal type of None. The reason is that there
is no emulator present to understand cursor movements and hence to protect
the 25th line. In this situation Kermit sets the mode line to Off, as is
shown on the status display. Later, changing to a full emulator the 25th
line is reserved for status information (Kermit's or the user's) and it is
protected. However, the mode line is still commanded to be off from the
previous terminal type none operations. Off in this situation means that
Kermit cannot place its own status line at the bottom of the screen. When
Kermit exits command mode it saves all 25 lines so that a user controlled
25th line will not be permanently erased, and it restores all 25 lines when
connect mode is resumed. In this case the 25th line was generated by
terminal type none operations. To redisplay Kermit's normal status line the
mode line must be enabled again by Set Mode On rather than just the ^]M
toggle; the toggle has effect only when Kermit's mode line is enabled.

        This is working as planned, even if the explanation is awkward. Again,
the 25th line can be used either by Kermit (normal) or by a remote application.
Exiting and then reentering Connect mode is not known to a remote application
and thus Kermit must and does preserve the 25th line around such interruptions.
Unfortunately, Kermit does not preserve a long history log of just how
the 25th line was generated. If an application writes there that will forcibly
disable the mode line (off state) to prevent Kermit from generating its own.
When the mode line is off and connect mode is reentered then the 25th line
shows whatever information was present there when connect mode was exited.
If the mode line is disabled by an application or by the command Set Mode Off
then the only way to turn it (Kermit's mode line) on again is to give the
command Set Mode On.

        The positioning of the cursor is a knotty problem. The position
is remembered across interruptions to connect mode; if it weren't then
we would be very unhappy indeed. For example, while in connect mode typing
the escape character ^] in fact temporarily or permanently exits connect
mode; losing the cursor position to do a simple toggle or menu operation would
be unacceptable. Undoubtedly, there are some side effects of this cursor
preservation strategy; the bad ones we will find and fix.

        I hope this clarifies how Kermit treats the Connect mode screen.
Maybe someone needs to put a little AI into Kermit since the pure logic can be
baffling.

        Regards,
        Joe D.

[Ed. - Thanks!]

------------------------------

Date: 21 APR 86 21:57-MST
From: JRD@USU
Subject: SmartTeam Modem Problem.
Keywords: SmartTeam Modem, Modem

        Someone had been telling me for some time that Kermit gets stalled
and does not recover. He was talking from an IBM compatible to a VAX. After
translating things back and forth I decided his modem might be at fault.
Side by side testing of his modem and mine today yielded: both receive files
from the VAX with no problem. Mine sends files ok, his sends flakey packets
and the VAX gives up with Device Errors after a dozen packets or so. His
modem is a SmartTeam 1200 external unit widely advertized under various
names. The problem seems to be the modem's small internal power regualtors
run very hot and allow the power to droop during sending. This might result
in a power-induced carrier phase shift and hence badly framed chars.  The
problem is evident only at 1200 baud when the modem sends long packets (ACKs
get through ok to the VAX). Work around suggested was to send shorter
packets until the power supply heat problem is fixed. Running his unit with-
out the case yielded excellent file transfers and a couple of toasty
fingers.  If all this is correct then there might well be a design problem
in these units remeniscent of older modems dying from overheated power
regulators (pre-VLSI era). My modem is a Hayes 2400 external unit (at the
price it had better work!)

        Regards,
        Joe D.

------------------------------

Date: Mon Apr 21 23:00:25 1986
From: Herm Fischer <hermix![e-mail]>
Subject: New PC Convertible (Laptop) Modem
Keywords: IBM Convertible PC, Modem, Internal Modem

Just got a document today which indicates that the laptop's internal modem
behaves mostly like the PC Jr's internal modem (as far as modem commands
go)...  Rest (screen, etc) behaves like a PC...  Some notes on modem having
to be set into a "transparent state" to ignore whatever puts it into command
state...

And, oh yes, its execution is faster than the plain PC because static CMOS
ram does not use clock cycles for refreshing.  But it should go thru bios
for input (keyboard) so that if waiting for keyboard it powers down...

  Herm

------------------------------

Date: 22 Apr 1986 1523-EST
From: William M Esser, [phone] (via LCG.KERMIT)
Subject: SCO XENIX V AND C-KERMIT 4C(58)?
Keywords: C-Kermit

        Have received a copy of C_KERMIT 4C last week and have attempted to
compile on a Sperry IT (AT type) under SCO XENIX V. C_kermit compiles under
sys3nid or xenix if -Mm is added to the make file for each of these. However
the system produces a unique type of Kermit, which will only talk to a second
C_kermit running under SCO XENIX V. Has any one else found this true and if
so, is there a fix ?????

------------------------------

Date: Wed, 23 Apr 1986 09:10 EST
From: Jack Shaw <JDS2F@UOTTAWA>
Subject: Apple II CP/M Kermit Diskette?
Keywords: Apple II CP/M

I am looking for someone with a copy of Apple CP/M Kermit for use with
an Apple Super Serial Card (6551 ACIA I believe). I would appreciate
it if you would post this in Info-Kermit. I'll be glad to send down a
diskette to the volunteer! Thanks.

                          Jack Shaw
                          [e-mail]
                          Univ. of Ottawa

[Ed. - Since we do not have an Apple II micro here, we cannot supply
diskettes to users.  Peter Trei has been kind enough to offer his services
to distribute Apple II DOS diskettes but we do not yet have a volunteer for
the Apple II CP/M version in the U.S.  If anyone has this version of Kermit
please submit it to a Users Group and let us know.]

------------------------------

Date: 22 Apr 86 20:48 +0200
From: [e-mail]
Subject: Kermit-10 Problem and Fix
Keywords: Kermit-10

Problem:
  .run k10mit

  TOPS-10 KERMIT version 3(134)
  Kermit-10>set file (parameter) byte-size (to) 7
  ? Unrecognized switch or keyword: "7"
  Kermit-10>set file (parameter) byte-size (to) ? one of the following:
  7-bit         36-bit          8-bit           auto-byte       eight-bit
  seven-bit     thirty-six-bit

Diagnosis: The command table is not sorted properly. The new "36-bit"
           parameter comes after "7-bit". It should be vice versa.

Cure:      exchange two lines in the table FBS020 in K10MIT.MAC

[Ed. - Thanks for the fix.  The change has been made to our copy of
KER:K10MIT.MAC.]

------------------------------

Date: Thu, 24 Apr 86 09:35:03 est
From: Tom Putnam <[e-mail]>
Subject: Re: Info-Kermit Digest V4 #25, PCJr Baud Rate Detection
Keywords: PCJr

A little known and less appreciated fact is that the IBM PCJr uses a
slightly different clock frequency to run the 8250A UART.  While I haven't
taken the time to look at the code in Kermit-MS 2.28 jrd/5g, it is apparent
that it reads the baud rate divisor register on startup and, if it is set to
some value, it uses the value to look up the baud rate in its table.  The
table values that are supposed to be used for PCJr are slightly different
than for the rest of the PC line.  I suspect Kermit-MS doesn't know about
this difference.  The differences are small enough that you can get by with
the "normal" PC settings and things will generally work.  Here are the
values from the IBM Tech Reference manuals:

        Baud rate       PC,XT,AT        PCJr
        300             384             373
        1200            96              93
        2400            48              47
        4800            24              23
        9600            12              12

"Smart" software that knows about the PCJr can check ROM location F000:FFFE
where the PC Type is flagged: FC=AT, FD=Jr, FE=XT, FF=PC.  (There re
probably others by now).  Is it worth it?  I doubt it...

Tom Putnam                              Manager of User Services
ARPANET: [e-mail]             Purdue University Computing Center
     or  [e-mail]            Mathematical Sciences Bldg.
BITNET:  PUTNAMT@PURCCVM                West Lafayette, IN 47907
USENET:  [e-mail]                317/494-1787

[Ed. - Thanks!]

------------------------------

End of Info-Kermit Digest
*************************
-------
30-Apr-86 18:35:57-EDT,10608;000000000000
Mail-From: SY.CHRISTINE created at 30-Apr-86 18:35:13
Date: Wed 30 Apr 86 18:35:13-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V4 #27
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 30 Apr 1986       Volume 4 : Number 27

Today's Topics:

              Announcing Kermit for the Commodore Amiga
               Commodore Amiga Kermit Bootstrap Progam
                    Announcing UNIX Kermit 4D(060)
            MSKermit 2.28 jrd/5e Works on IBM Convertible
                         Gould MPX-32 Kermits
                                Ideas

----------------------------------------------------------------------

Date: Tue, 29 Apr 86 16:12 EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Announcing Kermit for the Commodore Amiga
Keywords: Commodore Amiga Kermit, C-Kermit, UNIX Kermit

A version of C-Kermit for the Commodore Amiga is now available.  It's an
adaption of C-Kermit (which also runs on UNIX, VAX/VMS, and the Apple
Macintosh) for the Amiga by Davide P. Cervone of the University of Rochester,
User Services, [e-mail].  It was developed in Lattice C V3.03; it is
not known whether it is compatible with other compilers, or cross-compilers.

This version runs as a regular local Kermit, and also provides a server mode
supporting GET, SEND, REMOTE HELP, and BYE.  The user interface is
line-oriented (it runs from the CLI), with command completion and help in the
style of the UNIX Kermit.

The limitations of this version are discussed in KER:CKIKER.BWR, and the
differences between Amiga Kermit and UNIX Kermit are described in
KER:CKIKER.DOC.  The procedure for creating an executable from the sources
is outlined in KER:CKIKER.BLD (an automated EXECUTE file, KER:CKIKER.MAK, is
provided).  A BOO-format encoded executable is available (KER:CKIKER.BOO),
together with the program to decode it (KER:MSBPCT.C).  There's also a BASIC
version in CKIBOO.BAS (see next message).

Amiga Kermit is still under development, with planned enhancements to include:
a menu and mouse driven interface, wildcard file expansions, VT100 terminal
emulation, and local and remote command execution.  Now that Davide has
received his copy of the ROM kernel manuals, he should be able to add these
more advanced features.  Another version of Kermit for the Amiga, also based on
C-Kermit, has been in development at SAS Institue.  Davide has made contact
with these people, in hopes that the two versions can be merged into one.

The complete set of new files is in KER:CKU*.*, KER:CKC*.*, and KER:CKI*.*
on Internet host CU20B, available via anonymous FTP, and on KERMSRV at CUVMA
on BITNET.  The "I" system designator was selected for the Amiga because "A"
was already in use for general C-Kermit information; "I" stands for
Intuition (the Amiga operating system?).  Also, the bare minimum Amiga files
can be found in KER:CA*.*, for the benefit of those who order Tape A
(micros) and expect the Amiga to be among them.

------------------------------

Date: Mon, 28 Apr 86 15:24 EST
From:  [e-mail]
Subject: Commodore Amiga Kermit Bootstrap Progam
Keywords: Commodore Amiga Kermit

I am sending a modified version of MSPCTRAN.BAS which will unpack the .BOO
file for the Amiga Kermit for those of us lacking the benefit of a C
compiler.  The work was done by Andy Hollander here at Notre Dame and the
file is called CKAKER.BAS.  It takes about an hour to unpack the current
pre-release version of CKAKER.BOO, but it is worth the wait.  Our
compliments to Davide Cervone.

mark johnson
univ of notre dame

[Ed. - Thanks!  The file is in KER:CKIBOO.BAS.]

------------------------------

Date: Tue, 29 Apr 86 16:13 EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Announcing UNIX Kermit 4D(060)
Keywords: UNIX Kermit, C-Kermit

This is a minor new release of UNIX Kermit.  The big change is the addition of
Commodore Amiga support by Davide Cervone (see above), hence the escalation of
the minor version from C to D.  Also, a couple minor problems have been
corrected:

. Multiline GET in TAKE command files now works (thanks to G|ran Uddeborg
  for reporting this one) - KER:CKUUSR.C.

. File collision renaming bugs fixed and algorithm improved - KER:CKUFIO.C.

. CONNECT command handles fork creation failure more gracefully - KER:CKUCON.C.
  Thanks to Gordon Haverland, Dawson Creek, BC, for reporting this one.

The new files are in KER:CKU*.* and KER:CKC*.*.  Fixed bugs removed from list
in KER:CKUKER.BWR.  This new release was tested on a VAX with Ultrix 1.1
(4.2BSD), built using all the new modules, including the ones to which Amiga
support was added.

------------------------------

Date: Thu 24 Apr 86 18:18:02-PST
From: David John Buerger  <[e-mail]>
Subject: MSKermit 2.28 jrd/5e Works on IBM Convertible
Keywords: MS-DOS Kermit, IBM PC Convertible

I have received an evaluation unit of the new IBM PC Convertible and have
managed to get MS Kermit 2.28 jrd/5e (3/20/86) working on it.  Using a 3.5"
external disk drive attached to a PC/AT, I copied the necessary Kermit files
onto the new diskette.  This version of Kermit seems to work fine with no
modifications.

[Ed. - Good News!]

Unfortunately, the IBM internal modem for the Convertible does not recognize
Hayes AT commands (or most others familiar to us all).  Consequently, to
dial a number with Kermit on the Convertible, you must get into the Kermit
Connect mode, issue a ^N, then type D xxxxxxx where the x's are the number
you are dialing.  After logging off of a host, you type ^N, then H<return>
to disconnect the line.  When will IBM ever learn (sigh)?

[Ed. - We're IBM.  We don't care.]

Oh well, I'm happy that Kermit works on it.

[Ed. - Us too.]

David J. Buerger
Director, PC Center
Santa Clara University
[e-mail]

------------------------------

Date: Thu 24 Apr 86 21:52:23-MST
From: Mike Niswonger <[e-mail]>
Subject: Gould MPX-32 Kermits
Keywords: Gould MPX-32 Kermits

    I have rounded up the missing include file from the Singer-Link
version of Gould MPX-32 Kermit (GM1).  Please add this to the existing GM1
files. I will be reorganizing this group of files, but I have had several
requests for this file so I wanted to get it out ASAP.

[Ed. - Thanks!  It's installed in KER:GM1KER.INC.]

    I also have a more advanced version of Kermit for the Gould system,
from Simulation Associates.  A complete preliminary set of files with the
GM2 prefix can be found in my work directory.  I say preliminary because I
haven't had time to polish the doc, and server mode still doesn't work all
of the time.  The files have been checked out on my system, independently
from the author's system, and the Kermit is known good.

[Ed. - Thanks again.  We haven't managed to get this one yet, but will
keep trying.  It should show up on CU20B within a couple days.]

    Please add these files to CU20B's Kermit repository -- permission
has been granted by both authors.  I will let you know when updates to doc
or code are available.
                    -- Mike Niswonger

------------------------------

From: "Roger Fajman" <RAF@NIHCU>
Date: Wed, 30 Apr 86  15:42:54 EDT
Subject: Ideas
Keywords: Compression

A couple of ideas for improvements to Kermit:

(1) It would be nice to be able to give a list of files in a SEND command.
I often want to send several files at once, but can't express it with a
wildcard.  Now I must either rename the files, make up a command file (works
only if the receiving Kermit is a server), or sit at the PC and issue
another SEND command after each file is transfered.  I am going to try to
get this into the NIH TSO Kermit, if we can, so I would like to have a
standard syntax for it.

[Ed. - There's nothing in the Kermit protocol that prevents a program from
allowing this kind of syntax.  In fact, you can use it with UNIX Kermit when
you invoke it from the command line ("kermit -s foo bar baz").  The problem
is that many Kermit programs that have interactive command parsers use the
first filespec as the file(s) to send, and the second as the name to send it
under, or the initial filespec of a group, so it's just a question of
finding some alternate syntax.]

(2) Some of the file compression programs available for the IBM PC, such as
ARC, can achieve a considerable reduction in the size of a file (often 50%).
As the resulting file is binary, this results in a corresponding reduction
in transmission time when an 8-bit channel is used (assuming no 8th bit
quoting and neglecting the effect of control character quoting).  The
advantage of extending Kermit's compression capability to a more
sophisticated algorithm is that the user would get the benefit automatically
when both Kermits have the capability.  No separate compression and
decompression steps would be required.  Also, the method of encoding the
file could be designed to reduce the need for quoting characters, especially
when a 7-bit link is used.  The April 1986 issue of the Communications of
the ACM contains an article called "A Locally Adaptive Data Compression
Scheme" by Bentley, et. al. They claim that their algorithm does just about
as well as Huffman coding, without requiring two passes over the file.

[Ed. - There are a lot of whizzy compressions algorithms around, some
requiring one pass, some two, and each has its advocates.  In fact, there's
nothing that precludes Kermit programs from using any of them, but obviously
the two programs have to agree on the method used, and the key (if any).
The Attributes packet actually has some fields defined for this purpose.  In
practice, however, the simple run-length encoding that Kermit programs
currently use is often quite effective, and it's very easy to program.
Other methods are often better employed outside of Kermit -- like piping
UNIX Kermit through the (Lempel-Ziv) 'compress' program on either end, or
for that matter through tar.  Building this stuff into Kermit itself is a
big chore, and therefore probably wouldn't be done to more than a couple of
Kermit programs, thereby limiting its usefulness.]

Any comments?

[Ed. - etaoinshrdlu]

------------------------------

End of Info-Kermit Digest
*************************
-------
 7-May-86 15:26:24-EDT,7166;000000000000
Mail-From: SY.CHRISTINE created at  7-May-86 15:23:00
Date: Wed 7 May 86 15:23:00-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V4 #28
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 07 May 1986       Volume 4 : Number 28

Departments:

  ANNOUNCEMENTS -
         New TSO Kermit in Pascal
         New HP-86 Kermit Available
         New CP/M Source Files

  MISCELLANY -
         Compression, cont'd
         Quad board reported harmful to Kermit on Compaq

----------------------------------------------------------------------


Date: 05/07 05:43:19
From: M70B@CBEBDA3T
Subject: New TSO Kermit in Pascal
Keywords: TSO Kermit
Cross-Ref: MVS/TSO, see TSO Kermit

Finally my version of TSO-KERMIT is finished.  I read in a file on the
KERMIT-server that you're expecting my version since a year.  I have had my
program for beta-test since Nov 85, but the guys were not so sensitive to
inform me about their experiences.  But on our installation we run it with
great success.

There is a total of 7 files, containing the following:

     * TS2DS.ASM     Some ASM routines for TSODS command
     * TS2DS.INS     Installation procedure for TSODS command
     * TS2DS.PLI     Some PL/I rotines for TSODS command

     # TS2KER.INS    Installation of TSO/KERMIT
     # TS2KER.DOC    User's Guide of TSO/KERMIT
     # TS2KER.ASM    Some ASM routines for KERMIT
     # TS2KER.PAS    KERMIT main program

*) The TSODS command is used within the KERMIT program, to redirect
   TSO command output into a temporary file, accessible from the PASCAL
   main program.

   Fritz Buetikofer
   Amt fuer Informatik des Kt. Bern
   Laengassstrasse 51
   CH-3012 BERN (Switzerland)
   BITNET: M70B@CBEBDA3T

[Ed. - The files are installed in KER:TS2*.* on CU20B, and TS2* * on CUVMA.
This version is based in part on the Pascal/VS Kermit for VM/CMS by Victor
Lee of Queen's University, with some modules in Pascal, others in assembler,
still others in PL/I.  This version of Kermit is more advanced than the
old assembler version from the University of Chicago (KER:TSO*.*); it allows
transfer of binary files, includes 8th-bit prefixing, wildcard send, repeat
count compression (receive only), alternate block checks, server mode, etc.
It runs only on line-mode ASCII connections through a 3705-style front end;
there is currently no support for Series/1-style protocol converters.]

------------------------------

Date: Mon 05 May 86 21:53:08-EDT
From: Martin Rootes, Sheffield City Polytechnic, UK
Subject: New HP-86 Kermit Available
Keywords: HP86 Kermit
Cross-Ref: Hewlett-Packard, see HP

This is to announce Version 1.00 of HP86 Kermit.  HP86 Kermit provides
terminal emulation and Kermit protocol file transfer for the following
systems:

  Hewlett-Packard HP86.
  Hewlett-Packard HP87 - NOT TESTED.

The program has been tested at Sheffield City Polytechnic on the HP86,
with a  HP 82939A  serial interface.  Since the  program is written in
HP86/87 BASIC it is  expected that it will  work on the HP87,  however
this has yet to be confirmed.

The  program  was  written  in  HP86/87  BASIC and requires the binary
program UTIL/1  to supply  utilities for  enhanced screen  control, it
also relies on the I/O ROM for control of the serial interface. As the
program is written  in BASIC various  problems arise, the  major three
are:-

  1. It is noticeably slower than many other Kermit implementations.

  2. The baud rate is limited to 300, this was the fastest rate that
     could be handled by the terminal emulation section.

  3. The program is limited to sending files of type DATA, and numeric
     variables cannot be sent without conversion.

It  is  hoped  that  in  the  future some enterprising individual will
convert this program into assembler, this would undoubtedly  alleviate
problems 1 & 2 and hopefully 3.

The files are :-

HP8AAA.HLP -- List of all the HP8*.* files, with brief explanations.
HP8KER.DOC -- Kermit User Guide for v1.00.
HP8INS.DOC -- Kermit installation guide.
HP8BOO.FOR -- Downloading program.
HP8KER.BOO -- Kermit program in BASIC for downloading (see documentation).
HP8KRC.BAS -- Commented Kermit program (Reference only).

Author:- Martin Rootes,
         Computer Services Department,
         Sheffield City Polytechnic,
         Pond Street,
         Sheffield,
         S1 1WB
         United Kingdom.

         Tel:- (U.K.) 0742 20911 ext 2342

[Ed. - Thanks!  The new files are in KER:HP8*.* available via ANNONYMOUS FTP
from CU20B and BITnet KERMSRV from CUVMA.]

------------------------------

Date: Mon 05 May 86 21:53:08-EDT
From: Alan Phillips of Lancaster University, UK
Subject: New CP/M Source Files
Keywords: CP/M-80 Kermit

This is to announce new system dependent Kermit-80 files, edited with loving
care (and a lot of work) by Bertil Schou of Loughborough University.  They
now contain the system dependencies for all the currently available .HEX
files on CU20B.  As the SYS file is getting rather large, Bertil has
included a commented-out CHN directive about half way down which may be
useful to some people.

[Ed. - Thanks!  The new files are in KER:CP4TYP.ASM and KER:CP4SYS.ASM.
The .HEX files have been available for many months now without the source.
This brings the source up to date.  Just in case there turns out to be some
inconsistency in the new source, the old ones are preserved in KO:.]

------------------------------

From: "Roger Fajman" <RAF@NIHCU>
Date: Thu, 01 May 86  12:54:35 EDT
Subject: Compression, continued
Keywords: Compression

The advantage of having the compression algorithm built into Kermit is that
different systems have different compression programs.  Everything's OK if I
run something through ARC, for example, on an IBM PC, and then send it to
another IBM PC.  However, if I want to send the fine to a different kind of
machine, it is not likely to have a suitable decompress program.  Also,
using a separate compression utility makes transmitting a file into a 3 step
process, and thus more difficult for an unsophisticated user and more time
consuming for everyone.  Of course, many Kermits would have to implement the
same algorithm for it to be effective.  That means a quite a bit of work,
but the same can be said of sliding windows.

------------------------------

Date: Wed 7 May 86 12:58:41-EDT
From: Christine M Gianone <[e-mail]>
Subject: Quad board reported harmful to Kermit on Compaq
Keywords: Compaq

A Kermit user called and reported that the Quad board (I assume he meant
Quadram?) with the built-in clock, when installed on the Compaq along with
QUADCLOCK.SYS (?), prevents Kermit from transferring files.  Booting without
QUADCLOCK.SYS fixes the problem.

------------------------------

End of Info-Kermit Digest
*************************
-------
15-May-86 15:53:18-EDT,8105;000000000000
Mail-From: SY.CHRISTINE created at 15-May-86 15:51:52
Date: Thu 15 May 86 15:51:52-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V4 #29
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 15 May 1986       Volume 4 : Number 29

Departments:

  ANNOUNCEMENTS -
        New Gould/SEL Kermit Available
        New Kermit-32 With Bug Fixes

  MISCELLANY -
        Quad board reported harmful to Kermit on Compaq, cont'd
        Discussion group for technology for the handicapped
        Turbo Lightning and Kermit?
        Kermit for Digital Minc?
        WKermit on the AT?

----------------------------------------------------------------------

Date: Wed 7 May 86 20:02:43-MDT
From: Mike Niswonger <[e-mail]>
Subject: New Gould/SEL Kermit Available
Keywords: MPX-32 Kermit, Gould/SEL, SEL

I'm sending an alternative version of Kermit for Gould/SEL MPX-32 system
that was submitted by Simulation Assoc.  This version has some added
features that the old didn't.

[Ed. - The files are in KER:GM2*.* available via ARPANET using FTP, user
ANONYMOUS, any password and via BITnet at CUVMA using KERMSRV.  The older
version will be kept in KER:GM1*.* until some Gould/SEL users tell us that
there is no reason to keep it.]

------------------------------

Date: Fri, 9 May 86 12:41:29 EDT
From: rmcqueen (Robert C McQueen) @ sitvxb
Subject: New Kermit-32 With Bug Fixes
Keywords: Kermit-32, VAX/VMS

I think (and hope) that I have taken care of the items that you have referred
to me.  There is a completely new set of source files which include the one
and only .MSS file, all of the MACRO-32 files and the Bliss modules.  There
is a new .HEX file which includes the fix for sending files with FORTRAN
carriage control.

[Ed. - The two fixes relate to allowing control characters to pass through
transparently during CONNECT, and transfer of FORTRAN-format files.  The new
release is in KER:VMS*.* on CU20B, and also available as VMS* * from
KERMSRV at CUVMA.]

------------------------------

Date: Thu, 8 May 86 09:55 AST
From: <[e-mail]> (Eberhard W. Lisse)
Subject: Quad board reported harmful to Kermit on Compaq, cont'd
Keywords: Quad Board, Compaq

>> A Kermit user called and reported that the Quad board (I assume he meant
>> Quadram?) with the built-in clock, when installed on the Compaq along with
>> QUADCLOCK.SYS (?), prevents Kermit from transferring files.  Booting without
>> QUADCLOCK.SYS fixes the problem.

This is not restricted to the Compaq, but to the IBM XT as well. I have had
the same problem when transferring files to the VMS/VAX here in the
hospital. I managed to transfer by setting the TIMER off.

I have reported this problem to jrd directly, but he didn't know yet what could
have caused this.

This has also been reported by Jim Moore in a recent IBM info (5 47) as
follows:

>> Date: 24 Apr 86 09:11 EST
>> From: Jim Moore <moore@ncsc>
>> Subject: Quadram Quadboard
>>
>> I recently sent a message to INFO-KERMIT concerning the inability of the
>> latest kermit release (v2.28 jrd/5g 13 apr 86) to perform file transfer from
>> our 11/750 under UNIX 4.1.  Well, it turns out that the problem is once
>> again my Quadram Quadboard.
>>
>> I've had problems before with the print spooler and ram disk that come with
>> the quadboard interfering with the Symphony communications package, so I
>> just used a different spooler.  Now it turns out that the CLOCK on the
>> quadboard interferes with kermit somehow!
>>
>> That's (at least) two popular software packages that Quadram's Quadboard
>> really mungs up.  So, until I get my JRAM-3 board I'm using this
>> wonderful "multi-function board" of mine for just the memory....
>>
>> Jim Moore
>> Naval Coastal Systems Center

------------------------------

Date: 8 May 86 06:45 EDT
From: Jim Moore <moore@ncsc>
Subject: Quad board and Kermit on Compaq
Keywords: Quad Board, Compaq

As I mentioned a few months ago, the device driver QUADCLOK.SYS interferes with
an IBM PC-XT also.  A way around this is to put QUADCLOK.COM into the AUTOEXEC
batch file; the clock is still read and kermit transfers work fine.

jim moore
naval coastal systems center

------------------------------

Date: Thu 8 May 86 10:33:53-EDT
From: Frank da Cruz <[e-mail]>
Subject: Discussion group for technology for the handicapped
Keywords: Handicapped

A mailing list has been set up at North Dakota State University for
discussing computer and other technology for people with any kind of
handicap, plus meetings, conferences, funding agencies, and so forth.  It is
run by Bob Puyear, [e-mail] (via Arpanet,
[e-mail]), who will add you to the mailing
list if you send him a request to do so.  To send mail directly to the list
itself, replace NU025213 by L$HCAP in the addresses above.

------------------------------

Date: Thu, 8 May 86 08:48:28 pdt
From: Bob Borchers <[e-mail]>
Subject: Turbo Lightning and Kermit?
Keywords: Turbo Lightning

Has anyone run into a bug that makes file tranfers with Kermit incompatible
with having Turbo Lightning resident. The file transfer appears to go fine
but the file either received or sent is trashed. Terminal traffic is just fine
and I have found nothing else that is having trouble with lightning. For
reference I am using an AT at 8Mhz, either version 2.26 or 2.28 of Kermit
and a fairly early version of Lightning talking to a Vax running BSD4.3 at
1200 baud.

Bob<[e-mail]>

[Ed. - Try the latest pre-release of MS-DOS Kermit, in which the dynamic
memory management has been fixed up considerably.  If Turbo Lightning is
well-behaved, then it should be able to peacefully coexist with the new
version of Kermit.  The latest test version for the AT is in KER:MSTIBM.BOO
on CU20B, or, if you can transfer binary files directly, KER:MSTIBM.EXE.]

------------------------------

Date: 8-MAY-1986 15:41:58
From: [e-mail]
Subject: Kermit for Digital Minc?
Keywords: Minc-11

Has anyone transferred files from a Digital Minc computer using Kermit.
We have a user who is interested in doing this and would like to know of
anyone who has a version of Kermit for the Minc computer.

[From Brian Nelson, author of PDP-11 Kermit (the Minc is a laboratory model
of the PDP-11) -- If the Minc runs a reasonably current version of RT11
(v5.x is best), and they have an extra DLV11 on it, it should work.]

------------------------------

Date: 10 May 86 23:55:50 PDT (Sat)
From: [e-mail]
Subject: WKermit on the AT?
Keywords: Sliding Windows, WKERMIT

Did anyone ever figure out why WKermit (Kermit with Sliding Windows) doesn't
work when trying to communicate between two AT-class machines?  Someone
wrote in with a message about two or three months ago (I don't remember the
exact message) saying they couldn't get it to work between two AT's, and I
had no luck just recently with two Compaq Portable 286's.  I've got an
application ideally suited for sliding windows.  I can recompile the code
locally, but my hardware specific knowledge about the AT is limited.  If
anyone (like the author) has any ideas about where to start looking, it
would be greatly appreciated.

      - Dennis Persinger
        Aerospace Corp.
        djp@aerospace

[Ed. - The person who put together WKERMIT (Jan Van der Eijk) assumed that
it would be used only with modems, so the program requires the presence of
carrier detect.  You should be able to get around this restriction by
cross connecting DTR and CD in one of the connectors, or shorting DTR and
CD in both connectors.]

------------------------------

End of Info-Kermit Digest
*************************
-------
22-May-86 17:53:48-EDT,10271;000000000000
Mail-From: SY.CHRISTINE created at 22-May-86 17:53:03
Date: Thu 22 May 86 17:53:03-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V4 #30
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 22 May 1986       Volume 4 : Number 30

Departments:

  ANNOUNCEMENTS -
        New Release of Prime Kermit
        Sliding Windows Kermit Available for PC-DOS
        VMS Kermit 3.2.077 Hex File

  MISCELLANY -
        Stevens P/OS Kermit Doesn't Work Under P/OS 3.0
        Sending BREAK from C-Kermit on the Fortune 32:16?
        Speed Difference Between Upload and Download Using Kermit?
        Humble Apology for Amiga Kermit Beware File Mistakes

----------------------------------------------------------------------

Date: Thu 22 May 86 16:55:47-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Release of Prime Kermit
Keywords: Prime, Windows

This is to announce version 7.57 of Prime Kermit for the PRIMOS operating
system, R19 or later, contributed by John Mulligan and Hugh Matlock of The
Source Telecomputing in McLean, VA.  This version corrects the bugs that
were reported for the last version and also supports the sliding window
protocol extension.  It is in use at The Source, and has been used
successfully over Telenet (with its characteristic delays) with very high
efficiency, as reported in previous issues of the Info-Kermit Digest.

The new version is in KER:PRIME.* on CU20B, available via anonymous FTP
(Internet) or NFT (CCnet), and in PRIME * on CUVMA, available via KERMSRV on
BITNET.  Thanks to Leslie Spira of The Source for sending it in.

The old version, which contains some special functions for dealing with SPSS
Portable Files, remains available as KER:PRIMEK.* (PRIMEK * on BITNET).

------------------------------

Date: Thu 22 May 86 16:59:56-EDT
From: Frank da Cruz <[e-mail]>
Subject: Sliding Windows Kermit Available for PC-DOS
Keywords: MS-DOS Kermit, Windows, C-Kermit

This is to announce a version of Kermit that runs on the IBM PC and
compatibles under PC-DOS, and which supports the sliding window protocol
extension.  It may be used in conjunction with Prime Kermit to accomplish
very efficient data transfers.  It was written by Jan van der Eijk of NUS,
commissioned by The Source Telecomputing, based on an old version of
Columbia C-Kermit.  It has not been integrated with "real" C-Kermit yet for
a variety of reasons, but this will come eventually.  The files are in
KER:WKERMIT.* on CU20B, available via anonymous FTP (Internet) or NFT
(CCnet), and in WKERMIT * on CUVMA, available via KERMSRV on BITNET.  Thanks
to Leslie Spira of The Source for submitting it.

------------------------------

Date: Thu, 22 May 86 09:15:10 EDT
From: SY.FDC@CU20B
Subject:  VMS Kermit 3.2.077 Hex File
Keywords:  VMS Kermit

When VAX/VMS Kermit 3.2.077 was announced in Info-Kermit Digest V4 #29, the
hex file for the program's task image was inadvertantly not updated.
Apologies to those who took the trouble to get the file and dehexify it,
only to find that it was still 3.2.075, and thanks to those who reported the
problem.  A hex file for 3.2.077 is now available in KER:VMSMIT.HEX on CU20B
(and VMSMIT HEX on CUVMA).

------------------------------

Date: Thu, 22 May 86 09:15:10 EDT
From: rmcqueen (Robert C McQueen) @ sitvxb.ccnet
Subject: Stevens P/OS Kermit Doesn't Work Under P/OS 3.0
Keywords: Professional-300, P/OS

The DEC Professional-3xx version of Kermit from Stevens doesn't work in
version 3.0 of P/OS.  It worked in all of the field test versions of the new
P/OS 3.0, but doesn't work in the released version.  We are currently
working on the problem, but I can not give you any time frame as to when it
will be fixed in that version.

Bob

------------------------------

Date: Mon, 12 May 86 11:18:09 BST
From: Philip Dunne EuroKom <mcvax!euroies![e-mail]>
Subject: Sending BREAK from C-Kermit on the Fortune 32:16?
Keywords: C-Kermit, Fortune

I have just installed the C-KERMIT programs on a FORTUNE 32:16 (OS 1.2.3).
The executable file was created using the make ft17 option.  I am using
C-KERMIT to transfer files between the Fortune and a GEC 63/40 running
SYSTEM V.  Inorder to contact the GEC I have to go through a Gandalf switch.
When I try to send a BREAK to get the attention of the switch I get this
message:

Can't send BREAK : Not a typewriter.

Can anyone tell me what alterations are needed so that I can send a BREAK
from the Fortune and so use KERMIT normally.

                Thanks in advance
                                  mcvax!euroies!philip

[Ed. - The Fortune support in C-Kermit uses the 4.2 BSD method for sending a
BREAK, namely ioctl(ttyfd,TIOCSBRK,(char *)0).  You are apparently getting a
negative return code from this function, which means either that that's not
really the right way to send a BREAK on the Fortune (anybody know for sure?),
or the function isn't implemented correctly, or somehow you're passing it a
file descriptor that's not for a tty.  The code in question is in the file
ckutio.c, function ttsndb().]

------------------------------

Date: 9 May 86 16:40:49 GMT
From: P Wei <[e-mail]>
Subject: Speed Difference Between Upload and Download Using Kermit?
Keywords: Performance

I am using Kermit (v.2.26) transfering files between IBM PC and VAX (running
UNIX 4.2bsd and C-Kermit).  Everything works fine except that it only takes
a few minutes to download 50K bytes file from VAX to PC, whereas it takes
*hours* to upload the file.  (I am using a network line with 9600 baud rate.
The only setting after I invoke ms-kermit is "set parity even" and "set baud
9600".  AND the transfering is at midnight. The vax has less people to serve
at this hour than in daytime).  Can anyone shine some light on me ? What is
going wrong ?  Is this an intrinsic problem with the kermit program?  Thank
you in advance for your help!

[Ed. - The speed difference you observe is not the normal behavior of
Kermit.  It's probably caused by the network.  Many network terminal
concentrators, statistical multiplers, and similar devices allocate much
higher bandwidth in the host-to-terminal direction than in the terminal-to-
host direction on the assumption that the data coming from the "terminal"
consists only of human keystrokes, whereas the host is capable of spewing
forth vast amounts of data in response to a short command.  Of course, when
the terminal is really a PC running a file transfer program like Kermit,
this assumption is very wrong.]

------------------------------

Date: Tue, 20 May 86 17:03 EST
From: <[e-mail]>
Subject: Humble Apology for Amiga Kermit Beware File Mistakes
Keywords: Amiga Kermit

It has come to my attention that a preliminary evaluation that I wrote
concerning Phil Julian and Jack Ralphs' version of Amiga Kermit was distributed
along with the CKIKER.BWR file for Amiga Kermit.  This report was not intended
to be included in the beware file, and has been removed.  It contained a
number of inaccuracies, which I hope to remmedy below.  More important, is was
viewed as a condemnation of Phil and Jack's version, which it was not meant to
be.  Phil and Jack have been very generaous to me in sending their code for
evaluation.  I learned a lot from it, and I find it to be an excellent
product, far superior to mine in many respects.  My main intent in that letter
was to indicate that the files, as they were given to me, were not in a form
appropriate for distribution, and that some work would be required to put them
into a distributable form.  It did not mean that the program should not be
distributed, nor that major changes were required to make it distributable.
This was not clear from what I said in my letter, for which I appologize.

Phil and Jack's version WILL be distributed, and I recommend that people use
it.  I suggested (recently) that their version replace mine as the "official"
version, but I do not know whether this will happen.  I will continue to work
on an Amiga-style interface for Kemit (something along the lines of MacKermit)
that is menu-driven and uses requestors, etc.  This will be some time in
coming, however, I'm afraid.

Since my complaints about Phil and Jack's version were aired publicly, I
think that the corrections to my complaints should be as well.  Many of the
"problems" I listed were really personal preferences, not mistakes with the
product.  These should not have been included in a list of bugs.  Inaccuracies
in the list that was published include the following:

   1)  It no longer uses the C-Kermit 057 version files.

   2)  The function keys do not, in fact, produce garbage, they produce no
       output, and the arrow keys produce arrow movements as they should.
       In addition, a number of the most important ANSI escape sequences are
       correctly interpreted by the console driver, so that Amiga Kermit
       can be used with many full-screen programs that expect a VT100
       terminal.  The HELP key is the only one I could find that produced
       strange results.

   3)  The changes I claimed were made to the Unix modules actually were made
       in the Amiga-dependent code, which is OK to do.  The copy I received
       was missing a section of Unix code in one place, but I understand that
       this has been replaced in the final version.

   4)  The reference to "inferior code" in the summary section referred to
       MY version, not Phil and Jack's; this was not clear from the context.

One final disclaimer:  my letter did not affect the decision about which
version to distribute, as my version was announced in the INFO-KERMIT Digest
BEFORE I sent that evaluation.  I deeply regret any misunderstandings that
may have been caused by the publishing of that report.

                                Davide P. Cervone

------------------------------

End of Info-Kermit Digest
*************************
-------
28-May-86 14:25:31-EDT,9601;000000000000
Mail-From: SY.CHRISTINE created at 28-May-86 14:23:39
Date: Wed 28 May 86 14:23:39-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V4 #31, Special Edition
To: [e-mail], [e-mail]
Reply-To: Info-Kermit@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 28 May 1986       Volume 4 : Number 31

             Special Edition: MS-DOS Kermit 2.29 Released

----------------------------------------------------------------------

Date: Wed 28 May 86 11:08:51-EDT
From: Frank da Cruz <[e-mail]>
Subject: Announcing Version 2.29 of MS-DOS Kermit
Keywords: MS-DOS Kermit, IBM PC, Rainbow, HP110, HP150, Heath/Zenith-100
Keywords: NEC APC, Sanyo MBC, TI PC, Victor 9000

This is to announce version 2.29 of MS-DOS Kermit for the IBM PC family and
compatibles, the DEC Rainbow, Heath/Zenith-100, HP-1xx, NEC APC, Sanyo MBC, TI
PC, Victor 9000, several other systems, and generic MS-DOS.  This version
replaces version 2.28, which was released June 10, 1985.

The new release was prepared by Joe R. Doupnik of Utah State University
([e-mail]) over many long months of detailed work.  Joe began by adding
full DOS 2.0 file support to 2.28 along with a range of server functions, and
fixing the bugs that were listed in the .BWR file.  Then he took the VT100
emulation code from James Harvey of Indiana/Purdue University (which was
written for version 2.27) and merged it in, adding features to bring it up to
nearly complete VT102 emulation, while leaving the VT52 and Heath-19 emulation
intact.  Joe has also added many new features and commands, and has tirelessly
coordinated testing of the new program on different systems through many
generations of prerelease, and cheerfully checked and merged in improved
support for various systems (like the Z100).

The result is finally ready for distribution.  In addition to the new programs,
there is a completely new MS-DOS Kermit chapter for the Kermit user guide, new
help and beware files, and other new material.  On most systems, the new
version requires less memory than the previous one, and only slightly more disk
space.  On the IBM PC family, the program needs about 60K to run, but will
allocate more if it can.

New Features of This Release:

. Full DOS 2.0 file system support in all commands. DOS 1.x support removed.

. On the IBM PC family, emulation of VT102, VT52, H19, and dumb terminal.
. Support for host control of 25th line during terminal emulation on IBM PC.
. Screen rollback memory now dynamically sized rather than fixed.
. IBM PC VT102 emulation includes all major VT102 features except
  132 columns, smooth scrolling, printer control, and diagnostic functions.

. On IBM PC family, peaceful coexistence with TopView, DesqView, MS Windows.
. Some support for IBM Extended and Professional Graphics Adapters.
. New SET TERMINAL command for setting terminal type and parameters,
  including foreground and background color and intensity on systems that
  support it (currently only for IBM family).
. New screen dump feature (on the DEC Rainbow and IBM family only).
. Increased screen rollback memory on Rainbow & IBM.
. HANGUP command for dropping DTR & RTS, to signal modem to hang up phone
  (IBM family only).
. Heath/Zenith-100 port i/o now interrupt driven, therefore much faster.

. The MS-DOS Kermit server now responds to advanced server commands (REMOTE
  DIR, REMOTE HOST, REMOTE DEL, REMOTE TYPE, REMOTE CWD, etc).
. SET RETRY n command for changing the packet retry threshold.

. Improved file name handling, to prevent destruction of directory, system,
  hidden, read-only, and volume label files.  File renaming algorithm much
  improved for conversion of incoming file names to DOS conventions, and for
  filename collision avoidance.

. LOG command now also logs debugging information (packets, terminal session)
  if SET DEBUG ON command has been given.
. New file transfer display options: SET DISPLAY QUIET, REGULAR, SERIAL.
. Serial display used by default in generic MS-DOS Kermit.

. Program segments are now ordered independently of MASM/LINK version, without
  any special switches required for building.
. Assembles with MS MASM 1.25, IBM MASM 2.0 aka MS MASM 3.0, and MS MASM 4.0,
  as well as Intel RMX assembler.  As released, the programs were assembled
  with Microsoft MASM 4.00 and Link 3.05.  Runs under all existing versions of
  MS/PC-DOS, 2.0 and higher.

. All known bugs in version 2.28 fixed including:
   Severe problems if program assembled and linked improperly
   GET command filename confusion
   Many problems with file renaming, name truncation, etc.
   Exported filenames with no filetype no longer end with period
   SET DEST PRINTER didn't work correctly
   Problems with dynamic memory allocation
   Display problems on early PC, Compaq
   Heath-19 emulation bug regarding receipt of CR or LF at col 80 vs autowrap
   The "C?" bug in the command parser
   ^C of a file transfer now honors SET INCOMPLETE KEEP
   Lost clusters on disk if BYE command given with log file open
   RUN command did not default file types .EXE, .COM, .BAT
   Long debug lines would overflow screen
   Overruns of half duplex systems at high baud rates
   Control-prefix operands in packets not range checked
   Interrupt and performance problems on IBM PC family
   Numbers sometimes disappearing from file transfer display
   Problems parsing SET PORT options in generic MS-DOS Kermit
   Program crashed with "divide overflow" when transferring very long file
   Tendency to hangup Hayes 1200B internal modem upon startup
   Problems when padding with more than 2 or 3 characters

Incompatibilities with previous release:

. SET HEATH gone, replaced by SET TERMINAL { HEATH, VT102, VT52 }
. SET AUTOWRAP gone, replaced by SET TERMINAL WRAP
. Filename completion (recognition) no longer works, because of support for
  fully qualified DOS 2.0 pathnames.

Tested on the following systems:

. IBM PC, XT, AT, PCjr, Portable PC, Convertible PC, and RT with AT DOS option
. Compaq, Z150, Z160, and other IBM compatibles
. DEC Rainbow
. Heath/Zenith-100
. HP-150, HP-110, and Portable Plus
. NEC APC and APC-3
. Victor 9000 / Sirius 1
. ACT Apricot
. Sanyo MBC 550
. Texas Instruments Professional PC
. Intel 300 series with iRMX-86
. Generic MS-DOS

Needs testing on:

. Wang PC
. Olivetti M24 PC
. Grid Compass II
. DECmate-II,III with XPU (MS-DOS) option

IBM PC family H19 and VT102 emulators tested successfully with:

. EMACS (DEC-20, CCA, GNU, and others, using line/char insert/delete)
. EDT, PHONE (VAX/VMS)
. 1-800-DEC-DEMO
. UNIX vi, sysline, etc
. Various torture tests

The new files are in KER:MS*.* on CU20B, available on the Internet via
anonymous FTP, and in MS* * on CUVMA, available on BITNET through KERMSRV at
CUVMA.  Within a few days they should also be available for UUCP transfers from
okstate (Oklahoma State University).  The executable programs are encoded in
"BOO" format (a printable 4-for-3 encoding of the .EXE file, with compression
of repeated zeros).  The BOO files are in KER:MSV*.BOO (for instance, the
version for the IBM PC family is in KER:MSVIBM.BOO), which may be decoded with
the program MSBPCT.BAS (slow) or MSBPCT.EXE (fast, but you need the Basic
program to get the fast version in the first place, because it too is
BOO-encoded).  BOO files for the old release (2.28) are still available as
KER:MSO*.BOO.

The new manual chapter is in KER:MSKERM.DOC (long, about 122K).  A summary of
the Kermit-MS invocation and commands is in KER:MSKERM.HLP (shorter, about 9K).
KER:MSKERM.BWR lists the known bugs and deficiencies, along with some
implementation notes.  KER:MSR229.UPD contains the release notes for this
version (somewhat similar to this message).

Before you get all of the KER:MS*.* files over the network, first get the
following files, which will help you zero in on the particular files you need:

. KER:MSAAAA.HLP - describes the organization MS-Kermit files in detail.
. KER:MSBAAA.HLP - describes the bootstrapping procedure for BOO files.
. KER:MSSAAA.HLP - describes how to build the program from source files.

Most people will not need the source files, which add up to quite a chunk.

If you are new to Kermit network distribution, then even before you get these
files, you should get and read KER:AAAREAD.ME (AAAREAD ME on BITNET KERMSRV).
If you can't access CU20B or CUVMA by network, you can order diskettes by mail
from:

    Kermit Distribution
    Columbia University Center for Computing Activities
    612 West 115th Street
    New York, NY  10025

Include a check for $10 US ($15 if you also want a Kermit User Guide) payable
to Columbia University Center for Computing Activities, to cover our
reproduction and handling costs.  To order from outside North America, write
to the above address for further information.

Please send inquiries, bug reports, comments, complaints, and suggestions to
Info-Kermit-Request@CU20B, or by postal mail to the above address.  In
particular, reports that the program works (or doesn't) on the as-yet-untested
machines will be most welcome.

P.S. It might take a while for the files to show up on BITNET, due to
temporary troubles with our network connection to CUVMA.

------------------------------

End of Info-Kermit Digest
*************************
-------
 5-Jun-86 12:03:00-EDT,6712;000000000000
Mail-From: SY.CHRISTINE created at  5-Jun-86 11:57:46
Date: Thu 5 Jun 86 11:57:46-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V4 #32
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu,  5 Jun 1986       Volume 4 : Number 32

Today's Topics:

         Modified MVS/TSO Kermit Via 7171 Protocol Converter
                           New OKSTATE.TXT
              New GEC 4000 Kermit Version from Lancaster
                Many modifications for RT11 Kermit-11
                   C-Kermit vs. MS-Kermit Server II
                    Minor problem with MSYIBM.ASM
                      C-kermit & SCO Xenix Sys V

----------------------------------------------------------------------

Date:    Fri, 23 May 86 09:08 EST
From:  [e-mail]
Subject: Modified MVS/TSO Kermit Via 7171 Protocol Converter
Keywords: MVS/TSO Kermit, 7171 Protocol Converter

Please find enclosed a slightly modified version of TSODYNAL.ASM for the
TSOS1 Kermit.  We had to make a relatively minor change so RECEIVEd datasets
were correctly allocated to the user's proper disk pack. The two affected
lines are commented out with the changes following them.

Mark

[Ed. - The new modified version of TSOS1 Kermit is in KER:TSODYNAL.ASM
available via FTP at CU20B, user ANONYMOUS (any password) and from BITnet at
CUVMA using KERMSRV.]

------------------------------


Date: Mon, 26 May 86 18:40:54 CDT
From: Gregg Wonderly <[e-mail]>
Subject: New OKSTATE.TXT
Keywords: Okstate, UUCP

        There is the new update of OKSTATE.TXT for anyone who is
interested in downloading files via UUCP.

Gregg

[Ed. - The new file is in KER:OKSTATE.TXT.  The file is too long to include
here in the digest.]

------------------------------

Date: Thu 29 May 86 16:54:36-EDT
From: Christine M Gianone <[e-mail]>
Subject: New GEC 4000 Kermit Version from Lancaster
Keywords: GEC 4000

        This is to announce a new version (3.5) of the Kermit for the GEC
4000 series minis running OS 4000, from Martin Loach of Rutherford Appleton
Laboratories.  The files should replace the current GEC set.  The language
is Babbage rather than SERC/MUMS.

[Ed. - These files are in KER:GEC*.*.  Thanks again to Alan Phillips of
Lancaster University for maintaining Kermit in the U.K. and for sending us
updated Kermit versions.]

------------------------------

Date: Fri, 30 May 86 08:05 EST
From: <[e-mail]> (brian nelson)
Subject: Many modifications for RT11 Kermit-11
Keywords: Kermit-11, RT11/TSX+

 A minor release of Kermit-11 is available. This version, 3.51,  differs
only in a number of RT11/TSX+ specific modifications from the previously
announced Kermit-11.

 Specifically:

 1. Reduction in the size of the  root  for  XM  to  facilitate  running
Kermit as a foreground task.

 2. Complete rewrite of terminal emulation, specifically to enhance  the
support of the XL/XC/CL handlers. It  is  now  completely  event  driven
thus  performance  should be improved as well as presenting a much lower
load on the CPU. It should also function better under SJ.

 3. Restructuring buffer allocation to (1) Reduce the root size for  XM,
and  (2) To enable the USR to swap over buffers for SJ and FB. This will
eliminate Kermit crashing on USR requests in 95% of  the  cases  for  SJ
and  FB  systems  with  minimal  background  memory  available (ie, many
devices in the system and/or large RMON).

 4. Control C delivery has been improved by adding a watchdog  timer  to
check for control C's as RT11 does not generate an AST on control C.

 The  files  are  currently  available  via  [e-mail] or by
dialup from  the  University  of  Toledo's  VAX  11/785.  Columbia  will
receive a new distribution shortly.

Brian Nelson
[e-mail]

[Ed. - This is will be announced when we receive the new tape.]

------------------------------

Date: Tue, 3 Jun 86 09:13:31 pdt
From: Steve Walton <ametek![e-mail]>
Subject: C-Kermit vs. MS-Kermit Server II
Keywords: C-Kermit, MS-DOS Kermit

The problem with this combination is solved, and warrants a warning.  We
were starting our MS-Kermit server from our host, by doing a CTTY COM1: when
the PC was booted.  Apparently the CTTY sufficiently degrades the
performance of the serial port that Kermit will not work reliably even at
1200 baud.  When the CTTY was not done, and MS-Kermit was put into server
mode from the PC's keyboard, no problems were encountered at 9600 baud.

I hope this information is useful to others.

Stephen Walton, Ametek Computer Research Division

[Ed. - Has anyone else experienced these performance problems when CTTY
is in effect?  I assume Steve is using an IBM PC or compatible.  Is there a
difference between the new release (2.29) and previous ones in this respect?
We have tested use of Kermit through CTTY on the Rainbow up to 9600 baud
with no problems.]

------------------------------

Date: Wed 4 Jun 86 10:01:11-EDT
From: Frank da Cruz <[e-mail]>
Subject: Minor problem with MSYIBM.ASM
Keywords: MS-DOS Kermit, MSYIBM.ASM

The MS-DOS Kermit terminal emulation module for the IBM PC, MSYIBM.ASM,
contains a definition for the symbol SETBLK, which duplicates the definition
from the header file, MSSDEF.ASM.  Late-model assemblers are not perturbed
by this, but earlier assemblers complain about it, and some may refuse to
generate an object module.  Cure: remove the EQU for SETBLK from MSYIBM.ASM.
This has already been done on the master copies in Kermit distribution.
Thanks to the several people who pointed out the problem.

------------------------------

Date:  Tue, 3 Jun 86 22:18 EDT
From:  Roger Hartmuller <[e-mail]>
Subject:  C-kermit & SCO Xenix Sys V
Keywords: C-Kermit, SCO Xenix, System V

   I finally got the fix to allow kermit transfers with C-kermit running
under SCO Xenix System V on an IBM AT.  I haven't seen it published in
the forum, so I'm sending it in, even though I didn't discover the fix
myself.  In ckcfn2.c, in the routine chk1(), declare chk as an unsigned
int rather than an int.

    The problem was supposedly caused by an error in the C compiler.
Anyway, the fix works.

[Ed. - KER:CKCFN2.C has that change in it now.]

------------------------------

End of Info-Kermit Digest
*************************
-------
16-Jun-86 16:58:19-EDT,8623;000000000000
Mail-From: SY.FDC created at 16-Jun-86 16:56:30
Date: Mon 16 Jun 86 16:56:30-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V4 #33
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Mon, 16 Jun 1986       Volume 4 : Number 33

Today's Topics:
                     Kermit for PDP-8 with OS-278
                New Kermit User Guide, Protocol Manual
                        BITNET KERMSRV Backlog
         Series/1 and Clone Initialization File for MSKERMIT
               Kermit 2.29 Packet Count Display Problem
   Problem with 2.29 Server and Block Checks, and Cursor Shape Hint

----------------------------------------------------------------------

Date: Wed 11 Jun 86 16:30:43-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit for PDP-8 with OS-278
Keywords: PDP-8 Kermit

This is to announce Kermit for the DEC PDP-8 or DECmate running an operating
system called OS-278.  OS-278 is similar to OS-8, but has support for more
modern devices -- like RX50 diskette drives -- added.  OS-278 is not the same
as WPS.  It is not a DEC product, but is available from DECUS, and is used
within DEC for DECmate development.  This Kermit program is based on the OS-8
version of Kermit done by Jerry Sands & Randy Hippe of Bureau of Engraving Inc,
Minneapolis MN, and was adapted to OS-278 by Martyn Hemmings at DEC in
Germany.  The files are in KER:K278*.* on CU20B, available via anonymous FTP,
or on CUVMA as K278* *, available (traffic permitting) via BITNET KERMSRV.

It is hoped that this program will eventually serve as a basis for a "native"
DECmate WPS Kermit.  Anyone interested in doing this work should contact us
(Kermit Distribution at Columbia) first.

------------------------------

Date: Tue 10 Jun 86 16:13:40-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Kermit User Guide, Protocol Manual
Keywords: Kermit User Guide, Kermit Protocol Manual

Revision 2 of the 6th Edition of the Kermit User Guide is now available.  It
contains new chapters for MS-DOS Kermit 2.29, Macintosh Kermit 0.8(34), VMS
Kermit 3.2, and a new bootstrapping section for CP/M-80 Kermit (thanks to
Bernie Eiben for the latter -- it turns out that the old bootstrapping
procedure, which has been in the manual for years, simply did not work).  The
User Guide is formed from KER:KUSER.MSS, plus individual chapters for each
implementation covered, whose MSS files reside with the other files for that
implementation.  Only minimal changes have been made to KUSER.MSS.
KER:KUSER.DOC is the complete manual, suitable for reading on a CRT screen;
it's about 280 pages long (700K).

A new edition of the Kermit Protocol Manual -- the 6th edition -- is also
available.  The new material consists mostly of corrections to the old, plus
new sections on long packets and sliding windows.  The new protocol manual
is in KER:KPROTO.MSS (Scribe source) and KER:KPROTO.DOC (CRT-readable file).
The files KER:KPROTO.UPD and KER:KPROTO.UP2 (which described long packets and
sliding windows, respectively) have been removed.

The new manuals are available via anonymous FTP from CU20B (Internet) and
from KERMSRV at CUVMA (BITNET), and in printed form from Kermit Distribution
at Columbia (see KER:AAXFLY.DOC for ordering instructions).

------------------------------

Date: Wed 11 Jun 86 14:01:03-EDT
From: Frank da Cruz <[e-mail]>
Subject: BITNET KERMSRV Backlog
Keywords: BITNET, KERMSRV

Due to the overwhelming number of requests for Kermit files from KERMSRV
at CUVMA, and to the unavailability of key BITNET routing hosts for
extended periods of time over the past few days, CUVMA's queues for outbound
BITNET files filled up to the point that the system could no longer
function, so the queues had to be flushed.  Over 1000 files were affected.
Therefore:

. People who requested files from KERMSRV over the past week may have
  to request them again, but...

. It would be better if files were only requested by one person -- preferably
  the Kermit maintainer -- at each site, to prevent duplication.

. We will try to work out some arrangement with BITNET management (EDUCOM)
  to let the Kermit files flow more smoothly over BITNET.  The most likely
  interim solution will be the establishment of additional BITNET Kermit
  file servers at other geographical locations.  These will be announced as
  they become available.

Apologies for the inconvenience.

------------------------------

Date: Wed, 4 Jun 86 12:35 EDT
From: "John C. Klensin" <[e-mail]>
Subject:  Series/1 and Clone Initialization File for MSKERMIT
Keywords: Series/1, 7171, Protocol Converter, MS-DOS Kermit

I enclose two logical files, one that describes what the other does, called
MSI7171.HLP and MSI7171.INI, for setting up the IBM PC with MS-Kermit 2.29 for
communicating with an IBM VM/CMS mainframe through a Series/1-style front end
(7171, 4994, Yale ASCII package).  This has been tested against the
Series/1-VM/CMS combination at MIT; I have no way to know if it will work in
other combinations.

Motivation: keyboard-switching drives me crazy and, for example, my left-hand
little finger instinctively reaches toward the second vertical row of function
keys and likes finding "clear" there.  If it does not find "clear" there, it
better not find anything destructive, like whatever the S/1 does when it sees
whatever VT100 PF2 maps to.

In other words, 2.29 is set up as much like a VT100 as one can reasonably make
a completely different keyboard layout, and I think that Joe made a relatively
good set of compromises where there was no "right" thing to do.  But the
problem is whether one wants to try to map keys functionally (Joe's approach)
or geographically.  The S/1 is really using a VT100 to imitate a 3278; using
MSKERMIT's VT102 mode involves using the PC to imitate a VT100 imitating a
3278.  The keyboard file does a little better imitation of a 3278 keyboard on
the PC so that it becomes a bit more like a PC imitating a 3278 using VT100
codes and the S/1 as intermediaries.

[Ed. - Thanks!  The files are installed in KER:MSI7171.* on CU20B and
MSI7171 * on CUVMA.]

------------------------------

Date: 3-Jun-86 12:29:47-EDT
Subject: Kermit 2.29 Packet Count Display Problem
From: [e-mail]
Keywords: MS-DOS Kermit

When using Version 2.29 to download a file from a Kermit-20 server, the Packet
counter will not reset.  This happened when I either cancel a file or when I
get a second file.  (I am not doing wild card gets).  The counter just picks up
where it left of from the last transfer.  The screen displays 0 packets
received, clears the screen and shows the number of packets from the last
transfer and starts counting.

The files transfer correctly and the number of KBytes transferred is updated
properly only the number of packets seems to be affected.  Other then this it
seems to work just fine.

Marc Frederick

[Ed. - This is indeed a bug, and has been noted in the "beware file".  It also
happens when SENDing to a server.]

------------------------------

Date: Sun 15 Jun 86 17:23-EDT
From: Ed Barton <[e-mail]>
Subject: Problem with 2.29 Server and Block Checks, and Cursor Shape Hint
Keywords: MS-DOS Kermit, Cursor

I believe I have discovered a bug in IBM-PC kermit version 2.29.  When
MS-Kermit is operating in server mode, it does not appear to respect the
block-check setting.  If I use version 2.28 and set block-check 3, I can
transfer files from my CP/M system that uses set block-check 3.  If I use
version 2.29 in server mode, I cannot ship files over from my CP/M system
unless I put the CP/M system in set block-check 1 mode.

[Ed. - Thanks for the report, we'll check it out.]

By the way, on at least some systems that have the cursor-shape bug, if you run
a program that explicitly sets the cursor-shape in the AUTOEXEC.BAT file, then
the cursor-shape will be correctly remembered from there on.  This worked for
my system and perhaps could be mentioned in the documentation.

[Ed. - Thanks for the hint.  Such a program was listed in Info-Kermit V4 #10,
and can also be found in the latest incarnation of the MS-DOS Kermit "beware"
file, MSKERM.BWR.]

------------------------------

End of Info-Kermit Digest
*************************
-------
27-Jun-86 15:22:03-EDT,10162;000000000000
Mail-From: SY.CHRISTINE created at 27-Jun-86 15:19:27
Date: Fri 27 Jun 86 15:19:26-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit V4 #34
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 27 Jun 1986       Volume 4 : Number 34

Today's Topics:

                    New Release of Kermit for Magiscan 2
             Announcing MS-DOS Kermit 2.29 for IBM Semi-Clones
          Announcing MS-DOS Kermit V2.29 for the Seequa Chameleon
                          MS-DOS Kermit 2.29 Fixes
                        CP/M-80 Kermit Developments

----------------------------------------------------------------------

Date: 16 Jun 1986 1556-GMT
From: CENT01::SYSKERMIT "Alan Phillips, KERMIT distribution" 16-JUN-1986 11:54
Subject: New Release of Kermit for Magiscan 2
Keywords: Magiscan 2 Kermit, Joyce-Loebl, UCSD p-System

This is to announce an updated release of Kermit for the Joyce-Loebl Magiscan 2
image processor, running UCSD p-System. Changes from the previous release are:

    I micro-coded the receive packet routine so data shouldn't get clobered
    when it is being received. This means that transfers can take place at
    greater baud rates. (Though for terminal emulation you are still limited to
    1200 baud because the magiscan cannot scroll faster).

    The receive packet routine is now just a simple loop that puts all the
    characters is a buffer for decoding later.

    The option to use the Winchester on #9 on the Magiscan 2a version has been
    included, also the directory on the 2a disks are larger so this has been
    taken care of in the SYSUNIT.

    For the 2a I have used JL's own image load and save routines as these are a
    lot faster, 2-30secs(depending on wether a floppy or winchester) cf 2.5mins
    for the Magiscan 2.

    A new command has been added, SET MUX number- this command is analogous to
    the one of similar name on the BBC kermit. It enable the user to set a
    delay porportional to the number between each byte of data sent(the default
    is zero).

I hope that will cover all. If there is anything new/or bugs could
you let me know.

     Henry Balen
     c/o Image Processing Group,
     Dept. Physics and Astronomy,
     University College London,
     Gower Street,
     London.

[Ed. - Thanks for thee update, Henry and Alan.  The files are in KER:UCJ*.*
available with FTP at CU20B over the Internet and via BITnet using KERMSRV
at CUVMA.  These files have replaced the old Kermit version.]

------------------------------

Date: 16 Jun 1986 1556-EDT
From: Glenn Everhart, via <LCG.KERMIT@DEC-MARLBORO>
Subject: Announcing MS-DOS Kermit 2.29 for IBM Semi-Clones
Keywords: MS-DOS Kermit, MS-DOS 2.29, IBM Semi-Clone Kermit

I have created MSXCLO.ASM now which is edited from MSXIBM.ASM for MS Kermit
V2.29.  MSXCLO is a "half generic" MS-DOS Kermit that uses the IBM BIOS INT 14H
call for i/o to its comm port. The screen I/O is however exactly the IBM PC
version's, so you get good VT102 emulation but are able to work on a machine
that uses a different serial chip from IBM's but which emulates the IBM BIOS.
The Seeque Chameleon and DG/1 are examples of this sort of box.  The beastie
works OK at 1200 baud, may work a bit faster for file transfers - I haven't
looked.

To use, you need to jumper pins 20 and 6 to get the BIOS to think DSR is high,
else it emits nothing.

I've also made an MSVCLO.LNK which is linker instructions for the clone
version, and MSICLO.INI, which sets the keyboard layout so that the AT keypad's
lower 4 rows are exactly as the VT100's, F1 to F4 become PF1 to PF4, and F7,F8,
f9 and F10 become up, down, left, and right arrows. This is easier to follow at
our site than the "standard" layout.

I intend to come up with an MSXSEEQ.ASM one of these days that will run faster
on a Seequa, but this is of greater general interest.

The speed setting code may only work on setup; the thing defaults to 1200 baud
but can be forced by MODE, then dialing, if desired. I suspect the BIOS is
refusing to change once it sees DSR there... so some care is needed in the
jumpering. Anyhow, much less flaky looking than the old SEEQUA.ASM.

Glenn Everhart

[Ed. - We've built and tested this program on an IBM PC/AT.  Glenn is right,
you certainly do need to cross-connect DTR and DSR, and as he says, the speed
setting code is not entirely reliable.  In fact, on our PC/AT, it seems that
the speed would change from 1200 to 1800 occasionally during CONNECT, and
the only way to get it back to 1200 would be to exit from the program and
use some other utility (like MODE, or the real PC/AT Kermit) to set it back
to 1200.  On the AT, we couldn't transfer files at all, because upon escaping
back from CONNECT, the speed would always change from 1200 to 1800.  But then,
the program wasn't intended to be run on a real IBM system, only on semi-clones
with IBM-compatible BIOS, but with different serial i/o chips.  Everyone with
DG/1's, Seequa Chameleons, and other systems that fall into this category are
encouraged to pick up this version and report back their results.  The files
are in KER:MSXCLO.ASM, KER:MSVCLO.LNK, KER:MSVCLO.BOO, KER:MSVCLO.EXE (if you
can transfer binary file directly) all on CU20B, and on KERMSRV at CUVMA
with the same names, but without the KER: in front or the dot in the middle.]

------------------------------

Date: 20 Jun 1986 0902-EDT
From: Glenn Everhart, via <LCG.KERMIT@DEC-MARLBORO>
Subject: Announcing MS-DOS Kermit V2.29 for the Seequa Chameleon
Keywords: MS-DOS Kermit, MS-DOS 2.29, Seequa Chameleon Kermit

I've now (finally) got a Kermit (the MSXSEE.ASM part anyhow; the rest uses
IBM PC modules) for Seequa Chameleon that works, even at high baud rates (at
least to 19.2, maybe higher; tries up to 38.4). It's interrupt driven and
works nicely, and finally gives the Chameleon and its 8274 port a decently
fast public Kermit.  MSVSEE.LNK is the MS-DOS Link command file to put it
together, and MSVSEE.BOO is the encoded .EXE file.

I expect that these pieces will replace the old SEEQUA.ASM.

Glenn Everhart, RCA Labs, 609-338-6022

[Ed. - Thanks, Glenn!  The files have been placed into KER:MS%SEE.* on CU20B
(available on the Internet via anonymous FTP), and are also available on
BITNET via KERMSRV at CUVMA, and they have indeed replaced the old (circa
November 1983) SEEQUA.ASM in the Kermit distribution.]

------------------------------

Date: Mon 23 Jun 86 16:57:13-EDT
From: Frank da Cruz <[e-mail]>
Subject: MS-DOS Kermit 2.29 Fixes
Keywords: MS-DOS Kermit, MS-DOS 2.29

The MS-DOS Kermit "beware file" now contains patches for the following
problems, which were reported over the past few weeks with version 2.29 of
MS-DOS Kermit.  Thanks to Joe Doupnik for collecting and verifying them (and to
those who submitted them in the first), and for devising some of them himself.

. Current packet number in the file transfer display is not set back to 0 when
  a SEND or GET command is issued to a remote Kermit server.
. Server mode does not always use the negotiated block-check type.
. Receive command fails if it follows a Get which ended with an error message.
. Hayes 1200B internal modem hangs up at inconvenient times.
. Occasional transmission of a null (ASCII 0) flow control character.

The "beware file" is in KER:MSKERM.BWR, available via anonymous FTP from
host CU20B, or MSKERM BWR on CUVMA via BITNET KERMSRV.

It is expected that after a few more weeks, after the bug reports have
settled down, there will be a new release of MS-DOS Kermit that incorporates
these and other fixes, and possibly a few new features.

------------------------------

Date: 23-JUN-1986 11:19:42
From: Alan Phillips <[e-mail]>
Subject: CP/M-80 Kermit Developments
Keywords: CP/M-80 Kermit

Here's the latest news on CP/M-80 Kermit from the UK:

1. CP4TTK.HEX is for a Teletek CP/M-80 micro with an ADM 22 terminal.  It's
   from David Moore, Software Development, APV Automation, Fleming Way,
   Crawley RH10 2YX, UK. Telphone (UK) 0293-51890.  Source will probably be
   built into Bertil Schou's 4.07 release.

2. Bertil has produced what he's calling version 4.07 (wonder what happened
   to 4.06???), and it's about ready for test release. We'll put it out over
   here to get out the major bugs, than think about whether we should get the
   pre-release stuff to you for more general use. Bertil has split the SYS file
   into one per implementation, fixed the outstanding bugs in the system-
   independent stuff, and added a few features that we found were needed to
   talk to a common, but UK-specific mainframe version.

   One thing that occured to me is that we ought to change the naming structure
   of the files to match the MS-Kermit method, now we've split the SYS file.
   Having CP4 as the prefix dosn't give enough characters, so how do you
   feel about renaming it to CP? Then we can use

         CPSxxx.ASM   for system independent source
         CPXxxx.ASM   for system dependent
         CPVxxx.HEX   for the hex files

   Let us know what you feel on that.

[Ed. - The new naming is just fine.  The CP4 prefix was only to distinguish
the then-new version from the previous one (whose prefix was CPM), because
they had to coexist for a while.  Thanks to Bertil for doing all this work,
and to you for coordinating it with us.  Now that the system-dependent files
are all separated, I hope someone (maybe Bertil?) can take on the task of
making them compatible with the MODEM overlay files, so that Kermit and MODEM
(XMODEM, YMODEM, MEX, etc) can share the same set of overlays.  The new
version will be announced on Info-Kermit when it arrives.]

------------------------------

End of Info-Kermit Digest
*************************
-------
14-Jul-86 11:58:35-EDT,11600;000000000000
Mail-From: SY.CHRISTINE created at 14-Jul-86 11:57:35
Date: Mon 14 Jul 86 11:57:35-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #1
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Mon, 14 Jul 1986       Volume 5 : Number 1

Today's Topics:

                     Kermit Now Available for Atari ST
                      Info-Kermit-Request ID confusion
                           PDP-11 Kermit Binaries
                        Using VMS Backup with Kermit
                        Swedish characters in Kermit
                      RE: Swedish characters in Kermit

----------------------------------------------------------------------


Date: Thu 3 Jul 86 15:37:22-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit Now Available for Atari ST
Keywords: Atari ST Kermit

This is to announce Kermit for the Atari ST series of personal computers,
contributed by Bernhard Nebel, Technische Universitaet Berlin
([e-mail]).  The program is written in DRI C, and is based upon
the OS9 version of Kermit, which was in turn based on the original (simple)
UNIX Kermit.  The program transfers text and binary files, can do wildcard
sends, and includes the necessary settings for communicating with IBM
mainframes (parity, handshake, 8th-bit prefixing).  IBM communications is
one major advantage of this program over the Kermit program that DRI has
been distributing with their GEM developers kit (and which they never
submitted to Columbia Kermit Distribution), and another is that this one
(unlike DRI's) actually employs the GEM user interface.

GEM Kermit does not provide a terminal emulator, nor does it manipulate
RS-232 parameters itself.  Instead, it relies on existing accessories from
the desk menu to supply these functions.  Bernhard has also supplied a
special IBM line-mode terminal accessory.

The source consists of C and header files, and there are also some
"uuencoded" binary files for the Kermit program itself and various
accessories and resource files.  As originally submitted (via BITNET mail),
the file names had the prefix ST, but since that prefix was already in use
for Software Tools Kermit, I changed the names of the files from STK*.* to
AST*.*.  In most cases this was a simple string replacement, but STKERM.*
became ASTKER.*.  Also UUENCODE.C and UUDECODE.C became ASTUUE.C and
ASTUUD.C, respectively.  I also changed (I hope) all internal references to
these filenames accordingly.

The files are available in KER:AST*.* on CU20B via anonymous FTP on the
Internet, or on BITNET from KERMSRV at CUVMA, and should appear within a
reasonable amount of time at Oklahoma State for UUCP access.  ASTKER.DOC is
the documentation (in English), which includes installation instructions.

------------------------------

Date: Fri 11 Jul 86 13:50:11-EDT
From: Ken Rossman <[e-mail]>
Subject: Info-Kermit-Request ID confusion
Keywords: Info-Kermit-Request

My apologies to those of you who sent mail to Info-Kermit-Request and got
it bounced back to them with a "No such directory" error.  We have been
moving files and directories around on the system lately, and the
redistribution list to which "Info-Kermit-Request@CU20B" points was moved
along with everything else, but the list was not updated.

It is fixed now.  Sorry for any inconvenience.  /Ken

------------------------------

Date: Mon 7 Jul 86 14:08:20-EDT
From: Frank da Cruz <[e-mail]>
Subject: PDP-11 Kermit Binaries
Keywords: PDP-11 Kermit

For those who are able to transfer files from CU20B using FTP or NFT,
and who need the latest release of PDP-11 Kermit (for RSX, RT, or RSTS),
the 8-bit binary .TSK or .SAV images are now available in KB:K11*.*.  These
are considerably smaller than the .HEX files in the main distribution, and
require no postprocessing.  Thanks to Brian Nelson for sending them in on
diskette.

------------------------------

Date: Thu 10 Jul 86 09:19:47-EDT
From: Frank da Cruz <[e-mail]>
Subject: Using VMS Backup with Kermit
Keywords: VMS Kermit

Apparently, VMS Backup cannot create a saveset on disk with a blocksize
of 512, which is the blocksize used by VMS Kermit when you give the
"set file type fixed" command.  To remedy this situation, Gary Stebbins of
DEC wrote a little procedure for converting VMS Backup savesets to and from
blocksize 512, to allow these files to be transferred with Kermit.  Use of
Backup in this way permits convenient transfer of a group of unlike or
complex files in a single Kermit operation, such that all their FILES-11
and RMS attributes are preserved after transfer.  Thanks to Bernie Eiben for
sending it in.  The files are in KER:VMSBAK.DOC and KER:VMSBAK.BAS.

------------------------------

Date: Mon 7 Jul 86 19:32:24-EDT
From: Frank da Cruz <[e-mail]>
Subject: Re: Swedish characters in Kermit
Keywords: Swedish characters

[Ed.- This is in response to those of you interested in getting Swedish
characters on your screen during terminal emulation using Kermit.]

Unfortunately, there's no "standard" version of Kermit that will display
Swedish characters on the screen, because there's no commonly accepted way to
represent Swedish (or Norwegian, or Finnish, or German, or Spanish, or Hebrew,
or...) characters in 7-bit ASCII.  Old versions of IBM PC Kermit (the current
version is 2.29) have been modified to display Swedish characters from a
special font when certain 7-bit ASCII characters are received, but so far there
is no good, general solution to this problem, because of the lack of standards
(or more precisely, the lack of conformity to existing ISO standards).  The
best person to ask about this would be Per Lindberg at the University of
Stockholm (Per_Lindberg_QZ@QZCOM).  He advocates the use of a special console
driver to map between US ASCII and Swedish (or any other) characters.
Unfortunately, doing it this way would interfere with Kermit's built-in VT102
terminal emulation; the only way to get IBM PC Kermit to show Swedish
characters on the screen is modify the program.  But then how do you make the
Norwegians, Finns, Germans, Spaniards, and Israelis happy?  And then what about
the Turks, Russians, Armenians, Japanese, Cherokee, etc etc?

Since it is undesirable to modify the Kermit program for each new "national"
character set to be supported, a better solution might be to adopt a new
mechanism usable at runtime, something like the key redefinition mechanism
(SET KEY).  But such a mechanism would probably be somewhat complicated,
because different systems use different methods to transmit "national"
characters:

(a) Selected 7-bit USASCII characters are redefined, for instance left
square bracket "[" might come out as an umlaut-A on a Swedish terminal.

(b) 8-bit codes are used to represent the national characters.  This might
follow some proposed standard, or it might be completely system dependent
(the IBM PC or DEC Rainbow have built-in 8-bit characters, totally different
from each other).

(c) A shift-in/shift-out sequence might be used to switch between character
sets.  This could correspond with the VT100's ability to switch in and out of
the alternate character set ROM, triggered by ESC ( 1, ESC ( 2, etc.

If anybody knows about a good, general solution to this problem that does not
require the program be modified for every new character set, please speak up.

- Frank

------------------------------

Date: 08 Jul 86 19:39 +0200
From: [e-mail]
Subject: Re: Swedish characters in Kermit
Keywords: Swedish Characters

**KERMIT, IBM PC and national characters.**

Yes, there *is* a standard way to represent national characters with a
7-bit code! Instead of adding more bits, the trick is to shift between
several character sets. The ANSI standard X3.41 escape sequence "SCS"
(Select Character Set) which is implemented in the VT100 and VT102
does this. ANSI X3.41 is related to ANSI X3.64, on which the VT100 is
based. This scheme is also an ISO and SIS (Swedish Institute for
Standards) standard. I suggest that you look up SIS 63 61 27 (ISO ESC
2/8 4/0 and ISO ESC 2/8 4/7 and ISO ESC 2/8 4/8).

My VT100-workalike can shift between vanilla ASCII and SIS using the
ESC ( A, ESC ( B etc. scheme. The characters [ \ ] { | } are umlaut
A:s and O:s (upper & lower case) on the keyboard, and the ANSI ESC
sequence shifts what the screen shows. There is a *big* difference in
difficulty learning which is what: I know without thinking which key
to hit for a left square bracket, but reading a C program with that on
the screen is awful. So I just switch what the screen shows, and no
problem.

BEGIN <flame>

wThe *problem* is IBM, who choose to use a non-standard 8-bit code for
representing national characters. Foo! ALSO they have the WORST
keyboard in history, with *both* USA and Swedish layouts. Double foo!
(They are different, [ is an upper-case letter, so we want it shifted).

END <flame>

To live with this problem, all communications software on their PC has
to talk 7-bit codes with the port and 8-bit codes with the screen and
possibly also with the keyboard. Your (a)-(b)-(c) scheme is sound. To
do this, I suggest you give KERMIT a character translation table for
I/O to COM:, and another table for keyboard layout. This, I beleive,
would solve the problem for all languages on the PC, be they Swedish,
Hebrew or whatever. The tables should be written in assembler (using
MACROs?), and linked with KERMIT giving an .EXE file which works on
swedish-modified PC:s. (Swedish keyboard layout, the right 8-bit codes
to the screen, the corresponding 7-bit codes to/from the port). Thus
nationally flavoured KERMITs can be distributed. (A luser can't hack
and link it, we have to do it and distribute diskettes, which we do
anyway).

The console driver I have been talking about is not a good solution.
However, IBM puts out a program called KEYBSV (KEYBNO for norway etc)
with *all* swedish PC:s which (I think) remaps the BIOS keyboard
driver. But since KERMIT reads the keyboard the hard way (?), this
won't help. (And you don't want to send 8-bit codes to the port!) I
have heard rumours that IBM has a paper with recommendations for
nationalizing software, have you seen it? (I have not). Do try to get
a copy of it, if it exists.

By the way, if you are implementing VT100 in KERMIT (which I think is
a very good idea), you might want to test it with my VTTEST program
which tests all features (and a few bugs...) in a VT100 (VT102). The
program is written in C, and runs under TOPS-10 and Twenex (Sargasso
C) and UNIX. If you don't already have it, I'll send it!

        -- Per Lindberg ([e-mail])
                        QZ - Stockholm U. Computing Center
                        Box 27322
                        S-10254 Stockholm
                        Sweden
                        + 46 8 654500
                        ...enea!suadb!lindberg

        (Im am not with the University of Stockholm, but the Stockholm
        University Computing Center, which is another organisation).

------------------------------

End of Info-Kermit Digest
*************************


-------
18-Jul-86 12:09:47-EDT,31929;000000000000
Mail-From: SY.CHRISTINE created at 18-Jul-86 12:07:51
Date: Fri 18 Jul 86 12:07:51-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #2
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 18 Jul 1986       Volume 5 : Number 2

Today's Topics:

                   Additional BITNET Kermit File Access
                         Amiga Kermit Bootstrapping
                      Extra-Long Packets Specification
                KERMIT Transfer Rates with File Compression
                  MS-Kermit 2.29 Memory Contention Problem
                   Rosetta Stone for MS-Kermit and VT100
                             A Wish List (long)

----------------------------------------------------------------------

Date: Tue, 15 Jul 86 06:19 EST
From: <[e-mail]> (brian nelson)
Subject: Additional BITNET Kermit File Access
Keywords: KERMSRV at Uoft02

Usage of [e-mail]

There is a bitnet server for Kermit files at the node Uoft02. The 'user' is
called KERMSRV and is accessed in the following manner:

from VM/CMS:    CP SMSG RSCS MSG UOFT02 KERMSRV DIR
                CP SMSG RSCS MSG UOFT02 KERMSRV SEND K11*.*

from VMS Jnet:  $ SEND KERMSRV@UOFT02 SEND K11*.*

Please note that any filespec containing wildcard characters will be queued
for a deferred transmission; please do not override this by submitting
multiple requests.  Also, there is no point in sending requests that involve
CUVMA or CUNYVM in the routing. If the traffic is too high, there is a
possibility that requests could be deferred to the next day.

We are connected to Ohio State via 9600 line, then to PSUVM which goes
to CUNYVM when I send you mail. Most of the european traffic seems to go
from PSUVM to GWUVM and then out to EARNET. Anyway, I think we want to
avoid routing that involves CUNYVM. Sorry, if we were farther west then
this thing would be more useful.

The commands are (in Jnet format)

        $ send kermsrv@uoft02 dir FILESPEC
        $ send kermsrv@uoft02 send FILESPEC
        $ send kermsrv@uoft02 vmsdump FILESPEC
        $ send kermsrv@uoft02 help

The 'VMSDUMP' command can be used to avoid EBCDIC translation, thus if you
are running jnet on your vax you can request Kermit-11 binary files.

[e-mail]

[Ed. - Thanks for the information Brian!]

------------------------------

Date:  Wed, 16 Jul 86 16:22 N
From: <[e-mail]>
Subject: Amiga Kermit Bootstrapping
Keywords: Amiga Kermit, Bootstrapping

As I tried to install the Amiga Kermit I found out there was no real
solution for the bootstrap procedure: How could I get the CKIBOO.BAS and
CKIKER.BOO files on our Amiga?

One of the problems was, that if I used a simple BASIC program, buffer
overflows occurred and there was no reliable stop criterium.

That's why I wrote two programs, one for our Vax and one BASIC program for
the Amiga which can do the job.

W. Maessen
Agricultural University,
Wageningen, The Netherlands

P.S.

I didn't have the time to create a composite program which combines
CKIBOO.BAS and this Amiga Basic program, but it sure would save some time.

[Ed. - Thanks!  The programs are listed in the file KER:CKIBOO.MSG.]

------------------------------

Date: Thu 17 Jul 86 13:19:44-EDT
From: Frank da Cruz <[e-mail]>
Subject: Extra-Long Packets Specification
Keywords: Extra-Long Packets, ELP

Recent technological advances have brought high-speed, error-correcting
asynchronous dialup modems into the marketplace, and it won't be long until
they are affordable by ordinary mortals.  The first question some people ask
when they learn of these of these devices is whether their error-correcting
capability has made Kermit obsolete.  The answer is an emphatic no, for at
least two reasons.  First, although error-free transmission may be guaranteed
from modem to modem, it cannot be assurred between modem and computer.
Second, even when the connection between computer and modem is clean, problems
of file delimitation, file representation, and computer-to-computer
synchronization are not solved by these modems.

When new communication technologies provide high-speed, potentially error-free
paths, then file transfer performance is unreasonably hampered by Kermit's
short packets and its stop-and-wait operation.  But (you ask) won't the long
packet extension solve this problem?  Perhaps, for some modems.  But others,
already on the market, will not perform at their peak unless they handle data
in bursts even longer than the 9024-byte maximum provided by this extension.
One such modem, operating in half duplex, wants data in chunks of at least
16K-20K, and others may need even more.

Successful transmission of very long packets, especially at high speeds,
requires effective end-to-end full duplex flow control.  When modems or other
intermediate devices are involved, each device along the chain must be able to
control the flow of data from the devices "upstream."  For instance, if the
receiving computer cannot keep up with arriving data, it must be able to stop
the modem, and when the modem's buffers approach fullness, it must stop the
other modem, which in turn must be able to stop the sending computer, all
without loss of a single byte of data.

But given a virtually error-free path with reliable end-to-end flow control,
Kermit's maximum packet length can be further increased by employing a second
kind of extended header, which is just like the long-packet (LP) header, except
with a 3-byte, rather than 2-byte, extended length field.  The presence of a
3-byte length field is signalled when the LEN field of the packet indicates
(after decoding) a length of one.  The DATA field of such a packet begins with
an extended header in which the first three bytes are the 3-digit base-95
length, and the 4th byte is the header checksum.  This allows for lengths up to
857,374 (95 cubed minus 1).

To ensure that this extension is compatible with Kermit programs that are
unaware of it, we must include it in the negotiations.  Rather than extend the
capability mask into a second byte, we take over one of the reserved bits, and
assign capability #2 (bit 4 of the first capability byte, corresponding to a
value of 16) for extra-long packets (ELP).  The rest of the initialization
string stays the same, but the interpretation of the MAXLX1 and MAXLX2 fields,
which appear at CAPAS+2 and CAPAS+3 respectively, is different.  If the ELP
capability bit is set (regardless of the setting of the LP bit), then the
2-digit base-95 quantity given by MAXLX1 and MAXLX2 should be multiplied by 95
to obtain the intended length.  In other words, MAXLX1 is the "9025's place"
(rather than the 95's place), and MAXLX2 is the 95's place (rather than the 1's
place).  For instance, if the maximum length is to be 30,000, the encoding
could be "#>" (3x9025 + 30x95 = 29,925) or "#?" (30,020).

As with regular long packets, the file receiver tells the sender the maximum
length packet to send.  But now there are more possibilities, since either
Kermit program may support one or the other or both (or neither) long packet
extension.  If the receiver does not support LP or ELP, the sender will send
only normal packets (NP).  If a Kermit program supports ELP, then it should
also support LP, so that it can fall back to LP rather than to NP when the
receiver supports LP but not ELP.

The interesting case arises when the sender supports only LP, but the receiver
supports both LP and ELP.  If the receiver puts the ELP maximum length in
MAXLX1 and MAXLX2, then the sender (which is unaware of the ELP extension) will
interpret these numbers as the LP maximum length, 95 times smaller than what
the receiver intended.  But since the sender goes first in the negotiation, the
receiver sees that the sender does not have ELP capability, and in this case it
can specify a suitably large LP maximum length (like 9024) in its own
initialization string, rather than an ELP maximum length that the sender would
misinterpret.  Without this trick, fallback would occur to a much smaller size.

A few final words of caution are necessary.  First, the longer the packet, the
more rigorous the required error-checking technique; it would be unwise to
transmit packets of thousands of characters guarded by anything less than a
16-bit CRC.  Second, extra-long packets are untried as of this writing; even if
the technique works, performance might be disappointing if the implementation
follows the straightforward path suggested in all the foregoing code.  When
packets are very long, the transmission line can sit idle for extended periods
while packets are being assembled and disassembled.  Although idleness is
unavoidable while the receiver is checking and processing the packet before
ACKing it, the sender can make use of this time to begin assembling its next
packet, so that additional idle time after the ACK is received is avoided.
This trick requires an additional packet transmission buffer, which, for
very long packets, might be hard to find.  Finally, users must know the
required conditions for successful use of long packets, and must request
extended packet sizes explicitly; too many things can go wrong if long packets
are used by default.

------------------------------

Date: Tue, 15 Jul 86 13:19 EDT
From: [e-mail] (Phil Julian, SAS Institute)
Subject: KERMIT Transfer Rates with File Compression
Keywords: Compression

We have found that piping Kermit input through a 'compress' program will
greatly increase the transmission rate when going between a Sperry 5000 Unix
system and an HP 9000 Unix system, using C-Kermit on both ends.  Much of the
improvement may be due to spaces in the original source, and nulls in the
tar format, but the effects of the compression program are much greater than
Kermit's internal space compression.

The first attempt to send the files was

     tar cf - . | kermit -i -s -             on the HP 9000
     kermit -i -k | tar xf -                 on the Sperry 5000

22 megabytes took 8.5 hours to send, with a 31.4% efficiency rate, at 19.2k
baud.

The next attempt to send the files was

     tar cf - . | compress | kermit -i -s -     on the HP 9000
     kermit -i -k | uncompress | tar xf -       on the Sperry 5000

4 megabytes took 1 hour to send, with a 54.6% efficiency rate, at 19.2k
baud.  The improvement was a 74% over using Kermit alone.  The compress
program is in the public domain, and uses the Lempel-Ziv algorithm.

These figures may add to the argument to add space compression algorithms to
the Kermit protocol.  Few systems have Unix-like pipes, so the addition to
the protocol would be useful.

[Ed. - Yep, in fact this technique is suggested in the documentation.  There
are other problems with Unix Kermit performance too, including excessive
copying of data from buffer to buffer, single-character i/o where bulk i/o
would suffice, lack of flow control, etc.  These will be addressed in future
releases.]

------------------------------

From: I. WRENCH <[e-mail]-f>
Date: Wed, 16 Jul 86 09:11:36 BST
Subject: MS-Kermit 2.29 Memory Contention Problem
Keywords: MS-Kermit 2.29 memory contention

In a previous UK newsletter I asked for help with problems using v2.29 of
Ms-Kermit to a DEC 10 system. The symptoms were that files sent from the PC
contained spurious characters on arrival, always in the same places. Several
people replied with sugestions, all of which i tried and seem to have no
success. I managed to get access to kermits on non-DEC machines and tried my
Ms-Kermit out with them - and got exactly the same problem. This lead me to
think that my actual copy of Ms-Kermit (brought down in .BOO form from
Lancaster) might have been corrupted somehow. I brought the .BOO file down
again using a different terminal capture prog than I originally used, and
converted the .BOO file using both the .PAS and .BAS de-hexers - but nothing
changed. This seems to suggest that there was something wrong with the set-up
on the IBM-XT I was using, and with a lot of playing around I traced down the
problem to be a program called INT10 that was being loaded in the AUTOEXEC.BAT
file. This program I believe has something to do with the Hercules graphics
board and I presume was causing workspace contention problems with Ms-Kermit. I
think this was caused as Ms-Kermit was growing in size to the point when the
problem was triggered at the release of v2.29. Incidentally the scroll back
pages function also just stopped working, it just pulled back rubbish onto the
screen. Anyway all is back to perfect working order now, if anyone else was
having similar problems to me i.e a perectly good program just stopped working
properly, and you can't trace it, then look to see what else is resident in
memory. Hope this is of use.

                   Iain Wrench.

[Ed. - See next message.]

------------------------------

Date: 17 JUL 86 13:31-MDT
From: JRD@USU
Subject: RE: MS-Kermit 2.29 Memory Contention Problem
Keywords: MS-Kermit 2.29 memory contention

Iain's difficulties were appearence of strange characters in transferred
files and a trashed roll back screen.  In his most recent note he traced
both to a Hercules supplied Helpful Utility, INT10.COM.

Indeed, Iain. The Hercules display board has characteristics much different
than standard IBM boards. Their INT10 program intercepts Bios Int 10h calls
(video display) and maps them into Hercules compatible form and might also
use memory not belonging to itself. The strange looking characters on the
roll back display were graphics images whereas Kermit expects text and
attributes. I have a legal copy of INT10 here and get similar troubles.
However, Kermit runs well with the EGA boards, in text mode.

Thanks for the specific symptoms. I had seen your original note in the UK
Kermit newsletter, but have not had time to reply.

        Regards,
        Joe D.

------------------------------

Date: Mon, 14 Jul 86 21:51:40 EDT
From: [e-mail]
Subject: Rosetta Stone for MS-Kermit and VT100
Keywords: VT100 Emulation, Keyboard settings

After (too much) hacking around with various other terminal programs and
with Kermit, I've come up with a reasonably useful general reference for
mapping the vt100 keypad with MS-Kermit.

No single keyboard mapping is "best"; it all depends on your particular
application.  In particular, some keyboards are best mapped logically (f1
corresponds to numeric pad 1) and others are best done physically (the one
in the upper corner is the same in both).  Instead of trying to please
everyone, here's a way to roll your own with a minimum of effort.

The first set of diagrams are pictures of the keyboard mappings for all the
vt100 implementations I could find.  There aren't too many, but these few
show the various approaches nicely.

The second set of diagrams should save some time when you build an
initialization file.  In it are the results of SHOW KEY for all the function
keys and all the numeric keypad keys.

(The numeric keypads shown have an enter key on them, since they were done
on a Zenith 158.  With that exception they should be generally applicable.
I don't have an enhanced AT keyboard to play with.)

Edward Vielmetti
Computing Center MicroGroup
University of Michigan
[e-mail]


 +----+----+----+----+
 | PF1| PF2| PF3| PF4|       This is the layout of a real, live
 +----+----+----+----+       VT100 keypad.
 |  7 |  8 |  9 |  - |
 +----+----+----+----+
 |  4 |  5 |  6 |  , |
 +----+----+----+----+
 |  1 |  2 |  3 |    |
 +----+----+----+entr|
 |    0    |  . |    |
 +---------+----+----+


 +----+----+----+----+
 | SF1| SF2| SF3| SF4|       This is the layout of the VT100 emulation
 +----+----+----+----+       for Procomm v2.3.
 | F7 | F8 | F9 | SF5|
 +----+----+----+----+
 | F4 | F5 | F6 | SF6|
 +----+----+----+----+
 | F1 | F2 | F3 |    |
 +----+----+----+ SF8|
 |   F10   | SF7|    |
 +---------+----+----+

 +----+----+----+----+
 | F1 | F2 | F3 | F4 |       This is the layout of the default VT100
 +----+----+----+----+       emulation for MS-Kermit v2.29.
 | F5 | F6 | F7 | F8 |
 +----+----+----+----+
 | F9 | F10| SF1| SF2|
 +----+----+----+----+
 | SF3| SF4| SF5|    |
 +----+----+----+ SF6|
 |   SF7   | SF8|    |
 +---------+----+----+

 +----+----+----+----+
 | F1 | F2 | SF1| SF2|       This is the layout for PC-VT v8.4.  Note
 +----+----+----+----+       the two keys mapped to the same
 | F3 | F4 | SF3| SF4|       VT100 key in the case of 0 and enter.
 +----+----+----+----+
 | F5 | F6 | SF5| SF6|
 +----+----+----+----+
 | F7 | F8 | SF7| SF8|
 +----+----+----+    |
 | F9   F10| SF9|SF10|
 +---------+----+----+

 +----+----+----+----+
 | OP | OQ | OR | OS |       These are the escape sequences sent out
 +----+----+----+----+       by these emulations.  Read "OP" as
 | Ow | Ox | Oy | Om |       <esc>OP.
 +----+----+----+----+
 | Ot | Ou | Ov | Ol |
 +----+----+----+----+
 | Oq | Or | Os |    |
 +----+----+----+ OM |
 |   Op    | On |    |
 +---------+----+----+

 +----+----+----+----+
 | F10| SF1| SF2| SF3|       This is the VT100 emulation
 +----+----+----+----+       defined by PC1:MSKERMIT.INI
 | F7 | F8 | F9 | SF4|       for the University of Michigan's
 +----+----+----+----+       MTS system.
 | F4 | F5 | F6 | SF5|
 +----+----+----+----+
 | F1 | F2 | F3 |    |
 +----+----+----+ SF6|
 |  Grey - | SF7|    |
 +---------+----+----+
1
 Show Key for the function keys:

 +----+----+   +----+----+   +----+----+   +----+----+
 | f1 | f2 |   | 596| 597|   |1118|1119|   |2152|2153|
 +----+----+   +----+----+   +----+----+   +----+----+
 | f3 | f4 |   | 598| 599|   |1120|1121|   |2154|2155|
 +----+----+   +----+----+   +----+----+   +----+----+
 | f5 | f6 |   | 600| 601|   |1122|1123|   |2156|2157|
 +----+----+   +----+----+   +----+----+   +----+----+
 | f7 | f8 |   | 602| 603|   |1124|1125|   |2158|2159|
 +----+----+   +----+----+   +----+----+   +----+----+
 | f9 | f10|   | 604| 605|   |1126|1127|   |2160|2161|
 +----+----+   +----+----+   +----+----+   +----+----+
  unshifted      shifted      with ctrl     with alt

      +----+----+----+----+          +----+----+----+----+
      |Home| Up |PgUp|Gry-|          |  7 |  8 |  9 |Gry-|
      +----+----+----+----|          +----+----+----+----|
      |Left|    |Rght|Gry+|          |  4 |  5 |  6 |Gry+|
      +----+----+----+----+          +----+----+----+----|
      | End|Down|PgDn|    |          |  1 |  2 |  3 |    |
 +----+----+----+----+entr|     +----+----+----+----+entr|
 |   Ins   |   Del   |    |     |    0    |    .    |    |
 +---------+---------+----+     +---------+---------+----+
          cursor pad                   numeric pad


      +----+----+----+----+          +----+----+----+----+
      | 71 | 72 | 73 | 74 |          | 583| 584| 585| 586|
      +----+----+----+----+          +----+----+----+----+
      | 75 |    | 77 | 78 |          | 587| 588| 589| 590|
      +----+----+----+----+          +----+----+----+----+
      | 79 | 80 | 81 |    |          | 591| 592| 593|    |
 +----+----+----+----+ 28 |     +----+----+----+----+ 540|
 |    82   |    83   |    |     |   594   |   595   |    |
 +---------+---------+----+     +---------+---------+----+
         unshifted                       shifted

      +----+----+----+----+
      |1143|    |1156|    |
      +----+----+----+----+
      |1139|    |1140|    |
      +----+----+----+----+
      |1141|    |1142|    |
 +----+----+----+----+1052|
 |         |         |    |
 +---------+---------+----+
          with ctrl

------------------------------

Date: Wed, 16 Jul 86 16:17 PDT
From: [e-mail]
Subject: A Wish List (long)
Keywords: MS-DOS Kermit, MS-DOS 2.29

     For the last year or so I have been using MS-KERMIT on a PC-XT to
connect to a variety of computers.  These include the CRAYs here at
NMFECC and the local VAX running VMS.  I have been collecting a
wish-list, and thought it was time to post it and see if some of the
items might be added to the "official" list in the BWR file.

     Here goes:

1) Any new text coming from the host or typed by the user should appear
at the end of the last screenful, not at the cursor location.  Operator
messages from the host, as well as messages from programs I am running,
often obscure critical text on the screen while I am examing something I
did five minutes earlier.

2) Seven pages (or so) of screen memory is nowhere near enough.  I'd
like to be able to use as much memory as I want, (say) 30 pages of
screen memory.  Better still would be an "infinitely" long memory,
with simultaneous storage into a disk file that would serve as both a
log and the top half of the screen memory.  This might also allow you
to view the screen memory of your last session simply by paging back
during the current session.  The present log is awkward since a) it
isn't available online, and b) it contains a lot of control
characters from backspacing over typing errors, and from screen
editing sessions on the VAX when I forget to turn off the logging.

3) Printing and dumping.  It would be nice if one could somehow "mark" a
section of the screen memory and either print it or save it to a file.

4) The CRAYs do not respond to input characters until the carriage
return is pressed (this is also true of many computers accessed through
networks).  Thus, screen editing is impossible without use of a
"co-editing" program which runs on the PC and the CRAY simultaneously.
It might be a good project to develop standards for such a system.
NMFECC and LCC both support a system called SED which seems to work
well.

5) Again because of the above characteristic, editing of input lines
is limited to backspacing.  A true line-editing capability (as on the
VAX, or in the DOS supplement/shareware program CED) could be
incorporated into the terminal emulator.  This is the natural place
for such a capability, since the line could be echoed locally,
edited, then sent when the return key was pressed.

6) A related wish is command-line recall, either VMS/CED-style (press a
key repeatedly and old command lines reappear in reverse order) or by
highlighting text in the screen memory somehow, then bringing the line
into the current command buffer for editing by pressing a key, then
sending it with a return.  On our system, linefeed characters echo as
exclamation points, and so a facility for translating exclamation points
into linefeeds (and echoing linefeeds as !'s during local pre-
transmission editing) would be useful - of course, the mapping should
be general enough to support a variety of host computer idiosyncrasies.

7) When I assign a character string to a key, then press the key, often
the characters appear too rapidly for our CRAY terminal concentrator to
accept them.  It would be useful if the speed with which character
strings were sent to the host could be selected by the user.  Since when
I talk to the VAX I press the arrow keys a lot, and these send
three-character sequences, I'd like these to be sent at full speed - so
some means of specifying the "speed of paste" when each key is defined
would be best.  (Also, it would be nice if the interactive key
definition procedure were streamlined so that the user need only press
the key they wished to define - why do we need to know the scan code?).

8) It would be nice to have a "bare bones" mode that used DOS for the
keyboard handling.  My text editor has a facility whereby one can
start a command processor, and use the editor commands to paste old
lines, etc.  Thus, one gets command line recall and a log when
running compilers on the pc.  It would be nice if I could run codes
on the CRAY this way.

     Also, I have some questions about what happens when one is not
in connect mode and a message comes in over the serial port from the
mainframe.  When I am at Kermit command level after a ctrl-]c, then I
reconnect, data is missing from the screen (if I had been listing my
files, the list would be garbled).  I have had better luck with
ctrl-]p.  What I'd really like is a full explanation of what happens
- for example, does the disk actually run in a background mode to
update the log when an interrupt comes in over the port?

     Finally, I expect that some of the above wishes might be
answered by use of either a) a windowing program, b) a mouse with
appropriate driver for cut-and-paste, or c) a keyboard enhancer
program, and wonder if anyone has learned any useful tricks.  I use
SIDEKICK all the time with MS-KERMIT, and find it useful to paste
frequently used lines from the notepad; SIDEKICK allows the user to
control the speed of pasting, and so I avoid the problem alluded to
in (7) above.

     In general, I'm very pleased with MS-KERMIT; I would appreciate
any comments on these ideas from either the KERMIT developers or the
user community.  Comments can be posted if of general interest; other-
wise I can be reached at:
              [e-mail]
or some such thing depending on the syntax of your local mail utility;
Im on the LLV VAX on the MFENET at Lawrence Livermore National Laboratory.

------------------------------

Date: 16 JUL 86 21:47-MDT
From: JRD@USU
Subject: RE: Wish List
Keywords: MS-DOS Kermit, MS-DOS 2.29

Mr. Friedman ([e-mail]),

        Your long "wish list" arrived in the mail from Columbia and, since
I have been doing much of the MS Kermit development recently, perhaps I can
comment on some of the points.

        As I understand things, the bulk of the wishes are closely related
to offsetting deficiencies of the mainframe host, full editing facilities
in particular.

Point 1: While in connect mode incoming text should be placed at the end
of previously received text rather than at the cursor position (if the screen
has been rolled back manually). True, but. This would require a healthy amount
of screen and memory management code and employment of multiple pages of video
memory (on what kind of display adapter?) to avoid massive flickering between
old and new screens. And, think about what must be done if the regular screen
scrolls up. Just telling the host Xoff can work wonders most of the time;
exiting connect mode, selecting port 2, and returning to connect mode will
also preserve the old screen (but will lose new incoming text from port 1).

Point 2: Five screens of roll back are too few, 30..inf would be much nicer.
Again, these things can be done, at a stiff price in both runtime code
space and programmer effort. An easy work around is to make a hard copy
listing as you go (Control PrtSc does the trick). Micros are spoiling us.

Point 3: Selectively edit a screen for dumping to a printer. See below.

        Modern full screen editors on micros have many of the characteristics
you wish. They cost $200+ when Sold in large quantities and they just edit.
Some serious duty editors of this kind are Brief, Emacs, Epsilon, and Kedit.
For capturing program output to a window have a look at Epsilon by Lugaru;
I'm using Brief. Some day, "real soon now", mainframe editors will catch up,
but at a very hefty price in i/o channel facilities (38 Kbaud+) and scads of
real memory for buffers, etc. My students have remarked to me that because
I have pronounced ideas on what editors should do then why not write my own.
Yes, certainly, but what about all the other interesting things to do?

Point 4: Cray editors are line oriented rather than full screen types. Yep!
Only Real Programmers use Crays and RPs are happy with card images and
patching binaries; I was & did. Try a copy of Emacs. By the way, why are
you burning up Cray time doing editing? Don't you fellows at LLL work into a
mere-computer front end to handle i/o, scheduling, and other routine chores?
(Must be the SDI money.)

Point 5: Line editing Helpful Utilities. These still work under Kermit!
Mouse menus can be very useful for classes of minor tasks, and Kermit loves
the little fellows. Microsoft supplies a very good menu program with their
mouse; I have both.

Point 6: Command line recall buffer and translation of strange input chars.
Kermit already has too many buffers and the command parser is Byzantine
trying to do the present command line editing (in system independent fashion).
Limited translation is being considered, particularly for European characters.

Point 7. Pace sent characters. Either lower the baud rate or have the troops
get a concentrator with typeahead buffering. If we were to pace characters
then most of the other users would hit the overhead. Also, key redefinition
could be much smoother. Sure could, and we are thinking about doing so
when time is available; it will not replace Prokey et al. Also, how do you
get file transfer packets through a slow concentrator?

Point 8: Bare bones keyboard handling (let DOS do it). MS Kermit obtains
keyboard info by both DOS calls and Bios calls; it does not go to the
keyboard hardware and the like. It is about as bare bones as possible. If you
were to use a fancy console handler which passes along scan codes properly
then it probably would be compatible with Kermit. Most such utilities do not
do so yet.

Question: What's with the serial port?
        Kermit returns the serial port to its original owner when Kermit
does not have direct need of it, such as between file transfers. That is
a very good safety feature for a program which uses interrupts for reception.
As you may notice, between file transfers or Connect sessions there is no
implied source/sink for serial port information; thus, Kermit is unaware
of the port at such times. If the port were left active then Kermit would
have to be prevented from accessing conflicting programs or letting the user
Push to DOS, etc just to keep the interrupts from calling a perhaps non-
existant interrupt routine (a disaster) or having a buffer overflow.
When DOS grows up to be a multi-tasking o/s then we can consider letting
Kermit run in the background; WINDOWS/DOS 5.0 does not seem to be there yet.
I also run DECnet-DOS on my micro, and it tries to permanently install itself
as an extension of DOS plus "own" the serial port most of the time. It runs
the port in the background and messes with DOS in a very serious way.

Comment added by me. Kermit as a whole is written and improved by volunteers,
using an enormous number of man hours, and we earn exactly zero for doing so.
Thus, features get added when someone decides to do them (best to let Columbia
know first since others may be doing the same thing). Many of the items on
your wish list fall into the very sophisticated technique department.
Fortunately for all of us, many of the Kermit contributors are adept at such
matters, when they have the time. Suggestions such as yours provide a rich
menu of interesting things to consider. Like to have a go at one or two?
And not least, thanks for the nice words about the existing Kermit; they help.

        Regards,
        Joe D.

------------------------------

End of Info-Kermit Digest
*************************
-------
22-Jul-86 16:21:49-EDT,17314;000000000001
Mail-From: SY.FDC created at 22-Jul-86 16:20:13
Date: Tue 22 Jul 86 16:20:13-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V5 #3
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 22 Jul 1986       Volume 5 : Number 3

Today's Topics:
                  New Kermit for the Commodore Amiga
                            HP1000 Kermit
                      Bug in MS-DOS Kermit 2.29
                             Sanyo Kermit
                          BOO File Problems
                   Extra-Long Packets Specification
              Some Thoughts about Long Packets in Kermit
                          CMS Kermit Problem

----------------------------------------------------------------------

Date: Mon 21 Jul 86 17:31:29-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Kermit for the Commodore Amiga
Keywords: Amiga, Commodore Amiga, C-Kermit

This new version of Kermit for the Commodore Amiga is based on the current
C-Kermit release, 4D(060), and has been sent in by Jack Rouse of SAS
Institute (Cary, NC).  It replaces (by mutual agreement) the Amiga Kermit
previously submitted by Davide Cervone of the University of Rochester.  The
CKI*.* files have been replaced, except for the bootstrapping files, which
remain where they were.  Also, several of the system-independent C-Kermit
modules have been restored to their original condition (the previous Amiga
Kermit release altered them to include "printf2" and "printf3" functions;
these are no longer needed).  The new release includes help, documentation,
beware, and "boo" files, along with source.  The files are in KER:CKI*.* on
CU20B, plus (if you want to build from source) the other C-Kermit source
files (CKU*.C, CKU*.H, CKC*.C, CKC*.H, CKWART.*, CKCPRO.W).  The files are
also available on BITNET from KERMSRV at CUVMA.  For those who cannot get at
these files over the networks, or who have trouble with the bootstrapping
procedure, Jack will send an Amiga diskette including source and executable
program if you send him a check for $6.00:

  Jack Rouse
  106 Rubin Ct., Apt. A-4
  Cary, NC  27511

The CKI*.* files from the previous Amiga Kermit are still available on CU20B
as KO:CKI*.*.  Jack is also working on an adaptation of C-Kermit to Apollo
Aegis.  This will be announced when it is received.

------------------------------

Date: 17 Jul 86 17:20 +0200
From: [e-mail]
Subject: HP1000 Kermit
Keywords: HP1000 Kermit

For a long time I have tried to install Kermit on every machine in our
company's multivendor computer hardware environment.

The biggest problems arose with the HP1000 (RTE-6/VM) we still have, but
finally I could solve them mostly.

The Fortran-Kermit (HPM* files) you distribute contains some bugs, but we
could get it running with an HP150-Kermit, but not with VAX- or
DEC20-Kermit. For a long time we had to use the HP150-Kermit (with debug
mode enabled) as an intermediate for transfers to other hosts. Not good, but
better than nothing.

When the Pascal-Kermit (HPA* files) arrived, we hoped to get it working,
because the Pascal-Compiler is identical on RTE-6/VM and RTE-A. But we ran
into big troubles, and as a regular reader of Kermit Info Digest I wonder
that nobody has complained about this Kermit version.  These were the main
problems:

1. Two source files are missing (PASCAL.PAS, VMAST.PEX).
2. A compiler directive (STANDARD_LEVEL HP1000) is missing in some modules,
   causing lots of compilation errors.
3. The revision number of the Pascal compiler has to be 2440
   (or later) and not 2401 as stated in the instructions.

We did a lot of investigations to find this, but after adding the correct
compiler directive and installing a new version of the Pascal compiler, we
gave up, because of the missing source files. They contain only procedure
headers, and backtracing from the compilation errors it is possible to write
them again. But we did not want to put so much work in it.  I also tried to
phone the author of this Kermit, but he went off in his holidays for 4 weeks
just half an hour before I called him, and nobody else was there to help me.

But finally everything turned into happiness, when I received a new Fortran
version of Kermit distributed at an HP1000 conference in Washington (DC). I
could compile and link it without any problems and it worked instantly.
Later I discovered a bug concerning the time-out setting of the terminal
port, but this was obvious and easy to correct. This Kermit version supports
remote and local (very difficult on a half-duplex machine!) operation as
well as server mode. And, best of all, this Kermit runs on RTE-6/VM and
RTE-A as well, the type and revision(!) of the operating system is
selectable by parameters.

I suggest, that this Kermit version should replace both the HPM* and HPA*
files in the official Kermit distribution.

I am sure that the author will give you the most recent version of this
Kermit (which I do not have, yet) if you contact him:

  Paul Schuman
  E-Systems, Inc., Greenville Division
  P.O. Box 1056 CBN 101
  Greenville, Texas 75401
  Phone [phone]
  Telex 701511 mfogvl ud

In the meantime we got MS-Kermit 2.29 on our ATs, and we discovered that the
HP1000-Kermit does not like it (file transfer with version 2.27 works
perfectly). We have found out, that the 2.29-Kermit precedes every packet
with XON or binary zero depending on the setting of the flow control, and
the HP1000-Kermit seems to have a bug in its packet parsing routine.  Maybe
this is already corrected in the next release, which I will receive in
October presumably, but is now available from Paul Schuman as said above.

Best regards, Michael.

Real Name:     Wolfgang Michael Terenyi
MAILNET:       W._Michael_Terenyi_(SANDOZ)@QZCOM.MAILNET
ARPA/CSNET:    W._Michael_Terenyi_(SANDOZ)[e-mail]
JANET:         W._Michael_Terenyi_(SANDOZ)[e-mail]
G3 Fax:        [phone]
Telex:         132287 sfi a
Real Address:  SANDOZ Research Institute
               Brunner Str. 59
               A-1235 Vienna
               Austria, Europe

[Ed. - Many thanks for the information.  We have written to Paul Schuman and
asked him to send it in.  It will be announced when (if?) it arrives.  Also
thanks for describing the MS-DOS Kermit problem so succinctly (see below).]

------------------------------

Date: Fri 18 Jul 86 11:22:05-EDT
From: Frank da Cruz <[e-mail]>
Subject: Bug in MS-DOS Kermit 2.29
Keywords: MS-DOS Kermit, IBM Mainframe, HP1000, Harris

The new MS-DOS Kermit has a serious problem when used with certain kinds of
host computers, including IBM mainframes, HP-1000's, and Harris minis.  The
symptom is that file transfer doesn't work -- either at all, or else rarely.
The cause is that when flow-control is set to NONE, then Kermit erroneously
precedes each packet with a NUL (ASCII 0) byte.  Most hosts are immune to
NULs on the communication line, but an IBM mainframe with VM/CMS will
discard all following characters up to the break character (CR), in Kermit's
case the entire packet.  On the Harris, a NUL reportedly kills the entire
Kermit process.  See the previous message for what happens on the HP-1000.
A patch is available for those who are affected by this problem.  Since it
is rather long, it has been added to the end of the "beware file".  This
file is available as KER:MSKERM.BWR on CU20B (via anonymous FTP on the
Internet) or MSKERM BWR on CUVMA (via KERMSRV on BITNET).

An updated release of MS-DOS Kermit containing fixes for this and all the
other reported problems, plus a few surprises, should be available in late
summer or early autumn.  In the meantime, source-level patches will continue
to be listed in the beware file.

------------------------------

Date: 1986 Jul 21   19:43 EST
From: Bob Babcock <[e-mail]>
Subject: Sanyo Kermit
Keywords: Sanyo MBC Kermit

The Sanyo release of kermit version 2.29 has a bug which locks it at 300
baud.  I got a copy of the sources over KERMSRV and fixed the problem.  I
will send you the revised MSXMBC.ASM shortly.

I also got copies of the IBM specific routines and created a Sanyo version
with essentially all of the IBM features.  This version requires an optional
video board which only some machines have.  (The board was produced by Sanyo
to make the MBC series sufficiently IBM compatible to run Lotus 123.)  I
have a couple little things which I may work on before sending the sources
off.  I have named the Sanyo specific routines MSX55X.ASM, MSY55X.ASM and
MSZ55X.ASM, but you can change that if you prefer.  Because of the video
board requirement, these do not replace MSXMBC.

[Ed. - Thanks.  The names are fine, though it would be preferable if the
two Sanyo versions could be combined into one, which could tell at runtime
whether the option board was present.  The new stuff will be announced when
it arrives.]

------------------------------

Date: Mon, 21 Jul 86  21:07:57 EDT
From: "Roger Fajman" <RAF@NIHCU>
Subject: BOO File Problems
Keywords: BOO File, Bootstrapping, MS-DOS Kermit, KERMSRV, EBCDIC

I figured out some problems that I encountered with BOO files and the IBM
PC.  There were two:

(1) If you use the PUNCH command of KERMSRV@CUVMA on BITNET, the file comes
with trailing blanks, which will cause the EXE file generated to be
incorrect.  The BOO format doesn't use blanks, so trailing blanks can be
safely stripped before the file is processed.  However, MSBPCT.BAS does not
do this, so you had better.

[Ed. - The MSBPCB and MSBPCT programs should indeed strip trailing blanks.]

(2) When getting BOO files through BITNET, take care with your EBCDIC-ASCII
translations.  Ours is the same as Columbia's, except for curly braces.
Most BOO files don't have curly braces, but MSBPCT.BOO (the C version of the
IBM PC BOO file decoder) does have a curly brace in it that represents a
count of NULs.

BOO files don't contain any kind of internal consistency check, such as a
byte count and/or checksum, so problems such as these just give you EXE
files that don't work.

[Ed. - It would have been nice to include consistency checks in .BOO files,
but since checksums or CRCs are based on the numeric, internal
representation of the characters, you get into trouble when going between
ASCII and EBCDIC systems.  Actually, when you use the MSBOOT.FOR/MSBPCB.BAS
pair, there is a minimal kind of consistency check -- the length of each
line is transmitted along with the line by MSBOOT and checked by MSBPCB.
But you're right, you don't even get this with the MSBPCT programs.  That's
why the recommended technique is to use these bootstrapping programs to
get a Kermit program that SEEMS to work onto your PC, and then use that
Kermit program to get another copy of itself, with error checking, etc.]

------------------------------

Date: Sat, 19 Jul 86 23:44:48 edt
From: [e-mail] (Roy Smith)
Subject: Re: Extra-Long Packets Specification
Keywords: Long Packets

> The first question some people ask when they learn of these of these [sic]

[Ed. - oops]

> devices [error correcting modems] is whether their error-correcting
> capability has made Kermit obsolete.  The answer is an emphatic no [...]

I know this list is for discussing Kermit, but I couldn't help noticing that
exactly the same question is asked about uucp.  Time and time again I've
seen people suggest that all the overhead of computing checksums that uucp
does could be eliminated if only you had error correcting modems.  Come to
think of it, I've seen it asserted more than once that you don't really need
TCP/IP on an ethernet, since you don't have to worry about mangled packets.
Will people never learn?

As it happens, while I was typing in the first paragraph of this message, a
bunch of "/usr: file system full" messages popped up on my screen.  Kermit,
uucp, and ftp (and presumably Decnet, Appletalk, Xmodem, and so forth) all
deal with full file systems in some rational way.  Error correcting modems
do not.  It doesn't do you much good to move the bits from here to there if
they just get dropped on the floor at the other end without any warning.

Roy Smith, {allegra,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016

------------------------------

Date: Sat, 19 Jul 86 01:18:10 edt
From: [e-mail]
Subject: Some Thoughts about Long Packets in Kermit
Keywords: Long Packets, Sliding Windows

I see a potential problem with long packets - just because two kermits have
the capability, it might not make sense to use it.  They may be connected
together by a regular modem.  You can have some user selectable option, but
the less the user has to know about the lower levels, the better (getting
all the options set correctly can be difficult now).  One solution might to
use adaptive packet sizing.  They could start small, and rapidly grow larger
as it is determined that the link is error free.  Another nice feature
(which I'm sure has been mentioned before) would be packet stacking and
built in compression.  It might soon become difficult to determine where to
do some of these things - in kermit or in the modem.

  - Jon Zeeff    ihnp4!umich!umix!b-tech!zeeff
         [e-mail]

[Ed. - Well...  There is also a packet-stacking extension to Kermit (called
"sliding windows"), which is independent of, and not mutually exclusive
with, long packets.  However, sliding windows (a) require full duplex
communication, and (b) are complex to program.  Any particular
implementation will depend on peculariarities of the system -- interrupts,
multiprocessing, etc -- in order to achieve full duplex transmission.  Long
packets are the best way to boost performance in a half duplex connection
(and many of these new modems are half duplex), but you're right: long
packets should not be sprung on the user by default.  The user should know
the necessary preconditions -- a very clean connection, large input buffers
at the receiving end, and effective, reliable end-to-end flow control.]

------------------------------

Date: 1986 Jul 21   19:43 EST
From: Bob Babcock <[e-mail]>
Subject: CMS Kermit Problem
Keywords: CMS Kermit

I have always found it difficult to run Kermit talking to an IBM mainframe
running CMS over a straight ascii line.  The problem is that line noise
during a file transfer tends to interrupt the Kermit process and pop you
into CP.  To resume execution of Kermit, you need to send a BEGIN command (b
is enough).  But you can't do this without aborting the transfer at the
local Kermit, assuming that it hasn't already timed out before you noticed
the problem.  This problem does not arise if Kermit is run over a series/1
interface or equivalent, but the IBM mainframe which is our link to BITNET
does not have series/1 software which would allow Kermit to run.  I have
thought about modifying Kermit at different levels, either allowing the user
to hit a key and transmit a B, or making Kermit smart enough to recognize
the problem and automatically send the begin command.  Do you know if anyone
else has attacked this problem?  I don't want to reinvent the wheel.  I
should emphasize that this is not a problem with the CMS Kermit, but rather
is a characteristic of the environment it runs in.

[Ed. - This is only a specific instance of a common problem: what should the
local Kermit do when the remote Kermit "goes away" during file transfer?
When the remote Kermit goes away, you're confronted by some aspect of the
underlying system, or in some cases nothing at all.  The possibilities are
simply too numerous to be accounted for in the Kermit protocol, or any
protocol that attempts to span a large number of systems.  You shouldn't
have to embody specific knowledge about a particular remote system in
another system's Kermit program -- if you did, where would it end?  The best
that can be done is what is currently done: if a packet does not elicit the
expected reply, try again, up to the retry limit, and then give up, but also
allow for manual intervention.  In the case of MS-DOS Kermit, you can type
Ctrl-C at any time during the file transfer to get back to Kermit-MS>
command level instantly, so that you can CONNECT and do whatever you can to
clean up.  Unfortunately, there's no way to tell the local Kermit to resume
the file transfer where it left off.

CMS is a special case.  Luckily, there's a special solution.  Version 3 of
CMS Kermit (due for release Any Day Now, will put the line into a special
mode so that any characters at all that appear to CP will continue the
program, that is, will do what "begin" would have done.]

------------------------------

End of Info-Kermit Digest
*************************
-------
25-Jul-86 13:24:02-EDT,20572;000000000000
Mail-From: SY.FDC created at 25-Jul-86 13:22:50
Date: Fri 25 Jul 86 13:22:50-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V5 #4
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 25 Jul 1986       Volume 5 : Number  4

Today's topics:
               IBM PC Kermit 2.29 on Diskette in the UK
             Another BASICA Program to DeBOO Kermit Files
                Kermit-11, Kermit-32 and Wildcard Send
      HP1000 Kermit Saga, cont'd, and MS-Kermit Filespec Parsing
                 Kermit with Other Terminal Emulators
                            Emulation Wish
                  Protocol Manual Potential Changes
                       Multics Kermit Dialout?
                      MS Kermit for Epson QX-16?
       Kermit with Internal Hayes Modem on the Leading Edge D?
            Kermit for General Automation-type Equipment?
                          More on BOO Files
                 Problem with Atari UU-encoded Files

----------------------------------------------------------------------

Date: 22-JUL-1986 11:31:21
From: Alan Phillips <[e-mail]>
Subject: IBM PC Kermit 2.29 on Diskette in the UK

Lancaster University Kermit distribution can now supply the complete set of
files for MS-Kermit 2.29 on the IBM PC on diskette.  Those interested can
contact me at:

            Kermit Distribution,
            Department of Computing,
            Computer Building,
            Lancaster University,
            Lancaster  LA1 4YW
            UK

or phone (UK) 0524-65201 x 4881

Diskette supply is offered in the UK and Eire only, and we can't return calls
to other countries. We have a complete set of Kermit files for all current
implementations on a VAX system, and these can be accessed by anyone who can
connect to us, from anywhere. Those wanting details, or who wish to receive
the UK Kermit newsletter, should mail me as

            SYSKERMIT @ UK.AC.LANCS.VAX1        (JANET)
            SYSKERMIT @ UK.AC.LANCS.VAX1        (BITNET)
            SYSKERMIT%LANCS.VAX1 @ UK.AC.UCL.CS (ARPA)
            SYSKERMIT%LANCS.VAX1 @ UKC          (UUCP - UK *only*)

[Ed. - Many thanks for providing this service, Alan, and for all the
work you've done in promoting and distributing Kermit in the UK!]

------------------------------

Date: Thu, 15 May 86 23:24 EDT
From: Alan H. Holland <FEAHH@VTVM1>
Subject: Another BASICA Program to DeBOO Kermit Files

Enclosed is a BASICA program developed from MSBPCT.BAS that takes 45% to 60%
of the time that MSBPCT.BAS would take.  For lack of a better name, I have
been calling it MSBPCT2.BAS.  The following comparative times (in min:sec)
were done on an IBM PC XT using PC-DOS 2.1 and IBM BASICA 2.0.  In CONFIG.SYS,
BUFFERS=8.

 Input File    Input Length     Type of Disk Used      MSBPCT       MSBPCT2
------------   ------------     -----------------      ------       -------
MSKERMIT.BOO      47,701         10 MB hard disk        22:45        10:27
 (ver. 2.27)
MSJRD5G.BOO       59,394         10 MB hard disk        22:38        12:28
MSJRD5G.BOO       59,394         360 KB floppy          24:09        13:50

[Ed. - Thanks!  The program has been added to the Kermit distribution
as MSBPCT.BAA (the old one is still MSBPCT.BAS; our filenames have to be
unique within the 6.3 paradigm...)]

------------------------------

Date: 22-JUL-1986 11:44
From: [e-mail]
Via:  [e-mail]
Subject: Kermit-11, Kermit-32 and Wildcard Send

Users of Kermit-11(V3.51) under RSX-11M and Kermit-32(V3.1.066 ) under VMS
4.2 may be interested to note the different ways in which these two kermits
treat file version numbers. If you wildcard send multiple generations from
the PDP-11 they arrive with the same version numbers as they left with.
However if you wildcard send them back the VAX sends the latest version
first, thus reversing the generation numbers...  Purge then becomes a very
dangerous command..

Cheers

Jonathan Pennick
Animal and Grassland Research Inst.

------------------------------

Date: Wed, 23 Jul 86 10:10 EST
From: <[e-mail]> (brian nelson)
Subject: Re: Kermit-11, Kermit-32 and Wildcard Send

Kermit-11 always strips the filename down to NAME.TYPE before sending the
name over in the F packet. Perhaps a possible alternative would be to allow
different levels of filename processing, such as a set command to (1) Remove
all but NAME.TYPE (2) To allow the version number, (3) To allow transmission
of the UIC or directory, and (4) To allow retention of the device name.  I
am not suggested the actual syntax as I would like to see Kermit maintain
some sort of common command syntax.

It would be quite undesirable to default to anything other than FILE.TYPE
as many other Kermits would reject a name that included a version field.
Lastly, if the version number is sent, then what about collision on the
version number?

[Ed. - The whole business of filename transmission is quite a stumper.  If
we could characterize file specifications on every possible system in some
canonic syntax to include every possible field (device, directory or path,
name, type, version, attributes, etc etc), then maybe we could have some
kind of format specification to say just which fields to transmit, how to
fill in defaults for missing fields, etc., plus a selector to tell whether
these fields, once selected, should be translated to canonic form for
transmission, or transmitted literally (e.g. between like systems)...]

------------------------------

Date: 21 Jul 86 17:39 +0200
From: [e-mail]
Subject: HP1000 Kermit Saga, cont'd, and MS-Kermit Filespec Parsing

We found the bug in the packet parsing routine of HP1000-Kermit in the
meantime; it works now with MS-Kermit V2.29 perfectly.

The old HP1000 file system allows file names starting with ? (question
mark).  If you put the HP1000-Kermit in server mode, you cannot transfer such
files, because if you type GET ? on your PC AT, the help feature is
immediately invoked. Is there an easy way to disable the recognition of
question mark for help ?

[Ed. - MS-DOS Kermit always wants to give help if you type a question mark.
Since question marks can be legitimate parts of file specifications (either
as a wildcard character, or as an actual part of the name), the following
compromise was made in the Kermit-MS command parser: If you type a question
mark as the first character in a filespec field, you get help, but if you
type it in a subsequent field, it is taken literally as part of the
filespec.  To enter a question mark as the first character of a filespec,
type a pound (sharp) sign (#) instead.  Meanwhile, I'm sure everyone with
HP-1000's is waiting anxiously for this new Kermit program...]

------------------------------

Date: Tue, 22 Jul 86 23:57 -0200
From: Jonathan Scott <GUCJS@SEGUC21>
Subject: KERMIT with Other Terminal Emulators

I thought KERMIT was a file transfer protocol until I met KERMIT-MS V2.29
which is obviously a sophisticated terminal emulator but also happens to
have KERMIT file transfer capability.  It's great, but it doesn't quite do
everything I want.  I already have a terminal emulator which does... except
that it doesn't support KERMIT file transfer.

The terminal emulator which I normally use has features which I don't want
to give up, including graphics and automatic mode switching between full
screen mode and line by line mode when running with an IBM 7171.  It's a big
problem switching over to KERMIT in the middle of a session because my
normal emulator is like a DM1520 Elite (for high performance because all the
control codes are 1 byte) but KERMIT emulates VT10x-type terminals and I
can't even enter the command to start the host KERMIT through the KERMIT
terminal emulator.

What I would like to see is a separate KERMIT file transfer facility which
can be used together with any other terminal emulator for a PC.  I think it
would be best to have a "hot key" type switch between the terminal emulator
and KERMIT.  It might not be easy, but I think it would be more helpful than
any number of special new features in the KERMIT terminal emulator, and file
transfer is after all the primary purpose of KERMIT.

The terminal emulator in KERMIT V2.29 is a very nice product and should
obviously continue to be developed, but terminal emulation is a tricky area
and it is very difficult to satisfy everyone (I know because I wrote one a
couple of years ago "sufficient for all our current needs" which has
resulted in a continuous barrage of enhancement requests ever since).  What
I want from KERMIT is a reliable file transfer system without side-effects,
integrated as neatly as possible into my existing work environment - then it
would really be worth the money we don't have to pay for it...

Has anyone done any work in this area before?  Does this seem feasible?

Jonathan Scott <[e-mail]>
(Gothenburg Universities Computing Centre, Sweden)

[Ed. -  A standalone Kermit file transfer program is not a bad idea, but
when you separate your terminal program from your file transfer program, you
have to waste a lot of time feeding them BOTH the same set of communication
parameters.  Particularly tedious if you switch between different hosts a lot.]

------------------------------

Date: Tue, 22 Jul 86 13:47:46 cdt
From: [e-mail] (David Sanderson)
Subject: Emulation Wish

A good way to provide emulation of nearly any terminal would be to build an
emulator into KERMIT that would configure itself from an entry in a
termcap-style file.  What tools exist that might make this addition easier
for micro versions, like MS-KERMIT?  Would performance necessarily suffer?

David Sanderson            Illinois State Geological Survey
true UUCP: ...uiucdcs!uiucuxa!uiucuxe!dsandrsn  (before 15 Aug.)
           ...wucs!wucec1!dws3014               (after  15 Aug.)

[Ed. - Ron Fowler once attempted a CP/M Kermit implementation that would do
this, but he either gave up or lost interest.  Since then, nobody has picked
up the cudgel.  In principle it's a great idea.  At compile time, the
program only needs to know a bunch of symbols ("cleol" for "clear to end of
line", etc) and program functions associated with each symbol.  These
functions could be filled in in a system-dependent way for each system (IBM
PC, Macintosh, etc).  Then at runtime, the program reads a termcap file
entry for the desired terminal type (ADM3A, Concept-100, VT-102, DM2500,
etc) to learn the escape sequences associated with each symbol, plus some
global parameters like whether cursor addressing is 1- or 0-based, etc.  In
practice, however, writing the code could be quite a chore...]

------------------------------

Date: Wed 23 Jul 86 18:13:17-PDT
From: Bob Larson <[e-mail]>
Subject: Protocol Manual Potential Changes

When using long packets and sliding windows together, the suggestion of
reducing the packet size (long packets section) cannot be done if a later
packet has been sent.  (Unless some further protocol extention is done.)

There are also a couple of problems in the attributes system/os field:
Prime/Primos is listed both as G and M4.  Tandy (J) should probably be
subdivided, TRSDOS and Disk Extended Color Basic versions of Tandy specific
Kermit exist.  (Tandy seems to be migrating away from proprietary os's, they
supply Xenix, MS-DOS and Os9.)  The assignment of these seems to be quite
random, UNIX and Os9 have one listing each, while cpm has 4.

The delimiter may be listed in both the type and format attribute packet if
the type is A.  It should probablby only be in the format.

Encoding should have a compress 4.0 type (bits in the range 12-16 may also
need to be listed.)

Shouldn't the "1-@ (ascii 49)" be "1 (ascii 49)"?

[Ed. - Thanks...]

------------------------------

Date: Wed, 23 Jul 86 13:35 MST
From: [e-mail]
Subject: Multics Kermit Dialout?

I'm having a real problem using Multics as a local system when dialing out
to just about anything, but most importantly to VMS systems.  Kermit works
fine when dialing out of VMS, but refused to work the other way round.

The procedure is fairly simple, dial_out of multics to the VMS system over a
direct line, set up kermit on VMS in server mode.  Escape back to Multics
with dial_out escape character and execute the Multics Kermit.After issuing
the command "GET" or "SEND", the Multics kermit will timeout everytime.  You
can't get back to the VMS system until you quit the Multics kermit.

An alternate method was to dial_out to VMS, get kermit up, and set the
timeout period to be 60 seconds.  You would then issue the Send or receive
commands and escape back to Multics, get kermit running and set it to
receive or send before the VMS side timed out.  This gave a 'fatal error on
remote'.  All of the parameters are set correctly.  ie) sop, eop,
packet_length, parity, etc.  If anyone has had this problem or heard of it a
clue would be greatly appreciated.

Cameron Roe University of Calgary [e-mail]

[Ed. - I understand there are several different versions of Multics Kermit
out there, of which Columbia has only one (the original from Oakland Univ).
Maybe some versions work better than others in this, and other, respects.
Can anyone shed any light?]

------------------------------

Date: 24 Jul 1986 0906-EDT
From: Don Bach, Sysop, FIDO 18/13
Via: [e-mail]>
Subject: MS Kermit for Epson QX-16?

I've installed the MSVCLO on my Epson. It works ok, but is a tad slow and
whenever I return to the Kermit-MS prompt, the baud gets reset to 1800. Is
anyone working on a version for the Epson QX-16?

Don Bach
P.O. Box 631
Vicksburg, MS 39180
[phone]

[Ed. - Not that I know about.  Anyone else?  The 1800 baud bug occurs on
other systems, too, so it's probably a problem with the code itself.]

------------------------------

Date: 24 Jul 1986 21:23-EDT
Subject: Kermit with Internal Hayes Modem on the Leading Edge D?
From: Charles Davis <[e-mail]>

A colleague is having difficulty getting MSKERMIT V2.29 to talk to an
internal Hayes modem on his Leading Edge D machine.  Are there special
configuration steps he needs to follow to make this work?

[Ed. - There are some problems with the Hayes 1200b even on real IBM
systems; there will be some fixes in the next release.  The only way to
know if these fixes will also work for the Leading Edge is to try them
out.]

------------------------------

Date: Thu, 24 Jul 1986 18:26 PDT
From: "Jeffrey Sicherman"  <[e-mail]>
Subject: Kermit for General Automation-type Equipment?

Though I am still planning (real soon now) to do a Kermit version for the
General Automation architecture machines that I work on (Control and MIBS
operating systems), I have come across mention of an existing implementation
which apparently does not appear in the Kermit listings, possibly because it
is part of a commercial package as opposed to a separate program.  The
manufacturer (or distributor?) is a company called GEI Rechnersysteme GmbH,
Aachen, West Germany.  Anybody on the other side of the Atlantic know
anything about this software and its availability (or anyone on this side
for that matter) ?

------------------------------

Date: Wed, 23 Jul 86  12:58:48 EDT
From: "Roger Fajman" <RAF@NIHCU>
Subject:  More on BOO Files

> [Ed. - It would have been nice to include consistency checks in .BOO files,
> but since checksums or CRCs are based on the numeric, internal
> representation of the characters, you get into trouble when going between
> ASCII and EBCDIC systems.  Actually, when you use the MSBOOT.FOR/MSBPCB.BAS
> pair, there is a minimal kind of consistency check -- the length of each
> line is transmitted along with the line by MSBOOT and checked by MSBPCB.
> But you're right, you don't even get this with the MSBPCT programs.  That's
> why the recommended technique is to use these bootstrapping programs to
> get a Kermit program that SEEMS to work onto your PC, and then use that
> Kermit program to get another copy of itself, with error checking, etc.]

I don't understand what you are saying here.  If I use KERMSRV@CUVMA to get
a copy of a BOO file, say for a new version of MSKERMIT, I must run a
program someplace to decode that file into an executable file.  Wherever I
do that, I am open to possibly not having the BOO file exactly right.  It
would be helpful if the actual binary executable files were available via
KERMSRV.  Then BOO files would really not be needed after the first time, at
least for those of us who have EBCDIC machines on BITNET.

As far as checksums in BOO files are concerned, if they were implemented,
they should be based on the original file.  This avoids EBCDIC-ASCII
translation difficulties in computing the checksum and would usually detect
errors that were introduced into the BOO file due to translation problems.

Anyway, now that I am aware of the problems, I can watch for them.  It did,
however, take me a while to figure out what was happening.

[Ed. - We've gone through several different encodings for .EXE files, and
.BOO files are simply the most recent.  All such encodings have their
faults.  Intel HEX format has too much storage (and transmission) overhead,
the BOO files are more compact but not error-checked, and see below about
UUENCODE.  Is there another encoding in common use that is (a) error
checked, (b) compact, and (c) easily decoded?  By (c) I mean can you type in
a short (1 or 2 page) BASIC program to do the job (this rules out LZW or
Huffman compression, I think).  Otherwise, maybe we'll add length and
checksum fields to .BOO files, along with an internal identifier so the
decoding program knows the data is really what it's supposed to be, plus
start and end markers, maybe even an ASCII "test pattern" of the entire
character set near the beginning to allow the decoder to determine in
advance whether any mistranslations have occurred.  Some day, we'll get this
right...]

------------------------------

Date: 25-JUL-1986 12:21:04
From: [e-mail]
Subject: Problem with Atari UU-encoded Files

There may be a problem with the AST*.UUE encoded files : I've had a report
that the copies I picked up from cu20b over arpa have lost trailing spaces
from the ends of some records, resulting in an unusable object file.

I don't know whether the spaces got lost on the way to me, or from me to the
user here, or whether they aren't on the cu20b files at all, but it sounds
like the sort of problem that may affect a lot of people. Perhaps the author
could modify the encoding technique slightly to end records only with
non-space characters?

[Ed. - These files came to us over BITNET, which trimmed the trailing blanks.
It's always a bad idea when encoding binary files printably to allow spaces
in the encoding.  Fortunately, UU-encoded files have lines beginning with a
length field, so the right number of spaces can be restored.  Below is a
little program in my favorite screwball language, SNOBOL, to do this.  It
must be run on an ASCII system because length fields are ASCII values.]


    &TRIM = 1

* Look for beginning

BEGIN    LINE = INPUT                      :F(NOBEGIN)
    LINE POS(0) 'begin '                :S(GO):F(BEGIN)
NOBEGIN    TTY = 'No begin line'                :(ERR)
GO    OUTPUT = LINE

* Read encoded lines, get length, pad to that length.

LOOP    LINE = INPUT                    :F(DONE)
    OUTPUT = IDENT(LINE,NULL)            :S(LAST)
    LINE POS(0) LEN(1) . X                :F(ERR)
    &ALPHABET @P X                    :F(ERR)
    OUTPUT = RPAD(LINE,(((P - 32) / 3) * 4) + 1)    :S(LOOP)

* Blank line and 'end' line at end.

LAST    LINE = INPUT                    :F(LAST2)
    OUTPUT = IDENT(LINE,'end') LINE            :S(DONE)
LAST2    TTY = 'No end line'

* Error and regular exit.

ERR    TTY = 'Fatal error'                :(END)
DONE    TTY = 'Done'
END

------------------------------

End of Info-Kermit Digest
*************************
-------
 1-Aug-86 12:47:07-EDT,12869;000000000000
Mail-From: SY.CHRISTINE created at  1-Aug-86 12:46:06
Date: Fri 1 Aug 86 12:46:06-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #5
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 1 Aug 1986       Volume 5 : Number 5

Today's Topics:

                   The First Kermit Newsletter Available
                              Okstate Downtime
              Kermit-80 files on PC-format diskettes in the UK
                          Japanese Kermit Manuals
                KERMIT for Sirius/Victor 9000 under CP/M-86
        Two Kermit-MS 2.29 Implementations for the Sanyo 550 Series
                  Re: KERMIT with Other Terminal Emulators
                    CMS Kermit Problem (making it work)
                                 .BOO files
                Using C-Kermit to dialout on a DF112 modem?

----------------------------------------------------------------------


Date: Tue 29 Jul 86 14:41:54-EDT
From: Christine M Gianone <[e-mail]>
Subject: The First Kermit Newsletter Available
Keywords: Kermit Newsletter

The first issue of the (paper) Kermit Newsletter (July 1986, Vol.1 No.1) is
currently available.  The Newsletter target audience was originally intended
to be those who do not have access to our networks and have asked to be
informed about new Kermit releases and other Kermit news.  Articles in this
issue include: MS-DOS Kermit Version 2.29; Kermit Book Published by Digital
Press; C-Kermit; The Top Five Kermit Questions; Mac Kermit 0.8(34); Protocol
Extensions; VAX/VMS Kermit-32 Version 3.2; Kermit's Early History.  Anyone
who is interested in obtaining a copy of this and future Kermit Newsletters
may do so by sending their postal (not electronic) mailing address to
Info-Kermit-Request@CU20B, Kermit@CU20B, or KERMIT@CUVMA.  Number 1 will
be sent to those who request it this way till our leftover copies run out.

------------------------------

Date: Tue, 29 Jul 86 20:12:34 -0500
From: Mark Vasoll <[e-mail]>
Subject: Okstate Downtime
Keywords: Okstate Downtime

The system Okstate, (home of the UUCP and Kermit Server Kermit
distributions) will be down from August 8th until August 31st while our
machine room is being remodeled.  The uucpker and kermsrv dialin number will
not answer the phone during this period.  Watch for the return of uucpker
and kermsrv shortly after August 31st.

Thanks,
Mark Vasoll
Department of Computing and Information Sciences
Oklahoma State University

Internet:   [e-mail]
Obsolete:   [e-mail]

UUCP:  {cbosgd, ea, ihnp4, isucs1, mcvax, pesnta, uokvax}!okstate!vasoll

[Ed. - Thanks for the information.  The return date of UUCP will be
announced in the digest.]

------------------------------

Date: 30-JUL-1986 17:18:19
From: [e-mail]
Subject: Kermit-80 files on PC-format diskettes in the UK

Having had a number of requests lately for it, we've now set things up so we
can supply a complete set of the CP/M-80 Kermit files (CP4) on IBM PC MS-DOS
format diskettes. Not having any CP/M engines, we can't write diskettes
directly in CP/M format: but this at least will let people get the files
onto their own territory (and it's easier to move files from your own PC to
your CP/M machine than download over a phone line).

The service is offered in the UK and Irish Republic only: the address, as
before, is

           Kermit Distribution,
           Department of Computing,
           Computer Building,
           Lancaster University,
           Lancaster LA1 4YW
           UK

           Phone (UK) 0524-65201 x 4881

We hope before long to be able to provide all the IBM PC Kermits (Xenix, QNX
and so on) on MS-DOS format discs; and in the longer term we intend to offer
all Kermit sources for everything in this way.


Alan Phillips

[Ed. - Thanks!]

------------------------------

Date: Mon 21 Jul 86 09:20:55
From: ken-ichiro murakami <nttlab!NTT-20![e-mail]>
Subject: Japanese Kermit Manuals
Keywords: Japanese Kermit Manuals

   I will give the Japanese Kermit manuals to everyone. The only problem is
that I cannot distribute machine readable code. My favorite workstation is
STAR Japanese version, and all my document files are in this machine. JSTAR
has no way to export files except for FDD, and the number of JSTAR in Japan
is also small. That is, every time the manual is ordered, I must print it
out and send by mail (not E-mail).  However, I'll distribute free manuals as
many as possible. Please forward me, when you receive requests for Japanese
manuals.  I can distribute JSTAR FDD or printed documents.

    Ken-ichiro Murakami
    NTT Basic Research Laboratories
    3-9-11 Midori-cho, Musashino-shi
    Tokyo, 180
    Japan

    Telephone : [phone]
    E-mail address : "nttlab!murakami"@Shasta    (from ARPA)
                or
             [e-mail]   (from JUNET)
                (JUNET is Japanese domestic network.)

[Ed. - Thanks to Ken-ichiro Murakami for all the work he put into
translating the Kermit User's Guide and the Kermit Protocol Manual and for
volunteering to distribute these manuals to others.]

------------------------------

Date:     Tue, 29 Jul 86 10:44 MDT
From:     <[e-mail]> (Eric Zurcher)
Subject:  KERMIT for Sirius/Victor 9000 under CP/M-86
Keywords: Sirius/Victor 9000 Kermit, CP/M-86

This note will be followed by slightly modified versions of A86 and H86
files for KERMIT for the Victor 9000/Sirius under CP/M-86.  This version is
nearly identical to the one I sent to you about 3 weeks ago, and differs
only in that the SET PORT command is now implemented, allowing the user to
select either serial port "A" or "B" - "A" is the default.  I hadn't
originally intended bothering to add this feature, but a freak lightning
strike knocked out the "A" port on one of the Victors in our department, and
it was easier (and cheaper) to implement the SET PORT option than to fix the
hardware.

                                        Sincerely,

                                        Eric Zurcher
                                        Dept. of Biology
                                        Utah State University
                                        Logan, Utah 84322-5305
                                        [e-mail]

[Ed. - Thanks, Eric.  The new files are in the Kermit distribution as
KER:C86XV9.*.]

------------------------------

Date: Wed, 23-JUL-1986 22:26 EST
From: Bob Babcock <[e-mail]>
Subject: Two Kermit-MS 2.29 Implementations for the Sanyo 550 Series
Keywords: MS-DOS 2.29, Sanyo 550 Series

This is to announce two versions of Kermit 2.29 for the Sanyo 555.  One has
a fairly simple machine dependent routine MSXMBC.ASM, in particular, it does
not have any terminal emulation other than responding properly to some
VT-100 escape sequences which the BIOS recognizes.  This version will run
under DOS 2.11 on any Sanyo MBC-550 or 555 which has a serial port.  I
haven't tried it under DOS 1.25, but Kermit does check the DOS version, so
it ought to work.  The other version is derived from the IBM Kermit and
includes almost all of its features including emulation of VT-52, VT-102,
Heath-19 terminals.  This version requires the optional IBM compatible video
board.  Since DOS 1.25 doesn't support the video board, the question of DOS
version doesn't arise for this version.

Most of the work in producing these routines was copied from code written by
Joe Smiley for version 2.27.

Both versions use the standard files:
     mssdef.h msscmd.asm msscom.asm mssfil.asm mssker.asm mssrcv.asm
     msssen.asm mssser.asm mssset.asm msster.asm mssfin.asm

The simple version has one Sanyo dependent-file:
     msxmbc.asm

The video board version has three Sanyo-dependent files:
     msx55x.asm msy55x.asm msz55x.asm

Bob Babcock
Mail stop 63
Smithsonian Astrophysical Observatory
60 Garden Street
Cambridge, MA  02138
617-495-7107  FTS 830-7107

Net addresses:
[e-mail]
[e-mail]

[Ed. - The new files are in KER:MS%MBC.* (simple version) and KER:MS%55X.*
(video-board/vt100 version), including .BOO files for each (% is the DEC-20
single-character wildcard).]

------------------------------

Date: Sat, 26 Jul 86 11:40 AST
From: <[e-mail]> (Eberhard W. Lisse)
Subject: Re: KERMIT with Other Terminal Emulators
Keywords: Terminal Emulation

Apropos of Jonathan Scott's message on this subject in the Info-Kermit
Digest V5 #4...

If one needs both Kermit (MS 2.29) and another Terminal program I would try
to run the other one from within Kermit. (RUN XYTERM)

I do this with a public domaine Tektronix 4010 emulator with no problems at
all. That combination works, in fact, better than a commercial product
(VTERM from Coefficient Systems) we use here as well, as that one does not
leave the keyboard as it is but switches to the US layout which is very
different from the one which comes with the IBM PC when bought in Germany.

------------------------------

Date: Wed, 30 Jul 86 14:34 EDT
From: CCPHIL@TUCC
Subject: CMS Kermit Problem (making it work)
Keywords: VM/CMS Kermit, CMS Kermit

Bob Babcock mentioned a problem with CMS Kermit putting him into CP mode,
where he has to interact with the system by entering a "begin" command to
get back into CMS mode.

The solution is to enter the command "set run on".  This changes your CMS
environment in a few .  One thing that happens is that a carriage return
will return you to CMS mode if you enter CP mode.  S most Kermits will time
out, and send a NAK packet (which is terminate in a carriage return), then
you automatically return to CMS mode where ermi Kermit runs without dropping
a stroke.  Your default environment must be "set run off".  We have used e
"set run on" command hen going to CMS from the HP 900 and other hosts at SAS
Institute.

[Ed. - Version 3.0 of CMS Kermit should return you to CMS mode automatically
if you happen to enter CP mode.]

------------------------------

Date: 30-JUL-1986 15:04:20
From: [e-mail]
Subject: .BOO files

How about using a hybrid Intel-Hex/BOO file format to provide the error
checking? If you were to structure a record as

               :<length><BOO-encoded data><checksum>

where length and checksum are ASCII hex, and checksum is based on the sum of
the byte values after conversion, you'ld add only 5 bytes per record. An EOF
record would have a length value of 0, adding 3 bytes to the grand total. I
would guess an 8-bit checksum would be enough for anyone's needs, and you'ld
have only a 6% or so increase in file size.

That would give you the checking needed: for another 2 bytes per record you
could add a <record-type> ASCII hex field after the <length> field, which then
gives you an expansion path if you ever do a major change in the structure.
The obvious ones here are

    Type 0   Filename record (including such attributes as you might want,
             such as "total length of data you should get when you've done")
    Type 1   Data record
    Type 2   ASCII test pattern
    Type $FF EOF

Having a specific record type for EOF and FileName would let you concatenate
.BOO encodings for multiple files and convert them all in one run of the
converter program.

And, I suppose, if you used record type values not used in Intel hex, you could
produce a universal converter that could do both.....

Alan

------------------------------

Date: Thu, 31 Jul 86 14:57:07 edt
From: Jeffrey Burgan <[e-mail]>
Subject: Using C-Kermit to dialout on a DF112 modem?
Keywords: DF112 Modem

I am having problems getting a DF112 modem to work with C-Kermit.  When I
issue a 'set line /dev/ttyIb' command after the 'set modem df100' command,
kermit does not respond with a prompt. It seems it is waiting for carrier
detect. Has anyone gotten a DF112 to work dialing out and if so, are there
any special switch settings for the modem.  Any help would be appreciated.

Thanks in advance,

Jeffrey Burgan
University of Maryland
[e-mail]

[Ed. - It also depends on which version of C-Kermit -- Sys V, 4.2BSD,
etc.  Sys V has special treatment for modems ("CLOCAL"), which may or may
not be consistently implemented on different System-V systems.]

------------------------------

End of Info-Kermit Digest
*************************

-------
 8-Sep-86 17:40:31-EDT,15879;000000000000
Mail-From: SY.CHRISTINE created at  8-Sep-86 13:05:07
Date: Mon 8 Sep 86 13:05:07-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #6
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>


Info-Kermit Digest         Mon, 08 Sep 1986       Volume 5 : Number 6

Today's Topics:

                           New Kermit for HP-1000
                     New Release of Sperry-1100 Kermit
                 New Kermit for Use with Microsoft Windows
                      More Kermit Diskettes Available
                                 MSBPCT.ASM
                        Amiga Kermit Initialization
                       Kermit Documentation in French
                  Review of MS Kermit 2.29 vs ProComm 2.3
                            Kermit on IBM MVS/XA?
                        Suggestions for Fortran Port

----------------------------------------------------------------------


Date: Wed 3 Sep 86 17:23:51-EDT
From: Christine M Gianone <[e-mail]>
Subject: New Kermit for HP-1000
Keywords: HP-1000 Kermit

This is to announce a new Kermit program for the HP-1000 running either
RTE-6 or RTE-A, replacing both of the two earlier HP-1000 programs, as
discussed in Info-Kermit V4 #xxx and #yyy.  This program was submitted by
Paul Schuman of E-Systems, Inc, Greenville, Texas, who has also contributed
it to the appropriate HP user groups.  The files are in KER:HPM*.*.
Binaries (for RTE-A) are in KB:HPM*.*.  The old versions have been moved to
KO:HP*.*.

------------------------------

Date: Wed 3 Sep 86 17:37:23-EDT
From: Christine M Gianone <[e-mail]>
Subject: New Release of Sperry-1100 Kermit
Keywords: Sperry

This is to announce version 2.5 of Sperry 1100 Kermit from pAaul sTevens at
the University of Wisconsin.  The changes include conditional assembly to
make it easier to port to "standard" Sperry systems, increased maximum
record size from 800 to 2000, and error corrections.  The source file,
in Sperry assembler, is in KER:UNIVAC.ASM.

------------------------------

Date: Sun 10 Aug 86 10:21:58-EDT
From: Bill Hall <[e-mail]>
Subject: New Kermit for Use with Microsoft Windows
Keywords: Microsoft Windows, MS-DOS Kermit

I have developed a simple version of Kermit to run under Microsoft Windows.
I will be sending you the files via the mails on a floppy disk for you to
try.  It is strictly bare bones, but the multitasking aspect is really nice.

If you will put it on the system, I will maintain it and develop it further.

[Ed. - Thanks Bill!  The diskette was received, and the files have been
placed in KER:WIN*.* on CU20B.  Although this program is bare-bones (no
help, only dumb terminal emulation), it runs a lot faster under MS Windows
than regular Kermit does, and it has the advantage that it can be run in
several windows at once, for instance transferring two files simultaneously,
one on COM1 and the other on COM2, all in the background while doing other
work in the foreground.  The program is written in Microsoft C v4.0 (Windows
aware), using the supplemental Windows libraries, the Microsoft Resource
Compiler, and LINK4 v5.02.  It takes advantage of MS-Windows' built-in comm
and screen drivers, and is thus usable on any system that runs Windows.  It
requires a lot of memory and only runs at speeds up to 2400 baud.  It has
several typical Windows menus so a mouse is a near necessity.  This Kermit
program should not be confused with the other "Windows Kermit" for the PC
(WKERMIT), which implements windows in the other sense of the word, namely
the sliding window transport-level protocol.  The executable program is
KER:WINKRM.BOO, in Boo-file format, which can be translated to and .EXE
file using any of the KER:MSBPCT.* programs.  The 8-bit binary .EXE file
is available in KB:WINKRM.EXE, for those sites that can transfer such files
directly from CU20B.]

------------------------------

Date: Sun, 17 Aug 86 17:06:41 pdt
From: Randy Spencer <spencer@usc-oberon>
Subject: More Kermit Diskettes Available
Keywords: Kermit Diskettes

This is a copy of the letter I sent out to net.micro.amiga.  I am sending
it to you because I just noticed the file AADISK.HLP on CU20B and would
like to be included...

I am willing to send you a copy of Kermit for the IBM, C64, or the Amiga.
These are the most recent versions available from Columbia.  Send me $6.00
and your mailing address to:

    Randy Spencer {Keeper of the Kermits}, Box 4542, Berkeley CA 94704
                   ^^^^^^^^^^^^^^^^^^^^^optional

I prefer checks, they make good receipts.  I *will* include the sources for
Amiga Kermit on the disk I send.  I will include the sources for the IBM
Kermit if requested (but it is so hard to keep up with the changes, and I
cannot be sure that it will compile as I have not got all the compilers for
the IBM (I am just using the transformer)).  The sources for c64 Kermit will
not compile on the c64 (they were compiled on a mainframe) so there is
little use in downloading them.  There are some other utilities on the disk
and the .boo file is included if you want to modem someone else a copy of
the file.

                    Randy Spencer

[Ed. - Thank you for offering to distribute Kermit on diskettes, Randy.
Your name and terms have been put in the file KER:AADISK.HLP.  Are there
any other volunteers for micros we do not already have listed?]

------------------------------

Date: 27 Aug 86 14:14 EDT
From: [e-mail] (John Junod)
Subject: MSBPCT.ASM
Keywords: .EXE files

I have just completed a reconstruction of Kermit on a DEC Rainbow using the
MSVRB1.BOO file. The target machine had a Vanilla MS-DOS disk without BASIC
or a Terminal Emulator with file transfer.  It did have MASM and LINK. I was
able to capture the BOO file by using "copy aux mskermit.boo" (and you could
capture the msbpct.asm file by using "copy aux msbpct.asm") and sending a
control-z at the end from another MS-DOS machine connected to the Rainbow's
communication port. Since I was unable to find an assembly version of MSBPCT
I wrote the following to reconstruct MSKERMIT.EXE. (Note: you must have the
source BOO file on the default drive as MSKERMIT.BOO and the output will
always be MSKERMIT.EXE on the default drive.

If necessary do a "copy" or "rename" of your capture file before running the
assembled MSBPCT.ASM)

           Regards,

           John Junod
           Code 1821
           David Taylor Naval Ship R and D Center (DTNSRDC)
           Bethesda, Md 20084-5000

[Ed. - Thanks John!  The file is in KER:MSBPCT.ASM.]

------------------------------

Date: Fri, 05 Sep 86 01:50 EDT
From: CCPHIL@TUCC
Subject: Amiga Kermit Initialization
Keywords: Amiga Kermit
Cross-Ref: Commodore Amiga (see also Amiga Kermit)

I have found the following kermit initialization file useful for the Amiga,
when you want to emulate a standard ANSI terminal (like a VT100).  I have
used this with a PCI protocol converter and also a VAX VMS system.  The PCI
works well, but the VAX has problems in EDT when lines need to be scrolled
up from the bottom of the screen.

Note that the Amiga Kermit will configure itself based on the settings in
the Preferances screen for the serial line.  Insert the following lines into
a file s:.kermrc :

%
% Set up to 80 columns by 24 rows, position to (0,0), & clear screen
%
echo \\033[25t\\033[80u\\033[0x\\033[0y\\014
%
echo Kermit is initialized and 80x24 ANSI screen!

------------------------------

Date: Thu 4 Sep 86 16:12:48-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit Documentation in French
Keywords: French Kermit Documentation

A translation into French of the first part of the Kermit User Guide appears
in CiSi telematique's "Bulletin Technique", numbers 86/05-06 and 86/07-08,
available (I'm not sure how) from CiSi telematique, 35 Boulevard Brune,
75680 Paris CEDEX 14, phone [phone].  Thanks to Gerard Gaye.

------------------------------

Date: 22 Aug 86 05:23:44 GMT
From: [e-mail] (Pete Holzmann, Octopus Enterprises, Cupertino, CA)
Subject: Review of MS Kermit 2.29 vs ProComm 2.3
Keywords: MS-DOS Kermit, ProComm

THANK YOU to the many who responded to my recent request for info on
communications programs that properly handle flow control. This is a summary
of the responses and my subsequent experience:

The responses were almost unanimous in recommending either ProComm (2.3 is
the latest version) or MS-Kermit (2.29 is the latest). A kind soul sent me
MS-Kermit, and I picked up ProComm locally.

A review of the two:

Kermit: lots of options, but not really as flexible as the number of options
might lead one to believe.  Comes with one terminal emulator (VT102) and only
one file transfer protocol (Kermit, no sliding windows).  Can use 38.4
KBaud, a win.  Drives my LCD display at about 6 Kbaud.  User interface isn't
too bad once you know how to use it, but it is not at all intuitive (you
must 'Cancel Connection' to get to command mode, and that doesn't *really*
break the connection, fortunately!).  No dialing directory or other
niceties, although you *can* push into DOS.  File transfers are slooooowwww.
Running between two 8 MHz AT's at 38.4 KBaud, I could only push through
about 300 bytes a second!!!  Rather poor.  However, I didn't find any bugs.
It may not do a whole lot, but it works.

[Ed. - Actually, PC Kermit comes with 3 terminal emulators built in -- VT52,
H19, and VT102 -- plus the ability to run with external terminal device drivers
like ANSI.SYS or whatever.  2.29 is slightly slower than some previous
releases, but not THAT slow!  See below...]

ProComm: Great user interface, lots of terminal emulations, lots of transfer
protocols, lots of niceities including dialing directory that can also link
to destination-specific command files (for auto-login, etc).  Color,
windows, (even sound if you can stand it).  Very fast file transfers (even
good in Kermit, with sliding windows, but slower than the other protocols).
It is a 'shareware' program (kermit is from a University, presumably more
altruistic).  BUT A BIG BOO for all the bugs.  ProComm has a strong tendency
to lock up.  More so on AT's, but also on PC's.  It can happen when you
aren't doing anything, it can happen during file transfer, it can happen due
to problems in terminal emulation, it can happen... you get the idea.  I've
posted another article asking for help with these problems.  I just can't
trust ProComm.  Otherwise, it would be the greatest thing since sliced
bread.

[Ed. - Kermit has color too...]

Actually, there's two wish-list features I wish could be added to
ProComm or some other program:

1) Conditional branching and user-input in command files, similar to
   some of the capabilities of CrossTalk.

2) Putting something like CWEEP into the comm program, so that one
   could easily select the files to be block-transferred.  It would make
   unattended operation MUCH more useful! It would even be better if you
   could grab filenames off the screen (so you could get a remote
   directory, then just point at the files you want to download).

Again, thanks for the help! (My current status: using ProComm in general,
but using MS-Kermit when it is important that the job get done right without
system-reboot hassles).

[Ed. - The following comments about MS-DOS Kermit 2.29 performance on the
IBMs and clones come from Joe Doupnik, who put together version 2.29 and
is working on a new release, 2.29A]

At 38400 baud the effective speed ought to be well above 9600 baud (like
14-16Kb or so).  That's for the new version (2.29a) whereas the release
version (2.29) is the normal slow poke (say 3000 but not quite 300 baud).

MSKermit 2.29 is slower than 2.28 (please speed up if possible).  Well, the
test version of 2.29 on the previous disk is much faster than 2.28.  As an
example, transferring a plain text file, mssscp.asm in fact, between two
regular IBM PC clones at 9600 baud this morning took:
        132 seconds     with MSK 2.28
        67 seconds      with MSK 2.29a/test   same packet length as 2.28
That's a 2:1 speedup! Lower baud rates achieve less dramatic factors since
the transmission time is a greater proportion of the whole.  2.29a
at 38400 baud works, but the higher efficiency did not come cheaply.

Some additional comments since I have focused on that topic recently.  The
measured overhead of new 2.29a to move a character from one ramdisk to
another is close to 350 microseconds per character plus the time sending the
data on the comms link.  The per character time includes the major factor of
time doing (s-l-o-w) DOS file calls. I overlap as much packet construction
and decomposition as possible with i/o without going to extreme measures
(read that as expanded buffering + management code).  Screen writes are time
consuming but are less so now.  The release 2.29 (and earlier releases) had
high overhead associated with clock timing (for timeouts); this version does
not.  Earlier versions had real trouble with the serial port at high speeds;
this version has code written for high speeds.  A problem with all comms
programs is that items hanging on the clock tic block interrupts from the
serial port and cause data loss.  Examples are print spoolers, keyboard
enhancers, screen savers, pop up helpers, and so forth; it is amazing how
much time they eat.  With a scope attached to the comms line I observe a
series of 1000 byte packets to use 1.34 +/- seconds from ACK to ACK at 9600
baud; hence the timing figure above.  This is on a regular 4.77 MHz PC and
translates into an efficiency of 75% on the comms line.  In the test case of
transferring MSSSCP.ASM from hard disk to a ramdisk the new version gave a
throughput of about 507 bytes/sec (5000 baud, 33950 bytes div 67 seconds)
end to end (or about 7200+ on the comms line) including all overhead of
prefix encoding chars, screen updating, packet header bytes, etc.  I think
the new Kermit will beat many or most X-modem implementations (certainly the
ones I have).  So, Kermit's efficiency is up this time around, and it can
run at much higher speeds than before.

------------------------------

Date: Thu 4 Sep 86 10:04:46-EDT
From: Walter V Dixon Jr <[e-mail]>
Subject: Kermit on IBM MVS/XA
Keywords: MVS/TSO Kermit?

Another GE site is trying to use an MVS version of Kermit under XA.  They
are getting an ijkmsg SYSDA not allowed.  Is there anyone they can call to
get help solving this problem?

Thanks

Walt Dixon

------------------------------

Date: Mon, 18 Aug 1986 01:49 PDT
From:   "Jeffrey Sicherman"  <[e-mail]>
Subject: Suggestions for Fortran Port
Keywords: Fortran Port

I would appreciate some advice from anybody who has done a kermit
port/implementation in FORTRAN or who is familiar with one or more of the
FORTRAN implementations.

  The machine is a minicomputer and has an old FORTRAN compiler ... Fortran
IV (which corresponds to FORTRAN 66, I think) and I would like
recommendations on which of the existing versions would be easiest to
convert. I could edit some new IF constructs, etc., but I wouldn't like to
use one if it was rife with such constructs. Maximum facilities would be
nice, but right now ease of conversion is primary. Please reply to me if
possible:

             [e-mail]

Thanks for any help.

------------------------------

End of Info-Kermit Digest
*************************


-------
10-Sep-86 16:54:28-EDT,20102;000000000000
Mail-From: SY.CHRISTINE created at 10-Sep-86 16:52:54
Date: Wed 10 Sep 86 16:52:54-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #7
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 10 Sep 1986       Volume 5 : Number  7

              Converting Kermit Distribution to 3 Tapes
               New (Minor) Release of C-Kermit for UNIX
                    Kermit 2.29 for the NEC APCIII
                 Uuencoded Files and Trailing Blanks
                        Kermit for NCUBE AXIS
                  Timing Problem with TOPS-20 Kermit
                     VAX to PC binary file xfers
             Being thrown into CP while using CMS Kermit
                      CMS KERMIT under VM/XA/SF?
    Kermit through 3708 Front End or WETRONIC Protocol Converter?
                    PRIMOS Kermit v. IBM-PC 2.29?
                  Kermit and Paradise Graphics Card?

----------------------------------------------------------------------

Date: Tue 9 Sep 86 17:26:35-EDT
From: Frank da Cruz <[e-mail]>
Subject: Converting Kermit Distribution to 3 Tapes
Keywords: Kermit Distribution

The collection of Kermit programs and documentation has once again grown
beyond the capacity of our most common distribution, 1600bpi 2400-foot reels
of magnetic tape.  We are now in the process of reorganizing the files from
2 groups (micros and mainframes) into 3 groups (micros, mainframes, and
esoterica).  Our major goal is to keep the most popular stuff on tapes A and
B, so that people who ordered these tapes before the changeover will still
stand a good chance of getting everything they want.  However, we must
create sufficient empty space on tapes A and B to allow the new Kermit
programs recently announced (and others waiting in the wings) to fit.

We'll try to do this as fairly as possible.  In the meantime, we'll be
installing new programs and files on CU20B without necessarily also putting
them in our other distribution areas or on our tapes.  When this rash of
installations (and announcements) is complete, we'll see how to most
equitably distribute the files.  Network access to Kermit files will be
unchanged, but during the transition some of the new files won't necessarily
be available at all of the distribution points.

------------------------------

Date: Tue 9 Sep 86 17:27:50-EDT
From: Frank da Cruz <[e-mail]>
Subject: New (Minor) Release of C-Kermit for UNIX
Keywords: C-Kermit
Cross-Ref: UNIX Kermit (see also C-Kermit)

This is to announce a new, minor release of C-Kermit for UNIX.  Because of
some mixups this past July, the new Amiga Kermit was installed in the Kermit
distribution with an inconsistent set of sources; the major reason for this
release is to remove this inconsistency.  Also, a few minor bugs are fixed.
Significant performance improvements and additional features will come in
future releases.  Here's a brief summary of what's in this new release:

Changes from Jack Rouse and Phil Julian of SAS Institute:
. Commodore Amiga support, replaces that from Davide Cervone of Rochester U.
  All-new CKI*.* files (this was announced in Info-Kermit v5 #3).
  This is the version written up in Jul/Aug 86 Amiga World.
. Revert CKUCMD.[CH] and CKUUS?.[CH] to their old selves (no more printf2,
  printf3, since these are no longer necessary for the Amiga), but add a
  few new Amiga specifics under #ifdef AMIGA conditionals.
. Fix multiline GET parsing to allow get back to top-level prompt if illegal
  local filename given (in CKUUSR.C).
. Supply a missing printf() parameter in CKWART.C.

Other changes:

Fix top-level parse loop in CKUUSR.C to reset any start state that might
erroneously have been set when a parse error has occurred.  Eliminates (for
instance) the spurious "?Sorry, you must set speed first" message if you
specify "foo bar" as the local filespec in multiline GET.

Make sysinit() return -1 if it fails, 0 if it succeeds, and have CKCMAI.C
check the return code.  Corresponding changes to invocation of sysinit in
CK[UVMI]IO.C.

Change references in CKUFIO.C to _file member of FILE structure to more
portable fileno() [suggested by Doug Orr, U of Mich].

In CKUFIO.C, change zclosf() to kill the fork before waiting for it to
terminate.

Fix Sys-V speed setting code (change "," to ";" between tttvt.c_cflag
statements) in CKUTIO.C.

Fix errpkt() function in CKCFN2.C to close open files, so that further
host commands can be done by the server after such a command is interrupted
abnormally [problem pointed out by Gregg Wonderly, Oklahoma State U].

Add Stan Barber's 4.3BSD acu control code to CKUTIO.C, under NEWUUCP
conditional.  I'm not sure if NEWUUCP needs to be defined in the makefile,
or what...

Version 4D(061) has been compiled and tested under Ultrix 1.1 (= 4.2BSD),
Ultrix 1.2 (whatever that may be a hybrid of), 2.9BSD on a DEC Pro/380, and
true 4.3BSD on a VAX 11/750 (4.3BSD includes an earlier version of C-Kermit
-- 4C(057) -- on its distribution tape).  The files that are new to this
version are in KER: on CU20B.  They are:

CKUCMD.C, CKUCMD.H, CKITIO.C
CKUUSR.C, CKUUSR.H, CKMTIO.C
CKUUS2.C, CKUUS3.C, CKVTIO.C
CKUFIO.C, CKUTIO.C
CKCMAI.C, CKUKER.UPD

------------------------------

Date:  Fri, 29 Aug 86 21:16 EDT
From:  [e-mail]
Subject:  Kermit 2.29 for the NEC APCIII
Keywords: MS-DOS Kermit, NEC APC3
Cross-Ref: NEC APCIII (see also NEC APC3 and MS-DOS Kermit)

          As we discussed almost two months ago, I have this version of a
terminal driver for the NEC APCIII which implements almost everything found
in the IBM PC driver plus some little goodies of its own.  Roger Link
(linkr%vtvm1) and I have worked together on debugging the present version;
he is now releasing it to his general (local) universe, which will no doubt
turn up additional bugs, but one cannot wait forever.

          I have put a note in the Boston Computer Society APCIII newsletter
offering to supply disks for users finding it inconvenient to get the source
from Columbia.  The same offer applies to the general world, which you may
publish in whatever manner is common.  The instructions are to send me 1
floppy to get the executable code, 4 floppies to get all the sources.  The
address is:
                    Robert Goeke
                    MIT Center for Space Research
                    Room 37-567
                    77 Massachusetts Avenue
                    Cambridge, MA  02139

[Ed. - Thanks!  We will distribute this stuff as part of the 2.29a release,
since corresponding changes have to be made to all the other incarnations of
MS-DOS Kermit.  Till then, those who are anxious to get it can get floppies
by mail as advertised above.]

------------------------------

Date: Sun, 03 Aug 86 22:35:31 EST
From:  [e-mail]
Subject: Uuencoded Files and Trailing Blanks
Keywords: Uuencoded Files

      If you use KERMIT under VM/CMS, it is hard to use uuencoded files such
as the uuencoded version of ST Kermit, since VM/CMS Kermit removes all
trailing blanks when downloading files.  Here is a solution to this problem;
it is a version of UUDECODE that supplies trailing blanks as necessary,
written to run on the Atari ST.  It is written in 68000 assembly language,
and can be assembled using the public domain assembler, AS68.

                                       David Moews
                                     [e-mail]

[Ed. - Thanks David!  The files are in KER:ASTUUD.*.  The trailing blanks
will be lost, however, if punched across BITnet.  See KER:ASTKER.BWR for
a more complete explanation and a SNOBOL program to restore the blanks.]

------------------------------

Date: Fri, 8 Aug 86 11:02:58 edt
From: couch <@CSNET-RELAY.ARPA,@TUFTS.CSNET (alva l couch):[e-mail]>
Subject: Kermit for NCUBE AXIS
Keywords: NCUBE AXIS

I now have a partially functional adaptation of C - Kermit 4.2 for the
NCUBE parallel processor running the AXIS operating system.

                Sincerely,
                    Alva L. Couch,
                    Dept. of Computer Science,
                    Tufts University,
                    Medford, MA, 02155

[Ed. - As soon as Columbia receives the files, we'll attempt to add
Alva's code to the current C-Kermit release, and announce when it's
ready.]

------------------------------

Date: Tue, 09 Sep 86 13:10:00 PDT
From: Bob Larson <[e-mail]>
Subject: Timing Problem with TOPS-20 Kermit
Keywords: TOPS-20 Kermit
Cross-Ref: KERMIT-20 (see also TOPS-20 Kermit)

After making a few improvements in my specialized kermit used to transfer
mail between USC's primes and other computers, (better timeout handling)
files started being duplicated.  (Cases of up to 26 have been reported.)  I
finaly traced the problem down: Tops-20 kermit (4.2(253)) frequently ignors
a GE (Generic Erase, i.e. Delete File) packet sent immediatly after an ack
to a B packet.  (Is the tops-20 clearing its input buffer before going back
to server wait?)  By adding a delay (20 seconds is probably a bit much, but
works) before sending the GE packet, this problem has dissapeared.  My
kermit implimentation cannot resend the GE packed after a timeout, since it
requests to delete the oldest generation of a file (-2) after it has been
transferred. (If the Ack of the GE packed was lost, repeating the GE packet
would erase a file that has not been transfered.)

A completly different solution to the problem would be to convince the
tops-20 end to tell me what generation of the file it is sending.  I'm not
sure I want to put the work into supporting atribute packets even if the
tops-20 end did.

[Ed. - What the DEC-20 Kermit server actually does in response to a GE
packet is to send back a whole transaction, in which the Data packets list
the actual files (including generation numbers) that were listed.  Thus you
don't get an ACK, you get a "long form response".  If you want to try to
pick out the filenames from the data packets you can do so, but this would
mean the Prime code would have to have special knowledge of the form in
which the DEC-20 sends this information.]

Another problem I have noticed with tops-20 kermit 4.2(253) is it wants a
control-v counted as two characters in a GE packet it receives, which does
not agree with my interpretation of section 8.2.1 of the kermit protocol
manual (sixth edition).  (The case of control characters is not dirrectly
discussed, so it is somewhat left to interpretation.)

[Ed. - If you want to quote a special character in a filespec sent to a
DEC-20 Kermit server, precede it by a Ctrl-V, just as you would do when
typing odd filenames directly to TOPS-20.  The data field of the generic
packet is formed before datalink-level encoding, therefore the little length
fields within the data packet of a generic command reflect the length before
encoding.  For instance, if you want to send a generic command to delete a
file called x.? (where ? is not normally a legal character in a filename),
the data field of the g packet would look like "E$x.#V?" -- $ indicates a
length of 4, AFTER DECODING (and before encoding).  Clear?  (ha)]

Bob Larson <[e-mail]>

------------------------------

Date: Fri 8 Aug 86 21:37:30-PDT
From: Dan Davison <[e-mail]>
Subject: VAX to PC binary file xfers
Keywords: VAX/VMS Kermit, MS-DOS Kermit

Someone asked about doing binary file transfers via kermit from an IBM PC to
a VAX.  A response indicated that it can be done.  I'm sorry to report that
response is wrong in some cases.

We routinely transfer files from VAXEN to uVAXen and other PCs (Pro 350,
Dec Rainbow, IBMPC Portable, a few others).  Vax has a binary file format tha
CANNOT be transfered using KERMIT.  They cannot (1) be transfered via KERMIT
VAX to VAX; (2) uVAX to VAX (or vice versa) and (3) PC to VAX (or vice versa).

It doesn't matter what parity, baud, stop,start etc. you use.  We speak to
a set of 785s, everybody running the same version of kermit.  The thing to
do is a

    DIR/FULL/ALL filename.EXE

If the record size is 512 (the usual for VAX executables and some special
format files made via FORTRAN and PASCAL) you are guaranteed to get garbage
after the transfer.  We have tried all sorts of ways around this, but the only
way that works is to copy the files over DECNET to a machine that has a tape
drive.

We also cannot transfer binary (.OBJ) files with Kermit.  The problem lies n
in KERMIT but the way the VAX keeps information in the file header.  You can
transfer the files, true, but they are useless and cannot be RUN or LINKed.

Non-DEC binary files, on the other hand, can be transferred successfully, re-
loaded and used.  I use our Microvax to backup my hard disk (until its
reacent headache (crash) courtesy of Federal Express.

If anyone wants further info, or knows of a way around this, please get in
touch with me at one of the addresses below.

Dr. Dan Davison, Dept. of Biochemical and Biophysical Sciences, SR-1,
University of Houston--University Park, 4800 Calhoun, Houston, Tx 77004

[Ed. - The normal trick is to SET FILE TYPE FIXED or SET FILE TYPE BINARY.
Did you try either or both of these?  (They are alleged to work, provided
the record length is 512.)  Of course, what VMS Kermit really needs is
attribute packets.  PDP-11 Kermit uses this to transfer the entire
FILES-11 FAB (or whatever it's called) along with the file, so it can be
properly reconstructed on the receiving system, provided it's also FILES-11.
Future releases of VMS Kermit may work somewhat better in this respect.]

------------------------------

Date: Fri, 01 Aug 86 23:19:27 EDT
From: Mark S. Feldman <[e-mail]>
Subject: Being thrown into CP while using CMS Kermit
Keywords: CMS Kermit

Recently, there has been discussion here about the problem of CMS Kermit
falling through to CP.  I've used CMS Kermit a lot, both here at the
University of Maryland and at several comercial sites.  Only one of the
comercial systems that I have used has ever thrown me into CP, and it was
doing it fairly consistently one day.  The problem was not with Kermit, but
with the over-loaded state of the computer.  I don't even think that having
control returned to kermit would have helped that day - the machine was
being thrown into CP because it could not keep up with the input.

What if you want to go into CP?

While preventing CMS Kermit from being thrown into CP might help some
people, I wonder if it might hurt some others.  What if you need to break
out of (server) CMS Kermit and for some reason the pc Kermit is unable to
transmit a finish packet, or any packet for that matter.  Wouldn't the
proposed change to CMS Kermit make it very difficult, and perhaps
impossible, to get out of CMS Kermit server mode if their were a problem
with the pc Kermit?

  Mark

[Ed. - When using the CMS in linemode through a 3705 or equivalent, then
almost any kind of framing or parity error can throw you into CP.  The
proposed change will continue Kermit where it left off, immediately,
whenever this happens -- a fairly frequent occurrence over dialups, etc.
It's still possible to break out if you're coming in as a 3270 through a
Series/1-style front end, and it may also be possible with a 3705 if
you type a lot of BREAKs in a row.]

------------------------------

Date: Tue, 19 Aug 1986 16:04 EDT
From: Nick Gimbrone <NJG@CornellA>
Subject: CMS KERMIT under VM/XA/SF?
Keywords: CMS Kermit

Has anyone succeeded (tried) in using CMS Kermit under VM/XA/SF?

[Ed. - CMS Kermit (any version) should work, provided VM/XA/SF has TTY
support (does anyone know if it does?).  In any case, Kermit should still
work on these systems through Series/1-style front ends.]

------------------------------

Date: Mon, 11 Aug 86 13:04:12 MEZ
From:  [e-mail]
Subject: Kermit through 3708 Front End or WETRONIC Protocol Converter?
Keywords: Protocol Converters

       We (id est: the Computer Center of the University of Bonn, West
Germany, where I work beside my studies), we want to run KERMIT on an
IBM3708 Protocol Converter.  Did anyone of yours already test this
configuration?  Did anyone of yours heard about someone *out in netland* who
has this configuration and/or has tested it and/or is using it.  Any notes
concerning this problem will be very welcome !!!!!!!!

[Ed. - The 3708 makes an ASCII terminal look like an SNA terminal, rather
than a local bisync 327x terminal.  There is no code in CMS or TSO Kermit
to handle these, and it's not clear that there ever can be -- for a protocol
converter to be usable for Kermit file transfer requires that it can be put
into transparent mode (and that the mainframe Kermit program know how to do
this); does the 3708 have a transparant mode, like the Series/1 or 7171?]

Did anyone *out there in netland* already succeded in a filetransfer using
KERMIT for conecting PCs to an IBM/370-series-mainframe via a Protocol
Converter WETRONIC PCI/1076?  We are able to run an emulation on this
configuration, but we still have problems when trying the file transfer
facility.  Any notes concerning this problem will be very welcomed.  Thanks
a lot for all your efforts in advance.  Have a nice day.  Please answer me
directly to:
                 Thorsten Glattki
                 Computer Center,Univ.Bonn,W.-Germany
My netaddress is : <UZR500%DBNRHRZ1.BITNET at WISCVM.WISC.EDU>

[Ed. - Similar considerations apply here.  Does the WETRONIC thingie have
a transparent mode?  If so, code can be added to mainframe Kermit to turn
this on and off, as it does for 7171's, etc.  Otherwise, forget it.]

------------------------------

Date: Fri, 29 Aug 86 11:14:58 BST
From: Chris_K_now-and-then <[e-mail]>
Subject: PRIMOS Kermit v. IBM-PC 2.29?
Keywords: Prime Kermit, MS-DOS Kermit

     Has anyone actually worked IBM-PC Kermit 2.29 against (any) PRIMOS
Kermit successfully?  If so a note as to the settings employed would be much
appreciated.  A friend at Salford is failing utterly.

                                          Chris Kennington.

[Ed. - This combination is in common use between The Source (which has
Primes) and their customers (many of whom have PCs).  However, most
accesses to The Source are through Telenet, which adds an additional
level of complexity.  The magic in that case, however, is simply "set
parity mark".  Do you have the most recent (May 86) version (7.57)?]

------------------------------

Date: Mon, 8 Sep 86 15:40:47 EDT
From: Kenneth Van Camp -FSAC-  <kvancamp@ardec>
Subject:  Kermit and Paradise Graphics Card?
Keywords: Graphics Card

    I recently replaced my old IBM monochrome (non-graphics) display
adapter with a Paradise Modular graphics card (still driving my IBM
monochrome display) on my PC-XT.  For some reason, the text display with
this board is noticeably slower than with the old mono card.  I can live
with this, but when I go into Kermit I am now dropping characters when in
the normal connect mode.  I tried slowing down the baud rate to 4800, and I
even told Unix to put in some fairly long pauses after every line (stty
cr3), to no avail.  I also tried both types of flow-control in Kermit, with
no effect.  It's important that I point out that nothing has changed except
the display adapter -- same modem, same Kermit, etc.  Yet Crosstalk XVI
doesn't seem to have the same problem; no characters are dropped at any
speed.  Does anybody know what's going on?

          --Ken Van Camp <[e-mail]>

------------------------------

End of Info-Kermit Digest
*************************
-------
15-Sep-86 09:40:29-EDT,25093;000000000000
Mail-From: SY.FDC created at 15-Sep-86 09:35:20
Date: Mon 15 Sep 86 09:35:20-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest, V5 #8
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Mon, 15 Sep 1986       Volume 5 : Number  8

Today's Topics:

   Prerelease Version of MS-DOS Kermit 2.29A Available for Testing
     New Release of Kermit for Concurrent (nee Perkin-Elmer) 3200
              New Kermit for Burroughs 7800 and A Series
                    Glut of Kermit Files (A Plea)
                        MS Kermit use of COM3
               CMS Kermit under VM/XA/SF Clarifications
                      Distributing TAKE scripts.
                     Kermit 2.29 for Tandy 2000?

----------------------------------------------------------------------

Date: Fri 12 Sep 86 13:45:15-EDT
From: Frank da Cruz <[e-mail]>
Subject: Prerelease Version of MS-DOS Kermit 2.29A Available for Testing
Keywords: MS-DOS Kermit 2.29A, IBM PC, Rainbow
Cross-Ref: DEC Rainbow, see Rainbow

A prerelease test version of MS-DOS Kermit 2.29A is available for testing
on the IBM PC,XT,AT and compatibles, and the DEC Rainbow.  This test version
is being released at this time mainly to help those who must use the program
for file transfer in half-duplex environments (e.g. with IBM mainframes or
certain HP or Harris minis) where line turnaround handshaking must be used;
version 2.29 has a bug that prevents this from working, and 2.29A fixes the
bug.

2.29A also includes some new features.  These are not necessarily completely
developed or polished in this test release, but they appear to be mostly
functional and usable:

. Performance improvements, particular on the IBM PC family.
. Support for extended-length packets, up to 1000 bytes long.
. A script facility, almost identical to the one in DEC-20 Kermit.
. A TRANSMIT command, for raw uploading.
. An ECHO command.
. VT102 ANSI printer control support (IBM PC family only).

Extended-length packets may be enabled using the SET SEND/RECEIVE
PACKET-LENGTH command, and will be used if the other Kermit program supports
them.  So far, only Kermit-11 (for PDP-11's with RSX, RT, RSTS, etc) does,
but version 3.1 of IBM VM/CMS mainframe Kermit, which will be announced
shortly (next week?) will also support long packets.

The script facility allows you to write "programs" of Kermit commands to
interact with the remote system.  Scripts are typically used for dialing
modems, logging in on remote systems, or performing other routine and/or
complicated interactive jobs.  The Kermit script is not a full-fledged
programming language (with variables, conditional branching, etc), but
differs from other popular script facilities by not differentiating script
commands from other program commands, so that all Kermit commands may be
freely intermixed in a script.  The commands that were added specially to
support script execution include INPUT, OUTPUT, PAUSE, ECHO, plus various
SET options.  The Kermit User Guide chapter for the DEC-20 (KER:K20MIT.DOC)
may be consulted for a complete description of the script facility.

Raw uploading is accomplished using the TRANSMIT command, which sends a
file "raw", a line at a time.  It works like DEC-20 Kermit's TRANSMIT
command, and may (like any other Kermit command) be used in conjunction
with scripts.

The ECHO command includes \ooo escape sequence recognition for including
arbitrary characters in octal notation.  This allows all sorts of fancy
special effects on the Rainbow by including VT100 commands in strings to
be echoed, and also on IBM PCs that have ANSI.SYS or similar console drivers
loaded.

ANSI printer support allows the PC to respond to host escape sequences
for printing selected regions of the screen, turning the printer on and
off, etc.

Version 2.29A is being put together by Joe Doupnik at Utah State University
([e-mail]), who also was responsible for version 2.29.  The performance
improvements, bug fixes, and long packet support were done by Joe, and the
script facility came from James Sturdevant at AC Nielsen in Minneapolis,
and Joe integrated it into the new release.

The files are in KER:MSTIBM.BOO for the IBM family and KER:MSTRB1.BOO for
the Rainbow.  Use any of the BOO-file decoders, KER:MSBPCT.*, to decode into
runnable .EXE files.  A brief guide to the new features of 2.29A is in the
file KER:MST29A.HLP.  No additional major functionality is intended for
2.29A, so please restrict your comments and suggestions to features that are
already in the program.  Note that the MST*.BOO files may be replaced from
time to time as bugs are reported and fixed, up until the final release of
this version.

------------------------------

Date: Thu 11 Sep 86 10:29:15-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Release of Kermit for Concurrent (nee Perkin-Elmer) 3200
Keywords: Concurrent Kermit
Cross-Ref: Perkin-Elmer Kermit (see Concurrent Kermit)

This is to announce version 2.1 of Kermit for the Concurrent Computer
Company (formerly called Perkin-Elmer) 3200 series under OS/32 7.2.1 and
up, by Paul Mamelka, Southwest Foundation for Biomedical Research,
San Antonio, Texas.  The major changes from version 2.0 of June 1985 are:

. Name change from Kermit-PE to Kermit-CO
. Horrible bug fixed caused by typo (RECKPT instead of RECPKT)
. Minor bugs also fixed
. First 3 letters of command or set option now sufficient for abbreviation
. SYSIO style now controlled by parity setting
. Selection of text, binary, contiguous file types
. End of record selection for text file transmission
. "File Warning" added (filename collision avoidance)
. Initialization file
. Automatic error logging

The new files replace the old ones as PERKIN.* in the Kermit distribution
(even though Paul sent them to us with the new prefix CON to denote the
company name change).

------------------------------

Date: Thu 11 Sep 86 11:44:59-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Kermit for Burroughs 7800 and A Series
Keywords: Burroughs Kermit

This is to announce Kermit for the Burroughs 7800 and other Burroughs large
systems (5000/6000/7000 and A series), written in Algol by Larry Johnson,
Dave Squire, and Katie Stevens at the Computer Center, University of
California at Davis.  The program and user manual are in the Kermit
Distribution as B78*.*, alongside the other Burroughs mainframe Kermits,
B68*.* (for the 6800, from Quest Research, Inc), and B79*.* (for the 7900,
from THE--Technische Hogeschool Eindhoven).  If any Burroughs aficionados
out there know if this new program makes either or both of the other two
redundant, please let us know so we can move them to a less critical area.

UC Davis has indicated willingness to supply this version of Kermit directly
to other Burroughs sites that request it directly from them.  The address is:

  David Squire
  Senior Programmer, ID-1023
  Systems Group, Computer Center
  University of California, Davis
  Davis, CA  95616  USA

------------------------------

Date: Fri 12 Sep 86 14:45:15-EDT
From: Frank da Cruz <[e-mail]>
Subject: Glut of Kermit Files (A Plea)
Keywords: Kermit Distribution

As Kermit's popularity escalates, more and more contributions of Kermit
programs show up on our doorstep.  We know what to do with many of them:
new ones simply get installed (though often a good deal of file renaming
is necessary to avoid conflicts), etc.  But what do we do when there are
multiple versions for the same system, or similar systems?  In some cases,
we can't really tell when a version is redundant, because we don't know
enough about the systems involved (like the Burroughs mainframes mentioned
in the previous message).  In other cases, two different people submit
totally different Kermit programs for the same system; should we keep both
(sometimes there are more than two!)?  It would be most helpful if we could
get some feedback from the people who actually use these programs.

Here are a few items we could use some help with, as we try to clean up
our Kermit collection:

Apple II DOS - Does anybody use the native 6502 assembler version that was
  based on an old release of the CROSS version?  (By the way, a new,
  native assembler version is under development at the U of Maryland, and
  work is also being done on a new release of the CROSS version.)

Burroughs - Are all 3 versions (prefixes B68, B78, B79) necessary, or can
  one or two of them be eliminated?

CDC - We have two CDC Cyber Kermits, one in Fortran, one in Compass.  Do we
  need both?  Is one more portable, or clearly better in other ways, than
  the other?

Commodore 64 - The "major" version is in CROSS, based on the Apple DOS version.
  CROSS only runs on DEC-10s and DEC-20s, most of which are not long for
  this world.  Does anybody care enough about the C-64 to translate this
  into a native assembler (if there is such a thing)?  And what about the
  other C-64 Kermit written in FORTH?

Data General MV Series with AOS, AOS/VS - We have several Kermits for these
  systems.  Most of these are quite old, primitive, buggy, and undocumented.
  There are at least 3 or 4 separate efforts underway to replace them.  I
  have urged the various people or groups to get together and settle on a
  single replacement.  Watch Info-Kermit for news, or read the file
  KER:AAWAIT.HLP in case you're interested in contacting any of these people
  directly (this file contains a list of all the Kermit programs that we
  know to be under development).

DEC PDP-11 - We have a main version (Brian Nelson's Macro-11 version) that
  runs on all the DEC operating systems, but there's also an old OMSI Pascal
  version just for RT-11.  Does anyone use the Pascal version any more?

DEC Rainbow - Does anyone out there run QNX on the Rainbow?  Have they tried
  QNX Kermit?  How about on the IBM PC?

DEC VAX/VMS - The main version is the Stevens Inst. of Tech. version written in
  Bliss, but also distributed in Macro-32 source form.  But there's also an
  old Pascal version.  Does anyone use the latter?  Also, is anyone using
  the VMS implementation of C-Kermit?

Gould/SEL 32 MPX-32 - We have two separate versions, both in Fortran, for this
  system, prefixes GM1 and GM2.  Do we need both?  Can GM1 be retired?

Honeywell - All this Honeywell stuff is a mystery to me.  In addition
  to Multics Kermit (we have one version of this, but have heard that there
  are several others floating around), there are two separate versions for
  GCOS (one in B, one in C, prefixes HDP and HG, respectively), and two for
  CP-6 (one in Pascal and one one in PL/6, prefixes HCP and HC6).  Do we
  really need all of these?  How about "Level 6" or DPS-6?  Can anyone who
  really knows the Honeywell world recommend a consistent, minimal set of
  good Kermit programs for the Honeywell line?

IBM 370 MVS/TSO - We have a couple different versions of Kermit for this
  system, but they will all soon be replaced by a new comprehensive release
  from the National Institutes of Health.

ICL/Perq - Does anybody still have Perq workstations?  If so, can they tell
  us if we really need two different Kermit programs for the Perq, both in
  Pascal?  (Prefixes PQK and PQ2.)  If not, which one is better?

Intel - There are literally dozens of Kermit programs for Intel micros,
  many of which we haven't either bothered to install.  Some are for RMX
  (or iRMX), some for ISIS.  Can anybody who knows about Intel development
  systems take a look at these and tell us which ones are redundant?
  In addition to the MS-Kermit 2.29 Intel support modules, we have
  specific Intel Kermit programs with prefixes RMX, I86, MDS, and MD2.

Software Tools - We have a version of Kermit written in Ratfor for use with
  the Software Tools library.  It reportedly runs on at least the HP-3000
  and the Sperry 1100.  Is anyone actually using it?  Does anyone know if it
  runs on any other systems?

Univac (oops, I mean Sperry (oops, I mean Burroughs)) 1100 - We have 3
  Kermits for this one: prefixes ST (Software Tools), UN (Assembler), and
  another UN (Pascal).  Can any of these be sacrificed?  At least, can one
  of them (say, the assembler version) be considered the "main" one?

Victor 9000/Sirius 1 with MS-DOS - In addition to the support in MS-Kermit
  2.29 for this system, there's also a C language version.  Is anyone using
  it?

Comments, comparisons, reviews, suggestions will be appreciated.  The more
redundant material we can retire, the more room we have for new Kermit
programs, and the less often we have to add new tapes to the Kermit
distribution.  Meanwhile, anybody who's considering writing a new Kermit
program or upgrading or fixing an old one, please contact Kermit
Distribution at Columbia before proceeding to make sure that your work
will not be duplicating someone else's.  Thanks!

------------------------------

Date: 10 SEP 86 12:12-MDT
From: JRD@USU
Subject: MS Kermit use of COM3
Keywords: MS-DOS Kermit, COM3

        In response to queries about use of more than two communication
ports with MS-DOS Kermit, I have compiled a few pointers.

        MS Kermit, internally, does allow many serial ports: four directly and
as many as wished through rebuilding. As we all realize MS Kermit tries to
connect directly to the serial port hardware (the UART chip, if possible
so that characters can be read by an interrupt procedure. Hardware details
differ greatly among MSDOS machines so code for serial port specifics
is located in the system dependent module MSX---.ASM.  The number of ports
visible on the Status screen is adjusted to match the kind of machine (model)
being used.

        The system independent part of Kermit has a standard table of four
named ports, expandable to whatever size is needed, which hold nine bytes
of information for each port. That information is the baud rate index, flag
for local echo on/off, parity type flag, flow control bytes and on/off flag,
and handshake (line turn around) character and on/off flag. Expansion thus
uses little space. The system dependent module(s) examine this table to
decide how to setup the particular port. The table is found in file MSSCOM.ASM.

        For IBM PCs and clones MS Kermit knows the hardware addresses
of COM1 and COM2, which have been specified by IBM. Higher comms port addresses
have not been standardized and thus are not mentioned in MS Kermit. However, it
is a simple matter to add new addresses to the list in MSXIBM and to readjust
the couple of tables which support the Set Port command (performed in MSXIBM).

        The most recent (September) issue of PC Tech Journal has an article on
boards offering many serial ports, together with the range of addresses
provided by each board. It is unfortunate that the addresses near standard
comms ports are frequently used by other add-in hardware so that no consensus
exists for COM3 et seq. and hardware conflicts are common.

------------------------------

Date: Thu, 11 Sep 1986 13:47:00 EDT
From: Nick Gimbrone <NJG@CORNELLA>
Subject: CMS Kermit under VM/XA/SF Clarifications
Keywords: CMS Kermit

To clarify my question concerning CMS Kermit under VM/XA/SF.  We currently
have and are running this operating system.  The CMS we are running under it
is esentially identical to CMS R4 under an HPO system (we don't yet have
FILELIST and that ilk of commands up and we have a small mod to XEDIT to
address an LDEV problem).  VM/XA does NOT support any TTY access.  VM/XA/SF
only supports 3270s (real, or fake as with the 7171).  When attempting to
run Kermit over a 7171 or Passthru (which works under VM/HPO and VM/SP
systems) under VM/XA/SF I get an addressing exception.  I will eventually be
looking at this, but if anyone has already solved the problem I'd appreciate
hearing from them via the net.  Thank-you.

------------------------------

Date: Thu, 11 Sep 1986 02:17 PDT
From:   "Jeffrey Sicherman"  <[e-mail]>
Subject: Subject: Distributing TAKE scripts.
Keywords: TAKE command, Script

Since one of the problems of using micro KERMITS with unfamiliar mainframes
is not knowing the necessary protocol parameters that may be required to
interface through front-ends and operating system peculiarities, a standard
way of distributing appropriate TAKE scripts on a system or site specific
basis would be desireable.  Why not bootstrap them?

     In particular, I would propose a

             CONNECT TAKE [filename]

command for the local system.  This would have the effect of CONNECTing to
the the host which should be running KERMIT in non-server mode (by
definition of the problems, we are not ready to send packets yet).  The user
would then enter a new command:

             GIVE [systemname]

on the host. Ignoring the optional name arguments for moment, the effect of
this would be that the local micro would interpret the lines coming from the
host not only as displayable data but as local commands, just as though a
local TAKE had been performed.  Most likely these would be SET commands:
(almost) anything that would be valid in a local TAKE file (it would not be
wise to switch ports or line parameters at this point or invoke any
transfers or change of mode).

[Ed. - Well... It's a good idea, but complicated.  The first pitfall is that
neither the host Kermit program nor the local one necessarily know what
parameters are really necessary -- for instance, if the connection goes
through an X.25 network, or bounces off a satellite, or is very noisy.  The
user is the only one who really knows.]

     Of course, a minimal subset of all possible commands would probably be
most appropriate for consistency across a broad range of micro
implementations; such a list would be sent when the GIVE is issued with no
systemname argument.  It would establish the minimum conditions for a usable
and reasonably efficient exchange.  Where differences are significant with
respect to different local systems, especially with regard to reliability or
efficiency, a systemname specification would send SETtings appropriate to
that combination.  I have stated this as systemname rather than filename
since there is no reason that the responses could not be built into the
program rather than increasing the number of distribution files.  This makes
it somewhat inflexible though, so there are good arguments on each side
(maybe I'm only arguing with myself) and I don't think the choice is
critical; either way will serve the purpose.

[Ed. - The problem here is that there are hundreds of programs to deal with,
and, because Kermit is a volunteer, cooperative, loosely organized effort
(at best), each program's syntax has its peculiariarities, despite the
efforts that have been made to settle on consistent terminology (e.g. in the
User Guide and Protocol Manual).  Does this mean we have to change 50 or 100
programs to make them conform?  Or does it mean that every mainframe Kermit
should have explicit knowledge of the variations in syntax used by all the
other Kermit programs?  Unfortunately, both alternatives are impractical.]

    The optional filename on the CONNECT TAKE command would cause the
received commands to be stored into a local file that could be TAKEn locally
for subsequent uses.  Admittedly, this is not an error-free exchange but the
errors are likely to be noticeable to the operator when rejected by the
command processor and the process can be repeated. By saving an error-free
transmission, it need only be performed once or infrequently.  For this
reason, a remote KERMIT implementation should probably announce the
existence of new values at initialization time when changes of significance
are made. If random (non-syndromatic) single character changes in
transmission are of concern (such as for decimal specifications of
block-check options, maximum lengths, framing character specifications) I
propose the following mechanism:

     Define a new command called VERIFY which takes all the same operands as
SET but merely compares its target value to the current setting. If a
discrepancy exists, display an error message.  By inserting SETs and VERIFYs
in the same GIVE transmission at appropriate intervals, most such errors
should be operator detectable.  The implementation seems rather
straightforward to me since the same parsing could be used with a global
mode switch telling low level logic whether a store/call or compare/error is
to be invoked.  A final possibility to minimize the possibility of an
erroneous transmission being used would to, either by default or command
variation, cause the commands in the take to be checked (and verified), but
only put into effect if no errors occur.  This could be accomplished by
having an edit-only pass on initial receive and rereading the take
destination file if error-free. If the no-file-name variation were used, the
take stream could be stored in a temporary file and/or an internal buffer.

[Ed. - Kermit already has an automatic way for each Kermit program to
"configure" the other one with respect to settings for buffer size, packet
terminator, padding, timeout, etc., namely the Send-Init negotiation.  These
packets provide a common intermediate representation for these parameters
and their values, something you don't get with textual SET commands, which
can vary from program to program (in fact, some programs don't have command
parsers at all, but use menus instead).  Unfortunately, not everything can
be negotiated in these error-checked packets.  Most notable are physical or
datalink settings like baud rate, parity, and flow control, because these
must already be set correctly before the Send-Init negotiation can take
place.  And, still more unfortunately, these parameters are often unknown
(and sometimes unknowable) to the programs themselves.  However, it is
possible to adopt some heuristics to get around some of the other problems,
and these can be fairly simple.  One example would be automatic parity
detection -- when the program gets the first packet (S, I, Y, G, etc, which
will never contain 8-bit data), it can figure out what the parity is, if
any, and then adjust itself accordingly.  This kind of trick seems more
practical and reliable than the proposed method of exchanging SET commands.]

------------------------------

Date: 11-Sep-1986 0946
From: [e-mail] (Gary Hafner, DEC Littleton)
Subject: Kermit 2.29 for Tandy 2000?
Keywords: Tandy 2000 Kermit

1) Does anyone out there know of a version of MSKERMIT V2.29 that's been
modified for the Tandy 2000? If not, could someone take a minute and explain
what it would take to do such a thing? Being a mainframe-type of user rather
than a PC user, I don't really know a heck of a lot about MS-DOS, but I have
a relative that could use this program if there were some way to come up
with it (who knows, between the 2 of us we might even be able to come up
with it ourselves...).

[Ed. - The version of Kermit we have for the Tandy 2000 was based on an
ancient version of IBM PC Kermit, namely 1.20, when it was still a
single-module program just for the PC, adapted by Steve Padgett at the U of
Texas in Feb, 1984.  The Tandy-specific code is under T2000 assembly
conditionals.  It would be great if somebody could look at this code and
churn out MSX, MSY, and MSZ modules from it, to fit in with the current
multi-module MS-DOS Kermit.]

2) I understand there's already 2 files for the Tandy 2000, and one of them,
a file with a ".FIX" extension, appears to be in a form similar to the
"MSxxx.BOO" formats for other machines. Could someone jot down the names of
the programs that both create AND 'unscramble' this format? I'm not familiar
with it at all.

[Ed. - The .FIX file was a precursor to the .BOO file.  It was a simple
4-for-3 (or was it 3-for-2?) encoding, but with no compression.  The program
to decode the .FIX file (this was the only survivor of the species) was in
TA2EXE.BAS.  However, as of now, both the .FIX file and the TA2EXE.BAS
program have been removed and replaced by a TA2000.BOO file, which you can
"un-boo" in the normal way, as described in MSBAAA.HLP.  The .BOO file is
only about 18K long, compared with the 30K .FIX file (and 15K .EXE file).
The 8-bit binary .EXE file is now available in KB:TA2000.EXE, for those who
can FTP it directly from CU20B.]

------------------------------

End of Info-Kermit Digest
*************************
-------
18-Sep-86 16:06:52-EDT,20563;000000000000
Mail-From: SY.CHRISTINE created at 17-Sep-86 12:16:56
Date: Wed 17 Sep 86 12:16:56-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #9
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 17 Sep 1986       Volume 5 : Number  9

Today's Topics:
          Announcing IBM Mainframe VM/CMS Kermit Version 3.1
                    MS-DOS Kermit 2.29A Prerelease
                      Announcing Kermit for DTSS
        CP/M-80 Kermit-80 Version 4.08 on Trial Release in UK
         Comment on MS-DOS Kermit vs Graphics Screen Display
                    Problems with Atari ST Kermit
                   Problems with MacKermit 0.8(34)

----------------------------------------------------------------------

Date: 1986 Sep 9   20:05 EST
From: (John F. Chandler) <[e-mail]>
Subject: Announcing IBM Mainframe VM/CMS Kermit Version 3.1
Keywords: CMS Kermit, IBM Mainframe

   This is to announce CMS Kermit Release 3.1 for IBM 370-series mainframes
running VM/CMS.  The new version has been consolidated into a single source
file, but there is a new, optional, separate program which can be used for
loading Kermit into high memory (thereby allowing Kermit to invoke any CMS
program).  An effort has been made to keep the CMS-dependent parts of Kermit
together (many operations are performed using MACRO's which could be
redefined to fit, for example, TSO), but there are still many spots in the
code which implicitly assume the CMS environment.

Below is a list of the more important additions in Version 3.1:

1.  Massive reorganization and cleanup of source code.

2.  Advanced server functions.

3.  Basic and advanced commands to a local server from remote mode, driven
    by TAKE command file.

4.  Long packet protocol (type 0 extended headers).  Allow arbitrary foreign
    filespec in SEND and GET commands.  Provide optional prefix and suffix for
    outgoing file headers.

5.  CWD and SPACE commands along with SET DESTINATION.  The default filemode
    for SEND is taken from CWD.

6.  TYPE, ECHO, XTYPE, and XECHO commands (the latter two being Series/1
    transparent-mode analogs of the first two, useful for raw downloading).

7.  REMOTE KERMIT commands honored by CMS Kermit server, including SET, SHOW,
    TDUMP, TAKE, CMS, CP, STATUS, and SPACE.

8.  TEST mode for debugging.

9.  Optionally append to, rather than, replace, old files with duplicate names.

10. Optionally keep files even when the transfer is cancelled.

11. Send Attribute packets with file size, host system, and possibly file
    type and record format.  Receive and ACK attribute packets.

12. Option whether to search only the "home" disk and its read-only extensions
    or all accessed disks when the filemode is omitted from filespec.

13. Automatic recovery from line-noise interruptions on TTY lines.

14. Multi-column, two-level selective SHOW display.

15. New help text for HELP command.

[Ed. - Many thanks!  Version 3.1 began as 3.0 (which was never released),
consisting mostly of source-level reorganization, cleanup, bug fixes,
plus new keyword parsing and a new help command, by Vace Kundakci of
Columbia.  John made further contributions, including the new server
functions, Attribute packets, new SET and SHOW commands, the new CMS chapter
for the Kermit User Guide, the new installation procedure, and more.  Bob
Bolch of Triangle Universities added the extended-length packet support,
Clark Frazier of the Harvard B-School added features for raw downloading
through the Series/1 (XECHO and XTYPE).  The new version should also fix
most or all of the bugs that were reported by many sites (particularly by
Greg Small at UC Berkeley) since the release of version 2.  The new files
are in KER:CMS*.* on CU20B.  The old ones will be kept on CU20B for a while
as KO:CMS*.*.]

------------------------------

Date: Tue 16 Sep 86 12:41:47-EDT
From: Frank da Cruz <[e-mail]>
Subject: MS-DOS Kermit 2.29A Prerelease
Keywords: MS-DOS Kermit

The MS-DOS Kermit 2.29A Prerelease that was announced in the previous digest
turned not to work with IBM mainframe Kermits.  It has been fixed in this
respect and replaced.  The new version is dated September 15 rather than
September 10th, and has been tested against VM/CMS Kermit with no problems,
using both 3705 (linemode) front ends and Series/1-style ASCII protocol
converters, and both regular and extended-length packets up to 1000 bytes in
length.  The test versions of MS-Kermit are in KER:MST*.* on CU20B and also
on KERMSRV as MST* * for BITNET access.

Also, as noted in the .HLP and .BWR files, when parity is set to NONE, all 8
bits of incoming characters are displayed on the screen during CONNECT.
This will cause consternation to users of systems (particularly the IBM PC
family) with 8-bit character sets.  This feature was added to accommodate
European and non-Roman-alphabet environments that really do have 8-bit ASCII
character sets, but it was erroneously tied to the PARITY setting.  In fact,
there are systems (like the DEC-20) which have 7-bit ASCII character sets,
but which send parity (e.g.  even) to the terminal, but don't require parity
coming from the terminal, and whose Kermit programs put the line into
transparent 8-bit mode for file transfer.  Until a new SET command is added
to select 8-bit or 7-bit terminal display, the workaround is to SET PARITY
SPACE during terminal emulation and to SET PARITY NONE for file transfer.

------------------------------

Date: Tue 16 Sep 86 13:11:57-EDT
From: Frank da Cruz <[e-mail]>
Subject: Announcing Kermit for DTSS
Keywords: DTSS Kermit

A new version of Kermit has been written for Honeywell 6000 mainframes
running the Dartmouth Timesharing System (DTSS) in "Virtual PL/1" (VPL1) by
Philip Koch of the Dartmouth Kiewit Computer Center.  This is a relatively
esoteric Kermit since there are not very many DTSS installations, and of
them, few have VPL1 compilers.  However, brief instructions are included for
converting to non-virtual PL/1.  There's no manual or help file, but there
are some comments at the beginning of the source file, which is in
KER:DTSS.PL1 on CU20B.  Thanks to Philip Crowell of Dartmouth for sending
the program to us on tape.

------------------------------

Date: 11-SEP-1986 17:01:26
From: [e-mail] (Alan Phillips)
Subject:  CP/M-80 Kermit-80 Version 4.08 on Trial Release in UK
Keywords: CP/M Kermit
Cross-Ref: Kermit-80 (see also CP/M Kermit)

Bertil Schou at Loughborough University in the UK ([e-mail] on
the UK JANET network) has now got his mammoth rewrite of Kermit-80 available
for test release. At the moment the files are available only by FTP in the UK
from his machine, but once the very worst bugs have been cleared we'll be
getting the files to Columbia for wider circulation. Bertil has sent in some
notes on what changes he's made: here they are:

Superficially,  there  is  little  real change  in  operation  of Kermit-80,
but  there  have  been some major jobs  tackled  like trapping BDOS calls and
multiple FCB buffering...

New bits for this version include:

               SET {SEND/RECEIVE} START-OF-PACKET character
               SET DIRECTORY-FILE-SIZE  (Shows  or hides  file  sizes  on
                       DIRectory displays)
               USER to set other user spaces
               RECEIVE to collect a file from a remote SENDer
               GET to collect a file from a remote SERVER
               SEND {local filename} {remote filename}
               TAKE to take command files from disk
               automatic  TAKE  KERMIT.INI  on default  disk  on  loading
                       KERMIT-80 (useful for SET BAUD etc.)
               much improved speed on DIRECTORY
               automatic  CLOSE-ing of a terminal connection if the  line
                       is  DROP-ped  (currently only for  an  Apple,  and
                       Torch  has  a dummy test for cntrl-] D in  connect
                       state)
               improved printer handling. (Kermit-80 sends an XOFF to the
                       host if the characters are comming in faster  than
                       they  are  printed.   This does not work  in  this
                       version,  as another option,  SET FLOW-CONTROL has
                       not been fully implemented - also,  I did not have
                       a printer to test this out on a Torch...)

On  the  negative side,  only LASM can be used  to  assemble  the source files.
I personally see no pont in being able to support several assemblers if LASM
can do the job, but then again, I have not  used  the MAC80 cross assembler...

All  source  files  have  been  renamed,  and  there  are  a  few additions.
All source files are named in the form:

               CPaxxx.ASM

where:

               a=S for system independent source files
               a=X for system dependent source files
               a=other letters for .HEX files etc.   These files have NOT
                       been created as yet.

The  system  dependent code has changed a  litle  too,  hopefully bringing  the
CPXSYS.ASM (formerly CP4SYS.ASM) file a  bit  more toward  a manageable  size.
There  is now the  possibility  for FAMILIES  of  systems,  like APPLE and
NorthStar  (also  Comart), which  contains  code  for computers of a single
type.   I  have immediately  gone against all this by creating a family with
the code for Torches, Cifers, Ithacas and Superbrains.  (This because we have
these systems here at Loughborough)

CPXSYS.ASM is largely unmodfied from CP4SYS.ASM.   Systems now in families
have their code duplicated in the relavent family file. CPXSYS.ASM  LINKs  to
the family file  if  appropriate.   In  due course,  I  hope to split off more
systems into "families" either on  their own,  or grouped  with other similar
systems.   I  know this is a half way step to true independent code for each
system, but  some systems are so close to others that I think it best  to group
them this way.

All VDU and terminal information is now held in CPXVDU.ASM.  This is really the
last section in the older CP4SYS.ASM file.

A quick "schematic" of what happens at assembly time...

        LASM CPXTYP... this then assembles the following:

        CPXTYP
          |
          v
        CPSDEF
          |
          v
        CPXLNK
          |
          v          (CPXSYS acts as a sorter for FAMILY switching)
        CPXSYS-------+----------+-----------+-----------+----
          |          |          |           |           |
          v          v          v           v           v
        (rest  of  CPXTOR     CPXAPP      CPXNOR       CPX???  one of
        CPXSYS)      |          |           |           |      several
          |          |          |           |           |      Families
          +<---------+----------+-----------+-----------+----
          |
          v
        CPXVDU
          |
        <END of assembly>

Users  should  be  aware  of  the  change  both  to  the  linking information
and start of the overlay address.   There are two new entries in the table,
family (offset 6) and lptstat (offset 20h). The  former is a two byte pointer
to a text string for  a  FAMILY (or  null  if not used) and the latter a JMP to
a routine  giving the status of the printer.   This can be done through  BIOS,
but not  through BDOS.   Users with odd sorts of printers may need to add their
own code here.

There  have  also  been some bugs fixed in  some  of  the  system dependent
code, so you would be wise pulling all the source files across.

The overlay address is now 5000h, and will probably change before this
revision  is complete.   The speeding up of  multiple  file handling takes its
toll on memory,  as there are now 64-ish  FCBs buffered.  This speeds up the
DIRECTORY command no end.

With  the overlay address at 5000h there is still a lot of  space free for more
things to be added (about 800h bytes).

Things yet to be done - lots!

There have been moves trying to add other independent modules for other
terminal  emulators  other than  the  VT52.   Demands  for SERVER,  REMOTE
HOST...,  file compression, better TRANSMIT, % of file  sent  and/or Kbyets
sent/received as part  of  the  display diring  transfers,  a lot of cosmetic
tidying up as well as  even more systems to be added.   CP/M-80 is a slowly
dying DOS,  and I feel  inclined to leave some bits out,  like SERVER (how many
use really  large  winchesters  in CP/M-80  systems,  and  want  true
servers?).    Does  anyone  have  a  burning  desire  for   these facilities?
And if so, will YOU be willing to take on the job of implementing them?

        Bertil Schou.

[Ed. - Above you see the future of CP/M-80 Kermit -- comments and
suggestions will be relayed to Bertil -- get them in soon, before it's
too late.]

------------------------------

Date: 14 SEP 86 18:44-MDT
From: JRD@USU
Subject: Comment on MS-DOS Kermit vs Graphics Screen Display
Keywords: MS-DOS Kermit

        In the Kermit Digest V5 #7 Kenneth Van Camp, kvancamp@ardec, said
that his new display board was causing MS Kermit 2.29 (but not Crosstalk) to
drop characters arriving from the serial port.

        The critical things here are: does the display board turn off
interrupts during screen scrolling, does it use the standard color card
display memory address (B800H, vs B000H for the monochrome card), does it
use interrupt request lines reserved for the serial port, and might its Bios
(if any) intercept the normal Int 10h video interrupt to implement things
its own way? An answer of Yes indicates slower processing of screen data.
The slowest screen operation on my EGA equipped system is scrolling (runs
about 16 millisec per text line), and scrolling can be caused by receipt of
a line feed (rather than a carriage return). Loss of characters indicates
the serial port interrupt could not be serviced before another character
arrived at the port. Common delaying items include print spoolers, screen
savers, and many other items, all of which tie on to the system clock tic
interrupt and block interrupts for extended periods. If the display adapter
also keeps interrupts off for milliseconds then things will get lost.

        When the screen is scrolled Kermit has a lot of work to do. Before
scrolling it copies the top (or bottom, as appropriate to the scroll
direction) line to an internal buffer, asks the Bios to do its slow screen
scroll, and then if need be writes a new bottom (top) line from a buffer to
the screen.  MS Kermit 2.29a has a speedier algorithm for all of this; but
still, the limiting factor is the Bios. If the display adapter were to turn
off interrupts during its Bios scroll operation then that's that.

        The MS Kermit command Set Term Color 10 forces a fast screen update
which may aid Kenneth; it causes snow on IBM CGAs.

        Regards,
        Joe D.

------------------------------

Date: TUE, 26 AUG 86 17:10:04 GMT
From: C20228 @ UK.AC.PLYM.B
Subject: Problems with Atari ST Kermit
Keywords: Atari ST Kermit

I have an ATARI 1040 ST with an ATARI C development kit. The kit has a
version of Kermit based on the old VMS/UNIX Kermit. This works but is not
really suitable for the uninitiated ATARI user (ie 1st Year Students). I
therefore set out to implement Bernhard Nebels GEM KERMIT 1.02 which you
have on file store at Lancaster.

1) Use VMS kermit to download the UUENCODED HEX files from LANC, get DECODE
program in C to decode above file. Compile DECODE program and feed it the
UUENCODED HEX files, results in KERMIT.PRG and KERMIT.RSC files now on disk.
Execute KERMIT.PRG it doesn't work !!! ATARI turns up its toes and displays
usual two bombs, then returns to desktop.

2) OK back to LANC file store, new message in 00BULL.TXT there is a new
version of the DECODE program in assembler, to correct missing spaces
problem. Right download it, and another copy of UUENCODED HEX file for good
mesure. Assemble DECODE program OK, now run it and feed it UUENCODED HEX
files, results in KERMIT.PRG etc etc.... execute Kermit ATARI experiences
fatal error, usual two bombs displayed, program returns to desktop.

3) OK now I'm really mad, back to LANC filestore. Transfer whole of ATARI C
source code (didn't really want to do it this way, but!). Write BATCH file
to compile all C source modules, link modules, KERMIT.PRG now appears on the
disk. Execute KERMIT.PRG ATARI treats us to a wonderful display of random
graphics and dither patterns, stand admiring random graphics for a while
before remembering that we are supposed to be running KERMIT. Try to regain
control of ATARI, to no avail, even reset leaves the machine with a duff
hard disk driver, finally resort to powering down and re-booting. Repeat
above three procedures on and off for about a week. finally give up in
disgust!!!!!

CAN ANYBODY HELP!!

Chris Rose
Micro-Support
Plymouth Polytechnic.

[Ed. - This is a good example of the paradox of Kermit -- you can't get
it unless you already have it...  Has anybody succeeded in making this
work?  Maybe a .boo file would be better than a UUENCODE file -- at least
.boo files don't have trailing blanks, and there's a .BOO-file decoder
written in C (KER:MSBPCT.C on CU20B).  It would also be most helpful if
someone could volunteer to ask as a provider of Atari ST Kermit diskettes,
or to induce an Atari user group to do it.  If this happens, please tell
us, so we can refer people who ask us.]

------------------------------

Date: Sat, 23 Aug 86 09:31:28 pdt
From: gould9![e-mail] (Joel West)
Subject: Problems with MacKermit 0.8(34)
Keywords: Mac Kermit

I've been using MacKermit for 1.5 years now and am very pleased overall.  I
use it every day even though I own two commercial (MacTerminal and
Microphone) programs which sit unused.  But... (You knew this was coming)

I'm having trouble with my MacPlus:
    1) The Receive dialog box is not compatible with HFS and
       looks quite bizarre.
    2) I was unable to map keys on the Plus to other values.
       (Has anyone else tried this?) My previous mappings
       from my 512 days work fine, though.

[Ed. - All of our Macintosh programmers disappeared after 0.8(33).
The current version, 0.8(34), consists mostly of VT102 emulation
improvements by Davide Cervone of the U of Rochester.  No work has been
done to accommodate the Mac Plus.  It has been suggested that the resource
file can be edited to make the Receive-file box look right for the Mac+, by
making it the same size as the Send-file box.  The keypad stuff mostly works
fine with the Mac+ (at least on ours), provided you start with the VT100
Keypad startup file that's supplied on our distribution diskette, and on
CU20B as KER:CKMVT1.HQX (and .DOC).]

Also, a lingering nit-pick from day one:
  When starting a new file, the transaction dialog box should
  pull down the "Transferred OK" message from the previous
  file, as it is confusing to tell whether the msg is left from
  the previous file or is a status on the current file.

If there are any lingering key problems on the European macs or the Plus, I
would recommend the article "Be a Keyboard Sleuth" (by Joel West) in the
August 1986 MacTutor.  I can supply a paper copy to anyone who's interested
in doing further work on MacKermit or K-Config.

    Joel West                 MCI Mail: 282-8879

[Ed. - Mac Kermit does indeed need work.  The major thing that needs to
be done to it is translation to a native Macintosh C compiler, so that
a VAX or other Unix system with the SUMACC tools is not required to
modify the program.  Several people have expressed an interest in doing
this, but I don't think anyone has really started.  Also, there doesn't
seem to be any concensus as to the best C compiler for the job.
Suggestions welcome, volunteers even more welcome!]

------------------------------

End of Info-Kermit Digest
*************************
-------
19-Sep-86 17:39:59-EDT,21262;000000000000
Mail-From: SY.CHRISTINE created at 19-Sep-86 17:39:03
Date: Fri 19 Sep 86 17:39:03-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #10
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 19 Sep 1986       Volume 5 : Number 10

Today's Topics:

        Alternate BITNET Kermit Distribution at University of Toledo
                      Os9 Kermit from os9 Users Group
                Using C-Kermit on VAX/VMS for Mail Spooling
                MS-DOS Kermit with Different Character Sets
                   More on Wanted: Kermit for the Apple][
                      Help with Installing VMS Kermit
                        VAX to PC Binary File XFERS
                     MVS/TSO and Apple II Kermit Gluts
                       Problems with Atari ST Kermit
                    Uuencoded Files and Trailing Blanks

----------------------------------------------------------------------

Date: Fri 19 Sep 86 14:31:37-EDT
From: Frank da Cruz <[e-mail]>
Subject: Alternate BITNET Kermit Distribution at University of Toledo
Keywords: BITnet

The collection of Kermit files at the University of Toledo VAX-11/785
is now being updated on a weekly basis.  BITNET sites that have trouble
getting a response from CUVMA (due to congestion) are welcome to try
KERMSRV at UOFT02.  To get started with KERMSRV (at either CUVMA or
UOFT02) give the command:

SMSG RSCS MSG xxxxx KERMSRV HELP (from CMS)
  or
SEND KERMSRV@xxxxx KERMSRV HELP  (from VAX/VMS with Jnet)

where "xxxxx" is either CUVMA or UOF02.  Thanks to Brian and to the
U of Toledo Computing services for helping to ease BITnet congestion.

------------------------------

Date: Fri 19 Sep 86 05:52:04-PDT
From: Bob Larson <[e-mail]>
Subject: Os9 Kermit from Os9 Users Group
Keywords: Os9 Kermit

Os9 kermit is available from the Os9 users group as disk 48.  (The latest
disk listing I have from them has this mislabeled as 68k only and lists disk
37 as the 6809 version.  The version on disk 37 has quite a few bugs that
are fixed in the version on disk 48.)  Since several things are determined
at compile time, it's a good idea to have the C compiler available even if
they claim to supply a compiled version.

Membership in the Os9 users group is $25/year and includes disk 0 and MOTD
their monthly newsletter.  Send Name, address, computer type, os9 type and
level, and disk format to:

The Os9 Users Group
Attn: Membership
9743 University Ave.
Suite 330
Des Moines, IA 50322

Disk orders from members should be sent to the same address, Attn: Disk
order.  Disks are $5 for 5", $8 for 8", $80 for the works on 5" 80 track
DSDD standard os9.  Disk orders are accepted from members only.

[Ed. - Thanks for the information.  This Users Group has been added to our
KER:AADISK.HLP file, with the terms outlined.]

------------------------------

Date: Tue, 16 Sep 86 09:44:36 pdt
From: varian![e-mail]
Subject: Using C-Kermit on VAX/VMS for Mail Spooling
Keywords: C-Kermit, VAX/VMS Kermit, Scripts

We use C Kermit (058) under VMS here.  I wrote some scripts that run kermit
unattended in order to send mail from UNIX to VMS.

[Ed. - Thanks for the scripts!  Since they are rather long, we've put them in
the Kermit distribution as CKVKER.SCR.]

------------------------------

Date: Wed, 13 Aug 86 16:40 N
From: Kimmo Laaksonen <[e-mail]>
Subject: MS-DOS Kermit with Different Character Sets
Keywords: MS-DOS Kermit, Character Sets

The internal translation feature allows MS DOS Kermit user to change
external character codes to MS DOS internal codes within Kermit, and vice
versa. This feature is mainly intended for text display and file transfer in
non-English speaking countries, where "national" characters in a remote host
are assigned to codes that have another graphics representation in a
"standard", ie.  Anglo-American, character set (some "standard" graphics are
replaced with national grahics - in terminals, line printers, etc.). In a PC
there is an extended character set, where both "standard" and "national"
characters can be intermixed in text files. The internal translation
supports full 8 bits, so it can be used to map different 8 bit character
sets to each other, too, like the DEC set (eg. in VT200 series) to the IBM
PC set and vice versa.

Without translation a text file prepared on the remote host will look
strange because the PC will display the "standard" graphics instead of the
national graphics, when the file is typed on PC screen via Kermit terminal
emulator, or when it is transferred to PC as a file with Kermit and then
looked upon with a text editor in PC.  Respectively a text file prepared in
a PC and transferred with Kermit to a remote host looks strange because
different codes are used to represent national characters in remote host
output devices.

MS DOS Kermit internal translation is an elegant solution to this situation.
There certainly exist separate programs to do the necessary code
conversions. One problem with them is that at least twice the file space is
required, which may turn out to be impossible in a PC if the file is large.
Another problem is the extra time required for running a separate conversion
program.  Translation overhead within MS DOS Kermit is negligible.

Translation does NOT affect the Kermit protocol, ie. translation  is
done  outside  Kermit  packet assembly/disassembly. The new commands
for translation are:

 SET XLATION object [parameter(s)]

The following objects are available:

 ALL       Affects all translations. Valid parameter values  are  ON
           or OFF. ON is the default !

 DISPLAY   Controls translation of characters received DURING Kermit
           terminal  emulation, ie. what is displayed on the screen.
           Does not (should not?) affect terminal controls, eg.  ESC
           sequences.

 PRINT     Controls translation of characters received and output to
           printer DURING Kermit terminal emulation.

 SEND      Controls translation when transferring files FROM the PC.

 RECEIVE   Controls translations when transferring files TO the PC.

Parameters:

 OFF       Turns translation OFF for the selected object. Respective
           translations  must  be  OFF  to properly SEND and RECEIVE
           binary files, eg. .EXE, .COM, etc.

 ON        Turns CURRENT translations on for  the  selected  object.
           The   Finnish   convention   is   the  default  for   all
           translations (guess why).

 INITIAL   Resets a translation table to an identity table  ie.  all
           possible 8 bit codes are translated to them selves. It is
           good practice to initialize a  translation  table  before
           starting to build a new translation.

 EXPAND    Copies the lower half, ie. first 128 translations, to the
           upper  half  of the selected translation table. This is a
           useful feature when only the 7 lower bits (as  in  ASCII)
           are meaningful and the 8th bit (ASCII parity) is a "don't
           care".

 CODE base nnn base nnn

           This parameter is  used  to  actually  set  up  a  SINGLE
           translation  in  the selected object's translation table.
           The first pair (base  nnn)  is  the  original  code.  The
           second  pair is the code to which it is to be translated.
           Base can be any of DEC (decimal), HEX  (hexadecimal),  or
           OCT  (octal).  The  actual  code (nnn) is a number in the
           selected base.

In addition there is a new command for terminal emulation:

 SET EIGHBIT value

It controls whether MS Kermit strips the 8th (normally  parity)  bit
(value  =  OFF,  the default) during terminal emulation, or if all 8
bits are used (ON). Passing all 8 bits is  useful  when  2  PCs  are
connected  together,  or when connected to a DEC VAX VMS set to pass
all 8 bits. Note that the DISPLAY and PRINT translations are applied
(if ON) AFTER the 8th bit is stripped off or passed on as it is.

Some notes:

The MS DOS Kermit translation is not intended for a lay operator. It
would  be best if somebody at a site prepared command file(s) to set
up (and enable) the required translations. It is usually too tedious
to give a note listing the necessary Kermit commands that a user has
to  type  in,  although  it's  possible.   TAKE,   or   even   using
MSKERMIT.INI,  is much easier. Anyway, since we didn't touch the SET
KEY  facility,  it  is  customary  to  include   tailored   keyboard
"translation"  command  files in local Kermit distribution floppies,
so adding a few new files (or including  them  in  SET  KEY  command
files) for the translations suits that custom well.

Some may think that the ability to define only a single  translation
for a single object at a time is too slow, but usually there are not
so many of them, well under 10 for the Finnish  character  set,  for
example. Even mapping a full 8 bit set to another, eg. DEC character
set to IBM PC, and vice versa, doesn't require  modification  of all
256  codes.  And when the translations are set up, they are normally
loaded from a file, which doesn't take long.

We have translation files for the Finnish language and  IBM  PC  (of
course!),  including  SET  KEYs,  which  we can send to Columbia for
redistribution. However, we think it's better  to  postpone  sending
anything  yet,  because  our additions to MS Kermit were done on the
2.27 version! We think it's better to wait until we have added  them
to  2.29.  After  that  we  hope that translation becomes a standard
feature in MS Kermit to keep all us non-AngloAmericans happy.

If you REALLY want something fast, send queries to:

  [e-mail], or
  [e-mail]

(We are connected to EARN/BITNET, only.)

[Ed. - Sounds like you've really attacked the problem head-on.  Still,
it's going to be tough to make everybody happy.  On the one hand you've
got all the different character sets -- Finnish, Swedish, German, Spanish,
etc. -- and on the other you've got all the different hardware -- the IBM
character ROM, the DEC version (with its multifarious "country kits"),
presence or absence of all different, incompatible graphics boards, etc.
I can visualize having dozens, maybe hundreds, of character-set files to
adapt each alphabet to each kind of hardware.  And then we have to deal
with people's personal preferences about which key should transmit which
code...  But still, this sort of thing is badly needed in the
non-Anglo-American world.  What do people think?  Kimmo, maybe when you
get your hands on 2.29a (when it's finally released) you can try installing
your translation code, keeping these questions in mind.  Like, maybe there's
a way to combine many mappings into one compact file...]

------------------------------

Date: 4 Sep 86 02:37:48 GMT
From: umcp-cs!cvl!umd5![e-mail] (Ben Cranston)
Subject: More on Wanted: Kermit for the Apple][
Keywords: Apple II Kermit, Uppercase Terminals

Some people suggested that although they have other means of transfering
stuff from their Unix machines to their Apples I should post Kermit
anyway.  So I sat down and started to upload the source.  I didn't get
very far.  The Apple ][ that I use doesn't have lower case.  Unix is
not very friendly to upper-case-only terminals that try to use Kermit.
(To try it yourself, next time you sign on, type your userid in upper
case.)

[Ed. - What Kermit are you using on Unix?  C-Kermit handles the
uppercase environment just fine, at least on 4.2BSD -- uppercase
filenames map to lowercase, etc, and since during file transfer the
line is open in rawmode, the Unix terminal driver's uppercasing does
not interfere with the packets.]

I got it uploaded to the Sperrysaur which is a case insensitive
machine.  Unfortunately it doesn't like lines longer than 132
characters so I'm gonna hafta do moby "join" commands when I get it
FTPed up here.

But this exposes a pathological problem.  It probably works if you
have the lower case stuff, but what should the response of Kermit be
to an unmodified Apple?  Should there be a force-to-lower-case option?
Suggestions?

Oh, the other feature this Kermit has is a 70 column display-to-hires
option.  It doesn't make it on a color TV, but it's barely tolerable
on my B/W set.  On a video monitor it should be better...

                    umd5.UUCP    <= {seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben
Ben Cranston zben @ umd2.UMD.EDU    Kingdom of Merryland Sperrows 1100/92
                    umd2.BITNET     "via HASP with RSCS"

------------------------------

Date: 9-SEP-1986 10:17:43
From: [e-mail]
Subject:  Help with Installing VMS Kermit
Keywords: VAX/VMS Kermit

  We've had some discussions in the UK newsletter lately with people having
trouble installing VMS Kermit and its help files on VMS. A couple of people
have contributed some ideas and command procedures to help the non-VMS
expert: I have them online here as VMSINS.HLP

        Alan

[Ed. - Thanks!  This file is in KER:VMSINS.HLP on CU20B.]

------------------------------

Date: 16-Sep-1986 0539
From: [e-mail]  (Cathy Fulton -- CXO Technical Training)
Subject: VAX to PC Binary File XFERS
Keywords: VAX/VMS Kermit

In response to the recent messages about transferring VMS binary files
with Kermit...

I xfer VMS binary files to and from a PC all the time using Kermit.  Well,
they're not really binaries, but hexified forms of binaries.

There are two programs, VMSHEX.MAR and VMSDEH.MAR, which are used to hexify
and dehexify any VMS binary.  You first hexify the file with VMSHEX and then
Kermit it to the destination.  The hexified file is a normal ASCII file, so
SET FILE TYPE TEXT.  Upon Kermiting the file back to a VMS system, run VMSDEH
on it to restore the file to its original state.

- Cathy

[Ed. - Preprocessing is always a way around this kind of thing.  VMSHEX &
VMSDEH not only hexify & dehexify the file, but preserve & restore the
FILES-11 stuff.  If you're going from VAX to VAX, you can also use Kermit
to send BACKUP save sets back & forth.  Still, it should be possible to
transfer fixed 512-byte-block binaries with Kermit-32, at least that's
what it says in the documentation.  Maybe this could be a hot topic at
the DECUS Kermit session.]

------------------------------

Date: Tue, 16 Sep 86 21:19 EST
From: [e-mail]
Subject: MVS/TSO and Apple II Kermit Gluts
Keywords: MVS/TSO Kermit, Apple II Kermit

We have been using a very nice MVS/TSO version of Kermit written in
assembler by Steve Blankenship of TUCC.  He has modeled this after CMS
Kermit, and it the nicest, most powerful version we have run across for an
MVS/TSO site.  It supports communications both through 3705/3725 front ends
and Series 1/7171 front ends and includes a server mode, initialization and
take files, optional log files, tab expansion, etc., etc.

Steve and Roger [Fajman] (of NIH) have been put in contact with the hope
that the two versions and the two authors could hash things out to come up
with a definitive MVS/TSO standard version.  Let's hope for the best.

[Ed. - Indeed they are in contact, and there will be at least one or two
releases soon, and there's a good chance that one or more of these will
be consolidated with CMS Kermit at some time thereafer.]

As for Apple II Kermits, both Ted Medin and Dick Atlee have been working on
very nice 80-column versions.  Ted's runs under DOS 3.3 and ProDOS and is
just about complete (although some distribution has already started on some
Apple II mailing lists).  From what I have seen of the source, it is being
done with the CROSS assembler.  Dick's version, as far as I know, is only
DOS 3.3, although it is done in Big Mac assembler - an advantage.  He has
been very busy lately, and I don't know how he is coming with it.  Both
myself and two other people I know of have been trying to work with Dick for
ProDOS versions of his work.

Again, in this case it would be very nice to consolidate all of this work to
one, nice version - although the release of the Apple //GS will probably
make that two versions now.

[Ed. - Ted's version has been received at Columbia, where Peter Trei,
the other Apple II Kermit person, has been trying to merge it with his
own latest version.  How this will stack up against -- or eventually be
consolidated with Dick's version remains to be seen.]

A major problem with versions for machines such as the Apple is the
non-communication with Columbia on distribution and availability.  If Apple
II users could follow the example (I hate to say this) of MS-DOS users, the
whole group would benefit.  Take version 2.29A of MS-Kermit as a solid
example of what can happen when people cooperate to produce one, good piece
of software.

Sorry for the verbosity, but this is a subject about which I feel very
strongly, and thus far my efforts to persuade people to work with and
through Columbia for their own sakes and for the sake of the best Kermit
versions possible have been met with much adversity (in the micro world).
Any suggestions on this topic would be appreciated.

Thanks for letting me blow off some steam.

Mark

[Ed. - Yes, people should consult with Columbia before starting work on
a Kermit program to avoid this kind of duplication of effort, not to mention
filename conflicts and other lesser headaches.  However, even when they do,
sometimes things fall through the cracks.  Anyway, we try to keep a record
of everybody who's working on everything in the file KER:AAWAIT.HLP, and
everyone who's interested in forthcoming versions is welcome to take a look
at it.]

------------------------------

Date: 19 Sep 86 09:26:06 EDT (Fri)
From: Michael Fischer <[e-mail]>
Subject: Re: Problems Installing Atari ST Kermit
Keywords: Atari ST Kermit

I had problems installing GEM Kermit, too, but I finally got it to work.
Here in a nutshell are what the problems were:

1.  The UUDECODE program distributed with Kermit (astuud.c) is written
for the Lattice C compiler.  To use it with the Alcyon C compiler distributed
with the Atari Developer's Kit, it is necessary to open the binary output
file with "fopenb" instead of "fopen"; otherwise, the file is opened in
text mode (ignoring the "b" mode flag") and every ^J in the output has a
gratis ^M inserted after it.

2.  Recompiling the sources as Chris Rose did is not sufficient, for
the resource files are *only* distributed in binary form.  A correct
program given a bad resource will crash, just as an incorrect program
will.  Thus, one has no choice but to get UUDECODE to work.

3.  Once I fixed UUDECODE, I successfully decoded both the Kermit
program and resource files and they worked without problem.  I also
rebuilt the program from the sources and it also worked with the
decoded resource file.

4.  There has been a great deal of activity lately on the INFO-ATARI16
bboard discussing the various problems people have been having with
UU-encoded files.  There seem to have been two or three independent sets
of problems:
(a)  Bugs in the UUDECODE program to run on the ST as described above.
(b)  Problems with the encoded file being modified during transmission
such as tab expansion, truncation of trailing blanks, or padding of
all lines to a given length.
(c)  For people who tried decoding on a mainframe and then transmitting
the binary files to the ST (often using the old Developer's kit Kermit),
forgetting to set binary mode on both the transmitting and receiving
Kermit.  After numerous reports of failures and then people bringing
these problems out in the open, success stories such as mine above
began pouring in.  So UU-encoded files *are* usable, but it can be
rather tricky to do it right.

I will contact the "New Haven ST's" user group to see if they would
be willing to copy GEM Kermit onto disks for people.

  Mike Fischer
  <[e-mail]>

[Ed. - See next message for another hint.]

------------------------------

Date: Sat, 13 Sep 1986  12:40 MDT
From: [e-mail]
Subject: Uuencoded Files and Trailing Blanks
Keywords: Uuencoded Files

I made a small experimental change to our version of uuencode to solve
the truncated trailing blank problem and it turns out to be
transparent to uudecode.  That change is simply to insert a "M" to
each uuencoded line just prior to the insertion of the CRLF.  BITNET
users accessing our system through our mail file server have voiced no
complaints since I made that minor change.

--Frank

------------------------------

End of Info-Kermit Digest
*************************
-------
25-Sep-86 18:11:13-EDT,17282;000000000000
Mail-From: SY.CHRISTINE created at 25-Sep-86 18:09:44
Date: Thu 25 Sep 86 18:09:44-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #11
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 25 Sep 1986       Volume 5 : Number 11

Today's Topics:

      New Release of QK-KERMIT (MsDos and CP/M Kermit in Turbo Pascal)
                       New Release 1.6 of KERMIT/TSO
                              Motorola Kermit
              New IBM and Rainbow .BOO Files for MS-DOS 2.29a
                        MS-DOS Kermit 2.29 Question
                       VMS File Attributes and KERMIT
                             Timing out on CMS
                      Re: Kermit BOO for HP Integral?
                       UNIX SYS/V Version of Kermit?
             UUCP and Kermit Server at Okstate returns to life
                              Kermit for C128?

----------------------------------------------------------------------

Date: Mon, 22 Sep 86 16:27 EDT
From: VIC@QUCDN
Subject: New Release of QK-KERMIT (MsDos and CP/M Kermit in Turbo Pascal)
Keywords: QK Kermit, Turbo Pascal

I am sending you version 2.6 of QK-KERMIT (an MsDos and CP/M Kermit program
written in Turbo Pascsal.)
In addition to the new Pascal source, I have sent the following files:
     1. hex file for MsDos (IBMPC) kermit with VT100 emulation.
     2. hex file with overlay file for a kermit with VT100/TEK4010 emulation.
     3. hex file for a KayproII kermit.
     4. updated installation documentation
     5. updated user documentation.
Both the MsDos versions will also contain code to handle the APL character
set.  You should replace the old files with the new files. The old files
which I didn't send are the same for the new version.  There is also a new
QKKER.SCR (Script source for the documentation) will also be sent.

[Ed. - Thanks, Vic.  The new files have been installed in KER:QK*.* on CU20B,
and in BITNET KERMSRV on CUVMA as QK* *.]

------------------------------

Date: 23 Sep 86  14:15 CET
From: Fritz Buetikofer <[e-mail]>
Subject: New Release 1.6 of KERMIT/TSO

Since May 86 some bugs in the version 1.4 have appeared.  And furthermore
some new commands have been implemented:

 * Bugs fixed and error handling improved in the routine which checks
   for the presence of a file (Check_Dsn).
 * New command TAKE to execute KERMIT-commands from within a file.
 * When displaying STATUS screen, you will find a notice, whether
   the INIT-file (KERMIT.SETUP) has been found or not.
 * New command SET ATOE/ETOA to modify the ASCII <-> EBCDIC translation
   tables, while running KERMIT.
 * New command SET INCOMPLETE, to specify what has to be done with a
   file when user aborts the transfer.
 * Update of SEND command, so that the user may specify a filename,
   which is sent to the micro (instead of generating one automatically).

Only the Pascal source file and the documentation were changed.  For the
very near future, I'm going to implement a STATISTICS command, handling of
attribute packets and (maybe) long packets.

Regards to all TSO freaks, F.Buetikofer, University of Bern (Switzerland)

[Ed. - Thanks, Fritz!  The new files are installed as KER:TS2KER.PAS and
KER:TS2KER.DOC, replacing the old version, on CU20B for anonymous Internet
FTP, and TS2KER PAS and TS2KER DOC on CUVMA for BITNET KERMSRV access.  This
version of MVS/TSO Kermit works only on linemode (3705-style) connections,
but it has many more features than the original TSO version.  Meanwhile,
watch Info-Kermit for announcements of at least two other new TSO Kermits on
the way, both with many advanced features, and both able to operate over
both linemode and Series/1-style connections.]

------------------------------

Date: 22 sep 86  17:07 GMT +0100
From: <RBG.XX@GEN>
Subject: Motorola Kermit
Keywords: Motorola Kermit, 68000

     After experimenting the high reliability of the Kermit file transfer
protocol, I promoted its utilization in my department.  Since we make a
heavy use of Motorola microprocessors I am writing a Kermit implementation
for 680xx processors based systems.

     The language used is assembly, and I think it may be processed by most
assemblers following the syntax defined by Motorola (I proved the 2500 A.D.
68000 cross assembler, the Motorola MC68000 cross assembler and the CERN
M68MIL cross macro assembler).  The key principle of this Kermit
implementation is machine independence (obviously stated that the processor
belongs to the 680xx family).  The system dependent part is composed by a
few routines, containing all the knowledge about the system's file structure
and I/O ports.  The program is thoroughly documented, thus allowing the
implementors to modify it easily, according to their need.

     This Kermit implementation has been written in order to be installed
also on those 680xx family based machines, which have no or not-standard
operating system, being often custom built for the solution of specific
processing problems.  At least in the high energy physics field, that
frequently happens.

     I think that the first version of the program will be ready in 1 or 2
months. If you are interested in it, I would be glad to send it to you, so
that you can distribute it.

                  Roberto Bagnara
                  Physics Department
                  Bologna University
                  via Irnerio, 46
                  40126 BOLOGNA
                  ITALY

                  DECnet address: 39948::MICRO
                  Bitnet address: [e-mail]

[Ed. - This will be announced when it is received.]

------------------------------

Date: 21 SEP 86 18:24-MDT
From: JRD@USU
Subject: New IBM and Rainbow .BOO Files for MS-DOS 2.29a
Keywords: MS-DOS Kermit

MSTIBM.BOO  and  MSTRB3.BOO are identified as MS Kermit 2.29 test 21 Sept 1986.

        The items of note are:

- new command to control width (7 or 8 bits) of characters displayed in
 non-file-transfer mode:
        Set Display  Regular | Serial | Quiet | 7-bit | 8-bit
 7-bit is the default width. Any two keywords above can be used together on
 the same command line. The Status display also shows the Regular etc type
 plus the 7-bit or 8-bit tag. 8-bit is ineffective if parity is other than
 None.

- Set Send Packet ### has been modified slightly to use this command to set
 the ultimate upper limit the size of outgoing packets. The default value
 is 1000. The Status screen still shows the active, negotiated, size. In
 practice this means MS Kermit will send packets of size "other end's
 requested size" or the Set Send Packet value, whichever is smaller; thus
 the user need not do anything to send long packets to an appropriate host.
 However, MS Kermit requests only standard 94 byte packets be sent to it
 unless the user specifically requests another length by giving the
 command Set Receive Packet ###. The limit of 1000 bytes is arbitrary and
 can be enlarged by changing the single parameter "maxpack" located in the
 header file and rebuilding; two lines of Help in mssset.asm should also be
 edited to match the readjusted maxpack value.

- Bug fixed: incompletely received files were not deleted when a transfer
 was prematurely terminated.

- Bug fixed: VT102 emulator did not always correctly position the cursor
 within a restricted scrolling region when the escape sequence
 ESC top; bottom r  was received.

        Regards,
        Joe D.

[Ed. - Thanks, Joe!  The new files replace the old ones as KER:MST*.BOO
(and KB:MST*.EXE) on CU20B and MST* * on CUVMA.  This should pretty much
complete the list of new functions for 2.29a; leaving only the tedium of
bringing all the other versions up to this level and testing them, and
then bringing the manual up to date...]

------------------------------

Date: Mon, 22 Sep 86 19:47 EDT
From: Michael G. Chan <seismo!mcnc!duke![e-mail]>
Subject: MS-DOS Kermit 2.29 Question
Keywords: MS-DOS Kermit

Is there any way to patch MSKermit to recognize the 43 lines mode of an EGA?
I can put the display in 43 lines mode but MSKermit always put the status
line on the 25th line when connected.

                        Thanks
                        Michael Chan
                        chan@duke

[Ed. - From JRD: There are no quick patches even though most of the code is
written for arbitrary sized screen. Some parts are specific about line
numbers (location of the status line, for example).  Also, my experience has
been that 43 line mode is such a hybrid (ega vs the rest of the Bios and
DOS) that it may not function well on machines having two display adapters;
I have such a situation. For a while I considered including more specific
ega mode support but quit when the quirks became too much. EGAs were
designed with most registers being write-only. Thus, the ega needs to be
managed; in turn, that is tough to do properly within an applications
program containing an inner program (terminal emulator).]

------------------------------

Date: 19 Sep 1986 2127-EDT
From: "Bernie AT&T:617-467-5664 LDP Workstations" <[e-mail]>
Subject: VMS File Attributes and KERMIT
Keywords: VMS Kermit

With a 'little bit' of trickery it's possible to send any file from VMS to
any other system and back to VMS.

Single files :
Use LZCOMP/LZDECOMP {base language C - an implementation of Lempel-Ziv-
        Welch compression} in {non-portable} VMS-specific mode.
        In this mode RMS-attributes are carried and reestablished
        at decompression. Use KERMIT to move the file.

Collection of files :
Use VMS BACKUP to generate a single 'Backup' save-set and then

        a. LZCOMP/LZDECOMP {see above}

or      b. VMSBAK.BAS {source language BASIC} to 'restructure' the blocking
           of the save-set to KERMIT's 512 bytes fixed records. Then
           use KERMIT to move and VMSBAK again to de-block back to original
           blocking {restriction - original blocking has to be multiple of
           512!!.

.. last {but not least}
single and multiple files

        Use Stevens Institute's VMSHEX and VMSDEH {source language MACRO} -
        and transmit the resultant 'hexified' files via KERMIT. This method
        (although the oldest) will generate the largest files for trans-
        mission via KERMIT and could therefore be the slowest one.

BTW 'standard' VMS executables can also be 'moved' by telling the
'receiving' KERMIT 'SET FILE TYPE FIXED'. However the above three 'choices'
will work in all cases - since LZCOMPRESS, BACKUP and VMSHEX all include RMS
file descriptors in the encoded file and reconstitute same.

[Ed. - Thanks, Bernie!  The VMSBAK.BAS program was already in the Kermit
distribution, and now the LZW-compression programs have also been added, as
KER:VMSLZ*.*; the file KER:VMSLZ.HLP explains the organization and contents
of the files.  The programs are written in C, and may be compiled under
VAX/VMS with VAX-11 C, on PDP-11s with DECUS C, or under Unix.  Thanks to
Martin Minow of DEC for adapting 'compress' to the DEC operating systems.]

------------------------------

Date: Mon 22 Sep 1986 16:26:54 CDT
From: Dan Theriault <DANNO@UIUCVMD>
Subject: Timing out on CMS
Keywords: CMS Kermit

Some of our users here type Kermit Receive on CMS and then realize too late
that they forgot their PC Kermit at home or whatever.  The result is that
they can't get out of Kermit so what they often end up doing is hanging up
their telephone and run disconnected on CMS for days.  They often wind up
using 80 percent of our CPU as Kermit searches and searches and searches for
an incoming file.  I've looked at the source to our Kermit and I found a
variable that claims to be the time-out counter for Receiving, but nothing
I've done causes it to work.

Any help?

Dan Theriault
University of Illinois at Urbana-Champaign

[Ed.- From John F. Chandler <[e-mail]> The normal method of
escaping from a Kermit protocol wait is to type a bunch of CR's at Kermit.
The number required will depend on the context: for the initial packet
exchange, the retry threshhold is 16, but after that the threshhold is
determined by the SET RETRY command (default 5).  There is no need to set
aside some special sequence of characters to abort a transfer "by hand"; all
it takes is the patience to type 16 carriage returns.]

------------------------------

Date: Fri, 19 Sep 86 11:33:29 cdt
From: seismo!uiucdcs!uxc.CSO.UIUC.EDU![e-mail] (Mark Zinzow)
Subject: Re: Kermit BOO for HP Integral?
Keywords: HP Integral Kermit

It seems the only boo files for Ckermit are for machines like the Amiga.
The HP does not come with a c compiler so having a boo file available from
kermsrv would be desirable.

[Ed. - Can anybody send in a Kermit .BOO file for this system?]

I was very happy when MSTIBM.BOO made it over the net.  Does anyone have an
application to run on an IBM mainframe using a 7171 or Series/1 type front
end, that utilizes the new print support for local printing of a mainframe
file (under VM/CMS) with kermit on the PC?

Mark S. Zinzow                        ARPA:  [e-mail]
Research Programmer                   BITNET: [e-mail]
Computing Services Office             UUCP: ihnp4!pyrchi!uiucuxc!zinzow
University of Illinois at Urbana-Champaign

------------------------------

Date: 15 Sep 86 20:25:20 GMT
From: [e-mail]
Subject: UNIX SYS/V Version of Kermit?
Keywords: UNIX Kermit

Does kermit now cooperate with uucp?  That is, does it know how to create
the uucp lockfiles for a device, so that uucp won't wake up and stomp on
kermit's toes?  Of course, if it doesn't, it would be easy enough to modify
kermit, if only we had the source.

[Ed. - Yes, C-Kermit includes code to "cooperate" with uucp.  BUT...  Every
version of Unix wants this to be done a different way, and every site tends
to change it again.  And then come the perennial questions: what is the name
of the lock directory?  what are the lock files called?  should the lock
directory be publicly writeable, or should Kermit be sutuid'd or setgid'd to
it?  Should the lock file be empty, or contain the pid of the process that
has line locked.  A quick look at ckutio.c (yes, the sources are widely
available, e.g. see next message) will show just some of the variations on
these themes, as will a perusal of many past issues of this digest...]

------------------------------

Date: Sun, 21 Sep 86 15:18:51 -0500
From: Mark Vasoll <[e-mail]>
Subject: UUCP and Kermit Server at Okstate returns to life
Keywords: Okstate, UUCP

The UUCP and Kermit Server services at the Oklahoma State University
Department of Computing and Information Sciences are back on the air again.
The information in the okstate.txt blurp still contains the correct access
information.

One side note though, since we reactivated the dial-in line on Sept 16th,
someone's system has been dialing us every 15 minutes, 24 hours a day and
using the uucpker login and password.  Since this type of thing is easily
automated and forgotten, and since the system in question doesn't get far
enough into the UUCP protocol to identify itself (so I could send the system
manager a mail message), I am making this public plea for everyone who even
*might* have something like this set up to go take a look before your phone
bill hits the mega buck level.

Thanks,

Mark Vasoll
Department of Computing and Information Sciences
Oklahoma State University
Internet:   [e-mail]
Obsolete:   [e-mail]
UUCP:  {cbosgd, ea, ihnp4, isucs1, pesnta, uokmax}!okstate!vasoll

------------------------------

Date: Fri, 19 Sep 86  20:47:40 EDT
From: [e-mail]
Subject: Kermit for C128?
Keywords: Commodore Kermit

Are there any plans for a version of KERMIT-65 for the COMMODORE 128 in 128
mode?  I have all kinds of problems with the COMMODORE 64 version, and it
would be very convenient, I think, for all COMMODORE 128 users to have a
128-mode version.  An ideal program would be one similar to the other
kermits, but one that redefined the 128 character set for special unix-type
characters (backslash, curly braces, tilde, etc.), worked in 80-COLUMN mode,
emulated a VT-52, and could take advantage of the 8502 microprocessor's
2-MHZ speed, at least during actual file transfers, and prefereably always
when in 80-column mode.  If anyone has plans for this, I would be happy to
help out.  I don't know 6502 assembly language, but I do know BASIC, Pascal
and C quite well.  If anyone knows of any plans for a 128 version, please
let me know!  Thanks!

Matt Kimmel,
[e-mail]   <BITNET>
[e-mail]  <ARPANET>

------------------------------

End of Info-Kermit Digest
*************************
-------
 6-Oct-86 17:34:20-EDT,18576;000000000000
Mail-From: SY.CHRISTINE created at  6-Oct-86 17:32:22
Date: Mon 6 Oct 86 17:32:22-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #12
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Mon, 6 Oct 1986       Volume 5 : Number 12

Today's Topics:

                     New Release of Kermit-11 Available
                          Another 2.29a Prerelease
                   Atari ST Kermit on Diskette in the UK
                           BOO files vs UUENCODE
                         Suggestions for MS-Kermit
                  Screen Saver Feature as part of Kermit.
                             MS-Kermit on 80386
                            Found on net.bizarre

----------------------------------------------------------------------

Date: Fri 26 Sep 86 15:31:53-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Release of Kermit-11 Available
Keywords: Kermit-11, K-11, PDP-11 Kermit

This is to announce Version 3.54 of Kermit-11 for PDP-11s or Pro-3xx's
running the various DEC operating systems (RSX, RSTS, RT, P/OS, etc) or
TSX+, from Brian Nelson at the University of Toledo ([e-mail]).
New features since the last release, 3.50 (April 1986), include:

. Command line editing and recall controlled by arrow keys.   ";" and "!"
  may be used to delimit comments.

. Handling of DEC multinational 8-bit ASCII text files.

. New SET FILE NAMING options.

. New SET SEND [NO]XON command, to prefix every packet with an XON to fight
  pathological problems with flow control.

. Minor bug fixes and cleanups.

. Some RT11/TSX+ specific modifications:

  Reduction in the size of the root for XM to facilitate running Kermit as a
  foreground task.

  Complete rewrite of terminal emulation, specifically to enhance the
  support of the XL/XC/CL handlers. It is now completely event driven
  thus performance should be improved as well as presenting a much lower
  load on the CPU. It should also function better under SJ.

  Restructuring buffer allocation to (1) Reduce the root size for XM, and (2)
  To enable the USR to swap over buffers for SJ and FB. This will eliminate
  Kermit crashing on USR requests in 95% of the cases for SJ and FB systems
  with minimal background memory available (ie, many devices in the system
  and/or large RMON).

  Control C delivery has been improved by adding a watchdog timer to check for
  control C's as RT11 does not generate an AST on control C.

The new files are available via anonymous as KER:K11*.* on CU20B and over
BITNET via KERMSRV at both CUVMA and UOFT02.  The file K11INS.DOC contains
installation instructions, K11AAA.AAA is a read-me file, and K11FIL.DOC is a
(slightly dated) annotated list of the Kermit-11 files (of which there are
about 111, totalling about 3.8 megabytes in size).  The file K11CMD.MAC
contains the detailed update history.

------------------------------

Date: Thu 2 Oct 86 10:10:32-EDT
From: Frank da Cruz <[e-mail]>
Subject: Another 2.29a Prerelease
Keywords: MS-DOS Kermit

A new copy of MSTIBM.BOO is available for testing.  This one fixes a bug
with VT100/102 emulation when rubout (DEL) characters are received -- some
screen editors send these as padding, and they were erroneously causing
characters to disappear from the screen during editing.  Also, display of
login script text in 8-bit ASCII even when parity is in use or display is
set to 7 bits no longer occurs.  The new files are in KER:MSTIBM.BOO and
KB:MSTIBM.EXE on CU20B for anonymous FTP, or in MSTIBM BOO on CUVMA for
BITNET KERMSRV access.  Thanks to Walter Bourne of Columbia for pointing
out the problems, and to Joe Doupnik for fixing them.  The final release
of 2.29a should be ready in a week or two.

------------------------------

Date: 29-SEP-1986 15:06:20
From: [e-mail]
Subject: Atari ST Kermit on Diskette in the UK
Keywords: Atari ST Kermit

A colleague in our Environmental Sciences Department with an Atari 1040ST has
kindly volunteered to do some disc copying, so we're now able to supply the
ST files on Atari format discs. Anyone interested should contact us on
(0524) 65201 x 4881, or to [e-mail]1 on JANET.

I'm afraid this offer is to users in the UK and Eire only: we can't return
calls or answer letters from other countries.

------------------------------

Date: Mon 29 Sep 86 11:57:26-EDT
From: Frank da Cruz <[e-mail]>
Subject: BOO files vs UUENCODE
Keywords: .BOO files, UUENCODE

[Ed. - The following message is in response to a question from Keith
Petersen about whether BOO file format should be added to the the formats
supported by the SIMTEL20 archive file server.]

The main advantage of BOO files over UUENCODE files (except when Frank W's
trick of putting a printable character on the end of each UUENCODEd line is
applied) is that BOO files don't have blanks in them, so they don't get
truncated by mailers, BITNET file transfer, etc.  Also, BOO files don't have
dots, which can cause problems when going through SMTP processes when the dot
occurs in "column 1".  Also, BOO files tend to be a little more compact; both
BOO and UUENCODE use 4-for-3 packing, but BOO files also run-length encode
strings of nulls.  As Keith points out, neither encoding includes error
checking; BOO files avoided that because of ASCII/EBCDIC considerations.

Both BOO and UUENCODE encodings have a distinct advantage over LZW, Huffman,
and other more efficient, but complicated, techniques: the decoding program is
short enough to be typed in and used by the average PC owner.

The BOO-file maker is written in C; BOO-file decoders are written in PC Basic,
BASICA, MASM, Pascal, and C.  These programs are available from CU20B as
KER:MSB*.*.

I'm not sure it's time to design yet another "standard" printable encoding for
binary files, but here are some considerations, in case anyone is interested:

The major reason for encoding binary files printably is to allow transmission
on or through character-oriented media not designed for arbitrary 8-bit data.
In particular, encoded files should pass freely through electronic mail, should
be downloadable via dialup (possibly through public data network), and
should be easily stored on and retrieved from magnetic tape.

The encoding should be compact (to minimize time and expense of transmission)
and simple (to allow the decoding program to be small enough for an individual
to type in), and it should allow errors to be detected during "de-encoding".

Since mail is often used to transmit these files, the decoding process should
be able to skip past mail headers and find the real beginning of the encoded
file.  The encoded file should begin with a distinctive header containing at
least the file's name, and possibly other attributes, and it should end with a
distinctive trailer, allowing multiple files to be concatenated (archived?)
together, and picked apart and decoded by a single run of the decoding program.

Did I say "possibly other attributes"?  I think we want to avoid anything
system-dependent here.  We should be shooting for a way to encode stream binary
data, not structured files.  If the file is to have structure (e.g. it is a DEC
FILES-11 file, or a Macintosh application, or a VM/CMS VB-format file), then
that should be imbedded in the data itself, and the encode/decode progam must
know how to handle it.

Did I say "archived"?  I don't want to raise the spectre of yet another
SQ/LIBR/SWEEP/ARC/etc/etc system.  Especially not one in which (like ARC),
the "archiving" program decides on the most appropriate encoding for each
file (e.g. it would be overkill to turn assembler source into a BOO file).
But the possibility of having more than one file concatenated together at
least suggests that each file's header should contain not only the file's
name, but also the encoding technique (including none).

There should be an error detection mechanism that is independent of the
character set of the host computer.  It should be possible to encode the file
on an ASCII system and decode it on an EBCDIC one, and vice versa.  It's hard
to imagine how to do this in a transportable way (given the idiosyncratic
nature of most ASCII/EBCDIC translation tables), or in a way that results in
short encoding and decoding programs.

Obviously, control and 8-bit characters should be excluded from the encoding,
as well as those printable characters that are known to cause problems with
networks and mailers (space, atsign, and period spring to mind).  And it
should break the file up into "lines" that are short enough (say, 64
characters?) to pass through the most restrictive line-, record-, or
block-oriented mechanisms, but that have no relation at all to the data
itself.

Here is a brief survery of some of the encoding techniques I know about:

HEX: Simple 1/2 packing into hex digits, with CRLFs inserted to break
 the file up into lines.  No error checking, compression, etc.  Very simple
 to encode and decode.

BOO: 4/3 packing, null compression, printable, no blanks or dots, no error
 checking, no skipping past mail headers, single file only.  Tends to survive
 mail, raw download, etc., but sensitive to transmission errors.

UUENCODE: 4/3 packing, no compression, printable.  Includes blanks, dots, and
 atsigns.  No error checking.  Skips past mail headers, but tends not to
 survive mail, card-oriented communication links (like BITNET), or any software
 that strips trailing blanks.

BINHEX version 4 (HQX): Macintosh only; 4/3 packing, printable, no blanks.
 Includes data and resource fork, allows Mac application to be fully
 reconstituted (MacBinary is similar, but is not a printable encoding).

Intel Hex format (HEX, H86): Simple 2/1 hex encoding, error-checked, used
 by Intel and compatible loaders.

VMSHEX/VMSDEH: VAX/VMS only.  Like Intel Hex format, but includes FILES-11 FAB,
 allowing FILES-11 files to be fully reconsitituted.

LZW and Huffman: These are compression, rather than encoding, techniques, but
 they are often built into encoding programs.  However, the decoding programs
 are too long and complicated to be typed in.

All of these have their advantages and disadvantages.  The tradeoffs are in
program complexity vs encoding efficiency and tranparency.  Further discussion
of the subject would be most welcome, as would a "standard" in this area.

------------------------------

Date: 30 September 1986 17:03:58 CDT
From: George Wiggans <[e-mail]>
Subject: Suggestions for MS-Kermit
Keywords: MS-DOS Kermit

I use Kermit extensively, but do not write code to add to it, therefore, I
wanted to suggest what enhancements I would like.

(1) I would like Kermit to assume all commands are prefixed with RUN unless
they are Kermit commands.  Many times I must retype the command because I
forgot the RUN.

[Ed. - Not a bad idea; it's been suggested before.  Maybe this will appear
in a future release.]

(2) A recall previous commands feature.  I use Norton's DOS Editor (NDE) in
DOS which lets me recall and edit earlier commands.  It uses the up and down
arrows to scroll through the previous commands.

[Ed. - You'll probably never see this, because the command parser is
supposed to be machine independent.]

(3) A Tek 4010 emulation for the IBM PC with an EGA card.

[Ed. - This may appear in a future release; several people have expressed
some interest in doing it.]

(4) A raw download from the mainframe using a 7171 terminal emulator so
yokeing the screen to the printer would work for printing files.

[Ed. - You already have this: LOG PRN.  The new CMS Kermit release has the
matching feature, XTYPE, which transmits a file raw, in transparent mode,
through the 7171.  You could even use this to drive a plotter.]

I am sure that you get many suggestions, but I thought that I would add
mine.

[Ed. - You're right.  And one of the suggestions I get is to come up with a
version of MS-Kermit that has been stripped of all its fancy features and
is once again a compact, simple file transfer program.  This is becoming an
issue not only because it's getting increasingly difficult for users to deal
with such a feature-laden program, but also because it takes up so much
space on disk and in memory.  The latter is a real problem for diskless
laptop portables.]

Thanks,
George

------------------------------

Date:  Mon, 6 Oct 86 09:13 EDT
From:  David M Chizmadia <[e-mail]>
Subject:  Screen Saver Feature as part of Kermit.
Keywords: MS-DOS Kermit

  Our site uses Kermit as the primary communications program on our IBM PCs.
We would like to have a feature which would allow us to set Kermit to blank
the screen after so many minutes of keyboard inactivity.  A command along
the lines of SET SCRNSAVE n (where n is an integer >= 0 and represents the
number of minutes of keyboard inactivity to wait before blanking the screen)
would be optimal.  If anyone has implemented or is planning to implement
this feature, I would be interested in hearing about it.  If not, I will try
to implement it and pass it back to this digest.

Dave Chizmadia

(ARPA) Chizmadia -at DOCKMASTER.ARPA

[Ed. - It might be a better idea to use another utility to do this.]

------------------------------

From: drilex![e-mail]
Date: Mon, 29 Sep 86 22:06:36 edt
Subject: MS-Kermit on 80386
Keywords: MS-DOS Kermit

I know it's awfully early, but has anyone tried a recent version of
MS-Kermit (2.28 or 2.29) on a Compaq 386 yet?  I have somebody who's hot
to buy one, but they need kermit...

I'd try it myself, except I'm not sure when I will get around to getting
a 386.

Craig Jackson
UUCP: {harvard,linus}!axiom!drilex!dricej
BIX:  cjackson

------------------------------

Date: Sat, 27 Sep 86 16:24:46 pdt
From: Bob Larson <blarson@usc-oberon>
Subject: Found on net.bizarre
Keywords: Kermit Humor

In article <[e-mail]> [e-mail] writes:
>
>You know how I like to spend a day?
>
>When I'm not installing database managers, compilers, graphics
>packages, etc. (and then FOLDING, SPINDLING and MUTILATING them
>so they'll run on our non-standard system), I like to sit by the
>phone and wait for questions about how to use Kermit. I make copies
>for our users who have PC's, and at least half of them call for
>help. The typical conversation goes something like:
>
>"Hello, may I help you?" (In my user-friendliest voice.)
>
>In an aggrieved tone:
>"Yeah, I'm trying to use Kermit and I'm having problems."
>
>(I wait half a second to see if they'll add to that - like;
> *what* problems? No WAY!)
>
>"Yes, what exactly is the matter?"
>
>"It doesn't work."
>
>(I break a pencil between two fingers.)
>"Ah. Did you read the entry in on-line HELP about how to use it?"
>
>"Yes, but I can't get it to do aaanything!"
>
>"Did you execute the file KERMIT.EXE on your PC?"
>
>"What?"
>
>(I'm not a violent person, but I star this user in a Sam Peckinpah movie.)
>"Are you sitting in front of your PC?"
>
>"Yes."
>
>"Type KERMIT."
>
>"... Ok, I did that."
>
>"Type TAKE M-S-K-E-R-M-I-T"
>
>"... ... ... Ok."
>
>(The INI file sets baud rate, etc. and CONNECTS them to the modem.)
>"You see where it says 'Connecting to Host Computer'?"
>
>Triumphantly:
>"Yes! I got this far, and it didn't DO anything!"
>
>"Well, at this point, you're communicating with your modem, NOT with
>VPS (our system). You have to type the dial command, and your modem will
>call the campus network. Then you can sign on as usual."
>
>"OOHHHH! Let me try that!"
>
>The user types the dial command, eventually gets it right, and
>(I'M NOT KIDDING ABOUT THIS) the goddam modem starts dialing on the
>line we're talking on!
>
>I stuff my eyes back into their sockets.
>
>There are a few seconds of silence at this point, during which I draw
>blood from my palms with my fingernails, as the user's brain grinds
>and grinds and comes up with THE QUESTION:
>
>"What do I do then?"
>
>(We're almost home now, I tell myself.)
>"Well, then you just run Kermit on VPS, and you can start transmitting
>files back and forth. It works just like the documentation says it
>does."
>
>Why do I let them go at this point? I KNOW they're going to call back,
>because people who don't know that you still have to dial in even if
>you're using Kermit can't possibly transfer a file with it, but if
>I talk to them much longer, things get red and hazy, and somebody just
>might get killed.
>
>Eventually they give up, and call me again. I establish that they have
>no idea what commands to type after they sign on and run Kermit ("Yes,
>of *course* I read the documentation!"), and have them come in to see
>me. Since I don't have a private phone line, I have to borrow the line
>from the cubicle across the hall, stringing it over the corridor.
>Our Assistant Provost inevitably brushes it with the top of his head (he's
>pretty tall), and visibly wonders why *THIS* goof is still working here.
>
>I hook up the modem and show them, STEP. BY. STEP. how to transfer files.
>The mists part, and BEHOLD! I've initiated yet another user to the mysteries
>of Kermit. They clutch my hand, weep little tears of gratitude, admire my
>plaster of paris Boston Terrier (you don't want to know), and they're off.
>
>Do I sound like a hateful little misogynist weasal, looking for a little
>sympathy? Well, I am, but the point is, you'd be one too if you had to
>do this OVER and OVER and OVER! Is it any wonder I come to work at 11 am,
>smelling of soy sauce? Do you have to ask why I torture small animals in
>the evening? Why I don't wear ties in the office, but DO when I'm lying
>around at home? Shall I tell you about the time
>two people came in the same day at different times for the above described
>help, and I later discovered they SHARE THE SAME PC???!!!
>
>ARRRRGGGGHHHHHH!!!
>
>I'm going to lunch.

------------------------------

End of Info-Kermit Digest
*************************


-------
 8-Oct-86 17:25:46-EDT,6730;000000000000
Mail-From: SY.FDC created at  8-Oct-86 17:24:12
Date: Wed 8 Oct 86 17:24:12-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V5 #13
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed,  8 Oct 1986       Volume 5 : Number 13

Today's Topics:
                        Kermit Book Available
                       New C-Kermits on the Way
                     Other New Kermits On The Way
             Re:  Screen Saver Feature as Part of Kermit

----------------------------------------------------------------------

Date: Wed 8 Oct 86 11:35:52-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit Book Available

The Kermit book is finally in print.  Thanks to all the members of the
Info-Kermit community who provided information, responded to queries, read
drafts, and helped in other ways, and especially to Don Knuth for contributing
the Foreword.  And thanks are due, perhaps even more, to all of you who have
kept Kermit alive and growing over the years by generously contributing your
time and effort to its design, development, and distribution, and to the
keepers of the computer networks that have made the rapid spread of Kermit
information and programs so easy.  Kermit is truly a community project.  I
tried to fit as many of you as I could into the acknowledgements, and
apologize in advance to anyone I might have missed.

The book is called "Kermit, A File Transfer Protocol," (author me), published
by Digital Press.  It does not replace the Kermit User Guide, because specific
Kermit programs are not described in detail, but it supplements it by
discussing motivation, commands, operation, and tricks in greater detail, and
filling in more background -- there are tutorials on file systems and on data
communications (RS-232, modems, cable-building, etc), plus many new tables,
diagrams, pictures, summaries, a glossary, etc etc.  There's a troubleshooting
guide, a new bootstrapping technique including a "baby Kermit" program in
BASIC short enough to type in to a PC, hints to programmers for writing and
submitting Kermit programs, etc etc.

The book does, however, replace the Kermit Protocol Manual; it presents the
protocol in more detail, and (I hope) more coherently, than the PM, and
includes program fragments from a bare-bones version of C-Kermit to illustrate
each facet of the protocol, in a much more layered and structured fashion than
was done before (but the PM will still be kept around).

It will take some time before the book reaches the bookstores, since it only
left the bindery this week.  In the meantime, it can be ordered direct from
Digital Press by calling 1-800-343-8321, order number EY-6705E-DP.  It is also
being distributed this week at DECUS in San Francisco, but reportedly it's in
short supply.  Anyone who has checked the book box on Columbia's Kermit order
form should be getting their copies within 2-3 weeks, maybe sooner (we'll send
them out as soon as we get them).

Disclaimer: I am obviously biased about this book.  Reviews, favorable or
not, will be most welcome and will be published in the Info-Kermit digest.
Reports of mistakes, typos, etc, are also welcome (so they can be fixed in
the next printing, if any) as well as suggestions for changes to make in
future editions.

------------------------------

Date: Wed 8 Oct 86 11:45:52-EDT
From: Frank da Cruz <[e-mail]>
Subject: New C-Kermits on the Way

There is a lot of work underway to bring C-Kermit to new systems.  Below is
a brief list of the work in progress; the major intention is to prevent
duplication of effort, and to promote cooperation.  If you are working on a
Kermit program for any of the systems listed below, or know anyone who is,
please have them contact us, so we can put them in touch with the people who
are working on these projects:

Apollo Aegis
Apple II GS, CPW (windows)
Apple Macintosh (convert Mac Kermit to Lightspeed C)
Data General MV series, AOS/VS
MS-DOS
NCUBE parallel processor with AXIS OS
VAX/VMS (add more knowledge about VMS file system)

If you know of anyone adapting C-Kermit to any systems not listed above,
also have them contact us, so we can add them to the list.  Thanks!

------------------------------

Date: Wed 8 Oct 86 10:14:45-EDT
From: Frank da Cruz <[e-mail]>
Subject: Other New Kermits On The Way

Here are some other Kermit development efforts.  Again, if you are (or know
of anyone who is) doing any work along the same lines, please (have him/her)
contact us:

Apple II: (1) New CROSS release for DOS; (2) new release in native assembler.
  ProDOS support may appear in one or both of the above.
Apple III (yes Apple III)
CDC Cyber 170 Series: Various new versions, improvements to current ones.
CP/M-80: New release, will support many more systems more modularly.
CP/M-86, Concurrent CP/M-86: IBM PC
Data General MV Systems, AOS and AOS/VS: versions in Fortran, C, DGL
HP-9000 and 98x6 BASIC systems
Honeywell DPS6/GCOS6
IBM System/370 Series: Major effort underway to integrate CMS and TSO versions
Intel development systems (many separate efforts underway)
Japanese micros - many versions available through NEC or NTT
Motorola 68000 assembler version, OS-independent
Motorola development systems (Xormacs, VME, Versados, etc etc)
MS-DOS: Version 2.29a will be ready soon!
MUMPS-11 (improved version reportedly done, on the way)
Philips development systems
Pick Operating System (IBM PC, etc)

There are also many, many others of a less certain nature.  All of these
efforts are listed in the file KER:AAWAIT.HLP on CU20B (AAWAIT HLP on
CUVMA).

------------------------------

Date: Mon, 6 Oct 86 15:30:20 pdt
From: [e-mail] (Dave Tweten)
Subject: Re:  Screen Saver Feature as Part of Kermit
Keywords: MS-DOS Kermit, Screen Saver Feature

You don't need to put a screen saver feature into Kermit.  There are
several public domain terminate-and-stay-resident screen saver programs
available, any one of which can be started before running Kermit
(perhaps in an AUTOEXEC.BAT file), and which will be effective while
Kermit runs.  The Info-IBMPC source code library at USC-ISIB.ARPA has at
least two.  I wrote another (which has the user-settable time feature
you requested).  I'm sure many others exist in the public domain.  A
little asking around should net you one you like.

------------------------------

End of Info-Kermit Digest
*************************
-------
28-Oct-86 11:16:10-EST,20840;000000000000
Mail-From: SY.CHRISTINE created at 28-Oct-86 11:14:44
Date: Tue 28 Oct 86 11:14:43-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #14
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 28 Oct 1986       Volume 5 : Number 14

New York Mets:
   The Official Baseball Team of the Kermit File Transfer Protocol

Today's Topics:
               Call for IBM Mainframe Kermit Developers
                          Re: File encoding
                     Where to Get HP-1000 Kermit
                 Kermit Server at Bitnet node UOFT02
                          Prime Kermit 7.57
                        RT11 XM Kermit Problem
                           Mac connections
                          MS-Kermit options
                   Two Small Requests for MSKERMIT
                       MSKermit LOG suggestion
                        Kermit on Compuserve?
                   Problem with Kermit and DATAKIT

----------------------------------------------------------------------

Date: Thu 9 Oct 86 13:23:41-EDT
From: Frank da Cruz <[e-mail]>
Subject: Call for IBM Mainframe Kermit Developers
Keywords: VM/CMS Kermit, MVS/TSO Kermit

A lively discussion (and some work) is underway to merge the major IBM
System/370 series assembly-language Kermit programs, so that VM/CMS and
MVS/TSO Kermits can share common OS-independent modules (particularly
the code that implements the Kermit protocol itself).  Any IBM mainframe
Kermit developer or maintainer who wants to be involved in this
discussion should send me a note (as SY.FDC@CU20B, or [e-mail]).
This includes those who have any connection with the Kermit programs for
MVS/GUTS, MUSIC, and MTS, and who might be interested in integrating Kermit
into the various dialects of Wylbur, and possibly also with CICS.

------------------------------

Date: Sat 11 Oct 86 02:08:17-PDT
From: Bob Larson <[e-mail]>
Subject: Re: File encoding
Keywords: File Encoding

Here are a couple of file encoding schemes that Frank da Cruz missed in his
list:

btoa/atob 4.0: 5/4 encoding to printable characters, space not included.
Designed for use with (and comes with) compress 4.0.  Has header and trailer
lines so mail headers may be skipped and multiple files may be sent
together.  (Available for ftp from the mod.sources archives at
seismo.css.gov, I have an os9/68k version if there is interest.)

Motorola S record: 2/1 encoding to printable characters.  Designed for use
with eprom programmers, etc. so includes address specification.  (Number of
address bits vary between various S record formats.)  The only advantage of
this format that I know of is encoding/decoding programs come with os9.
Included for completeness.

Bob Larson

[Ed. - Thanks for completing the encoding form list Bob.]

------------------------------

Date: Wed 15 Oct 86 11:24:44-EDT
From: Frank da Cruz <[e-mail]>
Subject: Where to Get HP-1000 Kermit
Keywords: HP-1000 Kermit

In V5 #3 of the Info-Kermit Digest, a message was posted by Michael Terenyi
describing a new HP-1000 Kermit that solved all the problems of the previous
versions, that was available from Paul Schuman of E-Systems, Inc,
Greenville, Texas.  Some weeks later, we actually received, installed, and
announced this version in the regular Kermit distribution.  However, Paul
has been getting numerous calls, blank tapes, etc, ever since.  Although
Paul was kind enough to contribute his program to Kermit Distribution, he
does not have the time or resources to honor the high volume of requests
he's been getting for this program.  If you need it, please get it either
from Columbia (by mail order, or over the networks as HPM*.*), or else from
the international Hewlett-Packard User Group:

  Interex
  680 Almanor Avenue
  Sunnyvale, CA  94086-3513
  Phone [phone]

You probably have to be a member of Interex before you can order programs
from them.  Paul thinks they have Kermit programs for a large variety of HP
minis, workstations, and PCs, all on native media, which is a service
Columbia has not been able to provide.

------------------------------

Date: Wed, 15 Oct 86 12:43 EDT
From: <[e-mail]> (brian nelson)
Subject: Kermit Server at Bitnet node UOFT02
Keywords: Kermit BITnet Server

For those of you experiencing trouble accessing [e-mail] there
was a problem in the way it sent interactive messages back.  It was acting
as if it were a NODE and not a USER when sending messages.  This has been
fixed.

Also, please note that it responds to interactive messages only, files sent
to it with imbedded commands will not cause it to send files back.

Brian Nelson

------------------------------

Date: Tue, 21 Oct 86 18:35:15 GMT
From: [e-mail]
Subject: Prime Kermit 7.57
Keywords: Prime Kermit

   There is a bug in PR1ME Kermit version 7.57.

   If, when in SERVER mode, the user logs off with a BYE command on the
micro-Kermit, the NEXT user to get that PRIMOS usernumber can have problems
related to the PRIMOS KILL and ERASE characters.  It showed up in the
Sheffield Editor for us.

 The problem arises if other software expects that the PRIMOS routine ERKL$$
returns leading zeros in the words that give the user's KILL and ERASE
characters as documented in DOC3621-190 Subroutines Reference Guide page
10-23.  What is not documented is that when writing the KILL and ERASE the
leading byte of the words should be ZERO.  This is the only reason that
reading returns leading zeros!

   Unfortunately, PRIMOS Kermit uses leading spaces when writing these
values.  This in itself causes no problem as when Kermit exits SERVER mode
in all ways EXCEPT when it receives a BYE command, it restores the user's
KILL and ERASE characters with words it had read previously.  Again this
seems no problem as LOGO$$ restores the System default KILL and ERASE
characters so everything appears OK to the next user.  But logo$$ does not
seem to alter the leading byte of the words holding KILL and ERASE, hence
the problem.

   The simplest fix in PRIMOS Kermit is as follows:-

   In GENERIC_CMD.PLP, before
         call logo$$(0,0,' ',0,0,code);
   insert the line
         call xfer_mode(0,code); /* restore terminal characteristics */

   Ideally, the first call to erkl$$ in XFER_MODE.PLP should be fixed so
that it has leading zeros in the character strings it passes, but this needs
more changes to be made in the source.  The fix given is short and it works!
There may be a problem with forced logouts which this fix obviously won't
cope with.  The QUIT handler calls xfer_mode so there is no trouble there.

   This caused us no end of trouble to track down to Kermit!  It seemed an
epidemic had struck as more and more users hit this problem.  (The PRIMOS
command TERM -kill and TERM -erase fixes a user in trouble).  It didn't help
that we changed from Rev 19.3 to Rev 19.4 at the same time as we released
Kermit 7.57.

  Neil Brooks
  University of Exeter Computer Unit

[Thanks.  We will forward this message to the authors of Kermit.]

------------------------------

Date: Thu, 23 Oct 86 11:51 EDT
From: <[e-mail]> (brian nelson)
Subject: RT11 XM Kermit Problem
Keywords: RT-11 Kermit

 A problem with the RT11 XM version of Kermit-11 (K11XM.SAV) has been
reported. The symptom is that any command that requires additional prompting
for input, such as SHOW and SET, the prompt will be garbage.  Ie, the
command:

        Kermit-11>SHOW <cr>

should reply with:

        What:

The cause is the command table being swapped over by the command line
editor, thus making the pointer to the prompt text invalid. The correction
is made in K11CMD.MAC as follows. The lines commented with /55/ are the
corrections.

Brian Nelson
[e-mail]

[Ed. - Thanks.  The fix is in KER:K11.BWR.]

------------------------------

Date: Fri 24 Oct 86 13:13:29-EDT
From: Frank da Cruz <[e-mail]>
Subject: Mac connections
Keywords: MacKermit

There have been increasing numbers of questions coming in about how to
connect Macintoshes and Mac-Pluses to modems and directly to other
computers.  I hope the following details will help.  I won't go into any
detail explaining terms -- you can look them up in a data communications
book (or the Kermit book!).

The Macintosh serial port is not RS-232, it's RS-422 and uses different
signalling.  The Mac RS-422 port lacks the modem signals CD, DTR, DSR, RI,
and RTS, and any modems that expect to handshake with the Mac using these
signals will not work unless the handshaking can be overriden (e.g. by
setting configuration switches in the modem) or by fakeout wiring in the
modem end of the cable.

The Macintosh serial port connector has 9 pins rather than the customary 25
pins that RS-232 requires.  The Mac-Plus has an 8-pin "Din-8" connector,
which needs a special converter from Din-8 to 9-pin to make it "plug
compatible" with the original Mac.

Here are the Macintosh 9-pin connector assignments, and the corresponding
Din-8 assignments:

9-pin   Din-8    Signal
  1       4       FG     (frame ground)
  2               +5V    (not connected in DB9/Din-8 converter)
  3       4       SG     (signal ground)
  4       8       TD+    (transmit positive)
  5       5       TD-    (transmit negative)
  6       2       +12V
  7       1       CTS    (clear to send, or "handshake")
  8       6       RD+    (receive positive)
  9       3       RD-    (receive negative)

The cable that you need to connect the Mac to a modem or to another Mac may
not be readily available in a store, so you might have to alter or build one
yourself.  The parts (DB-9 and DB-25 connectors, pins, cables, tools, etc)
should be available from computer stores or in computer supply catalogs like
Inmac, Black Box, Misco, etc.

To connect a Macintosh to a modem, you need a male 9-pin (called DB-9, DE-9,
or D-9) on the Mac end.  Only pins 3, 5, 8, and 9 need to be connected.  On
the modem end, a 25-pin male DB-25 connector.  Four wires in the cable
should connect the pins in the two ends as follows:

Mac    DB-25
 3       7    Signal ground
 5       2    Transmitted data
 8       1    Frame ground
 9       3    Received data

Before testing this cable with your modem, be sure it's plugged into to
desired port (the present version of Kermit on the Macintosh, 0.8(34), works
only on the communication port, not on the printer, SCSI, or any other port;
this restriction may be lifted in future releases), and the baud rate is set
appropriately, usually 1200.

You should be able to dial the modem (if it's Hayes compatible) by typing
ATD and the phone number.  If this doesn't work, check the configuration
switches of your modem.  In particular, it must be in originate mode (ATD
puts Hayes-like modems in originate mode automatically), and it may need to
be instructed to ignore DTR (many modems require DTR signals from the PC,
but the Mac doesn't provide one).  For further details, read your modem
manual.

To connect your Mac to another PC, use a "null modem" cable.  Here is how
to set up a null modem cable with a Mac 9-pin (male) connector on one end
and a male DB-25 on the other:

Mac 9-pin     DB-25      The DB-25 end of this cable can be plugged into
                         any computer that has a female RS-232 DB-25 serial
3 SG ---+                port connector.  To connect a Mac with a PC/AT
        |                (which has a DB-9 connector, but with RS-232
        +---- 7 SG       rather than RS-422, signalling), use a regular Mac
        |                modem cable, described above, on the Mac, a regular
8 RD+ --+                PC/AT modem cable on the AT (available in stores
          +-- 6  DSR     and catalogs), and a female-female null modem
          |              (also available in stores and catalogs) to connect
7 CTS <---+-- 20 DTR     the DB-25 ends of each cable.
          |
          +-- 8  CD      To connect two Macs back-to-back, use a similar
                         trick: two Mac modem cables, plus a null modem.
5 TD- ------> 3  RD
                         Building, adapting, and testing connectors is
9 RD- <------ 2  TD      not everyone's dish of tea.  If it's not yours,
                         then take a copy of this message to a computer
         +--- 4  RTS     store and point to what you need.  If possible,
         |               try to test it there on a configuration similar
         +--> 5  CTS     to yours before paying for it.


Back to modem cables.  If your modem requires certain modem signals, and
this requirement cannot be disabled, you should be able to cajole the modem
into operation by using a null modem cable like the one above, but with

5 TD- ------> 2  TD

9 RD- <------ 3  RD

That is, the modem signals RTS, CTS, DTR, DSR, and CD are all faked in
the connectors, but receive and transmit are not cross-connected as in a
real null-modem cable.

------------------------------

Date: Thu 9 Oct 86 12:02:50-EDT
From: [e-mail]
Subject: MS-Kermit options
Keywords: MS-DOS Kermit

(1) - In a recent message to Info-Kermit, someone proposed that the MS-DOS
Kermit subcommand parser incorporate assumption of a "run" prefix for inputs
that are not specifically Kermit subcommands.  I suggest that, unless such
suggested feature is effected as a togglable option via Kermit's "set"
subcommand or as an equivalent togglable function, such proposed feature's
simplistic allure be resisted because the "feature" could potentially have
unintended side effects that would interfere undesirably with Kermit's
otherwise expected proper behavior.

As you are aware, the proposed run prefix assumption feature would send DOS
flying on PATH-related searches for each and every Kermit-level
nonsubcommand input, including typos.  For example, people who park their
harddisks when they run Kermit for long remote sessions would see this
behavior of the proposed feature put their disk in "drive."  The feature
might also necessitate that Kermit macros be named differently from programs
on the PATH which the "feature" would want to run -- clearly a cumbersome
and "nontransportable" requirement.

(2) - I much prefer to see Kermit continue to steer clear away from
special-interest "gimmeckery" such as commandline recall/edit, screensaver,
alarm and calculator functions, etc.  I have seen many users (beginner and
advanced but not intermediate) who often choose to use earlier (even buggy)
versions of MS-Kermit just because they want a bare-bones program without
the fancy-schmancy code even though they have ready access to V-2.29a!

(4) - A universally useful feature would be runnability of MS-Kermit with
DOS-level subcommands, switches, etc. -- e. g.:

   DOS>KERMIT -do MACRO1
or,
   DOS>KERMIT -take INIT1.

(5) - Without implying that Kermit should become a whole O/S with
development tools, compilers and the rest, I ask whether Kermit could indeed
not be modularized so that a core program could be run and then desired
features could be loaded optionally through subcommands that work on
external file contents -- that'll take care of memory size, extra features
and the rest of the complaints and suggestions, wouldn't it?  And, how about
an O/S-(in)dependent Kermit Function Module Protocol?  /Farhad

------------------------------

Date: Sat, 11 Oct 86 08:11:16 EDT
From: John C Klensin <[e-mail]>
Subject: Two Small Requests for MSKERMIT
Keywords: MS-DOS Kermit

With apologies for joining the litany...

1) It would be nice if the key scanning table were expanded so that the two
new function keys (F11 and F12) on the extended keyboards could be used.
Neither their scan codes, nor the function key names are recognized by 'set
key', and 'show key' does not even recognize that they are keys.

[Ed. - There's nothing in Kermit that prevents the new scan codes from
being recognized.  These keys simply are not generating them in the same
way the other keys generate scan codes.  Even on the previous keyboards,
some keys -- like Ctrl-1, Ctrl-3, Ctrl-4, etc, keypad 5, Sys Req, etc --
generate no scan codes.]

2) There is apparently no convenient way to display the [path]name of the
current local directory.  I can set it (with LOCAL CWD ...), or get a
directory of its contents (with LOCAL DIR), but can't just inquire about its
name.  The CP/M-86 versions do an approximation to the job by displaying the
kermit prompt in the form

   KERMIT86 DN>

where D and N are the drive and user number; MSKERMIT should have SOME way
to obtain this info without listing out the contents of the directory.

[Ed. - Right, this should show up in a future release.]

Similarly, it would be nice to be able to ask the thing to tell me to whence
I am logging.  I can, more or less, find out if logging is turned on, but
can't (at least as far as I know) find the name of the file to which logging
is occurring.

Both of these things take on added importance as the presence of scripts and
TRANSMIT make it more possible to tailor the kermit environment to the needs
of a particular [naive] user, introducing more confusion as to what has
happended when something goes wrong.

[Ed. - All good points.  Anything that can be SET should be capable of
being SHOWn.]

------------------------------

Date:    Wed, 15 Oct 86 07:29 EST
From:  [e-mail]
Subject: MSKermit LOG suggestion
Keywords: MS-DOS Kermit, LOG command

Being an avid user of IBM's 7171 controller via an IBM PC and MSKermit, I
might suggest the following modification to MSKermit's LOG feature: allow
one to strip escape sequences if desired.  Session logs of sessions through
a 7171 or Series 1 controller with IBM mainframes can be accomplished with
the escape sequence - F commands, but dumping screen at a time for more than
a few screens is anything but easy.  If an option was available for the LOG
function which would allow the user to choose between keeping the escape
sequences and stripping them, I believe its functionality would be greatly
increased.

Mark

[Ed. - Doing what you ask would introduce a whole new level of complexity
into terminal emulation, slowing it down significantly.  It would also add
dependence on the particular terminal being emulated, and on the system
doing the emulating.  In your particular case, a way around the problem
is to use CMS Kermit's XTYPE and XECHO commands, to send stuff "raw" to
the ASCII terminal, where it can be logged.]

------------------------------

Date: Mon 13 Oct 86 13:12:46-EDT
From: Dan Caldano <[e-mail]>
Subject: Kermit on Compuserve?
Keywords: Compuserve

Does anyone have any info about downloading files from Compuserve using
Kermit on a 512K Mac?  Am new to this sort of thing, and while I've mastered
downloading from our local DEC20 I must admit to being daunted by what I'm
reading on Compuserve (besides it's expensive just "grazing" through Compu-
serve) and in various magazines.  Anyone out there able to point out what
I'm missing?  Any help would be appreciated, thanks.

[Ed. - Good question.  Can some knowledgable Compuserve subscriber post
a message to Info-Kermit telling whether Kermit is available on Compuserve,
and if so, how to get at it?]

------------------------------

Date: Mon, 13 Oct 86 17:19:47 EDT
From: [e-mail] (Vernon Bradner)
Subject: Problem with Kermit and DATAKIT
Keywords: DATAKIT

I am trying to use Kermit over AT&T's DATAKIT packet switched data network.
Kermit file transfers work, but sometimes have many frame retransmits
resulting in much longer file transmit times.

The xmodem file transfer protocol has no such problems over DATAKIT.  Of
course, I would much prefer to use Kermit (especially since with Kermit I
can transmit several files at once, unlike xmodem).

Has anyone else had similar problems with Kermit and DATAKIT? Possibly I
just have the wrong settings in Kermit?

Any ideas you might have would be a big help.

Thanks - Vern Bradner ([e-mail])

[Ed. - Has anyone had experience using DATAKIT packet switched data network?]

------------------------------

End of Info-Kermit Digest
*************************
-------
 3-Nov-86 16:36:28-EST,14520;000000000000
Mail-From: SY.FDC created at  3-Nov-86 16:34:24
Date: Mon 3 Nov 86 16:34:22-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V5 #15
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Mon,  3 Nov 1986       Volume 5 : Number 15

Today's Topics:
                 Kermit Files Split into Three Groups
               New Release of Kermit for TRS-80 Model 4
                  Atari ST Kermit Diskette Volunteer
                       Re: CompuServe vs Kermit
           How to Display Connected Directory in MS-Kermit
                      Kermit vs Datakit Networks
                PROCOMM Kermit File Transfer Problems?
              KermitLANd: Suggestions to Improve Kermit
                Ideas for Kermit Distribution Overflow

----------------------------------------------------------------------

Date: Thu 30 Oct 86 17:08:01-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit Files Split into Three Groups
Keywords: Kermit Distribution, Distribution, Tapes, OK State, UUCP

The Kermits just keep rolling in.  In June 1985, the material became too big
to fit on a single 1600-bpi 2400-foot reel of labeled tape, so we had to
split the files into two groups: A (micros) and B (minis and mainframes).
In August 86, the collection grew too large for two tapes, and intallation
of some new versions was put on hold.  So now a third tape (C) has been
added.  Tape C is for "esoterica" (less popular versions of Kermit,
implementations infrequently requested from us, European and Japanese
versions, etc, and redundant versions) and for large documents -- the Scribe
source for the User Guide and Protocol Manual, the mail archives, etc.  The
AAVERS.HLP file tells exactly which group each implementation is assigned
to.  AAFILES.HLP explains in a bit more detail.

Apologies to anyone who feels slighted by having their favorite Kermit
version assigned to the "esoteric" tape.  The assignments were not totally
arbitrary and capricious, but were made mostly according to the frequency
with which people ask for (or about) these versions, with the goal of having
the three collections occupy about the same amount of disk/tape space (about
15MB each).  The most popular micro and mainframe Kermits remain on tapes A
and B, so that people who order these tapes in the "old way" will still most
likely get what they were expecting.

For network access, the procedures are pretty much unchanged.  FTP, NFT, and
KERMSRV will continue to work as before.  The file KER:AANETW.HLP has been
updated (along with all the other relevant files) to reflect the new layout.
Apologies for the disruption in KERMSRV service from Friday afternoon (Oct
31) to Monday afternoon (Nov 3) while the files were being reorganized.

As we announced a couple months ago, our major tape-making facility (a small
UNIX Vax) could not have its Kermit files updated until this reorganization
took place.  This has now been done.  Oklahoma State University, which keeps
a parallel Kermit collection for UUCP access, updates its files from this
VAX; hence OK State has not been getting new Kermit files since August.  We
will send them a new set of tapes this week, and the automatic updating
should kick in again after they have installed it.

------------------------------

Date: Fri, 31 Oct 86 13:01:26 -0600
Subject: New Release of Kermit for TRS-80 Model 4
From: Gregg Wonderly <[e-mail]>
Keywords: TRS-80 Model 4

This is to announce the newest version of the TRS80 Model 4 KERMIT.  This
version, 5.2, has many small bug fixes, as well as some major additions to
the program.  The changes are listed in detail in the file M4CHGS/ASM, but
the most important ones since the previous release (5.0) are bug fixes,
command restructuring (particularly SET FILE), transaction and debug
logging, and wildcards allowed in SEND and KILL.

Version 5.1 was never released.  There were also some changes in the
H19-filter that is now included in the distribution.  These changes include
the addition of a STRIP8 parameter to SETH19 that will allow the parity bit
to be stripped from characters before they are put on the display.

In this version of KERMIT, I have made some attempts to start reducing the
number of hardware manipulations that do not use the system SVC's.  However,
there are still many Model 4 specific operations.  I would like to begin
replacing the Model 1/3 version of KERMIT with this version, in the interest
of making more of the functionality of Model 4 KERMIT available to Model 1
and 3 owners.  If anybody is interested in taking on the task of doing this
for either machine, the help would be greatly appreciated.  Most of the work
will involve finding replacement code for routines that manipulate the Model
4 hardware (Display, Comm Line, etc...).

Any interested parties should send mail to me at the address below so that
there can be some sort of cordination of efforts.

Gregg Wonderly
Department of Computing and Information Sciences
Oklahoma State University

UUCP: {cbosgd, ea, ihnp4, isucs1, mcvax, uokvax}!okstate!gregg
ARPA:  [e-mail] or gregg%okstate.CSNET@CSNET-RELAY

[Ed. - Thanks, Gregg!  The new version replaces the old one as KER:M4*.*.
In the spirit of consolidating the hundreds of Kermit versions, I'd heartily
encourage anyone who cares about the TRS-80 Model 1 and 3 Kermits to get
together with Gregg and try to hammer together a common version for the
models 1, 3, and 4.]

------------------------------

Date: Mon 3 Nov 86 12:05:59-EST
From: Il H Oh <[e-mail]>
Subject: Atari ST Kermit Diskette Volunteer

I finally got Kermit running on my Atari ST.  I'd be glad to mail ST Kermit
diskettes to other ST users, if they'll send me a preformatted diskette and
a self-addressed, stamped return mailer.  My address is:

  Il Oh
  362 Riverside Dr. Apt. 10B7
  New York, NY 10025.

il

[Ed. - Many thanks!  Diskette volunteers are always welcome, as are user
groups and diskette services that are willing to provide Kermit diskettes by
mail order at low cost (say, in the neighborhood of $10).  If anyone out
there has a Kermit program on a diskette that's not readily available from
Columbia or other sources, you are heartily encouraged to volunteer as Il
has done, or to submit it to an appropriate user group or diskette service.]

------------------------------

Date: Tue, 28 Oct 86 21:40:12 est
From: [e-mail] (John McNamee)
Subject: Re: CompuServe vs Kermit
Keywords: CompuServe

To answer the query from Dan Caldano in Info-Kermit V5 #14: no, CompuServe
does not support Kermit.  They support XMODEM and two of their own protocols
(CIS "A" and CIS "B"), and are working on something like X.PC for concurrent
file transfer and terminal sessions.  I doubt they are going to support
Kermit since it was a major fight to get them to support XMODEM, and a lot
more of their users have XMODEM than have KERMIT.

John McNamee    <[e-mail]>       CompuServe: 70235,1345

[Ed. - Do the current protocols suffice?  Can everybody get at Compuserve
with an 8-bit transparent path, with buffers that never need to be shorter
than 132, etc?  Or do they all have CompuServe A & B on their micros?  If not,
then maybe those who need Kermit could start infiltrating and agitating...]

------------------------------

Date: Wed 29 Oct 86 15:05:29-EST
From: Peter Kanaitis <[e-mail]>
Subject: How to Display Connected Directory in MS-Kermit

In Info-Kermit Digest V5 #14, John C Klensin writes:

>2) There is apparently no convenient way to display the [path]name of the
>current local directory....
>
>[Ed. - Right, this should show up in a future release.]

Why not do a:

Kermit-MS>run cd
 or
Kermit-MS>run chdir

P. Kanaitis
Allegheny-Singer Research Institute
[e-mail]

[Ed. - Where there's a RUN, there's a way...]

------------------------------

Date: Wed, 29 Oct 86 08:02:46 est
From: ulysses![e-mail] (Philip S. Kravitz)
Subject: Kermit vs Datakit Networks
Keywords: Datakit

Unlike Vern Bradner (Info-Kermit Digest V5 #14), I use Kermit all the time
over Datakit networks and have not experienced any problems.  (I primarily
use the Unix version of Kermit although I have had no problems with the
MS-DOS version either).

------------------------------

Date: Wed, 29 Oct 86 16:10:04 PST
From: [e-mail]
Subject: PROCOMM Kermit File Transfer Problems?
Keywords: PROCOMM

I am having problems transfering files from an IBM-PC/XT using PROCOMM V2.42,
to a VAX/VMS V4.4 system running KERMIT-32> V3.1.066.  File transfers seem to
work fine with normal PCKERMIT/MSKERMIT V2.29, but will not work with PROCOMM.
Has anyone out there had any experiences with PROCOMM'S kermit file transfers
to a VAX ???

------------------------------

Date: Thu, 18 Sep 1986 15:28 PDT
From: "Jeffrey Sicherman"  <[e-mail]>
Subject: KermitLANd: Suggestions to Improve Kermit
Keywords: Kermit Protocol, Suggestions

My intention was to link several PCs with on onsite minicomputer.  Since
Kermit is already in the public domain and is implemented on numerous
machines, it seems to me that it could be suitable for this purpose if some
program changes were made to existing implementations and a very few
(perhaps even non-essential) packet/protocol changes were made for a
LAN-only environment.  Some of the considerations that have occurred to me
are indicated below, but I'm sure there are some features and complexities
that I have overlooked.

[Ed. - Jeffrey goes on to point out that a Kermit server is a lot like a
network file server, and then discusses problems of routing, station
identification, topology, media access & contention, file attributes, mail,
etc., at some length.  KERMIT IS NOT A NETWORK.  It's strictly for
point-to-point, user-initiated, temporary connections over serial
communication devices.  Furthermore, Kermit provides terminal emulation, NOT
virtual terminal service -- there's a big difference.  Kermit's design is
simply not amenable to layering of arbitrary kinds of network services --
especially interactive ones like virtual terminal service, SMTP dialogs,
etc.  All these problems have been solved already, and a lot of the software
-- particularly TCP/IP implementations -- is either in the public domain or
else relatively cheap.  Let's remember that the vast majority of Kermit
users are individuals with modems who couldn't care less about these issues,
let alone take the time to work on design and implementation problems that
take huge, PAID, programming teams years to solve.]

------------------------------

Date: Thu, 18 Sep 1986 00:19 PDT
From: "Jeffrey Sicherman"  <[e-mail]>
Subject: Ideas for Kermit Distribution Overflow
Keywords: Files

I noted the request for assistance in cleaning up the Kermit distribution
files in the recent digest (vol 5 no. 8) and the associated difficulties in
maintaining order in the system.  In response to this, I suggest the
following:

It would be useful to have a file that was a matrix of kermit
implementations.  The rows of this matrix would be the various
implementation; the columns would be features implemented.  This could be
restricted only to features defined within the Kermit protocol and standard
or could also include other esoterica but should at least include all the
defined features and such things as mode of operation.  The matrix entries
could be as simple as Y/N or X/- to indicate the compliance, or a level of
support (e.g.  checksum types) or could indicate parametric values (e.g.
maximum packet sizes) or the characters used for implementation (e.g.
prefixes).

     A couple of columns could also include annotations such as latest
version.  Multiple entries might be desirable where there are multiple
implementations or there is a new version in beta test; if so they should be
marked as such.  It would also be nice to have some figure of merit or
rating that indicates the reliability, quality of documentation, and ease of
use; this would probably be not scientific in nature but hell, one of the
advantages of development by controlled chaos is not having to adhere to a
lot of bureaucratic rules.

     Admittedly, a matrix of reasonable comprehensiveness would be rather
large and be difficult to present in printed form.  Therefore there should
be a native, master form of the matrix which is comprehensive.  This, I
expect, would take the form of a spreadsheet file (in native form and/or
some common convertible, importable standard one)...

[Ed. - Jeffrey goes on to describe how the matrix might be implemented, and
discusses some of the attendant problems.  It's a great idea, but one that
will probably never see the light of day.  If it's a spreadsheet, it's
necessarily dependent on some piece of software that not everybody has.  If
it's plain text, we've got a problem in organization and formatting; many
people want to see this information in printed form, which limits it to 80
or 132 columns in width -- our AAV*.* files are the best we've been able to
come up with to date; they fit on the screen, and can be printed 2-up on
landscape paper and/or double-sided for convenient mailing (when you mail 30
or 40 Kermit info packets per day, you have to think of these things).  They
show the most important information (file prefix, system, os, language,
version number, date, contributor) as compactly as possible in the space
that we have.  To reorganize these files all you need is a sorting program,
which every computer should have, and to search them a text editor suffices.
Still, the need for a master list of Kermit versions (available, on-the-way,
and possible) that includes more information than the AAV and AAW files is
real.  I expect we'll have to do something like this one day, and the form
it will take will be some kind of simply structured plain text.  It's just a
matter of finding the time to do it.]

------------------------------

End of Info-Kermit Digest
*************************
-------
12-Nov-86 17:37:49-EST,23422;000000000000
Mail-From: SY.CHRISTINE created at 12-Nov-86 17:36:47
Date: Wed 12 Nov 86 17:36:47-EST
From: Christine M Gianone <[e-mail]>
Subject: INfo-KErmit Digest V5 #16
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 12 Nov 1986       Volume 5 : Number 16

Today's Topics:
                  Announcing HP9845 Kermit in BASIC
                       Updates to Cyber Kermit
                     Oksatate Kermit Distribution
                         Getting Kermit Files
                  F11 and F12 on new IBM PC Keyboard
                            TSO Kermit Fix
                       Fix to os9 Kermit Server
                        Portable 68000 Kermit
                    More on CompuServe vs. Kermit
                        CompuServe and Kermit
                      VAX/VMS Kermit to PROCOMM
                   PROCOMM's Kermit and the VAX/VMS
                PROCOMM Kermit File Transfer Problems
                        Kermit-32 and PROCOMM
               How to Transfer Binary from UNIX to VMS?
                           VAX/VMS & Kermit
                        C-Kermit and Xenix 3.0
                    Re: FIDO - UNIX Kermit problem
                   Rainbow MSKERMIT initialization

----------------------------------------------------------------------

Date: 7-NOV-1986 12:53:27
From: [e-mail]
Subject: Announcing HP9845 Kermit in BASIC
Keywords: HP9845 Kermit

          Please find attached a listing of a minimalist kermit data
transfer program in interpreted Basic (!) for the HP9845. As it's in
interpreted Basic a listing of the source code seemed the best form to
distribute it in.  This implementation was developed by Chris Walker in the
Physics Dept here, and is principally designed for the transfer of
experimental data from a micro functioning as a data logger to a mainframe.
As such it lacks some features of a standard Kermit implementation, but it
works well and does what its supposed to do.

          Cheers,
                    Doug

Doug Moncur, Computing Service, University of York, Heslington, York YO1 5DD
          tel: [phone]x487 :: janet: [e-mail]

[Ed. - Thanks for the new Kermit version.  Many people have asked for this
in the past.  The files are in KER:HP9845.*.]

------------------------------

Date: 12-NOV-1986 10:14:07
From: [e-mail]
Subject:  Updates to Cyber Kermit
Keywords: Cyber Kermit

  A new version of Manchester University's Cyber Kermit (CYB) has just
arrived here: I've attached their release notes below.
                                   Alan

CYBKER.UPD

In addition to several minor alterations and improvements, there are
two major changes to Cyber Kermit  which have been requested by many
users of the program:

A Directory command has been added to list the names and lengths  of
local files.  When an optional filename parameter is specified, only
those files with matching names are listed.   This command is avail-
able both as a local command on the Cyber and as a remote command in
server mode.

The wildcard character '*' is allowed in file names after DIR, SEND,
remote DIR, and remote GET commands.

[Ed. - These files will placed in KER:CYB*.* as soon as they arrive over the
network.]

------------------------------

Date: Tue 11 Nov 86 09:50:49-EST
From: Frank da Cruz <[e-mail]>
Subject: Oksatate Kermit Distribution
Keywords: Okstate, UUCP

For those who may have missed previous announcements about this, here is a
brief description of the dialup Kermit file services available from Oklahoma
State University, Department of Computing and Information Sciences, Stillwater,
Oklahoma.  The OK state collection has just been brought up to date to reflect
the new 3-area organization, and to include the Kermit versions that have been
announced since last August.  OK State provides both UUCP and Kermit dialup
access.

The files from TAPE A are in /usr/spool/uucppublic/kermit-a/*
The files from TAPE B are in /usr/spool/uucppublic/kermit-b/*
The files from TAPE C are in /usr/spool/uucppublic/kermit-c/*

 -- UUCP --

You need to set up "okstate" as a site in your "L.sys" UUCP dialing file
using the information listed below.  You can then issue the following
commands on your system:

   uucp okstate!~uucp/kermit-a/aaaread.me /usr/spool/uucppublic

   (this example will retrieve a general information file about the entire
    Kermit Distribution.  DO THIS FIRST!)

   uucp okstate!~uucp/kermit-b/ck\* /usr/spool/uucppublic

   (this example will retrieve the current version of C-Kermit)

There are several files available that contain information about the entire
distribution.  We recommend that you retrieve these files first.  They are
"aaaread.me" which explains the file name conventions used, "aafiles.hlp"
which explains how to find the different kermit versions, and "aafiles.dir"
which is a complete listing (by name) of all files in the in each kermit
directory.  These files will enable you to choose the right files the first
time.

UUCP Login information:

Site Name    : okstate
Phone number : [phone] (300/1200 baud)
Login name   : uucpker
Password     : thefrog
Hours        : 24 hours per day, 7 days a week
Problem      : okstate!uucp-support                          (UUCP)
  reports    : [e-mail]                 (ARPA)

The following is a sample L.sys line (\r is a carriage return):

okstate Any ACU 1200 405-624-6953 "" \r ogin: uucpker word: thefrog

 -- KERMIT SERVER ACCESS --

Okstate also provides access to the Kermit distribution via a Kermit Server.
The number is the same as above for the uucpker login, so the line may be busy
quite a bit.  This server is a specialized server with controlled access.  At
present, the server is only allowed access to the Kermit directories on our
machine.

You need the following information in order to access the server:

KERMIT login   :   kermsrv
Password       :   piggy
Parity         :   even
Data path      :   7 bit
Available      :   24 hours/day, 7 days a week

When the login is completed, the server will start, and you should escape
back to your local KERMIT to issue further commands.  If the server remains
idle for a period of time around 10 minutes, it will be stopped.

The best place to start after logging on is "REMOTE HELP", followed closely by
the desired "REMOTE DIR" commands.  If you don't include an argument to REMOTE
DIR, you should be prepared for more than 600 lines of output.  It is usually
better to read the 'aaaread.me' file (using REMOTE TYPE perhaps) and then do
the DIR with some kind of wildcard (like "REMOTE DIR ck*").

Mark Vasoll
Computing and Information Sciences       Internet:  [e-mail]
Oklahoma State University                UUCP:  {cbosgd, ihnp4, isucs1,
Stillwater, Oklahoma                            pesnta, uokmax}!okstate!vasoll

[Ed. - Once again, many thanks for providing this service.  A much longer and
more detailed description of how to access the OK State Kermit files may be
found in the file AANOKS.HLP in the Kermit distribution.  There may be a
slight delay before this service is fully available because of a last-minute
foulup (Columbia's fault) with the tapes.]

------------------------------

Date: Wed 5 Nov 86 14:16:29-EST
From: Ken Rossman <[e-mail]>
Subject: Getting Kermit Files
Keywords: FTP, Arpanet

It seems to be a general problem with the ARPAnet backbone these days.
There's been lots of speculation on what the actual problem is and how to
solve it on lists like TCP-IP.  In any case, the only thing I can recommend
at this point in time is to try the file transfer during off hours and on
weekends.  I think I've had my best successes with FTP on Saturday nights/
Sunday mornings.  Submit a batch job to get the files, so you don't actually
have to be there at that time.  /Ken

------------------------------

Date: Wed, 29 Oct 86 08:59:32 PST
From: [e-mail]
Subject: F11 and F12 on new IBM PC Keyboard
Keywords: IBM PC Keyboard

Following is a note from our kermit guru, Greg Small ([e-mail])
regarding patches he made to our version of Kermit to allow use of F11 & F12.
The patches DO NOT specifically apply to any other versions of Kermit, but
may provide a starting point for patching other versions.

   Al Stangenberger
   Forestry & Resource Mgt.
   U. C. Berkeley

[Ed. - Thanks for the patch.  Many people have asked about this.  Greg's
changes have been forwarded to Joe Doupnik for inclusion in the next
release, coming Real Soon Now...]

------------------------------

Date: Mon, 3 Nov 86 18:10:24 pst
From: [e-mail] (Glenn Thobe)
Subject: TSO Kermit Fix
Keywords: TSO Kermit

TSO Kermit v.1.1 appeared to be broken as file transfers would regularly
fail at the same point in the transmission.  I was advised to enter the
following TSO command:

    profile char(bs)

which totally fixed the problem.  Apparently anything other than "bs" for this
profile parameter causes some character translation which interferes with the
incoming data.  I hope this information will be of use to others.

-Glenn Thobe

[Ed. - This message has been added to the TSO Kermit beware file -
KER:TSOKER.BWR ]

------------------------------

Date: Mon 3 Nov 86 23:42:40-PST
From: Bob Larson <[e-mail]>
Subject: Fix to os9 Kermit Server
Keywords: os9 Kermit

After seeing a rather vague bug report in the mod.os.os9 usenet newsgroup
about os9 kermit, I did find the bug in the os9srv.c module of os9 kermit:
It did not allocate space for the receive file name to go into.  I have not
tested this fix for the same reason I never tested the host mode originally:
my system is not set up to answer the phone.  The fix is rather
straitforward (two lines of code) and obviously needed, so I am including
the fixed os9srv.c at the end of this message.

The answer to the question of who should get the os9 kermit bug reports is
probably me, being the person who submited the last two versions to the
columbia kermit archives and the latest to the os9 users group.  Reports
sent to [e-mail] would probably get to me also.

Bob Larson
Arpa: [e-mail]  or  [e-mail]
Uucp: sdcrdcf!usc-oberon!blarson

[Ed. - Thanks Bob!  The new file KER:OS9SRV.C has replaced the old one.  The
old file has been moved to KO:OS9SRV.C.]

------------------------------

From: [e-mail]
Date: 11 nov 86  14:38 GMT +0100
Subject: Portable 68000 Kermit
Keywords: 68000 Kermit

[Ed. - This is from Roberto Bagnara, Physics Department, Bologna University
(Italy), concerning a Kermit program he's developing for the Motorola 68000
family of processors, designed for portability among 68000 operating systems
and assemblers, particularly those of the sort that are sold as turnkey
systems for lab work, with little or nothing in the way of utility software
or operating system support for many of the functions we take for granted.
Anyone who has an interest in such systems, please respond to Roberto's
questions directly, or through Info-Kermit.  Thanks!]

   I'm writing to you, in order to clarify some points about the Kermit
program that I'm developing. Here they are:

a) I'm working hard, because I'd like to carry out my job by
   the end of this month.  The first version of Kermit68K will
   be necessarily a preliminary one, due to the fact that, being
   employed at a department of physics, I haven't the advantage
   of a useful exchange of ideas, suggestions, etc.
   I need strong user/implementor feedback, in order to make the
   program effectively portable to different machines and
   operating systems, and to refine it, so that it works at its
   best.  Having said all that, do you think that it's better to
   include it in the official distribution as a preliminary or
   you know any potential user/implementor, whom I can address
   to, in order to get this feedback?

[Ed. - Any "alpha test" volunteers out there?  If not, then let's just
install the preliminary version for distribution.]

b) Ensuring portability while maintaining, as much as possible,
   a unique source code would be a nice result. Unfortunately
   the assemblers differ, in general, in the syntax of the
   directives, besides some of them produce machine code
   directly, thus not allowing linking with other modules, that
   is separate assembly is impossible.
   Is there a public domain or highly diffused pre-processor
   for files inclusion and conditional text insertion ?

That's all for now.

                       Thank you very much.
                              Roberto

------------------------------

Date: Mon, 3 Nov 86 23:24:09 est
From: [e-mail] (John McNamee)
Subject: More on CompuServe vs. Kermit
Keywords: CompuServe

Most CompuServe users access the service via CompuServe's own network, which
has dialups all over the place.  Very few come in via Telenet, Tymnet, etc.
The CompuServe network nodes are quite smart and have large input buffers,
and CompuServe may even move some or all of file transfer protocol handling
off the mainframes and into the nodes.

------------------------------

Date: Mon 3 Nov 86 22:40:40-EST
From: Russ Forster <[e-mail]>
Subject: CompuServe and Kermit
Keywords: CompuServe

I have used compu-serv rather extensivly in the last little while and have
experenced a number of problems in downloading files.  This is partly due to
going through DATAPAC here in the 'Great White North'.  CIS does not support
KERMIT at all and this can (and does) cause problems for us AMIGA owners.
XMODEM pads out to 256 characters per line, so if the line is less, it gets
filled with nulls.  Because the AMIGA is multi- tasking, It must know the
length of the file to find a place for it in memory.  We AMIGAns have
developed a number of Chomping programs to eat up the null's that XMODEM
insists on putting in.

The bottom line is yes Yes YES!!!! I would love to see KERMIT infiltrate
these networks like CIS and PEOPLE LINK.  Us AMIGIANS need it.

                    /Russ

ps.  This was in response to the latest KERMIT digest.

Disclaimer ..
The above commnets are my own not my employeers.

------------------------------

Date: Thu, 6 Nov 86 18:08:14 pst
From: [e-mail] (Glenn Thobe)
Subject: VAX/VMS Kermit to PROCOMM
Keywords: VAX/VMS Kermit, PROCOMM

In reference to Lawrence Clark's communication (IKD v.5, no.15), I have had
difficulty transferring files from VAX/VMS Kermit-32 v.3.2.077 to Procomm
v.2.4 on an IBM-PC (that's the other direction from what L.C.  was trying to
do).  The transfer of a text file was successful but very slow.  The VAX
would send out a data packet immediately upon receipt of an ack and wait,
time out, send a repeat of the data packet, wait some more, finally receive
the ack, etc.  This is just one experience, not a controlled experiment, so
I wouldn't hasten to make any hard and fast judgements from it.

-Glenn Thobe
[e-mail] (arpa)

[Ed. - See the following messages...]

------------------------------

Date: Fri, 7 Nov 86 16:42:15 est
From: Robert Montante <seismo!iuvax![e-mail]>
Subject: PROCOMM's Kermit and the VAX/VMS
Keywords: PROCOMM, VAX/VMS

In response to Lawrence Clarke's question about ProComm's Kermit and VAX/VMS
Kermit:  I am using ProComm v2.42 for Kermit transfers quite successfully, to
and from a VAX/VMS V4.2 with Kermit-32 (and also with ckermit running under
UNIX on another VAX).  I have noticed that both ProComm and the host Kermits
make some default-setting assumptions that are incompatible (and occasionally
inexplicable).  Something like the "block check type" may need to be adjusted
locally or on the host (or both); this was necessary to get me going on UNIX.
    ...Bob Montante...

 Datclaimer: "[Usual disclaimer: I have no opinion, therefore I don't exist .]"
Disclaimer: I opine, therefore I am.  My employer, however, is a figment.

RAMontante
Computer Science                "Have you hugged ME today?"
Indiana University

[Ed. - Block check type is something that two Kermit programs are supposed
to negotiate between themselves.  It's possible that ProComm isn't doing
this right.]

------------------------------

Date: Wed, 5 Nov 86 14:13:09 est
From: phri!dvm![e-mail] (Frank Wortner)
Subject: PROCOMM Kermit File Transfer Problems
Keywords: PROCOMM

I noticed the last Kermit Digest had a note from Lawrence Clarke about the
difficulty getting PROCOMM and Kermit to speak to eachother.  I've had this
problem also.  File transfers were OK when MSKERMIT 2.29 talked to C-Kermit
4C(58) on the VAX ( an 11/780 running DEC Ultrix ), but when PROCOMM 2.42
took over, the Kermit transfers simply stopped working.

All was not lost, however, since I discovered that if I changed some of
PROCOMM's line settings, everything worked again.  I used the Line-Settings
menu (Alt-P) to set the parity to space, and Kermit then happily resumed
shipping files.  I don't know how or why this worked, but if anyone out
there wants to use PROCOMM to talk to Kermit, experimenting with parity
bit settings is worth a shot.

                            Frank Wortner
                        UUCP: [e-mail]
                      (... allegra!phri!orville!frank )

------------------------------

Date: Tue, 4 Nov 86 08:58:17 EST
From: rmcqueen (Robert C McQueen) @ sitvxb
Subject: Kermit-32 and PROCOMM
Keywords: Kermit-32, PROCOMM

In response to Lawrence Clarke in the Info-Kermit Digest V5 #15:

Try using at least version 3.2 of Kermit-32 to see if the problem still
exists that and PROCOMM.  We have fixed lots of random problems along the
way and could have resolved this problem.

Bob

------------------------------

Date: Tue, 4 Nov 86 12:16:52 pst
From: [e-mail] (Rex Black)
Subject: How to Transfer Binary from UNIX to VMS?
Keywords: C-Kermit, VAX/VMS Kermit, Binary Files

My advice is to archive the file (since that changes format) and try that.
If that fails, you know that it is NOT the data format which is tripping up
the machine, but rather some form of hardware/communications problem between
DEC and Pyramid.

It's always a good idea to isolate your bug.

    Rex

------------------------------

Date: Tue, 11 Nov 86 23:03:16 est
From: Bob Sutterfield <[e-mail]>
Subject: VAX/VMS & Kermit
Keywords: VAX/VMS Kermit

In article <[e-mail]> [e-mail] (Brad Banko) writes:
>Kermit dogs our VMS system down... whenever one of us uses kermit
>to communicate over the modem, it really dogs our 11/750 down... it is
>particularly bad when typing long messages or kermitting files... has anybody
>else had this type of problem, and is there an easy fix?
>    I don't know if the problem is with VMS, or Kermit...  Thanks.

    Yes, I've noted that problem on a 750 running VMS.  Even at
1200 bps on a DMF-32 modem port, filling a screen (like by cat(1)ing a
text file on the remote system) can grab over 90% of an otherwise-busy
CPU (thus saith MONITOR).  Curiously enough, unlike your report, I
only saw the problem while CONNECTed to a remote system, never while
SENDing or GETting a file to/from a remote server.

    The clue to the cause is to look (still via MONITOR) at all
the buffered I/O that's going on in your process.  Think about all
those characters passing through the port drivers, the class drivers,
etc. to get to your screen, generating high-priority interrupts as
they go.  It's pretty gruesome.

    I tried various permutations of the SYSGEN parameters
concerning silo and DMA and typeahead buffer sizes, particularly the
one that controls when the minimum-size thing that triggers a switch
to "DMA mode" from character-by-character interrupt mode - I think
it's TTY_DMASIZE (I no longer have any connection with VMS systems, so
my memory is foggy of its name).  Nothing seemed to help me.

    It seems to me that the only way to improve this problem would
be to make Kermit much more intelligent about VMS guts, in order to
bypass some of the layers that characters have to go through.  This,
of course, would make it much less portable, even to new versions of
VMS, as the terminal driver is wont to change occasionally.  Like,
apparently, with new major releases of the operating system.

------------------------------

Date: Wed 5 Nov 86 16:58:31-EST
From: Christine M Gianone <[e-mail]>
Subject: C-Kermit and Xenix 3.0
Keywords: C-Kermit, Xenix

Has anyone has any experience running C-Kermit under the Xenix operating
system, version 3.0A, on the AT?  If you got it to work, what "make" options
did you use, or what modifications did you make to the source?  We're
getting a lot of questions about this.

------------------------------

Date: Wed, 5 Nov 86 13:59:29 est
From: munnari!latcs1.oz![e-mail] (Philip Lee)
Subject: Re: FIDO - UNIX Kermit problem
Keywords: FIDO, C-Kermit, UNIX Kermit

Found the problem, FIDO kermit allways sends out file with 8th bit quoting
(with '&' prefix), even when you come in with 8 bits and no parity!  I
should've guessed it when the received binary file is bigger than the
original. I've been told that it would be fixed in the next version of FIDO,
the one I've been connected to runs on ver 11W.

Philip P.H. Lee,
La Trobe University,
Dept. of Computer Science,    PHONE:    [phone] ext 2902
Bundoora,            A/CSnet:[e-mail]
Victoria 3083,            ARPA:    [e-mail]
AUSTRALIA.    UUCP:{seismo,hplabs,mcvax,ukc,nttlab}!munnari!latcs1.oz!philip

[Ed. - There have been many complaints from people downloading ARC files
from FIDO BBS's with Kermit that the files cannot be successfully unARC'd.
This could be the problem!  A cursory examination of a packet log shows
that 8-bit quoting was not negotiated, but was used by FIDO anyway, so
that the resulting downloaded file was filled with extraneous & characters.
We'll try to check this in more detail.]

------------------------------

Date: Fri, 7 Nov 86 08:07 ???
From: RLH <[e-mail]>
Subject: Rainbow MSKERMIT initialization
Keywords: MS-DOS Kermit, DEC Rainbow

Does anyone have a good .INI initialization file for the MS-DOS version of
Kermit on a DEC Rainbow?

What I want to do is to get the terminal emulation to look as much like a
VT200 series terminal as I can - particularly as far as having the function
keys transmit the right sequences so that I use the key definition
facilities of VAX/VMS and the TPU editor.

If you have a .INI that does a good job of this, would you send me a copy?

    thanks,

    Bob Haar

[Ed. - Try KER:MSIRB2.INI on CU20B (MSIRB2 INI from KERMSRV). You're welcome.]

------------------------------

End of Info-Kermit Digest
*************************
-------
21-Nov-86 16:34:02-EST,15396;000000000000
Mail-From: SY.CHRISTINE created at 21-Nov-86 16:32:41
Date: Fri 21 Nov 86 16:32:40-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #17
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 21 Nov 1986       Volume 5 : Number 17

Today's Topics:
               WISCVM Arpa/BITNET Mail Relay Congestion
                            HP9845 Kermit
             Okstate Kermit Service Available Once Again
                      Re: C-Kermit and Xenix 3.0
                           FIDO and Kermit
                         Error in CP4KER.DOC
                             Amiga kermit
                           C-Kermit 4D(060)
                 Help needed on Kermit-32 and X25/X29
                        Kermit and CompuServe

----------------------------------------------------------------------

Date: 14 November 86 18:34 EST
From: Larry Landweber  <LHL @ WISCVM.WISC.EDU>
Subject: WISCVM Arpa/BITNET Mail Relay Congestion
Keywords: BITNET, Arpanet

Because of Arpanet congestion problems, our WISCVM mail relay is unable to
keep up with the quantity of mail sent to it for forwarding. While the
problem is particularly acute in the Bitnet to Arpanet direction, the level
of traffic in both directions is a problem.  A large part of this traffic
results from mailing lists.  Furthermore, while we are usually only sent a
single copy of a list mailing, the recipient list is often very long.  A
single message may require the sending of over a hundred copies. This is a
problem for two reasons... Arpanet congesion makes it difficult at times to
establish and keep TCP connections and such connections are slow; second,
the implementation of the gateway at present makes multiple copies for
forwarding (a poor design choice that is being worked on).  At present, the
first problem is far [more] significant.

To alleviate the problems cited above and enable us to provide a reasonable
level of service, we are asking Arpanet list maintainers to provide list
exploders on Bitnet and vice versa.  Your cooperation will be very much
appreciated. Note that in a about a month we will begin limiting the number
of copies we will relay by putting a limit on the number of recipients in
RCPT TO lines in SMTP and BSMTP.  This limit is likely to be 10.

Gligor Tashkovich <[e-mail]> has agreed to help
coordinate the process of putting maintainers on one net in touch with
relevant people on the other list.

Thanks in advance for your cooperation in this matter.

Larry Landweber

cc: NIC @ SRI-NIC.ARPA   CIC @ SH.CS.NET   INFO @ BITNIC
    PEB @ CERNVM

[Ed. - This is a serious problem.  There is not a lot of duplication in the
Info-Kermit list; only a few hosts appear more than twice (they are
VTVM1 (6 times), CALSTATE (5), BROWNVM (3), DACTH51 (3), DBNRHRZ1 (3),
UMKCVAX1 (3), and UREGINA1 (3)).  If the subscribers at those hosts could
arrange to combine themselves into a local redistribution list, that would
be appreciated.  Meanwhile, we'll try to work out some arrangement so that
mail to BITNET subsribers won't be arbitrarily discarded.  But success can't
be promised.]

------------------------------

Date: Fri 21 Nov 86 12:00:35-EST
From: Christine M Gianone <[e-mail]>
Subject: HP9845 Kermit
Keywords: HP9845 Kermit

In Info-Kermit Digest V5 #16 HP9845 Kermit was announced to be in the file
KER:HP9845.*.  Accidentally, the files were placed in KER:HP9KER.* This has
been corrected.  Sorry for any inconvenience.

------------------------------

Date: Tue, 18 Nov 86 16:05:28 -0600
From: Mark Vasoll <[e-mail]>
Subject: Okstate Kermit Service Available Once Again
Keywords: Okstate

I have reenabled the dial-in modem and about 45 seconds after doing that
someone had logged into uucpker and started grabbing stuff.  Looks like
there is still plenty of demand!

Cheers,
Mark

------------------------------

Date: 13 November 1986 0810-PST (Thursday)
From: [e-mail] (Larry Bierma)
Subject: Re: C-Kermit and Xenix 3.0
Keywords: C-Kermit, Xenix

I got kermit running on an AT running IBM's XENIX 1.0 (which is supposedly
the same as Microsoft XENIX 3.0) with no problems.  Unfortunatly I don't
remember what "make" option I used and I no longer have the machine.
If no one else gives you better information let me know and I'll get
access to the machine and check what I did.

  Larry        ARPA: [e-mail]
        UUCP: {decvax,ucbvax,ihnp4}!sdcsvax!sdics!nprdc!bierma
        PSTN: [phone]

[Ed. - Well, there is some feedback.  Does anyone have more information?]

------------------------------

Date: Fri, 14 Nov 86 13:52:40 CST
From: [e-mail] (John Plocher)
Subject: FIDO and Kermit
Keywords: FIDO, Kermit

The Fido kermit problem is deeper than just 8 bit quoting...
  I downloaded an ARC file and ran a simple filter on it to
  expand 8 bit quoting...  BOMB!

  The file became much shorter than the original and would not unarc.
Is this because the 8bit decoding can't be done outside of the kermit
state machine?  I'm confused as to how to fix this problem:

    setting my kermit to use a 7 bit line with 8 bit quoting
    does NOT seem to get rid of the problem!

"Never trust an idea you get sitting down" - Nietzche
            {harvard,seismo}!uwvax!uwmacc!uwhsms!plocher        (work)
John Plocher    {harvard,seismo}!uwvax!puff!plocher                 (school)
            decvax!encore!vaxine!spark!121!0!John_Plocher       (FidoNet)

------------------------------

Date: Mon, 17 Nov 86 11:35 N
From: <[e-mail]>
Subject: Error in CP4KER.DOC
Keywords: CP/M Kermit

Dear Kermit-eers,

There are two tiny little errors in the file CP4KER.DOC.

A small 8080-assembler program is listed which should downline-load the
Kermit-hex-files from a DEC20-system to a CP/M-microcomputer.

line 015A shows:        jm 170          This should be: jc 170
line 0167 shows:        jm 170          This should be: jc 170

Change the above lines and it really works!

A happy Kermit-eer,

                .KeesdeGroot    (DEGROOT@HWALHW50)

[Ed. - Thanks for the bug report and the fix.  This message has been added
to KER:CP4KER.BWR.  This whole program was replaced in the second revision of
the sixth edition of the Kermit User Guide but this file has not yet been
updated.]

------------------------------

Date: Mon, 17 Nov 86 21:55 EST
From: <[e-mail]>
Subject: Amiga kermit
Keywords: Amiga Kermit
Cross-Ref: Commodore Amiga (see also Amiga Kermit)

   This may or may not be of interest to anyone there. I obtained what I
believe is the latest version of Amiga Kermit from the Columbia Kermit
server a couple of months back. (I used the earlier one before that.) This
newer version is rather nice, except that it doesn't seem to be able to
generate even parity. The old version worked fine, this newer one does not
seem to generate even parity (at least, not the even parity that the local
IBM 3081 likes) under release 1.1 of AmigaDos. I've tried it with the 1.2
beta serial.device, but no luck. I haven't made any attempt at fixing it; I
am NOT a C programmer (yet?).
                                                        Rick Pim

------------------------------

Date: Tue, 18 Nov 86 02:01 EST
From: Kuryan Thomas <[e-mail]>
Subject: C-Kermit 4D(060)
Keywords: C-Kermit

[Ed. - The latest version of C-Kermit is 4D(061)]

This is Kuryan Thomas at Virginia Tech Physics department.  Some months ago
I reported a problem with C-Kermit running on my AT&T PC6300PLUS under
UNIX System V.  I couldn't get the dial command to work -- I would always
get an error like "Can't hang up the phone" or "Communications Disconnect."

After some time as a UNIX administrator and programmer, I've managed to
debug the problem.  In function tthang() in ckutio.c, the phone is hung up
by using ioctl() to set the baud rate on the port to 0.  This, I believe,
is standard UNIX procedure.  On my particular system, though, this operation
always fails with ioctl() signalling an error (-1) and setting errno to
ENXIO (No such device or address).  This is definitely a bug, because the
phone IS correctly hung up (DTR line is dropped).  The fix is to simply
ignore error returns from the hang-up ioctl() in tthang() (that's the first
ioctl() call in tthang()).

[Ed. - Since this error might be significant on other systems, maybe the
best thing would be to report any error returned by this ioctl(), but then
proceed anyway.]

I uncovered a few other problems, all of which I found (rather kludgy) fixes
for.  First, the dial command cannot work unless carrier detect is asserted
on the terminal line.  My modem, a Prometheus 1200, refuses to accept the
commands.  (Or my tty port refuses to behave correctly, I'm not sure which.)
The fix is to strap CD high with the DIP switches on the bottom panel.

[Ed. - This sounds like another problem with your system.  Obviously, CD
will not be asserted until the phone call is completed and carrier is
detected.  The system should not require CD to be on while dialing.  Strapping
CD high, of course, prevents Kermit or any other program from telling when
carrier really drops.]

Next, my computer, like the 3BX series, expects its lock files in the
directory /usr/spool/locks, rather than /usr/spool/uucp.  The problem is
that the former, unlike the latter, is writable only by the uid uucp.
It might appear that the solution is to make ckermit owned by uucp and
set the set-uid bit, but ckermit uses the access() system call to check
write access to the lock directory.  access() uses REAL uid's to check
access, not effective uid's.  Therefore, set-uid is ineffective.  The only
fix I could think of was to remove the lines in look4lk() that report an
error if access() says there's no write permission in the lock directory.
If the set-uid trick is used, all is well and the lock file is created.
If you forget to set the set-uid bit or something else goes wrong, the
attempt to creat() the lock file fails with an error like "Couldn't gain
exclusive access of lock file" or words to that effect.

[Ed. - It seems like every variant of Unix on every different kind of
system puts the "lock files" in different places.  And what's more, each
installation sets the permissions differently.  Perhaps the next release
of UNIX Kermit will make the lock file location a makefile option, to
emphasize that it has given up all hope of knowing where to find it.]

Finally, the problem of having Kermit hang up the phone when you return to
the shell (thus terminating the conversation) can be solved by strapping
DTR high with the modem's DIP switches.  Ckermit can no longer hang up the
phone correctly, but if you often return to your local shell in the middle
of a remote session, the convenience is worth it.  And, of course, the
remote end is usually able to hang up the phone correctly when you are done
with it.

[Ed. - Or you can push from Kermit to an inferior shell, leaving the connection
active and all Kermit settings intact -- use the "!"  command at prompt level.
A "push" escape will probably also be added to the 'connect' command in the
next release.  Setting the modem's "ignore DTR" switch prevents the modem from
noticing when your system crashes, and terminating the connection, resulting in
potentially big phone bills if this happens during unattended Kermit or UUCP
operation.]

Hope this will be of help to someone.

------------------------------

Date: Wed, 19 Nov 86 15:32 GMT
From: Jan Peter Stuart <[e-mail]-M> 19-NOV-1986 15:37
Subject: Help needed on Kermit-32 and X25/X29
Keywords: Kermit-32

I was dissappointed to find after my note in newsletter 92, that possibly
no one else uses Kermit-32 on a vax at the end of an X25 line.

So far I have been singularly unsuccessful in getting anything to
function on the outside world!

The problem is now a bit clearer at least. Kermit-32 was designed
to use a vax terminal line. I have no terminal lines to the outside
world, only an x25 connexion that terminates at a DEUNNA board in the
vax. Thus no hardware PAD!

I can certainly establish connections thru the vax X25 without kermit
but does anyone know how to tell kermit-32 to set up an x25/x29 type
of call ????

If I find no other uk users in this position, is there any way I can
request help from the source ? (USA) ?

Yours hopefully,

Jan Stuart.

also direct at uk.ac.rl.gm

------------------------------

Date: Thu, 20 Nov 86 09:18:39 PST
From: Steve Walton <ametek![e-mail]>
Subject: Kermit and CompuServe
Keywords: CompuServe

Adding fuel to the fire...

    I have had the experience of using Kermit over Telenet.  It was not
pleasant.  The remote system was the WELL, a 4.2BSD Vax 750 in Berkeley, and
the local system was my Amiga.  Version 4D(061) of C-Kermit was used at the
WELL end, and a PD terminal emulator at the Amiga end.  Efficiency was 25%.
(Has anyone ever seen C Kermit do better than 65% efficiency?)  I finally
gave up on Kermit, and am now using the 1024-byte-packet version of XMODEM
for WELL communication.

    Compuserve "B" protocol uses 511-byte packets, which seem to work
fine over Tymnet, Telenet, and the CompuServe net.  PeopleLink offers XMODEM
and a new one called "Windowed XMODEM" (!) to get around the delay problems.
When I first arrived on PeopleLink, I suggested windowed Kermit to them as a
new protocol.  I haven't asked why they didn't adopt it, but suspect it was
because windowed Kermit is basically nonexistent (except possibly for some
alpha test versions and the IBM PC-only one from the Source).  So is
windowed XMODEM, but XMODEM is much closer to universal than Kermit, and is
easily modified to add the window support.  After all, we're talking a
strict 8-bit asynch-to-asynch one file at a time protocol.

    I love the little green guy, and use it whenever I have a direct
connect line between two machines.  But it's a big lose on the
packet-switched nets, and when you're paying by the minute, that's
important.

Stephen Walton            ARPA:    ametek![e-mail]
Ametek Computer Research Div.    BITNET:    walton@caltech
610 N. Santa Anita Ave.        UUCP:    ...!ucbvax!sun!megatest!ametek!walton
Arcadia, CA 91006 USA
818-445-6811

[Ed. - Windowed Xmodem is not exactly what you might think -- Since
Xmodem does not have replies (ACKs and NAKs) that are in packet form
so that they can indicate WHICH packet they are ACKing or NAKing,
true sliding windows cannot be supported by any of the MODEM family.
What Windowed Xmodem does is cancel the entire file transfer if any
error is detected.  So it's fast when it works, but "infinitely slow"
when it doesn't.  C-Kermit will eventually have support for both long
packets and sliding windows.]

------------------------------

End of Info-Kermit Digest
*************************
-------
 8-Dec-86 16:40:34-EST,19107;000000000000
Mail-From: SY.CHRISTINE created at  8-Dec-86 16:30:14
Date: Mon 8 Dec 86 16:30:14-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #18
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Mon, 8 Dec 1986       Volume 5 : Number 18

Today's Topics:

                      PERKIN-ELMER 7000 Series Kermit
                         NIH TSO Kermit Version 1.0
                            BITNET Distribution
                          More on FIDO and Kermit
                       SCO Sys V/286 Xenix Kermit 4C
               Use of Unix Kermit on Packet Switched Network
                       VAX/VMS Kermit-32 and X25/X29
                 Micro_Vax II problem with modem interface
                            HP9845 BASIC Kermit
                Kermit for RSX-11/M v3.2 and/or Hyperion PC?
                          Problem with P-E Kermit?
                   PR1ME Kermit with connect capability?

----------------------------------------------------------------------

Date: Mon 8 Dec 86 11:32:34-EST
From: Chris Lent <[e-mail]>
Subject: PERKIN-ELMER 7000 Series Kermit
Keywords: Perkin-Elmer, Concurrent

I've gotten a Kermit for the Perkin-Elmer 7000 Series computers which are
IDRIS based.  It's loosely based on the old C-Kermit from the old Protocol
manual. It has Binary file (8-bit and &-quoting), Repeat quoting and server
mode (GET,SEND,and FINISH).  It has no connect mode, as the 7000 series
comes with the cu(1) command which does the same thing.

I didn't create this version (Dan Eisner of Perkin-Elmer did), but I did
create a bootstrap document. I translated the bootstrap programs so that I'm
using an existing format for encoding the binary files.  For its size it's
one of the most solid Kermit's I've seen so far.

Chris Lent
"phri!cooper!chris"@NYU.ARPA
[e-mail]

------------------------------

Date: Fri, 05 Dec 86  23:33:18 EST
From: "Roger Fajman" <RAF@NIHCU>
Subject: New NIH TSO Kermit Version 1.0
Keywords: TSO Kermit, IBM Mainframe

I would like to announce the availability of the NIH TSO Kermit Version 1.0.
The following summarizes its capabilities:

NIH TSO Kermit Capabilities At a Glance:

       Local operation:  No
       Remote operation:  Yes
       Transfers text files:  Yes
       Transfers binary files:  Yes
       Wildcard send:  Yes
       XX/XY interruption:  Yes
       Filename collision avoidance:  No
       Timeouts:  Yes
       8th-bit prefixing:  Yes
       Repeat character compression:  Yes
       Alternate block check types:  Yes
       Communication settings:  No
       Transmit BREAK:  No
       IBM mainframe communication:  Yes
       Transaction logging:  No
       Session logging:  No
       Debug logging:  Yes
       Raw transmit:  No
       Login scripts: No
       Act as server:  Yes
       Talk to server: No
       Advanced commands for servers:  No
       Local file management:  Yes
       Command/init files:  Yes
       Handle file attributes:  No

I am sending a tape to Frank da Cruz at Columbia so that NIH TSO Kermit can
be included on the regular Columbia distribution tapes.  When the files are
available on KERMSRV, ask for TSNKER.TXT to see the installation
instructions.  There are 8 required files, plus 13 more if you want the
source.

NIH TSO Kermit may also be obtained directly from NIH by sending a letter of
request and a tape to the following address:

   Joseph D. Naughton
   Chief, Computer Center
   National Institutes of Health
   Building 12, Room 2244
   Bethesda, MD 20892

There is no charge.

The NIH version of TSO Kermit is an extensive modification and rewrite of
the University of Chicago TSO Kermit, which in turn was based on an early
CMS Kermit developed at Columbia University.  The external design was done
by Roger Fajman and Dale Wright.  The internal design and programming was
done by Dale Wright.

------------------------------

Date: Wed, 03 Dec 86 13:02:24 EST
From: Harold C Pritchett <HAROLD@uga>
Subject: BITNET Distribution
Keywords: BITNET

Please add:

      [e-mail]

to your distribution list.  This is a BITNET List server which will allow
BITNET users to subscribe and receive copys of your list without having to
transverse the WISCVM gateway.  After this is done, you might want to
announce the availablility of this list as an alternative method for your
BITNET subscribers to receive this list.

For a BITNET user to subscribe to this list, they can issue the command

     TELL LISTSERV AT UGA SUB I-KERMIT Users Name  (from VM/370)

     SEND LISTSERV@UGA SUB I-KERMIT Users Name     (from VAX/VMS)

All other users can send RFC-822 mail to LISTSERV at UGA where the first
of the message text (the line after the blank delimiter line) is

     SUB I-KERMIT Users Name

[Ed. - Thanks.  BITNET subscribers might want to try this new service and if
it works okay, they may want to switch from Info-Kermit at CU20B to
I-KERMIT, in order to relieve congestion at the WISCVM gateway.]

------------------------------

Date: 1986 Nov 21   22:14 EST
From: (John F. Chandler) <PEPMNT@CFAAMP>
Subject: More on FIDO and Kermit
Keywords: FIDO

It should be obvious that if the two Kermits mis-negotiate the state of
8-bit quoting there can be irretrievable garblings.  In particular, assuming
the sender thinks "&" is the 8-bit quote, all occurences of "&" get sent as
"#&", which is garbage if the receiver thinks there is no 8-bit quoting.
The "#&" is probably converted to "f", but it could depend on the
implementation!  If it, in fact, comes out as "&", then a post-reception
filter would try to merge it with the following character anyway.  If there
is garbling even when the two Kermits claim to agree on the quoting state,
it might be a good idea to send a short file with a few mixed 7- and 8-bit
byte values.  Then you'll have a clue as to what's happening.

[Ed. - Actually, translation of "#&" to "f" is improper, because "&" is not
in the range of encoded control characters.  The "#" operator should
"controllify" the following character only if it is in the range 63-95
(decimal), otherwise it means "take the following character literally".  But
you're right, there are some Kermit implementations that do not follow this
rule.]

------------------------------

Date: Sat 29 Nov 86 21:08:53-MST
From: Mike Niswonger <[e-mail]>
Subject: SCO Sys V/286 Xenix Kermit 4C
Keywords: Xenix

Help!!,
    There seems to have been a lot of hassles stirred up about what is
necessary to run which version of C-Kermit on which version of Xenix.  I
would like to compile a full list of users who have Kermit up and running on
a Xenix system.  Please include the following information:

  User name and net address
  Hardware: manufacturer, model, CPU (8086, 80286, etc), configuration
  SPECIFIC Xenix version including:
  . Source (IBM, Microsoft, SCO, Tandy)
  . Sys III, Sys V, V7, "Sys V with Berkeley features", etc.
  . Xenix release version (very important)
  . Development system (compiler) version
  Edit level of C-Kermit used (should be 4D(061))
  Specific fixes, patches, workarounds, actual flags used during compilation
  (please don't just say "see makefile")

I realize that this may require some digging, but please help out.  I have
been working (on and off) trying to bring up Kermit on a friend's SCO Xenix
286 / Sys V AT clone for almost a year, with little success.  From some of
the notes that I have seen, I am not alone.

A compilation of the results will be submitted to CU20B when complete.

            -- Mike Niswonger,
               [e-mail]

[Ed. - As we've noted in previous postings, "Xenix" is almost a meaningless
label, except that it means a operating systems that resembles one or more
versions of Unix.  Thus, it has proven next to impossible for us to tell
people how to bring up C-Kermit under "Xenix".  If we had a list of all the
different incarnations of Xenix along with the parameters that Mike has
listed, it would help a lot.]

------------------------------

Date: Mon, 24 Nov 86 12:49:10 WET
From: Bruce Wilford { 01 387 7050 x 3691 } <[e-mail]>
Subject: Use of Unix Kermit on Packet Switched Network
Keywords: Unix Kermit, C-Kermit, X.25

People connect to our machine from all over the UK via an X25 network.  Some
have to pay for this and therefore need to use message (line) mode.  If they
are in line mode the characters will not be forwarded until the <CR> is
typed at the end.  This would ruin the effect of command completion, with
ESC and things like ? being picked up immediately.

[Ed. - First, note that you do not HAVE to use command completion, ESC, or ?
when talking to C-Kermit.  You can use it as a traditional Unix command,
with command-line options, as documented in the manual (or type "kermit -h"
for a brief summary).  During interactive use, if you configure your PAD to
use only CR as the data forwarding character (X.3 parameter 3, value 3),
then you will simply not have the special features available to you at your
terminal; you can still type the commands.  You can use X.3 PAD commands to
change your data forwarding characters; for instance "SET? 3:14" will allow
forwarding on CR, ESC, DEL and a few other control characters, but not ^U or
"?", which are also used by the interactive command parser.  "SET? 3:72" will
cause forwarding on any control character.  There's no X.3 selector for "?".
You can also configure the PAD to let you do local editing when in line
mode (X.3 parameters 15-18).  During file transfer, Unix Kermit puts the
communication line into "rawmode" which, in some Unix implementations,
causes the Unix system to tell the network to do character-at-a-time i/o,
which means one character per packet, which is unnecessarily expensive when
you're paying by the packet.  Future releases of Unix Kermit may provide
some kind of workaround for this.]

------------------------------

Date: Sun, 23 Nov 86 16:47:10 EST
From: [e-mail]
Subject: VAX/VMS Kermit-32 and X25/X29
Keywords: VMS Kermit, X.25

In Info-Kermit dgest V5 #14, Jan Peter Stuart <[e-mail]-M>
asked about using Kermit-32 to connect out through an X.25 PSI interface to
the outside world.

Unfortunately, I am in the same situation.  However, since our users can
usually loop around in our network (Merit), and come back in to use it as a
remote kermit, our need is not overly pressing.  There are other VAX/VMS
systems attached through X.25 interfaces to Merit, though, and any real,
software solution would bre greatly appreciated.

    Richard S. Conto
    University of Michigan Computing Center
    1075 Beal Ave.
    Ann Arbor, Mi. 48109, USA

    ARPA/Internet:    [e-mail]

[Ed. - Bob McQueen, the author of VMS Kermit, says that he'd be willing to
look into adding X.25/29 PSI support, but (1) he doesn't have an X.25 PSI
system at his site, and (2) he doesn't have any documentation on the
interface.  If someone can provide the details of the VAX/VMS X.25 interface
(does it look like a normal terminal? Do you send special X.28 control
sequences to the PAD? etc) and would be willing to test the results, please
contact Bob as "rmcqueen%sitvxb.CCNET"@CU20B, or through Info-Kermit.
Results cannot be promised.]

------------------------------

Date: 25 Nov 1986 12:07-EST
From: DEC PC BBoard <[e-mail]>
Subject: Micro_Vax II problem with modem interface
Keywords: VMS Kermit

            We have recently got a Microvax II and are facing some problems
in connecting the MUX ports to modem. I am here a faculty member in
Electrical Engineering at North Dakota State University Fargo, North Dakota,
USA.
            The problem is as follows:

1. When the prot, e.g. TXA0 is defined as MODEM port, using SET TERM
command, after a user logs in through that port, he is logged out in about
30 seconds with a message, SYS - E - HANGUP. If the port is not defined as a
modem, by the command SET TERM/NOMODEM then this hangup does not occur, but
if the modem is switched off without the user having logged off, the user is
not logged out and anybody who comes in through that port is in effect
working as the 'old' user. This is a big security risk Did you come across
any such problem. We are here using a PACKSnetwork which uses Gandolf
modems. The operating system is VMS 4.4 and the port controllers are DHV-11.

                 I shall be very thankful for your suggestions.

                                  K.Sankara Rao

[Ed. - Reply from Bob McQueen: "This person is talking about setting VMS
parameters on his terminal lines and is doing it incorrectly from what I read.
I'd guess from the message that the problem he is having is that the device
requires DTR to be raised and the modem he is using doesn't (or the terminal
cable doesn't have the line)."  We get questions like this all the time.
What we need is a quick guide to VMS DCL parameters for using Kermit in
various situations -- direct connect, dialin, dialout, etc.  We'll try to
come up with something like this.]

------------------------------

From: uw-apl!apl-em![e-mail]
Date: Thu, 20 Nov 86 09:46:29 pst
Subject: HP9845 BASIC Kermit
Keywords: HP9845 Kermit, BASIC Kermit

Our HP9845's do not recognize the following:

Mass Storage Unit Specifier ":Q"
CCOM, CMODEL, CCONNECT, CDISCONNECT, CCONTROL, CSTAT, CWRITE, CREAD
Block if: IF THEN, ELSE, END IF on separate lines
Case selection: SELECT, CASE, END SELECT on separate lines

These keywords are in fact in ROMs we don't own.  According to our HP
service engineer:

    > Mass Storage Unit Specifier ":Q"

    This is the msus for the "HP7908" disc.

    > CCOM, CMODEL, CCONNECT, CDISCONNECT, CCONTROL, CSTAT, CWRITE, CREAD

    These commands are found in the Datacomm ROM, which can only  be used
    with the HP98046 Datacomm interface.

    > Block if: IF THEN, ELSE, END IF on separate lines
    > Case selection: SELECT, CASE, END SELECT on separate lines

    These are found in the Structured Programming ROM, along with many
    other useful commands like XREF and INDENT.

Since we don't have the above and have no plans to purchase I am considering
redoing the code a little to use the more common I/O ROM and HP98036 serial
interface.  I already have written a terminal emulator which performs quite
well (keeps up at 1200 bps) so I don't forsee any great difficulty.  On the
down side I cannot say when I can get to it.

In any case there should be some words in the HP9845 kermit distribution
about the above ROMs and I/O cards being required.  I don't think the mass
storage unit specifier (MSUS) problem is serious -- people can change that
to their usual MSUS.

[Ed. - HP has such a variety of products, and so many of them come with
BASIC as the only standard (or only, period) programming language, that it
would be very desirable to have a relatively portable HP-BASIC Kermit, if
indeed there is some subset of the language that is consistent across the HP
line, and which does not require special ROMs and options (Is there???).
Meanwhile, your message has been added to the "beware file" for this version
of Kermit.]

------------------------------

Date: Mon, 24 Nov 86 07:26:18 EST
From: Noah Diesbourg <IND@WINDSOR1>
Subject: Kermit for RSX-11/M v3.2 and/or Hyperion PC?
Keywords: Kermit-11, Hyperion PC

Is anyone running Kermit on a

    PDP 11/34 with RSX 11M ver 3.2
             or a
    Hyperion PC?

[Ed. - According to K11INS.DOC, the minimum version of RSX that Kermit-11
can run under is 4.1.  The author's advice to people in this situation is to
upgrade.  It is recognized, however, that there are many old PDP-11 systems
out there that can't be easily upgraded.  There are rumors of bare-bones
remote-only Kermit programs written in Fortran for earlier releases of RSX,
but none of these programs has yet surfaced.  If anyone wants to send one
in, it would be appreciated.  The Hyperion is an IBM-incompatible MS-DOS
system, and should be able to run "generic" MS-DOS Kermit.]

------------------------------

Date: Tue, 2 Dec 86 11:39 EST
From: <[e-mail]> (brian nelson)
Subject: Problem with P-E Kermit?
Keywords: Perkin-Elmer Kermit

This was sent to me by someone using kermit dialup access here.
Anyone know about Perkin-Elmer Kermit?

[e-mail]

> From:   DRWHO::KERMIT        2-DEC-1986 11:33
> Submission by:
> Richard J. Zirbes
> [phone]
> U.S. Geological Survey
> BOX 25046 MS 516
> Denver, CO.  80225

> Environment:
>       OS/32 Version 8.1.2 (not 8.2)
>       all perkin.* files in my work area.
> Problem 1:
>       Source compiles fine using d and o compilers, links okay
> however; when trying to start up using KERMIT.INI file I get:
>       SVC ADDRESS ERROR
>              INST @17A92
>      SVC PARAMETER BLOCK
>              AT C770
>       MEMORY FAULT ADDRESS Z39C1
>       TASK PAUSED.

> also; when I use another file such as KINIT.DAT in the command
>              line:  KERMIT KINIT.DAT
>       the results are the same.

> The files KINIT.DAT and KERMIT.INI look like:
> SET PARITY EVEN
> SET PACKET 90
> SET FCHEK OFF
> SET 8BIT OFF
> SET SEOR LF
> SET FILE TEXT
> EXIT

> Problem 2:
> I run kermit without an initializer file and enter the parameters
> defined above interactively and send a file to my ckermit I get
> transmission errors and kermit-co times out.  Ckermit has settings:

> mode:                local
> parity:              even
> duplex:              full
> flow:                xon/xoff
> handshake:           none
> packet start:        1
> packet end:          13
> packet length:       90

> block check type: 1, delay: 5
> 8th bit prefix       '&'

> File Names:          converted
> File Type:           text

> Please contact me with any solutions. Thank you.

------------------------------

Date: Tue, 02 Dec 86 09:07:00 PST
From: jfisher@USGS3-VMS
Subject: PR1ME Kermit with connect capability?
Keywords: Prime Kermit

I am in need of a Kermit implementation for PR1ME machines that can be run
in local mode, 'dialing-out' through a comm. port to another mini Kermit, so
as to transfer files between them.  I spoke to Leslie Spira of The Source,
who said she didn't have one, but she had a vague recollection that somebody
else might have modified her PR1ME Kermit to allow it to connect out. Does
anybody out there have such a beast ?

------------------------------


End of Info-Kermit Digest
*************************
-------
19-Dec-86 12:09:28-EST,18669;000000000000
Mail-From: SY.CHRISTINE created at 19-Dec-86 12:07:37
Date: Fri 19 Dec 86 12:07:37-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V5 #19
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 19 Dec 1986       Volume 5 : Number 19

Today's Topics:

           New Kermit Program for IBM 370 Mainframes with MVS/TSO
                           Kermit-MPX version 2.3
                         Misuse of Okstate services
                             C-Kermit and Xenix
                         C-Kermit on Microport Unix
                  Uploading Macintosh Binhexes with Kermit
                        Bug in Apollo Pascal Kermit
                            Prime kermit connect
                              Kermit and X.25
                         Problem with HP9845 Kermit
                       HCP and HC6 Versions of Kermit
                 Need Fast De-BOOing Program for the Amiga
                            Data General MV2000
                 Kermit 3.1 - An interesting speed problem
                           Symbolics V7.0 Kermit

----------------------------------------------------------------------

Date: Thu 18 Dec 86 15:31:12-EST
From: Frank da Cruz <[e-mail]>
Subject: New Kermit Program for IBM 370 Mainframes with MVS/TSO
Keywords: MVS/TSO Kermit

The new IBM 370-series mainframe MVS/TSO Kermit from the US National
Institutes of Health (NIH), announced in the previous Info-Kermit digest, is
now available in the Kermit distribution areas under the prefix TSN.  There
are 21 files, comprising a total of about 3 megabytes, including three
documentation files and a TSO help file.

The program is written in "ALP", which is a preprocessor for 370 assembly
language developed at NIH.  The ALP preprocessor, also supplied, is written
in PL/I.  For those who do not have PL/I or do not wish to bother with the
source programs, a hexidecimal-encoded object file is provided, along with
an assembler program to decode it into a binary object file; this can be
linked with a tailorable module (written in straight assembler) in which
site dependencies, such as the ASCII/EBCDIC translations, are specified.

Before deciding to transfer all 3 MB from Columbia over a network, first get
the file TSNKER.TXT, which explains which files are which, and then only get
the ones you really need.

Thanks to Roger Fajman at NIH ([e-mail]) for submitting this program
to us.  Roger participated in the design with Dale Wright, who then did the
programming.  The new program has many advanced features over previous TSO
Kermit versions, including server mode, binary file transfer, file
interruption, 8th-bit prefixing, run-length encoding, alternate block check
types, and support for both 3705-style line mode and Series/1-style full
screen emulation.  It is hoped that this new version will render the old
University of Chicago (linemode only, circa July 1984) and University of
Toronto versions (Series/1 only, March 85) obsolete.  Reactions from TSO
sites will be appreciated, in the interest of keeping redundant Kermit
versions at a minimum.  Reactions from users of the Pascal/VS version from
the University of Bern (linemode only, Sept 86) will also be appreciated.

For the present, the Chicago, Toronto, and Bern versions remain available in
the Kermit distribution under the prefixes TSO, TSO, and TS2, respectively.
For the future, there may still be another TSO Kermit program on the horizon, a
result of a cooperative effort among IBM mainframe Kermit sites to develop a
Kermit program that is portable among all IBM 370 mainframe operating systems
(no estimate as to when this will be ready, but IBM mainframe system
programmers who are interested in developments in this area may send mail
to IBM-KERMIT@CU20B or IBM-KERMIT@CUVMA).

------------------------------

Date: Sun 7 Dec 86 22:40:44-MST
From: Mike Niswonger <[e-mail]>
Subject: Kermit-MPX version 2.3
Keywords: Gould, SEL, MPX

    The latest version of Kermit-MPX (GM2) for Gould machines is now
available for you to FTP from my directory at Simtel20.  All files are found
in directory PD:<MISC.GOULD-KERMIT>GM2KERM.*.  This release 2.3 of
Kermit-MPX, which is also being submitted to the Gould User's group library.
                    -- Mike Niswonger

[Ed. - Thanks Mike!  The files are also available through KERMSRV at CUVMA
and on CU20B using FTP (user ANONYMOUS), any password.  These files have
replaced the old KER:GM2*.* and the old files are now in KO:GM2*.*]

------------------------------

Date: Mon, 08 Dec 86 18:50:27 -0600
From: Mark Vasoll <[e-mail]>
Subject: Misuse of Okstate services
Keywords: Okstate, Oklahoma State

Fellow Kermiters,

    It saddens me to inform you all that various people have started to
abuse the UUCP login "uucpker" on Okstate by attempting to use us as a
jumping off point for mail.  While we enjoy providing the home for Kermit
access via UUCP, we have no desire to become a major mail relay point for
various random systems.  To this end, I have had to place a restriction on
our UUCP to not accept the "rmail" command from any system using the uucpker
account.  This will, unfortunately, make it more difficult for people to
report problems to okstate!uucp-support, but there is very little I can do
about it.  Please use the following mail paths when reporting problems with
the Kermit distribution (no phone calls please).

Internet:  [e-mail]
      or:  [e-mail]

UUCP    :  {cbatt, cbosgd, ihnp4, pesnta, rutgers, seismo}!okstate!uucp-support


Mark Vasoll
Computing and Information Sciences       Internet:  [e-mail]
Oklahoma State University                UUCP:  {cbatt, cbosgd, ihnp4, pesnta,
Stillwater, Oklahoma                            rutgers, seismo}!okstate!vasoll

------------------------------

Date: Tue, 9 Dec 86 08:05:48 EST
From: [e-mail]
Subject: C-Kermit and Xenix
Keywords: Xenix, C-Kermit

RE: Info-Kermit Digest V5 #18

I recently put the latest C Kermit (4D(061)) up on a Tandy 16/6000 running
Xenix 3.1 with no problems.  I used the make sys5 command to compile; only
changes needed were to include /sys/typedefs.h for the void identifier found
in one file.  Everything seems to be working ok so far.

------------------------------

Date: Mon, 15 Dec 86 10:17:15 EST
From: es![e-mail]
Subject: C-Kermit on Microport Unix
Keywords: C-Kermit

I just compiled 4D(061) using 'make sys3'. It work right from the start.
Many people have sent in messages about trouble getting Kermit to run on
XENIX. I had used XENIX for a time, but found the include files and compiler
contained many errors and incompatibilities with real system V Unix.

Microport Unix is a full System V for the IBM-AT. Unlike XENIX, it is based
on the current Sys V sources and therefore Kermit was easy to get running.
Those of you using XENIX may want to investigate this new package.

Dan Senie

PS. I am not connected in any way with Microport Systems, ATT, etc.

     UUCP:     ...!harvard!anvil!es!Dan_Senie     (case is important!)
     ARPA:     anvil!es![e-mail]

------------------------------

Date: Sun, 7 Dec 86 11:29:35 pst
From: gould9![e-mail] (Joel West @ Western Software Technology)
Subject: Uploading Macintosh Binhexes with Kermit
Keywords: UNIX, MacKermit, hqx

I've been meaning to send this along for a while, but I wasn't sure anyone
was interested.  A query on INFO-MAC prompted this posting.

It is a UNIX csh script (MACKERM) that I use to upload binhexes using
kermit.  If for a file foo.hqx, it first sends the header (before the
binhex) as 'About foo', then sends foo.hqx.  I use the header to later note
the origin on the final unhexed file.

To make this work, you need to take the first file (usually a short About...
file) manually, selecting the target directory.  Then place your MAC in
server mode, since each 'kermit' command at the UNIX side is a separate
session, and the Mac would otherwise quit file transfer mode.

Oh yeah, it also works on ordinary files, preserves actual names ('FooBar'
instead of 'FOOBAR') and NEVER transfers a directory.  So it's real useful
to type
    mackerm *
place the Mac in server mode, and walk away.

    Joel West
    [e-mail]    ihnp4!gould9!joel

==File =====

    #!/bin/csh
    # by Joel West, ihnp4!gould9!joel, 11/14/86
    # Script to send binhexes and other files
    # Also preserves exact upper/lower case name
    set noglob
    foreach f ($*)
        if (-d $f) continue
        set typ=$f:e
        switch ($typ)
          case hqx:
          case hex:
        set r=$f:r
        set T1=/tmp/kermdat_$$
        set T2=/tmp/kermhqx_$$
        rm -f $T1 $T2
        cat $f | cutat '(This' $T1 $T2
        kermit -s $T1 -a "About $r"
        kermit -s $T2 -a $f
        rm -f $T1 $T2
        breaksw
          default:
        kermit -s $f -a $f
        endsw
    end

== EOF ==

[Ed. - Thanks.  This hint has been added to the Macintosh Kermit .BWR
file, CKMKER.BWR.]

------------------------------

Date: Fri 14 Nov 86 10:34:23-PST
From: Ted Shapin <[e-mail]>
Subject: Bug in Apollo Pascal Kermit
Keywords: Apollo Kermit

We found that the Pascal kermit for the Apollo inserts extra line feeds
every 256 characters if there is no line feed carriage return in the file.
We traced it to the I/O in the Pascal program which can only read 256 byte
lines.

[Ed. - Thanks for the information.  This message is now in the file
KER:APOLLO.BWR.]

------------------------------

Date: Wed 10 Dec 86 10:45:54-PST
From: Bob Larson <[e-mail]>
Subject: Prime kermit connect
Keywords: Prime Kermit

I have a partially working one, based on the old version of prime kermit.
I'm not even sure if I have a complete set of sources for it on tape any
more.  Known bugs include dropping characters in connect mode, problems with
some of the message strings (incorect use of ioa$), and not supporting 2400
baud.  (Writen before prime standardized the "optional" speeds at 2400 and
4800 baud for autobaud.)

I have been considering making improvements to the current prime kermit, with
support for amlc lines among them.

------------------------------

Date: WED, 10 DEC 86 17:17:13 BST
From: CJK @ UK.AC.SALFORD.R-D
Subject: Kermit and X.25
Keywords: C-Kermit, X.25

     Points from infodigest 5/17.  First Steve Walton & Telenet:

     We over this side of the pond are quite used to using Kermit over
X.25 networks (posing as an X.29 terminal).  It works fine, at least in
the micro-mainframe mode, with call originated by the micro.  Efficiency
should not be affected much until the ratio:

        time-through-network / front-end-delay

reaches about 5.  The crucial thing is to set up the X.3 parameters in
the PAD so that the whole Kermit packet gets into a single X.25 packet;
it is bound to be shorter than the 128-byte maximum on X.25.
In general you have to use a transparent-type mode to let the SOH get
through, but there is no need at all to forward on every character (which
simply fills up the X.25 window with single-character X.25 packets).
Provided the EoL is a forwarding character, which it will be if it is CR,
all works fine.  What you actually do depends on the user interface
provided by your PAD.  This is in fact all covered in your book.

     Of course, network congestion can slow things down.  Our X.25s, the
public PSS and private JANET, have maximum time-through-networks of about
0.1 sec in all normal circumstances, so no problem.  But I heard last week
in a different context that the congestion on ACCUNET was so severe that
holding transatlantic calls open was very difficult.  If Telenet is in
the same state, then you've got problems.  But blame the sizing of the
network, not X.25 or Kermit.

     Does CKermit really limit you to 65% of line-speed?  I tested
homegrown Kermits here (at up to about 30Kbaud) and found that, with
data-compression on, I always got better than 100% of linespeed.  If
CKermit is really that slow, is it losing time somewhere that it
needn't?

     Incidentally, switching over to Kuryan Thomas' problems with his
autodialler:  Many UARTs will not receive if DCD is not high (it's a
protection against line-noise).  If you have one of these, and an
autodialler which does not hold up DCD while it is trying to talk
to you, then you have no option but to strap DCD to one of the other
pins, e.g. DSR.

                                Chris Kennington.

------------------------------

Date: 11-DEC-1986 09:47:23
From: [e-mail]
Subject: Problem with HP9845 Kermit
Keywords: HP Kermit
Cross-Ref: Hewlett-Packard Kermit

It's not a bug: it's a problem regarding some assumptions regarding the
machine configuration, which I should have spelt out when I sent it in.

We have explained/apologised to one or two people who contacted us directly,
and if in a fit of absent mindedness I had not deleted a note I had from
Chris regarding the configuration assumptions, I would forward it to you for
a BWR file. As I mentioned when I sent it in, it does not pretend to be a
full kermit, more a minmalist bulk data transfer utility conforming to the
kermit protocol.

It is probably possible to bypass the need for specific ROMs and so on by
the use of inline assembler, however, if the ROMs are available, it is
better to use the facilities provided by the HP virtual communication
device.

I'll get the precise details from Chris as soon as possible for you for
inclusion in a BWR

Sorry about the hassle,
                              Doug

------------------------------

Date: 11 Dec 86 13:42:00 EST
From: John Stewart <[e-mail]>
Subject: HCP and HC6 Versions of Kermit
Keywords: Honeywell Kermit

   I was looking at the versions file and noticed that two versions of
Kermit are listed for our machine, HCP and HC6.

   HCP is a Pascal implementation of Kermit that was ported to the Honeywell
Cp-6 operating system by Bucknell University.  It is a very minimal
implementation (it doesn't even do repeat counts, let alone advanced
features like server mode).

   HC6 is much more complete then HCP, and both the original developer and
myself are continuing to enhance it.

   I suggest that distribution of the HCP version of kermit be discontinued.

Regards.. jas

[Ed. - Thanks, this seems to be the concensus of opinion; the HCP version
was indeed retired to Tape C.]

------------------------------

Date:  Wed, 10 Dec 86 10:33 EST
From:  "John G. Ata" <[e-mail]>
Subject:  Need Fast De-BOOing Program for the Amiga
Keywords: Amiga Kermit

Can somebody out there who has a C compiler on the Amiga please compile
CKIBOO.C and then make a BOO file out of it and send it in to Kermit
Distribution as, say, CKIBOO.BOO, so that those of us without a C compiler
only have to run the Basic de-booer once, on CKIBOO.BOO, and then can
subsequently use the compiled de-booer which should be much faster.  It
takes about an hour to de-boo Amiga Kermit with the Basic de-booer.

                    John G. Ata

------------------------------

Date: Tue, 16 Dec 86 16:25:14 est
From: munnari!latcs1.oz![e-mail] (Philip Lee)
Subject: Data General MV2000
Keywords: Data General

Has anyone sucessfully ported the unix kermit to Data General MV2000 running
DG/UX ver. 3.00? We've tried recompiling ver 4D on it.  It compiled without
complaining, but gave link error. However it sort of work. We could do ascii
file transfer, but any compressed file or any of those using all 8 bits would
fail. The DG kermit would accept set file type binary quite happily and
indicate the same, but on file transfer it would just time out and fail.

In generating the DG/UX kermit we used the following:

make wermit \
 "CFLAGS = -D_file=_fd -DUXIII -DDEBUG -DVER2 -DTLOG -O4" "LNKFLAGS ="

Could this be also related to the problem of 8 bit transfers between FIDOnet
Kermit and the Pyramid?

[Ed. - The FIDO question has still not been totally solved, mostly because
of lack of time, but it might help you to know there's a version of Kermit
specifically tailored for DG MV/UX (is that the same thing?), based on an
old release of Unix Kermit, available in the Kermit distribution under the
prefix DGM.  There's also a C-Kermit implementation for AOS/VS on the way.]

------------------------------

Date: Sun, 14 Dec 86 14:56:29 +0200
From: Sam Gamoran <VSSAM@WEIZMANN>
Subject: Kermit 3.1 - An interesting speed problem
Keywords: CMS Kermit, PROCOMM

We just installed CMS Kermit 3.1 - appears to solve our problems with 2.1
particularly the program hanging and binary transfers.

We use CMS Kermit through a 7171 against PCs running either MS-DOS Kermit
2.28 or Procomm 2.3 with the Kermit file transfer option.  Works great with
MS-DOS Kermit 2.28 but file transfer crawls with Procomm 2.3.

Every packet sent by CMS-KERMIT 3.1 ends with an X-ON character.  The old
CMS-KERMIT 2.1 did not do this.  It appears that this X-ON character causes
Procomm to delay a second or so before sending the next packet.  We saw on a
line monitor packets going out from PC to mainframe and an instantaneous
response followed by a delay.  With the old CMS-KERMIT, where the main
difference between packets is the absence of the final X-ON character no
delay occured and transfer throughput was 400% faster!

Do you know of anyone having experience with PC->Mainframe file transfer
using PROCOMM who has encountered similar problems? I am also sending this
query to the procomm folks.  Thanks,

Sam Gamoran

------------------------------

Date: Tue, 16 Dec 86 15:39 CST
From: "David S. Cargo" <[e-mail]>
Subject: Symbolics V7.0 Kermit
Keywords: Symbolics Kermit

Symbolics is upgrading their system software to version 7.0.  The old
Symbolics Kermit no longer works with the new system revision.  Has anybody
upgraded the existing version to run on the new system?  I'm trying to avoid
some wheel reinvention.

------------------------------

End of Info-Kermit Digest
*************************
-------
31-Dec-86 15:55:38-EST,14580;000000000000
Mail-From: SY.FDC created at 31-Dec-86 15:54:33
Date: Wed 31 Dec 86 15:54:33-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V5 #20
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 31 Dec 1986       Volume 5 : Number 20

Today's Topics:
               Series 1/7171 Support in NIH TSO Kermit
             Speed Problem Between ProComm and Kermit-CMS
                      C-Kermit With Intel Xenix
                 Fix for Unix Kermit on SCO System V
                   C-Kermit and Valid Workstations
                Where to Send HP-1000 Kermit Requests

----------------------------------------------------------------------

Date: Sat, 20 Dec 86  21:00:25 EST
From: "Roger Fajman" <RAF@NIHCU>
Subject: Series 1/7171 Support in NIH TSO Kermit
Keywords: TSO, MVS/TSO Kermit

One important correction to Info-Kermit V5 #19: NIH TSO Kermit does not
presently have Series 1/7171 protocol converter support.  We don't have
those machines.  If someone wants to send us the modification, we will be
glad to include it.

[Ed. - Oops!  Sorry.  It appears that reports of the death TSOS1 were
somewhat exaggerated.  Volunteers?  Also, note that the "other" new TSO
Kermit, expected in the not-too-distant future, should indeed support both
Series/1 (full screen) and 37x5 (linemode) style hookups.]

Also, I checked the files as they appear on KERMSRV at CUVMA, and found some
erroneous translations between vertical bars and exclamation marks.  The
following files contain real exclamation points: TSNKER.ALP (just a
comment), TSNKER.DOC, TSNEDR.DOC, TSNMAC.DOC, and TSNTBL.ASM (in the
translate tables).  The last one is the most serious.

[Ed. - Oops again!  That's what comes from reading EBCDIC tapes on a Unix
system with 'dd'...  We'll try to get clean copies of these files over
BITNET to replace the current copies.  It has also been reported that
some files have U and e where square brackets ([) and (]) ought to be.]

------------------------------

Date: 1986 Dec 22   13:52 EST
From: (John F. Chandler)   <[e-mail]>
Subject: Speed Problem Between ProComm and Kermit-CMS
Keywords: ProComm, CMS Kermit, Series/1

I have seen reports of the problem from a number of places now, some not
specifically mentioning the use of a 7171, but none mentioning anything
else.  The implication of the latest report (in Kermit Digest #19) is clear:
ProComm needs to be fixed.  However, I should add that the XON added to the
end of each packet by CMS Kermit is not essential and could be removed if
necessary.  It was added as a convenience for the micro Kermit -- the rule
of thumb is: when talking to an IBM mainframe, always wait for an XON before
sending the next packet.  The rule is not true for the various protocol
converters (Series/1, 4994, and 7171), but the added XON makes it harmless.
How does ProComm perform when told to wait for the XON?

------------------------------

Date:  Mon, 22 Dec 86 21:26 CST
From:  [e-mail]
Subject: C-Kermit With Intel Xenix
Keywords: Xenix, C-Kermit

I have been running 4D(061) under Intel Xenix(3.3) on an Intel 286/310
system for some time now with no problems.  I used "make xenix".  I also got
a clean compile/link for an older UniPlus (UniSoft System III) for 4D(061).
It is running, but I have not used it extensively.  I used "make sys3".

          Richard   {[e-mail]}

------------------------------

Date: 21 Dec 86 04:30:32 GMT
From: ihnp4!killer![e-mail]
Subject: Fix for Unix Kermit on SCO System V
Keywords: C-Kermit, SCO Xenix, Xenix

I have some info that may be useful in trying to determine why kermit
(wermit) specifically ckuker does not want to run on Xenix sys V (SCO).  I
noticed a discrepancy in the server mode prompt from any other system to an
SCO system.  On most systems, the prompt is "# N3".  HOwever, on Xenix, the
thing comes up "# N/".  A Xenix system will talk to another Xenix system
(SCO), but cannot communicate with any other systems for protocol transfer.

The problem comes from performing functions on unsigned and signed ints.
For some reason (compiler bug), when certain operations are performed on
standard ints, the sign bit gets set (lsb in MS byte).  This makes checksums
come out screwy.  To resolve this, edit the module 'ckcfn2.c' (by the way,
we are talking about ckuker here) look for the function 'C K U 1'.  You will
notice an 'int chk' below the function heading.  Simply change it to
'unsigned int chk' and the version should work perfectly.

My thanks to all who helped isolate this... Allen

[Ed. - Hmmm...  What version of C-Kermit has everyone been using?  This
change was made months ago, either in 4D(061) or 4D(060).  Maybe if everyone
with SCO Xenix systems tries the current version - 4D(061) - the problem
will disappear.  Could some SCO Xenix users verify this???  By the way, I
think Allen meant to say 'C H K 1' rather than 'C K U 1'.]

------------------------------

Date: Tue, 9 Dec 86 16:12:13 pst
From: hplabs!valid![e-mail] (Carol Fernihough)
Subject: C-Kermit and Valid Workstations
Keywords: C-Kermit, Valid Workstations

I'm unclear as to where to mail bug reports regarding kermit.  I'd like my
mail find its way to 1) kermit programmers at Columbia University, and 2) a
network, so that I could receive responses from other users who can suggest
fixes.  Would you please forward this mail if necessary, and let me know where
I should send UUCP mail.  Although I have access to kermit information via the
mod.protocols.kermit newsgroup on Usenet, I do not have permission to post to
the moderated newsgroup.

[Ed. - UUCP mail can be sent to ...!seismo!columbia!cu20b!info-kermit]

I have tested version 4D(060) of c-kermit quite extensively on Valid's
workstation, which is an S320 running 4.2 BSD UNIX.  I compiled c-kermit
using "make valid".

I've found the following problems when transferring files between two S320's:

* Use of the -k option corrupts the file during kermit's transfer:
  This problem also arises when transferring files between the S320 and
  c-kermit (compiled using "make sys3") on the IBM PC/AT.

  machineA# kermit -iwl /dev/ttys0 -b 9600
  c-kermit(machineA)> connect
  (log onto machineB)
  machineB# kermit -ik > file.from_machineA
  (escape back to machineA)
  c-kermit(machineA)> send file
  file -> FILE, Size 50

  The text file that arrives on machineB is 52 bytes long since it has a CR LF
  at the beginning of the file.  Binary files are corrupted in the same manner.
  Text files are corrupted when sent using the -k option with no -i option.

[Ed. - We can't reproduce this problem on our 4.2BSD (Ultrix 1.1, really) VAX
750, but it's probably related to the well-known bug which inserts an
extraneous CRLF into standard output every 4096 characters (this only happens
with the -k option).  There's nothing in the C-Kermit code that inserts this
CRLF, so it must have something to do with Unix's blocking.  Does anybody have
an idea what must be done to convince Unix to leave out the CRLFs -- some
kind of mysterious ioctl or fnctl applied to stdout, maybe?]

* Can't use -c option
  When I escape (^\c) after starting kermit on machineB, I escape out of
  the kermit on machineA.  This also happens when kermit is started in server
  mode.

  c-kermit(machineA)> kermit -cl /dev/ttys0 -b 9600 -iw
  (log onto machineB)
  machineB# kermit -iw

[Ed. - This is the documented behavior.  When you invoke Kermit with action
commands (either protocol or connect, or both) on the command line, it acts
like a normal Unix command, i.e. it exits when done.  Leave out the -c
option, and you'll get an interactive Kermit session that you can escape
back to.]

* This problem occurs randomly.
  When host to host, and connected to machineB:

  c-kermit(machineB)> exit
  (logout from csh)
  Can't get character:  I/O error
  [Back at Local System]
  c-kermit(machineA)>
  (exits directly back to kermit on machineA - should need ^\c first)

  The problem also occurs randomly when machineB is running in server mode:

  c-kermit(machineA)> finish
  c-kermit(machineA)> connect
  machineB# logout
  Can't get character:  I/O error
  [Back at Local System]
  c-kermit(machineA)>

[Ed. - This probably is caused by your ports and cables.  Most likely, you've
got the systems connected by a true null-modem cable, in which one computer's
DTR is connected to the other computer's CD and/or DSR.  The remote computer
may be configured to drop DTR upon logout, which would cause the local one to
sense that CD or DSR disappeared, and to return an I/O error the next time
you tried to read or write characters to the port.  The Kermit connect command
exits when it gets an i/o error.  Solution: trade in your true null modem cable
for a "fakeout" cable in which DTR is connected to CD and DSR within the local
connector, or reconfigure your ports to be less persnickety about modem
signals.]

* When kermit is invoked from a script command, the command line options
  are ignored.
  machineA# kermit -iwl /dev/ttys0 -b 9600
  machineA's /.kermrc file contains:
  script gin:--gin:--gin: name ssword: passwd \
  machineB#--machineB# kermit~s-iwx
  send binary_file binary_file.from_machineA

  The attempted transfer simply times out because kermit on machineA is NOT
  in server mode, nor have the other command line options taken effect.

  Workaround:
  Rather than including command line options in a call to kermit from a
  script, put the necessary commands in the script or in the remote machine's
  .kermrc.

[Ed. - This is just a guess, but maybe the '-' in '-iwx' is the culprit,
since dashes are meta-characters in uucp-style scripts.  Try changing
'kermit~s-iwx' to 'kermit~s~055iwx' and see if that works.]

* Finish doesn't always work
  When using a server, type finish, then connect.  Kermit will sometimes
  connect back to kermit on the remote machine rather than the shell on
  the remote machine.

[Ed. - This depends upon whether you invoked Kermit with -x on the command
line (in which case it exits to the shell) or with the interactive 'server'
command (in which case it returns to C-Kermit> command level).]

I've also begun to test c-kermit between the S320 and the Microvax, running
VAX version 2.1.  I compiled c-kermit on the Microvax using the CKVKER.COM DCL
procedure.  I've found the following problems:

S320 -> Microvax

* Can't transfer binary files
  Both host to host and server transfers corrupt binary files.

[Ed. - Presumably you gave the -i option or 'set file type binary' on both
ends.  Have other users of C-Kermit on VMS found this to be true?  I think the
problem is that VMS binary files are not simple streams but are structured
with particular blocksizes, etc.  There's no code in C-Kermit to do this.  I
hope somebody who's familiar with VMS and VAX-11 C will add this code, or
provide some hints or workarounds to this problem.]

* Bye doesn't work
  When running kermit on the microvax in server mode, type bye, then connect.
  Bye acts like finish because kermit will connect to the microvax command
  interpreter prompt.  At this point, type logout (which doesn't echo on the
  screen).

[Ed. - Again, sounds like something to do with VMS.  Maybe VMS doesn't allow
a program to log out its own job unless the program is started or configured
with some specific capability.  Can any VMS experts answer this?]

* Finish doesn't work
  When using the microvax as a server, type finish, then connect.  Kermit will
  connect back to kermit on the microvax rather than the command interpreter.

[Ed. - As in the Unix case, it depends on how the program was invoked.]

* Exit doesn't always work
  Sometimes no action will be taken in response to exit.  Quit always works
  however.

[Ed. - That's strange, because quit is simply a synonym for exit -- both are
associated with exactly the same code.]

Microvax -> S320

* Directory doesn't work
  Directory listed only one file in a directory containing several files.

* Cwd doesn't work
  Cwd caused an access violation and exited from kermit.
  c-kermit(microvax)> cwd
  %SYSTEM-F ACCVIO, access violation, reason mask=00, virtual address=00000000,
  P4
  %TRACE-F-TRACEBACK, symbolic stack dump follows
  module name   routine name    line    rel pc  abs pc
  CKVFIO        system          3233    17      15122
  CKUUSR        docmd           1796    1a2     12F53
  CKUUSR        parser          1635    182     12B69
  CKCMAI        main            930     BC      D918
  $ (could not echo - logged out)

[Ed. - Again, I appeal to VMS experts for help sprucing up the VMS-specific
functions in the CKV*.C modules.]

I also have a question.  What is the reason for not reading the .kermrc file
when the command line contains an action?

[Ed. - No special reason except that the structure of the code made it hard
to do.  This feature should be added in a future release.]

UUCP address:  ucbvax!hplabs!pesnta!valid!carolf

                                  Thanks!

                                  Carol Fernihough

[Ed. - And thanks to you for your detailed reports.  This is how Kermit
programs keep getting better.  I hope I've answered each point
satisfactorily.  If not, let me know.  - Frank]

------------------------------

Date: Wed 24 Dec 86 10:56:43-EST
From: Christine M Gianone <[e-mail]>
Subject: Where to Send HP-1000 Kermit Requests
Keywords: HP-1000 Kermit, Interex

Paul Schumann has been getting many requests for his version of Kermit
for the HP-1000 but is unable to provide such a service.  He has asked
that in the future people please make such requests of Columbia University
or the HP User Groups since these groups are set up to do this kind of
distribution.

If anyone is interested in becoming a member of the HP User Group, the
address is as follows:
                                Interex
                                680 Almanor Avenue
                                Sunnyville, CA 94086-3513

------------------------------

End of Info-Kermit Digest
*************************
-------
12-Jan-87 12:52:43-EST,21964;000000000000
Mail-From: SY.CHRISTINE created at 12-Jan-87 12:48:56
Date: Mon 12 Jan 87 12:48:56-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V6 #1
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Mon, 12 Jan 1986       Volume 6 : Number  1

Today's Topics:
                  CUVMA bitnet link down 1/15 - 1/18
           New Rainbow MS-DOS Kermit with VT-220 Emulation
                          C-Kermit and CRLF
                           Bug in C-Kermit
                   Xenix on IBM-PC/AT & SCO Xenix V
                          Kermit and Procomm
                ASCII uploads using Kermit on the VAX
                       Kermit & DECserver 200's
               Send/Receive Overlap Implementation Flaw
                    Function key map for PC Kermit
                   ISIS-II Kermit/bootstrap wanted

----------------------------------------------------------------------

Date: Fri, 9 Jan 87 11:46:24 est
From: Alan Crosswell <[e-mail]>
Subject: CUVMA bitnet link down 1/15 - 1/18
Keywords: BITNET

The communications controller for CUVMA's Bitnet link is scheduled to
be down from 7:00AM EST 1/15/86 through 8:00PM EST 1/18/86.
Directly connected nodes "upstream" (relative to CUNYVM) of CUVMA:
    CUVMB, CUVMC, CUCCA, CUCHEM, CUCEVX, CUCSVM, CUGSBVM,
    CUCSVM, CUTCV1, CUTHRY,    GECRDVM1, NYSPI, NYUCCVM, NASAGISS.
This also means the BITNET-CCNET gateway at CUVMA will be unreachable
during this time.

------------------------------

Date: 19 Dec 1986 2150-EST
From: David L. Knoell, Basic American Food Company, Vacaville, CA 95696
Via: [e-mail]
Subject: New Rainbow MS-DOS Kermit with VT-220 Emulation
Keywords: MS-DOS Kermit, Rainbow Kermit, Terminal Emulation

My company uses multi-vaxen (clustered and DEC-neted) including 8600,780's
and mult-micro VAXens.  We also have many Rainbows and so have a vested
interest in their use as it relates to the VAX.  It seemed a shame that DEC's
firmware only emulated a VT102 even though the keyboard looks exactly like a
VT220.  For a while it didn't make much difference since VMS didn't know what
a VT220 was anyway.  Now we are using SEDT under VMS and it sure does know
what a VT220 is.  Well, one thing led to another and there were a few bugs in
MSXRB1 and also in the Rainbow's firmware which needed fixing and I've never
liked software which pre-empts any keys for its own selfish use without
giving the user a way to override, so...

New & Improved DEC Rainbow MS-Kermit Features:

1 o  Full VT220 Terminal emulation including User Defined Keys.
     All VT220 escape sequences are supported except the down-line
     loadable character stuff. Insert Characters (ICH) and Erase Characters
     (ECH) as well as Selective Erase in Line/Display are fully implemented.
     Enhancements such as "turn off" character attributes are also included.

2 o  Full VT102 printer port support as well as a VT240 "printer-to-Host"
     loop-back enables Kermit to operate as a cheap "line-monitor".

3 o  Interactive (during Connect) "Hot-key" definition of any key.  Keys can
     be assigned to ascii strings or to a "special-function).  These
     assignments are temporary for a single connect session but do override
     all other key assignments except VT220 user defined keys.  Over 80 special
     functions are provided which include all ms-kermit standard functions
     such as "prev screen,prev line,next screen,dump screen,print screen etc".
     Many additional functions have been added which can be assigned either
     temporarily via "connect mode help" or with the standard ms-kermit
     SET KEY function.  This usage is upward compatible with the current 2.29
     release.

4 o  Kermit functions currently assigned to keys with "embedded code" can be
     disabled so a user can customize his kermit via SET KEY in a mskermit.ini
     file.  An example  "ini" file is included which duplicates the current
     "hard coded" functions.

5 o  A "connect mode" interactive help section was added which
     contains all sorts of goodies.  In fact each of the functions selectable
     from the "Main Help Menu" are also available as "special functions" and
     can be assigned to any key. The current funtions include: Show All Keys;
     Set Key to Special Function; Set Key To Ascii String; Special Interactive
     Status; Show Kermit Internal; Set File Name.  Chars keyed are in reverse
     video, chars received in normal video.  Control chars and sequences as
     well as escape sequences are brite.  In this mode most control/escape
     sequences are not actually done however there are some exceptions.
     Down-line loaded user defined key sequences are done as well as shift
     keys to application mode etc..

7 o  Improved scroll buffer management provides up to 20 screens of 132 chars
     each.  This is 480 lines of video memory and is allocated if enough free
     memory is available.  If not enough is available then less is allocated
     on a line by line basis.  The memory management has been improved so that
     it always reflects exactally what has been received.  All video attributes
     are supported including double wide/hi stuff.  If you scroll back and a
     character is received to be put on the screen; then the scroll management
     routines restore the screen before modifying video memory.  The dump to
     printer/disk routines also handle the character set shifts required to use
     the Rainbow's multi-national character set and VT100 graphics.

8 o  Source code has been re-organized along the same lines as the IBM version.

  Author: David L. Knoell
          Basic American Food Company
          PO Box 1140
          Vacaville Ca  95696

[Ed. - Many thanks!  The .BOO file, sample initialization file, and extensive
documentation have been installed in the Kermit distribution areas as
MSVRB2.* (to distinguish them from the "mainline" Rainbow version, MSVRB1.*).
The program identifies itself as "Rainbow + MS-Kermit V2.29.1 4 July 86".
To turn on all the new functions, you have to TAKE the file MSVRB2.INI.
Unfortunately, we can't simply replace the old version, because the work done
by David duplicates -- incompatibly, of course -- much work that has already
been done on the next release of MS-Kermit by Joe Doupnik (yes, David and Joe
have now been put in touch with each other).  Since the VT-220 emulation and
other improvements are so useful, this version is being released as an
alternate, more or less dead-end, Rainbow MS-Kermit.  It seems to work as
advertised (tested on a Rainbow 100B), with one caveat: typing Ctrl-S (for
instance, to give a Search command to EMACS) freezes (XOFFs) the Rainbow
until a Ctrl-Q (XON) is typed.  The source code for this version has been
sent to Joe to see if it can be adapted to the new release.]

------------------------------

Date: Thu, 1 Jan 87 17:32:11 PST
From: hoptoad![e-mail] (John Gilmore)
Subject: C-Kermit and CRLF
Keywords: C-Kermit, UNIX Kermit

Re: Info-Kermit Digest V5 #20

>[Ed. - We can't reproduce this problem on our 4.2BSD (Ultrix 1.1, really) VAX
>750, but it's probably related to the well-known bug which inserts an
>extraneous CRLF into standard output every 4096 characters (this only happens
>with the -k option).  There's nothing in the C-Kermit code that inserts this
>CRLF, so it must have something to do with Unix's blocking. Does anybody have
>an idea what must be done to convince Unix to leave out the CRLFs -- some
>kind of mysterious ioctl or fnctl applied to stdout, maybe?]

No such luck -- no Unix stdio that I've seen inserts CRLF's.  Certainly not
4.2BSD's.  What you write is what you get.  Kermit *is* writing the CRLF
somewhere; maybe sometime when it thinks it's writing to the user's
terminal, it's actually writing to the data stream.  Since under the -k
option both go to standard output, this would not be hard to do.  I looked
in the kermit sources (though I don't run it here) and kermit seems to be
using stdout for all kinds of things, e.g. printing error messages that
should probably go to stderr instead.

You can probably debug this using dbx to watch what is happening in the
stdout buffer, e.g. "trace _iob[1]._buf" or some such.  It'll be slow, since
it looks after each instruction or source line, but it should catch it for
you.

[Ed. - We'll look again, thanks.]

------------------------------

Date: 10-JAN-1987 11:30:56
From: mfmail!nwbuts![e-mail]
Via: [e-mail]
Subject: Bug in C-Kermit
Keywords: C-Kermit

I appear to have discovered a bug in C-kermit.  We are currently running
version 4C(057) but I have also tried it on (061) with the same effect.

The problem occurs in sending files with file-type binary, and results in
the file being truncated.  If the last sequence is a multiple-character
escape, which wont fit into what should be the penultimate packet, then
after that packet has been sent the flag (first) says that EOF has been
reached and gives up, although there is still a sequence to send.

I have looked at this and the problem seems to be in ckcfns.c in the routine
getpkt, but I have not yet worked out a fix.  I would be grateful to know if
anyone else has already fixed the problem.

 Gordon Scott

 (Micro Focus, 26 West Street, Newbury     Tel - 0635 32646)

[Ed. - This appears to be to be a real bug in the getpkt() function.  A
cursory inspection of the source shows that the solution might be as simple
as moving the return() statement like this:

    } else if (first == -1) {    /* EOF from last time? */
    first = 1;        /* Setup for next time. */
        return(size = 0);       /* <--- delete this */
    } else x = 1;

    /* Do any leftovers */

    for (size = 0; (data[size] = leftover[size]) != '\0'; size++)
        ;
    *leftover = '\0';
    if (first == -1) return(size); /* <--- and add this */

This is totally unverified; reports welcome.  Thanks!]

------------------------------

Date: Wed, 7 Jan 87 00:55:42 EST
From: [e-mail] (Gary Nelson)
Subject: Xenix on IBM-PC/AT & SCO Xenix V
Keywords: Xenix, C-Kermit, SCO Xenix

In response to request for users of C-Kermit 4D061 on SCO Xenix:

My configuration:    IBM-PC/AT
            SCO Xenix Release 2.1.3 (Update E & F)

CRC problems - none, all 3 block checks work fine to any system I use:
        IBM-PC - MSDOS, MS-Kermit v2.29
        Intel 310 Xenix, C-Kermit
        DEC VAX 11/780 - BSD 4.3
        DEC PDP-11/70, RSX11m-Plus
I agree, fixed several(??) releases ago.

However, the dial command did not work after updating to the release of SCO
Xenix V.  The following diff file corrects problem in ckutio.c that broke
the dial command.  Note, if you are on SCO Release 2.1.0 - DO NOT include
this fix, leave the 4D061 version as released alone - it works fine.  The
nap() mod is not neccessary - just saw it and changed it to use an available
facility.

********** start of diff file **********

14a15,27
> /* Modification history:
>
> 23-NOV-86    Gary B. Nelson, Nelson Associates, Manassas, VA
>         As a consequence of my new release of SCO Xenix V2.1.3
>             breaking kermit:
>         Mods to msleep to use nap(), note -> add "-lx" to
>             LNKFLAGS in the makefile.
>         Mods to tthang to make it work again, with this new release
>             of XENIX (symptom was that the dial command
>             stopped working, a problem that was incorrectly
>             diagnosed by ?? as seen on the usenet a few days ago).
> */
>
527d539
< #ifndef XENIX        /* xenix cannot do close/open when carrier drops */
532d543
< #endif
1416,1418c1427
< #ifdef XENIX
< #define CLOCK_TICK 50            /* millisecs per clock tick */
< #else
> #ifndef XENIX
1420d1428
< #endif
1431a1440,1446
> #endif
> #endif
>
> #ifdef UXIII
> #ifdef XENIX
>     nap( (long) m );
> #endif

********** end of diff file **********

------------------------------

Date: 16 Dec 86 17:15:00 GMT
From: ihnp4!inuxc!pur-ee!uiucdcs!uxc.cso.uiuc.edu![e-mail]
Subject: Kermit and Procomm
Keywords: Procomm

Re: Kermit and Procomm

/* Written 1:38 pm Dec 15, 1986 by [e-mail] in
uxc.cso.uiuc.edu:comp.sys.ibm.pc */

> Would someone please explain (in full detail) to me how to get Procomm 2.4
> to do Kermit transfers. I can get Xmodem to work fine, I can get Kermit to
> Kermit to work fine, I just can't get Procomm to Kermit to work...

It seems that you do not have your parity set the same on both sides, or
your packet lengths are not the same.  On the Procomm side, I have usually
selected a packet lenght of 90.  My guess, however, is that the parity is
set different on the two programs.  Even if your host is set for no parity,
your Kermit might be looking for even parity.  Look at the status screen on
Kermit to verify that it is set the same as Procomm.  The parity on Procomm
will always correspond to what you are communicating at.

I have had no problems using Procomm to transfer vi Kermit to and from
uiucuxc.  If you need more help, contact me at the address below or call our
office at 244-0608.  Good Luck!

Dan Crimmins
University of Illinois at Urbana-Champaign
Computing Services Office - Micro Consulting Dept.
ARPA:    [e-mail]
BITNET:    [e-mail]
CSNET:    [e-mail]
UUCP:    {ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!crimmins

------------------------------

Date: 21 Dec 86 06:22:47 GMT
From: [e-mail]
Subject: ASCII uploads using Kermit on the VAX
Keywords: VAX Kermit, Modems

I've never been able to get an error-free ASCII upload to my local VAX; the
average is an error about every 20 lines.  At first I suspected Flash (would
be sad, since it's a fine terminal program) but now I find the same problem
with Uniterm.  Even Kermit logs a zillion errors, many of which are fatal.

Now I suspect my Avatex 1200 (not 1200hc) modem.  Can anyone shoot down this
theory for me by claiming successful uploads with that model?

I should point out that I get nary an error on downloads of any kind to the
ST.

Finally, to those of you who are waiting for the STEDT I promised, I'll send
it as soon as I get this problem licked.

    Thanks.
             Roger

------------------------------

Date: Thu 1 Jan 87 15:38:50-EST
From: Eric R. Crane <[e-mail]>
Subject: Kermit & DECserver 200's
Keywords: DECserver

We have just ordered some DECserver 200's and are wondering what special
considerations we will need when using KERMIT to transfer files to Vax VMS
systems over these lines.

  Eric R. Crane
  Carnegie Mellon University
  Computation Center
  Systems Software
  [e-mail]   (Arpa)
  R602EC0N@CMCCVB (Bitnet)

[Ed. - We encountered numerous difficulties trying to get Kermit to work on
Ultrix and TOPS-20 when connected through DECserver-100s (aka LAT boxes).
There are many parameters that have to be set correctly, and in some cases
the host's LAT service may have to be modified to allow input in bursts as
long as a typical Kermit packet.  In TOPS-20's case, Kermit packet sizes had
to be cranked down to about 40 until this was fixed.  Anyone who has
experience using Kermit through the DECserver-200 (or -100) is encouraged to
pass along any tips.]

------------------------------

Date: Wed, 7 Jan 87 17:43:49 PST
From: [e-mail] (Greg Small)
Subject: Send/Receive Overlap Implementation Flaw
Keywords: Send/Receive Overlap

Apparently many Kermit implementations still have the old send/receive overlap
flaw.  The problem is receiving while sending a packet.  The receive buffer
should be cleared AFTER the current packet is sent.  All implementers should
check their implementations and correct them if flawed.

The symptom is continuous retries while sending a file,  usually resulting in
an abort.  The retries occur about as rapidly as data packets would be sent,
e.g. once a second at 1200 baud (contrasted to 5-10 seconds for a timeout).

Normally Kermit sends data packets and receives ACKnowledgements
alternately.  Abnormal conditions may cause the remote Kermit to send an ACK
or NAK while the local Kermit is sending a data packet.  Because the local
Kermit did not clear its receive buffer or cleared it before sending the
packet rather than after, it reads the ACK received while it was sending.
This causes the local Kermit to resend the packet while the remote Kermit is
replying to the previous packet, so the overlap cycle repeats until an abort
or the timing is disturbed.

This has an additional twist for half-duplex Kermits such as IBM ASCII 37x5
and the Series/1-4994-7171 (physically full-duplex but logically
half-duplex).  Because Kermit-CMS controls the channel, its ACK/NAK
guarantees that the received data packet will be bad, which in turn
guarantees another NAK, which guarantees another overlapped send, etc.
repeating the cycle.

The problem is more likely at 1200 baud where the packet takes almost a full
second to send (96 chars/120 cps) and much less likely at 9600 baud where
the packet takes only .1 seconds because the remote Kermit is less likely to
respond in less than .1 seconds.  It is also more likely for long files
because the probability of the triggering event is greater.

Since we could not modify all Kermit versions in the field, we modified our
Kermit-CMS 2.01 to prefix 120 NULs to any NAK sent.  This guarantees that
the receiving Kermit will not see the NAK until after it has stopped
sending.

Greg Small                                           [phone]
Personal Computer Networking & Communications        [e-mail]
214 Evans Hall CFC                                   ucbvax!jade!opal!gts
University of California, Berkeley, Ca 94720         [e-mail]

[Ed. - A more concrete illustration of this problem would be helpful - which
systems & Kermit versions, which one is sending & which receiving, etc.
We've never seen this behavior at Columbia, with our mix of IBM (linemode
and fullscreen) and DEC (DEC-20 and Unix) mainframes, MS-DOS micros, etc.]

------------------------------

Date: 8-JAN-1987 14:38:56
From: [e-mail]
Via: [e-mail]
Subject: Function key map for PC Kermit
Keywords: MS-DOS Kermit, Key Map

Please find enclosed a comprehensible (???) function key map for ibm pc
running ms-kermit 2.29 showing the vt-102 keypad. Has anybody had any
thoughts on a special version for the new (looks almost like a vt1xx) pc
keyboard?

          Cheers,
                    Doug

Doug Moncur, Microsystems Advisor, Computing Service, University of York,
Heslington, York YO1 5DD
janet: [e-mail] :: phone [phone]x487/5969

**** here goes...

ibm_pc/vt_102 keypad mapping for mskermit_2.29

          <<EXPLANATION>>
                                                  +-------------------+
vt_102 equivalent for <SHIFT+FKEY>--->  |         3         |
edt equivalent (U/CASE means GOLD)--->  |  char    SPECINS  |
ibm keytop--------------------------->  |<<<<<<<< F5 >>>>>>>|
vt_102 equivalent for <FKEY>--------->  |          7        |
edt equivalent (U/CASE means GOLD)--->  |   page  COMMMAND  |
                                                  +-------------------+

          +-------------------+-----------------+
          |         6         |         ,       |
          |    cut   PASTE    |  del_c   UND_C  |
          |<<<<<<<< F1 >>>>>>>|<<<<<<< F2 >>>>>>|
          |         PF1       |       PF2       |
          |        gold       |       help      |
          +-------------------+-----------------+
          |         1         |         2       |
          |  word   CHNGCASE  |  eol   DEL_EOL  |
          |<<<<<<<< F3 >>>>>>>|<<<<<<< F4 >>>>>>|
          |         PF3       |       PF4       |
          |     fndtxt FIND   |   del_l UND_L   |
          +-------------------+-----------------+
          |         3         |      enter      |
          |  char    SPECINS  |  enter    SUBS  |
          |<<<<<<<< F5 >>>>>>>|<<<<<<< F6 >>>>>>|
          |          7        |        8        |
          |   page  COMMMAND  |    sect FILL    |
          +-------------------+-----------------+
          |         0         |         .       |
          | line    OPEN_LINE | select    RESET |
          |<<<<<<<< F7 >>>>>>>|<<<<<<< F8 >>>>>>|
          |          9        |        -        |
          |  append  REPLACE  |  del_w  UND_W   |
          +-------------------+-----------------+
          |                   |                 |
          |                   |                 |
          |<<<<<<<< F9 >>>>>>>|<<<<<< F10 >>>>>>|
          |          4        |        5        |
          |  advance BOTTOM   |    backup TOP   |
          +-------------------+-----------------+

------------------------------

Date: Mon, 12 Jan 1987 02:28 PST
From: [e-mail]
Subject: ISIS-II Kermit/bootstrap wanted
Keywords: ISIS-II Kermit

  Is there anyone who can provide a copy of ISIS-II (Intel MDS) Kermit on 8"
single or double density ISIS-formatted diskette or a cheap and easy
bootstrapping method for it. Cable specs would be appreciated for the
latter, if provided.

Jeffrey Sicherman
[e-mail]

------------------------------

End of Info-Kermit Digest
*************************
-------
20-Jan-87 18:48:17-EST,24754;000000000000
Mail-From: SY.CHRISTINE created at 20-Jan-87 18:47:08
Date: Tue 20 Jan 87 18:47:07-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V6 #2
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 20 Jan 1986       Volume 6 : Number 2

Today's Topics:

   MS-DOS Kermit 2.29b Test Prerelease for IBM PC, Clones, & Generic DOS
              Issues for New MS-DOS Kermit Keyboard Translator
                        Kermit Thru DECserver 100's
                                MD? Kermits

----------------------------------------------------------------------

Date: 13 JAN 87 01:12-MDT
From: JRD@USU
Subject: MS-DOS Kermit 2.29b Test Prerelease for IBM PC, Clones, & Generic DOS
Keywords: MS-DOS Kermit

        This most recent version of MS Kermit 2.29, identified as MS-Kermit
2.29b, has support for VT102 printer commands, long packets, and script
execution.  Additionally, it has corrections to most problems known at this
time.
        A new kind of MS Kermit, MSTCLO.BOO, is available for near-clones of
IBM PC's but whose serial port hardware is not similar.  Here is a description
from the originator, Glenn Everhart of RCA:

   This module is derived from MSXIBM.ASM and is intended for IBM PC
   near-clones that differ in their serial I/O but emulate the IBM
   BIOS. Such machines include Seequa Chameleon, DG/1, and others.
   The idea is to use the VT100 emulation (which will work) but
   use BIOS for all serial I/O. This is not interrupt driven and so
   will (unfortunately) not be able to keep up well at high baud
   rates. Nevertheless, it will be far better than the old Seequa
   version which didn't emulate anything.

        Note that this "semi-clone" version may also work on IBM equipment
in situations where the real IBM version will not, for instance when
communicating through a network communications server (e.g. on the token
ring) rather than a real asynchronous adapter (untested - guinea pigs?).

BUG FIXES AND INTERNAL IMPROVEMENTS:

        MS Kermit 2.29 of May '86 (no letter) had two serious bugs.  First
was an incompatibility with Hayes and similar internal modems: the modem
would hangup the phone when a file transfer completed or Connect mode
exited.  We have tested this version with a real Hayes 1200B modem with
satisfactory results (whew!, but let's keep our fingers crossed).

        Second was that extraneous null characters could be sent at the
start of a file transfer or when Connect mode was entered, causing certain
mainframes (e.g. IBM mainframes in linemode) and minis (e.g. HP-1000s) to
ignore packets (or worse), preventing file transfer from taking place.  The
nulls are no longer transmitted.

        In addition, there were numerous small problems throughout MS
Kermit, as might be expected, and those identified to date have been
addressed.  One important one was the serial port was left active if one
PUSHed to DOS while in Connect mode.

        Serious DOS errors are now trapped by Kermit to prevent Kermit from
being aborted with the serial port interrupt alive and with a couple of
other items redirected to Kermit itself.  The most common such error is
"Drive Not Ready."  Previously, these conditions would invoke the normal DOS
Critical Error proc which would request "Abort, Retry, Ignore?" and would
abort the program if Abort were chosen.  Now, Kermit exercises a fourth
option, Fail the Operation, when these errors occur.  Procedures spawning a
second copy of COMMAND.COM (DIR, etc) still can yield the A/R/I message but
it is harmless in this case.  However, if such a message arises while Kermit
is in Server mode a human must still type the answer locally.  The
implementation replaces the normal DOS Control-Break (^C) and Critical Error
handlers with Kermit's own handlers and restores the originals when Kermit
exits.

        Numerous small bugs concerning negotiated parameters (8 bit quoting,
Block check types, etc) have been fixed; these mainly concerned Server mode
operations. The terminal emulator no longer responds to the answer-back msg
request; there is no answer-back message in the emulator.  Screen handling
has been improved internally, but it still has a few glitches.

        While in Connect mode 8 bit received data will be passed through to
the terminal processor if the Parity type is None, and the character will be
displayed from the system's 8-bit character set.  If Debugging is ON then
characters with their high bit set will be displayed as a tilde and then a
code for the lower 7 bits; i.e., 10000001b is displayed as ~^A.  (Note to
mail readers: due to network quirks these characters may be mistranslated;
the tilde is the funny wiggle character above the accent mark and the
control symbol is a caret.)

ADDITION TO SET DISPLAY COMMAND:

        Set Display  Regular | Serial | Quiet | 7-bit | 8-bit

        The keywords 7-bit and 8-bit have been added to control display
of characters in connect mode.  7-bit is the default and 8-bit
becomes meaningless when parity is other than None.  The Set Display
command accepts two keywords in one command, processed left to right.

ADDITION TO SET PROMPT COMMAND:

        Special characters, such 8-bit Ascii or control characters like
escape, can be included in text of Kermit's prompt by specifying them as
octal numbers in the form \ooo where o is an octal digit.  Escape itself is
\33.  To return to Kermit's default prompt give the Set Prompt command
without text.  The replacement prompt can be up to 80 characters long.

VT102 PRINTER SUPPORT (IBM PC version only, for now):

    The MS Kermit VT-102 emulator now accepts ANSI printer control
sequences from the host, including Print Screen, Print Current Line,
Enable/Disable Auto Print, etc.

LONG PACKETS:

        MS Kermit can now use packets up to 1000 bytes in length.  The
transmitter selects the type of packet (Regular or Long) based upon the size
of the data to be sent in that particular packet; negotiations at the start
of a file transfer determine the maximum length.  The receiver is prepared
to accept Long packets at any time up to a maximum length set by the user.

        The commands Set Send Packet nnn and Set Receive Packet nnn the
maximum packet size; nnn can be as large as 1000.  Kermit uses 94-byte
packets as its default maximum size; longer packets will be employed only if
the user gives the Set Send/Receive Pack commands above.

        Long packets may be used in conjunction with any other Kermit
program that supports them.  Currently, these include IBM 370 VM/CMS Kermit
3.1, PDP-11 Kermit (for RSX, RT, RSTS, etc), and MS-Kermit itself.

EFFICIENCY:

        The IBM serial port interrupt routine, buffer handler for received
chars, and the packet assembly/disassembly routines Spack and Rpack have been
completely rewritten for efficiency, long packets, and high speed operations.
It is possible to operate at 38400 baud on a plain 4.77 MHz IBM PC provided
that the clock tick routine is not loaded with time consuming extras (Helpful
Utilities, print spoolers, screen savers, and the like).  Long packet and
high efficiency code are system independent; fancy high speed operation code
is for IBM PC's and clones and the DEC Rainbow.

SCRIPTS:

        A simple script and raw file upload facility has been written by Jim
Sturdevant and myself (Jim did the original version and we developed it from
there).  The syntax and operation conform to the description of login
scripts in the Kermit book, and in the DEC-20 section of the Kermit User
Guide.  This code is actually system independent.

        Joe Doupnik
        [e-mail]

[Ed. - Many thanks, Joe!  The three versions that you sent have been put in the
Kermit distribution for testing as MSTIBM.BOO (IBM PC family), MSTCLO.BOO
("semi-clones"), and MSTGEN.BOO (generic MS-DOS version, should run - slowly -
on any DOS machine).  Further details about the printer control sequences and
the script facility are in MST29B.DOC.  This second post-2.29 pre-release of
MS-Kermit comes without sources because the source is still undergoing
development towards the forthcoming "real" release, and is being issued
primarily to relieve the many Kermit users who have been affected by the
internal-modem and interpacket-null problems.  If no serious flaws are
encountered, this release will replace 2.29 on our distribution diskettes;
therefore, IBM-PC Kermit users are strongly encouraged to get this new version
and try it out, and report any problems back to Info-Kermit.  It has been
tested on a PC/AT at Columbia against VAX/Unix, DEC-20, and IBM VM/CMS (both
linemode and full-screen) Kermits, and seems to work as advertised.

The next true release of MS Kermit, to be called 2.30, will also include a
completely reworked key definition facility, which will allow key definitions
to work on any system covered by MS-Kermit, not just a select few, and will
allow Kermit "verbs" (like scroll back one screen, send a BREAK, toggle mode
line, etc) to be assigned to arbitrary keys.  It will probably also include
some other features, like reporting of performance statistics.  Volunteers
for testing the new code on systems that Joe does not have access to are most
welcome; such systems include the Wang PC, Victor 9000, HP-110 and 150, Sanyo
MBC, ACT Apricot, Heath/Zenith 100, Grid Compass, TI PC, etc.  Please send
mail to Info-Kermit@CU20B if you'd like to volunteer.  The IBM version also
needs rigorous testing under all the many and varied conditions our network
readers can subject it to: with various window and desktop managers, in
conjunction with different terminate-and-stay-resident (TSR) utilities,
with ANSI.SYS and its many replacements, with keyboard utilities like
ProKey, with networks like PC Network and Token Ring, with every conceivable
kind of host at the other end of the connection.  This is one of the most
widely used pieces of software in the world and YOU are the quality control!

Internet users may get the new files from host CU20B.COLUMBIA.EDU using FTP,
login ANONYMOUS, any password.  The files are KER:MST29B.* (documentation),
KER:MSTIBM.* (IBM version), KER:MSTCLO.* (semi-clone version), and
KER:MSTGEN.* (generic DOS version).  The .EXE files are encoded as printable
".BOO" files, which may be decoded using any of the KER:MSBPCT.* programs.
If you're unfamiliar with Kermit network distribution at Columbia, first GET
the file KER:AAAREAD.ME, read it, and take it from there.  BITNET users may
request the files from KERMSRV at host CUVMA; to get started you TELL
KERMSRV AT CUVMA HELP (or SEND/REM, or whatever the syntax on your host is).
The files should also show up at the Oklahoma State University (okstate)
UUCP Kermit server within a few days.]

------------------------------

Date: 13 JAN 87 23:00-MDT
From: JRD@USU
Subject: Issues for New MS-DOS Kermit Keyboard Translator
Keywords: MS-DOS Kermit, Keyboard Translation

[Ed. - The following message from Joe Doupnik, the current developer of MS-DOS
Kermit, who is working on the forthcoming release.  The major area that has not
been addressed so far is the keyboard translation facility of Kermit.
Presently, this facility is available only in selected implementations: the IBM
PC family & compatibles, the DEC Rainbow, and maybe a couple others.  The
reason it hasn't spread further is that it is done in a very system-dependent
way.  The system dependence has obvious benefits: speed, and the ability to get
at every conceivable key combination (like Ctrl-Shift-Alt-a), but the lack of
portability is a drawback.  The other major problem with the "old way" is that
certain functions, like screen rollback, modeline toggle, and BREAK
transmission, were hardwired to certain keys and could not be moved.  The
recently released alternate Rainbow Kermit (MSVRB2) addressed this problem by
enumerating every conceivable Kermit function and allowing them to be assigned
to arbitrary keys by number.  Anyone interested in these issues should grab
a copy of MSVRB2.DOC to see how this was done, and how it is presented to the
users.  On the assumption that the keyboard translator will change, Joe
presents what he feels to be the relevant issues -- compatibility with old
key definition files, efficiency, portability, adaptability to changing
keyboard and system design, etc -- and solicits opinions.]

        First, to answer the obvious question of "What would you like
in a keyboard translator?" Everything, naturally. Naturally, but ...

        I see a number of main goals of a translator. Recall, the translator
is active only during Connect mode.
        1. Almost any key should be able to emit (send to the other side)
any 8 bit character code (a char in my shorthand) or even a string of
them (a string). The binary null character is the only exception.
[Ed. - Why?]
        2. Common Kermit functions such as send a break, show the system
status, toggle the printer on or off, and so forth should be assignable
to almost any key. Included in the function category are cursor movements
when a terminal emulator is used since some emulations require the movement
escape sequence to be different depending on the state of the emulator yet
we still think of left arrow as a left arrow key. Future functions should
be incorporatable with little effort. I refer to these function operations
as named Kermit "verbs", meaning do some complex pre-programmed operation.
        3. Several keys could send the same character, string, or activate
the same "verb", without interference. Each key definition is distinct so
undefining one key does not undefine related keys.
        4. Keys which are defined ought to be undefinable easily and those
defined ought to be shown upon demand either per key or the whole set.
        5. Default definitions should be built-in for some emulators to reduce
the necessity of using a startup file of definitions, yet when such a file
is read into Kermit its contents should take precedence over existing
definitions. Any such file should be plain ascii, without control codes or
other unprintable characters. Similarly, old unused definitions should be
purged automatically if they occupy limited space; strings, in particular,
are space hungry.
        6. A controversial point. The name of a key (what is on the keycap)
can be sacrificed in favor of an obscure number if by so doing that particular
Kermit is freed of a particular keyboard. IBM-AT and XT owners take note.
By referring to keys via the system's internal numerical mumbo-jumbo then
the system can tell us if key F12 exists without the translator having any
direct foreknowledge (i.e., code having been written with that key in mind)
of such keys. Clearly, the disadvantge is less spontaneous key defining
and muttered comments about technical persons while pondering keys versus
key-numbers. More on this technical aspect later since it does affect design
of a translator.
        7. The manner of defining keys, that is the syntax of a Kermit
command, should be reasonably similar from machine to MS DOS machine so
that a single Kermit manual can explain matters for all. This has the
further hidden benefit of allowing more of the core translator code
to be used on all machines so that one improvement is shared immediately.
More elegant full color menus could be used where appropriate and when
someone implements them for a given machine.
        8. Whatever may be done, the translator should not be a memory/cpu
hog, should not consume acres of Status or Set display space, nor should it
be visible to those people who would rather work without a translator.
Similarly, the translator should attempt to co-exist with resident keyboard
utilities such as SuperKey, ProKey, and the like with Kermit reading what
these resident utilities deliver.
        9. A keyboard translator is not an editor nor a programming language
nor a cover up for a clumsy host nor anything more than a simple translator.
        10. Finally, the syntax of definitions should permit unusual
string constructions with embedded control codes and spaces, full eight bit
character codes, and permit sufficient length to be useful as full remote
host commands. The definition should be printable for documenting on paper
and for editing; straight printable ascii. Such definitions could be entered
from an existing file and (not just or) directly from the keyboard.

        That's my preliminary wish list. Item 6 will be of immediate
concern to many readers.

        For purposes of illustration, let me describe one translator as a
user would encounter it.

;Defining a key:
; Command is SET KEY <key ident><whitespace><definition>
;
; <key ident> is
;               a single ordinary ascii char or
;               the numerical equivalent of an ascii char or
;               a Scan Code written as a number or
;               keyword SCAN followed by a number.
;               ?       Displays help message.
;       Numbers and Binary codes are of the form
;               \123    an octal number
;               \o456   an octal number         base letters o, d, x can be
;               \d213   a decimal number        upper or lower case
;               \x0d    a hex number
;               \{b###}  braces around above material following slash.
;               Braces are optional, and the default number base is octal.
;               The backslash character \ is required.
;
; <whitespace> is one or more spaces and or tabs.
;
; <definition> is
;       missing altogether which "undefines" a key.
;       \Kverb          for a Kermit action verb; upper or lower case K is ok
;       \{Kverb}        ditto. Verb is the name of an action verb.
;       text            a string with allowed embedded whitespace and embedded
;                       binary chars as above. This kind of string may not
;                       commence with sequences \K or \{K; use braces below.
;       {text}          string confined to material within but excluding
;                       the braces. Note, where the number of opening braces
;                       exceeds the number of closing braces the end of line
;                       terminates the string: {ab{}{{c}d ==> ab{}{{c}d
;                       but  {ab}{{c}d ==> ab.
;       ?               Displays help message and lists all action verbs.
;
;       A key may be translated into any single 8 bit code.
;
;       Comments can follow a Kermit action verb or a braced string; no
;       semicolon is required since all are stripped out by the Take file
;       reader before the defining text is seen by SET KEY.
;
;       The current Kermit escape character cannot be translated without
;       subtrafuge. Many keys can yield the same escape character.
;
;       Examples:
;               Set Key q z
;                               makes key q send character z
;               Set Key \7 \33[0m
;                               makes key Control G send the four byte
;                               string  ESC [ 0 m
;               Set Key q
;                               undefines key q so it sends itself (q) again.
;               Set Key \4455 \kexit
;                               defines IBM Alt-X to invoke the leave connect
;                               mode verb "exit" (Kermit's escape-char ^]c).
;               Set Key \x0c Login \{x0d}myname\{x0d}mypass\x0d
;                               defines Control L to send the string
;                               Login <cr>myname<cr>mypass<cr>
;
;Showing a key:
; Command is SHOW KEY <cr>
; System prompts user to press a key and shows the definition plus the
; free space for strings and other definitions. Responding to the Press
; a Key prompt with a question mark produces a list of all defined keys.

        Some example "verbs" are exit, send-a-break, status, toggle-mode-line,
toggle-printer, the four arrow keys, definitions for Function keys emulating a
VT102 terminal (for IBM and several other machines), and so forth totaling over
40 "verbs."  256 verbs are permitted if the space is set aside accordingly.
Strings are limited to a full Kermit command line of 128 characters, and a
nominal 1 K byte buffer is allocated to hold all multi-character strings; it
could be much larger. Single replacement characters come out of a pool of
definition packets set at say 100-200 possible definitions, or more if needed.
A European or Dovark keyboard typically would use single character replacements
and cost 4 bytes of table space per definition.

        Additional technical comments on the example.

        This example translator uses the number business to identify a
key. Such numbers are displayed by the Show Key command. The benefit to the
systems designer is the same code with only minor changes ports well to
an IBM PC or a Generic terminal driven device or just about any other
machine. It was also designed to be "unplugged" by using a replacement
code file if the space consumed were too much for a system; unplugging
means an assembly language file need only be substitued whole for another
without any editing.
        Also, the numerical key identification scheme relies on the local
operating system to provide a key's magic number for tomorrow's fancy
125 key keyboard with attached mouse and telephone dialer without Kermit being
pre-designed for that device. A suprising new keycode is just another
number to the translator. In fact, the main body of the translator knows
precisely zero about keyboards! It sees a keycode number and follows
instructions in the translation tables. A short system dependent procedure
is charged with the easy task of obtaining a key response and delivering it
in standardized form to the main translator. Much easier on the programmer!
        This example translator is "non-modal" in the sense that one key
always means the same thing. Modes could be introduced, such as when
examining the Status display a certain key could bring up details of the
serial port or packet parameters but do something else while Kermit is
acting as a terminal. The cost of modes is in space for code and extra tables
and a more complex key definition scheme (not to mention major headaches
concerning compatibility among different machines).
        An actual implementation of this example uses about 6-7 Kbytes for
code plus tables. It works much faster than my speeded up IBM AT keyboard.

        So, it's not perfect is it? What we will get is a combination of
your best ideas blended with the necessities of writing one for multiple
machines. It's a fine time to do a super job.

        Regards,
        Joe D.

------------------------------

Date: 13 Jan 87 07:55:00 EST
From: "INFOCEN - Greg Elder" <[e-mail]>
Subject: Kermit Thru DECserver 100's
Keywords: DECserver

I've used KERMIT through DECserver 100's to communicate with and transfer to
VAX/VMS systems.  I've run at 9600 baud with no problems.  The only thing I
needed to do was set some of the parameters on the DECserver as described on
page 20 of the DECserver 100 Terminal Server User's Pocket Guide.  This page
describes how to set up the DECserver for file transfers.  Basically you
give the server these commands:

    Local> SET BAC NONE FOR NONE LOS NONE
    Local> SET BRO DIS FLO DIS LOS DIS

These commands turn-off the ability to have special switch characters
(backward, forward, and local switches) on the server and it disables flow
control, broadcast, and loss notification on the server.  Hope this
information is helpful.

Greg Elder
elder@wpafb-info2

------------------------------

Date: Wed, 14 Jan 1987 02:19 PST
From: [e-mail]
Subject: MD? Kermits
Keywords: ISIS/MDS Kermit

  Which of the two ISIS/MDS kermits should be considered the latest and
greatest ? The help files for each make it a little ambiguous with entries
about the same date (within a couple of months) and a comment that one was
received based upon the other which was upgraded soon after .... sigh. Is
there a real difference or what? (weak docs)

------------------------------

End of Info-Kermit Digest
*************************

-------
26-Jan-87 12:01:53-EST,23438;000000000000
Mail-From: SY.CHRISTINE created at 26-Jan-87 12:00:19
Date: Mon 26 Jan 87 12:00:19-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V6 #3
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Mon, 26 Jan 1987       Volume 6 : Number 3

Today's Topics:

        Announcing Kermit for PICK (REALITY) OS on Microdata Systems
             Announcing Kermit for the CIE 680/XX Microcomputer
        Announcing Kermit for the MODCOMP Classic running MAX IV OS
                         Kermit BITNET Distribution
                         Wang Kermit 2.29a Works!!!
                 Mskermit Version 2.29 Keys for the IBM PC
                Bad Filenames in MS-DOS Kermit Version 2.29
                        MS-DOS Kermit Version 2.29b
               Problems Compiling C-Kermit on ATT 3BX Systems
                 Update on Commodore-64/C-128 Kermit Wanted

----------------------------------------------------------------------

Date: Thu 22 Jan 87 15:13:03-EST
From: Frank da Cruz <[e-mail]>
Subject: Announcing Kermit for PICK (REALITY) OS on Microdata Systems
Keywords: PICK Kermit

This is to announce a version of Kermit for the PICK operating system,
contributed by Joe Fisher, a computer consultant in Austin, Texas.  This
first release, 0.2C, is written in DATA/BASIC (with some Microdata assembler
subroutines), and has been successfully run only on the Microdata (now
McDonald Douglas) REALITY systems under version 4.2E of the REALITY (the
original PICK) operating system.  It is very much still in the development
stage (as reflected by the version number) and a great deal of work will be
necessary in order to bring it up to the expectations of the Kermit user
community.  It will transfer error-free data however, and has been used with
a number of other Kermits, including IBM PCs with MS-DOS, DEC Pro-350 with
P/OS, VAX/VMS, PDP-11 with RSX, etc.  The programs have been transferred to
PICK 1.3 running on the IBM PC-XT and testing is underway.  Changes in the
I/O code will have to be made there but operation should be more reliable
than on the Microdata.

For the purposes of Kermit distribution, the numerous files have been packed
together into two large files, PICK.BAS and PICK.DOC -- source and
documentation, respectively.  Each file-within-a-file starts with a line of
the form

<<< name >>>

in which "name" is the actual name of the original file.  The files are
available in KER:PICK.* on CU20B, and as PICK * from KERMSRV at CUVMA on
BITNET.

------------------------------

Date: Fri 23 Jan 87 12:12:15-EST
From: Christine M Gianone <[e-mail]>
Subject: Announcing Kermit for the CIE 680/XX Microcomputer
Keywords: CIE Kermit

This is to announce a version of Kermit for the CIE 680/XX microcomputer,
contributed by David S. Lawyer of the University of California at Irvine.
This program is only a stopgap measure until a later version of Kermit (the
so called C-Kermit for example) can be ported to the CIE.  One exception to
this may be for CIE's which only have 256K of RAM.  Since this kermit code
(when compiled) is much shorter than the C-Kermit, it will run well on
computers with limited RAM memory.  This Kermit represents a modification to
the "UNIX Kermit" of 1981-1983.

NOTE TO NON-UCI USERS:  UCI= The University of California at Irvine.
This Kermit program was developed for use at UCI and may not work as well
elsewhere without additional modifications.

The program named kerm (source code kerm.c in the C language) is a program
modified at UCI for use on the CIE computer which adheres to the Kermit
protocols.  You may use Kermit to connect to a remote host, and then log on
to it using the connect command.  Then you may either: use your CIE like a
fairly dumb terminal connected to the remote (i.e. have a session on the
remote computer) or utilize both the CIE Kermit and the Kermit on the remote
to transmit files between the remote and the CIE.

For the purposes of Kermit distribution, the numerous files have been packed
together into four large files, CIE680.C, CIE680.ANN and CIE680.BWR
CIE680.HLP -- source, this message, a beware file and limited documentation,
respectively.  Each file-within-a-file starts with a line of the form

<<< name >>>

in which "name" is the actual name of the original file.  The files are
available in KER:CIE680.* on CU20B, and as CIE680 * from KERMSRV at CUVMA on
BITNET.

------------------------------

Date: Fri 23 Jan 87 12:46:10-EST
From: Christine M Gianone <[e-mail]>
Subject: Announcing Kermit for the MODCOMP Classic running MAX IV OS
Keywords: MODCOMP Kermit

This is to announce a version of Kermit for the MODCOMP Classic running
under the MAX IV operating system, contributed by BOB BORGESON, of SETPOINT,
Inc., 10245 Brecksville Rd., Brecksville, Ohio 44141.  This release is
version A.0., and is written in FORTRAN and Assembler and should be compiled
with a FR5 compiler and assembled using the M5A assembler.  The program has
been tested between the MODCOMP and an IBM PC running PROCOMM, a Macintosh
with Red Ryder and a micro-VAX with Kermit-32.  MODCOMP Kermit has been
donated to the MODCOMP user group, MUSE.

For the purposes of Kermit distribution, the numerous files have been packed
together into three large files, MODCMP.ASM, MODCMP.ANN and MODCMP.DOC --
source, this announcement and documentation, respectively.  Each
file-within-a-file starts with a line of the form

<<< name >>>

in which "name" is the actual name of the original file.  The files are
available in KER:MODCMP.* on CU20B, and as MODCMP * from KERMSRV at CUVMA on
BITNET.

------------------------------

Date: Fri, 23 Jan 87 10:39:40 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: Kermit BITNET Distribution
Keywords: BITNET, KERMSRV, EARN

I recently ordered Mcintosh Kermit from KERMSERV at CUVMA to be sent here to
the University of Liege in Belgium.  This was on the 11th of this month.  12
days after, I just received CKMKER.HQX from the net. I am still waiting for a
DOC file.  And I had promised it for 20th.  Now, during that time, I've had
some peeping into BITNIC's RSCS queue.  It used to amount to a mean 400 to
800 files. I have been amazed by the number of apparently huge Kermit files
(QUKERMIT) waiting for a chance to go.  Short files take over larger ones and
get reasonable delays.  Now my suggestion.  Why not spare a sattelite channel
and install a Kermit redistribution site on the net this side the atlantic?
The problem being where and how to raise interest, you might take advantage
of Info-Kermit to ask for candidates.  If you give away the file server and
claim for reasonable disk space and maintenance time, I think there might
well be some candidates.  The only problem is, consequently, traffic load.
It costs nothing to ask anyway.  Sincerely yours.

[Ed. - Sorry for the inconvenience.  Are there any BITNET (EARN) sites in
Europe that would be willing to act as BITNET Kermit file servers?  We
(Columbia) would be glad to send periodic tapes.  KERMSRV software is
available for VM/CMS, written in Columbia Wylbur Exec language, and for
VAX/VMS written in DCL.  A Kermit BITNET file server could also be
implemented using LISTSERV, which is already widely used in Europe.  The
collection currently stands at about 50 megabytes, and growing.  Meanwhile,
European sites might find it easier to take advantage of the European Kermit
tape distribution centers, one at Lancaster University serving the UK and
Eire, and for continental distribution, "Club Kermit" based in France, a
DECUS VMS SIG-style tape distribution tree.]

------------------------------

Date: Tue 20 Jan 87 00:09:01-EST
From: Christopher P. Lent <[e-mail]>
Subject: Wang Kermit 2.29a Works!!!
Keywords: Wang PC, MS-Kermit

I got the Wang-PC version of Kermit working. I also included all the 2.29a
modules and they seem to work perfectly.

So now all it's missing is:
  Modem control for hangup
  Define/show Key
  Terminal Emulator (beyond WANG BIOS support).
  Actual port names corresponding to Kermit's idea.
   (Currently COM1 and COM2 are equivalent to AUX).

Many things work now which didn't before:
  A. SET BAUD works (up to 19200 baud!)
  B. Status no longer crashes kermit with "Divide overflow".
  C. 2.29a commands (transmit,pause,input ... )

I'm working on the missing parts but I figured I'd send along a MSTWNG.EXE and
MSTWNG.BOO file to allow some of the rest of the world to get going while I
finish this up.

The version number on this version is:

Wang (CP Lent 19 Jan 87) Kermit-MS V2.29a 1 Oct 86

Chris Lent

[e-mail]    (ARPA)
PEDHEM@CUCCFA            (BITNET)
ihnp4!philabs!phri!cooper!chris    (UUCP)

[Ed. - Thanks!  The files have been placed in KER:MSTWNG.BOO and
KB:MSTWNG.EXE, and the new Wang support will be included in the next
release.]

------------------------------

Date: Mon, 19 Jan 87 09:38 EST
From: <[e-mail]>
Subject: Mskermit Version 2.29 Keys for the IBM PC
Keywords: MS-DOS Kermit, IBM PC Keyboard

Hi - regarding Doug Moncur's mapping of VT100 keys for use with MS Kermit
2.29 for the IBM PC keyboard; here at the University Of Buffalo the Micro
Information Center distributes MS Kermit 2.29 to students, faculty and
staff.  A locally written, 140K ASCII file is included, discussing specific
file transfer/emulation situations, especially in VMS and CMS.  Here is a
fairly long excerpt from the file.  If you are interested in receiving the
entire 140K file, please send a blank IBM PC diskette with a written request
and return mailer to Micro Services Group, University Of Buffalo, Computing
Center, Buffalo, NY 14260.  Please note that no electronic requests will be
acknowledged.  However, I can send the entire file to Columbia University if
you feel it is worth considering as an addition to your current MS Kermit
distribution files.

Hope this helps- MICHOT = Micro Services Staff
[e-mail]


       MS Kermit 2.29 uses the IBM PC function key area for these
       functions.  The IBM PC numeric keypad area DOES NOT correlate
       to the VT100 keypad area in MS Kermit 2.29.  In the IBM PC
       function key area, the following diagram shows how the PC
       function keys are defined as VT100 keypad keys:

                                            (shifted function keys)

          +---------+    +---------+        +---------+     +---------+
       F1 |  PF 1   | F2 |  PF 2   |    SF1 | KeyPad  | SF2 | KeyPad  |
          |         |    |         |        |    6    |     |   ,     |
          +---------+    +---------+        +---------+     +---------+
          +---------+    +---------+        +---------+     +---------+
       F3 |  PF 3   | F4 |  PF 4   |    SF3 | KeyPad  | SF4 | KeyPad  |
          |         |    |         |        |    1    |     |   2     |
          +---------+    +---------+        +---------+     +---------+
          +---------+    +---------+        +---------+     +---------+
       F5 | KeyPad  | F6 | KeyPad  |    SF5 | KeyPad  | SF6 |  Enter  |
          |    7    |    |    8    |        |    3    |     |         |
          +---------+    +---------+        +---------+     +---------+
          +---------+    +---------+        +---------+     +---------+
       F7 | KeyPad  | F8 | KeyPad  |    SF7 | KeyPad  | SF8 | KeyPad  |
          |    9    |    |    -    |        |    0    |     |    .    |
          +---------+    +---------+        +---------+     +---------+
          +---------+    +---------+        +---------+     +---------+
       F9 | KeyPad  | F10| KeyPad  |    SF9 |  Not    | SF10|  Not    |
          |    4    |    |    5    |        |  Used   |     |  Used   |
          +---------+    +---------+        +---------+     +---------+


        To function effectively in CMS, you need to know what function
         keys on the IBM PC perform what function in CMS.  The
         following diagrams illustrate how you would use the IBM PC
         function keys (and shifted function keys) in CMS:

                                                (shifted function keys)

             +---------+    +---------+        +---------+     +---------+
          F1 |  PFK1   | F2 |  PFK2   |    SF1 |  PFK9   | SF2 |   PA3   |
             +---------+    +---------+        +---------+     +---------+
             +---------+    +---------+        +---------+     +---------+
          F3 |  PFK3   | F4 |   PA1   |    SF3 |  PFK10  | SF4 |  PFK11  |
             +---------+    +---------+        +---------+     +---------+
             +---------+    +---------+        +---------+     +---------+
          F5 |  PFK4   | F6 |  PFK5   |    SF5 |  PFK12  | SF6 |  Clear  |
             +---------+    +---------+        +---------+     +---------+
             +---------+    +---------+        +---------+     +---------+
          F7 |  PFK6   | F8 |   PA2   |    SF7 |         | SF8 | Insert  |
             +---------+    +---------+        +---------+     +---------+
             +---------+    +---------+        +---------+     +---------+
          F9 |  PFK7   | F10|  PFK8   |    SF9 |         | SF10|         |
             +---------+    +---------+        +---------+     +---------+

         The next diagram scopes out the IBM PC function key
         definitions using the XEDIT CMS Editor with MS Kermit 2.29:

                                                (shifted function keys)

             +---------+    +---------+        +---------+     +---------+
          F1 |  Help   | F2 |   SOS   |    SF1 |         | SF2 |         |
             |         |    | Lineadd |        |         |     |         |
             +---------+    +---------+        +---------+     +---------+
             +---------+    +---------+        +---------+     +---------+
          F3 |  Quit   | F4 | BRKKEY  |    SF3 | Rgtleft | SF4 | Spltjoin|
             |         |    |         |        |         |     |         |
             +---------+    +---------+        +---------+     +---------+
             +---------+    +---------+        +---------+     +---------+
          F5 | TabKey  | F6 | SChange |    SF5 | Cursor  | SF6 |  Clear  |
             |         |    |    6    |        |  Home   |     | Cmd line|
             +---------+    +---------+        +---------+     +---------+
             +---------+    +---------+        +---------+     +---------+
          F7 | Redisply| F8 |         |    SF7 |         | SF8 | Insert  |
             | Subcomm |    |         |        |         |     |         |
             +---------+    +---------+        +---------+     +---------+
             +---------+    +---------+        +---------+     +---------+
          F9 | Backward| F10| Forward |    SF9 |         | SF10|         |
             |         |    |         |        |         |     |         |
             +---------+    +---------+        +---------+     +---------+

       The next diagram illustrates the EDT full screen editor
       keypad definitions that would be used on the IBM PC
       function key area using MS Kermit 2.29:

                                         (shifted function keys)

       +---------+    +---------+        +---------+     +---------+
    F1 |  Gold   | F2 |  Help   |    SF1 |   Cut   | SF2 |  Del C  |
       |         |    |         |        | [Paste] |     | [Und C] |
       +---------+    +---------+        +---------+     +---------+
       +---------+    +---------+        +---------+     +---------+
    F3 |Find Next| F4 |  Del L  |    SF3 |  Word   | SF4 |   Eol   |
       | [Find]  |    | [Und L] |        |[Cngcase]|     |[Del Eol]|
       +---------+    +---------+        +---------+     +---------+
       +---------+    +---------+        +---------+     +---------+
    F5 |  Page   | F6 |  Sect   |    SF5 |  Char   | SF6 |  Enter  |
       |  [Cmd]  |    | [Fill]  |        |[Specins]|     |  [Subs] |
       +---------+    +---------+        +---------+     +---------+
       +---------+    +---------+        +---------+     +---------+
    F7 |  Append | F8 |  Del W  |    SF7 |  Line   | SF8 | Select  |
       |  [Repl] |    | [Und W] |        |[Open Ln]|     | [Reset] |
       +---------+    +---------+        +---------+     +---------+
       +---------+    +---------+        +---------+     +---------+
    F9 | Advance | F10| Backup  |    SF9 |  Not    | SF10|  Not    |
       | [Bottom]|    | [Top]   |        |  Used   |     |  Used   |
       +---------+    +---------+        +---------+     +---------+

        Press GOLD get first to get bracketed [] functions

------------------------------

Date: Mon 19 Jan 87 22:44-EST
From: Ed Barton <[e-mail]>
Subject: Bad Filenames in MS-DOS Kermit Version 2.29
Keywords: MS-DOS Kermit

The IBM-PC implementation of Kermit 2.29 does not catch filenames that are
actually device names.  This was a great deal of trouble to figure out,
though perhaps the problem should have been obvious when it occurred.  For
example, if the file AUX.C is transferred to IBM-PC Kermit, Kermit will get
an error trying to write device AUX, which is how MS-DOS interprets the
filename AUX.C.  AUX.C should have been changed to XAUX.C or something.

------------------------------

Date: Mon, 19 Jan 87 21:07:55 est
From: Joel Seiferas  <[e-mail]>
Subject: MS-DOS Kermit Version 2.29b
Keywords: MS-DOS Kermit

     During a file transfer, in both 2.29a and 2.29b, the "File name" and
"KBytes transferred" data usually flash only briefly on my screen before
disappearing.  I'm working at 1200 baud, over a phone line; and I am dis-
playing on an IBM Monochrome Display, via a 64K IBM EGA.  My PC is an early
one, but I have updated the BIOS and replaced the 8088 with an NEC V20.  My
screen driver is Fansi-Console 2.0.

                Joel Seiferas
                joel@rochester

------------------------------

Date: Tue, 13 Jan 1987 11:40 EST
From: Lawrence Fan <GYACC@CUNYVM>
Subject: Problems Compiling C-Kermit on ATT 3BX Systems
Keywords: C-Kermit, UNIX Kermit, ATT 3BX

I am having a compile problem with C-Kermit 4D(061) on ATT 3BX systems.  I
get warnings when I compile.  Not enough to kill the process but
nevertheless, trouble.  The 'make' did finish and I do have wermit and it is
able to run...  but the warnings are bothering me.  I am enclosing the
warnings when I do 'make att3bx':

    cc -DUXIII -DATT3BX -DDEBUG -DTLOG -i -O -c ckuusr.c
"ckuusr.c", line 1047: warning: illegal pointer combination, op =
"ckuusr.c", line 1048: warning: illegal pointer combination, op =

    cc -DUXIII -DATT3BX -DDEBUG -DTLOG -i -O -c ckutio.c
ckutio.c: 23: extra tokens (ignored) after directive
ckutio.c: 94: extra tokens (ignored) after directive
ckutio.c: 451: extra tokens (ignored) after directive
ckutio.c: 1151: extra tokens (ignored) after directive
ckutio.c: 1166: extra tokens (ignored) after directive
ckutio.c: 1574: extra tokens (ignored) after directive
"ckutio.c", line 950: warning: illegal pointer combination, op ==

    cc -DUXIII -DATT3BX -DDEBUG -DTLOG -i -O -c ckudia.c
"ckudia.c", line 583: warning: illegal pointer combination, op !=
"ckudia.c", line 623: warning: illegal pointer combination, op =
"ckudia.c", line 624: warning: illegal pointer combination, op =

    cc -DUXIII -DATT3BX -DDEBUG -DTLOG -i -O -c ckuscr.c
"ckuscr.c", line 253: warning: illegal pointer combination, op =

Thanks a lot for your help.

[Ed. - There are two problems.  First, your compiler is complaining about
"extra tokens" after #endif and #else directives in ckutio.c, the most
heavily conditionalized module of C-Kermit.  These "tokens" are merely the
proprocessor variables (like ATT3BX) from the matching #if, added for
clarity.  Most compilers don't complain about them, and they don't seem to
be causing any real problem.  Perhaps in the next release they should be
turned into real comments, e.g. "#endif V7" will become "#endif /* V7 */".

All the other messages ("illegal pointer combination") have to do with the
signal() function; see signal(2) in your Unix manual.  'signal()' is
supposedly declared (in <signal.h>) like so:

    int (*signal(sig,func))();
    int sig;
    void (*func)();

i.e. 'signal' is a pointer to a function that returns an integer (see p.195
of the C book).  The 'func' is either a symbol, such as SIG_IGN, defined in
<signal.h>, or a pointer to an integer function that you supply.  Symbols
are defined like so in <signal.h>, at least on my 4.2BSD system:

    #define SIG_IGN (int (*)())1

i.e. a pointer to an imaginary function that returns a constant of 1 (did I
say that right?)  When you invoke signal() to associate a new function with
a particular signal, it's supposed to return a pointer to the function that
was previously associated with that signal, allowing you to save, restore,
and test the interrupt structure.  Thus Kermit does things like:

    int (*istat)(), (*qstat)();

>   istat = signal(SIGINT,SIG_IGN);    /* Let the fork handle keyboard */
>   qstat = signal(SIGQUIT,SIG_IGN);    /* interrupts itself... */
      :
      :
    signal(SIGINT,istat);        /* Restore interrupts */
    signal(SIGQUIT,qstat);

and

>   if (signal(SIGINT,SIG_IGN) == SIG_IGN) ... ;

Your compiler is complaining about the statements marked with ">" because it
believes there is a type mismatch between signal() and istat, qstat, and
SIG_IGN.  Check the definition of signal() in your system's <signal.h> and
see if you can find out why, then let us know.  The rest of the "illegal
pointer combinations" are of the same nature.  If some new release of the
ATT 3BX C compiler and/or header files is causing this problem, we'll have
to do something special within ATT3BX conditionals, since the current setup
seems to cause no problems on other systems.  Let's hear it for portability...
Can any ATT 3BX System V experts out there shed any further light?]

------------------------------

Date: 15 Jan 87 06:22:28 GMT
From: [e-mail] (Gregory Woodbury)
Subject: Update on Commodore-64/C-128 Kermit Wanted
Keywords: Commodore-64

A few months ago, someone asked if there were any plans to update the C-64
kermit for a native mode C-128 kermit.  I have been watching with bated breath
for a reply (but apparently in vain).  It seems that with the expanded memory
available in the 128 that a significantly better version could be made, without
requiring the users to resort to the CP/M mode to get a better kermit.  Any
information on this project would be appreciated.

Gregory G. Woodbury                The usual disclaimers apply
CEO, Research Triangle C-64/128 User's Group
{duke|mcnc|rti-sel}!ethos!ggw                 The line eater is a boojum snark!

------------------------------

End of Info-Kermit Digest
*************************


-------
 5-Feb-87 12:23:07-EST,19235;000000000000
Mail-From: SY.CHRISTINE created at  5-Feb-87 12:18:13
Date: Thu 5 Feb 87 12:18:13-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V6 #4
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 4 Feb 1987       Volume 6 : Number 4

Today's Topics:

                            MS-DOS Kermit 2.29b
                    Note for Testers of MS Kermit 2.29b.
                           MS-DOS Key Definitions
                        Kermit Keyboard Redefinition
                            Keyboard Translator
                                Bugs in WART
                          Commodore-64/C128 Kermit
                 Rationale for C-Kermit's approach to DTR?
                        Kermit for Apple // ProDOS?

----------------------------------------------------------------------

Date: 26 JAN 87 21:02-MDT
From: JRD@USU
Subject: MS-DOS Kermit 2.29b
Keywords: MS-DOS Kermit, 2.29b

RE: Kermit Digest V6 #3

        Ed Barton reported that MS DOS interprets incoming filenames
such as AUX.C as meaning send the contents to device AUX. He recommends
Kermit rename the file to XAUX.C or similar. I just tested this situation
by having a VAX send this note as AUX.C to my micro running PC DOS 3.21.
The file was automatically renamed to AUX00001.C because AUX was recognized
as an existing file. This is with MS Kermit 2.29b. Earlier versions may
not detect the device name.
        There are circumstances where device names are wanted as file
destinations, a serial printer connected to COM1 (AUX) is one of them.
Another small complication is that MS DOS character devices are known by
their names (CON, AUX, PRN, and the like) so that non-standard drivers
can have names in conflict with incoming files without Kermit being
aware of the sensitive names. MS Kermit knows nothing about real device
names per se and relies on DOS itself to reveal a potential conflict.
A workaround is to use an override filename when receiving such a file:
        Kermit-MS> Receive Foo.bar
replaces the incoming filename with Foo.bar.

        Joel Seiferas said the file transfer screen flashed on only
momentarily with his IBM PC w/Fansi-Console 2.0. Kermit follows DOS's
rules for the display. I suggest he try again without Fansi-Console
because such utilities trap video i/o and apply their own rules. Kermit,
of course, is completely unaware of the Helpful Utility and does not
need an ANSI interpreter. There was an earlier problem with Fansi-Console
when Kermit displayed the Connect mode status line; Fansi-Console's author,
Bob Smith, fixed that this summer.

        My local tester of Zenith 100 Kermit version 2.29b says that it
works! One bug concerned cursor addressing after toggling the mode line
while in Connect mode. He promised to bring around tech documentation on the
Z100. Until advantage can be taken of those details I think we ought to try
out MSK 2.29b on the Z100. Therefore, following this note is file MSTZ10.BOO
for the Z100.

        Regards,
        Joe D.

[Ed. - Thanks Joe!  The .BOO file for the Zenith 100 is in KER:MSTZ10.BOO if
anyone wants to test it.  See message from Joe below.....]

------------------------------

Date: 26 JAN 87 22:11-MDT
From: JRD@USU
Subject: Note for Testers of MS Kermit 2.29b.
Keywords: MS-DOS Kermit, Z100 Kermit, Zenith 100 Kermit

                Notes for testers of MS Kermit version 2.29b

        The Kermit Digest, Volume 6 number 3, 20 Jan 1987 contained a list
of improvements and new features found in maintainence release 2.29b. A
slightly longer version is reproduced below. As the Digest notes, we want to
make sure the present material is in good shape so the next major release,
2.30, will be more stable. So, the pleasant task of current testing is to
exercise Kermit, discover problems, and relay symptoms and even solutions
to Columbia or myself.

        One possible problem is MS Kermit will attempt to send 94 byte
packets to a remote host which asks for smaller ones.

        Another is a HANGUP command in a script might clear the modem DTR
and RTS signals so that the next serial port operation thinks they are still
active whereas the modem is asleep.

        A concern is detection of the XON/XOFF flow control characters when
parity is being used. With the new allowance of 8 bit characters an incoming
8 bit character could appear as XON or XOFF with the high bit set. Testing
is needed here.

        Similarly, the new ANSI printer control needs testing.

        Terminal emulation in IBM Kermit is clearly a target for bug hunts.
Difficulties with line wrapping and the like using various editors is a
common problem. If you are using a popular Helpful Utility (the terminate
and stay resident kind) and note an anomoly try to detect if the H.U. is the
culprit so that other users will know of likely pit-falls. Sometimes it is
hard to note what are proper versus observed operations; an annotated LOG is
a good starting point since I can try to repeat the offending character
sequences. Escape characters in a LOG file are best translated to "ESC" or
other printable code for network transmission; a .BOO file also works if an
English description is sent along with it.

        We are especially interested in knowing if MS Kermit 2.29b
successfully communicates with a wide varitey of hosts and through various
communications front-end devices. At this stage Kermit knows little about
Local Area Networks; your experiences would help.

        Thanks for your time and help,
        Joe Doupnik
        [e-mail]
        Center for Atmospheric and Space Sciences
        Utah State University
        Logan, Utah 84322
        [phone] (work)

[Ed. - The updates to MS-DOS Kermit 2.29b are described in KER:MST29B.UPD]

------------------------------

Date: Mon 26 Jan 87 20:07:46-EST
From: D. M. Rosenblum <[e-mail]>
Subject: MS-DOS Key Definitions
Keywords: MS-DOS Kermit, Keys

In the INFO-KERMIT digest, Vol. 6, No. 2, Joe Doupnik asks for comments
about what users would like in a Kermit key translation system.  One thing
that I would like (that I have asked about before) is the ability to specify
key translations that may take effect (and be disabled) only on the receipt
of certain character sequences from the remote host.

For instance, on a real VT1xx terminal (or a VT52, for that matter), there
are certain escape sequences that the host can send that will cause the
keypad keys to generate something other than their normal characters; there
are other escape sequences that the host can send that will cause the keypad
keys to revert to their normal characters.  What would be nice is to be able
to specify a set of key definitions that should take effect automatically
when such an escape sequence is received from the host, and should cease to
be in effect when the escape sequence that would normally turn off the
alternate definitions is received ("cease to be in effect" here would imply
reverting back to either the default key definitions, or possibly some
user-specified defaults -- in other words, the user should be able to
define, say, the long keypad "+" key on an IBM-PC keyboard to mean one thing
most of the time, but to mean something else when the host has sent the
escape sequence that puts the keypad into alternate keypad mode, and to
revert back to his/her "most of the time" definition when the host sends the
escape sequence that puts the keypad back into normal mode).  Since Kermit
is emulating a VT102, the escape sequences that have this effect are
well-defined (the only reason I'm not mentioning them here is that I don't
have a VT1xx manual readily available at the moment), and one wouldn't have
to accomplish the impossible task of thinking of what the right escape
sequences should be to have this effect.

Daniel M. Rosenblum, Ph.D. candidate,
School of Urban and Public Affairs (SUPA), Carnegie-Mellon University

ARPAnet (Internet): [e-mail]
CSnet: use the appropriate gateway to ARPANET
BITnet: DR01%TE.CC.CMU.EDU@CMUCCVMA or DR01%TE.CC.CMU.EDU@WISCVM;
        DR01@CMCCTE or [e-mail] may work from some sites.
CCnet (DECnet): DR01@CMCCTE or [e-mail] or DR01@CMCCTE.#DECnet
                CMSPVX::SPPHDR01 (VAX DECnet only)

------------------------------

Date: Tue, 27 Jan 87  17:45:50 EST
From: "Roger Fajman" <RAF@NIHCU>
Subject: Kermit Keyboard Redefinition
Keywords: MS-DOS Kermit, Keys

I would really like to see the keyboard translator get away from numeric
codes.  It's very unfriendly and thus discourages people from using the
facility.  One way to do this while still maintaining machine independence
is to allow the key names and code names to be defined via Kermit commands.
Then one person has to suffer once for each type of machine (to define the
correspondence between key names and scan codes.  It also allows things like
new F12 keys to be handled without changes to Kermit.  Here is a sample
syntax:

To define keys:

   <command> ::= SET KEY <key-name> <key-def>

   <key-def> ::= <key-item>
              |  <key-item> <key-def>

   <key-item> ::= <number>          [to represent an ASCII code]
               |  <quoted-string>
               |  <key-name>        [to refer to another key definition]
               |  <Kermit-function>
               |  <code-name>       [to refer to a predefined code sequence]

   <Kermit-function> ::= ESCAPE
                      |  BREAK
                      |  PRINTON
                      |  PRINTOFF
                      etc.

   <number> is any of the following:

         decimal integer
         octal integer suffixed with the letter O
         hex integer with a leading digit and suffixed with X

         Suffix letters could be either case.

         Alternatively, the backslash notation could be used for
         octal and hex.

   <quoted-string> is zero or more characters enclosed in single or
                   double quotation marks.  If a quotation mark of
                   the same type as the enclosing ones is contained
                   in the string, it must be doubled.


To define the correspondence between the names of keys and scan codes:

   <command> ::= SET KEYNAME <key-name> SCAN <number>


To define names for ASCII codes, escape sequences, etc.:

   <command> ::= SET CODENAME <code-name> <code-def>

   <code-def> ::= <code-item>
               |  <code-item> <code-def>

   <code-item> ::= <number>
                |  <quoted-string>
                |  <code-name>

Of course, there should be corresponding SHOW commands for each of the set
commands, but I will omit their definitions.

Examples:

Make q key send z:

   set key q "z"

   assuming:

   set keyname q scan ###   [### represents the scan code for the q key]

Make control-G key send ANSI attributes off sequence:

   set key cntl-g normal

   assuming:

   set keyname cntl-g scan ###   [### represents scan code for control-G]
   set codename esc 01bh
   set codename normal esc "[0m"

Define control-L to send login sequence:

   set key cntl-l "login" cr "myname" cr "mypass" cr

   assuming:

   set keyname cntl-l scan ###   [### represents scan code for control-L]
   set codename cr 0dh

The advantage of this scheme is that only once per different kind of machine
does someone have to sit down and set up a file of SET KEYNAME commands to
establish the correspondence between names of keys and scan codes.  Everyone
would then use these names by having a TAKE command for the definition file
in their MSKERMIT.INI file.

Likewise, people could define files of code sequence names.  Some obvious
sets of useful definitions are the mnemonics for ASCII control codes and
VT102 escape sequences.  Again, many people could benefit from the work of
one person in setting up such definition files.

Once such definition files were available, people could redefine the
keyboard without having to think about scan codes, numeric values of ASCII
codes, or obscure escape sequences.

What do you think?

Roger Fajman

------------------------------

Date: Tue, 20 Jan 87 21:25:26 EST
From: Russell Nelson <[e-mail]>
Subject: Keyboard Translator
Keywords: Keyboards

Well, I have experience with two keyboard translators.

Freemacs

Freemacs is a programmable editor that supports the IBM-PC and Z-100.  It is
freely copyable, hence the name, and source is available.  I anticipate that
people will want to port it to other MS-DOS machines besides these two, and
of course you always have a keyboard problem.  The module that contains the
dependent code has a keyboard translator that translates the keys into
strings.  I use strings because the programming language is very string
oriented, and they are more self- documenting than numbers.

Windows

Windows will run on any MS-DOS machine for which a driver can be written.
Specifically, Windows has a keyboard driver, which translates the keycodes
into three sets of numbers: the required virtual keys (every driver must
supply them; they include all ASCII characters plus a few like F1 through
F10), the optional virtual keys (like Left, Middle, and Right for the
optional mouse buttons, F11 through F16, etc)., and the machine dependent
virtual keys.  All but the machine dependent keys are standardized.  F12
returns the same code for all machines on which it exists.

Both are reasonable solutions.  I believe that the Windows version is better
IF you let the user input the names of the required and optional keys.  The
code for the names can be looked up in a table.  I think that it is
resonable to expect the user to look up the machine dependent keycodes.

-russ
GEnie: BH01
BITNET:BH01@CLUTX
uucp:  decvax!sii!trixie!gould!clutx!bh01

------------------------------

Date: 28-JAN-1987 14:08:40
From: [e-mail]
From: Chris Kennington ([e-mail].r-d)
Subject: Bugs in WART
Keywords: C-Kermit, WART.C

     I have been setting up the WART preprocessor as a general tool on my
MSDOS micro (i.e. not part of a unix or similar MAKE), and have found the
two following problems:-

1.  It won't discard a comment on the states line (and so won't even
        process its test-program).  Correction is to insert a call
        to "rdcmnt(fp)" in routine "rdstates()" if after the line
        "if (isspace(c) ......" you come out with c == '/'.
        Note that this problem shows up with a very odd diagnostic,
        as the routine then attempts to insert a null state into
        the table, and the algorithm always gives a match on a null
        state....  You'd still get the diagnostic if there was
        garbage on the line.

2.  Under MSDOS using Aztec-C, because of the anomalous way that this
        compiler treats '\n', you get a .c program output in which many
        of the lines are separated by LFs, not by CRLF pairs (as required
        by MSDOS).  Feeding this to Aztec blows the compiler.  The
        outputs from printf() are OK, since Aztec puts in a CRLF pair
        when '\n' is found in a format-string; but the copying
        routines using "putc(c,fp)" calls come to grief.  Simplest
        cure I can think of (tho' not efficient) is to replace all
        these calls by ones to "outc(c,fp)", where this is coded:-

                outc(c,fp)
                char c;  FILE fp;
                {
                    if (c == '\n') putc('\r',fp);
                    return(putc(c,fp));
                }

        For more generality, this could be conditionally compiled
        with a simple macro for outc(), depending on a #ifdef.

    I may do a bit more generalizing on the WART program, to make it
suitable for programs which have several state-tables in them, possibly
nested one within the other.  If so, I will feed the resulting prog back to
you (both Lancaster & Columbia).

                                        Chris Kennington ([e-mail])

[Ed. - Thanks for the comments on Wart -- we'll put them in its "beware
file" for now.]

------------------------------

Date: Wed, 28 Jan 87 21:39:25 est
From: "Ray Moody" <[e-mail]>
Subject: Commodore-64/C128 Kermit
Keywords: Commodore-64 Kermit

RE: Inquiry in the Info-Kermit Digest V6 #3

    The posting made several months ago is not mine, but I am currently
working on C64/C128 Kermit.  Some of the features I _PLAN_ to add include
support for the C128 80 column screen and VT100 emulation.

    I do _NOT_ plan to have this version of Kermit run in native 128 mode.
The 80 column screen can be accessed in C64 mode, and we are not out of
memory yet.  I see no reason to seperate C128 Kermit form C64 Kermit.

    If you have any features you want to have added to C64/C128 Kermit, please
send me Email.

                                                    Ray Moody
                                                     [e-mail]
                                                     pur-ee!s.cc.purdue.edu!aij

------------------------------

Date: Tue, 27 Jan 87 11:01:03 CST
From: Dave Capshaw <[e-mail]>
Subject: Rationale for C-Kermit's approach to DTR?
Keywords: C-Kermit, DTR

What is the rationale for the way that C-Kermit 4D(061) manipulates DTR?  To
hang up the phone, C-Kermit uses ioctls to explicitly clear and set DTR
which leaves DTR asserted even after Kermit exits.  (This is what surprised
me.)  What is the advantage of this approach over having DTR simply follow
the open/close state of the line?

[Ed. -  The ioctl's are in the function tthang(), in the file ckutio.c, under
the Berkeley conditionals (apparently ATT-type systems do it another way --
setting the baud rate to zero).  The code clears DTR, sleeps half a second,
then restores DTR.  Are there any Unix wizards out there who can explain why
(a) this is necessary, or (b) why it should not be done.  I hesitate to
simply remove the ioctl that restores DTR, because somebody must have put it
there for a reason...  Also, I assume that close() does not affect the state
of DTR?]

------------------------------

Date: Tue 27 Jan 87 00:51:38-PST
From: Mark Crimmins  <[e-mail]>
Subject: Kermit for Apple // ProDOS?
Keywords: Apple II Kermit, ProDOS

There was some talk a while back in the Digest about various people
developing a version of Kermit for Apples that would (i) support 80 column
displays, and (ii) use the ProDOS operating system.  I KNOW there's a demand
for this --- does anyone have a working version of such a thing yet?

Thanks,
Mark Crimmins
[e-mail]

------------------------------

End of Info-Kermit Digest
*************************
-------
18-Feb-87 18:04:40-EST,23191;000000000000
Mail-From: SY.CHRISTINE created at 18-Feb-87 18:00:37
Date: Wed 18 Feb 87 18:00:37-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V6 #5
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 18 Feb 1987       Volume 6 : Number 5

Today's Topics:
                       New Release 2.0 of Kermit/TSO
                      Kermit Article in Computerworld
              Subscription to Info-Kermit Digest Via LISTSERV
                      Info-Kermit Digest Subscription
                        New Info-Modems mailing list
                        C-Kermit on ATT3B2 (Revised)
                 Re: C-Kermit Compile Problems on AT&T 3BX
                      Complaints about AT&T 3BX Kermit
                      C-Kermit 4D(061) on the Masscomp
                            /Q in Fansi-Console
                        Fansi-Console and Tallscreen
                 Bad Filename in MS-DOS Kermit Version 2.29
                    MS-DOS Kermit and Mouse Definitions
                         MS-Kermit Key Definitions
                  Prime Kermit and Kermit Sliding Windows
                              Intel MDS Kermit
              CMS TAKE File for Mac Kermit National Characters

----------------------------------------------------------------------

Date: Tue, 3 Feb 1987
From: Fritz Buetikofer <[e-mail]>
Subject: New Release 2.0 of Kermit/TSO
Keywords: TSO Kermit

Good new year ... good news !!!

Finally I found time to implement long packets into Kermit/TSO !

After reading thorougly the documentation of long packets and sliding
windows, I decided to try an implementation of long packets only, because
you don't get any full duplex channels on a TSO system (Here I refer to the
letter of Roger Fajman of Tue, 30 Jul 1985).  To my astonishment the changes
for long packets were not so many !!  And after one day of testing I had the
first transfer with long packets running. As we are connected via a local
area network to the host, I decided to start with a maximum packet size of
1K, which seems to be wide spread. Then I thought it would be useful, to set
the checktype automatically to 3 (CRC), if the packet size exceeds a certain
limit, which I put to 256 chars. In this period I found severe problems in
this Kermit version, because it sent wrong checktypes in certain cases. So I
had to fix this too ...

At this point I'd like to send a 'thank you' to the makers of Kermit-MS.  As
the latest test version of Kermit-MS supports long packets, I had a good
test partner for my version.

In the past time I had some questions about the extended ascii table,
supported in my Kermit version. I think I should explain a little bit more
what I mean with this feature:

In early days of filetransfer, people usually sent programs to and fro, and
these programs normally included only characters in the range of ASCII
32..126. And all text formating was done on the micros. But later, people
wanted to share the text documents with others. And these texts include now
simple graphics characters, greek chars and in Europe our special
characters, the 'Umlaute'! There I thought it should be possible to specify
on the mainframe side a table (or maybe only a table-extension). And in the
original CMS version of Victor Lee I found this table and implemented a full
ASCII table according to the character set of the IBM PC. When I tranfer
files from my MAC I have to modify this table using an external file with
SET ATOE's.

Well, these are all notes I'd like to append to this new Kermit version.
Changes have been made mainly to the Pascal source, the assembler
subroutines to be able to handle 1K packets instead of 94 chars, in the
documentation file and some little modifications in the install procedure
... so you have to get all TS2KER files !!

I hope you enjoy this new version and take profit of the increased transfer
rate of up to 200% (with long packets) !!

     Fritz

[Ed. - Vielen Dank, Fritz!  And sorry for the delay in installing your new
version.  The TS2KER.* files have all been replaced, and the TS2DS.* files
remain the same.  This TSO Kermit version is an alternative to the NIH TSO
Kermit; the two versions have different sets of features.  Comparative
reviews would be appreciated.  There is still at least one other TSO Kermit
program waiting in the wings, the TSO implementation of the "Portable 370
Kermit".  Watch Info-Kermit for further announcements.]

------------------------------

Date: Wed 18 Feb 87 1:00:00
From: Howie Kaye <[e-mail]>
Subject: Kermit Article in Computerworld
Keywords: Computerworld

For anyone who is interested, there is an article about Kermit in
Computerworld this week (February 16), on page 43.  "Kermit leaps in
popularity" is the exact title, written by Christine Gianone and Frank da
Cruz.

/Howie

[Ed. - Thanks for mentioning the article, Howie.  More Kermit articles are
expected in the future.]

------------------------------

Date: 1987 Feb 9   14:48 EST
From: (John F. Chandler)   <[e-mail]>
Subject: Subscription to Info-Kermit Digest Via LISTSERV
Keywords: LISTSERV

Service to BITNET subscribers through the LISTSERV redistribution system
seems to be stable now, so I'm ready to do my part in relieving the load at
WISCVM by dropping my direct subscription to the Kermit Digest.  With only
one exception, the issues have arrived via the BITNET redistribution no more
than a day later than via direct mail and typically within a few hours.  It
might be a good idea to announce these hopeful statistics to the list as a
whole and to urge all BITNET subscribers to switch to LISTSERV membership.

                                                John

[Ed. - Thanks to all of you who have subscribed to LISTSERV@UGA to relieve
the WISCVM load.  Your help is greatly appreciated.  After trying this out
and making sure it works, please be sure to drop your direct Info-Kermit
subscriptions.  See message below to find out how to subscribe to LISTSERV.]

------------------------------

Date: Wed, 11 Feb 87 09:59:54 EST
From: "Alan H. Holland" <FEAHH@VTVM1>
Subject: Info-Kermit Digest Subscription
Keywords: LISTSERV

I saw the article in Info-Kermit Digest about the problem with ARPANET
congestion.  I have subscribed to the Info-Kermit Digest redistribution
being done by LISTERV at UGA on BITNET.  You may remove my name from the
original distribution being done at CU20B.

You may wish to advise your other BITNET subscribers of this redistribution
service.  For a user on an IBM VM/CMS system on BITNET, the syntax to
subscribe to the Info-Kermit Digest redistribution would be:
     TELL LISTSERV AT UGA SUB I-KERMIT user's-real-name
where user's-real-name may contain blanks and periods and does not require
any quote marks.

------------------------------

Date: Fri, 6 Feb 1987  23:49 MST
From: Keith Petersen <[e-mail]>
Subject: New Info-Modems mailing list
Keywords: Info-Modems

Announcing a new Internet mailing list [e-mail], a
discussion group of special interest to modem users.  Info-Modems is
gatewayed to/from Uucp's "comp.dcom.modems".

The mail archives on SIMTEL20 for this list are:

<ARCHIVES.MODEMS>MODEMS-ARCHIV.TXT  for the current messages

<ARCHIVES.MODEMS>MODEMS.ARCHIV.ymmdd  for the older messages

The files are available via ANONYMOUS FTP for those with TCP/IP access to
the Internet.

Submissions to the group should be addressed to [e-mail]
and administrative requests to [e-mail].

--Keith Petersen <[e-mail]>

------------------------------

Date: Thu, 29 Jan 87 11:56:16 PST
From: [e-mail] (David Ragozin)
Subject: C-Kermit on ATT3B2 (Revised)
Keywords: C-Kermit, AT&T 3B2

Here is a corrected version of my earlier note in which "ckcdeb.h" was
incorrectly referenced instead of "ckcker.h". Changes marked by ! in margin.
>From rag Thu Jan 29 09:10:57 1987
>To: [e-mail]
>Subject: C-Kermit on ATT3B2
>
>On my new 3b2/400 with C-FP+ floating point C compiler, the only "serious"
>problem encountered arose from the fact that <sys/types.h> defines
!"typedef unsigned char    unchar".  Since  "ckcker.h" gives a #define unchar(a)
>MACRO, it was necessary to make the following changes:
!    1) In each module including both types.h and ckcker.h, they
>        had to be included in that order.
!    2) The #define unchar(c) in ckcker.h had to be preceeded by
>        #ifdef unchar
>        #undef unchar
+        #endif
>Sorry I don't have access to my machine right now to check exactly which
>modules were affected.
>
>(These changes were applied to (061) version code).
>
>By the way, has anyone had success using C-Kermit on a 3B2/400 to gain
>access to a "bi-directional" port? (The 3b2 with sysV.3 at least, has
>a "uugetty" process which looks for logins on a port, but will allow
>a local user to gain access for outgoing use.  The protocol for gaining
>access isn't clear to me - it seems to be connected with locking the
>port line before you try to open it.  What else must be done - special open
>or ??? - is unknown to me at this time. By the way - doesn't looking to see
>if you can lock a line  and actually locking it, before you try to open it
>for exclusive use make sense in general?)

------------------------------

Date: Wed, 28 Jan 87 15:04:27 EST
From: rutgers!unirot!citibank![e-mail]
Subject: Re: C-Kermit Compile Problems on AT&T 3BX
Keywords: C-Kermit, AT&T 3BX

    I ran a make on the 4D(061) source obtained from okstate using a
3B15 under V.2.1.1 and had no errors as described.  The preprocessor
apparently handled the #endif XXX without problems, nor did I have pointer
problems with the signal() calls.

I suggest he check his makefile for any funny redirection of include
directories, etc.  The problem doesn't seem to be in the standard makefile
or code.

                    Bob Halloran, Consultant

UUCP: rutgers!unirot!halloran            DDD: [phone] eve ET
CSNet/ARPA: unirot![e-mail]     ATTmail: RHALLORAN

------------------------------

Date: Mon, 2 Feb 87 09:40:02 CST
From: Christian G. Herzog <ihnp4!laidbak![e-mail]>
Subject: Complaints about AT&T 3BX Kermit
Keywords: AT&T 3BX Kermit

RE: Info-Kermit Digest V6 #3
In regards to the blurb on complaints when porting to ATT3Bx systems :

    Starting with System V Release 3, signal() is now defined
    as returning a pointer to a function returning void.

    This was kind of makes sense since you couldn't use the return
    value of a signal function anyway.  Signal probably would have
    been defined this way from day one if the 'void' data type
    had existed.

Chris Herzog
ihnp4!laidbak!zog
Lachman Associates

------------------------------

Date: Mon, 9 Feb 87 14:24:24 CST
From: sun!soma.bcm.tmc.edu!rice![e-mail] (Stan Barber)
Subject: C-Kermit 4D(061) on the Masscomp
Keywords: C-Kermit, Masscomp Kermit

I have finally taken time to check out the C-Kermit release of late last
year on the Masscomp family of computers. Here are the results of the test:

"make rtu" makes a working version except the usualy problems with the uucp
spool locking problems.

"make bsd" makes a working version if it is used in the ucb environment with
the enclosed modifications make to the ucb environment libc.a.  The problem
with the spool locking remains.

I also provide a version of the acucntrl program for the masscomp that can
toggle the getty on the line and provide line locking if needed. So people
can add "-DNEWUUCP" to the CFLAGS line if they use this program.

Finally, I tested the dial command with our Hayes modems, and it doesn't
work. I have not tested why. I will try to test it out sometime.

Here is the "fix" to allow "make bsd" to work on the masscomp.
This "fix" is unsupported, but it does seem to work.

#!/bin/sh
# this program will a bug in the ucb universe libc that seems
# to remain uncorrected on the Masscomp
# even with the new release of the run-time libraries.
# You must be the superuser to use this.
ar x /.attlib/libc.a ttyname.o
ar r /.ucblib/libc.a ttyname.o
rm ttyname.o
ranlib /.ucblib/libc.a
exit 0

Stan Barber, Moderator
mod.computers.masscomp (or comp.sys.masscomp)
[e-mail]

------------------------------

Date: Thu, 29 Jan 87 21:48:57 est
From: Joel Seiferas  <[e-mail]>
Subject: /Q in Fansi-Console
Keywords: MS-DOS Kermit, 2.29b, Fansi-quick

     Jim Celoni ([e-mail]) solved my problem with the file
transfer screen in 2.29b for the IBM PC: ``The file transfer screen is
incompatible with Fconsole 2.0's /Q1 option.  Fansi-quick really does speed
things up, so all I do is toggle it before and after the transfer.  Good
thing they put /Q1 /Q0 on keystrokes...  +j'' This does solve the problem.

                Joel Seiferas
                [e-mail]

------------------------------

Date: Fri, 06 Feb 87  19:56:58 EST
From: "Roger Fajman" <RAF@NIHCU>
Subject: Fansi-Console and Tallscreen
Keywords: Fansi-Console, Tallscreen

>         Joel Seiferas said the file transfer screen flashed on only
> momentarily with his IBM PC w/Fansi-Console 2.0. Kermit follows DOS's
> rules for the display. I suggest he try again without Fansi-Console
> because such utilities trap video i/o and apply their own rules. Kermit,
> of course, is completely unaware of the Helpful Utility and does not
> need an ANSI interpreter. There was an earlier problem with Fansi-Console
> when Kermit displayed the Connect mode status line; Fansi-Console's author,
> Bob Smith, fixed that this summer.

The problem that I encountered with the displaying of the attributes of the
status line in MS-Kermit 2.29a was related to Tallscreen, not Fansi-Console.
Bob Smith, the author of Tallscreen, provided a fix.

The problem was that the video attributes of the status line were not
displayed correctly.  The information itself was properly displayed.

The confusion probably arose because part of Tallscreen is a replacement for
ANSI.SYS.  It is, however, a completely separate product from Fansi-Console,
which also replaces ANSI.SYS.

Roger

------------------------------

Date: Wed, 28 Jan 87 15:39:42 est
From: Bennett E. Todd III <ecsvax![e-mail]>
Subject: Bad Filename in MS-DOS Kermit Version 2.29
Keywords: MS-DOS Kermit

RE: Info-Kermit Digest V6 #3

>From: Ed Barton <[e-mail]>
>Subject: Bad Filename in MS-DOS Kermit Version 2.29
>
>The IBM-PC implementation of Kermit 2.29 does not catch filenames that are
>actually device names.  [...]

and a fine thing, too! I can print files from remote systems by downloading
to a file named "prn".... This is a DOS "feature", and is quite well
documented in elementary DOS tutorial materials. It's nice that this feature
(allowing access to character-special devices via names in the filename
space) isn't disabled by some well-meaning hackery. Allow the system to
behave as documented! (Note: I do NOT intend here to claim that MS-DOS is
particularly correct in its documented behavior; that is a separate issue).
If you don't like the current behavior of MS-DOS vis-a-vis filenames
matching device names, there is an undocumented DOS interrupt which can be
used to change it.  It is called the AVAILDEV function, and is stacked up on
the same DOS function number as the SWITCHAR function. Specifically, to
prevent prn.dat from referring to the printer (or any other such device name
overriding) issue the following machine language instructions (the debugger
can be used to make a .COM file to run these):

    mov    ax,3703h
    xor    dl,dl
    int    21h

-Bennett

------------------------------

Date: Mon, 02 Feb 87 21:58:22 EST
From: "James H. Coombs" <JAZBO@BROWNVM>
Subject: MS-DOS Kermit and Mouse Definitions
Keywords: MS-DOS Kermit, Microsoft Mouse

I am thinking about writing a Microsoft Mouse menu for use with Kermit.
Is anyone interested in sharing definitions/ideas?  Thanks.  --Jim

P.S.  I am primarily interested in experimenting with using the mouse
when emulating a VT100 on an IBM mainframe (CMS, XEDIT, etc.), but it
might be best to concentrate on supporting such Kermit functions as
Push to DOS.  One problem that I see immediately is that cursor movement
is sluggish; the speed at which one can move a mouse makes this sluggishness
obvious and problematic.  Comments, suggestions?

------------------------------

Date: Mon, 9 Feb 1987 11:46:06 CST
From: Dan DeNise <KERMIT@UMRVMB>
Subject: MS-Kermit Key Definitions
Keywords: MS-DOS Kermit, Key Definitions

I just got Info-Kermit Digest V6 #4 today, and felt moved to respond to
Roger Fajman's suggestion of adding SET commands for key names.  I don't
like it.  It would add bulk to an already bulky program and reading and
decoding key name definitions as well as key definitions would make startup
even slower than it is now.

I think a simpler and better solution is to add a prompted version of the
SET KEY command.

   set key q z

could be entered as:

   set key
   Press a key: q
   Scan code is
   Enter definition: z

and

   set 5 kexit

could be entered as:

   set key
   Press a key: <Alt-X>
   Scan code is 5
   Enter Definition: kexit

This would facilitate interactive key definitions by not forcing people to do
a SHOW KEY command to find the scan code before doing each SET KEY commmand.

I also think Kermit should be able to write the current key definitions to a
file.  The most appropriate form, of course, is a series of SET KEY commands,
ready to be TAKEn in MSKERMIT.INI.

Dan DeNise
[e-mail]

------------------------------

Date: Sun 1 Feb 87 01:14:52-PST
From: Bob Larson <[e-mail]>
Subject: Prime Kermit and Kermit Sliding Windows
Keywords: Prime Kermit, Sliding Windows

I've noticed a couple of problems in prime kermit:

The character '*' is converted to the wildcard character '@' in filenames.
Since '*' is a legal character in filenames, this can cause problems.  This
is why you can't use a relitive pathname such as '*>subdir>file' in a get
command from another system.

Wildcard characters '+' and '^' are not expanded unless the pathname also
contains an '@'.

The default window size is much bigger than the tipical terminal input
buffer, so windowed kermit operation may be slower than non-window unless it
is set to something reasonable.  (2 or 3)

Parity is not set or unset consistantly on outgoing data.  Specificly, the
parity bit is set on the quote character in the send-init packet and not in
the data packets.

I'm working on a new version, modernized (requires 20.0 or later primos)
with connect mode and several other new features.  In my test version, I've
noticed that the NAK of most desired on receiving a short packet tends to
cause the same packet to be sent numerous times.  (The errors were caused by
receive buffer overflow.)  Delaying the NAK of the most desired (which has
already been NAKed once) until the receive buffer is empty seems to me to be
a better policy, but I havn't actually tried it.

[Ed. - Thanks!  Your message was added to PRIME.BWR.]

------------------------------

Date: Wed, 04 Feb 1987 13:40 PST
From: [e-mail]
Subject: Intel MDS Kermit
Keywords: MDS Kermit

A while ago in the digest I questioned if anyone knew which Kermit version
for the intel MDS's was most current in view of closely spaced revision
dates. I have examined both versions and the MD2* files are obviously
enhanced with respect to functionality.

  However, in examining them carefully, the implementation of the new
features, principally server commands (not server mode) appears to have been
done with block-copy type editing since many text strings are duplicated
even where not exactly appropriate. Moreover, the logic does not completely
support the protocol manual specifications: It will not handle long replys
and interprets any ACK reply as init information instead of display text.
This all seems rather harmless and I don't doubt that it works for the
implementor, particularly since the comments and many menus and prompts
specifically refer to a VAX as the remote host machine and may not have had
widespread testing.

   I am undertaking a correction of these features and also adding support
for several low-level enhancements: binary quoting, alternate checksums,
long (and extra long) packets, repeat prefixing, and character parity. Will
probably also add xon-xoff control and server mode later. In conjunction
with this I am reorganizing the source along more functional lines and to
balance module size somewhat (many MDS's still operate on painfully slow
floppies and have 808x chips ...  compiles can take a while). I notice that
several other people are working on modifications (according to the AAWAIT
file), mostly to upper level features such as TAKE, SETs, menus, which I am
not addressing. I would like to contact them for cooperative purposes but no
network addresses are listed.

   If any are on the net, I would appreciate being contacted to coordinate
and merge changes.

   Jeffrey Sicherman
   [e-mail]

------------------------------

Date: Fri, 06 Feb 87 09:22:45 ULG
From: Andre PIRARD <[e-mail]>
Subject: CMS TAKE File for Mac Kermit National Characters
Keywords: CMS Kermit, Macintosh Kermit, National Characters, EBCDIC, ASCII

I told you some time ago of national characters and an emerging IBM EBCDIC
set called "table 500" to support them.  I've composed an according
conversion table to be TAKEn on CMS KERMIT for use with MacKermit.
Pitifully, it's only useful in file transfer mode.  I see no way in terminal
mode (on the 7171) that would not involve screen codes translation on the
Mac.  By the way, there is still the problem of the "OPTION dot" key that is
nowhere to find on our national keyboards.  We have : (colon) where you have
"." (dot) and our dot is the shifted key to the right of your M (which is
our ",?" (isn't that easy?)).  Neither OPTION ":" nor "." (which needs the
shift key) nor others yield the interrupt.  Do you have a hint?  Or wouldn't
there be a more "international" choice to be chosen in a future version?
Here goes my file for anyone it can help:

[Ed. - Thanks, Andre.  We've never seen a European Macintosh Keyboard.  Can
anyone else offer any hints?  Meanwhile, Andre's translation table has been
added to CKMKER.BWR and CMSKERM.BWR.]

------------------------------

End of Info-Kermit Digest
*************************
-------
27-Feb-87 17:39:26-EST,20339;000000000000
Mail-From: SY.CHRISTINE created at 27-Feb-87 17:38:14
Date: Fri 27 Feb 87 17:38:14-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-kermit Digest V6 #6
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 27 Feb 1987       Volume 6 : Number 6

Today's Topics:

                Kermit Becomes Finalist in Fluegelman Award
   MS-DOS Kermit 2.29b Test Prerelease for IBM PC, Clones, & Generic DOS
                     Bug in QK-Kermit TV4010 Emulation
                           ProDOS Apple // Kermit
                      An Apple// ProDOS 80-col Kermit
            Differences between Unix C-Kermit and Amiga C-Kermit
                         Kermit over DECserver-200
                        SET ETOA/ATOE in CMS KERMIT
                          C-Kermit on SCO Xenix V
                   Kermit & Curses Box Function Problem?
                        MacKermit on a 128K Machine?
                           Kermit-Intel (MLINK)?
                           Apple 2 GS and Kermit?
                         C-Kermit on an AT&T 7300?

----------------------------------------------------------------------

Date: Wed 19 Feb 87 12:24:16-EST
From: Christine M Gianone <[e-mail]>
Subject: Kermit Becomes Finalist in Fluegelman Award
Keywords: Fluegelman Award

Kermit has been selected as one of the 11 finalists for the First Andrew
Fluegelman Award.  The award is given for "a substantial, innovative
contribution to the personal community in commercial, shareware, or public
domain software".  The award was established in 1986 by PCW Communications,
Inc. to commemorate Fluegelman's contributions to the software field;
Fluegelman developed PC Talk, "the first easy-to-use and powerful
communications program for the PC".  The annual award is made possible
through a fund which was established in his name after his death in July,
1985.  Six reputable judges are currently evaluating Kermit software.

------------------------------

Date: Wed 19 Feb 87 12:24:16-EST
From: Christine M Gianone <[e-mail]>
Subject: MS-Kermit 2.29B for IBM PC Family Installed
Keywords: MS-Kermit

A "maintenance release" of MS-DOS Kermit for the IBM PC family and compatibles
has been installed in the Kermit distribution as the preferred PC Kermit
version, to bridge the gap between version 2.29, which has several serious bugs
(the worst two: it can't transfer files when using half duplex line turnaround
handshaking, and it has trouble with certain internal modems), and 2.30, which
will be the next major release.  The interim release is dubbed 2.29B, dated 19
Feb 87, and fixes most known bugs and problems in 2.29.  It is essentially the
same as the version announced in Info-Kermit V6 #2 on 20 Jan 87, but with a
couple additional bug fixes.  Starting now, this will be the version that comes
on our PC Kermit distribution diskette.

The program is in KER:MSTIBM.BOO (decodable into an .EXE file using an MSBPCT
program), and the list of corrections is in KER:MSKERM.BWR.  This version also
contains, in "preview form" some of the new featues planned for 2.30, including
ANSI printer control, Kermit script language, and extended-length packet
support.  Description of these new features is in KER:MSR29B.UPD.  Sources for
this version are not available, since they are still undergoing rapid change as
2.30 is readied for release.  Profuse thanks to Prof. Joe R.  Doupnik of Utah
State University for the tremendous amount of work and skill that went into
this release, and is also going into 2.30, and to the many volunteers who
helped test the various fixes and changes.  Much more will be said about this
when 2.30 is released.

------------------------------

Date: 2-FEB-1987 09:02:30
From: [e-mail]
Subject: Bug in QK-Kermit TV4010 Emulation
Keywords: QK-Kermit

We have been trying to implement the QK - tv4010 version of kermit running
under MS-DOS on an IBM and an IBM clone and have run into some difficulties.
First of all there is a bug in the connect.pas source file for the tv4010
where a comment has been placed in the middle of the definition for the tab
spacing, this is easily overcome by moving the comment.  Other problems have
not proved so easy to solve:

   Once the file has been compiled with the relevant Turbo Graphics routines
we tried to do some graph plotting with routines from simpleplot on a VAX
under VMS4.3, we then discovered you need the file 4x6.fon on the disk, with
this we got some rather poor and sometimes unintelligable text.  Our graph
plotted well enough but that was it, the emulator did not seen able to cope
with being told to leave graphics mode, the only way out I could find was to
reboot the micro !!!! and then run kermit again.  Does anyone have a lead on
this problem?

    Another strange problem came to light.  On running one of our VAX FORTRAN
programmes which runs perfectly well on a standard terminal and under Kermit
2.29a on the micros, and which does not involve graphics we found that it
gives different results ??!!??  (No we don't believe it either!!)

    I hope these comments will be of some use, and perhaps there is someone
around who has encountered and overcome them.

                Yours,
                       Graham Barlow  ([e-mail])

[Ed. - Thanks for the comments -- they've been kept as KER:QKMSTV.BWR.]

------------------------------

Date: Fri, 06 Feb 87 17:26 EST
From: Mark B. Johnson <CDTAXW@IRISHMVS>
Subject: ProDOS Apple // Kermit
Keywords: ProDOS, Apple II Kermit

In response to Mark Crimmins' query in Info-Kermit Vol 6, #04, there does
exist a very nice 80-column, interrupt-driven, ProDOS version of Kermit for
the Apple II series.  Ted Medin has done a great job with the Stevens
version and is currently up to V3.73 which works well in 80-column mode and
with ProDOS.  It runs as a shell program so it must be used with
BASIC.SYSTEM, and currently it has to be installed (originally) under DOS
3.3.  It supports both DOS 3.3 and ProDOS and works with several serial
interfaces.

I am currently working on a version specific to ProDOS 16 and the IIGS, and
I hope when finished to pare it back for ProDOS 8 with mouse support on the
rest of the II line.  Check the file AAWAIT on KERMSRV for more details on
all the Apple II Kermits.

Mark

[Ed. - Because of some uncertainty about who's doing what to which version,
Ted's Kermit hasn't been installed in the Columbia Kermit distribution yet.
See below.]

------------------------------

Date: Tue 10 Feb 87 13:41:08-PST
From: Mark Crimmins  <[e-mail]>
Subject: An Apple// ProDOS 80-col Kermit
Keywords: Apple II Kermit

My query in a previous Digest was rewarded:  Ted Medin replies,

>From: Ted Medin <[e-mail]>
>To: [e-mail]
>Subject: kermit
>Message-ID: <M1987$[e-mail]>
>
> We have been running 80 cols for a couple of years and prodos for
>a year or so. Ftp to nosc-shark.arpa as anonymous then:
>
> cd ker*mit.           - dont forget the .
> hash                  - so you can see the bytes fly (or crawl)
> get readme            - read this for instructions
> dir                   - you will need this after reading
>
>                                  Ted

The program works great.  It's a shell to BASIC.SYSTEM, has all the usual
functions, and even a limited server mode.  For some reason I haven't
tracked down yet, though, a program run after leaving this kermit, but
without rebooting ProDOS, will often crash (this makes it not so good a
thing to run from a /ram disk, etc.).

I also received several promising messages of fancy Apple Kermits in the
works for the IIGS, and for II's with mouse-interfaces, etc.  Can't wait.

Mark

------------------------------

From: rutgers!lll-lcc!cae780!videovax.TEK.COM![e-mail]
Date: Fri, 20 Feb 87 08:52:39 PST
Subject: Differences between Unix C-Kermit and Amiga C-Kermit
Keywords: C-Kermit, Amiga Kermit

A few months ago, I received copies of C-Kermit 4D(060) for both our
VAX and my Amiga.  Since I am by nature curious, I diff-ed the files
that both had in common.  I found some interesting things (e.g., in
the Unix source for ckwart.c, there was a missing parameter in an
"fprintf" statement), some changes one would expect (e.g., a bunch
of added "#if[n]def AMIGA . . . #endif" constructs), and lots of
seemingly unnecessary changes.

In a number of the Amiga ckc* and cku* files, form feeds (^L) were
substituted for the blank lines or "/*Form Feed*/" comments that were
present in the Unix version.  When one diffs the two versions of
ckucmd.c, ckuusr.c, ckuus2.c, and ckuus3.c, reams of output showing
the spacing changes obscure the real differences between the two files.

In these same files, the Amiga versions have "printf" substituted for
each occurrence of "printf2" and "printf3".  The following usage counts
were obtained with grep:


                                      Amiga             Unix
                                      -----             ----

                   /   printf           52               13
        ckucmd.c  {    printf2           0               33
                   \   printf3           0                7

                   /   printf          104               63
        ckuusr.c  {    printf2           0               31
                   \   printf3           0               14

                   /   printf            7                1
        ckuus2.c  {    printf2           0                4
                   \   printf3           0                2

                   /   printf           36               31
        ckuus3.c  {    printf2           0                4
                   \   printf3           0                1


It is my understanding that the intent is that C-Kermit be compilable on
any compiler (no matter how old), even if it does not support variable
numbers of arguments.  Thus, the Amiga versions of these files are not
compatible with the generally-distributed C-Kermit sources.  I do not
understand why these changes were made, as they serve only to relieve
the C preprocessor of an insignificant burden.  (I would hope that all
the compilers available for the Amiga can handle a "#define printf2
printf"!)

Not only do these changes make the supposedly "common" parts of the
Amiga C-Kermit source unique, they also cause diff to produce reams of
output, obscuring the true nature of the differences between the Amiga
sources and the Unix sources.

An even more serious consideration to Amiga owners (myself included), is
the risk of becoming cut off from the mainstream of C-Kermit development.
Recently (Info-Kermit Digest, Vol. 6 No. 1), Gordon Scott reported a bug
that seems to reside in ckcfns.c.  Since this file was not modified
significantly by the Amiga C-Kermit developers, a fix could be installed
simply by recompiling with the updated file.  However, if a bug is found
in ckucmd.c or ckuus[r23].c, we would have to depend on the people who
did the port to the Amiga to update the source files, or hand-install
the changes from the diffs.

I realize that C-Kermit propagates primarily by volunteer labor, and that
those who keep it all together at Columbia have relatively little control
over the individual implementations.  I would hope, though, that gentle
persuasion will be applied to those who charge down unmarked paths, thus
increasing the entropy of C-Kermit.

I would be happy to write a letter containing these thoughts to the
developers of the Amiga version of C-Kermit.  However, I do not wish to
hassle them if my understanding is incorrect.  Please let me know what
the situation is with regard to the Amiga version, and if you think a
letter to the Software Distillery would help.

                    Steve Rice
{decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!stever

[Ed. - You will find most of your complaints are addressed in 4D(061), released
in September 86 -- one of its main purposes was to replace the Amiga support,
putting the rest of C-Kermit more or less back the way it was.]

------------------------------

Date: 27 Jan 87 07:11 +0100
From: [e-mail]
Subject: Kermit over DECserver-200
Keywords: DECserver-200

Re: Info-Kermit Digest V6 #1

We use Kermit over our DECserver-200's without any problems.

Our configuration is:

VAX8300-DEBNT(BI Ethernet Interface)-DECserver-200/MC(with modem control)-
Sytek LocalNet-20 (Broadband LAN)-any PC (AT, XT, HP150, Apple).  The ports
on the DECservers are configured for a dedicated service to our VAX, i.e.
the DECserver is invisible for the user who seems to be connected to the VAX
directly.  We have a speed of 9600 baud and XON/XOFF flow control (as opposed
to Greg Elder's opinion mentioned in Kermit Info Digest V6 #1).

Best regards, Michael.

Real Name:     Wolfgang Michael Terenyi
MAILNET:       W._Michael_Terenyi_(SANDOZ)@QZCOM.MAILNET
ARPANET:       W._Michael_Terenyi_(SANDOZ)[e-mail]
JANET:         W._Michael_Terenyi_(SANDOZ)[e-mail]
BITNET:        P1117@QZCOM
CompuServe:    76067,1434
Telephone:     [phone]
G3 Fax:        [phone]
Telex:         132287 sfi a
Real Address:  SANDOZ Research Institute
               Brunner Str. 59
               A-1235 Vienna
               Austria, Europe

------------------------------

Date: Mon, 23 Feb 87 14:35:23 SA
From: "Kai U. Leppamaki" <LK-KLE@FINHUT>
Subject: SET ETOA/ATOE in CMS KERMIT
Keywords: VM/CMS Kermit

Andre Pirard (and others, including myself) have made alternative translation
tables to be used with CMS KERMIT.  The problem is, however, that modifications
introduced simply by SET ETOA/ATOE commands only work on IBM 7171 (or similar)
protocol converter lines where file transfer is based on "transparent" mode
operation (i.e. no EBCDIC<->ASCII conversion done by the operating system).

On half duplex "dumb" tty-lines (3705 or the like) the ETOA & ATOE tables
must not modified.  They must match the system tables in order to have KERMIT
working at all !

However, I have modified CMS KERMIT 3.1 to include additional translation
tables.  They only affect transmitted data within KERMIT but not the way
packets are coded/decoded.  The user may freely modify these new tables but
not the original tables which still must remain intact.

I trust Andre's translation tables are fully compatible with my modifications
although not applicable here in Finland - different tables must be developped
for each language and/or national convention.  I have composed Finnish tables
for the Mac and IBM PC character sets.

Kai U. Leppamaki
TeKoLa (= Helsinki University of Technology, Computing Centre)
Espoo, Finland
Acknowledge-To: <LK-KLE@FINHUT>

------------------------------

Date: Tue, 10 Feb 87 08:24:53 est
From: jl42#@andrew.cmu.edu (Jay Mathew Libove)
Subject: C-Kermit on SCO Xenix V
Keywords: C-Kermit, SCO Xenix V

I am attempting to use C-Kermit (dated April 1986, from CMCCTE::PK:<KERMIT>)
on an IBM PC/AT compatible (as yet, no compatibility problems- been running
for over a year) configured with two serial ports, com1: and com2: with a
modem attached to com1. I can use the modem fine from DOS, but under the
S.C.O. Xenix System V version 2.1.3 that I have just installed I can not
convince CKermit to talk to the modem. The XENIX system has allowed calls to
come in, and indicates that it should work with communication software (it
has uucp utilities that I am clueless about) so I think it must just be an
idiosyncrasy that I don't know how to deal with between CKermit and my
machine.

If anyone has information about getting CKermit to run on an SCO XENIX V
operating system on an AT, please help!

Thanks in advance-
 Jay Libove
         [e-mail]
         [e-mail]

------------------------------

Date: Friday, 6 February 1987  16:52-MST
From: nosc!humu!uhmanoa!uhccux![e-mail] (The Perplexed Wiz)
Subject: Kermit & Curses Box Function Problem?
Keywords: MS-Kermit, Curses Box Function, Terminal Emulation

Does anyone have a fix for the Kermit H19 and VT102 emulation modes?  I've
noticed that at least one curses function does not work correctly with
Kermit: box.  I am fairly sure of this because I switched to the Mark of the
Unicorn PC/InterComm VT100 emulator to make sure it was not some PC
flakiness causing the problem.  The curses functions worked fine using the
PC/InterComm emulator.

Given the following conditions:
    Ultrix 1.2 (sort of 4.2bsd) on a VAX 8650
    set term=vt100
    Kermit 2.29 on any kind of PC, AT, or clone
    CGA or EGA display
    C program using curses' box function

The symptoms are:
    Only the top and right edges are displayed
    move'd alphanumerics sometimes appear and sometimes don't
        after a refresh() call.

Thanks....todd

Todd Ogasawara, U. of Hawaii Computing Center
UUCP:        {ihnp4,seismo,ucbvax,dcdwest}!sdcsvax!nosc!uhccux!todd
ARPA:        uhccux![e-mail]
INTERNET:    [e-mail]

------------------------------

Date: Sun, 15 Feb 87 11:58 EST
From: Mark B. Johnson <[e-mail]>
Subject: MacKermit on a 128K Machine?
Keywords: Mac Kermit

Is anyone successfully using MacKermit V0.8(34) on a 128K machine?  I am sure
we had done it here sometime back, but I have tried it recently with several
different versions of the Finder and System and keep getting system crashes
when trying to Send files.  We are sure it is the System and Finder, and are
wondering if anyone who might be doing it successfully could send us their
configuration.  Thanks again.

------------------------------

Date: Thu 29 Jan 87 08:53:33-CST
From: David M. Gracia <[e-mail]>
Subject: Kermit-Intel (MLINK)?
Keywords: MLINK, Wyse PC

Does anyone have any experience running Kermit on a Wyse pc talking to
Kermit under MLINK on an Intel 310 If so, I need to know your secret. I am
not having any luck getting it to run.  Thanks.
    Dave

------------------------------

Date: Wed 25 Feb 87 17:36:33-GMT
From: Alan Greig <[e-mail]>
Subject: Apple 2 GS and Kermit?
Keywords: Apple II Kermit, GS

Has anyone tried apple kermit on the GS ? I have had a query from someone I
sent a kermit disc saying that they can't get it to run on the GS. Well I
don't have a GS...

It seems they are using DOS 3.3 and the Super Serial Card. I thought the GS
had a built in serial port which emulated a slot card. If so what happens
when u plug in another card ? Kermit runs and goes into connect mode but
neither seems to receive or transmit although the escape sequence does
return to kermit command level. I've pointed out all the usual pitfalls with
Apple kermit such as serial chip not initialised but it doesn't seem to
help.

Any pointers from anyone using the GS and/or SSC card with kermit welcome.

Alan Greig
Computer Centre
Dundee College of Technology

Janet: [e-mail] ([e-mail])
Arpa:  [e-mail]

[Ed. - See message above about the Apple II GS.]

------------------------------

Date: Thu, 26 Feb 87 12:28:40 PST
From: [e-mail] (Michael Laver)
Subject: C-Kermit on an AT&T 7300?
Keywords: C-Kermit, AT&T 7300

Has anyone had any luck creating a C-Kermit for the AT&T 7300 (the "Unix
PC"). Both "make sys3" and "make sys3nid" leave me with the error message

    Stop. Don't know how to make chcdeb.h

I downloaded the shar files to an IBM PC, read them into the 7300, and
converted the case of the filenames.

Any help would be appreciated.

                --Mick Laver
                [e-mail]

------------------------------

End of Info-Kermit Digest
*************************
-------
10-Mar-87 13:02:24-EST,25737;000000000000
Mail-From: SY.CHRISTINE created at 10-Mar-87 13:01:20
Date: Tue 10 Mar 87 13:01:20-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V6 #7
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 10 Mar 1987       Volume 6 : Number 7

Today's Topics:

                              New iRMX Kermit
                    Announcing Kermit for Computervision
                   Announcing Kermit for the TI Explorer
              Announcing New FLEX Kermit for the Motorola 6809
                  Announcing 2 New Apollo Kermit Versions
                       Announcing Updated C86PRO.A86
              CDC Cyber Kermit Version 3 Available Running NOS
                       Cyber Kermit V3 vs. THE OTHERS
       Announcing a new Concurrent/Perkin-Elmer/Interdata 3200 Kermit
                                Long packets
                        Problems With VAX/VMS Kermit
                               VMS Kermit Bug
                    Occasional loss of trailing newline.
                         C-Kermit on an AT&T 7300?
                      Re: SET ETOA/ATOE in CMS KERMIT

----------------------------------------------------------------------

Date: January 23, 1987
From: Robert L. Stanis, Grinnel College, IA
Subject: New iRMX Kermit
Keywords: iRMX, Intel

Here is version 2.41 of iRMX Kermit.  With version 2.41, all I/O routines
have been written using system calls so both the 534 and 544 communications
boards should work without problems.  Any other communication boards should
work too, but this has not been tested here.  This version is an update of
the PL/M version.  The current author is still Albert Goodman.

Version 2.42 was updated for the iRMX-286 operating system at the University
of Illinois.  We had previously sent them version 2.41, which runs on
8086-based machines.  It may make the most sense to refer to these as
separate implementations of Kermit since they are not compatible across CPU
boards/operating systems, even though the sources are similar.

Bob Stanis
Grinnell College
Noyce Computer Center
Grinnell ,Iowa 50112

[Ed. - Since it's not really clear from this letter what we have, this new
version is being installed as KER:IRMX.*, and the old version will remain as
KER:I86KER.*.  If indeed these two versions are redundant, would some kind
Intel iRMX system user please let us know?]

------------------------------

Date: Wed 19 Feb 87 12:24:16-EST
From: Christine M Gianone <[e-mail]>
Subject: Announcing Kermit for Computervision
Keywords: Computervision Kermit

This is version 1.21 of Computervision Kermit, written in Fortran S,
submitted by Val Jawks, 435 CPB, Bringham Young University, Provo, Utah
84602.  This version was converted from John Lee of RCA Lab's HP1000 Kermit.

The files are in KER:CVKER.*.  There are two files; source and help.

------------------------------

Date: Wed 19 Feb 87 12:24:16-EST
From: Christine M Gianone <[e-mail]>
Subject: Announcing Kermit for the TI Explorer
Keywords: TI Explorer Kermit, Lisp

This is Release 1.0 of TI Explorer Kermit, written in Common Lisp,
contributed by Brian Carb and Steve Ford of UNISYS Corporation, PO Box 500,
Bluebell, PA 19424.  This implementation was developed as a joint effort
between Sperry Corporation and Texas Instruments Incorporated.  You should
be using Sperry Release 2.1.1 or TI Release 2.1 of Explorer software.  When
Release 3.0 is available, this software will probably no longer work, and an
updated version will be distributed by Sperry and TI.  This implementation
has been successfully tested in conjunction with Kermit implementations for
Sperry 1100, DEC Vax, DEC 2060, and Sperry and IBM PCs (KERMIT-MS).

The TI Explorer Kermit files have been renamed and are in KER:EXPLRE.*.
Files are separated by *** FILENAME ***, and are available via FTP at CU20B
(login as user ANONYMOUS, any password) and via KERMSRV on BITNET (SMSG RSCS
MSG CUVMA KERMSRV HELP).

------------------------------

Date: Wed 11 Feb 87 11:24:16-EST
From: Christine M Gianone <[e-mail]>
Subject: Announcing New FLEX Kermit for the Motorola 6809
Keywords: FLEX Kermit, 6809, Motorola 6809

This is to announce a new version of FLEX Kermit for the Motorola 6809,
written in July 1986, by Jur van der Burg, Nettelhorst 56, 2402 LS Alphen
aan den Rijn, The Netherlands.  This is version 3.0, written in C (Compiled
with Introl (c) compiler)

Kermit for FLEX has its roots in the (old) UNIX version. It is enhanced in
several ways, such as data logging, server mode etc.

It should run on about any version of the FLEX-09 (tm) or SK*DOS (tm)
operating system.  It requires 48K of memory. Hardware dependent things are
kept in the files FLK.H and FLIO.C .

FLEX-09 KERMIT has most of the features specified in the KERMIT Protocol
Manual.

[Ed. - The new files can be found in KER:FL2KER.*.  The old files remain in
KER:FLXKER.*.]

------------------------------

Date: Wed 11 Feb 87 11:24:16-EST
From: Christine M Gianone <[e-mail]>
Subject: Announcing 2 New Apollo Kermit Versions
Keywords: Apollo Kermit

This is to announce a new version of Apollo Kermit developed by Control Data
Corporation (Apollo version 2.8) and another new version (Apollo version
2.7) which came in about the same time from Gordon Sands of Marconi Space
Systems.  If anyone is interested in putting ALL of these new features into
one Kermit program, please let us know.  Until then, please test the new
versions.

  The version (2.8) developed by Control Data Corporation implements the
protocol as outlined in the Kermit Protocol Manual, Fifth Edition.  The
Kermit version is the Pascal one that Beckman Instruments obtained from
Columbia and fixed some bugs.  It will now handle binary files properly.
This implementation of Kermit is designed to run as a "remote" Kermit and
therefore does not implement any of the "local" Kermit commands.  Apollo
Kermit 2.8 is particularly suited for running in 'server' mode and
implements QBIN partially.  8-bit quoting is always done in this version; it
is not optional.  See the Kermit protocol description where is describes the
use of 'N' and 'Y' in the QBIN field of the initialization packet.

[Ed. - The new files have replaced the older ones as KER:APOLLO.*.
KER:APOLLO.ANN is this file.  KER:APOLLO.HLP contains documentation for
running KERMIT on the Apollo and communicating with an IBM-PC.  There are
three source files for KERMIT on the Apollo.  The source files are
KERMITB.PAS, KERMITIO.PAS, and EXISTF.C.  The files are separated by:
/*----- end of file ----- */ and stored as KER:APOLLO.PAS.]

The version (2.7) from Gordon Sands of the Technical Computing Dept.,
Marconi Space Systems has added several facilities to the Apollo (Pascal)
version of Kermit. In particular, the new version can drive a screen without
Graphics Primitives. Gordon developed this to enable a user on one node to
drive an RS232 port on another, but it should also be usable on an attached
terminal (Trevor Wright's query in NEWS01V2).

      The main other facilities are:
          repeat count processing,
          filename hashing,
          RECEIVE followed by filename,
          more error etc. messages to the screen   and
          SET TIME and TIMEOUT.
  SET parameters GRAPHICS and NORMAL control whether graphics are used to
  drive the screen and whether filenames are normalised.
      There are further details in a revised .HLP file and in comments at
  the start of the source file.

[Ed. - These files have been put in KER:AP2KER.*.  Now there are 2 Apollo
versions -- APOLLO.* and AP2KER.*.  The old Apollo Kermit is now in
KO:APOLLO.*]

------------------------------

Date: 16-FEB-1987 13:58:40
From: [e-mail]
Subject: Announcing Updated C86PRO.A86
Keywords: C86 Kermit

  This is to announce an update to C86PRO.A86, by Chris Lock of Nottingham
University. It makes the C86 Kermit resilient to packets being echoed back
to it. Chris did it orginally for a specific implementation talking to a
specific wierd British mainframe, but this part of his code should be of
general use in all the C86 implementations.

            Alan

[Ed. - Thanks!  The new files have replaced the old ones in KER:C86PRO.*.
This is protocol module for CP/M-86 Kermit.  If anyone wants to rebuild
the program for a particular system, this source can now be used.]

------------------------------

Date: Mon 16 Feb 87 18:18:05-EST
From: Christine M Gianone <[e-mail]>
Subject: CDC Cyber Kermit Version 3 Available Running NOS
Keywords: Cyber Kermit, CDC Kermit, CDC Cyber Kermit

A new version of Kermit is available for CDC Cybers running NOS.  This
version (3.0) was developed by Steve Roseman, Lead Systems Programmer,
Lehigh University Computer Center ([e-mail]).  It is derived
from the U of Texas Fortran 5 Kermit, with NOS/BE and UT2D support removed.
It contains the following new features and changes:

. Wildcard file names on the SEND command and server GET command.
. Local and permanent file SEND and server GET.
. A DIRECTORY command and server REMOTE DIRECTORY command.
. Automatic recognition of DISPLAY CODE, 6/12 ASCII, and 8/12 ASCII file
   text modes on SEND.  Receives 6/12 ASCII by default.
. The SET FILE-MODE command allows BINARY and TEXT file types.
. Supports repeated character compression (if the micro Kermit allows).
. Supports long file transfer packets up to 1000 characters (if the
    micro Kermit allows).
. Cyber Kermit no longer affects the parity of your terminal connection.

[Ed. - The files have been named to KER:CD3KERM.*.  The KER:CYBKER.* files
still remain in the KERMIT-2 directory as well, and the old version that
supports NOS/BE is in KERMIT-3.  And...  we expect yet another version to
arrive someday that will support NOS/VE.  See message below for a comparison
of the various Cyber versions.]

------------------------------

Date: 23 FEB 1987  13:32 EST
From: Steve Roseman <[e-mail]>
Subject: Cyber Kermit V3 vs. THE OTHERS
Keywords: Cyber Kermit

Below is a comparison between the 3 Cyber Kermit versions:

CDC KERMIT V2 vs V3:

V2 advantages:   Provides NOS/BE and UT2D support; removed in V3.
                 Slightly smaller memory requirements.

V3 advantages:   More features, including long packets, wildcard file names,
                 repeat prefixing, DIR command and REM DIR server command,
                 editable HELP file.

CYBER (MANCHESTER) vs. V3:

Manchester Advantages:  Much smaller memory requirements (importance reduced
                        by non-swap code and longer packets).
                        Faster (less CPU usage).
                        Probably slightly faster transfer rate with standard
                        length packets.
                        Some users think it is the 'greatest Kermit since
                        sliced bread'.

V3 advantages:          See above.
                        Readable/maintainable code.
                        63 character set NOS site support (not very important).

    If it was my choice, I would keep the CDC Kermit V2 for the remaining
NOS/BE sites.  We can't abandon them.  I would abandon the Manchester
version.  It's a small, fast version, but the unreadable code and, now,
comparative lack of features, make it less desirable.  Or keep it around, it
doesn't take too much food.  It's up to you.

                                                      Steve Roseman

------------------------------

Date: Mon 16 Feb 87 18:18:05-EST
From: Christine M Gianone <[e-mail]>
Subject: Announcing a new Concurrent/Perkin-Elmer/Interdata 3200 Kermit
Keywords: Concurrent Kermit, Perkin-Elmer Kermit, Interdata 3200 Kermit

This is to announce a new Kermit version (1.0) configured for
Concurrent/Perkin-Elmer/Interdata 3200 series Super-Minicomputers running
OS/32, by Creighton J. Miller, Department of Speech, Theatre, and
Communication Disorders, Louisiana State University, Baton Rouge, LA.

According to Creighton J. Miller:
This program has been developed and installed on a Perkin-Elmer 3210 system
with 1 Mbyte of memory, under OS32MT72, Revision 0.  All program code except
for the I/O modules, has been written in "primitive" FORTRAN which should
prove to be highly portable (even to other machines) compact and fast.  All
I/O utilizes system-level versatility through run-time access to PE's SVC1
I/O handler, whose operations could be easily duplicated on most other
mini's in a single added subroutine (image mode read-/write-and-proceed
calls and echoless reads).

In developing this program, much reference has been made to code from
Kermit-PE 2.0, developed by Paul Mamelka and currently available from either
Columbia University or PE-Interchange: The primary reasons for developing
PE-Kermit being a desire to enhance program size/speed/portability issues
and to incorporate binary file transfers (eventually raw transfers as
well...), plus a few added "bells and whistles" I'd had in mind.

Although no warranty of the routine is either expressed or implied, feel
free to use/distribute/alter the code at will --- so long as it is put to no
explicitly commercial applications: I think you'll be impressed by this
Kermit's relatively gentle and forgiving nature.  I would be happy to
exchange information, comments or just pleasantries with those of you who
find some use for the logic.

A complete set of installation/development/message files is included
with the code, as an aid to fellow-travelers on the road to intersystem
communications.  They'll work as-is on a properly prepared 3200 series PE
system; properly prepared meaning in this case, OS32MT72.0 or higher OS and
BIOC with an enabled, 80 byte (minimum) typeahead cue, plus the sysgened
MASK=X'FF' option.  Please note that the interactive message file,
KERMIT.HLP, is an IN-dexed file with an 80 character record length, and
holds binary information.  Each line is structured as follows;

               1.  BYTES 00-03 => length in bytes (binary) of the
                                  message line which follows

               2.  BYTES 04-[length+4] => message line, in image
                                          form.

Program size ranges from 22k bytes, using FORT7-O, through 25k bytes,
using FORT6 (you'll need assembly access to OS/32 7.2.0's SVC1, like that
included in SYS7IO.FTN), to about 38k bytes, using FORT7-D.  You will
discover SIGNIFICANTLY enhanced response times for the program with the
optimizing compilers.

Transfers have been accomplished between both a PE-3210 and a PE-8/32
(as Hosts) and Zenith Z-148 (4.7 and 8 meg clocking), IBM XT, IBM AT and
Kaypro 2000 Pc's, at baud rates ranging from 300 through 9600, over
dedicated and modem links.  These have been used for both ASCII and BINARY
data, with full-sized packets (94 bytes).  MS-Kermit 2.26 was the usual
Caller routine, but MS-Kermit 2.28, and Procomm 2.1 and 2.3 have also been
used (Procomm 2.1 has quirks which effectively prevent binary transfers).

[Ed. - These files are in KER:PE2KER.*.  The old files are still in
KER:PERKIN.*; if anyone can demonstrate why we should keep the old version,
or can say definitively that this new one can replace it, please let us
know.  Our Kermit tapes runneth over...]

------------------------------

Date: 1987 Feb 20   09:38 EST
From: (John F. Chandler)   <PEPMNT@CFAAMP>
Subject: Long packets
Keywords: Protocol Extensions

One of the concerns in sending long packets is that the communication link
may suddenly change in such a way that the agreed-upon packet size becomes
unsendable.  Since checkpointing the I/O on the source file may be awkward
or impossible, the recommended procedure of error recovery by resending only
about half of the failed packet requires a method for cutting the packet
buffer without separating a prefix byte from its suffix.  I offer the
following algorithm for finding a suitable cutting point.  Assume here that
'#', '&', and '~' are the Control, 8th-bit, and Repeat quote characters and
that M is the desired index into the packet buffer BUF.  I use 'ne' for the
Not-equal operator.

  1. N = M
  2. Go to 5
  3. N = N - 1
  4. N = N - 1
  5. If BUF(N) = '#' then go to 4
  6. If BUF(N) = '~' and BUF(N+2) ne '~' then go to 3
  7. If N > M - 5 or BUF(N+1) ne '#' or BUF(N+2) ne '#' then go to 10
  8. N = N + 2
  9. Go to 7
 10. N = N + 1
 11. If BUF(N) = '#' then return (N+2)
 12. If BUF(N) = '~' then return (N)
 13. If BUF(N) = '&' then go to 10
 14. Return (N+1)

Note that if 8th-bit or Repeat prefixing is turned off, the tests in step 13
or in 6 and 12 would fall through.  Also note that steps 7-9 take care of
multiple quoted-control-quotes (if Repeat prefixing is off), but that the
repeat count threshhold will have to be set at 4 (at least for characters
that do not require any other prefixing) in order to avoid another possible
run-back in steps 3-6.

                                          John

------------------------------

Date: Tue, 24 Feb 87 16:30:32 CST
From: "Jeff Balvanz" <[e-mail]>
Subject: Problems With VAX/VMS Kermit
Keywords: VAX/VMS Kermit

We have been having some problems with VAX/VMS Kermit here at ISU and I'm
wondering if anyone can offer some advice.  Here are some of the problems:

1.  When uploading to VAX from MS-Kermit 2.29 (Zenith Z-158) using an
eight-bit communications line, SET PARITY NONE on both ends usually results
in 16 retries and no packets sent.  Setting parity to EVEN on both ends
causes a file to be uploaded, but often with repeated characters in the file
(as in "This is a miiiiiiiiiiiiiiiiistake.") making the upload unusable.
However, setting the parity back to NONE on both sides after an unsuccessful
upload at EVEN sometimes results in a successful transfer.  It drives us
nuts because sometimes no parity works just fine, and some files will
transfer successfully with EVEN parity.  The files that give repeating
characters are normal text files, and it is (to me, anyway) impossible to
determine any difference between the files that work and those that don't.
However, a file that doesn't work once usually will repeat the behavior.

2.  Downloading files with FORTRAN carriage control to MS-Kermit 2.29 (or, I
suspect, any other local Kermit) results in the message "Illegal file type"
from VMS Kermit.  APPENDing the file to a normal file created with the
CREATE command causes it to download just fine.  According to the source
code this was supposed to be fixed in VMS Kermit v 3.2.

We are running VMS version 4.5 and VMS Kermit version 3.2.076, just
assembled from MACRO source gotten from Columbia over BITNET since the VMS
upgrade.  Any suggestions?  I'd be happy to correspond with someone over
BITNET if it will help.

Jeff Balvanz
Manager, Microcomputer Services
Iowa State University Computation Center
[e-mail]

------------------------------

Date: 19-FEB-1987 13:34:51
From: [e-mail]
Subject: VMS Kermit Bug
Keywords: VAX/VMS Kermit

Help!

Kermit 3.2.077 keeps crashing out when I use it. I eventually tracked down
the problem to be tied up with the length of the filename involved; rather
than there being something wrong with the file itself.

If the filename is 'too long' Kermit crashes out with an access violation.

This is demonstrated by the two examples below. In the first, I have used a
short-cut to specify the file I want to send, in the second the full file
specification is given.

Paul Hare

PS. This problem is critical where we are concerned since the file transfers
   that are causing Kermit to crash are under the control of a third-party
   application package; so nothing can be done to avoid long file names.

[Ed. - Thanks for the report.  We've sent it to the VMS Kermit authors.]

------------------------------

Date: Mon, 19 Jan 87 09:50:36 PST
From: rutgers!lll-lcc!cae780!videovax.TEK.COM![e-mail]
Subject: Occasional loss of trailing newline.
Keywords: C-Kermit, VAX Kermit

I have run into an occasional problem with C-Kermit dropping the last
character in a file.  This was first observed in old versions of C-Kermit
running on our VAX (a "beta release" from sometime in the Spring of 1985)
and on my Amiga (an early hack of unknown pedigree).  I had hoped this
problem would go away with version 4D(060), which we are now running on the
VAX and I am using on my Amiga.  Unfortunately, the problem still exists.

In Info-Kermit Digest V6 #1, Gordon Scott reported discovery of a bug
that may be related (I don't know how newlines are transmitted).
The description Gordon gives is consistent with the apparently random
nature of the problem I encounter, although my transfers are in text mode.
An occasional file will lose the trailing newline.  If the newline is
appended and the file transmitted again, the newline is again lost.
However, not all trailing newlines are lost.  Most files are transmitted
without problems.

[Ed. - Thanks, we'll take a look at all the evidence you've gathered, and
hope we'll home in on the problem & fix it.]

------------------------------

Date: Thu, 26 Feb 87 12:28:40 PST
From: [e-mail] (Michael Laver)
Subject: C-Kermit on an AT&T 7300?
Keywords: C-Kermit, AT&T 7300

Has anyone had any luck creating a C-Kermit for the AT&T 7300 (the "Unix
PC"). Both "make sys3" and "make sys3nid" leave me with the error message

    Stop. Don't know how to make chcdeb.h

I downloaded the shar files to an IBM PC, read them into the 7300, and
converted the case of the filenames.

Any help would be appreciated.

                --Mick Laver
                [e-mail]

[Ed. - The real name of the file is ckcdeb.h, not chcdeb.h -- could that
be the problem???]

------------------------------

Date: 1987 Mar 2   13:17 EST
From: (John F. Chandler)   <PEPMNT@CFAAMP>
Subject: Re: SET ETOA/ATOE in CMS KERMIT
Keywords: CMS Kermit

The proposal of having more than two ASCII/EBCDIC tables is not a new
one.  The following diagram shows the various translations a file must
undergo in sending and receiving and why Kermit could logically maintain
four tables instead of two in an IBM mainframe environment.

                         *                      *
 File ---> Buffer ---> Packet ---> Buffer ---> TTY     (Sending)
      ETOA       ENCODE       ATOE        sys
       1                       2           3

  *                     *
 TTY ---> Buffer ---> Packet ---> Buffer ---> File     (Receiving)
     sys         ETOA       DECODE       ATOE
      4           5                       6

Nonetheless, only two tables should suffice in practice, given the
following assumptions:

 1. System tables 3 and 4 are invertible for all codes of interest,

 2. tables 3 and 4 are mutual inverses for all ASCII codes 32-126 plus
    at least two different control characters (such as SOH and CR), and

 3. the media marked with asterisks (*) above have only 7-bit data.

Bear in mind that the original reason for allowing the user to modify
Kermit's translation tables was to adapt to operating systems with
peculiar tables 3 or 4, not to permit extended 8-bit ASCII fonts.  In
any case, tables 2 and 5 must be the inverses of 3 and 4, respectively,
but, since Kermit uses 7-bit ASCII for making packets, the second half
of table 2 is unused and, thus, might as well be the same as the second
half of table 6.  As long as tables 3 and 4 are inverses, I see no reason
why the "used" half of table 2 (which equals the first half of table 4)
should not also match the first half of table 6.  In other words, the
system tables should accurately reflect the local standards for
7-bit-ASCII-to-EBCDIC conversion.  The same line of reasoning also leads
to the conclusion that tables 1 and 5 can be identical.  Half of each
table is invariant at a given installation, being anchored in the local
definition of 7-bit-ASCII-to-EBCDIC, but the other half is free for
tailoring to any purpose -- there could be separate definitions of
8-bit-ASCII codes for different target machines.  Suppose that one or
more of the above assumptions are false:

 1. If table 3 (or table 4) is not invertible, then Kermit can't work.

 2. If tables 3 and 4 are not inverses, then Kermit must have four
    different tables after all.  Are there, in fact, any installations
    where this is the case?  If so, why can't the tables be rationalized?

 3. If an installation provides 8-bit data lines, then tables 3 and 4
    are entirely filled, and tables 2 and 5 are entirely invariant, but
    only if Kermit tries to use 8-bit codes in packets.  Are there, in
    fact, any installations where this is the case?  If so, then is the
    gain in efficiency from using 8-bit codes (for text) really worth the
    trouble of maintaining separate translation tables?

------------------------------

End of Info-Kermit Digest
*************************


-------
26-Mar-87 18:37:56-EST,21598;000000000000
Mail-From: SY.CHRISTINE created at 26-Mar-87 18:37:03
Date: Thu 26 Mar 87 18:37:03-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V6 #8
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 26 Mar 1987       Volume 6 : Number 8

Today's Topics:

                   Announcing Kermit for the Sinclair QL
                   Announcing Kermit for TRS-80 Model II
              Announcing Kermit for Data General running RDOS
                            UUDECODE for BITNET
                  AP2 (Apple and Apollo) Kermit Name Clash
                               KERMSRV access
                      Re: Problem with VAX/VMS Kermit
                 Request for DTR control in VAX/VMS Kermit
                      Re: SET ETOA/ATOE in CMS KERMIT
                      More on ASCII/EBCDIC translation
                                TRS Model 1
         C-Kermit changes needed for Zilog systems under Zeus 3.21
                              C-Kermit for AOS
                  Kermit-11 Problem Discovered and Solved
                          SANYO MBC555 AND KERMIT

----------------------------------------------------------------------


Date: 13-MAR-1987 11:20:54
From: [e-mail]
Subject: Announcing Kermit for the Sinclair QL
Keywords: Sinclair QL Kermit

It has come to my notice that there is a demand for Kermit on the Sinclair
QL.  As I've written an automated file server to connect several QL's to a
Xenix machine that is based on the Kermit protocol, I feel I ought to let
you have what I've accomplished on the basis of providing a development
source for anyone interested in taking it further. There is a full
description of how the version developed and what it can and cannot do in
QLKERM.DOC

I would recommend users to use floppy or RAM disks due to the slow and
unreliable nature of the Microdrives. Floppy disks are an essential requirement
for any further development.

The source files have been renamed to fit the standard 6.3 convention. To
compile from source they have to be renamed as follows:

     Current Name   Original Name      Usage
     ------------   -------------      -----

     QLKERM.DOC     QLK_DOC            usage and comments
     QLKERM.LNK     QLK_LINK           Metacomco linker control file
     QLKMAIN.C      QLKMAIN_C          main module
     QLKKER.H       QLKKER_H           main header file
     QLKSWITC.C     QLKSWITCH_C        state table switcher
     QLKUS1.C       QLKUSR1_C          top level command parser
     QLKUS3.C       QLKUSR3_C          parameter setter
     QLKUSR.H       QLKUSR_H           parser header file
     QLKCMD.C       QLKCMD_C           command prompter/editor
     QLKCMD.H       QLKCMD_H           editor header file
     QLKFNS.C       QLKFNS_C           base level functions

Compilation also needs stdio_h, ctype_h and qdos_h as supplied with the
Metacomco 'C' development kit.

Suggestions for enhancements are:

     A proper terminal emulator ( preferably VT100 ) - the need for this is
so great that I could be tempted to do this myself if only I could obtain an
example 'C' source ( for any machine ).

     Rebuilding wider functionality, including the help, that I have removed
to minimise storage requirements.

Please note that I will be moving to a new job in Cambridge in mid-April, so
would like to wash my hands of QLKermit, as it were, but I would be happy to
answer any queries people may have.

  Robert Coughlan,
  Department of Surgery,
  Liverpool University,
  PO Box 147,
  Liverpool L69 3BX
  UK

  (051) 709 - 0141 x 2670

[Ed. - Thanks for the new Kermit version.  The files are in KER:QLKER.*
available using FTP to CU20B (login user ANONYMOUS - any password) and
through BITNET via KERMSRV.]

------------------------------

Date: Mon 23 Mar 87 11:26:46-EST
From: Christine M Gianone <[e-mail]>
Subject: Announcing Kermit for TRS-80 Model II
Keywords: TRS-80 Kermit

A new version of TRS-80 Kermit has been developed by Serge G. Kruk, Systemes
Temps Reel, 1030 Hodge, St-Laurent, Quebec, Canada H4N 2B7 ([phone]).
This implementation of the Kermit protocol is for the Radio-Shack Model II
running under TRSDOS.  This version of the Kermit protocol implements only
send and receive capabilities using the one-character checksum.

Known Bugs include:
      -  Command parsing and recovery is minimal.
      -  During a file transfer, TRSKER remains silent.  Only the noisy
      -  disk accesses of the equipment will tell you that a transfer is
             in progress.  (But completion status is unambiguous...)
      -  TRSKER uses the TRSDOS clock interrupt services to timout an
             unanswered packet but it does'nt seem to work all the time...

[Ed. - These files are in KER:TR2KER.* available through BITNET via KERMSRV
and by using FTP to connect to CU20B.]

------------------------------

Date: Mon 23 Mar 87 11:26:46-EST
From: Christine M Gianone <[e-mail]>
Subject: Announcing Kermit for Data General running RDOS
Keywords: Data General Kermit, RDOS Kermit

This version is a modification for RDOS of the version of Torbjorn Alm & Per
Lindberg for the ABC-800.  It was modified by Remi Castonguay.  The only
file sent to Columbia was the source code, written in BASIC.

[Ed. - The BASIC code is in the file KER:RD2KER.BAS.  Please report any bugs
to Info-Kermit@CU20B.]

------------------------------

Date: Fri 20 Mar 1987 11:51:19 CST
From: Mark S. Zinzow <MARKZ@UIUCVMD>
Subject: UUDECODE for BITNET
Keywords: UUDECODE, BITNET

  When mail goes somewhere via bitnet there are two problems.  One is that
tabs get eaten by ASCII <--> EBCDIC conversion, which is a pain for source
code text.  The other is that trailing spaces are stripped off.  This is nice
for cutting useless characters from mail, but uuencoded files suffer.  My
enhancement is to put the spaces back.  Someone has written a uuencode that
puts an extraneous character at the end of each line which also solves the
bitnet problem on the sending end.

I realize that the four if's in outdec would be better rewritten as one
for loop, but I was tired when I fixed this last night and it works close
enough.

[Ed. - Thanks!  This version of UUDECODE is in KER:UUDECO.C.]

------------------------------

Date: 13-MAR-1987 11:20:54
From: [e-mail]
Subject: AP2 (Apple and Apollo) Kermit Name Clash
Keywords: Apple Kermit, Apollo Kermit

  Doubtless you've had a lot of people telling you this, but we now have two
Kermits with prefix AP2! (one is the new Apollo stuff, the other the very
old Apple native assembler version).....

       Alan

[Ed. - No, Alan, you were the only one who mentioned this.  Ooops...  The
new version of Apollo Kermit, formally named AP2*.* is now named APL*.* in
KER:.  Thanks for catching this.]

------------------------------

Date: 03/17/87 14:41:34 CET
From: [e-mail]
Subject: KERMSRV access
Keywords: KERMSRV

Hello! I want to bring some information regarding KERMSRV access to your
attention.

In INFO-KERMIT V6 #7 you wrote that KERMSRV can be accessed from BITNET via
'SMSG RSCS MSG CUVMA KERMSRV HELP'.  This command is only valid for VM
machines, I suppose. We have a MVS (Man Versus System) machine here where I
can only use
'SMSG KERMSRV AT CUVMA HELP'. But all I get is 'INVALID COMMAND HELP'.

The correct form to get an answer is 'TELL KERMSRV AT CUVMA HELP'.  Then I'm
notified that 'KERMSRV INFO' has been sent to me and it really arrives!

I hope this information is of some use for you.

Frank Schwab
069/798-8238
Institut fuer theoretische Physik
Robert-Mayer-Str. 10
D-6000 Frankfurt/M.

[Ed. - Sorry about the confusion.  The KERMSRV syntax changes with every
machine it seems.  Here's what we know about so far:

  VM/CMS:    TELL KERMSRV AT CUVMA HELP (or SMSG RSCS MSG CUVMA KERMSRV HELP)
  MVS/TSO/E: TELL KERMSRV AT CUVMA HELP (may be site dependent)
  VMS JNET:  SEN/REM CUVMA KERMSRV HELP
  UNIX UREP: netexec cuvma msg cuvma kermsrv help

Does anyone have any additions or corrections?]

------------------------------

Date: Tue, 10-MAR-1987 19:28 PST
From: Mike Iglesias <[e-mail]>
Subject: Re: Problem with VAX/VMS Kermit
Keywords: VAX/VMS Kermit

As I remember, you can't rebuild VMS Kermit from the macro sources because
they're not all up to date (some are from 3.2.076, some from 3.2.077).  You
have to take the KERMIT.HEX (not sure about the file name) file and de-hex
it using VMSDEH.MAR, also available from columbia.  I reported it a long
time ago (when 3.2.077 was released), but I guess it hasn't been fixed yet.

Version 3.2.077 fixes your problem with FORTRAN carriage-control files.
I've never seen your problem with the parity settings; I always use no
parity from MS-DOS Kermit v2.28/2.29 and have never had any problems
transfering files to our VMS systems.

Mike Iglesias
University of California, Irvine
[e-mail]
[e-mail]

[Ed. - We expect a newer release (3.2) from Stevens shortly.]

------------------------------

Date: Thu, 12 Mar 87 10:38:09 aest
From: Andrew Hunt <munnari!rpepping.oz![e-mail]>
Subject: Request for DTR control in VAX/VMS Kermit
Keywords: VAX/VMS Kermit

Would it be possible for the implementors of VMS Kermit to add modem (DTR)
control to the program.  This would involve setting DTR on on the KER$COMM
line (maybe if only different from TT:) and implementing the HANGUP command
to allow it to be cleared.  This would make it compatible with MS-Kermit
V2.29+ and allow easier use with modems and terminal switchers whih require
DTR to be set before they will lissen to you.

Many thanks in advance, ...Andrew HUNT, CSIRO Radiophysics, Australia.

------------------------------

Date: Tue, 03 Mar 87 09:03:10 SA
From: "Kai U. Leppamaki" <LK-KLE@FINHUT>
Subject: Re: SET ETOA/ATOE in CMS KERMIT
Keywords: VM/CMS Kermit

I trust you still have your sketch readily available so I'm using the same
ETOA/ATOE table numbers you did.

You saw no reason why the first half of table 2 (and 4) should not match the
first half of table 6.  On our site they mostly do not !  On a site which
uses national (7 bit) character sets the first half of table 6 may vary from
file to file i.e. the user may have used the local national (7 bit ASCII)
character set for one file and the American convention for another.  This is
very often the case when one receives text files from various parts of the
world.

Since the system table (4) can represent only one of the conventions there
is an apparent need for an independent table which can be freely modified on
the fly.  On our site the system tables (for tty lines) have not been
modified and they still reflect the American convention. This is to minimize
the effort needed to maintain the tables. Most of the text files use the
Finnish national character set (ASCII or EBCDIC) but many do not.

The problem originally raises from the stupid fact that the national char
replacements are different in EBCDIC than in ASCII !!  E.g. the Finnish
"umlauted" upper case "A" (two dots on top) replaces the left bracket in
ASCII whereas in EBCDIC it has stolen the place of a "#" !

This is why we cannot get along with only one translation table but need at
least two alternatives. The tables 2 & 5 must always match the system tables
3 & 4 (and never really need to be modified) whereas tables 1 & 6 must match
the character set CURRENTLY in use.

With only 8 bit "multinational" ASCII sets (with the first 128 codes
matching the American usage) your reasoning obviously holds but not if 7 bit
national variations are used !

Do you agree ?

------------------------------

Date: 1987 Mar 17   14:26 EST
From: (John F. Chandler)   <[e-mail]>
Subject: More on ASCII/EBCDIC translation
Keywords: ASCII/EBCDIC Translation

   It seems that the European experience includes a problem I didn't
consider in my analysis of the number of distinct A/E translation tables
needed in a Kermit-370.  In essence, the problem is that different
conventions for the national characters can exist for different terminals
and off-line sources of text, and the differences can affect the 7-bit
half-table for ordinary "ASCII" characters.  This is similar to what
happened after the replacement of 026 keypunches with 029's (BCD with
EBCDIC).  I'm afraid that a complete solution is beyond the scope of Kermit
because, in all likelihood, there are already files on disk at such sites
making use of the differing conventions.  In the case of BCD vs. EBCDIC, the
FORTRAN compilers (for example) were equipped with optional automatic
translation of the input source.  Sadly, the situation is more complicated
when one considers all varieties of text, but something of the sort might
still be possible.  As a fallback position, though, it would be necessary to
adopt a scheme that does an extra translation, either by making a translated
copy (as in using the COPYFILE TRANS option for CMS users) or by translating
before writing on disk in the first place (as in the extra Kermit tables).
The former approach solves the problem for all time (old files using one
convention can be converted at any time), but the latter would seem to be
more efficient (at least, if used consistently).  Adding such a Kermit
function would require two new SET commands.  Does anyone have any ideas on
what they should be called?
                                           John

------------------------------

Date: Mon, 16 Mar 87 21:03:01 EST
From: Charles L Oei <burdvax!thing2.PRC.Unisys.COM![e-mail]>
Subject: TRS Model 1
Keywords: TRS Kermit

I have several remarks though that you might want to put into a .BWR file
for future users of Kermit for the TRS80 Model 1 running TRSDOS 2.3:

Of the files that are distributed, a person really only needs to see:

   TRSMIT.DOC.1  and  TRSMAKE.BAS.1

The others are either Z80 assembly language source code (for good latenight
reading), or miscellaneous/extraneous files that are of no real consequence.
[TRSDNLD.BAS.1 when downloaded and ran produces correct checksum, but
the resultant /CMD file doesn't seem to run correctly (at least the couple
of times I tried it -- it could otherwise, but I didn't want to invest any
more time since TRSMAKE did work satisfactorily).]

When TRSMAKE.BAS is downloaded and ran, don't worry about that it says
that the checksum is wrong, it's probably just fine. Here are the checksums
that TRSMAKE says it should be and what I get, respectively: 976487 976454

There are two problems (of any real consequence) with the resulting
KERMIT/CMD file:

   1) not so bad is that vt52 emulation doesn't work

   2) The other is that I couldn't talk w/ other Kermits unless I set
      set the parity to "space". The Kermit on the other end doesn't
      have to set its parity to space though. [After this, all
      went well].

Also, some annoying things that I had with it were:
   in terminal "connect" mode, I have no cursor;
   the <break> key in command mode doesn't appear to "abort" a command,
      but the <clear> key seems to do the trick anyway;
   in "connect" mode, the <control> key designation doesn't work either.

Oh, and probably some other minor things too, but overall, it's great.
At least it works and sends/receives files better than raw transfers
sans error checking.

Thanks to Stan Barber and the original writers of CP/M 80 Kermit.

Charles Oei

[Ed. - Thanks for the report.  It's now in the TRSMIT.BWR file.]

------------------------------

Date: 19-March-1987
From: J.M.Saunders, British Aerospace plc
Subject: C-Kermit changes needed for Zilog systems under Zeus 3.21
Keywords: C-Kermit, Zilog, Zeus

At present we have two Zilog 8000 systems running Zeus 3.21. Detailed below
are the changes made in order to get a working version: they are mostly to get
around apparent compiler bugs.

Kermit was built using "make sys3". We got around the setjmp and longjmp
problem by defining these to be the same as longret and setret in include
files.

The changes to C-Kermit for Zilog were contained in ckutio.c and ckufio.c

CHANGES TO CKUTIO.C:

These can be split into 3 parts: ensuring the terminal settings were read and
set correctly, getting non-canonical processing to work correctly, and making
the lockfile format compatible with that of current software.

1. Terminal settings

The ioctl call did not put the terminal settings into the termio structure, and
any modifications made were ignored.  This was traced to an apparent bug in the
compiler, which was cured by changing the storage class of the termio structure
from static to the default in the variable declarations

2. Non-canonical mode

As soon as the interactive prompt appeared, Kermit returned to Unix command
level. This was traced to the terminal settings.  If the wait time setting
c_cc[5] is non-zero, ^A's are sent whilst the machine is waiting.  These were
being interpreted as EOF characetrs instructing Kermit to tidy up and exit.
The problem is cured by setting c_cc[5] to zero in all cases where
non-canonical mode was used (modes set in concb and conbin)

3. Lockfile

uucp on the Zilog requires the username and terminal of the person using the
remote line and not a pid number. The changes made (apart from variable
declarations) were in look4lk :

CHANGES TO CKUFIO.C:

The problem here is to do with file names being garbaged when wild card
characters were used. The name of the first file to be transferred was being
corrupted, due to corruption of the pointer to it. This had no visible
explanation and was put down to a compiler bug. The fix is in the form of a
kludge that ensured that the 0th location in the array was not used (i.e. names
are stored from element 1 onwards). Changes were made in the znext, znewn and
fgen functions as below:

OTHER BUGS:

The only other bug found was that trailing nulls are sometimes removed from
binary files in transfer.

J.M. Saunders,
Daisy CAE Support Engineer,
British Aerospace plc,
Naval and Electronic Systems Division,
Dept 399, FPC 126,
PO Box 5,
Filton, Bristol, UK BS12 7QW

[Ed. - Many thanks for the report!  The code differences have been omitted from
the above, as some of them are fairly lengthy, but this entire message
including the code has been added to CKUKER.BWR (the Unix Kermit "beware"
file).]

------------------------------

Date: Wed, 11 Mar 87 16:51:33 EDT
From: [e-mail]   (RHL)
Subject: C-Kermit for AOS
Keywords: C-kermit, AOS

Last I looked there seemed to be no C-kermit for the Data General AOS
operating system. So Ive hacked up a version. All functions (server, local)
seem to work fine on our machine but id like to try it on others before
making it public. Is anyone else with a DG machine willing to try C-kermit?

    My machine: MV20000
    Operating SYS: AOS/VS V7.53 (with MV/UX overlay unix)
    C compiler: AOS C V3.21

My goal is to make C-Kermit work under AOS/VS only. Send feedback to
        [e-mail]
        or ..ihnp4!mit-eddie!lids!lamb

    Thanx , Rick Lamb

[Ed. - The same thing has also been done elsewhere, and we're expecting it
to arrive "any day now".]

------------------------------

Date: Mon, 23 Mar 87  13:00 EST
From: Lewis M. Dreblow - PSYCH at UFFSC
Subject: Kermit-11 Problem Discovered and Solved
Keywords: Kermit-11

  I wish to inform the user community of a problem which occurred with the
K11 release of Kermit. I was trying to use kermit on a 11/23 running RTV5
and TSXV5. I had no trouble using the release as a server, but kept getting
hung whenever I tried to do a get or send to another remote server. It
didn't matter what machine was on the server end. After about a month of
tearing my hair out I discovered that I had TSGENed IOABT = 0 which caused
TSX to wait for IO completion on jobs. This seemed fine at TSGEN time, but
due to the .ABTIO MCALL in K11PRT caused kermit to hang for two minutes at
every get or send command.

  Thus, users should be aware that they have to either (1) TSGEN IOABT = 1
or (2) at the command line (or in a command file) prior to running kermit
issue the SET IO ABORT command. You may want to remember to SET IO NOABORT
after running kermit as well.

[Ed. - Thanks for the report; it's been added to the K11.BWR file.]

------------------------------

Date: 17 Mar 87 00:37 GMT
From: cfac-cso @ Walker-EMH.arpa
Subject: SANYO MBC555 AND KERMIT
Keywords: SANYO Kermit

I have just obtained a copy of Kermit and attempted to run it on my Sanyo
MBC555 with video interface card.  I am using XXXMBC.XXX version of Kermit
and I cannot utilize the autoanswer function of my Smartmodem 300 utilizing
my RadioShack model 100.  Does anyone have any suggestions?

G. Lyford
CFAC-CSO@WALKER-EMH

------------------------------

End of Info-Kermit Digest
*************************


-------
 9-Apr-87 12:07:07-EST,25455;000000000000
Mail-From: SY.CHRISTINE created at  9-Apr-87 12:04:06
Date: Thu 9 Apr 87 12:04:06-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V6 #9
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 9 Apr 1987       Volume 6 : Number 9

Today's Topics:

                Version 3.3.111 of VAX/VMS Kermit Available
              New Kermit Available for Apple II DOS and ProDOS
             New Version of Kermit now Available for Commodores
                     Commodore-64 GEOS Kermit Available
                  Announcing a new version of ISIS Kermit
                       Re: TRS-80 Model I/III Kermit
                  AT&T 6300 File Transfer Problems Solved
                  UUCP Source Copyright Status - IMPORTANT
                         Kermit on the Macintosh II
                       Re: Kermit on the Macintosh II
                           Kermit for the Mac SE
                            MacKermit 34 on 128K
                  Sanyo Kermit and Auto Answer Modem Mode
                        XENIX Clock Tick and Kermit
                     CP/M-80 kermit for the Epson PX-8

----------------------------------------------------------------------

Date: Mon 6 Apr 87 15:38:15-EST
From: Frank da Cruz <[e-mail]>
Subject: Version 3.3.111 of VAX/VMS Kermit Available
Keywords: VAX/VMS Kermit

This is to announce VAX/VMS Kermit Version 3.3.111, from Bob McQueen at
Stevens Institute of Technology.

This version is a maintenance version only and does not contain any major
development work.  This version has been tested under VMS 4.3, 4.4, and 4.5.
It will definitely not run under pre-4.0 releases of VMS (version 3.1 of
VMS Kermit was the last version that would do so; it is still kept in the
Kermit distribution as VMSV31.HEX).

The major change is the addition of a TRANSMIT command for raw file upload.
There are also internal improvements and bug fixes involving the CONNECT
command, IBM mainframe communication, etc.

The task image is encoded in hex format using the VMSHEX program, and is
decodable with the VMSDEH program.  This release includes modified versions of
the hexify/dehexify programs, contributed by Eric McQueen (no relation) of Utah
State University; they allow 16-bit, 24-bit, or 32-bit addresses, and VMSDEH
recognizes each kind automatically.  The new release of Kermit-32 is hexified
with 32-bit addresses, and so requires this new version of VMSDEH to decode it.

------------------------------

Date: Fri 3 Apr 87 15:35:48-EST
From: Frank da Cruz <[e-mail]>
Subject: New Kermit Available for Apple II DOS and ProDOS
Keywords: Apple Kermit

This is to announce a new release (3.75) of Apple II Kermit that runs under
both Apple DOS 3.3 and ProDos, from Ted Medin ([e-mail]).  It includes
new LOG, SERVER, and SET commands, the ability to do XON/XOFF, printer control,
VT52 emulation improvements, timeouts, support for various 80-column cards and
for a variety of communication cards including:

    Apple Comm Card
    CCS 7710
    Hayes Micromodem II
    Microtec Comm Card
    Super Serial Card

and it has extended-length packet support.

The program is based on the previous release of Apple II Kermit, which remains
available (for now) as KER:APP*.*, because it's not yet clear at what point
these two versions diverged, and whether the old version has been serving as
the basis for parallel developments.  The new version is in KER:A2*.*, and is
written in a dialect of the CROSS assembler language, and comes with a cross
assember (A2XASM.*) written in C to assemble it; this cross assembler can be
run on a Unix system (Berkeley or Ultrix, and possibly any other Unix system,
so long as it runs on a 2's complement, rather than 1's complement, machine).

It might also be possible to assemble it with the Merlin assembler after some
minimal editing, except that the source file is too big and would need to be
broken into pieces (anyone who succeeds in doing this is encouraged to report
back the actual procedure).

The memory size of this version of Kermit is currently $7000 so it should
run on a 32K Apple.

------------------------------

Date: Wed, 25 Mar 87 02:28:04 est
From: "Ray Moody" <[e-mail]>
Subject: New Version of Kermit now Available for Commodores
Keywords: Commodore Kermit

                                   ANNOUNCING

               Commodore 64/Commodore 128 Kermit Version 2.0(57)

    The new features include:

    1) Bug fixes.
    2) VT100 emulation.
    3) Commodore 128 support.
    4) Fresh bugs.

    1) Bug fixes.

       I fixed the bug that prevented people from using a standard VT52
termcap entry when emulating a VT52.  The problem was when UNIX wanted to
scroll the screen in moved the cursor to what it thought was the bottom line
(the 24th) and sent a line feed.  On the Commodore, this didnt scroll the
screen.  The cursor was moved to the 25th line.

       The fix for this bug was to reduce the size of the screen to 24
lines.  The 25th can be used as a status line by programs like sysline (see
below).

       This change obsoletes the termcap entry for Kermit 1.7.  Use a
straight VT52 termcap.  You can add so=\Eo:se=\En if you desire.

       IMPORTANT: If you use the old Kermit termcap entry, strange things
happen!

    2) VT100 emulation.

       Kermit 2.0 will emulate a VT100.  Type "set terminal-emulation
vt100".  Kermit recognizes most of the VT100 escape sequences, and all of
the popular ones such as start underline, start flashing, set scrolling
area, and others.

      Kermit 2.0 will support a status line like that generated by
sysline(1) in VT100 mode.  To do this, you must add the hs, ts, fs, and ds
termcap entrys.  The interesting part of my .login file is:

set noglob
set term=(`tset -SQ -m '<2400:vt100' -m 'unknown:?regent20'`)
if ($term[1] == vt100) then
    setenv TERM vt100
    setenv TERMCAP $term[2]"hs:ts=\E7\E[m\E[25;0H:fs=\E8:ds=\E7\E[25;0H\E[2K\E8"
else
    setenv TERM $term[1]
    setenv TERMCAP $term[2]
endif
unset noglob

       Note that Kermit 2.0 will work with a standard VT100 termcap, but if
you dont add the hs, ts, fs, and ds fields, you cant use a sysline.

    3) Commodore 128 support.

       Kermit 2.0 will support the 80-column chip in the Commodore 128.  To
use this, boot your Commodore 128 in C64 mode.  At the prompt, type "set
screen-driver commodore-128".

    4) Fresh bugs.

       There are probally alot of fresh bugs in this version.  If you find
any, pleas let us know!

    The commands that have been changed in this version are:

set vt52-emulation on        ->   set terminal-emulation vt52
set vt52-emulation off       ->   set terminal-emulation none
       (added)               ->   set terminal-emulation vt100

show vt52-emulation          ->   show terminal-emulation

set screen-width 80-columns  ->   set screen-driver 80-columns
set screen-width 40-columns  ->   set screen-driver 40-columns
        (added)              ->   set screen-driver commodore-128

       There are many more things I want to add in the future, such as the
ability to change the screen colors, a file-type compatible with C-power
files, Improved VT100 emulation, key bindings for the extra keys on the
C128, etc.

       These will get done in due time.

So much for the features.  To get a copy of Kermit 2.0, the only place that
you will be able to get it FOR SURE is from Columbia U or on diskette from:

Dr. Evil Laboratories
P.O. Box 190
St. Paul, IN 47272

Why this place that you have never heard about?  Well, this company is a
third mine, and it is the only place I know of set up to distribute disks on
any kind of regular, reasonable basis.  To get it, just send $5.00 to cover
the disk and postage.  I want to stress that Kermit is PUBLIC DOMAIN, and
may be freely copied.  Dr. Evil Labs can't afford to give it away because
supplies cost $$.  Dr. Evil Labs isn't out for your buck, as it sells
shareware exclusively (i.e. Do you know of anyone rich from selling
shareware??  Of course not!).

One more thing.  The manual with this new version is still the same manual
that was released with v1.7(52).  My roommate, Kent Sullivan, is going to
completely revise the manual to reflect all of the new features.  It will be
released as soon as the final 2.XX version is finished.  He should do a good
job, as he is a Professional (Technical) Writing major.  He said that if
anyone has any complaints/ideas about the manual to drop me a line, or him
directly at:

[e-mail]
pur-ee!ec.ecn.purdue.edu!corvair

                        Ray Moody
                         [e-mail]
                         pur-ee!s.cc.purdue.edu!aij

[Ed. - The new files are in KER:C64V2.*, available with FTP at CU20B (user
ANONYMOUS - any password) and through KERMSRV on BITNET.  There is no HEX
file available for the new code.  If anyone would like to get the new source
and make a HEX file for Kermit distribution, it would be appreciated.  See
message below for another possible new Commodore Kermit version for GEOS.]

------------------------------

Date: Tue, 31 Mar 87 04:40 CST
From: <[e-mail]>
Subject: Commodore-64 GEOS Kermit Available
Keywords: Commodore-64

This is a "vaporware" announcement of a version of Kermit for the Commodore
64.  Any comments, suggestions, hints, wishes, mumbles, or other
communication is invited.

I am especially interested in bugs and problems encountered in Kermit
implementations.  Especially useful would be discussion on methods (tricks?)
to make this implementation of Kermit "robust".

          Machine: Commodore 64
          Operating System:  Berkeley Softworks' GEOS, if we can get
          technical info. on it.
          Programming Language:  'C' and 6502 Assembly
          "Seriousness":  The authors are college students, developing
          this on their spare time.  We are 85% dedicated to
          completing the project as scheduled.
          Tentative Schedule:  Testing will (hopefully) begin 3rd
          quarter '87.

          We are aware of one other implementation of Kermit for the
          '64 that is based on the Apple version.  The implementation
          we are writing will have more features, including
          (hopefully) VT100 emulation in 80 columns.

          We  also have plans of porting the program to an Atari 800 in
          the future.  (It will run under ATARI DOS.)

A few notes:  now we are 95% committed to completion
              it WILL run under GEOS, but early versions may not.

How much in demand is VT220 emulation?  We are considering it, but is the
selective erase and special character attributes bold and blink important?
Thee selective erase looks NOT FUN.  The downloadable character sets are out
for sure..Not enough resolution on the '64.

For that matter, what kind of terminal would it be good to emulate in
addition to the VT220?

                     Thanks to anyone who writes,
                       John

------------------------------

Date: Mon 6 Apr 87 12:20:47-EST
From: Christine M Gianone <[e-mail]>
Subject: Announcing a new version of ISIS Kermit
Keywords: ISIS Kermit

Announcing a new version of ISIS Kermit created by Bill Boyd, Hughes
Aircraft Company, Fullerton, CA, from a version (MDS) received from Columbia
University via the DSSO department of Intel.  It incorporates some
enhancements inspired by the Kermit version from Leigh Instruments (MD2) as
well as a number of other enhancements.  All of the ISIS Kermit files have
the prefix "MDS".  For more information on this version, see file
MDSAAA.HLP.

The ISIS Kermit provides dumb terminal emulation and file transfer for Intel
Series II, Series III and Series IV computers running the ISIS operating
system.  It has the basic Kermit features and some additional ones.

According to somone who used some Kermit material from the new Kermit tapes,
the installation command file for Intel iRMX-86 (I86) is incomplete.  This
version of ISIS Kermit differs in several ways from the earlier (MDS)
version.  See the .DOC file for more details.

        William H. Boyd, Jr.
        Hughes Aircraft Company
        Bldg 635 M/S KA266
        1901 W. Malvern Ave.
        Fullerton, CA 92634

[Ed. - Thanks!  The new Verison has replaced the old one in KER:MDS*.*.  The
old version is now stored in KO:MDS*.*]

------------------------------

Date: Fri, 27 Mar 87 11:28:32 CST
From: cortex![e-mail] (Stan Barber)
Subject: Re: TRS-80 Model I/III Kermit
Keywords: TRS-80 Model I/III

As a point of interest, I will try to get out a new version of TRSMIT for
the MODEL I/III computers sometime before the end of summer.  If you have
some features you'd like to see, send a note to [e-mail].

Stan Barber

------------------------------

Date: Thu, 26 Mar 87 12:26 MST
From: Kevin J. Gray <GRAYK@BYUVAX>
Subject: AT&T 6300 File Transfer Problems Solved
Keywords: AT&T 6300, Modems

KERMIT USERS:

   About a year ago I reported some problems running Kermit on the AT+T
6300.  The problem was an excessive number of retries and failed transfers.
A few months later I saw a message in the digest reporting similar problems
due to overheating of a voltage regulator on a modem.  This turned out to be
the problem in my case also but I was unable to correct it by removing the
cover as was mentioned.  After four months and three tries the manufacturer
was unable to correct the problem.  The offending modem is marketed under
many brand names.  It is recognizable by eight LED's on the front of the
case.  I got a refund, bought a quality internal modem, and over the past
six months have averaged less than 1 retry per 1000 packets transferred.

------------------------------

Date: Wed, 1 Apr 87 17:43:39 PST
From: [e-mail] (Bob Larson)
Subject: UUCP Source Copyright Status - IMPORTANT
Keywords: UUCP Kermit

In article <[e-mail]> [e-mail] (Bill Cheswick) writes:
>In article <[e-mail]> [e-mail] (Jack Jansen) writes:
>The point is, why should we use those icky uucp protocols that are
>hardly documented, and unused except in some proprietary sofware
>Because it is faster.  Compare the transfer speeds of uucp and kermit: you
>only get about half your baud rate in kermit file transfers.  uucp does
>better.

Kermit with full duplex windows should aproach 75% effeciency on
binary files, and about 95% on ascii text files.  UUCP will do worse
than windowing kermit on lines with high latency.  (Satelite links,
fast "9600 baud" half-duplex modems.)  (Kermit can work with up to 32
outstanding acks, UUCP is 2 I think.)  The large packet option of
kermit will do better than that in some situations.

>Of course, the real problem is that kermit is still inefficient.

The problem is kermit was designed for environments present in the
real world, and UUCP for an ideal world.  Many unix administators have
trouble trying to get UUCP to work through real-world modems, port
selectors, multiplexors, etc.

>  (They said
>they were thinking of improving the protocol a couple of years ago.  I wonder
>if anyone has worked on it...)

The extentions you are talking about are called "full-duplex windows" and
"large packets".  Both are present in the most recent protocol manual,
and there are implementations available from Columbia university.
Unfortunatly, neither are in the Unix implementation C-Kermit yet.  Of
course, all correct kermit implementations should work with all
others, whether any specific enhancement is present or not.

>And while you are looking for a protocol, how about using one that transmits
>files in both directions at the same time?  There are many protocols that
>have solved this problem already.

I've thought of proposing such an extension to kermit.

>Actually, I use kermit quite often, and like it.  But shouldn't a program
>that may be responsible for a lot of telephone use be as efficient as
>possible?

As efficient as practical.  Squeezing a few percent more out a phone
conversation by limiting yourself to a single vendor for software is a
trade-off that should be examined closly.

People seriously interested in kermit can read the info-kermit digest on
mod.protocols.kermit.  [e-mail] can be
contacted if you need an arpanet/bitnet subscription.  There is also a book
on kermit by Frank da Cruz, I have not yet read it.

Kermit is available via arpanet ftp, bitnet, uucp from okstate, and on
tapes.  The request address above should be willing to send the details if
needed.

Bob Larson
Arpa: [e-mail]
Uucp: (several backbone sites)!sdcrdcf!usc-oberon!castor.usc.edu!blarson
            seismo!cit-vax!usc-oberon!castor.usc.edu!blarson

[Ed. - It should be noted that long packets and sliding windows are not
necessarily easy to implement in Unix Kermit, due to the fact that Unix's
kernel terminal buffers are not very big -- 256 bytes or so.  Since Unix
Kermit transfers files in rawmode (in order to avoid 8th-bit prefixing when
not required by the communication link), it cannot do XON/XOFF flow control,
so that long packets or a windowful of short packets would overrun its
buffers.  One solution would be to always do 8th-bit quoting, which would
allow the avoidance of rawmode.  But that would add overhead, and it would
also cause problems with the Kermit programs that can't do 8th-bit quoting.

------------------------------

Date: Fri 20 Mar 87 11:01:04-EST
From: MacIntosh User Group <[e-mail]>
Subject: Kermit on the Macintosh II
Keywords: Macintosh II Kermit

     While in California for the AppleWorld sideshow I was left alone for
two hours with a Mac II during which time I had opportunity to pop a Kermit
disk into its gaping maw . . . You may be happy to know that, as far as I
could tell, the program seemed to run just fine.  According to Didier Diaz,
the Mac II project coordinator, about 30 to 40% of the programs written for
the Mac don't run on the II due to their not following "Inside Macintosh"
stringently enough.  He was happy to see Kermit faring so well by
comparison.

      Just thought you might like to know this bit of trivia.

                                   Father Mack +
                           (a.k.a.:  Fr. Larry D. McCormick,
                                     President, CUMUG)

------------------------------

Date: Fri 27 Mar 87 09:57:57-EST
From: Robert Cartolano <[e-mail]>
Subject: Re: Kermit on the Macintosh II
Keywords: Macintosh II Kermit, Mac SE

It is good to hear.  Kermit works well with the Mac SE also.  I think Apple
is still working on compatibility, and when they get through, they expect
90% of all programs to run on the II.

Rob

------------------------------

Date: Mon 6 Apr 87 08:59:23-EDT
From: David Zubrow <[e-mail]>
Subject: Kermit for the Mac SE
Keywords: MacKermit

Has anyone had success using Kermit with the Mac SE?  I'm using a US Robotics
modem and the version of Ckmker from Sumex-Aim.  The cable from the computer
to the modem is one that is wired to match a MacPlus.  Whenever I log into a
remote host I get the connect tone, I might even get so far as to login, but
after a few characters are displayed on my screen the modem hangs up and gives
a "NO CARRIER" message.  I'm at a loss as to whether the problem is the modem
or the software or the cable.  Obviously, those are things I will change, not
the computer!

Thanks for your help,

Dave Zubrow
Committee on Social Science
 Research in Computing
CMU

------------------------------

Date: Wed, 1 Apr 87 22:23:12 pst
From: uw-apl!apl-em![e-mail]
Subject: MacKermit 34 on 128K
Keywords: MacKermit

> Date: Sun, 15 Feb 87 11:58 EST
> From: Mark B. Johnson <[e-mail]>
> Subject: MacKermit on a 128K Machine?
> Keywords: Mac Kermit

> Is anyone successfully using MacKermit V0.8(34) on a 128K machine?  I am sure
> we had done it here sometime back, but I have tried it recently with several
> different versions of the Finder and System and keep getting system crashes
> when trying to Send files.  We are sure it is the System and Finder, and are
> wondering if anyone who might be doing it successfully could send us their
> configuration.  Thanks again.

I think MacKermit V0.8(34) is too big for a 128K Mac.  I have experimented a
bit by taking out the VT100 fonts and the "blank cursor" which had been
added using the Resource Mover according to Davide Cervone.  Without those
it gets a bit farther in sending and receiving files.  In the receive cases
where three dialog boxes are overlaid it bombs.  And when sending it bombs
when trying to display the files to chose in a dialog box.  I have tried
this with slightly different results (but not good) using both the original
(Summer 1984) system and finder as well as the March 1985 update which
includes finder version 4.1.

John Dunlap    Applied Physics Lab, University of Washington
[e-mail]

[Ed. - Thanks for the report, it's been added to the "beware" file.]

------------------------------

Date: 1987 Mar 27   17:24 EST
From: Bob Babcock   <[e-mail]>
Subject: Sanyo Kermit and Auto Answer Modem Mode
Keywords: Sanyo Kermit

I saw your message in Info-Kermit digest complaining that you couldn't use
auto-answer mode on your modem with Sanyo Kermit.  I can think of two
possible problems.  One is that Hayes compatible modems have a command to
set the number of rings before answering, with zero rings meaning never
answer.  I think the usual default is to answer after one ring, but perhaps
not.  More likely, the problem is with DTR.  I don't remember offhand how
Sanyo Kermit leaves DTR set when not connected, but it could be telling the
modem to disconnect, which might reasonably be interpreted to mean don't
auto-answer either.  There is probably either a modem command or a switch
you can set to force DTR always high.  See if this makes it auto-answer.

Also, there is a version of Sanyo Kermit which requires the video board, and
has the same VT-100 emulation code as the IBM version.  Right now it's at
the 2.29a level, but I hope to bring it up to 2.29b or 2.30 in the not too
distant future.  There is also an independently developed Sanyo Kermit with
a VT-100 emulator which does not require a video board.  Last I heard, this
version was being upgraded from 2.28 to 2.29.

------------------------------

Date: 30 Mar 87 20:44:01 GMT
From: [e-mail] (William E. Davidsen Jr)
Subject: XENIX Clock Tick and Kermit
Keywords: XENIX, C-Kermit

Re: Info-Kermit Digest V6 #8:

In C Kermit there is code which assumes that for XENIX the CLOCK_TICK
should be 50. Xenix/286 runs 50 ticks per second, and the value should
be in milliseconds per tick (20). Older version ran 20 ticks/sec. There
is a simple solution fos all USG versions, SysIII and later:
  #include <sys/param.h>
  #define CLOCK_TICK 1000/HZ

This works for all systems with less than 1000 tick/sec, and avoids having
to change the value for other machines. Machines with fast clocks (such as
Cray2, once every 4.1ns) will need some minor modifications to this code.

2nd:

C Kermit compiled with the Xenix option doesn't reset the DTR line when
performing a connect after a hangup (via ^\H). With the SysV option the DTR
works correctly, but the lock file doesn't get handled correctly.  If anyone
has a fix for this it wold be desirable to have the line become active after
hangup without reselecting the device.

bill davidsen            sixhub \
      ihnp4!seismo!rochester!steinmetz ->  crdos1!davidsen
                chinet /
ARPA: [e-mail] (or [e-mail])

------------------------------

Date: Tue, 31 Mar 87 08:33:05 EST
From: John C Klensin <[e-mail]>
Subject: CP/M-80 kermit for the Epson PX-8
Keywords: CP/M-80 Kermit, Epson PX-8

As a general warning, while this version works quite well downloading files
to the RAM disk, it seems to hang up and get into trouble when used with
Epson's external 3 1/2 inch diskette unit.  When files of more than moderate
size are downloaded, the first 15Kb or so are transferred without
difficulty, then the number of retries suddenly goes 'way up, becoming about
1:1 with the number of packets.  It finally grinds entirely to a halt.
These problems are speed independent (they occur at 1200 baud, and they
occur at 19.2Kbaud in about the same place).  And they do NOT occur when the
default "disk" is the A: ram disk, only with the external diskette drive.

   Fixes or suggestions would, of course, be welcome.

------------------------------

End of Info-Kermit Digest
*************************
-------
 8-May-87 12:50:42-EDT,22980;000000000000
Mail-From: SY.CHRISTINE created at  8-May-87 12:48:51
Date: Fri 8 May 87 12:48:51-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V6 #10
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 07 May 1987       Volume 6 : Number 10

Today's Topics:

                        Use of [e-mail]
           IBM PC Kermit on the New IBM Personal System/2 Series?
                       MS-Kermit Works on IBM PC2/30
                       MS-Kermit Works on IBM PC2/50
                       Kermit-MS 2.29 Modem Problems
                  Local Echo Problem with MS Kermit 2.29B
                            MSVIBM.BOO Problems
                     Printer Control in MS-Kermit 2.29B
                       Apollo Kermits (Pascal and C)
                             Apollo Kermit bug
                    ISIS Kermit - fixes and frustrations
                            QL Kermit HEX Needed
                     Commodore Kermit .HEX file Needed
                       Bugs in new Apple Kermit (A2)
                           Bug in Amiga C-Kermit
                      C Kermit on Motorola Delta SVR3
                        Bugs in Sperry Univac Kermit

----------------------------------------------------------------------

Date: Mon, 20 Apr 87 08:12 EST
From: <[e-mail]> (brian nelson)
Subject: Use of [e-mail]
Keywords: KERMSRV

I would like to point out a couple of problems with requests to the Kermit
bitnet server here at Toledo. The first is that attempts to see if Kermsrv
is 'logged in', ie, SEN/COM UOFT02 CPQ U KERMSRV or SM RSCS MSG UOFT02
KERMSRV CPQ U KERMSRV will ALWAYS fail.  This is a VMS node running Jnet and
jnet treats server processes in a manner unlike VM does.

For all pratical purposes, Kermsrv is always running. If a message is sent
to it, and for some reason its not there, Jnet will tell you.

Secondly, KERMSRV can ONLY respond to interactive messages, it can not
process mail. I see several attempts per day to send it mail.

I hope this clarifies any confusion regarding the server here.

Brian Nelson

------------------------------

Date: Fri 3 Apr 87 12:26:06-EST
From: Frank da Cruz <[e-mail]>
Subject: IBM PC Kermit on the New IBM Personal System/2 Series?
Keywords: IBM PC System/2

Now that we've seen IBM's announcements for their new line of PCs, is there
anyone out there who can say whether IBM PC Kermit (2.29B or earlier) runs on
them?  If not, what are the symptoms?  If so, are there any peculiarities?

------------------------------

Date: Wed, 8 Apr 87 17:55:12 PDT
From: [e-mail] (Greg Small)
Subject: MS-Kermit Works on IBM PC2/30
Keywords: MS-DOS Kermit

MS-Kermit 2.27 ran OK [under DOS 3.3 on the PC2/30] with the serial port so the
serial UART and interrupt controlers are compatible.  Requires distribution of
software in 3.5" floppy format.

------------------------------

Date: 14 April 1987, 11:15:11 CST
From: [e-mail] (Michael Palmer)
Subject: MS-Kermit Works on IBM PC2/50
Keywords: MS-DOS Kermit

Am coming to you now from a model 50.  Kermit ... work[s] fine with it.

------------------------------

Date: Wed,  6 May 87 13:26 EDT
From: HOLLEY  <BOB@SER>
Subject: Kermit-MS 2.29 Modem Problems
Keywords: MS-DOS Kermit, Modems

Our data center began distributing Kermit-MS 2.29 in the later part of last
fall.  Several weeks after we began, it became obvious that version 2.29
would not work for users who had internal modems.  In January, we learned of
version 2.29B, which appeared to address the internal modem problems, and we
began to distribute that.

We thought all our problems were solved, but now we have several people with
internal Hayes 1200B "short card" internal modems (at least one of those has
his modem card plugged into a true IBM-XT), who seem to be having troubles
even with 2.29B.  In addition, we just came across the following article in
the March/April issue of the University Computing Services Newsletter of the
University of Oklahoma:

HAYES MODEM INCOMPATIBLE WITH KERMIT

There is a new Hayes internal modem which is incompatible with Kermit-MS
version 2.29.  The modem is model 1200-B, the same designation used for
previous models.  The distinction is that it is on a half-length or "short
card."  Short cards are about 7 inches long.

This incompatibility is distressing because Hayes modems are generally
acknowledged as the industry standard and Kermit-MS supports Hayes
compatible modems.  The Hayes short-card modems fail to establish a
connection when used with Kermit-MS version 2.29.  They may be incompatible
with other software as well.  They do work with Hayes SmartCom software and
earlier versions of Kermit-MS.  Hayes-compatible modems from other vendors
work with 2.29.  This problem is unlikely to be resolved in the near future.

(Reprinted from the University of Nebraska at Omaha Campus Computing
Newsletter, March/April 1987)

It is not entirely clear whether the above article is referring to the
original release of Kermit-MS 2.29 or to Kermit-MS 2.29B.  One is led to
suspect the latter, though, as we never found ANYONE with an internal modem
of any kind that could get 2.29 to work.

Is there really some particular problem with Hayes 1200-B "short-card"
internal modems and Kermit-MS 2.29B??  If there is, we would like to warn
our users not to purchase this particular equipment.

Thank you for your kind attention.

Robert M. Holley
Director, User Ed & Pubs
Southeast Regional Data Center
Florida International University
Miami, Florida

BITNET Addresses:  BOB@SERVAX or BOB@SER

[Ed. - The current developer of MS-Kermit tested 2.29B with a loaner Hayes
1200B half-height card, and it worked successfully.  Another user with an
Everex half-height Hayes clone also reported successful operation.  Can anyone
else with these modems report further, so that if any additional fixes are
needed, they can get into 2.30 before its final release?]

------------------------------

Date: Thu, 16 Apr 87 10:24:37 CDT
From: [e-mail] (Keith Pyle)
Subject: Local Echo Problem with MS Kermit 2.29B
Keywords: MS-DOS Kermit

One of my co-workers asked me to report that there is apparently a bug in
the handling of local echo with MS Kermit 2.29b.  When transferring files to
or from a CMS system (CMS Kermit 3.1), he has noted that the first character
typed as a command to the CMS Kermit will be displayed but that subsequent
characters do not appear until after the return is entered AND the CMS
Kermit has processed the command.

Keith Pyle    [e-mail]

[Ed. - We are unable to reproduce this problem, using PC/ATs and a VM/CMS
system running the same version of CMS Kermit.  Has anyone else experienced
a problem like this?]

------------------------------

Date: 26 April 1987, 16:38:47 EST
From: Aharon Friedman           516-282-7979         FRIEDMAN at BNLVMA
Subject: MSVIBM.BOO Problems
Keywords: MS-DOS Kermit

I have problems with that file. It stalls the computer after running
msbpct on it.
              Aharon Friedman

[Ed. - Most likely the .BOO file was the victim of a nonstandard ASCII/EBCDIC
translate table somewhere on its journey between its home on CUVMA and your
PC.  The .BOO file has been successfully decoded at many other BITNET sites.]

------------------------------

Date: 29-APR-1987 10:53:36
From: [e-mail]
Subject: Printer Control in MS-Kermit 2.29B
Keywords: MS-DOS Kermit

Printer control from vn 2.29b of IBM Kermit is fine in the sense that it
appears to correctly handle flow control etc.

However, if you are expecting to use the power of the printer via escape
sequences then you will be disappointed.

There are two modes for controlling the printer port directly from the
terminal line : Esc [ 5 i and Esc [ ? 5 i. The former is used to select
a transparent mode (no screen echo), while the latter selects a
conversational mode (with screen echo).

The important point about transparent mode is that no escape sequences
received by Kermit in this mode should be interpreted for the screen's
purposes - they should all be passed on unchanged to the printer, with
the sole exception of the escape sequence which closes the printer port
( Esc [ 4 i ).

Version 2.29b does no such thing - it interprets an escape sequence and
appears to remove the escape and the character following from the stream
of data. This is consistent with a primitive two byte escape sequence
model beloved of VT52 and other simple terminal protocols.

It has another related failing : since Kermit appears to regard nul as a
padding character to be thrown away at liberty, it continues to do this
in transparent printer mode. Some printers (e.g. the Epson family)
feature nul as a required part of an escape sequence. More important
perhaps is that more recent printers have started to offer a downloading
facility for character sets. A character definition of course is
supplied as a sequence of bytes rpresenting the rows of the matrix, and
nul is the value required for an empty row.

I know I may be asking the printer support module to run before it can
walk, but I hope you can appreciate the importance of the matter.

Cheers : Norman Bridges.

------------------------------

Date: Tue, 31 Mar 87 14:05:09 MST
From: "Tim E. Barrios" <[e-mail]>
Subject: Apollo Kermits (Pascal and C)
Keywords: Apollo Kermit

Thanks for fixing the ^Y's in the file.  Now, it looks like there is one
key character that is missing from the following lines causing a syntax
error when compiled:
    567, 577, 850, 1282, and 1442
my guess is that the character is '&'.  this might have been related to the
^Y problem.

About the 'C' version, it's been almost a year since I messed with it, but it
had something to do with a difference between the Unix sys5 include library's
'.h' (some record's struct statement) and what the kermit source expected.
The person who is working on that problem is:
   wicinski@nrl-css (arpa net)
we have kept in touch concerning both versions on the apollo.
thanks,
tim barrios

[Ed. - See message below...]

------------------------------

Date: Fri 3 Apr 87 15:34:12-PST
From: Ted Shapin <[e-mail]>
Subject: Apollo Kermit bug
Keywords: Apollo Kermit

I'm sorry that the Pascal source file I sent you for Apollo Kermit had some
errors in it.

For reasons I have not yet found, when I sent APOKERMIT.PAS from the Apollo
to the DEC 20 using TOPS 20 KERMIT version 4.2(253), alll the "Y" characters
turned into "control-Y's", and all of the "&" characters were missing.  When
I sent the same file to an IBM-PC using KERMIT-MS version 2.29b, the file
was sent correctly.

[Ed. - All of the changes have been made so the Apollo Kermit should be ok
now.]

------------------------------

Date: 17 Apr 87 17:48:00 EDT
From: John R. Williams <[e-mail]>
Subject: ISIS Kermit - fixes and frustrations
Keywords: ISIS    Kermit, MDS Kermit, iPDS

For those of you who have implemented Bill Boyd's latest version of ISIS
Kermit (see the Digest, Volume 6, Number 9) I have an interim fix for the
problem of losing characters in Connect mode and a plea for help concerning
the program's performance.  I have not been able to contact Mr. Boyd.

First, the fix.  This will allow at least some of you to operate in Connect
mode at 4800 and 9600 baud.  It will still occasionally miss characters at
4800 baud and consistently miss 1 or 2 characters per line at 9600 baud,
but in my case, at least, 9600 baud Connect mode operation is now usable, if
not perfect.

In the Connect Module, find the statement that looks something like this:

    if ready(port) > 0 then call putc(getc(port, 0);

Declare a temporary variable, such as "i", and then enclose the above
statement in a DO loop, like this:

    declare i byte;
        .
        .
        .


    do i = 1 to 200;
      if ready(port) > 0 then call putc(getc(port), 0);
    end;

This causes the program to read the input port 200 times for every time it
checks for keyboard input.  The loop termination value 200 was determined
empirically.  You may find that another value works better for you.  I also
replaced "putc" with "co", which bypasses the status checking provided by
"putc".  That may not provide any real benefit.

Next, performance considerations.  You may be interested to know that in my
system file transfer at 19200 baud occurs with no errors.  The only problem is
that screen output at 19200 is pure gibberish - it misses 50 to 70 per cent of
the characters, even with the fix noted above.

The performance problem that concerns me with the new version, however, is
that for some reason when receiving files the time between packets is
excessively long, averaging about six seconds!  The old version is at least 10
times faster under the same circumstances, and I cannot find any code
differences to account for it.  The delay is apparently in procedure RPACK
where it waits to receive the SOH.  If anyone has an explanation and a fix for
this condition, I am most anxious to hear from you!

All my experience with ISIS Kermit has been using a Series III MDS, with a
Winchester disk, connected directly to a VAX 11/782 terminal port (no modem).
The VAX is running VMS Kermit-32 version 3.2.77 under VMS 4.4.

Also, if anyone has had any success using ISIS Kermit on an iPDS, I'd like to
share experiences with you.  In my version, the iPDS receives VAX files OK but
fails miserably when sending.

John

[Ed. - Thanks.  This note has been put into the file KER:MDSMIT.BWR.]

------------------------------

Date: Wed, 22 Apr 87 11:38:17 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: QL Kermit HEX Needed
Keywords: Sinclair QL Kermit

Probably not many Sinclair QL users own a disk drive nor do they have the C
compiler available.  Couldn't someone send a hex file to be included in the
Kermit library?  Thanks in advance.

[Ed. - If someone could send a .HEX file for this Kermit version, we would
be glad to include it in the regular Kermit Distribution.]

------------------------------

Date: Wed, 22 Apr 1987 14:53 EST
From: Ray Moody <MOODY@PURCCVM>
Subject: Commodore Kermit .HEX file Needed
Keywords: Commodore Kermit

    I have received several requests to create a .HEX file for Commodore
Kermit Version 2.  I don't have a program that can create .HEX files.  Is it
possible for someone else to create the .HEX file?

                                        Ray Moody
                                         [e-mail]
                                         ihnp4!pur-ee!s.cc.purdue.edu!aij
                                         [e-mail]

[Ed. - Can anyone create a .HEX file for Commodore Kermit and send it in for
redistribution, or send some kind of .HEX-file maker & decoder to Ray?]

------------------------------

Date: 24-APR-1987 10:31:30
From: [e-mail]
Subject: Bugs in new Apple Kermit (A2)
Keywords: Apple II Kermit

Alan Thomson of our Chemistry department reports a few problems with the new
A2 Apple Kermit. These were found using a non-interrupt driven Mountain
Hardware CPS card (the driver for which will be sent over to you soon):

  1. When using GET, A2 Kermit lingers around doing things internally for long
     enough to miss the first few characters of the server's response. After
     timing out and retrying things settle down to work OK.

  2. After issuing FINISH the Apple side waits for 5 seconds before reissuing
     its command prompt.

------------------------------

Date: Sat, 25 Apr 1987 00:50 CST
From: Ian Horstmeier <HORSTMIH@UREGINA1>
Subject: Bug in Amiga C-Kermit
Keywords: C-Kermit

I recently received this from a friend of mine regarding C-kermit for the
Amiga.  Perhaps this information will be useful.

Subject - Re: Using VT100/KERMIT and IBM systems
Summary - The fix for C-Kermit

The reason that C-kermit on the Amiga doesn't work with the IBM, is because
the parity is not set!  I got my version of C-Kermit from kermserv@cuvma
on BITNET, and it still contains this bug.  In the CKICON.C module, look
in the connect mode function.  In about the middle of it, there is a call
to the output a character function ttocq(c).  This needs to be changed to
ttocq(dopar(c)).  There! It now works with IBM and sets parity correctly.
According to the comments in the code, Kermit does its own parity checking
and the serial.device is always in 8 bit no parity.  I always use kermit on
the mainframe and the vax.  One thing you will notice is that the standard
amiga keymap does not generate codes to be compatible with anything!  I am
in the process of writing a keymap module for amiga c-kermit to make it look
like a vt100.   Good luck!
                                                              Walter Reed

UUCP :  ihnp4!umn-cs!ndsuvax!ncreed
Bitnet: ncreed@ndsuvax  OR NU105451@NDSUVM1

[Ed. - Thanks for the fix -- it's been added to CKIKER.BWR.  Further reports
would be appreciated.]

------------------------------

Date: 29 Apr 87 16:41:05 GMT
From: seismo!gatech!mcdchg![e-mail] (Ron Heiby)
Subject: C Kermit on Motorola Delta SVR3
Keywords: C-Kermit

Hi!  I just finished bringing up C Kermit 4D(061) on a Motorola Delta system
running System V/68 Release 3.0.  I found some minor problems that I thought
should be mentioned.

The entry in the makefile (ckuker.mak) for "att3bx" and the corresponding
#define for "ATT3BX" is actually not dependent on the AT&T 3B architecture.
It is for the AT&T Basic Networking Utilities (BNU), also called "Honey
DanBer UUCP".  This version of uucp is standard with System V Release 3
as it comes from AT&T and as implemented on the Motorola systems.  I suggest
changing the makefile and define to something more like "hdbuucp" or something
like that.  Of course, HDB is not restricted to System V releases, so the
"-D" for it should probably be seperate from any particular "make" target.

The "beware" file for C Kermit talks about a name confilict on "unchar" for
ATT 3Bx systems.  This is really a System V Release 3 issue and is also
the case for the Motorola implementation.  I tried the suggested fix, of
"-Dunchar=myunchar" in the makefile and, as expected, it didn't help.  I
edited the files used for my build to change "unchar" to "myunchar".  There
are other references to be changed for non-UNIX builds.  The files I changed
for this were: ckcker.h, ckcpro.w, ckcfn2.c, and ckcfns.c.

System V Release 3 has re-defined the signal(2) system call as:
    extern    void (*signal())();
instead of:
    extern    int (*signal())();
This means that lines in ckudia.c, ckuusr.c, and ckuscr.c must be changed
to avoid illegal pointer combination errors.  I just changed "int" to "void"
in each case.  Better (more general) would be to use a typedef based on a
define, like "SVR3" (which might also cause the BNU locking code to be used).

The C compiler that comes with SVR3 is no longer so forgiving of random tokens
following preprocessor directives.  Convention has been to do things like:
    #if FOO
        code
    #else !FOO
        other code
    #endif FOO
This causes warnings on both the #else and #endif.  Correct would be:
    #if FOO
        code
    #else /* !FOO */
        other code
    #endif /* FOO */
Several places in ckutio.c had to be changed for this.

Also, ckcdeb.h includes some #include lines for "vax11c" which are not
of legal format.  Even though they are bounded by #ifdef/#endif, the
pre-processor still sees them and barfs.  I changed the conditionals
surrounding them to cause them to actually be commented out, if "vax11c"
were not defined.  This problem could be construed to be a bug in the
C Pre-processor, but I don't have a copy of a current ANSI spec, so am
not sure.

Here are context diffs of the code changes I made.  "orig" is the original code
as I received it.  "save" is the code as I modified it to compile properly.

[Ed. - This message, and the diffs, have been added to CKUKER.BWR, and will be
looked at for the next release.  Thanks!]

Ron Heiby, [e-mail]    Moderator: comp.newprod & comp.unix
Motorola Microcomputer Division (MCD), Schaumburg, IL
"I am not elsewhere."

------------------------------

Date: TUE, 14 APR 87 14:34:41 GMT
From: ROGER @ UK.AC.TPB
Subject: Bugs in Sperry Univac Kermit
Keywords: Sperry Kermit, Univac Kermit

    I recently acquired a copy of Sperry UNIVAC KERMIT written in assembler,
for use on a non front end site.

    After a little tinkering , to get it to work with our setup , I discovered
a couple of little coding bugs.  I must admit I'm not the world's greatest
programmer in @MASM, but I THINK (underline that in italics) I've sorted them
out:

    There was a bug in the SHOW SEND routine that caused the SEND STARTOFPACKET
displayed to be the RECEIVE STARTOFPACKET, and a bug in the SHOW RECEIVE
routine that caused it to display the SEND STARTOFPACKET.

    No prizes for guessing what had happened !!!!

    The actual parameters in the SHOW list had been juxtaposed; simply
swapping over lines 2281 and 2300 in the original source should cure the
problem.

    Another more serious problem was that when assembled with MDLFE=0 and
DCPFE=1, the code still expected to find a couple of entrypoints that
weren't there: they'd not been assembled because of a conditional directive.

    My cure is rather elegant, but as I've no idea what I've done it may not be
the right one.  All I did was to move the offending reference, in line 2613 to
only occur in the conditional directive immediately following it. that is line
2613 was inserted AFTER the IF MDLFE statement.

    That seems to have cured it, it now @MASM's without errors, and @MAP's
without errors.  I've succesfully used it in SERVER mode with a PC clone
running CROSSTALK, so I assume I've done the right thing.

     If anyone else has any tips or points Id like to hear from them.

Jason LoCascio,
British Gas PLC
59 Bryanston Street
LONDON
W1
[phone] ext. 1289

Or I can be contacted at THAMES POLYTECHNIC , via JANET :-
ROGER @ 000045399000.TPB.SPCP.FTP.MAIL
(We are not registered in NRS yet)

------------------------------

End of Info-Kermit Digest
*************************
-------
-------
21-May-87 15:52:34-EDT,23406;000000000001
Mail-From: SY.FDC created at 21-May-87 15:51:32
Date: Thu 21 May 87 15:51:32-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V6 #11
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 21 May 1987       Volume 6 : Number 11

Departments:

  ANNOUNCEMENTS -
    Mailing List Problems
    New Release of NIH TSO Kermit
    New TSO Kermit for the 3708 Front End
    New Version of CDC Cyber NOS Kermit
    Announcing Kermit for Lilith Workstation in Modula-2
    New Release of Acorn BBC Kermit
    New C-Kermit for the Sinclair QL version 1.10
    Another New Kermit for Sinclair QL
    Version 1.01 of Kermit for HP86/87 Available
    Announcing Kermit for ICL PC Quattro
    New Apple II Kermit 3.75 Driver for Mountain Hardware CPS Card
    Kermit Tape Reader Sperry/Univac/Unisys Systems

  REPORTS -
    Apple ][ Kermit Comments
    Unix V.3 & kermit
    VMS Kermit HELP files
    Qkermit problems

  QUERIES -
    MVS/TSO Kermit to work with Amdahl V7 & V8?
    Sending BREAK from Toshiba 3100?
    Is Kermit available for Digital VAXmate?
    Kermit for Wang VS-100?

----------------------------------------------------------------------

Date: 21 May 87 3:22:00PM EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Mailing List Problems

Due to many changes in network host tables recently installed on CU20B,
there was a lot of trouble mailing the last Info-Kermit digest, V6 #10.
Some people got 0 copies, some got 1, some got 2.  If you receive this one
but didn't receive the last one, send a note to Info-Kermit-Request@CU20B to
get a copy.  If you got an extra copy, just send it back (just kidding).
Since #10 was sent out, the mailing list has been corrected to mostly agree
with the new host tables.  Apologies for the inconvenience.

------------------------------

From: "Roger Fajman" <RAF@NIHCU>
Date: Tue, 28 Apr 87  01:53:55 EDT
Subject: New Release of NIH TSO Kermit
Keywords: TSO Kermit, IBM Mainframe Kermit
Xref: MVS/TSO, see TSO

This is to announce release 1.0.1 of NIH MVS/TSO Kermit, which fixes some
installation problems.  There were problems with the installation JCL,
assembling the table module under assembler FX, and using MVS/370 instead of
MVS/XA.  I think that these have all been fixed.  The bugs in NIH TSO Kermit
itself are currently being worked on.  I hope that we will have a release with
those fixes in a few weeks.

[Ed. - Thanks, Roger!  The new files are in KER:TSN*.* at CU20B, or TSN* *
on BITNET, available from KERMSRV at CUVMA, and will appear on Kermit Tape B.]

------------------------------

Date: 15 May 87 1:23:45
From: Christine M. Gianone <[e-mail]>
Subject: New TSO Kermit for the 3708 Front End
Keywords: TSO Kermit, MVS/TSO Kermit, 3708 Front End

And here's still another new TSO Kermit.  This is actually the original,
primitive version 1.0, modified to support the 3708 front end, add missing
error messages, and tested under MVS/XA and TSO/E.  The modifications were
done by Geoffrey S. Mendelson, Sungard Central Computer Facility in
Philadelphia, and sent in on tape.  The source files are available in
KER:TS3*.* for anonymous FTP from host CU20B, in TS3* * on CUVMA for BITNET
retrieval via KERMSRV, and will appear on Kermit Tape B.  Let's hope that
the 3708 support can be integrated into (one of?) the "mainline" TSO
Kermits, and eventually also into the forthcoming portable 370 Kermit.

------------------------------

Date: 12-MAY-1987 15:58:49
From: [e-mail]
Subject: New Version of CDC Cyber NOS Kermit
Keywords: CDC Cyber Kermit, NOS Kermit
Xref: Cyber, See CDC

Here is version 1.30 of Kermit for CDC Cyber running NOS 2.4, written by
Allison Ballard and Paul Jarvis of Imperial College, London.  This version
has support for sliding windows, and is written in Compass.

The files you should get are:

NOSKER.BWR - "Beware" file
NOSKER.CAP - NOS Kermit capabilities at a glance
NOSKER.DOC - User manual
NOSKER.INS - Installation instructions
NOSKER.SRC - Source program

                Alan Phillips, Lancaster University

[Ed. - Thanks for sending these files, Alan, and thanks to Allison & Paul at
Imperial College for writing the program.  This puts the number of CDC Cyber
Kermits at 4.  This version has been added to Tape C, since Tape B is
getting rather full.  Hopefully in the future, the two Compass versions can
be merged.  The files are available for network access as KER:NOS*.* on
CU20B and NOS* * on CUVMA (BITNET).]

------------------------------

Date: 15 May 87 4:01:32PM EDT
From: Christine M. Gianone <[e-mail]>
Subject: Announcing Kermit for Lilith Workstation in Modula-2
Keywords: Lilith Workstation Kermit, Modula-2

This is to announce Kermit for the Lilith Workstation, written in entirely
Modula-2 by Matthias Aebi, Institut fuer Informatik, University of Zuerich,
Switzerland.  While certain dependencies on the Lilith Medos file system are
implicit in the program, it should be readily portable to any system that
has a Modula-2 compiler.

The files are in KER:M2*.* (actually, K3:, i.e. it goes on "Tape C"),
available for anonymous FTP from CU20B, or M2* * via KERMSRV from BITNET
host CUVMA.  M2*.MOD are the Modula-2 source files; M2*.DEF are the symbol
definition files.  M2KERM.HQX is a Macintosh Word formatted user manual to
be unpacked on a Mac by BinHex; M2KERM.DOC is the same, but saved "text
only" as a plain ASCII file and then edited by hand to remove excess blank
lines & rejustify the paragraphs (apologies to Matthias for whatever
mangling this may have caused).  There's another BinHex document,
M2TITLE.HQX, whose original name was something about TitelBlatt (i.e. Title
Page), but I couldn't find the accompanying application to display it on the
Mac.  Many thanks to Matthias for contributing this version, and to
Columbia's Carlos Albuerne for actually bringing it to us on a Mac diskette.

------------------------------

Date: 15-May-1987 12:16:44
From: Christine M. Gianone <[e-mail]>
Subject: New Release of Acorn BBC Kermit
Keywords: Acorn BBC Micro Kermit
Xref: BBC Micro, See Acorn

This is to announce version 1.45 of Acorn BBC Kermit from Alan Phillips of
Lancaster University ([e-mail]),
which replaces version 1.30 of April 1986.  The program runs on Acorn models
B, B+, B+128, and Master 128, with Acorn DFS, 1770 DFS, ADFS, Econet, or any
other Acorn-compatible filing system.

Version 1.45 comes with numerous big fixes and improvements, new
documentation (including a 124-page manual), and a new version (1.50) of
Alan's free 65c02 assembler (which can be used to assemble the program by
those who don't have the ADE assembler).

The new version is in KER:BBC*.* (really K3:, or Tape C), for anonymous FTP
from CU20B, and as BBC* * on BITNET/EARN from KERMSRV at CUVMA.  The file
BBC145.ANN lists in detail the changes to BBC Kermit since version 1.30.
The source is in BBCKER.ASM, which is actually the concatenation of many
smaller files (explained in comments at the top).

Version 2.0 of BBC Kermit (which will appear in "many months") will support
sliding windows.  Thanks to Alan for producing this new version and sending
it to us over BITNET.

------------------------------

Date: 8-MAY-1987 14:50:05
From: Jonathan Marten
Via: [e-mail]
Subject: New C-Kermit for the Sinclair QL version 1.10
Keywords: Sinclair QL Kermit

It seems that new versions of Kermit for the Sinclair QL are appearing thick
and fast, and this parcel is no exception.  I have taken the original C
version written by Robert Coughlan of Liverpool University and greatly
expanded it, replacing may of the features which were removed from its
C-Kermit base to reduce its size; and also added some new ones.  These
include default devices, file name translation and transfer interruption;
however server mode is not supported, which the BCPL version in [.QL2] does.

It also does not support the Q-Connect module or any form of flow control
other than CTS/RTS.  It however includes most of the interactive command
parser features of full C-Kermit.  Hopefully you (or someone out there!)
will find a use for it.

Full documentation is supplied in QLKER.DOC.  This version is written to be
compiled using the Metacomco C development system.  The files need to be
renamed before compilation.

If it turns out that somebody is interested in using this version, I would
be pleased to receive bug reports or improvement suggestions.
Unfortunately, I have no electronic mail address so I cannot support them
that way.  Perhaps some other way could be found.

Jonathan Marten
89 Austen Road
Farnborough
Hampshire GU14 8LG
ENGLAND
[phone]

[Ed. - These files have replaced the old version as KER:QLK*.* on CU20B for
anonymous FTP access.  The old version is in KO:QLK*.* for now.  BITNET
users may ask KERMSRV at CUVMA for them as QL* *, and they are on Kermit
Tape C for mail orders from Columbia.]

------------------------------

Date: 1-MAY-1987 14:50:11
From: [e-mail]
Subject: Another New Kermit for Sinclair QL
Keywords: Sinclair QL Kermit

Author - David Harper, Dept. of Applied Maths, Liverpool University
(SX36 @ UK.AC.LIV.IBM)

This version of Kermit for QDOS is written in BCPL and is based upon
C.G.Selwyn's Tripos implementation.  [Ed. - We never saw the Tripos version.
If anyone out there cares about it, we can try to unearth it.]

The main features are:

(1) It is executed as a QDOS job and so it can run in parallel with other
    jobs, including SuperBasic. This means that all the facilities of the
    QL are available, even when file-transfer is in progress.

(2) It can operate in both local and server mode - the latter is ideal for
    transfer between the QL and another micro, which can view the QL as a
    remote 'mainframe'.

(3) A simple teletype terminal-emulator is provided for use when the QL is
    required to communicate with a mainframe.

(4) Software support is provided to allow QL-Kermit to be used with the
    Tandata QConnect communications device. This is recommended when
    the remote mainframe uses XON/XOFF handshaking, since the QL hardware
    can only do CTS/RTS handshaking.

(5) The TAKE command is provided to allow the user to put often-used
    sequences of Kermit commands into a file.

(6) A HELP command is provided to remind the user of the commands which
    can be issued. In addition, HELP SET displays all the SETtable
    options.

Copies of QL-Kermit can be obtained by sending a formatted microdrive or
3.5 inch disk with a padded SAE to

  David Harper
  Dept of Applied Maths and Theoretical Physics
  The University
  P.O. Box 147
  Liverpool   L69 3BX
  ENGLAND

(This address is only valid until September 1987, and only within UK)

At present, the source code files and the EXECable code just fit onto a single
microdrive. They occupy about 207 blocks. In view of probable future
extensions, it might be advisable to send two microdrives or a disk if you want
both source code and EXEC code files.

The BCPL source code should be compiled using Metacomco's BCPL Development Kit
(Vn. 2.0 or after).

[Ed. - This new implementation of QL Kermit is in KER:QL2*.* on CU20B,
QL2* * on CUVMA for BITNET KERMSRV access, and on Kermit Tape C.]

------------------------------

Date: 29-APR-1987 15:36:36
From: [e-mail]
Subject: Version 1.01 of Kermit for HP86/87 Available
Keywords: HP86 Kermit, HP87 Kermit

On its way to you is version 1.01 of Kermit for the HP86/87, by Martin Rootes
of Sheffield City Polytechnic, UK.  This release cures some flow control
problems in version 1.00.

The files for this release are:

HP8KER  BOO     Complete program - plus file header for boot programs.
HP8KER  BAS     Complete program - no comments, includes null lines.
HP8KRC  BAS     Complete program - with comments.

which should replace the existing ones.  All other files are unchanged.

[Ed. - These files are in KER:HP8*.* on CU20B, HP8* * on CUVMA, and are
available on Kermit Tape A (moved from Tape C).]

------------------------------

Date: 13-MAY-1987 14:20:57
From: [e-mail]
Subject: Announcing Kermit for ICL PC Quattro
Keywords: ICL PC Quattro Kermit, Concurrent CP/M-86

Here is a Kermit for ICL PC Quattro and PC 2 micros running Concurrent
CP/M-86 (Concurrent DOS).  It's by Chris Lock, Nottingham University.  I
think I sent these long ago, but they seem to have got lost somewhere.

The files in this lot are:

  CN8ICM.A86,CN8IPR.A86,CN8XIC.A86,CN8XIC.H86,CN8XIC.MSG

The CN8I*.ASM files are slight modifications to the system-independent files
that this version has to have in order to work.  The changes aren't
appropriate to other implementations.

[Ed. - Thanks, Alan.  These files have been added to the other Concurrent
CP/M-86 Kermit files in K3:, and placed in KERMSRV for BITNET/EARN access,
and on Kermit Tape C.]

------------------------------

Date: 14-MAY-1987 09:20:11
From: [e-mail]
Subject: New Apple II Kermit 3.75 Driver for Mountain Hardware CPS Card
Keywords: Apple II Kermit, Mountain Hardware CPS Card, CPS Card

Files A2CPS.HEX and A2CPS.M65 contain the hex and source respectively to use
the Mountain Hardware CPS card with Apple Kermit 3.75.

The driver is contributed by Alan Thomson, Department of Chemistry,
Lancaster University, Lancaster, UK (JANET mail address
[e-mail]2)

[Ed. - Thanks!  The files are in KER:A2CPS.* on CU20B, and similarly on
CUVMA KERMSRV, and included with Apple II Kermit 3.75 on Tape A.]

------------------------------

Date: April 21, 1987
From: Mike Lucich (via tape)
Subject: Kermit Tape Reader Sperry/Univac/Unisys Systems
Keywords: Sperry, Univac, Tapes

We here at Ft Leavenworth initially had a rough time reading the KERMIT
release tape on our Unisys (aka Sperry, Univac) 1100 mainframe and send you
the following program in the hope others will find it usefull.

We run both assembler and Pascal versions of KERMIT on our mainframe and
have made several minor changes to accomodate MS-DOS KERMIT Version 2.27
through our ancient C/SP front end processors.  Fortunately with MSKERMIT
version 2.29 these kludges are no longer required (the ability to set
handshake to any character solves our problems nicely).

Please feel free to refer any Unisys users with problems with KERMIT to us,
if we might help them.  Also please return our tape with the latest KERMIT
distribution to the address above.  We thank you!

Mike Lucich
USA ISC DOIM
Unisys Support Team
ATTN: ATZL-GMO-IA
Ft Leavenworth, KS  66027-5700

[Ed. - The COBOL program that reads a file from a Kermit tape (the format is
either EBCDIC OS Standard Label Format V or else ASCII ANSI Label Format D;
it's not clear from the message, most most likely it's the EBCDIC tape,
since this program itself arrived on an EBCDIC tape)... is in
KER:UNIVAC.INS, along with this message.]

------------------------------

Date: 11-MAY-1987 09:33:49
From: Martin J Carter <[e-mail]>
Subject: Apple ][ Kermit Comments
Keywords: Apple II Kermit

I've seen mentions recently in the Digest of Apple ][ Kermit, and I thought
I'd add my two penn'oth.

I have a rather battered Apple ][ Europlus, which I inherited with the
office, and am attempting to use a Kermit which announces itself as
"Stevens/CU-Apple ][ Kermit-65 ver 2.1a" (all in uppercase, as I'm working
with the naked original, without benefit of 80-column card or safety net),
which I pulled from Lancs last month and installed as per docs (but without
any bug patches not already in APPLEK.HEX).  We are having several problems,
which are probably related.

1) When I attempt to transfer a file to the Apple, the name gets mangled,
consistently: "applek.hex" becomes "!00,%+.(%8", at least on my screen.
(Numbers and punctuation get through OK, but the resultant filename can
never be kosher, so all you can do with the received file is delete it with
FID.)  This *only* happens when RECEIVEing or GETting files from a host
which sends the filename in lower case (in the F packet (?)).  There's ways
round it, but it's messy, and had me short-circuited for quite a time.

2) When I do SHOW ALL, many of the responses show up as blanks: VT52, IBM,
LOCAL-ECHO, EIGHT-BIT-QUOTING, FILE-WARNING, and FILE-BYTE-SIZE.

3) Text files transfer from the Apple OK, and binary files appear to
transfer also, but turn out to be parity-stripped on arrival.  (Note that
EIGHT-BIT-QUOTING and FILE-BYTE-SIZE are amongst those reported as blanks by
SHOW above.)  Debugging refused to work as well, which is at best confusing.

On further investigation, it turns out that the binary image generated by
APPDXL from APPLEK.HEX ends somewhat further on than implied by the "save
file length" parameter L$4E00 used in the documentation.  When I used the
slightly larger value L$5000, Problem (2) went away, and I've no doubt so
did Problem (3).  (Should the docs be fixed, or just post a "beware" file?)

I've just yesterday pulled the A2 AppleDOS/ProDOS Kermit from Lancs, so I'll
let you know if Problem (1) has persisted into this version.  In the
meantime, since the Stevens/CU APP Kermit is still around, I thought it best
that others profit by my blunderings.

Yours in plaster,

        Bruised of Nottingham <[e-mail]>

[Ed. - Thanks for the report, which we've added to the .BWR file for this
version.  Meanwhile, any comments from users of any of the various Apple II
Kermit programs?]

------------------------------

Date: Tue, 12 May 87 09:03:31 EDT
From: Russell Nelson <[e-mail]>
Subject: Unix V.3 & kermit
Keywords: Unix System V.3

Have you heard anything about using kermit with Unix V.3?  AT&T has a new
terminal driver (uugetty) for modem lines that does not work well with
kermit.

I've finally got 'cu' working.  kermit dies because uucp owns the port.
I've tried changing ownership and protection on the port.  cu or uugetty
keeps changing them back.

[Ed. - If users of Sys V.3 can supply details or fixes, we'll include them
in the next release of C-Kermit.]

------------------------------

Date: 15-APR-1987 15:18:59
From: [e-mail]
Subject: VMS Kermit HELP files
Keywords: VMS Kermit

Any idea what's happened to VMSSYS.HLP and VMSUSR.HLP? They don't seem to
exist any more (people are asking me where the help info is on the new
TRANSFER command.....)  Alan

[Ed. - I'm not sure what the difference is between them and the current
VMSMIT.HLP, but the old files you mentioned have been put back in the VMS
Kermit distribution, in hopes that someone will straighten them all out.]

------------------------------

Date: Wed, 13 May 87 10:42:36 GMT
From: CAPURSO@IBACSATA
Subject: Qkermit problems

We are linking our computing resources using kermit and all went ok
using Unix-kermit , CMS-Kermit , Ms-Dos kermit downloaded from Columbia.
But we had some problems using QKERMIT emulating TEK4010.
1 - we got QKMSTV.HEX, converted to QKMSTV.EXE
2 - we got source, recreated the overlay KERMIT.000
3 - we got QKVT1.TBL, renamed KEYTABLE.DAT
4 - we get an error when a graphical application starts writing:
       TURBO GRAPHICS error #1 in procedure #0 . Press Return
    we give RETURN and all goes ok. STRANGE ... ?
    We read on QKMSTV.BWR that perhaps we need the file 4X6.FON . SURE ?
5 - we rebuilt KERMIT.000 using QKMSVT, because we DO have TURBO PASCAL
       but NOT the graphical toolbox . Then, we renamed KERMIT.000 and all
       went OK. We have the plots, but why don't you distribute also the
       overlays?     THANK YOU - MARIO

[Ed. - Your comments have been forwarded to the contributor, VIC@QUCDN.]

------------------------------

Date: Tue, 31 Mar 87 12:43 EST
From: [e-mail]
Subject: MVS/TSO Kermit to work with Amdahl V7 & V8?
Keywords: MVS/TSO Kermit

We have two IBM/370 plug-compatibles (Amdahl V7 & V8) on which we have tried
the MVS/TSO Kermit from Toronto with indifferent success. We got it to work
on the V8 but not on the V7; the version on the V8 has twice died for
reasons uncertain/unknown. We are contemplating trying to adapt the NIH
version (which runs under MVS/XA)to our non-XA systems.  We would GREATLY
like to communicate with anyone out there in the IBM world whose
configuration approximates ours, for exchange of information.

We run MVS 3.8, SP 1.3.4 ; the TP packages in the host are ACF/VTAM V2.1
and TCAM10. The TP front-end packages are ACF/NCP 2.1 (SDLC) and EP (2703)
(Async/Bisync).

If you are listening and would be willing to share your experiences, please
send mail to JFisher @ MIT-MULTICS.ARPA.  Thanks in advance !

------------------------------

Date: Thu 14 May 87 00:16:01-EDT
From: Michael van Biema <[e-mail]>
Subject: Sending BREAK from Toshiba 3100?
Keywords: Toshiba 3100, BREAK

I ported MSKERMIT to my Toshiba 3100, but BREAK does not seem to work.  Does
anybody have any experience with this problem?  I am using the Toshiba internal
modem.

Michael

------------------------------

Date: Thu, 7 May 87 16:07 CST
From: <[e-mail]>
Subject: Is Kermit available for Digital VAXmate?
Keywords: VAXmate Kermit

Has anyone ported Kermit to the Digital VAXmate?  The VAXmate is IBM
compatible, and includes MS-Windows.  I can't find a way to bootstrap Kermit.
The standard package apparently does not include a language or the assembler.

Thanks in advance for any help.

Ed McGuire
Systems Coordinator
Grinnell College
[e-mail]

[Ed. - Since the VAXmate is IBM compatible, you should be able to execute
MS-Kermit directly from an IBM PC or AT Kermit diskette.  If you don't have
a Kermit diskette, you should be able to use the "baby Kermit" in BASIC
(listed in the Kermit book) to bootstrap it (the VAXmate comes with BASIC,
right?).  Reports about the operation of IBM PC Kermit on the VAXmate would
be most welcome.]

------------------------------

Date: Thu, 14 May 87 05:16:27 PDT
From: Ted Medin <[e-mail]>
Subject: Kermit for Wang VS-100?
Keywords: Wang VS-100

 We need a kermit for the wang vs-100 can anyone help us.
                                Ted
                     mailing address "[e-mail]"

[Ed. - Many people have requested Kermit for Wang VS systems over the years,
but no one has ever volunteered to write one.  Is there anyone out there who
might be equipped to do this?]

------------------------------

End of Info-Kermit Digest
*************************
-------
 3-Jun-87 14:10:57-EDT,16159;000000000000
Mail-From: SY.CHRISTINE created at  3-Jun-87 14:10:24
Date: Wed 3 Jun 87 14:10:24-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V6 #12
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 3 Jun 1987       Volume 6 : Number 12

Today's Topics:
                 New IBM PC Kermit with Tektronix Emulation
                             QK-Kermit Answers
                  Macros for VAX/VMS EDT in MS-Kermit 2.28
                          Apple II Kermit Answers
                    Sending BREAK from Toshiba Lap Tops
                             UNIX V.3 & Kermit
                    IBM PC Kermit 2.29b Screen Color Bug
                      Handshake Bug in MS Kermit 2.29
                 Inconsistent Length of BREAK in MS-Kermit
                     Patches for HP-150 Kermit Problems
                   Kermit Has Made It To the Board Level
                       Does Perkin-Elmer Kermit Work?

----------------------------------------------------------------------

Date: Monday, 18 May 1987 15:37:59
From: [e-mail]  ([e-mail]-ICF)
Via: [e-mail]
Subject: New IBM PC Kermit with Tektronix Emulation
Keywords: Tektronix Emulation, MS-Kermit

I have developed an IBM TEK emulation for KERMIT, and am sending you the
.BOO file. The notes below are intended for a .BWR file - I have called the
version MSTEK.BOO.

This is a version of KERMIT 2.29 with a built-in Tektronix emulator. Please
note:

1. This version will work with IBM CGA graphics, or any software that emulates
it. It will not work with Hercules, but should work on an EGA card, but only in
CGA resolution.

2. The TEK emulation is not complete - in particular, the characters are IBM's
own character set and there is no MARGIN 1. All vectors should, however, be
correctly positioned in relation to one another, though the aspect ratio may
not be perfect. In addition, a cross-hair facility is provided. Use arrow keys
to move the cross-hairs, and SHIFT-arrow for faster movement.

3. TEK mode is entered from VT or other mode upon receipt of the sequence ESC
FormFEED (hex 1B 0C); you can exit from TEK mode either when ESC-US (hex 1B 1F)
is sent by the host, or by pressing the Kermit escape key (CTRL-], by default).

4. Please send any comments/problems to:

          Brian Holley
          Faculty of Economics and Politics
          University of Cambridge
          [e-mail]-ICF

[Ed. - Thanks, Alan, for passing this along, and thanks to Brian for
contributing his work.  The .BOO file only, along with this message (no
source) is available in Kermit distribution as MSTIBT.*.  Some alternate
versions of Tektronix emulation may also appear for IBM PC Kermit, and there
is some reason to hope that one of these may be incorporated into the next
real release, 2.30, although if new code keeps showing up at the present rate,
the next release may never see the light of day...]

------------------------------

Date: Thu, 21 May 87 16:53 EDT
From: [e-mail]
Subject: QK-Kermit Answers
Keywords: QK-Kermit

In response to the item about QK-Kermit in Info-Kermit V6 #11, all the problems
you mentioned are related to the use of the Graphic ToolBox and the use of
overlays.  I have a new version of Qk-kermit which eliminates the use of the
Graphic Toolbox and overlays.

I will send this version off to Columbia as soon as I make sure that the CP/M
code will be compatable with the MS-DOS code.

                                   Victor Lee (613)-545-2033

[Ed. - Thanks Victor!  We will include it as soon as Columbia receives it.]

------------------------------

Date: Wed 1 Apr 87 12:23:47-EST
From: D. M. Rosenblum <[e-mail]>
Subject: Macros for VAX/VMS EDT in MS-Kermit 2.28
Keywords: VAX/VMS EDT, MS-DOS Kermit

I finally wrote up some macros that let me get at VAX/VMS EDT in MS-DOS
Kermit 2.28 for the IBM-PC.  (They may be totally inappropriate for other
keyboards.)  Like actual Zenith-19 terminals, these emulate the EDT keys by
position, rather than by name.  (I realize that 2.29 is doing VT100-family
support, but CMU isn't yet using 2.29, and I presume a lot of folks out
there still use 2.28 or earlier versions.)  To use them, go into EDT change
mode, escape back to KERMIT, issue a DO SETEDT command, and connect back to
the VAX; then when you're done, after you exit EDT, escape back to KERMIT,
issue a DO CLEAREDT command, and connect back to the VAX.  The documentation
of which keys do what is in the command file (at the end of this message).

By the way, the point that I made some time back about the kind of emulation
that I'd like to see is that I'd like to have MS-Kermit, if it's doing
Zenith-19 emulation, automatically do the user-defined macro SETEDT when it
receives an ESC = sequence from the host, and do the user-defined macro
CLEAREDT when it receives an ESC > from the host.  (Of course, the names of
the macros don't have to be SETEDT and CLEAREDT, but the idea is that the
user should be able to define key settings to be invoked and revoked
respectively on receipt of ESC = and ESC >.)  I believe that the VT100 uses
those same old VT52 escape sequences to get the alternate and normal keypad
(these are apparently different from the ANSI standards, which, according to
another source, are allegedly ESC [ > 7 h to go into alternate keypad mode
and ESC [ > 7 l to go back to normal keypad mode).

[Ed. - Yes, may people have requested such macro definitions.  They have
been put into a file called KER:MSIEDT.INI.]

------------------------------

Date: Thu, 21 May 87 22:54:49 EDT
From: [e-mail] (Gadi )
Subject: Apple II Kermit Answers
Keywords: Apple II Kermit

[Ed. - This is in response to the "Apple ][ Kermit Comments" in V6#11
from Martin J Carter.]

You'll probably get lots of replies, but..  Your problem (1), in which the
name gets mangled, is caused by the lack of a lower case display chip in your
apple.  Without one, all lower case characters are displayed as symbols.  If
you want to still use this kermit, (the newer one is MUCH better).  You should
make sure your file names are upper case.

       Gadi
ARPA:  [e-mail]
UUCP:  {harvard, seismo, ut-sally, sri-iu}!rutgers!friedman
CMS:   RUTGERS!SYSOP (CMS is DOWN. Long live CMS)

------------------------------

Date: Mon, 25 May 87  11:53:50 EDT
From: "Roger Fajman" <RAF@NIHCU>
Subject: Sending BREAK from Toshiba Lap Tops
Keywords: Toshiba, MS-DOS Kermit

> I ported MSKERMIT to my Toshiba 3100, but BREAK does not seem to work.
> Does anybody have any experience with this problem?  I am using the Toshiba
> internal modem.

The Toshiba internal modem for the Toshiba 1100+ and 3100 does not transmit
break signals.  Toshiba says that, yes, it works that way.  A company called
Megahertz makes an internal modem for the 1100+ and 3100 called the T1200
that does send break signals.  I have tried it for a short time and found no
problems.  We just purchased an 1100+ with a T1200 modem, but the modem was
backordered.  After it arrives, I will be able to say more.  Inability to
send a break signal seems to be a fairly common problem among the cheap 1200
bps modems.  I have encountered it several times before.

The address for Megahertz is

     Megahertz Corporation
     2681 Parley's Way, Bldg. 2-102
     Salt Lake City, Utah 84109

     Telephone: 800-33-TURBO
                801-485-8857

I believe that the list price for the T1200 is $400.

[Ed. - In general, Kermit does not work with internal modems unless the
modem mimics the serial port exactly, or there is explicit code in the
Kermit source which knows about that particular internal modem.  MS-DOS
Kermit 2.29B reportedly does work with Hayes and Hayes compatible full and
half-card internal modems, however.]

------------------------------

Date: 26 May 87 19:38:11 GMT
From: gatech!mcdchg![e-mail] (Ron Heiby)
Subject: UNIX V.3 & Kermit
Keywords: C-Kermit

Russell Nelson <[e-mail]> says:
> Have you heard anything about using kermit with Unix V.3?  AT&T has a new
> terminal driver (uugetty) for modem lines that does not work well with
> kermit.
>
> I've finally got 'cu' working.  kermit dies because uucp owns the port.

It isn't the driver that's new.  The program "uugetty" is a replacement for
"/etc/getty" that has knowledge of the same lock files that cu and uucp use.
Use of "uugetty" allows a port to be used as either incoming or outgoing on
demand, without administrator intervention.

One solution to Russell's problem is not to use "uugetty" on the line(s)
he wants to use kermit with.  On a system with very few modems this is
pretty limiting.  When I brought kermit up on my SVR3 system, I made the
kermit program suid to uucp.  This allowed it to manipulate the lock files
and the port just fine.  It seems, though, that kermit doesn't really expect
to be running suid, so this "solution" just creates a fairly large security
hole.  (I turned off the suid bit when I found out.)  As I mentioned in a
note a couple of weeks ago, the make target for "att3bx" is only used for
the HDB lock file protocol.  Since uugetty is only available with HDB (as
far as I know), perhaps the same target and #define could be used to insert
code to deal with kermit running suid.  My guess is that all that is needed
is a "setuid(getuid());" after the lock is created and port opened
successfully.  Probably belongs shortly after the call to ttlock() in ttopen().
I haven't completely tested it, but this seems to work ok on my system.  I
also had to comment out the call to access() that checks to see if the lock
directory is writable, as access() uses the real uid of the caller instead
of the effective uid, which is what we want.  We then depend on the actual
creat of the lock file's return code to indicate a problem.

These changes might not be a bad idea for all UNIX versions of kermit.

Ron Heiby, [e-mail]    Moderator: comp.newprod & comp.unix
"Small though it is, the human brain can be quite effective when used properly"

[Ed. - Thanks for the info.  We'll try to do something about this in the
next release of Unix Kermit.]

------------------------------

Date: Mon, 18 May 87 15:52:37 edt
From: [e-mail]
Subject: IBM PC Kermit 2.29b Screen Color Bug
Keywords: MS-DOS Kermit

    If you set the color with the mskermit.ini to bright white on blue
(set term 1, 37, 44), the color will change during certain full screen
applications.  We first discovered this with the 4BSD program more.  The
color is fine until you press the space bar for the next segment of text,
then the text changes to dull white or grey on blue.  We have an office
automation program called Office Power that causes the same color change.

Further information: We have reproduced these results on IBM ATs, Compaq
286s and Z-248s with various brands of EGA cards and monitors.  If you press
the ESC-chr and then c and then another c, your color will be reset.

[Ed. - From JRD: [e-mail] (no real name) today commented that
telling Kermit to use a Connect mode screen of bright white on blue (Set Term
Color 1 37 44) later resulted in ordinary white on blue as an application ran
on the host machine. This is correct since the host machine is sending a
command to set the screen that way. An escape sequence of ESC [ 0 m meaning
reset all video attributes does this. The difficulty regarding Kermit is that,
first it is running on systems which designate ordinary white to be a poor
light grey (yes, on my AT+ega+Multisync system too), and second the bold
colors still need to be under control of the host for other emphasis.]

------------------------------

Date: Thu, 21 May 87 14:46:42 MEZ
From: [e-mail]
Subject: Handshake Bug in MS Kermit 2.29
Keywords: MS-DOS Kermit

I think I have found a bug in MSDOS-Kermit version 2.29 for IBM-PC.  Our
configuration is an IBM PC/AT-02 connected via interface to an IBM /370 with
VM/SP Rel.4.

Using CMS-Kermit version 2.1 in the server mode everything was allright
except the GET command failed. But talking to the CMS-Kermit 3.1 server
mostly each command ended in the message 'Invalid server command'. Only the
REMOTE commands worked correctly. An observation with a linemonitor pointed
out that MSDOS-Kermit sends a NUL byte at the beginning of a packet.
Actually at the GET command it was the second packet which had a leading NUL
byte.  Version 2.28 has not this bug ( but it is not as comfortable as 2.29).

Because I'm not a great programmer in MASM I added a condition to the outchr
routine in module msxibm, which skips if the character is a NUL.
Unfortunately now it is impossible to set padding char NUL.

Of course this isn't a satisfactory way and I hope that you can give me a
better solution to this problem.

Thank's in advance for you efforts
          Matthias Brocks

[Ed. - This is a known bug of MS-DOS Kermit 2.29.  The latest release
(2.29B) fixes the problem.  It's in MSTIBM.BOO in the Kermit distribution.]

------------------------------

Date: Fri 22 May 1987 09:08:05 EDT
From: <[e-mail]>
Subject: Inconsistent Length of BREAK in MS-Kermit
Keywords: MS-DOS Kermit

I had problems with the break character on my COMPAQ 386 using MSKERMIT.
MSKERMIT for the IBM-PC and compatables uses an instruction loop to time the
length of a break character (based on the timing of a 4.77Mhz 8088) and the
faster the machine the shorter the break.  I patched the assemly program to
calebrate the break on startup correctly.

   Hope this helps with your problem.

[Ed. - The next release will generate BREAKs of constant duration,
independent of the CPU clock speed.]

------------------------------

Date: Thu, 21 May 87 11:59:41 EDT
From: uwvax!seismo!wucs1!wuphys!hpuslma![e-mail]
Subject: Patches for HP-150 Kermit Problems
Keywords: HP Kermit

I contacted Bill MacAllister who had mentioned a fix for 8-bit transfers
using kermit on an hp150 in msvhp1.bwr.  The following is a dif of my
msxhp1.asm file after making the changes from a listing he sent me.  I have
tried it as a local kermit and it seems to work.  I haven't tried it with
the hp150 working as a remote kermit or as server.

[Ed. - The patch has been added to the file KER:MSVHP1.BWR and forwarded
to Joe Doupnik for the next release.]

------------------------------

Date: Wed, 27 May 87 11:49:03 EDT
From: rmcqueen (Robert C McQueen) @ sitvxb
Subject: Kermit Has Made It To the Board Level
Keywords: Terminal Emulation

According to the May 18th Network World:

AST Research, Inc. recently unveiled a 2 port terminal emulation board.  The
board will do VT220 terminal emulation, and file transfer using the Xmodem
or Kermit protocols.  The article states the board has an 80186 on it and
128kb memory.  The board will handle 5 windows (2 VT220 sessions, a DOS
session and two notepads.).

Different.

Bob

------------------------------

Date: 20 May 87 15:24:38 GMT
From: [e-mail] (Mark Smith)
Subject: Does Perkin-Elmer Kermit Work?
Keywords: Perkin-Elmer Kermit

Hi!  Is there anyone out there that is successfully running Kermit in any
version on a Perkin-Elmer?  Has anyone ever heard of anyone running it
successfully on a Perkin-Elmer.  If so, please respond by E-mail to me or
call me at [phone] between 9am and 4:445 pm EDT.

Thanks.
mark

[Ed. - Reportedly, the Perkin-Elmer Kermit versions work.  Is there reason
to believe this is not the case?]

------------------------------

End of Info-Kermit Digest
*************************
-------
24-Jun-87 13:22:21-EDT,17514;000000000001
Mail-From: SY.CHRISTINE created at 24-Jun-87 13:21:37
Date: Wed 24 Jun 87 13:21:37-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V6 #13
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 24 Jun 1987       Volume 6 : Number 13

Today's Topics:

                       Kermit Paper Newsletter V1 #2
                  QK-KERMIT Version 2.7 Tek4010 Emulation
                  New Commodore Kermit (version 2.0) files
                         DECmate CP/M Kermit fixes
                        F11 & 12 on new AT keyboards
                       Announcing MS-DOS Kermit 2.29C
                         Bugs in Apollo Kermit 2.8
             Bug in Mac Kermit 0.8(034) Using 2-byte Checksums
                    Kermit with Tek emulation (MSTIBT.*)
                   Missing files for Apple II UCSD Kermit?
                            Apple 2e/CPM/Kermit?
                            Kermit for HPUX 5.1?
                         Unix Kermit in Background?
                                HP-150 Kermit?

----------------------------------------------------------------------

Date: Mon 15 Jun 87 12:21:33-EDT
From: Christine M Gianone <[e-mail]>
Subject: Kermit Paper Newsletter V1 #2
Keywords: Kermit Paper Newsletter

The Kermit Distribution group at Columbia University Center for Computing
Activities are in the process of preparing V1 #2 of the Kermit Newsletter
(V1 #1 appeared last July).  In addition to giving the non-network-connected
world news about the latest Kermit versions, we'd also like to publish some
articles from Kermit users all over the world who are putting Kermit to good
(and possibly interesting or unusual) uses.  We would be especially
interested in stories about how Kermit is used to somehow benefit humanity
(or other creatures), or to foster international cooperation, to make life
easier for the disabled, etc etc.  For many, Kermit is used for mundane
purposes like saving money.  We'd like to hear about that too.  Although we
distribute Kermit programs to thousands of sites, and probably millions of
users, we get very little feedback on how Kermit is actually used.  We'd
like to get this kind of news in any form, at any time, but if you'd like to
see it published in the Kermit Newsletter, please send it soon, and keep the
article fairly short (say 100-500 words).

Also, if anyone has any semi-technical general-interest contributions to make,
e.g. using Kermit over LANs, or through public networks, etc, these would also
be most welcome.

Whether you wish to contribute or not, you can be added to the subscriber
list by sending your mailing address to Info-Kermit@CU20B, or to Kermit
Newsletter, Columbia University, 612 West 115th Street, New York, NY 10025
USA.  This process won't be necessary if you received the first issue, or if
you've ever ordered Kermit material from us by mail, in which cases you're
already on the list.

------------------------------

Date: Thu, 11 Jun 87 11:29 EDT
From: [e-mail]
Subject: QK-KERMIT Version 2.7 Tek4010 Emulation
Keywords: QK-Kermit

An updated version of QK-KERMIT v2.7 which provides tek4010 emulation is now
available.  This version does not require the use of Turbo Graphic toolbox and
it does not require overlays.  Most of the problems, questions and difficulty
in using QK-kermit 2.6 were related to the toolbox and overlays, so this should
mean v2.7 should be a much easier simpler version to implement and use.  Only
the CGA version is ready.  Hercules and EGA versions will be coming later.

                        Victor Lee
                        (613)-545-2033
                        bitnet :  VIC@QUCDN

[Ed. - Thanks, Victor!  The new release is in KER:QK*.* on CU20B, available
with anonymous FTP, and on CUVMA as QK* * for BITNET KERMSRV access.  The new
release includes IBM PC and Kaypro II support, Apple II support will come
a bit later.]

------------------------------

Date: Fri, 12 Jun 87 23:31:14 EST
From: "Ray Moody" <[e-mail]>
Subject: New Commodore Kermit (version 2.0) files
Keywords: Commodore Kermit

    Two new files have been submited to CU20B for distribution.

    C64V2.HEX is the hex file that everyone has been waiting for!  It can
be de-hexed with C64DXL, which is the same program that de-hexes Kermit1.7.
Instructions are available in section 4.3 of C64KER.DOC.

    C64V2.INI is a basic program that can be run to create a kermit.ini file
that will work with Kermit version 2.0.  Most version 1.7 init files will work
with kermit V2, however, there are some that will not.

    As always, I welcome suggestions for improvements and bug reports.

                    Ray Moody
                     ihnp4!pur-ee!j.cc.purdue.edu!aij
                     [e-mail]
                     [e-mail]

[Ed. - Thanks Ray!  These files have been put in KER:C64V2.HEX and
KER:C64V2.INI available using FTP to CU20B, user ANONYMOUS (any password) or
through BITNET using KERMSRV.  This message is in KER:C64V2.HLP.]

------------------------------

Date: 16 Jun 87 15:43:21
From: Charles J. Lasner (OC.LASNER@CU20B)
Subject: DECmate CP/M Kermit fixes
Keywords: DECmate Kermit

The latest version of KERMIT-80 for the DECMATE II, III, III-PLUS version of
CP/M-80 (version 4.05) will not properly work when attempting a connection
between the DECMATE and a remote half-duplex KERMIT such as CMS-KERMIT.

This is due to the default action of the 6120 processor within the DECMATE
which does all i/o for the Z80. All occurrences of XON/XOFF (aka <^S>/<^Q>
or DC1/DC3) are eaten by the 6120 for flow control purposes which is
normally not a problem.

When connected to a half-duplex KERMIT such as CMS-KERMIT, the XON (<^Q>)
character is used to formally turn around the line.  Since the 6120 absorbs
all such characters, KERMIT-80 hangs when attempting this (retrying with
<CR> will actually work slowly!).

a/o this writing, this problem also exists with DECMATE II MS-DOS KERMIT, so
a work-around is imperative.

A partial fix is available in the files: CP4DMF.ASM, .HEX, and CP4DMU.ASM,
.HEX.  Each program comes with a short help (.HLP) file to explain its
operation.

[Ed. - Thanks, Charles!  The new files are installed in KER:CP4DMF.*
and KER:CP4DMU.* on CU20B for anonymous FTP access, and also on CUVMA
for BITNET KERMSRV access (as CP4DMF * and CP4DMU *).]

------------------------------

Date: Thu 18 Jun 1987 18:43:27 CDT
From: Mark S. Zinzow <Markz@Uiucvmd>
Subject: F11 & 12 on new AT keyboards
Keywords: MS-DOS Kermit

The program to activate scan codes in the Info-IBMPC Digest V6#45 works fine
with MS-Kermit 2.29B in allowing the definition of function keys F11 and
F12.  If you don't already subscribe to I-IBMPC on our listserv, you can
find the digest on LISTSERV 193 in the file I-IBMPC 87-00052.  The digest
entry is self explanatory, but for those who find downloading easier than
debug or MASM, I've put F11F12.COM on our kermit disk in binary form.

I would suggest executing F11F12 in your AUTOEXEC.BAT file so that it's
always installed when you wish to run kermit.
Then all you need to do is modify your 7171KEYS.DEF file.  Here is an
example that I've tacked on the end of mine (7171ADD F11 on the kermit disk):
;
; Additional definitions for use with F11F12.COM
; PF11 assigned to F11
set key scan 133
\033-
; PF12 assigned to F12
set key scan 134
\033=
; PF21 assigned to shift F11
set key scan 647
\033o
; PF22 assigned to shift F12
set key scan 648
\033p

Some of you may prefer to redefine all the shift codes to PF13-PF24, but
I prefer to remain consistent with the 10 key definitions.

[Ed. - Thanks!  The Kermit key definition mechanism will change in the
forthcoming release (2.30 -- see next message), but the mechanism for
activating the F11 and F12 keys may still be useful.]

------------------------------

Date: Mon 15 Jun 87 12:21:33-EDT
From: Christine M Gianone <[e-mail]>
Subject: Announcing MS-DOS Kermit 2.29C
Keywords: MS-DOS Kermit 2.29C

MS-DOS Kermit 2.29C is now available for testing on the IBM PC, Zenith
100/200, the NEC APC III, HP-150, HP-110 and Portable Plus (untested), and
Grid Compass (also untested).  A generic version is also available.  The
.BOO files are in KER:MST*.BOO and descriptions of the updates can be found
in MSR29C.UPD.  The sources are not yet available because they are still
undergoing last-minute revisions.  Thanks to Joe Doupnik of Utah State
University for all his time and effort.  Please test this version on your
system and report the results, so that we might be able to announce MS-DOS
2.30 soon.

------------------------------

Date: 8-JUN-1987 14:20:28
From:  [e-mail]
Via: [e-mail]
Subject: Bugs in Apollo Kermit 2.8

Two problems/bugs that I have come across with apollo kermit 2.8 First, the
apollo seems to store ascii files with just a newline between records, and
apollo kermit 2.8 does not map newline into CR LF when sending files.
However it does the correct translation when receiving files.  Second,
apollo kermit 2.8 does not correctly implement 8 bit prefixing.  If the
other system says that it cannot 8 bit prefix it puts an N in the packet in
place of the 8 bit prefix character requested by apollo 2.8 This is wrongly
interpreted by apollo kermit as a request to use the N character as the
prefix character with the result that all N characters in the file become
Control-N at the destination file.

Tim Lee Pafec Ltd, Strelley Hall, Strelley, Nottingham
phone [phone] ext 556

[Ed. - Thanks for the report.  It's been added to the "beware file" for
Apollo Kermit.  Any volunteers to fix and test it?]

------------------------------

Date: 10-JUN-1987 17:35:59
From: [e-mail]
Subject: Bug in Mac Kermit 0.8(034) Using 2-byte Checksums
Keywords: MacKermit

I have found a problem using Macintosh Kermit with two byte checksums when the
data packet can have bytes with the eighth bit set. The resulting checksum is
consistent with such bytes being negative in the range -128 to -1, i.e. bytes
are treated as signed -128..127 rather than unsigned 0..255. The Kermit book
makes it clear (c.f. page 224) that the latter is correct.

The workaround is easy - don't use two byte checksums for binary files.

Regards,
David.

[Ed. - Thanks for the report, which we've added to the Mac Kermit "beware
file."  The problem will be looked at in the next release of C-Kermit.]

------------------------------

Date: Thu, 11 Jun 87  14:09 EDT
From: Walter Bourne <WMBSC@CUVMA>
Subject: Kermit with Tek emulation (MSTIBT.*)
Keywords: Tek Emulation

I have run into two problems with the Tek emulation.  The first is that it
displays certain characters meant as padding.  SAS/Graph, for instance,
sends a string of ^V's (hex 16) after the clear command.  These appear as
small blocks half the normal character height across the top of the page.
The bell SAS rings at the end of the plot is also displayed as a triangle
pointing right.  There are sometimes what looks like part of a Tek vector
command printed in the upper left after the bell.

The second problem is that it loses some data when filling large areas
solidly at higher baud rates (over 1800).  SAS, running on an IBM CMS
system, apparently uses no handshaking and the close spacing of the vectors
doesn't allow the program to catch up during the move portion of the
command????

  Walter Bourne,
  Ass't Director
  Center for the Social Sciences
  420 West 118 St., Rm 814 SIA
  New York, NY   10027
  Tel: [phone]

[Ed. - Thanks for the report, Walter.  It's been forwarded to the developers
and added to the (previously nonexistent) MSTIBT.BWR file.]

------------------------------

Date: 17-JUN-1987 11:23:37
From: [e-mail]
Subject: Missing files for Apple II UCSD Kermit?
Keywords: Apple II Kermit

We need a version of UCSD Kermit on an Apple II for getting some files off an
Apple II onto a PC Clone. I've downloaded the sources, but can't track down a
copy of SYSTEM.ATTACH and ATTACHUD.  Do you have these, or does anyone know
where they can be obtained?

Chris Murphy
Computer Centre
Oxford Polytechnic

[Ed. - Any users of UCSD Pascal Kermit on the Apple II out there who can help?]

------------------------------

Date: 15 Jun 87 19:48:08 GMT
From: [e-mail] (A. Dain Samples)
Subject: Apple 2e/CPM/Kermit?
Keywords: Apple II Kermit

I am having trouble getting kermit running.  Any help would be appreciated.
My hardware configuration is
    * Officially enhanced Apple 2e
    * PCPI ``Starcard'' (Applicard) with Z80B
    * Hayes Smartmodems (I have access to the 1200 and the 2400)
    * SuperSerial Card

I got kermit off the simtel20 PD archives PD:<CPM.MODEM>CP405HEX.ARK (thanks
much to those who spend their time [and money?] keeping these archives
open!).  Using the accompanying instructions I configured kermit for the
``generic'' CP/M system using the IOBYTE.  Much to my surprise, it was able
to talk to the modem on the first try!  (Magic is always surprising.)  Much
to my disappointment, characters are being dropped.  I cannot seem to get
the Hayes modem into its ``monitor'' mode to set registers, autodial, etc.,
and not every character I type at the keyboard is being echoed, and not
every character I type make the geblinken lights on the modem light up.  It
looks like some sort of handshake or speed problem between the PCPI system
software and the SSC.  At first I thought the Hayes and the Super Serial
Card were trying to talk at different baud rates, but a lot of messing
around and writing test programs convinced me this is not what is happening.
E.g., the SSC and the modem work fine under SmartTerm, but then they don't
under kermit.  I thought maybe the Hayes Smartmodem 2400 was not being
initialized properly under kermit, so I tried the Hayes 1200 under kermit,
and it experiences the same problem.

I want to use kermit under CP/M since SmarTerm requires a re-boot and wipes
out my AE RamWorks ramdisk.

Any help would be much appreciated!  What am I missing?  Is there a Kermit
configuration overlay specifically for my configuration?

Mail to [e-mail].  If there is sufficient interest, I will post
a summary.

Thanks in advance,
Dain

A. Dain Samples, 573 Evans, UC Berkeley, [e-mail]
(All opinions expressed herein are mine, and do not reflect the opinions of
anyone that does not want them to.)

------------------------------

Date: 15 Jun 87 19:09:02 GMT
From: rochester!steinmetz!ebstokes@vdsvax..arpa (Stokes Edward B)
Subject: Kermit for HPUX 5.1?
Keywords: HPUX, Kermit

We have an HP 9836 (Series 200) microcomputer which is running HPUX 5.1
(hp's flavor of unix, basically system V). We would like to have a cheap
reliable interface to an Ultrix VAX via an existing RS232 line. CU works OK,
but doesn't do even the most simplistic checking of files that are
transferred.  Does anyone have any experience with HPUX Kermit ? It does not
have the familiar "server" mode which is available in most versions,
consequently we've not had much luck making it work. Thanks in advance. Ed
Stokes

[e-mail]

[Ed. - Regular C-Kermit 4D(061) is said to work under HP-UX if you build it
with the "sys5" option.  However, it lacks support for some of the HP 9836
specific features, some of which may appear in the next release.]

------------------------------

Date: Wed, 17 Jun 87 11:40:38 PDT
From: [e-mail] (Danielle Bercel, MIS Systems Programming)
Subject: Unix Kermit in Background?
Keywords: C-Kermit

Is anyone aware how to run Unix Kermit in the background? The version we
have here seems to want tty access and even though the commands are coming
from a script we cannot run it in the background.

Any suggestions?

danielle
UUCP:  {hplabs,decvax,}!sun!toto!{danielle,dbercel}
COM:   [e-mail]
ARPA:  [e-mail]

[Ed. - The -q option, given on the command line, is intended to "quiesce" the
tty and allow the program to run in the background, when invoked with a "&"
on the end of the command line.]

------------------------------

Date: Wed, 17 Jun 87 14:10 EST
From: Mark B. Johnson
Subject: HP-150 Kermit?
Keywords: HP-150 Kermit

Could anyone be so kind as to send us the HP 150 version of MS-Kermit on
diskette?  We cannot transfer anything to the one here on campus due to an
outdated BASIC.  We would be ever so grateful ...

Mark Johnson
Univ. of Notre Dame

[Ed. - This is a popular request.  Does anyone know of an HP User Group that
we could submit a Kermit diskette to for distribution.  In the near future,
there is a possibility that Kermit Distribution at Columbia will be able
to provide this service, but until then...... ??]

------------------------------

End of Info-Kermit Digest
*************************
-------
14-Jul-87 16:21:16-EDT,23547;000000000000
Mail-From: SY.CHRISTINE created at 14-Jul-87 16:19:31
Date: Tue 14 Jul 87 16:19:31-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V6 #14
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 14 Jul 1987       Volume 6 : Number 14

Today's Topics:

               Patched up MSTIBM.BOO (beta test) for testing
                  Update to Tek emulator for IBM PC Kermit
                    Announcing Kermit for Tripos systems
                  Announcing a New Acorn Version of Kermit
                Announcing ICL 2900 VME Kermit Version 1.01
            Announcing Kermit for the Harris H100-1 Running VOS
                    Announcing Kermit for the TI990 DX10
             Kermit and the Toshiba 3100 Internal modem (2 messages)
                             Kermit for Mac II
                          MAC II and mailing list
                           Kermit on the MAC SE?
                         Unix Kermit in Background
                Getting the files SYSTEM.ATTACH and ATTACHUD
                          Kermit for the RTE-6 OS?
                 Files Needed for the DG Nova Running RDOS?
                         Man page for BSD C-Kermit?
                        Vax to IBM 370 File Transfer
                        Help with C-Kermit on Cyber
                      C-Kermit Problem on a SUN 3/160

----------------------------------------------------------------------

Date: 28 JUN 87 17:31-MST
From: JRD@USU
Subject: Patched up MSTIBM.BOO (beta test) for testing
Keywords: MS-DOS Kermit

Following this note is the latest MSTIBM.BOO file which has fixes for
problems known to date and the added items: CTTY support, version banner on
file transfer display, errorlevel returns, auto-cleanup of Macros, retention
of full file statistics for last send, and Set Term Roll On | Off (default
is Off).  Ident is 2.29C dated 27 June 1987.

Cured reported problems: Set Key in a Macro echos its status lines;
backspacing at the Set Key definition prompt crashed the system.

One cannot use the regular numeric keypad as a general dispatch area for
umpteen functions per key, just three per key is the limit. Suggest using the
Function keys for this purpose; they are designed to support four per key.
The Num Lock key does what it should, sets numeric mode; Shift can be added
on top to get a third function per key. Control-Break key combination is now
predefined to send a BREAK out the comms port, so does Alt-B.

When Kermit Pushes to DOS from within Connect mode Kermit sends a flow-off
character (XOFF), if flow control is active, to suspend the remote host and
later a flow-on (XON) character when resuming Connect mode.  It does not do
this if the Push occurs at the Kermit prompt level since sending a stray
character at that time might wakeup a remote host or communications black
box when we were doing only local work.

        Regards,
        Joe D.

[Ed. - Thanks Joe!  Those of you who are testing the new Kermit on IBM PCs
and compatibles (including PS/2s) are encouraged to grab the new version from
KER:MSTIBM.BOO on CU20B and try it out.  The bug-reporting period will soon
be over.]

------------------------------

Date: 18-JUN-1987 09:47:32
From: [e-mail]
Subject: Update to Tek Emulator for IBM PC Kermit
Keywords: Tek Emulation, MS-DOS Kermit

  Brian Holley has expanded his Tek emulator version of MS-Kermit 2.29 to
use CGA/EGA and Hercules cards, and also to run on Olivetti (M24??). The
files are KER:MSTIBT.BWR and KER:MSTIBT.BOO.  This update to the BOO file
should cure the problem Walter Bourne reported in Info-Digest 13.

The latest version of the TEKtronix 4010 emulator for MSKERMIT has the
following facilities:

1. Support for: CGA, EGA, Hercules, Olivetti

2. To switch from one of the graphics facilities to another, use the command:
   SET TERMINAL GRAPHICS xxx
   where xxx can be one of CGA, EGA, Hercules, Olivetti

3. The line drawing algorithm writes direct to screen memory and is therefore
much faster than in the previous version; it will, however, almost certainly
cause problems under Topview, Windows or other windowing systems.

Please note:

4.The TEK emulation is not complete:
    (a) characters are all based on an 8 by 8 matrix, giving 80 characters
        across the screen (90 for Hercules), and 25 lines (CGA), 43 lines (EGA
        and Hercules), or 50 lines (Olivetti). (A 4010 has 74 by 32)

    (b) there is no MARGIN 1.

All vectors should, however, be correctly positioned in relation to one
another, though the aspect ratio may not be perfect. In addition, a cross-hair
facility is provided. Use arrow keys to move the cross-hairs, and SHIFT-arrow
for faster movement.

5. TEK mode is entered from VT or other mode upon receipt of the sequence ESC
   FormFEED (hex 1B 0C); you can exit from TEK mode either when ESC-US (hex 1B
   1F) is sent by the host, or by pressing the Kermit escape key (CTRL-], by
   default).

6. Please send any comments/problems to:
          Brian Holley
          Faculty of Economics and Politics
          University of Cambridge  CB3 9DD

          [e-mail]

[Ed. - Thanks, Alan!  The new file is in KER:MSTIBT.BOO.  Remember, this is
still "vanilla" 2.29, with Tek emulation added.  Tek emulation probably will
not make it into 2.30, but here's something that can be used (at least on
IBM PCs with CGAs) till then.]

------------------------------

Date: 29-JUN-1987 10:14:55
From: [e-mail]
Subject: Announcing Kermit for Tripos systems
Keywords: Tripos Kermit

Here's a version of Kermit to run under the Tripos operating system (a high
portability system devised at Cambridge University, England, that has
appeared on various machines and is the basis of Amigados.). This version,
written by C.G.Selwyn of Metacomco Ltd, is in BCPL, based on the old C
Kermit from the Protocol Manual. There's no documentation for it,
unfortunately.

[Ed. - Thanks Alan.  The source code can be found in KER:TRIPOS.* available
by FTP to CU20B, user ANONYMOUS (any password) or through BITNET using
KERMSRV.]

------------------------------

Date: 29-JUN-1987 10:14:55
From: [e-mail]
Subject: Announcing a New Acorn Version of Kermit
Keywords: Acorn Kermit, C-Kermit

This is the Kermit for the Acorn Cambridge Workstation, contributed by Acorn
Computers Ltd.

Users of this Kermit might like to know that it is available on disc from
Acorn at a cost of #50 to cover media and handling.

C-Kermit is a completely new implementation of Kermit, written modularly and
transportably in C. The protocol state transition table is written in wart,
a (non-proprietary) lex-like preprocessor for C. System-dependent primitive
functions are isolated into separately compiled modules so that the
program should be easily portable among Unix systems and also to non-Unix
systems that have C compilers.  This document applies to Unix
implementations of C-Kermit, and in most ways also to the VMS
implementation.

[Ed. - Thanks for submitting this version Alan.  The files are in KER:AC*.*.]

------------------------------

Date: 29-JUN-1987 10:14:55
From: [e-mail]
Subject: Announcing ICL 2900 VME Kermit Version 1.01
Keywords: VME Kermit

SWURCC VME Kermit Version 1.01

This version of VME Kermit is the standard version. If the communications
device for terminal connection to VME is an ASG, VME Kermit may not work.
This is because of a VME bug. Once this bug has been fixed the standard
version will run via ASG. If you find that VME Kermit will not run via ASG
please contact SWURCC for details of a modification to circumvent the bug.

                                                       David Lord (SWURCC)

[Ed. - Thanks David.  The files have replaced the old ones in KER:VME*.*.
The old files have been placed in KO:VME*.* for now.]

------------------------------

Date: Tue 30 Jun 87 11:24:29-EDT
From: Christine M Gianone <[e-mail]>
Subject: Announcing Kermit for the Harris H100-1 Running VOS
Keywords: H100 Kermit

This program was written using Harris Fortran 77 on a Harris H100-1
computer (VOS 4.1.1 operating system) by Skip Russell, Division of
Biostatistics, Washington University in St. Louis ([e-mail])

It was tested at up to 9600 baud against Columbia University's "MSKERMIT"
version 2.27 on an IBM PC/AT running DOS 3.0.

This version (1.04 April, 1987) added code to the first version to allow GETs
of file groups using the "?" wildcard character.  The program was came out of
a need to transfer files between the aging Harris 100 and an IBM PC.

Skip Russell wrote this program especially for Harris computers which are
configured with a "MUX" as opposed to the more recent CNP or DMACP I/O
processors, since the Pascal-based Harris Kermit which was already in
existence does not accommodate such a configuration.  As such, he has not
taken advantage of many of the special features offered by those devices
(notably timeouts and buffered I/O via "hot read"), but have opted instead
for simpler, albeit less efficient, modes of communication.  In any case,
this program should work properly on a Harris machine in any configuration.

The files are in KER:H100*.*.

------------------------------

Date: Tue 30 Jun 87 11:24:29-EDT
From: Christine M Gianone <[e-mail]>
Subject: Announcing Kermit for the TI990 DX10
Keywords: TI990 Kermit

This version (1.0) of Kermit for the Texas Instrument DX10 was written by
Paul W. Madaus, Johnson Controls, Inc., 507 E. Michigan St., Milwaukee, WI
53201.  His cover letter follows:

The Kermit source was originally designed to run on the Sperry(UNIVAC) 1100.
He has chosen to convert and implement this version of Kermit onto the
TI-990 DX10 systems.  The conversion of system specific procedures was
straightforward, the basic protocol of the UNIVAC version was written in
standard Pascal, and of all the versions tested for conversion, the UNIVAC
version produced an acceptable amount of errors upon initial DX10
compilation (not a deciding factor - but very influential).  Before
continuing further, he wishes to credit the original UNIVAC version (2.0) of
this program to:
                     Edgar Butt         (last known address)
                     Computer Science Center
                     University of Maryland
                     College Park, Maryland 20742

His method of re-design will consist of removal or conversion of all UNIVAC
system dependent software, addition of a command parsing mechanism, addition
of interactive command control, addition of several new Kermit commands,
addition of simple tty type terminal emulation via connect cmd, addition of
remote as well as local Kermit execution, and addition of a Pascal XOR
function for 7th and 8th bit setting and resetting.  This program makes use
of TI Pascal extensions but does not include any non-TI Pascal structures.
Program was compiled and linked at DX10 REL. 3.7.0 and DX10 Pascal REL.
1.8.0.  THE TI Pascal configuration process was not used only for greater
simplicity and easier portability.

[Ed. Thanks Paul.  The files have been placed in KER:TI9*.*]

------------------------------

Date: Tue, 30 Jun 87  11:19:39 EDT
From: "Roger Fajman" <RAF@NIHCU>
Subject: Kermit and the Toshiba 3100 Internal modem (more!)
Keywords: Toshiba 3100, Modems

I recently received the Megahertz T1200 internal modem for my Toshiba 1100+.
It seems to work fine with Kermit.

[Ed. - This is good news.  See message below.]

------------------------------

Date: Mon 29 Jun 87 17:05:48-EDT
From: Christopher P. Lent <[e-mail]>
Subject: Kermit and the Toshiba 3100 Internal modem (more!)
Keywords: Toshiba 3100, Modems

RE: "Roger Fajman" <RAF@NIHCU> message in a former Kermit digest.

Well, there are two work-arounds and a solution for the Toshiba 3100
internal modem:

First the solution:

Toshiba has come out with replacement for the internal modem which DOES send
a break.  A friend of mine got his replaced by Toshiba. Toshiba had him ship
his modem out and they sent a replacement.  I've tested the new internal
modem card and it DOES send a break with Kermit 2.29A and 2.29B.  It also
sends a break and a long break with Kermit-MS V2.29C (Development for 2.30)
7 Jun 87 .  Also the Kermit HANGUP function works fine.

I imagine Toshiba's replacement policy is a "if you call, we MAY tell you
about it" type deal, but I would guess the most effective route would be to
call Toshiba directly.

The part number on my friend's box is: PA7438E B (is B for Break ? :-)

The Work-Arounds:

One workaround (which I have not tested) might be to set the baud rate down
to 45.5 and send a null (via CTRL-] 0).  This should simulate a BREAK well
enough.

A second workaround is to get an external modem and use that.  The integral
serial port on the T3100 does send breaks and handle the modem signals
properly.

Hope this helps,
Chris Lent
cbosgd!philabs!phri!cooper!chris
[e-mail]

------------------------------

Date: Fri, 26 Jun 87 21:02:06 PDT
From: [e-mail] (Dwight Hare)
Subject: Kermit for Mac II
Keywords: MacKermit

My version of Kermit, 0.8(34), immediately bombs on my new Mac II.
Is there a version of Kermit which runs on the Mac II?

Dwight Hare
[e-mail]

[Ed. - Reportedly, MacKermit 0.8(34) works on the Mac II.  Comments?]

------------------------------

Date: Sun, 5 Jul 87 18:54:57 pdt
From: Alex Woo <[e-mail]>
Subject: MAC II
Keywords: Mac Kermit

I recently purchased a MAC II and discovered that the SUMEX version
of Kermit 0.8 failed to even startup.  Is there an updated version?

Thanks
Alex Woo, MS 227-2        |    [e-mail]
NASA Ames Research Center    |    [e-mail]
Moffett Field, CA 94035        |    {seismo,topaz,lll-crg,ucbvax}!
Phone: [phone]        |    ames!pioneer!woo

  {hplabs,hao,ihnp4,decwrl,allegra,tektronix,menlo70}!ames!pioneer!woo

[Ed. - We had earlier reports that Mac Kermit worked OK on the Mac II and
the Mac SE.  What could be the hidden factor that makes it work for one
person but not another?  Anyway, there will soon be a new release of Mac
Kermit that can be compiled directly on the Mac under Megamax C, so that
Macintosh wizards can start finding and fixing problems.  Watch Info-Kermit
for announcements.]

------------------------------

Date: Tue 30 Jun 87 11:24:29-EDT
From: Christine M Gianone <[e-mail]>
Subject: Kermit on the MAC SE?
Keywords: MacKermit, VAX/VMS Kermit

"rozycki%thebay.dec@decwrl" is trying to use MacKermit 0.8(34) on a MAC SE
to communicate with a VAX/VMS system running Kermit 3.3.111.  It is a direct
connection using a printer cable.  A connection can be made but file
transfer is not successful.  Various parity settings have been tried.  Has
anyone has a similar experience?

------------------------------

Date: Tue, 30 Jun 87 15:17:16 BST
From: Gordon Scott <seismo!mcvax!mfmail![e-mail]>
Subject: Unix Kermit in Background
Keywords: C-Kermit

In response to the query about running Unix Kermit in background
(Info-Kermit Digest V6 #13 ) there are a few other things to note as well as
using the -q flag.

-q appears to have no effect on some of the output from the script module
and to get round that one I generally just redirect the standard output.

Another point is that the documentation about errors in take files being
fatal in background is wrong for 4C(061), although it was correct in
4C(057).

It also took me a while to realise that protocol timeouts are not fatal to
the job in background - kermit will keep retrying for a while and then go on
to the next command.

Gordon Scott
Micro Focus Ltd
(mcvax!ukc!mfmail!gas)

[Ed. - Thanks for the comments; these problems should be fixed in the next
release of C-Kermit.]

------------------------------

Date: Sun, 28 Jun 87 22:32:00 pdt
From: hplabs!cae780!amdcad!ames!well![e-mail]
Subject: Files SYSTEM.ATTACH and ATTACHUD for Apple II UCSD p-System Kermit
Keywords: Apple II, UCSD p-System

In article <[e-mail]> Chris writes:
>SYSTEM.ATTACH and ATTACHUD.  Do you have these, or does anyone know
>where they can be obtained?
>
>Chris Murphy
>Computer Centre
>Oxford Polytechnic

    Both are available from the International Apple Corps in Daly City,
CA, USA -- and probably from his local Apple User Group in England . . .

Sam'l Bassett, Semantic Engineer -- My words & ideas are for sale!
34 Oakland Ave., San Anselmo  CA  94960;  [phone]
UUCP:  {...known world...}!hplabs OR ptsfa OR lll-crg!well!samlb;
Compuserve:  71735,1776;  WU Easylink ESL 6284-3034;  MCI SBassett

------------------------------

Date: 28 June 87 21:33-EST
From: MLCARSON@MTUS5
Subject: Kermit for the RTE-6 OS?
Keywords: RTE Kermit

  I'm looking for a version of Kermit that will work on the RTE-6 operating
system with a HP12966A interface using a DVA05 driver.  We have three such
interfaces: one for a HP2645A terminal, one for a HP2622A terminal, and one
that is shared by a PC and another HP terminal via 1200 baud modem.  I have
a version of Paul Schumann's Kermit but I believe it requires either a
12040B/C or 12792B/C multiplexer.  I can't even try this Kermit because its
on a 5.25" PC formatted disk.  I can't just upload it to the HP editor
because of the ENQ/ACK protocol that is taking place.  Is there anyway of
getting around this?  If there is a Kermit out there that works, how do I
get it on the HP?  Could you please help me with this problem or point me to
someone who could?  It would really be appreciated.  Thank you.

------------------------------

Date: 1-JUL-1987 10:23:05
From: [e-mail]
Subject: Files Needed for the DG Nova Running RDOS?
Keywords: DG Nova Kermit

It's been pointed out to us that the files for Kermit in Fortran-5 for DG
Nova machines running RDOS (prefix RDO) are incomplete. There are include
references to SETSETUP.FR and F5ERR.FR, and these files aren't in the set,
and what they may contain isn't obvious.

Does anyone know what's in the files, or has anyone got copies?

       Alan Phillips

[Ed. - These are probably DG files that come with DG Fortran.  Anyway, the
person who contributed the Fortran version of RDOS Kermit is long gone.
The forthcoming release of C-Kermit will support DG C environments; it has
been tested on AOS/VS, but not RDOS, however the C environment is supposed
to be consistent across all the DG product lines.]

------------------------------

Date: 6 Jul 87 18:29:01 GMT
From: hao!boulder!sigi![e-mail] (Tinsley A. Galyean)
Subject: Man page for BSD C-Kermit?
Keywords: C-Kermit

I am looking for a man page for the latest version of C-Kermit BSD.

C-Kermit, 4D(061) 8 Sep 86, 4.2 BSD

The source I have did not have a man page with it.  If you have one that you
wrote yourself or otherwise found would you please mail me a copy.

Thank You

    tag

    [e-mail]    (CSNET or ARPANET)
    ...!{nbires,hao}!boulder!tag    (UUCP)

[Ed. - The man page, such as it is, is in KER:CKUKER.NR on CU20B, and comes
with C-Kermit in the normal distribution.]

------------------------------

Date: Wed, 08 Jul 87  11:16:58 EDT
From: "Bob Klein" <KL2@NIHCU>
Subject: Vax to IBM 370 File Transfer
Keywords: VAX/VMS Kermit, TSO Kermit

A user at our site is trying to transfer a file from a Vax (under VMS 4.5)
to our IBM 3090 running MVS using Vax Kermit 3.1.066.  He can set up the
connection but can't even get the transfer started.  I noticed in the
Info-Kermit Digest V6 #9 that there is a new release of VAX/VMS Kermit
(3.3.111) which contains bug fixes for among other things IBM mainframe
communications.  Does anyone have any experience doing file transfer between
a Vax and a 3090 (or other 370 model) running MVS.  The version of Kermit on
our mainframe is NIH TSO Kermit.  Thanks in advance for any pointers.

------------------------------

Date: 24 Jun 87 15:40:00 MST
From: <[e-mail]>
Subject: Help with C-Kermit on Cyber
Keywords: C-Kermit, Cyber

I am attempting to put CKUKER onto the CDC NOS VX/VE system.  This (hybrid)
system is supposed to be SVID compatible.  I can get the makefile to work
just fine with "make sys3" or "make sys3nid" as the instructions say.  When
I execute ("wermit"), the prompts seem to be missing carriage returns and/or
line feeds (e.g. the help ("?") directive produces a list which does not
line up, and seems to be going off the page 'til wraparound.)  This makes
output hard to read.

Even worse, the input seems to have a one-character buffer... typing
anything causes Kermie to interpret each character as if it were the full
command.  Trying "server" will get 6 errors, one for each letter which is
either an illegal command or not long enough for Kermit to distinguish which
particular command is being requested.  The only things which work are helps
("?", "h") and a few of the other commands uniquely determined by one letter
and requiring no other argument.

I am not a C or UNIX guru, but am learning at a regular pace.  I've tried
stabs in the dark by having ckutio use ICANON for tty and console lflag
values -- but I really don't know what's happening.  I fear that the strang
CYBER environ- ment of UNIX (called VX) sitting atop NOS/VE which is
dual-mode with NOS may be doing very strange things to I/O.  The local CDC
VX/VE expert is stumped.

HELP!  Anybody have a similar problem?

Declan A. Rieb
Sandia National Laboratories, Division 2614
Albuquerque NM

Phone: [phone]
[e-mail]

------------------------------

Date: 8-JUL-1987 10:05:25
From: V Paramananda (PS) <[e-mail]>
Via: [e-mail]
Subject: C-Kermit Problem on a SUN 3/160
Keywords: C-Kermit

We are having trouble with a version of C Kermit installed on a Sun 3/160
workstation within the Department of Photogrammetry and Surveying at UCL. It
appears impossible to get the system set up as a virtual terminal so that
that it can initiate transfers from other Kermits, in this case a VAX within
UCL. We can set up the line /dev/ttyb on thisd Sun without any apparent
problems. However, when the line is connected there is no response from
remote hosts at the other end of the line. It is unlikely that the hardware
is a fault, as the UNIX utility function 'tip' is able to establish
connections without problems.

Could you please reply to:

[e-mail]

Thankyou,

Mark O'Neill,
Dept of Photogrammetry and Surveying
UCL,
Gower Street,
Londow WC1E 6BT UK.
Tel: [phone]X2743

------------------------------

End of Info-Kermit Digest
*************************
-------
28-Jul-87 14:33:21-EDT,21024;000000000000
Mail-From: SY.CHRISTINE created at 28-Jul-87 14:32:07
Date: Tue 28 Jul 87 14:32:07-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V6 #15
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 28 Jul 1987       Volume 6 : Number 15

Today's Topics:

               Reorganization of Files on Kermit Tapes
        Announcing Kermit68K, a Portable 68000 Kermit Program
                       A New MSTRMX.* Available
          MacKermit 0.8(34) on the Macintosh II (4 messages)
              7171 MSKERMIT.INI for MS-DOS 2.29C Kermit
                     Problem with C-Kermit on SUN
                        Binary File Transfers
                Time Loop for Prompts in Script Files
                     MSKERMIT for the DEC Rainbow
                 Bootstrap version of Kermit-CMS 3.1
                    Portable Kermit for IBM 370's
                     VMS Kermit Buffering Problem

----------------------------------------------------------------------

Date: Mon 27 Jul 87 12:52:37-EDT
From: Frank da Cruz <[e-mail]>
Subject: Reorganization of Files on Kermit Tapes
Keywords: Kermit Tapes

Due to the recent influx of new Kermit versions, Kermit Distribution has grown
from 3 to 5 tapes.  Tape A still contains the more popular microcomputer (PC,
workstation) Kermit implementations; Tape B still contains the more popular
mini and mainframe Kermit implementations (IBM mainframes, C-Kermit, DEC OS's,
etc); Tape C contains additional micro versions (overflow from Tape A); Tape D
contains additional mini and mainframe versions (overflow from Tape B); and
Tape E contains machine readable copies and text formatter source for the
Kermit User Guide, Protocol Manual, and Byte Article and other large documents,
including old mail archives.  Apologies for any inconvenience this might cause
to tape customers.  Those who access Kermit files by network should notice no
difference.

------------------------------

Date: Sat, 18 Jul 87 12:26 N
From: <[e-mail]> (Roberto Bagnara)
Subject: Announcing Kermit68K, a Portable 68000 Kermit Program
Keywords: 68000, Motorola 68000, OS-9

I'm very pleased to announce that, after 1 year of work, the OS9/68000 version
of Kermit68K pre-release 1.0.00 is ready to be distributed.

Kermit68K/OS9 is an implementation of Kermit68K for microcomputer systems
running the OS-9/68000 operating system from Microware.  Kermit68K is patterned
after UNIX C-Kermit, however it is written completely in Motorola 68000
assembly language to allow easy portability to 68000 based systems without C
compilers.  The OS-9 system specific modifications were performed by Steve
Williams of the Electrical and Computer Engineering Department at the
University of Texas at Austin.

Kermit68K has been designed and written to be (among other things) portable.
This means that it can be implemented on any 68000 based machine with any
operating system (really also on machines without an operating system).
Furthermore (being highly modular, ROMable etc.) it is suitable for
nonstandard, specific applications (e.g. automatic data transmission from a
remote acquisition station to a database host computer).

I hope, by pre-releasing Kermit68K at this time, to involve experts of other
operating systems/machines.  People willing to try other implementations of
Kermit68K (for example under UniFLEX, PDOS, VERSADOS, CPM/68K etc.)  shouldn't
hesitate to contact me at any time.  The type and amount of work necessary is
deducible by reading the distribution file K6GSYS.ASM (the only system
dependent module).

Finally I want to remind the potential users of Kermit68K/OS9 that we, I and
Steve, need a strong feedback; there are many things to test and correct.
Furthermore I'm continuously upgrading the program and I should take many
decisions, so users suggestions will be very useful to me.  Please, feel free
to contact me at any time.  Cordially,

                 Roberto Bagnara

Ordinary Mail:        Roberto Bagnara
                      Physics Department
                      Bologna University
                      via Irnerio, 46
                      40126 BOLOGNA
                      Italy

Bitnet:               Bagnara@Iboinfn
DECnet:               39937::BAGNARA
Arpanet, Usenet:      [e-mail]

[Ed. - Many thanks Roberto!  The files are in KER:K6*.* avaialable via ARPAnet
by FTPing to CU20B, user ANONYMOUS (any password) or through BITNET using
KERMSRV.]

------------------------------

Date: Monday     July 27, 1987 12:57 PM PDT.
From:<[e-mail]>
Subject: A New MSTRMX.* Available
Keywords: MS-DOS RMX Kermit

This is to announce the test release of version 2.29C of Kermit for both the
RMX86 and RMX286 Operating Systems.  Relevant files are MSTRMX.BOO, for RMX86,
and MSTRX2.BOO, for RMX286, MSTRMX.DOC, and MSERMX.P86.

[Ed. - Thanks to [e-mail] for sending these
.BOO files.  The are in KER:MSTRMX.BOO and MSTRX2.BOO.  Please try them out
and send reports to Info-Kermit@CU20B.]

------------------------------

Date: Tue, 21 Jul 87  16:53 EDT
From: MLM@PITTVMS
Subject: MacKermit on the Macintosh II
Keywords: MacKermit

Is there a Kermit for the Macintosh II?  We have tried Macintosh Kermit
version .8(34) with the system crashing.

Mark Medice, Academic Computing, Univ. of Pittsburgh.

[Ed. - See messages below...]

------------------------------

Date: Thu, 23 Jul 87 13:22 EDT
From: <[e-mail]>
Subject: MAC II Kermit Problems.
Keywords: MacKermit

Does anyone have a version of Mac Kermit for the Mac II?  It seems that
the current version 0.8(34A) Oct/85 starts to load but then the standard
restart error message appears.

Also, is there a version of the program to define the new keyboard for the
Mac II?

Thanks in advance to anyone that posts an answer.

Luis Strauch
York University
Toronto, Canada

BITNET: LUIS@YULIBRA

[Ed. - See messages below...]

------------------------------

Date: 15 Jul 87 01:37:24 GMT
From: [e-mail] (Joel West)
Subject: Kermit & Mac II (V6 #14)
Keywords: MacKermit

The only thing that obviously affects one Mac II and not the other is the
Monitors setting.  Some programs that get fancy blit directly to bitmaps but
I doubt MacKermit 0.8 does this.

0.8 (34) crashes nicely (with 2-bit monochrome pixmaps) about 10 subroutine
calls deep on the stack frame.

Megamax C has a problem with System 4.1, incidentally, although a new
release may fix this.  However, I hope that the released version will be
compatible with either MPW C or LightspeedC, as these seem to be the two
most popular implementations nowadays.  I would say MPW is probably the
preferred compiler for large jobs but you're more likely to find volunteer
workers who have Lightspeed.

MPW provides Megamax-style C string conversions if you want it, while
LightspeedC has 16-bit ints like Megamax.  Converting either one shouldn't
be too bad, although the Lightspeed code generation won't be
68020-compatible until the next release (due Real Soon Now).

    Joel West,  Palomar Software, Inc. (c/o UCSD)
    {ucbvax,ihnp4}!sdcsvax!jww or [e-mail]

[Ed. - The new release will indeed be Megamax, but volunteers to convert
to MPW or Lightspeed will be gratefully accepted!]

------------------------------

Date: Mon, 20 Jul 87 14:09:03 EDT
From: Charlie C. Kim <[e-mail]>
Subject: Mac Kermit and Mac II
Keywords: MacKermit

MacKermit works on a Mac II; however, the Sumacc C compiler runtime
library does not.  Unfortunately, the current version of MacKermit is
built with the Sumacc C compiler.  The problem is the traps and calls
to various in-rom/ram packages on the Macintosh are built in-line, on
the stack as I remember, by the Sumacc C compiler runtime libraries.
This doesn't work too well on a 68020 based system like the Mac II
because the 68020 has an instruction cache.

If you are willing to live with a (moderate) performance degradation,
simply turn off the instruction cache with following MPW asm program:
        Machine MC68020
    nocache main
        clr.l d0
        movec d0,cacr
        rts
        ENDP
        end

Simply "restart" your machine to turn the cache back on.

Charlie C. Kim
User Services
Columbia University

Here's the corresponding compiled program in binhex 4.0 format:
 ---------------- CUT HERE ----------------
(This file must be converted with BinHex 4.0)

:#@j[)'PMB@0SC3""8&"-2j!%!*!)!@qqk!#3"!%!N!-",!#3!b`!N!0$!4JQEJ!
@)'hkZL*Z!!J`%8'm(rrP3#K`!!!H&!*(!2m#H#i!!J#3!d&38%`rN!3!N!S*R`#
3"N&38%`rN!3!N"LG*p!U!*!'!@m"DN(ZrIBI%$mm!2p1V3&53qlqpR"!)YK63'l
k3QG"l[lf,`J[,J!12bi!$%KZrrj1Z[ib%"pR%MmZrri[,J!),bi!%NkY!(*J$%*
R,bi!##m,6Ud!FNcI')"1AL"Ih[`!%Nl3d&*23d968dm!N!3,SJ9J!!j19[cq)'i
!#%2Zr`#3""J!N!-S!!!#!*!%#!#3!b!!!$mm!!'Tm!#3!``!N!-"F!"1H`!#6R8
!!!%!N!-",!#3!b`!N!0$!!,Sk!AL!*!$(!!q!!"$6d4&!!%!#J!!rrmJ!*!)!3!
!&!!!(!!#k'`%6@&TE[M5!:

[Ed. - Thanks Charlie!  This message has also been added to the CKMKER.BWR
file.]

------------------------------

Date: Thu 16 Jul 1987 11:12:40 CDT
From: Mark S. Zinzow <Markz@Uiucvmd>
Subject: 7171 MSKERMIT.INI for MS-DOS 2.29C Kermit
Keywords: MS-DOS Kermit, Protocol Converters, .INI Files

I have finished translating the MSKERMIT.INI file to 2.29C and
got the typos out.

[Ed. - Thanks, Mark!  For now, the file is in KER:MSI71C.INI.  We'll have to
find some better naming scheme...  This file should go a long way towards
helping the many people who are confused by the new key redefinition syntax.]

------------------------------

Date: 8-JUL-1987 10:05:25
From: V Paramananda (PS) <[e-mail]>
Via: [e-mail]
Subject: Problem with C-Kermit on SUN
Keywords: C-Kermit

We are having trouble with a version of C Kermit installed on a Sun 3/160
workstation within the Department of Photogrammetry and Surveying at UCL. It
appears impossible to get the system set up as a virtual terminal so that
that it can initiate transfers from other Kermits, in this case a VAX within
UCL. We can set up the line /dev/ttyb on this Sun without any apparent
problems.  However, when the line is connected there is no response from
remote hosts at the other end of the line. It is unlikely that the hardware
is a fault, as the UNIX utility function 'tip' is able to establish
connections without problems.

Mark O'Neill,
Dept of Photogrammetry and Surveying
UCL,
Gower Street,
Londow WC1E 6BT UK.
Tel: [phone]X2743

[Ed. - Many people are using C-Kermit on SUNs to communicate with VAXes.
We'd need more information before we could diagnose the problem -- exactly
which version of C-Kermit are you running?  Exactly how are you connected
- direct line, modem, local net, ...?  Are there any error messages?
Meanwhile, could someone who is successfully using C-Kermit on a SUN please
pass along any hints?]

------------------------------

Date: 15 Jul 87 16:35:52 GMT
From: [e-mail] (Tom Holodnik)
Subject: Binary File Transfers
Keywords: Binary Files

In Frank da Cruz' Kermit reference, he states that the command "set
file type binary" issued at both ends will enable encoding of binary data
streams into ascii characters.

In all the versions of Kermit I have seen (Kermit 2.29, C-Kermit 4D(061)), this
option is unavailable.  The reference states that this facility may not be
available on every version, but I was wondering what versions of Kermit it was
available for, and whether there were any plans to incorporate it into future
versions for the PC, or for Unix systems.

I'm sure that it may be simple to implement this into the CMU version of
Kermit, but it makes sense to have some standardization, eh?

Thanks,
Tom Holodnik
Carnegie-Mellon University

[Ed. - You're confusing a couple issues.  SET FILE TYPE BINARY means that
no representation-level data conversion will be done -- no ASCII/EBCDIC
translation, no conversion of line terminators from one system to another,
etc.  In other words, the bytes of a file are sent as is.  The default is
mode for file transmission is TEXT, in which files are represented as
streams of ASCII characters, with lines (records) delimited by CRLFs.  Now,
after these conversions are done, Kermit encodes data for transmission.
First, all nonprintable characters are converted to prefixed printables.
For instance, Control-M becomes #M.  Second, if parity is in use on the
communication line, a second printable prefix (normally &) is inserted before
any byte whose high order data bit is 1, so &#M would be the encoding for
binary 10001101 (Ctrl-M with its 8th bit on).  All Kermits do the control
prefixing, whereas 8th bit prefixing is an optional and negotiated feature.]

------------------------------

Date: 20 Jul 87 20:47 EST
From: [e-mail]
Subject: Time Loop for Prompts in Script Files
Keywords: Script Files

I'm a summer intern at GE's Corporate Research and Development in Schenectady,
New York.  I've been working on a script file to automatically upload a file
from the pc to the mainframe.

I'm a little frustrated with the time loop requirement for the anticipated
prompts.  Is there some way that the next command in the script file be
executed upon seeing the anticipated prompt?  Right now, I've something like
"INPUT 15 Enter Access Code"; and depending upon the time specified, the
waiting period will vary up to the specified time even though the anticipated
might have appeared before 15 seconds or the specified time has elapsed.

Thanks,
Ben

[Ed. - There must be something wrong.  If MS-Kermit encounters the input
string, it proceeds to the next command right away.  Therefore, it must not
be matching the string.  Maybe parity is the culprit?]

------------------------------

Date: Mon, 20 Jul 87 14:43:05 EDT
From: "James J. Steiner" (CCL) <[e-mail]>
Subject: MSKERMIT for the DEC Rainbow.
Keywords: DEC Rainbow Kermit

Does anyone have experience with the enhanced MSKERMIT for the DEC Rainbow
100 written by David Knoell. I down loaded a copy two months ago and found
that it doesn't work as described in its documentation. Particularly the
'print controller' escape sequence doesn't work. also the information in
the help screens status doesn't agree with the information shown when you
use the status command. This is a very fine program otherwise but I often
use screen bypass printing provided by the 'print controller' sequence in
the Rainbows native vt100 mode.

Thanks,
Jim Steiner
[e-mail]
[phone]

------------------------------

Date: 1987 Jul 22   13:21 EDT
From: (John F. Chandler)   [e-mail]
Subject: Bootstrap version of Kermit-CMS 3.1
Keywords: CMS Kermit, TSO Kermit, Portable IBM Kermit

With the release of Kermit-CMS 3.1 it became possible to choose a bootstrap
form of the program that loads Kermit into free storage and permits
execution of any and all user programs underneath Kermit.  However, I know
of one user who consistently found the bootstrap program to halt with a
message claiming a lack of storage.  I have finally traced the problem to
the length of his GLOBAL list of TXTLIB's, but before I do anything else
about it, I would like to know:

1. Has anybody besides me and this one other user tried out the bootstrap
   form of Kermit-CMS?  The module is only about 400 bytes long and is
   accompanied by a TEXT file.  The difference in operation is that the
   bootstrap version will execute user-area CMS commands (e.g., COPYFILE)
   while the traditional form will not.

2. Has anybody who tried out the bootstrap version encountered problems
   like the one I described (error message DMSLIO109S VIRTUAL STORAGE
   CAPACITY EXCEEDED, followed by return code 108)?  Any other problems,
   for that matter?

                                         John

------------------------------

Date: 1987 Jul 23   20:15 EDT
From: (John F. Chandler)   [e-mail]
Subject: Portable Kermit for IBM 370's
Keywords: CMS Kermit, TSO Kermit, IBM 370 Kermit, Portable IBM Kermit

There is a new development in Kermit for the IBM 370 architecture,
namely, a generic Kermit.  The new Kermit is descended from the original
Kermit-CMS 1.0, but it differs from its cousins in that the system-
specific functions (such as disk I/O, system interaction, and terminal
I/O) are segregated into a separate section of code.

The initial implementation (the CMS version) has been completed and
tested, and a preliminary TSO version has been written.  When the latter
has been debugged, it can replace all of the existing TSO Kermits (by
virtue of supporting both line-mode and Series/1-type terminals, as well
as offering most capabilities supported by Kermit-CMS 3.1, plus many
more.)  The hitch is that debugging the TSO version requires someone
with access to a TSO environment.  Anyone wishing to help bring the new
TSO Kermit to completion (and thereby acquiring it soon) should send me
a note, either by E-mail or post.  For that matter, anyone wanting to
port Kermit-370 to any other operating system should do so as well.

BITNET:   PEPMNT@CFAAMP
Internet: [e-mail]
Post:     John F. Chandler
          Center for Astrophysics  M/S 63
          60 Garden St.
          Cambridge, MA 02138

[Ed. - Volunteers, please!  Our disks are becoming choked with alternate
TSO Kermit versions -- this one for 3705s, that one for Series/1, another
for 3708, etc etc.]

------------------------------

Date: Thu, 23 Jul 87 12:10 EST
From: JOHNSON <@cis.upenn.edu:[e-mail]>
Subject: Kermit Buffering Problem
Keywords: VAX/VMS Kermit

I am a Kermit user and would like to ask you for help with a specific
problem.  Can anyone help with a buffering problem we are having when using
Kermit to connect to an out going line from a VAX 11/750 to a University-
wide network at the University of Pennsylvania.

Kermit (version 3.2.076) is installed on our system.  The University of
Pennsylvania has installed a fiber optic network throughout the University
with a T-1 phone link from the network to New Bolton Center where we are
located. ( The campus at New Bolton Center (NBC) is located about 40 miles
from Philadelphia and serves as the center for large animal teaching and
research for the Vet School of the University.)  The NBC campus has been
provided with fiber optic links to the main buildings on the NBC campus.
Currently, three systems are connected to the network, the VAX 750 is one of
them. Because it is not possible to provide direct network access to all
users at NBC, I would like to give our VAX users access to the network
through the VAX.

Connecting to the network through Kermit has been no problem; however,
buffer overruns prevent the connection from being useful.  File transfers
seem to work OK, but, when using Kermit in connect mode, receiving large
amounts of data at the originating terminal always results in lost
characters.  It seems that the terminal sends an XOFF, but the host sending
the data continues to send, and data is lost at the receiving terminal.

I have tried changing terminal buffer sizes with no success.  I have spoken
with the network administrator about XOFF settings on the network lines.  He
assures me that the network is set correctly.  Also, we have enabled the
alt_typeahead setting for the terminal lines.  We have had no success with
any of these remedies.

The following diagram may help to explain the connections.

   Originating terminal--> VAX--> Network--> Remote Host   *** seems to work OK

   Remote Host--> Network--> VAX--> Originating Terminal   *** lost characters

I would greatly appreciate any help you could give me with the problem.

Thanks,
Kaye Johnson
NBC
University of Pennsylvania

[Ed. - We have heard similar reports about VMS Kermit losing characters when
during CONNECT.  Reportedly, the CONNECT code could be done in better ways.
Unfortunately, the authors of VMS Kermit aren't going to be able to spend much
more time on it.  We hope that the VMS support in C-Kermit will be souped up to
the extent that it can start being used in place of Kermit-32.  Meanwhile, your
setup may be a "worst case" in that it could take a long time for XOFFs to
propogate back through the network, depending on how flow control works in
your network.]

------------------------------

End of Info-Kermit Digest
*************************
-------
 7-Aug-87 12:08:04-EDT,27034;000000000000
Mail-From: SY.CHRISTINE created at  7-Aug-87 12:07:12
Date: Fri 7 Aug 87 12:07:12-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V6 #16
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 7 Aug 1987       Volume 6 : Number 16

Today's Topics:

             Announcing C-Kermit 4E(066), a Test Release
                        DG Kermit Announcement
           Announcing MS-DOS Kermit 2.30 for RMX86 & RMX286
                 New MSPCTRAN program in Turbo Pascal
                 Update to BOO-maker program MSBMKB.C
                  Modcomp Kermit Files Now Complete
                    Re: "Okstate" Leaving the Net
                     MS-DOS Script PAUSE Command
                     Re: Bootstrapping CMS Kermit
                     Re: Kermit Buffering Problem
                     Re: Kermit & Mac II (V6 #14)
                         Re: DG Nova (V6 #14)
                C-Kermit on PDP-11/23 running UNIX V6

----------------------------------------------------------------------

Date: Thu 6 Aug 87 12:19:49-EDT
From: Frank da Cruz <[e-mail]>
Subject: Announcing C-Kermit 4E(066), a Test Release
Keywords: C-Kermit, Unix, Macintosh, VAX/VMS, Apollo, Aegis, Commodore
Keywords: Amiga, Data General

This is to announce an experimental new release of C-Kermit for Unix, VAX/VMS,
the Apple Macintosh, Apollo Aegis, the Commodore Amiga, and Data General
AOS/VS.

I've tested this version on various Unix systems (Ultrix 1.2 & 2.0 on various
VAXes, AT&T System V on a 3B20, and 2.9BSD on a Pro-380), but not on anything
else.  Since I'm about to leave on vacation for several weeks, I'd appreciate
it very much if during that time people could try it out on all the other
systems it hasn't been tested on, including Macintosh, Apollo, Amiga, VMS, Data
General, and many Unix variants (Xenix, Venix, Zeus, etc, especially in local
or dialout mode), and report back to [e-mail], especially
if they have fixes to contribute.

The new release is 4E(066).  The major changes from 4D(061) (September 86)
include:

  . Support for long packets (but not sliding windows).

  . Performance improvements: less copying of received data, more efficient
    i/o, especially when receiving files.

  . C-Kermit now takes its init file always, even if invoked with command-line
    action arguments.

  . Easy escape from packet mode (^C^C at any time).

  . A file bytesize mask to 'set file type {text, binary} {7, 8}' so that
    Kermit can be used to strip 8th data bit during file transfer (e.g. of
    Wordstar files), independent of parity setting.  Default 8.

  . A new 'set terminal bytesize {7, 8}' command.  Default 7.

  . A 'set retry' command to adjust packet retransmission limit.

  . Support for the Macintosh with Megamax C, so that for the first time
    Mac Kermit can be built directly on the Mac.

  . New support Data General AOS, AOS/VS, MV/UX and possibly RDOS & other
    DG operating systems.

  . New support for Apollo Aegis.

  . Continued support for the Commodore Amiga.

  . New 'make' options for sys5r3, CIE Regulus, HP-UX, IBM IX/370, Zilog,
    and some others.

  . Better statistics reporting.

  . Major bugs fixed:

    - Loss of trailing control characters at end of file when sending.
    - 2-character checksum now works with 8-bit binary files.
    - Background/take-file interaction fixed (maybe?).
    - Insertion of spurious CRLF at position 4096 when doing 'kermit -k'.
    - Parsing of multine 'get' command (again).

  . Many minor bugs fixed.

Benchmarks show a slight improvement in efficience when sending files with
regular length packets, and large improvement when receiving files, and a very
dramatic improvement when receiving files when using parity.  The improvements
are most noticable on systems where the CPU is the bottleneck.  For instance,
transferring a 16K text file between a VAX-11/750 and a Rainbow at 9600 baud,
using even parity and 94-character packets, the following effective baud rates
were observed:

        C-Kermit  Version
        4D(061)   4E(066)

  Send        3500      3920   (a  12% improvement)
  Receive      800      4223   (a 428% improvement)

Use of long packets improves efficiency even more, up to a point (a function of
the packet length and the particular system) past which it degrades again.  A
good length for VAXes seems to be 300-800, where we get effective baud rates in
the 50-80% range (provided we have clean lines and no retransmissions) --
higher efficiency at lower baud rates, and even higher in all cases when
compression can be done.  For instance, the following efficiencies were
observed when sending the typical Unix 8K program core image (which has lots of
0's in a row) at 9600 baud from a Rainbow to each of two typically loaded
VAXes:

            ------ VAX 8700 -------    ------- VAX 750 -------
  Packet    Effective                  Effective
  Length    Baud Rate    Efficiency    Baud Rate    Efficiency
    40        4481          47%          3414          36%
    94        6518          68%          4217          44%
   200        7170          75%          4780          50%
   300        7966          83%          4780  (peak)  50%
   500        7966          83%          3773          39%
   800        8962  (peak)  93%          2757          29%
  1000        7966          83%          2390          25%

By the way, a caution to those who are running Ultrix 2.0 on VAX 8700's: Kermit
(any version), and probably any program like Kermit, doesn't work very well at
9600 baud on DMZ's with fast PC's like IBM ATs or PS/2s, but does OK at 4800
and below, or at 9600 baud with slower PCs like Rainbows, PC-1's, etc.  But
Kermit works fine with the same PCs on 750s, 8650s, and other non-BI VAXes.

A plea for help with the non-Unix versions:

. For all versions, there's been a change to CKxTIO.C (the system-dependent
  terminal i/o and interrupt procedures for system x) that allow for much more
  efficient operation with parity; the change is in ttinl(), and I tried to
  apply it to the various modules, probably incorrectly (and in some, I hadn't
  the slightest idea what to do).  All but the Unix version (ckutio.c) are
  untested.

. The Data General, Apollo, and Amiga support comes from Phil Julian and Jack
  Rouse at SAS Institute.  Their work applied to 4D(061), and I tried to
  integrate it into the new version.  I'm sending them a tape with the new
  files so they can test it out; meanwhile, if people with Data General
  systems can try to build from the source and report on the results, that
  would be great, especially if it still works.

. The VMS support hasn't changed, except for the ttinl() business.  I have
  a volunteer who's souping up the VMS support for C-Kermit (in light of
  the "stable" status of Stevens Kermit-32), and will send him a tape, and
  hope to get results back in a couple months.

. The Macintosh support is a major new change.  It now compiles directly
  on the Mac, under Megamax C, thanks to Jim Noble of Planning Research
  Corp, who will also get a tape.  Again, this support was added to 4D(061),
  and needs to be rebuilt for 4E(066).  If anybody can try this, please report
  back.  And if it works, send in new CKMKER.HQX and CKMKEY.HQX files for 4E.
  And if anybody wants to try converting it to Apple MPW C, or Lightspeed C,
  etc, that would be good too.

The files are in KER:XK*.* on CU20B.COLUMBIA.EDU (available via anonymous FTP)
and XK* * on CUVMA (available via BITNET KERMSRV), and will be on Kermit Tape
B, and should also show up at Oklahoma State U for UUCP access within a couple
weeks.  The new files don't replace the current C-Kermit files (CK*.*), and
will not do so until all the systems demonstrably work.  In order to use these
files, you have to rename them to CK*.* (or ck*.*) so that the various
Makefiles and other build procedures work, and the include (.h) files have the
right names.  There's a program to do this, XKTOCK.C, which should be fairly
portable (if it doesn't work, the files can be renamed by hand).

Since the collection of files is quite large, you might want to make a
judicious selection if obtaining them over networks:

  Group       Size  Description

  KER:CKC*.*  111K  Required for all systems.
  KER:CKW*.*   13K  Wart, required for all systems.
  KER:CKU*.*  545K  For Unix, VMS, Data General, Apollo.  Includes Unix docs.
  KER:CKM*.*  488K  Macintosh specifics.
  KER:CKI*.*   96K  Amiga specifics.
  KER:CKD*.*  892K  Data General specifics.
  KER:CKV*.*   67K  VAX/VMS specifics.

  Total size approximately 2.2MB

  KER:CKP*.* (these files don't exist yet, but "P" is reserved for IBM PC)
  KER:CKH*.* (not available yet, reserved for Harris, see below)

(On BITNET/EARN, leave out the KER: and replace the period by a space.)

A detailed list of changes is in the file XKUKER.UPD, and the documentation
(CKUKER.MSS, .DOC, .BWR, .NR) has been revised to reflect the new features.

Thanks in advance to anyone who is willing to take a shot at evaluating and/or
fixing all of this, and apologies for releasing it and then disappearing.
And thanks to the many people (listed in the XKUKER.UPD file) who contributed
to this release.

Finally, if you succeed in building and running this program for a any system
at all besides VAXes with Ultrix, please report back the system, OS, OS
version, and maybe some particulars like maximum baud rates, best packet size,
problems, idiosyncracies, and tricks.

- Frank

P.S. I just got a tape from David Wilson of the Waisman Center in Madison,
WI, with C-Kermit 4D(061) support for Harris computers with DMACPs or CNPs
(whatever those are!), but according to his letter, major changes were required
to the system-independent (CKC*.*, CKU*.*) modules.  It's too late to try to
integrate this with the new stuff.  Maybe in September.

------------------------------

Date: Fri, 15 May 87 16:05 EDT
From: [e-mail] <Phil Julian, SAS Institute>
Subject: DG Kermit Announcement
Keywords: C-Kermit, DG Kermit

The new Kermit for the Data General computers is ready for initial release.
This Kermit is the Unix Kermit version 4D(061) with DG-specific modules for
file I/O (ckdfio.c), terminal I/O (ckdtio.c), and the connect command
(ckdcon.c).  This version supports all the features that Unix Kermit provides,
except for the DIAL command and the SCRIPT command.  The program was developed
under AOS/VS rev 6 and rev 7.54, and with recompilation it may work on other
Data General systems, such as AOS/RT32 and MV/UX.  Version 3.21 of the C
compiler was used to develop the source.

In addition to the usual features of C-Kermit, some additional features are
available for the DG Kermit.

    * Data General wild cards and special symbols are supported when
      referencing files, including the following set: # + - * ^ = @

    * Fully qualified pathnames can be used to get or send files.
      Sub-directories are entered if the # character is used.

    * DG and non-DG terminals are supported, so that character deletes occur
      correctly on-screen for any terminal device.

    * Batch mode operation is supported.

    * I/O redirection of the "xeq" command is supported.

    * Baud rates up to 38400 are supported, and other additional baud rates
      are supported (enter "help set baud" at the Kermit prompt).

    * Terminal emulation on a dial-out line from the DG is very fast, and has
      been tested up to 19200.

    * The initialization file, .kermrc, is executed even when Kermit is used
      in command line mode.

    * The local space command accepts a directory parameter.

Documentation is also supplied (ckdker.doc), which is adapted to the Data
General from the regular Unik Kermit document (ckuker.doc).  Installation
guidelines are included (ckdker.hlp), and cli macros assist in compiling and
installing the source code.  A "beware" file lists all known bugs and quirks
(ckdker.bwr).

Data General users can get C-Kermit version 4D (061) in DG tape format,
including all source, binaries, and program files.  I finally got around to
loggin onto the NADGUG bulletin board, and announced C-Kermit.  When someone
wanted to know how to get a copy of the program, I asked for a volunteer to
distribute DG Kermit tapes.  I got an immediate response.  Please add this
address and information about providers of DG Kermit:

     Send a tape and return postage to

    Randy Burndt
    Data Processing Manager
    American Urological Association
    6750 West Loop South
    Suite 900
    Bellaire, Texas  77401

     and he will send you Kermit and some other DG utilities.

Thanks to Randy and the NADGUG BBS for a quick response.

Phil Julian

BITNET:  CCPHIL@TUCC
Usenet:  rti!sas!julian
Phone:   [phone]

[Ed. - Many thanks, Phil!  These files are included with the new C-Kermit 4E
files, KER:XKD*.*, plus some conditional compilation code in some of the XK[CU]
modules.  Let's hope that the 4E can be brought up quickly on the DG, and that
the tape volunteer will get a copy.]

------------------------------

Date: Tuesday   August  4, 1987  4:41 PM PDT.
From:<[e-mail]>
Subject: Announcing MS-DOS Kermit 2.30 for RMX86 & RMX286
Keywords: MS-DOS Kermit, RMX Kermit

This is to announce the test release of version 2.29C of Kermit for both the
RMX86 and RMX286 Operating Systems.  Relevant files are MSTRMX.BOO, for
RMX86, and MSTRX2.BOO, for RMX286, MSTRMX.DOC, and MSERMX.P86.

In addition to all of the changes that have gone into MSKermit in nearly four
full versions since 2.26, wildcard send, full RMX paths and file names, easing
of previous restrictions on RUNable commands, and performance improvements have
been added at the RMX end.

Wildcard send has been implemented through use of an auxiliary command, WC,
whose source is in MSERMX.P86.  A comment header includes SUBMIT file contents
to generate the command for both OS's.  As a fortuitous fallout to wild card
implementation, a list of file names may be used wherever Kermit accepts a wild
card file specification, as long as all files in the list are in the current
default directory.  For example:

SEND READ.ME.FIRST,*X*.A*,*.OBJ,ETC.ETC

works.  Try to say that in DOS!  Similarly, when Kermit is in SERVER mode, it
will respond to a GET file-name-list from the local Kermit.

The WC command is only necessary for wildcard sends.  Kermit works fine
without it.  If used, it should be in one of the default search directories.
It and Kermit needn't be in the same directory.  The WC command isn't
otherwise totally useless.  Try "WC ?able,movie*" as an alternative to
"DIR$ FOR ?able,movie*".

Note that all version 2.29C's aren't identical.  Kermit is a living,
changing in real-time thing.  If the version ID were changed with every
discrete instance of Kermit, the alphabet would be exhausted in less than
one month.  While comments are solicited, any "How come this one's not the
same as that one?" or "Why's that turkey's got a later version than my
superb system?" will be referred to this paragraph, if we're in a good mood.

[Ed. - Many thanks!  The files are in KER:MSTRMX.* and MSERMX.P86 available
through APRAnet by FTPing to CU20B as user ANONYMOUS (any password) and via
BITNET using KERMSRV.]

------------------------------

Date: Thu, 30 Jul 87 22:03 CST
From: <[e-mail]>
Subject: New MSPCTRAN program in Turbo Pascal
Keywords: MSPCTRAN

  I am sending a Turbo Pascal program which does the same thing as the
MSPCTRAN.BAS file.  I got tired of waiting so long to translate the .BOO
files I receive so often from Columbia, so I decided to re-write the
MSPCTRAN.BAS program in Turbo Pascal.  This sped up the translation
considerably.  On my IBM-AT clone, running at 10 Megahertz and using a hard
disk, unpacking the MSTIBT.EXE file using the BASIC program took over 7
minutes.  This program does it in 22 seconds.  Using floppy diskettes the
speed improvement should be even faster, because I buffer more of the output
in memory than the BASIC program does.

  I have tested the program using Turbo Pascal version 3.01C and 2.00B.  I
tried it on the MSTIBT.BOO file.  Doing a file compare on it when it is
finished shows that the BASIC and PASCAL versions are identical except for
the last few bytes, which are different because the files are padded out to
a block size of 128 characters.  This will not effect the KERMIT program
because these padding characters are not really part of the program.

  There is nothing in this program which is specific to IBM computers, so it
should compile fine using the generic MS-DOS version of Turbo Pascal.  There
is some Turbo Pascal specific code (the BLOCKWRITE and STRING[255] portions
especially) but the program should be easily transportable to other pascals.

  I hope you find this useful.  Consider it partial repayment for the
excellent service Columbia is doing for the Computing community.

  Kevin Lowey
  Computing Services
  University of Saskatchewan
  LOWEY@SASK (bitnet)
  ...!alberta!sask!lowey  (uucp)

[Ed. - Many thanks!  This goes into the collection, along with the
assembler, C, and Basic versions, as KER:MSBPCT.PAS.]

------------------------------

Date: 30-JUL-1987 14:06:06
From: David Sizeland   <[e-mail]>
Via: [e-mail]
Subject: Update to BOO-maker program MSBMKB.C

I have made some mods to msbmkb.c as it doesn't run properly on Unix systems
as is.  The changes are in the code to open the output file.  Under Unix,
open won't create the file if it doesn't exist, you have to use creat
instead.  Also, I am not sure about the 0x1ff in the open for the input
file, the compiler doesn't give an error but it is certainly superfluous.
The diffs are from the old file to the new.

David.

[Ed. - Thanks, your diffs have been added to MSBMKB.BWR.]

------------------------------

Date: 7-Aug-87 0:0:0 EDT
From: Christine M. Gianone <[e-mail]>
Subject: Modcomp Kermit Files Now Complete
Keywords: Modcomp

The version of Kermit that was announced for the Modcomp Classic running
under the MAX IV operating system, contributed by Bob Borgeson, of SETPOINT,
Inc., announced in Info-Kermit V6 #3, 26 Jan 87, had a bunch of files missing.
The missing files have been restored, and the program should now be complete.
The files are in KER:MOD*.*.

------------------------------

Date: 4-Aug-87 0:0:0
From: Mark Vasoll <[e-mail]>
Subject: Re: "Okstate" Leaving the Net
Keywords: Okstate

In article <[e-mail]>, I write:
> The system "okstate" will be leaving Usenet as of August 14th.  All
> News and uucp mail connections will be dropped.

I haved received several mail messages asking how this will affect our
UUCP Kermit Distribution.  The answer is, not at all.  We will continue
to provide access to the full collection of Kermit sources via both
direct UUCP connections and via our custom Kermit server.  The only
change will be that the support address is now "[e-mail]"
and will only be reachable via the Internet as mentioned in my original
posting.

Mark Vasoll
Computing and Information Sciences   Internet:  [e-mail]
Oklahoma State University            UUCP:  {cbosgd, ihnp4, rutgers, seismo,
Stillwater, Oklahoma                         uiucdcs}!okstate!vasoll

[Ed. - Also, in view of the new reorganization of Kermit distribution
into 5 areas, it'll take a while for OK State to reflect the new
arrangement.  Patience, please.]

------------------------------

Date: Wed, 29 Jul 87 12:17 MDT
From: <[e-mail]> (Joe Doupnik [e-mail])
Subject: MS-DOS Script PAUSE Command
Keywords: MS-DOS, Script Files

In the latest Kermit Digest Ben Chang, [e-mail]
commented that he experienced unstable delay times when using the MS Kermit
script command PAUSE. The timing was found to be machine dependent in a
subtle DOS way and has been rewritten to avoid the effect. The release
Kermit will time accurately on all machines having a DOS timeofday clock.

Ben might also want to try the long script example from the new MS Kermit
manual for transparently loading files to/from the host.  For quick
reference and relaying here is a pair to implement

        DOS-prompt> send filespec

where filespec can have wildcard characters. It differs only trivially from
the manual example.

                        Regards,
                        Joe D.

[Ed. - Thanks, Joe!  Your script example has been placed in KER:MSTIBM.SCR.
The manual Joe mentions is still in preparation, but will be released with
the real 2.30, probably in early September.]

------------------------------

Date: Wed, 29 Jul 87 11:52:52 EDT
From: BJ CAMERON (SYSTEMS DEVELOPMENT) <HESSE@WATDCS>
Subject: Re: Bootstrapping CMS Kermit
Keywords: CMS Kermit

In reply to John Candler's query about the bootstrap form of Kermit-CMS 3.1:
There is another option not mentioned in the documentation which also permits
running user programs underneath Kermit (e.g. COPYFILE).
When LOADing the Kermit module use the RLDSAVE option.  For example:

LOAD KERMIT (RLDSAVE
GEN KERMMOD

You can then load Kermit as a nucleus extension with the following EXEC.

/*
   FUNCTION:  NUCXLOAD THE KERMIT MODULE TO FREE UP THE USER AREA
   CREATED BY:     HESSE@WATDCS   86/11/12
*/
   address command
   parse upper arg arg_string
   'NUCXLOAD KERMMOD'
   KERMMOD arg_string
   'NUCXDROP KERMMOD'

[Ed. - Thanks!  Your comments have been added to KER:CMSKERM.INS.]

------------------------------

Date: 29 JUL 87 23:05-PDT
From: [e-mail]
Subject: Re: Kermit Buffering Problem
Keywords: VMS Kermit

In response to the query about VMS Kermit typeahead buffering in Info-Kermit
V6 #15:

Try setting /ALT (alternate typeahead buffer) on the line you want to use
with KERMIT.  This gives you a bigger input buffer, so you won't get (as
many) data overruns.  I believe that you can set the size of the alternate
typeahead buffer with SYSGEN if you want to make it bigger.  I have all my
outgoing lines configured that way (via SYSTARTUP.COM so it's permanent) and
it helps a lot.

Mike Iglesias
University of California, Irvine

------------------------------

Date: Wed, 29 Jul 87 17:37:59 EDT
From: Paul Placeway <[e-mail]>
Subject: Re: Kermit & Mac II (V6 #14)
Keywords: MacKermit, MAC II

In article <[e-mail]> you write:
>Date: 15 Jul 87 01:37:24 GMT
>From: [e-mail] (Joel West)
>Subject: Kermit & Mac II (V6 #14)
>Keywords: MacKermit
...
>MPW provides Megamax-style C string conversions if you want it, while
>LightspeedC has 16-bit ints like Megamax.  Converting either one shouldn't
>be too bad, although the Lightspeed code generation won't be
>68020-compatible until the next release (due Real Soon Now).
>
>    Joel West,  Palomar Software, Inc. (c/o UCSD)
>    {ucbvax,ihnp4}!sdcsvax!jww or [e-mail]

The last sentence is interesting, but partially untrue.  While the current
release of LightSpeed C dosn't support 68020 code, the 68020 is a propper
superset of the 68000.  LightSpeed does run, and does produce good, working
(although 68000) code on a Mac II.  Not too supprising since THINK did
follow all the rules that Apple set down for Mac software (not everyone
does: MegaMax did NOT).

In short, LightSpeed C does run on a Mac II, and does produce working
code (VERY QUICKLY) on a II.

            Paul Placeway
        Department of Computer and Information Science
    ARPA:    paul@ohio-state.{arpa,csnet}
    UUCP:    ...!cbosgd!osu-eddie!paul

[Ed. - All the more reason for someone to look at bringing up the new
Mac Kermit (announced above) on the Mac II, and possibly adding support
for Lightspeed or MPW C.]

------------------------------

Date: Wed, 29 Jul 87 14:25:26 edt
From: xyzzy![e-mail] (Michael Meissner)
Subject: Re: DG Nova (V6 #14)
Keywords: DG Nova Kermit

In article <[e-mail]> you write:
> Date: 1-JUL-1987 10:23:05
> From: [e-mail]
> Subject: Files Needed for the DG Nova Running RDOS?
> Keywords: DG Nova Kermit
>
> It's been pointed out to us that the files for Kermit in Fortran-5 for DG
> Nova machines running RDOS (prefix RDO) are incomplete. There are include
> references to SETSETUP.FR and F5ERR.FR, and these files aren't in the set,
> and what they may contain isn't obvious.
>
> Does anyone know what's in the files, or has anyone got copies?
>
>        Alan Phillips
>
> [Ed. - These are probably DG files that come with DG Fortran.  Anyway, the
> person who contributed the Fortran version of RDOS Kermit is long gone.
> The forthcoming release of C-Kermit will support DG C environments; it has
> been tested on AOS/VS, but not RDOS, however the C environment is supposed
> to be consistent across all the DG product lines.]

Ughhh, the DG C compiler only supports the 32-bit MV/eclipse systems (RDOS
runs on the 16-bit Eclipses and Novas).  The operating systems that the
DG C compiler supports are:

    AOS/VS        propritary
    AOS/RT32    propritary real-time subset of AOS/VS
    AOS/DVS        propritary distributed AOS/VS
    MV/UX        Unix System V hosted on top of AOS/VS
    DG/UX        Native System V/BSD unix

To my knowledge, the only C compiler that supports RDOS or AOS, is from
a company called IPT.  Sorry for any confusion.

Michael Meissner, Data General.        Uucp: ...!mcnc!rti!xyzzy!meissner

[Ed. - Oh.  So we can wipe RDOS off the C-Kermit list...]

------------------------------

Date: Tue, 28 Jul 87 12:57:12 PDT
From: [e-mail]
Subject: C-Kermit on PDP-11/23 running UNIX V6
Keywords: C-Kermit, PDP-11 Kermit

Has anyone got a working version of Kermit for a PDP 11/23 running Unix
version 6?  The C compiler on this system is very limited and does not
handle #ifdef.

Thanks in advance for any help.

[Ed. - C-Kermit is probably hopeless for V6.  Best hope would be the
old, old Unix Kermit from the 5th edition protocol manual, in KER:UX*.*,
or maybe Chris Kennington's portable C Kermit, KER:CUC*.*.  Good luck!]

------------------------------

End of Info-Kermit Digest
*************************
-------
21-Aug-87 14:29:38-EDT,20220;000000000000
Mail-From: SY.CHRISTINE created at 21-Aug-87 14:28:20
Date: Fri 21 Aug 87 14:28:20-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V6 #17
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 21 Aug 1987       Volume 6 : Number 17

Today's Topics:

                            New IBM PC .BOO File
                    Kermit 80 Version 4.08 (pre-release)
                    CDC Cyber Kermit Version 3 Available
                        Very Fast MSBPCT.PAS Program
                                COM3 Kermit
                        QK-Kermit QKKER.PAS File Bug
                           Re: EBCDIC Definition
                      CMS Kermit Initialization Files
                        Re: Bootstrapping CMS Kermit
                      Re: CMS 3.2 X-binary (2 messages)
                               Kermit 0.8(35)
                              C-Kermit Problem
                   Missing Files in RDOS Kermit Explained
               Transferring Other File Types in ProDos Kermit

----------------------------------------------------------------------

Date: Mon, 17 Aug 87 21:45 MDT
From: <[e-mail]> (Joe Doupnik)
Subject: New IBM PC .BOO File
Keywords: MS-DOS Kermit

I am sending another .BOO file with the usual trimmings plus better handling
of network packets for Token Passing systems and single buffered network
boards.

        Regards,
        Joe D.

[Ed. - Thanks Joe!  The new .BOO file is dated 16 Aug 87 and is in
KER:MSTIBM.BOO available through ARPAnet by FTPing to CU20B, user ANONYMOUS
(any password) and through BITNET at CUVMA using KERMSRV.  Thanks to all who
have been testing past versions of MS-DOS Kermit.  Please test this one and
send in comments, etc.]

------------------------------

Date: 29-JUN-1987 10:14:55
From: [e-mail] (Bertil Schou, Loughborough U, UK)
Via: [e-mail] (Alan Phillips)
Subject: Kermit 80 Version 4.08 (pre-release)
Keywords: CP/M Kermit

After an incredibly long gestation peroid, here is hopefully an updated
version of Kermit-80 V4.05.  Kermit-80 V4.08 is issued for testing purposes
only.  I want any feedback about problems generated in this revision, or
others desperately want fixing.

Superficially, there is little real change in operation of Kermit-80, but
there have been some major jobs tackled like trapping BDOS calls and
multiple FCB buffering...

New bits for this version include:
       SET {SEND/RECEIVE} START-OF-PACKET character
       SET DIRECTORY-FILE-SIZE  (Shows  or hides  file  sizes  on
               DIRectory displays)
       USER to set other user spaces
       RECEIVE to collect a file from a remote SENDer
       GET to collect a file from a remote SERVER
       SEND {local filename} {remote filename}
       TAKE to take command files from disk
       automatic  TAKE  KERMIT.INI  on default  disk  on  loading
               KERMIT-80 (useful for SET BAUD etc.)
       much improved speed on DIRECTORY
       automatic  CLOSE-ing of a terminal connection if the  line
               is  DROP-ped  (currently only for certain systems).
       improved printer handling.

On  the  negative side,  only LASM can be used  to  assemble  the
source files.   I personally see no pont in being able to support
several assemblers if LASM can do the job, but then again, I have
not  used  the MAC80 cross assembler...   Comments  on  assembler
compatabilities, please!

[Ed. - Thanks!  The new files -- source only, no hex -- are in KER:CX*.*.
The old CP/M version remains in KER:CP*.*.  Please report back bugs
problems, etc, as well as positive indications of what systems this new
version works on.]

------------------------------

Date: Thu 20 Aug 87 13:41:48-EDT
From: Christine M Gianone <[e-mail]>
Subject: CDC Cyber Kermit Version 3 Available
Keywords: CDC Cyber Kermit

A new version of Kermit is available for CDC Cybers running NOS.  It is derived
from the U of Texas Fortran 5 Kermit, with NOS/BE and UT2D support removed.  It
contains the following new features and changes (items 8 through 10 are new for
Version 3.3.)

1.  Wildcard file names on the SEND command and server GET command.  A '*'
    stands for any 0 or more characters.  A '?' stands for any one character.

    For example:
         *BUG      All files ending in BUG.
         *DOG*     All files containing DOG.
         F*        All files starting with F.
         F?X*      All files whose names start with F and contain X in the
                   the third position, followed by 0 or more characters.

2.  Local and permanent file SEND and server GET.  If no local files match the
    request, the user's permanent file catalog is searched.

    If the specified file name is preceeded by 'L:', only local files are
    sent.  If preceeded by 'P:', only permanent files are sent.

3.  A DIRECTORY command and server REMOTE DIRECTORY command.  Lists local
    (by default) or permanent file names.  Accepts wildcards and/or L: and
    P: specifications (above).

4.  Automatic recognition of DISPLAY CODE, 6/12 ASCII, and 8/12 ASCII file
    text modes on SEND.  Receives 6/12 ASCII by default.

    The SET FILE-MODE command allows BINARY and TEXT file types.

    SET TEXT-MODE allows AUTO to set automatic recognition (above), or
    DISPLAY, 6/12-ASCII, or 8/12-ASCII to force a specific character
    translation for TEXT file mode.

    BINARY file mode stores characters as 7.5 8-bit characters per 60 bit
    Cyber word.

5.  Supports repeated character compression (if the micro Kermit allows).

6.  Supports long file transfer packets up to 1000 characters (if the
    micro Kermit allows).

    Use the SET RECEIVE PACKET 1000 command within Cyber Kermit to enable
    long packet receive.  To send long packets, enter the above command in
    your micro Kermit, if it supports long packets.

7.  Cyber Kermit no longer affects the parity of your terminal connection.
    If you have trouble sending or receiving files, check your parity
    setting.  On the Cyber, the parity at login is set to NONE.  Note that
    changing your terminal class (TC parameter) via TRMDEF or %TC=?? will
    reset your parity setting.

8.  ***New for V3.3***   (May, 1987)
    Kermit will take commands from the file KERMINI at startup time.  You
    may use this to set non-standard parameters, start up an server
    automatically, etc.  Kermit will first look for a local KERMINI, then
    for a permanent file KERMINI.

9.  ***New for V3.3***
    There is now a   TAKE filename  command to direct Kermit to read its
    commands from a local or permanent file.  It searches for local and
    permanent files like the SEND command, above.

10. ***New for V3.3***
    When files are being received by the Cyber, Kermit will now attempt to
    use up to 3 characters of the micro's filename's extension as part of the
    Cyber's file name.  This allows file transfers of the form   LONGNAME.*
    to proceed with fewer file name conflict problems.

Please contact me if you have any problems with Cyber Kermit Version 3.

      Steve Roseman
      Lehigh University
      [e-mail]
      [phone]

[Ed. - Many thanks Steve!  These files have replaced the old files in
KER:CD3KER.*.]

------------------------------

Date: Thu, 13 Aug 87  11:46 EDT
From: Helmut Waelder <ZRWA001@DTUZDV1>
Subject: Very Fast MSBPCT.PAS Program
Keywords: MSBPCT.PAS

Here is a completly new version of MSBPCT.PAS written in turbo pascal.
It was developed for maximum speed. On my PC it decodes the MSKERM.BOO
file in about 9 (nine) seconds.

[Ed. - Many thanks.  The source code has replaced the old one in KER:
MSBPCT.PAS.]

------------------------------

Date: Sat 4 Jul 1987 14:17:29 CDT
From: Mark S. Zinzow <Markz@Uiucvmd>
Subject: COM3 Kermit
Keywords: MS-DOS Kermit, COM Ports

I had not recieved the Kermit Info-Digest V6N13 when I sent my note to the
IBM PC Info-Digest regarding my hacked copy of MS-Kermit 2.29 that supported
Com3.  Even though it took over a week for the files MSR29C.UPD and MST*.BOO
(MSTIBM.BOO in particular) to show up on KERMSRV at UOFT02 after they did on
KERMSRV at CU20B, I have them now and recomend them over my version.

Joe did not wait for me to update my modifications (I don't blame him; I was
taking too long) for version 2.3 so com3 & com4 support are in MS-DOS Kermit
2.29C.  Since my version is obsolete I will not be sending it to those who
have requested it from me.  If you really need the old version of kermit
with COM3 support, send me another request and I'll send a BOO file of the
binary.  I do not plan to distribute the soure because it is both large
(about 1 MB), obsolete, and contrary to C.U.'s policy of distributing source
to minor releases.

    Electronic Mail                          U.S. Mail
ARPA: [e-mail]   Mark S. Zinzow, Research Programmer
BITNET: [e-mail]         Computing Services Office
To BITNET from ARPA or UUCP:         University of Illinois at Urbana-Champaign
[e-mail] 150 Digital Computer Laboratory
CSNET: [e-mail]   1304 West Springfield Ave., Urbana, IL 61801
USENET/UUCP: {ihnp4,convex,pur-ee,cmcl2,seismo}!uiucdcs!uiucuxc!uiucuxe!zinzow
 Phone: [phone]  Office: CSOB 109  ihnp4!pyrchi/

------------------------------

Date: Thu, 23 Jul 1987  23:45 MDT
From: Keith Petersen <[e-mail]>
Subject: QK-Kermit QKKER.PAS File Bug
Keywords: QK Kermit

After getting QKKER.PAS from CU20B via FTP I attempted to edit QKKER.PAS to
split the individual files.  I noted that quite a few seemed to be missing
so I sent a note to the author.  Here is his reply:

>Date: Wednesday, 22 July 1987  13:32-MDT
>From: VIC%QUCDN.BITNET at wiscvm.wisc.edu
>To:   kpetersen at SIMTEL20.ARPA
>Re:   QK-Kermit
>
>     The file QKKERM.PAS should contain all the source files for both
>MsDos and CP/M version.  I seems as though you have a truncated
>QKKERM.PAS file.  The file should contain about 5462 lines. The last
>thing in the file is the KEYTABLE.DAT file.   It maybe that someone
>along your network path maybe truncating long files.

After receiving that I decided to get the file again and look at it with
EMACS on the mainframe.  What I found was a single control-Z at the end of
RECVFILE.PAS.

    END ; (* ------- RECVFILE procedure -------*)
^Z <-----the control-Z was here
(* ===FILE============ CONNECT.PASVT100 =========================== *)
(* ================================================================== *)
(*  Global Var and Procedures for Connect Procedure.                  *)
(* ================================================================== *)

On CP/M or MSDOS most editors see a control-Z as end-of-file.  I have
removed the control-Z and the fixed file is temporarily available via FTP in
PD:<MSDOS.TEMP>QKKER.PAS from SIMTEL20.ARPA.  No other changes were made.
Please let me know when you get it so I can delete the file.

--Keith Petersen

[Ed. - The offending Ctrl-Z has been removed from our copy.]

------------------------------

Date: Wed, 29 Jul 87 22:30:16 EDT
From: Peter DiCamillo <CMSMAINT@BROWNVM>
Subject: Re: EBCDIC Definition
Keywords: EBCDIC

There's a definition in Appendix G of IBM System/370 Principles of
Operation, GA22-7000.  The most convenient reference, which also includes
ASCII, is the "yellow book", System/370 Reference Summary, GX20-1850.

                                                       Peter

------------------------------

Date: Thu, 30 Jul 87 02:18:17 PDT
From: rutgers!ames!lll-tis!ptsfa![e-mail]
Subject: CMS Kermit Initialization Files
Keywords: CMS Kermit

Re: Info-Kermit Digest V6 #15:

I have a question related to CMSKERMIT.  According to the documentation, one
should be able to create initialization files which KERMIT reads and
executes upon startup.  One is described as (SYSTEM) KERMINI and the other
is described as (USERID) KERMINI.  What I am having trouble understanding is
exactly what the FILENAME FILETYPE would be in the CMS environment for
either file.  I realize the (USERID) KERMINI would be located on the user's
"A" disk, but is the filename KERMINI, and if so, what filetype?

Thanks!

(all standard disclaimers apply - your actual baud rate may vary,
depending upon atmospheric and cosmic disturbances)
Robert Cohen San Ramon, California {ihnp4,lll-crg,qantel,pyramid}!ptsfa!rhc

[Ed. - Answer:  SYSTEM KERMINI is the name of the system-wide init file,
and (USERID) KERMINI is on your disk, with (USERID) replaced by your own
user ID.  E.g., if your user ID is FOO, the file is FOO KERMINI.]

------------------------------

Date: 1987 Aug 10   14:29 EDT
From: (John F. Chandler)   [e-mail]
Subject: Re: Bootstrapping CMS Kermit
Keywords: CMS Kermit

The RLDSAVE option does not exist under CMS release 3 or earlier.
RLDSAVE+NUCXLOAD is clearly the method of choice under release 4 and beyond
(as long as Kermit doesn't somehow get loaded into LOW nucleus free
storage).  In fact, one might choose to leave Kermit in place as a permanent
system extension, rather than issue a NUCXDROP after each invocation.

------------------------------

Date: 1987 Aug 10   13:05 EDT
From: (John F. Chandler)   [e-mail]
Subject: Re: CMS 3.2 X-Binary
Keywords: CMS Kermit

>                                 I noticed that v-binary downloads F files
> just as binary does. That makes the user bound to specify not only the file
> RECFM F, but also the LRECL when he uploads F files.
> It would be easier if he had concern of neither RECFM nor LRECL.
> Do you see any any other straightforward way to transport CMS files, DISK
> DUMP excepted?

As a matter of fact, there is a way for transporting files for eventual
reconstruction on a system like the original one.  The method is called
archiving.  Kermit-CMS is halfway there -- it generates attribute info that
could be saved away by the micro Kermit and passed along with the file to
the target host.  What is missing is a well-thought-out scheme for deciding
precedence among the possible sources of attribute info.  We must remember
that "most" micro Kermits do not support file archiving, so the mainframe
must continue to assume that the usual source of attributes will be the
user, via SET commands.  I haven't thought it all out myself, but perhaps
Kermit-370 could merge any attributes received via A-packets and then
restore the defaults.

                                       John

------------------------------

Date: Wed, 12 Aug 87 09:57:00 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: Re: CMS 3.2 X-Binary
Keywords: CMS Kermit

>As a matter of fact, there is a way for transporting files for eventual
>reconstruction on a system like the original one.  The method is called
>archiving. ...

Yes, but as you say, everyone has to deal with attributes packets, keep them
somewhere and send them back. It is a long way until they all do so.  If we
agree an archive file is of no use on the archiver other than resending as
is for reconstructing, why not think of the archivee including the
attributes in the data itself, just where the archiver would think of
putting them? As with CMS, the data format itself may have to be adapted for
reconstruction anyway (also think of the Mac forks...).  If the CMS V-BINARY
or like were to segment fixed length files, the only missing information
would be RECFM, LRECL and timestamp to do so.

------------------------------

Date: Fri, 7 Aug 87 16:03:11 PDT
From: [e-mail] (Dave Platt)
Subject: Kermit 0.8(35)
Keywords: MacKermit

I've tested the Megamax version briefly on my Plus, talking to a 4D(061) on
my Sun 3/52, and it seems to work fine.  I've posted a short note to
comp.sys.mac, reporting that 0.8(35) is now available and relaying your
request for people to complete the 4D(066) port and/or port the whole thing
to MPW or LightSpeed C.

[Ed. - Thanks for the feedback on MacKermit.  And thanks to all of you
who have sent in comments, complaints, etc. about the new C-Kermit in
general.  I am keeping them all together for the author to review.]

------------------------------

Date: 8-JUL-1987 10:05:25
From: V Paramananda (PS) <[e-mail]>
Via: [e-mail]
Subject: C-Kermit Problem
Keywords: C-Kermit

We are having trouble with a version of C Kermit installed on a Sun 3/160
workstation within the Department of Photogrammetry and Surveying at UCL. It
appears impossible to get the system set up as a virtual terminal so that
that it can initiate transfers from other Kermits, in this case a VAX within
UCL. We can set up the line /dev/ttyb on thisd Sun without any apparent
problems. However, when the line is connected there is no response from
remote hosts at the other end of the line. It is unlikely that the hardware
is a fault, as the UNIX utility function 'tip' is able to establish
connections without problems.

Could you please reply to:
                           [e-mail]
Thankyou,
Mark O'Neill,
Dept of Photogrammetry and Surveying
UCL,
Gower Street,
Londow WC1E 6BT UK.
Tel: [phone]X2743

------------------------------

Date: 12-AUG-1987 11:23:39
From: [e-mail]
Subject: Missing Files in RDOS Kermit Explained
Keywords: RDOS Kermit

The missing files SETSETUP.FR and F5ERR.FR in RDOS Kermit (RDO) have now
been explained. SETSETUP.FR is a mistyping for STDSETUP.FR, which is
included in the conatenated sources; F5ERR.FR is a standard DG Fortran
support filem which ought to be included with the Fortran compiler.

------------------------------

Date:  Wed, 12 Aug 87 12:39 EDT
From:  [e-mail]
Subject:  Transferring Other File Types in ProDos Kermit
Keywords: ProDos Kermit, Apple Kermit

Kermit 3.75 (and presumably the later ones too) is only "designed" to
handle four file types:  TXT, BIN, INT, and BAS, the standard DOS 3.3
types.  As far as I can tell, the only type it does something funny with
is the TXT type -- it converts from ordinary ASCII to Apple's hi-bit
ASCII, but it may also do something special with INT and BAS.

To get it to handle something else (in my case, WordPerfect's $A0 type)
one can fool it into using any file type code you want for the binary
mode.  To do this you need to change two bytes in the program.

At location $4995 there is a string A9 06 CD
  (LDA #06
   CMP ...)

At location $4A2A there is A9 06 8D
  (LDA #06
   STA ...)

(the locations will presumably differ in other versions, but my guess is
that the same sequence will be there someplace)

The first is where it is checking that the file type of a file you are
about to transmit is what you say it should be, the second is where it
is setting the file type of a file it is about to receive.

If you want it to handle any other file type, change the 06 (the ProDos
file code for binary files) in both locations to whatever other file
type you want.  (in my case, $A0 for WordPerfect files.)  Save the
changes.  Then whenever you want to handle that file instead of TXT go
to the kermit command mode and SET FILE-TYPE BINARY.

(Of course, if you want to handle binary, or yet another type, you'll
have to change the two locations again.)

(No guarantees, comments welcome)

[e-mail]

[Ed. - Thanks for the report.  It has been added to the .BWR file.]

------------------------------

End of Info-Kermit Digest
*************************
-------
 4-Sep-87 13:18:05-EDT,27813;000000000000
Mail-From: SY.CHRISTINE created at  4-Sep-87 13:17:03
Date: Fri 4 Sep 87 13:17:02-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V6 #18
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 4 Sept. 1987       Volume 6 : Number 18

Today's Topic:
  C-KERMIT -

                               Kermit 0.8(35)
                         Mac Kermit 0.8(35) report
              Experimental C-Kermit 4E(066) Works on SCO Xenix
                    Test C-Kermit Feedback on SCO Xenix
                       C-Kermit 4E(066) on Convex C1
      Experimental Kermit 4E(066) Mostly Works on Gould Powernode 6000
                  More about Experimental Kermit on Gould
                 Trouble with C-Kermit 4E(066) Init File???
                   New xkuker (C-Kermit) Bugs on Pyramid
                        C-Kermit 4E Amiga .BOO File
             C-Kermit 4E(066) on Amiga, and Long Packet Problem
                    4E(066) Long Packet Problem Followup
                       C-Kermit on Pro 350 / Venix V1
        C-Kermit Version 4E(066) Results on Celerity, Pyramid, 3B20
                   Bugfix for C-Kermit 4E(066) on Pyramid
                       C-Kermit 4E fixes for BSD 4.3
                 Problems with C-Kermit 4E(066) on VAX/VMS
           C-Kermit 4E Problems on Tandy 16A/6000 and Arete 1200
                            C-Kermit 4E Feedback
                            C-Kermit Lock Files

----------------------------------------------------------------------

Date: Fri, 7 Aug 87 16:03:11 PDT
From: [e-mail] (Dave Platt)
Subject: Kermit 0.8(35)
Keywords: Macintosh Kermit, C-Kermit

I've tested the Megamax version briefly on my Plus, talking to a 4D(061) on my
Sun 3/52, and it seems to work fine.  I've posted a short note to
comp.sys.mac, reporting that 0.8(35) is now available and relaying your
request for people to complete the 4D(066) port and/or port the whole thing to
MPW or LightSpeed C.

------------------------------

Date: Fri, 14 Aug 87 16:03:11 EDT
From: Ben Cranston <[e-mail]>
Subject: Mac Kermit 0.8(35) report
Keywords: Macintosh Kermit, C-Kermit

Preliminary testing of Mac Kermit 0.8(35) indicates everything functional.
I STILL have to change the Inbound End-Of-Packet character from 13 to 10
(015 to 012) to communicate with one of our hosts, which insists on sending
even parity and terminating output "records" with both a CR and LF.

When I reported this problem over a year ago, we thought the problem was
parity bit related, based on some comments in the Kermit history file.
Based on an accidental observation in our latest testing, it now occurs to
me that there is another explanation.

Scenario one:

Packets from the host end with an even parity CR LF (0215 0012) but Kermit
erroniously thinks the 0215 from the serial port and the 0015 from the
"protocol" menu are not the same character.  Setting 0012 to be the end of
packet character causes the end of packet to be correctly recognized,
as a LF already has even parity and thus needs no added parity bit.

A comment from the history file about "putting SCC into 8 bit mode always
and doing parity ourselves" started us thinking in this direction.

Scenario two:

Packets from the host end with CR LF.  Kermit correctly recognizes CR as the
end of the packet, but incorrectly interprets the LF as the end of another
record.  This empty record somehow confuses the protocol.  Setting LF to be
the end of packet character causes the CR to be interpreted as just one more
data character after the packet but before the end of the record.

In checking out this new Kermit I grabbed a file of test data, downloaded it
to the Mac, uploaded it back, and compared it against the original version.
Unbeknownst to me, the particular file I chose had an explicit linefeed
character embedded in the data at one point.  Somewhere in the
download-upload process this linefeed was changed into a real newline,
creating a one-line discrepancy between the two files.

Now, I'm quite sure the LF -> newline mapping was not happening on the host.
Nor is it a problem with Mac filesystem semantics, as the Mac uses CR and
not LF as its newline character.  If some routine in Kermit is confusing
LF with CRLF it could cause this kind of behavior.

Another interesting observation was that the "retransmit" indicator on the
screen seemed to be incrementing by two.  That is, it would read 1, 3, 5,
7, 9, 11, and so on until the transfer timed out.  Like two records were
going by each time or something...

If anyone can suggest an experiment that would differentiate between these
two scenarios, and wouldn't take massive efforts to perform, I would be
interested in hearing about it...

I do have MPW installed, and have access to Lightspeed.  Conversion from
Megamax might be complicated by the fact that Megamax has 16 bit INTs and
MPW has 32 bit INTs.  I have converted a few simple programs and so have
some experience in the area.  If nobody else takes up the gauntlet I suppose
I could be persuaded to take it on, if only to fix the aforementioned bug...

Ben Cranston <[e-mail]>
Computer Science Center Systems Group
The University of Maryland

[Ed. - There have been numerous complaints over the last couple years that
C-Kermit cannot properly cope with incoming packets that are delimited by
CRLF.  We have never been able to reproduce the problem.  Your descriptions
might help.  Will try to track it down.]

------------------------------

Date: Sun,  9 Aug 87 15:28:56 edt
From: [e-mail] (Jay Mathew Libove)
Subject: Experimental C-Kermit 4E(066) Works on SCO Xenix
Keywords: C-Kermit, Xenix

I brought the experimental sources to my SCO Xenix 2.1.3 system (running on an
IBM PC/AT compatible, made by PCs Limited) and compiled them directly, no
trouble (make xenix).

Jay Libove
Arpa:   [e-mail]    Bitnet: [e-mail]
UUCP:   ...!{seismo, ucbvax, harvard}!andrew.cmu.edu!jl42
UUCP:   ...!{pitt | bellcore} !darth!libove!libove

------------------------------

Date: Tue, 11 Aug 87 23:04:22 PDT
From: [e-mail]
Subject: Test C-Kermit Feedback on SCO Xenix
Keywords: C-Kermit, Xenix

I'm running SCO Xenix 2.2 on a 386, and have (so far) three comments re the
new test version of kermit ...

 1) Why all the wait(0)'s instead of wait((int *)0) as mentioned
    in the comments?  Any machine that has sizeof(int) != sizeof(* int)
    is going to need that typecast, and there's no reason I can think
    of why the code wasn't fixed when the comment was applied.

[Ed. - I wasn't sure if this should apply to all systems, guess it should be
changed as you suggest.]

 2) A couple of files included "file.h" erroneously.  I ifdef'd it out
    for xenix, but I guess it should be omitted for others as well.

[Ed. - This is a horrible problem; no two systems seem to agree about what
is in file.h or where it is.  Notice that other SCO Xenix people did not
report this problem...]

 3) I've included a very quick implementation of modem support for Concord
    2400 bps modems.

Oh, I modified the xenix make to use large model w/out even trying the
default, don't know if that would have worked or not.

Follows are my diffs,

   Jim

[Ed. - Thanks!  Diffs added to XKUKER.BWR for now.]

------------------------------

Date: Wed, 12 Aug 87 14:07 EST
From: Mark B. Johnson <CDTAXW@IRISHMVS>
Subject: C-Kermit 4E(066) on Convex C1
Keywords: C-Kermit, Convex

We got C-Kermit up and running without (so far) any problems on a Convex C1
minisupercomputer running Convex UNIX V6.0.  The make bsd option worked
without change.  I will report any problems as they crop up.

Mark Johnson
Univ of Notre Dame

------------------------------

Date: Mon, 10 Aug 87 17:56:50 MDT
From: Mike Niswonger <[e-mail]>
Subject: Experimental Kermit 4E(066) Mostly Works on Gould Powernode 6000
Keywords: C-Kermit, Gould Powernode 6000

    Just picked up the experimental Kermit and brought it up on a Gould
Powernode 6000 (dual processor) running UTX 2.0.  This system thinks it is
BSD 4.3, so i just made "BSD".  So far everything looks good, but tests are
still incomplete - I'll post a complete report in a couple of days when I have
had a chance to test more options.

    I had to try long packets first.  Everything works fine at 1000 char
packets between MSKermit 2.29C and the new kermit at 9600 baud.  The effective
baudrate was about 6800 baud, or about 71% efficency.  I'll try and find the
optimum baud rate and packet length later this week.

                          Mike

------------------------------

Date: Wed, 12 Aug 87 18:24:37 MDT
From: Mike Niswonger <[e-mail]>
Subject: More about Experimental Kermit on Gould
Keywords: C-Kermit, Gould Powernode 6000

    In continuing my debug on CKermit 4e(066) I found a problem in
trying to send with long packets.  Negotiations look OK, but send packets
go to maximum size without long packets.  Long packets are accepted in the
other (receiving) direction.  Nice for uploads, but . . .

[Ed. - Probably related to "set send packet-length" command, see below.]

    I'll get copies of the log files and send them to you.  During debug
I also noticed a problem with F111 format debugs - sometimes they get a <CR>
in them at the end of the data which causes an overprint on the data when I
send it to the printer.  I'll try and track these down.  Let me know if you
hear of any other bugs.

                  Mike

------------------------------

Date: Tue, 11 Aug 87 14:36:38 CDT
From: [e-mail] (Moore)
Subject: Trouble with C-Kermit 4E(066) Init File???
Keywords: C-Kermit

have you folk heard any complaints about .kermrc being ignored in the new unix
release of kermit 4e(066) 4 aug 87, 4.2bsd?  maybe i'm doing something stupid
(again).

jim

[Ed. - There have been a couple reports of this, but we can't reproduce on
our own 4.2BSD (really Ultrix 2.0) VAX.  Kermit 4E(066) finds the .kermrc
file if it's in the home directory, even if you're cd'd to another directory,
or else in the current directory if there's not .kermrc in your home
directory.  The way the program finds the home directory name has not changed
in many releases (it's just getenv("HOME");).]

------------------------------

Date: Tue, 11 Aug 87 17:00:12 EDT
From: MATTHEWS <[e-mail]>
Subject: New xkuker (C-Kermit) Bugs on Pyramid
Keywords: C-Kermit, Pyramid

I have found two problems so far with the newest version 4E(066) of kermit.
Here is what happens when you try to run it on Pyramids version of UNIX (OSx).

    Script started on Sun Aug  9 23:56:57 1987
    udccpyr1% cd
    udccpyr1% cat .kermrc
    echo
    echo set file type BINARY
    set file type BINARY
    echo set file names LITERAL
    set file names LITERAL
    echo
    set prompt "C-Kermit@pyr1>"
    udccpyr1% cd /usr/tmp/kermit
    udccpyr1% ./wermit

    set file type BINARY
    set file names LITERAL

    C-Kermit, 4E(066) 4 Aug 87, 4.2 BSD
    Type ? for help

    set file type binary 8
    bad
    ?Invalid - bad

    Fatal: Kermit command error in background execution
    udccpyr1%
    script done on Sun Aug  9 23:58:00 1987

I get no prompt or anything, it just exits with this error message.  It
appears as though it thinks I want to run it in the background.  I compiled
kermit the same exact way with the "bsd" flag on both machines and it does
different things on each one.

[Ed. - I noticed some similar behavior on a system running 2.9BSD.  The problem
can be traced to the conint() function in xkutio.c, where the program attempts
to determine whether it's running in the background by testing some signals,
etc.  Apparently, there is no universally valid way (at least none that I know
of) for doing this, so the same test will give different results on different
systems.  If Kermit thinks it's running in the background, then errors in
'take' files (including .kermrc) are fatal.  Unix wizards are invited to take a
look at the conint() function and suggest a better way of checking for
background operation.]

The second minor bug that I discovered when trying to run kermit on our Vax
8650 running 4.3 BSD is that SET PROMPT isn't working correctly.  A command in
a .kermrc file such as "set prompt C-Kermit@vax1>" doesn't change the prompt.
It appears to work okay when you type it at command line.

[Ed. - Yes, that's a bug.  It'll have to be fixed.  See below.]

Sorry I can't be specific to where exactly the problems are within the source;
I only kept it on the machines long enough to compile it.  I have a 1000 block
quota.

                    John Matthews

------------------------------

Date: Sat, 29 Aug 87 15:37 EST
From: <[e-mail]> (Rick Pim)
Subject: C-Kermit 4E Amiga .BOO File
Keywords: C-Kermit, Amiga

        The Aug 7 info-kermit digest mentioned a new release of C-Kermit
for, amongst other things, the Amiga. According to the directory I looked
at of cki* *, the BOO file is new. The digest requested comments/etc, so I
ordered the BOO file and decoded it today. According to the header once
it's running, the version is 4D. It has at least one of the same bugs as 4D
(parity does not work).

[Ed. - Right, we don't have an Amiga .BOO file based on the new version yet.
We were hoping somebody would make one.  See next message.]

------------------------------

Date: Wed, 12 Aug 87 10:25:42 pdt
From: cit-vax!ametek![e-mail] (Steve Walton)
Subject: C-Kermit 4E(066) on Amiga, and Long Packet Problem
Keywords: C-Kermit, Amiga

Well, I grabbed C-Kermit 4E(066) from CU20B, and have been able to compile and
link a running version on my Amiga using Manx Aztec C V3.40b.  In the process,
I added the appropriate include files and the DOSFH and FILENO macros for Manx
C to ckiutl.c and ckitio.c; diffs will follow shortly.  (One thing which was
easy: parity can be ignored in ttinl(), since the Amiga's serial.device
handles it itself, and passes characters to Kermit with the parity bit already
stripped.)

However, I have hit what appears to be a major bug: 4E(066) will not use long
packets when talking to itself.  I have built the BSD version of 4E(066) on
our 4.3BSD 780 using "make bsd", and tested it in a loop mode by phoning the
machine from one of its own dialout lines.  After a "set send packet-len 150"
and "set receive packet-len 150" on both ends, it does not use long packets,
but rather the standard ones.  This also happens when connected to the 780
from my Amiga at home.

One minor bug, easily fixed: the help information for set send packet-len
still says that the maximum packet length is 94.

Stephen Walton, [e-mail]
Ametek Computer Research Div.
610 N. Santa Anita Ave.
Arcadia, CA 91006 USA
818-445-6811

[Ed. - See next message.]

------------------------------

Date: Fri, 14 Aug 87 14:28:04 pdt
From: Steve Walton  <cit-vax!ametek![e-mail]>
Subject: 4E(066) Long Packet Problem Followup
Keywords: C-Kermit

After reading the docs for 4E(066) (RTFM, right?) I tested it again talking to
itself on my 4.3BSD 780.  This time, the only set command I did was a "set
receive packet-length 300" on the receiver.  This time, long packets were
used.  If I also naively do a "set send packet-length 300" on the sender,
short packets are used.  I think this is still a bug, but not quite the one
I'd reported previously.

[Ed. - "set send packet-length" is used to override negotiations.  Apparently
it doth override them too much.  This will have to be fixed.]

------------------------------

Date: Sat, 22 Aug 87 14:21:56 cst
From: ihnp4!sask![e-mail] (Irving Reid)
Subject: C-Kermit on Pro 350 / Venix V1
Keywords: C-Kermit, Venix, Pro-3xx

Is anyone else running C-Kermit on Venix V1?  I'm having all sorts of
problems - dial scripts always crash, crashes at >300 baud, etc.  I'm
dragging down the new experimental version to see if it gets better; I'll
let the world know how that turns out.

[Ed. - We had Venix V1 systems here once, but no longer, so were unable
to test the new C-Kermit on them.  Anybody?]

As an aside, for those of us with limited bandwidth to the outside world
would it be possible for new versions to come with a concise list of which
files have changed, so we don't need to take the whole thing?  Better yet,
since many people in the Unix world have Larry Wall's "patch" program, new
versions could be distributed as diff's against the old; this should save
lots of network time for such a large program.

[Ed. - Desirable, but in this case, all the files changed, and in most cases
the diffs would be larger than the original files.]

 - irving -   ([e-mail] or {alberta, ihnp4, utcsri}!sask!reid)

"Warning: don't use braces, tildes, circumflexes or double quotes as
delimiters - chaos will result"

------------------------------

Date: Tue, 25 Aug 87 16:08:53 PDT
From: Mick Laver (ACC Microconsulting) <[e-mail]>
Subject: C-Kermit Version 4E(066) Results on Celerity, Pyramid, 3B20
Keywords: C-Kermit, Celerity, Pyramid, ATT 3B20

The new C-Kermit compiled succesfully under BSD 4.3 systems on Vaxes and a
Celerity, under Sys V on a 3B20, and under the Pyramid 90X's "dual-universe"
bsd4.2/sys5.  Also compiled under VMS 4.5, but I didn't test it there other to
determine that it compiled and ran.

Results:

Worked ok on all 4.3 and Sys V systems (see below).

Did NOT work on the Pyramid.  While it would compile and run, if you said
"send file" or "receive" it would go back to the C-Kermit prompt.  Command
line send or receive just went back to system prompt.  One of our systems
programmers looked at it briefly and couldn't find the problem.  He said he'd
look further and I'll send a follow-up if he gets anywhere.

[Ed. - See next message for Pyramid fix.]

Binary tranfer problem: Our 4.3 VAX C-Kermit would send binaries incorrectly
if no parity was used with extended packets. If 8th bit prefixing was used
(set parity space on MS-DOS Kermit 2.29b) the files would go OK.  When
"normal" sized packets were used binary xfer worked fine either way.

[Ed. - This one will have to be checked...]

   Mick Laver, ACC         Internet:  [e-mail]
   C-010  U.C.San Diego    UUCP:     ...!sdcsvax!sdcc3!zz1ml
   La Jolla, CA.92093      Ph:                [phone]

------------------------------

Date: Tue, 25 Aug 87 00:43:07 EDT
From: Paul Placeway <[e-mail]>
Subject: Bugfix for C-Kermit 4E(066) on Pyramid
Keywords: C-Kermit, Pyramid

I ftp-ed the sources for beta 4E from cu20b, and had a bit of a problem making
it work on a Pyramid 98x under the BSD universe.  After poking around a bit, I
discovered that the ttpkt() routine was failing when everything seemed fine,
so I looked hard at the code and discovered what looks like a place where
someone forgot to flesh out an #ifdef.  After changing ckutio.c in the
following way, C-Kermit seems to work fine.  Here are my diffs...

 *** ckutio.c.orig    Thu Aug 20 11:43:52 1987
     ckutio.c    Mon Aug 24 23:54:58 1987
 ***************
 *** 912,917
       ttflui();                /* Flush any pending input */
       return(0);
   #endif /* bsd4 */
   #endif /* myread */
   #endif /* not uxiii */

     912,920
       ttflui();                /* Flush any pending input */
       return(0);
   #endif /* bsd4 */
 + #else /* myread */
 +     ttflui();                /* Flush any pending input */
 +     return(0);
   #endif /* myread */
   #endif /* not uxiii */

            Paul Placeway
        Department of Computer and Information Science
    SNail:    The Ohio State University
        2036 Neil Ave. Columbus OH USA 43210-1277
    ARPA:    paul@ohio-state.{arpa,csnet}
    (soon):    [e-mail]
    UUCP:    ...!cbosgd!osu-eddie!paul
    (soon): ...!cbosgd!cis.ohio-state.edu!paul

[Ed. - Many thanks!]

------------------------------

From: Markku Toijala <mcvax!kolvi![e-mail]>
Date: Wed, 26 Aug 87 14:52:48 EET DST
Subject: C-Kermit 4E fixes for BSD 4.3
Keywords: C-Kermit

I have been setting up C-kermit 4E on microvax II running BSD 4.3.  Here are
the modifications I found necessary:

1) Add seteuid/seteguid to allow (remote) shell commands when using
   csh as login shell.  In 4.3 it seems that csh checks for uid/gid
   before starting itself.  Effects can be seen when you run sgid to give
   only kermit access to an outgoing line.

[Ed. - This area wasn't addressed by 4E(066); older releases are the same.]

2) KERMRC was defined only in ckuusr.c, but also ckuus2.c used it to
   get init filename -> you did not get indication of it with "show para".
   Moved the stuff to ckuusr.h

[Ed. - Right you are, "show" doesn't list the init file name.  This will be
fixed.]

3) Moved setting of default prompt to take place before reading .kermrc.
   Now you can have "set prompt" command in it ...

[Ed. - Right again.]

4) Removed . from Extendend-length packets ... - string.

There may still be something wrong with long-packets, but i have not had time
to look at that yet.

[Ed. - Yes, see above.]

Markku Toijala                         !   UUCP:     kolvi!mto
Helsinki University of Technology      !   Internet: [e-mail]
Otakaari 5 A                           !   EARN:     [e-mail]
SF-02150 Espoo,  Finland               !   tel:      [phone]

[Ed. - Many thanks!  Diffs added to XKUKER.BWR.]

------------------------------

Date: 27 Aug 87 10:55:00 EST
From: "SRLVX2::KABERLINE" <kaberline%srlvx2.decnet@ford-vax>
Subject: Problems with C-Kermit 4E(066) on VAX/VMS
Keywords: C-Kermit, VAX/VMS

Recently downloaded the new experimental new release of C-Kermit, version
4E(066).  I compiled and tested it on both systems I have access to, a
Masscomp (unix), and a VAX 8600 running VMS V4.5.  I am writing this to report
a few minor problem I've noticed, mostly when running under VMS:

1. During the building of wermit under VMS, I got an error
   message while linking:

    %LINK-W-NUDFSYMS, 1 undefined symbol:
    %LINK-I-UDFSYM,     SYSCLEANUP
    %LINK-W-USEUNDEF, undefined symbol SYSCLEANUP referenced
        in psect $CODE offset %X00000B6E
        in module CKUUSR file CKUUSR.OBJ;1

[Ed. - Right, a syscleanup() function should be added to CKVTIO.C.  It doesn't
necessarily have to do anything...]

2. Under VMS, the "cwd" command does not appear to work?

[Ed. - This is done by the function system(), defined in CKVFIO.C, called
with the argument PWDCMD, which is apparently undefined for VMS.  Oops!]

3. A "dir" command is *NOT* equivalent to a "dir *.*" command under
   VMS;  both commands produce identical output on the Masscomp.

4. Finally, I can't seem to get the long packets to work.  I
   set the send and/or receive packet size on both ends, then
   try to send a file from/to VMS/Unix.  The files transfer OK,
   but when I then do a "show parameter" command, the packet
   sizes displayed is 94??

[Ed. - You should avoid "set send packet-length" and only use
"set receive packet-length" on the receiving end, till "set send
packet-length" is fixed.]

Haven't noticed anything else yet, but I'll keep experimenting and report
anything else I might discover.

            Thanks!

            Steven Kaberline    (Kaberline@ford-vax)
            Ford Motor Company
            Scientific Research Labs, Rm. S-3061
            P. O. Box 2053
            Dearborn, MI  48121   USA
            [phone]

------------------------------

Date: Thu, 3 Sep 87 08:26:14 EDT
From: [e-mail]
Subject: C-Kermit 4E Problems on Tandy 16A/6000 and Arete 1200
Keywords: C-Kermit, Tandy 16A/6000, Arete 1200

I've tried out the new 4E(066) release on a Tandy 16A/6000 and Arete 1200 under
System V.2.  One problem I've noticed is that if you try to get the status
of the transfer, as soon as you type Cntrl A, the transmission begins to
send %T's, and eventually times out.  This was during file transmissions
between the Arete and MTS Kermit.  It was also reproducible between the
Arete and Tandy machines.

[Ed. - This sounds like something pretty specific to your machine; Ctrl-A
status reports work ok on the machines we've tested.  I hope you can track it
down.]

Another had to do with setting long packets.  If I set the Tandy end to send
at a length of 900, and the Arete end to receive at 900, when I put the Tandy
end into server mode, the transmission begins, but terminates immediately with
an OK.  If I only put the receive end at a length of 900, things go fine. (900
is just an arbitrary number I picked) .

[Ed. - Right, see above.]

The program compiled cleanly on both machines, except that on the Tandy end
(running under Xenix 3.1.2), I had to include <sys/types.h> for one of the
files in which void is used.

------------------------------

Date: Mon, 17 Aug 87 21:45 MDT
From: <[e-mail]> (Joe Doupnik)
Subject: C-Kermit 4E Feedback
Keywords: C-Kermit, ATT Unix PC

A couple of comments on the new test C Kermit:

1. signal() returns type "int" on my Unix PC running AT&T sys5r3, just like
everyone else, yet the conditionals in the code specify "void" for only
sys5r3. So here we have an exception to the cast in steel Standard Edition of
Unix from the horse's mouth. Btw, release 3 here means 3.0 whereas in-house at
AT&T they are up to 3.5 at last reading.

[Ed. - Oh, so sys5r3 is not the same everywhere...  Well, since the type cast
for signal() is the only difference in Kermit between sys5r3 and sys5r2 (or,
for that matter Sys3), then use "make sys3" or "make sys5" (which is an alias
for "make sys3").]

2. The file statistics display indicates files are always transferred with
type 1 block check, even though I have type 3 set in both .rkermit and on the
remote machine and sometimes set it that way by hand in C Kermit.

[Ed. - Will investigate this.]

3. When the dust settles Lint (no pun intended) ought to be run across the
code to pick up the loose ends. My Lattice C compiler on the AT machine is
more picky than the standard Unix compilers and lets me know to do better next
time, sigh.  You'd think it wanted us to be (gag) Pascal programmers.  On the
other hand, you may have done so and we are seeing Unix vs ANSI in action.
Can't win either way.

[Ed. - No, I was scared to Lint it, but I will.]

4. Otherwise, it works just great!  Throughput is way up.  Whereas the
previous release yielded about 10-12Kbaud across STARLAN to my AT this version
indicates 18+Kb the same way.  That's with 1000 byte packets.

        Regards,
        Joe D.

------------------------------

From: [e-mail] (Stan Barber)
Subject: C-Kermit Lock Files
Date: 20 Aug 87 21:26:17 GMT
Keywords: C-Kermit, Unix Lock Files

I should point out that C-Kermit(041) does handle lock files correctly under
BSD4.3 with the 4.3UUCP locking structure.  This creates a lock directory
(/usr/spool/uucp/LCK) that is publically writable and each program (except
kermit) using the locking protocol is smart enough to test for dead locks
(coming from programs that aborted and did not remove its lock).

Stan

[Ed. - Presumably, this is also true for 4E?]

------------------------------

End of Info-Kermit Digest
*************************
-------
10-Sep-87 16:54:08-EDT,27020;000000000000
Mail-From: SY.FDC created at 10-Sep-87 16:53:23
Date: Thu 10 Sep 87 16:53:23-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V6 #19
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 10 Sep 1987       Volume 6 : Number 19

Today's Topics:
                        New Copy of MSTIBM.BOO
              Documentation for MS-Kermit 2.29C and 2.30
                Proposed Extensions to Kermit Protocol
               Update to UCSD p-System Kermit for Terak
                       C-Kermit on the Unix PC
                   4E(066) on NCR Tower Works Fine
                      Sperry 1100 Kermit Retires
                     More on Multiple CDC Kermits
              Kermit 80 Version 4.08 (pre-release) Files
                     EBCDIC and ASCII Definitions
                    Transferring WordPerfect Files
                              MSBPCT.PAS
        7171 Causes CMS Kermit Problems When Flow Control Used
                    Need HP150 Kermit on diskette
                        Kermit for a Bondwell?
              VMS Kermit version 3.2.076 STATUS Command

----------------------------------------------------------------------

Date: Wed 2 Sep 87 10:09:44-EDT
From: Christine Gianone <[e-mail]>
Subject: New Copy of MSTIBM.BOO
Keywords: MS-DOS Kermit

Some people were experiencing problems downloading the new KER:MSTIBM.BOO
(2.29C, 16 Aug 87) file.  There is now a new copy, same name, which we have
downloaded and un-BOO'd with no difficulties.  No release changes have been
made to this version.

------------------------------

Date: Thu 10 Sept 87 15:36 EDT
From: Frank da Cruz <[e-mail]>
Subject: Documentation for MS-Kermit 2.29C and 2.30
Keywords: MS-Kermit 2.29C

In response to the many complaints and questions about the latest MS-Kermit
pre-release: Some of the more obvious incompatibilites between 2.29B and
2.29C (which is pretty much what 2.30 will look like) are:

   - SET KEY and SHOW KEY commands use different key identifications and
     syntax.  This is a big one.

   - CLEAR command now means clear serial port buffer rather than clear key
     and macro definitions.  Key and macro definition string space is now
     garbage collected, so a CLEAR command for them is no longer necessary.

   - CLRINP command is gone (replaced by CLEAR).

   - Numbers of the form \nnn now default to decimal rather that octal.

   - "LOG filespec" replaced by "LOG SESSION filespec" and "LOG PACKET
     filespec".

   - The LOCAL command prefix has been removed from 2.30.

Most of these incompatibilities will break your MSKERMIT.INI or other command
or script files, but each has a rationale.  A draft version of the manual for
2.30 (which applies to 2.29C as well) has just been completed.  It's in
KER:MST29C.DOC (SCRIBE text formatter source in KER:MST29C.MSS) on CU20B and in
MT29C * on CUVMA for KERMSRV access.  Suggestions for the final draft are most
welcome.

------------------------------

Date: 14th August 1987
From: Chris Kennington ([e-mail])
Subject: Proposed Extensions to Kermit Protocol
Keywords: Kermit Protocol Extensions

            I am currently implementing a Kermit facility to go into a
private ViewData system.  This is a commercial contract, so what the
customer says he needs has to be supplied.  We may end up with something
which ought to be called "Kermit compatible" rather than Kermit, but that's
life.  The environment is MSDOS on a micro; hence the multithreading nature
of the code, which I discussed with you a few months ago.

            There are two specific things which the user requires beyond the
normal Kermit protocol.  He wants other parts of the host program to be able
to send messages (single-liners) to the terminal's screen at any time during
a file transfer; and he wants the terminal to flip automatically from
connect into send or receive mode any time it starts to receive a I/S/R
packet from the host (so that the transfer can be fully initiated from the
host end, the converse of server operation).

            I would like to fit these in in as clean a way as possible.  My
current plan is as follows, but I should be glad of comments, particularly
if you either think there is a better way or have plans for extension of the
protocol in either of these directions.
                                                Chris K.

MESSAGES TO SCREEN

            This must be divided into two cases; message going in the same
direction as the data, and message going against the data.

            For the first case, I propose to define a new type of packet
which can be interleaved with the data-packets.  Rather than choose a new
letter I propose to reuse the generic message (G-M) codes.  Normal rules for
sequencing would apply.

            For the second case, I propose just to put data into the next
ACK, starting the data with a blank so that it cannot be confused with a
cancel-transmission request.

            The first suggestion is not backwards-compatible unless it is
counted as a new "capas".  I would like to be able to negotiate it, so that
the same program could be used to work both standard Kermits and the Kermit
facility in this customer's integrated ViewData terminal program.

            The second ought to be transparent to existing Kermits.

AUTOMATIC TERMINAL RESPONSE

            I propose that, whenever in connect mode, the terminal Kermit
detect any SOH received, check to see whether the next few characters are
compatible with the header of a Kermit I, S or R packet, and if so flip into
the appropriate transfer mode.  At the end of the transfer it would flip
straight back to Connect mode.  The rationale is that, in a ViewData system,
the user always feels that he is working the ViewData host rather than a
local micro, so he wants to have host-commands (sent in terminal mode)
executed forthwith.

            The ViewData screen-driving protocol does not make use of SOH as
a control character as far as I know.

            When working to a normal host Kermit, this code would never be
triggered except by some unexpected binary garbage.

[Ed. (Frank) - Your ideas sound reasonable.  We considered the idea of
screen messages when first designing the protocol, but didn't include them
because there could be no guarantee that the user would be there to read
them.

You can put anything in an ACK you want, so long as you start it with a
space, and it won't interfere with existing Kermits.  Let's say that if an
ACK to a data packet contains text starting with space, then the text is to
be displayed on the screen (or added to the user's mailbox, transaction log,
or whatever), or can be ignored altogether (as existing Kermits will do).

For messages in the same direction as the data, I'd actually recommend a new
packet type, "M", rather than a G packet of subtype M, because a G packet
only occurs at the start of a transaction.  The use of such a packet would
indeed have to be negotiated.  Let's provisionally assign capability bit #6
for this.  This would mean that we overflow into the second capability word,
and have to set the low order bit in the first one to indicate that this has
happened.  Obviously, M packets will not be sent unless both Kermits set
capability bit #6 in the negotiation phase.  Does anyone have any serious
objections to this protocol extension?  Like all other extensions, it's
compatible with existing versions, because it won't be used unless both
sides agree.

Automatically flipping into protocol mode when a packet arrives during connect
is an implementation decision, but probably there should be a command to defeat
this.  Not only must you worry about noisy lines, but also those cases where
the user might actually display a file that contains examples of Kermit
packets, and also for debugging purposes.]

------------------------------

Date: 19-AUG-1987 11:11:20
From: Nick Rothwell, University of Edinburgh.
Via: [e-mail]
Subject: Update to UCSD p-System Kermit for Terak

   In the following you will find two of the pieces of UCSD pSystem Kermit
which I've altered to handle text files properly - binary file transfer is
right out because, apart from anything else, the pSystem II.0 BIOS can't
read/write binary files byte by byte correctly, so that's a non-starter.

   I originally fixed the bug that the receive routines expected the sequence
'#M#J' to occur together, so a '#M' at the end of a message followed by '#J' at
the start of the next got things confused. The final fix is to totally ignore
all '#'-codes except the sequence '#M#J' (whether adjacent or not), so as to
ensure reliable text file transfer *without* confusing the filing system with
unexpected control characters.

   The changes are to RECSW.TEXT and KERMIT.TEXT which are part of the
concatenated source [.UCT]UCTERAK.PAS. Diff listings for these two files are
below.

Nick Rothwell,   Laboratory for Foundations of Computer Science,
                 University of Edinburgh.
                 ARPA:    nick%{cstvax,itspna}[e-mail]
                 JANET:   [e-mail].{cstvax,itspna}
                 UUCP:    <Atlantic Ocean>!mcvax!ukc!{cstvax,itspna}!nick

[Ed. - Many thanks, Nick.  Your changes have been placed in UCTERAK.BWR.]

------------------------------

Date: Sat, 5 Sep 87 18:06:19 EDT
From: David Herron E-Mail Hack <[e-mail]>
Subject: C-Kermit on the Unix PC
Keywords: C-Kermit, Unix PC

Joe Doupnik of USU.BITNET says "signal() returns type 'int' on my Unix PC
running AT&T sys5r3 ..."

He's getting confused over the numbering scheme(s) for SysV's.

The SysV on the Unix PC is NOT the same SysV as the mainstream that is
currently up to SysVr3.1 (i.e. a little past SysVr3).  The SysV there
started as Convergent's port of SysVr1 (or r0, since they hadn't subdivided
SysX's into "releases" at that time) ... This port was different from the
standard SysV of the time (for instance, it had full-fledged virtual memory
... something which didn't get into the mainstream SysV until one of the
sub-releases of SysVr2).

The current version of Unix PC SysV is 3.5.1.  It has had some SysVr2
features tossed in and eventually may be re-integrated with the mainstream
versions, but is still a different version of Unix.

Hope this clears up some confusion -- you may want to put these remarks into
a README of some sort in the CKermit distribution.

BTW, some people here had fixed up a C-Kermit which worked well with the Unix
PC's, but they didn't think about sending in their code.  I'm going to point
them at this experimental version and get them to re-do their stuff for this
version... and by-golly, I think they'll send in their stuff to y'all this
time around too ... :-)

------------------------------

Date: Sat, 5 Sep 87 19:00:39 edt
From: [e-mail]
Subject: 4E(066) on NCR Tower Works Fine
Keywords: C-Kermit, NCR Tower

I sure am glad we're back in touch with Info-Kermit, here at the TECNET
project at Clemson University.  (Due to network problems, we had been
offline for more than a year.)  As soon as I saw (in the latest digest) that
4E(066) had long packets, I FTPed it from CU20B, ran the "make sys3" on our
NCR Tower 32 running NCR's Tower O.S.  version 3.something (flawless "make,"
by the way), and then started testing.  I'm happy to report that it works
just fine (except for the "too powerful" "set send packet-length" command as
previously reported in the Digest), and it even cleared up a *long*-standing
problem we've had with using it to upload via TELENET and even parity to the
Tower 32, a problem whose source we were never able to pinpoint (Kermit,
Tower, or TELENET?) despite a huge number of hours of debugging time.

Keep up the great work, froggers!

-- Larry Afrin
   TECNET Project
   Dept. of Computer Science
   Clemson University
   [e-mail]

------------------------------

Date: Tue 1 Sep 87 13:42:01-EDT
From: Frank da Cruz <[e-mail]>
Subject: Sperry 1100 Kermit Retires
Keywords: Sperry 1100 Kermit

The University of Wisconsin is retiring its Sperry 1100, and Paul Stevens,
the author of Sperry 1100 Kermit, will no longer be able to actively
support the program.  Is anyone out there willing to take over?  Volunteers
please send mail to [e-mail], or write to the Kermit
Distribution address (network-connected volunteers preferred).  Thanks to
Paul for all his contributions to Kermit culture over the years!

------------------------------

Date: Thu, 11 Dec 86 14:02:15 cst
From: [e-mail] (Jim Knutson)
Subject: More on Multiple CDC Kermits
Keywords: CDC Kermit

RE: [Steve Roseman <[e-mail]>: More on Multiple CDC Kermits]

Personally, I feel that the CDC versions of kermit for the version I wrote
(the fortan version), should probably be split into seperate versions.  The
code for trying to manage several operating systems and approximately 5
different character sets is horrendous.  I would be in favor of ripping out
all non-nos code (that means NOS/BE and, sniff, UT-2D).  A NOS/VE version
will probably have to be done seperately because of the word size
differences and all.  I have not had many calls from NOS/BE sites lately and
very few calls from NOS/VE sites as well.

However, I must say that I really haven't been maintaining the Cyber version
of Kermit for quite a while now so perhaps my suggestions should be tempered
by that.

------------------------------

Date: Sun, 23 Aug 1987  15:02 MDT
From: Keith Petersen <[e-mail]>
Subject: Kermit 80 Version 4.08 (pre-release) Files
Keywords: CP/M Kermit

With great expectations I today got the KER:CX*.* files for the CP/M Kermit
4.08.  Imagine my surprise to find that all the ASM modules which previously
had been individual files for ease in editing were now all together in one
HUGE 780k file!!!

The ONLY reason that LASM was used in the first place, instead of the stock
CP/M assembler, was so the pseudo instruction LINK could be used at the end
of each module.

The present form of the source code is, in my opinion, unusable.  Bertil has
removed ALL tabs from the source, making it even larger.  His reasoning was
that people were messing up the source by getting it through hosts that
change a tab to a single space.  This is probably true, but the file is too
large to handle.  It must be broken down into its individual modules again
to make it manageable by potential users.  I can't even edit it on my CP/M
DDDS 1.2 megabyte floppy system.

  Keith

[Ed. - Our fault.  We had to crunch the files together because of a severe
space problem on our tapes.  As you know, file marks are expensive.  The
idea is that once some CP/M aficionados like yourself get a chance to try it
out and bless it, it can replace the old CP/M Kermit files, KER:CP4*.*, and
then there will be plenty of room to store the files separately.  For now,
and for FTP access only, the .ASM source files are available separately as
K7:CP*.ASM on CU20B (note, K7).  Please take them and try them out, and send
any comments to Info-Kermit@CU20B, whence they will be relayed to the
author, Bertil Schou at Loughborough University in England, who is anxious
for feedback.  By the way, the files were joined together using a simple
Unix Bourne shell script, a copy of which is in K7:JOIN.SH.  They were
unjoined with a C program, which is in K7:UNJOIN.C.]

------------------------------

Date: Mon, 24 Aug 1987 10:15:10 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: EBCDIC and ASCII Definitions
Keywords: EBCDIC, ASCII, Multinational Character Sets

EBCDIC definition from the "Principles of operations" IBM manual only covers
English characters and is old story.

There is now an ISO 8859 definition for EBCDIC. It extends the code to other
languages needs.  Because you can imagine all languages don't fit in a 256
set, the standard is split into mutltiple definitions of which the most
widely used is ISO 8859/1 (Latin Group 1). It is a superset of the former
EBCDIC, but shows some trouble with the former loose definition of brackets,
vertical bar and exclamation mark.

IBM has started using ISO 8859/1 with its so-called table 500.  They have a
3274 RPQ 7L0577 and various peripheral support for it.

ASCII has its own ISO extended definition(s?) too, but I'm sorry not to know
the number.  However I can say IBM now started using it in an alternate
codes definition for its new PS/2 microcomputers series.  They put it a name
of their own blend: "Code page 850".

So, if anyone does not know what to do with undefined EBCDIC and ASCII
codes, here is the answer to increase a program's usability by a factor.

These standards are probably not well known in America, because of little
need, but it's relieving that IBM now accepts international standards and
uses its position to promote them.

[Ed. - 7-bit ASCII is ANSI standard X3.4 and ISO 646 and CCITT T.50.
ANSI X3.32 specifies graphic renditions for control characters.
ANSI X3.41 and ISO 2022 give 8-bit code extension techniques for ASCII.
ANSI X3.134.1 & ISO 4873 specify an 8-bit code for information interchange.
ANSI X3.134.2 specifies an 8-bit ASCII multilingual character set.
ISO 6937 specifies coded character sets for text communication.
See discussion about Swedish character sets in Info-Kermit V5 #1, 14 Jul 86.]

------------------------------

Date: Wed, 26 Aug 87 19:59 CDT
From: Dave Bell - ACADEMIC CONSULTANT (U. of Winnipeg) <UOWDJB@UOFMCC>
Subject: Transferring WordPerfect Files
Keywords: WordPerfect

I'm having problems transferring a WordPerfect file.  The file I'm trying to
transfer (PC to a VAX) contains the WordPerfect document plus the printer
ESC codes.  When I try to Kermit it across I get the following error from
the VAX Kermit:

  %KERMIT32-E-REC-TO-BIG  Record to big for kermits internal buffer.

Can anybody help with this, as I'm a novice user of Kermit I'd appreciate
any help I could get.  Thanks in advance.

David Bell
Academic Consultant
Computer Services

E-mail:  [e-mail]
V-mail:  204/786-9494
S-mail:  Computer Services,
         The University of Winnipeg,
         515 Portage Avenue,
         Winnipeg, Manitoba,
         Canada  R3B 2E9

[Ed. - Most likely, Wordperfect is delimiting lines with special codes,
rather than CRLFs, so that the VAX does not recognize the intended lines as
separate records.  Rather, it sees them all as one very long record, which
causes its record buffer to overflow.  Unfortunately, VMS Kermit doesn't
provide a mechanism to expand the buffer size.  Workarounds would be (a)
transfer it as a binary file, or (b) translate to regular ASCII text before
transmission.]

------------------------------

Date: 30 Aug 1987 20:58-CDT
From: [e-mail]
Subject: MSBPCT.PAS
Keywords: MSBPCT, .BOO Files

After I read about the improved performance of MSBPCT.PAS (compared to
MSBPCT.BAS) I down-loaded this file from Columbia and tried to use it.  My
compiler gave 33 warnings and 50 errors.  I am using a MicroSoft v3.11
compiler which is essentially a UCSD compiler with system enhancment.
Additionally, I have modified the BEGXQQ module (specifically the DOSXQQ)
routines to allow full use of the MS-DOS v3.xx function requests and full
access to registers.  This has not presented any problems when modifying and
recompiling programs created prior to making the mods.

I assume that this program was written for turbo-pascal since it is not
compatible with either "standard" or UCSD PASCAL (yes - there are switches
which can be entered on the command line to make the MicroSoft PASCAL
compiler act like a less capable compiler).

If anyone knows a source for a public domaine turbo compiler, I would
appreciate pointers.  Since I mostly program in assembly and turn to PASCAL
only when string manipulation is too complex or the program is exteemly long
I will not spend my money on a turbo compliler.

Although I realize there may be some who disagree with me, I suggest that any
future postings in PASCAL be more generic in nature.

Al Holecek
[e-mail]

[Ed. - We can't discourage people from writing in Turbo Pascal -- it's fast,
cheap, and a lot of people have it.  Microsoft or IBM Pascal may be more
standard, but it's less common in the world due to price.  Anyway, there are
versions of MSBPCT also written in Assembler and C.  The C version is also
available in .BOO file form, so you don't need a C compiler to run it, just
MSBPCT.BAS to translate it to .EXE form (and then you don't need MSBPCT.BAS
any more.]

------------------------------

Date: Mon, 31 Aug 87 11:09:50 CST
From: Mike Sorsen <[e-mail]>
Subject: 7171 Causes CMS Kermit Problems When Flow Control Used
Keywords: CMS Kermit, 7171, Yale IUP

There is a bug in the 7171 that causes CMS Kermit file transfers to abort in
the middle of a SEND after a large number of retries.  The symptoms are that
during a SEND by CMS Kermit through a 7171 CMS Kermit violates the Kermit
protocol by retransmitting a packet before other Kermit can respond when
XON/XOFF flow control was used by the receiver or when XON/XOFF flow control
was used by other hardware in between the 7171 and the receiver.

This bug was observed using CMS KERMIT 3.1 running under VM/SP 3.1 (PUT 8409
SLU 311) through a 7171 at EC A31864 to MS-DOS Kermit version 2.29b.

I have not done any testing with 4994s or Series/1 boxes running the
Yale IUP. They provide the same function as the 7171 for an IBM host.

The sequence of events is this:

CMS Kermit sends a packet using transparent write/read.  The receiver or
other hardware in between the 7171 and the receiver sends a pacing stop
(XOFF) and then a pacing start (XON) to the 7171 while the packet is being
sent by the 7171. The 7171 performs the pacing, but when the transparent
write part of the transparent write/read is complete it ends the transparent
read prematurely, returning X'93' (XOFF) to Kermit as the reply to the
packet sent out.  CMS Kermit rejects this and retransmits the packet, which
causes a breakdown of the Kermit protocol. The breakdown occurs because the
recieving Kermit usually starts transmitting an ack to CMS Kermit while the
packet is being retransmitted.

I am currently chasing this problem though the IBM support structure, but I
doubt that they will issue a new EC for this problem.

Circumventions:

Set the 7171 flags so that XOFF is not a valid termination of a transparent
read. See page 4-20 of 'IBM 7171 Reference Manual and Programming Guide',
IBM publication number GA27-0021.  This has been tested at our site and
found to circumvent the bug even though the XOFFs are being transmitted
during the transparent write part of the transparent write/read order and
this flag concerns the transparent read part of the order.

or

Change the CMS Kermit datastream so that CMS Kermit uses a transparent write
order instead of a transparent write/read order.  The CMS Kermit code is
written to allow for either order in the write datastream. The byte at label
WRRD (X'128E' in my assembly) should be changed from X'05' to X'00'.  I have
not tested this circumvention.

Mike Sorsen <SORSEN@WUVMD> or <[e-mail]>
Computer Services Systems Group - Campus Box 1152
Washington University - St. Louis, Missouri 63130
Phone: [phone]

[Ed. - Thanks for the report Mike.  This has been added to the CMSKERM.BWR
file.]

------------------------------

Date: 2 Sep 87 00:02:33 GMT
From: sri-unix![e-mail] (Susan E. Cole)
Subject: Need HP150 Kermit on diskette
Keywords: HP150 Kermit

I am trying to help someone who has an HP150 obtain a copy of Kermit on a 3
1/2" disk in a format the HP150 can read.  The person says she has no
compilers or assemblers so we can't download source code and put the program
together on the 150.

So -- does anyone know how she can get it?

Thanks.
Susan Cole
usenet: !hplabs!sri-unix!cole
ARPA:   [e-mail]

[Ed. - A popular request.  Any volunteers?  For that matter, are there any
volunteers to distribute ANY versions of Kermit on native media for ANY
systems that Columbia cannot provide?]

------------------------------

Date: Wed, 12 Aug 87 15:54:10 MEZ
From: Erich Neuwirth <[e-mail]>
Subject: Kermit for a Bondwell?
Keywords: MS-DOS Kermit

I have a problem with a Bondwell 8 amd Kermit.
I have tried 3 different versions:
MSVIBM hangs the system completely.
MSVGEN does not work. Either it states
Disk error reading device COM1
Abort, Retry, Ignore?
or when i have done
set port 2
I get
?Warning: Cannot open com port
Enter a file handle.
and so on.
Entering 3 does not help, then the system again hangs completely.
MSVCLO works almost
In connect mode it works fine, but as soon as I get out of that mode
status shows baud rate set to 1800.  Resetting it and issueing any
transfer command (get, receive, remote dir ....)
generates an error msg about not being able to communicate to host
and then again the baud rate setting is shown to be 1800.
I think the com port must be rather uncoventional in that machine.
Does anybody have any experiences?

P.S.: Setting the other machine to a baud rate of 1800 does NOT help.

------------------------------

Date: Fri, 4 Sep 87 14:47 EST
From: <[e-mail]>
Subject: VMS Kermit version 3.2.076 STATUS Command

I have checked the documentation for recent releases of Kermit-32 and I see
no mention of a problem I have just noticed in version 3.2.076: when I issue
the STATUS command after finishing one or more transfers, the display shows
an effective data rate that is either 0 or garbage (approximately 2**32).
Is this a feature that has never been properly implemented?  Has it been
fixed in subsequent releases without being mentioned in the announcements?
We are now running VMS 4.4 - does that have anything to do with the problem?

[Ed. - Wierd.  We tried it on VMS Kermit 3.1 and 3.3 under VMS 4.3 and got
correct reports in both those versions.  Don't have a copy of 3.2 handy, but
it seems unlikely that it would be broken in 3.2 but not 3.1 or 3.3...]

------------------------------

End of Info-Kermit Digest
*************************
-------
16-Sep-87 19:21:41-EDT,25511;000000000000
Mail-From: SY.FDC created at 16-Sep-87 19:21:07
Date: Wed 16 Sep 87 19:21:07-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V6 #20
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 16 Sep 1987       Volume 6 : Number 20

Today's Topics:

                     Announcing C-Kermit 4E(067)
                 Xenix Experimental C-Kermit 4E(066)
  C-Kermit 4E(066) Support on Control Data 180 Mainframes with VX/VE
                 New Release of Kermit-11 for PDP-11s
            Cover on following mstibm.boo (dated 16 Sept)
                     Insert mode in Kermit 2.29c
            Info-Kermit Digests Available in Indexed Form
     New Organization of Distribution Tapes Reflected at Okstate
                          MacKermit on an SE
                          MacKermit 0.8(35)
                Comments on Recent Kermit Digest Items
              Re: Proposed Extensions to Kermit Protocol
                       Kermit-32 STATUS Command
                    Prime Kermit Source Unpacking
                          WordPerfect files
                      Kermit Protocol Curiosity

----------------------------------------------------------------------

Date: Tue 15 Sep 87 18:24:28-EDT
From: Frank da Cruz <[e-mail]>
Subject: Announcing C-Kermit 4E(067)
Keywords: C-Kermit, Unix, VMS

Now that the beta test of version 4E(066) of C-Kermit (announced in V6 #16)
has had some time to fester, and some good bug reports (and fixes!) have
trickled in, it's time to announce a new release, 4E(067).  This one
includes only fixes for the reported bugs, plus a couple of minor additions.
It was tested with VAX Ultrix 2.0 and VAX/VMS 4.3.  If it checks out OK on
other systems too, it will replace 4D(066) as the standard C-Kermit release.
Checking out OK means that it is not inferior to 4D(066) in any way, so that
no harm would be done by the replacement.  The changes include:

- Fix to allow C-Kermit to run on Pyramid & similar systems.
- The wild "set send packet-length" command was tamed.
- Allow "set prompt" to work, even from init file.
- Problems with packet retransmissions in response to CRLFs should be gone.
- Added dial support for the Concord Condor CDS 220 2400b modem.
- Changed Xenix compilation options a bit.
- New make options for CDC VX/VE, "clean", and "lint".
- Set effective group & user IDs on BSD systems for csh command execution.
- Fix parsing of "show parameters".
- Fix parsing of "remote cwd" from take-command file.
- Breakup of source lines longer than 80 characters.
- Supply missing functions & symbols for VAX/VMS.
- Cosmetic & lint-suggested changes.

See the file xkuker.upd for details.  The affected files are (just so you
don't have to transfer the whole 2.5MB collection again):

  xkcfns.c,   xkcfn2.c,   xkcmai.c,   xkudia.c,   xkufio.c,   xkutio.c,
  xkuusr.h,   xkuusr.c,   xkuus2.c,   xkuus3.c,   xkvfio.c,   xkvtio.c,
  xkuker.bwr, xkuker.mak, xkuker.upd, xkvker.bwr

available as usual from CU20B via anonymous FTP or on BITNET from CUVMA
via KERMSRV.

There are no new binaries or hex files.  People with Unix (any flavor, esp.
Xenix), VAX/VMS, Data General AOS, Macintosh, Apollo, or Amiga systems are
urged to get these files and build the new version from source.  Anyone who is
equipped to build this program from source for the Macintosh or Amiga is
further exhorted to do that, and then report any bugs or fixes (or better
still, report if there aren't any!), and if the result is usable, send in
the .HQX or .BOO file.

If no significant problems are reported with the Unix, VMS, or Macintosh
implementations within a few weeks, 4E(067) will become the standard
distributed version of C-Kermit, so that we don't have to carry the CK*.* and
XK*.* files side by side, and that will make room for some new additions to the
"popular minis and mainframes" area (Tape B).

Thanks to everyone who sent in bug reports, suggestions, and fixes -- Joe
Doupnik, David Herron, Steve Walton, Paul Placeway, S.O. Lidie, Jim Guyton,
Phil Julian, Markku Toijala, and many others.

------------------------------

Date: Sun, 13 Sep 87 03:27:29 edt
From: [e-mail] (Jay Mathew Libove)
Subject: Xenix Experimental C-Kermit 4E(066)
Keywords: C-Kermit, Xenix

A thought - you commented (or someone commented) that the "other Xenix
people" (paraphrase) did not report the trouble of redefined stuff from
include files. Well, from the kermit digest it appears that I am the only
other one who reported to you on Xenix CKermit, and this fits as I have
modified my system include files to avoid certain redefinition problems.
Certain modules include redefinitions IF certain other modules have been
previously included. I have #ifndef I_modname'd the sections that would be
repeats, and I define I_modname when a module is included.  Hope this
explains the lack of problems in this respect on my end.

Jay Libove
Arpa:   [e-mail]    Bitnet: [e-mail]
UUCP:   ...!{uunet, ucbvax, harvard}!andrew.cmu.edu!jl42
UUCP:   ...!{pitt | bellcore} !darth!libove!libove

[Ed. - OK, the "#include <sys/file.h>" statements are removed from ckutio.c
and ckufio.c in 4E(067).  Thanks!]

------------------------------

Date: 12 SEP 1987  22:49 EDT
From: "S. O. Lidie" <[e-mail]>
Subject: C-Kermit 4E(066) Support on Control Data 180 Mainframes with VX/VE
Keywords: C-Kermit, CDC, VX/VE
Xref: Control Data, see CDC

I have ported C-Kermit to Control Data's Unix product, VX/VE 5.2.1.  VX/VE
runs under control of NOS/VE, the Cyber 180 operating system.

Only a few mods were needed, all to CKUTIO.C.  They were mostly for
selecting line discipline 0, because VX/VE defaults to a special line
discipline 1.  The diff outputs for CKUTIO.C and the makefile follow.

Here are some effective baud rates (ebr) at various line speeds and packet
sizes.  These rates are essentially the same for both send and receive, so I
averaged them:

                      1200        4800        9600
                   ----------------------------------
Packet Size:ebr     250: 950                250:5300
                    500:1000    500:3600    500:6400
                   1000:1000   1000:3800   1000:6900

                       83%         79%         72%

Perhaps you would include the following mods into C-Kermit:

[Ed. - Omitted from message, included in 4E(067).]

------------------------------

Date: Fri 11 Sep 87 12:15:37-EDT
From: Brian Nelson <[e-mail]>
Subject: New Release of Kermit-11 for PDP-11s
Keywords: PDP-11, RSX, RSTS, RT11, P/OS, VA4224 Modem

Kermit-11 3.58 for PDP-11s with DEC and DEC-like operating systems (RSTS/E,
RSX11/M, RSX11/M+, RT11, TSX+, IAS, P/OS, Pro/RT, etc) is now available.
It replaces release 3.54 of September 1986.  Changes are relatively minor; they
include:

. SET PHONE TONE/PULSE, SET PHONE BLIND
. VA4224 modem support.
. Allow linking with I/D space under RSTS/E, RSX11M+.
. Fix command macro display (SHO ?)
. Add Ctrl-A status report during local-mode transfers.
. Dynamic record buffer allocation, bigger buffers for I/D space.
. Conditional .INCLUDE's for assembly on RT11 V4 and P/OS.
. Fix sending BREAK for XL on RT11
. SET LINE TTN:/[NO]ALLOCATE for RSTS/E

[Ed. - Thanks, Brian!  The new files are in KER:K11*.*, including new
documentation (K11USR.*), available from host CU20B via anonymous FTP
(Internet) or NFT (CCnet), and from host CUVMA on BITNET via KERMSRV.]

------------------------------

Date: Sat, 12 Sep 87 22:55 MDT
From: <[e-mail]> (Joe Doupnik)
Subject: Cover on following mstibm.boo (dated 16 Sept)
Keywords: MS-DOS Kermit

The current MSTIBM.BOO file follows (dated 12 Sept) if you want to
do anything with it at this time.  I'm off Sunday am to meetings all week.

        Regards,
        Joe D.

[Ed. - Not sure what's new in this one, but it seems to work OK, so it
replaces the 2.29C version dated 16 August as KER:MSTIBM.BOO on CU20B
(MSTIBM BOO on CUVMA).  There's also a somewhat updated draft of the manual
in KER:MST29C.DOC.  Feedback appreciated, as the real 2.30 release draws
ever nearer.]

------------------------------

Date: Fri, 11 Sep 87 23:27:06 EDT
From: "James H. Coombs" <JAZBO@BROWNVM>
Subject: Insert mode in Kermit 2.29c
Keywords: MS-DOS Kermit

I asked about this before but have not seen a response.  How about providing
some method for making it clear when one is in insert mode?  Ideally, the
cursor would get fat.  This is a serious weakness in Kermit's terminal
emulation capacities.  The problem is aggravated by the fact that insert mode
is automatically toggled off by certain operations.  One does not really know
what the mode is until one starts typing.  YTERM provides such feedback, so it
obviously can be done.
                                    --Jim

[Ed. - Probably not in the near future.  2.30 is about ready to release.
And also this feature would tickle a bug in early IBM PC ROMs discussed in
past issues of Info-Kermit and Info-IBMPC.  Anyway, a real VT100 doesn't do
this... (standard copout).]

------------------------------

Date: Fri 11 Sep 87 11:45:49-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digests Available in Indexed Form
Keywords: Info-Kermit, Digest, Kermit Digest, Index

Info-Kermit Digests Volumes 3 - 6 have been indexed and paginated, so that
information can be easily looked up by topic.  The indexed versions, suitable
for printing, are in KER:IMAIL.85B, KER:IMAIL.86A, KER:IMAIL.86B,
KER:IMAIL.87A.  Indexing will proceed retroactively back to Volume 1, time
permitting.

------------------------------

Date: Thu, 10 Sep 87 16:22:14 -0500
From: Mark Vasoll <[e-mail]>
Subject: New Organization of Distribution Tapes Reflected at Okstate
Keywords: OK State, UUCP, Dialup Kermit File Access

The new five tape organization of the Kermit distribution has
been duplicated on the Oklahoma State University UUCP and Kermit
server system.  The following is the new layout.

/usr/spool/uucppublic/kermit-a   --  Tape A (microcomputer versions)
/usr/spool/uucppublic/kermit-b   --  Tape B (mini/mainframe versions)
/usr/spool/uucppublic/kermit-c   --  Tape C (more micro versions)
/usr/spool/uucppublic/kermit-d   --  Tape D (more mini/mainframe versions)
/usr/spool/uucppublic/kermit-e   --  Tape E (documents and misc.)

See the "aafiles.dir" file in each directory for exact contents or refer to
"aavers.hlp" for tape name and file name prefixes on specific versions.

Mark Vasoll
Computing and Information Sciences   Internet:  [e-mail]
Oklahoma State University            UUCP:  {cbosgd, ihnp4, rutgers,
Stillwater, Oklahoma                         uiucdcs}!okstate!vasoll

[Ed. - Thanks, Mark!  And thanks for continuing to provide this valuable
service.]

------------------------------

Date: Sun, 13 Sep 87 12:41:28 edt
From: "Robert B. Stam" <[e-mail]>
Subject: MacKermit on an SE
Keywords: MacKermit, Macintosh SE

Here's a copy of the fix I had to use to get Kermit to run on an SE (as
opposed to a Plus or earlier).  This is a copy of an article posted to
comp.sys.mac

In a recent posting I commented that I was not able to get MacKermit to run
correctly on my Mac SE, and that it seemed to be a problem with fonts.  A
local insightful chap suggested that MacKermit as delivered from columbia
might not have a FOND resource.  In fact it does not (this is true of both
ckmker.hqx and xkmker.hqx).  The fix is as follows:

1)  Make a copy of MacKermit.
2)  Run Font/DA mover
3)  Close the system file fromt the left window
4)  Click the left Open button with the option key down (the option key tells
    it to open all kinds of files, like MacKermit)
5)  Find and open the original copy of MacKermit
6)  Click the right Open button with the option key down
7)  Find and open the duplicate copy of MacKermit
8)  Select and remove the 2 fonts (VT100 etc...) from the right hand window
    (ie, from the copy of MacKermit)
9)  Select and copy the 2 fonts (VT100 etc...) from the left hand window, thus
    copying the 2 fonts from the original copy of MacKermit to the
    duplicate copy of MacKermit
10) Close everything and quit.  MacKermit should now work.

This is not quite the NOP operation it looks like.  When Font/DA mover moves
a font it looks to see if the destination has the appropriate FOND resource,
and if not it adds it.

Many thanks to Oliver Steele of UNC who guessed what the problem was and
suggested that I look for the FOND.

Happy Kermitting ...

Robert B. Stam                          CSNET: [e-mail]
UNC Computer Science Department        ARPA:  [e-mail]
Sitterson Hall 083A                   UUCP:  {ihnp4|decvax}!mcnc!unc!stamr
Chapel Hill, NC 27514                   Phone: [phone]

[Ed. - And many thanks to you for sending in the solution, which has been
added to the Mac Kermit "beware" file.]

------------------------------

Date: Mon, 14 Sep 87 11:08:37 EDT
From: Warren Bell <[e-mail]>
Subject: MacKermit 0.8(35)
Keywords: MacKermit

I was under the impression that there was a new version of Kermit for
the Macintosh, with version number 0.8(35), but when I requested
CKMKER.HQX from KERMSRV@CUVMA, I received version 0.8(34), dated March 1986.
Will the new version be available on the Bitnet server?

-Warren Bell
([e-mail] or [e-mail])

[Ed. - The new version is XKMKER.HQX, not CKMKER.HQX.  And even that is not
so new -- it's based on the 4D(061) sources, but changed to compile under
Megamax C, and with a couple cosmetic changes.  I hope somebody out there
will build a version of MacKermit, let's call it 0.8(36), from the new C-Kermit
4E(067) sources, and maybe even add material to the dialog boxes to allow
selection of long packets and other new features, and then send in the
resulting .HQX file (and any modified XKM*.* sources).]

------------------------------

Date: Fri, 11 Sep 87 23:39 MDT
From: <[e-mail]> (Joe Doupnik)
Subject: Comments on Recent Kermit Digest Items
Keywords: Kermit Protocol Extensions

Regarding the latest Kermit Digest (V6 #19):

1. Chris Kennington's embedded file transfer controls while in Connect mode.
The SOH + stuff combination is a little delicate, as Frank also mentioned.
What about an extension of a DEC escape sequence set: ESC [ ? etc  ? This
would be easy to parse and would help maintain ruggedness of the code and
also would not cause a false alarm if transparent printing were active.
The host side would need to start a file transfer with it and the current
version of Kermit-MS can tolerate it as a packet lead-in sequence.

[Ed. - See discussion below.]

2. Dave Herron and Unix version numbers.  Thanks Dave.  My manuals all say
plain jane sysVr3 and now I know (I think).  C-Kermit works solidly on my Unix
PC after removal of the void cast on signal(), for what its worth.

3. Dave Bell and sending WordPerfect files to Kermit-32.  Yup, the binary
nature of those files requires SET FILE TYPE BINARY on the VMS side.

[Ed. - More about this below.]

4. Kermit-32 has math problems with effective baud rate.  True indeed.
Local Kermit-32 version is 3.3.111 and it solidly reports 2**32.

[Ed. - See below.]

5. Eric Neuwirth and the Bondwell PC. Eric, more than the serial board is
non-standard with your machine. Try Kermit-MS version 2.30 when it appears
and if that hangs your system it is time to find a friend with computer
experience.

6. From Jim Moore, [e-mail]: sees "4i" at end of transparent
printing.  An old problem fixed some time ago.

[Ed. - i.e. fixed in current MSTIBM.BOO, version 2.29C.]

7. From Walter Mischel, psy1.mischel@cu20b: Control-@ does not send
a null.  That's a keyboard definition affair.  The real IBM keyboard does
not send a null from any key combination since it is the same as a Control
Break to the Bios. It can be added to the current key definitions as
        Set Key \1283 \0
Perhaps this should be made a default definition.

[Ed. - A real VT100 doesn't send a null from ^@ either...]

8. From David Cargo, [e-mail]: top rank keys are coupled
to similarly labeled keypad keys for key definitions.  Old problem since
fixed.  The keypad is fully 'aliased' to separate such keys and allow the
keypad itself to be reconfigured without affecting the top rank keys.

        Regards,
        Joe D.

------------------------------

Date: 1987 Sep 11   23:21 EDT
From: (John F. Chandler)   [e-mail]
Subject: Re: Proposed Extensions to Kermit Protocol
Keywords: Kermit Protocol Extensions

In response to the suggestion of automatic resumption of Protocol mode upon
receipt of any SOH, I'd like to point out that noisy lines are not only
problem.  Many Kermits can (and some must) use a packet-marking character
other than SOH, and it seems a pity to trigger on SOH (or on the current
packet character) trusting that said character will never occur for
non-Kermit reasons.  I think it would be better to implement a special
Connect-mode command to put the micro-Kermit back into Protocol mode. After
all, in Connect mode, Kermit listens for "commands" from the remote host and
updates the screen accordingly -- why not just extend the terminal emulation
language by adding one new escape sequence?  Upon receipt of that command,
the micro could pop into server mode and await instructions.  Note that the
remote host can then do more than just send files -- it can issue the whole
range of server-mode commands to change settings and even upload files.

------------------------------

Date: Wed, 16 Sep 87 16:38:23 BST
From: Chris Kennington ([e-mail])
To: John F. Chandler ([e-mail])
Cc: info-kermit @ cu20b.columbia.edu
Keywords: Kermit Protocol Extensions

John:
        Thanks for your thoughtful comments (suggesting a terminal
escape-sequence to trigger local Kermit into protocol mode).
        I take your point that any auto-triggering ought to be on the
current Start-of-Packet character, not "hardwired" to SOH.  I'd also intend
that the implementation should check pretty thoroughly that the next few
characters are compatible with the header of one of the Kermit packets legal
at this point (S, I etc.).
        From the point of view of my (commercial) client, the objective was
to achieve a local Kermit which would flip into protocol mode as soon as the
user gave the appropriate command to the host Kermit (in connect mode).  The
proposed environment is one where the relatively naive user thinks of his
local equipment as an intelligent terminal, not a computer.  As far as he is
concerned, he always thinks he is talking to the mainframe host.
        The ESC-sequence idea has attractions because it's controllable
(though some thought would be needed to pick an appropriate sequence,
presumably from one of the ANSI "local implementation" sets).  The
disadvantage is that, as an extension to the Kermit host protocol, there
would be a delay before the majority of mainframe host Kermits implemented
it.  My client, as always, wants it yesterday; and wants it to work
independent of the level of Kermit on the host.
        I shall probably proceed with the trigger-on-"SOH" logic, if only to
see how it works.  But I am in favour of defining an extension to the
protocol which permits, in effect, limited communication between the two
Kermit state-machines embedded in the connect data-stream.  There might be a
number of other things which could usefully be done, such as setting the
start-of-packet character itself.  This sounds like an idea to be threshed
around generally.
                                Chris K.

[Ed. - Anyone who adds this kind of mechanism to a Kermit program should
also provide a way for the user to override it, in case of accidents and for
debugging.  About the "Kermit escape sequence" -- since any Kermit program
can emulate any terminal whatsoever, or for that matter may make use of any
built-in firmware, external terminal device driver, or even an external
terminal, then how can you pick a sequence guaranteed not to collide with
any conceivable terminal's repertoire of escape sequences?  (The world isn't
composed only of ANSI terminals -- we also have HP's, DG's, etc etc).
Looking for a Kermit packet does indeed seem to be the best route.]

------------------------------

Date: Fri, 11 Sep 87 23:55 CDT
From: <[e-mail]>
Subject: Kermit-32 STATUS Command
Keywords: Kermit-32, VMS Kermit

In light of the comments about STATUS not working, it doesn't work for us in
versions 3.0 or 3.3.  We're running VMS 4.5 (VAX 8650).  (Usually we
download files to IBM PCs, running ProComm 2.4.2.)

MM

VMS Kermit-32 version 3.3.111
Kermit-32>stat

Totals for the last transfer
 Characters sent        188
 ...
 Effective data rate    4294967106 baud

[Ed. - This is wierd.  It seems to be independent of Kermit version, but
dependent on VMS version.  A real baud rate is displayed by 3.1 and 3.3
of VMS Kermit under VMS 4.3...  Anyway, it seems Kermit-32 is headed for
extinction, and development is picking up on the VMS version of C-Kermit,
which doesn't have any problems reporting the effective baud rate.]

------------------------------

Date: Sun, 13 Sep 87 22:29:42 EDT
From: [e-mail]
Subject: Prime Kermit Source Unpacking
Keywords: Prime Kermit

The source for Prime Kermit is in one big file, PRIME.PLP.  CU20B has a
program PRIMES.FTN which breaks it into its component files automatically.
Unfortunately, this program doesn't work.  It looks for lines of colons
separating the files.  PRIME.PLP has lines of pound signs.  The program also
messes up finding file names.  I'm trying to fix the program, but I am
wondering if anyone has already got it working.

The alternative way of splitting the file is to use EMACS.  We have this,
but it truncates the file after 5000 lines, so that doesn't help either.

If I get it working soon I'll let you know.

Mike Ciaraldi

------------------------------

Date: Mon, 14 Sep 87 15:56:28 EDT
From: John C Klensin <[e-mail]>
Subject: WordPerfect files
Keywords: WordPerfect

WordPerfect files are, in fact, binary ones, with funny line delimiters and
several other such things -- it is not just printer ESC codes.  To transfer,
you must either:

  - Treat the file as binary, as suggested in Info-Kermit.  It, after all,
*is* binary.  Use SET FILE TYPE BINARY to VMS Kermit.

  - Use WordPerfect's "convert" program to encode it into seven-bit ASCII
graphic characters.

If you really have a WordPerfect printer output file (rather than the file
that WordPerfect actually operates on) then the problem is the same, but
only the first solution -- binary transmission - will do you any good.

------------------------------

Date: Wed, 16 Sep 87 06:11:51 EDT
From: John C Klensin <[e-mail]>
Subject: Kermit Protocol Curiosity

We have run into a small protocol curiosity when using a strange mix of
equipment.  It seems to parallel another strange mix, so the problem may be
general enough to be worth consideration.  The problem:
  - We start with a terminal concentrator that requires (or is most easily
configured with) a "parity none" arrangement.  In our case, the concentrator
speaks RS232 asynch on the PC side and TCP/IP Telnet on the network side.
  - The network -- specifically, either the concentrator or the host at the
far end -- won't negotiate an eight-bit "binary" transfer of data, so binary
information must be transmitted with 8th-bit prefixing.
  - But, while the protocol manual seems to provide for me to force 8th-bit
prefixing by sending a character other than N or Y, most versions of kermit
ask for this feature only if parity is set on (non-none).  If we turn parity
on, the terminal concentrator, which checks it, gets very upset.

In addition to our TCP/IP problems, this seems to parallel some difficulties
we've observed with some complex protocol converter arrangements that make
ASCII devices speak 327x at the far end of complex links.

We can, of course, get around this by "hexifying" the files prior to
transmission, but that is what 8th-bit quoting is supposed to save us.  So,
this is a bit of a plea for either an
  SET EIGHTH-BIT-QUOTING ON  option or
some way to say
  SET PARITY NONE-but-don't-transfer-eight-bit-data-without-quoting

[Ed. -  Not really a protocol issue, but an implementation decision.  This
is the first time we ever heard of an environment where 8th-bit quoting
is necessary and at the same time parity is proscribed.  But my goodness,
how do explain something like this to the "naive user".  The manual is
already hundreds of pages thick!]

------------------------------

End of Info-Kermit Digest
*************************
-------
18-Sep-87 18:37:53-EDT,23774;000000000000
Mail-From: SY.FDC created at 18-Sep-87 18:37:17
Date: Fri 18 Sep 87 18:37:17-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V6 #21
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 18 Sep 1987       Volume 6 : Number 21

Departments:

  ANNOUNCEMENTS -
        Announcing NIH TSO Kermit Version 1.1A
        Announcing C-Kermit for Convergent Technologies CTOS
        Announcing Kermit v2.8a for Apollo
        Info-Kermit Digest BITNET Delivery in Danger
        News about Kermit Programs for VAX/VMS
        Kermit User Guide and Protocol Manual Available in Portuguese

  C-KERMIT -
        C-Kermit 4E(067) on VAX/VMS Bug Report
        C-Kermit 4E(066) Support for Amdahl UTS Half Duplex Systems
        C-Kermit 4E(066) on Apollo, IBM RT, Microvax II Bug Report
        Patches to C-Kermit for Phone Directory

  MS-DOS KERMIT -
        SCANCHEK Program for IBM-PCs
        MS-Kermit 2.29C on 3COM LAN
        Problem with TurboBASIC and MSBPCT.BAS

  MAC KERMIT -
        Mac Kermit Can't Receive Files Whose Names Start With X?
        Decoding KERMSRV's .HQX Files?

    MISCELLANY -
        Re: Kermit Protocol Curiosity

----------------------------------------------------------------------

From: "Roger Fajman" <RAF@NIHCU>
Date: Wed, 16 Sep 87  18:44:10 EDT
Subject: Announcing NIH TSO Kermit Version 1.1A
Keywords: TSO Kermit, MVS/TSO Kermit, IBM 370, NIH

Version 1.1A of NIH TSO Kermit is now available.  It contains fixes for a
number of bugs, but no new functions.  The following four files were
updated: TSNKER.TXT, TSNKER.BWR, TSNKER.OBH, and TSNKER.ALP.  The new
version is available from Columbia in the usual ways and directly from NIH
(at no charge) by sending a letter and a tape to

      Joseph D. Naughton
      Chief, Computer Center
      National Institutes of Health
      Building 12, Room 2244
      Bethesda, MD 20892

A new version is under development that does contain new functions such as
(1) long packets, (2) 7171 protocol converter support (being developed
elsewhere), (3) multiple commands on a line, (4) multiple file names in a
SEND or GET command, (5) better handling of data set name collisions, and
(6) other things I can't remember at the moment.  No release date has been
established for this version.

[Ed. - Thanks, Roger!  The four new files are available in KER: on CU20B for
anonymous FTP (Internet), from KERMSRV on CUVMA (BITNET), and on Kermit
distribution tape B.]

------------------------------

Date: Fri, 11 Sep 87 08:45:32 edt
From: ecsvax.uucp![e-mail] (Joel Dunn)
Subject: Announcing C-Kermit for Convergent Technologies CTOS
Keywords: Convergent Technologies, CTOS, NGEN, Burroughs B20, BTOS, C-Kermit
Keywords: VT100 Emulation

Over the last year, I have been gradually porting C-Kermit 4.2(030) march 85
to CTOS, a multi-tasking proprietary operating system that runs on Convergent
Technologies NGEN micro computers.  I re-wrote the comm line I/O, disk I/O,
and video I/O, and added a rudimentary VT100 emulation option.  The protocol
code is pretty much as I got it, as is the command parser and things like that.
I use it fairly regularly, both as a terminal emulator and for text and binary
file transfers to my local Unix machine running C-Kermit.

My port is not perfect, but I would like to offer it up to the "Kermit Gods"
if you are at all interested.  I know it is based on "old" source, but that
is what I was able to easily get at the time I started this project, back in
the summer of '86.  I only worked on it as time permitted, so that's why it
took me a year to get it where I thought it worked.

Joel Dunn
UNC-Chapel Hill
Administrative Data Processing
440 W. Franklin Street
Chapel Hill, NC  27514

[e-mail]
{backbone}!mcnc!unc!dunn.UUCP
{backbone}!mcnc!ecsvax!joeld.UUCP

[Ed. - Many thanks, Joel!  There have been many requests for CTOS Kermit over
the years, and also for BTOS (for Burroughs B20, etc, which is supposed to be
compatible).  It would be much appreciated if anyone can report on whether this
version also works on BTOS.  CTOS Kermit has been put in KER:CT*.* on CU20B,
CT* * on CUVMA, and on Tape C of the Kermit distribution.  Since you've gone to
the trouble to develop most of the system-dependent C-Kermit code for CTOS, I
hope that someone will take the next step and adapt it to the current version
of C-Kermit, so we don't have to carry a redundant set of files.]

------------------------------

Date: Fri, 18 Sep 87 14:12:18 +0200 (Central European Sommer Time)
From: [e-mail] (KLaus D. Schmitt THD Inst. f. EEV FB17)
Subject: Announcing Kermit v2.8a for Apollo
Keywords: Apollo, Pascal

Some time ago I got Kermit for Apollo from Netlib.  We installed this version,
but had some trouble with SEND command (nothing could be send from Apollo !).

We examined the sources from Netlib and corrected them with the result, that
all works quite well on our DN 3000 communicating with some PC's and VAXen.

Please note, that the source includes kermitio.pas in the file kermit.pas.
existf.c is no longer needed !

Greetings from Europe
Klaus D. Schmitt
Inst. for El. Power Supply
Technical University Darmstadt
F R G

[Ed. - Gruess aus Nord-Amerika, und vielen Dank, Klaus!  Kermit 2.28a replaces
APOLLO.PAS in Kermit Distribution.  Meanwhile, if anybody knows the difference
between APOLLO.* and APLKER.* (both Pascal Kermits for the Apollo, apparently
cousins descended from version 2.6?), let us know!  If they can be reconciled
into a single version, we could free some space and alleviate some confusion.]

------------------------------

Date: Wed, 16 Sep 87 13:03:34 PDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Info-Kermit Digest BITNET Delivery in Danger
Keywords: Info-Kermit Digest, BITNET, LISTSERV

As of December 1, 1987, the WISCVM Internet/BITNET mail gateway will go out of
service because of the heavy load this function has placed on their system.
There are currently about 150 entries in the Info-Kermit distribution list that
go through the WISCVM gateway.  Although Columbia has its own BITNET mail host,
CUVMA, experience has shown that routing through CUVMA to BITNET does not work
for most addresses.  This is because the To: list does not appear as part of
the message (and nobody would want it to, since it's about 600 lines long!),
and the protocol for a mailer to send the recipient list to the receiving mail
agent varies among BITNET sites.  Anyone who receives the Info-Kermit Digest
through WISCVM is urged to advise us of an alternate address, or to register
with a LISTSERVer near you.  For instance, you could subscribe through Tulane
University by typing the following command (from a VM/CMS system):

  TELL LISTSERV AT TCSVM SUB I-KERMIT your-name

where your-name is your actual name, which may contain spaces, etc.  After
you have done this, make sure you get delivery of at least one Info-Kermit
digest from UGA, and then you can send a message to Info-Kermit-Request@CU20B
telling us to drop you from our own distribution list.

Other LISTSERV sites that can redistribute Info-Kermit include Brown University
(BROWNVM), the University of Georgia (UGA), and the University of Guelph
(CANADA01).  Eventually, Columbia University (CUVMA) will join them.  Other
BITNET and NETNORTH sites with LISTSERVers, particularly in mid- and far west
North America, as well as EARN sites in Europe, are also encouraged to
volunteer to distribute Info-Kermit mail.  There will be more news about this
in future digest, I hope.

------------------------------

Date: Wed, 16 Sep 87 13:03:34 PDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: News about Kermit Programs for VAX/VMS
Keywords: C-Kermit, VAX/VMS Kermit, VAX/VMS C-Kermit
Keywords: VAX/VMS Fortran/Pascal Kermit
Cross-Ref: VMS, See also VAX/VMS

If you attended the Nashville DECUS Kermit session, you may have heard Bob
McQueen announce that continued development of VAX/VMS Kermit-32
(KER:VMS*.*) at Stevens Institute of Technology is probably a lost cause.
VMS Kermit was developed by Bob McQueen and Nick Bush at Stevens from 1982
until the most recent (and probably final) release, 3.3.111, in April 1987.
Nick left Stevens some years ago, and Bob and his staff are too tied up in
other projects to continue their Kermit work.  Many, many thanks to Bob,
Nick, and SIT for one of the most ambitious and popular Kermit
implementations, and for many contributions to the Kermit protocol itself.

Kermit-32 is written in the Bliss language, DEC's "corporate implementation
language" (originally developed at CMU).  Bliss never gained popularity among
DEC's customers; few sites have Bliss compilers.  If there are any VMS Bliss
sites out there who are willing to take over maintenance and development of
Kermit-32, please come forward!

Not entirely parenthetically, it should be noted at this point that there is
also a VMS Kermit written in a combination of Pascal and Fortran, last released
by Bruce Pinn and Philip Murton at the University of Toronto in 1984
(incidentally, this is based on Toronto's OMSI Pascal Kermit for RT11, the
first high-level language Kermit program).  To my knowledge, no further
development is planned on this program either.  Some sites that are
uncomfortable running Kermit-32 because they don't have Bliss compilers use
this version instead (it's in KER:VX*.*).

It now appears that all further work on VMS Kermit will concentrate on the C
version, of which release 4E(067) was announced in the previous Kermit
digest (KER:XK*.*).  Development of VAX/VMS support for C-Kermit has been
taken over by:

    Jamie Hanrahan
    (uucp:     {akgua | hplabs!hp-sdd | sdcsvax | nosc}!crash!pnet01!jeh)
    (arpa:     crash!pnet01![e-mail])
    (internet: [e-mail])
    (US Mail:  c/o Simpact Assoc., 9210 Sky Park Ct., San Diego CA 92123)

Jamie is working from the latest stuff.  If you're a VMS VAX-11 C and/or RMS
expert (preferably on the net) and would like to help out, please contact
Jamie.  Similarly, if you have any suggestions, bug reports, fixes, etc, for
C-Kermit on VMS, send them to Jamie, cc to Info-Kermit@CU20B.  Among the
improvements we hope to see are better performance during CONNECT and more
detailed knowledge of the VMS file system.  Thanks to Jamie for taking this on!

------------------------------

Date: Wed, 16 Sep 87 13:03:34 PDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit User Guide and Protocol Manual Available in Portuguese
Keywords: Kermit Documentation, Portuguese

Ricardo B. Ghirlanda of Telecomunicacoes Brasileiras S.A., Brasilia, Brazil
(pardon the missing diacritical marks) has translated the Kermit User Guide and
Protocol Manual (5th Editions, somewhat behind the times) into Portuguese.
These manuals have been placed into KER:POR*.* on CU20B (POR* * on CUVMA):

  PORTUG is the Portuguese User Guide (Fifth Edition).
  PORTPM is the Portuguese Protocol Manual (Fifth Edition).
  PORTTT is a manual describing a Kermit-based file transfer service

The original files were in 8-bit IBM PC WordStar (.WSD) format, which can't be
included in Kermit distribution.  The files of type .HEX are "hexified"
versions of the WordStar files, which can be dehexified back into the original
8-bit WordStar format by a simple program that puts each pair of hex digits
back together (a sample program is listed in PORTAA.HLP).  The files of type
.TXT are 7-bit ASCII files produced from the WordStar files by stripping the
high-order bit of each 8-bit byte.  These are pretty much readable on a
terminal or printer; diacritics are mostly done with backspace-overstrike, etc.

Thanks to Mr. Ari Lopes Cunha of Brasilia for submitting this material.

If you have Kermit documentation translated into any new languages, please send
them in.  This is especially appropriate now that we have a special place to
keep them (Tape E).  I've seen (or heard of) Kermit manuals in German, Italian,
Hungarian, and Japanese, but have never received machine-readable versions.

------------------------------

Date: 17 SEP 1987  15:57 EDT
From: Steve Roseman <[e-mail]>
Subject: C-Kermit 4E(067) on VAX/VMS Bug Report
Keywords: C-Kermit, VAX/VMS C-Kermit

Running C-Kermit 4E(067) under VMS V4.5 seems to work so far, with 3 problems.

1.  The user needs a BYTLM quota of at least 5000 to execute a "! xxx" command,
    "DIR", or "SPACE".  Otherwise the job just hangs up.

[Ed. - This doesn't happen to me under VMS 4.3, unless somebody raised my
BYTLIM (whatever that is!) without my knowing it.]

2.  With a sufficient BYTLM, the above work, but if any are done, C-Kermit
    leaves behind a subprocess when it exits.  Re-entering C-Kermit and
    executing any of the above starts up (and then leaves behind again)
    another subprocess.  Repeat until your job hangs up.

3.  A "! LOGOUT" command kills the subprocess in which it executes;  another
    "! xxx" command just hangs, since C-Kermit doesn't seem to know it's
    gone.

    Fairly minor problems, but file transfers run well with 1000 char packets.

                                                      Steve Roseman
                                                      Lehigh Univ.

PS:  in Vol 6, number 20, you mention a new MSTIBM.BOO.  One thing that
has been fixed is flow-control after ^S and no ^Q (e.g. ^X^S^X^Z save and exit
EMACS).

[Ed. - Thanks for the bug reports, Steve.  They've been passed along to Jamie.]

------------------------------

Date: Mon, 14 Sep 87 19:12+0600
From: Darren R Besler <[e-mail]>
Subject: C-Kermit 4E(066) Support for Amdahl UTS Half Duplex Systems
Keywords: C-Kermit, Amhdahl, UTS, Half Duplex, IBM 370

This is in regard to the experimental version of C-Kermit, version 4E(066).
The installation here at the University of Manitoba is the following:

     Processor:    Amdahl 5870
     Oper Sys:     UTS/V running under VM
     Comm Ctlr:    Amdahl 4705

Due to the above machine configuration we are running UTS in half duplex mode.
C-Kermit is written to work in full duplex mode.  I have made appropriate
changes to allow running in half duplex mode.  These changes have been embedded
amongst #ifdef HALFDUPLEX or #ifdef FULLDUPLEX constructs.  Could these changes
be incorporated into the next version of C-Kermit?

The files modified are the following:
    ckucmd.c
    ckuker.mak
    ckutio.c

Here is the cdiff for ckucmd.c

Darren R Besler
Dept. of Computer Services
University of Manitoba
Winnipeg, Manitoba, Canada

[Ed. - Diffs omitted, added to KER:XKUKER.BWR, but the diff for ckutio.c is
missing.  Building C-Kermit for half or full duplex operation according to
a compile-time option may not be the best method, however.  What if there
are both full- and half-duplex connections to the same system?  E.g. an IBM
or Amdahl mainframe with 3705 half-duplex ASCII TTY lines, and full-duplex
7171 protocol converters...]

------------------------------

Date: FRI, 18 SEP 87 13:05:17 MESZ
From: [e-mail]
Subject: C-Kermit 4E(066) on Apollo, IBM RT, Microvax II Bug Report
Keywords: C-Kermit, Apollo, IBM RT PC, MicroVAX II, Ultrix

C-KERMIT 4E(006) 4 AUG 87  REPORT:

APOLLO Domain/IX DN3000, SR 9.5.1 SYS5, C-Kermit 4E(066) 4 Aug 87
  Generated with 'make sys5'
  When using '.kermrc' or using the 'take' command
    the 'C-Kermit>' prompt is not present and then
    any invalid command brings the message
      'Fatal: Kermit command error in background execution',
    after which C-Kermit terminates.

IBM PC RT 6150, AIX 2.1, C-Kermit 4E(066), AT&T System III/System V
  Generated with 'make sys5'
  Cracks up with 'Bad system call - core dumped' when using '.kermrc'
    or using the 'take' command
  Pervious version worked ok
  For this version do not use 'take', set line and speed at kermit
    command level

[Ed. - The above two problems are caused by the check for background
operation in conint(), module ckutio.c.  If someone can figure out what
the code should be to determine whether Kermit is running in the foreground
or the background on these systems, please send it in!  Meanwhile, the
workaround is to always have conint() set the variable backgrd to 0.  Of
course, then you can't really run it in the background...]

MICRO VAX II, Ultrix 1.2A, C-Kermit 4E(066) 4 Aug 87, 4.2 BSD
  Generated with 'make bsd'
  Runs O. K., except the tty line hangs after use.
  Extended packet works.

[Ed. - I tried it in remote mode on a MicroVAX II with Ultrix 2.0, and
it didn't hang the line after use.  Are you talking about remote or local
mode?]
                                       Regards, Ray Koluvek

------------------------------

From: ames!pluto!warren@phri (Warren Burstein)
Date: 13 Sep 87 17:22:26 GMT
Subject: Patches to C-Kermit for Phone Directory
Organization: Industrial Automation Systems - New York, NY
Keywords: C-Kermit, Phone Directory, Dial Command

These patches add to ckermit a "set phone" command.  Aliases are recognized in
the "dial" command.  My .kermrc is now full of "set phone" commands.

The new command looks like
   set phone pacx 280-8050
After this command, I can say
   dial pacx

I don't know how to make a "patch" file so here is a shar of all the diffs.
I didn't use any fancy methods to store phone numbers, it didn't seem worth the
effort.

[Ed. - Pretty neat.  Thanks, Warren.  For now, the code will be kept in
XKUKER.BWR.]

------------------------------

Date: Sat, 12 Sep 87 16:57:57 EDT
From: Phil Benchoff <BENCHOFF@VTVM1>
Subject: SCANCHEK Program for IBM-PCs
Keywords: IBM PC Key Codes, MS-DOS Kermit

Enclosed is SCANCHEK.C and SCANCHEK.BOO for IBM-PCs.  This program displays
BIOS scancodes and MS-Kermit 2.29C key idents.  It is useful to determine key
idents while defining MS-Kermit keyboard definitions.

The source will compile with Computer Innovations C-86 or Borland Turbo-C.
Special thanks to JRD for providing details of MS-Kermit keyboard handling and
modifications to the code.  Please add it to the distribution if you think it
will be useful.

[Ed. - Thanks!  The files have been renamed MSUCHK.C and MSUCHK.BOO to fit the
Kermit file naming scheme.]

------------------------------

To: "Joe Doupnik" <JRD@USU>
From: "Roger Fajman" <RAF@NIHCU>
Date: Thu, 17 Sep 87  18:32:03 EDT
Subject: MS-Kermit 2.29C on 3COM LAN
Keywords: MS-DOS Kermit, 3COM Ethernet, Netbios

One of our people here tried a quick PC-PC test with MS Kermit 2.29C running
over a 3COM Ethernet with 3Plus software.  He found two things:

(1)  Kermit would not work with version 1.0 of the 3COM Netbios.
     The 1.2 version seemed to work, but he did not try a lot of
     things.  Apparently 1.0 is a less than complete implementation
     of Netbios.

(2)  The SET PORT NET command appears not to upcase its argument.
     The value he used had letters in it that had to be entered
     in upper case in order to work.

Roger

------------------------------

Date: Thu, 17 Sep 87 10:52:05 CDT
From: [e-mail] (Moore)
Subject: Problem with TurboBASIC and MSBPCT.BAS
Keywords: BOO File Programs, BASIC, TurboBASIC, MS-DOS Kermit

Has anyone commented on TurboBASIC not working properly with MSBPCT.BAS?  I
recently downloaded both the .BAS and .BOO files to create an executable;
GW-BASIC and QuickBASIC 3.0 executely nicely, but TurboBASIC chokes on line
300; in fact, as nearly as I can tell, the program just stops executing
completely.

------------------------------

Date: Thu, 17 Sep 87 11:43:43 PDT
From: [e-mail] (Kevin 0'Gorman)
Subject: Mac Kermit Can't Receive Files Whose Names Start With X?
Keywords: Mac Kermit

I found this in ckmker.bwr in the 4E(066) distribution.  I ran into a very
similar problem I thought I would pass along.

> Occasionally, files transferred to the Mac with apparent success will be
> empty.  This happens very rarely and cannot be reproduced.  It has only been
> reported twice, once on a Hyperdrive system, and once on a Mac with a Tecmar
> disk after the screen had been dumped to the printer.  (this problem may be
> rectified in edit (33), which now terminates on failure to close, attempting
> to report an appropriate error.)  One user claimed to be able to reproduce
> the problem by using Mac Kermit to GET any file whose name starts with X from
> the Unix Kermit server (yet others can't reproduce it this way).

I was reading the Kermit distribution from a VAX running 4D kermit, and 4.3 BSD
with a Mac Plus running 0.8 Kermit.  The VAX was running as server, and I
requested x*.  I would get the first file okay, but all others would pass
by VERY fast, with the notation "Discarded" and "K bytes: 0" on the Mac.

When I renamed that first file, that had arrived okay, so that it was no longer
selected by x*, I got the new first file okay, but all others were passed over.
This repeated ad infinitum.  I renamed all files on the VAX so that none began
with "x", and they came across just fine.

Another thing I noticed, that may bear on this, is that the renaming of the
files did not agree with the documentation.  Some of my files had more than
one period in the name (I originally was trying to get compressed files named
like ckusr.c.Z), and I found that the mac reported the filename being recieved
as CKUSR.CXZ.  I gathered that it was changing things so that there were never
more than 1 "." in a filename.  I can't tell which system did this.

Since "x" is special in this way, the special code may be munging incorrectly
on subsequent files of a set.  I dunno.  I just thought I would pass along
instructions on how to repeat this.

[Ed. - There appears to be something very wrong with Mac Kermit's filename
collision avoidance algorithm...]

------------------------------

Date: 2 SEP 1987 18:31:20 EDT
From: "Richard E. Lynch" <VM10CA@WVNVM>
Subject: Decoding KERMSRV's .HQX Files?
Keywords: Mac Kermit, BinHex

Hello, This is Rich Lynch at WVNET.  I just downloaded some of your KERMSRV
files and one of them is a .HQX file which has a comment at the top. The
comment says the file must be converted with the BINHEX Ver 4.0 program.
Is this program available from KERMSRV and if not where might I get a
copy ?  Thanks in advance.

...Rich

[Ed. - BinHex is a "shareware" program for which (to my knowledge) source is
not available.  There is no way for us to distribute binaries on KERMSRV or on
magnetic tape (the explanation is tedious).  BinHex is, however, on our Mac
Kermit distribution diskette, which you can order by mail.]

------------------------------

From: "Roger Fajman" <RAF@NIHCU>
Date: Thu, 17 Sep 87  16:43:11 EDT
Subject: Re:  Kermit Protocol Curiosity
Keywords: 8th-bit Prefixing, Parity

Have you tried setting the parity in Kermit to SPACE?  The 7-bit ASCII
characters will look the same on the line as with parity NONE (8th bit zero),
but Kermit will know that the 8th bit is not available for data and should
request 8th bit prefixing.

[Ed. - Obvious answer, should have thought of it...  Thanks also to Bruce
Cowan of SFU for responding similarly.]

------------------------------

End of Info-Kermit Digest
*************************
-------
22-Sep-87 16:18:31-EDT,26099;000000000000
Mail-From: SY.FDC created at 22-Sep-87 16:17:30
Date: Tue 22 Sep 87 16:17:30-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V6 #22
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 22 Sep 1987       Volume 6 : Number 22

Departments:

  ANNOUNCEMENTS -
        Some LISTSERVers Allowing Info-Kermit Subscriptions (2 messages)

  MS-DOS KERMIT -
        New .BOO File for Intel iRMX Version of MS-Kermit
        Clear Keys on MS-Kermit 2.30?
        MS-DOS Kermit 2.29C Maximum Packet Size
        MS-DOS Kermit 2.29C Problem with IRMA Board
        MS-DOS Kermit 2.29C Send-As Name?
        MS-DOS Kermit 2.29C Color and Intensity
        Losing Interrupts on IBM PC and PS Systems

  VAX/VMS KERMIT -
        Kermit-32 Escape Sequence and VT330 Terminal
        C-Kermit 4E on VAX/VMS Bug Report

  MISCELLANY -
        Native Media for Commodore-64 Kermit
        Kermit and the IBM 7171
        Kermit for Tandy 6000?
        8th-Nit Prefix Bug in Kermit For TRS80 Model IV (M4)

----------------------------------------------------------------------

Date: Sat, 19 Sep 87 15:22:16 FIN
From: The Head of the Post Office <POSTMAST@FINHUTC>
Subject: Some LISTSERVers Allowing Info-Kermit Subscriptions
Keywords: Info-Kermit Digest, BITNET, LISTSERV

There already is a peered LISTSERV-list called I-KERMIT that distributes
Info-Kermit Digest.  (Here it is called IKD for some historical reason...)

This is part of our configuration file for this list.

 *  Peers= I-KERMIT@UGA,I-KERMIT@MARIST,I-KERMIT@TCSVM
 *  Peers= I-KERMIT@CLVM,I-KERMIT@EB0UB011,I-KERMIT@RUTVM1
 *  Peers= I-KERMIT@UBVM,I-KERMIT@DEARN,I-KERMIT@VTVM2,I-KERMIT@BNANDP11
 *
 *  Owner= HAROLD@UGA     (Harold Pritchett)

I think that all the BITNET users could be (should have been ?) transferred
to this list.

Petri Autio

[Ed. - Thanks for the list, Petri!  See next message for more information.]

------------------------------

Date: Tue, 22 Sep 87 11:57:19 EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Info-Kermit Digest Distribution by LISTSERV
Keywords: Info-Kermit Digest, BITNET, LISTSERV

So far, the following BITNET sites have indicated (perhaps indirectly) that
they maintain LISTSERVers capable of handling Info-Kermit Digest
subscriptions.  Thanks to each of these sites for providing this service.

  Node       Country       Name

  BNANDP11   Belgium       Facultes Univ Notre Dame de la Paix, Namur
  CANADA01   Canada        University of Guelph, Ontario
  FINHUTC    Finland       Helsinki U of Technology,
  EB0UB011   Spain         Univ Autonoma Barcelona
  BROWNVM    USA           Brown University, Providence, RI
  MARIST     USA           Marist College, Poughkeepsie, NY
  RUTVM1     USA           Rutgers University, New Brunswick, NJ
  TCSVM      USA           Tulane U Computing Services, New Orleans, LA
  UBVM       USA           SUNY Buffalo, NY
  UGA        USA           U of Georgia
  VTVM2      USA           Virginia Polytech Institute, Blacksburg, VA
  CLVM       USA?          Clarkson U ERC (where is it?)
  DEARN      West Germany  Gesellschaft fuer Schwerionenforschung

Hopefully, we'll be adding CUVMA (Columbia University, NY, USA) to the list
very soon.  Other BITNET/EARN/NETNORTH sites, especially in areas far from
the locations above, are encouraged to volunteer.  Meanwhile, if you're a
BITNET subscriber, please, "TELL LISTSERV AT nearest-node SUB I-KERMIT
your-name".  When you start getting the LISTSERV copy, send a message to
Info-Kermit-Request@CU20B and ask to be removed from our list.  This way,
there should be no interruption in service when the WISCVM Internet/BITNET
mail gateway goes out of service on December 1.

We are also attempting to gradually remove WISCVM dependencies from our own
list.  Last week we sent out a test message to all the BITNET sites on the
Info-Kermit mailing list to see which ones could accept mail directly from
CU20B.  The results are still coming in, but those sites that seem to have
received the mail successfully have had their entries changed to bypass the
WISCVM gateway.

------------------------------

Date: Thu, 10 Sep 1987 08:57 PDT
From: [e-mail] (Jack Bryans)
Subject: New .BOO File for Intel iRMX Version of MS-Kermit
Keywords: Intel, iRMX, RMX Kermit, MS-DOS Kermit

Here's the latest .BOO file for the Intel iRMX version of MS-DOS Kermit,
based on the current 2.29C MS-DOS Kermit development version.  There's also
some acommpanying documentation.

[Ed. - Thanks, Jack!  It has been put in KER:MSTRMX.BOO and .DOC and
MSTRMX * on CUVMA.  Feedback solicited!]

------------------------------

Date: Thu, 17 Sep 1987 15:58 CDT
From: William Bruce Curtis <NU024414@NDSUVM1>
Subject: Clear Keys on MS-Kermit 2.30?
Keywords: MS-DOS Kermit

Is it possible to provide a replacement for the old CLEAR command which
cleared all the key definitions?  When using mskermit to log on to several
different systems it is very convenient to be able to clear all the key
definitions without exiting from mskermit and restarting it.  For example we
use a fairly long take file to customize the keyboard when logging on to CMS
but when logging on to UNIX a vanilla Heath-19 is preferred.  Several users
here have complained about 2.29c's lack of a clear key command.  I realize
that the clear command should clear the port as described in the book but
could we please get some command to clear all of the keys put back in before
2.30 is released?

[Ed. - Yes, 2.30 will contain a command SET KEY CLEAR.]

------------------------------

Date: Fri, 18 Sep 87 11:34:15 CDT
From: James Gregory <[e-mail]>
Subject: MS-DOS Kermit 2.29C Maximum Packet Size
Keywords: MS-DOS Kermit

I'm in the process of putting the most recent 2.29C through its paces.  When
the set send and receive packet commands are issued, the response indicates
there is a maximum value of 9024 bytes, however, the current implementation
only supports 1000 bytes.  Just thought I'd bring this to your attention in
case it was an oversight.  I realize that the 9024 byte limit is supported
by the protocol, however, it seemed you would want the response to be
specific to the current implementation.

[Ed. - Will be fixed in 2.30 to report the actual maximum size.]

------------------------------

Date: Fri, 18 Sep 87 11:19:45 MDT
From: John Shaver Modernization Office <[e-mail]>
Subject: MS-DOS Kermit 2.29C Problem with IRMA Board
Keywords: MS-DOS Kermit, HP Vectra, IRMA Board

I have a Vectra, an HP AT Clone.  I have sidekick and an IBM terminal emulator
called IRMA resident in RAM with 640K.  I have about 450K left.  The
significant difficulty came from 2.29C refusing to let me use COM2 as a port.
I have, am and continue to use Port 2 with 2.29.

[Ed. - From JRD: The serial port handling in 2.29C is much different from
previous releases.  In particular, the port is tested before use.  The
various levels which a user sees are messages such as "Port not available",
"This port uses the Bios", and nothing at all (which is best of all).  The
first message is shown if the Bios work area in low memory indicates the
port was not found by the machine's boot code (COM1 is at 40:00H and COM2 is
at 40:02H, and normally hold 03f8H & 02f8H, respectively).  The second
occurs if the port was found but the UART chip was not the kind which Kermit
can control (an 8250).  Diagnosis then proceeds by noting the kind of
message, removing some add-in software, removing the IRMA board, and finally
calling for help (with additional system details).]

------------------------------

Date: 21 Sep 1987 23:41-CDT
From: [e-mail]
Subject: MS-DOS Kermit 2.29C Send-As Name?
Keywords: MS-DOS Kermit

Thank you for improving Kermit.  The changes have made a menu-driven
system for accessing the host much easier to write.

I have found 1 minor glitch so far - All caps must be used when specifying
the remote file name in the "SEND" command.  If lower case is used, the file
created on the host has a name with ASCII char 22 preceding each letter.
I.e.  using the name "test" as the remote file name will produce a file on
the host named "^Vt^Ve^Vs^Vt".

[Ed. - This is actually a documented feature.  If it was done the other way,
you couldn't specify a lowercase name if you had to.]

------------------------------

Date: Mon, 21 Sep 87 16:21:41 CDT
From: James Gregory <[e-mail]>
Subject: MS-DOS Kermit 2.29C Color and Intensity
Keywords: MS-DOS Kermit, Terminal Color, Terminal Intensity
Cross-Ref: Color, see Terminal Color

When I am using 2.29C as a terminal emulator with "set term color 1 10 37
44", the high intensity character display is behaving questionably.  While
using "more" on a UNIX system (e.g.), the first page will display in high
intensity.  The next and following pages will display in low intensity.  If
I enter the escape sequence "^]c" followed by "connect", characters begin
displaying in high intensity again.  I tested this behavior using the "vi"
editor, also.  When the display went to low intensity, presumably because
the remote system sent the correct escape sequence to cause such behavior, I
escaped back to the local system, reconnected, and entered "^L" to redisplay
the current page.  The page then displayed in high intensity.  If the change
in attributes was the result of character sequences generated by the remote
system, I expected to see consistency.  I assumed the editor was
retransmitting the same escape sequences.

This observation is not new to the current test version.  I withheld
bringing it to your attention earlier.  I thought this type of incident
would be so common that it would either be corrected or accounted for in the
info-kermit digest prior to release of 2.30.

Testing was done on an MS-DOS 3.1 Zenith Z-248 with an EGA.

[Ed. - From JRD: I know what you mean about the intensity bit.  My Unix PC
does the same thing to me.  It's 'ok' though when we realize the host is
explicitly sending a no-bold attribute command every now and then.  Kermit
uses the screen attributes active when Connect begins and they might well be
bold white on blue and switches when the host so commands.  The real dilemma
is PC color screens are unsatisfactory in 'normal' intensity whereas DEC
terminals are good that way.  Also DEC terminals can control the background
intensity but PC's usually cannot.  To provide a variation of intensity
required by the host applications software we are then stuck with normal
meaning rather dim.  It's a pain which IBM needs to address.  Does that help?]

------------------------------

Date: Mon, 07 Sep 87 09:43:06 ULG
From: Andre PIRARD <[e-mail]>
Subject: Losing Interrupts on IBM PC and PS Systems
Keywords: MS-DOS Kermit, IBM PC, IBM PS/2

[Ed. - From a recent Info-IBMPC Digest.]

>...  IBM, 3Comm and Microsoft have been pretty cavalier about losing
interrupts in the past. ... says Billy.

And the beat goes on.  Here is a problem I reported to IBM:

>When a communication program drives an asynchronous adapter by interrupts
>and a national keyboard driver is used, typing while line input is being
>displayed produces screen garbage.  Keyboard interrupts are an infrequent
>and long process and assigned higher priority (1) than frequent and short
>communication interrupts  (3,4) (why?).  Their drivers send the 8259 EOI
>just before IRET, as most regretfully do.  Consequently, even if cpu
>interrupts are enabled, the 8259 will not request communication interrupts
>to the processor until the very end of keyboard interrupt processing,
>which, if excessive, causes communication line overrun.  DOS 3.2 KEYBBE
>(on XT), for example, is near the limit, and causes occasional overrun at
>9600 baud.
>
>But 3.3 KEYB (on PS/2 30!) is far beyond and does it nearly for every
>keystroke.  CTL-ALT-F1ing KEYB (to the original ROM presumably) removes
>the problem.  Rotating 8259 priorities (OUTing C1H to 20H) solves the
>problem for KEYBBE, but not for KEYB (why?).  But assigning the keyboard
>interrupt lowest priority also shuffles the other ones.  In particular,
>the timer interrupts get the next to lowest.  Is this practice advisable?

And some more comments for INFO-IBMPC:

What frightens me is that the problems are worse on 3.3 PS/2 30 than on a
plain XT or AT.  I was expecting maturity from PS/2.

The priorities are as follows (0 highest):

0: timer ticks
1: keyboard
2:mouse (generally)
3,4: communication
5,6: disk and diskette
7: printer

Generally, BIOS and MSDOS as a whole are careful not to disable processor
interrupts too long unnecessarily, even during interrupt processing.  There
could be occasional exceptions to this, but I never experienced any in
communication.

But with the host of available TSR programs hooking onto interrupt vectors,
the situation may change.  If such a program acts as a front end, it cannot
decently enable interrupts without presuming what its followers do and need,
and it will necessarily perform before 8259 EOI anyway.  For this reason,
such programs should act after the original sequence if possible, when
interrupts can be enabled for sure, except for another reason, the stack
growth nightmare.  It is therefore important to write or choose such
programs carefully.  The TSR programs problem is all the more acute as timer
and keyboard interrupts are the most favored for hooks.

[Ed. - From JRD: Columbia sent me a copy of your comments on interrupt
latency when national keyboard sets are employed.  That explains a rash of
comments from PS/2 model 30 users concerning lost serial port characters.
Your comments are exactly on target concerning clearing the 8259 chip.  If
you were to peek at the MS-Kermit/IBM serial port interrupt routine you
would see the 8259 being cleared as quickly as possible before doing the
reminder of the work, for this very reason.  Interrupts are also enabled as
quickly as possible because I know the stack will not grow out of control.
Let's hope that Microsoft/IBM listen carefully.  They are already being told
that OS/2 has severe interrupt latency problems when multitasking Real and
Protected mode windows together.]

------------------------------

Date: 18 Sep 87  8:38 -0600
From: Grant Delaney <[e-mail]>
Subject: Kermit-32 Escape Sequence and VT330 Terminal
Keywords: VAX/VMS Kermit, VT330

A note of caution the Kermit-32 escape sequence is also the terminal reset
and self test sequence for the new DEC VT330 terminal.  The escape sequence
should therefore be changed before a connect if you want to get out again.

[Ed. - Kermit-32's default escape sequence is Ctrl-]C.  C-Kermit's is
Ctrl-\C.]

------------------------------

Date: 17 Sep 87 12:23:00 MST
From: <[e-mail]>
Subject: C-Kermit 4E on VAX/VMS Bug Report
Keywords: C-Kermit, VAX/VMS Kermit

I've just downloaded the newest XK* versions to VAX VMS 4.5.  It compiled
without a hitch, using the XKVKER.COM.  It even transferred a file OK.
However, there are a couple of problems.

I'm running an IBM PC/XT at 9600 Baud using the VTERM 4010 Version 2.0
software from Coefficient Systems Corporation, which supplies a pretty good
VT102 emulation.  Connection is through COM1: to a Gandalf LDS120 line
driver, into a Gandalf (I think) port contender device, thence to a VAX
8600.  No DECNET.  The BLISS version of KERMIT works OK.

-   The SHOW command produces a lot of unprintable characters in the
    header lines of the table ("send" and "receive"), after which
    several of the lines contain gibberish.  After the SHOW, things go
    back to normal (except see below)

-   After many commands are executed, and the C-Kermit> prompt shows,
    typing another command responds with "?invalid - xxx".  Typing an
    erase-line character (CTRL-U on VMS) before doing anything else
    will erase 3 characters of the prompt, indicating that three characters
    must have been received by VMS from the terminal(?)  I can easily
    get around this problem by habitually typing <CTRL-U>command...but who
    wants to?

Is it possible that I need to SET TERMINAL to something different before
executing Kermit?  Or are there indeed spurious characters being sent by
C-Kermit?  At any rate, this version works OK, but the BLISS version is the
system standard here.

Declan A. Rieb, Division 2614           [e-mail]
Sandia National Laboratories            [phone]
Albuquerque, NM 87185-5800

[Ed. - Can anybody help with this?  I've tried the same thing on a VAX 780
with VMS 4.3, but can't make it happen.  There seems to be a recurring theme
over past weeks -- all versions of VMS Kermit (Bliss, C, different releases)
seem to print various kinds of garbage when you give the SHOW or STATUS
commands under VMS 4.4 or later.  What's going on???]

------------------------------

Date: Sat, 19 Sep 87 11:17:47 -0500
From: [e-mail] (Ray Moody)
Subject: Native Media for Commodore-64 Kermit
Keywords: Commodore-64 Kermit, Diskette Volunteers

>[Ed. - A popular request.  Any volunteers?  For that matter, are there any
>volunteers to distribute ANY versions of Kermit on native media for ANY
>systems that Columbia cannot provide?]

This probably is not worth posting, but if you are making a list of people who
can distribute Kermit on native media, we wish to be included.

[Ed. - Yes it is!  We do keep such a list.  It's AADISK.HLP, and we've added
you to it.  I hope others will follow your example and volunteer with disks
and formats that Columbia cannot provide -- the many CP/M formats, 8-inch
diskettes, Xenix Kermit diskettes, SUN tape cartridges, etc etc.]

We will provide Commodore-64/Commodore-128 Kermit V2.0 on a 1541 disk.
(soon V2.1 and maybe Commodore plus-4 kermit.....)  We ask $5.00 to cover
the costs of postage, handling, and the disk.  We stress that Kermit is in
the public domain.  The $5.00 is only so we can recover the costs of
postage, handling and the disk.  We will be able to continue to provide this
service for the foreseeable future.  Please send U.S. funds.  We regret that
we will not be able to provide source code in this format because it will
not fit on a 1541 disk.  Our mailing address is:

         Dr. Evil Laboratories
         P.O. Box 190
         St. Paul, IN 47272

Ray Moody
 [e-mail]
 ihnp4!pur-ee!j.cc.purdue.edu!ray
 [e-mail]

Kent Sullivan
 ihnp4!pur-ee!corvair

------------------------------

Date: Mon, 21 Sep 87 17:10:43 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: Kermit and the IBM 7171
Keywords: IBM Mainframe Kermit, IBM Series/1, CMS Kermit, VTAM, XON/XOFF
Cross-Ref: 7171, see IBM Series/1

I once wrote a communication/ftp program that we have been using on the
Series/1 and 7171 for several years without much problem.  For several
reasons too long to explain here, we decided to convert it to the Kermit
protocol.  It now works beautifully with another micro Kermit or in IBM 370
TTY mode, but the 7171 is such that it causes nasty problems.  I'll explain
them mainly on the IBM370 list, but I think some facts I learned from
experience with my former program can be of general interest to 7171 users.

1) The S/1 style protocol converters run in two modes: terminal emulation
and transparent mode.  File transfer uses transparent mode.  In this mode,
the host (370) outputs data (write phase), then switches to read phase to
get the reply.  The 7171 always uses interrupt driven RS232 I/O to a 340
bytes input buffer (the S/1 uses a smaller buffer, but uses DMA in
transparent mode).  This means that when using packet sizes larger than 340
bytes, XON/XOFF pacing protocol MUST be used.  It implies that the micro
Kermit use it, but also that it not be disabled on the 7171 side.  Failing
that, I/O that once looked OK on a lightly loaded 7171 may suddenly go wrong
when the load increases.  And I have seen what go wrong means: a buffer
overflow may cause complete deadlock of the communication port and need a
DTR drop to recover it.

2) Considering that it is best to always use (or at least allow) XON/XOFF in
file transfer raises another problem.  The 7171 will receive XON/XOFF as
pacing during write phase, but not during read phase.  Moreover, XOFF is
defaulted as an end-of-input character.  It may happen that timing problems
cause an XOFF sent by the external device during write phase to effectively
arrive during read phase and end it with null input.  For this reason,
allowing XON/XOFF as pacing must be paired with disabling XOFF as an
end-of-packet character.  That is the system programmer setting bit X'1000'
at DC00:0008 in the 7171 NVRAM.

3) The 7171 may end an inbound packet prematurely on certain types of
transmission errors I could not determine.  This process looks like
auto-catalytic.  Once started, chances are high the host is assaulted by an
awful lot of short packets it NACKs.  It seems the reason is turning the
line to read phase in the middle of a character the external device
trustfully sends.  Because a single error is multiplied, the 370 Kermit
retry count should be set as high as possible.  On the other side, the
external device (micro) must expect a flood of NACKs in response to a single
packet.  It is therefore essential to purge the input buffer as late as
possible, I do it just before sending the end-of-packet character.
Question: does any Kermit reply before the eop? If yes, it would be better
to purge before sending the checksum.

4) There is no provision in the 7171 to recover from a lost XON, nor in the
370 to timeout.  To avoid deadlock, the micro must implement its own
recovery.  At least XON should be sent to the 7171 after a timeout.  I also
send "clear screen" to allow the host to recover from loosing fullscreen
mode as well as "transmission error reset" and "purge input buffer".  The
last two may be unnecessary, but are harmless anyway.

5) The maximum packet size is 1920, a screensize buffer.  Better use 1900 to
allow for some extraneous characters.  Around 950 is a good choice as little
performance gain is (usually) observed beyond and because it eases faster
resynchronization when two packets stick together.

I think these facts (and maybe others, welcome) will help to run file
transfer with the 7171 much more reliably.

Now that's not all.  There are problems with VTAM and the fact that being a
half duplex device in file transfer mode, the 7171 would normally call for
handshaking.  But I'll continue these, resorting to 370 Kermit internals, on
the appropriate list.

This gives but a faint idea of the mess 370 Kermit people have to deal with.
Believe me how thankful one has to be for their patience and work against a
beast said to be working as designed!

------------------------------

Date: 21 Sep 87 19:19:30 GMT
From: [e-mail] (Kent Hutson)
Subject: Kermit for Tandy 6000?
Keywords: Tandy 6000, Xenix, C-Kermit

Does anyone know where I can find a Kermit program that will work on a Tandy
6000 running Xenix?  I have tried C-Kermit from Columbia, but had a lot of
trouble getting it running.  I would like some suggestions for getting
C-Kermit running if you know what the problem might be.

Kent Hutson
Baylor College of Medicine, Houston, Texas

[Ed. - Others have complained of being unable to get C-Kermit working on the
Tandy 6000.  Previous versions reportedly worked, but it seems that the
system was so slow that the program had to be compiled in a special way.
For one thing, is Tandy Xenix still based on Unix V7?  If so, then you have
to do "make v7" rather than "make xenix" to build the program.  And before
you do that, look in the makefile for special hints about "TRS-80 Xenix".]

------------------------------

Date: 6-SEP-1987 21:32:56
From: [e-mail] (Tom Bourke)
Via: [e-mail]
Subject: 8th-Nit Prefix Bug in Kermit For TRS80 Model IV (M4)
Keywords: TRS-80 Model 4 Kermit
Cross-Ref: Tandy, see also TRS-80

This is a note to explain the problem that arises under the use of Tandy
Model IV Kermit and Kermits that follow the protocol to the last letter.  It
also gives a temporary solution, while I am informing Gregg Wonderly, an
American who wrote the Model IV implementation, but I'll also look into
providing a fix 'cos I'm using the darned thing!

Anyway, on with the problem.  The protocol manual suggests that Kermits make
the best use of the communication lines they have access to.  As a result,
machines communicating over 8-bit lines should use the full 8-bits unless
parity of some form or another is in use.  As a result, if you are using
'proper' 8-bit lines, you shouldn't prefix the 8th bit prefixing character,
'cos you won't be sending any 8th bit prefixes anyway!  The Tandy Model IV
implementation of Kermit ignores this wonderful piece of information and takes
every '&' character as an eighth bit prefix.  As you have guessed this does
wonderful things to program listings! (Especially ones in 'C'!)

The instant (!) solution to this problem is to tell the host machine that it
is dealing with a machine that doesn't like the eighth bit.  SET PARITY
SPACE has been working here on the VAX <-> Tandy Model IV's.  At the same
time, the Tandy Model IV should have eighth bit prefixing turned on.

------------------------------

End of Info-Kermit Digest
*************************
-------
 9-Oct-87 12:51:13-EDT,26114;000000000000
Mail-From: SY.CHRISTINE created at  9-Oct-87 12:50:12
Date: Fri 9 Oct 87 12:50:12-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V6 #23
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 7 Oct 1987       Volume 6 : Number 23

Departments:

  ANNOUNCEMENTS -
        New MSTIBM.BOO for IBM PC MS-Kermit 2.29C
        Maintenance Release 2.3 of Pascal TSO Kermit
        Version 3.79 of Apple II Kermit Available
        Version 2.8 QK Kermit Available
        MS-DOS Kermit 2.29C for RMX
        Release 1.2 of Kermit for HP264x
        New Kermit Documentation in German

  MS-DOS KERMIT -
        Need help with iRMX Kermit
        MS-DOS Kermit 2.29C Session Logging
        Bug in MSTIBT 2.29/tek3
        Kermit with Tek4010/4014 Emulator

  UNIX KERMIT -
        C-Kermit for Tandy 6000
        Tandy Kermit Question in V6 #22
        Suspending C-Kermit
        C-Kermit and Berkeley Unix job control (crtl-Z)
        C-Kermit for Umax 4.2 on Encore
        Minor Bug in C-Kermit under Ultrix
        Modem Control without Carrier

  MISCELLANY -
        Kermit for Convergent Tech Wanted
        Data General One Help Needed
        Re: Data General One Help Needed
        DPS8 Kermit and X25
        AAFILES.DIR on CU20B Kermit Areas
        Kermit-68K Problems for OS-9

----------------------------------------------------------------------

Date:     Sun, 27 Sep 87 18:41 MDT
From:     <[e-mail]> (Joe Doupnik)
Subject:  New MSTIBM.BOO for IBM PC MS-Kermit 2.29C
Keywords: MS-DOS Kermit 2.29C

A new MSTIBM.BOO, dated 8 Oct 1987 is available for testing. This has the
improvements to allow Control-C to kill commands and pop the current TAKE
file with them.  I added a key definition to make Control-@ send a null
character by default, as many have requested.

This edition also has changes to ignore DEL characters when using the VT102
terminal emulator, to implement the \; char pair as a literal semicolon in
Take files and Macros (vs seeing the ; as a comment introducer), to ensure
that error packets emitted before the file capabilities sequence is
completed are sent with a block check of 1 byte, and to apply the SET
DISPLAY 8/7 bit filter to the log file (when DEBUG is active the logging is
forced to 8 bit mode).

And, at long last, the DEC Rainbow version has been updated to 2.29C,
more or less compatible with the IBM version.  The .BOO file for this is
in KER:MSTRB1.BOO.

[Ed. - Thanks Joe!  The new files ahve replaced the old ones in
KER:MSTIBM.*, available thru Arpanet by FTPing to CU20B, user ANONYMOUS (any
password) or thru BITNET using KERMSRV.  We're homing in on the real, final
release of 2.30!  The draft manual for 2.30, which also applies to 2.29C,
remains available as KER:MST29C.DOC, and will change from time to time,
until we get it right... (or until the program we're trying to describe
stops changing).]

------------------------------

Date: 01 OCT 87   15:13  GMT
From: [e-mail]  (F.Buetikofer, Help desk UNI Bern)
Subject: Maintenance Release 2.3 of Pascal TSO Kermit
Keywords: TSO Kermit

After a hot summer while I did not very much additional work on my
TSO-Kermit, I encountered some hidden bugs ... and fixed them.

The biggest problem was a system connected with 300 baud (!) to our
mainframe.  TSO Kermit didn't check for the right Y packet to come in, and
continued sending. This should be fixed now.  Another not official goodie is,
that my kermit should understand attribute packets (they are logged to the
KERMIT.LOG file, so I can analyse what's coming from the micro).

I'm appending the hottest version of Kermit (Pascal and documentation)
so you can put it in the distribution library.

Thanks and regards ... Fritz

[Ed. - And thanks to you!  The new files are in KER:TS2KER.PAS and
KER:TS2KER.DOC.  The other KER:TS2*.* files remain unchanged.]

------------------------------

Date: Wed, 30 Sep 87 08:46:42 PDT
From: Ted Medin <[e-mail]>
Subject: Version 3.79 of Apple II Kermit Available
Keywords: Apple II Kermit

Here are some significant changes from 3.75
1. Command additions/changes
  a. swap bs/del keys
  b. set terminal vt100/vt52/monitor
  c. catalog
  d. delete file
  e. modem - talks to hayes modem via file kermit.modem
  f. set file-type other - if you know the hex type you can set them all
2. Kermit now initializes by reading file kermit.init
3. Kermit now supports //c & //gs
4. Bug fixes by the gross
5. Finally some one wrote a driver for the cps card - thanks Alan Thomson
6. Thanks to the following for their help. Rich Fincher, Mark Johnson,
   Grant Delaney, Paul Close and a host of others who i may have forgot.
   You may have been forgotten but your name is probably in the source
   with the code you inspired.

[Ed. - Thanks, Ted!  The new files have replaced the previous ones in
KER:APP*.* on CU20B, etc etc.]

------------------------------

Date: Fri, 11 Sep 87 13:41 EDT
From: [e-mail]
Subject: Version 2.8 QK Kermit Available
Keywords: QK Kermit, Turbo Pascal, IBM PC, Tektronix Emulation

Version 2.8 adds graphics input (GIN) to the TEK4010 emulation and it provides
code for Hercules card and EGA card inaddition to the regular CGA card.  The
are also other minor improvements and bug fixes, many of which were provide to
me by G.W.Selke.
                              Victor Lee

[Ed. - Thanks!  The files are available in KER:QK*.* on CU20B and QK* * on
CUVMA.]

------------------------------

Date: Mon, 28 Sep 1987 09:38 PDT
From: [e-mail]  (Jack Bryans)
Subject: MS-DOS Kermit 2.29C for RMX
Keywords: RMX Kermit

The latest test release (V2.29C) of MS-Kermit ported to RMX86 and RMX286
includes a completely new and expanded configuration option, the addition of
SET/SHOW KEY, and support for 10 ports.  Previous restrictions on port
redefinition have been removed.  See KER:MSTRMX.DOC for details.
KER:MSTRMX.BOO is for RMX86 and KER:MSTRX2.BOO for RMX286.  The approximate
vintage of the underlying MS-Kermit modules (MSS*) is mid-August.

[Ed. - Many thanks!]

------------------------------

Date: 1987 Sep 28   22:18 EDT
From: (John F. Chandler)   [e-mail]
Subject: Release 1.2 of Kermit for HP264x
Keywords: HP Kermit

At long last, the new release of Rover-Kermit is ready.  The update
consists of new versions of HP264X.ASM, HP264X.HEX, and HP264X.MSS,
and the latter should provide a new HP264X.DOC as well.  The following
are the most important of the changes and improvements in Release 1.2:

 1. Two-byte checksums.
 2. Mnemonic commands for setting parameters.
 3. More elaborate display of current settings.
 4. ^X/^Z interruption.
 5. Retain filespec on RAM file.
 6. Display any characters received while waiting for handshake.
 7. Fixed bug in creating repeat strings from runs longer than 94.
 8. Flush data communication buffer before starting any transaction
    (except the first in a given session).
 9. The ROLL and HOME keys now work for the conversation workspace.

[Ed. - Thanks, John!  The files are in KER:HP2*.*.]

------------------------------

Date: Fri 9 Oct 87 09:36:54-EDT
From: Frank da Cruz <[e-mail]>
Subject: New Kermit Documentation in German
Keywords: German

Gisbert W. Selke of the Wissenschaftliches Institut der Ortskrankenkassen
in Bonn, West Germany, has written an introduction to Kermit for German-
speaking users, with examples from MS-DOS Kermit 2.30 and Modcomp Kermit.
The files are in KER:GERMIT.*, available via anonymous FTP from CU20B,
or as GERMIT * available from KERMSRV at CUVMA on BITNET.  Thanks to
Gisbert for the contribution, as well as many useful suggestions concerning
the new MS-Kermit manual, and "national character" support in MS-Kermit.

------------------------------

Date: Thu, 24 Sep 87 10:28:17 EDT
From: [e-mail] (N. Topping)
Subject: Need help with iRMX Kermit
Keywords: IRMX Kermit

I have been experiencing problems trying to implement the IRMX version 2.41
of Kermit (Kermit version developed by Grinnell College 87/03/04).

I am trying to implement Kermit on an Intel 80286 running iRMX release 6.  I
am unable to receive files from a remote computer.  The iRMX kermit says it
is receiving but never completes or returns any error messages.  I am also
unable to send files using iRMX kermit because kermit aborts with a "FILE
NOT FOUND" error message.  (This error message is printed whether or not the
file to be sent exists.)  I have no clue to what file it is complaining
about.

If anyone has any helpful hints or information about working versions of
iRMX Kermit or how to fix these problems with iRMX Kermit 2.41 please send
mail directly to me at dfs@nadc.

Thanx in advance,
dfs@nadc

[Ed. - Try using the fancy new RMX Kermit that's based on MS-Kermit,
KER:MSTRX2.BOO, announced in the previous message.]

------------------------------

Date: Thu, 24 Sep 87 15:08:14 -0700
From: Richard Nelson <[e-mail]>
Subject: MS-DOS Kermit 2.29C Session Logging
Keywords: MS-DOS Kermit

The new version is excellent - thanks.  I have an IBM/AT with EGA/ECD,
Irma, and internal Hayes 1200B.  When I dial my local Unix system and
LOG SESSION, the ATDT commands appear in the log file in readable ASCII,
but the logged-in Unix session in h19 mode is completely unintelligible.
Screen dumps come out fine.  Since LOG worked fine for me in the last
version I had (v 2.27), this probably isn't a Kermit bug, but I need
assistance/advice in how to correct the problem, since taking a screen
dump won't do for recording long sessions.

Thanks Again,
Richard Nelson
[e-mail]

[Ed. - The next release (the current test release?) now uses 7-bit bytes
for the LOG file if you have SET DISPLAY 7 (which is the default), or if
PARITY is not NONE.  If you have SET DEBUG ON, however, the log file will
have 8-bit bytes.]

------------------------------

Date: Tue, 22 Sep 87 17:37 CST
From: <[e-mail]>
Subject: Bug in MSTIBT 2.29/tek3
Keywords: MS-DOS Kermit, Terminal Emulation

There appears to be a minor bug in the Tektronix terminal emulation in
MSTIBT version 2.29/TEK3.  Sometimes, when the cursor position is supposed
to move without drawing anything, it instead draws a thin black line.
Normally you hardly notice it, but if the program is drawing text, or doing
a lot of short movements and short lines to draw an object, then it can make
the letter or object unreadable.

Kevin Lowey -- University of Saskatchewan Computing Services

[Ed. - This bug report has been forwarded to the author in England, who says
that a new release based on 2.29C will be arriving shortly.]

------------------------------

Date: 2 Oct 87 18:15:50 GMT
From: [e-mail] ( Jim Mower)
Newsgroups: comp.sys.ibm.pc
Subject: Kermit with Tek4010/4014 Emulator
Keywords: MS-DOS Kermit, Tektronix

I'm having some problems getting the Kermit executable from CUVMA
to run on my Zenith 248.  I've downloaded mstibt.boo (ascii
translation of executable) and msbpct.bas (basic conversion program
that creates mstibt.exe from mstibt.boo), run the basic program on
mstibt.boo, got mstibt.exe, ran it and got 'program too large to
fit in memory.'  Has anyone else had this experience or a happier
one?

[Ed. - Apparently the sender of the previous message had better luck.
Maybe you were done in by an ASCII/EBCDIC gremlin somewhere along
BITNET.]

------------------------------

Date: 29 Sep 87 05:26:45 GMT
From: cbmvax!vu-vlsi!devon![e-mail] (Paul Sutcliffe Jr.)
Subject: C-Kermit for Tandy 6000
Keywords: C-Kermit, Tandy Kermit

I have C-Kermit 4D(061) running (very well, thank you) on a Tandy 6000
using Tandy Xenix 3.1.2.

Xenix 3.0 is supposed to be a System III look-alike, but it has alot
of V7 stuff still.  As I recall, though, I used "make xenix" after
having made a few tweaks to the Makefile and some of the .c files.
The "special hints" are mostly directed at the older (VERY V7) version
of Xenix 2.3 (Tandy version 1.x.x).

I'll put together some diffs and pass them along for you to post, if
you want.

Paul Sutcliffe, Jr.

UUCP (smart):  [e-mail]
UUCP (dumb):   ...{rutgers,ihnp4,cbosgd}!bpa!vu-vlsi!devon!paul

[Ed. - Please do!]

------------------------------

Date: Wed, 23 Sep 87 08:43:02 EDT
From: [e-mail]
Subject: Tandy Kermit Question in V6 #22
Keywords: Tandy 6000, Xenix, C-kermit

Regarding your question about the Tandy 6000 in Info-Kermit Digest V6 #22:

I am currently running 4D(061) kermit on such a machine with no problems.
My machine has 512K memory and a 15 Meg hard drive.  It runs at 6Mhz.  I
have not experienced any problems with "slowness", as other's have often
described.  As a matter of fact, my machine is in reality on old Model II
that was upgraded to essentially a Model 16a, which is my case is equivalent
to a Model 6000 now.  Anyway, the Xenix that Tandy current supports is Xenix
3.1.2, which is pretty much like system III.  Note that all the versions of
kermit I have compiled on my machine have been done under Xenix 3.xx.  The
earlier version of Xenix that Tandy put out for the first Model 16's was
done from a version 7 Unix base.  I have had no expericence with the older
Xenix.  However, if you are using that version, you really should pay the
$99.00 to Tandy and upgrade to version 3.xx. (At least it was $99.00 about a
year and a half ago).

Anyhow, to compile C-Kermit on a 6000 under Xenix 3.xx, you need to do
two things:

 1). Look in the source files for the use of identifier "void". If you
     find that identifier in a file, make sure you put  the include
     line "#include <sys/types.h>" at the top of that file with the
     other include statements.

 2).  Say make sys3, and wait awhile.  If your system is fully loaded,
      ie, about 90% full on the hard drive, and little memory, you may
      not be able to compile the program.  Make space on your hard drive
      (down to around 75% free), and try again.  It may take as long as
      a half hour to compile.

Note that I recently compiled the experimental C-Kermit (the "new release")
on a 6000 under Xenix 3.1.2 with no problems, save for the "void" identifier.
 Also note that I am the only user of my machine, ie, I don't have other
 users running out of tty ports.  I can't tell you what running kermit
 is like on a 6000 with 2-3 other users.

I hope this information is of help to Tandy 6000 owners trying to get Kermit
up and running.

------------------------------

Date: Wed, 23 Sep 87 02:29:56 edt
From: [e-mail] (John Dotts Hagan)
Subject: Suspending C-Kermit
Keywords: C-Kermit

I have just installed version 4E(067) on Ultrix-2.0 and have discovered
a change (hopefully a bug).

I used to be able to ^Z (suspend) out of kermit's "C-Kermit>" prompt and
all was cool.  Now it exists and leaves the terminal trashed (in cbreak
mode I believe).

Is this a bug?

--Kid.

[Ed. - Sounds like one.  See next message.]

------------------------------

Date: Thu, 1 Oct 1987 15:27 CDT
From: William Bruce Curtis <NU024414@NDSUVM1>
Subject: C-Kermit and Berkeley Unix job control (crtl-Z)
Keywords: C-Kermit

   Is there a reason that cntrl-Z is trapped in the new release of C-Kermit?
The user document for C-Kermit says that Kermit can be stopped using cntrl-Z
(job control under Berkeley Unix) but the following code in the conint routine
in ckutio.c traps the keyboard generated stop signal (SIGTSTP) and causes the
program to exit.

#ifdef SIGTSTP
        signal(SIGTSTP,SIG_IGN);        /* Keyboard stop */
#endif

I have commented out the code and C-Kermit seems to work fine plus it can be
stopped from the keyboard with ctrl-Z just like the earlier releases.

Thanks,
Bruce Curtis

------------------------------

Date: Saturday 26 Sep 87 3:22 PM CT
From: Jay Ford (U of Iowa) <[e-mail]>
Subject:  C-Kermit for Umax 4.2 on Encore
Keywords: C-Kermit

I acquired the XK*.* files for C-Kermit 4E(067) for use on  an  Encore
Multimax  running  Umax  4.2  (somewhere  between BSD 4.2 & 4.3).  The
"make bsd" ran flawlessly,  but  I  ran  into  trouble  with  the  tty
locking.   The  resulting "wermit" tries to use /usr/spool/uucp as the
lock directory, but we don't have the permissions set to  allow  this.
However,  there  is  a  /usr/spool/locks  directory  which  does  have
appropriate permissions, so I added a make type of "umax"  which  uses
this  path  in  ckutio.c.   Following  are this diffs for ckuker.mak &
ckutio.c.

% diff Makefile.orig Makefile
24a25
> # for Encore Multimax Umax 4.2, "make umax"
211a213,217
>
>
> #Encore Umax 4.2  (between bsd 4.2 & 4.3)
> umax:
>       make wermit "CFLAGS= -DBSD4 -DUMAX -DDEBUG -DTLOG"

% diff ckutio.orig.c ckutio.c
793a794,796
> #ifdef UMAX
>     char *lockdir = "/usr/spool/locks";
> #else
794a798
> #endif /* umax */

------------------------------

Date: Thu, 01 Oct 87 23:52:57 EDT
From: [e-mail]
Subject: Minor Bug in C-Kermit under Ultrix
Keywords: C-Kermit, Ultrix

In C-Kermit 4E(067) 14 Sep 87, 4.2 BSD:
When compiling under Ultrix 2.0, using the vcc C compiler (which is slightly
better than pcc), C-Kermit doesn't compile cleanly, due the the existence
of several #ifdef vax11c lines in some of the .h files.  These have been used
to denote VAX/VMS specific code.  The vcc compiler pre-defines the symbol
vax11c on Ultrix just as it does on VMS.  C-Kermit can be made to compile
cleanly on both Ultrix and VMS if these lines are changed to #ifdef vms.

Keith Moore
UT Computer Science Dept.    Internet: [e-mail]
107 Ayres Hall, UT Campus    CSnet: moore@tennessee
Knoxville Tennessee        BITNET: moore@utkcs1

[Ed. - Thanks for the useful hint!]

------------------------------

Date: Wed, 30 Sep 87 9:39:15 EDT
From: Brian Vaughan <[e-mail]>
Subject: Modem Control without Carrier
Keywords: Masscomp Kermit, C-Kermit, Modems

I am trying to set up Kermit on a Masscomp running RTU 3.1a UNIX with a
Telebit Trailblazer 18000 baud modem (Hayes like). The Kermit used is
version 4.2 and came from Masscomp's user library.

My problem is in controlling the local modem when not connected to another
remote modem (no carrier). The ideal solution is a new kermit command organized
like the DIAL command to get around the unix clocal control.

Does anyone out there know of such an improvement?

Please send a copy of your reply directly to me as I'm not a regular reader
of Info-Kermit.

If a newer version of Kermit includes what I need, could you include detailed
instructions on where and how to pick up a copy? I'm still a little wobbly
in net land.

Thanks in advance.

------------------------------

Date: Fri, 18 Sep 87 15:06:07 EDT
From: [e-mail] (Jim Sanchez)
Subject: Kermit for Convergent Tech Wanted
Keywords: Convergent Technologies,CTOS,BTOS,Burroughs B26

I need a source for or pointer to a terminal emulator supporting kermit for
the Burroughs B26 series workstations.  These are basically convergent
technologies units with a slightly modified CTOS operating system.  I have a
PLM compilier for this system if only sources are available.  Please email
me if you know where I can get such an animal.  Thanks in advance.

Jim Sanchez, Sytek Inc.
301-520-5100
UUCP:..!uunet!pyrdc!gmu90x!sanchez or ..!hplabs!sytek!jim
ARPA: [e-mail]

[Ed. - Presumably, the C-based Convergent CTOS version announced in
Info-Kermit V6 #21 should also work on Burroughs B20-series systems with
BTOS.  Has anyone tried this yet?]

------------------------------

Date: Mon, 28 Sep 1987 13:08 CDT
Sender: L-HCAP List <L-HCAP@NDSUVM1>
From: Bob Puyear <NU025213@NDSUVM1>
Subject: Data General One Help Needed
Written-by: Rick Alfaro  (FidoNet)
Keywords: DG1 Kermit

I recently aquired a DG 1 with an internal modem.  Unfortunately the only
communications program that I hvae found to work with the internal modem is a
special version of Crosstalk for the dg 1.  I am totally blind and use a
speech synthesizer and screen reading software with my system.  The screen
reading program will only voice data written to the screen via normal dos
calls.  Crosstalk takes incoming data and writes it driectly to the screen
thereby making it unavailable to the speech program.  I am trying to find a
shareware program like Procomm or Telix that will work with the DG 1 internal
modem.  Maybe there is a patch available somewhere for one of the exsisting
comm programs.  I would appreciate any info that will help me solve this
problem.  Thanks in advance.  Rick Alfaro

[Ed. - See message below.]

------------------------------

Date: Mon 28 Sep 87 15:17:10-EDT
From: Frank da Cruz <[e-mail]>
Subject: Re: Data General One Help Needed
Keywords: DG1 Kermit

In response to Rick Alfaro's request for a communication program that will
work with the DG/1, doing only DOS calls to the screen, he might want to try
MS-DOS Kermit.  The latest release senses the absence of a true 8250 UART and
then does only DOS calls to the port, and if you "set terminal none", it will
also do only DOS calls to the screen.  Furthermore, if you "set display
serial", its file transfer display will make sense to a speech program (in
fact, this mode was designed specifically for that purpose).  Version 2.29C
of MS-DOS Kermit is available from Columbia University on diskette by mail
order, or over BITNET or other networks.  Feedback about its utility (not only
on the DG/1, but also the IBM PC family or any MS-DOS machine) for the blind
and/or deaf would be much appreciated.  - Frank

-----------------------------

Date: Fri, 02 Oct 87 16:18:40 GMT
From: [e-mail]
Subject: DPS8 Kermit and X25
Keywords: DPS8 Kermit, X.25

   I would like to use kermit on a DPS8 machine runnig GCOS 8

 1) What I understand Kermit DPS 8 is doing:

               +-+
   +------+    |D|                      +------+
   |      |    |A|  asynchronous line   |micro |
   | DPS 8|----|T|----------------------|      |
   |kermit|    |A|                      |kermit|
   +------+    |N|                      +------+
               |E|
               |T|                   virtual terminal
               +-+                   and file transfer


 2) What I would like to do:

               +-+
   +------+    |D|      |  X25  |       +-+        +------+
   |      |    |A|  X25 | public|  X25  |P|asynch. |micro |
   | DPS 8|----|T|------|       |-------|A|--------|      |
   |kermit|    |A|      |network|       |D| line   |kermit|
   +------+    |N|      |       |       +-+        +------+
               |E|
               |T|                              virtual terminal
               +-+                              and file transfer

 I don't know very much about the Datanet
 Anybody thinking that I have any chance to do that ?

What kind of thing I have to do on the Datanet or anywhere else ?  Some
people in France tell me that the data coming out of the Datanet with X25
are always encapsulated in DSA frames. Is that true ?

 I am completely lost ...

 Thank you in advance.

          Gerard H. Gaye
          Cisi-Telematique
          CEN Saclay, BP 24
          91190 Gif sur Yvette
          France

             gaye@frsac11 (bitnet)

------------------------------

Date: Wed, 23 Sep 87 13:39:11 +0200
From: Hans Anton Aalien <[e-mail]>
Subject: AAFILES.DIR on CU20B Kermit Areas
Keywords: AAFILES.DIR

Are you aware that the automatic update of the AAFILES.DIR files has stopped?
If you were not, now you are.  I often found those files useful for more
detailed "detective" work on the distribution areas, so I would like the
service to be restarted.  If you could invent a file name to identify directory
(i.e. tape) as well, I think that would be an advantage -- e.g. AAFIL1.DIR ...
AAFIL5.DIR, AAFILB.DIR, AAFILT.DIR, etc.
            Hans

[Ed. - You're right!  The automatic daily batch job that does this has been
restarted.  Good idea about the names -- they've been changed as you
suggested.]

------------------------------

Date: Sat 19 Sep 87 12:47:34-PDT
From: Bob Larson <[e-mail]>
Subject: Kermit-68K Problems for OS-9
Keywords: 68000 Kermit, OS-9

To build k6 on my FHL QT+ (osk version 1.2, 2.1 is on the way) it needed
a couple of simple fixes:

The reference to "/d0" in the makefile needs to be changed to "/dd".  (/dd
should work on any system configured as recomended by microware.)

The "use defsfile" line in all source modules needs to be changed to "use
/dd/defs/defsfile".  (Again, /dd is the standard place to keep this.)

Connect has a MAJOR problem: it converts incoming /r to /r/l, and ignores
the following /l.  This does not work with systems that put null padding
between (tops20) or with ANY full-screen program.  (My z29 emulates a z29
just fine, thankyou.)  My attempt to fix this did not work.

Oh well, I wasn't in to desperate of need for a third kermit implementation
for my system.  I really should finish the C-Kermit port enough to make it
distributable, and update it to the latest verison of c-kermit.

Bob Larson

[Ed. - Thanks for the comments, Bob.  They've been added to KER:K6OAAA.BWR,
and forwarded to the program's author.]

------------------------------

End of Info-Kermit Digest
*************************
-------
23-Oct-87 15:28:48-EDT,28224;000000000000
Mail-From: SY.CHRISTINE created at 23-Oct-87 15:25:25
Date: Fri 23 Oct 87 15:25:24-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V6 #24
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 23 Oct 1987       Volume 6 : Number 24

Departments:

  ANNOUNCEMENTS -
        RE: Info-Kermit Digest V6 #23 Multiple Copies
        Kermit HEX file for the Amstrad PCW
        MS-DOS iRMX Kermit Documentation

  MS-DOS KERMIT -
        Use of Kermit by the Disabled
        Space Key on MS-Kermit 2.29c
        MS Kermit 2.29C Report or Query
        Problem with Input Translation and 'SET DISPLAY 7'
        Kermit 2.29C VT-102 Emulation
        Kermit-MS v2.29c
        MS-Kermit 2.29c Comments
        Kermit with Zenith COM3
        Printing through a PC (2 messages)

  MACINTOSH KERMIT -
        MacKermit, Key Redefinition
        MacKermit 0.8(35) bug?
        Mac Kermit CKMKEY & XKMKEY
        MacKermit 0.8(35) Can't Save Settings File
        Mac .HQX files

  MISCELLANY -
       Thanks on CONNECT.PASVT100
       Kermit Versions and Packet Size
       VMS: No Default Terminal Line for Transfers

----------------------------------------------------------------------

Date: Wed 14 Oct 87 15:19:29-EDT
From: Christine M Gianone <[e-mail]>
Subject: RE: Info-Kermit Digest V6 #23 Multiple Copies
Keywords: Info-Kermit Digest

You may have gotten 2 different versions of Info-Kermit Digest V6 #23.
The first digest was sent out and was lost somewhere in the network.
Meanwhile, thinking that digest was not sent out, I added some other
messages and sent out yet another version of the digest.  Sure enough,
both copies got sent.  Keep the latest copy (with the German documentation
message in it).  I apologize for any inconvenience this may have caused.

------------------------------

Date: 15-OCT-1987 13:34:27 GMT +01:00
From: [e-mail]
Subject: Kermit HEX file for the Amstrad PCW
Keywords: Amstrad PCW

The system-dependant HEX file for the Amstrad PCW was sent to us by
Phil Wade of Hull University computer centre.

        Regards,
          Steve Jenkins.

[Ed. - Thanks Steve and Phil.  This HEX file is in KER:CP4PCW.HEX available
from Arpanet by FTPing to CU20B, user ANONYMOUS (any password) and GETting
the file or thru BITNET using KERMSRV.]

------------------------------

Date: Tue, 22 Sep 1987 09:00 PDT
From: [e-mail]  (Jack Bryans)
Subject: MS-DOS iRMX Kermit Documentation
Keywords: iRMX Kermit, MS-DOS Kermit

MSKERMIT, the richest and most widely used implementation of KERMIT for the
small computer, has been ported to iRMX86 and iRMX286.  The .DOC file
discusses differences between KERMIT and MSKERMIT, where KERMIT refers to
the RMX version and MSKERMIT refers to the DOS program.  Users unfamiliar
with MSKERMIT may prefer to read this in conjunction with MSKERM.DOC.

[Ed. - Thanks Jack!  The file is in KER:MSTRMX.DOC.]

------------------------------

Date: Tue 20 Oct 87 09:51:19-EDT
From: Frank da Cruz <[e-mail]>
Subject: Use of Kermit by the Disabled
Keywords: MS-DOS Kermit 2.30, Disabled

In preparing version 2.30 of MS-DOS Kermit for release, we are trying to
make the program as useful as possible for people with disabilities like
motor impairment, blindness, or deafness.  This program provides terminal
emulation and file transfer for PCs in the IBM PC family, for IBM
compatibles, the DEC Rainbow, and many other MS-DOS systems, and it is
available free of charge by copying from someone who has it, downloadable
over networks and BBS's, or by mail order for a modest distribution fee
from Columbia University or various diskette services.  There are
several factors that could inhibit Kermit's use by the disabled:

 . The escape sequence to get back to Kermit after connecting to a remote
system is Control-Rightbracket followed by C.  People who can only press one
key at a time should not be required to enter control sequences.  Similarly,
people with only one hand should not be expected to type control characters
beyond their reach.  The new release will allow the Kermit escape-back or
other CONNECT-level escape commands to be assigned to single keys, like F1.
So far so good.

 . The screen display during file transfer has fields for the filename,
the number of packets transferred so far, the number of bytes, etc.  These
fields are updated randomly, so that Kermit's output during file transfer
would make little sense when redirected to a Braille or voice device.  SET
DISPLAY SERIAL remedies this.

 . During terminal emulation, Kermit bypasses DOS and the BIOS and writes
directly to screen memory.  This would also bypass any special drivers
installed by people with voice or Braille output devices.  The command SET
TERMINAL NONE turns off terminal emulation and uses DOS for all screen
writes, allowing DOS or BIOS-level drivers to be used.

 . In order to allow the widest possible range of key redefinitions, Kermit
uses the BIOS to obtain key scan codes, thus bypassing any DOS-level console
drivers, like ANSI.SYS (but not BIOS-level drivers like SuperKey and
ProKey).  Kermit can be directed to use DOS to obtain key codes, but then
the distinction is lost between various keys (like the digit "2" above the
"Q" and "W", and the digit "2" on the numeric keypad).  However, when DOS is
used, there is an apparent problem in DOS itself when multiple characters
are assigned to a single key (involving nonblocking character reads).  Thus
BIOS-level keyboard handling could potentially bypass DOS-level drivers
distributed with special keyboards, but DOS-level drivers could have
annoying restrictions.

Please help us to make the program as useful as possible by answering the
following questions (or offering any other comments):

1. If you are directing screen output to a voice, Braille, or other device,
please let us know what the device is, how the redirection is done, and (if
you know it) whether the redirection is at the DOS, BIOS, or hardware level.
Also, are there screen drivers for the deaf that translate sounds (like the
terminal beep) into special visual effects?  Again, at what level do they
operate?

2. If you have a special keyboard, keyboard replacement, or keyboard driver,
please let us know about it.  Does the driver operate at the DOS, BIOS, or
hardware level?  Does the device look like a real keyboard to the system's
BIOS?

3. What about TDD modems?  Clearly, Kermit or other ASCII-based
communication programs are not compatible with Baudot-only TDD systems.
Translating between ASCII and Baudot is not a practical solution, because
the ASCII alphabet is more than twice the size of Baudot.  Packet-mode
file transfer would be impossible because the Kermit packets could not be
uniquely reconstructed on the receiving end.  Presumably there is movement
in the TDD world away from Baudot to ASCII code?

4. Any other considerations we may have overlooked?

Thanks for your help!

Frank da Cruz
  Columbia University
  Center for Computing Activities
  612 West 115th Street
  New York, NY  10025  USA

Network addresses:
  [e-mail]      (Internet)
  FDCCU@CUVMA                    (BITNET)
  ...uunet!columbia!cu20b!sy.fdc (Usenet)

------------------------------

Date: Tue, 22 Sep 1987 09:36 CDT
From: William Bruce Curtis <NU024414@NDSUVM1>
Subject: Space Key on MS-Kermit 2.29c
Keywords: MS-DOS Kermit

There seems to be an error in the show key command for mskermit 2.29c.
Space, ctrl-space, alt-space and shift space all show up as the same scan
code.  This is also true for the scan program that was mentioned in the
lastest digest (msuchk.boo).  We have an application where we want to define
alt-space to somethng else.

Thanks,
Bruce

[From jrd - ALT/Control/Shift Space all yield the same scan code.  True. The
IBM Bios says the space bar is unaffected by these modifier keys and Kermit
uses largely what the Bios reports. There are plenty of modified Function keys
around (some nearly out of reach above normal keys).]

[From jrd - While on this subject, there have been several requests to allow
the RETurn key to be separated from a duplicate found on some numeric keypads.
This seems reasonable until the regular RET key is undefined and then it sends
nothing at all!  Overall, this is a messy situation because Kermit has no
advance information about the keyboard and which keys send what.  Not only
that, but the duplicate RET may even return the same scan code as the regular
key, depending on which keyboard is being examined.  I've tried my machine with
and without this feature and have ended by cursing it when I've undefined it
once too often without thinking. The subject is not entirely closed but the
odds are not favorable for a neat solution.]

------------------------------

Date: Thu, 24 Sep 87 16:59 EST
From: "GLENN EVERHART, 609 486 6328" <[e-mail]>
Subject: MS Kermit 2.29C Report or Query
Keywords: MS-DOS Kermit

I have been attempting to create a MSKERMIT.INI file for the 2.29c rev of
Kermit and have hit what appears to be a brick wall. The keypad I want to
create basically uses the bottom 4 rows of the IBM AT keypad to look exactly
like the bottom 4 rows of a VT100 keypad, with PF1 thru PF4 mapped to F1-F4 and
F7-F10 acting as arrow keys. This is a particularly easy configuration to
remember and use.

In 2.29b and earlier, SET KEY SCAN could be used this way since the keypad 5
key had a different scan code from the 5 key above the main keyboard. In 2.29c
this appears to have changed. Moreover, it's not clear that ANY definition is
now possible to recapture this desirable behavior, since SHOW KEY now shows the
two "5" keys alike (note I have to be in numlock mode to get any scan code back
at all).

I'd like to request that some disambiguating method be re-inserted in the code
if possible before 2.30 is frozen.  It's very handy to have access to all the
keys, in spite of the IBM screwups in the keypad 5 key case.

    Glenn Everhart
[e-mail]

[From jrd - The most recent version separates the keypad items from the
typewriter top rank aliases, such as the numbers.  Of course, keypad 5 was
damaged by IBM so to use it at all the keypad must be shifted into numeric mode
by either NumLock or Shift keys.  See if the current version is better for your
application.]

------------------------------

Date: Fri, 25 Sep 87 17:18:45 +0200
From: [e-mail]
Subject: Problem with Input Translation and 'SET DISPLAY 7'
Keywords: MS-DOS Kermit

I connect to mainframes which (normally) use 7-bit ASCII characters for text.
By convention the characters [\]/{|} (following ASCII Z/z) are interpreted as
national (Norwegian) letters -- and not the standard brackets/braces, etc.
The IBMPC uses 8-bit ASCII, including the national letters (above ASCII 127).
To use the PC as a terminal, I have six "SET KEY" commands, and corresponding
"SET TRANSLATION IN" commands to do the mapping, the first pair being
"SET KEY \146 \91" and "SET TRANS IN \91 \146".

All goes well with the Aug 12 edition, but with the new (12 Sep) version
(MSTIBM.BOO.18,19 on CU20B), my input translations don't work any more.
But that's just what the latest manual (MST29C.DOC) tells me, too:

"The sequence of applying filters to received characters is: ....
   4. translate if TRANSLATION INPUT is ON
   5. if LOG SESSION is active then copy character to file
   6. pass character to the terminal emulator which does:
          .... else
          if SET DISPLAY is 7-BIT then remove high bit before use."

The TOPS20 and unix systems I use  normally send parity with output characters,
so I rely on (the default) "SET DISPLAY 7-bit".  But then, of course, my newly
translated Norwegian letters are garbled.

Can my problem be solved with another combination of commands?  If not,
could you consider changing the sequence of actions, referred to above?
Or is there another possibility?  I really hope something can be done!

   Hans A. ]lien, Inst. of Informatics, Univ. of Oslo, Norway ([e-mail])

[From jrd - Log file shows high bit in many characters even when Set Display 7
bit is active.  That's the way it is designed presently, logging is done
between the Set Translation filter and the Set Display filter.  Maybe we should
apply the 7/8 bit filter to the log file as well.  On the same subject, some
Unix systems like to send characters with parity almost no matter what one
tells the operating system. On mine, stty -parity does not seem to help much
either, but then that machine wins more battles than me.]

[From jrd - In response to Hans ]lein: It seems that his TOPS-20 system uses
parity frequently and he uses SET DISPLAY to remove the high bit. I think the
proper thing to do is use SET PARITY xxx to remove the high bit from the
communications line and then the two filters above should produce the desired
National characters with SET DISPLAY 8-bit.  Parity of MARK (or occassionally
SPACE) is acceptable to most 8-bit systems and chops off the high bit upon
reception (as well as stimulating 8 bit quoting on file transfers).]

[Ed. - Even though DEC systems like the DEC-20, VAX, etc, normally send parity
during a terminal session, the Kermit programs put the communication line into
8-bit "binary" mode for file transfer, so that 8th-bit quoting is not
necessary.]

------------------------------

Date: Tue, 29 Sep 87 16:01:17 mdt
From: Richard Cook <[e-mail]>
Subject: Kermit 2.29C VT-102 Emulation
Keywords: MS-DOS Kermit

I had noticed the problem with using terminal emulation in 2.29C, but what
seems to be happening is that some programs/utilities will try to use
reverse video when they see a VT-102. The escape characters sent to reverse
the video also reverse the intensity so that if you had white on blue you
get low intensity characters from then on (as in the status line).  This is
"fixed" temporarily by escaping back to the PC (I'm on an IBM AT) and
reconnecting, but the next reverse video flips things back again.  This
happens, for example, when I use the rn program to read Info-Kermit and rn
tries to highlight the subject field.  The problem does not occur with the
original 2.29 Kermit.

[From jrd - Some utilities program the MS Kermit/IBM screen back to dim
(normal) intensity.  That is correct.  The host can change the attributes,
including intensity. The current Kermit is "smarter" and allows the screen to
show two levels of intensity, which are required by some applications.  I think
we are stuck with that behavior until IBM changes matters or I add yet one more
Set Terminal command to change colors rather than intensity.]

------------------------------

Date: Fri, 2 Oct 87 09:10 EST
From: <[e-mail]>
Subject: Kermit-MS v2.29c
Keywords: MS-DOS Kermit

When using Kermit-MS version 2.29c to run GNU Emacs on a Vax, I find that
Ctrl-@, the command to set the mark, no longer works; it just rings the
bell with no other message.  The mark is set properly with version 2.29.
Any ideas would be appreciated.
                                        M. Besson
                                        Villanova Univ.

[Ed. - The new MSTIBM.BOO, dated 8 Oct 1987, announced in Info-Kermit Digest
V6 #23 has an added key definition to make Control-@ send a null character
by default, as many have requested.]

------------------------------

Date: Wed, 23 Sep 87 14:07 EDT
From: "Ken Van Wyk, User Services, ext. 4988" <[e-mail]>
Subject: MS-Kermit 2.29c Comments
Keywords: MS-DOS Kermit

I've been playing with Kermit 2.29c quite a bit and I have a couple
comments/suggestions to make.

First, I really like being able to assign a Kermit "verb" to a key.  This is a
very useful feature that was sorely lacking in earlier versions, in my opinion.
An additional verb that I would like to see is "quit", which actually exits
kermit, regardless of whether or not there are any pending commands in (say) an
MSKERMIT.INI file.

Also, I would *LOVE* to see a command line parameter (say, -F) which instructs
Kermit to read from a file *OTHER* than MSKERMIT.INI.  This would greatly ease
the job of building a menu driven interface (for the rest of the world) around
Kermit.  A command line could then read, for example, KERMIT -F
C:\KERMIT\VAX.INI or KERMIT -F C:\KERMIT\IBM.INI or something like that.  Any
takers?

[Ed. - Good ideas, but no prognosis for whether such a feature will make it
into 2.30.]

Some users have also asked for COM3 and COM4 support in Kermit.  Is this going
to work in 2.30?

[Ed. - 2.30 contains hooks for COM3 and COM4.  See KER:MST29C.DOC for how
to use them.]

Finally, is 2.30 going to work on a Z-100?  Is anyone working on that?  If so,
will it support VT-100 (or 102...)?  I know of a few Z-100 users who would
deeply appreciate this, myself included.

[Ed. - We need a Z-100 wizard to help with this.  Any volunteers?]

Thanks!

------------------------------

Date: Thu, 15 Oct 87 07:47:40 PDT
From: Steve Dennett <[e-mail]>
Subject: Kermit with Zenith COM3
Keywords: MS-DOS Kermit 2.29C, Zenith

There has been some previous discussion of versions of MS-DOS Kermit that
use the (IBM?) COM3 port.  Zenith, in the Z248 (80286) PC sold in large
quantities to the government, includes its own non-IBM-compatible COM3 port
on a board called the Z-304.  One of our programmers is trying to adapt some
comm software for us, and is having a terrible time, and getting information
from Zenith is an uphill battle.

Has anyone successfully adapted Kermit (or any other comm program) to run
with *this* board's COM3 port?  If so, I'd really appreciate pointers to the
code, esp. that used for handling interrupts when receiving information.
Thanks!

Steve Dennett
 [e-mail]

------------------------------

Date: Wed, 14 Oct 1987 08:06 -
From: Peter W. Day <OSPWD@EMUVM1>
Subject: Re: Printing through a PC
Keywords: MS-DOS Kermit 2.29B, Printing

>Date: Wed, 14 Oct 87 12:40:38 GMT
>From: Dermot O'Beirne <DOBEIRNE@IRLEARN>
>Subject: Printing through a PC
>
>Can anyone tell me how to set up our system to allow host printing
>commands to print through the parallel Centronics type and / or second serial
>RS232 ports  of a PC when in VT100 emulation mode using KERMIT 2.29.

Kermit-MS (ver 2.29b) supports a PC-attached Printer using the ANSI defined
sequences

           escape left square bracket 5 i    (Print on)

           escape left square bracket 4 i    (Print off)

Send the "print on" sequence followed by the text to print followed by the
"print off" sequence.  Anything between these sequences will be directed
to the PC-attached printer instead of the screen.

On an IBM computer, you are out of luck unless you can somehow send a character
which gets trabslated to an ESC.  This is possible through a 7171 protocol
converter, but I don't know about other types of IBM ASCII connections.

Peter Day
Emory University

[Ed. - Thanks for the help, Peter.  See Joe's message below also.]

------------------------------

Date: Wed, 14 Oct 87 10:22 MDT
From: Joe Doupnik <[e-mail]>
Subject: Printing through a PC
Keywords: MS-DOS Kermit 2.29C, Printing

Your mainframe can send a pair of escape sequences to the PC which,
if everything is working properly, will relay further bytes directly to the
PC's main printer (PRN).

The sequence to start this "transparent printing" operation is
        ESC [ 5 i       which is Media Copy On or DEC's Controller Print ON
and
        ESC [ 4 i       turns off this mode.

Neither sequence is printed and nothing shows on the screen. This operation
and other similar kinds are described in the manual accompanying MS Kermit
version 2.30 (when it appears sometime next century).

A similar pair drives both the screen and the printer:
        ESC [ ? 5 i     turns it on (DEC's Auto Print On)
and     ESC [ ? 4 i     turns it off again.


Support of these is recent so be sure to get the latest MS Kermit
from Columbia (and yes, it is still volatile).
        Regards,
        Joe D.

------------------------------

Date: Tue, 6 Oct 87 14:17:45 EDT
From: BJ CAMERON (SYSTEMS DEVELOPMENT) <HESSE@WATDCS>
Subject: MacKermit Key Redefinition
Keywords: MacKermit

I recently received a version of MACKERMIT 8(34) from the Bitnet server at
Columbia.  I was wondering if there is a way to access the extra keys
available on the new style keyboards?  Is there a list of scan codes that
get returned for these keys?

[Ed. - Currently, no.  The new keyboards and systems have an entirely
different way of handling the keyboard than is coded into Mac Kermit.  Some
people in various places are working on an update, but there's no estimated
release date yet.]

------------------------------

Date: Mon, 21 Sep 87 16:57:03 EST
From: Bob Blackmun <ACC00RRB@UNCCVM>
Subject: MacKermit 0.8(35) bug?
Keywords: MacKermit

I have downloaded MACKermit 0.8(35) (otherwise known as XKMKER.HQX) from
CUVMA, run it through BinHex 4.0, and find that it changes my keyboard
definition file (created by XKMKEY.HQX) unless I first lock the keyboard
file.  Is this normal?  (I have not had this experience with the previous
(CKMKER.HQX, version 0.8(34)) version.)

[Ed. - Since we have had so many complaints about this, it must be "normal".
Let's hope a new release will appear soon that corrects these and other
problems, especially when Mac Kermit is run on the Mac II or SE.  Meanwhile,
see messages below.]

------------------------------

Date: Mon, 28 Sep 87 10:39:20 EST
From: Bob Blackmun <ACC00RRB@UNCCVM>
Subject: Mac Kermit CKMKEY & XKMKEY
Keywords: MacKermit

We are having problems with CKMKEY 0.8 (6) and/or (7).  Both versions
appear to clobber the terminal file while saving it, even if no changes
are made to the file.  Is anyone else having similar problems?  We have
found that CKMKER 0.8(35) does the same thing unless the terminal file
is locked.   What are we doing wrong!!

[Ed. - Nothing, sad to say.  But see next message.]

------------------------------

Date: Mon 12 Oct 87 22:39:11-PDT
From: Jim Lewinson <[e-mail]>
Subject: MacKermit 0.8(35) Can't Save Settings File
Keywords: MacKermit, Settings

If told to, MacKermit SAYS it is saving the settings file on top of an
existing settings file, but it doesn't really do it.  The old settings
remain.  However, if you save it under a new name, it works just fine.
Then you can rename the new file to the old name and all works nicely.
However, it is a bug.
                    Jim

P.S.  I'll bet you are going to add a message to end of this saying:
    "Added to .BWR file".  :-)

[Ed. - Added to .BWR file.]

------------------------------

Date: Mon, 28 Sep 87 22:57:31 PST
From: [e-mail] (Joel West)
Subject: Mac .HQX files
Keywords: MacKermit, BinHex

Most user groups have a public domain disk that includes

    Binhex V4.0

which is the program for encoding/decoding a complete Macintosh binary file
to printable characters.  If you intend to be sending/retreiving Macintosh
documents or programs from KERMSRV or anyone on the mail system, you should
obtain a copy.  (Also, as noted, it's on the Columbia Mac disk.)

------------------------------

Date: Wed, 23 Sep 87 17:59 EDT
From: [e-mail]
Subject: Thanks on CONNECT.PASVT100
Keywords: QK Kermit

As it turns out, I had downloaded the QK-Kermit on July 20, and the Ctrl-Z
problem got me.  Hadn't bothered looking at it much since then.  Now I have
the right connect file and the KEYTABLE.DAT file, so thanks for the help.
Now for two by-the-ways:

1) Now that it compiled beautifully, seems to be having problems talking to
   KERMIT32 on our VAX, although the terminal emulation is fine.  Haven't
   spent more than an hour on it, though, so haven't really isolated the
   problem.

[Ed. - Try the new version announced in Info-Kermit Digest V6 #23 and see if
that makes the problem go away.]

2) Picked up Frank da Cruz's book, called something like "KERMIT - A File
   Transfer Protocol" a month or so ago, since I'm much more familiar with
   the whims of XMODEM than KERMIT and wanted some help.  It's really
   excellent in all three areas I noted -- as a comm tutorial, a KERMIT
   reference, and programmer's guide.  Thanks to Frank for taking the time
   to write such a readable and thorough explanation of the protocol.  Has
   it been publicized anywhere on the net, or is he being quiet/modest
   about it?

[From Frank - Thanks for the nice words.  There was actually a totally immodest
announcement of it in Info-Kermit V5 #13 (Oct 8, 86).]

Anyway, once more, thanks for the help and the book.

David Escalante

------------------------------

Date: Mon, 12 Oct 87 08:27 EDT
From: [e-mail]
Subject: Kermit Versions and Packet Size
Keywords: Kermit Features

Last week I downloaded Kermit for the MAC, IBM, and VMS.  I found that the
IBM version 2.29b supports packet sizes greater than 90 bytes.  After tring
the MAC 0.8(35) and VMS 3.3.111 I found both of these versions do not have
this feature implemented.  Is there any versions that support larger packet
sizes.  The main reason I would like this version is for file transfers on
our broadband lan.

Is there a table that lists the optimum packet size and data rate.

John Gartley
[e-mail]      CSnet
[e-mail]            ARPAnet

[Ed. - The only versions (so far) which contain long packet support are
MS-DOS 2.29C (soon to be 2.30), CMS Kermit 3.1, PDP-11 Kermit, and VAX/VMS
C-Kermit 4E (the C version, not the Bliss version).  The next time somebody
builds Mac Kermit from the current C-Kermit base, it too should support long
packets.  The documentation of each Kermit program should give "capabilities
at-a-glance" (many do).  Meanwhile, it would be useful to have a document
that lists the features of each Kermit program in a table.  Hopefully, we
will get around to producing such a document.  Volunteers are always
welcome.]

------------------------------

Date: Tue, 13 Oct 87 16:13 N
From: <[e-mail]> (Helmut Feldweg)
Subject: VMS: No Default Terminal Line for Transfers
Keywords: VAX/VMS Kermit

I'm new on this list, so the following question undoubtedly has been
asked before. Still, I don't know the answer:

  We are running KERMIT-32 (version 3.0.051) on our VAX 11/750 running
  VMS 4.4 using logical terminal lines generating terminal names
  like _LTAn: where n increases by one for every user logged in
  since the last shutdown of the system. It happens occasionaly that our
  system managers manage to keep the machine alive without a shutdown
  over a period of time, so 'n' will exceed 999. Our version of KERMIT
  doesn't like terminal numbers greater 999 (= terminal names exceeding
  8 characters). It says 'no default terminal line for transfers' and
  refuses to accept any command. A way out is to create a new process
  via "$ SET HOST node", where the trouble with high numbers doesn't occur,
  but this is a boring procedure.
  Any hints to avoid this?

Helmut Feldweg
Max-Planck-Institut fuer Psycholinguistik
Nijmegen, The Netherlands
e-mail:   [e-mail]

[Ed. - Run version 3.2 or 3.3 of VMS Kermit, which contain a fix for this
problem.]

------------------------------

End of Info-Kermit Digest
*************************
-------
 6-Nov-87 17:28:47-EST,26624;000000000000
Mail-From: SY.CHRISTINE created at  6-Nov-87 17:27:48
Date: Fri 6 Nov 87 17:27:45-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V6 #25
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 6 Nov 1987       Volume 6 : Number 25

Today's Topics:

      New 2.29C Test Version with Support for Enhanced Keyboards, etc.
                       Announcing Mac Kermit 0.9(36)
                 Initial Impressions of Mac Kermit 0.9(36)
                       Use of Kermit by the Disabled
                           Easylink and C-Kermit
                How to Get C-Kermit for Data General AOS/VS?
                                Amiga Kermit
                  VMS 4.6 Bug Report with C-Kermit 4E(067)
           Mapping Kermit65's Vt100 emulation to GS & //e  Keypad
                        MS-Kermit and IBM Mainframes
                          RSTS V7.0 Kermit Wanted
                          More on C64 Kermit V2.0
                 Diffs for C-Kermit 4D(061) and Tandy 6000
                          Long Packets in CD3KERM
                    Long Packet Support in Apple Kermit
                        Tektronix Excerciser Needed

----------------------------------------------------------------------

Date: Mon, 26 Oct 87 21:27 MST
From: <[e-mail]> (Joe Doupnik)
Subject: New 2.29C Test Version with Support for Enhanced Keyboards, etc.
Keywords: MS-DOS Kermit 2.29C, Enhanced Keyboards

I found a safe way to test for the IBM Enhanced keyboard and use it if
found.  The improved keyboard translator was tested locally on a PCs Ltd 386
with the Enhanced keyboard, on two PCs Ltd 286's (one supporting the
keyboard and the other <mine!> with an older Bios which does not), and a
Zenith 151 PC clone which also predates Enhanced keyboards.  Systems having
the new keyboard and a compatible Bios can use F11, F12, the separate arrow
keys, plus digit 5 and asterisk and forward slash keys on the keypad as
essentially new keys.  This means NumLock can be toggled on for a numeric
keypad and still let the separate arrow keys operate as regular arrow keys.

Status and Help displays were tweaked by one column to provide readable
results for 40 column displays.  The terminal emulator works just fine with
40 columns (excepting both the status line and drop down help menu) since I
made the dynamic screen size improvements this summer.  Try DOS MODE CO40 or
similar to see this in action.

This one also fixes (?) the reported problem of an extra character occurring
between the packet's EOL and Handshake chars causes loss of the packet, and
it fixes a mangled Set Handshake command (crunched in a general cleanup
recently).

        Regards,
        Joe D.

[Ed. - Thanks, Joe!  The new version is, as usual, in KER:MSTIBM.BOO, and
the manual draft, KER:MST29C.DOC, has been altered to reflect the new
changes.  This release, however, has (at least) one minor bug.  ASCII RUB
(DELETE) appears on the screen as a little house.  You can fix this by putting
the following statements in your MSKERMIT.INI file:

SET TRANSLATE INPUT ON
SET TRANSLATE INPUT \127 \0

This glitch will be removed in the next (pre)release.]

------------------------------

Date: Wed, 28 Oct 87 18:43 GMT
From: <[e-mail]>
Subject: Announcing Mac Kermit 0.9(36)
Keywords: Macintosh Kermit

Some times ago Carlos Albuerne was so kind to pass my Modula-2 version
of Kermit to you. In his letter he mentioned that you might be glad about
some help with the Macintosh version. So I'm happy to be able to send
you a new enhanced binary version of the program. It's a port to MPW C
including many bug fixes and new features. Here is a short (unordered and
incomplete) list of the changes I made to the program:

# The Cursor with open desk accessories now works correctly
# Long packets now supported
# Dialog boxes cleaned up
# New program icon
# Settings files are no longer TEXT
# Changed "Restore ResourcesE" to "Load ResourcesE"
# Reformatted many parts of the source to be better readable
# Settings can now be written back to an already existing settings file
# Server mode: added directory listing feature
# Added multifile (folder) send
# Added Server "Delete" file command
# Added Server "Space" command
# Server mode: Stop Alerts are not displayed (e.g. User cancelled transaction
  stopped server operation)
# Get whole folder content from the server with filename ":"
# Menu command keys added to menus
# Support of menu command keys
# Menu command key and FKEY flag now saved with settings
# Accept end of transmission with keydown (not only mousedown)
# Added terminal settings dialog
# Added non-transparent terminal mode
# Added smooth scrolling option to terminal emulation
# Added underline cursor option to terminal emulation
# Added display of protocol version to "About Kermit" dialog.
# Fixed a bug in ckmtio which caused problems with the parity bit when
  receiving form an IBM host for example.
# Added a simple Take file interpreter
# Added session logging
# Added transaction logging
# Added a completly new keyboard management (CKMKEY is no longer necessary)
# "Keep" flag settable by user
# statistics in about dialog
# rewrote parts of the window handling routines: windows are now
  highlighted according to the userinterface guidelines

Thanks to the good code generation of the MPW C compiler just porting the
source saved about 20 kBytes of binary code. Rewriting parts of the source
saved some more kBytes. This results in a new version with all the new
features added but about 6 kByte smaller than version 0.8(35).

I hope you will like the new version which I think could be called 0.9(36).
Please tell me where and how to send the source code (preferably a BITNET
address). Today I read about Paul Placeway of Ohio State University who seems
to be working on a new version too.  Unfortunately I don't have an address to
contact him directly. So I leave it up to you, how to handle the integration
of the sources. Unfortunately I will not be able to continue the work on
MacKermit at the moment, because the company who payed for the three weeks of
development wants me to do some work which pays for them too. Nevertheless I
will try to write a documentation for the new version. I will keep you
informed about this.


Matthias Aebi

PS: Please do not try to reply via the source address of this message. I
normally do not have access to this account. Use one of the two adresses below
instead:

BITNET:   K116430@CZHRZU1A
USENET:   ...!mcvax!cernvax!unizh!aebi

[Ed. - Many thanks, Matthias!  It should be noted that this contribution came
out of the blue, and it may or may not be reconciled with other work in
progress.  Thus, it may become the "mainline" Mac Kermit, it may become a dead
end, or it may be integrated with the work of some other people.  But if it
works as advertised, it should be a definite improvement on the current
versions, so please take it and try it out.  Reports and reviews are most
welcome.  Does it work on all Macs?  All but the original 128K Mac?  Support
old and new keyboards, file systems, etc?  Meanwhile, we're making an attempt
at getting Matthias's sources to other Mac Kermit developers in hopes of
combining the best of all versions.]

------------------------------

Date: Thu, 29 Oct 87 17:07:50 PST
From: [e-mail] (Dave Platt)
Subject: Initial Impressions of Mac Kermit 0.9(36)
Keywords: MacKermit

I've spent the last half-hour playing around with Kermit 0.9(36) on a Mac
Plus running System 3.2, connected via a 9600 baud hardwired line to a TIP
which opens TELNET connections to various local hosts in-house.  I tested
0.9(36) against 4E(067) running on a Vax 8650 under Ultrix 1.2.

Notes from my fiddle-about:

1) I was able to puzzle out the method for remapping some of the keys
   on the Mac Plus keyboard to do what I wanted.  The big clue was that
   one persuades Kermit to send a control character by using the
   sequence "\nn", where "nn" is the decimal representation of the
   ASCII character desired.  Unfortunately, it's difficult to confirm
   the setting of a key that has been mapped in this fashion;  when you
   hit the same key to check the setting, you typically see a small
   empty box (the standard "Unassigned font code" character in the Mac
   font structure).  It'd be nicer if Kermit reconverted unprintable
   characters to the \nn notation before displaying them.

2) I wasn't able to figure out how remap a key so that it would send a
   Break.  This was possible under 0.8(34) and (35) using a _very_
   obscure function mapping;  I haven't discovered the equivalent under
   0.9(36).

3) The send and receive packet-sizes, and perhaps some of the other
   protocol-related information, isn't being restored properly when you
   load a settings file;  the packet size returns to the default of
   90.  Some of the protocol information (block-check type, for
   example) is being saved and restored properly, though.

4) The screen image is not restored properly after a dialog box is
   erased (e.g. after a download, or after changing the settings).  The
   problem appears to be most acute if the screen was trying to scroll
   during the erase-and-refresh process;  I suspect that the scroller
   and the screen-refresher are stepping on each other's feet.

5) The ability to receive 900-byte packets makes an _amazing_ different
   in the speed of a download in my 9600-baud TELNET environment.

6) If you save a settings file "on top of" an existing settings file
   of the same name, 0.9(36) does not copy the old version's
   window-placement information when it creates the new version.
   This is most noticable if the old version had been moved onto the
   Mac desktop;  the new version is not visible on the desktop, but is
   instead found in the disk's (or folder's) window.  0.8(34) did this
   correctly, by copying the old version's window/position information.

7) I like the smooth scrolling, and the ability to use a thin-underline
   cursor rather than an eye-searing blinking-block.

Conclusion: not at all bad for a beta version;  it'll really be nice
when the current set of glitches are tracked down and persuaded to
move to Tumbolia.

Here are the results for the Mac II:

1) I had noticed that some of the field labels in the protocol-setup
   box were either misplaced, or only partially present, when I ran
   0.9(36) on a Mac Plus under System 3.2.  These fields all appear to
   be OK when the same version of Kermit is run under System 4.1 on
   my Mac II.  I'm not sure whether the difference is in the System
   itself, or in the fonts.

2) The scrolling/refresh conflict I noticed on 3.2/Plus is also present
   in the 4.1/Mac II environment.

3) I reported that some of the protocol-configuration information wasn't
   being saved and restored in the settings files.  I found last night
   that the "send packet-length" information is saved and restored OK,
   but that the "receive packet-length" always reverts to 90.

4) Smooth scrolling on a Mac II in 8-bit-pixel mode is incredibly slow
   (much slower than smooth scrolling on a Plus).

5) Over a 1200-byte dialup line to a Tip which was telnet'ed into a
   Sun 3/110 running SunOS 3.4, 800-byte packets worked just fine for
   both "send file" and "receive file".

------------------------------

Date: Mon, 26 Oct 87 09:21:11 PST
From: [e-mail] (Dave Platt)
Subject: Use of Kermit by the Disabled
Keywords: Disabled, MacKermit

I might suggest that people with motor impairment might wish to consider
running CKMKER on a Macintosh, and make use of the new "Easy Access"
capabilities of the Macintosh operating system.

"Easy Access" is a standard, free (bundled) utility which permits the use of
the Macintosh window environment with a single finger (or any similar
manipulating digit such as a mount-stick, forehead-mounted pointer, etc).  It
includes several capabilities, including "sticky keys" (touching a modifier
key such as Shift or Option once will "press" it for the duration of the next
keystroke; touching the modifier twice will "lock" it until it is touched a
third time) and "Mouse keys" (permits the user to move the cursor around on
the screen by using the arrow keys on the keypad, and "click" the mouse button
by typing a single digit on the keypad).

Of course, "Easy access" doesn't solve any of the problems relating to
Braille output, voice output, etc.

------------------------------

Date: Fri, 23 Oct 87 10:05:59 EDT
From: pisces![e-mail] (Ian Wells)
Subject: Easylink and C-Kermit
Keywords: C-Kermit, Easylink

I would like to use Kermit (C-Kermit) with scripts to upload and download
electronic mail to Easylink - Western Union's electronic mail system.

I am planning on using this from a Sun running Berkeley Unix and a Motorola
system in Europe using System V Unix.  Who should I contact to find someone
who might have written such a script?

(-: IanWells COMPASS Wakefield MA USA think!compass!wells [phone] :-)

------------------------------

Date: 13 Oct 87   13:40
From: BRADLEJP@SNYPLABA
Subject: How to Get C-Kermit for Data General AOS/VS?
Keywords: Data General Kermit, AOS/VS Kermit, C-Kermit

It appears that there is a beta version of Kermit in C for AOS/VS.  I have a
directory of the files on KERMSRV, and believe that the necessary files have
XKD as the first three letters.  Is this correct?

Assuming that your response is yes, we would like to receive these files via
BITNET, but have some questions about the KERMSRV commands.  We will be making
the request from a Burroughs A-10 mainframe (not having a BITNET
implementation for our DG machine).  Are the files ASCII text files, or are
some of them binary?  We understand that the files are in "V-format," but are
not sure what this means (no experience with the IBM world).  Could you please
tell me what the physical layout of the files is, and what KERMSRV command
would be best to use to request them?

Thank you very much

[Ed. - The files are all ASCII text.  The binaries are encoded printably,
and a decoder is included among the XKD*.* files.  The ones you need are
XKC* *, XKU* *, XKW* *, and XKD* *.  Tell KERMSRV at CUVMA to send you each
of these groups.  Once you get them, you have to rename XK*.* to CK*.* if
you want to compile from source.]

------------------------------

Date: Fri, 16 Oct 87 21:31:24 CDT
From: Phil Howard <PHIL@UIUCVMD>
Subject: Amiga Kermit
Keywords: C-kermit, Amiga Kermit, VM/CMS Kermit

I have obtained all the files identified in the file CKIAAA.HLP from the
BITNET Kermit server.  I FTP'd these to a UNIX system and then downloaded them
to my Amiga using an older version of Kermit that was already on a disk
someone gave me.  My C compiler has not arrvied yet so I can't compile the
source but I did go ahead and run the basic program (CKIBOO.BAS) to convert
the boot file (CKIKER.BOO) into what I thought should be a runnable file.  The
file did not run and AmigaDOS said it was not a runnable object program.  It
had almost the same size as the older one, and the beginning stream of
characters was similar as best as I could it by typing them on the screen.

1.  Is that the proper procedure, to convert the boot file into a runnable
    object program?

2.  Does anyone who is on a VM/CMS system on BITNET have an already converted
    runnable object program that they know work (cause they ran it) that
    they can send me?  I would prefer it be sent from a VM/CMS to a VM/CMS
    system to be sure it does not undergo brain damage from ASCII/EBCDIC
    conversion gremlins; remember it's a binary.

[Ed. - The problem is probably ASCII/EBCDIC gremlins as you surmise.  No one
else has complained so far, but then we have no way of knowing if anyone
else has tried this yet!  Can anybody help?]

------------------------------

Date: 19 Oct 87 10:49:00 EDT
From: "ETD1::LABOVITZ" <[e-mail]>
Subject: VMS 4.6 Bug Report with C-Kermit 4E(067)
Keywords: VAX/VMS Kermit, C-Kermit

I have just compiled the source modules for C-Kermit 4E(067) under VAX/VMS 4.6
on our VAX 11/785, using the supplied XMVKER.COM file.  During the final
link of the KERMIT executable, the following warning message is produced
by the linker:
    %LINK-W-MULDEF, symbol SYSTEM multiply defined
        in module C$UNIX file SYS$COMMON:[SYSLIB]VAXCRTL.OLB;1

While I have not had a chance to confirm this with our DEC Software Analyst
(he's on vacation until next week), this seems to be directly attributable
to the new VMS 4.6 C Run Time Library.

Other than producing a warning message, however, our new version of KERMIT
seems to be running well thus far.  If any other problems arise, I will forward
them to Info-Kermit, otherwise it will soon replace our current version
of KERMIT-32.

                    LT Stuart Labovitz
                arpa:    [e-mail]
                arpa:    [e-mail]

[Ed. - Thanks for the report.  It's been forwarded to the new C-Kermit/VMS
developer and added to the XKVKER.BWR file.  Since compilation and linking
were tested with VAX-11 C 2.3 on VMS 4.6, and this problem didn't arise,
the culprit is indeed most likely the runtime system.]

------------------------------

Date: 21 Oct 87 20:57 -0600
From: Grant Delaney <[e-mail]>
Subject: Mapping Kermit65's Vt100 emulation to GS & //e  Keypad
Keywords: Apple II Kermit, Kermit-65

For version (3.79): The attached patch when executed will Apple Kermit's Vt100
function keys into the Keypad.  You will still have to use Open-Apple with the
keypad keys.  This should also work with Apples numeric keypad

       Key Pad                       VT100 Function Keys
 ___________________________________________________________________
|       |        |       |       |         |       |FNDNXT | Dellin |
| clear |   =    |   /   |   *   |   Gold  | Help  | Find  | Undlin |Gold
|--------------------------------|----------------------------------|
|   7   |   8    |   9   |   +   |  Page   |section|append | DLword |
|       |        |       |       | command |  Fill |Replace|Undlword|Gold
|--------------------------------|----------------------------------|
|   4   |   5    |   6   |   -   | Advance | Backup| Cut   | DelChar|
|       |        |       |       | Bottom  |  top  | paste |undlchar|Gold
|--------------------------------|----------------------------------|
|       |        |       |       | word    |  EOL  | Char  |        |
|   1   |   2    |   3   |       | ChngCas | DelEol|SpecIn | Enter  |Gold
|------------------------| enter |-------------------------|        |
|                |       |       |     BLine       |Select |SubStit |
|       0        |   .   |       |   OpenLine      | Reset |        |Gold
_________________|_______|_______|___________________________________

 ==========================  cut here ==========================
BLOAD KERMIT379
CALL -151
6AFB:2E 18 3D 2F 2A
6B00:37 38 39 2B 34 35 36 2D 31 32 37 38 39 2B 34 35
6B10:36 2D 31 32 33 0D 30
BSAVE KERMIT379.GS,A$1000,L$6900

[Ed. - Thanks, your message has been added to the APPKER.BWR file.]

------------------------------

Date: Tue, 13 Oct 87 09:59:53 EDT
From: Claude Goldman <CLAUDE@BROWNVM>
Subject: MS-Kermit and IBM Mainframes
Keywords: MS-DOS Kermit, Protocol Converters, IBM Mainframe

I have several questions/suggestions about using kermit on an IBM PC
to connect to IBM mainframes via a 7171's.

1 - Is it possible to indicate the status of the VT102 status lights
    in some way?  In particular it can be very frustating not knowing
    when you are or are not in insert mode.

[Ed. - The four VT102 LEDs are shown in the Kermit mode line.  But they
don't necessarily reflect whether the terminal is in insert mode, only
that the host sent the sequences to turn the lights on or off.]

2 - When emulating a 3270 type terminal it would be very handy to be
    able to assign different colors to different field attributes, i.e.
    protected/unprotected high/low, foreground/background (now possible),
    etc.   This would be handy for full screen programs in Rexx, Xedit,
    Focus, etc.

3 - I could not do ascii file transfers when parity was set to none.
    Any ideas why?

[Ed. - Because the 7171 and IBM mainframe use parity.  If you don't tell
MS-Kermit about this, checksums will appear to be wrong.]

------------------------------

Date: Sat, 17 Oct 87 12:24 GMT
From: <[e-mail]>
Subject: RSTS V7.0 Kermit Wanted
Keywords: PDP-11 Kermit, RSTS Kermit

I am here with Hansruedi and we are looking for a way to connect a PDP-11/34
running under RSTS V7.0 to a 11/73 under RSTS V9.3.  For internal reasons we
would like to keep V7.0 on the old machine and therefore we are looking a
RSTS-Kermit for V7.0.  We asked Brian already for that problem, and he says he
is not sure whether he still has such an old backup binary version of
RSTS-Kermit, because compiling the old source on his new 9.5 RSTS will not
necessarily garantee to run on our old machine. Therefore, would you know of an
existing RSTS V7.0 runnable Kermit ( HLP- and EXEC-files) or would it possible
that you deposit an "Wanted" call into the KERMIT-infobox.  Hoping to find in
our account some morning such a nice RSTS V7.0 version of KERMIT.  Thanking you
in advance, we remain with best regards also from Hansruedi

otto.

------------------------------

Date: 14 Oct 87 21:36:54 EDT
From: FFO04688@UDACSVM
Subject: More on C64 Kermit V2.0
Keywords: Commodore 64 Kermit

I have had some success with the new version of Kermit.  It seems to do a
pretty good job of supporting the VT100 protocol.  A couple of things that I
noticed:

  1.  Boot file dosen't work properly.  I have to load the main file and
      run it.

  2.  Delete key on keyboard is mapped as Rubout (very annoying)  You
      have to press the F7 key for backspace.  This can be dealt with
      (at least on UDEL vaxes) by issuing an 'stty dec' command to the
      c-shell.  This could probably be fixed via a custom termcap entry
      (or more drastically) changing the program's translation table.
      Note:  This could be a problem with our VT100 termcap, but I
             doubt it as I have never had a problem with any other
             VT-100 emulators.

  3.  Send command dosen't seem to work properly with C-kermit's receive,
      I have to put the host into server mode and issue commands to the
      server to transfer files properly.

I'm interested in hearing about anyone else's experiences with the package.

Rob Elkins
ARPA:  relkins%trillian@udel-relay

------------------------------

Date: Wed, 21 Oct 87 22:20:18 EDT
From: cbmvax!vu-vlsi!devon![e-mail] (Paul Sutcliffe Jr.)
Subject: Diffs for C-Kermit 4D(061) and Tandy 6000
Keywords: C-Kermit 4D(061), Tandy Kermit

In Info-Kermit Digest V6 #23, I said I'd send the diffs along to compile
C-Kermit on a Tandy 6000.  Here they are.  Note that they assume that one is
running Tandy Xenix 3.0 or greater.

Install these diffs in the "stock" 4D(061) C-Kermit distribution, and then
type "make trs16" to compile.  In reality, you only need to make the
modification to the makefile (ckuker.mak); the other diffs just make the
startup banner agree with the operating system version -- I didn't like
kermit saying "Xenix/286" on my 68000!

- paul

[Ed. - Thanks!  Just the makefile entry is reproduced below.  The full diffs
have been added to KER:XKUKER.BWR.]

#Tandy 16/6000 with Xenix 3.0
trs16:
    make wermit "CFLAGS= -DTRS16 -DXENIX -DUXIII -DDEBUG -DTLOG \
        -DM_VOID -Dvoid=int -F 3000 -n" \
         "LNKFLAGS = -F 3000 -n"

------------------------------

Date: 24 OCT 1987  20:36 EDT
To: <[e-mail]>
From: Steve Roseman <[e-mail]>
Subject: Long Packets in CD3KERM
Keywords: CDC Kermit, Long Packets

    My feelings are crushed!  In V6 #24, you didn't mention that long packet
support has been in CDC Cyber Kermit V3 (CD3KER) since March.  The guy 'Ed.'
who makes comments on each letter to Info-Kermit forgot about us.  Just
because Cybers aren't as popular as VAXes, IBMs, and PCs.....

Steve Roseman
Lehigh University

[Ed. - Oops, sorry!  Cybers might not be as popular as IBM PCs, but one
Cyber costs about as much as about 1000 of them...]

------------------------------

Date: Mon, 26 Oct 87 12:13:49 PST
Subject: Long Packet Support in Apple Kermit
From: Mick Laver (ACC Microconsulting) <[e-mail]>

Re: Your response to John Gartley about long packet support (KD 6:24).

The Apple II Kermit (ver 3.79) also supports packets up to 250 characters.
Use SET RECEIVE (OR SEND) PACKET FA (or less).  It works well with C-Kermit
4E(067).

Mick Laver, C-010                 Internet:  [e-mail]
UCSD Academic Computing Center    UUCP:     ...!sdcsvax!sdcc3!zz1ml
La Jolla, CA.92093            BITNET:         [e-mail]

[Ed. - Oops again.  This all comes from not having a comprehensive database
of what Kermit versions have which features.  Someday...  For that matter,
add the new Mac Kermit 0.9 to the list.]

------------------------------

Date: Fri 30 Oct 87 16:48:53-EST
From: Frank da Cruz <[e-mail]>
Subject: Tektronix Excerciser Needed
Keywords: VAX/VMS, Tektronix Emulation

Does anybody have a VAX/VMS program that will put a Tektronix 4010 emulator
through its paces?  If you're willing to contribute to development and testing
of a new Kermit release, please send your program to me by electronic mail
(if it's not too huge) in hex format (as produced by the VMSHEX program that's
supplied with VMS Kermit).  Thanks!

Frank da Cruz
[e-mail] (Internet)
FDCCU@CUVMA               (BITNET)

------------------------------

End of Info-Kermit Digest
*************************
-------
11-Dec-87 17:10:26-EST,29573;000000000000
Mail-From: SY.CHRISTINE created at 11-Dec-87 17:09:25
Date: Fri 11 Dec 87 17:09:25-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V6 #26
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 11 Dec 1987       Volume 6 : Number 26

Departments:

  ANNOUNCEMENTS -
        Japan DECUS, November 1987
        New Release of DEC-20 Kermit
        Latest Test Release of RMX86 & RMX286 Kermits
        OS-9 Kermit Available for Eltec Eurocom-3
        KERMIT File Protocol on COMPUSERVE
        Finally Kermit on Compuserve
        FTPing Files From Columbia
        Kermit Network File Organization

  UNIX KERMIT -
        RE: VMS 4.6 Bug Report with C-Kermit 4E(067)
        Re: Amiga Kermit
        C-Kermit on Apollo
        C-Kermit on Minix?

  Macintosh KERMIT -
        MacKermit with multilingual 7171
        [Andre PIRARD: MacKermit with multilingual 7171]
        Mac Kermit 0.8(35) on the Mac II
        MacKermit 0.9(36) Initial Impressions
        MacKermit 0.9(36) B3 Testing
        Macs, Versaterm and Kermit Errors

  MISCELLANY -
        IRMX86 Kermit -- I've found it!

----------------------------------------------------------------------

Date: Thu 10 Dec 87 09:40:03-EST
From: Frank da Cruz <[e-mail]>
Subject: Japan DECUS, November 1987
Keywords: Japan DECUS, DECUS

Sorry for the long delay since the last Info-Kermit digest.  The week of
November 16, we were in Japan at the invitation of Japan DECUS to make
presentations at the 1987 Japan DECUS Symposium and at NTT, which was quite
an experience.

The DECUS presentations were accompanied by simultaneous translation into
Japanese, for which the attendees, usually about 80-100 per session, wore
special headsets, like at the UN.

Our first presentation was "Kermit, Current Status, Future Directions," in
which 30-minutes were devoted to Kermit history, philosophy, the mechanics
of Kermit development and distribution, and an overview of some of the new
and forthcoming Kermit releases; a brief technical talk was given on the
Kermit protocol performance enhancements (data compression, long packets,
sliding windows); and Ken-Ichiro Murakami of NTT, Japan's "Kermit-san",
spent some time speeking about special considerations for use of Kermit in
Japan -- versions for Japanese computers, use of and conversion among the
various Japanese character sets, Japanese translations of the Kermit
manuals, etc.  (Some of this session got written up in Nov 30 Digital News,
Page 10.)

A 3-hour "Fast-Paced Kermit" course was also conducted for about 40
students, consisting of 2 hours lecture and an hour of practice (using PCs
and a MicroVAX running VMS), with Japanese translation.

We were charmed by the hospitality and generosity of our hosts, and we were
pleasantly surprised at the high level of knowledge of, interest in, and
support for Kermit in Japan.

- Chris & Frank

------------------------------

Date: Fri 11 Dec 87 15:34:19-EST
From: Frank da Cruz <[e-mail]>
Subject: New Release of DEC-20 Kermit
Keywords: DEC-20 Kermit

I never thought I'd touch this program again, but it contained a thoughtless
restriction, namely that it wouldn't let you issue commands to servers unless
you were in local mode (e.g. after dialing out through another line).  This
prevented you from putting a bunch of commands (multiple SENDs and/or GETs,
followed by FINISH) into a TAKE file, TAKing the file, escaping back to the PC
and putting it in server mode.  The new release, 4.2(260), removes this
restriction so long as the commands (like GET, FINISH, BYE) are issued from
TAKE files.  The old problem of inferior process capabilities not getting set
right, e.g. after a PUSH command, is also fixed.  The new version is in
KER:K20MIT.MAC on CU20B.  - Frank

------------------------------

Date: Tue, 01 Dec 87 10:52:47 PST
From: [e-mail]  (Jack Bryans)
Subject: Latest Test Release of RMX86 & RMX286 Kermits
Keywords: RMX Kermit

The latest version mostly brings the RMX Kermits up to date with more recent
MS-Kermit sources.  The documentation (MSTRMX.DOC) has been edited to clarify
issues reported by users and to include information on obtaining Terminal
Support Code fixes from Intel for the ^W problem.

[Ed. - Thanks Jack!  The new files have replaced the old ones in
KER:MSTRMX.BOO, KER:MSTRX2.BOO, and KER:MSTRMX.DOC.]

------------------------------

Date: Mon 2 Nov 87 18:37:00-EST
From: Frank da Cruz <[e-mail]>
Subject: OS-9 Kermit Available for Eltec Eurocom-3
Keywords: OS-9 Kermit, Eltec Eurocom-3

I got the following letter....                      21 October 1987

"I appreciate very much the idea of Kermit and I'm a happy user of OS-9
Kermit, VAX-Kermit-32, and the Kermit facility of Smarterm (MS-DOS).
Therefore I like to offer my knowledge and services to other people:

OS-9/68000 Kermit Implementation for ELTEC EUROCOM-3

Media: 5.25" DSDD 96tpi standard OS-9 diskette (others on request)
comprising source, executable object, user manual (including hints
for use of /t1) and actual info about Kermit and other implementations.

Order by prepayment of sFr. 30.- to post-office account 60-52873-4 or
with accompanying check or by charging to account (sFr. 50.-) from
Beat Brunner, Hinterherdschwand 30, 6020 Emmenbruecke, Switzerland.

Thanks for your services.

Sincerely yours,

Beat"  (No network address)

------------------------------

Date: Thu, 19 Nov 87 22:39:45 EST
From: "Joseph A. Bruno" <[e-mail]>
Subject: KERMIT File Protocol on COMPUSERVE
Keywords: CompuServe Kermit

When I logged onto COMPUSERVE today, the "what's new" messages informed me
that the KERMIT file transfer protocol is now supported.  I tried to
download a small file and it worked OK form me.  I am using KERMIT-11 on a
PDP-11 with the TSX+ operating system.  I think you should let other users
know about this through the news letter and ask for feedback when others try
it with different versions of KERMIT especially if they have problems.

------------------------------

Date: Sat 14 Nov 87 10:02:24-PST
From: Bob Larson <[e-mail]>
Subject: Finally Kermit on Compuserve
Keywords: Compuserve Kermit

(Compuserve is probably the largest commercial bbs.)

Compuserve is now beta testing their implemintation of the kermit protocol
in the os9 sig.  (Presumably it is in their other sigs that do beta tests as
well.)

My understanding is it is a rather limited version that can only do single
file sends and receives.  Nobody has yet said if it supports full duplex
windows, long packets, or other optional features of kermit and I havn't yet
tested it.  (Compuserve charges extra for bad service, so it may be in no
rush...)

------------------------------

Date: Sun, 15 Nov 87 07:27:28 EST
From: [e-mail] (Eric Van Tassell)
Subject: FTPing Files From Columbia
Keywords: FTP

Hi,
    Are you trying to discourage ftp's? I have been trying for a month
to get VMS kermit to MIT and continually been amazed at the abyssimally low
transfer rates. What's up?

                [e-mail]

[Ed. - Apparently many people have been having problems FTPing files from
Columbia's computers.  Someone is checking on the problem.  Sorry for an
inconvenience.]

------------------------------

Date: Sun 8 Nov 87 02:22:45-PST
From: Jim Lewinson <[e-mail]>
Subject: Kermit Network File Organization
Keywords: Kermit Files

I am a little confused about the organization of the Kermit directories
on CU20B these days.

As far as I can see, there are two sets of directories, <KERMIT-n> n=2,3,4,5
which I assume are used for creating tapes, and
<KERMIT-EXTRA>, <KERMIT-BINARIES>, <KERMIT-TOOLS> (?) which I don't know what
they do any more.

Which of these sets of directories are still being maintained?  Which ones
are accessed when someone asks for a file by saying KER:file.ext to FTP?

If both are being maintained, would it be possible to get a AAFILx.DIR file
for each of them.  There currently seems to be an AAFILB.DIR file in
both <KERMIT-2> and <KERMIT-BINARIES>, but they are of drastically different
sizes.   (However, both seem to be recent.)

Sorry to be a bother about this, but I am trying to make sure that our local
set of directories are up to date so that people at Stanford can pull out
of them instead of putting any more load on CU20B.

                            Jim

[Ed. - Apparently, this has been confusing for other users as well. All the
Kermit files can be found by using the logical name KER:, which will direct
the user to either KERMIT, KERMIT-2 ..... etc.  We'll try to make an effort
to keep AAFILx.DIR files in all these directories.]

------------------------------

Date: Tue, 10 Nov 87 14:44 CST
From: <[e-mail]>
Subject: RE: VMS 4.6 Bug Report with C-Kermit 4E(067)
Keywords: C-Kermit, VMS Kermit

> Date: 19 Oct 87 10:49:00 EDT
> From: "ETD1::LABOVITZ" <[e-mail]>
> Subject: VMS 4.6 Bug Report with C-Kermit 4E(067)
>
> I have just compiled the source modules for C-Kermit 4E(067) under VAX/VMS
> 4.6 on our VAX 11/785, using the supplied XMVKER.COM file.  During the
> final link of the KERMIT executable, the following warning message is
> produced by the linker:
>
>     %LINK-W-MULDEF, symbol SYSTEM multiply defined
>         in module C$UNIX file SYS$COMMON:[SYSLIB]VAXCRTL.OLB;1
>
> While I have not had a chance to confirm this with our DEC Software Analyst
> (he's on vacation until next week), this seems to be directly attributable
> to the new VMS 4.6 C Run Time Library.
>
> [Ed. - Thanks for the report.  It's been forwarded to the new C-Kermit/VMS
> developer and added to the XKVKER.BWR file.  Since compilation and linking
> were tested with VAX-11 C 2.3 on VMS 4.6, and this problem didn't arise,
> the culprit is indeed most likely the runtime system.]

Was C-Kermit/VMS really tested under VMS V4.6?  Before VMS V4.6, there was
no `system' function in the VAX C runtime library.  Starting with VMS V4.6,
Digital provides a `system' function.  The error message basically
indicates that the linker was provided with two routines named `system'.
It sounds like the developer of C-Kermit/VMS implemented `system' in the
code, and that it now conflicts with the new V4.6 standard `system'.

It should be straightforward for VMS V4.6 users to remove the definition
of `system' from the C-Kermit/VMS code and recompile/relink.  Perhaps the
developer can find some nifty way to define `system' conditionally
depending upon which VMS version is being used.

Ed

------------------------------

Date: Wed, 11 Nov 1987 14:27:29 EST
From: John Owens <[e-mail]>
Subject: Re: Amiga Kermit
Keywords: C-Kermit, AMiga Kermit

>I have obtained all the files identified in the file CKIAAA.HLP from the
>BITNET Kermit server.  I FTP'd these to a UNIX system and then downloaded them
>
>    they can send me?  I would prefer it be sent from a VM/CMS to a VM/CMS
>    system to be sure it does not undergo brain damage from ASCII/EBCDIC
>    conversion gremlins; remember it's a binary.
>
>[Ed. - The problem is probably ASCII/EBCDIC gremlins as you surmise.  No one
>else has complained so far, but then we have no way of knowing if anyone
>else has tried this yet!  Can anybody help?]

Typically, the ASCII/EBCDIC translation tables used by Kermit and FTP on your
VM/CMS system should match those used by your protocol converters, and, if
your system people are reasonably diligent, they probably do.  The problem
comes when you have an EBCDIC file that was originally ASCII and was converted
to EBCDIC using a different table.  The way I got around this problem for
Kermit BOO files was to use VM/CMS Kermit with no local translation table,
since its table matches that used at Columbia.  Our installation had
a SYSTEM KERMINI that changed the translation table, so I just created
a SYSTEM KERMINI A with one line: ECHO NULL KERMINI
then transferred the file with kermit.  If you must use FTP, you're
out of luck as far as I know, unless you want to give the UNIX dd
translation tables a shot:  use BINARY FTP mode, then say, on the UNIX
system, "dd if=ebcdic-file of=ascii-file conv=ascii".  Good luck!

        -John Owens
        Virginia Tech Communications Network Services
        [e-mail]    [e-mail]
        [phone]               [e-mail]

------------------------------

Date: Tue, 3 Nov 87 23:59:40 est
From: [e-mail] (Seung)
Subject: C-Kermit on Apollo
Keywords: C-Kermit, Apollo Kermit

Has anyone tried running C-Kermit on an Apollo DOMAIN/IX system?  The
sources build OK when I type "make bsd" but Kermit gives various error
messages when I try to run it.  The most common ones are "Warning, problem
getting exclusive access," and "Warning, problem relinquishing exclusive
access."  I am working on an Apollo DN3000 running 4.2 BSD DOMAIN/IX SR9.6.
The version of C-Kermit is 4D(061).

Sebastian Seung

[Ed. - The problems you're seeing have to do with the UUCP lock files.
Since you're probably running a single-user system, you don't have to worry
about these anyway.  The messages are harmless.]

------------------------------

Date: Mon 9 Nov 87 10:35:12-EST
From: Frank da Cruz <[e-mail]>
Subject: C-Kermit on Minix?
Keywords: C-Kermit

Has anyone tried C-Kermit (preferably version 4E(067)) on Andy Tanenbaum's
Minix (Unix v7) OS for the PC?

------------------------------

Date: Fri, 6 Nov 1987 12:38:30 ULG
From: Andre PIRARD <[e-mail]>
Subject: MacKermit with multilingual 7171
Keywords: MacKermit, 7171, EBCDIC

This message describes problems to adapt MacKermit screen and keyboard
drivers, especially to international requirements in terminal mode.  I have
read that a revision of the keyboard handling is planned.  So, it must be the
right time to contact the right person about this.  Could you please forward
this message to him/them?  I am of course willing to discuss the problem and
carry out related tests needing a national keyboard.

We have settled our mind here (Belgium) to use Kermit micro to CMS mainframes
communication and file transfer.  This is done mainly through 7171's.

The new scheme I have worked out with John Chandler and the IBM-Kermit group
now allows to perform correct ASCII-EBCDIC conversion of the ISO multilingual
character set during files transfer.

In terminal mode, there is no way to have the 7171 use 8-bit data. I however
used a trick to support a limited set of the ISO covering our own nationals.
This works by having the micro send special escaped sequences for these codes.
The 7171 parses these sequences and works out the correct character.  On
return however, the 7171 cannot be instructed to send escape sequences, so I
used the control codes that were not used to another purpose. This is why the
terminal mode set is limited.

This requires some logic on the micro side. I have implemented it in our
traditional ftp, now converted to the Kermit protocol.

But here is the problem. Mac people use Mac Kermit (I neither feel able nor
eager to program the Mac, and MacKermit is fine the way it is).  But they're
crying out for their national characters in terminal mode.  The following two
facts prevent me to implement the above scheme:

- Escape characters received by the Mac terminal mode do not display at all.
  Is this the result of its own ANSI driver or an incomplete font?
  Some control over the display of the *complete* set of non-action characters
  is needed. Possibly by simply specifying a specially tailored font?
  Can this be done now?

- MacKermit keyboard driver is wonderful at building the required escaped
  sequences with appropriate setup. But using our national characters
  requires that some of them be composed by a succession of a dead key
  (bearing an accent) followed by the underlying letter. This composition is
  normally done by the appropriate (localized) keyboard interface layer wich
  I understand is bypassed by MacKermit.

  Using the standard keyboard interface (and still allow for codes conversion
  and escaping) would be simpler in terms of keyboard independence, but would
  restrict the keys combinations to those effectively used by the interface.
  I do not have enough insight of the Mac to propose a solution to this
  point, but I feel it should sound reasonable to suggest a compromise such as:
  Is is possible to have the MacKermit keyboard driver normally receive the
  keyboard codes through the full interface and however steal selected
  keystrokes at the hardware level when instructed to do so by the setup
  tables, with conversion possible at both levels?
  Or is there even a simpler solution?

  This would not only solve the problem, but also make the keyboard setup
  a much more simpler task (every new Mac I saw needed an adjustment).

I hope to help finding minor modifications that could enhance MacKermit.
I understand that not being able to carry on tests on unavailable hardware
is a problem. This is why I will be glad to help towards this.

Andre.

[Ed. - See message below.]

------------------------------

Date: Fri, 6 Nov 87 17:41:31 EST
From: [e-mail] (Paul W. Placeway)
Subject: [Andre PIRARD: MacKermit with multilingual 7171]
Keywords: MacKermit

At first glance, this looks like quite a problem.  According to what I have
read about the new Apple keyboard mapping standards, It shouldn't be a problem
to define any key to produce any sequence (of up to 255 chars, I believe)
8-bit sequence, or use any key as a deadkey for a following one (<Option-e o>
for example).  The other advantage is that it allows an abstraction away from
the hardware level, so that the same map will do the "right things" for a Mac
512 keyboard, and also recognize and deal with the control key on the IIgs and
the "USS Serritoga" keyboards.

One of my goals for the display code is to be able to display an 8 bit wide
character set, so that people who don't happen to speak only American English
(the majority, of course) can have extended character sets.  Fortunately,
Apple is very aware of the "language barrier", and has a system designed to
deal with it.

In other words, it isn't a problem, and I will keep this in mind when working
on the Mac stuff.

       -- Paul W. Placeway            Dept. of Computer & Info. Science
(now)  [e-mail]            2036 Neil Avenue Mall
(soon) [e-mail]        Columbus, OH 43210-1277
(in a pinch) ...!cbosgd!osu-cis!tut!paul    [phone]

------------------------------

Date: Mon, 9 Nov 1987 17:12:01 ULG
From: Andre PIRARD <[e-mail]>
Subject: Mac Kermit 0.8(35) on the Mac II
Keywords: MacKermit

I have downloaded MacKermit 0.8(35) on a Mac II (and adjusted the keyboard
table using 0.8(6) on an SE). It performs great for what I have tried
(terminal mode and file transfer with VM CMS).

But I happened to QUIT it and enter MacWrite while my CMS session was still
active. After a while, the system bombed in my back, while completely idle.
Suspecting comm line interrupts, I restarted the system and Kermit. A message
appeared on the refreshed screen indeed. I quit again and sent my session yet
a message. The system bombed again after some mouse clicks. This happened
several times with varying interval between message and the time the crash
occurs.  Everything looks like the line interrupts are kept enabled to nowhere
code.  This happened with System 4.1 (french) and Finder 5.5 on an SE or
Multifinder 6.0B2 ona a II. I could not reproduce it with 0.8(34) (on the SE
of course).

------------------------------

Date: Mon, 9 Nov 87 22:26:33 CST
From: [e-mail] (Brian H. Powell)
Subject: MacKermit 0.9(36) Initial Impressions
Keywords: MacKermit

Regarding:

>Date: Thu, 29 Oct 87 17:07:50 PST
>From: [e-mail] (Dave Platt)
>Subject: Initial Impressions of Mac Kermit 0.9(36)

>2) I wasn't able to figure out how remap a key so that it would send a
>   Break.
     Enter \bs (short break) or \bl (long break).  This is explained if you
click "help" in the "Set key macros..." dialog.

>4) The screen image is not restored properly after a dialog box is
>   erased (e.g. after a download, or after changing the settings).
     I find this to be a pretty common happening, and it needs to be fixed
soon.

     I don't know if you're really soliciting BeWaRes or not for this version
of MacKermit, but here are some, all regarding MacKermit 0.9(36).

     Other problems I have found:
* I'm unable to set command-spacebar to NUL.  It keeps wanting to set it to
  "\177" when I try to set it to "\0".
* The meta-key option (for the option key) is not available.  I want my
  meta-key back, so I'll probably dump this version of kermit and go back to my
  other terminal program (uw) and the old kermit.  The old ckmkey could set
  modifier keys to act as meta-keys.  (I want a real meta-key, not just one
  that prefixes with ESC.)  Actually, if you fiddle around with "Set key
  macros...", it's possible to set some meta-key combinations explicitly.  I
  haven't gotten it to behave rationally, yet, but there are possibilities
  there.  One also runs into the old problem of dead-keys.  (e.g., you have to
  press option-e twice to get it to register.)  There are ways to work around
  dead keys.
* In the "set modifiers" dialog, if I choose to make both control and clover
  act as a control key, only the control key really acts like a control key.
  clover-b, for instance, sends a 'b'.  This forces me to "Set key macros..."
  for each clover-key.  (Which is how I found out that cmd-spacebar can't be
  set to NUL (above).)  I'm not sure if this is a bug in the code or a bug in
  the dialog box for letting me choose both modifiers at the same time.
* (An oldy but a goody) I like it when the (mouse) cursor disappears when I
  start typing.  (Using ObscureCursor in QuickDraw.)  I wish kermit did this.
* When "Menu Clover-keys active" is turned off, I'd like the clover-keys to
  disappear from the menu.  It's too confusing to an unready user to see those
  cmd-equivalents listed in the menu but semantically disabled.
* In certain instances, things I type to the "Set key macros..." dialog get
  sent to the host as well.  This can be duplicated by choosing "Set key
  macros..." and typing option-`.  Click OK twice and type something (say 'f').
  The host echoes `f.

     I look forward to the real MacKermit.

Brian H. Powell
        UUCP:    ...!uunet!ut-sally!brian
        ARPA:    [e-mail]

   _Work_                     _Not Work_
  Department of Computer Sciences        P.O. Box 5899
  Taylor Hall 2.124                Austin, TX 78763-5899
  The University of Texas at Austin        [phone]
  Austin, TX 78712-1188
  [phone]

------------------------------

Date: Tue 1 Dec 87 00:48:18-PST
From: Jim Lewinson <[e-mail]>
Subject: MacKermit 0.9(36) B3 Testing
Keywords: MacKermit

I grabbed a copy of this from CU20B to try it out, and I still can't get the
Keyboard stuff to do what it used to do for me.  The OPTION key used to
ONLY insert an ESCAPE in front of the keystroke, and make no other changes.

Pressed            What I want        What IS
               Sent              Sent
OPTION d        ESC d            ESC d
OPTION SHIFT D        ESC D            ESC D  (Not too important)
OPTION SHIFT .        ESC >            ESC .  (IMPORTANT)

I use the latter keystrokes all the time to get to the end of a file.  I
suspect other people may use OPTION SHIFT 4 to get the EMACS spell checker.
(In fact, I might start using this, now that I think of it.)  I suspect I
may also use OPTION SHIFT 3 for Query-Replace, but not often enough to
notice it.

If I had to give up a feature to get this, I would get rid of the concept
of Modified/Unmodified.  Kermit is generally used to talk to other machines
in 7 bit ASCII.  The ability to send a E with an accent grave on it sounds
really neat, but isn't very useful when you get down to it.

I wouldn't worry too much about trying to get the window postion of the new
settings file right.  After all, you did write a new file, and this is
something that I do very very rarely.  Usually, it is just to create a new
version for a different speed or something similar, so I usually create a
new file anyway.

I tried to use the long packets, but the Unix machine I was trying to use
only has a short packet Kermit on it.  I thought I grabbed a new
long-packet one, but I guess I got the wrong one.

I did use 0.9(36) B2 to transfer B3 down, and it seemed to do a fine job,
except it transfered the files I told it to, not the ones I wanted.  :-)
I guess a little more DWIM is needed in that department.  (Or maybe a little
less DIMWitted behaviour on my part. :-) )

                        Jim

------------------------------

Date: Tue, 10 Nov 87 09:07 GMT
From: [e-mail] 11-NOV-1987 11:11
Via: [e-mail]
Subject: Macs, Versaterm and Kermit Errors
Keywords: MacKermit, Versaterm

We have been using both the "formal" Mac Kermit based on "C" kermit and a
terminal emulator/file transfer packaged called Versaterm at Loughborough with
mixed success.

We selected Versaterm as the suggested terminal emulator and file transfer
program over the distributed Mac Kermit for two reasons: terminal emulation was
far better, and could also "do" Tektronix emulation, and more importantly,
appeared to be more reliable in Kermit transfers than Mac Kermit.

However, we have had a rash of file transfer problems, resulting in truely
garbled data at the Mac end.  (Early bits of the file keep appearing thoughout
the file, not all the file is available even though the transfer says it has
completed, etc.)  Closer investigation showed an unusual bug in Multics
(Amaranth) Kermit.  We FTP-ed the files to a VAX and again tried to transfer
the files to the Mac, with similar results.  It therefore seems as if Versaterm
is not a good as it is made out to be.

Has anyone else used Versaterm and had problems, and better still come up with
som work-arounds?

In anticipation, Bertil Schou.

------------------------------

Date: Wed, 28 Oct 87 17:08:23 EST
From: [e-mail] (N. Topping)
Subject: iRMX86 Kermit -- I've found it!
Keywords: RMX Kermit

About a month ago I made an appeal for information on Kermit for iRMX86.
Apparently there was some discussion, confusion and advice generated by this
request.  I say "apparently" because I did not personally read any messages
since I do not subscribe to this mailing list.  As a nonsubscriber, I asked
that responses be mailed directly to me (dfs@nadc).  However I received only
one direct response from Jack Bryans (Thanks!) and he alluded to these
kermit-digest discussions.

I am posting this message to inform the Kermit community that I have finally
located a version of iRMX86 Kermit that works.  I found the name of Larry Grim
of Mesh Inc. in the "aawait.hlp" file.  I contacted Larry and he graciously
provided the Kermit source code (ASM86) and documentation.  Larry's iRMX86
version of Kermit was developed for an Intel 86/310 sometime in 1985.  He
developed this iRMX86 Kermit by converting the IBM PC DOS version of Kermit.
The conversion effort was sponsored by the Dupont Corporation.

Since Larry does not have network access to the Kermit repository, I promised
him that I would inform the Kermit community of his accomplishment and
volunteer to mail his Kermit source and documentation to the Kermit
repository.  If the keepers of Kermit are interested in obtaining this version
of Kermit, please let me know (by direct response, please!) where to mail it.

All credit and questions regarding this version of KERMIT should be referred
to:

    Larry Grim
    Mesh, Inc.
    2802 Bethel Rd.
    Oxford, PA
    215-932-3709

Sincerely,
(dfs@nadc)
Michael Lipczynski
Veda, Inc.
Warminster PA.
215-672-3200

P.S. We assembled and linked iRMX86 Kermit (with no modifications!!) on a OEM
system that contains an Intel 8026.  We have not had any problems so far.

[Ed. - We seem to have no end of Kermits for Intel iRMX and MDS systems, and
so far have little idea which to keep and which to throw out.  For (i)RMX,
we have the ones with prefixes RMX, IRM, and I86, plus Jack Bryan's new
version based on MS-Kermit 2.29C (MSTRM*), and for MDS systems we have the
MDS programs and the MD2 ones.  Comparative reviews would be appreciated.
Meanwhile, you might want to coordinate with Jack Bryans about whether the
iRMX Kermit you've described should be added to maze at Columbia, or maybe
Jack's version will make it unnecessary.]

------------------------------

End of Info-Kermit Digest
*************************
-------
18-Dec-87 16:00:41-EST,26409;000000000000
Mail-From: SY.CHRISTINE created at 18-Dec-87 15:59:24
Date: Fri 18 Dec 87 15:59:23-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V6 #27
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 18 Dec 1987       Volume 6 : Number 27

Today's Topics:
Departments:

  ANNOUNCEMENTS -
        IBM PC Kermit with Tektronix 4010 Emulation Available for Testing
        Info-Kermit BITNET Subscribers Moved to LISTSERV
        Changes to Okstate Kermit Distribution Service
        Kermit Available for the HP-125 CP/M Business Computer

  MS-DOS KERMIT -
        Kermit-MS and >25-Line EGA Modes
        More Comm Ports for MS-Kermit?

  UNIX KERMIT -
        Suspending C-Kermit under 4.2 BSD
        C-Kermit Problems

  MISCELLANY -
        Trouble Building CMS Kermit
        Kermit-PE (Concurrent 3200, OS/32) Bug Fix
        Need Kermit on a VAX 730 under VMS 4.0
        Red Ryder's Kermit Send Fails
        Re: BOO File Problems
        Kermit 3.79 on Apple 2c
        Kermit Found for Convex
        Need Kermit for IBM System 9000
        Kermit Wanted for Old RSX-11m v3.2

----------------------------------------------------------------------

Date: Thu, 17 Dec 87 00:11 MST
From: <[e-mail]> (Joe Doupnik)
Subject: IBM PC Kermit with Tektronix 4010 Emulation Available for Testing
Keywords: Tektronix Emulation, MS-DOS Kermit, EGA

File MSTIBM.BOO, dated 16 Dec 1987, is on the way.  It includes Tektronix 4010
graphics terminal emulation (plus Tek 4014 line-drawing commands) for the IBM
PC with EGA, CGA, or Hercules graphics adapter, or no graphics board at all
(Kermit automatically senses which board is in place).  Tek emulation can be
invoked in two ways:

(1) SET TERMINAL TEK (or by toggling terminal type with Alt-Minus), and

(2) from within DEC or Heath mode when the host transmits ESC-Formfeed.

Return to DEC/Heath mode upon receipt of Ctrl-X, or SET TERM VT102 (or
anything other than Tek).  On color systems, the prevailing fore- and
background colors are used.  On systems with sufficient graphics memory, both
the text and graphics screens are saved for restoral after escaping back and
reconnecting.

There's also a corresponding version of "generic" MS-DOS Kermit, MSTGEN.BOO,
naturally without the Tek emulation.

        Joe D.

[Ed. - Many, many thanks, Joe!  This is a great piece of work.  It is based on
Brian Holley's (Cambridge U, UK) adaptation of Tek code that was originally
written for the TI PC version of Kermit by Joe Smith (Colorado School of
Mines).  Joe has seamlessly integrated it into the mainline Kermit, and added
many features in the process.  We've tested the result on PCs, XTs, and ATs,
and it works, and it goes fast!  So far, the manual (MST29C.DOC) does not
describe the Tek emulation in any detail, but a few preliminary notes can be
found in MSTIBM.HLP.  The new Kermit version itself is in MSTIBM.BOO.  These
files are in KER: on CU20B.COLUMBIA.EDU, available via anonymous FTP, or
available as MSTIBM * from KERMSRV at CUVMA on BITNET.  If no serious problems
are encountered, this could be "it" -- the real 2.30 release.]

------------------------------

Date: Thu 17 Dec 87 17:15:03-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit BITNET Subscribers Moved to LISTSERV
Keywords: BITNET, LISTSERV

As announced a while back, the WISCVM mail gateway between BITNET and the
other networks (Internet, CSnet, CCnet, etc) ceased operation on December
15th.  There were still 105 subscribers of Info-Kermit using this gateway.
Some of these subscribers were lists in themselves, so it's hard to know how
many people at how many sites are involved.

Before this edition of the Info-Kermit Digest was sent, all of these
subscribers were moved to a new LISTSERV-based distribution, I-KERMIT@CUVMA.
If this happened to you, you should have received by now a notification from
your friendly neighborhood LISTSERVer.

From now on, anyone who wants to subscribe to the Info-Kermit Digest from a
BITNET site should send mail to LISTSERV@CUVMA, with the body of the message
as follows:

SUBSCRIBE I-KERMIT your personal name

Similarly, if you are getting Info-Kermit mail from a LISTSERVer, and you
want to cancel your subscription, send mail to I-KERMIT@CUVMA, with the
body of the message saying

UNSUBSCRIBE I-KERMIT

For more information about LISTSERV, send mail to LISTSERV@CUVMA, with the
message body saying "HELP" (for a short getting-started message) or "INFO GEN"
for a longer explanation of what LISTSERV is, along with the most common
commands.

Most of the subscribers that were moved had to be entered as "Name Unknown"
because the personal names were not kept in our present distribution list.  If
you receive mail that refers to you in this manner, you can tell LISTSERV your
actual name by sending it a SUBSCRIBE request that includes your name.  It
should correct the current entry, rather than make a duplicate one.

------------------------------

Date: Mon, 14 Dec 87 12:57:22 -0600
From: Mark Vasoll <[e-mail]>
Subject: Changes to Okstate Kermit Distribution Service
Keywords: Okstate

We have made some changes in our communications system that will now allow
us to offer 2400 bps access as well as the old 300/1200 access via both
Kermit and UUCP.  The login information has not changed, except that upon
receiving a carrier, you should send the following

<carriage return>
<delay about 2 seconds>
<carriage return>

In UUCPeese, that's:

"" \r\d\d\r ogin: uucpker word: thefrog

or in a C-Kermit script:

~0 ~r~d~r ogin: kermsrv work: piggy

Since new hardware is involved, there may be problems.  It would be most
helpful if you could send [e-mail] a message describing
any problems with approximate time (don't forget the timezone) and date.
Also, your UUCP system name would be helpful if you were trying to use UUCP.

Thanks,

Mark Vasoll
Computing and Information Sciences   Internet:  [e-mail]
Oklahoma State University            UUCP:  {cbosgd, ihnp4,
Stillwater, Oklahoma                         rutgers}!okstate!vasoll

[Ed. - Thanks Mark.  This information has been added to the file
KER:AANOKS.HLP.]

------------------------------

Date: Tue,  8 Dec 87 13:45 PST
From: <MAILER@UWALOCKE>
Subject: Kermit Available for the HP-125 CP/M Business Computer
Keywords: CP/M Kermit, HP-125

I have a version of CP/M Kermit for the Hewlett-Packard HP-125 (a short-lived
CP/M machine produced in the early 1980's and intended for the business
office.)  It is based on version 4.05 of 1985.  It will send/receive files
over both Data Comm Port 1 and Data Comm Port 2 (although the latter can only
be done in 7-bit bytes -- HP's restriction) and will emulate a VT52 as well as
responding to HP terminal escape sequences with VT52-Emulation OFF.  Would you
be interested in this version, even though it is not current?

By the way, I am using an HP-125 because a company called Maryland Computer
Services (now part of a company called Enabling Technologies) modified it for
voice-access with special software for the blind.  I am a blind systems
programmer on a DECsystem-10 here.

Please send any reply to MAILER@UWALOCKE.  Please place on the subject-line
of your message the phrase dec10%"bpa".

        Michael Freeman-MORF
        Bonneville Power administration
        P.O. Box 491
        Vancouver, Wa 98666

[Ed. - Thanks!  The system-dependent hex file, plus the above message,
have been installed in KER:CP4HP1.* on CU20B.  Michael will be sending the
sources to Bertil Schou in England, who's been working on CP/M-80 Kermit,
so that HP-125 support will be in the next release.]

------------------------------

Date: Wed 2 Dec 87 21:43:18-EST
From: Jim Celoni S.J. <[e-mail]>
Subject: Kermit-MS and >25-Line EGA Modes
Keywords: MS-DOS Kermit, EGA

I'm using Kermit-MS now on an AT compatible w/ EGA & ECD in 34x80 mode.
I've also used it at 42x80 and 57x80, all as heath-19 (except changing
the termcap li entry), using ega35, ega43, and ega58 mode-setting programs.

I'm happy Kermit-MS 2.29c handles more than 24 lines intelligently!

------------------------------

Date: Mon, 14 Dec 87 17:34 EST
From: <[e-mail]>
Subject: More Comm Ports for MS-Kermit?
Keywords: IBM PC Comm Ports, COM3 and COM4, MS-DOS Kermit

I was attempting to alter the MS-DOS version of Kermit so that it would access
COM3: or COM4:, but to no success.  I was wondering if there were any standards
to the interupt vector addresses and the end-of-int value.  I have the
addresses of the data/status/port for com 3 & 4, but the values of MDINTC3/4,
MDINTO3/4, MDINTV3/4, and EIOCOM3/4 are a mystery.  Can anyone help with an
explanation of how these values are obtained?  Is there someone else that I
should be asking?

        Thank you
        Bryan Blair   a.k.a    JBLAIR@LOYVAX

[Ed. - There are indeed no standards.  The current prerelease of MS-DOS
Kermit, 2.29C (soon to be 2.30), includes hooks to allow users to access
their COM3 or COM4 ports.  These are documented in the MS Kermit manual,
MST29C.DOC, which must be used in conjunction with your expansion board's
technical manual.]

------------------------------

Date: Wed,  9 Dec 87 14:28:25 -0500 (EST)
From: [e-mail] (Walter Lloyd Wimer, III)
Subject: Suspending C-Kermit under 4.2 BSD
Keywords: C-Kermit

Has anyone fixed C-Kermit so that it can be suspended using ^Z (SIGTSTP)
without leaving the terminal in cbreak and no-echo mode?

If not, I believe I have.  Let me know and I'll send the changes.

Walt Wimer
Data Communications
Carnegie Mellon University

[Ed. - We've received a number of fixes for this.  They're listed in
KER:XKUKER.BWR on CU20B, and will be added to the next release.]

------------------------------

Date: Sun, 8 Nov 87 21:59:05 EST
From: Phil Ritzenthaler <[e-mail]>
Subject: C-Kermit Problems
Keywords: C-Kermit

I have had a small problem occur with the new C Kermit (4E(067)).  I was
uploading a 92K file from my PC (using 2.29b) to a VAX 11/785 running Unix
4.3 BSD using a packet length of 500 bytes.  This was a VERY local call.

I had 3 errors that occured during transmission and whin doing a 'diff' against
the original file there were problems . . . some "Y#5"'s, many "#"'s, and then
many more "@"'s.  It looked to be the length of 1 500 byte packet.

Could you clue me in on what occured?  Are the larger packet lengths
unresonable and not possible in the "real world"?

Again, thanks . . .

Phil Ritzenthaler            |USnail: University Computer Services
Computer Graphics Research Specialist   |        241 Math-Science Bldg.
UUCP :.!cbosgd!osu-cis!bgsuvax!ritzenth |        Bowling Green State University
CSNET: [e-mail]                |        Bowling Green, OH   43403-0125
ARPA : [e-mail]   | Phone: [phone]

[Ed. - If anybody can reproduce this problem, please send in the exact scenario
so we can fix it!]

------------------------------

Date: Thu, 29 Oct 87 11:53:41+0700
From: indovax![e-mail] (Benny Ranti )
Subject: Trouble Building CMS Kermit
Keywords: CMS Kermit

I am research assistant at Comp. Sc. Center Univ. of Indonesia.  I have
tried to compile Kermit CMS source program (sixth edition, rev. 2 based on
IBM 360/370 Assembly Lang) on IBM 4361 (under VM/CMS).  We found an error
during the compilation, the error was "undefined code" for STAX instruction
within INTINI routine. We have looked at IBM's book but we didn't find STAX
as a mnemonic.

Another thing, do you have Kermit source for VSE/SP ?

I am looking forward to hearing a good news from you.

Please contact me:
my uucp address is:

uunet!indogtw!indovax!ranti

[Ed. - The STAX macro is in the TSOMAC macro library.  Like it says in the
intallation instructions for CMS Kermit, you have to GLOBAL TSOMAC before
assembling.

There is presently no Kermit for DOS/VSE.  But with the new "portable 370"
Kermit nearly ready for release, it should be a simple (?) matter for a DOS/VSE
programmer to add support for that system, following the methods used for
VM/CMS and MVS/TSO.  Watch Info-Kermit for announcements.]

------------------------------

Date: 8-DEC-1987 14:54:26 GMT
From: Diane Lowe, CAP Industries.
Via: [e-mail]
Subject: Kermit-PE (Concurrent 3200, OS/32) Bug Fix
Keywords: Perkin-Elmer Kermit

I have recently discovered a bug in our version 2.0 of Kermit-PE (Concurrent
3200, OS/32).

At the OS/32 Mainframe end, when trying to SET DEBUG ON, the following Fortran
error message occurred;

    ERR 301 (OOC8AO) :ON
    VALUE 20 FOR SPECIFIER > MAX VALUE ALLOWED:14
    TASK PAUSED

This can be resolved by adding the following line to KERMIT.LNK

    OPTION LU=21

Regards,
    Diane Lowe.

[Ed. - Thanks Diane.  Although are currently sending out 2.1 (9/11/86) of
PE-Kermit, we have created a KER:PERKIN.BWR to add your fix.]

------------------------------

Date: 25 Nov 87 16:57:23 GMT
From: [e-mail] (Dictionary of Old English)
Subject: Need Kermit on a VAX 730 under VMS 4.0
Keywords: VAX/VMX Kermit

I need to get any version of Kermit up on our DEC VAX 11/730.  It is running
VAX/VMS 4.0, right now, and the only compiler we have is a version of a
C compiler from Whitesmiths.

We can transfer ASCII to it right now, through various means, but binaries so
far have been a problem.

Also, the only removable media we have are RL02 cartridges, and the tiny
DECTAPE II's.  RL02 aren't very popular, and I am not sure if we can directly
read or write DECTAPE II's.  If we can get a binary of a kermit on an RL02,
it could be a solution, but so far, we haven't been able to find anyone.

Another alternative is to do something similar to "uuencode" a binary of
kermit, transfer it via ASCII, then "uudecode" it on the VAX.  The only
problem is, we don't have such utilities.  We might need a source for that
in Whitesmith's C, or get the binary... which brings us back to the same
problem.

SO, if anyone can suggest anything that we can do to get Kermit running
on our VAX, it would be much appreciated.

Also, please respond by Email if possible.

--Tak Ariga

Internet:  [e-mail]
BITNET:    oldeng@UTORGPU
Phone:     [phone] {office}

++ Dictionary of Old English == University of Toronto == Toronto, Canada ++

[Ed. - VMS Kermit is available in hex file format as VMSMIT HEX, available
from KERMSRV at CUVMA, along with a Macro-32 decoder program, VMSDEH MAR,
which you can assemble, link, and run, to produce a runnable Kermit.  See
the file VMSAAA HLP.  Or, if anybody wants to volunteer to send Kermit on
an RL02 or tape cassette...]

------------------------------

Date: Wed, 09 Dec 87 13:27:53 -0800
From: Alastair Milne <[e-mail]>
Subject: Red Ryder's Kermit Send Fails
Keywords: Red Ryder

I have been trying to send a textfile created with IdeaLiner from a 512K Mac
to C-Kermit under a UNIX copy called DYNIX, running on a Sequent. The file
goes across, and no error is reported, but when I look at it on the UNIX
system, there are no linebreaks at all.  In fact, "wc" counts 0 lines for it

I can't even use "vi" on it: the single undelimited line is far too long.
But the linebreaks are definitely there on the Mac.  Apart from the fact
that MockWrite shows that text properly broken, a byte-level examination
with ViewEdit in MacTools shows an ASCII 13 at the end of each line.

I doubt whether it can be anything do to with the UNIX kermit.  I've
already used it often for exchanging files with DOS (Kermit 2.29C) and the
p-System, and the files go across perfectly intact.

I am using the Kermit built into Red ryder 9.2; I don't know which version
of C Kermit is on UNIX.  I have tried all the switch settings I can find
that might add CR's or LF's at linebreaks, but they make no difference.
I've even tried fiddling with newline mode in the VT100 emulation, even
though Kermit should have all terminal emulation turned off.

This is a considerable and unexpected hindrance.  Could somebody please
tell me how to get the line breaks preserved across the transfer?  My work
on the Mac is for nothing if I can't get it to where our group works on the
Sequent.

I have tried getting a file from UNIX, using Red Ryder Kermit receive.  It
works fine: all the linebreaks are where they're supposed to be.  But
sending is hopeless.

Please help.
Thanks again,
Alastair Milne

[Ed. - I can't comment on Red Ryder, but if it were Mac Kermit, I'd guess
that you were sending the text in binary mode, so that the CRs which are
used on the Mac to delimit text lines were not being translated into CRLFs
during transmission, which means that Unix Kermit won't see any line breaks,
and so will just store the bare CRs, which are not line delimiters in Unix.]

------------------------------

Date: 11 Nov 87
From: [e-mail] (Gisbert W.Selke)
Subject: Re: BOO File Problems
Keywords: MS-DOS Kermit, .BOO Files
Xref: BOO Files, See .BOO Files

I was doubting my sanity some time ago when I had serious problems with
MS-Kermit boo files, too. It turned out to be a local EBCDIC -> ASCII
conversion problem, and after some experimenting I found a way to get my boo
files transferred in a reliable way - the un-booed executables do work.

The problem is mainly that the boo format uses all the characters from
ASCII-zero (ASCII 48) to ASCII-tilde (ASCII 126). Included in this set are
some characters for which no standard EBCDIC <-> ASCII conversion rule
exists; assuming that characters and digits are OK (they will be, won't
they?!?), the extra characters needed are:

colon                 ":"
semicolon             ";"
less than             "<"
equals                "="
greater than          ">"
question mark         "?"
at-sign               "@"
left  square bracket  "["  (at our place, EBCDIC hex 'AD')
backslash             "\"
right square bracket  "]"  (at our place, EBCDIC hex 'BD')
caret, up-arrow       "^"  (in EBCDIC, usually negation sign)
underscore            "_"
accent grave          "`"
left  curly brace     "{"
vertical bar          ":"  (maybe "|" in some EBCDIC places)
right curly brace     "}"
tilde, quiggle        "~"

You should check if all these characters are transferred properly with
whatever procedure you use to get files to your Amiga. The ones that caused
trouble here were the up-arrow/negation-sign, the vertical bar and the
square brackets. So I used XEDIT to translate these particular characters
into inconspicuous sequences which got transferred properly; I wrote the
following XEDIT macro file to accomplish this:

SET LRECL 255
SET TRUNC 255
SET ARB OFF
SET HEX ON
TOP
* For transferring boo files to PC via IRMA board and IRMA software:
* translate characters which will not transfer properly otherwise:
:0 C /^/`not`/ * *
:0 C /|/`vba`/ * *
:0 C /X'AD'/`lbr`/ * *
:0 C /X'BD'/`rbr`/ * *

Remember to invoke XEDIT with a greater width, i.e.
           XEDIT  <file name>  <file type>  (width 255 noprof

This also makes sure you're not hampered by any profile which sets
trunc or lrecl to something inconvenient. Executing the above macro
file results in a file with greater line lengths: your file transfer
utility should be able to cope with that.

Also note that at some places, apparently ASCII left and right square
brackets are translated to EBCDIC "" (cent) and "|" (continuous
vertical bar), respectively; you might have to check that, although
I never encountered that with CUVMA files.

Well, I hope this at least gives you some clues, even if it isn't a
ready solution to your problem.

Happy kermitting,

\Gisbert

P.S.: I am enclosing a brief description of the boo format which
I prepared for a booing programme - for what it's worth.

C     BOO FORMAT FILES
C
C     IT IS NOT MEANT TO BE A TRANSFER PROTOCOL REPLACEMENT; IT
C     JUST MAKES TRANSFER POSSIBLE ACROSS LINES (E.G., DATA NETWORKS)
C     WHEN NO KERMITS ARE AVAILABLE OR ONE OF THEM CAN'T COPE WITH
C     BINARY STUFF.
C
C     BEWARE OF GREMLINS, THOUGH; ESPECIALLY EBCDIC <-> ASCII
C     TRANSLATION MAY BE A PROBLEM FOR SOME OF THE CHARACTERS ...
C
C     BASICALLY, 3 BYTES = 24 BITS ARE ENCODED INTO 4 CHARACTERS
C     BY DIVIDING THEM INTO 6-BIT-PIECES AND THEN ADDING ASCII-ZERO
C     TO MAKE THESE PIECES PRINTABLE. THE RESULT LIES IN THE RANGE
C     ASCII-ZERO TO ASCII-SMALL-O. - IN ADDITION, NULL COMPRESSION
C     TAKES PLACE; CONSECUTIVE NULL BYTES (WHICH OCCUR FREQUENTLY
C     IN EXECUTABLE FILES, E.G.) ARE ENCODED WITH A TILDE LEAD-IN
C     FOLLOWED BY THE NUMBER OF NULLS (UP TO 78), AGAIN RENDERED
C     PRINTABLE BY ADDING ASCII-ZERO. THE RESULTING CHARACTER IS IN
C     THE RANGE ASCII-ZERO (WELL, ASCII-TWO OR -THREE, REALLY) TO
C     TILDE (ASCII CODE 126). - CHUNKS OF FOUR CHARACTERS BELONGING
C     TOGETHER (RSP. TILDE AND NULL REPEAT COUNT) SHOULD NOT BE
C     DIVIDED ACROSS LINES. A LINE HAS A MAXIMUM LENGTH OF 76
C     CHARACTERS. - IN ADDITION, THE FIRST LINE OF THE FILE CONTAINS
C     THE NAME OF THE ORIGINAL FILE (IF KNOWN - OTHERWISE A DUMMY NAME)
C     AND NOTHING ELSE.
C

------------------------------

Date: Thu, 5 Nov 87 22:31:58 EST
From: [e-mail]
Subject: Kermit 3.79 on Apple 2c
Keywords: Apple II Kermit

I have been using Apple Kermit 3.79 on an Apple 2c and find it works great!
Terminal emulation and transfers at 2400 baud with no missing characters,
VT100 emulation including keypad, the works!  But there's one minor
problem...

While characters received from a remote system over the modem come through
OK at 300, 1200, and 2400 baud, those generated by the modem itself are
often garbled.

For example, when you type "AT" the modem is supposed to reply "OK".
Sometimes this works and sometimes it comes out as "O+".  Similarly, when
you reach the other machine the modem sends you "CONNECT", but this NEVER
comes through on the screen--it's always something like "CO%&T"
(sorry, don't remember the exact sequence).
It looks like the computer cannot handle characters that arrive too close
together.  I tried this on two different 2c's, and one has a much bigger
problem than the other.

Has anyone seen this problem?  Is it a Kermit or a 2c problem?  At first I
thought it was a matter of not responding to interrupts in time, but since
it even happens at 300 baud this doesn't seem likely.

I though it might be that the 2c was looking for 2 stop bits, but the source
code seems to be initializing the port properly (not that I'm a 2c expert!).

The 2c manual says something like "Peculiarities in the 2c's baud rate
generator may require changes in the data format" in the section on setting
data bits, stop bits, and parity.  Could that be it?  Did different
revisions of the 2c have different peculiarities?  Is there a workaround?

I foresee this will be a problem if a script facility is ever added to Apple
Kermit, as it will be hard to do input matching to look for prompts if they
cannot be received reliably.

Reviewing the manual, I realized that this problem of not getting the modem
prompts correctly will also mess up the MODEM command in Apple Kermit, since
it waits to receive the string "CONNECT" from the modem.

Mike Ciaraldi
University of Rochester Computer Science Department
[e-mail]

[Ed. - This report has been added to KER:APPKER.BWR.]

------------------------------

Date: Mon, 7 Dec 87 15:22 EST
From: <[e-mail]> (Shawn Allin - Alcan KRDC Computer Services)
Subject: Kermit Found for Convex
Keywords: Convex Kermit

I sent a question to you concerning the availability of Kermit for a Convex
supercomputer some months ago, and at that time you were unaware of a version
for it.  I just thought I'd get back to you with the news that there is now a
version running on it.

The only identification I have found on it so far is "UCL Remote-only Kermit,
V15B, March 1986".

I can look into it more, if you want further information.

     Regards,

     Shawn Allin
     Alcan International Ltd.,
     P.O. Box 8400,
     Kingston, Ont.,
     Canada  K7L 4Z4
     [phone]

     Bitnet: ACCESS@ALCANKTN
     (ALLIN@QUCDNSUR is alternate address if routing tables aren't updated yet)

[Ed. - We don't seem to have it in our collection.  If someone can send it
in, along with some more information about the machine and operating system
(apparently this is not the Convex that runs Unix), we'd be glad to add it
to the Kermit distribution.]

------------------------------

Date: Wed, 25 Nov 87 15:32 EST
From: [e-mail]
Subject: Need Kermit for IBM System 9000
Keywords: IBM System 9000 Kermit

Please help.

I am looking for a version of Kermit that will run on an IBM System 9000
Pascal V1.2 CSOS.

I do not know what all that means but that was on the operating manual (This
is not my system ).

Thanks
John Gartley
[e-mail]         (CSnet)  or
[e-mail]  (ARPAnet)...after 1-DEC-87

------------------------------

Date: Wed, 18 Nov 87 22:14 EST
From: Bryan Lally <[e-mail]>
Subject: Kermit Wanted for Old RSX-11m v3.2
Keywords: RSX Kermit, PDP-11

Help!

For reasons we won't go into, I need a KERMIT for a PDP-11 system running
RSX-11m v3.2.  This means RMS v1, not v2.  Anyone got one?  The new ones
won't work, 'cause they need RMS v2.  Replies to:

        bryan lally
        [e-mail]
        [e-mail]

------------------------------

End of Info-Kermit Digest
*************************


-------
28-Dec-87 20:25:39-EST,23568;000000000000
Mail-From: SY.FDC created at 28-Dec-87 20:25:05
Date: Mon 28 Dec 87 20:25:05-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V6 #28
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Mon, 28 Dec 1987       Volume 6 : Number 28

Today's Topics:

          Announcing IBM Mainframe VM/CMS Kermit Version 4.0
                          MacKermit Status?
     Version 0.9(36)b4 of Macintosh Kermit Available for Testing
                             Kermit News
                    Request for Kermit Information
                  VAX/VMS Cluster and Kermit Problem
           Non-Bug Report, MS-Kermit, CP/M Kermit (Kaypro)
                       Kermit 3.79 on Apple 2c
                   IBM 370 Mainframe UTS24-Kermit?
                       Kermit & Everex Modems?

----------------------------------------------------------------------

Date: Mon, 1987 Dec 21 12:08 EST
From: (John F. Chandler) [e-mail]
Subject: Announcing IBM Mainframe VM/CMS Kermit Version 4.0
Organization: Harvard/Smithsonian Center for Astrophysics
Keywords: IBM 370 Kermit, VM/CMS Kermit, CMS Kermit
Xref: IBM Mainframe, Also see IBM 370
Xref: VM/CMS Kermit, Also see VM/CMS Kermit, IBM 370

This is to announce CMS Kermit Release 4.0 for IBM 370 series mainframes
running the VM/CMS operating system.  The program is now a member of the
generic family Kermit-370 and appears in the Kermit distribution under a new
prefix: all CMS-specific files begin with IKC, while generic Kermit-370 files
begin with IK0 (I K Zero).  Kermit-CMS no longer consists of a single source
file.  Instead, the source is split into sub-files, some generic and some
CMS-specific.  The separate pieces are to be recombined into a single
composite source (or made into a macro library) for installation.  See the
file IKCKER.INS for instructions.  Generally, the files formerly known as
CMSKERM.* have been replaced by new IKCKER.* files.  The companion TSO Kermit
Release 4.0 is still in the testing and debugging stage, but should be
available soon.  Anyone interested in helping to get Kermit-TSO ready for
release should contact John Chandler <[e-mail]>.

Below is a list of the more important additions in Version 4.0:

    --- generic features ---

1.  Code reorganization into generic 370 and system-specific sections.

2.  Optional separate translation tables for counteracting the system
    conversion of terminal I/O.

3.  New GIVE command for saving a modified translation table.

4.  A new, RAW debug mode for recording the packet traffic as actually
    sent and received on "GRAPHICS" and "SERIES1" devices.

5.  Preservation of the case of commands as typed, with uppercase
    conversion of only those words that must be uppercase.

6.  New SET MARGIN command for limiting the width of a file to be sent.

7.  Settable tab stops for Kermit's conversion of tabs to spaces
    (alternative to the default 1, 9, 17, etc.).

8.  Replace SET SERIES1 subcommand with new SET CONTROLLER.  Support for
    multiple terminal controller types.

9.  New DIRECTORY and HOST subcommands following Kermit standard.

10. Combination of file-attribute SET subcommands (FILE-TYPE, LRECL, and
    RECFM) into a new group SET FILE.

11. Separate retry limits for initial and subsequent packet exchanges.

12. Pad binary records on disk with nulls, rather than blanks.

13. Automatically tune packet length when sending long packets according
    to heuristic optimum based on sparse Poisson statistics, provided
    that transmission errors do occur.

14. Expand STATUS report to include the number of files in the last
    transfer, throughput statistics, heuristic optimum packet length
    (when long packets are enabled), and the reason for any file
    rejection based on A-packets.

15. New command TDUMP NAMES to display the list of files sent in the
    last transfer.

16. Add file creation date to A-packet repertoire.

17. REMOTE COPY and REMOTE RENAME commands to a server at the other end.

18. Allow long packets through a 7171 with VTAM.

19. New type D-BINARY for binary files with undelimited variable-length
    records.

20. SET 8-BIT-QUOTE.  Allow 8-bit data where possible via SET PARITY.

21. SET SYSCMD, so that Kermit can be told to try "illegal" subcommands
    as host system commands instead of just rejecting them.

22. SET PROMPT subcommand.

23. Do not forget parameters specified by the other Kermit in I-packets.

24. Keep track of truncated records during a RECEIVE operation and
    report the count in STATUS; also call truncation an error after
    everything is received.

25. SET HANDSHAKE subcommand to alter or suppress handshake character
    Kermit-370 sends out after each packet.

    --- CMS-only features ---

26. System commands issued through Kermit via the subcommands CMS or
    HOST are automatically passed on to CP if (a) CMS rejects them and
    (b) IMPCP is set ON.

27. Kermit subcommands may be executed directly from CMS EXEC's.

28. Reject files known (via A-packets) to be too big for available
    storage.

29. Bypass user translation tables and set TERMINAL SCROLL CONT for
    protocol mode on TTY lines.

30. KERMBOOT avoids the loading problem (VIRTUAL STORAGE CAPACITY
    EXCEEDED) due to large GLOBAL TXTLIB's and preserves the untokenized
    command line so that Kermit may be given mixed-case or long words as
    part of the initial commands.

[Ed. - Thanks, John!  And thanks to all who helped put this new program
together.  This is a kind of milestone in Kermit development.  It should allow
the many IBM mainframe operating systems to run a common, advanced version of
Kermit.  All that's necessary is for some volunteers who are expert in
MVS/TSO, DOS/VSE, MUSIC, MTS, GUTS, and the various other 370 OS's to step
forward and fill in the system-dependent modules for their systems (as John
points out, the TSO version is nearly complete, but still needs some testing
and debugging).  If you want to volunteer to help, please contact John
directly, cc to Info-Kermit@CU20B.  The files are in KER:IK*.* on CU20B,
available via anonymous FTP, or on BITNET as IK* *, available from KERMSRV on
host CUVMA, and replace the files whose names started with CMS.

By the way, some of you may have seen an article in Digital News, November 30,
called "Advanced Kermit Version Available Soon for VAXs" (p.10).  It reported
on part of our talk at Tokyo DECUS, in which we described John's portable IBM
mainframe Kermit.  The editors at Digital News felt that putting "VAX" in the
headline would give the article more of a DEC slant, but it's obviously
misleading.]

------------------------------

Date: Sat, 28 Nov 87 13:59:06 PST
From: Dwayne Virnau... <[e-mail]>
Subject: MacKermit Status?
Keywords: Macintosh Kermit

Greetings from the INFO-MAC moderator, keeper of the sacred INFO-MAC
archives.  Files in the archives are available to anyone on the ARPAnet or
BITNET, and specifically to some 10,000 people who subscribe to the INFO-MAC
mailing list.  The latest version of Kermit for the Macintosh I have is
0.8(34), which does not work well (at all?) on the Mac2.  So, a few
questions:

What is the latest version of Kermit for the Macintosh?  How can I obtain a
copy of it?  I have FTP access, and would prefer to avoid tape or disk
distribution.

And on a slightly different note, what is the proper way to make this
request?  Since I am INFO-MAC I field hundreds of questions from people who
expect me to know every detal of the Macintosh, I apologize if INFO-KERMIT
is not the proper address.  But I am also hoping you might be able to direct
me.

Many thanks,

Dwayne Virnau...
Moderator, Info-Mac

[Ed. - A new MacKermit was sent to us by Matthias Aebi of the Eidgenossische
Technische Hochschule in Zuerich, who also wrote Kermit for the Lilith
workstation, announced in Info-Kermit V6 #25, November 6, 1987.  Since then,
Paul Placeway at Ohio State has been working on it.  See the next message for
news about this.]

------------------------------

Date: Mon, 21 Dec 87 16:35:01 EST
From: [e-mail] (Paul Placeway)
Subject: Version 0.9(36)b4 of Macintosh Kermit Available for Testing
Keywords: Macintosh Kermit

Following is a BinHex 4-ified copy of MacKermit 0.9(36)b4.  I have made
several changes to Matthias' code:

The C-Kermit part of 0.9(36)b4 is based on the (absolutly vanilla) 4E(067)
code.  I didn't have to edit any of the ckc* files a bit (ckmpro.c is just a
warted ckcpro.w with the standard Mac patch).

The backslash-number characters in the key macro code are now done in Octal
(just like C does).  Also, one can do control characters symbolically:
\^A --> Control-A.

Macro strings are stored as Pascal strings throughout now, so that one can
make a macro that includes NUL (ASCII 0).

MacKermit now has MultiFinder support.  It understands how to give away time
slices, has the SIZE (-1) resource, and will do background file transfers
(timeslicing multiple times per packet).  (In the process, the file xfer
dialog became modeless).

It has the FOND resource in the source files now (so SEs should be happy).

I added the extra stuff to the emulator so that VAX TPU will get along with
it.

Clayton Elwell added the ANSI insert multiple characters command
(ESC [ n @) to the emulator.

I also added a few extra bells and whistles:
. flashing/nonflashing cursor option
. visible bell option
. extra status indicators in the file xfer dialog,
. the mouse cursor is hidden on every key typed,
. the menu command characters option default is now dependant on the type of
  keyboard that the user is running (set for keyboards with a CTRL key, unset
  for all others), and
. there is now a default set of key macros and modifiers (arrow keys do VT100
  arrow key commands, BACKSPACE -> DEL, backquote -> ESC, command-backquote
  and control-backquote -> plain backquote).

        Have fun,
            -- Paul

[Ed. - Thanks, Paul! (And Matthias too!)  This new version is supposed to run
on any Macintosh, and to correct the various problems that many of you have
reported not only with 0.8(34), but also some of the newer prereleases.  It
should run on the entire Mac family with no special fussing about fonts or
other minutia.  But it probably will not fit into an original 128K Mac (does
anyone still have such a thing?)  The new Mac Kermit is still not a finished
product, however.  Some finishing touches are required to the key definition
feature, and in some other areas too.  And the manual has yet to be written.
Comments and reviews are welcome, and hopefully we'll have a final release
(maybe this time it'll actually be called 1.0!) soon, complete with source in
MPW C.  The program and documentation (such as it is) are in KER:XKM936.* on
CU20B, and KXK936 * on CUVMA.]

------------------------------

Date: Thu, 3 Dec 87 10:53:25 EST
From: Phil Ritzenthaler <[e-mail]>
Subject: Kermit News
Keywords: Kermit News, Newsletter

Is this newsletter still being printed?  I just had Vol.1 No. 1 pass across
my desk (slow, aren't they!) and I was wondering if there have been other
issues?

[Ed. - Yes, we just mailed out Volume 2 Number 1 (the second issue).  Anyone
who was on the mailing list for the first issue should also receive the
second one.  Plus the thousands of people who have ordered Kermit from us
since August 1986, or who have requested to be added to the mailing list.
Meanwhile, this time (unlike the first) we have an on-line version, available
for FTP'ing, etc.  It's in KER:NEWSV2.N1 on CU20B, or NEWSV2 N1 on CUVMA.]

------------------------------

Date: Fri, 4 Dec 87 09:23:36 mst
From: modular![e-mail] (Joe Earley)
Subject: Request for Kermit Information
Keywords: Kermit Protocol

Would you please send me some information about Kermit.  I've heard good
things about it and am hoping Kermit's capabilities exceed those of a package
we have developed in-house.

Specifically, we are interested if Kermit can do the following:

o  do file transfers which leave intact most VMS file header information,
o  do file transfers between Unix and VMS and retain file attributes,
o  handle arbitrary packet sizes to take advantage of clean lines,
o  have a 'talk' mode to do remote logins,
o  do automatic dialing and login to the remote host,
o  do session logging,
o  encoding of nonprintable characters to get around PBX's which act
   upon control characters,
o  do file transfers in an unattended batch mode.

We have only been on the net for about one month.  Our only access to the
outside world is through arizona.  We cannot directly get to an archive site
that I know of, so we can't get any previous information put into the Kermit
news group.  Thanks for any information you can give us.

Joe Earley, Modular Mining Systems, Tucson, Arizona  85714
USENET:     {ihnp4,allegra,cmcl2,noao}!arizona!modular!earley
INTERNET:   modular![e-mail]

[Ed. - Kermit protocol, as defined, can do everything you ask.  Actual
implementations, on the other hand, vary according to which features they
include.  Let's look at your list:

  o Do file transfers which leave intact most VMS file header information?

Currently, no.  If you want to preserve VMS file headers, you have to hexify
the VMS files first and dehexify them on the other end, using a special
utility that comes with Kermit.  Then you get the entire RMS FILES-11 FAB
structure, or whatever it's called.  Future versions of VMS Kermit may
transfer this information directly, using Kermit's File Attribute mechanism
(as PDP-11 Kermit currently does).

  o Do file transfers between Unix and VMS and retain file attributes?

Currently, no.  In the future, VMS and Unix Kermit will be built from common
C-language sources, and should be able to handle file attributes.

  o Handle arbitrary packet sizes to take advantage of clean lines?

Normal Kermit packets are 96 bytes long at most.  Extended-length packets (a
different format) may be up to about 9K in length.  Many Kermit programs
support this option, including C-Kermit for VMS and Unix.  Some
implementations (see the CMS Kermit announcement above) even vary the packet
size according to prevailing line conditions.

  o Have a 'talk' mode to do remote logins?

Yes, most Kermits -- including practically all PC or microcomputer Kermits --
include terminal emulation.  So do VMS and Unix Kermit.

  o Do automatic dialing and login to the remote host?

These features are found in some Kermits, but not all.  Unix Kermit includes
both a "dial" command (with accompanying modem control) and a script language.
MS-DOS Kermit includes a script language, etc.

  o Do session logging?

Most Kermit programs that perform terminal emulation can also do session
logging.

  o Encoding of nonprintable characters to get around PBX's which act
    upon control characters?

This is a hallmark of the Kermit protocol.  It encodes all packets as lines
of printable text.

  o Do file transfers in an unattended batch mode?

Yes.  This is a built-in part of the Kermit protocol.]

------------------------------

Date: Tue, 15 Dec 87 04:46:33 PST
From: [e-mail] (Rich Fay SPO-103/1 POLE 1-6)
Subject: VAX/VMS Cluster and Kermit Problem
Keywords: VAX/VMS Kermit

My name is Rich Fay from Digital.  I work at the Springfield Plant.  We are
having a problem using KERMIT with our VAX cluster as described below:

We are using VMS 4.6 and have the last 3 versions of VMS Kermit including
V3.3.111. All of them exhibit the same problem I will now describe.  We are
using MSKermit 2.29 and CPM ROBIN KERMIT V 4.05, (this problem only occurs
when logging in through a modem, or a Hardline that is connected through an
interface that uses modem protocols).

Sample Session follows;

dial up and logon

$Kermit
VMS Kermit-32 version 3.3.111

Kermit-32>set file type binary

Kermit-32>server
Kermit Server running on VAX/VMS host.  Please type your escape sequence to
 return to your local machine.  Shut down the server by typing the Kermit BYE
 command on your local machine.
12:12:58.14    %KERMIT32-F-TIMEOUT, device timeout
12:12:58.75    %KERMIT32-E-RECERR, Receive error - !AS
12:12:59.14    %KERMIT32-F-TIMEOUT, device timeout
12:12:59.56    %KERMIT32-E-RECERR, Receive error - !AS
12:12:59.96    %KERMIT32-F-TIMEOUT, device timeout
12:13:00.38    %KERMIT32-E-RECERR, Receive error - !AS

It seems that this problem only exists on vax systems that belong to a
cluster.  I also have an RT11 system running KERMIT version 3.53 with RT11
verison 5.4 and am using a DZV11M on an 11/23+, the DZ is connected to a hard
line to the VAX.  This system exhibits the same problem as the Robin and the
Rainbow.  From home, I dialed up a system that is not on the cluster and all
works very well.  I then try dialing up a system on the cluster and get
immediate failure.

I have posted this problem to the Digital KERMIT notes conference and noone
seems to have a solution to our problem.  We are hoping that you will be able
to shed some light on this problem.  Is there some special hardware/software
setups that must be done on the cluster to make KERMIT work properly??

Thanx in advance for any help you can offer to this problem.

                       Regards,
                       Rich Fay

Return address is: [e-mail].

[Ed. - As noted previously, VMS Kermit-32 (the Stevens version, written in
Bliss) is a "stable" product (to use the corporate euphemism).  This message
was circulated to various VAX/VMS cluster sites, and they reported no such
problem.  Can anybody reproduce it or suggest a cure?  Meanwhile, development
on the new C-language VMS Kermit continues.]

------------------------------

Date: Sun, 20 Dec 87 15:15:39 PST
From: [e-mail] (Jamie Hanrahan)
Subject: Non-Bug Report, MS-Kermit, CP/M Kermit (Kaypro)
Keywords: CP/M Kermit, Kaypro Kermit, MS-DOS Kermit

I've used both CP/M Kermit and MS-Kermit between my Kaypro 8 and my brand-new
HyperTurboWhizzoSchizo-AT clone to the VAXes at work and various other large
machines, but until recently, I'd never tried transferring files between my
machines; so when it came time to move some dBASE II databases to the AT
clone, I approached the project with some trepidation.

The AT follows the RS232C standard of using a male connector for a DTE port,
but the Kaypro (also wired as a DTE) does not, so I needed a gender changer
in addition to my modem eliminator cable (which has two females).  Before
attempting file transfers I decided it'd be best to just CONNECT the two
machines and see if characters typed on one would appear on the screen of
the other.

This worked the first time.

Time to try transferring a .DBF file.  Put the AT in RECEIVE mode, and SEND
from the Kaypro...

This, too, worked the first time.  Wait a minute, things aren't supposed to
be this easy...  I'll run this .DBF through dBASE III+'s II-to-III converter
and see if it hiccups on anything.

Looks perfect.  The rest of the .DBFs, index files, and program files
went just as easily.

You people do good work!!!!

(I'm sure this is old hat to you, but with all the bug reports you must get,
I figured you'd appreciate something a little different...)

Merry Christmas,

        --- Jamie Hanrahan
        (uucp:  {cbosgd | hplabs!hp-sdd | sdcsvax | nosc}!crash!jeh)
        (arpa:  crash![e-mail])
        (internet:  [e-mail])

[Ed. - Thanks, Jamie!  It's always nice to get reports like yours.]

------------------------------

Date: Mon, 21 Dec 87 06:45:04 PST
From: [e-mail] (Kenneth Adelman)
Subject: Kermit 3.79 on Apple 2c
Keywords: Apple II Kermit

> I have been using Apple Kermit 3.79 on an Apple 2c and find it works great!
> Terminal emulation and transfers at 2400 baud with no missing characters,
> VT100 emulation including keypad, the works!    But there's one minor
> problem...
>
> While characters received from a remote system over the modem come through
> OK at 300, 1200, and 2400 baud, those generated by the modem itself are
> often garbled.
>
> Has anyone seen this problem?  Is it a Kermit or a 2c problem?  At first I
> thought it was a matter of not responding to interrupts in time, but since
> it even happens at 300 baud this doesn't seem likely.

This sounds like a familiar problem. In order to save a few dollars, the Apple
//c's serial interface was clocked with a signal which was already present on
the motherboard and very close to the right frequency rather than adding a few
dollar crystal and clocking the 6551 ACIA at the right frequency.  As a result,
the Apple interface runs a few percent slower than the advertised baud rate,
and won't talk to some modems.  This problem is not present on any of the other
Apples, and perhaps Apple fixed it on the later //c's by adding the crystal.

I seem to recall someone saying that Apple would fix the problem if you could
convince your dealer that it exists. Apparently the serial interface talks to
Apple's modems just fine. The other solution would be to find a 6551 ACIA spec
sheet which would tell you what frequency crystal you need and what pins on
the 6551 to connect it across.  Presumably you would need to cut one trace and
add the crystal.

                            Ken

------------------------------

Date: Wed, 16 Dec 87 15:44:47 PST
From: [e-mail] (Dan Senderowicz)
Subject: IBM 370 Mainframe UTS24-Kermit?
Keywords: UTS24 Kermit, IBM 370 Kermit

Does anyone have a working version of Kermit for a 370 mainframe running
UTS24?  Thanks. Dan.

[Ed. - C-Kermit has code in it to support UTS24 (a kind of half-duplex Version
7 Unix for IBM mainframes from Amdahl Corp), and this code was used at several
sites in the past, but apparently it does not work at Berkeley.  Can anybody
who's still running UTS24 help?  This is one case where "portable 370" Kermit,
announced above, probably does not apply.]

------------------------------

Date: 8 Dec 87 07:58:24 GMT
From: amdcad!amdcad.AMD.COM![e-mail] (Indra Singhal)
Subject: Kermit & Everex Modems?
Keywords: Everex Modem, Internal Modem, MS-DOS Kermit

I just began subscribing to this group. I was told that there
had been a posting about a quirk in Everex modems that interfered
with proper Kermit operation on their modems. If any on of you
has a copy of the proceedings of the discussion, please
e-mail to me.
    Thanks...

-I said so... & said it for myself.             Indra K. Singhal
{ucbvax,decwrl,allegra}!amdcad!indra or amdcad![e-mail]

[Ed. - MS-DOS Kermit 2.29 for the IBM PC family did indeed have trouble
dealing with Everex or Hayes half-card internal modems.  Version 2.29B and
later fix the problem.  Try the current 2.29C release in KER:MSTIBM.*.]

------------------------------

End of Info-Kermit Digest
*************************
-------
13-Jan-88 17:46:00-EST,14271;000000000001
Mail-From: SY.CHRISTINE created at 13-Jan-88 17:44:59
Date: Wed 13 Jan 88 17:44:58-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #1
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 13 Jan 1988        Volume 7 : Number 1

SPECIAL EDITION:

                       Announcing MS-DOS Kermit 2.30
         Announcing version 2.29Z of MSKERMIT ported to RMX86 & RMX286

----------------------------------------------------------------------

Date: Mon, 11 Jan 88 19:55 MST
From: Joe Doupnik <JRD@USU> and Frank da Cruz <SY.FDC@CU20B>
Subject: Announcing MS-DOS Kermit 2.30
Keywords: MS-DOS Kermit 2.30, IBM PC Kermit 2.30, DEC Rainbow
Keywords: Tektronix Emulation, NetBIOS

This is to announce a major new release of the MS-DOS Kermit communication and
file transfer program, version 2.30, the first major release since version 2.29
appeared in May 1986.  The code has been frozen as of January 8, 1988.  Any
further features or fixes will be deferred for future releases.

The major new features of version 2.30 are:

 . Long file transfer packets (up to 1000 bytes)
 . NetBIOS local area network support
 . A simple script language for automated dialogs with other computers
 . Tektronix 4010 graphics terminal emulation
 . Improved DEC VT102 and Heath 19 emulation
 . ANSI printer control
 . Selectable initialization file names
 . File transfer performance statistics reporting
 . A new, more powerful, more portable key redefinition facility
 . Support for new IBM keyboards
 . A mechanism for installing COM3 and COM4 support
 . Ability to assign Kermit connect-mode "verbs" to arbitrary keys
 . Keyboard and port input character translation during terminal connection
 . Support for both 7-bit and 8-bit (international) character sets
 . Improved interaction with DOS batch programs
 . More flexible command-line invocation options
 . Security features for server operation
 . Ability to operate Kermit through an external console via CTTY
 . Compatibility with most internal modems
 . Modem status report (CD, DSR, CTS)
 . Increased memory for screen rollback, macro and key definitions
 . Garbage collection of macro and key definition memory
 . Improved cooperation with half-duplex hosts
 . Improved DOS error handling
 . Improved debugging and logging functions
 . Improved consistency of command syntax
 . A completely rewritten manual

The program requires DOS 2.0 or later, and 90K+ of memory.  Version 2.30
currently runs on the entire IBM PC family, including the new PS/2 series, on
IBM clones such as the Compaq, AT&T 6300, and DEC VAXmate, and on "semi-clones"
like the Seequa Chameleon and Data General/1, which have different serial port
adapters.  There is also a specific version for the DEC Rainbow (which does not
include Tektronix emulation), and a "generic MS-DOS" version that should run on
any DOS machine, using only DOS calls (no specific terminal emulation).

Thanks are due to James Sturdevant of A.C. Nielson Company for the initial
implementation of the script language, to Joe Smith of the Colorado School of
Mines and Brian Holley of the University of Cambridge (UK) for the original
Tektronix emulation code, to David Knoell of Basic American Foods for the
initial implementation of "Kermit verbs" assigned to keys, and to AT&T for
supporting the NetBIOS development.

And thanks also to the hundreds of Info-Kermit Digest subscribers who tested
the many prereleases of this program, reported bugs, and suggested new
features, and who read and commented on drafts of the new manual.

The new IBM version replaces several previous versions that were distributed
separately, including the MSVCLO version (for IBM near-clones like the Seequa
Chameleon and DG/1) and the Olivetti M24 version.

Untested versions are included for the HP-150, HP-110 and Portable PC, and
the Grid Compass II -- if you have any of these machines, please try out the
new version!

Previous releases of MS-DOS Kermit also ran on a number of other machines,
including the Wang PC, Victor 9000, Sanyo MBC, NEC APC and APC3, etc.  The code
for these non-IBM compatibles will also be to 2.30 level, and released when
available.  Volunteers to test and fix the code for these machines are heartily
encouraged to step forward!

The files for version 2.30 have been installed in Kermit Distribution at
Columbia University.  They are available on the Internet from host
CU20B.COLUMBIA.EDU (a DECSYSTEM-20) as follows: run FTP, log in as user
ANONYMOUS, any password, and GET (or MULTIPLE GET, or MGET, according to the
syntax of your FTP program) the desired files.  They are also available on
BITNET and EARN from host CUVMA (an IBM mainframe) by sending a message to
KERMSRV@CUVMA requesting the desired files.  To learn more about KERMSRV, send
it a message "HELP".  KERMSRV at the University of Toledo (UOFT02) (a VAX/VMS
based Kermit file server) also has the files, and eventually, they will also be
available via UUCP from Oklahoma State University, from and from dialup
bulletin boards around the world.

The executable files are stored in a special printable bootstrap format, called
"BOO files".  These are decoded into .EXE files using a "BOO-file decoder"
program.  These are available written in various languages, including Basic,
MASM, C, and Pascal.  The documentation is available online in plain ASCII text
format, and in Scribe text formatter source format.  Following is a synopsis of
the files.  The KERMSRV name is the same as the CU20B name, except the "KER:"
should be omitted, and the period between the filename and filetype should be a
space, e.g. KER:MSAAAA.HLP on CU20B is MSAAAA HLP on CUVMA.

 CU20B Name        Size        Description

 KER:MSAAAA.HLP      7K        Explanation of file naming conventions
 KER:MSB*.*        130K total  BOO-file encoding/decoding programs
 KER:MSVIBM.BOO     97K        IBM PC Kermit, BOO-encoded executable
 KER:MSVRB1.BOO     68K        DEC Rainbow Kermit BOO file
 KER:MSVGEN.BOO     62K        Generic MS-DOS Kermit BOO file
 KER:MSTHP1.BOO     63K        HP-150 (untested)
 KER:MSTHPX.BOO     64K        HP-110 and Portable PC (untested)
 KER:MSTGRI.BOO     64K        Grid Compass II (untested)
 KER:MSKERM.DOC    263K        MS-DOS Kermit manual, plain ASCII text
 KER:MSKERM.MSS    263K        Scribe text formatter source for manual
 KER:MSKERM.HLP     12K        A summary of MS-Kermit commands
 KER:MSKERM.BWR     11K        List of known restrictions, bugs, etc.
 KER:MSS*.*        638K total  System-independent MASM Source files (13 files)
 KER:MSG*.*        110K each   System-dependent source (graphics, IBM only)
 KER:MSU*.*      70-85K each   Sys-depn source (keyboard support, all systems)
 KER:MSX*.*     39-150K each   Sys-depn source (port i/o, etc, all systems)
 KER:MSY*.*        100K each   Sys-depn source (terminal emulation, IBM only)
 KER:MSZ*.*        183K each   Sys-depn source (term emul, cont'd, IBM only)
 KER:MSV*.MAK        2K each   Microsoft MAKE files for each version
 KER:MSV*.BAT        2K each   Batch files to build each version
 KER:MSV*.LNK        1K each   LINK command files for each version

The utility program MSUCHK.C (and .BOO), contributed by Phil Benchoff of
Virginia Polytechnical Institute, allows convenient determination of
MS-Kermit's new keyboard codes on the IBM PC family.

Be sure to read the MSKERM.BWR file before trying to use the new version, or
reporting any problems with it.

Here are the minimum files needed for the new release ("xxx" stands for the
specific version, IBM, RB1, or GEN):

1. For everybody: The documentation -- MSKERM.DOC, MSKERM.HLP, MSKERM.BWR.

2. For those who already have Kermit on their PC:  MSVxxx.BOO.  If you don't
   have the MSBPCT "BOO-file decoder", also get that.

3. For those who want to make modifications to the sources:
   MSS*.*, MSGxxx.* (if any), MSXxxx.*, MSYxxx.* (if any) ,MSZxxx.* (if any),
   MSVxxx.MAK (or .BAT if you don't have MAKE), and MSVxxx.LNK.

The systems for which we don't yet have the new version ready are still in
the Kermit distribution as before, under the MSV, MSX, and MSY prefixes.  These
will be replaced as the new ones appear.

The IBM PC and DEC Rainbow versions may also be ordered on diskette from
Columbia, along with typeset, printed copies of the manual.  The IBM version
is available on 5.25-inch 360K DS DD diskettes, and on 3.5-inch 720K DS
diskettes for the PS/2 family.  The Rainbow version is on RX50.  Send mail to
[e-mail] or [e-mail] for ordering
information.  The distribution diskette for the IBM PC version will also be
submitted by Columbia to various user groups and diskette services.

New Features -

Of particular interest are the Local Area Network and Tektronix items.  Both
are available only for the IBM PC version of Kermit-MS.

LANs can be used as a communications pathway between cooperating Kermits and
between Kermit-MS and a host which allows direct remote logins from the LAN.
The mechanism is the NetBIOS emulator program supplied with each network, and
thus it works with most LAN systems.  Any station can become a Kermit network
server or a client, without interference with the regular network fileservers,
to allow multiple Kermit to Kermit links on a voluntary peer to peer basis.
The mechanism uses just the NetBIOS and not vendor dependent Asynchronous
Communications software packages (Kermit puts its own packets or Connect
mode characters in NetBIOS packets and uses the NetBIOS protocol in addition
to the standard Kermit protocol).

Tektronix terminal emulation provides standard line drawing, dot, and
character graphics of the 4010 class terminals using true graphics on the PC.
Kermit-MS automatically determines the display and display adapter board in
current use and does high resolution graphics in response to Tek style
commands (which are described in the new Users Manual).  Display adapters
currently supported are EGA, CGA, Hercules, AT&T/Olivetti, and even regular
Monochrome (with text characters rather than dots).  The graphics will be in
color (foreground and background) and will be preserved separately from
ordinary text (VT102, VT52, Heath-19) screens if the hardware permits and one
can switch back and forth from the keyboard.   Tektronix specifications have
been extended slightly to allow the host to switch Kermit-MS into and out of
graphics mode automatically for easy plotting from packages such as SAS.

The IBM PC version now supports the COM3 and COM4 ports available on many
machines with added hardware, provided the user informs the BIOS of their
presence.  The Users Manual shows how to do this.  Kermit-MS/IBM adapts to
screen dimensions found at startup, such as 132 columns or 43 lines, and is
able to switch several popular non-IBM EGA boards to 132 column mode under host
control.

Long packets, up to 1000 bytes, are supported to increase efficiency on long
haul communications circuits.  Efficiency increases by using fewer packets and
thus less overall time waiting for packets to be acknowledged.  Strong three
byte CRC checking is encouraged; it does not degrade local performance.  Long
packets are a reasonable alternative to the sliding windows approach which has
a problem on PCs when they attempt disk i/o while receiving characters on the
serial port (interrupts can get lost and packets need to be repeated).

Translation mechanisms are present to assist multilingual usage of essentially
ASCII or English style machines.  These are not panaceas for a very complex
problem, but testing in Europe indicates it is a step in the right direction.
The mechanisms are conversion of characters about to be displayed, control of
character size (7 or 8 bits), and the new generalized keyboard handler present
for all MS DOS machines.

A sustained awareness of supplementary input and output devices used by
disabled and other individuals is present in many parts of the program.  As we
learn more about such devices Kermit-MS will try to make their use possible and
comfortable.

Overall, the interior technical improvements are numerous.  This gives us added
flexibility and increased performance.

And may we share with you -

Like any Kermit program, MS-DOS Kermit is for everyone to use and share.  Once
you get it, feel free to pass it along to your friends and colleagues.
Although it is copyrighted and not in the public domain, we ask only that you
not attempt to sell it for profit, and that you use it only for peaceful and
humane purposes.  If you have comments, suggestions, improvements, or fixes,
please send them to Kermit Distribution at Columbia University, where they can
be considered for the next release or added to the "beware file".  Happy New
Year, and use Kermit in good health!

  Joe R. Doupnik                               Frank da Cruz
  Center for Atmospheric and Space Sciences    Center for Computing Activities
  & Dept of Electrical Engineering             Columbia University
  Utah State University                        612 West 115th Street
  Logan, Utah  84322                           New York, NY 10025
  [e-mail]                               [e-mail]

------------------------------

Date: Wed, 06 Jan 88 19:18:10 PST
From: [e-mail]  (Jack Bryans)
Subject: Announcing version 2.29Z of MSKERMIT ported to RMX86 & RMX286
Keywords: Intel, RMX Kermit

This version was made from the version 2.30 sources of MSKERMIT.  Last minute
fixups of the RMX code to support changes from version 2.29C are included.
If there are no problems in the next couple of weeks, it will be released as
version 2.30.  The RMX86 port is MSTRMX.BOO, the 286 is MSTRX2.BOO.
MSTRMX.DOC is still relevant.

------------------------------

End of Info-Kermit Digest
*************************
-------
22-Jan-88 17:08:31-EST,31139;000000000000
Mail-From: SY.CHRISTINE created at 22-Jan-88 17:07:33
Date: Fri 22 Jan 88 17:07:33-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #2
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 22 Jan 1988       Volume 7 : Number 2

Departments:

  ANNOUNCEMENTS -

       MSTZ10.BOO (New version of Z-100 Kermit-MS)
       New Versions of MSBMKB and MSBPCT
       Request to Originators of Kermits on BITNET
       Texas University CDC Kermit No Longer Supported
       TRS-80 Model II Kermit Files?

  MS-DOS KERMIT -

        MSTIBM Tek-Mode Problem
        Re: Observations on new Kermit 2.29C with partial Tektronix emulation
        Use of IBM PC Kermit to Control a Video Disk Player
        Retaining Past Screens
        MSKERMIT ver 2.29C tektronix 4010 won't overlay ALPHA and VECTOR
        Screen Scroll in MS-Windows
        MS-KERMIT V2.29C DATED DEC 16/87 VT102 PRINTER PROBLEM
        Kermit 2.29C
        Tektronics 4010 Kermit
        MS-KERMIT 2.29c Scroll-Back Problem with New Output
        MS Kermit and C language.
        MS-Kermit 2.30 Problem
        Problems with Kermit 2.30
        Kermit 2.30 Lack of Screen Blanking Solved
        Rainbow MS-DOS Kermit 2.30
        Generic MS-DOS V2.3 Problem
        MS-KERMIT 2.30

----------------------------------------------------------------------

Date: Sun, 17 Jan 88 21:34:58 EST
From: Drew Derbyshire <[e-mail]>
Subject:  MSTZ10.BOO (New version of Z-100 Kermit-MS)
Keywords: Z-100 Kermit, Zenith Kermit

Following this as separate mail you will find a .BOO file for a new version
of Z-100 Kermit-MS.  This version, tagged internally as 2.29d, was created
by me from the system independent 2.30 sources now online at
cu20b.Columbia.EDU and debugged MSxZ10.ASM sources that I got from Joe
Doupnik in October.

This is not my final version, but the program appears stable and I am
mailing it while I have a chance.  (Anything that works better thank Joe
for, anything that is broken blame me for.)  Changes to the program from the
2.29c version of MSTZ10 include:

     Z-200 support is deleted.  This was partially because I am
     using the standard ZDS include files for BIOS and hardware
     specific constants instead of dynamically chosen "magic"
     numbers, and partially because if problems were to arise
     with the Z-200 code I can't recreate them.  (Z-200 users
     can boot their systems in IBM PC mode and use the better
     IBM Kermit-MS.)

     A screen escape sequence output via DOS from the GETKEY
     routine is deleted.  This interfered with the output of
     various escape sequences and also slowed CONNECT mode down
     to where it fell behind at speeds as low at 1200 baud.

     An improperly installed internal queue for the AUX port is
     deleted.  This was causing monitor RAM and other storage
     overlays which in turn resulted in various display problems
     and system crashes.

     Output from within the terminal emulator is now done via
     direct calls to the Z-100 monitor ROM.  File transfer output
     is still done via DOS, so most "screen saver" programs will
     continue to work properly and not blank the screen during long
     file transfers.

     The HANGUP command is added.

     The BREAK command is fixed.   Formerly, it hung up the
     phone.

     The CONNECT mode HELP command no longer improperly enters
     server mode.

     Key values returned by the SHOW KEY command now match the
     values in the Z-100 user's manual.

This version has the following known bugs:

     The SHOW MODEM command returns incorrect information.

     All input on the keypad is taken as alternate keypad mode;
     the VT-52 escape sequence to have the keypad output normal
     numerics will be ignored.  However, the SET KEY command can
     be used to force these keys to output numerics.

     If the host sends the disable scan mode sequence (esc X ?),
     the keyboard translator will be disabled for all function and
     keyboard keys until CONNECT mode is exited and re-entered.

     The unshifted BREAK key is invisible to KERMIT.

These are for most part minor problems, and I consider the program
quite usable while I take my time correcting the bugs and exercising
the code in general.  Once these error are corrected, I will forward
the updated BOO file and sources to Info-Kermit.

Anyone desiring my interim sources may send me a note directly.

Drew Derbyshire

p.s. Don't thank me, thank Joe Doupnik for putting up with my questions
     and lack of results for four months, and thank Clarkson University's
     Educational Resources Center for providing E-mail and technical
     assistance.

Bitnet:    ahd@clgw
Internet:  <[e-mail]>
Voice:     914-339-7425
U.S.Snail: 578 Broadway, Apt 6
           Kingston, NY 12401

[Ed. - Thanks Drew (and more thanks to Joe too).  The file has replaced the
old one in KER:MSTZ10.BOO available thru Arpanet by FTPing to CU20B, user
ANONYMOUS (any password) and thru BITNET using KERMSRV.]

------------------------------

Date: 15 January 1988, 18:15:04 SET
From: RECK@DBNUAMA1 (Gisbert W.Selke)
Subject: New Versions of MSBMKB and MSBPCT
Keywords: .BOO Files

I have just sent you MSBMKB.FOR and MSBPCT.FOR.  They are written in as plain
FORTRAN IV as possible to make them better portable; however, some things like
writing/reading binary files are system specific. I have tried to indicate
those places. Also, I have included as much as I knew about BOO format in
comments.  In addition, I am sending MSBMKB.PAS, written in Turbo Pascal
(3.02). It runs quite a bit faster than the C version due to i/o buffering. I
include a boo-ed version of the COM file.

Congratulations on *the* *final* MS-Kermit 2.30!! What I have seen from
it up to now, I'm completely happy with it. Great stuff!

\Gisbert

[Ed. - Thanks, Gisbert!  Your en/de-BOOing programs are now installed in
the Kermit distribution as MSBPCT.FOR, MSBMKB.FOR, along with MSBPCT.PAS,
a Turbo Pascal version you sent us last November.]

------------------------------

Date: 14-JAN-1988 17:06:37 GMT
From: [e-mail]
Subject: Request to Originators of Kermits on BITNET
Keywords: Lancaster University

Readers of the Columbia Info-Kermit Digest might be aware that Lancaster
University in England runs a distribution service parallel to that offered
by Columbia on their CU20B system. We have a collection of Kermit files that
is as close to what's available on CU20B as possible and can be accessed on
the British universities network or over dial-up lines. We also write tapes
and discs for people who want them.

Until recently, we've been keeping our set of files up-to-date by FTP'ing
from CU20B, and we've been no more than a few days behind the US.  However,
the FTP service from Britain to Arpa closed last year, so we can't acquire
anything by that route.  We also have no capability to request files from
BITNET servers.  We get sets of tapes from Columbia a few times a year
(thanks very much to Chris and Frank for this) but inevitably we now lag 3
months or more behind.

So here's a plea to Kermit contributors who use BITNET to mail or FTP their
files to Columbia: if you would be prepared to send a parallel set of files
to us at the same time, we'd be very grateful to receive them, and we'll
look after distributing them in this country.  There's a very active Kermit
community over here which we co-ordinate with our own Info-Digest, so
there'll be more timely feedback for developers if we can get hold of
versions quickly.

We can accept files by mail over BITNET addressed to

             syskermit%uk.ac.lancs.vax1 @ ac.uk

at any time.  It should be OK to send up to 100K minimum per file; there will
be no space problems here so people can send without pre-arrangement.  If
mailing files is a problem we can accept them by FTP (we can't *pull* files
from BITNET, so we have to ask people to send): please mail to me for
details of a receiving account.

Traffic to us on Arpa has to be kept to a minimum, I'm afraid, so please
*don't* send stuff to us on this route. But if you have an Arpa-BITNET
gateway you can use.....

My thanks, and those of the British Kermit community, to anyone who can help
us out with this. We hope to hear from you.

          Alan Phillips
          UK Kermit Distribution
          Lancaster University
          United Kingdom

[Ed. - Thanks Alan for your continuing service...]

------------------------------

Date: Mon 4 Jan 88 10:43:06-EST
From: Christine M Gianone <[e-mail]>
Subject: Texas University CDC Kermit No Longer Supported
Keywords: CDC Kermit

William P. Reeder of the Comutation Center has just informed us that the
University of Texas is no longer to support Kermit-170 for the NOS and
NOS/BE operating systems.  The Kermit sources which are prefixed KER:CDC*.*
are now unsupported.  He recommends that the KER:CD3*.* version of NOS
Kermit, by Steve Roseman at Lehigh University become the standard version
for our distribution tapes.

Thanks to Jim Knutson and the University of Texas for all the past Kermit
support.

------------------------------

Date: Fri 22 Jan 88 11:55:48-EST
From: Frank da Cruz <[e-mail]>
Subject: TRS-80 Model II Kermit Files?
Keywords: TRS-80 Model II Kermit

It has been pointed out to us that the file TR2KER.HEX in the Kermit
distribution is not really a hex file at all, but just garbage. Is anybody
using this version of Kermit on the TRS-80 Model II with TRSDOS?  If so,
could they send in a new, real .HEX file?  Thanks!  - Frank

------------------------------

Date: Tue, 29 Dec 87 13:35 EST
From: <[e-mail]> (Shawn Allin - Alcan KRDC Computer Services)
Subject: MSTIBM Tek-Mode Problem
Keywords: MS-DOS Kermit 2.29C, TEK Emulation

I've just briefly tried the new MSTIBM with Tek emulation on a Compaq 386
with EGA. I ran a PLOT 10 program I have and the emulator went into
Tektronix mode upon receipt of a ESC FF properly.  However, when I tried the
ALT = to toggle back to VT102 mode, it cleared the screen but stayed in Tek
mode.  I had to enter command mode and type SET TERMINAL VT102 to get it
back.  Is this a bug, or am I overlooking something?

     Regards,

     Shawn Allin
     Alcan International Ltd.,
     P.O. Box 8400,
     Kingston, Ont.,
     Canada  K7L 4Z4
     [phone]

     Bitnet: ACCESS@ALCANKTN

[Ed. - Yes, it's Alt-Minus, not Alt-Equals]

------------------------------

Date: 30 Dec 87 06:48:40 GMT
From: [e-mail] (Phil Windley)
Subject: Re: Observations on new Kermit 2.29C with partial Tektronix emulation
Keywords: MS-DOS Kermit 2.29C, TEK Emulation

In article <[e-mail]> [e-mail] () writes:
>
>    7. Seems to pick up the type of graphics adapter
>    automatically.  I haven't tested this on a Hercules though . . .
>

It works with Hercules as well.

>
>If anyone knows of any new features or how to set keys please post or
>email me.

Here's a few lines from my mskermit.ini file that sets some keys:

set key \338 \Kkp0
set key \335 \Kkp1
set key \336 \Kkp2
...

I found these out mainly by a combination of experimenting and
accident.  I'm still trying to figure out how to write scripts, etc.
Is there documentation for this beast somewhere?

Phil Windley
Robotics Research Lab
University of California, Davis

[Ed. - The new SET KEY feature is thoroughly documented in the new MS-Kermit
2.30 manual, KER:MSKERM.DOC.]

------------------------------

Date: Fri, 8 Jan 88 17:11:10 EST
From: [e-mail] (Atul Kacker)
Subject: Use of IBM PC Kermit to Control a Video Disk Player
Keywords: MS-DOS Kermit, Video Disk Player

We have a user here who is currently using a DEC VT102 terminal for a
special application.  He uses the terminal to access a mainframe database,
which is a database of photographs in the George Eastman House archives.  He
also has a video disk player connected to the printer port at the back of
the VT102 terminal.  If he selects a record in the database that has a video
field, a picture of the photograph comes up on his video disk player.  The
mainframe program does this through the use of standard VT102 printer
control escape sequences.

He would now like to do this on his IBM PC using Kermit which supports the
same printer control sequences.  What I would like to know is how to set up
his system to do this.  I understand that the printer port on a VT102
terminal is a serial port.  What does Kermit use - the parallel or the
serial port when it sends the printer control sequences ?  Can he use COM2
to connect his video disk player to and use the DOS MODE command to redirect
the output of LPT1 ?  Any suggestions welcome. Thanks Atul Kacker
..!rochester!ur-tut!akk2

[Ed. - Version 2.30 of MS-DOS Kermit, just announced, supports all the
printer control sequences that the VT102 does, so it should work the same
way, on either a serial or parallel port.]

------------------------------

Date: Fri, 08 Jan 88 22:05:17 -0800
From: Alastair Milne <[e-mail]>
Subject: Retaining Past Screens
Keywords: MS-DOS Kermit 2.29C

   I am using Kermit 2.29C on IBM's and compatibles, and among all the useful
   features (including the excellent terminal emulation), there is one that
   sometimes drives me up a wall: the saving of past screens.  Every so often
   I will aim for the RETURN key, miss it, and hit HOME instead.  Everything
   stops in its tracks while n pages of screen scroll past.  And END, of
   course, so that it will all scroll back to where it's supposed to be.

   Obviously, in certain circumstances, this could be enormously useful;
   however, in the general case, I find it simply gets in the way; and in
   fact, with a clone having a slower screen than an IBM, or disabled
   interrupts during refresh, it can become very annoying.  I see no way
   among the commands to turn it off (or perhaps reduce the number of screens
   that are saved).  Is there in fact a way; or is one available in the next
   version?

   Thanks very much,

   Alastair Milne

[Ed. - No, there's no way to turn it off.  You can reduce the number of
screens by changing a parameter somewhere and reassembling.]

------------------------------

Date: Sun, 10 Jan 88 20:59:48 PST
From: Ya'[e-mail]
Subject: MSKERMIT ver 2.29C tektronix 4010 won't overlay ALPHA and VECTOR
Keywords: MS-DOS Kermit 2.29C

Possible bug with MSKERMIT version 2.29C:

(Forwarded from: Ya'[e-mail], Dated: Sun, 10 Jan 88 20:56:38 PST)

I have been using MSKERMIT vers 2.29C and have encountered a bug (feature?)
in the Tektroniks 4010 emulation mode.  Specifically, alpha mode characters
will erase and NOT OVERLAY vector mode data.  This frequently causes plot
titles and labels to obliterate the graphed data.

ps:     I have an IBM-PC/xt clone with the CGA adaptor.

[Ed. - This seems to be the behavior on the CGA, but not the EGA...]

------------------------------

Date: Mon, 11 Jan 88 11:12:15 est
From: [e-mail]
Subject: Screen Scroll in MS-Windows
Keywords: MS-DOS Kermit, MS-WIndows

I have had problems making Kermit scroll up/down screens under MS-Windows
when in a window*.

Version 2.29b and 2.29c (21 DEC) have been tested with version 1.01 - 1.03
and 2.03 of MS-Windows.  You are only able scroll up one line.

Both Version 2.29b and 2.29c will scroll properly in a window under
Windows/386.

* In a window refers to setting up the PIF file so that Kermit does not
write directly to screen and does not "modify" a com port.

    Stephen Northcutt ([e-mail])

[Ed. - This is a restriction of the program, noted in the MSKERM.BWR
file.  However, you should still be able to scroll up by using the mouse on
the scroll bar.]

------------------------------

Date: Tue, 12 Jan 88 11:50 EST
From: <[e-mail]>
Subject: MS-KERMIT V2.29C DATED DEC 16/87 VT102 PRINTER PROBLEM
Keywords: MS-DOS Kermit

We have been testing the new version of MS-KERMIT (V2.29c dated Dec 16) and
found some problems with the VT102 printer function.  When we used the old
version of MS-KERMIT (v2.29b), we where able to use the TPRINT command on a
VM/CMS system to print out files directly to the local printer attached to
the PC.  In the new version the printer goes crazy and all sorts of control
characters appear to have been received by the printer.  Where there any
changes to the printer routines of the VT102 option?  Like I said, the
command on VM/CMS worked on the old version of Kermit, but not in the new.

[Ed. - The new version is supposed to act more like a real VT102 than the
previous version, and supports host-controlled transparent printing.  The
behavior and escape sequences are documented in the manual, MSKERM.DOC.]

The TEK4010 emulation of Kermit V2.29C (dated Dec 16) works great when is
used with the IBM 7171 connected to VM/CMS.  We tested it out using SAS
GRAPH to plot various graphics.  We even had SAS GRAPH send the
startup/termination escape sequence with no problems.  Our next tests will
be on the VAX/VMS systems, also running SAS.

Thanks for all the efforts that went into putting MS-KERMIT together, its a
great product.

Luis Strauch
York University
Toronto, Canada
BITNET: LUIS@YULIBRA

------------------------------

Date: Tue, 12 Jan 88 12:07 EST
From: "James A. Harvey" <[e-mail]>
Subject: Kermit 2.29C
Keywords: MS-DOS Kermit 2.30

Jim Griffin gave me a copy of this to test the other day.  It's fantastic!!!
I.U. recently got a site license for a bunch of the Precision Visuals
graphics products (DI-3000, DI-3000 XPM, PicSure Plus, Metafile system,
etc.) and I'm now using the 4010 emulator in Kermit with it as I install and
test stuff.  Sure is a hell of a lot easier than switching back and forth
between PC-PLOT and Kermit, which is what I was doing last month!
Thanks!!!!!

                                - Jim Harvey

PS: It runs rings around PC-PLOT (I have an EGA-compatible system which the
Kermit 4010 emulator seems to make full use of, whereas PC-PLOT didn't
appear to).  I also tried it on a Zenith 151, it worked fine on that too.
The PVI (Precision Visuals) drivers tend to make full use of all the
features of the device they are driving; so any emulator passing off as the
real thing with these drivers is probably quite a good one.

[Ed. - James Harvey is the one who originally added VT100 emulation to Kermit.]

------------------------------

Date: Thu, 14 Jan 88 10:47:03 EST
From: Jim Griffin <[e-mail]>
Subject: Tektronics 4010 Kermit
Keywords: Ms-DOS Kermit 2.30, Tektronix

    I've been testing the beta version of the MSKERMIT that performs
Tektronics 4010 emulation. So far the program is working just fine but, I
would like to voice a complaint about one of the MSKermit commands that had
its definition changed. I would like the CLEAR command to clear out the
keyboard redefinitions instead of clearing the serial port buffer.  The
reason I need to clear the Keyboard definitions is that I frequently switch
back and forth between an IBM CMS machine with a 7171 protocol converter and
a VAX8800 with VMS. For CMS I can define the function keys the way the 7171
wants them but, when I go over to the VAX I need to clear out the CMS
function key definitions and have them set back to a TRUE VT100 state. The
old CLEAR command did this for me. Perhaps an EMPTY command could be
implemented to clear the serial port buffer.

[Ed. - The new syntax is "SET KEY CLEAR".  Also see KER:MSIIBM.INI for an
example of setting Kermit up to work with a protocol converter.]

------------------------------

Date: Thu, 14 Jan 88 11:56:20 PST
From: [e-mail]
Subject: MS-KERMIT 2.29c Scroll-Back Problem with New Output
Keywords: MS-DOS Kermit

A messed-up screen results when new output is superimposed on old after
using the PgUp key to scroll back.  It's best to always press End key before
getting new output.

[Ed. - This behavior can be controlled by SET TERMINAL ROLL.]

------------------------------

Date: Thu, 14 Jan 88 22:12 EST
From: Timothy Stark <[e-mail]>
Subject: MS Kermit and C language.
KeywordsL MS-DOS Kermit 2.30

   Last night, I get mskermit stuffs from kermsrv library after you posted
anncouning information about Kermit 2.30. And I downloaded stuffs into my
IBM PC/AT. It worked fine for both VT100 and Tek4010!!! It is GREAT kermit
terminal! I would like that Tek4010 Graphics Terminal Emulation!  I read a
file called MSKERM.BWR about bugs and missing features. I found that
challaging information at end of MSKERM.BWR said that system-depend machine
language will be replace C-language portable modules in the future.  Who
will rewrite MSkermit 2.30 for C-Language??

[Ed. - Keep watching Info-Kermit... there may be an announcement some day.]

   I found a bug in Kermit 2.30 that SEND command initialized back to 80
packet-lenght after I did SET SEND PACKET 94! I tried to SET SEND PACKET 94
and checked STATUS. It said Sending packet lenght that is 94. I tried to
SEND <file> and Packet-Lenght: 78~79. I rechecked STATUS command.  It said
that 80. I believed that SEND forced to set packet 80 instead 94!  Please
fix it!

-- Tim Stark

[Ed. - It's not a bug.  SET SEND PACKET-LENGTH is used to override the
negotiated packet length, but only if the negotiated one was longer.  In
this case, it's shorter, so what the other Kermit asked for is what it got.
This is described in the manual.]

------------------------------

Date: Wed, 20 Jan 88 10:48:01 EST
From: J. P. Letellier <[e-mail]>
Subject: MS-Kermit 2.30 Problem
Keywords: MS-DOS Kermit 2.30

I am presently using a Zenith AT clone (ZWX-248-62) as a remote terminal to
a VAX-750 running Berkley 4.2.  I downloaded kermit 2.30 and started trying
it out.  I have run into the following problem:

I am running my terminal with "set term color 1,10,33,41".  When I page
things through "more" or "page", at the bottom of the screen page, the VAX
sends the sequence "esc[7m" to change the background for the "more XX%"
notification, and an "esc[m" to reset the terminal to the way it was.
Except, it resets the terminal to the non-intense mode and I can no longer
read anything on my screen.  I can program an "F-key" to put out the "set
term color 1" again, which resets my screen to readable, but that makes for
a two-stroke sequencing through "more", and will be a lot of trouble in
writeups which make an extensive use of background switches (because the
screen also erases when I do the "set term color 1").  jp

------------------------------

Date: 21 Jan 88 18:01:51 GMT
From: [e-mail] (Jim Greenlee)
Subject: Problems with Kermit 2.30
Keywords: MS-DOS Kermit 2.30

Well, I've been playing around with the new version of Kermit that was
recently announced (thanks, Tom :-) for about 2 days now, and I think I have
discovered a bug (or at least an anomaly) in the VT100 emulation.

First, a little background. I had been using version 2.29 (May, 1986) of
Kermit on my AT&T PC 6300 almost since it was released. One of the fea-
tures that I use the most is the ability to set FG/BG colors on a color
monitor - I normally use "set term color 1 10 33 46", which gives me a
high-lighted yellow FG on a light blue BG. I also almost always use the
VT102 emulation mode.

This works fine with version 2.29, particularly in the case where the host
sends a US (underline start) or UE (underline end) sequence to the terminal.
On a color monitor, this causes the FG/BG colors to be reversed.

So...I ftp-ed and unBOOed version 2.30 of Kermit, carefully read the manual
and help files, changed my MSKERMIT.INI files to match the new format, and
discovered that the US/UE sequences do not produce the same results on my
color monitor. What happens is that receipt of a US causes the video image
to be reversed, and the UE sequence causes it to be restored, but for some
reason the FG high-lighting is turned off. If I drop back into command mode
and do another "set term color", then everything works fine until I get
another US/UE sequence.

This problem does not manifest itself with the Heath/Zenith mode (which is
what I'm using in the interim). I checked the beta version (2.29C) that was
posted recently, and got the exact same results - US/UE causes high-lighting
to be turned off. Is this a genuine bug or did I just get a munged copy of
the software? Is their any way I can fix it short of getting all the sources
and ferreting out the problem myself? Has anybody else noticed this problem?

Any and all { help | comments | suggestions } are welcome.

                        Jim Greenlee
The Shadow...!{decvax,hplabs,ihnp4,linus,rutgers}!gatech!jkg

------------------------------

Date: Wed 20 Jan 88 22:01:51-EST
From: Jim Celoni S.J. <[e-mail]>
Subject: Kermit 2.30 lack of screen blanking solved
Keywords: Ms-DOS Kermit 2.30

Recall last month I reported that the December Kermit-MS 2.30 beta didn't
clear the screen for me on going to connect mode.  After your reply, I was
pretty sure Fansi-console was the culprit, whether in its quick scroll mode
(/q1, using extra graphics memory on cga or ega) or not (/q0).  Official
2.30 behaves the same way: cycling through emulation modes cleared things, I
think, but explicit Alt-key clearing didn't.

Imagine, then, my happiness when I discovered that everything works right
when I do a MODE CO80 just before invoking kermit.  Fansi-console is a fine
program with lots of users, and the mode tip might help in other situations
too.  Maybe a word in the .BWR file...

P.S.  I have an IBM 256K EGA and run IBM DOS 3.3 on an Antex AT clone.

> Date: Wed, 20 Jan 88 22:27 MDT
> From: Joe Doupnik <[e-mail]>
> Subject: RE: Kermit 2.30 lack of screen blanking solved

>         The indications seem to be that Fansi-console reports the wrong
> screen size information to callers such as Kermit. The ALT = reset clears
> the known screen size, using ega information stored in the Bios, but
> going through graphics and back to text terminal types does a real live
> mode set (same as MODE xxxx). Mode setting gets back standard screen
> dimensions stored in Command.com and puts everything in proper places both
> in the display board and in the Bios. Apparently, Fansi-console keeps some
> of this to itself so Kermit can't find those parts. Too many chiefs. There
> is not a thing Kermit can do about such a situation, but you might want to
> bring it to the attention of Hersey for their consideration.

------------------------------

Date: Fri, 22 Jan 88 11:47 EST
From: <[e-mail]>
Subject: RAINBOW MS-DOS KERMIT 2.30
Keywords: MS-DOS Rainbow Kermit 2.30

Hopefully someone can answer my question.  I have just finished putting
together MS-DOS Kermit 2.30 for the Rainbow 100.  We use Kermit to connect
to a DEC PDP-11/70 system.  On our system, we have a program to print
certain files via the printer port.  This program simply turns the printer
port on, reads a line, writes an line, and when finished, turns the printer
port off with the proper escape sequences.  This works perfect in terminal
mode, but when using Kermit, it does not work.  The supplement for the
MS-DOS Users Guide especially for the extended DEC Rainbow version of
MS-Kermit says that complete support for all printer port functions has been
included in this version of the emulator.  Should this work?  Can I not from
BASIC on a host system turn on the printer port, print a file, and turn the
printer port back off while running Kermit?

I would appreciate any help on this subject!

Thanks,
Terry Lewis
University of Tennessee at Martin
Martin, Tennessee  38238
TLEWIS@UTKVX1  (BITNET)

[Ed. - You should be able to do this, but there's always the possibility
of a bug, either in Kermit, or in its interaction with the Rainbow's VT102
firmware.  Users are invited to peek at the source code and send in fixes
if necessary.]

------------------------------

Date: Fri, 15 Jan 88 13:32 CDT
From: Raisin in the mid-dle <[e-mail]>
Subject: Generic MS-DOS V2.3 Problem
Keywords: MS-DOS Kermit 2.30

I downloaded the generic MS-DOS kermit V2.3 to try out on my TI-PC (IBM-
compatible-sort-of).  It runs, but whenever I do a 'SET BAUD xxx' command it
complains "Command not implemented".  What gives?  Did I have a download
problem or are others experiences this problem?

Regards,
Stewart French

[Ed. - Setting the baud rate is a system-dependent function, and therefore
is not implemented in Generic DOS Kermit.]

------------------------------

Date: Mon, 18 Jan 88 17:32 N
From: Eberhard Lisse, Abt Verbrennungschirurgie, RWTH Aachen <IUS@DACTH51>
Subject: MS-KERMIT 2.30
Keywords: MS-DOS Kermit 2.30

MS-Kermit has always been among my ten favourite programs and has now moved
up to number one, even beating Don Kneller's NDmake 4.31 for which I now
seriously consider paying the $ 35. :-)

I would like to move its version be renamed to 3.0 as it looks almost a
complete rewrite to me and includes lots of nice new features, not the least
being the Tektronix emulation for which lots of users have longed since some
time.

[Ed. - A sensible idea, but unfortunately, it's been publicized at version
2.30 too far, too wide, and too long.]

I would also like to thank Joe publicly, via INFO-KERMIT, for his time and
effort to produce this marvelous piece of code which I think is better than
most commercial products. And I have tried some ...

regards, el

Eberhard W. Lisse
Burn Unit and Department of Plastic and Reconstructive Surgery
Technical University Aachen
West Germany

BITNET:         ius@dacth51                             preferred
ARPA:           [e-mail]
UUCP:           psuvax1!dacth51.BITNET!ius              from overseas
                unido!dacth51.BITNET!ius                within Europe
                {{uunet!}unido!rmi!}lisse!el            Real Soon Now

------------------------------

End of Info-Kermit Digest
*************************


-------
26-Jan-88 17:30:51-EST,24743;000000000000
Mail-From: SY.CHRISTINE created at 26-Jan-88 17:30:06
Date: Tue 26 Jan 88 17:30:05-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #3
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 26 Jan 1988       Volume 7 : Number 3

Departments:

  ANNOUNCEMENTS -
        Announcing C-Kermit 4E(068)
        Updates for CDC Cyber NOS Kermit (CD3KER)
        Announcing DECSYSTEM-20 Kermit 4.2(262)
        German Translation of MSKERM.HLP for V2.30

  VM/CMS KERMIT -
        Installing CMS Kermit 4.0
        Kermit on 9370 using ASCII Subsystem
        CMS Kermit 4.0 Packet Size Anomaly

  UNIX KERMIT -
        Re: Announcing C-Kermit 4E(068)
        Data General C-Kermit 4E(067)
        Kermit on BSD 4.2
        Re: Kermit on BSD 4.2
        C-Kermit 4D(061) and Microport Unix

  MISCELLANY -
        UUCP Lock Files
        VAX -> NASA VAX Problem
        Secure Kermit File Server for VMS?
        Kermit for the Visual 1050?
        Commodore 64 Kermit and GNU Emacs?

----------------------------------------------------------------------

Date: Sun 24 Jan 88 20:15:25-EST
From: Frank da Cruz <[e-mail]>
Subject: Announcing C-Kermit 4E(068)
Keywords: C-Kermit 4E(068), Unix Kermit

This is to announce another minor release, but this time a "real" release,
of C-Kermit for Unix, VAX/VMS, Data General AOS, the Commodore Amiga, the
Apple Macintosh, etc.  The changes were minor, and only appear in the Unix
versions.  They include:

 . Suspendibility via Ctrl-Z on systems with job control (Bob Brown).
 . Explicit support for SCO Xenix in the Makefile (from D.W. Bettinger).
 . Explicit support for the AT&T 7300, including the ability to dial its
   internal modem (from R.E. Hill, untested).
 . Improved response of the C-Kermit server to 'remote cwd' commands.
 . Miscellaneous small fixes and cleanups.

The major change is that since this is now considered a real release, the
files have been named from XK*.* back to CK*.*, and the XK*.* files are
gone, resulting in a savings of about 2 megabytes in our Kermit distribution
area and on our tapes.

All files' names changed, but the only files whose contents changed are:

 ckuker.upd - Update history
 ckuker.bwr - Beware file
 ckcfns.c   - Functions (better reporting of current directory by server)
 ckcmai.c   - Main program (new version number)
 ckcpro.c   - Protocol module (wart output)
 ckudia.c   - Dial module (ATT 7300 support added)
 ckuusr.c   - New calls
 ckutio.c   - Support for ATT 7300, job control fixes
 ckufio.c   - New zgtdir() function to return current directory
 ckdfio.c   - Ditto (but dummy)
 ckifio.c   - Ditto (but dummy)
 ckmfio.c   - Ditto (but dummy)
 ckvfio.c   - Ditto (but dummy)
 ckwart.c   - Syntax error fixed

These files are in K2: on CU20B.COLUMBIA.EDU, e.g. K2:CKCFNS.C, available
via anonymous FTP.  They are also available on BITNET from KERMSRV@CUVMA as
CKCFNS C, etc.  For information about using KERMSRV to get Kermit files,
send a message to KERMSRV@CUVMA with the message text saying "help".

Please report any problems with this release to Info-Kermit@CU20B.

------------------------------

Date: Wed, 30 Sep 87  14:15:20 EDT
From: [e-mail] (Olaf Pors  804-924-0633)
Subject: Updates for CDC Cyber NOS Kermit (CD3KER)
Keywords: CDC Cyber Kermit

The files CD3KER.INS and CD3KER.MOD contain feature addition to CDC NOS
Kermit (the CD3 Kermit).  CD3KER.INS is a replacement for that file on the
Kermit distribution.  CD3KER.MOD is the only source code you need to upgrade
CD3 Kermit from version 3.2 to the one I created (3.3); this file should be
added to the rest of the CD3KER files on the distribution, so it can be
applied using the CDC UPDATE utility.  UPDATE works with a base file
(usually quite large) and applies modifications (usually small) to create a
file for compilation.  This is the way that CDC maintains their system
software, and I think CD3 Kermit should be handled this way too; i.e., have
a large, unchanging base file and a small modification on the distribution.
New changes would be added to the modification file until it gets too
unwieldy, at which time a new base file would be created.  The CD3KER.INS
file I've supplied assumes the (possible) existence of such a modification
file.  See also the comments in CD3KER.INS.  All the documentation needed
concerning my enhancements (upward compatible) is at the beginning of the
CD3KER.MOD file.

[Ed. - Thanks, Olaf!  And apologies for taking so long to bring your
contribution to public light.  Olaf's changes include support for 8/12 ASCII
binary files, optional kinds of EOF conversion, and support for CDCNET.
Unfortunately, in August 1987 (several months before you submitted this
one), Steve Roseman of Lehigh University ([e-mail]) submitted
another, different, version 3.3 of this program, announced in Info-Kermit V6
#17.  Your files have been put in KER:CD3KER.IN2 (so as not to interfere
with Steve's CD3KER.INS), and CD3KER.MOD.  Meanwhile, let's hope someone
will be able to reconcile the two versions and maybe produce a version 3.4?]

------------------------------

Date: Tue 26 Jan 88 16:15:25-EST
From: Frank da Cruz <[e-mail]>
Subject: Announcing DECSYSTEM-20 Kermit 4.2(262)
Keywords: DECSYSTEM-20 Kermit

This release corrects problems introduced by the previous release, announced
a few digests ago.  Now, not only does DEC-20 Kermit not prevent you from
issuing GET, REMOTE, BYE, and FINISH commands when in remote mode (e.g. to a
PC Kermit server), but now they also work!  In addition, it is now possible
to execute CWD and REMOTE CWD from a TAKE file (it wasn't before).  The new
version is in KER:K20MIT.MAC and KER:K20MIT.DOC on CU20B, and in K20MIT MAC
and K20MIT HLP on CUVMA.  This may be the final release of DEC-20 Kermit;
the main goal is to get the existing bugs out before our last DEC-20 sails
smoothly into eternity.

------------------------------

Date: 01/25 04:02:13
From: Gisbert W. Selke <[e-mail]>
Subject: German Translation of MSKERM.HLP for V2.30
Keywords: MS-DOS Kermit, German Manual

Enclosed is MSGERM.HLP, a German version of MSKERM.HLP.

[Ed. - Thanks, Gisbert!  It's been put in the Kermit Distribution as
MSKGER.HLP, the name change being necessary because the MSG prefix is
already used for something else.]

------------------------------

Date: Tue, 29 Dec 87 10:19:17 EDT
From: Terrence Ford <[e-mail]>
Subject: Installing CMS Kermit 4.0
Keywords: IKC Kermit, CMS Kermit 4.0

Two very minor points that may save people some time installing 4.0:

   1) As received from KERMSRV@CUVMA, the following files all proved to have
      a last record beginning with X'00' (which will cause the assembler to
      complain with IFO053 OP CODE NOT FOUND ON FIRST OR ONLY CARD)

                       IKCUTL.ASM
                       IK0CMD.ASM
                       IK0COM.ASM
                       IK0DEF.ASM
                       IK0DOC.ASM
                       IK0MAC.ASM
                       IK0MAI.ASM

   2) In step 2, the HELPCONV command will create IKCKER $HLP A, not IKCKER
      $HLPCMS A as documented.

As I said, very minor.

Terrence Ford

[Ed. - Thanks, Terrence.  Problem (1) was an artifact of our file transfer
process (FTP, not Kermit!), and has been rectified -- the CUVMA copies no
longer have nulls at the end.]

------------------------------

Date: Mon, 21 Dec 87 11:03:33 PST
From: [e-mail] (James V. Bys)
Subject: Kermit on 9370 using ASCII Subsystem
Keywords: CMS Kermit

We have been running CMS Kermit 3.1 on an IBM 4381 with a 7171 interface
successfully.  We recently received an IBM 9375 with an ASCII Subsystem.
This IBM supported subsystem acts similarly to the 7171.

Kermit compiles and starts successfully on the 9375.  When Kermit is put in
server mode, the FIRST file transfer occurs successfully.  After this
transfer, the terminal attached to the ASCII Subsystem is completely hung.
None of the local reset characters have any effect.  Needless to say, no
further communication by the local Kermit with the 9375 occurs.

The CMS installation instructions state:

"When CMS Kermit is to be used with a 7171, make sure the 7171 is set
up with its 'keyboard lock delay' parameter set to 0.  Otherwise, the
'terminal' will hang whenever CMS Kermit clears the screen..."

This symptom sounds similar to the one mentioned above using the ASCII
Subsystem.  There, however, is no mention that we could find of a "keyboard
lock delay" parameter in manual SA33-1564 "ASCII Subsystem Customization and
Programmer's Guide".

Could anyone that has successfully installed Kermit through an ASCII
Subsystem please comment?

James V. Bys
California Institute of Technology

Internet address: [e-mail]
Bitnet address:   JIMBYS@CITIAGO

------------------------------

Date: Sat, 23 Jan 1988 14:22:08 EST
From: "James H. Coombs" <[e-mail]>
Subject: CMS Kermit 4.0 Packet Size Anomaly
Keywords: CMS Kermit

Thanks for the new version of CMS Kermit 4.0.

I have found many improvements and only one oddity (or two?).

1) The documentation (IKCKER DOC) says:

   "Maximum packet size:               1920"

   But when I try to set the receive packet size to 1920, the executable
   rejects the command and issues the message:

   "Operand must be <1914"

   The same problem occurs when I try to set the send packet size.  In
   addition, when I specify something like '1900', I am told that the
   send packet size is limited to the range '20-94'.


2) This may be a local problem, but I get the following message on startup:

   "Handshake is XON -- not needed"

   CMS Version is "Rel 3 Lev 302.2".

Thanks.  --Jim

Dr. James H. Coombs
Software Engineer, Research
Institute for Research in Information and Scholarship (IRIS)
Brown University
[e-mail]
Acknowledge-To: <JAZBO@BROWNVM>

------------------------------

Date: Mon, 25 Jan 88 23:01:49 PST
From: [e-mail] (Bob Larson)
Subject: Re: Announcing C-Kermit 4E(068)
Keywords: C-Kermit 4E(068)

In article <[e-mail]> [e-mail] (Paul Vixie Esq) writes:
>In article <[e-mail]> [e-mail] (Frank da Cruz)
>writes:
>>This is to announce another minor release, but this time a "real" release,
>>of C-Kermit for Unix, VAX/VMS, Data General AOS, the Commodore Amiga,
>>the Apple Macintosh, etc.  The changes were minor, and only appear in the
>>Unix versions. [...]
                                 ^^^^^^^^^^^^^^^^^^
>I'm curious, though, as to whether this release includes the long-discussed
>"windowing kermit protocol" which would apparently allow several ACKs to be
>outstanding at one time, thus improving performance on half-duplex and X.25
>connections.

Unfortunatly, I'm rather certain full duplex windows havn't made it into
C-kermit yet.  The only version I know of are for Primos, a semi-functional
(and unmaintainable) one for ms-dos, and commercial ms-dos packages (such as
procomm).  There may of course be others I am not aware of.

The later C-kermits do include long packet support.  This is what is desired
for half-duplex, but is not as good for x.25 or long delay hookups.  I'm
curious as to when, if ever, windows will make it into c-kermit.

Bob Larson      Arpa: [e-mail]      [e-mail]
Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson
Prime mailing list:     [e-mail]
                        oberon!fns1!info-prime-request

[Ed. - Sliding windows are not in C-Kermit 4E(068).  This is high on the list
of things to add to C-Kermit, as are Attribute packets, and support for MS-DOS.
These will appear in future releases, which in turn will appear as time
permits.]

------------------------------

Date: Sat, 26 Dec 87 20:02:38 CST
From: [e-mail] (Samudra E. Haque)
Subject: Data General C-Kermit 4E(067)
Keywords: C-Kermit 4E(067)

In your 4E(067) version I believe you have conditional compilation for Data
General machines (== ifdef datageneral), assuming that people who run these
machines want to compile a version for themselves. Well, there is a problem
with that. There are basically two major types of software on DG machines:
AOS/VS and DG/UX, i.e. native AOS with MV/UX subshells and native unix for
the Data General. Unfortunately, on both C compilers the symbol
"datageneral" is defined!  This is of course a problem since both unixes are
*not* identical in file structure and programs.

So: Just using plain "#ifdef datageneral" will tend to break people who try
to compile C-Kermit on DGUX's version.  What I might suggest use the
construct "#ifdef datageneral #ifndef DGUX" etc..

Else: I'm just about finished with 4E(067) for DG/UX.. this version with
proper #ifdef DGUXs. My version of ckuusr.c seems to be broken though,
(symbol line length attribute conflict ? )..and I've been wanting to FTP a
new version over. ... ...

Thanks for your attention.

Samudra E. Haque
Computer Science Systems Group
Computer Science Department
University of Minnesota, Minneapolis, MN 55455.

[Ed. - This message arrived too late for the new release.  But you're more
than welcome to fix the program up for Data General operation and send the
changes back to Columbia, preferably based on the just-announced 4E(068)
release.]

------------------------------

Date: 28 Dec 87 00:42:59 GMT
From: [e-mail] (Michael Galassi)
Subject: Kermit on BSD 4.2
Keywords: C-Kermit

I recently wrote a program to deal with idle users on my system and have a
loose end to tie up before I can send it on to r$ for posting to
comp.sources.unix.

The problem is with Kermit.  When users are kermiting files back and forth
stat(2) on their terminal shows that the device has not been accessed since
the file transfer started.  I know perfectly well that data is going across
the link as the lights on the modem blink in the usual kermit fashion, but
looking at the st_mtime, st_atime, and st_ctime entries in the structure
returned by stat(2) shows no change during the course of the file transfer.
I know this is not a problem with my invocation of the stat system call as
who(1) also reports the terminal as idle.  HELP!!!  How is kermit doing its
i/o?

I am running C-Kermit version 4C, when it starts up I get the message:

C-Kermit, 4C(057) 31 Jul 85, 4.2 BSD

If anyone knows exactly how Kermit does it's i/o could you please
send me mail about this?  Also, what other programs have you found that play
the same tricks with i/o that I should look out for?

        -michael

[Ed. - See message below.  C-Kermit opens /dev/tty in rawmode and does
unbuffered read()'s and write()'s to it.]

------------------------------

Date: 28 Dec 87 17:37:05 GMT
From: [e-mail] (Eric Gisin)
Subject: Re: Kermit on BSD 4.2
Keywords: C-Kermit

C-Kermit probably opens /dev/tty instead of using stdin and stdout, so the
/dev/tty?? inode times are not updated.  The reason for doing this so one
can send stdin or receive stdout as a file.

One fix is to modify kermit to use stderr instead of /dev/tty.

[Ed. - C-Kermit does indeed use /dev/tty.]

------------------------------

Date: Sat, 23 Jan 88 20:39:54 EST
From: Brodsky <[e-mail]>
Subject: C-Kermit 4D(061) and Microport Unix
Keywords: C-Kermit 4D(061)

I'm having difficulties using C-Kermit on a tty port with getty.  Even
though Microport says you can get away with this by running getty on
/dev/ttyM? I have had numerous occasions where the C-Kermit process hangs
while attempting to aquire the port. The process will will linger without
responding to any kill (even kill -9), LCK* file removal, or init state
change.  The only way to get the tty port back is to reboot.  There are no
problems running C-Kermit as long as getty doesn't have the port, however.

This bug is not a consistent one. There are times when running C-Kermit and
getty together works fine and other times when it does not. One thing that
tends to cause the problem to occur more often is when getty has a multiple
speed setting (such as 1200R where it will switch between 300 and 1200 bps).
I suspect some sort of port access confusion in ttyM?, but I haven't yet the
skills to track this beast down. Can anyone help?

Thanks for all the wonderful work Froggers!

                                  Jake Brodsky

"What nature doesn't do to us,
 Is done by our fellow man."     --Tom Lehrer

------------------------------

Date: Sat, 5 Dec 87 09:27:35 CST
From: convex!smu![e-mail] (Laurence Leff)
Subject: UUCP Lock Files
Keywords: UUCP, Lock Files

Our version of kermit does not access the lock files correctly so as to
avoid interfering with uucp under 4.3BSD.

The lock file mechanism changed from 4.2BSD to 4.3BSD.  Yet the version of
Kermit that came with the 4.3BSD distribution from Mt. Xinu is using the old
style uucp lockng mechanism appropriate for 4.2BSD systems.

Has anyone fixed this and can send us a patch?

       Laurence Leff
       Coordinator, Computer Science Department Computer Facilities Management
                    Team
       convex!smu!leff leff%smu@csnet-relay  E1AR0002 at SMUVM1 (BITNET)

[Ed. - Let's hear it once again for UUCP lock files, probably the silliest
single feature of Unix.  Why access to tty devices should be shared rather than
exclusive by default is a profound mystery.  So long as every Unix system in
the world (and every new release of each version) must have a different idea of
where the UUCP lock file should be, what it should be called, what should be in
it, who its owner should be, etc etc, communication programs, like Kermit, that
attempt to work on many different Unix versions will remain in a perpetual
state of confusion (end of tirade).  The past few releases of C-Kermit have had
code to deal with 4.3BSD lock files, but it's not activated by default.  Look
in the module ckutio.c for "NEWUUCP".]

------------------------------

Date: Thu, 21 Jan 88 16:38:24 EST
From: "Robert E. Zaret" <[e-mail]>
Subject: VAX -> NASA VAX Problem
Keywords: VAX/VMS Kermit

Someone just came in with a problem transferring files from his lab's VAX to
a VAX run by NASA.  Both seem to be VAX 11/750s running Kermit-32.  He calls
an 800 number to connect through Telenet using 1200 bps, 7 databits, and
even parity.  He has no problem using the NASA VAX.  However, when he tries
to transfer a FORTRAN source file, he sees no error messages, but cannot
find the file at the other end.  More specifically: he invokes Kermit on the
NASA end and puts it in server mode; then he uses ^]c to escape back to his
local kermit and tells it to send the file; after 3-5 minutes, he gets a new
Kermit-32 prompt.

I am surprised about the Telenet connection: the 800 number seems curious; I
was unable to use Telenet with 7e (I had to use 8n to connect to Telenet and
let it handle, correctly, the computer at the other end that insists on 7e);
and he never sees the usual Telenet prompts.  He is certain he uses Telenet,
not TELNET.

We would certainly appreciate any hints.  Thanks.

[Ed. - The Telenet variations are not totally inexplicable.
A Telenet host can configure the user's Telenet pad as to parity, etc., using
private X.28 (or is it X.29) parameters.  Thus the behavior of your PAD can
depend on what host you're connecting to.  Meanwhile, can anybody who has
used Kermit in this environment help?]

------------------------------

Date: 14 Jan 88 21:19:51 GMT
From: Kral <amdahl!drivax![e-mail]>
Subject: Secure Kermit File Server for VMS?
Keywords: VAX/VMS Kermit

We have a need for a "secure" file server on our VMS machines.  We want
something that would enable our customers to call up, log in, and transmit
or receive files in their home directory.  They should be able to do
directory listings within their own tree as well.  However, they should
not be able to spawn off sub-processes, read or write files outside of their
home directory, etc.  Ideally, the wouldn't be able to have any kind of
access, including directory listings, of anything outside of their home
directory.

Our problem is this:  our machine security is pretty relaxed, leaving
any security up to limiting login access to "trusted" users.  As a result, the
users have gotten used to leaving world read (and sometimes write!) permission
on their home directories.  Most of the users on the machine we wish to
implement this on are Operating System Engineers, so we figured it would be
kind of costly to impose any reasonable security on the system.  We also
figured that permissions probably wouldn't be kept long if we were to require
them to change them.

Now we have customers that want to do file transfer with us, and we need
their accounts secure from each other, as well as our own source code
directories being secure from them.

Right now I am attempting to modify kermit-32 to take out any remote
commands.  I only have the macro sources to work with.  ANy suggestions
are appreciated.

kral                                            [THERE ARE NO ORDINARY MOMENTS]
408/647-6112                                    ...{ism780|amdahl}!drivax!braun

[Ed. - C-Kermit might be easier to work with, but it is not yet truly at
home in the VMS environment.  But it's not clear that changing Kermit is the
answer to the problem.  If they can log in, they can get at other people's
files.  Even if you have a "secure" Kermit on the system, they can use it
to transfer an "insecure" one for their own use.]

------------------------------

Date: Wed, 30 Dec 87 19:31:38 PST
From: Michael Marria <[e-mail]>
Subject: Kermit for the Visual 1050?
Keywords: Visual 1050 Kermit

I am looking for further information to get this Visual 1050 transfering
binaries. It has a usable ascii modem and trap system, so I can get .HEX files
to start up.

This thing is somewhat Kapro II and DEC Rainbo compatible.  I down
loaded the HEX file for a Kaypro which runs until I attempt connection which
crashes the machine.

Any help on this will be much appreciated.

Also, if this helps, it runs CP/M3, though I assume the crash problems
relate to the port loction being different then that of a Kaypro.

Anybody out there have one of these things?

                                Thanks much,
                                Michael

[Ed. - If it runs CP/M 3.0, then you should not be using Kaypro Kermit,
you should be using CP/M 3.0 Kermit, which should run as-is on any CP/M
3.0 system.  The system-dependent hex file for this is in KER:CP4CP3.HEX,
which is combined with KER:CP4KER.HEX to produce the complete running
program, according to the instructions in the manual.]

------------------------------

Date: 12 Jan 88 16:42:08 GMT
From: [e-mail] (Pete Hsi )
Subject: Commodore 64 Kermit and GNU Emacs?
Keywords: Commodore 64

While using GNU Emacs with C64 Kermit at 1200 baud, I noticed when scrolling
UP ONLY, the screen would get garbled. (Probally overflowing the input
buffer? I haven't notice this happening at 300 baud (300 baud?!? ARGH!))

Anybody out there know the solution to this? I have FLOW-CONTROL ON in C64
Kermit.  I do a re-draw screen command (C-l; no biggie) but I would like a
more elegant (sp?) solution such as resetting TERM-CAP, etc.

More info:
    Host: Ultrix (Dec's Unix) running GNU Emacs 18.49.1 and
          VMS running the ported version of GNU Emacs.
    Local: Commodore 64 running Kermit 2.0 (VT100 emulation), 1200 modem.

If possible, send me mail. Thanks in advance.

  Pete

Univs. of Maryland Baltimore County  (UMBC == "U Must Be Crazee" :-)
    ARPA: [e-mail]   or   [e-mail]
    Bitnet: pete@umbc
"Mis-spellings are the fault of my computer"

------------------------------

End of Info-Kermit Digest
*************************
-------
29-Jan-88 19:38:05-EST,21983;000000000000
Mail-From: SY.FDC created at 29-Jan-88 19:37:26
Date: Fri 29 Jan 88 19:37:26-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V7 #4
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 29 Jan 1988       Volume 7 : Number 4

Departments:

  ANNOUNCEMENTS -
        Announcing C-Kermit 4E(070) (Sorry!)
        New Version of Honeywell CP-6 Kermit
        New PDP-11 Kermit Documentation
        CU20B Nears Retirement
        SCANCHEK 4.0 Available

  MS-DOS Kermit -
        MS-Kermit 2.30 Rollback Disable
        Kermit 2.30 for GRiD
        Rainbow MS-DOS Kermit 2.30
        Kermit 2.30 and the Tandy 1000
    IBM PC Convertible Diskettes?

  C-KERMIT -
        C-Kermit Timeout Problem Fix
        Compiling Kermit 4E (068) on BSD 4.3
        A Better Way to Detect Background Execution
        C-Kermit 4E(068) on 4.3 BSD
        Small Problem in ckuusr.c for System V
        Problem with CKUUSR.C on VMS

  MISCELLANY -
        Kermit Support for IBM 3708 Front Ends?
        Re: TRS-80 Model II Kermit HEX File

----------------------------------------------------------------------

Date: Fri 29 Jan 88 21:25:40-EST
From: Frank da Cruz <[e-mail]>
Subject: Announcing C-Kermit 4E(070) (Sorry!)
Keywords: C-Kermit 4E(070), UNIX Kermit

This is to announce, directly on the heels of C-Kermit 4E(068), another new
version, 4E(070).  I apologize for this.  Edit 68 had two fatal flaws,
which are described in messages below, but briefly:

 . getcwd() not defined in BSD UNIX, breaking BSD versions.
 . Unconditional reference to SIGSTOP, breaking non-BSD versions.

A couple other small fixes were also applied.  One is for the error message
C-Kermit returns when it times out (thanks to Paul Placeway).  The other
finally allows Kermit to determine whether it is running in the background, so
that the "disappearing prompt" problem is fixed...  But only for Berkeley and
Ultrix versions.  See messages below.

Sorry for the inconvenience.  If you want to replace the files that were
"damaged" in the 068 release, they are ckutio.c, ckufio.c, ckuusr.c,
ckcfn2.c, ckucmd.c, and ckcmai.c.

------------------------------

Date: January 25, 1988
From: [e-mail]
Subject: New Version of Honeywell CP-6 Kermit
Keywords: Honeywell CP-6, CP-6

I've sent you a tape containing version 1.00 of Kermit that runs on Honeywell
machines running the CP-6 (Control Program 6) operating system.

The following are changes/additions made to CP-6 KERMIT since the original
version (0.95) was sent to Columbia University in December, 1985.  Many
thanks to John Stewart of Carleton University, Tom Erskine of CRC, Mike
Iglesias of UC Irvine, and Mike Schmidt of Honeywell Bull, Canada, for their
help and supplied code.

  . Recognize ARC and LIB as default binary file extensions.
  . Optimize code that strips parity off incoming characters.
  . Block move of packet data to eliminate looping.
  . Eliminate redundant checksum calculation.
  . Handle repeat counts in file name packet.
  . Use FSFA on file that is being received or sent.
  . Added the ability to specify up to two EOR characters instead of
    assuming CR/LF.  This is useful, for instance, when communicating with
    some software on Apples.
  . Fixed bug that caused KERMIT to Memory Fault if a 'LIST' command
    was issued with no fid specified.
  . Enhanced the SHOW command to show some of the SETable things that
    it didn't before (EG, Binary EXtensions) as well as values for
    all the new commands.
  . The PARITY used for a transfer is now logged in the LOG file.
  . The activation character for received packets is now included in
    KERMIT "debug" files.
  . Fixed bug that prevented records with embedded CR's from being
    received correctly.
  . Relaxed syntactical constraints on some commands so optional blanks
    are permitted.
  . Added the SET FILE PREFIX, SET FILE SUBDIRECTORY CHAR and
    SET FILE SUBDIRECTORY { ON | OFF } commands.
  . Made it possible to interrupt multiple file transfers so you can
    quit the current file or the entire group of files.
  . Added the CG and STATION options to allow transfers through ComGroups.

I hope to have another version in about two months that will include long
packets and maybe sliding windows.

- Lee Hallin -
  Honeywell Bull
  5250 West Century Blvd
  Los Angeles, CA  90045
  [phone] x317

[Ed. - Many thanks, Lee!  The new files are in KER:HC6*.*, available via
anonymous FTP from CU20B.COLUMBIA.EDU, and HC6* * available from
KERMSRV at CUVMA via BITNET.]

------------------------------

Date: Thu 28 Jan 88 09:59:41-EST
From: Frank da Cruz <[e-mail]>
Subject: New PDP-11 Kermit Documentation
Keywords: PDP-11 Kermit, RSX, RSTS, RT11

Thanks to Dan Graham at NYU, we have a Scribe'd version of the PDP-11 Kermit
manual, suitable for typesetting and inclusion in the next edition of the
Kermit User Guide.  It's in KER:K11MIT.MSS and .DOC.

------------------------------

Date: Thu 28 Jan 88 09:59:41-EST
From: Frank da Cruz <[e-mail]>
Subject: CU20B Nears Retirement
Keywords: CU20B, Kermit Distribution, DEC-20, DUMPER Tapes

CU20B only has a few more months to live (exact date of retirement still to
be determined).  So, if anybody wants to order DEC-20 DUMPER or DEC-10 BACKUP
tapes, get those orders in soon!  Once CU20B is gone, we won't be able to
make these tapes any more.  Also, over the coming months, we'll be
converting our network operations to a VAX 8700 with Ultrix 2.0 (which is
like 4.2BSD Unix) system and an IBM mainframe running VM/CMS.  Watch
Info-Kermit for announcements about new procedures.

------------------------------

Date: Fri, 29 Jan 88 09:06:00 EST
From: Phil Benchoff <[e-mail]>
Subject: SCANCHEK 4.0 Available
Keywords: SET KEY, SCANCHEK, Key Definition

Finally.  Enclosed is a version of scanchek.c and scanchek.exe that
should match MS-Kermit 2.30.  The enhanced keyboard is supported,
and the program will indicate if a particular key is available on
the enhanced keyboard only.

[Ed. - Thanks, Phil!  For those who don't know, this is an interactive
program that can be used to find the key codes for all the keys on the
IBM PC keyboard, for use with Kermit's SET KEY command.  The files are
kept in KER:MSUCHK.C and KER:MSUCHK.BOO.]

------------------------------

Date: Sat, 23 Jan 88 13:54:57 EST
From: "James H. Coombs" <[e-mail]>
Subject: MSKermit 2.30 Rollback Disable
Keywords: MS-DOS Kermit 2.30

Alastair Milne writes:

    Every so often I will aim for the RETURN key, miss it, and hit HOME
    instead.  Everything stops in its tracks while n pages of screen
    scroll past.  And END, of course, so that it will all scroll back to
    where it's supposed to be.

    ...

    I see no way among the commands to turn it off (or perhaps reduce
    the number of screens that are saved).  Is there in fact a way; or
    is one available in the next version?

To disable the roll back, simply remap the relevant keys to other functions.

I have the opposite problem: mapping the roll back functions to new keys.
I tried with 2.29c with no success; I asked and either didn't get an
answer or it slipped by me.  Is there a way to remap this functionality?

Thanks.  --Jim

Dr. James H. Coombs
Software Engineer, Research
Institute for Research in Information and Scholarship (IRIS)
Brown University
[e-mail]
Acknowledge-To: <JAZBO@BROWNVM>

[Ed. - We received an avalanche of messages to this effect.  Apologies for
the thoughtless "Ed." comment.  Of course you can remap your Home key to not
invoke the \Khomscn verb.  You can move that function to some less easily
hit key, e.g. the commands "set key \327 {}" and "set key \1399 \Khomscn"
move it from Home to Ctrl-Home.  And to answer Jim's question, yes, you can
remap the rollback function to other keys, as in "set key \338 \Kupscn" to
move it to the Ins key.]

------------------------------

Date: Mon, 25 Jan 88 10:51:59 EST
From: Owen Adair <[e-mail]>
Subject: Kermit 2.30 for GRiD
Keywords: MS-DOS Kermit 2.30, GRiD Kermit

I downloaded 2.30 Kermit for the GRiD (.BOO format) and it tries to run, but
all I get is garbage then it crashes. Has anyone else tested the beast on a
GRiD model 1101? I currently use 2.29 and it works although not all the
features function.

Hope INFO-KERMIT can help!

-owen

Owen Adair, WD4FSU
Digital Signal Processing Lab, Georgia Tech, Atlanta GA 30332
Internet:       [e-mail]
uucp:   ...!{decvax,hplabs,ihnp4,linus,rutgers,seismo}!gatech!gt-eedsp!owen

[Ed. - This would require a Grid assembly-language programmer to look at
2.30 code and debug it.  Anybody?]

------------------------------

Date: Wed, 27 Jan 88 10:14 EST
From: <[e-mail]>
Subject: Rainbow MS-DOS Kermit 2.30
Keywords: MS-DOS Kermit 2.30, Rainbow Kermit

I recently put a question here regarding the printer port on the Rainbow.
I had a copy of the documentation for version 2.29.1 which does support
the printer port on a rainbow.  In MSKERM.DOC, it states that the printer
port is not supported and indeed I have found that it does not.  Are there
any plans for the offical distribution of Kermit to support the printer
port, i.e. being able to send the proper escape sequence to the printer port
to turn it on and off and to send files to it from a host such as a vax, or
any host?

Terry Lewis
University of Tennessee at Martin
Martin, Tennessee  38238

[Ed. - This would require an expert Rainbow programmer.  I don't know if
the Rainbow printer port is the same kind of device as the communications
port, with the same interrupt structure, etc.  If so, it might be easy.
Anyone?]

------------------------------

Date: Wed, 27 Jan 88 13:05:03 EST
From: "James R. McCoy (CCS-E)" <[e-mail]>
Subject: Kermit 2.30 and the Tandy 1000
Keywords: MS-DOS Kermit 2.30, Tandy Kermit

I have a strange problem with Kermit on a Tandy 1000 -- I have an older
Tandy 1000 with a Monochrome monitor and MSDOS 3.2.  Kermit seems to work
well enough until I hit the ^]c combination.  At that point the screen goes
blank and commands such as quit exit and push fail -- The only thing I can
seem to do is hit a "C" which puts me back to the host, or I can issue a
three-fingered salute and reboot.

In an effort to work around, I renamed mskermit.ini to *.old and reexecuted
-- This got me to the Kermit-MS> prompt.  Everything worked well until I hit
the "c" to connect.  The conection worked well and the session went well up
to the point where I did the ^]c combination and then I went right back to
square 1 --

Is there a special version specifically for the Tandy 1000?

Thanks for your assistance.

[Ed. - No, there's not a special version for the Tandy 1000.  It's allegedly
IBM compatible, but I have heard a lot of stories to the contrary, e.g. that
the Epsilon editor doesn't work at all, etc.  Anybody know the real story?]

------------------------------

Date: Thu 28 Jan 88 09:59:41-EST
From: Frank da Cruz <[e-mail]>
Subject: IBM PC Convertible Diskettes?
Keywords: IBM PC Convertible

Can anyone say for certain whether IBM PC Convertible 3.5" diskettes
are compatible with the 720K 3.5" diskettes that are used in the IBM PS/2
Model 30?

------------------------------

Date: 27 Jan 88 10:59 EST
From: [e-mail] (John Junod)
Subject: C-Kermit Timeout Problem Fix
Keywords: C-Kermit 4E(068)

The following code was developed about a year and a half ago by Mark A.
Thomas here at David Taylor Research Center to solve the time-out problem as
mentioned in the Info-Kermit Digest, V7 #3.

Hope this helps....

                   L. John Junod
                   junod@dtrc

/* The following fix was made in kermit to prevent the local machine from
timing out the terminal line.  The local machine uses the last access time
of /dev/ttyXX to check for an inactive terminal. Fancy kermit i/o doesn't
update /dev/ttyXX while packets are sent/received. Since a packet doesn't
update the access time of the tty line, The local machine thinks the line is
inactive and times it out after 5-10 minutes.  A call to the routine
check_time() is made in spack() and rpack(), and after 50 packets the tty
time is updated.  60 packets at 300 baud take about 5 minutes to send, so 50
packets is safe. */

/* included to fix local timeout problem */

#include "signal.h"
#include "sys/types.h"
#include "sys/timeb.h"
#define  NULL           0x0

/*  C H E C K _ T I M E  --  Fix timeout during packet sending and
                             receiving.  Since packets don't update the
                             tty access and modify times, we do it.      */

check_time()
   {
   static char *tty_name = (char *) NULL;
   static int i = 0;
   char *ttyname(),*calloc();
   struct timeb tbp;
   time_t t[2];
   if (tty_name == NULL)
      {
      tty_name = calloc(32,sizeof(char));
      strcpy(tty_name,ttyname(0));    /* allocate and get tty name of stdin */
      }
   i++;
   if (i > 50)
      {
      i = 0;
      ftime(&tbp);           /* get system time */
      t[0] = tbp.time;
      t[1] = tbp.time;
      utime(tty_name,t);     /* update tty time */
      }
   }

[Ed. - This would probably do the trick for BSD, but all the time stuff is
system dependent.  BSD, Sys V, Xenix, Venix, V7, etc, have different ways of
getting the time.  Meanwhile, this message has been added to the C-Kermit
"beware file".]

------------------------------

Date: Tue, 26 Jan 88 17:11:35 CST
From: David A Rasmussen <[e-mail]>
Subject: Compiling Kermit 4E (068) on BSD 4.3
Keywords: C-Kermit 4E(068)

make wermit "CFLAGS= -DBSD4 -DDEBUG -DTLOG"
cc -DBSD4 -DDEBUG -DTLOG -c ckuusr.c
"ckuusr.c", line 515: KERMRC undefined

I have not changed anything. I copied the new files described by FDC
on Jan 25.

Is this a general problem or perhaps something I did? (all I did was
copy the new files into my older distribution (066?) with the xk* files.

I think perhaps ckuusr.h also changed if I read your .bwr file right.
Of course this wasn't listed in your message to the net...

Anyhow, that could be it, or else I'm totally wrong :-)

[Ed. - I hope so!  KERMRC is defined in ckuusr.h as ".kermrc" for Unix
systems, and that's where ckuusr.c picks up the definition from.  None of
that changed, and it compiles fine on our Unix (Ultrix) systems.  Did
anybody else have any trouble with this?]

------------------------------

Date: Tue, 26 Jan 88 16:08:36 PST
From: unisoft![e-mail] (Jeff Bloomfield)
Subject: A Better Way to Detect Background Execution (in ckutio.c)
Keywords: C-Kermit 4E(068)

I currently use C-Kermit 4C(052) on a System V machine.  Perhaps this bug
has been corrected.

I usually invoke kermit with an sh script, which runs my dialing (phone
directory) program prior to invoking kermit.

There were various reasons why I had to use
    :
    trap "args" 1 2 3
    :
    kermit

Naturally, since this version of kermit tests the value that that signal(2)
returns in

    if ( signal( SIGINT, SIG_IGN ) ) {
        backgrd = 1 ;
        :
        :
    }
to detect background execution, kermit would fail with

    Fatal: Kermit command error in background execution.

as soon as I made a typo from the interactive prompt.  A solution that seems
to work (on both BSD and SYS V) is:

    if ( ! isatty(0) ) { /* Is stdin a tty? */
        signal( SIGINT, SIG_IGN ) ;
        backgrd = 1;
        :
        :
    }

Refer to:  ttyslot(3) - SYS V
           ttynam(3F) - BSD

QUESTION:  Has this problem been corrected?  Does this look like a more
           reasonable solution?  Appreciate a reply.

[Ed. - This is essentially what C-Kermit 4D and later do.  Except today's
release does it a different way for BSD, which turns out to work even
better: Kermit's process group is compared with the controlling terminal's
process group (got via an ioctl that's unavailable in Sys V), and if they
differ, then it's in the background (thanks to Fuat Baran of Columbia U for
suggesting this approach).  If anybody else has a definitive test for
background operation under Sys V, BSD, or other Unix systems, please send it
in.  I'm not sure the isatty(0) test is foolproof -- it certainly isn't in
BSD.  Nor is the signal(SIGINT,SIG_IGN) == SIG_IGN test.  Neither one of
these tends to work when the program is invoked with "&", whereas one works
and the other doesn't under various other conditions (e.g. "kermit < foo",
"foo | kermit", "kermit < foo &", etc etc).  Also something very strange
happens to the signals if you take a command file from Kermit, which invokes
a shell escape, e.g. "! date").  Enough...]

------------------------------

Date: Wed, 27 Jan 88 10:04:59 -0500
From: Dan Grim <[e-mail]>
Subject: C-Kermit 4E(068) on 4.3 BSD
Keywords: C-Kermit 4E(068)

When I say "make bsd" I end up with _getcwd undefined at link time!  There
seems to be a FORTRAN getcwd routine which might actually work 1but the
arguments don't necessary look compatible.  Has this version really been
built successfully under 4.3?

Dan

[Ed. - About 500 people complained about this one.  The assumption was that
getcwd() was a system call available on all versions of Unix.
Unfortunately, it's not.  On Berkeley, it's called getwd().  The reason I
didn't spot this is that I compiled the program on Ultrix, which is supposed
to be like 4.2BSD, little suspecting that it also includes a collection of
"System V Compatibility Functions".  Real BSD 4.2 or 4.3 doesn't have getcwd.

Unfortunately, the name can't simply be changed to getwd() in BSD versions,
because Kermit already has an internal function by that name, which is
defined and used in ckucmd.c.  So in order to use the system's getwd() call,
Kermit's function must have its name changed to gtword().  These changes are
in 4E(070) announced above.]

------------------------------

Date:     Fri, 29 Jan 88 13:51:31 EST
From:     Gary P Standorf <[e-mail]>
Subject:  Small Problem in ckuusr.c for System V

I tried compiling C-Kermit 4E(069) on a VAX 11/780 running System V Release
2 and it blew up in the ckuusr.c module.  It seems that an #ifdef is missing
around the stptrap() function.  Since this function is called in response to
a SIGTSTP signal, and that doesn't exist on SVR2, it appears that an #ifdef
SIGTSTP is needed so that the function is only included if SIGTSTP is
defined.

Thanks,

Gary Standorf
<[e-mail]>

[Ed. - Thanks for pointing this one out.  The reference to SIGSTOP in
function stptrap() in ckuusr.c should be surrounded by #ifdef SIGSTSP ...
#endif conditionals.]

------------------------------

Date: 28 Jan 88 09:48:00 GMT+109:13
From: <[e-mail]>
Subject: Problem with CKUUSR.C on VMS

The symbol SIGSTOP is not defined on our VMS system(4.5).  The only call to
this routine that I could find was enclosed with the an #ifdef SIGSTSP.  The
program compiled and ran fine on this system after this change was made to
CKUUSR.C.  Thanks for all your efforts, you have a great package.

ken poole
[e-mail]

[Ed. - Thanks, same deal as with Sys V, fixed in 4E(070).]

------------------------------

Date: Thu, 1988 Jan 28   17:46 EST
From: (John F. Chandler)   [e-mail]
Subject: Kermit Support for IBM 3708 Front Ends
Keywords: Kermit-370, 3708, IBM 3708, IBM Mainframe Kermit, TSO, MVS/TSO

The release of Kermit-370 4.0 for TSO is approaching, but there are a few
loose ends that need to be tied up.  One of these is the support for the
3708 front end, which has been copied as accurately as possible from the
version known as TS3KER in the Kermit distribution.  Since there has
apparently never been any feedback on TS3KER, I don't even know if this
particular 3708 approach has worked for anybody besides its originator.
Anybody who is running TSO through a 3708 and who would be willing to report
on either TS3KER or a preliminary version of TSO Kermit 4.0 should drop me a
line.  Thanks.
                                     John

------------------------------

Date: Sun, 24 Jan 88 17:59:02 EST
From: [e-mail]
Subject: Re: TRS-80 Model II Kermit HEX File
Keywords: TRS-80 Model II Kermit

RE: Info-Kermit Digest V7 #2:

RE TRS 80 MODEL II Kermit hex file: I believe that file is to be used with
Pickles and Trout CPM release 2.2.  I don't believe there was ever a version
done for TRSDOS.  I got the source files about maybe 4 years ago to try and
do such a conversion, but the volume of assembly code was just too much to
try and convert (plus the code at the time was in 8080 and I was versed at
the time in Z80, hence that conversion had to be done first).  Anyway,
TRSDOS was undergoing a slow death at the time, and I just gave up on the
conversion.  If there ever was a TRSDOS version of kermit, I too would be
interested in hearing about it.

[Ed. - There is indeed a native TRSDOS version for the Model II.  It's in
KER:TR2KER.*, announced in Info-Kermit V6 #8, 26 March 1987.]

------------------------------

End of Info-Kermit Digest
*************************
-------
 4-Feb-88 16:45:51-EST,22354;000000000000
Mail-From: SY.CHRISTINE created at  4-Feb-88 16:44:46
Date: Thu 4 Feb 88 16:44:46-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #5
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 4 Feb 1988       Volume 7 : Number 5

Departments:

  ANNOUNCEMENTS -
        New Documentation for Old CIE-680 Kermit

  MS-DOS KERMIT -
        MS-Kermit Under OS/2
        Thanks for rollback help!
        The New Tek-Emulating Kermit and SAS
        HP-150 Terminal Program
        Kermit problems with Visual Commuter computer
        Kermit-MS 2.30 & Macintosh II

  MISCELLANY -
        CMS Kermit 4.0
        Problems with Apple Kermit.
        GNU Emacs with C64 Kermit
        First-Time Download of Kermit on Commodore-64 with Only Tape
        Kermit Sources Wanted for iRMX-86
        VME/10 Kermit?
        VT-52 Emulator for Osborn Exec
        One Character Checksum

----------------------------------------------------------------------

Date: Fri 29 Jan 88 17:26:53-EST
From: Frank da Cruz <[e-mail]>
Subject: New Documentation for Old CIE-680 Kermit
Keywords: CIE Kermit

Sent in by the author, David S. Lawyer, of Irvine, CA, plus a termcap
entry for it.  In KER:CIE680.HLP and .TRM.

------------------------------

Date: Thu, 28 Jan 88 13:53 MDT
From: Joe Doupnik <[e-mail]>
Subject: MS-Kermit Under OS/2
Keywords: MS-DOS Kermit, OS/2

[Ed. - A question we're getting a lot these days is "Will (or can) MS-Kermit
run under OS/2?"  As far as 2.30 (and earlier) are concerned, the answer is
"yes, but only in DOS compatibility mode", i.e. taking over the whole machine.
As to the possibility of turning it into a real OS/2 application, we have the
following from Joe Doupnik...]

A switch to OS/2 is possible, even in assembler, but a C version would make
this much easier.  In simple terms, OS/2 is not an interrupt-driven system but
a more conventional "call" type.  So all the Bios/Dos software interrupts get
repackaged to do calls to system functions, much like a C interface.  The tough
part concerns hardware interrupts where either the machine interrupt enable bit
needs toggling (STI/CLI), not permitted under OS/2 full mode, and/or the
physical hardware needs attention from the program.  Rumors and the Microsoft
Journal say that interrupt handler latency is very, very long on 286 machines
and communications programs should expect troubles.  And, naturally, OS/2 runs
only on AT's and above.

So, the short forms are: Yes, it runs now in the DOS box, but a full OS/2
version needs a substantial development effort.  The Presentation Manager specs
are still fluid but when stable will require a second pass at OS/2 Kermit to
adapt to window sizing things.

        Regards,
        Joe D.

[Ed. - Thanks, Joe.  If anybody else has any insight into the issues involved
in bringing Kermit to OS/2, please send a message to Info-Kermit!]

------------------------------

Date: Mon, 01 Feb 88 22:04:50 -0800
From: Alastair Milne <[e-mail]>
Subject: Thanks for rollback help!
Keywords: MS-DOS Kermit 2.30

    To James Coombs, Eric Boehm, Doug Brenner, RECK@DBNUAMA1, Gisbert Selke,
    and all the others who were kind enough to respond about accidentally
    hitting HOME:

    Thanks very much for the quick and thoughtful replies.  Though remapping
    the HOME key had never occurred to me, it is obviously the quickest and
    easiest thing to do.  I don't mind having the PAGE UP and PAGE DOWN, since
    those let you move back with some control; and I think the END is a good
    idea, to get you back where you actually are as quickly as possible.  But
    the HOME is just grief.

    It's marvellous what the net can do for you.  The amusing thing is that I
    have not yet seen the info-kermit digest in which my own message appeared,
    and would never have know that the editor included a reply in it if one of
    you hadn't forwarded the copy to me.

    Thanks again to all.
    Alastair Milne

[Ed. - Also, did you know that there's a kind of automatic END feature?  Try
SET TERMINAL ROLL ON.]

------------------------------

>>Date: Mon, 11 Jan 88 11:12:15 est
>>From: [e-mail]
>>Subject: Screen Scroll in MS-Windows
>>Keywords: MS-DOS Kermit, MS-WIndows
>>
>>I have had problems making Kermit scroll up/down screens under MS-Windows
>>when in a window*.
>>
>>Version 2.29b and 2.29c (21 DEC) have been tested with version 1.01 - 1.03
>>and 2.03 of MS-Windows.  You are only able scroll up one line.
>>
>>Both Version 2.29b and 2.29c will scroll properly in a window under
>>Windows/386.
>>
>>* In a window refers to setting up the PIF file so that Kermit does not
>>write directly to screen and does not "modify" a com port.
>>
>>    Stephen Northcutt ([e-mail])
>>
>>[Ed. - This is a restriction of the program, noted in the MSKERM.BWR
>>file.  However, you should still be able to scroll up by using the mouse on
>>the scroll bar.]

[ From jrd - MS Windows 1.x, 2.x operates the screen in graphics mode but
has trouble reporting back text written by a program to the shadow text
screen. Thus, manually scrolling a Kermit screen within a shared MS Windows
window reports total gibberish or worse to Kermit as it tries to save text
lines scrolling off the screen. It's really an MS Windows concern.  To
suppress this characteristic roll back is turned off when in MS Windows.  MS
Windows/386 is not available locally and I have no idea of how to test for
versions of Windows.  Those little white lies we tell in the .PIF file
(Kermit does not directly access the screen, does not use serial ports,
etc!) are to make Windows behave itself but not to control Kermit.  What you
see Kermit do in a shared window is accomplished by magic.]

------------------------------

Date: Tue, 12 Jan 88 22:22 N
From: Jnet%"STREB@YORKVM1" 12-JAN-1988 19:15
Via: <[e-mail]> (Eberhard W. Lisse)
Subject: The New Tek-Emulating Kermit and SAS
Keywords: MS-DOS Kermit 2.30, Terminal Emulation, TEK

The line that I have used in my SAS routines to start Tek mode and then
turn it off is:

GOPTIONS DEVICE=TEK4010,GEPILOG='18'X,GPROLOG='1B0C'X,GPROTOCOL=GSAS7171

That seems to work just fine....

Jim Streb
Micro Support
York University
Downsview, Ontario
Canada

[Ed. - Presumably, this is when SAS is running on a mainframe, and the user
has a full-screen connection through an IBM 7171 protocol converter.]

------------------------------

>>Date: Tue, 26 Jan 88 10:55:52 PST
>>From: David Mendel <[e-mail]>
>>Subject: Kermit 2.30 graphics
>>Keywords: MS-DOS Kermit 2.30A
>>
>>    This is a suggested improvement for msvibm.exe 2.30.  Please forward
>>to the correct person.
>>
>>    I am using msvibm.exe 2.30 on an ATT6300, and I have had the following
>>problem with the graphics mode.  Normally I use the graphics mode to build
>>interactive plots using S which puts the command line near the bottom of
>>the screen.  If I make one typo, it prints an error message, and puts the
>>cursor at the top of the screen.  The problem is that this clears the
>>picture that I have created.
>>
>>    What I would like is an option at the 'More >' prompt to move the
>>cursor to the top of the screen without clearing the screen in the
>>process.  Perhaps pressing n would move the cursor to the top of the
>>screen without clearing the screen, while pressing any other key would
>>clear the screen as it does now.
>>
>>    Several of us use kermit with S here at Stanford and we would find
>>this to be a big improvement.
>>
>>Thanks,
>>David Mendel

[From jrd - The temptation to convert a simple Tek terminal into a modern
one is to be resisted.  My suggestion is to educate 'S' to behave differently
when it knows that it owns the bottom line of a screen (Tek or regular
text).  How about using the top left corner for user text?  'S' appears to be
a Stanford program so sources are likely to be nearby.]

------------------------------

>>Date: Sun, 10 Jan 88 20:59:48 PST
>>From: Ya'[e-mail]
>>Subject: MSKERMIT ver 2.29C tektronix 4010 won't overlay ALPHA and VECTOR
>>Keywords: MS-DOS Kermit 2.29C
>>
>>Possible bug with MSKERMIT version 2.29C:
>>
>>I have been using MSKERMIT vers 2.29C and have encountered a bug (feature?)
>>in the Tektroniks 4010 emulation mode.  Specifically, alpha mode characters
>>will erase and NOT OVERLAY vector mode data.  This frequently causes plot
>>titles and labels to obliterate the graphed data.
>>
>>ps:     I have an IBM-PC/xt clone with the CGA adaptor.
>>
>>[Ed. - This seems to be the behavior on the CGA, but not the EGA...]

[From jrd - A complete 8 by 8 dot character cell is written for each
character, so that both foreground and background colors are maintained and
characters can be erased. Supression of the background is being considered
but may not be do-able and still maintain the above characteristics. If
annotation is done first then the problem does not occur. I'd like
overlaying too.]

------------------------------

Date: Thu, 17 Dec 87  15:19 PST
From: [e-mail] (Adlai)
Subject: HP-150 Terminal Program
Keywords: HP-150 Kermit

Hi we have about 20 HP 150's (Hewlett packard Micro computers).  We need to
use them as full screen terminals for CMS.  Can You Help Us???

We have a copy of mskermit ver 2.27 for the HP-150, it transfer files great.
But it does not work as a full screen terminal, has someone writen a
terminal emulator for the HP-150 ?  It would be a very big help to use to
get such a program. Any ideas, information or sujestions would be very much
appreciated.

Adlai Jordan
MESA
Mathematics Engineering Science Achievement

[Ed. - HP-150 Kermit doesn't do any terminal emulation at all, but simply
passes incoming characters to the screen.  This goes through the HP-2621
terminal firmware, so you can use HP-150 Kermit for full screen applications
with hosts that know how to drive an HP-2621 terminal.  This means you'd have
to modify your protocol converter (Series/1, 7171, or whatever it is) to know
about the HP-2621 control sequences.  But don't attempt to use HP-150 as a
terminal emulator at speeds above 4800 baud.  It just doesn't work.  Finally,
you might want to pick up the 2.30 version of HP-150 Kermit from KERMSRV
at CUVMA.  It's in MSTHP1 *.]

------------------------------

Date: Sat, 23 Jan 88 17:08:20 EST
From: Marshall D. Abrams <[e-mail]>
Subject: Kermit problems with Visual Commuter computer
Keywords: MS-DOS Kermit, Visual Commuter

I am having problems getting Kermit to work on a Visual Commuter portable
IBM compatible computer and would appreciate communicating with someone else
who has been successful with this particular brand.  I am not on the info-
kermit list, so please respond directly.

I have tried both the Kermit in VTERM and stand-alone Kermit Vers 2.28.  Both
work from my office computer, but neither from home on the Visual Commuter.
I don`t think it's the modem or phone line, because I also have an Atari at
home and the Kermit on the Atari works just fine when plugged into the
modem.

I did turn on debug mode.  It took about 6-8 tries to get a file name
accepted for transfer, but no data packets ever got through. It just timed
out.  I tried adjusting the parity; that didn't help either.

I'm open to suggestions and thank you for your consideration.

Sincerely,

 - Marshall D. Abrams, phone: [phone]
   The MITRE Corporation, 7525 Colshire Drive
   Mail Stop Z670, Mc Lean, VA   22102

[From jrd - Marshall. Sorry, but I have no information on the Visual
Commuter.  Is there anyone else who can help?]

------------------------------

Date: Wed, 03 Feb 88 22:00 EST
From: "Mark B. Johnson" <[e-mail]>
Subject: Kermit-MS 2.30 & Macintosh II
Keywords: MS-DOS Kermit 2.30 on Mac II, MacKermit

Just as a note, Kermit-MS V2.30 runs standard VT-102 emulation and file
transfer (in background under MultiFinder) just great using the AST286 board
in a Macintosh II.  The new Macintosh version is much faster of course, but
for those people who have to have MS-DOS software, it is quite useable.  I
will give the TEK emulation a try next.  Just thought someone out there
might be able to use this information...

Mark

------------------------------

Date: Thu, 1988 Jan 28   14:21 EST
From: (John F. Chandler)   [e-mail]
Subject: CMS Kermit 4.0
Keywords: CMS Kermit

Comments on comments about CMS Kermit 4.0 in recent Info-Kermit Digests...

> 2) This may be a local problem, but I get the following message on startup:
>
>    "Handshake is XON -- not needed"

This startup message is just a friendly reminder to heed paragraph 4 in
section 1.2 of the CMS Kermit User's Guide:

  CMS is different from some other IBM mainframe systems in that allows
  a program  to take control  of prompting  and synchronization  on TTY
  lines.  Kermit-CMS  takes advantage of this option, and it is not, in
  general, necessary  to enable handshaking  on the micro Kermit before
  connecting to CMS.  In other words, handshaking  should be suppressed
  for both  TTY and SERIES1  devices  (the  micro  Kermit  should  have
  HANDSHAKE  set OFF, and Kermit-CMS  should have HANDSHAKE  set to 0).
  Since the generic Kermit-370  default handshake  (XON) is retained in
  Kermit-CMS,  the subcommand  SET HANDSHAKE  0 is a good candidate for
  inclusion in SYSTEM KERMINI.

By the way, I noticed that you didn't "Ed." the comments from Brown in Digest
#3 about trying to set the SEND packet size -- surely, you don't feel that one
Kermit can even try to force another to accept Long Packets; that's what it
would mean if Kermit-CMS accepted the command SET SEND PACKET 1900.  Perhaps
the documentation should explicitly say that one can't do that.

[Ed. - Right...  that one slipped by.]

------------------------------

Date: Mon, 1 Feb 88 11:36 N
From: <[e-mail]>
Subject: Problems with Apple Kermit.
Kewyords: Apple II Kermit

I recently got a copy of version 3.79 of Apple II KERMIT.  I experienced
some problems under ProDOS to up/download text files since they are always
handled in 7 bit mode (setting unconditionally the high order bit when
receiving and stripping it off when sending) like under DOS 3.3. This is
incorrect since now the Apple IIgs uses this high order bit to extend the
ASCII character set in the same way as on the Macintosh.  Unfortunately I
have no source code to try to patch the code in order to enable a full 8 bit
text file transfer under ProDOS.  Can you help me?  Thanks in advance & best
regards.

                                Fabio Viviani
                                C.S.E.L.T. - Turin, Italy
                                ([e-mail])

[Ed. - This is certainly a trend.  Your message has been forwarded to the
current developer of Apple II Kermit, who's working on a new release.]

------------------------------

Date: Wed, 03 Feb 88 22:05:09 -0500
From: [e-mail] (Ray Moody)
Subject: GNU Emacs with C64 Kermit
Keywords: C64 Kermit

In Info-Kermit Digest Volume 7, Number 3 you write:
>While using GNU Emacs with C64 Kermit at 1200 baud, I noticed when scrolling
>UP ONLY, the screen would get garbled. (Probally overflowing the input
>buffer? I haven't notice this happening at 300 baud (300 baud?!? ARGH!))

    Yes, you are quite right.  Since the Commodore-64 has no built-in
80-column screen, I have to simulate 80-columns with bitmap graphics.
Scrolling a bitmap screen backwards is a non-trivial operation and takes a lot
of time.  If Kermit receives scroll-reverse requests too fast, it will overflow
its input buffer.

    Normally, when Kermit's input buffer is in danger of being overflowed,
Kermit will transmit a ^S to stop the remote host from sending.  The only
problem is that GNUemacs chooses to ignore this stop request.

    There are several ways to solve this problem:

    1) The best solution I can think of is to tell GNUemacs that you wish to
       use flow-control.  You can do this by putting (set-input-mode nil t)
       in your .emacs file.

    2) Ask GNUemacs to provide a delay after scrolling the screen backwards.
       You can do this by adding sr=<XXX>\EM to your terminal description,
       where <XXX> is the number of milliseconds of delay that you want.  I
       experimented a little and found that 200 milliseconds is "about" right.
       This isn't very elegant because it will slow GNUemacs down a lot.

    3) Use a Commodore-128 or wait for Kermit 2.1 to be released and use a
       Batteries-Included 80-column add on card.  If you use one of these,
       Kermit will not be forced to simulate an 80 column screen with graphics.

                   Ray Moody,    Author of Commodore Kermit version 2.0
                    [e-mail]
                    ihnp4!pur-ee!j.cc.purdue.edu!ray
                    [e-mail]

    Many thanks to Jay Vosburgh for providing the magic emacs incantations.

[Ed. - And thanks for passing along the hints.  They've also been added to
the Commodore-64 Kermit "beware" file.]

------------------------------

Date: 12 Jan 88 15:12 +0100
From: Alf Christophersen <[e-mail]>
Subject: First-Time Download of Kermit on Commodore-64 with Only Tape
Keywords: C64 Kermit

A friend of me want to get KERMIT on his Commodore 64 with CP/M, but he
has only a tape station.  How do we upload first time, e.g. from a
Olivetti M24 with direct connection over RS232?  I remember there was
a procedure when I loaded first time with our Altos 8000/7, but have
forgotten the procedure.  Does anyone have some idea?  Is there any tape?

Alf Christophersen
Engineer
Dep. of Nutrition Research
PO. Box 1046 BLindern
N-0316 Oslo 3
Norway

------------------------------

Date: Fri Jan 15 00:20:02 1988
From: peregrine!imt3b2!seila![e-mail]
Subject: Kermit Sources Wanted for iRMX-86
Keywords: iRMX Kermit

Anyone out there have working C or PLM sources for kermit under release 6+ of
iRMX-86 running on a 310 box?  Please email replies.  Thanks in advance!
According to info from Columbia U., someone at Grinnel College (?) has done
this...

Don Kossman, SEI Information Technology, Los Angeles
usenet: {ccicpg!imt3b2 | peregrine!imt3b2 | sun!tsunama!tsunami}!seila!don

[Ed. - There are two families of Kermit programs for (i)RMX(2)86.  One
consists of variations on a version written in PL/M, and the other is an
adaptation of MS-DOS Kermit by Jack Bryans at Calstate.  Does anyone know
of any reason why the former would still be necessary in the presence of
the latter?  And if there is any reason for keeping a PL/M version, which
of the three that we have should be kept?  Below is a list...]

IRM C  Intel 86/380     iRMX-86    PL/M         2.41  87/03/04  Grinnell Col.
I86 C  Intel 86/380     iRMX-86    PL/M         2.3   85/09/23  Grinnell Col.
RMX C  Intel 86,286     RMX 1.0    PL/M         1.0   85/10/25  Cornell U
MS  A  Intel 300 Series iRMX-86    MASM/ASM86   2.29Z 88/01/07  Cal State
MS  A  Intel 300 Series iRMX-286   MASM/ASM86   2.29Z 88/01/07  Cal State

------------------------------

Date: Thu, 31 Dec 87 07:57:23 CST
From: [e-mail] (rod merry)
Subject: VME/10 Kermit?
Keywords: VME Kermit

Does anyone know where I can get a binary copy of Kermit for the Motorola
VME/10 running VERSADOS.  I will supply or pay for the diskettes.

Thanks,

Rod Merry                               [e-mail]
Computer Network Technology             {quest|meccts}!cnt!rod
9440 Science Center Drive
Minneapolis, MN 55428                        [phone]

[Ed. - Try Wm. Pierce, Motorola Semiconductor, 3102 N. 56th St, MS/56-122
Phoenix, AZ 85108.  We have had reports that this person has, and distributes,
a VME/10 VERSADOS Kermit, but we have never received it.  We'd like to carry
a VERSADOS Kermit in our distribution, and would like an "official" source
to refer people to who need it on diskette.  If anybody finds out the status
of this purported Kermit version, please let us know.]

------------------------------

Date: 29 Jan 1988 06:18-CST
From:  John A. Wright <[e-mail]>
Subject: VT-52 Emulator for Osborn Exec

Does anyone know of a Kermit program with a VT-52 emulator for the Osborne
Executive.  If one does not exist, does anyone know of a VT-52 emulator for
the same?

------------------------------

Date: 20 Jan 88 00:37:50 GMT
From: [e-mail] (John McDaid)
Subject: One Character Checksum
Keywords: Checksum

Can anyone give me a short, CLEAR explanation on how a one character checksum
is derived in Unix Kermit?  Mail me directly with the answer.  I thank anyone
who gives this any effort.

John McDaid
[e-mail]

[Ed. - Add up the 8-bit values of all the bytes from the length field to the
last data byte.  Truncate the sum to 8 bits.  Call this S.  Then:

X = S & 63;         /* Low order 6 bits */
Y = S & 192 >> 6;   /* High order 2 bits, shifted to right */
C = (X + Y) & 63;   /* Add them together, keep low 6 bits of result */
CHKSUM = C + 32;    /* Make it printable */

More concisely (as it is actually done in C-Kermit):

CHKSUM = tochar((s + ((s & 192)/64)) & 63);

This was originally designed, back in the days of 8-bit processors, to work
on machines that could only do 8-bit arithmetic.  The idea was to have all
the bits of an 8-bit sum contribute to a printable ASCII single-character
checksum.]

------------------------------

End of Info-Kermit Digest
*************************
-------
17-Feb-88 12:08:08-EST,25795;000000000000
Mail-From: SY.CHRISTINE created at 17-Feb-88 12:07:11
Date: Wed 17 Feb 88 12:07:10-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #6
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 17 Feb 1988       Volume 7 : Number 6

Departments:

    MS-DOS KERMIT -
        MS-Kermit for the GRiD Compass (Six Messages)
        MS-Kermit Tektronix 4010 Graphics Emulation
        Problem Setting Num Lock and Scroll Lock Keys in MS-Kermit
        Kermit 2.30 for HZ100?

    C-KERMIT -
        Bug Report for C-Kermit 4E(070) on Unix PC (3b1)
        Re: Unix Kermit Idle Line Problem
        C-Kermit 4E(070) vs System V R3 vs 3B2
        C-Kermit for Xenix 286?

    MISCELLANY -
        Using TOPS-20 Kermit with 9-Bit Files
        Need Kermit for Microbee?

----------------------------------------------------------------------

Date: 28 Oct 87 20:54:41 GMT
From: [e-mail] (Owen Adair)
Subject: MS-Kermit for the GRiD Compass
Keywords: MS-DOS Kermit 2.29C, GRiD Compass

I am using kermit for the GRiD. I have difficulty using the BREAK function
while online. It seems to reset the serial port or something. Is there
anyone else out there using MSKermit with the GRiD?

Owen Adair, WD4FSU
Digital Signal Processing Lab, Georgia Tech, Atlanta GA 30332
Internet:       [e-mail]
uucp:  ...!{decvax,hplabs,ihnp4,linus,rutgers,seismo}!gatech!gt-eedsp!owen

[From jrd - Right, we need a Grid guru. Any volunteers?]

[Ed. - See messages below....]

------------------------------

Date: Sun, 31 Jan 88 18:14:14 EST
From: David Kirschbaum <[e-mail]>
Subject: Re Grids and Kermit
Keywords: GRiD Kermit

NetLandians,

I keep hearing pleas from Grid users to make Kermit work with the Grids.
I'd be more than glad to give a hack to it (got source for v2.30, much
experience with assembler, comm ports, etc.).  However .. I do NOT have any
details on the stupid serial ports, interrupts, chips, etc. for the Grid
running under MS-DOS.

I tried long ago to get such information, or little smidgens of source code
for Grid's stupid comm program, but discovered I was suspected of trying to
steal the Crown Jewels .. and left Grid to their own just deserts.  If
someone has ANY technical information on exactly what it takes to tweak a
Grid's serial port(s), and can pass that info to me (ANY language!  Just so
it isn't buried in 80Kb of some pirated comm program's binary object file.)
.. will be glad to give it a hack.  Of course I don't HAVE a Grid, so
couldn't test it .. but could send the .ASM source (fully documented) to a
willing volunteer (who had MASM) to assemble and test.

Mail directly to me .. no use inflicting Info-Kermit with this.

David Kirschbaum
Toad Hall
[e-mail]

[Ed. - Thanks for the offer David.  Anyone with a GRiD willing to help?
But first, see following messages.]

------------------------------

Date: Mon, 1 Feb 88 13:55 EST
From: RLH <[e-mail]>
Subject: MS Kermit 2.30 on GRID
Keywords: GRiD Kermit

In Vol. 7, No. 4, Owen Adair wrote about not being able to run MS Kermit v
2.30 on a Grid model 1101. I am not familiar with the model 1101, but do
have v 2.30 running on a Grid GRIDCASE 2 PLUS.

I used a copy of the executable that I had put together for a standard
IBM-PC and it worked without changes. I never even tried the Grid specific
code. I have not exercised all Kermit features but I have done considerable
file transfer between the Grid and VAX/VMS as well as with true IBM-PC's -
no problems. Also, the VT102 terminal emulation works great with DEC
software such as TPU, EDT, and LSE.

Version 2.30 is a great package. Thanks to everyone who helped put it
together.

                Bob Haar        ( [e-mail] )
                G.M. Research Labs

------------------------------

Date: Wed, 3 Feb 88 10:48:54 EST
From: sundc!hadron![e-mail] (Kurt L. Reisler)
Subject: Re: MS-KERMIT 2.30 for the GRiD
Keywords: MS-DOS Kermit 2.30, GRiD Kermit

>
> Does this mean that you have tested the GRiD version and found it to work?
> I've had reports from other people that it didn't work.  If it does, could
> you send a brief synopsis of your exact system model, OS version number,
> configuration, etc, so that we can pin down what the problem might be, if
> any?  Thanks!  - Frank
> -------
>

Well, I have not tested it extensively, but I have tried it on a 1129, and a
friend has tried it on an 1101.  You need to set port 2 to access the
internal modem.  Then, in uppercase (shift escape to lock) you need to do a
ATZE1 to see your commmands echod.  Problems include the fact that it
appears to run only at 300 baud, and there is an EXTREME amount of internal
buffering going on, until you escape back to the kermit command level.  Then
the buffering seems to go away (?).  I have successfully transfered a file
(at 300 baud GAK!).  I hope to have more time this weekend to play with it
further.  Let me see what version of MSDOS it is running. MSDOS 2-11 Bios
version C

Help that this helps. and I will keep you posted.

(later...)

What a wonderous thing documentation is.  It causes the gloom to lift
like the rising of the sun :-)

Adding the following to the autoexec.bat file on the MSDOS side of the
GRiD will cause the modem port (comm2) to default to 1200 baud:

echo baud=1200 > com2stat

Once in KERMIT, use the SET PORT 2 command to access the modem, and it
will only take upper case commands.  Will be testing it more extensively
over the weekend.

 Kurt Reisler [phone]

 UNISIG Chairman, DECUS US Chapter                       | Hadron, Inc.
 ..{uunet|sundc|rlgvax|netxcom|decuac}!hadron!klr        | 9990 Lee Highway
 Sysop, Fido 109/74  The Bear's Den   [phone]     | Suite 481
 Sysop, Fido 109/483 The Pot of Gold  [phone]     | Fairfax, VA 22030


------------------------------

Date: Fri, 5 Feb 88 23:47:35 EST
From: sundc!hadron![e-mail] (Kurt L. Reisler)
Subject: Re: MS-KERMIT 2.30 for the GRid
Keywords: MS-DOS Kermit 2.30, GRiD Kermit

As promised, more information, and ALL of it is posative.  I have a working
copy of "GRiD Compass II Version A MS Kermit V2.30" dated 8 January 1988.  I
got it off of Columbia via anonymous ftp, in the normal boo format.  Used
the utilited from Columbia to convert the boo file to a .EXE file on my 4.2
BSD system, transferred it to my Fido BBS (on a DEC Rainbow) then using
MediaMaster, to a SSSD IBM diskette, to the GRiD.

I have used it sussessfully (am using it at the moment) on a GRiD 1101 and
GRiD 1129.  In both cases, the systems are configured with a GRiD 2101 Hard
disk subsystem.  The GRiDS are setup for GRiDOS, with the MSDOS (2.11-C)
running on a partition of the hard disk.  I also figured out how to get it
to run at 1200 baud (RTFD :-).

Anyway, in the AUTOEXEC.BAT file on the MSDOS partition, I have the
following:

        ECHO BAUD=1200 > COM2STAT
        ECHO V=250 > COM2STAT

To set the baud rate and volume on the modem.  In the MSKERMIT.INI file,
I have the following:

        SET PORT 2
        SET BAUD 1200
        STAT

Once I Connect to the modem, I issue the following command to the modem:

        ATE1Q0V1

So that I can see what I am doing with the standard Hayes modem
commands.

So far, it seems to work fine.  Have been able to upload and download
files between the GRiD and my FIDO systems without problems.

Anyway, hope this has been helpful.  If you think it would be useful, I
can uuencode the copy I have and post it to the net.  In addition, it is
available for download from either of my fido nodes, listed in the
.signature below.

 Kurt Reisler [phone]

 UNISIG Chairman, DECUS US Chapter                       | Hadron, Inc.
 ..{uunet|sundc|rlgvax|netxcom|decuac}!hadron!klr        | 9990 Lee Highway
 Sysop, Fido 109/74  The Bear's Den   [phone]     | Suite 481
 Sysop, Fido 109/483 The Pot of Gold  [phone]     | Fairfax, VA 22030

------------------------------

Date: 10 Feb 88 14:07 PST
From: [e-mail]
Subject: Re: Kermit 2.30 for GRiD
Keywords: MS-DOS Kermit, GRiD Kermit

;;;     I downloaded 2.30 Kermit for the GRiD (.BOO format) and it
;;;     tries to run, but all I get is garbage then it crashes. Has anyone
;;;     else tested the beast on a GRiD model 1101? I currently use 2.29
;;;     and it works although not all the features function.


Last night I brought MSTGRI 2.30 up on my Grid and it worked well, except
for baud rate change (I couldn't get 300 baud to work). I called a couple of
systems and performed successful uploads and downloads of ASCII files (I
haven't tried binaries yet).

My system is a Grid Compass-II 1121, which is like the 1101 except that it has
ROM sockets. I was using ROM-based MS-DOS 2.11. I did have to explicitly SET
PORT 2 from inside Kermit. My modem driver is Grid's MODEM.SYS. I dialed out by
typing C, then ATTD 123-4567.

[Ed. - So it seems that the GRiD version of 2.30 sort of works on the GRiD
Compass, which is not IBM Compatible, and that the IBM PC version works on
the GRIDCASE 2 PLUS, which is IBM compatible.  So we have a semisolid base to
work from, in case anyone who is a GRiD expert wants to make improvements.
Volunteers should contact Info-Kermit@CU20B.  Meanwhile, these messages have
been added to the "beware file" for the GRiD, MSVGRI.BWR.]

------------------------------

Date: 12 Feb 88 13:55:26 GMT
From: ecsvax.uucp![e-mail] (Robert T. Herbst)
Subject: MS-Kermit Tektronix 4010 Graphics Emulation
Keywords: MS-DOS Kermit 2.30

I have recently installed kerm230 on a pc6300 and a pc6300plus.  Not only is
kerm230 excellent for communications, it also has super terminal emulators.
The vt102 permits keypad editing on VAX/VMS. Better yet the TEK 4010
emulator allows interaction with gnuplot. Now we have the best of several
worlds.

                        R. T. Herbst
                        herbst@ecsvax

------------------------------

Date: Fri, 12 Feb 88 10:51:09 PST
From: "Eric Yen  714-856-5244" <[e-mail]>
Subject: Problem Setting Num Lock and Scroll Lock Keys in MS-Kermit
Keywords: MS-DOS Kermit 2.30, Num Lock, Scroll Lock

Is it possible to use the MSKERMIT "Set Key" command to have the IBM PC
NumLock and ScrollLock keys generate escape sequences?  My attempt to do
so failed.

Eric Yen
Systems Programmer

[Ed. - Unfortunately, it is not possible because the IBM Bios does not return
scan codes when these keys are pressed.]

------------------------------

Date: Fri 12 Feb 88 15:00:17-PST
From: Mike Dante <[e-mail]>
Subject: Kermit 2.30 for HZ100?
Keywords: Heath/Zenith 100

I note in your Version hlp file that there exists a Kermit Version 2.3 for
the Zenith HZ100. (Or am I not understanding the file?)  But I could not find
a new version under KER:MSVZ10.*.  I tried the generic MS_DOS version on my
Z100 but I could not set the baud rate.  I kept getting the message "Command
not implemented."  Am I having a problem decrypting the .BOO file?  Is there
a KERMIT V2.30 available for the HZ100?

Thanks,

Mike

[Ed. - Generic MS-Kermit doesn't know how to set the baud rate, because it
knows nothing about the PC's specific hardware.  You should be able to set
the baud rate outside of Kermit using some kind of system utility (like MODE
on the IBM PC), and then Kermit should use the port as you've set it up.  The
latest test version of Kermit for the Heath/Zenith 100 is in KER:MSTZ10.BOO
on CU20B, dated January 19, 1988.  H/Z-100 users are encouraged to test it
and report the results, and if there are problems, to apply or suggest
fixes.]

------------------------------

Date: Fri, 12 Feb 88 12:34:08 EST
From: David Herron E-Mail Hack <[e-mail]>
Subject: Bug Report for C-Kermit 4E(070) on Unix PC (3b1)
Keywords: C-Kermit 4E(070)

I've gotten a copy of C-Kermit and am trying it out on various machines.
Mainly my Unix-PC since it's advertised to support the UnixPC.

First off, it wouldn't even compile right.  In ckudai.c there is a "static
MDMINF ATT7300" which simply CANNOT be right.  The problem is that you're also
using "ATT7300" as the pre-processor symbol to select UnixPC features, and it
has a null value, and the statement ends up looking like:
"struct mdminf = { ... };" which is a syntax error.

My workaround for the moment is to make all references to that symbol to be
"att7300" and make sure it's "static".  The preprocessor on UnixPC's is of the
style that doesn't allow:

        #define ATT7300 ATT7300

because it complains about macro recursion.  (Oh, BTW, I'm running SYSV r3.51,
the latest version for Unix PC's).

Next, the makefile stuff for supporting the shared libraries is wrong.  When
doing an ld to use the shared libraries, at least on Unix PC's, you pretty
much have to use ld directly like:

        ld {some options} /lib/shlib.ifile {object files}
                {more options} /lib/shlib

I may be off in a detail or two, but the point is that the way it was written
in the makefile was very wrong, as evidenced by all the multiply defined
symbols.  Further, if I undo the stuff for the shared libraries I get
"tgetent" and a couple of other termcap functions as being undefined.  And I
can't find those functions in any of the libraries on the system.  What I
ended up doing was using a "cc" front end which handles loading the shared
libraries properly and has support for programs which use curses.  It was
posted recently in unix-pc.sources and I could forward it to y'all if you
want.  (It's the one named "ccc", there's at least one other of these
scripts).

Using "ccc" I got it pretty close, but there's a routine in /lib/shlib named
"openi" and there was a conflict between it and the one y'all had in ckcfns.c
-- the workaround here is to declare YOUR openi() to be static (which works
because it's not used in any other of your files), and don't forget to put a
"static openi();" at the beginning of the file as well.  There's even a
section reserved up there for local variables.

Now I've got a program that compiles and loads without errors.  In testing
some functionality:

I started with the remote kermit in server mode and transferred /bin/cat to
the remote (a 4.3bsd vax running kermit 4C(057)) and then got it back ("get
cat").  The result is a cat that is one byte shorter, but is otherwise exactly
the same.  Now, this is a real neat trick too, 'cause it starts and ends with
the EXACT same bytes (I looked using od)!  This shouldn't work out like this.
The new copy should be missing a byte at the end, but we've got the same byte
at the end.  There isn't a byte missing in the middle 'cause "cmp" doesn't
find it, and if I "diff" the "od -c" output from each file, the ONLY
difference is the byte count at the very end.

I'm more than a little confused about that one ...

While the remote is in server, the local kermit acts rather strangely.
Possibly when doing ANY command, but definitely when doing send, get, and "!"
commands, to get back to command level from the command I have to type ^R ...
the only other character I've tried is <CR> which didn't get me back to
command level.  Further, I once hit an empty line then started to do a shell
escape and it dumped me OUT of kermit and said something about an invalid
shell command.  (an asice: There's times when I hate command processors which
read what I'm typing and complain before I get a chance to fix typing errors
...)

FINALLY:

In order to successfully connect to the modem and make a phone call I have to
enter this non-intuitive sequence of commands:

        ! rm /usr/spool/uucp/LCK..ph0
        set line /dev/ph0
        set modem att7300
        set speed 1200
        dial <phone number>
        ! phtoggle
        dial <phone number>

If I don't remove the lock file first, the set line command of course will
complain about the lock file being there.  But if I go ahead and phtoggle then
set line, the open in set line never returns and I hang.  Then, there's some
other state where if I phtoggle the getty process that get started starts
looping -- that is, getty exits immediately causing init to start a new one
which exits immediately, and so on.  Anyway -- I haven't tried it without a
dial command before the phtoggle yet.

I've got a kermit around here which'll let you do:

        ! phtoggle
        set line /dev/ph0
        set modem att7300
        set speed 1200
        dial <phone number>

just like you'd expect ... but it's an old copy that someone here made work
and then never told you guys about the changes.  (ARGH!)  Anyway, between the
two versions I should be able to get something working.

Oh, another problem when I exitted kermit ...  I said "quit" and it waited a
little while and said "Problem with hanging up modem".

[Ed. - Unfortunately, we don't have any Unix PCs, or for that matter any
System III or V systems to test C-Kermit on, so we rely on people like
you to tell us what to do, or what we should have done.  You're apparently
the first person who tried the new ATT7300 stuff, so thanks for the feedback
on that.  But I haven't heard complaints from others about multiply defined
symbols, shared libraries, etc, and a lot of people are running this version
on System V, so I can only assume the problem there must be UnixPC-specific.

If you can send me a makefile entry that you have actually used with the
UnixPC, I'll be glad to replace the current one with yours, and add a hint
that if people have trouble w/other ATT Sys III/V based systems, they might
look at the ATT7300 entry for a model.  If this is new stuff, then we have
a slight problem, because up till now (or at least up to Sys V R3), all
Sys III and Sys V C-Kermits could be compiled the same way.

Termcap???  There's nothing in Kermit that uses termcap or curses...
The other stuff will have to be looked in to.  Thanks for the report.  For
now, it's been added to the "beware file", CKUKER.BWR.]

------------------------------

Date: Wed, 10 Feb 88 22:29:13 EST
From: rochester!ames!ucbcad!ucbvax.Berkeley.EDU!-
  ucbcad!ames.uux!pur-ee!iuvax!bsu-cs![e-mail] (Rahul Dhesi)
Subject: Re: Unix Kermit Idle Line Problem
Keywords: C-Kermit, Unix Kermit

Re: Info-Kermit Digest V7 #3

This is an answer to a query from [e-mail] (Michael Galassi)
dated 28 Dec 87 00:42:59 GMT, in which he said that users using
"C-Kermit, 4C(057) 31 Jul 85, 4.2 BSD" are timed out for being idle
even though they are doing Kermit file transfers.  Here is my
work-around as it was posted in a local newsgroup.

"By popular demand, here again is the technique for avoiding inactivity
timeouts when doing a long file transfer via Kermit.

Step 1.   At the system prompt, give the command "tty".  This command
will print your terminal name.  It will be of the form /dev/tty15
where instead of 15 you will see the number of your terminal.
Remember it.

Step 2.  Invoke Kermit interactively with the command "kermit" given
without parameters.  (Actually you can give parameters too, so long
as they don't cause Kermit to begin data transfer immediately.)
When Kermit starts up and prints the prompt "C-Kermit", you go to:

Step 3.   To Kermit, give the command "set line /dev/tty15".  In place
of the 15, use whatever terminal number you obtained in Step 1.

Step 4.  Now give Kermit the commands necessary to begin your file
transfer.   You will not get an inactivity timeout.

Users who want to win fame on this system and the gratitude of others
can change Kermit so that the above sequence will not be necessary.
Currently Kermit uses the standard device /dev/tty which is synonymous
with your actual terminal.  However, the operating system treats it
like a distinct device from your actual terminal.  So, even though a
file transfer is going on using /dev/tty, the actual terminal, say
/dev/tty15, seems to be idle to the system, so you can get logged out.
This can be fixed by (a) finding the place where Kermit opens /dev/tty
and (b) replacing that with an open of the actual terminal name, which
can be obtained from the system call ttyname()."

Rahul Dhesi         UUCP:  {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi

[Ed. - We'll consider this for the next release.  Meanwhile, this message
has been added to the C-Kermit "beware file", CKUKER.BWR.]

------------------------------

Date: 10 Feb 88 23:09:57 EST (Wed)
From: ames!netsys![e-mail] (Len Rose)
Subject: C-Kermit 4E(070) vs System V R3 vs 3B2
Keywords: C-Kermit 4E(070)

One little note to people setting up this on an ATT 3B2 running under
SYSVR3...  They have two options in the makefile that sort of clash when you
are bringing up this software.. You either have to choose:

make att3bx or make sys5r3

If you don't choose att3bx,the code does not look for the LCK..ttyxx in
/usr/spool/locks ... However if you choose att3bx,it does not handle signals
correctly...  All I did to defeat this was just put a #define in ckutio.c for
att3bx...

Just thought I'd pass this on, no big deal with it...

Len

[Ed. - Sigh, lock files again.  There must be some better approach.  Are
there any Unix experts out there who can suggest a better way to deal with
this problem, than requiring Kermit itself know the directory name, the
filename, the permissions, and the contents of the lock file on every version
of every Unix variant?  Perhaps a separate program that runs Kermit in a
lower fork, or a program that Kermit runs in a lower fork.  Of course,
separate programs have a way of getting lost...]

------------------------------

Date: 12 Feb 88 00:38:41 GMT
From: hplabs!sun!texsun!liberty!swatsun![e-mail] (Eiji "A.G." Hirai)
Subject: C-Kermit for Xenix 286?
Keywords: C-kermit

This is a request for help in getting kermit working BUT wait ! - don't
ignore us, please!  Where would this network be if nobody helped each other
with other's problems some of the time?  I usually give help when I can with
a question on the net...  Anyway, here's our problem:

If anyone has had experience with getting C-Kermit 4C to work on Xenix 286
systems, could you divulge to us what you did to get it to work?  We can
compile but cannot work C-Kermit to work on our Sperry's and Intel 286/310.
We would bery bery much like to talk to you!

        Thanks everyone.

                                                -a.g. hirai
                                                a sysadmin for swatsun.uucp

Eiji "A.G." Hirai @ Swarthmore College, Swarthmore PA 19081 | Tel. [phone]
UUCP:   {rutgers, ihnp4, cbosgd}!bpa!swatsun!hirai |  "All Cretans are liars."
Bitnet:       vu-vlsi!swatsun![e-mail] |         -Epimenides
Internet:            bpa!swatsun![e-mail] |         of Cnossus, Crete

[Ed. - The current version, 4E(070), allegedly works OK on Xenix 286, and
there's even a special makefile option for it, "make xenix" (for Microsoft)
or "make sco286" (for SCO Xenix 286).  But that doesn't mean there will be
no problems.  There is tremendous variation among the C compilers, runtime
libraries, etc, among the endless number of products (and versions thereof)
that call themselves Xenix.]

------------------------------

Date: Wed 3 Feb 88 18:35:32-PST
From: Bruce Tanner <[e-mail]>
Subject: Using TOPS-20 Kermit with 9-Bit Files
Keywords: TOPS-20 Kermit, DEC-20

I've gotten the MS-DOS 2.30 .BOO files and decided to use the MSBPCT.C
program using the Stanford KCC compiler.  The program ran fine unchanged.
However, opening a file "wb" generates a 9-bit file (four nine-bit bytes per
word).  OK, just use the "SET FILE SIZE AUTO" and let Kermit figure it out,
right?  Wrong.  I had to teach it about 9 bit files also.  So, here are the
REDIT changes I've made to edit 262 (decimal 178):

1. Recognize 9 bit files
2. Clean up the Moon: code (it kept giving me phase errors)
3. Make edit decimal (just remove the vi%dec at Version: if you don't like it)

[Ed. - Thanks!  Code omitted, copied to KER:K20MIT.BWR for now.]

------------------------------

Date: Mon 15 Feb 1988 19:06:16 CST
From: Mark S. Zinzow <[e-mail]>
Subject: Need Kermit for Microbee?
Keywords: Microbee Kermit

I have a request from a user on our campus for a copy of kermit for the
following system purchased in Sweden and made in Australia.  Is a native
media version available, or does anyone know if this machine can be coerced
to read any PC formatted disk?  I just thought I'd check before trying to
bootstrap the generic CPM version.

Hardware:
Micro Bee Model II C. 1982
128 k
Expansion unit SBCO1

Software:
Telcom 2.0
CMP 80 C. 1984 copy may 3, 1985

[Ed. - We don't have any record of a Micro Bee in our list of existing
Kermits, or list of Kermits in progress.  Like most CP/M systems, it can
probably use one of the existing CP/M Kermits with a few minor adjustments
to port addresses, etc.  Has anyone had any experience with a Micro Bee
computer?]

------------------------------

End of Info-Kermit Digest
*************************
-------
 1-Mar-88 17:07:23-EST,24193;000000000000
Mail-From: SY.CHRISTINE created at  1-Mar-88 17:06:27
Date: Tue 1 Mar 88 17:06:27-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #7
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 1 Mar 1988       Volume 7 : Number 7

Departments:

  ANNOUNCEMENTS -
        Recent FTP (and general TCP/IP) problems with CU20B
        New BOOing and UnBOOing Programs, and German Kermit Documentation
        Keasy - "Easy Kermit" documentation in TeX
        Kermit-CMS Updates

  MS-DOS KERMIT -
        Minor problems in Kermit-MS V2.30
        MSKermit on Zenith eaZy-PC Serial (Mouse) Port
        Kermit & OS/2
        Int 14h, Kermit and Networks
        MS-Kermit Tek 4010 Emulation Typeover -vs- Overlay
        IBM PC MS-Kermit vs Datatronics Internal Modem
        MS-DOS Kermit Using EGA 43 Line Mode
        Toshiba T3100 versus MS-Kermit Tek Emulation

  MISCELLANY -
        C-Kermit on sys-V Based PCs
        Using TOPS-20 Kermit with 9-Bit Files
        Re Mark Zinzow's request for MicroBee Kermit

----------------------------------------------------------------------

Date: Mon 29 Feb 88 18:13:55-EST
From: Ken Rossman <[e-mail]>
Subject: Recent FTP (and general TCP/IP) problems with CU20B
Keywords: FTP

Recently, there has been an increasing frequency in the number of problems
experienced with FTP file transfers from the Kermit directories on CU20B.
While I am not sure of all of the different possible causes for this recent
set of problems, I do know that we have sorely needed some IP fixes in the
TOPS-20 monitor on CU20B.

Well, the fixes are finally installed!

I'm hoping that the IP free space fixes we've recently installed here will
help FTP performance to/from CU20B.  I'd be interested in hearing from some
of the sites out there who were so recently having FTP performance problems
to CU20B.  Do things appear to be working better now?

/Ken

------------------------------

Date: 12 February 1988, 16:21:39 SET
From: Gisbert W. Selke <[e-mail]>
Subject: New BOOing and UnBOOing Programs, and German Kermit Documentation
Keywords: .BOO Files, German

I have converted MSB*.PAS to Turbo Pascal 4.0, and sent them as MSBMKB.PAS
(which makes .BOO files) and MSBPCT.PAS (which decodes them).

I've also sent updated copies of the corresponding Fortran versions,
MSB*.FOR.  I have removed some more system dependencies which I hadn't even
been aware of before (thanks to Stefan Kaufmann for pointing them out), and
also fixed a minor bug in MSBMKB.FOR due to which garbage was added at the end
of a BOO file.

And I have also sent a new, corrected German translation of the MSKERM.HLP
file, under the name MSKGER.HLP.

I just noticed that there is no 63 second restriction on MS-Kermit 2.30's SET
INPUT DEFAULT-TIMEOUT and the like, as I seem to recall there used to be.
That's great, since our host is sometimes *quite* sluggish!

\Gisbert

[Ed. - Thanks Gisbert!  Your contributions have all been installed with the
MS-DOS Kermit distribution.]

------------------------------

Date: Mon, 8 Feb 88 16:53 N
From: Barbara Rosi <[e-mail]>
Subject: Keasy - "Easy Kermit" documentation in TeX
Keywords: TeX, LaTeX

Thank you very much for giving us Kermit, it has been a valuable resource and a
pleasure to participate in the community.  Enclosed is a translation of part of
the Kermit User Guide from Scribe into LaTeX.  Thank you very much for your
interest.

[Ed. - Thank you!  It has been put into KER:KEASY.TEX.]

------------------------------

Date: Mon, 1988 Feb 29   18:34 EST
From: (John F. Chandler)   [e-mail]
Subject: Kermit-CMS Updates
Keywords: CMS Kermit 4.0

I have forwarded new versions of IKCKER.BWR and IKCKER.UPD covering
all bug reports and complaints to date about release 4.0 of Kermit-CMS.
The updates are largely, but not entirely, to the generic part of the
code, and some have no effect on CMS operation (they were needed for
the TSO version coming out soon).  Only three of the updates touch on
problems that had no simple workarounds in the original release:

 a. Files of RECFM V being downloaded are no longer trimmed of the
    trailing blanks on TEXT transfers,
 b. the user may now explicitly upload a file to a specific filemode
    (and filemode number) through a Kermit-CMS server, and
 c. there is no longer a garbage message when WARNING is ON and the
    automatic renaming facility runs out of names to try.

The details can be found in IKCKER.BWR for the other changes.

                                     John

[Ed. - Thanks John!]

------------------------------

Date: Fri, 5 Feb 88 09:05 EST
From: Pete Kanaitis <[e-mail]>
Subject: Minor problems in Kermit-MS V2.30
Keywords: MS-DOS Kermit 2.30

I wanted to point out two minor problems with KERMIT-MS 2.30.

     The first is about using flow of control.  With flow of control
enabled, (which it is by default), some programs on your DEC hosts that use
^S and ^Q as special characters, rather than XOFF/XON, (such as EMACS) will
get an extra ^S or ^Q sent into the input buffer.  In the case of EMACS, a
^S or ^Q gets sent into the editing buffer.  Depending on your baud rate, I
have noticed that ^Q gets sent into the input buffer at faster baud rates,
(9600), and ^S gets sent at slower baud rates (1200).

This problem did not exist in the 2.29b versions.  I noticed that this
started to occur when the Tektronix code was added to Kermit in the later
2.29c versions.  It was mentioned to me that the serial port handling was
changed when the Tektronix code was added.

A work around for this problem is to set flow of control to none.  But by
doing this, I have found that some of my host characters get garbled at 9600
baud, when long lists go scrolling by on my screen.

[Ed. - The real, though painful, workaround is to SET FLOW NONE before you
start EMACS, and SET FLOW XON/XOFF when you exit EMACS, see below.]

I would like to suggest that this be mentioned in the beware file, unless
that there is some solution for this problem.

The second problem is about starting up Kermit in Tektronix mode on a port
connected to a modem (in my case, a Hayes 1200 external).

First starting Kermit by:
C>KERMIT
IBM-PC Kermit-MS: V2.30  8 Jan 1988
Type ? for help

Kermit-MS>set term tek
Kermit-MS>c

Now try to type a few "AT" commands to the modem.  You may find that you may
have to hit Control-Break once to get the "AT" to work.  Even before that,
you are unable to use Alt-Minus to switch terminal types.

If you already have a host connected to the port, you will not experience
this problem.  If you start up on a modem port (with no connection
established) in VT102 mode, hit Alt-Minus a few times to get into Tektronix
mode, the same problem occurs.  You cannot type "AT" until you hit the
Control-Break once.  Even after that, toggling back to VT102, then back to
Tektronix, and typing "AT" sometimes causes a bell to sound.  (This is *NOT*
the keyboard lock high-pitched bell).

If you have an external modem, you can make this observation.  Once
connected, look at the Transmit and Receive lights on your modem when you
switch into Tektronix mode by pressing Alt-Minus.  You will see the Transmit
light flicker every time you enter Tektronix mode.  I am guessing that this
is where the serial port handling is different.  Is the serial port being
reinitialized at this time?  Maybe this is why I cannot type the "AT" from
Tektronix mode.

I have tested these problems with my modem with both DTR turned on and off.
There was no other resident software on my PC at this time.

Thank you for your time.

Peter Kanaitis
Research Systems Analyst
Allegheny-Singer Research Institute
Pittsburgh, PA 15212
[phone]

[e-mail]

[From JRD -- Pete. Once again, thanks for the extended comments.  Emacs and
flow control: what can I say? If Kermit is permitted to do flow control and
Emacs responds to xon/xoff as commands then one must turn off flow control,
or else move the Search and Quote EMACS commands to to some other keys
besides Ctrl-S and Ctrl-Q.

Speed: the speed/baud rate/code sequences are the same for XON and XOFF so I
don't quite understand your observations unless you are referring to lag
time of the VAX responding to our hand-typed XON/XOFFs.  Please note that
changing screen modes to enter or exit Tektronix graphics emulation involves
a full Bios video Mode Set and that takes a long time with interrupts turned
off. To prevent overruns from the serial port I bracket the mode-set with
XOFF/XON to suspend the host.  Some modems will echo these characters and
thus suspend Kermit for Set Receive Timeout (13) seconds unless SET TIMER
OFF is given.  That is the cause of troubles starting the modem. Bell noises
mean characters were lost in an overrun.  Try SET TIMER OFF before starting a
Tek session since the timer is mainly for (a) packet timeouts and (b) to break
XON/XOFF deadlocks of precisely the kind which you encountered (local and
remote sides tell each other XOFF simultaneously); expect lost characters
during text-graphics screen changes.  It's a limitation of the machine's
architecture.]

------------------------------

Date: Fri, 5 Feb 88 19:25:22 PST
From: [e-mail]
Subject: MSKermit on Zenith eaZy-PC Serial (Mouse) Port
Keywords: MS-DOS Kermit 2.30, Zenith Kermit, eaZy-PC Mouse Port

On a Zenith eaZy-PC, there is a built-in serial *mouse* port.  Experiments
had shown that ProComm can use it as a communications port at speed up to
19,200 baud without problem, but MS-Kermit will hang the machine at the
first character.  Does anyone know why?

(To rephrase the question, if a serial port works for a serial mouse *and*
ProComm (at high baud rate), why wouldn't it work with MS-Kermit 2.30?)

BTW, the port address of this only serial port is 0x02F8, if that matters.
Any pointers would be appreciated.

..Sam

Internet: <[e-mail]> or <[e-mail]>
UUCP: {ihnp4!alberta,watmath,uunet,uw-beaver}!ubc-vision!ubc-mts!skl
BITNET: <USERSKL@UBCMTSG>

[From JRD - My Microsoft serial mouse does the same thing when I talk to it
from Kermit while in TEKTRONIX mode (for testing, naturally, since the mouse
is a poor conversationalist). The cause for me is the mouse echoes the
XOFF/XON sent while the screen changes to graphics mode, which is a very slow
process partly done with interrupts turned off.  But communications resume
about 13 seconds (SET RECEIVE TIMEOUT interval) later as Kermit breaks the
XON/XOFF deadlock. Another likely situation is the port does not use the same
Interrupt ReQuest line as IBM machines or even that the mouse driver grabs
material away from Kermit.  Release 2.30/A will help resolve the IRQ business
automatically but can do nothing about aggressive drivers.]

------------------------------

Date: Mon, 8 Feb 88 14:59:03 est
From: [e-mail]
Subject: Kermit & OS/2
Keywords: MS-DOS Kermit, OS/2 Kermit

I tried to run MS-Kermit 2.29B and 2.30 under OS/2 in the DOS compatibility
box.  It sort of worked.  I think it might be OK at a slower speed, but this
was at 9600 baud.  Problems include "bell sounds" (Ctrl-G's), and data that
should have been arranged in columns not lining up correctly.  I think the
other side of the connection thought I was sending BREAKS as well.

I have seen similar results on an ATT 6300 running Kermit as a DOS task
under UNIX at 9600 baud and a 6mhz AT running Kermit under Wendin's PC UNIX.
I think the problem in each case is the PC is not fast enough to manage 9600
baud and a 'real' operating system.

There was a plan at one point to merge PC Kermit into C-Kermit.  This might be
the best migration path towards OS/2.

    Stephen Northcutt ([e-mail])

[From JRD -- Slowness is the result of all the overhead of context switching
from protected to real mode which must be occuring once for each received
character. The Control-G Beeps mean the UART received a new character before
the last was extracted - an "overrun" situation.  Microsoft warns of this
effect on 80286 based machines due to the design deficiency of that Intel
chip; 80386's are vastly better.  The context switch to real mode involves a
full reset of the cpu chip (yikes!) and, clearly, interrupts are off;
selected 80286 chips have a faster reset pathway but they seem to be present
or used in fast reset mode only in the PS/2 machines.  Conversion to a full
protected mode OS/2 version of C Kermit is indeed on my mind; that is a lot
of work and costs a few dollars.  I have no direct information on Wendin's
O/S products beyond that stated in a few magazine articles.]

------------------------------

Date: Mon, 8 Feb 88 15:36:43 est
From: [e-mail]
Subject: Int 14h, Kermit and Networks
Keywords: MS-DOS Kermit 2.30

The documentation for 2.30 Kermit mentions communicating with the BIOS via
Int14h on some clone PCs.  (much improved documentation by the way, many
thanks).

The documentation for my PC's Bridge Communications Ethernet adapter card
mentions communicating with terminal emulation sw via Int 14.

I read and re-read the Kermit documentation, but could not find out how to
tell Kermit to treat my PC as a clone and use the BIOS.  Finally I modified
line 1548 of MSXIBM.ASM to read "jmp chkpor1".  The resulting Kermit used
the BIOS.  When I Connected the Bridge PCS1> prompt appeared.  With Kermit I
was able to telnet to a host computer.  I was even able to use a Kermit
server on the host computer to transfer a file to my PC.  Kermit at 10 mbs
takes a little getting used to, but I am sure I will.

Have I missed something?  Was there a Kermit command to force use of the
BIOS?  The problem with my version of Kermit is that now it always finds the
Bridge board, not the serial port.

If I didn't miss anything is it an option worth having?  I am under the
impression there are several networking boards and software that allow Int
14 interfacing.  Perhaps an addition to the Set Port command to include BIOS
along with 1 - 4 and NET.  I am even willing to attempt the coding, but be
warned, the MSXIBM.ASM change was my first foray into assembler.

        Stephen Northcutt ([e-mail])

[From JRD -- Stephen.  The story here is Kermit uses the Bios only if a
suitable UART is not available, but not by command of the user.  LAN vendors
have invented a variety of interesting extensions to the serial port Bios
interrupt vector but I do not have documentation from them to do anything
about those methods. The best suggestion currently is to do what you did:
get sources and make a local change; that's one of the reasons for sources
being available.  At least Bridge chose to emulate regular Bios calls rather
than using proprietary settings of registers.  Did Bridge really let you run
TCP/IP's Telenet?  If so we'd really like to know!]

------------------------------

Date: Mon 08 Feb 1988 15:39:27 EST
From: <[e-mail]>
Subject: MS-Kermit Tek 4010 Emulation Typeover -vs- Overlay
Keywords: MS-DOS Kermit, Terminal Emulation

>>>>Date: Sun, 10 Jan 88 20:59:48 PST
>>>>From: Ya'[e-mail]
>>>>Subject: MSKERMIT ver 2.29C tektronix 4010 won't overlay ALPHA and VECTOR
>>>>Keywords: MS-DOS Kermit 2.29C
>>>>
>>>>Possible bug with MSKERMIT version 2.29C:
>>>>
>>>>I have been using MSKERMIT vers 2.29C and have encountered a bug (feature?)
>>>>in the Tektronix 4010 emulation mode.  Specifically, alpha mode characters
>>>>will erase and NOT OVERLAY vector mode data.  This frequently causes plot
>>>>titles and labels to obliterate the graphed data.
>>>>P.S. I have an IBM-PC/XT clone with the CGA adaptor.
>>>>
>>>>[Ed. - This seems to be the behavior on the CGA, but not the EGA...]
>>
>>[From jrd - A complete 8 by 8 dot character cell is written for each
>>character, so that both foreground and background colors are maintained and
>>characters can be erased. Supression of the background is being considered
>>but may not be do-able and still maintain the above characteristics. If
>>annotation is done first then the problem does not occur. I'd like
>>overlaying too.]

I have already undone this 'improvement' to the Tek 4010 emulator in my copy
of kermit (2.30).  It involved only about a half dozen lines in the
MSGIBM.ASM file.

                                 Stuart Scharf (SS@LL)

[From JRD - Making the change in the code is easy.  The reason for doing it
my way is explained above, mostly erasure (after all, we are a few years
beyond punched cards and paper tape).  The Tek storage tube characteristic
of overwriting everything is messy in today's environment, especially with
my typing skills.  If the Kermit community would rather have the overwriting
then I'll remove the full cell approach and hence erasures.  What's the
consensus?]

------------------------------

Date: 10 Feb 88
From: Robert W. Lane, Iowa City, IA (via US mail)
Subject: IBM PC MS-Kermit vs Datatronics Internal Modem
Keywords: MS-DOS Kermit 2.30, Modems

I have a Datatronics internal modem, 1200 baud, and I'd like to configure
it as COM3 at 03E8h using the 8259 interrupt line IRN4 (also used by COM1).
MS-Kermit 2.30 will let me access this modem using SET PORT 3 after running a
short program called SETCOM3 in order to update memory at 40:0000h with the
address of the modem.  Unfortunately, this modem is built around a 8031
microprocessor and when Kermit tries to ascertain whether or not the port found
in 40:0000h has an 8250 async controller, it fails and prints a message that
all calls will go through the Bios.  Is there any way to make Kermit skip this
test and just use the interrupt vector at IRQ4 (at 0030h)?

[From JRD -- Selecting an IRQ (4 in this case) is only part of the story.
Kermit needs to talk with the UART chip to set/get the baud rate, send/receive
characters, and so forth, and thus Kermit needs to know a lot about the UART.
That is why the tests are done before activating a serial port and why the
Bios is used if an 8250 chip is not found. If the Datatronics modem has such a
specialized pseudo-UART then only software tailored to it can be expected to
function. You might wish to query the manufacturer about this situation.]

------------------------------

Date: Thu 18 Feb 88 11:43:24-PDT
From: [e-mail]
Subject: MS-DOS Kermit Using EGA 43 Line Mode
Keywords: MS-DOS Kermit 2.30

I've found a couple of bugs in MS-Kermit 2.30 for the IBM when using EGA 43
line mode, I'm going to try to look at the code when I get a chance, but in
case someone else fixes it first (or jrd has already fixed them!):

    1. The cursor is a dash after exiting connect (I saw the note in
    MSKERM.BWR, it's kind of a pain to have to run a program to fix the
        cursor every time you pop in and out of kermit.

    2. The STAT command doesn't clear the screen, it starts from the top
    but leaves stuff at the bottom.

    3. Scroll up doesn't work, it only goes 3 lines and only once. I tried
    to fix this in 2.29, but gave up when I heard 2.30 was imminent, hoping
    it would be fixed.


                    Mike Pawka
                    [e-mail]

[From jrd - Mike, EGA 43 line mode stuff. Thanks.

Cursor is a dash after exiting Connect mode. This appears to be an EGA board
problem. IBM had bugs in their original EGA boards and Kermit takes steps to
avoid it within Connect mode. However, testing here with a Video 7 EGA board
in all kinds of strange screen modes indicates no problems.

Similarly, the lack of screen clearing for the STATUS command does not
appear here. I just check the item by going into 43 line mode to write this
note. If you are letting ANSI.SYS be active then it knows only 25 lines
whereas in Connect mode Kermit takes charge.

Only 3 lines on Scroll Up commands. That means Kermit found insufficient
memory for screen buffers and Command.com together so sacrificed buffer
space to allow subsidary tasks to be run via Command.com.  Use CHKDSK or
Kermit's SPACE command to see the total free memory. However, memory space
is easily fragmented by loading TSR's.

What brand of EGA board and machine are you using?]

------------------------------

Date: Monday, 22 February 1988 10:24am EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Toshiba T3100 versus MS-Kermit Tek Emulation
Keywords: MS-DOS Kermit 2.30, Terminal EMulation, Toshiba Kermit

It has come to our attention that Tek Emulation doesn't work on the
Toshiba laptop.  Not only doesn't it work, it hangs the machine so badly
that only powering it off and on will revive it.  It seems that the Toshiba,
although apparently IBM compatible in other respects, requires a special
function call to put it in graphics mode.  The question is, how can MS-Kermit
tell, at runtime, that it is running on a Toshiba 3100, rather than a real
IBM PC?  Is there a ROM location that has a unique machine identifier?

------------------------------

Date: Fri, 19 Feb 88 00:56:53 EST
From: [e-mail] (Charles Hedrick)
Subject: C-Kermit on sys-V Based PCs
Keywords: C-Kermit 4C(058)

Re: Info-Kermit Digest V7 #6

Because of the question about Kermit on various sys-V based PC's, I
thought I'd confirm that version 4C(058) works without any
modifications on Microport System V/AT, which is Sys Vr2 for a PC/AT.
I compiled it as sys3nid.  (There is no need to request separate I&D
space.  You always get that effect.)  Microport supplies 4D, which
also works fine, but I built 4C (the most recent source we had lying
around at Rutgers) because I like to have my major applications
programs built from source.  (Of course I have no way to know what
Microport may have done to bring up 4D.)

------------------------------

Date: Wed, 17 Feb 1988  23:03 MST
From: "Frank J. Wancho" <[e-mail]>
Subject: Using TOPS-20 Kermit with 9-Bit Files
Keywords: TOPS-20 Kermit

The KCC DEC-20 C compiler defaults to 9-bit files when you create a file
with "wb" for its own reasons - the internal character types are 9-bit, and
four 9-bit quantities on a read will properly pick up all 36 bits in a
PDP-10 word.  However, all you have to do is change the "wb" in the open to
"w8" and you will get the expected behavior, i.e. 8-bit files which DEC-20
Kermit can recognize automatically.

[Ed. - Thanks, Frank!  Your message has been added to the DEC-20 Kermit
"beware file".]

------------------------------

Date: Fri, 19 Feb 88 14:13 +1000
From: Andrew Hunt <munnari!rpepping.oz.au![e-mail]>
Subject: Re Mark Zinzow's request for MicroBee Kermit
Keywords: MicroBee Kermit, CP/M Kermit

Yes CP/M Kermit does run on a MicroBee - a colleague of mine has one
and uses kermit betweem it and his PC.  He warned that the only problem
he had found occurred when using the optional dual serial line (SCC)
ports on the memory card in place of the one on the mother board.  In
this case there are 3 serial ports on the machine which confuses the
poor wee beasite - solution is to disable the single mother-board port
and then all performs well up to 38400 Baud.

There exists - somewhere in the vicinity of "Public Domain" - a program
called PC-Alien (incl PC-Alien Jnr and MSA) for reading foreign CP/M and
MS-DOS diskettes on ordinary PCs.  This includes support for MicroBee
format 360KB diskettes and I have successfully used it for reading and
writing such.

Regards ...Andrew HUNT,   CSIRO Radiophysics, Australia.

------------------------------

End of Info-Kermit Digest
*************************

-------
18-Mar-88 19:11:26-EST,18173;000000000001
Mail-From: SY.FDC created at 18-Mar-88 19:10:22
Date: Fri 18 Mar 88 19:10:22-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V7 #8
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 18 Mar 1988       Volume 7 : Number 8

  ANNOUNCEMENTS -
        Announcing IBM Mainframe MVS/TSO Kermit Version 4.0
        Announcing Kermit 2.30 for the RMX86 and RMX286 Operating System
        New Release of Harris-100 Kermit
        Announcing a New Kermit for Kaypro I
        C-Kermit Amiga Un-BOOing Bug Fix
        New Kermits on the Way from the UK
        ASCII, ISO, and which EBCDIC?

----------------------------------------------------------------------

Date: Wed, 1988 Mar 16  16:55 EST
From: (John F. Chandler) [e-mail]
Subject: Announcing IBM Mainframe MVS/TSO Kermit Version 4.0
Keywords: IBM 370 Kermit, MVS/TSO Kermit, TSO Kermit
Xref: IBM Mainframe, Also see IBM 370
Xref: MVS/TSO Kermit, Also see MVS/TSO Kermit, IBM 370

This is to announce TSO Kermit Release 4.0.  The program is now a member of
the generic family Kermit-370 and appears in the Kermit distribution under a
new prefix: all TSO-specific files begin with IKT, while generic Kermit-370
files begin with IK0 (I K Zero).  Kermit-TSO no longer consists of just two
source files.  Instead, the source is split into sub-files, some generic and
some TSO-specific.  The separate pieces are to be recombined into a single
composite source (or made into a macro library) for installation.  See the
file IKTKER.INS for instructions.  Generally, the files formerly known as
TS*.* (except TSN*.*, the NIH version) will be replaced by the new IKTKER.*
files.  This TSO Kermit is still in the testing stage, but most of the
features described in the documentation have already been verified.  Any bug
reports should be sent to John Chandler <[e-mail]>.

Below is a list of the more important additions in Version 4.0:

    --- generic features (same as announced for CMS last December) ---

1.  Code reorganization into generic 370 and system-specific sections.

2.  Optional separate translation tables for counteracting the system
    conversion of terminal I/O.

3.  New GIVE command for saving a modified translation table.

4.  A new, RAW debug mode for recording the packet traffic as actually
    sent and received on "GRAPHICS" and "SERIES1" devices.

5.  Preservation of the case of commands as typed, with uppercase
    conversion of only those words that must be uppercase.

6.  New SET MARGIN command for limiting the width of a file to be sent.

7.  Settable tab stops for Kermit's conversion of tabs to spaces
    (alternative to the default 1, 9, 17, etc.).

8.  Support for multiple terminal controller types.

9.  New DIRECTORY and HOST subcommands following Kermit standard.

10. Combination of file-attribute SET subcommands (FILE-TYPE, LRECL,
    BLKSIZE, and RECFM) into a new group SET FILE.

11. Separate retry limits for initial and subsequent packet exchanges.

12. Pad binary records on disk with nulls, rather than blanks.

13. Automatically tune packet length when sending long packets according
    to heuristic optimum based on sparse Poisson statistics, provided
    that transmission errors do occur.

14. Expand STATUS report to include the number of files in the last
    transfer, throughput statistics, heuristic optimum packet length
    (when long packets are enabled), and the reason for any file
    rejection based on A-packets.

15. New command TDUMP NAMES to display the list of files sent in the
    last transfer.

16. Send and acknowledge attribute packets.  Add file creation date to
    A-packet repertoire.

17. REMOTE COPY and REMOTE RENAME commands to a server at the other end.

18. Allow long packets through a 7171 with VTAM.

19. New type D-BINARY for binary files with undelimited variable-length
    records.

20. SET 8-BIT-QUOTE.  Allow 8-bit data where possible via SET PARITY.

21. SET SYSCMD, so that Kermit can be told to try "illegal" subcommands
    as host system commands instead of just rejecting them.

22. SET PROMPT subcommand.

23. Remember parameters specified by the other Kermit in I-packets.

24. Keep track of truncated records during a RECEIVE operation and
    report the count in STATUS; also call truncation an error after
    everything is received.

25. SET HANDSHAKE subcommand to alter or suppress handshake character
    Kermit-370 sends out after each packet (not available for 3705's).

    --- features new to TSO Kermit ---

Since Version 4.0 is the first release of Kermit-370 for TSO, some of
these "new" features are actually new only to the Columbia distribution
for TSO.

26. Suppression of LINE and CHAR delete functions during protocol mode.

27. Advanced server functions and subcommands for talking to another
    Kermit running in server mode.

28. Long packet protocol.

29. TYPE, ECHO, XTYPE, and XECHO subcommands (the last two being
    Series/1 analogs of the first two.)

30. REMOTE KERMIT commands honored by TSO server, including SET, SHOW,
    TAKE, TDUMP, STATUS, HOST, TSO, CWD, DIR, and TYPE.

31. TEST mode for debugging.

32. Multi-column, two-level, selective SHOW display.

33. Optionally append to, rather than replace, old data sets with
    duplicate names.

34. Automatic detection of terminal controller type (TTY or SERIES1).

35. SYNADAF message in cases of disk I/O error.

[Ed. - This a major new Kermit release, one that many sites have been craving
for years.  At last, a single TSO Kermit that brings together most of the
capabilities of TSOKER (linemode only), TSOS1 (full-screen only), TS2KER
(long packets, etc), TS3KER (3708 front end support), etc, etc, plus all the
advanced features of VM/CMS Kermit, plus the ability to easily add support
for other IBM 370 operating systems, like MTS, MUSIC, GUTS, etc.  As John
points out, this version may not yet be fully debugged, especially on the
more esoteric front ends, so reports -- good or bad -- from testers are more
than welcome.  The files are in the Kermit distribution as KER:IK0*.* (system
independent files, shared by VM/CMS Kermit), and KER:IKT*.* (TSO-specific
files), available via anonymous FTP from CU20B.COLUMBIA.EDU, and available on
BITNET/EARN via KERMSRV at CUVMA ("TELL KERMSRV AT CUVMA HELP") as IK0* * and
IKT* *.  Once the kinks, if any, are ironed out, this version will replace
TSOKER, TSOS1, and TS3KER in the Kermit Distribution.]

------------------------------

Date: Thu, 17 Mar 88 14:17:42 PST
From: [e-mail]  (Jack Bryans)
Subject: Announcing Kermit 2.30 for the RMX86 and RMX286 Operating System
Keywords: iRMX86, iRMX286, Intel RMX
Xref: RMX, see Intel

This is to announce version 2.30 of Kermit for both the iRMX86 and iRMX286
Operating Systems.  It is the first release for iRMX286 and the first since
late 1985's version 2.26 for iRMX86.

This is the same program, ported to the RMX's, as the Jan. 8,1988 release of
MS-Kermit, version 2.30, for the IBM PC, which is probably the most widely
used and richest Kermit implementation.  A DOS emulator provides enough of
the DOS environment to allow the essentially unchanged MS-Kermit code to run
under both of the RMX Operating Systems.  For a summary of changes on the
MS-Kermit end, see the KERMSRV files MS*.UPD.

From the RMX end, this version includes support for wild cards, full RMX
paths and file names, and removes restrictions on the use of RUN.  You can
now RUN AEDIT from within Kermit.

As a fortuitous fallout to wild card implementation, a list of file names may
be used wherever Kermit accepts a wild card file specification, as long as
all files in the list are in the current default directory.  For example:

SEND READ.ME.FIRST,*X*.A*,*.OBJ,ETC.ETC

works.  Try to say that in DOS!  Similarly, when Kermit is in SERVER mode, it
will respond to a GET file-name-list from the local Kermit.

The SET and SHOW KEY commands have been added.

Configuration has been completely redone, with its implementation separated
from the Kermit initialization file.  To avoid confusion with the previous
version, the .ini file name has been changed to KERMIT.INI.  A good dozen
configuration options are available, reducing the need to obtain the source
code.

Serial ports have been increased to ten, with all requirements and
restrictions on device attachment removed.  Additionally, you can ping-pong
between serial communication ports and the port your terminal (in this case,
presumably, a PC) is attached to, with the file transfer display
automatically set to QUIET mode (necessary for one port operation) and reset
to its previous mode when you select another port.

Performance has been improved in a number of areas, especially in connect
mode.  Improved serial device drivers scheduled for release in forthcoming OS
updates from Intel (RMX286, Release 2, Updates 1 and 2, and RMX86, Release 8)
will improve Kermit performance significantly on both OS's, especially on
faster systems.

A number of timing problems peculiar to '386 based systems have been cleared
up in the past month.  Feedback from '386 beta testers indicates performance
more than impressive enough to make 8086 users, appropriately, green with
envy.

The following files constitute this release:

MSVRMX.BOO  BOO-encoded executable Kermit for RMX86
MSVRX2.BOO  BOO-encoded executable Kermit for RMX286

MSVRMX.DOC  Documentation for both OS's

MSVRMX.HLP  How to build Kermit for either OS from source code
MSVRMX.CSD  The edit pass SUBMIT file.  \ Converts MSSDEF.H & MSS*.ASM
MSVRMX.MAC  The edit pass macro file.   / to MSSDEF.H86 & MSS*.A86
MSURMX.A86  Source code for the keyboard support module for RMX
MSXRMX.A86  Source code for the traditional "X" module for RMX
MSZRMX.A86  Source code for the DOS emulator and Kermit driver
MSVRMX.P86  Source code for the wild card implementing auxiliary command, WC

Note that all files but the enBOOed executables apply to both OS's.  The edit
pass generates submit files for conditional assembly and for linking or
binding the object modules to produce an executable for either OS.

The MS-Kermit files, MSKERM.DOC, MSKERM.HLP, and MSKERM.BWR provide primary
documentation for all version 2.30's.

Acknowledgments:

Joe Doupnik of Utah State University, who has been responsible for MS-Kermit
starting with version 2.29, was most accommodative in making changes to the
DOS code to simplify things for the RMX portings.

Among the beta testers, Steve Cox of Milliken Research Corp., Chris Jamison
of Ransburg Corp., and especially Chris Vickery of Queens College, NY,
provided valuable feedback.  Henning Pangels of Carnegie-Mellon University's
Robotics Institute showed up in the nick of time via e-mail, innocently
inquiring if there was an RMX286 Kermit he could try out on his brand new
'386.  His response to being pressed into guinea pig duty is appreciated.

Mark Aaldering of Intel made the port to RMX286 possible.  Thanks also to
Intel's Paul Cohen, Rick Gerber, and Tom Willis, and, with apologies, to
those overlooked.

[Ed. - Thanks, Jack!  These files are now in the Kermit Distribution under
the names you've listed.]

------------------------------

Date: 17 Mar 88 0:0:0
From: [e-mail]
Subject: New Release of Harris-100 Kermit
Keywords: Harris-100

Enclosed is the lastest revision of the Harris 100 Kermit (H100KER.*) which
I sent you last year.  Revisions include miscellaneous minor bug fixes and
better handling of embedded End-of-file marks.  This brings the current
version number up to 1.06 (June 87).  The program has been tested for
compatability with MSKERMIT 2.30.  See the .DOC file for more details.  A
list of the changes made in each version can be found near the end of that
file.  This will be my last version of Harris Kermit, since, tragically, our
Harris is scheduled to expire in a few weeks.

The files are as follows:

   H100KER.DOC  -- documentation file (contains usage info, technical
                   info, revision history, "bewares", etc.)

   H100KER.JCL  -- Harris JCL for compiling

   H100KER.F77  -- Fortran code

   H100KER.ASM  -- Assembler code

   H100KER.HLP  -- On-line help file (sent in response to REMOTE HELP)

To bring your "version" file up to date, the operating system we are using
is now "VOS 5.1.0".

Skip Russell
Division of Biostatistics, Washington University in St. Louis

[Ed. - Thanks, Skip!  The files are now in the Kermit distribution as
KER:H100*.* (H100* * on KERMSRV).]

------------------------------

Date: Wednesday, 17 February 1988  05:00-MST
From: "Paul V. Pullen" <[e-mail]>
Subject: Announcing a New Kermit for Kaypro I
Keywords: Kaypro I Kermit

I have successfully completed the creation of a new version of Kermit for my
Kaypro1.  I have an LASMed hex file to be included in the SIMTEL20 Kermit
data that will enable others using the Kaypro1 to work successfully with a
proper (or at least my copy works properly now).  I had to create a special
'log' in the CP4TYP and CP4SYS asm files.  I did it by adding another
defination, being a kp1, and setting terminal type to ADM-3A, which is the
proper look alike for the Kaypro1.  Then, to work properly with my Base Vax,
I used the TERMCAP for an ADM3A and named it a kp1|kaypro1|Kaypro 1|.  The
effect is a fully operational termcap for my system, and support on the VAX.

One requirement to make the upload-download (especially download) to operate
properly was the reduction of the 'maxsec' to 4K from 8K in CP4SYS.  The
requirement to make the kaypro1 kermit to run will be to mload CP4KER,CP4KP1
together, and the resulting kermit works properly here at least.

Paul Pullen
(address: [e-mail])
(Snail mail:  8100 Sagramore Road
              Baltimore, MD. 21237)

[Ed. - Thanks!  The hex file is in KER:CP4KAD.HEX, and some documentation in
KER:CP4KAD.HLP.]

------------------------------

Date: 25-FEB-1988 16:50:15 GMT
From: [e-mail]
Via: [e-mail]
Subject: C-Kermit Amiga Un-BOOing Bug Fix
Keywords: Amiga Kermit, Commodore Amiga

I have now successfully installed KERMIT on the Amiga from the CKIKER.BOO
file, using the programs suggested by W.Maessen for initial transfer of the
.BOO file.  To perform the translation of the .BOO file to an Amiga executable
file, I use the C program CKIBOO.C. However, I feel I should point out two
problems with CKIBOO.C which prevented it compiling under Lattice 3.1.

Firstly, the preprocessor IF nesting in lines 26 to 39 is WRONG - the #endif
at line 30 should appear after line 39. The program thus failed to compile as
it ended up looking for <sys/file.h> in line 37.

Secondly, the preprocessor IS cas3 sensitive and all #commands must be in
lower case. Thus the #IFDEF and #ENDIF lines in the last 10 lines of the
program should be in lower case.

I have appended the corrected version of CKIBOO.C and hope this will alleviate
a few hours of frustrating debugging for other users.

Andrew C.R. Martin,
Laboratory of Molecular Biophysics,
University of Oxford,
U.K.

The ammended version of CKIBOO.C was tested under Lattice C V.3.10 and
Kickstart 1.2 on an Amiga 1000.

[Ed. - Thanks!  This program is now in KER:CKIBOO.C in the Kermit
distribution.]

------------------------------

Date: 15-MAR-1988 12:36:45 GMT
From: [e-mail]
Subject: New Kermits on the Way from the UK
Keywords:  MINIX Kermit, CP/M-80 Kermit 4.09, Acorn Archimedes

Some good news for you. I have just received a kermit for the MINIX.  It is
based on C-Kermit 4D (061) sources and the author Adria Godwin of Thorne EMI,
has made a commitment to update it when we have all the files for 4E (070).

I am also in the process of getting CP/M-80 Kermit 4.09 files off to you as
they are now on line here with no problems as yet reported.

Last but not least Acorn have at last supplied the Archimedes Kermit. They
have, unfortunately supplied in a format that will take some work to get on
line but I'll forward them ASAP.

                    Regards,
                        Steve

[Ed. - This message published in case anyone else was thinking of working on
any of these items.  There are also some other Kermits due for new releases
shortly, including Apple II, Apple Macintosh, and Os9.]

------------------------------

Date: Mon, 14 Mar 1988 08:45:21 +0100
From: Andre PIRARD <[e-mail]>
Subject: ASCII, ISO, and which EBCDIC?
Keywords: Translation Tables, Character Sets, ASCII, EBCDIC

We ASCII or EBCDIC network users must pay particular attention to character
codes standards, now extending to international. Even sites not interested in
in international characters will sooner or later hit the problem because,
albeit the situation is straight in the ASCII world with an ISO standard, it
is far from that for EBCDIC users faced to a choice of several codes whose
differences lies on a few codes, strangely enough not international.

The subject is discussed on a mailing list set up by Edwin Hart. Join with:

  TELL LISTSERV AT JHUVM SUB ISO8859 user-name

Or sending a note on BITNET to: LISTSERV AT JHUVM
Containing:                     SUB ISO8859 user-name

can help the community agree on a viable single code or at least help each
site in finding its most appropriate one and save everybody's time and money.
I'll soon post a summary of the problem to that list.

Please forward this note to anybody interested.

------------------------------

End of Info-Kermit Digest
*************************
-------
22-Mar-88 14:05:43-EST,22558;000000000000
Mail-From: SY.CHRISTINE created at 22-Mar-88 14:04:36
Date: Tue 22 Mar 88 14:04:35-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #9
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 22 Mar 1988       Volume 7 : Number 9

Departments:

  ANNOUNCEMENTS -
        Announcing Kermit-65 3.81 for Apple II DOS and ProDOS
        Announcing Os9/68k C-Kermit 4E
        Announcing MS Kermit v2.30 for the NEC APCIII
        Results of Porting C-Kermit 4E and Fixes

  MS-DOS KERMIT -
        MS-Kermit 2.30: Question & Bug?
    MS-Kermit 2.30 vs Internal Qubie Modem
        MS-Kermit Block Check Bug?
    MS Kermit V2.30 Problem on PS/2 Model 60
        MS-Kermit 2.30 Use over Ethernet LAN
        Kermit v2.30 and Hayes Modem Query
        A few Notes on MS-Kermit 2.30

----------------------------------------------------------------------

Date: Tue, 16 Feb 88 14:09:53 PST
From: Ted Medin <[e-mail]>
Subject: Announcing Kermit-65 3.81 for Apple II DOS and ProDOS.
Keywords: Kermit-65, Apple II Kermit

Ok, here is version 3.81 for the Apple II, DOS and ProDOS.
The significant changes between 3.79 & 3.81 are as follows:

1. gs keypad support for vt100 mode
2. print screen function for //e or better
3. cursor keys can become vt100 cursor keys
4. improved initial prefix get - thanks to Sean Noland
5. file transfer now supports wildcard sends - thanks to Dick Atlee
6. server mode improved
8. new manual, APPLE.DOC (from APPLE.MSS).

[Ed. - Thanks, Ted.  The new release is in the Kermit Distribution as
KER:APP*.* on CU20B.COLUMBIA.EDU, available via anonymous FTP, and on
KERMSRV at CUVMA as APP* *, for BITNET/EARN access.]

------------------------------

Date: Mon 22 Feb 88 00:28:49-PST
From: Bob Larson <[e-mail]>
Subject: Announcing Os9/68k C-Kermit 4E
Keywords: Os9 Kermit, C-Kermit

Os9/68k ckermit is functionaly identical to UNIX C-Kermit, with a few minor
problems noted in ck9ker.bwr.  Support for Microcom modems has been added to
ckudia.c.  Thanks to Peter Scholz of the Ruhr Universitaet Bochum for his
incomplete port of an earlier version of C-Kermit, some of which survives in
ck9tio.c and ck9fio.c.

This is the most complete of the three families of Kermit for Os9/68k.  The
original (based on old unix kermit) is still needed for Os9/6809.  (A new
version has been mentioned on Compuserve.)   There's also the assembler
version from Italy, but it's primarily intended as a portable 68000 Kermit,
with Os9 support included as an example of how to implement it for a
particular system.

[Ed. - Thanks, Bob!  Your files are in KER:CK9*.* on CU20B, and CK9* * on
CUVMA.  The diff files have been combined together into a single file,
CK9KER.DIF.  The indicated changes were not applied to mainline C-Kermit, but
will probably be included in the next release of C-Kermit.]

------------------------------

Date: Mon, 21 Mar 88 10:45:20 est
From: Robert F. Goeke <[e-mail]>
Site: MIT Center for Space Research, Cambridge Mass.
Subject: Announcing MS Kermit v2.30 for the NEC APCIII
Keywords: NEC APCIII

        I was a little surprised to find out a week ago that v2.30 of MS
Kermit had gotten released in January -- not having heard from anyone since
last summer.  Nevertheless a bit of fast keyboarding brought the NEC community
back up to date.  The current version for the APCIII does everything the IBM
one does -- including the Tektronix emulation -- with the following
elaborations:

        a)  The graphics are 640 x 400 in your choice of green, no
        matter what the text screen color is.

        b)  The graphics are not saved during mode switch.

        c)  The function performed by Shift-Arrow during cursor control
        is done by Control-Arrow on the NEC (shift arrow doesn't emit
        a unique key code here).  I'm not sure this is even mentioned in
        the manual, but the msg code made it clear.  Furthermore, the APCIII
        use the "real" arrow keys for this function, not the 2-4-6-8 set.

The remaining comments in the manual concerning the NEC APCIII implementation
are still all correct.

The files for the APCIII implementation are: available via anonymous

        msgap3, msuap3, msxap3, msyap3, and mszap3 (all .asm)  for source
and
        msvap3.boo                                             for executable

                                        Bob Goeke
                                           [[e-mail]]  or
                                           [...!seismo!space.mit.edu!goeke]
                                        MIT Center for Space Research
                                        Cambridge, Massachusetts  02139
                                        617-253-1910

[Ed. - Thanks, Bob, and sorry for the crossed signals.  The files listed
above are now in the Kermit distribution.]

------------------------------

Date: Sun, 28 Feb 88 02:47:21 EST
From: [e-mail] (Charles Hedrick)
Subject: Results of Porting C-Kermit 4E and Fixes
Keywords: C-Kermit 4E

I just finished porting Kermit 4E to my Microport System V/AT.  As usual,
simply typing "make sys3nid" (which is the setting for vanilla System V,
oddly enough) works correctly.  It works correctly in the sense of building
a kermit that works the same as it works on other systems.  Unfortunately,
the major new feature in 4E turns out not to work on any of the systems I
have access to.  This is the long packet size feature.  The two kermits
exchange information about what options they support.  Unfortunately, the
code used for generating the byte that contains the capabilities appears to
be wrong.  It results in having the systems say that they don't support long
packets.  The expression is a long one involving several ? : constructs.  My
C documentation does not make clear what the relative precedence of ?  and |
should be.  However both the Sun 3 and System V 286 compilers take the
opposite view from the authors of C Kermit.  By adding a few ()'s, we avoid
the ambiguity.  There was also a problem that the packet size sent for the
benefit of old systems that don't support long packets was miscalculated.
THey simply took the low-order byte of the full packet size.  What they
wanted was MIN (packetsize, 94), 94 being the maximum size allowed by old
implementations.

The fixes are shown below.

This message is being sent to be info-kermit and the Microport newsgroup.
For the benefit of Microport users, let me note that Microport supplies a
fairly recent version of kermit with the system, version 4D.  The version
being discussed here adds only the long packet support.  (You might still
find it useful to get the files, since Microport doesn't seem to supply
documentation.)  Kermit is available via anonymous FTP from
CU20B.COLUMBIA.EDU.  The files you need are roughly ker:ckc*.*, ker:cku*,
and ker:ckw*, but ker:ckaaaa.hlp will give me information.  Kermit is also
available at Simtel20.  The index I have claims it is pd2:<unix.kermit>,
although today I was unable to get to those files to check them.

[Ed. - Thanks, Chuck!  Always wondered how long it would take to drag you
into Kermit maintenance...  Your changes have been added to the "beware
file" for now, and will appear in the next release.]

------------------------------

Date: Tue, 2-Feb-88 19:41:52 WET
From: [e-mail] (Ronald Soo Han Khoo)
Subject: MS-Kermit 2.30: Question & Bug?
Keywords: MS-DOS Kermit 2.30

In comp.binaries.ibm.pc recently:

>From: [e-mail] (27-Jan-1988 1454)
posted a distribution version 2.30 of kermit.

1) QUESTION:

    Does anyone know if its possible to defeat the auto-detect of graphics
adapter type? (we run a service here with lots of m/cs with ega-type cards
emulating hercules, so its kinda inconvenient for the inexperienced users to
keep switching the emulation software around)

2) BUG ???

The documentation posted with it mentions that ctrl-]<space> returns the
terminal emulator to text mode from tektronix emulation mode.  This doesn't
seem to work in the version posted, but oddly, DOES on an older development
version (2.29C@cambridge).  Does anyone know anything about this ?

Duncan White,        |
Dept. Of Computing,  |    Flying is the art of aiming oneself
Imperial College,    |    at the ground and missing.
London, SW7.         |        -- Douglas Adams, So Long and Thanks
England.             |           for all the fish.

[From jrd - Hercules mode on EGAs: see comments below. Escaping from Tek mode
is well documented in the MS Kermit 2.30 manual; the quick way is to toggle
the terminal type via ALT minus (verb \Ktermtype).]

------------------------------

Date: Thu 18 Feb 88 14:29:26-CST
From: Clifford A. Wilkes <[e-mail]>
Subject: MS-Kermit 2.30 vs Internal Qubie Modem
Keywords: MS-DOS Kermit 2.30, Internal Modem, Qubie Modem, Sperry PC

I have a Sperry (IBM clone) with an internal Qubie 300/1200 baud modem.
I have been using KERMIT 2.26 which allows me to dial out via:

MS-KERMIT>connect
at
OK  (KERMIT response)
atdt9999999  (simulated number)

With version 2.30 only after booting (warm or cold) the first time entering
AT (capitals only) gets the OK response.  Subsequent attempts receive no
response from Kermit.  And no matter what I do (ATDT in caps for example)
the modem will not 'dial'.  With all of the new features I was wondering if
there aren't some switches that I should set specially.  The modem is Hayes
compatible.  I'm using port 1 and 1200 baud.

Any assistance will be appreciated.

[From jrd - What does SHOW MODEM indicate? Could you have a conflict with
another board using the same address or IRQ (4)? Any messages from Kermit,
such as using the Bios? And, are there any other "Helpful Utilities"
running?  Pretty standard questions, naturally, but version 2.30 does work
with internal modems.]

------------------------------

Date: Tue 16 Feb 88 19:29:38-EST
From: Charles Lasner <[e-mail]>
Subject: MS-Kermit Block Check Bug?
Keywords: MS-DOS Kermit 2.30, PDP-8 Kermit

Found a bug in MS-KERMIT (any version):

Set MS-KERMIT to Server Mode (might not be necessary but I found it this way)
using K12MIT which has no options as the local KERMIT I use GET FILESPEC
the MS-KERMIT end had SET BLOCK 3

THE K12MIT end only supports type 1

All transmissions fail with many retries in both directions. It appears the
MS-KERMIT end fails to negotiate down the BLOCK-CHECK TYPE back to 1. If the
BLOCK CHECK is set to one at the MS-KERMIT end, then all works fine. This is
a oneway bug.

The user settings of BLOCK CHECK are not to be the final used value, just the
starting point. When MS-KERMIT presents a 3 and K12MIT presents a 1, the 1
should win!

[From jrd - Tested MS Kermit against C Kermit and VMS/BLISS Kermit with MS
Kermit using Block Check 3 in server mode and the other two as requestors
with Block Check of 1. Files transferred just fine and the logs show type 1
Block Checks, as it should be.]

------------------------------

Date: Tue, 23 Feb 88 13:13:53 PST
From: [e-mail]  (Stephen Walton)
Subject: MS Kermit V2.30 Problem on PS/2 Model 60
Keywords: MS-Kermit 2.30, PS/2

I haven't seen this reported before, so here goes: I recently used MS-Kermit
V2.30 on a friend's brand new IBM PS/2 Model 60.  For the record, it has all
IBM equipment: 44 MB hard disk, 1 MB RAM, and VGA.  My own floppy was the
only disk I wrote to.  Everything seemed to go fine with the file transfers,
and I shut off the machine when I was done.  The next morning, to our
horror, the PS/2 wouldn't boot!  A reboot with the IBM-supplied setup
diskette revealed that the system configuration was bad; specifically, the
system time had been corrupted.  A strange problem.  Any ideas?

  Steve Walton, formerly of Ametek, now at Cal State Northridge

[From jrd - Kermit does not mess with (read or write or even know about) the
CMOS setup and clock nor does it even dream of setting a system clock. So,
it is another system effect unrelated to MS Kermit.]

------------------------------

Date: Thu, 18 Feb 88 11:13:42 EST
From: [e-mail] (Bob Napier)
Subject: MS-Kermit 2.30 Use over Ethernet LAN
Keywords; MS-DOS Kermit 2.30

I'm configuring a network of IBM PS/2's and a Microvax 3500.  I need to run
an application on the MicroVAX from the pc's over Ethernet with Tektronix
40xx emulation.

The network board I'm considering for the pcs is 3com Etherlink/MC and
Novell Netware software. The MicroVAX will have an Ethernet interface
adapter and the networking software is still up in the air.

Question: Will Kermit 2.3 support MicroVAXen over Ethernet??  That is, is
there a corresponding version of Kermit for the VAX to act as a server to the
PS/2s??

Thanks,

Bob Napier ([e-mail])
615-576-4547

[From jrd -- Bob, joining the MicroVax to PS/2's on a Novell NetWare LAN is
a little more complicated than plugging things together. The main concern is
getting the MicroVax to speak NetWare (IPX packets to be precise) so I
presume you are using a bridge or TCP/IP. MS Kermit readily talks across
NetWare using their NetBios emulator. If you are using 3Com's TCP/IP package
then I'd have to talk with 3Com about their mechanisms of bridging out of
the LAN.  However, the other approach is to make the MicroVax regard the LAN
connection as a regular login port. In that case MS Kermit could speak to
the MicroVax directly as a terminal (across the LAN in packets and all) just
as I do to my Unix box with STARLAN. Check with 3Com and/or have them give
me a call at [phone] (days, MST) to sort out the affair.  If it makes
any difference a lot of people want similar functionality: from PC on a LAN
to their larger host via Ethernet or whatever.]

------------------------------

Date: Wed, 2 Mar 88 14:05:16 CST
From: [e-mail] (Moore)
Subject: Kermit v2.30 and Hayes Modem Query
Keywords: MS-DOS Kermit 2.30

I'm having a problem executing a remote command using Kermit; I hope someone
can help:

I have a server on the west coast running MS Kermit 2.30 on a Compaq with a
Smartmodem 2400, and my local machine is a 248 with a Zenith 2400 modem.  My
problem is this: I need to be able to not only shut the server down on the
west coast (no problem there), but also shut the modem off remotely.  I've
tried writing the string ATS0=0 (disable autoanswer) to a file called
SHUT_UP.TXT, then writing to a batch file shut_up.bat the command COPY
SHUT_UP.TXT COM1: I then upload both files to the server, and issue the
kermit command remote host shut_up, which should copy ATS0=0 to com1: Well,
I've tried it locally, and the "server" echoes the command and replies "1
file(s) copied" so the copy is working right, only the modem doesn't come
out of autoanswer, and when I query ATS0? I get back a non-zero number (the
default).  I've also tried directing ATZ to the modem, with no success.  Yet
when I run the batch file on my machine, as well as the "server", it works
fine...

Any help?  (Please!?!)

[From jrd - The modem can be shut down (turning off auto-answer mode) by
first placing the modem in "command" mode with the Hayes " +++ " sequence
(with 1-second pause before and after) and then issuing the ATS0=0 command.
If Kermit is running as a server within a script then the above strings can
be sent to the modem with the OUTPUT command.  Asking DOS to send the command
while Kermit is running is not a good idea because DOS depends on modem lines
DSR and CTS being asserted before its i/o will succeed.  Try this script
example:

        <Kermit setup commands go here>
        Server          ; receipt of FIN command will exit Server mode
        pause 2         ; lead time for +++ sequence
        output +++
        pause 2         ; exit time for +++ sequence
        output ATS0=0\13 ; turn off auto-answer mode
        exit            ; exit Kermit

Seems like the right thing to do anyway.]

------------------------------

Date: 04 Mar 1988
From: [e-mail] (Gisbert W.Selke)
Subject: A Few Notes on MS-Kermit 2.30
Keywords: MS-DOS Kermit 2.30

     Here are a few observations on very minor problems with MS-Kermit 2.30
in the 08 Jan version. - I'm running it on a very close AT clone under DOS 3.3,
with *no* compatibility problems so far; but then again, I'm not sure that
there couldn't be compatibility trouble (DOS 3.3). - Anyway, here goes:

[From jrd - I use PC DOS 3.30 locally so any bugs are mine and not IBM's.]

(i) If a host application has written to line 25 of the PC screen by directly
addressing it, the mode line is turned off alright, as described in the manual.
However, a subsequent [clear screen[ sequence (ESC left-bracket 2 J) seems to
clear only lines 1 through 24; line 25 remains uncleared. This is somewhat
disturbing at times.

[From jrd - the bottom/status/25-th line is not part of the regular host
display unless the terminal kind is NONE. Some users employ that line for
host status and hot key legends and a normal screen erasure would be
unwanted.  It can be erased by placing the cursor there first, ESC
left-bracket 25 ; 0 H or the appropriate line number for other display
sizes. Btw, version 2.30/A will finally solve the mode line toggle (fossil
mode line) problem.]

(ii) Is there no way to get reverse blinking text? On our VT102 clones (ECMA
standard, to be exact), this works, but on a PC running Kermit, it doesn't.
(May be a hardware restriction?? I didn't find it in the manual, though.)

[From jrd - my EGA + high res color monitor respond to ESC left-bracket 5 m
as the reverse video signal and to ESC left-bracket 7 m as the inverse video
command. ESC left-bracket 5 ; 7 m will do both together. Kermit does do them
so they should appear on your monitor. Numbers in ESC left-bracket .. m are

    0 (or nothing): clear all attributes
    1: bold
    4: underline
    5: blink
    7: inverse video
    10: fast screen updating (not adjustable by host commands, for CGA only)
    30-37: foreground color = 30 plus sum of 1=red, 2=green, 4=blue
    40-47: background color             same

applied in the order received. Underline is inverse video on color monitors.]

(iii) Is the setting of the DOS errorlevel really working?? It is OK with
receiving files, but I seem to get a non-zero errorlevel on each and every
file transfer. - Note: I have a rather complicated script built along the lines
of your example in the manual (or wherever it was I saw it); stepwise checking
reveals that the error level seems to be set not due to script commands
(like [input xxx[) but during the file transfer proper.

[From jrd - that's a real bug. The code was written to behave properly but
last minute changes made the SEND command always report an error. This is
fixed in version 2.30/A which is in preparation.  Apologies to all.]

(iv) I have problems accessing the F11/F12 keys in combination with
shift/alt/ctrl. Part of this is probably due to the German keyboard adaptor
I use (not IBM's KEYB xx, something called KEY6000), but it occurs even without
any resident keyboard adaptor at all. (I'm not having other TSRs in memory,
either.)  Here is what SCANCHEK 4.0 (22 Jan 88) reports (in keeping with
Kermit's "show key"):

            with KEY6000                          without KEY6000
           "key name"    key ident              "key name"    key ident
F11         C-F12        \394                    A-H          \291
SF11        --- nothing ---                      --- nothing ---
CF11        A-,          \1331                   A-4          \1403
AF11        --- nothing ---                      (graphic)    \207
SCF11       A-,          \1843                   A-4          \1915
SAF11       --- nothing ---                      (graphic)    \207
CAF11       --- nothing ---                      (graphic)    \207
SCAF11      --- nothing ---                      (graphic)    \207

F12         *unknown*    \504                    A-J          \36
SF12        K            \75                     --- nothing ---
CF12        A-.          \1332                   A-5          \1404
AF12        --- nothing ---                      (graphic)    \207
SCF12       A-.          \1844                   A-5          \1916
SAF12       --- nothing ---                      (graphic)    \207
CAF12       --- nothing ---                      (graphic)    \207
SCAF12      --- nothing ---                      (graphic)    \207

The only key combinations with the "extended keyboard flag" were F11, CF11,
SCF11, and CF12, but only under KEY6000.

[From jrd - Hmmm. For the Enhanced keyboard the individual items making the
reported key code are:
scan codes F11, F12 = 133, 134; SF11, SF12 = 135, 136, CF11, CF12 = 137, 138,
AF11, AF12 = 139, 140 plus Enhanced kbd = 1024 plus Scancode = 256 plus Shift
= 2, Control = 4, Alt = 8. All in decimal notation. I don't have an Enhanced
kbd handy to check but something appears strangely, such as F12 showing as
\36. Could it be your keyboard differs from IBM's in some coding details?
Responses from other users would be appreciated.]

So, this sums it up (modulo typos); the "F11/F12" item is *not* meant as
something to worry anyone - I can easily survive without these fancy keys.
I just thought someone might be interested, or maybe encounter similar
problems.

Otherwise, Kermit is working just fine. It's a great thing to use, and we do
use it everyday. I haven't checked the TEK emulation yet, but I most
certainly will.  BTW: no strong feelings about overlaying or not.

\Gisbert

[From jrd - Right, one abstaining vote on the Tek erasure/overlay subject.
I'm counting the few which have arrived. Otherwise, Tek emulation will be
better in version 2.30/A.  Plus other nice additions are being tested now.
Thanks again for the information.]

------------------------------

End of Info-Kermit Digest
*************************
-------
 5-Apr-88 12:20:50-EST,24866;000000000000
Mail-From: SY.CHRISTINE created at  5-Apr-88 12:19:53
Date: Tue 5 Apr 88 12:19:53-EST
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #10
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 5 Apr 1988       Volume 7 : Number 10

Departments:

  ANNOUNCEMENTS -
        MS-DOS and C-Kermit Source Diskettes Now Available
        Okstate Kermit Distribution Updated
        Announcing C-Kermit 4E(070) for the Amiga
        Announcing XSEND, a Utility for MS-DOS Kermit

  PORTABLE IBM 370 KERMIT -
        More Updates for CMS Kermit
        TSO Kermit Problems
        MVS/TSO Kermit Packet Size Query (and Answer)

  MS-DOS KERMIT -
        Anybody Like a VT-202 Layout?
        Session Log Bug in MS-DOS Kermit 2.30
        Memory Resident Server
        IBM PS/2 60 Bug

  MACINTOSH KERMIT -
        MacKermit 9(36)b4 Parity Problem
        0.9(36)beta Versions of MacKermit
        Basic MacKermit Help
        MAC Kermit .936

  VAX/VMS KERMIT -
        Problems with Filenames in VAX/VMS Kermit
        VMS Kermit - Sending Filespecs
        VAX/VMS Kermit "SET LINE" Command?

  MISCELLANY -
        CPM Kermit Help
        RE: Setting Flow Control for EMACS in Kermit
        PROCOMM+'s Kermit Feature
        Question on NetBios
        KEASY.TEX

Send digest submissions to Info-Kermit@CU20B, requests for addition to or
deletion from the Info-Kermit subscriber list to Info-Kermit-Request@CU20B.

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host CU20B, CU20B.COLUMBIA.EDU, or
CU20B.CC.COLUMBIA.EDU (a DECSYSTEM-20), as user ANONYMOUS, using any password,
and GET the desired files from logical device KER:.  You can also get Kermit
files over BITNET/EARN; to get started send a message with text HELP to
KERMSRV, the Kermit file server, at host CUVMA.  For detailed instructions,
read the file KER:AANETW.HLP (AANETW HLP on KERMSRV).  To order by mail,
request a complete list of Kermit versions and an order form from Kermit
Distribution, Columbia University Center for Computing Activities, 612 West
115th Street, New York, NY 10025 USA.

----------------------------------------------------------------------

Date: Thu 24 Mar 88 12:23:36-EST
From: Christine M Gianone <[e-mail]>
Subject: MS-DOS and C-Kermit Source Diskettes Now Available
Keywords: MS-DOS Kermit 2.30, C-Kermit 4E(070)

By popular demand, source diskettes for MS-DOS Kermit version 2.30, and UNIX
Kermit version 4E(070) are now available from Columbia University Center for
Computing Activities Kermit Distribution.

A set of four IBM PC MS-DOS 360K diskettes contains the source files for
MS-DOS Kermit, for the IBM PC and PS/2 families and compatibles.  A $50 fee
is charged for the source diskettes with the MS-DOS Kermit User Guide.
Please specify MS-DOS Kermit Source Diskettes when ordering.

A set of two IBM PC MS-DOS 360K diskettes contains the source files for the
UNIX version of C-Kermit, which can be built for many different UNIX
systems, including Berkeley, AT&T, Xenix, etc.  A $30 fee is charged for the
source diskettes with the C-Kermit User Guide.  Please specify C-Kermit
Source Diskettes when ordering.

We are also looking into providing Kermit programs in other formats.  Here's
a question I hope someone can answer: Is DEC's new diskette drive, the RX33,
able to read diskettes written (by the same operating system, VMS or Ultrix)
on an RX50?

Here's another question: Can Micro-PDP11's read TK50 tape cartridges written
on a MicroVAX with VMS?  In what format?  Will TK70 drives be able to read
TK50 tapes?

------------------------------

Date: Fri, 25 Mar 88 08:18:12 -0600
From: Mark Vasoll <[e-mail]>
Subject: Okstate Kermit Distribution Updated
Keywords: Okstate

I just received and installed a new set of Kermit tapes from Columbia.  All
the latest versions should now be available via our UUCP and Kermit server
service.

Mark Vasoll
Computing and Information Sciences   Internet:  [e-mail]
Oklahoma State University            UUCP:  {cbosgd, ihnp4,
Stillwater, Oklahoma                         rutgers}!okstate!vasoll

------------------------------

Date: Tue, 29 Mar 88 14:38:49 PST
From: [e-mail]  (Stephen Walton)
Subject: Announcing C-Kermit 4E(070) for the Amiga
Keywords: Amiga Kermit, C-Kermit
X-Ref: Commodore Amiga, See Amiga

Enclosed is a shell archive containing the following files:

    ckiker.bwr--A new version, with my comments on the end.
    ckiker.boo--A BOO file for C Kermit on the Amiga.
    Makefile--A makefile for the Amiga under Aztec C.
    diffs--The context diffs to convert CKI*.C to the new versions.
    msb_diffs--Context diffs which I applied to make msbpct.c and
           msbmkb.c work on the Amiga.

I hope all of this is useful to somebody.

                Steve Walton, 29-Mar-88
                Dept. of Physics & Astronomy
                Cal State, Northridge
                18111 Nordhoff St.
                Northridge, CA 91330

Email to: [e-mail] (will forward)

[Ed. - Thanks, Steve!  The entire shell archive has been added, for now,
to CKIKER.UPD, and the changes will be applied to the next release of
C-Kermit.  In case you're wondering what this does for Amiga users, the
major change since the last Amiga release is the addition of long packets.]

------------------------------

Date: Wed 30 Mar 1988 21:04:24 CST
From: Mark S. Zinzow <[e-mail]>
Subject: Announcing XSEND, a Utility for MS-DOS Kermit
Keywords: XSEND, MS-DOS Kermit

Enclosed is a copy of XSEND.C, a program to generate TAKE (script) files for
MS-DOS Kermit to allow it to send files and directories to a server over entire
tree branches or disks.  This version generates commands with absolute path
names, and therefore works only between two MS-DOS systems

Perhaps a useful extension might include passing arguments for remote and
local prefix strings to allow relative paths (e.g. ".") or drive letters
etc.  Suggestions for simple and easy to use command syntax are welcome.

The program compiles with Turbo C and Microsoft C, and possibly others.

[Ed. - Thanks, Mark!  Your program has been added to the Kermit distribution
as MSIXSE.*, including the C source program, a .BOO file based on a Microsoft
C 5.0 compilation, and some help text.]

------------------------------

Date: Mon, 1988 Apr 4   16:42 EDT
From: (John F. Chandler)   [e-mail]
Subject: More Updates for CMS Kermit
Keywords: CMS Kermit

I have sent new versions of IKCKER.BWR & IKCKER.UPD, noting and correcting
numerous minor problems in CMS Kermit-370 4.0.

                                        John

[Ed. - Thanks, John!  The files are now available in the Kermit distribution.]

------------------------------

Date: Thu, 1988 Mar 24   13:01 EST
From: (John F. Chandler)   [e-mail]
Subject: TSO Kermit Problems
Keywords: TSO Kermit

Concerning the new Kermit for TSO: a few bug reports have come in, and
fixes are in the works.

1. Uploading a member of an existing PDS will force the DCB attributes of
   the PDS to whatever Kermit-TSO has for FILE parameters.  A workaround
   is to SET APPEND ON while uploading members.
2. HELP cannot be invoked twice within the same Kermit session.  More
   generally, TSO commands may leave datasets marked "in use" so that
   they are unavailable for further processing.
3. The DIR subcommand is uninterruptible.  The same is true of any
   TSO command invoked from Kermit which doesn't issue a STAX.  If you
   hit BREAK enough times, though, you can get back to the TMP.
4. Kermit may hang when entering protocol mode over a protocol
   emulator if the screen is already full.  A workaround is to clear
   screen by hand.
5. There are rumors that this version won't work for TTY lines through
   VTAM.  If this is true, a temporary workaround might be to issue a
   SET CON FULL by hand (or that might not work either).  In any case,
   if there is any confirmation of the rumors, I'd like to hear the
   details, and I have two possible fixes ready, just in case.
6. If you invoke a non-existant TSO command from Kermit, there will
   be a sub-task ABEND and a READY message.  Just type a carriage return
   to resume Kermit operation.

The fixes for items 1-4 should be out shortly (in IKTKER.UPD).

------------------------------

Date: Wed, 30 Mar 88 09:22:32 SET
From: Peter Bodifee <ESC1467@ESOC>
Subject: MVS/TSO Kermit Packet Size Query
Keywords: MVS/TSO Kermit, Kermit Protocol

Re: Info-Kermit Digest, V7 #8:

After reading the new possibilities of the latest MVS kermit, the following
question popped up.

Why is the maximum receive packet size in Kermit TSO version 1.00 (via 7171)
limited to 60 ? Is this because there is a hardware limitation in the 7171
(that is what I have been told, but I have some strong indications against it)?
The documentation I have on the 7171 does not give me any information in the
input/output buffer sizes.

Any help in this direction will be greatly appreciated.

Regards, Peter Bodifee
          ESA/European Space Operation Centre
          Darmstadt, West Germany
          BITNET:  ESC1467@ESOC
          phone  [phone]

[Reply From John Chandler, author of IBM mainframe Kermit 4.0: Early versions
of the 7171 had an input buffer of only 64 bytes or so.  If a micro Kermit
tried sending packets longer than that, nothing could get through.  As a matter
of fact, I believe the buffer is still fairly small, but the 7171 code performs
flow control so that it can keep up with any packet size from the micro.  Both
the CMS and TSO Kermits used to have a packet size default of 60 for SERIES1
mode, but release 4.0 of Kermit-370 has removed that convention (for both CMS
and TSO).  An informal poll conducted last fall (in the form of a query
broadcast to all subscribers of the BITNET IBM7171 discussion group) failed to
turn up any known 7171's which still need the 60-byte packet limit.]

------------------------------

Date: Wed, 23 Mar 88 13:26 MEZ
From: "Eberhard W. Lisse" <[e-mail]>
Subject: Anybody Like a VT-202 Layout?
Keywords: MS-DOS Kermit 2.30, VT-202 Setup, Terminal Emulation

We hacked up a vt202 layout which runs TPU and I felt I should beam it over
right away. (Well before I leave the Burn Unit anyway ...)

regards, el

Eberhard W. Lisse, MD
Burn Unit, Technical University, Aachen, West Germany

[Ed. - Thanks, el!  (VT202?) Since people tend to send in lots of these
special- purpose .INI files, we've decided to collect them all into a single
file, MSIIBM.HLP, and yours is will be at the top.]

------------------------------

Date:  4 Apr 88 20:56 +0100
From: Harald Hanche-Olsen <[e-mail]>
Subject: Session Log Bug in MS-DOS Kermit 2.30
Keywords: MS-DOS Kermit 2.30, Session Log

The command 'log session foo.bar' seems to work OK except in the case
when foo.bar exists but is empty (that is, it has zero bytes in it).
In this special case, nothing is appended to the file, and the session
log is lost.

An empty file is easily created by Kermit itself, if you follow the
command 'log session foo.bar' immediately by a 'close' command.  This
is how I happened to create an empty file and subsequently got burnt.
Ouch!

[Ed. - This is obviously a bug that needs fixing...]

------------------------------

Date: Fri, 04 Mar 88 11:21:42 CST
From: Arlene Slocum <[e-mail]>
Subject: Memory Resident Server
Keywords: MS-DOS Kermit 2.30

Is there such a thing as server mode only of Kermit that stays memory resident
and checks the serial port for file transfer requests?  We are running version
2.30 Columbia Kermit at 9600 baud over an x.25 network on IBMPC XT compatibles.
We would like a background server capability that is compatible with Kermit and
lets PC users do other work.

Arlene Slocum, Programmer/analyst
Institute for Public Policy and business Research
University of Kansas
607 Blake
Lawrence, Kansas  66045
913-864-3701
send replies to my bitnet address: ARLENE@UKANVM

[Ed. - Currently no.  There is a Microsoft Windows version of Kermit, capable
of background operation, but it doesn't have the ability to act as a server.
MS-Kermit 2.30 can act as a server, but has no particular ability to operate
in the background.]

------------------------------

Date: Thu, 24 Mar 88 11:20:45 DNT
From: <[e-mail]>
Subject: IBM PS/2 60 Bug
Keywords: IBM PS/2

The IBM PS/2 60 does have a bug. The local IBM-people should know about the
system time problem, and if they don't, tell them to ask the Danish IBM-team.
We had the same problem here, until some patch-code in the CONFIG.SYS was
installed by an IBM'er.

                       Niels Kristian Jensen.

[Ed. - This is in response to the query from Stephen Walton in V7 #9 about
not being to boot the model 60 after running Kermit...]

------------------------------

Date: Wed, 2 Mar 88 12:44:41-1000
From: [e-mail] (David Lassner)
Subject: MacKermit 9(36)b4 Parity Problem
Keywords: MacKermit 0.9(36)b4

Is anyone using MacKermit 9(36)b4 successfully with a host that requires
even parity?  We can't get it to work with ours.

David Lassner, University of Hawaii Computing Center
[e-mail]     [e-mail]

[Ed. - The parity bug will be fixed in the "real" release, coming soon.]

------------------------------

Date: Tue, 23 Feb 88 11:43:57 EST
From: [e-mail]
Subject: 0.9(36)beta Versions of MacKermit
Keywords: MacKermit 0.9(36)

I have been using the 0.9(36)b3 version of Kermit for several weeks.
It works very well under Multifinder, although not as a multitasking
application.  I used getinfo to set the size to 128K.  (I don't know
what a MacII size should be).  The only anomalies I have found are that
downloaded files often don't show up with the correct size until opened
from another application and that window update gets confused about whether
text should be bold or not.

On Feb 1, 1988 I downloaded the 0.9(36)b4 version of Kermit from the
University of Toledo server (CKM936.HQX).  This version will set EVEN parity
in the Communications dialog box, will save the setting to a file, will
restore this setting under LOAD settings, but unfortunately will not
set the Mac serial port to even parity.  Persons using an IBM 7171 protocol
converter will not be able to use this version.  It may be useful to make
the 0.9(36)b3 version available until this problem can be resolved.

I have terminal tables for use with a 7171 protocol converter for the four
common Mac keyboards, including the old numeric keypad.  Documentation is in
the form of MacDraw files.  I would be happy to .sit them and send them for
distribution if there is interest and if someone can tell me where they should
be sent.

Thanks to everyone who has worked on the Macintoh versions.  0.8(34) works
today.  There aren't many programs of that vintage thay can make that claim.

[Ed. - Any day now, we'll have a new release that fixes the parity bug,
and is not a step backward.]

------------------------------

Date: Wed, 24 Feb 88 21:41:56 PST
From: Dennis Mar <[e-mail]>
Subject: Basic MacKermit Help
Keywords: MacKermit

Greetings far-flung correspondents:  thank you for your kind offers
of advice.

We operate an IBM3033 with VM/CMS.  In November the Kermit release
was upgraded from 2.01 to 3.1.

A MacIntosh SE users says "the difficulty apparently lies between
Red Rider 10.3 and the mainframe KERMIT.  I set the KERMIT carrot-Q
handshake.  However I fell that there may be other parameters that
need to be set.

  1. Is Red Ryder's SEND/RECEIVE Kermit compatible with Release 3.1?
  2. What are the parameter settings required?
  3. Are there more mainframe Kermit commands required than in the past?"

Any advice or direction to the appropriate documentation would be most
appreciated.

------------------------------

Date: 1 Apr 88 16:56:52 GMT
From: [e-mail] (Frank Simmons)
Subject: MAC Kermit .936
Keywords: MacKermit

 Has anyone discovered how to send a break with the latest version of
 MacKermit?

[Ed. - The new release will include a manual!]

------------------------------

Date: 21 Mar 88 09:20:00 CST
From: "NTVAXB::JAMES" <[e-mail]>
Subject: Problems with Filenames in VAX/VMS Kermit
Keywords: VAX/VMS Kermit

I have a user with a peculiar problem.  When he tries to SEND a file from
VAX Kermit by giving its full file specification, VAX Kermit bombs saying
it couldn't find the file.  Example :

Kermit-32> SEND DUA1:[PUBLIC]NETWORKS.DOC
(now it waits, as it should)
(I get back to local kermit and type RECEIVE)
(and it fails because it could not find file "NETWORKS.DO")
(I CONNECT back to VAX Kermit and do : )
Kermit-32> STATUS
....
Last error : File not found for DUA1:[PUBLIC]NETWORKS.DO

Apparently the VAX KERMIT loses the last character of the filename somewhere
along the line.  This only occurs when a drive or directory name is specified.
Any ideas on this one ?

We are using version 3.3.111...

At any rate, I was wondering when a new version of VMS Kermit could be
expected.  I have thoroughly enjoyed the new MS-DOS version, and would
love to see a new version of the VMS...

James Shoffit                  BitNet: JAMES@NTSUVAX  (POSTMAST@NTSUVAX)
Vax Programmer/Operator        THENET: NTVAXB::JAMES  (NTVAXB::POSTMASTER)
Postmaster for NTSUVAX.BITNET  Inter : [e-mail]
North Texas State University        or [e-mail]
Denton, Texas  76203

[Ed. - Unfortunately...  it looks as if Kermit-32 has some kind of fixed-
length buffer for filenames, or some other kind of limitation or bug.  And
there's not much chance of getting it fixed, since the original authors have
all left Stevens Institute of Technology, and no one else has come forward
to take over responsibility for the program -- small wonder, since it's written
in Bliss-32, a language found almost nowhere.  Meanwhile, much-improved VMS
support is being added to C-Kermit, and there should be an announcement some
time in the not-too-distant future.]

------------------------------

Date: Fri, 4 Mar 88 17:41 EDT
From: <[e-mail]>
Subject: VMS Kermit - Sending Filespecs
Keywords: VAX/VMS Kermit

Is the following a known bug of VMS Kermit?

Kermit-32>set file naming untranslated
Kermit-32>send *.*
Sending: DQA0:[MIKE]SCARLETBEGONIAS.TXT;23 as SCARLETBEGONIAS.TXT [OK]
Sending: DQA0:[MIKE]FIREMOUNTAIN.TXT;1T;23 as FIREMOUNTAIN.TXT [OK]
Sending: DQA0:[MIKE]STSTEPHEN.TXT;15;1T;23 as STSTEPHEN.TXT [OK]

The files get sent [OK], but that initial filespec gets annoying...

Mike Rego  <[e-mail]>

------------------------------

Date: Thu, 31 Mar 88 15:37:33 EST
From: [e-mail] (David Kobus)
Subject: VAX/VMS Kermit "SET LINE" Command?
Keywords: VAX/VMS Kermit

When trying to use the VAX/VMS "set line" command on KERMIT, I encounter a
"no privilege for attempted operation".  Does anybody know what VAX/VMS
category privilege (e.g. netmbx,share) I must allow a user to enable the
terminal line to be accessible to the user's processes?

(later...)

1.Upon trial and error, it appears that the "READALL" privilege category is
  the least dangerous privilege that you can authorize a user running on a
  MicroVAX II VMS system in order to permit a KERMIT SET LINE command to be
  issued.
2.I invite verification from the VMS KERMIT community.

  David B. Kobus
  Naval Air Development Center

------------------------------

Date: Tue, 23 Feb 88 16:21:52 MST
From: [e-mail] (Richard Travsky)
Subject: CPM Kermit Help
Keywords: CPM Kermit

Hi -
  I don't know if you can help me with this or not.

  I and and few others in my department own Kaypro 2X's.  We have a CPM
version of Kermit that we got through the BITNET KERMSRV.  It works fine
file transfer wise.  It has a VT52 emulation mode that doesn't work too well
on the 2X.  Since we recently acquired a pair of VAX 8800s, this emulation
feature is now of more concern to us.  Is there a CPM Kermit version more
suitable for the 2X?  The Kermsrv index is huge and it is hard to tell what
file is what.

  We'll be eternally grateful for any help you could give.

Rich Travsky
Computer Services
[e-mail]    (or [e-mail])

[Ed. - No, there's nothing specific for the 2X.  You're more than welcome
to add support for it to CP/M Kermit yourself!  (Or if anyone else has already
done so, please speak up!]

------------------------------

Date: Sun, 6 Mar 88 12:27:46 EST
From: [e-mail] (Jeff Siegal)
Subject: RE: Setting Flow Control for EMACS in Kermit
Keywords: Flow Control, XON/XOFF

Re: Info-Kermit Digest V7 #7

>[Ed. - The real, though painful, workaround is to SET FLOW NONE before you
>start EMACS, and SET FLOW XON/XOFF when you exit EMACS, see below.]

How about some escape sequence the host can send to Kermit to turn
flow-control on and off.  Emacs (GNU Emacs anyway) can be configured
to send such a sequence when entering or exiting.

Jeff Siegal

[Ed. - Unfortunately, the DEC VT102 does not support such a sequence,
and it's often a bad idea to make up new sequences for terminal emulators,
as they may conflict with other new sequences that other people make up.]

------------------------------

Date: Tue, 23 Feb 88 08:35:53 PST
From: [e-mail]
Subject: PROCOMM+'s Kermit Feature
Keywords: PROCOMM+

A user at our site has recently solved a problem that has been annoying him
for sometime.  The user uses PROCOMM+ to log on to the Unix mainframe from
home, and loves this product.  However, he has never got its inbuilt kermit
protocol to work correctly.  He recently figured out, however, that if he
resets the communications parameters to N-8-1 in mid-session, although
normal unix prompts etc. go gahgah, kermit then works fine.  Therefore, he
changes the parameters for kermit use and then back again when he exits
kermit and everything works fine.  Do you think this means there is some
misset parameter in our kermit installation?  Any other theories?  The user
uses E-7-1 for normal unix purposes.

Thanks for any help in this matter.

                        Bob Rendler [e-mail]

[Ed. - Many UNIX systems use parity by default, typically even.  When you
run Kermit on the PC, you don't notice this because Kermit strips the parity
bit during terminal emulation by default (you can override this with SET
DISPLAY 8).  However, UNIX Kermit does NOT use parity during file transfer --
it puts the communication line into 8-bit "raw" (binary) mode during packet
operations.  Apparently Procomm does not provide a way, as MS-Kermit does,
to do "no parity" but also to strip the high-order bit during terminal
connection.]

------------------------------

Date: Mon, 14 Mar 88 22:17 PST
From: CARL FUSSELL <[e-mail]>
Subject: Question on NetBios
Keywords: NetBios

I am looking for information on Net Bios.  Can anyone suggest references
I might look at?   We were thinking about trying to coerce IBM PC
Kermit talk to our VAX (C-Kermit) over our ethernet.  Any opinions
or comments about the feasibility of this would be welcome.

Thanx in advance...

Carl Fussell
Santa Clara Univ
[e-mail]

------------------------------

Date: Mon, 14 Mar 88 16:55 EDT
From: Ted Nieland - SRL <@WPAFB-AAMRL.ARPA:TNIELAND@FALCON>
Subject: KEASY.TEX
Keywords: KEASY.TEX

I just FTPed KEASY.TEX from CU20B, but I am getting many errors when I run it
through LaTeX.  Does KEASY require a special STY file?  Is anyone else having
problems with KEASY.TEX?

Ted Nieland

[Ed. - We received several complaints like this.  Has anybody succeeded in
running it thru TeX?  Directions, fixes, would be appreciated.]

------------------------------

End of Info-Kermit Digest
*************************
-------
25-Apr-88 15:56:10-EDT,23869;000000000000
Mail-From: SY.CHRISTINE created at 25-Apr-88 15:53:46
Date: Mon 25 Apr 88 15:53:45-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #11
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Mon, 25 Apr 1988       Volume 7 : Number 11

  ANNOUNCEMENTS -
        Announcing Version 2.31-test4 of IBM PC Kermit
        New Sliding Windows Kermit for the IBM PC
        Announcing Commodore 64/128 Kermit Version 2.1(68)
        Announcing a Version of Kermit for MAI Basic Four (MBF) Minis
        C-Kermit 4E(070) Diffs for Apple Mac II's A/UX
        Masscomp C-Kermit Fixes for RTU 4.0b
        Fixes for C-Kermit 4E(70) for VMS

Send digest submissions to Info-Kermit@CU20B, requests for addition to or
deletion from the Info-Kermit subscriber list to Info-Kermit-Request@CU20B.

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host CU20B, CU20B.COLUMBIA.EDU, or
CU20B.CC.COLUMBIA.EDU (a DECSYSTEM-20), as user ANONYMOUS, using any password,
and GET the desired files from logical device KER:.  You can also get Kermit
files over BITNET/EARN; to get started send a message with text HELP to
KERMSRV, the Kermit file server, at host CUVMA.  For detailed instructions,
read the file KER:AANETW.HLP (AANETW HLP on KERMSRV).  To order by mail,
request a complete list of Kermit versions and an order form from Kermit
Distribution, Columbia University Center for Computing Activities, 612 West
115th Street, New York, NY 10025 USA.

----------------------------------------------------------------------

Date:     Thu, 21 Apr 88 21:31 MDT
From:     <[e-mail]> (Joe Doupnik)
Subject:  Announcing Version 2.31-test4 of IBM PC Kermit
Keywords: MS-DOS Kermit 2.31, IBM PC Kermit

A new version of MS Kermit is available for testing on IBM PC's and
compatibles.  It is labelled 2.31-test4.  It is an early "alpha test" of the
next release, 2.31, for which a release date can't even be estimated.  Until
then matters are subject to change, but what is present now is most unlikely
to be withdrawn.

Items of interest beyond 2.30 (a subset):

1. Selection of a serial port has been extended to permit specification of
Bios level interaction with Kermit rather than letting Kermit go directly
to the port hardware. The commands are

        SET PORT BIOSn (n = 1 to 4)     for Bios interaction
and
        SET PORT COMn (n = 1 - 4)       for Hardware interaction
and
        SET PORT NET host-name          for NetBios interaction

The Bios spec is present specifically to support networks which intercept the
normal Bios serial port interrupt 14H.  Kermit expects registers to be used
exactly like the IBM Bios, and i/o is not interrupt driven.  If there are
problems I am most interested in fixing them post haste.

Further, when the serial port hardware UART is employed the interrupt
request line (IRQ) parameter is now obtained automatically by Kermit so
that the IRQ may be 3 or 4 for different ports, as the user sees fit.
Previously, IRQ had to be 4,3,4,3 for COM1-4; now PS/2's with 4,3,3,3
should work automatically. An arcane detail, to be sure, but in the past
one causing much user frustration.

Until now MS Kermit checked the Bios work area for port info even if the BIOS
were used for comms.  Since various LAN mfrs do an intercept it could happen
that they leave COM1 and COM2 intact and grab COM3, so to speak. If there were
no hardware for COM3 the Bios work word would be empty, more often than not,
and port 3 would be unusable even for networking. This version skips checking
up on matters if the Bios is chosen (voluntarily by SET PORT BIOSn, or
automatically be lack of a suitable UART chip). Thus, networking intercepts
can be shuffled down to BIOS3 or BIOS4 to free the real serial ports.  The
consequence of selecting BIOSn when there is nothing there is to read lots of
echos of our own characters, harmlessly.

2. File attributes packets are available to transfer the size, creation time
and date of a file to cooperating hosts.  Few Kermits implement attributes
packets but the new IBM CMS Kermit and the PDP-11 Kermits do so.  C-Kermit
will support them in the near future.  Two new commands result from attributes
packets:

        SET ATTRIBUTES ON | OFF         (default is ON)

to suppress attribute negotiations if the host might be confused by them, and

        MAIL filename username@host

MAIL is exactly the same as a SEND command except the file attributes packet
requests the host submit the file to the local Mail utility with the indicated
addressing (can include spaces) rather than store the file on disk.
Presently, the command is unique to MS Kermit; expect selected C-Kermit
support in the near future.  MAIL will fail right away (without sending the
file) if the remote host cannot understand the request.

3. A Transaction log is available to record the filename, direction of
transfer, size, starting time, date, and final status of each regular file
exchange.  The log entry is a terse two line description ready for printing or
automated processing.

        LOG TRANSACTION <optional filename, TRANSACT.LOG is the default>

turns on this logging,

        CLOSE TRANSACTION

turns it off, and

        SHOW LOG

indicates the status of logging.  Material is alway appended to log files to
prevent losing older information.  Similarly, there are separate SESSION
(Connect mode) and PACKET log files.

4. Kermit can be operated directly from DOS files, such as

        KERMIT < todo.lst
or      Preprocessor | Kermit

These files or pipes contain the same information as would be typed by hand,
yet Kermit knows a file is being read and will exit to DOS when the file
becomes empty (it will not hang waiting for keystrokes which never arrive).
Kermit TAKE files can be run this way if desired.

5. The command parser permits definition and use of Kermit "variables" such
as \%1, \%2 and so on.  Variables have names of backslash, percent sign,
character '0' and above (with upper and lower cases merged).  Variables are
defined as Macros of that name and the definition can be any string.  Such
strings can contain other variable names.  These variables substitute the
definition text for their name.  For example

        DEFINE dial AT\13,input OK,pause,output ATDT \%1,inp CONNECT, Connect
        DO dial 1-800-555-1212

places the word "1-800-555-1212" in variable \%1 and that text appears
in the Hayes ATDT command during dialing.

Thus, variables \%1,..\%9 are automatically defined by adding words after
the macro name in the DO command, much like command line arguments to
programs or Batch files.

Other variables are defined by the DEFINE <macro name> <mac definition>
command, as usual. Of note is that when a variable name appears in a Kermit
command it is immediately replaced by its definition; if the definition
contains other variables they are also expanded immediately.  No definition
is the same as a null length string.

        DEF test echo first \%1, second \%2, third \%3,
        DEF \%e  echo first \%1, second \%2, third \%3,

yield the same display, via

        DO test word word word
or      DO \%e this that another
or      \%e foo bar bletch

Macros can be displayed by SHOW MACRO <optional mac name abbreviation>.

6. The Tektronix 4010 emulator has been improved and made more like a real
Tek 4010 terminal. The user may allow Kermit to select the active graphics
display adapter (default) or may override that choice via the command

        SET TERMINAL GRAPHICS Auto-sensing | CGA | EGA | VGA | HERCULES | ATT

ATT includes Olivetti M24/M28/DEC VAXmate/Toshiba T3100/AT&T 6300/6300+.
VGA invokes a 640x480 dot color display but the bottom 79 lines are not
saved due to display adapter memory limits.

7. Screen scrolling in the VT102 emulator has been improved twenty fold for
the case where top and bottom display lines do not scroll. Emacs and many
applications scroll interior lines; this version should do so much faster.
Whole screen scrolling is limited by the display adapter board rather than
Kermit.

8. Error messages have been improved to be more helpful. For example,
typing the command

        Kermit-MS> SAT Timer on

shows the message '?Word "SAT" is not usable here', and

        Kermit-MS> SET Timer on and off and maybe on the table

does indeed Set Timer ON and also shows the message

        ?Ignoring extra characters "and off and maybe on the table"

And so forth.  After all, if the machine knows when an error has been made
then maybe it can fix the safe kind without bothering people.

9. The general screen status display is still present but has been supplemented
by a number of individual "SHOW keyword" displays to assist finding things.
SHOW ? indicates all the current keywords for this command.  Command STATUS
gives a screenful of the most interesting things.  SHOW is under active
development to find decent groupings and display formats.

10. The Kermit command line interface now permits full 8-bit character inputs,
with only NUL, ESC, DEL/BS, ^W (delete word), ^U (delete line), and ^C being
special.  This is to enhance support for various languages and keyboards.

11. A new Kermit verb for Connect mode is \Kholdscrn which acts like the
DEC VT10x Hold Screen key: display is suspended immediately by ignoring
new characters (depends on flow control at the serial port level to XOFF
a chatty host). This verb is not assigned to a key presently. It is a toggle
and is cleared by resetting the terminal (\Kreset, ALT =).

12. The VT102 emulator supports the escape sequence pair ESC [ 1 2 h/l to
control local echoing of outgoing material. ANSI spec.

13. The VT102 "25th" line, or status line, is under better control in that
a fossil of the line (written by the host) does not appear unexpectedly.
The status display indicates when the line is on and owned by the host.

14. Another networking item is that files opened read-only now have the DOS
DENY-NONE bit set so that competing tasks may access them simultaneously,
such as when they are run by Pushing or RUN within Kermit.

15. The command SPACE no longer requires presence of CHKDSK.COM. The disk
space calculation is done internally. Empty disk drives yield a nice message.

16. Script commands have been enhanced. A new command is

        WAIT [timeout] \CD | \CTS | \DSR

        WAIT 04:15 \CD\DSR      ; wait for carrier detect and modem ready

to wait for the presence of one or more of these modem signals, or fail with
a timeout.
Commands WAIT, PAUSE, INPUT accept timeouts of seconds and now HH:MM:SS
(truncate from the right but leave at least one colon) which means essentially
"until" that time of day (24 hour clock). The hh:mm:ss must be less that
12 hours from the present so the software can distinguish early from late. A
carriage return will force a timeout, to avoid rebooting a somnolent machine.

17. If a host echoes our XOFF Kermit now detects the situation and ignores
the arriving XOFF. Also, while waiting for the host to send XON Kermit tests
new characters at a rapid rate to improve response time.

18. CD is now a synomym for CWD (and for SET DEFAULT).

19. PAUSE now stops pausing when characters are typed at the keyboard.
This allows you to put things like this into your script files:

    ECHO Type any character when ready
    PAUSE 1000

20. A HELP command was added -- nothing fancy, just enough to get users
started (memory is a consideration here).

21. Finally, MS Kermit works well under MicroSoft Windows. Previously, it
ran fine under Windows but was unable to show Connect mode material which
was voluntarily rolled back on-screen. Screen scrolling now works perfectly.
Tested on MS Windows 2.03 on AT's and MS Windows 386.

[Ed. - Thanks once again, Joe, for your tireless efforts.  The new test
version is now in the Kermit Distribution as MSTIBM.BOO, along with this
message, MSTIBM.HLP, which can serve, for now, as an addendum to the MS-DOS
Kermit User Guide.]

------------------------------

Date: Fri 15 Apr 88 16:06:45-EST
From: Frank da Cruz <[e-mail]>
Subject: New Sliding Windows Kermit for the IBM PC
Keywords: MS-DOS Kermit, Sliding Windows, BIX

This is to announce a version of Kermit for the IBM PC by Terje Mathisen of
Norsk Hydro Data, announced by him on BIX in November 87 (his BIX mail ID is
"terjem").  It's written in Turbo Pascal, and claims to include long packets
AND sliding windows, and a nonstandard "fast mode", in which data fields are
not encoded at all (it can only use this to talk to itself).  There is dumb
terminal emulation, which seems to take place only in a small horizontal
window under the command menu.

The source files arrived with nonstandard naming conventions, and have
therefore been packed into a single file, TP4KER.PAS, with name markers like
<<< KERMIT.PAS >>> at the head of each file.  The executable program is encoded
as TP4KER.BOO (which can be decoded back into TP4KER.EXE using any of the
MSBPCT programs).  There is no manual, but a very short summary is in
TP4KER.HLP.  Comments & reviews welcome, as would be results of testing the
long packet and sliding window features against other Kermit implementations
that have them.

------------------------------

Date: Mon, 18 Apr 88 00:54:48 -0500
From: [e-mail] (Ray Moody)
Subject: Announcing Commodore 64/128 Kermit Version 2.1(68)
Keywords: Commodore 64, C64

Commodore 64/128 Kermit Version 2.1 (68) is now available.  This new version
has many new features, improvements, and even some bug fixes.  Here are the
main new features/improvements/bug fixes:

 + Enhanced DEC VT-100 terminal emulation with  support  for
   the  VT-100  keypad.   Kermit  should  now  work  fine on
   operating systems such as  VMS.   V2.1  has  some  VT-102
   features added as well: Insert/Delete Line/Character.

 + Limited Tektronix 4010 graphics terminal emulation.  Ker-
   mit  can plot both graphics and text with a resolution of
   320 x 200 (C-64) or 640 x 200 (C-128).

 + Commodore 128 grey key and numeric keypad  support.   The
   grey keys and the numeric keypad, not normally accessible
   on a C-128 in C-64 mode, are active within Kermit.

 + A special file-type for transferring C Power  (now  Power
   C) source code files.  You can now download C source code
   ASCII files as well as upload C Power source files.   All
   necessary  character  translations  are handled automati-
   cally.

 + A screen driver  for  the  Batteries  Included  BI-80  80
   column  card.  This device gives a display as nice as the
   Commodore 128's 80-column hardware, but lacks many attri-
   butes such as blinking and bold.

In addition to these major improvements, many smaller changes were made.
Several bugs were squashed that affected VT-100 emulation, the STATUS
command, and other things.

Obtaining Kermit on a Floppy Disk:

A copy of Commodore Kermit may be obtained by sending $5.00 postage and
handling to:

                 Dr. Evil Laboratories
                 P.O. Box 190
                 St. Paul, IN 47272

We stress that Commodore Kermit is absolutely free, the $5.00 is only
used to cover the cost of the disk, the mailer, postage, and handling.  The
disk will contain Commo- dore Kermit version 2.1, a copy of the preliminary
documentation broken into several files small enough to be viewed with a
good wordprocessor, an initialization file, and, for C128 users, an autoboot
sector.  (All of the files on the disk are available for download from the
Kermit archives.  There is a program in the Kermit archives that will create
the proper autoboot sector for people that want to have one.)

Sometime this summer a final printed (and maybe even bound) version of
the manual will be available at a reasonable cost.  Stay tuned.

Also available from Dr. Evil Laboratories is a custom ROM for the
Batteries Included 80-column card that provides access to the entire ASCII
character set.  Currently we ask $5.00 for the custom ROM.  This price is
subject to change and installation is required.

Dr. Evil Laboratories is a small software company in which Kent and I
are partners.  The company has the facili- ties to distribute Kermit much
more efficiently than either of us could personally.  Also, Dr. Evil Labs
has a permanent address, something that we, being in college, don't have.

All orders to Dr. Evil Laboratories must be in U.S. funds.  Indiana
residents must add 5% sales tax.

Kermit can also be downloaded from the Kermit archives on ARPANET,
BITNET, and other places.  For complete downloading instructions, see the
file KER:AANETW.HLP.

                           Ray Moody
                            [e-mail]
                            ihnp4!pur-ee!j.cc.purdue.edu!ray
                            [e-mail]

                           Kent Sullivan
                            Qlink: corvairkid

The files are as follows:

        c64ker.ann      - announcement of new kermit
        c64ker.hlp      - how to download from cu20b.  How to get 1541 disk
        c64ker.doc      - documentation (a total rewrite of the old docs)
        c64ker.hex      - the downloadable binary itself
        c64ker.m65      - source code.  Too big to mail, so split into parts
        c64ker.rom      - replacement character rom for BI-80 80-column card
        c64ker.ini      - program to create kermit.ini file
        c64auto.bas     - program to create an autoboot sector


[Ed. - Thanks Ray.  The files have been updated as you suggested.  The new
files have replaced the old ones in KER:C64*.*]

------------------------------

Date: Thur 07 Apr 88 14:31:00-PDT
From: Edward V. Wastrodowski, Sphere Holdings Limited (SHL)
Subject: Announcing a Version of Kermit for MAI Basic Four (MBF) Minis
Keywords: MAI, Basic Four

This is to announce the availablity of Kermit for the MAI Basic Four
minicomputers, series model numbers 7000,8000, and 9000; it is
written using the latest release of BOSS/VS Business Basic (tm)
called BB86.

[Ed. - Thanks for putting this together and sending it to us on tape.
It has been installed in the Kermit Distribution as MBF*.*, and available
by mail order on Tape D.  Also included is a short Basic program to read
ANSI-D format tapes (like the ones we distribute Kermit on).]

------------------------------

Date: Thu, 07 Apr 88 15:57:22 PST
Subject: C-Kermit 4E(070) Diffs for Apple Mac II's A/UX
From: Marion Hakanson <[e-mail]>
Keywords: C-Kermit, Macintosh A/UX, A/UX

Below are the changes necessary to make C-Kermit 4E(070) compile and run
properly on an Apple Mac II running A/UX (Apple's Unix).  A/UX is mostly
System V, but with BSD compatibility grafted on in some rather unique ways.
Here is a short description of the changes I made (quite minor, really).

ckuker.mak:     Add an "aux" target, which is identical to the "sys3"
                target with an added "-DAUX" flag.  See below.

ckufio.c:       Near the top, in a #ifdef UXIII/#endif pair, is a
                #define MAXNAMLEN DIRSIZ.  Apparently A/UX has its own
                MAXNAMLEN definition, so surrounding the above #define
                in #ifndef MAXNAMLEN/#endif takes care of that problem
                in a "portable" manner.

ckutio.c:       I really wanted to avoid adding an AUX flag, but this
                is quite unique (i.e. "strange").  A/UX has SIGTSTP,
                so the job-control code in C-Kermit gets compiled in
                properly, but C-Kermit expects 4.2bsd signal semantics
                when this happens.  The easiest workaround seems to be
                to add to sysinit() a call to A/UX's set42sig() library
                routine, which enables BSD-style reliable signals, along
                with the corresponding TTY job control.  In other words,
                it allows C-Kermit to be suspended with ^Z and restarted
                with "fg" from the C-shell, instead of being killed when
                you try to restart it.

The only other trick I had to discover to use C-Kermit was that you may need
to "set line /dev/modem" (and not tty0) to use the modem port.  Note that
I'm communicating with a hard-wired port selector, and not a "real" modem,
but modem control lines are used here (perhaps not the correct ones,
though).

Apple seems to distribute A/UX with C-Kermit 4E(066) installed in the
/usr/bin directory (this was the C-Kermit with the serious long packet bug),
and sources in /usr/src/kermit.  Other than a similar, but less portable
than mine, change to ckufio.c, I could detect no modifications they made to
the distribution 4E(066), which of course did NOT do the right thing with
Ctrl-Z, etc.

Please let me know if problems occur with these changes, or if other
modifications are indicated.  We've only had this A/UX system up for a
couple of days, and Kermit was a necessity for connecting it to something
other than itself.  Here are the patches:

[Ed. - Many thanks!  For now, your changes have been added to the CKUKER.BWR
file, and they will certainly be incorporated into the next release, which,
given the number of changes that have arrived in recent weeks, will have to
be pretty soon...]

------------------------------

Date: 15 Apr 88 13:59:27 GMT
From: dalesys%lamont.Columbia.edu@lamont (dale chayes)
Subject: Masscomp C-Kermit Fixes for RTU 4.0b
Keywords: Masscomp, RTU, C-Kermit

I have butchered the recent release of C-Kermit to accomodate the notion
of "dir.h" in the beta version of Masscomp's RTU (RTU-4.0.b1) operating system.
(For RTU-3.1, "make rtu" with the distributed sources works fine.)

I did it in a rather crude way. It would be more appropriate to make a new
entry in the makefile "rtu4" and use ifdefs, but that's not how it
happened.... (at least I put in some comments (:-))

Dale Chayes Lamont-Doherty Geological Observatory of Columbia University
usmail: Route 9W, Palisades, N.Y.  10964
voice:  [phone] extension 434    fax: [phone]
usnet:  ...philabs!lamont!dale

[Ed. - Thanks, Dale.  Your changes are in CKUKER.BWR for now, and should
find their way into the next release.  It sure would be nice if makers of
Unix systems could agree on where their header files go, and whether they
must be included or not...]

------------------------------

Date: Wed 20 Apr 88 15:42:14-PDT
From: Ted Shapin <[e-mail]>
Subject: Fixes for C-Kermit 4E(70) for VMS
To: [e-mail]
Phone: [phone]; Mail:Beckman Instruments, Inc.
Mail-addr: 2500 Harbor Blvd., X-11, Fullerton CA 92634

Here are some fixes for C-Kermit 4E(70) we made for our VAX VMS system.
The fixes are from Will Wood, Beckman Instruments, Fullerton, CA.

[Ed. - Listings omitted, but added to CKVKER.BWR, and forwarded to Jamie
Hanrahan, who's working on a new release of C-Kermit for VMS.  The fixes
include a more effective way of having the C-Kermit server log itself out when
it gets a BYE command, and a fix for the function that returns the current
default device:[directory], and some terminal i/o improvements.]

------------------------------

End of Info-Kermit Digest
*************************
-------
18-May-88 17:22:15-EDT,25678;000000000000
Mail-From: SY.CHRISTINE created at 18-May-88 17:21:17
Date: Wed 18 May 88 17:21:17-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #12
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 18 May 1988       Volume 7 : Number 12

Today's Topics:

                        Kermit News Articles Needed
              Announcing Version 4.09 of Kermit-80 for CP/M-80
                Announcing QK-Kermit Version 3.0 for MS-DOS
                        Announcing Sanyo Kermit 2.30
          Announcing re-release of V2.30, MS-Kermit for iRMX OS's
        Announcing a New MSKermit 2.30 for Apricot F Series Machines
                Announcing C-Kermit 4D(061) Adapted to MINIX
                          Updates for TSO Kermit
                   Error in CD3KER, CDC Cyber NOS Kermit
                                 CDC Kermit
              Clarification of uucp-support address on okstate
                              DG/1 Success!!!
                            Kermit Konfigurator
            C-Kermit 4E(070) and Long Packets under VMS vs X.25
                  DEC PRO350 Terminal Emulation Software?

Send digest submissions to Info-Kermit@CU20B, requests for addition to or
deletion from the Info-Kermit subscriber list to Info-Kermit-Request@CU20B.

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host CU20B, CU20B.COLUMBIA.EDU, or
CU20B.CC.COLUMBIA.EDU (a DECSYSTEM-20), as user ANONYMOUS, using any password,
and GET the desired files from logical device KER:.  You can also get Kermit
files over BITNET/EARN; to get started send a message with text HELP to
KERMSRV, the Kermit file server, at host CUVMA.  For detailed instructions,
read the file KER:AANETW.HLP (AANETW HLP on KERMSRV).  To order by mail,
request a complete list of Kermit versions and an order form from Kermit
Distribution, Columbia University Center for Computing Activities, 612 West
115th Street, New York, NY 10025 USA.

----------------------------------------------------------------------

Date: Wed 18 May 88 12:00:00
From: Christine M Gianone <[e-mail]>
Subject: Kermit News Articles Needed
Keywords: Kermit News

The next issue of the Kermit newsletter is in progress.  Some of the
articles in the past issue described how Kermit was and is being used in the
U.S. and other countries.  We would like to include a similar section in
the next Kermit News.  Please submit any articles describing how Kermit is
being put to good, interesting or unusual uses as soon as possible since we
hope to go to print sometime in the next month.  We would be especially
interested in stories about how Kermit is used to somehow benefit humanity
(or other creatures), to foster international cooperation, or to make life
easier for the disabled.  For many, Kermit is used for mundane purposes like
saving money.  We'd like to hear about that too.

Thanks again to all those people who have submitted articles in the past.

                                          - Christine Gianone

------------------------------

Date: 8 Jan 88 0:00:00
From: Bertil Schou, Loughborough University, UK
Via: [e-mail]
Subject: Announcing Version 4.09 of Kermit-80 for CP/M-80
Keywords: CP/M-80 Kermit 4.09

After an incredibly long gestation period, here is hopefully an updated
version of Kermit-80 V4.05. Kermit-80 V4.08 is issued for testing purposes
only.  Version 4.09 is the release issue of version 4.08.  I still, however,
want any feedback about problems generated in this revision, or others
desperately want fixing.

Superficially, there is little real change in operation of Kermit-80, version
4.05, but there have been some major jobs tackled like trapping BDOS calls and
multiple FCB buffering...

New bits for this version include:
     SET       {SEND/RECEIVE} START-OF-PACKET character
     SET       DIRECTORY-FILE-SIZE (Shows or hides file sizes on
                 DIRectory displays)
     SET       TERMINAL to OFF, VT52, DUMB, EXTERNAL, QUIET, REGULAR.
     SET       USER to set other user spaces
     RECEIVE   to collect a file from a remote SENDer
     GET       to collect a file from a remote SERVER
     SEND      {local filename} {remote filename}
     TAKE      to take command files from disk (including other take files!)
     FCOPY     Copy CP/M files from within Kermit (no wildcard)
     TYPE      Type a file to the console from within Kermit
     PRINT     Print a file to the printer from within Kermit
     -         Updated  TRANSMIT command that waits for a string of characters
                 from the host (default is CR).
     -         Command line commands, eg:
                    KERMIT ;SET FILE BINARY;SEND FOO.BAR
     -         Automatic TAKE KERMIT.INI on default disk on
                 loading KERMIT-80 (useful for SET BAUD etc.)
     -         Much improved speed on DIRECTORY
     -         Automatic CLOSE-ing of a terminal connection if the line is
                 DROP-ped (currently only for an Apple, and Torch has a dummy
                 test for cntrl-] D in connect state)
     -         Improved printer handling.

On the negative side, only LASM and Microsoft M80 assemblers can be used to
assemble the source files. I personally see no point in being able to support
several assemblers if LASM can do the job, but then again, I have not used the
MAC80 cross assembler...  Comments on assembler compatabilities, please!

All source files have been renamed, and there are a few additions. All source
files are named in the form CPaxxx.ASM, where:

     a=A for general information
     a=S for system independent source files and hex file
     a=X for system dependent source files
     a=V for system-dependent hex files

The system dependent code has changed a litle too, hopefully bringing the
CPXSYS.ASM (formerly CP4SYS.ASM) file a bit more toward a manageable size.
There is now the possibility for FAMILIES of systems, like APPLE and NorthStar
(also Comart), which contains code for computers of a single type.  I have
immediately gone against all this by creating a family with the code for
Torches, Cifers, Ithacas and Superbrains (this because we have these systems
here at Loughborough.)

Bertil Schou.

[Ed. - Many thanks, Bertil!  And also to Alan Phillips and Steve Jenkins at
Lancaster University for sending this new version to us via transoceanic
magnetic tape, and to the many others in the UK who contributed to this new
release.  This version supports all the systems supported by version 4.05,
with the exception of the HP-125, and with the addition of many more, for a
total of something like 52 systems.  The new files have been installed in
KER:CP*.*, and the old ones moved (on CU20B, anyway) to KO:CP*.*.  CP/M
users, please get this new version and try it out, so we can make sure it's
safe to distribute.  And this is also the time to plead ONCE AGAIN for
volunteers to distribute CP/M Kermit on 5.25-inch diskette for different
kinds of systems, and also in "universal" 8-inch diskette format.  Please
come forward if you can do it, or know of a user group that can!]

------------------------------

Date: Fri, 29 Apr 88 11:35 EDT
From: [e-mail]
Subject: Announcing QK-Kermit Version 3.0 for MS-DOS
Keywords: Pascal Kermit, Turbo Pascal Kermit, QK-Kermit, Tektronix Emulation

I have a new version of QK-Kermit which was written using Turbo Pascal 4.0
compiler.  This version no longer supports CP/M systems but was specifically
written to run on MsDos systems.  It takes advantage of the new Turbo Pascal
features such as the new Turbo Pascal Units (TPU) and the improved graphics
facility.  It is now no longer necessary to have different version of
QK-Kermit for each of the graphics cards.  The same KERMIT.EXE file will work
on CGA, EGA, Hercules, MCGA, and VGA graphics card.

Last time, I had problems in sending the new version over BITNET, and ended up
sending you the files via floppy disk.  I will send the new version via a 3.5
inch floppy if that is OK with you.

                                Victor Lee

[Ed. - Thanks, Victor!  The disk was received in good order, and the files
have been installed in the Kermit Distribution, replacing version 2.8 from
October 1987.  The files on the disk have been renamed to fit the Kermit
Distribution naming conventions.  They can be restored to their original
names by running the DOS batch file, QK3AAY.BAT.  The executable program is
in the form of a simple hex file, and can be converted back into an
executable .EXE file by running QK3EXE (originally called HEXEXE) on it.]

------------------------------

Date: Sun, 1988 May 15   14:10 EDT
From: Bob Babcock <[e-mail]>
Subject: Announcing Sanyo Kermit 2.30
Keywords: MS-Kermit 2.30, Sanyo MBC Kermit 2.30

This is to announce the release of Kermit version 2.30 for the Sanyo 550 and
555.  This version is derived from the IBM 2.30 release, and supports
essentially all of the features of the IBM version which make sense for the
Sanyo.  Unlike previous releases, a single executable will run on machines
with or without the optional CGA-like video board.  (A video board is required
for Tektronix emulation.)

The files being sent to Columbia are:
  MSV55X.BOO - BOO-encoded .EXE file (decode with any MSBPCT program)
  MSG55X.ASM, MSU55X.ASM, MSX55X.ASM, MSY55X.ASM, MSZ55X.ASM - system
      dependent source files (also uses the generic MS-Kermit 2.30
      sources)
  MSV55X.HLP - Sanyo-specific addendum to the MS-Kermit 2.30 manual

Present in the source code, but disabled by conditional assembly statements,
is code to apply a temporary patch to the BIOS keyboard routines to enable
more key combinations to be distinguished.  This will only work if the
keyboard interrupt is not being intercepted by a previously loaded program
such as a print spooler or a TSR.

Anyone interested in working on future releases should contact one of the
current developers for copies of the update files and updating program which
are used to create the Sanyo sources from the IBM originals.

Developers for this release are
  Bob Babcock - [e-mail]
  Joe White - [e-mail]

[Ed. - Thanks to Bob and Joe for all of this!  The files have been placed
in the Kermit distribution under the names listed above.  Now we only have
a few MS-DOS systems remaining whose Kermits haven't yet been upgraded to
2.30 level.]

------------------------------

Date: Mon, 02 May 88 12:18:32 PDT
From: [e-mail]  (Jack Bryans)
Subject: Announcing re-release of V2.30, MS-Kermit for iRMX OS's
Keywords: iRMX Kermit, RMX Kermit, Intel, MS-Kermit for iRMX

One out of thirty files sent from RMX with a three byte checksum failed
depending on the length of the last packet modulo sub-packet size.  This
re-release fixes that.  Files updated are MSVRMX.BOO (for iRMX 86), MSVRX2.BOO
(for iRMX 286), MSXRMX.A86, and MSVRMX.MAC.  The latter file was modified to
change the RMX date in the sign-on and version messages to 22 Apr and to
eliminate erroneous and confusing error messages in the edit pass when run on
iRMX 86.

[Ed. - Thanks for the fix Jack!  The old files have been replaced with the
new ones.]

------------------------------

Date: 26-APR-1988 15:29:57 GMT
From: [e-mail]
Subject: Announcing a New MSKermit 2.30 for Apricot F Series Machines
Keywords: MS-DOS Kermit 2.30, Apricot Kermit

I have a working version of MSKermit 2.30 for Apricot machines it runs well on
my FP portable and so should run on the rest of the F series. I know of no
reason why it should not run on the PC/XI but I have yet to get feedback on
this. However I felt it better to let you have it as is and then wait for
comments, if any. I have implemented the keyboard translator but only in a
very basic form as yet. Otherwise it performs most of the other features of
2.30 such as script files etc. but no modem support or terminal emulation.

The files are:
               MSVAPR.BOO    BOO-encoded .EXE file;
               MSUAPR.ASM
               MSXAPR.ASM

Dick Carlton
Department of Earth Sciences,
The Open University,
Walton Hall,
Milton Keynes, England KK7 6AA

ps: if anyone wants the whole source plus the working version I can let them
have it on a single 3.5in diskette in self unpacking archive form on receipt
of a diskette.

[Ed. - Many thanks!  The new files have been added to the MS-Kermit files,
replacing the old Apricot version.  Presumably your diskette offer only
applies in the UK?]

------------------------------

Date: 26 February 1988
From: Adrian Godwin, 78 Putnoe Street, Bedford, England.
Via: [e-mail]
Subject: Announcing C-Kermit 4D(061) Adapted to MINIX
Keywords: MINIX, C-Kermit, Tanenbaum, IBM PC MINIX

Here is a set of C-Kermit 4D(061) sources, modified for use with Andrew
Tanenbaum's UNIX V7 implementation for the IBM PC family, MINIX.  The source
is derived from the Lancaster VAX/VMS backup format distribution tapes of
20.1.88, and 6 files are modified:

    ckuusr.c    ckuus3.c    ckufio.c
    ckutio.c    ckcmai.c    ckcfns.c

Some additional files containing build information for an MS-DOS (Lattice C)
cross-compilation, fixes to the MINIX kernel and pre-built executable files
(in .BOO format) are also present.  These have names of the form cktker.???,
and are documented in the file cktker.hlp .

Modifying C-Kermit 4D-061 for use under 'MINIX' has required rather more
changes to Minix than to Kermit. The C source files are included; they all
began as the CK---.--- files for the 4D(061) distribution set. Here the names
have been changed to MX---.--- . Hints, fixes and library changes are also
attached - most of these are applicable for anyone implementing a serial i/o
driver for Minix, and many library fixes are useful for porting other
utilities.

C-Kermit cannot be built under version 1.1 Minix, as it compiles to about 85K
and the initial Minix assembler cannot separate I&D model output.  The
executable file was therefore built under MS-DOS using the Lattice 3.10 C
compiler. Some care is needed in cross-compiling : see the notes in
Tanenbaum's book about libraries, and read the enclosed Lattice makefile,
cktker.mak.

A port of this version to the latest C-Kermit version 4E(070) is now underway
and will be released at some future time.

[Ed. - While awaiting arrival of the 4E adaptation, this set of files has
been placed in the Kermit Distribution under the prefix MX, as in KER:MX*.*,
and is on Tape B.  Thanks to the folks at Lancaster University for sending
this in.]

------------------------------

Date: Mon, 1988 Apr 25   15:18 EDT
From: (John F. Chandler)   [e-mail]
Subject: Updates for TSO Kermit
Keywords: TSO Kermit, 370 Kermit

Here are the updates I promised a few weeks ago (and some others, too)
for TSO Kermit-370.  I am sending replacements for IKTKER.UPD and
IKTKER.BWR -- the latter gives a bit more elaboration of the bugs fixed
and new features implemented.

[Ed. - Many thanks John!]

------------------------------

Date: 09 MAY 1988  09:49 EST
From: Steve Roseman <[e-mail]>
Subject: Error in CD3KER, CDC Cyber NOS Kermit
Keywords: CDC Cyber Kermit

There is an error in CD3KER, the CDC Cyber NOS Kermit (the Fortran one), which
prevents its use with V2.31 of MS-Kermit.  CD3KER's response to an 'F' packet
contains the wrong length, which didn't bother V2.30, but does upset V2.31.
The following code fixes the problem.  Please replace the current CD3KER.BWR
with this message, since the current .BWR file is out-of-date.  Thanks.

*IDENT,MAY0688
*D,KERMLIB.3426
            CALL SNDPACK(Y, NUM, SLEN(FILESTR), FILESTR)

On a related note, I will be negotiating with Olaf Pors of Univ of Virginia
about who gets to incorporate his mods from last September (V7 #3), into the
standard CD3KER.  I don't really have the time, but I will if necessary.

Steve Roseman
Lehigh University Computing Center
LUSGR@LEHICDC1

------------------------------

Date: Mon, 9 May 88 16:47:20 EDT
From: Olaf Pors <[e-mail]>
Subject: CDC Kermit
Keywords: CDC Cyber Kermit

I just took a look at the Kermit distribution and noticed that the CD3KER.IN2
and CD3KER.MOD files were the ones that conflicted with Steve Roseman's 3.3
version of Kermit.  Late last year I downloaded Roseman's 3.3 version and
upgraded my mod to correspond (producing version 3.4), and I thought I sent
you the upgraded stuff.

In case something got dropped, here are the two files again.  The first one
should be put in place of CD3KER.INS (get rid of CD3KER.IN2).  The second
should be put in place of CD3KER.MOD.  There's also an updated CD3KER.HLP.

Olaf Pors, University of Virginia

[Ed. - Thanks, Olaf.  The updated files have been put in right places.]

------------------------------

Date: Mon, 25 Apr 88 18:33:37 -0500
From: Mark Vasoll <[e-mail]>
Subject: clarification of uucp-support address on okstate
Keywords: OKSTATE

We have recently moved the Kermit distribution at Okstate to another
computer.  A result of this is that the previously stated restriction of not
being able to send mail over this link is now enforced (since the new home
of Kermit is not the "real" okstate.  Questions about the Kermit or UUCP
servers at Okstate should be addressed to:

Domain: [e-mail]
UUCP Path: {cbosgd, ihnp4, rutgers}!okstate!uucp-support

Attempts to mail via the uucpker login to okstate!uucp-support will be
flushed.

Thanks,

Mark Vasoll
Computing and Information Sciences   Domain:  [e-mail]
Oklahoma State University            UUCP:    {cbosgd, ihnp4,
Stillwater, Oklahoma                           rutgers}!okstate!vasoll

------------------------------

Date: Mon, 25 Apr 1988 20:37:05 EDT
From: "Robert E. Zaret" <[e-mail]>
Subject: DG/1 Success!!!
Keywords: MS-DOS Kermit 2.30, DG/1

I just tried MS-Kermit 2.30 extended development (received from Columbia 23
April) on my DG/1 and have succeeded. In fact, I am using it to compose this
note.  I still can't use COM1/BIOS1 with either the internal modem or an
external modem.  However, if I set the port to BIOS2, I can use COM2 with an
external modem.  I have only been using it for a few minutes, but 1200 bps
seems to be no problem.  I also tried connecting to an AT with a null modem;
Kermit could switch the port's speed to 2400 bps, and I could talk to the AT,
but I couldn't transfer files (each Kermit kept trying, but did not recognize
the other.)

I got the idea to try BIOS2 from two clues: 1) when I use the STATUS command
right after I start Kermit, the display says the port is BIOS1; and 2) when I
tried SET PORT 2, Kermit said the port was unavailable.

Thank you, thank you.  I've had other options, but was rooting for Kermit; I
know at least one other person around here with a DG/1, who has fewer options
and believes several others in the area have the same problem; and I've been
concerned about the person who wrote to the Kermit digest a few months ago
about communications software that can run on a DG/1 and be used by the blind.

------------------------------

Date: Thu, 12 May 88 15:27:03 PDT
From: Ariane Glagowski <[e-mail]>
Subject: Kermit Konfigurator
Keywords: MS-DOS Kermit

We are supporting MS-Kermit here as a method for connecting PC's to VM/CMS via
7171's.  Users at UVic can connect to a 7171 port by having a direct
connection to a Gandalf PACX port or an Ungermann-Bass Net/One port, or
dialing to a PACX port. Another connection method is through DATAPAC, although
that is seldom used.

We tried to set up a Kermit "TAKE" file or an ".INI" file for the Users, with
appropriate keyboard mapping and script commands to automate the connection to
VM. If automatic connection was desired, the User was able to connect to VM by
invoking Kermit and typing "TAKE filename" and waiting until the VM/370 logo
appears on the screen. With all the possible combinations of connection
methods, baud rates, monitors, keyboard layouts, etc., etc. it became
impossible for our User Services to help all the first time users with their
connection problems.  We decided to write a Kermit Konfigurator program which
the User could run and would build a TAKE file according to the User's
requirements.

Before running Kermit for the first time, the User types KKONFIG on his PC.
KKONFIG prompts with questions like "select baud rate", "select communications
port", "do you want automatic connection to CMS", etc., along with simple help
menu's for each possible selection. When KKONFIG terminates, it writes a
"TAKE" file that the User can use when running Kermit or he can rename it to
an .INI file.

KKONFIG is written in Turbo PASCAL and linked into one .COM file.  As it
stands now, it is customized for our environment but the source could easily
be tailored to other environments.

If anyone is interested in trying it out to see how it works, please send a
note to me, Ariane Glagowski, [e-mail], and I will send you the
.COM file over the network. You can then receive the file onto your CMS disk
and download it to your PC using Kermit.  Be sure to set the host Kermit in
binary mode before downloading to your PC.

The Konfigurator works with MS-Kermit 2.29c and 2.30.

Ariane Glagowski <[e-mail]>
Acknowledge-To: <CCARIANE@UVVM>

------------------------------

Date: 25-APR-1988 11:34:37 GMT +01:00
From: [e-mail]
Subject: C-Kermit 4E(070) and Long Packets under VMS vs X.25
Keywords: VAX/VMS C-Kermit, X.25, Long Packets, C-Kermit 4E(070)

I've just built 4E(070) under VMS and been trying to use long packets with it
to MS-Kermit 2.30, with distinct lack of success.

We have a (*very* slow) VAX-11/780 running VMS 4.7; terminals are connected to
X25 PADs and make X29 calls into the VAX. We have all our lines set for 9600
baud. C-Kermit works OK with normal packet sizes, and it sends files *to* the
PC with 250 byte packets OK. However, trying to use any packet size about 200
bytes or so *from* the PC results in repeated retries; the log shows that the
VAX is giving "Data Overrun" errors on about 1 in 3 packets.

I tried changing CKVTIO.C to set the line to use HOSTSYNC, which ought (I
think) to allow VMS to exert flow control on data coming from the PC (?), but
no effect. Has anyone seen this problem elsewhere? Is the solution just to
reduce the baud rate to what will work?

   Alan Phillips

[Ed. - The problem is probably in the VAX's network interface.  It seems from
your description that the network is delivering the PC's data correctly to
the VAX, but the VAX cannot keep up.  It may be that VMS's support for
incoming terminal connections over an X.25 network is designed with the
faulty assumption that the host sends large amounts of data, and terminals
only send small amounts.  What is the biggest X.25 data packet your VAX will
accept?  If it is 128 (a typical value), then long Kermit packets will be
segmented by the network, and the VAX must reassemble them.  If the VAX is
very slow, new segments may arrive before it has disposed of previous ones.
As you suggest, there should be flow control between the VAX and the network,
but X.25 is supposed to provide this, no?  But it may be that specific
support is required in VMS Kermit for X.25 connections as opposed to real
terminals.  Any VMS X.25 experts out there?]

------------------------------

Date: 5 May 88 21:16:03 GMT
From: chemabs!chemabs![e-mail] (Robert S. Hall)
Subject: DEC PRO350 Terminal Emulation Software?
Keywords: PRO350 Kermit

I am looking for an alternative terminal emulator for a DEC PRO 350.  I am
currently using an in-house written VT102 terminal emulator which works well,
but is not quite as fast as I would like.  What I would like to know is:

        o Is anyone else currently using PRO/Kermit?  If so, have
          you noticed any problems?

        o Has anyone made ANY enhancements to PRO/Kermit.  What I
          am most interested in is PRO/Kermit's 'connect'
          function, i.e.  User Defined Function Keys, etc.

    o Does anyone know of any other VT220/VT102 terminal emulation
          software available for the DEC PC350 other than PRO/Comm
          or PRO/Kermit?

Any input you might have on this subject will be greatly appreciated. Thanks!

Robert S. Hall
Chemical Abstracts Service      Columbus, Ohio 43210    [phone] X2027
cbosgd!osu-cis!chemabs!hall

[Ed. - There are several Pro-Kermits.  The one most people use is probably
the K11 version from Brian Nelson.  The Stevens version gave up the ghost
a while back when new P/OS releases made it stop working.]

------------------------------

End of Info-Kermit Digest
*************************
-------
24-May-88 12:53:36-EDT,24454;000000000000
Mail-From: SY.CHRISTINE created at 24-May-88 12:51:17
Date: Tue 24 May 88 12:51:17-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #13
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 24 May 1988       Volume 7 : Number 13

Today's Topics:

         Help Sheet on Recent MS-Kermit 2.31-test5 22 May 1988 Code
             Extended ASCII with Kermit, For Kermit Developers
                   Re: VAX/VMS Kermit "SET LINE" command

Send digest submissions to Info-Kermit@CU20B, requests for addition to or
deletion from the Info-Kermit subscriber list to Info-Kermit-Request@CU20B.

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host CU20B, CU20B.COLUMBIA.EDU, or
CU20B.CC.COLUMBIA.EDU (a DECSYSTEM-20), as user ANONYMOUS, using any password,
and GET the desired files from logical device KER:.  You can also get Kermit
files over BITNET/EARN; to get started send a message with text HELP to
KERMSRV, the Kermit file server, at host CUVMA.  For detailed instructions,
read the file KER:AANETW.HLP (AANETW HLP on KERMSRV).  To order by mail,
request a complete list of Kermit versions and an order form from Kermit
Distribution, Columbia University Center for Computing Activities, 612 West
115th Street, New York, NY 10025 USA.

----------------------------------------------------------------------

Date: Sun, 22 May 88 21:08 MDT
From: <[e-mail]> (Joe Doupnik)
Subject: Help Sheet on Recent MS-Kermit 2.31-test5 22 May 1988 Code
Keywords: MS-DOS Kermit 2.31-test5

The following MSTIBM.BOO, 2.31-test5 22 May 1987, corrects some problems
and adds some new features.

A quick update on a new script feature, long overdue. Now present are the
new commands:

  IF [NOT] {SUCCESS | FAILURE | ALARM | COUNT | DEFINED | ERRORLEVEL | EXIST}
                                                            <Kermit command>
  GOTO [:]<label>
  :text                               text is a label, a la Batch files
  REINPUT <timeout> <match string>
  SET ALARM <time>
  SET COUNT number
  POP
  STOP

Let's start with labels.  They are like the Batch variety and are identified by
a line starting with a colon and then the label text proper (any non-spacing
text should be ok).  Material following the label on that line is ignored.
GOTO is the way to jump to a label. The label name in a GOTO command may
optionally have the leading colon; however, the labeled line must begin with
a colon to be recognized as a label. A label is known only within it's home
Take file or Macro and cannot be referenced from outside. Thus, nested Take
files or Macros can use labels of the same name without confusion. See the
discussion of IF DEFINED for a way to retain information between Take files
or Macros.

GOTO <label> does pretty much as expected. It goes to the line following the
indicated label.  The technique is to rewind the Take file (or the Macro) and
search for the label, so the GOTO's can be forward or backward.  Since scripts
are relatively short files there is not much time lost.  If no such label then
there is a message saying

        ?Label ":text" was not found

and the current Take file or Macro is exited; i.e., there is no place to
continue the execution thread. (No bomb box, no crashing noises.)

Giving a label by hand to the Kermit prompt is a no op (is ignored without
comment).  This is done to let script control flow run across labels without
producing messages en route. GOTO has meaning only within Take files and
Macros.

REINPUT is very much like the script INPUT command, except it attempts to
reread the 128-character script serial port buffer for material matching the
user's string and does not consume the buffer in the process.  Thus, several
REINPUT commands can have a chance to examine the same buffer.  Regular INPUT
discards buffer characters as they are examined, REINPUT does not.  And,
REINPUT can request newly arrived characters, until the buffer fills, as
needed while seeking the desired pattern; that's where the timeout is
effective.

The IF statements look like

        IF [NOT] <condition> <command>

where NOT is optional (yes, NOT NOT NOT.. flips back and forth)

        <condition> is one of the following:
                FAILURE                 (of previous Kermit command)
                SUCCESS                 ( ditto )
                ERRORLEVEL number       (true when ERRORLEVEL >= number)
                EXIST filespec          (with path and wild cards)
                COUNT                   (decrement COUNT, but not below 0,
                                         then if COUNT is still greater than 0
                                         do the indicated command)
                ALARM                   (true if present time >= alarm time)
                DEFINED macro/variable name  (true if macro/variable exists)

        <command> is any legal Kermit command, including another IF statement.

When an IF statement logical test yields False control passes to the Kermit
command on the next line. IF statments themselves do not produce testable
status so that several IF statements can test a previous main Kermit command.

The command

        SET COUNT number   (0 to 65535 decimal)

presets a variable COUNT to the value of number so that it and the IF COUNT
statement can form a loop. There is an separate internal copy of COUNT for
each nested Take file and Macro. SET COUNT has meaning only when given in
Take files and Macros. COUNT is initialized by SET COUNT and it is both
decreased and then examined by IF COUNT. For example, the loop below executes
the interior commands four times -

        SET COUNT 4                     ; do this loop four times
        :TOP                            ; a label for IF COUNT
        <various commands go here>
        IF COUNT GOTO TOP               ; decrement COUNT. If COUNT is still
                                        ; non-zero then go to label TOP

The command

        SET ALARM time

sets an internal alarm clock for use by IF ALARM. Time can be stated as the
number of seconds from now or as HH:MM:SS to specify a time of day. Trailing
SS seconds and MM minutes are optional; a 24 hour clock is used. Times should
not be more that 12 hours in the future so that Kermit can distinguish early
from late. The alarm time is zero until changed by this command, and IF ALARM
does not modify the alarm time. (Right. Now we need "set coffee-pot on"!)

When an IF statement is typed by hand the line is quietly absorbed if the
conditional test fails; otherwise, the line is broken automatically and the
<command> part is then entered at the normal Kermit prompt.

Examples:

        IF NOT DEF \%3 DEF \%3 FOO.BAR  ; supply a missing filename

        IF DEF IBM DO IBM               ; or "Don't DO nothing" (poor English)

        IF NOT EXIST c:\dumm*.txt  IF EXIST mskermit.ini  RUN copy hither yon

One not so obvious use for the IF DEFINED command is to communicate status
between Take files or Macros. That is, a "DEFINE name text" command executed
in one can let another test that name for existence or not. DEFINE name no-text
undefines the macro. Thus, macro names can be used as semaphores or flags (one
bit variables).

Recall, the command "GOTO label" is needed to jump.

Here is a small example looking for modem text CONNECT 1200 or CONNECT 2400:
        set speed 2400
        output AT\13                    ; awaken modem at desired speed
        pause
        output atdt 555-1212\13         ; dial the telephone
        input 30 CONNECT                ; first part of normal response
        if failure goto hangup          ; here "hangup" is a label
        reinput 3 2400                  ; did we connect at 2400 baud
        if success goto login           ; if so jump to login label
        reinput 2 1200                  ; how about 1200 baud
        if fail goto hangup             ; neither so quit
        set speed 1200                  ; slow down Kermit
        :login
        <do login stuff>
        :hangup                         ; a label rather than a command
        hangup                          ; disconnect telephone
        echo \13That's all folks!\13\10

The commands

        POP
        STOP

provide clear exits from a Take file or a Macro. POP exits the current
Take file or Macro, and STOP exits all of them and gets back to the Kermit
prompt.

Before there are too many helpful suggestions in this area, and we could
use plenty, please note that the construction of Kermit command lines and the
parsing code impose limits on what can be accomplished. The command structure
is inadequate to support the syntax and notions of a modern programming
language without a complete redesign of much of MS Kermit. Plus, simplicity
does have a few benefits.

The INPUT command used to be the only one that began with "I", so many existing
scripts and macro definitions abbreviate INPUT this way.  To preserve and
protect this work, I is recognized as an acceptable non-unique abbreviation for
INPUT.

The constructions shown above also work ok in Macros, given the 128 byte length
limit of a macro.  GOTO produces a warning message if given by hand.  Task
size increase has been reasonably small so far.

I think this is a close enough mimicry of Batch to control most scripts for
communications while avoiding the language development snarl.  I'll let the
Hayes folks bask in the glory of auto-scripting.

On another front, I finally was able to borrow a PS/2 Model 50 for an evening.
First, I too saw the message that COM1 was not available.  Thirty minutes later
everything was fine.  That's the difference of being able to do rapid probes.
The new MSTIBM.BOO works well on the Model 50.

The problem area was in the recent code to automatically detect the IRQ value
for a serial port. Apparently PS/2's have enough differences in the timing
in that section to have confused the test code; the new material passes on
that machine and on my AT clone. Defensive action is indicated below.

The current test MS Kermit, dated 22 May 1988, still performs the automatic
IRQ test to assist unusually configured boards; but if the tests fail it
now reverts to choosing an IRQ value of 4, 3, 4, 3 for ports COM1, 2, 3, 4,
respectively, as was the case in version 2.30. PS/2 machines, Models 50 and
greater, will use IRQ 3 for COM2 in accordance with IBM specifications.

Second, reports of very large transfers not surviving a trip through some
recent test Kermits probably resulted from the receiver section tripping out
when a timeout or similar condition occurred. That produces an internal 'T'
packet but the receiver was not fully educated on them; it is ok now. I sent a
1.2MB file back and forth several times and pushed the Return key many times on
both sides, and so on with no premature failures. That's with recent code;
earlier stuff had the attribute of stopping after the first difficulty.

Third, incoming responses to REMOTE commands are now preceeded by a blank line
prevent some hosts from overwriting the local command line.

This is a good place to remark that some IBM hosts which recognize attributes
packets may send a file with a date but no time field.  MS Kermit records the
time as all zeros and DOS interprets that as no time at all; this is a proper
result under the circumstances.  Recognition of attributes packets can be
turned off by SET ATTRIBUTES OFF.

Fourth, the Tektronix emulator now recognizes ANSI.SYS style escape sequences
to change drawing colors. These are the same as in the VT102 emulator; vis

        ESC [ Pn ; Pn ; .. m

where Pn represents an ascii number:
             0 = set medium intensity white on black
             1 = set high intensity foreground
         30-37 = set foreground drawing color,  30 + sum of colors
         40-47 = set background color, 40 + sum of colors
        colors are 1 for red, 2 for green, 4 for blue, sum to get others.
        Parameters are applied in the order received.

The Tektronix emulator assumes the colors of the VT102 emulator until given
it's own set, as above. Resetting the emulator (\Kreset or ALT =) returns to
the VT102 coloring set. Clearing the screen (reception of ESC Control-L)
employs the new background color.

The following MSTIBM.BOO can be posted for public inspection, with the reminder
that the script enhancements are still under active development and will
hopefully be improved soon.

        Regards,
        Joe D.

[Ed. - Once again, Joe, many thanks for all your careful and patient work.
We hope that the features described in this message, and the previous one
about "2.31-test4" will comprise the major changes for version 2.31, and
a formal announcement will appear soon, once the kinks are worked out of
the new code.  Please test it on IBM PC's, compatibles, and near-compatibles
like the DG/1 and report any problems.  The files are in MSTIBM.BOO and
MSTIBM.HLP in the Kermit distribution.]

------------------------------

Date: Fri, 20 May 88 15:26:25 +0200
From: Andre PIRARD <[e-mail]>
Subject: Extended ASCII with Kermit, For Kermit Developers
Keywords: Extended ASCII

ABSTRACT

In the course of implementing our own national character sets with Kermit
for terminal mode and file transfer, my understanding of the problem evolved
from confusion to (near) simplicity and from national to international.  I
think my findings will be of much interest to those having to deal with the
Spanish, French, German, Italian, well, the American continent, Western
Europe and many other languages.  That's, for them, really interconnecting
the majority of computers existing to-day.

On request, I've tried to be as short as possible at the risk of skimming
here and there.  I sure won't blame those getting bored with the subject.
They can skip to the conclusion and see just what it takes in Kermit terms.
Conversely, those really interested will get more information from the
standards and the ISO8859 list of BITNET's LISTSERV @ JHUVM and its
archives.

Finally I take the occasion to praise all those devoting much of their time
to straightening things that had run havoc. It's their ideas I am conveying.
But I am sure glad to help. I just hope my limited English will carry the
message precisely.


DETAIL

In the process of implementing extended characters transfer between micros
and IBM mainframes, I relied on the extended capabilities of Kermit 370
conversion (thanks John!). I came to the conclusion that, for the sole IBM
PC, I should set up to 9 different tables in order to support 3 EBCDIC
tables x 3 "ASCII" tables.  For the Macintosh, that's 3 more tables with the
IBM host.  I was unable to have Kermit do Mac to IBM PC conversion, unless
endeavouring translation on the PC, 3 more tables or so.

I hacked some limited national characters support for IBMPC terminal mode
through the 7171, but our Mac users were left with a dumb nice keyboard and
a deaf screen.


Kermit implements two main files transfer modes.

Binary mode defines how to transport a continuous string of bytes containing
values only required to be meaningful to the originating and receiving final
systems.  No matter how stored on an intermediate one, it should forward or
return the same byte string on the communication line.  The point here is
that each node operation is clearly defined, making it the best method when
appropriate.

Text mode, in contrast, defines how to transport *records* containing codes
for "readable" characters intended to be usable -- and stored as such -- on
any system.  The protocol rules how to, on the line, stream the records in a
system independent manner. Again, every node should forward the data
unaltered, that is equivalent communication line encoding.

The Kermit protocol wisely says that the ANSI X3.4 (ASCII) standard is to be
used to represent these characters.  It is the code used on most computers
and those (IBM, Commodore) not using it have to deal with their own problem
of code conversion.

Most modern computers now implement an 8-bit extended character set in order
to support, to various extents, languages requiring characters not found in
ANSI X3.4 (I intentionally disregard the obsolete 7-bit remapping methods).
Almost each does it its own way however, because there was no standard at
the time they were devised (IBM even has multiple ones within a single
system).

Clearly, translation must occur somewhere to transmit extended text usefully
between them.  If it is done say by running a program in the receiving
system, one must know and use the right table according to the sender.  The
mere at least 7 codes that I have to deal with make for 5040 tables in
theory.  In practice, what was a crystal clear matter as long as only X3.4
was used becomes a real puzzle with extended codes.  As the number of tables
grows, so does the problem factorially.

To a lesser extent, the same problem holds for terminal mode.  It occurs
only when a computer supports remote terminals, but we must fiddle with a
7-bit data path, an issue solved per se by the Kermit protocol in the first
case.

It is evident that the problem lies in each machine's dealing with the
others' own business, and that the solution is to have them talk a common
code on the line, as it is now with X3.4 and for those not using it.
Imposing them to use that code internally is impractical, although
recommendable.  But having each convert the data to/from that common code
before/after transmission reduces the above example to a mere 6 tables
pairs.

What is striking is the technical simplicity of translating every character
data byte that flows on a communication line to a common code everyone
agrees about.  What is sorry is that we have to. What is moot is what common
code should be used on the line.

It is my strong feeling that Kermit itself translating national codes to
make up for the lack of its host system using a standard will be *extremely*
useful for people having to use these codes.  This feature must be optional,
because incompatible with previous use.  It would be a shame to have two
Kermit implementations for the same system corrupt data because one uses
this feature and the other lacks it.

The cause of the problem, a missing standard, does no longer exist.  ISO
8859/1 = ANSI X3.134.2 = ECMA 94 has been defined and gathers every possible
character extension for Latin group 1 users, by far the largest, plus other
common symbols satisfying many computer brands. It looks like a very well
thought out thing and several leading manufacturers have adopted it, or a
pre- release because they couldn't wait, or modified their previous codes to
conform to ISO (have exactly the same graphics, but use other codes points,
in line with this proposition).  That's IBM, DEC, Microsoft and Lotus for
what I gathered.  It looks like the future many, international and US, are
working for.

The on-the-way-ISO8859/x users should not be left out.  The problem is
parallel, but their codes will be untranslatable to ours.  They might be
expected to start with pure ISO right off.  Until the 16 bits (some say 32)
codes sets will be devised, but that's our children's Kermit probably.


CONCLUSION

In summary, a Kermit implementation would be much enhanced for many people
if simply:

- it was optionally translating bytes during text mode file transfer (at the
file I/O or equivalent level). Nothing elaborate is required to start this.
Just a pair of null translation tables, easily found and patched, and a
couple of code lines will cover both the "translation" and "optional"
topics.

- it was doing the same at the communication line I/O level during terminal
mode and, when using 7-bits wide data path, implementing the ISO 2022 SO/SI
feature to use the upper half of the set (shift out) and revert to the lower
one (shift in).  Several already do.

That's all. But a welcome leap further would be to:

- if a particular system does not conform to ISO (like the Mac, misses some
of its graphics or uses others), define a best fit one to one correspondence
between its character set(s) and ISO (there should be total agreement as to
which, up to with the manufacturer). It must involve the 256 codes in a
revertible way.

- have systems supporting terminals do it in ISO mode, preferrably on an
8-bit wide line.

- have these features bundled in options.

Thanks for your patience in reading.

Andr). Oops, not yet. Andre'.

[From Frank - This message is the tip of a large iceberg.  Kermit does
indeed use 7-bit US ASCII with CRLF-terminated lines as the common
intermediate representation, or "transfer syntax", for text files.  This has
been a great strength of Kermit, allowing text files to be transferred in
useful form between arbitrary systems.  But the years since Kermit was
designed have witnessed the growth of widespread computing based on
non-ASCII alphabets, many of them 8-bit or 16-bit character sets that cannot
be mapped to 7-bit ASCII.  Therefore, it would seem appropriate to do as
Andre and many others have suggested: allow for a selection of transfer
syntaxes.  The mechanism would be something like SET TEXT {ASCII, ISO8859/1,
JIS, etc}, where the default would be ASCII, as now.  This command would
select the character set to be used on the communication line during file
transfer.  Similarly, a SET TERMINAL CHARACTER-SET command would govern the
transmission and display of text during terminal emulation.  This would not
necessarily be the same as the one used in file transfer.  Since not all
Kermit programs could be expected to support the same character sets (other
than ASCII), this could be a parameter specified in the Attributes packet
under the "encoding" attribute, which already includes an "A" parameter for
ASCII.  New symbols would have to be defined for each alphabet, such as I1
for ISO8859/1, I2 for ISO8859/2, etc, J for JIS (is there more than one
variety of JIS), etc.  Suggestions and discussion are welcome.]

------------------------------

Date: Tue, 5 Apr 88 15:28 EDT
From: [e-mail]
Subject: Re: VAX/VMS Kermit "SET LINE" command
Keywords: VAX/VMS Kermit

Mike Rego asks:

>When trying to use the VAX/VMS "set line" command on KERMIT, I encounter a
>"no privilege for attempted operation".  Does anybody know what VAX/VMS
>category privilege (e.g. netmbx,share) I must allow a user to enable the
>terminal line to be accessible to the user's processes?

READALL is not a privilege that you want to give out casually, as it allows
a user to read *any* file on the system regardless of access protections.
What we do here is to set the protection on the particular device such that
the world has read access. This allows a user with no special privileges to
connect to the device. The command is:

  $ SET PROTECTION=(W:R) ddcu:/DEVICE

where ddcu: is the device you want users to have access to. I do not know of
any major security problems this creates.

Tony Carter
MIT Bates Linac
[e-mail]

[Ed. - We received many replies similar to this one.  Among them was the
suggestion that the above technique might make it possible for one user to
spy on another, with the workaround being something like:

  $ SET PROTECTION=(W:RWLP)/DEVICE/OWNER=[1,4] TXA0:

There was also the idea of using access control lists for the dialout devices:

  $ SET ACL/OBJECT=DEVICE/ACL=(IDENTIFIER=INTERACTIVE,OPTIONS=NONE,-
          ACCESS=READ+WRITE) TXA10:

This technique also allows you to grant access to only certain authorized
users.  In no case should users need to be given special privileges to assign
an external TTY line.]

------------------------------

End of Info-Kermit Digest
*************************
-------
 7-Jun-88 17:41:12-EDT,22631;000000000000
Mail-From: SY.CHRISTINE created at  7-Jun-88 17:40:20
Date: Tue 7 Jun 88 17:40:20-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #14
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>


Info-Kermit Digest         Tue, 7 Jun 1988       Volume 7 : Number 14

Departments:

  ANNOUNCEMENTS -
        Announcing Release 3.3.117 of VAX/VMS Kermit
        Announcing Macintosh Kermit Version 0.9(40)
        Tape Utility Programs Available

  MACINTOSH KERMIT -
        Defective S packets from MacKermit 9(36)b4
        MacKermit Questions
        Linefeed problem with MacKermit 0.9(36)B4
        Kermit Between Macintosh and UNIX, Slight Problem

  MISCELLANY -
        8-Bit Asynchronous Communication with Parity Bit
        Does Windowed Kermit Exist?
        Bi-directional Protocols
        Modcomp Kermit - A Bug and Two Suggestions

Send digest submissions to Info-Kermit@CU20B, requests for addition to or
deletion from the Info-Kermit subscriber list to Info-Kermit-Request@CU20B.

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host CU20B, CU20B.COLUMBIA.EDU, or
CU20B.CC.COLUMBIA.EDU (a DECSYSTEM-20), as user ANONYMOUS, using any password,
and GET the desired files from logical device KER:.  You can also get Kermit
files over BITNET/EARN; to get started send a message with text HELP to
KERMSRV, the Kermit file server, at host CUVMA.  For detailed instructions,
read the file KER:AANETW.HLP (AANETW HLP on KERMSRV).  To order by mail,
request a complete list of Kermit versions and an order form from Kermit
Distribution, Columbia University Center for Computing Activities, 612 West
115th Street, New York, NY 10025 USA.

On June 1, 1988 the renaming of CS and CC hosts from .COLUMBIA.EDU to
.CS.COLUMBIA.EDU and .CC.COLUMBIA.EDU domains took place. Please report
any problems to your local departmental network/system manager.

----------------------------------------------------------------------

Date: Wed 1 Jun 88 12:00:00-EST
From: Christine M Gianone <[e-mail]>
Subject: Tape Utility Programs Available
Keywords: Tape Utility Programs

Tape utility programs are available in the Kermit Distribution on Tape E.
The programs have been collected from various sources, and are being made
available as a public service.  For distribution purposes, they have been
renamed as indicated in KER:TUAAAA.HLP.

------------------------------

Date: Wed 1 Jun 88 12:00:00-EST
From: Christine M Gianone <[e-mail]>
Subject: Announcing Release 3.3.117 of VAX/VMS Kermit
Keywords: VAX/VMS Kermit

This is to announce VAX/VMS Kermit-32 Version 3.3.117, submitted by Jonathan
Welch of Amherst College.  This version contains fixes for some of the bugs
that were noted in VMSMIT.BWR, the "beware file" for the previous release,
3.3.111.  Here's the list:

 - Fix the message generated in NEXT_FILE so that the filenames displayed
(e.g. Sending: foo.bar;1 as foo.bar) are always terminated by a null (ASCIZ).

 - Modified SY_TIME to use $GETTIM as opposed to the LIB$timer routines
(which broke when their method of calculating time differences changed in
V4.4?).  Removed the call to LIB$INIT_TIMER in SY_INIT.

 - Modified MAIN_ROUTINE to return the status code from COMND when exiting.
Note: The error message codes returned are internal Kermit-32 error codes.

 - Added the ability to send a BREAK character to the outgoing terminal
session using the sequence esc-chr B.  The break will be sent after the next
character arrives.  This is because there must be no outstanding I/O on a
channel in order to modify terminal characteristics (necessary to send a
break).

 - Modified COMND_HELP to look for the kermit help file called KERMIT_HELP or
pointed to by the logical name KERMIT_HELP.  Thus if a user wants to have the
kermit help file in a directory other than SYS$HELP it is not necessary to
define the logical name KERMIT (which causes problems: i.e. RUN KERMIT will
fail).

 - Calls to LIB$SIGNAL with multiple arguments were not coded correctly.  For
calls with multiple arguments an argument count was added.  Minor changes to
KERM_HANDLER to make use of the changed argument passing method.

The hex file for the new version is in KER:VMSMIT.HEX, which can be converted
into an .EXE file using the VMSDEH program.  The program was linked under VMS
4.4, which means that the .EXE will run under VMS 4.4 and above.  If you have
an earlier release of VMS 4.x, then you will have to rebuild from Bliss or
Macro source.  If you are running VMS 3.x, you won't be able to use the new
version at all, but must continue to run version 3.1 of VMS Kermit, which is in
KER:VMSV31.HEX.

------------------------------

Date: Thu 26 May 88 16:42:08-EDT
From: Christine Gianone <[e-mail]>
Subject: Announcing Macintosh Kermit Version 0.9(40)
Keywords: MacKermit 0.9(40)

This is to announce Macintosh Kermit 0.9(40), by Paul Placeway of Ohio State
University and Matthias Aebi of ECOFIN Research and Consulting, Ltd, Zuerich.
MacKermit 0.9(40) runs on all Macs except the 128K original.  If you have a
128K Mac, you should keep version 0.8(34), the last formal release.

As of 0.9, MacKermit has been translated into Apple MPW C, so that it can be
edited, compiled, and built on the Macintosh itself.  This translation was
based on work by Jim Noble of Planning Research Corporation, who converted
MacKermit 0.8(34) from SUMACC C (which had to be cross-compiled on a UNIX
system) to Megamax C.  Matthias converted Jim's version to MPW C, and he also
added many of the new features listed below.  After that, Paul Placeway
integrated the program with version 4E of C-Kermit and added additional new
features, also shown below.

 - Long packet support
 - The cursor with open desk accessories now works correctly
 - New program icon
 - New settings files are no longer TEXT
 - Settings can now be written back to an already existing settings file
 - Key redefinition function built in to Kermit, no more CKMKEY
 - Server mode directory listing feature
 - Multifile (folder) send
 - Server "Delete" file command
 - Server "Space" command
 - Get whole folder content from the server with filename ":"
 - Support of menu command keys (key macros)
 - Terminal settings dialog separated from communication settings
 - Non-transparent terminal mode
 - Display of statistics and protocol version to "About Kermit" dialog
 - Parity problems fixed
 - More efficient file transfer in many cases, especially when parity in use
 - Session logging (screen capture)
 - Transaction logging
 - Multifinder support
 - Additions to the VT102 emulator (smooth scrolling, etc)
 - Rearrangement of menus and displays
 - Program no longer hangs if remote response window gets too full
 - Program now works correctly on 64K ROM machines
 - A new manual

The new files are among those in KER:CK*.* on CU20B.COLUMBIA.EDU, available
via anonymous FTP, and on BITNET, as CK* * from KERMSRV at CUVMA.  In
particular:

 CKMKER.HQX is the MacKermit application, in BinHex Version 4 format
 CKMKER.DOC is the new Kermit User Guide chapter for MacKermit
 CKMKER.MSS is the Scribe source for the manual chapter

If you would like sources, the files you need (using Unix notation for
brevity) are: CK[CMU]*.[CHRW], that is, all files whose names start with CK,
followed by C, M, or U, and then some more characters, with a filetype of C,
H, R, or W.  You also need the file CKMMAK.*, the "makefile" in BinHex v4
format.

The previous version, 0.8(34), will be retained (without source) as CKM834.*
and CKMKEY.HQX for use on 128K Macs.

Thanks to all the Info-Kermit readers who have been beta-testing different
pre-releases of this program since last October.  And many thanks to Paul and
Matthias for putting this release together and making it available.  Please
report any problems to Info-Kermit-Request@CU20B.

------------------------------

Date:  Sun, 22 May 88 22:28 EDT
From:  "David M. Rosenberg" <[e-mail]>
Subject:  Defective S packets from MacKermit 9(36)b4
Keywords: MacKermit 0.9(36)b4

I have MacKermit 9(36)b4 configured to send 1000 byte packets.  The first
time I try to send a file from the Macintosh, MacKermit produces a correct S
packet indicating that the maximum length for non-long packets is 90 bytes,
that it supports the long packet capability, and the maximum length for long
packets is 1000 bytes.  After having successfully sent a file with long
packets, on the second and subsequent attempts to send a file, MacKermit
produces defective S packets.  These defective S packets are defective only
in that the character that encodes the maximum length of non-long packets is
not in the permissible range (it is a backspace character - I assume that
MacKermit is trying to encode the value 1000 in a single byte and its
algorithm produced the backspace character).  This defective S packet should
be acceptable to a program prepared to receive long packets - because it
indicates support for the long packet capability and a valid maximum length
for long packets.  But it is a defective S packet.

[Ed. - This is the same bug that was noted by Chuck Hedrick in Info-Kermit
V7 #9, 22 March 88.  It is not particular to MacKermit, but is endemic to
all C-Kermit-based Kermits, therefore MacKermit 0.9(40) will have the same
problem.  A fix from Chuck is listed in CKUKER.BWR, and will be applied in
the next release of C-Kermit.]

------------------------------

Date: Tue, 5 Apr 88 13:47:59 EDT
From: Howard Walter <[e-mail]>
Subject:  MacKermit Questions
Keywords: MacKermit 0.9(36)b4, Long Packets

I am using the (36)b4 release of MacKermit on a Mac+ and have been VERY
pleased with it. I have several questions:

I am using a Vadic 9600VP modem which has a 4KB buffer.  Are there any plans
to allow ckermit to use a larger buffer such as 4KB?

[Ed. - MacKermit can receive packets up to 1KB and send packets up to 2KB.
As of today, you can get the sources and increase these sizes, which are
just symbols defined in CKCKER.H, MAXRP and MAXSP respectively, recompile,
and try it out.  Satisfaction not guaranteed (very long packets sometimes
give poorer performance -- you have to find the optimum length for your
setup.)]

Does the vt100 terminal emulation mode honor flow control? I have never had
a problem transfering files but the terminal mode frequently trashes the
screen.

[Ed. - As of today, yes.]

Would you consider changing the terminal mode so that if the user types a
control-S, the terminal immediately stops displaying new characters?  With
the large buffer in the modem, you can type a control-S and then wait for
several screenfuls until the buffer clears.

[Ed. - The new version, 0.9(40), does not do this.  At 9600 baud, anywhere
from a line or two up to nearly a screenful goes by before the XOFF takes
effect, depending on how much the Mac itself has buffered up internally (it
has a biiiig input buffer.  Future versions might have a feature like this,
similar to the VT100 No Scroll button.]

Is there an escape sequence to activate the printer on the Mac and
automatically print whatever is appearing on the screen?

[Ed. - No, ANSI printer control is on the list of ideas for future versions.]

Thanks!!
Howard

------------------------------

Date: Wed, 13 Apr 88 20:32:20 EDT
From: Caroline Arms <[e-mail]>
Subject: Linefeed problem with MacKermit 0.9(36)B4
Keywords: MacKermit 0.9(36)b4, Key Redefinition

I don't seem to be able to set a key to the linefeed character () -
or rather the LF looks as though it gets converted to a CR (or CR/LF)
before transmission.  I had no such problem with the earlier version of
MacKermit I had been using - 0.8(35).  Is this is a bug or a feature?

[Ed. - Neither, at least not in the new version.  Maybe you didn't notice
that control characters should be entered as octal, rather than decimal,
numbers.  Also, in the new version, you can enter them symbolically, e.g.
\^J for linefeed, \^M for carriage return, etc.]

Apart from that, the new version seems to be a substantial improvement.

Caroline Arms   CA0L@CMUCCVMA

------------------------------

Date: 2 May 88 23:02:41 GMT
From: [e-mail] (Thomas Sj|land)
Subject: Kermit Between Macintosh and UNIX, Slight Problem
Keywords: MacKermit

I tried to use kermit to transfer a (MacWrite-)file from a Macintosh to a
SUN and back again and found some problems:

(I used kermit -u on the sun).

[Ed. - "kermit -u" ???]

1. Kermit lost information present in the Macintosh files without informing
   the user and asking whether that was OK (probably the user is naive, since
   smart users seem to use other protocols according to my minisurvey in
   the surroundings here :-).

[Ed. - The problem is that the user did not tell Unix Kermit to receive the
file in binary, rather than text mode.  Use "kermit -ir", for instance.
You'd need a smart protocol indeed to receive files from a foreign system
and know whether they are text or binary!]

2. Kermit transformed names in upper case letters on the Mac to lower case
   on Unix without informing about this. (Again, Macusers expect more info
   about what is going on than traditional users. The Mac-Kermit should
   be more user friendly here.

[Ed. - Maybe so, but the default action is even friendlier.  If the file
arrived at Unix in mixed case, your naive user might not know that case is
significant, and would not be able to refer to the file until s/he figured
this out.  If you prefer filenames to be transferred literally, you can
give Unix Kermit users an initialization file (.kermrc) that includes the
command "set file names literal".]

3. When transferring the file back to the Mac, Kermit destroyed the
   original file, again without informing the user about what was going on.
   (The mapping of filenames was involved here).

[Ed. - This is NOT the default action.  Someone customized your user's
MacKermit to do this.  Normally, MacKermit will append a dot and a number to
any incoming file that has the same name as an existing file.]

- Are there versions of Kermit for the Mac around that do a better job on
  keeping all information stored in a Mac-file, when transferring to a
  file system like the one of Unix?  Note that one might well want to use
  the Unix system as a buffer for files to be downloaded on another Mac,
  and Kermit ought to be able to handle the situation.

(Yes, I know that one can use PackIt or BinHex before sending files, but
 if that is needed, I think Kermit should warn the user when he is about
 to make a stupid mistake.)

[Ed. - No, not yet.  Something like this is on the list for a future
release.  Probably MacKermit will be able to convert to/from MacBinary while
sending and receiving.  This does not mean you can't transfer Mac
applications directly with Kermit, only that it's a bit cumbersome.]

Opinions ?

[Ed. - Always welcome, as are suggestions, complaints, and praise.  But
remember -- these programs are done by volunteers in their spare time!]

Thomas Sj|land
SICS, PO Box 1263, S-164 28 KISTA, SWEDEN
Tel: [phone]    Ttx: 812 61 54 SICS S    Fax: [phone]
Internet: [e-mail] or {mcvax,munnari,ukc,unido}!enea!sics.se!alf

------------------------------

Date: Fri, 15 Apr 1988 11:18:56 IST
From: "Jonathan B. Owen" <[e-mail]>
Subject: 8-Bit Asynchronous Communication with Parity Bit
Keywords: RS-232, Asynchronous Communication, Data Bits, Parity

I keep reading all too often of people writing that 8-bit communication is
mutually exclusive with a parity bit.  Actually, each frame, or character
transmitted over an asynchronous link starts with a Start-Bit followed by 7
or 8 Data-Bits, followed by an optional Parity-Bit, and finally terminated
with 1, 1.5 or 2 Stop-Bits.  In effect, besides the framing bits, a maximum
of 9 bits are possible for each character.

The reason I write this, is because I wanted to use Mac-Kermit 0.9(36) with
an IBM/370.  Apparently, you cannot set 8 bit communication with Mac-Kermit.
Also, I ran across another program on the Mac which lets you select EITHER 8
bit communication or 7 Bit with Parity, which is ridiculous (can't remember
name of program off hand).

I hope this letter clears things up a bit (or 9 bits!).

Email: gdau100@bguvm (bitnet)
Snail: 6/15 Mendelson, Tel-Aviv  Israel
Voice: [phone]
Jonathan B. Owen

[Ed. - I guess it depends on who sets the standards.  According to ANSI
X3.16-1976, "Character structure and character parity sense for
serial-by-bit communication", there are two environments: 7-bit and 8-bit.
In the 7-bit environment, each character should contain 7 data bits, a
single parity bit, plus a start and stop bit (section 3.1).  In the 8-bit
environment, you get the start bit, 8 data bits, and a stop bit.  "There is
no parity bit in the 8-bit environment" (section 3.2).  In real life, of
course, you can transmit whatever you like.  For instance, the 8250 UART in
the IBM PC allows for 5, 6, 7, or 8 data bits, with or without parity.  The
key consideration is that the receiver be programmed exactly like the sender
as to the number of start, data, parity, and stop bits.  Much hardware, and
most software, is designed according to the ANSI standard, and therefore
allows 7 bits with parity, or 8 bits with no parity.  The asynchronous
serial interfaces found on IBM mainframes (3705 TTY lines, 7171 protocol
emulators, etc) all use 7 data bits with parity.  You can definitely use
MacKermit to communicate with IBM mainframes in either mode, but certain
beta test releases of 0.9(36) had bugs relating to parity, which are fixed
in 0.9(40).]

------------------------------

Date: Fri, 20 May 88 08:07:33 EDT
From: [e-mail] (Ralph Hyre)
Subject: Does Windowed Kermit Exist?
Organization: Carnegie-Mellon University, CS/RI

I have a 19.2kbps 8-bit-transparent connection from my office to home.
(Bell of PA's Metropolitan Campus Network - I believe it's based on Project
Victoria technology - it will be upgraded to 64 kbps Real Soon Now.)

I sometimes transfer files using Kermit [4D(061) on a 4.3 Vax, MacKermit
0.7(21)], but the transfer times seem unreasonably long.  A minor glitch
is that the Kbyte estimates on the Mac are double what they can (and should)
be in reality.  The main problem is that my effective data rate is around
200 cps, when I'd expect at least 1000 cps.  The seems to be mostly because
there can only be one outstanding unacknowledged packet.  This makes the
effect of other delays in the system (mainly the intermediate routers and
terminal concentrators in between) intolerable.

Is there some Kermit variant that is available for Unix machines and Macs
that will support a 'window' (outstanding unacknowledged data, which is
presumably accounted for at some later time.)

This all makes X/Y/Z/MODEM/7 looks awfully tempting, since I know I have an
8-bit transparent path, except of course the MacTerminal I'm using makes it
practically impossible to download to disk other than the one MacTerminal is
on.  I'd rather fight than switch.

Thanks for any pointer and help you can provide.

                    - Ralph W. Hyre, Jr.

Internet: [e-mail]    Phone:(412)268-{2847,3275} CMU-{BUGS,DARK}
Amateur Packet Radio: N3FGW@W2XO, or c/o W3VC, CMU Radio Club, Pittsburgh, PA

[Ed. - When there are long round trip delays, a full-duplex sliding window
protocol is the best solution.  We hope that sliding windows will be added to
C-Kermit (and therefore Unix and Macintosh Kermits) in the next few months.
But then, we've been saying that for two years.  Meanwhile, long packets are
better than short packets, so try them in the current releases of Unix and
Macintosh Kermits.]

------------------------------

Date: 24 Apr 88 20:09:51 GMT
From: [e-mail] (Gadi )
Subject: Bi-directional Protocols
Keywords: Bi-directional Protocol

Does anyone know about a bi-directional protocol?  It seems to me that
having a MODEM or KERMIT type protocol running in both directions over a
phone link would double the thoughput.  I was thinking of this mostly with
respect to passing FIDONET, UUCP, etc mail.  Is there any reason why such a
protocol won't work?

                                          Gadi

uucp:   {ames, cbosgd, harvard, moss}!rutgers!aramis.rutgers.edu!friedman
arpa:   [e-mail]

[Ed. - Kermit and Xmodem would take some massive redesigning to transfer
files bidirectionally, to the extent that they wouldn't be Kermit or Xmodem
any more.  Once you leave the public arena, you can find some protocols that
claim to do this, like Blast.]

------------------------------

From: Gisbert W.Selke ([e-mail])
Date: 27 May 1988
Subject: Modcomp Kermit - A Bug and Two Suggestions
Keywords: Modcomp Kermit

I think I found a bug in Modcomp Kermit which sometimes caused it to crash a
file transfer without necessity. I think I've fixed it, and I've written a
letter to the authors for clearance.  The letter is appended below, together
with the fixed routine (SDATA).  In addition, I think one can make Modcomp
Kermit cope better with a particular Modcomp peculiarity (viz., using Ctrl-A
as a signal to the terminal maintenance processor - the standard Kermit
start of packet must be set to something different because every once in a
while TMP saw a Ctrl-A before Kermit could grab it).  One can do without
this change; but I think it's worth it for the sake of conformity to the
rest of the Kermit world.  Finally, an assembly-language subroutine has been
recoded into Fortran.  I'd like to hear suggestions from people more
knowledgeable than myself, though, before I proceed and install this change.

[Ed. - Thanks, Gisbert!  Your letter, with the suggested fixes, has been
placed with the Modcomp Kermit files as MODCMD.BWR.]

------------------------------

End of Info-Kermit Digest
*************************
-------
29-Jun-88 19:06:33-EDT,20270;000000000000
Mail-From: SY.CHRISTINE created at 29-Jun-88 19:05:00
Date: Wed 29 Jun 88 19:04:59-EDT
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest V7 #15
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 29 Jun 1988       Volume 7 : Number 15

Today's Topics:

                      Utility Program for Prime Tapes
                      RE: VAX C-Kermit Over X.25 PADs
                      RE: VME/10 Kermit Under Versados
                Bug in CD3KER vs. 3.4, CDC Cyber Nos Kermit
               Problems with Downloading Commodore 64 Kermit
                             MS Kermit and OS/2
              8-Bit Asynchronous Communication with Parity Bit
                  Bug in Macintosh Kermit Version 0.9(40)
                 Apple II Kermit and the Super Serial Card
                RE: Setting Flow Control for EMACS in Kermit
                            Kermit Over Networks
                       Automatic ISO 8859 Conversion

Send digest submissions to Info-Kermit@CU20B, requests for addition to or
deletion from the Info-Kermit subscriber list to Info-Kermit-Request@CU20B.

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host CU20B, CU20B.COLUMBIA.EDU, or
CU20B.CC.COLUMBIA.EDU (a DECSYSTEM-20), as user ANONYMOUS, using any password,
and GET the desired files from logical device KER:.  You can also get Kermit
files over BITNET/EARN; to get started send a message with text HELP to
KERMSRV, the Kermit file server, at host CUVMA.  For detailed instructions,
read the file KER:AANETW.HLP (AANETW HLP on KERMSRV).  To order by mail,
request a complete list of Kermit versions and an order form from Kermit
Distribution, Columbia University Center for Computing Activities, 612 West
115th Street, New York, NY 10025 USA.

----------------------------------------------------------------------

Date: Fri, 10 Jun 88 17:51:04 PDT
From: Bob Larson <[e-mail]>
Subject: Utility Program for Prime Tapes
Keywords: Prime, tape utility program

Prime now supplies a utility (ux_tape) to read and write UNIX tar and cpio
tapes with the latest version of primos (21.0.2 and 21.0.3).  The bugs in the
21.0.2 version probably make in unusable, but it looks like tar tapes will be
a reasonable alternative to the program to read ANSI tapes that you currently
are supplying for Prime systems.  (21.0.3 has only been available a couple of
weeks, and most sites are still running pre-21 primos.)

------------------------------

Date: Sat, 21 May 88 14:39:59 EDT
From: elsie![e-mail] (Arthur David Olson)
Subject: RE: VAX C-Kermit Over X.25 PADs
Keywords: C-kermit

Re: Info-Kermit Digest V7 #12:

> We have a (*very* slow) VAX-11/780 running VMS 4.7; terminals connected to
> X25 PADs and make X29 calls into the VAX. We have all our lines set for 9600
> baud. C-Kermit works OK with normal packet sizes, and it sends files *to* the
> PC with 250 byte packets OK. However, trying to use any packet size about 200
> bytes or so *from* the PC results in repeated retries; the log shows that the
> VAX is giving "Data Overrun" errors on about 1 in 3 packets.

The same sort of thing happens with PCs connected via DZ11s; the VAX just
can't drain the DZ11's silo fast enough, resulting in silo overflow.

So. . .here at elsie we don't even try; we've set MAXRP to 94.

   *** 1.1/ckcker.h    Sat May 21 14:37:26 1988
   --- 1.4/ckcker.h    Sat May 21 14:37:28 1988
   ***************
   *** 26,31 ****
   --- 26,35 ----

     #define MAXSP 2048            /* Send packet buffer size  */
     #define MAXRP 1024            /* Receive packet buffer size  */
   + #ifndef ASWAS
   + #undef MAXRP
   + #define MAXRP 94            /* ...or suffer buffer overruns */
   + #endif /* !defined ASWAS */
     #define MAXWS 1                /* Maximum window size */

     /* Kermit parameters and defaults */
--
    Canada's program is to spaceflight as the carrier pigeon is to mail.
    [e-mail]            ADO is a trademark of Ampex.

[Ed. - Thanks....  It has been added to KER:CKVKER.BWR.]

------------------------------

Date: Thu, 19 May 88 19:53:50 {o
From: [e-mail] (Alan Martello)
Subject: RE: VME/10 Kermit Under Versados
Keywords: VME/10 Kermit

Response to inquiry in digest V& #5 concerning VME/10 Kermit under Versados

Motorola has now included the KERMIT protocol in the TRANSFER command for
release 4.6 of Versados (untested, but according to the 4.6 doc.).  I have
not tried to run this since all the Versados machines I use are frozen at
Version 4.5, but from previous experience with Motorola supplied software, I
would not hold my breath.  I did not attempt to run the executable from 4.6
under 4.5 since the 4.6 documentation indicated that a new device driver
call to handle character I/O more reasonably was added to Versados 4.6,
although it did not mention Kermit explicitly.

(*FLAME ON* I made the assumption that Motorola could not easily port Kermit
without adding the new driver call since Versados handles just about all its
I/O in a brain-damaged fashion. *FLAME OFF*)

I would give Versados 4.6 a try if you have it available, but remember that
Motorola is the same company that provided the tape backup support which I
used to save a corrupted Fujitsu Eagle (150 MB) under Versados only to find
that their restore program could only read the first tape of a three volume
save set!!!  (I guess they never tried to read more than 60 MB of
information).

Good Luck!

Alan Martello
University of Pittsburgh

UUCP: { akgua | allegra | cmcl2 | idis | ihnp4 | mi-cec | pitt
    psuvax1 | sun | sunrise | vax135 } ! cadre ! arm
ARPA: [e-mail]

DISCLAIMER - the views expressed above concerning Versados and Motorola
software are entirely my own after working with their '680x0 development
environment' for three years.

------------------------------

Date: Fri, 27 May 88 14:00:48 -0800
From: ames!tis.llnl.gov!lll-tis!lll-crg!lll-winken!uunet!convex!otto!jimi!unsvax.uucp![e-mail]
Subject: Bug in CD3KER vs. 3.4, CDC Cyber Nos Kermit

I have been installing the latest Kermit distribution for CD3KER vs. 3.4
for the CDC Cyber NOS systems and I discovered an error in the CD3KER.MOD
file. The problem concerns the fact that the modified array SETTYP must be
in alphabetical order for the Fortran subroutine MATCH to work correctly.
To fix the file CD3KER.MOD replace the following four lines -

*D 1041
     +    'TEXT-MODE', BIN-MODE', 'EOR-EOF-MODE' /
*D 1046
      GO TO (20,30,40,10,50,70,75,80,90,100,110,120), INDX

with the following six lines -

*D 1039,1041
      DATA SETTYP /  'BIN-MODE', 'DEBUG', 'DELAY', 'DUPLEX',
     +    'EOR-EOF-MODE', 'FILE-MODE', 'INIT-RETRY', 'RECEIVE',
     +    'RDELAY', 'RETRY', 'SEND', 'TEXT-MODE' /
*D 1046
      GO TO (110,20,30,40,120,10,50,70,75,80,90,100), INDX

I should add that I have installed CD3KER vs. 3.4 on an older Cyber NOS
l647 and everthing seems to work except for the CDCNET versus NPU test
in Program KRM0100.

Dave Bartlett
UNS Computing Services
[e-mail], [e-mail],
or via BITNET as AC34U05@UNEV

[Ed. - Thanks.  Your message has been put in KER:CD3KER.BWR.]

------------------------------

Date: Sat, 04 Jun 88 23:28:29 MET
From: Jos Grote Punt <[e-mail]>
Subject: Problems with Downloading Commodore 64 Kermit
Keywords: C64 Kermit

Many people have a problem with dowloading and converting C-64 Kermit. The
cause is a bug in the file C64DXL.HEX. In the file C64KER.HLP it says that
with C64DXL.BAS you can convert this hexdump file into a hexdump loader. With
this loader (called C64DXL.C000) you can then convert C64KER.HEX to a running
version of Kermit. The help file states that you should save the file with the
last address displayed by C64DXL.C000. You will never see this address because
of the bug. It works ok if you change $00 on address $C20A in $60 (BRK changed
in RTS).

Besides that there's another problem with C64KER.HEX. This file is in the so
called MINMIC hexdump format, where a every line looks like this:
  1. A ';' that marks the beginning of the line
  2. The number of data bytes
  3. The adress (in HIGH-LOW format) from which this line is to be loaded
  4. The data bytes itself (A-F in uppercase)
  5. Two-byte checksum (HIGH-LOW format), being the sum of all other bytes

The last line has a 00 as the number of data bytes. So, what's wrong with
C64KER.HEX? It has two databytes less than above item 2 says! Result: the hex-
dump file loads ok, but the checksum can't be checked. This means that if you
were lucky and there was no error during the download of C64KER.HEX than the
resulting Kermit will work, in the other case you have a big problem! The
strange thing is that the file C64DXL.HEX is allright.
I hope this info can help some people.

Jos Grote Punt
Faculty of Medicine
University of Nymegen
The Netherlands

[e-mail]

[Ed. - Many thanks for the report!  It's been added to the C64KER.BWR file.]

------------------------------

Date: Thu, 21 Apr 88 11:46 PDT
From: [e-mail]
Subject: MS Kermit and OS/2
Keywords: MS-Kermit, OS/2

Has anyone begun development to enable MS-Kermit to be multitasked under
OS/2?  If so, estimated time schedules?  Please CC: me directly as I don't
often read this digest.  Thanks.

David J. Buerger
Santa Clara University
[e-mail]

[Ed. - This is a popular question.  Someone has been working on porting
C-Kermit to OS/2 and this should be available shortly.  In the longer term,
some thought is being given to adapting MS-Kermit to full OS/2 compatibility,
but this will take some time.  Meanwhile, it's possible that "WINKRM" -- the
MS-Windows version of Kermit -- can be used under OS/2 to transfer files
while other processes are active, as it can under Windows itself.  A new
version of WINKRM has just arrived and will be announced as soon as it's
installed.  Meanwhile, the current version of MS-Kermit runs in DOS
compatibility mode under OS/2.  As Joe Doupnik reports "Throughput seems
terrific, given my DOS AT on one side and the Model 80-111 running OS/2 on
the other.  A 9600 baud line yielded about 8400 effective for a long text
file.  The only difference so far is if one asks a Kermit server to write to
a protected disk the OS/2 error menu pops up rather than letting Kermit
manage it; telling OS/2 to let the error flow to the program yields Kermit's
normal graceful recovery."]

------------------------------

Date: Fri, 15 Apr 1988 11:18:56 IST
From: "Jonathan B. Owen" <[e-mail]>
Subject: 8-Bit Asynchronous Communication with Parity Bit
Keywords: RS-232, Asynchronous Communication, Data Bits, Parity

I keep reading all too often of people writing that 8-bit communication is
mutually exclusive with a parity bit.  Actually, each frame, or character
transmitted over an async. link starts with a Start-Bit followed by 7 or 8
Data-Bits, followed by an optional Parity-Bit, and finally terminated with
1, 1.5 or 2 Stop-Bits.  In effect, besides the framing bits, a maximum of 9
bits are possible for each char.

The reason I write this, is because I wanted to use Mac-Kermit 0.9(36) with
an IBM/370.  Apparently, you cannot set 8 bit communication with Mac-Kermit.
Also, I ran across another program on the Mac which lets you select EITHER 8
bit communication or 7 Bit with Parity, which is rediculous (can't remember
name of program off hand).

I hope this letter clears things up a bit (or 9 bits!).

Email: gdau100@bguvm (bitnet)
Snail: 6/15 Mendelson, Tel-Aviv  Israel
Voice: [phone]
Jonathan B. Owen

[Ed. - In theory, you're right.  In practice, it depends on the UART.  Many
UARTs simply do not give you the option, or even if they do, the
corresponding device drivers do not.  Nor do most modems, PADs, or other
communication equipment.]

------------------------------

Date: Sun, 19 Jun 88 21:53:42 +0100
From: Eamonn McManus <[e-mail]>
Subject: Bug in Macintosh Kermit Version 0.9(40)
Keywords: MacKermit 0.9(40)

There is a trivial but annoying bug in Mac Kermit 0.9(40), as released to
comp.binaries.mac on Usenet.  (The version says it is Kermit version 0.9(40),
04/05/88 11:51.)  The default settings for tab stops place the last one at
column 71 (zero-origin) rather than 72 as it should be.  Most of the time
this doesn't show up (which is presumably why the bug hasn't been fixed so
far) but it is quite noticeable in editors like vi that attempt to optimise
cursor motion, frequently by using tabs.

Here is a patch that fixes the bug.  The version of ckmcon.c is that from
0.9(36)b4 but I assume it hasn't changed.

Since I don't have the 0.9(40) sources, I've had to patch the binary.  This
involves editing block 132(dec) and changing byte 0x19c to a 0, and byte
0x19e to a 1.

Eamonn

[Ed. - Thanks.  Your message has been put in KER:CKMKER.BWR.]

------------------------------

Date: Wed, 16 Mar 88 15:54 N
From: [e-mail]
Subject: Apple II Kermit and the Super Serial Card
Keywords: Apple II Kermit

I am attempting to load and run KERMIT on an Apple IIe minicomputer.  The
documentation for KERMIT in the file APPLE.DOC hints about some possible
problems to be encountered in this situation, especially when using the
APPLE SUPER SERIAL CARD.  Please send suggestions and/or newly updated
documentation for the installation of KERMIT on the APPLE IIe.

As a secondary attempt I have installed a Z-80 coprocessor card into my
Apple IIe.  I have then tried to use the Kermit programs: CPMAPPLE, CPMPLUS,
CPMGENER, and KERMIT version 4.3, all without success.  The KERMIT programs
load properly, but will not execute the CONNECT command without hanging up.
Both the SSC card and CPM card and these versions of KERMIT work properly on
an APPLE II+ in our laboratory.

Thank you for your assistance and cooperation.

Sincerly yours,

Timothy Good         Centre de Recherches en Physique des Plasmas
                         Lausanne, Switzerland
Bitnet address: SIEGRIST@CLSEPF51

[Ed. - From Ted Medin, maintainer of Apple II Kermit: The super serial card
and driver are probably the most bullet proof part of kermit-65. Since it
works on the //+ and not the //e i suspect they have hardware problems with
their //e. I use the //e or //e+ all the time and am using it right now with
a super serial card. Is there a difference with export models of the //e????]

------------------------------

Date: Tue, 5 Apr 88 17:53:39 EDT
From: [e-mail] (Paul Placeway)
Subject: RE: Setting Flow Control for EMACS in Kermit
Keywords: Flow Control, EMACS

< >[Ed. - The real, though painful, workaround is to SET FLOW NONE before you
< >start EMACS, and SET FLOW XON/XOFF when you exit EMACS, see below.]

< How about some escape sequence the host can send to Kermit to turn
< flow-control on and off.  Emacs (GNU Emacs anyway) can be configured
< to send such a sequence when entering or exiting.

The _best_ way is to make your micro use a real big serial input queue (that
is what MacKermit does).  If you can't do that, then if you are running Gnu
Emacs, there is a _much_ better way to deal with this: In your .emacs (for
Unix system; VMS uses some other name), include:

;;; for stupid ^S and ^Q problems (sets ^^ to be ^Q, ^\ to ^S,
;;; ^S to ^\, and ^Q to ^\, and makes ^\ ignored).
;;; NOTE: the second line of the string must NOT be indented!!
(setq keyboard-translate-table
"\000\001\002\003\004\005\006\007\010\011\012\013\014\015\016\017\
\020\036\022\036\024\025\026\027\030\031\032\033\023\035\021\037")
(global-set-key "\036" 'ignore)

and get used to typing ^\ for I-Search and ^^ for Quote.  I also remember
some way of making emacs actually use ^S and ^Q for flow control, but I
can't remember off the top of my head.

        -- Paul

------------------------------

Date: Fri, 24 Jun 88 16:34 CST
From: [e-mail]
Subject: Kermit Over Networks
Keywords: MacKermit 0.9(40), MS-DOS Kermit 2.31

I am looking for communications programs, preferably versions of Kermit,
that can connect from PC compatibles or Apple Macintoshes to VAXen across an
Appletalk (Localtalk) network.  Specifically, our configuration is this: In
several administrative offices at the college, we are adding small Phonenet
networks (running Appletalk protocols) primarily to allow sharing of Apple
LaserWriters.  In the new construction, there is only one data port
connection in the wall for each computer, so connection to the VAXen should
be through the local network.  The VAXen are connected to the Appletalk
(LocalTalk) network through Ethernet via a Kinetics FastPath.  The
microcomputer software will be either TOPS or Appleshare.  The VAX
connection is very simple, just VT100 emulation and standard Kermit server
file transfers.  Kermit-MS version 2.30 has support for NetBIOS local area
networks, but not for Appletalk.  MacKermit 0.9(40) seems to have no LAN
support.  If you have an Appletalk-aware version of Kermit, or if you can
comment on any Appletalk-aware communications packages, please let me know.
I read Info-Kermit regularly, but it may be difficult to reach me through
the network, so please respond to:

        Sande Nissen
        Computer Center
        Carleton College
        One North College Street
        Northfield, MN  55057
        [phone]
    net: [e-mail]

[Ed. - Appletalk support is not in MacKermit currently, but it's on the
"wish-list."  For MS-Kermit, the best solution would be an independent
BIOS-level device driver which Kermit could take advantage of using either
its built-in BIOS or NetBIOS support (SET PORT BIOSx, SET PORT NET).  Is
anyone aware of work going on in this area?]

------------------------------

Date: 1 Jun 88 11:47:08 GMT
From: mcvax!rhi.hi.is![e-mail] (Fridrik Skulason)
Subject: Automatic ISO 8859 Conversion
Keywords: ISO Standards, Character Sets
Organization: University of Iceland (RHI)

Regarding a recent note about automatic text conversion to ISO 8859/1.

As a matter of fact, we did just this here in Iceland a few years ago, while
this standard was still known here just as "ECMA code". The reason was of
course, that the first PCs had arrived here, and we often had to transfer
text to/from our VAX, which used modified 7 bit ASCII.

Later we added a translation table to Mackermit, where a small problem
appeared, namely that not all characters in the Mac character set could be
translated into ISO codes. This problem was simply ignored, and all
"untranslatable" characters were just translated into a single "junk"
character. The reason was simply the low frequency of those characters in
normal text ( << 0.1%)

As a matter of fact, we are back to using the original unmodified VAXkermit
(on our two VAXes) and Ckermit (on our HP9000), since we now use ISO 8859/1
on those computers, and therefore no translation is needed there. (Well -
almost unmodified - I think we had to delete one instruction which stripped
off the eight bit somewhere.)

ISO 8859/1 is very popular here in Iceland (Not surprising, since it is the
first major international character set standard which supports all our
special characters) We are getting tired of having to modify everything
else, like the HP Roman8 or the IBM/PC character set, so please make this
change to Kermit (or better still - start using 8859/1 on your computers).

         Fridrik Skulason          University of Iceland
         UUCP  [e-mail]      BIX  frisk

------------------------------

End of Info-Kermit Digest
*************************
-------
 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
*************************

 6-Jan-89 17:35:54-GMT,25375;000000000001
Received: by cunixc.cc.columbia.edu (5.54/5.10) id AA01146; Fri, 6 Jan 89 12:16:38 EST
Date: Fri, 6 Jan 1989 12:16:37 EST
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V9 #1
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Fri, 6 Jan 1989       Volume 9 : Number 1

Today's Topics:

            Announcing MS-DOS Kermit 2.32
              New German MS-DOS Kermit Help File
           MS-Kermit and EIA flow control (RTS/CTS)
       MS-Kermit and the Public Domain MNP software emulation package.
             MS-Kermit and the Hyperion?
              Kermit Parity Negotiation?
              Kermit with Telebit Modem Support?
     VT100 setting file for MacKermit and the IBM 7171 protocol converter
           Some Responses to V8 #11 and Kermit-370
           Bug in Kermit-80 for Northstar Advantage

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 Dec 21 13:14:20 1988 EST
From: Christine Gianone <[e-mail]>
Subject: Announcing MS-DOS Kermit 2.32
Keywords: MS-DOS Kermit 2.32, IBM PC, DEC Rainbow, HP-150
Keywords: Grid Compass II, Victor 9000, Hebrew, Arabic

This is to announce version 2.32 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, the Victor 9000, and for "generic DOS".  This release replaces
version 2.31 of July 1988.  The majority of the work was done by Professor
Joe R. Doupnik of Utah State University, who also prepared the 2.29, 2.30,
and 2.31 releases.

Like previous releases, version 2.32 includes an advanced and efficient
implementation of the Kermit file transfer protocol, emulation of the VT102,
VT52, and Heath 19 terminals, as well as the Tektronix 4010/4014 graphics
terminals, a script programming language, and a wide variety of options,
settings, and other features.

New to version 2.32 are many bug fixes and internal improvements, and one
major new feature -- support, during CONNECT mode, for languages like Hebrew
and Arabic in which characters are displayed from right to left, plus
mechanisms to facilitate switching between character sets (and their
associated directions).  These new language features were adapted from work
done by Baruch Cochavy, IIT, Haifa, Israel, whose test version of "Hebrew
Kermit" was announced in Info-Kermit V8 #9.  The enhanced language support is
available through the new command SET TERMINAL DIRECTION, plus a new
ALTERNATE-ROM option for the SET TERMINAL CHARACTER-SET command, plus the
association of special predefined macro names with new private escape
sequences.

Other improvements include:
 - A new ASK command, prompts user to input data to a variable.
 - A new IF [NOT] EQUAL command compares string variables (use with ASK).
 - A new ASSIGN commands copies one variable to another.
 - Screens cleared by ESC [ 2 J are now saved in the rollback buffer.
 - Removal of Timeout and Hangup screen messages during script/macro execution.
 - A way to pass multi-word strings as single arguments to a macro.
 - A way to disable server timeout NAKs (while server waits to answer a call).
 - REMOTE LOGIN command (for use with Kermit servers that support it).
 - Miscellaneous improvements in the file transfer display.
 - Better color support during CONNECT.

Among the major bugs that were fixed are:
 - Problems with GOTOs and labels in script programs.
 - Ungermann-Bass Net/1 support.
 - Loss of data when receiving files to a printer.
 - Crashes resulting from overflow of script or macro buffers.
 - Crashes resulting from stray interrupts.
 - Victor 9000 now can do Tektronix graphics again.
 - More COM1/COM2 confusion cleared up (e.g. for PCjr).
 - Filesize and disk space computation with file attribute packets.
 - SET SEND TIMEOUT interference with file encoding and decoding.
 - Program should now be assemblable by MASM 5.1 as well as 5.0 and 4.0.

The changes since version 2.31 are described fully in the file MSR232.UPD.
The user manual, MSKERM.DOC (.MSS, .PS) has been revised to reflect the new
features.

This new release is available in both source and binary form.  It may be
ordered on diskette or magnetic tape from Columbia, and it may be obtained via
network file transfer over the Internet or BITNET/EARN.  On the Internet, use
FTP (user anonymous) to host CUNIXC.CC.COLUMBIA.EDU [128.59.40.130], CWD (or
CD) to the directory kermit/a.  On BITNET/EARN, send an interactive or e-mail
message to KERMSRV@CUVMA (the BITNET Kermit file server), containing the text
HELP, to get started.

The executable files are stored in a special printable format, called "BOO
files", suitable for BITNET file transfer, electronic mail, etc.  These are
decoded back into .EXE files using any of the MSBPCT "BOO-file decoder"
programs.  The documentation is available online in plain ASCII text format,
in Scribe text formatter source format, and in Postscript format.  Following
is a synopsis of the files.  The KERMSRV name is the same as the CUNIXC name,
except the CUNIXC name is lowercase with a period between the filename and
filetype, wherease the KERMSRV name is uppercase with a space separating the
filename and filetype, e.g. msaaaa.hlp on CUNIXC is MSAAAA HLP on CUVMA.

 CUNIXC Name   Size        Description

 msaaaa.hlp      7K        Explanation of file naming conventions
 msbaaa.hlp      4K        Explanation of bootstrapping procedure
 msb*.*        174K total  BOO-file encoding/decoding programs, many languages
 msvibm.boo    115K        IBM PC Kermit, BOO-encoded executable
 msvrb1.boo     83K        DEC Rainbow Kermit BOO file
 msvgen.boo     78K        Generic MS-DOS Kermit BOO file
 msvhp1.boo     77K        HP-150 (untested)
 msvgri.boo     78K        Grid Compass II (untested)
 mskerm.doc    333K        MS-DOS 2.32 Kermit manual, plain ASCII text
 mskerm.ps     489K        MS-DOS 2.32 Kermit manual, for Postscript printers
 mskerm.mss    323K        Scribe text formatter source for manual
 mskerm.hlp     16K        A summary of MS-Kermit commands
 mskerm.bwr     14K        List of known restrictions, bugs, etc.
 mss*.*        776K total  System-independent MASM Source files (12 files)
 msg*.*        128K        System-dependent source (Tektronix graphics)
 msu*.*      70-85K each   Sys-depn source (keyboard support, all systems)
 msx*.*     25-174K each   Sys-depn source (port i/o, etc, all systems)
 msy*.*     22-124K each   Sys-depn source (terminal emulation, IBM only)
 msz*.*     66-189K each   Sys-depn source (term emul, cont'd, IBM only)
 msv*.mak        2K each   Microsoft MAKE files for each version
 msv*.bat        2K each   Batch files to build each version
 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.

For the benefit of those who are still running version 2.29 and haven't
converted to later versions because the SET KEY syntax changed so drastically,
there is also a new file, MSVIBM.KEY, which lists the old (2.29) and new (2.30
and later) IBM keyboard scan codes.

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, V90, GEN, etc):

1. For everybody: The documentation -- MSKERM.DOC, MSKERM.HLP, MSKERM.BWR,
   MSR232.UPD.

2. The new Kermit program itself: MSVxxx.BOO (where xxx denotes the particular
   MS-DOS system: IBM, RB1, HP1, etc).

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).  Use MSBPCT.EXE to decode MSVxxx.BOO.

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 if and when 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.

FINAL WORDS:

Like any Kermit program, MS-DOS Kermit is for everyone to use and share.
There is no software license, and the program and documentation may be
reproduced and redistributed without restriction, so long as this is not done
for profit.  Please take or order the files you need.  If you're getting files
over a network, please be judicious -- don't ask for 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 (where
it's deserved) to Info-Kermit@CUNIXC (.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.

------------------------------

Date: Fri, 23 Dec 88 17:01:16 SET
From: [e-mail]
Subject: New German MS-DOS Kermit Help File
Keywords: MS-DOS Kermit 2.32, German

Enclosed is the updated German version of the MS-Kermit help file.

Here are a few notes on seeming glitches in the help file; none of them
serious, of course:

Section top-level commands:
CLOSE:   option "ALL" is missing

Section remote commands:
REMOTE LOGIN is missing
REMOTE SEND should really be REMOTE MESSAGE, I presume
Commands honoured by MS-Kermit server:
I cannot check this, since I don't have a suitable connection to a PC;
but I guess MS-Kermit will honour a HELP command?

Section SEND/RECEIVE parameters:
There is no SET SEND DELAY command - the appropriate command is just SET
DELAY.
TIMEOUT : time given is in *seconds*

Section SHOW commands:
TRANSLATION does not accept "INPUT" as a subcommand. TRANSLATION by
itself suffices.

Pretty minor stuff...

\Gisbert

[Ed. - Thanks, Gisbert, all corrections valid, and all are now in the new
(English) MSKERM.HLP.  The German version is in MSKGER.HLP.]

------------------------------

Date: Wed, 23 Nov 88 14:17:13 EST
From: John C Klensin <[e-mail]>
Subject: MS-Kermit and EIA flow control (RTS/CTS)
Keywords: MS-DOS Kermit 2.31

Our otherwise-several-times-qualified new ISDN phone system seems to strongly
prefer RTS/CTS to XON/XOFF, especially at higher speeds.  I looked at the
possibility of adding this to MSKERMIT many years ago (before you got actively
involved) and decided I was not motivated enough.  I'm now feeling motivated,
since AT&T claims significantly higher data throughput when hardware flow
control is used.

On the other hand, I don't want to do anything that would foul up or delay
the brilliant job you are doing, or whatever release schedule you have.  So:
should I pick up the sources for 2.31A from somewhere and go to work on them?
Or should I do this against the "released" 2.31 sources, or should I wait
until after 2.31A becomes "official"?

While I haven't looked at the code in 2-3 years, I assume that this type of
enhancement should impact only a single module, plus or minus the table(s)
that know what all of the options are.  If you can point me to the right
place, it would save a bit of time and be appreciated.

     Thanks,  John Klensin,  MIT

[From jrd - The place to look for hardware vs software flow control in all in
one file: msxibm.asm. We have just canned version 2.32 (nee 2.31/A) and
Columbia is sorting through the mountain of files I sent to them.

Hardware flow control is slightly more messy because we need to probe the
hardware for a signal level and to select sending a character vs wiggling a
wire. It would be interlocked with the real UART port, as contrasted with the
zillions of other port options now present (Bios and networks). It is do-able
fairly easily and cleanly. Have a go, with my blessing.]

Thanks.  I'll wait until the 2.32 sources appear, then go at it.  Your comment
about the messy-ness parallels a note that I sent to the local AT&T folks
yesterday: my experience with EIA flow control is that it works very well when
one has a controller organized s.t. one can get interrupts when the state of
the lines change.  When, as with the IBM PC UART, about the only thing one can
do is poll them, one is basically using EIA control to simulate Xon/Xoff
logic, with no real gain in performance and at a higher nusiance level.  But,
who am I to argue with the hardware folks....

On the tab stuff, I think that something like 1:8, or some other way of saying
"start with 1, increment by 8 until you get to the end" would be a lovely way
to spell "default", as well as solving many other problems (there are a few
word processing packages that could use similar suggestions).

[jrd: Yes, I understand. The tabs set by the host can be overridden by a
terminal reset, \Kreset, while in Connect mode. This is much like a real VT102
where the "setup" values are restored by a reset. When we set tabs at the
Kermit prompt level that is essentially the "setup" state for the emulator. A
default condition could be added to the SET TERMINAL command, where default
means every 8; actually I'd like an implied repeat count on the tabs 1:8 start
in col 1, repeat by skipping 8 columns, or something like that.]

Thanks again.
   john

------------------------------

Date: Sat, 17 Dec 88 23:43:06 +0200
From: Ze'ev "Steed" Shtadler <[e-mail]>
Subject: MS-Kermit and the Public Domain MNP software emulation package.
Keywords: MS-DOS Kermit, MNP Emulation Software

Looking in the SIMTEL-20 archives I found a software package that can make any
asynchronous modem an MNP Class-2 error-free modem.  This package is written
in Microsoft C and Assembler.  The telephone lines around here are noisy, and
it is very difficult to use Kermit as a terminal emulator (and I don't put the
blame on Kermit :-).  The modem on the other end of the line is an MNP modem,
but I couldn't use its error free option since I can only afford a regular
modem.  By putting the MNP emulation into Kermit I can have an error free
terminal too.

Did anyone try to combine Kermit with this package?  How complicated is
changing the serial I/O routines?

                                        Ze'ev.

                   ARPANET: [e-mail]
                   UUCP: ...!psuvax1!techunix.bitnet!steed
                   BITNET: steed@techunix
                   Domain: [e-mail]
                   CSNET: [e-mail]

[Ed. - This would probably be a BIG job, and would tax Kermit's terminal
emulator, which already does about 100 things with each character (see the
new diagram in the MS-DOS Kermit 2.32 User Guide).  However, you could
conceivably use this program "under" Kermit, in conjunction with an ANSI.SYS
or NANSI.SYS or similar console driver, and then pop back up to Kermit when
you need to transfer files.]

------------------------------

Date: Thu, 15 Dec 1988 15:52 EDT
From: Mark Bramwell   519 661-3714 <[e-mail]>
Subject: MS-Kermit and the Hyperion?
Keywords: Hyperion, MS-DOS Kermit

I have recently picked up a Hyperion portable computer.  This is a MS-DOS
machine whose day has come and gone.  It has 256k, built-in monitor, serial,
parallel, and 2 360k floppy drives.  The unit boots ok with PC-DOS 3.1 and
PC-DOS 4.0

The serial port is not exactly IBM compatible.  If I put a break-out on
the serial port and type in the command   DIR > COM1:
I can see data coming from the port.  However, kermit says COM1: NOT
AVAILABLE.

Question:  Is there ANY version of kermit that will run on the hyperion?
           Does anyone know the IRQ and BASE address of this box so I
           can try patching a comm package?

There were two versions of the hyperion, and I have one of each.  Slight
BIOS change between the two.

[Ed. - Several things to try: (1) Use Generic DOS Kermit, rather than the
IBM PC version; (2) Use the IBM PC version, but try giving the command
"SET PORT 2", or if that doesn't work, "SET PORT BIOS1" or "SET PORT BIOS2";
(3) get the latest source code and add Hyperion support to it.]

------------------------------

Date: Mon, 28 Nov 88 10:56 MDT
From: Pete Klammer 303/556-3915 <[e-mail]>
Subject: Kermit Parity Negotiation?
Keywords: Kermit Protocol, Parity

Just about the last frontier of KERMIT user friendliness is parity.  Would it
be possible for KERMIT to automatically sense or set or negotiate parity?
Getting parity right is the "final frustration".

We have MS-KERMIT v2.31, VMS KERMIT-32 v3.3.111, PRIME KERMIT v1.04.1,
C-KERMIT on various UNIXen, etc.  Our "least-common-denominator" parity
setting recommendation is 7-BIT EVEN.  But when we log into VMS, it is through
a DECserver-500 ethernetted to the VAX, and the parity is effectively
concealed from VMS: SET TERM and SHOW TERM will not budge VMS's stubborn
notion that our terminal parity is NONE.  So when we crank up VMS KERMIT into
SERVER mode, it is thinking PARITY NONE, while our PC KERMIT is still thinking
PARITY EVEN.  Any GET, SEND, or REMOTE commands now retry fruitlessly.
Couldn't the guy in PARITY NONE mode step down into EVEN or ODD for a couple
of retries?

 * --poko       Pete Klammer, Systems Programmer, [phone]
 *              CU-Denver Computing Services / Campus Box 169
 *              1200 Larimer St NC2506 / Denver CO 80204-5300
 *              BITNET%"PKLAMMER@CUDENVER"
 *              INTERNET%"[e-mail]"

[Ed. - Agreed.  As you noted, the system that is running the Kermit
program cannot necessarily be aware of what parity is being used, even by
itself.  Thus, negotiation wouldn't necessarily work.  But a heuristic can be
used instead -- anyone who wants to is welcome to try it.  The leading control
fields of the packet (MARK, LEN, SEQ, and TYPE) are always 7-bit characters.
Thus the receiver of a packet can deduce that parity is in use if any of these
characters have their 8th bit set.  In fact, by finding any two characters in
this set that would have opposite parity sense, you could even determine which
kind of parity (even, odd, or mark) is being used.  The only pitfall here is
distinguishing "space" parity from no parity.  This trick also assumes,
possibly incorrectly, that a system wants you to send it the same kind of
parity that it is sending to you.]

------------------------------

Date: 16 Dec 88 08:51:06 GMT
From: versatc![e-mail] (Tony Tran)
Subject: Kermit with Telebit Modem Support?
Keywords: Telebit, Modems

Does anybody have a version of kermit which supports the Telebit Trailblazer
modem at 19.2kb ? Ours only supports up to 9.6kb.

I would appreciate any hint or sources sent to my following e-mail address.

  Tony Tran
  Versatec, Inc.
  Santa Clara, Calif.
  {sun|ames|pyramid|ubvax}!versatc!tran

[Ed. - All versions of Kermit already work OK with the Telebit.  But
Unix Kermit only lets you give SET SPEED commands up to 9600, whereas the
Telebit can run at 19,200.  The trick is just to add the (nonstandard) symbols
for 19,200 baud to the C-Kermit source and recompile, e.g. as outlined by
[e-mail] (Sergei A. Gourevitch), whose message on the subject has
been added to the ckuker.bwr file.  The Telebit modem, by the way, actually
executes the Kermit protocol between the modem and the computer, and its own
"PEP" protocol between the modems.  Thus the Kermit you run (say) on your PC
is actually trading packets with the Kermit in the modem, not the Kermit on
the other end of the connection.]

------------------------------

Date: Fri, 16 Dec 88 00:48:48 IST
From: "Jonathan B. Owen" <[e-mail]>
Subject: VT100 setting file for MacKermit and the IBM 7171 protocol converter
Keywords: MacKermit 0.9(40)

This file is a Kermit 0.9(40) document containing key definitions
for emulating a VT100 terminal to be used with a 7171 IBM protocol
converter.  Note that this is for use with an extended keyboard only.

The keys defined are as follows:

    F1 thru F12    --    Use to access IBM Function keys
    Clear key      --    Clear Screen
    Arrow keys     --    Moves cursor around screen
    Help/ins       --    Toggle Insert/Overstrike Mode
    Home           --    Moves to first field in Panel
    Page Up/Down   --    Same as pressing F7/F8 respectivly
    End            --    Sends <CR> BOTTOM <CR> (useful in XEDIT)
    Del            --    Delete Char. under cursor
    F13            --    Toggles between CP and VM modes
    F14            --    Same as Clear Key (See above)

Also, definitions useful for modem users:

    <Option><ESC>  --    Sends +++ to the modem (Hayes escape sequence)
    <Option> h     --    Sends "at h" for hanging up line

                            Hope this helps out...

  (--)    /--)     /-(\                 Email: gdau100@bguvm (bitnet)
  \ /    /--K      | \|/\   /\/) /|-\   Snail: 55 Hovevei Zion
  _/_/o /L__)_/o \/\__/  \X/  \_/ | |_/        Tel-Aviv, 63346  ISRAEL
 (/        Jonathan B. Owen             Voice: [phone]

[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: Fri, 16 Dec 88  01:22:11 EST
From: "Roger Fajman" <[e-mail]>
Subject: Some Responses to V8 #11 and Kermit-370
Keywords: Kermit-370

> 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

It's also risky not to ignore bare CRs.  Some systems, such as IBM TSO/TCAM,
echo a CR/LF when they receive a CR.  If the Kermit on the other end insists
on treating that CR as the end of a packet, you'll never get a file transfer
going without changing the EOL character.  We experienced this exact problem
with older releases of C Kermit talking to NIH TSO Kermit.  It took quite a
while to figure out what was happenning.

------------------------------

Date: Mon, 14 Nov 1988  21:08 MST
From: Keith Petersen <[e-mail]>
Subject: Bug in Kermit-80 for Northstar Advantage
Keywords: Kermit-80, Northstar Advantage, CP/M-80 Kermit

Relayed from GEnie:

Item    1411308                 88/11/13        15:35
From:   J.LABUTE                        John P. Labute
To:     W8SDZ                           Keith Petersen, CP/M SysOp
Sub:    Kermit-80

There seems to be a bug in the version of Kermit-80 for the Northstar
Advantage (CP409ADV.COM).  This version echos back to the remote anything
that it receives, even with the local echo off (as I verified with my
laptop).  I have tried two versions for my APPLE II with success.  Can
you help me or put me in contact with somebody who can.  Thanks.

[Ed. - Anybody???]

------------------------------

End of Info-Kermit Digest
*************************

20-Jan-89 19:13:51-GMT,19540;000000000001
Received: by cunixc.cc.columbia.edu (5.54/5.10) id AA00105; Fri, 20 Jan 89 13:51:36 EST
Date: Fri, 20 Jan 1989 13:51:34 EST
From: Frank da Cruz <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V9 #2
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Fri, 20 Jan 1989        Volume 9 : Number 2

Departments:

  ANNOUNCEMENTS -
        New Release of C-Kermit Available for Testing (UNIX only)
        Announcing Apple II Kermit Version 3.85
        Announcing a New MS-DOS Kermit 2.32 for the GRiD Compass II
        Announcing Commodore 64/128 Kermit Version 2.2

  MS-DOS KERMIT -
        Printing MS-DOS Kermit EGA Graphics Screens
        Kermit Support of Novell Asynchronous Server Interface?
        MS-Kermit 2.32 Filesize Computation
        MS-Kermit Disk Space Calculation
        MS-Kermit 32MB File Transfer Limitation
        Problem with Kermit on a Packard Bell AT clone
        Nice New MS-Kermit 2.32 Features

Send digest submissions to [e-mail], requests for
addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or 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.  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: Mon, 16 Jan 1989 23:25:08 EST
From: Frank da Cruz <[e-mail]>
Subject: New Release of C-Kermit Available for Testing (UNIX only)
Keywords: C-Kermit, ATT7300, UNIX Kermit, UNIX PC
Keywords: SUNOS 4.x, Ultrix, VAX/Ultrix

This is to announce a test release of C-Kermit, 4E(071).  No major changes in
functionality, but some significant bug fixes and possibly performance
improvements.  A quick list:

 - Fix bug that sometimes caused files to be corrupted, or the file
   transfer to fail, when long packets were being used and the final packet
   was 93-95 characters long.

 - Fix bug in long packet negotiation.

 - Fix 8th-bit prefixing negotiation to prevent misunderstandings on second
   and subsequent SEND commands when parity is in use, which could sometimes
   result in corrupted files.

 - Recover from a subtle protocol deadlock that can occur when you GET a file
   over a noisy, long-distance connection.

 - Improve efficiency of CRC calculation.

 - In command parser, treat tab as completion character (ESC), rather than
   synonym for space (convenient for C-Shell, K-Shell, GNU EMACS users).

 - Reduce size of program somewhat by storing state transitions as shorts,
   rather than ints.

 - Add HANGUP command, and related improvements in CONNECT command to help
   recover from modem signal transitions, etc.

 - Let users "set speed 19200" (at their own risk).

 - Change ATT System III / V i/o parameters to improve efficiency.

 - Attempt to fix ATT7300 UNIX PC support.

 - Fix and/or add entries to the makefile for 2.10 BSD, Microport Sys V,
   SCO Xenix/86, /286, /386, SUNOS 4.x.  (By the way, you can actually compile
   and run C-Kermit in the System V environment under SUNOS 4.x -- just say
   "make sys5r3" and ignore the warnings.)

 - Other minor changes.

These changes are described in greater detail in the file ckuker.upd, which
also gives credit to many people for uncovering (and in many cases supplying
the fixes for) the bugs.

This release needs to be tested thoroughly on as many different kinds of UNIX
systems as possible -- pure Berkeley (2.9, 2.10, 4.1, 4.2, 4.3), AT&T (System
III, V, and VR3), hybrids (Ultrix, SUNOS, etc), Xenix (all varieties), etc
etc.  It has only been tested so far on VAXes with Ultrix, and SUN-4's with
SUNOS 4.0, with some preliminary testing (before all the changes were made)
on an ATT 7300 UNIX PC.

In particular, I have no way to test the 'dial' command with real modems.
Does it still work?  (Did it ever?)  Can it still be Ctrl-C'd out of?

For now, the new release is available only via ftp from
cunixc.cc.columbia.edu, in the directory kermit/test.  Please get the files
and try the new version out, and report any problems to me.  After the kinks
are worked out, it will replace the current standard release, and then we can
move on to bigger things, like attribute packets and maybe even sliding
windows.  And cleaning up the spaghetti of #ifdef's in the code...

Since C-Kermit also forms the basis for VMS, Macintosh and some other Kermits,
validation of this new release will clear up protocol-related glitches in
those programs too.

------------------------------

Date: Tue, 17 Jan 89 09:00:00 PDT
From: Christine M Gianone <[e-mail]>
Subject: Announcing Apple II Kermit Version 3.85
Keywords: Apple II Kermit 3.85, ProDOS

This is to announce Apple II Kermit Version 3.85 for Apple II DOS and ProDOS,
which replaces version 3.84 of August 1988, from Ted Medin,
[e-mail].  The major changes include:

 - Improved performance on Apple II's with interrupt-driven communications
   (most systems //e+ or later).
 - A new "set timing" command, to allow adjustment to internal clocks of
   different speeds.
 - A new "type" command for displaying local files without leaving Kermit.
 - The "help" command now displays an external help file that you can change
   without rebuilding the program itself.
 - An escaping mechanism for sending special characters to the modem.
 - A revised manual.

The new files are in app*.* in the various Kermit Distribution areas, and can
be ordered on Kermit Tape A.  Many thanks to Ted for his continued efforts in
developing and supporting this program.

------------------------------

Date: Sun, 8 Jan 89 12:45:14 EST
From: [e-mail] (John Nyenhuis)
Subject: Announcing a New MS-DOS Kermit 2.32 for the GRiD Compass II
Keywords: MS-DOS Kermit 2.32, Grid Compass II

I have developed an enhanced MS-DOS kermit 2.32 for the GRiD Compass II that
supports Tektronix emulation and also contains several other features not
present in the current msvgri.exe. I have tested this program extensively on
GRiD Compass II models 1129 and 1131. (The 1129 has a small screen and the
1131 has a large screen.) I am submitting this kermit 2.32 to the Kermit
Distribution. I welcome comments and questions from users of MS-DOS kermit
2.31B for the GRiD Compass II.

I thank Prof. Doupnik for his helpful suggestions and encouragement in this
endeavor.

Key new features of the new MS-DOS Kermit for the GRiD Compass II:

 1. Tektronix 4010 emulation is supported.
 2. Speed is about 80% faster in connect mode.
 3. The hangup and send break commands now work.
 4. Flow control now works.

The new files are msggri.asm, msvgri.boo, msugri.asm, msvgri.hlp, msvgri.lnk,
and msxgri.asm.  Except for msggri.asm, which is new, these files are updates
of current files in the Kermit distribution.  The file msvgri.hlp contains
documentation for the the latest Kermit for the Compass II.

Thank you.

John Nyenhuis   Purdue University  School of Electrical Engineering
West Lafayette IN 47907   [phone]     [e-mail]

[Ed. - Thank you!  These files have replaced the previous Grid files in
the Kermit Distribution, kermit/a, Tape A, etc.]

------------------------------

Date: Sun, 15 Jan 89 15:21:33 EST
From: [e-mail] (Ray Moody)
Subject: Announcing Commodore 64/128 Kermit Version 2.2
Keywords:  Commodore 64/128

Commodore Kermit version 2.2 is now available.  This new version has one major
new feature: reliable communication at 2400 bps is now possible (but only on a
C128 when using the built-in 80-column screen).  There are also some bug
fixes.

 - Obtaining Kermit on a Floppy Disk:

A copy of Commodore Kermit may be obtained by sending $5.00 postage and
handling to:
                 Dr. Evil Laboratories
                 P. O. Box 190
                 St. Paul, IN 47272

We stress that Commodore Kermit is absolutely free.  The $5.00 is used to
cover the cost of the disk, mailer, postage, and handling.  The disk will
contain Commodore Kermit version 2.2, extensive on-disk documentation broken
into seven files small enough to be viewed with a good word processor, and an
initialization file.  A boot file is included for the convenience of C64
users.  For the convenience of C128 users a boot sector is provided that can
load Kermit using the fast serial routines.

Dr. Evil Laboratories also provides a bound manual for Commodore Kermit
version 2.2.  This documentation is exactly like the on-disk manual
content-wise, but is typeset for greater readability.  This manual is
available for $5.00.

Dr. Evil Laboratories is a small software company which has the facilities to
distribute Kermit much more efficiently than I could personally.  Also, Dr.
Evil Labs has a permanent address, something that I, being in college, don't
have.

All orders to Dr. Evil Laboratories must be in U.S. funds.  Indiana residents
must add 5% sales tax.

 - Downloading Kermit from the Kermit Archives

Commodore Kermit may also be downloaded from the Kermit archives.  The Kermit
archives are available on BITNET, ARPANET, and USENET.  For complete
downloading instructions, see the file C64KER.HLP in one of these archives.

 - Short Cut

For a short time, Kermit binaries may be obtained via anonymous FTP from
maxwell.physics.purdue.edu.  These files are true binary files and must be
copied from this machine using image mode and then downloaded directly to a
Commodore with a binary file transfer protocol (such as Kermit 2.1).  Those
people who can take advantage of this service should find it to be simpler
than downloading and then converting the ASCII files in the Kermit archives.

Many thanks to Fred Bowen and Frank Prindle for making this version of Kermit
a reality.

[Ed. - And many thanks to Ray for sending it in to Kermit Distribution.]

------------------------------

Date: Tue, 17 Jan 89 13:30 EST
From: Christine M Gianone <[e-mail]>
Subject: Printing MS-DOS Kermit EGA Graphics Screens
Keywords: MS-DOS Kermit Tektronix Emulation
Keywords: Graphics, Epson Printer Graphics, MS-DOS Kermit Printer Support

As explained in the MS-DOS Kermit User Guide, MS-Kermit uses the services of
DOS to access the PC's printer.  Kermit simply outputs the requested material
to DOS, and it can be intercepted by any printer driver you happen to have
installed.  This can include an ordinary print spooler, a driver for a
particular printer, etc.

When Kermit is emulating a Tektronix graphics terminal, it does not handle
print-screen requests itself.  You may load a graphics printer driver
to do this.  IBM systems come with a utility GRAPHICS.COM, described in the
IBM DOS manual.  Unfortunately, this utility works only with CGA graphics
adapters, not EGA.

A short public-domain utility, EPSON.COM, written in assembler by Dr. R.
Brooks Van Horn, Jr., Herndon, VA, can be used for printing EGA graphics
screens on Epson FX-series printers.  This utility has been added to the
Kermit Distribution as msgeps.*.  Thanks to Dr. Van Horn for contributing it
to the public domain and to Joe Doupnik for sending it in.

------------------------------

Date:  Tue, 20 Dec 88 16:52 EST
From: [e-mail]
Subject:  Kermit Support of Novell Asynchronous Server Interface?
Keywords: MS-DOS Kermit Network Support, Novell, NASI

I am currently using a Novell Netware LAN with a PCOX modem server.  It uses
the Novell Asynchronous Server Interface (NASI) to interface to the modems.
Does anyone have any experience with this system?  Does Kermit support the
NASI interface (Does it have a NASI driver)?  I tried using the "SET PORT NET
<name>" but got an error message.  I'm using MS-Kermit 2.30.  Any suggestions?

Craig Forbes
Forbes @Dockmaster

[From jrd - Craig, try SET PORT BIOSn (n = 1 - 4) so Novell's NASI can
intercept the Bios call. The SET PORT NET command invokes NetBios, which is
not what is needed in this case.  Many other networks also intercept a normal
serial port Bios call and relay information across the link; that's the most
important use of the SET PORT BIOS command.]

------------------------------

Date: Thu, 29 Dec 88 23:55:08 LCL
From: David Boeshaar <[e-mail]>
Subject: MS-Kermit 2.32 Filesize Computation
Keywords: MS-DOS Kermit Network Support, MS-DOS Kermit File Size Limitation
Keywords: Novell

I am running Kermit 2.32 on a PS/2 model 25 attached to a Novell Netware 2.0a
network, Running DOS 3.2.  Whenever I download a file, I get the A: disk lite
come on, KERMIT then reports no room on the disk, but then completes the
download correctly. DRAT! Even the ANN and UPD files said this was corrected.
BOO HOO!

Oh well, other than that, KERMIT is still a GREAT communications program that
is GREATLY apprectiated here at Syracuse University.  Thanx for all the great
work!

[From jrd - I'll bet that COMMAND.COM is left assigned to drive A: and DOS is
checking the boot drive for something.  Check your Environment (DOS SET
command) and Novell's MAP command to see if A: is in the search path.  I've
not noted the effect here under NetWare 2.0a, 2.10, and now 2.12, but then
locally COMMAND.COM is on a non-floppy drive.]

------------------------------

Date: Wed, 16 Nov 88 07:34:07 EST
From: Dave Tetreault <[e-mail]>
Subject: MS-Kermit Disk Space Calculation
Keywords: MS-DOS Kermit Network Support, Novell
Keywords: MS-DOS Kermit File Size Limitation

I am having problems using the beta version of MS-Kermit to transfer files to
network disks on a Novell network.  It works as long as I use a local disk but
using a network disk Kermit oftens aborts file transfer to the PC with
complaints about not enough disk space.  I have been using 3.21 July for
months with no problems.  I went back and tested the later 2.31/A beta version
and it also has the same problem with checking disk space.

  David E. Tetreault
  Manager of Technical Support
  Academic Computer Center
  University of Rhode Island

[From jrd - you might try MS Kermit version 2.32, which cures certain disk
space problems. Otherwise MS Kermit is compatible with Novell NetWare. It
is possible to arrive at amazingly convoluted disk letter assignments, yet
MS Kermit attempts to query the underlying real disk (via legal DOS calls).
My Novell system runs with straight forward assignments. SET ATTRIBUTES OFF
will also bypass the disk space check.]

------------------------------

Date: Tue, 20 Dec 88 13:45 EST
From: "Michael W. Sabato" <[e-mail]>
Subject: MS-Kermit 32MB File Transfer Limitation
Keywords: MS-DOS Kermit File Size Limitation

We have DOS 4.0 installed on a PS/2 Model 80 with 112 megabyte disk split into
a 72 megs and 40 megs logical disks.  When downloading a database file greater
than 32 megs from an IBM mainframe to a PC, Kermit quits when 32 megabytes
have been transmitted.  Are there any plans to support DOS files larger than
32MB?

The current version 2.31 is great to work with and I am sure we have not used
all of its capabilities.  The long packet support by both Kermit-370 and
MS-Kermit make our downloads do-able in a reasonable time.  Thanks!

[From jrd - I enlarged some of the numerology in MS Kermit for version 2.32 to
accomodate larger disk partitions.  However, parts of the file size message on
the screen will roll over at about 16 MB due to trying to rapidly get through
double precision integer arithmetic quickly for nearly every packet
(percentage done is the messy item: d.p. division).  When I did that part
originally several years ago no one dreamed of 32MB+ files.  I must commend you
on such faith in Kermit to transfer files of that size and trust that you said
SET INCOMPLETE-FILE KEEP.]

---------------------------------

Date: 7 Dec 88 00:07:27 GMT
From: Mike Iglesias <[e-mail]>
Subject: Problem with Kermit on a Packard Bell AT clone
Keywords: MS-DOS Kermit VT102 Emulation, Packard-Bell AT Clone

I'm having a problem with Kermit 2.30 and 2.31 on Packard Bell AT clone (10mhz
286, Phoenix BIOS v3.07, EGA).  Kermit works fine in terminal emulation mode
(VT100, H19) until it has to scroll the screen up one line, and then it beeps
when the next line comes in from the system I've dialed up to (at 2400 baud).
>From looking at the source, it looks like Kermit is getting an overrun on the
serial port and substituting a bell for the character it didn't get (it
usually drops the first character on a line).  I've tried switching the serial
card with another to see if the problem goes away, but it didn't.

Mike Iglesias
University of California, Irvine

P.S.  If it helps, Procomm does almost the same thing - it doesn't beep when a
character gets lost, though.  And the EGA card is made by STB Systems, if that
makes any difference.

[From jrd - Mike, the Control-G is from me, as my way of warning the user that
the beep replaces one or more overrun characters. The loss is due to something
in the Bios which is taking forever to scroll the screen and is doing so with
interrupts off. I'd try another EGA board or call STB for hints. My Video 7
boards (Vega and VGA) are not the world's fastest, but they don't yield
overruns either.]

[From Mike - Replacing the EGA card solved the problem.  It looks like it was
taking too long to scroll the screen (probably with interrupts disabled) so
the serial port lost a character.  We've got a lot of AT&T 6300s around (with
the Phoenix rom bios) and they don't have any problems running kermit.  Keep
up the good work!]

------------------------------

Date: Thu, 5 Jan 89 20:22:23 EST
From: elsie![e-mail] (Arthur David Olson)
Subject: Nice New MS-Kermit 2.32 Features

Many thanks for the usual fine job.  Port 3 on our IBM PS/2's now works right
out of the box.  And both \Kterminals and \Kterminalr are greatly appreciated;
our users can now go from being connected back to DOS with a single keystroke,
and our VAX can coerce the PC's into doing things that used to require human
intervention.  Now if only we had \Kterminalt and \Kterminalu and. . .

    Arthur David Olson    [e-mail]    ADO is a trademark of Ampex.

[From jrd - Whew! (com3) And "give'm an inch ..."  A little devious thinking
reveals that inside of TERMINALR/S one may do absolutely anything, including
defining/clearing other macro or variable names to act as one-bit flags, doing
a script INPUT command to obtain another character or string, and so forth.
One can build up a Kermit command list from successive invokations of these
macros plus the definition abilities.  The rest I leave to clever users.]

------------------------------

End of Info-Kermit Digest
*************************

25-Jan-89  2:44:00-GMT,14575;000000000001
Received: by cunixc.cc.columbia.edu (5.54/5.10) id AA22170; Tue, 24 Jan 89 21:30:30 EST
Date: Tue, 24 Jan 1989 21:30:29 EST
From: Frank da Cruz <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V9 #3
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Tue, 24 Jan 1989        Volume 9 : Number 3

Today's Topics:

           Announcing MS-DOS Kermit 2.32/A
          MS-Kermit 2.32 Binary Transfer Bug
    Announcing IBM Mainframe VM/CMS Kermit-370 Version 4.1
       Announcing IBM Mainframe MVS/TSO Kermit-370 Version 4.1
               C-Kermit Update


Send digest submissions to [e-mail], requests for
addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or 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.
Login as user anonymous (note, lower case), 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 kermit/a/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, 23 Jan 89 19:56 MDT
From: Joe Doupnik <[e-mail]>
To: [e-mail], Info-Kermit
Subject: Announcing MS-DOS Kermit 2.32/A

To correct a somewhat serious bug in MS-Kermit 2.32 (see next message), a
maintenance release of MS-Kermit -- 2.32/A -- is now available.  The
opportunity was also used to fix a few minor problems.  The changes from MS
Kermit 2.32 to 2.32/A 21 Jan 1989 are listed below.

Items common to all machines supported by MS Kermit -

1. Correct a problem negotiating 8-bit prefixing when MS Kermit is operating
   with parity of NONE yet the other side requests that such quoting be done.
   Version 2.32 had a problem and would receive the 8-bit quoting character
   "&" as ordinary text and hence produce a corrupted file. Setting parity
   to SPACE on the PC with version 2.32 might be a suitable workaround.

2. Correct ENABLE/DISABLE MESSAGE commands to work properly. Previously the
   sense was inverted and the command applied to SEND rather than MESSAGE.

3. Formally decode messages in ACKs to data or filename packets before
   displaying them.

4. Add analysis of prompt text in the ASK command so that \number forms are
   converted to binary before displaying the prompt. This makes the prompt
   field behave the same as in the ordinary SET PROMPT command. A dollar sign
   will terminate the text string for either command.
   Example:     ASK \%1 \27[31mEnter password\27[37m

5. Correct small textual errors in the SET command main help screen.

6. Allow command REMOTE MESSAGE to use three character text messages.

Items specific to the IBM-PC version of MS Kermit -

7. Delay accessing a communications port until the port is actually needed.
   This prevents the automatic probing of COM1 at Kermit startup, even before
   file mskermit.ini or equivalent is read. COM1 remains the default port
   unless another is selected by a SET PORT command. The effect of this change
   is transparent except where Kermit has been operated under a multi-tasking
   Environment such as Concurrent-DOS, Desqview, DoubleDos, or MS Windows.
   These situations have experienced difficulty when a second copy of Kermit
   is started while the first copy is actively using COM1; the disturbance
   is created when COM1 is prepared for use as part of the Kermit startup
   process. The present change prevents this disturbance by selecting but not
   touching a port until a Kermit command requires it. Note that STATUS, SHOW
   COMMUNICATIONS, SHOW MODEM, SET BAUD, SET SPEED, and SET PORT commands
   do access the selected port for information; to avoid possible interference
   between users of COM1 perform the desired SET PORT command to select and
   initialize another port before using these latter commands.

8. Add several small improvements to video screen support for the VT102
   terminal emulator when Video 7 boards are used. Preserve 43 line mode
   whenever possible. Defeat 132 column mode for Video 7 VGA boards used with
   fixed frequency analogue displays (31.5KHz), such as the IBM 85xx series.
   Prevent using wrong display buffer address when an unknown proprietary
   video mode is encountered from many EGA and VGA style boards.

9. Put the VT102 screen into the rollback buffer when clearing the entire
   screen with any escape sequence combination. Partial screen erasures
   do not cause preservation in the rollback buffer.

10. Support character 9Bh, ANSI "CSI", as equivalent to reception of "ESC ["
    in the VT102 emulator.

11. Preserve character set pointers and related items in the VT102 emulator
    when the screen width is changed.

12. Avoid unnecessary flow control commands when Control-Print Screen is
    active.

The files which have been changed since version 2.32 are:

    new release ident and date:
      MSSDEF.H

    new system independet files:
      MSSKER.ASM, MSSSEN.ASM, MSSSER.ASM, MSSSET.ASM, MSSTER.ASM

    and for IBM-PC's:
      MSXIBM.ASM, MSYIBM.ASM, MSZIBM.ASM
                                                        Joe Doupnik
                                                        22 Jan 1989

[Ed. - Many thanks once again, Joe.  The new files have been put in Kermit
distribution, and MSKERM.BWR has been updated accordingly.]

------------------------------

Date: Thu, 19 Jan 1989 18:42:32 CET
From: Helmut Waelder <[e-mail]>
Subject: MS-Kermit 2.32 Binary Transfer Bug

I have transferred a binary file from IBM/370 Kermit 4.0 in server modus
to MS-Kermit 2.31 and a second time to MS-Kermit 2.32 with LOG PACKETS.
The result is as following (all data packets are the same for V2.31 and
V2.32):

    ------ MS-Kermit 2.31 ( works ok) ----------
    Spack: ^A0 I~- @-#Y1~*  ~G^M
    Rpack: ^A- Y~% @-#&1~(Y^M
    Spack: ^A/ Rdos33pat.arcY^M
    Rpack: ^A- S~% @-#&1~(S^M
    Spack: ^A0 Y~- @-#&1~*  ~$^M       <---- this packet differs in V2.32
    Rpack: ^A/!FDOS33PAT.ARC.^M
    -------- MS-Kermit 2.32 ( in error ) --------
    Spack: ^A0 I~- @-#Y1~*  ~G^M
    Rpack: ^A- Y~% @-#&1~(Y^M
    Spack: ^A/ Rdos33pat.arcY^M
    Rpack: ^A- S~% @-#&1~(S^M
    Spack: ^A0 Y~- @-#Y1~*  ~W^M       <----- different
    Rpack: ^A/!FDOS33PAT.ARC.^M

Over the line comes the same data, but it seems to me that MS-Kermit does not
correctly interpret the 8th bit prefixing.  There is no byte with 8th bit on
in the received file (v2.32) and the file is about 30% bigger in size.
/Helmut

[Ed. - This is a serious bug, and it is the main reason for releasing 2.32/A
at this time.  If Kermit should be able to do anything right, it's file
transfer!]

------------------------------

Date: Tue 24 Jan 89 18:00:00 EST
From: John Chandler <[e-mail]>
Subject: Announcing IBM Mainframe VM/CMS Kermit-370 Version 4.1
Keywords: IBM 370 Kermit, VM/CMS Kermit
Xref: CMS Kermit, also see VM/CMS Kermit

This is to announce CMS Kermit Release 4.1.  The sources have not been
completely rewritten, nor have they been resequenced, but numerous
fixes, extensions, and improvements have been inserted.  The changes
applied include all updates formerly available in IKCKER.UPD plus a
number of new ones.  As with Release 4.0, all CMS-specific files begin
with IKC, and generic Kermit-370 files begin with IK0 (I K Zero).  The
separate pieces are to be recombined into a single composite source (or
made into a macro library) for installation.  See the file IKCKER.INS
for instructions.  Release 4.1 is also being issued in the companion TSO
and MUSIC versions (see the separate announcements for details).  Anyone
interested in helping to port Kermit-370 to still other operating
systems should contact John Chandler <[e-mail]> or
<[e-mail]>.

Below is a list of the more important additions in Version 4.1:

    --- generic features ---

 1. Trimming of trailing blanks from commands read from TAKE files.

 2. New SET BAUD for improved calculation of optimum packet size.

 3. Optional suppression of Attribute packets.

 4. A new option to specify treatment of received records too long for
    the open file.

 5. File header packet acknowledgments containing the name actually used
    for the received file.

 6. Separate specification of SEND and RECEIVE parity.

 7. Option for "permanent", user-inaccessible ATOE and ETOA translation
    tables for TTY controllers and for site-specific default controller
    type.

 8. Automatic detection of controller type distinguishing SERIES1 from
    GRAPHICS.

 9. Both SEND and GET prompt the user for native and foreign filespecs
    if no arguments are entered.

10. New SEND syntax allowing multiple files, independent of wildcard
    notation.

11. Expanded transaction log, now including file sizes and error
    messages.  In addition, the log is kept for both SEND and RECEIVE
    operations.

12. Easy escape from Kermit protocol mode via STOP.

13. NAK(n+1) treated as ACK(n).

14. Attribute packets no longer destroyed via SET ETOA.

15. Long replies from other Kermit (in server mode) accepted without
    S-packets.

16. SHOW ALL restored.  SET ? without mention of ALL.

    --- CMS-only features ---

17. File creation times are included along with dates in A-packets.

18. An extensive new DEBUG option has been added for SERIES1 I/O.

19. Kermit-CMS now accepts a file header packet specifying the filemode
    for the new file.

20. The CMSTYPE and EMSG settings are now honored by Kermit in the
    process of intercepting typeout while in server mode.  for protocol
    mode on TTY lines.

21. The HELP subcommand now always uses the name under which Kermit was
    invoked.

[Ed. - Many thanks, John!  The files have been installed in Kermit
Distribution.  The MVS/TSO release is announced in the next message.  The
MUSIC version will probably be announced in the next digest.]

------------------------------

Date: Tue 24 Jan 89 18:00:00 EST
From: John Chandler <[e-mail]>
Subject: Announcing IBM Mainframe MVS/TSO Kermit-370 Version 4.1
Keywords: IBM 370 Kermit, MVS/TSO Kermit
Xref: TSO Kermit, see MVS/TSO Kermit

This is to announce Release 4.1 of Kermit-370 for TSO.  The sources have not
been completely rewritten, nor have they been resequenced, but numerous
fixes, extensions, and improvements have been inserted.  The changes applied
include all updates formerly available in IKTKER.UPD plus a number of new
ones.  While Release 4.0 was a test release, 4.1 may be considered a
production version.  As with Release 4.0, all TSO-specific files begin with
IKT, and generic Kermit-370 files begin with IK0 (I K Zero).  The separate
pieces are to be recombined into a single composite source (or made into a
macro library) for installation.  See the file IKTKER.INS for instructions.
Release 4.1 is also being issued in the companion CMS and MUSIC versions
(the CMS version is announced in the previous message, the MUSIC version
will come soon).  Anyone interested in helping to port Kermit-370 to still
other operating systems should contact John Chandler <[e-mail]>
or <[e-mail]>.

Below is a list of the more important additions in Version 4.1:

    --- generic features ---

(same as listed above for CMS Kermit)

    --- TSO-specific features ---

17. SET DELIM subcommand.

18. END subcommand.

19. Revised generic file update program GUPI (for applying updates to
    Kermit-370) and an all-new, one-step installation procedure (see the
    installation guide).

20. More general wildcard file name matching.

21. The file header for a downloaded PDS member includes the last
    qualifier of the PDS name appended to the member name.

22. The LRECL used by Kermit-TSO now conforms to MVS/TSO standards,
    rather than being TSO LRECL - 4 for RECFM=V.

23. Numerous bug fixes.  The TSO Kermit-370 may now be considered a
    production program, rather than a test release.

24. Kermit-TSO supports downloading of uncataloged and
    password-protected data sets.

------------------------------

Date: Tue 24 Jan 89 20:00:00 EST
From: Frank da Cruz <[e-mail]>
Subject: C-Kermit Update
Keywords: C-Kermit, UNIX Kermit

So far the only problems that have been reported with C-Kermit 4E(071),
announced in the previous digest, have had to do with compilation under
Xenix.  Some minor typos were fixed in ckufio.c, and some hints were added
to the makefile.  Also, "cd" was added as a legal (but invisible) synonym
for "cwd".  The result is 4E(072), available via ftp only from kermit/test
on cunixc.  The files that changed since last time are ckuusr.c, ckuus3.c,
ckufio.c, ckcmai.c, and ckuker.mak.

Has anyone checked out local mode operation at all?  You know, "set line
/dev/ttyxx, set speed yyyy, connect"?  On direct connections?  Dialed
connections with modem control?  On AT&T based systems?  On BSD-based
systems?  Under Ultrix?  SUNOS?  Xenix?  This is the wierdest the part of
the program, in which Kermit must go through a byzantine series of
incomprehensible system calls, different for each and every system, turning
modems on and off, closing and reopening file descriptors, changing file
modes, etc etc.

Many users have reported problems in this area in the past -- Kermit getting
hung in a read() or write() call, Kermit giving up on the connection because
of "I/O errors", etc.  The new release tries to get around some of these
problems by putting timers around blocking operations that might get stuck,
and closing/reopening the connection when the system reports i/o errors.
(These kinds of things seem to happen a lot in Ultrix 2.2.)

------------------------------

End of Info-Kermit Digest
*************************

 9-Feb-89  5:44:00-GMT,22025;000000000001
Received: by cunixc.cc.columbia.edu (5.54/5.10) id AA14046; Wed, 8 Feb 89 23:51:13 EST
Date: Wed, 8 Feb 1989 23:51:12 EST
From: Frank da Cruz <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V9 #4
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Wed, 8 Feb 1989        Volume 9 : Number 4

Today's Topics:

          Announcing IBM Mainframe MUSIC Kermit Version 4.1
                      NOTICE to TSO Kermit Users
                     C-Kermit 4E(072) Is Released
                    Announcing UniFLEX 6809 Kermit
       MS Kermit 2.32 for GRiD Compass, Source Code Corrections
               Announcing Another New MS-Windows Kermit
          MS-Windows Kermit Heath-19 Emulation (2 messages)
                      Announcing SCANCHEK.C 4.1
                   Kermit Disks for TRS-80 Model 4
                    C-Kermit on Apollo under SR10?
                 VMS & C-Kermit Problem with Localnet?

Send digest submissions to [e-mail], requests for
addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or 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.
Login as user anonymous (note, lower case), 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 kermit/a/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, 03 Feb 89 12:00:00 EST
From: Pierre Goyette <[e-mail]>
Subject: Announcing IBM Mainframe MUSIC Kermit Version 4.1
Keywords: IBM 370 Kermit, MUSIC Kermit

This is to announce MUSIC Kermit Release 4.1.  This program is now a member
of the generic family Kermit-370 and appears in the Kermit distribution
under a new prefix: all MUSIC-specific files begin with IKM, while generic
Kermit-370 files begin with IK0 (I K Zero).  Kermit-MUSIC no longer consists
of just two source files.  Instead, the source is split into sub-files, some
generic and some MUSIC-specific.  The separate pieces are to be recombined
into a single composite source for installation.  See the file IKMKER.INS
for instructions.  Generally, the files formerly known as IMU*.* will be
replaced by the new IKM*.* files.  This MUSIC Kermit is still in the testing
stage, but most of the features described in the documentation have already
been verified.  Any bug reports should be sent to Pierre Goyette
<[e-mail]>.  Anyone interested in helping to port Kermit-370 to
still other operating systems should contact John Chandler
<[e-mail]>.

Below is a list of the more important additions in Version 4.1 of MUSIC
Kermit (including many already announced for CMS Kermit):

 . Advanced server functions, including REMOTE KERMIT.
 . Long packet protocol (type 0 extended headers).
 . TYPE, ECHO, XTYPE, and XECHO subcommands (the last two being
   Series/1 analogs of the first two.)
 . TEST mode for debugging.
 . Multi-column, two-level, selective SHOW display.
 . Optionally append to, rather than replace, old data sets with
   duplicate names.
 . New GIVE command for saving a modified translation table.
 . A new, RAW debug mode for recording the packet traffic as actually
   sent and received on "GRAPHICS" and "SERIES1" devices.  Also, an
   I/O mode for recording supplemental transfer information.
 . Preservation of the case of commands as typed, with uppercase
   conversion of only those words that must be uppercase.
 . New SET MARGIN command for limiting the width of a file to be sent.
 . Settable tab stops for Kermit's conversion of tabs to spaces
   (alternative to the default 1, 9, 17, etc.).
 . Support for multiple terminal controller types.  Automatic detection
   of terminal controller type (TTY or SERIES1).
 . Limited emulation of MUSIC commands within Kermit.
 . Automatically tune packet length when sending long packets according
   to heuristic optimum based on sparse Poisson statistics, provided
   that transmission errors do occur.
 . Expand STATUS report to include the number of files in the last
   transfer, throughput statistics, heuristic optimum packet length
   (when long packets are enabled), and the reason for any file
   rejection based on A-packets.
 . New command TDUMP NAMES to display the transaction log, which
   includes names, file sizes and error messages.
 . Send and process Attribute packets (optionally may be suppressed).
 . Basic and advanced server commands to a server at the other end.
 . New types V-BINARY and D-BINARY for binary files with undelimited
   variable-length records.
 . SET 8-BIT-QUOTE.  Allow 8-bit data where possible via SET SEND (or
   RECEIVE) PARITY.
 . SET PROMPT subcommand.
 . Keep track of truncated records during a RECEIVE operation and
   report the count in STATUS; also, call truncation an error after
   everything is received.
 . A subcommand SET LONGLINE, to select the desired processing
   of lines received by MUSIC that exceed the LRECL -- the options
   are to fold, truncate or simply halt.
 . SET HANDSHAKE subcommand to alter or suppress handshake character
   Kermit-370 sends out after each packet (not available for 3705's).
 . Trimming of trailing blanks from commands read from TAKE files.
 . File header packet acknowledgments containing the name actually used
   for the received file.
 . Both SEND and GET prompt the user for native and foreign filespecs
   if no arguments are entered.
 . New SEND syntax allowing multiple files, independent of wildcard
   notation.
 . Easy escape from Kermit protocol mode via STOP.
 . File allocation error messages are now saved in Kermit and
   reported as part of the STATUS text.

- Pierre Goyette, McGill University <[e-mail]>

[Ed. - Pierre, merci beaucoup!  This is the third IBM mainframe operating
system to be covered under the umbrella of Portable Kermit-370, and a
testimony to the modular design of this program.  The new MUSIC support files
have been added to the other Kermit-370 files as IKM*.* in the "B" area.  The
earlier MUSIC Kermit program (IMUSIC.ASM) remains available for now Kermit
Distribution area "D" for now.  Users of other IBM mainframe operating
systems, particularly those for which no Kermit is available at all -- notably
DOS/VSE -- are encouraged to do as Pierre has done, and fill in the
system-dependent portions of Kermit-370 for those environments.  Instructions
for doing this can be found in the file IK0POR.HLP.]

------------------------------

Date: Fri, 1989 Jan 27   22:48:14 EST
From: (John F. Chandler)   [e-mail]
Subject: NOTICE to TSO Kermit Users
Keywords:  IBM 370 Kermit, MVS/TSO Kermit
Xref: TSO, See MVS/TSO

The source module IK0MAI.ASM that appeared as part of release 4.1 of
Kermit-370 on January 24 contained a line that produced an assembly error
under TSO (but no other operating systems).  That module (112 lines in all)
now been replaced.  Sorry for any inconvenience.

------------------------------

Date: Thu, 2 Feb 1989 15:31:12 EST
From: Frank da Cruz <[e-mail]>
Subject: C-Kermit 4E(072) Is Released

Since there have been no further reports of bugs in the test version of
C-Kermit announced in Info-Kermit V9 #2 and #3, this version has been moved
to the regular Kermit Distribution, where it can now be picked up by normal
means (anonymous FTP to CUNIXC.CC.COLUMBIA.EDU, KERMSRV at CUVMA, mail order,
etc).  But it's not too late to report bugs, so please, everyone (especially
those who didn't have the opportunity to do it before) grab the new version
and report success or failure for particular machine/operating system/version
combinations.  To build the program for your system, rename the file
ckuker.mak to makefile, and then type "make xxx", where xxx is the appropriate
makefile option (read the makefile to see what the options are).

The new files are ckc*.*, cku*.*, and ckw*.*, in the "b" area.  This list
actually includes a few files unmodified since the previous release, but it
guarantees you an up-to-date set of files for Unix and its variants.  Don't
ask for ck*.*, or else you will get tons of files for Macintosh, Data General,
VAX/VMS, Commodore Amiga, OS9, etc. (see ckaaaa.hlp for naming conventions).
Programmers who use any of the non-Unix systems just mentioned are encouraged
to build new versions of C-Kermit for these systems, based on the new
system-independent or Unix-based modules.

------------------------------

Date: 31-JAN-1989 18:30:02.32
From: Jur van der Burg <[e-mail]>
Subject: Announcing UniFLEX 6809 Kermit
Keywords: UniFLEX, 6809

Author:      Jur van der Burg
             Nettelhorst 56
             2402 LS  Alphen aan den Rijn
             The Netherlands
Easynet:     UTRTSC::VDBURG
Language:    C (Compiled with McCosh compiler Version 27.0:2)
Version:     1.4
Date:        Januari 11, 1989

KERMIT for UniFLEX 6809 has its roots in the UNIX version. It is enhanced in
several ways, such as data logging, server mode etc.

UniFLEX KERMIT has most of the features specified in the KERMIT Protocol
Manual.  Installation notes can be found in the file 'UFREAD.ME'.

[Ed. - Many thanks, Jur!  And thanks to Bernie Eiben for relaying this
program to us.  It can be found in the "c" area of Kermit Distribution as
uf*.*.]

------------------------------

Date: Sat, 28 Jan 89 15:41:49 EST
From: [e-mail] (John Nyenhuis)
Subject: MS Kermit 2.32 for GRiD Compass, Source Code Corrections
Keywords: MS-DOS Kermit 2.32, Grid Compass II

Thanks for placing my MS Kermit 2.32 for the GRiD Compass in the kermit
distribution. Looking at the source files at Columbia, I see that a few
corrections are in order:

 (1) msugri.asm contains the code for msxgri.asm.
 (2) msxgri.asm is not the most recent version.

To fix these problems:

 (1) Delete msxgri.asm.
 (2) Rename msugri.asm to msxgri.asm. (i.e. "mv msugri.asm msxgri.asm")
 (3) Use the correct msugri.asm that is below.

File sizes are:
  msugri.asm  72694
  msxgri.asm  65704

This situation is likely related to my sending you a revised msxgri.asm only
a few days after sending the first one.  The revised msxgri.asm has ended up
as msugri.asm.  The files msggri.asm and msvgri.boo are correct.

On another note, I recently tested this kermit on a GRiD Compass 1101 and it
worked fine. Thus, it is probable that this Kermit will work on the entire
GRiD Compass family.  I welcome comments from users of Kermit 2.32 for the
GRiD Compass and I will endeavor to fix any bugs that surface.

Thanks again.

   John N.

John Nyenhuis   Purdue University  School of Electrical Engineering
West Lafayette IN 47907   [phone]     [e-mail]

[Ed. - John, thanks very much for noticing msxgri.asm's attempt to
masquerade as msugri.asm.  The corrections have been made as you suggested,
including installation of the new msxgri.asm file.]

------------------------------

Date: Thu, 19 Jan 89 13:21:40 PST
From: [e-mail] (William Hall)
Subject: Announcing Another New MS-Windows Kermit
Keywords: MS-Windows Kermit, Heath-19 Emulation
Xref: Windows, see MS-Windows

Christine,

I have an update to the Windows version of Kermit.  I fixed some problems in
handling screen colors when the user has non-standard colors.  It's on the
way on diskette.

--Bill Hall

[Ed. - Thanks, Bill.  Your new version, 1.03, arrived OK, and has replaced
the 1.0 version of December 9, 1988, in the Kermit "A" area.]

------------------------------

Date: Fri, 27 Jan 89 04:53:27 EST
From: Erez Zadok <[e-mail]>
Subject: MS-Windows Kermit Heath-19 Emulation
Keywords: MS-Windows, Windows, WKERM, Heath-19 Emulation, MSBPCT

I'm writing this using wkerm.exe that I downloaded yesterday, unjured using a
C program provided with winkrm.jar, unbooed with another C program that's
provided that I had to compile on my PC, and installed it into Windows.

Well this version is very simple. It provides an emulation for H-19, and
worked fine with curses based programs as far as generating the correct escape
sequences. However, programs that use full-screen emulation, like emacs,
display only 21 lines and jumps if you're scrolling the full-screen in it's
window. Sysline workes fine, but it just helps to the "jumping" in emacs etc.
I would prefer to see a real 80X25 screen...

I tried to transfer a simple file and only got part of it. I did read the
document/bwr files provided and seems to me I was doing the right thing but
something didn't work well. I'll dwell on that later.

This version of kermit works fine with windows as far as multiple windows
running "at the same time" or even when the window is minimized. I especially
liked the fact that I could run file transfer and do other things while Kermit
crunches 'em packets ... but it didn't complete the file transfer as noted.

Another note, about msbpct.c which is the C program to unboo/unpack *.boo
files.  The program contains the following two lines:

                #define MSDOS
                #define CI86

My environment and/or the C compiler has MSDOS already defined and so the
compiler refused to compile the program, saying that MSDOS is being
redefined... Also, nowhere in the comments above it did it say to comment out
one or more of the above #define lines. I wound up commenting out both lines
to have the program compile successfully and unpack the *.boo files.

Any comments?

FYI,
Erez.

[Ed. - See Bill's answer below.  And thanks for pointing out the problem
with MSBPCT.C.  It has been fixed.  The new copy is in the Kermit
Distribution "A" area.]

------------------------------

Date: Fri, 27 Jan 89 16:50:01 PST
From: ames!olivej.ATC.Olivetti.Com![e-mail] (William Hall)
Subject: MS-Windows Kermit Heath-19 Emulation

The answer to the user's problem about apparently only having 21 lines on
the screen is really complicated.  First, it may help to know that the
terminal window is a child of the main window and is always 80 columns by 24
lines (if no change has been made via win.ini).  But, the main window may be
too small to show all 24 lines.  At the same time, it is necessary to ALWAYS
have the insert point visible on the screen.  Hence, if running EMACS and
there is a write to the status line, the child is moved up to the
appropriate position to show the insert point.  Then, if the insert point is
then repositioned back to the top of the file, the child window is rolled
down so that the cursor is stil visible.

(it amused me to see the remark 'the program is simple enough' in the
message.  Just getting this positioning I just described took quite a bit of
effort!)

Anyway, the user can get out of this problem by increasing the height of the
main window so that the screen does not have to roll up and down to keep the
insert point visible.  Of course, whether this is possible depends on the
font being used and the display.  If a CGA is the display, then there is no
help unless I make it possible to use a font smaller than the OEM font,
which is the default and which is 8 scans high.  Using the Heath19 font
makes it worse since it is 10 scans high.  However, the user should have no
problem on the EGA or VGA with either the OEM default font or the Heath
font.

I don't know why there was a file transfer problem.  I never had problems
with it just stopping in the middle of the transfer.  Of course, my only
target machines are a VAX running Berkeley UNIX and an IBM PC with MSDOS
Kermit.  So, it might depend on the host's implementation and my failure to
account for something which I have not seen to date.

At any rate, I would be happy to talk to the individual concerned.  He can
contact me directly at oliveb!whall or by phone.  [phone] or
408-241-6983.  I tried to figure out his address in the noise which passes
for a header and I am not sure if I can figure it out.  So, if you will
forward this along I would be grateful.

I just send Christine Gianone a new version which makes some cosmetic
changes to the way screen colors are handled.  I got some mail from a
gentleman at Columbia saying that the current version did not handle unusual
choices of screen colors and he was right.  The one in the mail should take
care of this.

--Bill

[Ed. - Thanks again, Bill.  We've tried WKERM out with Windows on our
machines, and it seems to transfer files just fine.]

------------------------------

Date: Tue, 31 Jan 1989 10:40 MET
From: [e-mail]
Subject: Announcing SCANCHEK.C 4.1
Keywords: MS-DOS Kermit Key Definitions, SCANCHEK

I've found a minor error in Scanchek 4.0: The program doesn't match exactly
Kermit's SHOW KEY function.  On the numeric keypad (white keys only) NumLock
offsets the shift keys and vice versa (as indicated in MSUIBM.ASM).  In
MS-Kermit 2.32 the separation of the comma on German keyboard keypads from
the regular comma was added.

I updated Scanchek.c to match Kermit 2.32. The new version, 4.1, is enclosed.

Regards
Matthias Reichling

[Ed. - Many thanks, Matthias.  For those who don't know, scanchek is a
program, originally written by Phil Benchoff, that lets you conveniently
type keys on an IBM PC family (or compatible) keyboard, and reports their
scan codes, as used by the MS-Kermit SET KEY command.   This new version of
scanchek has replaced 4.0 in the Kermit Distribution as MSUCHK.*.]

------------------------------

Date: Mon, 30 Jan 89 09:12:16 +0100
From: mcvax!prismaa.prl.philips.nl![e-mail]
Subject: Kermit Disks for TRS-80 Model 4
Keywords: TRS-80 Model 4

It took some time, but I managed to collect:

        TRS-80 Kermit for the Model 4, Sources & executables

I'm willing to make disks for these. You seem to have no diskette volunteers
for this version, so here's your first!

The sources come to some 240Kb, which is more than will fit on 1 standard
TRSDOS 6 disk (40Tks, SSDD --> 180Kb), but I can handle any other format if
requested, as long as it is TRSDOS 6 compatible (i.e. 40/80Tks SS/DS SD/DD).

The following seems doable:

 - Executables & docs : US$10 to AnywhereVille, AnyLand (1 disk)
                        US$5  if you send me the disk+envelope
 - Executables & sources & docs
                      : US$15 to AnywhereVille, Anyland (3 disks)
                        US$7.50 if you send me the disks+envelope

Specify disk format if you want it other than 40Tks, SSDD. 80Tks ONLY IF YOU
SEND THE DISK(S), as 96Tpi disks are rare in The Netherlands (and therefore
unacceptably expensive)

My postal address is:

        Bert Laverman
        P.a. Dilgtweg 14
        9751 NG  Haren
        The Netherlands

I'm afraid that current developments force me to restrict the offer to
September 1989.

BTW I posted an announcement on `comp.sys.tandy', but although there are
TRS-80 users on the net, I had no replies yet. I will pass the program on to
the User's group gere in the Netherlands anyway.

Greetings, Bert Laverman ([e-mail])

------------------------------

Date: Wed, 25 Jan 89 09:45:33 NOR
From: hanche%imf.unit.no@norunix
Subject: C-Kermit on Apollo under SR10?
Keywords: Apollo, C-Kermit on Apollo

Has anybody managed to make C-Kermit work under SR10 on an Apollo?
Apparently, the Apollo fixes in the code are for earlier versions of the
operating system.  At least, it calls for a number of include files
(notably, /sys/ins/*.ins.c) that were not present on our system until we
copied them from a SR9.7 system.  That's maybe not the smartest thing to do,
but at least it enabled me to compile C-kermit without errors.  However,
when I run it, the following happens:

        % wermit
        C-Kermit, 4E(070) 29 Jan 88, Apollo DOMAIN/IX 4.2 BSD
        Type ? for help
        C-Kermit>set line /dev/sio1
        /dev/sio1: Not a typewriter
        Sorry, can't open line: Not a typewriter
        C-Kermit>

/dev/sio1 is supposed to be the serial port on my Apollo DN3500.  We are
running Domain_OS SR10 with only the 4.3 BSD environment installed.  Any
help is appreciated!

- Harald Hanche-Olsen   Division of Mathematical Sciences
  [e-mail]    The Norwegian Institute of Technology

Please send any direct replies to me at [e-mail] (local mail
gateway troubles...).

------------------------------

Date: Wed, 8 Feb 89 10:33:59 EST
From: [e-mail] (D. Kobus)
Subject: VMS & C-Kermit Problem with Localnet
Keywords: VMS Kermit, C-Kermit for VMS, Sytek Localnet

While using C-Kermit on a Microvax II (VMS 4.4), when I CONNECT to my localnet
cable network I encounter a "contti: ttiosb.status: %SYSTEM-F-HANGUP, data set
hang-up" flag. This is not the case when I CONNECT to the same line when
successfully using VMS-Kermit. Also, once a localnet connection to another
computer is established, I can shell over to C-Kermit and communicate without
problem.

I have tried a variety of SET TERMINAL options without success. Frank da Cruz
of Columbia has pointed me to the offending code in the ckvtio.c routine but;
at present, comprehension of that programming eludes me.

If anyone on the net has encountered and overcome this hurdle, your response
will be appreciated.

David B. Kobus
Naval Air Development Center

------------------------------

End of Info-Kermit Digest
*************************

24-Feb-89 20:32:07-GMT,30517;000000000001
Received: by cunixc.cc.columbia.edu (5.54/5.10) id AA01128; Fri, 24 Feb 89 14:04:56 EST
Date: Fri, 24 Feb 1989 14:04:55 EST
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V9 #5
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Fri, 24 Feb 1989        Volume 9 : Number 5

Special MS-DOS Kermit Issue:

             MS-DOS Kermit at 115,200 bps
              MS-Kermit vs Screen Savers
          Behavior of MS-Kermit SUCCESS/FAILURE Status Flag
         Problem with Scripts in IBM-PC Kermit 2.31?
                   MS Kermit 2.32/A
            MS-Kermit Screen Highlighting
         MS-Kermit Highlighted Screen Characters vs IBM 7171
          Kermit Tektronix Emulation "More>" Prompt
           MS-Kermit Tektronix Emulation vs Numeric Keypad
            MS-DOS Kermit vs Toshiba 3100 Graphics
            Mouse Problems with MS-Kermit
      New Releases of KERMIT No Longer Support Microsoft/Logitech Mice?
                Wang version of Kermit
           MS-Kermit Receiving Files to a Printer?

Send digest submissions to [e-mail], requests for
addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or 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.
Login as user anonymous (note, lower case), 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 kermit/a/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: 26 Jan 89 21:05:00 GMT
From: michael regoli <[e-mail]>
Subject: MS-DOS Kermit at 115,200 bps
Keywords: MS-DOS Kermit Performance

hello!  i need help with the new version of ms-kermit (2.32 on 11 dec 88).

i have two AT microcomputers (IBM and zenith) connected through a serial
port with a null modem cable.  i am using extended packet lengths (1,000)
with a block check type of 3 (for use in transferring 8-bit data).
everything else is set to kermit defaults (with respect to flow control,
handshaking, delays, timeouts, retries, etc.).

my problem is that i cannot drive the cable faster than 57,600 baud.  when i
try 115,200 baud, i have problems with host acknowledgment and errors.
(i've even tried shortening the packet length to 94.  still, when the IBM is
in server mode, and a "send fn" on the zenith is performed, about 5 packets
get through and the IBM says "unable to send data" while the zenith reports
"unable to receive an acknowledgment from the host.")

how can i drive the cable at 115,200?  i know that the serial ports will
handle the speed because i've used MIRROR (a clone of crosstalk) at that
speed with both machines.

thanks for any help.  and by the way, this is an excellent upgrade to
kermit.  if you don't have it, you should.

                        |  michael regoli
                        |  ...rutgers!iuvax!silver!regoli
                        |  [e-mail]

[From jrd - A lot happens for each character to accomodate the diverse
situations Kermit faces in the field -- see the flowchart in the MS-Kermit
2.32/A manual.  Some other items to be aware of are the display adapter,
keyboard, and Helpful Utilities. The nice formatted file transfer display
calls on DOS (and hence the Bios) for support and parts turn off interrupts
long enough to lose characters; try SET DISPLAY QUIET or SERIAL. Keyboards
generate messages when ANY key is depressed and that causes the Bios to also
execute small code sections with interrupts off.  Finally, Helpful Utilities
which attach to the system clock tic are very heavy loads because the whole
interrupt system is completely blocked while they run 18.2 times/sec. Even
DOS PRINT does this in a marked way.

The problem is actually not so much the work done per character in Kermit,
although that determines the ultimate throughput, but rather what the
non-Kermit parts of the computer do with interrupts turned off. The slower
the machine then the longer it takes to do those system items. I have
successfully run MS Kermit between Zenith 4.77MHz PCs and other systems at
115Kb, provided the cable length is very short and the serial port crystal
oscillators are reasonably matched.  IBM PS/2's seem to quit working above
38,400 baud in my tests. In current development work here with disk i/o
occurring while packets are being received shows that the disk stuff causes
marked character loss at speeds of 56KB and faster; that was great for me
since I wanted lots of random errors for testing purposes!

Unload all of those TSRs, don't let DOS PRINT be used, specify enough DOS
buffers to keep DOS tracking fresh material, watch out for slow RAM disk
routines using Extended or Expanded memory on ATs, and be aware of add-in
boards (and particularly bus mice) eating system time.  It does work at
115KB.  People who really want speed use networks such as Ethernet, Token
Ring, Starlan, and similar which are designed for high data rates and
reasonable distances. Mirror and other Xmodem programs are fine for simple
PC to PC communications, Kermit is far superior (by design) when non-PC's
are involved or when the communications path is complex or hostile.]

------------------------------

Date: 26 Jan 89 15:08:00 CST
From: "DAVE CARGO" <[e-mail]>
Subject: MS-Kermit vs Screen Savers
Keywords: MS-DOS Kermit vs Screen Savers, Screen Savers

I just ran into a situation that I think MS-Kermit handles correctly, but I
thought I'd ask to make sure.  I'm running MS-Kermit 2.30 (I haven't had a
chance to update that system yet).  During long file transfers the screen
went blank.  In order to see what was on the screen I hit the space bar.
Are characters other than ^X, ^Z, return, etc. ignored during transfers?

I just want to make sure it's "safe" to hit the space bar when the screen
has been blanked like that.  (It's not my system and I don't know what
screen saver is being used; I couldn't remove it anyway.)

David S. Cargo

[From jrd - It is safe to type with abandon while packets flow, although it
does put a load on Kermit. Only the characters ^E, ^X, ^Z, ^C , and CR will
be let through the sieve. My screen saver reawakens with even ALT or NumLock
(my favorite way of doing it while within MS Windows and Excel).]

------------------------------

Date: Fri, 27 Jan 89 14:26:03 est
From: steinmetz!unioncs![e-mail] (Richard Boehm)
Subject: Behavior of MS-Kermit SUCCESS/FAILURE Status Flag
Keywords: MS-DOS Kermit Scripts

The User's guide to MSKERMIT 2.32 states, under "The INPUT command", "The
command reports a testable status of SUCCESS or FAILURE and sets the DOS
ERRORLEVEL parameter to 2 if it fails to match within the timeout interval.
As I understand it, a flag is set. It has been my experience, however, that
this flag may only be tested ONCE before it's value becomes RESET. This
behavior is not what I expect in a flag. I expect a flag to retain its
status until altered by an action of the program. When a flag resets itself
after testing, I consider it to be unusual.

I'm trying to login to a Unix system.  My login script must tell the called
modem what baud I'm using, and I can't do this directly. I have to have the
called modem cycle through its available speeds until we "connect". I do
this by sending a break from my end.  The code is:

  :LOOP
  INPUT 1 login:
  IF FAILURE OUTPUT \B
  IF FAILURE GOTO LOOP

This doesn't work. I can set take-echo on and see kermit send the break, but
it won't loop back.  I considered the possibility that in the short period
of time it takes to execute the instruction, the comm port had received
"login" and was continuing on, but then the baud rate of the two systems
would match - they don't.  I have a workaround, ie.,

    :LOOP
    INPUT 1 login:
    IF FAILURE OUTPUT \B
    REINPUT login:
    IF FAILURE GOTO LOOP

But shouldn't the SUCCESS/FAILURE flag be stable?

BTW - KERMIT is great. I've tried Procomm, Telix, and others. I always come
back.

  {uunet | philabs}!steinmetz!unioncs!boehmr            Richard E. Boehm, Jr.
  [e-mail]
  [e-mail]

[From jrd - Acknowledged, testable status ought to be rational. Alas, the
difficulty is finding the desirable subset of commands which can set status
and others which will leave it intact. More work is needed in this area. Tnx]

[Ed. - It's also possible to achieve some semblance of structured, goto-less
programming by using macros as if they were procedures.  In this case:

  def retry output \b, goto \%1
  :loop
  input 1 login
  if failure retry loop

should do the trick.]

------------------------------

Date: Wed, 16 Nov 88 18:38:07 EST
From: Lawrence Sewell <[e-mail]>
Subject: Problem with Scripts in IBM-PC Kermit 2.31?
Keywords: MS-DOS Kermit Scripts

I am having a problem with using logon scripts with IBM-PC Kermit.  It appears
that Kermit can lose/transform/add data that is sent to it from the remote
system when using scripts.  To explain the problem I am having, I need to give
you some background information.  My environment consists of:

System .................. IBM PS/2 Model 80
Operating System ........ PC-DOS 3.30
Kermit .................. IBM-PC Kermit-MS: 2.31 15 August 1988
                      and IBM-PC Kermit-MS: beta test of 2.31/A 9 Nov 1988
Communication settings .. COM1, SPEED 9600 and SPEED 19200, PARITY SPACE,
                          other settings are at their defaults
Communication network ... IBM-9751 Data Switching Network (Rolm CBX)
System accessed ......... IBM 7171 protocol converter attached to
                          an IBM 3090 running VM/XA SP1.

My script handles the details of accessing a data line on the CBX, placing a
call to the 7171, entering my terminal type (a VT100), and then starting
terminal emulation.  The last two steps of this process is performed the
following script commands:

  OUTPUT vt100-13 ;  enter the 7171 terminal type
  CONNECT ; start terminal emulation

When the terminal type is entered, the 7171 sends a series of VT100 setup
codes to the terminal.  This code consists of (in Kermit notation):

   \0D=\0D[H\0D[J\0D[?1;6l\0D?7h

When accessing the 7171 with SPEED of 9600 or 19200, everything is ok except
that my PC switches from 80 column mode to 40 column mode.  At lower SPEEDs
(e.g. 300, 1200, and 4800), I have no problems (e.g. my PC stays in 80 column
mode).  If I access the 7171 without using scripts, I have no problems using
every SPEED setting.  I assume that Kermit is seeing some command to set it to
40 column mode at these higher SPEED rates.

Is this a problem or "feature" of Kermit or am I doing something wrong in the
script?  Should I not use Kermit scripts?

I have gone through the "MS-DOS KERMIT USER GUIDE" and "Making PC software
work with digital PBXS" by Christine Gianone and Frank da Cruz (in Data
Communications October 1988, vol 17 no 11, pages 129-157) without finding
useful information.

[From jrd - When doing script commands Kermit is NOT in real terminal
emulation mode.  Rather, echos and the like are sent to the screen via DOS.
Your ANSI.SYS is interpreting the host's escape sequences and changing the
video mode to 40 columns.  Unless the CONNECT command is active ALL Kermit
output is sent to the screen via DOS.  This allows Kermit scripts to work on
non-IBM-compatible systems like the Rainbow, HP-150, Victor 9000, etc.
Under version 2.32 I added a helpful feature of not displaying echos of the
OUTPUT command if SET INPUT ECHO OFF is given.  This would leave the host's
echo material sitting in the serial port buffer ready to be read when
Connect mode begins.  If the host side has been told to not use XON/XOFF
flow control then there is no way to throttle the host while Kermit waits on
the printer.  P.S. I presume the "\0D" items above were \27, meaning the
ESCape character.]

------------------------------

Date: Tue, 31 Jan 89 11:35:27 CET
From: Knut Winsnes <[e-mail]>
Subject: MS Kermit 2.32/A
Keywords: MS-DOS Kermit VT102 Emulation, International Character Sets

Hi|  I picked up the latest version of MSkermit for the IBM-PC yesterday.
Great work, thanks|  I have some problems:
   -set translation input \x7c \x9b
    does not work as expected.  (VT100 emulation <-> IBM 7171).
    (It works under MSkermit 2.31).
    The vertical-bar symbol is not translated to the 'cent' symbol. (The
    cent symbol is mapped to a Norwegian character in PC-DOS/HW.)
    It disappears together with the blank characters following, and one
    non-blank character following the blanks.  (And the cursor does some
    strange movements, sometimes.).
    set translation input \x7c \x94 works well, (as a sample).
    Bug?
   -Pressing ctrl-s (xoff) during character reception 'eats' one
    or two characters and beeps the 'bell' (9600 baud).
    Same with MSkermit 2.31.  Bug or PC limitation?
   -On the 'un-enhanced' PC keyboard (Norwegian) some characters are mapped
    to more than one key.  The right character on a key-top = ALT-SHIFT+key.
             +---+  +---+  +---+
    Sample:  |( *|  |) (|  |= )|
             |8  |  |9  |  |0  |
             +---+  +---+  +---+
    Is it possible to SET KEY ALT-SHIFT-0 to a value, without setting
    SHIFT-9 to the same value?

Knut / Norwegian School of Management

[From jrd - Similar comments from [e-mail], also in Norway.  The CSI
character, 9bh / 155d, should have been detected as CSI before SET
TRANSLATION INPUT rather than afterward. A natural dilemma actually,
depending on whether one wants SET TRANS to do language work or to
compensate for communications pecularities.  I'll do better next time.  On
many machines touching ANY key invokes the Bios momentarily and that can
shut off interrupts briefly. My DELL 310 (early model) came with a built-in
keyclick routine which kept interrupts off for very long intervals; I have
to manually say ALT grey minus several times to fully turn off the darned
thing. The Beep/Control-G is a reminder from the Kermit serial port code
that one or more characters have been lost and the Control-G is the
replacement. Key mapping: the thing to try is SET KEY and see what your Bios
reports on various key mappings. Kermit takes what the Bios provides and
actually knows nothing about what's printed on keycaps.]

------------------------------

Date: Sunday, 23 October 1988  01:24-MDT
From: cadre!pitt!cisunx![e-mail] (Patrick Champion)
Subject: MS-Kermit Screen Highlighting
Keywords: MS-DOS Kermit VT102 Emulation, Screen Highlighting

I have noticed that mskermit 2.31 still has a problem displaying files.  If
one runs RN or MAN on unix, as soon as the highlighted letters in these
program are displayed, kermit goes from normal intensity to a dimmer
intensity.  Why does this happen, and is there anyway to avoid it.  For
example, I saw someones terminal displaying those highlighted (underlined?)
words in a different color.  This seemed to avoid the dimming of the
following text.

  Patrick Champion
  [e-mail]
  [e-mail]

[From jrd - One would have to know what the Unix system is sending to
control highlighting of characters. I gather that it is something like
ESC [ 0 m, meaning turn off bold/blink/etc. Check your termcap file for
particulars and modify it accordingly. At this time MS Kermit does not
provide separately adjustable colors for various attributes, but the host
may do so simply with the ESC [ 3x or 4i m sequence (ANSI style).]

------------------------------

Date: Tue, 13 Dec 88 14:57:26 GVA
From: "J.-M. Saint-Viteux CERN - DD" <[e-mail]>
Subject: MS-Kermit Highlighted Screen Characters vs IBM 7171
Keywords: MS-DOS Kermit VT102 Emulation, Screen Highlighting, IBM 7171
Xref: 7171, See IBM 7171

I currently use MS-kermit version 2.31 to emulate a VT100 terminal attached to
an IBM mainframe (running VM/SP) via a 7171.  I am very satisfied with that
apart from one thing: I am unable to distinguish highlighted (or bright)
characters from normal intensity ones.  Is there a way to do that (by getting
highlighted characters in a another color or in bold like Mac/Versaterm for
instance)?  This feature is very important for our site because information
are hidden in highlighted characters (that is the way a default response of an
online screen appears for instance).  I would like to thank you very much in
advance for your reply.

        J.-M. Saint-Viteux /CERN lab

[From jrd - MS Kermit provides the normal/bold/inverse video attributes as
a VT100. If your normal screen is bold and the host says bold then, clearly,
one will see no difference. If the host does not send the ESC [ .. m sequence
then Kermit will do nothing at all. See the MS Kermit User's Manual, file
MSKERM.DOC, for details on the standard escape sequences and the reply above.]

----------------------------

Date: 18 November 1988 1249-PST (Friday)
From: [e-mail] (Rick Butterworth)
Subject: Kermit Tektronix Emulation "More>" Prompt
Keywords: MS-DOS Kermit Tektronix Emulation

We have been using a variety of terminal emulation programs and file transfer
applications for years, but just recently stumbled into MSKermit, the program.
We have been delighted to find KERMIT, and are very excited at each feature we
discover.  We would like to use MSKermit for emulation of a Tek 4014 in
support of our mainframe graphics based DSS applications.

There is one problem however, and that is the "More>" pause that occurs
whenever it appears that text is being written below the last line of the
screen.  While drawing a graph on the screen, our programs do not continue
beyond the last line, however the "More>" is interrupting our graphic output.
After some thought, we realized that CP (our applications run on IBM's CP/CMS,
aka VM) is terminating our output lines with <CR>, and possibly <LF> and <NUL>
as well.  While no visible character is transmitted, MSKermit is dutifully
pausing and then erasing the screen anyway.  As our application manages text
on the screen with erase as needed, we could live with no "More>".  We looked
for a way to set the Tek margin pause off, but there appears to be none.  We
realize KERMIT is working as documented.  Is there a way to replace the Tek
emulation erase sequence with some innocuous one like nuls? If so, I can not
seem to find it. Have you any suggestions?  Thanks.

/Rick Butterworth

[From jrd - a real Tek 40x0 device will roll over text from the bottom of the
screen to the top of the right half of the screen, over writing what was
there. When it fills that half a light comes on the control panel to push a
button to resume operation. Instead, Kermit places the "more>" msg at the
lower right corner (there being no convenient light to illuminate) and awaits
a carriage return, the same as the DOS MORE filter program.  Somehow your
applications program is attempting to move the "cursor" below the screen since
I display the "more>" message only in that circumstance.  I'd suggest your
programs be instructed to move up one line before ending a graph since there
is no mechanism to turn off the page full indicator.  The SET TRANSLATION
INPUT command is effective in Tek mode, but that modifies characters singly
rather than recognizing character strings. You might want to modify the source
code in file MSGIBM.ASM and remove the "more>" message for local use.]

------------------------------

Date: Wed, 4 Jan 89 11:26:18 EST
From: [e-mail]
Subject: MS-Kermit Tektronix Emulation vs Numeric Keypad
Keywords: MS-DOS Kermit Tektronix Emulation, MS-DOS Kermit Mouse Support

I've recently started using MSKermit 2.31 (Aug 15 '88), and have particularly
appreciated the Tek 40xx emulation. It has a small problem which I'd like to
report.

There is apparently no distinction made between the numeric keypad and the
upper row of numeric keys, at least under certain limited circumstances.  I
ran into this problem during graphics input mode when the program I was using
wanted a numeric value from 1 to 4 inclusive along with the cursor position.
Usually striking a key should send the ASCII code along with the cursor
position to the host, and indeed MSKermit manages to do this most of the time.
However, for the upper numric keys "2", "4", "6", and "8", what happens
instead is that the graphics cursor moves!! It seems that the T40xx emulation
code moves the graphics cursor based on a keys ASCII code rather than a scan
code. Unfortunately, I can't find anything in the documentation file that
hints at any way to control which key scan codes cause cursor movement. That
seems to be assembled into the program.

By the way, I've observed this exact same problem on an IBM PC Convertible, a
Zenith Z-158 with Hercules card, and a Dell System 220 which uses the C&T
chipset to provide Hercules/CGA/EGA/VGA graphics modes.  Has anyone else had
this problem, and has it perhaps been fixed already?

Also, are you aware of any plans to support a mouse for graphics input?  My
machine has a Microsoft bus mouse and that would be much nicer that fiddling
with cursor keys.

Many thanks for your time and attention, and thanks for a very useful product.

[From jrd - MS Kermit uses DOS to obtain keyboard information while within the
Tektronix emulator. Thus the regular numeric keypad arrow keys produce cursor
motion but the shifted numeric keypad arrow keys are reported by DOS as
numbers. Shifted arrow keys are used for crosshair speed control and thus
overlap the upper rank numeric/punctuation keys. Maybe we can do something
constructive about this later on.

Mice work just fine, but you may find the cursor motion slow since Microsoft
has set up matters to do one effective arrow key for only many "mickeys." This
might be adjustable with the mouse driver setup program.  In any case, go
ahead and use the mouse; it works here with the Microsoft serial mouse, but
use the MS mouse programs MOUSE ON and then DEFAULT to make the mouse emulate
the arrow keys.]

------------------------------

Date: Thu, 01 Dec 88 23:59:42 CET
From: Kurt Ernulf <[e-mail]>
Subject: MS-DOS Kermit vs Toshiba 3100 Graphics
Keywords: MS-DOS Kermit Tektronix Emulation, Toshiba 3100 Graphics

Dear Friends,

Congratulations to the new Kermit version!  As always, it is a great program,
widely in use here at the Dept. of Psychology, Univ. of Goteborg, Sweden.

One little bug seems to be persistent, though. The Toshiba 3100 fails to
display 640x400 graphics, even though Kermit is set to GRAPHICS ATT, but
yields "only" CGA 640x200. Would it be possible to fix this bug?  It would
greatly enhance our working environment|

Thanks,
Kurt Ernulf

[From jrd - Check the version 2.32 release.  Kermit looks in memory location
F000:14H for the string T3100 TOSHIBA with the characters doubled.]

------------------------------

Date: Tue, 15 Nov 88 17:42:34 MEZ
From: Konrad Neuwirth <[e-mail]>
Subject: Mouse Problems with MS-Kermit
Keywords: MS-DOS Kermit Mouse Support, Norton Commander

When I quit MS-KERMIT and start the Norton Commander Version 2 (I did not try
with version 1), the program simply does not react to the mouse. I have a
MicroSOft SERIAL Mouse, so I think here is the problem.  If I use a program,
that I know uses the Mouse Driver, I don't have any problems, so I suppose the
Commander takes the imput directly from the mouse. I suppose that Kermit takes
up some interrupts, or sets some pointers, and does not restore the to ther
original value or position or whatever. But it is just a guess. Please, can
anyone help me?  Thanks!

  Konrad Neuwirth
  Fernkorngasse 44-2-4
  A-1100 Wien, Austria

[From jrd - I have had no problems between MS Kermit and the Microsoft serial
mouse on my systems. Kermit is very very careful about interrupts and the
like, much more so than most programs. The problem likely lies with Norton
Commander's assumptions about mice drivers and serial ports.  I presume the
mouse is not on COM1 since Kermit starts up using COM1 and later can be
switched to another port. If it does change ports it tells the old port to
turn off interrupts, as it should. For example, using COM1 and COM3 on the
same interrupt line means that only one port can be left active. Try the
Microsoft mouse driver support program MOUSE.COM and say MOUSE OFF or MOUSE
ON, as appropriate. I also use the mouse with Kermit under Windows/1/2/386
with no interference; occassionally I even have Kermit talk with the mouse to
demonstrate for visitors what those clicks mean to PC's.]

------------------------------

Date: Wed, 11 Jan 89 15:31 PST
From: <[e-mail]>
Subject: New Releases of KERMIT No Longer Support Microsoft/Logitech Mice?
Keywords: MS-DOS Kermit Mouse Support

MS-Kermit version 2.30 worked with both Microsoft Mouse and Logitech Mouse
using the escape sequences built into the mouse drivers.  Under MS-Kermit
version 2.31, both the Microsoft and the Logitech mouse quit working.  Can you
please implement support for these mice under a future release of MS-Kermit or
indicate how to get these mice to work under existing (version 2.32) versions
of Kermit.
                                                Dr. A. Olin/Y.N. Miles

[From jrd - Surprize! Kermit never has attempted to understand the escape
sequences of mice as such. However, I note that my MS serial mouse likes to
send characters with parity so the Kermit command line parser sees 8-bit
characters these days. At the command line level SET PARITY has no effect
since the command applies to serial port material rather than the keyboard.  I
do not know how the mice are being used (command line, inside Connect mode, in
Tek emulator mode, etc) but locally saying MOUSE ON, DEFAULT (MS programs, the
latter meaning use the default mouse menu) makes the mouse emulate the arrow
keys and Kermit is happy with them at the DOS level. This lets one use mice to
control the Tek crosshairs since the keyboard is read at DOS level rather than
via the Bios (where the mouse would not be observed).]

------------------------------

Date: Sun, 29 Jan 89 23:23:37-1000
From: Tom Wilson  <[e-mail]>
Subject: Wang version of Kermit
Keywords: Wang PC

The current Wang PC version of Kermit appears to still lack a large number
of commands found on the IBM-compatible version.  Is there someone working
on creating a Wang-specific version?  I am short on time right now, but am
interested in producing a Wang version if there is no one else working on
this.  (I have previously written a VT-100/tektronix emulator with
upload/download (no error checking) for the Wang, so I understand the major
quirks of the sytem.)  Can you tell the development status of a Wang
version?

Secondly, are all the PC versions of Kermit in assembler?  It seems that
much of the code could be in C instead, with only low-level stuff in
assembler.  Does such a beast exist?  I have seen C-Kermit (slightly), but I
get the impression that it is for unix systems or at least time-sharing
systems.  What other info is available/what is the status of this?

[From jrd - We do need an active volunteer to work on Wang PC Kermit. There
is no Wang technical documentation here so development has ceased. I'd be
pleased to work with you in upgrading it to version 2.32/A.

On C vs Assembler for MS Kermit. It started in assembler and the effort
versus reward to convert it is not beneficial. My own perspective, biased to
be sure, is that performance/flexibility/etc are vital and language per se
is nearly a non-issue. I think in terms of algorithms, performance, and cost
and rather than language (transparent after frequent use) or "low/high"
level and the like. C Kermit is designed to run on a very wide variety of
machines. However, its features are quite different than those in MS Kermit,
particularly the user interface.  Finally, it's been my experience that very
few people actually work in the source code of Kermits, of whatever
language, since they are not exactly simple exercises. This is unfortunate
because Kermit is what it is because it is also very much a community
development (vs a closed commerical operation).  We would welcome someone
doing a complete conversion of MS Kermit from assembler to portable C
(omitting vendor-specific items) and maintaining performance in critical
areas. Before starting however, do have a careful look at both C Kermit and
MS Kermit sources. It's one of those "could" versus "should" affairs.]

------------------------------

Date: Tue, 31 Jan 89 15:14+0100
From: [e-mail]
Subject: MS-Kermit Receiving Files to a Printer?
Keywords: MS-DOS Kermit Printer Support

I have got the new KERMIT 2.32 release for PC (MS-DOS).

With version 2.31 I have lost data when receiving files to my printer. Now
with the new version the host hangs up when receiving files to a printer if
the files are longer then 40-50 lines.  Then I have to cancel the
listing-job and restart (without printing).  Sometimes I have to login new.

Is this a bug of Kermit 2.32 or is there any way to receive files to a
printer without hang up of the host?
                                         Achim Marx
                                         BITNET: Marx -at DMZRZU71

[From jrd - This is most likely an XON/XOFF flow control mismatch between
the PC and the host.  MS Kermit 2.32/A will properly print at almost any
baud rate, 2.32/A being slightly smarter about extra XON/XOFF's than earlier
versions, but the host must support XON/XOFF flow control to avoid overruns
on the communications line.]

------------------------------

End of Info-Kermit Digest
*************************

 4-Apr-89 22:50:51-GMT,18993;000000000001
Return-Path: <[e-mail]>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
    id AA11347; Tue, 4 Apr 89 18:50:45 EDT
Received: from watsun.cc.columbia.edu by cunixc.cc.columbia.edu (5.54/5.10) id AA20115; Tue, 4 Apr 89 18:46:42 EDT
Received: by watsun.cc.columbia.edu (4.0/SMI-4.0)
    id AA11199; Tue, 4 Apr 89 18:28:18 EDT
Date: Tue, 4 Apr 1989 18:28:17 EDT
From: Christine M Gianone <[e-mail]>
To: [e-mail]
Subject: Info-Kermit Digest V9 #6
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Tue, 4 Apr 1989        Volume 9 : Number 6

Today's Topics:

         New Network Address for Kermit Distribution
        Kermit File Server Available on LISTSERV@HEARN
     Proposed Kermit Protocol Extension for International Character Sets
        New Release of C-Kermit Available for Testing
            C-kermit on apollo under SR10!
           Announcing the Final Test of OS/2 Kermit
       Announcing Kermit for Hewlett-Packard BASIC Workstations
             TSO Kermit-370 through VTAM
         Terminal Controller Detection in Kermit-370
               Graphics devices and CMS Kermit
            CMS Kermit for IBM 3174 w/AEA

Send digest submissions to [e-mail], requests for
addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or 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.
Login as user anonymous (note, lower case), 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 kermit/a/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 Mar  13 11:42:49 1989
From: Christine M Gianone <[e-mail]>
Subject: New Network Address for Kermit Distribution
Keywords: cunixc, watsun, Network Distribution of Kermit

The home system for Kermit distribution has moved from cunixc.cc.columbia.edu
(a VAX 8700 running Ultrix 2.2) to watsun.cc.columbia.edu (a SUN-4/280 running
SUNOS 4.0).  The Internet host number for watsun is 128.59.39.2.

Cunixc will remain active and accessible to anonymous ftp, and its Kermit
files will remain up-to-date until further notice.  Internet users are
encouraged to ftp from watsun rather than cunixc, because cunixc is a busy
system that tends to be overloaded and slow during peak hours, and watsun
should be able to handle the ftp traffic better.

You should begin sending e-mail to Info-Kermit and Info-Kermit-Request at
watsun rather than cunixc.  The cunixc e-mail addresses will remain effective
until further notice.

------------------------------

Date: Thu, 23 Mar 89 16:28:45 MET
From: "INFOatHEARN (EARN-NL Info Service)" <[e-mail]>
Subject: Kermit File Server Available on LISTSERV@HEARN
Keywords: HEARN, LISTSERV, Netherlands, Kermit File Servers

Since several weeks the complete KERMIT database is available on the EARN node
HEARN in The Netherlands.  All files from the Kermit server in the USA
(KERMSRV@CUVMA) are available on the Dutch node and every week in the night
from Sunday onto Monday the Dutch server is updated.

All files are available via LISTSERV@HEARN and are listed in KERMIT FILELIST.
This file can be requested by:

  VM/CMS:  TELL LISTSERV AT HEARN GET KERMIT FILELIST
  VAX/VMS: SEND LISTSERV@HEARN GET KERMIT FILELIST

A specific file is requested by:

  VM/CMS:  TELL LISTSERV AT HEARN GET fn ft KERMIT
  VAX/VMS: SEND LISTSERV@HEARN GET fn ft KERMIT

The use of the word KERMIT at the end of the command prevents LISTSERV from
searching in other databases.

Marc de Lyon / Frans-Jozef Sprengers,

INFOatHEARN (EARN Info Service in The Netherlands)
Acknowledge-To: <INFO@HNYKUN11>

[Ed. - Many thanks to the brave people at INFOatHEARN for setting up a
European Kermit Distribution area for BITNET/EARN.  This will greatly
alleviate the transatlantic network congestion that has occurred in the past
when new versions of Kermit are announced from Columbia.  European users are
urged to obtain their Kermit files from LISTSERV@HEARN rather than
KERMSRV@CUVMA from now on.]

------------------------------

Date: Mon Apr 3 11:42:49 1989
From: Christine M Gianone <[e-mail]>
Subject: Proposed Kermit Protocol Extension for International Character Sets
Keywords: Kermit Protocol, International Character Sets
Keywords: ISO Standards, Japanese
Xref: National Characters, see International Character Sets

A very rough, preliminary draft proposal for an extension to the Kermit file
transfer protocol is now available for review.  Its purpose is to allow the
transfer of multi-language text files between unlike computer systems.  The
new transfer syntax uses the 8-bit character sets defined in the ISO 8859 and
similar standards, and mechanisms for switching among them defined in ISO
2022.  Japanese and other multi-byte character sets are handled by similar
mechanisms.

If you would like to read this document (about 70K), it can be ftp'd from
watsun or cunixc as kermit/test/isok2.txt, or, on BITNET, obtained from
KERMSRV@CUVMA as T:ISOK2.TXT.  The "2" denotes draft #2.  Future drafts will
be isok3.txt, isok4.txt, etc. (but not too many of them!).  A special splinter
group e-mail list, "isokermit", has been set up for those who would like to
discuss these issues in detail.  If you would like to join this group, please
let me know.

------------------------------

Date: Mon Apr 3 10:01:15 1989
From: Frank da Cruz <[e-mail]>
Subject: New Release of C-Kermit Available for Testing
Keywords: C-Kermit, UNIX Kermit, Attribute Packets, SUN, Ultrix, VAX/VMS
Xref: File Attributes, see Attribute Packets

This is to announce a test release of C-Kermit, 4F(077).  The major new
feature is limited support for file attribute packets.  C-Kermit can send
attribute packets containing system ID, file sizes (K and bytes), and
encoding method (text or binary), and will honor positive and negative
responses.  The command 'set attributes {on, off}' was added, to allow
attribute packet processing to be disabled in case of misunderstandings; it
is enabled by default.

C-Kermit also receives and reads attribute packets but so far does nothing
with these attributes except for "Disposition" (Attribute "+").  If the
disposition is M, then the file is mailed to the designated address(es).  If
the disposition is P, then the file is printed with the specified options.
These operations are currently done in the obvious, crude way (via
"system()"), and only for UNIX.  The LOG DEBUG command will record attributes
in the debug log.

MS-Kermit users will notice that when receiving files from C-Kermit, the
percent transferred will be displayed, and that MS-Kermit will refuse to
receive files from C-Kermit that are too big for the available disk space.
Also the MS-Kermit MAIL command will work with C-Kermit in RECEIVE or SERVER
mode.

Other changes include:

 -  Improved speed when sending files, most noticable on slower machines.
    Thanks to Paul Placeway of Ohio State University for supplying a new
    buffered file input function, along with reorganizing the packet encoding
    functions.

 -  The SET SERVER TIMEOUT command was added to control the rate at which the
    C-Kermit server issues NAKs during command wait, 0 = no NAKs at all.  The
    server's periodic NAKs can interfere with originate/answer devices like
    digital PBXs or autodial modems, putting them in originate mode when the
    user wanted the device to be in answer mode.  SET SERVER TIMEOUT 0 can now
    be used in such situations.

 -  Make C-Kermit send NAKs: ckcpro.w, ckcfns.c, ckcfn2.c, ckcmai.c.  Up till
    now, C-Kermit has always responded to a corrupted packet or a timeout by
    resending its previous packet.  It turns out that when talking to a more
    generalized Kermit program -- i.e. one that provides for sliding-window
    packet transfer, in which a window size of 1 is just a special case --
    that it is better for C-Kermit to send NAK packets in response to
    corrupted packets or timeouts, which a sliding-windows Kermit will act
    upon immediately.

 -  Cure a longstanding protocol bug in which Kermit would sometimes fail to
    send files whose names started with capital X or Z.

 -  Fixes to ensure that UNIX versions catch the HUP (hangup) signal, and
    clean up and disappear properly in the event of a telephone disconnection.

 -  In remote mode, when file transfer is done over the job's controlling tty,
    use file descriptor 0 (stdin) rather than obtaining a new file descriptor
    on the terminal.  This allows UNIX "idle line monitors" to properly detect
    Kermit activity and not log out Kermit users in the middle of 40-megabyte
    file transfers because the tty line appears to be idle.

 -  Add UNOS support from David MacKenzie, [e-mail].

 -  Slightly better support for Hayes modems -- catch the case where user
    dials out at 2400 but gets connected at 1200.

 -  Several minor bug fixes.

See the file ckuker.upd for details about the changes.

This release needs to be tested thoroughly on as many different kinds of UNIX
systems as possible -- pure Berkeley (2.9, 2.10, 4.1, 4.2, 4.3), AT&T (System
III, V, and VR3), Xenix (all varieties), etc etc.  It has been tested so
far on 4.2BSD-based systems (Ultrix 2.0 and SUNOS 4.0) and AT&T System-V
systems (the AT&T Unix PC).

For now, the new release is available via ftp from cunixc.cc.columbia.edu, in
the directory kermit/test/ck*.  Please get the files, try them out, and report
any problems to me.  After the kinks are worked out, version 4F will replace
the current standard 4E release.

BITNET/EARN users may also access the test files in the new KERMSRV test area.
Refer to these files as T:CKU*.*, T:CKC*.*, and T:CKW*.*, for instance:

  TELL KERMSRV AT CUVMA MAIL DIR T:*.*
  TELL KERMSRV AT CUVMA SEND T:CKC*.*

Among the files in the test area, you will also find updated VAX/VMS support
files for C-Kermit from Mark Buda at DEC.  These are a "work in progress" and
are not quite usable yet.  If you would like to look at them, their names all
begin with the letters "ckv" (in KERMSRV, they are T:CKV*.*).  They will be
updated from time to time, as will the other files in this area, as bugs are
fixed, etc.  Watch forthcoming issues of Info-Kermit for announcements of
improved VMS versions of C-Kermit, and a real release of version 4F in general.

------------------------------

Date: Tue, 4 Apr 89 20:05:36 +0200
From: [e-mail]
Subject: C-kermit on apollo under SR10!
Keywords: C-Kermit, Apollo Kermit

I asked earlier about making C-Kermit work under SR10 on an Apollo.  I
now have the answer, thanks to our local Apollo representative.
Although the silence following my query was deafening---suggesting
that no one on this list uses Apollos---I will now report the fix.

The problem is basically this: The C-kermit code is full of special
code to handle Apollos.  All this code turns out to be unnecessary
(and indeed harmful) when running under SR10, since the operating
system is now much more Unixlike.  Unfortunately, even the C compiler
provided with the 4.3BSD environment of SR10 defines the preprocessor
symbol aegis, thereby activating the unwanted code.  I fixed this by
inserting a new item in the makefile, looking like this:

#Apollos running SR10.0 or later:
sr10-bsd:
    make wermit "CFLAGS= -DBSD4 -DDEBUG -DTLOG -Uaegis"

I also needed to add one line to ckcmai.c (anywhere near the beginning):

#undef apollo

and then the program compiled like a charm.

I also discovered that you must use /dev/tty??, not /dev/sio? as the
latter access the serial lines at a lower level than is standard on
Unix systems.

- Harald Hanche-Olsen   Division of Mathematical Sciences
  [e-mail]    The Norwegian Institute of Technology

------------------------------

Date: Wed, 15 Mar 89 13:34 CST
From: [e-mail]
Via: [e-mail]
Subject: Announcing the Final Test of OS/2 Kermit
Keywords: OS/2 Kermit, IBM PS/2, PS/2

This is to announce a new version of C-Kermit for OS/2 for the IBM PS/2
family.  Version 1.0p fixes a number of bugs in the VT100 terminal emulator,
which is now upgraded to a VT102.  Many thanks to all those who commented on
the previous releases, and particularly to Kevin Lowey at the University of
Saskatchewan and to Peter White of the University of New Brunswick for their
advice on the emulation.  The documentation is also updated, to explain better
the interaction of Kermit with the OS/2 MODE utility.

If no bugs are reported to me by Monday 1st May 1989, this version will become
the first full (ie. non-beta-test) release of C-Kermit for OS/2, at which
point the version number will be changed to 1.0 and the sources will be
released.

Please send bug reports to "[e-mail]"

Chris Adie

[Ed. - Thanks to Chris, and to Kevin for relaying the material to Columbia.
The new release replaces the previous one in the Kermit Distribution "B" area
as files cko*.*.]

------------------------------

Date: Wed Mar  1 11:42:49 1989
From: Christine M Gianone <[e-mail]>
Subject: Announcing Kermit for Hewlett-Packard BASIC Workstations
Keywords: HP-9000 Kermit, BASIC Kermit
Xref: Hewlett-Packard, See HP

This is to announce Kermit for the HP 9000 Series 200 and 300 BASIC
workstations, written in HP-BASIC by Andrew Campagnola of Hewlett-Packard
Measurement Systems Division in Loveland, Colorado, with contributions from
Keith Moore at the HP NJ Division labs.  This version, Kermit-RMB 1.0, of the
program is the initial release.  Kermit-RMB is capable of both remote and
local operation, transfers text and binary files over both 8-bit and 7-bit
connections, emulates the DEC VT100 terminal, does raw uploads and downloads,
includes logging functions, has a macro facility, and handles Kermit File
Attribute packets.  It also printer control, a hex editor and dump facility,
and a file type conversion utility.  It lacks certain other capabilities
including wildcard send, 2- and 3-character checksums, server functions, and
long packets.  The program runs on any Series 200/300 computer with 1MB of
memory and BASIC 5.0 or greater, and will run on any HP serial interface
available for these computers.

Kermit-RMB comes with an extensive manual, BASIC source code, and binaries
encoded in hexadecimal format.  The files are in the "C" area of Kermit
Distribution, kermit/c via anonymous FTP, or on the C tape, as files whose
names start with HPB.  The program will also be distributed by Interex, the
international HP computer user group, on native-format 3.5" diskettes, and
can also be obtained over BITNET from KERMSRV at CUVMA.

Many thanks to Andy for contributing this program.

------------------------------

Date: Mon, 1989 Feb 13   13:54:52 EST
From: (John F. Chandler)   [e-mail]
Subject: TSO Kermit-370 through VTAM
Keywords: Kermit-370, Protocol Converters, VTAM, TSO Kermit

A new update is now available, thanks to Herb Huston at GSFC, for
automatically detecting the presence of VTAM controlling a line-mode
connection on TSO.  The new code then sets the controller type to VTAMTTY and
removes the necessity for the user to do it by hand (or to rely on the Kermit
installer for setting the default controller type to VTAMTTY).  The update is
available in IKTKER.UPD in the Kermit distribution.  This update is
particularly useful at sites with both VTAM and TCAM TTY lines, since no
default there would satisfy everyone.

------------------------------

Date: Mon, 1989 Feb 27   13:10:35 EST
From: (John F. Chandler)   [e-mail]
Subject: Terminal Controller Detection in Kermit-370
Keywords: Kermit-370, Protocol Converter, VTAM

Release 4.1 of Kermit-370 has code for automatically detecting whether a
full-screen terminal is a SERIES1-type or not by issuing a SERIES1 status
request (which is "illegal" for controllers not compatible with the Yale ASCII
communication system).  Unfortunately, some users report that VTAM refuses to
allow such a command through.  Can anyone familiar with VTAM operation suggest
a way of making it more amenable?

------------------------------

Date: Fri, 1989 Mar 31   17:16:16 EST
From: (John F. Chandler)   [e-mail]
Subject: Graphics devices and CMS Kermit
Keywords: Kermit-370, Graphics, VM/CMS Kermit

I'm looking (again) for anyone who is interested in getting CMS Kermit to run
with the class of protocol converters known as Graphcis devices (including
MICOM, PCI, and LeeData models, among others).  This time, I have not one, but
two, new possibilities of code to try as alternatives to the standard-issue
CMS Kermit 4.1.  The few people who have tried CMS Kermit with Graphcis
devices in the past (and bothered to report their results) have been
frustrated by failure, but there is now a very good prospect of getting at
least one version to work.  Please, let me know if you're interested.  Also,
if you happen to have tried CMS Kermit successfully with one of these devices
(I'm still hoping), I would love to have the details.

                                    John

                                    BITNET:   PEPMNT@CFAAMP
                                    Internet: [e-mail]
                                    SPAN:     CFAPS2::CHANDLER

------------------------------

Date: Wed, 29 Mar 89 10:05:59 PST
From: GEORGE WESTLUND <[e-mail]>
Subject: CMS Kermit for IBM 3174 w/AEA
Keywords: Kermit-370

I've tried the IBM-NETS and LIAISON groups with little or no success, so
now I'll ask you guy's...

Are you aware of a version of IBM-CMS Kermit that will work with an IBM 3174
Remote communications controller with ASCII Emulation Adapters?  If one
exists, I need to know the version number so I can convince our systems people
to upgrade.  If one doesn't exist, is there a chance of one in the near
future?  Can you put me in touch with anyone who could provide more
information.

I have already received a couple of querries from users who would also
like this capability.

All help appreciated!

[Ed. - Others have asked about this.  Anyone?]

------------------------------

End of Info-Kermit Digest
*************************



27-Apr-89 20:26:41-GMT,25864;000000000001
Return-Path: <[e-mail]>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
    id AA23762; Thu, 27 Apr 89 16:26:33 EDT
Received: from watsun.cc.columbia.edu by cunixc.cc.columbia.edu (5.54/5.10) id AA26589; Thu, 27 Apr 89 16:25:38 EDT
Received: by watsun.cc.columbia.edu (4.0/SMI-4.0)
    id AA23647; Thu, 27 Apr 89 16:14:06 EDT
Date: Thu, 27 Apr 1989 16:14:06 EDT
From: Christine M Gianone <[e-mail]>
To: [e-mail]
Subject: Info-Kermit Digest V9 #7
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Thu, 27 Apr 1989        Volume 9 : Number 7

Departments:

  MS-DOS KERMIT
           How to Enable Printer Under MS-Kermit
       Keycodes for WordPerfect and MS-Kermit
           MS-DOS Kermit Praise
           MS-Kermit V2.32/A Tek4010 Emulation
           MS-Kermit Flow Control Problem
           MS-Kermit with ProKey
           MS-Kermit Tektronix Emulation vs MCGA
           Problem with MS-Kermit 2.32A Scripts

  IBM 370 KERMIT -
           Kermit-370 vs WallData Protocol Converters
           Questions about 370-Kermit and MacKermit

  MACINTOSH KERMIT -
           MacBinary for MacKermit?

  PDP-11 KERMIT
           Problem Kermit Running Under RSTS/E v7.2

  CP/M KERMIT -
           Bug report, CP/M kermit (and other notes)
           Kermit on Northstar Horizon?
           Kermit on Archives 2 Z80 Box

Send digest submissions to [e-mail], requests for
addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or 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.
Login as user anonymous (note, lower case), 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 kermit/a/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: 4 Apr 89 22:23:03 GMT
From: [e-mail] (Ubben Greg)
Subject: How to Enable Printer Under MS-Kermit?
Keywords: MS-DOS Kermit Printer Support, pcprint

I have an IBMPC running MS-Kermit (emulating a vt100) to connect to a Unix
host, and would like to write a shell script on the host which will print a
file on the PC's local printer.  In other protocols, this is handled by
outputting a special character sequence which tells the PC that the following
text should be routed to the printer, outputting the file, and then outputting
the sequence to turn off the printer.  However, I cannot find such a sequence
(be it a DOS, ANSI, Kermit, or vt100 command) that works under this configura-
tion.  Can someone please enlighten me?

                                -- Greg Ubben
                                   Johns Hopkins University

[Ed. - We have a program that does just what you need: "pcprint".  It's in
kermit/a/msppcp.* (.c = C language source, .nr = nroff man page source).
Theoretically, all you need to do is have Unix send the ANSI transparent print
sequence (ESC [ 5 i) at the beginning, and (ESC [ 4 i) at the end.  The
following shell script would normally do the trick:

    #!/bin/sh
    echo -n '<ESC>[5i'
    if [ $# -eq 0 ]; then
      cat
    else
      cat $*
    fi
    echo -n '<ESC>[4i'

(where <ESC> is a real ESC character).  But since most Unix systems transmit
even parity, this can foul up the printer.  The pcprint program takes care of
this by doing its output in 8-bit "raw mode".  The program currently works
only in Berkeley-based Unix implementations, but should be easily modifiable
for ATT Unix.]

------------------------------

Date: Thu, 20 Apr 1989 21:28:30 EDT
From: "Joe R. Doupnik" <[e-mail]>
Subject: Keycodes for WordPerfect and MS-Kermit
Keywords: WordPerfect

I have obtained an MS-Kermit initialization file which defines the keys
expected by mainframe WordPerfect.  It seems that people find this to be a
scarce item.

[Ed. - Thanks, Joe!  This file has been added to the Kermit distribution
as MSIWP.INI.]

------------------------------

Date: Sat, 1 Apr 89 21:09:51 PST
From: kenn r stump <[e-mail]>
Subject: MS-DOS Kermit Praise
Keywords: MS-DOS Kermit 2.32/A

Kermit V2.32/A is an excellent program.. For once, I have a true terminal
emulation which doesn't get whipped and flogged by cursoring commands.  The
file transfer is excellent, too..  Works Great..  Couple of bugs once in a
while, but can be overlooked easily..  (especially if you follow proper
procedure on transferring files, right?)

Very good Software..  Am very impressed..  However, the manual could have been
a tad bit smaller..  But life has its rough moments..

[From jrd - Nice words are always welcomed!  Look for a new release this
summer, with many many new features including decent sliding windows.  We've
been working on it since before version 2.32 was announced.]

------------------------------

Date: Wed, 12 Apr 89 09:08 EDT
From: Carl <[e-mail]>
Subject: MS-Kermit V2.32/A Tek4010 Emulation
Keywords: MS-DOS Kermit Tektronix Emulation

I have just recently upgraded my copy of MS-Kermit (IBM-PC Kermit-MS: V2.30
8 Jan 1988) to IBM-PC Kermit-MS: V2.32/A 21 Jan 1989.  The PC Backspace key
behaves differently in the Tektronix 4010 emulation mode for these two
versions.  In MS-Kermit 2.30 Tek4010 emulation the BS key echoes a backspace,
space, backspace, i.e., the character sequence detected with debug set to on
is the following enclosed in brackets: [^H ^H].  The result is the expected;
the character just to the left of the cursor position is deleted from the
IBM-PC CRT and the "invisible" cursor is moved one position to the left.
Tek4010 emulation under MS-Kermit 2.32/A reports the same response to the BS
keystrike; however, the result is different.  The cursor is moved one position
to the left but the character is not deleted from the CRT.  A subsequent
keystrike on the PC keyboard overwrites the previous character, i.e., both
characters are displayed at the same position.  Both versions of MS-Kermit
behave the same on (1) IBM-PC/AT with EGA monitor and PC-DOS 3.2, and (2)
Compaq Deskpro 386/25 with a Mono VGA monitor and MS-DOS 3.3.  I have looked
over the MS-Kermit manual, "MS-DOS Kermit User Guide...", Jan 24, 1989 without
locating a method to make MS-Kermit 2.32/A delete the character on the CRT.
Is there a way to do this?

[From jrd - Yes, the BS key does behave differently, due to many comments by
dedicated Tek users.  Thus, in MSK 2.32 there is no destructive backspace.
There's hope, however.  The next release is likely to have a number of
enhancements to Tek mode, desct.  BS among them. As you know, a real Tek 4010
has no erasure capability whatsoever, being storage tube technology.]

------------------

Date:  Thu, 6 Apr 89 13:10:50 -0500
From: [e-mail] (Brendan B. Boerner)
Subject: MS-Kermit Flow Control Problem
Keywords: Flow Control, MS-DOS Kermit Flow Control

Hello, I would like to comment upon the issue of flow control in MS-Kermit and
MacKermit and how it could be mistaken for a bug.

Consider this scenario: A user is using Kermit and the remote computer sends a
^S.  The user continues typing.  At this point, if the user were to try to do
*anything* including using ^]c (on MS-Kermit) or use the menus (on MacKermit),
_nothing will happen_.  In order to proceed either a) the remote computer
needs to send a ^Q, or b) the user will have to reboot.  Note that the user
must type something after receiving the ^S in order for the computer to appear
to "lock up".  If the ^S arrives, and the user tries to use ^]c or the menus,
before typing something, these actions will succeed.  It is only after trying
to type a character that this problem appears.

The reason why this could be construed as a bug is that the occasional burst
of line noise could conceivably "trick" Kermit into thinking that it received
a ^S.  The user will probably never know that a ^S has been received and will
probably issue a command to redraw the screen and continue.  Now the user has
problems.  Kermit will be waiting for a ^Q to arrive and until then, the user
is locked out.  For the longest time, while trying to figure out what was
causing my IBM PC or Mac to lock up when using Kermit, I thought that this was
a bug.  It was not until after I traced down to the ASCII 19 character (^S) as
being the culprit that I realized that this was possibly a flow control
problem.

Is there any solution for this?  It would be nice if, upon realizing that a
stray ^S was received, the user could issue some command which would tell
Kermit to forget about that ^S.  This would presume that Kermit would still
allow menus or other commands to be used after the user has typed characters.

Thank you,
Brendan B. Boerner
Microcomputer Services
The University of Texas @ Austin
Internet: [e-mail]    UUCP: ...!cs.utexas.edu!ut-emx!boerner
BITNET:   [e-mail]

[From jrd - MS Kermit has a timer to sense when it has waited long enough when
trying to send a character.  When the timer expires it breaks any Xoff
deadlock.  However, a character needs to be sent before the holdup can occur
in the first place.  As far as stray Control-S' are concerned, how is Kermit
to know which is a stray?  The wait is blissfully short, say 8 seconds or so
and can be reduced by SET SEND TIME (though beware that yields an 8-bit prefix
packet decoding problem, sigh).  It would be nice if the user could enter an
overriding Control-Q, but that means queueing (no pun) output text and
selecting ^Q as an express request; too complicated for most cases.  Single
threaded DOS and all that.  I'm afraid we're stuck with it.]

[From pwp -- Oh!, *that's* what my mysterious line noise lock up problem is.
Hmm.  On the Mac, here is what's happening: the keyboard output is done with
blocking (synchronous) writes to the serial driver.  Now the serial driver has
flow control turned on in both directions (probably should be an option), and
the remote computer has sent an Xoff, so the driver blocks waiting for an Xon.
Since it is a blocking write, the driver can't return until the write
succeeds, and since it can't return, Mac Kermit can't call GetNextEvent or
WaitNextEvent, so the whole Mac freezes up.  I've just done a bit of hacking
on the output routines, and come up with this: when interactive (i.e. not
running any protocol), either turn off input flow control (preferable), or
force an unlock on each character typed.  Input flow still needs to be obeyed
when doing the protocol, possibly with a timeout (so the machine doesn't lock
up when doing file IO either).  This will be fixed in the next release of Mac
Kermit.]

[Ed. - It would seem to make good sense to turn off host-to-terminal
flow-control during terminal emulation, so long as we really know that the
user is typing.  Obviously, we should continue to honor flow control in this
direction any time the PC or Mac is transmitting characters on its own, like
during packet protocol, script execution, and raw uploads.]

------------------------------

Date: Fri, 14 Apr 89 13:16:26 EDT
From: "John Cripe [phone]" <[e-mail]>
Subject: MS-Kermit with ProKey
Keywords: MS-DOS Kermit vs ProKey

One of the people here has reported a problem using PROKEY a TSR and Kermit.
He was running Kermit 2.31 1 JUL 88.  Has anyone else heard of any problems
with PROKEY or any other TSR packages?  I looked in the documentation of
2.32/A and did not see any bugs fixed that matched.  SIDEKICK, the only TSR I
have access to right now seemed to work without problem so it may only be
certain ones.  Any help would be appreciated.

[Ed. - By all accounts, MS-Kermit works fine, or CAN work fine, with ProKey.
>From personal experience we know Kermit works perfectly with SuperKey, a
similar product.  If anyone has special hints about ProKey, please pass them
along.]

------------------------------

Date: Thu, 9 Mar 89 23:30:23 EST
From: [e-mail] (vu tv 16643)
Subject: MS-Kermit Tektronix Emulation vs MCGA
Keywords: MS-DOS Kermit Tektronix Emulation, MCGA

Kermit is a great program!  I like its key mapping and Tektronix emulation
capabilities.  In fact, I abandoned ProcommPlus in favor of Kermit.  However,
I have one small problem with my graphics adapter.

I have an IBM PS/2 Model 25 with MCGA capable of displaying VGA mono (ie,
640x480 in 2 colors or Mode 17 indicated in Table 1-5 in the manual), but I
was never able to get it.  The auto sensing always gave me CGA 640x200 B/W,
and the command SET TERMINAL GRAPHICS VGA didn't help either.  Is there a way
for me to get VGA mono?

                                        - Thu V. Vu
                                        [e-mail]
                                        uunet!x102a!tvu

[From jrd - The MCGA mode is not really supported by MS Kermit, as you have
noted. I do not have a PS/2 to check these things, but the VGA implementation
on the Model 25 is not reporting itself in the EGA compatible form as being
capable of high resolution graphics. I need an IBM PS/2 VGA Tech Ref to pin
down all the details.]

------------------------------

Date: 22 Feb 89 16:17:00 EST
From: "Michael J. Porter" <[e-mail]>
Subject: Problem with MS-Kermit 2.32/A Scripts
Keywords: MS-DOS Kermit Scripts, IBM 7171, Protocol Converters

We are having a slight problem with Ms-Kermit 2.32 in conjunction with the IBM
7171 ASCII protocol converters.  A script of the form:

  INPUT 10 TERMINAL TYPE:
  OUTPUT vt100\13
  CONNECT

will usually fail.  Apparently the 7171 sends the VT100 setup escape sequences
so quickly that Kermit does not have a chance to get into connect mode and
process them.  You can see them echo on the screen briefly.  These setup
sequences do things like cause the keypad to go into application mode etc.

                                Thanks,

                                Mike Porter

[e-mail]

[From jrd - A common misconception is that scripts operate with the VT102
emulator active; the emulator is not active. The case at hand can be easily
managed by SET INPUT-ECHO OFF before the final OUTPUT command.  This tells
OUTPUT to not helpfully echo incoming material, thus leaving it in the serial
port buffer, ready to be read by CONNECT mode.  Thanks to Peter Jones,
<MAINT@UQAM>, for similar observations.]

------------------------------

Date: Wed, 05 Apr 89 10:16:45 LCL
From: Eric Job <[e-mail]>
Subject: Kermit-370 vs WallData Protocol Converters
Keywords: IBM 370 Kermit, Protocol Converters, WallData

We're trying to use Columbia's MS-Kermit 2.32/A and Kermit-CMS to upload and
download files to PCs.  Our problem is that we're using WallData Protocol
Converters, which don't appear on the list of supported protocol converters.
Has anyone ever had success with the WallData units, could anyone suggest some
directions or even give me a definitive answer as to the possibility /
imposibility of doing Kermit file transfers?  Thank you.  Please reply
directly to me.

Eric Job <[e-mail]>, [phone], BITNET TechRep
Networking/Systems Support, Office of Computer Services
Box 24,340-A, East Tennessee State University
Johnson City, TN  USA 37614-0002

[Ed. - It all depends on how the WallData protocol converter works.  First,
you should be using Kermit-370 4.1.  You should run through all of the
available SET CONTROLLER options: SERIES1, GRAPHICS, etc.  Maybe one of them
will work.  If not, either (a) the thing can't be made to work at all because
there's no way for the host to put it into and take it out of transparent
mode, or (b) it has some peculiar way of entering and exiting transparent mode
which has to be programmed into Kermit-370.  If you, or anyone, gets Kermit
working with this protocol converter (or determines that it's impossible),
please let us (and Eric) know so we can update our list.]

------------------------------

Date: Tue, 11 Apr 89 08:47:51 PDT
From: GEORGE WESTLUND <[e-mail]>
Subject: Questions about 370-Kermit and MacKermit
Keywords: IBM 370 Kermit, IBM 3174 Controller, Protocol Converters
Keywords: MacKermit 0.9(40)

I have two questions regarding KERMIT.

#1   Is there a version for IBM VM/CMS that will work through ASCII
     emulation ports on an IBM 3174 remote communications controller?
     If there is could you send me the version number so I can talk our
     systems people into upgrading.  If there is not, could you put me in
     touch with someone who might be upgrading the current version to
     handle it.  We desperately need this, but do not have the time or
     personnel to do it ourselves.

[From John Chandler -- This question has been raised before, but not
conclusively answered.  In other words, we don't even know yet whether
transparent communication is possible through a 3174.  If CALPOLY is desperate
enough, it should be simple enough to investigate the possibilities
thoroughly.  If it *is* possible, I can promise that a version of Kermit-370
can be made to handle the 3174 shortly after the arrival here of a description
of how to enter and leave transparent mode.  Without that description, there's
nothing I can do, and nobody has taken on the project as far as I know.]

#2   The 0.9(40) release of MacKermit doesn't like to launch by clicking
     on the saved settings files, either that or if there is a 0.9(36) version
     on the machine as well as 40, it starts it instead, even if the file
     was saved with 40.  This is a pain.  I hope someone has already
     started working on this one.  I'd appreciate any info.

[Ed. - This has also been reported by a couple other people.  We don't know
why this happens.  The obvious solution is to have only one version on the
disk.]

George Westlund, Academic Computing Services
Cal Poly State University, San Luis Obispo, CA

------------------------------

Date: Fri, 14 Apr 89 18:35:51 -0700
From: Alastair Milne <[e-mail]>
Subject: MacBinary for MacKermit?
Keywords: MacKermit 0.9(40), MacBinary

A problem that has arisen with the transfer of Mac archive files from Simtel20
leads me to wonder: would it be permissible to have the regular choice of
"text" or "binary" file type extended, in MacKermit's case, to include the
choice of "MacBinary"?  At present, this is a problem with using MacKermit,
because SIT files arriving from Simtel20 in otherwise perfect condition are
being written as TEXT type files in MacBinary form -- when MacBinary is
actually intended as a protocol to permit the receiving end to reconstruct the
file just as it was on the sending Mac.  (There is even provision for placing
its icon at its old position in the new folder, though I don't claim that
MacKermit need recognise that much).

It's true that MacKermit would probably not be able to tell when the remote
system was *not* sending a MacBinary file; but the same applies at present in
most cases between binary and ASCII, and the solution would probably also be
the same.

The only way at present actually to get the file you intended seems to be to
use another application, which recognises MacBinary, to complete the
reconstruction from the downloaded file.

What is the feeling about providing such a special option in MacKermit?

Alastair Milne, U.Calif. Irvine

[Ed. - Support for MacBinary transfers is planned for a future release of
MacKermit, but probably not the forthcoming release.]

------------------------------

Date: Fri, 17 Feb 89 17:58 EST
From: <[e-mail]>
Subject: Problem Kermit Running Under RSTS/E v7.2
Keywords: PDP-11 Kermit, RSTS/E
Xref: DEC PDP-11, See PDP-11

I recently installed Kermit under RSTS/E v7.2 and it seems to work fairly
well.  Sometimes it will take the file KERMIT:KERMIT.INI when it starts
running and sometimes it won't.  Sometimes when I issue the command TAKE
KERMIT.INI (with this file in my own account) it says ER$FLK FILE IS LOCKED BY
OTHER USER.  It gives the same error sometimes when I try to issue remote
commands from a micro such as remote dir.  Is this something I can fix or is
this just one of the drawbacks that I have read about that I have to put up
with while running under 7.2?

Terry Lewis
TLEWIS@UTKVX  (bitnet)

[From Brian Nelson - This is correct. The problem is a function of the job
number being odd or even (honest).  Kermit-11 uses RMS11 v2, 7.2 uses RMS11
1.8.  RMS11 V2 uses an exec EMT that returns garbage in some field under 7.2.]

[Ed. - Also, expect a new release of PDP-11 Kermit soon which corrects a
couple minor problems (not this one).  In particular, the RT-11 version will
slightly inflate the file size sent to it in an attribute packet from another
system, so that it can preallocate enough disk space for the file, even after
expansion of (for example) linefeeds into CRLFs.]

------------------------------

Date: Sun, 12 Mar 89 03:22:57 EST
From: Mark W. Eichin <[e-mail]>
Subject: Bug report, CP/M kermit (and other notes)
Keywords: CP/M Kermit, TurboDos

The latest kermit from ~ftp/kermit/a/cp[sx]*.asm has a minor (but
visible) bug. In cpspk2.asm, line 341 is

        mvi     a,'$'           ; dollar terminate string
        call    prtstr

(these are after the label gofi7g.)

The problem is that the '$' has to be actually moved into the string
to terminate it. Adding the line

        stax    d

between the above two solves the problem.

The bug manifests itself when doing a "receive": as soon as the remote host
sends the filename, it gets displayed on the local screen, followed by
arbitrarily large amounts of garbage (whatever code followed the filename
buffer up to the first '$', which for me tended to be about 4-5 lines of
garbage...)

[Ed. - Thanks for the fix.  It has been added to the .BWR file.]

On a related note: I have successfully ported kermit to TurboDOS (a CP/M-like
operating system written by Software 2000) so that it uses the "T-functions",
a set of standard extensions to CP/M, particularly a set of generic serial
routines. I have only tested it on my personal system, a custom port of
TurboDOS to the Radio Shack Model 4P, but it is likely to work on any TurboDOS
system. Are you interested in adding this to your collection? Are there any
stylistic constraints you require on submitted code? (I would like to see it
included, if only because there have been "people working on" TurboDOS
versions, according to your list, for at least 4 years now.)

Also, I have patches to the Simtel20 PD2:<UNIX-C.CPM>XASM.SHAR[12], an 8080
assembler which runs under UNIX, which add a LINK command, that enables it to
assemble the entire CP/M Kermit release. I will be submitting them to the
Simtel20 people, but I can send them to you as well if you are interested.

[Ed. - Yes, please send all source code either via e-mail, if the files are
small enough or on an IBM PC compatible diskette so we can add the files to
the Kermit Distribution area.]

Thanks for providing such a good *FREE* system!

                                Mark Eichin
                                <[e-mail]>

------------------------------

Date: Wed, 05 Apr 89 10:02:08 -0400
From: [e-mail]
Subject: Kermit on Northstar Horizon?
Keywords: CP/M Kermit, Northstar Horizon

Has anyone on the list successfully installed Kermit on a Northstar Horizon
running CP/M?  I have had the same trouble with both the pre- assembled
objects and locally-assembled source.  Most of it works, except that when the
host (or a terminal attached to the port) sends a character, a "D" is sent
back to the host.  Characters typed on the Northstar go out to the host
correctly.  Study of the source reveals nothing.  Has anybody else seen this
behavior?  Has this happened on other machines?  I'm running CP/M 2.23/A, by
the way, with the two built-in serial ports.

Jim Gonzalez                            AT&T: 617-873-2937
BBN Systems and Technologies Corp.      ARPA: [e-mail]
Cambridge, Massachusetts                UUCP: ...seismo!bbn!gonzalez

------------------------------

From: munnari!yarra.oz.au![e-mail] (Charles Meo)
Subject: Kermit on Archives 2 Z80 Box
Date: 6 Apr 89 00:37:11 GMT
Organization: Pyramid Technology Australia, Melbourne
Keywords: CP/M Kermit, Archives 2 Z80

I have recently purchased (for $A100) an archives 2 cpm machine to use as a
terminal from home. This beastie works fine with generic kermit but I don't
have any documentation about the screen control codes so I can set up an
emulation for it. I need this to make life on the pyramid a bit more pleasant
when I log in.

Does anyone have any info on this box? Archives Computers don't seem to be in
business anymore in this country, so I can't ask them!  If anyone knows how
the SIO is mapped, that would be great too.  Mail me if you can help out at
all. Thanks in advance!

chuck

ps BTW this thing sold for $6k+ when it was new just 8 years ago! Moral:
digital technology has made resale value a thing of the past.

------------------------------

End of Info-Kermit Digest
*************************

10-May-89 21:17:15-GMT,24379;000000000001
Return-Path: <[e-mail]>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
    id AA15195; Wed, 10 May 89 17:17:10 EDT
Received: from watsun.cc.columbia.edu by cunixc.cc.columbia.edu (5.54/5.10) id AA18336; Wed, 10 May 89 17:15:43 EDT
Received: by watsun.cc.columbia.edu (4.0/SMI-4.0)
    id AA15012; Wed, 10 May 89 17:08:20 EDT
Date: Wed, 10 May 1989 17:08:18 EDT
From: Christine M Gianone <[e-mail]>
To: [e-mail]
Subject: Info-Kermit Digest V9 #8
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Wed, 10 May 1989        Volume 9 : Number 8

Special MS-DOS Kermit Issue:

               MS-Kermit 2.32/A for NEC-PC9801
            MS-Kermit and Novell Networks
            MS Kermit 2.32A vs Novell Disk Server
        MS-Kermit Scripts for DDN TAC and PCBoard BBS
         MS-Kermit 2.32A Image Ghosting on IBM PS/2 Monitors
          MS-Kermit Dropping Characters w/ Accelerator Cards
               MS-DOS Kermit 2.32/A Server Bug
           MS-DOS Kermit 2.32/A & AE PC Transporter
               MS-DOS Kermit 132 Column Support
            MS Kermit Scripting Questions

Send digest submissions to [e-mail], requests for
addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or 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.
Login as user anonymous (note, lower case), 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 kermit/a/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: Tue, 25 Apr 89 23:18:15 JST
From: Hirofumi Fujii <[e-mail]>
Subject: MS-Kermit 2.32/A for NEC-PC9801
Keywords: Japanese, NEC PC 9801, Kanji/Kana, MS-DOS Kermit 2.32/A

Dear Chris & Frank,

I would like to send you a new version of NEC-PC9801 MS-Kermit 2.32/A.  Please
replace the MS*P98 modules in your library.  The new features of this program
are:

1. SET TERMINAL COOKED-LOG {ON | OFF}

 If it is ON, the session logging is made after the analysis of ESC sequences.
 In VT102 emulation mode, this means that the receiving characters are
 translated from JIS X 0202 (ISO 2022) stream to local code, i.e., Kanji-code
 in JIS X 0202 stream is logged in Shift-JIS (MS-Kanji) code.
 All the control codes except for CR, LF, HT and VT are not logged.
 The ESC sequences except for cursor movement are eliminated.  The ESC sequence
 for the cursor movement is logged as CR LF. This is quite convenient for text
 files.

 If it is OFF, the session logging is made before terminal emulation.
 No translation is made on the receiving codes.

2. SET PORT DEVICE device/file-name

 This command allows you to use the standard MS-DOS devices/files as
 a communication port.  If it is a file, the contents of the file are displayed
 on the screen of the terminal emulator.  This can be used to playback the
 session log file.  Any key-input holds the strem from the file.

In addition to the above, many missing functions in the previous version
are implemented, e.g., screen colors, screen roll back capabilities, etc.

Hirofumi Fujii
National Laboratory for High Energy Physics (KEK), Japan
[e-mail]

[Ed. - Many thanks for the fine work, and for submitting this program to
us.  The two new features are quite useful, and will probably also appear
in a future standard release of MS-Kermit.  For those who don't know, the
NEC PC 9801 is the most popular personal computer in Japan, and supports
a combination of Roman, Kana, and Kanji codes.  This version of Kermit
fully supports the character set capabilities of this machine.]

------------------------------

Date: Wed, 08 Mar 89 15:15 EST
From: Jim Gogan <[e-mail]>
Subject: MS-Kermit and Novell Networks
Keywords: MS-DOS Kermit Network Support, Novell, Interlan, Ungermann-Bass

Don't know how many people are aware of the following, but ...

MS-Kermit 2.31/2.32/2.32a (any newer?) works very nicely as the end-user
communications software package on a local area network with:

  - Novell's Netware Asynchronous Communications Server (NACS)
     (not the original one, but, I think, version 2 - the one
      originally developed by Network Products Corp - check
      the copyright notice on your disk);

  - Network Products Corp.'s (NPC, hereafter) ACS-2 (an enhanced
     version of the above); and,

  - NPC's Network Modem Program - a nice, relatively inexpensive
     ($195 + modem) way to share a workstation's modem
     across a Novell network.

The key ingredient of all the above is the use of NPC's NCSI (Network
Communications Services Interface), what Novell (sometimes) refers to as
NASI.  NCSI provides the DOS-based communications software applications the
access mechanism to the async server (or modem sharing) product.  Lo and
behold, it turns out the the basic functions of NCSI (which include
writing/reading to/from a virtual circuit, issuing a control request - e.g.
transmitting a break, checking for a break, and disconnecting) are
compatible with an interface from Ungermann-Bass called NETCI (gee, almost
sounds the same...).

Anyway, if you are using any of the above products for async comm resource
sharing on a PC LAN, if you include the command "set port ub-net1" in the
MSKERMIT.INI file at the end-user's PC, MS-Kermit works quite well with
these programs.  It works regardless of the network hardware you're using
(i.e., you DON'T have to be using Ungermann-Bass hardware for this to work);
just so long as the async server product uses NPC's NCSI to talk to the
communications software.

Sure beats paying for the network versions of ASCOM IV or Crosstalk - "free"
has such a nice ring to it!  Plus, you get the added features of key
remapping and Tektronix 4010 emulation, among others.

While we're on the subject .....  With the Interlan TCP/IP Gateway for
Novell networks, it is also possible to use MS-Kermit (same versions as
above) for your communication software via telnet.  Since Interlan was so
kind as to provide an Interrupt 14 hook for their telnet implementation, all
one needs to do is include "set port bios1" in their MSKERMIT.INI file and
invoke Interlan's telnet command with "telnet [internet node] mskermit" from
the DOS prompt.  Works just fine also - again, gives you Tektronix 4010
emulation capability over TCP/IP at no charge (well, except for the Interlan
gateway product).

This use of MS-Kermit gives us the advantage of being able to support one
communications package from the end-user's point of view, regardless of how
they're getting out - dial out/standalone, dial out/network with shared
modem, dial out or direct connect/network with async server, or TCP/IP
gateway.  (Of course, there's still the SNA Gateways, but that's another
story!)

If anyone has any specific questions about implementing the above, feel free
to send mail to [e-mail] (or [e-mail] for you
internet'ers).

-- Jim Gogan
   Microcomputing Support Center
   Univ. of North Carolina - Chapel Hill

[From jrd - Thanks Jim for pointing out all the Novell related items. I've
promised Novell to provide support for their systems, but I have not been
able to obtain their async server software for real testing (Novell has been
very generous to me on non-Kermit things) although I have the tech ref.
Serial port interception is one of the purposes of command SET PORT BIOSn.]

------------------------------

Date: Wed, 08 Mar 89 15:15
From: Dermot O'Beirne <DOBEIRNE@IRLEARN>
Subject: MS Kermit 2.32A vs Novell Disk Server
Keywords: MS-DOS Kermit Network Support, Novell

I have just received a very recent version of MSVIBM (Kermit 2.32A dated Jan
1989) and thanks to Joe Doupnik and all for the great work. The problem I have
is one that has persisted with every version since the disk-space checking was
thankfully introduced. Every time I want to do a transfer with attribute
checking on MS-Kermit checks to see if there is enough space on my A disk if I
have set default to a Novell Netware mapped drive. So if I dont have a disk in
my A drive then the transfer aborts. Why does it not check the Novell drive
where there is lots of space? The Novell version is advanced 2.12 and there is
nothing special in my environment except that COMSPEC is C:COMMAND.COM because
I boot up from my C disk.

Any suggestions? Is this a bug or feature?
Thanks,

Dermot O'Beirne
Systems Programmer
Computer Centre
UCD, Dublin

[from jrd - 2.32/A should be ok. I wonder if we are seeing a side effect of
Novell's drive MAPping. I don't recall that happening on my Netware 2.12 w/TTS
system, but I'll probe more to be sure. It too has command.com located on
drive c: (a ram disk). Readers may be interested to note that Dermot was the
first to discover problems of losing serial port characters while printing
across a network, and I introduced printer buffering within Kermit to solve
that problem at Univ College, Dublin.]

------------------------------

Date: Saturday, 11 March 1989  21:20-MST
From: Alan Ariel <[e-mail]>
Subject: MS-Kermit Scripts for DDN TAC and PCBoard BBS
Keywords: MS-DOS Kermit Scripts, TAC
Xref: DDN TAC, See TAC

I've uploaded PD1:<MSDOS.KERMIT>PCBDKER.ARC to SIMTEL20.  It is a collection
of scripts I use with MSKermit for DDN access through a TAC and BBSing with
PCBoard BBSs.  I've been impressed with the number of things I can do with
MSKermit that I only though I could do with PROCOMM or QMODEM.

I hope the scripts might let someone else discover the things they could do
with it.  I was first led to it when I learned I could remap keys to
whatever I wanted and use 43 line mode on my EGA for my comms.  The 43 line
mode is great if you're trying to look at a large file or a lot of messages
at once.  I use DSZ for my normal BBS transfers and of course Kermit for
PC-Mainframe stuff.  I'm really happy with it.

Alan D. Ariel                               BITNET: 1052P@NAVPGS
LT        USN                               DDN:    [e-mail]
SMC 1624                                    (or)    [e-mail]
Naval Postgraduate School                   Tel:    [phone]
Monterey, CA 93943                          AV:     878-2786

[From jrd - Thanks Alan.  Much appreciated!]

------------------------------

Date: Thu, 09 Mar 89 18:59:00 EST
From: Kanthan Pillay <[e-mail]>
Subject: MS-Kermit 2.32A Image Ghosting on IBM PS/2 Monitors
Keywords: MS-DOS Kermit VT102 Emulation, IBM 7171

We are running MS-Kermit 2.32A connected to our IBM3081 mainframe through
a 7171 protocol converter. There is a cosmetic problem that has arisen that
is not present in 2.31. When the screen is cleared on a PS2 monitor (any
flavour) using the clear sequence Esc-OM, the VM READ/RUNNING line from the
lower right hand corner of the screen moves briefly to the upper right hand
corner before disappearing. It is only a cosmetic problem but can be
disturbing. Any fixes?
                                           Kanthan Pillay
                                           Princeton University
                                           Computing and Information Technology

P.S. The documentation in PostScript format is excellent. Thank you to all who
put it together.

[From jrd - That's Kermit rolling the current screen into the roll back
buffer whenever the entire screen is cleared.  The status VM READ/RUNNING
could be cleared by the host before the screen, but that's asking a lot of
the systems software. The clearing escape sequences are of the ESC [ ... J / K
form and ESC [ .. M means delete lines at and below the cursor line. Clearing
is much faster than multiple deletes, by far.  Any chance of telling the host
to use formal ESC [ .. J codes?  Columbia gets the kudos for Postscript.]

------------------------------

Date: Mon, 27 Mar 89 10:15:59 MST
From: Doug Baldwin <[e-mail]>
Subject: MS-Kermit Dropping Characters w/ Accelerator Cards
Keywords: MS-DOS Kermit vs Intel Accelerator Card, Intel Accelerator Card

We have recently come across a problem using accelerator cards with Kermit-MS
version 2.32/A.  In PC's with the Intel Inboard accelerator card, running
Kermit-MS 2.32/A, we lose characters during a 9600 bps terminal session when
Kermit is in VT102 emulation mode.  However, when we switch to Tektronix mode,
we don't lose characters.  We also discovered the same to be true with version
2.30.  Kermit-MS version 2.29b works fine in VT102 mode with the accelerator
board installed.

Do you have any idea what the difference is between VT102 & Tek mode, or why
version 2.29b works and 2.30+ doesn't.  Are you handling things differently
at the register level?  Bigger buffers in Tektronix mode?  More processing
required in VT102 mode?  Do you have any suggestions (patches) that will
resolve this problem?  Any information will be welcome... Thanks.

--Doug Baldwin
  Microcomputing & Communications Services
  Computing Services Customer Support
  Arizona State University  [phone]

[From jrd - I'm guessing that video screen scrolling in the Bios is being done
very slowly and interrupts are kept off too long during the process.  Tek mode
does not scroll the screen, hence no problem.  Scrolling under 2.32 is done in
segments to be compatible with MS Windows and that can yield two scrolling
calls on the Bios (hence more exposure to the above side effects).  I have
heard a similar complaint about losing characters when the Intel board tries
to communicate and suggested the individual contact Intel for any known cures.
Things are vastly different inside MS Kermit after 2.29.]

------------------------------

Date: 9 Feb 89 09:09
From: [e-mail]
Subject: MS-DOS Kermit 2.32/A Server Bug
Keywords: MS-DOS Kermit Bugs

There seems to be a bug in SERVER mode, with Kermit-MS for the IBM-PC
(MSVIBM), version 2.32/A (21 Jan 1989).  The Kermit running in SERVER mode, is
unable to receive a file, sent to it via the SEND command from the other
machine, if the destination directory is a root directory.

This works fine if the default directory on the machine in SERVER mode, is
a subdirectory.  It also works OK using root directories, with either the
GET command, or the SEND/RECEIVE combination (not in SERVER mode).

- Andy Ingraham  ([e-mail])

[From jrd - A known bug, which will be fixed in next release.]

------------------------------

Date:  Tue, 4 Apr 89 15:06 EDT
From: [e-mail]
Subject: MS-DOS Kermit 2.32/A & AE PC Transporter
Keywords: MS-DOS Kermit on Apple IIgs With PC Transporter, Apple II

Warning, this is an arcane problem.

>From time to time I use an Applied Engineering PC Transporter on an Apple
IIGS with PC kermit.  The specs for the PC Transporter say it has a V-30
microprocessor running at 4.17 MHZ, a CGA-compatible video controller and
640K dual-port RAM.

On the Apple side, for historical reasons I'm still using a SSC and have no
problems when I use Apple kermit.

I have no problems using pc-kermit 2.29.  When I moved up to 2.31 and later
2.32A I find I lose characters at 2400 baud.  The character loss occurs only
when a terminal is being emulated (not when term is set to "none") and when
the screen starts to scroll.  It doesn't help to not install ANSI.SYS or a
mouse driver that are normally there (I don't know if that steals many cycles
or not) and to set display quiet or serial.  Protocol transfers work fine --
I've transferred many a large file (100k or more) using 1000 byte packets with
nary even a single retransmission.  (phone lines here are generally very
clean.)

Applied Engineering had an upgrade to their software that was claimed to speed
up something in its using the Apple communications hardware to emulate the IBM
serial ports. I have installed that (and I seem to remember that is what made
2.29 usable.)

Suggestions anyone???

[e-mail]

[From jrd - The emulator of screen Bios calls must be both slow and keeps
interrupts off for too long.  This would not be unusual for hybrid emulator
boards because of the traffic passing through a small path (say an 8 bit port
or memory location) between cpus and the work to emulate on a different
system.  Scrolling is one of the slowest things video systems perform and
something is not able to attend to the serial port in the meanwhile.  My Atari
800 + 8088 DOS board could run to 9600 baud with a purely software UART using
MS-Kermit on the DOS side (farthest from the "serial port").  The regular
Atari 800 Kermit, however, ran out of steam at 4800 baud.]

------------------------------

Date: 15 Feb 89 12:39:00 PST
From: "SD::HURLEY" <[e-mail]>
Subject: MS-DOS Kermit 132 Column Support
Keywords: MS-DOS Kermit VT102 Emulation

I have been enjoying Kermit-MS at work using the Compaq 286 with a VGA
monitor.  I want to mention that I hope that you somehow are able to enlarge
the support for VGA monitors using the VT102 terminal emulator to include
132 column emulation.  The DEC VAX which I talk to frequently has several of
these screens to explain the keyboard, and Kermit-MS does not recognize
them.  What happens is that the right edge of the screen is lost.  The only
progam that I know of which recognizes the 132 column screen of our VAX is
"Call", which is an Air Force program and is used extensively at the U.S.
Air Force Base (Space Division) in El Segundo, California.  There are
several people here trying out Kermit-MS, and I know that they would be
pleased if this glitch were fixed.

I am sorry to report that at home, using my XT-clone (no name), Kermit-MS
has some rather serious problems.  I can run Kermit-MS, but when I go to
VT102 terminal emulation using the CONNECT command, I cannot get the modem
to respond.  When I type ATZ, the "echo back" is very slow, and I never
receive the customary "OK" response from the modem.  This set up, which is
described fully in the next paragraph, works with Smartcom II ver. 2.2, and
with Smartcom III ver. 1.0B.  These are the two tests for compatibility
which are normally applied.  So, I conclude that there is something about
Kermit-MS which is preventing it from working with my XT-clone.  I have
checked all the normal things ...  I am running at 1200 baud which is the
proper speed for the modem, and I am using COM2 which is the correct serial
port.  Just to be sure that I was not running interference from a TSR, I
booted from a master DOS disk (ver.  3.2), and then ran Kermit-MS.  Still,
the result was the same.

I hope you can find a fix.  There are a lot of other XT-clone people out
there, and I am sure that they will have problems too.  By the way, I am
using a DTK ver. 2.27 bios chip (piggybacked on top of a Smartwatch chip for
the clock), a 640K clone motherboard, an Omnitel PC3 modem (1200 baud), a
Paradise Plus VGA video board (8bit), an Above Board/PS with 2 MB of RAM,
and a Copy II PC Deluxe Option board.  I have a multifunction board which
contains a floppy disk controller controlling two floppy disks, a parallel
printer port, a, serial port which is connected to a Mouse Systems mouse,
and a joystick port.  I have a hard disk controller by Western Digital, and
it controls a 20 MB hard disk by Seagate, Model ST225.  So, this fairly
describes my setup.

I surely hope you can help.

[From jrd - There is no "standard" way of invoking 132 column mode on
EGA/VGA boards. Each manufacturer has invented a private method, and I lack
access to and information on what most have done.  Kermit requires a solid
signature to identify the board safely and the incantations to change modes
to and from 132 columns.  MS Kermit does support a handful of popular
EGA/VGA boards.  A simple workaround for unknown systems is to use the
manufacturer's utility to set 132 columns and then run Kermit.

By the way, Smartcom II and PCTALK III have a deficiency inherited from old
MS Compiled Basic that the serial port interrupt vector is stolen by the
Basic program and not returned properly, leading to eventual crashes.  From
your description of the modem echoing I surmize that there are serious
hardware conflicts in the system, typically involving IRQ 3 (COM2), its port
addressing, and perhaps other items.  The slow "echo back" is from the
modem, clearly, so it too may be experiencing conflicts.  One place to look
is that Paradise VGA board and it's 8 vs 16 bit modes; I've experienced
troubles with a loaner, and with the Professional.  Pulling boards is not
much fun, but may be the quickest way to pinpoint the cause.]

------------------------------

Date: Tue, 28 Feb 89 22:59:36 -0800
From: [e-mail] (Eric C. Hewitt)
Subject: MS Kermit Scripting Questions

I am submitting this for someone else because the questions are beyond my
technical knowledge of Kermit.

                -Eric Hewitt
                UCSC Computer Center Consulting
                [e-mail]
                [e-mail]

P.S. - He does not have 2.32/A yet.

Hi.  I'm using Kermit 2.32 now.  It works better than 2.31 but I'm still
having problems, mainly with lost characters.

Kermit loses characters from the serial port when it isn't in connect mode.
It seems especially bad when it's waiting for input for the "input" command,
and is also worst when it is a message from the modem.  But it also occurs in
other situation.  Unfortunately the loss of characters causes the most
problems when waiting for input to "input" that is a response from the modem,
because I want to test for whether it is CONNECT 2400, etc.  At the same time
that input is lost the speaker usually beeps.

Oddly enough, it isn't nearly as bad when I have take-echo set to "on".  I'd
think that if anything having to echo script commands would slow down the
program's resonse to the modem.  Anyway, I would much rather have take-echo
set off, but I can't while this happens.  Has anyone else noted this behavior?

Also, when I am at the kermit command level, or when kermit is suspended
because I've pushed to DOS or run a program, any data coming in the serial
port is lost.  This doesn't happen with Crosstalk; a lot of input can arrive
while Crosstalk is suspended and it will appear when it is restarted.  Is
kermit supposed to behave this way?  It is a serious problem for me since I
often suspend kermit to run other things on my system while I'm logged on, but
if I get a write message or something I will never know it.  Kermit sends a ^S
when it is suspended, apparently in an attempt to forestall output, but that
isn't good enough.

Finally, is there a copy of the 2.32 manual online or on a drive
somewhere?  Thanks.

    John DuBois

[From jrd - The MS Kermit User's Manual is file MSKERM.DOC, available on
Kermsrv (Bitnet) or anonymous ftp to cunixc.cc.columbia.edu.  MS Kermit does
not continue to operate the serial port when one Pushes to DOS, for the very
good reason that the next program may also use the same port.  If Control-S
does not stop the host then you need to run MS Windows or Concurrent DOS or
DESQview or similar environments to achieve a semblence of multitasking.
MS Kermit does not run in DOS background since there is really No$Such_Thing.
Kermit does not lose characters while processing the INPUT command unless
your system is imposing a very heavy load in the background (TSRs, PRINT
command, etc).  If you snatch a copy of 2.32/A, and the manual, there are
examples of scripts which do autobaud recognition of modem CONNECT responses.]

------------------------------

End of Info-Kermit Digest
*************************

14-Jun-89  2:03:31-GMT,26075;000000000001
Return-Path: <[e-mail]>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
    id AA18167; Tue, 13 Jun 89 22:03:27 EDT
Received: from watsun.cc.columbia.edu by cunixc.cc.columbia.edu (5.54/5.10) id AA01718; Tue, 13 Jun 89 22:02:38 EDT
Received: by watsun.cc.columbia.edu (4.0/SMI-4.0)
    id AA17906; Tue, 13 Jun 89 21:58:25 EDT
Date: Tue, 13 Jun 1989 21:58:24 EDT
From: Frank da Cruz <[e-mail]>
To: [e-mail]
Subject: Info-Kermit Digest V9 #9
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Tue, 13 Jun 1989         Volume 9 : Number 9

Departments:

  NEWS -
        Kermit Conference Report
        New Kermit Discussion List in Japan

  ANNOUNCEMENTS -
        Announcing MVS/TSO Kermit 4.1.001
        Announcing TSO Kermit 4.1.002
        Announcing CMS Kermit 4.1.001
        New Release of Kermit-11 for the DEC PDP-11
        Announcing Kermit for the Honeywell DPS-6
        Announcing Version 2.9 of Apollo Pascal Kermit
        Announcing GEC/OS4000 Kermit Version 3.9

  MISCELLANY -
        HP-9000 Kermit Bootstraping Methods
        Using Kermit on Ethernet?
        Mixing Things in MS-Kermit Key Definitions?
        Kermit-370 Through 3174 AEA?
        C64-Kermit Problem

Send digest submissions to [e-mail], requests for
addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN, WATSUN.CC.COLUMBIA.EDU, a
SUN-4/280 running UNIX (SUNOS 4.0), IP host number 128.59,39.2, or to CUNIXC,
CUNIXC.CC.COLUMBIA.EDU, a VAX 8700 running UNIX (Ultrix), IP host number
128.59.40.130.  Login as user anonymous (note, lower case), any password, and
GET or MGET 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
kermit/a/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, 8 Jun 1989 16:37:14 EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit Conference Report
Keywords: Conference, Kermit Conference, International Kermit Conference
Keywords: Moscow, USSR, International Character Sets

Apologies for the long hiatus in Kermit digests.  Christine Gianone and I
spent the last several weeks preparing for and then attending the First
International Kermit Conference, held in Moscow, USSR, May 29-31.  This
conference, sponsored by the International Centre for Scientific and Technical
Information (ICSTI) in Moscow, was attended by more than 70 computer
specialists from the USSR, Hungary, East Germany, Cuba, Mongolia, Bulgaria,
Poland, and Czechoslovakia.  Many of the conference attendees were active
Kermit program developers, working on Soviet and Eastern European computers.

The first two days were devoted to our presentation of Kermit's history,
philosophy, use, programming, protocol, and performance, with translation
between English and Russian for the lecture and question-and-answer sessions.

On the third day, Chris presented our proposed extension to the Kermit
protocol to allow transfer of text files in diverse character sets (including,
of course, Cyrillic) which was of great interest to this international
audience.  The basic ideas of the proposal were warmly endorsed in the
discussion which followed.  A third draft will appear soon, which will reflect
points raised in this discussion and others from the isokermit e-mail
conference.

There were also presentations from conference attendees, discussing their
adaptations of Kermit for Soviet and other Eastern European computers, and
some of the uses to which they had put these programs.  Perhaps the most
interesting described how Kermit was used in Soviet secondary school CAI labs
-- 250,000 PCs are being manufactured and delivered to Soviet secondary
schools as part of the current five-year plan, and each of them has Kermit in
ROM.

Chris presented ICSTI with a complete, up-to-date set of Kermit programs and
documentation on magnetic tape and diskette.  ICSTI in Moscow will join other
regional Kermit Distribution centers that have been set up around the world --
in England, Ireland, France, The Netherlands, Japan, Australia, etc.  ICSTI's
Kermit Distribution will serve the Soviet Union and other Eastern-block
countries, and ICSTI will become a center for coordinating Kermit program
development in those countries.  ICSTI presented Columbia with a version of
Kermit it had developed for IBM's CICS MVS subsystem and with a set of
Cyrillic fonts for the HP Laserjet.  The CICS support code has been sent to
John Chandler (see below) in hopes that it can be adapted to Kermit-370.

Our special thanks to Dr. Juri Gornostaev, Head of ICSTI's Computer
Department, and Professor A. Butrimenko, Director of ICSTI, for sponsoring the
first international conference devoted entirely to Kermit, and for their warm
and generous hospitality.  And thanks also to Juri and the "Kermit Gang" at
ICSTI -- especially Mischa, Andrei, Kostya, Marina, and Shamil -- for
befriending us and giving us an "insider's view" of the Soviet Union.

A more complete report of the Kermit conference will appear in the next (4th)
issue of Kermit News.  If you're not already a subscriber, send e-mail to the
Info-Kermit-Request address (or paper mail to the postal address) listed
above, requesting a subscription.

Meanwhile, new Kermit contributions have been pouring in.  Some of them are
announced below (MVS/TSO Kermit 4.1.002, VM/CMS Kermit 4.1.001, PDP-11 Kermit
3.60, Honeywell DPS-6 Kermit, and Apollo Pascal Kermit 3.9, GEC OS4000 Kermit
3.9.  Others will be announced in forthcoming Kermit digests, including OS/2
C-Kermit (complete with source code) and new releases of HP-9000 BASIC Kermit
and Microsoft Windows Kermit.

------------------------------

Date: Tue, 02 May 89 13:58:22 JST
From: Masamichi Ute <[e-mail]>
Subject: New Kermit Discussion List in Japan
Keywords: Japan, LISTSERV

I am a postmaster at the Science University of Tokyo, Noda campus (JPNSUT30)
in Japan.  Many thanks for your Kermit service and Kermit on many computers.
I have a report and a few questions for now.

1. I opened a Kermit discussion list (KERMIT-L) for BITNET users in Japan on
our LISTSERV.  I would like to introduce Kermit on any computers and exchange
usage and questions and so on.  We exchage a mail using the Japanese language
on KERMIT-L.

2. I would like to register Kermit programs by file server facility on our
LISTSERV:

 * MSVP98 for NEC PC-9801
    I got a developer's consent from Hirofumi Fujii KEIBUN@JPNKEKVM.
 * IBM Mainframe's Kermit, VM/CMS, MVS/TSO and MUSIC/SP
 * C-Kermit for EWS

I would like to register the execution files for Kermit beginners. It is
KERMIT MODULE, KERMIT HELPCMS on VM/CMS, for example.  In this case, do I have
to register Kermit original files on KERMSRV?  Please let me me know the rules
to register a Kermit program.

Yours sincerely,

Masamichi Ute
[e-mail]
Postmaster of JPNSUT30

Information Processing Center
Noda campus
Science University of Tokyo
2641, Yamazaki
Noda, Chiba, 278
JAPAN

[Ed. - Ute-san, many thanks for setting up the Japanese Kermit discussion
group and file server!  This is a valuable service, and will help to ease
the congestion on the trans-pacific network links.  To answer your questions,
we normally do not put binary executable files on our Kermit file servers or
distribution tapes, for reasons of transportability.  Binary files are often
not compatible with e-mail or labeled magnetic tape formats.  In some cases,
we encode the binaries as printable characters -- HEX or BOO files.  We
encourage you to keep the source code along with the binaries so that people
who get these programs can make improvements, fix bugs, etc, and also so that
users can satisfy themselves that the programs contain no viruses.  Thanks
again for what you are doing!]

------------------------------

Date: Mon, 1989 May 8   12:07:11 EDT
From: "John F. Chandler" <[e-mail]>
Subject: Announcing MVS/TSO Kermit 4.1.001
Keywords: MVS/TSO Kermit, IBM 370 Kermit

I have sent new BWR, INS, and UPD files for IKTKER.  Starting with this
batch, I intend to make a new "sub-release" number each time a new update
comes out -- hence, 4.1.001 for TSO.  This number is displayed is the same
places 4.1 was formerly, so there should be less of a problem figuring out
exactly what version is involved in problem reports henceforth.  I had hoped
to get a 4.1.001 out for CMS about now also, but I'm still waiting for
reports on an update I hope has finally made GRAPHICS controllers work for
CMS Kermit.

                                        John

[Ed. - Many thanks, John!  IKTKER.UPD shows the changes, which include
improved VTAM TTY support, handling of implicit CLISTs, and improved handling
of host commands.  The three new files are in kermit/b on watsun and cunixc
for anonymous FTP access, and also available on BITNET/EARN from KERMSRV at
CUVMA.  Also, see next message.]

------------------------------

Date: Tue, 1989 Jun 6   20:19 EDT
From: "John F. Chandler"   <[e-mail]>
Subject: Announcing TSO Kermit 4.1.002
Keywords: MVS/TSO Kermit, IBM 370 Kermit

Release 4.1.001 contained a bug that interfered with the catalog scan for
SEND operations, so that a "File not found" error would result.  The fix:
SC89157 (see IKTKER.UPD).  4.1.002 is now the current release.

------------------------------

Date: Tue, 1989 Jun 13   15:57 EDT
From: "John F. Chandler"   <[e-mail]>
Subject: Announcing CMS Kermit 4.1.001
Keywords: VM/CMS Kermit, IBM 370 Kermit, CMS Kermit

I have sent new versions of IKCKER.UPD and IKCKER.BWR.  This marks the
transition of CMS Kermit to the "edit number" system, such that each new set
of changes released through Columbia will result in a change in the edit
number (the 001 in 4.1.001).  I will try to keep a correspondence among all
the variants of Kermit-370, so that generic additions will appear at roughly
the same edit number for each.  Thus, the 4.1.001 that appeared for TSO in
May had the same set of generic updates as the new CMS 4.1.001, but TSO's
4.1.002 issued last week has only a TSO-specific bug fix, and, hence, the
next version of CMS Kermit will presumably be 4.1.003.  For CMS, 4.1.001
marks a significant milestone -- for the first time, GRAPHICS controllers are
supported.  In particular, complete success has been reported for the PCI 276
and partial success for the Renex TMS-1.  The other major innovation is the
option of entering CMS filespecs as name.type.mode (with periods instead of
blanks as delimiters).
                                      John

[Ed. - Thanks once again, John.  The new files are installed in the regular
places: kermit/b/ikcker.upd and .bwr on cunixc and watsun for Internet
anonymous FTP access, and IKCKER UPD and IKCKER BWR for BITNET access via
KERMSRV at CUVMA.]

------------------------------

Date: Thu, 25 May 1989 21:02:37 EDT
From: Brian Nelson <[e-mail]>
Subject: New Release of Kermit-11 for the DEC PDP-11
Keywords: PDP-11 Kermit, DEC PDP-11, RSX-11, RSTS/E, RT-11

This is a minor new release of Kermit for the DEC PDP-11 and its various
operating systems -- RSX-11, RSTS/E, RT-11, P/OS, TSX+, etc.  The version
number is 3.60, and it replaces 3.58 (which was released back in October
1987).  The changes include:

 . Support for the file protection attribute in the Attribute packet
 . For RSX, ensure Kermit is privileged before performing SF.SMC to remote
   port, to prevent crashes of RSX-11/M+ 4.0.
 . Add local terminal buffering to RSX 'connect' module.
 . Complete definition of DF224 modem.
 . Add a few percent to the size reported in an incoming file's attribute
   packet before preallocating the file for RT-11, to allow for expansion
   of (for instance) UNIX files to CRLF format.

[Ed. - Many thanks to Brian for sending in this update which was badly needed
by RT-11 users who sent files from IBM PCs to the PDP-11, and found that
RT-11 Kermit did not preallocate enough space for the file.  The new files
are in kermit/b/k11* on watsun and cunixc, and available as K11*.* from
KERMSRV at CUVMA on BITNET.]

------------------------------

Date: Thu May 11 15:25:33 1989
From: Frank Dreano, NAVMASSO, Chesapeake, VA
Subject: Announcing Kermit for the Honeywell DPS-6
Keywords: Honeywell DPS-6

This is the copy of the Honeywell DPS-6 Kermit I promised you serveral months
ago.  It has the latest features such as attribute packets and extended
packets.  Documentation and 'C' source code are enclosed (CUCLKER.C,
CUCLPRI.C contain the source and COMPLNK.EC is a DPS-6 batch job to build the
executable). Two modules of MSKermit 2.31 were modified to support DPS-6
Kermit telecommunications:

MSSCOM.ASM => MSSCOM.DPS: modified to support extended packets and
  double transmit the backslash character (\) for the 3.1 DPS-6
  operating system, a necessity unfortunately.

MSZIBM.ASM => MSZIBM.DPS: modified to provide VERY rudimentary
  terminal support when in VT102 mode...just enough to let a
  Honeywell user login to the DPS-6.

All changes are documented in the source and the executable MSKermit 2.31
produced by these modules remains generic and I have used it on the DDN VAX
systems as well as IBM and Tandem systems.

Sincerely,

Frank Dreano
NAVMASSO
1441 Crossways Blvd.
Chesapeake, VA  23320-8915
[phone]

[Ed. - Thanks to Frank Dreano and to Steve Carr for the sources.  Until now
we have only had a .HEX file which no one could modify.  The old .HEX file
has been replaced with the new sources and .HEX files in ~kermit/d/hd6*.jar.
The ".jar" files are collected files stored together ("join archive").]

------------------------------

Date: Tue, 30 May 89 11:36:31 WET DST
From: The UK National PD Software Archive
      <[e-mail]>
Subject: Announcing Version 2.9 of Apollo Pascal Kermit
Keywords: Apollo Kermit

The principal change between versions 2.7 and 2.9 of Apollo APX Kermit is to
add in the 8 bit quoting and associated file handling changes from APO Kermit
versions 2.8 and 2.8a.  In the parameters exchange, APX 2.9 also handles 'Y'
and 'N' in the 8-bit field from the other Kermit correctly.  Also there is
now SET 8BIT ON/OFF (if ON, it sends '&' which, according to the protocol
manual, means "I insist on quoting"; if OFF, it sends 'N' which means "I
can't").  I believe that the APX Kermit can now do everything that the APO
version does (and more).

The extensions are:

  APX can be run on a remote node, even (crudely) from an attached terminal
   on the local node.
  Repeat count processing.
  Filename normalising.
  RECEIVE followed by filename.
  SET TIME and TIMEOUT.
  CVT_NL is now called RAW (i.e. CVT_NL OFF now RAW ON).

This version works out how it is being driven and sets GRAPHICS and RAW
accordingly.  As before, if it is being driven by an sio line it assumes it is
running as a remote Kermit, so you can't use it as it stands to drive one sio
on a node from another.

If it is running on a remote node, CONNECT now works in RAW mode.  This means
you no longer get a double echo and echoing of passwords and you can send
control characters.  However, if you are using an attached terminal on the
local node, this doesn't work and you must explicitly SET RAW OFF before
CONNECTing.  If normalising, received file names are converted to lower case.
Now handles prefixing in incoming fileheader packets and does control quoting
in outgoing ones.

To avoid confusion, this version announces itself as Apollo-APX.  Minor code
changes to stop the Pascal optimiser generating warnings.

This version works under Aegis SR 9.7.  I don't know whether it works under
SR10 - but it will have to be made to eventually.

Gordon Sands
Technical Computing Dept.
Marconi Space Systems Ltd.
Anchorage Rd.
Portsmouth  PO3 5PU
ENGLAND
0705-664966 x3521

[Ed. - Thanks, Gordon!  And thanks to Steve Jenkins at Lancaster University
for sending this version in to us.  This new release has been placed in the
Kermit Distribution under the prefix "apx", in the C area (kermit/c/apx*).
It is supposed to combine the features of the two older Apollo Pascal Kermits,
which remain available in the same area under the "apo" and "apl" prefixes.
Users of Apollo Pascal Kermit are encouraged to pick up the new release and
let us know if the older ones can be retired.]

------------------------------

Date: Tue, 30 May 89 11:47:55 WET DST
From: The UK National PD Software Archive
      <[e-mail]>
Subject: Announcing GEC/OS4000 Kermit Version 3.9
Keywords: GEC OS4000 Kermit

Version 3.9 of GEC Kermit for standard OS4000 consists mainly of bug fixes
and fuller checking of received packets.  Most of the changes were prompted
by a spate of failed transfers some of which resulted in the GEC terminal
getting locked up.  The new version is more careful about whether it is in
Logical or Physical mode and looks for Ctrl-Z more often.  Some of the
packets were arriving with bytes missing.  This caused problems because the
GEC kermit would wait for the number of bytes it was expecting and transfer
would halt until one side timed out.  The new version looks for premature
CRs and immediately NAKs the packet.  There were also problems in binary
mode with files which ended in a null or with 2 or 3 copies of the same
character.

The routine which normalises incoming filenames now checks the new filename
and strips off leading digits.  Should the new name consist only of digits,
the first is replaced with an X, e.g. S12ABC.XYZ becomes .ABCXYZ and
S1234567.123 becomes .X4567123.

If a user types RECEIVE followed by a filename, but then SENDs more than one
file, only the first goes into the given name - the rest into normalised
versions of the sender's names.

I have developed a way of setting things up so that a user Kermitting to a
GEC machine needs only to connect once in a session (to compensate for the
lack of a LOGOUT command).  Details in GECSVR.JCL.

Gordon Sands,
Technical Computing Dept.
Marconi Space Systems Ltd.
Anchorage Road,
Portsmouth, ENGLAND PO3 5PU
0705-664966 x3521

[Ed. - Thanks again to Gordon and Steve for this work.  This version replaces
the old release in Kermit Distribution area D, under the prefix "gec".]

------------------------------

Date: Thu, 27 Apr 89 15:17 EST
From: Roger Wallace <[e-mail]>
Subject: HP-9000 Kermit Bootstraping Methods
Keywords: HP-9000 Kermit, BASIC Kermit, Bootstrapping

Alternative Methods for Bootstrapping KERMIT-RMB to HP-9000 Workstations:

We have now successfully bootstrapped Kermit-RMB to several HP-9000 series
workstations, and are in the process of gathering user feedback on the
performance of this new version.  This particular Kermit fills a long-
standing need for reliable file transfer to hosts outside of the HP family.
The basic terminal emulation and file transfer facilities seem to work as they
should; we will forward any bug reports from our user community both to the
Digest and to Andy Campagnola.  In the meantime, I thought I would pass along,
as alternatives, the methods we tried for getting the appropriate files into
HP-LIF disks.

[Ed. - 124 lines omitted from here for lack of space, see below...]

And finally, our thanks again to Andy Campagnola and his associates at HP for
making a much-needed Kermit implementation available.

Roger Wallace
Research Division
Raytheon Co.
Lexington, MA

[Ed. - And many thanks to you, Roger!  Your Fortran dehexifying program has
been added to the HPB files as HPBDEH.F77, and the full contents of this
message have been added as HPBKER.BWR.  There is also a new release of the
HP-9000 Kermit program on the way from Andy Campagnola that should simplify
the bootstrapping a bit.]

------------------------------

Date: Thu, 11 May 89 13:32:16 IST
From: Reuven Weiss <[e-mail]>
Subject: Using Kermit on Ethernet?
Keywords: MS-DOS Kermit Network Support, Interlan, 3COM

I would like to use the Kermit interface (scripts, key redefinitions, etc.)
while connected from a PC to a host by TELNET.  Our campus has many RS-232
terminals where we use Kermit 2.32/A on PC's and the various Kermit programs
on CDC, VAX and IBM hosts.  We also have a LAN under TCP/IP protocol.  The LAN
connects to the same hosts and to many PC's.  On the PC's we use 3COM 3C501
and WD8003E cards and NCSA 2.2 program (for TELNET and FTP).  Instructing
users would be easier if the two programs (KERMIT and NCSA) would have similar
user interface, where it is possible.  There is much similarity in terminal
emulation and KERMIT works now also with LAN (NETBIOS and U-B).  Perhaps
KERMIT can evolve to TCP/IP emulation?  I would like to read comments from
Kermit users.

Reuven Weiss
Faculty of Engineering
Tel - Aviv  University
[e-mail] (a VAX/VMS site) or
[e-mail] (an IBM/VM site)

[Ed. - There are many requests for this.  The most practical approach to
adding TCP/IP Telnet support to MS-Kermit would be to take the board-level
drivers from NCSA Telnet and convert them into TSR Bios-level drivers for
COM1.  Then let MS-Kermit's SET PORT BIOS1 command do the rest.  This
apparently already works with certain commercial IP products, e.g. Interlan's
TCP/IP Gateway for Novell networks (see Info-Kermit V9 #8).]

------------------------------

From: Martin Kiff <[e-mail]>
Date: Wed, 24 May 89 17:29:47 BST
Subject: Mixing Things in MS-Kermit Key Definitions?
Keywords: MS-DOS Kermit Key Definitions

A quick question, or perhaps a request.

I am trying to set up a key definition which is a combination of a Kermit verb
and trailing characters, something like:

   set key \316 \Klfarr\016T

give or take a few braces.

Why would I want to do a thing like that?  Well we use Kermit mainly over an
X.25 network talking to a VAX.  The VAX likes to think it is dealing with
single characters; the network works better with longer packets.  The PADs on
the network are thus set up to bundle together characters until there is a
1/20 sec pause and then send them off.  This is fine if using autorepeat to
write a string of '.'s across the screen but embarrassing if holding down the
'delete line' key.

It would be nice to be able to tag onto some of the VT100 verbs, like the
cursor movement, PF4, kpminus, kpcoma the characters to force the PAD to
dispatch the packet being built.  This is the <CntlP>T sequence above.

It seems however that Kermit (2.32/A version for PCs) doesn't allow this, is
it something in the pipeline?  Do other people have similar problems?

Many thanks,

Martin Kiff
Computing Services Unit
National Physical Laboratory
[e-mail]

[From JRD - Yes, this is a restriction.  As the code design stands presently
one cannot join a Kermit keyboard verb with other text in the same definition.
The algorithms in use do all the definition parsing when the key is being
defined, rather than when the definition is being sent to the host.  Were the
latter the case, then terminal emulation speed would drop a lot on medium
speed 286's and slower machines, and the memory usage for definitions would
grow substantially.  On 286 machines and above, you might consider
reprogramming the keyboard repeat rate to match the PAD.  There are public
domain programs (very short) to do just that.]

------------------------------

Date: Tue, 30 May 89 16:06:36 GMT
From: Pete Gifford <PETE@ALLEGVM>
Subject: Kermit-370 Through 3174 AEA?
Keywords: IBM 3174 Controller, IBM 370 Kermit

Does anyone have Kermit 4.1 file transfer for CMS or MUSIC working through a
local 3174 with the Asynchronous Emulation Adapter (AEA)?  We are using
ProComm+ for terminal emulation (VT102) and ProComm+'s Kermit file transfer
option and are not able to get the two to communicate.  Any help will be
greatly appreciated.

Pete Gifford           PETE@ALLEGVM
Systems Programmer     [e-mail]
Allegheny College      [phone]
Meadville, PA          [phone]

[From John Chandler - The latest word on the 3174 is that there is no means of
transparent throughput at present.  However, IBM has indicated there will be
some such capability fairly soon (as of a month ago, the microcode upgrade was
due in about 6 months).  It presumably won't be long after that before Kermit
will be able to do file transfers through the 3174.]

------------------------------

Date: Thu, 11 May 89 17:53:23 edt
From: [e-mail]
Subject: C64-Kermit Problem
Keywords: Commodore-64/128

I have the following configuration : a Commodore C64, a 2400 baud Hayes
compatible modem and a modem adaptor that connects the former two together.
When I used a terminal software called CCGMS 6.0, the system worked nicely up
to 2400 baud !!!!!  However, when I used KERMIT, it was a complete failure no
matter what baud rate I tried !!  The problem is : After the usual procedure
of dialing the number manually and hearing the high pitch tones, the modem
did not kick in to do the rest !!  Are there some parameters (that I am not
aware of) that need to be set beside baud rate in KERMIT ?  What about a
parameter in KERMIT called rs232-registers ?  What should be its hex value ?
Any help is appreciated !!
                                    Patrick Wong

------------------------------

End of Info-Kermit Digest
*************************

14-Jul-89 19:14:32-GMT,25038;000000000001
Return-Path: <[e-mail]>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
    id AA28323; Fri, 14 Jul 89 15:14:09 EDT
Received: from watsun.cc.columbia.edu by cunixc.cc.columbia.edu (5.54/5.10) id AA24015; Fri, 14 Jul 89 15:13:41 EDT
Received: by watsun.cc.columbia.edu (4.0/SMI-4.0)
    id AA28254; Fri, 14 Jul 89 15:09:36 EDT
Date: Fri, 14 Jul 1989 15:09:36 EDT
From: Christine M Gianone <[e-mail]>
To: [e-mail]
Subject: Info-Kermit Digest V10 #1
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Fri, 14 Jul 1989         Volume 10 : Number 1

Departments:

  NEWS -
        New Draft of International Character Set Proposal Ready for Review
        Article about International Character Sets at Moscow Conference
        New Additions to the Roster of Native Media Volunteers
        Missing Recent Issues of Info-Kermit

  ANNOUNCEMENTS -
        New Release of C-Kermit Available for Testing
        Announcing Release 0.97(57) of Macintosh Kermit
        Announcing Version 1.00 of OS/2 Kermit, with C-Language Source
        Announcing a Russian Version of Kermit for IBM/370 MVS/CICS
        Announcing Version 4.0 of MS-Windows Kermit
        New Release of HP-9000 BASIC Workstation Kermit
        CP/M Kermit Replacement Files
        New Release of Kermit-UCSD (UCPECAN)
        Kermit Script to Map IBM-PC Keyboard for GNU EMACS
        CPVROB.HEX File Now With Distribution

Send digest submissions to [e-mail], requests for
addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN, WATSUN.CC.COLUMBIA.EDU, a
SUN-4/280 running UNIX (SUNOS 4.0), IP host number 128.59,39.2, or to CUNIXC,
CUNIXC.CC.COLUMBIA.EDU, a VAX 8700 running UNIX (Ultrix), IP host number
128.59.40.130.  Login as user anonymous (note, lower case), any password, and
GET or MGET 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
kermit/a/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 Jul 5 12:00:00 1989
From: Christine M Gianone <[e-mail]>
Subject: New Draft of International Character Set Proposal Ready for Review
Keywords: International Character Sets, Kermit Protocol

The third draft of the Kermit international character set proposal is
complete.  Hopefully, the proposal is nearing its final stage before
incorporation into the Kermit protocol.  The proposed extension to Kermit
will allow unlike computers to transfer text files written in languages other
than English, including text containing many languages.

The new draft is available in kermit/test/isok3.txt on watsun and cunixc, and
in T:ISOK3.TXT from KERMRSRV at CUVMA on BITNET.  Your comments are most
welcome.  If you are interested in joining the smaller "isokermit" discussion
group, please let me know.

The document is about 94K long.  For convenience, it has also been broken up
into five smaller pieces of 16K-20K each, which may be obtained separately.
They are isok3.1, isok3.2, isok3.3, isok3.4, and isok3.5.

------------------------------

Date: Thu Jun 29 19:16:06 1989
From: Christine M Gianone <[e-mail]>
Subject: Article about International Character Sets at Moscow Conference
Keywords: International Character Sets, Data Communications Magazine
Keywords: International Kermit Conference

A short piece about the First International Kermit Conference and the
international character set extension to Kermit appears in the June 1989
issue of Data Communications Magazine, p.48 (p.52 of the international
edition).  A longer article will appear in a future issue.

------------------------------

Date: Thu Jun 29 19:22:23 1989
From: Christine M Gianone <[e-mail]>
Subject: New Additions to the Roster of Native Media Volunteers
Keywords: Alpha Micro 68K, IBM RT PC, Diskette Volunteers, Native Media

As readers of this digest know, Columbia University is able to provide Kermit
programs on magnetic tapes and disks in a limited number of formats.  But
there are many formats we cannot produce.  For that reason, we have always
encouraged public-spirited volunteers to come forward and distribute Kermit
programs on other kinds of media.  Recent volunteers have begun distributing
Kermit for the Alpha Micro (video tape cassette) and the IBM RT PC (5 1/4"
diskette).  We express our appreciation, and hope that additional volunteers
will join the group for formats and computers that are not yet available.  The
current list of diskette volunteers is available in the file aadisk.hlp.

------------------------------

Date: Wed Jul 5 15:00:00 1989
From: Christine M Gianone <[e-mail]>
Subject: Missing Recent Issues of Info-Kermit
Keywords: KERMSRV, LISTSERV, Info-Kermit

Due to some problems with the cunixc-to-watsun transition, Info-Kermit
volume 9, numbers 6, 7, and 8 were apparently not delivered to our BITNET
LISTSERV subscribers.  If you missed any of these issues, you can get them
by sending mail to KERMSRV@CUVMA.  In the text of the message, put one line
for each issue you need:

MAIL V9.6
MAIL V9.7
MAIL V9.8

Sorry for the inconvenience.

------------------------------

Date: Mon Jun 19 16:52:29 1989
From: Frank da Cruz <[e-mail]>
Subject: New Release of C-Kermit Available for Testing
Keywords: C-Kermit, UNIX Kermit, Attribute Packets, SUN, Ultrix
Keywords: Encore Multimax, OS/2, NeXT, IBM RT PC, Zilog ZEUS, Microcom
Xref: File Attributes, see Attribute Packets

This is to announce another test release of C-Kermit, 4F(085), to replace
the earlier test release 4F(077) that was announced on April 3, 1989.  This
version fixes several serious problems in 4F(077), namely:

  - Connect-mode craziness when when connecting back to a remote system after
    transferring a file.  Thanks to Frank Prindle for finding the fix for
    this.  The fix is only for BSD versions, other versions may still
    experience minor problems (a few glitch characters) under these
    circumstances -- if anybody can track down the problem and fix it, please
    do!

  - Protocol misnegotiations when C-Kermit is running in server mode, caused
    by a missing comment delimeter.  This caused all sorts of trouble, repeat
    counts and 8th-bit prefixes being accepted as data, etc.  Oops!

  - Hangup command, and ^\h connect-escape, fixed up so as not to leave lock
    files around (Patrick Wolfe).  Seems to work OK in BSD-based UNIX
    versions, untested in System III/V.

Besides these fixes, 4F(080) has several new features, including:

  - Further performance improvements, mostly from Paul Placeway of Ohio State
    University (of Macintosh Kermit fame), including "encode-ahead" and
    dynamic packet sizing (similar to Kermit-370).

  - Support for OS/2, contributed by Chris Adie of Edinburgh University in
    Scotland.  Unfortunately, Chris's work was based on release 4E(070) of
    C-Kermit, and so there had to be a lot of code-shuffling.  The result is
    entirely untested, which is one reason why this release is a test release
    rather than a real release.  See the separate announcement from Chris
    Adie.

  - A new 'transmit' command, for raw uploading.  As yet, not interruptible.

  - 'dial' command support for the Microcom ax9624 modem, from Jim Knutson.

  - Recognition of file-type attribute (text or binary) when receiving files.

  - Addition of file creation date to the attributes which C-Kermit sends.
    C-Kermit still does not do anything with dates on received files (tested
    in Berkeley versions, not tested in AT&T or other versions).

  - Support for tilde in file names in all interactive commands that parse
    input or output file names (SEND, RECEIVE, GET, DIRECTORY, LOG, CD, etc).

  - Support for tilde in file names sent to the C-Kermit server in GET,
    REMOTE DIRECTORY, and similar commands.

  - Support for 4.1BSD, Apple A/UX, NeXT, and RT PC AIX 2.2.1 added to
    makefile, and support for UNOS, Zilog/ZEUS fixed up (but not tested).

See the file ckuker.upd for details about the changes.

This release has been compiled and tested on a SUN-4/280 with SUNOS 4.0, a
VAX/8700 with Ultrix 2.0, and an Encore Multimax 310 with UMAX V 2.2.  It was
also briefly tested in the AT&T System V environment on the SUN, and seemed
to work OK.  Further testing is required on AT&T UNIX variants, Xenix, etc.

PLEASE report the results of your testing.  We need to know if this version
works on all the systems that the program tries to support before we can
make it an "official" release.

The new release is available via ftp from watsun.cc.columbia.edu, in the
directory kermit/test/ck*.  Also in the same directory on cunixc.

BITNET/EARN users may also access the test files in the new KERMSRV test area.
Refer to these files as T:CKU*.*, T:CKC*.*, T:CKW*.*, and (for OS/2) T:CKO*.*,
for example:

  TELL KERMSRV AT CUVMA MAIL DIR T:*.*
  TELL KERMSRV AT CUVMA SEND T:CKC*.*

Please get the files, try them out, and report any problems to me.  After the
kinks are worked out, version 4F will replace the current standard 4E release.

Note, there are also some ckv*.* files in kermit/test for the VAX/VMS version
of C-Kermit, but they are not totally up-to-date with this new test release.
Watch Info-Kermit for further announcements.

There are also some other C-Kermit systems that haven't been updated in a
long time, including the Amiga (cki*.*), Data General AOS/VS (ckd*.*), OS-9
(ck9*.*), etc.  Volunteers?

Thanks to the many people who tested 4F(077) and 4F(080) and sent in fixes and
suggestions, including (in no special order) Ge van Geldorp, John Evans, Mark
Buda, Martin MacLaren, Dave MacKenzie, Paul Placeway, Joe Doupnik, Chris Adie,
Frank Prindle, Gary Holbrook, Patrick Wolfe, and Jim Knutson, and apologies to
anyone I forgot to mention.

------------------------------

Date: Tue, 27 Jun 89 15:33:06 EDT
From: Paul Placeway <[e-mail]>
Subject: Announcing Release 0.97(57) of Macintosh Kermit
Keywords: MacKermit 0.97(57), MacBinary, Macintosh Kermit
Xref: Apple Macintosh, See Macintosh

The new Macintosh Kermit, version 0.97(57), is ready for testing.

Included are all the ckm*.* sources, a .hqx file which can be converted into
the MacKermit application using BinHex Version 4, and two short doc files,
(ckmvt1.doc and ckmker.hlp).  All of this is built on top of C-Kermit 4F(080),
with my bug fixes in the ckc files (it even builds a wart to use).

I have personally tested it on a 512k (not e) running System 1.1, a Lisa
running MacWorks 3.0, Mac Pluses running System 2.0 through 6.0.3 and a Mac II
running 6.0.2; I am told it works on SE and SE30 machines also (which is not
really a supprise).  Basically the only thing it doesn't work on (for sure) is
an old 128k "Classic" Mac (if I had one here I could probably make it work
there too).

Anyone who is doing work on Mac Kermit should get a copy of the new sources as
soon as they can; I have changed some things around, especially the terminal
emulator internals.  Code based on 0.9(40) may or may not be easy to work into
the new sources.

New additions to the program since the 0.9(40) release in May 1988 include:

    Vertically sizeable terminal emulation window.
    Scroll back.
    Faster file transfer.
    (hopefully) Correct binary file transfer code.
    MacBinary format transfers.
    Better keyboard handling.
    Printer support.
    Terminal emulation and file transfer using printer port.
    Partial emulation of a DEC VT300-Series terminal, including support
      for ISO 646 National Replacement Character sets and Latin Alphabet 1.

More keyboard macros have been added to better handle the vt100 keyboard
and normal/application mode stuff:

        \keypad0 -- \keypad9
        \keypad,
        \keypad.
        \keypad-
        \pf1-4
        \leftarrow
        \rightarrow
        \uparrow
        \downarrow

The keypad comes configured for a Plus; if you have an ADB machine, you will
have to remap the + and - keys, and possibly =, /, and * to be pf2-4.

Bugs and limitations still outstanding:

    Running in inverted screen mode doesn't work.
    The option key is still a dead key for the usual characters (e, u, etc.)
    Parts of the Edit menu should be greyed out when they do not apply.
    Cut and Paste do not deal with the real Scrapbook (yet).
    There still isn't a Tektronix graphics terminal emulator built-in.
    It is possible to confuse the selection by draging past the top of
      the window, waiting, and dragging down past the end of the window.

Other than these, if you find a problem please send mail to
[e-mail] (on the Internet), or KERMIT@CUVMA on
BITNET.  Please include Kermit version number, a discription of the hardware,
the System version number, and if possible a "repeat-by".

                                Happy Kermiting,

                                Paul Plaeway, MacKermit coordinator
                                [e-mail]

[Ed. - Many thanks, Paul!  The new files have been placed in the kermit/test
directory on watsun and cunixc, and in the T: area of BITNET KERMSRV on CUVMA.
This release has to be considered a test release because it is based on a test
version of C-Kermit, and also because there is not yet a new manual.  Mac
Kermit users, please take a copy, try it out, and report bugs to Info-Kermit
as Paul asks.  By the way, "correcting binary file transfer code" refers to
a long-standing problem in all Kermits based C-Kermit 4E(07x), which should
be corrected in the new 4F release, and therefore also in this release of
Mac Kermit, namely that -- under certain circumstances -- binary file transfer
over a 7-bit communication channel would only work once.  Also, please note
that Paul's .hqx file does not totally correspond to the C-Kermit ckc*.*
sources, since a few minor fixes were made between 4E(080) and 4E(082).  See
ckuker.upd for details.]

------------------------------

Date: Wed, 10 May 89 10:16 CST
From:  Chris Adie, Edinburgh University Computing Service
Via: [e-mail]
Subject: Announcing Version 1.00 of OS/2 Kermit, with C-Language Source
Keywords: OS/2 Kermit

The first full release of C-Kermit for OS/2 is now available.  The version
number is 1.00, and it superseeds all version numbers of the form 1.0a, etc.
There are only (literally) one or two bug fixes since the last beta test
release (1.0p).  There are still a couple of unfixed bugs in the DIAL and
SCRIPT commands - probably associated with the code which emulates the Unix
alarm() function, which both commands use.

The sources are now also available.  There are three OS/2-specific sources:

  ckocon.c
  ckotio.c
  ckofio.c

The rest of the sources are the C-Kermit ck*.c and ck*.h files, with additions
controlled by "#ifdef OS2" directives.

Unfortunately, pressure of work means I'm currently unable to do much more
with OS/2 Kermit.  Any volunteers to carry the torch?  You'll need the
Microsoft OS/2 Software Developer's Kit.  The main requirement (apart from
fixing the problems mentioned above) seems to be for keyboard remapping
facilities.

Chris Adie
Edinburgh University Computing Service

[Ed. - Thanks to Chris for this long-awaited contribution!  Chris's OS/2
conditionals have been added to the ckc*.* and cku*.* files, and some attempt
has been made to add the new i/o buffering and file attribute functions to
Chris's code.  The results are all in the kermit/test directory in the ckc*.*,
cku*.*, and cko*.* files (and also in the T: KERMSRV area for BITNET).
Included is a ckoker.boo file, which can be unboo'd back into an .EXE file
using any of the msbpct.* programs from kermit/a.  This boo-file is based on
Chris's original submission, and not on the updated sources.  OS/2 users are
urged to get the sources and try to build the new version, make any necessary
corrections to the OS/2 specific files, and report the results back to
Info-Kermit.  Thanks!]

------------------------------

Date: Wed Jul 5 12:00:00 1989
From: Christine M Gianone <[e-mail]>
Subject: Announcing a Russian Version of Kermit for IBM/370 MVS/CICS
Keywords: IBM 370 Kermit, CICS, MVS/CICS Kermit, USSR, Kermit-370

The files whose names start with IKX in the B area of Kermit Distribution
comprise a version of Kermit for CICS on the IBM 370-series mainframe.  This
version is based upon a very old release of MVS/TSO Kermit, and it was adapted
to CICS by the programmers at the International Centre for Scientific and
Technical Information (ICSTI) in Moscow, USSR, and presented to Columbia at
the First International Kermit Conference in Moscow, May, 1989.

This program is included with the Kermit-370 distribution in hopes that
someone will be able to adapt the CICS support to Kermit-370, for CICS under
MVS, VM, and/or DOS/VSE.  Programmers should be aware of the environment for
which this program was written.

First, it is for a Soviet IBM/370-compatible computer, the EC-8570, running an
old version of MVS.

Second, the EC-8570 uses a special version of EBCDIC which supports the
Cyrillic character set.  For communication with ASCII terminals, the EC-8570
uses a 7-bit character set called KOI-7, which is similar to ASCII, except
that the lowercase ASCII letters have been replaced by uppercase Cyrillic
letters.

Aside from these differences, it appears that this program should be suitable
for use on US IBM models, and that the CICS support -- which is for the
linemode TTY communication environment only, not the full-screen 3270
environment -- should be a suitable base for adaptation to Kermit-370.

Many thanks to the Computer Department at ICSTI for producing this version of
Kermit and contributing it to Kermit Distribution.  See the file IKXAAA.HLP
for further information.

______________________________


Date: Mon, 12 Jun 89 10:03:47 PDT
From: rochester!ames!claris!apple!netcom![e-mail] (Bill Hall)
Subject: Announcing Version 4.0 of MS-Windows Kermit
Keywords: MS-Windows Kermit

Enclosed is the most recent update of MS-Windows Kermit, version 4.0.  The
arrangement of the files has been completely reorganized to fit within Kermit
guidelines.  In particular, all file names are prefixed with WIN, a WINAAA.HLP
file is available, and all binary files have been converted to the BOO format.

On the surface, the program appears much the same as the old one; internally
there has been a major revision of the terminal emulation to improve
performance and to correct some bugs in the ANSI emulation.  In addition, the
dialog boxes have been revised to produce more standard patterns of behavior.
The Kermit implementation has not changed.

[Ed. - Many thanks, Bill!  This new release has been (very easily) installed
in the Kermit A area, replacing the old win*.* files.  Note, four files still
needed to be renamed: ckcdeb.h was renamed to winckc.h, cdwart.c was renamed
to winckw.c, ascii.h was renamed to winasc.h, and winker (the makefile) was
renamed to winker.mak.  The first two are just copies of the C-Kermit files.]

------------------------------

Date: Wed Jun 21 15:54:28 1989
From: Christine M. Gianone <[e-mail]>
Subject: New Release of HP-9000 BASIC Workstation Kermit
Keywords: HP-9000 Kermit, BASIC Kermit

>From Andy Campagnola of Hewlett-Packard in Loveland, Colorado, comes version
1.02 of HP-9000 BASIC workstation Kermit.  The major change seems to be that
the source can now be modified to run in HP-BASIC 4.0 as it contains no
compiled code -- it's 100% interpreted BASIC.  Many of these files came to us
in binary format with strange names, and so had to be hexified and renamed.
The files are in the C area of Kermit Distribution (kermit/c) under the
prefix "hpb".  See the file HPBAAA.HLP for details about file renaming and
encoding.  Thanks to Andy for sending in this new release!

------------------------------

Date: Wed, 10 May 89 16:07:22 WET DST
From: The National PD Software Archive
      <[e-mail]>
Subject: CP/M Kermit Replacement Files
Keywords: CP/M Kermit

[Ed. - This message is in response to a report that two of the CPM Kermit
files contained long strings of Ctrl-Z characters, followed by many K of
junk.]

The new CPM-Kermit developer is Dr Martin Carter of Nottingham University.
His Email address is [e-mail].  Here is a message
from him about the CPXSY*.ASM files:

Comparison of hard copy shows that the bit I thought was interpolated is in
fact the proper new end of the file; the code after that point is from the
original, after the point of deletion.  As I suspected, a CP/M directory
botch, but the other way round.  If *that* is the sort of thing Bertil's CP/M
editor did with Truly Huge Files, I can see why he split them up.

Further investigation shows that the same sort of thing has happened with
CPXSY2.ASM.  In neither case would assembly with LASM show up the problem, as
it would LINK elsewhere or (for CPXSY2) END before reaching the danger point.
I dunno what M80 would have made of it.

I've accordingly truncated both files properly (and added in something I
happened to see in an old copy of CPXSYS which appears to have fallen through
the cracks somewhere), and will be e-mailing them to your good selves Under
Seperate Cover.  Thanks for notifying me - the truncated files are not much
more than half the original length, which makes life easier with restricted
disc space.

Stay Tooned,

    Martin

[Ed. - Thanks for sending in the fixed files, Steve, and thanks to Martin for
fixing them.  They have replaced the old copies in the Kermit Distribution A
area as CPXSYS.ASM and CPXSY2.ASM.  Steve also reports that a new release of
CP/M Kermit, 4.09a, is on the way.  Stay tooned.]

------------------------------

From: [e-mail]
Subject: New Release of Kermit-UCSD (UCPECAN)
Date: Sat, 20-May-89 09:19:11 PDT
Keywords: UCSD Pascal Kermit, Atari ST, Pecan p-System

I am submiting my new version of Kermit-UCSD (Version 1.1), currently
running on the Atari MEGA ST2 with the Pecan Software Systems Inc p-System
Version IV.2.2, and adaptable to Version IV p-Systems on other machines.

You should receive 3 files: 1) a large (about 4500 lines) one containing
the source (UCPECA.PAS), a smaller (about 500 lines) one containing the
documentation (UCPECA.DOC), and a very short (about 50 lines) one containing
a brief list of changes made from V1.0 to V1.1 (UCPECA.UPD).

This version contains most of the features I wanted and fixes for the major
bugs of V1.0; known limitations are listed in the .DOC file.

                                        R. Tim Coslet

Usenet: [e-mail]
BIX:    r.tim_coslet

[Ed. - Many thanks, R. Tim!  Your new release has replaced the previous one
in the "c" Kermit distribution area as kermit/c/ucp*.*, and UCP*.* on BITNET.]

------------------------------

Date: Fri, 26 May 89 19:08:45 EDT
From: Andy Lowry <[e-mail]>
Subject: Kermit Script to Map IBM-PC Keyboard for GNU EMACS
Keywords: MS-DOS Kermit Key Definitions, GNU EMACS, Meta Key

I noticed when I pulled the latest kermit release recently that there's a
script included that maps the IBM-PC keyboard to make ALT generate Meta
characters for use with GNU EMACS.  I've included a file that does that as
well as control-meta characters for the lowercase letters.  It maps a few
other keys as well...  check the comments for details.  If it seems useful,
please feel free to add it to the distribution.

[Ed. - It does, and we did, thanks!  It has been put with the other MS-DOS
Kermit files in the "A" area, as msiem2.ini.]

------------------------------

Date: 7 Jul 89 14:35
From: [e-mail]
Subject: CPVROB.HEX File Now With Distribution
Keywords: DEC VT-180, Robin, VT-180, CP/M Kermit

Sending the file CPVROB.HEX file to include in the Kermit distribution.

- Willie

[Ed. - Thanks!  The file CPVROB.HEX (for the DEC VT-180 Robin) is in ~kermit/a
with the other CP/M Kermit files.]

------------------------------

End of Info-Kermit Digest
*************************

21-Aug-89 22:01:53-GMT,24015;000000000001
Return-Path: <[e-mail]>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
    id AA16194; Mon, 21 Aug 89 18:01:51 EDT
Received: from watsun.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
    id AA12585; Mon, 21 Aug 89 17:59:17 EDT
Received: by watsun.cc.columbia.edu (4.0/SMI-4.0)
    id AA15908; Mon, 21 Aug 89 17:22:26 EDT
Date: Mon, 21 Aug 1989 17:22:25 EDT
From: Christine M Gianone <[e-mail]>
To: [e-mail]
Subject: Info-Kermit Digest V10 #2
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Mon, 21 Aug 1989        Volume 10 : Number 2

Today's Topics:
                  Announcing Pick Kermit Version 0.3
                C-Kermit 4F(094) Available for Testing
                  ISO/Kermit Correspondence Archive
                  File Comparitor for IBM Mainframes
                      CMS Kermit 4.1.001 Warning
          MS-Kermit Scripts and IBM 7171 Protocol Converters
     Using KERMIT for File Transfer Between a PRIME and an RT PC
                      C64-Kermit Problem
                    Re:  Using Kermit on Ethernet?
                         Kermit for Navigator
                    Errors Compiling Amiga Kermit

Send digest submissions to [e-mail], requests for
addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN, WATSUN.CC.COLUMBIA.EDU, a
SUN-4/280 running UNIX (SUNOS 4.0), IP host number 128.59,39.2, or to CUNIXC,
CUNIXC.CC.COLUMBIA.EDU, a VAX 8700 running UNIX (Ultrix), IP host number
128.59.40.130.  Login as user anonymous (note, lower case), any password, and
GET or MGET 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
kermit/a/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 Aug 21 12:13:32 1989 EDT
From: Christine M. Gianone <[e-mail]>
Subject: Announcing Pick Kermit Version 0.3
Keywords: PICK, Microdata, McDonell Douglas, REALITY, Ultimate, IBM PC

>From Joe Fisher of Austin, Texas, comes release 0.3 of Kermit for the PICK
operating system, written in DATA/BASIC.  Version 0.3 replaces version 0.2C
of January 1987.  The previous release worked only on the Microdata REALITY
system, but the new release works on the following systems:

  Microdata (now McDonell Douglas) REALITY 4.2E
  DEC MicroVAX II with Ultimate Coprocessor R10*182P
  IBM PC/XT and compatibles under PICK R83*2.0
  IBM PC/AT and compatibles under PICK R83*2.2

The source files have been completely recoded and reorganized to be
compatible with Kermit Distribution.  They contain only printable ASCII
characters.  There is a new manual, in PICK Runoff format, PICDOC.RNO,
containing user and installation instructions.

Thanks to Joe for his efforts in preparing and contributing this new
version.  The files are in the D area of Kermit Distribution, under the
prefix PIC (kermit/d/pic*.* on watsun, PIC* * via BITNET KERMSRV).

------------------------------

Date: Mon Aug 21 12:33:41 1989 EDT
From: Frank da Cruz <[e-mail]>
Subject: C-Kermit 4F(094) Available for Testing
Keywords: C-Kermit, UNIX Kermit

The forthcoming new release of C-Kermit 4F is coming closer.  Many of the
problems reported by the beta testers have been solved, but a few more must
be fixed before final release.  Since 4F(085) was announced for testing in
Info-Kermit V10 #1 on July 14th, many changes have been made:

 - attempt to allow the program to compile correctly on Apollo SR10 BSD
 - attempt to fix the crazy echoing upon reconnecting after file transfer
   in AT&T-based Unix systems
 - fix the OS/2-specific code so that it compiles correctly
 - added new support for Masscomp/Concurrent RTU
 - added support for AT&T 6300
 - fix TRANSMIT command to be interruptible by Ctrl-C
 - various minor bug fixes, cosmetic improvements, and code reorganization
 - fix IBM/Rolm CBX dialing
 - fix support for NeXT in the makefile
 - improved support for Hayes modem responses
 - new Microcom modem support
 - updated support for OS-9/68K
 - fixed dynamic packet size recalculation to only shorten packets upon real
   errors
 - fixed file size and throughput reports in STATISTICS command
 - attempt to eliminate many compile-time point-type mismatches caused by
   calls to signal()

Some outstanding problems:

 - The OS/2 version reportedly compiles and runs correctly, but the
   CKOKER.BOO file which is provided is based on a much older version of
   C-Kermit.  OS/2 users who build the new version are encouraged to send in
   an up-to-date CKOKER.BOO file.

 - The VAX/VMS support code (CKV*.*) is not yet updated to agree with this
   version.  The new VMS code should be available within a week or two.

 - Similarly, the Macintosh code is slightly behind this version, and may
   need some reconciliation.

 - Support code for other non-Unix systems such as Commodore Amiga and Data
   General AOS/VS has not been updated in a very long time, and can not be
   compiled with the current version of C-Kermit.

 - BIG PROBLEM: On an AT&T 3B2/300, but apparently nowhere else, C-Kermit
   fails to write out one or more file buffers when receiving files.

 - Many Unix systems now disagree on the data type of the signal() function.
   Previously it was always (*int)(), but now it is (*void)() on some
   systems like AT&T System V R3, SUNOS 4.0, etc.  C-Kermit includes a
   SIGTYP definition in CKCDEB.H to handle this, but this needs to be
   updated to reflect the situation on the many different systems C-Kermit
   tries to support.  So far the only bad effect seems to be compile-time
   warnings about pointer mismatches.

C-Kermit users are urged to get the latest pre-release and try it out on
their systems and report any problems to me, so that this new version can
finally be formally released, and work can begin on the next version.

The files are in kermit/test/ck*.* on watsun, and T:CK*.* on BITNET KERMSRV
at CUVMA.

------------------------------

Date: Mon Aug 21 12:33:44 1989 EDT
From: Christine M. Gianone <[e-mail]>
Subject: ISO/Kermit Correspondence Archive
Keywords: International Character Sets

The mail archive of the "ISO / Kermit" discussion group is now available as
kermit/test/mail.txt on watsun, and as T:MAIL.TXT on BITNET KERMSRV.  The
messages discuss the recent proposal to extend the Kermit protocol for
transfer of text files composed of different national character sets, as
well as the first three drafts of the proposal itself.  Please notify me if
you want to be added to this discussion group.  A fourth draft of the
proposal will be available shortly.

------------------------------

Date: Fri, 1989 May 12   15:16:26 EDT
From: "John F. Chandler" <[e-mail]>
Subject: File Comparitor for IBM Mainframes
Keywords: IBM 370 Kermit

For those who don't already have a favorite file-comparison program, here's a
note concerning one that is available in the Kermit distribution under the
name IK0VER.FOR (that's I K Zero, not I K OH).  It's specialty is comparing
files of 80-byte records with sequence numbers in columns 73 through 80, and
it writes out the differences in the form of an update file for converting one
input file into the other.  The syntax of the updates is compatible with that
used by the UPDATE command of CMS (the control cards begin with the string
"./ " in columns 1-3).  It is not difficult to write a companion program for
applying the updates -- such a program is also available in the Kermit
distribution in versions for MVS, TSO, and MUSIC (in assembler).  IK0VER is
entirely in Fortran and contains comments with directions for converting from
F77 to F66.
                                   John

------------------------------

Date: Tue, 20 Jun 89 15:59:13 EDT
From: Brian Holmes <[e-mail]>
Subject: CMS Kermit 4.1.001 Warning
Keywords: IBM 370 Kermit

After installing version 4.1.001, so far I have only noticed one bug.  When
I invoke the new version I always get the message "Invalid Kermit command"
before I get the CMS-KERMIT> prompt.  I notice that the string '$_' appears
on the screen after I invoke the new version and before I get the error
message.  It appears that '$_' is getting passed to KERMIT somehow and of
course this would generate the error.  I grabbed a completely new version
from KERMSRV before I started too.  Has anyone else had a problem similar to
this?
                        Brian Holmes
                        CSC Operating Systems & Communications

SNAIL    : Wayne State University, 5925 Woodward, Detroit MI 48202 U.S.A.
BITNET   : BHOLMES@WAYNEST1
INTERNET : [e-mail]
UUCP     : {UMIX|ITIVAX}!WAYNE-MTS!BRIAN_HOLMES

[From John Chandler - The message before the Kermit prompt is undoubtedly
due to something in your KERMINI file left over from "the old days".  The
most likely that comes to mind is "SET SERIES1 ON", which was abandoned as
of 4.0 in favor of "SET CONTROLLER SERIES1".  Nearly all the other obsolete
forms of Kermit subcommand are still accepted in Kermit-370, such as "SET
FILE-TYPE BINARY" (should be "SET FILE TYPE BINARY") and "SET RECFM F"
(should be "SET FILE RECFM F").  The "$_" appearing on the screen suggests
something entirely different, namely, that you are connecting through a
fullscreen terminal that isn't Yale-ASCII-type.  Kermit-370 attempts to
detect the kind of terminal controller by issuing a Yale ASCII status
request (which contains an undefined 3270 order plus a dollar sign and
x'BC').  If the controller doesn't recognize the special order as a status
request introducer, the remaining characters will simply appear as text on
the screen.  Kermit will then, incidentally, decide that the controller is
of type GRAPHICS, but it might also be a real 3270-type terminal (in which
case, you wouldn't be able to do any file transfers).  Still, the screen
would normally be cleared after the status check, but some protocol
converters sometimes leave garbage on the screen anyway.]

------------------------------

Date: Fri, 04 Aug 89 09:46:51 ADT
From: [e-mail]
Subject: MS-Kermit Scripts and IBM 7171 Protocol Converters
Keywords: MS-DOS Kermit, Protocol Converters, IBM 7171
Xref: 7171, See IBM 7171

This is in reply to Mike Porter's query in Info-Kermit Digest, v9n7.  Sorry
about the long delay in replying, but because of a BITNET problem, I just
received this issue this week.

We also run IBM7171 protocol converters as the main access to the IBM
mainframes.  I have developed several scripts for automatically logging in,
e.g. to TSO.  In doing that work, I have gained some experience in writing
such scripts.  The following comments might be useful to others:

On a fast PC, it is possible to send a reply to the 7171 too soon (even though
the 7171 is a full duplex device with type ahead buffers).  Apparently, some
software clears the typeahead, e.g. when VTAM turns the terminal over to a new
application.  For example:

   INPUT 10 TERMINAL TYPE:
   OUTPUT vt100\13

starts the output as soon as the colon is received.  Use of Kermit in "line
monitor mode" (set debug on) shows that our 7171 is configured to send a blank
after the colon.  I use

   INPUT 10 TERMINAL TYPE: ;

where the semicolon appears to say that the input string ends at the character
immediately preceding.  Use of backslash code for blank might be better style.
This is particularly important when the 7171 sends an escape sequence (e.g.
cursor positioning) following the visible text.  I have found it frequently
necessary (on my 286 machine) to wait for the escape sequence before sending.
(BTW, escape sequences frequently include semicolons; remember to backslash
escape semicolons in input statements as in:

   input \27[2\;36H

I once spent many hours finding a bug in a script)

The problem of the 7171 sending set-up sequences during the script processing
and these not being transmitted to the emulator is a very annoying one when
trying to automate logons for users.  jrd's proposed solution of:

    set input-echo off
    input 10 terminal type: ;
    output vt100\13
    connect

won't work for us because there is a whole sequence of input/output statements
to do the logon to TSO or whatever before the connect, whereas the 7171
insists on sending the initialization immediately in response to the
"vt100\13".  (Question to jrd: with set input echo off, just how much input is
buffered for eventual processing by the emulator?)

One possible solution would be addition of commands to MS Kermit of the form:

    set terminal vt100-keypad-mode application

or similar.  A script could then anticipate the required setting of all the
emulator modes and explicitly set them before connect.  I can see no way of
doing this in MS Kermit 2.32/A.  (jrd: have I missed something?)

The current workaround is to instruct users to type the "7171 reset" key
(control G on our system) after logging in.  This retransmits all of the vt100
setups while the emulator is listening.  Unfortunately, it is easy for a user
to forget this, which causes strange problems, e.g. in the TSO editor.

I have tried ending scripts with

    output \7
    connect

(yes, with set input-echo off) to try to ask for a reset just before the
connect in the hopes that the emulator would then catch the sequences.  Works
perfectly in the next office on an IBM PC/XT.  On my PS/2 30-286 (an 80286,
10MHz, 1 wait state machine) the communications goes into a loop!  The 7171 is
continuously sending garbage stuff.  I have not had the time to determine
whether the 7171 has botched and is sending junk, or whether MSKermit is
continuously sending stuff and the 7171 is merely responding with error
messages.  (Typically, TSO invalid command, etc).  I presume that the problem
is that the reset occurs too soon after the last part of the logon command to
TSO on my faster machine.  I will report on this problem if I discover more
information.

John DeDourek, Professor
School of Computer Science
University of New Brunswick
Fredericton, N. B. CANADA
E3B 5A3

[e-mail]      -- Registered Domain Name
DEDOUREK@UNB         -- BITNET / NETNORTH (Canada)
[e-mail]  -- For mailers which only know how to get to
                        bitnet this way.

[From jrd - There are two buffers.  The serial port circular buffer is
typically 1500 bytes.  Script commands and the emulator draw from it, and
characters cannot be returned afterward.  Script commands may use a private
128 byte buffer for pattern matching; this buffer is not accessible by the
emulator.  This means that characters drawn out of the primary serial port
buffer by the script commands will not be seen by the terminal emulator.  (To
reiterate a common item: the terminal emulator is not active during scripts,
and this is the root of the discussion here).

I agree that \32 is much safer rendition of a trailing space than a movable
comment indicator. One may also use curly braces around the pattern string,
such as:

   INPUT 10 {TERMINAL TYPE: }           ; optional comment

If one checks DEC VT10x terminals one finds that keypad applications mode can
be set only by the host. The same is true for the VT300 series terminals.
However, the VT320/102/52/H-19 emulator the next release of MS Kermit has the
command SET TERMINAL KEYPAD {NUMERIC, APPLICATION}.

There must be a 7171 problem associated with a too rapid response from the PC.
One way of achieving a tiny wait interval is to say PAUSE 0, the processing
time for which is a few milliseconds.]

------------------------------

Date: 26 May 89 20:22:39 GMT
From: [e-mail]
Subject: Using KERMIT for File Transfer Between a PRIME and an RT PC
Keywords: IBM RT PC, Prime

Concerning using KERMIT for file transfer between a PRIME and an RT:

IT NOW WORKS!

Thanks to everybody who took the time to offer me suggestions, both in the
forum and directly.  I REALLY appreciate it.

It turned out to be a protocol problem -- like the RT version of KERMIT, the
PRIME version also has a KERMIT setup file (that I had been overlooking); so
when KERMIT on the PRIME was made active, it would change the parameters
that I had set using the PRIME's ASYNCH (or whatever) command.

Making sure parity was set to "mark" on both systems is what specifically
fixed the problem.

And to think the only Kermit I knew two weeks ago was the one on Muppet
Babies...

Thanks again for all the help.
-- Mark Skinner (MSKINNER at BOSTON5) 8-234-6521

------------------------------

Date: Tue, 13 Jun 89 22:30:30 EST
From: [e-mail] (Ray Moody)
Subject: C64-Kermit Problem
Keywords: Commodore 64 Kermit, C64 Kermit

>I have the following configuration : a Commodore C64, a 2400 baud Hayes
>compatible modem and a modem adaptor that connects the former two together.
>When I used a terminal software called CCGMS 6.0, the system worked nicely up
>to 2400 baud !!!!!  However, when I used KERMIT, it was a complete failure no
>matter what baud rate I tried !!

    Commodore Kermit is only capable of 2400 baud on a C128, not a
C64.  Support for 2400 baud is likely to appear in the future (hey;
a C64 is a slow machine.)

    There is a problem that occurs at 1200 baud on some modems when
connected to a C64.  The C64 thinks it is a C128 and uses slightly
different timing.  Some modems don't care, others do.  There is a
fixed version of Kermit 2.2, but this version is not widely
distributed.

    There are no known problem with 300 baud.

>The problem is : After the usual procedure
>of dialing the number manually and hearing the high pitch tones, the modem
>did not kick in to do the rest !!  Are there some parameters (that I am not
>aware of) that need to be set beside baud rate in KERMIT ?  What about a
>parameter in KERMIT called rs232-registers ?  What should be its hex value?
>Any help is appreciated !!

    My guess is that there is something *inside the modem* that is not
set properly.  Perhaps you are not sending an AT sequence that your
terminal program does.

    The "set rs232-registers" command is going away soon.  In older
versions of Kermit, the "set rs232-registers" command was used to
specify baud and parity with a cryptic hex number.

    The typical "gotcha" in Commodore Kermit is changing parity
without changing word-size.  If you are using no parity, you should be
using eight bit words.  If you are using any other parity, you should
have seven bit words.  (Perhaps this ``feature'' is too confusing to
be worth keeping.)
                                Ray

------------------------------

Date: Tue, 20 Jun 89  21:16:37 EDT
From: "Roger Fajman" <[e-mail]>
Subject: Re:  Using Kermit on Ethernet?
Keywords: Ethernet

> [Ed. - There are many requests for this.  The most practical approach to
> adding TCP/IP Telnet support to MS-Kermit would be to take the board-level
> drivers from NCSA Telnet and convert them into TSR Bios-level drivers for
> COM1.  Then let MS-Kermit's SET PORT BIOS1 command do the rest.  This
> apparently already works with certain commercial IP products, e.g. Interlan's
> TCP/IP Gateway for Novell networks (see Info-Kermit V9 #8).]

FTP Software recently announced INT 14 support for their PC/TCP product,
which supports many network boards.  I haven't had an opportunity to try it
with MS Kermit yet.

------------------------------

Date: Sat, 03 Jun 89 18:01:01 EDT
From: Peter Jones <[e-mail]>
Subject: Kermit for Navigator
Keywords: Navigator, Blind, Braille

Some time ago, I announced I would be interested in developing a KERMIT
system for the VBII terminal for the blind, an 8080-based braille
workstation. I have decided to abandon this project, as too much investment
would be required to support and debug an 8080 program in our environment.

Telesensory Systems Inc has announced a new device called the Navigator.
This is a PC-like system with braille I/O. As we use PC's at UQAM, support
would be available. I'm wondering if anyoune has tried Kermit on the
Navigator.  Would a special version be required?

Peter Jones     MAINT@UQAM     (514)-282-3542
"All's well that ends." :-)

------------------------------

Date: Fri, 21 Apr 89 09:16:59 MET
From: "Boelen, Lodewijk J.M." <[e-mail]>
Subject: Errors Compiling Amiga Kermit
Keywords: Amiga C-Kermit, Commodore Amiga

     Lectori Salutem

In December I have got both the sources and a BOO-ed version of Kermit on my
Amiga.  By curiosity I compiled the sources with the Lattice 3.10 compiler
to get acquainted with the software available on my new (second hand)
AMIGA2000.  I love that machine!

I remarked the following compiletime errors:
  1.there are many warnings 89 on the variables "pid" and "D7Save" and others;
  2. ckitio.c:
    .1 error 71: formal declaration error "m";
    .2 error 9: undefined identifier "m";
    .3 error 63: duplicate declaration of item "m";
  3. ckifio.c: error 57: semicolon expected;
  4. ckuus3.c: error 25: invalid macro usage.

The total time needed for compilation on my two-diskette machine, with an
adapted make-file, is 15 minutes.  On scanning the sources near the marked
lines I made some changes I will describe hereafter.  All the compiletime
errors were gone but the one in ckuus3.c.

To get a Kermit program I had to attack the BOO-ed version I guessed to be
in ckiker.upd.  When anyone is interested I will mail my critics and the way
I got a working Kermit program.  I could emulate a terminal, that's all.  I
called for HELP but got no responses on the sources problems.

So I waited for the newest version, announced in the meanwhile, hoping on
the errors to be corrected.  Before yesterday I compiled the newest sources
the first time.  I was sad to find the same errors as described above plus
one: the version of HEARN's ckucmd.c is cut off.  After receiving the
TUVMA-version and applying the corrections, yesterday I got in the same
situation as in January.  So now my second call for HELP!

Here are the corrections on the lines of the actual version:
  1. ckitio.c: all the errors are gone when you change line 692 from:
    "int n, m;" into: "int n;" and insert after line 695: "int m;";
  2. ckifio.c: a little above line 343 you can find: "return(...));". If you
    change this line in "return(...);" (one ")" less!) all is well.

I don't know C though it looks very nice, but also a colleague could not find
a solution on the error in ckuus3.c.

I wonder if the warnings are not harmful, but I don't know to correct them.

Can anyone help me? I would be grateful,

      Lodewijk.

[Ed. - To our knowledge, nobody has worked on the Amiga-specific portion of
C-Kermit since Steve Walton's contributions of January 1987, listed in
ckiker.upd.  If anyone out there has worked on upgrading C-Kermit's Amiga
support to the current version of C-Kermit -- or better still, the test
version 4F with file attribute packets -- please let us know!  Or if you are
willing to volunteer to take on the job, also please tell us.  Until then,
the best we can do is add Lodewijk's message to the ckiker.bwr file.]

------------------------------

End of Info-Kermit Digest
*************************

 5-Oct-89 21:59:39-GMT,19944;000000000001
Return-Path: <[e-mail]>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
    id AA05698; Thu, 5 Oct 89 17:59:35 EDT
Received: from watsun.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
    id AA11235; Thu, 5 Oct 89 17:58:48 EDT
Received: by watsun.cc.columbia.edu (4.0/SMI-4.0)
    id AA05686; Thu, 5 Oct 89 17:56:02 EDT
Date: Thu, 5 Oct 89 17:56:01 EDT
From: Christine M Gianone <[e-mail]>
To: [e-mail]
Subject: Info-Kermit Digest V10 #3
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Thu, 5 Oct 1989        Volume 10 : Number 3

Today's Topics:

           Kermit Distribution Moves from CUNIXC to WATSUN
      Announcing IBM Mainframe VM/CMS Kermit-370 Version 4.1.005
            New Test Release of Mac Kermit
      A Very Minor Re-release of MS-Kermit 2.32/A for the IBM PC
        Announcing a Minor Update to MS-Windows Kermit
            Announcing DECsystem-10 Kermit 3(134)
          Announcing a Version of CP/M Kermit for the HP-125
              New Version of Telcon Zorba Kermit
             Setup for Using CRISP with MS-Kermit
           Re: Mixing Things in MS-Kermit Key Definitions?
        Re: Mixing things in MS-Kermit 2.32/A Key Definitions
              Using Kermit on Ethernet?
          VT100 Terminal Emulation for the Heath89?


Digest submissions may be sent to [e-mail], requests
for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN, WATSUN.CC.COLUMBIA.EDU, a
SUN-4/280 running UNIX (SUNOS 4.0), IP host number 128.59,39.2.
128.59.40.130.  Login as user anonymous (note, lower case), any password, and
GET or MGET 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
kermit/a/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: Tue, 3 Oct 89 17:16:29 EDT
From: Christine M Gianone <[e-mail]>
Subject: Kermit Distribution Moves from CUNIXC to WATSUN
Keywords: CUNIXC, WATSUN, FTP, Kermit files, Info-Kermit, Info-Kermit-Request

As announced in Info-Kermit V9 #6 (April 1989), CUNIXC is being retired
from network service as a base for the Kermit files, and has been replaced
by WATSUN.CC.COLUMBIA.EDU, IP host number 128.59,39.2, which by now should
be well known to all Internet sites.  Watsun is the home of the Kermit
files, and contains the definitive copies of all the Kermit files.  It is
accessible via anonymous FTP, just as CUNIXC was.

------------------------------

Date: Wed, 1989 Sep 13   13:13 EDT
From: "John F. Chandler" <[e-mail]>
Subject: Announcing IBM Mainframe VM/CMS Kermit-370 Version 4.1.005
Keywords: IBM 370 Kermit, VM/CMS Kermit,
Xref: CMS Kermit, See VM/CMS Kermit
Xref: VM/XA Kermit, See VM/CMS Kermit
Xref: CMS/XA Kermit, See VM/CMS Kermit

This is to announce the release of Kermit-370 version 4.1.005 for CMS.  The
new version comes (for the first time) in two flavors, the new flavor being
CMS/XA.  The latter can be generated by obtaining the new file IKCXA UPD in
addition to the new version of IKCKER UPD and using the command VMFASM
KERMIT KERMXA instead of VMFASM KERMIT KERMIT.  The XA version will run
under CMS 5.5 under VM/XA SP 2 in either 370 or XA mode but will not run
under earlier releases of CMS.  Conversely, the standard version will run
under pre-5.5 CMS under either VM/SP or VM/XA but will not run under CMS
5.5.  This unfortunate dichotomy could be eliminated, but only by hard-
coding certain CMS macros and making extensive use of conditional assembly.

Version 4.1.005 has several improvements over 4.1.001:

 1. Certain situations causing VTAM to lock up a file transfer are now
    prevented.

 2. A bug introduced in 4.1.001, which prevented file transfers when the
    user had CP SET APL ON, has been corrected.

 3. Certain CP SET options which are not supported by VM/XA are now
    avoided by both flavors of Kermit when running under VM/XA.

 4. The tentative fix (SC89165) offered in IKCKER BWR for certain
    infinite waits on protocol-converter-type transfers has been
    definitely included.

 5. The common storage has been rearranged slightly to remain within
    the 4K addressibility limit.

 6. A new, separate error condition is recognized when Kermit-CMS
    receives a "packet" containing no start-of-packet character.  The
    old response was the somewhat misleading "Bad packet count or
    checksum."

 7. There is now provision for an accounting exit routine to be called
    after completion of each batch of SEND or RECEIVE.  A sample routine
    is available as IKCACT ASM and can be configured to punch cards, cut
    system accounting records, or write a disk file.  Since the exit
    routine is optional, you must explicitly load it with Kermit.

 8. Perhaps most interestingly, Kermit-CMS now recognizes a syntax for
    sending partial files by line numbers.  The syntax is

         SEND filespec<n-m>

    where "filespec" is any valid file specification, "n" is the first
    line to send, and "m" is the last.  There must be no blank between
    the file name and the "<".  Either "n" or "m" may be omitted (the
    default is the start or end of the file, respectively), and the
    hyphen may be left off as well if "m" is omitted.  The same syntax
    may be used in a GET request (or, in many cases, a REMOTE TYPE
    request) through a micro Kermit talking to a Kermit-CMS server.

Many thanks to the beta-testers, who put the new version through its
paces and helped in identifying weaknesses in the implementation.
Note: the TSO version of release 4.1.005 will be available soon.

[Ed. - Many thanks, John, for your continuing excellent and thorough work.
The new features are most welcome, and the support for XA will be good news
for many sites!  The new files are in the "B" area of Kermit Distribution,
kermit/b/ikc*.* on watsun for Internet access, and also available from
BITNET KERMSRV at CUVMA as IKC*.*.]

------------------------------

Date: Tue, 22 Aug 89 16:46:26 EDT
From: Paul Placeway <[e-mail]>
Subject: New Test Release of Mac Kermit
Keywords: Macintosh Kermit

New sources for Mac Kermit 0.98(62), compilable with the 4F(095) C-Kermit
files are now available, along with an up-to-date CKMKER.HQX file, which
can be decoded into the working Mac Kermit application using BinHex V4.

This version fixes the font assignment problems, makes mouse->arrow keys
work again, and does statistics on file transfer right.  It also is better
about keys when running under System 4.2 or better (specifically, it
disables dead-keys and doesn't strip off shifting when unmodifying keys).

                --Paul

[Ed. - Thanks Paul!  The new files have relaced the old ones in
kermit/test/ckm*.* on watsun, and in the T: area of BITNET KERMSRV on
CUVMA.  Please send reports and comments to Info-Kermit@watsun.]

------------------------------

Date: Thu, 14 Sep 89 21:17:39 EDT
From: "Joe R. Doupnik" <[e-mail]>
Subject: A Very Minor Re-release of MS-Kermit 2.32/A for the IBM PC
Keywords: MS-DOS Kermit 2.32/A

Release 2.32/A of MS Kermit had a bug when operated as a Server.  If the
current directory were the the root ("\") of a disk then it could not
receive files because the server added two backslashes before the name of
the incoming file, and issued an error message like "?Unable to create
\\FOO", rather than creating the file.  This problem is fixed in the
interim release file MSVIBM.BOO, for IBM-PCs only.  The running program
can be identified by the version banner double date of "21 Jan 1989/13
Sept 89."

Joe Doupnik (the guilty party).

[Ed. - Many thanks again, Joe!  The new MSVIBM.BOO file has been installed in
the "A" area of Kermit Distribution, and the MSKERM.BWR file has also been
updated.]

------------------------------

Date: Wed Sep 13 12:29:28 1989
From: Christine M. Gianone <[e-mail]>
Subject: Announcing a Minor Update to MS-Windows Kermit
Keywords: MS-Windows Kermit

>From Bill Hall of Santa Clara, CA, a new set of MS-Windows Kermit files.
The major change is that all the files have been named consistently, and
the makefile (winker.mak) adjusted accordingly.  There are also some minor
improvements to the dialog boxes, etc.  The new version is 4.10, and it
has been tested successfully under MS-Windows 2.03 on a PS/2.  The new
files, including a "boo" file of the executable program (which may be
converted back into an .EXE file using any of the MSBPCT programs), are in
the "A" area of Kermit Distribution, kermit/a/win*.* on watsun, and are
also available over BITNET from KERMSRV at CUVMA as WIN*.*.  Thanks to
Bill for sending in the new version.  Future releases are expected to have
some major additional features.

------------------------------

Date: Mon, 18 Sep 89 01:06:47 +0100
From: Dan Norstedt <[e-mail]>
Subject: Announcing DECsystem-10 Kermit 3(134)
Keywords: DECsystem-10 Kermit, Bliss Kermit, TOPS-10 Kermit, VAX/VMS Kermit

New features and changes in Kermit-10 3(134):

This version has added support for extended length packets -

      * Extended length packets are supported by the normal SET RECEIVE
        PACKET and SET SEND PACKET commands.  Sizes up to 1000 are allowed.
        By default, extended length packets are not used.  Typically, use
        SET RECEIVE PACKET 1000 and SET SEND PACKET 1000 to enable it.

It also contains bug fixes/enhancements from the VMS version -

      * CRC calulations works ok when sending 8 bit data not using quoting.

      * IBM mode handshake improved.

      * Don't lose last character in a buffer if it's a widow.

That's all, folks.  The updated files are:

        K10COM.REQ
        K10GLB.MAC
        K10MIT.MAC
        K10MSG.BLI
        K10MSG.MAC
        K10TT.MAC
        K10UNV.MAC

There are no new files, except this announcement.

The .MAC (Macro-10) files are generated from the Bliss sources, but they
will only work for KL and KS systems (our system is a KI).  But since KI's
are rare, and the previous version also was compiled only for KL/KS, I don't
think it's much of a problem.  The program has been put to heavy use here
over the last few months, and I believe it to be free of (at least) new
bugs.
                                        Regards,
                                        Dan Norstedt

[Ed. - Many thanks, Dan!  This will certainly be good news for the world's
remaining TOPS-10 users.  The new files are installed in Kermit
Distribution in the B area, kermit/b/k10*.* on watsun.cc.columbia.edu for
Internet access, and in K10*.* on KERMSRV at CUVMA for BITNET access.
Note that the system-independent Kermit protocol portions of this program
are supposed to share the same source files with VAX/VMS Kermit-32.
VAX/VMS users who have a Bliss-32 compiler are encouraged to get the new
files and see if a new version of Kermit-32 can be built from them, which
will give this orphaned program long packet support.]

------------------------------

Date: 30-Aug-89:08:08:48
From: [e-mail]
Subject: Announcing a Version of CP/M Kermit for the HP-125
Keywords: CP/M Kermit, HP-125

Sending you an Intel .HEX-formated version of the system-dependent part of
CP/M Kermit, Version 4.09, for the HP-125 Business Assistant computer running
HP's modified CP/M Version 2.2.  I suggest that it be called CPVHP1.TXT.  I
can also send the sources in separate messages if you wish.  Sorry it took so
long but other projects were pressing.

You may reach me by sending mail on Bitnet to [e-mail] with
the subject "dec10%bpa".  Cheers!

-- Mike Freeman, Bonneville Power Administration; P.O. Box 491; Vancouver,
WA 98666 Routine MORF (Telephone [phone]) --

[Ed. - Thanks, Mike!  The file has been installed as you suggest as
CPVHP1.TXT, and the source has been installed.]

------------------------------

Date: Fri,  1 Sep 89 12:17 PST
From: <MAILER@UWALOCKE>
Subject: New Version of Telcon Zorba Kermit
Keywords: Telcon Zorba Kermit

Sending a new version of the system-specific file CPVTEL.HEX which adapts
Kermit (version 4.09) for the Telcon Zorba.  This version allows the Zorba
to set various baud rates and to transmit a 300 ms break.  There is, of
course, also a version of the file cpxhea.asm which incorporates this
functionality for the Zorba.  CPVTEL.HEX, in Intel .HEX-format is being
sent.

I may be reached via E-mail via Bitnet at mailer@uwalocke.  Please make the
subject of messages <dec10%"bpa">.  Cheers!

-- Mike Freeman; 301 N.E. 107th Street; Vancouver, WA 98685;
Telephone (home) [phone], (work) [phone]. --

[Ed. - Thanks again Mike.  The old HEX file has been replaced with the new one
in ~kermit/a/cpvtel.hex.]

------------------------------

Date: 10 Sep 89 03:26:59 GMT
From: [e-mail]
Subject: Setup for Using CRISP with MS-Kermit
Keywords: MS-DOS Kermit, CRISP

Sending a shell archive containing files that can be used to allow the
crisp text editor to be used with MS-Kermit in vt102 mode.  To use it,
install mskermit.m in your crisp macros/tty directory and source
crisp.tak with MS-Kermit's "take" command.

I took the escape sequences almost verbatim from the tty/isc.m file,
then rebound MS-Kermit's keys to send them.  I didn't use MS-Kermit's
default vt102 bindings because, crisp being a clone of a DOS editor, it's
best to use the PC keyboard as such rather than awkwardly emulating a
DEC keyboard.

I welcome any improvements to these files; in particular, I don't have
color or an enhanced keyboard, so support for those is untested.
To use the keypad for crisp, you should probably put Num Lck on so you
don't have to use shift to go to the beginning of the line, etc.  Then
you access the MS-Kermit functions (scrolling the display memory) by
using shift.  There is no way to get the keypad to transmit plain old
numbers in this configuration.

[Ed. - Thanks.  The file is in ~kermit/a with the filename MSICSP.INI.]

------------------------------

Date: 14 Jun 1989 17:57-CDT
From: Jim Fregin <[e-mail]>
Subject: Re: Mixing Things in MS-Kermit Key Definitions?
Keywords: MS-DOS Kermit, Key Definitions, Kermit Verbs

Martin Kiff, in Info-Kermit Digest V9 #9, asked about mixing text with
MS-Kermit keyboard verbs.  His intent was to pad commands sent to the host
from a single keypress.  I have one solution to this.  Use the VT102
\KterminalS and \KterminalR verbs with the macros defined to output the
desired text and connect again.  The only drawback of this is that only 2 keys
could be defined in this manner.

This leads into a suggestion that I have for improvement of MS-Kermit.
Multiple keys could be defined in the above manner by allowing any defined
macro to be called from a single keypress in terminal mode.  (I.E. a macro
named PAD would be called by pressing a key defined as \Kpad.)  It sounds like
this overcomes the problem of parsing you spoke of in your reply to Martin
Kiff.

I would be EXTREMELY interested in this feature for calling macros and
subsequently executing several script files that I have written.

Jim Fregin

[Ed. - The forthcoming new release of MS-Kermit will allow \Kverbs to be
embedded in key definition strings, as in "set key \315 aaa\{Kgold}bbb",
and probably will also expand the number of macro names that can be
associated with keys.]

------------------------------

Date: Fri, 16 Jun 89 09:07:41 CDT
From: Fritz Keinert <[e-mail]>
Subject: Re: Mixing things in MS-Kermit 2.32/A Key Definitions
Keywords: MS-DOS Kermit, Key Definitions, Kermit Verbs

In Info-Kermit V9 #9, Martin Kiff asks about mixing text and Kermit action
verbs in a key definition. I ran into the same problem just two days ago.

The EDT editor on our VAX system uses combinations of function keys a lot. For
example, the "FIND" command is F1 F3. I tried to reassign this command to ^S,
like the EMACS editor I am used to, by saying

        set key \19   \Kgold\Kpf3

but that did not work. After many attempts, I found the solution: In section
1.17.2 of the Kermit documentation (line 5318), in the very right-hand column,
is a list of the actual characters transmitted by Kermit when these function
keys were pushed. For example, F1 = Esc O P. I then tried

        set key \19   \27OP\27OR

and that works fine. Even complicated things like F1 F5 "exit" shift-F6 (which
is the sequence to exit) work fine.  Assigning this to Alt-Z translates into

        set key \2348 \27OP\27Owexit\27OM

According to this, Martin's specific problem would be answered like this:
Instead of

        set key \316 \Klfarr\016T

try this

        set key \316 \27OD\016T

(This is assuming you use the VT-102 mode of Kermit). Good luck.

Fritz Keinert
Dept. of Mathematics
Iowa State University
Ames, IA 50011
[phone]
S1.FXK@ISUMVS

[Ed. - This is a good workaround until the next major release of MS-Kermit.]

------------------------------

Date: Thu, 11 May 89 13:32:16 IST
From: Reuven Weiss <[e-mail]>
Subject: Using Kermit on Ethernet?
Keywords: Ethernet, MS-DOS Kermit Network Support, TCP/IP

I would like to use the Kermit interface (scripts, key redefinitions, etc.)
while connected from a PC to a host by TELNET.  Our campus has many RS232
terminals where we use Kermit 2.32/A on PC's and the various Kermit programs
on CDC, VAX and IBM hosts.  We also have a LAN under TCP/IP protocol.  The
LAN connects to the same hosts and to many PC's.  On the PC's we use 3COM
3C501 and WD8003E cards and NCSA 2.2 program (for TELNET and FTP).
Instructing users would be easier if the two programs (KERMIT and NCSA)
would have similar user interface, where it is possible.  There is much
similarity in terminal emulation and KERMIT works now also with LAN (NETBIOS
and U-B).  Perhaps KERMIT can evolve to TCP/IP emulation? I would like to
read comments from Kermit users.

Reuven Weiss
Faculty of Engineering
Tel - Aviv  University
[e-mail] (a VAX/VMS site) or
[e-mail] (an IBM/VM site)

[Ed. - There are no plans at present to have MS-DOS Kermit include explicit
support for various Ethernet boards or for Telnet protocol.  However, Kermit
can be used in this environment if your TCP/IP implementation includes a
Bios Int14h COM1 interceptor.  An example is the Interlan TCP/IP gateway for
Novell (SET PORT BIOS1 in MS-Kermit).  See the message from Jim Gogan in
Info-Kermit V9 #8.]

------------------------------

Date: Wed, 10 May 89 19:41:25 EDT
From: [e-mail]
Subject: VT100 Terminal Emulation for the Heath89?
Keywords: Terminal Emulation, Heath89, CP/M Kermit

Has anyone configured kermit for the Heath89 (cpm 2.2) to look like a VT100
to an IBM 7171 protocal converter?  I would have great difficulty trying to
assemble a revision on my small machine.  Thanks in advance.

Rich Sandy
SANDY AT OUACCVMB.BITNET

[Ed. - To our knowledge, no one has ever written code to do this.  The only
hope would be if the H89 included Heath-19 terminal firmware, which is
capable to some extent of using the same ANSI escape sequences as the VT100.]

------------------------------

End of Info-Kermit Digest
*************************



 7-Nov-89  0:24:39-GMT,26407;000000000001
Return-Path: <[e-mail]>
Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (5.59/FCB)
    id AA06601; Mon, 6 Nov 89 19:24:36 EST
Received: from watsun.cc.columbia.edu by cunixc.cc.columbia.edu (5.59/FCB)
    id AA09219; Mon, 6 Nov 89 19:21:56 EST
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA06546; Mon, 6 Nov 89 19:20:10 EST
Sender: Frank da Cruz <[e-mail]>
Date: Mon, 6 Nov 89 19:20:09 EST
From: Christine M Gianone <[e-mail]>
To: [e-mail]
Subject: Info-Kermit Digest V10 #4
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Mon, 6 Nov 1989        Volume 10 : Number 4

Departments:

  ANNOUNCEMENTS -
        Announcing IBM Mainframe MVS/TSO Kermit-370 Version 4.1.005
        Announcing Apple II Kermit Version 3.86
        Announcing Kermit-12 Version 10f
        Minor Release of Commodore Kermit

  KERMIT PROTOCOL -
        Proposed Modification to "Set Warning"

  MOS-DOS KERMIT -
        MS-DOS Printer Drivers Needed
        MS-DOS Kermit Losing Characters at 19200 bps
        MS-DOS Kermit Losing Characters with KEYB Drivers

  MISCELLANY -
        Kermit over Ethernet
        Kermit File Transfers on DECstation 3100
        Problems with Kermit for the DECsystem-10
        DECsystem-10 Kermit Macro Source Problem
        Kermit Bootstrapping

Digest submissions may be sent to [e-mail], requests
for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN, WATSUN.CC.COLUMBIA.EDU, a
SUN-4/280 running UNIX (SUNOS 4.0), IP host number 128.59,39.2.
128.59.40.130.  Login as user anonymous (note, lower case), any password, and
GET or MGET 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
kermit/a/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, 1989 Oct 11   20:44 EDT
From: "John F. Chandler"   <[e-mail]>
Subject: Announcing IBM Mainframe MVS/TSO Kermit-370 Version 4.1.005
Keywords: IBM 370 Kermit, MVS/TSO Kermit, TSO Kermit

This is to announce the release of Kermit-370 version 4.1.005 for TSO.
This version is comparable to the recently released 4.1.005 for CMS.
Version 4.1.005 has several improvements over 4.1.004.

 1. The common storage has been rearranged slightly to remain within
    the 4K addressibility limit.

 2. A new, separate error condition is recognized when Kermit-TSO
    receives a "packet" containing no start-of-packet character.  The
    old response was the somewhat misleading "Bad packet count or
    checksum."

 3. There is now provision for an accounting exit routine to be called
    after completion of each batch of SEND or RECEIVE.  A sample routine
    is available as IKCACT ASM (for CMS) and may be adapted to specific
    needs.  Since the exit routine is optional, you must explicitly load
    it with Kermit in the linkage editor.  The appropriate JCL has been
    added to (but commented out) the installation job in IKTKER.INS.

 4. The installation batch job has also been updated to include the REUS
    option on the LKED step, so that TTY-mode timeouts will work on
    MVS/XA systems.  Also, conditional execution is now specified on the
    assembly and link-editing steps to minimize the repercussions of any
    errors in setting up the job.

 5. Perhaps most interestingly, Kermit-TSO now recognizes a syntax for
    sending partial files by line numbers.  The syntax is

         SEND filespec<n-m>

    where "filespec" is any valid file specification, "n" is the first
    line to send, and "m" is the last.  There must be no blank between
    the file name and the "<".  Either "n" or "m" may be omitted (the
    default is the start or end of the file, respectively), and the
    hyphen may be left off as well if "m" is omitted.  The same syntax
    may be used in a GET request (or, in many cases, a REMOTE TYPE
    request) through a micro Kermit talking to a Kermit-TSO server.

Many thanks to the beta-testers, who put the new version through its
paces and helped in identifying weaknesses in the implementation.
There are two updates that were not included in this release because
of inconclusive test results.  The first was designed to correct the
problem of Kermit failing to executed a migrated KERMINI file, and
the second to enable Kermit to recognize dataset modification dates
maintained by the ASM2 package.  Anyone interested in testing these
should send a note to John Chandler <[e-mail]>.

[Ed. - And many thanks to you, John!  The new files are installed in
the Kermit Distribution "B" area, kermit/b/ikt* on watsun for
anonymous ftp access, and on KERMSRV@CUVMA as IKT* * for BITNET access.]

------------------------------

Date: Tue Oct 31 19:04:55 1989
From: Christine M Gianone <[e-mail]>
Subject: Announcing Apple II Kermit Version 3.86
Keywords: Apple II Kermit 3.86, ProDOS

This is to announce Apple II Kermit Version 3.86 for Apple II DOS and ProDOS,
which replaces version 3.85 of January 1989, from Ted Medin,
[e-mail].  The major changes include:

   1. ProDos QUIT is fixed
   2. VT-100 emulation bug fixes
   3. The program now works on the Apple//c+ now works
   4. Blinking cursor when connected
   5. Connect escape menu now has MODEM and QUIT added
   6. Better handling of illegal characters in received filenames
   7. Wildcard file transfer SEND no longer misses files
   8. New installation procedure
   9. New Apple Cat serial card driver
  10. New file management commands LOCK, UNLOCK, and RENAME added
  11. GET & SEND commands now allow two filespecs so one can change the name
  12. Revised documentation, available in both ASCII and Postcript form

The changes are listed in more detail in the file APPAAA.NEW, along with
credits to those who supplied new code, reported bugs, and so forth, including
Ralph Carpenter, Les Ferch, Steve Kunz, Klaus Schnathmeier, and Dick Wotiz.

The new files are in app*.* in the various Kermit Distribution "A" areas, and
can be ordered on Kermit Tape A.  Many thanks to Ted for his continued efforts
in developing and supporting this program.

------------------------------

Date: 05-October-1989
From: [e-mail] (Charles Lasner)
Subject: Announcing Kermit-12 Version 10f
Keywords: PDP-8, PDP-12, VT-78, VT-278, DECmate, OS/8
Xref: DEC PDP, See PDP

This is to announce the release and availability of a highly revamped KERMIT
program for the complete family of Digital Equipment Corporation 12-bit
computers, known as KERMIT-12 (or K12MIT), Ver.  10f.  Unlike its
predecessors (K08MIT and K278, upon which it is partially based, as well as
prior versions of KERMIT-12), KERMIT-12, as now distributed, will run on any
PDP-8 model (8, Linc-8, 8/i, 8/l, 8/e, 8/f, 8/m, 8/a), PDP-12, VT-78, or
DECmate (VT-278, aka DECmate I, DECmate II, DECmate III, DECmate III-plus)
under any OS/8 family member operating system.  Proper operation is
accomplished automatically.  Companion utilities are provided to deal with
"ASCII-fied" binary files in ENCODE format (a mechanism designed by Charles
Lasner and Frank da Cruz as a proposed successor to BOO format); ENCODE
format has been employed to distribute the binary portion of this release of
KERMIT-12.

Due to the myriad port requirements of the various models, conditional
parameters have been provided in the source (as well as a separate patching
file) for models prior to DECmate I.  The program auto-configures for all
models of DECmate; parameters are available to select the DECmate ports
(DP278, communications, printer, etc.)  where applicable.

Many improvements have been provided to get this KERMIT "up to speed"
relative to other KERMITs.  KERMIT-12 has been tested successfully with many
KERMIT implementations and will run at the maximum baud rate (and sometimes
beyond the DEC-stated limit!) of the relevant interface.  Any console
terminal configuration acceptable to OS/8, etc. can be used at any baud rate
as long as local flow-control protocol is obeyed; remote flow control can be
disabled at console speeds higher than the remote line rate.  Connect mode
I/O is fully ring-buffered in all directions with local flow control always
enabled for all console terminal operations.  (This should satisfy all
console terminal requirements ranging from 110-baud teletypes to built-in
350-Kbaud VT-220 emulators, since any of the gamut of these ASCII terminals
could be the system console terminal for any of the KERMIT-12 supported
computer configurations!).

KERMIT-12 will run anywhere OS/8 does, so it runs on any perfect look-alike
suitably configured.  Some known compatibles are:

 - TPA made in Hungary, this machine is an 8/l except for the silkscreened
   letters which are Magyar, not English.
 - Fabritek MP-12
 - Intersil Intercept
 - Pacific CyberMetrix PCM-12
 - Digital Computer Controls DCC-112 and DCC-112H
 - Computer Extensions CPU-8 (a drop-in replacement for the 8/e or 8/a cpu
   for a PDP-8/A-400 or -600 hex-wide box)
 - Computer Extensions SBC-8 (a single-board computer -8 compatible based
   on the 6120 like a DECmate, but compatible with -8 peripherals, not
   DECmate peripherals; it also supports up to 16 comm ports)

Various emulators are available for PDP-10, 15 and the IBM-PC which will
also support KERMIT-12 if suitably configured.

Distribution files are available from CUCCA.  Testing is under way for some
of the more obscure configurations (e.g., DECmate III with comm port);
volunteers are welcome for this task.  The author can provide copies to
interested parties on virtually all of the popular PDP-8 media on a
time-available basis.

[Ed. - Many thanks, Charles!  The files are in Kermit Distribution area D
with prefix K12, and the previous PDP-8 versions having prefixes K08 and
K278 have been retired.  Internet users may ftp the files as kermit/d/k12*,
and BITNET users can get them from KERMSRV at CUVMA as K12* *.]

------------------------------

Date: Thu, 10 Aug 89 17:47:01 EST
From: [e-mail] (Ray Moody)
Subject: Minor Release of Commodore Kermit
Keywords: Commodore 64 Kermit

Commodore Kermit has been upgraded from version 2.2(70) to 2.2(73).  We have
decided to only increment the minor revision number because we have only
changed three bytes!  One byte fixes a bug in the parser that caused it to
claim that a valid command was unrecognizable when ESC was pushed.  Another
byte fixes a timing problem where some C64s would not be able to operate
with some 1200 baud modems.  (And, of course, this bug never happens on a
C128 running in C64 compatibility mode, which I used to test things.  Sigh).
The third byte changes the minor revision number to 73.

If you have Commodore Kermit 2.2(70), you can upgrade without downloading
anything as follows:

    1. Turn on/reset machine (into C-64 mode if on a C-128).

    2. Type: LOAD "KERMIT",8

    3. Type: POKE 3393,32
             POKE 19930,51
             POKE 26539,29

    4. Type: SAVE "@0:KERMIT",8

Ray

[Ed. - Thanks Ray.  The updated source and hex files have now replaced the
old ones in the Kermit Distribution "A" areas on watsun and CUVMA.
Commodore 64/128 Kermit files are prefixed as C64*.*.]

------------------------------

Date: Thu, 12 Oct 89 16:07:38 -0500
From: Gregg Wonderly <[e-mail]>
Subject: Proposed Modification to "Set Warning"
Keywords: Kermit Protocol, WARNING

I would like to propose that the "set warning" command be phased out in
favor of a new set of commands, namely the commands:

        set file exists replace
        set file exists rename
        set file exists skip
        set file exists ask

These commands would be added to kermit implementations wishing to have all
of these features.  The first two eliminate the need for "set file warning"
(which is not really a warning).

The behavior of the first two are equivalent to "set file warning off" and
"set file warning on" respectively.  The second two would extend KERMIT in
the following way.

When "set file exists skip" is in effect, the KERMIT requesting a file via a
GET or RECEIVE would answer the "F" packet with an "X" packet when the file
specified in the "F" packet already exists on the requesting machine.  It
would then move to a state which would ignore subsequent "D" packets thus
throwing away the file if the sending KERMIT did not understand "file
cancel" (the worse case which would only happen in very limited KERMITS).
This would allow a GET command involving wild cards to be restarted at the
point that it failed due to transmission failures.

When "set file exists ask" is in effect, the above behavior is controlled by
the answer to a prompt that is issued to the user.  A positive
acknowledgement (perhaps just pressing the y key or y and return) would
cause the file to be transfered, and negative acknowledgement from the user
would cause the file to be "skipped".  Of course the prompt could ask the
question in such a way as to reverse this logic.

I have implemented this in C-Kermit with no real problems.  It comes in very
handy for the case that I described above with wild cards.

Comments?

[e-mail]  (AT&T Bell Laboratories, or ihlpb!gregg)

[Ed. - Good ideas, Gregg.  We've actually been considering adding them, in
some form, to the protocol for some time.  In fact, you may have noticed
something called SET FILE SUPERSEDE in the Kermit book.  But better to combine
all this behavior within a single SET FILE command as you suggest.  Look for a
proposal in the next Info-Kermit.]

------------------------------

Date: Mon Nov  6 16:12:36 1989
From: Christine M Gianone <[e-mail]>
Subject: MS-DOS Printer Drivers Needed
Keywords: MS-DOS Kermit Printer Support

For inclusion with MS-DOS Kermit 3.0, to be announced for beta testing
within about a month, we need public domain (or copyright but freely
sharable, like Kermit itself) printer drivers:

 - A serial printer driver that does Xon/Xoff flow control with the printer.

 - Graphics printer drivers that will reproduce Kermit's Tektronix
   graphics screens on various kinds of printers (we currently have
   one of these, for the EGA/Epson combination).

 - Text printer drivers that convert between IBM PC special characters in
   various code pages (particularly the European accented vowels, etc) and
   the character sets of various printers (like Epson, etc).

If you have any programs like this and can contribute them in source-code
form, please contact me directly.  Thank you.

------------------------------

Date: Friday, 17 February 1989  04:33-MST
From: enea!kullmar!pkmab![e-mail] (Kristoffer Eriksson)
Subject: MS-DOS Kermit Losing Characters at 19200 bps
Keywords: MS-DOS Kermit Performance

In article <[e-mail]>, [e-mail]
(Clarence Dold) writes:
> From article <[e-mail]>, by [e-mail] (Kristoffer Eriksson):
>> When I use MS-kermit (ver 2.3*) at 19200 bps on an ALR 386/220 or at
>> 9600 bps on a Compaq Deskpro 286, and type anything at the same time
>> as I receive something, kermit beeps at me and loses received characters.
>
> If you are running UNIX, make sure that stty -a returns ixon ixoff -ixany.
> The default on our systems is -ixoff ixany, the result being that
> when Kermit gives an XOFF, your next keystroke is seen as IXANY, and turns
> the flow back on.

My principal use of MS-Kermit is indeed for connecting to UNIX systems. And
indeed I usually use ixon -ixoff ixany. But I've tried your advice now, and it
didn't help at all.

I made some more extensive tests, and found that Kermit starts beeping and
losing characters almost immediately when I type anything while output is
going on to the screen, but starts emitting xoff's much later. (I do have flow
control set to xon/xoff in Kermit.)

I even lose characters when there are less-than-one-line bursts of output
with pauses in between (and I type heavily), in which case Kermit couldn't
possibly need flow control.

The problem occurs when I use 19200baud on a 24 * 80 screen.  It also occurs
when I use kermit at 9600 on a 24 * 132 screen.

In Tektronix mode, no UART overruns occur, indicating that Kermit can handle
these high speeds with flow control.

My diagnosis was more or less confirmed when I tried to use Procomm 2.4.2.
Same problem there.

Casper H.S. Dik
University of Amsterdam     |                 [e-mail]
The Netherlands             |                 ...!uunet!mcvax!uva!dik

[From jrd - The real problem is the keyboard code in the Bios (plus any
interceptors) which is turning off interrupts far too long on each
keystroke.  Look for electronic keyclickers and shut them off completely. My
early model DELL 310 has such and loses characters.  The beep is my
indication that one or more characters have arrived at the serial port with
none being removed, an overrun condition; beep replaces the lost
character(s). With key clicking off there is no problem operating at very
high speeds (> 38400 baud).]

------------------------------

Date: Tuesday, 21 February 1989  14:57-MST
From: mcvax!kth!enea!kullmar!pkmab![e-mail] (Kristoffer Eriksson)
Subject: MS-DOS Kermit Losing Characters with KEYB Drivers
Keywords: MS-DOS KEYB Drivers

I have discovered that this character-loss problem occurs when I use a KEYB
to remap the keyboard layout for our national requirements.  When I use
plain US keyboard layout, Kermit doesn't beep, and doesn't lose characters.

I usually use the Swedish layout (obviously because I live in Sweden, and
have Swedish key-caps).  The command is KEYB SV (except for directory
names), and I use MSDOS 3.30.  I've also tried the UK layout.  It had the
same problem.  The US layout on the other hand, works fine, and it doesn't
matter how I get to it. I can switch to it by hitting CTRL-ALT-F1, or load
it with the command KEYB US, och just not load the Swedish layout.

Does anyone know why KEYB has this undesirable effect?

I still think that not even all users that do use KEYB have this problem.
Why? Are they just fortunate enough to have a 16550 on their serial port?
(That is not likely, I think.)

Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden
Phone: [phone]   !  e-mail: [e-mail]
Fax:   [phone]   !  or      ...{uunet,mcvax}!enea!kullmar!pkmab!ske

[From jrd - Yes, the keyboard helpers of DOS have code which turns off
interrupts for very long intervals, for each keystroke. The effect has been
noted in a number of countries.  Reports from the UK indicate that some
vendors are providing improved helpers which eliminate the problem.  There is
no clear reason why that code needs to turn off interrupts at all, and the
same code has probably been used in all the CodePage keyboard routines.]

[Ed. - There must be something different between the USA and Sweden.  If we
give the DOS command KEYB SV,850 on US-model PC/ATs or PS/2s running DOS
3.30, Kermit 2.32/A works perfectly.  So perhaps Swedish DOS is not the same
as USA DOS???]

------------------------------

Date: Fri, 6 Oct 89 11:33 EDT
From: "Vivek Khindria HSC-2D2 x2676 C.S.U." <[e-mail]>
Subject: Kermit over Ethernet
Keywords: Ethernet, MS-DOS Kermit Network Support

We use a package from Beame and Whiteside (Canadian) that allows serial
communication to be redirected across Ethernet via TCP/IP.  One version
works with any serial communication package.  But you need to put a loopback
plug on the serial port.  The other version of this software works the
communication packages that use INT14.  The workstation need not even have a
serial port.

The program will respond to all HAYES commands...ATH...ATZ etc..  We are
very happy with this package.  If you need more info send me an email note.

Vivek [e-mail]
Faculty of Health Sciences
McMaster University
Hamilton, Ontario Canada

------------------------------

Date: 1 Sep 89 18:39:14 GMT
From: [e-mail] (Ravindran Ramachandran)
Subject: Kermit File Transfers on DECstation 3100
Keywords: C-Kermit for DECstation 3100, DECstation

Has anyone got C-Kermit running on a DecStation 3100, and been able to send
very large files from a PC connected to a DecServer port?  Or even a Mac on
the DecServer line?  I've been struggling with it for a while now. I'm able
to send to my VMS machine without any trouble, but the RISC/ULTRIX combination
keeps getting timed out.  I used the Kermit from Columbia, and did a 'make
bsd' to get my executables.

I am able to send files from my DecStations to the PC, but not the reverse.
Could this be because the RISC machines are much faster? Is there any way
to control this? The message that I get when it times out is,
Unable to receive an acknowledgment from the host

 -- Ravi.

[Ed. - The problem is most likely in your DECserver.  You may have to
configure it so that its input and output buffers are BOTH big enough to
hold the largest Kermit packets you are trying to send.  100 would be a good
number, use a bigger number if you are using long packets.  You should also
try to vary the flow control settings (Xon/Xoff -- turn it off if it is on,
or vice versa).  Most people have reported success with C-Kermit on the new
DECstations, but that has been with the new, as-yet-unreleased version that
you can find in ~kermit/test on watsun.]

------------------------------

Date: 09/26 23:57:35
From: Mike Freeman
Subject:  Problems with Kermit for the DECsystem-10
Keywords: DECsystem-10 Kermit

PROBLEM:
    .SET WATCH FILES

    .R KERMIT

    [FL21: DSKD0:KERMIT.INI[5,34]]
    [FL21: DSKE0:KERMIT.INI[10,50]]
    ?
    ?Illegal UUO at user PC 434262
    .
DIAGNOSIS:  The fix in K10MIT.BWR for the problem encountered when TAKEing
files after INI:KERMIT.INI has been read but no KERMIT.INI exists in the
user's PPN caused Kermit to become confused when a KERMIT.INI
*did* exist in the user's PPN after INI:KERMIT.INI had been read.

CURE:  (see K10MIT.BWR)

PROBLEM: When Parity is set to None and the Block-check-type is set to
3-Character-CRC-CCITT, binary file transfers between Kermit-10 and Kermit
running on microcomputers either fail or are incorrect.

DIAGNOSIS: In the module K10MSG.BLI, in the routine CALC_BLOCK_CHECK which
calculates the block-check for a character-string, in the code for THE case
in which the 3-Character-CRC-CCITT is used, there is an IF-clause which
specifies the circumstances in which only seven bits of each eight-bit
character are to be used in the Block-check calculation.  As distributed,
high-order bits of characters are to be ignored when Parity None is in
effect.  This is incorrect.  The high-order bit of each character should be
ignored when Parity is set to anything but None.

CURE:  In the module K10MSG.BLI, in the routine CALC_BLOCK_CHECK,
in the 3-Character case, change the EQL in the IF-clause to a
NEQ.  (see K10MIT.BWR)

Please return mail to me via <[e-mail]>
with the subject "dec10%bpa".

Mike Freeman, Bonneville Power Administration
Vancouver WA, Telephone [phone]

[Ed. - Thanks, Mike.  The full text of your message, and the FILCOMs (diffs)
have been added to the file K10MIT.BWR in the Kermit Distribution "B" areas.]

------------------------------

Date:     Thu, 12 Oct 89  09:58:59  EDT
From: "C. BACON" <[e-mail]>
Subject:  DECsystem-10 Kermit Macro Source Problem
Keywords: DECsystem-10 Kermit

At some point, K10MIT.MAC apparently went through a filter someplace which
wrapped lines to about 80 characters, apparently always at a "grammatically
acceptable" character position, like a space or punctuation.  The result was
a field day for MACRO-10's error reporter.

A very few of these wraps were of strings which didn't raise an error,
including at least one "(-1)" which was at the end of a macro invocation.

I can easily find all those which raised assembler errors, but I don't know
about some which might not.

The funny part is that I have discovered some lines > 80 characters long; I
wonder if they were added after the wrap disaster.  If so, that would
suggest modifications to the code were made without the result being
completely recompiled!!

Of course I thank everyone concerned, yourself, Dan Norstedt, and the Kermit
project at CUCCA, for helping us keep the DECsystem-10 people happy.  More
later...  If I can get K10 built, should I send K10MIT.MAC and any others
which appear to have been similarly wrapped?  Of course I'll send them by
Unix mail, not Bitnet!

Chuck Bacon, aka CRB@NIHCUDEC or [e-mail]

[Ed. - Chuck, by all means try to put together a working version.  Also,
note the message immediately above.]

------------------------------

Date: Wed, 11 Oct 89 17:44:47 GMT
From: kodak!ektools!kadsma![e-mail] (Bill Fuller)
Subject: Kermit Bootstrapping

I have been told that there is a small program that you can type in on a
system that will allow you to asynch over a full version of Kermit.  Has
anyone heard of this micro-kermit code?  If so, does anyone know where I
could get it?  Thanks in advance,

Bill Fuller

[Ed. - The Kermit book, pp.186-188, lists a "baby Kermit" program in BASIC
for the IBM PC, which you can type in.  For raw capture without protocol,
you can use methods that are listed or described in many places, depending
upon what kind of computer you have.  For example, the procedure for CP/M
is given in detail in the CP/M Kermit User Guide.]

------------------------------

End of Info-Kermit Digest
*************************
From cmg  Thu Jan  4 18:25:07 1990
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA03603; Thu, 4 Jan 90 18:25:07 EST
Date: Thu, 4 Jan 90 18:25:06 EST
From: Christine M Gianone <[e-mail]>
To: info-kermit
Subject: Info-Kermit Digest V11 #1
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Thu, 4 Jan 1990        Volume 11 : Number 1

   PROPOSALS FOR KERMIT PROTOCOL ADDITIONS -

        Proposal for Kermit SET FILE COLLISION Command
        Proposal for Kermit SET ATTRIBUTE Command
        Proposal for REMOTE SET Extension to the Kermit Protocol

Digest submissions may be sent to [e-mail], requests
for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN, WATSUN.CC.COLUMBIA.EDU, a
SUN-4/280 running UNIX (SUNOS 4.0), IP host number 128.59,39.2.
128.59.40.130.  Login as user anonymous (note, lower case), any password, and
GET or MGET 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
kermit/a/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, 11 Dec 89 19:15:07 EST
>From: Christine M Gianone <[e-mail]>
Subject: Kermit Protocol Additions
Keywords: Kermit Protocol

This issue of the Info-Kermit Digest contains several proposals for extending
the Kermit protocol in certain minor ways, all of them related.  These
discussions are for Kermit developers.  They assume familiarity with the
Kermit protocol, as described in "Kermit, A File Transfer Protocol", by Frank
da Cruz, Digital Press (1987).

------------------------------

Date: Mon, 11 Dec 89 19:15:07 EST
>From: Christine M Gianone <[e-mail]>
Subject: Proposal for Kermit SET FILE COLLISION Command
Keywords: Kermit Protocol, SET FILE Command

PROBLEM:

As pointed out by Gregg Wonderly in Info-Kermit V10 #4, as well as by John
Chandler (author of Kermit-370) and many others previously, Kermit's SET
WARNING (sometimes also known as SET FILE WARNING) command is misnamed and
furthermore does not allow for certain desirable kinds of behavior when a file
arrives which has the same name as an existing file.

SOLUTION:

A new command to replace the old SET [FILE] WARNING command (or which can
coexist with it): SET FILE COLLISION, similar to the SET FILE EXISTS command
which was proposed by Gregg.  The name was changed for grammar's sake, several
additional options are suggested, and their behavior described somewhat
differently:

SET FILE COLLISION REPLACE: Destroy the previously existing file, replace it
    with the new copy (the current behavior of SET WARNING OFF).

SET FILE COLLISION RENAME: Give the incoming file a new, unique name so that
    it won't overwrite any existing files (like SET WARNING ON).  This would
    be the default behavior.

SET FILE COLLISION BACKUP: Give the existing file a new, unique name, using
    the same algorithm that is used on the arriving file by SET FILE COLLISION
    RENAME, and then accept the incoming file under its own name.

SET FILE COLLISION DISCARD: Reject any incoming file that has the same name as
    an existing file using (a) the attribute refusal mechanism ("N" in the
    data field of the ACK to the Attribute packet) if the use of attribute
    packets was negotiated, (b) by putting an "X" in the data field of
    acknowledgements to any Data packets that arrive to request cancellation
    of the file.  Always use method (b), even if also using method (a), in
    order to get on to the next file as quickly as possible.  In case the
    sending Kermit does not understand either of these signals and the file
    continues to arrive, do not open a new file and simply acknowledge and
    discard all data packets up to the end of the file.

    As Gregg pointed out, the DISCARD option will be handy for resuming
    transfer of a file group that had been interrupted.  This gives us a cheap
    version of checkpointing.  A more general and protocol-driven
    checkpointing mechanism will be proposed in the future.

SET FILE COLLISION APPEND: Append an arriving file to an existing file
    that has the same name.  The resulting file keeps the same
    system-dependent characteristics it had before, except that the date is
    changed.  This option should be used with caution, since it opens the
    door to creating files of mixed types (e.g. a text file appended to a
    binary file, a spreadsheet appeneded to a database, etc).  Old versions
    of IBM mainframe Kermit operated in this way.

SET FILE COLLISION ASK: Ask the user whether to replace, rename, discard,
    or append each arriving file that has the same name as an existing file.
    This option, too, should be used with caution because the file transfer
    could time out if the user takes too long to answer the query.  There are
    also user-interface issues: what happens to the active file transfer
    display, etc.  Macintosh Kermit currently supports this in the form of
    of "attended file transfer mode".

When the REPLACE and BACKUP options are in effect, a question arises
(originally posed by John Chandler).  Should the receiving Kermit create the
new file using its current file settings (SET FILE TYPE, etc), or should the
new file inherit the characteristics of the existing file, like protection,
blocksize, record format, etc, on systems where files have such things (IBM
mainframes, VAX/VMS, etc)?  There should also be a command to let the user
specify this:

SET FILE REPLACE {PRESERVE, DEFAULT}

where PRESERVE would create the new file with the same characteristics as the
old one, and DEFAULT would use the current file settings of the receiving
Kermit program and the host operating system when creating the new file.

The setting of SET FILE COLLISION will have an effect (as FILE WARNING does
now) upon the receiving Kermit's handling of the file size attribute as
reported in the incoming Attribute packet.  If the REPLACE option is in force,
then the existing file's size must be added to the available space before
deciding whether to accept or refuse the file on the basis of space.

This new command involves no new protocol.  Its operation is strictly local
to the receiving Kermit program, and gives the user added control over its
behavior when receiving files.

------------------------------

Date: Mon, 11 Dec 89 19:15:07 EST
>From: Christine M Gianone <[e-mail]>
Subject: Proposal for Kermit SET ATTRIBUTE Command
Keywords: Kermit Protocol, SET ATTRIBUTE Command

PROBLEM:

As the use of File Attribute (A) packets within Kermit programs grows more
widespread, it is becoming apparent that the user needs to have more control
over this feature.  Currently, most Kermit programs that support attribute
packets have a command SET ATTRIBUTES {ON, OFF}, so that if one or more
attributes is causing problems on the receiving computer, the sender can be
commanded not to send any attributes at all and the receiver can be told to
ignore all incoming attributes.

For example, suppose both the sender and receiver programs support the file
creation date attribute, and the receiver sets the arriving file's date from
it.  On some computers, incremental backups work according the file date and
so files that are received by Kermit won't be backed up.  If the user gives
the SET ATTRIBUTES OFF command, then the current date will be used when
creating the incoming file, but other useful attributes like file size will be
absent or ignored.  In this case, the receiving Kermit will not be able to
reject an arriving file in advance if it would be too big to fit on the
available storage.

You should not have to sacrifice all file attributes if only one of them is
causing problems.  Furthermore, it is possible to imagine situations in which
you want a certain attribute to be effective when sending a file but not when
receiving, or vice-versa.  For example, suppose the date attribute works
correctly when receiving a file, but when sending a file it causes the other
Kermit program to crash because of a bug.  In this case, you need a way of
telling your Kermit program to not to send the date attribute, but still
continue to handle for incoming files.

SOLUTION:

A new command, SET ATTRIBUTE <name> {IN, OUT} {ON, OFF}.  The <name> is the
name of any Kermit attribute as listed on pp.272-279 of the Kermit book, or
else the word ALL to mean all attributes.  IN OFF means that the attribute
should be ignored if it appears in an incoming File Attribute packet.  OUT OFF
means that the named attribute should not be included in any File Attribute
packets which are sent.  IN ON and OUT ON are used to enable the named
incoming or outbound attributes.  If you specify ALL OFF, then the Kermit
program should not set Attribute bit in the capabilities field of its
Send-Init packet (equivalent to the current command SET ATTRIBUTES OFF).
Examples:

  Command                      Meaning

  SET ATTRIBUTE LENGTH IN OFF  Ignore incoming length attributes
  SET ATTRIBUTE DATE OUT OFF   Omit date from outbound attributes
  SET ATTRIBUTE DATE OUT ON    Include date from outbound attributes
  SET ATTRIBUTE ALL OUT OFF    Don't send any attributes
  SET ATTRIBUTE ALL IN OFF     Ignore all incoming attributes

This new command is completely self-contained within each Kermit program.
There is no additional protocol between the two Kermit programs.

Thanks to John Chandler and Joe Doupnik for advice and suggestions on these
new commands.

------------------------------

Date: Mon, 11 Dec 89 19:15:07 EST
>From: Christine M Gianone <[e-mail]>
Subject: Proposal for REMOTE SET Extension to the Kermit Protocol
Keywords: Kermit Protocol, REMOTE SET Command

PROBLEM:

Certain Kermit programs (including MS-Kermit 3.0, C-Kermit 4F) include
information about whether a file is text or binary in the File Attribute
packet, so the receiver can put itself into the right mode automatically.  But
when talking to a server there is no way for the client program, before
issuing a GET command, to tell the server whether to send the file in text or
binary mode.  This problem extends to various other protocol and file-related
parameters.

NOTE:

The Kermit protocol definition includes a REMOTE KERMIT command, and the
associated packet format and protocol.  It lets the user of the client program
issue a command to the server in its own interactive-mode command language.
But this is not a totally satisfactory answer because the syntax of Kermit
programs can and does vary and, perhaps more to the point, some Kermit
programs do not have an interactive command mode at all (Macintosh Kermit is
one example).  What is needed is a standard mechanism and syntax that can
apply to all Kermit programs uniformly.

SOLUTION:

A new addition to the Kermit protocol: REMOTE SET.

REMOTE SET would be a Generic Kermit Server command.  A generic command looks
like this:

    +-----+---------------------------------+
    |  G  | x <len1> <op1> <len2> <op2> ... |
    +-----+---------------------------------+
     Type   Data

where "x" is the generic command, a single letter.  The letter S is not yet in
use, so let's define S to mean SET.  The S is followed by a single operand,
which includes a single-character length field, similar to other generic
command packets.

The parameters which may be SET remotely are the ones having to do with file
transfer and Kermit protocol in general, not system-dependent or
communications-dependent parameters, since these must already have been set
prior to making the initial connection, and must be set correctly in any event
BEFORE you can successfully send a REMOTE SET (or any other) packet to the
server.

The most needed REMOTE SET command is REMOTE SET FILE TYPE {TEXT,BINARY}, but
the others should be specified in the protocol too.  Numeric codes are
assigned to the parameters and values, so that the mechanism for conveying
this information is system- and language-independent and reasonably compact.
The REMOTE SET command does exactly what the corresponding SET command would
do if it had been given to the remote server as an interactive command before
it entered server mode.

  Command                                Code   Values

  REMOTE SET ATTRIBUTES IN ALL            132   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN LENGTH         133   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN TYPE           134   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN DATE           135   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN CREATOR        136   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN ACCOUNT        137   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN AREA           138   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN BLOCK-SIZE     139   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN ACCESS         140   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN ENCODING       141   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN DISPOSITION    142   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN PROTECTION     143   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN GPROTECTION    144   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN SYSTEM-ID      145   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN FORMAT         146   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN SYS-INFO       147   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES IN BYTE-COUNT     148   0 = OFF, 1 = ON

  REMOTE SET ATTRIBUTES OUT ALL           232   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT LENGTH        233   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT TYPE          234   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT DATE          235   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT CREATOR       236   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT ACCOUNT       237   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT AREA          238   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT BLOCK-SIZE    239   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT ACCESS        240   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT ENCODING      241   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT DISPOSITION   242   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT PROTECTION    243   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT GPROTECTION   244   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT SYSTEM-ID     245   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT FORMAT        246   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT SYS-INFO      247   0 = OFF, 1 = ON
  REMOTE SET ATTRIBUTES OUT BYTE-COUNT    248   0 = OFF, 1 = ON

  REMOTE SET FILE TYPE                    300   0 = TEXT, 1 = BINARY
  REMOTE SET FILE NAMES                   301   0 = CONVERTED, 1 = LITERAL
  REMOTE SET FILE COLLISION               302   0 = RENAME,  1 = REPLACE,
                                                2 = BACKUP,  3 = APPEND,
                                                4 = DISCARD, 4 = ASK
  REMOTE SET FILE REPLACE                 303   0 = PRESERVE, 1 = DEFAULT
  REMOTE SET FILE INCOMPLETE              310   0 = DISCARD, 1 = KEEP
  REMOTE SET INCOMPLETE (same as above)

  REMOTE SET BLOCK-CHECK                  400   number (1, 2, or 3)
  REMOTE SET RECEIVE PACKET-LENGTH        401   number (10-9024)
  REMOTE SET RECEIVE TIMEOUT              402   number (any, 0 = no timeout)
  REMOTE SET RETRY                        403   number (any, 0 = no limit)
  REMOTE SET SERVER TIMEOUT               404   number (any, 0 = no timeout)
  REMOTE SET TRANSFER CHARACTER-SET       405   Character Set Designator
  REMOTE SET WINDOW-SLOTS                 406   number (1-31)

One Kermit program should not have knowledge of another Kermit program's local
character sets, therefore REMOTE SET FILE CHARACTER-SET is not included.  The
Transfer Character Set Designator is the one described in the "ISO/Kermit"
proposal.  For example "I2/100" (ISO Latin Alphabet 1), "I2/144" (ISO
Latin/Cyrillic), or "I14/13" (Japanese Roman/Katakana).  The command would
use the name (for example REMOTE SET TRANSFER CHARACTER-SET LATIN1) and the
generic server command packet would use the corresponding designator.

REMOTE SET LANGUAGE is omitted for the present, but can be added later.  The
problem here is assigning a unique code to each of the world's languages.

The numbers shown for the codes and values are expressed as character
strings composed of ASCII digits, 0-9.  Here are examples, showing the TYPE
and DATA fields of the Kermit packet:

  GS#101!0      = REMOTE SET ATTRIBUTE LENGTH OFF
  GS#202!0      = REMOTE SET ATTRIBUTE TYPE OFF
  GS#300!1      = REMOTE SET FILE TYPE BINARY
  GS#400!2      = REMOTE SET BLOCK CHECK 2
  GS#401$1000   = REMOTE SET RECEIVE PACKET-LENGTH 1000
  GS#405&I2/100 = REMOTE SET TRANSFER CHARACTER-SET LATIN-1

ORGANIZATION AND EXPANSION:

The codes are numeric strings, with the hundred's place assigned roughly
according to "topic": 100's for Incoming Attributes, 200's for Outbound
Attributes, 300's for file-related items, and 400's for packet-related items.
Note that the SET ATTRIBUTE codes are equal to 100 or 200 plus the value of
the corresponding attribute designator.  There is plenty of room for expansion
within each category, and new categories can be added as required.

PROTOCOL:

The person using the client Kermit program issues a REMOTE SET command for
a single parameter, such as REMOTE SET FILE TYPE BINARY.  The program forms
the corresponding G packet and sends it to the server.

The server program can respond in any of the following ways, and the client
program should be prepared for each kind of response:

  E-packet:  An Error packet.  The server does not understand REMOTE SET
             packets, or it is not able to perform the specific SET that was
             requested.  Therefore the client must not assume that the SET has
             been done, and if it is in local mode, it must give a message to
             the user, as described below.

  Y-packet:  An Acknowledgement.  The server accepted the command, and
             performed the requested SET.  The data field of the Y-packet can
             be empty, to indicate that the requested value was accepted.  Or
             it can contain the value which the server actually set.  For
             example, the user types REMOTE SET RECEIVE PACKET-LENGTH 5000 but
             the server only supports lengths up to 1000:

        To server -->  GS#400$5000
                   Y1000        <-- To client

CLIENT IMPLEMENTATION:

A client can include support for any number of the REMOTE SET commands, or
none at all.  A minimal implementation might include only REMOTE SET FILE
TYPE.  This would include addition of the command to the program's command
tables, code to send the generic packet, and code to interpret the response
and issue any appropriate messages to the user, like the contents of the
error packet data field, or any altered value that the server sent back in
the data field of an acknowledgement.  Examples:

    REMOTE SET command succeeded
    REMOTE SET value changed to 1000
    REMOTE SET command failed: <reason from data field of E-packet>

SERVER IMPLEMENTATION:

A server can also include support for any number of the REMOTE SET commands,
or none at all.  If it supports none at all, then it will automatically
respond to a REMOTE SET packet with an error packet containing a message
like "Unimplemented REMOTE command".

If the server receives a REMOTE SET packet for a parameter it does not support
the REMOTE SETting of, then it should respond with an error packet containing
the message "Unknown REMOTE SET parameter".

If the server gets a REMOTE SET packet for a parameter which is known to it,
then it should:

(a) Set the parameter to the requested value and respond with an empty Y
    packet, or:

(b) If the requested value exceeds the server's maximum value for the
    parameter, set it to its own maximum value and respond with a Y packet
    containing the new value in its data field, as in the packet-length
    example above.

If the server is a "permanent" Kermit server which cannot be terminated using
BYE or FINISH, then when the user disengages from it using BYE, FINISH, or
LOGOUT, then when the server receives a BYE, FINISH, or LOGOUT command, it
should revert any parameters that were changed by REMOTE SET back to the
values that were in use when server mode was entered.

Thanks to Joe Doupnik and John Chandler for their assistance in the design
of this protocol extension.

------------------------------

End of Info-Kermit Digest
*************************

From cmg  Mon Jan  8 15:32:58 1990
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA09985; Mon, 8 Jan 90 15:32:58 EST
Date: Mon, 8 Jan 90 15:32:57 EST
From: Christine M Gianone <[e-mail]>
To: info-kermit
Subject: Info-Kermit Digest V11 #2
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Mon, 8 Jan 1990        Volume 11 : Number 2

Today's Topics:
                MS-DOS Kermit 3.0 Beta Test Available
                  New Luxor (luxker) Kermit Programs
                      Kermit-11 Comments Wanted

Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.0), IP host number 128.59.39.2.  Login as user
anonymous (note, lower case), any password, and GET or MGET (MULTIPLE GET)
the desired files.  The Kermit files are in directories kermit/a, kermit/b,
kermit/c, kermit/d, and kermit/e.  Test versions are in kermit/test.  You
can also get Kermit files over the BITNET/EARN network; to get started send
a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA.
For detailed instructions, read the file kermit/a/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 Jan 8 1990 12:00:00 EST
>From: Christine M Gianone <[e-mail]>
Subject: MS-DOS Kermit 3.0 Beta Test Available
Keywords: MS-DOS Kermit 3.0, International Character Sets, Sliding Windows
Keywords: Tektronix Emulation, VT320/340 Emulation, Local Area Networks
Keywords: WordPerfect

This is to announce a very short public beta testing period for MS-DOS
Kermit 3.0 for the IBM PC, PS/2, and compatibles.  Releases of 3.0 for some
of the non-IBM-compatible MS-DOS computers are in preparation, but not ready
yet, others need volunteer help.  Please get the test version as quickly as
possible and report problems directly to the author of the program, Joe R.
Doupnik, [e-mail], [e-mail], or [e-mail].

The files for this new release are available via anonymous FTP from
watsun.cc.columbia.edu on the Internet, and from KERMSRV@CUVMA on
BITNET/EARN.  On watsun, login with FTP as user anonymous (any password), cd
kermit/test, and multiple get (mget) the files.  On BITNET, send a message
(interactive or mail) to KERMSRV@CUVMA and request the desired files.  The
manual is in preparation and will be announced shortly.

The file MSTIBM.BOO is the runnable .EXE file encoded in printable format.
To convert the BOO-file back to .EXE, use any of the MSBPCT.* programs,
which can be found in the "A" area of Kermit distribution on watsun
(cd kermit/a), or in KERMSRV (just refer to them by name).  On watsun only,
the executable program, MSTIBM.EXE, is available for FTP in binary mode
(note, on watsun, the filenames are lowercase).  Here is a brief list of the
files that are available during this testing period (many of these names
will change in the real release):

  Internet     BITNET/EARN
  WATSUN       CUVMA
  kermit/test  T:            Description

  mstibm.exe   (none)        Executable program, about 131K (watsun only)
  mstibm.boo   T:MSTIBM.BOO  BOO-encoded version of MSTIBM.EXE, about 156K
  mstibm.hlp   T:MSTIBM.HLP  A short help file
  mstibm.bwr   T:MSTIBM.BWR  "Beware" file, known limitations and bugs
  mstibm.upd   T:MSTIBM.UPD  Summary of features new to version 3.0
  mstibm.ed    T:MSTIBM.ED   Detailed edit history
  mstibm.vt    T:MSTIBM.VT   Summary of functions of VT320 emulator
  mstibm.ini   T:MSTIBM.INI  Sample init file for version 3.0 (MSKERMIT.INI)
  mstibm.hay   T:MSTIBM.HAY  Hayes modem dialing script (HAYES.TAK)
  mstibm.wp    T:MSTIBM.WP   WordPerfect init file for version 3.0 (WP30.INI)
  mstlk2.asm   T:MSTLK2.ASM  LK250 keyboard driver source (from Terry Kennedy)
  mstlk2.com   (none)        Binary executable LK250 keyboard driver
  mstlk2.boo   T:MSTLK2.BOO  BOO-encoded version of MSTLK2.COM
  mstlk2.hlp   T:MSTLK2.HLP  Help file for LK250 driver
  ms*.asm,.h   T:MS*.ASM,.H  Source files

The public beta-testing period will last only about a week, so please test
the new features and send in reports and/or fixes as quickly as possible!
The formal release will come several weeks later.  Your cooperation in rapid
testing and reporting of bugs is much appreciated, and the short notice is
regretted.

As bugs are reported and fixed, the files MSTIBM.EXE, .BOO, and .BWR will
probably change from day to day, so when reporting a problem, be sure to
include the full version heading (as reported by the VERSION command).
These changes will be logged at the end of the file MSTIBM.ED.

NEW FEATURES OF MS-DOS KERMIT 3.0

 1. Emulation of most features of the DEC VT320 terminal, plus many features
    of the VT340.
 2. International character sets in terminal emulation and file transfer.
 3. Sliding window packet protocol.
 4. Expanded support for local area networks.
 5. Enhanced graphics commands in the Tektronix emulator, suitable for use
    with mainframe WordPerfect versions 5 and 4.2.
 6. Many other improvements.

The rest of this message describes these new features.  See MSTIBM.UPD and
MSTIBM.ED for details.

1. VT320/VT340 EMULATION

MS-DOS Kermit 3.0 emulates the DEC VT320 terminal, international model, with
many features of the more advanced VT340/330 text/graphics terminals thrown
in.  VT320 is the default terminal type for MS-DOS Kermit 3.0.  Kermit
continues to offer emulations for the DEC VT52, Heath/Zenith-19, and DEC
VT100/102 terminals, as well as of Tektronix graphics terminals.  Kermit's
VT320/340 emulation offers many capabilities beyond the VT102, including:

 . A selection of character sets, with the ability to switch among them.
 . Translation of the above sets to/from any of the five IBM PC code pages.
 . User-defined soft function keys, downloadable by the host.
 . Tektronix 4010/4014 graphics with many extensions, including color,
   "sixel" graphics, rectangle fill with various patterns, and more.
 . Support of the DEC LK250 keyboard, a DEC LK201 keyboard for IBM-PCs
   (via a special driver, MSTLK2.*).
 . A new mechanism for switching between 80 and 132 columns when your
   display adapter supports this.
 . Graphics screens may now be saved to disk files in uncompressed
   Aldus/Microsoft TIFF 5.0 format (approximately 110K per EGA screen)
   for importation into other applications that support TIFF files.

2. INTERNATIONAL CHARACTER SET SUPPORT

MS-DOS Kermit 3.0 supports translation between the PC's local character set
(Code Page) and ISO Latin Alphabet 1 (ISO 8859-1) during file transfer.
The relevant new commands are:

  SET TRANSFER CHARACTER-SET { TRANSPARENT, LATIN1 }
  SET FILE CHARACTER-SET { CP437, CP850, CP860, CP863, CP865 }

The default transfer character set is TRANSPARENT (that is, no translation
is done) for compatibility with previous releases of MS-DOS Kermit.  The
default file character set is your PC's current code page, such as CP437,
which is detected automatically.

These new commands allow you to transfer files containing accented and other
special characters with Kermit programs on computers that represent these
same characters using different codes, such as VAX/VMS, UNIX, Macintosh, IBM
mainframes, etc, when the Kermit programs on these computers also support
international text file transfer; new versions of C-Kermit for UNIX and
VAX/VMS, Macintosh Kermit, IBM mainframe Kermit, and others which support
this feature are in preparation (watch Info-Kermit for announcements).
International file transfer is also useful between two PCs that use
different code pages.

Various host-based international character sets are also supported during
VT320 terminal emulation, including 8-bit ISO Latin Alphabet 1, the DEC
8-bit Multinational Character Set, 12 different 7-bit National Replacement
Character (NRC) Sets, and several others.  Kermit automatically translates
incoming characters from the current terminal character set (SET TERMINAL
CHARACTER-SET) to the current PC code page, and it automatically translates
keystrokes from the current code page to terminal character set.  The
default terminal character set is LATIN1 (Latin Alphabet 1).  SET KEY
assignments take precedence on a per-key basis.

3. SLIDING WINDOW PACKET PROTOCOL

For increased efficiency during file transfer across long-distance,
long-delay communication links such as public data networks, MS-DOS Kermit
3.0 includes sliding window packet protocol.  This means that Kermit does
not have to wait for an acknowledgement for the current packet before
sending the next packet.  The number of packets that may be sent before
acknowledgements arrive is called the "window size", and this may range from
1 to 31.  A sufficiently large window size allows transmission of packets to
be continuous, and makes maximum effective use of the transmission channel.
The command to select the window size is:

  SET WINDOW n

where n is a number from 1 to 31.  The default window size is 1 for Kermit's
normal stop-and-wait operation.  Window sizes greater than 1 can be used
only with other Kermit programs that support this option, including PRIME
Kermit, C-Kermit 5A or later (still in preparation), certain commercial
programs, or another copy of MS-DOS Kermit 3.0.

Sliding windows may be used in conjunction with long packets.  The product
of the packet size and the window size may not exceed 2000.

4. LOCAL AREA NETWORK SUPPORT

MS-DOS Kermit 3.0 for the IBM PC, PS/2, and compatibles supports the
following local area networks and protocols:

 . Netbios via SET PORT NETBIOS for PC-to-PC file transfers.  Requires a
   Netbios-based PC network (like IBM PC Network or IBM Token Ring) and
   accompanying hardware and drivers.

 . Netbios via SET PORT NETBIOS for PC to AT&T Unix systems over StarGroup
   (formerly StarLAN) and for PC-to-host file transfer across any NetBios
   compatible system.  Requires a Netbios driver for your network interface.

 . Novell Terminal Emulation Service (TES) via SET PORT BIOSx.
   Requires Novell TES BIOS-Level COMx driver (e.g. COM1, COM2) that
   intercepts BIOS interrupt 14H and controls the network interface, and
   a host VAX running NetWare/VMS.

 . Novell NASI/NACS V2 and compatible asynchronous communication servers,
   via SET PORT NOVELL.  Requires Novell or compatible network.

 . DECnet-DOS, both LAT and CTERM interfaces, via SET PORT DECNET.
   Requires installation of DECnet-DOS or DECnet PCSA.

 . Ungermann-Bass Net/One Int 6BH via SET PORT UB-NET1.
   Requires an Ethernet board with U-B Net/One drivers or compatibles.

 . Intel OpenNET via SET PORT OPENNET, a NetBios implementation.

 . IBM asynchronous communication servers accessed through IBM EBIOS,
   via SET PORT BIOSx.  Requires EBIOS Int 14H interceptor (needs testing).

 . 3COM Bridge Application Program Interace (BAPI) to asynchronous
   communication servers via SET PORT BIOSx.  Requires 3COM Int 14H
   interceptor.

 . TCP/IP Telnet via SET PORT BIOSx.  Requires vendor's Int 14H interceptor
   to execute Telnet protocol, for example FTP Software's PC/TCP v2.04
   (TNGLASS), or Interlan's TCP/IP Gateway for Novell Networks.  Use TNGLASS
   dated 6 Dec 1989 or later.

5. TEKTRONIX GRAPHICS

The name Tektronix may no longer be adequate to describe the new features
drawn from DEC VT340/330 and HDS 2000/3000 graphics terminals.  Principle
additions are:

 . Rectangle (border only) and pattern filled rectangle drawing commands.

 . More preprogrammed line patterns, many rectangle fill patterns, both
   include several host-definable patterns.  Fill patterns are tiling kinds
   synchronized to the screen boundaries, for smooth joinery and easy
   pattern overlaying operations.

 . Host control of destructive space and backspace.

 . User control of opaque or transparent character writing.

 . Control of pixel basic operations such as write absolute, OR, XOR with
   existing colors, including DEC VT340 ORing of color palette numbers.

 . DEC Sixel graphics commands.

 . Screen dumping in TIFF v 5.0 formats (class B for B/W, class P palette
   for EGA and VGA screens), uncompressed.  One file for each screen
   capture.

 . Support of most common cursor steering and line/screen erasure escape
   sequences of ANSI text terminals, scaled to the text terminal's screen
   shape, so that text, Tektronix, and Sixel graphics can be mingled.

 . Automatic switching from text terminal to graphics terminal upon receipt
   of a Sixel Device Control String.

 . Presence, use, and reporting of the 16 color and b/w palettes of the DEC
   VT340/330 terminals.  DEC characteristic of black always writes
   absolutely.

 . Coloring commands acceptable in ANSI ESC [ 3x; 4x m  format and in Device
   Control Strings for both RBG and HLS (hue, lightness, saturation) systems.

 . Reporting of the graphics screen size and number of colors upon host
   request, an MS-DOS Kermit escape sequence in DEC private format.

 . Support for mainframe WordPerfect 5.0 and 4.2 to view and edit figures
   (pictures) and pages in graphics mode while preparing documents in text
   mode.  TIFF files from MS-DOS Kermit screens are directly readable into
   WordPerfect (and several other packages).

 . Terminal identification response of VT300 with Sixel and other attributes.

 . Recognition of 8-bit control sequences, but truncation of other 8-bit
   characters to 7-bit form.  For this, parity must be NONE and DISPLAY 8-bits.

 . Recognition of the ESC [ ? 34 h and l  TerminalS and TerminalR MS-DOS
   Kermit macro invokation sequences from the host.

6. OTHER IMPROVEMENTS

* Communications

 . Support for advanced features of the PS/2's National Semiconductor 16550A
   UART (serial communications) chip for improved performance.

 . New SET DUPLEX { HALF, FULL } command includes support for RTS/CTS
   handshake for use with half duplex modems, radio transmitters, etc.
   RTS/CTS is used if DUPLEX is set to HALF and the DSR signal is present.

* Terminal Emulation (in addition to VT320/340 and Tektronix features
  listed above):

 . Expanded storage for rollback screens.  If memory is available, Kermit
   will allocate room for about 10 screens.  More is available via the new
   DOS environment variable, KERMIT: SET KERMIT=ROLLBACK 120, memory
   permitting.

 . Screen rollback is now instantaneous.

 . New REPLAY command to replay a Kermit session log through the terminal
   emulators.

 . Transparent print now works properly in the presence of parity.

 . New SET TERMINAL KEYPAD { APPLICATION, NUMERIC } command gives users
   explicit control over VT terminal keypad mode.  Formerly the keypad mode
   could be changed only by escape sequences sent from the host.

 . Visual bell for deaf users (SET TERMINAL BELL VISUAL) during terminal
   emulation.

 . Support for additional monitors and display adapters:
   - Wyse-700 (graphics in several high resolution dimensions)
   - ATT EGA VDC600 (automatic recognition of 80/132 column mode)
   - STB VGA/EM, VGA/EM-15 boards (automatic recognition of 80/132 column mode)
   - Other boards to or from 80/132 columns via COLS80.BAT and COLS132.BAT.

* Kermit Protocol (in addition to international character sets and sliding
  windows, described above):

 . Maximum file transfer packet size increased from 1000 to 2000 bytes.

 . New server security features, including login/password, available via
   DISABLE, ENABLE, and SET SERVER commands.

 . Redirection of output of REMOTE commands to file or printer via
   DOS redirection symbol (>), e.g. REMOTE DIRECTORY > PRN.

 . Non-control versions of single-character file transfer interrupt commands
   (X,Z,E,C) are now available.

 . Many new options for SET ATTRIBUTES command, to control attributes
   individually, for example SET ATTRIBUTES DATE OFF.  Attributes now include
   date and time, file size, file type, and transfer character set.

 . MS-DOS Kermit server now recognizes REMOTE KERMIT SET commands.

 . New REMOTE SET command, used to change settings on remote Kermit server, as
   described in Info-Kermit V11 #1.  Also supported by MS-DOS Kermit server.
   This is a new Kermit protocol feature, as yet unsupported by other Kermit
   programs, but will be in future releases of C-Kermit, etc.

* Miscellaneous Features and Commands:

 . Space for macro names expanded from 500 to 1000 bytes.  Space for macro
   definitions was formerly 3000.  Now it's dynamically allocated and will
   use as much memory as can be found.

 . SHOW commands added for many types of things (file, protocol, terminal,
   memory, modem, statistics, etc).

 . Keyboard verbs (like \Kexit) can now be embedded within keyboard definition
   text strings and mixed with other keyboard verbs.

 . New WRITE <logfile> <object> command to annotate log files.  <logfile> may
   be SESSION, PACKET, TRANSACTION, or SCREEN.  <object> may be TIME, DATE,
   PATH, TEXT, etc.

 . New IF statements for arithmetic comparison: IF <, IF >, IF =, for example:
     IF < %\1 3 echo Argument is less than 3.

 . New numeric variables, can be used with IF <, etc, and WRITE:
   - ARGC        Number of words in a macro invocation
   - COUNT       Loop counter (set via SET COUNT)
   - ERRORLEVEL  Error level (set via SET ERRORLEVEL)
   - VERSION     Program version (built in, 3.0 = 300)
   Note: ARGC allows construction of macros that can test for the presence
   of arguments and supply defaults, without being confused by leftover
   parameters from previous macro invocations.

 . ASK command now operational, and allows backslash codes in prompt.
   ASK <variable> <prompt> prints prompt, stores what user types in variable.

 . New ASKQ command, like ASK but does not echo what the user types, useful
   for passwords.

 . Allow ECHO string and ASK prompt string to contain backslash codes for the
   PC's 8-bit characters, so that fancy effects and international characters
   can be displayed.

 . New controls and options for TRANSMIT command (SET TRANSMIT ?).

 . New command SET FILE WARNING { ON, OFF, NO-SUPERSEDE }.  ON and OFF are
   like previous SET WARNING command.  NO-SUPERSEDE option can be used for
   continuing interrupted wildcard file reception, skipping over files that
   already exist.

 . A patch mechanism for applying corrections to the binary executable
   program image.

Thanks to Professor Joe R. Doupnik of Utah State University for a year of hard
work on this release, and to the many testers during the development phase,
and to the contributors who helped with many aspects of the new version.

------------------------------

Subject: New Luxor (luxker) Kermit Programs
Date: Mon, 11 Dec 89 23:20:50 MET
>From: Bo Kullmar <[e-mail]>
Keywords: Luxor, ABC-80/800

I am sending you two kermit program for the old Swedish Luxor computers.
Today you have a program called luxker in the distribution that a member of
the ABC-Club (ABC-Klubben in Swedish), Torbjoern Alm, has done.  This program
has a lot of bugs so I recommend that you the replace it with the program that
I am sending you.  luxker has a limited server function that my program is
missing, but luxker does not handle binary files!

I am also sending you a Kermit program for the first Luxor computer ABC80,
which is mainly used in Sweden and the other nordic countries.

Most of the texts are in Swedish, but there is a .DOC file in English for both
programs.

By the way, I am the chairman of the ABC-Club.  The club today is a club for
PC and other modern computers but we still try to support the old ABC
computers.

Bo Kullmar, Helsingoersg. 38, S-164 42  KISTA, Sweden, Phone [phone]
UUCP:           {uunet,mcvax,munnari,cernvax,diku,inria,prlb2,tut,ukc,unido}
                !sunic!kullmar!bk
Internet:       [e-mail]

[Ed. - Many thanks, Bo, and to the others who worked on these programs.  They
have replaced LUXKER in the "D" area of Kermit distribution.  Each program is
in a single text archive file, LUX80.JAR for ABC-80 and LUX800.JAR for the
ABC-800.  Incidentally, the Swedish is written in the Swedish 7-bit National
Replacement Character Set, so it can be viewed on IBM PCs using MS-DOS
Kermit via SET TERMINAL CHARACTER-SET SWEDISH.]

------------------------------

Date: Fri, 24 Nov 89 12:34 EDT
>From: Brian Nelson <[e-mail]>
Subject: Kermit-11 Comments Wanted
Keywords: PDP-11 Kermit

I would like to hear from Kermit-11 users about suggested improvements and
bug fixes.  It's been a while since I've done much with Kermit, it would
seem it's about time to revisit Kermit and update it.  All comments are
welcome.

[e-mail]
[e-mail]

------------------------------

End of Info-Kermit Digest
*************************

From fdc  Thu Jan 18 20:54:35 1990
Return-Path: <fdc>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA08698; Thu, 18 Jan 90 20:54:35 EST
Date: Thu, 18 Jan 90 20:54:34 EST
From: Frank da Cruz <[e-mail]>
To: [e-mail]
Subject: Info-Kermit Digest V11 #3
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Thu, 18 Jan 1990        Volume 11 : Number 3

Today's Topics:
                     Announcing MS-DOS Kermit 3.0
               MS-DOS Kermit 3.0 Questions and Answers
                   New MS-DOS Kermit Book Available
                  MS-DOS Kermit 3.0 Feedback Wanted
               Announcing HP-1000 Kermit Version 1.99D
              Query: C-Kermit Treatment of Modem Signals

Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.0), IP host number 128.59.39.2.  Login as user
anonymous (note, lower case), any password, and GET or MGET (MULTIPLE GET)
the desired files.  The Kermit files are in directories kermit/a, kermit/b,
kermit/c, kermit/d, and kermit/e.  Test versions are in kermit/test.  You
can also get Kermit files over the BITNET/EARN network; to get started send
a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA.
For detailed instructions, read the file kermit/a/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.

[Ed. - And apologies for the I-KERMIT ADD message mistakenly sent to I-KERMIT
instead of LISTSERV.  Some day I'll learn!]

----------------------------------------------------------------------

Date: Thu, 18 Jan 1990 12:00:00 EST
>From: Christine M Gianone <[e-mail]>
Subject: Announcing MS-DOS Kermit 3.0
Keywords: MS-DOS Kermit 3.0

This is to announce the final release of MS-DOS Kermit 3.0, first announced
for beta-testing in Info-Kermit V11 #2.  Thanks to the thousands of you who
participated in the short testing period.  To recapitulate the major new
features of 3.0, they are:

 . DEC VT320 terminal emulation.
 . Many additions to Tektronix graphics emulation, including features
   from the DEC VT340 (color, sixel, but not REGIS) and HDS2000/3000,
   suitable for use with mainframe versions of WordPerfect 4.2 and 5.0.
 . Saving of graphics screens on disk in TIFF 5.0 format, suitable for
   import into PC Paint, Ventura Publisher, Pagemaker, WordPerfect 5.0, etc.
 . True half duplex operation with RTS/CTS hardware handshake.
 . International character set support for both terminal emulation and
   file transfer.
 . Sliding window packet protocol.

Problems reported and fixed during the testing period include:

 . Incorrect Attribute packet character set announcers.
 . Problems when receiving badly formatted packets 1800-2000 bytes in length.
 . Incorrect receive packet length after SET WINDOWS command.
 . Incorrect crosshair cursor report in Tektronix mode.
 . Automatic return to wrong text terminal type after Tektronix emulation.
 . Several incorrect special terminal character translations.
 . Incorrect operation of SET TRANSLATE INPUT.
 . Terminal lockup after failure to automatically enter 132-column mode.
 . Insufficient maximum allowed number of ANSI escape sequence parameters.
 . Nonfunctional 3COM BAPI network support.
 . Case sensitivity of ARGC, VERSION, and other special numeric variables.
 . Various minor escape sequence misinterpretations.

The new files have been installed in the regular Kermit distribution "A" area,
and are available over the networks via anonymous FTP from
watsun.cc.columbia.edu (Internet) and from KERMSRV at CUVMA (BITNET), and by
mail order from Kermit Distribution at Columbia University on a variety of
magnetic media.

Internet      BITNET        Description
 msvibm.boo    MSVIBM.BOO    BOO-encoded (printable) version of MSVIBM.EXE.
 mskerm.hlp    MSKERM.HLP    Summary of MS-DOS Kermit 3.0 features & commands.
 msr300.upd    MSR300.UPD    Description of new features in version 3.0.
 mskerm.bwr    MSKERM.BWR    Limitations and known bugs in version 3.0.
 mskerm.ed     MSKERM.ED     Detailed edit history of version 3.0.
 msvibm.vt     MSVIBM.VT     VT52/102/320/340/H19 terminal emulation summary.
 msvibm.tek    MSVIBM.TEK    Tektronix graphics summary (in preparation).
 mss*.asm,.h   MSS*.ASM,.H   System-independent source code.
 ms*ibm.asm    MS*IBM.ASM    IBM-PC/PS2-specific source code.
 msvibm.bat    MSVIBM.BAT    DOS batch program for building 3.0.
 msvibm.mak    MSVIBM.MAK    A makefile for building 3.0 under DOS with MASM.
 msvibb.mak    MSVIBB.MAK    A makefile for building 3.0 with Borland TASM.
 msvibx.mak    MSVIBX.MAK    A makefile for building 3.0 under Xenix.
 msvibm.lnk    MSVIBM.LNK    LINK command file for 3.0.

Kermit Init/Command Files:
 mskermit.ini  MSKERMIT.INI  Sample initialization file, includes DIAL macro.
 msihay.tak    MSIHAY.TAK    Hayes modem dialing script (used with DIAL).
 msiem*.ini    MSIEM*.INI    Keyboard setups for use with EMACS.
 msiwp3.ini    MSIWP3.INI    New keyboard setup for mainframe WordPerfect.

Utilities:
 mspeps.*      MSPEPS.*      Epson printer driver for EGA graphics screens.
 mspep4.*      MSPEP4.*      PC CP437-to-Epson character set translation.
 mspupc.sh     MSPUPC.SH     PCPRINT (transparent print) for UNIX.
 mspvpc.com    MSPVPC.COM    PCPRINT for VAX/VMS.
 msixse.*      MSIXSE.*      XSEND utility for sending directory trees.
 msuchk.*      MSUCHK.*      SCANCHEK utility to display keyboard scan codes.
 msulk2.*      MSULK2.*      LK250 keyboard driver.

Binaries are available on watsun only, for FTP in binary (image) mode,
in the kermit/bin directory:
 msvibm.exe    The MS-DOS Kermit 3.0 executable program.
 mspeps.com    Epson printer driver for EGA graphics screens.
 mspep4.exe    PC Code-Page-437-to-Epson character set translation.
 msixse.exe    XSEND utility for sending directory trees.
 msuchk.exe    SCANCHEK utility for keyboard scan codes.

Non-IBM Versions:

The non-IBM-compatible versions of MS-DOS Kermit 3.0 are not done yet.  Some
(DEC Rainbow, Heath/Zenith-100) are currently in preparation and will be
announced when they are ready.  Volunteers are needed for the others (Victor,
Sanyo, TI, HP, NEC, etc).  In the meantime, the new mss*.* source files are
incompatible with the old msu, msg, msx, msy, and msz system-dependent source
files for the non-IBM systems.  The .BOO files for the non-IBM versions,
however, will remain available.  Also, the old source files will be accessible
for limited time (most likely until the next major release of MS-DOS Kermit)
in kermit/old on watsun.

Bootstrapping:

For those who cannot use FTP to transfer the binary MSVIBM.EXE file
directly, the MSVIBM.BOO is an encoding of MSVIBM.EXE into printable ASCII
characters that should be safely transferrable over BITNET, e-mail, etc.
Use your old version of Kermit to download this file to your PC, and then
run any of the "BOO-file decoders" to translate it back into a runnable .EXE
file.  The following files are available for this purpose:

 msbaaa.hlp   An explanation of the bootstrapping files and procedures.
 msbpct.bas   A BOO-file decoder written in Microsoft BASIC.
 msbpct.c     Like MSBPCT.BAS, but written in C for speed.
 msbpct.boo   BOO file formed from MSBPCT.EXE based on MSBPCT.C.
 msbpct.*     There are also versions of MSBPCT in assembler, Fortran, etc.

If you have a C, Pascal, or other compiler, download the appropriate MSBPCT
source code, compile it, and run it to translate MSVIBM.BOO into MSVIBM.EXE.
If you only have BASIC, you should download MSBPCT.BAS and MSBPCT.BOO.  Then
use the former to create MSBPCT.EXE from the latter, and then use MSBPCT.EXE
to decode MSVIBM.BOO (using the BASIC version directly on MSVIBM.BOO would
take a very long time).

Our deepest thanks to Professor Joe R. Doupnik of Utah State University
([e-mail]) for the year of hard work he put in on this release, and for
his continuing devotion to the Kermit effort over the years.  Thanks also the
many others who contributed to 3.0, particularly Terry Kennedy, Jack Bryans,
John Junod, Bert Tyler, Mikko Laanti, Fred Richter, Hirofumi Fujii, Gary
Stebbins, Drew Derbyshire, and Paul Whitmer.  And for the accompanying
utilities, thanks to Mark Buda, Terry Kennedy, Phil Benchoff, Mark Zinzow, R.
Brooks Van Horn, and Frank da Cruz.

More about MS-DOS Kermit 3.0 in the following messages.

------------------------------

Date: Thu, 18 Jan 1990 13:12:11 EST
>From: Christine M Gianone <[e-mail]>
Subject:  MS-DOS Kermit 3.0 Questions and Answers
Keywords: MS-DOS Kermit 3.0

Here are the questions that came up most frequently during the MS-DOS Kermit
3.0 beta testing period:

 Q - I tried using the Latin-1 (or DEC-MCS) terminal character set, but I
     didn't get any special characters on my screen, only incorrect ASCII
     characters where the special characters should be.

 A - To see 8-bit text characters, you need an 8-bit no-parity connection to
     the host, and you must tell MS-DOS Kermit to SET DISPLAY 8 (7 is the
     default).  In the 7-bit environment, you can still use an 8-bit character
     set if your host sends shift-in/shift-out codes (but see MSKERM.BWR).
     Otherwise you must use one of Kermit's 7-bit "national replacement
     character sets" (Italian, Norwegian, etc), in which brackets, vertical
     bars, etc, are replaced by national characters.

 Q - If none of Kermit's built-in terminal character is suitable for my
     language or computing environment, what can I do?

 A - Put a lot of SET KEY and SET TRANSLATE INPUT commands in your
     MSKERMIT.INI file.  These commands override Kermit's built-in
     translations of outbound and inbound characters, respectively.  Also
     remember to SET TRANSLATE INPUT ON.  Using these mechanisms, you can
     construct an entirely new terminal character set.

 Q - Word-11 or other DEC PDP-11 or VAX/VMS applications do not seem to work
     right with 3.0.  Screens are fractured, etc.

 A - Kermit's new VT320 terminal emulation is noticed DEC by operating systems
     like VMS 5.0 or later, causing them to send 8-bit control sequences which
     are ignored by MS-DOS Kermit unless you SET DISPLAY 8.  SET DISPLAY 7 is
     still the default, for compatibility with earlier releases.

 Q - If Kermit does VT340 graphics, how come my SAS graphs don't come out
     right if I tell SAS that I have a VT340?

 A - Kermit implements many VT340 graphics features, including colors and
     sixels, but not DEC's REGIS graphics language, which is what SAS uses.
     There are no current plans to implement REGIS, which is huge.  The
     VT340 features which are supported by Kermit can be used to best
     advantage with host-resident versions of WordPerfect (4.2 and 5.0) on
     VAX/VMS or UNIX.

 Q - Why do I have to SET FILE TYPE TEXT and SET FILE TYPE BINARY with 3.0
     when I didn't have to do this in previous versions?

 A - During file transfer, version 3.0 does two things that previous versions
     didn't do: text file character set conversion, and conveying and using
     the file type given in the file attribute packet.  If you want to
     approximate the old mode of operation, in which you did not have to (and
     indeed could not) give SET FILE TYPE commands, you can SET TRANSFER
     CHARACTER-SET TRANSPARENT (this is the default anyway) and SET ATTRIBUTE
     TYPE OFF.

------------------------------

Date: Mon, 15 Jan 90 10:34:09 EST
>From: Frank da Cruz <[e-mail]>
Subject: New MS-DOS Kermit Book Available
Keywords: MS-DOS Kermit 3.0

Christine M. Gianone, who you know as the editor of the Info-Kermit Digest,
Manager of Kermit Development and Distribution at Columbia, designer of
recent extensions to the Kermit protocol, author of recent pieces in Data
Communications Magazine, PC Week, etc etc, has written a book on MS-DOS
Kermit 3.0:

  "Using MS-DOS Kermit", Digital Press, Bedford, MA (1990).

This book includes MS-DOS Kermit 3.0 for the IBM PC family on a 5.25-inch PC
diskette.  Printing should be complete by early- to mid-February.  The short
beta-testing period for 3.0 was due to the printing and binding deadline for
this book+disk package.

Chris's book is quite different from the earlier MS-DOS Kermit manuals.  It is
tutorial in nature, geared mostly towards the typical non-computer-expert PC
user.  It includes illustrated step-by-step instructions for program
installation and hooking up your cables and modems, an introduction to MS-DOS,
and chapters devoted to major Kermit topics including terminal emulation, file
transfer, server mode, international character sets, script programming,
features for people with disabilities, etc.  Every concept is illustrated by
examples.  A complete command reference is included, along with tables of PC
keyboard scan codes, Kermit keyboard verbs, and PC character sets, plus
glossary, index, etc.  The detailed technical appendices (escape sequences,
etc) found in the previous manuals are omitted; this information is (or will
be) available in other forms.  "Using MS-DOS Kermit" is an excellent
introduction to MS-DOS Kermit 3.0 and its new features, and the command
summaries and tables also make it a valuable reference.

The new book+disk package provides higher-quality documentation to a wider
audience.  Its tutorial approach will reduce the consulting burden on the
organizational help desk.  The book will give Kermit software a more "serious"
and professional image in the corporate and government sectors, and in the
press.  Ultimately, the result should be increased popularity for Kermit, new
inroads into the mass market, and some badly needed revenue for Kermit
Development and Distribution at Columbia to keep the Kermit project alive.
See the file MSKERM.HLP for availability and ordering information.

Of course, the Kermit software itself remains free, copyable, and sharable,
with source code openly available.  Online documentation is available too,
including:

  MSKERM.HLP - Expanded summary of MS-DOS Kermit 3.0 features and commands.
  MSKERM.BWR - The "beware" file, listing limitations, bugs, workarounds.
  MSR300.UPD - Description of the new features in 3.0.
  MSKERM.ED  - Detailed edit history since 2.32/A.
  MSVIBM.VT  - Description of terminal emulator escape sequences, keys, etc.
  MSVIBM.TEK - Description of graphics emulation features and escape sequences.
  MSKERM.DOC - The 2.32/A manual (long).  Also .MSS and .PS versions.
  MS*.ASM,.H - The source code! (very long).

All these files are new except for the 2.32/A manual (which still applies,
since 3.0 is backwards compatible with 2.32/A).  In addition, there are
numerous supporting files (contributed script programs, key mapping files for
various applications, notes and hints found in the Info-Kermit digest, etc).
Those who don't have access to the book should be able to find whatever
information they need in these files, and of course can tailor or combine
these documents to produce whatever local documentation they need.

------------------------------

Date: Wed, 17 Jan 1990 14:13:12 EST
>From: Christine M Gianone <[e-mail]>
Subject:  MS-DOS Kermit 3.0 Feedback Wanted
Keywords: MS-DOS Kermit 3.0

How is MS-DOS Kermit 3.0 working for you?  We usually hear from you only if
you have problems.  We'd also like to hear about it when things are OK.

Please let us know how you like the new features of 3.0 -- international
character sets, VT320 emulation, the new graphics features, sliding windows,
etc.  Also let us know about any discoveries you have made: how to use the
program with local area networks, host graphics applications, character sets,
etc, that are not mentioned in the documentation.  And of course, your problem
reports and suggestions for additional features in future releases are always
welcome.

And if you have any interesting stories about how you or your organization
are using Kermit, please send them in for possible publication in forthcoming
issues of Kermit News (yes, the fourth issue is on the way!).

------------------------------

Date: Mon Jan 8, 1990, 19:16:46 EST
>From: Christine M Gianone <[e-mail]>
Subject: Announcing HP-1000 Kermit Version 1.99D
Keywords: HP-1000, RTE Operating System

This is to announce version 1.99D of HP-1000 Kermit for the Hewlett-Packard
1000 series of computers with the RTE-6 and RTE-A operating systems, from
Paul Schumann of E-Systems, Inc, Greenville, Texas, USA.  This version
replaces version 1.98 of September 1986.  The major new feature is support
for the D-Series multiplexer and drivers.  The new files are available in the
"D" area of Kermit distribution:

  Distribution Name    Original Name     Description
   HPMKER.SRC           (many)            Fortran Source Code
   HPMKER.SUB           KERMIT.SBMT       Interex program submission form
   HPMKER.INS           KERMIT.ISTL       Installation instructions
   HPMKER.LOD           KERMIT.LOD        Loader command file
   HPMKER.HLP           KERMIT.TEXT       Plain text help file
   HPMKER.MAK           KERMIT.MAKE       Makefile

Binary files are not included, since these are not easily distributed on
industry-standard magnetic tapes or over networks.  According to the
installation instructions, these files can be generated from the Fortran
source (and in the case of the indexed help file, from KERMIT.TEXT).

The source code consists of many files concatenated into one single file,
HPMKER.SRC.  Within this file, each original file begins with a line like

<<< k6subs.ftn >>>

to show the original file name.  This file can be picked apart into its
original files with a text editor or a simple program.

Before attempting to build HP-1000 Kermit, be sure to reconstitute the
original source files, and to rename the HPMKER files back to their original
names shown above.  If you have trouble getting these files onto your HP-1000
or building Kermit from them, you can order a native HP-1000 tape containing
this program (including binaries) from Interex, the international HP user
group.

Many thanks to Paul Schumann for keeping this version of Kermit current,
and for contributing it to Kermit Distribution!

------------------------------

Date: Sat, 2 Dec 89 5:21:22 MET
>From: Kristoffer Eriksson <[e-mail]>
Subject: Query: C-Kermit Treatment of Modem Signals
Keywords: C-Kermit

[Ed. - What follows is an excellent discussion of some of the issues that
are holding up release of C-Kermit 4F, which in turn is holding up release
of C-Kermit 5A.  The system-dependent aspects of C-Kermit are the result of
contributions from dozens of programmers all over the world in the form of
patches to patches, rather than a rational and consistent design effort.
The code under discussion is in the ckutio.c module, and has reached a level
of complexity that defies understanding and instills fear in anyone who would
modify it, for fear of breaking something else which cannot be tested.
Responses to Kristoffer and to Frank da Cruz, [e-mail],
from UNIX programmers who might be able to help untangle this mess would be
most appreciated.]

I have made some modifications to ckutio.c for some new features, which made
it necessary for me to try and understand how kermit handles O_NDELAY and
CLOCAL on System V, and the corresponding facilities on other systems. My
conclusion so far, is that Kermit does not handle them in a concistent manner,
at least that is what I think now.

Now, to be able to continue with my new features, I need to fix this. To do
that without breaking anything at the same time, I need your help. I need to
know which parts of the current behaviour are intended, and which are not. I
need to know the consequences for systems other that SysV, because that is the
only one I have experience with. I need to know the consequences for the
routines that call on ckutio.c of changes in it. I have studied ckucon.c and
ckudia.c, but there are some other routines that call ckutio.c, which I
understand much less. I know there are many systems with flawed or in other
ways strange tty drivers. I need to know any considerations that should be
made for those.

I'll describe my understanding of O_NDELAY and CLOCAL on SysV. Let me know if
you disagree. You usually use O_NDELAY in the open() call to open a tty device
without blocking until there is a carrier present on that port, in case the
device has modem control enabled as default.  When you operate a modem on that
port, you usually don't want to wait for a carrier, since most modems don't
provide a carrier until you have dialed somewhere to, which you can't do if
you can't talk to it.  Ok, many modems can be configured to alwayes provide a
carrier, but then you can't be disconnected automatically when the connection
eventually drops. Kermit uses O_NDELAY on the open() in ttopen() if you have
set a modem type prior to the "set line" that causes ttopen() to be called.

O_NDELAY also affects read()-ing from the device. If there is nothing to read
(empty input buffer or dropped carrier), read() will finish immediately
returning 0 (the return value maybe will change/has changed in V.3 or V.4, I
don't know). You might want this behaviour sometimes (tell me if you think
Kermit does want it), but usually it is much more convenient to use the
VMIN/VTIME timed read in SysV, and Kermit does use VMIN/VTIME. With O_NDELAY
you would have to constantly loop on read() until you receive something.

However, if you turn off O_NDELAY, and use the VMIN/VTIME settings that Kermit
does, you have to find some other way to make the device ignore the carrier
absence, if you are going to talk to your modem.  You use CLOCAL to do that.
You couldn't have used CLOCAL to open the tty to begin with, since CLOCAL is
set through the ioctl() interface, which only works on already open files. But
once you have opened the file, you can set CLOCAL, and unset O_NDELAY. Kermit
sets CLOCAL when you dial, through a ttpkt(..., DIALING, ...) call in ckdial()
in ckudia.c.

Once you are finished commanding the modem, and have established a connection
and a carrier, you can unset CLOCAL so you will get an EOF when the connection
goes down. Kermit does that with a ttpkt(..., CONNECT, ...) call at the end of
ckdial().

If you have a direct connection that always gives a carrier, you need never
set CLOCAL.

So far, all seems well. However, O_NDELAY is not always unset, only sometimes.
I think this is wrong. I think O_NDELAY shoule always be unset at some time
before beginning to dial or connect. ttopen() leaves O_NDELAY set. ttpkt() and
ttvt() (ttvt is used by for the "connect" command) unset O_NDELAY only when
called with flow==DIALING.  Thus, for a direct connection where you do not
dial prior to connecting, O_NDELAY will remain set, unless I'm very mistaken.

By the way, I have not found any place where ttvt() is called with the
parameter "flow" set to either CONNECT or DIALING, but ttvt() nonetheless
handles those cases. ttvt() looks to me like a mutated ttpkt(), so maybe those
cases where just left in by accident?  Can they safely be removed?

After unsetting O_NDELAY, these functions perform some "magic"
( close(open(...) ). What systems need such magic?

Can someone explain how myread() works, especially the part where the return
value after an empty read is dependent on whether you have set a modem type or
not (ttmdm) and the loop around myread() in ttinc()?  I find it a bit strange.
What does the return values mean? I wonder whether this might be an effect of
O_NDELAY remaining set sometimes?  The condition ttmdm == 0 may during some
phases coincide with O_NDELAY remaining set, but not always. Is that the
reason for testing ttmdm?

In the end, ttres() also unsets O_NDELAY, this time without any magic, but
only for UXIII, and only if ttmdm != 0 (you have set a modem type).  Is there
any other reason for this than as a late repair of the missing unset earlier?
ttres() is supposed to restore the tty to "normal".  I wonder what this
"normal" mode is? If "normal" is the mode it had before dialing an connecting,
I don't think it will restore O_NDELAY to that state. I'm tempted to suggest
that it should be left alone, and to other functions fixed to always unset it,
but I am not sure that is the intended state either. If some very early state
is intended, which might be the case if ttres() can be called in an very early
state, e.g. via ttclos() if you change lines without using the first line,
maybe O_NDELAY should be turned on again?

tthang() closes and reopens the tty, except on Xenix systems. This open of
courses also blocks for carrier on my system if the O_NDELAY flag is not used,
exactly like the very first open. The open is performed with the same fcntl
flags as the file had before being closed. O_NDELAY is a fcntl flag. But
O_NDELAY is not always set at this point. It has been unset if you have used
the dial command, as I outlined before. I have patched this to force O_NDELAY
on the open, and restore to the original state afterwards. Any comment?  Why
is the tty closed at all? Shouldn't it suffice to set a zero baud rate, just
as the manual says? (It does suffice on my system.)

When the last open file descriptor to the tty is closed, it resets the
communications parameters to defaults (especially after dialing, when HUPCL
has been set explicitely). That is why CLOCAL will not remain on to enable a
painless new open.

Is it wise to use the "flow" parameter of ttpkt() and ttvt() both for setting
XON/XOFF flow controll and for indicating DIALING/CONNECT mode? Will there
never be any clash? What mode is it when it is not DIALING or CONNECT?

On many systems there is another solution to the problem of how to open and
read without blocking for a carrier. They have more than one device name (or
can have them created with mknod) for the same tty port. One name enables
modem control by default, and the other disabled it. Kermit does not know
about these different names, so it just uses what the user gives it.

I have testet that on SCO Xenix. I think it behaves somewhat strange on that
system, and not to my liking. The driver simply ignores my setting of CLOCAL,
and only uses the default for that device name, always. Are other systems like
that, too, or is just that Xenix is strange as always?

I think that's most of what I had on my mind.

Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden
Phone:[phone] ! e-mail: [e-mail]
Fax:  [phone] ! or ...!{uunet,mcvax}!sunic.sunet.se!kullmar!pkmab!ske

------------------------------

End of Info-Kermit Digest
*************************

From cmg  Fri Jan 26 14:28:11 1990
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA11037; Fri, 26 Jan 90 14:28:11 EST
Date: Fri, 26 Jan 90 14:28:11 EST
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V11 #4
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Fri, 26 Jan 1990        Volume 11 : Number 4

Today's Topics:
       PRIME Kermit Version 8.00 For PRIMOS R21 and R22
           Announcing Microsoft Windows Kermit 4.11
            MS-DOS Kermit 3.0 News
               "WKERMIT" Moved
           Additions to REMOTE SET Proposal
           Kermit Required in Government Contracts?

Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.0), IP host number 128.59.39.2.  Login as user
anonymous (note, lower case), any password, and GET or MGET (MULTIPLE GET)
the desired files.  The Kermit files are in directories kermit/a, kermit/b,
kermit/c, kermit/d, and kermit/e.  Test versions are in kermit/test.  You
can also get Kermit files over the BITNET/EARN network; to get started send
a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA.
For detailed instructions, read the file kermit/a/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, 17 Jan 90 12:51:45 WET DST
>From: John Horne <[e-mail]>
Via: Steve Jenkins, The National PD Software Archive, Lancaster University, UK
 <[e-mail]>
Subject: PRIME Kermit Version 8.00 For PRIMOS R21 and R22
Keywords: PRIME Kermit, Sliding Windows

This is to announce a new release of PRIME Kermit, version 8.00, that replaces
version 7.57 of May 1986, which was contributed by The Source Telecomputing,
Alexandria, VA, recently gone out of business.

Initially I was asked to investigate some problems our users were having with
large files.  However, the code seemed to be getting a bit old and messy.  So
it seemed somewhat easier to look at all of the code.  This version should
work exactly as the old version, but there is more functionality in it and the
use of packets should be more efficient.  The error handling has been much
improved, and I think that this will cure most problems that users used to
have.  All the previous known bugs have been sorted out in the code.  Where
possible version 6 of the Kermit Protocol Manual has been followed.  The new
version has been tested at PRIMOS revisions 21.0.5q and 22.0.1a.  Here is a
brief summary of the changes:

 - Support for 8-bit no-parity file transfers.
 - Better error handling and messages.
 - Full support for pathnames within commands.
 - Improved logging.
 - More command line options available (use -HELP to show them).
 - SET INCOMPLETE command.
 - Pound sign conversion option (US/UK).
 - CONVERT command to convert files to PRIME format.
 - Support for file size and  date attributes, user settable.
 - Support for nested TAKE files.
 - Local file management commands added including SPACE, RENAME, COPY, PUSH.
 - Better use of timeouts.
 - Filename collision detection and avoidance, user settable.
 - Many internal cleanups.

John Horne
Polytechnic South West
Plymouth, Devon, UK

[Ed. - Many thanks to John for this new version, and to Steve for sending it
to us!  The new files are installed in the Kermit Distribution D area as
PRIME8.*.  PRIME8.UPD includes a detailed list of changes since version 7.57.
PRIME8.SRC includes the build procedure, four insert files, and 39 source
files written in PLP, PRIME's version of PL/1.  Within PRIME8.SRC, each of
these files is separated by a line of -----'s and can be separated using a
text editor.  Warning, PRIME.SRC contains some rather long lines (some of them
up to 144 characters in length), which will no doubt cause problems for BITNET
transfers.  We are trying to find out if there is a way to legally break these
long lines.  Meanwhile, the old PRIME Kermit files for version 7.57 will
remain available in the D area as PRIME.*.  It is not known whether Version 8
will run under older versions of PRIMOS, such as R19, which 7.57 was written
for.  Please let us know whether we can retire the old version.

By the way, PRIME Kermit supports sliding window packet protocol, and so PRIME
users are particularly encouraged to test it against MS-DOS Kermit 3.0 with
window sizes greater than 1.  Reports welcome!]

------------------------------

Date: Mon, 22 Jan 90 18:15:26 EST
>From: Christine M Gianone <[e-mail]>
Subject: Announcing Microsoft Windows Kermit 4.11
Keywords: Microsoft Windows Kermit
X-Ref: MS-Windows, See Microsoft Windows

>From Bill Hall of Santa Clara, CA, comes version 4.11 of Microsoft Windows
Kermit (WINKER).  This program works on any PC that has Microsoft Windows 2.0
or greater.  It performs Heath-19 terminal emulation, does Kermit file
transfer, and two copies of it can be going at once, one on each COM port.

Version 4.11 is a minor update to the previous release, 4.10 of September
1989.  The major change is the inclusion of a comm driver (with Microsoft's
permission) that fixes an Xon/Xoff bug in the standard driver that is
distributed with Windows 2.10 and 2.11.  The source (Microsoft C 5.1) and .BOO
files are in the "A" area of Kermit distribution as win*.*.  Binaries (for
those who have access to binary FTP) are in kermit/bin/win*.*.  The .BOO files
may be "un-Boo'd" using the MSBPCT utilities, also found in the Kermit
distribution "A" area.

------------------------------

Date: Mon, 22 Jan 90 17:14:35 EST
>From: Christine M Gianone <[e-mail]>
Subject: MS-DOS Kermit 3.0 News
Keywords: MS-DOS Kermit 3.0 Graphics, MS-DOS Kermit 3.0 Network Support

EARLY REVIEWS

"I LIKE IT!!! ... Thanks for great program."
 - Kevin Lowey, University of Saskatchewan

"I *LOVE* Kermit!  It is wonderful to have a free communication package that I
can distribute to users just getting started dailing in to our VAX 8800 and/or
online library catalog."
 - Prof. Joe St Sauver, University of Oregon

"I'm very impressed with the new features, and am anxious to see the sliding
windows suport added to the [other] versions.  Kudos to JRD, and everyone
involved in the new release."
 - Mark Zinzow, University of Illinois at Urbana-Champaign

"I just received MS-DOS Kermit 3.00, and I must say that what I saw of it is
very nice ... the much faster scrolling ... Good for me, who scrolls a lot."
 - Matthias Niemeyer, Org. Chem. Inst., Goettingen, West Germany

"MS-DOS Kermit is the only PC communication program that works 100 percent
with speech devices and software used by the blind."
  - Rick Hayner, Portland, MI

"This version is AMAZING!!!!  ...  Until today, I didn't realize how powerful
the DECnet interface is...  I have modem servers around the network and I
never thought that a PC could Kermit over one of those modems - but SET PORT
DECNET does the trick.  Nice job!!!!"
  - Chris Lent and Robert Weiner, Cooper Union, NYC

BUGS AND PROBLEMS

But of course most messages of praise also included questions, suggestions,
or bug reports.  These are being added to MSKERM.BWR as they come in, and a
future message will give news about fixes for some of them.  Meanwhile, keep
the reports (good and bad) coming in!

One problem -- the one in which the program hangs AT&T 6300s running MS-DOS
3.10 -- is fixable by a DEBUG patch.  See the new file MSVIBM.DBG.  This file
will be used to record DEBUG procedures that can be used to fix bugs in or
otherwise change the IBM version of 3.00.

The MSZIBM.ASM file contained one line in which a comment extended beyond
column 80, preventing BITNET users from getting it via BITNET mail.  This
has been fixed.  Thanks to Franz Maier at the University of Salzburg, Austria,
for pointing out the problem.

NETWORKS DEPARTMENT

Kermit includes high-level interfaces for a variety of local area network
protocols (Netbios, DECnet, NASI/NACS, etc), but it does not include device
drivers for specific network boards and it does not execute the TCP/IP or
Telnet protocols.  Kermit is Kermit and can't really afford (in terms of
space and complexity) to do this.

What is needed here is a public-domain (or copyright but free, like Kermit)
program which executes Telnet (like NCSA) over TCP/IP, allows drivers for
various Ethernet boards to be plugged in, and can be run as a TSR interceptor
for Bios Int 14H, the communication port interrupt.  Such a program would
work through Kermit's SET PORT BIOS1 command.  Several such programs already
exist, but they are commercial products.  There is some possibility that a
future release of NCSA Telnet itself will provide the desired Bios hook.

We'd like to start collecting information about how to set up MS-DOS Kermit
3.0 to work with various kinds of PC LANs (or vice versa!), similar to the
information in MSKERM.HLP about Novell networks.  If you have hints about
setting up and using 3.0 with DECnet-DOS, 3COM, Netbios, Starlan, etc, please
send them in and we'll start collecting them into a file called MSVIBM.NET
(no such file yet).  Particulars about which programs and versions are used,
how to run them and in what order and with what options, etc, would be very
useful.

NEW GRAPHICS DOCUMENTATION

A file listing all of MS-DOS Kermit 3.0's graphics escape sequences is now
available as kermit/a/msvibm.tek on watsun.cc.columbia.edu for Internet FTP
access, and as MSVIBM.TEK on CUVMA for BITNET access via KERMSRV.  As readers
will note, there are many strange and powerful new capabilities here that
graphics-oriented applications can take advantage of, once educated to them.

Kermit does not emulate one particular kind of graphics terminal, but rather
combines the features of the Tektronix 4010 and 4014 monochrome graphics
terminals with selected features of the HDS 2000/3000 and DEC VT340 terminals,
including color control, sixel graphics, line and area patterns, rectangle
fill, and more.

So far, very few host programs know how to take full advantage of this mix of
capabilities.  In fact, the only one we know of is host-resident WordPerfect
version 4.2 or 5.0.  SAS Institute has been furnished with the new Kermit
graphics specifications, and they will consider adding support to SAS/Graph in
a new release -- thanks to all of you who called them about this, but please
don't call them any more, they got the message!

Experimentation is needed.  Try telling your graphics application that you
have a Tek 4010, a Tek 4014, an HDS 2000, an HDS 3000, and a VT340, and
compare the results.  Let us know which terminal type produces the best
results for which application (SAS/Graph, SPSS, S, DISSPLA/TELL-A-GRAPH, etc).
Note once again that VT340 will usually mean REGIS graphics to the
host, but Kermit does not support VT340 REGIS graphics, only sixel.

Better still, if your graphics application allows it, use the information in
MSVIBM.TEK to build a new driver, say "MSKERMIT300" (or encourage your
package vendor -- except SAS -- to do so), so that maximum advantage can be
taken of Kermit's new features.  If you succeed in doing this for a
particular package, please send us the information and we'll add it to the
MSVIBM.TEK file.

A second new file is also available: MSGTIF.DOC.  This is the Aldus/Microsoft
memo describing TIFF 5.0, the format used by MS-DOS Kermit 3.0 when dumping
graphics images to disk.  Note: MS-DOS Kermit cannot read TIFF files, it can
only write them.  To our knowledge, Kermit's TIFF format is supposed to be
compatible with WordPerfect 5.0, Pagemaker, Ventura Publisher, PC Paint, Gem
Paint, and Publishers Paintbrush.  Users of these packages are encouraged to
send reports, hints, etc, and we'd also like to hear about any other uses for,
or packages that go with, Kermit's TIFF files.

Packages that definitely do not import Kermit's TIFF files include Microsoft
Windows Paint 2.03 (even though TIFF is partially a Microsoft invention) and
the MIT X graphics conversion utilities PGM, PBM, etc (these only have support
for an earlier version of TIFF).

PROGRESS ON VERSION 3.0 FOR NON-IBM SYSTEMS

We have received an offer from John Nyenhuis at Purdue University to port
MS-DOS Kermit 3.0 to the GRiD Compass, HP Portable Plus, HP 110, and HP 150.
If you are interested in helping out with any of these systems, please get in
touch with John:

  John Nyenhuis   Purdue University  School of Electrical Engineering
  West Lafayette IN 47907   [phone]     [e-mail]

We also have some possible help with the DEC Rainbow and H/Z-100.  If you are
willing to (help) port 3.0 to any of the other computers supported by previous
MS-DOS Kermit releases (Sanyo, Victor, NEC, etc), please let us know!

UNIX TERMCAP NEEDED FOR MS-DOS KERMIT 3.0

In response to the many requests we've had for a UNIX termcap for Kermit's
VT-320 emulation, we can only say that most of the features that distinguish
the VT-320 from the VT-102 have to do with its 8-bit character set
capabilities, and most UNIX systems do not normally support 8-bit terminal
i/o, 8-bit control characters, or international character sets.  This has
started to change.  We also understand that release 19 of GNU EMACS will
support 8-bit character sets.  Anybody with VT320 termcaps, please send them
in!  Meanwhile, remember that the VT320 is compatible with the VT102 and
VT100, so you can still tell your UNIX host that you are using one of these,
even if MS-DOS Kermit's terminal type is set to VT320 (provided UNIX doesn't
inquire the terminal type via ESC Z).

------------------------------

Date: Mon, 22 Jan 90 12:51:00 EST
>From: Christine M Gianone <[e-mail]>
Subject: "WKERMIT" Moved
Keywords: Sliding Windows, WKERMIT

Speaking of Windows, PRIME, and The Source...  the old, original sliding
windows Kermit -- an adaptation of C-Kermit for the PC that was done in 1986,
commissioned by The Source Telecomputing to be used with their PRIME Kermit
implementation -- has been retired from the Kermit "A" area (popular versions)
to the "C" area (obscure versions), now that MS-DOS Kermit 3.0 supports
sliding windows and attribute packets, and that C-Kermit 5A (with sliding
windows) is on the way.

kermit/a/wkermit.* --> kermit/c/wkermit.*.

------------------------------

Date: Mon, 22 Jan 90 12:51:21 EST
>From: Christine M Gianone <[e-mail]>
Subject: Additions to REMOTE SET Proposal
Keywords: Kermit Protocol, REMOTE SET Command

REMOTE SET FILE BLOCKSIZE       311  number
REMOTE SET FILE RECORD-LENGTH   312  number
REMOTE SET FILE RECORD-FORMAT   313  F (fixed), V (variable), etc...

This is just for the record, to assign these numbers to these commands
for somebody who needed them.  Details to be filled in later.

------------------------------

Date: Thu, 25 Jan 90 17:42:25 EST
>From: Christine M Gianone <[e-mail]>
Subject: Kermit Required in Government Contracts?

We have heard many reports that certain requests for proposals or bids from
the US government for computer-related equipment include a requirement that
the Kermit protocol be supported.  We'd like to hear about any RFPs or
contracts, past or present, that called for Kermit.  Knowing about such things
helps us to convince those who need convincing that Kermit is not just a toy
used by hobbyists.

Still looking for other interesting stories about Kermit for Kermit News!

------------------------------

End of Info-Kermit Digest
*************************


From fdc  Wed Jan 31 12:45:24 1990
Return-Path: <fdc>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA03559; Wed, 31 Jan 90 12:45:24 EST
Date: Wed, 31 Jan 90 12:45:23 EST
From: Frank da Cruz <[e-mail]>
To: Info-Kermit
Subject: Duplicated Delivery
Message-Id: <[e-mail]>

Apologies to everyone who just got extra copies of Info-Kermit V11 #1 and
possibly other issues.  The SUN-4 from which the Info-Kermit Digest is
sent was restarted today for the first time in four months, and apparently
there were some old sendmail lock files hanging around that were cleared
by the restart, causing old mail that may or may not have been delivered
before to be delivered again.

From cmg  Thu Mar  8 17:46:08 1990
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA12775; Thu, 8 Mar 90 17:46:08 EST
Date: Thu, 8 Mar 90 17:46:07 EST
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V11 #5
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Thu,  8 Mar 1990        Volume 11 : Number 5

Today's Topics:
        Macintosh Kermit Update
        MS-DOS Kermit 3.00 Patches
        MS-DOS Kermit 3.00 for Rainbow, Grid, HP 110, and HP Portable Plus
        MS-DOS Kermit Utilities
        MS-DOS Kermit Help File in German
        MS-DOS Kermit Demo Files
        Proposed Mapping for IBM-PC Function Keys
        More MS-DOS Kermit Utilities: For Your Information with Thanks

Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.0), IP host number 128.59.39.2.  Login as user
anonymous (note, lower case), any password, and GET or MGET (MULTIPLE GET)
the desired files.  The Kermit files are in directories kermit/a, kermit/b,
kermit/c, kermit/d, and kermit/e.  Test versions are in kermit/test.  You
can also get Kermit files over the BITNET/EARN network; to get started send
a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA.
For detailed instructions, read the file kermit/a/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 7 Mar 1990 09:40:02 EST
>From: Christine M Gianone <[e-mail]>
Subject: Macintosh Kermit Update
Keywords: Macintosh Kermit

>From Paul Placeway <[e-mail]>, a minor update of the test version
of Macintosh Kermit, 0.98(63).  Parity setting is now correctly saved and
restored, and the user can now request that DTR be dropped on close.  The new
test version is available as:

BITNET/EARN       Internet
KERMSRV@CUVMA     watsun.cc.columbia.edu     Description

 T:CKMKER HQX      kermit/test/ckmker.hqx     BinHex V4 encoded binary

Thanks to Paul for fixing these problems.

------------------------------

Date: Wed 7 Mar 1990 10:40:02 EST
>From: Christine M Gianone <[e-mail]>
Subject: MS-DOS Kermit 3.00 Patches
Keywords: MS-DOS Kermit 3.0 Patches

Since MS-DOS Kermit 3.00 was released on January 16, a number of bugs have
been reported.  Luckily, one of the features of 3.00 is its new ability to fix
itself by applying patches.  The patch mechanism will work for the binary
program image (.EXE or un-BOO'd .BOO file) that is distributed by Columbia.
Modified versions, or versions which may have been built using different
assemblers or linkers, cannot be patched in this way.  A patch file is now
available that fixes about 25 minor problems, including:

 . Kermit can get stuck upon escaping back from connect mode if you have
   improperly set your COM port up as a printer using MODE COM1,...,P
   (NOTE: workaround without the patch is to type Ctrl-Break once or twice,
   or better still, remove the ",P" from your MODE command!)
 . Kermit can become stuck at startup on an AT&T 6300 or Olivetti M24.
 . Unwanted display of path if CD command is given in a take-file or macro.
 . IF = COUNT, IF = ARGC, etc, did not work correctly.
 . Inability to display C1 control characters as graphics when using
   SET TERMINAL CHARACTER-SET TRANSPARENT.
 . SET TRANSLATE INPUT did not work correctly with Shift-In/Shift-Out.
 . Transfer character set Latin-1 was incorrectly identified as I2/100 in the
   Attribute packet; it is now identified as I6/100 (ISO registration numbers)
 . Delayed handling in network environments when processing keystrokes that
   had string definitions.
 . ** Problems with Orchid Designer Professional VGA board in 132 column mode.
 . Several problems with escape sequences.
 . Mistranslation of various characters in several character sets.
 . Server did not exit when given BYE command.
 . Server did not negotiate type 2 or 3 block check correctly.
 . Macro or variable definitions could not be a single character.
 . On Novell server disks, incorrect reporting of no space available and
   unwanted attempts to access drive A.
 . Problems running on systems with too much free memory.

If none of these problems affects you, then you don't need to apply the
patches.  However, if you choose to apply the patches, you must apply them
all because some of them depend on some of the others (the Orchid patch
marked "**" above is an exception).  Here are the new files:

BITNET/EARN       Internet
KERMSRV@CUVMA     watsun.cc.columbia.edu     Description

 MSKERM   BWR      kermit/a/mskerm.bwr        Updated "beware" file
 MSKPATCH HLP      kermit/a/mskpatch.hlp      Instructions for patching
 MSKERMIT PCH      kermit/a/mskermit.pch      The patch file itself

The traditional profuse thanks to Professor Joe Doupnik of Utah State
University for these patches, to Jack Bryans for help with the patching
mechanism itself, and to all the people who found and reported these problems.

------------------------------

Date: Wed 7 Mar 1990 11:20:02 EST
>From: John Nyenhuis <[e-mail]>
Subject: MS-DOS Kermit 3.00 for Rainbow, Grid, HP 110, and HP Portable Plus
Keywords: Rainbow MS-DOS Kermit 3.0, Grid Compass MS-DOS Kermit 3.0
Keywords: HP 110 and Portable Plus MS-DOS Kermit 3.0
Xref: DEC Rainbow, See Rainbow

MS-DOS Kermit v3.00 is now ready for pre-release testing on three more
machines: the DEC Rainbow, Grid Compass, and both HP 110 and HP Portable Plus.
Gary Stebbins of Digital Equipment Corp, [e-mail], did the
Rainbow upgrade; and John Nyenhuis, Purdue University, School of Electrical
Engineering, [e-mail], upgraded both Grid and HP machines.
Our thanks to both Gary and John.

DEC RAINBOW COMPUTERS

The new Rainbow Kermit is similar to release 2.32 in the parts specific to the
Rainbow and the same as the IBM PC v3.00 in the system independent parts.

GRID COMPASS FAMILY

The system specific features are similar to those present in version 2.32
which was a significant enhancement over 2.31. Key features of Kermit 3.00 for
the GRiD Compass are:

  (a) Tektronix 4010 emulation is supported.
  (b) Maximum speed in connect mode is about 4800 baud.
  (c) The same program should work on the entire GRiD Compass
      family. (It has been tested on the 1101, the 1129, and the
      1131.) Note that you will need to "SET TERM BIG" on the
      113x in order for the graphics to work correctly.

HEWLETT PACKARD PORTABLE (110) AND PORTABLE PLUS LAPTOP COMPUTERS

There are a number of enhancements over the previous 2.32 version. An overview
of key new features:

  (a) Tektronix 4010 emulation is supported.
  (b) The internal modem on the HP 110 is supported. Select the
      modem port ("SET PORT MODEM"), go to connect mode, and
      and then press "Extend char d" (Extended Char and d at
      the same time). You will then be asked for the number you
      want to dial.
  (c) Speed in connect mode is faster. Maximum speed without
      flow control is about 3000 baud for the 110 and 4800
      baud for the Portable Plus.
  (d) The same program works on both the 110 and the Portable Plus.

Please let me know if you encounter any problems. I welcome any comments or
suggestions.  Test Kermits are available as the files listed below:

BITNET/EARN       Internet
KERMSRV@CUVMA     watsun.cc.columbia.edu     Description

 MSTRB1 BOO        kermit/a/mstrb1.boo        Rainbow BOO file (encoded binary)
                   kermit/bin/mstrb1.exe      Rainbow binary
 MSTGRI BOO        kermit/a/mstgri.boo        Grid Compass BOO file
                   kermit/bin/mstgri.exe      Grid binary
 MSTGRI HLP        kermit/a/mstgri.hlp        Grid documentation
 MSTGRI ANN        kermit/a/mstgri.ann        Grid announcement notes
 MSTHPX BOO        kermit/a/msthpx.boo        HP 110 & Portable Plus BOO file
                   kermit/bin/msthpx.exe      HP binary
 MSTHPX HLP        kermit/a/msthpx.hlp        HP documentation
 MSTHPX ANN        kermit/a/msthpx.ann        HP announcement notes

John Nyenhuis   Purdue University  School of Electrical Engineering
West Lafayette IN 47907   [phone]     [e-mail]

[Ed. - Many thanks to John and Gary for their rapid response to the release
of 3.0!  Please send the results of your testing to Info-Kermit and/or to the
John or Gary.  If testing proves successful, these test versions can replace
the current standard distribution for these programs.]

------------------------------

Date: Wed 7 Mar 1990 11:40:02 EST
>From: Christine M Gianone <[e-mail]>
Subject: MS-DOS Kermit Utilities
Keywords: MS-DOS Kermit 3.0 Printer Support, MS-DOS Kermit 3.0 Termcap
Keywords: Printer, PCPRINT, Termcap, MS-DOS Kermit Utilities
Keywords: Epson Printers, Radio Shack DMP200 Printer, HP Laserjet

We have recently received several useful new utilities that can be used with
MS-DOS Kermit.  First, from Dr. R. Brooks Van Horn, Jr., of Herndon, VA, a set
of printer drivers that can be used for dumping Kermit's graphics screens to
various kinds of printers.  These are all for use on EGA/VGA systems:

BITNET/EARN       Internet
KERMSRV@CUVMA     watsun.cc.columbia.edu     Description

 MSPAAA HLP        kermit/a/mspaaa.hlp        Introductory comments
 MSPDMP ASM        kermit/a/mspdmp.asm        For Radio Shack DMP200 (source)
 MSPDMP BOO        kermit/a/mspdmp.boo          Encoded binary
                   kermit/bin/mspdmp.com        Binary
 MSPE24 C          kermit/a/mspe24.c          For Epson LQ 2500 (source)
 MSPE24 BOO        kermit/a/mspe24.boo          Encoded binary
                   kermit/bin/mspe24.exe        Binary
 MSPHPL C          kermit/a/msphpl.c          For HP Laserjet (source)
 MSPHPL BOO        kermit/a/msphlp.boo          Encoded binary
                   kermit/bin/msphlp.exe        Binary

And from Mark Buda at DEC:

 MSPVPC COM        kermit/a/mspvpc.com       "pcprint" for VAX/VMS

And produced locally:

 MSELAT C          kermit/a/mselat.c         Shift-In/Shift-Out filter
 MSPEP4 C          kermit/a/mspep4.c         CP437-to-Epson translation
 MSPEP4 HLP        kermit/a/mspep4.hlp         Help file
 MSPEP4 BOO        kermit/a/mspep4.boo         Encoded binary
                   kermit/bin/mspep4.exe       Binary

MSPVPC.COM is a VAX/VMS DCL command file that prints VMS files on the PC's
local printer, using Kermit's transparent print function, similar to the UNIX
shell script MSPUPC.SH ("pcprint"), which has been in Kermit Distribution for
some time.

MSELAT.C is a UNIX filter for displaying UNIX-resident 8-bit Latin Alphabet 1
files on the PC screen with MS-DOS Kermit 3.00 or later (or on a DEC VT320/340
terminal) in the 7-bit environment (that is, when your connection to the UNIX
system is 7 data bits + 1 parity bit).

The MSPEP4 program translates from IBM PC Code Page 437 to the character set
of the Epson FX and RX series of printers, so that PC files containing
accented characters can be printed correctly.  This is not a printer driver,
but rather an input/output filter (as in "mspep4 < file.txt > prn").

Finally, we have a few VT320 termcap submissions for use on UNIX systems,
none of them evaluated locally.  These are collected together in the file
MSVIBM.TC (kermit/a/msvibm.tc on watsun).

------------------------------

Date: Wed 7 Mar 1990 13:40:02 EST
>From: Christine M Gianone <[e-mail]>
Subject: MS-DOS Kermit Help File in German
Keywords: German, MS-DOS Kermit 3.0 German Help File
Keywords: International Character Sets

Gisbert W. Selke of Bonn, West Germany, has translated the MS-DOS Kermit
3.00 help file into German.  Because this file is much longer than the help
file for version 2.32/A, this was quite a job compared to the last time he
did this!

In celebration of new international character set capabilities of MS-DOS
Kermit 3.00, this file was written by Gisbert using the 8-bit Latin Alphabet
One, so that German special characters are rendered correctly without
sacrificing the brackets, backslashes, and forth have (as they would have
been if the German 7-bit ISO 646 national replacement character set had been
used).  This presents a certain difficulty for network users who do not have
a clear 8-bit path for obtaining this file.

Therefore, Kermit itself was used to translate this file from Latin 1 into
"ASCII German" (in which umlaut-a becomes ae, etc), and the Latin-1 version
was stored in its original form in the kermit/bin directory on watsun only,
and was also converted to a .BOO file for other network transfers.

BITNET/EARN       Internet
KERMSRV@CUVMA     watsun.cc.columbia.edu     Description

 MSKGER HLP        kermit/a/mskger.hlp        ASCII plain text version
 MSKGER BOO        kermit/a/mskger.boo        Encoded 8-bit Latin-1 version
                   kermit/bin/mskger.lat      Original 8-bit Latin-1 version

If you put the 8-bit version on a UNIX system, you can use the mselat.c
utility announced above to view it in all its diacritical glory.  On a
VAX/VMS system, it can be viewed directly if you tell MS-DOS Kermit to SET
DISPLAY 8 and you tell the VAX to SET TERMINAL /EIGHTBIT.  Within a few
weeks (barring unforeseen disasters) there should be new beta test versions
of C-Kermit and IBM mainframe Kermit that you can use to transfer this file
to your PC with all the special characters correctly translated.

Note: the file, as sent from West Germany to the USA via BITNET mail, was
somewhat damaged in transit, and had to be reconstructed -- correctly, one
hopes.  Any errors in German orthography are due to this reconstruction.

Many thanks to Gisbert for this contribution!

------------------------------

Date: Wed 7 Mar 1990 12:40:02 EST
>From: Christine M Gianone <[e-mail]>
Subject: MS-DOS Kermit Demo Files
Keywords: MS-DOS Kermit 3.0 Demos, MS-DOS Kermit 3.0 Graphics

The terminal emulator demonstration files that are included on the MS-DOS
3.00 distribution disk are now also available on the networks.  Thanks to
Gisbert W. Selke of Bonn, West Germany, for taking the trouble to turn them
into .BOO files (to be decoded into their original form using any of the
MSBPCT programs).  The original "binary" versions are also available in
kermit/bin on watsun, as shown below.

BITNET/EARN       Internet
KERMSRV@CUVMA     watsun.cc.columbia.edu     Description

 MSDAAA HLP        kermit/a/msdaaa.hlp        Introduction to demo files
                   kermit/bin/msdcas.hgr      Heath-19 Demo: CASTLE.HGR
 MSDCAS BOO        kermit/a/msdcas.boo          Encoded version
                   kermit/bin/msdpat.hgr      Heath-19 Demo: PATTERN.HGR
 MSDPAT BOO        kermit/a/msdpat.boo          Encoded version
                   kermit/bin/msdcha.vt       VT320 Demo: CHARDEMO.VT
 MSDCHA BOO        kermit/a/msdcha.boo          Encoded version
                   kermit/bin/msdcol.vt       VT320 Demo: COLORS.VT
 MSDCOL BOO        kermit/a/msdcol.boo          Encoded version
                   kermit/bin/msdfea.vt       VT320 Demo: FEATURES.VT
 MSDFEA BOO        kermit/a/msdfea.boo          Encoded version
                   kermit/bin/msdemo.tek      Tektronix Demo: DEMO.TEK
 MSDEMO BOO        kermit/a/msdemo.boo          Encoded version
                   kermit/bin/msdusa.tek      Tektronix Demo: USA.TEK
 MSDUSA BOO        kermit/a/msdusa.boo          Encoded version

Additional demo files welcome!

------------------------------

Date: Sun, 4 Mar 90 7:22:28 CDT
>From: [e-mail] (David J. Camp)
Subject: Proposed Mapping for IBM-PC Function Keys
Keywords: MS-DOS Kermit 3.0 Key Mapping, Key Mapping

In an attempt to define some standards for the mapping of IBM-PC Function
Keys (F-keys) into ansi escape sequences, I have been studying how various
terminals and software packages work.  This is by no means a complete
investigation, and I have not made reference to any standards documents.
The table of those keys sent by these programs is below.

The first column is from the mskermit.ini take file that we are using now.
The author professed that his choices were somewhat arbitrary, so it is just
here for reference.  The second is the codes sent by NCSA_Telnet.  The third
are those sent by kermit when no mskermit.ini file is present.  The values
in parentheses are those returned by the kermit 'show key' function.  The
vt220 definitions are derived from a Dec vt240 Series Programmer Reference
Manual, experiments with a real vt240, and information about mapping 8-bit
escape sequences into 7-bit escape sequences provided by Joe Doupnik on the
info-ibmpc mailing list.

The last column is my proposed standard.  I welcome your comments.  We plan
to provide mapping tables for these key sequences in various formats.  Those
include kermit take files with 'set key' definitions, NCSA_Telnet config.tel
files, 'dkey' program scripts, Unix termcap and terminfo entries.

We will also be establishing a set of definition for how these keys are used
by Sas on our Unix system.  There is some debate over whether these should
reflect the operation of PC-Sas or perhaps CMS-Sas.  The CMS-Sas operation
seems more in line with what little I know about SAA, but some people are
already getting used to the PC-Sas definitions and want those instead.  I
welcome debate on the subject.

Note: a real vt240 has two sets of function keys. PF1-PF4 are called the
"Auxiliary Keypad Keys".  F1-F20 are called the "Top Row Function Keys".
F1-F5 are reserved for functions local to the terminal.

kermit keys:
            wubk NCSA     Kermit           vt240         recommended
            ermit         Default
            .ini
F1          ^[OP ^[OP     ^[OP             PF1=^[OP      ^[OP
F2          ^[OQ ^[OQ     ^[OQ             PF2=^[OQ      ^[OQ
F3          ^[OR ^[OR     ^[OR             PF3=^[OR      ^[OR
F4          ^[OS ^[OS     ^[OS             PF4=^[OS      ^[OS
F5          ^[Om ^[Om     ^[Ow (\Kkp7)                   ^[Om
F6          ^[Ol ^[Ol     ^[Ox (\Kkp8)     F6= ^[[17~    ^[[17~
F7          ^[On ^[On     ^[Oy (\Kkp9)     F7= ^[[18~    ^[[18~
F8          ^[OL ^[Ov     ^[Om (\Kkpminus) F8= ^[[19~    ^[[19~
F9          ^[Ok ^Z       ^[Ot (\Kkp4)     F9= ^[[20~    ^[[20~
F10         ^[OM ^[OM     ^[Ou (\Kkp5)     F10=^[[21~    ^[[21~
F11                                            ^[[23~    ^[[23~
F12                                            ^[[24~    ^[[24~
F13                                            ^[[25~
F14                                            ^[[26~
F15                                            ^[[28~
F16                                            ^[[29~
F17                                            ^[[31~
F18                                            ^[[32~
F19                                            ^[[33~
F20                                            ^[[34~
AF1                                                      ^[[23~
AF2                                                      ^[[24~
AF3                                                      ^[[25~
AF4                                                      ^[[26~
AF5                                                      ^[[28~
AF6                                                      ^[[29~
AF7                                                      ^[[31~
AF8                                                      ^[[32~
AF9                                                      ^[[33~
AF10                                                     ^[[34~
SF1                       ^[Ov (\KKP6)
SF2                       ^[Ol (\Kpcoma)
SF3                       ^[Oq (\KKP1)
SF4                       ^[Or (\KKP2)
SF5                       ^[Os (\KKP3)
SF6                       ^[OM (\Kkpenter)
SF7                       ^[Op (\KKP0)
SF8                       ^[On (\Kkpdot)
Alt+0            ^[Op                                    ^[Op
Alt+1            Oq                                    ^[Oq
Alt+2            Or                                    ^[Or
Alt+3            Os                                    ^[Os
Alt+4            Ot                                    ^[Ot
Alt+5            Ou                                    ^[Ou
Alt+6            Ov                                    ^[Ov
Alt+7            Ow                                    ^[Ow
Alt+8            Ox                                    ^[Ox
Alt+9            Oy                                    ^[Oy
Insert      ^[?H                               ^[[2~     ^[[2~
Delete      ^[?S ^On      \127 (DEL)           ^[[3~     ^[[3~
Up Arrow    ^[OA ^[OA     ^[OA (\Kuparr)       ^[OA      ^[OA
Left Arrow  ^[OD ^[OD     ^[OD (\Klfarr)       ^[OD      ^[OD
Down Arrow  ^[OB ^[OB     ^[OB (\Kdnarr)       ^[OB      ^[OB
Right Arrow ^[OC ^[OC     ^[OC (\Krtarr)       ^[OC      ^[OC
Prev Screen ^[?i ^[Ou^[Ox      (\Kupscn)       ^[[5~     ^[[5~  (PgUp)
Next Screen ^[?k ^[Ot^[Ox      (\Kdnscn)       ^[[6~     ^[[6~  (PgDn)
Home        ^[?a ^H            (\Khomscn)                ^[1~
End         ^[?j ^[Ot^[Or      (\Kendscn)                ^[4~
Ctrl+PgUp   ^[?c ^[Ou^[Ow      (\Kupone)
Ctrl+PgDn   ^[?d ^[Ot^[Ow      (\Kdnone)
Ctrl+End    ^[?b ^[OP^[Ot      (\Kdump)
Ctrl+Home   ^[?a
Find                                           ^[1~
Select                                         ^[4~

Bitnet:   [e-mail]                ^      Mr. David J. Camp
Internet: [e-mail]   < * >    Box 8067, Biostatistics
uucp:     uunet!wugate!wubios!david         v      660 South Euclid
Washington University (314) 36-23635               Saint Louis, MO 63110

[Ed. - Thanks, David!  Kermit's key mapping is a powerful customizing
feature.  The built-in defaults, as well as any particular "standard" that
may be proposed, will never please everybody.  In particular, the difference
in layout between the old and new IBM keyboards is always a problem.  And
among users there are two basic schools of thought: "Kermit's keys should
follow the labelling on the keytops" versus "Kermit's keys should be in the
same relative positions as the DEC keyboard's keys".  And then we have the
Num Lock problem: Num Lock is where you want your DEC PF1 or Gold key to be,
but Num Lock is inaccessible to SET KEY.  Further discussion welcome, as are
submissions of key definition files for popular applications (note, however,
that IBM 3270 protocol converter key mapping configurations tend to be
extremely site-dependent).  Quite a few of these files have been available
for some time as MSI*.*.  Some that recently arrived, for example from Kevin
Lowey at the University of Saskatchewan and Pierre Valiron in France, are in
a new file MSIKEY.HLP.]

------------------------------

Date: Sun, 18 Feb 90 22:40:01 EET DST
>From: Timo Salmi LASK<[e-mail]>
Subject: More MS-DOS Kermit Utilities: For Your Information with Thanks
Keywords: MS-DOS Kermit Utilities

Sun 18-Feb-90: With the introduction of the new Kermit version 3.00 in
January 1990, I have decided to update my MsKermit utilities accordingly,
and released (/pc/ts/)tskerm24.arc.  I have tried to build the system so
that it would still be compatible with MsKermit version 2.32A.  You will
thus have a choice between the two, and the tools should be useful even if
you have not yet updated to MsKermit version 3.00.  I have also included
some more postings and messages about Kermit with the kind permission of the
authors.  Available by anonymous ftp from chyde.uwasa.fi as usual.  If you
have not yet got MsKermit version 3.00 it can be obtained as
(/pc/pd2/)msker300.zip.

...................................................................
Prof. Timo Salmi        (Moderating at anon. ftp site 128.214.12.3)
School of Business Studies, University of Vaasa, SF-65101, Finland
Internet: [e-mail] Funet: gado::salmi Bitnet: salmi@finfun

TSKERM24.ARC    MsKermit utilities by Timo Salmi
Filename        Comment                             Date      Time    CRC
 -------        --------------------------------    ----      ----    ---
ANSI.CMD        Impose ansi terminal emulations   12-28-89  20:58:54  B3BB
GETBIN.CMD      Automatic file transfer to PC     12-21-89  14:42:06  DE7F
GETTEXT.CMD     Automatic file transfer to PC     12-21-89  14:45:12  B384
INITAT.CMD      Call all other initializations    12-23-89  09:46:50  EA88
INITAT30.CMD    Call 3.00 initializations, AT     01-12-90  10:33:50  E592
INITZN.CMD      Call initializations, laptop      12-23-89  09:47:12  B582
INITZN30.CMD    Call 3.00 initializations laptop  01-20-90  15:51:08  4A48
KERM.BAT        A simple boot for MsKermit 2.32A  02-11-89  12:10:04  3862
MEMACSAT.CMD    MicroEmacs Home End PgUp PgDn..   12-23-89  09:41:18  06C7
MEMACSZN.CMD    MicroEmacs Home End etc, laptop   12-23-89  09:40:22  F501
MSE.BAT         Boot MsKermit, colors, log boots  02-18-90  10:19:48  DFE1
MSK.BAT         Selective boot of MsKermit 2.32A  02-18-90  10:36:26  9809
MSK230QL.INI    VT102 keypad simulating QL QCODE  08-12-88  05:10:56  E8A0
MSK232AT.INI    VT102 keyboard for an AT or 386   01-14-90  17:46:42  0CBA
MSK232ZN.INI    VT102 keyboard for a laptop       12-29-89  16:09:48  85AE
MSK300AT.INI    VT102 for AT & 386 MsKermit 3.00  02-18-90  09:15:52  E2D3
MSK300ZN.INI    VT102 for laptopt, Mskermit 3.00  02-18-90  09:14:44  BFA6
MSZ.BAT         This I use on my laptop           12-23-89  10:15:26  44A7
MSZ30.BAT       This I use on my laptop for 3.00  02-18-90  10:10:42  4D5A
PHONE.CLL       Phone using a dialing directory   12-24-89  14:31:04  BF30
PUTBIN.CMD      Automatic file transfer from PC   12-21-89  14:44:38  DDE6
PUTTEXT.CMD     Automatic file transfer from PC   12-21-89  15:07:20  6405
SAMPLE.CLL      Autodialing! with MsKermit        08-12-88  22:23:28  9388
TIMELOG.EXE     For logging program usage         08-14-88  16:48:22  8A51
TSKERM.INF      Document                          02-18-90  21:49:46  C837
TSKERM.NWS      News announcements about tskerm   02-18-90  13:28:38  84FB
TSKERM.POS      Interesting postings and email    02-18-90  19:30:18  E0E8
TSPROG.INF      List of PD programs from T.Salmi  10-28-89  16:59:34  D436
VAASA.INF       Info: Finland, Vaasa, U of Vaasa  02-02-90  11:52:54  F6C0
ZSET.CMD        Set command synonyms, zmodem etc  02-18-90  09:33:54  A454
 ---            ------             ------  -----
0030            123195              66262   47%

[Ed. - An amazing amount of work!   This is a little bit too much for us to
handle at Columbia, but we are happy to post this announcement on Timo's
behalf.]

------------------------------

End of Info-Kermit Digest
*************************

From cmg  Mon Apr  2 17:05:02 1990
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA22125; Mon, 2 Apr 90 17:05:02 EDT
Date: Mon, 2 Apr 90 17:05:01 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V11 #6
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Mon, 2 Apr 1990        Volume 11 : Number 6

Today's Topics:

    Announcing MS-DOS Kermit 3.01 for the IBM PC and PS/2 Families
              Announcing VAX/VMS Kermit 3.3.118
                New .BOO-File Unpacker
        MacKermit and Shiva NetSerial Box on Appletalk

Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.0), IP host number 128.59.39.2.  Login as user
anonymous (note, lower case), any password, and GET or MGET (MULTIPLE GET)
the desired files.  The Kermit files are in directories kermit/a, kermit/b,
kermit/c, kermit/d, and kermit/e.  Test versions are in kermit/test.  You
can also get Kermit files over the BITNET/EARN network; to get started send
a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA.
For detailed instructions, read the file kermit/a/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: Tue Mar 20 20:16:02 1990
>From: Christine M Gianone <[e-mail]>
Subject: Announcing MS-DOS Kermit 3.01 for the IBM PC and PS/2 Families
Keywords: MS-DOS Kermit 3.01

This is a maintenance release of MS-DOS Kermit.  It incorporates all the
3.00 patches that were announced in the previous issue of Info-Kermit, and it
also includes other fixes and a couple new features, including:

 - Support for 75/1200 bps split speed operation (SET SPEED 75/1200),
   contributed by Dan Norstedt of the Stacken Computer Club in Sweden.
 - A change to the way SET TRANSLATE INPUT works to allow it to operate
   on 8-bit characters received in the 7-bit (parity) environment via single
   or locking shift mechanisms.
 - Automatic transmission of shift characters when typing 8-bit characters in
   the 7-bit (parity) environment.
 - Ability to use C1 control characters for graphics if terminal character
   set is TRANSPARENT.
 - Numerous character set translation corrections.
 - Improved operation with IBM EBIOS / LANACS (new command SET PORT EBIOS n),
   with help from Yale and IBM.
 - Improved operation with Novell file server disks.
 - Various minor fixes to Tektronix and VT terminal emulators.
 - Reinstatement of the "LEDs" in the VT320 mode line.
 - Other minor fixes.

The new files have been installed in the regular places:

BITNET/EARN       Internet
KERMSRV@CUVMA     watsun.cc.columbia.edu     Description

                   kermit/a/msvibm.exe        Executable binary
 MSVIBM   BOO      kermit/a/msvibm.boo        Encoded binary
 MSR301   UPD      kermit/a/msr301.upd        List of changes
 MSR300   PCH      kermit/a/msr300.pch        Patches for version 3.00
 MSR301   PCH      kermit/a/msr301.pch        Patches for version 3.01
 MSKERM   BWR      kermit/a/mskerm.bwr        Updated "beware" file
 MSS*     *        kermit/a/mss*.*            New sources

The patches for version 3.00 are no longer needed (and in fact cannot be used)
with 3.01.  The patches for version 3.01 include an optional patch to make
80/132 column switching work with different varieties of Orchid Designer
Professional VGA boards, of which different models use different video modes
yet identify themselves exactly the same way to Kermit.  Note that the version
3.00 patch file was renamed from MSKERMIT.PCH to MSR300.PCH, but that after
downloading MSR301.PCH, you must still rename it back to MSKERMIT.PCH in order
for the patches to take effect.

On behalf of all of us, thanks to Professor Joe R. Doupnik for putting this
new maintenance release together, and to those who sent in new code, problem
reports and suggestions, and who helped out with the testing.

Additional maintenance releases will probably appear from time to time, so
keep the reports coming in.

------------------------------

Date: 7 Feb 1990
>From: Burt Johnson, Diversified Computer Systems, Boulder, CO
Subject: Announcing VAX/VMS Kermit 3.3.118
Keywords: VAX/VMS Kermit 3.3.118

[Ed. - This new release of VAX/VMS Kermit-32 is most likely a one-shot deal.
Burt has definitely not committed to take over support of the program.
Future VAX/VMS Kermit development will focus on C-Kermit.]

This version has added support for extended length packets.  Extended length
packets are supported by the normal SET RECEIVE PACKET and SET SEND PACKET
commands.  Sizes up to 1000 are allowed.  By default, extended length
packets are not used.  Typically, use SET RECEIVE PACKET 1000 and SET SEND
PACKET 1000 to enable it.  If you want this as your packet default, write
these two SET commands into an initialization file like KERMIT.INI.  By
defining the logical VMSKERMIT = mydisk:[mydir]KERMIT.INI, your KERMIT
session will default to a packet size of 1000.

Also, removed update to 3.3.107 that prevented quitting on receipt of an
Error packet while in server mode.  This also didn't allow for Ctrl-Cs to
work properly.

This update is an adaptation of Dan Norstedt's KERMIT-10 3(134) release.
Because of increased program size for this update, word relative addressing
boundaries were exceeded.  A non-transportable PSECT redirection statement
was used to put PLIT messages within the word relative boundary as a quick
fix to correct this problem.  The .MAR files are generated from the Bliss-32
sources on a VAX/VMS 5.0 operating system (sorry, this is the oldest VMS
operating system I have available).  The KERMIT 3.3.117 executable that was
generated under VMS 4.3 remains available as the hex file VMSV43.HEX.

Regards,
Burt Johnson

[Ed. - Thanks, Burt!  The new files have NOT replaced the old ones in the
standard Kermit distribution areas, but rather have been placed in the test
area as follows:

BITNET/EARN       Internet
KERMSRV@CUVMA     watsun.cc.columbia.edu     Description

 T:VMSCOM   REQ    kermit/test/vmscom.req     Symbol definitions
 T:VMSMIT   BLI    kermit/test/vmsmit.bli     Main program source code
 T:VMSMSG   BLI    kermit/test/vmsmsg.gli     Protocol module source code
 T:VMSMIT   HEX    kermit/test/vmsmit.hex     Encoded binary
 T:VMS43    HEX    kermit/test/vms43.hex      Encoded binary of 3.3.117

The encoded binary can be decoded back into KERMIT.EXE using the program
VMSDEH.MAR.  Read VMSAAA.HLP for instructions.  Please get the new files, test
the new version thoroughly, and report results back to us, so we'll know
whether we can replace the current release with this new one.  Thanks!]

------------------------------

Date: Sat, 17 Feb 90 04:47:12 +0100
>From: Dan Norstedt <[e-mail]>
Subject: New .BOO-File Unpacker
Keywords: BOO Files, MSBPCT, MS-DOS Kermit Utilities

I have been thinking about .BOO-file distribution, and came up with the
following MS-DOS program, which makes ASCII capture and EDLIN sufficient
tools to convert .BOO files:
 ----- cut here -----
XPHPD[0GG0G,0G51G31GB'(G+(G:u'0g?(G>(GE1G@arwIV_F*=US@<1|_,5wXNg-7muTu(4
1m2?352t0osr2e3K1q2s0s3e0W1_F0:sss1@2G0t1k0s3p0@3T1m3>52f3>1k0t3<2C0@3T2
K1g2?0@3T1Fm3U51g3<1q0s3:0@3T1g3r1l0ts1>0I@3T1m3i52e0O2;h0L1_Eg352s0m3S2
j0W1g3of0<1;2?0r1m0s3:1>0m@3T2e0R1FH2E1m0s3:1>0B3^0=2g3=1g3s0@3T2e0@3^1t
2e0<1>0m1m0s361>0e1l0s371g3r1:0P@3T1:0P2e1hDk0s3q0V1F2M1_3_c2o3Z1=0Y1=0c
2s0o2Ag3H0CSCS1:0=F[1:0=2s0]352k0t1]2s0U390^3<1KL2D1Dc0sf1]2L0UE^1T2HfTZ
X3mS2@F5C6G3S2Y\_X3a25BB3W2HacTV^\aZ3S2gb3S2Y\_X3mSW28eebe3S2Whe\aZ3S2Y\
_X3S2<3b2B3W2Abg3S2XabhZ[3S2`X`bel3W4
 ----- cut here -----
Right, the above IS the executable code; just cut and name it MSBPCT.COM!

[Ed. - Diabolical!  The program which generated this extraordinary printable
COM file, written by Dan in assembly language, is in ~kermit/a/msbpcx.asm, and
a copy of the COM file itself (in case some of the characters did not survive
the e-mail translations) is in ~kermit/a/msbpct.com.  Also in MSBPCX ASM and
MSBPCT COM on KERMSRV at CUVMA for BITNET/EARN access.  Thanks, Dan!]

------------------------------

Date: Fri, 30 Mar 90 11:17:23 EST
>From: Paul W Placeway <[e-mail]>
Subject: MacKermit and Shiva NetSerial Box on Appletalk

RE: [e-mail] comments

>    We recently acquired version 0.98(63) or Kermit for the Macintosh,
>   dated 02/21/90.  We have been running MacKermit using a modem connected
>   via a Shiva NetSerial box on the Appletalk network.  The NetSerial box
>   can emulate the modem port or the serial port.

[From Paul: Sounds like the Shiva will _mostly_ emulate a serial port...]

>    We have found that when quitting MacKermit 0.98(63), there is an
>   error box displayed with the message "trouble closing serial port input
>   driver: 2240".  This happens when using the modem port or the serial port.
>   When you acknowledge the error by clicking "ok", then MacKermit goes ahead
>   and quits.

[From Paul: You should run with "Drop DTR on Close" checked, as the Shiva
driver seems to be having problems with the Serial Driver call to keep DTR up
on close.  This may have the undesirable side effect of hanging up the phone,
however.  The only real way around this is to use Kermit under MultiFinder,
and just switch out to do StuffIt and such.]

>     Additionally, when using the serial port, there is another error
>   message displayed when sending or receiving files.  The message says
>   "Bad input clear -28", and it pops up about every other packet.  If you
>   go ahead and click "ok", the file transfer continues, and in fact, the
>   files seem to be transferring ok.  This does not happen at all when using
>   the modem port.

[From Paul: Another bug in the Shiva driver -- in this case Kermit is trying
to do the Serial Driver call to clear the input queue, and the Shiva isn't
dealing with it well.  I will try to do something of a work-around for the
next version...]

>     The previous version of MacKermit we were using is version 0.9(40),
>   dated 04/05/88.  We have not seen either of these two problems with that
>   version of MacKermit.  We have seen the problems on both a MacPlus and
>   SE/30.

[From Paul: It didn't do either of the above calls, so you didn't see the
problem before.

You might try calling up Shiva tech support and complaining at them.
Tell them that you are having problems with their driver not
responding to handshaking control calls and buffer management control
calls.

        -- Paul Placeway <[e-mail]>]

------------------------------

End of Info-Kermit Digest
*************************

From cmg  Wed May 16 15:11:01 1990
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA19743; Wed, 16 May 90 15:11:01 EDT
Date: Wed, 16 May 90 15:11:00 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V11 #7
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest           Wed, 16 May 1990            Volume 11 : Number 7

Departments:

  KERMIT-370 -
        Announcing IBM Mainframe Kermit-370 Version 4.2
        Announcing IBM Mainframe VM/CMS Kermit-370 Version 4.2
        Announcing IBM Mainframe MVS/TSO Kermit-370 Version 4.2
        Announcing IBM Mainframe MUSIC/SP Kermit-370 Version 4.2
        Using CMS 6 Shared File System with Kermit

  VAX/VMS KERMIT -
        New Kermit-32 Release for VAX/VMS

  MS-DOS KERMIT -
        New MS-DOS 3.01 Patch File

  KERMIT NEWS -
        Kermit News Number 4 Is on the Way

  MACINTOSH KERMIT -
        MacKermit Questions and Answers
           About MacKermit...
           Kermit bug
           MacKermit 0.98(62), terminalr, terminals, Print
           Mac Kermit Print Option?
           Bug report on Mac Kermit 0.98(62)

Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.0), IP host number 128.59.39.2.  Login as user
anonymous (note, lower case), any password, and GET or MGET (MULTIPLE GET)
the desired files.  The Kermit files are in directories kermit/a, kermit/b,
kermit/c, kermit/d, and kermit/e.  Test versions are in kermit/test.  You
can also get Kermit files over the BITNET/EARN network; to get started send
a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA.
For detailed instructions, read the file kermit/a/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: Tue 8 May 1990 16:46:42 EDT
>From: "John F. Chandler"  <[e-mail]>
Subject: Announcing IBM Mainframe Kermit-370 Version 4.2
Keywords: IBM 370 Kermit
Xref: IBM Mainframe, See IBM 370
Xref: Kermit-370, See IBM 370, VM/CMS, MVS/TSO, MUSIC

This is to announce Kermit-370 Release 4.2.  The sources have not been
completely rewritten, nor have they been resequenced, but numerous
fixes, extensions, and improvements have been inserted.  The changes
applied include all updates formerly available in the various system-
specific update files plus many new ones.  All the variants of
Kermit-370 are being re-released simultaneously; see the accompanying
system-specific announcements for further details: IKCKER.ANN (CMS),
IKMKER.ANN (MUSIC), and IKTKER.ANN (TSO).  Anyone interested in helping
to port Kermit-370 to still other operating systems should contact John
Chandler <[e-mail]> or <[e-mail]>.

Below is a list of the generic changes in Version 4.2 of Kermit-370,
including those appearing in intermediate releases:

1)  New syntax for sending partial files by line numbers.

2)  Implementation of the new level-1 international transfer syntax being
    developed at Columbia.  See file ISOK5.TXT in the Kermit distribution for
    a description of the syntax.  Kermit-370 includes support for files stored
    using numerous IBM Country Extended Code Pages and transfers using
    character sets ASCII, CYRILLIC, GREEK, HEBREW, KATAKANA, and LATIN1.  The
    facility currently supports text files in the following languages:
    Bulgarian, Byelorussian, Danish, Dutch, English, Faeroese, Finnish,
    French, Gaelic, German, Greek, Hebrew, Icelandic, Italian, Japanese
    (Katakana), Latin, Macedonian, Norwegian, Portuguese, Russian, Serbian,
    Spanish, Swedish, Ukrainian, Welsh, and Yiddish.  In extending support to
    other languages, the limiting factor has been the shortage of information
    about character set arrangements for file storage on 370-compatibles.
    Anyone with such information is urged to forward it to the Center for
    Computing Activities at Columbia University.

3)  New syntax for specifying the response to filename collision, largely
    as specified in Kermit Digest V. 11 #1.  SET WARNING and SET APPEND
    are still available but are not documented.

4)  Kermit-370, when receiving a file, now attempts to honor the
    attributes specified by the sending Kermit, not including the Date
    attribute.

5)  New option to ignore any attribute, both for sending and receiving.

6)  Support for the MAIL, PRINT, and SUBMIT Disposition attributes via
    system-specific command invocations.  Implementations are intended to
    be site-specific as well, but a few samples are available.

7)  New provision for an accounting exit routine to be called after
    completion of each session of SEND or RECEIVE.

8)  Freedom to redefine anything in the ATOE/ETOA tables, even CR or LF,
    as long as the TATOE/TETOA tables are either correct or irrelevant.

9)  New, separate error message for receiving a "packet" containing no
    start-of-packet character.

10) Compatibility with the (aging) F-level assembler.

11) Assembly-time consistency check on the source components.

12) Edit number announced at start-up, in addition to release and date.

13) "In-core" files sent as TEXT, regardless of the current file TYPE.

14) Recover if an I-packet is denounced as an error or if the S-packet of
    a long reply is lost.

15) New SET SERVER-TIMEOUT subcommand.

16) SET BAUD changed to SET SPEED.

Incidentally, the generic update program GUPI has been updated, but the
old version will still work.  You need not recreate it, but if you do,
be sure to use all-new sources, or it will not assemble properly.

Many thanks to the beta testers who have helped work out the bugs in the
new release.

------------------------------

Date: Tue 8 May 1990 16:46:42 EDT
>From: "John F. Chandler"  <[e-mail]>
Subject: Announcing IBM Mainframe VM/CMS Kermit-370 Version 4.2
Keywords: IBM 370 Kermit, VM/CMS Kermit
Xref: IBM Mainframe, See IBM 370
Xref: CMS Kermit, See VM/CMS Kermit, IBM 370

This is to announce CMS Kermit Release 4.2.  The sources have not been
completely rewritten, nor have they been resequenced, but numerous
fixes, extensions, and improvements have been inserted.  The changes
applied include all updates formerly available in IKCKER.UPD plus a
number of new ones.  As with Release 4.1, all CMS-specific files begin
with IKC, and generic Kermit-370 files begin with IK0 (I K Zero).  The
separate pieces are to be recombined into a single composite source (or
made into a macro library) for installation.  See the file IKCKER.INS
for instructions.  Release 4.2 is also being issued in the companion TSO
and MUSIC variants (see the separate announcements for details).  Anyone
interested in helping to port Kermit-370 to still other operating
systems should contact John Chandler <[e-mail]> or
<[e-mail]>.

For a list of generic additions, see the generic Kermit-370 announcement
IK0KER.ANN.  The following is a list of CMS-specific updates added since
Release 4.1.

1) New bimodal version for VM/XA in addition to the version for VM/SP.

2) Certain CP SET options which are not supported by VM/XA are now
   avoided by both CMS variants of Kermit when running under VM/XA.

3) GRAPHICS controllers are supported.

4) Extended PLIST for system commands, not just a tokenized PLIST.

5) Current HANDSHAKE character, if any, automatically appended to the
   string specified via SET PROMPT, unless the string is empty or
   already ends with the HANDSHAKE.

6) Alternate filespec syntax fn.ft.fm allowed in subcommands.

7) Prevent certain infinite waits on protocol-converter-type transfers.

Many thanks to the beta testers who have helped work out the bugs in the
new release.

------------------------------

Date: Tue 8 May 1990 16:46:42 EDT
>From: "John F. Chandler"  <[e-mail]>
Subject: Announcing IBM Mainframe MVS/TSO Kermit-370 Version 4.2
Keywords: IBM 370 Kermit, MVS/TSO Kermit, TSO Kermit
Xref: IBM Mainframe, Also see IBM 370
Xref: MVS/TSO Kermit, Also see MVS/TSO Kermit, IBM 370

This is to announce Release 4.2 of Kermit-370 for TSO.  The sources have
not been completely rewritten, nor have they been resequenced, but
numerous fixes, extensions, and improvements have been inserted.  The
changes applied include all updates formerly available in IKTKER.UPD
plus many new ones.  As with Release 4.1, all TSO-specific files begin
with IKT, and generic Kermit-370 files begin with IK0 (I K Zero).  The
separate pieces are to be recombined into a single composite source (or
made into a macro library) for installation.  See the file IKTKER.INS
for instructions.  Release 4.2 is also being issued in the companion CMS
and MUSIC variants (see the separate announcements for details).  Anyone
interested in helping to port Kermit-370 to still other operating
systems should contact John Chandler <[e-mail]> or
<[e-mail]>.

For a list of generic additions, see the generic Kermit-370 announcement
IK0KER.ANN.  The following is a list of TSO-specific updates added since
Release 4.1.

1) Implicit CLIST invocation now supported.

2) Missing host commands no longer result in ABEND's.  Kermit simply
   returns an "invalid host command" indication.

3) Migrated data sets are automatically recalled, if possible, before
   attempting to use them.  This includes especially the initialization
   files.

4) Sending PDS members by wildcard has been re-enabled.

5) The "MOD" date, as defined by ASM2 package, is now used (if it
   exists) instead of the creation date for sending the date attribute.

6) TSO commands may now be up to 256 bytes long and be mixed-case.

7) NOINTERCOM is set during transfers.

8) Automatic detection of VTAMTTY as opposed to plain TTY.

9) TTY-mode timeouts now work under MVS/XA and MVS/ESA.

10) Kermit HELP subcommand now works more than once per session.

Incidentally, the generic update program GUPI has been updated, but the
old version will still work.  You need not recreate it, but if you do,
be sure to use all-new sources, or it will not assemble properly.

Many thanks to the beta testers who have helped work out the bugs in the
new release.

------------------------------

Date: Tue 8 May 1990 16:46:42 EDT
>From:   Pierre Goyette   <[e-mail]>
Subject: Announcing IBM Mainframe MUSIC/SP Kermit-370 Version 4.2
Keywords: IBM 370 Kermit, MUSIC/SP Kermit
Xref: IBM Mainframe, Also see IBM 370
Xref: MUSIC/SP Kermit, Also see IBM 370 Kermit

This is to announce MUSIC Kermit Release 4.2.  The sources have not been
completely rewritten, nor have they been resequenced, but numerous
fixes, extensions, and improvements have been inserted.  The changes
applied include all updates formerly available in IKMKER.UPD plus a
number of new ones.  As with Release 4.1, all MUSIC-specific files begin
with IKM, and generic Kermit-370 files begin with IK0 (I K Zero).  The
separate pieces are to be recombined into a single composite source for
installation.  See the file IKMKER.INS for instructions.  Bug reports
should be sent to Pierre Goyette <[e-mail]>.  Release 4.2
is also being issued in the companion TSO and CMS variants (see the
separate announcements for details).  Anyone interested in helping to
port Kermit-370 to still other operating systems should contact John
Chandler <[e-mail]> or <[e-mail]>.

For a list of generic additions, see the generic Kermit-370 announcement
IK0KER.ANN.  The following is a list of MUSIC-specific updates added
since Release 4.1.

1) Correction of problem in SERIES1-type transfer I/O with large blocks.

Incidentally, the generic update program GUPI has been updated, but the
old version will still work.  You need not recreate it, but if you do,
be sure to use all-new sources, or it will not assemble properly.

Many thanks to the beta testers who have helped work out the bugs in the
new release.

------------------------------

Date: Fri, 1990 May 11   13:13 EDT
>From: "John F. Chandler"   <[e-mail]>
Subject: Using CMS 6 Shared File System with Kermit
Keywords: VM/CMS Kermit, Shared File System

CMS Kermit has been reported as unable to work with files in the Shared File
System (SFS) of CMS 6.  This is only partly true.  Because of the changed
length of FST entries in SFS, Kermit has been unable to tell whether a
specified file already exists, but it can store a file into the SFS
routinely.  There is now an update from East Texas State for determining the
proper length of FST entries (see IKCKER.BWR in the new release of CMS Kermit
-- thanks to Charles Becker for supplying the update and to M.R.  Cagle for
devising it), but problems have still been reported in locating the proper
FST.  If the source of these problems is the shared nature of SFS, the only
solution may be to give up Kermit's high-speed built-in FST routine and fall
back on the system GETFST function.  Anyone with information about the
organization of SFS FST's or anyone interested in halping to solve the "Case
of the Missing Files" should drop me a line.
                                  John

  <[e-mail]>  or  <[e-mail]>

------------------------------

Date: Tue, 15 May 90 13:35:57 EDT
>From: Christine M Gianone <[e-mail]>
Subject: New Kermit-32 Release for VAX/VMS
Keywords: VAX/VMS Kermit 3.3.122

VAX/VMS Kermit-32 Version 3.3.118, contributed by Burt Johnson, and announced
in Info-Kermit V11 #6, was not formally installed so that a testing period
could verify whether it could safely replace the previous release, 3.3.117.
Its major new feature was support for long packets (up to 1K in length).
Jonathan Welch, [e-mail], of the University of Massachusetts in
Amherst, picked up this version and fixed it up a bit, and now we are making
it "official" and releasing it as version 3.3.122.  Jonathan's changes
include:

 . Added the SET FILE BLOCKSIZE nnn (where nnn is the record size in bytes)
   command for incoming BINARY and FIXED file transfers.  If no blocksize has
   been specified the old behavior will be used.  Also modified SHOW FILE to
   display record size when appropriate.  People have been asking for this
   one for years!

 . The restriction on file name and type lengths is now 39 characters each.
   Previously the restriction was 9 characters for the name and 3 for the
   type (pre-VMS 4 format).

 . Under some circumstances if all kermit operations were successful a return
   status of 0 was generated; SS$_NORMAL is now returned instead.

 . If SS$_HANGUP occurs on the outgoing terminal line the user will be
   notified. If the outgoing line is serviced by a DECserver (LTA type
   terminal) the user must issue a CONNECT LTAnnn command to reestablish a
   LAT link to the DECserver.

 . Relative offsets to data structures are now longwords.  This change is an
   internal one which only those people compiling and linking Kermit-32 would
   be interested in, but it may allow the program to support packets even
   longer than 1K.

This version of Kermit-32 was linked under VMS 4.5, and so the VMSMIT.HEX
file requires VMS 4.5 or later to run.  If you have an earlier version of
VMS, then you can build Kermit-32 from the Macro-32 source code as outlined
in VMSAAA.HLP.  Jonathan will try to find a VMS 4.0 system to build the .HEX
file on, but in the meantime, if anyone else with VMS 4.0 would care to
contribute a VMSMIT.HEX file based on the new sources, it would be much
appreciated.

Meanwhile, Gary Stebbins sent in some new procedures for building VMS Kermit:
VMSINS.KIT is a VMS install kit, VMSMKH.COM is a DCL procedure for creating
the help files and library; VMSMKI.COM is a DCL procedure for creating the
VMSINSTAL file.  And Both Gary and Jonathan updated the help text; the new
version with both of their changes in it is VMSMIT.RNH.

Thanks to Jonathan and Gary, and once again to Burt, for their work on this
popular Kermit version.  The new files are in the B area of Kermit
Distribution: Tape B, kermit/b/ on watsun (anonymous ftp), and also on BITNET
KERMSRV at CUVMA.

The previous release of VMS Kermit, 3.3.117, is still available in
kermit/old, and the 3.3.118 test version has been removed from kermit/test.

------------------------------

Date: Mon, 14 May 90 12:34:56 EDT
>From: Christine M Gianone <[e-mail]>
Subject: New MS-DOS 3.0 Patch File
Keywords: MS-DOS Kermit 3.0 Patches

The patch file for MS-DOS Kermit 3.01 has been updated by Joe Doupnik to
correct the following problems:

  . Incorrect operation of REMOTE commands
  . Unwanted echo of path from CD command
  . Incorrect REMOTE LOGIN operation
  . Incorrect operation of ASK if invoked from within a macro
  . Incorrect operation of logging commands if invoked from within a macro
  . Problems with several VT320 and Tektronix escape sequences
  . Incorrect identifier for Latin-1 character set in Attribute packet
  . Failure to clear communication port buffer before sending a file

The updated patch file is in kermit/a/msr301.pch (watsun, Internet) and
MSR301.PCH (BITNET KERMSRV).

------------------------------

Date: Wed, 15 May 90 08:15:00 EDT
>From: Christine M Gianone <[e-mail]>
Subject: Kermit News Number 4 Is on the Way
Keywords: Kermit News #4

Kermit News Number 4 has gone to press -- 32 pages of news of Kermit
releases, plus world news, stories from users, and technical contributions
including a detailed analysis of Kermit's performance, and much discussion of
Kermit's new ability to handle international character sets.  If you are not
already on our mailing list and you would like to receive the new issue (free
of charge!), please send me your postal mailing address within the next few
days, so it can be added to the subscription list before the mailing labels
are printed.

------------------------------

Date: Wed, 18 Apr 90 17:54:51 EDT
>From: Paul W Placeway <[e-mail]>
Subject: MacKermit Questions and Answers
Keywords: Macintosh Kermit

   From: Haydn Huntley <[e-mail]>
   Subject: About MacKermit...

   Is it possible to change the size of the characters on the screen?
   It's nice to be able to fit so many on the screen at once, but
   sometimes I wish a 12 point font were available...

Coming soon (I've had a lot of requests, and have a large screen and poor
eyesight myself)...

   Also, do you allow people to use the source for MacKermit?  Is it
   available for ftp?

See the info-kermit intro.

   From: [e-mail] (Rudy Gobits)
   Subject: Kermit bug

   I want to report a possible bug in Kermit version 0.98(62) that I
   currently use. When sending a file compressed with Stuffit 1.51
   with the MacBinary option in 'File Defaults...' checked, and the
   host's file type set to binary, the file is transferred OK. However
   I end up with an 'eaten' stuffed file, i.e. the data fork length
   has been reduced to 0 (zero). This happened more than once, in fact
   it is 100% reproducible. I run Kermit on a Macintosh SE with System
   6.0.3.  Further I have a question: where do I get a manual for
   Kermit? I got this version of Kermit from a bulletin board in The
   Netherlands without manual.  Thank you for making Kermit.

Yes, there is a BAD bug in Kermit sending in MacBinary format: it
zeros the source file when closing it after transfer (not a real
useful feature), due to a screw-up (of mine) in the source code (some
of the code magically disapeared).

This will be fixed Real Soon Now; I am testing the file code a lot
trying to find any other problem points before leting the next version
out.  In the mean time, don't use MacBinary.

Hopefully no one has lost any work due to this.  Sorry.

   From: <#[e-mail]>
   Subject:  MacKermit 0.98(62), terminalr, terminals, Print

             From: Macintosh Conference System Opperator
                   (RobPlatt)

   I just got Kermit 0.98(62), and it is nice.

   Our mainframe programmers want to know, are terminalr and terminals
   supported? and are macros supported?

No, these are currently available only in MS-DOS Kermit.  Macros will probably
appear some time soon.  Programmable answer-back will never appear (it's too
much of a security hole).

   I am not a Kermit protocol expert, but your answers would help our
   mainframe programmers....

   and there is a Print menu up in the menu bar, but it is always grey.
   Should it be grey, or not? I have never seen it active/selectable???

The Print menu will light up if you send information at Kermit as if
it were a VT-xxx terminal with a local printer, that is, surround the text
to be printed with ESC [ 5 i (to start printing) and ESC [ 4 i (to stop).
More printer support is coming.

   From: Jay Graham <[e-mail]>
   Subject: Mac Kermit Print Option?

        Dear Sirs,

        I have a copy of the release of mac kermit .98(63) and it has a
        menu option that is inactive called "PRINT". Is there a way to
        capture text from an entire session or parts of a session and
        save it or print it at a later time? (END of session).

See above about what "PRINT" does.

You can currently save the text of a session by doing a "log session"
("Log" menu, "Session" item).  In a future version this will be able
to save all the characters too, but for the moment it only captures
lines displayed on the screen.

   From: [e-mail] (Todd Wilson Medlin)
   Subject: Bug report on Mac Kermit 0.98(62)

   I've noticed on several occasions that while using Get File From Server
   that if I interrupt with a command-. then the arrow icon is trashed and
   I get what I assume is a raw storage being used for the pointer.

   I'm on a 1M Mac Plus.

Interesting.  I must have a stray pointer problem to track down...

                --Paul

------------------------------

End of Info-Kermit Digest
*************************


From cmg  Fri Jun 22 12:53:12 1990
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA03324; Fri, 22 Jun 90 12:53:12 EDT
Date: Fri, 22 Jun 90 12:53:11 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V11 #8
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Fri, 22 Jun 1990        Volume 11 : Number 8

Today's Topics:
           Kermit News #4 Available On Line
     MS-DOS Kermit 3.02 Pre-Release Available for Testing
     MS-DOS Kermit 3.0 for Heath/Zenith-100 Available for Testing
         New MS-Windows Kermit Available for Testing
              Another New VMS Kermit-32
        Announcing Kermit 1.02 for the Honeywell DPS-6
     VMS DCL Procedure for Using WordPerfect with Kermit
   Okstate Kermit/UUCP Kermit Distribution Server Adds Trailblazer
        SIM3278 TCP/IP Version Supports Kermit-370 4.x
          Needed: Mac Kermit for a 128K Mac

Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.1), IP host number 128.59.39.2.  Login as user
anonymous (note, lower case), any password, and GET or MGET (MULTIPLE GET)
the desired files.  The Kermit files are in directories kermit/a, kermit/b,
kermit/c, kermit/d, and kermit/e.  Test versions are in kermit/test.  You
can also get Kermit files over the BITNET/EARN network; to get started send
a message with text HELP to KERMSRV, the Kermit file server, at host CUVMA.
For detailed instructions, read the file kermit/a/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, 22 Jun 90 12:30 EDT
>From: Christine M Gianone <[e-mail]>
Subject: Kermit News #4 Available On Line
Keywords: Kermit News #4, MS-DOS Kermit Utilities Diskettes

A plain-text ASCII version of Kermit News #4 is available online as
kermit/e/news.n4 on watsun (Internet) and NEWS.N4 from KERMSRV at CUVMA
(BITNET/EARN).  Meanwhile, the paper version has been mailed to all
subscribers and should have arrived by now.

Some people have asked what is on the 2-diskette set "MS-DOS Utilities and
Technical Documentation" that is listed on the order form in Kermit News.  A
list and description of the files is given in the file kermit/a/msauti.dsk on
watsun (and MSAUTI.DSK on KERMSRV).

------------------------------

Date: Tue, 19 Jun 90 13:59 EDT
>From: Christine M Gianone <[e-mail]>
Subject: MS-DOS Kermit 3.02 Pre-Release Available for Testing
Keywords: MS-DOS Kermit 3.02

Version 3.02 of MS-DOS version 3.0 for the IBM PC, PS/2, and comptibles, from
Professor Joe R. Doupnik of Utah State University is now available in a
priliminary prerelease form for testing.  MS-DOS Kermit users should be aware
that this will probably be the final release of MS-DOS Kermit in its present
form, because code space is completely used up.  The next release will
involve a massive reorganization of the code to make space for new features,
translation tables, etc.  Obviously, this will require a lot of time and
effort.

Version 3.02 fixes the bugs for which patches were required in the 3.00 and
3.01, as well as some problems that were not fixed by these patches.  It also
has some new features:

 . SET FLOW-CONTROL has a new option, RTS/CTS, for controlling sending and
   receiving of characters at the hardware level.  It is effective only for
   COM1..COM4 (real UARTs); selecting SET FLOW RTS/CTS for other
   communications ports is the same as SET FLOW NONE.  It is effective only
   when SET DUPLEX is FULL.

 . The port address of serial ports COM3 and COM4 may now be given to Kermit
   itself rather than being set externally, using the new commands:

     SET COM3 <address>
     SET COM4 <address>

   or in the DOS KERMIT= environment variable, as shown below.

   The IRQ value for these ports must still be 4 or 3. It is permissable to
   have two serial ports sharing the same IRQ line, provided only one is
   active at a time. Kermit does testing to discover which IRQ, 4 or 3, is
   used by the selected serial port.

 . The current list of commands recognized from the DOS environment lines
   starting with KERMIT=, KERMIT0=, KERMIT1=, etc, are:

        COM3 value                      value = port address (no default)
        COM4 value                      value = port address (no default)
        ROLLBACK value                  value = number of screens (def 10)
        INPUT-BUFFER-LENGTH value       value = size (in bytes) of the
                                          the script INPUT command buffer.

   Environment lines are constructed with the DOS command SET, which can be
   given at the DOS prompt or included in your AUTOEXEC.BAT file, for example:

        C> SET KERMIT=ROLLBACK 35;COM3 \x02f8;INPUT 256;

 . SET TERMINAL WIDTH {80, 132} allows you to manually set the screen width
   in text terminal emulation mode, provided your display adapter is capable
   of 132 column mode (IBM adapters -- MCGA, CGA, EGA, VGA) are not.  This
   was previously possible only with escape sequences transmitted from the
   host.  Screen width change is accomplished via the user-supplied files
   COLS80.BAT and COLS132.BAT.  Also, a bug which could cause Kermit to loop
   endlessly reading these files under certain conditions has been corrected.

 . SET TERMINAL ARROW-KEYS {CURSOR, APPLICATION} gives you manual control
   over the escape sequences sent by the arrow keys during VT100/300
   emulation.

 . SET TERMINAL BELL {AUDIBLE, VISUAL, NONE} has the new option "none" for
   people who prefer peace and quiet.

 . REMOTE PRINT <filespec> [ printer-parameters ] allows files to be sent to
   a Kermit server for printing rather than storage, provided the server
   supports this feature.  The MS-DOS Kermit server will also respond
   correctly to REMOTE PRINT commands.

 . SET KEY LK command to ask Kermit to look for an LK250 (DEC-style) keyboard
   driver.  Previously Kermit did this automatically, and this interfered
   with Kermit's correct operation on certain PCs.

 . SET TERMINAL BELL { AUDIBLE, VISIBLE, NONE } - New option to turn off
   the terminal bell entirely during terminal emulation, for use when your
   host application sends lots of irritating bells.

 . Explicit control over assignment of the left (and right, if any) half of a
   terminal character set to G0 through G3 through optional trailing
   parameters to the SET TERMINAL CHARACTER-SET command.  The exact design of
   this item is still fluid.  In this test release, it looks like this:

     SET TERMINAL CHARACTER-SET <name> [ G0 [ G1 [ G2 [ G3 ] ] ] ]

   For example, SET TERM CHAR LATIN1 G1.

This final item allows you to assign one or more character sets to the VT320
terminal emulator's tables, G0 through G3, by typing a command.  Formerly
this could only be done by escape sequences sent from the host.

An example where this override capability is handy is when LATIN1 needs to be
accessed from the keyboard or host with a single key command ^N or back again
with ^O.  These control codes are named SO and SI, respectively, and they
switch displaying of 7-bit characters from the usual ASCII table in G0 to the
table in G1, and back again.  Of course, the other computer receiving our
typing and providing our viewing must observe the same conventions.

The host can move LATIN1 to G1 by sending the escape sequence ESC - A (three
characters) or we can do it by hand with the command above.  A real DEC VT320
assigns the right half of Latin-1 to G2 and G3 by default, leaving ASCII in
G0 and G1.

Unfortunately, most people do not know how to get their hosts to send
strange escape sequences to put their terminal emulators into the right
frame of mind, and in some cases the host offers no way to do this.  Now you
can do it at Kermit command level.

The command:

  SET TERMINAL CHARACTER-SET <name>

works exactly as before, assigning the left (and right, if any) half of the
character set to the G0..G3 tables according the DEC's default assignments.

If you include one or more of G0, G1, G2, and G3 after the character set
name, Kermit will assign the character set only to the tables that you
mention, and will leave the others undisturbed.  The most common use of this
command will be to set up Latin-1 so it can be used without any special
action on the part of the host, simply by sending 8-bit characters or SI/SO:

  SET TERMINAL CHARACTER-SET LATIN1 G1

If the named character set is an 8-bit set (like Latin-1 or DEC-MCS) then the
right half of it (characters with their high bit set) is assigned to the named
table, which can be G1, G2, or G3, but not G0 (this is an international
standard, not an arbitrary and capricious Kermit rule!).  If it is a 7-bit set
(like ASCII, DUTCH, GERMAN, ITALIAN, NORWEGIAN, etc), then the entire set is
assigned to the named table (see pp.118-119 of "Using MS-DOS Kermit").

You can even use this command to assign up to four different character sets
to the four tables:

  SET TERM CHAR LATIN1           (ASCII  -> G0,G1; Latin-1 -> G2,G3)
  SET TERM CHAR LATIN1 G1        (Latin1 -> G1, replaces ASCII)
  SET TERM CHAR DUTCH G2         ("Dutch ASCII" -> G2)
  SET TERM CHAR DEC-SPECIAL G3   (DEC Special Graphics -> G3)

OK, so now how do you display all these characters once you have them
assigned to your G0..G3 tables?  Very briefly, the rules are (again, these
are international standards, and how the real DEC VT320 works):

  1. Two pointers are maintained, GLeft and GRight, each pointing to one
     of the four Gnumber tables. Initially, for VT300's GLeft points to G0
     and GRight to G2; VT100's have only G0 and G1 so GRight points to G1.

  2. When a 7-bit printable value arrives, the corresponding character
     is displayed from the table where GLeft points (normally G0).

  3. When an 8-bit printable value arrives, the corresponding character is
     displayed from the table where GRight points; that is usually G2 for
     VT300's. 8-bit characters will be seen only if you SET DISPLAY 8 and SET
     PARITY NONE, otherwise they get chopped to 7 bits.

  4. If the "locking shift" character Shift Out (SO, or Control-N) arrives,
     then GLeft is pointed at G1 and all subsequent arriving 7-bit values
     will be displayed from G1. The Shift In (SI, or Control-O) character
     cancels this and points GLeft to G0, which is its normal place.

  5. The locking shift sequence LS2 (ESC n) points GLeft to G2 and causes
     subsequent 7-bit values to be displayed from G2.  This is cancelled by
     SI (point GLeft back at G0). 8-bit characters are still directed to
     where GRight points. The other shifts below work similarly.

  6. The locking shift sequence LS3 (ESC o) causes subsequent 7-bit values
     to be displayed from G3.  This is also cancelled by SI.

  7. The "single shift" sequence SS2 (ESC N) causes the following character
     only to be displayed from G2.

  8. The single shift sequence SS3 (ESC O) causes the following character
     only to be displayed from G3.

  9. The GRight pointer also has shifts to G1, G2, and G3, but none to G0:

        locking shift G1 right    ESC ~    points GRight to G1
        locking shift G2 right    ESC }    points GRight to G2
        locking shift G3 right    ESC |    points GRight to G3

Well, you get the idea (there's more).  If you're interested in a summary
of the concepts of character set designation and switching, see the file
isok5.txt in kermit/e (ISOK5.TXT in KERMSRV).  A summary of Kermit's VT320
character-set designating escape sequences is listed in kermit/a/msvibm.vt
(MSVIBM.VT on KERMSRV).

Version 3.02 also includes some new fixes for the Tek and VT emulators, etc.
Details of the changes since 3.01 are in the file MSR302.UPD.  The MSTIBM.BOO
file and the latest source files are in the Kermit test areas (kermit/test on
watsun, use the T: prefix for KERMSRV).  On watsun only, the mstibm.exe file
is available for binary-mode ftp in the directory kermit/bin.

More changes are expected.  Watch the kermit/test and T: areas of Kermit
Distribution, and Info-Kermit for more announcements.  Send reports of
possible problems to [e-mail] or
[e-mail].

------------------------------

Date: Fri, 8 Jun 90 14:21 EDT
>From: Christine M Gianone <[e-mail]>
Subject: MS-DOS Kermit 3.0 for Heath/Zenith-100 Available for Testing
Keywords: MS-DOS Kermit 3.0, Heath/Zenith-100, Z-100

>From Bo Gedda of Lidingoe, Sweden, Z-100 Kermit updated to 3.0 level.  It
includes the system-independent aspects of MS-DOS Kermit 3.0, such as sliding
window packet protocol and improved script language, but not the
IBM-dependent aspects like VT320 emulation and LAN support.  The files are in
kermit/test/ms*z10.* on watsun and T:MS*Z10.* on KERMSRV at CUVMA.

------------------------------

Date: Fri, 8 Jun 90 12:30 EDT
>From: Christine M Gianone <[e-mail]>
Subject: New Microsoft Windows Kermit Available for Testing
Keywords: Microsoft Windows Kermit

>From Bill Hall, a new version of Kermit for Microsoft Windows that includes
VT52/100/102/132 terminal emulation (the previous version only emulated the
Heath/Zenith-19 terminal) and an improved user interface.  Bill says it should
work under Windows 3.0.  No sources or documentation yet -- the new user
interface should make it self explanatory.  Report problems, reactions, etc,
to Info-Kermit and we'll collect them and pass them on the Bill.  Reports from
Windows 3.0 users would be especially appreciated.

You can ftp the binary executable program from kermit/bin/wn100k.exe on
watsun, or the printable "boo" file from kermit/test/wn100k.boo on watsun, or
you can request the boo file as T:WN100K.BOO from KERMSRV at CUVMA on
BITNET/EARN.  The boo file is decoded into a an .EXE file using any of the
MSBPCT programs in the Kermit Distribution "A" area.

Thanks to Bill for his continued improvements to this program.

------------------------------

Date: Fri, 1 Jun 90 13:17 EDT
>From: Jonathan_Welch <[e-mail]>
Subject: Another New VMS Kermit-32
Keywords: VAX/VMS Kermit 3.3.126

This version of Kermit-32, 3.3.126, was linked under VMS Version 4.5, so
that the VMSMIT.HEX file can be VMSDEHex'd and will run on any VMS system
4.5 or later.

Changes since edit 122:

Modified a miscoded call which affected GETting files using long packets;
standard length packets were being used when long packet support was
available in both kermit programs.

The buffer for terminal names has been increased from 20 to 255 characters.

A bug which resulted in a "No default terminal line for transfers" message
when kermit was run as a subprocess has been fixed. It turns out that when
asking $GETJPI to return JPI$_TERMINAL a null string is returned for this
item when called from a subprocess.

A similar error that was corrected occurs when one VMS service returns a
terminal name sans trailing ':'.  When used as input to another service an
error occurs ("invalid device name" from the service is returned to the user
as "no default terminal line for transfers").

Unfortunately the only cure is to either 1) upgrade the operating system or
2) have the code check for the lack of a ':' and add one (this is what the
new version does).

The batch problem is fixed, as it was related to the terminal line business.

The spawn issue will have to be dealt with in the future as it will involve
some tricky coding.  DEC changed the meaning of the CAPTIVE bit in the user
authorization file (UAF) to mean RESTRICTED and added a new bit for CAPTIVE
as of VMS 5.2 (?).

-jonathan.

[Ed. - Thanks, Jonathan!  Also, the truncated VMSMIT.HEX file has been
replaced with an updated and full-length version, the missing VMSCOM.REQ
file has been installed, without which it was not possible to build the
program from the source code and get the new long packet support.]

------------------------------

Date: Mon 18 Jun 1990 10:30:00 EST
>From: Frank Dreano, NAVMASSO, Chesapeake, VA
Subject: Announcing Kermit 1.02 for the Honeywell DPS-6
Keywords: Honeywell DPS-6, MS-DOS Kermit 3.01

I have finished testing Version 1.02 of Honeywell Superkermit and have also
generated the changes to Version 3.01 of MS-DOS Kermit necessary to
communciate with the Honeywell DPS-6 minicomputer.  (The latter changes are on
the diskette in three files having a filename extension of .DPS with comments
explaining modifications at the start of the files.)  Although these changes
are made directly to the source, I feel that they are small and succint enough
to be natural candidates for the new MSKermit 'patch' facility.

The modified MS-DOS Kermit 3.01 produced from this source still works
properly with other machines such as the AT&T 3B2, Vax, Tandem, etc..  The
new Superkermit (source code is included in CUCLKER.C and CUCLPRI.C) for the
Honeywell now supports 2000-byte packets and corrects a minor bug in the
decoding of incoming attribute packet information.  All sources on this
diskette should be included in and/or replace the current official library
versions.

Frank Dreano Jr.

[Ed. - Thanks Frank, and thanks for your contribution to Kermit News #4!
The new Honeywell Kermit source files, along with documentaion and diffs for
the MS-DOS Kermit files, special batch and initialization files, etc, have
been installed in a single "text archive" file in the "D" Kermit distribution
area, replacing the previous version, as kermit/d/hd6ker.jar on watsun
(Internet) and HD6KER.JAR on CUVMA (BITNET KERMSRV).  Frank also sent in an
impressive PC-based demo of his NALCOMIS data transfer operation, but because
of its format (a large collection of .EXE files), it not practical to add it
to Kermit Distribution.  Meanwhile, the changes to MS-DOS Kermit have been
forwarded to Joe Doupnik, who will include them in the next major release of
MS-DOS Kermit -- not 3.02, because code space is too tight.]

------------------------------

Date: Fri, 1 Jun 90 11:42 EST
>From: Bob Martin <[e-mail]>
Subject: VMS DCL Procedure for Using WordPerfect with Kermit
Keywords: MS-DOS Kermit, WordPerfect, VMS, DCL

Folks,

I enclose a VMS DCL procedure that allows VMS WordPerfect 5.0 to be used
with MS-DOS Kermit 3.0. It automatically redefines ANY IBM type keyboard (84
or 101) to the standard PC key definitions for IBM WordPerfect 5.0. In other
words you can use the PC WordPerfect template when you are using VMS
WordPerfect.  Sorta makes it easier to remember!

The Procedure is reasonably well documented; if you have any questions
or comments feel free to drop me a line at the addresses listed in
the procedure.

Bob Martin --

[Ed. - Thanks, Bob!  Your new procedure has been put in the Kermit
Distribution A area as MSIWP3.COM.]

------------------------------

Date: Wed, 20 Jun 90 19:27:27 -0500
>From: Mark Vasoll <[e-mail]>
Subject: Okstate Kermit/UUCP Kermit Distribution Server Adds Trailblazer

We have just replaced the modem used in our dial up Kermit Distribution
with a Telebit Trailblazer.  All access information remains the same,
just the additional speed is also offered.

Mark Vasoll
Computer Science Department                Email:  [e-mail]
Oklahoma State University
Stillwater, Oklahoma

------------------------------

Date: Thu, 14 Jun 90 23:38:09 EDT
>From: Ed Sterling <[e-mail]>
Subject: SIM3278 TCP/IP Version Supports Kermit-370 4.x
Keywords: SIM3278, IBM 370 Kermit

Greetings,

I am the author of SIM3278 TCP/IP, a new member of the SIM3278 product line
(where other products are SIM3278/VM /VTAM and SIM3278/GCS). I'm happy to
announce that I finally have been able to support Kermit in at least one
environment!

SIM3278 TCP/IP Release 2.0 which is now in production, will support Kermit
file transfers with SET CONTROLLER SERIES1, using the "7171" WRITE-THEN-READ
transparency.  There is "effective" support of the "7171" WRITE-ONLY
transparency, however due to interface limitations, SIM3278 TCP/IP does NOT
emulate the ATTN interrupt to the application after the transparent write
completes.  This does not seem to affect KERMIT Release 4.0 transfers.

Please note that the SIM3278 TCP/IP software level MUST be Release 2.0; our
earlier Release 1.0 does not support KERMIT.  Further requirements appear to
be KERMIT Release 4.x (tests using KERMIT 3 did not work, and appeared to be
related to the ATTN interrupt requirement cited above).  And, IBM TCP/IP for
VM Release 1.2.2 is required.

A test site which could be contacted as a reference is Portland (OR) State
Univ., Fred Dayton (FRED@PSUORVM).

Simware STILL intends to support Kermit in the next release of SIM3278/VM.  I
am one of the founders of Simware, and the guy who in fact made the
"infamous" mistake back in 1983 of FAILING to realize the Kermit data should
be left alone and NOT translated! This mistake is what "breaks" Kermit
transfers through SIM3278/VM, and yes, we've built our own file transfer
programs (AKA "FORSIMPC") that of course "rely" on this mistake.

However, I am currently working in a team to revise the entire SIM3278
system, and I plan to fully support the "7171" transparencies in this next
release, using my success in the TCP/IP product, and porting it to the VM
version of SIM3278 next.

Let me join hundreds of others in thanking you for supporting Kermit as well
as you do.  As a vendor, it's great to have a de facto universal transfer
"system" that can solve many customer connectivity problems, that "we"
individually cannot do alone.

Regards,
Ed Sterling
Simware Inc.

[Ed. - Thanks, Ed!  Your message will certainly be welcome news to your many
customers who are also Kermit users, and it will put your product a step
ahead of competitors that do not support transparent or graphics mode in
their protocol emulators.  Meanwhile, the new SIM3278 transparent mode
support will have to be verified against versions 4.1 and 4.2 of Kermit-370.]

------------------------------

Date: Tue, 22 May 90 12:33:25 CDT
>From: Eric Romo <[e-mail]>
Subject: Needed: Mac Kermit for a 128K Mac

We tried version 0.8(34) on our Mac 128K with no luck.

What system/finder combination would you recommend using with that version
of CKMKER?  Keep in mind that we don't have much memory available. Also if
you would, send me an even older version of CKMKER, since that may have a
better chance of running on a 128K Mac.

Thanks for your continued help.
Eric Romo
Acknowledge-To: <UD069225@NDSUVM1>

[Ed. - We thought that 0.8(34) did the trick, but apparently not!  We don't
have any versions older than that.  Does anybody out there still have Kermit
running on a 128K Mac?  Could you send in a BinHex'd version of it?]

------------------------------

End of Info-Kermit Digest
*************************

From cmg  Wed Jul 18 16:20:31 1990
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA10474; Wed, 18 Jul 90 16:20:31 EDT
Date: Wed, 18 Jul 90 16:20:31 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V12 #1
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Wed, 18 Jul 1990        Volume 12 : Number 1

Departments:

  ANNOUNCEMENTS -
        Updated MS-DOS 3.02 Test Version Available
        New Release of Kermit for HP-3000
        Announcing NCR 9800 Kermit
        New Release of Kermit for UNISYS (Burroughs) A-Series
        New Kermit Programs for Luxor ABC Series and FACIT DTC/DTC2

  IBM MAINFRAME KERMIT -
        New MS Kermit REMOTE PRINT interface with Kermit-370
        Kermit-370 support for IBM 3174 AEA

  VAX/VMS KERMIT -
        VMS Kermit-32 Hints
        How to Create a Kermit Connection over X.25 from VAX/VMS?

  MISCELLANY -
        Kermit for Microsoft Windows
        External Kermit Driver
        Kermit for Atari Portfolio?

Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.1), IP host number 128.59.39.2.  Login as user anonymous
(note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired
files.  The Kermit files are in directories kermit/a, kermit/b, kermit/c,
kermit/d, and kermit/e.  Test versions are in kermit/test.  Binaries are in
kermit/bin (use ftp in binary mode).  You can also get Kermit files over the
BITNET/EARN network; to get started send a message with text HELP to KERMSRV,
the Kermit file server, at host CUVMA.  For detailed instructions, read the
file kermit/a/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 Jul 13 18:16:23 1990
>From: Christine M Gianone <[e-mail]>
Subject: Updated MS-DOS 3.02 Test Version Available
Keywords: MS-DOS Kermit 3.02

Additions to Joe Doupnik's MSR302.UPD file since the previous announcement
in Info-Kermit V11 #8:

22. Add more character set corrections from Matthias Reichling.

23. Correct problem of placement of CR/LF in text screen dump (broken in
    recent v3.02 changes), from Brian Holley.

24. Make small change to Self Test code, DECTST, CSI 2 ; Ps y  (VT100) and
    CSI 4 ; Ps...; Ps y  (VT320). Do a terminal reset only if a Ps is 0 or 1.
    This is in the VT terminal emulator. Ps values greater than 1 are for
    testing the terminal serial port, printer, and repeating the tests; they
    are ignored here. All cases move the cursor back to the main display.

25. Minor change to ensure modem status is correct even if the port has not
    yet been used. File msxibm.asm.

26. Modify the way characters are placed on Tektronix graphics screens from
    starting them at intervals of 8 PC screen dots across the screen to
    placing the lower left at the current drawing position (1 dot resolution).
    Characters are 8x8 dots. The effect is better positioning accuracy along
    the x-axis; the y-axis already behaved the better way. File msgibm.asm.

27. Tiny tweak to Tek graphics code to overcome a deficiency in some Bios'
    on storing video mode values if the high bit is set (means do not clear
    the display buffer). Brian Holley found such a case and GRAPHICS.COM in
    DOS 4 became confused.  The Bios on most machines clears that bit.  msgibm.

28. Follow the lead of C-Kermit 5A and attempt simple correction of Parity
    on the communications line during packet transfers.  Parity will be
    shifted to EVEN, ODD, or MARK by the detector, in addition to the older
    warning about removing the high bit on characters.  The first two packet
    characters determine the parity, though the first four are examined for
    unexpected setting of the high bit.  msscom, mssset, mssrcv, msssen.

29. Adjust Tektronix emulator slightly so that SET TERM CLEAR-SCREEN does
    a screen clear using the existing character coloring to write all spaces,
    rather than doing a full reinitialization of the emulator. The text
    emulator is not affected. Since ESC [ 30's; 40's m screen coloring command
    sets the fore- and background color palette registers (7 and 0, resp) a
    screen clear manually or by receipt of ESC [ 2 J will use this palette.
    A terminal reset restores the built-in default palette.

    More changes are expected.

The files are in the Kermit test area, kermit/test/mstibm.boo and
kermit/bin/mstibm.exe on watsun, and T:MSTIBM.BOO on CUVMA.

------------------------------

Date: 15 June 1990
>From: Tony Appelget, General Mills Inc, Minneapolis, MN, USA
Subject: New Release of Kermit for HP-3000
Keywords: HP-3000 Kermit

The HP3000 SPL Kermit seems to be badly neglected.  The listing in "Kermit
News number 4" shows your most recent version to be v1.1 dated 85/06/24.  I am
enclosing what I am assuming to be a much more modern version.  It is the
product of a lot of hours put into the v1.0 version over the past five or six
years and works very well here.

All my changes  are listed in comments at the beginning of the program.  A few
of the big changes are:

- Added a HELP function.
- Implementated a very versatile command name abbreviation scheme.
- Implemented 3-byte checksums in addition to the old standard one-byte
  checksums.
- Implemented long packets with a maximum of 2000 bytes.  Decreasing packet
  size in response to packet errors is not implemented.
- This Kermit sets a JCW (program completion code).
- Cleaned up a plethora of small bugs.
- At the insistance of our security types, a file validation scheme was
  built into the program.  No one uses it.  Leaving it in place will cause
  no harm.  It should be removable without too much trouble.

The version number, 2.7, that I have stuck on the program is totally arbitrary
as far as I am concerned.  If my enclosed Kermit meets your standards for
distibution, it would be a feather in my cap for you to do so.

(signed)
Tony Appelget
K0DCF/AFA3AO/AFF3MN

[Ed. - Thanks, Tony, it does, apply feather to cap!  It looks like Kermit News
#4 is shaking a lot of Kermit updates out of the woodwork.  This one replaces
the old 1.1 version from 1985 in the Kermit "D" area as hp3000.*.]

------------------------------

Date: Fri Jul 13 13:53:17 1990
>From: Christine M. Gianone <[e-mail]>
Subject: Announcing NCR 9800 Kermit
Keywords: NCR 9800 Kermit

This is to announce a Kermit program for the NCR 9800-4 computer, contributed
by Paul E. Gladden of NCR Corporation, San Diego, CA, USA, for the NCR VE4.0
operating system.  There are separate variations for the IVS and MCS
environments.

Both products are written in the C language, based on C-Kermit 4E with
features added or deleted depending on VRX system capabilities, and NCR
selected product content.  Module names reflect the same usage as in C-Kermit
4E.  New modules have a short explanation.

IVS-Kermit and MCS-Kermit share common source code. MCS-Kermit has two
additional files to interface to the MCS telecommunications facility.  MCS
modules are labeled MCS ONLY.

A large number of files are included.  These have been installed in the "D"
area of Kermit Distribution as ncrker.*.  The file ncrker.doc contains user
documentation and installation instructions.  The file ncrker.jar is a "join"
text archive of the numerous source files, which contains instructions at the
top on how to break it apart.

Many thanks to Paul for submitting this new Kermit implementation.

------------------------------

Date: 22 June 1990
>From: Dave Squire, University of California at Davis
Subject: New Release of Kermit for UNISYS (Burroughs) A-Series
Keywords: UNISYS A-Series, Burroughs A-Series

Enclosed is the 1.040 release of our version of Kermit for Unisys A-Series
systems.  This is an upgrade of "B78" Kermit 1.019 from 1986.  The important
new features of this release are: long packets, alternate block-checks, and
a "take" command.  The program has also been modified to use the A-Series
hardware more efficiently.

This release contains the Kermit symbol (written in Algol) and a documentation
file.  We will continue to distribute Kermit directly to A-Series sites who
contact us.  We will also consult with new Kermit users to help them get
started.  There is no fee for either service.  You may refer any Unisys
A-Series users to us.  Also, please feel free to contact me if I can help with
any A-Series questions.

Dave Squire
Computing Services
University of California
Davis, CA  95616-8563  USA
Phone [phone]

[Ed. - Thanks to Dave and to Larry Johnson and Katie Stevens at UC Davis for
their work on this program and for sending in this new version!  It's in the
Kermit Distribution "D" area as uasker.*.  The previous release has been kept
as b78ker.*, in case the new release does not run on the B7800 or on older
Burroughs A-Series machines or operating system releases.  If it is not
necessary to keep the old version, please let us know: does this new version
run on the B7800?  Also, does anybody know the name of the operating system
for these machines?]

------------------------------

Date: Sun, 8 Jul 90 0:30:08 MET
Subject: New Kermit Programs for Luxor ABC Series and FACIT DTC/DTC2
>From: Bo Kullmar <[e-mail]>
Keywords: Luxor, ABC-80/800

I am sending you updates for the ABC80 and the ABC800 Kermit. Two members of
the ABC-Klubben have done the work.

Joergen Westman has fixed the repeat prefix handling in the ABC80 Kermit.  It
did not work against Kermit programs that could not do run-length encoding.
(Jorgen with dots over the o.)

Mikael Johansson has updated the ABC800/ABC802/ABC806 Kermit to version 4.11
and included support for FACIT DTC and FACIT DTC2. FACIT DTC/DTC2 is a ABC800
clone.

--Bo Kullmar

[Ed. - Thanks, Bo!  The lux*.* files in the Kermit "C" area have been updated
to the new versions.]

------------------------------

Date: Tue, 1990 Jun 26   16:58 EDT
>From: "John F. Chandler"   <[e-mail]>
Subject: New MS Kermit REMOTE PRINT interface with Kermit-370
Keywords: MS-DOS Kermit, REMOTE PRINT Command, IBM 370 Kermit

I noticed from reading Info-Kermit V11 #8 that MS-DOS Kermit 3.02 has a REMOTE
PRINT command.  For those not familiar with the guts of Kermit protocol, I'd
like to remark that this command is essentially a slight modification of the
MAIL command (you can see traces of that history on the screen when you issue
the command), and support exists for the mainframe ends of both in release
4.2.0 of Kermit-370.  A slight modification of the KERMAIL command, renamed
KERMPRT, will do the job (see IKxKER.DOC or IKxKER.PS for descriptions), as I
have already demonstrated on my CMS system.  If there is sufficient interest,
I could add samples of these mainframe commands to the Kermit-370 area, but
the implementations will likely vary widely from site to site.

One of these days, I'll see about implementing a REMOTE PRINT subcommand in
Kermit-370 so a mainframe user connected with a PC as a terminal can make hard
copies on an attached desktop laser printer.  Right now, though, I'm
concentrating on implementing Kermit support for the transparency mode in the
new B2 microcode for the IBM 3174 (about which, more later).
                                    John

------------------------------

Date: Tue, 1990 Jun 26   17:34 EDT
>From: "John F. Chandler"   <[e-mail]>
Subject: Kermit-370 support for IBM 3174 AEA
Keywords: IBM 370 Kermit, IBM 3174 AEA

I now have word from IBM that the new release of 3174 microcode is out.  It
is called B2 (that is, Level 2 of Configuration B) and is supposedly
available to all customers with the "B" configuration of the 3174.  As I
understand it, "B" costs extra and requires a bit more hardware (minimum
requirement is model 11L or equivalent), while "A" comes with the box.
Apparently, there are no plans for upgrading "A".  If you have "B"
configuration installed, though, this upgrade should finally make it possible
to run Kermit through the 3174.  I have some documentation about the new
"ASCII Graphics Mode", and I think the necessary Kermit code is pretty
simple.  Indeed, I have already made a stab at it (pending the answers to a
few questions).  I'm looking for volunteers to try out the new feature and
troubleshoot the code.  If you think you want to try it, the first thing to
do is make sure that you (1) have the "B" configuration and (2) have received
and installed the "B2" update from IBM.  I have no idea what the shipping
schedule is like for things like that.  I can send you the Kermit update as
soon as I check on a few details or even sooner if you're really eager.
Meanwhile, let me know if you're interested.
                                  John

------------------------------

Date: Fri Jul 13 19:13:27 1990
>From: Christine M. Gianone <[e-mail]>
Subject: VMS Kermit-32 Hints
Keywords: VAX/VMS Kermit

Several people have complained that Kermit-32 has been sending files
incorrectly when the file type is set to binary.  This can happen when the VMS
file has a carriage control attribute; for example, VMS Lotus files are
created this way.  The recent release of Kermit-32 has a new command SET FILE
TYPE BLOCK which seems to get around this difficulty.

Also, judging from many messages received in the past month, many people who
have complained that Kermit-32 did not pick up their terminal name correctly
("No default terminal line for transfers") have not obtained version 3.3.126,
announced in Info-Kermit V11 #8, which fixes that problem, as well as
problems related to spawning and batch operation.

------------------------------

Date: 22 Jun 90 13:33:16 GMT
>From: [e-mail] (R.E. Sonneveld, [phone], PTT Research)
Subject: How to Create a Kermit Connection over X.25 from VAX/VMS?
Keywords: VAX/VMS Kermit, X.25 Network

Wanted: Kermit communication over X.25 (with for example EuroKom) with my
'own' VMS system as my home base.  In other words: is it possible to start
Kermit on the VAX, then SET HOST/X29 to e.g. EuroKom, then start Kermit at the
remote side and establish the connection?

We have tried the following:

 1) loopback one DECserver port-X to port-Y
 2) define the DECserver ports to be 'transparent'
 3) define DECserver port-Y to autoconnect
 4) with LCP, create LTA port pointing to the DECserver port-X
 5) define default port for Kermit (KER$COMM), pointing to the LTA device

Starting Kermit and using the default port will result in a connect via the
DECserver loopback to the original VMS-system, thus creating the possibility
of establishing a X.25 connection.  This works great! The major problem and
the reason why we won't release this 'facility' is SECURITY: whenever a
connection is established by one person and this connection aborts
unexpectedly, than the next user who tries to make a connection using this
default port gets the session of the first user!

Any help greatly appreciated!

Rolf Sonneveld        E-mail: [e-mail]

PTT Research          *      Tele phone : [phone]
Neher Laboratories,   *      Tele  fax  : [phone]
The Netherlands       *      Tele   x   : 31236 prnl nl

[Ed. - This is a common question from Europe.  As yet, neither C-Kermit/VMS
nor VMS Kermit-32 contain any explicit support for VAX/PSI or X.25 in any of
its forms.  We are hoping that someone with an X.25-connected VAX/VMS system
will add this support.  Volunteers?]

------------------------------

Date: Fri, 29 Jun 90 05:27:31 EDT
>From: Erez Zadok <[e-mail]>
Subject: Kermit for Microsoft Windows
Keywords: Microsoft Windows Kermit

I'm running now WIN100 V2.0 and it's a definite advantage over older
versions.  I have a few comments and questions.

COMMENTS:

(1) Good job!  I like it in the GUI environment.  I actually downloaded
files while playing Solitaire.  Multitasking on my desk.  I liked the fact
that there was a running number of packets on the minimized kermit icon so I
can always keep a watch over the file transfer.  I liked the beep at the end
of the transfer and the Alert that popped up for me at the end.

(2) This is definitely the wave of the future.  I think windows kermit
*will* be a major communication package to use on ms-dos platforms and will
bite a large chunk of the regular ms-kermit.  But there's a lot to be done.
With Windows 3.0 out now, you have all the reasons in the world to make this
package at the same level of MS-Kermit 3.02.

(3) The first things that struck me as in need of improvement were (and bear
in mind that I know MS-Kermit 3.02 *very* well):

- Not enough variety of fonts to choose.  My VGA does not fit 80
  columns with this font (courier) and the other font (preview) is
  way too small.  Maybe the fonts are windows dependent and not
  depend on kermit?
- No apparent way to map the keyboard,  Esp. swapping ` and ESC, and
  mapping CAPSLOCK to CTRL.
- No dialup scripts to use.
- Not enough colors to choose from (esp. the high intensity ones.)
- Win100 does not use the new builtin help feature in Windows 3.0.

(4) Then, upon closer look, I found that the next few items should be
improved (lower priority in my opinion):

- Support for long packets.
- When changing a font or its size, I would like not to have to
  restart kermit.
- I would like to see a way to set the number of lines as an input
  from the keyboard and not only by resizing the window.
- I would like to cut from the kermit screen by using the mouse only
  and marking and cutting.  The current way is not as clean.
- Screen refreshes are not as fast (maybe that's due to my
  hardware configuration and lack of memory.)

(5) The vt100 emulator works well with all kind of applications including
EMACS and curses-based applications.

(6) Possible serious bug:  At one point I got an alert "out of token memory"
error or something, and kermit aborted.  My line was not disconnected.  I am
running Windows 3.0 in real mode (no extended or expanded memory yet on my
286) and it seems that kermit ran out of memory of some sort.  In either
case it should not have aborted but only gave an alert.  Maybe this error is
unrecoverable...

[Ed. - This is one of several messages about Bill Hall's new VT100-emulating
Kermit for Microsoft Windows.  All of them contained similar questions and
favorable comments.  Bill replies as follows:

Most of the suggestions are on my worklist to do - someday!.  Life if pretty
busy since I work a regular job and also write the Windows column for PC
Magazine.  But, I do want to improve the version I have put up as a beta.

Please be patient.  There is no help because it is a 2.0 application.  The
font is terrible, but don't blame me for this.  I would have to design a
complete series of fonts for a range of displays if I could not use the ones
supplied by Windows.  Maybe some kind soul will eventually help me with this
really non-trivial effort.

The screen update is slow.  As you know, everything in Windows is done in
software so this is a problem.  However, I'm sure I can do something to
improve it a bit, and I'll give it a try.

The implementation of the Kermit part is confined at the present to the
standard stuff.  It may be archaic, but it takes a lot of time to get all the
new features working.  Also, making Kermit work smoothly in Windows is quite a
chore.  It is so hard that I'm doing an article on it using the level I have
developed up to now as the example.  When the article is done, I will then
take up the task of upgrading the program.]

[Ed. again - By the way, Bill has sent in a slightly updated version of the
program, and some preliminary documentation: win100.msp (to be viewed in
Microsoft Paint) and win100.wri (for Microsoft Write).  They document just the
emulator part of the program, not the file transfer part.]

------------------------------

Date: Tue, 26 Jun 90 23:43:20 CST
>From: BOB SHERMAN <[e-mail]>
Subject: External Kermit Driver
Keywords: MS-DOS Kermit 3.0

Greetings:
  I am running a BBS on an IBM PC.  Do you have any suggestions
  for a external kermit driver?  Thanks for any help.

                                         Bob Sherman

------------------------------

Date: Mon, 25 Jun 90 11:33:39 CDT
>From: [e-mail] (J. Philip Miller)
Subject: Kermit for Atari Portfolio?
Keywords: Atari Portfolio Kermit

In a review of the Atari Portfolio - a pocket size, almost DOS PC - there was
mention of a modified version of Kermit that would work on the Portfolio.
Could some point me to where it is available?

This machine runs the DIP Operating System, which is very close to DOS 2.11.
I understand it is a small patch to the regular PC version.

-phil

J. Philip Miller, Professor, Division of Biostatistics, Box 8067
Washington University Medical School, St. Louis MO 63110
[e-mail] - Internet  [phone]
uunet!wuarchive!wubios!phil - UUCP [phone](FAX)  C90562JM@WUVMD - bitnet

[Ed. - Yes, and please point us at it too!]

------------------------------

End of Info-Kermit Digest
*************************

From cmg  Fri Aug  3 14:50:25 1990
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA29240; Fri, 3 Aug 90 14:50:25 EDT
Date: Fri, 3 Aug 90 14:50:24 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V12 #2
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Fri, 3 Aug 1990        Volume 12 : Number 2

Departments:

  ANNOUNCEMENTS -
        Another Update of the MS-DOS Kermit 3.02 Test Release
        Version 8.12 of PRIME Kermit Now Available
        New Documentation Available for VAX/VMS Kermit-32 3.3.126
        New Test Release of DEC Rainbow Kermit

  MS-DOS KERMIT -
        MS-DOS Kermit 3.0x and Microsoft Windows 3.0
        MS-DOS Kermit 3.0 Hints
        MS-Kermit Server and Hayes 2400bps Modems?

  KERMIT-370 -
       IBM Mainframe Kermit and Trailing Blanks
       IBM Kermit 4.2 and tn3270

Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.1), IP host number 128.59.39.2.  Login as user anonymous
(note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired
files.  The Kermit files are in directories kermit/a, kermit/b, kermit/c,
kermit/d, and kermit/e.  Test versions are in kermit/test.  Binaries are in
kermit/bin (use ftp in binary mode).  You can also get Kermit files over the
BITNET/EARN network; to get started send a message with text HELP to KERMSRV,
the Kermit file server, at host CUVMA.  For detailed instructions, read the
file kermit/a/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 Aug  1 19:56:09 1990
>From: Christine M. Gianone <[e-mail]>
Subject: Another Update of the MS-DOS Kermit 3.02 Test Release
Keywords: MS-DOS Kermit 3.02

>From Joe Doupnik.  Changes since the version announced in Info-Kermit V12 #1
are listed below.  Items 38 and 39 will be of interest to Honeywell users for
supporting connections to the Honeywell DPS-6 (see article by Frank Dreano in
Kermit News #4) -- they remove the need for a custom version of MS-DOS Kermit
to communicate with the the Honeywell systems.  Please report any problems to
Joe at [e-mail] or [e-mail].

30. Add correction to ensure NUL and DEL are passed through when printing
    transparently. msxibm

31. Revise REPLAY filespec a little. Previously at the end of the file any
    key would exit Connect mode. Now all keys remain active so that screen
    dumping and screen rollback function; ALT-X and Control-C (emergency
    bailout) exit Connect mode. msxibm

32. Internal revisions to details of handling 75/1200 baud split speeds.
    Previously, filling the receiver buffer would cause an XOFF to be sent
    at 1200 baud rather than at the correct 75 baud. Now the XOFF character
    is sent at 75. A pseudo-queue is present to prevent conflicts of using
    the timer chip for beep or regular 75 baud output when the receiver
    interrupt occurs (and resulted in the XOFF being sent at interrupt level
    rather than at task level). The queue makes the XOFF be sent at task level
    and at the proper 75 baud rate. Dan Norstedt had the idea, this queueing
    stuff is my solution. 75 baud output is done as a software UART. msxibm

33. Details here and there to save code segment space, from Dan Norstedt.

34. Add terminal type of VT100. This performs identically to a VT102 except
    the response to the type inquiry from a host is ESC [ ? 1 c (a VT100).

35. Found and fixed a protocol problem present in MSK 3.0 to date. If an I
    packet is sent to a server Kermit which does not understand I packets
    the resulting Error packet from the server is to be taken as a forgivable
    error, rather than otherwise being a fatal one. The version 3.0 and 3.01
    code forgot to forgive. I packets are sent by GET and REMOTE commands.
    Fixed on 19 July. mssser.

36. Remove VTxxx response to CSI [ .. R. That should not have been present.
    Thanks to Ted Medin for discovering its presence.

37. Add 80/132 column support for Paradise Autoswitch EGA Mono board, thanks
    to David Zielke of Duke Univ. msyibm

38. Add two new commands

    SET SEND DOUBLE-CHAR <number between 0 and 255>
        which sends this character twice in a row in outgoing packets.
        The doubling occurs as packet bytes are being sent to the
        communications channel and hence does not occur during packet
        construction. This accomodates communications devices which
        need doubling to let through a single copy. The doubling
        will not appear in the packet log. Padding characters are
        not affected by this command since padding is to be discarded
        at the other end anyway.

    SET RECEIVE IGNORE-CHAR <number between 0 and 255>
        which ignores this character in received packets. This
        accomodates communications devices which may insert a
        character into a stream, such as a Line Feed inserted before a
        Carriage Return. The ignored character will not appear in the
        packet log. Note that NUL (0) and DEL (127) are normally
        ignored even without this command.

39. Add terminal type of HONEYWELL to the emulator. This is a VT100 with
    two special responses. A received ENQ character, decimal 5, causes the
    emulator to send the 14 characters

        '7813  P GC  A' 03h

    and receipt of  ESC y  causes the emulator to send the 27 characters

       ESC '[8p  OT' 03h ESC '[y7813  P GC  A ' 03h

    where the quote marks (') above are not sent but are present so we can
    see the spaces which are sent; other spaces are for reading convenience.
    03h is Control-C, a binary value 3. The terminal ident response is VT100.
    These Honeywell VIP7809 emulation features are from Frank Dreano,
    [e-mail].

40. Modify the internals for SET KEY LK250 to result in checking for an
    active external LK250 driver and if found activate the LK250 usage in
    Kermit. If the driver is not found the message "?LK250 keyboard external
    driver is not active." is displayed. Note that to obtain the default
    LK250 key mappings the user must say SET KEY CLEAR after the above
    command, and then add any local definitions. Tnx to Terry Kennedy. msuibm

41. In command WAIT <timeout> \CD \CTS \DSR   let the backslash character
    be optional, to merge syntax with C Kermit 5A. mssscp

42. Add further Honeywell terminal type modifications from Frank Dreano:
    - change invocation ESC y to be ESC [ y     (see item 39 above)
      This will cause loops if the host echoes the response.
    - add  ESC `  (accent grave) clears screen and homes the cursor.

43. Revise slightly the query for the active Code Page, and the table of
    character sets for use by SET FILE CHARACTER-SET, to be system dependent
    so that MS-DOS in Japan can be used more effectively. That MS-DOS lacks
    the concept of Code Pages. Thanks to Hirofumi Fujii for the suggestions.

44. Add another host invocation control sequence to the text terminal emulator.
    Reception of  CSI Pn;...Pn ~  invokes a macro named PRODUCT, if it
    exits, and sets variables \%1, \%2, and so forth up to \%9 to be the ascii
    version of the numeric parameters Pn above. Omitted parameters are taken
    to be zeros. Only as many variables are set as numeric parameters, and
    script item ARGC is one larger than this quantity. If macro PRODUCT does
    not exist only the \%x items are changed. Connect mode is not reentered
    automatically if the macro exists. This is very similar to TERMINALR and
    TERMINALS, except for the variable setting part.
    The invocation sequence may change so don't write it into applications
    until Kermit is released again. It is not invocable from the keyboard,
    because of the needed parameters. mssset.asm, msyibm.asm, mszibm.asm.

45. Correct a keyboard translation problem. Control codes could be translated
    to printable characters for a few National Replacment Character sets,
    because that was where the special graphical symbols are located on the
    IBM PC display adapter. This has been corrected to never translate control
    codes.

46. Slightly revise script INPUT and REINPUT command sensing of timeouts to
    do the time reading after each serial port character reading operation.
    This might cure complaints of REINPUT 0 reporting premature FAIL status.

47. If disk reading fails while sending a file tell the receiver to dispose
    of the file with a Delete status, rather than the previous status of
    just end-of-file. There is no other simple way of informing the receiver
    of such a local problem. Other files in a group will be processed normally.

  More changes are expected.

------------------------------

Date: Fri Aug  3 10:46:17 1990
>From: Christine M. Gianone <[e-mail]>
Subject: Version 8.12 of PRIME Kermit Now Available
Keywords: PRIME Kermit

>From Matthew Sutter of Lincoln National Corporation in Fort Wayne, Indiana,
USA, comes version 8.12 of PRIME Kermit, an upgrade of version 8.00 that was
prepared by John Horne of Polytechnic South West in Plymouth, England.

The major feature of version 8.12 is support for local-mode (dialout)
operation using the AMLC lines.  CONNECT, GET, FINISH, and BYE commands have
been added, as well as the script commands INPUT, OUTPUT, CLEAR, and PAUSE.

This version also contains fixes to repeat character processing and sliding
windows, but the sliding window feature still needs more work in order to
interoperate with MS-DOS Kermit 3.0 or C-Kermit 5A.  This work is underway,
watch Info-Kermit for further announcements.

The new files are in kermit/d/prime8.* on watsun, and PRIME8.* on CUVMA.
There is, as yet, no new documentation.  Thanks to Matt for his work and for
contributing it to the Kermit collection!

------------------------------

Date: Wed Aug 1 18:29:49 1990-EDT
>From: Christine M. Gianone <[e-mail]>
Subject: New Documentation Available for VAX/VMS Kermit-32 3.3.126
Keywords: VAX/VMS Kermit

The VAX/VMS Kermit-32 chapter of the Kermit User Guide has been updated to
include all the information about the new release, and the help text has also
been updated.  Thanks to Jonathan Welch of the University of Massachusetts for
his help in clarifying the actions and interaction of the SET FILE BLOCKSIZE
and SET FILE TYPE commands, and for proofreading the manual.

The files for the new manual are VMSHDR.MSS and VMSMIT.MSS (Scribe source),
VMSMIT.DOC (plain ASCII text) and VMSMIT.PS (Postscript).  The help text is in
VMSMIT.RNH (Runoff source).  Tape B (kermit/b, etc etc).

------------------------------

Date: Thu Aug 2 13:01:34 1990-EDT
>From: Christine M. Gianone <[e-mail]>
Subject: New Test Release of DEC Rainbow Kermit
Keywords: MS-DOS Kermit, Rainbow Kermit, DEC Rainbow

>From Robert Weiner, a new version of Kermit for the DEC Rainbow, based on
the system-independent parts of the July 22nd MS-DOS Kermit 3.02 test release.
The Rainbow version lacks many of the IBM-specific enhancements that appeared
in MS-DOS Kermit 3.0, like international character sets, instantaneous screen
rollback, etc, but these MAY be added before the final release of this
program.  The system-independent features -- script programming enhancements,
sliding windows, long packets, VT200/300 emulation (it's still at the VT102
level), etc.

Thanks to Rob for keeping the Rainbow up to date!  The files are in
kermit/a/mstrb1.boo ("BOO" file to be un-boo'd into an .EXE file using any of
the MSBPCT files) on the Internet or MSTRB1 BOO on BITNET KERMSRV at CUVMA.
For internet binary-mode FTP access only, also kermit/bin/mstrb1.exe.

------------------------------

Date: Thu, 2 Aug 90 11:18:30 PDT
>From: [e-mail] (William Hall)
Subject: MS-DOS Kermit 3.0x and Microsoft Windows 3.0

Just tried MS-DOS Kermit 3.0 in enhanced mode Windows.  I began by running a
DOS shell then running Kermit.  Did not bother with a PIF file.  I changed the
settings to run from exclusive to background.  You can get to these setting
with ALT-SPACE, then moved it to a Window.  For fun, I ran vttest on UNIX and
checked the character set, especially the one for DEC special graphics.  They
looked as expected.

Then I tried a long file transfer.  I made the window iconic, and the file
transfer ran in the background to completion with no errors.  At the end, the
bell beeped to let me know it was done.

So it works and quite well to the extent that I tested it.

--Bill

------------------------------

Date: 1-AUG-1990 20:33:04.67
>From: Joe Doupnik <[e-mail]>
Subject: MS-DOS Kermit 3.0 Hints
Keywords: MS-DOS Kermit 3.0 Troubleshooting

[Ed. - This is extracted from a reply by Joe to a user who reported a
nonfunctioning Kermit on a Compaq computer.]

One common item is an internal modem which fails to follow the normal rules of
how to behave like a regular serial port.  Another is two devices are having a
small battle for an IRQ line or a memory (port) address.

MS-DOS Kermit 3.02 (not 3.2) is strictly development software, as indicated in
the note file MSR302.UPD and on the startup banner.  The REMOTE command
problems you report fall into the category of fixed, broken, and then fixed
again (sigh).  In all of the broken cases Kermit would retry many times and
that takes up to a minute or so to finish.  While that is happening one side
can send an XOFF to the other and forget to send a matching XON later; Kermit
waits 10 seconds to figure out this situation when it needs to send and breaks
through regardless.  So, this "flow control deadlock" can add to the waiting
interval, but it's better than being told to never speak ever again.

Another situation, which happened to me a couple of years ago, was the poor
hard disk controller had a conflict with another board and every once in a
while the machine would hang waiting on the hard disk for 10 minutes or more.
Usually I had to push the big Red switch. When Kermit has to go to the hard
disk then these kinds of things can happen.

Generally, I try to sort out the problem by trying Connect mode between
machines right away. If that works then I know the communications line part is
basically ok.  If packets fail then I say SET DEBUG ON and SET DISPLAY SERIAL
to watch what's happening during a file transfer or REMOTE command (REMOTE WHO
is my favorite "protocol" quicky, no disk access).

Let's suppose the Compaq is in sad shape.  My suggestion is to backup the hard
disk contents and ensure they are correct (say to DOS VERIFY ON to help).
Then do a low level format of the drive (yow!) and a DOS FORMAT with the
correct version of DOS.  Put things back on the hard disk and keep your
fingers crossed.  Double check the settings of the boards too.  Unload the
likely mountain of favorite TSR's and see if things work.  If they do then
start adding them back one at a time and retesting.  Make sure that CONFIG.SYS
has BUFFERS=20 or so and FILES=20 or so.  Watch out for Desqview because it
has troubles remembering that a communications program needs to service
interrupts from the serial port.  Don't mix DOS files from different
releases/manufacturers.

Ensure that parity is the same on both machines, NONE being better than any
other flavor (Kermit does it's own checking in a much more secure way).  Don't
use MODE COM1:....,P with that ",P" (for Printer waiting) on the same port as
the communications channel because DOS will grab the port and won't release
it.  Watch for mice drivers nibbling on the same serial port.  In short, take
the machine down to bare metal and rebuild it slowly from a consistent set of
original DOS floppies (put write-protect tabs on them).

Did I forget to mention virii?

------------------------------

Date: Tue, 02 May 89 16:54:34 CDT
>From: Barry Pederson  <[e-mail]>
Subject: MS-Kermit Server and Hayes 2400bps Modems?
Keywords: MS-DOS Kermit Server Mode

Hi, we've been using MS-Kermit for a while now, and it's been incredibly
useful, but we're having a slight problem.  We have some IBM model 30-286
machines connected to Hayes 2400bps external modems.  They work fine except
when we try to have the modems answer the phone while Kermit is in server
mode.

We have a script set up to set the speed to 2400, parity to none, then we
output ATS0=1\13 to the modem, and go into server mode.  Sometimes it works,
but a lot of the time, when the phone rings the modem will drop down to
1200bps.

In a previous Kermit Digest, I thought I saw something about C-Kermit having
problems with Hayes modems, does MS-Kermit have a known incompatibility
between it's server mode and a Hayes modem?

I suspect that Kermit is working fine, but the Hayes is doing something screwy
(we've tried MS-Kermit 2.31 and 2.32/a).  I'd really appreciate any
suggestions on how to keep the Hayes from slowing down.

Thanks.

Barry Pederson    University of North Dakota School of Medicine
     [e-mail]     or    [e-mail]

[Ed. - When MS-Kermit is in server mode, it times out every 30 seconds or so
and transmits a negative acknowledgement packet (the familiar "^A# N3").  It
is likely that the NAK packet is confusing the modem.  The workaround is to
give MS-DOS Kermit the SET TIMER OFF command before putting it in server mode,
which is safe as long as the other Kermit will do timeouts (some, like IBM
mainframe CMS Kermit, cannot).  In MS-DOS Kermit 2.32/A or later, you can
disable server command wait timeouts without turning the timer off, by using
the command SET SERVER TIMEOUT 0.]

------------------------------

Date: 6-Jul-90 22:03:17-GMT
>From: Randy [e-mail]
Subject: IBM Mainframe Kermit and Trailing Blanks
Keywords: IBM 370 Kermit, VM/CMS Kermit, Blanks

We're running Kermit CMS and MS Kermit to transfer files with a record length
of 1500 bytes. What's happening is that the records have trailing blanks.
Kermit strips these blanks off. We need them to remain intact for input into a
commercial package we are running under DOS. Is there any way to keep the
blanks from being stripped? I know that you can specify LRECL and RECFM at the
CMS level but that is for files being received in CMS.  We need the same
capability for MS-DOS Kermit.

Randy Schirmer
West Chester University, West Chester, PA
215-436-1094, RSCHIRME@WCU

[From John Chandler - When the file type is TEXT and the recfm is F,
Kermit-370 strips off trailing blanks from each record before sending a file.
In order to keep trailing blanks in a downloaded file, you can convert it to
RECFM V in CMS before sending it, e.g., by using COPYFILE with the RECFM V
option.  This is true of versions from 4.1 onward.]

------------------------------

Date: Wed, 20 Jun 90 08:33:25 -0500
>From: C Lance Moxley <[e-mail]>
Subject: IBM Kermit 4.2 and tn3270
Keywords: IBM 370 Kermit, tn3270

I just assembled Kermit/370 on an IBM 3081 running VM/SP 5.  The program
assembled just fine.  But, I have no idea how to set things to work through
tn3270. I've used MS-DOS Kermit for quite a while now and also am very
comfortable with C-Kermit, but this seems to be alot different. I would
appreciate any help you can give on this.  I also have the ability to use 3708
protocol converters, but I don't think there is any way I can put them in
line-by-line mode. I would really prefer to use tn3270. If you are the wrong
person to ask this to, please direct me to the right person. Also if there are
any examples anywhere, let me know. I couldn't find anything on watsun.

Thanks for a very fine product. The other versions that I use are the best of
their kind. Especially the new C version.

                                Thanks,
                                Lance

[From John Chandler - Actually, no, I haven't used tn3270 myself, but Bob
Babcock has -- and from a Unix system only.  It should have been essentially
the same as your attempt, but it worked.  The special considerations are only
two: you must SET CONTROLLER SERIES1 by hand, and you cannot (apparently)
upload using long packets.  The system in question was a CONVEX, as opposed to
a SUN, but I think the tn3270 would have been the same.]

------------------------------

End of Info-Kermit Digest
*************************

From cmg  Tue Aug 28 16:03:24 1990
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA28887; Tue, 28 Aug 90 16:03:24 EDT
Date: Tue, 28 Aug 90 16:03:23 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V12 #3
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Tue, 28 Aug 1990        Volume 12 : Number 3

Today's Topics:

         Duplicate Copies of Info-Kermit Digest V12 #1 and #2
         Proposed Kermit Extension for SET FILE TYPE
          And ANOTHER New Test Release of MS-DOS Kermit 3.02
        A New Version of Kermit for OS/2 Presentation Manager
               New Release UCPECAN Kermit V1.1
             MS-Kermit 3.0x and German telephones
                 Looking for Stories


Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.1), IP host number 128.59.39.2.  Login as user anonymous
(note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired
files.  The Kermit files are in directories kermit/a, kermit/b, kermit/c,
kermit/d, and kermit/e.  Test versions are in kermit/test.  Binaries are in
kermit/bin (use ftp in binary mode).  You can also get Kermit files over the
BITNET/EARN network; to get started send a message with text HELP to KERMSRV,
the Kermit file server, at host CUVMA.  For detailed instructions, read the
file kermit/a/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: Tue Aug 28 17:44:54 1990-EDT
>From: Christine M Gianone <[e-mail]>
Subject: Duplicate Copies of Info-Kermit Digest V12 #1 and #2

Please disregard any duplicate copies of recent Info-Kermit
Digests.

------------------------------

Date: Thu Aug 16 17:44:54 1990-EDT
>From: Christine M Gianone <[e-mail]>
Subject: Proposed Kermit Extension for SET FILE TYPE
Keywords: Kermit Protocol, Labeled File Type

Kermit programs presently differentiate between text and binary files via
the SET FILE TYPE command.  When the file type is TEXT, the Kermit program
that is sending the file converts the file's record format and character set
from its local form to a standard form, and the receiving Kermit program
converts from the standard form into its own local record format and character
set.  When the file type is BINARY, the file is sent as-is, byte for byte.

These two ways of handling files are sufficient in many cases, but fall short
when one or both computers has a complex file system, such as the Macintosh or
DEC operating systems like VAX/VMS.  The Kermit protocol includes a mechanism
for transmitting a file's attributes in a generic way, but these attributes
are of little use when the file is being received by a computer with a simple
file system, such as UNIX or MS-DOS, that can't do anything with them.  And
they are not sufficient to convey every conceivable bit of information about
about every kind of file on every kind of computer.

To allow a complicated file to be transferred, a new file type is proposed:

  SET FILE TYPE LABELED

Notice the spelling of "LABELED" (only one L between the E's).  When this
setting is in effect, the sending Kermit sends not only the file's data, but
also system-dependent structural information about the file.  Since this
information can be quite lengthy, it is sent as if it were file data, in data
packets preceding the actual file data, rather than in attribute packets.  All
of this information is sent in binary mode (no conversions).

The receiver of the file can elect whether to act upon the label information,
or simply store it.  Kermit programs for simple file systems need no changes,
and can still act as repositories for labeled files, to be sent back later to
the system of origin.  On the other hand, labeled file transfers between like
systems (e.g. two VAX/VMS computers) will result in the reception of a file
with all the correct characteristics.

There are two possible modes of operation.  The first (and safer) mode
requires human intervention on a per-file basis, but an automatic mode is also
possible.

DEFINITIONS

A "bare" file is a file stored on disk that does NOT contain, as part of
its contents, Kermit-constructed label information.

A "labeled" file is a file stored on disk whose contents include
Kermit-constructed label information.

FORMAT OF A LABELED FILE

This description applies to a labeled file as stored on disk and to a bare
file that has label information added to it by a sending Kermit.

  BANNER  The literal text string "KERMIT LABELED FILE:", just the twenty
          characters within the quotes including the trailing colon, in 7-bit
          ASCII.  ASCII is used even on non-ASCII systems (like IBM mainframes
          with EBCDIC).

  IDLEN   A 2-byte ASCII decimal numeric length field, with leading zeros if
          necessary, for example "02".

  SYSID   The system ID, one of the codes listed on pp.275-278 of the Kermit
      book.  This is a string of 1 to 99 ASCII characters (but typically
          1-3 characters), for example "D7" for VAX/VMS.  The length of the
          SYSID field is given by the preceding field (IDLEN).

  LBLEN   A 2-byte ASCII numeric length field, with leading zeros if
          necessary, for example "00", "02", "09", "99".

  LABEL   A label field, 1 to 99 ASCII characters.  The length is given by
          the preceding length field (LBLEN).  The LABEL field contains the
          name of the file descriptor data that follows.

  VALEN   An 8-byte ASCII numeric length field, with leading zeros if
          necessary, for example "00000512".  Zero ("00000000") is a
          permissible length for a value.

  VALUE   The value associated with the label, 0 to 99999999 bytes of
          information about the file in system-dependent format.  The labels
          and the format and layout of the associated values for each system
          type should be clearly defined and documented.

     The sequence (LBLEN, LABEL, VALEN, VALUE) may be repeated for as many
     labeled values are needed (if VALEN is zero, then VALUE is omitted).

  CONTENT The file's contents, encoded in whatever form that, in combination
          with the labeled values, allows for its eventual reconstruction in
          its original form.

All fields in a labeled file are subject to whatever encoding, prefixing, or
compression options have been negotiated by the two Kermit programs.

REQUIRED LABELS

The following labels (composed of ASCII uppercase letters) are reserved, and
are required in every labeled file:

  VERS    The operating system version, e.g. "5.3-1".  If there is no version
          to be specified, this label must still be present, but with a
          zero-length value.

  DATA    This is the final label.  It always has a zero-length value, which
          is followed immediately by the file's contents, as defined above.

EXAMPLE

A hypothetical example for VMS (ignore the indentation and line breaks;
the length fields are marked with L's):

                      LL  LL    LLLLLLLL     LL   LLLLLLLL
  KERMIT LABELED FILE:02D704VERS000000055.3-103FAB00000512<512 bytes here>
  03ACL00000723<723 bytes here>02DATA00000000<file's contents here>
  LL   LLLLLLLL                LL    LLLLLLLL

Note: FAB and ACL are not necessarily real labels.

EFFECTS ON THE KERMIT PROTOCOL

When SET FILE TYPE LABELED is in effect, the sending Kermit should include
the file type (") attribute, specifying a type of binary (B), if attribute
packets have been negotiated.  Otherwise, there is no effect on the protocol
at all.  In particular, a label-wise Kermit program can interoperate perfectly
well with another Kermit program that is completely ignorant of labeling, in
which case the latter program simply "archives" or "unarchives" the file,
labels and all (provided the user remembered to place it in binary mode).

This proposal does not rule out the system-independent type of file archiving,
based on file attribute packets, that is described in the Kermit book.
However, if the "system-dependent" attributes suggested by this proposal can
be worked out in a sufficiently generic fashion, this may lead to a more
effective type of transmission of complex files between unlike systems that
share similar types of file characteristics (block size, record format,
character set, carriage control, etc).

On the other hand, for the first pass at an implementation (for VMS), it might
make more sense to simply have a single system-dependent label, like "FAB",
whose value is simply the File Access Block, and perhaps another one like
"ACL" for its Access Control List.  The two approaches do not rule each other
out.

USER INTERFACE

When SENDING a file, the user should first determine whether it is a bare file
or a labeled file.  This can be done by visual inspection (looking at the
first 20 bytes), or from memory (e.g. because all labeled files have a
particular filetype, or are kept together in a certain directory).  Then:

  (a) If it is a bare file, use SET FILE TYPE LABELED if you want to send
      label information too.

  (b) If it is a labeled file, use SET FILE TYPE BINARY.

When receiving a file, use SET FILE TYPE LABELED if you want labels in the
incoming file to be interpreted and applied, and:

  (a) The other Kermit is sending a bare file from a like system using SET
      FILE TYPE LABELED, or:

  (b) The other Kermit is sending a labeled file, of the receiving system's
      system type, from any kind of system, without SET FILE TYPE LABELED.

The receiving Kermit program that has been given a SET FILE TYPE LABELED
command must inspect the incoming data.  The first 30-36 bytes of the first
packet contain the BANNER, IDLEN, SYSID, and the first LBLEN, and LABEL (which
should be "04VERS").  If these five items are in correct format, and the SYSID
matches the program's own, then the program will accept the file in labeled
mode.  Otherwise, it will treat it as a binary file and store all the data,
including BANNER, SYSID, LABELs, VALUEs, and all length fields.

If a receiving Kermit program has accepted the file in labeled mode, but then
encounters an unknown label or other inconsistency in the labeled file format,
it must interrupt the file transfer (by putting an X in the data field of the
first available ACK) and discard the file.  This is because it cannot be
expected to back up and undo whatever label interpretation it has already done.

It is also conceivable that "similar" systems -- such as the DEC operating
systems VMS and RSX-11 -- might be able to honor each other's labels.  This
eventuality should be allowed for, possibly with SET commands.

At the discretion of the programmer, a command such as SET FILE
LABEL-DETECTION { AUTOMATIC, MANUAL } could be installed.  If so, the default
must be MANUAL, that is, processing of labeled files occurs only if the user
asks for it explicitly.  For an arriving file, AUTOMATIC mode would detect the
BANNER, SYSID, and first LABEL and go into action as if the user had SET FILE
TYPE LABELED.  When sending a file, the program would avoid adding surrounding
label information if the user had already SET FILE TYPE LABELED.  This sort of
thing is obviously dangerous, and users should be cautioned about it.

POSTPROCESSING

Separate programs should be provided to translate a labeled file into a real
file, to be used in case the user forgot to SET FILE TYPE LABELED, or the file
was deposited by means other than Kermit.  Such a program might have two
options (or come in two forms): interpret the labels, and simply strip the
labels.

ACKS

Thanks to Terry Kennedy and Frank da Cruz for suggesting this idea, and to Joe
Doupnik, John Chandler, and Paul Placeway for many valuable suggestions.
Comments welcome!

------------------------------

Date: Mon, 27 Aug 90 10:13:45 EDT
>From: Christine M. Gianone <[e-mail]>
Subject: And ANOTHER New Test Release of MS-DOS Kermit 3.02
Keywords: MS-DOS Kermit 3.02

>From JRD's update notes since V12 #2:

48. Add recognition of IBM PC video boards STB VGA/EM Plus (Tseng 4000)
    and Everex Viewpoint EV-678, from Terry Kennedy. The list of boards known
    to Kermit for switching between 80 and 132 columns is now:
    ATI EGA Wonder
    AT&T
    Everex Viewpoint EV-659, FVGA-673, EV-678, Micro Enhancer Deluxe
    Paradise AutoSwitch EGA Mono
    STB VGA/EM (Tseng TVGA)
    STB VGA/EM Plus (Tseng 4000), VGA/EM-16, VGA/EM-16 Plus
    Tseng Labs EVA board w/132-col kit installed
    Tseng Labs UltraPAK mono/Hercules w/132 column modes
    Video 7 Vega Deluxe w/ 132X25.COM driver installed and Video 7 VGA

49. Add a facility to the keyboard translator.  Let key definition strings
    of the form {\Kverb other material} activate an existing Macro if and
    only if the verb is not in the list of those predefined for the keyboard
    translator.  If "verb" matches the name of a regular Kermit Macro execute
    the Macro and stay on the Kermit command line; thus a CONNECT command is
    needed to return to Connect mode. If verb does not match a Macro then do
    nothing and stay in Connect mode. Be aware that searching tables for the
    name of the verb uses many cpu cycles and will reduce performance.

    Examples:
        DEFINE Accumlate Receive, Connect
        SET KEY \315 {\Kaccumulate}

    Pressing the IBM PC "F1" key (code \315 above) makes the keyboard
    translator see string {\Kaccumlate}, verb "accumlate" is not in the
    predefined tables, and hence Kermit invokes the Macro named ACCMULATE.
    That Macro puts Kermit into file receive mode and when the file, or
    file group, transfer has been completed it returns to Connect mode.

        DEFINE WP Take wp30.ini, Connect
        SET KEY \316 {\Kwp}

    This makes IBM PC key "F2" invoke macro WP which in turn reads in
    and executes the contents of file WP30.INI. Kermit then returns to
    Connect mode. Nothing happens if the user has not defined Macro WP.

    Braces around the whole key definition are required so that the search
    for the verb name is done while executing Connect mode rather than when
    defining the key. If the braces are omitted then only the predefined
    keyboard verbs are available; an error will be reported if the verb is
    not one of these.

    Text sent to the host may preceed and follow the \Kverb part. To avoid
    confusion "Kverb" itself, but not the "\", may be placed in braces too,
    such as:

    DEFINE Accumulate cd c:\junkmail,Receive,Connect
    SET KEY \315 {kermit\13\send foo.bar\13\{KAccumulate}exit\13}
    the pieces:   |_______________________||............||_____|
                  string to host          do Macro    string to host

    This sends the string "Kermit<carriage return>Send foo.bar<carriage ret>"
    to the host to invoke its Kermit and asks it to send file foo.bar. It
    then invokes local Macro Accumulate to receive the file, and finally it
    sends the string "exit<carriage return>" to the host. Braces around
    KAccumlate deliniate it from the final string text.

    There is no host command which can invoke these Macros; this protects the
    PC against stray garbage text and unauthorized commands from the host.
    Files changed are MSUIBM.asm (procedure keysv) and MSYIBM.asm.

50. Reinstate Dump screen: filename on Status display. msssho, msyibm

51. Correct a misprint in the National Replacment Character sets for Spanish.
    Apparently a DEC typist inserted one accent mark too many in the table.
        char value    was        is now
    60h \96        accent        accent        just for reference
    7bh \123    accent        degree
    7ch \124    degree        n tilde
    7dh \125    n tilde        c cedilla
    7eh \126    c cedilla    tilde
    Corrections are in file mszibm.asm

52. Embellish the VT300 character set abilities by permitting National
    Replacement Character (NRC) sets to be "designated" by the host to a
    particular Gn set table, viz:

    Designator         Mnemonic       Description of Action
    ESC ( <ident>    SCS    Designates 94 byte character set <ident> to G0
    ESC ) <ident>    SCS    Designates 94 byte character set <ident> to G1
    ESC * <ident>    SCS    Designates 94 byte character set <ident> to G2
    ESC + <ident>    SCS    Designates 94 byte character set <ident> to G3

    where <ident> is:
    NRC country  <ident>        NRC country  <ident>
    British        A        Italian        Y
    Dutch        4        Norwegian/Danish ' (hex 60) or E or 6
    Finnish        5 or C        Portuguese    %6
    French        R        Spanish        Z
    French Canadian    9 or Q        Swedish        7 or H
    German        K        Swiss        =

   Example: ESC ) A  loads the British NRC set (A) into G1 (the ")" part).
   To load Latin1 into G1 use  ESC - A  because Latin1 is a 96 character set.
   NRCs are all 94 character sets.

   This embellishment does NOT turn on NRC operation in the Digital Equipment
   Corporation sense. To follow DEC usage employ SET TERM CHARACTER-SET to
   choose the country and have the host enable or disable NRCs by sending
   CSI ? 42 h  or CSI ? 42 l, respectively.
   Changes are in file mszibm.asm.

53. Minor code corrections to parsing eight bit controls introduced by item 52.
    File mszibm.

54. Incorporate support for Novell's TELAPI TCP/IP Telnet program. This
    is selected by command

            SET PORT TELAPI nnn.nnn.nnn.nnn

    where nnn.nnn.nnn.nnn is the Internet address of the remote host, in
    decimal.

        Example: SET PORT TELAPI 129.123.1.11   (machine netlab.usu.edu)

    TELAPI is a component of the Novell package LAN WorkPlace for DOS. At
    Utah State University it was run with the Novell (ex-Excelan) EXOS 205T
    Ethernet board (a smart mutiprotocol board supporting TCP with NetWare
    IPX 802.3 style packets). Novell Utility TSU.EXE is not required.

    SET PORT TELAPI must not be confused with SET PORT NOVELL(NASI); they
    use very different communications methods.

    Notes on this new faciity:

     a) Hosts not on the local network will likely require their
        Internet address and the local gateway to be specified with utility
        ROUTE, such as
            ROUTE ADD 128.59.39.2 129.123.1.254
    The first address is watsun.cc.columbia.edu, in New York City,
    and the second is that of a local gateway box (a cisco, Inc router
    at Utah State University in Logan, Utah).

     b) The communications channel is opened as an 8-bit wide BINARY
        character at a time mode, thus Unix hosts may require Line Feed
    (Control J) as a line terminator. See also item g) below regarding
    character \255.

     c) Included in this work is sending a BREAK signal as a Telnet
        "Interrupt Process" command.

     d) A status message is shown for 3 seconds if the connection cannot
        be established.

     e) Once an Internet number has been specified with SET PORT TELAPI it
        will be retained for subsequent SET PORT TELAPI commands. Thus it
    need be stated only once. SHOW COMMUNICATIONS will display the number.

     f) The presence of the host can be checked by sending the two bytes
         \255\246  which is Telnet signal "Are You There", and to which the
    host is supposed to send back a bell or visible message. This can
    be arranged easily by command SET KEY <key's ident here> \255\246
    if SET TERMINAL CHARACTER-SET TRANSPARENT is selected.
        See TCP/IP documents RFC-854 and RFC-855 for Telnet specifications.

     g) Character \255 is special in Telnet; it introduces Options negotiation.
        To send \255 as data it must be sent twice, as \255\255 or use the
    new command SET SEND DOUBLE \255 to do this for Kermit packets.
        Please be aware of this character when sending Binary files.

     h) TELAPI version 3.5 sometimes has trouble hanging up a connection. It
        will attempt creating a new one for each new session and can exhaust
    its space (defaults to two of them) when an old one persists. The
    only cure I know is to unload the TELAPI TSR (DOS command TELAPI -u)
    or reboot the machine.

     i) TELAPI version 3.5 is also notably slow in delivering characters to
        terminal emulators. Expect an effective 2400 baud rate.

     j) TELAPI uses Interrupt 14h with high numbered function calls. Beware
        of using other Int 14h trapping programs simultaneously.

     k) Kermit uses only the Internet number form of addressing for TELAPI
        because the TCP "name resolver" (conversion of a name to a number)
    is not available directly with TELAPI. Thus, full compliance with
    TCP/IP specs is not available to Kermit or other external terminal
    emulators using the TELAPI interface. The full specs recommend using
    names and letting a separate group of machines, called Name Servers,
    provide the Internet number via TCP/IP methods.

    All the changes are confined to file msxibm.asm

55. Correct a real bug: if SET LOCAL ON and while in Connect mode Control-
    PrintScreen (copy screen to printer) are active then Kermit crashes the
    system. The reason is a stack overflow when the same function ends up
    calling itself again by roundabout means. Adequate correction required
    small revisions about what is or is not echoed locally. Now almost every
    thing except DEC status reports is echoed (my real VT320 seems to do the
    same). Affected files are msyibm.asm and mszibm.asm, done on 14 August.

56. Add Enviroment and command line SET COM1 and COM2 to the list as per
    item 4 above.

57. Significant change to \%n variables defined as macro arguments. For each
    Macro invocation first save variables \%0 through \%9, clear \%0..\%9,
    define \%0 to be the name of the macro being invoked and \%1..\%9 as
    the arguments to the macro. When the macro exits restore the previous
    \%0..\%9 variables. This process nests naturally, and ARGC still
    represents the one plus the number of macro arguments. C Kermit 5A and
    MS-DOS Kermit 3.02 are now in agreement on these items.
    Previously \%0 was not affected by macro invokation and \%1..\%9 were
    not saved and restored around the macro. The new behavior may affect
    scripts written in the past. File mssset.asm

58. Add alternative command syntax:
    SET FILE COLLISION means the same as older SET FILE WARNING
    and SET FILE COLLISION DISCARD is the same as SET FILE COLL NO-SUPERSEDE.
    Changes are in mssset.asm and msssho.asm

59. Correct problems with REM LOGIN. Is the last of problems in this area?

60. Correct problems with CTS/RTS handshake timing and half duplex. Tnx to
    Brian Holley for spotting them. msxibm.asm

61. Add DESQview support call to release the cpu timeslice when in Connect
    mode and no character is available from the serial port. msyibm.asm

62. Modify the retry procedure to send a packet character to wait 60ms rather
    than 10ms between each of five attempts. This may help situations where
    a network device may be unresponsive for about 200ms between characters.
    msscom.asm

  More changes are expected.

The mstibm.boo file and the source files are in kermit/test on watsun and in
the T: area of KERMSRV.  The binary .EXE file is available on watsun only in
kermit/bin/mstibm.exe.  There is also a test 3.02 version for the DEC Rainbow,
contributed by Robert Weiner of Cooper Union.  It is in kermit/test/mstrb1.boo
and kermit/bin/mstrb1.exe.  The latest Rainbow test version tracks the non-IBM
specific portions of MS-DOS Kermit, and adds some new character translations
for screen dump and print screen.  Thanks to Joe and Robert for their
continuing work on MS-DOS Kermit!

------------------------------

Date: Mon, 27 Aug 90 14:13:12 EDT
>From: Christine M. Gianone <[e-mail]>
Subject: A New Version of Kermit for OS/2 Presentation Manager
Keywords: OS/2 Presentation Manager Kermit

Contributed by Brian R. Anderson of Burnaby, BC, Canada.  Here is the note
that accompanied Brian's submission:

"The version of Kermit contained herein is for OS/2-PM.  It was written from
scratch by the author (Brian R. Anderson) in Stony Brook Professional
Modula-2.  A two part article in the September/October 1990 issues of Dr.
Dobb's Journal describe this implementation (which is a port of an earlier
program that I wrote for DOS in Logitech Modula-2).

This program is public domain, and may be copied freely, modified/enhanced,
and distributed freely (in original or enhanced form).

Included on the disk are an executable version of the program
(PCKERMIT.EXE); 17 Modula-2 source code files (8 .DEF and 9 .MOD); icon and
resource files; make and linker response files, and the EXE definition file.
To recompile the program: M2MAKE PCKERMIT <cr>.  The program includes:

      Kermit single and multiple file transfer
      TVI950 Terminal Emulation (optimized for IBM7171/PROFS)
      Automatic renaming of files in case of name clash
      Continuous display of communications settings"

Brian indicates that this program is the starting point for a program that
will be sold commercially.  Further details are in the file O2AAAA.HLP.

The files are in the Kermit test area for now, pending reactions from the
Kermit user community:

watsun.cc.columbia.edu    BITNET KERMSRV@CUVMA    Comments
  kermit/test/o2aaaa.hlp    T:O2AAAA.HLP            "boo" encoding of program
  kermit/bin/o2aker.exe                             Executable program
  kermit/test/o2aker.boo    T:O2AKER.BOO            "boo" encoding of program
  kermit/bin/o2aker.ico                             Program icon
  kermit/test/o2aico.boo    T:O2AICO.BOO            "boo" encoding of icon
  kermit/test/o2asrc.jar    T:O2ASRC.JAR            Source code

The boo files can be decoded into the original binary files using any of the
msbpct programs available in kermit/a.  The "jar" file is a text archive of
the source files that can be picked apart with a text editor or a simple
program.  Brian's submission did not include a user manual.

Many thanks to Brian for contributing this program.

------------------------------

Date: Sat, 28 Jul 90 12:10:27 PDT
>From: rochester!ames!claris!portal!cup.portal.com![e-mail]
Subject: New Release UCPECAN Kermit V1.1
Keywords: Pecan, USCD Pascal Pecan Kermit

I am submiting a minor upgrade to UCPECAN my Kermit-UCSD (Version 1.1).

You should recieve 2 files: 1) a large (about 1400 lines) one containing
the source (UCPUPD.PAS) and a very short one containing "installation
instructions" and a brief list of changes made to V1.1 by this upgrade
(UCPUPD.UPD).  The changes are

1)  Added a new Unit (DIR.FIXES) to work around problems
    encountered with SFS. This update removes Limitation #4,
    making BINARY file transfers exact in both SFS and AFS
    implementations.

2)  Fixed a bug that caused an incorrect time to be sent in
    the attribute packet if no time was specified with the
    creation date (this bug affected both AFS and SFS).

                      R. Tim Coslet

Usenet: [e-mail]
BIX:    r.tim_coslet

[Ed. - Many thanks, R. Tim!  The new files have been installed in the Kermit
Distribution C area.  Keep up the good work!]

------------------------------

Date: Tue, 07 Aug 90 02:00:41 MEZ
>From: "Gisbert W.Selke" <[e-mail]>
Subject: MS-Kermit 3.0x and German telephones
Keywords: MS-DOS Kermit 3.0, German

Here's a (partial) solution to a problem no-one besides me seems to have had:
I'm running MS-DOS Kermit over a 1200 bps line in what is yet West Germany.
For some obscure reason, the German PTT transmits the signal to my phone that
can be used to record the fee due. (No, I never had such a gadget. Maybe some
former owner of this flat had.) Unfortunately, the tone used for this is
right within the range used for 1200 bps transmissions. So, if I'm lucky,
I get a corrupted packet every 8 to 12 minutes (for local calls - much more
often for trunk calls); if I'm in terminal mode, however, I get some 10
scrambled characters on the screen. So far, so annoying. But you ain't seen
nothing yet: some of the garbage obviously contained shift-in/-out sequences,
so that I was left with funny graphics characters all over the screen
henceforward, where ordinary 7-bit ASCII should have been. The solution came
with one of the 3.02 revisions of MS-Kermit: 'set term char ascii g1' takes
care of the odd shift!

Still, some of the garbage even throws me out of that; apparently, it loads
a different character set into gx, where x = 1..3. So, if anyone has a way
of doing away with the disturbances altogether, any help/hints/pointers will
be appreciated, with software solutions muchly preferred.

\Gisbert   c/o  <UPP101.DBNRHRZ1.BITNET>

------------------------------

Date: Mon Aug 27 10:19:29 1990 EDT
>From: Christine M Gianone <[e-mail]>
Subject: Looking for Stories

 ... of how Kermit has been used in imaging and visualization applications,
including modelling, CAD, medical imaging, and so forth, for possible
publication.  MS-DOS Kermit graphics, Kermit protocol imbedded in imaging or
CAD systems, whatever you know about ...

------------------------------

End of Info-Kermit Digest
*************************

From cmg  Tue Sep 11 14:07:49 1990
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA05561; Tue, 11 Sep 90 14:07:49 EDT
Date: Tue, 11 Sep 90 14:07:48 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V12 #4
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Tue, 11 Sep 1990        Volume 12 : Number 4

  MS-DOS KERMIT:

        Next Test Release of MS-DOS Kermit 3.02
        Kermit on Novell Networks
        Feedback on MS KERMIT 3.02 of July 20
        Kermit Problems - V3.01
        MS-Kermit and VAX ALLin1
        Question about Kermit 3.01 and the 128-byte history buffer
        Kermit & WordPerfect under PCSA
        Re: MSKERMIT <-- TCP/IP --> Unix-Host

Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.1), IP host number 128.59.39.2.  Login as user anonymous
(note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired
files.  The Kermit files are in directories kermit/a, kermit/b, kermit/c,
kermit/d, and kermit/e.  Test versions are in kermit/test.  Binaries are in
kermit/bin (use ftp in binary mode).  You can also get Kermit files over the
BITNET/EARN network; to get started send a message with text HELP to KERMSRV,
the Kermit file server, at host CUVMA.  For detailed instructions, read the
file kermit/a/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, 10 Sep 90 16:03:23 EDT
>From: Christine M Gianone <[e-mail]>
Subject: Next Test Release of MS-DOS Kermit 3.02
Keywords: MS-DOS Kermit 3.02

63. Correct a small problem leading to confusion in terminal emulation if an
    arriving control sequence is terminated prematurely by another. msscmd.asm

64. Add command REMOTE SET FILE COLLISION UPDATE, meaning the file receiver
    on the other side should process files with the same name as "updates"
    (whose meaning is system dependent) to existing files. A MS-DOS Kermit
    server does not recognize the command. mssser.asm

65. Another small adjustment to item 62. Move the long interval retrying of
    sending characters to be at the final launching point for BIOS comms
    channels. The intent is to compensate for a particular X.25 channel which
    rejects new characters with a failure indication; that channel is known
    to be very sluggish. This change permits character retries for Connect
    mode and scripts as well as packets. msscom.asm, msxibm.asm

66. Ensure that the graphics terminal emulation writes characters as opaque,
    when so selected, for black and white displays. msgibm.asm

67. Accomodate LATIN5/Cryillic character set of Code Page 866 as much as
    possible. The command SET TRANSFER CHARACTER-SET has the new option
    LATIN5, and if selected will force FILE CHARACTER-SET to be CP866.
    Similarly, if the FILE CHARACTER-SET is selected to be the new option
    CP866 then it will force TRANSFER CHARACTER-SET to be LATIN5.
    Warnings are issued for both cases.

    When sending a text file with TRANSFER CHARACTER-SET LATIN5 the file
    attributes packet will send "I6/144" for the file character-set
    identification (the "C" attribute) and no translations will be done.

    When receiving such a file no translation will be done, regardless of
    the currently active FILE CHARACTER-SET. Actually the file should be
    rejected unless the user has stated SET UNKNOWN-CHARACTER-SET to KEEP,
    but the code gets very messy if the rule is enforced at this time.

    The reason is for the coupling of commands is CP866 has many Cryillic
    characters in the right, high bit set, section which have no equivalents
    in other Kermit character sets and regular Code Pages. Hence, when LATIN5
    or CP866 is selected there can be no translation of characters between
    CP866 and either the other (Western European) Code Pages or the LATIN1
    character set. Thus LATIN5 or CP866 selects a Transparent file transfer
    but with a LATIN5 "I6/144" character set identification.

    For terminal emulation SET TERMINAL CHARACTER-SET TRANSPARENT will prevent
    unwanted translations and also convert the C1 controls area into printable
    characters found in CP866.
    Files affected are mssfil.asm, mssset.asm, msyibm.asm.

68. Add communications enhancement to using the Int 14h serial port
    interceptor TES from Interconnections Inc (distributed with Novell
    NetWare for VMS). The new command

        SET PORT TES <optional host name>

    invokes TES and make a connection to the indicated host. This competes
    with SET PORT BIOSn because they use some common operations.

    <optional host name>        Action
        host-name       Connect to that host, and disconnect from a previous
                        TES host if such a connection were active.
           *            Show all available TES hosts but do not connect.
        nothing         Use the current TES host name to reestablish an
                        existing connection. Most useful when switching
                        between TES and a real serial port. If no host name
                        exists then a list of available hosts is shown.

    Keyboard verb \Knethold is used to invoke the TES command interpreter
    while in Connect mode (to revise connections usually), and HANGUP breaks
    an existing connection. Sending a BREAK (ALT-B or \Kbreak) performs the
    same function for TES as \Knethold. Use this function when manual control
    of sessions is desired, such as creating multiple sessions managed by
    TES rather than by Kermit.

    These new TES operations couple closely with version 2.x of TES and will
    not work with earlier ones. Instead use SET PORT BIOS1 and the TES hot
    key with older TES's. If the TES hot key is used then \Knethold may not
    be recognized; use the hot key again to control TES. If the hot key has
    not been used then TES material is shown on the Connect mode screen.
    SHOW COMMUNICATIONS will show the current host name, as read back from
    TES itself. The apparent serial port identifier on the Connect status
    line is the letter "I".

    Note that placing a connection on hold and later returning to it may
    require pressing the \knethold or \kbreak keys and typing RESUME to make
    the TES command interpreter return control to the data stream. It's
    apparently a problem in the interpreter.

    If Kermit is exited completly then the active session is terminated, but
    held sessions are retained. Thus, to preserve sessions after Kermit has
    exited use \knethold or \kbreak to get the TES command interpreter and
    place the connection on hold manually. The session may be resumed as above.

    I am testing with TES version 2.1 beta so both sides have growing pains.
    Modifications are all in file msxibm.asm

69. Make an attempt to pass macro arguments \%0..\%9 through (around) a
    TAKE command to keep some consistency with MS-DOS Kermit 3.00 and 3.01.
    For example,
        DEFINE DIAL Take Hayes.tak      which has dialing commands
        DIAL 555-1212                   we want the number passed down to the
                                        interior of Hayes.tak as \%1.

    where file Hayes.tak (from the diskette with Chris' book) starts off as
        COMMENT - Initial setup
          def errstop echo Error: \%1\13,def \%1,hang,stop
          set speed 2400                ; *** Change to 1200 ...
          <more stuff in here>
          echo \13Dialing \%1.  Wait...\13\10  ; Dialing for the first time,
          goto dial                     ; so skip the "Redialing" message

        COMMENT - Dialing loop
        :REDIAL
          echo \13Redialing...\13\10    ; Give this message when redialing
        :DIAL
          output ATDT\%1\13             ; Dial the number
          <more stuff follows>

    Another example:
        DEFINE xxx Set term VT302,take x.tak,connect
        xxx A B C
    where file x.tak holds
        echo \%0 \%1 \%2 \%3

    This displays  XXX A B C and then enters Connect mode as a VT320 terminal.

70. Add a new element to command line variables, taken from C Kermit 5A.
    Numerical variables ARGC, COUNT, ERRORLEVEL, and VERSION can be used as
    the ascii representation of their values by the new text substitution
    operator

        \v(numerical variable)

    Soon this will be expanded to include other "named variables" such as
    TIME, DATE and so on which are also internal quantities in Kermit.

    Examples:
        ECHO The version number of this program is \v(version) today.
    which displays
        The version number of this program is 302 today.
    And DEFINE See ECHO \%0 - the num var is \v(\%1) here.
        See argc
    which displays
        SEE - the num var is 2 here.
        See version
    which displays
        SEE - the num var is 302 here.

    The expression \v(numerical variable) is replaced by it's ascii value.
    This may be used in any command. The current syntax of IF = ARGC 2 ...
    is retained for compatibility purposes but in new scripts it should be
    replaced by IF = \v(argc) 2  etc.

    If the item within the parentheses is not one of the above numerical
    variables, or if a right parenthesis does not end the variable name
    then the entire expression from \v( to the current point is discarded.
    Examples of bad syntax:
        ECHO testing \v(versions) stuff
    or
        ECHO testing \v(version stuff
    both of which display
        testing stuff

    All the changes for this item are in file msscmd.asm

 More changes are expected.

[Ed. - The Cyrillic and \v() items are not final.  An actual translation
between CP866 (Alternative Cyrillic) and ISO 8859-5 will probably be
installed before 3.02 is released.  \v(name) will probably be changed to
require the name of a builtin variable (which need not necessarily be
numeric) within the parentheses.]

------------------------------

Date: Thu, 09 Aug 90 10:22:53 EDT
>From: Doug Salane <[e-mail]>
Subject: Kermit on Novell Networks
Keywords: MS-DOS Kermit, Novell Network

I am trying to use Kermit for station to station communication on my Novell
Network.  This is an ELS Level II Network which uses Arcnet cards in a bus
topology.  I would like to use Kermit to transfer files between machines
without relying on the server.  Is this possible?

I have tried using the SET PORT NETBIOS and SET PORT NOVELL after loading the
Novell IPX workstation shell.  I get an error message that says the Network is
not available.

I'd appreciate your help. Thanks.

[From jrd - Doug, what's needed is NetBios running on top of IPX and NET3/4.
It's in the Novell NetWare collection. After that just follow the instructions
in the Kermit documentation about SET PORT NET <name>. I use Kermit that way
here, and it is also the official AT&T method of talking to an AT&T Unix
machine from a DOS PC. SET PORT NOVELL(NASI) uses the NASI/NACS async server,
not what you want at all.
        The short form of the documentation says start the Server Kermit
first (SET PORT NET, Server). No destination address is needed by the server.
Then start a client Kermit with SET PORT NET <server's NetBios name> and
issue file transfer or REMOTE commands.]

------------------------------

Date: Sat, 21 Jul 90 14:23:19 PDT
>From: [e-mail] (Leland Bruns )
Subject: Feedback on MS KERMIT 3.02 of July 20
Keywords: MS-DOS Kermit 3.02

I am forwarding some feed back on the test version of MS KERMIT version 3.02
and some comments on version 3 in general.  Please forward to the appropriate
persons.  Thank you.

ENVIRONMENT

First, my environment is a Wedge Technology 386-based PC-AT clone, with a
Video-7 VGA board.  I am compiling using MicroSoft's MASM version 5.01.  My
hosts are VAX VMS and Ultrix machines.  The PC's operating system in PC-DOS
version 3.30.

[From jrd - similar to my own environment: DELL 310, Video-7 VGA, VMS host,
PC-DOS 3.30]

I have recently copied MS KERMIT version 3.02 from the /kermit/test directory
at watsun.cc.columbia.edu.  My comments below are based on the versions dated
July 15 and July 20.  (I see there is a new version this morning, July 21, but
have not had the chance to port or test this version.)  I am comparing the
test version 3.02 to the original 3.00 distribution version.

TEKTRONIX EMULATION PROBLEMS

I see that there are significant changes to the MSGIBM.ASM module for
Tektronix emulation, and have concentrated on looking for differences there.
The one difference I would like to report is in the way GIN input apparently
works in the new version.  In the original 3.00 version, when a key was
entered at the PC, the host would receive the ASCII code for the character
entered, the 4 character xy coordinate, and one final character (I can't tell
easily from the host software I have to work with what that final character
is, as the software discards it).

The new version 3.02 test version apparently does not send the GIN report to
the host until the user has entered the desired key (at which time the
cross-hair cursors disappear) AND an additional carriage return.  Not too
surprising, the host receives an additional character which must be ignored to
continue properly.

I believe that the behavior of the original version 3.00 of MS KERMIT is
correct, while that the new test 3.02 version is incorrect.  The user should
not have to enter both the desired key plus a carriage return for each GIN
input point.  I would very much like to see the original behavior restored.

[From jrd - advice is most welcomed because my Tek docs seem to differ
about what should happen (they are not consistent either).]

FEEDBACK & ENHANCEMENT REQUEST

Since I'm taking the time to report the problem above, I'd like at the same
time to pass on some positive feedback on MS KERMIT version 3 and an
enhancement request.  I very much like the work that has gone into MS KERMIT
between versions 2 and 3.  KERMIT is unique in its universal availability, its
faithful terminal and graphics emulation, and public availability of source
code.

The latter feature, availability of source code, is important to me as I have
one minor hardware incompatibility for which I must modify each KERMIT release
as it becomes available.  Specifically, I have dedicated hardware on all four
COM ports, and on IRQ2 thru 5 (see the comments below).  In order to make use
of my 9600 Baud Telebit Trailblazer modem on COM3, IRQ5, I must create a copy
of MS KERMIT modified to use IRQ5 rather than IRQ4.

I don't think my situation is too uncommon these days, as more and more
powerful PC's become available and are equipped with more and more hardware,
requiring use of COM ports 3 and 4.  I frequently see queries posted asking
how to get around the restrictions imposed by the current MS KERMIT.  I think
many users would benefit the ability to specify the interrupt number and
address on a per port basis...just as the newer MS KERMIT versions now allow
specification of the COM port address.  Failing that, the next best thing
would be to allow the user to define the interrupt numbers and addresses in a
straightforward manner in the MSXIBM.ASM source (vs. the convoluted encoding
required at present...see my difference file below).

[From jrd - But.... If one is not using all the COM ports simultaneously then
one can use two at once if they are on different IRQ lines. Just ask Kermit to
touch the competing ports so their interrupt driver chips are taken off the
bus (as decent software should have done anyway). I am reluctant to move far
from IRQ 3 and 4 because of the interference with other peripherals (IRQ 5 is
the hard disk controller on XTs). I can't easily change things in v3.02
anwyway because of the necessary revisions to the data structures. Btw, I too
have a Trailblazer (T2500), and I avoid most serial port conflicts via a $30
RS232 A-B-C-D box; COM1 is comms, COM2 is the mouse.]

Once again, let me say how much I appreciate the work going into MS KERMIT
version 3.  Thanx in advance for your consideration of the suggestions above.

[From jrd - Thank you for the suggestions and the compliment.]

                                        Leland M. Bruns
                                        Intel Corporation
                                        [phone]
                                        [e-mail]

------------------------------

Date: Wednesday, 25 Jul 1990 13:06:12 EDT
>From: "Larry F Armbruster" <[e-mail]>
Subject: Kermit Problems - V3.01
Keywords: MS-DOS Kermit 3.01

I have experienced several problems using Kermit.  The configuration
of my system is:

  PS/2 Model 50Z with an AT&T Voice Data Multiplexer dialing into a
  DECserver 200 V3.0 (BL33) - LAT V5.1 and accessing VM/CMS through
  a DECnet/SNA Gateway into a SIM3278 session manager.  Also at times
  I access a VAX cluster.

I have redefined the PS/2 function keys to emulate the VT100/200/300 series
of terminals.

When I emulate a VT320 - the session messages (ie SYS AVL, etc) writes to
the top line of the screen thus wiping out the top line of the screen.
When I emulate a VT102 - the session messages are at the bottom of the screen.
This is only an annoyance and I can live with emulating the VT102.

The serious problem is the inability to use Kermit file transfers on either
CMS or VAX.  My computer center is aware of the CMS problem and attribute it
to the session manager.  However we cannot explain the VAX problem.  The VAX
Kermit Host (or maybe Mskermit) issues a parity error.  This is the case no
matter what parity, duplex, or flow control is used.  Any suggestionor help
is greatly apperciated.

[From jrd - since the pathway between the PC and either IBM/CMS or the VAX
goes through two external communications boxes one supposes that one or the
other box is adding its own parity, or more likely, is unable to handle a
stream of characters as long as a packet. Otherwise MS-DOS Kermit does run
fine to VAXen through common LAT boxes. Logging packets on both ends and
viewing the log files will show which machine is experiencing the troubles.]

------------------------------

Date: Wed, 15 Aug 90 08:08 CDT
>From: DEC-WOLF <[e-mail]>
Subject: MS-Kermit and VAX ALLin1
Keywords: MS-DOS Kermit 3.01, VAX/VMS, ALLin1

Hello all,

I was wondering if there were other Ms-Kermit (3.01) users who are using PCs to
communicate with a VAX and who use ALLin1, who are also experiencing problems
with printing over the printer port.  We have determined that everything works
fine when the Vax thinks the terminal type is a VT200.  If the terminal type is
NOT VT200 series than the printing is erratic or non-existent.  After
researching the problem I dicovered that Allin1 is sending the following escape
sequences for the two terminal types:

VT20O   Esc [ 5 i

VT100   Esc [ 5 i Esc [ 6 i
VT300

The Esc [ 5 i is the proper sequence to open the printer port for a VT100,
VT200, or VT300 terminal.  After calling Digital, I was told that (Esc [ 6 i)
was the escape sequence to open the printer port for the VT125 terminal.
Evidently the sloppy programmers at DEC check for VT200 ONLY and send the VT100
and VT125 sequences for other terminals.  It seems that either Kermit or the
printers are confused by the (Esc [ 6 i) sequence.  I know that Dec should just
straighten their act out but I was wondering if anyone knew how to work around
this problem from the Kermit end.  Could the (Esc [ 6 i) sequence be ignored or
stripped out by Kermit?  We plan on just changing the terminal type to VT200 on
the Vax end but it seems a bit kluging to me (normally the Vax and terminal
communicate the terminal type between each other at login).

Bill Bryson
User Services Analyst
CC_BRYSON@SWTEXAS

P.S.  Our systems personel could also patch allin1 to change the printer
scripts (i.e. not send ESC [ 6 i) but feel it is unlikely that they will (it is
considered a no-no to "mess" with Digital software).

[From jrd - MS-DOS Kermit v3.02 consumes the ESC [ 6 i and does not send it
to the printer. Yes, it's a carry over and should not be there. Here is the
entry in the file msr302.upd describing changes to version 3.02 -
15. Correct bug in transparent printing within text emulator which corrupted
    back to back escape sequences sent to the printer.]

------------------------------

Date: Fri, 27 Jul 90 17:47 EDT
>From: John W Manly <[e-mail]>
Subject: Question about Kermit 3.01 and the 128-byte history buffer
Keywords: MS-DOS Kermit 3.01, CLEAR Command

Hi there.  Another question about MS-Kermit and the use of the history buffer
in Take or Script files.

Could anyone fill me in on the relationship between the INPUT statment, the
REINPUT statement, the CLEAR command, and the 128-byte history buffer?

In particular, the manual states that REINPUT only accepts additional input
from the serial port until the history buffer is full.  How does one then
clear it out?  A CLEAR command presumably does so.  Does an INPUT operation
clear it as well, or clear it only if it's full, or anything like that?

Any help would be greatly appreciated.  Thanks.

                                 - John W. Manly
BITNET:  JWMANLY@AMHERST           Systems Manager
PHONE:   [phone]            Amherst College

[From jrd - The CLEAR command does indeed clear things: the history buffer
and the serial port receive circular buffer (preceeds the history buffer).
I agree that a separate script history buffer clearing command would be
beneficial. In the meanwhile, the history buffer can be made either larger
or smaller via the DOS command
   SET KERMIT=INPUT-BUFFER-LENGTH value
value is number of bytes (default 128)]

------------------------------

Date: Tue, 31 Jul 90 14:44 EDT
>From: Pete Kanaitis <[e-mail]>
Subject: Kermit & WordPerfect under PCSA

Recently, we have been looking at WordPerfect 5.0 under VMS and have tried
the MS-Kermit macros and DCL command procedure (ftped from watsun) to set
the IBM PC keyboard to do WP bindings.  This seems to work fine under any
asynch connection, but does not seem to work with MS-Kermit running under
PCSA.   Under PCSA, when the terminalS and terminalR macros are envoked,
the key bindings are set, the connect command gets issued, but the original
terminal session gets disconnected!  (Since we use virtual terminals, we
can re-connect back to the WordPerfect session, and resume, but only after
we re-login in)

Here's an example of what is happening:

MSKERMIT.INI has the following:

set port decnet singer
set terminal wrap on
define terminalS take C:\wp30.ini, connect
set key \2344 \KTerminalS

Then from the PC:

C>kermit
IBM-PC Kermit ...

MS-Kermit>connect

Welcome to Singer...
Username: FOOBAR
Password:

$ @PUBLIC:PCWP
What type of Graphics adapter are you using (ega, cga, vga)?  vga

$ WP FILE.EXT
Defining Function Keys for WordPerfect Products....
(After a few seconds Kermit reconnects..)
(Nothing happens. When I hit any key...)

Welcome to Singer...
Username: FOOBAR
Password:

   You have the following disconnected process:

 ...
   Connect to above listed process [YES]:

(Now you are back in WordPerfect)
(When you exit..)
Save Document? (Y/N) Yes
Exit WP? (Y/N) Yes

WP key definitions cleared...

(screen clears, back to normal)

Does anyone have any ideas?

Thank you...

Pete Kanaitis
Manager, Computational Resources
Allegheny-Singer Research Institute
[e-mail] (Internet)
X979PK0P@CMCCVB (Bitnet)

[From jrd - When WordPerfect starts up it requests a long Color Palette
report from the VT300 terminal. Kermit sends the report fine, but some
communications channels can't handle 200 some odd byte bursts. Also, the
VAX must have SET TERM/HOSTSYNC so that the VAX can XON/XOFF the terminal.
There is really nothing I can do, because on my VAX some paths just can't
cope, even when I insert massive pauses between characters. Sometimes
it's the length of the DEC Color Palette report which is the root problem.
My test copy of WordPerfect/VMS has exceeded it's 6 month lifetime, but
I recall that I could use PCSA/DECnet-DOS fine this way. The only "but" is
the VMS command SET TERM/HOSTSYNC must be stated.]

------------------------------

Date: Wed, 18 Jul 90 14:34:55 -0400
>From: [e-mail]
Subject: Re: MSKERMIT <-- TCP/IP --> Unix-Host
Keywords: MS-DOS Kermit, TCP/IP, Unix

In article <[e-mail]> you write:
>In <[e-mail]> [e-mail] (Gressel) writes:
>
>>Hello,
>
>>we tried it with an Interlan-NI5210-Card, no success!
>
>In Kermit News number 4, June 1990 Joe R. Doupnik and Christine M. Gianone
>writes:
>
>TCP/IP is a very widespread networking method linking machines locally and
>around the world.  ...

I would like to add that Wollongong's Pathway Client Plus also supports
the INT 14 service.  We use both Kermit and Procomm Plus Network Version
and they work great!

Mark Regester Information Systems & Services, NCR Peripheral Products Division
 NCR:654-8340 <[e-mail]>
[phone] <uunet!ncrlnk!ncrwic!m.regester>
 FAX:[phone]

[From jrd - Yeah! A WINning way.]

------------------------------

End of Info-Kermit Digest
*************************

From cmg  Mon Sep 17 16:04:06 1990
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA01766; Mon, 17 Sep 90 16:04:06 EDT
Date: Mon, 17 Sep 90 16:04:06 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V12 #5
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Mon, 17 Sep 1990        Volume 12 : Number 5

Today's Topics:

       Announcing IBM Mainframe VM/CMS Kermit-370 Version 4.2.1
           Selecting CONTROLLER type in Kermit-370
              Announcing  KERMIT-12 Version 10g
            Kermit Proposal SET FILE TYPE
               Prime8 Help for Dividing Source
      Re: A New Version of Kermit for OS/2 Presentation Manager
            Re: Info-Kermit Digest V12 #2
            Kermit incapatability with LSE
            Kermit 3.01 Arrow Key Problem
            132 column mode in MS-Kermit?
                  Kermit & Telebits

Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.1), IP host number 128.59.39.2.  Login as user anonymous
(note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired
files.  The Kermit files are in directories kermit/a, kermit/b, kermit/c,
kermit/d, and kermit/e.  Test versions are in kermit/test.  Binaries are in
kermit/bin (use ftp in binary mode).  You can also get Kermit files over the
BITNET/EARN network; to get started send a message with text HELP to KERMSRV,
the Kermit file server, at host CUVMA.  For detailed instructions, read the
file kermit/a/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, 1990 Sep 12   18:30 EDT
>From: "John F. Chandler" <[e-mail]>
Subject: Announcing IBM Mainframe VM/CMS Kermit-370 Version 4.2.1
Keywords: IBM 370 Kermit, VM/CMS Kermit
Xref: CMS Kermit, See VM/CMS Kermit, IBM 370 Kermit

This is to announce the release of Kermit-370 version 4.2.1 for CMS.  As
usual, the new version comes in VM/SP and VM/XA/SP flavors, but the
changes are the same for both.

Version 4.2.1 has several improvements over 4.2.0, the most important
being:

 1. Spurious flow-control "packets" from MS-DOS Kermit are now ignored.

 2. Overflow of the fullscreen buffer is now avoided when the receiving
    Kermit asks for 2K packets.

 3. Kermit-370 now supports transfers in LATIN2 and LATIN3 and file
    storage in CP870, CP880, and CP905.  In addition, L1, L2, and L3 are
    recognized as aliases for the three LATIN sets, and two-character
    abbreviations are accepted for the other transfer sets as well.  The
    new sets add support for Afrikaans, Albanian, Catalan, Croatian,
    Czech, Esperanto, Galician, Hungarian, Maltese, Polish, Romanian,
    Slovak, Slovene, and Turkish.

 4. Kermit-370 supports file transfers through the IBM 3174 AEA with B2
    microcode.  The support is restricted to terminals with the ASCII
    Graphics capability in three ways:

    a) The terminal type must be defined in the 3174 to support graphics
       (only the built-in VT241 and Tektronix 4205 types plus suitable
       user-defined terminal types).

    b) The line must be defined without an associated Host Addressable
       Printer.

    c) If the 3174 is owned by VTAM, the connection must be made with a
       logmode that allows the Read Partition Query (such as M2SDLCNQ).

    Kermit-370 automatically detects the B2 AEA and sets CONTROLLER
    accordingly (to AEA if graphics is allowed, to NONE if not, or to
    GRAPHICS if Query is denied).  Since the 3174 supports full 8-bit
    communication, it may be useful to configure the ports for 8-bit
    data and to set both SEND and RECEIVE PARITY to NONE in Kermit-370.

 5. Kermit-370 now uses the FILE COLLISION settings for all files in a
    group rather than just the first.

 6. Kermit-370 has three new subcommands: REMOTE MAIL, REMOTE PRINT, and
    REMOTE SUBMIT.  They transmit a file (or group of files via wild
    cards) tagged for mailing, printing, and submitting as job,
    respectively.

The new release is in the form of updates to be applied to the 4.2.0
source.  The new files are IKCKER.UPD, IKCKER.BWR, IK0AAA.HLP, and
IK0KER.UPD (the latter is only a catalog of all the updates, not the
updates themselves).  The new code has been tested on most known types
of protocol converter (many thanks to the beta testers!) to make sure
the 3174 support does not harm the existing support for Kermit file
transfer, but problems may still turn up.  Bug reports are welcome, as
usual.

A similar release 4.2.1 will soon be available for TSO and MUSIC.

                                         John

[Ed. - Thanks, John!  The new files are installed in kermit/b on watsun
and are also available from KERMSRV@CUVMA on BITNET.  This program is truly
amazing in its adaptability to the infinitely varied 3270 emulation
communications environment, and it is a groundbreaker in character set
conversion.  Let's hope that the other Kermit programs catch up in the latter
department soon.  For that to happen, we need examples and listings of the
PC, UNIX, Macintosh, etc, character sets used for all the language supported
by Latin Alphabets 1 through 5, Latin/Cyrillic, and others.  If you have them,
please send them in and we'll do our best to support them.]

------------------------------

Date: Thu, 1990 Sep 13   11:50 EDT
>From: "John F. Chandler"   <[e-mail]>
Subject: Selecting CONTROLLER type in Kermit-370
Keywords: IBM 370 Kermit

One of the improvements in release 4.2.1 is a more thorough DEBUG output
that proved very useful in bringing the support for the IBM 3174 to
completion.  This enhancement makes no difference to routine file transfer,
but it raises the possibility of determining easily the exact response of
any kind of protocol converter to the efforts of Kermit to decide which
CONTROLLER type to use.  To this end, I ask all installers of release 4.2.1
to take a few minutes and create a debug log for each (fullscreen)
environment where Kermit-370 might be used, provided, that is, that you do
not apply the optional update SC89058.  Even if you have applied SC89058 in
the past, it might be worthwhile to omit it as an experiment.  The desired
debug log is created by starting Kermit-370 and entering the subcommands SET
DEBUG I/O LONG, SET LINE, and QUIT.  I would be grateful if you would send
the resulting KER LOG along with the following information: level of VTAM
(if any) driving the session, model of front-end processor (if any) and
software, model of protocol converter (if any) and software.  These results
would be interesting even for real IBM 3270-type terminals or protocol
converters unable to support Kermit file transfers.  It is possible that the
information collected will enable Kermit to distinguish certain environments
that currently fail to trigger the correct default CONTROLLER type.

                                    John

P.S. My e-mail address is:

 Internet:    [e-mail]
 BITNET:      PEPMNT@CFAAMP

------------------------------

Date: Thu Sep 6 1990 11:00:00 EDT
>From: Charles Lasner <[e-mail]>
Subject: Announcing  KERMIT-12 Version 10g
Keywords: PDP-8, PDP-12, VT-78, DECmate, OS/8
Xref: DEC PDP, See PDP

This is a maintenance release of KERMIT-12.  A minor problem relating to
incorrect CPU identification messages has been fixed.  The problem only
appeared when the CPU was a KK-8A single-board CPU; this configuration was
previously untested.  Thanks to Johnny Billquist of Sweden for his
assistance in pinning down the problem.

KERMIT-12 operation was not affected in any other way, as only the
DECmate-specific identification is crucial; earlier PDP-8 family members
are treated in a generic fashion except for the "frill" of model
identification (all PDP-8, PDP-12, VT-78 models use software-compatible
port hardware;  all DECmates are incompatible and must be handled
individually).  We are still looking for volunteers to test the various
DECmate III and DECmate III+ configurations.

The rest of the release concerns the encoding of files into the
"ASCII-fied" format.  The format has been modified to be more robust, since
the original method has proven itself to be problematic in certain
practical circumstances (as reported in K12MIT.BWR).

The new ENCODing format is based on five-bit encoding with repeat
compression.  As much as 256 repeated 12-bit words will be expressed in a
five character field.  Any repeated 12-bit value can be compressed, as
opposed to simple zero compression, as in other common encoding schemes.
(PDP-8 files often have repeated strings of the value 7402 octal, which is
the HLT instruction.)

The only printing characters required to pass through any distribution
"path" are 0-9, A-V, X, and Z. The alphabetic characters can also be
lower-case.  All command lines are framed by ( and );  all data lines are
framed by < and >.  These characters can be changed if required, as they
are not part of the data; they could be replaced by W (w) and Y (y) if
necessary.  (Changing the framing characters requires slight modification
of the ENCODing and DECODing programs.)

The new format supports a 60-bit file checksum to ensure proper decoding at
the other end.  The former 12-bit checksum could be compromised on long
files.

The new ENCODing programs creates internal (REMARK commands stating the
ENCODed file's creation date, and the original file's creation date.  This
will aid in distribution of PDP-8 files where the user wishes to maintain
proper file dates.  The date algoritm used is the one proscribed by the
OS/8 DIRECT program. (OS/8 systems only OPTIONALLY support file dates, and
there is an eight-year "anomaly" associated with identifying the year; the
user must determine the credibility of the year portion of the date.  The
value provided by the ENCODE program for the original file creation date is
always today's year or the previous seven years as necessary; this field
will not be provided if the system doesn't support the required AIW
feature.)

Overall file size is theoretically as much as 6/5 of the original encoding
format (as the earlier format was based on six-bit encoding), but actual
size varies downward due to slightly less file overhead (wider lines mean
less CR LF; there is now less automatically generated verbiage), and the
random improvement afforded by simple repeat compression.

Virtually all K12MIT-related files are re-released at this time.  There are
several new files.  Due to the "fragile" nature of TECO macro files, the
file K12GLB.TEC is no longer being distributed directly; the file K12GLB.ENC
is the same file in the new ENCODE format.

The new files have been installed in the regular places:

BITNET/EARN       Internet
KERMSRV@CUVMA     watsun.cc.columbia.edu     Description

 K12MIT   ENC      kermit/d/k12mit.enc        Encoded binary of KERMIT-12
 K12MIT   DOC      kermit/d/k12mit.doc        Documentation file
 K12MIT   BWR      kermit/d/k12mit.bwr        Updated "beware" file
 K12MIT   DSK      kermit/d/k12mit.dsk        Description of RX02 diskettes
 K12MIT   ANN      kermit/d/k12mit.ann        Announcement of KERMIT-12
 K12MIT   UPD      kermit/d/k12mit.upd        Release update file
 K12DEC   PAL      kermit/d/k12dec.pal        Decoding program
 K12ENC   PAL      kermit/d/k12enc.pal        Encoding program
 K12PL8   ENC      kermit/d/k12pl8.enc        Encoded binary of PAL8 Ver B0
 K12CRF   ENC      kermit/d/k12crf.enc        Encoded binary of CREF Ver B0
 K12MIT   PAL      kermit/d/k12mit.pal        Main source file of KERMIT-12
 K12PCH   PAL      kermit/d/k12pch.pal        KERMIT-12 source patch file
 K12CLR   PAL      kermit/d/k12clr.pal        Memory clearing file
 K12MIT   LST      kermit/d/k12mit.lst        Symbols-only listing file
 K12PRM   PAL      kermit/d/k12prm.pal        Sample VT-78 config file
 K12GLB   ENC      kermit/d/k12glb.enc        Encoded TECO file macro
 K12ENC   DOC      kermit/d/k12enc.doc        Encoding format description

[Ed. - Many thanks, Charles.  Believe it or not, there are still quite a
few PDP-8 based systems out there, and even some PDP-12s.  You won't find
very many other new software packages that support them!]

------------------------------

Date: Thu, 6 Sep 90 08:47 CST
>From: <[e-mail]>
Subject: Kermit Proposal SET FILE TYPE
Keywords: Kermit Protocol

Please accept these remarks regarding the proposed SET FILE TYPE extension
to Kermit.

1.  The labels are transmitted in normal Data packets.  Therefore an
ignorant Kermit receiver will write them into the file as data.  This is a
MAJOR change to the protocol, which has always provided transparent file
exchange.  When reading such a file, how is a program to know that labels
have already been included?  Will these files cause problems for other
file-transfer protocols such as Xmodem?

[Ed. - No, it won't cause problems with Xmodem.  Xmodem or any other file
transfer protocol, including a Kermit program that does not know about labeled
files, will store or send a labeled file just like any other file, without
interpreting the label information.]

2.  Stored-in-File labels are incompatible with the MacBinary protocol in
    standard use on Macintosh computers.

[Ed. - That's true.  But MacBinary format cannot be adapted to other kinds
of file systems such as VAX/VMS.  Kermit can still be used to transfer
MacBinary files, and a MacBinary option will be added to Macintosh Kermit
before its next release.]

3.  The sending operator must now decide whether to send with labels or not.
    Previously, the sender had no choices to make.  We should not be adding
    complexity to the process if we can help it.

[Ed. - This is true.  However, without labels it is impossible to transfer a
complex file and retain all of its features.  Therefore this proposal
addresses only computers with complex file systems, like VAX/VMS, IBM
mainframes, etc, and does not affect other computers.  Users can continue to
use Kermit on these systems in the normal way, but now they will also have
an additional tool to let them successfully transfer files that they could
not transfer before.]

4.  Perhaps a better approach would be to use:

        SET FILE TYPE system type

    Where 'system' identifies the receiving file management system,
    (RMS, VSAM, etc.) and 'type' identifies the appropriate attributes.
    Example:

        SET FILE TYPE RMS INDEXED

    where RMS represents Vax RMS file management, and INDEXED identifies
    the incoming file as an indexed file.

    This approach requires that the sending and receiving routines be
    similarly intelligent about the information required to successfully
    transmit and write the file, but allows unintelligent intermediary
    programs (repositories, bulletin boards, etc.) to receive and send
    the files without any special settings (other than SET FILE TYPE BINARY).

[Ed. - It is a cardinal principle of Kermit or any other well-designed file
transfer protocol that any particular computer must not be required to have
knowledge about the formats and conventions of any other kind of computer.
Rather, each Kermit implementation knows only the data formats of its own
computer and those defined for the "standard intermediate representation" on
the wire.  Otherwise, hundreds of different programs would require
modifications to know about hundreds of different computers.  Not only is
this a waste of computing and human resources, but it's a moving target.]

    It also allows the following sequence to take place:

      machine 1 Kermit send  -> machine 2 Kermit receive (FILE TYPE BINARY)
      machine 2 BrandX send  -> machine 3 BrandX receive
      machine 3 Kermit send  -> machine 4 Kermit receive (FILE TYPE xxx ttt)

    Machine 1 sends the file BELIEVING that the receiver knows how to handle
    it, but only the machine 4 program needs to know.  However, machine 3
    can also use the file, if it recognizes, or is told to recognize, the
    file type.

[Ed. - The Labeled File proposal works the same way.]

    A simplification of this approach would be to use SET FILE TYPE AUTO
    which would cause the receiver to perform some recognition process
    before writing the file.

[Ed. - The labeled file proposal includes this possibility too.]

We have recently developed a Macintosh VT100 terminal emulator which
incorporates Kermit file exchange, and automatically distinguishes TEXT
documents from applications and formatted documents.  The users need only
tell the Vax to SET FILE TYPE ASCII/BINARY depending on whether they intend
to edit it on the Vax, or transfer it to another Mac.  The program pre-pends
the Macbinary header for non-text documents when sending, and recognizes it
when receiving.  I think you'll agree that the LABELED proposal only adds
complexity to our situation, and requires users to make unnecessary
decisions about the process.

[Ed. - Your application seems to be Macintosh-centered, in the sense that
you regard the VAX as a repository for Macintosh applications, which you
encode in MacBinary, but you make no provision for storing VAX applications
or complex binary VAX files on the Mac.  For your purposes, MacBinary will
do just fine.]

------------------------------

Date: Tue, 28 Aug 90 17:27:31 EDT
>From: John M. Crawford <[e-mail]>
Subject: Prime8 Help for Dividing Source
Keywords: Prime Kermit

Enclosed is a short file which provides the necessary Primos editor (ED)
tricks to divide (and then build) Kermit 8.12 for Primos. You might consider
appending it to the PRIME8.ANN file (or another) for general distribution to
Prime kermit users.

John M. Crawford      [phone]                Computing Services Center
                                                    College of Business
[e-mail]                                     1775 College Road
[e-mail]                     The Ohio State University
[e-mail]               Columbus, Ohio 43210

[Ed. - Many thanks!  Your ED file is now enshrined in PRIME8.ANN.]

------------------------------

Date: Wed, 29 Aug 90 10:23:11 PLT
>From: Wim Bonner <[e-mail]>
Subject: Re: A New Version of Kermit for OS/2 Presentation Manager
Keywords: OS/2 Kermit

The message said that the Kermit files were in the OS/2 test area pending
comments from the user community.  Is this where I make comments?

I tried the Kermit program just now.  It has an annoying habit of going full
screen.  I have a 1024x768 screen, so an 80,25 screen will fit in less than
a quarter of the screen, and leave room for much more on the screen.

I am running OS/2 1.2, and was not able to get the lights on my modem to
blink when I typed characters after Connecting.  That is normally a good
indication something is wrong.  All of the other communication programs that
I've tried work fine.

Wim Bonner - [e-mail] - V(509)335-4436

[Ed. - Thanks.  We'll collect all such comments and put them in an envelope
and send them back to the contributor.  Meanwhile, has anyone else gotten
the program to work?]

------------------------------

Date: Sat 25 Aug 90 11:51:37-CDT
>From: Rob Pettengill <[e-mail]>
Subject: Re: Info-Kermit Digest V12 #2
Keywords: MS-DOS Kermit 3.02, Macros, Variables, Scripts

The behavior of the macro positional parameters has changed in the new test
release of MSKermit 3.02.  Previously when a take script was taken in a
macro the \%n positional arguments were defined in the take script - with
this version they are undefined.

The previous behavior was reasonable for a script.  Are you tring to make
take files behave more like macros?  If so then it should be possible to
pass positional arguments to the take files explicitly.  In any case the
behavior in the current 3.02 does not seem desirable.

;rob

[Ed. - That was a mistake, which has been corrected in the latest 3.02
release.  Macro parameters are now on a call stack so if macro A calls macro
B, A's parameters are still intact when B returns.  The mistake was indeed
that a TAKE file was being treated like a macro.  In the latest edit, it is
not: if macro A TAKEs a command file, A's parameters are available to the
TAKE file, as before.]

------------------------------

Date: 29 Jul 90 23:18:00 CDT
>From: "COLLINS, STERRETT" <[e-mail]>
Subject: Kermit incapatability with LSE
Keywords: MS-DOS Kermit 3.0, LSE, VAX/VMS, Terminal Emulation

I am using MS-Kermit v3.0 on a Kaypro 286 operating MS-DOS v3.21, connecting
to a VaxCluster operating VMS v5.3 .  I have tried using the language
sensitive editor (LSE v3.0), but Kermit fails to emulate the terminal that
LSE expects.  I have tried setting terminal/nodec_crt3, which partially
corrects the problem, but still not satisfactorily.  I am not sure that LSE
does not think that every member of the VT300_Family of terminals is a Regis
terminal.  I have access to a Regis_Emulating communications software
package, which I do not normally use for licensing considerations, but
which, if I switch to that after having entered LSE using Kermit, is able to
emulate the terminal properly.

The possible answers would seem to be:

"The operating system does not successfully detect the correct terminal
characteristics."

"The Operating system does successfully detect the correct terminal
characteristics, but this information is not propperly transferred to LSE."
I only know that SHOW TERMINAL reveals that it does not have the REGIS
characteristic, but does have the SIXEL charactersitic, and the DECCRT_3
characteristic.

                                        sterrett collins
                                        physics department
                                        texas tech university

[From jrd - Another case where Kermit command SET DISPLAY 8 needs be done
to avoid clobbering the 8-bit control sequences sent by the host.]

------------------------------

Date: Mon, 23 Jul 90 19:44:42 GMT
>From: [e-mail] (Greg Seminara)
Subject: Kermit 3.01 Arrow Key Problem
Keywords: MS-DOS Kermit, Arrow Keys

Arrow keys work only sporadically when connected to a UNIX host from a DOS
PC running Kermit 3.01 if you are using a full-screen "curses" application.
Seems to be sending either the wrong ansi sequence or is sending the
sequence too fast.  If you press arrow keys with a significant pause between
each press, keys usually work OK.  Emulation is vt102 for kermit and TERM is
set to "kermit" or "vt100".  Kermit 2.32a and before work fine under
identical conditions.  - HELP!

[From jrd - your Unix host has a problem with communications.  If characters
in a control sequence are NOT sent in rapid succession then EMACS reacts
differently than expected.  In addition, some host machines apparently have
intrinsic difficulties running in true full duplex.  Unix loves to echo
arriving characters willy nilly.  So when Unix is sending a control sequence
while one is arriving from Kermit and Unix is also echoing it then Kermit
receives both sets of information with characters intermingled.  If the
sequences arrived separately then Kermit could cope.  This is pretty silly
behavior by Unix; the application should attempt supressing echos.  There is
nothing that Kermit (nor a real terminal) can do about it.]

------------------------------

Date: Thu, 30 Aug 90 14:28:57 CDT
>From: [e-mail] (Moore)
Subject: 132 column mode in MS-Kermit?
Keywords: MS-DOS Kermit, 132 Columns, Screen Settings

Greetings.

I have a very persistent user here who wants the word directly from the
horse's mouth regarding a feature of MS-Kermit:

I've always thought that EGAs cannot do 132-column mode (except by simulating
it in graphics mode).  MS-Kermit doesn't change that, right?  Isn't it the
"responsibility" of the hardware to switch modes, and then Kermit just detects
and uses that mode?

[Ed. - True.  Except that in version 3.0 and later it also supports automatic
switching between 80 and 132 column mode via the COLS80.BAT and COLS132.BAT
mechanism.  That is, if Kermit gets the escape sequence telling it to switch
modes, it will try to run the appropriate BAT file that does the PC- or
adapter-specific things required to switch modes.]

Can Kermit simulate 132-column mode by letting the user pan an 80-column
window left and right?

[Ed. - No.]

Thanks for any help.

Jim
[e-mail]

------------------------------

Date: 27 Aug 90 11:42:05 GMT
>From: mrsvr![e-mail] (Tom Shaw ct58 Ex 5084)
Subject: Kermit & Telebits
Keywords: Modems

I'm looking for anyone who has/is doing something similar to this: I am
transferring binary and ASCII files across dial-up phone lines using Telebit
Trailblazer Plus modems and kermit.  The transfers are between 2 Suns, one
running Sun OS 3.5 and the other running Sun OS 4.01.  The size of the files
range from 2500 bytes to 800kbytes.  Does anyone have any tips, traps to
avoid, benchmarks of what kind of rate I should be expecting for ASCII and
binary files or any hands on advice.  I am using kermit version 4E(72).

In the past few weeks, I've heard stories about using Telebits in Germany,
what kind of problem is there and are there any other countries I might have
a problem connecting and transfering to?

Any help would be appreciated.  Thanks

Tom

[Ed. - As you may know, Telebits have Kermit built inside them.  If you
activate this feature, Computer A actually talks Kermit protocol to Modem A,
Modem A talks high-speed error-correcting PEP protocol to Modem B and Modem B
talks Kermit protocol to Computer B.  This is all done transparently to the
Kermit programs, but you have to put the originating Telebit into "Kermit
spoof" mode.  See your Telebit manual.]

------------------------------

End of Info-Kermit Digest
*************************


From cmg  Wed Oct 10 17:02:44 1990
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA02736; Wed, 10 Oct 90 17:02:44 EDT
Date: Wed, 10 Oct 90 17:02:42 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V12 #6
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Wed, 10 Oct 1990        Volume 12 : Number 6

Today's Topics:

               New Honeywell DPS-6 Superkermit
             Announcing Kermit for the Tandy 100
               CMS Kermit 4.2.1 erratum
               OS/2 PM Kermit Feedback
               OS/2 PM Kermit Feedback
              Easy Exit from Terminal Emulation
          Running MS-DOS Kermit 3.0x under DESQview
           USING MS-DOS Kermit 3.0 with MNP Modems
              MS-Kermit 4010 GIN mode by Mouse?
              Suppresing Kermit's Error Checking
              MacKermit Settings Trouble
             Larger Font for Mac Kermit 0.98(63)?
              Prime Kermit Version 8.12
              Kermit REMOTE SET Command

Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.1), IP host number 128.59.39.2.  Login as user anonymous
(note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired
files.  The Kermit files are in directories kermit/a, kermit/b, kermit/c,
kermit/d, and kermit/e.  Test versions are in kermit/test.  Binaries are in
kermit/bin (use ftp in binary mode).  You can also get Kermit files over the
BITNET/EARN network; to get started send a message with text HELP to KERMSRV,
the Kermit file server, at host CUVMA.  For detailed instructions, read the
file kermit/a/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: Tue, 2 Oct 90 11:42:02 PDT
>From: [e-mail] (Frank Dreano)
Subject: New Honeywell DPS-6 Superkermit
Keywords: DPS-6 Kermit, Honeywell Kermit

I am sending you a new version of the Honeywell DPS-6 Superkermit.  This
version basically 'blows out' the server mode to provide much more
functionality, (After Joe R. Doupnik's excellent effort to support the
Honeywell DPS-6 in MS-DOS Kermit 3.02 dev. 28, I felt like I had to respond
in kind):

1) Superkermit server 'gets' and 'sends' now support wildcard filespecs.

2) MS-DOS Kermit 'remote cwd' commands are now supported.

3) MS-DOS Kermit 'remote set file type { text, binary }' commands are now
   supported.

4) A new Superkermit file type, called 'foreign', supports MSDOS *.EXE,
   *.COM, *.WKS, *.ZIP, etc. file transfers WITHOUT converting to ASCII.
   MS-DOS Kermit 'remote kermit foreign' sets Superkermit for these
   transfers.  UNIX executables, etc, are likewise supported by this new
   file type.  The 'foreign' type also works with the VIP-3 terminal
   emulator.

5) MS-DOS Kermit 'remote type [filename]' commands are now supported.

6) MS-DOS Kermit 'remote host [host command]' commands are now supported.

7) MS-DOS Kermit 'remote dir [filespec]' commands are now supported.

8) MS-DOS Kermit 'remote delete [filespec]' commands are now supported.

9) MS-DOS Kermit 'remote mesage [text]' commands are now supported.

10) MS-DOS Kermit 'remote who' commands are now supported.

NOTE:  There ARE some warnings about using these commands...  See the
       HD6KER.BWR 'beware' file for details.

I received a request to allow the Superkermit server to select either
8th-bit or image mode binary transfers.  If I didn't implement this ability
the default would always be 8th-bit (not satisfactory in all cases).  So I
have implemented two additional commands:

                'remote kermit image'
                'remote kermit prefix'

   Performed a much-needed clean up of code placing all compiler pre-
   processor code along with global/external variables and function
   prototypes in a separate file.  In addition, I have adopted your
   naming conventions for the source files:

            HD6KER.DOC -  Version 2.00 documentation.
            HD6KER.H   -  New include file described above.
            HD6KER.C   -  Kermit state switchers and heuristics.
            HD6PRI.C   -  Kermit protocol primitives.
            HD6COMP.EC -  New Kermit batch compilation JCL.

I believe the above improvements have resulted in a much more useful
Superkermit 'server' mode as well as more manageable source code.  My thanks
to Tim Ewing of Honeywell Federal Systems Incorporated (HFSI) in McLean,
Virginia for suggesting and testing some of the above changes.  I feel that
the code reorganization and additional server functionality have made this a
major release and I am calling it Version 2.00.

Frank Dreano Jr.

[Ed. - Many thanks, Frank!  The new files have been installed in the "D"
area of Kermit distribution under the names you sent them with
(kermit/d/hd6*.* on watsun).  Special thanks for adjusting the filenames.]

------------------------------

Date: Tue Oct  9 21:29:27 1990
>From: Christine M Gianone <[e-mail]>
Subject: Announcing Kermit for the Tandy 100
Keywords: Tandy 100

Apparently floating around since 1984, discovered recently and sent in by
Jay Rouman: a Kermit program, written in BASIC by Dave Straayer, for the
Tandy 100.  No documentation.  In kermit/c/ta100.bas on watsun, TA100 BAS
on CUVMA.  Thanks, Jay!

------------------------------

Date: Mon, 1990 Sep 17   20:04 EDT
>From: "John F. Chandler"   <[e-mail]>
Subject: CMS Kermit 4.2.1 erratum
Keywords: Kermit-370, CMS Kermit, IBM Mainframe

The announcement mentioned restrictions on VTAM logmodes for successful file
transfer through the IBM 3174, but the example cited was one that does *not*
work.  The logmode that is known to work is M2SDLCQ.

[Ed. - A corrected copy of IKCKER.ANN (the announcement text for CMS Kermit
4.2.1) has been installed.]

------------------------------

Date: Tue, 18 Sep 90 11:20:12 -0700
>From: [e-mail] (Alan Bishop)
Subject: OS/2 PM Kermit Feedback
Keywords: OS/2 Kermit, Modems

In article <[e-mail]> Wim Bonner writes:
>
> I am running OS/2 1.2, and was not able to get the lights on my modem to
> blink when I typed characters after Connecting.  That is normally a good
> indication something is wrong.  All of the other communication programs
> that I've tried work fine.
>
You need to play with the octs & so forth settings.  Look under the
communcations setup bit & toggle all the settings on the line that has OCTS
listed.  It works fine for me.

------------------------------

Date: Tue, 18 Sep 90 14:23:25 EDT
>From: "Robert E. Zaret" <[e-mail]>
Subject: OS/2 PM Kermit Feedback
Keywords: OS/2 Kermit

I did get the Presentation Manager version of Kermit working, but haven't
spent much time with it.  I already have the full screen OS/2 Kermit and my
monitor is strict VGA, so I have no urge for a PM version.  Thus, I wasn't
going to comment.  However, the digest I received today asked for comments,
so:

My major dissappointment is lack of VT100 support.  I assume its absence is
temporary.  I've seen enough mangled emulators to believe VT100 emulation is
not trivial, so I'ld support a decision to leave it out until other parts
are settled.  However, I have little use for a program without it.

I was able to communicate with my internal modem; the modem responded to a
query (ATS1?) and to dial commands.

I found no way to save settings.
The speed setting is labelled baud, rather than bps.
I would prefer one pull down menu for all communications settings
    (com port, bps, parity, etc.)
I didn't find a documentation file, and the program itself mentioned
    no way to get out of communication mode except by exiting the
    program completely.  I tried ctl-[, and it worked.  This sequence
    seems inconsistent with the DOS version, but I'm not sure
    consistency matters, or is even possible.
I, too, found the program insisting on using a full screen.  The
    behavior of the maximimize box (upper right corner) seems odd,
    but I'm not sure what it should do given the other problem.
I believe PM programs can find and use the user's preferences for colors,
    as set in the control box.  Definitely not a high priority.

Technical note: I'm using IBM OS/2 EE 1.2 on an IBM Model 80/311 with
an IBM 8513 monitor and an internal BusinessLand modem (not quite
all blue :-).

------------------------------

Date: Wed, 18 Apr 90 11:49:40 -0700
>From: [e-mail]
Subject: Easy Exit from Terminal Emulation
Keywords: Terminal Emulation, MS-DOS Kermit, Macros

Here is an easy way to leave terminal emulation, hangup the phone, and drop
to DOS (I put it on alt-Z):

        def terminalr hangup,exit
        set key \2348 \kterminalr

(Thanks to Joe D. for pointing this out.)

Here is why I couldn't display IBM graphic characters even though I had my
display set for 8-bit and terminal character set transparent.

Ted.

[From jrd - Alas, VT100's are really 7-bit devices and this time I have
enforced the rule, to make character set stuff behave as DEC intended. Try
SET TERMINAL VT320.]

------------------------------

Date: Sun, 16 Sep 90 16:19 MDT
>From: Joe Doupnik <[e-mail]>
Subject: Running MS-DOS Kermit 3.0x under DESQview
Keywords: MS-DOS Kermit, DESQview

Assistance in creating a DESQview .DVP configuration file (DVSETUP.TXT)
for MS-DOS Kermit.

My copy of DESQview is version 2.26 running on a 386 machine with 2MB, with
no expanded memory, but with QEMM/386. The display adapter is a Video-7
"VGA".  The tables below are similar to the DESQview screens.

Please, when configuring QEMM to load-high drivers etc always exclude video
memory.

I have been able to run two copies of MS-DOS Kermit v3.02 together, to
different destinations with different communications ports. In addition,
full graphics capability was retained.
                                                Joe D.
 ============================================================================
                        Change a Program
 Program Name............: MS-DOS Kermit v3.02
 Keys to Use on Open Menu: KE                   Memory Size (in K): 200
                                                (say 150 minimum)
 ----------------------------------------------------------------------------
 Program...: Kermit.exe
 Parameters:            (Kermit command line items, if any, go here.)
 Directory.: C:\yourdir
 ----------------------------------------------------------------------------
 Options:
                Writes text directly to screen.......: [N]      *
                Displays graphics information........: [N]      **
                Virtualize text/graphics (Y,N,T).....: [T]      ***
                Uses serial ports (Y,N,1,2)..........: [Y]
                Requires floppy diskette.............: [N]

   *   Not true, but MS-DOS Kermit is DESQview-aware and covers up nicely.
   **  Not true, naturally, but causes DESQview to put Kermit into full
       screen mode while graphics are executed and then to return to windowed
       mode after switching to text terminal emulation.
   *** Can be [Y] with the same effect as above.
 ----------------------------------------------------------------------------
                        Change a Program Advanced Options

 System Memory (in K).....:     0  Maximum Program Memory Size (in K)..:
 Script Buffer Size.......:     0  Maximum Expanded Memory Size (in K) :
 Text Pages: 1  Graphics pages: 0  Initial Mode:  3    Interrupts: 00 to FF

 Window Position:
        Maximum Height:  25     Starting Height:  20    Starting Row...:  5
        Maximum Width.:  80     Starting Width.:  40    Starting Column:  5
  (Choose your own window sizes, naturally. 132 column mode causes DESQview
   to switch to full screen.)
 ----------------------------------------------------------------------------
                                Shared Program
 Pathname..:
 Data......:
 ----------------------------------------------------------------------------
 Close on exit (Y,N,blank)......: [ ]   Uses its own colors..............: [N]
 Allow Close Window command.....: [Y]   Runs in background (Y,N,blank)...: [Y]
 Uses math coprocessor..........: [N]   Keyboard conflict (0-F)..........: [0]
 Share CPU when foreground......: [Y]   Share EGA when foreground/zoomed.: [Y]
 Can be swapped out (Y,N,blank).: [ ]   Protection level (0-3)...........: [3]
 ============================================================================

------------------------------

Date: 9 Sep 90 06:27:49 GMT
>From: [e-mail] (Timo Salmi LASK)
Subject: Using MS-DOS Kermit 3.0 with MNP Modems
Keywords: MS-DOS Kermit, Scripts, MNP Modems

In article <[e-mail]> [e-mail]
(Andrew Rossmann) writes:

> I just bought a 2400 baud MNP5 modem (ATI 2400etc/e.) I have quickly
> found out that some modems do not like the attempt to set up an MNP
> protocol. I am currently using Procomm Plus. The problem is that there is
> no way for me to have a particular entry in the dialer set the modem's MNP
> on or off (a linked script file is only called AFTER connection.) Are there
> any other communications programs out there that let you send special
> initializations to the modem BEFORE dialing?  Is there a sneaky way to do
> this in Procomm Plus??
>
Yes, I've thought about the same problem, and MS-DOS Kermit has this
feature.  With proper script programming you can have MS-DOS Kermit do
whatever initializations do wish before dialing, and then on top of that
doing the dialing from a multi-entry dialing directory.  This MS-DOS Kermit
dialing directory facility is available in the /pc/ts/tskerm24.arc MS-DOS
Kermit utilities collection downloadable by anonymous ftp from
chyde.uwasa.fi, Vaasa, Finland.  The flexibility and potential of MS-DOS
Kermit as a fully fledged communication program rather than just an
excellent terminal emulator are often underrated and little known.

....................................................................
Prof. Timo Salmi        (Moderating at anon. ftp site 128.214.12.3)
School of Business Studies, University of Vaasa, SF-65101, Finland
Internet: [e-mail] Funet: gado::salmi Bitnet: salmi@finfun

------------------------------

Date: Thu, 20 Sep 90 17:41 MDT
>From: Pete Klammer 303/556-3915 <[e-mail]>
Subject: MS-Kermit 4010 GIN mode by Mouse?
Keywords: MS-DOS Kermit, Terminal Emulation, GIN mode, Graphics, Mouse

We find that the 4010 emulation in MS-KERMIT supports GIN mode, that is,
graphical cursor position input, which is great!  For instance, the ZOOM
command in ANSYS puts up a crosshair target on our screen, which we can
position with the cursor keys.  Pretty neat.

Is it possible to get our PC mouse connected to this cursor?  The GIN mode
steps with the cursor keys are pretty small, hence slow.  It would be even
neater than the already neat that it is, if MS-KERMIT Tektronix emulation
would support a PC mouse for GIN mode.  Thanks!

/** --poko ________________________________* "cut on dashes for mailing label"
Pete Klammer [phone] FAX[phone]|[e-mail]
CU-Denver Computing Services Campus Box 169|bitnet: PKLAMMER@CUDENVER
1200 Larimer St NC2506 Denver CO 80217-3364|uucp:...!boulder!pikes!pklammer **/

[Ed. - MS-DOS Kermit does indeed support mouse movement of the graphics
cursor.  Make sure you have given the necessary DOS commands to turn the
mouse on, such as MOUSE ON and/or DEFAULT.]

------------------------------

Date: Mon, 24 Sep 90 12:01:37 CDT
>From: [e-mail] (David J. Camp)
Subject: Suppresing Kermit's Error Checking
Keywords: MS-DOS Kermit, Error Checking, Kermit Protocol, Performance
Keywords: MNP Modems

I just read the December inquiry about suppressing Kermit's error checking
to save time when using an MNP reliable connection.  You could do a raw
download.  For instance, if you are on a host that will let you simply
'type', 'cat', or 'fstype' a file, you can tell Ms-Kermit to capture the
screen and let it flow.  The MS-Kermit command is 'log session filename'.
Make sure that you have 'set flow on' and that the host will recognize the
flow control to gate the transfer.  This will not work for binary files.

I do not recommend this.  The reliability of the link goes beyond the
mode-to-modem portion of the communication.  There are several things you
can do to improve the speed of Kermit transfers.  The first is to increase
your packet size.  Recent versions of Kermit allow packets near 1000 bytes
in length.

[Ed. - Kermit's theoretical maximum packet size is 9024.  MS-DOS Kermit 3.0
supports packets up to 2000 bytes.  IBM mainframe Kermit supports packets up
to about 1700.  The forthcoming release of C-Kermit 5A (watch Info-Kermit for
an announcement) can be configured to support the full 9K.]

I usually limit myself to 500, because MNP modems doing baud rate
translation fail with larger packets in non-MNP mode.  The speed of transfer
with 500-byte packets is very nearly that with 1000-byte packets.

I did some benchmarks to compare the speed in MNP stream mode vs. MNP block
mode.  My conclusion is that the difference is small, and you are better off
using stream mode to make interaction less jumpy.  A much bigger payoff is
gained by using long packets.

Next, use sliding windows if they are available.  I have done some
benchmarks to determine the optimum number of windows, and it is 2.

[Ed. - Actually, the optimum window size varies according to the round-trip
delay of the connection and its noise characteristics.  See Kermit News #4.
For a clean and relatively direct connection with MNP modems, 2 appears to
be a good size.  Also bear in mind that, in general, the large the window
size, the smaller the maximum packet size, because most Kermit programs have
a finite total packet buffer size.]

The last thing I can recommend is to use 8-bit communications if possible.
It may be necessary to do more than just 'set parity none', but I am not
sure of this.  If you are downloading from an IBM mainframe, this will
probably not work.  -David-

[Ed. - SET PARITY NONE is usually the default, but only works if the
connection is truly 8 bits wide.  Most IBM mainframes do not give you an
8-bit path.  Neither to telnet connections, nor most public data network
connections.]

[e-mail]                 ^        Mr. David J. Camp
[e-mail]        < * >      [phone]
...!uunet!wugate!wubios!david          v        "Be kind to sinners."
"Concentration impedes Inspiration."  ---  "Depend on God, who has dominion."

------------------------------

Date: Thu, 19 Jul 90 10:34:05 MST
>From: Tom Aurand <[e-mail]>
Subject: MacKermit Settings Trouble
Keywords: MacKermit 0.98

I'm having trouble getting XON/XOFF flow control to stick in the settings
file when using MacKermit 0.98 on different SE's.  Can I patch it?  Thanks
for your help.

[From Paul Placeway - Get a copy of 0.98(63) -- the difference between edit
62 and 63 was a fix for that and saving of parity.  BTW: DON'T USE MACBINARY
MODE -- sending a file in MacBinary mode will delete the file on the Mac (yes,
that's a bug).  I suggest you disable the MacBinary button with ResEdit.]

[Ed. - 0.98(63) is available in kermit/test/ckmker.hqx.]

------------------------------

Date:  Mon, 23 Jul 90 10:36:59 -0500
>From: [e-mail] (Robert T. Harms)
Subject: Larger Font for Mac Kermit 0.98(63)?
Keywords: MacKermit 0.98(63), Fonts

I would like to use a larger font with my Mac Kermit on a Mac IIci - related
to general eye problems of mine.  I have used ResEdit to replace the VT100
built in font with a Courier 12 font.  BUT this obviously isn't enough.  (1)
The WIND resource seems to permit increasing the width of the window, but
somewhere the dimensions of the window need to be coded as well, and (2) the
cursor position is erratic with respect to character width.

Is there some way I can customize the font size using ResEdit?  Or would
you advise me to leave well enough alone?

Bob Harms       [e-mail]

[From Paul Placeway - Unfortnatly, MacKermit 0.98 has the font size
parameters hard coded into it, so you can't change the font even if you find
all the right places to patch.

This will be fixed in the next release (I have that part of the code now
working, but other parts don't yet).  (I'm getting older and blinder too...
I like to run with a 10pt font (usually Courier 10)).]

------------------------------

Date: 04 Sep 90 18:02:39 O
>From: [e-mail]
Subject: Prime Kermit Version 8.12

Yesterday I transferred a copy of PRIME Kermit Version 8.12, and new
fresh copies of Kermit Version 3.0.1 for IBM PCs. Both sources compiled
and run flawless except:

1. Generic commands issued from PC to PRIME Kermit in server mode usually
respond with unimplemented command (e.g. remote who, remote dir, remote
delete, etc.) But they are implemented in Prime KERMIT!  There seems to be a
definition problem of generic commands either on the sender (PC) or upon
reception (PRIME Kermit).

[Ed. - This is because vanilla 3.01 sends improperly formed generic
commands.  The patch file MSR301.PCH fixes this problem and, of course, it
will be fixed in 3.02.]

2. The only generic command which led to an action was remote type file
(file being a text file).  However, PRIME Kermit sends garbage between every
character from the text file !

[Ed. - Hmmm...     Could this be because PRIME uses "negative ascii"?]

3. We run PRIMOS 22.1.2 on a PRIME CPU.  At Rev 22 major changes affected
AMLC I/O (more assignable lines then ever, especially lines over Ethernet
cables, with line numbers larger than 128! Same applies to user numbers, we
have numbers up to 996 users! That means that several old interfaces to
PRIMOS, e.g. calls to DUPLX$, ASNLN$ etc have new replacements, which MUST
be used to change communication properties when either a user number or a
line number is larger than 256!  This seems to be a serious problem to all
users of PRIME Kermit 8.12 using Rev 22 and up, on larger machines, since
some of the new interfaces did not officially exist on older Prime
Revisions, and I expect that they are users which are forced to use either a
newer revision (e.g.  all TCP/IP users) or an older revision (for example
older hardware, running into performance problems when changing to rev 22).
Coding of those routines must be revision dependent, to give all Prime users
a perfect program.

Marcus C. Wagner
Department of Statistics and Computer Science
Universitaetsstrasse 5/9
A-1010 Vienna, Austria, Europe
University of Vienna

Email: since our TCP/IP connection is in experimental operation (since
two months, with some severe TCP/IP implementation errors of PRIME),
it will happen that my email address via Internet fails (host seems to be
down for the outer world) Alternatively, I am reachable via EARN/BITNET.
[e-mail] (IP)
A4421DAC@AWIUNI11  (EARN/BITNET)

Thanks to all programmers, who invested so much time to redesign the
old version of Prime Kermit, which we implemented five years ago, several
known bugs of that old version during normal file transfers vanished in
the new program, not to mention the performance gain.

[Ed. - Thanks for the comments.  They have been sent to the PRIME Kermit
developers.]

------------------------------

Date: Fri, 28 Sep 90 20:00:00 PDT
>From: [e-mail]
Subject: Kermit REMOTE SET Command
Keywords: Kermit Protocol, Remote Set, Character Sets

I'd like to suggest a small extension to the Kermit remote set command.  As
you have it defined, the REMOTE SET TRANSFER CHARACTER-SET allows setting any
transfer alphabet that has a designator.  However, there is also the option
called TRANSPARENT or NONE, i.e. suppress translation completely.  Since that
option does not have a designator, one cannot set it.  I would like to have
some kind of extension to allow setting TRANSPARENT.  Perhaps we could invent
a designator, say, 0 (zero), or perhaps some other method to guarantee that
the TRANSPARENT setting does not conflict with any possible future designator.
We could perhaps invent a new registration, kermit (K), and have TRANSPARENT
be K0.

I came up with this problem while implementing translation in my kermit, but
for time reasons the remote set isn't going to make it into my next release,
so I'm not in a gigantic rush for this, but I'd like to resolve it.

[Ed. - This is actually a tricky situation.  The idea was that TRANSPARENT
should be the default, for compatibility with the hundreds of Kermit
programs that do not support the character-set extension.  Adding a new
designator to denote TRANSPARENT might confuse Kermits that don't understand
it, including Kermits that do support the character-set extension, if that
designator were to arrive in an Attribute packet.  Incoming files bearing
the new designator might be rejected because of "unknown character set" --
clearly undesirable behavior, avoidable perhaps by having the user SET
UNKNOWN CHARACTER-SET KEEP, but how to explain this to mere mortals?  So
far, it has been an implementation decision about whether character-set
changes based on incoming attribute packets are "sticky".  If they are, this
presents the problem that there is no way for a client to tell a server to
switch from translation to transparent.  So it would appear that a decent
compromise would be to invent a new designator, say K0, for TRANSPARENT, and
to support it in REMOTE SET TRANSFER CHARACTER-SET commands, but, at least
for a time, not use it in Attribute packets.  Opinions?]

By the way, the last info I have on remote set is dated 11 Dec 89.  Was there
anything later?

[Ed. - Three additional parameters were added in Vol 11 #4: REMOTE SET FILE
{ BLOCKSIZE, RECORD-LENGTH, RECORD-FORMAT }.  The details for RECORD-FORMAT
have not yet been worked out.]

The 11 Dec info has a minor problem in that file collision discard and ask
are both 4; I presume ask should be 5, to fit the pattern.

[Ed. - Right, ASK should be 5.  Thanks.]

Bruce Cowan
KEA Systems Ltd.

------------------------------

End of Info-Kermit Digest
*************************

From cmg  Tue Nov 20 16:21:26 1990
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA02155; Tue, 20 Nov 90 16:21:26 EST
Date: Tue, 20 Nov 90 16:21:26 EST
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V12 #7
Reply-To: [e-mail]
Queries-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Tue, 20 Nov 1990        Volume 12 : Number 7

Today's Topics:

      Announcing IBM Mainframe MVS/TSO Kermit-370 Version 4.2.1
           Announcing CP/M Kermit Version 4.10 for Testing
         New Test Release of Microsoft Windows Kermit
         Another New Prerelease of MS-DOS Kermit 3.02
           Rainbow Kermit Updated Too (for testing)
              New Kermit for Gould/SEL 32/77 MPX
          MS-Kermit 3.02 Argument Handling, Keyboard Mapping
            Re: Kermit REMOTE SET Command
               Kermit for STRATUS/VOS?
                 Kermit vs Hypercard?

Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.1), IP host number 128.59.39.2.  Login as user anonymous
(note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired
files.  The Kermit files are in directories kermit/a, kermit/b, kermit/c,
kermit/d, and kermit/e.  Test versions are in kermit/test.  Binaries are in
kermit/bin (use ftp in binary mode).  You can also get Kermit files over the
BITNET/EARN network; to get started send a message with text HELP to KERMSRV,
the Kermit file server, at host CUVMA.  For detailed instructions, read the
file kermit/a/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 Nov 15 11:45:38 1990
>From: "John F. Chandler"  <[e-mail]>
Subject: Announcing IBM Mainframe MVS/TSO Kermit-370 Version 4.2.1
Keywords: IBM 370 Kermit, MVS/TSO Kermit
Xref: TSO Kermit, See MVS/TSO Kermit, IBM 370 Kermit

Kermit-370 version 4.2.1 for TSO has now been released.  For the most
part, this release matches the version 4.2.1 for CMS announced in
September, but there are some system-specific differences.

Version 4.2.1 has several improvements over 4.2.0, the most important
being:

 1. Kermit-370 supports file transfers through the IBM 3174 AEA with B2
    microcode (or higher).  The support is restricted to terminals with
    the ASCII Graphics capability in three ways:

    a) The terminal type must be defined in the 3174 to support graphics
       (only the built-in VT241 and Tektronix 4205 types plus suitable
       user-defined terminal types).

    b) The line must be defined without an associated Host Addressable
       Printer.

    c) If the 3174 is owned by VTAM, the connection must be made with a
       logmode that allows the Read Partition Query (such as M2SDLCQ).

    Kermit-370 automatically detects the B2 AEA and sets CONTROLLER
    accordingly (to AEA if graphics is allowed, to NONE if not, or to
    GRAPHICS if Query is denied).  Since the 3174 supports full 8-bit
    communication, it may be useful to configure the ports for 8-bit
    data and to set both SEND and RECEIVE PARITY to NONE in Kermit-370.

 2. Overflow of the fullscreen buffer is now avoided when the receiving
    Kermit asks for 2K packets.

 3. Kermit-370 now supports transfers in LATIN2 and LATIN3 and file
    storage in CP870, CP880, and CP905.  In addition, L1, L2, and L3 are
    recognized as aliases for the three LATIN sets, and two-character
    abbreviations are accepted for the other transfer sets as well.  The
    new sets add support for Afrikaans, Albanian, Catalan, Croatian,
    Czech, Esperanto, Galician, Hungarian, Maltese, Polish, Romanian,
    Slovak, Slovene, and Turkish.

 4. Kermit-370 has three new subcommands: REMOTE MAIL, REMOTE PRINT, and
    REMOTE SUBMIT.  They transmit a file (or group of files via wild
    cards) tagged for mailing, printing, and submitting as job,
    respectively.

 5. Spurious flow-control "packets" from MS-Kermit are now ignored.

 6. When downloading ISPF PDS members, Kermit-TSO now uses the ISPF
    modification date as the time stamp (if attributes are enabled).

 7. Kermit-370 now uses the FILE COLLISION settings for all files in a
    group rather than just the first.

 8. The format of KER.LOG for SET DEBUG I/O has been extended to give
    hexadecimal buffer dumps like those of CMS Kermit.

The new release is in the form of updates to be applied to the 4.2.0
source.  The new files are IKTKER.UPD and IKTKER.BWR.  The new code has
been tested on both IBM 7171's (demonstrating downward compatibility)
and IBM 3174's (many thanks to the beta testers!), and the CMS version
had already been tested on other types of protocol converters, but
problems may still turn up.  Bug reports are welcome, as usual.

A similar release 4.2.1 will soon be available for MUSIC.  Also, watch
for release 4.2.1 for CICS.

[Ed. - Thanks, John!  The new files are in in the B area of Kermit
distribution: iktker.ann (this message), iktker.bwr (the beware file), and
iktker.upd (the updates to be applied to the program to produce the new
version; see iktker.ins for instructions.]

------------------------------

Date: Thu, 1 Nov 90 14:18:55 EST
>From: Mike Freeman <[e-mail]>
Subject: Announcing CP/M Kermit Version 4.10 for Testing
Keywords: CP/M-80 Kermit

Just to prove that the CP/M world still exists, here is CP/M Kermit-80
Version 4.10.

New features include:

o SET COLLISION {BACKUP/DISCARD/RENAME/REPLACE}
o SET INCOMPLETE-FILES {DISCARD/KEEP}
o Many REMOTE commands, including some REMOTE SET commands
o RENAME command to rename CP/M files from within Kermit-80
o SET RECEIVE/SEND PACKET-LENGTH nn (nn <= 94)
o Many bug fixes
o Kermit-80 Version 4.10 now supports the Microbee family of
   computers (56K, 64K, 128K and 256K) manufactured by
   Microbee Systems, Ltd, of Australia.

Technical changes:

o An "I" packet is now tried before the request for files is sent
  in a GET command
o The overlay address is now 7000H
o The overlay (CPXLNK.ASM) has an added INCFLG variable to handle
  INCOMPLETE-FILES status

Syntax hints:

In REMOTE commands such as REMOTE COPY, REMOTE MESSAGE, REMOTE RENAME,
REMOTE WHO etc., where two arguments are required, the syntax is as for Vax
VMS Kermit, i.e.,

  REMOTE <command> <argument 1>
  Prompt:  <argument 2>

For example:

  REMOTE COPY <old-file>
  New file: <new-file>

The REMOTE LOGIN command has three arguments, of which the last two are
prompted for an entered on new lines.  Arguments are optional.

In commands such as REMOTE SET FILE BLOCK-SIZE which take a numeric
argument, Kermit-80 does not check the argument for validity.  Whatever is
typed is what the host sees.

The FCOPY command has been renamed COPY.

The syntax for the RENAME command is as for the COPY command, that is:
RENAME <old-filespec> <new-filespec>

More rigorous checking for wildcards is now done by both of these
commands.

SET BAUD-RATE is now SET SPEED.

The CONNECT command no longer can be abbreviated to "C"; the minimum
acceptable abbreviation is now "CON".

The option SET FILE DEFAULT has ben re-enabled.  Use a TAKE-file to set the
initial file-mode to ASCII or BINARY.

Building Kermit-80 ver. 4.10:

Kermit-80 ver. 4.10 is built using the same procedure as for version 4.09.

Many thanks to those who have contributed bug fixes, and, in particular,
to Mr. Russell Lang of Monash University, Australia, for contributing
a bug-fix and the family file for the Microbee systems.

[Ed. - Many thanks, Mike!  We hauled out our original Kermit Superbrain from
nine years ago, downloaded the system-independent hex file and the
"Brain"-dependent hex file, combined them with MLOAD, and the new version
worked perfectly.  But because CP/M Kermit runs on so many different
computers, we are installing it in the Kermit test area for now.  If you
encounter any problems with it, send e-mail to Mike at the address above.
After a decent testing interval, it will replace version 4.09 in the main
distribution area.  The Kermit test area is kermit/test on watsun, and T: on
CUVMA.  All CP/M-80 Kermit filenames start with the letters CP.  There are
more than a hundred files, so first get the file CPAAAA.HLP, which lists and
describes the files, read it, and then request the files you need.  An
updated version of MLOAD is also included as MLOAD.*.  An updated manual
will be available shortly.  Thanks again to Mike for all the work that went
into this release.]

------------------------------

Date: Fri, 19 Oct 90 18:10:57 PDT
>From: [e-mail] (William Hall)
Subject: New Test Release of Microsoft Windows Kermit
Keywords: Microsoft Windows Kermit

WIN100.EXE, a version of Kermit with VT100 and VT52 terminal emulation for
Microsoft Windows, is available on an experimental basis from the Kermit
distribution center.  Programs are available for both Windows 2.x and Windows
3.0 and replace the previously released WN100K.EXE.  Except for bug fixes, the
2.x version will not receive further enhancements.  The 3.0 version will
undergo several improvements over the next several months as time permits
including the release of all sources when legally possible.  Plans include
basic server support as well as extensions of the emulation to include VT220
and H19 as well as 8 bit character sets.  4010/4014 support and Telapi support
are also planned for the future.  Accompanying the programs is a font file
suitable for use on VGA displays which allow for proper display of bold
characters and DEC special graphics.

[Ed. - Many, thanks, Bill!  The new files are in ~kermit/test/win*.* on
watsun for Internet anonymous ftp access, and T:WIN*.* on CUVMA for BITNET
KERMSRV access.]

------------------------------

Date: Thu Nov 15 11:47:07 1990
>From: Christine M Gianone <[e-mail]>
Subject: Another New Prerelease of MS-DOS Kermit 3.02
Keywords: MS-DOS Kermit 3.02

>From Joe Doupnik's change log:

71. Expand the command line internal variable value substitution syntax
    \v(variable) to encompass internal variables:
        ARGC        PATH
        COUNT        TIME
        DATE        VERSION
        ERRORLEVEL
    Allow "?" help and <ESC> word completion on these items as well.

    Now scripts can include additional controls such as
        IF equal \v(date) 09-16-1990 echo it's \v(time) on Sunday
    Notice that \v(variable) yields a text string and cannot be combined
    with the strictly numerical IF test conditions of <, =, and >. For
    numerical tests employ the form
        IF > time 12:00 echo the time is past noon

    Some basic concepts are as follows.
    - Intrinsic (built-in) commands do not affect the \%0..\%9 variables,
      but user created commands (Macros) do create a private version of
      \%0..\%9.

    - To be a command the keyword, intrinsic or macro, must be the first word
      at the Kermit prompt. Commas in Macros start a fresh command line even
      though the Kermit prompt is usually not displayed on the screen while
      within a macro.

      Thus in the definition below of macro test
        DEFINE test echo \%0 \%1,mywords,echo test mywords \%1
      there are three commands (they start at the effective Kermit prompt):
        echo TEST <first argument><carriage return>
    mywords  becomes  whatever macro mywords is defined as<carriage ret>
    echo test mywords <first argument to test><carriage return>
            The argument to this last echo cmd is the simple text
            "test mywords" plus the first argument to test.
            In the text neither test nor mywords is replaced by
            its definition, and echo is an intrinsic command.

    - String substitution variables, \%<character> and \v(variable), are
      always immediately replaced by their definition string no matter where
      they are used outside of a DEFINE command.

    - ASSIGN is similar to DEFINE except that whereas DEFINE uses the
      definition text as a literal string ASSIGN first evaluates the text,
      i.e. it replaces \%<character> and \v(variable) items with their string,
      at the time the ASSIGN statement is executed.

72. More work on Tektronix BYPASS mode. By popular demand, ensure that BYPASS
    mode stays on (discards incoming characters) until a control character
    arrives from the host, or the screen is cleared, or the emulator is reset.
    Previous test editions of version 3.02 waited for a local control code to
    be generated. Files affected are msgibm.asm and msyibm.asm.

73. Correct tiny bug introduced by item 70. File mssker.asm
    And plug a security hole of two Control-C's in a row from a remote client
    causing server mode to exit if FIN/BYE is disabled. Files msscom.asm and
    mssser.asm.

74. Modify the action of the BYE/FINISH/LOGOUT command from an MS-DOS Kermit
    client. Previously these would complete successfully whether or not the
    server host sent an Error packet. It has been discovered that C Kermit
    version 5A sends an Error packet response if BYE has been Disabled. To
    keep things rational MS-DOS Kermit now stays active if an Error packet
    is received for these commands. Script writers may want to issue an
    extra command to EXIT Kermit regardless. An MS-DOS Kermit server returns
    an ACK with a message that the command is disabled, it logs out the user,
    it hangs up the connection, and it returns to being a server waiting for
    another customer, all if BYE is disabled.

75. Adjust the FILE TRANSFER CHARACTER-SET tables for LATIN5/Cyrillic to
    use ISO 8859-5 (Latin/Cyrillic) on the wire and presume Code Page 866
    (Alternate Cyrillic) in the machine. Modify the character set name
    from LATIN5 to CYRILLIC. Cyrillic uses an ISO 2022 announcer of ESC L.
    File mssfil.asm is changed.

76. Add to list of \v(variable) items the variables PLATFORM and SYSTEM.
    Platform returns the machine name, such as IBM-PC, and System returns
    the operating system name, MS-DOS, for MS-DOS Kermit. This is to match
    C Kermit 5A.
    In addition, add the objects PLATFORM and SYSTEM to the WRITE command;
    they may be followed by optional text:
        WRITE SESSION Platform and this is a good machine.
    FIles changed are msscmd.asm and msster.asm

77. Correct a sneaky bug regarding testing for DESQview which led to over
    writing of a few Help messages in the main body of MS-DOS Kermit/IBM-PC.
    File msyibm.asm.

78. Add numerical variable KEYBOARD to IF statements, \v(variable), and
    WRITE statements so that Take files can be tailored to fit either 88
    (so-called Old AT) or 101 (so-called Enhanced) keyboards. The value is
    either 88 (default) or 101 or 250. The determination of 88 or 101 is made
    at Kermit startup. The IBM PC version also permits the value 250 if the
    LK250 keyboard is selected (SET KEY LK250) and external driver is present
    for the Digital keyboard. Files affected are msuibm, msscmd, mssscp,
    and msster.

79. Enhancements to SET PORT EBIOS for IBM LANACS.
    - Let the baud rate be set for BIOSn and EBIOS ports for IBM-PC version.
    Initially they will show as "unknown" until set by the user. In addition
    to the speed 8 data bits and no parity are set. For EBIOS, the port
    being adjusted is really that on the asynchronous server; the local PC
    uses NetBios and EBIOS to simulate that remote port across the network.

    - Add new optional final command argument of the EBIOS server port name
        SET PORT EBIOS <local coms port, 1..4> <server port name>
    such as  SET PORT EBIOS 1 modem-2400

    If the server port name is omitted then the port name is taken from the
    EBIOS table on the client machine, such as resuming an old connection.
    This option removes the necessity of using the REDIRECT.EXE program, part
    of the LANACS package, because Kermit does a simple redirection of the
    selected local port to the named host port (and the name is persumed to
    be a unique one rather than a group name). If another type of connection
    is desired then (a) omit the sever port name in the SET PORT EBIOS cmd
    and (b) perform the redirection with REDIRECT.EXE. Each instance of SET
    PORT EBIOS <local comms port> uses its own port information of speed,
    parity, flow control, handshake, and local-echo.  msxibm.asm, msster.asm

80. On the formatted file transfer screen add " of n" to the Window slots
    line, where n is the maximum number negotiated between Kermits. msssho.asm

81. Correct bug in processing CSI ? 256 n leading to crashes. Thanks to
    Risto Laitinen. File msgibm.asm

82. Modify the strategy for DEC Autoprint, CSI ? 5 (and 4) i  from printing
    each character as it arrives to printing display lines only as the cursor
    is moved off it by an autowrap or LF, FF, or VT (otherwise do not print
    the line). Thanks to Michael Wolter for pointing out the problem. mszibm

83. Also, preserve the state of VTxxx terminal emulator printing around
    processing of DEC Set Conformance Level commands, e.g. CSI 63; 1 " p.
    Plus, correct a small bug resetting the cursor column to zero when writing
    to a host owned status line. Tnx to Michael Wolter and John E. Davis.

84. 12 Oct, two small fixes - ensure REM FILE TYPE remembers the command while
    being an MS-DOS Kermit server (mssser.asm), and cure a small \v(variable)
    bug in file msscmd.asm.

85. Correct a problem of not sending an XON following a failed RUN or PUSH
    command. An XOFF sent automatically as Kermit shells to DOS. The XOFF/XON
    pair is used to suspend host output while DOS is in charge. mssker.asm

86. 25 Oct. Fix some parser problems (Control-C handling, ASK command line
    editing) introduced with internal changes made over the past three weeks.
    Files changed are msscmd.asm and mssset.asm.

87. Modify the action of pressing the Enter key while a script INPUT command
    is in progress. Previously it meant "assume a match has occurred" so the
    script could progress. Now it means "assume a timeout has occurred" and
    report a failure status. People seem to prefer the latter approach. mssscp

88. 2 Nov. Add internal support of Microsoft compatible mouse for Tektronix
    GIN crosshairs. Both the regular cursor keys and the mouse can function
    together. Pressing either mouse button is the same as pressing the Enter
    key. The mouse driver must be active for Kermit to use it (include line
    DEVICE=path\MOUSE.SYS in file CONFIG.SYS for permanent residency, or give
    the DOS command MOUSE ON for temporary residency of the MS mouse driver).
    This addition bypasses any active mouse menu programs such as DEFAULT.COM
    during Tektronix emulation but they continue to run otherwise. MS-DOS
    Kermit uses standard Microsoft Interrupt 33h mouse calls. msgibm.asm

89. Extend automatic detection of unexpected parity in packets to include the
    first four protocol characters rather than the first two. In addition,
    perform the test only on the first good received packet of a file transfer
    group. The test is effective only if the local parity setting is NONE,
    and if another setting is detected from the host then the local setting
    is changed permanently. Files msscom, mssrcv, msssen, msssser.asm.

90. Correct some subtlities in command line parsing when a local prompt is
    offered, such as in GETting files with an overriding local name. Files
    msscmd.asm and mssker.asm.

91. Add a text cursor symbol, an 8x8 dot hollow box, in Tektronix graphics
    terminal emulation mode so we can see where we are. The box is removed
    before generating a TIFF format screen dump (default keys Control-End) and
    it is restored afterward. The box is XOR'd with the picture so that no
    information is lost. File msgibm.asm.

92. Add command SET TERMINAL GRAPHICS CURSOR {ON, OFF}, default is ON. This
    permits one to turn off the text cursor while in graphics (Tek) mode.
    The cursor is suppressed around almost all drawing and Sixel commands.

    Add command SET TERMINAL GRAPHICS COLOR <color values> which is analogous
    to the text mode command SET TERM COLOR and uses the same color values.
    Two technical notes: the background color cannot be given bold attributes,
    and the colors are stored in DEC VT340 color palette slots 0 (background)
    and 7 (foreground).

    Be wary of two side effects of colored graphics screens: most Print Screen
    programs will put a black dot on the printer paper if a dot is illuminated
    at all, and Sixel graphics normally add (OR) to the exiting dot coloring
    and hence the coloring may not be what was intended. Resetting the
    emulator restores the colors specified by these SET TERMINAL commands.
    Files msyibm.asm and msgibm.asm

93. To the mouse support add setting of the span of cursor motions to be the
    current screen dimensions, for mouse drivers which may not do this
    automatically. An internal item, no user commands. Thanks to Leland Bruns
    of Intel.

More changes are expected.

------------------------------

Date: Fri, 2 Nov 90 22:55:21 EST
>From: Robert Weiner <rweiner>
Subject: Rainbow Kermit Updated Too (for testing)
Keywords: Rainbow Kermit, DEC Rainbow, MS-DOS

The current version of DEC Rainbow 100 MS-DOS Kermit is ready for testing
and is available on watsun.cc.columbia.edu in the following files:

    ~kermit/test/mstrb1.boo        BOO Encoded MS-DOS Executable
    ~kermit/bin/mstrb1.exe        MS-DOS Executable

This version was built using the current generic MS-DOS Kermit modules which
exist on watsun.cc.columbia.edu in the ~kermit/test directory, and therefore
contains many of the bugfixes and enhancements which
have been mentioned for the IBM-PC version.

[Ed. - A version of MS-DOS Kermit 3.02 for the Heath/Zenith 100 is expected
soon too.  Watch Info-Kermit for an announcement.]

------------------------------

Date: Wed Nov  7 17:01:54 1990
>From: Christine M Gianone
Subject: New Kermit for Gould/SEL 32/77 MPX
Keywords: Gould/SEL Kermit, MPX Kermit

This is to announce a Kermit server program for the Gould/SEL 32/77 computer
with the MPX 1.5E operating system, from Barry M. Wilson, Queensland
Electricity Commision, Belmont State Control Centre, 311 Wecker Road,
Mansfield, Queensland 4122, Australia, phone [phone].

There is no user interface, it is a server only.  It supports long packets,
up to 768 bytes in and 1000 bytes out.  It handles run-length compression
encoding in incoming packets, but does not compress when sending.  There is no
further documentation.

The source files and build procedure are collected together into a single
file, kermit/d/gm3ker.jar (a "join archive") on watsun for anonymous FTP
(Internet) and GM3KER.JAR from KERMSRV at CUVMA (BITNET).

Thanks to Barry for doing the work and sending it in!

------------------------------

Date: Sun, 14 Oct 90 17:20:36 -0700
>From: [e-mail] (Merton Campbell Crockett)
Subject: MS-Kermit 3.02 Argument Handling, Keyboard Mapping
Keywords: MS-DOS Kermit 3.02

When using version 3.02 of MS-Kermit, I get an error, "?word xxxxx not usable
here.", when entering the command

        dial xxxxx

however, although an error is reported, the HAYES.TAK command file is invoked
and attempts to dial "ATDTxxxxx"--not exactly the intended operation.

The DIAL macro is the one defined in Christine Gianone's MSKERMIT.INI file.
The LOOKUP macro was modified as shown below.  The macros worked under version
3.00 and 3.01.

[Ed. - Right you are.  There were many complaints about the way Kermit's macro
arguments were handled -- they were not saved and restored across calls like
real function arguments.  Now they are.  Unfortunately this breaks the nice
LOOKUP and DIAL macros.  They must be slightly recoded to use a global
variable.  Hopefully the benefits are worth it.  Something like this,
maybe:

def lookup -
  if eq \%1 compuserve  def \%9 7654321,-
  if eq \%1 telenet     def \%9 8765432,-
  if eq \%1 fishnet     def \%9 9876543,-
  if eq \%1 hairnet     def \%9 5551234,-
  if def \%9 assign \%n \%9

;   DIAL macro to dial a number.  The argument can be either a telephone
;   number or a string defined in a lookup(x) macro.  The macro requires
;   HAYES.TAK to be in the current directory or in a defined DOS PATH.

def dial if = argc 2 assign \%n \%1,-
  if < argc 2 if not def \%n fatal {Dial what?},-
  if > argc 2 fatal {No spaces please.},-
  lookup \%n,-
  assign \%1 \%n,-
  take hayes.tak

I connect to several different office automation systems based on Unix
platforms which presume that the "terminal" is a DEC VT100 class terminal and
make heavy use of the VT100 keypad for functions and subfunctions.  I also use
EDT on IAS and VMS platforms.  The following excerpt from my MSKERMIT.INI
command file may be of interest to others with 101 key keyboards who find
MS-DOS Kermit standard mappings hard to remember or would just prefer to have
the keypad in a manner more similar to a VT100, VT200, or VT300 class
terminal.

[Ed. - Many thanks, your contribution has been added to MSIVT3.INI, our
collection VT300 keyboard mappings...]

------------------------------

Date: Wed, 1990 Oct 10   22:35 EDT
>From: "John F. Chandler"   <[e-mail]>
Subject: Re: Kermit REMOTE SET Command
Keywords: REMOTE SET, Kermit Commands, Remote Commands

> This is actually a tricky situation.  The idea was that TRANSPARENT should
> be the default, for compatibility with the hundreds of Kermit programs that
> do not support the character-set extension.
>
Let's not forget that it would be the default only for systems whose native
character set is ASCII.  Its meaning, in fact, is rather nebulous, since it
is very similar to FILE TYPE BINARY for ASCII systems.  What it means, in
short, is "use the FILE CHARACTER-SET for the TRANSFER (or vice versa)."
However, a TRANSPARENT sender cannot presume to tell the receiver what
character set to use, so the situation is, indeed, tricky.  The natural
Encoding attribute for TRANSPARENT transfers is "*!A" on all ASCII systems (or
perhaps no attribute at all), but there is *no* natural value on non-ASCII
(e.g., EBCDIC) systems.

> Adding a new designator to denote TRANSPARENT might confuse Kermits that
> don't understand it, including Kermits that support the character-set
> extension, if that designator were to arrive in an Attribute packet.
>
You bet.

> So far, it has been an implementation decision about whether character-set
> changes based on incoming attribute packets are "sticky".  If they are, this
> presents the problem that there is no way for a client to tell a server to
> switch from translation to transparent.
>
.. except, of course, REMOTE KERMIT SET TRANSF CHAR TRANSP.

> So it would appear that a decent compromise would be to invent a new
> designator, say K0, for TRANSPARENT, and to support it in REMOTE SET
> TRANSFER CHARACTER-SET commands, but, at least for a time, not use it in
> Attribute packets.  Opinions?]
>
Yes.  I would say, though, that K0 should never be allowed in A-packets.
                                           John

------------------------------

Date: 11 Oct 90 20:17:40 GMT
>From: [e-mail]
Subject: Kermit for STRATUS/VOS?
Keywords: Stratus, VOS

Looking for a version of KERMIT that runs on STRATUS and supports full set of
KERMIT commands.  Currently have a version of KERMIT that only knows how to
receive ASCII files.  Would like to have a version that supports both sending
and the receiving and can act as both the initiating and terminating end of a
KERMIT session.  Also, would like a version that supports the transportation
of binary files.

A portable version would be acceptable.

[Ed. - Good luck!  In fact, you seem to have more than we do -- our listings
don't show any entries for Stratus at all.  Anybody out there know anything
or working on anything for the Stratus?  We have a similar request from
Bill Oliver, MD, Department of Hospital Labs, UNC Hospitals,
[e-mail].]

------------------------------

Date: 30 Oct 90 18:15:13 GMT
>From: [e-mail] (Gordon Maskew Fair, III)
Subject: Kermit vs Hypercard?
Keywords: Hypercard Kermit

Has there been a stack created that will allow one to use all the
kermit, and/or xmodem, and/or ymodem commands?  If there is anything
somewhat like this I would greatly appreciate it.

Thanks in advance,

Gordon

------------------------------

End of Info-Kermit Digest
*************************
From fdc  Tue Jan  8 10:45:04 1991
Return-Path: <fdc>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA09528; Fri, 4 Jan 91 21:52:26 EST
Date: Fri, 4 Jan 91 21:52:25 EST
From: Frank da Cruz <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V13 #1
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest          Fri, 4 Jan 1991        Volume 13 : Number 1

Today's Topics:
        New Release of Apple II Kermit
        New Release of VAX/VMS Kermit-32
        Another Prerelease of MS-DOS Kermit 3.02 Ready for Testing
        New Update of MS-DOS Kermit 3.02 for the Victor 9000
        New Update of MS-DOS Kermit 3.02 for the DEC Rainbow
        Updated Auxilliary Files for Kermit-370
        CP/M Kermit version 4.10 Enhancements
        TOPS-10 Kermit Files Repaired

Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.1), IP host number 128.59.39.2.  Login as user anonymous
(note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired
files.  The Kermit files are in directories kermit/a, kermit/b, kermit/c,
kermit/d, and kermit/e.  Test versions are in kermit/test.  Binaries are in
kermit/bin (use ftp in binary mode).  You can also get Kermit files over the
BITNET/EARN network; to get started send a message with text HELP to KERMSRV,
the Kermit file server, at host CUVMA.  For detailed instructions, read the
file kermit/a/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 Dec  5 09:16:51 1990
>From: Christine M Gianone <[e-mail]>
Subject: New Release of Apple II Kermit
Keywords: Apple II Kermit 3.87

>From Ted Medin, <[e-mail]>.  Here is his description of the
new release:

  1. Decimal numbers allowed in lots of places.
  2. Screen restore on "connect" for //e or better.
  3. Kermit file attributes are handled.
  4. Percent of file transferred where possible (file attributes required).
  5. Lots of bug fixes (will we ever get the vt100 right :-)
  6. Kermit protocol bug fixes.
  7. Escape character "\" can be used in file names for file xfers.
  8. Show volumes - (ProDos only) shows the prefixes of the online volumes.
  9. Escape V - When connected will toggle cursor-keys-vt100.
 10. Some vt102 printer codes are handled - don't expect much.
 11. New driver for the Ace dual card.  Thanks to Andy Tefft.

Now for a list of credits for those who helped.  I'm sure I missed someone
so please accept my appoligies: Doug Ashbrook, Todd Bakal, Ralph Carpenter,
Grant Delaney, Les Ferch, Paul Hirose, Steve Kunz, Ted Lee, Murphy Sewell,
Andy Tefft, Dick Wotiz.  (End Quote)

The new files are in kermit/a/app*.* on watsun.cc.columbia.edu (Internet)
and they are available from KERMSRV at CUVMA (BITNET/EARN).

------------------------------

Date: Wed Dec  5 09:16:51 1990
>From: Christine M Gianone <[e-mail]>
Subject: New Release of VAX/VMS Kermit-32
Keywords: VAX/VMS Kermit

>From Jonathan Welch, a minor new release of Kermit-32 for VAX/VMS, version
3.3.128.  The new release replaces version 3.3.126, and contains two
corrections: a bug when transferring files containing print carriage control,
and problems operating in non-interactive (e.g. batch) mode.  The files are
in the B area, kermit/b/vms*.* on watsun, VMS*.* on CUVMA KERMSRV.  The file
vmsmit.hex is KERMIT.EXE encoded in hex format, which you can convert back to
EXE format using the VMSDEH program, also supplied in the same area.  See the
file VMSAAA.HLP for instructions.  Thanks to Jonathan for keeping Kermit-32
alive!

------------------------------

Date: Tue Jan  1 20:37:42 1991
>From: Christine M Gianone <[e-mail]>
Subject: Another Prerelease of MS-DOS Kermit 3.02 Ready for Testing
Keywords: MS-DOS Kermit 3.02, IBM PC

Here are the changes since the last announcement, from Joe Doupnik's
MSR302.UPD file.  The new version is ready for testing in
kermit/test/mstibm.boo in BOO file format, convertible to executable .EXE file
using any of the kermit/b/msbpct.* programs, or as a directly executable
binary file in kermit/bin/mstibm.exe.  As usual, many thanks to Joe for his
constant and devoted attention to this program.

94. Make several internal changes to the code for SET PORT TES, with no
    changes to user level commands. File msxibm.asm.

95. 26 Nov. Fix two problems introduced this past week: unwanted ghost cursor
    boxes in graphics emulation mode if character writing is opaque and the
    display is CGA or Hercules, and loss of \Knethold for TES. Files changed
    are msgibm.asm and msxibm.asm.

96. Another graphics terminal emulation fix for the case of using opaque
    character writing with monochrome displays when the characters do not
    start on a multiple of 8 horizontal PC dots. File msgibm.asm

97. Add a problem solver from Frank da Cruz: if Kermit times out waiting for
    a packet character to arrive then send an XON to the host, if such flow
    control is active, to free a host which might have received an XOFF as
    a stray line noise character. File msscom.asm

98. Add more flexibility to the REMOTE LOGIN <username password account>
    command so that it can be stated on one line, particularly for Take files,
    and yet retain the ability to use embedded spaces in all three fields. To
    use embedded spaces surround the quantity with curly braces, {..}. An
    example is a username of "my name" and a password of "no show":
        REM LOGIN {my name}{no show}
    or equivalently
        REM LOGIN {my name}   {no show}
    The account name is omitted in this example. Kermit will prompt for the
    items only if nothing is specified after the word LOGIN. File mssser.asm,
    done on 6 Dec.

99. Improve performance of the Novell TELAPI communications path. Command
    TELAPI between single Character and Line Mode depending on what Kermit
    sends, because otherwise TELAPI will send Kermit packets as a long burst
    of TCP/IP Telnet packets each holding one data character. This boosted the
    Kermit to Kermit file sending speed from 240 to 1990 file characters per
    second in one test situation (an 8MHz AT to a MicroVAX II using Kermit-32
    version 3.3.126 and 1000 byte packets).

    However, because of the way TELAPI Line Mode works this gain is obtained
    only if the end-of-packet character on packets sent by MS-DOS Kermit is
    the default 13 (Carriage Return); other values will result in TELAPI using
    its method of a single character per Telnet packet. That is, when TELAPI
    is in Line Mode a Carriage Return is required to send its buffer.

    Second, side step a particularly slow TELAPI operation when receiving
    characters. This boosted reception from 240 to 1720 file characters/sec
    in a similar test. All changes are in file msxibm.asm. Done on 8 Dec 1990.

100. Add a finishing touch to SET PORT TELAPI to handle the case of starting
     a NEW or RESUMING an existing connection when the command is given.

101. By request, add additional Tek submode entry and exit commands of
        ESC 1   enter Tek submode from text emulator and clear Tek screen;
                ignored if Tek mode is disabled.
        ESC 2   exit Tek submode from text emulator;
                ignored if acting as a full Tek terminal (SET TERM TEK).
     Files changed are msgibm.asm and mszibm.asm

102. Make a couple small changes to files msxibm.asm and mssset.asm to ensure
     that changes to flow control take effect immediately rather than waiting
     for the serial port to be closed and reopened manually (by changing ports
     and changing back again).

103. Two small changes. Ensure received packet retry counter does not increase
     when any legally framed packet arrives, rather than considering only those
     in the current window. File mssrcv.asm.
     Add tiny time windows when the serial port interrupt routine can permit
     other interrupts to be serviced while it reads bytes from the FIFO of a
     16550A UART chip. Previously interrupts were turned off during the entire
     read process. Improvments will be noticed only on machines already
     running in a nearly overloaded situation. This feature may be removed if
     any bad reports arrive. File msxibm.asm.

104. Add screen-clear command CLS to clear the screen at Kermit command
     level, especially for Take files and Macros (Control-L does it by hand).
     File mssker.asm, done 17 Dec 1990.

105. Add correction to file msxibm.asm to prevent sending an XOFF if the
     communications port is inactive. Affects situations such as starting
     Kermit and saying DIR before doing anything else.

106. Remove item 97. At least one IBM mainframe Kermit objects to an XON when
     reading packets (however slowly it may respond). File msscom.asm, 23 Dec.

107. Add support for 132x25 screens with the new IBM XGA display adapter. Tnx
     to Bert Tyler at NIH. File msyibm.asm

108. Small correction in file msuibm.asm, IBM PC keyboard reader, to work
     around a PS/2 keyboard Bios problem with the keypad "5" key.

109. Ensure that during terminal emulation out going bytes of values greater
     than 9fh are not converted into 7-bit control form (ESC letter) under any
     circumstance. Only bytes in the C1 control code area may be converted.
     File msyibm.asm

110. Correct small error in identifying the transfer character set given in
     received attributes packets. Also, if an arriving file indicates a
     Transfer Character Set of CYRILLIC then force use of CP866 for that
     particular file and revert back to normal afterward. File mssrcv.asm
     And if the user manually selects CP866 then retain that setting around
     pushing to DOS. File msxibm.asm

111. During file transfers pressing either Control-Q or just Q sends an XON
     code to the other side, regardless of our flow control setting. This
     is to manually free a host blocked by a stray XOFF. File msscom.asm

Joe has also written a capsule summary of the changes from version 3.01 to
3.02.  It is available in the file kermit/test/msr302.doc, about 36K in
length.  Thanks again, Joe!

------------------------------

Date: Mon, 17 Dec 90 23:53:57 EST
>From: "Joe R. Doupnik" <[e-mail]>
Subject: New Update of MS-DOS Kermit 3.02 for the Victor 9000
Keywords: MS-DOS Kermit 3.02, Victor 9000 Kermit

I completed a quick upgrade of the Victor 9000 (Sirius 1) Kermit material
from version 2.29 to 3.02 and placed the files on ~kermit/test.  I lack a
Victor upon which to test these changes so we need to hear from volunteers.
File mstv90.boo is accompanied by the three main source files msuv90.asm,
msxv90.asm and msyv90.asm.  The startup banner carries the date of 17 Dec
1990.

Joe D.

[Ed. - Thanks, Joe.  Reports from Victor 9000 users would be much
appreciated.]

------------------------------

Date: Sat, 29 Dec 90 03:05:16 EST
>From: Robert Weiner <[e-mail]>
Subject: New Update of MS-DOS Kermit 3.02 for the DEC Rainbow
Keywords: MS-DOS Kermit 3.02, Rainbow

Here is the latest version of DEC Rainbow Test Kermit built from current
MS-DOS Kermit sources in ~kermit/test.  Nothing Rainbow specific new here.
-Rob

[Ed. - Thanks, Rob!  Readers can find this contribution in
kermit/test/mstrb1.boo (boo file) and kermit/bin/mstrb1.exe (binary).]

------------------------------

Date: Mon, 1990 Dec 17   14:56 EST
>From: "John F. Chandler" <[e-mail]>
Subject: Updated Auxilliary Files for Kermit-370
Keywords: Kermit-370, IBM Mainframe, CMS Kermit

Two files have recently been updated.  One is IK0VER.FOR, a comparison
program which generates a difference file in the form of CMS-style updates:
there was a sequencing problem in the output difference file whenever a
matching stretch of exactly one card appeared in the midst of differences.
IK0VER is of interest primarily to programmers on non-CMS systems who wish
to send code improvements in a compressed and uniform fashion.  The other
file is IKCACT.ASM, the sample accounting exit routine for Kermit-CMS.
Nothing has been changed in the way it works, but some new options have been
added for recording the accounting information.  Also, a note of caution:
the punch option, as a quick examination of the code would indicate, does
NOT work in an XA-mode virtual machine.  Andre Pirard has signaled an
intention to make an XA-mode version some day, but not right away.

John

[Ed. - Thanks, John!  John has also sent in a set of Kermit-370 documentation
files that contain "Fortran" carriage control in column 1, and that are fully
paginated, with an index and a table of contents that make sense.  These are
available in the "B" area as IK*.LPT.]

------------------------------

Date: Fri, 23 Nov 90 18:28:30 EST
>From: Mike Freeman <[e-mail]>
Subject: CP/M Kermit version 4.10 Enhancements
Keywords: CP/M Kermit

As a result of an E-Mail discussion with Dr. Russell Lang at Monash
University in Australia, I have made the following enhancement to Kermit-80
Version 4.10: when receiving or getting files, if a "disk full" condition is
found, rather than aborting with no other action, the enhanced Kermit now
deletes the file causing the "disk full" condition, complains to the user
(which it always did) and sends an "E" packet to the other side to tell it
to stop sending.  These changes are in cpsker.asm, cpspk1.asm, cpsker.hex in
my area, /uw/guests/freeman/.  Except for bug fixes as a result of the test
release, I believe this will be the last work on Kermit-80 ver. 4.10.
Future enhancements will go into Kermit-80 ver. 4.11.

After checking with Joe Doupnik, I've modified CP/M Kermit to take account
of the SET INCOMPLETE-FILES setting when receiving files and a disk-full
error occurs. If SET INCOMPLETE KEEP is in effect, the incomplete file will
be closed and kept, else it will be deleted.  The user will still know that
the transmission was unsuccessful as the "Failed" message will appear even
with SET TERMINAL QUIET.  The "E" packet will still be sent to the remote
Kermit. This is the behavior before my last change except that under all
circumstances, an incomplete file is closed (errors ignored), so that, if
SET INCOMPLETE-FILES KEEP is in effect, an attempt wil be made to output the
last buffer.

-- Mike Freeman K7UIJ --

[Ed. - Thanks, Mike!  CP/M Kermit users should continue to check the new
files in kermit/test/cp*.* for updates.  Reports and contributions continue
to arrive from far and wide, showing that CP/M is still alive.  When they
have settled down, version 4.10 will replace 4.09 in the standard Kermit
distribution.]

------------------------------

Date: Wed, 28 Nov 90 17:00:55 EST
>From: Mike Freeman <[e-mail]>
Subject: TOPS-10 Kermit Files Repaired
Keywords: TOPS-10 Kermit, DECsystem-10 Kermit

In Kermit Digest V10#4, I noticed that Chuck Bacon noticed that <CR><LF>s
had been inserted in the Macro-10 sources for DECsystem-10 Kermit in such a
way that the Macro compilation was broken.  Did Mr. Bacon ever get a
corrected set of files to you?  It would appear not as a cursory perusal of
the ~kermit/b/ area shows you still have the chopped files (as I presume
they came from Mr. Norstedt).  In any case, I have sent you reformatted
files to compile/load/execute properly on the DECsystem-10.  The Bliss
modules are unaffected.  These sources also include my bug fixes also.
Everything works correctly as far as I can tell.  Ciao.
-- Mike K7UIJ --

[Ed. - Many thanks, Mike!  TOPS-10 lives too, eh?]

------------------------------

End of Info-Kermit Digest
*************************

From cmg  Tue Feb  5 16:41:17 1991
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA18565; Mon, 4 Feb 91 17:00:38 EST
Date: Mon, 4 Feb 91 17:00:37 EST
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V13 #2
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Mon, 4 Feb 1991        Volume 13 : Number 2

Today's Topics:

             Info-Kermit Digest Delivery
          Last Test Prerelease of MS-DOS Kermit 3.02
       DEC Rainbow Kermit 3.02 Prerelease Available for Testing
          MS-DOS Kermit 3.02 in ROM on the HP Portable Plus
         Using the MS-DOS Kermit Terminal Emulator with PICK
            CP/M Kermit for the Ampro Little Board

Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.1), IP host number 128.59.39.2.  Login as user anonymous
(note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired
files.  The Kermit files are in directories kermit/a, kermit/b, kermit/c,
kermit/d, and kermit/e.  Test versions are in kermit/test.  Binaries are in
kermit/bin (use ftp in binary mode).  You can also get Kermit files over the
BITNET/EARN network; to get started send a message with text HELP to KERMSRV,
the Kermit file server, at host CUVMA.  For detailed instructions, read the
file kermit/a/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, 4 Feb 1991 11:33:24 EST
>From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest Delivery
Keywords: Info-Kermit Digest

Many Info-Kermit subscribers report that they have not been receiving
Info-Kermit issues regularly.  Others report receiving two or more copies of
each one.  These problems seem to be caused by our local UNIX mail delivery
agent, sendmail, and our postmaster is investigating.  It is very likely that
the enormous number and geographic dispersion of Info-Kermit subscribers is
greater than sendmail ever expected to cope with.

I would encourage those of you who subscribe to Info-Kermit directly to move
your subscription to the I-KERMIT listserver on BITNET/EARN.  You can do this
even your mail address is not on a BITNET host.  To do this,
send e-mail to [e-mail] containing the following text:

  SUBSCRIBE I-KERMIT <name>

where <name> is your personal name, which can be in upper and lower case,
contain spaces, etc.  Once you receive a digest issue from I-KERMIT, you can
send e-mail to [e-mail] asking to have your direct
subscription cancelled because now you are receiving the digest through
LISTSERV.  If you ever want to cancel your I-KERMIT subscription, send e-mail
to [e-mail] containing the text:

  SIGNOFF I-KERMIT

Users of Unix systems that receive the regular newsgroup postings can also
read comp.protocols.kermit, which is simply a reposting of the Info-Kermit
Digest to the Unix netnews network (how or by whom I have never known).

Meanwhile, for those of you who are wondering which issues you might have
missed, Volume 12 (July through December, 1990) had 7 issues (1 through 7).
We're now in Volume 13 (Jan-Jun 1991), and this is the second issue.  Missing
issues can be retrieved from kermit/e/v12.* and v13.* on watsun via anonymous
ftp on the Internet, or V12 * and V13 * from KERMSRV at CUVMA on BITNET/EARN.

Sorry for the inconvenience, hope all is better soon.

------------------------------

Date: Mon, 4 Feb 1991 12:46:58 EST
>From: Christine M Gianone <[e-mail]>
Subject: Last Test Prerelease of MS-DOS Kermit 3.02
Keywords: MS-DOS Kermit 3.02

We're nearing the final release of the next version of MS-DOS Kermit, which up
till now we have been calling 3.02.  When it is finally released, the version
number will be 3.10 to reduce confusion about test versions versus real
versions.  As of this announcement, development of this release is frozen.
Please continue to send in bug reports and other comments, but suggestions for
new features will be kept for a post-3.10 release.  This message, extracted
from Joe Doupnik's MSR302.UPD file, lists the changes since the last posting,
in Info-Kermit V13 #1.  Subsequent messages describe work on some of the
non-IBM-PC versions.

The files are available in the Kermit Distribution "test" area, kermit/test
on watsun.cc.columbia.edu for anonymous FTP access on the Internet, and the
T: area of KERMSRV at CUVMA on BITNET.  They include:

 BOO File      Documentation     Systems Supported
  mstibm.boo    msr302.upd,.doc   IBM PC, PS/2, and compatibles
  mstgen.boo                      Generic MS-DOS
  mstgri.boo    mstgri.doc,.hlp   Grid Compass
  msthp1.boo    msthp1.doc,.hlp   Hewlett Packard 150
  msthpx.boo    msthpx.doc,.hlp   Hewlett Packard 110 and Portable Plus
  mstrb1.boo    mstrb1.doc        DEC Rainbow-100
  mstv90.boo                      Victor 9000 (Sirius 1)
  mstz10.boo    mstz10.doc        Heath/Zenith-100

The "boo" files are executable (.EXE) files encoded in "BOO" format, which
can be decoded back into .EXE format using any of the MSBPCT programs that
can be found in kermit/a/msbpct.* on watsun or MSBPCT * on KERMSRV.

The non-IBM versions listed above are approximately up to date with the IBM
version, but they lack many of the system-dependent features such as network
support, international character-set translation, and others, but they do
incorporate sliding windows, script language programming, and other
system-independent aspects of MS-DOS Kermit 3.02.  The non-IBM versions have
not been tested in the current edit, although they were tested at earlier
points in the 3.02 development cycle.

Thanks to Joe Doupnik for his skill, patience, endurance, generosity, etc,
in pulling this release together, and to other MS-DOS Kermit programming
volunteers including Robert Weiner, Gary Stebbins, John Nyenhuis, Terry
Kennedy, Bert Tyler, and many others, and to the hundreds or thousands of
testers.  Please report bugs or problems in this latest program edit to
Info-Kermit or directly to Joe at [e-mail] (Internet) or JRD@USU
(BITNET/EARN).  Joe's notes follow:

112. Add a feature suggested by John Klensin and Frank da Cruz, from C Kermit.
     New substitution variable notation \$(item)  means replace  \$(item)  by
     the string on the right hand side of the line starting as ITEM= in the
     DOS Environment. Any word may be used for ITEM. The replacement will be
     empty if either the string or the item is absent in the Environment.
     Leading and trailing spaces and tabs are removed from the string.
     Examples:
        Echo \$(path)
        shows the string which occurs after "PATH=" in the Environment, such
        as C:\;C:\WP;C:\DOS.

        IF eq \$(video) CGA echo Upgrade to VGA
        will show the string "Upgrade to VGA" if someone has provided the line
        VIDEO=CGA  in the Environment, perhaps by typing SET VIDEO=CGA or
        written there by a program.

        ASSIGN \%p \$(path)
        gives variable \%p the definition of the right hand side of PATH=.

     Semicolons occurring in \$(..) replacement strings will be treated as
     ordinary characters and will not start a comment. Comments starting
     with a semicolon are now restricted to ordinary Macros and Take files.

     Changes are in files mssker.asm and msscmd.asm.

113. Add variable \v(speed) to the list of substitution variables. \v(speed)
     is the ascii value of the communications line speed, in bits/second. It
     may be the word "unknown", without the quotes, if the value is not
     available, and it may contain non-numerical characters such as "." and
     "/" as in 45.5, 134.5, and 75/1200. Network connections will usually
     return "unknown". Changes are in file msscmd.asm.

114. Add variable "program" to the WRITE command and let it be variable
     \v(program). It is the string MS-DOS_KERMIT. Notice the underscore.
     Changes in file msster.asm.

115. Correct two keyboard related problems: reporting \v(keyboard) as 88 keys
     for such keyboards, and retaining the SET KEY {ON, OFF, LK250} state if
     an LK250 keyboard is requested (by this command) but is not present.
     Changes in file msuibm.asm.

116. Make small corrections to network-presence tests which previously
     said no-network if the net's interrupt pointed to segment 0f000h, system
     ROM. With the advent of memory mappers such as QEMM, 386MAX, etc holes
     in ROM can be filled by network drivers. The new test procedures allow
     networks to be detected in the ROM holes. File msxibm.asm.

117. Correct a problem with screen rollback storage when system memory is
     really short. An error in the code allowed storage (and a system crash)
     if the area were absent due to insufficient memory. File msyibm.asm.

118. Correct a presence signature of the STB/EM Plus board when changing
     between 80 and 132 columns, from Terry Kennedy. File msyibm.asm.

119. Correct a strange protocol problem. If receiving characters from an IBM
     mainframe host (or equiv) which requires use of a "handshake" character,
     typically Control-Q, and an end of packet character arrives prematurely
     then the bad partial packet is marked and delivered as a good one.
     Change in file msscom.asm.

120. Add code from Bert Tyler to manually set IBM XGA display boards in 80
     or 132 column mode because (apparently) the first boards lack support
     in their Bios. File msyibm.asm.

121. Add command SHOW VARIABLES [\v([name])] which displays the strings
     associated with variables of the form \v(variable-name). Leading "\v("
     and trailing ")" may be omitted. SHOW VARIABLE with no argument shows
     all variables; abbreviations are allowed here. Files changed are
     mssker.asm, msscmd.asm, msssho.asm.

122. Add 80/132 column support for the ATI VGA Wonder board, as a extended
     case of the EGA board. Tnx to Steve Wood. File msyibm.asm.

123. Permit abbreviations in \v(variable) phrases, such as \v(ver) rather
     than the full form of \v(version). File msscmd.asm

124. Correct a bug in the file receiver code which could reject a file if
     SET ATTRIBUTES LENGTH OFF were stated. File mssrcv.asm, done 16 Jan 91.

125. When the device holding the Session log (Connect mode) becomes full or
     reports an error during writing then put the error message on the status
     line, and suspend logging. Previously the error message was written on
     the main part of the screen where it could be overwritten or missed, and
     logging was reattempted every 128 bytes. Now logging is attempted again
     when reentering Connect mode. File msster.asm

126. Changes to \v(variable) area.
    a) Truncate the fractions of seconds field from \v(time).
        b) Add \v(ndate) which reports the date with all digits as YYYYMMDD
       for easier testing in scripts. \v(date) reports MM-DD-YYYY.
    c) Add \v(status) which reports the value of the Kermit status word;
       0 is success, any other numeric is a failure. Most Kermit commands
       clear this word result before execution. The current values are
       listed below; "user intervention" may be added to other values.

         Condition         Status    Comment
    success            0    initial value for most commands
    send failure        1    includes OUTPUT and TRANSMIT commands
    receive failure        2    includes INPUT command timeout
    remote cmd failure    4    REMOTE command failed for any reason
    Take file failure    8    Take file not found
    general failure           16    many causes
    user intervention     256    usually by typing Control-C

     These changes also apply to WRITE statements.

     Changes affect most mss*.asm files.

127. Add two tests to the script IF statement. These are lexical comparisons
     between two words. The curly brace {..} operators are not usable here.

    IF LLT    word1 word2 <command>
        executes <command> if word1 has    fewer characters (after
        removing leading spaces) than word2, or if at the first
        character where the words differ word1 has a character
        occurring earlier (less than) in the ascii collating sequence
        than that in word 2.

    IF LGT    word1 word2 <command>
        opposite of above, for word1 longer than word2 or the first
        differing character in word1 occurs later (greater than) that
        in word2 in the ascii collating sequence.

     Combining these with IF EQUAL and the NOT modifier yields all logical
     comparison conditions, as shown in the table below. Case sensitivity
     of the tests is controlled by SET INPUT CASE {IGNORE, OBSERVE}, with
     IGNORE being the default; when case is observed uppercase letters are
     "less than" lower case letters.

         Lexical Test        Kermit IF statement
    word1 =  word2        IF EQUAL word1 word2 ...
    word1 != word2        IF NOT EQUAL word1 word2 ...
    word1 <  word2        IF LLT word1 word2 ...
    word1 >  word2        IF LGT word1 word2 ...
    word1 => word2        IF NOT LLT word1 word2 ...
    word1 <= word2        IF NOT LGT word1 word2 ...

     Changes are in file mssscp.asm

128. Speedup response of the VT300 terminal emulator to VMS SET TERM/INQUIRE,
     and correct SET DEBUG SESSION to not invoke packet logging. Files
     mszibm.asm and msscom.asm, resp.

129. Send an XON when opening the "serial port", to free a host blocked by
     an XOFF from whatever cause. Correct REINPUT not timing out automatically
     if the history buffer is full and a string match is not found.
     Files msxibm.asm and mssscp.asm, resp. 25 Jan 1991

130. For macros invoked while in terminal emulation mode, such as TERMINALS,
     PRODUCT, user defined macros, etc., make variable \%0 be the macro name.
     Changes in file msyibm.asm.

131. Add special feature of calling Macro ON_EXIT when Kermit is exiting to
     DOS (but not when PUSHing/shelling to DOS). The user needs to define
     the Macro and it may contain any commands but normally ones wanted to
     put the system back into a standard form. For example

         DEFINE ON_EXIT run cols80.bat,echo Goodbye from MS-DOS Kermit.

     This Macro will be executed to switch the screen to 80 column mode
     when Kermit command EXIT or QUIT is given.
     Changes are in file mssker.asm.

132. Permit specification of the IRQ value of a UART serial port. The command
     SET COM3 <port address> <IRQ value>
     has the new optional second field to hold the IRQ (2 through 15 decimal).
     Example:
         SET COM3 \x03e8 \2
     The equivalent command for the DOS Environment would be
         C> SET KERMIT=com3 \x03e8 \2

     If the IRQ value is omitted then an IRQ of 4 or 3 will be used for
     testing. In all cases, a test is run to see if the serial port responds
     with this port address and IRQ value. If it does not then the port is
     tested again at the given address but using IRQ 4 or 3. If that fails
     the port is assigned an IRQ of 4 for COM1 and COM3 and 3 for COM2 and
     COM4; PS/2 machines are assigned 3 for COM2..4. XT's and other machines
     based on 8x88/8x86 cpu chips can not use an IRQ above 7.

     BEWARE!! It is very easy to interfere with other equipment in the
     computer, such as your harddisk, if the IRQ is used by other boards.
     The hard disk on XT's uses IRQ 5, and on AT's and above it typically
     uses IRQ 14. Parallel printers rarely use IRQs so by swithing off IRQ
     generation on the parallel port(s) one may recover IRQ 7 and 5 (AT's).
     Check carefully before experimenting. You use this facility only at your
     own risk.

     Changes are in file mssset.asm and msxibm.asm.

[Ed. - Notice -- this item was added only reluctantly by Joe, in response to
hundreds of requests for from those who have strange setups for their serial
ports -- nonstandard boards, unusual mixtures of serial devices, etc etc.
Joe's (and our) advice is to use Kermit's IRQ-setting option only as a last
resort.  It's much better and safer to try to rearrange your equipment
configuration to use a standard IRQ of 3 or 4 for all serial ports.
Nevertheless, it is important that those of you who have been requesting the
ability to specify your own IRQ test this feature and report back as quickly
as possible, good or bad.  Thanks!]

133. Change name of \v(path) and WRITE <log> PATH to be \v(directory) and
     WRITE <log> DIRECTORY, respectively, to avoid possible confusion with
     the PATH=  clause in the DOS Environment.
     Files msscmd.asm and msster.asm.

134. Small revisions to keep CTTY COMn happy. Shut down the serial port
     when at the Kermit prompt to let DOS style i/o have a chance at the
     serial communications line.
     File mssker.asm.

135. Reduce the WRITE command to syntax of WRITE <dest> text. Date and time
     etc are available via variables \v(date) and so on. Now the script
     input-buffer is displayed as part of the command SHOW SCRIPT.
     Files msssho.asm and msster.asm.

------------------------------

Date: Thu, 10 Jan 91 02:43:04 EST
>From: Robert Weiner <[e-mail]>
Subject: DEC Rainbow Kermit 3.02 Prerelease Available for Testing
Keywords: Rainbow, DEC Rainbow, MS-DOS Kermit 3.02

Here's the latest release of DEC Rainbow 100 MS-Kermit version 3.02 dev
27-Jan-1991 built from the current source on watsun in ~kermit/test/mss*.
This brings the Rainbow version in sync & up to date with the IBM PC version
as far as the MS-DOS Kermit system independent parts are concerned.

I haven't seen much (if any) feedback about the Rainbow versions.  I'm using
it on a Rainbow 100B with alot of memory and a V20 processor.  I'd like to
hear from someone who has used it on a machine with less memory, etc, or on a
Rainbow 100A.  I don't expect anything should have broke on a 'smaller'
Rainbow, but who knows.

This keeps the Rainbow version up-to-date with the current IBM PC version.
There is now also some documentation for the new Rainbow version in
mstrb1.doc.

[Ed. - Thanks, Robert!  The new files are in kermit/test/mstrb1.boo and .doc,
with a binary version in kermit/bin/mstrb1.exe.]

------------------------------

Date: Sun, 13 Jan 91 20:40:21 -0500
>From: [e-mail] (John Nyenhuis)
Subject: MS-DOS Kermit 3.02 in ROM on the HP Portable Plus
Keywords: MS-DOS Kermit 3.02, HP Portable Plus

Joe Doupnik suggested that I pass along my experiences in installing MS-DOS
Kermit 3.02 in ROM on the HP Portable Plus.

Over the holidays, I had some fun with the HP Portable Plus.  I got a ROM
burner and put Kermit in ROM.  In the Portable Plus architecture, it is
possible to run a program form ROM.  (The operating system puts the ROM
starting at 9000:0000.)  The idea is to have the code segments in ROM and to
have the data and stack segments in RAM.  To do this, I had to make a few
patches to mssker.asm.  Code like "mov ax,data" needs to be changed since it
is not possible for MS DOS to make segment fixups at load time if the program
is in ROM.  It was also necessary to do the approximately 120 relocation fixes
that arise from the two code segments.  (I wrote a small Turbo Pascal program
to do this.) I wrote a small loader program in assembler which calls Kermit
3.02.  The loader program has the responsibility of setting up the data and
stack segments, copying Kermit's data segment to RAM, and informing Kermit of
the values of DS and SS.  Kermit and the loader program fit in a pair of
27C512 EPROMS with about 35K to spare.

Kermit in ROM makes the Portable Plus, which has no internal drives, stand
alone. i.e., if you don't have an external drive, just use the Kermit from ROM
to load your files.  Since the program is run from ROM, Kermit will run on a
Portable with as little as 128 K RAM.

I am willing to be of help in supplying Kermit in ROM to HP Portable Plus
users.  I can e-mail the source code and image files to the interested.  For a
fee (say $50) to cover the cost of EPROMS, shipping, and time, I can do custom
burns and also include instructions on how to install the ROMs.  (Please
advise if this proposed service would cause a problem with Columbia's
copyright on the program.  I am deeply appreciative of the efforts that Joe
Doupnik and others have put into MS-DOS Kermit and under no circumstances do I
want to take unfair advantage of their efforts.)  Any thoughts you have on
distributing MS DOS Kermit ROMS for the Portable Plus are most welcome.

[Ed. - John, you are most welcome to offer this service.]

Also, I have passed along versions of MS DOS Kermit 3.02 for the GRiD Compass,
HP 150, and HP Portable and Portable Plus to Joe Doupnik.  (All are RAM
based.)  He said they would be put in /kermit/test in watsun.

[Ed. - They are, as listed earlier in this issue.]

Sincerely,

John Nyenhuis   Purdue University  School of Electrical Engineering
West Lafayette IN 47907   [phone]     [e-mail]

------------------------------

Date: Sat, 19 Jan 1991 13:12:22 EST
>From: Christine M Gianone <[e-mail]>
Subject: Using the MS-DOS Kermit Terminal Emulator with PICK
Keywords: PICK, MS-DOS Kermit and PICK

David L. Clark of History Database in Malibu, CA, USA, has sent in a document
describing how to use MS-DOS 3.0 Kermit's VT320 emulator to access the PICK
operating system in general, and the History Database in particular.  This
document includes detailed instructions for the PICK end, plus MS-DOS Kermit
initialization files for the PC.  This document has been put with the other
PICK Kermit files in kermit/d/pickrm.vt (PICKRM.VT on KERMSRV), and in
kermit/a/msipic.doc (MSIPIC.DOC on KERMSRV).  Thanks to David for this
excellent document.

------------------------------

Date: Tue, 8 Jan 91 18:08:00 EST
>From: Mike Freeman <[e-mail]>
Subject: CP/M Kermit for the Ampro Little Board
Keywords: CP/M Kermit

Here are the system dependent files to adapt CP/M-80 Kermit 4.10 for the Ampro
Little Board. The code was contributed courtesy of Jay S. Rouman of Mt.
Pleasant, MI (dexter![e-mail]). He tells me that it works up
thru 4800 bps and file transfers work fine at 9600 bps though the screen
doesn't keep up (presume QUIET mode doesn't present a problem).  I also
submitted cpxsy2.asm with a comment fixed and cpaaaa.hlp and cpk410.ann
updated to show CP/M Kermit support for the Ampro Little Board.

There are also a number of bugs fixed:

(1) leading white space in commands and keyword searches is now ignored
(whether from keyboard, CP/M command-line or TAKEfile -- this was the
original intent of the code but it didn't work).
(2) A further fix to the "disk full" reporting code in CPSPK1.ASM per
report from Russel Lang is hopefully the last.
(3) A RET has been put at the end of OUTCONN in CPXNOR.ASM -- D.P.Arnot
of Scottish Agricultural College in Auchincurive, Ayr, UK reported
this.
(4) Mr. Arnot also says the Amstrad Kermits don't work properly -- they
put garbage in received files (4.09 didn't work, apparently, either).
(5) The CPSCMD.ASM now zaps the entire fcb (in CMIL). This fixes a bug
where the COPY command did not copy files correctly after one
successful COPY on my HP-125.

Re the Amstrad: Am trying to get more info -- don't have one here.  Sorry for
the continuing fixes but suggestions keep coming in.  I presume this will
settle down pretty soon!  It's interesting to see CP/Mers come out of the
closet.  Ciao!

Some bugs in Remote commands and in the Transmit comands are fixed
(syntax for Remote commands is enforced more) and the 8K buffer is used
for the COPY, TYPE and PRINT commands (the big buffer). I hadn't
intended to submit the TYPE and COPY changes but had these bug fixes to
put in so thought I'd put these enhancements in also.

[Ed. - The new files are in kermit/test/cp*.* on watsun and in T:CP* * on
CUVMA.]

------------------------------

End of Info-Kermit Digest
*************************

From cmg  Tue Mar 19 16:16:04 1991
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA21697; Tue, 19 Mar 91 16:16:04 EST
Date: Tue, 19 Mar 91 16:16:03 EST
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V13 #3
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Tue, 19 Mar 1991        Volume 13 : Number 3

Today's Topics:

            Announcing MS-DOS Kermit 3.10
               New Version of XSEND for MS-DOS
                New CP/M Kermit Files


Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.1), IP host number 128.59.39.2.  Login as user anonymous
(note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired
files.  The Kermit files are in directories kermit/a, kermit/b, kermit/c,
kermit/d, and kermit/e.  Test versions are in kermit/test.  Binaries are in
kermit/bin (use ftp in binary mode).  You can also get Kermit files over the
BITNET/EARN network; to get started send a message with text HELP to KERMSRV,
the Kermit file server, at host CUVMA.  For detailed instructions, read the
file kermit/a/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, 18 Mar 1991 12:27:37 EST
>From: Christine M Gianone <[e-mail]>
Subject: Announcing MS-DOS Kermit 3.10
Keywords: MS-DOS Kermit 3.10
Keywords: IBM PC, DEC Rainbow, Grid Compass, HP-110, HP-150
Keywords: NEC PC9801, Victor 9000, Sirius/1, Heath/Zenith-100, Zenith-100

MS-DOS Kermit 3.10 is now available.  Here is a list of its major new
features; a more detailed description follows:

 . Support for Cyrillic character sets during file transfer
 . Automatic parity detection during file transfer
 . Support for full-duplex RTS/CTS flow control
 . User-settable serial port address and IRQ line
 . Improved and expanded network support
 . Text and graphics terminal emulation improvements
 . Improved printer control
 . Additional script programming functions and variables
 . Bugs fixed

SYSTEMS

Version 3.10 is available for:

 . IBM PC and PS/2 families and compatibles
 . DEC Rainbow 100
 . Grid Compass
 . Hewlett Packard 110 and Portable Plus
 . Hewlett Packard 150
 . NEC PC9801 (with Japanese Kanji/Katakana support)
 . Victor 9000 / Sirius 1
 . Zenith / Heath 100
 . Generic MS-DOS

The non-IBM versions lack certain system-dependent features present in
the IBM version such as network support, terminal emulation features (VT320
emulation, Tektronix emulation), and character-set translation, but they
all include the basic file transfer mechanisms of version 3.0 and later:
long packets, sliding windows, and so forth.

MAJOR NEW FEATURES:

Support for Cyrillic character sets during file transfer: SET FILE
CHARACTER-SET CP866, SET TRANSFER CHARACTER-SET CYRILLIC (ISO 8859-5
Latin/Cyrillic).  This allows Cyrillic text to be transferred with IBM
mainframe Kermit 4.2 and C-Kermit 5A with correct translation to or from the
various system-specific Cyrillic character sets.  Languages covered by ISO
8859-1 and CP866 include Bulgarian, Byelorussian, English, Macedonian,
Russian, Serbian, and Ukrainian.  There is as yet no built-in support for
Cyrillic terminal character sets, but this can be accomplished on Cyrillic
PCs with SET TERMINAL CHARACTER SET TRANSPARENT plus user-constructed SET
TRANSLATE INPUT tables.

Automatic detection of EVEN, ODD, or MARK parity during file transfer (SPACE
parity cannot be automatically detected).  Reduces file transfer failures
when using a 7-bits-with-parity connection when you have forgotten to give a
SET PARITY command.

RTS/CTS full-duplex hardware flow control is selectable with the new command
SET FLOW RTS/CTS for smooth operation with high-speed modems, terminal
servers, and other high-speed devices that support this feature.

A new command for telling Kermit the address for COM ports 1, 2, 3, or 4, as
well as their IRQ line numbers.  IRQ values other than 3 and 4 can be used
with nonstandard serial communication boards.  Now you can adapt Kermit to
just about any serial communications configuration.  However, the PC
hardware provides no protection against spurious IRQ values, so you must use
the new IRQ selection feature with great caution (for example, to avoid
accidentally interfering with your hard disk).

New or improved network support:

 . Support for Novell's TELAPI TCP/IP telnet program via the new command
   SET PORT TELAPI <internet-address>.

 . Support for Interconnections Inc TES terminal emulation over Novell Netware
   to Netware-equipped VAX/VMS computers via SET PORT TES <hostname>.

 . Improved support for IBM EBIOS / LANACS.  Baud rate can now be set for ACS,
   server port name can be selected so REDIRECT program no longer needed,
   HANGUP and BREAK work with ACS.

 . Support for AT&T StarGROUP Asynchronous Gateway service (via EBIOS).

 . Improved grouping of escape sequences sent by function and arrow keys.

 . Improved operation over slow network connections.

 . Networks supported now include:

     3COM BAPI
     AT&T StarLAN / StarGROUP
     DECnet CTERM and LAT
     IBM EBIOS / LANACS
     Intel OpenNET
     NetBIOS
     Novell Netware NASI / NACS
     Novell Netware TELAPI
     Interconnections Inc / Novell TES
     Ungermann-Bass Net/One
     plus any BIOS Interrupt 14 interceptor for TCP/IP or other services

New terminal emulation features:

 . Improved 132-column support.  New command SET TERMINAL WIDTH {80, 132}
   allows you to specify the screen width from the keyboard, and Kermit also
   responds to host-generated escape sequences for switching screen width
   between 80 and 132 columns.  Video adapters supported for automatic
   screen-width switching include:

     ATI EGA and VGA Wonder (NEW)
     AST, Dell, and other boards based on Western Digital VGA boards (NEW)
     AT&T / Olivetti
     Everex Viewpoint EV-659, FVGA-673, EV-678, Micro Enhancer Deluxe (NEW)
     IBM XGA (NEW).
     Paradise AutoSwitch EGA Mono (NEW)
     Paradise VGA Plus 16 (ROM BIOS 003056-xxx firmware) (NEW)
     Paradise VGA Plus (ROM BIOS 003056-xxx firmware) (NEW)
     Paradise VGA Professional (ROM BIOS 003056-xxx firmware) (NEW)
     STB VGA/EM (Tseng TVGA)
     STB VGA/EM Plus (Tseng 4000), VGA/EM-16, VGA/EM-16 Plus (NEW)
     Tseng Labs EVA board with 132-column kit installed
     Tseng Labs UltraPAK mono/Hercules with 132 column modes
     Video 7 Vega Deluxe with 132X25.COM driver installed and Video 7 VGA

   Other 132-column capable adapters are supported via automatic execution of
   user-provided COLS80.BAT and COLS132.BAT files.

 . SET TERMINAL CHARACTER-SET <name> [ G0 [ G1 [ G2 [ G3 ] ] ] ].  The new
   trailing parameters let you explicitly designate a particular character set
   to one or more of the terminal emulator's G0..G3 areas.  This is necessary,
   for example, for using an 8-bit character set in the 7-bit environment with
   Shift-In / Shift-Out.

 . The host may now designate 7-bit National Replacement Character sets to
   G0..G3 using standard ISO 2022 or DEC character-set designation escape
   sequences.

 . Key definition strings can now contain a mixture of keyboard verbs and
   regular characters.  Verbs can be not only built-in \K verbs (like
   \Kbreak), but also names of user-defined macros (like {\Kmymacro}).

 . New command SET TERMINAL ARROW { CURSOR, APPLICATION } lets you switch
   arrow key modes manually.

 . SET KEY LK lets you tell Kermit that you are using a DEC LK250 keyboard
   with an external LK250 driver loaded.

 . New SET TERMINAL BELL option, NONE, tells Kermit to ignore incoming bell
   characters, rather than sounding them (AUDIBLE) or flashing the screen
   (VISIBLE).

 . Keyboard control sequences and strings are now grouped together in network
   packets.

 . Transparent printing is now done a line at a time, rather than a character
   at a time.

 . Improved coordination with DesqView during terminal emulation.

 . VT100 terminal type added.  This is the same as the VT102, but sends the
   VT100 identification string in response to "what are you?" queries to
   prevent host applications from sending VT102-specific escape sequences such
   as insert / delete character.

 . HONEYWELL terminal type added.  Same as VT102, but with built-in ENQ and
   other responses to mimic a Honeywell VIP7809 terminal.  This allows MS-DOS
   Kermit to be used with Honeywell DPS-6 computers.  (MS-DOS Kermit does not
   normally support the ENQ feature because it is a security risk.)

 . Terminal emulations supported by the IBM version now include:

     DEC VT52
     Heath/Zenith 19
     DEC VT100 (NEW)
     DEC VT102
     DEC VT320
     Honeywell VIP 7809 (= VT102 but with several VIP-specific features) (NEW)
     Tektronix 4010/4014 graphics with VT340 features
     NONE (allows external console drivers to provide other emulations)

Tektronix graphics terminal emulation improvements:

 . Graphics-mode fore- and background colors now user-selectable via new
   SET TERMINAL GRAPHICS COLOR command.  Separate fore- and background colors
   can be used for text screens and graphics screens.  Graphics screen colors
   are now preserved after a clear-screen operation.

 . A text cursor is now available in graphics mode, selectable with the new
   SET TERMINAL GRAPHICS CURSOR command.

 . New built-in support of the Microsoft mouse for moving GIN-mode
   crosshairs.

 . The GIN mode crosshair cursor is now full-screen for increased visibility.

 . Various BYPASS mode improvements.

 . Improved character placement and rendition.

 . Tektronix graphics are supported on the following display adapters:

     AT&T / Olivetti (in CGA mode)
     Hercules and compatibles
     IBM CGA, EGA, VGA, XGA and compatibles (VGA and XGA used in EGA mode)
     Wyse 1280x800, 1280x780, and 1024x780 models

Printer control:

 . New SET PRINTER command lets you redirect printing to a selected file or
   device during terminal emulation, for example SET PRINTER OOFA.TXT (file)
   or SET PRINTER NUL (device).  This applies to your use of the Print-Screen
   and Ctrl-Print-Screen keys as well as to Transparent Print and Autoprint
   escape sequences received from the host during terminal emulation.

New file transfer features:

 . New command REMOTE PRINT <filespec> <options> to send a local PC file to a
   remote Kermit program and ask the remote Kermit to print it with the
   specified options (such as printer name, number of copies, etc).

 . New SET SEND DOUBLE-CHAR <char> command, to cause the specified character
   to be doubled in outgoing packets.  Useful for transferring files through
   PADs, TIPs, Honeywell mainframes, etc, that use a printable character as an
   escape and require two copies in order to pass one copy through.

 . New SET RECEIVE IGNORE-CHARACTER <char> command, to tell MS-DOS Kermit to
   discard and ignore the given character when received during file transfer.
   Useful for getting around communications processors that insert line feeds
   or similar characters in the data stream, e.g. for "screen wrapping".

 . New REMOTE SET FILE COLLISION UPDATE command requests the remote Kermit to
   reject all incoming files that are not newer than existing files of the
   same name.

 . SET FILE COLLISION { OVERWRITE, RENAME, DISCARD } tells what to do when an
   incoming file has the same name as an existing file.

 . New REMOTE LOGIN syntax allows imbedded spaces in username, passwd, acct.

 . Pressing Q or Ctrl-Q during file transfer now sends an XON character to
   break XOFF deadlocks.

New script programming features:

 . New IF commands added: IF LLT <word1> <word2> ("lexically less than") and
   IF LGT <word1> <word2> ("lexically greater than") for lexical string
   comparisons (IF EQUAL was already available), similar to IF <, IF >, IF =
   for numeric comparisons.  Both forms may be used with NOT, e.g. IF NOT LLT
   \%a \%b ...

 . New PRODUCT macro, similar to TERMINALS/TERMINALR.  Invoked when host sends
   CSI Pn;..Pn ~.  If macro named PRODUCT is defined, it is invoked with its
   arguments set to the numeric Pns (up to 9 of them).  Designed to let host
   applications invoke custom procedures on the PC, e.g. for VAX Lotus to
   automatically invoke a Kermit key mapping command file to set up the PC's
   keyboard for using VAX Lotus.

 . New CLS command to clear screen while in command mode.

 . New ON_EXIT macro, executed automatically (if the user has defined it) by
   the EXIT or QUIT command.  Useful for restoring video modes, etc.

 . Built-in variables of the form \v(name) added to command parser, for use in
   script programs, TAKE files, etc:

   \v(argc)        macro argument count
   \v(count)       current value of loop counter (SET COUNT / IF COUNT)
   \v(date)        current date dd-mm-yyyy, e.g. 08-02-1991
   \v(ndate)       numeric date yyyymmdd, e.g. 19910208
   \v(directory)   current disk and directory, e.g. C:\LETTERS
   \v(errorlevel)  current value of ERRORLEVEL variable (SET ERRORLEVEL)
   \v(keyboard)    IBM PC keyboard type: 88, 101, or (for LK250) 250.
   \v(platform)    PC type, e.g. IBM-PC, DEC-RAINBOW
   \v(program)     Program name, MS-DOS_KERMIT
   \v(speed)       Current transmission speed (only for COM1..4)
   \v(status)      0 if previous command succeeded, nonzero if it failed.
   \v(system)      MS-DOS
   \v(time)        Current time of day, hh:mm:ss, e.g. 12:30:01
   \v(version)     Numeric program version, e.g. 310 for version 3.10.

   These variables can be used in any context in any command where a \%x
   variable can be used, except they cannot be the objects of DEFINE, ASSIGN,
   or ASK commands; that is, they are read-only.  View all built-in variables
   with the new SHOW VARIABLES command.

 . Read access of DOS environment variables via \$(name), for example \$(PATH).

 . WAIT command now accepts modem signal names without backslashes: CD CTS DSR
   (for compatibility with C-Kermit), as well with with them: \CD, \CTS, \DSR.

 . New, more flexible WRITE command.

Bugs fixed since 3.01:

 . Redirection of REMOTE command output has been fixed
 . Unwanted echo of path from CD command in command files or macros
 . REMOTE LOGIN operation fixed
 . Corrected operation of ASK operation if used within a macro
 . Corrected operation of SET LOG command within macros
 . Latin1 transfer character set identification changed from I2/100 to I6/100
 . Serial port input buffer now cleared at start of a file-sending operation
 . Improvements in half duplex operation
 . Corrected calculation of screen rollback space for small and big memories
 . Corrections to character set translation tables
 . Corrections to VT300 UDK (user-defined keys) feature
 . Corrections to transparent printing
 . Corrections to split/speed Xon/Xoff flow control
 . Corrected operation with remote servers that don't understand I-packets
 . Correction to print-screen operations with local-echo on
 . Various minor VT and Tektronix terminal escape sequence bugs fixed
 . PC disk i/o errors during file transfer now reported to other Kermit
 . Corrected recovery from disk-full errors when logging a terminal session

INCOMPATIBILITIES BETWEEN MS-DOS KERMIT 3.10 and 3.00/3.01:

Macro arguments are now "stacked", saved at each macro entry and restored
upon exit, so that calling macro B from within macro A does not destroy macro
A's arguments.  Note: this changes the operation of the LOOKUP macro
described in "Using MS-DOS Kermit" (1st edition).  Variable \%0 now holds the
name of the currently active macro.

An INPUT command interrupted by keyboard activity now sets a FAILURE status
rather than SUCCESS, by popular demand.  You can use IF ALARM to test whether
failure was because of timeout or keyboard interruption.

The REPLAY command now allows screen rollback, dump, print, etc.  At the end
of the replay file, use regular terminal emulation keys (PgUp, Ctrl-End,
PrintScreen) to invoke these functions, and use Alt-X, Ctrl-]C, or Ctrl-C to
get back to the prompt.  Previously, any keystroke would return to the prompt.

BYE, FINISH, or LOGOUT commands that fail (e.g. because the remote server has
these operations disabled) no longer behave as if they had succeeded.

WRITE command has new format: WRITE <destination> <text>.  The <text> may
contain any Kermit variables, including \v(...) variables.

CRLF is now supplied automatically at the end of WRITE and ECHO text.

DOCUMENTATION:

See FILES below.  A new edition of "Using MS-DOS Kermit" is in preparation.

ACKNOWLEDGEMENTS:

Another collosal effort by Professor Joe R. Doupnik of Utah State University,
with help from Merton Campbell, John Chandler, Frank da Cruz, Max Evarts, Mike
Freeman, Hirofumi Fujii, Bo Gedda, Thomas Goerz, Brian Holley, Terry Kennedy,
Ted Medin, Jason Merrill, Andy Newcomb, Dan Norstedt, John Nyenhuis, Bert
Tyler, Robert Weiner, Steve Wood, Konstantin Vinogradov, Dave Zielke, and many
others.  Special thanks to all of you who participated in the testing period
and sent in valuable reports and suggestions.

NEW FILES:

Internet anonymous ftp    EARN/BITNET
watsun.cc.columbia.edu    KERMSRV@CUVMA   Description

  GENERAL FILES

 kermit/a/mskerm.hlp       MSKERM HLP      Help file (plain text)
 kermit/a/mskerm.bwr       MSKERM BWR      "Beware File" (bugs & limitations)
 kermit/a/msr310.doc       MSR310 DOC      Detailed description of new features
 kermit/a/mskerm.ed        MSKERM ED       Detailed cumulative edit history
 kermit/a/mskermit.ini     MSKERMIT INI    Sample initialization file
 kermit/a/msihay.scr       MSIHAY SCR      Hayes modem dialing script

  IBM PC FILES

 kermit/bin/msvibm.exe     (none)          Executable Kermit program for IBM
 kermit/a/msvibm.boo       MSVIBM BOO      BOO-encoded .EXE file for IBM
 kermit/a/msvibm.vt        MSVIBM VT       VT terminal emulator summary for IBM
 kermit/a/msvibm.tek       MSVIBM TEK      Tektronix emulator summary for IBM
 kermit/a/msivt3.ini       MSIVT3 INI      VT-200/300 keyboard mappings for IBM
 kermit/a/msivt3.doc       MSIVT3 DOC      Documentation for MSIVT3.INI
 kermit/a/msgtif.doc       MSGTIF DOC      Documentation for TIFF file format
 kermit/a/msulk2.asm       MSULK2 ASM      New LK250 keyboard driver

  OTHER VERSIONS

 kermit/a/ms*gen.*         MS*GEN *         Generic DOS files
 kermit/a/ms*gri.*         MS*GRI *         Grid Compass files
 kermit/a/ms*hp1.*         MS*HP1 *         HP-150 files
 kermit/a/ms*hpx.*         MS*HPX *         HP-110 / Portable Plus files
 kermit/a/ms*ibm.*         MS*IBM *         IBM-specific files
 kermit/a/ms*p98.*         MS*P98 *         NEC PC9801 files
 kermit/a/ms*rb1.*         MS*RB1 *         DEC Rainbow 100 files
 kermit/a/ms*v90.*         MS*V90 *         Victor 9000 / Sirius 1 files
 kermit/a/ms*z10.*         MS*Z10 *         Zenith / Heath 100 files

The ACT Apricot, Sanyo, NEC APC, DECmate, RMX, TI Professional, and Wang PC
versions have not been updated.

  SOURCE FILES

 kermit/a/ms*.asm, ms*.h   MS* ASM, MS* H   Microsoft assembler source files
 kermit/a/ms*.lnk          MS* LNK          Linker command files
 kermit/a/ms*.mak          MS* MAK          makefiles for "make"

All MS-DOS Kermit files have been removed from the test directories,
kermit/test/ms*.* on watsun and T:MS* * on KERMSRV.

The ".boo" files for each version are .EXE files encoded in a printable
ASCII format, suitable for BITNET, e-mail, and other nontransparent modes of
transmission.  You can decode the boo-files back into .EXE files using any
of the MSBPCT.* programs available in kermit/a/msbpct.* or MSBPCT * from
KERMSRV.  See msbaaa.hlp for details.

For a detailed description of the MS-DOS Kermit file naming conventions, see
the file msaaaa.hlp (MSAAAA HLP).

------------------------------

Date: Mon, 18 Mar 1991 12:28:30 EST
>From: Christine M Gianone <[e-mail]>
Subject: New Version of XSEND for MS-DOS
Keywords: XSEND, MS-DOS Kermit 3.11

The XSEND program (kept in the Kermit distribution as MSIXSE.*, originally
contributed by Mark Zinzow) creates a command file for MS-DOS Kermit to send
an MS-DOS directory tree to another PC that is running MS-DOS Kermit in
server mode.  XSEND has been updated by an anonymous donor to use relative
directory syntax rather than absolute directory names, so now it can be used
to send directories from MS-DOS Kermit to a Unix Kermit server as well as to
an MS-DOS Kermit server.  And with appropriate command-line options, XSEND
can also be told to create similar command files suitable for use by TFTP on
the PC.  Other new options are available too.  The new files are:

Internet anonymous ftp    EARN/BITNET
watsun.cc.columbia.edu    KERMSRV@CUVMA   Description

 kermit/a/mskxse.c         MSKXSE C        C-language source
 kermit/bin/mskxse.exe     (none)          Executable program
 kermit/a/msrxse.boo       MSRXSE BOO      Boo-encoded .EXE file
 kermit/a/msixse.hlp       MSKXSE HLP      Help file (plain text)

------------------------------

Date: Thu, 14 Feb 91 15:54:43 EST
>From: Mike Freeman <[e-mail]>
Subject: New CP/M Kermit Files
Keywords: CP/M Kermit 4.11

The files kermit/test/cps*.* (.asm and .hex) contain my latest tinkerings
with CP/M Kermit 4.10. These tinkerings have been fruitful: some code has
been tightened up a bit, a couple of bugs in the TYPE command have been
corrected and the mechanism for getting text to be passed to Kermit Servers
via REMOTE commands has been simplified, allowing characters such as <esc>
and "?" to be passed directly without having to type a "\"-prefixed octal
number for each of those characters in order to avoid misinterpretation or
inadvertent action by Kermit-80's command parser.  The bugs in the TYPE
command which have been fixed are:

 . The terminal screen was not always cleared before typing each file
   due to some terminals not reacting to <ff>s

 . TYPE did not always find the correct files and sometimes typed
   garbage or parts of other files (than the one(s) desired) when
   disks were reset.

Also, TAKE-files no longer recognize semicolons as command separators (so
commands like REMOTE DELETE *.*;* work correctly from TAKE-files), QUIT is
now a synonym for EXIT and CONNECT, RECEIVE and SEND may now be abbreviated
to C, R and S, respectively.  In addition, the files cpxtm4.asm and
cpvtm4.hex have corrected video codes courtesy of Lance Tagliapietra (he
says they work).

 -- Mike --

------------------------------

End of Info-Kermit Digest
*************************


From cmg  Fri Apr 26 12:23:10 1991
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA13209; Tue, 23 Apr 91 16:03:00 EDT
Date: Tue, 23 Apr 91 16:02:59 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V13 #4
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Tue, 23 Apr 1991        Volume 13 : Number 4

Today's Topics:

            Announcing CP/M-80 Kermit Version 4.11
            Patches for MS-DOS Kermit 3.10
                ROSCOE Kermit
          Announcing NEC PC 9801 MS-DOS Kermit 3.10

Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.1), IP host number 128.59.39.2.  Login as user anonymous
(note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired
files.  The Kermit files are in directories kermit/a, kermit/b, kermit/c,
kermit/d, and kermit/e.  Test versions are in kermit/test.  Binaries are in
kermit/bin (use ftp in binary mode).  You can also get Kermit files over the
BITNET/EARN network; to get started send a message with text HELP to KERMSRV,
the Kermit file server, at host CUVMA.  For detailed instructions, read the
file kermit/a/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 Apr 1991
>From: Mike Freeman <[e-mail]>
Subject: Announcing CP/M-80 Kermit Version 4.11
Keywords: CP/M-80 Kermit 4.11

Just to prove that the CP/M world still exists, here is CP/M Kermit-80
Version 4.11.  Features added since version 4.09 include:

  o SET COLLISION {BACKUP/DISCARD/OVERWRITE/RENAME}
  o SET INCOMPLETE-FILES {DISCARD/KEEP}
  o Many REMOTE commands, including some REMOTE SET commands
  o RENAME command to rename CP/M files from within Kermit-80
  o SET RECEIVE/SEND PACKET-LENGTH nn (nn <= 94)
  o SET AUTORECEIVE ON now implies that Kermit-80 ALWAYS tries to
    receive more files when a RECEIVE transaction has completed.
  o QUIT is now a synonym for EXIT.
  o STAY is now a synonym for SET NO-EXIT.
  o CONNECT, RECEIVE and SEND may be abbreviated to C, R and S, respectively.
  o Processing of commands from a file via a TAKE command may now be
    canceled by entering a Control-C at the console.
  o The TYPE and PRINT commands are now immediately canceled if a
    Control-C is entered at the console. If a Control-X is entered at
    the console, typeout/printout of the current file is canceled and
    typeout/printout of the next file, if any, begins.
  o Many bug fixes
  o Kermit-80 Version 4.11 now supports the Microbee family of computers
    (56K, 64K, 128K and 256K) manufactured by Microbee Systems, Ltd, Australia.
  o Kermit-80 now supports the Ampro Little Board system.

Technical changes:

  o An "I" packet is now tried before the request for files is sent
    in a GET command
  o The overlay address is now 7000H
  o The overlay (CPXLNK.ASM) has an added INCFLG variable to handle
    INCOMPLETE-FILES status
  o The COPY, TYPE and PRINT commands now use the large buffer
    (8K bytes default size) for file I/O

Many thanks to those who have contributed bug fixes, and, in particular, to
Mr. Russell Lang of Monash University, Australia, for contributing a bug-fix
and the family file for the Microbee systems and to Mr. Jay S. Rouman of
Mt. Pleasant, MI, for contributing the code for the Ampro Little Board.
Thanks are also due to Lance Tagliapietra of the University of Wisconsin at
Platteville for finding several bugs.

[Ed. - And many thanks to you, Mike, for all the work you have put into
CP/M Kermit over these past months!  The new files have replaced the old ones
in the Kermit "A" area: kermit/a/cp*.* on watsun (Internet) and CP* * from
KERMSRV at CUVMA (BITNET/EARN).  The updated manual is cpkerm.doc (plain text)
and cpkerm.ps (Postscript).]

------------------------------

Date: Thu, 11 Apr 1991
>From: Christine M Gianone <[e-mail]>
Subject: Patches for MS-DOS Kermit 3.10
Keywords: MS-DOS Kermit 3.10 Patches

Several patches have been issued by Joe Doupnik for MS-DOS Kermit 3.10.
They are in the file kermit/a/msr310.pch on watsun.cc.columbia.edu
(Internet) and MSR310 PCH on KERMSRV@CUVMA (BITNET/EARN).  This is a short
text file designed to be read by MS-DOS Kermit when it starts up.  It should
be renamed to MSKERMIT.PCH and stored in the same directory as your MS-DOS
Kermit initialization file, MSKERMIT.INI.  To install the patches, include
the command PATCH as the first command in your MSKERMIT.INI file.  CAUTION:
these patches should only be applied to the binary .EXE file for the IBM PC
family and compatibles distributed by Columbia as MSVIBM.EXE (or decoded
from MSVIBM.BOO).  Do not attempt to apply these patches to any other
version, or to a version you built yourself from the source files.

The patches include:

  1. Alternate video mode Orchid Designer Professional VGA board.
  2. Remove CRLF from WRITE command output.
  3. Make sure new NetBios sessions cancel old ones.
  4. Omit sending flow control XON when first opening a session.
  5. Correct errors in parsing { things braces }, and other fixes.
  6. Correction to patch 5.
  7. Cyrillic translation table corrections.
  8. Fix for VT terminal emulator CSI parser initialization.

Thanks to Joe for responding so promptly to users' bug reports!

------------------------------

Date: Fri, 1991 Mar 29   22:04 EST
>From: "John F. Chandler" <[e-mail]>
Subject: ROSCOE Kermit
Keywords: IBM Mainframe Kermit, ROSCOE, TSO/ROSCOE, MVS/TSO/ROSCOE

Two new files, IKRKER.BWR and IKRKER.UPD, constitute the collection of all
known tips, fixes, and workarounds for running TSO Kermit under ROSCOE.
This is not what I would call a full-fledged new variant of Kermit-370,
since ROSCOE Kermit is only slightly changed from "vanilla" TSO Kermit.
Hence, installers of ROSCOE Kermit will still need to fetch all IKT*.* files
and follow the instructions in IKTKER.INS with only a few alterations based
on IKRKER.BWR.  If further reports come in, I'll add them to the collection.
Also, I would be glad to include code updates, especially if some user
should feel motivated to add support for native ROSCOE files or other
ROSCOE-specific features.

John

------------------------------

Date: Thu, 18 Apr 91 20:28:28 JST
>From: Hirofumi Fujii<[e-mail]>
Subject: Announcing NEC PC 9801 MS-DOS Kermit 3.10
Keywords: NEC PC9801, MS-DOS Kermit 3.10

This is to announce an upgraded version of MS-DOS Kermit for the NEC PC9801.
It is up to date with the final version 3.10 sources, and it corrects a bug
with Xon/Xoff flow control.

Hirofumi Fujii

[Ed. Many thanks!  The new version replaces the old one in the Kermit
Distribution A area.]

------------------------------

End of Info-Kermit Digest
*************************


From cmg  Wed Jun  5 16:31:49 1991
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA26051; Wed, 5 Jun 91 16:31:49 EDT
Date: Wed, 5 Jun 91 16:31:48 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V13 #5
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Wed, 5 Jun 1991        Volume 13 : Number 5

Today's Topics:

               Kermit for Microsoft Windows 3.0
         New VAX/VMS Kermit-32 Available for Testing
        New Version of Honeywell DPS-6/DPS-6000 Kermit
         Re: C-Kermit 4E(072) changes for IBM RS/6000
          New Patch File for MS-DOS Kermit 3.10 IBM Version
            LK250 Keyboard Driver for DEC VAXmate
                  Kermit Files Moved
              Playing Dirty with Kermit
          Re: TCP/IP/Novell/Terminal Emulator for Wollongong
      MS-DOS Kermit 3.10 Key Map for Microsoft Word on SCO UNIX
            Macintosh Kermit Questions and Answers
         EMACS-Friendly Terminal Emulators for the Macintosh
           QTERM V4.3 for CP/M has improved Kermit support

Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.1), IP host number 128.59.39.2.  Login as user anonymous
(note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired
files.  The Kermit files are in directories kermit/a, kermit/b, kermit/c,
kermit/d, and kermit/e.  Test versions are in kermit/test.  Binaries are in
kermit/bin (use ftp in binary mode).  You can also get Kermit files over the
BITNET/EARN network; to get started send a message with text HELP to KERMSRV,
the Kermit file server, at host CUVMA.  For detailed instructions, read the
file kermit/a/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: Tue, 28 May 91 12:00:00 EDT
>From: Christine M Gianone <[e-mail]>
Subject: Kermit for Microsoft Windows 3.0
Keywords: Microsoft Windows 3.0 Kermit

Bill Hall has sent in a new release of Kermit for Microsoft Windows.
You may have seen Bill's feature article on this program in January 1991
Microsoft Systems Journal: "Adapting Extended Processes to the Cooperative
Multitasking of Microsoft Windows".  The previous release of this program
only works under Windows 2.0x.  The new release is for Windows 3.0.  Here
is Bill's description:

"A version of Kermit for Microsoft Windows 3.0 has been made available for
distribution by Columbia University.  The complete package contains a
Windows program along with documentation, fonts, and complete sources.  The
basic program, WIN100, contains a substantial emulation of DEC VT100 and
VT52 terminals and a version of Kermit with enough features to perform
reliable file transfer as well as act as a client to a Kermit server.

"WIN100 has evolved from an earlier experimental version which has been
available from Columbia for some time.  This latest version has several new
features:

   1. Support for COM1 through COM4.
   2. Improved font selection.
   3. A wider selection of foreground and background colors.
   4. Restricted scroll regions and origin mode.
   5. Control representation mode.
   6. Memory rollback.  Currently, this is limited to five screen pages.
   7. Redesigned dialogs.
   8. Editing commands to move around the terminal window and through the
      rollback memory.
   9. Substantial font support for the VGA including normal and bold fonts
      with both the Windows and DEC special graphics character sets, all in
      wide and narrow formats.  Sources for the fonts are also supplied.
  10. An optional 8-bit mode with support for some DEC 8-bit controls.
  11. A complete set of Kermit REMOTE commands including GET, BYE, FINISH,
      LOGOUT, as well as remote file manipulations.
  12. Enhanced user interface for working with REMOTE commands.
  13. Local commands for listing and changing directories.
  14. Dialogs for setting Kermit packet and Protocol parameters."

The files have been placed in the Kermit Test area (kermit/test on watsun,
T: prefix for KERMSRV) to allow for a period of public testing before formal
release.  The file names all start with the prefix "wk".  Get the file
"wkaaaa.doc" and read it first, then get the other files you need.  Many
thanks to Bill for this valuable contribution!

------------------------------

Date: Mon, 3 Jun 1991 16:29 -0500
>From: Jonathan_Welch <[e-mail]>
Subject: New VAX/VMS Kermit-32 Available for Testing
Keywords: VAX/VMS Kermit-32 3.4

This is a test version of Kermit-32 with file attribute support.  Its major
new feature is support for Kermit Attribute packets, which let the file sender
convey information about the file -- such as size -- to the receiver.
The version number is T3.4.016.

Use the command SET ATTRIBUTE ON to enable attribute support and SET
ATTRIBUTE OFF to disable it at the local level.  In this test version,
ATTRIBUTE is OFF by default, so you have to turn this option on explicitly.

Use the commands SHOW ALL, SHOW FILE, or SHOW PACKET to see the status of
local attribute support.

This version has been tested against itself and to a lesser degree against
MS-DOS Kermit 3.01.  I would like to know the results of additional testing
against these and other kermit implementations.

Jonathan Welch
VAX Systems Programmer
100 Marcus Hall
Univ. of Mass.                              Bitnet: JHWELCH@umaecs
Amherst, MA. 01003                        Internet: [e-mail]

[Ed. - Thanks, Jonathan!  The new version is in the Kermit Test area
(kermit/test on watsun, T: prefix on KERMSRV).  The filenames all start with
the letters "vms".  Please try out the new version and report successes or
failures, so we'll know whether to install it as the official release.]

------------------------------

Date: Tue, 7 May 91 03:50:03 PDT
>From: Frank Dreano <[e-mail]>
Subject: New Version of Honeywell DPS-6/DPS-6000 Kermit
Keywords: Honeywell DPS-6/DPS-6000 Kermit 2.01
Xref: Bull, See Honeywell

I am sending updated HD6KER.C, HD6KER.H, and HD6PRI.C source files for
the Honeywell DPS-6/DPS-6000 Superkermit.  The new version number is 2.01.
They contain the following minor fixes:

Dec 1990 - fixed a long-standing bug in binary file sending...the
    spar() routine defaulted to a 'Y' in the 8th-bit quoting field
    of the send-init packet; this meant that Superkermit did not
    require 8th-bit quoting - a usually false assumption.  Instead
    the classic Kermit prefix default char of '&' is now the default
    if no prefix character is received from the PC Kermit.

Apr 1991 - implemented the 'remote space' command as a Honeywell
    'STS -ALL' (status of all devices) command as MSKermit 3.10
    fixed a bug in this function.

This may be the last Superkermit update that you will receive as I am
considering building a C-Kermit (5A) for the Honeywell DPS-6/DPS-6000.  With
the knowledge of 'C' gained while writing Superkermit as well as what I have
learned about terminal I/O while porting the EMACS screen editor to the
DPS-6/DPS-6000 systems, this seems possible.  In fact, I have gotten all of
the C-Kermit modules (for the beta test sliding windows version) to compile
on a Honeywell computer and I am analyzing the requirements to build the
system dependent CKUTIO.C and CKUFIO.C modules.  I wish that I had only
known about the C-Kermit Program Logic Manual sooner - I feel like I have
found the Rosetta stone!  This will be a 'spare-time' project so I will keep
you posted.
                    Frank Dreano Jr.

[Ed. - Many thanks, Frank!  The new files, hd6ker.c and hd6pri.c, are in
the Kermit "D" area (kermit/d on watsun, or just refer to them by name on
KERMSRV).  If anybody else out there is interested in adapting C-Kermit 5A
to new systems, the "Rosetta stone" and all the other C-Kermit 5A files are
in kermit/sw/ on watsun (Internet access only, for now); be sure to contact
us before you start!  Work is especially needed for OS/2, Apollo Aegis, and
Data General AOS/VS, for which supporting code is written, but out of date.]

------------------------------

>From: [e-mail] (Jamie Watson)
Date: Wed, 29 May 91 12:16:17 MET
Subject: Re: C-Kermit 4E(072) changes for IBM RS/6000
Keywords: IBM RS/6000, C-Kermit 4E

The following are the changes I made to Kermit version 4E(072), for the
IBM RS/6000 running AIX 3.1, patch level 3003.  These changes assume the
use of the 'posix' serial line discipline, which is the default, and that
the program will be compiled with 'cc', not with 'xlc' or 'bsdcc'.  The
RS/6000 specific changes are bracketed by "#ifdef _IBMR2", which is a
symbol defined by the preprocessor phase of the RS/6000 C compiler.  The
command "make sys3nid" will compile everything appropriately.

In addition to the changes which are acutally "required" to get kermit
working on the RS/6000, I made one "convenience" change.  The serial port
can be selected on the command line with the "-l xxx" option; but if there
is a modem present, the modem type must be defined before kermit attempts
to open the serial line, in order to get it to use the O_NDELAY flag.  I
added a command line option of "-m xxx" to define the modem.  Thus, kermit
can be called with "kermit -m hayes -l /dev/tty12 -b 9600".

Also included with these diffs are two small changes necessary for the RT/PC
running AIX 2.2.1.  These changes are bracketed by "#ifdef aiws", which is
defined by that C compiler.

[Ed. - Thanks, Jamie!  These changes should tide RS/6000 users over until
release 5A of C-Kermit comes out, which incorporates support for the
RS/6000, your modem change, as well as support for many other new systems
and many new features.  Watch Info-Kermit for an announcement when the beta
test version is ready.  Meanwhile, Jamie's changes have been added to
kermit/b/ckuker.bwr (CKUKER.BWR on KERMSRV).]

------------------------------

Date: Tue, 28 May 91 12:02:00 EDT
>From: Christine M Gianone <[e-mail]>
Subject: New Patch File for MS-DOS Kermit 3.10 IBM Version
Keywords: MS-DOS Kermit 3.10

The file kermit/a/msr310.pch (MSR310.PCH on KERMSRV) contains four new patches
for MS-DOS Kermit 3.10 (IBM version), from Joe Doupnik:

 9. Prevent interaction between CONNECT mode and script session logging,
    and flush printer (PRN) buffer upon EXIT.

10. Printing while in Connect mode: if printer becomes not ready place
    message " *** PRINTER IS NOT READY *** press R to retry or D to discard
    printing" on the mode line and wait for a response.  Retries will now not
    omit buffered characters.  DOS's waiting time can be 20 seconds before it
    tells Kermit the status.

11. Permit implicit 80/132 column support for more video boards based on the
    Western Digital WD90C00 VGA chip.  These include Paradise Professional
    and Paradise VGA1024.

12. Final corrections to the Latin/Cyrillic-CP866 translation tables.

There is only one patch file.  These patches have been added to the end of
it, so now it contains patches 1-12.  To apply all patches to MS-DOS Kermit
3.10 (IBM version), transfer this file to your PC, put it in the same
directory as your MSKERMIT.INI file (the directory should be in your DOS
PATH), rename the file to MSKERMIT.PCH, and add the PATCH command to the top
of your MSKERMIT.INI file.

------------------------------

Date: Tue, 28 May 91 12:03:00 EDT
>From: Christine M Gianone <[e-mail]>
Subject: LK250 Keyboard Driver for DEC VAXmate
Keywords: LK250 Keyboard Driver, VAXmate, MS-DOS Kermit

>From Trevor Warwick, DEC UK, via Terry Kennedy (author of the LK250 driver
for the IBM PC family), an LK250 keyboard driver for the DEC VAXmate.  It is
installed as MSULKV.ASM in the Kermit A area (kermit/a on watsun, refer to
it simply by name on KERMSRV).  There is a short description at the top of
the file.  Thanks to Trevor for the contribution!

------------------------------

Date: Tue, 28 May 91 12:03:00 EDT
>From: Christine M Gianone <[e-mail]>
Subject: Kermit Files Moved

The following Kermit versions were moved from the "A" area to the "C" area
on April 23, 1991, because the new CP/M release caused Tape A to overflow:

  Version                  Files
    Commodore 64             c64*.*
    Tandy Color Computer     cck*.*
    Tandy Models 1 and 3     trs*.*
    Tandy Model 2            tr2*.*
    Tandy Model 4            m4k*.*
    PC Turbo Pascal Kermit   qk3*.*

------------------------------

Date: Wed, 15 May 91 13:54:54 EDT
>From: [e-mail] (A. Kaniss)
Subject: Playing Dirty with Kermit
Keywords: MS-DOS Kermit, CDC Cyber

Christine,

Here's a little trick that can make the lives of those who have to log onto
larger computers easier provided they're smart enough to decide to use kermit
to do it.

Situations arise when utilities that are on larger systems have complex
access paths and you can't keep copies in your own directory on the system.

A way around this problem such that when you want to use the utilities but
don't feel like entering those complex paths each time you want them is to
have kermit do it for you.

Specifically for CDC Cyber-type systems a kermit user may want to use kermit
on the system once they've logged on.

Rather than enter the attach command at the terminal, put all of those attach
commands into your kermit log-on script just before the CONNECT command.
Also remember to put the output command before them and end each OUTPUT
statement with "\13" (carriage return).

Now remember to put the "INPUT /" command on each line following each output
command to check on the output and make sure it happened.

An example will serve best to illustrate what I've been talking about so far:

  output attach,kermit /un=system\13
  input /
  output attach,ucsifm /un=userlib\13
  input /
  connect

When the connect happens all I have to type to start kermit is:

  kermit

and all I have to type to start ucsifm is:

  ucsifm

Jude

------------------------------

Date: 1 May 91 01:35:04 GMT
>From: [e-mail] (Todd Ogasawara)
Subject: Re: TCP/IP/Novell/Terminal Emulator for Wollongong
Keywords: MS-DOS Kermit Network Support, Wollongong TCP/IP, Novell

In article <[e-mail]>
[e-mail] (Todd Ogasawara) writes:

> I am using Wollongong's WIN/TCP for DOS to talk to my UNIX box from
> a Novell network via Wollongong's WIN/ROUTE for DOS (this routes the
> encapsulated TCP/IP packets within an IPX packet to get to my UNIX box).
> The problem is that the vt100 emulator that is used by both the telnet and
> rlogin software from Wollongong has a few problems and I would like to use
> another terminal emulator. Wollongong allows you to use another emulator.
> However, the software must go through interrupt 14. I don't have anything
> that does that (Kermit, Procomm, etc.).
>
Thanks to the many people who set me sent e-mail telling me the answer to my
problems.  Good ol' MS-DOS Kermit 3.10 (which I already had) did the trick.
I call Kermit from the Wollongong MS-DOS software using the command:

  telnet -e kermit hostname

or a batch file containing the lines:

  rlogin hostname -e -l username
  kermit

and have:

  SET PORT BIOS1

in my MSKERMIT.INI file (along with my normal setup).

Now everything works just fine.  Thanks again to everyone who responded!

Todd Ogasawara ::: Hawaii Medical Service Association
Internet       ::: [e-mail]
Telephone      ::: [phone] ext. 7

------------------------------

Date: Wed, 22 May 91 22:32:20 EST
>From: [e-mail] (Rodney Brown)
Subject: MS-DOS Kermit 3.10 Key Map for Microsoft Word on SCO UNIX
Keywords: MS-DOS Kermit 3.10, Microsoft Word

Enclosed is a key mapping file for MS-DOS Kermit 3.10 for use with
MicroSoft Word 5.0 on SCO-Unix.
Word provides a limping mode to support the lack of Scan codes.
Alt -> Ctl-A    Ctl -> Ctl-C    Shift -> Ctl-Z
Function Key 1-10 -> Ctl-F 1-9,0

I use a TERMINALS macro on ALT-W to load that Keyboard, run a script to
fiddle with the TERM variable, run word & send the PRODUCT escape sequence
to reset to a standard keyboard mapping after exiting word.
The following two lines in the /usr/lib/word/tcap file for the VT200 entry
give the paragraph character, midline dots & other DOS standard Word
characters. (Requires PARITY NONE connection)
    :Wa=\140:Wb=\145:Wc=\266:Wd=\142:Wf=\267:Wg=\151:\
    :Wi=\253:Wj=\273:\
A better way of proceeding could be to set up the word tcap entry to use
a standard Kermit keyboard mapping for function & cursor control keys,
so that the Word extensions don't interfere with normal running & don't
require separate loading.

Rodney Brown, Co-Cam Computer Group    ACSNet: [e-mail]

[Ed. - Thanks, Rodney!  Your key mapping file has been installed in
Kermit distribution as msimsw.ini.]

------------------------------

Date: Tue, 28 May 91 12:01:00 EDT
>From: Christine M Gianone <[e-mail]>
Subject: Macintosh Kermit Questions and Answers

In response to hundreds of messages...

Q: What is the latest version of Mac Kermit?

A: The version we are distributing officially is still 0.9(40).  There is a
   later version available in the kermit/test area: 0.98(63), but it is not
   officially released.  It has one very serious flaw: MacBinary file
   transfers can sometimes cause files to be deleted from your disk.  There
   is no documentation for any version since 0.9(40).

Q: Does Mac Kermit 0.9(40) work on the IIci, IIfx, IIsi?

A: There have been reports that it does not.  Hopefully the next release
   will remedy these problems.

Q: Why hasn't a new version of Mac Kermit been released in two years?

A: The next release of Mac Kermit is in preparation.  It's based on C-Kermit
   5A, which itself is not released yet.  As soon as a usable prerelease
   version is ready (pretty soon?), it will be announced for testing.

Q: What are some of the features of the forthcoming release?

A: Selectable fonts and sizes, cut and paste, printer control, international
   character sets, screen rollback, session logging, sliding windows,
   compatibility with newer Macintosh models and software, etc.  Also, many
   bug fixes: using the printer port as a communication port, inverse video,
   MacBinary transfers, etc etc.

Q: How does the "Print" menu work?

A: In version 0.98(63), you'll notice the Print menu is dimmed.  It becomes
   active when Kermit receives an ANSI printer control sequence from the
   host, such as ESC [ 5 i (begin transparent print) or ESC [ ? 5 i (begin
   autoprint).

Q: Does Mac Kermit work under System 7?

A: In version 0.98(63) -- available in kermit/test but never formally
   released -- communication works, file transfer works.  The major problem is
   with its built-in VT100 terminal emulation font.  This problem should be
   corrected in the next release.

Q: How about a DIAL command?  A script programming language?

A: It is not clear yet whether these facilities will be available in the new
   version.  They are part of C-Kermit 5A, upon which the new Mac Kermit
   will be based, but integrating C-Kermit's interactive prompt-and-command
   user interface with Mac Kermit's point-and-click style might prove too
   difficult.

Watch Info-Kermit for an announcement when the first prerelease version of the
new Mac Kermit is ready for testing.

------------------------------

Date: 2 May 91 23:54:52 GMT
>From: [e-mail] (Timothy L. Davis)
Subject: EMACS-Friendly Terminal Emulators for the Macintosh

Over the past month I've received 11 replies to my question: What terminal
emulators work well with GNU EMACS?  I was specifically interested in using
option as the meta-key instead of the ESC prefix, ability to generate all
control characters (including cntrl-space, control-^, etc.), using the mouse
for cursor positioning, and variably large number of rows and columns.

I was pleasantly surprised by the result:

  3 votes for MacKermit: does almost all I asked.

  3 votes for VersaTerm/VT Pro, which would do everything given
    a macro packages such as QuickKeys

  1 vote for MacLayers, which reportedly uses opt+command for META.
    I couldn't get this form of META to work. a high-bit stripper somewhere?

  1 vote for "termyulator", which I haven't heard of before, but is
    supposed to be extensible via XCMDs.

MacKermit does most of what I wanted, and more.  I was wisely warned that my
negative premonitions about MacKermit, based on an older version, were
totally wrong.  The latest MacKermit (version 0.98(62)) is MUCH improved,
and is really quite versatile.  With extended-length (1K) packets enabled, I
get file transfer rates about equal to those of Zterm.

And re: Emacs: The META key can be easily mimicked in "modifiers" by
specifying \033 for as a prefix character whenever option is held down.  All
the "missing" control keys can be programmed as "key macros".  Holding down
option causes the mouse to create cursor-movement commands for mouse clicks.
And, kermit correctly handles an increased number of columns.  Best of all,
it's free!

Thanks to all who responded.

Tim Davis ([e-mail])

------------------------------

Date: Wed, 1 May 91 23:28:45 PDT
>From: pallio.UUCP![e-mail] (David Goodenough)
Subject: QTERM V4.3 for CP/M has improved Kermit support
Keywords: CP/M, QTERM

As an alternative to Kermit 4.11, another CP/M program that provides Kermit
support is QTERM. Up to V4.2 the Kermit code was very buggy, but it's been
seriously re-worked for V4.3, and has several enhancements.

The main features that the Kermit implementation provides are server access,
type three block checks and long packets (up to 1023 bytes).

The extended block checks were done to increase reliability of long packet
transfers: using a type 1 block check on a 1K data packet is a bit too
likely to let an error slip through.

Server access is very limited: a regular send will send files to a server,
since it wakes up when the Send/Init packet arrives. For taking files from a
server, there isn't an initial I/Y exchange, it is assumed that the server
had sensible parameters set before entering server mode. Against C-Kermit
(4e-70) this worked well, but this was the only test bed available. Caveat
Emptor when using it against other servers. It'll probably get the job done,
but you may miss out on some of the neato features available.

In addition, numerous bugs have been fixed up: there were problems with
determining the high bit prefix character that would occasionally cause all
'Y's to be changed to '^Y's; also when repeat character packing was not
being used, there were problems detecting end of file properly, just to name
two.

The source for all of QTERM will be published (it may already be available
by the time this goes out), however it will probably only be useful for
study. Since QTERM has a lot of other features (including a very full Xmodem
implementation), the Kermit code makes heavy use of other capabilities in
the program, so it would be very hard to pluck the Kermit code out for use
in another program. However as an example of how to handle long packets and
extended block checks it may prove interesting.

    [e-mail] - David Goodenough        +---+
                        IHS    | +-+-+
    .....!wet!pallio!dg                +-+-+ |
AKA:    [e-mail]              +---+

[Ed. - Since this is not a Kermit program per se, it will not be part of
Kermit Distribution.  Kermit users who are interested in it should be able
to find it in the CP/M archives at SIMTEL20.]

------------------------------

End of Info-Kermit Digest
*************************

From cmg  Tue Jul  9 16:33:19 1991
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA24985; Tue, 9 Jul 91 16:33:19 EDT
Date: Tue, 9 Jul 91 16:33:17 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V14 #1
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Tue, 9 Jul 1991        Volume 14 : Number 1

Today's Topics:

           New VT200/300 Key Mapping File for MS-DOS Kermit
           MS-DOS Kermit and Microsoft Windows 3.0
                 Kermit and Desqview
              Kermit, LAT & Windows 3.0 problem
           8-bit Linemode Devices on IBM Mainframes
              New VMSHEX/VMSDEH Programs


Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.1), IP host number 128.59.39.2.  Login as user anonymous
(note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired
files.  The Kermit files are in directories kermit/a, kermit/b, kermit/c,
kermit/d, and kermit/e.  Test versions are in kermit/test.  Binaries are in
kermit/bin (use ftp in binary mode).  You can also get Kermit files over the
BITNET/EARN network; to get started send a message with text HELP to KERMSRV,
the Kermit file server, at host CUVMA.  For detailed instructions, read the
file kermit/a/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, 20 Jun 1991 10:58 CST
>From: Kevin Lowey <[e-mail]>
Subject: New VT200/300 Key Mapping File for MS-DOS Kermit
Keywords: MS-DOS Kermit

Here is a new version of MSIVT3.INI (also known as VT300.INI) which fixes a
bug in the extended keyboard definition, in which the DEC Remove key was
mapped to a nonexistent scan code, rather than to Gray Delete.  Also, the PC
F11 and F12 keys on extended keyboards are now used for Help and Do,
respectively, and the DEC F11-F20 keys are now mapped to Alt-F1 through
Alt-F10 on both 88 and 101 keyboards, for consistency, and the DEC Enter key
was moved to PC F10 on the 88 keyboard to make it easier to use programs
that require the keypad Enter key.

[Ed. - Thanks, Kevin.  The new file replaces the old version as msivt3.ini.
The documentation file, msivt3.doc, has also been updated.]

------------------------------

Date: Tue,  25 Jun 1991 14:25:32 EDT
>From: Christine M Gianone <[e-mail]>
Subject: MS-DOS Kermit and Microsoft Windows 3.0
Keywords: MS-DOS Kermit and Windows 3.0, Windows 3.0
Xref: Microsoft Windows, See Windows 3.0

In response to numerous queries, here is the situation -- as best we know it
-- with MS-DOS Kermit and Microsoft Windows.

MS-DOS Kermit is not a "Windows Application".  It was not written
specifically for Windows, and it does not have a Windows-like menu-and-mouse
command interface.  However, MS-DOS Kermit has knowledge of the Windows
environment and can run "in a window" under certain conditions.  This means
that Kermit can run simultaneously with other Windows applications (even
other copies of Kermit), it can use Windows fonts, and you can cut and paste
to and from the Kermit window into other windows, etc, if you have
constructed the KERMIT.PIF file properly and you have enough memory for
Kermit.

When Kermit cannot be run in a Window, you can still use it under Windows as
a full-screen application.

Under Windows 2.0, you can use Kermit in a window on any kind of PC or PS/2
that has enough memory.  Everything works normally (but slower) except
Tektronix emulation, which behaves as if you had a monochrome video adapter
(plus signs are used instead of dots).  The important .PIF file parameters
are "Directly Modifies" (uncheck all the boxes), "Memory Requirements" (190
KB required, 400 KB desired), "Program Switch" (check Text box), "Screen
Exchange" (check Text/Graphics box).  If you don't have enough memory, you
can reduce Kermit's memory requirement by eliminating rollback screens: give
the DOS command "SET KERMIT=ROLLBACK 0" before starting Kermit, or put this
command into your MSKERMIT.INI file.

Under Windows 3.0, the situation is the same as for 2.0 if you are running
Windows on a 386 or 486 class PC in Enhanced Mode, with the added benefit
that Tektronix graphics works if you set up your KERMIT.PIF file for the
High Grahics Video Memory display option (however, Windows will complain
when you try to switch back to Kermit's text screen from the graphics
screen, and does not save the graphics screen).

However, Windows 3.0 apparently does not allow non-Windows DOS applications
(even Kermit, which is written with "Windows awareness") to operate in a
window in Real or Standard mode, which you must use on a 286 or lower class
PC, such as a PC, PC/XT, PC/AT, PS/2 Model 50, etc.  On these machines,
Windows 3.0 only allows Kermit to run in full-screen mode.  This seems to be
a limitation of Windows 3.0.  If anybody knows how to overcome this
limitation, please send mail about it to Info-Kermit.

If you can get Kermit into a window, but it does not communicate over the
COM1 or COM2 port, check your WIN.INI file to make sure that the MODE
command for COM1 or COM2 does not include a ",P" -- if it does, remove the
",P".

------------------------------

Date: Mon, 3 Jun 91 11:47:02 EDT
>From: Isidore G Bendrihem <[e-mail]>
Subject: Kermit and Desqview
Keywords: MS-DOS Kermit, DesqView

I've been running kermit under Desqview 386 (QEMM 5.11 and DV 2.31) with no
problems.  I recently installed an upgrade from Quaterdeck (QEMM 5.13 and DV
2.33), and whenever I start kermit, after giving the "Press ?  for help"
message, it freezes my computer up.  I can't even get back to Desqview.  It
seems like kermit has taken control over the keyboard.  Any suggestions?

Configuration:

386sx, 4 MB
Chips & Technologies chip set
AMI BIOS
MS-DOS 4.01
Kermit 3.10 (I've tried both with patches and without them)

[From jrd: What's one to say?  At the startup stage Kermit is using 100%
pure DOS calls to do everything. Kermit never grabs keyboard interrupts.
That leaves two possibilities: DV 2.33 has changed what needs to go into
your DV setup file for Kermit and/or DV 2.33 has problems.  MS-DOS Kermit
worked fine with the previous release of Quarterdeck software.]

------------------------------

Date: Tue, 4 Jun 1991 15:34:16 EDT
>From: [e-mail] (Maria Rosa Drake)
Subject: Kermit, LAT & Windows 3.0 problem
Keywords: MS-DOS Kermit, DEC Pathworks

We are running DECs PathWORKS network operating system, which provides LAT
support, and Kermit 3.01 and Kermit 3.10. We have no difficulty using Kermit
to access host systems via LAT when running under DOS; however we have
discovered that when invoking Kermit from within Windows 3.0 enhanced mode,
the system hangs (it works under Windows 3.0 standard mode).  Our
MSKERMIT.INI file does a SET PORT DECNET VAXname and a CONNECT; right after
connect is where the problems occur.

The systems are Zenith 386's with 4MB of RAM running either MS DOS 3.3+ or
MS DOS 4.0.  Any suggestions?

Maria Rosa Drake
Florida International University

[From jrd: One supposes that Pathworks is not designed to run by loading
DECnet outside Windows and then coupling a task to it within Windows.  At
least that's my guess.  The networking programs have to take some steps to
ensure the top level client is in the "right virtual machine" and so on, and
maybe your version of Pathworks does not do that job.  I make no pretense of
being a Windows 3.0 expert of any kind, but a suggestion is to start the
whole thing from a .BAT file within Windows, to see if that helps.  You
might also contact DEC to see if this is a known problem and get any
workarounds.  In addition, I would check the Pathworks documentation on
suggestions configuring Windows (things to be said in SYSTEM.INI etc
regarding networks).  It could turn out that Windows 3 itself is the culprit
when programs use high numbered interrupts for communications (DEC LAT and
CTERM both require these things to talk to external terminal emulators).]

------------------------------

Date: Wed, 1991 Jun 12   19:28 EDT
>From: "John F. Chandler"   <[e-mail]>
Subject: 8-bit Linemode Devices on IBM Mainframes
Keywords: IBM 370 Kermit

I am looking for people who would be interested in trying out 8-bit-wide
file transfer through a new generation of front ends on IBM mainframes.  The
following is a list of configurations that I believe may support the new
8-bit-wide ASCII communications, but it is not by any means complete and not
necessarily accurate.  I'd be interested to hear from anyone who has
knowledge of these or other 8-bit devices for "LU1" communications.  Also,
as I said before, I'm looking for testers willing to try out a version of
Kermit that has been modified to take advantage of the 8-bit capabilities.
I can be reached at either

  <[e-mail]>
or
  <[e-mail]>

Thanks.  By the way, even if all you can tell me is that I have
misspelled something in the list, I would still like to hear from you.
By the way, I posted this message on the BITNET discussion group for IBM
protocol convertors (which was the closest thing I could find to the
subject), but got no substantive answers.  I also posted it on the IBM
mainframe Kermit developers discussion group with no better results.

  Maker      Model          Software

  Fibronics  K2000          KNET/MVS
  Fibronics  K200           KNET/MVS
  Fibronics  K310           KNET/MVS
  Intel      Fastpath       ACCES/MVS
  ?          ACC9315        ACCES/MVS
  ?          Eicon/MSDOS    PACKET/74
  Intel      Jupiter 1000   PACKET/74
  IBM        37x5           COMMPRO/NAS
  Amdahl     47x5           COMMPRO/NAS
  Renex      RPAD
  Netlink    SNA/Gate
  Netlink    3703
  Perle      350/SNA
  Telematics PCI 167
  Telematics PCI 1067

------------------------------

Date: Wed, 5 Jun 1991 19:30:29 EDT
>From: [e-mail] (Jeff Guerber)
Subject: New VMSHEX/VMSDEH Programs
Keywords: VMS hex/dehex programs

It was recently pointed out on the Info-VAX mailing list that VMSHEX/VMSDEH
do not work for VAX indexed files -- they come out sequential instead.  I
took a look at the MACRO source, and it wasn't hard to find the bug -- the
file organization byte was not being saved in the hexified file, as were the
record format, record attributes, and so forth.  I have fixed the programs
(by adding a new packet type) so that they do save this byte, and they seem
to work as expected.  (I wasn't sure that they would, because the RMS manual
seems to indicate that extended attribute blocks are needed, but I
successfully hexed/dehexed an indexed file with 3 keys, and the new file
matched the original exactly.)  VMSDEH seems to work fine with older .HEX
files that don't have this packet, with the organization defaulting to
sequential as before.  A better method might be to save the entire file
access block and any extended attribute blocks, but this is beyond my
knowledge of MACRO and RMS.

If the Old VMSDEH is used on new-VMSHEXed files, the old VMSDEH gives an
"Unknown block type" error message, skips the new record and goes on to
do the rest of the input file, creating a sequential output file, and so
it appears that replacing the old VMSHEX/VMSDEH programs with the new ones
will do no harm.

Sorry, but I cannot take over support for these programs (if such is
needed); I really know very little about MACRO.

Jeff Guerber
ST Systems Corp. (STX)
NASA / Goddard, code 693.2
[e-mail]

Any opinions are my own and not those of NASA or STX.

[Ed. - Thanks, Jeff!  The new VMSHEX and VMSDEH programs have been placed
in the Kermit Test area for now.  If anybody encounters problems with them,
please send reports to Info-Kermit.  For that matter, if anyone can verify
that they do work as advertised, and are upwards compatible with the old
VMSHEX and VMSDEH programs, let us know.]

------------------------------

End of Info-Kermit Digest
*************************

From cmg  Tue Aug 20 12:17:24 1991
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA19465; Tue, 20 Aug 91 12:17:24 EDT
Date: Tue, 20 Aug 91 12:17:23 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V14 #2
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Tue, 20 Aug 1991        Volume 14 : Number 2

Today's Topics:

         New Lotus 1-2-3/V Key Mapping File for MS-DOS Kermit
               Kermit With DOS 5.0 Task Swapper
        Windows 3.0 and High-Speed Kermit Connections
                  Window Slot Sizes
           Unique Log File Names for MS-DOS Kermit?
            Keyboard Bug in MS-DOS Kermit
                   Kermit Archives

Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.1), IP host number 128.59.39.2.  Login as user anonymous
(note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired
files.  The Kermit files are in directories kermit/a, kermit/b, kermit/c,
kermit/d, and kermit/e.  Test versions are in kermit/test.  Binaries are in
kermit/bin (use ftp in binary mode).  You can also get Kermit files over the
BITNET/EARN network; to get started send a message with text HELP to KERMSRV,
the Kermit file server, at host CUVMA.  For detailed instructions, read the
file kermit/a/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 Jul 1991 15:20 CST
>From: [e-mail]
Subject: New Lotus 1-2-3/V Key Mapping File for MS-DOS Kermit
Keywords: MS-DOS Kermit, Lotus

Here at Southeastern Louisiana University, we have Lotus/123 on our VAX/VMS
system.  Many of our users use PCs with Kermit to access the VAX system and we
would like to have some method of maintaining transparency for the user, i.e.
we want the user to be able to use Lotus/123 on the Vax from his PC and have
it look and feel as though he were using PC Lotus.

I have created a Lotus 1-2-3 key mapping file for enhanced keyboards.  I am
sending that to you separately.  Feel free to make any suggestions/comments,
etc. and use it in the digest.

Ravi
BITNET:  RAVI@SLU
Southeastern Louisiana University

[Ed. - Thanks very much, Ravi!  The new file is in kermit/a/msi123.ini on
watsun, and MSI123.INI on KERMSRV.]

------------------------------

Date: Mon, 15 Jul 91 23:47:17 EDT
>From: Dick Elnicki <[e-mail]>
Subject: Kermit With DOS 5.0 Task Swapper
Keywords: MS-DOS Kermit and DOS 5.0, MS-DOS 5.0

DOS 5.0 and Kermit appear quite compatible.  I am currently using Kermit
with my EasyK scripts for this e-mail.

A program applicaton for Kermit access to our IBM VTAM services is in my DOS
Shell.  Before starting it, I enabled the Active Task list.  Then I clicked
on the program name to auto dial into our VTAM services.

Once signed on, I can press ALT with ESC to toggle back to the DOS Shell.
At the shell, I can start a second application, e.g., PCWrite or Lotus 123.
This, of course, depends on the free memory available.

The ALT with TAB's also works as described.  One can toggle through the
active tasks.  The name appears at the top of the screen.  A choice is make
by pressing Enter for a named task.

The ALT with ESC choice gives the DOS Shell as noted above. Here you can
also double click on the desired active task to return to it.  Or, you can
click on another program to start it (if you have enough free memory).  And,
you can click on an active task, then on FILE, and then on DELETE to shut
down an application.

My mouse works as desired.  It is an inexpensive 3-button mouse that is not
from IBM, Microsoft, or any other "name" brand.  The roller ball runs the
cursor, the left button is set to ENTER, the middle button is PF7 (scroll up
in the VTAM world), and the right button is PF8 (scroll down).

DOS 5.0 is certainly worth the price of admission.  It does run a number of
my applications that DOS 4.0 could not handle.  The DOS Shell run with the
mouse is easier to use than my old dozen-or-so AAA.BAT-type application
start-up screen.  The HELP is great, too.

This is not a commercial.  I don't have any stock in Microsoft.  I do hope
you can use the above to pass on to other Kermit users how they might use
DOS 5.0.

Best regards,
Dicke

[Ed. - Thanks for the encouraging report, Dicke!  It seems that we are going
through a period of Microsoft pulling the rug out from under Kermit with new
releases of Windows, DOS, etc.  Unfortunately, the reports are not all
completely positive.  One user reports that Kermit cannot keep up with serial
port input at high speeds -- 19,200 bps or above, depending on the processor
model, under DOS 5.0.  Apparently, DOS 5.0 can lose serial port interrupts
where previous versions of DOS did not, most likely because of its new memory
management features.]

------------------------------

Date: Thu, 25 Jul 91 16:06:52 EDT
>From: [e-mail]
Subject: Windows 3.0 and High-Speed Kermit Connections
Keywords: MS-DOS Kermit and Windows 3.0, Windows 3.0

If you desire to run MS-Kermit at speeds higher than 9600 bps under
Windows 3.0 (MS-DOS) you need a third party driver (i.e. TurboComm)
because the native Windows 3.0 communication driver maxes out at 9600.
You also need to have 16550a UART chips in your serial ports too.

H.W.Payne

------------------------------

Date: Fri, 26 Jul 91 15:57:35 -0700
>From: [e-mail] (Charles Lloyd)
Subject: Window Slot Sizes
Keywords: Sliding Windows, Packet Length, Performance

How does one determine the best size for a window slot?  I have a line which
has between 1 to 2  seconds roundtrip delay  (variable wrt time  of day) and
have not improved effective throughput much with choices or 1, 4, or 8.

Slot count = 1 : Significant idle time on LEDs of modem.
Slot count = 4 : Sporadic idle time, rapid acknowledgements on SD LED.

Slot Count = 8 : Alomost continuous flow on the RD light, almost continuous
blips on SD light.  Yet, the throughput only went from 5Kbps to 7 Kbps in
going from 1 to 8.  (I didn't check for slots = 4).

Is it unadvisable to play with packet size?

Is it possible to set the slot count too big so that data overruns cause
more errors than with a smaller window?  What's the rule of thumb?

Many thanks,
Charles.

[Ed. - There is an article in Kermit News #4 explaining in great detail how
to optimize Kermit's performance by varying the window slots and packet
length.  Kermit News #4 is on watsun as kermit/e/news.n4, NEWS.N4 on CUVMA
via KERMSRV.  Briefly, you should use the smallest window size that keeps
the modem receive or transmit light on continuously (depending on whether
you are sending or receiving files), and then increase the packet size to
the maximum allowed by the receiving Kermit.  Let's say you get continuous
transmission with 5 slots.  MS-DOS Kermit's total packet buffer size is
2000, so the maximum size for each packet is 2000 / 5 = 400.  Tell both
Kermits to SET WINDOW 5, and tell the receiving Kermit to SET RECEIVE
PACKET-LENGTH 400.]

------------------------------

Date: Sat Jul 20 19:13:04 1991
>From: Ben Olasov <syska.com![e-mail]>
Subject: Unique Log File Names for MS-DOS Kermit?
Keywords: MS-DOS Kermit and Unique File Names

I'm trying to turn on a session log file prior to invoking a Kermit script
file.  While the command line:

  kermit take cbd.scr

works, the line:

  kermit log session d:\local\20\250.txt take cbd.scr

doesn't.

[Ed. - Multiple commands on the command line must be separated by commas:

  kermit log session d:\local\20\250.txt, take cbd.scr

Adding the comma after "250.txt" should fix the problem.]

The reason I'm turning on the session log first is so that I can expand a
system variable (from Waffle BBS software) into a filename at the time
that the kermit command line is executed, thereby logging each session to
a unique filename.  If anyone knows how to do this, or has an effective
alternative approach, I'd really like to hear from them.

Thanks,
  Ben Olasov

[Ed. - If you're using MS-DOS Kermit version 3.10 or later (you should be),
try this:

  SET COUNT 999
  DEFINE \%F \V(NDATE).\V(COUNT)

This makes the \%f variable be something like "19910727.999" (filename =
today's date, filetype = 999).  Now let's see if the file already exists:

  IF NOT EXIST \%F GOTO OK

If it does, decrement the COUNT variable and try again until you have a
name that's unique:

  SET COUNT 999
  :LOOP
  DEFINE \%F \V(NDATE).\V(COUNT)
  IF NOT EXIST \%F GOTO OK
  IF COUNT GOTO LOOP
  ECHO Sorry, you've already created 1000 log files today!
  STOP
  :OK
  LOG SESSION \%F

That should give you a unique filename.]

------------------------------

Date: Tue, 09 Jul 91 11:45:24 BST
>From: Brian Wood <[e-mail]>
Subject: Keyboard Bug in MS-DOS Kermit
Keywords: MS-DOS Kermit and Keyboard Drivers

I am surprised that this has not been picked up sooner as it is a bug which
appears to have been present in MS-DOS Kermit since version 2.31.

On an OPUS PC3, a turbo xt, which I suspect is also sold under different
badges, running MS-DOS 3.3 there is a clash between Kermit and the keyboard
driver installed using the KEYB.COM program.  I have only used the driver
for the UK keyboard but logically it should apply to them all.  After
varying amounts of time the PC will appear to hang and will not respond to
the keyboard except that you will get the beep to tell you that the keyboard
buffer is full.  This may well happen with other machines which use MS-DOS
3.3 and KEYB.COM.

The remedy is to use "set key off" to force kermit to use the DOS keyboard
routines rather than BIOS.

Cheers,

Brian Wood,
UMIST,
Manchester,
England.

[Ed. - This is not a Kermit bug.  Kermit is simply asking the BIOS for
keyboard input.  Kermit is not hanging the system, the BIOS and/or the
keyboard driver are doing it.]

------------------------------

Date: Fri 2 Aug 1991 11:33:26 EDT
>From: Christine M Gianone <[e-mail]>
Subject: Kermit Archives
Keywords: Kermit Archives

We receive a lot of complaints that it's difficult to find things in the
Kermit archives, and suggestions about how to reorganize them.  Many people
would like to see us put the MS-DOS related files into ZIP archives, the
UNIX-related files into compressed tar archives, or put each version in its
own subdirectory, etc etc.

The Kermit archives are designed to be written to industry standard ANSI "D"
or IBM OS "VB" labeled tapes that can be read on a wide variety of computers.
These tapes can only have text files on them; they consist of "records" that
are lines of text, and they can't have any kind of directory structure.  Tapes
are sent out by mail order, and the income from these orders pays for the
Kermit Development and Distribution operation and subsidizes network access.
We don't have the disk space or the time to keep multiple copies of the
hundreds of different Kermit implementations in the many different formats
that network users ask for.  If we were better funded and staffed, of course,
it would be a different story.

Here is a brief road-map to the Kermit files.  There are five major Kermit
areas, A through E.  On watsun.cc.columbia.edu, which offers anonymous FTP
access to the Internet, there is a kermit directory.  It contains a file
called read.me, which explains the organization of the directories and files
underneath it:  kermit/a through kermit/e, plus several special directories
for binary files, test versions, etc.  On BITNET/EARN, Kermit file access is
handled by a file server called KERMSRV at CUVMA.  You can ask KERMSRV for
any file by name, as long as it is in one of the A through E areas.  Binary
files are not available on KERMSRV, but  test versions can be requested by
prefacing filenames with "T:", for example T:MSTIBM.BOO.

Each directory, a through e, contains a group of files whose names start
with "aa", for example aavers.hlp.  These are text files that list all the
Kermit versions, sorted in various ways: by computer, operating system,
language, area, release date, etc.

Within each directory, files for each version are grouped together by
filename.  Related files start with the same 2- or 3-letter prefix, for
example all the MS-DOS Kermit files start with "ms".  When there are many
files for a particular Kermit version, there is usually an "aaa" file for
that version, for example msaaaa.hlp or ckaaaa.hlp, that explains the file
naming conventions.

------------------------------

End of Info-Kermit Digest
*************************

From cmg  Thu Aug 22 14:49:11 1991
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA22965; Thu, 22 Aug 91 14:49:11 EDT
Date: Thu, 22 Aug 91 14:49:10 EDT
To: Info-Kermit
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest Now Delivered by LISTSERV
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>


The Info-Kermit Digest is now delivered by BITNET LISTSERV, which has proven
more reliable and flexible than UNIX sendmail.  All subscribers who were
previously on the Info-Kermit distribution list at watsun have been moved to
the I-KERMIT LISTSERV distribution list: [e-mail],
[e-mail].

Digest submissions should still be sent to [e-mail],
and administrative queries to [e-mail].
Alternatively, BITNET/EARN subscribers can send mail to KERMIT@CUVMA (not
I-KERMIT).  But from now on, you can subscribe to Info-Kermit yourself, you
can cancel your subscription yourself, and you can correct your personal name
yourself.  Just send e-mail to: [e-mail] (or to whatever BITNET
node you actually received this Digest issue from), and Internet subscribers
can mail to [e-mail].  In the text of the
message, use the following commands:

  SUBSCRIBE I-KERMIT <your-personal-name>    (To start a subscription)
  UNSUBSCRIBE I-KERMIT                       (To cancel a subscription)
  REGISTER I-KERMIT <your-personal-name>     (To correct your name)

Remember: Don't send SUBSCRIBE, UNSUBSCRIBE, or REGISTER messages to I-KERMIT,
send them to LISTSERV.  Mail sent to I-KERMIT is forwarded to the whole list;
only the list owner is allowed to mail to I-KERMIT.  Send Digest submissions
or queries to KERMIT@CUVMA or to [e-mail].  If you
received this message, no action is required on your part.

Kermit files are still accessible in the normal way: from KERMSRV at CUVMA
on BITNET/EARN, and via anonymous FTP from watsun.cc.columbia.edu on the
Internet.  Internet users may also refer to watsun as:

  kermit.cc.columbia.edu

This name will remain effective in case the Kermit distribution host ever
changes from watsun to some other machine (this won't happen in the
foreseeable future).

For further information about LISTSERV, send mail to [e-mail]
containing the text "INFO".  Various reference cards, tutorials, and reference
manuals are available.

I trust that this change will result in fewer missed or duplicated issues,
and generally more reliable delivery.

From cmg  Fri Aug 23 15:13:06 1991
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA08669; Fri, 23 Aug 91 15:13:06 EDT
Date: Fri, 23 Aug 91 15:13:05 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V14 #3
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Fri, 23 Aug 1991        Volume 14 : Number 3

Today's Topics:

           MS-DOS Kermit 3.11 Prerelease Ready for Testing
          Termcap/Terminfo for MS-DOS Kermit on the Wang PC
              MS-DOS Kermit Speed under Windows

Digest submissions may be sent to [e-mail] or
[e-mail].  Requests for addition to or deletion from the
Info-Kermit subscriber list should be sent to [e-mail] or
[e-mail].  These messages must be of the form:

  SUBSCRIBE I-KERMIT <your-personal-name>    (To start a subscription)
  UNSUBSCRIBE I-KERMIT                       (To cancel a subscription)
  REGISTER I-KERMIT <your-personal-name>     (To correct your name)

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.1), IP host number 128.59.39.2.  Login as user anonymous
(note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired
files.  The Kermit files are in directories kermit/a, kermit/b, kermit/c,
kermit/d, and kermit/e.  Test versions are in kermit/test.  All files in these
directories should be transferred in text (ASCII) mode.  Binaries are in
kermit/bin (use ftp in binary mode).  You can also get Kermit files over the
BITNET/EARN network; to get started send a message with text HELP to KERMSRV,
the Kermit file server, at host CUVMA.  For detailed instructions, read the
file kermit/a/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, 23 Aug 1991 15:28 EDT
>From: Christine M Gianone <[e-mail]>
Subject: MS-DOS Kermit 3.11 Prerelease Ready for Testing
Keywords: MS-DOS Kermit 3.11, TCP/IP

>From Professor Joe R. Doupnik (JRD) of Utah State University, a new release
of MS-DOS Kermit.  The final release will occur in about one week, so rapid
testing and reporting of bugs is needed.  Please report problems directly via
e-mail to Joe: [e-mail] (Internet), JRD@USU (BITNET/EARN), with cc to
[e-mail].  Please limit your reports to bugs
(and/or fixes) -- the design and features of this release are frozen.  The
sooner you get your bug reports in, the greater the chances of getting the
bugs fixed!

The differences from version 3.10 are:

  NETWORKS:
  . Built-in TCP/IP network support for PCs with Ethernet-style packet drivers.
  . New SET PORT TCP/IP <host>, SET TCP/IP <parameter> <value> commands.
  . Alt-n has \Knethold assigned by default.
  . SET NETBIOS-NAME allows you to set the PC's Netbios node name.

  TERMINAL EMULATION:
  . VT220 terminal type now supported.
  . Alt-minus now toggles between current text terminal and graphics screens,
    rather than all possible terminal types.
  . SET TERMINAL CHARACTER-SET DEC-SPECIAL.
  . SET TERMINAL UPSS {DEC-MCS, LATIN1}.

  SCRIPT PROGRAMMING:
  . New OPEN, CLOSE, READ, and WRITE commands for local file access.
  . "Long variable names": \m(this-is-a-variable-name).
  . Maximum length for macro definitions raised from 255 to 1000.
  . GOTO is now global, rather than confined to current macro or command file.

  OTHER:
  . New simplified and expanded dialing directory using a plain text file.
  . All known 3.10 bugs are fixed.
  . Improved help and status screens.
  . New help and beware files.

The long variables work like this.  Define them as if they were macros:

  define telephone-number 7654321

Refer to them using the new \m() construct:

  output atdt \m(telephone-number)\13

Those who want to try out the TCP/IP networking support, but don't have
packet drivers, use anonymous FTP to get them from Clarkson College in
Potsdam, NY, host sun.soe.clarkson.edu [128.153.12.3], cd pub/ka9q, use "type
binary", get the appropriate zip, arc, zoo, etc, files, and use PKUNZIP or
ZOO on your PC to unpack them.  Only Ethernet-style packet drivers are
supported.  The new version of Kermit has been sucessfully tested with the
following boards and accompanying packet drivers:

  Ungermann-Bass PC/NIC board with Clarkson UBNICPC packet driver 9.1
  3COM 3C503 with Clarkson 3C503 packet driver 9.4.0
  Western Digital WD8003E with Clarkson WD8003E packet driver
  Cabletron boards with Cabletron CSIPD_E (1.05) and CSIPD_X packet drivers
  IBMTOKEN.COM 3C501 emulation packet driver 1.9 over Token Ring board+drivers
  DIS_PKT over NDIS for LAN Manager networks (incl DECnet/DOS, AT&T StarGROUP)

The new Kermit commands are:

  SET TCP/IP ADDRESS <ip-address>     Tell Kermit the IP address of your PC
  SET TCP/IP BROADCAST <ip-address>   IP broadcast address
  SET TCP/IP SUBNETMASK <ip-address>  Your local IP network subnet mask
  SET TCP/IP GATEWAY <ip-address>     IP address of nearest gateway
  SET TCP/IP DOMAIN <domain-name>     Domain name for your local IP network
  SET TCP/IP PRIMARY-NAMESERVER <ip-address>    Address of primary nameserver
  SET TCP/IP SECONDARY-NAMESERVER <ip-address>  Address of fallback nameserver
  SET TCP/IP HOST <ip-address or host-name>     Default host for SET PORT TCP
  SET PORT TCP/IP <ip-address or host-name>     Specify host to connect to

Automatic downloading of some of these parameters via BOOTP or RARP is also
supported.  Before using Kermit's TCP/IP features, be sure to read the TCP/IP
sections at the end of MSKERM.HLP and MSKERM.BWR!

Many thanks to Erick Engelke of Waterloo University in Ontario for
contributing his Waterloo TCP package (WATTCP), and for his cooperation in
adapting it to Kermit.

The new files are in kermit/test/ms* on watsun.cc.columbia.edu, and in T:MS*.*
on KERMSRV at CUVMA on BITNET/EARN.  Convert the MSTIBM.BOO file into
MSTIBM.EXE with any of the MSBPCT.* programs available in kermit/a or
kermit/bin, or from KERMSRV.  On the Internet only, the binary MSTIBM.EXE
program is available via binary-mode FTP from kermit/bin/mstibm.exe.
FTP users: remember -- transfer files from the kermit/bin directory in binary
mode, transfer all files from all the other directories in text (ASCII) mode.

Source code will appear with the final release.

See MSKERM.HLP for information about the new commands and about how to use
the dialing directory.  Make sure to get the new MSKERMIT.INI and MSIHAY.SCR
files too, since the dialing directory is implemented by these files (note,
you must rename MSIHAY.SCR to HAYES.SCR so the DIAL command can find it).
There is also a sample dialing directory file MSIDIA.TXT (rename to
DIALUPS.TXT).  The "beware file" for the new version is MSKERM.BWR -- be sure
to read it before reporting problems.

As always, our deepest thanks to Joe for his skill, generosity, patience, and
long hours of hard work in making this new version of MS-DOS Kermit available.

------------------------------

Date: Thu, 8 Aug 91 16:35:49 EDT
>From: [e-mail]
Subject: Termcap/Terminfo for MS-DOS Kermit on the Wang PC
Keywords: Wang PC Kermit

In case it's of interest to anyone else, I am sending my cheap way out of not
having a terminal emulator with the Wang PC version of MS-DOS Kermit: UNIX
termcap and terminfo files that will make the PC work as a VT100 minus
function keys.  (it has the correct screen and cursor escapes and the cursor
arrow keys which makes it completely adequate for full screen use but not
function keys).

Let me also mention that I've put the IBM-PC version of Kermit on several PC's
here we use as terminals, which had vt100 emulators only.  The vt320/tek
emulators are great and will probably save us from buying new graphics
terminals.  Keep up the good work!

Best regards,
                     Paul Mende
 [e-mail]            Center for Theoretical Physics
 [e-mail]            Massachusetts Inst. of Technology

[Ed. - Thanks, Paul.  The Wang PC termcap/terminfo material has been added
to the Kermit distribution as MSVWNG.TC.]

------------------------------

Date: Tue, 20 Aug 91 15:15:19 EST
>From: Pat Zerkle <[e-mail]>
Subject: MS-DOS Kermit Speed under Windows
Keywords: MS-DOS Kermit and Windows 3.0

Regarding newsletter comments re MS-DOS 5.0, Windows 3.0, and serial speeds
above 9600.  I use a 386/25MHz  64k cache, 4mb RAM 'AT Clone' (Club American)
with AMI BIOS, connecting via a DEC LAT to an IBM 7171.  I have had no
problem using MS-Kermit 3.1 at 19200 bps under MS-DOS 4.01, MS-DOS 5.0, and
via Windows 3.0 Enhanced under either DOS version.  In Windows, I use the
switch to enable background execution.  The maximum speed is probably limited
by a combination of software/BIOS/architecture/serial hardware/system load, so
we can probably only use empirical methods to get it to work.  As for Windows,
the files \WINDOWS\SYSIN*.TXT installed by Windows (at least, my 5/1/90 files)
explain several SYSTEM.INI settings related to COM ports.  The COMxBuffer and
COMBoostTime settings may help (hurt?) some users.

Cordially,
Pat Zerkle

[Ed. - Thanks for the encouraging report.  Another user, E.W. Carlson says,
"I don't understand the July 25 comment that MS-Kermit can not run faster
than 9600 baud under Windows.  I routinely run MS-Kermit at 19,200 baud
under Windows on a PS/2 55SX.  The machine is standard IBM equipment with
no special chips added."]

------------------------------

End of Info-Kermit Digest
*************************


From cmg  Fri Aug 30 13:02:31 1991
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA13446; Fri, 30 Aug 91 13:02:31 EDT
Date: Fri, 30 Aug 91 13:02:30 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V14 #4
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Fri, 30 Aug 1991        Volume 14 : Number 4

Today's Topics:

          MS-DOS Kermit 3.11 Beta Testing Continues
                Kermit News #5
                The Old Curiosity Shop
            MS-DOS Kermit vs Twincom 9600/V42.bis
            Modem Initialization in  MS-DOS Kermit
         The Wonders of Kermit 0.98(63) and One Little Grouse

Digest submissions may be sent to [e-mail] or
[e-mail].  Requests for addition to or deletion from the
Info-Kermit subscriber list should be sent to [e-mail] or
[e-mail].  These messages must be of the form:

  SUBSCRIBE I-KERMIT <your-personal-name>    (To start a subscription)
  UNSUBSCRIBE I-KERMIT                       (To cancel a subscription)
  REGISTER I-KERMIT <your-personal-name>     (To correct your name)

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.1), IP host number 128.59.39.2.  Login as user anonymous
(note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired
files.  The Kermit files are in directories kermit/a, kermit/b, kermit/c,
kermit/d, and kermit/e.  Test versions are in kermit/test.  All files in these
directories should be transferred in text (ASCII) mode.  Binaries are in
kermit/bin (use ftp in binary mode).  You can also get Kermit files over the
BITNET/EARN network; to get started send a message with text HELP to KERMSRV,
the Kermit file server, at host CUVMA.  For detailed instructions, read the
file kermit/a/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, 30 Aug 1991 12:00 EDT
>From: Christine M Gianone <[e-mail]>
Subject: MS-DOS Kermit 3.11 Beta Testing Continues
Keywords: MS-DOS Kermit 3.11, TCP/IP

Reports on the beta release of MS-DOS Kermit 3.11 continue to pour in to
Professor Joe R. Doupnik (JRD) of Utah State University.  In order to take
full advantage of these reports and produce a solid official version, the
testing period will continue for a few more days.  The final release is
expected by the end of next week.

The new files will remain in kermit/test/ms* on watsun.cc.columbia.edu, and in
T:MS*.* on KERMSRV at CUVMA on BITNET/EARN until then.  Convert the MSTIBM.BOO
file into MSTIBM.EXE with any of the MSBPCT.* programs available in kermit/a
or kermit/bin, or from KERMSRV.  On the Internet only, the binary MSTIBM.EXE
program is available via binary-mode FTP from kermit/bin/mstibm.exe.  FTP
users: remember -- transfer files from the kermit/bin directory in binary
mode, transfer all files from all the other directories in text (ASCII) mode.

Source code will appear with the final release.

Once again we offer our deepest thanks to Joe for his skill and stamina
to make this new version of MS-DOS Kermit available.

------------------------------

Date: Fri, 30 Aug 1991 12:00 EDT
>From: Christine M Gianone <[e-mail]>
Subject: Kermit News #5
Keywords: Newsletter

Kermit News #5, our paper newsletter (ISSN 0899-0309), will be published in a
couple months.  If you received Kermit News #4, or if you ordered Kermit
material from us since June 1990, you're already on the mailing list.  If you
want to be added to the mailing list, send in your postal address.  Library
serials collections are encouraged to subscribe too.  No cost!  If you haven't
seen Kermit News before, copies of the last three issues are available online
as kermit/e/news*.* (NEWS*.* from KERMSRV).

If you would like to publish an article in Kermit News #5, please send it in!
We're looking for stories about interesting ways you or your organization are
using or benefitting from Kermit, technical articles, reviews, and anecdotes.
Articles should be about 500 words (rough guideline, we're not strict).  The
deadline is October 1, 1991.

------------------------------

Date: Sat, 24 Aug 91 01:19:23 MEZ
>From: "Gisbert W.Selke" <[e-mail]>
Subject: The Old Curiosity Shop
Keywords: MS-DOS Kermit and Arithmetic, PRODUCT Macro, Arithmetic

; File ARITHMET.INI
; Arithmetic for MS-DOS-Kermit!
; Gisbert W.Selke, Aug 1991.
; Share and enjoy.
;
; This collection of macro definitions for MS-DOS Kermit 3.10 (or later)
; was prompted by Chris Gianone's remark:
; "Meanwhile, creative Kermit users will no doubt find their own uses for
; [the PRODUCT macro]". (Using MS-DOS Kermit, 2nd ed., p 182)
;
; Having done some math, I think I *know* what a product is...
; Given that Joe D. has made Kermit with its script language a universal
; Turing machine...  There you are.
;
; TAKE this file from the MS-Kermit> prompt; then, you can do calculations:
; tadd  <number1> <number2> <...> : show sum of numbers
;                                   ex: tadd  15 17    yields 32
;                                   ex: tadd  15 17 19 yields 51
; tmult <number1> <number2> <...> : show product of numbers
;                                   ex: tmult 11 13    yields 143
;                                   ex: tmult 2 3 4 5  yields 120
; tfact <number>                  : show factorial of number
;                                   ex: tfact 5        yields 120
; Macros used internally are explained below.
;
; More importantly, when you're in CONNECT mode and your host sends a
; sequence like "ESC [ 15;7 ~", the product of the two numbers will
; appear on your screen.
;
; Remark: Multiplication can be implemented more efficiently. This is
;         left as an exercise for the reader. So are FFT and primality
;         testing for large integers.
;
; Uses variables \%a..\%e as arithmetic registers and for passing results.
;
; Elementary operations:
; Increment one-digit number (\%1) by 1; result in \%r, overflow in \%o:
def inc1  def \%o 0,if = \%1 0 def \%r 1,if = \%1 1 def \%r 2,-
if = \%1 2 def \%r 3,if = \%1 3 def \%r 4,if = \%1 4 def \%r 5,-
if > \%1 4 inc1b \%1
; internal macro for inc1:
def inc1b if = \%1 5 def \%r 6,if = \%1 6 def \%r 7,if = \%1 7 def \%r 8,-
if = \%1 8 def \%r 9,if = \%1 9 def \%r 0,if = \%1 9 def \%o 1
; Increment the number in registers \%a..\%e by 1:
def inc5  inc1 \%e, ass \%e \%r,if = \%o 0 go e,inc1 \%d, ass \%d \%r,-
if = \%o 0 go e,inc1 \%c, ass \%c \%r, if = \%o 0 go e,inc1 \%b,-
ass \%b \%r, if = \%o 0 go e,inc1 \%a, ass \%a \%r,:e

; Split multi-digit number into digits, result in \%a..\%e:
def split def \%a 0,def \%b 0,def \%c 0,def \%d 0,def \%e 0,-
if = \%1 0 go e,set cou \%1,:l,inc5 \%a \%b \%c \%d \%e,if cou go l,:e

; Add \%1 to number in \%a..\%e:
def add1  if = \%1 0 go e,set cou \%1,:l,inc5 \%a \%b \%c \%d \%e,-
if cou go l,:e
; Add two numbers; result in \%a..\%e:
def add   split 0,if > \v(argc) 1 split \%1,if > \v(argc) 2 add1 \%2,-
if > \v(argc) 3 add1 \%3,if > \v(argc) 4 add1 \%4,-
if > \v(argc) 5 add1 \%5,if > \v(argc) 6 add1 \%6,-
if > \v(argc) 7 add1 \%7,if > \v(argc) 8 add1 \%8,-
if > \v(argc) 9 add1 \%9

; Multiply number in \%a..\%e by \%1; result in \%a..\%e:
def mult1 set cou \%1,ass \%9 \%a\%b\%c\%d\%e,if > \%1 0 go s,split 0,-
go e,:l,add1 \%9,:s,if cou go l,:e
; Multiply two numbers; result in \%a..\%e:
def mult  split 1,if > \v(argc) 1 split \%1,if > \v(argc) 2 mult1 \%2,-
if > \v(argc) 3 mult1 \%3,if > \v(argc) 4 mult1 \%4,-
if > \v(argc) 5 mult1 \%5,if > \v(argc) 6 mult1 \%6,-
if > \v(argc) 7 mult1 \%7,if > \v(argc) 7 mult1 \%8,-
if > \v(argc) 9 mult1 \%9

; Time-honoured practice: a factorial routine:
def fact  split 1,if = \%1 0 go e,set count \%1,:l,mult1 \v(count),-
if cou go l,:e

; user interface macros: calls for macros above, plus display of result:
def fatal echo Error: \%1\13, def \%1, stop      ; error handler
def tinc1  inc1 \%1,echo \%o\%r                  ; ex: tinc1  5
def tinc5b inc5b \%1 \%2 \%3 \%4 \%5,echo \%a\%b\%c\%d\%e
                                                 ; ex: tinc5b 1 2 3 9 9
def tinc5  split \%1,inc5 \%a \%b \%c \%d \%e,echo \%a\%b\%c\%d\%e
                                                 ; ex: tinc5 99
def tsplit split \%1,echo \%a\%b\%c\%d\%e        ; ex: tsplit 12399
def tadd   add  \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9,echo \%a\%b\%c\%d\%e
def tadd1  add1 \%1,echo \%a\%b\%c\%d\%e         ; ex: split 17, tadd1 15
def tmult1 mult1 \%1,echo \%a\%b\%c\%d\%e        ; ex: split 13, tmult1 7
def tmult  mult \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9,echo \%a\%b\%c\%d\%e
def tfact  if not = \v(argc) 2 fatal {TFact takes exactly 1 numeric -
argument},fact \%1,echo \%a\%b\%c\%d\%e
; Multiplication per PRODUCT macro:
def product   mult \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9,-
askq \%9 Result is \%a\%b\%c\%d\%e\59 hit RETURN:,connect
; Factorial:
def factorial if not = \v(argc) 2 fatal {Factorial takes exactly 1 -
numeric argument},fact \%1,askq \%9 Result is \%a\%b\%c\%d\%e\59 -
hit RETURN:,connect
; End of MS-DOS-Kermit arithmetic routines.

\Gisbert

[Ed. - Gisbert, you have done a fine job of demonstrating the power, elegance,
user-friendliness, and ease of use of MS-DOS Kermit's script programming
language!  This breakthrough makes cryptic programming languages like C,
Fortran, and BASIC -- not to mention hand calculators -- totally obsolete.]

------------------------------

Date: 16 Aug 91 20:03:50 GMT
>From: [e-mail] (LIAM GUMLEY)
Subject: MS-DOS Kermit vs Twincom 9600/V42.bis
Keywords: MS-DOS Kermit, Modems

G'day people.

This is kind of a software question as well but I figured this was the best
place to post.

I have just installed a Twincom 9600/V42.bis modem in my 386.  I have been
using Kermit for a while with my previous 2400 baud modem, and was hoping to
continue using it with this modem.  However I cannot get kermit to 'wake-up'
the modem with the AT command.  I tried COMMO 4.52 for the same purpose and
it worked just fine with no special setup.

Scenario:

386 booted with 'clean' MSDOS 4.01 - no config.sys or autoexec.bat.
Modem has had dip-switches changed from 246 to 135 - to set COM1 and IRQ4.
No changes have been made to the modem NVRAM setup (factory defaults).
MS-Kermit 3.10 started with no initialization file.
Kermit commands are

set port 1
set speed 38400
connect

Now when I type AT there is no response.  If I start up COMMO, I get a
response with AT immediately.  If I dial with COMMO and get the modem
on-line, I can do a warm re-boot, and Kermit will then talk to the modem
normally (as far as I can tell).

So I figure there must be something that Kermit is not doing correctly
in sensing COM port speed or something.  I have tried all the
SET PORT and SET COM1 options that the Kermit beware file suggests, but
have had no luck.

Okay, I could trash Kermit and use COMMO.  But I want to use kermit if
possible.

Cheers,
Liam.

Liam E. Gumley
Research and Data Systems Corporation              Disclaimer:
Greenbelt MD, USA                                  Opinions I express here are
[e-mail]                           my own, not the company's.

[Ed. - Liam sent this later: "I have some good news.  I was playing with the
modem again this morning, and I thought "Why not try the DIAL script
(hayes.scr) you supplied with MS-Kermit 3.10?"  So I shut the computer down,
re-booted, started up kermit, then did a

  DIAL whatever

and it came back with:

  Error: Turn on or connect your modem

BUT within a second, it had woken up the modem, and was dialing the number.  I
changed hayes.scr to have the speed=38400 and to do ATDT tone dialling.
Kermit now works fine!  I can exit, and re-enter Kermit as usual.  I guess
that the initialization string output in HAYES.SCR is what does the good deed.
So it looks like things are working as they should.  Thanks again for your
very prompt reply.  I've been using Kermit for a few years now because it's
the only program I know that maps the DEC-VT keypad satisfactorily - once you
get used to it you don't want to change.  Heck, I have the little white and
gold DEC keypad stickers on my PC keyboard!]

------------------------------

Date: Wed, 21 Aug 1991 10:02:38 -0500 (CDT)
>From: Kathy Kothmann <[e-mail]>
Subject: Modem Initialization in  MS-DOS Kermit
Keywords: MS-DOS Kermit, Modems

We have an MS-DOS Kermit question which, although I have consulted
Christine Gianone's book on MS-Kermit, I cannot locate the answer.  I
hope the following excerpts will explain.

On Tue, 20 Aug 1991, Peter Ferrara wrote:

 > > Where does the initialization command go for setting up ms-kermit.  I am
 > > trying a VIVA 2400bps modem and can't get kermie baby to accept it.
 > > Its initialization command is ATE1V1X4QO&C1&D2 S7=255 SO=O^M
 > > pferrara@tenet

To which I responded:

> > Two suggestions:  First - edit the mskermit.ini file and put it in
> > there.
> > But a better alternative is to go ahead and type connect and get into
> > terminal mode and then type at <Return>.  Then type that long
> > initilization string and press <Return>.  Then type ATDT phonenumber.
> >
> > I think there's a way to customize the kermit files so that it will do
> > that for you... will check the manual I bought on MS-Kermit and see.
> > Kathy

And Peter answered this morning with:

> Thanks... I appreciate any help.  it seems that our ms-kermit version is
> generic and has a real difficult time accepting the "cheap" modems.
> Hope to hear from you soon.

NOW - I checked the .INI file and couldn't find anyplace to enter that
lengthy initialization string nor could I see how to get kermit to enter
it after typing CONNECT  (which is where I thnk it belongs).  What is
the easiest way for Peter to get that string sent to his modem?

We surely would appreciate some assistance.  If there is someone else we
should write, please let us know.

THANKS,
Kathy Kothmann
[e-mail]

[Ed. - Look at MSIHAY.SCR (which is normally renamed to HAYES.SCR).  The
following sends the modem initialization command.  Change it to whatever
is needed:

  output ATQ0V1X1\13              ; Send AT, use word result codes.

See your modem manual for details.]

------------------------------

Date: Wed, 21 Aug 91 17:42 BST
>From: Alan Grafen <[e-mail]>
Subject: The Wonders of Kermit 0.98(63) and One Little Grouse
Keywords: Mac Kermit

Dear Kermit People,
    I've just started using Kermit 0.98(63) for the Mac, and its wonderful.
Its cutting and pasting is extremely useful - no mainframe user can afford
to be without facilities of this kind.  BUT for some reason the clipboard is
private to Kermit.  I would like to cut from the Kermit window, and paste
into a word processor; and then cut from the word processor and paste into
the Kermit window.
    I'm sure this was not intended - and that other people have pointed this
out.  Please add my voice to those asking for a Mac-wide clipboard in the
next release.
    Kermit is a tremendous public service - please do not construe my letter
as a complaint.  Keep up the good work.
                                      Best Wishes,
                                         Alan Grafen

[Ed. - This problem should be fixed in the next release.  Unfortunately, we
are not quite sure exactly when that will be.  Watch Info-Kermit for
announcements.]

------------------------------

End of Info-Kermit Digest
*************************

From cmg  Mon Sep 16 16:32:45 1991
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA20318; Mon, 16 Sep 91 16:32:45 EDT
Date: Mon, 16 Sep 91 16:32:44 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V14 #5
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Mon, 16 Sep 1991        Volume 14 : Number 5

Today's Topics:

               MS-DOS Kermit 3.11 is Released!
         New Second Edition of "Using MS-DOS Kermit"
        Kermit, TCP/IP, Packet Drivers, and the Future
           Adding TCP/IP Features to MS-DOS Kermit

Digest submissions may be sent to [e-mail] or
[e-mail].  Requests for addition to or deletion from the
Info-Kermit subscriber list should be sent to [e-mail] or
[e-mail].  These messages must be of the form:

  SUBSCRIBE I-KERMIT <your-personal-name>    (To start a subscription)
  UNSUBSCRIBE I-KERMIT                       (To cancel a subscription)
  REGISTER I-KERMIT <your-personal-name>     (To correct your name)

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.1), IP host number 128.59.39.2.  Login as user anonymous
(note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired
files.  The Kermit files are in directories kermit/a, kermit/b, kermit/c,
kermit/d, and kermit/e.  Test versions are in kermit/test.  All files in these
directories should be transferred in text (ASCII) mode.  Binaries are in
kermit/bin (use ftp in binary mode).  You can also get Kermit files over the
BITNET/EARN network; to get started send a message with text HELP to KERMSRV,
the Kermit file server, at host CUVMA.  For detailed instructions, read the
file kermit/a/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, 16 Sep 1991 14:00:00 EDT
>From: Christine M Gianone <[e-mail]>
Subject: MS-DOS Kermit 3.11 is Released!
Keywords: MS-DOS Kermit 3.11, TCP/IP, MCGA, Dialing Directory, Windows 3.0

This is to announce the final release of MS-DOS Kermit 3.11 from Professor
Joe R. Doupnik of Utah State University, and a new Second Edition of the
documentation, "Using MS-DOS Kermit" (see message below).

The major new feature of version 3.11 is its built-in support for
TCP/IP networking, adapted from parts of the Waterloo TCP package from Erick
Engelke of Waterloo University in Ontario.

Also included are script language improvements that allow for a much
improved DIAL command that can use a plain text file as a dialing directory,
and VT220 emulation to fill the gap between VT102 and VT320.  And finally, a
last-minute, down-to-the-wire improvement: support for high-resolution
Tektronix graphics on the PS/2 Model 25 and 30 MCGA video adapter.  Give the
command SET TERMINAL GRAPHICS VGA to use it (otherwise Kermit thinks the
MCGA is a CGA, and uses low-resolution graphics).

TCP/IP NETWORKING

Why add TCP/IP to Kermit?  Many people use both network and serial
connections, and until now had to switch between a Telnet program (which
doesn't support serial connections) and Kermit (which didn't support Telnet
connections).  For file transfer, the TCP/IP FTP protocol, while fast, does
not support many of Kermit's advanced features.  Kermit offers you features
not found in Telnet and FTP: a script programming language, flexible key
mapping, macros, international character set translation, and VT320
and Tektronix 401x terminal emulation.  Perhaps most important of all, now
you have a single application program and a common user interface for both
serial and network communication.

Kermit's TCP/IP and TELNET implementation takes up only about 30K of
additional program space.  It runs only over Ethernet-style packet drivers
(see Joe's article below) available from your network board vendor, or via
anonymous FTP from Clarkson University, host sun.soe.clarkson.edu
[128.153.12.3], cd pub/ka9q, use "type binary", get the appropriate zip, arc,
zoo, etc, files, use PKUNZIP, PKXARC, or ZOO on your PC to unpack them, read
the files READ.ME, MANIFEST.DOC, and INSTALL.DOC, and take it from there.
Copies are also available on watsun.cc.columbia.edu in kermit/packet-drivers
(source and documentation) and kermit/packet-drivers-bin (PC binaries).

Kermit supports downloading of its network parameters from BOOTP and RARP
servers, making it possible for all users of a corporate or campus network to
have the same initialization file -- a big plus for network managers.  Keep
your network information in a central database, rather than spread around on
scattered PC hard disks and diskettes!

Kermit's TELNET implementation automatically negotiates TELNET protocol
parameters such as local echoing, so connecting to a linemode TELNET server
(such as found on an IBM mainframe) works automatically.  However, Kermit
does not include built-in 3270 terminal emulation, so it is not (yet) a
replacement for tn3270.  But, it can be used with reverse telnet terminal
servers connected to IBM 7171 or other 3270 protocol converters.

Contrary to expectations, Kermit *can* make TCP/IP connections from within a
Microsoft Windows 3.0 Enhanced Mode window.  Kermit does not support multiple
simultaneous TCP/IP sessions, and the fact that you can run it under Windows
is not, unfortunately, an escape clause to this rule.  The packet driver only
allows one one application per protocol; this also means, for example, you
can't use Kermit and (say) NCSA telnet at the same time for TCP/IP
connections.  However, you can still have multiple copies of Kermit running,
as long as each one is using a different communication method, or a different
serial port.

Read the new help and beware files for more information about TCP/IP.

DIALING DIRECTORY AND MODEM SUPPORT

Kermit's new dialing directory is an ordinary plain-text file that Kermit's
DIAL macro searches using Kermit's new OPEN, READ, and CLOSE commands.  To
take advantage of this new feature, make sure you get a copy of the new
sample initialization file, MSKERMIT.INI, as well as the Hayes modem dialing
script program, MSIHAY.SCR (which you must rename to HAYES.SCR).  A sample
dialing directory is available as MSIDIA.TXT (which you must rename to
DIALUPS.TXT).

Kermit can also manage other types of modems besides Hayes.  Two steps are
necessary: (1) change the definition of the "_modem" variable in
MSKERMIT.INI, and (2) write a dialing script program for your modem, to
substitute for HAYES.SCR.  An example is provided for the IBM/Siemens/Rolm
CBX data phone (ROLMphone) in the file MSIROLM.SCR (which you should rename
to ROLM.SCR).  Readers are encouraged to develop scripts for other kinds of
modems and dialing methods, following the conventions used in HAYES.SCR and
ROLM.SCR, and send them in to us for distribution.

NEW FILES:

Internet anonymous ftp    EARN/BITNET
watsun.cc.columbia.edu    KERMSRV@CUVMA   Description

  GENERAL FILES

 kermit/a/mskerm.hlp       MSKERM HLP      Help file (plain text)
 kermit/a/mskerm.bwr       MSKERM BWR      "Beware File" (bugs & limitations)
 kermit/a/mskermit.ini     MSKERMIT INI    Sample initialization file
 kermit/a/mskermit.pch     MSKERMIT PCH    Sample patch file
 kermit/a/msidia.txt       MSIDIA TXT      Sample dialing directory file
 kermit/a/msihay.scr       MSIHAY SCR      Hayes modem dialing script
 kermit/a/msirolm.scr      MSIROLM SCR     ROLMphone dialing script

  EXECUTABLES

 kermit/bin/msvibm.exe     (none)          Executable Kermit program for IBM PC
 kermit/bin/msvibm.pif     (none)          Microsoft Windows 3.0 PIF file
 kermit/a/msvibm.boo       MSVIBM BOO      BOO-encoded .EXE file for IBM PC
 kermit/bin/msvgen.exe     (none)          Generic MS-DOS exectable
 kermit/a/msvgen.boo       MSVGEN BOO      BOO-encoded .EXE for generic DOS

  SOURCE FILES

 kermit/a/ms*.asm, ms*.h   MS* ASM, MS* H   Microsoft assembler source files
 kermit/a/msn*.*           MSN* *           C-language network source files
 kermit/a/msv*.lnk         MSV* LNK         Linker command files
 kermit/a/msv*.mak         MSV* MAK         Makefiles for "make"

All MS-DOS 3.11 IBM PC Kermit files have been removed from the test
directories, kermit/test/ms*.* on watsun and T:MS* * on KERMSRV.

The ".boo" files for each version are .EXE files encoded in a printable
ASCII format, suitable for BITNET, e-mail, and other nontransparent modes of
transmission.  You can decode the boo-files back into .EXE files using any
of the MSBPCT.* programs available in kermit/a/msbpct.* or MSBPCT * from
KERMSRV.  See msbaaa.hlp for details.

For a detailed description of the MS-DOS Kermit file naming conventions, see
the file msaaaa.hlp (MSAAAA HLP).  The MS-DOS Kermit implementations for
non-IBM compatibles (except the generic DOS version) have not yet been
upgraded to 3.11 level -- volunteers?

Once again, thanks to Joe for his skill, generosity, patience, dedication,
perserverence, and endurance (we're running out of adjectives for Joe!) in
putting this new MS-DOS Kermit version together and sharing it with us.  And
thanks to the beta testers who sent in such prompt and detailed reports of
problems so Joe could fix most of them so quickly!

------------------------------

Date: Mon, 16 Sep 1991 13:00:00 EDT
>From: Frank da Cruz <[e-mail]>
Subject: New Second Edition of "Using MS-DOS Kermit"
Keywords: MS-DOS Kermit 3.11, Using MS-DOS Kermit

MS-DOS Kermit 3.11 is accompanied by a brand-new revised and expanded Second
edition of Christine Gianone's book, "Using MS-DOS Kermit", Digital Press,
Bedford, MA, USA (1991), order number EY-H893E-DP, Digital Press ISBN
1-55558-082-3, Prentice Hall ISBN 0-13-952276-X.  The book includes a
5.25-inch 360KB MS-DOS Kermit 3.11 diskette.  The US single-copy price is
$34.95, up $5.00 from the first edition (not bad for 100 extra pages and 6
months work).  To order, call (USA, toll free) 1-800-343-8321.  It is also
available from Kermit Distribution at Columbia University and in software
stores and computer bookstores (where you'll recognize it easily by its new
purple cover).

A German language edition, "MS-DOS Kermit -- das universelle
Kommunikationsprogramm, Einfuehrung und Referenz", is published by Verlag
Heinz Heise GmbH & Co KG, Hannover, Germany, ISBN 3-88229-006-4, translated
by Gisbert W. Selke (proprietor of the Old Curiosity Shop from Info-Kermit
V14 #4), 5.25-inch 360KB diskette included, with many of the text files
translated into German, price 69 DM.

The new edition describes all the new features of version 3.11, including
everything that was added in versions 3.01, 3.02, and 3.10.  It has a new
chapter on local area networks (including TCP/IP); a new appendix with a
complete technical description of Kermit's terminal emulator with tables of
all the escape sequences recognized and sent by Kermit in both text and
graphics mode; expanded descriptions of many of Kermit's features, including
printer control and the script programming language, including the new
dialing directory features; an improved index.  There are also new
instructions for running Kermit under Windows and DesqView, for using LK250
keyboards, and there are many new tables, including one for Cyrillic
character sets.  The new book remains an excellent introduction (Einfuehrung)
for the novice, and it is now an even more complete reference (Referenz) for
the expert.

The first edition of "Using MS-DOS Kermit" was received with unanimous
approval by the critics.  Some samples from the book reviews:

"...one of the finest user guides, commercial, shareware, or otherwise, that
this reviewer has had the pleasure of reading."
  - Tom Nichol, Link-Up, July/August 1990 (p.8)

"An excellent introduction to computer communications, [Using MS-DOS Kermit]
explains in simple but intelligent language how to set up and get going."
"Must-read for PC buffs..."
  - Anne M. Russell, Working Woman, September 1990 (p.94)

"While the book is aimed at nontechnical readers, I highly recommend it to
all technical personnel in the computing field, particularly those who
abhore software manuals."
  - William Oblitey, ACM Computing Reviews, V32 #6, June 1991, pp.283-284

Both the English and German versions of the Second Edition should be
available in late September or early October.  Every copy sold helps support
the Kermit development and distribution effort, so don't be shy!

------------------------------

Date: Mon, 9 Sep 1991 20:38 MDT
>From: Joe Doupnik <[e-mail]>
Subject: Kermit, TCP/IP, Packet Drivers, and the Future

Release 3.11 of MS-DOS Kermit for IBM-PCs and compatibles opens a new
communications channel for Kermit: many hundreds of thousands of machines
around the world attached to the cooperative Internet network.  The lingua
franca of that channel is the TCP/IP protocol suite, including the Telnet
interactive protocol.  This is networking with a capital "N".

We have received many requests for Kermit to "talk over the Ethernet" to
other machines.  The impression held by those unfamiliar with the mysterious
art of communications is that one simply puts individual bytes on the
Ethernet much as we do with ordinary RS232-C wires.  Alas, the opposite is
true so it might be worthwhile reading the few paragraphs on this technical
matter.  Even if you know the Packet Driver story from my Novell activities
skim it for a repeat performance now underway with PD + NDIS + ODI.  After
that I'll mention some items about how Kermit handles Telnet.

Ethernet, Token Ring, and similar network transport systems are party lines
carrying traffic for many machines and using many different protocols.  To
keep the traffic flowing to the right places without ambiguity, the data --
our information -- is wrapped in administrative red tape with From: and To:
addresses and much more.  These ensembles are called packets or frames, and
their rules of construction and manipulation are aptly named protocols, not
unlike the Kermit protocol itself.

IP is one protocol, TCP is a higher-level protocol that uses IP as a shipping
agent.  Novell has the SPX and (shipping agent) IPX protocols, and so on.
Fortunately each of these can share the communications wire, time-sharing the
party line, with the others because they obey the same rules for primitive
addressing in the outermost wrapping of the packet or frame.  That's about
all they have in common: they drive on the same side of the road and they
recognize traffic lights.

The Internet is a massive voluntary interconnection of machines around the
world.  So not only do we have local addressing to do, but we have to be able
to send and receive packets through gateways to distant lands.  Interestingly,
with TCP/IP we, as people, typically use the names of the machines, but on
the wire only a numerical identification is employed.  So behind the scenes
name server machines have to quietly tell our program the number of the host
whenever we use the name.  We say NETLAB.USU.EDU but on the wire this machine
is known as 129.123.1.11, a 32-bit quantity.  As you might imagine, each
protocol has its own distinct rules about names and numbers, as if the other
protocols did not exist.  More alchemy.

What we see so far is that sending data bytes over Ethernet involves a lot of
busy work preparing packets in just the right format, with the address of
both sender and receiver and other vital administrative detail.  The wire can
carry a large variety of these packets.  This means each machine hears all
the packets, the network adapter board filters out all but those addressed to
the itself (and the broadcasts), and the machine must have code to pick out
the packets it wants and to wrap/unwrap (encode/decode) the interior shipping
instructions particular to the protocol it understands.  Serial RS232-C links
avoid all of this because there is only one machine at each end.

This brings us to a very local problem to be solved.  Our PC might wish to
use several protocols simultaneously.  For example, a NetWare (or StarGROUP
or PATHWORKS) file server is used to provide file service and we also want to
use TCP/IP Telnet to log onto a remote machine in Logan, Utah (Logan is
always "remote", no matter how close to it one may be).  That means both IPX
and IP need to share the Ethernet (or Token Ring, etc) communications board,
or we will need a board per protocol.  Thus the problem is: what hardware or
software will we need to use two or more protocols simultaneously?

Until a couple of years ago the solution to the problem was to purchase a
network adapter board for each protocol in each client machine.  Software of
one protocol attached to a board and knew how to converse with it (that's a
ticklish job known as being a device driver).  Pretty soon there were lots of
different boards, and one needed to buy software tailored for each one.  In
many cases, with only one board we had to reconfigure and reboot one's PC in
order to switch among different networking applications.

FTP Software Inc. of Wakefield, MA, USA, a vendor of PC-based TCP/IP
programs, soon went bananas trying to write drivers for each new Ethernet
board on the market.     They wisely decided that what was needed was a small
piece of code, called a Packet Driver, which did all the board-specific
functions yet provided a standardized interface (a virtual board) to the
application software.  They wrote the Packet Driver (PD) Specification, made
it public, and suggested that board makers write their own Packet Drivers so
that FTP Inc and other software houses could get on with their primary task
of creating useful communications programs (see John Romkey's recent article
in BYTE magazine).

More came of this than they may have realized.  Two aspects make Packet
Drivers very popular.  One is that the programs are tiny, only about 2.5KB,
and "relatively easy" to write.  Thus software vendors can provide a PD
interface as yet one more choice of board and save many tens of thousands of
dollars of development effort per product per year, per vendor.  That was
FTP's intention too: save internal resouces.  We benefit by lower software
production costs.

The second benefit is greater from the perspective of users (vs vendors).
That is, the PD specification permits several protocols to call upon it, the
owner of a single board, and each receives only the packets it wants.  The
requesting program thinks it owns a whole board.  So a user can run several
non-competing protocol stacks (networking software systems) at the same time,
each asking for different kinds of packets, yet using only one physical
network adapter.  For example, Kermit can send a file from a Novell file
server to a TCP/IP host, using a single Ethernet board.  Now we are getting
somewhere!

The demand for Packet Drivers became large quickly.  Individuals around the
world started writing them because board vendors were too slow.  Russel
Nelson, then at Clarkson University, established a clearing house for
user-written Packet Drivers and made them available at no charge.  Oh boy,
free and available now, available even across the network via anonymous FTP.
A personal observation is that the general public, or at least a broadly
based non-commercial group, is needed to make a standard take root and
prosper; individual companies have their own territory and traditions to
contend with.

In the interests of completeness I need to mention two roughly similar
systems that arose after Packet Drivers.  The first is NDIS, Network Driver
Interface Specification, by 3Com and Microsoft.  NDIS performs the same
functions as a Packet Driver, and a few more.  NDIS programs are entirely
commercial endeavors at present and all are much much larger than Packet
Drivers.  The most recent addition to the business is Novell's Open Datalink
Interface, ODI, also commercial presently and sized between PDs and NDIS.
ODI includes more features that the other two.  NDIS is used by Lan Manager
systems (DEC PATHWORKS, AT&T StarGROUP, 3Com 3+Open, and others); ODI is used
only by Novell NetWare at this time.  It appears that all three will live
side by side for some time to come.  But what about this side by side stuff;
didn't we just solve that for the network adapter case?

Now a new question arises: Can I run TCP/IP with a Packet Driver interface for
the program (say Kermit) together with AT&T StarGROUP together with NetWare?
Golly, will demands ever end?  The answer is: it can be done, easily!  FTP
Software, again, wrote a small program called DIS_PKT, and I expanded on their
effort with a program of the same name.  DIS_PKT sits on top of NDIS and
provides a Packet Driver interface for programs that want to communicate this
way, and it allows NDIS-style programs to use NDIS simultaneously.  Dan
Lanciani of Harvard has a preliminary program called ODIPKT that lets Novell's
ODI material sit on top of a Packet Driver, and Don Provan of Novell has
another named PDEther.  These little programs are given the trade name of
"shims", and for many of us they are worth their weight in gold (saved from
buying more LAN adapters, which if you recall, is where we came in).

Well, that was an educational diversion.  Back to TCP/IP in MS-DOS Kermit.
TCP/IP is a mature protocol with many many features.  Telnet is a protocol
sitting on top of TCP/IP which provides an error-checked terminal-like
communications pathway to a host.  The software