About the Kermit file-transfer protocol and
about terminal emulation under various Kermit implementations
(archives of various Usenet discussions)

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

2002:

Newsgroups: comp.protocols.kermit.misc
Message-ID: <ascn99$pl1$1@newsmaster.cc.columbia.edu>
Organization: Columbia University
Date: 1 Dec 2002 10:11:53 GMT
From: Jeffrey Altman <jaltman@watsun.cc.columbia.edu>
Subject: A Letter to the Kermit Community

1 December 2002:

Today marks the end of a significant period in my life.  For the last
eight years I have been privileged to work on and support Kermit as my
career.  I began working for Columbia University after nearly seven 
years as a Kermit user and eventually as primary developer of OS/2
C-Kermit which became the basis for Kermit 95 on Windows 95/98/ME
and Windows NT4/2000/XP.

During this time the Kermit project shipped 23 releases.  The initial
version of K95 was shipped on Oct 5, 1995 just seven months after I
joined Columbia University.  K95 was not only a port of OS/2 C-Kermit
to Windows but an attempt to make C-Kermit easy to understand for
beginners by adding a Graphic Front End and to do so in a manner that
would be inherently cross platform.

Back then our dreams were to build a front end that could be supported
on OS/2 and 32-bit Windows with the ability to easily port it to MacOS
and X-Windows.  At the time our development platform had to be selected,
Java was not even announced to the world.  (That occurred in early
August 1995.)  We selected Zinc as our cross platfrom development
environment. Unfortunately, cross platform development environments that
wrap existing OS components tend to be lowest common denominator feature
sets and result in apps that are not entirely what the end user expects.
(Java discovered this with the original AWT library and eventually
constructed the Swing library to avoid the OS dependencies.)

For Kermit, the reliance on Zinc allowed us to easily support both
OS/2 and Windows but resulted in significant compromises in features
as the years went on.  The Zinc library was not only lowest-common-
denominator but also suffered from two significant problems:

 . it is a memory and GUI resource hog

 . the authors never checked memory buffer overwrites

These two issues resulted in significant problems in pre-1.1.21
releases of Kermit 95.  First, as the number of configurable items
in the Settings Notebook increased the required GUI resource allocation
increased to more than 30% of the total GUI resources available on
Windows 95/98/ME.  This would result in unpredictable crashes.

The memory overwrite bugs were primarily caused by a failure to
allocate enough memory for path names.  The Zinc library was
originally developed to support DOS, 16-bit Windows, and OS/2.  The
8.3 filename restrictions, coupled with the limited drive space
available on those systems, resulted in short pathnames.  It seems
they never anticipated that anyone would want a pathname greater than
64 characters.  Now with today's GUIs, coupled with removal of the 8.3
restrictions, it is common for the filename alone to be 64 characters,
not even considering the rest of the pathname.  The memory overwrites
produced data corruption in the Zinc databases that stored the
Connection Configurations.  The problems became more obvious as users
switched to Windows 2000 and began to install K95 in directories with
long pathnames or across network shares access via UNC names.

For 1.1.21 and later these issues were addressed by a combination of
extensive debugging of the Zinc libraries coupled with limiting the 
number of GUI resources allocated at once.  It is due to the latter
that the Settings Notebook was broken up into separate (although 
annoying) settings pages.

I'm not going to say that the choice of Zinc was a disaster, but in
hindsight it would have been better if the decision to use Zinc could
have been put off until Java for desktop development began to
stablize.  However, waiting until mid-1997 was not an option and now
that Zinc has been deployed Kermit 95 has become dependent on its
database format.  Any attempt to migrate to something else would
require either abandoning the existing user data or re-implementing
the Zinc database format in the new language.  Neither are desireable,
nor did we ever have the resources.  The use of Zinc did succeed in
its initial goals:

  construct a GUI front end for C-Kermit that would reduce the 
  need for end users to understand the C-Kermit command language
  in order to configure and establish connections to hosts over
  a wide range of connection types; and do so on multiple operating
  systems on multiple architectures in a manner that allowed for
  database portability.  

The initial versions of K95 were shipped on OS/2 (X86) plus Windows
95/NT4 (X86,MIPS,Alpha,PPC).  We even had a PowerPC version for OS/2
but it was never publicly released since the operating system itself
was never released.  It was possible to use a single Dialer database
on multiple operating systems in multi-boot scenarios.  At one point I
had a database shared by OS/2, Windows 95, NT4, and Windows 95 (Hebrew
edition.)

Porting OS/2 C-Kermit to Windows was a challenge in itself.  C-Kermit
is a single threaded application.  OS/2 C-Kermit is multi-threaded
(separate threads for command processor, keyboard/mouse input, screen
display, and device/network I/O processing) but it can count on all
thread independent signals being delivered to the first thread in the
process.  In Windows, thread-independent signals are delivered to the
process in their own thread.  To this day I am still not satified with
the cross platform model I developed to handle events such as SIGINT.
The existing implementation works well enough for most purposes and
there have always been an endless number of new features to add to K95
such that I have never had the time to re-visit the design of this
fundamental building block.

Looking back over the last eight years it is somewhat incredible to
think about what was achieved.  In 1995, the source code for K95 was
less than 80,000 lines in total.  The executable for the Windows X86
was 786k.  For the 2.1 release the base source code over 500,000 lines
of code not including support for SRP, Kerberos, SSL/TLS, and SSH; the
k95g executable is 3566.5K.  The security protocol support adds another
1.2 million lines of source code plus almost 3MB in supporting DLLs.  

Then there is all of the documentation that was written: 88,000 lines
(the original release had 5235 lines of documentation.)  [This does
not include the "Using C-Kermit" book which Frank and Christine were
able to update only once during this time frame.  To accommodate all of
the new documentation which has been written, an updated "Using C-Kermit"
current with version 8.0 would need to be 1800 pages in length.]

I tried to look back and summarize all of the features that were added
to Kermit in the last eight years and I became overwhelmed.  There
were 35 plus terminals that were emulated; streaming Kermit protocol;
the Internet Kermit Service; all of the IETF work (TELNET AUTH SRP,
TELNET AUTH KRB5, TELNET START-TLS, TELNET FORWARD-X, PKIX, TLS,
KERBEROS 5, SSH 2, FTP AUTH TLS; TN3270 extensions; DNS SRV); UTF8
terminal support; URL hotspots; mouse event programming; Windows
Telephony; DECNET; TELNET; RLOGIN; KLOGIN; Remote COM-PORT-CONTROL;
HTTP; FTP; all of the security implementations; Bidirectional Printer
Management; the GUI release; export permission; and thousands of other
things that I just can't summarize because (to be honest) I can't
remember.  I tried to use the Internet Wayback Machine

  http://web.archive.org/web/*/http://www.columbia.edu/kermit/k95.html

but it's almost as if everything on the current k95.html page is new.

One of the greatest aspects of my work on Kermit has been that the
impact of my work has not been limited only to the Kermit product and
its users.  Through Kermit I have participated in the Internet
Engineering Task Force on numerous working groups and have either
authored or edited over two dozen Internet-Drafts and RFCs.  In
addition, I have been an active contributor to various OpenSource
projects: OpenSSL; MIT Kerberos; Tom Wu's Secure Remote Password
distribution; Peter Runestig's Secure Telnet and FTP clients and
servers; Denis Sbragion's Sredird Telnet Com-Port-Control daemon; plus
many others.  I participated as an unofficial observer in the Commerce
Department BIS advisory council meetings on export control.  Plus I was
able to work with purely commercial companies to help them ensure that
their products were compliant with protocols implemented within Kermit.

With all of this there is always more that I wish I could have
accomplished.  We never did implement TN3270/TN5250 within Kermit.
Nor did we ever port the terminal emulator to MacOS or X-Windows.  The
BeOS port never truly worked and we don't support PalmOS or Windows CE/
PocketPC devices.  The Internet Kermit Service never received wide
enough support from OS vendors such as IBM, Sun, HP, Compaq, and
RedHat.  Support for security features on VMS is still not complete.
We never got to develop a drag/drop file transfer interface for
Kermit, Zmodem, and FTP.  But overall I believe that Kermit 95 is a
very good product that in many ways probably does too much.  :-)

Unfortunately, my time to work on Kermit as a Columbia University
staff member has come to an end and it is time for me to move on to 
other endeavors, even if I am not quite sure what they will be.  

I still consider myself a member of the Kermit Project even if I am
not paid to be.  Kermit has been a part of my life for fifteen years.
It was a lab for me when I was in college and then grad school.  When
I got my first job as a developer after receiving my Master's, I
continued to work on C-Kermit eventually taking the reins of the OS/2
port from Kai Uwe Rommel.  I left that job for Columbia because the 20
hours a week I was spending on Kermit was a lot more enjoyable than
the work I did for my employer.  I can't imagine how it would be possible
for me to simply give it up now but my work on Kermit has caused me to
grow far beyond what is possible within Kermit.  Therefore, Kermit is 
going to have to become a smaller piece of my life.

My participation in open source projects such as MIT Kerberos and
OpenSSL will continue.  My participation in the IETF will continue.
Over the last year and a half I have become very interested in Peer to
Peer overlay networks and purely distributed authentication systems.
I have been active in the Project JXTA community (http://www.jxta.org)
and currently sit on its Board.  I have been actively pursuing the
creation of an IETF P2P Working Group to standardize a suite of P2P
protocols; and an IRTF P2P Research Group to study the effects of P2P
overlay networks on an Internet containing 10^14 nodes (today's
Internet has less than 10^9 nodes.)  It is my hope that my next
employeer will provide me the opportunity to continue this work.

In the meantime, I will be available on a contract basis through
Internet Access Methods (http://www.iamethods.com) /
(http://www.iamx.com) for development or consulting work on Kermit;
Peer to Peer systems; or various Security efforts.  I can be 
reached either at jaltman AT columbia.edu or jaltman AT iamx.com.

Last but not least I want to say thank you to Frank da Cruz, Max
Evarts, Christine Gianone, everyone I've worked with at Columbia
University; and all of the wonderful users that have supported Kermit
over the years most notably: Peter Runestig, Mark Zinzow, Kent Martin,
Arthur Marsh, Perry Wolfe, Robert Strickler, Greg Belenger, Clarence
Dold, Thomas Dickey, Jim Schneider, Vincent Fatica, Gene Alexander,
and everyone else whose name I can't pull off the top of my head.
Without you Kermit would not be any fun at all.

Jeffrey Altman

Volunteer Kermit Developer

-- 
 Jeffrey Altman * Volunteer Developer      Kermit 95 2.1 GUI available now!!!
 The Kermit Project @ Columbia University  SSH, Secure Telnet, Secure FTP, HTTP
 http://www.kermit-project.org/            Secured with MIT Kerberos, SRP, and 
 kermit-support@columbia.edu               OpenSSL.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
References: <ascn99$pl1$1@newsmaster.cc.columbia.edu>
Message-ID: <asdnnr$hr$1@watsol.cc.columbia.edu>
Organization: Columbia University
Date: 1 Dec 2002 14:25:47 -0500
From: Frank da Cruz <fdc@columbia.edu>
Subject: Re: A Letter to the Kermit Community

In article <ascn99$pl1$1@newsmaster.cc.columbia.edu>,
Jeffrey Altman <jaltman@watsun.cc.columbia.edu> wrote:
:
: Today marks the end of a significant period in my life...
: Looking back over the last eight years it is somewhat incredible to
: think about what was achieved...

Anyone who has been following the goings on here since 1995 knows Jeff's
key role in most of it, if only by his over-the-top devotion to 24x7
end-user support:

  http://www.columbia.edu/kermit/tsreviews.html

Jeff is an extremely talented and hard-working person; we were lucky to
have him and are unlucky to lose him.  Ironically, Jeff's main passion
over the past 5 years or so--security--is precisely what should have
sealed our success, yet the market did not respond.

Kermit 95 was one of the first, if not THE first, full-featured Windows
communication software packages to support Kerberos IV, Kerberos V, and
SSL/TLS, as well as the lesser-known Secure Remote Password, each of
which offers MANAGEABLE secure authentication and strong encryption.

But it turned out that, despite the many earlier requests for it, nobody
actually wanted *manageable* security (because it must, indeed, be managed),
and instead flocked towards SSH, which in many ways is a disaster waiting
to happen:

  http://www.columbia.edu/kermit/sshclient.html#x3.2

This was a setback for us, because instead of concentrating on GUI
development, essential not only in the mass market but also to many of
our potential large licensees, we had to drop everything and add SSH to
K95, which took a year, just so people could keep using K95 in an
environment where Telnet servers were being turned off (rather than
secured) and SSH was suddenly required for terminal connections.

We had expected that at least some of the larger corporations and
government agencies would be more serious about security.  Live and learn.


: One of the greatest aspects of my work on Kermit has been that the
: impact of my work has not been limited only to the Kermit product and
: its users.  Through Kermit I have participated in the Internet
: Engineering Task Force on numerous working groups and have either
: authored or edited over two dozen Internet-Drafts and RFCs....

Shamefully this kind of activity is no longer valued in most workplaces.
Devotion to standards and participation in their evolution rarely
contributes to the bottom line, and are increasingly discouraged if not
punished in these hard times except in the few companies that can still
afford it -- a trend which has consequences for us all.


: ...  But overall I believe that Kermit 95 is a
: very good product that in many ways probably does too much.  :-)

A common theme in the evolution of any software product.  It starts out
small and focussed; users request more features; the market makes new
demands (such as SSH); the product becomes increasingly complex and
"bloated"; eventually users begin longing for the good old days when the
product was "lean and mean".  But of course they can't go back to the
original release because it lacks certain essential features that were
added later--a different set of them for each user!

Perhaps our mistake has been to listen too closely to our users and try
too hard to please.  Other products tend to displace K95 by offering
users very little in terms of features or choices, and therefore are
perceived as easier for most people to use.

Kermit's strength, however, lies in its ability to be adaptable to
almost any setting; perhaps it is best suited to situations in which
professionals can configure it for end users -- employees or clients of
a company, the population of a university, workers in a government
agency.  This is done through its command scripting language, which
allows complex or repetitive procedures (such as EDI transactions) to be
"canned" for use by relatively unskilled workers.

I would like to think the value of this approach will become apparent as
we suffer increasingly through the labor-intensive, error-prone,
point-and-click interfaces that are coming to dominate the workplace and
drag down productivity.


: I still consider myself a member of the Kermit Project even if I am
: not paid to be.  

I can't predict how much time Jeff can devote to Kermit in the future.
Even if it's only 10% of his normal contribution, that's about a
full-time job for anybody else :-)

But let's not take this as an epitaph for Kermit 95.  We have just
released version 2.1, which is totally up to date with all the latest
Kerberos, OpenSSL, and other security libraries, and seems so far to be
quite solid.  It's easy to install and easier to use than ever.  It's
easier to get too.  As long it remains popular I'm sure Jeff won't
forget about it.  In any case, we intend to continue to develop and
support it, as we always have done.  If that changes, I'll let you know.

Kermit 95 2.1 has just now gone to press.  The new shrinkwraps--which,
for the first time, contain the secure cryptographic version of the
software -- should be available towards the end of December.  You can
preorder them at the old price starting today:

  http://www.columbia.edu/kermit/k95order.html

Thanks, Jeff.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
References: <ascn99$pl1$1@newsmaster.cc.columbia.edu>
Message-ID: <8ce22d01.0212021110.77c49d5a@posting.google.com>
Organization: http://groups.google.com/
Date: 2 Dec 2002 11:10:28 -0800
From: Dan Skinner <JDanSkinner@JDanSkinner.com>
Subject: Re: A Letter to the Kermit Community

jaltman@watsun.cc.columbia.edu (Jeffrey Altman) wrote in message
news:<ascn99$pl1$1@newsmaster.cc.columbia.edu>...
> 1 December 2002:
<snip>
A day that will live in infamy!

Jeff; a comment from a Kermit newbie.(First use August 1990).
You and Frank and all have lived up to a support model that is as
different from its competitors as C-Kermit and K95 are different from
their competitors, and that is a GOOD THING  :-)

I've tried to model my little company's products and services on your
good example, down to absurdly low prices.

How can I help you make it work, rather than How can I avoid
responsibility is a model and a style that will always be in fashion! 

THANK YOU!!!
Good Luck and Good Computing.

Best Regards^Dan.
JDanSkinner.com

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
References: <ascn99$pl1$1@newsmaster.cc.columbia.edu>
    <8ce22d01.0212021110.77c49d5a@posting.google.com>
Message-ID: <asge12$nf8$1@watsol.cc.columbia.edu>
Organization: Columbia University
Date: 2 Dec 2002 14:58:26 -0500
From: Frank da Cruz <fdc@columbia.edu>
Subject: Re: A Letter to the Kermit Community

In article <8ce22d01.0212021110.77c49d5a@posting.google.com>,
Dan Skinner <JDanSkinner@JDanSkinner.com> wrote...
:
: I've tried to model my little company's products and services on your
: good example, down to absurdly low prices.

Good luck.  It's nice to know that some people still believe in such
notions, which are largely held to be "legacy, deprecated" concepts long
ago replaced by the more up-to-date "take the money and run".

The best way to keep the old ideas alive is to not be shy about
spreading the word across our wonderful Internet.  In Kermit's case,
it's especially important since most people still believe that it hasn't
changed since 1983.  "Kermit, oh yeah, I remember that, I used in
college...  A nice little toy for its time...  What ever happened to it?"
We have a web page to refer people to when they say things like that:

  http://www.columbia.edu/kermit/kermit.html

To this day, people cling to incredibly clunky, obscure, and unsafe
methods of doing things (such as automating an FTP session) that would
be perfectly straightforward with C-Kermit or K95.  My favorite is when
someone asks how to do something involving recursive directory traversal
in Unix (deleting files, moving them, transferring them, whatever) --
something that can be done in one simple command in Kermit, like:

  delete /recursive /before:1-jan-2000 *.txt

The conversation rapidly devolves into heated arguments over the syntax
of "find" and "xargs" versus various Unix versions and shells, and then
over the ensuing week or two into insults and death threats, before it
finally veers off on some tangent, such as English versus metric units
of volume, weight, or mass as applied to bottles of beer.

We need independent Kermit users to pop up on the newsgroups when people
ask "How do I do such-and-such?" and Kermit is the obvious and sensible
answer.  Jeff and I do this a lot, but people would pay more attention
if they heard it from a variety of actual users who benefit from it in
real life.  Why should they trust us?

Yes, if you post on newsgroups you get spam.  I get tons of it.  It's
annoying, but that's all.  There are many worse things in the world,
starting with unemployment.

"Up with Common Sense!"  Our new slogan?  It's an inversion of Gracie
Allen's campaign slogan in the 1940 presidential race.  (Where is she
now when we need her?)

  http://www.geocities.com/Hollywood/Hills/1836/campaign1940.html

- Frank


 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-
 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!emory!gatech!udel!news.mathworks.com!news.alpha.net!uwm.edu
      !lll-winken.llnl.gov!sol.ctr.columbia.edu!news.columbia.edu
      !watsun.cc.columbia.edu!fdc
Message-ID: <3at022$rfc@apakabar.cc.columbia.edu>
References: <CznG7G.1ty@dorsai.org>
Date: 22 Nov 1994 14:43:14 GMT
Organization: Columbia University
Lines: 26
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Subject: Re: re-dial in kermit 3.12

In article <CznG7G.1ty@dorsai.org>, Vito Kwan <vkwan@dorsai.org> wrote:
>
> I am using MS-DOS kermit on my PC and try to find out how to re-dial
> a phone number at a certain time interval, like 5-seconds.
> Could someone please give me some hints?
>
Read the chapter on script programming in the manual?

Use any of the standard dialing scripts, which already do this?

Once again, the manual is:

  Christine M. Gianone, "Using MS-DOS Kermit", Second Edition, Digital
  Press / Butterworth-Heinemann, Woburn, MA, 1992, 345 pages, ISBN
  1-55558-082-3.  Packaged with version 3.13 of MS-DOS Kermit for the
  IBM PC, PS/2, and compatibles on a 3.5-inch diskette.

  US single-copy price: $34.95; quantity discounts available.  Available
  in computer bookstores or directly from:

    Kermit Development and Distribution
    Columbia University Academic Information Systems
    612 West 115th Street
    New York, NY  10025  USA
    Telephone: +1 212 854-3703

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.terminals,comp.sys.ibm.pc.misc
Path: utkcs2!gatech!destroyer!caen!hellgate.utah.edu!cc.usu.edu!jrd
Message-ID: <1992Oct9.142143.59575@cc.usu.edu>
References: <1992Oct5.021247.22556@samba.oit.unc.edu>
            <JT.92Oct9164708@fizyk1.fuw.edu.pl>
Organization: Utah State University
Lines: 23
Date: 9 Oct 92 14:21:43 MDT
From: jrd@cc.usu.edu (Joe Doupnik)
Subject: Re: Inexpensive Tek 4014/DEC VT220 Emulator?

In article <JT.92Oct9164708@fizyk1.fuw.edu.pl>, jt@fuw.edu.pl (Jerzy Tarasiuk)
 writes:
>>>>>> On Mon, 5 Oct 1992 02:12:47 GMT, sdoublie@med.unc.edu (Sylvie Doublie)
 said:
> (some lines deleted)
> Sylvie> connect by modem to computers at her lab. She needs the
> Sylvie> program to emulate both Tek 4014 and DEC VT220 terminals. She doesn't
> Sylvie> have much money to spend, so she'd like to get a [free or cheap]
> Sylvie> program, but an inexpensive commercial application will suffice.
> 
> 
> KERMIT can emulate Tek 4010 and DEC VT100, VT220, VT320 (at least
> version 3.11 which I use just now to write this message).
> And it at least can be tried free, get it (e.g. by FTP) and read
> docs to know if she need pay (for commercial use would need).

-----------

	All accurate except for the very last point. Kermit USE is always
free. Financial arrangements come into play when a Columbia Kermit becomes 
part of another product package offered for sale.

The Kermit Project is heavily dependent on such arrangments and on the
sale of the user's books, plus <too infrequent> donations. If corporations
were to contribute a fraction of the cost otherwise spent on a
commerical product, we could do much more, and faster too, and buyers
would still enjoy the benefits of a commercial-grade product with Tech
Support and a professionally done user's manual (Digital Press and
Prentice Hall does the publishing).

	Joe Doupnik

 ..............................................................................

 [see below for discussions of Kermit support policy]

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.protocols.kermit.misc
Message-ID: <00q6ivkjdn6f8mad9ou0pi95gk273d343a@4ax.com>
Organization: Dunwoody Georgia
Date: Sun, 27 Jul 2003 02:04:29 -0400
From: Bill <bill.loard@nowhere.org>
Subject: Word Perfect Keyboard (Frank)

Clueless!

Well I am still attempting to help a Medical Transcriber change her
connection with  Kermit to a UNIX server.  I thought she had made it
work but she wasn't that lucky and the System Person said the old
version of ProComm was the  only one that would work. 

Anyhow today I tried to log in and got to the terminal screen after
typing in the set terminal keyboard-mode wp, and as you advised
checked the terminal type on the terminal page and there is no
vt320-w!  There isn't even an option in the scroll box. I don't think
the set command is working (or I am putting it in the wrong screen!).

I have also looked through the .ini files and they seem to be similar
enough to do the simple things she needs to do (file retrieval and the
upload of her work). 

I refuse to believe that the ancient version of ProComm is the only
thing that will work!  I really thought that it was out of production
but [Symantec] still sells a version. 

She and I both are working from a template and maybe there are more
options working from scratch?

Any additional thought?

Thanks

Bill 
Atlanta 

 ..............................................................................

Newsgroups: comp.protocols.kermit.misc
Message-ID: <bfummb$q3k$1@watsol.cc.columbia.edu>
References: <00q6ivkjdn6f8mad9ou0pi95gk273d343a@4ax.com>
Organization: Columbia University
Date: 26 Jul 2003 16:01:15 -0400
From: Frank da Cruz <fdc@columbia.edu>
Subject: Re: Word Perfect Keyboard (Frank)

In article <00q6ivkjdn6f8mad9ou0pi95gk273d343a@4ax.com>,
Bill  <bill.loard@nowhere.org> wrote:
:
: [I] checked the terminal type on the terminal page and there is no
: vt320-w!  There isn't even an option in the scroll box. I don't think
: the set command is working (or I am putting it in the wrong screen!).

VT320-W would not appear in the scroll box; it's not a terminal type,
it's a keyboard mode applied to a terminal type.

: I refuse to believe that the ancient version of ProComm is the only
: thing that will work!
:
Me too.  Let's try again, step by step.  Let's assume you have a connection
to the host, and have started WordPerfect on the host.  K95 is in its
terminal screen (normally blue, but could be any color).  On the bottom
of the screen (inside the frame) is a green line with white writing, called
the Status Line, that says:

  o o o o VT320  Help: Alt-H  Command: Alt-X  (etc etc).

At this point do:

 . Alt-x (i.e. hold down the Alt key and press the X key)

 . At the K-95> prompt, type the following command:

     set terminal keyboard-mode wp

 . Alt-x again to get back to the terminal screen.

Now the Status Line should say:

  o o o o VT320-W  Help: Alt-H  Command: Alt-X  (etc etc).

and the WordPerfect Key mappings should be in effect.

To return to the regular VT320 key mapping, do:

 . Alt-x (i.e. hold down the Alt key and press the X key)

 . At the K-95> prompt, type the following command:

     set terminal keyboard-mode normal

 . Alt-x again to get back to the terminal screen.

and the "VT320-W" in the status line should revert to "VT320".

There *should* be an easier way to do this:

  Ctrl-Alt-Shift-W

is supposed to toggle in and out of WordPerfect keyboard mode.  But
for some unknown reason this does not seem to work on all PCs.

If these instructions do not cause "VT320-W" to appear in Kermit's
status line, send e-mail to kermit-support@columbia.edu, and we'll
do the detailed troubleshooting.

By the way, when you first posted this question you said you had
the "latest kermit", and I assumed by that you meant you had
Kermit 95 2.1.3.  If that's not the case and you are talking about
(e.g.) MS-DOS Kermit, then please say so.

- Frank

 ..............................................................................

Newsgroups: comp.protocols.kermit.misc
Message-ID: <bg1c04$rd7$2@blue.rahul.net>
References: <00q6ivkjdn6f8mad9ou0pi95gk273d343a@4ax.com>
    <bfummb$q3k$1@watsol.cc.columbia.edu>
Organization: a2i network
Date: Sun, 27 Jul 2003 20:17:08 +0000 (UTC)
From: dold@WordXPerfe.usenet.us.com
Subject: Re: Word Perfect Keyboard (Frank)

I wanted to wait for Frank to respond first, with a K95 entry that was more
graceful than my setup.

I made my own mapping for WordPerfect and MSDOS Kermit-3.11 to a
UnixWare box.  I was also faced with another Unix (ESIX) system that
came with bundled software and a fixed terminal type of vt100-pro,
with some mangling to fit the Procomm-of-the-day mapping.

By capturing what procomm sent to the unix system for each F key, I
was able to build my own map of what Kermit needed to send.  I probably
still have that lying around somewhere.

I looked at the Wordperfect mapping that was on the kermit site at that
time, and chose not to use it, although I don't recall why.

-- 
Clarence

 ..............................................................................

Newsgroups: comp.protocols.kermit.misc
Message-ID: <rmcaivsdj43fa90f5lu0sijkfq8i5b98dg@4ax.com>
References: <00q6ivkjdn6f8mad9ou0pi95gk273d343a@4ax.com>
    <bfummb$q3k$1@watsol.cc.columbia.edu> <bg1c04$rd7$2@blue.rahul.net>
Organization: Dunwoody Georgia
Date: Mon, 28 Jul 2003 10:38:19 -0400
From: Bill <bill.loard@nowhere.org>
Subject: Re: Word Perfect Keyboard (Frank)

Thanks! This evening was a break-through. The keyboard-mode needs to
be issued after the session is started and then the W is appended to
the terminal type. I have forgotten whether she used vt220 or vt320. I
used the vt220W and go to the help screens and that lets you see the
UNIX template. 

I expect that the days of UNIX WP and ProComm are pretty fuzzy
memories to  most folks now - certainly to me. We never used UNIX
based applications, except for CAD workstations and they and their
dark room requirements didn't last so very long because along came
AutoCad and we were all PCs.

Thanks for the help. If you find the ProComm mappings/Kermit version I
am willing to try.

Bill
Atlanta

 ..............................................................................

Newsgroups: comp.protocols.kermit.misc
Message-ID: <bg3alk$4nc$1@watsol.cc.columbia.edu>
References: <00q6ivkjdn6f8mad9ou0pi95gk273d343a@4ax.com>
    <bfummb$q3k$1@watsol.cc.columbia.edu> <bg1c04$rd7$2@blue.rahul.net>
Organization: Columbia University
Date: 28 Jul 2003 10:06:44 -0400
From: Frank da Cruz <fdc@columbia.edu>
Subject: Re: Word Perfect Keyboard (Frank)

In article <bg1c04$rd7$2@blue.rahul.net>,
 <dold@WordXPerfe.usenet.us.com> wrote:
:
: I wanted to wait for Frank to respond first, with a K95 entry that was more
: graceful than my setup.

K95's WordPerfect keyboard mode is built-in.  You can see what the default
mappings in the Default.Ksc file, which is in your Kermit 95 directory tree
somewhere; there's also a copy here:

  ftp://kermit.columbia.edu/kermit/k95/default.ksc


Search for "SET TERMINAL KEY wp" and then read the next 146 lines.  Of
course you can change the mapping any way you like.

: I looked at the Wordperfect mapping that was on the kermit site at that
: time, and chose not to use it, although I don't recall why.

It should have been just the ticket since these mappings were provided by
WordPerfect themselves.  K95 used this map as a model for its WP keyboard
mode.

- Frank

 ..............................................................................

Newsgroups: comp.protocols.kermit.misc
Message-ID: <3a3hivophckesp3qko7bm90q1bobfgn8jk@4ax.com>
References: <00q6ivkjdn6f8mad9ou0pi95gk273d343a@4ax.com>
    <bfummb$q3k$1@watsol.cc.columbia.edu> <bg1c04$rd7$2@blue.rahul.net>
    <bg3alk$4nc$1@watsol.cc.columbia.edu>
Organization: Dunwoody Georgia
Date: Wed, 30 Jul 2003 23:37:41 -0400
From: Bill <bill.loard@nowhere.org>
Subject: Re: Word Perfect Keyboard (Frank)

I have used FinePrint to print out the whole manual, and found the WP
section. If the old mapping file is found it may be worth posting at
Kemit. I expect that the Transcribers will all hit this at some
point(?). Especially when the old version of ProComm(s) flake out.
Pretty sure it will not run in XP and I haven't tried it on my Win2K
machine. 

Thanks

Bill
(BTW the existing WP emulation works well enough to make corrections
to the server copy, and apparently they mostly work on WP locally and
then up-load the files. Kermit up-loads fine as is......)

 ..............................................................................

Newsgroups: comp.protocols.kermit.misc
Message-ID: <bg8qhi$pla$1@watsol.cc.columbia.edu>
References: <00q6ivkjdn6f8mad9ou0pi95gk273d343a@4ax.com>
    <bg1c04$rd7$2@blue.rahul.net> <bg3alk$4nc$1@watsol.cc.columbia.edu>
    <3a3hivophckesp3qko7bm90q1bobfgn8jk@4ax.com>
Organization: Columbia University
Date: 30 Jul 2003 12:08:18 -0400
From: Frank da Cruz <fdc@columbia.edu>
Subject: Re: Word Perfect Keyboard (Frank)

In article <3a3hivophckesp3qko7bm90q1bobfgn8jk@4ax.com>,
Bill  <bill.loard@nowhere.org> wrote:
: I have used FinePrint to print out the whole manual, and found the WP
: section. If the old mapping file is found it may be worth posting at
: Kemit. I expect that the Transcribers will all hit this at some
: point(?). Especially when the old version of ProComm(s) flake out.
: Pretty sure it will not run in XP and I haven't tried it on my Win2K
: machine. 
: 
Why don't you post what you think the mapping should be and then we
can compare it with what Kermit uses, and then we'll know why you think
there is a problem.  Remember: Kermit's mapping is the one recommended
by the WordPerfect company itself.

Anyway, you still haven't confirmed that you have actually activated
Kermit's WordPerfect keyboard mode.  I explained several times how to
to do this.

- Frank

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.terminals,comp.sys.ibm.pc,comp.sys.ibm.pc.misc
Path: utkcs2!darwin.sura.net!news.udel.edu!ravel.udel.edu!sigurd
Message-ID: <BwFu5n.1J9@news.udel.edu>
Sender: usenet@news.udel.edu
Nntp-Posting-Host: ravel.udel.edu
Organization: University of Delaware
References: <1992Oct5.021247.22556@samba.oit.unc.edu> <1992Oct6.092905.19557@news.uni-stuttgart.de>
Date: Tue, 20 Oct 1992 20:56:10 GMT
From: sigurd@ravel.udel.edu (Sigurd Andersen)
Subject: Re: Inexpensive Tek 4014/DEC VT220 Emulator?


In article <1992Oct6.092905.19557@news.uni-stuttgart.de>
	skok@itwds1.energietechnik.uni-stuttgart.de (Holger Skok) writes:
: Kermit emulates vt100 and Tek4014 and it's free (as far as I know). 
: I haven't found out though, how to store the Tek4014 image and convert
: it to HPGL like it is possible with some commercial terminal emulators.
: ...
[ Others also sent various related messages which I will NOT summarize ]

[as of 20 Oct 1992]

The latest version of MS-Kermit (for MS-DOS-based personal computers)
is 3.12.  That's the version now distributed by Columbia University.
Version 3.12 adds the ability to establish network connections using
ODI drivers in addition to the connections using packet drivers that
were possible with version 3.11.

MS-Kermit and versions for other computer systems are fully copyable.
The following quote is from the book, "Using MS-DOS Kermit," Second
Edition:
	"Kermit programs can be freely reproduced and shared as long as
this is not done for profit.  No licensing or registration is required.
However, Kermit programs are not in the public domain.  In general,
each Kermit program includes a copyright notice to protect its special
status. ..." (page xxii)

With version 3.11 or 3.12 (and possibly earlier versions), one can
capture Tektronix graphics screens as "Aldus/Microsoft TIFF (Tagged
Image File Format) 5.0 ... suitable for importation into applications
such as WordPerfect 5.0, Aldus Pagemaker, Ventura Publisher, PC Paint,
and others that support TIFF 5.0." (ibid., p. 85)
Screen capture is initiated with the key combination Control-End.  The
graphics commands from a host that create the screen images can also
be captured (using the LOG SESSION command) and played back using the
REPLAY command.

A reference for the book: "Using MS-DOS Kermit   Connecting your PC to
the Electronic World" Second Edition, by Christine M. Gianone.  From
Digital Press (ISBN 1-55558-082-3) or Prentice-Hall (0-13-952276-X).

-- 
Sigurd Andersen    Internet: sigurd@chopin.udel.edu    CNS User Services
     __o            or Sigurd.Andersen@MVS.udel.edu    115-B Newark Hall
   _ \<,_                   Bitnet: ACS20833@UDELVM    Univ. of Delaware
  (_)/ (_)         Ph: (302) 831-1992 Fax: 831-4335    Newark, DE. 19716

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.os.vms
Path: utkcs2!darwin.sura.net!paladin.american.edu!news.univie.ac.at!hp4at
      !mcsun!uknet!strath-cs!str-ccsun!dct.ac.uk!ccdarg
Message-ID: <1992Oct20.154534.710@dct.ac.uk>
Date: 20 Oct 92 14:45:34 GMT
References: <1992Oct19.160704.1@uwovax.uwo.ca> <1992Oct19.215917.5808@ais.com>
Organization: Dundee Institute of Technology
From: ccdarg@dct.ac.uk (Alan Greig)
Subject: Re: Shipping obj files using Kermit?

In article <1992Oct19.215917.5808@ais.com>,
 bruce@ais.com (Bruce C. Wright) writes:
