GT.M V5.0-000 available

GT.M V5.0-000 is a major release of GT.M. The fact that it has a new top level version number - V5 vs. V4 - means that it has a new database format. There is significant new functionality as well, as described in the GT.M V5.0-000 Release Notes (http://www.sanchez-gtm.com/user_documentation/targets/GTM_V5.0-000_Release_Notes.html).

In GT.M V5, transaction counts are 64-bit unsigned integers, up from 32-bit unsigned integers in GT.M V4. This means that if a large bank with millions of accounts previously needed a mupip integ -tn_reset every 6 months, with V5.0-000, it will still need a transaction number reset, but only every 2 billion years. A database that runs nonstop at 1,000,000 updates per second will now need a TN reset every 585,554 years. [Note that even with a 32-bit transaction count, a typical GT.M installation other than very large banks, may have a transaction reset interval of years to decades. Only the largest GT.M production sites in banking are inconvenienced by 32-bit transaction counts.]

Even though a database format change affects every index and data block in the database, GT.M V5.0-000 comes with an upgrade procedure that operates mostly in parallel with normal application operation. Stand alone access is required typically only for a few seconds. There is also the ability to downgrade from V5.0-000 to V4.4-004, again mostly during normal operation, with a few seconds of stand alone access required.

[Some limitations apply, but they are not believed to be relevant to typical applications deployed on GT.M.] Database upgrades are described in the GT.M Database Migration technical bulletin (http://www.sanchez-gtm.com/user_documentation/targets/GTM_Database_Migration.html). Note that if you are using an application deployed in a logical dual site configuration, the upgrade can be accomplished with continuous application availability.

The most significant enhancements in this release are as follows:

1. As discussed above, transaction counts are increased from 32 bits to 64 bits. In order to facilitate the database upgrade, Fidelity strongly recommends that new database files created with all prior versions of GT.M be created with the Reserved Bytes parameter set to 8 (in Unix) and 9 (in OpenVMS). See the technical bulletin GT.M Database Migration (http://www.sanchez-gtm.com/user_documentation/targets/GTM_Database_Migration.html) for more details.

2. M names can be up to 31 characters long. GT.M allows up to 31 characters for M local and global variable names; M routine names; M source file names; M Label names; M lock names; and database region and segment names. Leading carets (^) continue to not count towards identifier length. Any characters after the first 31 are ignored. See the technical bulletin GT.M Long Names (http://www.sanchez-gtm.com/user_documentation/targets/GTM_Long_Names.html) for details.

3. A new intrinsic function, $INCREMENT(glvn[,expr]), is provided to atomically increment a global variable by a numeric value. Please note that the increment is atomic, but the evaluation of the expression is not, unless inside a transaction (TStart/TCommit). See the GT.M V5.0-000 Release Notes (http://www.sanchez-gtm.com/user_documentation/targets/GTM_V5.0-000_Release_Notes.html) for details.

4. GT.M on UNIX/Linux now recognizes when the $PRINCIPAL device is a TCP socket. Previously such devices were treated as regular files. Network services can now be written in GT.M and deployed under inetd/xinetd. See the GT.M V5.0-000 Release Notes (http://www.sanchez-gtm.com/user_documentation/targets/GTM_V5.0-000_Release_Notes.html) for details.

5. On the secondary of an application deployed in a logical dual site configuration, helper processes can now be used to speed the rate at which updates can be committed to disk. For those environments where the primary is able to commit updates faster than the secondary can, resulting in the build up of a backlog on the primary, helper processes may be able to increase the rate at which the secondary can commit updates. See the technical bulletin GT.M Update Helper Processes (http://www.sanchez-gtm.com/user_documentation/targets/GTM_Update_Helper_Processes.html) for details.

6. There is now an option for a database file to allow existing global variable nodes with null subscripts but to prohibit setting/updating global variables with null subscripts. See the technical bulletin GT.M Null Subscripts (http://www.sanchez-gtm.com/user_documentation/targets/GTM_Null_Subscripts.html) for details.

7. On OpenVMS, upper and lower case labels in M routines can be the target of a call from an external C routine to an M routine. There was previously a restriction requiring upper-case M labels in this context. See the technical bulletin GT.M Long Names (http://www.sanchez-gtm.com/user_documentation/targets/GTM_Long_Names.html) for details.

8. GT.M traditionally collated a null subscript between numeric subscripts and string subscripts. The M standard specifies that null subscripts be collated before numeric subscripts. When a database file is created, it can now be created to use either traditional GT.M collation or M standard collation for null subscripts. See the technical bulletin GT.M Null Subscripts (http://www.sanchez-gtm.com/user_documentation/targets/GTM_Null_Subscripts.html) for details.

In addition to the above enhancements, there are a number of fixes, performance enhancements, and other improvements, as discussed in the GT.M V5.0-000 Release Notes (http://www.sanchez-gtm.com/user_documentation/targets/GTM_V5.0-000_Release_Notes.html).