SY.CHRISTINE@CU20B.COLUMBIA.EDU.UUCP (03/27/87)
Info-Kermit Digest Thu, 26 Mar 1987 Volume 6 : Number 8
Today's Topics:
Announcing Kermit for the Sinclair QL
Announcing Kermit for TRS-80 Model II
Announcing Kermit for Data General running RDOS
UUDECODE for BITNET
AP2 (Apple and Apollo) Kermit Name Clash
KERMSRV access
Re: Problem with VAX/VMS Kermit
Request for DTR control in VAX/VMS Kermit
Re: SET ETOA/ATOE in CMS KERMIT
More on ASCII/EBCDIC translation
TRS Model 1
C-Kermit changes needed for Zilog systems under Zeus 3.21
C-Kermit for AOS
Kermit-11 Problem Discovered and Solved
SANYO MBC555 AND KERMIT
----------------------------------------------------------------------
Date: 13-MAR-1987 11:20:54
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Announcing Kermit for the Sinclair QL
Keywords: Sinclair QL Kermit
It has come to my notice that there is a demand for Kermit on the Sinclair
QL. As I've written an automated file server to connect several QL's to a
Xenix machine that is based on the Kermit protocol, I feel I ought to let
you have what I've accomplished on the basis of providing a development
source for anyone interested in taking it further. There is a full
description of how the version developed and what it can and cannot do in
QLKERM.DOC
I would recommend users to use floppy or RAM disks due to the slow and
unreliable nature of the Microdrives. Floppy disks are an essential requirement
for any further development.
The source files have been renamed to fit the standard 6.3 convention. To
compile from source they have to be renamed as follows:
Current Name Original Name Usage
------------ ------------- -----
QLKERM.DOC QLK_DOC usage and comments
QLKERM.LNK QLK_LINK Metacomco linker control file
QLKMAIN.C QLKMAIN_C main module
QLKKER.H QLKKER_H main header file
QLKSWITC.C QLKSWITCH_C state table switcher
QLKUS1.C QLKUSR1_C top level command parser
QLKUS3.C QLKUSR3_C parameter setter
QLKUSR.H QLKUSR_H parser header file
QLKCMD.C QLKCMD_C command prompter/editor
QLKCMD.H QLKCMD_H editor header file
QLKFNS.C QLKFNS_C base level functions
Compilation also needs stdio_h, ctype_h and qdos_h as supplied with the
Metacomco 'C' development kit.
Suggestions for enhancements are:
A proper terminal emulator ( preferably VT100 ) - the need for this is
so great that I could be tempted to do this myself if only I could obtain an
example 'C' source ( for any machine ).
Rebuilding wider functionality, including the help, that I have removed
to minimise storage requirements.
Please note that I will be moving to a new job in Cambridge in mid-April, so
would like to wash my hands of QLKermit, as it were, but I would be happy to
answer any queries people may have.
Robert Coughlan,
Department of Surgery,
Liverpool University,
PO Box 147,
Liverpool L69 3BX
UK
(051) 709 - 0141 x 2670
[Ed. - Thanks for the new Kermit version. The files are in KER:QLKER.*
available using FTP to CU20B (login user ANONYMOUS - any password) and
through BITNET via KERMSRV.]
------------------------------
Date: Mon 23 Mar 87 11:26:46-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Announcing Kermit for TRS-80 Model II
Keywords: TRS-80 Kermit
A new version of TRS-80 Kermit has been developed by Serge G. Kruk, Systemes
Temps Reel, 1030 Hodge, St-Laurent, Quebec, Canada H4N 2B7 ((514) 748-0515).
This implementation of the Kermit protocol is for the Radio-Shack Model II
running under TRSDOS. This version of the Kermit protocol implements only
send and receive capabilities using the one-character checksum.
Known Bugs include:
- Command parsing and recovery is minimal.
- During a file transfer, TRSKER remains silent. Only the noisy
- disk accesses of the equipment will tell you that a transfer is
in progress. (But completion status is unambiguous...)
- TRSKER uses the TRSDOS clock interrupt services to timout an
unanswered packet but it does'nt seem to work all the time...
[Ed. - These files are in KER:TR2KER.* available through BITNET via KERMSRV
and by using FTP to connect to CU20B.]
------------------------------
Date: Mon 23 Mar 87 11:26:46-EST
From: Christine M Gianone <SY.CHRISTINE@CU20B.COLUMBIA.EDU>
Subject: Announcing Kermit for Data General running RDOS
Keywords: Data General Kermit, RDOS Kermit
This version is a modification for RDOS of the version of Torbjorn Alm & Per
Lindberg for the ABC-800. It was modified by Remi Castonguay. The only
file sent to Columbia was the source code, written in BASIC.
[Ed. - The BASIC code is in the file KER:RD2KER.BAS. Please report any bugs
to Info-Kermit@CU20B.]
------------------------------
Date: Fri 20 Mar 1987 11:51:19 CST
From: Mark S. Zinzow <MARKZ@UIUCVMD>
Subject: UUDECODE for BITNET
Keywords: UUDECODE, BITNET
When mail goes somewhere via bitnet there are two problems. One is that
tabs get eaten by ASCII <--> EBCDIC conversion, which is a pain for source
code text. The other is that trailing spaces are stripped off. This is nice
for cutting useless characters from mail, but uuencoded files suffer. My
enhancement is to put the spaces back. Someone has written a uuencode that
puts an extraneous character at the end of each line which also solves the
bitnet problem on the sending end.
I realize that the four if's in outdec would be better rewritten as one
for loop, but I was tired when I fixed this last night and it works close
enough.
[Ed. - Thanks! This version of UUDECODE is in KER:UUDECO.C.]
------------------------------
Date: 13-MAR-1987 11:20:54
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: AP2 (Apple and Apollo) Kermit Name Clash
Keywords: Apple Kermit, Apollo Kermit
Doubtless you've had a lot of people telling you this, but we now have two
Kermits with prefix AP2! (one is the new Apollo stuff, the other the very
old Apple native assembler version).....
Alan
[Ed. - No, Alan, you were the only one who mentioned this. Ooops... The
new version of Apollo Kermit, formally named AP2*.* is now named APL*.* in
KER:. Thanks for catching this.]
------------------------------
Date: 03/17/87 14:41:34 CET
From: UF02%DDAGSI3.BITNET@wiscvm.wisc.edu
Subject: KERMSRV access
Keywords: KERMSRV
Hello! I want to bring some information regarding KERMSRV access to your
attention.
In INFO-KERMIT V6 #7 you wrote that KERMSRV can be accessed from BITNET via
'SMSG RSCS MSG CUVMA KERMSRV HELP'. This command is only valid for VM
machines, I suppose. We have a MVS (Man Versus System) machine here where I
can only use
'SMSG KERMSRV AT CUVMA HELP'. But all I get is 'INVALID COMMAND HELP'.
The correct form to get an answer is 'TELL KERMSRV AT CUVMA HELP'. Then I'm
notified that 'KERMSRV INFO' has been sent to me and it really arrives!
I hope this information is of some use for you.
Frank Schwab
069/798-8238
Institut fuer theoretische Physik
Robert-Mayer-Str. 10
D-6000 Frankfurt/M.
[Ed. - Sorry about the confusion. The KERMSRV syntax changes with every
machine it seems. Here's what we know about so far:
VM/CMS: TELL KERMSRV AT CUVMA HELP (or SMSG RSCS MSG CUVMA KERMSRV HELP)
MVS/TSO/E: TELL KERMSRV AT CUVMA HELP (may be site dependent)
VMS JNET: SEN/REM CUVMA KERMSRV HELP
UNIX UREP: netexec cuvma msg cuvma kermsrv help
Does anyone have any additions or corrections?]
------------------------------
Date: Tue, 10-MAR-1987 19:28 PST
From: Mike Iglesias <MIGLESIAS%UCIVMSA.BITNET@wiscvm.wisc.edu>
Subject: Re: Problem with VAX/VMS Kermit
Keywords: VAX/VMS Kermit
As I remember, you can't rebuild VMS Kermit from the macro sources because
they're not all up to date (some are from 3.2.076, some from 3.2.077). You
have to take the KERMIT.HEX (not sure about the file name) file and de-hex
it using VMSDEH.MAR, also available from columbia. I reported it a long
time ago (when 3.2.077 was released), but I guess it hasn't been fixed yet.
Version 3.2.077 fixes your problem with FORTRAN carriage-control files.
I've never seen your problem with the parity settings; I always use no
parity from MS-DOS Kermit v2.28/2.29 and have never had any problems
transfering files to our VMS systems.
Mike Iglesias
University of California, Irvine
miglesias@ucivmsa.bitnet
iglesias@ics.uci.edu
[Ed. - We expect a newer release (3.2) from Stevens shortly.]
------------------------------
Date: Thu, 12 Mar 87 10:38:09 aest
From: Andrew Hunt <munnari!rpepping.oz!ANDREW@seismo.CSS.GOV>
Subject: Request for DTR control in VAX/VMS Kermit
Keywords: VAX/VMS Kermit
Would it be possible for the implementors of VMS Kermit to add modem (DTR)
control to the program. This would involve setting DTR on on the KER$COMM
line (maybe if only different from TT:) and implementing the HANGUP command
to allow it to be cleared. This would make it compatible with MS-Kermit
V2.29+ and allow easier use with modems and terminal switchers whih require
DTR to be set before they will lissen to you.
Many thanks in advance, ...Andrew HUNT, CSIRO Radiophysics, Australia.
------------------------------
Date: Tue, 03 Mar 87 09:03:10 SA
From: "Kai U. Leppamaki" <LK-KLE@FINHUT>
Subject: Re: SET ETOA/ATOE in CMS KERMIT
Keywords: VM/CMS Kermit
I trust you still have your sketch readily available so I'm using the same
ETOA/ATOE table numbers you did.
You saw no reason why the first half of table 2 (and 4) should not match the
first half of table 6. On our site they mostly do not ! On a site which
uses national (7 bit) character sets the first half of table 6 may vary from
file to file i.e. the user may have used the local national (7 bit ASCII)
character set for one file and the American convention for another. This is
very often the case when one receives text files from various parts of the
world.
Since the system table (4) can represent only one of the conventions there
is an apparent need for an independent table which can be freely modified on
the fly. On our site the system tables (for tty lines) have not been
modified and they still reflect the American convention. This is to minimize
the effort needed to maintain the tables. Most of the text files use the
Finnish national character set (ASCII or EBCDIC) but many do not.
The problem originally raises from the stupid fact that the national char
replacements are different in EBCDIC than in ASCII !! E.g. the Finnish
"umlauted" upper case "A" (two dots on top) replaces the left bracket in
ASCII whereas in EBCDIC it has stolen the place of a "#" !
This is why we cannot get along with only one translation table but need at
least two alternatives. The tables 2 & 5 must always match the system tables
3 & 4 (and never really need to be modified) whereas tables 1 & 6 must match
the character set CURRENTLY in use.
With only 8 bit "multinational" ASCII sets (with the first 128 codes
matching the American usage) your reasoning obviously holds but not if 7 bit
national variations are used !
Do you agree ?
------------------------------
Date: 1987 Mar 17 14:26 EST
From: (John F. Chandler) <PEPMNT@CFAAMP.BITNET>
Subject: More on ASCII/EBCDIC translation
Keywords: ASCII/EBCDIC Translation
It seems that the European experience includes a problem I didn't
consider in my analysis of the number of distinct A/E translation tables
needed in a Kermit-370. In essence, the problem is that different
conventions for the national characters can exist for different terminals
and off-line sources of text, and the differences can affect the 7-bit
half-table for ordinary "ASCII" characters. This is similar to what
happened after the replacement of 026 keypunches with 029's (BCD with
EBCDIC). I'm afraid that a complete solution is beyond the scope of Kermit
because, in all likelihood, there are already files on disk at such sites
making use of the differing conventions. In the case of BCD vs. EBCDIC, the
FORTRAN compilers (for example) were equipped with optional automatic
translation of the input source. Sadly, the situation is more complicated
when one considers all varieties of text, but something of the sort might
still be possible. As a fallback position, though, it would be necessary to
adopt a scheme that does an extra translation, either by making a translated
copy (as in using the COPYFILE TRANS option for CMS users) or by translating
before writing on disk in the first place (as in the extra Kermit tables).
The former approach solves the problem for all time (old files using one
convention can be converted at any time), but the latter would seem to be
more efficient (at least, if used consistently). Adding such a Kermit
function would require two new SET commands. Does anyone have any ideas on
what they should be called?
John
------------------------------
Date: Mon, 16 Mar 87 21:03:01 EST
From: Charles L Oei <burdvax!thing2.PRC.Unisys.COM!oei@seismo.CSS.GOV>
Subject: TRS Model 1
Keywords: TRS Kermit
I have several remarks though that you might want to put into a .BWR file
for future users of Kermit for the TRS80 Model 1 running TRSDOS 2.3:
Of the files that are distributed, a person really only needs to see:
TRSMIT.DOC.1 and TRSMAKE.BAS.1
The others are either Z80 assembly language source code (for good latenight
reading), or miscellaneous/extraneous files that are of no real consequence.
[TRSDNLD.BAS.1 when downloaded and ran produces correct checksum, but
the resultant /CMD file doesn't seem to run correctly (at least the couple
of times I tried it -- it could otherwise, but I didn't want to invest any
more time since TRSMAKE did work satisfactorily).]
When TRSMAKE.BAS is downloaded and ran, don't worry about that it says
that the checksum is wrong, it's probably just fine. Here are the checksums
that TRSMAKE says it should be and what I get, respectively: 976487 976454
There are two problems (of any real consequence) with the resulting
KERMIT/CMD file:
1) not so bad is that vt52 emulation doesn't work
2) The other is that I couldn't talk w/ other Kermits unless I set
set the parity to "space". The Kermit on the other end doesn't
have to set its parity to space though. [After this, all
went well].
Also, some annoying things that I had with it were:
in terminal "connect" mode, I have no cursor;
the <break> key in command mode doesn't appear to "abort" a command,
but the <clear> key seems to do the trick anyway;
in "connect" mode, the <control> key designation doesn't work either.
Oh, and probably some other minor things too, but overall, it's great.
At least it works and sends/receives files better than raw transfers
sans error checking.
Thanks to Stan Barber and the original writers of CP/M 80 Kermit.
Charles Oei
[Ed. - Thanks for the report. It's now in the TRSMIT.BWR file.]
------------------------------
Date: 19-March-1987
From: J.M.Saunders, British Aerospace plc
Subject: C-Kermit changes needed for Zilog systems under Zeus 3.21
Keywords: C-Kermit, Zilog, Zeus
At present we have two Zilog 8000 systems running Zeus 3.21. Detailed below
are the changes made in order to get a working version: they are mostly to get
around apparent compiler bugs.
Kermit was built using "make sys3". We got around the setjmp and longjmp
problem by defining these to be the same as longret and setret in include
files.
The changes to C-Kermit for Zilog were contained in ckutio.c and ckufio.c
CHANGES TO CKUTIO.C:
These can be split into 3 parts: ensuring the terminal settings were read and
set correctly, getting non-canonical processing to work correctly, and making
the lockfile format compatible with that of current software.
1. Terminal settings
The ioctl call did not put the terminal settings into the termio structure, and
any modifications made were ignored. This was traced to an apparent bug in the
compiler, which was cured by changing the storage class of the termio structure
from static to the default in the variable declarations
2. Non-canonical mode
As soon as the interactive prompt appeared, Kermit returned to Unix command
level. This was traced to the terminal settings. If the wait time setting
c_cc[5] is non-zero, ^A's are sent whilst the machine is waiting. These were
being interpreted as EOF characetrs instructing Kermit to tidy up and exit.
The problem is cured by setting c_cc[5] to zero in all cases where
non-canonical mode was used (modes set in concb and conbin)
3. Lockfile
uucp on the Zilog requires the username and terminal of the person using the
remote line and not a pid number. The changes made (apart from variable
declarations) were in look4lk :
CHANGES TO CKUFIO.C:
The problem here is to do with file names being garbaged when wild card
characters were used. The name of the first file to be transferred was being
corrupted, due to corruption of the pointer to it. This had no visible
explanation and was put down to a compiler bug. The fix is in the form of a
kludge that ensured that the 0th location in the array was not used (i.e. names
are stored from element 1 onwards). Changes were made in the znext, znewn and
fgen functions as below:
OTHER BUGS:
The only other bug found was that trailing nulls are sometimes removed from
binary files in transfer.
J.M. Saunders,
Daisy CAE Support Engineer,
British Aerospace plc,
Naval and Electronic Systems Division,
Dept 399, FPC 126,
PO Box 5,
Filton, Bristol, UK BS12 7QW
[Ed. - Many thanks for the report! The code differences have been omitted from
the above, as some of them are fairly lengthy, but this entire message
including the code has been added to CKUKER.BWR (the Unix Kermit "beware"
file).]
------------------------------
Date: Wed, 11 Mar 87 16:51:33 EDT
From: LAMB@Lids.mit.edu (RHL)
Subject: C-Kermit for AOS
Keywords: C-kermit, AOS
Last I looked there seemed to be no C-kermit for the Data General AOS
operating system. So Ive hacked up a version. All functions (server, local)
seem to work fine on our machine but id like to try it on others before
making it public. Is anyone else with a DG machine willing to try C-kermit?
My machine: MV20000
Operating SYS: AOS/VS V7.53 (with MV/UX overlay unix)
C compiler: AOS C V3.21
My goal is to make C-Kermit work under AOS/VS only. Send feedback to
Lamb@lids.mit.edu
or ..ihnp4!mit-eddie!lids!lamb
Thanx , Rick Lamb
[Ed. - The same thing has also been done elsewhere, and we're expecting it
to arrive "any day now".]
------------------------------
Date: Mon, 23 Mar 87 13:00 EST
From: Lewis M. Dreblow - PSYCH at UFFSC
Subject: Kermit-11 Problem Discovered and Solved
Keywords: Kermit-11
I wish to inform the user community of a problem which occurred with the
K11 release of Kermit. I was trying to use kermit on a 11/23 running RTV5
and TSXV5. I had no trouble using the release as a server, but kept getting
hung whenever I tried to do a get or send to another remote server. It
didn't matter what machine was on the server end. After about a month of
tearing my hair out I discovered that I had TSGENed IOABT = 0 which caused
TSX to wait for IO completion on jobs. This seemed fine at TSGEN time, but
due to the .ABTIO MCALL in K11PRT caused kermit to hang for two minutes at
every get or send command.
Thus, users should be aware that they have to either (1) TSGEN IOABT = 1
or (2) at the command line (or in a command file) prior to running kermit
issue the SET IO ABORT command. You may want to remember to SET IO NOABORT
after running kermit as well.
[Ed. - Thanks for the report; it's been added to the K11.BWR file.]
------------------------------
Date: 17 Mar 87 00:37 GMT
From: cfac-cso @ Walker-EMH.arpa
Subject: SANYO MBC555 AND KERMIT
Keywords: SANYO Kermit
I have just obtained a copy of Kermit and attempted to run it on my Sanyo
MBC555 with video interface card. I am using XXXMBC.XXX version of Kermit
and I cannot utilize the autoanswer function of my Smartmodem 300 utilizing
my RadioShack model 100. Does anyone have any suggestions?
G. Lyford
CFAC-CSO@WALKER-EMH
------------------------------
End of Info-Kermit Digest
*************************
-------