>
> In article <1992Oct19.160704.1@uwovax.uwo.ca>,
>    brent@uwovax.uwo.ca (Brent Sterner) writes:
>>
>>    I have a user who wants to transfer .obj files to another site using
>>    Kermit.  The files arrive, bit are not usable.  The file organization
>>    seems to end up being munged, whether he uses binary mode or not.
> 
> Yes, rather annoying how VMS .OBJ files and Kermit don't agree with one
> another very well.  :-(
> 

C kermit 5A for VMS can transfer *any* VMS file preserving RMS attributes.
It can even transfer to a PC (say) and then correctly restore the file
on the way back. The moment it passes the beta stage (which is expected
any day now...) I'll post out a copy of the announcement here. In the
meantime you can probably get hold of it as follows.

HOW TO GET THIS EDIT

The new edit is available (on the Internet only) via anonymous ftp from host
watsun.cc.columbia.edu [128.59.39.2], using text (ASCII) mode in the directory
kermit/sw/.  General C-Kermit documentation:

  ckaaaa.hlp   Explanation of file naming conventions
  ckcplm.doc   C-Kermit "program logic manual"
  ckccfg.doc   C-Kermit configuration info
  ckcker.ann   Info-Kermit Digest announcement of version 5A(179)
  ckcker.bwr   General C-Kermit beware file
  ckcker.upd   C-Kermit program update history since edit 179, plain text
  ckc178.upd   C-Kermit 5A update history through edit 178, HUGE
  ckuker.doc   plain-text user manual (still 179)
  ckuker.ps    Postscript user manual (ditto)
  ckuker.mss   Scribe source for user manual + ckuhdr.mss (ditto)

VMS sources:      ck[cuwv]*.[cwh], plus ckvcvt.c (labeled-file decoder)
VMS build:        ckvcdt.com plus ckvker.com (DCL), ckvker.mak (VMS MAKE),
                  or ckvker.mms (MMS).  Instructions: ckvins.doc.
VMS executable:   ckvker.hex, use ckvdeh.mar to decode it into .EXE format.
                  NOTE: this executable does not include TCP/IP support.
VMS docs:         ckvker.hlp, ckvins.doc, ckvker.bwr
VMS diffs:        ckv184.dif (88K), use with cku184.dif.

-- 

Alan Greig                            Janet: Alan@UK.AC.DUNDEE-TECH
Dundee Institute of Technology	   Internet: Alan@DCT.AC.UK
Tel: (0382) 308810

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 53502 of comp.os.vms:
Path: utkcs2!gatech!rutgers!spcvxb!terry
From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
Newsgroups: comp.os.vms
Subject: Re: Shipping obj files using Kermit?
Message-ID: <1992Oct20.232253.4168@spcvxb.spc.edu>
Date: 21 Oct 92 03:22:53 GMT
References: <1992Oct19.160704.1@uwovax.uwo.ca> <1992Oct19.215917.5808@ais.com>
Organization: St. Peter's College, US
Lines: 23

In article <1992Oct19.215917.5808@ais.com>, bruce@ais.com (Bruce C. Wright) writes:
> Yes, rather annoying how VMS .OBJ files and Kermit don't agree with one
> another very well.  :-(

  Fixed in a forthcoming major release. C-Kermit 5A, now in beta test, adds
a new file transfer type called "LABELED". Labeled transfers correctly pre-
serve all the file attributes you'd ever want. You can transfer any VMS file
structure between systems with this feature. I've moved RMS indexed files,
.OBJ's, etc.

  You can even pass these files through an intermediate system which knows
nothing about VMS files. I've moved VAX Notes conference files from one VAX
to my PC and then back to another VAX and had them work fine.

  The current test version of C-Kermit is available from watsun.cc.columbia.edu
in directory kermit/sw. At the present time I believe only sources are avail-
able; you'll need the VAX C compiler (or DEC C for an Alpha AXP) to compile it.

  When the test period is over, a formal announcement will likely be made here.

	Terry Kennedy		Operations Manager, Academic Computing
	terry@spcvxa.bitnet	St. Peter's College, Jersey City, NJ USA
	terry@spcvxa.spc.edu	+1 201 915 9381


 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 676 of comp.terminals:
Newsgroups: comp.dcom.lans.ethernet,comp.terminals
Path: cs.utk.edu!gatech!howland.reston.ans.net!ux1.cso.uiuc.edu!uchinews!cs.umd.edu!afterlife!grday
From: grday@afterlife.ncsc.mil (Gary Day)
Subject: MSDOS Kermit and TCP/IP
Message-ID: <1993May14.021506.3974@afterlife.ncsc.mil>
Organization: The Great Beyond
Distribution: usa
Date: Fri, 14 May 1993 02:15:06 GMT
Lines: 83
Xref: cs.utk.edu comp.dcom.lans.ethernet:4760 comp.terminals:676

On April 16, 1993 I posted the following:

>I have an IBM AT running MSDOS 5.0 with a 3COM 3C505 LAN adapter.
>Can someone please tell me what I need (i.e., packet driver or whatever,
>and where I might obtain such) in order to use MSKERMIT 3.11

     Several people asked me to post what I found out, so here it is.

First, MSDOS Kermit may be used to communicate via TCP/IP lans in one
of two ways.  MSDOS Kermit provides direct support for TCP/IP
lans via a set of  SET TCP/IP commands. In order to use MSDOS
Kermit in this mode, you need a packet driver.  PCTCP-PLUS from FTP Software
Inc.  comes with a complete collection of packet drivers. These
same drivers may be obtained from:

Host:  sifon.cc.mcgill.ca
Location: /pub/ftp_inc/dos/pdrivers

     MSDOS kermit 3.11 is also available from this same location.
     You may need to refer to the documentation with your specific
adapter to get the correct values to use when installing the appropriate
packet driver.  Specifically, you will need to supply a software interrupt
number, the hardware interrupt number used by the adapter, the I/O address,
and the memory base address.  For example, I have a 3C505 card, so I use
the command:

3c505 0x60 5 0x300 0xcc00

By the way, PCTCP-PLUS comes with a device driver called 3C505.COM
which should not be confused with the packet driver by the same name.

With the packet driver installed, you can invoke Kermit and give the
appropriate SET TCP/IP commands, for example:

SET TCP/IP ADDRESS 139.75.25.126
SET TCP/IP SUBNETMASK 255.255.255.0
SET TCP/IP GATEWAY 192.75.55.9
SET TCP/IP DOMAIN NCSC.MIL
SET TCP/IP PRIMARY-NAMESERVER AFTERLIFE
SET TCP/IP PRIMARY-NAMESERVER VALHALA
SET PORT TCP/IP PARADISE

You may need to get the help from your LAN manager to get the proper values

to be supplied for the addresses and for the name servers.

     The second, and easier way to use Kermit on a TCP/IP LAN, is to use
the TNGLASS "-e" option, which informs TNGLASS (from PCTCP) that an alternate
terminal emulator is being used.  This causes TNGLASS to make a TELNET
connection, and then invoke the named terminal emulator, with which it will
communicate via DOS interrupt 14. For example:

tnglass paradise -e kermit

In this case, you will need to inform kermit that it is to communicate
via interrupt 14, by issuing the command:

SET PORT BIOS1


     All of this information and much more is given in the book:

"Using MSDOS Kermit" by Cristine Gianone

and this is a book that I highly recommend for serious MSDOS Kermit users.
It also comes with MSDOS Kermit 3.11 on a 5 and 1/4 in. floppy.


     I am a blind programmer and use a screen reader driver, together
with a speech synthesizer to produce speech from the displayed text.
The MSDOS Kermit vt100 emulation  is done through MSDOS I/O interrupt calls
and thus works well with my screen reader. (Some earlier documentation
indicates that Kermit performs terminal emulation via direct video memory
access, but this appears not to be the case, at least for vt100 emulation).
However, I have found that if I install a packet driver and try to make
a direct TCP/IP connection with Kermit, my system will hang as soom as my
screen reader is enabled.  I haven't a clue why this should be. But the
second method of using tnglass and interrupt 14 works fine.

Gary R. Day:  grday@afterlife.ncsc.mil

Thanks to  Wayne Hann,  of the Cabot College of Applied Arts,
 WAYNE@FAC.CABOT.NF.CA for pointing me in the right direction.


 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.os.vms
Path: cs.utk.edu!gatech!concert!rutgers!spcvxb!terry
Message-ID: <1993May9.171512.5872@spcvxb.spc.edu>
Date: 9 May 93 21:15:12 GMT
References: <01GXWVNSRHQ89BVI9R@JCSVAX1.BITNET>
Organization: St. Peter's College, US
From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
Subject: Re: Kermit is toooooooo slow !!


In article <01GXWVNSRHQ89BVI9R@JCSVAX1.BITNET>,
    HANY%JCSVAX1.BITNET@pucc.Princeton.EDU
    (Axioms can be viewed as a form of exact theology) writes:
>
>         Our school runs VMS Kermit-32 version 3.3.111 on a VAX/VMS V5.4-2.
> I find it pretty slow to transfer files using this protocol, specially
> that our highest connection is at 2400 bauds. Still, at 2400, I get almost
> triple Kermit's speed using ZMODEM when connecting to my local BBS.

  There's a number of reasons for this. First, your 2400 baud connection to
JCS is either through the DCA front-end, or through the NJ Bell LANgate packet-
switched network. Both of these introduce substantial delays when used for file
transfer. A protocol which utilizes multiple-packet windows will perform better
on this type of link. C-Kermit does this; I don't know about Zmodem. Second,
Zmodem expects to be able to pass most control characters through the line.
While I am told that it is careful to avoid using "troublesome" characters like
^S/^Q, I believe it will use ^V (or is it ^N?), which is the "attention charac-
ter" for your DCA front-end. Kermit quotes all control characters in user 
files.

> My question is: Is there any shareware/freeware software that is faster than
> this version of Kermit ? I think that it won't be hard to convince our sys
> mngr to switch if such a thing exists. It is equally important also to know
> where can I get it. An FTP site will be the most convenient, but I am also
> willing to call long distance if it is worth it.

  C-Kermit is substantially faster than Bliss Kermit-32 as long as both ends 
are capable of using long packets and sliding windows. Many other Kermits, in-
cluding MS-DOS Kermit, support these features.

  C-Kermit is available by anonymous FTP from watsun.cc.columbia.edu. In your
case, you'd want (as a minimum) kermit/v/ckvker.hex and ckvdeh.mar.

  As you probably know, I provide support for some of the more esoteric pieces
of software on the JCS cluster. I'd be glad to install C-K there if system man-
agement requests it.

	Terry Kennedy		Operations Manager, Academic Computing
	terry@spcvxa.bitnet	St. Peter's College, Jersey City, NJ USA
	terry@spcvxa.spc.edu	+1 201 915 9381


 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.dcom.modems
Path: cs.utk.edu!nntp.memst.edu!ukma!eng.ufl.edu!spool.mu.edu
      !howland.reston.ans.net!darwin.sura.net!udel!news.intercon.com
      !psinntp!news.columbia.edu!usenet
Message-ID: <1993May16.144933.16900@news.columbia.edu>
Date: Sun, 16 May 1993 14:49:33 GMT
References: <f3ic4no@quack.kfu.com>
Organization: Columbia University
From: fdc@fdc.cc.columbia.edu (Frank da Cruz)
Subject: Re: zmodem for kermit 

In article <f3ic4no@quack.kfu.com> haymoree@quack.kfu.com (Ed Haymore) writes:
>
> How do I get a decent throughput with Kermit on a 14.4k modem?  I can't
> get anything more than about 350 cps -- with zmodem I get 1600+ cps on
> the same setup.  (compressed file, by the way)
> 
> Even at 2400 baud, kermit's speed is about 50% of zmodem's.  If the
> quoting doesn't significantly increase the amount of data to transfer,
> what makes kermit so slow?

First, let's make sure you are using real and up-to-date Kermit software,
and not the minimalistic and half-hearted Kermit implementations that you
find in most commercial and shareware communication software.  For DOS and
Windows, use MS-DOS Kermit 3.12 (soon to be 3.13); for UNIX use C-Kermit  
5A(188) (soon to be 189) (watch comp.protocols.kermit for announcements).

Then make sure an effective method of flow control, preferably RTS/CTS,
is enabled at each interface along the communication path.  For example,
tell MS-DOS Kermit to SET FLOW RTS/CTS, and give the corresponding settings  
to your modem.

Set your interface speed higher than the modem's modulation speed.  For
example, using 14400 bps modulation, set your interface to 57600 bps if  
possible, or 38400 or 19200 otherwise.  (This doesn't actually matter too
much when transferring precompressed files, but it does matter for most other  
types of files, and is a good rule to follow in general when using modems  
that do data compression.)

Tell both Kermit programs to SET WINDOW <n>, where <n> is a number somewhere
between 2 and 20 -- the optimum value depends on the connection, the  
characteristics of the modem and the data.

Tell both Kermit programs to SET RECEIVE PACKET-LENGTH 1000.  Also, when
sending binary files (like ZIP files) don't forget to tell the file sender
to SET FILE TYPE BINARY (it will tell the receiver automatically).

Using these settings, you should get about 1300 cps for ZIP or other  
precompressed files, and much higher rates for other types of files.

MS-DOS Kermit 3.13 and C-Kermit 5A(189) will include a new feature that lets
you boost throughput of ZIP and other precompressed files by about 20%, ON  
PERFECTLY CLEAN 8-BIT TRANSPARENT CONNECTIONS, bringing Kermit's performance  
in this situation to the same level as Zmodem's (as pointed out earlier,  
Kermit already outperforms Zmodem in most other situations: text files, most  
uncompressed binary files, noisy connections, connections with delays, 7-bit
connections, etc).

To get Kermit software, use anonymous ftp to watsun.cc.columbia.edu  
[128.59.39.2], directory kermit, get the file READ.ME, read it, take it
from there.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.tcp-ip,comp.terminals
Path: cs.utk.edu!gatech!europa.eng.gtefsd.com!uunet!cs.utexas.edu!utah-morgan
      !hellgate.utah.edu!cc.usu.edu!jrd
Message-ID: <1993Aug16.215757.71292@cc.usu.edu>
References: <westesCBtqsx.69F@netcom.com> <24n6pq$pr8@toffu.icl.fi>
Organization: Utah State University
Date: 16 Aug 93 21:57:57 MDT
From: jrd@cc.usu.edu (Joe Doupnik)
Subject: Re: Where to get VT-100 source code in public domain?

In article <24n6pq$pr8@toffu.icl.fi>, jel@xerver.icl.fi (Jerry Lahti) writes:
> westes@netcom.com (Will Estes) writes:
> 
>>I need to write a simple VT-100 emulator as part of a commercial
>>product.  Where does one find the specifications for VT-100, and is
>>there any code in the public domain for this emulation that can be
>>used as either a reference or actually copied into a commercial
>>product?
> 
> Presumably Digital will sell you the appropriate reference manuals.
> 
> MS-Kermit sources might serve as a reference, although the display
> emulation is unfortunately :-) already at the VT-320 level. However,
> I have not looked closely enough at the copyrights to know, if the
> code could be directly incorporated into a commercial product.
> 
> /Jerry Lahti
> 
> -- 
> Jerry Lahti             !  tel. +358-0-567 3639
> ICL Personal Systems Oy !  fax. +358-0-567 5670
> P.O.Box 780             !  Email: jel@xerver.icl.fi (Internet) 
> 00101 Helsinki, Finland !  X400:  C=FI A=MAILNET P=ICL O=ICL S=LAHTI G=JERRY
------------------
	Here's the copyright notice from MS-DOS Kermit:

;  Copyright (C) 1985, 1993, Trustees of Columbia University in the 
;  City of New York.  Permission is granted to any individual or institution
;  to use this software as long as it is not sold for profit.  This copyright
;  notice must be retained.  This software may not be included in commercial
;  products without written permission of Columbia University.

So no, one can't use the material for commercial products. The ref for
DEC VT100's is from Digital themselves (that's by far the best ref too).

        Joe D.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.dcom.modems
Path: cs.utk.edu!darwin.sura.net!howland.reston.ans.net!agate!dog.ee.lbl.gov
       !hellgate.utah.edu!cc.usu.edu!jrd
Message-ID: <1993Oct31.194051.2931@cc.usu.edu>
Date: 31 Oct 93 19:40:51 MDT
References: <2aehhv$kbg@vixen.cso.uiuc.edu> <752109594snz@genesis.demon.co.uk>
        <2aejmc$77v@apakabar.cc.columbia.edu> <1993Oct28.204050.9223@omen.UUCP>
Organization: Utah State University
From: jrd@cc.usu.edu (Joe Doupnik)
Subject: Re: Problems with com4 and Kermit 

In article <752109594snz@genesis.demon.co.uk>,
 fred@genesis.demon.co.uk (Lawrence Kirby) writes:
>
> In article <1993Oct28.204050.9223@omen.UUCP> caf@omen.UUCP writes:
> 
>>What's unreal about the Kermit in Telix, Procomm, et al?  Do they violate the
>>published Kermit spec?
> 
> Many do. I've noted that in the past some implementations won't accept valid
> negotiation packets even though published specs show how to deal with them,
> even when the packets contain fields for the more advanced functions.
> 
> -----------------------------------------
> Lawrence Kirby | fred@genesis.demon.co.uk
> Wilts, England | 70734.126@compuserve.com
> -----------------------------------------

	To quote a section from the "Kermit News", Number 5, July 1993,
which has a big article on the subject of performance.
(start quote, with some abbreviations)

Table 1 illustrates the performance of the Kermit protocol implementations
found in different PC software packages. These measurements were made on a
direct 19200-bps serial connection, downloading a typical ASCII text file
(the VM/CMS Kermit-370 manual), 135087 bytes in length, from a Sun
SPARCserver-10 with C-Kermit 5A(189) to the hard disk of an IBM PS/2 Model 70.

Table 1 Kermit Implementations Compared
               Window  Packet	Time  Speed
PC Software    Size    Length	sec   (cps)  Effic	Remarks
-----------    ------  ------   ----  -----  ----  ---------------------------
Telix		1	  94	131   1052    55%  No Long Pkt, no Slide Window
METZ		1	  94	119   1158    60%  No LP, no SW
Smartcom III	1	  94	113   1220    64%  No LP, no SW
PROCOMM PLUS   14       1000	 77   1790    93%  Window size is not selectable
Zstem 340	2	1000	 74   1863    97%  Max window size is 2
MS-DOS Kermit   3	1000	 72   1915    99%  Full control-char prefixing
MS-DOS Kermit   3	1000	 69   1999   104%  Only 0, 1 and 129 prefixed
------
MS-DOS Kermit v3.13
METZ v1.16
PROCOMM PLUS v2.0
Smartcom III v1.0A
Telix v3.21
Zstem 340 v1.0.4
(end quote)

	Please contact Christine Gianone, cmg@columbia.edu, to request a copy.
	Joe D.
 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.dcom.modems
Path: cs.utk.edu!gatech!europa.eng.gtefsd.com!uunet!nntp.club.cc.cmu.edu
      !honeydew.srv.cs.cmu.edu!GS137.SP.CS.CMU.EDU!pwp
Message-ID: <pwp.752302635@GS137.SP.CS.CMU.EDU>
Originator: pwp@GS137.SP.CS.CMU.EDU
Organization: School of Computer Science, Carnegie Mellon
X-Newsreader: NN version 6.5.0 #13 (NOV)
References: <1993Oct31.194051.2931@cc.usu.edu><1993Nov01.112834.8307@omen.UUCP>
          <752171522snz@genesis.demon.co.uk> <1993Nov02.112928.17189@omen.UUCP>
Date: Wed, 3 Nov 1993 04:57:15 GMT
From: Paul Placeway <pwp+@cs.cmu.edu>
Subject: Re: Problems with com4 and Kermit


caf@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>
>So where can the current Real Kermit(Tm) protocol specs be FTP'd from??
>It appears that one must use code from the latest Columbia Kermit sources,
>and those are protected by a restrictive Copyright.

Watsun.cc.columbia.edu.  You know this already, and so does most of
the rest of the planet.

>>Most ZMODEM implementations do go as fast as the freely available specs
>>permit.

>Likewise for Kermit, and likely to stay that way.

Yup.  Unix Kermit 5a and MS Kermit 3, for instance.  The current spec
is the natural union of the latest protocol document and the final
versions of the un-quoting additions from the Kermit mailing list, ALL
of which are available for anonymous FTP right now (yes, I just
checked).  The spec MUST be right, because there are hundreds of
Kermit implementations, often in different languages, which all
actually work together.  The only way to do this is to have a clear,
complete, and available spec, and to implement to it.

I know personally that the sliding windows spec is correct.  I wrote a
ground-up new implementation in 1988 (yes, 5 years ago).  When I had
it working to the spec correctly, it worked correctly against the
existing code the first time I tried it.

And the latest, fastest, Kermit is *still* backwards compatible to
version 1.

Zmodem cannot make the same claim, though for reasons of greed rather
than any good technical reason.  Now if the spec for the latest
version of zmodem were available, and Omen just happened to make the
best quality implementation, you shouldn't have any problem with
compensation for your efforts, and users of machines too weird for
Omen to support (eg. Macs, Amigas, hand-held calculators) would
benefit from other high performance implementations.  (And like
Microsoft, if a small market becomes a big one, you have an easy
chance to step in and sell even more.)

On the other hand, if you want to run a closed spec, well, I can only
suggest you ask IBM and DEC how they feel about the current popularity
of Sun, or perhaps consider the current popularity of ARC vs. ZIP.
The Market reacts to a good value.  The inverse is also true...

>Chuck Forsberg WA7KGX          ...!tektronix!reed!omen!caf 

		-- Paul Placeway <pwp+@cs.cmu.edu>

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-


Article 47123 of comp.dcom.modems:
Newsgroups: comp.dcom.modems
Path: cs.utk.edu!avdms8.msfc.nasa.gov!europa.eng.gtefsd.com!uunet!omen!caf
From: caf@omen.UUCP (Chuck Forsberg WA7KGX)
Subject: Re: Problems with com4 and Kermit
Organization: Omen Technology INC, Portland Rain Forest
Date: Fri, 05 Nov 1993 00:12:25 GMT
Message-ID: <1993Nov05.001225.8163@omen.UUCP>
References: <752171522snz@genesis.demon.co.uk> <1993Nov02.112928.17189@omen.UUCP> <pwp.752302635@GS137.SP.CS.CMU.EDU>
Lines: 92

In article <pwp.752302635@GS137.SP.CS.CMU.EDU> Paul Placeway <pwp+@cs.cmu.edu> writes:
>caf@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>
>>So where can the current Real Kermit(Tm) protocol specs be FTP'd from??
>>It appears that one must use code from the latest Columbia Kermit sources,
>>and those are protected by a restrictive Copyright.
>
>Watsun.cc.columbia.edu.  You know this already, and so does most of
>the rest of the planet.
>
>>>Most ZMODEM implementations do go as fast as the freely available specs
>>>permit.
>
>>Likewise for Kermit, and likely to stay that way.
>
>Yup.  Unix Kermit 5a and MS Kermit 3, for instance.  The current spec
>is the natural union of the latest protocol document and the final
>versions of the un-quoting additions from the Kermit mailing list, ALL
>of which are available for anonymous FTP right now (yes, I just
>checked).  The spec MUST be right, because there are hundreds of
>Kermit implementations, often in different languages, which all
>actually work together.  The only way to do this is to have a clear,
>complete, and available spec, and to implement to it.

Um, last time I checked, Unix Kermit and MS Kermit are covered
by restrictive copyrights.  My "likely to stay that way" comment
refers to Kermit support in "the popular implementations" of
Kermit in ProComm, Crosstalk et al.  I don't think DCA or
Datastorm are any more likely to violate Columbia's copyright
than they are likely to violate the copyright in rz/sz.

The fact that someone was able to cobble together a program that
works in one or two benign environments does not mean the spec
is through or accurate.


>I know personally that the sliding windows spec is correct.  I wrote a
>ground-up new implementation in 1988 (yes, 5 years ago).  When I had
>it working to the spec correctly, it worked correctly against the
>existing code the first time I tried it.

I'm not sure Frank completely agrees with you:
. Sliding Windows.  Of course, I know the history too.  I worked closely with
  The Source throughout the development of sliding windows, but the
  implementations that they commissioned were rush jobs that left a lot to be
  desired.  They were nowhere near "efficient and robust under stress".  They
  were buggy as all get-out, hideous to contemplate internally, and broke more
  often than they worked.  This was the code that was incorporated into
  shareware Procomm, by the way, and who knows where else.  Eventually, we
  wrote our own sliding windows implementations completely from scratch.
  Compare them yourself for robustness and efficiency with The Source version.

Of course, the good implementation is Copyrighted.

>And the latest, fastest, Kermit is *still* backwards compatible to
>version 1.

Yup.  It took me an hour to get C-Kermit 189 on SCO to send a binary file
to C-Kermit 189 on a BSDI machine starting with the settings given in the
Kermit News article. (The Kermits were using different dialects, then
Ctrl-C had to be escaped.)  Kermit lusers often encounter this dialect
problem.   So don't lecture me on compatibility.

>Zmodem cannot make the same claim, though for reasons of greed rather
>than any good technical reason.  Now if the spec for the latest

Oh yes ZMODEM can.  Every case of incompatibility that I have been
able to investigate has been caused by the implementor breaking
the spec or the PD source code in one or more ways.

As for greed, I might point out that I have licensed ZMODEM-90(Tm)
under much more favorable conditions than Frank da Cruz has offered
to license me the current Kermit technology.

Thye July Kermit News obfuscates this issue by claiming Kermit
software was never public domain.  In fact, until recently
developers were free to incorporate the Kermit source code into
their programs.  Apparently the financial situation at Columbia
U has changed.

>version of zmodem were available, and Omen just happened to make the
>best quality implementation, you shouldn't have any problem with

Yes, we do make the best implementation, which is why Frank da Cruz
was careful not to use it for his so-called "True-Life Benchmarks"
in his hit piece on ZMODEM.

-- 
Chuck Forsberg WA7KGX          ...!tektronix!reed!omen!caf 
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
  Omen Technology Inc    "The High Reliability Software"
17505-V NW Sauvie IS RD   Portland OR 97231   503-621-3406

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-


Article 49457 of comp.dcom.modems:
Newsgroups: comp.dcom.modems,comp.unix.questions
Path: cs.utk.edu!gatech!howland.reston.ans.net!cs.utexas.edu!uunet!news.crd.ge.com!sixhub!davidsen
From: davidsen@sixhub.tmr.com (Bill Davidsen)
Subject: Re: DSZ for unix
Reply-To: davidsen@tmr.com (bill davidsen)
Organization: TMR Associates, Schenectady NY
Date: Wed, 8 Dec 1993 03:30:02 GMT
Message-ID: <CHp5q3.175@sixhub.tmr.com>
References: <1993Dec1.143941.252999@ucl.ac.uk> <CHMK9M.IK@tc.fluke.COM>
Lines: 30
Xref: cs.utk.edu comp.dcom.modems:49457 comp.unix.questions:57484

In article <CHMK9M.IK@tc.fluke.COM> wjones@tc.fluke.COM (Warren Jones) writes:

| If you have kermit version 5A, you can teach it to use sz/rz as
| external protocols.  Put something like this in $HOME/.kermrc:
| 
| --------------------------- cut here ----------------------------------------
| # Generic external protocol
| #
| def extern ! exec /usr/local/bin/\%1 \%2 <\v(line) >\v(line),-
|     echo,-
|     connect

Only on some implementation of UNIX. On some the serial port is owned by
uucp (or bin, root, or ???) and the comm progs must run setuid. And in
sysV you can't setuid to euid unless you are root or have V.4. Therefore
you (as your login id) can't open the serial port with redirection, and
the trick doesn't work.

The solution is to add code to Kermit to run the prog using the port as
stdin and stdout, and I did it, and am sending the code to Frank to
incorporate. I really needed it, although Kermit is much faster than
Zmodem on some lines, since zmodem seems to get a long way past an error
before starting the retry (or something). The line is a modem pool
connected via enet to the system called, and with the net and protocol
and modems playing packets the zmodem performance is slower.
-- 
Bill Davidsen, davidsen@tmr.com      |  C programming, PC based UNIX, data
    TMR Associates, +1 518-370-5654  |  acquisition, device drivers.
_____________________________________|______________________________________
cat - 'kat, a purr bearing mammal


 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.dcom.modems
Path: cs.utk.edu!emory!europa.eng.gtefsd.com!library.ucla.edu!agate
      !headwall.Stanford.EDU!Csli!paulf
Message-ID: <1994Jan21.200109.12743@Csli.Stanford.EDU>
Organization: The Three Packeteers
References: <2hlpdn$e3m@golem.wcc.govt.nz> <1994Jan20.193454.25924@omen.UUCP>
   <1994Jan20.213158.29111@Csli.Stanford.EDU> <1994Jan21.181856.2768@omen.UUCP>
Date: Fri, 21 Jan 1994 20:01:09 GMT
From: paulf@Csli.Stanford.EDU (Paul Flaherty)
Subject: Re: Protocol Shootout Results


caf@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>
>Paul, could you be so kind as to provide the pathnames for these files?
>I don't see any of the three Kermit books in Columbia University's public FTP
>area.  All I found was a copy of an antique Kermit spec.  Please provide
>pathnames for:
>	1.  current Kermit protocol spec

~ftp/kermit/e/kproto.ps

>	2.  Using C-Kermit

~ftp/kermit/b/ckuker.ps

>	3.  Using MS-DOS Kermit

~ftp/kermit/a/mskerm.ps

Those files, plus the most current .bwr text files, AND SOURCE CODE, make up
an outstanding documentation example.

-- 
-=Paul Flaherty, N9FZX | "Fighter pilots make movies.  Bomber pilots make
->paulf@Stanford.EDU   |  history."  -- Jake Grafton

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.dcom.modems
Path: cs.utk.edu!emory!europa.eng.gtefsd.com!uunet!omen!caf
From: caf@omen.UUCP (Chuck Forsberg WA7KGX)
Subject: Re: Protocol Shootout Results
Organization: Omen Technology INC, Portland Rain Forest
Date: Sat, 22 Jan 1994 13:04:28 GMT
Message-ID: <1994Jan22.130428.10097@omen.UUCP>
References: <1994Jan20.213158.29111@Csli.Stanford.EDU>
   <1994Jan21.200109.12743@Csli.Stanford.EDU> <1994Jan21.181856.2768@omen.UUCP>

In article <1994Jan21.200109.12743@Csli.Stanford.EDU>,
 paulf@Csli.Stanford.EDU (Paul Flaherty) writes:
>
>caf@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>
>>Paul, could you be so kind as to provide the pathnames for these files?
>>I don't see any of the three Kermit books in Columbia University's public FTP
>>area.  All I found was a copy of an antique Kermit spec.  Please provide
>>pathnames for:
>>	1.  current Kermit protocol spec
>
>~ftp/kermit/e/kproto.ps

No, that's the 1986 spec. 
It doesn't describe "Real Kermit" according to Columbia University.

>Those files, plus the most current .bwr text files, AND SOURCE CODE, make up
>an outstanding documentation example.

Paul must think "Kermit" means "free".  This is no longer true.

  Copyright (C) 1985, 1993, Trustees of Columbia University in the City of New
  York.  The C-Kermit software may not be, in whole or in part, licensed or
  sold for profit as a software product itself, nor may it be included in or
  distributed with commercial products or otherwise distributed by commercial
  concerns to their clients or customers without written permission of the
  Office of Kermit Development and Distribution, Columbia University.  This
  copyright notice must not be removed, altered, or obscured.

-- 
Chuck Forsberg WA7KGX       caf@omen.COM      503-621-3406
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
 Omen Technology Inc      "The High Reliability Software"
TeleGodzilla BBS:621-3746    FAX:621-3735   CIS:70007,2304


 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.dcom.modems
Path: cs.utk.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!agate
      !headwall.Stanford.EDU!Csli!paulf
Message-ID: <1994Jan22.184854.18205@Csli.Stanford.EDU>
Organization: The Three Packeteers
References: <1994Jan20.213158.29111@Csli.Stanford.EDU>
   <1994Jan22.130428.10097@omen.UUCP>
   <1994Jan21.181856.2768@omen.UUCP> <1994Jan21.200109.12743@Csli.Stanford.EDU>
Date: Sat, 22 Jan 1994 18:48:54 GMT
From: paulf@Csli.Stanford.EDU (Paul Flaherty)
Subject: Re: Protocol Shootout Results (Really: Kermit Legal Status)

caf@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>
>No, that's the 1986 spec. 
>It doesn't describe "Real Kermit" according to Columbia University.

Well, that's the current protocol spec.  If by "Real Kermit" you include stuff
like the command interface, that can be had from reading the source code.
The status of the protocol spec is listed in the forward:

#begin kermit.columbia.edu:~ftp/kermit/e/kproto.doc#

                         PREFACE TO THE SIXTH EDITION

The sixth edition (June 1986) of the Kermit Protocol Manual is being issued for
two major reasons: to correct minor errors in the fifth edition, and to include
new  sections  on  two major protocol extensions: long packets and sliding win-
dows.  No attempt has been made to reorganize, rewrite,  or  otherwise  improve
the  protocol  manual.    The Kermit protocol has been presented in an entirely
different -- hopefully more thorough, organized, coherent, and useful  (if  not
more  formal)  --  manner  in  the book, "Kermit, A File Transfer Protocol," by
Frank da Cruz, Digital Press, Bedford MA (1987), ISBN 0-932376-88-6, DEC  order
number EY-6705E-DP.  If you have the book, you won't need this protocol manual.
On the other hand, if you don't have the book, this manual should still contain
all  the necessary information.  The Kermit Protocol Manual will continue to be
freely distributed in perpetuity.

#end kermit.columbia.edu:~ftp/kermit/e/kproto.doc#

>Paul must think "Kermit" means "free".  This is no longer true.

You're confusing "free" with "public domain".  There are all sorts of copyright
arrangements in which the author maintains the copyright, but the product
remains economically free.  The purposes behind keeping the copyright include
but are not limited to: preventing other people from exploiting your work for 
financial gain, preventing others from introducing bugs into software with
your name on it, granting special conditions to certain user communities, etc.

>  Copyright (C) 1985, 1993, Trustees of Columbia University in the City of New
>  York.  The C-Kermit software may not be, in whole or in part, licensed or
>  sold for profit as a software product itself, nor may it be included in or
>  distributed with commercial products or otherwise distributed by commercial
>  concerns to their clients or customers without written permission of the
>  Office of Kermit Development and Distribution, Columbia University.  This
>  copyright notice must not be removed, altered, or obscured.

Nothing in this notice is inconsistent with economically free availability.
Now, before you bring up your previous argument with respect to Kermit News
Volume 5, let me do it for you:

#begin kermit.columbia.edu:~ftp/kermit/e/newsn5.txt#

It's KermitWare!

While Kermit software is not a commercial product, it is not in the public
domain either, and never has been.  It is not "shareware."  It's not
"freeware."  It is copyright by Columbia University.  See page -TERMS for our
terms and conditions.

#end kermit.columbia.edu ~ftp/kermit/e/newsn5.txt#

This is meaningless unless you also quote the TERMS page:

#begin kermit.columbia.edu:~ftp/kermit/e/aaxfly.doc#

TERMS AND CONDITIONS

The Kermit software--including source code--is furnished without warranty of
any kind, and neither Columbia University, nor the individual authors or
publishers, nor any institution that has contributed Kermit material,
acknowledge any liability for any claims arising from the use of Kermit.  Since
source code is available, users may fix bugs and make improvements, and are
encouraged to contribute their work back to Columbia for further distribution.

Kermit software may be ordered by private individuals, corporations, academic
or government institutions, and other organizations for their own internal use,
but the software may not be resold or otherwise redistributed to external
clients, customers, or contractors without written permission of the Manager of
Kermit Development and Distribution at Columbia University.  Contact us for
further information.

#end kermit.columbia.edu:~ftp/kermit/e/aaxfly.doc#

Again, nothing is inconsistent with economically free availability.  Note
especially the phrase "Kermit software is not a commercial product", and the
fact that "The Kermit Protocol Manual will continue to be freely distributed 
in perpetuity".  Looks pretty free to me.


-- 
-=Paul Flaherty, N9FZX | "Fighter pilots make movies.  Bomber pilots make
->paulf@Stanford.EDU   |  history."  -- Jake Grafton

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.dcom.modems
Path: cs.utk.edu!gatech!swrinde!cs.utexas.edu!utah-morgan!hellgate.utah.edu
      !cc.usu.edu!jrd
Message-ID: <1994Jan25.173740.8796@cc.usu.edu>
Date: 25 Jan 94 17:37:40 MDT
References: <1994Jan24.011009.2030@eisner> <1994Jan25.151426.22711@omen.UUCP>
Organization: Utah State University
From: jrd@cc.usu.edu (Joe Doupnik)
Subject: Re: Protocol Shootout Results

In article <1994Jan25.151426.22711@omen.UUCP>,
     caf@omen.UUCP (Chuck Forsberg WA7KGX) writes:
> In article <1994Jan24.011009.2030@eisner>,
>    billy@mix.com (Billy Youdelman) writes:
>>In article <CK3vKB.2Dy@ra.nrl.navy.mil> William C Fenner
>>   <fenner@cmf.nrl.navy.mil> writes:
>>
>>> But Kermit, in the way that it was set up for Columbia's test, has no
>>> way to interrupt the transfer *at*all*.  Tough luck if something happens
>>> and you don't want to see all the spew on your screen.
>>
>>How about sending it an error packet?
>>
>>Billy Y..
>>
> 
> Neat idea.  Perhaps the next version of C-Kermit and MSKermit will do that.
> Of course an error packet may be as effective as stopping the Queen Mary
> by dragging an oar if Kermit already has five 5000 byte packets queued up.
> 
> -- 
> Chuck Forsberg WA7KGX       caf@omen.COM      503-621-3406
> Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
>  Omen Technology Inc      "The High Reliability Software"
> TeleGodzilla BBS:621-3746    FAX:621-3735   CIS:70007,2304
--------------
	An error (E) packet is just fine, and it works unless the other
side has become rather hopelessly locked up. As I mentioned offline to 
another person I think I've tried ^C^C maybe twice over the past year,
and I tend to use Kermits rather frequently (I wonder why). An Error
packet is available from the keyboard during a file transfer session,
as are less drastic X (skip this file) and Z (skip the rest of the file
group) keyboard interruptions. These features have been in Columbia Kermits 
for years and years, are part of the original protocol, are described in
the user's manual books, are on the screens.

	Consequently the comment at the top of the inclusion is false.
	Joe D.
	
 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.dcom.modems
Path: cs.utk.edu!nntp.memst.edu!ukma!eng.ufl.edu!saimiri.primate.wisc.edu
      !sdd.hp.com!sgiblab!darwin.sura.net!howland.reston.ans.net
      !sol.ctr.columbia.edu!news.columbia.edu!usenet
Message-ID: <2i699f$5h2@apakabar.cc.columbia.edu>
Date: 26 Jan 1994 17:29:19 GMT
References: <1994Jan26.162400.4383@omen.UUCP>
Organization: Columbia University
From: fdc@fdc.cc.columbia.edu (Frank da Cruz)
Subject: Re: Protocol Shootout Results

In article <1994Jan26.162400.4383@omen.UUCP>
caf@omen.UUCP (Chuck Forsberg WA7KGX) writes:
>
> In article <758917572snx@crynwr.com> nelson@crynwr.com (Russell Nelson)
> writes:
> ...
> Bravely spoken by someone with a commercial link to Columbia
> University's Kermit software.
> ...
> The real "wonk issue" is that Columbia knows my observations are
> correct.  They have not even attempted to rebut them.  Frank da
> Cruz declined to appear at the Jan 6 Protocol Shootout knowing
> full well the troubling questions about Kermit News he would be
> forced to address.
>
 
I already addressed all these points weeks ago.  Chuck clearly
believes that by reiterating them on a daily basis, they will
become gospel.  However, I will not engage in public bickering with
someone whose primary debating tactic is to always get in the last
word.  The Kermit News article speaks for itself -- Chuck can
refute it all he wants to, and you, good readers, can judge for
yourselves.  Bear in mind, however, that this is not an all-or-
nothing issue -- use one, use both, use neither.

