Columbia Kermit/kermit.zip/archives/msr313src.zip/mskerm.bwr

Text File | 1994-05-12 | 136KB | 2,752 lines

File MSKERM.BWR           MS-DOS KERMIT 3.13 "BEWARE FILE"                  May 1994

               BUGS, LIMITATIONS, HINTS & TIPS

This file last updated: Thu May 12 08:34:08 1994

This file discusses common problems installing or using MS-DOS Kermit and
presents solutions or workarounds in many cases.  It applies to version 3.13
of MS-DOS Kermit for the IBM PC family and compatibles.  See KERMIT.HLP
(MSKERM.HLP) for copyright information, terms and conditions, and a summary of
MS-DOS Kermit commands.

Major sections of this file are marked by an equal sign (=) on the left margin.

The user manual for MS-DOS Kermit 3.13 is the book "Using MS-DOS Kermit",
Second Edition, by Christine M. Gianone, published by Digital Press, Bedford,
MA (1992), order number EY-H893E-DP.  Available in book and computer stores,
or order from Columbia University at 1-212-854-3703.  Changes since the
book was published are described in KERMIT.UPD (MSKERM.UPD).

Please consult "Using MS-DOS Kermit" and this file before contacting Kermit
technical support staff.  Report problems via e-mail to [e-mail] on
the Internet or to [e-mail], or call [phone], or by Fax to
[phone], or write to Kermit Distribution, Columbia University Academic
Information Systems, 612 West 115th Street, New York, NY 10025, USA.

= PATCHES

The following patches correct problems noted since Version 3.13 was released:

 1. OPTIONAL: Specify 132-column video mode for Orchid Designer Professional
    video adapter.
 2. Make SHOW PROTOCOL display handshake correctly;
    fix \KdgC3 and \KdgC4 keyboard verbs.
 3. Correct insert/delete character when at right margin.
 4. Correct CONNECT-mode status line to stay off if SET to OFF.
 5. Correct invocation of DEC-MCS character set.
 6. Correct selective-erase-in-line.
 7. Correct two graphics mode errors.
 8. Make ENQ response immediate on network connections.
 9. OPTIONAL: Permit trying 132-column text display in Microsoft Windows.
    Remove semicolon in left margin after Patch 9 comment to enable this patch.
    If Windows blows up with this patch enabled, put the semicolon back.  In
    many observed cases, Windows becomes deeply disturbed when the application
    attempts to change video modes, but in others it works OK.  It depends on
    whether the particular video adapter hardware is supported and fully
    understood by the Windows video driver, plus other environmental factors
    (TSRs, drivers, etc etc).
10. Allow TCP/IP domain server reply to come from a different address than the
    one to which the request was sent.
11. Avoid creating a long packet when long packets have not been negotiated
    and the last packet character is prefixed control code.
12. In Data General transparent printing, recognize binary and ASCII forms of
    '2' and '3' in command arguments.
13. Correct memory corruption resulting from erase-to-end-of-line operations
    for double-width characters on a 132-column screen.
14. OPTIONAL.  For Digital PATHWORKS version 4.0 and later only, enable use
    of LAT in Windows and in expanded memory.  To activate the patch remove
    the leading semicolons from the five lines after the Patch 14 comment.
    Not recommended because of the severe contention over, and relatively
    narrow bandwidth of, the EMS mapping mechanisms, which make EMS not
    terribly well suited for realtime communications applications.
15. Correct unprefixing of 8-bit control codes during Kermit packet operations.
16. Ensure Packet-Driver signature is examined to full length.
17. Correct erase-to-end-of-screen when on status (bottom) screen line.
18. Arcnet ODI address byte location correction.
19. Correction to patch 18, must be used if patch 18 is used.
20. Correct erase cursor to end of line when on status line.
21. Include status line in TELNET session screen save/restore.

Other problems corrected since original 3.13 release:

 1. Patch-file-finding test in MSKERMIT.INI was wrong.
 2. KERMIT.PIF file internally referred to MSTIBM.EXE rather than KERMIT.EXE.
 3. USR Sportster dialing script (SPORT.SCR) contained a syntax error
    ("W1" should not be in the initialization string).
 4. COLS80.BAT included an invocation of a specific SVGA driver, rather than
    the normal instructive ECHO commands.

= INCOMPATIBILITIES BETWEEN MS-DOS KERMIT 3.13 AND EARLIER VERSIONS:

 1. The TERMINALR/S macro capability is replaced by host-initiated change
    of screen writing direction (details in KERMIT.UPD).  As a consequence
    of this, host-based WordPerfect won't be able to load your key settings
    (see next section).  Any other host software that sent the TERMINALR/S
    sequences will also need to be converted in similar fashion.  ALL-IN-ONE
    can make your screen look backwards, etc etc.  See the APC section in
    KERMIT.UPD (MSKERM.UPD) for further details.

 2. STATUS command removed.  There is no longer any way to display all of
    MS-DOS Kermit's settings on a single screen.  Now use the SHOW command to
    display categories of settings: SHOW TERMINAL, SHOW COMMUNICATIONS, SHOW
    PROTOCOL, etc.

 3. STATISTICS, which displays file transfer statistics, has been added as a
    top-level command, for compatibility with C-Kermit.     So if you were used
    to typing "stat" to get a screenful of settings values, now you will get
    file transfer statistics instead.

 4. Alt-n was previously bound by default to the \Knethold verb.  It is now
    bound to the new \Knextsession verb.  \Knethold (used on TES, EBIOS,
    NASI/NACS, and various other PC networks or asynchronous communication
    servers) has been moved to Alt-z.

= WORDPERFECT

WARNING: WordPerfect 6.0 comes with a fax program, FAXDIR.EXE, that runs
as a TSR.  Reportedly, this program fiddles with the communication port while
other communication applications (such as Kermit) are running.  If you
experience strange effects -- like hangups or sudden unexplained changes of
interface speed -- while running Kermit with FAXDIR loaded, remove FAXDIR.

WARNING 2: The WordPerfect Office Shell is not a true multitasking
environment.  It simply brings the "hot-key'd" program to the foreground and
deactivates the other programs.  Thus, you can't use it to accomplish Kermit
file transfers in the "background", etc.  Even more important, you cannot use
it to put Kermit TCP/IP connections on hold; the result will be a hung system,
or worse.  Explanation: Kermit registers its address with the network board
driver; the driver deposits incoming material at the given address.  If WP
Shell has swapped Kermit out of memory and replaced it with another
application, the board driver will write network packets all over the new
application's memory, with unpredictable (but never good) results.

To make host-based UNIX WordPerfect work with MS-DOS Kermit 3.13, follow these
directions (courtesy of Chris Thompson at Vanderbilt University; presumably
similar steps can be followed for the VMS version):

. Go into the directory where the terminal definitions are stored (in my case
  of WP 5.1 for AIX, it was /usr/wp51/shlib), and execute "wpterm" (it usually
  requires you to be super-user).

. A screen containing all the terminal definitions will appear.  Highlight the
  current Kermit terminal definition and hit Create.

. It will ask "Model new definition after Kermit?"  Answer yes.

. It will then ask for a new name for your new terminal definition.  Call it
  something like KERMIT313.

. At the bottom of the screen, several options will appear.  Choose the option
  for Terminal Control Characters.  It will then bring up a screen with the
  different initialization strings and their values.  The first four items are
  the ones that need altering (Terminal Initialization, Terminal Reset, Quick
  Initialization, and Quick Reset).  Just delete "[27][?34h" or "[27][?34l"
  (for initialization and reset, respectively) from the string and replace it
  with "[27]_take \kermit\wpunix.ini[27]\" or "[27]_set key clear[27]\",
  leaving the rest of the string intact.

. Be sure to change your WPTERM environment variable if you decided to create
  a definition with a different name.

= MICROSOFT WINDOWS

MS-DOS Kermit is the recommended Kermit software for Windows.  Follow the
directions in the KERMIT.HLP file for installing it.  However, you should be
aware that Windows is not a friendly environment for communications software.
Kermit will necessarily run slower under Windows than under DOS because
Windows has higher overhead; Kermit gets fewer CPU cycles per unit time
under Windows than it does under DOS.  Also, Windows has even more ways than
DOS to interfere with Kermit -- interrupt and memory conflicts, etc.

To improve Kermit's performance under Windows, try any or all of the following:

1. Use the PIF editor to raise Kermit's priority.  This will, of course, slow
   down any other active applications while Kermit is running.

2. Use the PIF editor to lock Kermit in memory.  This will also interfere with
   other applications, but it eliminates the chance of Kermit being swapped
   out when characters arrive on the communications device, which could
   otherwise be lost while Windows swaps Kermit back in to process them.

3. To avoid memory conflicts, don't let Windows choose its own memory
   management layout.  Instead, make sure the "[enhanced]" section of your
   SYSTEM.INI file agrees with your DOS memory configuration as to where
   expanded memory goes and what areas to eXclude.  EMMEXCLUDE= and
   EMMPAGEFRAME= items should be set to match your expectations.  Put nothing
   in segments (i.e. EMMEXCLUDE) A000-BFFF, which must be reserved for the
   video adapter.

4. Make sure your serial communication (COM) device has a 16550A buffered
   UART.  This reduces the number of interrupts that must be serviced (slowly)
   by Windows before Kermit gets to see them.  Avoid internal modems, which
   almost never have buffered UARTs.

4.5 (So far, this one is just folklore...)  In the "[386Enh]" section of
    SYSTEM.INI, you might find a section like this:

      COM1Irq=4
      COM1Base=03F8
      COM2Irq=3
      COM2Base=02F8
      COM3Irq=3
      COM3Base=3220

   For any COM port that really has a 16550A buffered UART, try adding a
   line like:

      COM1FIFO=1

5. Install an alternative communication port driver, such as the WFXCOMM
   driver that comes with WinFax PRO, Delrina Technology Inc.

6. If you want to "minimize" Kermit (shrink it to an icon) while it is
   running, e.g. for "background" file transfers, be sure that you have
   allocated some background time for it in the KERMIT.PIF file.  Even then,
   Kermit (and all other tasks) are at the mercy of other applications that
   might not be willing to give up their shares of the CPU.

A handful of users have reported abnormal termination of Kermit in a window
with the message, "This application has violated system integrity due to
execution of an invalid instruction and will be terminated".  Diagnosis:
Unknown.  Workaround:  Using PIFEDIT, check all the memory options in the
KERMIT.PIF file, including "Lock Application Memory", "EMS Memory Locked",
and "XMS Memory Locked".

= WINDOWS FOR WORKGROUPS

Windows-for-Workgroups (WFW) networking is built upon LAN Manager NDIS
board handler software.  MS-DOS Kermit can make TCP/IP connections from
within Windows for Workgroups by using the DIS_PKT9.DOS and WINPKT.COM shims
that come on the Kermit disk.  For WFW 3.10 and earlier, NDIS drivers are
normal CONFIG.SYS device drivers, and DIS_PKT9 instructions apply.  For
WFW 3.11 and later, which uses its own built-in protected-mode NDIS 3.0:

 . In the SYSTEM.INI file, [Network Drivers] section, add DIS_PKT9.DOS at
   the end of the "transport=" line.  Make sure you are using DIS_PKT9
   as distributed on the MS-DOS Kermit diskette, and not DIS_PKT11 or any
   other version.  See below about PROTOCOL.INI.

 . Also in the [Network Drivers] section of SYSTEM.INI file, include
   "LoadRMDrivers=yes".  This means that the NET START command loads Real Mode
   (RM) Drivers.  DIS_PKT9.DOS is a Real Mode Driver.

 . In AUTOEXEC.BAT, use NET START.

 . As with all network connections in Windows, you must either lock Kermit
   in memory (Check Lock Application Memory in the KERMIT.PIF file) or else
   load the WINPKT shim "on top of" DIS_PKT9, following the instructions in
   WINPKT.DOC.

For greater detail, see the file MSKWFW.DOC.

= TROUBLESHOOTING MS-DOS KERMIT SERIAL PORT AND MODEM PROBLEMS

  "Why can't MS-DOS Kermit find my COM3 or COM4 port?"
  "Why can Kermit send characters to my COM port, but not read them?"
  "Why doesn't Kermit work with my internal modem?"

Rule out the obvious: Is everything connected and turned on?  Did you
give a SET PORT command for the right device, and did you give it BEFORE any
other device-related commands, such as SET SPEED and SET PARITY?  Remember,
port-related settings apply to the port that was selected in the most recent
SET PORT command, so a proper sequence might be:

  SET PORT COM2          ; First select the port
  SET SPEED 19200     ; Then set its speed
  SET PARITY EVEN     ; and other parameters for this port...
  SET FLOW RTS/CTS
  SET LOCAL-ECHO ON

Each of these parameters is remembered for each port, so switching ports (e.g.
SET PORT COM1 after you have given the above sequence of commands) changes
all these parameters to their previous (or default) values for the port you
have switched to.  To see communication parameters for the current port:

  SHOW COMMUNICATIONS

Check them carefully to be sure they are what you intended.

  The following discussion is detailed and technical, but most of it boils
  down to (a) telling Kermit two numbers, the port address and IRQ value; and
  (b) fiddling with your modem.     Keep that in mind as you read more about PC
  hardware than you ever wanted to know.

HOW A PHYSICAL COMMUNICATION PORT IS ASSOCIATED WITH A DOS COMn DEVICE

DOS PCs come with full support for two communication ports, COM1 and COM2, and
with provisions for two more, COM3 and COM4.  COM3 and COM4 are not well (or
consistently) supported in most types of PCs, as are COM1 and COM2 which
rarely (by themselves) cause any problems.  This discussion considers only
COM1-COM4, since higher-numbered COM ports are rare, and in any case not
supported by MS-DOS Kermit.

The digit in the port name (like the "2" in COM2) is an index into an area in
memory that contains the address of the serial port hardware.  The PC's Basic
Input/Ouput System (BIOS) has four words starting at segment 40 (hexadecimal),
word 0, for the addresses of the first four COM ports.  Word 0 is for COM1,
word 2 (two bytes per word) for COM2, word 4 COM3, and word 6 COM4.  To view
these addresses:

  C:\> debug         (start the debug program)
  -d 40:0         (display segment 40)
  -q             (quit the debug program)

