Bela Lubkin wrote:
> waiting to catch those crucial few seconds. The opportunity to get
> your Unix system into single-user mode is much like the opportunity
> to get a machine into BIOS setup. It is reasonable for it to delay a
> bit so you have a chance to catch it.

I don't think the analogy is quite so: if you missed the BIOS "del" key
(or whatever), you have no recourse but another reboot; however, if you
missed the OpenServer "Boot:" prompt (to tell the system to go into
Single-User), you can always do an "init 1".

> It's a server OS. It should, in fact, only be rebooted in
> extraordinary circumstances.

The system may be so, but the applications that it usually runs more
often than not need a nightly reboot (Filepro, anyone?).

Pepe typed (on Fri, Jul 04, 2008 at 05:03:32PM +0200):
> Bela Lubkin wrote:
>> waiting to catch those crucial few seconds. The opportunity to get
>> your Unix system into single-user mode is much like the opportunity to
>> get a machine into BIOS setup. It is reasonable for it to delay a
>> bit so you have a chance to catch it.
>
> I don't think the analogy is quite so: if you missed the BIOS "del" key
> (or whatever), you have no recourse but another reboot; however, if you
> missed the OpenServer "Boot:" prompt (to tell the system to go into
> Single-User), you can always do an "init 1".
>
>> It's a server OS. It should, in fact, only be rebooted in
>> extraordinary circumstances.
>
> The system may be so, but the applications that it usually runs more
> often than not need a nightly reboot (Filepro, anyone?).

I have been using filePro for twenty years and I have never seen a site
where filePro required nightly reboots, or for that matter where filePro
ever required any reboot whatsoever.


--
JP

----- Original Message -----
From: "Pepe" <pepe@naleco.com>
Newsgroups: comp.unix.sco.misc
To: <distro@jpr.com>
Sent: Friday, July 04, 2008 11:03 AM
Subject: Re: SCO 5.0.4/5 stops at boot: prompt on a fresh install in a VMware workstation


> Bela Lubkin wrote:
>> waiting to catch those crucial few seconds. The opportunity to get
>> your Unix system into single-user mode is much like the opportunity
>> to get a machine into BIOS setup. It is reasonable for it to delay a
>> bit so you have a chance to catch it.
>
> I don't think the analogy is quite so: if you missed the BIOS "del" key
> (or whatever), you have no recourse but another reboot; however, if you
> missed the OpenServer "Boot:" prompt (to tell the system to go into
> Single-User), you can always do an "init 1".
>
>> It's a server OS. It should, in fact, only be rebooted in
>> extraordinary circumstances.
>
> The system may be so, but the applications that it usually runs more
> often than not need a nightly reboot (Filepro, anyone?).

What about filePro?

My current supported user count running filepro, not counting all the customers with their own servers, is around 1000, spread over 6 machines.

All filePro.

Lets see...

nj4:~ # cd /u/global/appl/filepro
nj4:/u/global/appl/filepro # ls |wc -l
663
nj4:/u/global/appl/filepro # find ./ -name 'prc.*' |wc -l
9995
nj4:/u/global/appl/filepro # find ./ -name 'index*' |wc -l
92173

nj4:/u/global/appl/filepro # find ./ -name 'key*' |wc -l
22252
nj4:/u/global/appl/filepro # find ./ -name 'prc.*' |xargs cat |wc -l
1844564

nj4:/u/global/appl/filepro # uptime
11:45am up 166 days 11:20, 11 users, load average: 0.17, 0.16, 0.18
nj4:/u/global/appl/filepro #

The filepro licences are 256 user and we do bump into it once in a while, there is often 200 concurrent users most weekdays. Our smallest box is still bout 100 concurrent users. That's people, not filepro instances or login sessions, those numbers are even higher of course.