I am only posting this to dispel the notion that anyone is hiding,
and to point out that Chuck is acting an awful lot like Senator Joe
McCarthy of yore, brandishing his lists, naming names, and assigning
guilt by association.  I would not like to think that participants
in this newsgroup hesitate about their postings for fear they will
be publically vilified and ridiculed.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.dcom.modems
Path: cs.utk.edu!nntp.memst.edu!ukma!asuvax!farallon.farallon.com!agate
      !howland.reston.ans.net!sol.ctr.columbia.edu!news.columbia.edu!usenet
Message-ID: <2imthj$pu5@apakabar.cc.columbia.edu>
Date: 2 Feb 1994 00:53:07 GMT
Organization: Columbia University
From: fdc@fdc.cc.columbia.edu (Frank da Cruz)
Subject: Re: Protocol Shootout Results
Lines: 441

Against my better judgement I promised Chuck I would respond to his
"Protocol Shootout Report".  I apologize for prolonging this ridiculous
debate, and I would encourage Chuck to refrain from further gratuitous
snipes at each person who posts a message even remotely supportive of
Kermit or critical of Zmodem, not to mention using innocent questions --
even on unrelated topics -- as an opportunity to fire off another salvo.
I think everybody comes off looking and feeling better if we just answer
users' questions and try our best to solve their problems, and stop
using this forum as a soapbox.

Chuck says:
> For Russ' sake I do hope Crynwr software derives more income as a
> result of their relationship with Columbia Kermit than the cost of a
> single $20 DSZ registration.

And for Chuck's sake, I hope he does not make a regular practice of
disclosing business details about his customers in public.  This is not
a big confidence builder for potential customers.

Chuck says:
> ...as it was written and as people read it, Kermit News #5 is a
> promotional piece that seeks to enhance Columbia's revenues by
> trumpeting the relative performance of Columbia's product under a
> selected set of conditions and alternatives carefully contrived to
> promote the idea that Kermit is faster than competitive alternatives.
>
Of course it's a promotional piece.  However, the test conditions are
fair.  Four representitive types of files -- including the ones where
Zmodem's well-known strengths lie -- were transferred over different
types of connections.

Chuck's primary complaint, as I understand it, was that I did not use
ZMODEM-90(TM)-Moby-Turbo(TM) extensions in my tests.  Fine, I never said
I did.  I used the software that everybody uses and compares Kermit
against, the packages we have heard about constantly over our many years
of help-desk experience, and the article is totally explicit and
detailed about what was tested.

Chuck says:
> So we're back to where we started before Columbia University's Kermit
> News #5 broadside attack on their competition: Use Kermit for
> traditional IBM mainframes and other weird iron, otherwise use ZMODEM
> to get the best in speed, the reliability of 32 bit CRC, and Crash
> Recovery for real world error recovery.

That's clearly a skewed opinion.  Here is my skewed opinion:

Use Kermit anywhere at all.  Use Zmodem on a small subset of "anywhere
at all".  You can't use Zmodem on the rest of "anywhere at all" because
it does not work, or it does not exist, in that environment.  This
includes at least all 7-bit connections, which are quite common outside
the BBS world, and all of the "oddball" operating systems that one finds
on IBM mainframes, etc, which, one supposes, are only to be sneered at.
I would be very surprised to learn of a connection where Zmodem works
and Kermit does not.

On those connections where "regular" Zmodem protocol works at all, you
can get Kermit to work just as well or better.

Zmodem-90-Moby-Turbo(TM) might well go faster than Kermit if you have it
available to you on both ends, and the connection is cooperative, and if
that is true, then hats off to Chuck.

Chuck says:
> Columbia could have improved on this situation by developing a
> compact, high performance version of the WKERMIT (The Source) Kermit
> driver that could be used by bulletin boards, Telix, ProComm, Qmodem,
> et al.  Perhaps it is not too late for Columbia to correct the
> situation.

This is absolute nonsense, and a red herring on two counts.

The implementation Chuck is referring to (a) is nine years old, (b) was
a quick hack that hardly ever worked, and (c) depended, in the PC
version, on proprietary libraries for communications functions.  The
"WKERMIT" Chuck is referring to did not allow long packets, had horrible
error-recovery characteristics, and because of the communications
strategies used, would get hopelessly hung if there were any confusion
about modem signals, to the point that you'd have to reboot your PC, and
it did not support any kind of flow control.  Furthermore, it had no
terminal emulator, no script language, no convenience features like key
mapping, and none of the server-related Kermit protocol functions are
supported.  Anybody who wants to check out this "compact, high
performance version" of Kermit for themselves, feel free:

  host kermit.columbia.edu, directory kermit/extra, files wkermit.*.
  Note: wkermit.exe is binary, the rest are text.

In short, it is a primitive package and its Kermit protocol
implementation is limited and fragile.  It was a stopgap commissioned
by The Source [an early online service], cobbled together in a hurry by
a contract programmer from even-then obsolete C-Kermit source code,
to be used until the real thing came along.  Although it was some time
in coming, the real thing did, indeed, come along, and WKERMIT was
promptly retired.

> Columbia could have improved on this situation by developing a
> compact, high performance version of the WKERMIT (The Source)
> Kermit driver that could be used by bulletin boards, Telix,
> ProComm, Qmodem, et al.  Perhaps it is not too late for Columbia
> to correct the situation.  
>
Red Herring #2 -- Suppose we rephrase this as: "Omen Technology could
have improved on this situation by developing a compact, high
performance version of the Zmodem-90(TM)-Moby(TM)-Turbo(TM) driver that
could be used by bulletin boards, Telix, ProComm, Qmodem, et al.
Perhaps it is not too late for Omen Technology to correct the situation."

SHOOTOUT RESULTS

Chuck says:
> Last July Columbia University used its non-profit mail permit to
> distribute thousands of copies of Kermit News Number 5.
>
Point for Chuck.  Yes, as a nonprofit institution, we do indeed get a
break on bulk 3rd-class mailings.  So what?

> In "The Truth about Kermit File Transfer Performance" tenured
> Columbia University professor...
>
That I'm not.

> ...Frank da Cruz proudly announces that Kermit "outperforms X-, Y-,
> and ZMODEM protocol transfers every time."

Out of context.  Anybody who reads the article knows that that
"ZMODEM protocol transfers" refers to the ones that were performed in
the suite of tests, using the specified software (Procomm, Telix), and
"every time" refers to each test that was performed.  Again, I invite
anybody who is interested, and especially anyone who feels compelled
to take sides on this issue, to actually read the article.  I will be
glad to send you printed copy if you send me your postal address.  You
can also ftp it from kermit.columbia.edu, directory kermit/e, files:

  newsn5.txt (ASCII)
  newsn5.ps  (PostScript)

> It is not my intention to defend a competitor's product.  But,
> the reported Kermit efficiency of Procomm Plus (93%) and Zstem
> (97%) are very close to that of Columbia's own MSKermit (99%).
>
Right; I did not want to imply that all non-Columbia PC Kermit
implementations are lousy, but I did want to show that MS-DOS Kermit
is equal to or better than the best of them.  I also left out some
others that were ridiculously bad.

> Frank's 104% figure for MSKermit is misleading because the reduced
> control character prefixing responsible for the MSKermit speedup also
> works sending to Procomm Plus.  Columbia does not disclose this
> inconvenient result.  In fact, C-Kermit sending to Procomm Plus
> transferred some of Columbia's test files in less time than the
> C-Kermit-MSKermit combination required.
> 
Score half a point for Chuck.  It's true, I did not know that Procomm
could handle unprefixed control characters.  In fact, it can handle
*some* unprefixed control characters.  But carriage return (Ctrl-M) is
not among them, so all we gain in text file transfers in this case is
the ability to send linefeed bare.  When I repeated the test downloading
the same text file to Procomm under the same conditions as the original
test, except with all possible control characters unprefixed, Procomm's
score went up from 93% to 94%.

> After shading the truth about competitors' Kermit downloading
> performance, Frank's paper proceeds to redefine the YMODEM protocol
> I developed in the 1980's.
>
Sorry if I misrepresented YMODEM -- Nevertheless, the YMODEM protocol
used in the tests was as stated: sb on the host, and YMODEM protocol
in the PC software.  Whatever it is!

> Thanks to Columbia's ignorance of file transfer protocols I don't know
> what protocol they actually used for the "XMODEM" and "YMODEM" tests
> listed in Columbia's True-Life Benchmarks.
>
It's clearly stated in the article: sx and sb on the host, XMODEM or
YMODEM protocol in the PC software.

> But Columbia's published numbers reveal a seriously slovenly
> experimental procedure.  XMODEM and ZMODEM in all their forms transmit
> file data verbatim, without any prefixing.  As a result, data patterns
> have no effect on X/YMODEM throughput.
>
The results given in the article are exactly as reported by the
software, and each trial was run three or more times.  Theory is fine,
but in the real world all sorts of factors can cause variations.  We
have been through this time and again.

> In addition, Columbia Kermit programs significantly understate the
> time required to perform a file transfer.  Kermit reports a file
> transfer took 112.98 seconds when in fact the machines were tied up
> more than nine seconds longer.
>
Here's what actually happens: if you install C-Kermit according to
instructions, it comes with an initialization file that reads in your
dialing and services directories and defines all sorts of macros.
Obviously, this can take some time, especially on slow computers.  These
are convenience features that have nothing to do with file transfer,
that can be skipped.  sz does not have features like script programming,
dialing directories (let alone dialing), and so starts up faster.

If you want Kermit to start up as fast as sz, you can tell it to skip
the initialization file and give the file-sending and parameter-setting
commands on the command line, for example:

  kermit -Y -v 5 -e 5000 -s foo.zip

For real speed, you can even build a nonstandard version of Kermit that
excludes all sorts of time-and-space-consuming features: the interactive
command parser, the built-in debugger, the character-set translator,
etc, and reduce the startup time to practically nil AND make it run
faster too.  I did not do that, because it would not be representative
of the C-Kermit software that people actually use.

Second, there is a deliberate default delay of 5 seconds after you give
a SEND command to a remote-mode C-Kermit, to give the user time to
"escape back" to the local Kermit and give a RECEIVE command.  This is
purely a convenience feature and has nothing to do with the protocol --
it gives the user time to read an instructional message and then to
escape back without seeing the first packet on the screen.  Of course
you can set the delay to be any length of time you want, including zero,
and you can disable this feature altogether.  (AND you can also use the
autodownload feature to obviate the need for escaping back altogether --
yes: Kermit has autodownload too, *and* autoupload).

For the record, Kermit's timers start ticking when the first packet is
sent or received, and stop when the last packet is sent or received.

> One set of Columbia's measurements was so preposterous that I
> simply couldn't resist having a bit of fun with it.  We noticed
> that cutting the communications speed from 19200 to 9600
> actually increased the speed of a Columbia Kermit file transfer
> from 2648 to 2736 characters per second.  (p.13, Tables 2 and 5.)
>
This is indeed what happened.  Explain it any way you like.

> One of the tricks Columbia used to discredit ZMODEM in their
> "True-Life Benchmarks" was to carefully select files with
> redundant data that responds unusually well to Kermit's run
> length compression while at the same time refusing to use ZMODEM
> compression.
> 
In fact, we chose four types of files:

  1. A typical text file (the IBM Mainframe Kermit manual).
  2. A UNIX binary file, which, admittedly, had big runs of zeros.
  3. An MS-DOS binary (.EXE) file (MS-DOS Kermit itself).
  4. A ZIP file (the MS-DOS Kermit distribution file set).

Each of these files illustrates properties of the two file transfer
protocols.  Nothing is rigged or pre-engineered here -- these are
perfectly normal files.  We could easily have left out (for example) the
ZIP file, which would have skewed the results far more in favor of
Kermit, or picked a text file that could have been compressed a lot more.

> The most egregious instance of this deception is seen with Columbia's
> selection of a Sun Sparc binary of the "uuencode" program.  This is a
> tiny program stored in a 24576 byte file.  All but a few thousand are
> nulls.  Naturally this does wonders for Kermit transfer speeds.  Had
> Columbia's protocol boffins read the sz 3.24 documentation they could
> have discovered that ZMODEM compression does even better.
>
But only if you use it with PC software that includes ZMODEM-90(TM)-etc
extensions.  I actually did use the compression option (-Z) on sz, but
it had no effect since, apparently, Procomm and Telix don't do anything
with it.  And yes, the "uuencode" file was chosen deliberately to
illustrate the dramatic effects of Kermit compression on this type of
file.  So what?  People actually do transfer this type of file from
time to time.

> Real world users download mostly compressed files,...
>
This is debatable.  As I pointed out yesterday, the readers of this
newsgroup are are not typical of the world's computer users at large.

> ... and here the winner is YMODEM-g, closely followed by MobyTurbo(Tm)
> ZMODEM, regular ZMODEM, with Kermit bringing up the rear.
> 
YMODEM-g has not much more resemblence to a file transfer protocol than
Kermit's TRANSMIT command, or "copy foo.zip com1".  If it works, of
course it's fast, because it doesn't do anything other than blast the
data at the other end, all in one piece, with a filename on the front
and checksum on the end (I'm sure Chuck will correct me if this is a gross
misrepresentation of YMODEM-g technology).  Recovery from transmission
errors is, to use Chuck's words, "by sudden death".

> So why is Kermit not the fastest when it only prefixes a few control
> characters?  The question is incorrect.  Columbia claims that only 0,
> 1, and 129 need to be prefixed, but this doesn't work sending to
> MSKermit 3.11.
>
Of course it doesn't, we never said it did.  We were using MS-DOS Kermit
version 3.13, which is the first release to support this feature.  Also,
our advice about which characters need to be prefixed goes into a lot
more detail -- there are no simple formulas.  Today, for example, I
found that when using a local Annex terminal server, the following
characters must be prefixed in addition to whatever might be required by
the Kermit programs themselves: 15 18 21 23 29 127 143 146 149 151 157
255.  Not all connections in the world are totally transparent, the way
BBS users are accustomed to.

> The most impressive demonstration, and the likely reason Frank da Cruz
> did not choose to appear at the Shootout is Kermit's performance in
> the noise test.  Or, to be more precise, Kermit's non-performance.  In
> the Kermit News True-Life Benchmarks, Frank da Cruz specified a window
> size of 5 and a packet length of 5000.  Undoubtedly Frank chose this
> long packet length to minimize Kermit's high per packet overhead
> compared to ZMODEM SUBpackets.
> 
8-10 bytes out of 5000 = 0.18 percent.  Who is going to quibble about
that?  Of course I chose long packets to improve performance -- that's
what they're for.  This is all explained in the article.

> XMODEM, YMODEM and Kermit cannot resend a packet with a different
> size.  The problem is even worse with Kermit's selective
> retransmission protocol.  When we attempted to replicate Columbia's
> 9600 bps plus noise test (Table 5) Kermit failed every time.  Well,
> almost every time.  The first few times Kermit worked, but that was
> only because C-Kermit quietly refused to send the specified 5000 byte
> packets because a needed "set buffer" command was not included.  When
> Kermit actually uses the specified 5000 byte packets with noise bursts
> at 2 second intervals, no data packets get through.  Why?  It takes 5
> seconds to send a 5000 byte packet at 9600 bps but the specified noise
> bursts come faster than that.  Kermit croaks every time unless the Jim
> Kirk Kobiashi Maru procedure is used (relax the test).
> 
Chuck makes a good point here.  He's right: if the noise bursts came
at precise 2-second intervals, the first data packet would never have
gotten through.  But the noise bursts were being generated on a UNIX
system, whose actions are governed by a scheduler, and are therefore
not precise.   Once the first data packet got through, the remaining
packets were shortened automatically.

I deliberately chose the worst possible conditions under which Kermit
could function at all with the same settings that I was using in the
preceding tests.  I could have sweetened the results considerably by
tailoring Kermit's settings *in advance* for noise resistence, and
increasing the noise level.  For example, noise every 1/2 second, and
short, 94-byte packets (which are, by the way, Kermit's default) rather
than 5K packets.  Kermit would have come out even further ahead than it
did in the article.

> I made an informal survey of the guests at the shootout.  As so
> many have noted, line noise today manifests itself mostly in
> disconnected calls.
>
We've been through this before too.  Just because this is 1994, you
can't assume that all telephone connections are clean (here in the New
York City area, T1 clock slippage is still a frequent occurrence).  Ask
residents of other countries -- especially in Eastern Europe, the former
Soviet Union, China, Africa, and South America, about their telephone
systems.  We also cannot assume that everybody in the world is using
error-correcting modems.

Even assuming all that were true -- no more noise, no more errors -- we
still have other sources of error, overlooked all too often: improperly
(or un-) implemented flow control, data overruns on PCs that do not have
buffered UARTs, interrupt conflicts, etc.

> When this happens ZMODEM's Crash Recovery is relevant, allowing the
> safe resumption of interrupted file transfers.  Since Kermit has no
> such feature Columbia chose not to discuss this most vital of ZMODEM's
> many features.
> 
ZMODEM's crash recovery is indeed a useful feature, but...

 (a) It only works for binary-mode transfers.

 (b) It only works when the file sender has a stream-oriented file
     system that supports an "fseek()" operation.

It doesn't work for text-mode transfers because files can change size
during text-mode transfer because of record-format conversion.  It
doesn't work on record-oriented file systems, or with record-oriented
file formats.

A fully capable "crash recovery" feature would work for both text and
binary mode transfers, and it would not make any assumptions about the
features of the file system.   It would be built into the protocol at
the session layer.  It would involve checkpoints, commitments, and
protocol messages that would allow resumption not only of an interrupted
file transfer, but even of the connection itself.

These are complicated issues requiring a lot more thought than "hmmm,
how long is the file?  n bytes?  OK, fseek(n) and start blasting away".
This kind of "crash recovery" could be added to Kermit software with
about five minutes' programming time, but it would be useful only in the
circumscribed world where Zmodem's method is also useful, and Kermit
caters to a more diverse audience.  When crash recovery appears in
Kermit protocol and software, it will be generally useful.

Later, Chuck says:
> This historical dissertation overlooks one critical fact.  If a
> desired text translation is not performed by the file transfer
> protocol, the translation can be made later.  No information lost.
>
> But when Kermit modifies files with spurious text translations
> that file is destroyed. 
> 
> In the real world one cannot equate the two situations.
>
No matter whether the default transfer mode is text or binary, somebody
will transfer files in the wrong mode; it can't be avoided.  Chuck is
right, transferring a binary file in text mode results in garbage.  But:

  "If a desired text translation is not performed by the file transfer
  protocol, the translation can be made later.  No information lost."

Is it?  Maybe this is true in the English (ASCII) speaking world.  Do
any readers of this newsgroup transfer textual data written in Albanian,
Bulgarian, Byelorussian, Czech, Danish, Dutch, Faeroese, Finnish,
French, German, Hebrew, Hungarian, Icelandic, Irish, Italian, Japanese,
Macedonian, Norwegian, Polish, Portuguese, Romanian, Russian,
Serbocroatian, Slovak, Slovene, Spanish, Swedish, or Ukrainian?  Between
unlike systems that use totally different encodings for the "special
characters" of your language?  Did you know that Kermit handles the
character sets for all these languages, and more?

Let's look at just (say) German.  Here are a few of the common *and*
*totally* *different* encodings I can think of for German: German ISO
646, ISO 8859-1 (and -2), IBM PC code pages 437, 850, and numerous
others; IBM Mainframe (EBCDIC) code pages 037, 500, and numerous others;
DEC Multinational, Data General International, Macintosh, Atari, HP
Roman8, NeXTSTEP.  Is it the responsibility of every German-speaking
computer user to know all of these character sets and have translation
utilities that work between every pair of them on every kind of computer?

OK, so everybody should speak English and then everything works.  But
then what about record formats?  Suppose I transfer a text file from a
record-oriented system in binary mode by mistake.  I lose the record
boundaries.  Suppose it's a BASIC or FORTRAN program, or a poem.  Vital
information is lost -- the program won't compile, the poem won't scan.

In an ideal world, computers would have been designed from the beginning
with considerations like this in mind.  Imagine how easy all our lives
would be if file systems and organizations and character sets were all
compatible?  Then we would have one and only one transfer mode, and it
would always work, and always produce useful results.  But this is the
real world, in which nobody can agree on anything, and everyone
proclaims their own way of doing things a "standard".

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-


Newsgroups: comp.dcom.modems
Path: cs.utk.edu!ornl!rsg1.er.usgs.gov!darwin.sura.net!howland.reston.ans.net
      !cs.utexas.edu!uunet!nwnexus!camco!camco!not-for-mail
Date: 23 Feb 1994 19:42:27 -0800
Organization: Celestial Software, Mercer Island, WA
Message-ID: <2kh7n3$h26@camco.celestial.com>
References: <CLp49n.1u9M@tsh.com>
NNTP-Posting-Host: camco.celestial.com
From: bill@camco.celestial.com (Bill Campbell)
Subject: Re: SCO kermit

In <CLp49n.1u9M@tsh.com> frank@tsh.com (Frank Mostek) writes:
:
:Would a kind soul please email me the SCO version of kermit?  I bought
:the source, but our customer does not have the C compiler on the SCO
:box, and I don't have access to a SCO box.

Considering that the binary for 3.2v4 is 437632 stripped, this
isn't really a candidate for e-mail.  I have it on ftp.celestial.com
if you have ftp access.

Bill

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.dcom.modems
Path: cs.utk.edu!gatech!howland.reston.ans.net!europa.eng.gtefsd.com
      !library.ucla.edu!ihnp4.ucsd.edu!dog.ee.lbl.gov!hellgate.utah.edu
      !cc.usu.edu!jrd
Message-ID: <1994Mar7.093039.12780@cc.usu.edu>
Date: 7 Mar 94 09:30:39 MDT
References: <1994Mar7.134440.29536@ibr.cs.tu-bs.de>
Organization: Utah State University
From: jrd@cc.usu.edu (Joe Doupnik)
Subject: Re: Kermit: How to get rid of echos ?

In article <1994Mar7.134440.29536@ibr.cs.tu-bs.de>,
 c0033010@ws.rz.tu-bs.de (Sven Kuehne) writes:
> 
> I don't know if my question will fit into this newsgroup, but comp.protocols.
> kermit seems to be a bit deserted ...
> 
> How can I tell Kermit to be quiet when executing a script ? I only wanna
> see thing I write out by using 'echo ...'. I don't want things from
> 'output ...' or the replies of the other side written to the screen. I've
> tried 'set local-echo off' but it doesn't help !
> 
> Does anyone know how to achieve this ?! It might be simple ...
> Sven
> #===========================================================================#
> # Sven Kuehne	        Rechenzentrum		tel   +49 531 391-5548        #
> #			TU Braunschweig		fax   +49 531 391-5549        #
> # Abteilung Netze und	Hans-Sommer-Str. 65	email c0033010@ws.rz.tu-bs.de #
> # Arbeitsplatzrechner	D-38092 Braunschweig	      s.kuehne@tu-bs.de       #
> #===========================================================================#

	Two answers for you.

	1. As discussed in the user's manual, the book "Using MS-DOS Kermit",
the script commands INPUT and OUTPUT control their echoing with 
SET INPUT-ECHO ON or OFF. Maybe you need to acquire the manual, details on
screen two of the Help command.

	2. The Kermit News group material goes straight to Columbia rather
than being reflected worldwide.  
        Joe D.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!stc06.CTD.ORNL.GOV!rsg1.er.usgs.gov!jobone
      !newsxfer.itd.umich.edu!caen!usenet.cis.ufl.edu!usenet.eel.ufl.edu
      !news.mathworks.com!hookup!news.moneng.mei.com!howland.reston.ans.net
      !news.sprintlink.net!EU.net!sun4nl!echelon!kees
Organization: Echelon Consultancy, Enschede, The Netherlands
Date: Mon, 31 Oct 1994 17:01:10 GMT
Message-ID: <CyJr9y.3CA@echelon.nl>
References: <CyID9G.HFK@echelon.nl> <392u8h$hvr@apakabar.cc.columbia.edu>
From: kees@echelon.nl (Kees Hendrikse)
Subject: Re: ANSI (Was: MS-DOS Kermit 3.14 Beta-9 Ready)


In <392u8h$hvr@apakabar.cc.columbia.edu> Frank da Cruz writes:
>
> In article <CyID9G.HFK@echelon.nl> kees@echelon.nl (Kees Hendrikse) writes:
>> (...) would it be very hard to also implements the 'SCO console' emulation,
>> a.k.a. SCO-ANSI?

> I believe this is basically the current ANSI screen handling, but with the
> keyboard handled differently -- instead of transmitting the characters
> associated with the keys, the scan codes are transmitted.