("C:\>" is the DOS prompt, "-" is the debug prompt.)  Here are the results
on a PS/2 with 3 COM ports:

  0040:0000  F8 03 F8 02 20 32 00 00-BC 03 00 00 00 00 60 03  .... 2........`.
             ^^^^^ ^^^^^ ^^^^^ ^^^^^
             COM1  COM2  COM3  COM4

The first line (like the one above) contains the COM port information (ignore
the other lines, as well as the characters on the right).  "F8 03" is the
2-byte COM1 address, expressed in hexadecimal (base 16) with the low byte
first.  Thus the actual COM1 address is 03F8 hex, expressed in Kermit commands
as \x3f8.  The COM2 address is 02F8, the COM3 address is 3220, and (since
there is no COM4) the COM4 address is 0000.  That is how both DOS and the BIOS
understand which ports are defined and where to find them.

When your PC is powered up, the BIOS startup code checks for serial port
hardware (that is, a Universal Asynchronous Receiver/Transmitter, or UART) at
the two port addresses 03F8 and 02F8.  If it finds a UART at the first address
then that address is placed in word 40:0 and declared to be COM1.  Then the
BIOS tries the second address and if successful this address goes into the
first available word at that time, typically 40:2 as the address of COM2.
Thus if you remove a COM1 device then a previously COM2 device will appear in
the COM1 BIOS storage area as COM1 to DOS and Kermit.  What happens to the
other two words depends on the PC model and BIOS.  The IBM PS/2 BIOS fills in
all four words on startup, but most others handle only the first two because
that's how IBM did it with the original PCs.

  So... just setting switches or jumpers on a serial port board or internal
  modem does NOT necessarily define the board to be a particular COM port.

So why do some communication programs work with COM3 and COM4 without any
special fiddling?  These programs ASSUME certain COM3 and COM4 addresses, even
when there are no entries in the BIOS communication-port area.  Some of these
programs show you their assumptions in a menu (and might allow you to change
them), others do not.  The assumed values are usually as follows:

  Port     Assumed Address (hexadecimal)
  COM1          03F8
  COM2          02F8
  COM3          03E8
  COM4          02E8

  NOTE: PS/2s use different addresses for COM3 and COM4 -- 3220 and 3228,
  respectively.  Well-behaved communication software (like Kermit) will use
  these addresses rather than the defaults listed above.  Ill-behaved software
  ignores the segment-40 addresses and erroneously attempt to use its own
  values, right or wrong.

Unchecked use of an assumed port address is DANGEROUS if the device is not
really where the software expects, especially if some other kind of device,
say a network adapter, is at the given address.  It can also produce unwanted
conflicts under Windows, OS/2, and DesqView, whose drivers often set the
port's segment-40 word to 0 when they want to use the port exclusively and
without interference, and then restore the real address when done, and similar
unwanted interference with Int 14H redirectors that allow serial-port
communication software to be used on network connections.

Unlike most other PC communication software, Kermit does NOT attempt to use a
communications port unless:

  (a) It finds its address in the BIOS comm-port area, segment 40, or:
  (b) You specify the address yourself.

AND:

  The device at the given address passes certain tests, in which registers
  must contain certain values that are legitimate for a UART.

In other words, KERMIT IS MORE CAREFUL than most other communication software,
because does not want to risk disrupting normal operation of your PC.

SPECIFYING THE PORT ADDRESS

If you tell MS-DOS Kermit to SET PORT COMn (where n is 1, 2, 3, or 4), and
Kermit responds:

  Warning, no hardware for this serial port.
  This port will be operated through the BIOS as BIOSn

it means that Kermit did not find an address for the port in the BIOS area or
it did find one but the hardware at that address did not look like a UART.  If
the cause of the message is a missing address, you can tell MS-DOS Kermit the
address of the port by issuing the following command:

  SET COMn \xhhhh

where n is 1, 2, 3, or 4, and hhhh are four hexadecimal digits (0-9, A-F)
representing the 16-bit address.  This command not only informs Kermit of the
address, but also inserts the address into the BIOS so other programs can find
the port (if they follow the rules), and so you don't have to give this
command to Kermit again until after the next time you reboot.

After giving the SET COMn command, give a SET PORT COMn command for the same
port, e.g.:

  set com3 \x3e8   ; FIRST specify the address of COM3
  set port com3       ; THEN select COM3

How do you know what addresses to give?     If have purchased an internal modem
or an add-on serial port, the installation instructions should tell you.  The
device must be configured -- generally by setting little switches or
installing or removing jumpers.     You have to make sure that the address that
you have chosen agrees with the address that Kermit will use.

Although it is not recommended that you guess at address values, sometimes it
is the only way (as often with inherited equipment), for which occasions here
is a list of the addresses commonly used for serial ports and internal modems:

  Port     Likely Addresses (hexadecimal)
  COM1         03F8
  COM2         02F8
  COM3         03E8, 3220 (PS/2)
  COM4         02E8, 3228 (PS/2), 02E0

You probably won't find a serial port at any address not listed above, but you
might find a port at another port's expected address.  The use of these
addresses in SET COMn commands should be relatively harmless (provided you
don't also specify an interrupt, explained later); if there is no error
message, Kermit found a possibly usable port. If there is an error message, no
harm should have been done.

Now let's look at the other cause for the "This port will be operated through
the BIOS" message, namely that an address was found in segment 40, but the
device at that address does not appear to be a genuine serial port.
Explanations might include:

 1. The device is at a different address.  Check your device's configuration
    again, or else your SET COMn command.

 2. Your device is indeed at the given address, but its registers do not
    contain values expected of a true PC serial port.  In that case, BIOS
    operation is the only alternative.

 3. Your device is at the given address, but there is a conflict with another
    device at that address or the machine's bus speed (not CPU speed) is set
    so high that the hardware test gave confusing results.

When Kermit operates a port through the BIOS, rather than directly, it will be
MUCH slower and might not work at all because the BIOS requires the CD, CTS,
and DSR modem signals to be asserted by the device connected to the port (and
the CD signal is normally NOT asserted by a modem before it has made a
connection to another modem).  In that case, you will have to configure the
device (e.g. modem) to assert DSR, CTS, and CD always, or wire your modem
cable to fake these signals (e.g. by connecting CD and DSR together).

Assuming you have found the right address for your COM3 or COM4 port (or
nonstandard address for COM1 or COM2), and you want these addresses to be set
correctly for Kermit at all times, even if it doesn't read its initialization
file, you can put a command like the following in your AUTOEXEC.BAT file:

  set kermit=com3 \x3e8; com4 \x2e8;

INTERRUPTS

  "I can send characters to the modem, but I never see any on my screen."

This complaint (often arising from the user's observation of the modem lights
and speaker), also known as "can-talk-but-not-listen syndrome", usually means
that the communication device was found at the expected address, but Kermit's
idea of its interrupt is wrong.     What's an interrupt?

To achieve high-speed communication without impacting other applications,
Kermit reads characters from a serial device using "interrupts".  Whenever a
character arrives at the serial device, the device sends a signal, called an
interrupt, that can be "caught" by application software like Kermit, leaving
the application free to do other work in the meantime without having to
constantly look at the serial port to see if any characters have arrived (an
operation called "polling", which is used by some other communications
programs).  Communications programs that use polling are not sensitive to
interrupts being set improperly and might therefore work with improperly-
configured machines where Kermit will not (until you give it the required
information), but they also tend to take over the entire computer.

In contrast to polling programs, Kermit is normally waiting for input from the
keyboard, and is therefore idle if you are not typing and no characters are
arriving at the communication port.  In multi-tasking environments such as
Windows or OS/2, this allows other applications the largest possible share of
the CPU while Kermit is running.

When a character arrives at the port, an interrupt signals Kermit to wake up
from its keyboard-wait state and read the character from the port.  But Kermit
needs a way of knowing which device the interrupt came from, so it will not
erroneously read characters from the wrong one.  The device is identified by
an Interrupt Request (IRQ) number, a small number like 3 or 4.  The BIOS does
not record the IRQ number used by a serial port because the BIOS uses polling
rather than interrupts.  The communications software has to know which IRQ to
use.  By convention from the original IBM PC, COM1 uses IRQ 4 and COM2 uses
IRQ 3.  There is no standard for COM3 and above, but certain conventions are
normally followed:

  Port     PS/2  Others
  COM3     IRQ3    IRQ4
  COM4     IRQ3    IRQ3

  WARNING: Certain serial port cards and internal modems allow
  themselves to be configured with different IRQ numbers (such as 9),
  even on COM1 or COM2.     Check your device's installation instructions.

Some types of PCs (PS/2s, for example) allow sharing of IRQ numbers, provided
each application has its own interrupt service routine and each such routine
is built to "chain" interrupts properly (i.e. pass them along to other
applications if they have arrived at the wrong place).  This works, for
example, with Kermit on a PS/2; you can run two copies of Kermit under
Windows, one using COM2/IRQ3 and the other using COM3/IRQ3 (i.e. two ports,
same IRQ), both doing input and output simultaneously with no confusion.  But
on most types of PCs, IRQs can NOT be shared, so each device must have a
unique IRQ number. This caution applies especially when you have a serial
mouse on IRQ 3 or 4.

Once Kermit knows the COM port's address, it tests to see which IRQ number, 3
or 4, the device uses.  This is a safe test and doesn't cause any modem
signaling or communication to take place.  The PC architecture has a limited
range of IRQ numbers available, and so (usually) there can not be a unique IRQ
number for each serial port when there are more than two, so in most cases no
more than two serial ports can be active at once.

MS-DOS Kermit tests first for IRQ4, and then if there is no response, IRQ3.
If both tests fail, a default value is used (on PS/2s, the default is IRQ4 for
COM1 and IRQ3 for COM2-4; on others it is IRQ4 for COM1 and COM3, IRQ3 for
COM2 and COM4).  No error message is given in this case, but
"can-talk-but-not-listen syndrome" is a likely result.

Some add-on communication boards or internal modems are set up to use IRQ
numbers other than 3 or 4 in order to avoid conflicts with COM1 or COM2 and/or
to allow more than two COM ports to be active at once. But this can be
dangerous -- for example, IRQ 5 (which is often used for this purpose) is also
used by the hard disk controller on the PC/XT.  IRQ 7 is often used by network
boards.  For this reason, Kermit does not automatically test any IRQ numbers
other than 3 or 4, and does not use any other IRQ number by default.

But it is sometimes necessary, particularly on ISA (Industry Standard
Architecture) bus machines (PC/ATs and compatibles) and earlier (such as PCs
and XTs) to use an IRQ other than 3 or 4, for example when when an internal
modem is installed as COM3 on IRQ4, and then use of COM1 prevents COM3 from
working, and vice versa.  This problem can often be solved by reconfiguring
the board to use an otherwise unused unique IRQ number.  Ideally this would be
a normally free IRQ such as 10 or 11, but unfortunately most communication
boards are not configurable for IRQs higher than 7.  Here is a brief, and
definitely not comprehensive, guide to the low IRQ numbers (with IRQ numbers
expressed in decimal):

     2    Normally available, but some video boards use it to obey an obsolete
    standard for indicating vertical refresh.  Adjust video board jumpers
    to not do this.     On 286's and above, IRQ 2 is also known as IRQ 9:
    same IRQ, alternate number.  Windows 3.0 had difficulty with devices
    using IRQ 2, but Windows 3.1 is better.

     3    Normally COM2 and COM4.     PS/2's use IRQ 3 for all serial ports above
    COM1.  IRQ3 is also a favorite "factory default" of many local area
    network (LAN) adapters.

     4    Normally COM1 and informally COM3 (except on PS/2s).

     5    Secondary parallel port.  Parallel ports are rarely interrupt-driven
    (except for Novell RPRINTER users) so this wire becomes free if
    you unjumper the IRQ on the parallel port board.  LAN adapters are
    frequently placed on IRQ 5.  PC/XTs use IRQ 5 for the hard disk.  Be
    careful with this one.

     6    Floppy disk drives. Leave it alone!

     7    Primary parallel port.    Remove as described for IRQ 5.    Be careful,
    LAN adapters are frequently placed here.

NOTE: IRQs higher than 7 are not available on original PCs or PC/XTs.

     9    Alias for IRQ 2 on PC/AT and above.  Don't try to use this one
        as if it were a unique IRQ.

    10    Usually free.

    11    Usually free.

    12    Used by the IBM bus mouse, otherwise usually free.

    13    Math coprocessor errors are trapped here, otherwise frequently free.

    14    Used by hard disk on 286 and above.  Leave alone!

    15    Some SCSI controllers use this.     Usually free.

If your communication board uses an IRQ other than 3 or 4, you will experience
the "can talk but not listen" syndrome when using Kermit.  To fix it, simply
inform Kermit of the device's IRQ number.  This is done in the SET COMn
command, after the address:

  SET COMn <address> <irq>

for example:

  SET COM3 \x03e8 5

When you include a number (like 3, 4, 5, 6, or 7) after the port address
(separated by a space), Kermit skips its IRQ test and uses the IRQ number you
specified the next time you give a SET PORT command for that port.

  AVOID address and IRQ conflicts; these items MUST NOT overlap existing
  equipment. SERIOUS DAMAGE can result if, for example, the IRQ number you
  give is the same as the one used by your disk controller or network
  adapter.  Incorrect operation can result if the interrupt is in use by a
  less critical device, such as a mouse.

It is necessary to specify the IRQ number in either of these two situations:

  1. The communication device uses an IRQ number other than 3 or 4.

  2. Kermit's IRQ test interferes with Windows or a similar environment.

Check your PC's configuration carefully before specifying an IRQ number.
Before starting Kermit, you can use certain public domain or commercial
utilities, such as MAPMEM, Northgate QAPLUS, Quarterdeck MFT, or the MSD
utility shipped with Windows 3.1 to get an idea of which IRQ numbers are
already in use (these utilities are, of course, not foolproof -- for example,
they can't tell what IRQs are used by programs that are not presently loaded).
(NOTE: Run these programs under DOS, not Windows, if possible, since Windows
tends to hide the true nature of your PC's serial port structure.)

If, even after establishing the device's interrupt, Kermit still fails to
operate correctly (or reliably), check to see whether:

  1. Some other device (such as a mouse or LAN adapter) is generating the
     same interrupt.

  2. Some other software (such as a mouse or video driver) is catching the
     same interrupt.

If you find a conflict, you'll have to resolve it: remove the offending device
driver or TSR from your CONFIG.SYS or AUTOEXEC.BAT file or turn it off
temporarily (e.g. with the MOUSE OFF command for certain mouse drivers); or,
if possible, reconfigure one of the conflicting devices to use a different
interrupt.

Example: A PC (not PS/2) is delivered with a serial mouse on COM1 and with
COM2 as a free serial port.  COM2 can be used with an external modem, but you
can't put an internal modem on COM3 because its IRQ conflicts with the mouse
and the COM4 address clashes with an 8514/A video adapter (such as the ATI
Ultra+).  Neither the mouse interrupt nor the video board address can be
changed.  So to install an internal modem, you must remove the serial mouse
and driver and, if you need a mouse, replace it with a bus mouse.

PROBLEMS WITH MODEMS

  "I just bought and installed an XYZ-Turbo V-Dot-Everything internal
   data/fax modem, and I can't make it work!"

This has long been a common complaint about internal modems.  The same
complaint is also now being heard with alarming frequency about some of the
newer external modems.  With internal modems, particularly when they are
installed on COM3 or COM4, the most common problems are:

 1. Kermit doesn't know the modem's address, or the device is using an IRQ
    number other than 3 or 4.  These problems can be fixed by giving the
    appropriate SET COMn command to Kermit and/or clearing up any interrupt
    conflicts among your PC's devices.

 2. The internal modem is installed incorrectly, with an address or IRQ that
    conflicts with one already in use on your PC.

 3. The internal modem does not correctly emulate a real IBM PC serial port,
    and therefore fails Kermit's hardware test, and therefore can only be
    used through the BIOS.

 4. The device is in a laptop, notebook, or palmtop computer, and power to
    the internal modem or serial port has been disabled in the CMOS setup,
    or has been turned off automatically when the cover is closed or the
    machine shut down.

In mid-1992, a new generation of low-cost, high-speed modems, both internal
and external, began to appear on the market.  These modems typically offer a
wide range of features: V.32 and V.32bis modulation, V.42 and MNP error
correction, V.42bis and MNP data compression, etc.  Unfortunately, many of
these modems suffer from bugs not found in earlier modems.  The problems are
generally related to initialization of the modem and interaction with its
command processor.  Some common complaints:

 1. "The modem won't dial or respond to commands".  Or the modem ignores
    commands when Kermit's PARITY is set to a particular value, like EVEN.  Or
    commands are not processed correctly above a certain interface speed.

 2. "I can dial successfully, and in general send characters to and through
    the modem, but I never get any characters back."  This looks suspiciously
    like the "talk-but-not-listen" problem, but in some cases it is a bug in,
    or a configuration problem with, the modem, having nothing to do with
    Kermit: the modem is simply not sending any characters to the PC.

 3. "After using the modem with <name-omitted> communication software, it
    also works with Kermit, but it won't work with Kermit unless I run
    <name-omitted> first."

 4. "I can communicate in command-mode with the modem, up until I give it
    an ATZ command, at which point it seems to die."

 5. The modem does not pass the BREAK signal.

 6. The DSR signal goes off after successful dialing.

And so on.  All of these are modem, not Kermit, problems.  Some suggestions
for overcoming them:

 1. Before giving a DIAL command, which invokes a macro containing OUTPUT
    commands for the modem's command processor, give the command:

    SET OUTPUT PACING <milliseconds>

    For example:

    SET OUTPUT PACING 100
    OUTPUT AT Q0 E1 V1 &F\13

 2. External modems only: Check that your modem cable has wires for (at least)
    the TD, RD, SG, CTS, RTS, DSR, CD, and DTR RS-232 signals.    If it does
    not, replace the cable with a real modem cable, or (temporarily) configure
    your modem to compensate for the missing signals.

 3. Read your modem manual and check your modem's configuration.  Perhaps its
    interface speed is locked to a different speed than the one Kermit is
    using.  Perhaps Kermit is set to use RTS/CTS flow control, but the modem
    is not asserting CTS.  Also, check its factory and/or saved settings, and
    under what conditions they are restored (for example, are they restored
    when the PC drops DTR?).  How are you selecting saved settings -- read
    your modem manual about (e.g.) the difference between AT&F and AT&F2.  Be
    aware that the AT&Fn commands might not restore all S-registers, so double
    check them.  Be particularly sensitive to the registers that control
    interface speed, modulation technique, error correction, data compression,
    negotiation, and fallback, and note that each modem maker probably uses
    different registers and commands to control each of these features.

 4. Try the following sequence to initialize the port (using COM3 in this
    example):

    SET COM3 <address> <irq>    ; (if necessary)
    SET PORT 3            ; Select port 3
    HANGUP                ; Drop DTR on port 3
    SET PORT 3            ; Re-initialize port 3

 5. SET PARITY NONE before giving a DIAL command or directly talking to the
    modem's command processor, and then SET PARITY to whatever the remote host
    or service requires after making the connection.  (NOTE: MS-DOS Kermit
    might set its parity to some other value automatically as a result of
    automatic parity detection during file transfer.)

 6. Ensure your PC bus speed is 8MHz.  Some PCs (not PS/2s) come with a BIOS
    SETUP facility that lets you change the PC's bus speed, memory wait
    states, etc.  In general, it is dangerous to deviate from the defaults,
    particularly from the 8MHz bus speed, a standard for add-on devices; it
    might be required by your communication board or internal modem.

 7. To avoid negotiation and fallback problems between the two modems, set
    your modem for features that you know the answering modem will support:
    the particular type of modulation, error correction, compression.  NOTE:
    connection problems between the two modems have nothing to do with Kermit
    and are beyond the scope of this document.  If a modem appears to dial
    correctly, gets connection tones, and then hangs up, it is a problem
    between the two modems (involving one or both modems and/or the phone
    company), and indicates a modem configuration problem, a bug, or a basic
    incompatibility between the calling and answering modems.

 8. The ATZ problem.  This is a bug in your modem.  If the modem doesn't work
    after an ATZ command, HANGUP and the SET LINE again.  If that doesn't do
    it, power the modem off and on.  If that doesn't work, power the PC off
    and on.

 9. If the modem doesn't pass the BREAK signal, but you want it to, read your
    modem manual about how to configure it appropriately.  If your modem can't
    be configured to pass the BREAK signal, but it does correctly implement a
    command for sending BREAK, such as AT\B9, define an MS-DOS Kermit macro,
    SBREAK, to send a BREAK as follows:

      define sbreak pause 1, output +++, pause 1, output ATB\{92}9\13, -
    pause 1, output ATO\13, connect

    and assign it to the key of your choice, for example F1:

      set key \315 {\Ksbreak}

10. Call your modem maker's technical support number.  Ask if they have
    replacement chips to fix bugs in your modem.

= DISK INTERRUPT CONFLICTS

On certain PCs, Kermit file transfers (or terminal sessions that are being
logged to disk) through serial communication devices (COM1 thru 4) can suffer
from data loss during disk read/write operations.  This is apparently because,
on these PCs, the entire interrupt mechanism is TURNED OFF during disk reads
or writes.  Thus, while the disk driver is active, no interrupts are generated
by incoming characters, and therefore they are likely to be lost (particularly
if the UART does not have its own buffer).

If you experience data loss during uploads (watch the "Retries" counter), try
sending the same file from a RAM disk; if the retries go away, your PC has
this problem.  If downloads to disk have lots of retries, try downloading the
same file to the NUL device (tell MS-DOS Kermit to RECEIVE NUL); same deal.

On some PC's, it has been observed that the disk-interrupt conflict occurs
when using a certain COM port, but not a different one.  For example, on a
PS/2 Model 70 A20, conflicts occur on COM2 but not COM1.

= MS-DOS 5.0 AND 6.x

You should not use MS-DOS Kermit (or other communications software) under
DOSSHELL.  Unlike Windows, DesqView, OS/2, etc, DOSSHELL is NOT a multitasking
environment.

= MICROSOFT WINDOWS, DESQVIEW, OS/2, WINDOWS NT, ETC.

Although MS-DOS Kermit can work in these environments, and even takes advantage
of many of their features, it does not have a "graphical user interface".  You
still have to type commands to the MS-Kermit> prompt or execute them from
command files with the TAKE command.

OS/2 1.x...

NOTE: The recommended communications software for OS/2 (any version) is
C-Kermit 5A(188) or later, which is a native OS/2 application.

Under OS/2 1.3 and earlier, MS-DOS Kermit only runs in full-screen mode.
Under 1.x of OS/2, the serial port must first be conditioned by the command:

  SETCOM40 COM1=ON

OS/2 2.0 and 2.1...

MS-DOS Kermit can run in a window of OS/2 2.x and, of course, also in a full
screen.  Kermit's flow control has no effect because OS/2 itself is
controlling the device.  You can configure OS/2 to handle flow control itself
by adding a command like the following to your STARTUP.CMD file:

    MODE COM1 XON=ON          (for XON/XOFF software flow control)
or:
    MODE COM1 RTS=HS OCTS=ON  (for RTS/CTS hardware flow control)

If your PC's communication port is a 16550A[FN] UART serial communication
adapter (as is standard on the PS/2), it has a built-in buffer to improve
performance.  To enable use of the 16550's buffering capability, add BUFFER=ON
to your MODE command:

    MODE COM1 XON=ON BUFFER=ON           (for XON/XOFF software flow control)
or:
    MODE COM1 RTS=HS OCTS=ON BUFFER=ON (for RTS/CTS hardware flow control)

If you don't have a buffered UART, MS-DOS Kermit (and most likely any other
communications software) will lose characters galore at high transmission
speeds.

IDLE_SENSITIVITY should be set to 0 and IDLE_DETECTION_TIME should be 100 to
reduce the jerkiness of DOS sessions.

Reportedly, MS-DOS Kermit runs quite well under OS/2 (in a DOS window, or
fullscreen) if you load the shareware SIO.SYS or VSIO.SYS driver in place of
OS/2's regular serial port driver.  If you do not have a buffered UART, tell
SIO.SYS to simulate one, e.g. "(COM1,3F8,IRQ4,,F)".

You can make TCP/IP connections with MS-DOS Kermit from within OS/2 as long
as you do not have any other network software loaded; that is, if MS-DOS
Kermit has exclusive access to the network board.


MICROSOFT WINDOWS...

MS-DOS Kermit operates under Microsoft Windows 3.0 and 3.1 in fullscreen mode
on all machines, and in a window on 386-class or higher machines that have
enough memory for Windows to operate in Enhanced Mode (3-4 megabytes are
required).  Be sure to install the KERMIT.PIF file so Windows can can set
things up correctly for Kermit operation.  See the instructions in MSKERM.HLP.

Under Windows 3.x Real or Standard mode, you can use still use MS-DOS Kermit
as a full-screen DOS application.  Kermit works in a window on all PCs (if
they have enough memory) under Windows 2.0.

Memory-management setups accomplished under DOS (e.g. by EMM386) in CONFIG.SYS
are undone by Windows.  If successful operation of Kermit or other
applications depends on some special memory configuration (such as eXclude=
and frame= clauses to protect portions of video memory, etc), you must
duplicate this configuration in the [Enhanced] section of the Windows
SYSTEM.INI file.  Note that segments A000 and B000 remain owned by the video
display system and not by memory managers.

The use of COM3 and COM4 under Windows is problematic, but most users report
success after finding the right "SET COMx <address> <irq>" command.

When running Kermit in two windows at once, one on COM1, one on COM2, Windows
complains that both applications want to access COM1.  To make sure that COM1's
IRQ 4 is not touched when starting COM2 (part of the "find the IRQ" test),
specify the COM2 port parameters explicitly as SET COM2 \x2f8 3 (standard port
address and IRQ for COM2) to make Kermit skip the test.

Similarly, if you have a serial mouse on COM1, and you want Kermit to use (for
example) COM2 for communication, add the following to your MSCUSTOM.INI
file to prevent Kermit from touching COM1 and interfering with your mouse:

  SET COM2 \x2f8 3 ; (substitute appropriate values)
  SET PORT COM2

Kermit's performance under Windows depends on the BIOS, the machine
architecture, the serial port hardware, which drivers and TSRs are loaded, the
system load, and Windows settings.  A 16550A UART is particularly important
under Windows, as is an effective flow control method. For further tuning,
look at the Windows files SYSIN*.TXT for information about SYSTEM.INI settings
related to communication ports, particularly COMxBuffer and COMBoostTime.

When running MS-DOS Kermit under Windows, specifying a ",P" at the end of a
serial port setting in WIN.INI or in a MODE command can cause loss of
characters from the serial port.  Remove the ",P" from the setting.

TCP/IP connections over packet drivers under Windows require the WINPKT shim.
TCP/IP connections over ODI under Windows require a packet-driver simulation
shim and also the WINPKT shim.  Or, instead of using WINPKT, you can lock
Kermit into memory.  See KERMIT.HLP for instructions on using Kermit's TCP/IP
support under Windows.

DESQVIEW and DESQVIEW/X ...

Users of DESQview set "Optimize Communications" in the Advanced menu to "No".

DESQview/X reportedly requires that the serial port be configured to
"optimize" to prevent Kermit from losing characters.  Network connections
(TCP/IP over a packet driver or ODI) within an X window of DESQview/X
apparently do not work.

WINDOWS NT ...

If you have performance problems with MS-DOS Kermit under Windows NT:

You really need at least 20 MB of memory to run Windows NT, and particularly
to run communications software under Windows NT.

The last service update has a bug in the serial driver.  You should back out
of it if WINVER shows your NT version as Build 528, Service Pack 2.

Check the Event Viewer for errors in the System Log, or use WINMSD to check
for IRQ conflicts.

Modifying system parameters...  Most parameters are kept in the NT Registry,
although a tiny handful of NT programs (like CLOCK) use .INI files.  The
Registry is poorly documented, but you can get the NT Resource Kit Tools by
anonymous ftp from ftp.microsoft.com (an NT system, FYI),
/Advsys/winnt/sup-ed/reskit/i386/RESKIT.EXE (for Intel systems), a
self-extracting archive has a fairly complete description of the registry
fields and what they mean.  WARNING!  You can render a system unbootable with
the registry editor.  To run the registry editor, type START REGEDT32 at a
console prompt.


= VIDEO PROBLEMS

Never use segments A000 or B000 for memory mapping.  These belong to the
video adapter.

Kermit does not mix well with NNANSI.SYS, a public domain (or shareware?)
console driver that replaces ANSI.SYS, and which implements "hardware
scrolling", a case of two non-cooperating programs directly manipulating
the video adapter at the same time!  Similar comments apply to other console
drivers that access the screen directly, including ANSI.COM (from PC Magazine,
circa 1988).

To turn off NNANSI.SYS's direct screen access, put the following commands in
your MSCUSTOM.INI file:

  echo \27[=98l                  ; Reset "fast mode"
  define on_exit echo \27[=98h   ; Set "fast mode"

= SERIAL COMMUNICATIONS

Certain kinds of PCs with internal modems will hang up their phone connections
if you give MS-DOS Kermit a SET FLOW or SET PARITY command; this has been
reported for a DECpc 425SL laptop, and an unnamed desktop with an Intel
internal modem.   MS-DOS Kermit 3.14 will include a workaround for this
problem.  In the meantime, avoid giving SET FLOW or SET PARITY commands on
these systems when there is an active connection through the modem.

ANSI.COM, mentioned above in connection with video problems, also interferes
with serial communications.  Solution: unload it, use ANSI.SYS instead.

On PCs with high-quality buffered UARTs, Kermit can be used at speeds up to
57600 bps under DOS (under Windows or DesqView, the maximum speed is probably
lower).     115200 bps works only with a very short shielded cable, and the async
adapters of the two machines in perfect tune.  Some VAX serial port interfaces
are out of tolerance at 19,200 bps and faster.    Some of the new high-speed PCs
(486s like, for example, the IBM PS/VP or the Gateway 2000) come with
unbuffered UARTs.  Despite the speed of the CPUs, these new machines perform
serial communications less reliably than older machines that run at 1/4 the
speed or less, but that have buffered UARTs (like the PS/2-70).

MS-DOS Kermit will tell you whether you have a buffered UART:

  SET PORT 2
  SHOW COMMUNICATIONS
  ...
  COM1 Address: Port \xf38, IRQ 4, 16550A UART FIFO

16550A UART means you have the good kind, FIFO means it has a "First-In
First-Out" buffer.  If Kermit does not say you have a 1655A UART FIFO, and you
are suffering from performance or data loss problems, replace it (if
possible!)  with a 16550A.

SHOW COMMUNICATIONS might incorrectly display the UART type after you switch
ports (e.g. from COM1 to COM2).  After using the new port (e.g. in CONNECT
mode), the display will be correct again.

If your speed is set too high, the symptom might be lost or garbled characters
or graphics images on the screen, or data-overrun beeps.  Normally flow control
prevents these problems so use it if you can.  Printing while in CONNECT mode
needs flow control to be active.

Even with flow control, however, there can be no guarantee that incoming
characters will not be lost at high communication speeds on very slow PCs,
such as original 4.77MHz PCs or PC/XTs.  In such cases, the only recourse is
to use a slower communication speed.

MS-DOS Kermit does not monitor the communication line for carrier loss during
terminal emulation or file transfer.  You can SHOW MODEM or SHOW COMMUNICATIONS
to inquire about CD, DSR, and CTS.  The script command WAIT permits sensing
carrier presence in a script program.

The SHOW MODEM and WAIT commands work right only if your modem or other
communication device is configured to raise and lower the DSR, CTS, and CD
signals appropriately, and the cable that connects your PC to the modem passes
these signals through.    For some modems, the factory setting is to always keep
CD on, even if there is no connection.    Consult your modem manual.

For serial devices, the HANGUP command (and Ctrl-]H in CONNECT mode) works
only if the cable that connects your PC to the communication device passes the
DTR signal through, and if the communication device itself is configured to
hang up or otherwise terminate the connection when the DTR signal is lowered
by the PC.  For some modems, the factory setting is to ignore DTR transitions.
Consult your modem manual (for example, tell a Hayes modem to "AT&D2").     NOTE:
in version 3.11, the HANGUP command turned off DTR for about 1/2 second and
then turned it back on again.  In version 3.12 and later, the HANGUP command
turns off DTR until the next time you issue a command that accesses the serial
port.  If you can't make the HANGUP command work, define a macro to send a
hangup command to the modem, for example (for Hayes modems):

  DEFINE MYHANGUP PAUSE 1, OUTPUT +++, PAUSE 1, OUTPUT ATH0\13

and then use this macro in place of the regular HANGUP command.  You can also
assign this macro to a "hot key", for example:

  SET KEY \2339 {\Kmyhangup} ; Assign MYHANGUP to Alt-h.

= TERMINAL EMULATION

Kermit's VT320/340 emulator lacks the following features:

 . Smooth scroll
 . Downloadable soft fonts
 . ReGis graphics (VT340/330)
 . Dual sessions in split screens (VT340/330)
 . Local screen editing and block transmission (for security reasons)
 . True double height/width characters (these are simulated)
 . Selective erasure (as a character attribute, a formatted screen item)
 . Some of the exotic and rarely-used features of the DEC VT340/330 series:
   formatted screen and graphics operations highly specialized to DEC hardware.

MS-DOS Kermit does not include "ANSI" or "PCTERM" emulation.  If you need
this, as when logging in to a PC-based BBS, tell MS-DOS Kermit to:

  SET TERMINAL TYPE VT320  ; This is the default, or use VT100.
  SET PARITY NONE          ; This is the default
  SET TERMINAL BYTESIZE 8
  SET TERMINAL CHARACTER-SET TRANSPARENT

and make sure your PC's code page agrees with what the BBS thinks it is,
otherwise box-drawing characters might come out looking like accented
letters.  If that doesn't work, then use your ANSI console driver instead of
Kermit's built-in VT terminal emulation: make sure you have the ANSI.SYS (part
of DOS) console driver loaded in your CONFIG.SYS, and SET TERMINAL TYPE NONE
(rather than VT320); note that when your terminal type is NONE, the mode line,
screen rollback, similar features are not available.

Hint: You can get a nice border around your terminal emulation screen if you
have Norton Utilities: "sa black on green", for example (either before
starting Kermit, or "run sa black on green" at the Kermit prompt) will give
you a restful green border, independent of Kermit's SET TERMINAL COLORation.

On certain national keyboards, like the German one, Kermit's normal escape
character, Ctrl-] (Control-Rightbracket) does not seem to work.  This is
because certain control characters are typed differently on these keyboards.
On the German keyboard, Ctrl-] is produced by holding down the Ctrl (Strg) key
and pressing the + (plus) key.  MS-DOS Kermit has no way of knowing this, and
continues to display the escape character as "^]" in the mode-line help text.

Kermit does not work with certain Swedish keyboard drivers because of a bug in
the keyboard driver.  Workaround: use a different keyboard driver.  Reportedy
there are several different Swedish keyboard drivers available.

Do not attempt to plug an "enhanced" (101) keyboard into a PC/XT or earlier.
The BIOS on early PCs does not support the newer keyboards, even if you
install the corresponding keyboard driver.

If VAX/VMS thinks you have a VT220 or VT320, it sends 8-bit control sequences.
Kermit does not understand them unless you SET TERMINAL BYTESIZE 8.  The
symptom is the appearance of fragments of escape sequences on the screen and
wrong cursor positioning, and possibly fractured tab settings, particularly
during EVE sessions.  You can prevent VMS from sending 8-bit control sequences
(if you really do not have an 8-bit connection) by giving the VMS command SET
TERMINAL /NOEIGHT.  For VAX/VMS, you should also use Xon/Xoff flow control in
both directions (SET TERM /TTSYNC /HOSTSYNC on VMS).

Reportedly (details not available, unverified), the EVE (or EDT/TPU) VMS-based
text editor requires not only the SET TERM BYTE 8 and SET TERM CONTROLS 8
settings in MS-DOS Kermit, but also the following commands to be issued to
the VMS DCL prompt (other EVE users indicate these commands are not needed,
and ESC Z (i.e. SET TERM/INQUIRE) takes care of everything):

  $ SET TERMINAL /DEV=VT300
  $ SET TERMINAL /NODEC_CRT2
  $ SET TERMINAL /DEC_CRT

In VT100/200/300 emulation on the IBM PC family, receipt of ESC [ 4 m (turn on
underscore) results in a color change rather than underscore on IBM CGA, EGA
and other color displays.  IBM color display adapters have one less attribute
than DEC terminals, and in addition the two systems intensify dots differently
(IBM does foreground/character dots only, whereas DEC can intensify any
dot).  The color chosen for underscore simulation is derived from the normal
fore- and background colors in a way that ensures it is different from both.
There is presently no way for the user to choose the color used for underscore
simulation.

Receipt of ESC [ 0 m does not affect the fore- and background colors, in
compliance with the definition of this function for real DEC VT terminals.
Fore- and background colors can only be changed by the host, by sending
explicit ESC [ 3x/4x m escape sequences, by issuing a SET TERMINAL COLOR
command to Kermit.

SET TERMINAL COLOR 1 [3xx 4xx] (used to make the foreground color bright), if
issued when SET TERMINAL SCREEN REVERSE is in effect, reverts to normal video.

Similary, if SET TERMINAL COLOR 1 is in effect, the effects of the host-
generated escape sequences CSI 1 m and CSI 0 m are reversed.

If certain incomplete escape sequences (e.g. Operating System Command) are
received during terminal emulation, Kermit can hang waiting for the string
terminator that never comes, usually because of noise on the communication
line.  Reset the terminal emulator by pressing Alt-= (Alt-equals), the default
key for \Kreset.

Kermit assumes 25 screen lines but can adapt to other lengths if it knows how
to get this information from the video adapter.  The number of lines is
usually available from DOS as the "video mode".  Unfortunately, different
video adapters have different video modes, or use the same mode numbers to
mean different things, and use different methods to set the mode (typically
some kind of DOS MODE or VMODE "LINES=" command, the "printing" of certain
escape sequences to be intercepted by the console driver, etc).  In any case,
Kermit tries its best to use the screen dimensions discovered upon startup,
but if Kermit subsequently enters 132-column or graphics mode, it typically
returns to an 80x25 screen because it can't know how the original nonstandard
geometry was established in the first place.

To get properly formatted screens during terminal emulation, be sure to inform
the remote host of your screen width and length.  On some UNIX systems, this
can be done by:

  `eval resize`

which asks the terminal for its dimensions (Kermit responds correctly) and
puts these values in your UNIX environment.  As of version 3.14, Kermit will,
on TCP/IP TELNET connections, engage automatically in NAWS (Negotiate About
Window Size) protocol with the TELNET server, if the TELNET server supports
this, which will inform the remote host of your screen size automatically.

So that key translation and macros can work on both IBM and non-IBM compatible
PCs, Kermit uses the system BIOS to obtain key scan codes.  But the IBM BIOS
does not produce scan codes at all for certain keys, and may produce duplicate
scan codes for others.    Num Lock, Print Screen, Scroll Lock, and Pause are
examples.

Although MS-DOS Kermit has verbs for DEC function keys (\KdecF6-F20) and it
also supports the DEC User-Defined Key (UDK) feature, it does not support both
of these simultaneously.  If the host sends a UDK-defining sequence for a
given function key, it will overwrite the normal definition of that key.  This
behavior differs from a real DEC terminal, which preserves the normal F-key
function, and assigns the user-defined value to the shifted version of the
function key.  Workaround: Use the \KdecF6-20 verbs for UDKs but *not* for
DEC F-keys.  Since the values sent by DEC F-keys are constant, assign these
values, rather than the corresponding verbs, to the desired keys.  The values
are listed in "Using MS-DOS Kermit", Table II-5, page 294.  Example:

  set key \2413 \27[17~  ; Assign DEC F6 value to PC Alt-F6
  set key \857 \KdecF6   ; Assign DEC Shift-F6 (UDK) to PC Shift-F6

When you PUSH to DOS (including when you use Kermit's RUN command), and you
have XON/XOFF flow control enabled, Kermit sends an XOFF (Ctrl-S) to the host
when you leave, and XON (Ctrl-Q) when you return (if you have RTS/CTS flow
control enabled, Kermit turns off RTS).     This prevents data transmitted by the
host from being lost.  However, if you are using Xon/Xoff and you do this
while using the EMACS text editor on the host, the Ctrl-S will be interpreted
as a Search command, and the Ctrl-Q as a Quote command.     When you return to
EMACS, type several Ctrl-G's to get back to normal.

Similar comments about sending Xoff and Xon apply when Kermit is commanded
to change its screen size between 80 and 132 columns.

Session logging can be turned on using the LOG SESSION command, and it can
be toggled on and off during terminal emulation by using whatever keys are
associated with the verbs \Klogoff and \Klogon.     One user stated the
requirement to enable a session log, but to have it initially turned off.
This can be done as follows (using the F1 and F2 keys as examples):

  SET KEY \315 {\Kloginit}  ; F1 to turn on log
  SET KEY \316 \klogoff        ; F2 to turn log off
  DEFINE loginit log session, set key \315 \klogon, define loginit, connect

To log your session to a printer, add the word PRN after "log session" in
the third line above.

The session log is written to disk by DOS.  The frequency with which DOS
updates this file is governed by the BUFFERS= line in your CONFIG.SYS file (see
your DOS manual).  If you allocate a large number of buffers in CONFIG.SYS,
disk operations occur infrequently and this improves performance.  If you need
to have the session log updated more frequently to minimize the loss of data
when there is a power failure, you can do this (at the expense of efficiency)
by allocating a smaller number of buffers in CONFIG.SYS.

If you have Kermit's TERMINAL TYPE set to NONE, there is a two second pause
after you give a CONNECT command, to give you time to read the message about
how to get back.

132-COLUMN MODE

You can't use 132-column in Windows, because Windows takes over the graphics
adapter and hides its particulars from Kermit.

If you have a monitor with fixed horizontal frequency but a video adapter that
Kermit knows how to switch into 132 column mode, you will see only garbage on
your screen whenever Kermit switches to 132 columns.  There is no way to tell
Kermit to ignore "switch to 132 columns" commands.  If you buy a
132-column-capable video adapter, be sure you have a compatible monitor.  See
KERMIT.UPD for further information on 132-column mode.

GRAPHICS TERMINAL EMULATION

In earlier releases, MS-DOS Kermit responded to ESC 1 and ESC 2 for
automatically switching into and out of Tektronix graphics mode, for the
benefit of some long-forgotten host-based graphics software.  This feature
has been discontinued because these escape sequences mean something entirely
different, namely "switch character size" in VT340 Tek mode.

PS/2 Model 25 and 30 MCGA adapter is used in low-resolution CGA mode by
default; images may be elongated or truncated.    Hi-resolution graphics can be
done (as of version 3.11) via SET TERM GRAPHICS VGA, but these slow PC models
might not be able to keep up at speeds above 9600 bps.

When you type the escape character (normally Ctrl-]) while in Tektronix
graphics mode, the screen goes back to text memory.  Then when you type the
argument character, the graphics screen reappears (unless the argument was C or
P).  Ctrl-]F will not file the graphics screen, but rather the text screen,
because that's the screen that's showing after type the Ctrl-] key.  To file
the graphics screen (in TIFF format), use \Kdump (normally on Ctrl-Keypad-End).

You can't dump the Tektronix screen while the GIN-mode crosshair cursor is
active; Kermit's keyboard translator is not active.  Key strokes (of regular
typewriter keys) or mouse actions are used to transmit the crosshair
coordinates.  If you press a non-typewriter key, Kermit just beeps.

Kermit does not emulate a particular kind of color graphics terminal, such as a
DEC ReGIS display or a Tektronix 41xx or 42xx series.  However, it can be used
for color graphics by mixing ANSI color-setting escape sequences with Tektronix
or Sixel commands.  This requires graphics software vendors adding support for
MS-DOS Kermit graphics to their packages (so far, WordPerfect Corp has done
this for their host-resident products).  There is at least one ReGis-to-Sixel
converter on the market: RETOS, a DEC product for VAX/VMS.

Problems may occur when using Kermit with host-resident (VAX/VMS) versions of
WordPerfect because the color palette report sent upon request of WordPerfect
is very long. If the host is not configured properly, parts of the report will
be lost because of overruns on the VMS side.  SET TERM /HOSTSYNC and /TTSYNC
are required for WP/VMS.  Even then intervening communication boxes (e.g.
terminal servers) can become overloaded with the 200++ byte response.

= PRINTER SUPPORT

Kermit uses DOS services for printing. There is no knowledge of particular
printer types in Kermit.  Kermit determines whether the printer is ready, or
whether there has been a printing error, via DOS's return code.  If DOS tells
Kermit the printer is not ready, Kermit changes the printer device name to NUL
so subsequent print operations won't block.  To reenable printing operations
(e.g. after turning on the printer, adding paper, etc), use a SET PRINTER
command such as SET PRINTER PRN or SET PRINTER LPT1.

When printing a file that contains a Ctrl-Z character, DOS will "close" the
printer as soon as it sees the Ctrl-Z, and when subsequent characters are sent
to the printer, DOS reports a printer error and Kermit reports "Printer error,
discard or retry?".  This is a feature of DOS.

The Print Screen and Shift-PrintScreen keys are never seen by Kermit.  They
are intercepted and acted upon by the BIOS.  Thus Kermit has no control over
the format of the printed output.  For example, a formfeed is not added to the
end to force a page eject.  If you want to print the current screen with a
formfeed at the end, use the following procedure:

  SET DUMP PRN    ; Specify that screen dumps go to the printer

and then use the \Kdump keyboard verb to accomplish the screen dump.  This
verb is assigned by default to the keypad Ctrl-End key, but you can assign it
to another key of your choice (but not Print Screen), for example:

  SET KEY \315 \Kdump  ; Assign screen dump to F1

Alternatively, you define a key (this time we use the F2 key) to send a
formfeed (ASCII 12) to the printer:

  DEFINE FFPRINT run echo \12 >PRN
  SET KEY \316 {\Kffprint}

Or you can redefine your host printing procedure to include a formfeed:

  1. Send ESC [ 5 i
  2. "type" the file
  3. Send formfeed (ASCII 12)
  4. Send ESC [ 4 i

(Shift-)Printscreen can cause the PC to hang if there is no attached printer.
This is a BIOS feature, Kermit never receives the command.  If this happens
during terminal emulation, try pressing Alt-= (hold down Alt and press the "="
key) several times to reset the terminal emulator.

Serial printers are not well supported by DOS, and since Kermit does all its
printing through DOS, Kermit's printing features might not work well with
serial printers.  To use a serial printer effectively, you must have a driver
for it that takes care of flow control, such as MSPSPD, available on the
MS-DOS Kermit Utilities and Technical Documentation diskette.

Transparent printing starts when the host sends the sequence ESC [ 4 i and
stops when the host sends ESC [ 5 i.  All characters, including escape
sequences, that arrive at the port are passed directly to the printer without
translation (but the parity bit is stripped if Kermit's parity is not NONE).
If character translation is desired, or it is desired not pass screen-control
escape sequences to the printer, use Autoprint rather than Transparent print
(ESC [ 0 i, ESC [ ? 4 i, ESC [ ? 5 i).    In that case, characters are translated
to the current IBM code page.  If your printer doesn't support your IBM code
page, you need an external utility to translate from the PC code page to the
printer's character set.  You can use SET PRINTER xxxx to capture Transparent
print or Autoprint data into a file.

Under PATHWORKS, reportedly, transparent print operations to a network printer
do not cause printing to actually occur until the user escapes back to the
MS-Kermit prompt and forces the printer to be closed (and reopened) with a SET
PRINTER PRN command.

If transparent print material arrives but the printer is not ready, Kermit
issues a PRINTER IS NOT READY message and gives the user a chance to retry
(R) or discard (D).  If D is selected, then, even if the printer is made
ready again, subsequent transparent print jobs are discarded.  Solution:
escape back to the prompt and give a SET PRINTER PRN command to reenable
transparent printing.

= INTERNATIONAL CHARACTER SETS

MS-DOS Kermit does not directly support Cyrillic terminal sets; that is, you
can't set your TERMINAL CHARACTER-SET to a Cyrillic set.  However, you can
still have a Cyrillic terminal session if you have a Cyrillic code page loaded
and you have issued the appropriate collection of SET KEY and SET TRANSLATE
INPUT commands.

Character-set translation during terminal emulation is done between the remote
TERMINAL CHARACTER-SET and the PC's current code page. During file transfer,
it's between the TRANSFER CHARACTER-SET and the PC's code page.  At startup,
MS-DOS Kermit asks DOS to report the current code page, and it sets your FILE
CHARACTER-SET and your TERMINAL CODE-PAGE to this value.  But DOS often lies
about the code page, so in most cases when your actual code page is anything
but 437 (or maybe 850), you, yourself, will have to tell MS-DOS Kermit what
your code page *really* is, using the following two commands:

  SET TERMINAL CODE-PAGE CPnnn ; Your actual current code page.
  SET FILE CHARACTER-SET CPnnn ; The code page for incoming text files.

The two would normally be the same, but MS-DOS Kermit lets you set them
differently if you want to, for example if you have a Hebrew code page loaded
for display purposes, but you want to download a Russian file that you will
display later, after loading a Cyrillic code page.

MS-DOS Kermit does not allow all possible combinations of FILE and TRANSFER
character sets.     The Hebrew code page (CP862) forces the Hebrew transfer
character set, and vice-versa.    Similarly for Cyrillic and Latin-2, etc.
Latin-1, however, can be used with many code pages: 437, 850, 861, 863, 865.

Some of the ISO 2022 or DEC-specific character-set designation escape
sequences, which *do* work correctly, nevertheless fail to have an effect on
the character-set field of the SHOW TERMINAL display.

LOG SESSION records characters that arrive at the serial port, before
translation by either Kermit's built-in terminal character set translation
tables or by user-specified SET TRANSLATION INPUT commands.  This allows
REPLAY to work correctly but it prevents special characters from being logged
after translation to the PC's own character set.  Screen dump (Ctrl-End or
Ctrl-]F) and autoprint, however, record the translated characters.

SET TERMINAL CHARACTER SET is effective only for text screens, not for
graphics screens.  This is because the fonts for all the special characters
have not been designed yet (and may never be, and even if they are, they would
require a lot of memory).

International characters in macro names are not case independent.

Case-independent string matching operations (e.g. SET INPUT CASE IGNORE,
IF EQUAL xxx yyy) won't necessarily work with international characters.

= JAPANESE KANJI

MS-DOS Kermit supports translation of Japanese Kanji during file transfer.
The Japanese Kanji code page for PCs is CP982 (this is the FILE CHARACTER-SET).
The Kanji code on the wire (in the file transfer packets) is Japanese Extended
UNIX Code (EUC) -- SET TRANSFER CHARACTER-SET JAPANESE-EUC.

At present, however, MS-DOS Kermit does not support Japanese Kanji
character-set translation during terminal emulation.  However, version 3.13 of
MS-DOS Kermit does support the Kanji video mode used on IBM-compatible DOS/V
PCs, which allows Kanji terminal emulation if the remote character set happens
to be Shift-JIS (CP982).

Special Japanese-model IBM PCs have Kanji fonts in firmware, allowing display
of Kanji characters in both Japanese-DOS and Japanese-DOS/V.

It is also possible to display Kanji on USA-model IBM PCs and compatibles with
VGA adapters.  In this case, Japanese-DOS/V (not Japanese-DOS) must be used.
More precisely, you can display Kanji even in English DOS/V if you have the
Japanese font (software) driver and Japanese (software) keyinput driver (you
can even use the 101 English keyboad).  Japanese-DOS/V is a revolutionary
operating system that opens the Japanese IBM-PC market.  Prior to DOS/V,
Japanese had to buy an expensive special Kanji PC models that could not run
English applications.  Japanese DOS/V consists of:

  Baseline DOS/V
  + Japanese font driver
  + Japanese fonts
  + Japanese keyinput driver
  + Japanese dictionary

The Japanese font driver displays Japanese characters in VGA 640 x 480 graphic
mode, and sometimes it might conflict with English applications.  However you
can easily switch back and forth because the baseline DOS/V is the same.

= COMMAND PROCESSING

Kermit's backslash-code processing will produce unexpected results when you
have a file or directory name that starts with a digit.  For example, if
Kermit's command processor sees the string "C:\4DOS", it translates the "\4"
into a Control-D character and will not find the 4DOS directory.  At present,
the only workaround for this situation is to avoid starting directory or
filenames with digits.

When a command field begins with the @ (at-sign) character, the following
characters are interpreted as a filename that contains the rest of the
command.  If you need to type a command field that actually starts with @, or
respond to an ASK or ASKQ query with text that starts with an atsign, you have
to encode the atsign as \64 or \{64}.

\B in an OUTPUT command tells Kermit to send a BREAK.  \L Tells Kermit to
send a Long BREAK.  If you need to output \B or \L literally, use two OUTPUT
statements, e.g.:

  define xbreak pause 1, output +++, pause 1, output AT\92, output B, -
    pause 1, output ATO\13, connect
  set key <key-of-your-choice> {\Kxbreak}

Notice that the backslash itself is written as "\92" to output it literally.

Certain commands, such as RUN, DIRECTORY, TYPE, etc, invoke COMMAND.COM
"underneath" Kermit, and COMMAND.COM might, in turn, invoke other programs.
If you get the message "Can't run program" in response to such a command, it
usually means there is not enough memory.  But you should also check your
SHELL environment variable.

When you RUN a program from within KERMIT, using the RUN command, there is no
way to access the program's return code.  In particular, Kermit's ERRORLEVEL
variable does not reflect the program's return code.  Kermit must RUN programs
through COMMAND.COM, and COMMAND.COM does not pass along the program's return
code to Kermit.

If you include the word STAY anywhere on the Kermit command line, e.g.:

  kermit echo stay

it is interpreted as a STAY command.

A command file that contains lines or commands too long for DOS's line buffer
(usually 128 characters) can hang your PC: a DOS problem, not a Kermit problem.

Commands in command files can be continued by including "-" as the last
character on the line, but NOT if the line ends with a trailing comment.  In
other words, you can't have a trailing comment on a continued line. If you
need to end a line with a dash, but the dash is part of the command rather
than a continuation symbol, use \45 instead or add a trailing comment.

Trailing comments can be used only in command files.  All text starting with
the first semicolon through the end of line is ignored.     If you need to include
an actual semicolon in a command, precede it with a backslash (\;).

The name and password that you specify in SET SERVER LOGIN must be matched
exactly by the ones in REMOTE LOGIN.  Case matters.  If you need to include
spaces within the username, password, or account field of the REMOTE LOGIN or
SET SERVER LOGIN commands, surround the field with {braces}.

DISABLE ALL is not equivalent to all the other DISABLE commands given
separately.  For example, DISABLE DELETE restricts REMOTE DELETE commands from
the client to working only in the MS-DOS Kermit server's current directory,
while DISABLE ALL prevents all types of modifications to the PC's file system,
including file deletion and creation.

= KEY MACROS

Version 3.13, unlike previous versions, attempts to recognize the difference
between between Space, Shift-Space, Ctrl-Space, Alt-Space, etc, so that SHOW
KEY shows different scan codes for each combination of Space with modifier
keys (a common request was to be able to SET KEY Ctrl-Space to send NUL).  An
unanticipated side effect of this change was that unmodified Space returns a
strange scan code when seen through the LK250 driver.  The cure is to add:

  IF EQ \v(keyboard) 250 IF > \v(version) 312 SET KEY \313 \32

to your MSKERMIT.INI file (this was added to the standard MSKERMIT.INI file
on September 9, 1993).

Key macros are executed while in CONNECT mode.  If you assign the \Khangup verb
to a key, Kermit remains in CONNECT mode after the hangup takes place.  On a
serial dialup connection, Kermit turns off the DTR signal, and you should see
a confirmation message from the modem, such as NO CARRIER, on your screen.  On
a TCP/IP network connection, however, Kermit does indeed drop the connection,
but since Kermit is still in CONNECT mode, it is immediately reestablished.
If you want to terminate a network session by pressing a key, use a method
that leaves CONNECT mode.  You can do this by defining a macro to hang up, and
then assigning execution of the macro to the key, e.g. Alt-d:

  define xxx hangup
  set key \2336 {\Kxxx}

This causes Kermit to return from CONNECT mode and execute the macro without
returning to CONNECT mode.  This technique works for both serial and network
connections.

To assign several verbs to a single key, use braces as in this example:

  set key \315 {\{Kgold}\{KdecF13}}

or this:

  set key \315 {\{Kfoo}\{Kdump}\{Kbar}}

in which "foo" and "bar" are macro names, and \Kdump is Kermit's screen-dump
verb.

= FILE TRANSFER

When using modems that do data compression, be sure to (a) use hardware flow
control (SET FLOW RTS/CTS); (b) set your serial port speed higher
(preferably at least 4 times higher) than the modem's connection speed; for
example, use SET SPEED 57600 for 14400 bps modems; (c) lock the modem's
interface speed.  The dialing script files for high speed modems, such as
PP14400.SCR, do all of this for you automatically.

Even when using RTS/CTS flow control, it is possible that characters will be
lost during file transfer.  This can happen if the PC turns off interrupts for
any length of time, e.g. to service the hard disk -- especially if you have a
disk-caching program active.  It can also happen if you have loaded the DOS
PRINT TSR, or a screen saver, or any of various other TSRs.  In such cases,
Kermit never gets the interrupt that signals a character has arrived, and so
cannot service it, and so Kermit's input buffer does not begin to fill up,
and so Kermit does not activate flow control.  The standard advice here is
to remove TSRs.  Also check that your PC is using "Fast A20 Gate" switching to
protected mode for items loaded above 1MB, such as RAM disks, etc, to prevent
slow keyboard controller equivalent from making the PC deaf during disk
activity.

The efficiency reported at the end of a file transfer is relative to the
serial port speed.  This can be confusing and/or misleading when using a modem
whose connection speed to the other modem is different from the serial port
speed, especially when the modems are also doing compression.

At present, there is no way to disable the "dynamic packet length" feature.

The transaction logging feature is somewhat broken in version 3.13; names of
received files in a file group are not recorded, e.g. during a GET *.*
operation.  This will be fixed in the next release.

SET EOF CTRL-Z, when used with text files that actually contain Ctrl-Zs, might
result in gaps or truncation in the vicinity of the Ctrl-Z.  This is a DOS
feature.

If the remote Kermit sends a file whose name (the part before the period)
corresponds to a DOS device name, such as CON, PRN, etc, the incoming file
will be sent to that device rather than being stored on disk.  This is a
feature of DOS.

When using Kermit through a terminal server (particularly those that execute
the TCP/IP Telnet protocol), or directly through a SET PORT TCP connection, it
is sometimes necessary to SET PARITY SPACE for file transfer. It is sometimes
impossible to use very long packets with terminal servers.  Try SET RECEIVE
PACKET-LENGTH 80, working up or down to the longest length that works.

REMOTE TYPE and other REMOTE commands resulting in an error "Unable to open
CON": insufficient FILES= in CONFIG.SYS.  FILES= should be at least 20.

The MS-DOS Kermit command REMOTE SET BLOCK-CHECK will generally have no effect
upon a remote server unless the SET BLOCK-CHECK is also given locally to
MS-DOS Kermit.

The host prompt for TRANSMIT is a single character (SET TRANSMIT PROMPT).  It
is not possible to specify a multi-character or varying transmit-prompt.

= SCRIPT PROGRAMMING

Many users have observed that it is difficult to interrupt the execution of
a script program, such as MS-DOS Kermit's dialing scripts.  Typing Ctrl-C or
Ctrl-Break does not have an immediate effect; these are noticed only when
Kermit asks DOS to read from (or check the status of) the keyboard, and only
certain Kermit commands do this.  Of these, the most useful is PAUSE, which
fails if any key is pressed during the PAUSE interval.  So if you want your
script program to be nicely interruptible, you can include the following two
commands at key points in the program:

  PAUSE 1
  IF FAIL STOP 1 Interrupted

You can increase the frequency with which DOS checks for Ctrl-C or Ctrl-Break
by including a BREAK=ON statement in your CONFIG.SYS file.

The terminal emulator is active only when MS-DOS Kermit is in CONNECT mode
(and when it is executing the REPLAY command).  Thus it is NOT active during
execution of script commands such as INPUT and OUTPUT.  This means:

 1. If the host sends the escape sequence that tells the terminal to identify
    itself, it is ignored.  You have to put the appropriate INPUT and OUTPUT
    commands in your script program.  Here is a macro to set your terminal type
    in Kermit and to set up the appropriate response string as well as terminal
    type string:

    def term if not def \%1 def \%1 \v(term),-
      set term type \%1,-
      if fail end 1,-
      assign _ttype \%1,-
      if eq \%1 vt320 assi _tid \27[\{63}63\\\;1\\\;2\\\;4\\\;8\\\;9\\\;15c,-
      if eq \%1 vt220 assi _tid \27[\{63}62\\\;1\\\;2\\\;4\\\;8\\\;9\\\;15c,-
      if eq \%1 vt102 assi _tid \27[\{63}6c,-
      if eq \%1 vt100 assi _tid \27[\{63}1c,-
      if eq \%1 vt52  assi _tid \27/Z

    Whenever you switch terminal emulations, do "term vt102" instead of "set
    term type vt102" (substitute your preferred terminal type).     In any script
    that responds to ESC Z (or whatever), have it "output \m(_tid)", and any
    prompt that asks for your terminal type you can "output \m(_ttype)".  And
    be sure to execute a "term" command in your MSKERMIT.INI file, so your
    initial terminal type is set.

 2. If the host sends escape sequences to set up or configure the terminal,
    these too are ignored; i.e. they have no effect on Kermit's terminal
    emulator.

 3. A host-generated escape to put the terminal in Tektronix mode has no
    effect.  Put explicit SET TERMINAL TYPE TEK commands in the appropriate
    places in your script program.

 4. Screen formatting escape sequences have no effect.    If you have SET INPUT
    ECHO ON, they are simply displayed as-is.

If the remote host is sending ANSI (VTxxx) escape sequences during execution of
the script program, then users of IBM PCs can use the ANSI.SYS or similar
console driver to interpret the escape sequences.  This is particularly useful
when running a script that logs in to a full-screen system, such as an IBM
mainframe through a protocol converter.     But beware: ANSI.SYS is not totally
compatible with Kermit's VT emulator, and it may produce unwanted side effects,
the most annoying of which is suddenly popping your PC into 40-column mode!  If
you experience difficulties with your screen display while using Kermit script
programs, use SET INPUT ECHO OFF.  Or remove ANSI.SYS from your CONFIG.SYS file
and reboot.

PAUSE, WAIT, and similar commands also open the connection on the currently
selected port if it is not open already.  For example, SET PORT TCP <host>
does not open the connection itself -- the first input/output command
(including PAUSE) will do it.  Similarly, if DTR is not asserted on a serial
connection, PAUSE will assert it.

PAUSE, WAIT, and similar commands also cause port input to be echoed to the
screen if INPUT ECHO is ON.  Use SET INPUT ECHO OFF to defeat this effect.

If the REINPUT command fails to find the requested text in the INPUT command
buffer, it will wait (up to the timeout interval) for more characters to
arrive from the communication channel.

INPUT / REINPUT combinations will not work if the INPUT buffer is smaller than
the amount of text that separates the INPUT text from the REINPUT text.  You
can increase the size of the INPUT buffer by including the desired size in
your KERMIT=INPUT <size> environment variable.  The default size is 256 bytes.

Script programming hint: To test whether a readable floppy disk is available
in drive A:, do this:

  SPACE A:
  IF FAILURE ECHO No diskette in drive A:.

The ON_EXIT macro is intended only for automatic execution when MS-DOS Kermit
exits.  It only works once, to prevent recursion (as would happen, for
example, if you put an EXIT command in your ON_EXIT definition).

= MEMORY MANAGEMENT

MS-DOS Kermit, like any DOS or Windows program, is likely to misbehave if your
PC memory is insufficient or is incorrectly configured.  MS-DOS Kermit runs in
conventional memory (the first 640K) of your PC.  It occupies about 280K
initially, and then allocates additional memory as needed for rollback
screens, file-transfer packet buffers, etc.  Kermit uses additional memory to
execute certain commands such as TYPE and DIRECTORY, for which it invokes a
second copy of COMMAND.COM (appoximately 30K) in conventional memory, as well
as RUN, which can invoke not only COMMAND.COM, but an additional program to be
run by COMMAND.COM, for example "run edit".  If there is insufficient memory,
these operations will not work; thus it is always best to have as much free
conventional memory as possible.

Memory for file-transfer packets is allocated at the time the transfer begins,
based on the current sliding-window size (SET WINDOW) and packet-length (SET
RECEIVE PACKET-LENGTH), and is deallocated when the transfer ends.  So SHOW
MEMORY won't reveal the effect of the packet buffers.  If insufficient memory
is available for the requested window size and packet length, MS-DOS Kermit
automatically reduces its RECEIVE PACKET-LENGTH.  For maximum file-transfer
efficiency, conventional memory is always used for packet buffers. Thus packet
buffers and RUN/PUSH/TYPE/ DIRECTORY commands "time-share" the same
conventional memory.

Memory for graphics screens is taken from your video display adapter.  Storage
of graphics images in the video adapter's on-board memory allows rapid
switching between text and graphics screens provided (a) your video has
sufficient memory, (b) the memory is not "mapped away", and (c) you are not
running Kermit under Windows.  Video adapter memory is generally in segments
A000-BFFF.

Memory for rollback screens is allocated when the CONNECT command is first
given, i.e. when Kermit first displays its terminal emulation window, and
remains allocated until you EXIT from Kermit.  This can be demonstrated by
starting Kermit, giving the command SHOW MEMORY, then giving the CONNECT
command, then escaping back (Alt-x), and then giving the SHOW MEMORY command
again -- see how available memory has shrunk.  Approximately 4K is required
per 24x80 rollback screen (more for bigger screens).  The default number of
rollback screens is 10, but the number can be set to practically any value at
all (0 or greater) by giving the following command to DOS before you start
Kermit (interactively, or in your AUTOEXEC.BAT file):

  SET KERMIT=ROLLBACK 40

The smaller the number, the less memory required; the bigger, the more memory.
In version 3.13, you can also give the new command:

  SET ROLLBACK <number-of-screens>

at the MS-Kermit prompt at any time, and the rollback memory will be adjusted
when you next CONNECT.

A large number of rollback screens can crowd out other possibilities, like the
ability to use Kermit's RUN, PUSH, TYPE, DIRECTORY, and other commands that
run inferior processes.  Version 3.13 of MS-DOS Kermit lets you store your
rollback screens in Expanded Memory (EMS) if you have more than 1MB of
physical memory and you have an expanded memory manager for it like
Quarterdeck QEMM or EMM386 and HIMEM that come with DOS 5.0 and Windows 3.1.

Using expanded memory for rollback screens frees 40K of conventional memory if
you are using the default number (10) of rollback screens, and it also allows
you to have a much larger number of rollback screens.  The following steps are
required to keep your rollback screens in expanded memory:

1. Make sure the desired amount of expanded (EMS) (not "extended", or XMS)
   memory is available.     The DOS MEM command will tell you this.

2. In your AUTOEXEC.BAT file, set the desired number of Kermit rollback
   screens.  For example, for 250 screens (requiring about 1 megabyte):

      SET KERMIT=ROLLBACK 250

3. Give the following command to MS-DOS Kermit:

      SET TERMINAL EXPANDED-MEMORY ON

   If this command fails, Kermit prints an appropriate error message.

Now start a Kermit session, scroll some text off the screen during CONNECT
mode, and check the operation of the PageUp/PageDown keys.  If they work,
you're done.  And as an added benefit, graphics screens will also be stored
in expanded memory, allowing you to switch between graphics and text screens
(Alt-minus), even under Windows, without losing the graphics screen.

If it doesn't work, then welcome to the bewildering world of DOS memory
management.  The most common symptom of a bad memory configuration is that
your PC will freeze the first time Kermit tries to scroll a line off the
screen or the first time it tries to clear the screen.    Now you should begin
looking at your CONFIG.SYS file.

First, here is a straightforward DOS 5.0 CONFIG.SYS configuration that sets up
a PC with 8MB of memory to have 6MB of expanded memory:

  DEVICE=C:\DOS\HIMEM.SYS
  DEVICE=C:\DOS\EMM386.EXE 6144 RAM
  DOS=HIGH,UMB
  DEVICEHIGH=C:\DOS\ANSI.SYS

HIMEM.SYS must be loaded first and then EMM386.     With memory management now
active, DOS is told to use "high memory" (don't ask) and "upper memory blocks"
(UMB, the space between 640K and 1MB) and then ANSI.SYS is loaded into the
upper memory area rather than conventional memory.

EMM386 is asked to take care of 6144K of expanded (EMS) (not extended, XMS)
memory, and the RAM switch means that it also should manage the upper memory
blocks.     This configuration works on a PC that has 8MB of memory (6144K =
6MB = 1024 x 6), leaving 1MB of extended memory for any process that might need
it.  If you have less memory than that, adjust as appropriate.

If you are using RAMDRIVE.SYS, give it the /A switch to use expAnded memory,
rather than the /E switch for extEnded memory, e.g.:

  DEVICEHIGH=C:\WINDOWS\RAMDRIVE.SYS 1024 512 64 /A

After making these changes to CONFIG.SYS, reboot your PC and give a DOS MEM
command to check that the needed amount of Expanded (EMS) memory is available.

Now run Kermit and check the expanded-memory rollback feature. Also tell
Kermit to SHOW MEMORY to see how much conventional memory remains after
starting Kermit.  If it's not enough for your purposes, look at your
CONFIG.SYS and AUTOEXEC.BAT files to see if there are any other drivers or
TSRs that can be removed or loaded high.  Here's another hint: If you access a
CD-ROM drive via Microsoft CD Extensions, include the /E switch (Expanded)
when you start it up:

  C:\BIN\MSCDEX /E /D:MSCD000 /M:10

In a more complicated configuration, suppose you have a network interface
board that uses a certain segment of memory (at, for example, segment address
CC00) which conflicts with DOS's memory management (note: addresses are
usually written in hexadecimal).  In that case, you have to tell EMM386 to
"exclude" this segment from its memory managing:

  DEVICE=C:\DOS\EMM386.EXE 6144 x=cc00-cc7f RAM

These segment address numbers are obtained from the technical manual for your
network interface board (or, perhaps more likely, from the board vendor's
technical support phone number).  Additional "exclude" clauses might be
needed for other boards or adapters.

For debugging, get additional information about your PC's memory layout using
the DOS MEM/C and MEM/P commands, the MSD program that comes with Microsoft
Windows, or the MFT (Manifest) program that comes with Quarterdeck QEMM.

If all else fails, tell Kermit to SET TERMINAL EXPANDED-MEMORY OFF (this is
the default anyway).  NOTE: whenever you switch Kermit's expanded memory
status from OFF to ON or vice versa, your previous rollback screens are lost.

Use caution with QEMM v6 "Stealth (ST:M) optimization".     This prevents Kermit
from accessing your video board's BIOS memory and finding the video board's
signature, and therefore from determining the appropriate method for switching
between 80 and 132 columns.  Most boards have a signature string within the
first 200h bytes of the video BIOS and excluding that much from stealth mode
should be sufficient to preserve the identification information.

= INTERACTIONS WITH DOS

A few users have reported that Kermit crashes with a "divide overflow" error.
It is believed that this happens when Kermit attempts to calibrate a software
timing loop that is independent of the speed of the computer by accessing the
system timer chip.  The speculation is that some external entity, a TSR
perhaps (maybe a screen saver), is reprogramming the timer chip out from under
Kermit.  Other common causes revolve around memory management, particularly
preventing the manager from stepping on either the LAN adapter or on video
memory (segments A000-BFFF).  Some screen savers, ANSI.SYS replacments,
keyboard helpers can contribute to too.  Print spoolers won't help things, nor
will disk cache programs.  Bus speed ought to be set to 8MHz and the number of
wait states should not stress the hardware.  etc etc.

The limit on your DOS PATH string is 127 characters.  If you add, say,
C:\KERMIT to the end of you your PATH= statement in AUTOEXEC.BAT, and that
makes it longer than 127, DOS (and Kermit's TAKE and similar commands) won't
be able to find your Kermit files.

All sorts of problems can occur when there are problems with your DOS PATH.
Kermit won't be able to find its TAKE files, INI files, patch files, etc.
Reportedly, when PCs are connected to Novell networks, "if there is not both a
system and a personal NetWare login script, however brief, then the default
LOGIN.EXE script will eat your DOS Path.  Be aware that DOS 6.2 has some
funnies about handling autoexec.bat and the master environment.  Also ensure
you are running without SETVER affecting the NetWare shells (i.e. use the
proper NetWare shell so no SETVER is needed)."

A REMOTE HOST or similar command sent to an MS-DOS Kermit server can invoke the
DOS critical error handler, which issues its familiar "Abort, Ignore, Retry?"
message on its real screen, and is waiting for a response from its own real
keyboard, and so the server will no longer respond.  Kermit attempts to catch
many of these errors before DOS learns learns about them, but some cannot be
avoided (like disk i/o errors).

Similarly, a REMOTE DIRECTORY command sent to an MS-DOS Kermit server can
cause the server to hang if its default directory command pauses after each
screen (DIRCMD=/P).  In fact, the server will hang any time a subprocess
invoked by any REMOTE command (watch out, in particular, for REMOTE HOST)
requests keyboard input.

MS-DOS Kermit uses the program named in the DOS Environment command line
starting as SHELL= as a replacement for COMMAND.COM.  Such a line is seen by
typing SET at the DOS prompt, and it is not associated with the SHELL= line
appearing in file CONFIG.SYS.

Interaction between MS-DOS Kermit and various terminate-and-stay-resident
(TSR) programs is necessarily unpredictable.  Console, mouse, clock, or
graphics drivers might interfere with file transfer, e.g. the CMOSCLK.SYS
driver on the PS/2 model 55SX.  If TSR programs are interfering with Kermit
(e.g. by taking over the timer or serial port interrupts), you should remove
them all from your AUTOEXEC.BAT or CONFIG.SYS files, and then put them back
one by one until you have identified the culprit.

Mouse drivers are particularly notorious in this respect.  Suggestion: don't
load your mouse driver in CONFIG.SYS or AUTOEXEC.BAT.  Instead, load it
manually when you need to use the mouse, unload it or turn it off when you are
finished with the mouse.  Most mouse drivers allow this.

Use caution when invoking certain TSR programs while PUSHed from Kermit
(e.g. using the PRINT command for the first time), as not all of these
programs observe proper etiquette for allocating and freeing memory, and the
TSRs will be loaded above Kermit into the middle of memory where they may
prevent large programs from loading later.

Beware of console drivers other than the real ANSI.SYS that is supplied with
DOS.  Many of the public domain, shareware, or third-party commercial console
drivers interfere not only with the screen and keyboard while Kermit is
active, but some of them also interfere with the communications port.

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

Date: 7 FEB 86 10:51-MST
From: JRD@USU
Subject: Dashed Cursor Problem on IBM PC

On early (original motherboard & BIOS) PCs, and on systems that mimic them
(e.g. early Compaqs), the cursor may assume a strange shape (e.g. minus sign)
upon return from CONNECT.  This is caused by a bug in the early BIOS, which
stored cursor attributes incorrectly.

The PC Tech Journal article discussing the problem is "The Dashed Cursor",
by Paul Pierce, PC Tech J., Dec. 1985, page 47. His code goes like this:
---(cut)---
;
; Program FIXCURS.ASM by Paul Pierce, PC Tech Journal, Dec 1985, page 47.
;
code    segment public 'code'
        assume cs:code, ds:code, es:nothing
;
;       This program is set up to be made into a COM file
;
        org     100H
;
; First check for the monochrome adapter.
;
start:  int     11H             ; set ax = equipment flag
        and     al,30H          ; mask off all but video bits
        cmp     al,30H          ; test for monochrome adapter
        jne     exit            ; jump if not monochrome
;
; Now check for incorrect cursor mode returned from the Bios
;
        mov     ah,3            ; call bios to get cursor type
        int     10H             ;
        cmp     cx,0607H        ; check for invalid (color) type
        jne     exit            ; jump if not a bad value
;
; At this point we know that the monochrome adapter is in use and that
; the bios cursor mode is incorrect.
; Call the bios to set the cursor type correctly.
;
        mov     cx,080cH        ; use correct cursor type
        mov     ah,1            ; call bios to set cursor type
        int     10H

exit:   mov     ah,0            ; exit back to DOS
        int     21H

code    ends
        end     start
---(cut)---
Here is the executable CURSOR.COM program, uuencoded (decode with uudecode):
---(cut)---
begin 644 CURSOR.COM
=S1$D,#PP=1&T`\T0@?D'!G4'N0P(M`'-$+0`S2$`/
``
end
---(cut)---
and here again as a BOO file (decode with MSBPCT.EXE):
---(cut)---
CURSOR.COM
cA4T<3``MA6d0ld@POT71WD7^@`8]07=4;@0cB40~0
---(cut)---

