SY.CHRISTINE@CU20B.COLUMBIA.EDU (Christine M Gianone) (05/08/87)
Info-Kermit Digest Thu, 07 May 1987 Volume 6 : Number 10
Today's Topics:
Use of KERMSRV@UOFT02.BITNET
IBM PC Kermit on the New IBM Personal System/2 Series?
MS-Kermit Works on IBM PC2/30
MS-Kermit Works on IBM PC2/50
Kermit-MS 2.29 Modem Problems
Local Echo Problem with MS Kermit 2.29B
MSVIBM.BOO Problems
Printer Control in MS-Kermit 2.29B
Apollo Kermits (Pascal and C)
Apollo Kermit bug
ISIS Kermit - fixes and frustrations
QL Kermit HEX Needed
Commodore Kermit .HEX file Needed
Bugs in new Apple Kermit (A2)
Bug in Amiga C-Kermit
C Kermit on Motorola Delta SVR3
Bugs in Sperry Univac Kermit
----------------------------------------------------------------------
Date: Mon, 20 Apr 87 08:12 EST
From: <BRIAN@UOFT02.BITNET> (brian nelson)
Subject: Use of KERMSRV@UOFT02.BITNET
Keywords: KERMSRV
I would like to point out a couple of problems with requests to the Kermit
bitnet server here at Toledo. The first is that attempts to see if Kermsrv
is 'logged in', ie, SEN/COM UOFT02 CPQ U KERMSRV or SM RSCS MSG UOFT02
KERMSRV CPQ U KERMSRV will ALWAYS fail. This is a VMS node running Jnet and
jnet treats server processes in a manner unlike VM does.
For all pratical purposes, Kermsrv is always running. If a message is sent
to it, and for some reason its not there, Jnet will tell you.
Secondly, KERMSRV can ONLY respond to interactive messages, it can not
process mail. I see several attempts per day to send it mail.
I hope this clarifies any confusion regarding the server here.
Brian Nelson
------------------------------
Date: Fri 3 Apr 87 12:26:06-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: IBM PC Kermit on the New IBM Personal System/2 Series?
Keywords: IBM PC System/2
Now that we've seen IBM's announcements for their new line of PCs, is there
anyone out there who can say whether IBM PC Kermit (2.29B or earlier) runs on
them? If not, what are the symptoms? If so, are there any peculiarities?
------------------------------
Date: Wed, 8 Apr 87 17:55:12 PDT
From: gts@violet.berkeley.edu (Greg Small)
Subject: MS-Kermit Works on IBM PC2/30
Keywords: MS-DOS Kermit
MS-Kermit 2.27 ran OK [under DOS 3.3 on the PC2/30] with the serial port so the
serial UART and interrupt controlers are compatible. Requires distribution of
software in 3.5" floppy format.
------------------------------
Date: 14 April 1987, 11:15:11 CST
From: C03640JP@WUVMD.BITNET (Michael Palmer)
Subject: MS-Kermit Works on IBM PC2/50
Keywords: MS-DOS Kermit
Am coming to you now from a model 50. Kermit ... work[s] fine with it.
------------------------------
Date: Wed, 6 May 87 13:26 EDT
From: HOLLEY <BOB@SER>
Subject: Kermit-MS 2.29 Modem Problems
Keywords: MS-DOS Kermit, Modems
Our data center began distributing Kermit-MS 2.29 in the later part of last
fall. Several weeks after we began, it became obvious that version 2.29
would not work for users who had internal modems. In January, we learned of
version 2.29B, which appeared to address the internal modem problems, and we
began to distribute that.
We thought all our problems were solved, but now we have several people with
internal Hayes 1200B "short card" internal modems (at least one of those has
his modem card plugged into a true IBM-XT), who seem to be having troubles
even with 2.29B. In addition, we just came across the following article in
the March/April issue of the University Computing Services Newsletter of the
University of Oklahoma:
HAYES MODEM INCOMPATIBLE WITH KERMIT
There is a new Hayes internal modem which is incompatible with Kermit-MS
version 2.29. The modem is model 1200-B, the same designation used for
previous models. The distinction is that it is on a half-length or "short
card." Short cards are about 7 inches long.
This incompatibility is distressing because Hayes modems are generally
acknowledged as the industry standard and Kermit-MS supports Hayes
compatible modems. The Hayes short-card modems fail to establish a
connection when used with Kermit-MS version 2.29. They may be incompatible
with other software as well. They do work with Hayes SmartCom software and
earlier versions of Kermit-MS. Hayes-compatible modems from other vendors
work with 2.29. This problem is unlikely to be resolved in the near future.
(Reprinted from the University of Nebraska at Omaha Campus Computing
Newsletter, March/April 1987)
It is not entirely clear whether the above article is referring to the
original release of Kermit-MS 2.29 or to Kermit-MS 2.29B. One is led to
suspect the latter, though, as we never found ANYONE with an internal modem
of any kind that could get 2.29 to work.
Is there really some particular problem with Hayes 1200-B "short-card"
internal modems and Kermit-MS 2.29B?? If there is, we would like to warn
our users not to purchase this particular equipment.
Thank you for your kind attention.
Robert M. Holley
Director, User Ed & Pubs
Southeast Regional Data Center
Florida International University
Miami, Florida
BITNET Addresses: BOB@SERVAX or BOB@SER
[Ed. - The current developer of MS-Kermit tested 2.29B with a loaner Hayes
1200B half-height card, and it worked successfully. Another user with an
Everex half-height Hayes clone also reported successful operation. Can anyone
else with these modems report further, so that if any additional fixes are
needed, they can get into 2.30 before its final release?]
------------------------------
Date: Thu, 16 Apr 87 10:24:37 CDT
From: pyle@ngp.utexas.edu (Keith Pyle)
Subject: Local Echo Problem with MS Kermit 2.29B
Keywords: MS-DOS Kermit
One of my co-workers asked me to report that there is apparently a bug in
the handling of local echo with MS Kermit 2.29b. When transferring files to
or from a CMS system (CMS Kermit 3.1), he has noted that the first character
typed as a command to the CMS Kermit will be displayed but that subsequent
characters do not appear until after the return is entered AND the CMS
Kermit has processed the command.
Keith Pyle pyle@ngp.utexas.edu
[Ed. - We are unable to reproduce this problem, using PC/ATs and a VM/CMS
system running the same version of CMS Kermit. Has anyone else experienced
a problem like this?]
------------------------------
Date: 26 April 1987, 16:38:47 EST
From: Aharon Friedman 516-282-7979 FRIEDMAN at BNLVMA
Subject: MSVIBM.BOO Problems
Keywords: MS-DOS Kermit
I have problems with that file. It stalls the computer after running
msbpct on it.
Aharon Friedman
[Ed. - Most likely the .BOO file was the victim of a nonstandard ASCII/EBCDIC
translate table somewhere on its journey between its home on CUVMA and your
PC. The .BOO file has been successfully decoded at many other BITNET sites.]
------------------------------
Date: 29-APR-1987 10:53:36
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Printer Control in MS-Kermit 2.29B
Keywords: MS-DOS Kermit
Printer control from vn 2.29b of IBM Kermit is fine in the sense that it
appears to correctly handle flow control etc.
However, if you are expecting to use the power of the printer via escape
sequences then you will be disappointed.
There are two modes for controlling the printer port directly from the
terminal line : Esc [ 5 i and Esc [ ? 5 i. The former is used to select
a transparent mode (no screen echo), while the latter selects a
conversational mode (with screen echo).
The important point about transparent mode is that no escape sequences
received by Kermit in this mode should be interpreted for the screen's
purposes - they should all be passed on unchanged to the printer, with
the sole exception of the escape sequence which closes the printer port
( Esc [ 4 i ).
Version 2.29b does no such thing - it interprets an escape sequence and
appears to remove the escape and the character following from the stream
of data. This is consistent with a primitive two byte escape sequence
model beloved of VT52 and other simple terminal protocols.
It has another related failing : since Kermit appears to regard nul as a
padding character to be thrown away at liberty, it continues to do this
in transparent printer mode. Some printers (e.g. the Epson family)
feature nul as a required part of an escape sequence. More important
perhaps is that more recent printers have started to offer a downloading
facility for character sets. A character definition of course is
supplied as a sequence of bytes rpresenting the rows of the matrix, and
nul is the value required for an empty row.
I know I may be asking the printer support module to run before it can
walk, but I hope you can appreciate the importance of the matter.
Cheers : Norman Bridges.
------------------------------
Date: Tue, 31 Mar 87 14:05:09 MST
From: "Tim E. Barrios" <barrios%asu.csnet@RELAY.CS.NET>
Subject: Apollo Kermits (Pascal and C)
Keywords: Apollo Kermit
Thanks for fixing the ^Y's in the file. Now, it looks like there is one
key character that is missing from the following lines causing a syntax
error when compiled:
567, 577, 850, 1282, and 1442
my guess is that the character is '&'. this might have been related to the
^Y problem.
About the 'C' version, it's been almost a year since I messed with it, but it
had something to do with a difference between the Unix sys5 include library's
'.h' (some record's struct statement) and what the kermit source expected.
The person who is working on that problem is:
wicinski@nrl-css (arpa net)
we have kept in touch concerning both versions on the apollo.
thanks,
tim barrios
[Ed. - See message below...]
------------------------------
Date: Fri 3 Apr 87 15:34:12-PST
From: Ted Shapin <BEC.SHAPIN@USC-ECL.ARPA>
Subject: Apollo Kermit bug
Keywords: Apollo Kermit
I'm sorry that the Pascal source file I sent you for Apollo Kermit had some
errors in it.
For reasons I have not yet found, when I sent APOKERMIT.PAS from the Apollo
to the DEC 20 using TOPS 20 KERMIT version 4.2(253), alll the "Y" characters
turned into "control-Y's", and all of the "&" characters were missing. When
I sent the same file to an IBM-PC using KERMIT-MS version 2.29b, the file
was sent correctly.
[Ed. - All of the changes have been made so the Apollo Kermit should be ok
now.]
------------------------------
Date: 17 Apr 87 17:48:00 EDT
From: John R. Williams <JWILLIAMS@ARI-HQ1.ARPA>
Subject: ISIS Kermit - fixes and frustrations
Keywords: ISIS Kermit, MDS Kermit, iPDS
For those of you who have implemented Bill Boyd's latest version of ISIS
Kermit (see the Digest, Volume 6, Number 9) I have an interim fix for the
problem of losing characters in Connect mode and a plea for help concerning
the program's performance. I have not been able to contact Mr. Boyd.
First, the fix. This will allow at least some of you to operate in Connect
mode at 4800 and 9600 baud. It will still occasionally miss characters at
4800 baud and consistently miss 1 or 2 characters per line at 9600 baud,
but in my case, at least, 9600 baud Connect mode operation is now usable, if
not perfect.
In the Connect Module, find the statement that looks something like this:
if ready(port) > 0 then call putc(getc(port, 0);
Declare a temporary variable, such as "i", and then enclose the above
statement in a DO loop, like this:
declare i byte;
.
.
.
do i = 1 to 200;
if ready(port) > 0 then call putc(getc(port), 0);
end;
This causes the program to read the input port 200 times for every time it
checks for keyboard input. The loop termination value 200 was determined
empirically. You may find that another value works better for you. I also
replaced "putc" with "co", which bypasses the status checking provided by
"putc". That may not provide any real benefit.
Next, performance considerations. You may be interested to know that in my
system file transfer at 19200 baud occurs with no errors. The only problem is
that screen output at 19200 is pure gibberish - it misses 50 to 70 per cent of
the characters, even with the fix noted above.
The performance problem that concerns me with the new version, however, is
that for some reason when receiving files the time between packets is
excessively long, averaging about six seconds! The old version is at least 10
times faster under the same circumstances, and I cannot find any code
differences to account for it. The delay is apparently in procedure RPACK
where it waits to receive the SOH. If anyone has an explanation and a fix for
this condition, I am most anxious to hear from you!
All my experience with ISIS Kermit has been using a Series III MDS, with a
Winchester disk, connected directly to a VAX 11/782 terminal port (no modem).
The VAX is running VMS Kermit-32 version 3.2.77 under VMS 4.4.
Also, if anyone has had any success using ISIS Kermit on an iPDS, I'd like to
share experiences with you. In my version, the iPDS receives VAX files OK but
fails miserably when sending.
John
[Ed. - Thanks. This note has been put into the file KER:MDSMIT.BWR.]
------------------------------
Date: Wed, 22 Apr 87 11:38:17 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: QL Kermit HEX Needed
Keywords: Sinclair QL Kermit
Probably not many Sinclair QL users own a disk drive nor do they have the C
compiler available. Couldn't someone send a hex file to be included in the
Kermit library? Thanks in advance.
[Ed. - If someone could send a .HEX file for this Kermit version, we would
be glad to include it in the regular Kermit Distribution.]
------------------------------
Date: Wed, 22 Apr 1987 14:53 EST
From: Ray Moody <MOODY@PURCCVM>
Subject: Commodore Kermit .HEX file Needed
Keywords: Commodore Kermit
I have received several requests to create a .HEX file for Commodore
Kermit Version 2. I don't have a program that can create .HEX files. Is it
possible for someone else to create the .HEX file?
Ray Moody
aij@s.cc.purdue.edu
ihnp4!pur-ee!s.cc.purdue.edu!aij
moody@purccvm.BITNET
[Ed. - Can anyone create a .HEX file for Commodore Kermit and send it in for
redistribution, or send some kind of .HEX-file maker & decoder to Ray?]
------------------------------
Date: 24-APR-1987 10:31:30
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Bugs in new Apple Kermit (A2)
Keywords: Apple II Kermit
Alan Thomson of our Chemistry department reports a few problems with the new
A2 Apple Kermit. These were found using a non-interrupt driven Mountain
Hardware CPS card (the driver for which will be sent over to you soon):
1. When using GET, A2 Kermit lingers around doing things internally for long
enough to miss the first few characters of the server's response. After
timing out and retrying things settle down to work OK.
2. After issuing FINISH the Apple side waits for 5 seconds before reissuing
its command prompt.
------------------------------
Date: Sat, 25 Apr 1987 00:50 CST
From: Ian Horstmeier <HORSTMIH@UREGINA1>
Subject: Bug in Amiga C-Kermit
Keywords: C-Kermit
I recently received this from a friend of mine regarding C-kermit for the
Amiga. Perhaps this information will be useful.
Subject - Re: Using VT100/KERMIT and IBM systems
Summary - The fix for C-Kermit
The reason that C-kermit on the Amiga doesn't work with the IBM, is because
the parity is not set! I got my version of C-Kermit from kermserv@cuvma
on BITNET, and it still contains this bug. In the CKICON.C module, look
in the connect mode function. In about the middle of it, there is a call
to the output a character function ttocq(c). This needs to be changed to
ttocq(dopar(c)). There! It now works with IBM and sets parity correctly.
According to the comments in the code, Kermit does its own parity checking
and the serial.device is always in 8 bit no parity. I always use kermit on
the mainframe and the vax. One thing you will notice is that the standard
amiga keymap does not generate codes to be compatible with anything! I am
in the process of writing a keymap module for amiga c-kermit to make it look
like a vt100. Good luck!
Walter Reed
UUCP : ihnp4!umn-cs!ndsuvax!ncreed
Bitnet: ncreed@ndsuvax OR NU105451@NDSUVM1
[Ed. - Thanks for the fix -- it's been added to CKIKER.BWR. Further reports
would be appreciated.]
------------------------------
Date: 29 Apr 87 16:41:05 GMT
From: seismo!gatech!mcdchg!heiby@columbia.edu (Ron Heiby)
Subject: C Kermit on Motorola Delta SVR3
Keywords: C-Kermit
Hi! I just finished bringing up C Kermit 4D(061) on a Motorola Delta system
running System V/68 Release 3.0. I found some minor problems that I thought
should be mentioned.
The entry in the makefile (ckuker.mak) for "att3bx" and the corresponding
#define for "ATT3BX" is actually not dependent on the AT&T 3B architecture.
It is for the AT&T Basic Networking Utilities (BNU), also called "Honey
DanBer UUCP". This version of uucp is standard with System V Release 3
as it comes from AT&T and as implemented on the Motorola systems. I suggest
changing the makefile and define to something more like "hdbuucp" or something
like that. Of course, HDB is not restricted to System V releases, so the
"-D" for it should probably be seperate from any particular "make" target.
The "beware" file for C Kermit talks about a name confilict on "unchar" for
ATT 3Bx systems. This is really a System V Release 3 issue and is also
the case for the Motorola implementation. I tried the suggested fix, of
"-Dunchar=myunchar" in the makefile and, as expected, it didn't help. I
edited the files used for my build to change "unchar" to "myunchar". There
are other references to be changed for non-UNIX builds. The files I changed
for this were: ckcker.h, ckcpro.w, ckcfn2.c, and ckcfns.c.
System V Release 3 has re-defined the signal(2) system call as:
extern void (*signal())();
instead of:
extern int (*signal())();
This means that lines in ckudia.c, ckuusr.c, and ckuscr.c must be changed
to avoid illegal pointer combination errors. I just changed "int" to "void"
in each case. Better (more general) would be to use a typedef based on a
define, like "SVR3" (which might also cause the BNU locking code to be used).
The C compiler that comes with SVR3 is no longer so forgiving of random tokens
following preprocessor directives. Convention has been to do things like:
#if FOO
code
#else !FOO
other code
#endif FOO
This causes warnings on both the #else and #endif. Correct would be:
#if FOO
code
#else /* !FOO */
other code
#endif /* FOO */
Several places in ckutio.c had to be changed for this.
Also, ckcdeb.h includes some #include lines for "vax11c" which are not
of legal format. Even though they are bounded by #ifdef/#endif, the
pre-processor still sees them and barfs. I changed the conditionals
surrounding them to cause them to actually be commented out, if "vax11c"
were not defined. This problem could be construed to be a bug in the
C Pre-processor, but I don't have a copy of a current ANSI spec, so am
not sure.
Here are context diffs of the code changes I made. "orig" is the original code
as I received it. "save" is the code as I modified it to compile properly.
[Ed. - This message, and the diffs, have been added to CKUKER.BWR, and will be
looked at for the next release. Thanks!]
Ron Heiby, heiby@mcdchg.UUCP Moderator: comp.newprod & comp.unix
Motorola Microcomputer Division (MCD), Schaumburg, IL
"I am not elsewhere."
------------------------------
Date: TUE, 14 APR 87 14:34:41 GMT
From: ROGER @ UK.AC.TPB
Subject: Bugs in Sperry Univac Kermit
Keywords: Sperry Kermit, Univac Kermit
I recently acquired a copy of Sperry UNIVAC KERMIT written in assembler,
for use on a non front end site.
After a little tinkering , to get it to work with our setup , I discovered
a couple of little coding bugs. I must admit I'm not the world's greatest
programmer in @MASM, but I THINK (underline that in italics) I've sorted them
out:
There was a bug in the SHOW SEND routine that caused the SEND STARTOFPACKET
displayed to be the RECEIVE STARTOFPACKET, and a bug in the SHOW RECEIVE
routine that caused it to display the SEND STARTOFPACKET.
No prizes for guessing what had happened !!!!
The actual parameters in the SHOW list had been juxtaposed; simply
swapping over lines 2281 and 2300 in the original source should cure the
problem.
Another more serious problem was that when assembled with MDLFE=0 and
DCPFE=1, the code still expected to find a couple of entrypoints that
weren't there: they'd not been assembled because of a conditional directive.
My cure is rather elegant, but as I've no idea what I've done it may not be
the right one. All I did was to move the offending reference, in line 2613 to
only occur in the conditional directive immediately following it. that is line
2613 was inserted AFTER the IF MDLFE statement.
That seems to have cured it, it now @MASM's without errors, and @MAP's
without errors. I've succesfully used it in SERVER mode with a PC clone
running CROSSTALK, so I assume I've done the right thing.
If anyone else has any tips or points Id like to hear from them.
Jason LoCascio,
British Gas PLC
59 Bryanston Street
LONDON
W1
(01) 723-7030 ext. 1289
Or I can be contacted at THAMES POLYTECHNIC , via JANET :-
ROGER @ 000045399000.TPB.SPCP.FTP.MAIL
(We are not registered in NRS yet)
------------------------------
End of Info-Kermit Digest
*************************
-------SY.CHRISTINE@CU20B.COLUMBIA.EDU (Christine M Gianone) (05/08/87)
8-May-87 12:50:46-EDT,22980;000000000000
Mail-From: SY.CHRISTINE created at 8-May-87 12:48:51
Date: Fri 8 May 87 12:48:51-EDT
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digest V6 #10
To: Info-Kermit@CU20B.COLUMBIA.EDU
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <12300766567.9.SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Info-Kermit Digest Thu, 07 May 1987 Volume 6 : Number 10
Today's Topics:
Use of KERMSRV@UOFT02.BITNET
IBM PC Kermit on the New IBM Personal System/2 Series?
MS-Kermit Works on IBM PC2/30
MS-Kermit Works on IBM PC2/50
Kermit-MS 2.29 Modem Problems
Local Echo Problem with MS Kermit 2.29B
MSVIBM.BOO Problems
Printer Control in MS-Kermit 2.29B
Apollo Kermits (Pascal and C)
Apollo Kermit bug
ISIS Kermit - fixes and frustrations
QL Kermit HEX Needed
Commodore Kermit .HEX file Needed
Bugs in new Apple Kermit (A2)
Bug in Amiga C-Kermit
C Kermit on Motorola Delta SVR3
Bugs in Sperry Univac Kermit
----------------------------------------------------------------------
Date: Mon, 20 Apr 87 08:12 EST
From: <BRIAN@UOFT02.BITNET> (brian nelson)
Subject: Use of KERMSRV@UOFT02.BITNET
Keywords: KERMSRV
I would like to point out a couple of problems with requests to the Kermit
bitnet server here at Toledo. The first is that attempts to see if Kermsrv
is 'logged in', ie, SEN/COM UOFT02 CPQ U KERMSRV or SM RSCS MSG UOFT02
KERMSRV CPQ U KERMSRV will ALWAYS fail. This is a VMS node running Jnet and
jnet treats server processes in a manner unlike VM does.
For all pratical purposes, Kermsrv is always running. If a message is sent
to it, and for some reason its not there, Jnet will tell you.
Secondly, KERMSRV can ONLY respond to interactive messages, it can not
process mail. I see several attempts per day to send it mail.
I hope this clarifies any confusion regarding the server here.
Brian Nelson
------------------------------
Date: Fri 3 Apr 87 12:26:06-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: IBM PC Kermit on the New IBM Personal System/2 Series?
Keywords: IBM PC System/2
Now that we've seen IBM's announcements for their new line of PCs, is there
anyone out there who can say whether IBM PC Kermit (2.29B or earlier) runs on
them? If not, what are the symptoms? If so, are there any peculiarities?
------------------------------
Date: Wed, 8 Apr 87 17:55:12 PDT
From: gts@violet.berkeley.edu (Greg Small)
Subject: MS-Kermit Works on IBM PC2/30
Keywords: MS-DOS Kermit
MS-Kermit 2.27 ran OK [under DOS 3.3 on the PC2/30] with the serial port so the
serial UART and interrupt controlers are compatible. Requires distribution of
software in 3.5" floppy format.
------------------------------
Date: 14 April 1987, 11:15:11 CST
From: C03640JP@WUVMD.BITNET (Michael Palmer)
Subject: MS-Kermit Works on IBM PC2/50
Keywords: MS-DOS Kermit
Am coming to you now from a model 50. Kermit ... work[s] fine with it.
------------------------------
Date: Wed, 6 May 87 13:26 EDT
From: HOLLEY <BOB@SER>
Subject: Kermit-MS 2.29 Modem Problems
Keywords: MS-DOS Kermit, Modems
Our data center began distributing Kermit-MS 2.29 in the later part of last
fall. Several weeks after we began, it became obvious that version 2.29
would not work for users who had internal modems. In January, we learned of
version 2.29B, which appeared to address the internal modem problems, and we
began to distribute that.
We thought all our problems were solved, but now we have several people with
internal Hayes 1200B "short card" internal modems (at least one of those has
his modem card plugged into a true IBM-XT), who seem to be having troubles
even with 2.29B. In addition, we just came across the following article in
the March/April issue of the University Computing Services Newsletter of the
University of Oklahoma:
HAYES MODEM INCOMPATIBLE WITH KERMIT
There is a new Hayes internal modem which is incompatible with Kermit-MS
version 2.29. The modem is model 1200-B, the same designation used for
previous models. The distinction is that it is on a half-length or "short
card." Short cards are about 7 inches long.
This incompatibility is distressing because Hayes modems are generally
acknowledged as the industry standard and Kermit-MS supports Hayes
compatible modems. The Hayes short-card modems fail to establish a
connection when used with Kermit-MS version 2.29. They may be incompatible
with other software as well. They do work with Hayes SmartCom software and
earlier versions of Kermit-MS. Hayes-compatible modems from other vendors
work with 2.29. This problem is unlikely to be resolved in the near future.
(Reprinted from the University of Nebraska at Omaha Campus Computing
Newsletter, March/April 1987)
It is not entirely clear whether the above article is referring to the
original release of Kermit-MS 2.29 or to Kermit-MS 2.29B. One is led to
suspect the latter, though, as we never found ANYONE with an internal modem
of any kind that could get 2.29 to work.
Is there really some particular problem with Hayes 1200-B "short-card"
internal modems and Kermit-MS 2.29B?? If there is, we would like to warn
our users not to purchase this particular equipment.
Thank you for your kind attention.
Robert M. Holley
Director, User Ed & Pubs
Southeast Regional Data Center
Florida International University
Miami, Florida
BITNET Addresses: BOB@SERVAX or BOB@SER
[Ed. - The current developer of MS-Kermit tested 2.29B with a loaner Hayes
1200B half-height card, and it worked successfully. Another user with an
Everex half-height Hayes clone also reported successful operation. Can anyone
else with these modems report further, so that if any additional fixes are
needed, they can get into 2.30 before its final release?]
------------------------------
Date: Thu, 16 Apr 87 10:24:37 CDT
From: pyle@ngp.utexas.edu (Keith Pyle)
Subject: Local Echo Problem with MS Kermit 2.29B
Keywords: MS-DOS Kermit
One of my co-workers asked me to report that there is apparently a bug in
the handling of local echo with MS Kermit 2.29b. When transferring files to
or from a CMS system (CMS Kermit 3.1), he has noted that the first character
typed as a command to the CMS Kermit will be displayed but that subsequent
characters do not appear until after the return is entered AND the CMS
Kermit has processed the command.
Keith Pyle pyle@ngp.utexas.edu
[Ed. - We are unable to reproduce this problem, using PC/ATs and a VM/CMS
system running the same version of CMS Kermit. Has anyone else experienced
a problem like this?]
------------------------------
Date: 26 April 1987, 16:38:47 EST
From: Aharon Friedman 516-282-7979 FRIEDMAN at BNLVMA
Subject: MSVIBM.BOO Problems
Keywords: MS-DOS Kermit
I have problems with that file. It stalls the computer after running
msbpct on it.
Aharon Friedman
[Ed. - Most likely the .BOO file was the victim of a nonstandard ASCII/EBCDIC
translate table somewhere on its journey between its home on CUVMA and your
PC. The .BOO file has been successfully decoded at many other BITNET sites.]
------------------------------
Date: 29-APR-1987 10:53:36
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Printer Control in MS-Kermit 2.29B
Keywords: MS-DOS Kermit
Printer control from vn 2.29b of IBM Kermit is fine in the sense that it
appears to correctly handle flow control etc.
However, if you are expecting to use the power of the printer via escape
sequences then you will be disappointed.
There are two modes for controlling the printer port directly from the
terminal line : Esc [ 5 i and Esc [ ? 5 i. The former is used to select
a transparent mode (no screen echo), while the latter selects a
conversational mode (with screen echo).
The important point about transparent mode is that no escape sequences
received by Kermit in this mode should be interpreted for the screen's
purposes - they should all be passed on unchanged to the printer, with
the sole exception of the escape sequence which closes the printer port
( Esc [ 4 i ).
Version 2.29b does no such thing - it interprets an escape sequence and
appears to remove the escape and the character following from the stream
of data. This is consistent with a primitive two byte escape sequence
model beloved of VT52 and other simple terminal protocols.
It has another related failing : since Kermit appears to regard nul as a
padding character to be thrown away at liberty, it continues to do this
in transparent printer mode. Some printers (e.g. the Epson family)
feature nul as a required part of an escape sequence. More important
perhaps is that more recent printers have started to offer a downloading
facility for character sets. A character definition of course is
supplied as a sequence of bytes rpresenting the rows of the matrix, and
nul is the value required for an empty row.
I know I may be asking the printer support module to run before it can
walk, but I hope you can appreciate the importance of the matter.
Cheers : Norman Bridges.
------------------------------
Date: Tue, 31 Mar 87 14:05:09 MST
From: "Tim E. Barrios" <barrios%asu.csnet@RELAY.CS.NET>
Subject: Apollo Kermits (Pascal and C)
Keywords: Apollo Kermit
Thanks for fixing the ^Y's in the file. Now, it looks like there is one
key character that is missing from the following lines causing a syntax
error when compiled:
567, 577, 850, 1282, and 1442
my guess is that the character is '&'. this might have been related to the
^Y problem.
About the 'C' version, it's been almost a year since I messed with it, but it
had something to do with a difference between the Unix sys5 include library's
'.h' (some record's struct statement) and what the kermit source expected.
The person who is working on that problem is:
wicinski@nrl-css (arpa net)
we have kept in touch concerning both versions on the apollo.
thanks,
tim barrios
[Ed. - See message below...]
------------------------------
Date: Fri 3 Apr 87 15:34:12-PST
From: Ted Shapin <BEC.SHAPIN@USC-ECL.ARPA>
Subject: Apollo Kermit bug
Keywords: Apollo Kermit
I'm sorry that the Pascal source file I sent you for Apollo Kermit had some
errors in it.
For reasons I have not yet found, when I sent APOKERMIT.PAS from the Apollo
to the DEC 20 using TOPS 20 KERMIT version 4.2(253), alll the "Y" characters
turned into "control-Y's", and all of the "&" characters were missing. When
I sent the same file to an IBM-PC using KERMIT-MS version 2.29b, the file
was sent correctly.
[Ed. - All of the changes have been made so the Apollo Kermit should be ok
now.]
------------------------------
Date: 17 Apr 87 17:48:00 EDT
From: John R. Williams <JWILLIAMS@ARI-HQ1.ARPA>
Subject: ISIS Kermit - fixes and frustrations
Keywords: ISIS Kermit, MDS Kermit, iPDS
For those of you who have implemented Bill Boyd's latest version of ISIS
Kermit (see the Digest, Volume 6, Number 9) I have an interim fix for the
problem of losing characters in Connect mode and a plea for help concerning
the program's performance. I have not been able to contact Mr. Boyd.
First, the fix. This will allow at least some of you to operate in Connect
mode at 4800 and 9600 baud. It will still occasionally miss characters at
4800 baud and consistently miss 1 or 2 characters per line at 9600 baud,
but in my case, at least, 9600 baud Connect mode operation is now usable, if
not perfect.
In the Connect Module, find the statement that looks something like this:
if ready(port) > 0 then call putc(getc(port, 0);
Declare a temporary variable, such as "i", and then enclose the above
statement in a DO loop, like this:
declare i byte;
.
.
.
do i = 1 to 200;
if ready(port) > 0 then call putc(getc(port), 0);
end;
This causes the program to read the input port 200 times for every time it
checks for keyboard input. The loop termination value 200 was determined
empirically. You may find that another value works better for you. I also
replaced "putc" with "co", which bypasses the status checking provided by
"putc". That may not provide any real benefit.
Next, performance considerations. You may be interested to know that in my
system file transfer at 19200 baud occurs with no errors. The only problem is
that screen output at 19200 is pure gibberish - it misses 50 to 70 per cent of
the characters, even with the fix noted above.
The performance problem that concerns me with the new version, however, is
that for some reason when receiving files the time between packets is
excessively long, averaging about six seconds! The old version is at least 10
times faster under the same circumstances, and I cannot find any code
differences to account for it. The delay is apparently in procedure RPACK
where it waits to receive the SOH. If anyone has an explanation and a fix for
this condition, I am most anxious to hear from you!
All my experience with ISIS Kermit has been using a Series III MDS, with a
Winchester disk, connected directly to a VAX 11/782 terminal port (no modem).
The VAX is running VMS Kermit-32 version 3.2.77 under VMS 4.4.
Also, if anyone has had any success using ISIS Kermit on an iPDS, I'd like to
share experiences with you. In my version, the iPDS receives VAX files OK but
fails miserably when sending.
John
[Ed. - Thanks. This note has been put into the file KER:MDSMIT.BWR.]
------------------------------
Date: Wed, 22 Apr 87 11:38:17 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: QL Kermit HEX Needed
Keywords: Sinclair QL Kermit
Probably not many Sinclair QL users own a disk drive nor do they have the C
compiler available. Couldn't someone send a hex file to be included in the
Kermit library? Thanks in advance.
[Ed. - If someone could send a .HEX file for this Kermit version, we would
be glad to include it in the regular Kermit Distribution.]
------------------------------
Date: Wed, 22 Apr 1987 14:53 EST
From: Ray Moody <MOODY@PURCCVM>
Subject: Commodore Kermit .HEX file Needed
Keywords: Commodore Kermit
I have received several requests to create a .HEX file for Commodore
Kermit Version 2. I don't have a program that can create .HEX files. Is it
possible for someone else to create the .HEX file?
Ray Moody
aij@s.cc.purdue.edu
ihnp4!pur-ee!s.cc.purdue.edu!aij
moody@purccvm.BITNET
[Ed. - Can anyone create a .HEX file for Commodore Kermit and send it in for
redistribution, or send some kind of .HEX-file maker & decoder to Ray?]
------------------------------
Date: 24-APR-1987 10:31:30
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Bugs in new Apple Kermit (A2)
Keywords: Apple II Kermit
Alan Thomson of our Chemistry department reports a few problems with the new
A2 Apple Kermit. These were found using a non-interrupt driven Mountain
Hardware CPS card (the driver for which will be sent over to you soon):
1. When using GET, A2 Kermit lingers around doing things internally for long
enough to miss the first few characters of the server's response. After
timing out and retrying things settle down to work OK.
2. After issuing FINISH the Apple side waits for 5 seconds before reissuing
its command prompt.
------------------------------
Date: Sat, 25 Apr 1987 00:50 CST
From: Ian Horstmeier <HORSTMIH@UREGINA1>
Subject: Bug in Amiga C-Kermit
Keywords: C-Kermit
I recently received this from a friend of mine regarding C-kermit for the
Amiga. Perhaps this information will be useful.
Subject - Re: Using VT100/KERMIT and IBM systems
Summary - The fix for C-Kermit
The reason that C-kermit on the Amiga doesn't work with the IBM, is because
the parity is not set! I got my version of C-Kermit from kermserv@cuvma
on BITNET, and it still contains this bug. In the CKICON.C module, look
in the connect mode function. In about the middle of it, there is a call
to the output a character function ttocq(c). This needs to be changed to
ttocq(dopar(c)). There! It now works with IBM and sets parity correctly.
According to the comments in the code, Kermit does its own parity checking
and the serial.device is always in 8 bit no parity. I always use kermit on
the mainframe and the vax. One thing you will notice is that the standard
amiga keymap does not generate codes to be compatible with anything! I am
in the process of writing a keymap module for amiga c-kermit to make it look
like a vt100. Good luck!
Walter Reed
UUCP : ihnp4!umn-cs!ndsuvax!ncreed
Bitnet: ncreed@ndsuvax OR NU105451@NDSUVM1
[Ed. - Thanks for the fix -- it's been added to CKIKER.BWR. Further reports
would be appreciated.]
------------------------------
Date: 29 Apr 87 16:41:05 GMT
From: seismo!gatech!mcdchg!heiby@columbia.edu (Ron Heiby)
Subject: C Kermit on Motorola Delta SVR3
Keywords: C-Kermit
Hi! I just finished bringing up C Kermit 4D(061) on a Motorola Delta system
running System V/68 Release 3.0. I found some minor problems that I thought
should be mentioned.
The entry in the makefile (ckuker.mak) for "att3bx" and the corresponding
#define for "ATT3BX" is actually not dependent on the AT&T 3B architecture.
It is for the AT&T Basic Networking Utilities (BNU), also called "Honey
DanBer UUCP". This version of uucp is standard with System V Release 3
as it comes from AT&T and as implemented on the Motorola systems. I suggest
changing the makefile and define to something more like "hdbuucp" or something
like that. Of course, HDB is not restricted to System V releases, so the
"-D" for it should probably be seperate from any particular "make" target.
The "beware" file for C Kermit talks about a name confilict on "unchar" for
ATT 3Bx systems. This is really a System V Release 3 issue and is also
the case for the Motorola implementation. I tried the suggested fix, of
"-Dunchar=myunchar" in the makefile and, as expected, it didn't help. I
edited the files used for my build to change "unchar" to "myunchar". There
are other references to be changed for non-UNIX builds. The files I changed
for this were: ckcker.h, ckcpro.w, ckcfn2.c, and ckcfns.c.
System V Release 3 has re-defined the signal(2) system call as:
extern void (*signal())();
instead of:
extern int (*signal())();
This means that lines in ckudia.c, ckuusr.c, and ckuscr.c must be changed
to avoid illegal pointer combination errors. I just changed "int" to "void"
in each case. Better (more general) would be to use a typedef based on a
define, like "SVR3" (which might also cause the BNU locking code to be used).
The C compiler that comes with SVR3 is no longer so forgiving of random tokens
following preprocessor directives. Convention has been to do things like:
#if FOO
code
#else !FOO
other code
#endif FOO
This causes warnings on both the #else and #endif. Correct would be:
#if FOO
code
#else /* !FOO */
other code
#endif /* FOO */
Several places in ckutio.c had to be changed for this.
Also, ckcdeb.h includes some #include lines for "vax11c" which are not
of legal format. Even though they are bounded by #ifdef/#endif, the
pre-processor still sees them and barfs. I changed the conditionals
surrounding them to cause them to actually be commented out, if "vax11c"
were not defined. This problem could be construed to be a bug in the
C Pre-processor, but I don't have a copy of a current ANSI spec, so am
not sure.
Here are context diffs of the code changes I made. "orig" is the original code
as I received it. "save" is the code as I modified it to compile properly.
[Ed. - This message, and the diffs, have been added to CKUKER.BWR, and will be
looked at for the next release. Thanks!]
Ron Heiby, heiby@mcdchg.UUCP Moderator: comp.newprod & comp.unix
Motorola Microcomputer Division (MCD), Schaumburg, IL
"I am not elsewhere."
------------------------------
Date: TUE, 14 APR 87 14:34:41 GMT
From: ROGER @ UK.AC.TPB
Subject: Bugs in Sperry Univac Kermit
Keywords: Sperry Kermit, Univac Kermit
I recently acquired a copy of Sperry UNIVAC KERMIT written in assembler,
for use on a non front end site.
After a little tinkering , to get it to work with our setup , I discovered
a couple of little coding bugs. I must admit I'm not the world's greatest
programmer in @MASM, but I THINK (underline that in italics) I've sorted them
out:
There was a bug in the SHOW SEND routine that caused the SEND STARTOFPACKET
displayed to be the RECEIVE STARTOFPACKET, and a bug in the SHOW RECEIVE
routine that caused it to display the SEND STARTOFPACKET.
No prizes for guessing what had happened !!!!
The actual parameters in the SHOW list had been juxtaposed; simply
swapping over lines 2281 and 2300 in the original source should cure the
problem.
Another more serious problem was that when assembled with MDLFE=0 and
DCPFE=1, the code still expected to find a couple of entrypoints that
weren't there: they'd not been assembled because of a conditional directive.
My cure is rather elegant, but as I've no idea what I've done it may not be
the right one. All I did was to move the offending reference, in line 2613 to
only occur in the conditional directive immediately following it. that is line
2613 was inserted AFTER the IF MDLFE statement.
That seems to have cured it, it now @MASM's without errors, and @MAP's
without errors. I've succesfully used it in SERVER mode with a PC clone
running CROSSTALK, so I assume I've done the right thing.
If anyone else has any tips or points Id like to hear from them.
Jason LoCascio,
British Gas PLC
59 Bryanston Street
LONDON
W1
(01) 723-7030 ext. 1289
Or I can be contacted at THAMES POLYTECHNIC , via JANET :-
ROGER @ 000045399000.TPB.SPCP.FTP.MAIL
(We are not registered in NRS yet)
------------------------------
End of Info-Kermit Digest
*************************
-------
-------