Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!ukc!dcl-cs!bath63!pes
From: pes@bath63.ux63.bath.ac.uk (Paul Smee)
Newsgroups: comp.sys.atari.st
Subject: Re: uuencodeded uudecode program is here.
Message-ID: <678@bath63.ux63.bath.ac.uk>
Date: Fri, 19-Dec-86 05:43:53 EST
Article-I.D.: bath63.678
Posted: Fri Dec 19 05:43:53 1986
Date-Received: Sat, 20-Dec-86 22:19:23 EST
References: <861208050928.462912@RADC-MULTICS.ARPA> <649@bath63.ux63.bath.ac.uk> <2124@dalcs.UUCP>
Reply-To: pes@ux63.bath.ac.uk (Paul Smee)
Organization: AUCC c/o University of Bath
Lines: 22
Keywords: UUDECODE on host works


Well, far as I can see there's no reason that uudecoding on a host, and
transferring to the ST, *shouldn't* work.  However, in practical terms,
it appears to be more likely not to work than transferring to the ST and
then uudecoding -- based on personally observed cases.

Certainly, if you've got a combination that works -- with uudecode on a host
and then port -- then use it, it will be quicker.  However, I'd suggest that
people who have trouble should try the other method of working -- port first,
then uudecode -- as in my experience that's likely to make the problems go
away.

I'm actually a bit suspicious of at least one release of VAX/VMS.  However,
other than telling y'all what I've seen, I'm not going to investigate it.
I don't have the incentive to (because I've got no problems working the way
I do); or the means (don't have a handy VMS, don't have a handy ST<->U**x
connection, so I have to run everything thru my Multics -- Multics uses
36 bit words (9-bit bytes) so that playing with 8-bit binaries on it can
be 'tricky', and in any case doesn't have uudecode).

So, in summary, if what you do works, stick with it, but if you're having
problems consider a change...