Scan codes are optional (settable with stty for scan-code terminals). In 
Ascii-mode the function keys send escape sequences. F1 sends ESC[M, 
shift-F1 sends ESC[Y etc. Screen handling is PC-Ansi/vt100-like, except for
scrolling, coloring, special things like 'send-screen-to-host'. 

> To the best of my knowledge, this is used only for communicating with the
> SCO console driver.  True?

SCO ansi can be used via the serial driver as well, by using the 'ansi' 
termcap/terminfo entries. Quite a few terminal-emulation packages have a
sco-ansi option now (James River's Ice-ten, for example), which makes it
the emulation of choice with these programs.

-- 
Kees Hendrikse                                | email:   kees@echelon.nl
                                              |
ECHELON consultancy and software development  | phone: +31 (0)53 836 585
PO Box 545, 7500AM Enschede, The Netherlands  | fax:   +31 (0)53 337 415

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!mp.cs.niu.edu
      !vixen.cso.uiuc.edu!howland.reston.ans.net!europa.eng.gtefsd.com
      !news.mathworks.com!udel!news-4.nss.udel.edu!chopin.udel.edu!not-for-mail
Date: 1 Nov 1994 16:10:18 -0500
Organization: Broken Toys Unlimited
Message-ID: <396arq$fqc@chopin.udel.edu>
References: <1994Nov1.100933.2067@gems.vcu.edu>
From: darkstar@chopin.udel.edu (Jerry Alexandratos)
Subject: Re: More lines per page?

In article <1994Nov1.100933.2067@gems.vcu.edu>,
Brainwave Surfer <agnew@gems.vcu.edu> wrote:
:Dear Netbeings,
:  I have a wonderful relationship with MS-dos kermit.  apart from dos,
:the package is fine.  I'd like to figure out how to set the video such
:that I can use one of the other modes, like 50 lines per screen, etc.
:Everything else is ok, but i'm lusting for more of the page like I can
:get on my Decterms in Motif.
:
:Jim

[sig deleted]

Okay, here's what you need to do on both ends of the connection.

PC--make sure you've got either an EGA card (for 43 line mode) or a VGA
    card (for 50 line mode).  Some cards support some funky things like
    60 lines under some Super-VGA setting or another.
    make sure you load an ANSI driver like ansi.sys or nnansi.sys
    issue the following mode command `mode con: lines=50'.
    start kermit.

UNIX-connect to host.
     issue an eval `tset -sQI <your-term-emulation>` command to set the
     TERM and TERMCAP environment variables.  For example eval `tset
     -sQI vt220` evaluates and sets the variables for vt220 term.  Make
     sure that you put in the ``I'' argument.  If you don't, then
     you'll see your screen cut in half and only the first 25 lines
     being drawn on.  If this happens, then you'll have to go to the
     kermit command line and do a `ru mode con: lines=50' command to
     reset your local terminal.
     Issue the `stty rows 49' command to set the number of rows (or
     `stty rows 50' if you don't use the status line at the bottom of
     the screen), followed by a `reset' command.

That should do it.  I don't know how to do this if you're connecting to
other types of host.  I think that for IBM's it doesn't make a
difference if they're in fullscreen mode, then they'll use all of the
available lines.  As for other types of hosts, your mileage may vary.

        --Jerry

-- 
|>  Jerry Alexandratos                **  "vengo de la tierra del    <|
|>  darkstar@strauss.udel.edu         **   fuego ten cuidado cuando  <|
|>  darkstar@canary.pearson.udel.edu  **   llamas mi nombre..."      <|

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!mp.cs.niu.edu
      !vixen.cso.uiuc.edu!howland.reston.ans.net!gatech
      !news-feed-1.peachnet.edu!emory!metro.atlanta.com!spcuna!ritz!kudut
References: <DRW.94Nov1095927@runge.mit.edu>
Organization: Mordor International BBS - Jersey City, NJ
Date: Tue, 1 Nov 1994 18:03:47 GMT
Message-ID: <CyLouB.6Lu@ritz.mordor.com>
From: kudut@ritz.mordor.com (Ken Udut)
Subject: Re: Receiving files "automatically"


In article <DRW.94Nov1095927@runge.mit.edu>,
 drw@runge.mit.edu (Dale R. Worley) writes:
>
>I'd like to know if there's any way that I can get (MS-)Kermit to
>receive a file "automatically" when the remote end runs a Kermit that
>is attempting to send a file.  As far as I can tell, right now once I
>start the remote Kermit sending, I have to get out of CONNECT, and
>then manually issue a RECEIVE command, then reconnect.  This seems
>quite pointless, so probably there is a way to make it all happen
>automatically.  But I haven't been able to find it in the
>documentation.

What version of Kermit are you running?  Latest beta test is 3.14, revision
10, available at kermit.columbia.edu under the directory:
/kermit/test/bin/mstibm.zip

To automatically send/receive files via Kermit, please check out the
KERMIT.UPD file that comes with the beta.  It explains how to engage
autoupload/download with Kermit.  

NOTE: MS-Kermit must be version 3.14, and C-Kermit (assuming that is
what is on the host side) must be version 190.  

>Also, is there a "dial this number and connect me to it" command?
>So far, I have been stuck doing a CONNECT and then manually issuing
>ATDT to the modem.

To dial, type "dial xxx-xxxx" or edit the DIALUPS.TXT file and add
the phone number you wish to dial in the format specified in that file.

If I'm not mistaken, if you use the "dial" macro, it will connect
you.  Otherwise, if you are a purist and want to do ATDT before the
phone numbers, then put a CONNECT at the bottom of your MSCUSTOM.INI.

>And why is it that Kermit comes with almost no documentation?  

It comes with a *lot* of documentation.  The KERMIT.BWR and KERMIT.UPD
file are both sets of documentation.  If you issue a HELP at the Kermit
prompt, you get more information.  While you are typing in a comment,
but you are not sure what to type in next, press a ?, and you will
magically get help for that command.

Indeed, you can learn almost everything there is to know about MS-Kermit,
programming scripts, macros, etc. (which aren't really all that hard!)
simply by using the information provided with the Kermit distribution.

>Or is the rumor that Kermit is "free" just a front for selling books?

Indeed - it is a rumour.  Is it true?  No.


Ken
kudut@ritz.mordor.com
LISTOWNER of Y-RIGHTS@SJUVM.STJOHNS.EDU-'discussion on the rights of kids/teens

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!gatech!howland.reston.ans.net!wupost!simtel.coast.net!w8sdz
Message-ID: <9411030524.AA13559@SimTel.Coast.NET>
Date: Thu, 3 Nov 1994 05:24:58 GMT
Organization: SimTel, the Coast to Coast Software Repository (tm)
References: <397oln$cp3@israel-info.datasrv.co.il>
From: w8sdz@SimTel.Coast.NET (Keith Petersen)
Subject: Re: Zmodem on kermit


4dsoft@zeus.datasrv.co.il (4th Dimension) writes:
>
>Im looking for a way to perform file transfer via the Zmodem utilities
>while working in kermit.
>
>Examples will be appreciates.

;
;Thanks to Jason Merrill <jmerrill@jarthur.claremont.edu> for this
;define to add zmodem protocol transfers. Add it to your mskermit.ini.
;
define rz run dsz F ha cts est 0 14400 rz \%1 \%2,
define sz run dsz F ha both est 0 14400 pB4096 sz \%1 \%2,
define t run dsz F ha cts est 0 14400 t \%1 \%2,

Keith
-- 
Keith Petersen
Moderator of comp.archives.msdos.announce and the MSDOS-Ann mailing list
Internet: w8sdz@SimTel.Coast.NET     or       w8sdz@Vela.ACS.Oakland.Edu
Uucp: uunet!umich!vela!w8sdz                       BITNET: w8sdz@OAKLAND

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!gatech!howland.reston.ans.net!cs.utexas.edu!news.cs.utah.edu
      !cc.usu.edu!jrd
Message-ID: <1994Nov3.223304.31997@cc.usu.edu>
Date: 3 Nov 94 22:33:04 MDT
References: <CypL0A.1L1@physics.purdue.edu>
Organization: Utah State University
From: jrd@cc.usu.edu (Joe Doupnik)
Subject: Re: 132-column Mode and MS-Kermit Verbs


In article <CypL0A.1L1@physics.purdue.edu>,
     korty@london.physics.purdue.edu (Andrew J. Korty) writes:
>
> My friend and I just discovered the world of 132-column mode, and we
> have a few questions for all who are familiar with its numerous
> wonders.
> 
> 1.  My friend wants to define a key to switch between the modes while
> in terminal emulation mode, but we couldn't find a verb that does
> this.  Is using verbs the only way?  Also, we'd like to know if
> there's a way to define a key to escape back to command mode and
> execute a Kermit command (of any kind).

	Check the user's manual, the book "Using MS-DOS Kermit" whose
details are given on the Kermit HELP screen and the *.UPD files issued
since then. You can assign a Kermit macro as the definition of a key. 
The macro can do anything you could say at the Kermit prompt, including 
issue SET TERM commands. Syntax is   SET KEY keycode {\Kmacroname}
and the \K must be inside the curly braces.
 
> 2.  I'm running DOS Kermit under OS/2 in a full-screen DOS session.
> When I use 132-column mode, everything works fine until I switch back
> to the desktop, at which time the video proceeds to get completely
> screwed up.  The only way to save things is to go back to Kermit and
> do an Alt-X (which puts the screen back in 80 column-mode) and then go
> back to the desktop (which is still screwed up) and activate a screen
> saver or something to refresh the screen.

	It's between OS/2 and your video driver and your monitor.
Please remember that there is no standard on 132 column video modes so
that OS/2 has no idea of what state the display is in and hence little
idea of what to do about it. Better video drivers could help more,
however.
 
> 3.  Also, Kermit's documentation claims that it can auto-detect the
> screen width requested by the host, but doesn't seem to.

	Maybe you mean the opposite here. Hosts can request 80 or 132
columns from VTxxx terminals, nothing more. Kermit obeys those requests.
Perhaps you mean that Kermit can tell the host its current screen size
upon request, which is true. There is no "auto-detect" in this arrangement,
by either host or terminal emulator. Kermit can also report screen size
in Telnet Options packets, if the host agrees to do so.
	Joe D.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-


Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!usenet.eel.ufl.edu
      !news.mathworks.com!hookup!news.moneng.mei.com!howland.reston.ans.net
      !sol.ctr.columbia.edu!news.columbia.edu!usenet
Date: 7 Nov 1994 22:26:13 GMT
Organization: Columbia University
Message-ID: <39m9i5$e00@apakabar.cc.columbia.edu>
References: <39lv9v$2s@vixen.cso.uiuc.edu>
From: fdc@fdc.cc.columbia.edu (Frank da Cruz)
Subject: Re: Will the New MS-DOS Kermit have MINPUT?


In article <39lv9v$2s@vixen.cso.uiuc.edu> adam@symcom.math.uiuc.edu (Adam H.  
Lewenberg) writes:
> 
> Will the New MS-DOS Kermit have the MINPUT command? I would like my 
> scripts to work in both MS-DOS Kermit and C-Kermit, so it would be
> nice if MINPUT was supported n MS-DOS Kermit. Adam Lewenberg
>

It is kind of late in the Beta cycle to consider adding this.  However,
you might be able to make do by defining an MINPUT macro, something like
this (courtesy of James Sturdevant):

define minput set alarm \%1,-
:top,-
if alarm end 1,-
input 1 \%2,if success asg mynput 1,if success end 0,-
if not def \%3 goto top,reinp 0 \%3,if succ asg mynput 2,if succ end 0,-
if not def \%4 goto top,reinp 0 \%4,if succ asg mynput 3,if succ end 0,-
if not def \%5 goto top,reinp 0 \%5,if succ asg mynput 4,if succ end 0,-
if not def \%6 goto top,reinp 0 \%6,if succ asg mynput 5,if succ end 0,-
if not def \%7 goto top,reinp 0 \%7,if succ asg mynput 6,if succ end 0,-
if not def \%8 goto top,reinp 0 \%8,if succ asg mynput 7,if succ end 0,-
if not def \%9 goto top,reinp 0 \%9,if succ asg mynput 8,if succ end 0,-
goto top

and then use it like this:


    minput 60 CONNECT ERROR {NO CARRIER} BUSY RING
    if fail errfail {No response from the modem}
    if eq \v(program) C-Kermit asg mynput \v(minput)
    goto CASE_\m(mynput)

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!usenet.eel.ufl.edu!news.mathworks.com!hookup!swrinde!cs.utexas.edu!uunet!winternet.com!jamess
From: jamess@winternet.com (James Sturdevant)
Subject: Re: Will the New MS-DOS Kermit have MINPUT?
Date: 8 Nov 1994 23:35:50 GMT
Organization: StarNet Communications, Inc
Lines: 21
Message-ID: <39p20m$rn1@blackice.winternet.com>
References: <39lv9v$2s@vixen.cso.uiuc.edu> <39m9i5$e00@apakabar.cc.columbia.edu> <jhurwitCyxwMo.JG7@netcom.com>
NNTP-Posting-Host: icicle.winternet.com
X-Newsreader: TIN [version 1.2 PL2]

Jeffrey Hurwit (jhurwit@netcom.com) wrote:
: In article <39m9i5$e00@apakabar.cc.columbia.edu>, 
: Frank da Cruz (fdc@fdc.cc.columbia.edu) wrote:

: >In article <39lv9v$2s@vixen.cso.uiuc.edu> adam@symcom.math.uiuc.edu (Adam H.  
: >Lewenberg) writes:
: >> 
: >> Will the New MS-DOS Kermit have the MINPUT command? I would like my 
: >> scripts to work in both MS-DOS Kermit and C-Kermit, so it would be
: >> nice if MINPUT was supported n MS-DOS Kermit. Adam Lewenberg

:     [macro and example of how to use it deleted]

:     Yes, this would work, but it's a little big, and memory is at a
:     premium for some of us.  I tend to use take files more, and save
:     memory for key settings and screen rollback.

Well, there is no reason that you can't put the text into a take file and
then define minput to take the take file.  Macros are no more than memory
resident take files.

JamesS

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!usenet.eel.ufl.edu
      !news.mathworks.com!udel!gatech!howland.reston.ans.net
      !sol.ctr.columbia.edu!news.columbia.edu!usenet
Date: 8 Nov 1994 16:52:40 GMT
Organization: Columbia University
Message-ID: <39oaco$5us@apakabar.cc.columbia.edu>
References: <DRW.94Nov8110735@runge.mit.edu>
From: fdc@fdc.cc.columbia.edu (Frank da Cruz)
Subject: Re: Receiving files "automatically"


In article <DRW.94Nov8110735@runge.mit.edu> drw@runge.mit.edu (Dale R.  
Worley) writes:
> Hmmm...  Just checked my KERMIT.HLP (version 3.13, gotten from
> watsun.cc.columbia.edu, I think, but I can't check right now, its FTP
> server is hosed), and it doesn't say that, although it does mention
> the DIAL command in passing at one point.
> 
My comments were in reference to version 3.14.  I think you will find a
lot of improvements in version 3.14 over 3.13.

> If I wanted to buy the manual for a telecomm program, I'd go to my
> local software store and buy Procomm.
>

A noble attitude.  In other words, since you don't want to buy a manual,
you expect real human people to work for you, for free.  To develop
software for you AND document it, AND answer your questions, all for
free, and listen to your complaints about how they did it.

Please, go buy Procomm.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!stc06.CTD.ORNL.GOV!rsg1.er.usgs.gov!jobone
      !newsxfer.itd.umich.edu!zip.eecs.umich.edu!panix!news.mathworks.com
      !hookup!usc!howland.reston.ans.net!agate!dog.ee.lbl.gov!news.cs.utah.edu
      !cc.usu.edu!jrd
Message-ID: <1994Nov10.062523.32448@cc.usu.edu>
Date: 10 Nov 94 06:25:23 MDT
References: <39kmo6$k82@ctsc.hkbc.hk>
Organization: Utah State University
From: jrd@cc.usu.edu (Joe Doupnik)
Subject: Re: Can Kermit 3.14 run on PCTCP's ODIPKT


In article <39kmo6$k82@ctsc.hkbc.hk>, s11976@ctsc.hkbc.hk (PM Wong) writes:
>
> We have been using Kermit's telnet (over either packet driver or Novell's
> ODI, i.e. Da Lancinni's ODIPKT) for quite some time now. Recently some
> PCTCP's apps have to be run and we want to keep the user Kermit telnet.
> So it'll be handy if Kermit can run on top of PCTCP's ODIPKT
> (I don't want to go for the tnglass option as batch files have been
> written that use kermit's telnet all along)
----------

	I replied to this privately but here is a summary.

	FTP Inc's ODIPKT has a license detection feature in ARP which
prevents Kermit or other non-FTP program from accessing ARP packets
over their ODIPKT. Both FTP's stack and Kermit will run over Harvard's
ODIPKT, but never together.

	Joe D.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!news.msfc.nasa.gov!europa.eng.gtefsd.com
  !howland.reston.ans.net!news.sprintlink.net!nwnexus!news.halcyon.com!coho!ken
Date: 9 Nov 1994 19:46:33 GMT
Message-ID: <39r8up$37e@news.halcyon.com>
References: <JASON.94Nov3134526@idiom.com> <39eco1$h7k@news.halcyon.com>
From: ken@coho.halcyon.com (Ken Pizzini)
Subject: Re: C Kermit and meta keys


In article <39eco1$h7k@news.halcyon.com>,
Ken Pizzini <ken@chinook.halcyon.com> wrote:
>
> In article <JASON.94Nov3134526@idiom.com>,
> Jason Venner <jason@idiom.com> wrote:
>>
>>I use C-Kermit on my linux machine and dial into various unix hosts.
>>
>>Kermit does not seem to honor the meta key.
>>Is there a way to make it recongnize 8 bit characters and pass them through
>>to the remote side?
>
> set term byte 8

This was only a partial answer.  He also needed to
  set command bytesize 8

		--Ken Pizzini

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!gatech!howland.reston.ans.net!agate!dog.ee.lbl.gov!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Subject: Re: C-kermit -ix and binary transfers (not working)
Message-ID: <1994Nov19.182311.33328@cc.usu.edu>
Date: 19 Nov 94 18:23:11 MDT
References: <3am2rr$ete@vixen.cso.uiuc.edu>
Distribution: usa
Organization: Utah State University
Lines: 34

In article <3am2rr$ete@vixen.cso.uiuc.edu>, adam@symcom.math.uiuc.edu (Adam H. Lewenberg) writes:
> I am having some trouble sending binary files from the UNIX machine at
> school  to my OS/2 system at home. Here is what happens: 
> 
> 1. If I type kermit -ix, escape back to my OS/2 Ckermit, and then type
> 'get file.zip', my OS/2 C-kermit starts receiving the file but announces
> that the FILE TYPE is "TEXT (no translation)". Huh?
> 
> 2. If I start kermit with no command line options, type 
> 'set file type binary' at the C-kermit prompt, type 'send file.zip',
> escape back to the OS/2 C-kermit and then type 'receive' my OS/2
> C-kermit recieves the file and tells me the FILE TYPE is BINARY. 
> 
> 
> Why does 2 work while 1 does not? Shouldn't the '-ix' force all file
> transfers to be binary? I used to have NO trouble (before I installed
> the current version of the Unix C-kermit). 
> 
> The Unix C-kermit is 
> 
>    C-Kermit 5A(190), 4 Oct 94, for Solaris 2.x
>     Copyright (C) 1985, 1994,
>     
> while the OS/2 kermit is
> 
> C-Kermit 5A(190) BETA.23, 18 Sep 94, for OS/2 2.11 32-bit
>  Numeric: 501190
-----------

	I believe the release notes for C Kermit explain that the
client now controls file TYPE via the SET FILE TYPE command given
on the client. It's part of file attributes, named the "whatami"
component, where the client informs the server of its binary/text
state. It's a step forward, really.
	Joe D.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 1194 of comp.protocols.kermit.misc:
Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!uwm.edu!spool.mu.edu!agate!overload.lbl.gov!dog.ee.lbl.gov!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc,alt.winsock
Subject: Re: winsock/pkt dvr hack possible?
Message-ID: <1994Nov21.105430.33454@cc.usu.edu>
Date: 21 Nov 94 10:54:30 MDT
References: <3a67j8$j39@Mercury.mcs.com> <3anvci$dut@relay.tor.hookup.net>  <soren.223.000F87E0@aztec.co.za>
Organization: Utah State University
Lines: 29
Xref: cs.utk.edu comp.protocols.kermit.misc:1194 alt.winsock:12192

In article <soren.223.000F87E0@aztec.co.za>, soren@aztec.co.za (Soren Aalto) writes:
> In article <3aoc2h$bit@apakabar.cc.columbia.edu> jaltman@watsun.cc.columbia.edu (Jeffrey Altman) writes:
> 
>>>>        Jeff is correct. The top of a sockets API is a TCP stream channel of
>>>>bytes, not packets. "It could be done..." means creating a second TCP/IP
>>>>stack feeding from the streams channel and packaging it into TCP/IP over
>>>>Ethernet frames to be passed to the application. Not very desirable, nor 
>>>>realistic.
>>>>        Joe D.  
	<huge amount of repeated material omitted>
> And _that_ is the real problem.  I have wondered at times if the
> TCP/IP stack functionality and the Comms/SLIP/PPP functionality
> shouldn't be separated into two programs--you could have a
> packet driver that "reflects" stuff & attach the comms driver
> for SLIP/PPP/whatever to one side and Winsock to the other.
-----------
	Nice idea but not practical here. There are a great many
coupling threads (variables, calls) between the high level and comms
level material in Kermit so that control may be exercised and speed
retained. And there is much more to comms than serial or the internal
TCP/IP stack; SET PORT exhibits the list (and some choices transparently
encompass two or three variations from the same vendor).
	Winsock is for pure Windows programs, not for DOS programs.
	MS-DOS Kermit removes itself from comms channels when done with
them. Few commercial TCP/IP stacks do so (none that I know of). Were
winsock guys to get off the pot when done the problem would be smaller.
So please consider hounding your winsock vendor to go un-TSR upon last
close and to not be present until an application makes a demand.
	Joe D. 

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 1176 of comp.protocols.kermit.misc:
Path: cs.utk.edu!gatech!europa.eng.gtefsd.com!library.ucla.edu!agate!dog.ee.lbl.gov!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Question about ASK usage in MS-Kermit script
Message-ID: <1994Nov20.184340.33391@cc.usu.edu>
Date: 20 Nov 94 18:43:40 MDT
References: <CzLEG2.3Er@nntpa.cb.att.com>
Organization: Utah State University
Lines: 23

In article <CzLEG2.3Er@nntpa.cb.att.com>, mrbaker@hodcs.ho.att.com (-M.BAKER) writes:
> Hello:
> 
> I have a question about ASK.  I am writing an MS-Kermit 
> script which prompts
> the user to enter a filename, so I "ASK" for it.  No problem
> there.  But I would like to be able to detect if the user merely
> hits the ENTER key without typing anything else in first.
> 
> There is probably an obvious answer.  I have looked all over &
> experimented with no success.  I am a new user of Kermit, hence I
> am working from .HLP, .UPD, and .BWR while waiting for my copy
> of "the book" to arrive.
> 
> Can someone please help? (Examples appreciated)
-----------
	ask \%a prompt>
	prompt> <user presses Enter so \%a is empty and therefore undefined>
	if equ "\%a" "" echo The user did not provide text
or	if defined \%a  echo The user did provide text
and so on. Don't use {\%a} {} because they will parse out to empty, leaving
 if equ echo The ... which is not what is wanted.
	Joe D.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 1195 of comp.protocols.kermit.misc:
Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!gatech!howland.reston.ans.net!math.ohio-state.edu!caen!hearst.acc.Virginia.EDU!murdoch!fulton.seas.Virginia.EDU!esh6h
From: esh6h@fulton.seas.Virginia.EDU (Erik Hatcher)
Subject: Re: Is there anyway to quit kermit without hanging up?
Message-ID: <CzMyoM.38v@murdoch.acc.Virginia.EDU>
Sender: usenet@murdoch.acc.Virginia.EDU
Organization: University of Virginia
References: <Pine.OSF.3.91a.941120223713.15730A-100000@saul1.u.washington.edu> <3aqkqo$6ia@apakabar.cc.columbia.edu>
Date: Mon, 21 Nov 1994 21:07:34 GMT
Lines: 17


In VMS you can "exit" C-Kermit and keep the modem allocated.

I use the VMS ALLOCATE command and then go into Kermit and exit,
then go into Kermit again and when I'm done I DEALLOCATE.

Works like a charm and is extremely useful for my particular
application (queuing files to send to various "nodes" but
keeping the connection up in case the next file queued is
for the same node!).

	Erik
--
Erik Hatcher                           + "But every now and then we just have
http://fulton.seas.virginia.edu/~esh6h |  to howl with the wolves." 
                                       |        - Werner Heisenberg
---------------------------------------+-------------------------------------

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!gatech!howland.reston.ans.net!agate!dog.ee.lbl.gov
      !news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Subject: Re: Telnet Data Mark displays as "r" on MSK 3.13.
Message-ID: <1994Nov21.074313.33432@cc.usu.edu>
Date: 21 Nov 94 07:43:13 MDT
References: <785307785snx@djwhome.demon.co.uk>
Organization: Utah State University

In article <785307785snx@djwhome.demon.co.uk>, david@djwhome.demon.co.uk (David Woolley) writes:
> When an interrupt signal is generated on our SCO machines
> (3.2V4.2), MS-Kermit (3.13, patch about 13, but there are no
> obvious fixes listed up to patch 20**) displays an "r".  NCSA
> Telnet handles this correctly, and examining the event trace
> shows that a Telnet Data Mark signal is being sent.
> 
> This happens for both Telnet interrupts, and interrupts generated
> by sending the stty interrupt character.
> 
> This is really only a cosmetic problem, and normally results from
> being too lazy to change the interrupt character or remap the
> backspace key before talking to the machine in question.  It
> doesn't happen for SunOS 4.1.1.
> 
> ** the patch level 20 file is at home, not in the office.
--------
	Data Marks are rather rare events, but you ought not have seen
an "r" as a consequence. DMARK is 242 decimal, which after chopping the
high bit yields 114 decimal "r". But the DMARK should have been sent as
IAC DMARK (255 242), and the Kermit Telnet code would (quotes) have absorbed
both bytes.
	If you are still reading along, the way I understand this situation 
is the SCO machine was trying to flush bytes sent to the MSK client, by 
sending IAC DMARK in a TCP segment with the TCP URGENT bit set. The recepient
is supposed to discard all data up to and including the IAC DMARK. Folks have 
commented upon this less than clear or desirable "feature" of Telnet, and 
Kermit does not play that game. Just how much discarding should occur is 
ambiguous, and I chose not to chase down internal buffers to do the flush. 
In any case, the commands are really intended to be sent to servers where a 
job may be blocked unable to read the data stream for the Interrupt Process 
command pair IAC IP or similar; they ought not be sent to clients.
	If you still have the trace I'd appreciate receiving a copy.
	Thanks,
	Joe D.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 1265 of comp.protocols.kermit.misc:
Path: cs.utk.edu!gatech!bloom-beacon.mit.edu!panix!news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Kermit AS400 implementation ???
Date: 28 Nov 1994 14:02:12 GMT
Organization: Columbia University
Lines: 27
Message-ID: <3bcnt4$6v8@apakabar.cc.columbia.edu>
References: <3bcfii$mgq$1@mhadf.production.compuserve.com>
NNTP-Posting-Host: watsun.cc.columbia.edu
Keywords: AS/400

In article <3bcfii$mgq$1@mhadf.production.compuserve.com>,
Helmut Stoecklin  <100303.1604@CompuServe.COM> wrote:
> Is there a Kermit implementation for a IBM AS400 out in the field?
>
Of all the computers and operating systems in the world, there are only
a couple for which nobody has ever written any Kermit software, and the
AS/400 (and its predecessors, the Systems /34, /36, and /38) is one of
them.  Evidently this line of computers must be very hard to program;
from what little I know about them, everything is "different" -- the
text character set (it's not ASCII), the file system (probably record-
oriented), the communication methods (some kind of bizarre proprietary
"twinax" block-mode affair).  But we have hurdled such obstacles before
in the IBM mainframe world, thus we have the experience and know what is
required.

We get this question frequently, so there is definitely a big demand.
But we do not have an AS/400 ourselves for development, and even if we
did, we don't have a programmer to do the work.  Back in the early days
of the Kermit project, there were dozens of sites developing Kermit
software for every imagineable platform.  Maybe it's time to revive
that early spirit.

Anybody who is seriously interested in developing a Kermit program for
the AS/400 (or porting an existing program, such as C-Kermit) should
contact me.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 1385 of comp.protocols.kermit.misc:
Path: cs.utk.edu!stc06.CTD.ORNL.GOV!fnnews.fnal.gov!uwm.edu!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Arcnet Packet Driver?
Message-ID: <1994Dec9.112623.34998@cc.usu.edu>
Date: 9 Dec 94 11:26:23 MDT
References: <3c96mj$bej@cello.gina.calstate.edu>
Organization: Utah State University
Lines: 18

In article <3c96mj$bej@cello.gina.calstate.edu>, jpowell@cello.gina.calstate.edu (Larry Powell) writes:
>    Does MSkermit support the use of Arcnet packet drivers? 
>    The reason I ask is that the docs with the packet drivers say that
> to use arcnet, the client software must support it (arcnet) specifically.
> They make mention of KA9Q being the only known client to support it.
>    I use arcnet with Novell which works fine. I also tested kermit with
> the Netbios that comes with Novell (Lite) and it works also. I tried a
> brief test of the packet drivers ARCNET and ARCETHER and they both failed
> to initialize and/or self test.
>    Thanks,
> --Larry Powell   jpowell@cello.gina.calstate.edu, lpowell@eis.calstate.edu
---------------
	As the documentation says, MSK supports Ethernet (DIX/Ethernet_II/
BlueBook) and SLIP Packet Drivers, as well as working directly over ODI
for these and other lan topologies. Be sure to use MSK 3.14 beta or later
(when there is a later) for TCP/IP over Arcnet ODI drivers due to an ODI
ambiguitity problem.
	Joe D.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Path: cs.utk.edu!gatech!swrinde!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Flow Control in MS-DOS Kermit 3.14
Message-ID: <1994Dec9.201750.35072@cc.usu.edu>
Date: 9 Dec 94 20:17:50 MDT
References: <3c2me7$d29@sundog.tiac.net> <1994Dec7.095922.34783@cc.usu.edu> <3c7enb$atf@sundog.tiac.net>
Organization: Utah State University
Lines: 53

In article <3c7enb$atf@sundog.tiac.net>, ciaraldi@max.tiac.net (Michael Ciaraldi) writes:
> Dear Joe,
> These (4 and 5) are two different cases, and they are different from 3.
> Each may be appropriate in certain situations, and I wanted to find
> out if Kermit supported them.
> 
> Consider a VAX with a serial card that has large output buffers, as many do.
> If a terminal (or Kermit emulating one) just passes through
> ^S and ^Q characters (case 3), what happens when the user hits a ^S (XOFF)?
> It gets sent to the host. The host CPU detects it and stops sending data.
> However, there may be several thousand characters still in the 
> output buffer of the serial card, and there is no mechanism for the
> host CPU to notify the card to stop sending. So, even though
> the user has hit ^S, several more pages of data appear on the screen
> and scroll off the top of the screen. I've seen this happen many times.
> Fortunately, MS-DOS Kermit has a screen scrollback buffer,
> but this is still a problem for most users
> (those who are not using Kermit, of course).
> 
> In case 4 and 5, when the user hits ^S, Kermit would stop sending
> updates to the screen. It would just accumulate any incoming
> data from the host into a buffer, then send it to the screen later
> when the user hits ^Q.  The difference between 4 and 5 is that
> in 5 the host also gets notified, so there is a chance that the buffer 
> will not overflow.

	In the user's manual is the keyboard verb \kholdscrn. That is
equivalent to DEC's HoldScreen key.
	Accumulating into a buffer is what triggers almost all flow
control activity: it reaches a high or low water mark. For snappy
flow control response reduce the capacity of the comms channel. Too
much storage capacity will result in lost bytes, with no way to prevent
that from occuring (except buy a faster PC). 
	 

> 
> On case 8, I asked because I was doing some tests on Kermit
> last week and found what I thought was funny behavior.
> I wired my PC to a Unix machine's serial port and used
> another comm program on the Unix machine to talk to that port.
> The Unix machine was set for no flow control.
> I gave the command SET FLOW XON to the PC Kermit,
> then did a TRANSMIT. The contents of the file started
> appearing in the window on my Unix machine.
> Then I hit a ^S on the Unix machine. The PC kept sending the file.
> Shouldn't Kermit have stopped sending the file until
> it received a ^Q?

	I have no idea what the Unix machine actually sent, if anything.
Tell MS-DOS Kermit SET DEBUG ON and enter Connect mode to debug the
Unix side. MSK should respond to the XOFF, and when it has something
to send while blocked it will wait about 8-10 seconds before breaking
through and sending (a deadlock prevention mechanism).
	Joe D. 

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 1409 of comp.protocols.kermit.misc:
Path: cs.utk.edu!gatech!udel!news.mathworks.com!news.kei.com!ub!ns1.potsdam.edu!news.potsdam.edu!nelson
From: nelson@crynwr.crynwr.com (Russell Nelson)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Arcnet Packet Driver?
Date: 12 Dec 1994 04:51:44 GMT
Organization: Crynwr Software
Lines: 16
Message-ID: <NELSON.94Dec11235144@crynwr.crynwr.com>
References: <3c96mj$bej@cello.gina.calstate.edu>
NNTP-Posting-Host: nh2.potsdam.edu
In-reply-to: jpowell@cello.gina.calstate.edu's message of 9 Dec 1994 01:06:27 -0800

In article <3c96mj$bej@cello.gina.calstate.edu> jpowell@cello.gina.calstate.edu (Larry Powell) writes:

      I use arcnet with Novell which works fine. I also tested kermit with
   the Netbios that comes with Novell (Lite) and it works also. I tried a
   brief test of the packet drivers ARCNET and ARCETHER and they both failed
   to initialize and/or self test.

ARCNET won't work with Kermit.  ARCETHER should.  If it doesn't
initialize, perhaps you used an incorrect command line?  What version
of ARCETHER and command line did you use?

--
-russ <nelson@crynwr.com>    http://www.crynwr.com/crynwr/nelson.html
Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | +1 315 268 1925 (9201 FAX)  | What is thee doing about it?
Potsdam, NY 13676 | What part of "Congress shall make no law" eludes Congress?

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 1410 of comp.protocols.kermit.misc:
Path: cs.utk.edu!gatech!newsxfer.itd.umich.edu!sol.ctr.columbia.edu!news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: term type in telnet-macro (Kermit 3.14)
Date: 12 Dec 1994 14:08:33 GMT
Organization: Columbia University
Lines: 49
Message-ID: <3chlh1$cl0@apakabar.cc.columbia.edu>
References: <3bul2u$47d@infosrv.rz.unibw-muenchen.de>
NNTP-Posting-Host: watsun.cc.columbia.edu

In article <3bul2u$47d@infosrv.rz.unibw-muenchen.de>,
Peter Schmolck <p41bsmk@kommsrv.rz.unibw-muenchen.de> wrote:
>I'm using MS-Kermit 3.14 Beta-14. My UNIX-hosts do not know what to do 
>with "vt320", and when trying to adjust my mscustom.ini definitions I 
>noted an inconsistency (or bug?). ... the myhost define in mscustom.ini:
>
> define myhost -
>   telnet myhost 23 vt320,-
>   if success assign myhost telnet \v(session)
>
>set the terminal type, and not only the TELNET-negotiated "telnet
>term-type" (which I rather preferred the macro to do).
>
Well, as the accompanying comment says, it's only a sample, which you should
adjust for the host(s) you are actually using, e.g.:

  set telnet term-type vt220,-
  telnet myhost,-
  if success assign myhost telnet \v(session)

Kermit sends its actual terminal type during TELNET negotiations UNLESS you
have given a SET TELNET TERM command, which overrides the actual terminal
type, but only for the purposes of telling the TELNET server what kind of
terminal type you have.  This is useful, for example, if Kermit's terminal
type is VT320, but the host knows the same terminal by a different name, such
as VT300, and does not recognize Kermit's terminal name.

>When I changed the myhost define from vt320 to vt220 the result was, that --
>expectedly -- the status line entry changed to VT220, but --unexpectedly--
>the remote TELNET server still received a "VT320". (??)
>
I checked this just now and it didn't happen to me.  Probably you just
continued the same session, and the terminal type was not renegotiated?

>BTW, mskermit.bwr says: "... to create an override string with command 
> SET TCP/IP TELNET-TERM-TYPE."
>Instead this should read either "set tcp/ip term-type" or "set telnet 
>term-type".
>
You're right, we'll fix it.  Thanks!

- Frank
x
x
x
x
x
x
x

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 1412 of comp.protocols.kermit.misc:
Path: cs.utk.edu!gatech!howland.reston.ans.net!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: term type in telnet-macro (Kermit 3.14)
Message-ID: <1994Dec12.073551.35191@cc.usu.edu>
Date: 12 Dec 94 07:35:51 MDT
References: <3bul2u$47d@infosrv.rz.unibw-muenchen.de>
Organization: Utah State University
Lines: 48

In article <3bul2u$47d@infosrv.rz.unibw-muenchen.de>, p41bsmk@kommsrv.rz.unibw-muenchen.de (Peter Schmolck) writes:
> I'm using MS-Kermit 3.14 Beta-14. My UNIX-hosts do not know what to do 
> with "vt320", and when trying to adjust my mscustom.ini definitions I 
> noted an inconsistency (or bug?).
> 
> The telnet macro in mskermit.ini:
> 
> define TELNET -
>   set flow none,-
>   set port tcp \%1 \%2,-
>   pause 0, if fail end 1,-
>   if def \%3 set term type \%3,-
>   if succ c  
> 
> and accordingly the myhost define in mscustom.ini:
> 
>  define myhost -
>    telnet myhost 23 vt320,-
>    if success assign myhost telnet \v(session)
> 
> set the terminal type, and not only the TELNET-negotiated "telnet
> term-type" (which I rather preferred the macro to do). When I changed the
> myhost define from vt320 to vt220 the result was, that -- expectedly --
> the status line entry changed to VT220, but --unexpectedly-- the remote
> TELNET server still received a "VT320". (??)
> 
> BTW, mskermit.bwr says: "... to create an override string with command 
>  SET TCP/IP TELNET-TERM-TYPE."
>      ^^^^^^^^^^^^^^
> Instead this should read either "set tcp/ip term-type" or "set telnet 
> term-type".
-----------
	It's not your fault, it's ours.
	In reality the MSK command SET PORT TCP/IP acquires just two
arguments: host and port number. It doesn't look for a terminal type.
The way to use a different terminal type is SET TERMINAL TYPE kind
or just SET TERMINAL kind. This will pass along to the host, upon
request, the same terminal type spelling we see in commands. Here is 
the canned list, lifted from the code:
	"UNKNOWN","H-19","VT52","VT100","VT102","VT220","VT320",
	"TEK4014","VIP7809","PT200","D463","D470","wyse50","ANSI"

	As you point out, the program uses SET TCP/IP TERM-TYPE ident
as the way to tell the host a different identication string than the 
default method. 
	The docs will be modified to be clear and correct on both items.
	Thanks,
	Joe D.

 [ subsequent releases have added a couple more ]

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-


Article 1398 of comp.protocols.kermit.misc:
Path: cs.utk.edu!emory!swrinde!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc,comp.protocols.ppp
Subject: Re: [?] Merit PPP and MS-DOS Kermit 3.13 PL17
Message-ID: <1994Dec10.090145.35091@cc.usu.edu>
Date: 10 Dec 94 09:01:45 MDT
References: <D0L9oo.J6I@indirect.com>
Organization: Utah State University
Lines: 12
Xref: cs.utk.edu comp.protocols.kermit.misc:1398 comp.protocols.ppp:7928

In article <D0L9oo.J6I@indirect.com>, monty@indirect.com (Jim Monty) writes:
> Can I run MS-DOS Kermit 3.13 over a PPP (specifically, Merit PPP) 
> connection?  If so, how?  Exactly.
-----------
	The indications are that "etherppp" provides an Ethernet Packet
Driver interface to applications. I phrase this as indications because
I've never been able to get etherppp to avoid hanging my PC as it installs
itself in memory. If you get it to install cleanly then treat it as an
Ethernet (which kind???, hopefully DIX/Ethernet_II/regular) Packet Driver.
By default Kermit will look for a Packet Driver when its internal TCP/IP
stack begins.

	Joe D.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 1405 of comp.protocols.kermit.misc:
Path: cs.utk.edu!gatech!swrinde!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: 3.14 beta 14 and PC/TCP
Message-ID: <1994Dec11.104027.35139@cc.usu.edu>
Date: 11 Dec 94 10:40:27 MDT
References: <D0n8CD.Gn8@adasoft.ch>
Organization: Utah State University
Lines: 36

In article <D0n8CD.Gn8@adasoft.ch>, jw@adasoft.ch (Jamie Watson) writes:
> 
> I must be doing something wrong, but I can't figure out what...
> 
> I am trying to use 3.14 Beta-14 with FTP Software PC/TCP 3.0 to connect
> from my laptop to my Unix system.  The laptop is a Toshiba 1950CS, with
> a Xircom PCMCIA ethernet adapter.  The Unix system is a DECsystem 5000/50,
> running Ultrix 4.4.
> 
> When I first start the system, I can reach the Ultrix system with all of
> the normal PC/TCP utilities (ping, tn, rlogin, etc).  I then start kermit,
> and give it what I think are the minimum configuration commands to get it
> working over TCP/IP:
> 
>     set tcp addr 193.72.200.10
>     set tcp host 193.72.200.7
>     con
> 
> It connects, and everything seems just fine.  But after I log out, and
> terminate kermit, none of the PC/TCP utilities work any more!  If I try
> to ping the Unix system, I get "ARP failed", and nothing I have tried can
> get this working again, short of rebooting the laptop.  But if I start
> kermit again, I can still connect to the Unix system!  I'm really very
> confused...
--------------
	The situation is easy to clarify. SET PORT TCP in Kermit means
to use Kermit's internal TCP/IP stack. That stack requires either a suitable
Packet Driver or ODI to talk to the lan adapter. FTP Inc's stack does more
or less the same thing. You loaded FTP Inc's stack and then told Kermit to
go to the same board and grab it; you are not running "over FTP Inc's stack."
I'm surprized that you we able to run Kermit over the board with FTP still
using all the TCP/IP material. 

	If you want FTP Inc's stack to remain resident and run Kermit
over the top of it you must use FTP's TNGLASS program, and tell Kermit
SET PORT BIOS1.
	Joe D.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 1521 of comp.protocols.kermit.misc:
Path: cs.utk.edu!gatech!howland.reston.ans.net!sol.ctr.columbia.edu!news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Help needed in slip setup!
Date: 26 Dec 1994 17:19:49 GMT
Organization: Columbia University
Lines: 60
Message-ID: <3dmtvl$l5k@apakabar.cc.columbia.edu>
References: <3dl8jc$54f@vixen.cso.uiuc.edu> <1994Dec25.203048.36009@cc.usu.edu>
NNTP-Posting-Host: watsun.cc.columbia.edu

In article <3dl8jc$54f@vixen.cso.uiuc.edu>,
 somebody@prairienet.org (Carlos Ramirez Pnet Admin) writes:
> Hello everyone after various attempts to setup config files for using 
> slip especially with dns I have given up and decide to ask assistance. 
> Thus can someone be so kind as to mail be a sample config files for using 
> kermit with slip for dos.
>
Did you read the instructions?  This is from the file NETWORKS\SETUP.DOC
in the MS-DOS Kermit 3.14 Beta ZIP file:

MAKING SLIP CONNECTIONS

To make a SLIP (Serial Line IP) connection, follow these steps:

1. SET PORT 1
   (or whichever serial port you will be using for the SLIP connection).

2. SET SPEED 19200
   (or whatever speed you will be using)

3. SET FLOW RTS/CTS (or NONE)
   Don't use Xon/Xoff flow control on a SLIP connection!  SLIP and Xon/Xoff
   are incompatible with each other.

4. Establish a connection to the terminal server or other device that will be
   providing SLIP service.  Determine the IP address and other information
   (e.g. gateway address) that it has assigned to you.	Normally, these are
   displayed on your screen before the terminal server enters SLIP mode.

5. Escape back to the MS-Kermit prompt and EXIT from MS-DOS Kermit.  The
   connection is left open.

6. Start the SLIP8250 driver, telling it to use the same port (hex address and
   IRQ number must be supplied) and speed (decimal) used in (1) and (2) above,
   and to use hardware flow control (-h), for example:

      slip8250 0x60 -h slip 4 0x3f8 19200

7. Start MS-DOS Kermit again.  Do NOT give it a SET PORT command for the
   serial port where SLIP is running.  Instead, give the SET TCP ADDRESS,
   SET TCP GATEWAY, and other necessary SET TCP commands.  Then, to make
   a connection, use SET PORT TCP <address>, where <address> is the IP
   hostname or address of the IP host you want to connect to.

Note: Even though you might think it's silly to exit from Kermit and then start
it again, when you could simply start the SLIP driver from the Kermit prompt,
there is a reason: starting a driver from inside an application results in
memory fragmentation.

Note 2: In version 3.13 and later, it is also possible to obtain BOOTP service
on a SLIP connection if your SLIP server is configured to provide it (for
example, Cisco terminal servers can do this).  Also, MS-DOS Kermit's SHOW
COMMUNICATIONS command will display the IP address of the BOOTP server.

> On a side note I have beta 13 of kermit what new since then?
>
Of interest to you would be an improvement in the efficiency of SLIP service,
which came in Beta 16 (the current Beta).

- Frank


 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!emory!gatech!newsxfer.itd.umich.edu!sol.ctr.columbia.edu!news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Subject: Re: Where's the last version ?
Date: 2 Jan 1995 16:37:53 GMT
Organization: Columbia University
Lines: 58
Message-ID: <3e9a51$ft7@apakabar.cc.columbia.edu>
References: <3e3pniINNped@mendel.sis.pasteur.fr>
NNTP-Posting-Host: watsun.cc.columbia.edu

In article <3e3pniINNped@mendel.sis.pasteur.fr>,
Daniel Azuelos <dan@pasteur.fr> wrote:
>Please, where's the last working version of Kermit for Mac ?
>
CURRENT STATE OF MACINTOSH KERMIT

As of: Sat Nov 12 11:00:53 1994

*** BULLETIN ***
Mac Kermit 0.991(190) dated 16 August 1994, or later, fixes the problem with
downloading under newer System releases (7.1.x).  Now files can be downloaded
on newer systems such as Centris 660 AV with OS 7.1, Power Mac 7100/66 with OS
7.1.2, etc, without bombs or other nasty effects.  It should also fix certain
binary/text-mode confusion that seemed to result in corrupted files when
downloading in binary mode.
*****************

The last formal release of Mac Kermit was 0.9(40) in 1988.  Unfortunately, it
does not work very well on newer Macintoshes or Systems.  However, newer
versions are too big for 512K Macs or below, so you'll have to run 0.9(40) on
these old models.

A great deal of work has been done on the program since 1988, but the result
(so far) is still not of release quality, though it is quite suitable for most
purposes.

The current pre-pre-release of Mac Kermit (still far from a final release) is
0.991(190), based on C-Kermit 5A(190).  It is available via anonymous FTP
from kermit.columbia.edu [128.59.39.2], directory kermit/f.

A comprehensive user manual will be published when the final 1.0 release is
complete.  Sorry, I can't give any reasonable estimate about when that will
be.  Watch the Kermit Digest (or comp.protocols.kermit, same thing) for
further announcements.  You can subscribe to the Kermit Digest by sending
email to LISTSERV@CUVMA.BITNET (or LISTSERV@CUVMA.CC.COLUMBIA.EDU) containing
the text:

  SUBSCRIBE I$KERMIT your-personal-name-here

Mac Kermit files, ftp from kermit.columbia.edu in text mode from the
kermit/f directory:

  ckm190.hqx -- current prerelease of Mac Kermit in BinHex 4.0 format
  ckmker.doc -- user documentation for 0.9(40), the previous release (1988)
  ckmker.ps  -- PostScript version of user documentation for 0.9(40)
  ckmker.bwr -- Notes about the current prerelease, FAQ's, etc
  ckmker.fon -- Notes about the new Mac Kermit terminal emulation font

and in the kermit/charsets directory:

  maclatin.* -- The new Mac Kermit font itself

Read the ckmker.bwr ("beware") file for further details.

(End of ckmaaa.hlp)

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 1566 of comp.protocols.kermit.misc:
Path: cs.utk.edu!gatech!swrinde!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: kermit auto DL/UL!
Message-ID: <1995Jan2.142944.36328@cc.usu.edu>
Date: 2 Jan 95 14:29:44 MDT
References: <lk32luqcZ$jG075yn@primenet.com>
Organization: Utah State University
Lines: 23

In article <lk32luqcZ$jG075yn@primenet.com>, jbishop@primenet.com (Jeff Bishop) writes:
> After examining kermit packets closely a friend has determined two strings
> that can be used to start kermit transfers automatically from {COMMO} (any
> other term program for that matter). This is not using the APC logic described
> in kermit.upd though.
> 
> The two strings are:
> 
> For upload I am using   "^a# N3" download              "^a5 S~".
> 
> I have tested this and it works using msdos kermit on both sides.
-----------
	Only if
	a) Control-A is used as the start of packet character, and
	   the checksum is correct
	b) this pattern can never exist in real data
	c) the other end is willing to send idle NAKs
	The S packet material is vital, is not nearly so short as you
have describe, and must not be broken into pieces.
	Unfortunately, none of a..c is a requirement. Maybe your friend should 
also examine the protocol specs carefully to see the variations. In general, 
there is no safe pattern.
        Joe D.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 1622 of comp.protocols.kermit.misc:
Path: cs.utk.edu!gatech!newsxfer.itd.umich.edu!zip.eecs.umich.edu!panix!news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Grabbing text from a remote session
Date: 8 Jan 1995 19:16:08 GMT
Organization: Columbia University
Lines: 33
Message-ID: <3epdlo$232@apakabar.cc.columbia.edu>
References: <D21Htq.161@murdoch.acc.virginia.edu>
NNTP-Posting-Host: watsun.cc.columbia.edu

In article <D21Htq.161@murdoch.acc.virginia.edu>,
Erik Hatcher <esh6h@fulton.seas.Virginia.EDU> wrote:
>I want to have C-Kermit on a VAX dial up a remote computer
>and enter in a Support call for processing by our company.
>The process of entering the support call generates a sequence
>number for that call that needs to be given back to
>our client for future reference.  This sequence number just appears
>on the screen when the information is being entered.
>
>Is there a way that I can grab this ever-changing value off the
>screen some how?  I was thinking that I could possibly log the
>session to a file and then read it back from that file, but
>I won't be in "connect" mode so "log session" would not grab
>it.  Is there an appropriate "log" command that I could use
>to file away the remotes responses??
>
There are numerous approaches, none of them pretty.  You are deeply
into the area we know as "screen scraping".

First of all, LOG SESSION should, indeed, work during script
execution, as well as in CONNECT mode.  So the brute-force approach
is to LOG SESSION and then grovel through the session-log file
afterwards to find the sacred number, either by hand or by program.

Well, if it can be done by program, that means there is some pattern
that allows you to locate the number.  If that is true, then you can
also use INPUT or MINPUT commands in your Kermit script to locate
(say) the thing that comes just before or just after the number, and
then you can pull the number out of the \v(input) buffer by using
string functions such as \findex(), \fsubstring(), etc, in a Kermit
script program.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 1630 of comp.protocols.kermit.misc:
Path: cs.utk.edu!gatech!swrinde!elroy.jpl.nasa.gov!lll-winken.llnl.gov!sol.ctr.columbia.edu!news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: 2 questions
Date: 9 Jan 1995 13:55:38 GMT
Organization: Columbia University
Lines: 74
Message-ID: <3erf8q$1rl@apakabar.cc.columbia.edu>
References: <3eqjo6$p9k@bingnet1.cc.binghamton.edu>
NNTP-Posting-Host: watsun.cc.columbia.edu
Keywords: Initialization, Telnet

In article <3eqjo6$p9k@bingnet1.cc.binghamton.edu>,
 <br00031@bingsuns.cc.binghamton.edu> wrote:
>I use ms Kermit to connect via telephone modem to my university Suns.
>  The suns uses
>c-kermit (about 2 versions back I think).
>1.  Every time I do file transfers I must reset several variables in
>c-kermit; flow control, windows, blocks etc..  Is it possible for me
>to have these commands as a script or macro in my home directory.
>
Yes, all of the above, as explained in the manual, "Using C-Kermit".
The recommended method is to install the standard C-Kermit initialization
file, .kermrc, in your home directory, and then create a .mykermrc
file, also in your home directory, containing the desired customization
commands.  For those who don't like the standard .kermrc file (which
sets up such items as your services directory, dialing directory, etc),
just make a .kermrc file.

>How would I tell c-kermit to use that script.?
>
See above.  You can also tell C-Kermit to use any file at all as its
initialization file, using the -y command-line option:

  kermit -y filename

And at any time C-Kermit is showing its prompt, you can tell it to execute
commands from a file:

  C-Kermit> take filename

And you can define macros and execute them like so:

  C-Kermit> define fast set rec packet-length 2000, set window 4
  C-Kermit> fast
  
And you can put the macro definitions in your initialization file or
any other file that you can "take".

All of this is explained in the manual.

>2.  It has been suggested in the past that the telnet capabilites of
>kermit are superior to the normal telnet.  Is it possible to use those
>telnet capabilties with my modem connection. I mean can I put c-kermit
>into Server mode and use its telnet.   Is there any possible benifit
>to gained by doing this over the normal telnet capabilites that are on
>the Unix system?
>
You mean, after dialing up to your Unix system, you want to know why you
might want to use C-Kermit instead of telnet to connect to another system
on the Internet?  The advantages include:

 . Kermit is more user-friendly ("help", "?", command and filename
   completion, etc).

 . The telnet implementation works in some cases where regular
   telnet does not.

 . Kermit has scripting (automation) capability; telnet does not.

 . Kermit has (in the UNIX version, a limited form of) key mapping;
   telnet doesn't.

 . Kermit can convert among many different character sets, telnet can't.

 . Kermit has session logging, telnet doesn't.

 . Kermit can make 8-bit telnet connections; some telnet clients can't.

 . Kermit can transfer files over a telnet connection, telnet can't.

The last point is important in the increasing number of cases where the
telnetted-to host or service does not provide ftp; e.g. Internet BBSs,
or Internet versions of commercial dialup services.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 1634 of comp.protocols.kermit.misc:
Path: cs.utk.edu!gatech!howland.reston.ans.net!sol.ctr.columbia.edu!news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Mac Kermit .991(190) 8bits ?
Date: 10 Jan 1995 14:00:57 GMT
Organization: Columbia University
Lines: 30
Message-ID: <3eu3up$e8p@apakabar.cc.columbia.edu>
References: <3esgd6INN4dm@mendel.sis.pasteur.fr>
NNTP-Posting-Host: watsun.cc.columbia.edu

In article <3esgd6INN4dm@mendel.sis.pasteur.fr>,
Daniel Azuelos <dan@pasteur.fr> wrote:
>When using Mac Kermit .991(190) I'd like to be able to type
>8bits character, much the same way we (on this side of the planet)
>are used to do it on any Mac.
>
>As an example, 'Alt-e e' should give an 'e acute' both on the
>screen and on the host computer to which I'm connected:
>displayed as , and sent to the computer as 0xe9.
>
You should be able to do it.  Please read the ckmker.bwr
file that accompanies Mac Kermit 0.991(190).  You will see
there are many shortcomings in the international character-set
support, but it still can be done.

You have to tell Kermit (in the Terminal settings) to allow
8-bit characters, and you have to select Latin-1 as the
character-set.

The big problem is with entering 8-bit characters.  Since
Mac Kermit's font is not a regular system font, but rather
a built-in one, you can't use Keycaps in the normal way, which
is frustrating.

Nevertheless, you should be able to enter 8-bit characters in
the normal way, provided you have not done anything to the
Alt (Option?) key in the Modifiers dialog of the Key Settings
menu.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 104454 of comp.os.vms:
Path: cs.utk.edu!gatech!howland.reston.ans.net!spool.mu.edu!uwm.edu!rutgers!news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.os.vms
Subject: Kermit Performance (was Re: Zmodem)
Date: 8 Jan 1995 17:54:56 GMT
Organization: Columbia University
Lines: 147
Message-ID: <3ep8tg$qc4@apakabar.cc.columbia.edu>
References: <3en6v1$eer@nyx10.cs.du.edu>
NNTP-Posting-Host: watsun.cc.columbia.edu
Keywords: Kermit, C-Kermit, Zmodem

In article <3en6v1$eer@nyx10.cs.du.edu>,
Michael Donohue <mdonohue@nyx10.cs.du.edu> wrote:
>AN earlier post said that Kermit was not entirely bad for transfering 
>files.  I tried and tried, but the max cps I could get was 157 or so on a 
>9600 bps line.
>
>Could someone please tell me ... the settings for kermit?
>
I have posted the following message to this group several times -- if
there is an FAQ, I hope this can be added to it.  But first, a word from
our sponsor.  The current version of Kermit for VMS is C-Kermit 5A(190).
It supersedes all previous VMS Kermit releases and programs, including all
versions of Kermit-32, which is no longer supported.  You can get C-Kermit
5A(190) by mail order from Columbia University, or by anonymous ftp to
kermit.columbia.edu, directory kermit/f, file ckvaaaa.hlp, read it, go
from there.  You can also access the Kermit repository via the Web at URL:

  http://www.columbia.edu/kermit/

The Kermit software effort is funded primarily by mail order and book
sales.  Users of C-Kermit (and MS-DOS Kermit) are encouraged to purchase
the appropriate manual -- it will show you how to use the software and how
to get the most out of it (e.g. answering questions like the one above, so
they need not be posted to dozens of newsgroups over and over and over
again).

If you type "help" at the C-Kermit> or MS-Kermit> prompt, you should get
(among other things) a complete reference to the appropriate manual.  If
you want more information, access the Web site listed above or send e-mail
to kermit.columbia.edu.

The following message is almost a year old and discusses the previous
release of C-Kermit, but aside from that, it still applies.

In article <s5$Oj86y-nB0055yn@faraday.clas.virginia.edu>
gap5u@faraday.clas.virginia.edu (Gregory Perron) writes:
> 
> I'm downloading from a vax 4000-90 thru a terminal server of some sort
> to my PC.  14.4's at both ends: I have a cardinal internal; they have
> us robotics.  I get messages of 14.4, lapm, v.42bis, etc.  But,
> downloads have been hideous.
> 
> I've given up on sz, because of too many aborted transfers.  I
> *think* the problem is w/ the vax, but I'm not sure.  [I get flawless
> 1600-1650 cps dl's on zipped files from a local bbs] Yes, I tried all
> the -ebrw permutations I could think of.
> 
> On to kermit: I use procomm plus/dos 2.01 on my PC.  On the vax,
> ckermit pops up and says:
> Ckermit 5a(188) 23 NOV 92, OpenVMS Vax.
>
You'll get better results with C-Kermit 5A(189) or later, which has two
new features described below.  C-Kermit 5A(189) is available via
anonymous ftp to kermit.columbia.edu, directory kermit/b, get the file
ckvaaa.hlp, read it, take it from there.

> My ckermit.ini file has:
> set send pack 1000
>
This command is not needed; see the documentation.

> set receive pack 1000
> set buff 20000 20000
> set file type bin
> set windows 10
> set block 3
> 
> Symptoms: max dl cps has been around 1100 for a zipped/jpg/gif file.
> And that's unusual: 950-1050 is more normal. It's almost like I'm
> only at 9600, modem report aside.
> 
I can't speak for Procomm, but I ran some tests using MS-DOS Kermit 3.13
(the current version) on a 486/66 over a V.32bis/V.42/V.42bis dialup
connection to a Cisco terminal server, and from there to a VAXstation
3100 running VMS 5.x and C-Kermit 5A. The calling modem is a Telebit
T3000, the answering modem is a USR Courier.

MS-DOS Kermit 3.13 is available via anonymous ftp to kermit.columbia.edu,
directory kermit/bin, binary mode, file msvibm.zip.

In these tests, I downloaded a 330K ZIP file (MSVIBM.ZIP -- the MS-DOS
Kermit 3.13 distribution).  My serial interface speed was 57600 bps, and
I used RTS/CTS flow control between my PC and the modem, and RTS/CTS was
also active between the answering modem and the terminal server.

In the first test (10 window slots x 1000-byte packets, same settings as
yours), I achieved an effective throughput of 1091 cps, like you got.

Since the connection between the terminal server and VMS is via TCP/IP
TELNET, and we know that TCP and IP will handle the flow control between
the VAX and the terminal server, I told C-Kermit to SET FLOW NONE (its
default setting is XON/XOFF) and ran the test again: 1136 cps.

Now that we've got the basics taken care of, we can work on tuning.
Next I tell C-Kermit to:

  SET CONTROL UNPREFIX ALL
  SET CONTROL PREFIX 1 129 255

(version 5A(189) or later is required for this; see the CKCKER.UPD file
for explanation) -- This removes control-character prefixing overhead
for all but 3 characters (4 really: NUL, Ctrl-A, Ctrl-A plus parity, and
the TELNET IAC character).  Now I get 1549 cps.  Note: control-character
unprefixing is of benefit primarily for precompressed files, secondarily
for uncompressed binaries, and has very little effect at all on text
files.

Well, the PC I was using is one of the new "high-speed, low-cost"
models, and so lacks a buffered UART.  All of the above transfers
suffered various amounts of retransmissions due to UART buffer overruns.
Switching to a much slower PC (a PS/2-70, 15MHz I think) that has a
16550A buffered UART, same transfer, same parameters, the throughput
goes up to 1601 cps.

Now, since I don't have to worry about buffer overruns any more, I
increase Kermit's packet length to 5000 (SET RECEIVE PACKET-LENGTH
5000).  Throughput: 1608 cps.

And now, since this is a precompressed file, I note that neither
Kermit's run-length compression, nor the modem's V.42bis compression
will do any good -- and some would say that they slow things down
a lot.  Let's see.  I turn both off:

  Kermit: SET REPEAT COUNTS OFF (C-Kermit 5A(189) or later required).
  Modem:  ATS190=0 (Telebit T3000)

and download the file again.  Result: 1616 cps.  Not a big difference.

Lessons (which apply mainly to this particular type of connection):

 1. Buffered UARTs are better than nonbuffered UARTs.
 2. Be sure to get the flow control at both ends.
 3. Use long packets (1K - 5K, whatever works) and sliding windows
    (4 or more).
 4. Once you've got all that working optimally, you can squeeze out
    another 20-30% efficiency with control-character unprefixing.
 5. After that, don't bother too much with fine tuning, particularly
    with disabling modem or software compression - it makes very little
    difference.

Please, before we have another flurry of postings from people asking
for the "optimal" list of control characters to be unprefixed, THERE IS
NONE.  Every connection is different, with its own unique characteristics.
Read the documentation.  Ditto for all the other variables we have looked
at here: window size, packet length, flow control, etc.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!cssun.mathcs.emory.edu!hobbes.cc.uga.edu
      !news-feed-1.peachnet.edu!news.duke.edu!convex!cs.utexas.edu
      !howland.reston.ans.net!gatech!newsfeed.pitt.edu!uunet
      !news.nyc.pipeline.com!news.cs.columbia.edu!news.columbia.edu
      !watsun.cc.columbia.edu!fdc
Date: 11 Apr 1995 14:31:41 GMT
Organization: Columbia University
Message-ID: <3me3sd$cb8@apakabar.cc.columbia.edu>
References: <3mbt5c$epg@cronkite.ocis.temple.edu>
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Subject: Re: Tuning Kermit


In article <3mbt5c$epg@cronkite.ocis.temple.edu>,
John Price <jprice@astro.ocis.temple.edu> wrote:
: We're using kermit to do file transfers from an IBM 3090 through a Cisco 
: terminal server. After reading the faq, I noticed that Cisco might have 
: problems with tn3270 emulation, so I tried logging in to a unix machine 
: (system V release 3 I believe) and using it's tn3270. I get the same 
: throughput, at about 90 char length packets (oscilates between 89 and 90). 
: 
: When I set packet lengths above 100, i get lockup. I suspect that our 
: tn3270 has a maximum packet lenght around 100, which would mean 90 is about 
: all we could do. Any hints?
: 
When you go through a 3270 emulator, you're at its mercy.  This is a perfect
example of why Kermit lets you specify the packet length, and why it uses
a short default packet length.  If longer packets kill the 3270 emulator,
then that's all there is to it.

Preliminary reports indicate that Cisco release 10.3 will let you transfer
files through its 3270 emulator with packets up to about 1900 bytes in
length.  That's a big improvement.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!nntp.memphis.edu!nntp.msstate.edu!gatech!news.mathworks.com!uunet!spcuna!news.columbia.edu!watsun.cc.columbia.edu!fdc
Subject: Re: Kermit MS-DOS Library...
Message-ID: <3nrbo6$73r@apakabar.cc.columbia.edu>
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Date: 28 Apr 1995 18:21:58 GMT
References: <3nq5ms$be8$1@mhafc.production.compuserve.com>
Organization: Columbia University
NNTP-Posting-Host: watsun.cc.columbia.edu
Lines: 17

In article <3nq5ms$be8$1@mhafc.production.compuserve.com>,
Hans Rehfeld  <100125.3631@CompuServe.COM> wrote:
>Is there a I/O library for MS-DOS available, which has sliding 
>windows implemented?  If yes, where is it accessable? Is it for 
>free ? 
>
If there is one, it is not from Columbia University, and it is
probably not for free.  For DOS, we would prefer that you use
MS-DOS Kermit itself as an external protocol, which is quite
simple and convenient in version 3.14 (the latest version).  If
this is to be included in a commercial or shareware application,
you'll have to license it, just as you would have to license any
commercial "comm library".  The advantage of doing it this way
is that you get the best Kermit implementation and at the same
time you help to support the Kermit effort.

- Frank


 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 2761 of comp.protocols.kermit.misc:
Path: cs.utk.edu!stc06.ctd.ornl.gov!fnnews.fnal.gov!uwm.edu!lll-winken.llnl.gov!hookup!solaris.cc.vt.edu!spcuna!news.columbia.edu!usenet
From: fdc@fdc.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: _tid variable in OS/2 Ckermit 191
Date: 8 May 1995 13:55:19 GMT
Organization: Columbia University
Lines: 17
Message-ID: <3ol7s7$evg@apakabar.cc.columbia.edu>
References: <1995May6.191609.9845@mercury.ncat.edu>
NNTP-Posting-Host: fdc.cc.columbia.edu

In article <1995May6.191609.9845@mercury.ncat.edu> hkennedy@mercury.ncat.edu  
writes:
> I noticed a variable named _tid for setting up the terminal mode in login
> scripts. However, I found no reference to this variable in the ckermit book
> or in the update docs. Could someone give an example of a script using this
> code. Thanks,
> 
It's the terminal ID string that the terminal sends in response to a
What Are You? query, normally  ESC Z, from the host, which can vary according
to terminal type.

It is not actually used in any of the login scripts, but it can be.  It would
be particularly handy for logging in to VMS.

It is not a built-in variable, but is defined in the CKERMOD.INI file.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 2866 of comp.protocols.kermit.misc:
Path: cs.utk.edu!gatech!news.mathworks.com!news.kei.com!nntp.et.byu.edu!news.provo.novell.com!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Help With Underline Color!
Message-ID: <1995May23.184650.52006@cc.usu.edu>
Date: 23 May 95 18:46:50 MDT
References: <3pta72$9s1@chopin.udel.edu>
Organization: Utah State University
Lines: 42

In article <3pta72$9s1@chopin.udel.edu>, darkstar@chopin.udel.edu (Jerry Alexandratos) writes:
> 
> Okay, I tried posting this about two weeks ago, but I think it got lost
> in the shuffle.
> 
> I'm using MS-Kermit v3.14 patch level 3 to connect to a unix host. 
> I've got the following lines in my mscustom.ini:
> 
> set term color 10,37,44
> set term under 1,33,44
> 
> So, everyone can assume that I use a blue on white screen on a vga
> monitor and I want my underlined characters to be bright yellow on
> blue.
> 
> However, that's not the behavior I get from set term under.  It sets
> the color to yellow on blue (this means that it comes up brown looking
> on blue).
> 
> It's like it doesn't interpret the 1 at the beginning of the string.
> 
> But here's the really unusual part.  If I go back to the MS-Kermit>
> prompt after I've connected and I type the command in by hand, the
> colors come out as typed in!
> 
> Am I missing something, or is this a bug in the way it's determining
> the colors?
------------
	It's not a bug that I know of, and it works fine here. But let
me add some things to consider at your end. Intensity during terminal
emulation tries to follow your DOS screen, in that a DOS bold white on
blue screen shows the remote host text also bold white on blue unless the 
host says otherwise. That's equivalent to DEC dim white on black, or 
DEC "normal." If the host says do a bold operation then MSK flips intensity 
and you see dim but that's now DEC "bold." All this to look nice initially.
So the results depend on how you got started and what the host said as
well as what you said. [This reads like one of those intelligence tests
where Mary is 5 years older than Jane was before Jane stopped counting.] 
	The other mention is it could be that screen color sequencing
in your startup files overrides the lines you added, so try moving yours
around to double check.
	Joe D.


 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 3036 of comp.protocols.kermit.misc:
Path: cs.utk.edu!nntp.memphis.edu!nntp.msstate.edu!emory!swrinde!howland.reston.ans.net!vixen.cso.uiuc.edu!uwm.edu!lll-winken.llnl.gov!osi-east2.es.net!oracle.pnl.gov!mica.inel.gov!pmafire!mars.poci.amis.com!cwis.isu.edu!news.cc.utah.edu!news.cs.utah.edu!cc.usu.edu!jrd
Newsgroups: comp.protocols.kermit.misc
Subject: Re: set carrier on, server ##
Message-ID: <1995Jun15.165614.54075@cc.usu.edu>
From: jrd@cc.usu.edu (Joe Doupnik)
Date: 15 Jun 95 16:56:14 MDT
References: <3rptu3$nhr@feenix.metronet.com>
Organization: Utah State University
Lines: 95

In article <3rptu3$nhr@feenix.metronet.com>, brit@metronet.com (Brit Systems) writes:
> I am using MS-Kermit 3.14. 
> 
> I'm running through some scenarios with
> "set carrier on, server" and what happens when you loose the carrier.
> 
> Here is what I get.
> 
> 1) set carrier on, server, break connection, server exits

	Yup. The way it ought to be.

> 2) set carrier on, server, start getting file, break connection, 
> 	file transfer terminates, server waits forever
>         (at least as long as I wanted to wait).

	Correct. The current session terminated. Server mode was
	perpetual.

> 3) set carrier on, server 120, start getting file, break connection,
>         file transfer terminates, server waits until timeout then exits.

	The very last part needs improvment but basically it's ok.

> 4) set carrier on, server 120, start getting very big file, 
> 	file transfer completes, server exits since it it past timeout.

	Yes, that's what the 120 says, be a server for that long.
 
> Specifically on scenario 2 and 3, is this just me?
> 
> And on a related issue.
> 
> 1) dial someone, set carrier on, start sending file, break connection, 
> 	file transfer terminates.

	Yup. Correct.

> 2) don't call anyone, set carrier on, start sending file,
> 	file transfer eventually times out.

	Never a carrier then no CD drop state, and hence "no problem."
        Head scratching goes here.

> It seems that only connect checks if CD before it starts.
> Send, receive, remote and server don't seem to check CD when they start.
> Is this right?

	They don't. They have no idea of the state of the comms channel
so they work so long as bytes can be sent or they run out of retries.
See below for more on this part. Again, modems aren't the only way of
talking.
 
> So if I want to check CD myself, what's the best way.
> "wait 0 cd" seems to work but it prints and ugly "?Timeout message".
> 
> \v(carrier) only says what you set carrier to.
> 
> Is there a \v(cd)? I seem to have seen \CD written but don't know
> how to use it.
	No, there isn't. Maybe there should be, but then modem comms
are only one of many comms channels. In addition, testing for CD involves
firing up the serial port and we may not want that to happen.
 
> Thanks again, for the many times ya'll have helped,
> Robbie Barton 
----------

	Let me be candid on this topic.

	From the beginning of MS-DOS Kermit steps were taken to ensure the
program would not fail because some modem wire wasn't high or low. That
philosophy has carried (sic) forward to the present. Kermit is not dependent
on a modem being present and healthy. Near the release time of MSK v3.14 we 
had a very reasonable request to drop connections when CD vanished, and I 
added code to accomplish that task. We got there but just barely.

	For CD dropping to be a failure one must first have CD asserted,
which explains your "don't call anyone" case. There's room to quibble here.

	From your report we see that matters are slightly muddled regarding
what to do when CD drops. The principal reason for the muddle is CD is
a data link item and ought not penetrate into the higher level software
such as protocol stacks etc. There are many other communications pathways
which do not involve CD. In addition, the Kermit file transfer stack has 
automatic retries on failures (from any cause, reasons for failures are 
normally worthless: failed is failed) and they don't know about the comms
link troubles. So retries occur, and server mode is basically a loop with 
retries (with CD off most of the time, of course), and so on. 

	What can we do about this? Not much right now. I'll have to do the 
doing in the next release and try to add CD sensitivity where possible 
without making a hash of the code. It won't be perfect in the sense that
CD dropping kills the program in a flash, as happens to programs totally
dependent on modems, but it will be better than at present. And we need
to explain a little more carefully what terminating a session means versus
exiting server mode completely.

	Thanks,
        Joe D.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 3040 of comp.protocols.kermit.misc:
Path: cs.utk.edu!news.msfc.nasa.gov!europa.chnt.gtegsc.com!news.sprintlink.net!news.bluesky.net!solaris.cc.vt.edu!spcuna!news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Ckermit for Unix and VTKeys
Date: 17 Jun 1995 15:55:58 GMT
Organization: Columbia University, New York City
Lines: 68
Message-ID: <3rutue$cum@apakabar.cc.columbia.edu>
References: <1995Jun15.035925.13393@mercury.ncat.edu>
NNTP-Posting-Host: watsun.cc.columbia.edu

In article <1995Jun15.035925.13393@mercury.ncat.edu>,
 <hkennedy@mercury.ncat.edu> wrote:
>I using Ckermit with Linux, and CKermit is not sending the correct key
>strings for PF1 and PF2. I looked in the manual it just said make sure that
>the correct emulation is in effect, and the have the key assignments
>correct for VT300 emulation in the X-Term session.
>
>Of intereset when using "show key" the only the first part of the key
>string is shown in the case of PF1 only \27 the other part is on the next
>line with the Ckermit prompt.
>
>Is it possible to use VT key emulation in a connect session with Ckermit
>for Unix (I'm using Linux).
>
Time to add this one to the FAQ.

C-Kermit comes in basically two varieties:

 . The version for OS/2 that had direct access to the keyboard and screen,
   and therefore can see keyboard scan codes and so on, and can do true
   terminal emulation.  Here you have comprehensive key mapping ability.

 . The versions for UNIX, VMS, and so on, that do not have direct access
   to the keyboard and screen, and rely on your console driver, terminal
   window, external terminal emulator (such as MS-DOS Kermit), or actual
   terminal to perform the terminal functions.

UNIX is an interesting case.  Traditionally, UNIX was accessed through a
terminal that was plugged into a terminal port on a timesharing system.
Thus, there *is* no keyboard and screen -- just a communication port.  In
recent years, this type of access has been largely replaced by terminal
servers, but there is still no keyboard and screen.  However, now that we
have a plethora of PC-based UNIX varieties that run on workstations (PCs)
that actually *do* have a keyboard and screen, it would seem to make sense
that Kermit should be able to see all the keys.

Unfortunately, this is not the case.  Most varieties of UNIX do not let
the application see the keyboard.  There is no kernel function called "get
keyboard scan code".  There is only read(), and read() reads a character,
not a multibyte scan code.  Thus, even if your console driver has
programmed (say) your F1 key to send (say) ESC O P, Kermit will read three
characters in succession, as if they were three keystrokes, not one.  It
has no way of knowing that you pressed the F1 key.  As far Kermit knows,
you pressed the Esc key, then the O key, then the P key.

Now perhaps Linux *does* have a system call to let an application at the
keyboard.  But...

 (a) In what contexts does it work?  Only on the raw console?  In an xterm
     window?  etc etc.

 (b) Does it require special privilege to execute?

 (c) What about all the other versions of UNIX that run on PCs -- FreeBSD,
     SCO, Solaris/Intel, etc etc?

 (d) What about all the other versions of UNIX that run on non-PC
     workstations -- SunOS, Solaris/Sparc, HP-UX, AIX, SGI, etc?

So the answer is, for now at least -- and as the documentation states --
C-Kermit's SET KEY command in UNIX (and VMS, AOS/VS, VOS, etc) works only
for keys that generate a single 8-bit value, 0..255.  Other types of
mappings will have to be accomplished outside of Kermit by configuring
your console driver, your xterm (e.g. with Xmodmap), and so on.

I'll add this to FAQ.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 3072 of comp.protocols.kermit.misc:
Path: cs.utk.edu!nntp.memphis.edu!nntp.msstate.edu!emory!swrinde!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Wyse 50 function keys
Message-ID: <1995Jun22.114156.54488@cc.usu.edu>
From: jrd@cc.usu.edu (Joe Doupnik)
Date: 22 Jun 95 11:41:56 MDT
References: <dmg.2.003AA2D4@interaccess.com>
Distribution: na
Organization: Utah State University
Lines: 11

In article <dmg.2.003AA2D4@interaccess.com>, dmg@interaccess.com (Brian K. Willard) writes:
> I am using kermit 3.14 for dos, connected to an rs6000.  When using a vt320 
> emulation and the wpunix.ini I can use my function keys in WP for AIX.  When I 
> switch to Wyse50 emulation none of my function keys work.  I need this because 
> our office supports many hardware platforms, and we have clients on ADDS 
> machines that need to use Wyse50.  
------------
	They are present, but not preassigned to keys. Use SET KEY
and the Wyse 50 function keys are keyboard verbs \KwyseF1..\KwyseF16
plus \KwyseSF1..\KwyseSF16 (shifted Wyse function keys).
	Joe D.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 3594 of comp.protocols.kermit.misc:
Path: cs.utk.edu!cssun.mathcs.emory.edu!atglab.bls.com!gatech!news.mathworks.com!panix!news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Pre-announcing Kermit for Windows 95
Date: 3 Sep 1995 14:55:50 GMT
Organization: Columbia University
Lines: 65
Message-ID: <42cflm$15a@apakabar.cc.columbia.edu>
References: <425lub$4rr@apakabar.cc.columbia.edu> <JRS.95Sep3025353@world.std.com>
NNTP-Posting-Host: watsun.cc.columbia.edu

In article <JRS.95Sep3025353@world.std.com>,
Rick Sladkey <jrs@world.std.com> wrote:
> I suppose it's obvious but I assume that source will not be available
> for Kermit for Windows 95?
>
Some parts will, some parts won't.  The parts that won't were all done
here, at our own expense -- and that's money that must be recouped.

This is not from a desire to be secretive, but rather because historically
code from our software has been incorporated into hundreds of commercial
and shareware programs, most often without permission.  If the new Windows
95 code is of any value, and we believe it is, the same thing would happen
if we made it public.  Our project was not established for that purpose.

> I realize you must be doing this to survive but how can you expect to
> compete with communications programs that have twice the features for
> half the price?
>
None of the communications software that has been announced for Windows 95
is less expensive than Kermit 95.  Most of it is in the $129 range.  For
universities, our academic site licensing plan should allay all fears
about cost.  This was posted yesterday.

> Let's say you really do come through on all of the features and the
> price comes down to 20 bucks.  Let's say you do survive.  Is is really
> worth it to give up the very thing that it is to be Kermit: free
> software with source?
>
The world has changed since 1981.  The Internet (then, the ARPAnet) was a
forum for sharing and cooperation and mutual help.  Now it's a hotbed of
entrepreneurs who are principally concerned with how to profit from the
work of others.  The question is: despite all that, do people still want
Kermit software?  I think that millions of them do.  It is up to us to
figure out how to be in a position to furnish to them in the long run.

> It seems better to me to throw in the towel and say it was an
> experiment that didn't work than to compromise in the name of survival.
>
We decided not to do that.  As you can see, the other Kermit software
versions (MS-DOS, UNIX, VMS, IBM Mainframe, and hundreds of others) are
still there.  Should we shut those down too?  If not, then how shall we
pay for their upkeep?

> Or better yet, can't you just charge for support and see how far that
> gets you?  It doesn't seem to me you've investigated that avenue yet.
>
Believe me, over the past 3 or 4 years we've investigated every option,
including that one.

> I am happy for you if the decision you have made makes you successful.
> Every one needs a job or funding.  But I think it is a sad turn of
> events.
>
Sure it is.  So is the rampant commercialization of the Internet.  But
that is an unstoppable force, and one which was devouring our project.
Whether it is good or bad remains to be seen, but it is real, and it will
change "our little world" forever in ways we can scarcely even begin to
imagine.

Those of you who are interested in this type of discussion are invited to
read through the archives of comp.procotols.kermit.misc, comp.os.vms,
comp.dcom.modems, and many other forums in which it has taken place at
great length over the past two or three years.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Path: cs.utk.edu!gatech!howland.reston.ans.net!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: MS-Kermit 3.14 - Problem with Wyse-50 Emulation
Message-ID: <1995Sep14.212654.61352@cc.usu.edu>
Date: 14 Sep 95 21:26:53 MDT
References: <811093642@gkja>
Organization: Utah State University
Lines: 36

In article <811093642@gkja>, Graham Jenkins <grahamj@gkja.melbpc.org.au> writes:
> One of our Applications suppliers is using sequences as shown in
> the example below for marking screen-areas to stand out.
> Unfortunately, the "revert-to-normal" bit doesn't work quite the
> same under KERMITE (mid-95 3.14 release) with a Wyse50 emulation
> as it does on a real Wyse50.  Is there perhaps a patch for this?
> 
> ---
> #!/bin/sh
> # wy50test.sh	Tests screen feature escape codes for Wyse-50 with
> #		MSKermit-3.14 (mid-'95 release, kermite).
> 
> # Sledgehammer reset
> echo "\0033(\0033\`A\0033A00-NORMAL\c"
> sleep 3
> 
> # Standout (Reverse character protect, write protect)
> echo "\0033\`6\0033)-STANDOUT\c"
> sleep 3
> 
> # Normal
> echo "\0033(-NORMAL\c"
> sleep 3
> 
> # Sledgehammer reset
> echo "\0033(\0033\`A\0033A00-END"
> exit 0
-----------
	Yes, this is a genuine bug, sigh. It turns out that fixing it is
something of a chore deep in the code because of the way sundry video
attributes are munged (changed) by the ESC ` <write protected display
attribute code> sequence. I'll have this fixed in the next release, as
they say, because it is turning out to be too complicated to generate
as a Patch file item. I have a real Wyse-50 to help decode the affair.
	Thanks,
	Joe D.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Path: utkcs2!stc06.ctd.ornl.gov!fnnews.fnal.gov!uwm.edu!news.cse.psu.edu
      !rutgers!news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Date: 26 Jun 1996 19:16:49 GMT
Organization: Columbia University
Message-ID: <4qs2b1$28v@apakabar.cc.columbia.edu>
Subject: Re: K95 wyse60 emulation soon?


In article <4qrsbc$mrm@samba.rahul.net>, Clarence Dold  <dold@rahul.net> wrote:
: Robert J. Strickler (bstrickl@thrunet.net) wrote:
: : We have a client that is currently using w3.1 and procomm with wyse60 
: : emulation, the accounting system has been modified to generally expect the 
: : wyse60 and it looks to be expensive to unmodify it to a more generic vt100 
: : expectation. They would like to move about 25 workstations to w95 and a 95 
: : terminal emulator. K95 looks like a great fit except that it needs this 
: : emulation. Any estimates on the availability?
: 
:  You don't mention what kind of connection you are using.
:  I used MSKermit under Win95 for dialup access for a while, until I got K95.
:  If you need TCP connectivity that would be a different story, but the serial
:  portion of MSK 3.14 worked fine.


But MS-DOS Kermit does not include Wyse60 emulation, only Wyse50, which
is different.  Kermit 95 1.1.5 will emulate Wyse 30, 50, 60, and 370.

-- 
fdc

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.announce,comp.protocols.kermit.misc
Path: cs.utk.edu!nntp.memphis.edu!nntp.msstate.edu!cssun.mathcs.emory.edu
    !swrinde!howland.reston.ans.net!vixen.cso.uiuc.edu!uwm.edu!chi-news.cic.net
    !newsfeed.internetmci.com!news.sprintlink.net!in1.uu.net!panix
    !news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Organization: Columbia University
Approved: fdc@columbia.edu
Date: 23 Oct 1995 20:15:15 GMT
Message-ID: <46gt4j$jpl@apakabar.cc.columbia.edu>
Subject: New Kermit Tech Support Policies


This is to announce new technical support policies for Kermit software.
Effective immediately, but with a grace period extending through
November 30, 1995:

 . Phone support may be obtained by calling +1 (900) 555-5595.
   Presently, this number is available only to those calling from
   within the USA.  Calls to this number cost $2.50 per minute.

 . Phone support may be also be obtained by calling +1 (212) 854-5126.
   This number may be called from anywhere in the world.  The cost of
   each call is $25.00, chargeable to your MasterCard or Visa account.

 . Phone support is available at no charge to tech-support liaisons at
   sites that have purchased site licenses or bulk right-to-copy licenses.
   The number is +1 (212) 854-5126; a bulk or site license serial number
   is required.  (Note: this category presently applies only to Kermit 95)

Technical support is also available at no direct charge as follows:

 . On the Web.  Point your Web browser at http://www.columbia.edu/kermit/
   and look through the Kermit FAQ and other topic areas.

 . By netnews.  Read and post questions to comp.protocols.kermit.misc.
   Members of the Kermit team will respond to questions on a best-effort
   basis.  Others may also respond.

 . By email to kermit-support@columbia.edu.  Members of the Kermit team
   will respond to questions on a best-effort basis.

Why the new policy?  Simple: One-on-one telephone support is costly and
inefficient, and the demand for it has been skyrocketing in recent years.
Charging for this service will allow us to expand it to keep pace with
demand.

You may begin using the 900 number right away.  Callers to 854-5126 will
be informed that this service will no longer be free after November 30.

Thank you for helping us to serve you better!

Frank da Cruz and Christine M. Gianone
Managers, the Kermit Project
Columbia University

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-


Article 3959 of comp.protocols.kermit.misc:
Path: cs.utk.edu!nntp.memphis.edu!nntp.msstate.edu!cssun.mathcs.emory.edu!swrinde!tank.news.pipex.net!pipex!news.mathworks.com!newsfeed.internetmci.com!chi-news.cic.net!news.wctc.net!spcuna!news.columbia.edu!watsun.cc.columbia.edu!fdc
Newsgroups: comp.protocols.kermit.misc
Subject: Re: how to get  DOS kermit c source code?
Message-ID: <46jurh$c8l@apakabar.cc.columbia.edu>
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Date: 25 Oct 1995 00:02:57 GMT
References: <45pk9f$so3@info.bta.net.cn> <4672ol$pak@Venus.mcs.com>
 <1995Oct20.092232.64321@cc.usu.edu> <46hf3j$li3@Mercury.mcs.com>
Organization: Columbia University
NNTP-Posting-Host: watsun.cc.columbia.edu
Lines: 28

In article <46hf3j$li3@Mercury.mcs.com>, Leslie Mikesell <les@MCS.COM> wrote:
>...
>What I'm saying is that Berkeley copyrighted code has found it's way
>into almost everything, and has helped a lot of people.  There is
>room for freeBSD, BSDI, and things like 'slirp', a slip/ppp emulation
>that is basically a full tcp/ip implementation running in user
>space that would never have happened if the base code had been
>restricted.  Once upon a time I thought that was the philosopy
>behind kermit too.
>
>
It was, but times changed.  I think you are missing the difference between
the Kermit project and various other projects on the net that you
associate with "free software".  The difference is: we are working on this
full time, and with some of us, it is our real job -- even our career.  We
are here for the long haul, as long as there is a demand, to develop and
support Kermit protocol and software.  You can't say that about most of
the other software that you cite.  The BSD project is shut down, the
people scattered to the wind.  Many of the other examples are one-shot
deals -- the people who created them moved on to something else -- you
can't get good, dependable support for that type of software.  You can for
Kermit.

By the way, if you or anybody else wants to contribute code, make
improvements, etc, nothing is stopping you.  But you have to leave
administration of our copyright up to us, because long after you have
moved on to something else, we will still need to be here.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 4318 of comp.protocols.kermit.misc:
Path: cs.utk.edu!stc06.ctd.ornl.gov!fnnews.fnal.gov!uwm.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!usc!chi-news.cic.net!news.wctc.net!spcuna!news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Caps-Lock Problem with K95
Date: 12 Dec 1995 13:32:13 GMT
Organization: Columbia University
Lines: 15
Message-ID: <4ak08t$850@apakabar.cc.columbia.edu>
References: <30cc57f7.3760203@news.sccsi.com>
NNTP-Posting-Host: watsun.cc.columbia.edu

In article <30cc57f7.3760203@news.sccsi.com>,
Joe Winett <jwinett@tulsa.com> wrote:
> Has anyone had weird problems with Upper and Lower case in K95?
> Sometimes it's like Kermit is in CapsLock, but all keys are really
> shifted -- 'a' sends 'A' and '7' sends '&', etc...
>
This is a bug in the Windows 95 console driver.  Caps Lock acts like Shift
Lock for 32-bit console applications that read scan codes (not just
characters).  Hopefully Microsoft will fix it.  There is no way to fix it
in Kermit, as it stands, because the characters you see are the ones that
Windows is reporting.  We are working to convert Kermit 95 to a full GUI,
non-console application, and that will avoid the problem by not using
Microsoft's console driver any more.  Watch this space for announcements.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 4341 of comp.protocols.kermit.misc:
Path: cs.utk.edu!cssun.mathcs.emory.edu!swrinde!newsfeed.internetmci.com!in1.uu.net!news.new-york.net!news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Unix WordPerfect and MSKerm3.14
Date: 19 Dec 1995 14:52:05 GMT
Organization: Columbia University
Lines: 52
Message-ID: <4b6jil$6l7@apakabar.cc.columbia.edu>
References: <95352.095758U54294@uicvm.uic.edu>
NNTP-Posting-Host: watsun.cc.columbia.edu

In article <95352.095758U54294@uicvm.uic.edu>,
<U54294@uicvm.uic.edu> wrote:
> Following the instructions in KERMIT.BWR got my WordPerfect 5.1 on
> SCO SV386 3.2v4.1 running smoothly. BUT...can someone tell me why
> removing the VT320 reset from WordPerfect's terminal initialization
> string should keep MS-Kermit 3.14 from switching character-writing
> direction? (This was my symptom, anyway).
>
Our first attempt, circa 1990, at implementing a mechanism by which the
host could control the terminal emulator was the "TERMINALR/TERMINALS"
macros, which could be invoked by a high-numbered escape sequence we
thought would be safe:

 ESC [ 34 h / l

Before choosing this sequence we not only researched the DEC technical
manuals, but also made numerous frustrating attempts to contact the
authority within DEC that was in charge of assigning new escape sequences
to ensure that DEC did not have any plans for this one, and request that
they reserve it for us.  We were never able to locate the right people.
So, perhaps unwisely, we went forward with this feature, and the UNIX and
VMS WordPerfect used this feature heavily to dynamically switch key maps.

As luck (or Murphy's Law) would have it, DEC subsequently picked this same
sequence to control screen-writing direction in its Hebrew-model
terminals, and later this sequence found its way into many applications
that had nothing to do with Hebrew, as a standard part of the terminal
initialization.  Soon, users of diverse VMS applications such as DECnotes,
All-In-1, etc, began to report that whenever they started up these
applications, strange things would happen: a file would begin to transfer,
their key map would change, etc.  In fact, these were the actions defined
in their TERMINALR macros.

So we had to give up on the TERMINALS/TERMINALR mechanism in version 3.14
and adopted the far more flexible APC mechanism, and changed Kermit to
treat the former TERMINALS/R escape sequence as a screen-writing direction
changer.  So now users of the "old" WordPerfect and the new Kermit were
in for a new surprise -- their screens would come out backwards!

In short, both Kermit and WordPerfect had to be changed to get around the
conflict between the two uses for the same escape sequence.

The tale is told in the KERMIT.BWR file for version 3.14, in the
Incompatibilities section, and the new APC mechanism is documented in the
KERMIT.UPD file, Section 10.

> Incidentally, for the umpteenth time, thanks to da Cruz,
> Gianone, Doupnik and the cast of thousands who made Kermit.
>
On behalf of all of us, you're very welcome!

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 4408 of comp.protocols.kermit.misc:
Path: cs.utk.edu!willis.cis.uab.edu!nntp.msstate.edu!cssun.mathcs.emory.edu!swrinde!news-relay.us.dell.com!natinst.com!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: The Future (was Re: Connecting to the Same Site Multiple Times)
Message-ID: <1995Dec29.173301.70177@cc.usu.edu>
Date: 29 Dec 95 17:33:01 MDT
References: <4bcrfp$lvh@piano.synapse.net> <4bt2qs$ap@gaia.ns.utk.edu> <4c1kem$j5r@huron.eel.ufl.edu>
Organization: Utah State University
Lines: 108

In article <4c1kem$j5r@huron.eel.ufl.edu>, afn10375@afn.org (David A. Johns) writes:
> Joe Doupnik (jrd@cc.usu.edu) wrote:
> 
> #   > Out of curiosity, do any of these priorities involve                  
> #   > MSDOS-Kermit, or has development on that platform essentially         
> #   > stopped?                                                              
> #   -----------
> #           I hope you favor dogs rather than cats, given what 
> #   curiosity does. Just what is it that you need?

	That's quite a wish-list David, and a couple days after the
official due-date! But let me add a few comments on the items as we
talk here on News.
  
> Well, I think my vote would go for more functionality in the 
> scrollback buffers (mark and save, search, buffer input while viewing 
> the buffer, etc.) and a real plain-text session log (and yes, I have 
> read the .bwr).  

	I guess you mean full editing, and hence a reasonably competant
full screen editor to match. That's quite a bit of code, and any editor
would have to work by shutting off comms so that screen and keys remain
strictly local. Also the scroll back buffer normally lives above 1MB, in 
expanded memory. That means the editor needs spill buffers up there too
to handle the large rollback buffers permitted by MSK. I think its easy
to see that this can get out of hand.
	The session log is plain-text if that's all the host sends to us.
Which means it sends a line of text followed by CR/LF, and no cursor 
steering, screen embellishments (bold, reverse video, etc), whatnot that
make up full screen work rather than glass-tty work. Otherwise our screen
is likely decorated semi-randomly as the cursor is moved here and there,
and thus what we see isn't the way things arrive or logged.
  
> I'd also like to see a way to preserve the scrollback buffer when 
> logging out of a TCP session.

	It is preserved, actually. But to see it we must be in terminal
emulation mode where the character sets and visual attributes are available.
It is available when a new session is started, or when we rollback during
another session.
  
> A nice addition to the script language would be a handful of 
> user-defined string triggers, like the string that starts automatic 
> ZModem downloads in programs that have that (I think NetTerm, a 
> winsock program, also watches for the KERMIT READY TO SEND signal and 
> starts a download hands-off).
  
	We've thought about these too. It might help to understand how
matters work. Triggers require that MSK buffer bytes entering the terminal
emulator, do not act on them, and do parsing of the accumulated stream as
each byte arrives. MSK does this for host-triggered printing, and for the
APC command. Those commands are well structured, short, and unambiguous
(not overlapping any other acceptable commands). So, accumulation/constant
reparsing without display and hence bursty screen updates (if any sometimes)
turns out to be not what people would accept, nor would I for that matter.
	We put a lot of thought into the security side too. Whatever happens
must be safe and under control of the user; no launch and forget strategy.
That means we don't launch external programs based on arbitrary strings
arriving. Not only do such strings happen in other circumstances (rather
like the Hayes triple + syndrome) but the consequences may not be what the
user can live with.
  
> Someone else has just mentioned having full access to the input 
> buffer.  I managed to use \v(input) to get the IP address on a SLIP 
> line (thus fully automating the process you outline in the network 
> docs), but I can imagine it would be nice to be able to work with more 
> than one line.

	As mentioned previously, a succession of INPUT statements can
gather a succession of "lines", so that facility exists now.
  
> It would be nice to have input that comes in while at the command 
> prompt (like when a macro is running or during a transmit) piped back 
> into the emulator so that they end up in the log and the buffer.

	You have a point. It's not possible presently. I should caution
that INPUT is not always running and hence there are gaps in the INPUT
buffer stream, and that stream wraps in its circular buffer. INPUT material
does go into the session log.
 
> Right now if you call MSK from another program it can read the port 
> speed, but not the parity.  I have one system I call that uses 7o1 
> (yes, odd parity), so in order to write general transfer scripts (in 
> Commo's macro language), I have to parse out the parity and send it to 
> Kermit.  Since DOS reports the parity (with MODE and MSD, at least), 
> it seems that Kermit should be able to read it.  

	? MSK does not run UART chips with hardware parity. Hardware
parity is a nice way of not communicating due to differences at each
end. MSK uses parity in software and it is highly forgiving during terminal
emulation (SET DISPLAY 7/8 etc). Furthermore, during file transfers MSK
automatically determines parity as much as is possible, and switches to
it with a message. I can add code to probe the UART for existing parity,
if that would really do a lot of good.
  
> By the way, I use Commo, calling Kermit for special purposes rather 
> than using Kermit for everything primarily because of the first three 
> suggestions above.
>  
> I could probably think of more if you're interested.

	Wishlists are always welcomed, even though only portions are
possible to include in the programs.
 
> David Johns

	Thanks David,
	Joe D.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 4472 of comp.protocols.kermit.misc:
Path: cs.utk.edu!cssun.mathcs.emory.edu!gatech!newsfeed.internetmci.com!howland.reston.ans.net!torn!news.ccs.queensu.ca!news.ccs.queensu.ca!not-for-mail
From: mike@ccs.queensu.ca (Mike Smith)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: 2 PCs directly linked?
Date: 12 Jan 1996 08:54:55 -0500
Organization: Queen's University, Kingston
Lines: 33
Sender: mike@post.queensu.ca
Message-ID: <4d5p7f$dmj@ccs-sparc2.queensu.ca>
References: <4d3i3q$nn0@n.ruf.uni-freiburg.de>  <4d4bgc$59o@apakabar.cc.columbia.edu> <4d5fj6$jfk@huron.eel.ufl.edu>
NNTP-Posting-Host: ccs-sparc2.ccs


In article <4d5fj6$jfk@huron.eel.ufl.edu>, djohns@freenet4.freenet.ufl.edu (David A. Johns) writes:

|> I know Kermit can do almost anything, but this seems like overkill to
|> me.  If the machines are close enough to use a null modem, the obvious
|> answer isn't a terminal program, but the Interlink program that comes
|> with DOS.  With that program you can not only send directory
|> structures (with xcopy), but you can also zip files from one machine
|> into an archive on the other, use the DOS replace program to update or
|> freshen files, etc., etc.  The DOS help file under intersvr.exe even
|> describes how to transfer the server files from one machine to the
|> other without needing disks.
|> 
|> David Johns

Maybe.  Maybe not.  I tried to set up Interlink for a friend who wanted to
move stuff from his laptop to his desktop.  He lives in another city and
didn't forewarn me I would be consulting during my visit. :-)  Anyhow,
whether it was ignorance on my part or something odd about Interlink
running bwtween his two particular machines, the file transfers were
unbearably slow.  Fortunately we had access to the net and pulled down
a copy of MSK.  It worked beautifully.  And I discovered something that
surprised me--there was a dramatic improvement in file transfer speed
when the server was the old laptop rather than the new desktop.  This
is contrary to Frank's advice so perhaps my memory is wrong.  However,
it is definitely worth testing both possibilities on your equipment.
In our case, the change improved file transfer speed from 3,700 to 10,000 cps.
Which is kind of "Wow!" when you see it happen.
-- 
 
 Mike Smith                                  mike@ccs.queensu.ca
 Queen's University                          Michael.D.Smith@QueensU.CA
 Computing and Communications Services       (613) 545-2024

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 4555 of comp.protocols.kermit.misc:
Path: cs.utk.edu!news.msfc.nasa.gov!news.ingr.com!news.internetMCI.com!newsfeed.internetmci.com!chi-news.cic.net!usc!ccnet.com!rahul.net!a2i!dold.a2i!dold
From: Clarence Dold <dold@rahul.net>
Newsgroups: comp.protocols.kermit.misc
Subject: Re: K95: Caps Lock affects number keys
Date: 29 Jan 1996 05:54:09 GMT
Organization: a2i network
Lines: 28
Message-ID: <4ehne1$33b@hustle.rahul.net>
References: <310c534e.104050636@news.aus.sig.net>
NNTP-Posting-Host: foxtrot.rahul.net
NNTP-Posting-User: dold

Ami Bar-Yadin (ami@sig.net) wrote:
: I use K95 to dial in to my office's computer, and was using an old
: program which requires it's menu selections to be entered in upper
: case, so I pressed CAPS LOCK on my keyboard.  When I needed to enter
: some dates, I used the number keys on the main keyboard (not the
: numeric pad) and got the symbols instead of digits, ie ")!@#(%"
: instead of "012395".

From the file "bugs.doc", in the K95 distribution:

.6. Keyboard Scan Codes (M)
.
.Certain keyboard scan codes, constructed by Kermit 95 from information
.reported by Windows, are inconsistent between Windows NT and Windows 95.
.These include Num Lock and Numeric Keypad /.
.
.More seriously, Windows 95 returns returns the shifted version of
.non-alphabetic characters when Caps Lock is on; for example, if you press
.the "2" key on a USA keyboard with Caps Lock on, you get "@" instead of "2".
.This is a Window 95 bug.  The same code under Windows NT returns the correct
.values.

This bug doesn't seem to affect Notepad.exe or MSDOS windows.

-- 
---
Clarence A Dold - dold@rahul.net
                - Pope Valley & Napa CA.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 4564 of comp.protocols.kermit.misc:
Path: cs.utk.edu!stc06.ctd.ornl.gov!fnnews.fnal.gov!uwm.edu!chi-news.cic.net!newsfeed.internetmci.com!panix!news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: MSDOS C-Kermit 3.14 Keyboard ScanCodes
Date: 30 Jan 1996 15:17:04 GMT
Organization: Columbia University
Lines: 18
Message-ID: <4elcpg$9hd@banzai.cc.columbia.edu>
References: <ombunmin3u.fsf@tees.cs.ualberta.ca>
NNTP-Posting-Host: watsun.cc.columbia.edu

In article <ombunmin3u.fsf@tees.cs.ualberta.ca>,
Vladimir Alexiev  <vladimir@cs.ualberta.ca> wrote:
: (Frank, if you think this is useful, feel free to put it in the
: distribution.) 
: 
: MSDOS C-Kermit 3.14 Keyboard ScanCodes for 88-keyboard (decimal).
: Please send additions (especially 101-keyboard codes) and corrections
: to vladimir@cs.ualberta.ca.  29 Jan 1996
: 
: key       norm shft ctrl  c+s  alt  s+a  c+a c+s+a
: --------- ---- ---- ---- ---- ---- ---- ---- ----
: Space      313  825 1337 1849 2361 2873 3385 3897
: 
Thank you, Vladimir.  In fact, this table already appears in "Using
MS-DOS Kermit" (and its translations), and it is also online in the
archive as kermit/a/msvibm.key, dating from 1989.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 4570 of comp.protocols.kermit.misc:
Path: cs.utk.edu!news.msfc.nasa.gov!newsfeed.internetmci.com!inet-nntp-gw-1.us.oracle.com!news.caldera.com!news.cc.utah.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: K95 emacs.ini doesn't map Alt as Meta
Message-ID: <1996Jan30.090609.72706@cc.usu.edu>
Date: 30 Jan 96 09:06:09 MDT
References: <yrazqbiymmp.fsf@panix.com> <4e62gs$63d@apakabar.cc.columbia.edu> <om68duimit.fsf@tees.cs.ualberta.ca>
Organization: Utah State University
Lines: 16

In article <om68duimit.fsf@tees.cs.ualberta.ca>, Vladimir Alexiev <vladimir@cs.ualberta.ca> writes:
> In article <4e62gs$63d@apakabar.cc.columbia.edu> jaltman@watsun.cc.columbia.edu (Jeffrey Altman) writes:
> 
>> Ctrl-Space.
>> SET KEY \1056 \Knull
> 
> 1056? On my keyboard it's 1337! (IBM XT 84 keys, DOS 3.1, MS-Kermit 3.14).
> And I just posted a list of all the scancodes... I guess it won't be very
> useful then :-(
----------
	Whoa! MS-DOS Kermit deals with keyboards by reading what the Bios
reports. It does not have a canned list of every "scan code" in the program.
And it's not C Kermit but MS-DOS Kermit (no relation).
	You have just demonstrated the failure of the canned table approach,
and the success of the MS-DOS Kermit approach. Machines can and will differ.
	Joe D.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 1755 of comp.sys.stratus:
Path: cs.utk.edu!not-for-mail
From: shuford@cs.utk.edu (Richard Shuford)
Newsgroups: comp.terminals,comp.os.msdos.apps,comp.os.msdos.mail-news,comp.protocols.kermit.misc,comp.sys.stratus
Subject: Monty Python, Flying Sheep, and Kermit (was Re: Searching Terminal for XT-PC)
Followup-To: comp.protocols.kermit.misc
Date: 2 Feb 1996 16:54:06 -0500
Organization: University of Tennessee, Knoxville--Dept. of Computer Science
Lines: 67
Distribution: world
Expires: 30 Mar 1996 22:11:22 EST
Message-ID: <4eu15uINN4ad@duncan.cs.utk.edu>
References: <4e3uol$jur@news.rhrz.uni-bonn.de> <4eivvv$4q2@news1.wing.net> <4erosl$9mr@sun001.spd.dsccc.com>
NNTP-Posting-Host: duncan.cs.utk.edu
Summary: modern Kermit implmentations can be fast
Keywords: Kermit, terminal, protocol
Xref: cs.utk.edu comp.terminals:5375 comp.os.msdos.apps:27952 comp.os.msdos.mail-news:4867 comp.protocols.kermit.misc:4579 comp.sys.stratus:1755

In article <4erosl$9mr@sun001.spd.dsccc.com>,
    jmccarty@spd.dsccc.com (Mike McCarty) writes:
>
>>)Axel Schneider (schneid2@zeus.informatik.uni-bonn.de) wrote:
>):
>): I am looking for a terminal program, that is suitable for an XT
>): IMB-compatible PC, can run under DOS 3.0 and fits on a 360kB Floppy
>): Disk (no harddisk available). 
>
> Kermit is okay if all you ever want to do is pretend to be a terminal.
> But if you want to do general communications, it is terrible. File
> down/upload are quite slow.

Monty Python's Flying Circus once did a sketch about Flying Sheep.

One character observed, "Notice that they do not so much fly as plummet."

The old farmer leaned on his fence and explained, "Sheep are dim.
Once they get an idea into their heads, there's no shifting it."

A similar case has arisen with popular opinion concerning the Kermit
file-transfer protocol.  

Unless you are a sheep (or a technical writer for a modem vendor),
remember this:  If you use Kermit correctly, it ain't necessarily slow.

With a correctly done implementations of the modern Kermit protocol in
place on BOTH ends of the connection, with both client and server
given appropriate setup commands, Kermit transfers can be as fast as
your modem will run.

Three things contribute to the misconception:

(1) Many host-system administrators have failed to install a new version
    of Kermit on their systems in the last 10 years.  The older programs
    may not have support for long packets and sliding windows--the modern
    protocol features which increase speed.

(2) The default tuning parameters are conservative, in the sense of wanting
    to make certain that SOME data transfer happens, even if slowly, despite
    possibly hostile communication conditions.  Whereas other popular
    protocols take the attitude, "If I can't go fast, I won't go at all."

(3) The instruction books for most new modems assert, with no reasons
    given, that "Kermit is slow".  The writers, we assume, are not aware
    of issues (1) and (2).

I'm typing this using MS-Kermit 3.14, the most recent Kermit program
by Joe Doupnik for MS-DOS. It performs an excellent emulation of a DEC
VT320 terminal and performs the Kermit file-transfer protocol with the
speed-enhancing long packets, sliding windows, and prefix control. (And
it fits on a floppy disk.)

The latest C-Kermit program, by many authors, is available for many
systems, including those running UNIX, VMS, AOS/VS, OS/2, or Stratus
VOS, and also implements those features.

The World Wide Web site for Kermit is entered by this URL:

    http://www.columbia.edu/kermit/

and performance issues are discussed in this section:

-- 
 ...Richard S. Shuford  | "Plans fail for lack of counsel,
 ...shuford@cs.utk.edu  |  but with many advisers they succeed."
 ...Info-Stratus contact|  Proverbs 15:22 NIV


 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!gatech!newsfeed.internetmci.com!panix!usenet
From: bsd@panix.com (Brian Downing)
Subject: Re: K95 emacs.ini doesn't map Alt as Meta
Date: 27 Jan 1996 11:40:43 -0500
Organization: PANIX Public Access Internet and UNIX, NYC
Lines: 27
Sender: bsd@panix.com
Message-ID: <yrazqb94mlw.fsf@panix.com>
References: <yrazqbiymmp.fsf@panix.com> <4e62gs$63d@apakabar.cc.columbia.edu>
	<yraohrp92pw.fsf@panix.com>
NNTP-Posting-Host: panix.com
In-reply-to: bsd@panix.com's message of 27 Jan 1996 08:39:08 -0500
To: bsd@panix.com (Brian Downing)
X-Newsreader: Gnus v5.0.13

In article <yraohrp92pw.fsf@panix.com> bsd@panix.com I wrote:

   ;from emacs.ini
   set key \2168 \27x     ; Alt-x
   set key \2168 \27y     ; Alt-x

   ;should be
   set key \2168 \27x     ; Alt-x
   set key \2169 \27y     ; Alt-x

Obviously I meant

   ;from emacs.ini
   set key \2168 \27x     ; Alt-x
   set key \2168 \27y     ; Alt-y

   ;should be
   set key \2168 \27x     ; Alt-x
   set key \2169 \27y     ; Alt-y

I didn't cut and paste from window to window so I messed up the comments
when I typed and then cut/paste w/emacs.

-- 
[  Brian Downing  ]
[  bsd@panix.com  ]
[   '95 VFR750F   ]

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-


Article 4613 of comp.protocols.kermit.misc:
Path: cs.utk.edu!stc06.ctd.ornl.gov!fnnews.fnal.gov!uwm.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!newsfeed.internetmci.com!inet-nntp-gw-1.us.oracle.com!news.caldera.com!news.cc.utah.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: bugs in Ckermit and Mskermit vt100 mode
Message-ID: <1996Feb9.064844.73658@cc.usu.edu>
Date: 9 Feb 96 06:48:43 MDT
References: <4fe3po$1gr@bignews.shef.ac.uk>
Organization: Utah State University
Lines: 17

> 
> 2) With MsKermit 3.14 for DOS with input echo on in an automated
> login sequence, the vt100 initialization string returned by tset
> (?) will result in the screen being switched to 40 column mode.
> This happens with the termcap/terminfo supplied with SCO UNIX ODT
> 3.0.  This does <not> happen for logins done by hand.  The
> problem appears only with <script> driven logins.
> 
> Running mode bw80 will reset the screen to the proper display.
----------
	Because while using scripts all screen writing is done at the 
Kermit prompt level by DOS, not via the terminal emulator. ANSI.SYS is
loaded on your machine and it does the 40 column mode change in response to
the probe from the remote host. No script can fully emulate a terminal of
the VT100 class and above, so you may wish to limit how much a script is
permitted to do before Connect mode is activitated.
	Joe D.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Path: cs.utk.edu!gatech!news.mathworks.com!news.kei.com!nntp.coast.net!howland.reston.ans.net!psinntp!psinntp!psinntp!psinntp!news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: bugs in Ckermit and Mskermit vt100 mode
Date: 9 Feb 1996 15:29:30 GMT
Organization: Columbia University
Lines: 66
Message-ID: <4ffp8q$l2c@apakabar.cc.columbia.edu>
References: <4fe3po$1gr@bignews.shef.ac.uk>
NNTP-Posting-Host: watsun.cc.columbia.edu

In article <4fe3po$1gr@bignews.shef.ac.uk>,
Earl H. Kinmonth <cck@kuso.shef.ac.uk> wrote:
: I have observed the following unfriendly behavior in vt100 mode 
: with Ckermit and Mskermit:
: 
: 1) With Ckermit for OS2 running under OS2 Windows 3.0 Japanese,
: garbage (control characters?) in English language posts will
: cause Ckermit to switch to a mode in which everything on screen
: appears in the Japanese katakana font although the source text is
: actually ascii.  This is purely an internal Ckermit problem.
: Using ALT+X to go to the command prompt gives a standard English
: display.
: 
: So far I've found nothing other than restarting Ckermit that will
: fix this situation.
: 
If you could send us a session log that demonstrates the problem,
along with the relevant C-Kermit configuration (particularly the
SHOW TERMINAL display), we could give a specific diagnosis.
However, it will probably not turn out to be a bug.  The
terminal-to-host connection uses a certain presentation protocol,
whose details depend upon the terminal type and other factors, but
which works by mixing control information with real data.  Control
information is commonly called an "escape sequence".  We are all
familiar with escape sequences that position the cursor on the
screen, clear the screen, and so on.

