Columbia Kermit/kermit.zip/e/mail.91b

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

From cmg  Tue Jul  9 16:33:19 1991
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA24985; Tue, 9 Jul 91 16:33:19 EDT
Date: Tue, 9 Jul 91 16:33:17 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V14 #1
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Tue, 9 Jul 1991        Volume 14 : Number 1

Today's Topics:

           New VT200/300 Key Mapping File for MS-DOS Kermit
           MS-DOS Kermit and Microsoft Windows 3.0
                 Kermit and Desqview
              Kermit, LAT & Windows 3.0 problem
           8-bit Linemode Devices on IBM Mainframes
              New VMSHEX/VMSDEH Programs


Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

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.  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: Thu, 20 Jun 1991 10:58 CST
>From: Kevin Lowey <[e-mail]>
Subject: New VT200/300 Key Mapping File for MS-DOS Kermit
Keywords: MS-DOS Kermit

Here is a new version of MSIVT3.INI (also known as VT300.INI) which fixes a
bug in the extended keyboard definition, in which the DEC Remove key was
mapped to a nonexistent scan code, rather than to Gray Delete.  Also, the PC
F11 and F12 keys on extended keyboards are now used for Help and Do,
respectively, and the DEC F11-F20 keys are now mapped to Alt-F1 through
Alt-F10 on both 88 and 101 keyboards, for consistency, and the DEC Enter key
was moved to PC F10 on the 88 keyboard to make it easier to use programs
that require the keypad Enter key.

[Ed. - Thanks, Kevin.  The new file replaces the old version as msivt3.ini.
The documentation file, msivt3.doc, has also been updated.]

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

Date: Tue,  25 Jun 1991 14:25:32 EDT
>From: Christine M Gianone <[e-mail]>
Subject: MS-DOS Kermit and Microsoft Windows 3.0
Keywords: MS-DOS Kermit and Windows 3.0, Windows 3.0
Xref: Microsoft Windows, See Windows 3.0

In response to numerous queries, here is the situation -- as best we know it
-- with MS-DOS Kermit and Microsoft Windows.

MS-DOS Kermit is not a "Windows Application".  It was not written
specifically for Windows, and it does not have a Windows-like menu-and-mouse
command interface.  However, MS-DOS Kermit has knowledge of the Windows
environment and can run "in a window" under certain conditions.  This means
that Kermit can run simultaneously with other Windows applications (even
other copies of Kermit), it can use Windows fonts, and you can cut and paste
to and from the Kermit window into other windows, etc, if you have
constructed the KERMIT.PIF file properly and you have enough memory for
Kermit.

When Kermit cannot be run in a Window, you can still use it under Windows as
a full-screen application.

Under Windows 2.0, you can use Kermit in a window on any kind of PC or PS/2
that has enough memory.  Everything works normally (but slower) except
Tektronix emulation, which behaves as if you had a monochrome video adapter
(plus signs are used instead of dots).  The important .PIF file parameters
are "Directly Modifies" (uncheck all the boxes), "Memory Requirements" (190
KB required, 400 KB desired), "Program Switch" (check Text box), "Screen
Exchange" (check Text/Graphics box).  If you don't have enough memory, you
can reduce Kermit's memory requirement by eliminating rollback screens: give
the DOS command "SET KERMIT=ROLLBACK 0" before starting Kermit, or put this
command into your MSKERMIT.INI file.

Under Windows 3.0, the situation is the same as for 2.0 if you are running
Windows on a 386 or 486 class PC in Enhanced Mode, with the added benefit
that Tektronix graphics works if you set up your KERMIT.PIF file for the
High Grahics Video Memory display option (however, Windows will complain
when you try to switch back to Kermit's text screen from the graphics
screen, and does not save the graphics screen).

However, Windows 3.0 apparently does not allow non-Windows DOS applications
(even Kermit, which is written with "Windows awareness") to operate in a
window in Real or Standard mode, which you must use on a 286 or lower class
PC, such as a PC, PC/XT, PC/AT, PS/2 Model 50, etc.  On these machines,
Windows 3.0 only allows Kermit to run in full-screen mode.  This seems to be
a limitation of Windows 3.0.  If anybody knows how to overcome this
limitation, please send mail about it to Info-Kermit.

If you can get Kermit into a window, but it does not communicate over the
COM1 or COM2 port, check your WIN.INI file to make sure that the MODE
command for COM1 or COM2 does not include a ",P" -- if it does, remove the
",P".

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

Date: Mon, 3 Jun 91 11:47:02 EDT
>From: Isidore G Bendrihem <[e-mail]>
Subject: Kermit and Desqview
Keywords: MS-DOS Kermit, DesqView

I've been running kermit under Desqview 386 (QEMM 5.11 and DV 2.31) with no
problems.  I recently installed an upgrade from Quaterdeck (QEMM 5.13 and DV
2.33), and whenever I start kermit, after giving the "Press ?  for help"
message, it freezes my computer up.  I can't even get back to Desqview.  It
seems like kermit has taken control over the keyboard.  Any suggestions?

Configuration:

