transfer filePro file from dos to unix

[Brian K. White]

----- Original Message ----- 
From: "Dennis Malen" <dmalen at malen.com>
To: <john at valar.com>
Cc: <filepro-list at lists.celestial.com>
Sent: Thursday, October 23, 2008 11:14 AM
Subject: Re: transfer filePro file from dos to unix


> John,
> 
> When I FTP I use TinyTerm to FTP in binary or ascii.
> 
> Perhaps I am making a mistake by using the following procedure:
> 
> The filePro file is created on my laptop. I then copy that file to a cd or a 
> usb port (I used the usb port). I then upload the filePro file on my windows 
> computer in my office. I then FTP the filePro file over to the UNIX box (I 
> have tried both binary and ascii). I then go through the procedures that Ken 
> outlined for the screen and report.
> 
> Do you see anything wrong that could corrupt the transfer?

The different parts of filepro files need different handling.

prc files need to have the correct line-endings for the platform they are on.
This means on unix, only LF's
On windows CRLF's
There are several ways to get that result, but focus on the result, not the method.
Saying "use acii mode ftp" is one method, and may or may not actually produce
the result, depending on other factors. So it's more robust to just be aware of the necessary end result, so that when you try to load a file on whichever platform, if it looks like junk, you just fix it by whatever means is handy. If you're on unix and the file cas CR's in it (^M's), look for utilities like, dos2unix, dostounix, dtou, dtox, or google up a sed or awk example. If you're on windows and the file lacks CR's, then I don't know what's the simplest fix. I'd proably generate a windows friendly file right on unix and ftp that in binary mode, since win & unix use different filenames for the same prc file. ("unix2dos <prc.foo >foo.prc" then copy foo.prc via ftp)

Other files like screens and output formats I _think_ need to transferred in binary mode.
They don't have line endings, they are fixed format files. I _think_. Me, I'd simply try it each way on a sample menu, screen, etc and see. It takes way way less time to just test it both ways and see than it does to post a question here and read 3 wrong and 2 right answers and try to guess who to trust and why you can'tmake it work until Ken finally utters the gospel on that particular matter, probably for the 12th time this year and every previous year (he has nothing better to do of course).

key, data, index*, (and now blob), unquestionably always transfer in binary mode ONLY.

Add to all the above, if the endianness of the two platforms differs then you also need swapcpu, but I think in this case you do not.

I'm not sure which if any components absolutely require xfer in order to generate correct checksums along the way.
Perhaps any component that has checksums in it. menu? screen? out? map?
Again simple trial & error is the fastest and most reliable way to find out in my opinion.
It only takes 2 tries per file type to ascertain either 1) needs ascii crlf/lf translation, 2) needs binary mode, ie, preserve the data exactly & perfectly, or 3) neither 1 nor 2 worked, and so it needs xfer.

-- 
Brian K. White    brian at aljex.com    http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!