Moving from SCO to Linux

[Brian K. White]

Jeremy Anderson wrote:
> tom heine wrote:
>> with linux boxes, filepro is very slightly quirky,  and you really
> have to stay on top of the security updates.....
>
> Well, one has to stay on top of security updates with _any_ OS.
> Regardless of that, I'm curious as to what you mean by "very slightly
> quirky".  Quirky as in "Hrm, that's odd, that line printer was
> processing jobs fine just five minutes ago", or quirky as in "Hrm,
> that's interesting, I could've sworn there used to be a machine room
> there, instead of a mushroom cloud..."  ?

one example:
assuming your termcap is set up right with a good linux terminal definition,
and your terminal emulator does a good linux emulation, then mostly it works
& looks fine, yet even though everything is set up right, there are a few
places where the backspace key doesn't work. So far it's only filepro
built-in input prompts and not fields on screens.
There is at least one example that users are likely to encounter, but I
don't remember what it is. The example I do remember is only going to be hit
by developers.

Go into *cabe (aka: define processing), hit F9, type something into the
search prompt, try to backspace to edit the search criteria.

That's annoying but has very little impact on anything.

Mostly Yes, you tar up at least the filepro files and menus and config file
& edits
install new native linux fp on the linux box
untar your data & menus
edit /etc/default/fppath if the new filesystem & directory layout is
different
edit or restor fp/lib/config (including, edit the lp command lines in there)
run setperms

Now whats left could be as little as "nothing, you're done"
or a lot, depending on the application code

There are a lot of _possible_ problems, but in my experience I haven't
actually hit very many of them at any one time in any one app. Always a few
things at least, but generally just a few.

Off the top of my head the things to look for, or rather, to simply be ready
for if users complain:
first, cd .../filepro
1) any and all system commands
  grep -i system */prc.*
2) any and all menu batch files
  ls .../fp/menus/*.-*
3) filenames in import/export commands
  egrep -i "import|export" */prc.*
4) filenames in file i/o commands (which, maybe 4.5 didn't even have those
commands yet so that was easy)
  egrep -i
"exists\(|open\(|close\(|remove\(|read\(|write\(|readline\(|writeline\("
*/prc.*
5) target filenames of any alien files
  for i in * ;do dxmaint $i -ra -e ;done
    It's not strictly necessary to rebuild indexes, even though the version
of fp is changing drastically, but I usually do, especially if the fp
version is changing, and this just happens to halt at each alien file for
which the target data file doesn't exist. Note the filename and hit X not
ctrl-c, and the loop will proceed on to the rest of the files.
6) @os tests that say @os eq "UNIX" instead of saying @os ne "DOS"
  grep -i "@os" */prc.*

There may be other possible things, but these probably cover 99% of anything
likely.

I've moved a few different old fp apps from various original authors from
xenix & unix boxes onto linux and it was usually 99% working within a couple
hours just by reproducing or faking the original filesystem & directory
names with symlinks etc...
and editing the lp command lines in the config file. And these were not our
own app which of course I'd know most of the potential gotcha's before even
starting, but totally unfamiliar apps by others. The trickiest thing I think
I remember hitting was some output format processing that had embedded
system commands that wrote data directly to serial /dev/tty nodes, and on
linux the equivalent devices had different actual filenames in /dev. I could
have symlinked the names the app expected or edited the app. Either way it's
easy to track down and fix in no time a minute after someone says "the label
printer doesn't print". So if that was the worst, you can see it's probably
not going to be very difficult.

Also,
Reproduce the user accounts, including by using the same user ID's even
though linux by default doesn't want to allow user ID's that low. Every
record in fp stores the userid who created it. This is often useful,
actually used, info. If the new userid's don't match the ones written into
the records you get actions attributed to users that didn't do it, and most
actions attributed to meaningles id numbers with no name. It might not be
just cosmetic either. Imagine routines that make decicions, maybe even
silently, based on comparing @cu and @id.

Your /etc/default/fppath will probably need to be changed.
A common case is, sco box had a seperate /u filesystem and fp was on that,
and the correct fppath for that situation is:
---
/u/appl
/u
/appl
[encrypted site passwd if any]
---

The same directories unpacked onto a linux box that just has one big "/"
where /u is not a filesystem mount point but just a directory, fppath needs
to be changed to this:
---
/u/appl

/u/appl
[encrypted site passwd if any]
---

If you start by installing the new linux version of fp fresh on the new
linux box, a correct fppath should be created for you, especially if you
emulate the old mount point directory and use it during the fresh install,
then that will minimize the number of bad filename assumptions in the app,
like commands that specify the full path to rreport or rclerk or files in
fpmerge.

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