I have a client with a persistent data corruption problem (about
which I've posted before). Their app runs in Pro/5 - version 2.25,
if memory serves.

Today, the tech support guy from the company where they buy
Pro/5 software casually mentioned that he hoped we weren't running
5.0.7 because it has corruption problems with Pro/5. He says
that they have seen numerous such problems, and that Basis (the
company that makes Pro/5) has been pestering SCO to try to
get these problems fixed. He claims that 5.0.6 did not have these
problems with Pro/5.

(Their previous server ran 5.0.5 or 5.0.6 - I forget which - and
was solid until shortly before it was replaced. We never identified
the cause of its sudden decrease in stability but we don't believe
it was a software issue.)

One of my colleagues is trying to get more information out
of Basis regarding this suggestion.

I know quite a few of the folks here use BBx or Pro/5 on OSR5;
have you seen file corruption problems on 5.0.7?
--
Stephen M. Dunn <stephen@stevedunn.ca>
>>>----------------> http://www.stevedunn.ca/ <----------------<<<
------------------------------------------------------------------
Say hi to my cat -- http://www.stevedunn.ca/photos/toby/

In article <HooI79.wt@stevedunn.ca>,
Stephen M. Dunn <stephen@stevedunn.ca> wrote:
> I have a client with a persistent data corruption problem (about
>which I've posted before). Their app runs in Pro/5 - version 2.25,
>if memory serves.

According to www.basis.com it states that 2.25 is supported for 5.05,
and 4.10 is supported through 5.06. I know we recently ported a
client to 5.0.7 who is running pro/5, but I don't know what
version of pro/5 they are using.
>
> Today, the tech support guy from the company where they buy
>Pro/5 software casually mentioned that he hoped we weren't running
>5.0.7 because it has corruption problems with Pro/5. He says
>that they have seen numerous such problems, and that Basis (the
>company that makes Pro/5) has been pestering SCO to try to
>get these problems fixed. He claims that 5.0.6 did not have these
>problems with Pro/5.

I'll see what I can dig up tommorow.

Dave

In article <HooI79.wt@stevedunn.ca>,
Stephen M. Dunn <stephen@stevedunn.ca> wrote:
> I have a client with a persistent data corruption problem (about
>which I've posted before). Their app runs in Pro/5 - version 2.25,
>if memory serves.

> Today, the tech support guy from the company where they buy
>Pro/5 software casually mentioned that he hoped we weren't running
>5.0.7 because it has corruption problems with Pro/5. He says
>that they have seen numerous such problems, and that Basis (the
>company that makes Pro/5) has been pestering SCO to try to
>get these problems fixed. He claims that 5.0.6 did not have these
>problems with Pro/5.

> (Their previous server ran 5.0.5 or 5.0.6 - I forget which - and
>was solid until shortly before it was replaced. We never identified
>the cause of its sudden decrease in stability but we don't believe
>it was a software issue.)

If it was unstable on the 5.0.5 or 5.0.6 and is unstable on 5.0.7
why do you rule out software as the issue. Sudden decrease in
performance [as opposed to gradual] usually has a point of orgin.

Replacement of HW or SW based on "it's probalby XXX" are often
wrong from my observations. Only when you truly identify the
problem can you make a true recommendation for changing HW, SW or
both.

I don't have any clients on Pro/5 anymore. It was stable but it
was in my opinion too fragile for my tastes. An admin error
killing something, or the inadvertant turning off of the UPS
because it was on the floor and someones foot kicked the button,
led to rebuilds that lasted for days. That was the big site.
A smaller site with Pro/5 had no problems, but it's total data
was about 1/10th of the other.

When it went 'funky' they'd call their support, he'd look at one
file that was many MB long when it should have been 50-100K - and
then start the program to rebuild. The last time that happened
before they went to UW7 - it took 2.5 days to finish the rebuild -
and during that time they had no access to sales order history so
they were constanly having to go to file cabinets. The SO was
about 2GB long and they kept bumping into the 2GB limit so that was
why the move to UW7.

> I know quite a few of the folks here use BBx or Pro/5 on OSR5;
>have you seen file corruption problems on 5.0.7?

What kind of corruption. The above was mostly involving the
indexes and not the actual data files. If anything got killed
instead of being properly exited, things would go crazy until the
files were rebuilt.

--
Bill Vermillion - bv @ wjv . com

In article <Hooo3t.yAI@wjv.com> bv@wjv.com writes:
$In article <HooI79.wt@stevedunn.ca>,
$Stephen M. Dunn <stephen@stevedunn.ca> wrote:
$> (Their previous server ran 5.0.5 or 5.0.6 - I forget which - and
$>was solid until shortly before it was replaced. We never identified
$>the cause of its sudden decrease in stability but we don't believe
$>it was a software issue.)
$
$If it was unstable on the 5.0.5 or 5.0.6 and is unstable on 5.0.7
$why do you rule out software as the issue. Sudden decrease in
$performance [as opposed to gradual] usually has a point of orgin.

It was stable on 5.0.5 or 5.0.6 for a long time, then suddenly
became unstable. I didn't rule out software as the issue; I said
it appeared not to be. The evidence was inconclusive but the
most likely cause appeared to be hardware.

$Replacement of HW or SW based on "it's probalby XXX" are often
$wrong from my observations. Only when you truly identify the
$problem can you make a true recommendation for changing HW, SW or
$both.

Agreed, but sometimes one's marching orders are not of one's
own making. A business can only withstand several hours to a
day of downtime every few days for so long before something must
be done, even if the cause of the problem cannot be positively
identified. That's what led to their decision to replace the
hardware and to upgrade to the latest version of OSR5.

$> I know quite a few of the folks here use BBx or Pro/5 on OSR5;
$>have you seen file corruption problems on 5.0.7?
$
$What kind of corruption. The above was mostly involving the
$indexes and not the actual data files.

The folks who maintain the apps tell me this is what's happening
here, too - it appears that index corruption is taking place, and
the actual data is intact. They can recover their data, but as
some files are close to a gigabyte, it takes a while, even on a
reasonably fast system (Xeon 2.8 or thereabouts, 1 GB RAM,
64-bit 133 MHz RAID card, 6 15k rpm Ultra320 hard drives).
--
Stephen M. Dunn <stephen@stevedunn.ca>
>>>----------------> http://www.stevedunn.ca/ <----------------<<<
------------------------------------------------------------------
Say hi to my cat -- http://www.stevedunn.ca/photos/toby/

In article <Hoopw5.26z@stevedunn.ca>,
Stephen M. Dunn <stephen@stevedunn.ca> wrote:
>In article <Hooo3t.yAI@wjv.com> bv@wjv.com writes:
>$In article <HooI79.wt@stevedunn.ca>,
>$Stephen M. Dunn <stephen@stevedunn.ca> wrote:

>$Replacement of HW or SW based on "it's probalby XXX" are often
>$wrong from my observations. Only when you truly identify the
>$problem can you make a true recommendation for changing HW, SW or
>$both.

> Agreed, but sometimes one's marching orders are not of one's
>own making. A business can only withstand several hours to a
>day of downtime every few days for so long before something must
>be done, even if the cause of the problem cannot be positively
>identified. That's what led to their decision to replace the
>hardware and to upgrade to the latest version of OSR5.

That's why in problem situations I only go in at the close of the
day and work late. Unless of course the system is down.

>$> I know quite a few of the folks here use BBx or Pro/5 on OSR5;
>$>have you seen file corruption problems on 5.0.7?

>$What kind of corruption. The above was mostly involving the
>$indexes and not the actual data files.

> The folks who maintain the apps tell me this is what's happening
>here, too - it appears that index corruption is taking place, and
>the actual data is intact. They can recover their data, but as
>some files are close to a gigabyte, it takes a while, even on a
>reasonably fast system (Xeon 2.8 or thereabouts, 1 GB RAM,
>64-bit 133 MHz RAID card, 6 15k rpm Ultra320 hard drives).

In the situation where the indexes were corrupted, I was there one
day when they called their support person. Really really knows his
stuff. He siad look at xxxx and tell me the size. He said
something along the lines of if it's over 50K then that was the
problem and I think - this is from 3-5 years ago - it was caused
by and ungraceful exit - IOW someone did not log off properly.

Details are hazy. When the UPS battery was weak and a power
interuption came buy, this also occured. I did not care for the
fragile design that caused that but that was the way it worked.

The HW sounds close to the system I was maintaining for awhile -
but with dual Xeons - and only 3 15K drives but not U320.

The SO history - vital to their operation - was close to 2GB - and
it was about a 2 day restore to rebuild that index. I don't recall
what else besides the inadvertant power-off that nuked the indexes,
but there was something that could be caused by a user or the
admin.

Since this started happening near a particular time point see if
you can track down any new users or HW added to the net - a new PC
for example and find out what that user is/was doing.

I wish I could be more helpful as to the cause but I don't even
have the email of the BBX expert. [That's all he did - worked for
one vendor with dozens of systems installed - and later when part
was sold they wanted him to move out-of-state to the regional
support - but he went independant.] And when I say expert back
there I do mean expert. At the time when they hired another
full-time person and took over their own in-house HW/OS maintenance
they were past 120 users with FR to 22 cities. And the index
corruption was the only weak point in the entire system.

Bill

--
Bill Vermillion - bv @ wjv . com