[fa.info-kermit] Info-Kermit Digest V3 #18

SY.FDC@CU20B.CC.COLUMBIA.EDU (Frank da Cruz) (09/13/85)

Info-Kermit Digest         Thu, 12 Sep 1985       Volume 3 : Number 18

Today's Topics:

        Announcing LM-KERMIT for Lispmachine Lisp Environments
                     Kermit Diskette Distribution
           HP110 Kermit Binaries & MSIBMP.BOO Name Problem
       NEC PC8800 (not 8001), APC III, & other Japanese Kermits
                       Kermit and the Far East
          Kermit and the European Packet Switching Services
                 Kermit on X.25 and Similar Networks
                         Kermit over Networks
                        CMS Kermit with 7171's
           Behaviour of MS-Kermit 2.28 on a COMPAQ Portable
                 Kermit for Exxon Office Systems 500?
                  Kermit for Cromix and the NCR DMV?
                  MS-DOS Kermit for the Gavilan PC?

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

Date: Wed, 11 Sep 85 19:04:27 EDT
From: George J. Carrette <GJC@MIT-MC.ARPA>
Subject: Announcing LM-KERMIT for Lispmachine Lisp Environments

                              LM-KERMIT
               KERMIT and terminal emulation capability
                   for ZetaLisp based lispmachines.

LM-KERMIT was implemented by Mark David of LMI (Lisp Machines Inc).  The
use of KERMIT on a lispmachine can fill the gap between sophisticated (and
expensive) networking hardware and software available on lispmachines and
the other extreme, NO NETWORKING.  What we found is that many mainframe/
minicomputer installations take a long time to purchase and install
something like ethernet TCP-IP, but that KERMIT shows up almost everwhere,
already installed or in some users directory.

There are presently available two versions:

* bundled with the LMI-LAMBDA. It supports terminal emulation, KERMIT,
  and serial connections via RS-232, TCP-IP (TELNET), etc. Also
  provided is a HOST/MAINFRAME emulation capability so that PC's
  can log into the machine and use SERVER mode.

* A port to the Symbolics 36xx machines done by Mark Ahlstrom of Honeywell.
  It supports terminal emulation, KERMIT, and serial connections via
  RS-232. 

The source is conditionalized in the usual manner, #+LMI, #+SYMBOLICS.
There are a few #+TI conditionalizations although they have not been
tested. A user of the TI (Texas Instruments) Explorer should be able to
bring LM-KERMIT up by changing most of the #+LMI conditionalizations to
#+(OR LMI TI).

A word about the programming style used.  Don't expect anything exemplary.
Parts of the code are a quick hack off of KERMIT.C, and much of the window
system code is a mix of "doing while learning" combined with later added
sophistication and hair. Compiling the source gives style warnings of
various severities on both the LMI and Symbolics machines. However, the
number of phone calls I've been getting on this has forced us to either
tell people to go away or provide what we have now. The port that Ahlstrom
did to Symbolics Release 6.0 was also of the "conditionalize into the
source the equivalent Symbolics function name or feature" rather than the
other more slow route of "rewrite things to use mainline Common-Lisp
functions."

However, now that it is out people will no doubt be improving things.

-gjc

[Ed. - The files are in KER:LM*.*, available via anonymous FTP from CU20B.]

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

Date: Thu 12 Sep 85 12:43:33-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit Diskette Distribution

As anyone who has received a Kermit tape knows, bootstrapping the
microcomputer versions from the tape is a tricky, frustrating business.
It's even trickier if you don't have a computer with a tape drive.  To ease
the pain, we are preparing to make it easier for people to get Kermit
programs on diskette; we expect to be able to distribute IBM PC and Apple
Macintosh diskettes ourselves, and we'd like to compile a list of other
sources for diskettes or other "native media".

