SY.FDC@CU20B.COLUMBIA.EDU.UUCP (09/17/87)
Info-Kermit Digest Thu, 16 Sep 1987 Volume 6 : Number 20
Today's Topics:
Announcing C-Kermit 4E(067)
Xenix Experimental C-Kermit 4E(066)
C-Kermit 4E(066) Support on Control Data 180 Mainframes with VX/VE
New Release of Kermit-11 for PDP-11s
Cover on following mstibm.boo (dated 16 Sept)
Insert mode in Kermit 2.29c
Info-Kermit Digests Available in Indexed Form
New Organization of Distribution Tapes Reflected at Okstate
MacKermit on an SE
MacKermit 0.8(35)
Comments on Recent Kermit Digest Items
Re: Proposed Extensions to Kermit Protocol
Kermit-32 STATUS Command
Prime Kermit Source Unpacking
WordPerfect files
Kermit Protocol Curiosity
----------------------------------------------------------------------
Date: Tue 15 Sep 87 18:24:28-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Announcing C-Kermit 4E(067)
Keywords: C-Kermit, Unix, VMS
Now that the beta test of version 4E(066) of C-Kermit (announced in V6 #16)
has had some time to fester, and some good bug reports (and fixes!) have
trickled in, it's time to announce a new release, 4E(067). This one
includes only fixes for the reported bugs, plus a couple of minor additions.
It was tested with VAX Ultrix 2.0 and VAX/VMS 4.3. If it checks out OK on
other systems too, it will replace 4D(066) as the standard C-Kermit release.
Checking out OK means that it is not inferior to 4D(066) in any way, so that
no harm would be done by the replacement. The changes include:
- Fix to allow C-Kermit to run on Pyramid & similar systems.
- The wild "set send packet-length" command was tamed.
- Allow "set prompt" to work, even from init file.
- Problems with packet retransmissions in response to CRLFs should be gone.
- Added dial support for the Concord Condor CDS 220 2400b modem.
- Changed Xenix compilation options a bit.
- New make options for CDC VX/VE, "clean", and "lint".
- Set effective group & user IDs on BSD systems for csh command execution.
- Fix parsing of "show parameters".
- Fix parsing of "remote cwd" from take-command file.
- Breakup of source lines longer than 80 characters.
- Supply missing functions & symbols for VAX/VMS.
- Cosmetic & lint-suggested changes.
See the file xkuker.upd for details. The affected files are (just so you
don't have to transfer the whole 2.5MB collection again):
xkcfns.c, xkcfn2.c, xkcmai.c, xkudia.c, xkufio.c, xkutio.c,
xkuusr.h, xkuusr.c, xkuus2.c, xkuus3.c, xkvfio.c, xkvtio.c,
xkuker.bwr, xkuker.mak, xkuker.upd, xkvker.bwr
available as usual from CU20B via anonymous FTP or on BITNET from CUVMA
via KERMSRV.
There are no new binaries or hex files. People with Unix (any flavor, esp.
Xenix), VAX/VMS, Data General AOS, Macintosh, Apollo, or Amiga systems are
urged to get these files and build the new version from source. Anyone who is
equipped to build this program from source for the Macintosh or Amiga is
further exhorted to do that, and then report any bugs or fixes (or better
still, report if there aren't any!), and if the result is usable, send in
the .HQX or .BOO file.
If no significant problems are reported with the Unix, VMS, or Macintosh
implementations within a few weeks, 4E(067) will become the standard
distributed version of C-Kermit, so that we don't have to carry the CK*.* and
XK*.* files side by side, and that will make room for some new additions to the
"popular minis and mainframes" area (Tape B).
Thanks to everyone who sent in bug reports, suggestions, and fixes -- Joe
Doupnik, David Herron, Steve Walton, Paul Placeway, S.O. Lidie, Jim Guyton,
Phil Julian, Markku Toijala, and many others.
------------------------------
Date: Sun, 13 Sep 87 03:27:29 edt
From: jl42+@andrew.cmu.edu (Jay Mathew Libove)
Subject: Xenix Experimental C-Kermit 4E(066)
Keywords: C-Kermit, Xenix
A thought - you commented (or someone commented) that the "other Xenix
people" (paraphrase) did not report the trouble of redefined stuff from
include files. Well, from the kermit digest it appears that I am the only
other one who reported to you on Xenix CKermit, and this fits as I have
modified my system include files to avoid certain redefinition problems.
Certain modules include redefinitions IF certain other modules have been
previously included. I have #ifndef I_modname'd the sections that would be
repeats, and I define I_modname when a module is included. Hope this
explains the lack of problems in this respect on my end.
Jay Libove
Arpa: jl42@andrew.cmu.edu Bitnet: jl42@drycas.bitnet
UUCP: ...!{uunet, ucbvax, harvard}!andrew.cmu.edu!jl42
UUCP: ...!{pitt | bellcore} !darth!libove!libove
[Ed. - OK, the "#include <sys/file.h>" statements are removed from ckutio.c
and ckufio.c in 4E(067). Thanks!]
------------------------------
Date: 12 SEP 1987 22:49 EDT
From: "S. O. Lidie" <LUSOL@LEHICDC1.BITNET>
Subject: C-Kermit 4E(066) Support on Control Data 180 Mainframes with VX/VE
Keywords: C-Kermit, CDC, VX/VE
Xref: Control Data, see CDC
I have ported C-Kermit to Control Data's Unix product, VX/VE 5.2.1. VX/VE
runs under control of NOS/VE, the Cyber 180 operating system.
Only a few mods were needed, all to CKUTIO.C. They were mostly for
selecting line discipline 0, because VX/VE defaults to a special line
discipline 1. The diff outputs for CKUTIO.C and the makefile follow.
Here are some effective baud rates (ebr) at various line speeds and packet
sizes. These rates are essentially the same for both send and receive, so I
averaged them:
1200 4800 9600
----------------------------------
Packet Size:ebr 250: 950 250:5300
500:1000 500:3600 500:6400
1000:1000 1000:3800 1000:6900
83% 79% 72%
Perhaps you would include the following mods into C-Kermit:
[Ed. - Omitted from message, included in 4E(067).]
------------------------------
Date: Fri 11 Sep 87 12:15:37-EDT
From: Brian Nelson <BRIAN@UOFT02.BITNET>
Subject: New Release of Kermit-11 for PDP-11s
Keywords: PDP-11, RSX, RSTS, RT11, P/OS, VA4224 Modem
Kermit-11 3.58 for PDP-11s with DEC and DEC-like operating systems (RSTS/E,
RSX11/M, RSX11/M+, RT11, TSX+, IAS, P/OS, Pro/RT, etc) is now available.
It replaces release 3.54 of September 1986. Changes are relatively minor; they
include:
. SET PHONE TONE/PULSE, SET PHONE BLIND
. VA4224 modem support.
. Allow linking with I/D space under RSTS/E, RSX11M+.
. Fix command macro display (SHO ?)
. Add Ctrl-A status report during local-mode transfers.
. Dynamic record buffer allocation, bigger buffers for I/D space.
. Conditional .INCLUDE's for assembly on RT11 V4 and P/OS.
. Fix sending BREAK for XL on RT11
. SET LINE TTN:/[NO]ALLOCATE for RSTS/E
[Ed. - Thanks, Brian! The new files are in KER:K11*.*, including new
documentation (K11USR.*), available from host CU20B via anonymous FTP
(Internet) or NFT (CCnet), and from host CUVMA on BITNET via KERMSRV.]
------------------------------
Date: Sat, 12 Sep 87 22:55 MDT
From: <JRD@USU.BITNET> (Joe Doupnik)
Subject: Cover on following mstibm.boo (dated 16 Sept)
Keywords: MS-DOS Kermit
The current MSTIBM.BOO file follows (dated 12 Sept) if you want to
do anything with it at this time. I'm off Sunday am to meetings all week.
Regards,
Joe D.
[Ed. - Not sure what's new in this one, but it seems to work OK, so it
replaces the 2.29C version dated 16 August as KER:MSTIBM.BOO on CU20B
(MSTIBM BOO on CUVMA). There's also a somewhat updated draft of the manual
in KER:MST29C.DOC. Feedback appreciated, as the real 2.30 release draws
ever nearer.]
------------------------------
Date: Fri, 11 Sep 87 23:27:06 EDT
From: "James H. Coombs" <JAZBO@BROWNVM>
Subject: Insert mode in Kermit 2.29c
Keywords: MS-DOS Kermit
I asked about this before but have not seen a response. How about providing
some method for making it clear when one is in insert mode? Ideally, the
cursor would get fat. This is a serious weakness in Kermit's terminal
emulation capacities. The problem is aggravated by the fact that insert mode
is automatically toggled off by certain operations. One does not really know
what the mode is until one starts typing. YTERM provides such feedback, so it
obviously can be done.
--Jim
[Ed. - Probably not in the near future. 2.30 is about ready to release.
And also this feature would tickle a bug in early IBM PC ROMs discussed in
past issues of Info-Kermit and Info-IBMPC. Anyway, a real VT100 doesn't do
this... (standard copout).]
------------------------------
Date: Fri 11 Sep 87 11:45:49-EDT
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Info-Kermit Digests Available in Indexed Form
Keywords: Info-Kermit, Digest, Kermit Digest, Index
Info-Kermit Digests Volumes 3 - 6 have been indexed and paginated, so that
information can be easily looked up by topic. The indexed versions, suitable
for printing, are in KER:IMAIL.85B, KER:IMAIL.86A, KER:IMAIL.86B,
KER:IMAIL.87A. Indexing will proceed retroactively back to Volume 1, time
permitting.
------------------------------
Date: Thu, 10 Sep 87 16:22:14 -0500
From: Mark Vasoll <vasoll%a.cs.okstate.edu@RELAY.CS.NET>
Subject: New Organization of Distribution Tapes Reflected at Okstate
Keywords: OK State, UUCP, Dialup Kermit File Access
The new five tape organization of the Kermit distribution has
been duplicated on the Oklahoma State University UUCP and Kermit
server system. The following is the new layout.
/usr/spool/uucppublic/kermit-a -- Tape A (microcomputer versions)
/usr/spool/uucppublic/kermit-b -- Tape B (mini/mainframe versions)
/usr/spool/uucppublic/kermit-c -- Tape C (more micro versions)
/usr/spool/uucppublic/kermit-d -- Tape D (more mini/mainframe versions)
/usr/spool/uucppublic/kermit-e -- Tape E (documents and misc.)
See the "aafiles.dir" file in each directory for exact contents or refer to
"aavers.hlp" for tape name and file name prefixes on specific versions.
Mark Vasoll
Computing and Information Sciences Internet: vasoll@a.cs.okstate.edu
Oklahoma State University UUCP: {cbosgd, ihnp4, rutgers,
Stillwater, Oklahoma uiucdcs}!okstate!vasoll
[Ed. - Thanks, Mark! And thanks for continuing to provide this valuable
service.]
------------------------------
Date: Sun, 13 Sep 87 12:41:28 edt
From: "Robert B. Stam" <stamr%cs.unc.edu@RELAY.CS.NET>
Subject: MacKermit on an SE
Keywords: MacKermit, Macintosh SE
Here's a copy of the fix I had to use to get Kermit to run on an SE (as
opposed to a Plus or earlier). This is a copy of an article posted to
comp.sys.mac
In a recent posting I commented that I was not able to get MacKermit to run
correctly on my Mac SE, and that it seemed to be a problem with fonts. A
local insightful chap suggested that MacKermit as delivered from columbia
might not have a FOND resource. In fact it does not (this is true of both
ckmker.hqx and xkmker.hqx). The fix is as follows:
1) Make a copy of MacKermit.
2) Run Font/DA mover
3) Close the system file fromt the left window
4) Click the left Open button with the option key down (the option key tells
it to open all kinds of files, like MacKermit)
5) Find and open the original copy of MacKermit
6) Click the right Open button with the option key down
7) Find and open the duplicate copy of MacKermit
8) Select and remove the 2 fonts (VT100 etc...) from the right hand window
(ie, from the copy of MacKermit)
9) Select and copy the 2 fonts (VT100 etc...) from the left hand window, thus
copying the 2 fonts from the original copy of MacKermit to the
duplicate copy of MacKermit
10) Close everything and quit. MacKermit should now work.
This is not quite the NOP operation it looks like. When Font/DA mover moves
a font it looks to see if the destination has the appropriate FOND resource,
and if not it adds it.
Many thanks to Oliver Steele of UNC who guessed what the problem was and
suggested that I look for the FOND.
Happy Kermitting ...
Robert B. Stam CSNET: stamr@unc.cs.unc.edu
UNC Computer Science Department ARPA: stamr%unc@mcnc.org
Sitterson Hall 083A UUCP: {ihnp4|decvax}!mcnc!unc!stamr
Chapel Hill, NC 27514 Phone: (919) 962-1826
[Ed. - And many thanks to you for sending in the solution, which has been
added to the Mac Kermit "beware" file.]
------------------------------
Date: Mon, 14 Sep 87 11:08:37 EDT
From: Warren Bell <wbell%gpu.utcs.toronto.edu@RELAY.CS.NET>
Subject: MacKermit 0.8(35)
Keywords: MacKermit
I was under the impression that there was a new version of Kermit for
the Macintosh, with version number 0.8(35), but when I requested
CKMKER.HQX from KERMSRV@CUVMA, I received version 0.8(34), dated March 1986.
Will the new version be available on the Bitnet server?
-Warren Bell
(wbell@gpu.utcs.toronto.edu or wbell@utorgpu.bitnet)
[Ed. - The new version is XKMKER.HQX, not CKMKER.HQX. And even that is not
so new -- it's based on the 4D(061) sources, but changed to compile under
Megamax C, and with a couple cosmetic changes. I hope somebody out there
will build a version of MacKermit, let's call it 0.8(36), from the new C-Kermit
4E(067) sources, and maybe even add material to the dialog boxes to allow
selection of long packets and other new features, and then send in the
resulting .HQX file (and any modified XKM*.* sources).]
------------------------------
Date: Fri, 11 Sep 87 23:39 MDT
From: <JRD@USU.BITNET> (Joe Doupnik)
Subject: Comments on Recent Kermit Digest Items
Keywords: Kermit Protocol Extensions
Regarding the latest Kermit Digest (V6 #19):
1. Chris Kennington's embedded file transfer controls while in Connect mode.
The SOH + stuff combination is a little delicate, as Frank also mentioned.
What about an extension of a DEC escape sequence set: ESC [ ? etc ? This
would be easy to parse and would help maintain ruggedness of the code and
also would not cause a false alarm if transparent printing were active.
The host side would need to start a file transfer with it and the current
version of Kermit-MS can tolerate it as a packet lead-in sequence.
[Ed. - See discussion below.]
2. Dave Herron and Unix version numbers. Thanks Dave. My manuals all say
plain jane sysVr3 and now I know (I think). C-Kermit works solidly on my Unix
PC after removal of the void cast on signal(), for what its worth.
3. Dave Bell and sending WordPerfect files to Kermit-32. Yup, the binary
nature of those files requires SET FILE TYPE BINARY on the VMS side.
[Ed. - More about this below.]
4. Kermit-32 has math problems with effective baud rate. True indeed.
Local Kermit-32 version is 3.3.111 and it solidly reports 2**32.
[Ed. - See below.]
5. Eric Neuwirth and the Bondwell PC. Eric, more than the serial board is
non-standard with your machine. Try Kermit-MS version 2.30 when it appears
and if that hangs your system it is time to find a friend with computer
experience.
6. From Jim Moore, moore@ncsc.arpa: sees "4i" at end of transparent
printing. An old problem fixed some time ago.
[Ed. - i.e. fixed in current MSTIBM.BOO, version 2.29C.]
7. From Walter Mischel, psy1.mischel@cu20b: Control-@ does not send
a null. That's a keyboard definition affair. The real IBM keyboard does
not send a null from any key combination since it is the same as a Control
Break to the Bios. It can be added to the current key definitions as
Set Key \1283 \0
Perhaps this should be made a default definition.
[Ed. - A real VT100 doesn't send a null from ^@ either...]
8. From David Cargo, dscargo@hi-multics.arpa: top rank keys are coupled
to similarly labeled keypad keys for key definitions. Old problem since
fixed. The keypad is fully 'aliased' to separate such keys and allow the
keypad itself to be reconfigured without affecting the top rank keys.
Regards,
Joe D.
------------------------------
Date: 1987 Sep 11 23:21 EDT
From: (John F. Chandler) PEPMNT@CFAAMP.BITNET
Subject: Re: Proposed Extensions to Kermit Protocol
Keywords: Kermit Protocol Extensions
In response to the suggestion of automatic resumption of Protocol mode upon
receipt of any SOH, I'd like to point out that noisy lines are not only
problem. Many Kermits can (and some must) use a packet-marking character
other than SOH, and it seems a pity to trigger on SOH (or on the current
packet character) trusting that said character will never occur for
non-Kermit reasons. I think it would be better to implement a special
Connect-mode command to put the micro-Kermit back into Protocol mode. After
all, in Connect mode, Kermit listens for "commands" from the remote host and
updates the screen accordingly -- why not just extend the terminal emulation
language by adding one new escape sequence? Upon receipt of that command,
the micro could pop into server mode and await instructions. Note that the
remote host can then do more than just send files -- it can issue the whole
range of server-mode commands to change settings and even upload files.
------------------------------
Date: Wed, 16 Sep 87 16:38:23 BST
From: Chris Kennington (CJK@SYSD.SALFORD.AC.UK)
To: John F. Chandler (PEPMNT@EARN.CFAAMP)
Cc: info-kermit @ cu20b.columbia.edu
Keywords: Kermit Protocol Extensions
John:
Thanks for your thoughtful comments (suggesting a terminal
escape-sequence to trigger local Kermit into protocol mode).
I take your point that any auto-triggering ought to be on the
current Start-of-Packet character, not "hardwired" to SOH. I'd also intend
that the implementation should check pretty thoroughly that the next few
characters are compatible with the header of one of the Kermit packets legal
at this point (S, I etc.).
From the point of view of my (commercial) client, the objective was
to achieve a local Kermit which would flip into protocol mode as soon as the
user gave the appropriate command to the host Kermit (in connect mode). The
proposed environment is one where the relatively naive user thinks of his
local equipment as an intelligent terminal, not a computer. As far as he is
concerned, he always thinks he is talking to the mainframe host.
The ESC-sequence idea has attractions because it's controllable
(though some thought would be needed to pick an appropriate sequence,
presumably from one of the ANSI "local implementation" sets). The
disadvantage is that, as an extension to the Kermit host protocol, there
would be a delay before the majority of mainframe host Kermits implemented
it. My client, as always, wants it yesterday; and wants it to work
independent of the level of Kermit on the host.
I shall probably proceed with the trigger-on-"SOH" logic, if only to
see how it works. But I am in favour of defining an extension to the
protocol which permits, in effect, limited communication between the two
Kermit state-machines embedded in the connect data-stream. There might be a
number of other things which could usefully be done, such as setting the
start-of-packet character itself. This sounds like an idea to be threshed
around generally.
Chris K.
[Ed. - Anyone who adds this kind of mechanism to a Kermit program should
also provide a way for the user to override it, in case of accidents and for
debugging. About the "Kermit escape sequence" -- since any Kermit program
can emulate any terminal whatsoever, or for that matter may make use of any
built-in firmware, external terminal device driver, or even an external
terminal, then how can you pick a sequence guaranteed not to collide with
any conceivable terminal's repertoire of escape sequences? (The world isn't
composed only of ANSI terminals -- we also have HP's, DG's, etc etc).
Looking for a Kermit packet does indeed seem to be the best route.]
------------------------------
Date: Fri, 11 Sep 87 23:55 CDT
From: <GE00707@SWTEXAS.BITNET>
Subject: Kermit-32 STATUS Command
Keywords: Kermit-32, VMS Kermit
In light of the comments about STATUS not working, it doesn't work for us in
versions 3.0 or 3.3. We're running VMS 4.5 (VAX 8650). (Usually we
download files to IBM PCs, running ProComm 2.4.2.)
MM
VMS Kermit-32 version 3.3.111
Kermit-32>stat
Totals for the last transfer
Characters sent 188
...
Effective data rate 4294967106 baud
[Ed. - This is wierd. It seems to be independent of Kermit version, but
dependent on VMS version. A real baud rate is displayed by 3.1 and 3.3
of VMS Kermit under VMS 4.3... Anyway, it seems Kermit-32 is headed for
extinction, and development is picking up on the VMS version of C-Kermit,
which doesn't have any problems reporting the effective baud rate.]
------------------------------
Date: Sun, 13 Sep 87 22:29:42 EDT
From: ciaraldi@cs.rochester.edu
Subject: Prime Kermit Source Unpacking
Keywords: Prime Kermit
The source for Prime Kermit is in one big file, PRIME.PLP. CU20B has a
program PRIMES.FTN which breaks it into its component files automatically.
Unfortunately, this program doesn't work. It looks for lines of colons
separating the files. PRIME.PLP has lines of pound signs. The program also
messes up finding file names. I'm trying to fix the program, but I am
wondering if anyone has already got it working.
The alternative way of splitting the file is to use EMACS. We have this,
but it truncates the file after 5000 lines, so that doesn't help either.
If I get it working soon I'll let you know.
Mike Ciaraldi
------------------------------
Date: Mon, 14 Sep 87 15:56:28 EDT
From: John C Klensin <KLENSIN@INFOODS.MIT.EDU>
Subject: WordPerfect files
Keywords: WordPerfect
WordPerfect files are, in fact, binary ones, with funny line delimiters and
several other such things -- it is not just printer ESC codes. To transfer,
you must either:
- Treat the file as binary, as suggested in Info-Kermit. It, after all,
*is* binary. Use SET FILE TYPE BINARY to VMS Kermit.
- Use WordPerfect's "convert" program to encode it into seven-bit ASCII
graphic characters.
If you really have a WordPerfect printer output file (rather than the file
that WordPerfect actually operates on) then the problem is the same, but
only the first solution -- binary transmission - will do you any good.
------------------------------
Date: Wed, 16 Sep 87 06:11:51 EDT
From: John C Klensin <KLENSIN@INFOODS.MIT.EDU>
Subject: Kermit Protocol Curiosity
We have run into a small protocol curiosity when using a strange mix of
equipment. It seems to parallel another strange mix, so the problem may be
general enough to be worth consideration. The problem:
- We start with a terminal concentrator that requires (or is most easily
configured with) a "parity none" arrangement. In our case, the concentrator
speaks RS232 asynch on the PC side and TCP/IP Telnet on the network side.
- The network -- specifically, either the concentrator or the host at the
far end -- won't negotiate an eight-bit "binary" transfer of data, so binary
information must be transmitted with 8th-bit prefixing.
- But, while the protocol manual seems to provide for me to force 8th-bit
prefixing by sending a character other than N or Y, most versions of kermit
ask for this feature only if parity is set on (non-none). If we turn parity
on, the terminal concentrator, which checks it, gets very upset.
In addition to our TCP/IP problems, this seems to parallel some difficulties
we've observed with some complex protocol converter arrangements that make
ASCII devices speak 327x at the far end of complex links.
We can, of course, get around this by "hexifying" the files prior to
transmission, but that is what 8th-bit quoting is supposed to save us. So,
this is a bit of a plea for either an
SET EIGHTH-BIT-QUOTING ON option or
some way to say
SET PARITY NONE-but-don't-transfer-eight-bit-data-without-quoting
[Ed. - Not really a protocol issue, but an implementation decision. This
is the first time we ever heard of an environment where 8th-bit quoting
is necessary and at the same time parity is proscribed. But my goodness,
how do explain something like this to the "naive user". The manual is
already hundreds of pages thick!]
------------------------------
End of Info-Kermit Digest
*************************
-------