FACTS on SCO
Tony Lawrence
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.
System used to be mostly terminals. Some of the terminals were always
connected through a Digi Port server. No telnet sessions were used
until recently.
Recently we put the system on new hardware and put most of the terminal
users on Zoc terminal emulation over telnet instead. The terminals
served by the Portserver remained the same.
Since that change, we've had irregular problems with the CONTRL.Y2K file
growing from its normal 300 or 400k to gigabyte size and ultimately
crashing FACTS as a result. For a while we suspected hardware but this
is the only file being corrupted. We swapped hardware just in case, it
changed nothing.
It MOSTLY happens once a week at around the same time of the morning, so
of course I then suspected some procedure that is causing this, and it
turns out that yes, a particular user DOES do something unusual both the
night before and the morning of the day of the week that this usually
happens on. So we went through a very long multi-week procedure of
trying to nail this down: have him use a different machine, have him do
the procedure as a different user, have him do it at different times,
have him not do it at all and all possible combinations which got us
absolutely no useful information: the uncontrolled growth happens or it
doesn't and there does not seem to be any relationship we can find to
anything anyone does: we can't MAKE it happen.
I thought it might have to do with telnet sessions, but those Portserver
terminal users were, of course, always telnet sessions.
So- it's a very unhappy situation right now. Any thoughts or
experiences will certainly be appreciated. If anyone knows of a more
focused place to ask this (a FACTS user group for example) that too
would help.
Thanks as usual..
--
Please note new phone number: (781) 784-7547
Tony Lawrence
Unix/Linux Support Tips, How-To's, Tests and more: http://aplawrence.com
Free Unix/Linux Consultants list: http://aplawrence.com/consultants.html
Bob Meyers
"Tony Lawrence" <to...@pcunix.com> wrote in message
news:3DB6AF9A...@pcunix.com...
> 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:
>
> connected through a Digi Port server. No telnet sessions were used
> until recently.
>
Did you have him try the corrupting procedure on the console?
Tony Lawrence
There's no procedure- we don't know what causes this. The console is
almost never used except by me to do maintenance- and even that's pretty
rare as I ssh in mostly.
Jeff Liebermann
>Since that change, we've had irregular problems with the CONTRL.Y2K file
>growing from its normal 300 or 400k to gigabyte size and ultimately
>crashing FACTS as a result. For a while we suspected hardware but this
>is the only file being corrupted. We swapped hardware just in case, it
>changed nothing.
Well, I have a guess(tm).
Any chance you're running into a 2GB file size limit?
Perhaps ULIMIT? The default system ULIMIT is only 1GB.
http://osr5doc.ca.caldera.com:457/FEATS/RNlimFileSize.html
I don't know anything about FACTS.
--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)336-2558 home
http://www.LearnByDestroying.com WB6SSY
je...@comix.santa-cruz.ca.us je...@cruzio.com
Tony Lawrence
> On Wed, 23 Oct 2002 10:18:02 -0400, in comp.unix.sco.misc you wrote:
>
>
>>Since that change, we've had irregular problems with the CONTRL.Y2K file
>>growing from its normal 300 or 400k to gigabyte size and ultimately
>>crashing FACTS as a result. For a while we suspected hardware but this
>>is the only file being corrupted. We swapped hardware just in case, it
>>changed nothing.
>
>
> Well, I have a guess(tm).
>
> Any chance you're running into a 2GB file size limit?
> Perhaps ULIMIT? The default system ULIMIT is only 1GB.
> http://osr5doc.ca.caldera.com:457/FEATS/RNlimFileSize.html
Oh probably- but the file should be 300 or 400k- when it starts growing
it is out of control and will sooner or later crash FACTS anyway-
whether or not it reaches ULIMIT. All it is is supposed to be is
housekeeping data- next invoice number, printer and ttydefs defs and
that sort of thing. It isn't static, but it shouldn't be larger than
the 300 or 400 k it normally is.
Jeff Liebermann
wrote:
>Jeff Liebermann wrote:
>> On Wed, 23 Oct 2002 10:18:02 -0400, in comp.unix.sco.misc you wrote:
>>
>>
>>>Since that change, we've had irregular problems with the CONTRL.Y2K file
>>>growing from its normal 300 or 400k to gigabyte size and ultimately
>>>crashing FACTS as a result. For a while we suspected hardware but this
>>>is the only file being corrupted. We swapped hardware just in case, it
>>>changed nothing.
>>
>>
>> Well, I have a guess(tm).
>>
>> Any chance you're running into a 2GB file size limit?
>
> > Perhaps ULIMIT? The default system ULIMIT is only 1GB.
> > http://osr5doc.ca.caldera.com:457/FEATS/RNlimFileSize.html
>
>
>Oh probably- but the file should be 300 or 400k- when it starts growing
>it is out of control and will sooner or later crash FACTS anyway-
>whether or not it reaches ULIMIT. All it is is supposed to be is
>housekeeping data- next invoice number, printer and ttydefs defs and
>that sort of thing. It isn't static, but it shouldn't be larger than
>the 300 or 400 k it normally is.
Well, in that case, something is filling the file with spurious
debris. It could be saving login failures, error messages, network
errors, printer errors, and other manure that might be generated
continuously. For example, my syslog file is full of BOOTP error
messages because I'm too lazy to disarm the monster. Look inside and
see what you find.
Tony Lawrence
Millions of bytes of mostly empty space. I should have mentioned that
before- a "strings" spits out a little of the kind of stuff you'd
expect, but hangs for long periods skipping over vast expanses of nothing..
Bill Vermillion
If FACTS is not shut down cleanly it will take some files that are
normally relatively small and make big files out of them. I saw
this at a customer site a few times and it's not pretty. They had
their own FACTS support person so I don't know all the details.
Cleanup is a pain and it happened often enough on systems the
support person handled that he had scripts he build to rebuild the
mess.
--
Bill Vermillion - bv @ wjv . com
Dave Gresham
Tony Lawrence <to...@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.
If you are not at Pro/5, then due to the way that FACTS was
licensed, you are going to have to go to a Facts Dealer and
ask what their policies are towards this.
The company that created FACTS is near Atlanta, GA, and their
name is Software Solutions.
>System used to be mostly terminals. Some of the terminals were always
>connected through a Digi Port server. No telnet sessions were used
>until recently.
>
>Recently we put the system on new hardware and put most of the terminal
>users on Zoc terminal emulation over telnet instead. The terminals
>served by the Portserver remained the same.
>
>Since that change, we've had irregular problems with the CONTRL.Y2K file
>growing from its normal 300 or 400k to gigabyte size and ultimately
>crashing FACTS as a result. For a while we suspected hardware but this
>is the only file being corrupted. We swapped hardware just in case, it
>changed nothing.
It has been awhile since I used Facts, but that file name doesn't
sound like a standard Facts file.
>
>It MOSTLY happens once a week at around the same time of the morning, so
>of course I then suspected some procedure that is causing this, and it
>turns out that yes, a particular user DOES do something unusual both the
>night before and the morning of the day of the week that this usually
>happens on. So we went through a very long multi-week procedure of
>trying to nail this down: have him use a different machine, have him do
>the procedure as a different user, have him do it at different times,
>have him not do it at all and all possible combinations which got us
>absolutely no useful information: the uncontrolled growth happens or it
>doesn't and there does not seem to be any relationship we can find to
>anything anyone does: we can't MAKE it happen.
>
>I thought it might have to do with telnet sessions, but those Portserver
>terminal users were, of course, always telnet sessions.
>
Bbx can be rather picky about terminal numbers, it assigns
a Terminal ID, ie T1, T2, T10, etc and this identifier code
is used by FACTS to determine what options are available to
a user.
>So- it's a very unhappy situation right now. Any thoughts or
>experiences will certainly be appreciated. If anyone knows of a more
>focused place to ask this (a FACTS user group for example) that too
>would help.
>
>Thanks as usual..
>
>
Hopefully you can find a FACTS support person who could look at this.
There skill set would need Bbx.
Tom Parsons
| In article <3DB6AF9A...@pcunix.com>,
| Tony Lawrence <to...@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.
--
==========================================================================
Tom Parsons t...@tegan.com
==========================================================================
Jeff Liebermann
wrote:
>Millions of bytes of mostly empty space. I should have mentioned that
>before- a "strings" spits out a little of the kind of stuff you'd
>expect, but hangs for long periods skipping over vast expanses of nothing..
Any chance it's a "sparse file"? Check it while it's running
normally. If so, then I suspect (guess) that it might write a giant
version of the sparse file to disk. If true, I don't have the
slightest idea what to do to prevent this from happening.
Tony Lawrence
Ahah!
That certainly could be the issue1
Tom Parsons
| Tom Parsons wrote:
| >
| > 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
I hope you remember your ancient history better than I because the
maximun number of usable inodes in those filesystems is somewhat less
than 64K but I can't find the exact number. I imagine I erred on the
cautious side and configured only 60,000 or so, knowing that would be a
safe number.
Tony Lawrence
> Tony Lawrence enscribed:
> | Tom Parsons wrote:
> | >
> | > 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
>
> I hope you remember your ancient history better than I because the
> maximun number of usable inodes in those filesystems is somewhat less
> than 64K but I can't find the exact number. I imagine I erred on the
> cautious side and configured only 60,000 or so, knowing that would be a
> safe number.
Well, currently there are only 49000 inodes on the entire system, so I
can certainly err on the side of caution and still leave room to grow.
Or I can break it into a couple of file systems (still with less inodes)
too.
Dan Martin
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
Brian White is an expert in FACTS, and Pat Welch certainly
knows his way around bbx, though I don't know if he has worked
with FACTS. Maybe they'll chime in.
Good luck,
Dan
Tony Lawrence
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 ?
:-)
Bob Bailin
In addition to all the suggestions made above, remember to run the BBx
"_fix"
utility on the CONTRL.Y2K BBx file to check for invalid internal pointers.
BBx has an internal option (in OPTS) to check for possible file corruption
upon each file open, generating an error=54 if the user count for a newly
(systemwide) opened file is non-zero. Many end-users disable this feature.
Also consider upgrading the user to the latest version of Pro/5 (3.x) which
features highly recoverable multi-keyed files and more robust error
checking.
Brian K. White
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.