There are also escape sequences that change the character set.  In
the VT220 and above series of terminals, these sequences are as spelled
out by ISO standards 4873 and 2022, and the International Register
of Character Sets.

It is intrinsic to the very design of terminal-to-host protocols that
"garbage" can take the same form as a valid escape sequence.  The
terminal has no way of telling the difference.  In your case, however,
I suspect that we are not seeing garbage at all, but -- since I take
it you are reading a Japanese newsgroup -- the text of the posting
actually contains a "switch-to-Kanji" (or Katakana, etc) sequence,
perhaps an improper one generated by the poster's news software.

But since OS/2 C-Kermit does not yet support Japanese terminal
emulation, as MS-DOS Kermit 3.14 does, the Kanji comes out wrong.

In any case, should your C-Kermit screen switch into Kanji or any
other undesired character set because of garbage or any other
reason, you should be able to switch it back with the Reset button,
Alt-R, verb \Kreset.  Failing that (it shouldn't fail), you can
also escape back to the prompt (Alt-X) and give the appropriate SET
TERMINAL CHARACTER-SET commands.

: 2) With MsKermit 3.14 for DOS with input echo on in an automated
: login sequence, the vt100 initialization string returned by tset
: (?) will result in the screen being switched to 40 column mode.
: This happens with the termcap/terminfo supplied with SCO UNIX ODT
: 3.0.  This does <not> happen for logins done by hand.  The
: problem appears only with <script> driven logins.
: 
: Running mode bw80 will reset the screen to the proper display.
: 
Right.  This is a well-known problem, documented for years in the
"beware file".  Solution: either don't SET INPUT ECHO ON during logins,
or else don't run ANSI.SYS.  (The problem is that an escape sequence
sent by the UNIX system is interpreted as "switch to 40 column
mode" by ANSI.SYS.  It's not a Kermit problem.)

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 4644 of comp.protocols.kermit.misc:
Path: cs.utk.edu!gatech!newsfeed.internetmci.com!vixen.cso.uiuc.edu!howland.reston.ans.net!usc!sdd.hp.com!hamblin.math.byu.edu!park.uvsc.edu!news.cc.utah.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: DOS Kermit over Win 95 TCP/IP?
Message-ID: <1996Feb17.193212.74384@cc.usu.edu>
Date: 17 Feb 96 19:32:12 MDT
References: <1996Feb17.173041@aik.tec.sc.us>
Organization: Utah State University
Lines: 23

