FACTS inode problem, linux-abi, bbx

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From: brian@aljex.com (Brian K. White)
Subject: Re: FACTS on SCO
Date: 6 Nov 2002 14:44:20 -0800
References: <3DB6AF9A.8090206@pcunix.com> <7BFt9.2426$YJ1.5242557@ruti.visi.com> <20021023183956.64072@tegan.com> <ap8iom$2ik$1@pcls4.std.com> <56fe3a2b.0210240626.27704aa@posting.google.com> <ap91n7$a0i$1@pcls4.std.com> 

Tony Lawrence <tony@pcunix.com> wrote in message news:<ap91n7$a0i$1@pcls4.std.com>...
> Dan Martin wrote:
> > Tony Lawrence <tony@pcunix.com> wrote in message news:<ap8iom$2ik$1@pcls4.std.com>...
> > 
> >>Tom Parsons wrote:
> >>
> >>>Dave Gresham enscribed:
> >>>| In article <3DB6AF9A.8090206@pcunix.com>,
> >>>| Tony Lawrence  <tony@pcunix.com> wrote:
> >>>| >Probably a lot of you have never heard of FACTS on Unix, but it used to 
> >>>| >be fairly common.  I'm hoping that somebody remembers or still uses this 
> >>>| >and might shed some light on this:
> >>>| >
> >>>| >History:  heavily customized FACTS on SCO since 3.2v4.2, currently 
> >>>| >5.0.6, proper patches, good new hardware.
> >>>| >
> >>>| 
> >>>| I have worked on Facts for several years.  How long ago did you
> >>>| upgrade to 5.0.6? Also, do you know what version of BBx you are
> >>>| working with?
> >>>| 
> >>>| If you are running anything less that Pro/5 you could be running
> >>>| into limitations of such an old Bbx engine. It has been a few
> >>>| years since I did any conversions of BBx from 3.2.4.2 to Openserver
> >>>| 5.0.x, however I seem to recall a rather nasty bug.
> >>>| 
> >>>| I just remembered the bug, it didn't know how to handle inodes
> >>>| properly in 5.0.x, and there was the possibility that it could
> >>>| start writing to a file other than the one the program tried
> >>>| to open.
> >>>
> >>>It had nothing to do with being unable to handle inodes properly
> >>>in OSR5.  For some silly reason, BBx was written in such a manner
> >>>that it could not handle inodes greater that just less than 64K.
> >>>It has no issue with inode numbers below that ceiling.
> >>>
> >>>I wouldn't call that a bug, I'd call it a feature of a very old product.
> >>>BBx and Pro5 have more than enough bugs without getting blamed for this.
> >>>
> >>>Having said all of this, I upgraded several BBx customers to OpenServer
> >>>and some are still running the old BBx.  It's no big deal, just make
> >>>the filesystems with mkfs and restrict the number of inodes to under
> >>>64K.  It was some time ago but I think I made the filesystems EAFS.
> >>
> >>Ahah!
> >>
> >>That certainly could be the issue1
> > 
> > 
> > Dear Tony,
> > 
> > I wish I had more to offer on this.
> > 
> > You probably want to try your post on basis.bbx-list
> > 
> > If you run "pro5" from the shell prompt, in the 
> > directory that contains the config.bbx file, you should
> > get a banner screen with serial number, version and release
> > number.  This will be helpful to the folks on the bbx list.
> > Substitute "bbx4" for "pro5" if their stuff is really old,
> > in which case, an upgrade might provide an immediate fix.
> > 
> > You can also search the knowledge base at www.basis.com
> > where I found this, which discusses the inode problem:
> > 
> > http://www.basis-knowledgebase.com/kb00686.html
> 
> 
> Ayup.  After looking at that, I think that is the most likely culprit. 
> Unfortunately for me, that means a Sunday job (24 hr x 6 day operation 
> there) but I feel good about the chances of it fixing the problem for good.
> 
> > Brian White is an expert in FACTS, 
> 
> Is there anything Brian ISN'T good at ?
> 
> :-)

humility?
getting up before 10 am?

actually I'm no expert at FACTS. I was forced to become rather
intimate with Prosper, FACTS's ancestor, and bbx3 on xenix, and I
still have copies running on 5.0.5, 5.0.6 and linux (only the 5.0.5 is
in production and that only for looking at legacy data that I didn't
export to the filePro app that replaced it.) I didn't know about the
inode problem at the time I first installed it, and it has not given
them any problems on a 9gig osr5 box. I may have just "lucked out" by
the fact that the copy was done early in the new box's life (most of
the drive was still empty) and since then they have never entered any
new data into the old app, just run it and look at stuff. I heard
about the possible problem sometime later but decided as long as they
don't have a problem, I won't mess with it.

I did recently help a guy try several different ways to transplant a
FACTS installation onto newer hardware. because osr5 could not support
the built-in and _very fast and desireable_ scsi card, we tried other
OS's
original osr5 pro5 bins on linux
original osr5 pro5 bins on freebsd (on my box)
new demo linux pro5 bins on linux
original osr5 pro5 bins on unixware

the last 2 worked well enough, but one required a several thousand
dollar pro5 upgrade, and the other required a several thousand dollar
OS trade-in & upgrade. Plus there would have been other things to deal
with such as the fax software that I never heard of. I did get the
linux-abi working on the linux box, but it just turned out that this
version of pro5 doesn't work in it, even though my old bbx3 did.

so he ended up putting in a (much slower) scsi card in the new box so
that osr5 could run on it, and sticking with osr5.

It was a pleasant excersise though. I ended up getting a fair brush-up
on:
- linux-abi on recent versions or redhat, including differences right
within the same version of redhat, after you install the updated
kernel rpm's (grrrr).
- svr4/ibcs on recent versions of freebsd.
- bbx startup-script changes and bbx termcap changes to deal with
various common terminals (linux console, freebsd console, unixware
console, rxvt, xterm)
- bbx startup script and environment changes to take a osr5 version of
facts, and transplant the facts bbx programs & data onto native linux
version of pro5 and linux OS.

running the osr5 pro5 binaries and facts on unixware required
practically nothing in the way of hacking. a little termcap twiddling
maybe, maybe not even that. Parts of that weekend are all a big blur
now.
 

Take Control of the Mac Command Line with Terminal

Take Control: The Mac OS X Lexicon

Take Control of Screen Sharing in Leopard

Take Control of Permissions in Leopard

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.