swg@ncs-med.UUCP (Stephen W. Glennon) (06/01/89)
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.) When I tried to start the self-extraction process I got the message: Program too big to fit in memory According to chkdsk --> 654336 bytes total memory 525152 bytes free The dos manual informs me that this error message occurs when "the file containing the command cannot be loaded because it is larger than the available free memory". The suggested corrective action is to use fewer buffers. So I deleted everything except the country line from the config.sys file and rebooted. Now chkdsk shows --> 596480 bytes free I tried the self-extraction process again and got the same error. The manual says "If the message reappears, your system does not have enough memory to execute the command." So much for reading the manual. Does this *really* mean that zoo201 needs more than 596480 bytes to extract itself? Did the executable get hopelessly mangled by kermit, or is something else wrong? Can anyone provide me with enlightenment? Thanks most hopefully! -Steve Glennon- ...!rutgers!umn-cs!ncs-med!swg
snuffy@unix.cis.pittsburgh.edu (Michael C Bednar) (06/02/89)
When I attempted to download zoo201 I didn't even get the error messages. The program simply locked up and I had to reboot my machine(I run an XT clone w/640k and dos 3.3). My solution was to download a copy of uudecode (there are three versions avail- able in the C.B.I.P. starters kit) and transmit the uuencoded version of zoo201 uudecoding it using my pc. It now works perfectly. The only reason I can think of for the glitch is that kermit adds garbage to the transmitted file(thus the increased file size) and that the uudecoding program cleans it up. You should be warned however that the decoding process takes considerably longer on the pc. I think zoo took about 1/2 hr. (and I have a 10mhz turbo installed!). I hope this helps. Snuffy p.s. Since this my first posting, if I did anything wrong I apologize in advance
asickels@ics.uci.edu (Alan Sickels) (06/02/89)
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
astieber@csd4.milw.wisc.edu (Anthony J Stieber) (06/03/89)
In article <977@ncs-med.UUCP> swg@ncs-med.UUCP (Stephen W. Glennon) writes: [...] >According to chkdsk --> 654336 bytes total memory Hey, what's this ^^^^^^ Shouldn't any 640K machine report 655360 bytes total RAM? There is a full 1024 bytes missing. Is IBM cheating the user again? :-) ps Make sure all the machines you're using know that the transfer should be binary, the file size should be tha same on all the machines. You could try moving just the uucode via text transfer then uudecode on the PC. -- Tony Stieber astieber@csd4.milw.wisc.ed att!uwmcsd1!uwmcsd4!astieber