In article <1996Feb17.173041@aik.tec.sc.us>, timmons@aik.tec.sc.us (Ray Timmons (803) 593-9954 ext. 1210) writes:
> Our networked PC's on campus are using the dis_pkt9.dos packet driver
> to run DOS kermit over the MS Windows for Workgroups TCP/IP stack.
> 
> Is there a way to do the same thing in Win 95?  I know that there is
> a Win 95 Kermit, but we don't have the money to buy it, nor the time 
> to teach another kermit interface.
> 
> Ray T.
---------
	Adding a little precision to your statement: you are running MS'
older 16-bit TCP/IP stack over their NDIS v2 16-bit/real mode drivers.
Win95 wants to use NDIS v3 protected mode (also 32-bit) material over
another MS TCP/IP stack. Once going that TCP/IP stack stays there, and
you can't run another TCP/IP stack at the same time.
	Two comments. You can run Win95 with Novell's ODI material,
real mode, and use MS-DOS Kermit within Win95. Shims ODIPKT + WINPKT
do the trick fine. If you use an NDIS v2 board handler and ignore MS'
TCP/IP stack then you can use the same scheme as you do now. Secondly, 
"teach another Kermit interface" is putting matters in a rather extreme 
form, don't you think? I doubt there is much "teaching" needed, and the
commands are very very similar to those in MSK.
	Joe D.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 4633 of comp.protocols.kermit.misc:
Path: cs.utk.edu!stc06.ctd.ornl.gov!fnnews.fnal.gov!uwm.edu!vixen.cso.uiuc.edu!newsfeed.internetmci.com!in1.uu.net!nwnews.wa.com!nwfocus.wa.com!krel.iea.com!comtch!andersr
From: andersr@comtch.iea.com (Rod Anderson)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Kermit - Escaping to local mode in batch mode. URGENT!
Date: 15 Feb 1996 13:34:51 GMT
Organization: CompuTech
Lines: 25
Message-ID: <4fvcpr$2bh@krel.iea.com>
References: <4fqncp$mkk@igate2.pt.cyanamid.com>
NNTP-Posting-Host: comtch.iea.com
X-Newsreader: TIN [version 1.2 PL2]

Bala Balakrishnan (balakrishnanb@cyanamid.com) wrote:
: I am trying to write a shell script which will use kermit for file 
: transfer in non-interactive mode. Kermit will be used to connect from a 
: unix machine to a OS/2 which will be placed in "Send" mode. At that point 
: I have to "Escape" back to my local kermit and issue a "receive" command 
: to get the file.

You probably want to place the remote system in server mode and let the 
local system control it via Kermit's scripting language.

This allows you to monitor the progress: logon, start-up of kermit, etc. 
and use appropriate actions for almost all situations.  One of the 
systems I (my program) upload to has varying (really varying) times 
between prompts for logging on.  Using loops, timed input, and success 
codes the program can get logged on almost regardless of the 
time between prompts.

I'm at home right now so don't have access to a script but if you're 
interested in seeing one of these as an example mail me and I'll send it 
to you.

Rod
-----
Please don't tell my mother I work for the government.
She thinks I play piano in a bordello.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-


Article 4638 of comp.protocols.kermit.misc:
Path: cs.utk.edu!gatech!newsfeed.internetmci.com!in2.uu.net!citicorp.com!news.new-york.net!news.columbia.edu!watsun.cc.columbia.edu!jaltman
From: jaltman@watsun.cc.columbia.edu (Jeffrey Altman)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Kermit - Escaping to local mode in batch mode. URGENT!
Date: 16 Feb 1996 06:06:14 GMT
Organization: Columbia University
Lines: 25
Message-ID: <4g16sm$4vj@apakabar.cc.columbia.edu>
References: <4fqncp$mkk@igate2.pt.cyanamid.com> <4fsutm$ilp@apakabar.cc.columbia.edu> <4fviat$467@igate2.pt.cyanamid.com>
NNTP-Posting-Host: watsun.cc.columbia.edu

In article <4fviat$467@igate2.pt.cyanamid.com>,
Bala Balakrishnan  <balakrishnanb@cyanamid.com> wrote:
>Kermit on the OS/2 is running in server mode waiting for an incoming 
>connection. All I need is a script which I can start from Cron on the
>unix side to be able to login to the OS/2 and get the files. 


then all you should need to do is say 

	kermit <scriptfile>

where <scriptfile> does something like

set network tcp/ip
set host <os2machine> <portnumber>
if failure end
get <files>
send <files>
....
hangup
exit
Jeffrey Altman * PO Box 220415 * Great Neck, NY * 11022-0415 * (516) 466-5495
               * 612 West 115th St #716 * New York, NY * 10025 * (212) 854-1344
  C-Kermit 5A(191) for OS/2:   http://www.columbia.edu/kermit/cko191.html
  Kermit 95 for Windows 95 :   http://www.columbia.edu/kermit/k95.html

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Path: cs.utk.edu!cssun.mathcs.emory.edu!swrinde!howland.reston.ans.net!news.cac.psu.edu!psuvm!hdk
Organization: Penn State University
Date: Wed, 14 Feb 1996 13:21:29 EST
From: H. D. Knoble <HDK@psuvm.psu.edu>
Message-ID: <96045.132129HDK@psuvm.psu.edu>
Newsgroups: comp.protocols.kermit.misc
Subject: Re: MS Kermit under OS/2 IAK
References: <4fksqu$rfk@news.eecs.umich.edu>
 <1996Feb11.101002.73807@cc.usu.edu>
Lines: 34

Using MS-Kermit in the following way enables tektronix graphics support
where it may not be supported (as well) otherwise.

COMTCP comes with OS/2 IBM TCPIP 2.0 and with Warp Connect. To run MS-Kermit
telnet via COMTCP, get the latest MS-Kermit patch file, and see the following
notes:

COMTCP is a DOS box command and works as follows:

            COMTCP hostname kermit patch, set port bios1, stay

       (i.e., no MSKERMIT.INI used; also worked with MSKERMIT.INI issuing
       PATCH and SET PORT BIOS1). After the above command, at the MS-Kermit>
       prompt, to Telnet, simply issue MSK subcommand: Connect
       and login to the host telnetted to as usual.

       Notes:
          (1) A separate WIN-OS2 (DOS) session using TCP/IP 2.0 Winsock, and
              a separate OS/2 TCP/IP 2.0 Webexplorer session, was running
              simultaneous with the above COMTCP Kermit session. That is,
              COMTCP is correctly multi-threaded by OS/2 Warp and TCP/IP 2.0.

          (2) A DOS Windowed session can be used to conduct a Telnet session.
              However, if a Windowed DOS session was used to do Tek Plotting,
              when the (Gnuplot) plot subcommand is issued, OS/2 Warp opens
              an Information Window which reads:
              "The system does not support this session's video in a window"
              and the DOS Window title changes to: Suspended: Kermit.exe
              At this point the connection to the Vax remains intact; clicking
              on the DOS Window Control Menu box (upper left-hand corner) and
              choosing Full-Screen from that menu (or pressing Warp hot key
              Alt-Home which toggles between DOS Window and DOS Fullscreen
              for that virtual DOS session) resumes the Vax session dialog,
              and then the Tek Plot displays as though DOS Full-screen was
              chosen in the first place.


 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 4629 of comp.protocols.kermit.misc:
Path: cs.utk.edu!news.msfc.nasa.gov!newsfeed.internetmci.com!howland.reston.ans.net!psinntp!psinntp!psinntp!psinntp!news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Kermit drops core at SET LINE /dev/cua1
Date: 14 Feb 1996 15:43:07 GMT
Organization: Columbia University
Lines: 42
Message-ID: <4fsvub$j2s@apakabar.cc.columbia.edu>
References: <4fr2nc$n0o@mozo.cc.purdue.edu>
NNTP-Posting-Host: watsun.cc.columbia.edu

In article <4fr2nc$n0o@mozo.cc.purdue.edu>,
Branden Robinson <branden@ecn.purdue.edu> wrote:
: I'm trying to run C-Kermit under Linux, but as soon as I type "set line
: /dev/cua1", kermit gets a segmentation fault.  This is the correct line, as
: evidenced by the fact that "echo ATDT" and a phone number redirected to
: /dev/cua1 makes the modem dial.
: 
: I thought this might have something to do with the lock file put on
: /dev/cua1, but both the compliation with the -DLINUXFSSTND and without it
: yield the same result.  What is going on here?
: 
: Relevant hardware:
:  Hayes Accura 14.4 + FAX internal on COM 2
: 
: Relevant software:
:  Linux Debian 0.93R6, kernel 1.2.13, GCC 2.6.3, C-kermit 1.90
: 
C-Kermit 5A(190) was tested successfully on every known Linux variation at
the time it was released (October 1994), but since then what is
collectively known as Linux has been changing rapidly out from underneath
us, thanks in large part to its numerous repackagers.  Most of the
problems stem from the many and varied curses libraries; this is the first
report I have heard of this nature.  You might try:

 1. The Debian C-Kermit distribution, put together and tested by the
    Debian Project.  Maybe they linked it with different libraries than
    you did:

      ftp://kermit.columbia.edu/kermit/linux/

 2. The 5A(192) Alpha not-yet-a-release:

      ftp://kermit.columbia.edu/kermit/test/

 3. Taking a debug log of a core-dumping session and sending the last
    hundred lines or so to kermit@columbia.edu for analysis.  Also see if
    you can get a backtrace from the core file to find out what routine it
    was in when it faulted.  I don't know what the command for this is on
    Linux -- locally I use "adb kermit core" and then "$c", where "kermit"
    is Kermit's pathname and "core" is the core file's pathname.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 38480 of comp.sys.dec:
Path: cs.utk.edu!stc06.ctd.ornl.gov!fnnews.fnal.gov!uwm.edu!vixen.cso.uiuc.edu!newsfeed.internetmci.com!tank.news.pipex.net!pipex!peer-news.britain.eu.net!warwick!bham!bhamcs!news.ox.ac.uk!news.ox.ac.uk!rjm
From: rjm@swift.eng.ox.ac.uk (Bob Manners)
Newsgroups: comp.sys.dec,comp.os.vms
Subject: MicroVAX KERMIT woes ... resolved
Followup-To: comp.sys.dec
Date: 16 Feb 1996 12:17:07 GMT
Organization: Oxford University Engineering Department
Lines: 35
Distribution: world
Message-ID: <RJM.96Feb16121707@swift.eng.ox.ac.uk>
NNTP-Posting-Host: swift.eng.ox.ac.uk
Xref: cs.utk.edu comp.sys.dec:38480 comp.os.vms:132607


Thanks to all that helped out!

In summary (to get text uploads to work properly on the serial lines):

1)SYSGEN to set TTY_ALTYPAHD to 1000
2)reboot
3)SET TERM/PERM/AL_TYPADH/TYPEAHEAD/TTSYNC/HOSTSYNC
4)logout/login again
5)Set comms program on PC to Xon/Xoff 
6)COPY/ALLOCATE=nnn TTA0: file
7)Upload the .HEX file

This approach avoided the "Input overruns" I'd been seeing before ...

Thanks also to George Cornelius who was able to provide me with a
hexified version of VMSMIT.EXE (KERMIT32) for VMS 4.x. This is now
working beautifully on my venerable MicroVAXen.

Cheers,
Bob.
--

----------------------------------------------------------------------------
Robert Manners                                  Osney Laboratory
rjm@swift.eng.ox.ac.uk                          Dept of Engineering Science
                                                University of Oxford
                                                01865 288762
Computer Museum: http://swift.eng.ox.ac.uk/rjm/museum.html
Also:            http://swift.eng.ox.ac.uk

      "There's more to life than books you know, but not much more"
----------------------------------------------------------------------------


 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 4924 of comp.protocols.kermit.misc:
