Here is the dilemma. HP recommended we disable the enhanced checkpoint code
because it caused a crash. When we questioned the possibility of corrupt
data with the code disabled, this was the response. My interpretation is
that we are in a "no win" situation. Disable the code and we risk corrupted
data in case of system crash. Enable it and we crash the system. The SRs
and Patch IDs are listed below in an email from the HPRC. Bottom line is
limited exposure due to data corruption - resolved by path MPEKXN3 - in beta
as of March 31. Enabling the enhanced checkpoint code actually caused a
crash, so we have it disabled.
Sent: Friday, March 31, 2000 12:30 PM
Subject: XM-related Problems on 6.0
Here are the results of my investigation into XM-related issues. I consider
your system exposed to the following outstanding problems:
1. Multiple occurrences of database corruption after a system abort.
Transactions are not being properly recovered. This problem exists
in 5.0 or later. Patch MPEKXN3 A is general release for 5.5. Patch MPEKXN3
B is in beta test status for 6.0.
2. In internal testing of pre-release 6.5, a window was discovered
where under certain circumstances, a system crash could leave one file with
improperly posted data. This problem was fixed in 6.5. Although this
problem has never been reported on 6.0, it could theoretically occur. Fix
information for 6.0 is the same as for 6.5 but there is not currently a
patch being created. A workaround is to enable the ALTERCHKPTSTAT feature
in 6.0 (however, see #3...). SR JAGac95032, 8606130177, 4701432211 has been
submitted for this problem.
3. System abort 2182 (SA2182) can occur on 6.0 or later with the new XM
feature, ALTERCHKPTSTAT ENABLE. SR JAGad02073, 8606132925 has been
submitted and a patch for 6.0 has been requested.
At this time, you have disabled the ALTERCHKPTSTAT feature, so you are not
exposed to the SA2182. However, this does renew the exposure to the problem
described in #2. Please note that this has not been seen on 6.0 and was
only seen on 6.5 during factory stress-testing so exposure should be
minimal.
-----Original Message-----
From: Steve Cole [mailto:[log in to unmask]]
Sent: Sunday, May 28, 2000 12:32 PM
To: [log in to unmask]
Subject: Re: [HP3000-L] Reminder for ALL MPE/iX 6.0
Users
Not disagreeing with the cause of your system abort or the
advice to disable
the feature, however, we have implemented this feature at
all of the
customer sites that we upgraded to 6.0 and have not had any
problems. We
have the feature implemented on our internal systems without
problems.
Regards,
Steve
=================================
Steve Cole
Outer Banks Solutions, Inc.
[log in to unmask]
www.outerbankssolutions.com
Phone: 919.231.2171 Fax: 919.231.7077
Sales: 800.368.6214
=================================
----- Original Message -----
From: Genute, A Thomas <[log in to unmask]>
To: <[log in to unmask]>
Sent: Sunday, May 28, 2000 9:22 AM
Subject: Re: [HP3000-L] Reminder for ALL MPE/iX 6.0 Users
> We had enabled the checkpoint improvement code on 6.0
after receiving
notice
> on the list in February. Unfortunately, this setting
caused a system
> crash. We were advised by HP to disable this feature
after that
occurred.
>
>
> Tom Genute
>
>
>
> -----Original Message-----
> From: Ken Paul [mailto:[log in to unmask]]
> Sent: Friday, May 26, 2000 7:58 PM
> To: [log in to unmask]
> Subject: [HP3000-L] Reminder for
ALL MPE/iX 6.0
Users
>
> Just a reminder to all of you who are
already on MPE/iX
6.0
> or are thinking
> of upgrading to 6.0.
>
> This doesn't include anyone on 5.5 or 6.5,
only MPE/iX 6.0
> with no PP, PP1
> or PP2.
>
> I sent a message to the list back in late
February about a
> potential problem
> with 6.0 and a possible fix available
within VOLUTIL.
Since
> that time we
> have repaired a lot of IMAGE databases on
6.0 machines
which
> possibly could
> have benefitted from this new VOLUTIL
feature. As the old
> saying goes: "an
> ounce of prevention...."
>
> Here is the important part of my message
from February:
>
> >While attending SigSoftVend last week I
was talking to a
> CSY lab engineer
> >and mentioned these 2 occurrences. He
wondered whether
> both clients were on
> >6.0. Long story short, he believes that
there is a
corner
> case bug within
> >the new XM code for 6.0 which he is now
going to develop
a
> patch. Until
> >that patch becomes available, he
mentioned that users of
> 6.0 could utilize a
> >new feature on 6.0 (and only 6.0) within
the XM which
would
> prevent the
> >problem from happening.
> >
> >In the 6.0 Communicator on page 216 there
is an article
on
> Transaction
> >Manager. On page 219 within the article
there is a
section
> entitled
> >Checkpoint Improvement which describes 2
new commands in
> Volutil for showing
> >and setting this new feature.
> >
> >In checking the last years worth of
messages on 3000-l
> there have been a few
> >references to this option. Mike Hornsby
asked about it in
> February of 1999
> >and Steve Macsisak with HP had a good
description of it
on
> February 19th
> >1999. Carl McNamee mentioned it
favorably back in
November
> of 1999.
> >
> >By default this option is disabled when
you install 6.0
and
> if you enable it
> >for your volume sets then you should not
experience the
> problem mentioned
> >above and you may even see a performance
improvement on
> Checkpoints within
> >the XM. The 2 commands are:
> >
> >showchkptstat <volset-name>
> >
> >alterchkptstat <volset-name>
ENABLE|DISABLE
> >
> >A key paragraph on page 220 then states:
> >
> >"Since this solution remembers the dirty
page ranges in a
> data structure
> >associated with each open file, it can't
affect files
that
> were open before
> >giving this request (ENABLE). However,
it will come into
> effect for the
> >files that were open (for the first time)
after giving
the
> request. So the
> >best way to enable or disable the
Checkpoint Improvement
is
> to reboot the
> >machine after giving the command."
> >
>
> Hope this helps,
>
> +---------------+
> | |
> | r | Ken
> [log in to unmask]
> | e |
> http://www.adager.com
> | g | Ken Paul
Tel 208
> 726-9100
> | a | Customer Support
Fax 208
> 726-2822
> | d | Adager Corporation
> | A | Sun Valley, Idaho
83353-3000
> U.S.A.
> | |
> +---------------+
>
|
