Columbia Kermit/kermit.zip/e/v14.9

Text File | 2020-01-01 | 29KB | 544 lines

24-Oct-91 16:13:57-GMT,28687;000000000001
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA17894; Thu, 24 Oct 91 12:13:53 EDT
Date: Thu, 24 Oct 91 12:13:52 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V14 #9
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Thu, 24 Oct 1991        Volume 14 : Number 9

Today's Topics:

         Announcing Kermit for Microsoft Windows 3.0
        Announcing a New Release of HP-3000/MPE Kermit
              Recent Kermit Protocol Extensions
                 Kermit News Articles
               MS-DOS Kermit and DR DOS
          Release of Additional Kermit-12 Utilities
           Re: New Serial Printer Driver for MS-DOS Kermit
        Flow Control for IBM Mainframe Half Duplex Connections
             MS-DOS Kermit Speed Under MS-Windows
              Kermit Packet Length Fluctuations

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 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).  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, 22 Oct 91 12:00:00 EDT
From: Christine M. Gianone <[e-mail]>
Subject: Announcing Kermit for Microsoft Windows 3.0
Keywords: Windows 3.0, Kermit for Windows

Written by Bill Hall, Santa Clara, CA, specifically for Microsoft Windows
3.0, announced for testing in Info-Kermit V13 #5, June 1991.  Since no
complaints have been received, this version has been moved into the "A"
area, replacing the previous version of Bill's Windows Kermit program, which
works only under Windows 2.0.

This is not MS-DOS Kermit, but a completely different program.  It uses the
point-and-click Windows user interface, and it runs in a window in Real,
Standard, and Enhanced modes of Windows 3.0 on any model PC or PS/2 that
supports Windows 3.0, and emulates the VT52, H19, and VT100 terminals.  The
program is the subject of an article written by Bill in the January 1991
issue of Microsoft Journal: "Adapting Extended Processes to the Cooperative
Multitasking of Microsoft Windows".

The new version of Windows Kermit lacks many of the advanced features of
MS-DOS Kermit: VT220/320 emulation, key mapping and macros, international
character sets, Tektronix graphics, long packets, sliding windows, script
programming, network support, etc, but some of these items are on Bill's
list for future releases.

The files are in kermit/a/wk*.* on watsun.cc.columbia.edu (Internet) and are
available as WK* * from KERMSRV at CUVMA on BITNET / EARN.  First get the
file wkaaaa.doc (WKAAAA HLP), read it, and then decide which other files you
need to get.  The old version of this program, which is still required for
Windows 2.0, has been moved to kermit/c/win*.* on watsun (WIN* * on CUVMA).

Thanks once again to Bill for this excellent contribution!

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

Date: Tue, 22 Oct 91 12:01:30 EDT
From: Christine M. Gianone <[e-mail]>
Subject: Announcing a New Release of HP-3000/MPE Kermit

FROM: Tony Appelget
      General Mills, Inc
      PO Box 1113
      Minneapolis, MN 55440-1113

Apparently my contribution of HP3000 Kermit has hit the streets.  I am
getting complaints, mostly because sites do not have current SPL compilers.

Since I first sent you my updated version of HP3000 Kermit, we have obtained
HP Spectrum machines.  Although Kermit did not fall flat on its face,
problems arose and I fixed them.  It is time for me to send you an update.
Enclosed on this disk are the following:

    This letter.
    My HP3000 Kermit source.
    My HP3000 Kermit object.

The object file is straight classic HP3000 code, ready to run.  It has not
been BOOed or otherwise been made eye-readable.  I assume that you have the
facilities to readily do that conversion if you choose.  I have run the
classic HP3000 code through HP's OCTCOMP processor and the resulting code
file seems to be well-behaved on a Spectrum machine.

(Signed)
Tony Appelget

[Ed. - Many thanks, Tony!  The new files are on watsun.cc.columbia.edu in
kermit/d/hp3*.* for Internet access, and available as HP3*.* from KERMSRV at
CUVMA on BITNET/EARN/CREN.  The .OBJ file has been converted to hex format,
which should be easily deodable: each 2 bytes are the hexadecimal encoding
of an 8-bit byte.  Ignore line ends.  A binary copy of the object file is in
kermit/bin/hp3kerm.obj (watsun, Internet only).]

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

