getting data to an updated machine

Fri Feb 3 08:48:02 PST 2006

Top post:

Not for nothing.. how about a null serial connection and fpTransfer. Several
years ago I used it to transfer from a Tandy 6000 to a Pentium 60 machine!!

It took a while (2 days) but it worked beautifully. Fptech even had the 8"
floppy version for the Tandy.

-- 
Rick Walsh

-----Original Message-----
From: Brian K. White <brian at aljex.com>
To: filepro-list at lists.celestial.com
Sent: Fri, 3 Feb 2006 05:08:54 -0500
Subject: Re: getting data to an updated machine

  ----- Original Message ----- From: "Creative Photography and Video"
<cpvphoto at cpvphoto.com> 
 To: "Brian K. White" <brian at aljex.com> 
 Sent: Thursday, February 02, 2006 8:27 PM 
 Subject: Re: getting data to an updated machine 

 > Thank you again. 
 > 
 > Question... 
 > 
 > I can rebuild index's and redo reports etc... what about using a >
compress.....and then finding software that will let me go floppy to >
floppy without worrying about a break and installing the compressed data >
key etc to the new system and new filepro for Linux that I can get from. >
Then I would need the line command to put the compressed data to a temp 1 >
directory and the name of what is needed to go from one floppy to the next >
that will work on my 486. machine.http://www.fptechnologies.com/ 
 > 
 > Steve 

 It's possible. There are a lot of issues to be aware of that together make
it difficult, which is why I didn't suggest it, but fine here goes.... 

 The native tar already on the machine will break a job up across floppies. 
 (possibly the cpio too but I never tried, I only just now noticed that sco
osr5's cpio does it, that means a 50% chance xenix's does it too) 
 Linux's tar does not know how to reassemble them though. However, I wrote a
