Xref: utzoo comp.sources.d:2428 comp.sys.ibm.pc:17021 Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!ucsd!ucbvax!agate!ig!uwmcsd1!nic!gonzo!nett From: nett@gonzo.ETA.COM (Jerry Nettleton) Newsgroups: comp.sources.d,comp.sys.ibm.pc Subject: Enhancement to UUENCODE/UUDECODE Keywords: utilities uudecode uuencode Message-ID: <410@nic.MR.NET> Date: 9 Jul 88 16:15:35 GMT Sender: news@nic.MR.NET Reply-To: nett@gonzo.eta.com (Jerry Nettleton) Organization: ETA Systems, Inc., St Paul, MN Lines: 22 Sometimes when I receive UUENCODEd files, I will combine the various parts and use the uudecode program to produce the output file (e.g. *.ARC files). I then download it to my PC only to find out that I have an invalid .ARC file. I have properly transferred a binary file using Kermit many times so that's not the problem. My suggestion for the uuencode program is to add 'block counts' and 'checksum/CRC' imbedded in the encoded file to ensure the output file gets created successfully. Before Kermit was generally available, I wrote an encode/decode program that happen to use the same techniques as Kermit to encode a 8-bit binary file into a readable 7-bit ASCII file. Since I wanted to upload/download the encoded ASCII file to/from a Sperry 1100 mainframe which only has 7-bit odd parity access, I encoded some error correction into the ASCII file to make sure I could warn the end user that the file was transferred properly. Any comments are welcome. Jerry Nettleton email: nett@gonzo.eta.com Software Engineer at&t: 612-642-8797 ETA Systems, Inc. usps: 1450 Energy Park Drive St. Paul, MN 55108