X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f996b,637bed96a2434e5a X-Google-Attributes: gidf996b,public X-Google-ArrivalTime: 1994-06-14 03:50:50 PST Newsgroups: alt.ascii-art Path: nntp.gmd.de!xlink.net!howland.reston.ans.net!usc!sdd.hp.com!think.com!spdcc!merk!winston From: winston@merk.com (Winston Smith) Subject: TALK: xxdecode Message-ID: Keywords: XXENCODE, ASCII, EBCDIC, UNIX, VM/CMS, MAINFRAMES Organization: Technology Partners, Inc. References: <9406070356.AA19108@davinci.icad.puc-rio.br> Date: Tue, 14 Jun 1994 09:54:02 GMT Lines: 50 On Wednesday, June 8, 1994 at 07:09:53 GMT (1:09am EDT ?) paul@heino.ibh.rwth-aachen.de (Paul Foerster) writes: PF> ... I never heard of xxencode. So let's generate some questions from PF> scratch: PF> PF> 1. Why wasn't it posted uuencoded? So, people have to go and look PF> for XXENCODE. Everyone already has UUENCODE. PF> 2. What the hell is XXENCODE? Sounds a little like a coder for PF> X-windows. But i'm wrong with this, or not? PF> 3. Where can I get XXENCODE? Or will ya' post (or make otherwise PF> accessible) a uuencoded version? I FTP-ed XXEDCODE, unpacked it, and <* TA-DA! *>... was off to the races before your could say, "Jack Robinson". It is functionally identical to UUENCODE in every respect and offers no obstacles to learning. I was using it in a matter of minutes, at the longest. I can think of a very good reason for XXENCODE, namely that the first, and fastest hardware on the computer networks are typically IBM mainframes which run the EBCDIC character set (a.k.a. translation tables for Hollerith punchcard strings). As a result, files in the big networks are constantly "pouring through" EBCDIC IBM mainframes at the large academic and industrial sites. Binary transfers are no problem; binary is binary! But what about UUDECODE ? UUDECODE is an --ASCII-- file that *-WANTS-* to be treated as a --BINARY-- file, but an EBCDIC mainframe --DOES NOT KNOW THIS-- ! It thinks that an ASCII file is written text. There are text filters on EBCDIC machines that say, "Hmm... I'd better not send this EBCDIC 'cent sign' to the ASCII machine I am handing off to, since the ASCII character set has no 'cent sign' character. Let us suppress it. Let us translate it to a 'pipe'. Let us translate it to an 'underscore'. It will be more readable...." The EBCDIC mainframe assumes that the ASCII UUENCODE file that it is getting is --TEXT-- meant to be read, not a program to be compiled. Programs are --ALWAYS-- sent as binary, according to them. Think of XXENCODE as a "subset" of UUENCODE that is safe for EBCDIC machines in their native environment that aren't normally running UNIX/ASCII, but are running something else, such as VM-CMS/EBCDIC. It is a more "universal" form of ASCII that translates to EBCDIC. (While this violates the spirit of "the ASCII universe", it maintains the goal of the group to be "usable on all computer hardware". The problem is that the EBCDIC machines should convert UUENCODED ASCII files into "binary" as they pass through their machines, rather than performing fancy text translation. The EBCDIC mailers are either not smart enough... or too smart for their own good! (...depending on your point of view).