SY.CHRISTINE@CU20B.COLUMBIA.EDU (Christine M Gianone) (01/27/88)
Info-Kermit Digest Tue, 26 Jan 1988 Volume 7 : Number 3
Departments:
ANNOUNCEMENTS -
Announcing C-Kermit 4E(068)
Updates for CDC Cyber NOS Kermit (CD3KER)
Announcing DECSYSTEM-20 Kermit 4.2(262)
German Translation of MSKERM.HLP for V2.30
VM/CMS KERMIT -
Installing CMS Kermit 4.0
Kermit on 9370 using ASCII Subsystem
CMS Kermit 4.0 Packet Size Anomaly
UNIX KERMIT -
Re: Announcing C-Kermit 4E(068)
Data General C-Kermit 4E(067)
Kermit on BSD 4.2
Re: Kermit on BSD 4.2
C-Kermit 4D(061) and Microport Unix
MISCELLANY -
UUCP Lock Files
VAX -> NASA VAX Problem
Secure Kermit File Server for VMS?
Kermit for the Visual 1050?
Commodore 64 Kermit and GNU Emacs?
----------------------------------------------------------------------
Date: Sun 24 Jan 88 20:15:25-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Announcing C-Kermit 4E(068)
Keywords: C-Kermit 4E(068), Unix Kermit
This is to announce another minor release, but this time a "real" release,
of C-Kermit for Unix, VAX/VMS, Data General AOS, the Commodore Amiga, the
Apple Macintosh, etc. The changes were minor, and only appear in the Unix
versions. They include:
. Suspendibility via Ctrl-Z on systems with job control (Bob Brown).
. Explicit support for SCO Xenix in the Makefile (from D.W. Bettinger).
. Explicit support for the AT&T 7300, including the ability to dial its
internal modem (from R.E. Hill, untested).
. Improved response of the C-Kermit server to 'remote cwd' commands.
. Miscellaneous small fixes and cleanups.
The major change is that since this is now considered a real release, the
files have been named from XK*.* back to CK*.*, and the XK*.* files are
gone, resulting in a savings of about 2 megabytes in our Kermit distribution
area and on our tapes.
All files' names changed, but the only files whose contents changed are:
ckuker.upd - Update history
ckuker.bwr - Beware file
ckcfns.c - Functions (better reporting of current directory by server)
ckcmai.c - Main program (new version number)
ckcpro.c - Protocol module (wart output)
ckudia.c - Dial module (ATT 7300 support added)
ckuusr.c - New calls
ckutio.c - Support for ATT 7300, job control fixes
ckufio.c - New zgtdir() function to return current directory
ckdfio.c - Ditto (but dummy)
ckifio.c - Ditto (but dummy)
ckmfio.c - Ditto (but dummy)
ckvfio.c - Ditto (but dummy)
ckwart.c - Syntax error fixed
These files are in K2: on CU20B.COLUMBIA.EDU, e.g. K2:CKCFNS.C, available
via anonymous FTP. They are also available on BITNET from KERMSRV@CUVMA as
CKCFNS C, etc. For information about using KERMSRV to get Kermit files,
send a message to KERMSRV@CUVMA with the message text saying "help".
Please report any problems with this release to Info-Kermit@CU20B.
------------------------------
Date: Wed, 30 Sep 87 14:15:20 EDT
From: op%VIRGINIA.BITNET@CUVMA.COLUMBIA.EDU (Olaf Pors 804-924-0633)
Subject: Updates for CDC Cyber NOS Kermit (CD3KER)
Keywords: CDC Cyber Kermit
The files CD3KER.INS and CD3KER.MOD contain feature addition to CDC NOS
Kermit (the CD3 Kermit). CD3KER.INS is a replacement for that file on the
Kermit distribution. CD3KER.MOD is the only source code you need to upgrade
CD3 Kermit from version 3.2 to the one I created (3.3); this file should be
added to the rest of the CD3KER files on the distribution, so it can be
applied using the CDC UPDATE utility. UPDATE works with a base file
(usually quite large) and applies modifications (usually small) to create a
file for compilation. This is the way that CDC maintains their system
software, and I think CD3 Kermit should be handled this way too; i.e., have
a large, unchanging base file and a small modification on the distribution.
New changes would be added to the modification file until it gets too
unwieldy, at which time a new base file would be created. The CD3KER.INS
file I've supplied assumes the (possible) existence of such a modification
file. See also the comments in CD3KER.INS. All the documentation needed
concerning my enhancements (upward compatible) is at the beginning of the
CD3KER.MOD file.
[Ed. - Thanks, Olaf! And apologies for taking so long to bring your
contribution to public light. Olaf's changes include support for 8/12 ASCII
binary files, optional kinds of EOF conversion, and support for CDCNET.
Unfortunately, in August 1987 (several months before you submitted this
one), Steve Roseman of Lehigh University (LUSGR@LEHICDC1.BITNET) submitted
another, different, version 3.3 of this program, announced in Info-Kermit V6
#17. Your files have been put in KER:CD3KER.IN2 (so as not to interfere
with Steve's CD3KER.INS), and CD3KER.MOD. Meanwhile, let's hope someone
will be able to reconcile the two versions and maybe produce a version 3.4?]
------------------------------
Date: Tue 26 Jan 88 16:15:25-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Announcing DECSYSTEM-20 Kermit 4.2(262)
Keywords: DECSYSTEM-20 Kermit
This release corrects problems introduced by the previous release, announced
a few digests ago. Now, not only does DEC-20 Kermit not prevent you from
issuing GET, REMOTE, BYE, and FINISH commands when in remote mode (e.g. to a
PC Kermit server), but now they also work! In addition, it is now possible
to execute CWD and REMOTE CWD from a TAKE file (it wasn't before). The new
version is in KER:K20MIT.MAC and KER:K20MIT.DOC on CU20B, and in K20MIT MAC
and K20MIT HLP on CUVMA. This may be the final release of DEC-20 Kermit;
the main goal is to get the existing bugs out before our last DEC-20 sails
smoothly into eternity.
------------------------------
Date: 01/25 04:02:13
From: Gisbert W. Selke <RECK%DBNUAMA1.BITNET@CUVMA.COLUMBIA.EDU>
Subject: German Translation of MSKERM.HLP for V2.30
Keywords: MS-DOS Kermit, German Manual
Enclosed is MSGERM.HLP, a German version of MSKERM.HLP.
[Ed. - Thanks, Gisbert! It's been put in the Kermit Distribution as
MSKGER.HLP, the name change being necessary because the MSG prefix is
already used for something else.]
------------------------------
Date: Tue, 29 Dec 87 10:19:17 EDT
From: Terrence Ford <TFOCU%CUVMC.BITNET@CUVMA.COLUMBIA.EDU>
Subject: Installing CMS Kermit 4.0
Keywords: IKC Kermit, CMS Kermit 4.0
Two very minor points that may save people some time installing 4.0:
1) As received from KERMSRV@CUVMA, the following files all proved to have
a last record beginning with X'00' (which will cause the assembler to
complain with IFO053 OP CODE NOT FOUND ON FIRST OR ONLY CARD)
IKCUTL.ASM
IK0CMD.ASM
IK0COM.ASM
IK0DEF.ASM
IK0DOC.ASM
IK0MAC.ASM
IK0MAI.ASM
2) In step 2, the HELPCONV command will create IKCKER $HLP A, not IKCKER
$HLPCMS A as documented.
As I said, very minor.
Terrence Ford
[Ed. - Thanks, Terrence. Problem (1) was an artifact of our file transfer
process (FTP, not Kermit!), and has been rectified -- the CUVMA copies no
longer have nulls at the end.]
------------------------------
Date: Mon, 21 Dec 87 11:03:33 PST
From: jimbys%CITIAGO.BITNET@CUVMA.COLUMBIA.EDU (James V. Bys)
Subject: Kermit on 9370 using ASCII Subsystem
Keywords: CMS Kermit
We have been running CMS Kermit 3.1 on an IBM 4381 with a 7171 interface
successfully. We recently received an IBM 9375 with an ASCII Subsystem.
This IBM supported subsystem acts similarly to the 7171.
Kermit compiles and starts successfully on the 9375. When Kermit is put in
server mode, the FIRST file transfer occurs successfully. After this
transfer, the terminal attached to the ASCII Subsystem is completely hung.
None of the local reset characters have any effect. Needless to say, no
further communication by the local Kermit with the 9375 occurs.
The CMS installation instructions state:
"When CMS Kermit is to be used with a 7171, make sure the 7171 is set
up with its 'keyboard lock delay' parameter set to 0. Otherwise, the
'terminal' will hang whenever CMS Kermit clears the screen..."
This symptom sounds similar to the one mentioned above using the ASCII
Subsystem. There, however, is no mention that we could find of a "keyboard
lock delay" parameter in manual SA33-1564 "ASCII Subsystem Customization and
Programmer's Guide".
Could anyone that has successfully installed Kermit through an ASCII
Subsystem please comment?
James V. Bys
California Institute of Technology
Internet address: JIMBYS@iago.caltech.edu
Bitnet address: JIMBYS@CITIAGO
------------------------------
Date: Sat, 23 Jan 1988 14:22:08 EST
From: "James H. Coombs" <JAZBO%BROWNVM.BITNET@CUVMA.COLUMBIA.EDU>
Subject: CMS Kermit 4.0 Packet Size Anomaly
Keywords: CMS Kermit
Thanks for the new version of CMS Kermit 4.0.
I have found many improvements and only one oddity (or two?).
1) The documentation (IKCKER DOC) says:
"Maximum packet size: 1920"
But when I try to set the receive packet size to 1920, the executable
rejects the command and issues the message:
"Operand must be <1914"
The same problem occurs when I try to set the send packet size. In
addition, when I specify something like '1900', I am told that the
send packet size is limited to the range '20-94'.
2) This may be a local problem, but I get the following message on startup:
"Handshake is XON -- not needed"
CMS Version is "Rel 3 Lev 302.2".
Thanks. --Jim
Dr. James H. Coombs
Software Engineer, Research
Institute for Research in Information and Scholarship (IRIS)
Brown University
jazbo@brownvm.bitnet
Acknowledge-To: <JAZBO@BROWNVM>
------------------------------
Date: Mon, 25 Jan 88 23:01:49 PST
From: blarson%skat.usc.edu@oberon.USC.EDU (Bob Larson)
Subject: Re: Announcing C-Kermit 4E(068)
Keywords: C-Kermit 4E(068)
In article <791@vixie.UUCP> paul@vixie.UUCP (Paul Vixie Esq) writes:
>In article <11449@brl-adm.ARPA> SY.FDC@cu20b.columbia.edu (Frank da Cruz)
>writes:
>>This is to announce another minor release, but this time a "real" release,
>>of C-Kermit for Unix, VAX/VMS, Data General AOS, the Commodore Amiga,
>>the Apple Macintosh, etc. The changes were minor, and only appear in the
>>Unix versions. [...]
^^^^^^^^^^^^^^^^^^
>I'm curious, though, as to whether this release includes the long-discussed
>"windowing kermit protocol" which would apparently allow several ACKs to be
>outstanding at one time, thus improving performance on half-duplex and X.25
>connections.
Unfortunatly, I'm rather certain full duplex windows havn't made it into
C-kermit yet. The only version I know of are for Primos, a semi-functional
(and unmaintainable) one for ms-dos, and commercial ms-dos packages (such as
procomm). There may of course be others I am not aware of.
The later C-kermits do include long packet support. This is what is desired
for half-duplex, but is not as good for x.25 or long delay hookups. I'm
curious as to when, if ever, windows will make it into c-kermit.
Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu
Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson
Prime mailing list: info-prime-request%fns1@ecla.usc.edu
oberon!fns1!info-prime-request
[Ed. - Sliding windows are not in C-Kermit 4E(068). This is high on the list
of things to add to C-Kermit, as are Attribute packets, and support for MS-DOS.
These will appear in future releases, which in turn will appear as time
permits.]
------------------------------
Date: Sat, 26 Dec 87 20:02:38 CST
From: haque@umn-cs.cs.umn.edu (Samudra E. Haque)
Subject: Data General C-Kermit 4E(067)
Keywords: C-Kermit 4E(067)
In your 4E(067) version I believe you have conditional compilation for Data
General machines (== ifdef datageneral), assuming that people who run these
machines want to compile a version for themselves. Well, there is a problem
with that. There are basically two major types of software on DG machines:
AOS/VS and DG/UX, i.e. native AOS with MV/UX subshells and native unix for
the Data General. Unfortunately, on both C compilers the symbol
"datageneral" is defined! This is of course a problem since both unixes are
*not* identical in file structure and programs.
So: Just using plain "#ifdef datageneral" will tend to break people who try
to compile C-Kermit on DGUX's version. What I might suggest use the
construct "#ifdef datageneral #ifndef DGUX" etc..
Else: I'm just about finished with 4E(067) for DG/UX.. this version with
proper #ifdef DGUXs. My version of ckuusr.c seems to be broken though,
(symbol line length attribute conflict ? )..and I've been wanting to FTP a
new version over. ... ...
Thanks for your attention.
Samudra E. Haque
Computer Science Systems Group
Computer Science Department
University of Minnesota, Minneapolis, MN 55455.
[Ed. - This message arrived too late for the new release. But you're more
than welcome to fix the program up for Data General operation and send the
changes back to Columbia, preferably based on the just-announced 4E(068)
release.]
------------------------------
Date: 28 Dec 87 00:42:59 GMT
From: nerd@percival.UUCP (Michael Galassi)
Subject: Kermit on BSD 4.2
Keywords: C-Kermit
I recently wrote a program to deal with idle users on my system and have a
loose end to tie up before I can send it on to r$ for posting to
comp.sources.unix.
The problem is with Kermit. When users are kermiting files back and forth
stat(2) on their terminal shows that the device has not been accessed since
the file transfer started. I know perfectly well that data is going across
the link as the lights on the modem blink in the usual kermit fashion, but
looking at the st_mtime, st_atime, and st_ctime entries in the structure
returned by stat(2) shows no change during the course of the file transfer.
I know this is not a problem with my invocation of the stat system call as
who(1) also reports the terminal as idle. HELP!!! How is kermit doing its
i/o?
I am running C-Kermit version 4C, when it starts up I get the message:
C-Kermit, 4C(057) 31 Jul 85, 4.2 BSD
If anyone knows exactly how Kermit does it's i/o could you please
send me mail about this? Also, what other programs have you found that play
the same tricks with i/o that I should look out for?
-michael
[Ed. - See message below. C-Kermit opens /dev/tty in rawmode and does
unbuffered read()'s and write()'s to it.]
------------------------------
Date: 28 Dec 87 17:37:05 GMT
From: egisin@orchid.waterloo.edu (Eric Gisin)
Subject: Re: Kermit on BSD 4.2
Keywords: C-Kermit
C-Kermit probably opens /dev/tty instead of using stdin and stdout, so the
/dev/tty?? inode times are not updated. The reason for doing this so one
can send stdin or receive stdout as a file.
One fix is to modify kermit to use stderr instead of /dev/tty.
[Ed. - C-Kermit does indeed use /dev/tty.]
------------------------------
Date: Sat, 23 Jan 88 20:39:54 EST
From: Brodsky <353164%UMDC.BITNET@CUVMA.COLUMBIA.EDU>
Subject: C-Kermit 4D(061) and Microport Unix
Keywords: C-Kermit 4D(061)
I'm having difficulties using C-Kermit on a tty port with getty. Even
though Microport says you can get away with this by running getty on
/dev/ttyM? I have had numerous occasions where the C-Kermit process hangs
while attempting to aquire the port. The process will will linger without
responding to any kill (even kill -9), LCK* file removal, or init state
change. The only way to get the tty port back is to reboot. There are no
problems running C-Kermit as long as getty doesn't have the port, however.
This bug is not a consistent one. There are times when running C-Kermit and
getty together works fine and other times when it does not. One thing that
tends to cause the problem to occur more often is when getty has a multiple
speed setting (such as 1200R where it will switch between 300 and 1200 bps).
I suspect some sort of port access confusion in ttyM?, but I haven't yet the
skills to track this beast down. Can anyone help?
Thanks for all the wonderful work Froggers!
Jake Brodsky
"What nature doesn't do to us,
Is done by our fellow man." --Tom Lehrer
------------------------------
Date: Sat, 5 Dec 87 09:27:35 CST
From: convex!smu!leff@a.cs.uiuc.edu (Laurence Leff)
Subject: UUCP Lock Files
Keywords: UUCP, Lock Files
Our version of kermit does not access the lock files correctly so as to
avoid interfering with uucp under 4.3BSD.
The lock file mechanism changed from 4.2BSD to 4.3BSD. Yet the version of
Kermit that came with the 4.3BSD distribution from Mt. Xinu is using the old
style uucp lockng mechanism appropriate for 4.2BSD systems.
Has anyone fixed this and can send us a patch?
Laurence Leff
Coordinator, Computer Science Department Computer Facilities Management
Team
convex!smu!leff leff%smu@csnet-relay E1AR0002 at SMUVM1 (BITNET)
[Ed. - Let's hear it once again for UUCP lock files, probably the silliest
single feature of Unix. Why access to tty devices should be shared rather than
exclusive by default is a profound mystery. So long as every Unix system in
the world (and every new release of each version) must have a different idea of
where the UUCP lock file should be, what it should be called, what should be in
it, who its owner should be, etc etc, communication programs, like Kermit, that
attempt to work on many different Unix versions will remain in a perpetual
state of confusion (end of tirade). The past few releases of C-Kermit have had
code to deal with 4.3BSD lock files, but it's not activated by default. Look
in the module ckutio.c for "NEWUUCP".]
------------------------------
Date: Thu, 21 Jan 88 16:38:24 EST
From: "Robert E. Zaret" <ZARET%MITVMA.BITNET@CUVMA.COLUMBIA.EDU>
Subject: VAX -> NASA VAX Problem
Keywords: VAX/VMS Kermit
Someone just came in with a problem transferring files from his lab's VAX to
a VAX run by NASA. Both seem to be VAX 11/750s running Kermit-32. He calls
an 800 number to connect through Telenet using 1200 bps, 7 databits, and
even parity. He has no problem using the NASA VAX. However, when he tries
to transfer a FORTRAN source file, he sees no error messages, but cannot
find the file at the other end. More specifically: he invokes Kermit on the
NASA end and puts it in server mode; then he uses ^]c to escape back to his
local kermit and tells it to send the file; after 3-5 minutes, he gets a new
Kermit-32 prompt.
I am surprised about the Telenet connection: the 800 number seems curious; I
was unable to use Telenet with 7e (I had to use 8n to connect to Telenet and
let it handle, correctly, the computer at the other end that insists on 7e);
and he never sees the usual Telenet prompts. He is certain he uses Telenet,
not TELNET.
We would certainly appreciate any hints. Thanks.
[Ed. - The Telenet variations are not totally inexplicable.
A Telenet host can configure the user's Telenet pad as to parity, etc., using
private X.28 (or is it X.29) parameters. Thus the behavior of your PAD can
depend on what host you're connecting to. Meanwhile, can anybody who has
used Kermit in this environment help?]
------------------------------
Date: 14 Jan 88 21:19:51 GMT
From: Kral <amdahl!drivax!braun@ames.arc.nasa.gov>
Subject: Secure Kermit File Server for VMS?
Keywords: VAX/VMS Kermit
We have a need for a "secure" file server on our VMS machines. We want
something that would enable our customers to call up, log in, and transmit
or receive files in their home directory. They should be able to do
directory listings within their own tree as well. However, they should
not be able to spawn off sub-processes, read or write files outside of their
home directory, etc. Ideally, the wouldn't be able to have any kind of
access, including directory listings, of anything outside of their home
directory.
Our problem is this: our machine security is pretty relaxed, leaving
any security up to limiting login access to "trusted" users. As a result, the
users have gotten used to leaving world read (and sometimes write!) permission
on their home directories. Most of the users on the machine we wish to
implement this on are Operating System Engineers, so we figured it would be
kind of costly to impose any reasonable security on the system. We also
figured that permissions probably wouldn't be kept long if we were to require
them to change them.
Now we have customers that want to do file transfer with us, and we need
their accounts secure from each other, as well as our own source code
directories being secure from them.
Right now I am attempting to modify kermit-32 to take out any remote
commands. I only have the macro sources to work with. ANy suggestions
are appreciated.
kral [THERE ARE NO ORDINARY MOMENTS]
408/647-6112 ...{ism780|amdahl}!drivax!braun
[Ed. - C-Kermit might be easier to work with, but it is not yet truly at
home in the VMS environment. But it's not clear that changing Kermit is the
answer to the problem. If they can log in, they can get at other people's
files. Even if you have a "secure" Kermit on the system, they can use it
to transfer an "insecure" one for their own use.]
------------------------------
Date: Wed, 30 Dec 87 19:31:38 PST
From: Michael Marria <marria@ardvax.stanford.edu>
Subject: Kermit for the Visual 1050?
Keywords: Visual 1050 Kermit
I am looking for further information to get this Visual 1050 transfering
binaries. It has a usable ascii modem and trap system, so I can get .HEX files
to start up.
This thing is somewhat Kapro II and DEC Rainbo compatible. I down
loaded the HEX file for a Kaypro which runs until I attempt connection which
crashes the machine.
Any help on this will be much appreciated.
Also, if this helps, it runs CP/M3, though I assume the crash problems
relate to the port loction being different then that of a Kaypro.
Anybody out there have one of these things?
Thanks much,
Michael
[Ed. - If it runs CP/M 3.0, then you should not be using Kaypro Kermit,
you should be using CP/M 3.0 Kermit, which should run as-is on any CP/M
3.0 system. The system-dependent hex file for this is in KER:CP4CP3.HEX,
which is combined with KER:CP4KER.HEX to produce the complete running
program, according to the instructions in the manual.]
------------------------------
Date: 12 Jan 88 16:42:08 GMT
From: pete@umbc3.umd.edu (Pete Hsi )
Subject: Commodore 64 Kermit and GNU Emacs?
Keywords: Commodore 64
While using GNU Emacs with C64 Kermit at 1200 baud, I noticed when scrolling
UP ONLY, the screen would get garbled. (Probally overflowing the input
buffer? I haven't notice this happening at 300 baud (300 baud?!? ARGH!))
Anybody out there know the solution to this? I have FLOW-CONTROL ON in C64
Kermit. I do a re-draw screen command (C-l; no biggie) but I would like a
more elegant (sp?) solution such as resetting TERM-CAP, etc.
More info:
Host: Ultrix (Dec's Unix) running GNU Emacs 18.49.1 and
VMS running the ported version of GNU Emacs.
Local: Commodore 64 running Kermit 2.0 (VT100 emulation), 1200 modem.
If possible, send me mail. Thanks in advance.
Pete
Univs. of Maryland Baltimore County (UMBC == "U Must Be Crazee" :-)
ARPA: pete@umbc3.umd.edu or pete@umbc2.umd.edu
Bitnet: pete@umbc
"Mis-spellings are the fault of my computer"
------------------------------
End of Info-Kermit Digest
*************************
-------