There is the potential for large objects (collections larger than about
2K in size, or byte objects such as Strings larger than about 8K) to become
corrupted and lose data under the following conditions:
1. The original database used a 32-bit oop format (GS/S 32-bit or GS/64
1.x).
2. During conversion from 32-bit to 64-bit 2.x, the postConv conversion
step was *not* performed.
3. The repository is upgraded to 3.x
The corruption can be seen when object audit reveals errors of the form:
In object [<oopNum>] of class <ClassName> [<oop of class>] the length NN
is invalid
Where the invalid length NN is 8192 or greater.
Note that besides the objects reported in the object audit, other objects
not reported may also be corrupted.
Customers using GS/S 32-bit that are considering migrating to GS/64, must
convert to a target GS/64 version 3.1.0.4 or later, to avoid this issue.
Upgrading to 3.1.0.4 will avoid problems, as will running postconv as part
of previous conversion to 2.x.
If the problem is encountered, contact GemTalk Technical Support for further
assistance in determining the scope of the problem and reconstructing corrupted
data.
Last updated: 6/19/13