Columbia Kermit/kermit.zip/e/v17.1

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

From cmg  Thu Jan 14 11:57:46 1993
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB/jba)
    id AA26555; Thu, 14 Jan 93 11:57:46 EST
Date: Thu, 14 Jan 93 11:57:43 EST
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V17 #1
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Thu, 14 Jan 1993        Volume 17 : Number 1

Today's Topics:
    StarGROUP Patch for MS-DOS Kermit 3.12
    MS-DOS Kermit, COM3, COM4, and Internal Modems

Digest submissions may be sent to [e-mail] or
[e-mail].  Requests for addition to or deletion from the
Info-Kermit subscriber list should be sent to [e-mail] or
[e-mail].  These messages must be of the form:

  SUBSCRIBE I$KERMIT <your-personal-name>    (To start a subscription)
  UNSUBSCRIBE I$KERMIT                       (To cancel a subscription)
  REGISTER I$KERMIT <your-personal-name>     (To correct your name)

Kermit files may be obtained over networks and by mail order.  On the
Internetwork, use FTP to log in to host WATSUN.CC.COLUMBIA.EDU, a SUN-4/280
running UNIX (SUNOS 4.1), IP host number 128.59.39.2.  Login as user anonymous
(note, lower case), any password, and GET or MGET (MULTIPLE GET) the desired
files.  The file kermit/read.me is a general guide to where things are.  The
Kermit files are in directories kermit/a, kermit/b, kermit/c, kermit/d, and
kermit/e.  Test versions are in kermit/test.  All files in these directories
should be transferred in text (ASCII) mode.  Binaries are in kermit/bin (use
ftp in binary mode).  All files on watsun have lowercase names, and case is
significant.

You can also get Kermit files over the BITNET/EARN network; to get started
send a message with text HELP to KERMSRV, the Kermit file server, at host
CUVMA.  For detailed instructions, read the file kermit/a/aanetw.hlp
(AANETW.HLP on KERMSRV).  To order by mail, request a complete list of Kermit
versions and an order form from Kermit Distribution, Columbia University
Center for Computing Activities, 612 West 115th Street, New York, NY 10025
USA.

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

Date: Tue, 12 Jan 93 11:30:00 EST
>From: Christine M. Gianone <[e-mail]>
Subject: StarGROUP Patch for MS-DOS Kermit 3.12
Keywords: StarGROUP, MS-DOS Kermit 3.12, Patches for MS-DOS Kermit

>From Joe Doupnik, author of MS-DOS Kermit: Patches 11 and 12 to cure a bug
that caused AT&T StarGROUP network connections to be lost after shelling to
DOS (RUN, PUSH, etc).  The updated patch file is in kermit/a/mskermit.pch on
watsun, MSKERMIT PCH on KERMSRV.  Copy it to the same directory where you
keep your MSKERMIT.INI file, and make sure there is a PATCH command at the
top of your MSKERMIT.INI file.

Remember, MS-DOS Kermit patch files only work with the binary KERMIT.EXE
(MSVIBM.EXE) distributed by Columbia University; they will not work with
versions that you have built yourself from source code, or that have been
modified in any manner.

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

Date: Tue, 12 Jan 93 11:40:00 EST
>From: Frank da Cruz <[e-mail]>
Subject: MS-DOS Kermit, COM3, COM4, and Internal Modems
Keywords: MS-DOS Kermit and COM3 and COM4
Keywords: MS-DOS Kermit and Internal Modems
Keywords: Modems and MS-DOS Kermit, COM3/COM4 and MS-DOS Kermit

With the arrival of the new breed of low-cost high-speed internal modems have
come ever-increasing numbers of queries about how to use them with MS-DOS
Kermit, especially on COM3 or COM4.  With the help of Joe Doupnik (author of
MS-DOS Kermit) and John Klensin at MIT, we have put together what I hope will
be a useful guide to this complicated topic.  This text has also been added
to the MSKERM.BWR file.


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?"


First, 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 would be, for example:

  SET PORT COM2       ; First select the port you want to use.
  SET SPEED 19200     ; Then set the desired speed on the selected port,
  SET PARITY EVEN     ; and other parameters for this port, such as parity,
  SET FLOW RTS/CTS    ; flow control,
  SET LOCAL-ECHO OFF  ; and CONNECT-mode echoing.

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) switches
all of these parameters to their previous (or default) values for the port you
have switched to.

To see the current port-related parameters, type the MS-DOS Kermit command:

  SHOW COMMUNICATIONS

This displays all the relevant information about your currently selected
communication device, which is COM1 by default.  Check the settings carefully
to be sure they are what you intended.


  * * * *
  The following discussion, which applies to MS-DOS Kermit versions 3.11 and
  3.12, is detailed and technical, but most of it boils down to (a) installing
  a patch; (b) telling Kermit two numbers, the port address and IRQ value; and
  (c) 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, but
with provisions for at least two more, COM3 and COM4.  The basic problem with
COM3 and COM4 is that they 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 are not presently supported by MS-DOS Kermit.

