Re: IDS 10.0FCnWm, replication and reversion

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