Columbia Kermit/kermit.zip/e/oldfaq.txt

Internet Message Format | 2020-01-01 | 128KB

From the comp.protocols.kermit.misc newsgroup and elsewhere...

Most questions are already answered in the published documentation.  Reading
the appropriate manuals (in conjunction with online release notes) will get you
started, answer most of your questions, and will let you get the most out of
your Kermit software: maximize the performance, write scripts to automate your
communications tasks, and so on.  The Kermit Project is entirely
self-supporting, and proceeds from sales of these manuals is our primary source
of funding.  So please do purchase the manuals.

Most recent update: 5 April 2000
                               Table of Contents
   1 How to Find Kermit Software                                              i
   2 What Is the Current Version of Kermit?                                   i
   3 Where to Get Kermit Manuals                                              i
   4 Why Is Kermit So Slow Compared to Zmodem?  (It Isn't!)                  ii
   5 My Backspace Key Doesn't Work!                                          ii
   6 How Do I Use MS-DOS Kermit over Trumpet Winsock or MS WfW TCP?         iii
   7 How to Transfer Files through a 3270 Protocol Converter?                iv
   8 Where Is the Key Map for 3270 Emulation?                                 v
   9 How Can I Make MS-DOS Kermit Use COM3, COM4?                             v
   10 MS-DOS Kermit Patches Don't Seem to Take Effect.                        v
   11 I Can Transfer Text Files but Not Binary Files                          v
   12 Binary Files Are Corrupted After Transfer                               v
   13 Why Doesn't the HANGUP Command Work for Me?                             v
   14 How Can I Make the DIAL/REDIAL Commands Keep Trying?                   vi
   15 I Enabled Sliding Windows but It Looks Like Only One Is Used.          vi
   16 How Do I Write a Script to Dial a Pager?                               vi
   17 When C-Kermit Dials My V.32bis (or V.34) Modem, I Get the Error        vi
      'Can't Change Speed to 14400 (or 28800)'
   18 How Do I Use Kermit with Pine?                                        vii
   19 How Do I Get a Session Log without All the Embedded Escape            vii
      Sequences?
   20 Kermit Doesn't Work Right with My (RPI) Error-Correcting Modem!       vii
   21 What about Winmodems?                                                viii
   22 What Kind of Modem Should I Buy?                                     viii
   23 My Arrow Keys Don't Work                                               ix
   24 MS-DOS Kermit under Windows Can't Find My Port                         ix
   25 If I Have an Error Correcting Modem Why Do I Need Kermit Protocol?      x
   26 How Do I Use 'SET KEY' with PC F-Keys, etc, in UNIX or VMS C-Kermit?    x
   27 How Can I Exit from C-Kermit without Hanging Up?                        x
   28 What Is SuperKermit?                                                    x
   29 Is Kermit Software Year-2000 Compliant?                                 x
   30 Is There a Kermit Library?                                             xi
   31 How Do I Call up a Dialback Service?                                   xi
   32 How Does the Numeric Keypad Work?                                     xii
   33 How to Get Rid of the "OK to Exit?" Prompt?                           xii
   34 How to Tell Kermit to Ignore Dialtone?                                xii
   35 Where is the Dialing Script for My Modem?                             xii
   36 I'm Having Terminal Emulation Problems with C-Kermit                 xiii
   37 Divide Overflow in MS-DOS Kermit                                     xiii
   38 Problems Using XYZMODEM External Protocols in C-Kermit               xiii
   39 Tone Dialing Changes to Pulse after First Digit                      xiii
   40 How to Transfer Files with the HP-48?                                xiii
   41 I'm Having Trouble with F-Keys                                       xiii
-------------------------------------------------------------------------------

1 How to Find Kermit Software

  World-Wide Web:
    http://www.columbia.edu/kermit/

  ftp: kermit.columbia.edu
    This is the definitive source for Kermit software
    on the Internet.  Other Kermit archives or "mirror sites"
    are not necessarily complete, accurate, or up to date.

  Newsgroups:
    comp.protocols.kermit.announce - Moderated
    comp.protocols.kermit.misc     - Unmoderated

  E-mail:
    [e-mail] (Orders and order inquiries)
    [e-mail] (Tech support)
    [e-mail] (General -- not an FTP mail server!)

  Post:
    The Kermit Project
    Columbia University
    612 West 115th Street
    New York NY  10025-7799
    USA

  Fax:  [phone]  or  [phone]

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

2 What Is the Current Version of Kermit?

Kermit 95 for Windows 95, 98, NT, and 2000:    1.1.20     Mar 31 2000
Kermit 95 for OS/2 (32-bit):                   1.1.20     Mar 31 2000
C-Kermit for OS/2 1.x (16-bit):                5A(190)    Oct  4 1994
MS-DOS Kermit for DOS and Windows 3.x:         3.15       Sep 15 1997
C-Kermit for UNIX, VMS, AOS/VS, OS-9:          7.0.197    Feb  8 2000
C-Kermit for Stratus VOS:                      7.0.197    Feb  8 2000
G-Kermit for UNIX:                             1.00       Dec 25 1999
C-Kermit for Atari ST:                         5A(189)    Jun 30 1993
IBM Mainframe Kermit for TSO:                  4.3.3      Feb 12 1999
IBM Mainframe Kermit for CMS, CICS, and MUSIC: 4.3.2      Dec 16 1997
Kermit-11 for RT-11:                           3.63       Sep 27 1997
Kermit-11 for RSX, RSTS, etc:                  3.60       Jun 13 1989
Mac Kermit (NOT A REAL RELEASE):               0.993(192) Jun  3 1996

Others (hundreds of them): See kermit/a/aavsys.hlp.

Also see the What's New section of our website.
-------------------------------------------------------------------------------

3 Where to Get Kermit Manuals
MS-DOS Kermit, full-featured communications software for IBM and compatible PCs
with DOS or Windows 3.x, is documented in:

    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 the current version of MS-DOS Kermit for
    the IBM PC, PS/2, and compatibles on a 3.5-inch diskette.  In computer
    and book stores, or order direct from Columbia University or from
    Digital Press.

A German-language edition is also available:

    Christine M. Gianone, MS-DOS Kermit, das universelle
    Kommunikationsprogramm, Verlag Heinz Heise, Hannover, Germany (1991),
    414 pages.  Packaged with version 3.12 of MS-DOS Kermit for the IBM PC,
    PS/2, and compatibles on a 5.25-inch diskette, including German-
    language help files.  Deutsch von Gisbert W. Selke.  ISBN
    3-88229-006-4.

And a French-language edition:

    Christine M. Gianone, Kermit MS-DOS mode d'emploi, Deuxieme edition,
    Heinz Schiefer & Cie., Versailles (1993), 406 pages.  Packaged with
    version 3.11 of MS-DOS Kermit for the IBM PC, PS/2, and compatibles on
    a 5.25-inch diskette.  Adaption francaise: Jean Dutertre.  ISBN
    2-901143-20-2.

There is also a Japanese book about MS-DOS Kermit, concentrating on the NEC
PC9801:

    Hirofumi Fujii and Fukuko Yuasa, MS-Kermit Nyumon, Computer Today
    Library 6, Saiensu-Sha Co., Ltd., publishers (1993), 160 pages.  ISBN
    4-7819-0669-9 C3355 P1854E.

C-Kermit 6.0, full-function communication software for UNIX, VMS, AOS/VS, VOS,
OS-9, QNX, the Commodore Amiga, and other platforms, is documented in:

    Frank da Cruz and Christine M. Gianone, Using C-Kermit, Second Edition,
    Digital Press / Butterworth-Heinemann, Woburn, MA, 1997, 622 pages,
    ISBN 1-55558-164-1.  In computer and book stores, or order direct from
    Columbia University or from Digital Press.

A German-language edition is also available:

    Frank da Cruz und Christine M. Gianone, C-Kermit--Einfuehrung und
    Referenz, Verlag Heinz Heise, Hannover, Germany (1994).  ISBN
    3-88229-023-4.  Deutsch von Gisbert W. Selke.

The Kermit File transfer protocol is specified in the following book, which
also includes tutorials on computers, file systems, data communications, and
using Kermit:

    Frank da Cruz, Kermit, A File Transfer Protocol, Digital Press /
    Butterworth-Heinemann, Worburn, MA, 1987, 379 pages, ISBN
    0-932376-88-6.  In computer and book stores, or order direct from
    Columbia University or from Digital Press.

Kermit software for hundreds of different computers and operating systems is
available from Columbia University.  Contact Columbia for a free Kermit
software catalog.

ENGLISH-LANGUAGE KERMIT BOOKS:

   1. In computer and book stores, or order direct from the publisher,
      Digital Press / Butterworth-Heinemann with MasterCard, Visa, or
      American Express:
        [phone]   (Woburn, MA office for USA & Canada,
                           Toll-free M-F 8AM-6PM Eastern time)
        [phone]   (Newton, MA office for sales/marketing info)
        [phone]   (Oxford, England distribution centre for
        [phone]  (Melbourne, Vic, office for Australia & NZ)
        [phone]      (Singapore office for Malaysia, Singapore,
                           Indonesia, Philippines, Thailand)
        [phone]  (Durban office for South Africa)

   2. From Columbia University:
        The Kermit Project
        Columbia University
        612 West 115th Street
        New York NY  10025-7799
        USA
        Tel.  [phone]
        Fax.  [phone]
        E-Mail: [e-mail]
      Domestic and overseas orders accepted.  Add $10 US PER BOOK for
      shipping outside of North America.  Orders may be paid by MasterCard
      or Visa, or prepaid by check in US dollars.  Add $65 bank fee for
      checks not drawn on a US bank.  Price includes shipping.  Do not
      include sales tax.  Quantity discounts are available.  Single-copy
      US prices (in US dollars):
        Using MS-DOS Kermit  . . . . . . . . . . . . . . . . .$ 44.95
        Using C-Kermit . . . . . . . . . . . . . . . . . . . .$ 44.95
        Kermit, A File Transfer Protocol . . . . . . . . . . .$ 39.95
        All three  . . . . . . . . . . . . . . . . . . . . . .$ 90.00

GERMAN-LANGUAGE KERMIT BOOKS:
  MS-DOS Kermit, das universelle Kommunikationsprogramm: DM 20,00
  C-Kermit--Einfuhrung und Referenz: . . . . . . . . . . DM 25,00

  Verlag Heinz Heise GmbH & Co. KG
  Helstorfer Strasse 7
  D-30625 Hannover, GERMANY
  Tel.  [phone]
  Fax.  [phone]

FRENCH:  Kermit MS-DOS Mode d'Emploi:  . . . . . . . . . . .  FF 495,00
  Heinz Schiefer & Cie.
  45 rue Henri de Regnier
  F-78000 Versailles, FRANCE
  Tel.  [phone]
  Fax.  [phone]

JAPANESE:  MS-Kermit Nyumon: . . . . . . . . . . . . . . . . .  1,800 Y
  Saiensu-Sha Co., Ltd.
  Abe-toku Building
  2-4 Kanda-suda cho, Chiyoda-ku
  Tokyo 101, JAPAN
  Tel.  [phone]
-------------------------------------------------------------------------------

4 Why Is Kermit So Slow Compared to Zmodem?  (It Isn't!)
Path: news.columbia.edu!usenet
From: [e-mail] (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: [HELP] Slow Kermit Transfer ?!
Date: 19 Sep 1994 14:15:42 GMT
Organization: Columbia University
Lines: 153

In article <[e-mail]>
[e-mail] (Binh Anson) writes:
> I used Kermit 3.13 for my PC, my modem has a speed of 14.4 K, but I
> found that the downloading rate from the mainframe to my PC was
> still very slow!  I tried Telix with SZ (Z-Modem Protocol), and it
> was very fast compared to Kermit. Is there a way to accelerate
> Kermit transfer ?
>
Yes.

But first, welcome to comp.protocols.kermit.misc.  This is the first day of
operation of this unmoderated newsgroup.  I hope it will prove beneficial to
all Kermit users.

To answer your question, somewhat longwindedly, since this Question is Asked so
Frequently :-) ...

Zmodem is optimized for speed on the assumption that it has a clear 8-bit
transparent channel with no blockages (small buffers, etc), and so, out of the
box, when it works it goes fast.  The tradeoff is that it often does not work
at all, in which case you have to configure it in various ways -- escaping of
control characters, changing window size, etc.  In some cases it can't be made
to work at all, either because of the nature of the connection, or because of
one or both of the computers on the two ends.

Kermit, on the other hand, is configured to work -- i.e. transfer files -- out
of the box, even under hostile conditions.  By default, it does not assume that
control characters pass through transparently, nor that large buffers are
available.  It does not even assume a full-duplex connection.  The tradeoff is
speed.

In a perfect world, there would be no tradeoffs, but the world is far from
perfect.  7-bit transmission is still extremely common, small buffers are very
common, even in modern terminal servers and other communications processors,
flow control is rarely implemented correctly and effectively, telephone lines
are still noisy, and we still have a bewildering array of communication methods
needed for accessing different kinds of hosts and services.  Most PCs are still
shipped with non-buffered UARTs; many PCs have interrupt conflicts, noisy
buses, etc; many modern modems are buggy.  The list goes on.  This is by way of
demonstrating that Kermit's default tuning is not crazy, and goes a long way
towards explaining its justified reputation for dependability.

Unfortunately, because of the tradeoffs necessary to achieve its reliability,
Kermit has a reputation for slowness:

    Yes, Kermit transfers are slow if you use the default tuning.

However, you can make Kermit go as fast as the communication path will permit
by changing a few parameters.  But first, here are some general principles that
apply to all communications software:

   1. Ensure that you have an effective means of flow control enabled at
      every juncture along the communication path (this applies to any
      file transfer protocol).  For example, when using high-speed,
      error-correcting modems, you should use some form of hardware flow
      control, most commonly RTS/CTS.  You have to tell the software to
      use it, AND you have to tell the modem to use it too -- if the flow
      control methods of the PC and the modem do not agree, then data will
      be lost.  The same is true of the modem at the other end of the
      connection, and the computer or device it is connected to.

   2. If your modem is capable of data compression, use it.  Fix the
      interface speed of the software to four times the connection speed
      if possible -- e.g. for a V.32bis 14400 bps connection, use an
      interface speed of 57600, or else the modem's compression capacity
      is likely to be wasted.

   3. On network connections (e.g. TCP/IP), it is usually best to turn off
      flow control entirely, because the underlying networking method
      supplies fully effective flow control.

Now, to make Kermit go fast, follow these steps:

   1. Use real Kermit software, not the many shareware and commercial
      packages, most of whose Kermit protocol implementations lack the
      performance features listed below and/or the means for the user to
      control them.


   2. Use long packets.  Kermit's default packet length is 94.  You can
      increase it to a theoretical maximum of 9024.  Give the following
      command to the file receiver:

      SET RECEIVE PACKET-LENGTH 2000  ; (or other length)

      The longer you make the packets, the more efficient the file
      transfer will be... IF IT WORKS.  If you make packets longer than
      some buffer somewhere along the line, and effective flow control is
      lacking, the transfer might not work.  Also, the longer the packet,
      the greater the chance it will be hit by noise, and the longer it
      takes to retransmit.  A good starting value to try is 1000.


   3. On full duplex connections, use sliding windows.  Sliding windows
      allow packets to be transmitted in a continuous stream, rather than
      "stop and wait" style.  The command is:

      SET WINDOW 4 ; (or other number)

      The maximum is 32 (or less, depending on the implementation).  Give
      this command to both Kermit programs.

For text files and uncompressed binary files, this should give you very good
performance -- efficiencies in the 85%-100% range.

For compressed files, and certain other types of binary files, you can squeeze
out another 20-25% efficiency by telling Kermit not to prefix a given list of
control characters.  A typical sequence might be:

  SET CONTROL UNPREFIX ALL  ;  Unprefix all control characters.
  SET CONTROL PREFIX 0 1 13 129 141 ...  ; Add back prefixes for these.

This might require some trial and error because there is no way that a
communication software program can know what characters are safe and which ones
are not on a particular connection.  For example, you might be going through an
X.25 PAD where Ctrl-P will pop you back to the PAD prompt.  Or you might be
going through a TELNET terminal server where Ctrl-] or Ctrl-^ will pop you back
to the terminal server prompt.  Or the connection might be using Xon/Xoff flow
control, and sending Ctrl-S as a data character might freeze the connection.

If you take all of these steps, using optimal packet lengths, window sizes, and
unprefixing, you should achieve transfer rates comparable to, and often better
than, the Zmodem implementations that you find in Telix, Procomm, and similar
shareware and BBS packages; for example, on a V.32bis/V.42/V.42bis connection,
RTS/CTS flow control, no parity, 57600 bps interface speed:

  Typical text files:        3500 cps (characters per second)
  Uncompressed binary files: 2400 cps (e.g. PC KERMIT.EXE)
  Compressed files:          1600 cps (e.g. ZIP files)

These figures come from Kermit News #5, June 1993, which is available on the
Web and also via anonymous ftp from kermit.columbia.edu, directory kermit/e,
file newsn5.txt (ASCII) or newsn5.ps (PostScript).  Also see Kermit News #4,
newsn4.txt (.ps), for a detailed discussion of long packets and sliding
windows.  [As of late March 1995, there are also html versions of these files
suitable for Web access.]  Kermit software is available via anonymous ftp to
kermit.columbia.edu [128.59.39.2], directory kermit and its subdirectories.
There are literally hundreds of different Kermit programs for *almost* every
machine and operating system imaginable.  The most widely used Kermit programs
are:

   - MS-DOS Kermit for DOS and Windows 3.x.  No, this is not a native Windows
     application, but yes, this is the Kermit software we recommend and support
     for Windows 3.x.  File: kermit/archives/msvibm.zip

   - C-Kermit for UNIX, VMS, OS-9, AOS/VS, the Commodore Amiga, etc.

   - IBM Mainframe Kermit-370 for VM/CMS, MVS/TSO, CICS, and MUSIC.
     kermit/b/ik*.*.

- Frank

POSTSCRIPT:  The Kermit software for Windows 95 and NT is Kermit 95.  It was
first released in October 1995 (after this message was posted).
-------------------------------------------------------------------------------

5 My Backspace Key Doesn't Work!

From: [e-mail] (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: [?] Backspace key says, "^?"
Date: 7 Jan 1995 21:26:44 GMT
Organization: Columbia University
Lines: 122

In article <[e-mail]>,
Jim Monty <[e-mail]> wrote:
> DISCLAIMER: I've looked for the answer to the following question in
> _Using MS-DOS Kermit_ and in the documentation included with MS-DOS
> Kermit 3.13.  I either couldn't find the answer or didn't understand
> it if I did.
>
Thank you for consulting the documentation.

> I'm using MS-DOS Kermit 3.13 on an i80386SX machine running MS-DOS
> 6.0, using a 14,400 bps Zoom VFP V.32bis modem.  Kermit is set for
> VT220 terminal emulation and is using the Latin1 character set and
> code page CP437.  I've not mucked with much in the initialization
> files, so you may assume that any other parameters are still set to
> the "factory" defaults.
>
> Alas, the question: In some online environments, my backspace key
> behaves as one would expect it to.  In others, hitting the backspace
> key results in either (1) nothing happening, or (2) the characters
> "^?"  appearing on the screen.
>
Or (3) the Backspace key acts like an Interrupt character on the host
(this usually happens with System V based UNIXes).

> I can, however, use Ctrl-H in these
> situations.  In these exact same online environments (e.g., vi
> insert mode when connected to my dial-up UNIX shell account) under
> analagous circumstances, the other terminal emulator that I use,
> Telemate Version 3.12, does not behave this way.  The backspace key
> functions as a destructive backspace.
>
> I presume that the change I need to make to my MS-DOS Kermit
> configuration is a simple one, but I can't figure it out.  And I've
> never really wanted to bother to spend a lot of time trying to
> figure it out myself.  (I want the magic straight from the wizards'
> minds.)  Thanks, in advance, for taking the time to help me.
>
> Jim Monty, Kermit Cheerleader at Arthur Andersen LLP
>

Well, Jim, I think it's finally time to classify this as a Frequently Asked
Question and add it to the FAQ (kermit.columbia.edu:kermit/FAQ.TXT).

As you have discovered, different hosts and applications use different
characters (or sequences) for destructive backspace.  The terminal emulator,
Kermit or otherwise (including Telemate -- if its backspace key works for you
in all circumstances, I think that's just a stroke of luck), has no way of
knowing what host or application you are using, and therefore no way of knowing
what to send when you press the Backspace key.

Of course, Kermit's Backspace key must send *something* "out of the box", so it
uses one of the several most likely destructive backspace values, and in fact
the one that is defined in ASCII to be destructive backspace, namely Rubout,
also known as Delete or DEL, character number 127, which sometimes is displayed
as "^?".  Lest anyone believe this is a frivolous choice, I quote from American
National Standard X3.4-1977, Section 5.1, Control Characters:

    0/8 BS (Backspace).  A one-active-position format effector that moves
    the position backward on the same line.

    7/15 (DEL). A character used primarily to erase or obliterate an
    erroneous or unwanted character...

In cases where the default does not work, Kermit lets you redefine the
Backspace key (or any other key) to send whatever you want it to send (or to
take any other actions) with the SET KEY command.

The SET KEY command has two operands: a unique identifier for a key or key
combination, called a scan code, and the value or action to be assigned to the
key.  Scan codes are written with a preceding backslash (\).  The scan code for
the Backspace key is \270.  The default definition for this key is \127,
meaning the character whose numeric value is 127, i.e. DEL.

You can find out a key's scan code by consulting Table I-9 in the manual (pages
285-288), or by giving the SHOW KEY command to Kermit and then pressing the
desired key or key combination.

Now, as you have discovered, some applications use Ctrl-H -- ASCII BS
(Backspace) -- for destructive backspace.  Consulting the ASCII table on page
275, you see that the ASCII code for BS is 8.  So to make PC's Backspace key
send BS instead of DEL, give this command:

  SET KEY \270 \8

If you use Kermit only to connect to hosts and services that use BS for
destructive backspace, then you can put this command in your MSCUSTOM.INI file,
and it will take effect automatically every time you start Kermit.

But some people (like yourself) switch between different hosts and/or services
that expect different characters or sequences for destructive backspace.  You
can, of course, give Kermit the appropriate command every time you switch from
one to another:

  SET KEY \270 \8    ; Backspace sends BS

or:

  SET KEY \270 \127  ; Backspace sends DEL

or you can use the macros that are already defined in MSKERMIT.INI for this.
In version 3.14, for example, we have macros with names like VAX and IBM.  The
VAX macro sets things up (including the Backspace key) for communicating with
VAXes and VAX-like systems, and that means, among other things, setting the
Backspace key to send DEL.  The IBM macro, on the other hand, is used for
communicating with IBM mainframes in linemode, where BS is used.

You can use these macros as they are, or you can write your own macros based
upon them and add them to your MSCUSTOM.INI file.  To use a macro, just type
its name at the MS-Kermit> prompt.

Suppose, for example, you normally access two different systems: a BBS (which
uses 8-bit characters, ANSI terminal emulation, and BS) and a UNIX system
(which uses 7-bit characters, VT220 emulation, and DEL), and these items need
to be changed when you switch between the two.  You could write two macros such
as these:

  define bbs set term byte 8, set term type ANSI, set key \270 \8
  define unix set term byte 7, set term type vt220, set key \270 \127

And then each time you want to use the BBS, you just type "bbs" at the
MS-Kermit> prompt, and each time you want to access the UNIX system, you type
"unix".

Of course, you could take this process even further, and turn the BBS and UNIX
macros into complete connection-establishment and login scripts, following the
directions in Chapter 14 of the manual, on script programming.

[NOTE: In Kermit 95, you can choose the Backspace-key action for each
connection on the Dialer Terminal page for that connection.]

- Frank
-------------------------------------------------------------------------------

6 How Do I Use MS-DOS Kermit over Trumpet Winsock or MS WfW TCP?

Date: Sun, 8 Jan 95 13:27 EST
To: ....
From: [e-mail]
Subject: Re: Using Kermit with Trumpt Winsock
> I have an internet connection (SLIP) using Trumpet Winsock to
> establish the connection to the server under windows.  I'd like to
> use kermit at that point to telnet to my company's computer.  I've
> filled in the IP addresses in my custom file, but when I run kermit,
> and try to telnet, I get the message:
>
>   Cannot attach to an Ethernet Packet Driver....
>
> Can you give me an idea of what I'm doing wrong?
>

The rule for DOS, Windows, and similar PC operating systems is:

    ONE APPLICATION PER PROTOCOL PER NETWORK BOARD

This applies also to serial ports being used as if they were network boards,
e.g. via SLIP.

If you are talking about Windows 95 or Windows NT, you can use Kermit 95, which
does use Winsock -- any 32-bit Winsock stack (Microsoft, FTP Software, or
Trumpet).

If you are talking about Windows 3.x, read on.

Now, Trumpet Winsock is using (i.e. registered for) the TCP protocol on your
"network board".  Thus, when you try to activate Kermit's own built-in TCP/IP
networking, it finds that it can't register TCP because TCP is already
registered.  Thus it "Cannot attach to ... Packet Driver".

One might think it would be possible, then, to tell Kermit to "use" Winsock.
But Winsock TCP/IP stacks are strictly for pure Windows (and NT) programs, not
for DOS programs.  MS-DOS Kermit is a "Windows-aware" DOS program, but a DOS
program nevertheless; it runs from the DOS prompt and within DOS emulator boxes
in various operating systems, and cannot access Winsock.  If you want to make a
TCP/IP connection with MS-DOS Kermit when Winsock is running, you have to
unload Winsock and use Kermit's own built-in TCP/IP capability directly over an
Ethernet- or SLIP-class packet driver or an ODI driver.  Or else install a
second network adapter.  Or...

It is PERHAPS POSSIBLE, but not necessarily recommended, to run Kermit's TCP/IP
stack alongside of Winsock using Dan Lanciani's NDIS3PKT shim, or to use the
PKTMUX TCP/IP multiplexor.  Use these methods at your own risk.

NDIS3PKT, in Dan's words:

"Ndis3pkt is a Windows virtual device (VxD) that provides multiple emulated
packet driver interfaces in Windows VMs and converts to NDIS3.  It knows how to
route packets to the correct VM at upcall time (similar to the function of
WINPKT) and it includes an optional tcp multiplexor to allow multiple tcp/ip
stacks to coexist with the same IP address (similar to the function of PKTMUX).
It can also support multiple boards, but that isn't a much-used feature.  It
can also emulate a class 1 (Ethernet) packet driver on top of Token Ring.  In
other words, ndis3pkt is intended to be a one-stop solution to packet driver
applications over NDIS3.

"Now, when people talk about ``Winsock'' they often mean one of the Winsock
providing packages that runs in the Windows system VM, e.g., Trumpet.  Because
Trumpet Winsock is really just another packet driver application, ndi3pkt is
perfectly happy to multiplex it along with any number of DOS applications.
Thus, from a high-level viewpoint, users see this as sharing DOS applications
with Winsock.  In reality, ndis3pkt knows nothing about Winsock, but the net
effect is the same."

NDIS3PKT is in pub/ndis3pkt on newdev.harvard.edu, available by by anonymous
ftp.  Be sure to read the license in the accompanying README file, and be sure
you have a version dated 17 Mar 95 or later.

NOTE: As of January 1997, this location has moved to:

ftp://hsdndev.harvard.edu/pub/ndis3pkt

http://ndtl.harvard.edu/ndis3pkt/

(Later, August 1995, more from Dan):

"Some people have been able to run kermit & MSTCP32 w/WfWG 3.11 together using
my ndis3pkt.386 driver.  The trick is to use different IP addresses for MSTCP32
and kermit.  More generally, you need one IP address for MSTCP32 and one IP
address for all your other packet-driver applications.  This is because,
although ndis3pkt includes a tcp session multiplexor that allows multiple
packet-driver-based tcp/ip stacks to share the same IP address on one machine,
ndis3pkt has no control over the MSTCP32 stack.  If you try to use the same
address for both, MSTCP32 will reset kermit's connections and such.

"Some people have been unable to get the MSTCP32+kermit+ndis3pkt combination to
work in configurations that appear superficially identical to those which work
elsewhere.  I suspect there is some minor detail of interest to be found here,
but I don't know what it is. :)"

For additional details, see discussions in comp.protocols.tcp-ip.ibmpc and in
the ndis3pkt documentation.

PKTMUX, also a risky proposition, is nevertheless, reportedly used with success
at some sites.  As one user reports, "I would not dismiss the use of a packet
driver, PKTMUX and as many PKTDRV stubs as you need.  We use that setup with
TCP/IP Kermit, NCSA Telnet and winsock compliant apps.  If you also use QEMM,
none of that takes ANY low memory and it is stable."
-------------------------------------------------------------------------------

7 How to Transfer Files through a 3270 Protocol Converter?

From: [e-mail] (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Kermit File Transfer and tn3270
Date: 16 Jan 1995 16:46:18 GMT
Organization: Columbia University
Lines: 169

In article <[e-mail]>,
Bert DeSimone <[e-mail]> wrote:
> Gotta figure this has come up before.  We are evaluating a terminal
> server that supports tn3270.  No problem using MS-Kermit to connect
> to the terminal server and connect via tn3270 to an IBM mainframe.
> However, file transfers (either invoking server on the mainframe or
> not) always fail.  Connecting through this same terminal server to
> the same mainframe through a 7171 presents *no* problem with file
> transfer.  (BTW: I don't have to be using tn3270 on a terminal
> server; file transfers with Kermit using tn3270 on a Unix host fail
> the same way).
>
> I am speculating that the mainframe Kermit must send a transparent
> mode sequence, ordinarily processed by the protocol converter, that
> is causing the problem.
>

One of the major strengths of the Kermit protocol is its ability to transfer
files with IBM mainframes over a wide variety of connection types, and there is
an excellent Kermit software program for the IBM mainframe, which is available
for VM/CMS, MVS/TSO (and ROSCOE), CICS, and MUSIC.  The current version is
4.3.2.

All of the Kermit books and manuals ("Kermit, A File Transfer Protocol", "Using
MS-DOS Kermit", "Using C-Kermit", and the IBM mainframe Kermit online manuals)
describe the process(es) in some detail.  Here is a brief summary.

Half-duplex (local-echo), line-at-a-time connections are generally handled by
the "ibm" macro that is built in to MS-DOS Kermit and C-Kermit, which performs
the following protocol-related settings:

  set local-echo on
  set parity mark
  set flow none
  set handshake xon

Full-screen sessions go through a 3270 terminal emulator.  This can reside
anywhere between the client software (such as MS-DOS Kermit) and the mainframe.
For the past 10 or 20 years, the most common place to find the 3270 emulator
was on a special purpose "protocol converter": a box that has serial lines on
one side and a connection to the mainframe on the other.  This box generally
works by tricking the mainframe into thinking it is a "control unit" with
multiple 3270 terminals attached, and at the same time tricking the terminals
into thinking they are communicating with a "normal" ASCII character-at-a-time
host.  The box converts between 3270 data streams and ASCII terminal (e.g.
VT100) conventions.  This includes ASCII/EBCDIC character-set conversion,
cursor positioning and screen painting, and keystroke interpretation.

As you can imagine, all of these conversions would normally have a disastrous
effect on Kermit protocol packets, and also upon any other type of data that
has to be transmitted "as is", without conversion, such as graphics terminal
directives.  Thus, many protocol converters support a "transparent mode", that
allows the mainframe host to command them to turn off their conversion
functions, and at a later time, turn them back on.

When everything works as planned, the only Kermit commands required for going
through the protocol converter are:

  set flow xon/xoff ; (usually)
  set parity even   ; (or other)

Everything else corresponds to the normal Kermit defaults (remote echo, no
"handshake", etc).

Unfortunately, the method for entering and leaving transparent mode differs
from one 3270 emulation product to another.  Ideally, there are two components:
(1) the identification phase, in which the mainframe software issues a special
instruction that causes the protcol converter to respond in a unique (but
harmless) way; and (2) the actual enter- and exit-transparent-mode directives.

IBM Mainframe Kermit needs to know which kind of transparency, if any, is used
by the protocol converter so it can be put into transparent mode at the
beginning of packet protocol and taken out of it upon return to interactive
command mode.  There are several ways that mainframe Kermit can go about this.
First, you can use the SET CONTROLLER command to tell it which style of
transparency is used by the protocol converter.  Second, mainframe Kermit can
be set up by the system administrator to always use a particular style.  Third,
it can attempt to "autodiscover" the controller type by issuing various types
of identification queries and checking the results.  The third method is not
very reliable, however, since many types of protocol converters fail to respond
to these queries even when they do implement a particular style of
transparency.

Nowadays, special-purpose protocol converters are giving way to general purpose
terminal and compute servers that include a "tn3270" function.  tn3270 is a
special kind of TELNET program that also performs 3270 emulation, and requires
that the mainframe be on a TCP/IP network and have a TN3270 server.  Here are
some examples:

   1. UNIX tn3270.  Most UNIX systems come with a tn3270 program that lets
      you make a full-screen connection to an IBM mainframe.  Once you
      have made the connection, you should be able to start Kermit on the
      mainframe, give it a SEND, RECEIVE, or SERVER command, escape back
      to your terminal emulator (e.g. MS-DOS Kermit), and transfer files
      without any special settings.  If you have trouble with this, then:

         - Ask mainframe Kermit to "show controller".  If it doesn't say
           Series/1, then tell it to "set controller series1".

         - Try using shorter packets.  The maximum length that can pass
           through the protocol converter might be less than what you are
           trying to use.  A typical maximum value might be 1700.

         - Tell one or both Kermit programs to "set parity space".

   2. VMS tn3270.  Depends on the TCP/IP version.  TGV Multinet, for
      example, does not claim to support transparent mode.

   3. Cisco terminal server tn3270.  Current releases of Cisco terminal
      server software include a tn3270 feature that is supposed to permit
      Kermit transfers, but it has bugs.  Sometimes these bugs can be
      worked around by using the methods listed in (1) above and
      specifying VERY short packets, like 30 or 40 bytes.  Sometimes they
      can't be worked around at all.  A future release of Cisco software
      (probably 10.3) will include new tn3270 software that implements
      Series/1-style transparency correctly, and allows Kermit transfers
      of both text and binary files in both directions using packet
      lengths up to about 1900 (or whatever the total screen size is).

If you try all of these workarounds with your terminal server and still get
failed transfers, make packet logs and/or debug logs in both Kermit programs to
find out what the terminal server is delivering to each Kermit program, and
report the misbehavior to your terminal server vendor.

For further information about specific protocol converters and how to configure
IBM Mainframe Kermit for them, please read the ik0aaa.hlp file that comes with
IBM Mainframe Kermit.

Finally, it is possible to transfer files through a 3270 fullscreen connection
even when 3270 emulator can't be put into transparent mode at all.  You can
read about this in the second edition of Using C-Kermit and the MS-DOS Kermit
update notes file (KERMIT.UPD).  Quoting from the latter:

"Doomsday Kermit" (DDK) techniques allow file transfer with IBM mainframes
through 3270 protocol converters that do NOT support transparent mode, to be
used in conjunction with IBM Mainframe Kermit's SET CONTROLLER FULLSCREEN
command on VM/CMS, MVS/TSO, or CICS.  MS-DOS Kermit 3.13 or later and IBM
Mainframe Kermit 4.2.3 or later required.  Commands:

  SET PARITY EVEN        ; Or whatever
  SET FLOW XON/XOFF      ; Or whatever
  SET SEND START 62      ; Greater-than sign
  SET RECEIVE START 62   ; Ditto
  SET BLOCK BLANK-FREE-2 ; New block-check type
  SET HANDSHAKE NONE

BLANK-FREE-2 is a new block-check type, exactly like type 2, except encoded to
never contains blanks.  Give IBM Mainframe Kermit the following commands:

  SET CONTROLLER FULL
  SET SEND START 62
  SET RECEIVE START 62
  SET BLOCK BLANK-FREE-2
  SET HANDSHAKE 0

Doomsday Kermit file transfers are not as reliable as regular Kermit protocol
transfers, and they are much slower.  Use this method only as a last resort;
that is, only when you can't get a transparent-mode fullscreen connection or a
linemode connection to the mainframe.
(end quote)

And beyond finally: in the future, we expect to add 3270 emulation to the
Kermit software itself, so you will be able to make tn3270 connections directly
from Kermit to the mainframe without having to go through a "black box" for the
conversion.  Of course, Kermit software will handle transparency correctly (and
automatically).  (And no, I can't estimate when built-in 3270 emulation will be
available.)

- Frank
-------------------------------------------------------------------------------

8 Where Is the Key Map for 3270 Emulation?
Real 3270 terminals have all sorts of keys that regular ASCII terminals (and
PCs and Macintoshes and UNIX workstations, etc) do not have.

A big part of the job of a 3270 protocol converter is to convert between ASCII
keystrokes (including escape sequences) and 3270 keys such as PA1 through PA3
and PF1 through PF24.

The administrator of the 3270 protocol converter creates the mapping.  So in
order to make a 3270 key map for Kermit, you first have to find out what the
mapping in the protocol converter is, and then assign the ASCII values
(characters or sequences) that correspond to each 3270 key to the desired PC
(or Mac, etc) key.

It is the responsibility of each site administrator to document the key
mappings used by its protocol converters.  Once you know the ASCII values that
correspond to each 3270 key, then it's easy to create Kermit key bindings.

For example, suppose the 3270 "cursor left" function (left arrow) is mapped to
ASCII Ctrl-B (ASCII character 2).  Then in MS-DOS Kermit you would:

  SET KEY \4427 \2

where \4427 is the scan code of the PC's (gray) left arrow key, and \2 is the
code for the ASCII value of the Ctrl-B character.
-------------------------------------------------------------------------------

9 How Can I Make MS-DOS Kermit Use COM3, COM4?

From: [e-mail] (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: COM3 available in 3.14?
Date: 20 Jan 1995 15:48:20 GMT
Organization: Columbia University

In article <[e-mail]>,
Cal Lott <[e-mail]> wrote:
> I was simply wondering if version 3.14 (or any earlier) could
> address COM3 and above.
>

A frequently asked question.  The short answer: Yes.

The medium answer: COM3 and above have no standard address or IRQ, hence
communications software (Kermit or anything else) can't always find them, in
which case you have to specify the address and IRQ, using a sequence like:

  SET COM3 \x3e8 5
  SET PORT COM3

(You need both commands, in the order shown.)  You must also beware of
"missing" COM ports.  To use (say) an internal modem as COM4 when there is no
COM3 is not straightforward.

The long answer: Read section 6 of the KERMIT.BWR file on your MS-DOS Kermit
3.14 diskette (the version at kermit.columbia.edu in kermit/a, file mskerm.bwr,
might be newer).

- Frank
-------------------------------------------------------------------------------

10 MS-DOS Kermit Patches Don't Seem to Take Effect.
Since the release of MS-DOS Kermit 3.14, there have been persistent reports
that patches don't seem to "stick".  That is, after giving a PATCH command, the
patch level is still reported as 0.  This can happen if the patch file is
transferred to the PC from a UNIX system in binary mode, so the lines end with
LF rather than CRLF -- DOS does not recognize the line boundaries and therefore
Kermit does not see valid patches.  Cure: make sure each line ends with CRLF.
Fix it in an editor, or re-transfer the file in text mode.

Also, remember there is no longer a need to rename the patch file to
MSKERMIT.PCH.  Since there are now three different Kermit executables, there
must be three corresponding patch files.  For version 3.14, these are:

  MSR314.PCH  -- For full-featured KERMIT.EXE
  MSRM314.PCH -- For "medium-size" KERMITE.EXE
  MSRL314.PCH -- For "Kermit Lite" KERLITE.EXE

Notice that each patch file includes the version number as part of its name.
This allows you to run different versions of Kermit without confusion about
patching.
-------------------------------------------------------------------------------

11 I Can Transfer Text Files but Not Binary Files
Here are the causes (and cures) listed in decreasing order of likelihood:

   1. You are going through a terminal server or other type of connection
      (telnet, rlogin, etc) that chops off the 8th bit.  Kermit can't tell
      that this is happening (as it can with devices that add even, odd,
      or mark parity), so you have to tell it.  The command is:

  SET PARITY SPACE

   2. You have used the SET CONTROL CONTROL UNPREFIX command to unprefix
      one or more control characters that are not safe.  Tell Kermit to:

  SET CONTROL PREFIX ALL

      and see if it works.  If so, you'll have to home in on the
      offender(s).

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

12 Binary Files Are Corrupted After Transfer
Some non-Columbia Kermit implementations simply do not work, including some
found in BBS software.  For example, if you download a file from a BBS using
their Kermit protocol option and find a lot of Ctrl-Ys in your file where only
actual letter Y's should be, then the BBS has a broken Kermit implementation.
The same is also true if a file downloaded from a BBS in binary mode is bigger
than the original.  Ask your BBS sysop to install MS-DOS Kermit ("Kermit Lite")
as an external protocol.  See the KERMIT.UPD file in the MS-DOS Kermit 3.14
distribution for additional information.

The more common cause, however, for "corrupted" binary files is that they were
transfered in text mode.

Both Kermit and ftp transfer files in text mode by default.  This means that
record formats and character sets are likely to be converted.  You can tell
Kermit to skip all conversions and transfer the file literally, as-is, with the
command:

  SET FILE TYPE BINARY

Normally, it is sufficient to give this command to the FILE SENDER before
giving it the SEND command.  But there are some exceptions to this rule:

   1. One or both Kermits do not support "Attribute packets" (or they are
      disabled).  This is true of many of the commercial and shareware
      Kermit implementations.  Cure: tell BOTH Kermits to use binary mode.

   2. You are using some combination of C-Kermit 5A(190) or later, MS-DOS
      Kermit 3.14 or later, or IBM Mainframe Kermit 4.3.1 or later in
      client server mode.  In this case, it is the CLIENT's file type
      setting, rather than the file sender's, that prevails.  Cure: tell
      the CLIENT to SET FILE TYPE BINARY, or to be extra sure, tell them
      both.

   3. You are sending the file from VMS C-Kermit, which is unique among
      Kermit programs in its ability to automatically switch between text
      and binary mode based on the file's characteristics.  VMS C-Kermit
      ignores SET FILE TYPE BINARY and SET FILE TYPE TEXT when sending
      files, and instead uses binary mode if the file's record format is
      Fixed, and text mode otherwise.  However, some binary files, notably
      VMS ZIP files, are stored using a "text-style" record format
      (Stream_LF), so Kermit sends them in text mode.  You can override
      this by telling it to SET FILE TYPE IMAGE.

If you follow all these directions and binary transfers still come out wrong,
then perhaps the file you were downloading was corrupt to begin with -- e.g.
it was ftp'd in text mode instead of binary mode.
-------------------------------------------------------------------------------

13 Why Doesn't the HANGUP Command Work for Me?
On network connections, Kermit's HANGUP command executes the appropriate
network protocol for closing the connection, and this should always work.

On serial connections, the HANGUP commands turns off the computer's DTR (Data
Terminal Ready) signal for a period of time.  According to the standard that
governs modem signals, this action is supposed to make a modem hang up the
phone call.  If it doesn't:

   1. Your modem has been configured to "Ignore DTR".  This setting is
      available on most Hayes-compatible modems, either on a physical
      switch (such as Configuration Switch 1 on the Hayes 1200) or as a
      command (&Dx on Hayes 2400 and later, and compatibles).  In many
      cases, "Ignore DTR" is the factory setting.  If you want your modem
      to obey the DTR signal, then you should set the switch
      appropriately, or give the command AT&D2.  The actual syntax of the
      command might vary among different brands and models of modems, so
      consult your modem manual for details.

   2. Your cable or connector has DTR "hotwired high", meaning that the
      DTR wire is jumpered to some other signal that is always high (on).
      If this is not what you desire, you should replace your cable with a
      standard modem cable.

   3. You are using a Macintosh with a "hardware handshaking cable".  This
      is actually the same situation as (2), except there is no way to
      "fix" the cable - please read the ckmker.bwr file for an
      explanation.

To work around these problems in Kermit, without actually fixing the underlying
cause, you can use a macro that escapes back to the modem's command processor
and gives it the command to hang up.  Such a macro is predefined for you in the
MS-DOS Kermit 3.14 initialization file, MSKERMIT.INI:

  ; ATHANGUP macro.  Use this if regular HANGUP command doesn't do the trick.
  def ATHANGUP sleep 1,out +++,sleep 1,out ath0\13
(Note: C-Kermit uses this technique anyway.)

In MS-DOS Kermit, you can assign execution of this macro to the "hot key" of
your choice, for example:

  set key \315 {\Kathangup}  ; Assign ATHANGUP macro to the F1 key

In Mac Kermit, you can just go to the terminal screen and do it by hand:

   - Pause at least one second

   - Type +++

   - Pause at least one second

   - Type ATH0 (letters A, T, H, digit zero)

   - Press the return key.

The modem should hang up and say NO CARRIER.
-------------------------------------------------------------------------------

14 How Can I Make the DIAL/REDIAL Commands Keep Trying?
In Kermit 95, just click on the appropriate boxes in the graphical Dialer
(Options -> Dialing -> Procedures), or use the following commands at the
command prompt:

K-95> set dial retries 30   (How many times to redial)
K-95> set dial interval 20  (How long to wait between tries)
K-95> dial 5551212

In C-Kermit 6.0, use the "set dial retries" and "set dial interval" commands
shown above.

In MS-DOS Kermit, the DIAL command is defined in the MSKERMIT.INI file, and it
does indeed retry the call several times.  REDIAL is also a macro, which simply
invokes the DIAL macro with the number most recently dialed; hence it, too,
tries the number several times.  If you want to change the number of times that
the DIAL macro tries, or the conditions under which it retries, or the interval
between tries, simply edit the DIAL macro definition in MSKERMIT.INI.
-------------------------------------------------------------------------------

15 I Enabled Sliding Windows but It Looks Like Only One Is Used.

Newsgroups: comp.protocols.kermit.misc
Subject: Re: Sliding windows - only one is used?
Date: Wed Feb 15 09:21:08 1995
From: [e-mail] (Frank da Cruz)

In article <3hn07m$[e-mail]>,
4th Dimension <[e-mail]> wrote:
> I'm using MS-Kermit 3.14, PL3 on my PC, talking to C-Kermit 5A(190)
> on the remote Sun.  When I start MSK, I load the FAST macro to get
> maximum thruput. Transfer of data is pretty fast, except that I
> never see more than one window used out of the three.  Is this a
> bug, a feature, or am I doing something wrong?
>

It's not a bug and you are probably not doing anything wrong.

When two Kermit programs have agreed to use a maximum window size greater than
one, let's say 4, here is what happens:

The FILE SENDER can send up to 4 packets without waiting for an acknowledgement
from the file receiver.  Each unacknowledged packet sits in the file sender's
window until it is acknowledged.  Thus its window size grows from 1 to 2 to 3
to 4.  If acknowledgments arrive quickly, the window might not grow to its
maximum size because it does not need to.

The job of the FILE RECEIVER is to accept and verify packets, decode them, and
write the decoded contents out to the file.  If packets arrive in sequence,
then each one is processed and disposed of as soon as it arrives.  If, however,
a packet arrives that has a sequence number that is more than one greater than
the previous packet that was successfully processed, this means that a packet
is missing.  Thus the packet that just arrived can't be written out to disk
because if it were, the file would have a piece missing.  So the
out-of-sequence packet is stored in the receiver's window until the missing
piece is filled in.

Thus you won't see the file receiver's window size exceed one unless there have
been transmission errors, no matter what window size the file sender might be
using.  For greater detail see pages 102-103 of "Using MS-DOS Kermit" or pages
158-161 of "Using C-Kermit" (1st edition) or pages 256-260 of the second
edition.

- Frank
-------------------------------------------------------------------------------

16 How Do I Write a Script to Dial a Pager?
A numeric pager is one that can display a number -- usually the number to be
called back.  The number is entered by pressing Touch-Tone keys on your
telephone, usually terminated by pressing the "#" or "*" key.

Numeric pagers are not modems.  Therefore when you dial one, it does not return
a carrier signal.  Therefore, the dialing modem will not say "CONNECT" or turn
on its carrier signal.  Therefore, DIAL commands will not succeed.

You can type commands to your modem manually for testing.  For example:

  ATDT7654321,,,,,8765432#;

In this example we Tone-dial the phone number "7654321", then we pause for ten
seconds (",,,,,") to give the pager time to answer the call, then we send
"8765432" to be displayed on the pager, then we send the "#" tone, and then we
return to command mode (";").  The modem should respond "OK".  The details will
vary with your modem, your telephone service, and the pager you are dialing.

Let's assume we have a Hayes 2400 or higher compatible modem.  Here's a sample
command file to call a numeric pager:

  define \%a 7654321  ; Number to call
  define \%b 8765432  ; Number to display on pager
  set port xxxxxxx    ; Select the communication device
  set speed 2400      ; Any speed supported by the modem
  output AT\13        ; Make sure it's in command mode
  input 3 OK          ; ...
  if fail stop 1 Can't get your modem's attention
  output {ATDT\%a,,,,,\%b#;\13}  ; Make the call
  input 3 OK          ; ...
  if fail stop 1 Can't place call

You can turn this into a macro that accepts the numbers as arguments.  See
"Using MS-DOS Kermit" or "Using C-Kermit" for additional script programming
instructions, and your modem manual and the pager manual for details of calling
and paging.  Note: the OUTPUT string is enclosed in curly braces to force the
commas to be taken literally (if you were using this command in a macro
definition and did not enclose the OUTPUT string in braces, the commas would be
command separators).  Note #2 - Some modems might also support a "wait for
quiet answer" feature, e.g. by using the at-sign "@" in the dialing string:

  ATDT7654321@8765432#;

However, even when your modem supports this feature, it might not be the right
approach for every paging service.  For example, some services issue a lengthy
voice message and then a beep (or two or three) before they are ready for the
message.  So in most cases a fixed pause is safest.

What about alphanumeric pagers?  You have to dial the paging service and then
either go through a series of prompts, or else execute a protocol like TAP.
C-Kermit 6.0 comes with a TAP paging procedure:

    ckepage.ksc

You can also send an alpha page "by hand".  The manual method goes like this
(at least for paging services that support TAP "manual mode"):

   1. Set up the call.

   2. Make sure that DIAL succeeds (Alpha pagers, unlike numeric pagers,
      will send carrier back).

   3. Look for "ID=".

   4. Send uppercase "M" followed by carriage return.

   5. You are prompted for the destination pager ID.  Send it, followed by
      a carriage return.

   6. You are prompted for the text of the message.  Send the text.  It
      might be restricted to one line, and even if not, it might be
      restricted to a certain total length.

   7. You might be prompted in some way for more pages or lines; you can
      answer yes or no.

   8. Assuming you answer no, optionally look for the farewell message,
      then hang up.

The exact procedure and prompts vary according to the paging service, so you'll
need to go through the process manually to see exactly what the prompts and
sequences are.  Then you can write a Kermit script to send manual-mode
alphanumeric pages automatically.
-------------------------------------------------------------------------------

17 When C-Kermit Dials My V.32bis (or V.34) Modem, I Get the Error 'Can't
   Change Speed to 14400 (or 28800)'
Dialing is covered in detail in Using C-Kermit, second edition, and the problem
listed in the title of this section should occur only rarely in C-Kermit 6.0
(it was quite common in earlier versions).

To recapitulate very briefly: older modems, like the Hayes 1200 and 2400, that
did not do error correction or compression, but that could negotiate their
modulation speed, would report the modulation speed upon successful connection,
and change their interface speed to match.  Thus, the communication software
would also have to change its own interface speed, or else the user would see
only garbage.

Modern modems have two different speeds: the interface speed and the modulation
speed.  The interface speed can be kept constant even though the modulation
speed changes.  Or not, depending on how the modem is configured.

C-Kermit versions prior to 6.0 had no way of knowing whether your modem is set
up to lock its interface speed, or to change it to match the modulation speed,
and therefore no way of knowing whether to believe the "CONNECT 28800" (or
whatever) message.  By default, for compatibility with the huge installed base
of older modems, it did believe, and therefore changed its interface speed
according to the CONNECT message.

But if your modem's interface speed is locked (which it SHOULD be if it is an
error-correcting, data-compressing modem), you must tell Kermit NOT to change
its interface speed by giving it the command:

SET DIAL SPEED-MATCHING OFF

Now to complicate matters, some of the newer modulations report speeds that are
not commonly supported by the host operating system, such as 14400 and 28800.
Hence the message "Can't change speed to 14400" (or 28800).  But even if these
speeds were supported, you would not want Kermit changing to them if the
modem's interface speed was locked.  You would still see only garbage, but you
would not get the "Can't change speed" message.

C-Kermit 6.0, by contrast, has a much more comprehensive modem database, and
automatically chooses the appropriate SPEED-MATCHING and other parameters when
you choose your modem type.  Therefore, when you choose a high-speed modem
type, one that is capable of speed buffering, C-Kermit automatically set DIAL
SPEED-MATCHING to OFF; whereas if you choose (say) the Hayes 2400 modem type,
it will set it ON.  You can override these automatic choices by giving explicit
SET MODEM and/or SET DIAL commands after your SET MODEM TYPE command.

See "Using C-Kermit" for additional detail.
-------------------------------------------------------------------------------

18 How Do I Use Kermit with Pine?
Here's a tip sheet we use at Columbia University - thanks to Joe Brennan.

SCREEN FORMATTING

Make sure that your UNIX terminal type agrees with Kermit's terminal emulation.
For example, if Kermit is emulating a VT320, tell UNIX:

  export TERM=vt320

or:

  setenv TERM vt320

If there is a complaint about "terminal type unknown" when starting Pine, then
try a lesser VT terminal model, such as VT220, VT102, VT100.

PRINTING

Pine's print command, letter Y, is known to work with MS-DOS Kermit and Mac
Kermit.  With MS-DOS Kermit, if the printer is directly attached, it should
make the printer print the selected email message.  With Mac Kermit, it should
send the selected email message into the printer buffer, which can be seen in
the Printer window, and which can be printed using the print command in the
pulldown File menu.

The command ''pcprint'' on UNIX (*), which prints any text file, does the same
thing as Pine's Print command.  It may be easier to debug problems by running a
command like ''pcprint .profile'' at the UNIX shell ($ prompt).

(*) pcprint is a UNIX shell script:

---(cut here)---
echo -n '<ESC>[5i'
if [ $# -eq 0 ]; then
  cat
else
  cat $*
fi
echo -n '<ESC>[4i'
---(cut here)---

(Replace <ESC> by a real Escape (ASCII 27) character.

DOWNLOADING FROM PINE TO THE PC

Use Pine's command letter E, Export, to copy a message into a file.  This file
will be created in your home directory on UNIX.  Then it can be downloaded to
your PC or Mac using Kermit.  After you finish, remember to remove the
now-unneeded file on UNIX, using the ''rm'' command at the $ prompt.

If you View a MIME-encoded message, Pine will ask whether to save it to a file
with a name of your choice.  Pine will decode the message and create the file
in your home directory on UNIX.  It can then be downloaded to your PC using
kermit.  MIME-encoded files are often binaries rather than plain text, so you
should set kermit to transfer a binary file.

UPLOADING FROM THE PC TO PINE

Send email in plain text if possible.  Save the document as plain ASCII text
with the PC application that created it.  Use Kermit to upload it to UNIX.  Run
Pine, choose letter C, Compose, and address your message as usual.  Move the
cursor to the Message Text area and choose control-R, Read File, and type the
name the file (the copy on UNIX) to insert.  You will see the file on screen,
as if you had typed it.  If it looks strange, it's not plain text, so start
over.  After you finish, remember to remove the now-unneeded file on UNIX,
using the ''rm'' command at the $ prompt.

If you want to send a PC document, use Kermit to upload it, setting Kermit to
transfer a binary file.  Run Pine, choose letter C, Compose, and at the
Attchmnt: header, type the name of the file (the copy on UNIX).  Pine will
encode it using MIME, and attach it to the end of any text you choose to type
in the message.  *Note*: with MIME or any form of encoding, you should
determine whether the recipient of your message will be able to decode it.
Plain text email (previous paragraph) can be read on any email system.
-------------------------------------------------------------------------------

19 How Do I Get a Session Log without All the Embedded Escape Sequences?
This can be done in Kermit versions that have true terminal emulators, such as
MS-DOS Kermit and Kermit 95.

In MS-DOS Kermit:

   - Don't LOG SESSION.  Instead, SET PRINTER <filename>.

   - Use Ctrl-Print Screen to "toggle" logging.

In Kermit 95:

   - Don't LOG SESSION.  Instead, SET PRINTER <filename>.

   - Press the key that has the \KprtAuto Kverb assigned to it to toggle
     logging on and off (it is off at first).  \KprtAuto is assigned to
     Alt-o (letter "o") by default.

The resulting file will contain only screen lines, and not the escape sequences
that put them there.  The mechanism used internally is called "autoprint", and
works by sending each screen line to the printer or printer file when the
cursor leaves it.

In UNIX and OS-9 C-Kermit, you can "set session log text".  This does not
filter out escape sequences, but at least it takes care of CR/LF/CRLF
conversion for you; see the description of this command in "Using C-Kermit".
-------------------------------------------------------------------------------

20 Kermit Doesn't Work Right with My (RPI) Error-Correcting Modem!
When you buy a modern error-correcting, data-compressing, speed-buffering
modem, you probably expect the modem to perform those functions, and most do.
Unfortunately, some modems that claim to have these features do not have them
at all, but require external software that implements them in your computer,
rather than in the modem where they belong.

One example of this practice is the Rockwell Protocol Interface (RPI), a
proprietary "standard" from Rockwell International Company that allows modem
companies to sell modems at a lower price by incorporating Rockwell chips that
do not include error-correction or compression capabilities.

This "standard" must be licensed from Rockwell, hence you will only find it
implemented in commercial software, such as on the diskette (if any) that came
with your modem.

In general, such software is available only for PCs running Microsoft Windows
3.x or Windows 95, or built into proprietary communications packages like
Comit.

If your modem documentation says it requires "RPI-compatible" software for
error correction and compression, and you want to use it with Kermit, then you
are out of luck unless you also have the software driver for the modem and can
use it on your computer.  Otherwise you bought the wrong modem.  Hopefully, you
can return it.

It is usually hard to tell by reading the modem box.  One user reports: "The
RPI bit is hidden on the back of the box: '*Error Control* V.42 and MNP RPI
software,' and '*Data Compression* V.42bis RPI software.'  The box design is
such that, unless you happen to already know what RPI is, you think you're
getting a modem with MNP/V.42 LAPM/V.42bis compression built in."

If you can't return the modem, you can still use it without error correction,
but then:

   - Noise is not filtered out on the modem-to-modem connection, as it
     would be with a real error-correcting modem, and noise bursts will
     interfere with your online sessions and your file transfers.

   - There is no modem-to-modem compression, because that requires error
     correction.

   - There is no flow control, because that too requires an
     error-correction protocol between the modems.

   - Speed buffering is ineffective because that requires flow control
     between the modems.  Thus, if the two modems have different interface
     speeds, vast amounts of data will be lost.

Thus, none of the modem's "advanced features" are really there.

Why RPI is a bad idea:

   - Implementation of MNP, V.42, and V.42bis in software is a VERY big
     job.  Since it is uneconomical for software companies to write
     software for any platform other than Microsoft Windows, it is
     unlikely that RPI drivers will ever be written for DOS, UNIX, OS/2,
     VMS, or any other platform.

   - Even when a company wants to produce a driver for (say) a new release
     of Windows, there is generally a long lag time before it is
     available.  Thus you might find when you install your brand-new
     operating system that your modem has become useless.

   - The driver software slows down your computer by consuming a vast
     amount of CPU cycles over and above what would be used if
     error-correction and compression were done in the modem, and it
     increases memory requirements, swapping, and in general can be
     expected to drag down the performance of your PC.

   - RPI seeks to replace an open communication method (the one that is
     universally used by serial communication software) by a closed,
     proprietary, licensed one, and potentially hold hostage all
     communications software developers to nondisclosure agreements.

   - It precludes publication of source code.

   - Since MNP 2-5 and V.42 and V.42bis are complex protocols, the
     software implementations will inevitably be buggy and are unlikely to
     be consistent, especially since the "standard" is not an open one,
     and the implementations themselves will not be open.

   - Even if the drivers are not buggy, the underlying operating system is
     likely to be.

   - Since not all software in the world will be "upgraded" to "support"
     the RPI "standard", your modem will not be usable in many of the ways
     you might have expected to use it.

   - Many people will buy these modems under the mistaken impression that
     they can use their high speeds and advanced features with their
     favorite software.  The average mass-market consumer is unlikely to
     understand the implications of "requires RPI-compliant software" in
     tiny print on the box.

   - By Gresham's Law, "The bad drives out the good".  RPI modems are
     cheaper, and might well drive reputable modems out of the
     marketplace, leaving the entire world's online community with no
     modems left to choose from but ones that will work only with Windows.
     This drives another nail into the coffin of "legacy" non-Windows
     platforms, and this, in turn, leaves the public with fewer choices
     for operating systems, applications, and computers themselves.

What are the benefits of RPI?

   - Lower-cost modems?  In order to save a few dollars, you are giving up
     the ability to use the modem on the platform of your choice, with the
     software of your choice, and you are probably going to get poorer
     performance than you would have had with the EC and DC protocols
     built-in over the life of the modem.

How do I tell if I have an RPI modem?

   - According to Rockwell, all RPI modems should issue a message
     containing "RPI" in response to the command ATI3.  Here are some
     examples:

AFEP-V1.510-BP39 ROCKWELL RPI (TM) MODEM
AFEP-V1.620z1.00 BS39 ROCKWELL RPI (TM) MODEM
V1.620-BP39 ROCKWELL RPI (TM) MODEM

   - The command to enable error correction (such as AT&Q5, depends on the
     modem) results in an ERROR response.

   - They normally have AT+Hdigit commands to control the RPI interface.
     (This one is not dependable, since there are no standards for modem
     commands, and so AT+H might be used on non-RPI modems for some
     entirely unrelated purpose.)

Is there a list of RPI modems?

   - No.  Just about any modem manufacturer is likely to have RPI models.
     The modem market is incredibly volatile, fast-moving, and voracious.
     Any such list would be obsolete before you could see it.
     Once-scrupulous companies will now do anything to cut costs and
     increase margins.  They have no choice -- if your competitors are
     doing it, you have to do it too or lose your business.  Rockwell
     licenses RPI "technology" to anyone who will pay for it, but is under
     no obligation to disclose its licensees, nor are the licensees under
     any obligation to inform Rockwell (or anybody else) which models
     contain RPI chips and which do not.  In many cases, the same make and
     model can have RPI and non-RPI variations.  This makes technical
     support an increasingly difficult job.  By saving a small amount of
     money for themselves, the modem manufacturers have created unneeded
     confusion among users and service providers, and driven up costs
     throughout the online world.

Is RPI the only "software driven" modem scheme?

   - No.  There are similar products from other companies.  This further
     complicates the task of the help desks of the world, for even once
     they have ruled out that a modem problem is due to RPI, it might be
     some other kind of "controllerless" modem based, for example, on the
     HSM chipset from AT&T (now Lucent).  US Robotics (now 3Com) sells a
     "Winmodem" (see next question).  IBM has the Mwave, whose signal
     processing functions (the very core of a modem) must be downloaded
     from the computer.

   - We can only expect to see more and more of this in the future.  As a
     maker of such items commented in the comp.dcom.modems newsgroup,
     "There's certainly a market for platform-independent modems, but you
     can't expect manufacturers to ignore the market opportunity for
     Windows-only modems, especially when they can have a cost and
     performance advantage."

Of course you can't.  But what about end users who don't understand any of
this?  Most of them do not make informed choices when buying modems.  And
increasingly, many of them make no choice at all -- the modem comes
preinstalled in a PC they have bought, and does not even include a manual;
sometimes not even a brand name.  And now that RPI modems have been out for a
while, we are beginning to see how they are passed from hand to hand, installed
in or connected to new computers (for use, e.g., with DOS or Linux) and causing
a whole new wave of problems.

If you have an RPI or other controllerless modem, and you need to use it in a
setting for which a driver is not available -- that is, in most cases, any
platform other than a PC running Microsoft Windows -- you are just plain out of
luck.  Return it and buy a real modem.  This way, you will encourage modem
manufacturers to continue to make real "platform-independent" modems.
-------------------------------------------------------------------------------

21 What about Winmodems?
Refer to the previous section.  Note, however, that Winmodems are even more
Windows-dependent than RPI modems, as they rely on the Windows drivers not only
for error correction and data compression, but for all of their modem
functions.  Thus they are totally useless outside of Windows 3.1 or Windows 95,
and even under those operating systems, they can be used only by native Windows
applications, and not by DOS applications -- not even when they are running in
a Windows window.  To quote from a posting to comp.dcom.modems from August 7,
1996:

"While the Winmodem does have some advantages over modems, this device and
others like it are generally inferior to a real and true modem.  The Winmodem
isn't really a modem, it's just a DSP and a few other componants on a card.  It
doesn't become a modem until you load up the Windows drivers for it.  First off
this means that you're totally and completely stuck with Windows software.  No
support for DOS in any way (not even through a DOS session in Windows), OS/2,
Linux, or even WinNT.  Furthermore it uses your computer CPU for some tasks
normally handled by a processor in the modem.  This drains some CPU power and
memory from your computer, which can slow applications down (although just how
much it'll slow things down depends on a number of factors)."

Thus you can not use MS-DOS Kermit or any other DOS communications software
with a Winmodem.  Nor can you use a Winmodem in Linux, SCO, OpenBSD, FreeBSD,
or any other form of PC-based UNIX.  You can, however, use Kermit 95 in Windows
95 or 98 (not Windows NT) with a Winmodem, since Kermit 95 is a native 32-bit
Windows application with access to the Windows drivers.

BUT... Even when we only want to use our Winmodem in Windows 95/98, and are
willing to live with the performance degradations, we still might have some
unpleasant surprises:

   - When you install a new software package, the modem stops working.
     The error might be something like "Failure to load DSP".  The new
     software package destroyed or renamed some unknown Windows Registry
     entry or file on your disk, which is a criticial part of the modem.
     Real modems are self-contained and are therefore immune to this
     phenomenon.  You'll need to reinstall the "modem" or Windows itself
     to recover.

   - You can't use your sound card when you are using your modem, because
     the modem uses the sound card for analog/digital conversion.

   - Modem calls will often fail for mysterious reasons related to your
     sound card or who knows what else.  Often, you will need to reboot,
     perhaps more than once, to clear the problem.

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

22 What Kind of Modem Should I Buy?
Refer to the previous two sections.

We have always recommended external modems.  In the past, the main reasons for
this were that:

   - They can be connected to any kind of computer that has a serial port.

   - You can monitor the lights and speaker sounds for troubleshooting.

   - They don't cause interrupt conflicts or address confusion, as
     internal modems almost always do.

In recent times, the reasons to stick with external modems are all the more
compelling:

   - Almost any recent-model modem is bound to have bugs and defects.
     Therefore it is better to keep it outside your PC, where it can't
     affect the internal bus, configuration, or interrupt structure of
     your computer.

   - An external modems can be turned off and on to return it to its
     power-up configuration, as is often necessary when the modem becomes
     hopelessly confused.  Internal modems can be power cycled only by
     turning your whole computer off and on.

   - External modems are almost never "controllerless".  To the best of
     our knowledge, all RPI modems, Winmodems, and other "software
     assisted" modems are internal PC modems.

   - External modems are never "Plug and Play".  Plug and Play modems need
     special OS-specific loaders to be initialized correctly.  They can't
     be used with DOS applications, even in a Windows 95 DOS window.  To
     the best of our knowledge they work only in Windows 95/98, and maybe
     to some degree also in Linux through the isapnptools software.

We do not recommend or endorse any particular brand of modem.  However, we do
recommend the following attributes:

   - It should be external rather than internal.  The extra price is worth
     it.

   - It should follow established ITU-T (formerly CCITT) standards like
     V.32bis, V.34, V.90, V.42, and V.42bis.  If a modem claims to
     "exceed" standards or "set" standards, beware; it is unlikely to
     interoperate correctly, or at all, with modems from other
     manufacturers.

   - It must not depend on operating-system-specific drivers or loaders
     for any of its signal processing, modulation, error-correction, or
     compression functions.  The operating system should be able to make
     full use of it through its serial-port driver, with the application
     providing the interface to the modem's command language.  Thus you
     should be able to change or upgrade operating systems without losing
     the ability to use your modem.

Read the box carefully before buying.

56K modems are designed for only one purpose: to dial up an Internet Service
Provider (ISP) that offers 56K service and has a digital connection to the
telephone network. If they don't work for other purposes, this is not
surprising, since they were not designed for any other purpose.

V.90 is the recently approved ITU-T standard 56K method, whereas X2 and K56flex
are competing proprietary methods that preceded the standard. While V.90 is
based on the other two, it does not include either one of them, and is only
just now appearing on the market.

Basic connection problems can occur if:

   - There is more than one analog segment (and therefore more than one
     analog/digital conversion point) in the telephone circuit between two
     56K modems. Of course, you have no control over this. But it is
     likely if you are calling any host or service that does not have a
     direct digital link to the phone network. It might also be the case
     if you are calling out from a PBX, which can involve multiple A/D D/A
     conversions.

   - There is only one analog segment, but it is too long or too noisy.

   - Your modem tickles bugs in the other modem, or vice versa.

   - Your modem and the other modem (which might or might not be a 56K
     modem) can not negotiate a common modulation or protocol. It takes
     more memory than most modems have to accommodate one or two 56K
     "standards" plus all the others (v.34 and below) and so essential
     fallback procedures might be lacking.

In theory, the modems should be able to recover from such situations
automatically, and agree upon a lower modulation and connection speed. In
practice, sometimes the modems become "frozen" or disconnect entirely. The most
common complaint is that the modem makes the connection, but there is only a
"blue screen" on the other end. That is, the modems are connected, the local
modem reports carrier, but no characters are transmitted.

Performance is a totally separate question, and generally hinges upon the
specific pair of modems and the connection between them.
-------------------------------------------------------------------------------

23 My Arrow Keys Don't Work

Newsgroups: comp.protocols.kermit.misc
Date: Mon Apr 24 10:24:29 1995
From: Frank da Cruz <[e-mail]>
Subject: Re: arrow keys and www?
Organization: Columbia University

In article <3n2s56$[e-mail]>,
Gideon Weisz <[e-mail]> wrote:
>
> This has to be a very simple problem, so apologies in advance, but I
> am stuck.  In www, using lynx, with mskermit 3.14 and vt220 (and
> HEBREW macro) the arrow keys do not work right.  To move among
> highlighted links, one is supposed to use the up/down arrows and to
> move among levels the left/right keys.  However, if I use
> right-arrow, I get "do you wish to send a comment"; if I use
> left-arrow it is taken as a command to download down-arrow moves me
> up! (up the screen to the last highlight).
>

Kermit is emulating a real VT220 terminal.

The VT220 cursor (arrow) keypad can be in one of two modes: cursor mode and
application mode.  These keys send different escape sequences depending on
which mode they are in.  When a VT220 is turned on (and when Kermit is
started), the arrow keys are in cursor mode.

By default (that is, unless you give SET KEY commands to change things), MS-DOS
Kermit uses the IBM keyboard arrow keys as the VT220 arrow keys.  Each key has
a "verb" assigned to it:

  Up arrow      \Kuparr
  Down arrow    \Kdnarr
  Right arrow   \Krtarr
  Left arrow    \Klfarr

These verbs track the cursor keypad mode automatically, and send the following
escape sequences:

               Cursor Mode   Application Mode

  \Kuparr        CSI A           SS3 A
  \Kdnarr        CSI B           SS3 B
  \Krtarr        CSI C           SS3 C
  \Klfarr        CSI D           SS3 D

where CSI is ESC followed by left bracket ([) on a 7-bit connection or decimal
155 on an 8-bit connection, and SS3 is ESC followed by O (uppercase letter O)
on a 7-bit connection and decimal 143 on an 8-bit connection.

How does the cursor keypad mode change?  The host can change it by sending
special escape sequences, or you can change it yourself by using the command:

  SET TERMINAL ARROW-KEYS { CURSOR, APPLICATION }

So why do the arrow keys not work in Lynx?  Or, in general, in any particular
application:

   1. Because the application expects the keypad to be in one mode when it
      is in the other mode.  This is a deficiency on the part of the
      application.  Applications should never ASSUME which mode the cursor
      keypad is in, but rather, they should PUT the keypad in the desired
      mode, or else they should accept arrow-key codes from either mode.
      Workaround: tell Kermit to SET TERM ARROW CURSOR (or APPLICATION).

   2. Because of a terminal-type mismatch.  Lynx, in particular, does not
      seem to use the termcap database (it uses only terminfo), and so
      therefore might not understand Kermit's VT220 or VT320 terminal type
      (this kind of confusion typically occurs when a terminal type is in
      the termcap database but not the terminfo one, and therefore works
      with EMACS or vi, but not with Lynx).  Solution: tell Kermit to SET
      TERM TYPE VT100 and also tell the host your terminal type is VT100,
      before starting Lynx, and ask you system administrator to add
      missing terminfo entries.

   3. Because of a character-size mismatch.  If you have been using a
      VMS-based VT220 or VT320 fullscreen application (such as ALEPH, EVE,
      etc), you might find that your arrow keys are sending 8-bit codes
      rather than 7-bit codes, and then when switching to another
      application like Lynx, the new application might not understand the
      8-bit codes.  Again, this is a deficiency of the application.
      Workaround: tell Kermit to SET TERM CONTROLS 7.

I put MS-DOS Kermit into Hebrew mode, accessed the ALEPH software, tried the
arrow keys and they worked OK.  Then I left ALEPH and started Lynx and got the
same symptoms you reported.  The three steps above fixed the problem.

[NOTE: In Kermit 95, the arrow keys, along with all other keys, are set up
automatically whenever you give a SET TERMINAL TYPE command.]

- Frank
-------------------------------------------------------------------------------

24 MS-DOS Kermit under Windows Can't Find My Port
Q: We use Kermit 3.14 very heavily on our campus. From DOS everything works
great. From MS-Windows 3.x, however, sometimes it works but often our users
will get a message like:

  Unknown hardware for port, using BIOS...

or:

  Cannot use RTS/CTS on non-UART port

A: First, let's assume that your COM port is not, in fact, an internal
"controllerless" modem, such as a Winmodem or RPI modem -- you can't use these
with MS-DOS Kermit or, for that matter, with any non-Windows application or in
any operating system other than Microsoft Windows.  See the sections on RPI
modems and Winmodems for more information about this.

Windows and/or Windows communications programs tamper with the PC BIOS, where
Kermit goes to find out what ports are available and what their addresses (and
IRQs) are.  The solution to this problem is to supply this information to
Kermit yourself.

Here is a macro you can use to set your port under Windows.  MS-DOS Kermit 3.14
is required.

  define PORT -
    if not = \v(argc) 2 end 1 Port number required, -
    if not = 0 \findex(:\%1:,:1:2:3:4:) forward PORT\%1, -
    end 1 \%1 - bad port number, -
    :PORT1, set com1 \x03f8 4, set port 1, end \v(status), -
    :PORT2, set com2 \x02f8 3, set port 2, end \v(status), -
    :PORT3, set com3 \x03e8 4, set port 3, end \v(status), -
    :PORT4, set com4 \x02e8 3, set port 4, end \v(status)

Put this macro definition in your MSCUSTOM.INI file and then just tell Kermit
"port 1", "port 2", "port 3", or "port 4" instead of "set port 1", etc, and
everything should work as expected.

IMPORTANT: The addresses and IRQs are the most common ones, but they are not
going to work on every machine.  PS/2s have different addresses and IRQs for
COM3 and COM4.  Many add-on cards -- especially internal modems -- might use
different IRQs altogether, like 5.  Again, see KERMIT.BWR for the gruesome
details.

Another user found that the following PORT macro also worked satisfactorily:

  define PORT -
    if not = \v(argc) 2 end 1 Port number required, -
    if not = 0 \findex(:\%1:,:1:2:3:4:) forward PORT\%1, -
    end 1 \%1 - bad port number, -
    :PORT1, run {MODE COM1:19,N,8,1}, set port 1, end \v(status), -
    :PORT2, run {MODE COM2:19,N,8,1}, set port 2, end \v(status), -
    :PORT3, run {MODE COM3:19,N,8,1}, set port 3, end \v(status), -
    :PORT4, run {MODE COM4:19,N,8,1}, set port 4, end \v(status)

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

25 If I Have an Error Correcting Modem Why Do I Need Kermit Protocol?
"If modern modems are capable of hardware error correction and compression,
isn't it redundant and inefficient to continue to use file-transfer protocols
like Kermit and ZMODEM that provide the same services?"

This is a common misconception, and, unfortunately, one that is promoted by
many of the modem makers themselves (e.g. when you read about protocols in the
modem manuals).  The modem makers (some of them) might excel at what they do,
but they are generally not experts on computers and software.  For example, the
following appears in a current modem manual:

    Generally, the most efficient file-transfer operations are achieved
    when the EC modem does the error checking in hardware, and the
    file-transfer protocol does not duplicate this effort. The YMODEM-G
    file-transfer protocol provides this level of service. This protocol
    was written for use with high-speed, error-control modems. This
    protocol does not provide any error-detection or recovery capability.

But it is not true that protocols like YMODEM-g (or, as is often suggested by
newcomers to modem communication, no protocol at all) are the best to use with
error-correcting modems.

That's because errors can also occur (and often do) outside the modem-to-modem
connection.  The most common causes are lack of sufficiently effective DCE/DTE
flow control and resulting buffer overflows in the receiver; unbuffered UARTs
that can't be serviced fast enough by a busy or slow CPU; interrupt conflicts
(including characters lost due to having interrupts turned off by other
drivers, e.g. disk-caching programs), and on and on -- things that are beyond
the modem's control.

Second, you don't always know that your error-correcting modem will make a
successful MNP or V.42 connection with the other modem.  The two modems might
have mismatched capabilities or there might be a "failure to negotiate" the
capabilities they do have.  Would you want to use different file transfer
methods depending on the type of connection negotiated by the modems?

Third, the communication channel outside the modems might not be fully
transparent.  For example, it might chop off the 8th bit of each byte, or it
might filter out certain characters, or use them for special purposes rather
than treating them as data.  This is common with terminal servers and other
types of communications front ends.

Fast protocols like Zmodem and modern Kermit impose little additional overhead,
and that small amount of overhead is well worth the savings in failed or
corrupt transfers, which are inevitable when using non-recovering methods in
situations like the ones described above.

But even more fundamentally: you can't know in advance that there will be no
errors.  So using a file transfer procedure without error recovery is silly,
because if there are errors, you'll have to start all over again.  It's like
not buying fire insurance for your house because you think it is fireproof.

Finally, what happens when the connection is broken?  Say, after transferring
99 megabytes of a 100-megabyte file?  Error-correcting modems can't stop wires
from being cut or pulled out, nor can they prevent power failures or keep
computers or applications from crashing.  So again, you need a good error
recovery protocol.  Both Zmodem and Kermit can pick an interrupted transfer up
from the point of failure.
-------------------------------------------------------------------------------

26 How Do I Use 'SET KEY' with PC F-Keys, etc, in UNIX or VMS C-Kermit?
The C-Kermit 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 subsequent
years, this type of access was largely replaced by terminal servers, but there
was 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...

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

   - Does it require special privilege to execute?

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

   - 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.
-------------------------------------------------------------------------------

27 How Can I Exit from C-Kermit without Hanging Up?
Many people want to be able to make a dialout connection with UNIX C-Kermit,
but then use some other software on the connection that C-Kermit made.  For
example, they want to use C-Kermit as their SLIP or PPP dialer.  But they
quickly find that when they exit from C-Kermit, that the connection is gone
before they can start the other application.

It is a fundamental property of UNIX (and VMS, and Windows 95 and NT, and most
other modern operating systems) that when a process exits, then every file that
was opened by that process is automatically closed by the operating system.  In
most cases, closing a terminal device (such as a dialout serial port) hangs up
the modem (by turning off the DTR signal).  There is nothing the process can do
about it.

However, many workarounds are possible.  Here are just a few:

   - If your C-Kermit version supports the REDIRECT command, use it to
     start the desired application (e.g. "redirect pppd").  The REDIRECT
     command runs the given application with its standard input and output
     redirected to the communications channel opened by C-Kermit's most
     recent SET LINE or SET HOST command.

   - Tell C-Kermit to SET MODEM HANGUP-METHOD RS232, and then configure
     your modem to ignore DTR (not recommended).  "Using C-Kermit", 2nd
     Ed., p.86.

   - When opening the device first from another application, feed the file
     descriptor for the device to C-Kermit using the "-l" (lowercase
     letter L) command-line option followed by the numeric file
     descriptor, e.g.  "kermit -l 6".  Then Kermit will not attempt to
     open the device, nor to change its characteristics, nor to close it
     when done, and when Kermit exits, it will still be available to the
     invoking process.  "Using C-Kermit", 2nd Ed., p.469.

   - When opening the device with C-Kermit, find out the file descriptor
     of the open device (it is given by C-Kermit's \v(ttyfd) variable) and
     then run ("!")  your other program from the C-Kermit prompt, feeding
     it the file descriptor, e.g. through shell redirection or a command
     line option (the method depends on the other program, the
     capabilities of the shell, etc).  "Using C-Kermit", 2nd Ed., p.356

   - In UNIX, after Kermit makes the connection, type "show comm" to find
     out the filename of the lock file.  Then suspend Kermit, delete the
     lock file, then start the other program and tell it to open the same
     tty device.

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

28 What Is SuperKermit?
When the Kermit protocol was first developed in 1981, it had short packets and
did not use sliding windows, but the design was deliberately extensible to
allow for the addition of these and many other features later.

A couple years later, when we defined the protocol for long packets and sliding
windows, somebody somewhere started calling it "SuperKermit".  Really, there's
no such thing -- Kermit is Kermit.  It's an extensible protocol in which the
two file transfer partners negotiate automatically about what features they
have in common and agree to use them.

All modern Columbia Kermits support long packets and sliding windows (except
IBM Mainframe Kermit does not "do windows" because it exists only in a
half-duplex environment, whereas full duplex connections are needed for sliding
windows).  They also support compression, single and locking shifts (for moving
8-bit data efficiently through 7-bit communication channels), file-transfer
recovery, dynamic packet lengths and timeouts, and all sorts of other advanced
and serious features that whoever coined the term "SuperKermit" never dreamed
about.

Usually when BBSs or non-Columbia communication programs refer to "SuperKermit"
they mean a 1985-vintage implementation of the Kermit protocol that implements
a primitive and not very robust form of sliding windows, usually not in
combination with long packets.  However, if it is properly implemented, it
should interoperate successfully with any other Kermit implementation, no
matter how advanced or how minimal.  That's the whole point of Kermit protocol.
-------------------------------------------------------------------------------

29 Is Kermit Software Year-2000 Compliant?
Kermit software is not, for the most part, date dependent.  It makes
connections, performs terminal emulation (in those versions that include this
feature), transfers files, translates character sets, and, in most cases,
executes scripts regardless of the date.

"Year 2000 compliance" depends on the Kermit program and the underlying
platform.  If the operating system, file system, BIOS, hardware, and/or other
critical component is not ready for the year 2000, then most likely Kermit
isn't either, since it relies on the underlying OS and hardware for date / time
service.

The primary relevance of this question to Kermit software is whether
post-millenium file dates are recognized, transmitted, received, and reproduced
correctly during the file transfer process.  This consideration, in turn,
applies only to those Kermit versions that implement the optional "Attribute
Packet" feature.  These include C-Kermit, Kermit 95, MS-DOS Kermit, Kermit-370,
and PDP-11 Kermit, all of which are coded to write and read 4-digit years in
all protocol messages.  (Note that these programs also include a command to
disable file-date processing altogether, in the event that it does not work as
intended.)

If post-millenium dates are not processed correctly, file transfer will still
take place, but the creation or modification date of the received file might be
incorrect.  An exception would be if the "file collision update" feature is
being used to prevent unnecessary transfer of files that have not changed since
the last time a transfer took place; in this case, a file might be transferred
unnecessarily, or it might not be transferred when it should have been.
Correct operation of the update feature depends on both Kermit programs having
the correct date and time.

Another exception would be when using the /BEFORE: or /AFTER:  file-selection
switches during file transfer.  If dates are not processed correctly, files
could be skipped that should have been sent, or vice versa.

If an incoming file is stored with the wrong date, for example with a year of
1900 rather than 2000, this might affect backup, archival, and cleanup
procedures, perhaps resulting in unwanted file deletion.  For example (in VMS):

$ delete/before="-90-" *.*;*
$ dir/since=1-jan-2000
$ purge/before=login *.*

Of secondary importance are the time stamps in the transaction and/or debug
logs, and the date-related script programming constructs, such as \v(date),
\v(ndate), \v(day), \v(nday), and perhaps also the time-related ones, \v(time)
and \v(ntime), insofar as they might be affected by the date.  Note: the
aforementioned script programming constructs are available only in C-Kermit,
Kermit 95, and MS-DOS Kermit.  The \v(ndate) is a numeric-format date of the
form yyyymmdd, suitable for comparison and sorting: e.g. 19970208 or 20011231.
If the underlying operating system returns the correct date information, these
variables will have the proper values.  If not, then scripts that make
decisions based on these variables might not operate correctly, but then
neither will any other date-related software on your computer.

Here is the current situation for the most popular Kermit software products.
The minimum version known to be Year-2000 compliant is shown.  We make no
claims whatsoever about the underlying operating systems or file systems.  The
situation with Kermit programs not listed here is at present unknown.

   - MS-DOS, PC-DOS, DR-DOS:
     MS-DOS Kermit: Version 3.15 or later required.


   - Windows 3.0/3.1/3.11:
     MS-DOS Kermit: Version 3.15 or later required.  IMPORTANT: MS-DOS
     Kermit is not supported under Windows 95, Windows 98, Windows NT,
     Windows 2000, or OS/2.  The supported Kermit software for those
     platforms is Kermit 95.


   - Windows 95 and 98:
     Kermit 95: Version 1.1.3 or later required (note that versions
     1.1.10, 1.1.11, etc, are later than 1.1.3; thus, for example, version
     1.1.17 is Year-2000 ready).


   - Windows NT and Windows 2000:
     Kermit 95: Version 1.1.3 or later required.


   - OS/2:
     Kermit 95: Version 1.1.11 or later required.


   - UNIX:
     C-Kermit: Version 6.0.192 or later required.


   - VMS:
     C-Kermit: Yes, all versions.  Kermit-32: unknown; Kermit-32 has not
     been supported since about 1987.  If you are using Kermit-32, please
     upgrade to C-Kermit.


   - Stratus VOS
     C-Kermit: Version 6.0.192 or later and VOS 12.3 or later required.


   - VM/CMS:
     CMS Version 13 and Kermit-370 Version 4.3.2 or later required.


   - MVS/TSO:
     Kermit-370 for TSO: Version 4.3.2 or later required.


   - MVS/ROSCOE:
     Kermit-370 for ROSCOE: Version 4.3.2 or later required.


   - MUSIC:
     Kermit-370 for MUSIC: Version 4.3.0 or later required.


   - CICS:
     Kermit-370 for CICS: Version 4.3.0 or later required.


   - RT-11:
     KRT for RT-11 and TSX+: Version 3.63 or later required.


   - RSTS/E:
     KRT for RSTS/E: Version 3.63 or later required.

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

30 Is There a Kermit Library?
Many software makers ask us for Kermit software in special forms that can be
embedded in their applications, to provide file transfer or other
communications functions to their customers.

But each software maker wants something different:

   - Connection establishment but no data transfer

   - Data transfer using pre-existing connection

   - Connection establishment and data transfer

   - File transfer only without "bells and whistles"

   - Scripting but not terminal emulation

   - Serial communication but not networking

   - Networking but not serial communications

   - Binary file transfer but not text

   - Greek character-set conversion but not Cyrillic

   - Access to shell escapes allowed

   - Access to shell escapes forbidden

   - A pretty display

   - No display at all

and on and on.  And they desire this functionality to be packaged as a link
library for this or that platform, a DLL, an OCX, a VBX, an OLE or OLE-2
object, an Active X control, a Delphi component, a Netscape Plugin, a Java
object, a Perl, Tcl, or Python extension, etc etc etc.  The combinations of
functionality and interface are many, and there is no way we can satisfy them
without warehouses full of programmers.

Consequently we recommend that software makers who wish to embed Kermit
functionality in their products (communications, scripting, file transfer,
terminal emulation, character-set translation, etc) license and use the
programs we already have available.

The "API" (Application Program Interface) is the command language.  It is more
fully expressive, precise, comprehensive, and portable than any other API that
could be designed (look at all the commands in C-Kermit or MS-DOS Kermit or
Kermit 95; each one is there for a reason).  As new releases of the Kermit
program come out, your product can be easily updated and will benefit from all
the new features, fixes, and speedups automatically.

The recommended method of embedding Kermit in another application is via
command-line invocation.  The Kermit command line can contain a selection of
simple commands, and it can also refer to more complex command files or scripts
composed by or included with your application.  Kermit can be configured to
create any kind of log you need, and it can return the status of its operations
in various ways that can be used by your application.

When you license Kermit software for embedding in your application, we are
happy to work with you to ensure it meets your needs.  And if Kermit protocol
transfers are important to you, then it should also be important to you to come
to the source -- we developed the protocol, we continue to improve it, we
believe in it, and we stand behind it.

Following this advice allows each party to concentrate on what they are good
at, rather than unnecessarily duplicating efforts and "reinventing the wheel".
You concentrate on your application; we'll do the communications.  We support
our software, you support yours, everybody is happy.
-------------------------------------------------------------------------------

31 How Do I Call up a Dialback Service?
A dialback service is one which you dial up to, provide some kind of
identification and/or authentication, such as a name and/or password, and then
it looks up your phone number in a database and calls you back.  It is a type
of security, based on having the phone numbers of all authorized callers, and
opening sessions for them only when they are calling from those numbers.

Suppose you were using a Hayes modem to make a call to a dialback service.  You
would do the following:

ATD7654321      (Dial the number)
CONNECT 14400   (Read the response)

Here you would have the identification / authentication dialog.  Now the
dialback service hangs up on you, and you must put the modem in answer mode:

NO CARRIER      (The connection is closed)
ATS0=1          (Tell the modem to answer the next call)

When the call comes in, the modem answers and you're on line.

But now you want to automate the process.  This is easily accomplished in
Kermit.  Let's use C-Kermit 6.0 to illustrate, since it has a new ANSWER
command.  Here is a simple script to do the job:

set modem type usr  ; or whatever
set port /dev/cua   ; or whatever
set speed 38400     ; or whatever
dial 7654321        ; dial the number
if fail stop

At this point, you would use INPUT and OUTPUT commands to accomplish the
identification / authentication dialog.  For example, if the dialback server
prompts you with USERNAME: and PASSWORD:, and your script had previously stored
these values in the variables \%u and \%p, respectively:

input 10 USERNAME:
if fail stop 1 No username prompt
output \%u\13
input 10 PASSWORD:
if fail stop 1 No password prompt
output \%p\13

Now you will need to hang up your end of the connection, and then wait for the
phone to ring:

hangup
answer 120
if fail stop 1 No callback

The ANSWER command conditions the modem for answering (ATS0=1 for Hayes and
compatible modems) and then waits the given number of seconds (120 in this
case) for the call to come in.  At this point, if the script is still
executing, you've got a connection.  You can give a CONNECT command, or execute
a login script, or whatever else you want to do.
-------------------------------------------------------------------------------

32 How Does the Numeric Keypad Work?

    This discussion applies to MS-DOS Kermit.  The situation with Kermit 95
    is slightly different: In Kermit 95, the Num Lock key can be mapped
    directly and the PC numeric keypad is mapped to the VT terminal numeric
    keypad by default.

MS-DOS Kermit reads scan codes from the PC BIOS (but if you are using Windows,
then all sorts of software layers are inserted between Kermit and BIOS, so
matters are somewhat more uncertain.

The BIOS reports one scan code for a numeric keypad key when Num Lock is on,
and a different code when Num Lock is off.  All that MS-DOS Kermit is doing is
reading the scan codes from (what it thinks is) the BIOS.

To use the PC's numeric keypad as if it were a VT terminal's numeric keypad in
MS-DOS Kermit, you must make the appropriate key assignments, since they are
not made by default.  By default, when Num Lock is not on, the keys have the
same assignments as the gray keys which have the same label (e.g.  Home, End,
Left Arrow, etc), for the benefit of 88-key keyboards.

To make the desired key assignments, you can use the VT300.INI file in the
KEYBOARD subdirectory of the MS-DOS Kermit directory:

take keyboard\vt300.ini

The pertinent commands from this file are:

set key \850 \kkp0        ; Keypad 0 (Numlock)   Keypad 0
set key \338 \kkp0        ; Keypad 0 (Normal)    Keypad 0
set key \847 \kkp1        ; Keypad 1 (Numlock)   Keypad 1
set key \335 \kkp1        ; Keypad 1 (Normal)    Keypad 1
set key \848 \kkp2        ; Keypad 2 (Numlock)   Keypad 2
set key \336 \kkp2        ; Keypad 2 (Normal)    Keypad 2
set key \849 \kkp3        ; Keypad 3 (Numlock)   Keypad 3
set key \337 \kkp3        ; Keypad 3 (Normal)    Keypad 3
set key \843 \kkp4        ; Keypad 4 (Numlock)   Keypad 4
set key \331 \kkp4        ; Keypad 4 (Normal)    Keypad 4
set key \844 \kkp5        ; Keypad 5 (Numlock)   Keypad 5
set key \332 \kkp5        ; Keypad 5 (Normal)    Keypad 5
set key \845 \kkp6        ; Keypad 6 (Numlock)   Keypad 6
set key \333 \kkp6        ; Keypad 6 (Normal)    Keypad 6
set key \839 \kkp7        ; Keypad 7 (Numlock)   Keypad 7
set key \327 \kkp7        ; Keypad 7 (Normal)    Keypad 7
set key \840 \kkp8        ; Keypad 8 (Numlock)   Keypad 8
set key \328 \kkp8        ; Keypad 8 (normal)    Keypad 8
set key \841 \kkp9        ; Keypad 9 (Numlock)   Keypad 9
set key \329 \kkp9        ; Keypad 9 (Normal)    Keypad 9

set key \334  \kkpminus   ; Keypad +             Keypad -
set key \2382 \kkpcoma    ; ALT Keypad +         Keypad ,
set key \851  \kkpdot     ; Keypad . (Numlock)   Keypad .
set key \339  \kkpdot     ; Keypad . (normal)    Keypad .
set key \4365 \Kkpenter   ; Keypad Enter         Keypad Enter

                          ; F1                   PF1 (default Kermit)
                          ; Use GOLD.COM to make Num Lock work as PF1/Gold.
set key \325 \kPF1        ; This works with WPGGOLD.COM.

set key \4399 \kPF2       ; Keypad /             PF2
set key \311  \kPF3       ; Keypad *             PF3
set key \330  \kPF4       ; Keypad -             PF4 Key

You need the GOLD TSR to make the Num Lock key work like the DEC Gold key.  The
GOLD TSR is found in the same directory as the VT300.INI file.

The rest of the commands in the VT300.INI file set up the function keys and
editing keys to be like the corresponding DEC VT220/320 keys.

But there is still one more piece to the puzzle.  As noted, the VT keypad can
be in one of two modes: numeric or application.  It is the responsibility of
the host application to send an escape sequence to put the keypad into the
appropriate mode before attempting to read keystrokes from it.  But some
applications fail to do that and simply ASSUME that the keypad is in the right
mode.  In many cases this assumption is wrong.  So MS-DOS Kermit has a command
that lets you force the keypad into the desired mode:

SET TERMINAL KEYPAD { APPLICATION, NUMERIC }

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

33 How to Get Rid of the "OK to Exit?" Prompt?
When I try to exit from Kermit it says:

A serial connection might still be active on com2.
OK to exit?

But the connection is closed!  How do I make this message and prompt go away?
It prevents scripts from running unattended.

Short answer:

    SET EXIT WARNING OFF

Long answer:  Kermit gives this message and prompt when given the EXIT command
(explicit or implied), or when told to change its communication device, and a
connection appears to be active on the current one.  On a serial device, this
means that the Carrier Detect (CD) signal is still present.  On a network
connection, it means that Kermit has not closed the connection and it does not
seem that Kermit's network partner has closed it either.

If you are using a modem, the best course is to fix it (or the cable) so CD
tracks the connection.  Kermit generally tries to do this itself, but sometimes
it is not possible due to switch settings in the modem.  See your modem manual
for details.

In some cases, however, the underlying operating system or device driver does
not provide Kermit with good information.

If you can't fix the modem or cable to report the connection status properly,
use SET EXIT WARNING OFF to tell Kermit to ignore the apparent connection
status upon EXIT.
-------------------------------------------------------------------------------

34 How to Tell Kermit to Ignore Dialtone?
Sometimes the telephone being used to place a modem call does not present a
dialtone that the modem recognizes.  This usually happens with PBXs, ISDN
phones, etc.  But Kermit programs generally tell the modem to wait for dialtone
before dialing.

To find out how to get around this feature, you'll need to look at your modem
manual.  If it's a Hayes compatible (i.e.  uses the AT command set), then it's
probably a matter of changing the "X" value in the init string.  Most Kermit
init strings use X4, in order to get the widest possible selection of result
codes.  In many modems, X3 is used to select "blind dialing" (i.e. without
waiting for dialtone), but this also sacrifices the ability to get a BUSY
response, and therefore to redial automatically if the line is busy.  Hopefully
your modem has finer-grained selections.

In C-Kermit or Kermit 95, a good way to change the X value in the init string
is, after you set your modem type:

  set modem type xxxx
  set modem command init \freplace(\v(m_init),X4,X3)

This assumes your modem type is "xxxx", and its init string contains X4.

In MS-DOS Kermit, just edit the dialing script.
-------------------------------------------------------------------------------

35 Where is the Dialing Script for My Modem?
C-Kermit and Kermit 95 do not use dialing scripts; their modem support is built
in.  To see a list of the modems supported, type:

set modem type ?

at the prompt.  If your modem is not listed, then (a) maybe one of the other
modem types will work ("generic-high-speed" is usually a good guess), and (b)
you can install your own modem definition as described on pages 90-92 of Using
C-Kermit; this, of course, requires knowledge of how to operate your modem,
which comes from reading the manual (if any) that came with it.

MS-DOS Kermit, on the other hand, uses dialing scripts, one per modem type.
The ones we have are in the MODEMS subdirectory of your MS-DOS Kermit
directory.  If you don't see one there for your modem, it is easy to adapt one
of the existing ones.  Just use a text editor to change the modem-specific
commands to the ones for your modem; consult your modem manual to find out what
its commands are.

In either case, if you have added support for a new modem, please send your new
definitions or script back to us, along with a complete description of your
modem's manufacturer, name, model designation, and features (modulation, error
correction and compression protocols, etc), so we can make them available to
others.
-------------------------------------------------------------------------------

36 I'm Having Terminal Emulation Problems with C-Kermit
C-Kermit on UNIX, VMS, etc, does not perform terminal emulation at all; nobody
ever claimed it did.  Instead, it is a semitransparent (or, if you make it so)
a fully transparent communications pipe between the remote computer or service
and your local terminal, terminal emulator, terminal window, or console, which
provides the terminal functions.  Thus, it is similar to Telnet, cu, tip, "set
host" in VMS, etc, but with added functionality (file transfer and management,
character-set translation, scripting, etc).

If you experience fractured screens, you probably have a mismatch between the
type of terminal or emulator you are running C-Kermit and the type the remote
host or service thinks you have.  Solution: let the host know what type of
terminal you really have.  For example, in Linux it would be ANSI or SCOANSI.
In an HPTERM window, it would be HPTERM.  In an AIX window, it would be
AIXTERM, etc.

If your arrow and function keys don't work, then you must configure your
terminal or emulator to have these keys send what the host or application
expects them to send.  The method for doing this depends on your terminal or
emulator.  For example, when using xterm or another X-based terminal window,
use xmodmap to configure your keyboard.  C-Kermit itself can't be used for this
(even though it has a SET KEY command) because it can't "see" the special keys
(arrow keys, function keys, editing keys, etc).

If host-directed transparent printing doesn't work, this is a deficiency in
your terminal or emulator and has nothing to do with Kermit.  However, if you
have the ability to change the host application, then you can use C-Kermit's
autodownload and/or APC features to accomplish the same thing.  See the manual
for details.
-------------------------------------------------------------------------------

37 Divide Overflow in MS-DOS Kermit
If you find that MS-DOS Kermit is giving you "Divide Overflow" errors after an
OS or hardware upgrade, or on a new PC:

   - If your PC is running Windows 95, Windows NT, or OS/2, then you
     should run the 32-bit version of Kermit for those platforms Kermit
     95.  This is the only Kermit software that is recommended or
     supported for Windows 95, Windows NT, or OS/2.


   - If your PC is running DOS (MS-DOS, PC-DOS, DR-DOS, etc) as its base
     operating system (and perhaps Windows 3.x on top of that), then
     upgrade your version of MS-DOS Kermit to the current release, MS-DOS
     Kermit 3.15

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

38 Problems Using XYZMODEM External Protocols in C-Kermit

From: [e-mail] (Frank da Cruz)
Newsgroups: comp.unix.aix
Subject: Re: Kermit Using External Protocols - XYZ modem
Date: 21 Nov 1997 14:39:12 GMT

In article <[e-mail]>,
Stephen Tait  <[e-mail]> wrote:
: I am having problems sendig a file from AIX 3.2/4.X over a modem to
: a DOS BBS system using Kermit and XMODEM. Using Kermit I dial the
: BBS, connect, enter login and password and the file name that I want
: to send to it. At this point the DOS BBS informs me to select a
: protocol:
:
: - for PCPLUS (DOS to DOS), I select PgUp, X for XMODEM, enter the
: filename and it all works fine.
:
: - for AIX, with Kermit 6.0.192 and XYZMODEM protocols from OMEN
: Technology site, I cannot send the file to the BBS because I don't
: know what the equivilant command for "PgUp"(send) in PCPLUS is in
: Kermit.  Also I have used scripting to autologin to the BBS send the
: file using the (sx) XMODEM command but all I get is a hung
: terminal:.(
:
: I have tried Kermit Support and they tell me, I quote "Omen Tech
: versions of sz rz ... do not allow redirection of stdio.You will
: need to find public domain versions of these protocols if you want
: to use them or purchase appropriate versions from Omen Tech."
:
: I find this hard to believe, and if somebody knows anything that can
: be of help I would be extremely gratefull:.)
:
By popular demand, C-Kermit 6.0 includes the ability to run external
protocols.  X-, Y-, and ZMODEM are external protocols to Kermit.
External means external, not built-in, and that they come from
elsewhere, not from the Kermit Project; you have to find your own
source for external protocol modules.

You are no doubt using Kermit to run your external protocols because
the sz/rz/sx/rx/sb/rb programs that you have will not make connections
for you.  They were never designed or intended to do that.

Furthermore, as you have learned, these programs do not meet the
fundamental requirement for an external protocol module: to transfer
files over standard input/output, which Kermit can then redirect over
the communications connection that it has made.  That's because,
starting in about 1988, the sz/rz/sx/rx/sb/rb programs were changed to
prevent this.  In other words, they are not designed or intended to be
used as external protocols.  This has nothing to do with C-Kermit or
the Kermit Project.

So you have five choices:

 1. Use Kermit protocol instead of X-, Y-, or ZMODEM.  No worries with
    getting software from different makers to mesh.

 2. Use crz/sz whch is designed to be used with Kermit and other
    programs.  The crzsz.zip file is available from many places
    including www.omen.com.

 3. License modern versions of sz/rz/sx/rx/sb/rb from Omen Technology
    that can be used as external protocols.

 4. License a monolithic program such as Pro-Yamm from Omen Technology
    so you won't need to run C-Kermit at all.

 5. Something entirely different from 1-4.

Frank da Cruz
The Kermit Project
Columbia University
http://www.columbia.edu/kermit/

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

39 Tone Dialing Changes to Pulse after First Digit
Some modems have a feature called adaptive dialing.  When they are told to dial
a number using Tone dialing, they check to make sure that dialtone has gone
away after dialing the first digit.  If it has not, the modem assumes the phone
line does not accept Tone dialing and so switches to Pulse.

When dialing out from a PBX, there is almost always a secondary dialtone.
Typically you take the phone off-hook, get the PBX dialtone, dial "9" (or other
number) to get an outside line, and then get the phone company's dialtone.  In
a situation like this, you need to tell the modem to expect the secondary
dialtone.  On Hayes and compatible modems, this is done by putting a "W" in the
dial string at the appropriate place.  For example, to dial 9 for an outside
line, and then 7654321, use ATDT9W7654321.  In C-Kermit and Kermit 95, this is
accomplished with:

SET DIAL PBX-OUTSIDE-PREFIX 9W

(replace "9" with your PBX's outside-line prefix).
-------------------------------------------------------------------------------

40 How to Transfer Files with the HP-48?
Here's a brief summary:

Put the HP-48 in Kermit server mode.  Set up the Kermit client like this:

  SET MODEM TYPE DIRECT   ; (C-Kermit or Kermit 95)
  SET PORT COM1           ; (Or other communication port)
  SET SPEED 9600          ; (Serial port speed)
  SET CARRIER-WATCH OFF   ; (Don't require carrier)
  SET FLOW NONE           ; (Don't use flow control)
  SET PARITY NONE         ; (8 data bits, no parity)
  SET BLOCK 3             ; (if desired, or 2)
  SET CONTROL PREFIX ALL  ; (Necessary in Kermit 95)

For file transfer, use binary mode unless you are exporting or importing HP-48
objects:

  SET FILE TYPE BINARY

To transfer files:

  SEND filename           ; Send file(s) to the HP-48
  GET filename            ; Get file(s) from the HP-48

To change directory on the HP-48:

  REMOTE HOST { relative_directory_name } EVAL

To shut down the HP-48 Kermit server:

  FINISH

If file transfers fail, try:

  SET SEND TIMEOUT 20     ; (Or other number of seconds)
  SET SEND PAUSE 100      ; (Or other number of milliseconds)

CLICK HERE for further information.
-------------------------------------------------------------------------------

41 I'm Having Trouble with F-Keys
Remember, your PC is not a real terminal.  In most cases, the PC has a
different kind of keyboard than a real terminal.  For example, a DEC VT100 has
no F-keys, but the PC has 10 or 12 of them.  However, a DEC VT220 or VT320 has
20 F-keys; the PC still has only 10 or 12.

    If your complaint is that you have Kermit set to VT100 or VT102
    emulation and the F-keys don't work, that's because the VT1xx terminals
    do not have F-keys.  They do, however, have PF keys 1 through 4, and
    these are assigned by default to the top row of the numeric keypad.  If
    you need F-keys, you probably need VT220 or higher, not VT100.

For your PC's F-keys to work like those of the corresponding terminal, Kermit
must map the PC's F-keys to the terminal's.  If the terminal has more F-keys
than the PC, you might have trouble finding the extra ones (such as F13 through
F20).

In MS-DOS Kermit, F-keys must be set up with SET KEY commands.  A command file,
VT300.INI, is supplied for this purpose in the KEYBOARD subdirectory of the
Kermit directory.

In Kermit 95, F-keys are defined automatically for each terminal type as
described in the Kermit 95 manual.

    IMPORTANT: MS-DOS Kermit and Kermit 95 use difference keycodes in their
    SET KEY commands.  You can make Kermit 95 read an MS-DOS Kermit key
    mapping file by first telling it to SET MSKERMIT KEYCODES ON.

Excess F keys are generally assigned to PC Alt-(10-minus-xx).  For example, DEC
F13 is Alt-F3 on the PC; DEC F20 is Alt-F20.

Shifted F keys are generally used as User-Defined Keys (UDKs).  Excess UDKs
(such as Shift-F13) are entered as Alt-Shift-F13 (etc).

If you don't like Kermit's default F-key assignments, you can change them with
SET KEY (or, in K95 only, SET TERMINAL KEY).

What does an F-key send?  Normally we assign "Kverbs" to each F-key.  For
example, when Kermit is emulating a VT220 or higher, the F6 key is assigned the
verb \KdecF06 (DEC F6), which means "Send what the DEC F6 key sends".  This
doesn't tell you exactly what characters are sent, but that's the point, since
many of the DEC key groups can be in different "modes" (set by the host
application or by the user), in which they send different sequences.  Kermit
tracks the mode and "does the right thing".

If you want the F-key to send something other than what the appropriate Kverb
sends, you can make a specific assignment.  For example:

set key \375 \{27}@7

In which we make the F8 key send a nonstandard sequence (ESC At-Sign 7) used by
host-based WordPerfect.

One of our most common tech support questions is "My host application menu says
to press F7 but when I do that nothing happens".  If you have read this far,
you can probably figure out the answer for yourself:

   - Is Kermit's terminal type set to what the host thinks it is?

   - If you are using MS-DOS Kermit, have you given a TAKE command for the
     appropriate key mapping file for your terminal?  (Not necessary in
     K95.)

   - What does SHOW KEY say is assigned to the key in question?  For
     example, for F7, type "show key" at the Kermit prompt, and then in
     response to the "Press key:" prompt, press the F7 key.  It tells you
     the keycode and the assignment:

  [C:\k95\KEYMAPS\] K-95> show key
   Press key:
   Key code \374 F7 (default) => Verb: \Kdecf07
  [C:\k95\KEYMAPS\] K-95>

   - If the assignment does not appear to be correct, use SET KEY to
     change it.

   - In unusual cases, the host application might want the F-keys to
     mapped to special sequences, which are different from what the real
     terminal would send.  In cases like this, you have to find out from
     the application's documentation or help desk what those sequences
     are.  Once you have this information, you can create your own custom
     keymap for this application.

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