386sx, 4 MB
Chips & Technologies chip set
AMI BIOS
MS-DOS 4.01
Kermit 3.10 (I've tried both with patches and without them)

[From jrd: What's one to say?  At the startup stage Kermit is using 100%
pure DOS calls to do everything. Kermit never grabs keyboard interrupts.
That leaves two possibilities: DV 2.33 has changed what needs to go into
your DV setup file for Kermit and/or DV 2.33 has problems.  MS-DOS Kermit
worked fine with the previous release of Quarterdeck software.]

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

Date: Tue, 4 Jun 1991 15:34:16 EDT
>From: [e-mail] (Maria Rosa Drake)
Subject: Kermit, LAT & Windows 3.0 problem
Keywords: MS-DOS Kermit, DEC Pathworks

We are running DECs PathWORKS network operating system, which provides LAT
support, and Kermit 3.01 and Kermit 3.10. We have no difficulty using Kermit
to access host systems via LAT when running under DOS; however we have
discovered that when invoking Kermit from within Windows 3.0 enhanced mode,
the system hangs (it works under Windows 3.0 standard mode).  Our
MSKERMIT.INI file does a SET PORT DECNET VAXname and a CONNECT; right after
connect is where the problems occur.

The systems are Zenith 386's with 4MB of RAM running either MS DOS 3.3+ or
MS DOS 4.0.  Any suggestions?

Maria Rosa Drake
Florida International University

[From jrd: One supposes that Pathworks is not designed to run by loading
DECnet outside Windows and then coupling a task to it within Windows.  At
least that's my guess.  The networking programs have to take some steps to
ensure the top level client is in the "right virtual machine" and so on, and
maybe your version of Pathworks does not do that job.  I make no pretense of
being a Windows 3.0 expert of any kind, but a suggestion is to start the
whole thing from a .BAT file within Windows, to see if that helps.  You
might also contact DEC to see if this is a known problem and get any
workarounds.  In addition, I would check the Pathworks documentation on
suggestions configuring Windows (things to be said in SYSTEM.INI etc
regarding networks).  It could turn out that Windows 3 itself is the culprit
when programs use high numbered interrupts for communications (DEC LAT and
CTERM both require these things to talk to external terminal emulators).]

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

Date: Wed, 1991 Jun 12   19:28 EDT
>From: "John F. Chandler"   <[e-mail]>
Subject: 8-bit Linemode Devices on IBM Mainframes
Keywords: IBM 370 Kermit

I am looking for people who would be interested in trying out 8-bit-wide
file transfer through a new generation of front ends on IBM mainframes.  The
following is a list of configurations that I believe may support the new
8-bit-wide ASCII communications, but it is not by any means complete and not
necessarily accurate.  I'd be interested to hear from anyone who has
knowledge of these or other 8-bit devices for "LU1" communications.  Also,
as I said before, I'm looking for testers willing to try out a version of
Kermit that has been modified to take advantage of the 8-bit capabilities.
I can be reached at either

  <[e-mail]>
or
  <[e-mail]>

Thanks.  By the way, even if all you can tell me is that I have
misspelled something in the list, I would still like to hear from you.
By the way, I posted this message on the BITNET discussion group for IBM
protocol convertors (which was the closest thing I could find to the
subject), but got no substantive answers.  I also posted it on the IBM
mainframe Kermit developers discussion group with no better results.

  Maker      Model          Software

  Fibronics  K2000          KNET/MVS
  Fibronics  K200           KNET/MVS
  Fibronics  K310           KNET/MVS
  Intel      Fastpath       ACCES/MVS
  ?          ACC9315        ACCES/MVS
  ?          Eicon/MSDOS    PACKET/74
  Intel      Jupiter 1000   PACKET/74
  IBM        37x5           COMMPRO/NAS
  Amdahl     47x5           COMMPRO/NAS
  Renex      RPAD
  Netlink    SNA/Gate
  Netlink    3703
  Perle      350/SNA
  Telematics PCI 167
  Telematics PCI 1067

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

Date: Wed, 5 Jun 1991 19:30:29 EDT
>From: [e-mail] (Jeff Guerber)
Subject: New VMSHEX/VMSDEH Programs
Keywords: VMS hex/dehex programs

It was recently pointed out on the Info-VAX mailing list that VMSHEX/VMSDEH
do not work for VAX indexed files -- they come out sequential instead.  I
took a look at the MACRO source, and it wasn't hard to find the bug -- the
file organization byte was not being saved in the hexified file, as were the
record format, record attributes, and so forth.  I have fixed the programs
(by adding a new packet type) so that they do save this byte, and they seem
to work as expected.  (I wasn't sure that they would, because the RMS manual
seems to indicate that extended attribute blocks are needed, but I
successfully hexed/dehexed an indexed file with 3 keys, and the new file
matched the original exactly.)  VMSDEH seems to work fine with older .HEX
files that don't have this packet, with the organization defaulting to
sequential as before.  A better method might be to save the entire file
access block and any extended attribute blocks, but this is beyond my
knowledge of MACRO and RMS.

If the Old VMSDEH is used on new-VMSHEXed files, the old VMSDEH gives an
"Unknown block type" error message, skips the new record and goes on to
do the rest of the input file, creating a sequential output file, and so
it appears that replacing the old VMSHEX/VMSDEH programs with the new ones
will do no harm.

Sorry, but I cannot take over support for these programs (if such is
needed); I really know very little about MACRO.

Jeff Guerber
ST Systems Corp. (STX)
NASA / Goddard, code 693.2
[e-mail]

Any opinions are my own and not those of NASA or STX.

[Ed. - Thanks, Jeff!  The new VMSHEX and VMSDEH programs have been placed
in the Kermit Test area for now.  If anybody encounters problems with them,
please send reports to Info-Kermit.  For that matter, if anyone can verify
that they do work as advertised, and are upwards compatible with the old
VMSHEX and VMSDEH programs, let us know.]

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

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

From cmg  Tue Aug 20 12:17:24 1991
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA19465; Tue, 20 Aug 91 12:17:24 EDT
Date: Tue, 20 Aug 91 12:17:23 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V14 #2
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Tue, 20 Aug 1991        Volume 14 : Number 2

Today's Topics:

         New Lotus 1-2-3/V Key Mapping File for MS-DOS Kermit
               Kermit With DOS 5.0 Task Swapper
        Windows 3.0 and High-Speed Kermit Connections
                  Window Slot Sizes
           Unique Log File Names for MS-DOS Kermit?
            Keyboard Bug in MS-DOS Kermit
                   Kermit Archives

Digest submissions may be sent to [e-mail],
requests for addition to or deletion from the Info-Kermit subscriber list to
[e-mail] or to [e-mail].

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.  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: Mon, 8 Jul 1991 15:20 CST
>From: [e-mail]
Subject: New Lotus 1-2-3/V Key Mapping File for MS-DOS Kermit
Keywords: MS-DOS Kermit, Lotus

Here at Southeastern Louisiana University, we have Lotus/123 on our VAX/VMS
system.  Many of our users use PCs with Kermit to access the VAX system and we
would like to have some method of maintaining transparency for the user, i.e.
we want the user to be able to use Lotus/123 on the Vax from his PC and have
it look and feel as though he were using PC Lotus.

I have created a Lotus 1-2-3 key mapping file for enhanced keyboards.  I am
sending that to you separately.  Feel free to make any suggestions/comments,
etc. and use it in the digest.

Ravi
BITNET:  RAVI@SLU
Southeastern Louisiana University

[Ed. - Thanks very much, Ravi!  The new file is in kermit/a/msi123.ini on
watsun, and MSI123.INI on KERMSRV.]

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

Date: Mon, 15 Jul 91 23:47:17 EDT
>From: Dick Elnicki <[e-mail]>
Subject: Kermit With DOS 5.0 Task Swapper
Keywords: MS-DOS Kermit and DOS 5.0, MS-DOS 5.0

DOS 5.0 and Kermit appear quite compatible.  I am currently using Kermit
with my EasyK scripts for this e-mail.

A program applicaton for Kermit access to our IBM VTAM services is in my DOS
Shell.  Before starting it, I enabled the Active Task list.  Then I clicked
on the program name to auto dial into our VTAM services.

Once signed on, I can press ALT with ESC to toggle back to the DOS Shell.
At the shell, I can start a second application, e.g., PCWrite or Lotus 123.
This, of course, depends on the free memory available.

The ALT with TAB's also works as described.  One can toggle through the
active tasks.  The name appears at the top of the screen.  A choice is make
by pressing Enter for a named task.

The ALT with ESC choice gives the DOS Shell as noted above. Here you can
also double click on the desired active task to return to it.  Or, you can
click on another program to start it (if you have enough free memory).  And,
you can click on an active task, then on FILE, and then on DELETE to shut
down an application.

My mouse works as desired.  It is an inexpensive 3-button mouse that is not
from IBM, Microsoft, or any other "name" brand.  The roller ball runs the
cursor, the left button is set to ENTER, the middle button is PF7 (scroll up
in the VTAM world), and the right button is PF8 (scroll down).

DOS 5.0 is certainly worth the price of admission.  It does run a number of
my applications that DOS 4.0 could not handle.  The DOS Shell run with the
mouse is easier to use than my old dozen-or-so AAA.BAT-type application
start-up screen.  The HELP is great, too.

This is not a commercial.  I don't have any stock in Microsoft.  I do hope
you can use the above to pass on to other Kermit users how they might use
DOS 5.0.

Best regards,
Dicke

[Ed. - Thanks for the encouraging report, Dicke!  It seems that we are going
through a period of Microsoft pulling the rug out from under Kermit with new
releases of Windows, DOS, etc.  Unfortunately, the reports are not all
completely positive.  One user reports that Kermit cannot keep up with serial
port input at high speeds -- 19,200 bps or above, depending on the processor
model, under DOS 5.0.  Apparently, DOS 5.0 can lose serial port interrupts
where previous versions of DOS did not, most likely because of its new memory
management features.]

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

Date: Thu, 25 Jul 91 16:06:52 EDT
>From: [e-mail]
Subject: Windows 3.0 and High-Speed Kermit Connections
Keywords: MS-DOS Kermit and Windows 3.0, Windows 3.0

If you desire to run MS-Kermit at speeds higher than 9600 bps under
Windows 3.0 (MS-DOS) you need a third party driver (i.e. TurboComm)
because the native Windows 3.0 communication driver maxes out at 9600.
You also need to have 16550a UART chips in your serial ports too.

H.W.Payne

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

Date: Fri, 26 Jul 91 15:57:35 -0700
>From: [e-mail] (Charles Lloyd)
Subject: Window Slot Sizes
Keywords: Sliding Windows, Packet Length, Performance

How does one determine the best size for a window slot?  I have a line which
has between 1 to 2  seconds roundtrip delay  (variable wrt time  of day) and
have not improved effective throughput much with choices or 1, 4, or 8.

Slot count = 1 : Significant idle time on LEDs of modem.
Slot count = 4 : Sporadic idle time, rapid acknowledgements on SD LED.

Slot Count = 8 : Alomost continuous flow on the RD light, almost continuous
blips on SD light.  Yet, the throughput only went from 5Kbps to 7 Kbps in
going from 1 to 8.  (I didn't check for slots = 4).

Is it unadvisable to play with packet size?

Is it possible to set the slot count too big so that data overruns cause
more errors than with a smaller window?  What's the rule of thumb?

Many thanks,
Charles.

[Ed. - There is an article in Kermit News #4 explaining in great detail how
to optimize Kermit's performance by varying the window slots and packet
length.  Kermit News #4 is on watsun as kermit/e/news.n4, NEWS.N4 on CUVMA
via KERMSRV.  Briefly, you should use the smallest window size that keeps
the modem receive or transmit light on continuously (depending on whether
you are sending or receiving files), and then increase the packet size to
the maximum allowed by the receiving Kermit.  Let's say you get continuous
transmission with 5 slots.  MS-DOS Kermit's total packet buffer size is
2000, so the maximum size for each packet is 2000 / 5 = 400.  Tell both
Kermits to SET WINDOW 5, and tell the receiving Kermit to SET RECEIVE
PACKET-LENGTH 400.]

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

Date: Sat Jul 20 19:13:04 1991
>From: Ben Olasov <syska.com![e-mail]>
Subject: Unique Log File Names for MS-DOS Kermit?
Keywords: MS-DOS Kermit and Unique File Names

I'm trying to turn on a session log file prior to invoking a Kermit script
file.  While the command line:

  kermit take cbd.scr

works, the line:

  kermit log session d:\local\20\250.txt take cbd.scr

doesn't.

[Ed. - Multiple commands on the command line must be separated by commas:

  kermit log session d:\local\20\250.txt, take cbd.scr

Adding the comma after "250.txt" should fix the problem.]

The reason I'm turning on the session log first is so that I can expand a
system variable (from Waffle BBS software) into a filename at the time
that the kermit command line is executed, thereby logging each session to
a unique filename.  If anyone knows how to do this, or has an effective
alternative approach, I'd really like to hear from them.

Thanks,
  Ben Olasov

[Ed. - If you're using MS-DOS Kermit version 3.10 or later (you should be),
try this:

  SET COUNT 999
  DEFINE \%F \V(NDATE).\V(COUNT)

This makes the \%f variable be something like "19910727.999" (filename =
today's date, filetype = 999).  Now let's see if the file already exists:

  IF NOT EXIST \%F GOTO OK

If it does, decrement the COUNT variable and try again until you have a
name that's unique:

  SET COUNT 999
  :LOOP
  DEFINE \%F \V(NDATE).\V(COUNT)
  IF NOT EXIST \%F GOTO OK
  IF COUNT GOTO LOOP
  ECHO Sorry, you've already created 1000 log files today!
  STOP
  :OK
  LOG SESSION \%F

That should give you a unique filename.]

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

Date: Tue, 09 Jul 91 11:45:24 BST
>From: Brian Wood <[e-mail]>
Subject: Keyboard Bug in MS-DOS Kermit
Keywords: MS-DOS Kermit and Keyboard Drivers

I am surprised that this has not been picked up sooner as it is a bug which
appears to have been present in MS-DOS Kermit since version 2.31.

On an OPUS PC3, a turbo xt, which I suspect is also sold under different
badges, running MS-DOS 3.3 there is a clash between Kermit and the keyboard
driver installed using the KEYB.COM program.  I have only used the driver
for the UK keyboard but logically it should apply to them all.  After
varying amounts of time the PC will appear to hang and will not respond to
the keyboard except that you will get the beep to tell you that the keyboard
buffer is full.  This may well happen with other machines which use MS-DOS
3.3 and KEYB.COM.

The remedy is to use "set key off" to force kermit to use the DOS keyboard
routines rather than BIOS.

Cheers,

Brian Wood,
UMIST,
Manchester,
England.

[Ed. - This is not a Kermit bug.  Kermit is simply asking the BIOS for
keyboard input.  Kermit is not hanging the system, the BIOS and/or the
keyboard driver are doing it.]

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

Date: Fri 2 Aug 1991 11:33:26 EDT
>From: Christine M Gianone <[e-mail]>
Subject: Kermit Archives
Keywords: Kermit Archives

We receive a lot of complaints that it's difficult to find things in the
Kermit archives, and suggestions about how to reorganize them.  Many people
would like to see us put the MS-DOS related files into ZIP archives, the
UNIX-related files into compressed tar archives, or put each version in its
own subdirectory, etc etc.

The Kermit archives are designed to be written to industry standard ANSI "D"
or IBM OS "VB" labeled tapes that can be read on a wide variety of computers.
These tapes can only have text files on them; they consist of "records" that
are lines of text, and they can't have any kind of directory structure.  Tapes
are sent out by mail order, and the income from these orders pays for the
Kermit Development and Distribution operation and subsidizes network access.
We don't have the disk space or the time to keep multiple copies of the
hundreds of different Kermit implementations in the many different formats
that network users ask for.  If we were better funded and staffed, of course,
it would be a different story.

Here is a brief road-map to the Kermit files.  There are five major Kermit
areas, A through E.  On watsun.cc.columbia.edu, which offers anonymous FTP
access to the Internet, there is a kermit directory.  It contains a file
called read.me, which explains the organization of the directories and files
underneath it:  kermit/a through kermit/e, plus several special directories
for binary files, test versions, etc.  On BITNET/EARN, Kermit file access is
handled by a file server called KERMSRV at CUVMA.  You can ask KERMSRV for
any file by name, as long as it is in one of the A through E areas.  Binary
files are not available on KERMSRV, but  test versions can be requested by
prefacing filenames with "T:", for example T:MSTIBM.BOO.

Each directory, a through e, contains a group of files whose names start
with "aa", for example aavers.hlp.  These are text files that list all the
Kermit versions, sorted in various ways: by computer, operating system,
language, area, release date, etc.

Within each directory, files for each version are grouped together by
filename.  Related files start with the same 2- or 3-letter prefix, for
example all the MS-DOS Kermit files start with "ms".  When there are many
files for a particular Kermit version, there is usually an "aaa" file for
that version, for example msaaaa.hlp or ckaaaa.hlp, that explains the file
naming conventions.

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

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

From cmg  Thu Aug 22 14:49:11 1991
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA22965; Thu, 22 Aug 91 14:49:11 EDT
Date: Thu, 22 Aug 91 14:49:10 EDT
To: Info-Kermit
From: Christine M Gianone <[e-mail]>
Subject: Info-Kermit Digest Now Delivered by LISTSERV
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>


The Info-Kermit Digest is now delivered by BITNET LISTSERV, which has proven
more reliable and flexible than UNIX sendmail.  All subscribers who were
previously on the Info-Kermit distribution list at watsun have been moved to
the I-KERMIT LISTSERV distribution list: [e-mail],
[e-mail].

Digest submissions should still be sent to [e-mail],
and administrative queries to [e-mail].
Alternatively, BITNET/EARN subscribers can send mail to KERMIT@CUVMA (not
I-KERMIT).  But from now on, you can subscribe to Info-Kermit yourself, you
can cancel your subscription yourself, and you can correct your personal name
yourself.  Just send e-mail to: [e-mail] (or to whatever BITNET
node you actually received this Digest issue from), and Internet subscribers
can mail to [e-mail].  In the text of the
message, use the following commands:

  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)

Remember: Don't send SUBSCRIBE, UNSUBSCRIBE, or REGISTER messages to I-KERMIT,
send them to LISTSERV.  Mail sent to I-KERMIT is forwarded to the whole list;
only the list owner is allowed to mail to I-KERMIT.  Send Digest submissions
or queries to KERMIT@CUVMA or to [e-mail].  If you
received this message, no action is required on your part.

Kermit files are still accessible in the normal way: from KERMSRV at CUVMA
on BITNET/EARN, and via anonymous FTP from watsun.cc.columbia.edu on the
Internet.  Internet users may also refer to watsun as:

  kermit.cc.columbia.edu

This name will remain effective in case the Kermit distribution host ever
changes from watsun to some other machine (this won't happen in the
foreseeable future).

For further information about LISTSERV, send mail to [e-mail]
containing the text "INFO".  Various reference cards, tutorials, and reference
manuals are available.

I trust that this change will result in fewer missed or duplicated issues,
and generally more reliable delivery.

From cmg  Fri Aug 23 15:13:06 1991
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA08669; Fri, 23 Aug 91 15:13:06 EDT
Date: Fri, 23 Aug 91 15:13:05 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V14 #3
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Fri, 23 Aug 1991        Volume 14 : Number 3

Today's Topics:

           MS-DOS Kermit 3.11 Prerelease Ready for Testing
          Termcap/Terminfo for MS-DOS Kermit on the Wang PC
              MS-DOS Kermit Speed under Windows

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: Fri, 23 Aug 1991 15:28 EDT
>From: Christine M Gianone <[e-mail]>
Subject: MS-DOS Kermit 3.11 Prerelease Ready for Testing
Keywords: MS-DOS Kermit 3.11, TCP/IP

>From Professor Joe R. Doupnik (JRD) of Utah State University, a new release
of MS-DOS Kermit.  The final release will occur in about one week, so rapid
testing and reporting of bugs is needed.  Please report problems directly via
e-mail to Joe: [e-mail] (Internet), JRD@USU (BITNET/EARN), with cc to
[e-mail].  Please limit your reports to bugs
(and/or fixes) -- the design and features of this release are frozen.  The
sooner you get your bug reports in, the greater the chances of getting the
bugs fixed!

The differences from version 3.10 are:

  NETWORKS:
  . Built-in TCP/IP network support for PCs with Ethernet-style packet drivers.
  . New SET PORT TCP/IP <host>, SET TCP/IP <parameter> <value> commands.
  . Alt-n has \Knethold assigned by default.
  . SET NETBIOS-NAME allows you to set the PC's Netbios node name.

  TERMINAL EMULATION:
  . VT220 terminal type now supported.
  . Alt-minus now toggles between current text terminal and graphics screens,
    rather than all possible terminal types.
  . SET TERMINAL CHARACTER-SET DEC-SPECIAL.
  . SET TERMINAL UPSS {DEC-MCS, LATIN1}.

  SCRIPT PROGRAMMING:
  . New OPEN, CLOSE, READ, and WRITE commands for local file access.
  . "Long variable names": \m(this-is-a-variable-name).
  . Maximum length for macro definitions raised from 255 to 1000.
  . GOTO is now global, rather than confined to current macro or command file.

  OTHER:
  . New simplified and expanded dialing directory using a plain text file.
  . All known 3.10 bugs are fixed.
  . Improved help and status screens.
  . New help and beware files.

The long variables work like this.  Define them as if they were macros:

  define telephone-number 7654321

Refer to them using the new \m() construct:

  output atdt \m(telephone-number)\13

Those who want to try out the TCP/IP networking support, but don't have
packet drivers, use anonymous FTP to get them from Clarkson College in
Potsdam, NY, host sun.soe.clarkson.edu [128.153.12.3], cd pub/ka9q, use "type
binary", get the appropriate zip, arc, zoo, etc, files, and use PKUNZIP or
ZOO on your PC to unpack them.  Only Ethernet-style packet drivers are
supported.  The new version of Kermit has been sucessfully tested with the
following boards and accompanying packet drivers:

  Ungermann-Bass PC/NIC board with Clarkson UBNICPC packet driver 9.1
  3COM 3C503 with Clarkson 3C503 packet driver 9.4.0
  Western Digital WD8003E with Clarkson WD8003E packet driver
  Cabletron boards with Cabletron CSIPD_E (1.05) and CSIPD_X packet drivers
  IBMTOKEN.COM 3C501 emulation packet driver 1.9 over Token Ring board+drivers
  DIS_PKT over NDIS for LAN Manager networks (incl DECnet/DOS, AT&T StarGROUP)

The new Kermit commands are:

  SET TCP/IP ADDRESS <ip-address>     Tell Kermit the IP address of your PC
  SET TCP/IP BROADCAST <ip-address>   IP broadcast address
  SET TCP/IP SUBNETMASK <ip-address>  Your local IP network subnet mask
  SET TCP/IP GATEWAY <ip-address>     IP address of nearest gateway
  SET TCP/IP DOMAIN <domain-name>     Domain name for your local IP network
  SET TCP/IP PRIMARY-NAMESERVER <ip-address>    Address of primary nameserver
  SET TCP/IP SECONDARY-NAMESERVER <ip-address>  Address of fallback nameserver
  SET TCP/IP HOST <ip-address or host-name>     Default host for SET PORT TCP
  SET PORT TCP/IP <ip-address or host-name>     Specify host to connect to

Automatic downloading of some of these parameters via BOOTP or RARP is also
supported.  Before using Kermit's TCP/IP features, be sure to read the TCP/IP
sections at the end of MSKERM.HLP and MSKERM.BWR!

Many thanks to Erick Engelke of Waterloo University in Ontario for
contributing his Waterloo TCP package (WATTCP), and for his cooperation in
adapting it to Kermit.

The new files are in kermit/test/ms* on watsun.cc.columbia.edu, and in T:MS*.*
on KERMSRV at CUVMA on BITNET/EARN.  Convert the MSTIBM.BOO file into
MSTIBM.EXE with any of the MSBPCT.* programs available in kermit/a or
kermit/bin, or from KERMSRV.  On the Internet only, the binary MSTIBM.EXE
program is available via binary-mode FTP from kermit/bin/mstibm.exe.
FTP users: remember -- transfer files from the kermit/bin directory in binary
mode, transfer all files from all the other directories in text (ASCII) mode.

Source code will appear with the final release.

See MSKERM.HLP for information about the new commands and about how to use
the dialing directory.  Make sure to get the new MSKERMIT.INI and MSIHAY.SCR
files too, since the dialing directory is implemented by these files (note,
you must rename MSIHAY.SCR to HAYES.SCR so the DIAL command can find it).
There is also a sample dialing directory file MSIDIA.TXT (rename to
DIALUPS.TXT).  The "beware file" for the new version is MSKERM.BWR -- be sure
to read it before reporting problems.

As always, our deepest thanks to Joe for his skill, generosity, patience, and
long hours of hard work in making this new version of MS-DOS Kermit available.

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

Date: Thu, 8 Aug 91 16:35:49 EDT
>From: [e-mail]
Subject: Termcap/Terminfo for MS-DOS Kermit on the Wang PC
Keywords: Wang PC Kermit

In case it's of interest to anyone else, I am sending my cheap way out of not
having a terminal emulator with the Wang PC version of MS-DOS Kermit: UNIX
termcap and terminfo files that will make the PC work as a VT100 minus
function keys.  (it has the correct screen and cursor escapes and the cursor
arrow keys which makes it completely adequate for full screen use but not
function keys).

Let me also mention that I've put the IBM-PC version of Kermit on several PC's
here we use as terminals, which had vt100 emulators only.  The vt320/tek
emulators are great and will probably save us from buying new graphics
terminals.  Keep up the good work!

Best regards,
                     Paul Mende
 [e-mail]            Center for Theoretical Physics
 [e-mail]            Massachusetts Inst. of Technology

[Ed. - Thanks, Paul.  The Wang PC termcap/terminfo material has been added
to the Kermit distribution as MSVWNG.TC.]

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

Date: Tue, 20 Aug 91 15:15:19 EST
>From: Pat Zerkle <[e-mail]>
Subject: MS-DOS Kermit Speed under Windows
Keywords: MS-DOS Kermit and Windows 3.0

Regarding newsletter comments re MS-DOS 5.0, Windows 3.0, and serial speeds
above 9600.  I use a 386/25MHz  64k cache, 4mb RAM 'AT Clone' (Club American)
with AMI BIOS, connecting via a DEC LAT to an IBM 7171.  I have had no
problem using MS-Kermit 3.1 at 19200 bps under MS-DOS 4.01, MS-DOS 5.0, and
via Windows 3.0 Enhanced under either DOS version.  In Windows, I use the
switch to enable background execution.  The maximum speed is probably limited
by a combination of software/BIOS/architecture/serial hardware/system load, so
we can probably only use empirical methods to get it to work.  As for Windows,
the files \WINDOWS\SYSIN*.TXT installed by Windows (at least, my 5/1/90 files)
explain several SYSTEM.INI settings related to COM ports.  The COMxBuffer and
COMBoostTime settings may help (hurt?) some users.

Cordially,
Pat Zerkle

[Ed. - Thanks for the encouraging report.  Another user, E.W. Carlson says,
"I don't understand the July 25 comment that MS-Kermit can not run faster
than 9600 baud under Windows.  I routinely run MS-Kermit at 19,200 baud
under Windows on a PS/2 55SX.  The machine is standard IBM equipment with
no special chips added."]

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

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


From cmg  Fri Aug 30 13:02:31 1991
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA13446; Fri, 30 Aug 91 13:02:31 EDT
Date: Fri, 30 Aug 91 13:02:30 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V14 #4
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Fri, 30 Aug 1991        Volume 14 : Number 4

Today's Topics:

          MS-DOS Kermit 3.11 Beta Testing Continues
                Kermit News #5
                The Old Curiosity Shop
            MS-DOS Kermit vs Twincom 9600/V42.bis
            Modem Initialization in  MS-DOS Kermit
         The Wonders of Kermit 0.98(63) and One Little Grouse

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: Fri, 30 Aug 1991 12:00 EDT
>From: Christine M Gianone <[e-mail]>
Subject: MS-DOS Kermit 3.11 Beta Testing Continues
Keywords: MS-DOS Kermit 3.11, TCP/IP

Reports on the beta release of MS-DOS Kermit 3.11 continue to pour in to
Professor Joe R. Doupnik (JRD) of Utah State University.  In order to take
full advantage of these reports and produce a solid official version, the
testing period will continue for a few more days.  The final release is
expected by the end of next week.

The new files will remain in kermit/test/ms* on watsun.cc.columbia.edu, and in
T:MS*.* on KERMSRV at CUVMA on BITNET/EARN until then.  Convert the MSTIBM.BOO
file into MSTIBM.EXE with any of the MSBPCT.* programs available in kermit/a
or kermit/bin, or from KERMSRV.  On the Internet only, the binary MSTIBM.EXE
program is available via binary-mode FTP from kermit/bin/mstibm.exe.  FTP
users: remember -- transfer files from the kermit/bin directory in binary
mode, transfer all files from all the other directories in text (ASCII) mode.

Source code will appear with the final release.

Once again we offer our deepest thanks to Joe for his skill and stamina
to make this new version of MS-DOS Kermit available.

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

Date: Fri, 30 Aug 1991 12:00 EDT
>From: Christine M Gianone <[e-mail]>
Subject: Kermit News #5
Keywords: Newsletter

Kermit News #5, our paper newsletter (ISSN 0899-0309), will be published in a
couple months.  If you received Kermit News #4, or if you ordered Kermit
material from us since June 1990, you're already on the mailing list.  If you
want to be added to the mailing list, send in your postal address.  Library
serials collections are encouraged to subscribe too.  No cost!  If you haven't
seen Kermit News before, copies of the last three issues are available online
as kermit/e/news*.* (NEWS*.* from KERMSRV).

If you would like to publish an article in Kermit News #5, please send it in!
We're looking for stories about interesting ways you or your organization are
using or benefitting from Kermit, technical articles, reviews, and anecdotes.
Articles should be about 500 words (rough guideline, we're not strict).  The
deadline is October 1, 1991.

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

Date: Sat, 24 Aug 91 01:19:23 MEZ
>From: "Gisbert W.Selke" <[e-mail]>
Subject: The Old Curiosity Shop
Keywords: MS-DOS Kermit and Arithmetic, PRODUCT Macro, Arithmetic

; File ARITHMET.INI
; Arithmetic for MS-DOS-Kermit!
; Gisbert W.Selke, Aug 1991.
; Share and enjoy.
;
; This collection of macro definitions for MS-DOS Kermit 3.10 (or later)
; was prompted by Chris Gianone's remark:
; "Meanwhile, creative Kermit users will no doubt find their own uses for
; [the PRODUCT macro]". (Using MS-DOS Kermit, 2nd ed., p 182)
;
; Having done some math, I think I *know* what a product is...
; Given that Joe D. has made Kermit with its script language a universal
; Turing machine...  There you are.
;
; TAKE this file from the MS-Kermit> prompt; then, you can do calculations:
; tadd  <number1> <number2> <...> : show sum of numbers
;                                   ex: tadd  15 17    yields 32
;                                   ex: tadd  15 17 19 yields 51
; tmult <number1> <number2> <...> : show product of numbers
;                                   ex: tmult 11 13    yields 143
;                                   ex: tmult 2 3 4 5  yields 120
; tfact <number>                  : show factorial of number
;                                   ex: tfact 5        yields 120
; Macros used internally are explained below.
;
; More importantly, when you're in CONNECT mode and your host sends a
; sequence like "ESC [ 15;7 ~", the product of the two numbers will
; appear on your screen.
;
; Remark: Multiplication can be implemented more efficiently. This is
;         left as an exercise for the reader. So are FFT and primality
;         testing for large integers.
;
; Uses variables \%a..\%e as arithmetic registers and for passing results.
;
; Elementary operations:
; Increment one-digit number (\%1) by 1; result in \%r, overflow in \%o:
def inc1  def \%o 0,if = \%1 0 def \%r 1,if = \%1 1 def \%r 2,-
if = \%1 2 def \%r 3,if = \%1 3 def \%r 4,if = \%1 4 def \%r 5,-
if > \%1 4 inc1b \%1
; internal macro for inc1:
def inc1b if = \%1 5 def \%r 6,if = \%1 6 def \%r 7,if = \%1 7 def \%r 8,-
if = \%1 8 def \%r 9,if = \%1 9 def \%r 0,if = \%1 9 def \%o 1
; Increment the number in registers \%a..\%e by 1:
def inc5  inc1 \%e, ass \%e \%r,if = \%o 0 go e,inc1 \%d, ass \%d \%r,-
if = \%o 0 go e,inc1 \%c, ass \%c \%r, if = \%o 0 go e,inc1 \%b,-
ass \%b \%r, if = \%o 0 go e,inc1 \%a, ass \%a \%r,:e

; Split multi-digit number into digits, result in \%a..\%e:
def split def \%a 0,def \%b 0,def \%c 0,def \%d 0,def \%e 0,-
if = \%1 0 go e,set cou \%1,:l,inc5 \%a \%b \%c \%d \%e,if cou go l,:e

; Add \%1 to number in \%a..\%e:
def add1  if = \%1 0 go e,set cou \%1,:l,inc5 \%a \%b \%c \%d \%e,-
if cou go l,:e
; Add two numbers; result in \%a..\%e:
def add   split 0,if > \v(argc) 1 split \%1,if > \v(argc) 2 add1 \%2,-
if > \v(argc) 3 add1 \%3,if > \v(argc) 4 add1 \%4,-
if > \v(argc) 5 add1 \%5,if > \v(argc) 6 add1 \%6,-
if > \v(argc) 7 add1 \%7,if > \v(argc) 8 add1 \%8,-
if > \v(argc) 9 add1 \%9

; Multiply number in \%a..\%e by \%1; result in \%a..\%e:
def mult1 set cou \%1,ass \%9 \%a\%b\%c\%d\%e,if > \%1 0 go s,split 0,-
go e,:l,add1 \%9,:s,if cou go l,:e
; Multiply two numbers; result in \%a..\%e:
def mult  split 1,if > \v(argc) 1 split \%1,if > \v(argc) 2 mult1 \%2,-
if > \v(argc) 3 mult1 \%3,if > \v(argc) 4 mult1 \%4,-
if > \v(argc) 5 mult1 \%5,if > \v(argc) 6 mult1 \%6,-
if > \v(argc) 7 mult1 \%7,if > \v(argc) 7 mult1 \%8,-
if > \v(argc) 9 mult1 \%9

; Time-honoured practice: a factorial routine:
def fact  split 1,if = \%1 0 go e,set count \%1,:l,mult1 \v(count),-
if cou go l,:e

; user interface macros: calls for macros above, plus display of result:
def fatal echo Error: \%1\13, def \%1, stop      ; error handler
def tinc1  inc1 \%1,echo \%o\%r                  ; ex: tinc1  5
def tinc5b inc5b \%1 \%2 \%3 \%4 \%5,echo \%a\%b\%c\%d\%e
                                                 ; ex: tinc5b 1 2 3 9 9
def tinc5  split \%1,inc5 \%a \%b \%c \%d \%e,echo \%a\%b\%c\%d\%e
                                                 ; ex: tinc5 99
def tsplit split \%1,echo \%a\%b\%c\%d\%e        ; ex: tsplit 12399
def tadd   add  \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9,echo \%a\%b\%c\%d\%e
def tadd1  add1 \%1,echo \%a\%b\%c\%d\%e         ; ex: split 17, tadd1 15
def tmult1 mult1 \%1,echo \%a\%b\%c\%d\%e        ; ex: split 13, tmult1 7
def tmult  mult \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9,echo \%a\%b\%c\%d\%e
def tfact  if not = \v(argc) 2 fatal {TFact takes exactly 1 numeric -
argument},fact \%1,echo \%a\%b\%c\%d\%e
; Multiplication per PRODUCT macro:
def product   mult \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9,-
askq \%9 Result is \%a\%b\%c\%d\%e\59 hit RETURN:,connect
; Factorial:
def factorial if not = \v(argc) 2 fatal {Factorial takes exactly 1 -
numeric argument},fact \%1,askq \%9 Result is \%a\%b\%c\%d\%e\59 -
hit RETURN:,connect
; End of MS-DOS-Kermit arithmetic routines.

\Gisbert

[Ed. - Gisbert, you have done a fine job of demonstrating the power, elegance,
user-friendliness, and ease of use of MS-DOS Kermit's script programming
language!  This breakthrough makes cryptic programming languages like C,
Fortran, and BASIC -- not to mention hand calculators -- totally obsolete.]

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

Date: 16 Aug 91 20:03:50 GMT
>From: [e-mail] (LIAM GUMLEY)
Subject: MS-DOS Kermit vs Twincom 9600/V42.bis
Keywords: MS-DOS Kermit, Modems

G'day people.

This is kind of a software question as well but I figured this was the best
place to post.

I have just installed a Twincom 9600/V42.bis modem in my 386.  I have been
using Kermit for a while with my previous 2400 baud modem, and was hoping to
continue using it with this modem.  However I cannot get kermit to 'wake-up'
the modem with the AT command.  I tried COMMO 4.52 for the same purpose and
it worked just fine with no special setup.

Scenario:

386 booted with 'clean' MSDOS 4.01 - no config.sys or autoexec.bat.
Modem has had dip-switches changed from 246 to 135 - to set COM1 and IRQ4.
No changes have been made to the modem NVRAM setup (factory defaults).
MS-Kermit 3.10 started with no initialization file.
Kermit commands are

set port 1
set speed 38400
connect

Now when I type AT there is no response.  If I start up COMMO, I get a
response with AT immediately.  If I dial with COMMO and get the modem
on-line, I can do a warm re-boot, and Kermit will then talk to the modem
normally (as far as I can tell).

So I figure there must be something that Kermit is not doing correctly
in sensing COM port speed or something.  I have tried all the
SET PORT and SET COM1 options that the Kermit beware file suggests, but
have had no luck.

Okay, I could trash Kermit and use COMMO.  But I want to use kermit if
possible.

Cheers,
Liam.

Liam E. Gumley
Research and Data Systems Corporation              Disclaimer:
Greenbelt MD, USA                                  Opinions I express here are
[e-mail]                           my own, not the company's.

[Ed. - Liam sent this later: "I have some good news.  I was playing with the
modem again this morning, and I thought "Why not try the DIAL script
(hayes.scr) you supplied with MS-Kermit 3.10?"  So I shut the computer down,
re-booted, started up kermit, then did a

  DIAL whatever

and it came back with:

  Error: Turn on or connect your modem

BUT within a second, it had woken up the modem, and was dialing the number.  I
changed hayes.scr to have the speed=38400 and to do ATDT tone dialling.
Kermit now works fine!  I can exit, and re-enter Kermit as usual.  I guess
that the initialization string output in HAYES.SCR is what does the good deed.
So it looks like things are working as they should.  Thanks again for your
very prompt reply.  I've been using Kermit for a few years now because it's
the only program I know that maps the DEC-VT keypad satisfactorily - once you
get used to it you don't want to change.  Heck, I have the little white and
gold DEC keypad stickers on my PC keyboard!]

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

Date: Wed, 21 Aug 1991 10:02:38 -0500 (CDT)
>From: Kathy Kothmann <[e-mail]>
Subject: Modem Initialization in  MS-DOS Kermit
Keywords: MS-DOS Kermit, Modems

We have an MS-DOS Kermit question which, although I have consulted
Christine Gianone's book on MS-Kermit, I cannot locate the answer.  I
hope the following excerpts will explain.

On Tue, 20 Aug 1991, Peter Ferrara wrote:

 > > Where does the initialization command go for setting up ms-kermit.  I am
 > > trying a VIVA 2400bps modem and can't get kermie baby to accept it.
 > > Its initialization command is ATE1V1X4QO&C1&D2 S7=255 SO=O^M
 > > pferrara@tenet

To which I responded:

> > Two suggestions:  First - edit the mskermit.ini file and put it in
> > there.
> > But a better alternative is to go ahead and type connect and get into
> > terminal mode and then type at <Return>.  Then type that long
> > initilization string and press <Return>.  Then type ATDT phonenumber.
> >
> > I think there's a way to customize the kermit files so that it will do
> > that for you... will check the manual I bought on MS-Kermit and see.
> > Kathy

And Peter answered this morning with:

> Thanks... I appreciate any help.  it seems that our ms-kermit version is
> generic and has a real difficult time accepting the "cheap" modems.
> Hope to hear from you soon.

NOW - I checked the .INI file and couldn't find anyplace to enter that
lengthy initialization string nor could I see how to get kermit to enter
it after typing CONNECT  (which is where I thnk it belongs).  What is
the easiest way for Peter to get that string sent to his modem?

We surely would appreciate some assistance.  If there is someone else we
should write, please let us know.

THANKS,
Kathy Kothmann
[e-mail]

[Ed. - Look at MSIHAY.SCR (which is normally renamed to HAYES.SCR).  The
following sends the modem initialization command.  Change it to whatever
is needed:

  output ATQ0V1X1\13              ; Send AT, use word result codes.

See your modem manual for details.]

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

Date: Wed, 21 Aug 91 17:42 BST
>From: Alan Grafen <[e-mail]>
Subject: The Wonders of Kermit 0.98(63) and One Little Grouse
Keywords: Mac Kermit

Dear Kermit People,
    I've just started using Kermit 0.98(63) for the Mac, and its wonderful.
Its cutting and pasting is extremely useful - no mainframe user can afford
to be without facilities of this kind.  BUT for some reason the clipboard is
private to Kermit.  I would like to cut from the Kermit window, and paste
into a word processor; and then cut from the word processor and paste into
the Kermit window.
    I'm sure this was not intended - and that other people have pointed this
out.  Please add my voice to those asking for a Mac-wide clipboard in the
next release.
    Kermit is a tremendous public service - please do not construe my letter
as a complaint.  Keep up the good work.
                                      Best Wishes,
                                         Alan Grafen

[Ed. - This problem should be fixed in the next release.  Unfortunately, we
are not quite sure exactly when that will be.  Watch Info-Kermit for
announcements.]

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

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

From cmg  Mon Sep 16 16:32:45 1991
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA20318; Mon, 16 Sep 91 16:32:45 EDT
Date: Mon, 16 Sep 91 16:32:44 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V14 #5
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Mon, 16 Sep 1991        Volume 14 : Number 5

Today's Topics:

               MS-DOS Kermit 3.11 is Released!
         New Second Edition of "Using MS-DOS Kermit"
        Kermit, TCP/IP, Packet Drivers, and the Future
           Adding TCP/IP Features to MS-DOS Kermit

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: Mon, 16 Sep 1991 14:00:00 EDT
>From: Christine M Gianone <[e-mail]>
Subject: MS-DOS Kermit 3.11 is Released!
Keywords: MS-DOS Kermit 3.11, TCP/IP, MCGA, Dialing Directory, Windows 3.0

This is to announce the final release of MS-DOS Kermit 3.11 from Professor
Joe R. Doupnik of Utah State University, and a new Second Edition of the
documentation, "Using MS-DOS Kermit" (see message below).

The major new feature of version 3.11 is its built-in support for
TCP/IP networking, adapted from parts of the Waterloo TCP package from Erick
Engelke of Waterloo University in Ontario.

Also included are script language improvements that allow for a much
improved DIAL command that can use a plain text file as a dialing directory,
and VT220 emulation to fill the gap between VT102 and VT320.  And finally, a
last-minute, down-to-the-wire improvement: support for high-resolution
Tektronix graphics on the PS/2 Model 25 and 30 MCGA video adapter.  Give the
command SET TERMINAL GRAPHICS VGA to use it (otherwise Kermit thinks the
MCGA is a CGA, and uses low-resolution graphics).

TCP/IP NETWORKING

Why add TCP/IP to Kermit?  Many people use both network and serial
connections, and until now had to switch between a Telnet program (which
doesn't support serial connections) and Kermit (which didn't support Telnet
connections).  For file transfer, the TCP/IP FTP protocol, while fast, does
not support many of Kermit's advanced features.  Kermit offers you features
not found in Telnet and FTP: a script programming language, flexible key
mapping, macros, international character set translation, and VT320
and Tektronix 401x terminal emulation.  Perhaps most important of all, now
you have a single application program and a common user interface for both
serial and network communication.

Kermit's TCP/IP and TELNET implementation takes up only about 30K of
additional program space.  It runs only over Ethernet-style packet drivers
(see Joe's article below) available from your network board vendor, or via
anonymous FTP from Clarkson University, host sun.soe.clarkson.edu
[128.153.12.3], cd pub/ka9q, use "type binary", get the appropriate zip, arc,
zoo, etc, files, use PKUNZIP, PKXARC, or ZOO on your PC to unpack them, read
the files READ.ME, MANIFEST.DOC, and INSTALL.DOC, and take it from there.
Copies are also available on watsun.cc.columbia.edu in kermit/packet-drivers
(source and documentation) and kermit/packet-drivers-bin (PC binaries).

Kermit supports downloading of its network parameters from BOOTP and RARP
servers, making it possible for all users of a corporate or campus network to
have the same initialization file -- a big plus for network managers.  Keep
your network information in a central database, rather than spread around on
scattered PC hard disks and diskettes!

Kermit's TELNET implementation automatically negotiates TELNET protocol
parameters such as local echoing, so connecting to a linemode TELNET server
(such as found on an IBM mainframe) works automatically.  However, Kermit
does not include built-in 3270 terminal emulation, so it is not (yet) a
replacement for tn3270.  But, it can be used with reverse telnet terminal
servers connected to IBM 7171 or other 3270 protocol converters.

Contrary to expectations, Kermit *can* make TCP/IP connections from within a
Microsoft Windows 3.0 Enhanced Mode window.  Kermit does not support multiple
simultaneous TCP/IP sessions, and the fact that you can run it under Windows
is not, unfortunately, an escape clause to this rule.  The packet driver only
allows one one application per protocol; this also means, for example, you
can't use Kermit and (say) NCSA telnet at the same time for TCP/IP
connections.  However, you can still have multiple copies of Kermit running,
as long as each one is using a different communication method, or a different
serial port.

Read the new help and beware files for more information about TCP/IP.

DIALING DIRECTORY AND MODEM SUPPORT

Kermit's new dialing directory is an ordinary plain-text file that Kermit's
DIAL macro searches using Kermit's new OPEN, READ, and CLOSE commands.  To
take advantage of this new feature, make sure you get a copy of the new
sample initialization file, MSKERMIT.INI, as well as the Hayes modem dialing
script program, MSIHAY.SCR (which you must rename to HAYES.SCR).  A sample
dialing directory is available as MSIDIA.TXT (which you must rename to
DIALUPS.TXT).

Kermit can also manage other types of modems besides Hayes.  Two steps are
necessary: (1) change the definition of the "_modem" variable in
MSKERMIT.INI, and (2) write a dialing script program for your modem, to
substitute for HAYES.SCR.  An example is provided for the IBM/Siemens/Rolm
CBX data phone (ROLMphone) in the file MSIROLM.SCR (which you should rename
to ROLM.SCR).  Readers are encouraged to develop scripts for other kinds of
modems and dialing methods, following the conventions used in HAYES.SCR and
ROLM.SCR, and send them in to us for distribution.

NEW FILES:

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

  GENERAL FILES

 kermit/a/mskerm.hlp       MSKERM HLP      Help file (plain text)
 kermit/a/mskerm.bwr       MSKERM BWR      "Beware File" (bugs & limitations)
 kermit/a/mskermit.ini     MSKERMIT INI    Sample initialization file
 kermit/a/mskermit.pch     MSKERMIT PCH    Sample patch file
 kermit/a/msidia.txt       MSIDIA TXT      Sample dialing directory file
 kermit/a/msihay.scr       MSIHAY SCR      Hayes modem dialing script
 kermit/a/msirolm.scr      MSIROLM SCR     ROLMphone dialing script

  EXECUTABLES

 kermit/bin/msvibm.exe     (none)          Executable Kermit program for IBM PC
 kermit/bin/msvibm.pif     (none)          Microsoft Windows 3.0 PIF file
 kermit/a/msvibm.boo       MSVIBM BOO      BOO-encoded .EXE file for IBM PC
 kermit/bin/msvgen.exe     (none)          Generic MS-DOS exectable
 kermit/a/msvgen.boo       MSVGEN BOO      BOO-encoded .EXE for generic DOS

  SOURCE FILES

 kermit/a/ms*.asm, ms*.h   MS* ASM, MS* H   Microsoft assembler source files
 kermit/a/msn*.*           MSN* *           C-language network source files
 kermit/a/msv*.lnk         MSV* LNK         Linker command files
 kermit/a/msv*.mak         MSV* MAK         Makefiles for "make"

All MS-DOS 3.11 IBM PC Kermit files have been removed from the test
directories, kermit/test/ms*.* on watsun and T:MS* * on KERMSRV.

The ".boo" files for each version are .EXE files encoded in a printable
ASCII format, suitable for BITNET, e-mail, and other nontransparent modes of
transmission.  You can decode the boo-files back into .EXE files using any
of the MSBPCT.* programs available in kermit/a/msbpct.* or MSBPCT * from
KERMSRV.  See msbaaa.hlp for details.

For a detailed description of the MS-DOS Kermit file naming conventions, see
the file msaaaa.hlp (MSAAAA HLP).  The MS-DOS Kermit implementations for
non-IBM compatibles (except the generic DOS version) have not yet been
upgraded to 3.11 level -- volunteers?

Once again, thanks to Joe for his skill, generosity, patience, dedication,
perserverence, and endurance (we're running out of adjectives for Joe!) in
putting this new MS-DOS Kermit version together and sharing it with us.  And
thanks to the beta testers who sent in such prompt and detailed reports of
problems so Joe could fix most of them so quickly!

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

Date: Mon, 16 Sep 1991 13:00:00 EDT
>From: Frank da Cruz <[e-mail]>
Subject: New Second Edition of "Using MS-DOS Kermit"
Keywords: MS-DOS Kermit 3.11, Using MS-DOS Kermit

MS-DOS Kermit 3.11 is accompanied by a brand-new revised and expanded Second
edition of Christine Gianone's book, "Using MS-DOS Kermit", Digital Press,
Bedford, MA, USA (1991), order number EY-H893E-DP, Digital Press ISBN
1-55558-082-3, Prentice Hall ISBN 0-13-952276-X.  The book includes a
5.25-inch 360KB MS-DOS Kermit 3.11 diskette.  The US single-copy price is
$34.95, up $5.00 from the first edition (not bad for 100 extra pages and 6
months work).  To order, call (USA, toll free) 1-800-343-8321.  It is also
available from Kermit Distribution at Columbia University and in software
stores and computer bookstores (where you'll recognize it easily by its new
purple cover).

A German language edition, "MS-DOS Kermit -- das universelle
Kommunikationsprogramm, Einfuehrung und Referenz", is published by Verlag
Heinz Heise GmbH & Co KG, Hannover, Germany, ISBN 3-88229-006-4, translated
by Gisbert W. Selke (proprietor of the Old Curiosity Shop from Info-Kermit
V14 #4), 5.25-inch 360KB diskette included, with many of the text files
translated into German, price 69 DM.

The new edition describes all the new features of version 3.11, including
everything that was added in versions 3.01, 3.02, and 3.10.  It has a new
chapter on local area networks (including TCP/IP); a new appendix with a
complete technical description of Kermit's terminal emulator with tables of
all the escape sequences recognized and sent by Kermit in both text and
graphics mode; expanded descriptions of many of Kermit's features, including
printer control and the script programming language, including the new
dialing directory features; an improved index.  There are also new
instructions for running Kermit under Windows and DesqView, for using LK250
keyboards, and there are many new tables, including one for Cyrillic
character sets.  The new book remains an excellent introduction (Einfuehrung)
for the novice, and it is now an even more complete reference (Referenz) for
the expert.

The first edition of "Using MS-DOS Kermit" was received with unanimous
approval by the critics.  Some samples from the book reviews:

"...one of the finest user guides, commercial, shareware, or otherwise, that
this reviewer has had the pleasure of reading."
  - Tom Nichol, Link-Up, July/August 1990 (p.8)

"An excellent introduction to computer communications, [Using MS-DOS Kermit]
explains in simple but intelligent language how to set up and get going."
"Must-read for PC buffs..."
  - Anne M. Russell, Working Woman, September 1990 (p.94)

"While the book is aimed at nontechnical readers, I highly recommend it to
all technical personnel in the computing field, particularly those who
abhore software manuals."
  - William Oblitey, ACM Computing Reviews, V32 #6, June 1991, pp.283-284

Both the English and German versions of the Second Edition should be
available in late September or early October.  Every copy sold helps support
the Kermit development and distribution effort, so don't be shy!

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

Date: Mon, 9 Sep 1991 20:38 MDT
>From: Joe Doupnik <[e-mail]>
Subject: Kermit, TCP/IP, Packet Drivers, and the Future

Release 3.11 of MS-DOS Kermit for IBM-PCs and compatibles opens a new
communications channel for Kermit: many hundreds of thousands of machines
around the world attached to the cooperative Internet network.  The lingua
franca of that channel is the TCP/IP protocol suite, including the Telnet
interactive protocol.  This is networking with a capital "N".

We have received many requests for Kermit to "talk over the Ethernet" to
other machines.  The impression held by those unfamiliar with the mysterious
art of communications is that one simply puts individual bytes on the
Ethernet much as we do with ordinary RS232-C wires.  Alas, the opposite is
true so it might be worthwhile reading the few paragraphs on this technical
matter.  Even if you know the Packet Driver story from my Novell activities
skim it for a repeat performance now underway with PD + NDIS + ODI.  After
that I'll mention some items about how Kermit handles Telnet.

Ethernet, Token Ring, and similar network transport systems are party lines
carrying traffic for many machines and using many different protocols.  To
keep the traffic flowing to the right places without ambiguity, the data --
our information -- is wrapped in administrative red tape with From: and To:
addresses and much more.  These ensembles are called packets or frames, and
their rules of construction and manipulation are aptly named protocols, not
unlike the Kermit protocol itself.

IP is one protocol, TCP is a higher-level protocol that uses IP as a shipping
agent.  Novell has the SPX and (shipping agent) IPX protocols, and so on.
Fortunately each of these can share the communications wire, time-sharing the
party line, with the others because they obey the same rules for primitive
addressing in the outermost wrapping of the packet or frame.  That's about
all they have in common: they drive on the same side of the road and they
recognize traffic lights.

The Internet is a massive voluntary interconnection of machines around the
world.  So not only do we have local addressing to do, but we have to be able
to send and receive packets through gateways to distant lands.  Interestingly,
with TCP/IP we, as people, typically use the names of the machines, but on
the wire only a numerical identification is employed.  So behind the scenes
name server machines have to quietly tell our program the number of the host
whenever we use the name.  We say NETLAB.USU.EDU but on the wire this machine
is known as 129.123.1.11, a 32-bit quantity.  As you might imagine, each
protocol has its own distinct rules about names and numbers, as if the other
protocols did not exist.  More alchemy.

What we see so far is that sending data bytes over Ethernet involves a lot of
busy work preparing packets in just the right format, with the address of
both sender and receiver and other vital administrative detail.  The wire can
carry a large variety of these packets.  This means each machine hears all
the packets, the network adapter board filters out all but those addressed to
the itself (and the broadcasts), and the machine must have code to pick out
the packets it wants and to wrap/unwrap (encode/decode) the interior shipping
instructions particular to the protocol it understands.  Serial RS232-C links
avoid all of this because there is only one machine at each end.

This brings us to a very local problem to be solved.  Our PC might wish to
use several protocols simultaneously.  For example, a NetWare (or StarGROUP
or PATHWORKS) file server is used to provide file service and we also want to
use TCP/IP Telnet to log onto a remote machine in Logan, Utah (Logan is
always "remote", no matter how close to it one may be).  That means both IPX
and IP need to share the Ethernet (or Token Ring, etc) communications board,
or we will need a board per protocol.  Thus the problem is: what hardware or
software will we need to use two or more protocols simultaneously?

Until a couple of years ago the solution to the problem was to purchase a
network adapter board for each protocol in each client machine.  Software of
one protocol attached to a board and knew how to converse with it (that's a
ticklish job known as being a device driver).  Pretty soon there were lots of
different boards, and one needed to buy software tailored for each one.  In
many cases, with only one board we had to reconfigure and reboot one's PC in
order to switch among different networking applications.

FTP Software Inc. of Wakefield, MA, USA, a vendor of PC-based TCP/IP
programs, soon went bananas trying to write drivers for each new Ethernet
board on the market.     They wisely decided that what was needed was a small
piece of code, called a Packet Driver, which did all the board-specific
functions yet provided a standardized interface (a virtual board) to the
application software.  They wrote the Packet Driver (PD) Specification, made
it public, and suggested that board makers write their own Packet Drivers so
that FTP Inc and other software houses could get on with their primary task
of creating useful communications programs (see John Romkey's recent article
in BYTE magazine).

More came of this than they may have realized.  Two aspects make Packet
Drivers very popular.  One is that the programs are tiny, only about 2.5KB,
and "relatively easy" to write.  Thus software vendors can provide a PD
interface as yet one more choice of board and save many tens of thousands of
dollars of development effort per product per year, per vendor.  That was
FTP's intention too: save internal resouces.  We benefit by lower software
production costs.

The second benefit is greater from the perspective of users (vs vendors).
That is, the PD specification permits several protocols to call upon it, the
owner of a single board, and each receives only the packets it wants.  The
requesting program thinks it owns a whole board.  So a user can run several
non-competing protocol stacks (networking software systems) at the same time,
each asking for different kinds of packets, yet using only one physical
network adapter.  For example, Kermit can send a file from a Novell file
server to a TCP/IP host, using a single Ethernet board.  Now we are getting
somewhere!

The demand for Packet Drivers became large quickly.  Individuals around the
world started writing them because board vendors were too slow.  Russel
Nelson, then at Clarkson University, established a clearing house for
user-written Packet Drivers and made them available at no charge.  Oh boy,
free and available now, available even across the network via anonymous FTP.
A personal observation is that the general public, or at least a broadly
based non-commercial group, is needed to make a standard take root and
prosper; individual companies have their own territory and traditions to
contend with.

In the interests of completeness I need to mention two roughly similar
systems that arose after Packet Drivers.  The first is NDIS, Network Driver
Interface Specification, by 3Com and Microsoft.  NDIS performs the same
functions as a Packet Driver, and a few more.  NDIS programs are entirely
commercial endeavors at present and all are much much larger than Packet
Drivers.  The most recent addition to the business is Novell's Open Datalink
Interface, ODI, also commercial presently and sized between PDs and NDIS.
ODI includes more features that the other two.  NDIS is used by Lan Manager
systems (DEC PATHWORKS, AT&T StarGROUP, 3Com 3+Open, and others); ODI is used
only by Novell NetWare at this time.  It appears that all three will live
side by side for some time to come.  But what about this side by side stuff;
didn't we just solve that for the network adapter case?

Now a new question arises: Can I run TCP/IP with a Packet Driver interface for
the program (say Kermit) together with AT&T StarGROUP together with NetWare?
Golly, will demands ever end?  The answer is: it can be done, easily!  FTP
Software, again, wrote a small program called DIS_PKT, and I expanded on their
effort with a program of the same name.  DIS_PKT sits on top of NDIS and
provides a Packet Driver interface for programs that want to communicate this
way, and it allows NDIS-style programs to use NDIS simultaneously.  Dan
Lanciani of Harvard has a preliminary program called ODIPKT that lets Novell's
ODI material sit on top of a Packet Driver, and Don Provan of Novell has
another named PDEther.  These little programs are given the trade name of
"shims", and for many of us they are worth their weight in gold (saved from
buying more LAN adapters, which if you recall, is where we came in).

Well, that was an educational diversion.  Back to TCP/IP in MS-DOS Kermit.
TCP/IP is a mature protocol with many many features.  Telnet is a protocol
sitting on top of TCP/IP which provides an error-checked terminal-like
communications pathway to a host.  The software to implement Telnet, and TCP,
and IP is complicated and normally fairly large.  Erick Engelke at the
University of Waterloo, Ontario, Canada, wrote a TCP/IP kernel which was
small enough to be considered for inclusion within Kermit itself, rather than
relying on programs such as NET14 and TNGLASS coupling to exterior TCP/IP
programs.  Much work later we accomplished the goal of embedding Telnet plus
TCP plus IP plus a good Packet Driver interface within Kermit, for an overall
cost of roughly 30KB increase of program size.  That's a bargain, folks.

Kermit includes procedures to talk with name servers to do that translation
of host names to numbers.  It has procedures for Kermit to learn its own
Internet address from servers of such things, via the BOOTP and RARP
protocols.  BOOTP can also supply name server addresses, a gateway address,
and so on.  Name resolution, etc, is all automatic from the user's
perspective, and based on the nuts and bolts discussion above it had better
be automatic!  The performance of built-in Telnet is much greater than the
alternative of coupling to an exterior TCP/IP program via BIOS Interrupt 14H,
and of course it is far faster than a serial RS232-C connection.

All connections require a communications program pay attention to the wire
very frequently.  LAN connections on Ethernet or Token Ring require even
closer than normal attention because packets arrive at incredible rates and
will jam up in the LAN adapter unless the communications program lends a
hand.  So Kermit has a small invisible background procedure to run the Telnet
code while Kermit itself sits at the command prompt or is sleeping while you
are shelled to DOS.  This reduces the clutter of fresh packets when Kermit is
not actively seeking them directly and it keeps the host happy.  By the way,
for the benefit of network managers, Kermit does not send only one data byte
in an individual IP network packet.  It gathers as many bytes as will fit
before a timer expires and exports few network packets.  A network monitor
shows Kermit file transfer activity to look much like FTP file transfers.  I
tried to make Kermit be nice to networks, and to their managers.

Another issue concerns running Kermit's Telnet path while in Windows 3.  The
technical problem is the Packet Driver calls on Kermit when each new packet
arrives, but Windows may move Kermit about in memory and thus the call goes
to the wrong spot (Uh-Oh time).  There is a simple solution.  Using the PIF
editor for a KERMIT.PIF file find the box labeled "Lock Application Memory"
in the Advanced Options section.  Check it.  That says don't move Kermit in
memory.  The nice consequence is Kermit is able to run in a window of
Enhanced Mode, and it will continue to run even when reduced to an icon.

Having Kermit use Telnet for local or long distance communication across
existing networks raises some interesting points.  The usual file transfer
program for TCP/IP work is FTP, File Transfer Protocol.  Those who use it
will tell you it is quick but not exactly smart nor user-friendly.  The
Kermit file transfer protocol is slower because it is designed for the worst
case situation of going from point A to B by many methods.  So FTP is faster
than Kermit-to-Kermit file transfers on a fast link.

But: Kermit can use many kinds of links whereas FTP can't, Kermit can
transfer the file time-and-date stamp, it can skip individual files or stop
the entire group of files when you wish during a big transfer, it can do
character-set to character-set transfers for international language
documents, it can rename files to avoid destroying originals, and so on.  The
process of moving information, not just raw bytes, is more advanced in Kermit
than in FTP.  In addition, Kermit is driven by user feedback and we respond
quickly.  FTP is not about to change much in the near future; what you have
now is what you will have several years from now.  Kermit's advanced features
are negotiated between any two Kermits so they always work even if one
program is five years older than the other, and runs on a vastly different
machine than the local PC.

It has been stated many times that there is a Kermit implementation for
almost every kind of computer in this world; the size of the Columbia
University Kermit archive supports it.  These programs are written by
individuals, volunteers, on a not-for-profit basis (costs usually are born by
them too).  New features appear at the rate which we, the volunteers, can
create them; the Kermit Project at Columbia exercises overall control so
matters remain coherent across Kermit software programs.

The popularity of Kermits, their responsiveness to the "marketplace" (i.e.,
the users), and their ability to work together between almost any pair of
machines makes Kermit an good vehicle for advancing the state of the art of
information exchange across communications channels.  Kermit is not wedded to
one communications method or protocol; it uses serial ports and MS-DOS Kermit
uses most of the commercially available networking channels.

However, adding new features costs: in time, money, and energy of talented
and experienced writers.  Each major addition, say adding 3270 emulation or
advanced Tektronix graphics support to MS-DOS Kermit, becomes a significant
project lasting months to years.  We are accomplishing with few people (who
by the way have regular full time jobs and careers other than Kermit) what
commercial software houses do with larger full-time paid staffs.  Thus major
advances need the support of the entire community, particularly from
commercial and government enterprises that benefit so heavily by not having
to pay hundreds of dollars per program per copy per year for connectivity.
Some companies have been very helpful by providing boards, software, or
complete operating environments.  Those contributions are much appreciated
and needed.  A firmer long-term basis is required so we can plan and
implement the strategically meaningful advances.

Kermit software has saved the corporate, government, and academic sectors
countless millions of dollars in its first ten years of existence.  As the
sophistication and demands of computer users grow, so too does the complexity
of the programming task.  If Kermit is to continue fill your needs and save
you money over the next ten years, let's hope some of the well-endowed
corporations and agencies that have done so well by our efforts will think
about supporting them in the future.

Additional features that many of you are requesting -- more ASCII terminal
emulations, multiple host sessions, 3270 emulation, ReGIS graphics, Tektronix
41xx and 42xx graphics, full integration with Windows 3.0, a fancy
menu-driven user interface with internationalized locales, etc -- each of
these is a massive project requiring additional dedicated programming staff
if these features are to be available in a timely fashion.  I ask for your
understanding when I say that these can't be provided in one or two releases.
The existance of strong requests is our reward that we are doing a good job
as you see it.

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

Date: Mon, 09 Sep 1991 18:18:46 EDT
>From: Erick Engelke <[e-mail]>
Subject: Adding TCP/IP Features to MS-DOS Kermit

Connectivity has come to mean much more than the RS-232 wires and modems
that webbed our offices in recent years.  Today's networks are connected
using a plethora of incompatible networking hardware, systems software and
hardware platforms.  But under the TCP/IP family of Internet protocols, all
these barriers melt away.  The newest version of MS-DOS Kermit is capable of
dealing with these intelligent, high-performance networks just as easily
as it has worked over other communication media for years.

The Waterloo TCP (WATTCP) code was developed at the University of Waterloo to
simplify creation or adaptation of TCP/IP-based utilities.  It uses a simple
and well defined application programmer's interface (API) based on a loose
adaptation of BSD networking functions.  The TCP portions actually execute
off the application program's stack.  This unusual practice simplifies
development and testing by allowing the application and the network functions
to all coexist in the same task.

One of the first applications written to demonstrate the capabilities of
WATTCP was a little program called TCPPORT which let Kermit or most other
communications programs be used as a TELNET client.  Although it seemed to be
merely an academic achievement and totalled less than 100 lines of 'C' code,
I started getting a growing quantity of mail from the masses who needed the
capabilities of MS-DOS Kermit in a TELNET package.  The most common reasons
cited were Kermit's international character support, its unmatched emulation
capabilities, and Kermit file transfers to machines not supporting FTP.

Within days I received a brief message from Frank da Cruz (C-Kermit author)
who had found the program and tried it with relative success.  To anyone
foolish enough to actually implement a TELNET client, there are hundreds of
documents (RFCs) which are required reading and nearly one hundred of them are
pertinent specifically to TELNET.  After much reading you must start the
eternal process of testing your version with everyone else's implementation.
One of the known problems TCPPORT had was the ability to crash some VMS
systems running poor but common TCP/IP implementations.  Frank's experience
from C-Kermit quickly resolved these and other problems.

By this time, Joe (author of MS-DOS Kermit) and Christine Gianone (Important
Kermit Person) had entered into our mail conversations and we started
discussing how we might incorporate the functionality of TCPPORT right into
MS-DOS Kermit.  MS-DOS Kermit had always packed an enormous number of
features into a pretty small package, but we felt we could add TELNET
capabilities without increasing the executable by more than thirty kilobytes.
This was a small cost for the enormous benefits.  It also a hard promise to
keep - we had overlooked some hidden data areas.

As soon as he had time, Joe dove right into the project and scrutized every
line of my code.  Since I had only started the WATTCP project about seven
months earlier, there were a number of areas which had not been fully tested
or which were incomplete.  During the Kermit-ization process, I mostly gave
advice and concentrated on the TCP core section while Joe did an amazing
amount of work in adapting and occasionally rewriting my efforts to fit his
needs.  He also acted coordinator, so we did not have to remember what
everyone else was doing.

Some of the features of my original code were of little use to MS-DOS Kermit,
so it became sort of a WATTCP-Lite, actually consuming less than twenty-five
kilobytes of the final Kermit executable.  Despite the occasional
simplification, we kept the API identical to the documented WATTCP API,
allowing us to keep our efforts coordinated for future revisions.

The process of perfecting the TELNET features was greatly simplified by the
Internet itself.  Whenver we were told of problems TELNETting to a particular
computer, we could KERMIT/TELNET there ourselves and solve the problems
without additional help.  In fact, we used Kermit to transfer updates to each
other.  This also allowed us to tune the long-distance capabilities which are
essential to a TELNET program.

The final product has the benefit of Frank, Christine, obviously Joe, and the
many volunteers whose efforts were too numerous to list.  This distributed
group of people has once again brought MS-DOS Kermit to the leading edge by
adding to its description: an excellent TELNET program.

Erick Engelke
WATTCP Architect
Faculty of Engineering
University of Waterloo
Waterloo, Canada

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

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


From cmg  Thu Sep 19 16:00:24 1991
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA02886; Thu, 19 Sep 91 16:00:24 EDT
Date: Thu, 19 Sep 91 16:00:23 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V14 #6
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Thu, 19 Sep 1991        Volume 14 : Number 6

Today's Topics:

           Announcing MS-DOS Kermit 2.32/A for Chinese DOS
           MS-DOS Kermit 3.11 Questions and Answers
               Mac Kermit Questions and Answers
              Kermit Files Slightly Reorganized
              Character Set Files and Utilities

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: Fri, 6 Sep 1991 15:28:00 EDT
>From: Quanfang Zhang <[e-mail]>
Subject: Announcing MS-DOS Kermit 2.32/A for Chinese DOS
Keywords: MS-DOS Kermit 2.32/A, Chinese DOS

I have translated MS-DOS Kermit Version 2.32/A into a Chinese version which
is called CC-DOS Kermit (CCKermit, the prompt is Kermit-CC) and can run under
either MS-DOS or CC-DOS (Chinese Code DOS).  When CC-Kermit runs under
MS-DOS, it is exactly the same as MS-DOS Kermit 2.32/A, but when it runs
under CC-DOS, all messages on the display are Chinese and the screen display
mode is also modified.  So if you know Chinese but little English, you can
also operate this Kermit successfully.

There are a lot of versions of CC-DOS, such as LIANXIAN, STCDOS, CCDOS213,
GWCDOS and so on, and among these versions many differences exist in the
screen display modes.  CC-Kermit can properly run on most CC-DOS versions.
In case you find it can't run on your machine, please let me know. I would
like to help you and make the program more satisfactory.

If you find bugs, please contact me.  I am going to do my best on this project
as time permits.

Quanfang Zhang
Computer Network Research Lab
Department of Computer Science & Engineering
Zhejiang University
Hangzhou 310027
PEOPLES REPUBLIC OF CHINA

Tel: [phone] ext 2400 or (571)761211
Email: [e-mail]

[Ed. - Hsei hsei, Quanfang Zhang!  Your Chinese DOS Kermit has been added
to the "C" area of the Kermit Distribution collection, as files CC*.*.
Also, in ~kermit/bin/ on watsun only, the binary executables: ccvibm.exe,
and ccvcga.exe (EGA and CGA versions, respectively).  The file ccaaaa.hlp
gives more information about this version.  The other files are organized
exactly like the MS-DOS Kermit files.  Many thanks for this contribution!]

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

Date: Thu, 20 Sep 1991 12:00:00 EDT
>From: Christine M Gianone <[e-mail]>
Subject: MS-DOS Kermit 3.11 Questions and Answers
Keywords: MS-DOS Kermit 3.11
Keywords: Token Ring, OUTPUT Command and MS-DOS Kermit 3.11
Keywords: PC-NFS and MS-DOS Kermit 3.11, SLIP, DIS_PKT
Keywords: DEPCA Ethernet Interface, TCP/IP, Packet Drivers

There has been an avalanche of mail about MS-DOS Kermit 3.11 over the past
few days.  Here are the most common questions, and some answers.  Much of
this is now noted in a slightly updated MSKERM.BWR file.

Q: Why can't I pick up the entire IBM PC 3.11 distribution in one file?

A: See the message on this topic in Info-Kermit V4 #2 about this.
   However, by popular demand, the IBM PC version of MS-DOS Kermit 3.11 is
   now available for binary-mode FTP from watsun as a ZIP archive:
   kermit/bin/msvibm.zip.  This file contains all the files that are on
   the distribution disk, plus a copy of the Digest announcement.  Thanks
   to Joe Doupnik for putting the ZIP archive together!

Q: I got MSVIBM.BOO from Kermit Distribution, and it was the Sept 6 version,
   rather than the Sept 7 version.

A: As of 8:15PM EDT, Sept 17, MSVIBM.BOO is the correct (Sept 7) version.
   Those who picked up this file before that time should replace it.  The
   Sept 6 version cannot be patched.  The Sept 7 version fixes this problem.
   The kermit/bin/msvibm.exe file on watsun was correct, however, and need
   not be replaced.

Q: My old script program doesn't work any more.  All my OUTPUT commands,
   which I abbreviated to "O", stopped working.

A: Version 3.11 includes a new OPEN command, so O is no longer a sufficient
   abbreviation for OUTPUT.  Make sure all your OUTPUT commands are
   abbreviated to at least "OU", and your OPEN commands to "OP".

Q: Why can't I make a TCP/IP connection with Kermit when I am also running
   PC-NFS?

A: Because the packet driver allows each protocol (such as ARP, RARP, IP,
   UDP, IPX, etc) to be used by only one application at a time.  This is a
   limitation of packet drivers.

Q: Why can't Kermit make TCP/IP connections over SLIP, Appletalk, or Token
   Ring packet drivers?

A: Because the code for this has not been written.  Kermit only knows how
   to talk to Ethernet-class (Class 1) packet drivers.  Support for the
   others, as well as built-in support for ODI and NDIS, are major
   development efforts.

Q: I can't make Kermit work with the Clarkson DEPCA.COM packet driver and
   a DEC DEPCA Ethernet board.

A: We have had several reports like this.  So far nobody has reported
   success with this one.  Make sure you read the installation
   instructions for the DEPCA packet driver -- it needs several special
   command-line parameters, and care must be taken that the default
   hardware interrupt number, 5, is not already used by some other device
   on your PC, like a disk drive or a printer port.  If anybody has had
   success with the DEPCA, please send a report.

Q: I can't get Kermit to make TCP/IP connections with the Harvard ODIPKT
   driver on a Token Ring network.

A: This would require additional coding in Kermit to understand Token Ring
   framing.  Kermit does work with ODIPKT over Ethernet.

Q: I can't assemble the file MSNTNI.ASM.  I get three errors "Cannot
   address with segment register".

A: This error occurs with newer releases of Microsoft MASM.  A new copy of
   the file MSNTNI.ASM has been installed that corrects this error, but
   which does not change the Kermit program in any way, and still works with
   MASM 5.0.

Q: Where do I get DIS_PKT?

A: (Msg from Joe Doupnik): There are two DIS_PKT'S, mine and FTP Software
   Inc's.  Mine is in an archive named DIS_PKT.TXT (uuencoded) or DIS_PKT.ZIP
   (same, PKZIP'd) on my VMS VAX, NETLAB.USU.EDU 129.123.1.11 in directories
   [.NOVELL] and [.NETWATCH].  FTP Inc's archive is named DIS_PTK.GUP (a
   nonsense phrase so we can tell apart our two renditions) on their VAX,
   VAX.FTP.COM.  I know mine works fine with almost everything, particularly
   AT&T StarGROUP.  My archive has a long how-to section with three example
   setups.  Recall that configuring Lan Manager material is a fine art.
   Fortunately adding DIS_PKT is really simple (one line in CONFIG.SYS, a
   half dozen in PROTOCOL.INI).  My samples show choices for WD8003E, 3C503,
   and AT&T EN100 boards.  Feel free to raid my cookie jars.

Q: Why does the new MSKERMIT.INI give lots of error message when used with the
   generic DOS Kermit version, MSVGEN.EXE?

A: It doesn't any more.  An updated version of MSKERMIT.INI is now available,
   which tests to make sure it is executing on an IBM PC or compatible before
   it tries to execute IBM-specific commands like SET TERMINAL.

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

Date: Thu, 20 Sep 1991 13:00:00 EDT
>From: Christine M Gianone <[e-mail]>
Subject: Mac Kermit Questions and Answers
Keywords: Mac Kermit

I have had literally thousands of inquiries about Mac Kermit in recent
months, many more than I can answer personally.  Let me try to summarize
the situation very briefly for everybody.

Q: Why doesn't (cut and paste, printing, etc etc etc etc etc) work in
   0.97(57), 0.98(63), 0.99(91), etc etc etc?  Why doesn't Mac Kermit work
   right under System 7?  Why are the fonts messed up?  Why isn't parity
   restored when I launch from a settings file?  Why do settings files created
   by different releases of Mac Kermit not call up the appropriate release
   when I open them?  Why are the key mappings for certain keys like Ctrl-@
   messed up?  How do I type international characters?  Why doesn't flow
   control work?  Why does Mac Kermit always hang up when I quit?  etc etc.

A: The last official release of Mac Kermit was 0.9(40).  Any version
   with a higher number is a test release, to be used at your own risk.
   The new Mac OS, System 7, came out after 0.9(40) and seems to have
   broken several of Mac Kermit's features.

Q: When will we see a new release of Mac Kermit?

A: Soon, I hope.  Our previous Macintosh volunteer programmer, Paul Placeway,
   has retired from Mac Kermit development after several years of hard work
   and invaluable contributions.  Several new developers have recently come
   forward, but it will take some time to come up with a new release that has
   the features you want, works with a wide range of Macintosh models,
   keyboards, and systems, and is well documented.  In the meantime, we have a
   very comprehensive list of bugs to correct and features to add, and this
   work is in progress.  Watch Info-Kermit for announcements of test releases.

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

Date: Thu, 20 Sep 1991 13:00:00 EDT
>From: Christine M Gianone <[e-mail]>
Subject: Kermit Files Slightly Reorganized
Keywords: Kermit Distribution

Due to the increased space required by MS-DOS Kermit 3.11, several Kermit
versions were moved from the "A" area to the "C" area (primarily the Atari
and CP/M-86 versions).  Also, several other Kermit versions were moved from
the "B" area to the "D" area -- long-discontinued systems like the DEC-20
(where Kermit was first developed) and the DEC-10.  Several obsolete and
redundant Kermit versions were totally retired.  If anybody notices that they
are missing and suffers for it, they can be resurrected.  A complete list of
the moves and changes can be found in the file AAVERS.UPD, the AAV*.HLP
files have been updated to show the new locations, as has AAFILES.HLP.

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

Date: Wed, 18 Sep 1991 20:14:12 EDT
>From: Christine M Gianone <[e-mail]>
Subject: Character Set Files and Utilities
Keywords: Character Set Files and Utilities, PostScript, Cyrillic

A new directory has been set up on watsun only: kermit/charsets.  The files
in this directory are not part of the normal Kermit distribution, and they do
not follow the normal naming conventions.  But they should prove useful to
Kermit users who want to use or learn about text files containing national
and international characters.

Included in the kermit/charsets directory are character set tables for many
character sets, which include the character names, values in decimal, octal,
hex, and row/column notation, and the 8-bit character values themselves.
Most of these tables (e.g. cp437.txt, cp850.txt, latin1.txt, next.txt, etc)
were produced by C programs (cp437.c, cp850.c, etc), so if you can't transfer
the 8-bit text successfully, get the corresponding C program, compile it, and
run it to recreate the character set table.

Also included is a program, textps, for converting plain text containing
8-bit characters to PostScript.  The original file can be in any of several
character sets including Latin-1, various IBM code pages, Apple QuickDraw,
NeXT, DEC MCS, etc.  You can use this program on any UNIX system, MS-DOS,
VAX/VMS, and any other computer that has a C compiler and supports the idea
of standard input and output redirection.  Thanks to Frank da Cruz for the
character set programs, tables, and the textps program.

Finally, the files cp866.doc and cp866.uue contain a Cyrillic code page
(real Cyrillic characters) you can use on your PC if it has an EGA or higher
and DOS 3.30 or higher.  This was contributed by Dimitri Vulis of the City
University of New York.  cp866.doc tells how to install the code page.

Once your Cyrillic code page is installed, you can display cp866.txt (the
Cyrillic code page table) on your screen locally from DOS, you can use DOS
applications to create and view Cyrillic files, etc.  MS-DOS Kermit 3.10 and
later supports CP866 as a file transfer character set, and you can also use
your Cyrillic code page during during terminal emulation with any of three
commonly used Cyrillic host character sets: ISO 8859-5, KOI-8, or Short KOI.
Kermit initialization files, from Konstantin Vinogradov of the International
Centre for Scientific and Technical Information in Moscow, are provided for
this purpose in the files kermit/charsets/*.ini.

The organization and naming of the files in this area is subject to change.
Meanwhile, additional contributions to this collection of character set
tables and utilities are most welcome.

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

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

From cmg  Wed Sep 25 11:58:15 1991
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA11541; Wed, 25 Sep 91 11:58:15 EDT
Date: Wed, 25 Sep 91 11:58:13 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V14 #7
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Wed, 25 Sep 1991        Volume 14 : Number 7

Today's Topics:

               New IBM Mainframe Kermit Release
          Announcing IBM Mainframe Kermit-370 Version 4.2.2
         List of Supported Front Ends for Kermit-370
         Announcing IBM Mainframe Kermit-370 for CICS
       Announcing IBM Mainframe VM/CMS Kermit-370 Version 4.2.2
      Announcing IBM Mainframe MVS/TSO Kermit-370 Version 4.2.2
                ROSCOE Kermit

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,  24 Sep 1991 14:25:32 EDT
>From: Christine M Gianone <[e-mail]>
Subject: New IBM Mainframe Kermit Release

Here comes a battery of announcements from John Chandler of the
Harvard/Smithsonian Center for Astrophysics in Cambridge, Massachusetts, for
IBM Mainframe Kermit-370 version 4.2.2 for the major IBM mainframe operating
systems.  Most notable among these is a brand new version for CICS, which can
be used under either MVS or DOS/VSE.  People have been asking for this for
nearly ten years!  Now they can shave off their long white beards...

The new files are in ~kermit/b/ik*.* on watsun for anonymous FTP over the
Internet, and on BITNET/EARN as IK* * from KERMSRV at CUVMA.  Included are
brand new versions of the user manuals in plain-text (.DOC), "line printer"
with carriage control (.LPT), and PostScript (.PS), one for each major
version: IKCKER (VM/CMS), IKTKER (VMS/TSO), and IKXKER (CICS).  Also included
are detailed installation instructions (the IK*KER.INS files) and other
documentation (.HLP, .BWR, etc).

Each version comes in two parts: the system-independent part (IK0), and
the system-dependent part (IKC, IKT, IKX).  You have to get both parts:


           ftp watsun           BITNET/EARN
           cd kermit/b          KERMSRV@CUVMA

  VM/CMS   ik0*.* and ikc*.*    IK0* * and IKC* *
  MVS/TSO  ik0*.* and ikt*.*    IK0* * and IKT* *
  CICS     ik0*.* and ikx*.*    IK0* * and IKX* *

Many thanks to John and to all the contributors and beta testers for these
significant new Kermit releases.

Now, if only somebody will produce a Kermit program for the AS/400, and
Systems /34, /36, and /38, we will have Kermit programs for all the major
IBM machines and operating systems.

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

Date: Monday, 1991 August 19  14:08 EDT
>From: "John F. Chandler"  <[e-mail]>
Subject: Announcing IBM Mainframe Kermit-370 Version 4.2.2
Keywords: IBM 370 Kermit
Xref: IBM Mainframe, See IBM 370

Kermit-370 version 4.2.2 is now available for CMS, TSO, and CICS.  The
changes are primarily generic, but there are also some system-specific
updates in each variant.  See the accompanying system-specific
announcements for the details: IKCKER.ANN (CMS), IKXKER.ANN (CICS), and
IKTKER.ANN (TSO).  The most important of the generic updates are:

 1) New "CC" option along with the line range for sending files.  This
    option specifies that the file has carriage control in column 1 and
    that it should be converted to ASCII control characters.

 2) More careful avoidance of built-in packet-size limits.

 3) V-binary (or D-binary) file transfers work all the way up to records
    of 64K-1 bytes.

 4) Leaving server mode if packet I/O errors recur.

 5) More liberal recognition of STOP commands in protocol mode.

 6) Extra explanatory error message, if available, now displayed upon
    completing a subcommand, along with basic status.  Also, any reason
    for cancellation is included in the E-packet text and noted in the
    transaction log.

 7) Time tags in transaction and packet logs.

 8) New TRANSPARENT transfer character set, which applies a null
    translation to all incoming and outgoing files.

 9) New SET TTABLE KP option which enables a full 8-bit translation
    table based on Hollerith codes.

10) Proper control-quoting on 8-bit analogs of ordinary control
    characters.

11) Suppression of echoing on LU1 3770-type front ends.

12) New VERSION subcommand, which displays the version number and date.

13) New "End-of-attributes" attribute.

14) 8th-bit quoting for the XECHO subcommand.

The new release is in the form of updates to be applied to the 4.2
source.  The updates are cumulative, so they include those that were
already released to make version 4.2.1.  In addition, the generic 370
part of the User's Guide has been updated to reflect version 4.2.1.

Many thanks to the beta testers who have helped work out the bugs.

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

Date: Tuesday, 1991 August 20  19:40 EDT
>From: "John F. Chandler"  <[e-mail]>
Subject: List of Supported Front Ends for Kermit-370
Keywords: IBM 370 Kermit and Supported Front Ends

There is a new version of IK0AAA.HLP to go with release 4.2.2 of several
variants of Kermit-370, and this seems like a good time to summarize the
changes in the list of supported "front ends".  Here is the list of new
entries added since the version of April 1990, complete with references
to footnotes in the new list.  The types shown are the abbreviation of
the relevant controller types in Kermit-370.  Those marked (3) are still
questionable, i.e., the reports were not conclusive.  Of the additions,
only one (the IBM 3174 AEA) represents an enhancement of Kermit itself;
the others are simply new reports or changes in the status of the "front
end" software.  In this time span, there have not been any new reports
of UNsupported front ends, just a reconfirmation of the limitation of
the IBM 3708 to linemode Kermit transfers.

  Name, model    Type Manufacturer              Notes
  -------------- ---- ------------------------- -----
  Amdahl 4705    T    Amdahl                    (2)
  Datalynx 3174  G    Andrew Data Systems       (3)
  Datalynx 3274  G    "                         (3)
  IBM 3174 AEA   A    IBM                       (6)
  IBM 3745       T    "                         (2)
  Jupiter 1000   T    Intel                     (14)
  K200           T    Fibronics                 (14)
  K310           T    "                         (14)
  K2000          T    "                         (14)
  Renex PCM      G    Renex Corp                (8)
  Renex RPAD     G    "                         (8)
  SIM3278 TCP/IP S    Simware                   (1,4)
  SIM3278/VM     S    Simware                   (1,4)
  STNxx          T    STRTC                     (13)
  tn3270         S    Greg Minshall             (1,2,11)

For the complete list of supported configurations, and for the
footnotes, see IK0AAA.HLP in the Kermit distribution.

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

Date: Monday, 1991 August 19  14:08 EDT
>From: "John F. Chandler"  <[e-mail]>
Subject: Announcing IBM Mainframe Kermit-370 for CICS
Keywords: IBM 370 Kermit, CICS Kermit
Xref: CICS Kermit, Also see IBM 370

There is now a variant of Kermit-370 for CICS.  The new Kermit has been
tested under releases 1.7 and 2.1 of CICS and with CICS running under
both VSE and MVS.  This is a full-function Kermit, like other variants
of Kermit-370, but is still a test program, since it has not been
subjected to any large-scale testing, and several planned refinements
have not yet been implemented.  Kermit-CICS is both a traditional
interactive Kermit and a CICS program that can be invoked to carry out a
specific file transfer or group of transfers and then quit.  Thus, it is
suitable both for "open" CICS systems where the users are permitted to
log in as "operators" and controlled systems where all activity is
performed through menus.  Kermit-CICS surmounts the lack of a real CICS
file system by managing its own storage directories assigned to specific
users, where each directory has members described by eight-character
names; the assignment of directories is done according to an algorithm
chosen by the local installer.  In addition, Kermit supports transfers
of TD and TS queues.  The initial version is release 4.2.2 and includes
a number of enhancements that are also appearing in the new releases for
CMS, TSO, MUSIC, and ROSCOE.  However, these enhancements are not listed
here, since this is the first version of Kermit-370 for CICS.  See the
relevant announcements for more details.  Work on Kermit-CICS is
continuing, but some of the tasks necessary for making it a full-fledged
production program have not even been started.

Features that need to be improved or added include:

 - IKXDYNAL for both CICS/VSE and CICS/MVS.  The former would probably
   support only spool files, but the latter should support both spool
   files and MVS data sets.

 - Sample exit routines for supporting userid algorithms besides the
   OPID and TERM options.

 - Sample package of security exit routines.

 - Enqueuing on extra-partition TD names before opening.

 - Support for data objects on a remote CICS.

 - Cleaner performance of server-mode BYE function, dependent on local
   conventions.

 - Support for indirect TD queues.

 - Testing linemode operation.

 - Mechanism for flushing terminal output from Kermit (such as from the
   TYPE subcommand).

 - Mechanism for collecting "terminal" output from invoked programs.

 - Testing under CICS/VM.

Anyone interested in working on these or other improvements should first
get in touch with the Center for Computing Activities at Columbia
University to find out if someone else has already begun a similar
project (and, if so, who).

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

Date: Monday, 1991 August 19  14:08 EDT
>From: "John F. Chandler"  <[e-mail]>
Subject: Announcing IBM Mainframe VM/CMS Kermit-370 Version 4.2.2
Keywords: IBM 370 Kermit, VM/CMS Kermit
Xref: CMS Kermit, See VM/CMS Kermit, IBM 370 Kermit

Kermit-370 version 4.2.2 is now available for CMS.  As usual, the new
version comes in VM/SP and VM/XA/SP flavors, but the changes are the
same for both.

Version 4.2.2 has numerous improvements over 4.2.1, but many of them are
generic (shared among all the variants).  See the accompanying generic
Kermit-370 announcement for more details.  The most important of the
CMS-specific updates are:

1) New, more flexible on-line help facility with a separate file
   available for each subcommand.  This can be used in connection with
   the CMS help menu system or with Kermit's internal help processor (or
   both).  The old-style, single help file is also still available.

2) Improved recovery from a "stolen" screen, fullscreen I/O errors,
   the classical VTAM lockup at the start of a SEND (caused by having
   too long a SEND delay), or a 4994 buffer overrun.

3) Kermit-CMS now invokes CMS commands in a way that closely matches the
   behavior of commands entered directly to CMS.

A more complete description of the changes can be found in IKCKER.BWR.

The new release is in the form of updates to be applied to the 4.2.0
source.  The updates are cumulative, so they include those that were
already released to make version 4.2.1.  In addition, the help file has
been revamped, and the User's Guide has been partly updated (but not
actually brought up to date with 4.2.2).  The new files are IKCKER.UPD,
IKCKER.BWR, IKCKER.MSS, IKCKER.DOC, IKCKER.LPT, IKCKER.PS, IKCKER.HLP,
IK0KER.MSS, IK0AAA.HLP, and IK0KER.UPD (the latter is only a catalog of
all the updates, not the updates themselves).  The new code has been
tested pretty thoroughly (many thanks to the beta testers!), but
problems may still turn up.  Bug reports are welcome, as usual.  In
particular, reports of any kind are needed for the new facility for
supporting 8-bit transfers in line mode -- this has barely been tested.

A similar release 4.2.2 is also available for TSO and CICS -- see the
corresponding announcements.

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

Date: Monday, 1991 August 19  14:08 EDT
>From: "John F. Chandler"  <[e-mail]>
Subject: Announcing IBM Mainframe MVS/TSO Kermit-370 Version 4.2.2
Keywords: IBM 370 Kermit, MVS/TSO Kermit
Xref: TSO Kermit, See MVS/TSO Kermit, IBM 370 Kermit

Kermit-370 version 4.2.2 is now available for TSO.  The new version has
numerous improvements over 4.2.1, but many of them are generic (shared
among all the variants).  See the accompanying generic Kermit-370
announcement for more details.  The TSO-specific updates are:

1) Correct UNIT selection for new datasets uploaded to TSO.  This fixes
   a bug introduced with version 4.1.

2) Multiple subcommands allowed on the initial invocation command line,
   provided the Kermit delimiter is defined in one of the initialization
   files.

3) Current status code available to CLIST's as &LASTCC.

A more complete description of the changes can be found in IKTKER.BWR.

The new release is in the form of updates to be applied to the 4.2.0
source.  The updates are cumulative, so they include those that were
already released to make version 4.2.1.  In addition, the help file has
been revamped, and the User's Guide has been partly updated (but not
actually brought up to date with 4.2.2).  The new files are IKTKER.UPD,
IKTKER.BWR, IKTKER.MSS, IKTKER.DOC, IKTKER.LPT, IKTKER.PS, IKTKER.HLP,
IK0KER.MSS, IK0AAA.HLP, and IK0KER.UPD (the latter is only a catalog of
all the updates, not the updates themselves).  The new code has been
tested pretty thoroughly (many thanks to the beta testers!), but
problems may still turn up.  Bug reports are welcome, as usual.  In
particular, reports of any kind are needed for the new facility for
supporting 8-bit transfers in line mode -- this has barely been tested.

A similar release 4.2.2 is also available for CMS and CICS -- see the
corresponding announcements.

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

Date: Fri, 1991 Mar 29   22:04 EST
>From: "John F. Chandler"   <[e-mail]>
Subject: ROSCOE Kermit
Keywords: IBM 370 Kermit, ROSCOE Kermit
Xref: ROSCOE Kermit, Also see IBM 370
Xref: MVS/TSO Kermit, Also see IBM 370

I have stored two new files on WATSUN: IKRKER.BWR and IKRKER.UPD.  These
constitute the collection of all known tips, fixes, and workarounds for
running TSO Kermit under ROSCOE.  This is not what I would call a full-
fledged new variant of Kermit-370, since ROSCOE Kermit is only slightly
changed from "vanilla" TSO Kermit.  Hence, installers of ROSCOE Kermit
will still need to fetch all IKT*.* files and follow the instructions in
IKTKER.INS with only a few alterations based on IKRKER.BWR.  If further
reports come in, I'll add them to the collection.  Also, I would be glad
to include code updates, especially if some user should feel motivated
to add support for native ROSCOE files or other ROSCOE-specific features.

                                     John

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

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

From cmg  Tue Oct  1 17:01:44 1991
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA02956; Tue, 1 Oct 91 17:01:44 EDT
Date: Tue, 1 Oct 91 17:01:43 EDT
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V14 #8
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Tue, 1 Oct 1991        Volume 14 : Number 8

Today's Topics:

            New Patch File for MS-DOS Kermit 3.11
         New Serial Printer Driver for MS-DOS Kermit
           Printing from MS-DOS Kermit on a Novell Printer
           Problems with DOS 5, DesqView, and MS-DOS Kermit
          Running MS-DOS Kermit 3.11 under DesqView
            MS-DOS Kermit 3.11 and Packet Drivers
            DEPCA Success with MS-DOS Kermit 3.11
          MS-DOS Kermit 3.11 Packet Size Problem with TCP/IP
           Kermit 3.11 TCP/IP Connections Dropping
            PC Kermit 3.11 Q&A: A Small Correction
         Something Good in DOS 5.0 for MS-DOS Kermit
               MS-DOS Kermit Keyboard Problems
              MS-DOS Kermit and Hebrew?
           MS-DOS Kermit and Horizontal Scrolling?


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: Sun, 29 Sep 91 21:35:02 EDT
>From: "Joe R. Doupnik" <[e-mail]>
Subject: New Patch File for MS-DOS Kermit 3.11
Keywords: MS-DOS Kermit 3.11 Patches

Here is a new patch file containing patches 1 to 4 for MS-DOS Kermit 3.11,
IBM PC version.

  Patch 1 (optional): Supply an alterate video mode for the Orchid Designer
    Professional VGA board when switching from 80 to 132 columns.

  Patch 2: Correct unwanted double echo from TCP/IP Telnet negotiations.

  Patch 3: Correct cursor indexing problem with scrolling region setup.

  Patch 4: Correct nested curly brace matching in Kermit commands.

Joe D.

[Ed. - Thanks, Joe.  The new patch file is in kermit/a/mskermit.pch on watsun
(Internet) and MSKERMIT PCH on KERMSRV@CUVMA (BITNET/EARN).  To apply these
patches, store this file in the same directory as your MSKERMIT.INI file and
uncomment the PATCH command in your MSKERMIT.INI file.]

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

Date: Tue,  1 Oct 91 12:00:00 EDT
>From: Christine M Gianone <[e-mail]>
Subject: New Serial Printer Driver for MS-DOS Kermit
Keywords: Printers, Serial Printers, MS-DOS Kermit and Serial Printers

One of the most common questions about MS-DOS Kermit is how to use it with a
serial printer.  In the words of Joe Doupnik:

"MS-DOS Kermit prints by sending material straight to DOS.  It does so by
gathering up to 128 bytes in a buffer, sends an XOFF to the host (if flow
control is being used), does a buffer write to DOS, and then sends an XON to
the host.  In the buffer writing process there are also checks on whether DOS
thinks the printer is ready and that all the characters were accepted, etc.

"By using DOS rather than the IBM PC BIOS interrupts or even particular
hardware we gain the ability to write the code once for many kinds of
machines, remove a mountain of code necessary to manipulate either serial or
parallel ports (if they exist), and most importantly we can write to
networked printers and print-to-disk TSRs and whatnot.  We can also change
the name of the print channel used by Kermit from PRN to any legal DOS name
(SET PRINT command)."

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.

Joe Doupnik recently found such a (public domain) utility and sent it in.
Originally called XONXOFF.COM, it was written by Frank Whaley in 1989.  It
works only for COM1, so it would be nice if somebody fixed it to allow any
COM port (address and IRQ) to be specified on the command line.  It can be
picked up from Kermit Distribution as kermit/a/mspspd.* on watsun (Internet)
or MSPSPD * from KERMSRV on CUVMA (BITNET/EARN).  The files are
mspspd.asm (the assembler source file), mspspd.hlp (a help file), and
mspspd.boo (a "boo" encoding of the binary .COM file).  Also, on watsun only,
the binary .COM file is available in kermit/bin/mspspd.com.

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

Date: Mon, 16 Sep 91 14:29 EST
>From: Clement Lepoutre <[e-mail]>
Subject: Printing from MS-DOS Kermit on a Novell Printer
Keywords: Printers, MS-DOS Kermit and Printers, Novell Networks

We have a PC which is hooked up to an old Novell network system.  It connects
to our mainframe where the person does some lists.  We have been able to
print those lists on the networked printer but get some errors at higher
speeds (e.g. 9600).  In other words, at 9600 the whole list does not get
printed whereas at 1200 the list comes out fine.  We feel the higher speed is
too fast for the network or Kermit to handle.

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 speed faster than 1200, obviously.  Thanks for any suggestions.

[from jrd - Plan A: It's neither the network nor Kermit having the problem,
but rather the PC.  Whatever is doing the printing on the PC is keeping
interrupts off for long periods and that prevents the serial port from
notifying Kermit that a new character has arrived.  The slower the machine
the more likely this will be.  I try very hard to avoid this specific problem
by first buffering characters within Kermit, up to 128 of them, then when the
buffer fills I first tell the host XOFF, then ask DOS to print them, finally
tell the host XON.  If you have turned off flow control in Kermit then these
hold-ups are not sent.  If you use a print spooler in the PC to pass
information to the printer then (a) that spooler will eat lots of CPU cycles,
alas, and (b) it may do so well after Kermit has done the stop/print/start
work.  If this is the case then please don't use the spooler (the DOS PRINT
command is such a beast too).  Another case is using a printer on a serial
port and the serial port driver is consuming the machine so that Kermit's
port can't get through.  In that case try a different serial port driver, or
use a parallel port.  Beware of having TSRs present which consume lots of CPU
cycles.

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

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

Date: Thu, 12 Sep 91 19:25:34 MEZ
>From: Erich Neuwirth <[e-mail]>
Subject: Problems with DOS 5, DesqView, and MS-DOS Kermit
Keywords: MS-DOS 5.0, MS-DOS Kermit and DOS 5.0
Keywords: DesqView, MS-DOS Kermit and DesqView

I have problems with MS-DOS Kermit since I installed DOS 5.  Not under plain
DOS, but when I am running DesqView under DOS 5.  I tried DesqView 2.31 and
DesqView 2.34, and in both cases it does not work.  (Additionally I am
running QEMM 5.11, I do not yet have a later version.)

When I open a DesqView window containing Kermit the machine simply hangs and
does not accept any keyboard input any more.  Even Ctrl-Alt-Del does NOT
work, so I really have to switch off.  The problem occurs both with Kermit
3.10 and Kermit 3.11.  The problem also occurs when I use TAME (i.e.
TAME-RES.COM) before running Kermit.

My machine is a Mycomp 25 MHz 386 with 4 MB of memory and an AMI BIOS.
Usually I have not experienced any compatibility problems.  Am I alone with
this kind of problem or are more people experiencing something similar?

[Ed. - Later, Erich writes:...]

The DesqView people solved my problem, and you might be interested in the
solution.  You have to set Optimize communications in the Advanced Setup
menu to NO.  Then it works.  The manual, though, states, that then you might
have problems with higher baud rates (4800 and higher).  Since currently I
am running at 2400 bps, this is no problem.

ERICH NEUWIRTH
BITNET (EARN): A4422DAB@AWIUNI11
INTERNET:      [e-mail]
Institute for Statistics and Computer Science
UNIVERSITY OF VIENNA, UNIVERSITAETSSTR. 5/9, A-1010 VIENNA, AUSTRIA

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

Date: 23 Sep 91 16:48:18 GMT
>From: [e-mail] (Keith Petersen)
Newsgroups: comp.binaries.ibm.pc.archives,comp.os.msdos.desqview
Subject: Running MS-DOS Kermit 3.11 under DesqView
Keywords: DesqView, MS-DOS Kermit and DesqView

I am running MS-DOS Kermit v3.11 in a DESQview window.  It takes more memory
than the previous version but works fine for me.

                              Change a Program

Program Name............: Kermit COM2
Keys to Use on Open Menu: KR                         Memory Size (in K): 265
Program...: \bin\kermit.exe
Parameters: take kermit2.ini
Directory.: \incoming
Options:
                 Writes text directly to screen.......: [N]
                 Displays graphics information........: [N]
                 Virtualize text/graphics (Y,N,T).....: [N]
                 Uses serial ports (Y,N,1,2)..........: [2]
                 Requires floppy diskette.............: [N]

                     Change a Program Advanced Options

System Memory (in K).......:   0   Maximum Program Memory Size (in K)..:
Script Buffer Size.......:     0   Maximum Expanded Memory Size (in K):    0
Text Pages: 1  Graphics Pages: 0   Initial Mode:  3     Interrupts: 00 to FF
Window Position:
   Maximum Height:  25       Starting Height:  20       Starting Row...:   5
   Maximum Width.:  80       Starting Width.:  40       Starting Column:   5

                               Shared Program
Pathname..: \dv\noff.shp
Data......:

Close on exit (Y,N,blank)......: [Y]  Uses its own colors..............: [Y]
Allow Close Window command.....: [N]  Runs in background (Y,N,blank)...: [Y]
Uses math coprocessor..........: [N]  Keyboard conflict (0-F)..........: [0]
Share CPU when foreground......: [Y]  Share EGA when foreground/zoomed.: [Y]
Can be swapped out (Y,N,blank).: [N]  Protection level (0-3)...........: [0]

In AUTOEXEC.BAT I have this, to minimize Kermit's use of memory:

  set KERMIT=ROLLBACK 0

Keith Petersen
Internet: [e-mail]     or     [e-mail]
Uucp: uunet!umich!vela!w8sdz                          BITNET: w8sdz@OAKLAND

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

Date: Sat, 21 Sep 91 06:36:36 EDT
>From: Russ Nelson <[e-mail]>
To: [e-mail]
Subject: MS-DOS Kermit 3.11 and Packet Drivers
Keywords: Packet Drivers, MS-DOS Kermit 3.11 and Packet Drivers
Keywords: DEPCA Ethernet Interface, TCP/IP

   Q: Why can't I make a TCP/IP connection with Kermit when I am also running
      PC-NFS?

   A: Because the packet driver allows each protocol (such as ARP, RARP, IP,
      UDP, IPX, etc) to be used by only one application at a time.  This is a
      limitation of packet drivers.

A2: Strictly speaking, it's a limitation of protocol stacks.  You can only
    run one protocol stack per node.  Otherwise, you'll have problems, e.g.
    which TCP/IP stack would answer ICMP messages?

   Q: I can't make Kermit work with the Clarkson DEPCA.COM packet driver and
      a DEC DEPCA Ethernet board.

   A: We have had several reports like this.  So far nobody has reported
      success with this one.

A2: The DEPCA.COM packet driver version 9.0 is known to fail on Turbo DEPCAs
    (DE-200), and old DEPCAs.  There is an interim release of it that fixes
    the Turbo DEPCA problem on sun.soe.clarkson.edu, in pub/ka9q called
    depca.com.  I am working on reverse-engineering the differences between
    the new and old DEPCAs, so eventually it will be made to work on the old
    DEPCAs also.

[Ed. - Thanks, Russ!  More about the DEPCA below...]

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

Date: Mon, 23 Sep 1991 13:19 +1200
>From: "John Davis" <[e-mail]>
Subject: DEPCA Success with MS-DOS Kermit 3.11
Keywords: Packet Drivers, MS-DOS Kermit 3.11 and Packet Drivers
Keywords: DEPCA Ethernet Interface, DEC Pathworks, TCP/IP, DIS_PKT

>Q: I can't make Kermit work with the Clarkson DEPCA.COM packet driver and
>   a DEC DEPCA Ethernet board.
>
Well, you now have at least _one_ success story :-)

I just ftp'd MS-DOS Kermit 3.11 and installed it on my machine, which runs
one of the older DPECA's (full length, 8 bit model - predates the current
LC/TURBO models).

I'm using the v9.1 clarkson DEPCA driver (which does work even though it
doesn't really support the older card - only probs are the ethernet address
is set to a ridiculous number, and promiscuous mode doesn't work), installed
on interrupt 0x7e (as SOSS requires that interrupt vector for the packet
driver), card is set for IRQ=5, IO=300h, and full 64K of memory at
D000:0000.  This setup works just fine with NCSA telnet, and after filling in
the appropriate section in MSKERMIT.INI it also works fine with MS-DOS
Kermit 3.11...

John Davis - [e-mail]
(Depart)mental Programmer,Chemistry Department
University of Canterbury, Christchurch, New Zealand

[Ed. - From a similar message from Robert L. Divany, <[e-mail]>:
"Old and new DEC cards seem to be referred to collectively as DEPCA cards,
even though they are quite different.  DEC refers to the new cards as
Etherworks controllers.  The DEPCA packet driver was released at about the
end of 1990, and was based on specifications supplied to Clarkson by DEC.  A
note from DEC is included with the Clarkson PD distribution in a file named
DEPCA.NOT.  Quoting from that file, "The Driver supports our most current
technology, and not, unfortunately, older DEPCA's".  In spite of this, I
have used the Clarkson DEPCA driver from release 8 and 9 with success on
some, but not all, new DE cards and on an older DEPCA (series E02) card.  I
have used release 9.1 of the driver with success on ALL DE and DEPCA cards
tested.  This includes the DE100 LC card, the DE200 Turbo, the DE210
Microchannel card and older DEPCA cards, both series D and E.  I suggest
that version 9.1 of the driver be tried if earlier versions fail.  Note that
version 9.1 is not the same as the driver supplied with the last release of
the packet driver collection (version 9).  Version 9.1 is available for
anonymous FTP from SUN.SOE.CLARKSON.EDU in /pub/packet-drivers/depca.com.
Be sure to use binary (Image) mode."]

[Ed. - And from Andy Evans, Plymouth State College, Plymouth, NH
<[e-mail]>: "I have more than 100 of the 'old' DEPCA cards on
our campus. We have site license for PathWorks V4.0 and I picked up DEC's
Client TCP/IP package for evaluation. It contains just what you are looking
for, an NDIS driver for that card.  Packet-Drivers run quite nicely with it,
and I haven't found a Packet Spec. application that didn't!  If you chose to
run just packets, you can retain 605K+ of low DOS memory on a 386 with
Quarterdeck. This is the only way I've successfully run TCP/IP on that card
(DEC's driver). The full implementation of DEC's Client TCP/IP is a bit of a
memory hog. Allows redirection of disks (file services) and printers - a big
plus.  DEC's TCP/IP NDIS suite was written by someone else (3COM / Hewlett
Packard) When I had some initial bugs the folks in Atlata (DEC Tech Suppt)
expressed dissatisfaction with it and the fact a replacement might be
considered (by DEC).  In time I have grown to like it, Packet Drivers over
NDIS with DIS_PKT.DOS works quite well. We are heavy Kermit users and have
been enjoying the new version regardless of communication protocol - it does
'em all doesn't it!??!!"]

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

Date: 24 Sep 91 17:20:26 GMT
>From: [e-mail] (Dale Phurrough)
Subject: MS-DOS Kermit 3.11 Packet Size Problem with TCP/IP
Keywords: Packet Drivers, MS-DOS Kermit 3.11 and Packet Drivers
Keywords: TCP/IP, MS-DOS Kermit 3.11 and TCP/IP, Packet Length

I remember the problem in 3.10 with packet sizes using the Ungermann Bass
ports and such.  Does this problem persist in 3.11 using the packet drivers
with the TCP/IP port?  It seems to.  I had to reduce my sending packet size
to 128.  My receive packet seems to be OK at any size.  Any ideas out there?

[From jrd - Kermit will try to fill a TCP packet, about 512 bytes of data,
until a short timer expires.  A straight UB connection gets offered up to
512 bytes of data (or to the end of a Kermit packet).  The indications are
some part of your UB network cannot stand such long packets.  That is also
true of some other terminal-like network pathways, such as LAT and TES,
at roughly 256 and 512 bytes respectively.  And they too are able to send
longer material to us than vice versa.  The reasons are in the way those
pieces of software are designed; they expect more terminal activity than
long file transfers.]

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

Date: 25 Sep 91 00:33:24 PST
>From: "Terry McKiernan"  <[e-mail]>
Subject: Kermit 3.11 TCP/IP Connections Dropping
Keywords: TCP/IP, MS-DOS Kermit 3.11 and TCP/IP

I'm having a problem maintaining MS-DOS Kermit 3.11 TCP/IP connections.  Can
you lend a hand?  Here is my setup:

    MS-DOS Kermit (MSVIBM) 3.11, from watsun.cc on September 19.
    various PCs, XTs, ATs
    HP EtherTwist 10-baseT adapters, HP hubs
    NetWare 3.11, TCPIP.NLM loaded, rip=yes, forward=yes
    BYU packet-driver IPX v. 2.01
    Clarkson packet driver v. 9.0.0
    Internet connection via PS/2 ethernet-to-token bridge (AIX)

The problem is, we can make connections to Internet sites, but as soon as we
connect, the connection is dropped.  The "connected" screen appears for a
split second (clear screen, status bar at bottom, beep), then the connection
drops and we are back at the MS-Kermit> prompt.

[From jrd - I don't want to create wrong ideas by speculating, but it is
possible the NetWare 3.11 server is not transmitting all the packets in both
directions.  That is typically a subnet mask error.  I have not yet had a
chance to route TCP through my NW 3.11 server so I offer this only as
speculation.]

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

Date: Tue, 24 Sep 91 00:54 PDT
>From: Denis DeLaRoca <[e-mail]>
Subject: PC Kermit 3.11 Q&A: A Small Correction
Keywords: Packet Drivers, MS-DOS Kermit 3.11 and Packet Drivers
Keywords: Token Ring, SLIP, TCP/IP

The latest Kermit digest contains a very useful Q&A summary for the
newly released TCP-based PC-Kermit... it points out that it doesn't
run on SLIP or Token Ring Packet drivers as framing for those protocols
has not yet been implemented in the TCP/IP code.  True for the SLIP
case and only half true for the TR case.  The current TR PD is a "fake"
Ethernet driver (type=1) and thus quite compatible with the TCP/IP
code in Kermit!

-- Denis DeLaRoca
   UCLA Office of Academic Computing

[Ed. - Thanks, Denis.  Many people said this.  Yes, Kermit does indeed work
over the IBMTOKEN.COM packet driver because IBMTOKEN.COM is an Ethernet
class driver.  But it does not work over Token-Ring class packet drivers,
nor over ODIPKT over Token Ring.]

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

Date: Mon, 23 Sep 1991 10:56 GMT-0200
>From: Petri Kaukasoina <[e-mail]>
Subject: Something Good in DOS 5.0 for MS-DOS Kermit
Keywords: MS-DOS Kermit and DOS 5.0
Keywords: National Keyboards, MS-DOS Kermit and National Keyboards
Keywords: MS-DOS 5.0, "Keyboards, National"
Xref: DOS 5.0, See MS-DOS 5.0

In previous versions of DOS the foreign keyboard program KEYB caused
trouble.  Kermit could not receive all characters if the keyboard was used
at the same time.  But in MS DOS 5.00 the bug does not exist!  (By the way,
I don't have extended memomy, so I do not use the new memory managament
capabilities of DOS 5.)

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

Date: Sat, 24 Aug 1991 19:11:20 GMT
>From: [e-mail] (Mikko Leino)
Subject: MS-DOS Kermit Keyboard Problems
Keywords: National Keyboards, MS-DOS Kermit and National Keyboards
Keywords: "Keyboards, National"

I have 2 problems here:

1)  How can I put a '|' -character into a "set key"-definition?

    ex.     set key \2323 get file.txt "| less"
                                       ^^^
    the above example results in a "v"-character instead of "|".

[Ed. - Such a SET KEY command works on US keyboards, so this is probably an
artifact of your Finnish keyboard or driver.  Instead of using a literal
vertical-bar character, insert its character code \124.  If that doesn't
work, you might also have to give the command SET TRANSLATION KEY OFF.]

2) Is it possible to make Kermit go to command line from interactive mode?
   ie. if you enter the command "connect" you enter into the interactive
   mode, but it seems that you cannot return.

[Ed. - The normal advice is: "Type Ctrl-] followed by the letter C to return
to the prompt".  But with certain national keyboards or drivers, it is
physically impossible to type the Ctrl-] combination, however there is
usually some other key combination that generates the same code.  Ctrl-],
Kermit's normal escape character, is ASCII code 29.  On the German keyboard,
for example, this may be entered by typing Ctrl-+ (hold down the Ctrl key,
marked "Strg" on the German keyboard) and press the plus (+) key.  On IBM PCs
and compatibles, you can also escape back by holding down the Alt key and
pressing the lowercase letter 'x'.]

Mikko Leino
[e-mail]

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

Date: Sun, 1 Sep 91 19:33:12 +0200
>From: oren alex <[e-mail]>
Subject: MS-DOS Kermit and Hebrew?
Keywords: Hebrew, MS-DOS Kermit and Hebrew

Is there a way to use Hebrew characters (8-bit) in Kermit's VT emulation?
I tried the translation table feature - no go.

[Ed. - Yes, it can be done.  First, your PC must have a Hebrew code page
loaded (CP862?).  Second, you must construct a file on your PC of the form:

  SET TERMINAL CHARACTER-SET TRANSPARENT
  SET TERMINAL BYTESIZE 8
  SET TRANSLATE INPUT \xxx \yyy
  SET TRANSLATE INPUT \xxx \yyy
  ...
  SET TRANSLATE INPUT ON
  SET TERMINAL DIRECTION RIGHT-TO-LEFT

In the SET TRANSLATE INPUT commands, \xxx is a host character code (for
example, in the ISO 8859-8 Latin/Hebrew Alphabet) and \yyy is a PC character
code to translate it into.  You need one of these commands for each Hebrew
character and other 8-bit character.

If you have a Hebrew keyboard, you can make a SET KEY command for each Hebrew
key to make it translate the PC key code into the corresponding host
character code before transmission.

This technique works for any code-page / terminal-character-set combination
that is not directly supported by MS-DOS Kermit, such as Cyrillic, Greek,
etc.  The only thing that is particular to Hebrew (and Arabic) about this
example is the command SET TERMINAL DIRECTION RIGHT-TO-LEFT.

Complete examples of how to do this for Cyrillic character sets can be found
in the *.ini files in the kermit/charsets directory on watsun (Internet only).

MS-DOS Kermit does not yet support Hebrew text file translation during
file transfer.]

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

Date: Mon, 9 Sep 91 15:10:12 PDT
>From: "Trevor Warwick" <[e-mail]>
Subject: MS-DOS Kermit and Horizontal Scrolling?
Keywords: 132 Columns, MS-DOS Kermit and 132 Columns, Horizontal Scrolling

My PC (a DEC VAXmate) doesn't support 132 column mode, and I guess that quite
a few older PCs, as well as newer laptop/portable PCs also only support the
simple video modes.

It would be very useful if MS-DOS Kermit had a way of scrolling the screen
from side to side.  So, when presented with a line that is longer than 80
characters, it would be nice if you could press a key and see the text that
has disappeared off the right hand edge of the screen, and be able to modify
it.  The model is of the terminal screen as a window which you move over the
text that is actually on the larger underlying surface.

[Ed. - This is actually a common request, and falls into the category of
"better support for 132 column mode" mentioned in the wish-list section of
the MS-DOS Kermit 3.11 announcement.  This would be a major undertaking, as
would the various other possible solutions for the EGA and VGA.  The
wish-list for MS-DOS Kermit is long, and many of the items on it are major
development projects.  At this point, the best way to get these features into
Kermit is to encourage your company to fund the Kermit development effort.]

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

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


From cmg  Thu Oct 24 12:13:53 1991
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 decodable: 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/hp3000.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 Protocol, 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
*************************



From cmg  Mon Nov 11 13:50:25 1991
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA10613; Mon, 11 Nov 91 13:50:25 EST
Date: Mon, 11 Nov 91 13:50:24 EST
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V14 #10
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Mon, 11 Nov 1991        Volume 14 : Number 10

Today's Topics:

            New Patch File for MS-DOS Kermit 3.11
                Compression Discussion
             QEMM Too Stealthy for Kermit
             MS-DOS Kermit 3.11 Printing Problem
        Double Echoing Problem with MS-DOS Kermit 3.11
              Novell Networks and Packet Drivers
             Using BOOTP with MS-DOS Kermit 3.11
          Kermit 3.11 TCP/IP versus 3Com 3C503 Cards
          MS-DOS Kermit on COM1 and COM2 in Windows
        MS-DOS Kermit vs Windows vs 9600 bps and Above

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: Wed, 6 Nov 91 22:00:53 EDT
>From: "Joe R. Doupnik" <[e-mail]>
Subject: New Patch File for MS-DOS Kermit 3.11
Keywords: MS-DOS Kermit 3.11 Patches
Keywords: Printers, TCP/IP, MS-DOS Kermit 3.11 and TCP/IP
Xref: Patch, See MS-DOS Kermit

Here is a new patch file for MS-DOS Kermit 3.11, dated 5 Nov 91.  The new
patches are:

Patch #6 solves the problem of using 8-bit CSI vs 7-bit ESC [ in the
host command to end transparent printing, reported by Leslie Foster, and it
cures a bug in reporting the status of devices such as the printer and cursor
position.

Patch #7 solves a problem that prevented file transfer from working on SET
PORT TCP/IP connections when parity was set to even or mark.

[Ed. - Thanks, Joe!  Readers, see below for Leslie Foster's message.  The new
patch file is in kermit/a/mskermit.pch on watsun and is available as
MSKERMIT.PCH from KERMSRV at CUVMA on BITNET/EARN.]

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

Date: Thu, 7 Nov 1991 10:27:55 EST
>From: Frank da Cruz <[e-mail]>
Subject: Compression Discussion
Keywords: Compression

Those interested in following the discussion on adding compression to the
Kermit file transfer protocol can refer to the e-mail archive in
kermit/e/compress.txt on watsun, COMPRESS.TXT on KERMSRV@CUVMA (presently
about 75K).  If you know something about the subject, feel free to chime in
(send e-mail directly to me).  If traffic warrants, a special-purpose
unmoderated discussion group can be set up.  I'm still looking to pointers on
detailed analyses.

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

Date: Mon, 28 Oct 1991 14:48 MDT
>From: Joe Doupnik <[e-mail]>
Subject: QEMM Too Stealthy for Kermit
Keywords: QEMM, 132 Columns
Keywords: MS-DOS Kermit and QEMM, MS-DOS Kermit and 132 Columns

This weekend I discovered that letting the QEMM v6 Stealth (ST:M)
optimization map away my VGA board's BIOS I also removed access to the same
by MS-DOS Kermit.  Kermit looks for a signature of a video board's Bios when
asked to change from 80 to 132 column mode, and the common signatures are
text strings in the Bios.  Alas, Stealth swiped the BIOS so no text strings
were visible.  Int 10h calls work fine, as expected, but that's not what
Kermit needs in this case.  So, before sending in a "broken" message on
Kermit let the video BIOS be visible and see if 132 column mode reappears.

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

Date: Fri, 18 Oct 91 16:46 -0300
>From: Leslie Foster <[e-mail]>
Subject: MS-DOS Kermit 3.11 Printing Problem
Keywords: Printers, MS-DOS Kermit and Printers

We recently installed a copy of Kermit 3.11 to emulate a VT220 terminal in a
GEAC library system.  We have been using version 3.01, but looked forward to
version 3.11 so we could display diacritics better.  However, we are now
having a problem printing from the host to the printer attached to the PC,
that we did not have in version 3.01.  In both cases, the options used are:

  Display: Regular, 8-bit
  Parity none

We have also installed a print spooler on the PC (20k).  When files are
sent for printing in version 3.01, the "PRN" flashes on the status line
until the file is collected in the spooler, and when finished, the terminal
returns to normal, and the printing is done correctly.

In version 3.11, this does not happen -- the PRN in the status line stays
on, and the terminal must be reset with ALT=.  In the debug mode, we can
see the characters required for printing being sent (ESC [ 5 i at the
beginning and ESC [ 4 i at the end).  These appear in the SET DEBUG SESSION
display as follows:

 ~^[5iTEST^M^J^L^@~^[4i

(with TEST being the line printed.)  It seems as if 3.11 is not interpreting
the 8 bit control characters for printing, while 3.01 could handle it.  Also,
after receiving the 8-bit "stop printing" control sequence, the terminal
emulator begins to behave strangely, displaying control characters as
graphics.

Leslie Foster, System Manager

[Ed. - Cured by Patch #6, see above.]

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

Date: Fri, 1 Nov 91 14:12 MST
>From: Ted McGrath <[e-mail]>
Subject: Double Echoing Problem with MS-DOS Kermit 3.11
Keywords: MS-DOS Kermit 3.11

I have just installed MS-KERMIT 3.11, and I have noticed the following problem.

1. I start kermit, use the 'vms' macro that was provided in the kermit
distribution, set my port to tcp/ip, set the other tcp/ip parameters,
and connect to our VAX 9000.  I get the username prompt, log in, and
everything seems to work just fine.

2.  After a while, I get tired of the reverse video stripe on the
bottom of my screen, so I push Crl-], then M to toggle the mode line
off.  The mode line goes away, but now everything I type is doubled
on the screen.  Ie- typing 'dir' produces 'ddiirr'.

3.  I push Alt-X, then show communications, and see that I am still set
at Duplex: full.  My display setting is VT320, Regular, 8-bit, with
terminal controls set to 7-bit.

4.  I reconnect to my VAX session with the 'CONNECT' command, and now
everything is back to normal.  I can toggle the mode line off, and on, and
off, but still my display is as it should be.  The problem does not seem
to re-appear until I log off, exit kermit, and then start it up again.

5.  I am running a PC with DOS 3.3, using the packet driver for the 3c503
card.  I also load IPX, and this copy of Kermit is coming off of a 3.10
Novell file server.  I have tried to duplicate this problem while
communicating to the VAX with TES, but it does not seem to appear then.

I would be happy to receive any solutions to this small, but vexing,
problem.  I have tried to give the critical information about my set-up,
if more information is helpful please let me know.

Ted McGrath     [e-mail]

[Ed. - This problem is cured by Patch #2 in the patch file mentioned above.]

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

Date: 2 Nov 1991 15:27:00 EST
>From: Christine M. Gianone <[e-mail]>
Subject: Novell Networks and Packet Drivers
Keywords: Novell Networks, Packet Drivers, TCP/IP
Keywords: MS-DOS Kermit 3.11 and TCP/IP

QUESTION: "How can I use MS-DOS Kermit's TCP/IP support and a Novell Network
at the same time?"

ANSWER: MS-DOS Kermit's TCP/IP support works only in conjunction with a
packet driver (see Joe Doupnik's article "Kermit, TCP/IP, Packet Drivers,
and the Future" in Info-Kermit V14 #5).  To use Kermit, or any other TCP/IP
application, and your Novell services at the same -- for example, to be able
to transfer a file between your Novell file server disk and an IP host
computer -- your Novell network must be configured to use a packet driver.

Novell does not provide instructions for how to do this, so it won't do any
good to look in your Novell manuals.  One commonly used method is provided
by a package of Novell shell drivers from Brigham Young University (BYU) in
Utah, USA.  These drivers can be obtained via anonymous FTP (password guest)
from dcsprod.byu.edu (128.187.7.3).  Use binary mode.  The drivers are found
in the novell subdirectory in a self-extracting archive file called
novell.exe; they support NetWare versions 2.1 and higher.  Transfer this
file (again in binary mode) to your PC and run it.  This will extract the
component files, including a READ.ME file that gives instructions for
configuring your Novell IPX driver to use a packet driver.

For convenience, the novell.exe file is also available via anonymous ftp
from watsun.cc.columbia.edu as packet-drivers/novell.exe (binary mode).

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

Date: Wed, 30 Oct 91 13:50:11 EST
>From: Ken Brown - Computer Services <[e-mail]>
Subject: Using BOOTP with MS-DOS Kermit 3.11
Keywords: BOOTP, MS-DOS Kermit 3.11 and BOOTP, Novell Networks

We are looking at making BOOTP service available for our academic users.  I
see that managing IP numbers could be a problem but that Kermit can use BOOTP
to set IP numbers.  We'd like to "idiot-proof" this as much as is possible.
Questions...

Where can I obtain BOOTP, its documentation, etc?

[Ed. - The BOOTP protocol is detailed in RFCs 951 and 1048.  A UNIX version
of BOOTP is available via anonymous ftp (binary mode), from Carnegie-Mellon
University, LANCASTER.ANDREW.CMU.EDU [128.2.13.21], pub/bootp.2.0.tar.  A
VAX/VMS version comes with TGV MultiNet 3.0.  Reportedly, a BOOTP server is
available for DOS, but we have not located it yet.  Anyone?  In a pinch, it
should be possible to adapt the CMU BOOTP server for DOS via minor (?) edits
and then link it with the Waterloo TCP (WATTCP) kernel.  And for Novell
networks whose only link to the IP world is through the Novell server, Novell
is preparing to release (at least in beta-test form) a BOOTP-forwarder NLM
for NetWare 3.11 servers, BOOTPFWD.NLM).  Watch CompuServe NetWire or your
favorite Novell newsgroup or mailing list for further information.]

Can BOOTP restrict access in some fashion?

[Ed. - Yes, by hardware address.  The BOOTP server sees the requestor's
hardware address in the BOOTP request packet and uses this to find the
associated IP address and send it back to the requestor.]

What happens if two systems have the same IP address?

[Ed. - The same thing that happens to your mail if your house has the same
street address as another house down the block.  You have to control IP
numbers centrally.  The BOOTP database is a good way to do this.]

How do others handle IP numbers when users can set their own in MSKERMIT.INI?

[Ed. - Administratively.  The network manager hands out IP numbers, and has
to trust users to use them properly.  Of course, this never works.  User A
gives User B her Kermit diskette, complete with MSKERMIT.INI file containing
a SET TCP/IP ADDRESS command, and then as soon as both of them try to use
Kermit TCP/IP connections at the same time, only one of them works.  The same
thing can happen with NCSA Telnet or any other DOS-based TCP/IP software.
That's why BOOTP service is a better approach for PCs: One network
configuration fits all.]

[Ed. - P.S. We still don't know for sure whether BOOTP service can be made
to work through a gateway.  Has anyone out there got this to work?]

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

Date: 22-OCT-1991 12:26:04.20
>From: "Patrick Eitner" <[e-mail]>
Subject: Kermit 3.11 TCP/IP versus 3Com 3C503 Cards
Keywords: Packet Drivers, 3Com 3C503, MS-DOS Kermit 3.11 and Packet Drivers

Hint for 3Com 3C503 users: When installing the packet driver for 3Com 3C503
cards, one has to pay attention that the memory on the card is *not*
disabled.  It was in my case, and the 3C503 packet-driver would not complain.
Since DEC PATHWORKS (and probably other networks) do not require the memory
enabled on the card, the default is disabled.  Maybe this fact should be
included in your BUGS&BEWARE file.

[Ed. - Thanks for the report.  As you suggest, a note about this has been
added to the "beware" file, kermit/a/mskerm.bwr on watsun, MSKERM.BWR on
KERMSRV.]

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

Date: Wed, 23 Oct 91 13:55:06 EST
>From: Dennis Perry <[e-mail]>
Subject: MS-DOS Kermit on COM1 and COM2 in Windows
Keywords: MS-DOS Kermit and Windows 3.0, Windows 3.0

I am trying to get two copies of MS-DOS Kermit 3.11 running under Windows.
I have an early version of Windows 3.0 so perhaps it has problems.

However, I've created two copies of the KERMIT.PIF file, one called NCR.PIF
and the other MOTOROLA.PIF.  I have two COM ports on my 386DX and a serial
cable to each system.

When the NCR.PIF file runs it goes to C:\KERMIT2 and runs MS-DOS Kermit 3.11
with 'set port 2'.  When I do a "show comm" it tells me that I'm using COM2
with address \x2F8, IRQ3.  MOTOROLA.PIF has 'set port 1' and reports COM1 in
use with address \x3F8, IRQ4.

When I start NCR.PIF and then start MOTOROLA.PIF, Windows says both
applications want to access COM1 - sometimes MOTOROLA.PIF does find COM1 and
tries to use the BIOS.

Have you heard of this problem before?  I'm using DOS 4.01 so perhaps there
is a problem here too?

[From jrd - 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 (port then IRQ).  This will make Kermit
bypass the test and leave COM1 material alone.  The problem here is how
people refer to COM2 as such: the second of two ports (that's what the BIOS
does) or the \x2f8 address (what most people do) or even what used to be
COM2 before they removed the COM1 device (happens often enough).]

Dennis Perry
Department of the Premier and Cabinet  Internet: [e-mail]
1 Treasury Place                       Voice:     Int'l 613 651 5028
MELBOURNE  VIC  3002                   Facsimile: Int'l 613 651 5201

P.S. I do have the WP30.INI file which is how I first discovered MS-DOS Kermit.
Did you know that WordPerfect Corp ships this file with WordPerfect 5.0 for
UNIX - that's how good they think it is.

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

Date: 25-Oct-1991 11:28am EDT
>From: Jeffrey E Altman <[e-mail]>
Subject: MS-DOS Kermit vs Windows vs 9600 bps and Above
Keywords: MS-DOS Kermit and Windows 3.0, Windows 3.0

The real problem with running above 9600 is that Windows 3.0 provides DOS
Applications with virtual services only.  In other words, Windows is
capturing the Serial I/O data and then sending it to MS-DOS Kermit when
MS-DOS Kermit is next run.  However, on slower machines (386sx on down) with
a 8250 or 16450 UART, Windows is unable to keep up with all of the Serial
Interrupts at 9600 or above.  (The actual speed that may be used is affected
by the PIF settings, SYSTEM.INI settings, and number of applications
running.)

In order to resolve this problem you need two things.  First, a 16550A UART
which supports a 16 byte FIFO buffer on the chip.  The FIFO cuts the number of
Serial Interrupts down to one every 16 bytes (during continuous high speed
transmissions) instead of one every byte received.  The second thing is a
replacement communications driver for Windows that supports the 16550A FIFO.
(It is rumored that Windows 3.1 will contain 16550A FIFO support.)

A company based in California called Bio Engineering Research Labs makes a
product called TurboComm which is a replacement Windows communication driver.
This allows much higher speed communication.  It also provides true access to
Com3 and Com4 while under windows.

Unfortunately, I do not remember the phone number or address of Bio Engineering
Research Labs.  I will try to forward it.  The author does read the
WINADV/Communications forum on Compuserve.

The other method is to purchase a Hayes ESP board which provides instead of a
16byte FIFO buffer, a 1K byte FIFO buffer.  It comes with drivers for Windows
3.0 and OS/2 1.x.

Jeffrey E Altman
Facilities Management Consultant
East Campus Physical Plant
State University of New York at Stony Brook
Stony Brook, NY 11794-8039

[From jrd - Jeffrey seems to be on target regarding the way Windows 3.0
handles the serial port.  A 16550A UART chip can help if the software
requests it.  MS-DOS Kermit exploits the chip (FIFO buffer highwater set to
8 characters to allow more arrivals while servicing) but it needs contact
with the real hardware to do so.  A disappointing factor in today's market
of cheaper and cheaper boards is finding a serial board with a socketed
UART.  Most of the serial port boards have UARTs implemented on some kind of
VLSI chip of unknown parentage.  So I think we are stuck with what we can
get and hope that Microsoft can improve their serial port interrupt routine
code.  Personally I've given up hope of "speed" when using Windows (even on
my 386 machine).  It's nice to know that there are alternatives, so thanks
Jeffrey.]

[Ed. - In response to the many people who were wondering how Gene (E.W.)
Carson managed to run Kermit in a Window at 19200 bps on a PS/2-55SX, as
reported in Info-Kermit V14 #3...  It turns out that Kermit wasn't actually
running at 19200 after all.  Although Gene's MSKERMIT.INI file set Kermit's
port speed to 19200 bps, and Kermit displayed it as 19200, the underlying
Windows setting for the port was 9600 bps and, as Jeffrey points out, the
Windows setting takes precedence; Kermit was only seeing the "virtual port".
After making this discovery, E.W. reports that he changed the port speed in
Windows to 19200 and saw the same communication problems as everyone else.]

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

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



From cmg  Fri Dec 13 12:12:34 1991
Return-Path: <cmg>
Received: by watsun.cc.columbia.edu (5.59/FCB)
    id AA12742; Fri, 13 Dec 91 12:12:34 EST
Date: Fri, 13 Dec 91 12:12:33 EST
From: Christine M Gianone <[e-mail]>
To: Info-Kermit
Subject: Info-Kermit Digest V14 #11
Reply-To: [e-mail]
Queries-To: [e-mail]
Errors-To: [e-mail]
Message-Id: <[e-mail]>

Info-Kermit Digest         Fri, 13 Fri 1991        Volume 14 : Number 11

Today's Topics:

           New Mac Kermit Prerelease Available for Testing
          Test Release 4.2.2 of Kermit-370 for MUSIC
               Latest MS-DOS Kermit Patch File
             Indexed Info-Kermit Digests
            TN3270 Support for MS-DOS Kermit 3.11?
         Cancelling Name Lookup in MS-DOS Kermit 3.11
         Saving MS-DOS Kermit Screen Output to a File
               BOOTP for DOS and/or LAN Manager
              Kermit Dialing Script for Telebits
            Two Kermit Macros Proving Popular Here


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: 11 Dec 1991 12:48:00 EST
>From: Christine M. Gianone <[e-mail]>
Subject: New Mac Kermit Prerelease Available for Testing
Keywords: Macintosh Kermit

There have been thousands of complaints and queries about Macintosh Kermit
in recent months.  It is simply not possible to answer them.  Instead, I am
making this announcement.

Development of a new release of Mac Kermit is underway.  It is FAR FROM
COMPLETE.  It is proceeding in stages, because different volunteers at
different sites in different countries are working on it in their spare
time, so the schedule is not firm.

Stage 1 of the development effort has produced a version that might be of
use to some of you until we release a more complete version.  The result is
version 0.99(91)+UTexas(9)+C-Kermit 5A(172).  There is NO DOCUMENTATION
beyond what you'll find in this message.  All the standard disclaimers
apply: USE IT AT YOUR OWN RISK, etc.  It seems to work under System 7 and on
newer Mac models, except in a couple known cases, the most notable being
when "Suitcase" is loaded.  Its behavior on older Mac models (68000 based
and/or small memory and/or Systems prior to 6.0) is unknown.

Here is a brief list of the major new features of this "non-release".  All
are subject to change.

 . Integration with a recent edit of C-Kermit 5A.  The main feature is
   sliding window packet protocol for increased file transfer efficiency,
   plus the ability to use very long packets (up to about 9000 bytes).
   There's also a new "file transfer thermometer".

 . An interactive command parser (the same as in C-Kermit 5A), in addition
   to the customary menus, plus the ability to execute commands from a
   command file.  Thus Mac Kermit now has a script programming language,
   a DIAL command, etc.  The script programming language is very similar to
   MS-DOS Kermit's.

 . A "Window" menu to let you switch among the terminal emulation, command
   parser, general text editing, and server response windows, with cutting
   and pasting between windows, etc.  Command files can be created in text
   editing windows and executed, saved, etc.

 . Redesigned menus (the design is nowhere near complete, and definitely
   will change).

 . Translation between the Mac Quickdraw character set and ISO 8859-1
   Latin Alphabet 1 during file transfer (presently available only via
   SET commands in the Command Window).

Many of the new features might be buggy or incompletely implemented.  The
basic functionality -- text, binary, and macbinary file transfers, VT320
emulation, etc -- seem to be fairly solid.

This NON-RELEASE version is available on the Internet as:

  kermit/test/ckmut9.hqx on watsun.cc.columbia.edu via anonymous ftp (text)

and on BITNET/EARN as:

  T:CKMUT9.HQX from [e-mail]

It's about 400K long.  Use BinHex version 4.0 to decode the HQX file into
the Macintosh Kermit application.

Please send reports, suggestions, and (most important) offers to help out
with the development to:

  Frank da Cruz
  [e-mail]

A few points about this program, to forestall hundreds of e-mail messages:

1. The VT100 font is usable only in 9-point size.  Select Courier from
   Mac Kermit's new Font menu if you want to use a larger size.

2. The VT100 font's code points for accented characters are incompatible
   with other Mac fonts, like Courier.  VT100 line- and box-drawing
   characters don't work in any but the VT100 font.

3. Volunteers are needed to work on the VT100 font, including design,
   rearrangement of the code points, externalization in a variety of point
   sizes, etc, so it is visible to keycaps, etc etc.  Please contact Frank
   if you're interested in taking on this task.

4. Key mapping has not been tackled in this version.  Improvements will
   come, hopefully, in a forthcoming test release.

5. Some improvements have been made in the area of printing, but much more
   remains to be done.

Remember, this announcement is being made only to tide over those who simply
cannot find a version of Mac Kermit that runs satisfactorily on their
system.  Feel free to send in bug reports, but don't expect them to be
answered.  They will be collected, collated, and acted upon during the
development process.

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

Date: Mon, 1991 Dec 9   16:06 EST
>From: "John F. Chandler"   <[e-mail]>
Subject: Test Release 4.2.2 of Kermit-370 for MUSIC
Keywords: IBM 370 Kermit, MUSIC Kermit

Kermit-370 version 4.2.2 is coming soon to MUSIC.  A trial release has
been undergoing tests for two months, but only at one site.  I have sent
the new updates to Columbia so that they can be made generally available
(as T:IKMKER.UPD on KERMSRV and as ~kermit/test/ikmker.upd on watsun).
As soon as enough reports come in to verify that there are no problems
with the test version, it will be released officially.  The new BWR file
has already been released (as IKMKER.BWR and as ~kermit/b/ikmker.bwr).
In most respects, the new MUSIC variant is just an adaptation of the
updates in the other three variants (CICS, CMS, and TSO), but there is
one notable change: Kermit-MUSIC 4.2.2 supports automatic detection of
the terminal controller type among the various full-screen flavors
(SERIES1, GRAPHICS, AEA).  This results in Kermit becoming incompatible
with MUSIC/SP 1.2 and requiring at least MUSIC/SP 2.2, but there is a
simple optional update to restore 1.2 compatibility.  See the notes in
ikmker.bwr dated 89/2/27 and 91/8/19 for more details.

Please send any test reports (whether good or bad) to PEPMNT@CFAAMP (on
BITNET) or to [e-mail] (on the Internet).

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

Date: Mon, 18 Nov 91 22:15:03 EST
>From: "Joe R. Doupnik" <[e-mail]>
Subject: Latest MS-DOS Kermit Patch File
Keywords: MS-DOS Kermit Patches

Here is today's edition of the MS-DOS Kermit 3.11 Patch news.  It has two
patches: number 8 corrects a coding error which mistakenly adds 9 to the
code for a DEC User Definable Key definition.  Number 9 is a workaround for
a bug in Interconnections Inc's TES program v2.2/R8, the latest available.
The bug would cause Kermit to crash at the start of a connection,
necessitating reboot of the PC.

[Ed. - Thanks, Joe!  The new patch file is in kermit/a/mskermit.pch on
watsun for anonymous ftp on the Internet, and also available from KERMSRV
at CUVMA on BITNET / EARN as MSKERMIT.PCH.]

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

Date: 18 Nov 1991 15:27:00 EST
>From: Christine M. Gianone <[e-mail]>
Subject: Indexed Info-Kermit Digests

Just a reminder that paginated, indexed versions of the Info-Kermit Digest
are available as imail.yyx, where yy is the year, and x is "a" or "b".  For
example, the current Digest volume (14) is in kermit/e/imail.91b on watsun
(Internet) or IMAIL.91B (KERMSRV@CUVMA on BITNET/EARN).

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

Date: 12 Nov 1991 09:19:29 EST
>From: <[e-mail]>
Subject: TN3270 Support for MS-DOS Kermit 3.11?
Keywords: 3270 Emulation, TN3270

We're running a couple of versions of tcp/ip for pc's, and we'd like to
replace the telnet/ftp stuff with Kermit.  There are a lot of reasons for
doing this: our users are familiar with Kermit, they can use it from home,
support for printing, etc.  With our IBM mainframe, we do need tn3270
support.  Are there any plans to include this support in Kermit?  If anyone
is working on it, we'd be happy to be guinea pigs.

[From jrd - Tom, I'm glad you like the current Telnet support in Kermit.  We
knew that once this area was opened that folks would want the whole range of
TCP/IP based programs.  Alas, we don't have the resources to do all that,
and mentioned the list and reasons in Info-Kermit V14 #5.  TN3270 is a
fairly large amount of effort to accomplish.  We would certainly consider it
if a generous sponsor were willing to contribute enough funds to hire some
persons to assist us.  In the meanwhile users can employ Telnet with the IBM
mainframe in line mode, or go through 3270 protocol converters (perhaps
connected "milking-machine" fashion to TCP/IP terminal servers).]

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

Date: Tue, 12 Nov 91 14:55:07 PST
>From: (Richard Stanton) <[e-mail]>
Subject: Cancelling Name Lookup in MS-DOS Kermit 3.11
Keywords: TCP/IP, MS-DOS Kermit 3.11 and TCP/IP

Is there any way of quickly aborting a failed or failing name lookup in MSK
3.11? I often sit there for ages while it tries to access a name server and
find the address for a computer name, and it's usually faster to reboot than
to wait for it to come back. (This is using TCP/IP) Thanks.

[From jrd - During the Domain Name Service query matters are entirely in the
hands of the TCP/IP code and there is no sampling of the keyboard or similar
interactive items.  This was done to greatly simplify the design of the new
Telnet material.  Some probes can take some time.  So, for the current
release one should wait out the process and/or remove the difficult name
server from the list.]

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

Date: Tue, 12 Nov 91 08:27:04 IST
>From: Ran Cheremsh <[e-mail]>
Subject: Saving MS-DOS Kermit Screen Output to a File
Keywords: MS-DOS Kermit and Saving Screens

I'm trying to transfer information from a database to my PC.  Whenever I log
information, I endup with a file full with escape characters.  The file is
almost impossible to read.  I can, on the other hand, save the screen by
using the Alt-H, F sequence.  The problem is, that this method requires a
page by page instruction.  Is there a way to save a session using a
quasi-Alt-H, F technique?

[Ed. - Using MS-DOS Kermit 3.11, try this:

  MS-Kermit>SET PRINTER XXX.LOG
  MS-Kermit>CONNECT

  Press Ctrl-PrintScreen

  When you want to stop recording your session, press Ctrl-PrintScreen
  again.

The file XXX.LOG (call it whatever you like) will contain a session log
that does not contain escape sequences.  This technique is documented on
pages 82-84 of "Using MS-DOS Kermit", second edition.]

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

Date: Wed, 13 Nov 91 11:03:04 +0100
>From: (Lars W. Holm) fnslh <[e-mail]>
Subject: BOOTP for DOS and/or LAN Manager
Keywords: MS-DOS Kermit 3.11 and BOOTP, BOOTP

Ref. Info-Kermit Digest vol.14, no.10:

I hope you will forward any information on BOOTP available for MS-DOS
machines to the Info-Kermit list. Also if any information on BOOTP service
on LAN Manager servers is available, it would be very much appreciated.

 . Lars W. Holm                            [e-mail] .
 . Norwegian Social Science Data Services [e-mail] .
 . Hans Holmboesgate 22                      Phone [phone] .
 . N-5007 Bergen, Norway                     Fax   [phone] .

[Ed. - Moore <[e-mail]> reports that "According to the
CUTCP distribution group, the program lpd located in /pub/lpd at
tacky.cs.olemiss.edu [130.74.96.13] can perform BOOTP functions."  This is
primarily a print spooler for PCs equivalent to UNIX lpd, but reportedly the
BOOTP service that is included is quite flexible.]

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

Date: 21 Aug 91 15:19:51 GMT
>From: [e-mail] (Al Porter)
Subject: Kermit Dialing Script for Telebits
Keywords: MS-DOS Kermit, Modems, Telebit

I'm using MS-DOS Kermit on a PC.  When I try to do a script to call up a
site:

  def remote dial 123-4567,input 60 CONNECT,output \13\13\13,connect

as soon as the connection begins, Kermit stops and says:

  Error: No dialtone or no answer

(I have defined dial via the default definition, and using hayes.tak)

How can I modify hayes.tak?  Does someone have a telebit.tak?

Thanks for any help!!!

[Ed. - The problem is that Telebit modems output the message RRING each time
the called phone rings.  Real Hayes modems don't do this.  The new version of
MSIHAY.SCR that comes with MS-DOS Kermit 3.11 allows for this message, and
has been tested successfully on Telebits.  Also, it's not a good idea to
give a macro the same name as a built-in command, like REMOTE.]

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

Date: Sun, 3 Nov 91 11:52 PST
>From: Professor TJ Olney <[e-mail]>
Subject: Two Kermit Macros Proving Popular Here
Keywords: MS-DOS Kermit Macros, File Transfer, TERMINALR/S Macros

These simple macros are proving quite popular to communications novices here.

   TJ Olney

;These two macros rely on prior definition of FATAL
;a macro to send a file to the remote machine automatically
; no manual invocation of the remote kermit
;non machine-specific by having separate lines for kermit and server
;it can deal with either ckermit or vmskermit or mskermit

def UPLOAD if < argc 2 fatal {Upload what local file?},-
 output kermit\13, -
 input 5 kermit,pause,output server\13,in 5  local machine,pause,send \%1,-
 fin, in 5 >,output exit\13,output ! \%1 uploaded\13,def \%1,c

;a macro to grab a file from the remote machine automatically
def DOWNLOAD if < argc 2 fatal {Download what remote file?},-
 output kermit\13,-
 in 5 kermit,pause,output server\13,in 5 local machine,pause,get \%1,fi,-
 in 5 >, output exit\13,def \%1

[Ed. - Thanks!  These are indeed handy macros -- they let the user control
file transfers exclusively from the MS-DOS Kermit end, without having to
start Kermit on the remote end, or to give the remote Kermit any commands.
However, they require the user to escape back first, and they rely on the
form of the remote Kermit's name, prompt, and messages.  There is a better
technique that can be driven entirely from the remote Kermit (or from host
command procedures that invoke the remote Kermit).  The trick is to define
MS-DOS Kermit's TERMINALS and TERMINALR macros appropriately, and have the
host send the escape sequences that invoke them.  This technique is
described on pages 180-181 of the second edition of "Using MS-DOS Kermit".]

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

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