Date: Tue, 22 Oct 91 12:02:00 EDT
From: Frank da Cruz <[e-mail]>
Subject: Recent Kermit Protocol Extensions
Keywords: Kermit Prototol, Character Sets, International Character Sets
Keywords: Compression

For the past several years, Kermit programs have been appearing that
translate character sets during transfer of text files.  This is necessary
because of the many different incompatible encodings used for national and
international (non-ASCII) characters on different kinds of computers.

The protocol extension that specifies exactly how this is done has been
undergoing continuous revision and refinement.  The current description can
be found in the file kermit/e/isok6.txt (ISOK6 TXT on BITNET KERMSRV).  Some
background can be found in an excellent paper by Andre' Pirard of the
Universite de Liege in Belgium, kermit/e/pirard.txt (PIRARD TXT on KERMSRV).

To increase the efficiency of 8-bit text file transfers through 7-bit
connections, a locking-shift option has been added to the Kermit protocol.
This is documented in the file kermit/e/lshift.txt (LSHIFT TXT on BITNET
KERMSRV).

The next major effort in Kermit protocol expansion (no commitment expressed
or implied!) is the addition of an effective and portable compression
method.  We're in the information-gathering phase now.  The method that is
finally chosen must be single-pass, in the clear legally (unlike LZW, which
is tied up in patent infringement litigation, or MNP-level-whatever, which
is licensed commercially), well-behaved and effective for all types of data
(7-bit text or 8-bit text in any language, binary executables, numeric data,
raster images, etc), relatively easy to program, and not horrendously
consumptive of CPU cycles or memory.  For maximum transportability, the
result of compression should be a sequence of 7-bit ASCII printable
characters (32-126 or a subset of these).  Suggestions, pointers to
specifications for various methods and analyses of them, etc, would be most
appreciated.

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

Date: Tue, 22 Oct 91 12:01:00 EDT
From: Christine M. Gianone <[e-mail]>
Subject: Kermit News Articles

Come on, send in those articles!  We're not going to publish the next issue
of Kermit News until we have some good ones.  I'm looking for interesting
stories about Kermit -- how it is being used in different countries,
industries, and different sectors of the economy; what role has it played in
recent historic events; why was it chosen over other alternatives, what
features are especially attractive or useful, etc, as well as amusing
anecdotes, technical contributions, reviews of recent Kermit releases, etc.
Kermit News is a real journal, ISSN number and all.  Get published!

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

Date: Sat, 12 Oct 91 3:59:16 EDT
From: Charles Lasner <[e-mail]>
Subject: MS-DOS Kermit and DR DOS
Keywords: DR DOS, MS-DOS Kermit and DR DOS

There is a cosmetic problem with DR DOS 5 (early and late) and DR DOS 6
whereby the OS doesn't do an automatic CR/LF when the application
terminates so therefore the KERMIT prompt gets overlayed with the DOS
prompt.  Otherwise all works very well.

DR DOS 6 can deliver even more memory than DR DOS 5 and certainly much
more than MS-DOS 5 or any version depending on your hardware.  Without
resorting to an admitted "trick" of memory management, DR-DOS can
deliver 627K out of 640K to the user program (on 386 systems using
EMM386.SYS) and 628K on C&T NEAT-chipset 286 systems.  This seemingly
high number is because pieces of DOS reside in either upper memory or
high memory or both.  MS-DOS KERMIT runs fine in all of these
configurations.

