info-kermit@ucbvax.ARPA (05/28/85)
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Info-Kermit Digest Mon, 27 May 1985 Volume 2 : Number 30
Departments:
C-KERMIT VERSION 4C -
More Changes to C-Kermit Version 4C
File Sizes Reported by C-Kermit
C-Kermit v4 to Apollo
C-Kermit 4C Comments/Bugs
C-Kermit on TRS-Xenix
Kermit 4C Broken "Dial" Command for PC/IX 1.1
C-Kermit 4C (16 May) Local-Remote Bug?
Status of 4C on 2.9bsd
Wart Mods
C-Kermit for Eunice
MISCELLANY -
Lisp Machine KERMIT
Kermit-11 BITnet Distribution: Correction
IBM PC/AT Serial Port Compatibility
AT Serial Port Compatibility
IBM Asynch Adapter at 19.2Kb and Beyond
Appeal to the Netherlands
Kermit for IAS?
IAS AND KERMIT
Need Help with Kermit-TSO and 7171
Converting New VM/CMS Kermit to MVS/TSO?
Kermit for the NorthStar horizon and USR S-100 modem.
Formatting documentation for Xerox 2700
Commodore 64 Kermit Diskette Availability
Kermit for Wang VS or OIS?
Two Faces of Kermit
----------------------------------------------------------------------
Date: Mon 27 May 85 16:41:12-EDT
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Subject: More Changes to C-Kermit Version 4C
Quite a few minor changes have been made to the working (but not yet really
released) copy of version 4C of C-Kermit. The major functional change is
that several of the 'set' parameters have been separated into 'set send'
and 'set receive' pairs to allow inbound and outbound packet parameters to
be set separately. Some changes have been made to the command parsing
functions -- the major result is that the multiline local-mode 'get' command
now works as advertised, and in addition can be escaped from if you change
your mind in the middle of it. Many minor bugs were fixed, some of which
are reported in the messages below.
Reportedly, problems still exist on ATT System III and System V based
systems in the areas of dialing, modem control, and so on. A special "3bx"
makefile option was added for ATT 3B-series systems to accommodate their
special handling of uucp lock files. Users of these System III/V systems
are encouraged to try out the new files and report problems (and fixes?), so
we can finally make version 4C "real".
The files are on CU20B, in <CKERMIT>CK*.*, as of 7:30pm EST 27 May 85. Only
the Unix and VMS versions have been affected by the recent changes; a new
Macintosh release should be ready shortly.
------------------------------
Date: Monday, 20 May 1985 08:26:04-PDT
From: d_schullman%sarah.DEC@decwrl.ARPA (Dan Schullman)
Subject: File Sizes Reported by C-Kermit
When SENDING a file, the displayed size of the file being sent is wrong.
It appears that 32kb-->63.99kb, 96kb-->127.99kb, etc. are shown as zero.
And that 64kb-->95.99kb, 128kb-->159.99kb, etc. are shown as ( size mod 64kb ).
The actual size of the transferred file is fine.
[Ed. - The problem is that zchki() returns the size of the file as its value,
but zchki() is not declared to be long. Also, it uses a regular int internally
to hold the size. The files ckufio.c, ckvfio.c, ckcfns.c, and ckucmd.c have
been changed to use longs where necessary, so that file sizes will look right
on machines that have short ints.]
------------------------------
Date: Sun, 19 May 85 15:48:00 pdt
From: Neal Holtz <holtz%cascade.carleton.cdn%ubc.csnet@csnet-relay.arpa>
Subject: C-Kermit v4 to Apollo
I finally got around to doing what I said I would in early March - port
C-kermit to Apollo (Aegis) environment. I waited for a newer version,
4.2(030).
As of this writing, I have only had it running for a few hours, so obviously
I have a lot of testing to do yet, but early results are very encouraging.
The standard Apollo C-library is very compatible with most Sys III (and some
4.2) -- the only exception is configuring serial lines and the console. I
probably could have added about 100 lines to ckxunx.c and ckzunx.c, but I
thought they were getting unmanageable with all the IFDEF's, so I made
equivalent ckxaeg.x and ckzaeg.c mostly by ripping out most of the compile
time control. There were couple of very trivial changes in a couple of
other places, but it went very smoothly. When I have had a chance to do
more testing, I will forward a few comments.
Currently, the TOPS-20 style command parser is being used. That doesn't fit
in with the Apollo environment as well as I would like (though it certainly
is usable). Haven't decide whether I will retain it. Will probably decide
to do whatever causes the least work and disruption (i.e. retain it).
Will gladly supply my changes to whoever wants them.
[Ed. - The modules other than ckufio (formerly ckzunx) and ckutio (formerly
ckxunx) that need modifications to accommodate Apollo Aegis now have them,
and the Apollo-specific modules will be announced when they arrive.]
------------------------------
Date: Wed, 22 May 85 09:55:41 -0100
From: hans@oslo-vax (Hans A. ]lien)
Subject: C-Kermit 4c Comments/Bugs
I had no trouble building v.4c on our vax 11/780 running 4.2bsd unix.
However, i have recognized a few problems / minor bugs. I must apologize
for not being very familiar with neither unix nor c, so I have no definitive
fixes to offer. But anyway:
1) It seems as some terminal output isn't printed to the terminal while the
file transfer is proceeding in the background. As a result, the process
stops waiting for terminal output.
First of all, there are messages of the kind "Warning: ...", which are
printed on stderr. I would very much appreciate that such messages be output
similarly to messages like "filename => FILENAME ...", WHICH come through
nicely.
[Ed. - These messages only appear at the start of a transaction, and they
are generally important enough that you should want to see them -- like,
"Warning, problem getting exclusive access", meaning that somebody else
might be using the same communication line at the same time. Once the
line is assigned to you, no further warning messages are issued.]
The other problem I have noticed, concerns indication of naks. They are
indicated by "N", but unlike ".", they demand the process in the foreground
to proceed. Once again, I think such output should be allowed to a job in
the background. Hopefully, this works OK if -q (quiet) is set, but I
haven't tried.
[Ed. - I can't reproduce this, nor can I find any code that seems to exhibit
this behavior.]
2) I have recognized a minor error in the Tops20-like command parser, which
results in repetition of default items by pressing several <esc> characters.
Try for example CKermit>log trans<esc><esc><esc><esc><esc>.
[Ed. - It was an error, all right. It's fixed now. Thanks for spotting it.]
3) Regarding command line options, my opinion is that a "bye" option should
be included, in addition to, or if the number of options should not grow
further, instead of the "finish" (-f) option. I think most people use such
an option to end a file transfer session, typically performed with a simple
list of commands making up a script. Does anyone (dis)agree?
[Ed. - The major restriction on the number of command line options is that
the command line help message should fit on one screen.]
hans@oslo-vax.arpa
Hans A. ]lien, Institutt for informatikk,
University Of Oslo, Norway.
------------------------------
Date: Tue, 21 May 85 16:04 MDT
From: RMark@DENVER.ARPA
Subject: C-Kermit on TRS-Xenix
I now have kermit 4C(044) running on TRS-Xenix, a Unix v7 system.
Both startup and file transfer are much slower than with kermit version 3.
The makefile parameters required are:
PROC=_proc
DIRECT=-DDIRECT
NPROC=_Nproc
BOOTFILE=/xenix
A fix was required in ckutio.c.
Robert Mark, USGS, Menlo Park, CA
[Ed. - Fix installed in ckutio.c, and the makefile (ckuker.mak) edited
accordingly.]
------------------------------
Date: Tue May 21 1985 14:11:11
From: Marco Papa <papa%usc-cse.csnet@csnet-relay.arpa>
Subject: Kermit 4C broken "dial" command for PC/IX 1.1
I encountered the following problems with installing and running Kermit 4C
for PC/IX 1.1 on a PC/XT with Hayes compatible modem.
1. Makefile problem.
PC/IX's "make" does not seem to like \'s to continue lines.
Taking out the \'s at the end of lines, and making one long line, fixes it.
[Ed. - A warning to this effect has been inserted in the .bwr file, but it's
funny we didn't here this one before, especially since a lot of development
was done on a PC/IX system.]
2. Dial feature broken.
The "dial" command does not work any more. Executing the following set of
commands:
> set line /dev/tty1
> set speed 1200
> set modem-dialer hayes
> dial 743-0000
will work up to the setting of the modem type. The dial command ALWAYS
returns with the message:
"Sorry, can't hang up the line"
I have not looked up in ckdial.c yet, but I believe the message comes from
there. I know that there is no problem with my modem switch settings,
since Kermit 4.2 runs just fine. Also, since dial does not work, I cannot
test the script command.
[Ed. - This has been fixed. There are still reportedly problems with DTR
during dialing on some systems.]
3. Lock file left around.
This is related to the "dial" problem above. When dial fails, the "exit"
command leaves the lock file around (/etc/locks/tty1 for example), so that
one has to manually delete it, before set line will work again. The lock
file is correctly deleted on exit, when dial is not executed.
Connect, send and receive seem to work just fine.
[Ed. - The ttopen() code in ckutio has been reworked to be more careful
about leaving lock files around.]
Also, ckuus2.c makes the C optimizer run out of space under PC/IX.
Marco Papa
UUCP: ...!sdcrdcf!uscvax!papa
CSNET: papa@usc-cse.csnet
ARPA: papa%usc-cse@csnet-relay.arpa
------------------------------
Date: Sat, 25 May 85 11:29:07 pdt
From: rag@uw-june.arpa (David Ragozin)
Subject: C-Kermit 4C (16 May) local-remote bug?
Running C-kermit, 4C (16 May) on 4.2 BSD Unix.
Problem:
Issue "set file type bin"
Then "send file" and on completion do "show para"
mode now shows as "local" instead of "remote"
Now when I get mode back to remote by "set line", then do a send of a text
file, on return the mode is local. Apparantly going into binary file mode
flips some flag which controls the mode setting on returns from at least the
send type transaction.
[Ed. - Oops - this bug was introduced into 4C (the 16 May version) and has
just been fixed. It actually had nothing to do with binary mode.]
(By the way, I could find no way to "document" this via any of the log
functions, since the "session logging" only works for local mode logging
while this bug requires that I record what appears on my screen from a
remote kermit.)
[Ed. - Try "kermit | tee xxx" -- the transcript will go into file xx. Or use
script on systems that have it.]
------------------------------
From: Paul Graham <unr70!unrvax!pjg@seismo.ARPA>
Date: 23 May 1985 1218-PDT (Thursday)
Subject: Status of 4C on 2.9bsd
As I suspected in my heart of hearts the transition from the 7th Ed. is not
going to quite as simple as I might have liked. Currently the 2.9 version
will not act as server or in the remote mode. Nor will it receive files in
the local mode (it will get a file from a server).
If anybody has solved all of these problems please let me know. Else
sometime next week it should percolate to the top of the stack, and I should
have some time for it once again.
Please drive carefully.
Paul Graham 702/784-6007
University of Nevada Reno
UUCP (seismo, ucbvax!menlo70)!unr70!unrvax!pjg ARPA unr70!unrvax!pjg@seismo
------------------------------
Date: Sat, 25 May 85 18:24:36 cdt
From: knutson@ut-ngp.ARPA (Jim Knutson)
Subject: WART mods
The following are a couple of context diffs for getting wart running on an
MS-DOS machine with the CI-C86 C compiler. The problems that were fixed
had to do with 1) not ignoring trailing text on #else and #endif 2) Stripping
comments within quotes and 3) not recognizing \f as a whitespace.
[Ed. - diffs omitted, changes installed in ckwart.c.]
------------------------------
Date: Wed, 22 May 85 23:01 EST
From: Larry Afrin <lbafrin%clemson.csnet@csnet-relay.arpa>
Subject: C-Kermit for Eunice
I don't remember if I explained this in an earlier message, but Eunice 3.2 is a
hybrid of 4.1bsd and 4.2bsd (with a touch of Version 7 thrown in, from what I
can deduce from how the time-of-day functions work), that runs under VMS.
A new version of Eunice, version 4.0, is coming out "VERY soon", sort of in
conjunction with the brand new release of VMS 4.1. Eunice 4.0 is reputedly
going to be a full 4.2bsd implementation under VMS. Now, seeing as how Kermit
4C can be installed under VMS directly, and seeing as how Eunice 4.0 is
supposedly going to be 4.2bsd straight up and down the line, you may want to
defer from adding any Eunice-specific support into the next Kermit version,
which I understand from you will be version 4C. You may especially want to
avoid using *my* mods since they're meant for Kermit 4.2, which I think you've
indicated is now obsolete, sort of.
-- Larry Afrin
Dept. of Computer Science
Clemson University
lbafrin@clemson if you're on CSNet
lbafrin.clemson@csnet-Relay if you're on ARPANet
[Ed. - I agree with Larry -- Eunice support is probably not worth including.
This is very much the same situation as Amdahl UTS, whose new version is pure
system V, and whose old version is some kind of hybrid. If anyone is desparate
for Larry's Eunice Kermit, they may want to contact Larry directly.]
------------------------------
Date: Fri, 24 May 85 14:53 CDT
From: "Mark L. Ahlstrom" <Ahlstrom@HI-MULTICS.ARPA>
Subject: Lisp Machine KERMIT
I now have the Lisp machine Kermit running "pretty well" on
Symbolics Lisp machines. I should be shipping it back to George
Carrette at LMI in a couple of weeks to have him retest it on LMI Lisp
machines and incorporate some recent LMI changes. Hopefully, the first
release to Columbia is within a couple months of being "real".
By the way, your information should be updated to show that the lmkermit
will be written in Zetalisp rather than Common Lisp. The info that it
was Common Lisp evidently came from an earlier plan that George Carrette
had to develop the code on another machine.
--Mark
------------------------------
Date: 21 MAY 85 10:46-EST
From: BRIAN%UOFT02.BITNET@WISCVM.ARPA
Subject: Kermit-11 BITnet Distribution: Correction
I just noticed that I said UOFT01 KERMSRV in my note about getting the
new Kermit-11. It should have been UOFT02 KERMSRV. See Kermit Digests
numbers 2-21 and 2-26.
------------------------------
Date: 15 May 85 06:52:09 GMT
From: Pat Chewning <patch%nsc-pdc.uucp@brl>
To: Info-IBMPC@USC-ISIB
Subject: IBM PC/AT Serial Port Compatibility
I am having trouble with my AT receiving serial data at baud rates over
1200. I suspect that it has something to do with the incompatibility of the
serial controller used on the AT versus the PC. Here's the set-up:
IBM AT
AST ADVANTAGE! multifunction board that has the serial port.
(Uses 16450 chip?)
Kermit Software (Also tried-out a copy of Crosstalk with same results)
[Both these software packages were written for PC]
Using the same physical RS232 line, I have no problem doing data transfers
at 9600 baud using a Compaq [IBM PC Clone].
The problem shows up at baud rates greater than 1200 (although occasionally
at 1200 baud as well). The characters are not wrong, but the problem is
missing characters. Transmitting characters works fine, its only on
receiving that I have a problem.
The manual that came with my serial card indicates that some incompatibility
exists between the serial controller chip used in the AT and the controller
chip used on the PC. It suggests that some software written for the PC may
not operate properly on the AT.
Does anyone know what those differences are, and in particular, what
specific changes need to be made to Kermit [I have a source] so that it will
work on the AT?
Pat Chewning
[Ed. - See below.]
------------------------------
Date: 16 May 1985 10:22:14 PDT
Subject: AT Serial Port Compatibility
From: Richard Gillmann <GILLMANN@USC-ISIB.ARPA>
Sounds like you have the Professional Graphics display. This has the
unfortunate effect of interfering with the serial ports at speeds over 1200
baud.
------------------------------
Date: Thu 16 May 85 13:57:53-EDT
From: Charlie C Kim <US.CCK@CU20B>
Subject: IBM Asynch Adapter at 19.2Kb and Beyond
Using an interrupt based system, as has been indicated, it is definitely
feasible to run the IBM serial card at speeds greater than 9600 baud. (In
fact, you'll probably need an interrupt based system at any speeds above
1200 or so). On an AT, I've been using Kermit, which is interrupt driven
for the serial IO, for file transfer to and as a remote terminal for a 4.2
Unix system (Vax 750 with DMF's--the DMF is a serial/parallel board for the
VAX which has a maximum speed ot 19.2KB on serial lines) at 19.2KB without
any problems. I've also tried it at 56KB between two PC's (one AT, one
PC-1) and between a PC-AT and Macintosh without any problems.
I've also be able to use the COM_PKG/INT_PKG pair in the IBMPC library to
communicate from a PC-AT to the above mentioned VAX at 19.2KB; again
without any problems.
So, empirical evidence supports the results. As as side note, I should
note that I've used communications packages which were incapable (on a
PC/XT) of going above 1200 baud without losing characters; I suppose these
were not interrupt driven.
Charie C. Kim
Columbia University
Center for Computing Activites
------------------------------
Date: Thu, 23 May 85 14:26:27 BST
From: Cjk@ucl-cs.arpa
Subject: Appeal to the Netherlands
To anyone in Holland (= The Netherlands):
Is there anyone in the Netherlands running Kermit who could help
me by providing a mainframe Kermit for demonstration purposes?
This would be to demonstrate that a micro-Kermit actually works.
If so, please mail me soonest as "cjk @ ucl-cs", on either ARPA
or JANET.
Chris Kennington.
------------------------------
Date: 24 MAY 85 14:50-N
From: DEGROOT@HWALHW5
Subject: Kermit for IAS?
1. Some users keep asking for a KERMIT version for the operating system
IAS on the PDP11. I understand that IAS is an obsolete operating
system. Previous KERMIT-versions for RSX could be generated for IAS.
The current versions of PDP11 KERMIT give not any notice of IAS.
Is there a KERMIT for IAS?
[Ed. - There is some hope that Kermit-11 will be adapted to IAS. There is
at least one very large IAS site that has indicated some willingness to do
this, but there is no definite commitment or timetable -- see below.]
2. The file CURRENT.DOC indicates version 3(124) for K10-KERMIT.
The right version number for the DEC10-KERMIT should be 2(124).
[Ed. - Thanks for pointing out the mistake.]
Kees de Groot (DEGROOT@HWALHW5)
Computer Centre
Agricultural University
Wageningen
The Netherlands
------------------------------
Date: 24 MAY 85 09:30-EST
From: BRIAN%UOFT02.BITNET@WISCVM.ARPA
Subject: IAS AND KERMIT
I just got a call yesterday from the EPA about IAS and Kermit. They
have some 30 systems running IAS version 3.1 and have volunteered to
port it to IAS. The main problem with IAS is that RMS-11 version 2 is
only supported on IAS 3.2, which many sites seem to have decided not to
install. I expect that these folks at the EPA will have Kermit-11
running on IAS soon, so I would suggest that others interested in IAS
Kermit to wait a couple of weeks until I get more info on the progress.
------------------------------
Date: Fri 17 May 85 19:34:39-PDT
From: Wing Lee <WingLee%ECLD@ECLA>
Subject: Need Help with Kermit-TSO and 7171
I am experiencing a problem with the Series/1 version of TSO-KERMIT. It
works fine with the Series/1, but here at USC we are replacing the Series/1
with an IBM 7171. I am having problems trying to upload files through the
7171. I am able to download files just fine, but when I upload, TSO-KERMIT
stops at the first bad packet. I used the debug option on TSO-KERMIT and
when I looked at the debug file, it shows that TSO-KERMIT stops right after
a CHECKSUM error. It appears that TSO-KERMIT is unable to notify the micro
KERMIT that it has received a bad packet and have the micro resend it, and
since the micro KERMIT hasn't received an acknoledement from TSO-KERMIT
telling it to that the last packet was good, a transmission lock up occurs.
I've tried everything I can think of to solve this problem, and would
appreciate any suggestions you can think of.
Thanks
Wing Lee
University Computing Services
University of Southern California
[Ed. - This is presumably the Version of TSO Kermit whose genealogy is
Columbia VM/CMS Kermit v 1.0 -> U of Chicago MVS/TSO support -> U of Toronto
Series/1 support. Anyone else out there using it? Also, see next message.]
------------------------------
Date: Mon 20 May 85 16:26:52-EDT
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Subject: Converting New VM/CMS Kermit to MVS/TSO?
To: Ron Rusnak <SYSRONR@UCHIVM1.BITNET>
Hi Ron -- Do you think anybody at U of Chicago will be working on TSO Kermit
any time soon? Ideally, I think it would be good if the new CMS release
(2.00, which has server mode, binary file transfer, CRC's, etc) could have
TSO support added to it in such a way that either TSO or CMS Kermit could be
built from it. I don't know much about IBM assembler, but I would hope that
this would be possible using macros or conditional assembly for the system-
dependent parts. This would simplify life a lot for both of us, not to mention
the hundreds of sites that are running TSO &/or CMS Kermit, allowing each
to benefit immediately from improvements in the system-independent areas.
What do you think? - Frank
[Ed. - I never got a reply to this, but maybe someone else who might be
interested in TSO Kermit -- U. of Toronto, maybe? -- would be willing to take
on the task.]
------------------------------
Date: Sun 19 May 85 19:49:20-MDT
From: Jon Albers <JALBERS@SIMTEL20.ARPA>
Subject: Kermit for the NorthStar horizon and USR S-100 modem.
To: northstar-users@SIMTEL20.ARPA, info-cpm@AMSAA.ARPA, info-kermit@CU20B.ARPA
I am looking for a version of Kermit that will work on a Northstar horizon
with either the second printer port, or better yet, the US Robotics S-100
internal modem. If you have or know of such a beast, or can perhaps give
some help with writing the code to make Kermit work with an S-100 modem
board, please reply to me at the below addresses:
Jon Albers
ARPA: JALBERS@SIMTEL20
/..seismo!dolqci!irsdcp!albers
UUCP: ---------<...seismo!dolqci!irsdcp!dcp1!albers
\..philabs!sbcs!bnl!bnl44!jalbers
------------------------------
Date: Sat 18 May 85 23:01:53-PDT
From: Bob Larson <BLARSON%ECLD@ECLA>
Subject: Formatting documentation for Xerox 2700
I had problems formatting the kermit documentation for our xerox 2700 also.
The verbatim portions of the manuals have lines to long to print at 10 cpi
with the default margins used for the 2700. By making sure that all verbatim
areas were printed at 12cpi, and modifying "italics" to do underlining
(the only italic font we have is 10cpi) I was able to format the manual
so only a few characters where lost.
It might work if formatted with a one character left margin.
Hope this helps.
Bob Larson <BLarson@Usc-Ecl.Arpa>
------------------------------
Date: Tue, 21 May 85 03:02:17 edt
From: Robert Scott Lenoil <lenoil@mit-eddie.ARPA>
Subject: Commodore 64 Kermit Diskette Availability
Enclosed is the text of my message to USENET, re: my ability to
supply Commodore 64 Kermit diskettes this summer. Please update the
00readme.doc file and the information that you give out over the
phone to reflect this new status. Note that my work phone number this
summer will be (206) 828-8080, effective June 1.
Subject: Kermit diskette availability
Newsgroups: net.micro.cbm
Distribution: net.micro.cbm
As you may know, I have been providing copies of Commodore 64 Kermit for
$7.00 as a service for those who couldn't otherwise obtain the program.
However, I will be leaving shortly for the summer and have decided not to
take my Commodore with me. Therefore, I do not anticipate being able to
fulfill any orders until my return August 25th. There is always a
possibility that I find somebody at work with a 64, so if you do need a
diskette, send me netmail, and I'll let you know if I can accommodate
you. (Send to this address - my mail will forward).
Robert Lenoil
lenoil@mit-eddie.uucp
lenoil@mit-eddie.arpa
lenoil@mit-mc.csnet
------------------------------
Date: Friday, 17 May 1985 14:26-MDT
From: ritcv!husky!pma%rochester.uucp@Seismo
Subject: Kermit for Wang VS or OIS?
Does any one know of a "kermit" for a Wang(tm) VS or OIS system ?
Please respond to me by email.
Thanks,
Philip Abram, Eastman Kodak Co., Rochester, N.Y.
PATH:
{allegra,seismo}!rochester!ritcv!-------\
>------husky!pma
{eagle,astrovax,netword}!sun!sunrise!----/
------------------------------
From: tektronix!stever@Berkeley
Date: Tuesday, 21 May 85 13:01:22 PDT
Subject: Two Faces of Kermit
Kermit is both a protocol and a communications program. One should not
ridicule people for their confusion about this point.
All communications programs whether commercial or not should be able to do
*raw* (i.e. ASCII) data file transfers using system level commands of the
computer they are talking to, as well as supporting one or more file transfer
protocals.
Kermit should not be an exception. This feature should be a part of the Kermit
protocal definition. Kermit implementations should not be included in the
distribution system of Kermit software unless they have the *raw* file transfer
function.
steven d. rogers
...ucbvax!tektronix!stever
[Ed. - In principle, I agree. In practice, Kermit programs are donated by
individuals who are free to implement whatever features they like, so long as
the minimum protocol features are present. We're not going to turn down
desparately needed contributions (we know when a Kermit implementation is
desparately needed when the number of phone calls asking about it exceeds
a hundred per day) because they lack a particular optional feature.]
------------------------------
End of Info-Kermit Digest
*************************
-------