= NETWORKS

When communicating across certain network pathways, the longest burst of
information tolerated from the PC can be rather short. For example, the LAT
path with SET PORT DECNET (PATHWORKS) has a limit of 256 bytes and the SET
PORT TES path has a limit of 512 bytes in a burst (or less, depending on the
TES release).  Longer bursts can cause the network software on one end or the
other to drop the connection.  This is most likely in the following situations:

 1. During file transfer, when sending files from the PC using long packets
    and/or sliding windows.  The total size of the packets in the window
    (packet length times the number of window slots) must be less than the
    burst limit for the network.

 2. During VT320 terminal emulation, if the host application (such as VMS
    or UNIX WordPerfect) sends a Terminal State or Color Palette Request
    escape sequence, DECRQTSR, "ESC [ 2 ; 2 $ u".  The response to this
    request is more than 200 characters long and has been known to break
    LAT and TES connections.

This is not a Kermit problem, but rather a limitation (or bug) in the
underlying networking method.  Workarounds include:

 1. If you have a DECnet LAT connection, make a DECnet CTERM connection
    instead (i.e. unload your LAT.EXE TSR and load the CTERM TSR instead).

 2. Enable RTS/CTS flow control between MS-DOS Kermit and the device it is
    most immediately connected to, if possible.     Otherwise, enable Xon/Xoff
    flow control in MS-DOS Kermit and at the host on the far end (e.g. tell
    VMS to SET TERM/HOSTSYNC/TTSYNC).

 3. Use a different networking method, e.g. TCP/IP instead of DECnet.

