Xref: utzoo comp.sources.wanted:3614 comp.sys.ibm.pc:13178
Path: utzoo!dciem!nrcaer!cognos!crcmar!patrick
From: patrick@crcmar.crc.uucp (Andrew Patrick)
Newsgroups: comp.sources.wanted,comp.sys.ibm.pc
Subject: Re: DMGBBS unarcing problems
Message-ID: <637@crcmar.crc.uucp>
Date: 15 Mar 88 15:25:43 GMT
Article-I.D.: crcmar.637
Posted: Tue Mar 15 10:25:43 1988
References: <309@spock.UUCP> <5671@cit-vax.Caltech.Edu> <1450@polyslo.UUCP>
Organization: CRC, Ottawa CANADA
Lines: 35
Summary: Shouldn't it be ARCHIVED first, and then UUENCODED?

In article <1450@polyslo.UUCP>, mdella@polyslo.UUCP (Marcos R. Della) writes:

  [stuff deleted]
 
> When I put the thing together, I used the uuencode system that was currently
> on our pyramid. I really don't know what version or release that was.  If you
> manage to get past that point, I was using pkarc.com version 3.5 to arc the
> thing together. I know going into submission the program was dearcable, but
> I don't know what happened after that...

  [stuff deleted]
 
> So, in summary:
>    uuencoded w/whatever is on the pyramid
>    arc'ed w/pkarc.com version 3.5
>    it was also split using the pyramid split program...
> 
> Marcos Della

Is it not the usual procedure to PKARC the files first, and THEN submit
them for UUENCODING?  By the sounds of it, Marcos did it in the
opposite order, which causes problems for those of us who UUDECODE on a
main-frame, and then ship to the PC for PKXARCing.  If this is the
problem, perhaps a re-post is called for using the correct processing
order?



Andrew Patrick, Ph.D.
INTERNET:  patrick@crcmar.uucp
UUCP:  ... uunet!mnetor!utzoo!dciem!nrcaer!crcmar!patrick
BITNET: patrick%crcmar@UTORGPU 
PHONE:  (613) 990-4675
CANADA POST:  Division of Behavioral Research, Communications Research Center,
              P.O. Box 11490, Station 'H', Ottawa, ON, CANADA K2H 8S2