SY.FDC@CU20B.COLUMBIA.EDU (Frank da Cruz) (03/22/86)
Info-Kermit Digest Fri, 21 Mar 1986 Volume 4 : Number 19
Today's Topics:
New C-Kermit Release Available for UNIX and VMS
Printable Encodings for Binary Files
Re: Printable Encodings for Binary Files
Kermit & Telebits
Sperry 1100 Kermit
Spooling Prints from an IBM/PC?
Re: Spooling Prints from an IBM/PC
Problems with Kermit on SCO Xenix V
MS-DOS Kermit on ATT 6300 vs VMS Kermit?
----------------------------------------------------------------------
Date: Fri 21 Mar 86 11:11:21-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
To: Info-Kermit@CU20B, info-unix@brl-sem
Subject: New C-Kermit Release Available for UNIX and VMS
This is to announce a new release of C-Kermit. It is only a minor release,
and incorporates no new functionality. The only intention is to fix the
more serious bugs. Future releases will involve more serious reworking of
the code to improve organization and performance, and to add missing features,
like extended packets, sliding windows, and attribute packets.
The new release is called 4C(058), for UNIX and VMS. The fixes that
apply to all (or most) systems supported by C-Kermit include:
. Bug with set send/receive padding fixed.
. Bugs that interfered with wildcard sends fixed.
. Bug that mixed up send and receive packet terminators fixed.
. Bug with single-file cancellation (^F or ^X) fixed.
. NAK for next packet now handled correctly as equivalent to ACK for current.
. NAK is no longer immediately sent after RECEIVE or SERVER command given.
. Long bursts of incoming data no longer crash the program.
. Longer sleep done at end of file transfer to prevent other side from hanging.
. ^S removed from among CONNECT escape character arguments.
. Dial pause of 0 no longer causes problems.
The fixes specific to UNIX include:
. Fixed support for 2.9 BSD (tested on DEC Pro 380).
. New makefile entry for Masscomp (untested).
. Some 0's in system calls changed to NULLs.
. SET SEND/RECEIVE TIMEOUT 0 no longer prevents file transfer from working.
VMS changes (untested):
. '!' should now spawn an interactive DCL.
. REMOTE commands to VMS C-Kermit server should now work.
The new version of Macintosh Kermit that is based on C-Kermit is not ready
yet because it's too big for our SUMACC cc68 cross-compiler to handle.
We're trying to dig up a version of cc68 with an expanded symbol table
(anybody have one we can FTP?).
The new C-Kermit files are in KER:CKC*.*, KER:CKU*.*, KER:CKV*.* on CU20B,
available via anonymous FTP, and in CKC* *, CKU* *, and CKV* * on CUVMA
via KERMSRV over BITNET. They should also find their way to uucp host okstate
at Oklahoma State University within a day or two.
------------------------------
Date: Tue, 18 Mar 1986 09:12 MST
From: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
Subject: Printable Encodings for Binary Files
Apparently the Intel HEX format, which HEXIFY generates, is not usable
on the PCs. What do you use? Is it those .BOO files? If so, how do
you generate them? Can they be generated on the 20? And, what is
used on the PC side to recreate the original?
------------------------------
Date: Thu 20 Mar 86 08:53:10-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Re: Printable Encodings for Binary Files
We have a couple programs on the DEC-20 for doing this kind of stuff.
KT:HEXIFY.* and KT:HEXCOM.* convert CP/M .COM files to Intel hex format
& vice versa. These were written by Bruce Tanner of Cerritos College, and
run on the DEC-10 or DEC-20. But I believe Intel hex format is of little
use on MS-DOS systems.
KT:HEXE.* and KT:UNHEXE.* convert between 8-bit binary files and straight
2-for-1 hex encoding (with CRLFs inserted for readability). I wrote these in
about 10 minutes one day. They only work on the DEC-20.
The .BOO file format is something we invented for distributing MS-DOS Kermit,
but it should work for any 8-bit binary file. It's sort of like Macintosh
BinHex (but .BOO came first): 4-for-3 printable ASCII encoding, with
compression of repeated zero bytes. A typical .BOO file is shorter than the
corresponding .EXE because of the zero-compression. Here are the relevant
programs:
KER:MSBMKB.C turns an 8-bit binary file into a .BOO file. KB:MSBMKB20.EXE is
a version that runs on the DEC-20; KB:MSBMKB.EXE is for MS-DOS. It can also
run on Unix.
KER:MSBOOT.FOR is a Fortran program that runs on a mainframe that downloads
a .BOO file to a PC. It runs on DEC-10, DEC-20, VMS, even IBM mainframes.
KER:MSBPCB.BAS is the corresponding Microsoft Basic program that receives the
.BOO file from MSBOOT, decodes it on the fly, and stores the resulting binary
file on the disk.
KER:MSBPCT.* are the programs that translate a file from .BOO format back to
.EXE (or whatever). They assume you have already downloaded the .BOO file.
The C version can run on Unix or MS-DOS (it takes a few seconds to process a
40K file). The .BAS version is in Microsoft Basic for MS-DOS -- it takes about
20 minutes to do the same 40K file.
------------------------------
Date: Thu, 20 Mar 86 07:54:29 EST
From: swb@batcomputer.tn.cornell.edu (Scott Brim)
Subject: kermit & Telebits
Frank, some mail you sent to Don Porter has wended its way to me. I'm
surprised you got even that much throughput running Kermit with the
Telebits. The answer is to use the new "interactive mode" PROMs - much
smaller delay times and a few other changes for tuning for real
terminal use. I think you'll see much better performance.
[Ed. - We might be getting some of these next week. If so, will give
them a spin.]
------------------------------
Date: Wed, 19 Mar 86 17:00:47 cet
From: FI%NORUNIT.BITNET@WISCVM.WISC.EDU
Subject: Sperry 1100 Kermit
We are running the Sperry Kermit by Paul Stevens, dated june/july 1985.
If anyone is interested, here is a report of some of our problems with
this Kermit, and our fixes for them. Apart from these minor annoyances,
Kermit has been a pleasure to use!
(1) There is no need for Kermit to assign the Sperry work file
exclusively, apart from the risk that someone else writes to
the file during transmission. To me, this was more annoying
than useful, so I changed the file assignment as shown.
(2) As distributed, Kermit will not treat program file elements
with multiple cycles (indicated by fieldata S in S3 of the
label control word), unless the data part of the label conforms
to the SDF standard (*SDFF* in first word). As a result,
elements written by the system line editor ED, will not be
transmitted correctly. That is, if our fix is not applied...
(3) When ACK'ing a previous data packet, Kermit as distributed put
the first 6 characters of the ACK'ed packet into the data part
of the ACK. I haven't seen any Kermit do that before, but it
looks straight enough. However, after receiving a couple of
those 'long ACKs', IBM PC-Kermit (2.28) fills the next one or
two packets with garbage (typically, a lot of zeros - nicely
encoded, though, so the receptor does not notice). The result
is an apparently successful transmission, with a few 'black holes'
in the element on the Sperry host. Changing the data size to
zero in these ACKs seemed to eliminate the problem.
These are the fixes in Sperry correction card format
(1) -3177,3177
sTrng '@ASG,A K$E$R$M$I$T$ . ' . Not exclusive
(2) -4287,4288
(3) -4713,4715
sz,h2 prline . Do a normal ack of length 0
l,u a2,prline . Seems to confuse PC-Kermit
-fi
Frithjov Iversen
Trondheim University Computing Center, Norway
[Ed. - Taksgardeha! (Did I spell that right? Not a chance...) I've added
your note to the .BWR file. I trust that pAul sTevens will see it himself
one day.]
------------------------------
Date: Thu, 20 Mar 86 12:22:20 est
From: Ken Mandelberg <km%emory.csnet-relay.csnet@CSNET-RELAY.ARPA>
Subject: Spooling Prints from an IBM/PC?
Is there any combination of kermits, that would allow spooling of files for
printing from an IBM/PC to a Unix host, without any operator interaction?
The normal steps of terminal emulation for login, escape to command mode,
initiating a file transfer, back to terminal emulation to issue some unix
print command, escape and terminate, seems to frustrate our secretaries. In
fact anything short of typing a one line command, or better yet a function
key, seems to be a problem.
I am a little out of date on what is available in each kermit version. The
server mode for Unix kermit would seem to speak to the question, but I think
PC kermit does not exploit it. Even if available, the server approach might
not be a great solution. The logistics of starting, stopping, the server,
and dealing with any malfunction would be very frustrating to these users.
Any suggestions and information would be appreciated. If there is a better
approach then kermit for this problem, that too would be appreciated.
Ken Mandelberg
Emory University
Dept of Math and CS
Atlanta, Ga 30322
{akgua,sb1,gatech,decvax}!emory!km USENET
km@emory CSNET
km.emory@csnet-relay ARPANET
------------------------------
Date: Fri 21 Mar 86 09:01:37-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Re: Spooling Prints from an IBM/PC
What you really need is a script facility in MS-DOS Kermit. But there
isn't one. The release after next will probably have it. With a script
facility, you could put all the commands for logging in to Unix and
starting up the server into a command file, and the user could "take unix"
or whatever (you could even define a command macro for this to make it
easier, or use a utility like ProKey to bind it to a function key).
Without a built-in script facility in MS-DOS Kermit, you might still be
able to accomplish the same effect by writing a little program to log them
in and start the Kermit server. It could be run from their autoexec.bat
file, or whatever.
Then, when they wanted to print a file, they could say "xprint foo.bar",
where xprint was a .bat file which simply translated the command into
"kermit send foo.bar".
On the Unix end, you could have server cd'd to a special spooling directory
(publicly writable), and then you could have a separate daemon process that
would wake up every so often, and print and delete any files that showed up
in this directory.
Finally, to let the user finish up for the day, you could have them type
simply "kermit bye". If that's too complicated, you could bind this string
to another function key, or write a little .bat file with a more suggestive
name that does the same thing.
The users could not be entirely oblivious of what was happening. The amount
of time to transfer a file from the PC to Unix could be significant if the
file is long. In 2.29 of MS-DOS Kermit, you could include "set display off"
on the command line, which would disable the screen display during file
transfer. Then, if they were using one of the "multitasking" systems like
DesqView, TopView, MS Windows, etc, they could continue with other work without
being bothered. In the future, there may be a version of Kermit for MS-DOS
that can be installed as a device driver. Once connected to a Kermit server
on the other end, it would work just like the PRINT command -- you could say
"send foo.bar", and it happen by itself, leaving even an ordinary DOS system
free to do other work during the transfer. But don't hold your breath for
this one.
------------------------------
Date: Fri, 14 Mar 86 09:55:15 EST
From: yatteau@harvard.HARVARD.EDU (John Yatteau)
Subject: Problems with Kermit on SCO Xenix V
I obtained source for C-Kermit 4C(057) 31 Jul 85 from the harvard vax and
compiled it under SCO Xenix Sys V Rel 2.0 on both an IBM PC/AT and an
IBM PC. The result was a dialect of Kermit in which the PC's can
communicate normally with each other, but not with the vax or any other
normal Kermit. The Xenix Kermits appear identical to C-Kermit on the vax
in every other way. The debug log shows the transfer hanging up on the
packet check ("rpack: chk_ should be ["). I had to modify the
makefile slightly to use the "middle model" option of cc, and tried all
likely makefile options (sys 3's and 5's). I even recompiled C-Kermit
on the vax to insure that the sources were identical.
Any ideas?
Jack Yatteau
yatteau@harvard.harvard.edu
617-495-9663
Pierce Hall/CEPP
29 Oxford St.
Cambridge, MA 02138
[Ed. - Beats me! This program is known to work on at least some versions
of Xenix on the IBM PC family. Has anyone out there seen anything like
this?]
------------------------------
Date: Fri, 21-MAR-1986 11:22 MST
From: KEVIN GRAY <GRAYK@BYUVAX>
Subject: MS-DOS Kermit on ATT 6300 vs VMS Kermit?
I am running MSDOS-KERMIT version 2.28 on an AT+T PC6300 and have experienced a
few problems that I hope you can help me remedy. While transferring files to a
Vax-8600 KERMIT-32 I have an inordinate number of retries-approximately 1 retry
for every 10 packets sent. I have also had difficulty transferring files of
20Kbytes or more to KERMIT-32. With the KERMIT-32 in server mode I have been
able to download files of up to 200Kbytes with 0 retries but when uploading
large files I very rarely have a successful transfer. Sooner or later I get
a KERMIT-32 device timeout error or a KERMIT-32 receive error. Smaller packet
sizes have made no difference. I have spoken to other users on the same system
who use different micros and none have reported the same problem so I am not
sure if the error is in my machine or not. I would greatly appreciate any help
you could give me regarding this problem.
Thank You,
Kevin Gray "grayk@byuvax"
[Ed. - Another "beats me". Does anyone else have any experience
transferring very large files between these two systems?]
------------------------------
End of Info-Kermit Digest
*************************
-------