DECnet/DOS PATHWORKS LAT.EXE is a protocol stack sitting on the top of the
DECnet stack and is independent of LAN adapter providing LAT (Local Area
Transport) service, primarily intended for terminal emulation over Ethernet.
Different versions of PATHWORKS come with different versions of LAT.EXE, which
work differently.  If you have trouble with LAT.EXE, try loading it in
conventional memory rather than expanded memory.

On DEC PATHWORKS LAT connections, it is often necessary to tell the LAT
control program on the PC to reserve enough memory for all of the local LAT
host names.  By default, space for 16 names is allocated.  Increase your LAT
control program's memory allocation if you have more than 16 hosts on your
DECnet network.  Also, remove ALL permanent LAT names from your database and
let the network provide them (this can mean waiting a minute or two for all
broadcasts to be heard).

When making LAT connections from within Windows, either make sure LAT is
loaded in conventional memory (recommended), or else that you have installed
Patch 14 (described at the top of this file, normally commented out).  Note
that under Windows, several copies of Kermit can be run simultaneously, each
of them with a separate LAT connection, if LAT has been configured to provide
the neccessary session control blocks (SCBs) to handle extra sessions.

If you see the "network not available" message when attempting to SET PORT
DECNET: (1) make sure that LAT, CTERM, or both are loaded; (b) if you loaded
LAT into expanded memory, make sure it does not conflict with the memory
usage of other devices, e.g. A000-BFFF for the video adapter; and (c) that
you have allocated sufficient SCBs and hostname table space.