The real trick is when you enable the so-called memmax +v option,
whereby the video buffer is mapped into the physical space where some
of the upper memory lives, thus allowing the remapping of live memory
space at A000 and up.  The net result is that the machine grows to a
whopping 724K (yes, that's 1024=1K units!), but all of the video's
graphics modes are disabled.  "well-behaved" software believes that
your video hardware is now a CGA only, complete with the minimal CGA
graphics modes, but all of the extended modes go away.  My machine is a
20 MHz "King of Neat" system with an Ahead Systems 1 Meg VGA.  All of
the extended modes (1024x768x16 or 256, 800x600x16 or 267, 640x480x256)
and all of the normal VGA and EGA modes just disappear.  Yet, the VGA
ROM is still present (and also RAM shadowed for speed).  Applications
seeking these modes find only the CGA stuff.

Needless to say, many applications are incompatible with this much
memory, but fortunately MS-DOS KERMIT isn't one of them.  It's real cute to
run KERMIT, then do a PUSH to DOS to find out that you still have over
600K beneath you!

[From jrd - Interesting.  Both MS and DR DOS are making some progress.  The
current version of QEMM/386 takes this further by reusing the area occuppied
by some ROMS (video, system, some others) with no, zero, loss of
functionality.  It's called Stealth mapping.  I advise all memory mappers
(people) to never put anything in video display areas because that belongs to
the video system and may/will be used by programs.  Simpleminded ideas about
video modes determining a video display adapter are for the birds so my advice
is still sound.]

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

Date: Thu Oct 10 1991 12:00:00 EDT
From: Charles Lasner <[e-mail]>
Subject: Release of Additional Kermit-12 Utilities
Keywords: .BOO, PDP-8, PDP-12, VT-78, DECmate, OS/8
Xref: DEC PDP, See PDP

    This is a release of companion utilities to KERMIT-12 for the purpose
of enhancing file distribution.  Two areas are addressed:  1) Initial
program acquisition,  2) Binary file encoding.

1)  Utilities are provided to create and load copies of KERMIT-12 "on the
fly" from a server such as a remote time-sharing system or a local PC on
the other end of a "clean" connection to the PDP-8.

    Unfortunately, most PDP-8 family systems lack a communications
predecessor to KERMIT-12.  Most communications applications were limited to
terminal emulation only, so it is rare that any PDP-8 system has an
existing utility sufficient to acquire KERMIT-12.  (Of course some sites
have prior versions of KERMIT-12 already.)

    Assuming an error-free serial connection to the other system, it is
possible to down-load KERMIT-12 directly into the PDP-8 memory without a
protocol.  This is similar to the process used for years by DEC field
service to load paper-tape copies of diagnostics.  Loading is limited to a
single PDP-8 field at a time.  Performing several load operations yields
intermediary image files which can be combined into K12MIT.SV identical to
the release version (except for irrelevant loading artifacts which is a
consequence of the operating system itself).

    The format chosen for Initial Program Load (.IPL) is an encoding that
yields ASCII files that should pass through any system with ease.  The
scenario of loading is assumed to be either direct system-to-system, or
between a remote system and one of its terminals.  All control characters
(such as CR and LF) are ignored, thus the encoded files contain frequent
line breaks to make the encoded file pallatable to the serving system.
Strictly lower-case letter messages are added at the beginning and end of
the file to serve as leader trailer fields as well as file documentation.
Please note that while spaces are insignificent, the rest of the ASCII
character set is used for loading information, so editing of .IPL files
must scrupulously avoid changes to the "body" of the file.

    A simple program (K12IPL.PAL) is provided for .IPL loading of a single
field.  The user must customize it for local requirements, and then enter
two variant forms of the loader. (Future releases could require additional
variants to be created.  The current release occupies two fields.)  This
process is similar to customizing the communications requirements of
KERMIT-12 itself.  The program is sufficiently small to allow manual entry
into the system debugger (ODT) directly.  Examples of such an entry session
are provided as K12IP0.ODT and K12IP1.ODT.  The source program may also be
retyped by any available means (TECO, EDIT, etc.) if desired.  Only
standard PDP-8 peripherals are supported such as KL8E, KL8-JA, etc., as
opposed to KERMIT-12 itself which supports various DECmate communications
hardware as well.  It was felt that the greatly increased complexity of
supporting the DECmate communications ports would make this process too
unwieldy.  However, it is possible to load the data through the DECmate's
printer port.  The VT-78 and all prior PDP-8 models are fully supported.

    Distribution files include K12FL0.IPL and K12FL1.IPL which are the
encoded copies of field zero and field one respectively.  K12IPL.DOC is a
discussion of the .IPL encoding format itself.  K12IPG.PAL is the utility
used to create K12FL0.IPL and K12FL1.IPL from the standard release file
K12MIT.SV. (K12MIT.SV is itself distributed in encoded form as K12MIT.ENC
and now also K12MIT.BOO (see below).  K12IPG can be used with other
programs for similar purposes if required.)