663 filepro files
10 thousand processing tables
1.8 _million_ lines of code (granted, maybe 1/3 isn't used)
22 _thousand_ key segments (we don't use any data segnments so all data is in the indexable keys)
92 _thousand_ individual automatic index files. (we almost never use demand indexes, so this number does represent he number of auto indexes that filepro maintains without error for at least the last 166 days with 200 users pounding on it most of those days)

Oh, I forgot, that box also hosts a couple of other filepro trees in addition to the one above, similar files and processing, just with only a few qualifiers. The directory above hosts about 40 qualifiers, which translates to about 40 companies, each with their own whole office full of employees all logged in with multiple windows all day every day.
So add to above maybe 4 more qualifiers and 40 more users.

And that's just one box, we ourselves have about 5 more just counting the live production boxes all with similar numbers.
Then there are all the last 15 or so years worth of customers who each got their own server with most of those in the 10-30 user range, a few 50's and a couple 100's and a 150.

With all that pounding, we almost never rebuild indexes or freechains or reboot or delete lockfiles or any of that crap that some people do.

These are all opensuse 10.x linux boxes now, but things were if anything better on OSR5. the individual boxes couldn't handle as many users because of plain filesystem speed, but the uptimes were longer and in neither case have uptimes been shortened by filePro. In neither case have we ever had to rebuild indexes or reboot or build freechains etc except on specific occasions for a specific file as a result of some particular specific damage or merely as a part of programming and restructuring.

Now, in the interest of full disclosure, we did have one mystery problem once a couple of years ago that we never tracked down, but, without changing the OS, the filepro binaries, the server hardware, or the server load & usage profile, but with constant filepro programming changes being made by 6 developers, a very rare lock-up problem occured that could only be fixed by a reboot (no amount of killing processes anf freeing file/record locks helped) it only happened maybe 3 or 4 times , all in a few month window about 2 or 3 years ago. Whatever it was somewhere in our code, it might have been technically legal, and thus a filepro bug. But this tells me it was both an extremely exotic bug, and possible to avoid, since we in fact no longer have it. I'm pretty sure it was programmer error somewhere that probably got fixed in the natural course of things without the fixer even realising they were fixing that problem as well as whatever they were intending to do. That was THE only time in 10 years and and somewhere around 200 filepro installations of just my own personal first hand experience that filepro necessitated a reboot. I have sco boxs out there in peoples offices with only 50 or fewer users generally, but they go years btween reboots, and then it's usually plain hardware failure or power or physical relocation. Several of those predate me joining the company and they never needed rebooting in all the years they were up before that either.

Not counting the windows installations. They are as you might guess, a different stoy.

Whatever problem you have that you think requires rebooting, it very probably doesn't. What it requires is someone who can spell unix to look things over and find the problems. Similarly for whatever language your main app is written in (filePro in your case apparently)

In the face of how hard we pound on filepro and how perfect it performs, I say that proves that filePro is not a weak link and not the blame for anything you think can only be fixed by rebooting.

Try again only try to find some other scapegoat. filePro sure isn't one.

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

Jean-Pierre Radley wrote (on Fri, Jul 04, 2008 at 12:03:08PM -0400):

| Pepe typed (on Fri, Jul 04, 2008 at 05:03:32PM +0200):
| > Bela Lubkin wrote:
| >> waiting to catch those crucial few seconds. The opportunity to get
| >> your Unix system into single-user mode is much like the opportunity to
| >> get a machine into BIOS setup. It is reasonable for it to delay a
| >> bit so you have a chance to catch it.
| >
| > I don't think the analogy is quite so: if you missed the BIOS "del" key
| > (or whatever), you have no recourse but another reboot; however, if you
| > missed the OpenServer "Boot:" prompt (to tell the system to go into
| > Single-User), you can always do an "init 1".
| >
| >> It's a server OS. It should, in fact, only be rebooted in
| >> extraordinary circumstances.
| >
| > The system may be so, but the applications that it usually runs more
| > often than not need a nightly reboot (Filepro, anyone?).
|
| I have been using filePro for twenty years and I have never seen a site
| where filePro required nightly reboots, or for that matter where filePro
| ever required any reboot whatsoever.
|
| --
| JP

Me too . . . starting with PROFILE on TRSDOS and taking every
step on the way until now with filePro 5.6.06D4 on SCO OSR 6,
and no version of Profile/filePro ever required a reboot for
any reason at any time on any of the various OS's [1].

Bob

[1] - OS's after TRSDOS were either Xenix or UNIX.

--
Bob Stockler +-+ bob@trebor.iglou.com +-+ http://members.iglou.com/trebor

Brian K. White wrote:
> ----- Original Message ----- From: "Pepe" <pepe@naleco.com>
> Newsgroups: comp.unix.sco.misc To: <distro@jpr.com> Sent: Friday,
> July 04, 2008 11:03 AM Subject: Re: SCO 5.0.4/5 stops at boot: prompt
> on a fresh install in a VMware workstation
>
>> Bela Lubkin wrote:
>>
>>> waiting to catch those crucial few seconds. The opportunity to
>>> get your Unix system into single-user mode is much like the
>>> opportunity to get a machine into BIOS setup. It is reasonable
>>> for it to delay a bit so you have a chance to catch it.
>>
>> I don't think the analogy is quite so: if you missed the BIOS "del"
>> key (or whatever), you have no recourse but another reboot;
>> however, if you missed the OpenServer "Boot:" prompt (to tell the
>> system to go into Single-User), you can always do an "init 1".
>>
>>> It's a server OS. It should, in fact, only be rebooted in
>>> extraordinary circumstances.
>>
>> The system may be so, but the applications that it usually runs
>> more often than not need a nightly reboot (Filepro, anyone?).
>
> What about filePro?
>
> My current supported user count running filepro, not counting all the
> customers with their own servers, is around 1000, spread over 6
> machines.

I don't know how can it be so stable for you. In a trucking company,
they had to reboot the OSR5 servers every night to get going the next
day... they had Filepro until they changed to an Oracle backend on Linux
and totally rewrote the application.

It was vox populi then that the cause for that was Filepro in a
multiuser concurrent environment. Maybe they were wrong.

On Fri, Jul 04, 2008, Pepe wrote:
>Brian K. White wrote:
....
>>
>> My current supported user count running filepro, not counting all the
>> customers with their own servers, is around 1000, spread over 6
>> machines.
>
>I don't know how can it be so stable for you. In a trucking company,
>they had to reboot the OSR5 servers every night to get going the next
>day... they had Filepro until they changed to an Oracle backend on Linux
>and totally rewrote the application.
>
>It was vox populi then that the cause for that was Filepro in a
>multiuser concurrent environment. Maybe they were wrong.
>
Yours is the exception rather than the rule. In the 20+ years I
have been supporting SCO systems, most have uptimes measured in
years, rebooting only for power failures or hardware moves.

Some applications require restarting when rotating logs, but
FilePro is not one that requires this. I could see possible
problems if one had lots of crashing Windows clients (is there
any other kind :-) leaving things in a strange state.

Bill
--
INTERNET: bill@celestial.com Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
Voice: (206) 236-1676 Mercer Island, WA 98040-0820
Fax: (206) 232-9186

Permit me to issue and control the money of a nation, and I care not
who makes its laws. -- Mayer Amschel Rothschild

Bela Lubkin wrote:
> Nico Kadel-Garcia wrote:
>
>> What happens if you just *wait* for a few minutes? Under 5.0.6,
>> there's a lengthy pause at that stage: I think that it's a legacy of
>> what is basically a very antique operating system that thinks you
>> should reboot only in emergencies, and threefore you *MUST* want a
>> lengthy chance to have a talk with it at boot time.
>
> Wow, that's an interesting interpretation.
>
> It's a server OS. It should, in fact, only be rebooted in extraordinary
> circumstances. It is not a version of Windows where the first "cure"
> for any glitch is a drive-by rebooting. This has nothing to do with
> antiquity.

I don't use "rock-stable" OS's as servers, because they turn out not to be.
Lightweight, userland redundancy and duplication of servers is usually more
reliable and gives flexibility for changing needs.

And the SCO OpenServer 5.0.6 systems are far, far more likely to need
rebooting than the other systems I deal with. The tendency of cpio tape
backups to hang the tape drive and require a reboot is *nasty*. I haven't seen
anything that bad in the server world in decades.

> Rebooting takes a while. Have you ever worked with a machine whose BIOS
> takes 3-4 minutes to initialize, but which gives you only a few seconds
> to tell it to go into BIOS setup? Pretty darn annoying, isn't it?
> You have to power cycle it, then watch carefully for several minutes,
> waiting to catch those crucial few seconds. The opportunity to get your
> Unix system into single-user mode is much like the opportunity to get a
> machine into BIOS setup. It is reasonable for it to delay a bit so you
> have a chance to catch it.
>
> And it's easily tuned.
>
>> Bela<

I agree with the BIOS problem. It's aggravated with SCSI devices. Amazingly,
it's eased by Linux BIOS's, which can be configured and don't spend ages
scanning for non-existent and deprecated hardware: the OLPC project uses them.

A delay is quite reasonable, I agree. But an additional line of text saying
'will boot in 60 seconds' wouldn't kill anyone to have written into the boot
loader.

Nico Kadel-Garcia wrote:

> Bela Lubkin wrote:
> > Nico Kadel-Garcia wrote:
> >
> >> What happens if you just *wait* for a few minutes? Under 5.0.6,
> >> there's a lengthy pause at that stage: I think that it's a legacy of
> >> what is basically a very antique operating system that thinks you
> >> should reboot only in emergencies, and threefore you *MUST* want a
> >> lengthy chance to have a talk with it at boot time.
> >
> > Wow, that's an interesting interpretation.
> >
> > It's a server OS. It should, in fact, only be rebooted in extraordinary
> > circumstances. It is not a version of Windows where the first "cure"
> > for any glitch is a drive-by rebooting. This has nothing to do with
> > antiquity.
>
> I don't use "rock-stable" OS's as servers, because they turn out not to be.
> Lightweight, userland redundancy and duplication of servers is usually more
> reliable and gives flexibility for changing needs.

Hmmm, I believe this is called "Sweet Lemons". Yes, you can build
something more or less reliable out of sufficiently redundant unreliable
parts, if that's how you want to work.

> And the SCO OpenServer 5.0.6 systems are far, far more likely to need
> rebooting than the other systems I deal with. The tendency of cpio tape
> backups to hang the tape drive and require a reboot is *nasty*. I haven't seen
> anything that bad in the server world in decades.

Use a different type of tape drive, different HBA, cabling, or
whatever's causing the issue. Or use a different backup strategy.
Certainly don't just live with the problem...

> > Rebooting takes a while. Have you ever worked with a machine whose BIOS
> > takes 3-4 minutes to initialize, but which gives you only a few seconds
> > to tell it to go into BIOS setup? Pretty darn annoying, isn't it?
> > You have to power cycle it, then watch carefully for several minutes,
> > waiting to catch those crucial few seconds. The opportunity to get your
> > Unix system into single-user mode is much like the opportunity to get a
> > machine into BIOS setup. It is reasonable for it to delay a bit so you
> > have a chance to catch it.
>
> I agree with the BIOS problem. It's aggravated with SCSI devices. Amazingly,
> it's eased by Linux BIOS's, which can be configured and don't spend ages
> scanning for non-existent and deprecated hardware: the OLPC project uses them.
>
> A delay is quite reasonable, I agree. But an additional line of text saying
> 'will boot in 60 seconds' wouldn't kill anyone to have written into the boot
> loader.

Yeah, that's a long time deficiency of the OSR5 boot program.

>Bela<

Bela Lubkin wrote:
> Nico Kadel-Garcia wrote:
>
>> Bela Lubkin wrote:
>>> Nico Kadel-Garcia wrote:
>>>
>>>> What happens if you just *wait* for a few minutes? Under 5.0.6,
>>>> there's a lengthy pause at that stage: I think that it's a legacy of
>>>> what is basically a very antique operating system that thinks you
>>>> should reboot only in emergencies, and threefore you *MUST* want a
>>>> lengthy chance to have a talk with it at boot time.
>>> Wow, that's an interesting interpretation.
>>>
>>> It's a server OS. It should, in fact, only be rebooted in extraordinary
>>> circumstances. It is not a version of Windows where the first "cure"
>>> for any glitch is a drive-by rebooting. This has nothing to do with
>>> antiquity.
>> I don't use "rock-stable" OS's as servers, because they turn out not to be.
>> Lightweight, userland redundancy and duplication of servers is usually more
>> reliable and gives flexibility for changing needs.
>
> Hmmm, I believe this is called "Sweet Lemons". Yes, you can build
> something more or less reliable out of sufficiently redundant unreliable
> parts, if that's how you want to work.

I've built Beowulf clusters this way, and helped deploy thousands of machines
worldwide. It's a viable strategy.

>> And the SCO OpenServer 5.0.6 systems are far, far more likely to need
>> rebooting than the other systems I deal with. The tendency of cpio tape
>> backups to hang the tape drive and require a reboot is *nasty*. I haven't seen
>> anything that bad in the server world in decades.
>
> Use a different type of tape drive, different HBA, cabling, or
> whatever's causing the issue. Or use a different backup strategy.
> Certainly don't just live with the problem...

Right. That's why I'm using a Linux box to take rsnapshot backups and run the
tapedrive. If I need more sophisticated tape management, or a tape library, or
encrypted backup. I'll use Amanda software on top of it. The rsnapshot can run
over a secure SSH tunnel, the rsnapshot server can serve NFS, SMB, or SSH
tunneled rsync back to the SCO system, and it's all freeware. It takes some
work to set up and configure, but that's true of anything. And the snapshot
capability approaches that of a NetApp storage array.

>>> Rebooting takes a while. Have you ever worked with a machine whose BIOS
>>> takes 3-4 minutes to initialize, but which gives you only a few seconds
>>> to tell it to go into BIOS setup? Pretty darn annoying, isn't it?
>>> You have to power cycle it, then watch carefully for several minutes,
>>> waiting to catch those crucial few seconds. The opportunity to get your
>>> Unix system into single-user mode is much like the opportunity to get a
>>> machine into BIOS setup. It is reasonable for it to delay a bit so you
>>> have a chance to catch it.
>> I agree with the BIOS problem. It's aggravated with SCSI devices. Amazingly,
>> it's eased by Linux BIOS's, which can be configured and don't spend ages
>> scanning for non-existent and deprecated hardware: the OLPC project uses them.
>>
>> A delay is quite reasonable, I agree. But an additional line of text saying
>> 'will boot in 60 seconds' wouldn't kill anyone to have written into the boot
>> loader.
>
> Yeah, that's a long time deficiency of the OSR5 boot program.
>
>> Bela<

The accounting program "Synchronics" at one of my customers leaves
enough stuff open that it runs out of internal storage somewhere
around 2 weeks. I have it rebooting at 1 AM every Sunday. The side
benefit is having a record that it happened so the customer can't
complain that the package failure is because it didn't reboot.

I have taken the boot timeout down to 5 seconds on several machines
but mostly take them to 15 seconds. Gives me a pretty fast turnaround
at a vet clinic chain that is required to reboot every night by their
software supplier.