If you know of a user group or other organization that distributes Kermit
on native media for a particular system (e.g. a Heath-89 user group, a
TRS-80 user group, etc), please send me the information that would be
needed to order Kermit from that organization -- Address, pricing, order
number, etc, plus phone number (so I can verify the information and their
willingness to act as distributor).  Also, if you belong to a user group
that could be distributing Kermit but isn't, maybe you could submit it.
Individuals are also welcome to volunteer to distribute diskettes -- as
some already have been doing for the Apple II and Commodore 64 -- but when
addresses and ordering information are published, the demand might exceed
the ability of a single individual to meet it.

Of course, any person or group that distributes Kermit should not be doing
it for profit; the cost should be designed only to recover expenses for
media, postage, packaging, etc, plus a little margin to allow for expansion
when demand outstrips capacity.

P.S. If you can't reply by netmail, send it to me at

	Columbia University
	Center for Computing Activities
	612 W. 115th Street
	New York, NY  10025

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

Date: Wed 31 Jul 85 19:25:38-PDT
From: Jim Lewinson <a.Jiml@SU-GSB-WHY.ARPA>
Subject: HP110 Kermit Binaries & MSIBMP.BOO Name Problem

According to the documentation, KER:MSIBMP.BOO is supposed to be
MSIBMPC.BOO.  I suppose it got truncated to make it 6 characters, but
AAFILES.HLP should be updated.

[Ed. - Thanks for pointing this out, will change AAFILES.HLP.]

Also, you find an (old) .EXE file for the HP-110 MS-DOS kermit on
[SU-GSB-WHY] WHY:<KERMIT>MSHP110.EXE.  It is based on an old version of the
source code, and I'm not sure how well tested it is, but maybe it will help
someone more than nothing.  Maybe when I get back to the west coast I can
get someone working on rebuilding it with the latest sources.

					Jim

[Ed. - Thanks.  The 8-bit binary .EXE file is now available as
KB:MSHP11.EXE, and a hex encoding (straight two-hex-digits per 8-bit byte)
is in KER:MSHP11.HEX.  There is also source and documentation which may or
may not correspond to the binaries in KER:MSXHPX.*.]

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

Date: Fri 6 Sep 85 22:33:03-PDT
From: Ronald Blanford <CONTEXT@WASHINGTON.ARPA>
Subject: NEC PC8800 (not 8001), APC III, & other Japanese Kermits