2)  Utilities are provided for encoding and decoding arbitrary OS/8 files
using the popular .BOO format encoding scheme.  .BOO format should be
compatible across dis-similar systems thus avoiding intermediary "hazards."

    While quite popular in the MS-DOS world for file distribution purposes,
.BOO format as originally designed has an inherent weakness that makes
reliable use on OS/8 family systems impossible.  I have designed an
extension to the format to make .BOO format sufficiently reliable to allow
implementation of an encoder and decoder for OS/8 systems.  Note that
ENCODE format is still the format of choice for file distribution because
of its more robust nature, but the shorter files created by a .BOO encoder
may be desirable in certain circumstances.  .BOO format files cannot pass
through WPFLOP "paths" to distribute files on DECmates or VT-78, so ENCODE
format is mandatory on systems used this way.

    The relevant problem with .BOO format has to do with file length
anomalies that are a consequence of the format itself.  .BOO files either
end on a repeat compression field or a complete three-byte data field
expressed as four characters, each only six bits significant.  Should a
file end with only one or two eight-bit data bytes, two or one additional
null bytes will be appended to pad out the last data field.  This leads to
files that are one or two bytes longer than intended.  At least this is the
behavior on systems like MS-DOS which maintain a file byte count.  Since
OS/8 files are multiples of whole records, each of which can be viewed as a
collection of 384 bytes, any change in a file's length of even a single
extra null byte will cause the creation of an extraneous whole record.
Besides wasting space, it is conceivable that an OS/8 file corrupted in
this manner could actually be dangerous to use!  Note also that this
problem can be cumulative in that repeated transmission between systems
where the file is stored locally in some decoded form, and then encoded
locally before transmission to another site, can cause the problem to
worsen indefinitely.  Clearly, .BOO format must be firmed up to prevent
this form of file corruption before it can be used safely on PDP-8 systems.
(It has also been noted that widely distributed .BOO encoding programs
exist on certain systems which exhibit defects such as erroneous appendage
of additional null bytes onto the end of the file not indicated by the
file's contents.  This is clearly a program bug and not an inherent problem
with .BOO format design.)

    The method chosen to correct the existing .BOO anomaly is to append a
correction field to the end of every file requiring it.  The basic
correction unit is ~0 which means literally a repeat compression field with
a count of zero.  This construct is ignored by most .BOO decoders because
it contributes nothing to the file. (At the bare minimum, .BOO decoders
should implement the robustness of ignoring this type of data.  It is
conceivable that due to design error, a decoding program could "blow up"
when encountering this data.  Imagine a file lengthened by 2^32 null bytes!
The exact amount of extraneously generated null bytes would likely be
2^{how many bits wide are integers on the machine} or one less than that.)

    .BOO-encoded files may now contain either ~0 or ~0~0 at the end to
indicate whether one or two bytes are to be "taken back" respectively.
Tests on MSBPCT.BAS and MSBPCT.C as currently distributed by CUCCA indicate
that these corrections are perfectly ignored, thus decoded files are
erroneously inflated by one or two bytes.  This is the expected behavior of
these older decoders.  When used with PDP-8 DEBOO.SV (distributed in source
form as K12DEB.PAL), the correct file length is maintained.  PDP-8 ENBOO.SV
(distributed in source form as K12ENB.PAL) is the first encoding program
that creates the correction field as necessary.  It is hoped that this
"pioneering" effort will cause other systems' encoders and decoders to be
similarly updated.

    Overall program operation for the encoder and decoder is identical to
the equivalent programs for ENCODE format.  Documentation is contained in
the source files.  As in the ENCODE format decoding program, the target
file name can be taken from the original file name imbedded within the
file, or optionally the user can specify a target file name as well as a
target device.  When encoding, the imbedded file name will always be the
original name of the file supplied as input to the encoder.  The user can
specify any valid combination of output file name and device for the
resultant encoded file.

    OS/8 files passed through ENBOO/DEBOO are packed/unpacked according to