To use PATHWORKS and Kermit's built-in TCP/IP support at the same time, use
the PKTDLL shim, available in Columbia University's packet-driver collection.

Sending BREAK over network connections via SET PORT BIOS1 + Int 14h
interceptor may or may not work, depending upon the actual network and drivers
in use.     Kermit uses the BREAK facility if the driver and network support it.

Kermit has no way to set or show the speed or parity used by a Novell
NASI/NACS communications server.  However, you should be able to do this from
the NASI menu.

Reportedly, when running Kermit on DOS 6.0 client on a Novell 3.11 network
with a NASI 3.0 Communications server, Windows 3.1 crashes upon exiting Kermit.
Reportedly, removing EMM386.EXE from the CONFIG.SYS file fixed the problem.

Symptom: PC no longer works after installing a network board.  Diagnosis: a
16-bit VGA display adapter is running in 16-bit mode.  Cure: Jumper it back to
8 bits and all should start working again.

PC-NFS prevents applications programs such as Kermit from creating a file in
the root directory of a PC-NFS disk drive.  When the applications program asks
if a particular file exists in the root, PC-NFS always responds with "volume
label present", whether or not the actual file is present.

MS-DOS Kermit 3.13 and later no longer supports SET PORT TELAPI for Novell LAN
Workplace for DOS (LWP) versions prior to 4.0.  Versions 3 and 4 are
incompatible (from the Kermit support point of view), and version 3.x had
many internal difficulties.  If you need to make SET PORT TELAPI connections
with Kermit, either upgrade your LWP software, or use an older version of
Kermit.

