Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ucbvax!XEROX.COM!Fleysher.wbst
From: Fleysher.wbst@XEROX.COM.UUCP
Newsgroups: comp.sys.atari.8bit
Subject: Re: Another try at uudecode for the 800...
Message-ID: <870128-070822-6550@Xerox>
Date: Wed, 28-Jan-87 10:07:41 EST
Article-I.D.: Xerox.870128-070822-6550
Posted: Wed Jan 28 10:07:41 1987
Date-Received: Thu, 29-Jan-87 05:41:29 EST
References: <8701280654.AA08218@mitre-bedford.ARPA>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 24

Thanks for the explanation of how UUDECODE works.  I'll give the new
version you distributed a try as soon as I can.

I think you should ALWAYS assume you have to update the length parameter
of OBUF$ - i.e., the ML DATA statements in you BASIC program aren't
being executed unless the user is really in BASIC.  Different versions
of your routine for non-basic users is an option.  However I also think
it's a mistake to be depending upon BASIC's data structures at all.  The
ML in your DATA statements would be more bullet proof if you allowed
BASIC to set the length of OBUF$ based upon the return value M from the
ML routine.  

re: the line feed problem:  When uploading to your UNIX environment you
must specify straight ATASCII to make sure no translation occurs to
screw up the (binary) data.  Also note that the line feeds do not look
like line feeds in their UUENCODED state, so selection of ATASCII vs.
ASCII on download from UNIX to the recipient's Atari should not make any
difference in the UUENCODED data - only the terminator character at the
end of each line of 60 bytes.  Is your ML routine sensitive to this
terminator character?

	Dan

-----------------------------------