the standard OS/8 "3 for 2" scheme to ensure byte accuracy where relevant.
This allows files which are ASCII, but too "delicate" for ordinary transfer
to be sent between unlike systems with total accuracy.  This includes any
file where the precise placement of CR and LF may be critical, or contains
unusual characters in the file such as BEL or ESC.  A perfect example of
this is the interchange of TECO macros between PDP-8s (used with OS/8
TECO.SV) and IBM-PCs (used with MS-DOS TECO.EXE) with a unix system as an
intermediary storage site.  Both end systems use like line termination
schemes incompatible with the intermediary system.  Since both systems
support .BOO format, the files can still be sent without loss.

    Most of the existing K12MIT-related files are unchanged.  K12MIT.DSK is
updated to reflect all new files pertaining to .IPL or .BOO utilities.
K12MIT.ANN and K12MIT.UPD are updated per this announcement.  All files
distributed in ENCODE format are replicated in .BOO format.

    The new files have been installed in the regular places:

BITNET/EARN       Internet
KERMSRV@CUVMA     watsun.cc.columbia.edu     Description

 K12MIT   ANN      kermit/d/k12mit.ann        Announcement of KERMIT-12
 K12MIT   UPD      kermit/d/k12mit.upd        Release update (this) file
 K12MIT   DSK      kermit/d/k12mit.dsk        Description of RX02 diskettes
 K12IPL   PAL      kermit/d/k12ipl.pal        .IPL loading program
 K12IP0   ODT      kermit/d/k12ip0.odt        ODT session creating IPL0.SV
 K12IP1   ODT      kermit/d/k12ip1.odt        ODT session creating IPL1.SV
 K12FL0   IPL      kermit/d/k12fl0.ipl        .IPL encoding of K12mit (FL0)
 K12FL1   IPL      kermit/d/k12fl1.ipl        .IPL encoding of K12mit (FL1)
 K12IPG   PAL      kermit/d/k12ipg.pal        .IPL-format encoding program
 K12IPL   DOC      kermit/d/k12ipl.doc        Description of .IPL format
 K12ENB   PAL      kermit/d/k12enb.pal        .BOO-format encoding program
 K12DEB   PAL      kermit/d/k12deb.pal        .BOO-format decoding program
 K12MIT   BOO      kermit/d/k12mit.boo        .BOO encoding of KERMIT-12
 K12PL8   BOO      kermit/d/k12pl8.boo        .BOO encoding of PAL8 Ver B0
 K12CRF   BOO      kermit/d/k12crf.boo        .BOO encoding of CREF Ver B0
 K12GLB   BOO      kermit/d/k12glb.boo        .BOO encoded TECO file macro

[Ed. - Thanks, Charles!  Additional information can be found in the new
file, k12mit.not (K12MIT NOT), a message from Charles to the "PDP-8 lovers"
mailing list.]

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

Date: Tue, 01 Oct 91  19:40:40 EDT
From: "Roger Fajman" <[e-mail]>
Subject: Re: New Serial Printer Driver for MS-DOS Kermit
Keywords: Printers, Serial Printers, MS-DOS Kermit and Serial Printers

> But DOS does not include any provision for flow control with a serial printer
> (parallel printers do this in hardware, automatically).  Therefore it is
> common to have printing problems when your communication speed with the host
> is faster than your printer's speed.  The solution is to install a printer
> driver that provides the needed flow control between the PC and the printer.

This is only partly true.  XON/XOFF flow control is not supported, but the
IBM PC and compatibles support hardware flow control on serial printers.  In
order to use it, you must have a printer that will drop some control signal
on the RS-232 interface when it wishes to stop incoming data and an
appropriately wired null modem cable.  Many serial printers can be configured
to drop DTR (Data Terminal Ready) on a buffer nearly full condition.  A
suitable null modem cable for such a configuration is wired as follows:

      20 (DTR) to 5 (CTS), 6 (DSR), 8 (CD)
      5 (CTS), 6 (DSR), 8 (CD) to 20 (DTR)
      2 (TD) to 3 (RD)
      3 (RD) to 2 (TD)
      7 (SG) to 7 (SG)
      1 (PG) to 1 (PG)  (optional)

Not all of these connections are strictly necessary, but I like to make them
this way because it makes the cable symetrical and works in a lot of
situations.

Roger Fajman                                   Telephone:  [phone]
National Institutes of Health                  BITNET:     RAF@NIHCU
Bethesda, Maryland, USA                        Internet:   [e-mail]

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

