3. Upgrading from GemStone/S 64 Bit 3.x versions

1. Check for use of deprecated methods

Verify that your application does not invoke any methods that were deprecated in previous releases, by enabling error or logging on deprecation in your existing repository. Deprecated methods are subject to removal in major releases; finding them before upgrading allows the deprecation messages to provide replacement instructions.

For details on finding deprecated methods, refer to the Programming Guide for GemStone/S 64 Bit v3.3.

2. File out your application code

If you do not already have source code for your application stored externally to the GemStone repository in a code management system, it is recommended to file out all application source code. Filein of application code is used to recompile all methods. You may also write code to manually recompile methods in all classes; see Recompile application code for details.

You should confirm that the format of your filed out code does not create new versions of your application classes on filein.

GemStone supports multiple versions of the same class, but tools operate on the most recent version of the classes. If you have instance of older versions of your applications classes that have not been migrated to the latest version, these class versions will not be upgraded by filein. We recommend that you migrate all instances to the most recent version of your application classes.

3. File out modifications to GemStone classes

File out any modifications or additions you made to GemStone/S 64 Bit kernel class methods. For more information about fileout, see the GemStone/S 64 Bit Topaz Programming Environment.

You will need to carefully compare these changes with GemStone/S 64 Bit 3.3.1 kernel methods, and refer to the Release Notes for version 3.3 and all release notes after the version you are upgrading from, to determine whether your changes are still necessary or appropriate. For a listing of Release Notes, see GemStone/S 64 Bit Release History.

CAUTION
Any changes that you have made to the GemStone/S 64 Bit kernel classes will be lost during upgrade; you MUST file these out in order to preserve the changes in version 3.3.1.

1. Install and configure GemStone/S 64 Bit 3.3.1

Install GemStone/S 64 Bit 3.3.1 to a new installation directory, separate from the installation directory for version 3.2.15, as described in Installing GemStone/S 64 Bit Version 3.3.1.

Configure GemStone/S 64 Bit 3.3.1 the way you expect to use it — that is, with the appropriate extent locations and sizes.

If you copy the configuration files from your previous version to the version 3.3.1, be sure to review any changes in configuration parameters to determin if changes are needed. Applications upgrading from v3.2.x will need to set the value for STN_GEM_LIBICU_VERSION, as described in the next section.

You should ensure that adequate space is available for extents, transaction logs, and a backup during the upgrade. You must provide space for the extents and transaction logs for both repositories, the old and the new.

2. If upgrading from v3.2, set STN_GEM_LIBICU_VERSION to legacy version

Repositories that are upgrading from 3.2.x should edit the system.conf file used by the v3.3.1 stone to include the following:

STN_GEM_LIBICU_VERSION = "51.2";

Do not perform this step if you are upgrading from version 3.0.x or 3.1.x.

3. Reset SystemUser password

Log in to the version 3.2.15 system as a user with OtherPassword privilege, such as DataCurator, and reset the SystemUser password to ‘swordfish’:

topaz 1> printit