You can't run LAN Workplace for DOS (LWP) and make SET PORT TCP/IP connections
with Kermit at the same time, because only one protocol stack of a given kind
can run over a single network board.  If you want to make a TCP/IP connection
with Kermit when LWP is loaded you can either (a) use SET PORT TELAPI rather
than SET PORT TCP/IP (slower and less flexible), or (b) unload LWP from the
DOS prompt by typing TELAPI UNLOAD and TCPIP UNLOAD, and then start Kermit.

The SET PORT TELAPI command does not allow specification of a TCP port
number, only a host address.

SET PORT TELAPI performance is good with version 4 of Novell's LAN WorkPlace
for DOS but it is poor with version 3.5 because that older version sends each
Kermit byte in an individual packet.  Because the TELAPI interface lacks the
ability to resolve Internet, names you can use the small Kermit macro below to
invoke Novell's program TSU to resolve names and set up a session:

  define telapi run tsu -o \%1 k1,run tsu -a k1 1,set port bios1

Use as Kermit command "telapi my.favorite.host" followed by CONNECT.  This
tells TSU to "o"pen a connection to the host named in Kermit variable \%1 and
give the session a TSU tag of "k1".  Then run TSU again and "a"ttach this
session to COM"1" meaning Kermit's BIOS1 port.    Four sessions can be started
by choosing different tags and port numbers, though this macro does not make
the changes.  An alternative to SET PORT BIOS1 is SET PORT 3COM for much
faster throughput; an end-of-session signal is not available with this method
so the user must exit manually.

