Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!ames!elroy!usc!orion.cf.uci.edu!uci-ics!asickels
From: asickels@ics.uci.edu (Alan Sickels)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: Problem with zoo201
Summary: Might be kermit transfers
Keywords: zoo execution error
Message-ID: <16375@paris.ics.uci.edu>
Date: 1 Jun 89 19:51:23 GMT
References: <977@ncs-med.UUCP>
Sender: news@paris.ics.uci.edu
Reply-To: Alan Sickels <asickels%bonnie.uci.edu@orion.cf.uci.edu>
Distribution: na
Organization: University of California, Irvine - Dept of ICS
Lines: 32

In article <977@ncs-med.UUCP> swg@ncs-med.UUCP (Stephen W. Glennon) writes:
>I am having trouble with zoo201.  Where did I go wrong?
>
>I saved the three parts of the zoo201 executable and ran them through 
>the combine script.  The resulting zoo201.exe file was the correct size 
>and the checksum was correct.
>
>I then used to kermit (with file type set to binary) to move the 
>file to a VAX 8350 and then kermit again (with file type set to binary
>again) to move the file to a PS/2 Model 30 with 640k of memory running 
>pc-dos 3.3.  The file started out as 87447 bytes on unix and ended up 
>as 89636 bytes on the ps/2.  (A difference I take to be due to the 
>granularity of file storage on the ps/2 though it seems suspiciously
>large.)

[Stuff about memory size deleted]

Something you absoutely MUST do when using kermit is not only make
sure both machines are use 8n1 or 7e1, but to let BOTH kermit
protocols know how many data bits and what parity they are running at.
Before I knew about this, I had similar problems.  Of course I could
be way off base, but you might want to try it.

BTW, kermit preserves the exact file length so your final copy (on
your PS/2) should be the same size as the one on the original unix
system.  It may take up more physical space (up to 2K) on your hard
drive, but a DIR of the file should show it to be the original size.

>	-Steve Glennon-		...!rutgers!umn-cs!ncs-med!swg

Alan Sickels
asickels%bonnie.ics.uci.edu@orion.cf.uci.edu