--- Neil Truby <neil.truby@ardenta.com> wrote:

> My customer is running IDS 10.0FC3 on a production
> system. It's crashed
> twice in the past week due to what turned out to a
> known bug (Bug: 173090
> SERVER CRASH WITH "ASSERT FAILED: YIELD_PROCESSOR:
> CONDITIONAL LATCH COUNT
> NON-ZERO IN THREAD 7" AT 2ND NODE IN A 2-NODE
> REPLICATION SCENARIO).
>
> Anyway, we've been provided with a version,
> 10.0FC3W2, which apparently
> addresses this problem whilst we wait for the pukka
> 10.0FC4 release due in
> January.
>
> Thinking about testing and resilience, do you think
> it's safe to assume that
> a) I can apply this to the secondary in an HDR pair:
> ie replicate from
> 10.0FC3 to 10FC3W2?
> b) If we find something unappetising about 10.0FC3W2
> we can revert simply by
> bouncing the engine and bringing it back up as
> 10.0FC3 again?
>
> I've asked the IBM technician but expect to get back
> the "official" answer,
> which I'd expect to be "No, at least for a).
>
> Thanks
> Neil
>
>

I would assume that upgrading the secondary as you've
suggested would be fine in this scenario, same version
just a different patch level.

I upgraded a couple of our systems, they were not HDR,
to 10.00.FC3X2 from 10.00.FC3 which is the patch
released after W2, AFAIK, and the only issues that we
had revolved around the DB_LOCALE setting, which
happen to be different on ALL of our clients than it
was on any of our database servers. I had to set the
DB_LOCALE in a system environment variable (.Net
connections), setnet32 (DB2 II) and existing ODBC
connections (Everyone else) in order to fix the "new
functionality".
sending to informix-list

"DL Redden" <redden96@yahoo.com> wrote in message
news:dlghli$tgk$1@news.xmission.com...
>
> --- Neil Truby <neil.truby@ardenta.com> wrote:
>
>> My customer is running IDS 10.0FC3 on a production
>> system. It's crashed
>> twice in the past week due to what turned out to a
>> known bug (Bug: 173090
>> SERVER CRASH WITH "ASSERT FAILED: YIELD_PROCESSOR:
>> CONDITIONAL LATCH COUNT
>> NON-ZERO IN THREAD 7" AT 2ND NODE IN A 2-NODE
>> REPLICATION SCENARIO).
>>
>> Anyway, we've been provided with a version,
>> 10.0FC3W2, which apparently
>> addresses this problem whilst we wait for the pukka
>> 10.0FC4 release due in
>> January.
>>
>> Thinking about testing and resilience, do you think
>> it's safe to assume that
>> a) I can apply this to the secondary in an HDR pair:
>> ie replicate from
>> 10.0FC3 to 10FC3W2?
>> b) If we find something unappetising about 10.0FC3W2
>> we can revert simply by
>> bouncing the engine and bringing it back up as
>> 10.0FC3 again?
>>
>> I've asked the IBM technician but expect to get back
>> the "official" answer,
>> which I'd expect to be "No, at least for a).

>>
>>
>
> I would assume that upgrading the secondary as you've
> suggested would be fine in this scenario, same version
> just a different patch level.
>

Got the official IBM answer which, just as expected, is:

"a. It is not advisable to have different versions on primary and secondary
HDR machines. They must be identical even if they are PID Drops.
b. You may be able to bring the secondary up on a different version in
theory but again this is not advised since this may cause a problem with
replication. I would advise installing the same version on both primary and
secondary machines.
I have attached a procedure on how to do this."

The procedure actually expects HDR to re-established via a restore! I'm
*sure* this isn't necessary, but whatever, better do it or we won't get
support if it goes tits up ...