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