--- 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