1. Release Notes for 3.6

Note for Beta users

If you have been testing with a beta version of v3.6, and if you are using encrypted extents, these beta-encrypted extents are not compatible with the release executables; there have been root page changes that make the encrypted extents incompatible. You must re-encrypt your beta-test extent dbfs, before these can be used with the 3.6 release executables.

New keyfiles required

The keyfiles for v3.5.x and earlier cannot be used with v3.6; new keyfiles are required for this release. To obtain a new keyfile for GemStone/S v3.6, write to keyfiles@gemtalksystems.com. In your request, include your license information, platform and any updates to contact information.

Please contact GemTalk Technical Support if you have issues or questions.

Platforms for Version 3.6

GemStone/S 64 Bit version 3.6 is supported on the following platforms:

• Red Hat Enterprise Linux Server and CentOS Linux 7.8 and 8.1; and
  Ubuntu 16.04, 18.04, and 20.04
  GemStone performs testing on a mixture of Red Hat and CentOS servers; both are fully certified platforms. Any reference to Red Hat applies to both distributions.
• Solaris 10 and 11.4 on x86
• AIX 7.1 and 7.2
• OS X 10.14.6 (Mojave) with Darwin 18.7.0 kernel, and OSX 10.15.6 (Catalina) with Darwin 19.6.0 kernel, on x86
  (Mac is supported for development only)

For more information and detailed requirements for each supported platforms, please refer to the GemStone/S 64 Bit v3.6 Installation Guide for that platform.

X509-Secured GemStone feature is fully tested and supported on Linux platforms only.

GemBuilder for Smalltalk (GBS) Versions

GemStone/S 64 Bit version 3.6 requires GBS version 8.5 or later for VisualWorks Smalltalk, or version 5.4.6 or later for VA Smalltalk.

The following versions of GBS are supported with GemStone/S 64 Bit version 3.6:

VSD Version

The GemStone/S 64 Bit v3.6 distribution includes VSD version 5.5.1. The previous version of GemStone/S 64 Bit, v3.5.4, included VSD v5.5.

VSD version 5.5.1 includes a number of new features and bug fixes. For details on the changes, see the Release Notes for VSD v5.5.1.

With GemStone/S 64 Bit v3.6, statmonitor now writes additional information to the statmonitor file: the command line used to invoke statmonitor. As a result, statmonitor files from v3.6 cannot be read by versions of VSD earlier than v5.5. VSD 5.5 can read statmonitor files generated in older versions of GemStone/S 64, 32-bit GemStone, and GBS, as well as those generated by GemStone/S 64 Bit v3.6.

VSD 5.5.1 is included with the GemStone distribution, and can also be downloaded as a separate product from https://gemtalksystems.com/vsd/

GemBuilder for Java (GBJ) Version

The most recent version of GBJ, v3.1.3, can be used with GemStone/S 64 Bit v3.6.

The GBJ shared library that is distributed with the server, libgbjgci313*, includes basic support for the new special data types in 3.6 (SmallTime, SmallDate, SmallDateAndTime, SmallScaledDecimal). Further support will be added in the next GBJ release.

GemConnect Version

The most recent version of GemConnect, v2.4, can be used with GemStone/S 64 Bit v3.6.

Upgrade

Upgrade is supported from all 3.3.x, 3.4.x, and 3.5.x versions. To upgrade from earlier versions, upgrade to a supported upgrade origin version, and then upgrade to 3.6.

Note that upgradeImage no longer overwrites the file $upgradeLogDir/upgradeImage.sh. If this file exists, upgradeImage creates $upgradeLogDir/upgradeImage_1.sh, and if this also exists, $upgradeLogDir/upgradeImage_2.sh, and so on.

Documentation Changes

Documentation has been revised for this release, with modifications to incorporate new and changed features, as well as corrections and improvements.

In addition to the maintenance changes, and addition of new information and features, the following improvements have been made:

• A new chapter has been added to the System Administration Guide that is specific to using encrypted extents.
• Materials on Date and Time classes, including the new specials added in v3.6, is added to the Programming Guide numerics chapter.
• The chapters on SymbolLists and ExternalSessions in the Programming Guide, and on Hot Standbys in the System Administration Guide have been extensively revised.
• Using debuggem and topazwaitfordebug to attach to and debug from a separate Gem process is now described in the Topaz User’s Guide.

The GemStone/S 64 Bit X509-Secured GemStone System Administration Guide has not been updated for this release.

Updated library versions

The version of OpenLDAP has been updated to 2.4.55.

The ZoneInfo (TimeZone database) has been updated from 2019a to 2020a.

$GEMSTONE/upgrade packaging

The way GemStone image code is packaged in the distribution for upgrade has been changed, as part of the development towards tonel-based source code management.

This change should be transparent to the user, but the contents of $GEMSTONE/upgrade will appear very different.

A number of Classes whose names begin with Upgrade, are present in the Globals SymbolDictionary. These classes implement methods used during the upgrade process.

Obsolete scripts no longer distributed

The upgradeComments, postconv, and convprep22 scripts are obsolete, and no longer included in the distribution.

AIO Page Server and Free Frame Page Servers no longer separate processes

The AIO Page Server and Free Frame Page Servers are now threads within the stone, rather than separate processes.

The way these are configured and tuned is unchanged; the configuration parameters have not been renamed, to avoid impact during upgrade.

The individual log files previously created by these processes are no longer written; these were seldom useful.

Page server cache statistics, as recorded by statmonitor, reports statistics for these page server threads with only minor changes, as AioThreadN and FFThreadN.

The supporting scripts, runaiopgsvr and runffpgsvr, have been removed.

NetLDI is now multithreaded

The NetLDI is now multithreaded. The number of threads defaults to 10; it can be configured using the startnetldi -t option. With X509-Secured GemStone, in secure mode, or if the NetLDI is running as root, the NetLDI always runs single-threaded.

Default Repository size smaller than keyfile maximum

For limited GemStone licences, one of the limits is the repository size. In previous releases, the default maximum size for a repository was the limit set in a keyfile; however, if the repository ran out of space (for example, a temporary increase due to a commit record backlog), there was no ability to recover, other than an emergency temporary keyfile from GemTalk Technical Support.

Now, when a license keyfile has a limit on the repository size, the default maximum size of the repository is 80% of the keyfile limit. This default is used if no size is explicitly set. If the repository reaches the default limit, it will shut down, but by manually configuring the size to a larger value that is still lower than the licence limit, the system can be restarted easily and the problem resolved.

Changes in transaction logs recorded in milliseconds

The timestamps on records in the transaction logs were previously in seconds, and are now in milliseconds.

Transparent huge pages on linux for Gem temporary object memory

Starting with version 3.5.1, the shared page cache is able to take advantage of transparent huge pages (2MB) pages, provided that this is enabled in the Linux kernel (see the Installation Guide for details). No special configuration in GemStone is needed to use transparent huge pages.

With 3.6, if GEM_TEMPOBJ_CACHE_SIZE is configured to more than 400MB, Gem temporary object memory can also use transparent huge pages. No specific action is required, other than enabling transparent huge pages in the linux kernel.

On restore, data pages automatically compacted

When restoring a backup, formerly, the repository could contain many partially empty data pages. Now, data pages are automatically compacted during restore.

Clustering is respected, and performance appears to be the same or better than without compaction.

FindFreeFrame handling

When a Gem requires new frame, but the shared page cache does not have frames on the free list, it scans the cache looking for a frame that can be made available. It is possible that no frames can be made available. Now, if it does not find a free frame after 60 seconds, the Gem will get a fatal cache error.