SY.FDC@CU20B.COLUMBIA.EDU (Frank da Cruz) (09/10/87)
Info-Kermit Digest Thu, 10 Sep 1987 Volume 6 : Number 19
Today's Topics:
New Copy of MSTIBM.BOO
Documentation for MS-Kermit 2.29C and 2.30
Proposed Extensions to Kermit Protocol
Update to UCSD p-System Kermit for Terak
C-Kermit on the Unix PC
4E(066) on NCR Tower Works Fine
Sperry 1100 Kermit Retires
More on Multiple CDC Kermits
Kermit 80 Version 4.08 (pre-release) Files
EBCDIC and ASCII Definitions
Transferring WordPerfect Files
MSBPCT.PAS
7171 Causes CMS Kermit Problems When Flow Control Used
Need HP150 Kermit on diskette
Kermit for a Bondwell?
VMS Kermit version 3.2.076 STATUS Command
----------------------------------------------------------------------
Date: Wed 2 Sep 87 10:09:44-EDT
From: Christine Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: New Copy of MSTIBM.BOO
Keywords: MS-DOS Kermit
Some people were experiencing problems downloading the new KER:MSTIBM.BOO
(2.29C, 16 Aug 87) file. There is now a new copy, same name, which we have
downloaded and un-BOO'd with no difficulties. No release changes have been
made to this version.
------------------------------
Date: Thu 10 Sept 87 15:36 EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Documentation for MS-Kermit 2.29C and 2.30
Keywords: MS-Kermit 2.29C
In response to the many complaints and questions about the latest MS-Kermit
pre-release: Some of the more obvious incompatibilites between 2.29B and
2.29C (which is pretty much what 2.30 will look like) are:
- SET KEY and SHOW KEY commands use different key identifications and
syntax. This is a big one.
- CLEAR command now means clear serial port buffer rather than clear key
and macro definitions. Key and macro definition string space is now
garbage collected, so a CLEAR command for them is no longer necessary.
- CLRINP command is gone (replaced by CLEAR).
- Numbers of the form \nnn now default to decimal rather that octal.
- "LOG filespec" replaced by "LOG SESSION filespec" and "LOG PACKET
filespec".
- The LOCAL command prefix has been removed from 2.30.
Most of these incompatibilities will break your MSKERMIT.INI or other command
or script files, but each has a rationale. A draft version of the manual for
2.30 (which applies to 2.29C as well) has just been completed. It's in
KER:MST29C.DOC (SCRIBE text formatter source in KER:MST29C.MSS) on CU20B and in
MT29C * on CUVMA for KERMSRV access. Suggestions for the final draft are most
welcome.
------------------------------
Date: 14th August 1987
From: Chris Kennington (cjk%r-d.salford.ac.uk@cs.ucl.ac.uk)
Subject: Proposed Extensions to Kermit Protocol
Keywords: Kermit Protocol Extensions
I am currently implementing a Kermit facility to go into a
private ViewData system. This is a commercial contract, so what the
customer says he needs has to be supplied. We may end up with something
which ought to be called "Kermit compatible" rather than Kermit, but that's
life. The environment is MSDOS on a micro; hence the multithreading nature
of the code, which I discussed with you a few months ago.
There are two specific things which the user requires beyond the
normal Kermit protocol. He wants other parts of the host program to be able
to send messages (single-liners) to the terminal's screen at any time during
a file transfer; and he wants the terminal to flip automatically from
connect into send or receive mode any time it starts to receive a I/S/R
packet from the host (so that the transfer can be fully initiated from the
host end, the converse of server operation).
I would like to fit these in in as clean a way as possible. My
current plan is as follows, but I should be glad of comments, particularly
if you either think there is a better way or have plans for extension of the
protocol in either of these directions.
Chris K.
MESSAGES TO SCREEN
This must be divided into two cases; message going in the same
direction as the data, and message going against the data.
For the first case, I propose to define a new type of packet
which can be interleaved with the data-packets. Rather than choose a new
letter I propose to reuse the generic message (G-M) codes. Normal rules for
sequencing would apply.
For the second case, I propose just to put data into the next
ACK, starting the data with a blank so that it cannot be confused with a
cancel-transmission request.
The first suggestion is not backwards-compatible unless it is
counted as a new "capas". I would like to be able to negotiate it, so that
the same program could be used to work both standard Kermits and the Kermit
facility in this customer's integrated ViewData terminal program.
The second ought to be transparent to existing Kermits.
AUTOMATIC TERMINAL RESPONSE
I propose that, whenever in connect mode, the terminal Kermit
detect any SOH received, check to see whether the next few characters are
compatible with the header of a Kermit I, S or R packet, and if so flip into
the appropriate transfer mode. At the end of the transfer it would flip
straight back to Connect mode. The rationale is that, in a ViewData system,
the user always feels that he is working the ViewData host rather than a
local micro, so he wants to have host-commands (sent in terminal mode)
executed forthwith.
The ViewData screen-driving protocol does not make use of SOH as
a control character as far as I know.
When working to a normal host Kermit, this code would never be
triggered except by some unexpected binary garbage.
[Ed. (Frank) - Your ideas sound reasonable. We considered the idea of
screen messages when first designing the protocol, but didn't include them
because there could be no guarantee that the user would be there to read
them.
You can put anything in an ACK you want, so long as you start it with a
space, and it won't interfere with existing Kermits. Let's say that if an
ACK to a data packet contains text starting with space, then the text is to
be displayed on the screen (or added to the user's mailbox, transaction log,
or whatever), or can be ignored altogether (as existing Kermits will do).
For messages in the same direction as the data, I'd actually recommend a new
packet type, "M", rather than a G packet of subtype M, because a G packet
only occurs at the start of a transaction. The use of such a packet would
indeed have to be negotiated. Let's provisionally assign capability bit #6
for this. This would mean that we overflow into the second capability word,
and have to set the low order bit in the first one to indicate that this has
happened. Obviously, M packets will not be sent unless both Kermits set
capability bit #6 in the negotiation phase. Does anyone have any serious
objections to this protocol extension? Like all other extensions, it's
compatible with existing versions, because it won't be used unless both
sides agree.
Automatically flipping into protocol mode when a packet arrives during connect
is an implementation decision, but probably there should be a command to defeat
this. Not only must you worry about noisy lines, but also those cases where
the user might actually display a file that contains examples of Kermit
packets, and also for debugging purposes.]
------------------------------
Date: 19-AUG-1987 11:11:20
From: Nick Rothwell, University of Edinburgh.
Via: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Update to UCSD p-System Kermit for Terak
In the following you will find two of the pieces of UCSD pSystem Kermit
which I've altered to handle text files properly - binary file transfer is
right out because, apart from anything else, the pSystem II.0 BIOS can't
read/write binary files byte by byte correctly, so that's a non-starter.
I originally fixed the bug that the receive routines expected the sequence
'#M#J' to occur together, so a '#M' at the end of a message followed by '#J' at
the start of the next got things confused. The final fix is to totally ignore
all '#'-codes except the sequence '#M#J' (whether adjacent or not), so as to
ensure reliable text file transfer *without* confusing the filing system with
unexpected control characters.
The changes are to RECSW.TEXT and KERMIT.TEXT which are part of the
concatenated source [.UCT]UCTERAK.PAS. Diff listings for these two files are
below.
Nick Rothwell, Laboratory for Foundations of Computer Science,
University of Edinburgh.
ARPA: nick%{cstvax,itspna}.ed.ac.uk@cs.ucl.ac.uk
JANET: nick@uk.ac.ed.{cstvax,itspna}
UUCP: <Atlantic Ocean>!mcvax!ukc!{cstvax,itspna}!nick
[Ed. - Many thanks, Nick. Your changes have been placed in UCTERAK.BWR.]
------------------------------
Date: Sat, 5 Sep 87 18:06:19 EDT
From: David Herron E-Mail Hack <david@ms.uky.edu>
Subject: C-Kermit on the Unix PC
Keywords: C-Kermit, Unix PC
Joe Doupnik of USU.BITNET says "signal() returns type 'int' on my Unix PC
running AT&T sys5r3 ..."
He's getting confused over the numbering scheme(s) for SysV's.
The SysV on the Unix PC is NOT the same SysV as the mainstream that is
currently up to SysVr3.1 (i.e. a little past SysVr3). The SysV there
started as Convergent's port of SysVr1 (or r0, since they hadn't subdivided
SysX's into "releases" at that time) ... This port was different from the
standard SysV of the time (for instance, it had full-fledged virtual memory
... something which didn't get into the mainstream SysV until one of the
sub-releases of SysVr2).
The current version of Unix PC SysV is 3.5.1. It has had some SysVr2
features tossed in and eventually may be re-integrated with the mainstream
versions, but is still a different version of Unix.
Hope this clears up some confusion -- you may want to put these remarks into
a README of some sort in the CKermit distribution.
BTW, some people here had fixed up a C-Kermit which worked well with the Unix
PC's, but they didn't think about sending in their code. I'm going to point
them at this experimental version and get them to re-do their stuff for this
version... and by-golly, I think they'll send in their stuff to y'all this
time around too ... :-)
------------------------------
Date: Sat, 5 Sep 87 19:00:39 edt
From: lbafrin@tecnet-clemson.ARPA
Subject: 4E(066) on NCR Tower Works Fine
Keywords: C-Kermit, NCR Tower
I sure am glad we're back in touch with Info-Kermit, here at the TECNET
project at Clemson University. (Due to network problems, we had been
offline for more than a year.) As soon as I saw (in the latest digest) that
4E(066) had long packets, I FTPed it from CU20B, ran the "make sys3" on our
NCR Tower 32 running NCR's Tower O.S. version 3.something (flawless "make,"
by the way), and then started testing. I'm happy to report that it works
just fine (except for the "too powerful" "set send packet-length" command as
previously reported in the Digest), and it even cleared up a *long*-standing
problem we've had with using it to upload via TELENET and even parity to the
Tower 32, a problem whose source we were never able to pinpoint (Kermit,
Tower, or TELENET?) despite a huge number of hours of debugging time.
Keep up the great work, froggers!
-- Larry Afrin
TECNET Project
Dept. of Computer Science
Clemson University
lbafrin@tecnet-clemson.arpa
------------------------------
Date: Tue 1 Sep 87 13:42:01-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Sperry 1100 Kermit Retires
Keywords: Sperry 1100 Kermit
The University of Wisconsin is retiring its Sperry 1100, and Paul Stevens,
the author of Sperry 1100 Kermit, will no longer be able to actively
support the program. Is anyone out there willing to take over? Volunteers
please send mail to Info-Kermit@CU20B.COLUMBIA.EDU, or write to the Kermit
Distribution address (network-connected volunteers preferred). Thanks to
Paul for all his contributions to Kermit culture over the years!
------------------------------
Date: Thu, 11 Dec 86 14:02:15 cst
From: knutson@huey.cc.utexas.edu (Jim Knutson)
Subject: More on Multiple CDC Kermits
Keywords: CDC Kermit
RE: [Steve Roseman <LUSGR@LEHICDC1.BITNET>: More on Multiple CDC Kermits]
Personally, I feel that the CDC versions of kermit for the version I wrote
(the fortan version), should probably be split into seperate versions. The
code for trying to manage several operating systems and approximately 5
different character sets is horrendous. I would be in favor of ripping out
all non-nos code (that means NOS/BE and, sniff, UT-2D). A NOS/VE version
will probably have to be done seperately because of the word size
differences and all. I have not had many calls from NOS/BE sites lately and
very few calls from NOS/VE sites as well.
However, I must say that I really haven't been maintaining the Cyber version
of Kermit for quite a while now so perhaps my suggestions should be tempered
by that.
------------------------------
Date: Sun, 23 Aug 1987 15:02 MDT
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
Subject: Kermit 80 Version 4.08 (pre-release) Files
Keywords: CP/M Kermit
With great expectations I today got the KER:CX*.* files for the CP/M Kermit
4.08. Imagine my surprise to find that all the ASM modules which previously
had been individual files for ease in editing were now all together in one
HUGE 780k file!!!
The ONLY reason that LASM was used in the first place, instead of the stock
CP/M assembler, was so the pseudo instruction LINK could be used at the end
of each module.
The present form of the source code is, in my opinion, unusable. Bertil has
removed ALL tabs from the source, making it even larger. His reasoning was
that people were messing up the source by getting it through hosts that
change a tab to a single space. This is probably true, but the file is too
large to handle. It must be broken down into its individual modules again
to make it manageable by potential users. I can't even edit it on my CP/M
DDDS 1.2 megabyte floppy system.
Keith
[Ed. - Our fault. We had to crunch the files together because of a severe
space problem on our tapes. As you know, file marks are expensive. The
idea is that once some CP/M aficionados like yourself get a chance to try it
out and bless it, it can replace the old CP/M Kermit files, KER:CP4*.*, and
then there will be plenty of room to store the files separately. For now,
and for FTP access only, the .ASM source files are available separately as
K7:CP*.ASM on CU20B (note, K7). Please take them and try them out, and send
any comments to Info-Kermit@CU20B, whence they will be relayed to the
author, Bertil Schou at Loughborough University in England, who is anxious
for feedback. By the way, the files were joined together using a simple
Unix Bourne shell script, a copy of which is in K7:JOIN.SH. They were
unjoined with a C program, which is in K7:UNJOIN.C.]
------------------------------
Date: Mon, 24 Aug 1987 10:15:10 ULG
From: Andre PIRARD <A-PIRARD@BLIULG12>
Subject: EBCDIC and ASCII Definitions
Keywords: EBCDIC, ASCII, Multinational Character Sets
EBCDIC definition from the "Principles of operations" IBM manual only covers
English characters and is old story.
There is now an ISO 8859 definition for EBCDIC. It extends the code to other
languages needs. Because you can imagine all languages don't fit in a 256
set, the standard is split into mutltiple definitions of which the most
widely used is ISO 8859/1 (Latin Group 1). It is a superset of the former
EBCDIC, but shows some trouble with the former loose definition of brackets,
vertical bar and exclamation mark.
IBM has started using ISO 8859/1 with its so-called table 500. They have a
3274 RPQ 7L0577 and various peripheral support for it.
ASCII has its own ISO extended definition(s?) too, but I'm sorry not to know
the number. However I can say IBM now started using it in an alternate
codes definition for its new PS/2 microcomputers series. They put it a name
of their own blend: "Code page 850".
So, if anyone does not know what to do with undefined EBCDIC and ASCII
codes, here is the answer to increase a program's usability by a factor.
These standards are probably not well known in America, because of little
need, but it's relieving that IBM now accepts international standards and
uses its position to promote them.
[Ed. - 7-bit ASCII is ANSI standard X3.4 and ISO 646 and CCITT T.50.
ANSI X3.32 specifies graphic renditions for control characters.
ANSI X3.41 and ISO 2022 give 8-bit code extension techniques for ASCII.
ANSI X3.134.1 & ISO 4873 specify an 8-bit code for information interchange.
ANSI X3.134.2 specifies an 8-bit ASCII multilingual character set.
ISO 6937 specifies coded character sets for text communication.
See discussion about Swedish character sets in Info-Kermit V5 #1, 14 Jul 86.]
------------------------------
Date: Wed, 26 Aug 87 19:59 CDT
From: Dave Bell - ACADEMIC CONSULTANT (U. of Winnipeg) <UOWDJB@UOFMCC>
Subject: Transferring WordPerfect Files
Keywords: WordPerfect
I'm having problems transferring a WordPerfect file. The file I'm trying to
transfer (PC to a VAX) contains the WordPerfect document plus the printer
ESC codes. When I try to Kermit it across I get the following error from
the VAX Kermit:
%KERMIT32-E-REC-TO-BIG Record to big for kermits internal buffer.
Can anybody help with this, as I'm a novice user of Kermit I'd appreciate
any help I could get. Thanks in advance.
David Bell
Academic Consultant
Computer Services
E-mail: UOWDJB@UOFMCC.BITNET
V-mail: 204/786-9494
S-mail: Computer Services,
The University of Winnipeg,
515 Portage Avenue,
Winnipeg, Manitoba,
Canada R3B 2E9
[Ed. - Most likely, Wordperfect is delimiting lines with special codes,
rather than CRLFs, so that the VAX does not recognize the intended lines as
separate records. Rather, it sees them all as one very long record, which
causes its record buffer to overflow. Unfortunately, VMS Kermit doesn't
provide a mechanism to expand the buffer size. Workarounds would be (a)
transfer it as a binary file, or (b) translate to regular ASCII text before
transmission.]
------------------------------
Date: 30 Aug 1987 20:58-CDT
From: SAC.DYESGPF@E.ISI.EDU
Subject: MSBPCT.PAS
Keywords: MSBPCT, .BOO Files
After I read about the improved performance of MSBPCT.PAS (compared to
MSBPCT.BAS) I down-loaded this file from Columbia and tried to use it. My
compiler gave 33 warnings and 50 errors. I am using a MicroSoft v3.11
compiler which is essentially a UCSD compiler with system enhancment.
Additionally, I have modified the BEGXQQ module (specifically the DOSXQQ)
routines to allow full use of the MS-DOS v3.xx function requests and full
access to registers. This has not presented any problems when modifying and
recompiling programs created prior to making the mods.
I assume that this program was written for turbo-pascal since it is not
compatible with either "standard" or UCSD PASCAL (yes - there are switches
which can be entered on the command line to make the MicroSoft PASCAL
compiler act like a less capable compiler).
If anyone knows a source for a public domaine turbo compiler, I would
appreciate pointers. Since I mostly program in assembly and turn to PASCAL
only when string manipulation is too complex or the program is exteemly long
I will not spend my money on a turbo compliler.
Although I realize there may be some who disagree with me, I suggest that any
future postings in PASCAL be more generic in nature.
Al Holecek
SAC.DYESGPF@E.ISI.EDU
[Ed. - We can't discourage people from writing in Turbo Pascal -- it's fast,
cheap, and a lot of people have it. Microsoft or IBM Pascal may be more
standard, but it's less common in the world due to price. Anyway, there are
versions of MSBPCT also written in Assembler and C. The C version is also
available in .BOO file form, so you don't need a C compiler to run it, just
MSBPCT.BAS to translate it to .EXE form (and then you don't need MSBPCT.BAS
any more.]
------------------------------
Date: Mon, 31 Aug 87 11:09:50 CST
From: Mike Sorsen <SORSEN@WUVMD.BITNET>
Subject: 7171 Causes CMS Kermit Problems When Flow Control Used
Keywords: CMS Kermit, 7171, Yale IUP
There is a bug in the 7171 that causes CMS Kermit file transfers to abort in
the middle of a SEND after a large number of retries. The symptoms are that
during a SEND by CMS Kermit through a 7171 CMS Kermit violates the Kermit
protocol by retransmitting a packet before other Kermit can respond when
XON/XOFF flow control was used by the receiver or when XON/XOFF flow control
was used by other hardware in between the 7171 and the receiver.
This bug was observed using CMS KERMIT 3.1 running under VM/SP 3.1 (PUT 8409
SLU 311) through a 7171 at EC A31864 to MS-DOS Kermit version 2.29b.
I have not done any testing with 4994s or Series/1 boxes running the
Yale IUP. They provide the same function as the 7171 for an IBM host.
The sequence of events is this:
CMS Kermit sends a packet using transparent write/read. The receiver or
other hardware in between the 7171 and the receiver sends a pacing stop
(XOFF) and then a pacing start (XON) to the 7171 while the packet is being
sent by the 7171. The 7171 performs the pacing, but when the transparent
write part of the transparent write/read is complete it ends the transparent
read prematurely, returning X'93' (XOFF) to Kermit as the reply to the
packet sent out. CMS Kermit rejects this and retransmits the packet, which
causes a breakdown of the Kermit protocol. The breakdown occurs because the
recieving Kermit usually starts transmitting an ack to CMS Kermit while the
packet is being retransmitted.
I am currently chasing this problem though the IBM support structure, but I
doubt that they will issue a new EC for this problem.
Circumventions:
Set the 7171 flags so that XOFF is not a valid termination of a transparent
read. See page 4-20 of 'IBM 7171 Reference Manual and Programming Guide',
IBM publication number GA27-0021. This has been tested at our site and
found to circumvent the bug even though the XOFFs are being transmitted
during the transparent write part of the transparent write/read order and
this flag concerns the transparent read part of the order.
or
Change the CMS Kermit datastream so that CMS Kermit uses a transparent write
order instead of a transparent write/read order. The CMS Kermit code is
written to allow for either order in the write datastream. The byte at label
WRRD (X'128E' in my assembly) should be changed from X'05' to X'00'. I have
not tested this circumvention.
Mike Sorsen <SORSEN@WUVMD> or <SORSEN@WUCFUA.WUSTL>
Computer Services Systems Group - Campus Box 1152
Washington University - St. Louis, Missouri 63130
Phone: (314) 889-6460
[Ed. - Thanks for the report Mike. This has been added to the CMSKERM.BWR
file.]
------------------------------
Date: 2 Sep 87 00:02:33 GMT
From: sri-unix!cole@RUTGERS.EDU (Susan E. Cole)
Subject: Need HP150 Kermit on diskette
Keywords: HP150 Kermit
I am trying to help someone who has an HP150 obtain a copy of Kermit on a 3
1/2" disk in a format the HP150 can read. The person says she has no
compilers or assemblers so we can't download source code and put the program
together on the 150.
So -- does anyone know how she can get it?
Thanks.
Susan Cole
usenet: !hplabs!sri-unix!cole
ARPA: cole@unix.sri.com
[Ed. - A popular request. Any volunteers? For that matter, are there any
volunteers to distribute ANY versions of Kermit on native media for ANY
systems that Columbia cannot provide?]
------------------------------
Date: Wed, 12 Aug 87 15:54:10 MEZ
From: Erich Neuwirth <A4422DAB%AWIUNI11.BITNET@wiscvm.wisc.edu>
Subject: Kermit for a Bondwell?
Keywords: MS-DOS Kermit
I have a problem with a Bondwell 8 amd Kermit.
I have tried 3 different versions:
MSVIBM hangs the system completely.
MSVGEN does not work. Either it states
Disk error reading device COM1
Abort, Retry, Ignore?
or when i have done
set port 2
I get
?Warning: Cannot open com port
Enter a file handle.
and so on.
Entering 3 does not help, then the system again hangs completely.
MSVCLO works almost
In connect mode it works fine, but as soon as I get out of that mode
status shows baud rate set to 1800. Resetting it and issueing any
transfer command (get, receive, remote dir ....)
generates an error msg about not being able to communicate to host
and then again the baud rate setting is shown to be 1800.
I think the com port must be rather uncoventional in that machine.
Does anybody have any experiences?
P.S.: Setting the other machine to a baud rate of 1800 does NOT help.
------------------------------
Date: Fri, 4 Sep 87 14:47 EST
From: <PEPAP@CFA1.BITNET>
Subject: VMS Kermit version 3.2.076 STATUS Command
I have checked the documentation for recent releases of Kermit-32 and I see
no mention of a problem I have just noticed in version 3.2.076: when I issue
the STATUS command after finishing one or more transfers, the display shows
an effective data rate that is either 0 or garbage (approximately 2**32).
Is this a feature that has never been properly implemented? Has it been
fixed in subsequent releases without being mentioned in the announcements?
We are now running VMS 4.4 - does that have anything to do with the problem?
[Ed. - Wierd. We tried it on VMS Kermit 3.1 and 3.3 under VMS 4.3 and got
correct reports in both those versions. Don't have a copy of 3.2 handy, but
it seems unlikely that it would be broken in 3.2 but not 3.1 or 3.3...]
------------------------------
End of Info-Kermit Digest
*************************
-------