Bob_BobR_Retelle@cup.portal.com (09/09/89)
John Stiborek in North Texas asks about errors in UUENCODED files he's received... It shouldn't matter what kind of computer does the transferring (VAX, IBM or whatever) since the whole point of UUENCODING is to convert a binary file int a standard ASCII text file that can be transferred by ANY machine, over ANY network... However, since there is NO error checking provided during an ASCII transfer, it's possible (or even likely in this case) that line noise has corrupted the lines that give the errors... each line DOES have a checksum attached to it, so that even though you won't be told about it at the time of the transfer, you'll be notified of any errors when you try to unencode the file. The only real solution is to keep trying the transfer until you get a good one... if you can find a different path to access the other computer, that might help... or as a last resort, send him a disk through the U.S. Snail.. BobR
antony@lbl-csam.arpa (Antony A. Courtney) (09/10/89)
In article <22004@cup.portal.com> Bob_BobR_Retelle@cup.portal.com writes: >John Stiborek in North Texas asks about errors in UUENCODED files he's >received... > >It shouldn't matter what kind of computer does the transferring (VAX, IBM or >whatever) since the whole point of UUENCODING is to convert a binary file int >a standard ASCII text file that can be transferred by ANY machine, over ANY ^^^ ^^^ >network... > > [more stuff about how ASCII doesn't do error checking deleted]. Don't believe everything you read. There are any number of sights out there on bitnet which have to pass through very old IBM hardware. This old IBM mainframe hardware does NOT use ASCII, but rather an older standard called EBCDIC. There are, however, plenty of EBCDIC<-->ASCII converter programs. Unfortunately they do not always agree on which characters are which. I have seen this happen enough times to know thatt uuencoding does not work for absolutely EVERY sight on EVERY network. Uuencoding just works on enough sights that nobody complains. Especially since nobody wants to have to clean up after IBM. If you are still stuck or want more information about this, there was a solution found by a programmer (and friend of mine) for the Tandy color computer which transferred files across just about any network you can think of(they use a fileserver on an EBCDIC computer). If you like, I can send you more information on who to talk to about getting a protocol which will work for you. Cheers, Antony ******************************************************************************* Antony A. Courtney antony@lbl.gov Advanced Development Group ucbvax!lbl-csam.arpa!antony Lawrence Berkeley Laboratory AACourtney@lbl.gov
exspes@gdr.bath.ac.uk (P E Smee) (09/17/89)
In article <22004@cup.portal.com> Bob_BobR_Retelle@cup.portal.com writes: >It shouldn't matter what kind of computer does the transferring (VAX, IBM or >whatever) since the whole point of UUENCODING is to convert a binary file int >a standard ASCII text file that can be transferred by ANY machine, over ANY >network... Ahh, but the problem is with transfers which pass thru an IBM machine, since IBM machines DO NOT SPEAK ASCII. They speak EBCDIC. There is not a unique one-to-one and reversible mapping between ASCII and EBCDIC. (And, to further confuse things, there are a number of variants of EBCDIC, frequently all used in different contexts on the same machine.) The most frequent problem with transfers which have been passed through IBM's is for characters which began life as ASCII circumflex (up-arrow, little hat, whatever you call it -- ASCII 0x94) to come back out of the IBM as tildes (squiggles -- ASCII 0x126). This is because neither of these graphics exists in EBCDIC. EBCDIC has a (different) single graphic representing the (IBM) 'NOT' character -- and both hat and squiggle tend to get mapped to that on input from an ASCII machine. The simplest uudecode algorithm (which assumes that the file contains only chars in the uudecode character set) will give an incorrect 6-bit value when it decodes the resulting squiggle, as compared with what was in the original file. (There is an alternative algorithm which will do the right thing, as will Dumas 'table' method.) It is generally (but not invariable) true that if you push an ASCII text file from an ASCII machine through an IBM EBCDIC machine and then back to an ASCII machine, you will not end up with an identical file. The two character coding schemes do not match. -- Paul Smee | JANET: Smee@uk.ac.bristol Computer Centre | BITNET: Smee%uk.ac.bristol@ukacrl.bitnet University of Bristol | Internet: Smee%uk.ac.bristol@nsfnet-relay.ac.uk (Phone: +44 272 303132) | UUCP: ...!mcvax!ukc!gdr.bath.ac.uk!exspes
ljdickey@water.waterloo.edu (Lee Dickey) (09/20/89)
In article <1989Sep17.143908.2056@gdt.bath.ac.uk> exspes@gdr.bath.ac.uk (P E Smee) writes: > >It is generally (but not invariable) true that if you push an ASCII text >file from an ASCII machine through an IBM EBCDIC machine and then back >to an ASCII machine, you will not end up with an identical file. The >two character coding schemes do not match. What Paul mentions here is particularly painful for academics in the UK who wish to correspond with others outside and who could benefit from their gateway to EARN (and BITNET). *The* gateway between BITNET and all other academic sites in the UK is ACUKRL, at Rutherford Labs. They are notorious for this problem, they know about it, and seem to take the attitude that the world should conform to their way of doing things. Rutherford would turn in his grave. On the other hand, many IBM sites that interact with ASCII machines are now using translate tables that correctly map the 95 graphic ASCII (ISO 646) characters. -- L. J. Dickey, Faculty of Mathematics, University of Waterloo. ljdickey@water.UWaterloo.ca ljdickey@water.BITNET ljdickey@water.UUCP ..!uunet!watmath!water!ljdickey ljdickey@water.waterloo.edu
antony@lbl-csam.arpa (Antony A. Courtney) (09/20/89)
In article <2657@water.waterloo.edu> ljdickey@water.waterloo.edu (Lee Dickey) writes: >In article <1989Sep17.143908.2056@gdt.bath.ac.uk> exspes@gdr.bath.ac.uk (P E Smee) writes: >> >>It is generally (but not invariable) true that if you push an ASCII text >>file from an ASCII machine through an IBM EBCDIC machine and then back >>to an ASCII machine, you will not end up with an identical file. The >>two character coding schemes do not match. > >What Paul mentions here is particularly painful for academics in the >UK who wish to correspond with others outside and who could benefit >from their gateway to EARN (and BITNET). *The* gateway between BITNET >and all other academic sites in the UK is ACUKRL, at Rutherford Labs. >They are notorious for this problem, they know about it, and seem >to take the attitude that the world should conform to their way >of doing things. Rutherford would turn in his grave. > > >-- > L. J. Dickey, Faculty of Mathematics, University of Waterloo. > ljdickey@water.UWaterloo.ca ljdickey@water.BITNET > ljdickey@water.UUCP ..!uunet!watmath!water!ljdickey > ljdickey@water.waterloo.edu There is a similar problem here in the US, as there are still plenty of gateways using EBCDIC. I suggest you contact Tim Koonce, a Ph.D. student in mathematics at U.C. Berkeley, who has developed a protocol for binary file transfer which is not inhibited by ASCII->EBCDIC->ASCII conversion. His email address is: koonce@brahms.berkeley.edu koonce@ucbbrahms.bitnet ...ucbvax!brahms!koonce (Anyone who cant get their mailer to find ucbvax is in poor shape. :) ) Good Luck! -Antony A. Courtney -- ******************************************************************************* Antony A. Courtney antony@lbl.gov Advanced Development Group ucbvax!lbl-csam.arpa!antony Lawrence Berkeley Laboratory AACourtney@lbl.gov