SY.CHRISTINE@CU20B.COLUMBIA.EDU (Christine M Gianone) (09/10/86)
Info-Kermit Digest Wed, 10 Sep 1986 Volume 5 : Number 7
Converting Kermit Distribution to 3 Tapes
New (Minor) Release of C-Kermit for UNIX
Kermit 2.29 for the NEC APCIII
Uuencoded Files and Trailing Blanks
Kermit for NCUBE AXIS
Timing Problem with TOPS-20 Kermit
VAX to PC binary file xfers
Being thrown into CP while using CMS Kermit
CMS KERMIT under VM/XA/SF?
Kermit through 3708 Front End or WETRONIC Protocol Converter?
PRIMOS Kermit v. IBM-PC 2.29?
Kermit and Paradise Graphics Card?
----------------------------------------------------------------------
Date: Tue 9 Sep 86 17:26:35-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Converting Kermit Distribution to 3 Tapes
Keywords: Kermit Distribution
The collection of Kermit programs and documentation has once again grown
beyond the capacity of our most common distribution, 1600bpi 2400-foot reels
of magnetic tape. We are now in the process of reorganizing the files from
2 groups (micros and mainframes) into 3 groups (micros, mainframes, and
esoterica). Our major goal is to keep the most popular stuff on tapes A and
B, so that people who ordered these tapes before the changeover will still
stand a good chance of getting everything they want. However, we must
create sufficient empty space on tapes A and B to allow the new Kermit
programs recently announced (and others waiting in the wings) to fit.
We'll try to do this as fairly as possible. In the meantime, we'll be
installing new programs and files on CU20B without necessarily also putting
them in our other distribution areas or on our tapes. When this rash of
installations (and announcements) is complete, we'll see how to most
equitably distribute the files. Network access to Kermit files will be
unchanged, but during the transition some of the new files won't necessarily
be available at all of the distribution points.
------------------------------
Date: Tue 9 Sep 86 17:27:50-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: New (Minor) Release of C-Kermit for UNIX
Keywords: C-Kermit
Cross-Ref: UNIX Kermit (see also C-Kermit)
This is to announce a new, minor release of C-Kermit for UNIX. Because of
some mixups this past July, the new Amiga Kermit was installed in the Kermit
distribution with an inconsistent set of sources; the major reason for this
release is to remove this inconsistency. Also, a few minor bugs are fixed.
Significant performance improvements and additional features will come in
future releases. Here's a brief summary of what's in this new release:
Changes from Jack Rouse and Phil Julian of SAS Institute:
. Commodore Amiga support, replaces that from Davide Cervone of Rochester U.
All-new CKI*.* files (this was announced in Info-Kermit v5 #3).
This is the version written up in Jul/Aug 86 Amiga World.
. Revert CKUCMD.[CH] and CKUUS?.[CH] to their old selves (no more printf2,
printf3, since these are no longer necessary for the Amiga), but add a
few new Amiga specifics under #ifdef AMIGA conditionals.
. Fix multiline GET parsing to allow get back to top-level prompt if illegal
local filename given (in CKUUSR.C).
. Supply a missing printf() parameter in CKWART.C.
Other changes:
Fix top-level parse loop in CKUUSR.C to reset any start state that might
erroneously have been set when a parse error has occurred. Eliminates (for
instance) the spurious "?Sorry, you must set speed first" message if you
specify "foo bar" as the local filespec in multiline GET.
Make sysinit() return -1 if it fails, 0 if it succeeds, and have CKCMAI.C
check the return code. Corresponding changes to invocation of sysinit in
CK[UVMI]IO.C.
Change references in CKUFIO.C to _file member of FILE structure to more
portable fileno() [suggested by Doug Orr, U of Mich].
In CKUFIO.C, change zclosf() to kill the fork before waiting for it to
terminate.
Fix Sys-V speed setting code (change "," to ";" between tttvt.c_cflag
statements) in CKUTIO.C.
Fix errpkt() function in CKCFN2.C to close open files, so that further
host commands can be done by the server after such a command is interrupted
abnormally [problem pointed out by Gregg Wonderly, Oklahoma State U].
Add Stan Barber's 4.3BSD acu control code to CKUTIO.C, under NEWUUCP
conditional. I'm not sure if NEWUUCP needs to be defined in the makefile,
or what...
Version 4D(061) has been compiled and tested under Ultrix 1.1 (= 4.2BSD),
Ultrix 1.2 (whatever that may be a hybrid of), 2.9BSD on a DEC Pro/380, and
true 4.3BSD on a VAX 11/750 (4.3BSD includes an earlier version of C-Kermit
-- 4C(057) -- on its distribution tape). The files that are new to this
version are in KER: on CU20B. They are:
CKUCMD.C, CKUCMD.H, CKITIO.C
CKUUSR.C, CKUUSR.H, CKMTIO.C
CKUUS2.C, CKUUS3.C, CKVTIO.C
CKUFIO.C, CKUTIO.C
CKCMAI.C, CKUKER.UPD
------------------------------
Date: Fri, 29 Aug 86 21:16 EDT
From: Goeke@MIT-MULTICS.ARPA
Subject: Kermit 2.29 for the NEC APCIII
Keywords: MS-DOS Kermit, NEC APC3
Cross-Ref: NEC APCIII (see also NEC APC3 and MS-DOS Kermit)
As we discussed almost two months ago, I have this version of a
terminal driver for the NEC APCIII which implements almost everything found
in the IBM PC driver plus some little goodies of its own. Roger Link
(linkr%vtvm1) and I have worked together on debugging the present version;
he is now releasing it to his general (local) universe, which will no doubt
turn up additional bugs, but one cannot wait forever.
I have put a note in the Boston Computer Society APCIII newsletter
offering to supply disks for users finding it inconvenient to get the source
from Columbia. The same offer applies to the general world, which you may
publish in whatever manner is common. The instructions are to send me 1
floppy to get the executable code, 4 floppies to get all the sources. The
address is:
Robert Goeke
MIT Center for Space Research
Room 37-567
77 Massachusetts Avenue
Cambridge, MA 02139
[Ed. - Thanks! We will distribute this stuff as part of the 2.29a release,
since corresponding changes have to be made to all the other incarnations of
MS-DOS Kermit. Till then, those who are anxious to get it can get floppies
by mail as advertised above.]
------------------------------
Date: Sun, 03 Aug 86 22:35:31 EST
From: MOEWS%UCONNVM.BITNET@WISCVM.ARPA
Subject: Uuencoded Files and Trailing Blanks
Keywords: Uuencoded Files
If you use KERMIT under VM/CMS, it is hard to use uuencoded files such
as the uuencoded version of ST Kermit, since VM/CMS Kermit removes all
trailing blanks when downloading files. Here is a solution to this problem;
it is a version of UUDECODE that supplies trailing blanks as necessary,
written to run on the Atari ST. It is written in 68000 assembly language,
and can be assembled using the public domain assembler, AS68.
David Moews
MOEWS@UCONNVM.BITNET
[Ed. - Thanks David! The files are in KER:ASTUUD.*. The trailing blanks
will be lost, however, if punched across BITnet. See KER:ASTKER.BWR for
a more complete explanation and a SNOBOL program to restore the blanks.]
------------------------------
Date: Fri, 8 Aug 86 11:02:58 edt
From: couch <@CSNET-RELAY.ARPA,@TUFTS.CSNET (alva l couch):couch@TUFTS.CSNET>
Subject: Kermit for NCUBE AXIS
Keywords: NCUBE AXIS
I now have a partially functional adaptation of C - Kermit 4.2 for the
NCUBE parallel processor running the AXIS operating system.
Sincerely,
Alva L. Couch,
Dept. of Computer Science,
Tufts University,
Medford, MA, 02155
[Ed. - As soon as Columbia receives the files, we'll attempt to add
Alva's code to the current C-Kermit release, and announce when it's
ready.]
------------------------------
Date: Tue, 09 Sep 86 13:10:00 PDT
From: Bob Larson <R.LARSON%FNS1@USC-ECL.ARPA>
Subject: Timing Problem with TOPS-20 Kermit
Keywords: TOPS-20 Kermit
Cross-Ref: KERMIT-20 (see also TOPS-20 Kermit)
After making a few improvements in my specialized kermit used to transfer
mail between USC's primes and other computers, (better timeout handling)
files started being duplicated. (Cases of up to 26 have been reported.) I
finaly traced the problem down: Tops-20 kermit (4.2(253)) frequently ignors
a GE (Generic Erase, i.e. Delete File) packet sent immediatly after an ack
to a B packet. (Is the tops-20 clearing its input buffer before going back
to server wait?) By adding a delay (20 seconds is probably a bit much, but
works) before sending the GE packet, this problem has dissapeared. My
kermit implimentation cannot resend the GE packed after a timeout, since it
requests to delete the oldest generation of a file (-2) after it has been
transferred. (If the Ack of the GE packed was lost, repeating the GE packet
would erase a file that has not been transfered.)
A completly different solution to the problem would be to convince the
tops-20 end to tell me what generation of the file it is sending. I'm not
sure I want to put the work into supporting atribute packets even if the
tops-20 end did.
[Ed. - What the DEC-20 Kermit server actually does in response to a GE
packet is to send back a whole transaction, in which the Data packets list
the actual files (including generation numbers) that were listed. Thus you
don't get an ACK, you get a "long form response". If you want to try to
pick out the filenames from the data packets you can do so, but this would
mean the Prime code would have to have special knowledge of the form in
which the DEC-20 sends this information.]
Another problem I have noticed with tops-20 kermit 4.2(253) is it wants a
control-v counted as two characters in a GE packet it receives, which does
not agree with my interpretation of section 8.2.1 of the kermit protocol
manual (sixth edition). (The case of control characters is not dirrectly
discussed, so it is somewhat left to interpretation.)
[Ed. - If you want to quote a special character in a filespec sent to a
DEC-20 Kermit server, precede it by a Ctrl-V, just as you would do when
typing odd filenames directly to TOPS-20. The data field of the generic
packet is formed before datalink-level encoding, therefore the little length
fields within the data packet of a generic command reflect the length before
encoding. For instance, if you want to send a generic command to delete a
file called x.? (where ? is not normally a legal character in a filename),
the data field of the g packet would look like "E$x.#V?" -- $ indicates a
length of 4, AFTER DECODING (and before encoding). Clear? (ha)]
Bob Larson <Blarson@Usc-Eclb.Arpa>
------------------------------
Date: Fri 8 Aug 86 21:37:30-PDT
From: Dan Davison <FOX.DAVISON%BIONET@sumex-aim.arpa>
Subject: VAX to PC binary file xfers
Keywords: VAX/VMS Kermit, MS-DOS Kermit
Someone asked about doing binary file transfers via kermit from an IBM PC to
a VAX. A response indicated that it can be done. I'm sorry to report that
response is wrong in some cases.
We routinely transfer files from VAXEN to uVAXen and other PCs (Pro 350,
Dec Rainbow, IBMPC Portable, a few others). Vax has a binary file format tha
CANNOT be transfered using KERMIT. They cannot (1) be transfered via KERMIT
VAX to VAX; (2) uVAX to VAX (or vice versa) and (3) PC to VAX (or vice versa).
It doesn't matter what parity, baud, stop,start etc. you use. We speak to
a set of 785s, everybody running the same version of kermit. The thing to
do is a
DIR/FULL/ALL filename.EXE
If the record size is 512 (the usual for VAX executables and some special
format files made via FORTRAN and PASCAL) you are guaranteed to get garbage
after the transfer. We have tried all sorts of ways around this, but the only
way that works is to copy the files over DECNET to a machine that has a tape
drive.
We also cannot transfer binary (.OBJ) files with Kermit. The problem lies n
in KERMIT but the way the VAX keeps information in the file header. You can
transfer the files, true, but they are useless and cannot be RUN or LINKed.
Non-DEC binary files, on the other hand, can be transferred successfully, re-
loaded and used. I use our Microvax to backup my hard disk (until its
reacent headache (crash) courtesy of Federal Express.
If anyone wants further info, or knows of a way around this, please get in
touch with me at one of the addresses below.
Dr. Dan Davison, Dept. of Biochemical and Biophysical Sciences, SR-1,
University of Houston--University Park, 4800 Calhoun, Houston, Tx 77004
[Ed. - The normal trick is to SET FILE TYPE FIXED or SET FILE TYPE BINARY.
Did you try either or both of these? (They are alleged to work, provided
the record length is 512.) Of course, what VMS Kermit really needs is
attribute packets. PDP-11 Kermit uses this to transfer the entire
FILES-11 FAB (or whatever it's called) along with the file, so it can be
properly reconstructed on the receiving system, provided it's also FILES-11.
Future releases of VMS Kermit may work somewhat better in this respect.]
------------------------------
Date: Fri, 01 Aug 86 23:19:27 EDT
From: Mark S. Feldman <MARKSF@UMD2.UMD.EDU>
Subject: Being thrown into CP while using CMS Kermit
Keywords: CMS Kermit
Recently, there has been discussion here about the problem of CMS Kermit
falling through to CP. I've used CMS Kermit a lot, both here at the
University of Maryland and at several comercial sites. Only one of the
comercial systems that I have used has ever thrown me into CP, and it was
doing it fairly consistently one day. The problem was not with Kermit, but
with the over-loaded state of the computer. I don't even think that having
control returned to kermit would have helped that day - the machine was
being thrown into CP because it could not keep up with the input.
What if you want to go into CP?
While preventing CMS Kermit from being thrown into CP might help some
people, I wonder if it might hurt some others. What if you need to break
out of (server) CMS Kermit and for some reason the pc Kermit is unable to
transmit a finish packet, or any packet for that matter. Wouldn't the
proposed change to CMS Kermit make it very difficult, and perhaps
impossible, to get out of CMS Kermit server mode if their were a problem
with the pc Kermit?
Mark
[Ed. - When using the CMS in linemode through a 3705 or equivalent, then
almost any kind of framing or parity error can throw you into CP. The
proposed change will continue Kermit where it left off, immediately,
whenever this happens -- a fairly frequent occurrence over dialups, etc.
It's still possible to break out if you're coming in as a 3270 through a
Series/1-style front end, and it may also be possible with a 3705 if
you type a lot of BREAKs in a row.]
------------------------------
Date: Tue, 19 Aug 1986 16:04 EDT
From: Nick Gimbrone <NJG@CornellA>
Subject: CMS KERMIT under VM/XA/SF?
Keywords: CMS Kermit
Has anyone succeeded (tried) in using CMS Kermit under VM/XA/SF?
[Ed. - CMS Kermit (any version) should work, provided VM/XA/SF has TTY
support (does anyone know if it does?). In any case, Kermit should still
work on these systems through Series/1-style front ends.]
------------------------------
Date: Mon, 11 Aug 86 13:04:12 MEZ
From: UZR112%DBNRHRZ1.BITNET@WISCVM.ARPA
Subject: Kermit through 3708 Front End or WETRONIC Protocol Converter?
Keywords: Protocol Converters
We (id est: the Computer Center of the University of Bonn, West
Germany, where I work beside my studies), we want to run KERMIT on an
IBM3708 Protocol Converter. Did anyone of yours already test this
configuration? Did anyone of yours heard about someone *out in netland* who
has this configuration and/or has tested it and/or is using it. Any notes
concerning this problem will be very welcome !!!!!!!!
[Ed. - The 3708 makes an ASCII terminal look like an SNA terminal, rather
than a local bisync 327x terminal. There is no code in CMS or TSO Kermit
to handle these, and it's not clear that there ever can be -- for a protocol
converter to be usable for Kermit file transfer requires that it can be put
into transparent mode (and that the mainframe Kermit program know how to do
this); does the 3708 have a transparant mode, like the Series/1 or 7171?]
Did anyone *out there in netland* already succeded in a filetransfer using
KERMIT for conecting PCs to an IBM/370-series-mainframe via a Protocol
Converter WETRONIC PCI/1076? We are able to run an emulation on this
configuration, but we still have problems when trying the file transfer
facility. Any notes concerning this problem will be very welcomed. Thanks
a lot for all your efforts in advance. Have a nice day. Please answer me
directly to:
Thorsten Glattki
Computer Center,Univ.Bonn,W.-Germany
My netaddress is : <UZR500%DBNRHRZ1.BITNET at WISCVM.WISC.EDU>
[Ed. - Similar considerations apply here. Does the WETRONIC thingie have
a transparent mode? If so, code can be added to mainframe Kermit to turn
this on and off, as it does for 7171's, etc. Otherwise, forget it.]
------------------------------
Date: Fri, 29 Aug 86 11:14:58 BST
From: Chris_K_now-and-then <cjk@uk.ac.ucl.cs>
Subject: PRIMOS Kermit v. IBM-PC 2.29?
Keywords: Prime Kermit, MS-DOS Kermit
Has anyone actually worked IBM-PC Kermit 2.29 against (any) PRIMOS
Kermit successfully? If so a note as to the settings employed would be much
appreciated. A friend at Salford is failing utterly.
Chris Kennington.
[Ed. - This combination is in common use between The Source (which has
Primes) and their customers (many of whom have PCs). However, most
accesses to The Source are through Telenet, which adds an additional
level of complexity. The magic in that case, however, is simply "set
parity mark". Do you have the most recent (May 86) version (7.57)?]
------------------------------
Date: Mon, 8 Sep 86 15:40:47 EDT
From: Kenneth Van Camp -FSAC- <kvancamp@ardec>
Subject: Kermit and Paradise Graphics Card?
Keywords: Graphics Card
I recently replaced my old IBM monochrome (non-graphics) display
adapter with a Paradise Modular graphics card (still driving my IBM
monochrome display) on my PC-XT. For some reason, the text display with
this board is noticeably slower than with the old mono card. I can live
with this, but when I go into Kermit I am now dropping characters when in
the normal connect mode. I tried slowing down the baud rate to 4800, and I
even told Unix to put in some fairly long pauses after every line (stty
cr3), to no avail. I also tried both types of flow-control in Kermit, with
no effect. It's important that I point out that nothing has changed except
the display adapter -- same modem, same Kermit, etc. Yet Crosstalk XVI
doesn't seem to have the same problem; no characters are dropped at any
speed. Does anybody know what's going on?
--Ken Van Camp <kvancamp@ARDEC.ARPA>
------------------------------
End of Info-Kermit Digest
*************************
-------