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...