Path: cs.utk.edu!gatech!usenet.eel.ufl.edu!freenet4.afn.org!djohns
From: djohns@freenet4.afn.org (David A. Johns)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Good shareware Term program w/Kermit?
Date: 8 Apr 1996 11:34:23 GMT
Lines: 46
Message-ID: <4katjv$sfu@huron.eel.ufl.edu>
References: <Pine.PTX.3.91.960328100503.9347A-100000@odin.cc.pdx.edu>
 <4k7hg7$o0e@nadine.teleport.com> <4k8a3n$auv@huron.eel.ufl.edu>
 <4k919j$mnt@apakabar.cc.columbia.edu>
NNTP-Posting-Host: freenet4.afn.org
X-Newsreader: NewsWerthy 1.71 (unregistered)

In <4k919j$mnt@apakabar.cc.columbia.edu>, fdc@watsun.cc.columbia.edu (Frank da
Cruz) wrote:

#   Actually, MS-DOS Kermit is far from dead.

That's what I wanted to hear :-).

#   You're right, it isn't going to be redone from scratch, but I
#   expect it to see continued development for some time to come.
#   While the user interface is not exactly what you might want to
#   foist upon a computer newcomer who expects everything to have
#   a slick graphical appearance and to happen by magic,

Well, I'm not sure that internal configuration, a useful scrollback
and log, integrated script and emulation, or a dialing directory are
exactly "slick" and "magic."  They're about 1985 technology, right?

#   it is ideal for many other applications, including those in
#   which an "expert" uses the powerful script language and
#   customization features to configure it for a particular use,
#   organization, or environment, where it is then used by "naive"
#   users, sometimes even without their knowledge.

I agree 100%, and in fact, that's how I was introduced to MSK, in an
institutional setting.

#   Meanwhile, I think I speak for everybody in acknowledging the
#   debt of gratitude that is owed by the world's millions (yes,
#   millions) of MS-DOS Kermit users to Professor Joe Doupnik of
#   Utah State University for his continued and unflagging
#   generosity, skill, and dedication in developing and supporting
#   this program over the past ten (yes, ten) years since he took
#   it over.

Yes, if I remember correctly from the docs of the earliest MSK I used
(around 1987), Joe was credited with volunteering to rewrite
portions of the MSK code.  Some volunteer effort!  I hope he gets
community service brownie points at USU.

#   Yes, there is some hope.  Obviously, for reasons of survival,
#   Windows 95 and NT are our top priority, but we have not
#   forgotten about OS/2.

Glad to hear that too.

David Johns

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-


Article 4929 of comp.protocols.kermit.misc:
Path: cs.utk.edu!gatech!newsfeed.internetmci.com!panix!news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: DOS Kermit under Win95
Date: 9 Apr 1996 14:50:27 GMT
Organization: Columbia University
Lines: 36
Message-ID: <4kdtfj$19h@apakabar.cc.columbia.edu>
References: <bhuberDpJsBE.5D8@netcom.com>
NNTP-Posting-Host: watsun.cc.columbia.edu

In article <bhuberDpJsBE.5D8@netcom.com>, Bud Huber <bhuber@netcom.com> wrote:
: I have run into a problem with Kermit ver 3.14 level 9, having now
: upgraded to Windows 95. Kermit works okay, but the problem is with the
: dialing. Under Win 3.1 I used a "dial" command to connect with my local
: POP. Included in the phone number of the dialing was a "70#,," (without
: the quotes) prefix to disable call waiting, per my local phone company
: service needs. 
: 
: Problem is that since upgrading to Win95, this same dialing string is 
: not properly passed to the modem. Same Kermit 3.14, same hardware, same
: everything except for running at the DOS level of Win95. 
: 
MS-DOS Kermit is not recommended for Windows 95 or NT.  We support it for
all versions of DOS, 2.0 through the latest, plus Windows 3.x, DesqView,
etc, with every conceivable combination of hardware, networking, memory
management configuration, and so on.

In Windows 95, MS-DOS Kermit might work on a serial connection and it
might not.  You're on your own.  It won't work on most kinds of network
connections, and definitely not for TCP/IP connections.  That's why we
wrote Kermit 95:

  http://www.columbia.edu/kermit/k95.html

Having said that, I tried your scenario locally and the call-waiting
suppression string (70#,,) was passed to the modem just fine (modem = USR
Courier, speed = 57600, flow = RTS/CTS), no matter whether I used the DIAL
command or typed it directly at the modem in CONNECT mode (same thing with
Kermit 95).

But then when I went to exit from MS-DOS Kermit, the window froze and
Windows 95 threw up all sorts of alert boxes.  The fix for this sort of
thing is to switch to Kermit 95.  Then if you have problems we can help
you with them.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Path: cs.utk.edu!stc06.ctd.ornl.gov!fnnews.fnal.gov!uwm.edu!cs.utexas.edu!howland.reston.ans.net!vixen.cso.uiuc.edu!newsfeed.internetmci.com!panix!news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: kermit for AS/400 (was Re: Multi-platform File Transfer)
Date: 25 Apr 1996 13:29:23 GMT
Organization: Columbia University
Lines: 75
Message-ID: <4lnunj$68@apakabar.cc.columbia.edu>
References: <31727860.2781@tkg.com> <Dq0J1x.ByB@cyberdex.cuug.ab.ca> <4l43sd$550@apakabar.cc.columbia.edu> <960424.001900.1g0.rnr.w164w_-_@locutus.ofB.ORG>
NNTP-Posting-Host: watsun.cc.columbia.edu

In article <960424.001900.1g0.rnr.w164w_-_@locutus.ofB.ORG>,
Russell Schulz <Russell_Schulz@locutus.ofB.ORG> wrote:
: jaltman@watsun.cc.columbia.edu (Jeffrey Altman) writes:
: > : 
: > : Naw, check out Kermit...
: >
: > I would love to recommend Kermit, but we don't have Kermit for AS/400.
: > Many times people ask us if they can port Kermit to OS/400.  And then
: > we never hear from them again.
: > So it can't be too easy.
: 
: how much pain is it to write a simple kermit, if you force everything
: even slightly suspicious to be escaped?
: -- 
:
Be my guest :-)

Among the problems to be considered are:

 1. Terminal i/o for the AS/400 is unlike anything else on earth.
    Synchronous, half-duplex, block-mode, twinaxial cable 5250 and
    associated controllers.

 2. The file system is based on EBCDIC rather than ASCII.

Granted, these problems are solvable (soluble?) since, indeed, we solved
similar problems at the very beginning when designing the Kermit protocol
to be "IBM-mainframe friendly".  See pages 108-113 of "Kermit, A File
Transfer Protocol".  First, you need a way to defeat the 5250ness of the
terminal (or Telnet) connection by putting it into "transparent mode".
Does anybody know how to do that?  Note that there is probably not just
one way to do this, but "n" different ways, where "n" is the number of
different 5250 control units and/or protocol converters on the market,
both from IBM and from third parties.

Of course, we might still be able to get through a controller even when it
is not transparent using the infamous "Doomsday Kermit" extensions introduced
a few years and described in Kermit News #5, June 1993, but "DDK" transfers
are necessarily quite slow.  (Kermit News #5 is available on the Web as
http://www.columbia.edu/kermit/newsn5.html.)

In any case, I would not be surprised if the APIs to the i/o subsystem are
hideously complex and obscure -- nothing like "read a character, write a
character" that most of us are accustomed to -- more like fill in seventeen
control blocks with mysterious control words, write a channel program in
assembly language and load it into the controller, start an asynchronous i/o
operation, and then wait for some interrupt to happen.  Just a guess.  Of
course, if you are an AS/400 programmer, this is your bread and butter.

Second, there are numerous problems stemming from the EBCDIC file-system
orientation, beginning with the program source code itself (e.g. if you
were to try to port C-Kermit), which more or less assumes the ASCII
collating sequence, to communications i/o (in which, for example, packet
checksums or CRCs are based upon the ASCII values of the characters in the
packet), not to mention the fact that any communications to the "outside"
(i.e. non-5250) world is going to be translating everything between EBCDIC
and ASCII...  So think about it -- textual is read from the disk in EBCDIC,
translated to ASCII so the checksum can be formed, the packet is then
translated from ASCII back to EBCDIC so that the communications subsystem
can translate back to ASCII (again)...

Third...  Do you also want it to be able to initiate connections?  Dial
out or Telnet?  How would you dial out?  Where is the modem?  And consider
how you, sitting at a block-mode 5250 terminal, would have an interactive
terminal session with, say, UNIX or a BBS.

The list goes on.

It's not impossible, but it appears to be hard enough that nobody has yet
been able to do it -- and this goes back to the System 34/36/38 days more
than a decade ago, a time when we had more than a small handful of
volunteer programmers eager to crank out new Kermit implementations.

Go ahead, make my day :-)

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 5161 of comp.protocols.kermit.misc:
Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!news.msfc.nasa.gov!newsfeed.internetmci.com!swrinde!tank.news.pipex.net!pipex!usenet2.news.uk.psi.net!uknet!uknet!bcc.ac.uk!ts-b.bcc.ac.uk!skaamjm
From: skaamjm@ucl.ac.uk (Matthew Moore)
Subject: Re: kermit & MS TCP/IP-32, v3.11b
Message-ID: <1996May22.151734.105314@ucl.ac.uk>
Date: Wed, 22 May 1996 15:17:34 GMT
References: <4nkv5u$e7a@ralph.vnet.net>
Organization: University College London
Keywords: kermit TCP/IP-32
Lines: 79

I add to degraaf's post the information that Kermit (3.13 and 3.14)
will run alomgside the Microsoft stack under Windows 95.
(I say alongside because the second IP address is needed).

NDIS3PKT installation under WIN95 is simpler : in the
network control panel you choose ADD protocol,
and specify location of NDS3PKT under
'HAVE DISK' - WIN95 does the rest.

Matthew Moore

degraaf@lys.vnet.net (degraaf) writes:

>Kermit _can_ be run over MicroSoft's new TCP/IP-32 ver 3.11b stack,
>but there's a trick.

>Short story:

>You must add NDIS3PKT.386 and you must use two different IP addresses,
>one for the MS stack, the other for kermit.

>Long story:

>I have a samba UNIX server and wanted to use the new MS TCP/IP-32
>ver3.11b stack for WindowsforWorkgroups 3.11 and also use kermit
>to log on directly to UNIX from a client PC.  I collected from
>ftp.microsoft.com/bussys/clients/wfw the files TCP32B.EXE and
>WFWFILES.EXE, as well as instruction files, INDEX.TXT, UPDATE.TXT, and
>WFWFILES.TXT.  The .EXE files expand into floppy-loads that are used to
>install this new stack into WfW 3.11 and some new files that are
>manually copied according to the complete instructions given.

>This new stack uses NDIS ver 3 to access the Ethernet card, while
>kermit uses a packet driver.  Previously, DIS_PKT9.DOS was interposed 
>between kermit's packet driver and the NDIS module, and WINPKT.COM
>was used to mediate between Windows and the packet driver.
>This was clearly documented by Joe Doupnik in DIS_PKT.DOC in the
>Kermit for DOS package.  Unfortunately these NDIS 2 programs don't work
>any more with the new NDIS 3 stack.

>Instead, one uses NDIS3PKT.386, written by Daniel D. Lanciani.
>It is a Windows VxD (Virtual Device) which provides a packet driver
>interface on top of NDIS 3.  I collected ver 1.2 from
>pc.usl.edu/pub/packet_drivers -  ndis3pkt.386 and ndis3pkt.readme.
>Installation is very simple:

>Copy NDIS3PKT.386 file to the system directory, eg C:\WFW\SYSTEM.
>In system.ini, add to [386Enh]
>	device=ndis3pkt.386
>and add a new section
>	[ndis3pkt]
>	netcard0=MS$NE1CLONE

>where MS$NE1CLONE happens to be the driver name for my network card.
>Yours may well be different.  (It's usually found in the BINDINGS= line
>of the [NETBEUI] section of protocol.ini)

>Now comes the trick.  You have, during network initialization,
>specified an IP address for the PC.  This is used by the MS stack in
>its communications with other machines on the network.
>You must also give kermit an IP address, usually in MSCUSTOM.INI, eg,
>	 SET TCP/IP ADDRESS 192.9.100.23   ;(NOT 192.9.100.22)
>Be SURE this is different from the address given to TCP/IP!

>When I initially used a single IP address for both, kermit's attempt 
>to open a connection to the UNIX server failed with the  message
>"Connection refused by host".  With a different IP address
>for kermit, connections succeed.

>Apparently, when packets arrive for both NDIS and the packet driver
>using the same IP address, bad things happen in the new MS stack. 
>Since NDIS3PKT.386 includes a multiplexor, the same "extra" IP address
>can be used by several packet driver programs, such as kermit. 
>But you must now use up two addresses for each PC. 
>Thanks, MicroSoft.

>--
>	David A. De Graaf	degraaf@vnet.net
>	DATIX, Inc.		(803) 785-3136

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.os.linux.misc,comp.protocols.kermit.misc
Path: cs.utk.edu!news.msfc.nasa.gov!newsfeed.internetmci.com!panix!news.columbia.edu!watsun.cc.columbia.edu!fdc
Organization: Columbia University
Message-ID: <4nq1um$g5p@apakabar.cc.columbia.edu>
References: <4lqr4e$55g@netnews.upenn.edu> <4no92v$17l@Mercury.mcs.com> <4noddj$aol@apakabar.cc.columbia.edu> <Drou7D.Cvr@telly.telly.org>
NNTP-Posting-Host: watsun.cc.columbia.edu
Lines: 24
Date: 20 May 1996 15:09:10 GMT
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Subject: Re: Kermit licensing (was: Caldera's WordPerfect)

In article <Drou7D.Cvr@telly.telly.org>,
Evan Leibovitch <evan@telly.telly.org> wrote:
: 
: This is a load of crap. I still have a copy of the letter I wrote to
: *you* November 4 1994, asking about the feasability of my company
: producing a CD-ROM that would contain every port of Kermit in existence.
: The letter was clear in its intent to pay Columbia for every CD-ROM sold.
: ...
: I also have a copy of your reply, Frank. You took three months to
: answer me, dismissing the idea and blowing it off.


Thanks for the reminder, Evan.  I looked it up, and sure enough we had
some correspondence about this.  If you want to classify as "blowing it off"
the fact that we were working 80-100 hours per week on getting the MS-DOS
Kermit 3.14 and C-Kermit 5A(190) releases out and therefore did not have
time to address the issue at the moment -- which is what I told you in my
response -- then I guess I blew it off.

The problem with your request was that it was not routine; you were
basically asking us (as you are now) to change our business model.  If we
had the luxury of trying a new business model, failing, trying another one,
again and again, and had no other demands on our time, this might be fun.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!news.msfc.nasa.gov!newsfeed.internetmci.com!news.wolsi.com!news.aros.net!news.cs.utah.edu!cc.usu.edu!jrd
Message-ID: <1996May23.172812.80806@cc.usu.edu>
References: <jodellDrrE5s.6o0@netcom.com>
Organization: Utah State University
Lines: 9
Date: 23 May 1996 17:28:12 MDT
From: jrd@cc.usu.edu (Joe Doupnik)
Subject: Re: MS-Kermit / multi-port cards (?)_

In article <jodellDrrE5s.6o0@netcom.com>, jodell@netcom.com (Jake Odell) writes:
> Any body figured out how to use ms-kermit with a multi-port dumb card
> like Digi, WCSC, etc? How do you tell Kermit to chech the vector port
> to see which UART is generating the interrupt?
---------

You don't because there is no support for vendor-specific serial
ports in MSK. I have none of these boards, nor the public information to
go with them.

	Joe D.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-


Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!news.msfc.nasa.gov!news.ingr.com!imci4!newsfeed.internetmci.com!EU.net!usenet1.news.uk.psi.net!uknet!psinntp!psinntp!psinntp!news.columbia.edu!watsun.cc.columbia.edu!fdc
Organization: Columbia University
Lines: 9
Message-ID: <4o26il$p1p@apakabar.cc.columbia.edu>
References: <jodellDrrE5s.6o0@netcom.com>
NNTP-Posting-Host: watsun.cc.columbia.edu
Date: 23 May 1996 17:17:09 GMT
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Subject: Re: MS-Kermit / multi-port cards (?)_

In article <jodellDrrE5s.6o0@netcom.com>, Jake Odell <jodell@netcom.com> wrote:
:
: Any body figured out how to use ms-kermit with a multi-port dumb card
: like Digi, WCSC, etc? How do you tell Kermit to chech the vector port
: to see which UART is generating the interrupt?


Most such cards come with a "Fossil driver".  Install the fossil driver,
then tell Kermit (version 3.14 is needed) to "set port fossil <number>".

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!news.msfc.nasa.gov!newsfeed.internetmci.com!in2.uu.net!news.mathworks.com!tank.news.pipex.net!pipex!usenet1.news.uk.psi.net!uknet!psinntp!psinntp!psinntp!news.columbia.edu!watsun.cc.columbia.edu!fdc
Organization: Columbia University
Lines: 44
Message-ID: <4o2pii$2su@apakabar.cc.columbia.edu>
References: <4o2gds$1aou@cass.ma02.bull.com>
NNTP-Posting-Host: watsun.cc.columbia.edu
Date: 23 May 1996 22:41:22 GMT
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Subject: Re: Caps lock makes !@#$% instead of 12345

In article <4o2gds$1aou@cass.ma02.bull.com>,
Lin Sprague <lsprague@cass.ma02.bull.com> wrote:
: 
: I'm using Kermit 95 on both Windows NT and Win95 and I've noticed that the
: top row number keys produce the punctuation characters rather than numerals
: when the Caps Lock key is down, just like if you were holding the <Shift>
: key. Is this by design? Is there any way to make it not do this?


Kind of makes you want to say "!@#$%"  :-)

(But are you sure it's also happening in Windows NT?)

From the Kermit 95 BUGS.DOC file:

6. Keyboard Scan Codes and Caps Lock (M)

Certain keyboard scan codes, constructed by Kermit 95 from information
reported by Windows, are inconsistent between Windows NT and Windows 95.
These include Num Lock and Numeric Keypad /.

More seriously, Windows 95 (not NT) returns the shifted version of
non-alphabetic characters when Caps Lock is on; for example, if you press the
"2" key on a USA keyboard with Caps Lock on, you get "@" instead of "2".  In
other words, Caps Lock behaves like Shift Lock.  This is a Windows 95 bug.  The
same K95 code executing under Windows NT returns the correct values.

Workaround: None, except to avoid using Caps Lock.  There is nothing Kermit
can do about this.  If Windows gives it the wrong scan code, Kermit can't
guess what the right one would have been -- especially when you consider the
multiplicity of national and other keyboards.

Cure: If the next Microsoft update or release fixes the Caps Lock bug, it will
be fixed in Kermit.  When the full-GUI, non-console-mode version of Kermit 95
comes out, that, too, will cure this problem by not using the console driver.

(end quote)

There is a kind of workaround for this, however.  You can find it at:

  ftp://kermit.columbia.edu/kermit/k95/caps.ksc

It's a key mapping file to "do the right thing" -- but only on a US keyboard.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Path: cs.utk.edu!news.msfc.nasa.gov!newsfeed.internetmci.com!EU.net!usenet1.news.uk.psi.net!uknet!dispatch.news.demon.net!demon!netcom.net.uk!netcom.com!kientzle
Message-ID: <kientzleDrx4yE.2IA@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
References: <4o08gj$d5u@ns2.ryerson.ca> <31a47d81.389121497@128.230.1.4> <TOM.96May23115142@amber.ssd.csd.harris.com>
Date: Fri, 24 May 1996 16:39:50 GMT
From: kientzle@netcom.com
Subject: Re: Best efficiency ?

In article <TOM.96May23115142@amber.ssd.csd.harris.com>,
Tom Horsley <Tom.Horsley@mail.hcsc.com> wrote:
>
>When I issue all the commands from the FAQ to give me a fast, clean, max
>throughput kind of connection and start the download it just screams for the
>first few kilobytes, then ...

It may or may not have anything to do with flow control per se.
If your serial driver is dropping data (possibly due to flow control
problems, possibly due to buggy drivers or scrambled hardware
interrupts) then long windows and/or long packets are deadly.

If you're using a long window, long packets, and there's data loss,
you'll see exactly the sort of behavior you describe: the sender will
send a bunch of long packets (furiously blinking modem), but only one
or two will be successfully received.  The receiver waits (no modem
lights), eventually times out and re-requests a packet (modem blinks
once), etc, etc.  Try selecting a small packet size and small window
and gradually increasing them.  I suspect you'll find a point beyond
which throughput degrades rapidly.  On one local connection, I found
that I had to limit the (window size times packet size) to less than
1500.  Beyond that, throughput dropped to nothing.  After upgrading
the serial drivers, suddenly large windows worked better.

If you're interested in the technical details of what's going on, you
might be interested in the article I wrote for Dr. Dobb's back in
February, which describes some techniques Kermit implementations can
use to deal with this type of problem.

                                - Tim Kientzle

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-


Article 5207 of comp.protocols.kermit.misc:
Path: cs.utk.edu!news.msfc.nasa.gov!elroy.jpl.nasa.gov!swrinde!newsfeed.internetmci.com!news.wolsi.com!news.aros.net!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: befuddled by MSKermit TCP/IP!!
Message-ID: <1996May28.093238.80968@cc.usu.edu>
Date: 28 May 96 09:32:38 MDT
References: <DrMp8y.H3p@gorilla.nbn.com> <1996May22.152843.27781@ucl.ac.uk> <Drw5tn.5yB@gorilla.nbn.com>
Organization: Utah State University
Lines: 103

In article <Drw5tn.5yB@gorilla.nbn.com>, holmes@gorilla.nbn.com (Tim Holmes) writes:
> Joe Doupnik (jrd@cc.usu.edu) wrote:
> : In article <1996May22.152843.27781@ucl.ac.uk>, skaamjm@ucl.ac.uk (Matthew Moore) writes:
> : > holmes@gorilla.nbn.com (Tim Holmes) writes:
> : > 
> : >>I have been trying to get MSKermit (the latest version just off
> : >>the ftp lines) to do a TCP/IP connection to a Linux box.  Not having
> : >>any luck.
> : > 
> : >>There are two machines, Linux is 150.0.0.1, DOS is 150.0.0.2.
> : >>The DOS box is running lanwp from a dvx setup.  If I exit dvx, I can
> : >>ping the Linux box ok.  I tried the following setup:
> : > 
> : >>set port tcp
> : >>set tcp pack odi
> : >>set tcp add 150.0.0.2
> : >>set tcp sub 255.255.255.0  
> : >>set port tcp 150.0.0.1
> : >>connect
> : > 
> : >>I get "cannot access IP packets".
> : > 
> : >>So I tried doing a packet driver (ne2000).  It seemed to initialize OK,
> : >>then when I do:
> : > 
> : >>set por tcp
> : >>set tcp add 150.0.0.2
> : >>set tcp sub 255.255.255.0
> : >>set port tcp 150.0.0.1
> : >>connect
> : > 
> : >>I get cannot ARP resolve 150.0.0.1.
> : > 
> : >>What am I doing wrong?
> : > 
> : >>Thanks,
> : > 
> : >>Tim Holmes
> : >>holmes@gorilla.nbn.com
> : > 
> : > 
> : > Neither 150.0.0.1 or 150.0.0.2 appeared to be registered in the DNS
> : > so the Addres resolution protocol is trying to look their names, and
> : > failing.
> : > 
> : > (You would need to talk to a local network administrator to get you
> : > boxes registered).
> : > 
> : > Matthew Moore
> 
> Since I'm the administrator of this two machine network (!), do I have
> to set up DNS to get kermit to work?
> : -----------
> : 	150.0.0.x is also illegal with a subnet mask of 255.255.255.0
> : because it creates a subnet field, the third octet in this Class B case,
> : of all zeros.
> :         Joe D.
> 
> What subnet mask would work?  I tried 255.255.0.0, but no go there either.
> Sorry for the dumb questions, but I'm having trouble with this one.

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

	None that you have. The rules of the game are like this. A 32 bit
IP address can be divided into three fields: a "network" portion whose
width is determined by the Class (the top three bits of the first octet),
a "subnet" portion which is taken from the third "host" portion and whose
width is determined by the subnet mask, and the remaining "host" portion.
	<network><host> -->subnetted--> <network><subnet><host>
None of the three fields may be all 1 bits nor all 0 bits.

	150.0.0.0 is a Class B address, thus the "network" part is 150.0,
and the "host" part is the last two octets (from which we will steal a
subnet portion). You stole the third octet for "subnet" and it's all 0's.

	One must not choose IP addresses out of the blue because at some
time you will be connected to the world. The RFC's make provision for
"private" IP addresses, as follows:

-----------
RFC 1597        Address Allocation for Private Internets      March 1994

3. Private Address Space

   The Internet Assigned Numbers Authority (IANA) has reserved the
   following three blocks of the IP address space for private networks:

        10.0.0.0        -   10.255.255.255
        172.16.0.0      -   172.31.255.255
        192.168.0.0     -   192.168.255.255

   We will refer to the first block as "24-bit block", the second as
   "20-bit block, and to the third as "16-bit" block.  Note that the
   first block is nothing but a single class A network number, while the
   second block is a set of 16 contiguous class B network numbers, and
   third block is a set of 255 contiguous class C network numbers.

----------
	That much said, let me add a bug report item to consider as well.
MSK 3.14 has a filter to reject packets echoed by NDIS board handlers, and
the filter resides well above the board hander code. The filter is broken,
alas, such that it rejects packets if the first three octets of the MAC
(hardware) address of source and destination are the same. Those three octets
are vendor idents on Ethernet boards. It's a bug, unpatchable, and the
workaround is try boards from different vendors. The cure is to await MSK
v3.15 which is in the works.

	Joe D.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Article 5807 of comp.protocols.kermit.misc:
Path: cs.utk.edu!news.msfc.nasa.gov!newsfeed.internetmci.com!howland.erols.net!newspump.sol.net!posts.execpc.com!usenet
From: manning@execpc.com (Steve Manning)
Newsgroups: comp.protocols.kermit.misc
Subject: K95 Wyse-50 problem
Date: Fri, 27 Sep 1996 15:11:51 GMT
Organization: Exec-PC BBS Internet - Milwaukee, WI
Lines: 36
Message-ID: <52gqrt$23m@newsops.execpc.com>
References: <51pul3$ade@newsops.execpc.com> <51rkud$iib@apakabar.cc.columbia.edu>
Reply-To: manning@execpc.com
NNTP-Posting-Host: camel.execpc.com
X-Newsreader: Forte Free Agent 1.0.82

fdc@watsun.cc.columbia.edu (Frank da Cruz) wrote:

>In article <51pul3$ade@newsops.execpc.com>,
>Steve Manning <manning@execpc.com> wrote:
>:
>: I've noticed that when I'm in a Wyse50 or 60 emulation and I ALT-X
>: back to the K95 prompt, my Enter key is non-functional.  I have to hit
>: Control-J for K95 to accept my commands.  When I change my emulation
>: to a VT100 or AT386, there is no problem.
>: 
>It's a bug.  It will be fixed in the next patch.  In the meantime, you can
>work around it with SET KEY \269 \13.

>- Frank

I also just ran into another Wyse-50 emulation problem.  The "." key
on the numeric keypad send the "DEL" character when NUMLOCK is on.
The other keypad keys all send the proper numeric characters.  Just
the "." is broken.

I used a "SET KEY" command to fix it for now.

I also seem to recall  that I had problems with the "grey" keys.  For
instance, K95 recognized a press of SHIFT-PrintScreen as
"Shift-Grey-Multiply".

We are planning on rolling out about 50 copies or so of K95 and Wyse
50 will be the initial emulation we use, since it is tested with all
our applications.  Eventually we will move to a "better" choice, but
for now it'll be WY50.

Unfortunately, I get the feeling that the Wyse 50 keyboard needs a
pretty thorough review.  I hope that this can be done and updates
included in a patch in the near future.

Steve


 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Date: 2 Apr 1997 17:23:47 GMT
From: Frank da Cruz <fdc@watsun.cc.columbia.edu>
Newsgroups: comp.terminals
Subject: Re: DOS vt220 terminal-emulator under Win95

In article <33423850.9068980@news.iaehv.nl>,
Rene Kreijveld <Rene.Kreijveld@IAEhv.nl> wrote:
:On 30 Mar 1997 23:22:05 GMT, fdc@watsun.cc.columbia.edu (Frank da Cruz) wrote:
: >Kermit 95:
: >
: >  http://www.columbia.edu/kermit/k95.html
: >
:
: Sorry Frank,\
:
: Kermit95 is a windows-based graphic terminal package.
: I am looking for a DOS text-based package.
:

No, take another look.

You said you wanted a Windows 95 Telnet client that can run in a
DOS box in text mode.  Kermit 95 does that.  (There is a separate
graphical dialer, but you don't have to use it.)

You can't run a DOS Telnet client in Windows 95 because Windows 95
Telnet clients must interface with 32-bit Winsock.

- Frank


 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.terminals
Message-ID: <5hvv5m$def$1@elle.eunet.no>
Organization: WinLink Software Integration
Date: 3 Apr 1997 10:01:26 GMT
From: Roald Ribe <Roald.Ribe@winlink.no>
Subject: Re: DOS vt220 terminal-emulator under Win95


In article <33435903.20A1@rekoab.se>
Christer Engstr=?iso-8859-1?Q?=F6m <rekoab@rekoab.se>?= wrote:

>> ...
>> ... You can't run a DOS Telnet
>> client in Windows 95 because Windows 95 Telnet clients must
>> interface with 32-bit Winsock.

> What if you are using a 16-bit WinSock stack, such as Trumpet ?

I can not quite see the attraction of using a text mode DOS terminal
emulator under Windows 95, but if you insist, it is possible to use
any terminal emulator which is based on Packet Drivers with the NDIS3PKT
converter from Dan Lanciani. It is a VxD which you install in Win 95
or in WfWG 3.11, which provides a Packet Driver interface for
multiple DOS boxes. Search on the net for ndis3pkt.386

-- 
<Roald.Ribe@winlink.no>

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.terminals, comp.arch.embedded
Date: 7 Apr 1997 19:25:41 GMT
From: Frank da Cruz <fdc@watsun.cc.columbia.edu>
Subject: Re: Q: what terminal emulations would you want supported?

In article <5i6305$h7f@baygull.rtd.com>, Don Yuniskis <dgy@rtd.com> wrote:
: In article <3349f864.73849399@news.netcomuk.co.uk>,
: Peter <z80@dserve.com> wrote:
: >>That's pure opinion.  Come sit at the Kermit help desk for a day and see
: >>how many terminal emulations are still in heavy use and heavy demand.
: >
: >How many people use Kermit? Last time I used it was about 10 years ago.
:
: Ah, well... there may be a few diehards in the UN*X camps -- though it
: offers very little more than cu(1)  :>
:
When did you last look at UNIX C-Kermit, fifteen years ago?  cu does not:

 . Transfer files
 . Include a script programming language
 . Translate character sets
 . Make Telnet or Rlogin connections


: I got tired of the 25%
: throughput penalty that kermit's file transfer imposes vs. something
: like Zmodem -- or even UUCP with a protocol spoofing modem.
:
Then you should have taken 30 seconds to look at the documentation.  Anyone
who still thinks that Kermit is slower than Zmodem, see:

  http://www.columbia.edu/kermit/perf.html

: The idea of "porting" kermit to an embedded platform is *laughable*!


Then why have so many companies done it?  Kermit is embedded in every kind
of device you can think of, ranging from calculators to fast-food restaurant
cash registers to cell-phone relay stations to fiber-optic multiplexers.

: It's far too big of a resource pig for what it would buy you.
:

And you know this... how?

Anybody who wants to know the actual information about Kermit software
and protocol is invited to visit the Kermit website:

  http://www.columbia.edu/kermit/

- Frank


 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Date: 5 Nov 1997 21:45:55 GMT
From: Frank da Cruz <fdc@watsun.cc.columbia.edu>
Subject: Re: discrepancy between k95 and C-kermit 6.0.192

In article <uen4vqeaa.fsf@davidf-nt.mks.com>,
David J. Fiander <davidf@mks.com> wrote:
: So, I've got a kermit shortcut for K95 that connects me to a host
: via telnet, and I have it configured to exit k95 when the
: connection is terminated.  Now, I connect, and then I say Alt-X
: to get back to the local kermit command mode, which works just
: fine.
: 
: On Solaris, with c-kermit, I say
: 
:       kermit -c -j <host>
: 
: It connects me, and I know that when the connection is terminated
: kermit will exit.  Much to my surprise, however, when I hit C-\
: to get back to the local kermit command mode, kermit exits.
: 
: Am I just missing something, or is this working properly?
: 

It's behaving as documented, but you're right, it's not a nice way to
behave.  But K95 does the same thing.

K95 is probably using a different command-line option:

  k95 -J <host> [ <port> ]

(capital J), which means "be like Telnet" -- you can escape back and
forth as much as you like without exiting, but then it will exit 
automatically when the connection is closed.

C-Kermit 6.0 has this feature too.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Date: 6 Nov 1997 01:23:21 GMT
From: Frank da Cruz <fdc@watsun.cc.columbia.edu>
Subject: Re: KERMIT95 - Window size in terminal emulation

In article <63qqa4$edf$1@host-3.cyberhighway.net>,
            Danny Stimpson <stimpson@bmcwest.com> wrote:
: Frank da Cruz wrote in message <63dqln$91i$1@apakabar.cc.columbia.edu>...
: > 
: > Some day the GUI version will be ready.  Please have patience until then.
:
: Frank, when do you think that might day happen?
 
My best estimate is currently "some time in 1998".  We're working hard on it,
but we're also working on hard on tech support and meeting the pressing needs
of our users for features like TAPI, Rlogin, new terminal emulations that they
can't live without, etc etc.  Expect at least one more console release before
the GUI.  Watch this space for announcements.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Date: 26 Feb 1998 17:32:35 GMT
From: Frank da Cruz <fdc@watsun.cc.columbia.edu>
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Can't change to that directory

In article <6d455p$1u0$1@samba.rahul.net>,  <dold@network.rahul.net> wrote:
: I am running  Kermit 95 1.1.15...
: On my PC, there are some scanned images in a directory
: D:\HP OfficeJet 500\images
: 
File and directory names that contain spaces are a Very Bad Idea.
Yes, they are cute for GUIs when you can click on them, but they do not
mix well with text-mode programs in which commands are a series of
fields separated by spaces, and therefore are not very useful in open
environments using open methods of remote access, as opposed to closed,
proprietary GUI methods.

: From a Unix prompt
: SunOS foxtrot 4.1.3_U1 6 sun4c
: C-Kermit 6.0.192 Release Candidate 1, 6 Sep 96, for SunOS 4.1 (BSD)
: 
: I tried 
: kermit -g 'D:/HP OfficeJet 500/images/*'
:
The shell quoting succeeds in passing the filename to C-Kermit as a
single argument, but remember the GET command (or at least the underlying
protocol) lets you request several filenames at once.  Thus the server
thinks you have given three file specifications instead of one.

Currently there is no mechanism in the Kermit protocol itself for
differentiating in a GET request packet between one filename with spaces
and multiple filenames.  This will need to be addressed.

In the meantime, you will have to do the same thing with Kermit that you
do with all other text-based software when you want to cope with filenames
like this: learn some awkward quoting rules and apply them.  In this case:


  kermit -g 'D:/HP\\{32}OfficeJet\\{32}500/images/*'

: This looks like a bug that might have been addressed in 1.1.14-> 1.1.15,
: but that doesn't seem to work for me.
: 
We do handle filnames with spaces in many other contexts, but currently not
in this one, except as shown above.

Solution 2: Use the FAT name.

: By the way, I like the new "GUI patch".  Very nice, with one problem.  As
: most windows products, warning windows pop up over the top of the message
: that you are being warned about.
: 
No comment.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Path: utkcs2!transfer.stratus.com!cam-news-feed2.bbnplanet.com
      !cam-news-hub1.bbnplanet.com!cpk-news-hub1.bbnplanet.com
      !news.bbnplanet.com!news.new-york.net!news.columbia.edu
      !watsun.cc.columbia.edu!fdc
NNTP-Posting-Host: watsun.cc.columbia.edu
Message-ID: <6d6oq6$7bt$1@apakabar.cc.columbia.edu>
References: <6d6jic$q5a$1@horus.mch.sni.de>
Organization: Columbia University
Date: Fri, 27 Feb 1998 16:15:02 GMT
From: Frank da Cruz <fdc@watsun.cc.columbia.edu>
Subject: Re: Catching errors while executing 'run console-app' commands in K95?

In article <6d6jic$q5a$1@horus.mch.sni.de>,
        Michel Dalle <Michel.Dalle@sni.be> wrote:
:
: I'm still trying to catch all kinds of errors while I'm executing scripts
: with K95. What has me stumped now is the following :
: 
: In a Kermit script, I want to launch a "console application" (something that
: runs in the DOS box of Windows 95 and NT). The console application returns a
: status of 0 if everything is OK, and it sends some messages to STDOUT. If
: the console application failes, it returns a status of 1, 2, 3, ... and
: prints a corresponding message to STDERR (this can be modified if needed).
: 
: How can I :
: 
: 1) know whether Kermit could launch the console application at all (e.g. 
:    no "Bad command or file name" message)
: 
How could you know unless you try?  I suppose you can use an IF EXIST
command to see if the program executable file exists, but of course that
does not guarantee it can be run.

: 2) know whether the console application executed correctly or not.
: 
This depends on the program's exit status code.  However, K95 has a bug in
which the return code of a program or command that you start from K95 is not
captured.  This bug is fixed in 1.1.16, to be announced shortly.

: 3) if there is an error, catch the error messages from stderr to some
:    variable in the script.
: 
I don't think there is any good way to do this.  First, Windows 95 has
bugs in this area.  When you attempt to start an application from a
different kind of application (16-bit, 32-bit, Console, GUI, etc) and
redirect the application's I/O, handles get clobbered, etc., and matters
deteriorate pretty rapidly from there -- frozen windows, dead system, etc.

Even if it worked, I don't think the Windows shell gives you a way to
redirect stderr.  So assuming the application wrote such messages to
stderr, you'd have to run some other shell that allowed stderr to be
redirected.