script that you can run on linux or freebsd that will reassemble a
multi-volume tar written by xenix or sco unix. 
 Without that it would be a bit of a chore but still doable. 

 That leaves compression. For the tar or cpio (I'm just going to say tar
from here on since I don't know that xenix cpio even does it) to be able to
do the job of chopping up the data across multiple volumes, you need to
compress the data before giving it to tar, which is only doable if you have
room on your old fs to hold a huge temp file. 

 Actually, there is yet another option, Xenix and all later sco versions
native tar actually has a strange compression mode where it will compress
each file itself, individually, before adding to the tar. But then it takes
a sco version of tar to know how to uncompress them. The compression is just
normal "compress" which on linux the "ncompress" command knows how to
uncompress, but I never wrote a script that will examine each file coming
out of a tar and try to decide if it should be uncompressed or not. I'm
guessing sco's tar adds metadat to the tar format to take the guesswork out
of the receiving and so that tar knows whether a given file was compressed
by tar and needs to be uncompressed, or if it was already a compressed file
and shouldn't be modified. Actually I have written such a script, but it was
to deal with unpacking ctar archives not sco native tar. (on freebsd where I
couldn't get their freebsd version of ctar to run). ctar does not change the
names of the files in the archive when it compresses them, and I think
xenix's tar does add .Z to the names. And I've since lost it. shame, it even
handled remapping symlinks... In any event, this option is only practical if
the new system is a newer version of sco, not linux or anything else.
Actually, yet another "actually" you could play with copying the tar program
from the xenix box and getting it to run in linux via linux-abi but that's a
whole other can of worms and frankly I've already spent too much time on
this question and I'm declining to explore that topic in depth since I've
done it all before and in the end for various reasons it isn't good enough
to invest effort into so forget I mentioned it. :) 

 I just assumed you didn't have much room to play in n the old filesystem.
Xenix's filesystem only goes as high as 512 megs (it's possible to have
several 512 meg fs's, but no single one larger than 512) 
 Usually the hard drives were a lot smaller than that and almost full by the
time they get this old. 
 If you have room on a fs you can try this: 
 cd / 
 find ./ -print |cpio -oBv |compress -H >xenix.cpio.Z 
 tar cv6 xenix.cpio.Z 

 That generates a cpio stream of the whole system, without storing absolute
paths, runs it through compress and then to a file. 
 Then it uses tar to write the one big compressed file to floppies. 

 (compress -H would compress a lot more sometimes twice as much, but alas, I
don't think anything on linux knows how to uncompress it still)
...testing... Yes, on suse 10.0, "tar tvzf test.tar.Z" works fine, so does
"zcat test.tar.Z |tar tvf -". Now does "-H" go back as far as Xenix? I don't
remember. Try it. I modified the command above to use it. 

 You can't avoid writing the big file because neither tar or cpio takes in
data on stdin in create mode. They generate data that compress can take in
though. 

 Then on linux, install pdksh or ksh93 (preferrably ksh93) using whatever
methid your distribution uses. ie, on suse it's "yast") 
 Then get this script: 
 cd /usr/local/bin 
 wget http://www.aljex.com/bkw/linux/scripthelp 
 wget -O scotar http://www.aljex.com/bkw/linux/scotar-1.7.ksh 
 chmod 755 scripthelp scotar 

 Cd someplace else where you want the cpio file to appear. 
 Make it anyplace but "/" !! 
 mkdir /xenix 
 cd /xenix 
 and just run "scotar" with no options and it will prompt you to insert
floppies. (-h provides help of a sort) 

 That produces xenix.cpio.Z 

 Then run 
 zcat xenix.cpio.Z |cpio -iBv 

 That extracts it, and because you created it without absolute paths above,
everything is extracted in a subdirectory tree under wherever you are
standing. 
 IE, /etc/passwd from the xenix box gets extracted to /xenix/etc/passwd 
 Your entire old system will be laid out as it was, all under /xenix 

 If there is not room on the old fs for a compressed archive of the whole
old fs, you could take pieces of the old fs instead of the whole thing, but
you'll just end up running into things that are missing. It's only sensible
to take the whole fs. That way when it comes several months later and the
customer tries to run end of year for the first time since the switchover,
and they discover it doesn't work, and you discover in the code that it
tried to run some script in /etc or in /usr/bin, (yes, I've seen apps where
the vendoir put scripts in /, /etc, /bin, /usr/bin, all over the place, the
app required them) that you didn't think to save from the old system and
have no way to get it now... Just take the whole system and avoid the
potential, it's fine if you never end up using anything outside of /appl. 
 Also, this will still be probably 50 to 100 floppies ! 
 And floppies suck, a brand new box of 100 may have 10 that fail, causing
you to have to start all over! 

 So, that is the 101 reasons why I suggest a temporary hard driver or
ideally a tape drive. It's _easier_, and _faster_, and more likely to work
the first time, and if it doesn't you can retry a lot easier & faster than
starting another floppy run. 

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

 > ----- Original Message ----- > From: "Brian K. White" <brian at aljex.com> 
 > To: <filepro-list at lists.celestial.com> 
 > Sent: Thursday, February 02, 2006 7:05 PM 
 > Subject: Re: getting data to an updated machine 
 > 
 > 
 >> 
 >> ----- Original Message ----- >> From: "Jeff Harrison"
<jeffaharrison at yahoo.com> 
 >> To: "Creative Photography and Video" <cpvphoto at cpvphoto.com>; >>
<Filepro-list at lists.celestial.com> 
 >> Sent: Wednesday, February 01, 2006 8:37 PM 
 >> Subject: Re: getting data to an updated machine 
 >> 
 >> 
 >>> --- Creative Photography and Video 
 >>> <cpvphoto at cpvphoto.com> wrote: 
 >>> 
 >>>> I have an older version of filepro running on a 
 >>>> xenix operating system and a wyse 486 machine. If I 
 >>>> want to put this on a newer updated machine and 
 >>>> linux what might be suggested in getting data over 
 >>>> to the new machine. 
 >>>> 
 >>>> Steve> 
 >>> 
 >>> It depends on the type of system to which you will be 
 >>> transferring the data. The byte order is different on 
 >>> certain machines, so depending on the destination you 
 >>> may need to run either the fptransfer program or the 
 >>> swapcpu program. If the byte order is the same then 
 >>> you should be able to simply tar up the data files and 
 >>> indexes, then ftp and un-tar them on the destination 
 >>> machine, then rebuild your indexes. 
 >>> 
 >>> You may run into a problem with indexes - there are 
 >>> programs out there that will document them for you, 
 >>> and re-build them. You may need to look into that if 
 >>> you need to go the swapcpu route. 
 >>> 
 >>> You will of course need to make sure you have filepro 
 >>> installed properly on the new machine, and configured 
 >>> similarly to your xenix box. You will probably want 
 >>> to copy over the $PFPROG/fp/lib/edits and 
 >>> $PFPROG/fp/lib/config files, and configure the system 
 >>> with the same printer names if possible. 
 >>> 
 >>> I believe that the really old versions of filepro had 
 >>> a different menu structure - I'm not sure if you will 
 >>> run into a problem with that or not. 
 >>> 
 >>> Good Luck. 
 >> 
 >> His initial and possibly biggest problem is physically accomplishing the
>> transfer. 
 >> TCP was available for Xenix but I never saw a copy. 
 >> 
 >> If the old box still runs and has a tape drive that is modern enough to
>> install even temporarily on a new machine That that's probably the >>
easiest. 
 >> (ie, is it at least ide or scsi? vs one of the old proprietary
interfaces >> like wangtek which will not likely have a working driver on
linux) 
 >> 
 >> If the old box has an intelligent serial card (digiboard, equinox, >>
cyclades..., and the brand doesn't automatically mean it's a intelligent >>
card, there are dumb and intelligent models) then getting a copy of rz/sz >>
or preferably kermit onto the old box and using a null modem serial cable >>
is do-able. Xenix couldn't do over 9600 natively, regardless of the >>
hardware, but the drivers for the intelligent versions of those >>
aftermarket cards added the ability to take full advantage of the >>
hardware. a few hundred megs at 115200 if you can use hardware flow >>
control (also provided by the drivers, natively you'd need to use the >>
modem control version of the tty which would require special jumpers in >>
the cabling to fake carrier-detect) 
 >> 
 >> If you have the ability to install a hard drive into the old box >>
temporarily then this is also pretty easy. 
 >> add a 2nd drive to the old box, make a 512 meg fdisk partition, and cpio
>> your whole filesystem (root & all mounted fs's if you had a seperate "u"
>> for example) and direct the output right to the raw device nide for the
>> partition on the 2nd drive, then read it back in in linux. I mean, don't
>> bother making a filesystem on the 2nd drive, just an fdisk partition, no
>> divvy, no mkfs. Or really, don't even bother with the fdisk. just run >>
mkdev hd up to the point where it runs fdisk, and make note of the disk >>
device shown in fdisk (/dev/rhd10 for 2nd disk for example), quit out of >>
mkdev hd at that point and have cpio write directly to that device just >>
like it was a tape. find / -print |cpio -oBv >/dev/rhd10 
 >> 
 >> Normally of course you would not think of this as among your easier >>
choices, but with an old incompatible tape drive, or broken, or none, and >>
linux's inability to read the old drive directly because of the divvy >>
divisions, and no tcp, and serial being slow and hard to get set up and >>
working well unless you're familiar with it, temporarily installing a >>
hard drive and treating it like a big floppy or tape actually becomes >>
attractive. And it's going to be a lot faster than the serial even if you >>
had the best type of serial card and were completely fresh in your serial >>
cabling and kermit/cu/other commands and did everything perfectly right >>
the first time. 
 >> 
 >> And all of the above assumes the new box is x86, no 64 bit amd or intel,
>> no powerpc, etc... You can move to those platforms but it just takes yet
>> more consideration and it's already a bit of a chore without that. 
 >> 
 >> Then comes the interesting times of getting a new linux version of fp
and >> running the code in it and tracking down all the horrible broken >>
assumptions scattered all through it. :) 
 >> I've done exactly all this several times (take app off old xenix box and
>> get running on linux or newer sco) so it's not too awful but don't hope
>> for a second that it will "just work". It will need some real massaging
>> for a while. Everything that looks broken at first is probably completely
>> fixable. Sometimes it's a case of a hundred little things rather than a
>> few big things. 
 >> 
 >> Brian K. White -- brian at aljex.com -- http://www.aljex.com/bkw/ 
 >> +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. 
 >> 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 
 >> 
 >> 
 >> 
 > 
 > 
 > 
 _______________________________________________ 
 Filepro-list mailing list 
 Filepro-list at lists.celestial.com 
 http://mailman.celestial.com/mailman/listinfo/filepro-list 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.15.0/249 - Release Date: 2/2/2006