SY.FDC@CU20B.COLUMBIA.EDU (Frank da Cruz) (09/22/87)
Info-Kermit Digest Tue, 22 Sep 1987 Volume 6 : Number 22
Departments:
ANNOUNCEMENTS -
Some LISTSERVers Allowing Info-Kermit Subscriptions (2 messages)
MS-DOS KERMIT -
New .BOO File for Intel iRMX Version of MS-Kermit
Clear Keys on MS-Kermit 2.30?
MS-DOS Kermit 2.29C Maximum Packet Size
MS-DOS Kermit 2.29C Problem with IRMA Board
MS-DOS Kermit 2.29C Send-As Name?
MS-DOS Kermit 2.29C Color and Intensity
Losing Interrupts on IBM PC and PS Systems
VAX/VMS KERMIT -
Kermit-32 Escape Sequence and VT330 Terminal
C-Kermit 4E on VAX/VMS Bug Report
MISCELLANY -
Native Media for Commodore-64 Kermit
Kermit and the IBM 7171
Kermit for Tandy 6000?
8th-Nit Prefix Bug in Kermit For TRS80 Model IV (M4)
----------------------------------------------------------------------
Date: Sat, 19 Sep 87 15:22:16 FIN
From: The Head of the Post Office <POSTMAST@FINHUTC>
Subject: Some LISTSERVers Allowing Info-Kermit Subscriptions
Keywords: Info-Kermit Digest, BITNET, LISTSERV
There already is a peered LISTSERV-list called I-KERMIT that distributes
Info-Kermit Digest. (Here it is called IKD for some historical reason...)
This is part of our configuration file for this list.
* Peers= I-KERMIT@UGA,I-KERMIT@MARIST,I-KERMIT@TCSVM
* Peers= I-KERMIT@CLVM,I-KERMIT@EB0UB011,I-KERMIT@RUTVM1
* Peers= I-KERMIT@UBVM,I-KERMIT@DEARN,I-KERMIT@VTVM2,I-KERMIT@BNANDP11
*
* Owner= HAROLD@UGA (Harold Pritchett)
I think that all the BITNET users could be (should have been ?) transferred
to this list.
Petri Autio
[Ed. - Thanks for the list, Petri! See next message for more information.]
------------------------------
Date: Tue, 22 Sep 87 11:57:19 EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Info-Kermit Digest Distribution by LISTSERV
Keywords: Info-Kermit Digest, BITNET, LISTSERV
So far, the following BITNET sites have indicated (perhaps indirectly) that
they maintain LISTSERVers capable of handling Info-Kermit Digest
subscriptions. Thanks to each of these sites for providing this service.
Node Country Name
BNANDP11 Belgium Facultes Univ Notre Dame de la Paix, Namur
CANADA01 Canada University of Guelph, Ontario
FINHUTC Finland Helsinki U of Technology,
EB0UB011 Spain Univ Autonoma Barcelona
BROWNVM USA Brown University, Providence, RI
MARIST USA Marist College, Poughkeepsie, NY
RUTVM1 USA Rutgers University, New Brunswick, NJ
TCSVM USA Tulane U Computing Services, New Orleans, LA
UBVM USA SUNY Buffalo, NY
UGA USA U of Georgia
VTVM2 USA Virginia Polytech Institute, Blacksburg, VA
CLVM USA? Clarkson U ERC (where is it?)
DEARN West Germany Gesellschaft fuer Schwerionenforschung
Hopefully, we'll be adding CUVMA (Columbia University, NY, USA) to the list
very soon. Other BITNET/EARN/NETNORTH sites, especially in areas far from
the locations above, are encouraged to volunteer. Meanwhile, if you're a
BITNET subscriber, please, "TELL LISTSERV AT nearest-node SUB I-KERMIT
your-name". When you start getting the LISTSERV copy, send a message to
Info-Kermit-Request@CU20B and ask to be removed from our list. This way,
there should be no interruption in service when the WISCVM Internet/BITNET
mail gateway goes out of service on December 1.
We are also attempting to gradually remove WISCVM dependencies from our own
list. Last week we sent out a test message to all the BITNET sites on the
Info-Kermit mailing list to see which ones could accept mail directly from
CU20B. The results are still coming in, but those sites that seem to have
received the mail successfully have had their entries changed to bypass the
WISCVM gateway.
------------------------------
Date: Thu, 10 Sep 1987 08:57 PDT
From: JAFW801@CALSTATE.BITNET (Jack Bryans)
Subject: New .BOO File for Intel iRMX Version of MS-Kermit
Keywords: Intel, iRMX, RMX Kermit, MS-DOS Kermit
Here's the latest .BOO file for the Intel iRMX version of MS-DOS Kermit,
based on the current 2.29C MS-DOS Kermit development version. There's also
some acommpanying documentation.
[Ed. - Thanks, Jack! It has been put in KER:MSTRMX.BOO and .DOC and
MSTRMX * on CUVMA. Feedback solicited!]
------------------------------
Date: Thu, 17 Sep 1987 15:58 CDT
From: William Bruce Curtis <NU024414@NDSUVM1>
Subject: Clear Keys on MS-Kermit 2.30?
Keywords: MS-DOS Kermit
Is it possible to provide a replacement for the old CLEAR command which
cleared all the key definitions? When using mskermit to log on to several
different systems it is very convenient to be able to clear all the key
definitions without exiting from mskermit and restarting it. For example we
use a fairly long take file to customize the keyboard when logging on to CMS
but when logging on to UNIX a vanilla Heath-19 is preferred. Several users
here have complained about 2.29c's lack of a clear key command. I realize
that the clear command should clear the port as described in the book but
could we please get some command to clear all of the keys put back in before
2.30 is released?
[Ed. - Yes, 2.30 will contain a command SET KEY CLEAR.]
------------------------------
Date: Fri, 18 Sep 87 11:34:15 CDT
From: James Gregory <jgregory@ALMSA-1.ARPA>
Subject: MS-DOS Kermit 2.29C Maximum Packet Size
Keywords: MS-DOS Kermit
I'm in the process of putting the most recent 2.29C through its paces. When
the set send and receive packet commands are issued, the response indicates
there is a maximum value of 9024 bytes, however, the current implementation
only supports 1000 bytes. Just thought I'd bring this to your attention in
case it was an oversight. I realize that the 9024 byte limit is supported
by the protocol, however, it seemed you would want the response to be
specific to the current implementation.
[Ed. - Will be fixed in 2.30 to report the actual maximum size.]
------------------------------
Date: Fri, 18 Sep 87 11:19:45 MDT
From: John Shaver Modernization Office <steep-mo-m@HUACHUCA-EM.ARPA>
Subject: MS-DOS Kermit 2.29C Problem with IRMA Board
Keywords: MS-DOS Kermit, HP Vectra, IRMA Board
I have a Vectra, an HP AT Clone. I have sidekick and an IBM terminal emulator
called IRMA resident in RAM with 640K. I have about 450K left. The
significant difficulty came from 2.29C refusing to let me use COM2 as a port.
I have, am and continue to use Port 2 with 2.29.
[Ed. - From JRD: The serial port handling in 2.29C is much different from
previous releases. In particular, the port is tested before use. The
various levels which a user sees are messages such as "Port not available",
"This port uses the Bios", and nothing at all (which is best of all). The
first message is shown if the Bios work area in low memory indicates the
port was not found by the machine's boot code (COM1 is at 40:00H and COM2 is
at 40:02H, and normally hold 03f8H & 02f8H, respectively). The second
occurs if the port was found but the UART chip was not the kind which Kermit
can control (an 8250). Diagnosis then proceeds by noting the kind of
message, removing some add-in software, removing the IRMA board, and finally
calling for help (with additional system details).]
------------------------------
Date: 21 Sep 1987 23:41-CDT
From: SAC.SAC-LMR@E.ISI.EDU
Subject: MS-DOS Kermit 2.29C Send-As Name?
Keywords: MS-DOS Kermit
Thank you for improving Kermit. The changes have made a menu-driven
system for accessing the host much easier to write.
I have found 1 minor glitch so far - All caps must be used when specifying
the remote file name in the "SEND" command. If lower case is used, the file
created on the host has a name with ASCII char 22 preceding each letter.
I.e. using the name "test" as the remote file name will produce a file on
the host named "^Vt^Ve^Vs^Vt".
[Ed. - This is actually a documented feature. If it was done the other way,
you couldn't specify a lowercase name if you had to.]
------------------------------
Date: Mon, 21 Sep 87 16:21:41 CDT
From: James Gregory <jgregory@ALMSA-1.ARPA>
Subject: MS-DOS Kermit 2.29C Color and Intensity
Keywords: MS-DOS Kermit, Terminal Color, Terminal Intensity
Cross-Ref: Color, see Terminal Color
When I am using 2.29C as a terminal emulator with "set term color 1 10 37
44", the high intensity character display is behaving questionably. While
using "more" on a UNIX system (e.g.), the first page will display in high
intensity. The next and following pages will display in low intensity. If
I enter the escape sequence "^]c" followed by "connect", characters begin
displaying in high intensity again. I tested this behavior using the "vi"
editor, also. When the display went to low intensity, presumably because
the remote system sent the correct escape sequence to cause such behavior, I
escaped back to the local system, reconnected, and entered "^L" to redisplay
the current page. The page then displayed in high intensity. If the change
in attributes was the result of character sequences generated by the remote
system, I expected to see consistency. I assumed the editor was
retransmitting the same escape sequences.
This observation is not new to the current test version. I withheld
bringing it to your attention earlier. I thought this type of incident
would be so common that it would either be corrected or accounted for in the
info-kermit digest prior to release of 2.30.
Testing was done on an MS-DOS 3.1 Zenith Z-248 with an EGA.
[Ed. - From JRD: I know what you mean about the intensity bit. My Unix PC
does the same thing to me. It's 'ok' though when we realize the host is
explicitly sending a no-bold attribute command every now and then. Kermit
uses the screen attributes active when Connect begins and they might well be
bold white on blue and switches when the host so commands. The real dilemma
is PC color screens are unsatisfactory in 'normal' intensity whereas DEC
terminals are good that way. Also DEC terminals can control the background
intensity but PC's usually cannot. To provide a variation of intensity
required by the host applications software we are then stuck with normal
meaning rather dim. It's a pain which IBM needs to address. Does that help?]
------------------------------
Date: Mon, 07 Sep 87 09:43:06 ULG
From: Andre PIRARD <A-PIRARD%BLIULG12.BITNET@WISCVM.WISC.EDU>
Subject: Losing Interrupts on IBM PC and PS Systems
Keywords: MS-DOS Kermit, IBM PC, IBM PS/2
[Ed. - From a recent Info-IBMPC Digest.]
>... IBM, 3Comm and Microsoft have been pretty cavalier about losing
interrupts in the past. ... says Billy.
And the beat goes on. Here is a problem I reported to IBM:
>When a communication program drives an asynchronous adapter by interrupts
>and a national keyboard driver is used, typing while line input is being
>displayed produces screen garbage. Keyboard interrupts are an infrequent
>and long process and assigned higher priority (1) than frequent and short
>communication interrupts (3,4) (why?). Their drivers send the 8259 EOI
>just before IRET, as most regretfully do. Consequently, even if cpu
>interrupts are enabled, the 8259 will not request communication interrupts
>to the processor until the very end of keyboard interrupt processing,
>which, if excessive, causes communication line overrun. DOS 3.2 KEYBBE
>(on XT), for example, is near the limit, and causes occasional overrun at
>9600 baud.
>
>But 3.3 KEYB (on PS/2 30!) is far beyond and does it nearly for every
>keystroke. CTL-ALT-F1ing KEYB (to the original ROM presumably) removes
>the problem. Rotating 8259 priorities (OUTing C1H to 20H) solves the
>problem for KEYBBE, but not for KEYB (why?). But assigning the keyboard
>interrupt lowest priority also shuffles the other ones. In particular,
>the timer interrupts get the next to lowest. Is this practice advisable?
And some more comments for INFO-IBMPC:
What frightens me is that the problems are worse on 3.3 PS/2 30 than on a
plain XT or AT. I was expecting maturity from PS/2.
The priorities are as follows (0 highest):
0: timer ticks
1: keyboard
2:mouse (generally)
3,4: communication
5,6: disk and diskette
7: printer
Generally, BIOS and MSDOS as a whole are careful not to disable processor
interrupts too long unnecessarily, even during interrupt processing. There
could be occasional exceptions to this, but I never experienced any in
communication.
But with the host of available TSR programs hooking onto interrupt vectors,
the situation may change. If such a program acts as a front end, it cannot
decently enable interrupts without presuming what its followers do and need,
and it will necessarily perform before 8259 EOI anyway. For this reason,
such programs should act after the original sequence if possible, when
interrupts can be enabled for sure, except for another reason, the stack
growth nightmare. It is therefore important to write or choose such
programs carefully. The TSR programs problem is all the more acute as timer
and keyboard interrupts are the most favored for hooks.
[Ed. - From JRD: Columbia sent me a copy of your comments on interrupt
latency when national keyboard sets are employed. That explains a rash of
comments from PS/2 model 30 users concerning lost serial port characters.
Your comments are exactly on target concerning clearing the 8259 chip. If
you were to peek at the MS-Kermit/IBM serial port interrupt routine you
would see the 8259 being cleared as quickly as possible before doing the
reminder of the work, for this very reason. Interrupts are also enabled as
quickly as possible because I know the stack will not grow out of control.
Let's hope that Microsoft/IBM listen carefully. They are already being told
that OS/2 has severe interrupt latency problems when multitasking Real and
Protected mode windows together.]
------------------------------
Date: 18 Sep 87 8:38 -0600
From: Grant Delaney <delaney%wnre.aecl.cdn%ubc.csnet@RELAY.CS.NET>
Subject: Kermit-32 Escape Sequence and VT330 Terminal
Keywords: VAX/VMS Kermit, VT330
A note of caution the Kermit-32 escape sequence is also the terminal reset
and self test sequence for the new DEC VT330 terminal. The escape sequence
should therefore be changed before a connect if you want to get out again.
[Ed. - Kermit-32's default escape sequence is Ctrl-]C. C-Kermit's is
Ctrl-\C.]
------------------------------
Date: 17 Sep 87 12:23:00 MST
From: <darieb@sandia-2.arpa>
Subject: C-Kermit 4E on VAX/VMS Bug Report
Keywords: C-Kermit, VAX/VMS Kermit
I've just downloaded the newest XK* versions to VAX VMS 4.5. It compiled
without a hitch, using the XKVKER.COM. It even transferred a file OK.
However, there are a couple of problems.
I'm running an IBM PC/XT at 9600 Baud using the VTERM 4010 Version 2.0
software from Coefficient Systems Corporation, which supplies a pretty good
VT102 emulation. Connection is through COM1: to a Gandalf LDS120 line
driver, into a Gandalf (I think) port contender device, thence to a VAX
8600. No DECNET. The BLISS version of KERMIT works OK.
- The SHOW command produces a lot of unprintable characters in the
header lines of the table ("send" and "receive"), after which
several of the lines contain gibberish. After the SHOW, things go
back to normal (except see below)
- After many commands are executed, and the C-Kermit> prompt shows,
typing another command responds with "?invalid - xxx". Typing an
erase-line character (CTRL-U on VMS) before doing anything else
will erase 3 characters of the prompt, indicating that three characters
must have been received by VMS from the terminal(?) I can easily
get around this problem by habitually typing <CTRL-U>command...but who
wants to?
Is it possible that I need to SET TERMINAL to something different before
executing Kermit? Or are there indeed spurious characters being sent by
C-Kermit? At any rate, this version works OK, but the BLISS version is the
system standard here.
Declan A. Rieb, Division 2614 DARIEB@SANDIA-2.ARPA
Sandia National Laboratories (505) 844-6338
Albuquerque, NM 87185-5800
[Ed. - Can anybody help with this? I've tried the same thing on a VAX 780
with VMS 4.3, but can't make it happen. There seems to be a recurring theme
over past weeks -- all versions of VMS Kermit (Bliss, C, different releases)
seem to print various kinds of garbage when you give the SHOW or STATUS
commands under VMS 4.4 or later. What's going on???]
------------------------------
Date: Sat, 19 Sep 87 11:17:47 -0500
From: ray@j.cc.purdue.edu (Ray Moody)
Subject: Native Media for Commodore-64 Kermit
Keywords: Commodore-64 Kermit, Diskette Volunteers
>[Ed. - A popular request. Any volunteers? For that matter, are there any
>volunteers to distribute ANY versions of Kermit on native media for ANY
>systems that Columbia cannot provide?]
This probably is not worth posting, but if you are making a list of people who
can distribute Kermit on native media, we wish to be included.
[Ed. - Yes it is! We do keep such a list. It's AADISK.HLP, and we've added
you to it. I hope others will follow your example and volunteer with disks
and formats that Columbia cannot provide -- the many CP/M formats, 8-inch
diskettes, Xenix Kermit diskettes, SUN tape cartridges, etc etc.]
We will provide Commodore-64/Commodore-128 Kermit V2.0 on a 1541 disk.
(soon V2.1 and maybe Commodore plus-4 kermit.....) We ask $5.00 to cover
the costs of postage, handling, and the disk. We stress that Kermit is in
the public domain. The $5.00 is only so we can recover the costs of
postage, handling and the disk. We will be able to continue to provide this
service for the foreseeable future. Please send U.S. funds. We regret that
we will not be able to provide source code in this format because it will
not fit on a 1541 disk. Our mailing address is:
Dr. Evil Laboratories
P.O. Box 190
St. Paul, IN 47272
Ray Moody
ray@j.cc.purdue.edu
ihnp4!pur-ee!j.cc.purdue.edu!ray
moody@purccvm.BITNET
Kent Sullivan
ihnp4!pur-ee!corvair
------------------------------
Date: Mon, 21 Sep 87 17:10:43 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: Kermit and the IBM 7171
Keywords: IBM Mainframe Kermit, IBM Series/1, CMS Kermit, VTAM, XON/XOFF
Cross-Ref: 7171, see IBM Series/1
I once wrote a communication/ftp program that we have been using on the
Series/1 and 7171 for several years without much problem. For several
reasons too long to explain here, we decided to convert it to the Kermit
protocol. It now works beautifully with another micro Kermit or in IBM 370
TTY mode, but the 7171 is such that it causes nasty problems. I'll explain
them mainly on the IBM370 list, but I think some facts I learned from
experience with my former program can be of general interest to 7171 users.
1) The S/1 style protocol converters run in two modes: terminal emulation
and transparent mode. File transfer uses transparent mode. In this mode,
the host (370) outputs data (write phase), then switches to read phase to
get the reply. The 7171 always uses interrupt driven RS232 I/O to a 340
bytes input buffer (the S/1 uses a smaller buffer, but uses DMA in
transparent mode). This means that when using packet sizes larger than 340
bytes, XON/XOFF pacing protocol MUST be used. It implies that the micro
Kermit use it, but also that it not be disabled on the 7171 side. Failing
that, I/O that once looked OK on a lightly loaded 7171 may suddenly go wrong
when the load increases. And I have seen what go wrong means: a buffer
overflow may cause complete deadlock of the communication port and need a
DTR drop to recover it.
2) Considering that it is best to always use (or at least allow) XON/XOFF in
file transfer raises another problem. The 7171 will receive XON/XOFF as
pacing during write phase, but not during read phase. Moreover, XOFF is
defaulted as an end-of-input character. It may happen that timing problems
cause an XOFF sent by the external device during write phase to effectively
arrive during read phase and end it with null input. For this reason,
allowing XON/XOFF as pacing must be paired with disabling XOFF as an
end-of-packet character. That is the system programmer setting bit X'1000'
at DC00:0008 in the 7171 NVRAM.
3) The 7171 may end an inbound packet prematurely on certain types of
transmission errors I could not determine. This process looks like
auto-catalytic. Once started, chances are high the host is assaulted by an
awful lot of short packets it NACKs. It seems the reason is turning the
line to read phase in the middle of a character the external device
trustfully sends. Because a single error is multiplied, the 370 Kermit
retry count should be set as high as possible. On the other side, the
external device (micro) must expect a flood of NACKs in response to a single
packet. It is therefore essential to purge the input buffer as late as
possible, I do it just before sending the end-of-packet character.
Question: does any Kermit reply before the eop? If yes, it would be better
to purge before sending the checksum.
4) There is no provision in the 7171 to recover from a lost XON, nor in the
370 to timeout. To avoid deadlock, the micro must implement its own
recovery. At least XON should be sent to the 7171 after a timeout. I also
send "clear screen" to allow the host to recover from loosing fullscreen
mode as well as "transmission error reset" and "purge input buffer". The
last two may be unnecessary, but are harmless anyway.
5) The maximum packet size is 1920, a screensize buffer. Better use 1900 to
allow for some extraneous characters. Around 950 is a good choice as little
performance gain is (usually) observed beyond and because it eases faster
resynchronization when two packets stick together.
I think these facts (and maybe others, welcome) will help to run file
transfer with the 7171 much more reliably.
Now that's not all. There are problems with VTAM and the fact that being a
half duplex device in file transfer mode, the 7171 would normally call for
handshaking. But I'll continue these, resorting to 370 Kermit internals, on
the appropriate list.
This gives but a faint idea of the mess 370 Kermit people have to deal with.
Believe me how thankful one has to be for their patience and work against a
beast said to be working as designed!
------------------------------
Date: 21 Sep 87 19:19:30 GMT
From: kent@soma.bcm.tmc.edu (Kent Hutson)
Subject: Kermit for Tandy 6000?
Keywords: Tandy 6000, Xenix, C-Kermit
Does anyone know where I can find a Kermit program that will work on a Tandy
6000 running Xenix? I have tried C-Kermit from Columbia, but had a lot of
trouble getting it running. I would like some suggestions for getting
C-Kermit running if you know what the problem might be.
Kent Hutson
Baylor College of Medicine, Houston, Texas
[Ed. - Others have complained of being unable to get C-Kermit working on the
Tandy 6000. Previous versions reportedly worked, but it seems that the
system was so slow that the program had to be compiled in a special way.
For one thing, is Tandy Xenix still based on Unix V7? If so, then you have
to do "make v7" rather than "make xenix" to build the program. And before
you do that, look in the makefile for special hints about "TRS-80 Xenix".]
------------------------------
Date: 6-SEP-1987 21:32:56
From: RHBNCSU@UK.AC.RHBNC.VAXA (Tom Bourke)
Via: SYSKERMIT%vax1.central.lancaster.ac.uk@NSS.Cs.Ucl.AC.UK
Subject: 8th-Nit Prefix Bug in Kermit For TRS80 Model IV (M4)
Keywords: TRS-80 Model 4 Kermit
Cross-Ref: Tandy, see also TRS-80
This is a note to explain the problem that arises under the use of Tandy
Model IV Kermit and Kermits that follow the protocol to the last letter. It
also gives a temporary solution, while I am informing Gregg Wonderly, an
American who wrote the Model IV implementation, but I'll also look into
providing a fix 'cos I'm using the darned thing!
Anyway, on with the problem. The protocol manual suggests that Kermits make
the best use of the communication lines they have access to. As a result,
machines communicating over 8-bit lines should use the full 8-bits unless
parity of some form or another is in use. As a result, if you are using
'proper' 8-bit lines, you shouldn't prefix the 8th bit prefixing character,
'cos you won't be sending any 8th bit prefixes anyway! The Tandy Model IV
implementation of Kermit ignores this wonderful piece of information and takes
every '&' character as an eighth bit prefix. As you have guessed this does
wonderful things to program listings! (Especially ones in 'C'!)
The instant (!) solution to this problem is to tell the host machine that it
is dealing with a machine that doesn't like the eighth bit. SET PARITY
SPACE has been working here on the VAX <-> Tandy Model IV's. At the same
time, the Tandy Model IV should have eighth bit prefixing turned on.
------------------------------
End of Info-Kermit Digest
*************************
-------