(AllUsers userWithId: #SystemUser) password: 'swordfish' .

System commitTransaction.

%

The upgrade script logs in with the SystemUser account and the default password, and resets the password for DataCurator and GcUser.

4. Stop user activity

Log in to the version 3.2.15 system as a user with SessionAccess and SystemControl privileges, such as DataCurator, and halt all user activity on the repository.

topaz 1> printit

System stopUserSessions.

%

5. Shut down the repository

You may now shut down the Stone. At the UNIX command line:

% stopstone stone3215

where stone3215 is the name of the version 3.2.15 stone on this machine. The repository must be cleanly shut down to avoid needing recovery when it is restarted with the new version’s executables.

6. Set environment variables for version 3.3.1

Set the environment variables required for the upgrade.

C shell:

% setenv GEMSTONE InstallDir331

% set path = ($GEMSTONE/bin $path)

% setenv upgradeLogDir tempDir 

Bourne or Korn shell:

$ GEMSTONE=InstallDir331

$ export GEMSTONE

$ export PATH=$GEMSTONE/bin:$PATH

$ upgradeLogDir=tempDir

$ export upgradeLogDir

where InstallDir331 is the GemStone/S 64 Bit version 3.3.1 installation and tempDir is a temporary directory for which you have write permission.

NOTE
Use a separate log directory for each repository you convert.

7. Copy extent files

Copy your version 3.2.15 extent files into the location specified by the configuration file option DBF_EXTENT_NAMES:

a. Using a text editor, open the configuration file that the version 3.2.15 repository uses.

b. Locate the last occurrence of the option DBF_EXTENT_NAMES, and note its value, a list of .dbf files.

c. Copy each .dbf file to the noted location in the version 3.3.1 installation. For example:

% cp InstallDir3215/data/extent0.dbf 331location

% cp InstallDir3215/data/extent1.dbf 331location

% cp InstallDir3215/data/extent2.dbf 331location

where 331location is the location specified by DBF_EXTENT_NAMES in the configuration file that will be used in version 3.3.1.

Before upgrading, ensure that there are no transaction logs from a previous version of GemStone/S 64 Bit in any of the transaction log locations specified in the configuration file that will be used by version 3.3.1. Transaction logs from earlier versions are not compatible with version 3.3.1. If the transaction log directories will be reused for version 3.3.1, any transaction logs should be deleted or copied elsewhere.

1. Start the Stone

Start the 3.3.1 Stone on the 3.2.15 extents you just copied:

% startstone stoneName331

2. Upgrade image

Ensure you are in a directory to which you have write permission, and run the upgrade script.

The upgrade is performed by the script upgradeImage. This script has optional switches to specify the stone name and to set to size of the GEM_TEMPOBJ_CACHE_SIZE used for the upgrade process.

upgradeImage [-h] [-c <cacheSize>] [-s <stoneName>]

-h prints this usage information.

-c <cacheSize> sets the size of the GEM_TEMPOBJ_CACHE_SIZE; if this is not

used, the script will default to use a value of 100000. 

-s <stoneName> sets the name of the running stone to upgrade; if this option is

not used, the script will default to gs64stone.

For example,

% upgradeImage -s stoneName331

The script will prompt you to press the return key to begin.

The script invokes subordinate scripts to complete the upgrade. The upgrade process will take some time. You can examine the progress, if desired, by examining the file $GEMSTONE/upgradeImage.out.

The script should complete with the message:

Upgrade completed. No errors detected.

If not, please preserve the Stone log file and the contents of $upgradeLogDir. Contact your internal GemStone support person or GemStone Technical Support.

3. Restore System Account passwords

Log in to GemStone/S 64 Bit version 3.3.1 as DataCurator or SystemUser, and change the password for SystemUser, DataCurator, and GcUser to a secure password, such as the passwords used for these accounts in v3.2.15. For example:

topaz 1> printit

(AllUsers userWithId: 'SystemUser') password: '3215Password'.

(AllUsers userWithId: 'GcUser') password: '3215Password'.

(AllUsers userWithId: 'DataCurator') password: '3215Password'.

System commitTransaction

%

where 3215Password is the account password used in version 3.2.15.

1. Reinstall any other GemStone products that modify kernel classes.

If you use GemConnect or GemBuilder for Java, you must reinstall the appropriate version of these products into your repository at this time.

To install, use the procedure in the Installation Guide for that product.

2. File in Kernel class changes

If you have modified any kernel class methods of the previous version or if you have added methods to kernel classes, compare your changes with the changes in version 3.3.1 to see whether your changes are still necessary or appropriate. Carefully review the Release Notes for each intervening version, as well as examining code in the image.

If the kernel class changes are still applicable, file in the changes, verify that errorcount is 0, and commit.

3. Recompile application code

The upgrade process requires all executable methods to be recompiled. You should have fileins available, from Step 2.. Alternatively, you may iterate classes in your image and recompile each one. If you are reusing scripts that managed recompile for the 2.x conversion, verify that the configuration parameter GemConvertArrayBuilder is not set.

GsDevKit environments will not need to perform this step.

a. Recompile by filein

File in all development and application code. Verify that errorcount is 0, and commit.

If you have instances of previous versions of classes, these old class versions will not be recompiled by this process. You should ensure that all application instances are migrated to current class versions before conversion, or manually recompile instances of older class versions.

b. Recompile within image

To recompile classes without filein, for each class in your repository execute

Class recompileAllMethods

You should ensure that you do not miss any classes. If you have instance of older versions of your classes, you will need to recompile methods on these older versions. For example:

class classHistory do: [:aClassVersion | 

		aClassVersion recompileAllMethods]

Attempting to execute methods that have not been recompiled will result in errors.

4. Recompile source code in persistent blocks

The compiled code in persistent blocks also requires recompile before it can be executed. All persistent executable blocks will need to be recompiled as part of upgrading.

c. Application-specific stored blocks

If your application stores persistent blocks, you will have to locate and recompile all such blocks before they can be executed.

d. SortBlocks in SortedCollections

To recompile the sortBlocks in persistent SortedCollections in your application, you may run the postconv script. This script only converts simple blocks; if your SortedCollection blocks are not simple (such as referring to method context), they cannot be automatically recompiled.

postconv [-c <numCacheWamerGems>][-h][-s <stoneName>] [-r]
[-n <numberOfSessions>] [-t <tempObjCacheSize>] [-u <userId>]

-c <numCacheWamerGems> specifies the number of cache warmer threads in a single gem to load the object table into the shared cache before starting post-conversion. If not specified, no cache warming is done.
-h prints this usage information.
-s <stoneName> sets the name of the running stone to scan; if this option is not used, the script uses gs64stone.
-n <numberOfSessions> specifies the number of parallel sessions which will convert the instances of SortedCollection and its subclasses. By default, use one session.
-r specifies to reuse an existing version of $upgradeLogDir/AllSortedCollections.bms, if it exists. This file contains the OOPs of all instances of SortedCollections and its subclasses. By default, the existing file is deleted and a new one created.
-t <tempObjCacheSize> sets the size of GEM_TEMPOBJ_CACHE_SIZE in KB; by default, 20000.
-u <userId> is the UserId whose SymbolList includes all subclasses of SortedCollection, for which instance’s sortBlocks will be converted. If not specified, defaults to SystemUser

For example,

% postconv -s stoneName331

The postconv script will write progress messages to stdout. When it completes, it will report:

postconv[INFO]: Congratulations! NNN SortedCollections were

successfully converted. No errors were detected.

If postconv reports errors, the results include information on the specific sortBlocks that failed recompile, such as those for complex sort blocks. These will need manual repair. Contact GemTalk Technical Support for assistance.

5. If upgrading from 3.1.x, resort for ICU-based collation

This step is only required if you are upgrading from 3.1.x, which used ICU version 48.1.1 for collation, and only if your 3.1.x application has SortedCollections that include unicode strings, or indexes on unicode strings, or if your application is in Unicode comparison mode.

If this is the case, you must resort all instances of SortedCollection that involve unicode strings (or legacy strings in Unicode Comparison Mode), and drop and rebuild indexes that involve instances of unicode strings (or legacy strings in Unicode Comparison Mode), to ensure these are sorted according the ICU collation now in use in the image.

6. Regenerate cached instances of PetitParser classes

Instance of PetitParser classes (classes with names that begin with PP) are not automatically converted to the new class versions. If you are upgrading from v3.2x and using PetitParser classes directly, and you have persistent instances, you should regenerate these instances.

1. Make backup

At this point, you should create a full backup of the upgraded repository.

2. Configure GBS

If you are using GBS clients, ensure you are running a supported version of GBS and client Smalltalk. You must use GBS version 8.1 or later for VW, or GBS 5.4.3 or later for VA, to connect to a GemStone/S 64 Bit v3.3.1 repository.

Configure GBS to use the version 3.3.1 client libraries. Depending on the GBS version you are upgrading from, the required libraries, library naming conventions, and the process GBS uses to identify the correct library to load may have changed.

See Configuring GBS for GemStone/S 64 Bit for details. If your GBS clients run on a different platform than your GemStone server, refer to the Installation Guide for that platform.