: 4) if there is no error, catch the stdout messages to some variable in 
:    the script.
: 
There is a mechanism for this, but whether it works depends on the
application and on Windows.  It is the \fcommand() function.  Example that
works:

  echo "\fcommand(echo hi there)"

prints "hi there".  Here's another that works as long as the file x.x is
not too long:

  assign \%n \fcommand(type x.x)

This assigns the contents of the x.x file to the variable \%n.

: From what I've seen in tests, \v(status) and \v(exitstatus) always return 0,
: and \v(pexitstat) always returns 1, independently of the success or failure
: of the console application (at least on Windows 95... ).
:
Right, that's the bug described above.  We'll have a fix for you soon.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-
Date: 2 Mar 1998 17:25:33 GMT
From: Frank da Cruz <fdc@watsun.cc.columbia.edu>
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Catching errors while executing 'run console-app' commands in K95 
?

In article <6d8vrv$br1$1@xenon.inbe.net>,
Michel Dalle <michel.dalle@village.uunet.be> wrote:
: ...
: Sorry to be pushy, but any idea when 1.1.16 is going to be available 
: exactly?  On the Kermit Website, it mentions March 1998, but is this
: tomorrow or on the 31st of March ?
:
We don't withhold information in our answers to questions.  If we had a
precise release date, we'd give it.  For any new release, there is a testing
process.  If problems are discovered in the field, then we correct or work
around them prior to the release.  We keep doing this until all known problems
are addressed because it is in nobody's best interest to release buggy
software.

: And do all these error catching problems also occur on Windows NT ?
: 
It turns out that the lack of status codes returned from external programs
invoked from K95 was the result of two bugs: one in Kermit 95 (corrected in
1.1.16) and the other in the Windows 95 command shell.  The latter bug does
not occur in the Windows NT command shell, nor in any of the known alternative
(non-Microsoft) command shells for Windows 95.  Therefore, Kermit 95 1.1.16
will obtain and report an external program's or command's exit status if the
intervening command shell reports it to Kermit 95.  If you are using Windows
95, you'll need to install an alternative command shell like Hamilton C-Shell,
4DOS, etc, that does what a command shell is supposed to do.  If you have
Windows NT, all this should work fine with any shell.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Message-ID: <34FD8085.76743518@aik.tec.sc.us>
References: <34FCA9D4.B2C2621F@aik.tec.sc.us>
Organization: Aiken Technical College
Date: Wed, 04 Mar 1998 11:25:41 -0500
From: Ray Timmons <lists@aik.tec.sc.us>
Subject: Re: VT320 F11 and F12?

Ray Timmons wrote:
> 
> With Kermit-95 1.1.15, I use a keymap ini that does just about
> everything except work for F11 and F12.
>
> The ini file says -
>
> set key \378 \Kdecf11   ; F11
> set key \379 \Kdecf12   ; F12
>
> But doesn't work in an application that does work with a
> real VT320.  I can assign the F11 and F12 keys to other
> keys and they work fine, so I know I have the right key
> and the ini is taking.
> 
> If I start Kermit on the VAX under K95, and do -
> Show Key, it shows the correct returns for F11 and F12
> ([23~ and [24~).
> 
> But if I run the following com file under VMS/DCL -
>
> $  DEFINE/KEY/NOECHO/TERM/NOLOG F11   "write sys$output """F11""
> $  DEFINE/KEY/NOECHO/TERM/NOLOG F12   "write sys$output """F12""
> $  DEFINE/KEY/NOECHO/TERM/NOLOG F13   "write sys$output """F13""
> $  DEFINE/KEY/NOECHO/TERM/NOLOG F14   "write sys$output """F14""
> $  DEFINE/KEY/NOECHO/TERM/NOLOG HELP   "write sys$output """F15-Help""
> $  DEFINE/KEY/NOECHO/TERM/NOLOG DO   "write sys$output """F16-DO""
> $  DEFINE/KEY/NOECHO/TERM/NOLOG F17   "write sys$output """F17""
>
> When I press the correct keys, only F15-F19 display an output.
> I am running VMS 6.2.
> 
> Anybody have any idea how to get F11 and F12 working as such?
> 
> Ray T.

Followup.  Thought I would test the com file above on a VT320, and
guess what.  Only keys F16-F20 display.  So the com file can't be used
to test to see if F11 and F12 are working.

But the question still remains.  How do you get F11 and F12 to work in
K95 just like it does on a real VT320?

Ray T.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Message-ID: <6h15ha$2c2$1@apakabar.cc.columbia.edu>
References: <6ggtct$7me$1@news.ncal.verio.com> 
     <6giigg$9ot$1@apakabar.cc.columbia.edu> <6h0ul6$m1s$1@news.ncal.verio.com>
Date: 15 Apr 1998 02:20:26 GMT
From: Jeffrey Altman <jaltman@watsun.cc.columbia.edu>
Subject: Re: timeout on k95

In article <6h0ul6$m1s$1@news.ncal.verio.com>, den <dirvine@psln.com> wrote:
:
: I am sorry Frank, but it is not the system logging me out.  I can use a
: different terminal emulation program and it can set there all day without
: being logged out.  Only K95 cuts off.
: 

Dennis:

I examined the debug.log that you sent me and as I pointed out to you
the TCP/IP stack is reporting ECONNRESET errors.

This is a fatal socket error which means that your TCP/IP stack has
received a packet or other data that it was not expecting.  This
usually means that MORE than one machine on your network is using the
same IP address.

A ECONNRESET error is fatal, and Kermit 95 treats it that way.  Kermit 95
is behaving correctly.  If another package decides to ignore this
error, then it is leaving you open to having your terminal session
hijacked or otherwise tampered with.

The proper place to look is at your network.  Do not blame Kermit 95
for this problem.

- Jeff
-- 
    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Date: 28 Apr 98 11:37:19 MDT
From: Joe Doupnik <jrd@cc.usu.edu>
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Direct Serial Connect MS DOS Kermit
 
In article <6i4r3p$c82$1@nnrp1.dejanews.com>, spellican@hotmail.com writes:
> I have an old 8088 (DOS only) and a pentium (Win95) sitting next to each
> other, and would like to transfer files via serial port (RS-232). I have
> MS-DOS Kermit 3.15. It is it capable of doing this, and if so how?
> 
> Thanks in advance!
> Steve Pellican
> spellican@hotmail.com
----------

        Connect them with an RS-232 reversing cable. If you need assistance
using Kermits please read their installation and operation material. Be aware
that you can let Win95 own a serial port and in that case MS-DOS Kermit
will be unable to gain control; reconfigure Win95 to get its applications
off that serial port or run Kermit without starting the GUI.

Joe D.


 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Date: 2 May 1998 13:47:46 -0400
From: Frank da Cruz <fdc@watsun.cc.columbia.edu>
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Help With File Download
 
In article <6iffut$8v7@bgtnsc01.worldnet.att.net>,
Bernie  <bfb@worldnet.att.net> wrote:
: I'm using Kermit 6 to login to a remote PC and download
: two .zip files using the kermit protocol.  It works OK for the first
: file, but then seems to hang when attempting to get the
: second.
: 
: Here is an excerpt of the script:
: 
: input 5 Your choice?
: output k                            #Select k for kermit protocol
: input 5 File name?
: output file1.zip\13
:
So evidently the PC has some kind of menu and your Kermit script is
pretending to interact with it, as you would do when your are typing
in CONNECT mode.  So far so good...
 
: server
: get file1.zip
: get file2.zip
: bye
: 
Here is where you go wrong.  You are putting C-Kermit (I assume that
is what you mean by "Kermit 6" in server mode.  But the remote PC is
still at its menu.  So how will they communicate?  Furthermore, the two
"get" commands will never be executed, since C-Kermit will remain in
server mode until commanded by the client to leave it, but there is no
client.
 
What to do:
 
 1. Obtain a copy of the manual:
      http://www.columbia.edu/kermit/ck60manual.html
 
    and read the chapters on script programming.
 
 2. Change your script as follows:
 
      input 5 Your choice?
      if fail stop 1 No protocol prompt
      output k
      input 5 File name?
      if fail stop 1 No Filename prompt
      output file1.zip\13
      receive
      if fail stop 1 Download of file1.zip failed
 
    I don't know what the remote PC does after a transfer.  Does it give
    another "File name?" prompt?  Assuming it does, the next part is:
 
      input 5 File name?
      if fail stop 1 No Filename prompt
 
      output file2.zip\13
      receive
      if fail stop 1 Download of file2.zip failed
 
Now have your script do whatever it must do to log out, close the connection,
or whatever else you want it to do.
 
- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Date: 3 May 1998 16:10:41 GMT
From: Frank da Cruz <fdc@watsun.cc.columbia.edu>
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Ftp Script Problem
 
In article <6igrtg$ggq@bgtnsc01.worldnet.att.net>,
Bernie  <bfb@worldnet.att.net> wrote:
: I'm attempting to write a script which will ftp to my
: localhost (for testing purposes) and put a file.
: In the script below, when the line is reached
: 
You can't use Kermit scripts to do ftp transfers.  FTP is 
not a built-in protocol in C-Kermit.  Although it has an "ftp"
command, all this does is run the external ftp program.
Integrating FTP into Kermit has been on our list for some
time, but our list is long and the amount of volunteer help
isn't what it used to be.
 
A feature that might allow ftp transfers to be scripted
(without actually building ftp protocol into C-Kermit) will
be added in C-Kermit 6.1.  Watch this space for announcements.
 
- Frank


 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Date: 3 May 1998 18:10:25 GMT
From: Frank da Cruz <fdc@watsun.cc.columbia.edu>
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Environment Variable Question
 
In article <6ii9gt$61j@bgtnsc03.worldnet.att.net>,
Bernie  <bfb@worldnet.att.net> wrote:
: Is it possible to set korn shell environment variables
: from within a c-kermit command file?
: 
: For example:
: 
: define \%a FILE1
: define \%b FILE2
: 
: #run F2=\%b; export F2
: run /bin/echo F2=\%b; export F2
: #run set F2=\%b
: 
Yes, it is possible to set them, but only in the inferior
shell that you have started by the RUN command.  As soon as
it exits, they disappear.  A program can not affect its
superiors in the process tree.  The shell "set" and "export" 
comands only affect the current process and/or its children.
UNIX rules.  Contrast with, say, VMS logical names.
 
- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-


Newsgroups: 
comp.protocols.kermit.misc,comp.protocols.misc,comp.protocols.tcp-ip,comp.softwa
re,comp.terminals,de.comm.protocols.misc,de.comm.protocols.tcp-ip,de.comm.softwa
re.misc,news.software,news.software.misc
Organization: CompuData, Inc.
Message-ID: <01bdc9de$fa2085c0$6ac9a126@perryw.compu.com>
NNTP-Posting-Host: 38.161.201.106
NNTP-Posting-Date: Mon, 17 Aug 1998 09:00:44 EDT
Date: Mon, 17 Aug 1998 13:00:44 GMT
From: "Nashmark" <perry@compu.com>
Subject: An open letter of praise for KERMIT 95 SUPPORT


Firstly, KERMIT95 is the best terminal emulation software for Windows you
will ever find! This note is not about that, however. It is about the
SUPPORT for the software, which, if you didn't know, is the MOST IMPORTANT
PART!

If you have never dealt with the people at Kermit support, take note.
KERMIT is supported by the people who wrote it!!! And they are the
greatest! 

If you EVER have a problem with KERMIT 95, just contact them. They will
solve the problem -- QUICKLY! I think it actually bothers them when there
is a problem to the point where they won't sleep until it's resolved! I'm
not lying!

Through the last year, when we were introduced to KERMIT, I have had a
variety of problems. I have been dealing with ancient systems with very old
terminal emulations (such as Hazeltine 1500). 

These guys have taken every problem, and solved it. This sometimes had to
be done by them writing a 'patch' -- within hours of me submitting the
problem! Try that with James River Corp, Quarterdeck (PCPLUS) or Microsoft
support. You MIGHT get a RESPONSE in a couple of days. But usually, they
will never admit a bug in their software, and you will NOT get the problem
resolved!

I recommend KERMIT95 for anyone who has a need for terminal emulation
through modems, telnet sessions, or even LAT connections. KERMIT95 beats
out the competition. Note the following:

1. KERMIT95 - price is <$100 !
2. KERMIT95 - MORE TERMINAL EMULATIONS THAN ANY OTHER CHOICE. THEY ALL WORK!!!
3. KERMIT95 - More communication protocols. All work FAST!
4. ICETCP (James River) - VERY LIMITED, Horrible support. 
5. PCPLUS 4.0 - Way overblown, too expensive (If I am buying emulation
   software, why do they include IE?)


And to Frank da Cruz and Jeffery Altman - THANK YOU!!!

-NASHMARK a/k/a PERRY WOLFE, COMPUDATA INC.

P.S. If you want to ask me anything about KERMIT, e-mail me. But don't be
afraid to contact them. Like I said, they are the greatest! And I do not
work for them.

http://www.columbia.edu/kermit/k95.html


 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Message-ID: <mMWSMjad0l7S@cc.usu.edu>
References: <70l9n2$hd1$1@team2.teamnet.net>
Date: 21 Oct 98 17:06:50 MDT
Organization: Utah State University
From: jrd@cc.usu.edu (Joe Doupnik)
Subject: Re: TCP/IP? (in DOS)


In article <70l9n2$hd1$1@team2.teamnet.net>, "draft2" <nobody@cfu.net> writes:
> Is it possible to do TCP/IP through DOS?
> I have an 80386 with 2M RAM and a 10baseT betwork adapter. I do not run
> windows. Our internet provider (whom I happen to work for) provides a
> 500kbps connection via cable modems. Now, as far as it is set up, it is like
> a regular network set up all over the city. We convert the signals to analog
> and send it over the cables, just like cable TV, the nthe cable modem sends
> it back to digital to the network card. Each computer must access a DHCP
> server unless given a static IP address. My question is, will kermit
> facilitate this type of connection and if so, can someone give me some
> intstruction.
-----------

        What might you mean by "facilitate"? If the answer is do something
particular about cable modems the answer is no. MS-DOS Kermit is the program
you are inferring, and it uses its internal TCP/IP stack to talk over SLIP,
some PPP, and ODI lan drivers. Once that is done the medium is responsible
for behaving as advertised (if Ethernet then it must behave as true Ethernet
to attached equipment). MSK supports RARP, BOOTP, DHCP remote address
acquisition. How one chooses to represent bits on wires off site is not
of interest here.

        Instructions on this are in the release documentation and the main
user's manual the book "Using MS-DOS Kermit". Please visit www.columbia.edu/
kermit for pointers to the material.

        Being an MS-DOS program, MS-DOS Kermit runs in 640K memory space,
and will use extended or expanded memory if available.
        Joe D.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Message-ID: <70nv1o$52p$1@apakabar.cc.columbia.edu>
References: <Pine.WNT.4.05.9810220906420.169-100000@neko.dental.washington.edu>
Date: 22 Oct 1998 18:54:48 GMT
From: Jeffrey Altman <jaltman@watsun.cc.columbia.edu>
Subject: Re: Stop automatic resetting of terminal emulation?

In article <Pine.WNT.4.05.9810220906420.169-100000@neko.dental.washington.edu>,
Andrew J Pardoe  <ap@u.washington.edu> wrote:
:
: We use K/2 and K-95 heavily to telnet to different applications throughout
: our hospital. We've run into a problem twice where the remote host will
: reset the terminal emulation of the local K-95 just after the remote login
: sequence is completed.
:
: It's not a problem when the VT host changes the emulation from VT320 to
: VT220 but we've run into a conundrum when an SCOANSI host changes the
: emulation from SCOANSI (which works perfectly) to ANSI (which doesn't.)
:
: Two possible solutions present themselves: first, get the host to stop
: sending a request to change terminal emulation; second, set Kermit to
: ignore any requests to change the terminal emulation. Knowing the kind of
: support one receives from Kermit, I decided to start here.
:
: Any suggestions would be appreciated. I couldn't find this addressed in
: the manual(s) or Dejanews so I'm stuck.
:

From BUGS.TXT and the BUGS page in the HTML Manual:

253. HINT: Using SCOANSI emulation with SCO hosts

There is a type of terminal emulation commonly called ANSI, which is
used by BBS's.  It is very simple -- essentially nothing more than
what you get with ANSI.SYS on a PC.  Then there is the highly evolved
and complex version of it used on the SCO (and Linux) console.  Kermit
95 supports both; the first emulation is called ANSI; the second is
called SCOANSI.  However, the *name* SCOANSI is unknown on SCO
systems.  They call it just ANSI.  So if a Telnet client such as
Kermit 95 comes in announcing its terminal type as SCOANSI, the SCO
host doesn't recognize it.  In Kermit 95 1.1.8 and later, the Telnet
terminal-type negotiation feature will cause Kermit 95 to change to
another terminal type, most likely "plain old" ANSI.  To work around
this problem in Kermit 95:

  set terminal type scoansi
  set telnet terminal-type ansi
  set terminal character-set transparent

Or on the SCO system:

  Copy the /usr/lib/terminfo/terminfo.src entry for ansi to an
  scoansi.src file, changing "ansi" to "scoansi" in that file, and then
  run tic on it.  In /etc/termcap, add "scoansi" as an alternate name in
  the "ansi" entry.

SCO will add "scoansi" as an official terminal type (or, more
precisely, a preinstalled synonym for what it now calls "ansi") in its
next OpenServer release.  (However, as of OSR5.0.4, they have not yet
done so).

-- 
    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Date: 22 Oct 98 15:33:43 MDT
Message-ID: <zr359kB7TU8S@cc.usu.edu>
References: <Pine.WNT.4.05.9810220906420.169-100000@neko.dental.washington.edu>
Organization: Utah State University
Date: 22 Oct 98 15:33:43 MDT
From: Joe Doupnik <jrd@cc.usu.edu>
Subject: Re: Stop automatic resetting of terminal emulation?

In article <Pine.WNT.4.05.9810220906420.169-100000@neko.dental.washington.edu>,
Andrew J Pardoe <ap@u.washington.edu> writes:
> We use K/2 and K-95 heavily to telnet to different applications throughout
> ...

Andrew,

        Curious that you should bring up the topic because we had gone
over it recently in the project. Let me indicate the two views on the matter.

        First is the IETF view. It says when the remote host asks repeatedly
for a terminal type the client is supposed to offer new kinds in each
response, as a negotiation process. Thus if a remote host does not understand
or accept one kind it asks again and the two sides run down their lists.
Spelling counts for everything here, and no two machines seem to agree
on spelling of terminal names. The RFCs do this haggle stuff.

        The second is my view, which is the negotiation is stupid in the
extreme. When the client responds with a terminal type that's it, there
isn't more to the game. The remote host accepts or copes or rejects.

	The reason haggling is so stupid is there is a great deal more
concerning terminal emulation than just the name/kind, and changing
the name/kind upsets all other items associated with the session.
Keyboard definitions, expectations by software at either end,
and so on are most often tailored for specific terminal kinds, and
here the IETF says it's fine to negotiate away that information
without a word to the user. Amazing.

        The fix, if we may use that term, is to force the terminal name
in the SET TCP TERM command so only one kind is permitted to be offered,

period.
        Joe D.

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Message-ID: <70ofhk$e9d$1@apakabar.cc.columbia.edu>
Date: 22 Oct 1998 23:36:20 GMT
From: Jeffrey Altman <jaltman@watsun.cc.columbia.edu>
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Stop automatic resetting of terminal emulation?

Joe:

This case is not the same as the one that you and I talked about privately.
In your case, the terminal type name "VT320" is not recognized by the host,
a VMS system, but after the login occurs a terminal type query is sent
by the host which then recognizes the terminal type as a VT320.  This lack
of host recognition of the Telnet Terminal Type negotiation is indeed
caused by a failure of the host to have the same name for the terminal
as the emulator, but because it has an alternate identification method
things still work.

Now lets take the case above.  Kermit reports the terminal type name
as "SCOANSI" to the host, an SCO OpenServer Unix system.  "SCOANSI" is
not recognized as a valid name in the termcap and terminfo databases
an so rejects it and asks for another name.  If Kermit does not respond
with a new name and instead continues sending "SCOANSI" the result is
that the TERM environment variable is set to "SCOANSI" and all of the
applications which are dependent on termcap and terminfo entries fail
with something like:


  $ emacs
  emacs: Terminal type scoansi is not defined.
  If that is not the actual type of terminal you have,
  use the Bourne shell command `TERM=... export TERM' (C-shell:
  `setenv TERM ...') to specify the correct type.  It may be necessary
  to do `unset TERMCAP' (C-shell: `unsetenv TERMCAP') as well.
  $

This happens because unlike VMS, Unix does not attempt to perform
a VT terminal id query after the login procedure succeeds when the
terminal type in unknown.

SCO has corrected this problem is their current releases by adding
"scoansi" as an alias for "ansi" in the terminfo database.  (They
still forgot to put one there in the termcap database.)

Kermit's attempt to negotiate a terminal type that SCO recognizes is the
best method to ensure that the applications started by the user will
in fact work.  Even if it means that they won't be running in the
optimal environment.

The problem with the name "ANSI" as used by SCO is that there is no
such thing as an ANSI terminal.  The ANSI X3.64-1979 standard (since
withdrawn and replaced by ISO 6429) is just a framework upon which
manufacturers could define their terminal command sets.  It did not
specify a list of required functions, nor keyboard commands, nor
prevent multiple but incompatible implementations of the same function.
The result are implementations based on X3.64-1979 which are rather
non-interoperable.  SCO should never have called its console terminal
"ANSI", just as IBM should never have called its console driver
"ANSI.SYS" which was then superceded by "NANSI.SYS"....

Since the SCO console is not the same as ANSI.SYS and not the same
as BeOS console or Linux console or Unixware console or QNX ANSI
console it should not be called "ANSI".  Hence, the name "SCOANSI"
in Kermit in order to distiguish it from the previous "ANSI" terminal
type that Kermit supported which is based on "ANSI.SYS".
Kermit 95 1.1.18 will work around all of these problems.  Not by
removing the negotiation of terminal types as declared by the IETF
but by enhancing its support of it by including terminal type aliases.
As it turns out VMS uses the name "DEC-VT300" instead of "VT320" to
describe the VT320 terminal type.  SCO already had aliases for
"ANSI" including "ANSI-850" and "ANSI-8859".  So now when "SCOANSI" is
not recognized K95 will try the other two before switching to a
different terminal emulation.

Leaving the terminal type in a mode that is not recognized by the
host does not serve anyone's best interest.


    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Message-ID: <wegLF5YIzlTM@cc.usu.edu>
Date: 22 Oct 98 18:36:41 MDT
From: Joe Doupnik <jrd@cc.usu.edu>
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Stop automatic resetting of terminal emulation?

        It is the very same thing we talked about. Please notice that I am
not criticizing K95 et al, but I am blasting the IETF for letting things
progress has they have. You nicely made my point by showing that some apps
which expect a certain terminal type recognize things are not working and
they don't work either. That is proper. Now the user has the opportunity
to do something specific about the matter, rather than being deceived
by Telnet Options. Some apps don't know and then we are in difficulties
without realizing it.

        Life would have been simpler if there had been both adherence to
the list of terminal names and timely expansion of the same, and vendors
who read before pressing keys. But like Unix itself, things got out of
control irreversibly.

        Given the muddle my position remains: what the user selects is
what he/she expects to receive. Telnet terminal kind is only one piece
of a larger integrated sequence of actions and it cannot change its
behavior willy nilly without bad consequences.

        What can be done? Well, there is a constructive alternative
available to us.

-  One, enable both ends to deal with aliases of common terminal names. 

-  Two, allow different terminal kinds upon permission and control of the
   user. The first is readily accomplished in many cases, the second
   requires user interface modification.

        Joe D.


 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Message-ID: <70p0mi$nij$1@apakabar.cc.columbia.edu>
Date: 23 Oct 1998 04:29:06 GMT
From: Jeffrey Altman <jaltman@watsun.cc.columbia.edu>
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Stop automatic resetting of terminal emulation?

There are two very different philosophies about how things should be
handled when the software configuration does not match the
requirements of the connection the user wants to make.  The first,
which is your approach, is to not do anything and wait for the user to
detect the problem and initiate a fix.  This approach makes the very
big assumption that the user will know how to determine what is wrong
and be able to fix it, or have someone locally available to do that
for them.

The second approach is to try to fix it for the user in an automated
way before the problem becomes a reality.  Very often this approach
works, and the user doesn't even know the difference.  Sometimes it
doesn't work at all and the user who knows how to fix it does, and the
ones that do not know, ask for help.  Sometimes it sort of works and
the response of the user (see previous sentence) depends upon on the
impact of the new problem.

I am a believer in the second approach.  And hence, the software that
I create tries to do things for the user whenver possible even if
sometimes we might guess wrong.  We always provide a method for the user
to turn off the automatic mode if it is necessary.  Hence, Kermit 95
and C-Kermit (when possible):

 . auto-detect file transfers in both directions
 . configures character-sets for Text transfers and terminal emulation
 . sets the terminal window size
 . responds to escape sequences during the INPUT command so the user
   does not have to worry about them
 . auto-switches between terminal types
 . optimizes file transfer parameters
 . auto-switches between file transfer modes based upon filename
 . automates the authentication process
 . auto-detects the modem type associated with a TAPI device
 . auto-detects the current location for dialing local, long
   distance, international calls.

My experience has been that as the end user population becomes more
mainstream and less techie we must attempt to automatically adjust
to the technical necessities of the moment for the user whenever
possible.  Otherwise, one of two things happen:

 . the user base overwhelms the support personel with questions
   about why won't the modem dial, or PINE start, or the file
   transfer go fast; or

 . the user becomes frustrated and chooses another product.

Given the low volume of technical support queries that we receive
compared to our installed base, I think that we have made the
correct set of choices.

Does this approach work all of the time?  No, but for every time
is does work, we have one less user making a phone call, sending
an e-mail or posting to a newsgroup.  And I think that is
appreciated by our users and their local support groups.

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-

Newsgroups: comp.protocols.kermit.misc
Message-ID: <70q1jp$426$1@apakabar.cc.columbia.edu>
Date: 23 Oct 1998 13:50:49 GMT
From: Frank da Cruz <fdc@watsun.cc.columbia.edu>
Subject: Re: Stop automatic resetting of terminal emulation?

In article <wegLF5YIzlTM@cc.usu.edu>, Joe Doupnik <jrd@cc.usu.edu> wrote:
: ...
:       Life would have been simpler if there had been both adherence to
: the list of terminal names and timely expansion of the same, and vendors
: who read before pressing keys. But like Unix itself, things got out of
: control irreversibly.
:
Especially nowadays when computers are big-business and mass-market
consumer items.  The careful attention once paid to standards -- their
formulation, and subsequent adherence to them -- is pretty much out the
window.

Yet I believe we must support the standards process, both by participating
in it and by following standards even sometimes in cases when we don't
necessarily agree with them (well, within reason).

The problem at hand is what to do when the client says "I have terminal
type xyz" and the host does not understand the name "xyz".  The TELNET RFCs
allow two approaches.  One is simple: do nothing, in which case the user
can recover by hand.  The other is to negotiate through a list until an
agreeable type is found.  The tradeoffs between control (favored by the
knowledgable user) and "seamlessness" (for the less knowledgable) are
obvious.

The problem with the latter occurs not so much because a particular name
does not appear in a list at the IANA, but because no semantics are
attached to the names in the IANA terminal-type list.  Of course, when the
list was started, no semantics were needed since terminal names referred to
real physical devices with well-defined properties, published in technical
manuals.  Nowadays, many "terminal types" exist only as software
abstractions with no physical counterparts, while others are improper
emulations of physical terminals that no longer exist and whose technical
manuals are no longer available.

As noted previously in this discussion, the "ANSI" name is virtually
meaningless, since many vendors (and makers of shareware, freeware, etc)
have appropriated this term and applied it to their mutually incompatible
products.  This gives rise to difficulties such as the one we see when
trying to match terminal types between Kermit 95 and an SCO host, described
in a previous posting.  The problem in this case, however, is SCO's, and was
reported to them (by us) long ago, and has been addressed (partially) in SCO
Open Server 5.0.5:

  http://www.sco.com/cgi-bin/ssl_reference?109521

As Jeff noted, the automatic matching of terminal type tends to be
beneficial for the typical Kermit-95 user, who -- in 1998 -- is less of a
tinkerer than the typical MS-DOS Kermit user.  Thus, I think MS-DOS Kermit
behaves appropriately for its constituency, and so does Kermit 95.

- Frank

 -===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-


Date: 22 Aug 2000 16:19:54 GMT
Organization: Columbia University
Newsgroups: comp.protocols.kermit.misc
Message-ID: <8nu97a$5oa$1@newsmaster.cc.columbia.edu>
From: Jeffrey Altman <jaltman@watsun.cc.columbia.edu>
Subject: Re: k95crypt.dll

In article <g965qssk1of4sd5q00ju9d1l6nhg7210vo@4ax.com>,
Michael Sundermann  <michael.sundermann@acm.org> wrote:
: Hi,
:
: I didn't find k95crypt.dll on the Kermit WebSite.
:
: Because the export restrictions are dropped,
: where can I download the above file.
:
: Thanks
: Michael Sundermann
: Germany

Export restrictions in the U.S. have not been dropped.
They have been relaxed for source code only releases but all
binaries are still restricted.  When we are able to export
the encryption features of K95 it will be announced on this
web site.


                  Jeffrey Altman * Sr.Software Designer
                 The Kermit Project * Columbia University
               612 West 115th St * New York, NY * 10025 * USA
     http://www.kermit-project.org/ * kermit-support@kermit-project.org

 //////////////////////////////////////////////////////////////////////////////

Date: 23 Aug 2000 00:09:12 GMT
Organization: Columbia University
Newsgroups: comp.protocols.kermit.misc
Message-ID: <8nv4n8$p05$1@newsmaster.cc.columbia.edu>
From: Jeffrey Altman <jaltman@watsun.cc.columbia.edu>
Subject: Re: SSL

In article <39A30E0D.9E8A7B80@kramer-smilko.com>,
Richard R. Kramer <rrkramer@kramer-smilko.com> wrote:
: I'd like to use K95 to connect via SSL. Below is what shows when I try,
: but I don't know what to make of it. Can you tell what's missing?
: (I've xxx'd out the IP address.)
:
:  Trying xxx.xxx.xxx.xxx... (OK)
: SSL_DEBUG_FLAG on
: SSL/TLS init done!
: [SSL - handshake starting]
: SSL_handshake:UNKWN  before/connect initialization
: SSL_connect:UNKWN  before/connect initialization
: SSL_connect:3WCH_A SSLv3 write client hello A
: SSL_read_alert
: SSL_connect:failed in 3RSH_A SSLv3 read server hello A
: [SSL - SSL_connect error: error:14094410:SSL
: routines:SSL3_READ_BYTES:sslv3 aler
: t handshake failure
: [SSL - FAILED]
: Can't connect to xxx.xxx.xxx.xxx:https
: Kermit 95 1.1.20, 31 Mar 2000, for 32-bit Windows


Due to patent licensing restrictions the SSL/TLS support that
is included with Kermit 95 does not include the RSA algorithm.
If you need RSA support (and can legally use it) you must
download a version of OpenSSL that does include RSA from another
site.

Most web servers only support RSA (and not DSA) certificates.
If you are using K95 to connect to such a site, then you will
get errors similar to those below unless you retrieve a
different version of OpenSSL.  <http://www.openssl.org>

We will provide RSA support in our products sometime after
the RSA patent expires at the end of September 2000.


                  Jeffrey Altman * Sr.Software Designer
                 The Kermit Project * Columbia University
               612 West 115th St * New York, NY * 10025 * USA
     http://www.kermit-project.org/ * kermit-support@kermit-project.org

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.os.vms, comp.protocols.kermit.misc
Message-ID: <asj7mt$7co$1@watsol.cc.columbia.edu>
Organization: Columbia University
Date: 3 Dec 2002 16:29:01 -0500
From: Frank da Cruz <fdc@columbia.edu>
Subject: VMS C-Kermit with SSL/TLS


Just after C-Kermit 8.0.206 was released, Jeff Altman (with help and advice
from VMS programmers and HP/Compaq engineers) got SSL/TLS security working
in VMS C-Kermit, at least for terminal connections.  This is the first form
of secure authentication and strong encryption available for VMS C-Kermit,
and since it's in Kermit (as opposed to the regular Telnet client), it also
allows secure file transfer over the terminal session as well as scripted
secure sessions.  The SSL/TLS version of VMS C-Kermit is not released yet,
but it's available for download in source-code form here:

  http://www.columbia.edu/kermit/ckdaily.html

Sorry, we can't put up binaries for download due to US export law.

To build, you'll need a VMS system with a C compiler and with either OpenSSL
or Compaq SSL installed, as well as a TCP/IP package such as UCX (I'm not
sure what will happen with other TCP packages like MultiNet and TCPware).
Then, with the C-Kermit file unpacked into your default directory, type:

  @ckvker.com "" "" "CK_SSL"


and off you go.  Of course you'll need an SSL-capable server to make
connections to, but you wouldn't be have read this far if you didn't have
one that you needed to get to.  The details of C-Kermit security are given
here:

  http://www.columbia.edu/kermit/security.html

(which will need to be edited to discuss VMS).

Without certificates, you'll be able to get encrypted, but not securely
authenticated, connections.  The software still needs to be updated to
know where to look by default in VMS for X.509 certificates; in any case,
you can use Kermit's SET AUTH TLS or SET AUTH SSL commands to specify the
certificate files.

Interested parties are invited to build and try the code and comment on it.

As noted in other postings, it should now be relatively easy for an
experienced VMS C programmer to adapt Kermit's FTP module to VMS, which
is already SSL/TLS ready.  Anyone interested in taking this on is welcome
to contact us at:

  kermit-support@columbia.edu

Ditto for C-Kermit's HTTP client (actually, someone has this almost
completed already, with just a few stumbling blocks remaining).

Thanks.

- Frank

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.protocols.kermit.misc
NNTP-Posting-Host: 70.244.104.135
NNTP-Posting-Date: Tue, 9 Feb 2010 20:19:37 +0000 (UTC)
References: <slrnhn34mm.em3.fdc@panix2.panix.com>
Message-ID: <0997221b-776e-4b3f-8b98-4c61c016a0f7@1g2000yqi.googlegroups.com>
Date: Tue, 9 Feb 2010 12:19:37 -0800 (PST)
From: Steven Schweda <sms.antinode@gmail.com>

Frank da Cruz wrote:
>
> Anybody have a VAX (with C compiler) for building C-Kermit 9.0?

   I do, but I won't be able to reach the power switch for
about a week.  There's also:

      http://deathrow.vistech.net/
      http://deathrow.vistech.net/account-info.shtml

and probably some others elsewhere.


 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.protocols.kermit.misc
Message-ID: <8TDpa.21775$7M5.1588527@twister.nyc.rr.com>
Date: Wed, 23 Apr 2003 21:48:52 GMT
From: "Jeffrey Altman [Road Runner NYC]" <jaltman2@nyc.rr.com>
Subject: Bitstream Vera Fonts work with Kermit 95

Bitstream and the Gnome Project have worked to release a set of Open 
Source fonts.  The notion was to provide a free set of fonts which could
be used on Open Source operating systems unlike the "free" fonts which
Microsoft recently pulled from their web site.  These are standard True 
Type Fonts (.TTF) which can be installed on Microsoft Windows as well as 
X Windows.

The Bitstream Vera Sans Mono font is not as well populated as other 
Unicode True Type Fonts, however, it is extremely readable.  One of the 
nice things about the license is that the font may be modified and 
redistributed without royalties.  Perhaps someone will add the terminal 
graphics.

You can read the license and download the fonts from

   http://www.gnome.org/fonts/

You will need 'gunzip' and 'tar' in order to expand the distribution.
Perhaps Frank will be willing to place the expanded files on the Kermit 
ftp site.

- Jeffrey Altman

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.protocols.kermit.misc
Message-ID: <3ea7e04d@duster.adelaide.on.net>
References: <8TDpa.21775$7M5.1588527@twister.nyc.rr.com>
Date: Thu, 24 Apr 2003 22:32:08 +0930
From: Arthur Marsh <arthur.marsh@internode.on.net>
Subject: Re: Bitstream Vera Fonts work with Kermit 95

Thanks, I downloaded and unpacked the .bz2 version on Solaris, then used 
C-Kermit to send the .ttf files to my PC running K95, and Vera Sans Mono 
looks good (and just fits a 24 line by 80 column terminal window) at 13 
points on a monitor set to a 1024 * 768 display resolution.

Arthur.

 //////////////////////////////////////////////////////////////////////////////

Newsgroups: comp.protocols.kermit.misc
Message-ID: <b890f0$4lb$1@watsol.cc.columbia.edu>
References: <8TDpa.21775$7M5.1588527@twister.nyc.rr.com>
Organization: Columbia University
Date: 24 Apr 2003 11:39:12 -0400
From: Frank da Cruz <fdc@columbia.edu>
Subject: Re: Bitstream Vera Fonts work with Kermit 95

In article <8TDpa.21775$7M5.1588527@twister.nyc.rr.com>,
Jeffrey Altman [Road Runner NYC] <jaltman2@nyc.rr.com> wrote:
: Bitstream and the Gnome Project have worked to release a set of Open 
: Source fonts...
:
:    http://www.gnome.org/fonts/
:
: The Bitstream Vera Sans Mono font is not as well populated as other 
: Unicode True Type Fonts...


A quick inspection of this font shows it's not much more than ASCII plus
Latin-1:  It has the Euro symbol, a couple Greek letters, a few letters
needed for Polish/Czech/Turkish, a few symbols from the Apple Quickdraw set
(per mille, "smart quotes", etc) and that's about it.  It doesn't even have
line/box-drawing characters (what Jeff meant by "terminal graphics").

Although it is an attractive and readable font and installs effortlessly on
Windows, it's not particularly useful for terminal emulation.  Compare
(e.g.) with Courier New or Lucida Console, both of which come with recent
Windows versions and handle most terminal emulation tasks including math,
technical, and forms, plus Greek and Cyrillic, and (Courier New only) Arabic
and Hebrew.

- Frank

 //////////////////////////////////////////////////////////////////////////////