The digit in the port name is an index into an area in memory that contains
the address of the serial port hardware.  The BIOS (the PC's Basic Input/Ouput
System) has four words reserved starting at segment 40 (hexadecimal), word 0,
to hold the addresses of the first four COM ports.  Word 0 defines COM1, word
2 (two bytes per word) defines 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
of this operation 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........`.
  0040:0010  65 46 00 80 02 00 00 20-00 00 38 00 38 00 3E 34  eF..... ..8.8.>4
  0040:0020  20 39 78 2D 2E 34 78 2D-0D 1C 64 20 20 39 34 05   9x-.4x-..d  94.
  0040:0030  30 0B 3A 27 30 0B 0D 1C-75 16 67 22 20 39 00 00  0.:'0...u.g" 9..
  0040:0040  0A 00 C3 00 00 00 00 00-00 03 50 00 00 10 00 00  ..........P.....
  0040:0050  00 18 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
  0040:0060  0E 0D 00 D4 03 29 22 76-07 35 18 FF F9 C8 0F 00  .....)"v.5......
  0040:0070  00 00 34 12 00 01 00 00-14 14 14 20 01 01 01 01  ..4........ ....

The first line contains the COM port information (ignore the other lines, as
well as the funny characters on the right).  "F8 03" is the 2-byte COM1
address, expressed in hexadecimal (base 16) with the low byte shown first.
Thus the actual COM1 address is 03F8 hex, which is expressed in Kermit
commands as \x03f8.  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 (and hence many communication programs, including Kermit) 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 and become 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 (there are exceptions) 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 define the board to be a particular COM port.

Why, then, do some communication programs work with COM3 and COM4 without any
special fiddling?  The answer is that these programs ASSUME that COM3 and COM4
are found at certain addresses, even when there are no entries in segment 40,
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, but these addresses are installed by the BIOS into segment 40
  when the PS/2 is started, so well-behaved communication software (like
  Kermit) will use these addresses rather than the defaults listed above.
  Ill-behaved software will ignore the segment-40 addresses and erroneously
  attempt to use its own values, which, with luck, might be correct but, more
  likely, will not work, or at worst, can disrupt normal operation of your PC.

Unchecked use of an assumed port address is DANGEROUS if the device is not
really where the software expects, but the software goes ahead and uses the
address anyway, in particular if some other type 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 zero when they want to use the port exclusively and without
interference, and then restore the real address when they are 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 will 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
  (addresses related to the port's base address) 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 chance disrupting normal operation of (or damaging)
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 an IBM-PC
compatible 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 appropriate word in segment 40
so other programs can find the port (assuming 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.  The SET COMn command must come first, then the SET PORT COMn command,
as in this example for COM3:

  set com3 \x3f8   ; Specify the address of COM3
  set port com3    ; Select COM3

How do you know what addresses to give?  Suppose you have purchased an
internal modem or an add-on serial port and you want to install it as a
particular COM port, say COM3.  The installation instructions for your device
will tell you how to do this.  The device must be configured -- generally by
setting little switches or installing or removing jumpers.  The manual should
tell you the address for each COM port.  You have to make sure that the
address that you have configured for the device 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
  COM4       02E8, 3228, 02E0

It is relatively unlikely that you will 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.  Why would
this happen?  There are several possible explanations, including:

 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 and by default 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 cross-connecting them to DTR).

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;

If you want the addresses to be set correctly in the BIOS communications area,
so all applications (not just Kermit), can find the ports, put a line like
this in your AUTOEXEC.BAT (substituting the appropriate ports and addresses):

  kermit -f nul, set com3 \x3e8, set com4 \x2e8


INTERRUPTS

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

This common 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 interfering with 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 may be "caught" by application software such as
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 of the other
communications programs).  Communications programs that use polling are not
sensitive to interrupts being set properly and may therefore work with
improperly-configured machines where Kermit will not (unless 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 integer 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 for serial port input and output.  Thus 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
Microsoft 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.  On most types of PCs, however, IRQs can NOT be shared, and
therefore 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 address of a COM port, it tests to see which IRQ number,
3 or 4, the device uses.  This is a safe test and does not 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.  This results in the
common limitation that no more than two serial ports can be active at once.

MS-DOS Kermit 3.12 and earlier test 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 is 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 sometimes 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.

  9  Alias for IRQ 2.

 10  Usually free.

 11  Usually free.

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

 13  QEMM traps math coprocessor errors 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 force Kermit to
both talk AND listen to the device, you must 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 will skip its IRQ test and use the IRQ number
you have specified when you next give a SET PORT command for that port.

  PLEASE NOTE that you MUST 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,
     and therefore must be skipped.

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

If, even after establishing the device's interrupt correctly, 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 driver) is catching the same
     interrupt.

If you find a conflict, take whatever means are at your disposal to remove 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 reconfigure one of the conflicting devices to use a
different interrupt.


PROBLEMS WITH MODEMS

  "I just bought and installed an XYZ V-Dot-Everything internal modem, and
  it works with <name-deleted> and <name-deleted> communication packages,
  but it doesn't work with Kermit".

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

 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 recent months (beginning about 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 (and usually more expensive) modems.  The problems are generally
related to initialization of the modem and interaction with its command
processor.  Some common complaints:

 1. An internal modem does not work at all; the modem becomes nonoperational
    as soon as Kermit attempts to access it.  The cause has been traced to the
    fact that Kermit's initialization of the modem's UART is "too fast" for
    some of these new modems.  (This same initialization sequence has been
    used for nearly a decade with no problems, and still works on the
    well-known and reputable brands of internal modems.)

 2. "Kermit won't dial or respond to modem commands".  The modem ignores
    dialing or other commands from Kermit.  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.

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

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

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

 1. Slow the UART-initialization sequence.  This is accomplished by patch #11
    to MS-DOS Kermit 3.11 and patch #10 to version 3.12.  These patches have
    been tested successfully on several of the misbehaving modems.  Get the
    patch file for your version of Kermit (3.11 or 3.12).  The patch files are
    in kermit/a/msr311.pch and kermit/a/msr312.pch on watsun.cc.columbia.edu
    on the Internet, available via anonymous FTP.  Rename the file to
    MSKERMIT.PCH and put in the same directory as your MSKERMIT.INI file, and
    start Kermit again.  At the MS-Kermit> prompt, give a VERSION command to
    make sure the patches were installed.  If not, give a PATCH command (or,
    better still, make sure that PATCH is the first command in your
    MSKERMIT.INI file, and that your MSKERMIT.INI file is in your DOS PATH so
    Kermit will always execute it).

 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 it is set to use hardware flow control, but Kermit is not.
    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 (for
    example) 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 when talking to the modem, and then set parity to
    whatever the remote host or service requires after making the connection.
    (WARNING: MS-DOS Kermit might set its parity to some other value
    automatically as a result of automatic parity detection during file
    transfer.)

 6. Ensure that 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, which is a standard for add-on
    devices, and might be required by your communication board or internal
    modem.

 7. Modify HAYES.SCR, or whatever dialing script you are using, to take
    extraordinary measures to ensure the modem is in command mode, and to send
    its initialization commands very slowly and to try them repeatedly.  For
    example, change "output ATQ0V1X1\13" to something like this (note: the
    modem-related commands shown here are all relatively portable -- you might
    also need additional modem-specific commands, such as AT&F2 to load a
    particular configuration, or specific S-register settings affecting speed,
    flow control, modulation, fallback, etc.):

      WAIT 1 DSR         ; See if modem is asserting Data Set Ready
      IF FAIL FATAL -
       {No DSR signal: Is your modem connected and turned on\63}
      SET PARITY NONE    ; Use no parity
      SET COUNT 5        ; Try 5 times to initialize
      :INIT
      HANGUP             ; Modem is connected - hang up on it.
      CLEAR              ; Clear Kermit's input buffer.
      OUTPUT \B          ; Send a BREAK.
      PAUSE              ; Wait a second.
      OUTPUT \17         ; Send a Ctrl-Q in case modem is Xoff'd.
      PAUSE 2            ; Wait two seconds.
      OUTPUT +           ; Send the most likely escape sequence,
      OUTPUT +           ; which is "+++" with at least a second of
      OUTPUT +           ; "silence" before and after.
      PAUSE 2            ;  ...
      OUTPUT \13         ; Send a carriage return.
      PAUSE              ; Wait a second.
      OUTPUT A           ; Send an A.
      PAUSE              ; Wait another second.
      OUTPUT T           ; Send a T.
      PAUSE              ; Wait another second.
      OUTPUT \13         ; Send a carriage return.
      PAUSE              ; Wait a second.
      CLEAR              ; Clear away echo and response.
      OUTPUT A           ; Send initialization command.
      OUTPUT T           ; One character at a time...
      PAUSE
      OUTPUT Q           ; Q0 = Result codes enabled
      OUTPUT 0
      OUTPUT V           ; V1 = Word result codes
      OUTPUT 1
      OUTPUT X           ; X1 = Dial response level
      OUTPUT 1
      OUTPUT \13         ; Carriage return terminates the command
      PAUSE
      INPUT 3 OK         ; Wait for OK response.
      IF SUCCESS GOTO INITOK  ; Got one.
      IF COUNT GOTO INIT      ; Didn't, try again.
      ECHO Failure to initialize modem.  ; No more tries.
      STOP 1                             ; Fail.
      :INITOK

    If this doesn't work, insert a PAUSE command after each OUTPUT command
    or run the script at a lower speed.

 8. Dial at a lower speed.  Make your interface speed match the modulation
    speed -- e.g. use 9600 for V.32, 2400 for V.22bis, etc.  Turn off fancy
    modem options like error correction and compression.  etc etc.  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 undoubtedly a
    problem between the two modems (involving one modem, 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.

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

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

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