Date: Wed, 02 Oct 91 09:11:18 -0400
From: Joe Morris <[e-mail]>
Subject: Flow Control for IBM Mainframe Half Duplex Connections
Keywords: Printers, Serial Printers, MS-DOS Kermit and Serial Printers
Keywords: IBM Mainframes and Flow Control, Flow Control and IBM Mainframes

In INFO-KERMIT 8.14, Clement Lepoutre ([e-mail]) reports
having problems while printing through Kermit to a local printer.  The
problem is that while the printer is cheerfully doing its thing, the data
arriving from the host overflows the buffers and drops into the bit bucket.

> Is there something settable in Kermit for it to take a larger or smaller
> hunk of information before it gets sent to the printer?  We would like to
> work at a [comm line] speed faster than 1200, obviously.  Thanks for any
> suggestions.

To which Joe Doupnik replied, including the tag note:

> Plan B: If the "mainframe" in your message is an IBM one, and your
> connection to it is a half-duplex linemode connection, flow control can't
> be done.  The only workaround in this case is to send printed material to
> your disk instead of to the printer (SET PRINTER filename) and later print
> the file by ordinary means.  Without flow control, the mainframe will
> easily overrun the printer.

I haven't used it for years (mainly because we've got only one async line
for line-mode users...and I think it was last called in 1988) but there's
a zap for the 37x5 EP and PEP code which can provide flow control for
IBM half-duplex systems *if* you can deliver EIA flow control (RTS/CTS)
to the mainframe port.  It's marketed by COMM-PRO Associates in Manhattan
Beach, CA.  In our case we're running a Sytek async LAN, and it can be
set up to take XON/XOFF at one end of a path and deliver CTS/RTS on the other.
It's not a perfect solution, but given half-[duplex] ASCII architectural
limitations it resolved our problems.  (We needed it because the Sytek net
does speed translation, and we had to support local users at 9600 BPS
and dial users at 300 BPS on the same port.  It worked.)

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

Date: Tue, 15 Oct 91 10:21:51 EDT
From: H W Payne <[e-mail]>
Subject: MS-DOS Kermit Speed Under MS-Windows
Keywords: Windows 3.0, MS-DOS Kermit and Windows 3.0

In the July 25th, Kermit Digest issue I made a comment that using MS-DOS
Kermit, MS-DOS 4.01 and MS-Windows 3.0 causes the native win3 comm driver to
max out at 9600 bps.  This note was referring to the following configuration:

                                  telephone link
PC Comm Port <---> MNP modem <-------------------> MNP modem <-----> SUN OS
  386 PC                         V.42 link with                   workstation
                                  MNP 3, 4 or 5

Both modems are identical and are rated for 9600 bps. Kermit was used to set
the PC's Com Port speed to 19,200 bps.  The PC is a 386 (25 MHz) with an
asynchronous communications element (VL16C452) which is programmable to 1.8
MHz.

After talking with many people I still can NOT get the modems to talk to each
other at 19,200 bps.  How can I get 19,200 bps between the two modems with a
third party driver?  E.W.Carlson, how did you do it?

[Ed. - We have attempted to make contact with E.W. Carlson too, but so far no
response.  We observe the same effect on a 386SX (PS/2-55SX) -- it has to
flow-control the host at 19200, but seems to keep up at 9600.  On a regular
386 (PS/2-70) it does keep up at 19200.]

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

Date: Fri, 11 Oct 91 15:47:51 -0400
From: "Blaise M. Barney" <[e-mail]>
Subject: Kermit Packet Length Fluctuations
Keywords: Packet Length, Kermit Protocol

Why would kermit quit sending packet lengths of 1000 (specified with both the
set send packet-length 1000 and set receive packet-length 1000 commands) and
drop down to about 90?  This occurs after approximately ten minutes of file
transfer at a packet length of 1000.

[Ed. - Certain Kermit programs, notably Kermit-370 4.2 and C-Kermit 5A, when
sending files, reduce the packet length automatically when transmission
errors occur, and then gradually increase it again as transmission errors
subside.  This is done to reduce the chances that a future packet will be
corrupted by noise, as well as the retransmission time.  The method used by
Kermit-370 is described in Kermit News Volume 3 Number 1, June 1988,
available online as kermit/e/newsv1.n3 (Internet) and NEWSV1 N3 (BITNET
KERMSRV).]

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

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