transfer filePro file from dos to unix

[Dennis Malen]

I have used Ken Brody's approach with the use of FTP. I used both the ascii 
and binary facility. I changed the ownership to filePro and moved it to the 
appropriate unix directory. Then I went into the program and it acknowledged 
a screen.9 and gave me the following error message:

*** A filePro Error Has Occurred ***

Error reading screen

On File: /appl/filepro/test/screen.9

Invalid screen format.?

Both machines were little endians.

Please note that the transfer of the prc file worked fine when I saved it in 
ascii and brought it over to the unix box.

Any thoughts?

Dennis Malen
516.479.5912
----- Original Message ----- 
From: "Brian K. White" <brian at aljex.com>
To: <filepro-list at lists.celestial.com>
Sent: Thursday, October 23, 2008 4:38 PM
Subject: Re: transfer filePro file from dos to unix


>
> ----- 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!
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list