SY.CHRISTINE@CU20B.COLUMBIA.EDU (Christine M Gianone) (09/20/86)
Info-Kermit Digest Fri, 19 Sep 1986 Volume 5 : Number 10
Today's Topics:
Alternate BITNET Kermit Distribution at University of Toledo
Os9 Kermit from os9 Users Group
Using C-Kermit on VAX/VMS for Mail Spooling
MS-DOS Kermit with Different Character Sets
More on Wanted: Kermit for the Apple][
Help with Installing VMS Kermit
VAX to PC Binary File XFERS
MVS/TSO and Apple II Kermit Gluts
Problems with Atari ST Kermit
Uuencoded Files and Trailing Blanks
----------------------------------------------------------------------
Date: Fri 19 Sep 86 14:31:37-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Alternate BITNET Kermit Distribution at University of Toledo
Keywords: BITnet
The collection of Kermit files at the University of Toledo VAX-11/785
is now being updated on a weekly basis. BITNET sites that have trouble
getting a response from CUVMA (due to congestion) are welcome to try
KERMSRV at UOFT02. To get started with KERMSRV (at either CUVMA or
UOFT02) give the command:
SMSG RSCS MSG xxxxx KERMSRV HELP (from CMS)
or
SEND KERMSRV@xxxxx KERMSRV HELP (from VAX/VMS with Jnet)
where "xxxxx" is either CUVMA or UOF02. Thanks to Brian and to the
U of Toledo Computing services for helping to ease BITnet congestion.
------------------------------
Date: Fri 19 Sep 86 05:52:04-PDT
From: Bob Larson <BLARSON@USC-ECLB.ARPA>
Subject: Os9 Kermit from Os9 Users Group
Keywords: Os9 Kermit
Os9 kermit is available from the Os9 users group as disk 48. (The latest
disk listing I have from them has this mislabeled as 68k only and lists disk
37 as the 6809 version. The version on disk 37 has quite a few bugs that
are fixed in the version on disk 48.) Since several things are determined
at compile time, it's a good idea to have the C compiler available even if
they claim to supply a compiled version.
Membership in the Os9 users group is $25/year and includes disk 0 and MOTD
their monthly newsletter. Send Name, address, computer type, os9 type and
level, and disk format to:
The Os9 Users Group
Attn: Membership
9743 University Ave.
Suite 330
Des Moines, IA 50322
Disk orders from members should be sent to the same address, Attn: Disk
order. Disks are $5 for 5", $8 for 8", $80 for the works on 5" 80 track
DSDD standard os9. Disk orders are accepted from members only.
[Ed. - Thanks for the information. This Users Group has been added to our
KER:AADISK.HLP file, with the terms outlined.]
------------------------------
Date: Tue, 16 Sep 86 09:44:36 pdt
From: varian!david@lll-crg.ARPA
Subject: Using C-Kermit on VAX/VMS for Mail Spooling
Keywords: C-Kermit, VAX/VMS Kermit, Scripts
We use C Kermit (058) under VMS here. I wrote some scripts that run kermit
unattended in order to send mail from UNIX to VMS.
[Ed. - Thanks for the scripts! Since they are rather long, we've put them in
the Kermit distribution as CKVKER.SCR.]
------------------------------
Date: Wed, 13 Aug 86 16:40 N
From: Kimmo Laaksonen <KLAAKSON@FINFUN.BITNET>
Subject: MS-DOS Kermit with Different Character Sets
Keywords: MS-DOS Kermit, Character Sets
The internal translation feature allows MS DOS Kermit user to change
external character codes to MS DOS internal codes within Kermit, and vice
versa. This feature is mainly intended for text display and file transfer in
non-English speaking countries, where "national" characters in a remote host
are assigned to codes that have another graphics representation in a
"standard", ie. Anglo-American, character set (some "standard" graphics are
replaced with national grahics - in terminals, line printers, etc.). In a PC
there is an extended character set, where both "standard" and "national"
characters can be intermixed in text files. The internal translation
supports full 8 bits, so it can be used to map different 8 bit character
sets to each other, too, like the DEC set (eg. in VT200 series) to the IBM
PC set and vice versa.
Without translation a text file prepared on the remote host will look
strange because the PC will display the "standard" graphics instead of the
national graphics, when the file is typed on PC screen via Kermit terminal
emulator, or when it is transferred to PC as a file with Kermit and then
looked upon with a text editor in PC. Respectively a text file prepared in
a PC and transferred with Kermit to a remote host looks strange because
different codes are used to represent national characters in remote host
output devices.
MS DOS Kermit internal translation is an elegant solution to this situation.
There certainly exist separate programs to do the necessary code
conversions. One problem with them is that at least twice the file space is
required, which may turn out to be impossible in a PC if the file is large.
Another problem is the extra time required for running a separate conversion
program. Translation overhead within MS DOS Kermit is negligible.
Translation does NOT affect the Kermit protocol, ie. translation is
done outside Kermit packet assembly/disassembly. The new commands
for translation are:
SET XLATION object [parameter(s)]
The following objects are available:
ALL Affects all translations. Valid parameter values are ON
or OFF. ON is the default !
DISPLAY Controls translation of characters received DURING Kermit
terminal emulation, ie. what is displayed on the screen.
Does not (should not?) affect terminal controls, eg. ESC
sequences.
PRINT Controls translation of characters received and output to
printer DURING Kermit terminal emulation.
SEND Controls translation when transferring files FROM the PC.
RECEIVE Controls translations when transferring files TO the PC.
Parameters:
OFF Turns translation OFF for the selected object. Respective
translations must be OFF to properly SEND and RECEIVE
binary files, eg. .EXE, .COM, etc.
ON Turns CURRENT translations on for the selected object.
The Finnish convention is the default for all
translations (guess why).
INITIAL Resets a translation table to an identity table ie. all
possible 8 bit codes are translated to them selves. It is
good practice to initialize a translation table before
starting to build a new translation.
EXPAND Copies the lower half, ie. first 128 translations, to the
upper half of the selected translation table. This is a
useful feature when only the 7 lower bits (as in ASCII)
are meaningful and the 8th bit (ASCII parity) is a "don't
care".
CODE base nnn base nnn
This parameter is used to actually set up a SINGLE
translation in the selected object's translation table.
The first pair (base nnn) is the original code. The
second pair is the code to which it is to be translated.
Base can be any of DEC (decimal), HEX (hexadecimal), or
OCT (octal). The actual code (nnn) is a number in the
selected base.
In addition there is a new command for terminal emulation:
SET EIGHBIT value
It controls whether MS Kermit strips the 8th (normally parity) bit
(value = OFF, the default) during terminal emulation, or if all 8
bits are used (ON). Passing all 8 bits is useful when 2 PCs are
connected together, or when connected to a DEC VAX VMS set to pass
all 8 bits. Note that the DISPLAY and PRINT translations are applied
(if ON) AFTER the 8th bit is stripped off or passed on as it is.
Some notes:
The MS DOS Kermit translation is not intended for a lay operator. It
would be best if somebody at a site prepared command file(s) to set
up (and enable) the required translations. It is usually too tedious
to give a note listing the necessary Kermit commands that a user has
to type in, although it's possible. TAKE, or even using
MSKERMIT.INI, is much easier. Anyway, since we didn't touch the SET
KEY facility, it is customary to include tailored keyboard
"translation" command files in local Kermit distribution floppies,
so adding a few new files (or including them in SET KEY command
files) for the translations suits that custom well.
Some may think that the ability to define only a single translation
for a single object at a time is too slow, but usually there are not
so many of them, well under 10 for the Finnish character set, for
example. Even mapping a full 8 bit set to another, eg. DEC character
set to IBM PC, and vice versa, doesn't require modification of all
256 codes. And when the translations are set up, they are normally
loaded from a file, which doesn't take long.
We have translation files for the Finnish language and IBM PC (of
course!), including SET KEYs, which we can send to Columbia for
redistribution. However, we think it's better to postpone sending
anything yet, because our additions to MS Kermit were done on the
2.27 version! We think it's better to wait until we have added them
to 2.29. After that we hope that translation becomes a standard
feature in MS Kermit to keep all us non-AngloAmericans happy.
If you REALLY want something fast, send queries to:
LK-KLE@FINHUT.BITNET, or
KLAAKSON@FINFUN.BITNET
(We are connected to EARN/BITNET, only.)
[Ed. - Sounds like you've really attacked the problem head-on. Still,
it's going to be tough to make everybody happy. On the one hand you've
got all the different character sets -- Finnish, Swedish, German, Spanish,
etc. -- and on the other you've got all the different hardware -- the IBM
character ROM, the DEC version (with its multifarious "country kits"),
presence or absence of all different, incompatible graphics boards, etc.
I can visualize having dozens, maybe hundreds, of character-set files to
adapt each alphabet to each kind of hardware. And then we have to deal
with people's personal preferences about which key should transmit which
code... But still, this sort of thing is badly needed in the
non-Anglo-American world. What do people think? Kimmo, maybe when you
get your hands on 2.29a (when it's finally released) you can try installing
your translation code, keeping these questions in mind. Like, maybe there's
a way to combine many mappings into one compact file...]
------------------------------
Date: 4 Sep 86 02:37:48 GMT
From: umcp-cs!cvl!umd5!zben@SEISMO.CSS.GOV (Ben Cranston)
Subject: More on Wanted: Kermit for the Apple][
Keywords: Apple II Kermit, Uppercase Terminals
Some people suggested that although they have other means of transfering
stuff from their Unix machines to their Apples I should post Kermit
anyway. So I sat down and started to upload the source. I didn't get
very far. The Apple ][ that I use doesn't have lower case. Unix is
not very friendly to upper-case-only terminals that try to use Kermit.
(To try it yourself, next time you sign on, type your userid in upper
case.)
[Ed. - What Kermit are you using on Unix? C-Kermit handles the
uppercase environment just fine, at least on 4.2BSD -- uppercase
filenames map to lowercase, etc, and since during file transfer the
line is open in rawmode, the Unix terminal driver's uppercasing does
not interfere with the packets.]
I got it uploaded to the Sperrysaur which is a case insensitive
machine. Unfortunately it doesn't like lines longer than 132
characters so I'm gonna hafta do moby "join" commands when I get it
FTPed up here.
But this exposes a pathological problem. It probably works if you
have the lower case stuff, but what should the response of Kermit be
to an unmodified Apple? Should there be a force-to-lower-case option?
Suggestions?
Oh, the other feature this Kermit has is a 70 column display-to-hires
option. It doesn't make it on a color TV, but it's barely tolerable
on my B/W set. On a video monitor it should be better...
umd5.UUCP <= {seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben
Ben Cranston zben @ umd2.UMD.EDU Kingdom of Merryland Sperrows 1100/92
umd2.BITNET "via HASP with RSCS"
------------------------------
Date: 9-SEP-1986 10:17:43
From: SYSKERMIT%vax1.central.lancaster.ac.uk@Cs.Ucl.AC.UK
Subject: Help with Installing VMS Kermit
Keywords: VAX/VMS Kermit
We've had some discussions in the UK newsletter lately with people having
trouble installing VMS Kermit and its help files on VMS. A couple of people
have contributed some ideas and command procedures to help the non-VMS
expert: I have them online here as VMSINS.HLP
Alan
[Ed. - Thanks! This file is in KER:VMSINS.HLP on CU20B.]
------------------------------
Date: 16-Sep-1986 0539
From: fulton%comet.DEC@decwrl.DEC.COM (Cathy Fulton -- CXO Technical Training)
Subject: VAX to PC Binary File XFERS
Keywords: VAX/VMS Kermit
In response to the recent messages about transferring VMS binary files
with Kermit...
I xfer VMS binary files to and from a PC all the time using Kermit. Well,
they're not really binaries, but hexified forms of binaries.
There are two programs, VMSHEX.MAR and VMSDEH.MAR, which are used to hexify
and dehexify any VMS binary. You first hexify the file with VMSHEX and then
Kermit it to the destination. The hexified file is a normal ASCII file, so
SET FILE TYPE TEXT. Upon Kermiting the file back to a VMS system, run VMSDEH
on it to restore the file to its original state.
- Cathy
[Ed. - Preprocessing is always a way around this kind of thing. VMSHEX &
VMSDEH not only hexify & dehexify the file, but preserve & restore the
FILES-11 stuff. If you're going from VAX to VAX, you can also use Kermit
to send BACKUP save sets back & forth. Still, it should be possible to
transfer fixed 512-byte-block binaries with Kermit-32, at least that's
what it says in the documentation. Maybe this could be a hot topic at
the DECUS Kermit session.]
------------------------------
Date: Tue, 16 Sep 86 21:19 EST
From: CDTAXW%IRISHMVS.BITNET@WISCVM.WISC.EDU
Subject: MVS/TSO and Apple II Kermit Gluts
Keywords: MVS/TSO Kermit, Apple II Kermit
We have been using a very nice MVS/TSO version of Kermit written in
assembler by Steve Blankenship of TUCC. He has modeled this after CMS
Kermit, and it the nicest, most powerful version we have run across for an
MVS/TSO site. It supports communications both through 3705/3725 front ends
and Series 1/7171 front ends and includes a server mode, initialization and
take files, optional log files, tab expansion, etc., etc.
Steve and Roger [Fajman] (of NIH) have been put in contact with the hope
that the two versions and the two authors could hash things out to come up
with a definitive MVS/TSO standard version. Let's hope for the best.
[Ed. - Indeed they are in contact, and there will be at least one or two
releases soon, and there's a good chance that one or more of these will
be consolidated with CMS Kermit at some time thereafer.]
As for Apple II Kermits, both Ted Medin and Dick Atlee have been working on
very nice 80-column versions. Ted's runs under DOS 3.3 and ProDOS and is
just about complete (although some distribution has already started on some
Apple II mailing lists). From what I have seen of the source, it is being
done with the CROSS assembler. Dick's version, as far as I know, is only
DOS 3.3, although it is done in Big Mac assembler - an advantage. He has
been very busy lately, and I don't know how he is coming with it. Both
myself and two other people I know of have been trying to work with Dick for
ProDOS versions of his work.
Again, in this case it would be very nice to consolidate all of this work to
one, nice version - although the release of the Apple //GS will probably
make that two versions now.
[Ed. - Ted's version has been received at Columbia, where Peter Trei,
the other Apple II Kermit person, has been trying to merge it with his
own latest version. How this will stack up against -- or eventually be
consolidated with Dick's version remains to be seen.]
A major problem with versions for machines such as the Apple is the
non-communication with Columbia on distribution and availability. If Apple
II users could follow the example (I hate to say this) of MS-DOS users, the
whole group would benefit. Take version 2.29A of MS-Kermit as a solid
example of what can happen when people cooperate to produce one, good piece
of software.
Sorry for the verbosity, but this is a subject about which I feel very
strongly, and thus far my efforts to persuade people to work with and
through Columbia for their own sakes and for the sake of the best Kermit
versions possible have been met with much adversity (in the micro world).
Any suggestions on this topic would be appreciated.
Thanks for letting me blow off some steam.
Mark
[Ed. - Yes, people should consult with Columbia before starting work on
a Kermit program to avoid this kind of duplication of effort, not to mention
filename conflicts and other lesser headaches. However, even when they do,
sometimes things fall through the cracks. Anyway, we try to keep a record
of everybody who's working on everything in the file KER:AAWAIT.HLP, and
everyone who's interested in forthcoming versions is welcome to take a look
at it.]
------------------------------
Date: 19 Sep 86 09:26:06 EDT (Fri)
From: Michael Fischer <fischer@YALE.ARPA>
Subject: Re: Problems Installing Atari ST Kermit
Keywords: Atari ST Kermit
I had problems installing GEM Kermit, too, but I finally got it to work.
Here in a nutshell are what the problems were:
1. The UUDECODE program distributed with Kermit (astuud.c) is written
for the Lattice C compiler. To use it with the Alcyon C compiler distributed
with the Atari Developer's Kit, it is necessary to open the binary output
file with "fopenb" instead of "fopen"; otherwise, the file is opened in
text mode (ignoring the "b" mode flag") and every ^J in the output has a
gratis ^M inserted after it.
2. Recompiling the sources as Chris Rose did is not sufficient, for
the resource files are *only* distributed in binary form. A correct
program given a bad resource will crash, just as an incorrect program
will. Thus, one has no choice but to get UUDECODE to work.
3. Once I fixed UUDECODE, I successfully decoded both the Kermit
program and resource files and they worked without problem. I also
rebuilt the program from the sources and it also worked with the
decoded resource file.
4. There has been a great deal of activity lately on the INFO-ATARI16
bboard discussing the various problems people have been having with
UU-encoded files. There seem to have been two or three independent sets
of problems:
(a) Bugs in the UUDECODE program to run on the ST as described above.
(b) Problems with the encoded file being modified during transmission
such as tab expansion, truncation of trailing blanks, or padding of
all lines to a given length.
(c) For people who tried decoding on a mainframe and then transmitting
the binary files to the ST (often using the old Developer's kit Kermit),
forgetting to set binary mode on both the transmitting and receiving
Kermit. After numerous reports of failures and then people bringing
these problems out in the open, success stories such as mine above
began pouring in. So UU-encoded files *are* usable, but it can be
rather tricky to do it right.
I will contact the "New Haven ST's" user group to see if they would
be willing to copy GEM Kermit onto disks for people.
Mike Fischer
<fischer@yale.arpa>
[Ed. - See next message for another hint.]
------------------------------
Date: Sat, 13 Sep 1986 12:40 MDT
From: WANCHO@SIMTEL20.ARPA
Subject: Uuencoded Files and Trailing Blanks
Keywords: Uuencoded Files
I made a small experimental change to our version of uuencode to solve
the truncated trailing blank problem and it turns out to be
transparent to uudecode. That change is simply to insert a "M" to
each uuencoded line just prior to the insertion of the CRLF. BITNET
users accessing our system through our mail file server have voiced no
complaints since I made that minor change.
--Frank
------------------------------
End of Info-Kermit Digest
*************************
-------