Release Notes : GT.M Version 5.1-000 Mainline Release
Copyright © 2006 Fidelity National Information Services, Inc.
June 14, 2006
| Revision History | |
|---|---|
| Revision 1.0 | 14 June 2006 |
|
GT.M Group Fidelity National Information Services, Inc. 2 West Liberty Boulevard, Suite 300 Malvern, PA 19355, United States of America |
GT.M Support: +1 (610) 578-4226 Switchboard: +1 (610) 296-8877 Fax: +1 (484) 595-5101 http://www.fis-gtm.com gtmsupport@fnf.com |
Table of Contents
As of the publication date, Fidelity supports this release on the following hardware and operating system versions. Contact the company for a current list of supported platforms.
Platform | Supported Versions | Notes |
Hewlett-Packard HP-PA HP-UX | 11i V2 | Running GT.M on HP-UX 11i requires that patch PHKL_28475 be applied to the system. This patch fixes a problem with the lseek64() C library call that GT.M uses. A system without this patch on will give fairly consistent database errors of varying types, structural damage, and in general will not work correctly for any but the most simplistic usage. The "swlist -p" command (as root) can be used to determine if this patch has been applied. Note that recent "BATCH" and "GOLDEN" patches may contain this patch so your system may have this patch applied but may not list it separately. Contact your HP service representative if you have questions. |
Hewlett-Packard Alpha/AXP Tru64 UNIX | 5.1B | - |
Hewlett-Packard Alpha/AXP OpenVMS | 7.3-1/7.3-2 | If you use external calls written in C with Version 6.x of the Compaq C compiler on Alpha OpenVMS, be sure to carefully review all the provided kits for that product and apply them appropriately. |
IBM eServer pSeries AIX | 5.1/5.2/5.3 | - |
Sun SPARC Solaris | 9.0 | - |
x86 GNU/Linux - Red Hat Enterprise Linux | 3, 4 | Although Red Hat Enterprise Linux is the formally supported distribution, the software should run on any contemporary combination of kernel, glibc (version 2.3.2 or later) and ncurses (version 5). |
[UNIX] All M sources must be recompiled.
[OpenVMS] All existing Call-in tables (i.e. MACRO source files) used in the call-in interface must be recompiled using the new macro library gtm$dist:gtmzcall.mlb. If they are not recompiled, GT.M behavior is unpredictable, and can include access violation, hangs and even possibly damage to the database.
Any existing images [OpenVMS] or shared-libraries [UNIX] created from compiled M sources must be relinked [OpenVMS] or recreated [UNIX] from the recompiled sources.
[OpenVMS] Any existing images created from the compiled call-in (MACRO) tables must be relinked.
If upgrading from a GT.M release that is later than V5.0-000 no global directory upgrade is required.
If upgrading from a GT.M version prior to V5.0-000, the V5 global directory format is different from a V4 global directory format, and must be upgraded. If a V4 global directory is opened with the V5 GDE utility program, even if no changes are made, an EXIT command will automatically replace the V4 format global directory file with a V5 format global directory file.
![[Note]](images/note.png) | |
Fidelity strongly recommends that you make a copy of any global directory before upgrading it. There is no way to downgrade a global directory from V5 format to V4 format. |
If you inadvertently open a V4 global directory with a V5 GDE, and do not wish to upgrade it, use the QUIT command rather than the EXIT command.
In the event you inadvertently upgrade a global directory, open it with V5 GDE, execute a SHOW ALL command and manually enter the necessary commands into a V4 GDE invocation.
If upgrading from a GT.M version prior to V5.0-000, a database upgrade is required. Database upgrades are described in the GT.M Database Migration Technical Bulletin. However, if upgrading from a GT.M release that is later than V5.0-000, no database upgrade is necessary.
The global directory in use at the time of database upgrade MUST have a mapping of globals to databases that exactly matches the globals that are actually resident in those databases. Some sites have more than one global directory with some having reduced or changed mappings such that, for example, a database may have more than one global in it but the global directory mapping has only a single global in it. This situation can potentially cause the database upgrade procedure to fail because database certification was not correctly processed. A sign that this could be an issue is if MUPIP REORG UPGRADE or a GT.M process fails with the DYNUPGRDFAIL message (block has insufficient room for expansion) after the V5 upgrade.
Refer to "Installing GT.M" in the GT.M Administration and Operations Guide.
Fidelity strongly recommends installing each version of GT.M in a separate (new) directory, rather than overwriting a previously installed version. If you are overwriting an existing GT.M installation with a new version, you must shut down all processes using the old version.
Any database files that were opened using the old version must be rundown (using MUPIP RUNDOWN) with the old software.
In UNIX editions, make sure gtmsecshr is not running. If found running, perform kill <pid of gtmsecshr>.
If you replace the binary image on disk of any executable file while it is in use by an active process, the results are unpredictable, depending on the operating system. These results include but are not limited to the denial of service (that is, system lockup) and damage to files that are opened by those processes (that is, database structural damage).
In UNIX editions, the configure script for this release will ask the following question:
Enter the RC node ID of the GT.CM server, if desired (42).
Respond by pressing ENTER.
GT.M V4.4-002 and later releases for IBM pSeries AIX require the Asynchronous IO facility to be available and configured. This must be done before installing GT.M. To make sure the facility is available; the following command can be used to display the filesets:
lslpp -l bos.rte.aio
If the filesets are not found, they will need to be installed from AIX installation media.
Use SMIT to configure the Asynchronous IO facility. Enter either:
smit aio (for gui mode) or
smitty aio (for text mode)
Select the "Configure AIO now" selection, which should give a message to the effect that "aio0 has been created". No further setup needs to be done at this time. Note that some systems may have a "posixaio" option instead of "aio", so in the case that the above smit command fails, try with posixaio instead. In addition to configuring the aio0 device, select "Change/Show characteristics of Asynchronous I/O" then change the value of "State to be configured at system restart" from "defined" to "available". This ensures that the aio0 device is available when the system is rebooted next.
If you intend to use database files larger than 2GB, you will need to configure any file system where such a file will reside, when the file system is created, to permit files larger than 2GB.
In OpenVMS, if upgrading from a GT.M version prior to V4.3-001, any customized copy of GTM$DEFAULTS must be updated to include a definition for GTM$ZDATE_FORM.
The following section can be ignored if you choose the standard GT.M configuration or if you answer yes to the following question:
Do you want to define GT.M commands to the system
If you define GT.M commands locally with
SET COMMAND GTM$DIST:GTMCOMMANDS.CLD
in GTMLOGIN.COM or other command file for each process which uses GT.M, you must execute this command after installing the new version of GT.M before using it. If you define the GT.M commands to the system other than during the installation of GT.M, you will need to update the system DCLTABLES with the new GTMCOMMANDS.CLD provided with this version of GT.M. See the OpenVMS "Command Definition, Librarian, and Message Utilities Manual" section on "Adding a system command." In both cases, it is important to match the proper GTMCOMMANDS.CLD with the version of GT.M being used.
GT.M V5.1-000 is a mainline release that includes two notable features, performance enhancements, several fixes and other improvements.
The following is a brief description of the two notable features that are introduced in GT.M V5.1-000:
In prior releases of GT.M, it was not possible to use a database file created in a given endian format directly on a system of the other endian format. To migrate data from an endian platform to one with a different endian format, one had to export data into ASCII format with a MUPIP EXTRACT -FORMAT=ZWR on the source platform and import with a MUPIP LOAD on the target platform. GT.M V5.1-000 provides the ability to perform an in-place endian conversion that simplifies the process of migrating data from one endian platform to another. The Database Endian Conversion Technical Bulletin contains a detailed description of this capability. [UNIX] (C9F06-002728)
GT.M V5.1-000 provides the capability to deploy an application in a logical multi-site configuration where there can be multiple secondary sites to a single primary site. This is an enhancement to the logical dual-site configuration that was available with the previous versions of GT.M that supported deploying a single secondary to the primary site. The Multi Site Replication Technical Bulletin contains a detailed description of this capability. [UNIX] (C9F06-002729)
See the Change History for a description on the items that are fixed in this release.
Fixes and enhancements specific to V5.1-000 are:
In very rare cases, a GT.M process while attempting to obtain a critical section lock on the database could incorrectly error out with a GTMASSERT error message and create a core file, due to coding anomalies. This issue is now fixed. (S9F11-002575)
Certain issues with the database-cache recovery logic could generate huge number of messages to be sent to the syslog and/or result in SIG-11 errors. This also resulted in a cascade of cache recoveries by multiple GT.M processes that terminated abnormally (creating a core file) and failed to recover the cache. These issues with the cache recovery logic are now fixed. (S9G02-002595)
GT.M processes that execute TP transactions with a timeout ($ZMAXTPTIME) could in rare cases not respond to a MUPIP INTRPT and execute a "FOR loop" for a maximum of one iteration, giving unexpected results. This issue is now fixed. GT.M processes no longer get into such a state. They now respond to MUPIP INTRPTs and execute the “FOR loops” correctly. (S9E08-002477)
MUPIP STOP of a running MUPIP BACKUP process now deletes temporary files. In GT.M V5.0-000D, MUPIP STOP of a running MUPIP BACKUP process could potentially result in RMS-E-FLK error messages, indicating that the temporary files created by the backup process were still open by other processes. Versions of GT.M prior to V5.0-000D would simply leave the temporary files on the system without resulting in any error messages. This benign error is now fixed. [OpenVMS] (C9G05-002796)
In prior GT.M versions, running a mupip replic -source -showbacklog command at the same time a source server startup or shutdown command is run could potentially result in a deadlock. This is now fixed. (S9E10-002501)
An issue with the communication between a replication external filter and the source or receiver servers that manifested itself as a hang or FILTERBADCONV error is fixed. (S9G03-002604)
In prior versions of GT.M, a MUPIP STOP on a GT.M process that was in the middle of a database cache recovery would terminate the process right away, resulting in potential database damage. This is now fixed and a GT.M process now waits for the cache recovery to complete before executing the MUPIP STOP. [VMS] (S9G05-002612)
The utility function ^%RSEL() now has an additional entry point SILENT^%RSEL(pattern,label) that provides non-interactive (batch) access to its functionality. The required parameter pattern is a string that specifies the routine names to be searched. The given value would be the input to the interactive ^%RSEL when it prompts for a pattern. "OBJ", "SRC" or "CALL" could be the optional string parameters and the default "SRC" value corresponds to the entryref of ^%RSEL if invoked interactively. (C9G01-002767)
Prior versions of GT.M installation scripts set the default EDITOR environment variable overriding the GT.M user settings. In GT.M V5.1-000, the user installation scripts are suitably modified to retain the user settings. [UNIX] (S9E10-002503)
There are no new error messages that are specific to the V5.1-000 release apart from the ones already detailed in the Multi Site Replication Technical Bulletin and the Database Endian Conversion Technical Bulletin.
For supplementary information on GT.M V5.1-000 Release, refer to GT.M V5.1-000 Supplementary Information Technical Bulletin
Command Syntax: UNIX syntax (i.e., lowercase text and "-" for flags/qualifiers) is used throughout this document. OpenVMS accepts both lowercase and uppercase text; flags/qualifiers on OpenVMS should be preceded with "/".
Reference Number: The reference numbers used to track software enhancements and customer support requests appear in parentheses ( ).
Platform Identifier: If a new feature or software enhancement does not apply to all platforms, the relevant platform or platforms appear in brackets [ ].