Bug 42317

GemStone/S 64 Bit

3.6.8, 3.6.7, 3.6.6, 3.6.5, 3.6.4, 3.6.3, 3.6.2, 3.6.1, 3.6, 3.5.8, 3.5.7, 3.5.6, 3.5.5, 3.5.4, 3.5.3, 3.5.2, 3.5.1, 3.5, 3.4.5, 3.4.4, 3.4.3, 3.4.2, 3.4.1, 3.4, 3.3.9, 3.3.8, 3.3.7, 3.3.6, 3.3.5, 3.3.4, 3.3.3, 3.3.1, 3.3, 3.2.16, 3.2.15, 3.2.14, 3.2.13, 3.2.12, 3.2.11, 3.2.10, 3.2.9, 3.2.8.1, 3.2.8, 3.2.7, 3.2.6, 3.2.5, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2, 3.1.0.6, 3.1.0.5, 3.1.x, 3.0.1, 3.0, 2.4.8, 2.4.7, 2.4.6, 2.4.5.1, 2.4.5, 2.4.4.8, 2.4.4.7, 2.4.4.6, 2.4.4.5, 2.4.4.4, 2.4.4.3, 2.4.4, 2.2.6.5, 2.2.6, 2.x

All

2.x fileout may version classes in 3.x filein

Fileout of the contents of a SymbolDictionary, using GBS or directly by invoking
   ClassOrganizer >> fileOutClassesAndMethodsInDictionary:on:
creates a fileout that is poorly structured.  When filed in again, this will cause the classes to be versioned, circumventing recent changes that avoid unneccessarily versioning classes.

This is a particular problem when performing file-in as part of a GemStone/S 64 Bit upgrade to 3.0 or later.  If the filein versions the classes, the unconverted classes and methods will remain in the image.

Fileouts created in v3.2 or later are correct, so this bug is fixed in this version; but upgrade from versions that include this bug to v3.2 or later, will still be impacted.

Fileouts of individual classes are not affected.

Workaround

You can recompile methods directly after conversion, rather than filing in code.  Filing out the 2.x code as classes avoids the problem.


                

Last updated: 5/5/14