SY.FDC@CU20B.COLUMBIA.EDU (Frank da Cruz) (11/27/85)
Info-Kermit Digest Wed, 27 Nov 1985 Volume 3 : Number 31
Departments:
ANNOUNCEMENTS -
PDP-11 Kermit Now Available for IAS 3.1
Kermit in C for DG MV Series with MV/UX
New Release of Burroughs B7900 Kermit
Another Kermit for Intex RMX Systems
VMS Hexify/Dehexify Fix
IMUSIC - MUSIC Kermit w/7171 support
UNIX KERMIT -
More notes on C-Kermit 4C(057)
More on Masscomp Running C-Kermit 4C(057)
Zilog Zeus Kermit, Os9 Kermit Warning
Problems with MacKermit for the Macintosh version 0.8(33)
MS-DOS KERMIT -
MS-DOS Kermit V2.28
Hardware Upgrade for some Professional Graphics Controllers
ROMing MS-DOS Kermit
MISCELLANY -
ETX/ACK Flow Control?
Problem Downloading Files with Apple II Kermit
----------------------------------------------------------------------
DATE: 25-NOV-1985
FROM: BRIAN@UOFT02
SUBJECT: PDP-11 Kermit Now Available for IAS 3.1
This is to announce that a version of Kermit-11 for IAS 3.1 is available.
Due to source incompatibility, only the task image and hexified task image
will be made generally available. The complete sources will be archived at
UOFT02 in directory KERIAS: available from dialup access, and a copy of the
sources will be sent to Frank when I send the K11 update the first week of
December. Doc and HEX files are in KER: as K11I31.* and KERBIN:K11I31.TSK.
Many thanks to Gene Costello and Bruce Wright of the EPA for this version of
Kermit-11.
Brian Nelson
[Ed. - This was the last current DEC operating system that did not have
a Kermit program -- now they all do. The hex, odl, cmd, and doc files are
in KER:K11I31.* on CU20B.]
------------------------------
Date: Wed, 27 Nov 85 09:44:53 est
From: John Sambrook <uw-beaver!entropy!gandalf>
Subject: Kermit in C for DG MV Series with MV/UX
This is a Kermit for Data General MV Series computers. In order to use this
Kermit you need the MV/UX product installed on top of your AOS/VS system.
If you don't have the MV/UX product but do have Data General's C compiler
you can modify the source to eliminate all calls to the UNIX emulator.
While this should not be too difficult, it will require some work. I would
have done it for you but my schedule is just too tight.
If you don't have a C compiler feel free to translate this to another language.
Note that you will need to provide a multitasking environment.
This version of Kermit was created from an older version of Kermit. It may or
may not be up to date. It was tested at our site with a Kermit on a 4.2BSD
system and seemed to work fine. As our site is moving to native UNIX (DG/UX)
we will not be using this Kermit for very long. I will answer questions about
this version as my schedule permits.
John Sambrook
Department of Bioengineering WD-12
University of Washington
Seattle, Washington 98195
Work: (206) 545-2018
UUCP: uw-beaver!entropy!gandalf
[Ed. - Thanks! The files are in KER:DGM*.* on CU20B, available via
anonymous FTP. The program is based mostly on the old Unix Kermit.]
------------------------------
Date: 24 Nov 85 09:44:53 est
From: J.M.H. Smeets, Technische Hogeschool Eindhoven (THE), Netherlands
Subject: New Release of Burroughs B7900 Kermit
Enclosed is a tape containing our final implementation of Kermit for
the Burroughs B7900. It includes file compression and binary transport.
[Ed. - The program, which is written in Burroughs Algol, is available on
CU20B as KER:B79*.*.]
------------------------------
DATE: 85/11/25
FROM: 3GTLBTL@CALSTATE.BITNET
SUBJECT: Another Kermit for Intex RMX Systems
I'm releasing RMXKERMIT this week. I'll get a tape off to you as soon as I can
get DP to do it. Our campus bookstore will send out 5 1/4" DSDD RMX format
disks for $6/disk. Disk 1 contains the executable program & documentation.
Disk 2 contains source code for those who want it. Orders can be sent to:
University Bookstore
6049 E. 7th St.
Long Beach, CA 90840
Attn: Lyle Bartlett
[Ed. - This yet-another-RMX-Kermit will be announced again when it shows up
at Columbia. This one differs from the others in being an adaptation of
MS-DOS Kermit, rather than a PL/M implementation.]
------------------------------
Date: 29 Oct 85
From: Andrew L. Burke, Tektronix MS 63/196, Wilsonville OR 97070
Subject: VMS Hexify/Dehexify Fix
Here are fixed versions of the VMS HEXIFY and DEHEXIFY programs. While
these programs worked correctly on small files (files with less than 65535
lines, or thereabouts), failed on large files. The problem was as follows:
the programs both used a longword (four bytes) internally to record the
current line number while reading/ writing the hexified file. However, both
only read/wrote a word (two bytes) to/from the hexified file. So, when it
came time for the VMSDEH program to read a line past the 65535th, it found
that the line number had wrapped back to line one. This causes prolems
because the program uses the line index to decide whether to expand
compacted nulls or not, and when it found the next line index not equal to
the current plus the current line length, it starts writing out nulls
(counting from 65535 to 1, or therabouts...). To make a long story short,
it didn't work. The fix is simply to read and write a longword. The other
modification is to VMSDEH is that it reports an end of file error when it
finished reading the hex file.
[Ed. - The fixed versions replace the old ones as KER:VMSHEX.MAR and
KER:VMSDEH.MAR on CU20B. This came up because Tektronix is including Kermit
with its TekniCAD product on its 4100 series systems with CP/M-86.]
------------------------------
Date: Sat, 23 Nov 1985 18:06 CST
From: John Voigt - Systems Group Tulane <SYSBJAV%TCSVM.BITNET@WISCVM.ARPA>
Subject: IMUSIC - MUSIC Kermit w/7171 support
We have discovered a bug in the new version of KERMIT for MUSIC which
supports the 7171 and Series/1 protocol converters. This bug does not
always seem to cause a problem but it should be fixed in your code. The
error is a result of a non-initialized control block field when sending
the first packet. If you are trying to use this version of KERMIT with
the 7171 and you get a message FSIO ERROR - 0B1000 then this fix should
correct the problem.
In routine INTRINI find the following lines: (near line number 2565)
LA R1,RECPKT
ST R1,KERMFSRB
add the following lines after the above two:
LA R1,L'RECPK2 GET LENGTH OF INITIAL SEND PACKET
ST R1,KERMFSRL SET RECORD LENGTH IN CONTROL BLOCK
This should correct the above error.
We have also found that if the terminal is defined to MUSIC as a "B" model
(with APL graphics characters) the 7171 will incorrectly translate data
causing KERMIT to fail altogether. This is a permanant restiction and
should be noted in a BWR file.
[Ed. - Noted, along with above fix.]
Also, in answer to several questions from other MUSIC sites, I would like
to let everyone know that KERMIT is running on MUSIC/SP without any
modifications so if you are considering a software upgrade it should not
cause any proplems for your KERMIT users.
------------------------------
Date: Sun, 24 Nov 85 04:16:02 CST
From: Stan Barber <neuro1!sob@rice.ARPA>
Subject: More Notes on C-Kermit 4C(057)
One more suggestion:
I would provide some mechanism to allow SYSIII compatible sites to
configure what signal that might like to use to allow the child and
parent to notify each other of problems. At my site, SIGUSR1 can not
be used by kermit, so I modify ckucon.c by replacing SIGUSR1 with
SIGUSR2. That fixes everything just fine.
At least a warning should be noted somewhere (in the .bwr file, I guess)
so that people will know to change it.
Alternatively, I would suggest a unique name (SIGKERMIT) that the
installer can define in the makefile (e.g. -DSIGKERMIT=SIGUSR2) to
keep people from mucking in the source file.
------------------------------
Date: Sun, 24 Nov 85 23:07:42 CST
From: Stan Barber <neuro1!sob@rice.ARPA>
Subject: More on Masscomp Running C-Kermit 4C(057)
There is one more difference that masscomp users should check if they make
Ckermit. Using the masscomp FIONREAD (when in connect mode) my cause characters
to be dropped. Using myread generally works better. This is certainly true if
the masscomp has the imux or jmux installed on it. It may not be true with the
new HPSMux installed. We don't have one yet, so I don't know.
In any case, I suggest a line for masscomp be added to the makefile of this
form:
rtu:
make wermit "CFLAGS= -UFIONREAD -DUXIII -DDEBUG -DTLOG -O" "LNKFLAGS ="
[Ed. - Thanks Stan, both your messages have been added to the .BWR file, and
are on the list for the next release.]
------------------------------
Date: Tue Nov 26 11:45:41 EST 1985
From: dolqci!irsdcp!scsnet!sunder@seismo.CSS.GOV
Subject: Zilog Zeus Kermit, Os9 Kermit Warning
I am the contributer of the Zilog Zeus support for C-Kermit. Kermit WILL NOT
WORK with the newest version of the Zeus operating system, i.e. 3.21. We have
gotten C-Kermit to run under this new release but we had to rewrite ckutio.c.
Do you want us to submit this new mod?
[Ed. - Sure, especially if the new ckutio.c also works with the old release
of Zeus. Or do we have to have two separate compile-time options for Zeus
systems?]
Also we think(!?) we have found two bugs in ckermit. One is in ckcpro.c. In
this module, C-Kermit sends an initial NAK to the other system rather than
waiting for the other side to make the first move. We simply commented this
line out and now C-Kermit will talk to older Unix kermits. Could this be made
public so that C-Kermit can be made a little more universal? Some systems may
never be able to port C-Kermit (ala Os-9 Level I) and need to be able to talk
to C-Kermit. Can this be done without losing any other comapatibility?
[Ed. - Are you talking about when C-Kermit is given the RECEIVE command,
or the SERVER command? In the former case, I don't see how we can get
around sending NAKs -- if the expected first packet doesn't come, Kermit
has to NAK it, in case it was lost on the way and the sender of it doesn't
do timeouts. If your local Kermit does timeouts, you can turn C-Kermit's
timer off all together with SET RECEIVE TIMEOUT 0. In the latter case,
you're right, there should be a SET SERVER TIMEOUT command to turn off the
periodic NAKing function of the server, but still let it time out during
a protocol transaction. Something like this should appear in a future
release.]
The 2nd bug is in ckutio.c In this mod, ckermit waits to get the other
side's eol char but then ignores it and expects its own: see the following
#ifdef ZILOG
seol = (len-- > 0) ? unchar(data[4]) : '\r'; /* Terminator */
if ((seol < 2) || (seol > 037)) seol = '\r';
#else
eol = (len-- > 0) ? unchar(data[4]) : '\r'; /* Terminator */
if ((eol < 2) || (eol > 037)) eol = '\r';
#endif
the ifdef ZILOG is our correction. It was our experience that C-Kermit
would not work with any system that did not use <CR> as eol or would
convert eol to <CR>. Hope this helps!
[Ed. - Thanks.]
------------------------------
Date: 26 November 1985, 08:43:52 CST
From: Tim Klosowski, Argonne National Laboratory <B34885@ANLVM.BITNET>
Subject: Problems with MacKermit for the Macintosh version 0.8(33)
I have been testing version 33 of the Kermit program for the Macintosh
computer prior to its release to our users. I have encountered no problems
using the program on a 9600-baud X.25 line hookup to our IBM 3033 mainframe.
The problems surfaced when using a 1200-baud line. I found three cases
during the course of my testing.
FIRST, normal execution and normal completion.
The file transferred sucessfully, the message stating this appeared and, after
a mouse-click, returned to the KERMIT-CMS prompt.
SECOND, normal execution and abnormal completion. The file transfers
successfully and the message appears. Instead of the KERMIT-CMS prompt
after a mouse-click, the program displays odd characters (such as %B..) and
necessitates several carriage returns to get action on the screen. The
characters continue until a file transfer error message appears followed by
the KERMIT-CMS prompt. The error message states that the transfer did not
complete, but closer examination indicates that the files did indeed
transfer successfully.
THIRD, abnormal execution and completion. The program stalls after a few
packets are transferred. The emergency exit is the only recourse.
The first case is what should ideally happen. The third is a known problem
(occurring after an emergency exit is invoked). The one that truly puzzles me
is the second. If this is a known problem or if there is something I can do to
eliminate the problem, please let me know.
[Ed. - Thanks for your report. I think that problem #2 has something to do
with closing down the line before the acknowledgement of the B (Break
Transmission) packet has been completely sent. This would only occur during
uploading, and can be cured by using an even longer delay between sending
the ACK and closing the line. It could also occur if this final ACK were
lost for some reason; again, a delay could cure this too. The problem
should be fixed in the next release.]
------------------------------
Date: Monday, 25 November 1985 13:46-MST
From: Dick McGee (MMW) <dickmc@BRL.ARPA>
Subject: MS-DOS Kermit V2.28
Has anyone successfully ported kermit v2.28 to a Z100? I fixed the reported
bugs in the source code and assembled it. I can upload and download with it
okay. If I do a DIRECTORY, PUSH, SPACE or any command that temporarily exits
to DOS it goes into the twilight zone and I have to hard reset. I'm running
MS-DOS 2.18.
I'm quite satisfied with the 2.26 version of Kermit, but since like
Mt. Everest, version 2.28 was there I thought I would try it.
s/Richard McGee dickmc@BRL.ARPA
[Ed. - Sounds like another casualty of version 2.28's new dynamic memory
allocation. Did you use the /S switch on the assembler?]
------------------------------
Date: 17 November 85 15:46-PST
From: Don Pelton (415) 854-3300 x2901 <DEP%SLACVM.BITNET@WISCVM.ARPA>
Subject: Hardware Upgrade for some Professional Graphics Controllers
[Ed. - Excerpted from a posting on Info-IBMPC.]
If you have bought, or plan to buy, IBM's Professional Graphics Controller
and Display, you may be interested in this. Several of us who bought this
board early this year discovered, through some painstaking research, that
there was a hardware bug on the board that caused it to interfere with ANY
terminal emulation program making use of the asynch port.
The old PGC cards have the numbers 6323697 and 6323698 on the top left of
the memory card. The new cards have these two numbers inked out and the
number 6448811 replaces them. The two old numbers are not always inked out
and if your board has the 6448811 number, you have a new board.
------------------------------
Subject: ROMing MS-DOS Kermit
Date: 25 Nov 85 10:38:57 EST (Mon)
From: jcmorris@mitre.ARPA
[Ed. - This message picked up from Info-IBMPC in response to a query from
ad0r@cmu-cc-te about installing Kermit ROMs in IBM PCs...]
It's probably not worth it. If you are willing to forgo the file upload/
download functions of KERMIT and use it to emulate a dumb terminal, it
shouldn't be too difficult to replace the screen and keyboard interfaces
with BIOS calls (I think that KERMIT uses DOS calls for these functions,
but I don't have the code at hand).
If you do this, why bother with KERMIT? There are several other packages
around which provide X3.64 interfaces; the real advantage to KERMIT is the
popularity of its file transfer capabilities.
If you want the file transfer capabilities, on the other hand, you will
have to write your own file subsystem and burn it on the PROM. For all
its faults, DOS does provide a mechanism for device-independent disk
access. Unless you are going to dedicate significant staff time (spelled
with dollar signs) to the project, you will wind up with a package which
will support only a few device types.
I see occasional articles in the press which describe central-server systems
where the node PC's have no hard disk (or sometimes no DASD at all). The
nodes, when booted, go to the central server for their copy of DOS; this
might be a better technique for you.
Ciao.
Joe Morris (jcmorris@mitre)
------------------------------
Date: Thu 21 Nov 85 11:11:21-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: ETX/ACK Flow Control?
Does anybody know what ETX/ACK flow control is, and what systems use it?
Is it like XON/XOFF, or ENQ/ACK, or is it something completely different?
------------------------------
Date: 24 Nov 85 00:07:26 GMT
From: Jeff Hollingsworth <hollings%ucbcory.ucb-vax.arpa@brl.arpa>
Subject: Problem Downloading Files with Apple II Kermit
I am having trouble using kermit to transfer files between an Apple IIe, and
UNIX. When I try to send files from UNIX to my Apple, all occurences of the
"&" (ascii 38) character are removed. This happens in both the image and
text mode. However, all goes ok when I transfer a file from the Apple TO
UNIX. Does anyone have an idea what is happening. The Apple has a Super
Serial card if that helps.
Thanks in advance.
Jeff Hollingsworth UUCP: ucbvax!cory!hollings
ARPA: hollings%cory@ucbvax.BERKELEY.EDU
AT&T: (415) 653-3723
[Ed. - Sounds like the two sides are not agreeing about 8th-bit prefixing.
The Apple thinks it's doing it, Unix doesn't. You didn't say what versions
of Kermit you're running, so the problem may be fixed by now. In any case,
you might be able to work around it by saying SET PARITY ODD on both sides
to force 8th-bit prefixing.]
------------------------------
End of Info-Kermit Digest
*************************
-------