Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ucbvax.ARPA Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!info-kermit From: info-kermit@ucbvax.ARPA Newsgroups: fa.info-kermit Subject: Info-Kermit Digest, V2 #19 Message-ID: <6122@ucbvax.ARPA> Date: Tue, 9-Apr-85 20:30:03 EST Article-I.D.: ucbvax.6122 Posted: Tue Apr 9 20:30:03 1985 Date-Received: Wed, 10-Apr-85 06:08:33 EST Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 302 From: Frank da Cruz 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 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 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 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 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 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 ************************* -------