One user reported that SET PORT TELAPI did not work with LWP 4.1 ("No
connection; Status = -8108").  This was traced to the LWP 4.1 INSTALL not
loading TELAPI.  After loading TELAPI, everything worked fine.

The Interconnections TES product, which Kermit fully supports, has a fancy
menu that pops up if you type the TES "hot key", Alt-LeftShift-T.  Reportedly,
this pop-up menu interferes with the LK250 driver that is distributed with
Kermit (it works fine with regular IBM keyboards).  The LK250 driver uses a
special interrupt, and the TES menu program might not properly chain this
interrupt.  The workaround is to use TES's text-mode menu, which Kermit brings
up if you type Alt-Home during terminal emulation.  Version 3.13 of MS-DOS
Kermit transparently supports both older and the latest TES products.

However, note that TES itself is somewhat fragile, and does not handle long
bursts of data very well.  So when using the TES path, keep your packet
lengths short.  Also, when using MS-DOS Kermit 3.13 and any of the later
versions of TES that are based on LAT (TES 3.0 or later?), do NOT enable
MS-DOS Kermit 3.13 Patch 14 -- just comment it out or remove it from the
MSR313.PCH file.

Reportedly, when making NETBIOS or 3COM(BAPI) connections under Windows,
characters from a DOS window can show up in the Kermit window.  Reportedly,
this can be fixed by setting Kermit's foreground and background priority to
150 and setting the priority of the other DOS applications to 5000.

NETBIOS STATION-TO-STATION CONNECTIONS

The procedure for establishing a NETBIOS PC-to-PC connection is as follows:

 1. On the first PC:
      SET NETBIOS NAME <xxx>
      SET PORT NETBIOS
      SERVER

 2. On the second PC:
      SET PORT NETBIOS <xxx>.K

(<xxx> is any name you choose, up to 14 characters long.)

Now you can initiate file transfer and other Kermit protocol operations from
the second PC.    If you want the two PCs to "chat" in terminal mode, send a
FINISH command from the second PC (or type Ctrl-C on the first, server, PC),
and then give the following commands to both PCs:

  SET TERMINAL NEWLINE ON
  SET LOCAL-ECHO ON
  CONNECT


TCP/IP SUPPORT

As of version 3.11, MS-DOS Kermit contains built-in TCP/IP and TELNET protocol
support.  This allows a PC equipped with an Ethernet or other network board
that is connected to a TCP/IP network to communicate with any other node on
the network, without requiring any additional TCP/IP software on your PC.  You
need an external Ethernet-style (Class 1) packet driver for your network
interface board, or (as of version 3.12) a SLIP Packet Driver or a Novell ODI
driver, or (as of version 3.13) the Novell SLIP_PPP ODI driver.     You can also
use any of various "shims" to sit between Kermit and other kinds of board
drivers (e.g. NDIS) to make them look to Kermit like Ethernet packet drivers.

Kermit always registers for the ARP and IP protocols.  In addition, but only
if you gave the command SET TCP ADDRESS RARP, it will also register for RARP.
Remember the rule:

  ONLY ONE APPLICATION PER PROTOCOL PER NETWORK BOARD!

That's why you can't run (say) PC-NFS and Kermit TCP/IP connections at
the same time.  Here are some hints for getting around this:

 . If PC-NFS comes with an Interrupt-14 redirector (similar to FTP
   Software's TNGLASS program), you can use that in conjunction with
   Kermit's SET PORT BIOS1.  Not as good Kermit's built-in TCP/IP
   TELNET, but better than nothing.

 . You can experiment with the PKTMUX driver.  This is supposed to let
   multiple TCP/IP stacks share the same network board.  Nobody knows
   very much about this, and a quick glance at the user manual is more
   than a little bit scary.  You can find PKTMUX on kermit.columbia.edu,
   directory packet-drivers/new, files pktdrv.exe and pktmux*.*.

 . You can install a second network board and give one to PC-NFS and
   the other to Kermit.  This is actually the best choice -- network
   boards don't cost much these days, especially compared to value of the
   amount of time you'd have to spend futzing with the other approaches.

With ODI, Kermit's Telnet operates across Ethernet (many frame kinds), Token
Ring, Arcnet, and PCnet.  Kermit does not contain built-in network device
drivers.  Packet drivers are available from network interface manufacturers,
and via anonymous FTP from Columbia University, host watsun.cc.columbia.edu
[128.59.39.2], cd packet-drivers, get the READ.ME file, read it, and take it
from there.  These files, now called the Crynwr packet driver collection, are
also available from Columbia University via mail order.     ODI drivers are
available from makers of the LAN adapter and in some cases from Novell.     See
Novell archive "novlib" on CompuServe and on machines ftp.is.sandy.novell.com
[137.65.12.2] and mirrors such as netlab2.usu.edu [129.123.1.44] for Novell
supplied ODI drivers.

The TCP/IP code in this version of Kermit has been tested successfully with at
least the following boards and packet drivers (according to reports from
users):

  Ungermann-Bass PC/NIC board with Clarkson UBNICPC packet driver 9.1
  3COM 3C501 with Clarkson 3C501 packet driver 5.0.
  3COM 3C503 with Clarkson 3C503 packet driver 9.4.0.
  Western Digital WD8003E with Crynwr (not WD) WD8003E packet driver 9.7.0
  Cabletron 2000 and 3000 series DNI boards with CSIPD_E 1.0x and later packet
    drivers on unshielded twisted pair, thin Ethernet, and thick Ethernet,
    on both PC/AT and Microchannel buses.
  Micom-Racal NI5210 with NI5210 packet driver.
  AT&T EN100 with Clarkson AT&T packet driver.
  IBMTOKEN.COM 3C501 emulation packet driver 1.9 over various Token Ring
    boards and drivers.
  DIS_PKT over NDIS for LAN Manager networks and NDIS-compliant boards
    including SD8003, 3C503, AT&T 10MB/sec thinwire
  Harvard ODIPKT over LSL, LANSUP, and IPXODI over Ethernet (but not
    Token Ring)
  Novell NE2000 with Crynwr NE2000 packet driver (not the Novell MLID!)

Token Ring, Arcnet, and LocalTalk packet drivers are not supported, as they
are not Ethernet- or SLIP-class Packet drivers.

The performance of the 3C50x packet drivers is poor, but the operation seems
correct.  Suggestion from a 3COM 3C503 Ethernet board user: "When installing
the packet driver for 3Com 503 cards, one has to pay attention that the memory
option on the card is not disabled.  It was in my case, and the packet-driver
did not complain.  Since other drivers (e.g.  the DEC PATHWORKS driver) do not
require the memory enabled, the default is disabled."

Reportedly, the packet driver supplied by Western Digital with their WD8003E
and/or Elite network boards cannot be found by Kermit.    The Crynwr WD8003E
packet driver, however, works correctly with both the WD8003E and Elite boards.
Same comments apply to WD8003E.SYS shipped with PC-NFS.

To reconfigure a Novell network (NetWare 3.xx or earlier) for packet drivers
so Kermit and Novell software can be used concurrently, use software from
Brigham Young University, available via anonymous ftp from dcsprod.byu.edu.
For further information, read the Kermit Distribution file MSABYU.HLP.

An Ethernet-simulation packet driver "shim" is available for systems using the
NDIS (Network Driver Interface Specification) program.    NDIS is frequently
used with LAN Manager networks, including AT&T's StarGROUP network and DEC's
Pathworks for DOS.  The interface program is named DIS_PKT and originated with
FTP Software Inc.  Their program DIS_PKT.GUP is available by anonymous ftp to
vax.ftp.com, and a research version DIS_PKT9.ZIP is available from Utah State
University by anonymous ftp to netlab2.usu.edu.     Instructions for configuring
Lan Manager to include DIS_PKT are included with the program.  (Also available
from watsun.cc.columbia.edu, in the packet-drivers.new directory and on the
MS-DOS Kermit diskette.)

Here is a setup with which one user reports success in using MS-DOS Kermit's
built-in TCP/IP support with LAN Manager and a Novell NE2000 Ethernet board:

CONFIG.SYS
---------------------------
SHELL=C:\COMMAND.COM /P /E:1024
DEVICE=C:\WINDOWS\HIMEM.SYS
DEVICE=C:\WINDOWS\EMM386.EXE noems I=B000-B7FF i=e000-efff
DOS=HIGH,UMB
COUNTRY=61,,C:\DOS\COUNTRY.SYS
BUFFERS=13
FILES=50
STACKS=0,0
LASTDRIVE=Z
DEVICEHIGH=C:\DOS\ANSI.SYS
DEVICEHIGH=C:\WINDOWS\MOUSE.SYS
DEVICEHIGH=C:\LANMAN\DRIVERS\PROTMAN\PROTMAN.DOS /i:C:\LANMAN
DEVICEHIGH=C:\LANMAN\DRIVERS\ETHERNET\NE2000\NE2000.DOS
DEVICEHIGH=C:\KERMIT\DIS_PKT9.DOS

PROTOCOL.INI
----------------------------
[PROTMAN]
  DRIVERNAME = PROTMAN$
  DYNAMIC = YES
  PRIORITY = NETBEUI

[PKTDRV]
; This section added for kermit
  DRIVERNAME = PKTDRV$
  BINDINGS = NE2000_NIF
  INTVEC = 0x65

[NETBEUI_XIF]
  DRIVERNAME = NETBEUI$
  SESSIONS = 8
  NCBS = 12
  BINDINGS = "NE2000_NIF"
  LANABASE = 0

[NE2000_NIF]
; protocol.ini section for the Novell NE2000 Card
  IOBASE = 0x300
  INTERRUPT = 5
  DRIVERNAME = MS2000$

Kermit's TCP/IP support does not work over the Harvard ODIPKT driver on a
Token Ring network because it requires Kermit to use Token Ring rather than
Ethernet frames (but it does work with ODIPKT over Ethernet).  See below about
the experimental new ODITRPKT (ODI-to-Packet-Driver-over-Token-Ring) shim.
Version 3.12 and later support ODI directly; ODIPKT (or ODITRPKT) are not
necessary except when using MS-DOS Kermit under Windows to make network
connections over an ODI driver.  Kermit's built-in ODI support does not work
from within Windows.

  To use Kermit's built-in TCP/IP support over an ODI driver
  from within Windows, you must:

    1. Run ODIPKT (or ODITRPKT) over your ODI driver, and:
    2. Run WINPKT over ODIPKT (or ODITRPKT) or else Lock Kermit in Memory.

Note that ODIPKT should be told to use a higher interrupt number (specify
in decimal, not hex!) than WINPKT.  For example:

   ODIPKT 0 97                (97 decimal = 61 hex)
   WINPKT 0x60 0x61

Do not use the "-w" (Windows) switch with the underlying packet driver,
if any!

Direct use of ODI drivers permits Kermit's TCP/IP to run with several kinds of
Ethernet frames: DIX/Blue-Book/Ethernet_II, 802.2, 802.2 with SNAP, and 802.3,
as well as with Token Ring, Arcnet, and PCLan broadband.  No extra protocol
"shim" is needed, but you must have the ODI drivers which come from Novell or
from your network board vendor.

The ODI interface will be tried if a Packet Driver is not found, and it can be
selected in preference to a packet driver by the command:

   SET TCP/IP PACKET-DRIVER-INTERRUPT ODI

where "ODI" replaces the interrupt number of a Packet Driver.

For ODI, the file NET.CFG should have the lines "Protocol IP etc" similar to
the example below:

    # File NET.CFG, example
    PB buffers=10
    show dots=on

    Link Support
        buffers 6 1514
        MemPool 2048

    Link Driver SMCPLUS
        Port  280 20
        Mem   000CA000 2000/10
        Int   7
        frame Ethernet_II
        Protocol IPX    8137    Ethernet_II
        Protocol IP    0800    Ethernet_II
        Protocol ARP    0806    Ethernet_II
        Protocol RARP    8035    Ethernet_II

To make TCP/IP connections, Kermit requires three "protocols", IP, ARP, and
optionally RARP as shown above.     The frame kinds can be anything the board
will support: Ethernet, Token Ring, Arcnet, all IEEE 802.2-based frames etc.
ODI will complain if the frame type cannot support these protocols.  Arcnet
uses different TYPE values, D4 for IP, D5 for ARP, and D6 for RARP, rather
than 0800 etc, as per RFC-1201.

Which board Kermit (or IPX or other application) will use if two or more
boards are available?  Although one would think the board could be selected by
placing the Protocol IP, etc, lines under the desired Link Driver section,
such is not really the case; those lines tell LSL the frame kind to associate
with the protocol (say IP) but not the board.  The frame lines are associated
with particular boards, however.  The default method for finding a board is
that the application chooses "the first board" offering a suitable frame,
regardless of whether or not the Protocol IP, etc, lines are present for that
board.  "First" refers not to the contents of NET.CFG but to the order in
which board drivers are loaded at DOS level.  So the indented protocol lines
tell ODI which frame a protocol needs, and a TYPE to use for recognizing
packets, but the lines do not identify a particular board.

To target a particular board a separate main section is used in NET.CFG.  The
section starts with the word Protocol against the left margin and has Bind
indented beneath it, like this -

    Protocol Kermit            Identifies Kermit section of NET.CFG
        bind SMCPLUS        Bind to SMCPLUS board driver

When a board name is used more than once then the alternative form is to use
a board number in place of the name:

    Protocol Kermit
        bind #2            bind to the board loaded second

Kermit considers the text in these sections to be case-insensitive.  The
#<digit> construction must not have a separation between the number sign (#)
and the digit.    The #<digit> case is normally used when two or more boards
share the same driver and thus are not distinguishable by name alone.

A sample STARTNET.BAT file might look like this:

@echo off            run quietly
c:\lsl >nul            LSL is always loaded before boards
c:\smcplus.com >nul        SMC/WD8003E board, the first
c:\exos.com >nul        EXOS-205T board, the second
rem c:\odinsup            Odinsup can coexist with Kermit
rem c:\odipkt 0 96        Odipkt can coexist with Kermit
c:\ipxodi >nul            IPX is always loaded after boards
rem echo Starting network...    may be needed to help some drivers
c:\bnetx ps=my-preferred-server > nul
rem (Packet Burst mode)    NETX loads after IPX
@echo on

If both EXOS and SMCPLUS boards offer frame Ethernet_II Kermit will choose the
first loaded board, SMCPLUS, in the absence of a "bind" command.  Putting the
section "Protocol Kermit, bind <board name or number>" anywhere in NET.CFG
selects a particular board for Kermit.    A complete NET.CFG file using two
boards is shown below and applies to both regular NetWare shells and the
newer VLM shells (but with minor changes to the no-board parts of things).

# File NET.CFG, an example with two boards
PB buffers=10
show dots=on
# all main sections must start in column 1, indent local material.

# Protocol "IPX" is for Novell's IPXODI
Protocol IPX
    Bind #1

# Protocol "Kermit" is for MS-DOS Kermit
Protocol KERMIT
    Bind EXOS

Link Support
    buffers 6 1514
    MemPool 2048

Link Driver exos
    Port  310 20
    Mem   000D0000 400
    Int   5
    frame Ethernet_II
    Protocol IPX    8137    Ethernet_II
    Protocol IP    0800    Ethernet_II
    Protocol ARP    0806    Ethernet_II
    Protocol RARP    8035    Ethernet_II

Link Driver SMCPLUS
    Port  280 20
    Mem   000CA000 2000/10
    Int   7
    frame Ethernet_II
    frame Ethernet_Snap
    Protocol IPX    8137    Ethernet_II
    Protocol IP    0800    Ethernet_II
    Protocol ARP    0806    Ethernet_II
    Protocol RARP    8035    Ethernet_II

# Protocol "TCPIP" is for Novell's Lan WorkPlace for DOS, not Kermit
Protocol TCPIP
    ip_address    129.123.1.99
    ip_router    129.123.1.254
    ip_netmask    255.255.255.0
    tcp_sockets    8
    udp_sockets    8
    raw_sockets    1
    nb_sessions    4
    nb_commands    8
    nb_adapter    0
    nb_domain    usu.edu

Link Driver SLIP_PPP
    DIRECT    YES
    BAUD     9600
    OPEN    ACTIVE
    PCOMP    YES
    ACCOMP    YES
    PORT    3F8
    INT    4
    FRAME    SLIP
    Protocol    IP    0800    SLIP

MAKING NOVELL SLIP_PPP ODI CONNECTIONS

Novell's SLIP_PPP ODI driver is a combined serial port SLIP and PPP module
which is part of the Lan WorkPlace for DOS (LWP) product.  Kermit requires
the line:

    Protocol    IP    0800    SLIP

to be included with the driver.     Note that Kermit can temporarily steal the
serial port hardware from this driver to dial the telephone and log into a
host; SLIP/PPP communications should resume normally after Kermit is set to
the TCP/IP pathway.  Here is a STARTODI.BAT and NET.CFG example with SLIP_PPP
carrying the TCP/IP traffic.  File STARTODI.BAT:

@echo off
REM - Load LSL first
c:\lsl.com
REM - Then load your network board driver
c:\ne2000.com
REM - Then load the Novell SLIP_PPP driver
c:\slip_ppp.com
REM - Then the regular Novell IPX driver and network shell, for example:
set name=olga
c:\ipxodi /d
c:\bnetx.exe ps=name-of-novell-server
@echo on

File NET.CFG:

# File NET.CFG
PB buffers=6
show dots=on
signature level=0

protocol KERMIT
    bind SLIP_PPP
#    bind ne2000

Link Support
    Buffers    7 1500
    MemPool    2048

Link Driver NE2000
    Port  360
    Int   5
    Frame    Ethernet_II
    Protocol    IPX    8137    Ethernet_II
    Protocol    IP    0800    Ethernet_II
    Protocol    ARP    0806    Ethernet_II
    Protocol    RARP    8035    Ethernet_II

Link Driver SLIP_PPP
    DIRECT    YES
    BAUD     9600
    OPEN    ACTIVE
#    TCPIPCOMP    VJ
    PCOMP    YES
    ACCOMP    YES
    PORT    3F8
    INT    4
    FRAME    SLIP
#    FRAME    PPP
    Protocol    IP    0800    SLIP

# Below is for Novell's Lan WorkPlace for DOS
Protocol TCPIP
    PATH SCRIPT    d:\lwp41\net\SCRIPT
    PATH PROFILE    d:\lwp41\net\PROFILE
    PATH LWP_CFG    d:\lwp41\net\HSTACC
    PATH TCP_CFG    d:\lwp41\net\TCP
    ip_router    129.123.100.254
    ip_netmask    255.255.255.0
    ip_address    129.123.100.5
    tcp_sockets    16
    udp_sockets    8
    raw_sockets    1
#    nb_sessions    4
#    nb_commands    8
#    nb_adapter    0
#    nb_domain    usu.edu
    Bind        slip_ppp

Kermit is told to bind to SLIP_PPP rather than to the active NE2000 board
because the indented minor clause Bind SLIP_PPP under the Protocol Kermit
major heading tells Kermit which MLID (board driver) to use.  Link Driver
SLIP_PPP has indented Kermit line "Protocol IP 0800 SLIP" so Kermit can use
the driver; ARP and RARP lines could have been added with no effect (no ARP on
a point-to-point link).     LWP/DOS does not need this protocol line because it
tends to generate them itself.

Either SLIP or PPP can be used by setting the Frame Type and using the same
frame type in the indented protocol line below it.  No NetBios support was
wanted from LWP/DOS so that section was commented out.

STARTODI.BAT loads SLIP_PPP but nothing is sent out immediately as there is
not yet any connection.     To make the connection, start Kermit, SET PORT COM1
(or whatever), set the desired speed and flow control (but not Xon/Xoff!),
dial the phone and log into the host or server, then start SLIP or PPP there
(Novell provides a DIALER program with SLIP_PPP which can set the port speed
and dial a phone number via rudimentary means; Kermit is much more flexible
about this).  In all this, Kermit is grabbing the serial port from SLIP_PPP,
using it, and then returning it when done.  Kermit's TELNET will find an ODI
driver, SLIP_PPP, adjust itself accordingly, and SLIP-style packets flow back
and forth.  (If Kermit doesn't find the ODI driver, tell it to SET TCP
PACKET-DRIVER ODI.)

ODI-TO-PACKET-DRIVER SHIMS

Prior to version 3.12, the only way to make TCP/IP connections over ODI with
MS-DOS Kermit was through the ODIPKT shim, which converts between the ODI
interface and the packet-driver interface.  ODIPKT is no longer necessary,
except under Windows (because there is, as yet, no equivalent of WINPKT for
ODI drivers).

There is an ODI to Packet Driver shim available for Token Ring cards which can
work with Kermit (and WINPKT).    The current version is still in Beta as of
this writing (May 93).    ODITRPKT is available via FTP from Oklahoma State
University host datacomm.ucc.okstate.edu as pub/oditrpkt/beta9.zip.  A copy is
also available in packet-drivers/new on watsun.cc.columbia.edu, but it might
not be as up-to-date as the one at the source.

Here is a NET.CFG example using ODITRPKT:

LINK DRIVER TOKEN
     INT 3
     FRAME TOKEN-RING
     FRAME TOKEN-RING_SNAP
     PROTOCOL IPX  E0    TOKEN-RING
     Protocol IP   0800 TOKEN-RING_SNAP
     Protocol ARP  0806 TOKEN-RING_SNAP
     Protocol RARP 8035 TOKEN-RING_SNAP

And here is one using Arcnet:

LINK DRIVER SMCARCWS
     INT 3
     PORT 300
     MEM D0000
     Frame NOVELL_RX-NET
     Protocol IPX  FA NOVELL_RX-NET
     Protocol IP   D4 NOVELL_RX-NET
     Protocol ARP  D5 NOVELL_RX-NET
     Protocol RARP D6 NOVELL_RX-NET

At the moment there is no Windows support for Kermit over ODI.    Instead we
recommend using shim ODIPKT or ODITRPKT over ODI, followed by WINPKT over that
to employ a Packet Driver interface into Windows.

= TCP/IP BUGS AND LIMITATIONS

Linemode TELNET is not supported.  This is the mode in which the TELNET client
buffers up "lines" and then sends them all at once (with the TCP PUSH-bit set)
when the user hits the Enter key.  This has been observed to cause problems
with only one TELNET server so far: the UNISYS 2200 TIP transaction processing
system.

Versions 3.11 through 3.13 neglect to respond to DO SGA bids from the TELNET
server.  This has been observed to cause a problem in only one instance, namely
with the Apertus Technologies Telnet Gateway Service (SCHOLAR) front-end to
the NOTIS libary system.  This problem will be fixed in version 3.14.

Domain name resolution might not work when you give a nickname instead of a
complete host name in the SET PORT TCP/IP command and Kermit transforms the
nickname into the desired complete host name by combining it with your TCP/IP
DOMAIN.  Kermit does not use a special Hosts file to relate nicknames to
complete host names.  Workarounds: use a complete hostname, an IP host number,
or set your TCP/IP DOMAIN correctly.  It should be obvious that Domain Name
Servers are specified by their IP number rather than name.

Version 3.13 supports multiple gateways on the local network.  Choosing the
incorrect gateway normally results in that gateway sending an ICMP Redirect
message to Kermit indicating the preferred gateway, and Kermit displays such
messages.  Version 3.12 and earlier did not implement ICMP Redirect actions.

Kermit's TCP/IP gateway must be on your physical network.

Kermit is not an IP router handling routing traffic broadcast on the wire.  It
does not listen to RIP or similar.  Instead it depends upon router to do that
and then tell Kermit what to do.  Kermit computes whether an IP destination is
on the local network; if it isn't Kermit uses the first IP gateway as the
local target for ARPing and further relaying.  It is up to that gateway to
either accept the traffic or to issue an ICMP Redirect packet indicating
another gateway to use for this particular connection.

For IBM mainframe linemode TELNET connections, automatic appearance of the
login banner might not work.  Type a carriage return (Enter) to get the login
banner.     Local-echo and linemode operation are negotiated automatically.

BOOTP requests are handled correctly within the local network, and have been
tested successfully through Novell's BOOTP forwarder NLM and through Cisco
routers with software version 8.2.7.  In the SET TCP/IP ADDRESS command, the
words BOOTP and RARP must be spelled out in full.  Version 3.11 and 3.12
support original RFC951 and 1048 BOOTP protocol, and version 3.13 adds support
for downloading of the PC's full host (domain) name as specified in RFC1395.
See MSKERM.HLP (KERMIT.HLP) for details.

EXIT from Kermit closes your TCP/IP session (just like HANGUP).     PUSHing or
running DOS commands from Kermit keeps it open.     In version 3.12 and later,
EXITing while a session is active causes a warning / confirmation message to
appear so you can change your mind.

Version 3.11 of MS-DOS Kermit uses only the TELNET port (23) for SET PORT TCP
connections.  Version 3.12 and later allow you to specify any desired port
(except 25) in the SET PORT TCP command, after the host name or address.

MS-DOS Kermit honors TELNET protocol negotiations, including terminal type and
ECHO/SGA.  Version 3.11 always sends "VT100" as its terminal type; later
versions send MS-DOS Kermit's active terminal type or allows the user to
create an override string with command SET TCP/IP TELNET-TERM-TYPE.

Not supported: FTP, TFTP, automatic setting of PC date/time from network, 3270
emulation (tn3270), etc.  There is no PING command, but MS-DOS Kermit responds
when PINGed and when probed by Traceoute.  The keyboard verb \Knethold does
nothing.  Multiple simultaneous TCP/IP sessions are supported in version 3.13;
see MSKERM.HLP (KERMIT.HLP) for details.

For TCP/IP connections to IBM mainframes in full screen 3270 mode, you need an
intermediate host or device to do the 3270/ASCII terminal conversion.  Typical
setup is a TCP/IP terminal server with its serial lines connected to a protocol
converter (e.g. IBM 7171), a UNIX host that has tn3270 available, or a terminal
server (like Cisco) that does 3270 terminal emulation.    To transfer files with
an IBM mainframe, you might have to tell MS-DOS Kermit to SET PARITY SPACE.

Version 3.12 and later support inbound connections to MS-DOS Kermit.  Inbound
TELNET connections do not copy DOS screens, etc, like Carbon Copy and PC
Anywhere and the free telnetd program of Erick Engelke; a Kermit-to-Kermit
connection is made instead.  To configure MS-DOS Kermit to be a TCP/IP server,
give the following command:

  SET PORT TCP * [ <port> ]
  SET SERVER LOGIN <username> [ <password> ]  ; (recommended but not required)
  SERVER

Use asterisk instead of an IP name or address, followed optionally by a TCP
port number (the default is 23 = TELNET), and then enter server mode.  Anybody
who TELNETs to your PC will see a brief screen message telling them to escape
back to their local Kermit prompt and issue commands from there, for example:

  REMOTE LOGIN <usename> <password>
  REMOTE DIRECTORY
  GET OOFA.TXT

Kermit's TCP/IP support cannot be used simultaneously with PC NFS because both
applications want to register use of ARP and IP with the packet driver, but
each protocol can only be assigned to one application.  This is only one
particular case of the more general rule:

    Only one TCP/IP based application can use a LAN adapter at once.

which also applies to DesqView/X and other TCP/IP products for the PC.

(There is a program called PKTMUX that, under some conditions, might allow
coexistence of multiple TCP/IP applications, but it is risky and not
recommended.)  To make MS-DOS Kermit work simultaneously with PC-NFS, Kermit
would have to be linked with the proprietary socket-library routines, which we
cannot do.  If you need to have NFS active simultaneously with an MS-DOS
Kermit TCP/IP connection, follow the hints given above, or use a different NFS
package that also works with Kermit such as FTP Software, Novell LWP, or Beame
and Whiteside.

The SET TCP/IP and SET PORT TCP/IP commands only return failure codes if there
is a parse error.  The connection is not opened until the first attempt to
communicate with the remote host: CONNECT, PAUSE, OUTPUT, etc.    While
connection establishment is in progress, you can't interrupt the program with
Ctrl-C.     Use IF SUCCESS / FAILURE after PAUSE 0 to check if the connection
is open, for example:

  DEFINE TELNET SET PORT TCP \%1 \%2, PAUSE 0, IF SUCCESS CONNECT

The second variable above is for the optional TCP port number in version 3.12
and later.

TCP/IP performance hints: Set your Kermit packet size to 500 or larger to
achieve most data sent per network packet. A convenient setting is SET
RECEIVE PACKET 1000, SET WINDOW 4, resulting in four 1000-byte packets in a
window.     SET FLOW NONE lets TCP/IP do the flow control and eliminates Kermit's
need to check for Xon/Xoff.  In most situations beyond the local network
performance will be limited by the long distance lines rather than by the PC.

End of MSKERM.BWR / KERMIT.BWR