info-kermit@ucbvax.ARPA (04/10/85)
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Info-Kermit Digest Tue, 9 Apr 1985 Volume 2 : Number 19
Departments:
ANNOUNCEMENTS -
ANSI Tape Program for Prime Computers
Commodore-64 Boostrap Program in SIMULA
IBM MAINFRAME KERMIT -
CMS Kermit and Linemode
EBCDIC, ASCII, and All That
ASCII in Kermit Docs
Re: EBCDIC, ASCII, and All That
MISCELLANY -
Text vs Binary Files in Kermit
Another CP-6 Kermit on the Way
B6900 Version of Kermit Using NDL2?
----------------------------------------------------------------------
Date: 9 Apr 1985 1829-EST
From: LSM.DUNCAN at DEC-MARLBORO
Subject: ANSI Tape Program for Prime Computers
Attached is a program written in Fortran-66 which will read variable
record length ANSI (Format D) tapes on a Prime computer. Since Fortran-66
is provided with all Prime machines, all Prime customers should be able to
compile and run it.
I have only briefly tested it, but it appears to work as advertised.
Much thanks should go to the Prime New York office. Ron Couch, a senior
analyst there wrote it, and Dave Tichane provided me with a copy to send
to you.
In order to help you out, I am willing to send a (paper) listing of it
to anyone who needs it. Please send a request to LSM.DUNCAN at
DEC-MARLBORO, Prime X.MAIL DUNCAN -ON EN.C6, or U.S. mail to:
Jeff Duncan
Prime Computer Inc.
492 Old Connecticut Path MS 21-02
Framingham, Ma. 01701
I hope this new program will help out the many Prime people who have had
difficulty with your tapes.
Jeff
[Ed. - Many, many thanks to Jeff, Ron, and Dave. Prime computer sites
have had a terrible time reading the ANSI tapes we sent them up till now.
The program is in KER:PRIMET.FTN, available via anonymous FTP from CU20B.]
------------------------------
Date: 08 Apr 85 14:19 +0100
From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject: Subject: Commdore-64 Boostrap program in SIMULA
Here is a version of the C64BOOT program written in SIMULA for DEC-10/20
computers. I have commented this version a little more than previous
versions of C64BOOT in other languages, to make it simpler for someone who
needs to re-write it into yet another language.
Note two important points: ALL echoing of characters from the CBM by the
HOST must be suppressed. Also the echoing of a line feed when the CBM
sends a carriage return.
The delimiter between lines sent to the CBM-64 should be only carriage
return, not carriage return-line feed.
[Ed. - Thanks, Jacob! The program is in KER:C64BOOT.SIM, available
via anonymous FTP.]
------------------------------
Date: Fri, 5 Apr 85 10:11:03 est
From: KRAMER <billk%udel-cc-vax2.delaware@UDEL-LOUIE.ARPA>
Subject: CMS Kermit and Linemode
Has anyone tried to get the VM/CMS Kermit working using the LINEMODE
patches from Queens Univ with a YALE ASCII/Series 1 front end (or an
IBM4994)? Better yet, does anyone have KERMIT working useing the
Transparent mode options with the YALE Ascii package?
[Ed. - The soon-to-be-released version 2.00 of VM/CMS Kermit will include
the ability to operate transparently through the Series/1 front end with
the Yale ASCII package. The U of Chicago's MVS/TSO Kermit was modified at
the U of Toronto to do the same thing, but the Toronto version ONLY works
through the Series/1-Yale front end; it's in KER:TSOS1.*.]
------------------------------
Date: Thursday, April 4, 1985 at 9:36 PM EST
From: Norman Ramsey <ZSYJARTJ%CORNELLA.BITNET@WISCVM.ARPA>
Subject: EBCDIC, ASCII, and all that
I am at my wits' end trying to cope with CMS, CMS-KERMIT, and the godawful
problem of ASCII/EBCDIC translation. I am working with two sites, CORNELLA
and MITVMA, that use DIFFERENT translation tables. I believe that BOTH
tables are noninvertable, and I am ready to flog the engineer who designed
EBCDIC.
All this notwithstanding, I would be happy (nay, ecstatic), if I could
somehow just send the RAW BITS from an ASCII machine (such as my IBM PC)
and an IBM mainframe. I would be happy with seven bits. I would be happy
with eight bits. I'm beginning to think the best I can hope for is six
bits, and that only be encoding everything as alphanumeric, comma, period,
blank, and such characters as we hope will always be translated *RELIABLY*
independently of the vagaries of the various sites.
Such as, f'rinstance: my site (CORNELLA) translates an ASCII backslash
into an EBCDIC cent sign (hex 4A) and back again. Too bad no other site
seems to do that. But you don't want to hear this...
Norman Ramsey
zsyjartj@cornella.bitnet
------------------------------
Date: 04/09/85 17:39:11 EDT
From: TS0013@OHSTVMA
Subject: ASCII in Kermit docs
I am curious about which version of ASCII is really the one on which
Kermit is based. The KERMIT PROTOCOL MANUAL says that The 1968 version of
ASCII, X3.4, is used. Appendix V of the same manual shows X3.4-1977. The
major point I am aware of in the 1977 version is that the broken or
"split" vertical bar has been "fixed" back to a solid vertical bar. The
name for it is now just "vertical bar".
Locally on our IBM systems, we have a homegrown standard for the
translation of ASCII to EBCDIC and EBCDIC to ASCII. This local standard
is based on the fact that early development and standard- ization of PL/1
insisted on using the exclamation point, stylized like a vertical bar, for
logical OR. A compromise was reached at some point making the code for
exclamation to be either a solid vertical bar or an exclamation. I still
see documents around that describe this mess. I think this was
implemented in 1968. In 1977 ANSI decided to fix the mess and make the
broken vertical bar into a solid one, and the exclamation was to be only
that. What resulted here was that the translations still change the CODE
for character number (octal)21 into a vertical bar in EBCDIC.
This has led to much confusion around here. The management here was only
recently aware that there were even any such changes in ANSI. I guess
they will learn that "standards never are".
What I am curious of is just what standard is Kermit based on. Is it
using some specific standard, or perhaps trying to track a moving target
(ASCII) ?
------------------------------
Date: Fri 5 Apr 85 10:49:27-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Re: EBCDIC, ASCII, and all that
My sympathies to all. ASCII/EBCDIC translation will always plague us.
Those who are interested in the sordid history -- and there's a lot of it
-- are referred to the book "Coded Character Sets, History and
Development" by C.E. Mackenzie, Addison-Wesley (1980). There are two
"standards" for translation between ASCII and EBCDIC:
[CACM] "Correspondences of 8-Bit and Hollerith Codes for Computer
Environments -- A USASI Tutorial", a working paper of the ANSI X3
Committee, published in CACM, vol.11, no.11, pp.783-789 (Nov. 1968)
[IBM] "System/370 Reference Summary", GX20-1850-5, IBM Corporation,
6th ed. (1984) (earlier editions presumably have the same table)
The former more closely approximates a formal standard since it comes from
the appropriate ANSI committee, but the latter is used more commonly in
practice, since it is promulgated by the major manufacturer of equipment
for which ASCII/EBCDIC translation is necessary. To complicate matters,
both ASCII and EBCDIC went through many fundamental changes over the
years; EBCDIC went through a long evolution from Hollerith and BCD to its
present state, and there have been at least four distinct ASCII alphabets:
those of 1963 (no lower case letters), 1965 (lower case letters added,
some new graphics added, others switched around), 1967 (ANSI X3.4-1968:
several graphics moved and/or redefined), and the current 1977 version
(X3.4-1977: vertical bar plugged). Many translation tables are relics
from these early days of rapid change; they were correct (i.e. useful) in
the context in which they were created but now cause problems, most
commonly with the following characters:
ASCII CACM IBM
ASCII value EBCDIC EBCDIC
graphic decimal Hex Hex Comments
! 33 4F 5A 4F in IBM is a solid vertical bar
[ 91 4A AD 4A in IBM is a cent sign
] 93 5A BD 5A in IBM is an exlamation mark
^ 94 5F 5F Listed in IBM as a "not sign"
| 124 6A 4F IBM has 3 vertical bars -- 4F, 6A, and FA
The Kermit translate table corresponds to the IBM table (with either 1968
or 1977 ASCII) and works at most sites. Unfortunately, this is not to say
that sites at which it does not work are using the CACM table; many sites
have reported problems with the translation of characters where IBM and
CACM agree, including curly braces "{}", backslash "\", and tilde "~". It
seems to be a relatively common practice for sites to "customize" their
translate tables, for reasons such as those mentioned above.
The IBM (and hence the Kermit) table is invertible, provided one sticks to
using only the EBCDIC 4F vertical bar, which is solid in EBCDIC and 1977
ASCII, and broken in 1968 ASCII (and on most current ASCII terminals and
printers).
The only way to get IBM systems (VM/CMS systems, anyway) to allow raw data
in and out a TTY line is to modify VM by adding the null translation table
along with an appropriate CP command to invoke it. It does not
necessarily do any good to preprocess your data (e.g. hexify it), because
Kermit packets contain not only data, but also control fields which may
contain any printable ASCII character.
------------------------------
DATE: TUESDAY, 9 APRIL 1985
FROM: BRIAN AT UOFT02
SUBJECT: Text vs Binary Files in Kermit
A proposal to assist in Kermit binary file transfers.
A common problem in Kermit file transfers is that of having to switch
between 'bin' (or 'fixed') modes and 'text' modes. While some Kermits,
such as the MS/PC DOS and Kermit-11/RT11 versions don't care what about
this (RT makes no distinction), Kermit-11, Kermit-20 and Kermit-32 do.
This problem becomes acute when one sets up a BB for downloading text
and exe (tsk,sav,...) files to micros. We need a means to automate the
switching from text mode to image mode. Kermit-11 currently uses two
methods to do this, one, if the file is not sequential implied CR then
Kermit-11 sets itself to 'binary' mode, ie, it uses RMS-11 direct
access macros to read the file. Also, it will check the filetype to see
if a match occurs, and if so, sets itself to binary mode for that file.
This is done since RSTS/E and RT can have files that ARE binary but
have no ufd data to say so.
Additionally, if Kermit-11 finds that a file is 'binary' it will tell
the other Kermit (if it said it can handle attributes via the CAPAS
field) such. Also, if Kermit-11 finds itself talking to another
Kermit-11 it will (for RSTS/E and RSX and P/OS) send a copy of the file
header (the RMS-11 IFAB).
Now, for the problem.
We need a consistant means of setting 'binary' xfer mode. Kermit-11 has
in it a hardwired list of filetypes that shoud be sent 'binary'. This
is ok most of the time, exceptions do occur. Like a .COM file is a
command procedure under VMS and RSTS V9 (which I am field testing) but
under CPM it is quite another thing.
The proposal is this:
The Kermit program should look for a file that contains a list of
filetypes that the system manager considers to be 'binary'. If found,
switch to image mode. Also, we should think about attribute packets, at
least in so far as 'I' format file.
brian nelson
brian@uoft02.bitnet
[Ed. - Brian's note points out a fundamental problem with Kermit, and in
fact with any file transfer mechanism, especially between unlike systems.
Brian's scheme would help a lot, but it would have to be combined with
all sorts of other heuristics, different on each system, to behave as
desired. For instance, to tell the difference between a VMS .COM file
(a textual command file) and a CP/M .COM file (an 8-bit binary file), one
would have to examine the data itself.]
------------------------------
Subject: Another CP-6 Kermit on the Way
Date: 04 Apr 85 20:19:50 PST (Thu)
From: Mike Iglesias <iglesias@uci-icsa>
Lee Hallin at Honeywell LADC (in Los Angeles) has also got a KERMIT for
Honeywell CP-6 systems. His has SERVER mode, some fancy debugging
features, etc. It's not completely done yet. He's planning on submitting
it to the KERMIT distribution when it's done. We've been testing it for
him for about 3 weeks. Just thought you'd like to know.
Mike Iglesias
University of California, Irvine
[Ed. - When it rains, it pours...]
------------------------------
Date: 5 Apr 1985 12:32-PST
Subject: B6900 Version of Kermit Using NDL2?
From: Geoffrey C. Mulligan <GEOFFM@SRI-CSL>
We have a B6900 running NDL2 and I am interested in getting Kermit
running. Has anyone written a version of Kermit using NDL2?
------------------------------
End of Info-Kermit Digest
*************************
-------