The NEC 8001 Generic Kermit-80 patch had a slight error, not in the patch,
but that the machine is in fact the NEC PC8800.  I got confused by the
multiplicity of models I deal with.  (I don't believe there is an 8001.)

As for the offer of source for Japanese computer Kermits, the NEC PC8800
has been extensively sold in this country so that source may be useful.
The PC9800 is sold here (with differences) as the APC III, which supports
only MS-DOS, making a CP/M-86 Kermit of no use.  I don't know about the
other models mentioned.

I received an MS-Kermit system module for the APC III (MSXAPC3.ASM) from
someone at Virginia Tech (VPI&SU).  I haven't seen it included in your
lists, so I wonder if you ever got a copy.  It seems to work acceptably
with version 2.28.  I can make it available if you wish.

-- Ron

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

Date: Sat, 07 Sep 85 16:50:22 cet
From:  ZDV626%DJUKFA11.BITNET@WISCVM.ARPA
Subject: Kermit and the Far East

There are some Fujitsus and NECs over here in Germany.  I would appreciate if
you could put at least the MS-DOS version on CUVMA.

I have requested Mr. Murakami to send it direct, but I don't know, really if it
will work. (usenet-BITNET)

Eberhard W. Lisse

[Ed. - I tried too, but got mailer replies back with messages like "Too
many hops"...]

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

Date: Sat, 07 Sep 85 16:21:39 cet
From:  ZDV626%DJUKFA11.BITNET@WISCVM.ARPA
Subject: Kermit and the European Packet Switching Services

I have no problems at all with the European packet switching service.
I have had no trouble on the Datex-P after setting both Kermits to

         SET PARITY EVEN

I have used the following hardware:

    IBM-PC     DOS 2.11 KERMIT 2.28
    OSBORNE 1  CP/M 80  KERMIT 4.05
    RAINBOW    DOS 2.?? KERMIT 2.26
    VAX 11/780 VMS 3.7
                   4.1  KERMIT 3.0.055
                               3.0.066.
    CYBER 175   NOS     KERMIT ???

    IBM         VM/CMS  KERMIT 2.??

( If I dial my BITnet host [the IBM] through Datex-P I have to set
  my local parity to even. I don't set anything on the IBM.

  If I do it from any machine through at the Technical University
  or from the University Hospital I have to set the local parity to
  MARK.

  This indicates that Datex-P forces the parity to EVEN.

  I can't get our PDP-11/44 RMS-X11M with the new KERMIT to file
  transfer.  CONNECT works, but now way of getting one single packet
  over to the IBM or back.  Doesn't bother me though, as I'm doing
  the file transfer with the VAX anyway due to a faster line.)

[Ed. - I believe newer versions of PDP-11 Kermit handle IBM communications
a little better.]

Same thing works for Telenet I am told by LBAFRIN@CLEMSON.CSNET who
had a mail the other day.

Eberhard W. Lisse <zdv626%djukfa11.bitnet@wiscvm.arpa>

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

Date: Wed, 11 Sep 85 11:15:18 BST
From: "Chris.K.Now-and-Then" <cjk@ucl-cs.arpa>
Subject: Kermit on X.25 and Similar Networks

     Peter Bendall's suggestion (infodig 16) of substituting BEL (07) for
SOH (01) as Kermit start-of-packet is an interesting kludge, but not quite
the canonical way of dealing with the problem (of how to work Kermit across
text-line-oriented networks).  Admittedly almost any (terminal) network will
pass BEL, for obvious reasons; but bridges, PADs etc. often feel free to
add BELs if they see fit.  What about a PAD which stuck a BEL into any
"overlength" line?

     I regularly Kermit large files over UK JANET, which uses XXX (X.3,
X.28, X.29) above X.25.  In normal terminal (line) mode, SOH will be
stripped.  The easy answer is to switch to character (transparent) mode, in
which case all control characters are passed through "as sent".  For XXX
this is in fact overkill, since there are parameters to specify which
control chars are to be passed; but it is straighforward and always
supported on the user interfaces; it also switches off local echo, which is
desirable.  In principle character-mode could result in Kermit packets being
sent as several blocks each; this does not in fact happen when using a
standard JANET PAD, due to the forward-on-timeout strategy employed.

     I believe that every terminal network protocol includes a transparent
mode, so the solution is generally applicable.

                                        Chris Kennington.

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

Date: Sat, 7 Sep 85 13:52:05 edt
From: Mike Ciaraldi <ciaraldi@rochester.ARPA>
Subject: Kermit over Networks

Two messages in Info-Kermit digest volume 3, number 14 asked about file
transfers over Milnet and Telenet.  I haven't used either of these, but the
symptoms sound like a problem I have run into before.

Sometimes you are able to log on, start up Kermit on the remote machine, and
give it commands like "DIR" with no trouble.  But when you try to do a file
transfer your local machine just sits there until it times out, as if no
packets are being received either way.

When this has happened to me, I can usually get it to work by EXPLICITLY
setting the parity of both Kermits, local and remote.  Naturally, if your
communications channel (e.g. Telenet) enforces a particular parity (e.g.
even), you have to set the Kermits to match each other and the comm channel.

Parity being slightly off doesn't seem to affect commands like DIR, but file
transfers and other things that use packets cannot handle it because the
checksums, 8th-bit prefixing, and so on are thrown off.  Thus no packets get
through.

Mike Ciaraldi
ciaraldi@rochester
seismo!rochester!ciaraldi

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

Date: Tue, 10 Sep 85 09:03:52 EDT
From: ostrove@umd5 (Steve Ostrove)
Subject: CMS-KERMIT with 7171's

We are in the process of testing out our 7171's with CMS.  Although I haven't
done extensive testing, yesterday I transfered a 65K file using KERMIT-MS
on one side and KERMIT-CMS on the other (versions 2.28 and 2.01 respectively).
The transfer was using a packet size of 94 (default).  I had no problems.
It would seem therefore that the problem with packet size and TSO, may be 
a problem unique to TSO and the 7171's.  I will attempt to do more extensive
testing of them soon.

On a different note.  When we put KERMIT-CMS into server mode, it does not
seem to respond to any terminating command with the exception of FINISH.
Neither LOG or BYE works.  Is this normal??

Sincerely,
Steve Ostrove
User Services Staff
The University of Maryland Computer Science Center
Ostrove@umd5.ARPA

[Ed. - Thanks for the information.  No, CMS Kermit is supposed to log itself
out upon receipt of a BYE request, and it does so nicely on our CMS system.
No one here can think of a reason why it would fail to do so.  Can anyone
else?]

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

Date: Mon, 9 Sep 85 13:40:34 BST
From: Ljwu@ucl-cs.arpa
Subject: Behaviour of MS-Kermit 2.28 on a COMPAQ Portable

     I have encountered a slight bios incompatability between a real IBM
PC/XT and a "Compatable" Compaq Portable.  In short, MS-Kermit v2.28 with
bug fixes as advertised in .BWR file work fine on the XT.  The problem,
however, is that when sending or receiving files, the Compaq displays a
blank inverse video mode line with a single spurious character ('s') above
the transfer status displays.  The mode line displayed during connection
appears normally.

     The information normally contained in this mode line is rather
important in that it gives the user information on how to abort an active
file transfer.  After some digging, I traced the problem to the routine
'putmod' in MSXIBM.ASM.  As I don't have documentation on the bios
interfaces I did a simple backout to the putmod routine in version 2.27.
Below are the affected lines:

Original version 2.28 code:
             call    poscur
             pop     si              ; get message back
     putmo1: lodsb                   ; get a byte
             cmp     al,'$'          ; end of string?
             je      putmo2
             mov     ah,14           ; write to screen
             mov     bx,07000h       ; inverse video, page one
             int     bios
             jmp     putmo1
     putmo2: ret                     ; and return
     putmod  endp

Version 2.27 backout:
             call    poscur
             pop     dx              ; get message back
             mov     ah,prstr
             int     dos
             ret
     putmod  endp

        This fix works fine for the COMPAQ.  On a real PC, however, the
information line is displayed in normal video.  At least this backout
provides the user with the necessary information in all cases.  Has anybody
else experienced this anomolous behaviour with a Compaq or have an
explanation for the incompatability?

                        -- Les J. Wu <ljwu@ucl-cs.arpa>

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

Date: Fri, 6 Sep 85 15:19:48 edt
From: Bob Sutterfield <sutter%ohio-state.csnet@csnet-relay.ARPA>
Subject: Kermit for Exxon Office Systems 500?

The secretary across the hall has recently been blessed with an Exxon Office
Systems 500 Series word processor.  It apparently crunches words nicely
enough, but its facilities to talk to the outside world are severely
limited.  It has some sort of asynchronous communications software, but this
won't do the job for us.

I don't know what kind of processor it has, nor what operating system it
runs.  We really need to get several hundred pages of publications off this
beast, and onto a usable machine.  Does anybody know of pointers to a Kermit
for this beast?

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

Date: Mon, 09 Sep 85 03:37:14 cet
From:  ZDV626%DJUKFA11.BITNET@WISCVM.ARPA
Subject: Kermit for Cromix and the NCR DMV?

Any information regarding Kermit for Cromemco Cromixor the NCR
Decision MATE V ?

Eberhard W. Lisse  <zdv626%djukfa11.bitnet%wiscvm.arpa>

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

Date: Tue, 10 Sep 85 14:08:18 PDT
From: rich@CIT-Hamlet.ARPA
Subject: MS-DOS Kermit for the Gavilan PC?

A professor here has the Gavilan PC with the 3" drives.  Has anyone
successfully run MS-DOS Kermit on one of these, and if so, can we possibily
get a copy of the disk?

Thanks is advance,

Rich Fagen
Caltech Computing Support
rich@cit-hamlet.arpa
rich@hamlet.bitnet
(818)-356-3896

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

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