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

Text File | 2020-01-01 | 407KB | 9,008 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--