Copyright © 2005 Fidelity Information Services Inc
Legal Notice
GT.M[tm] is a trademark of Fidelity Information Services, Inc.
GT.M and its documentation are provided pursuant to a license agreement containing restrictions on their use. They are the copyrighted intellectual property of Fidelity Information Services, Inc. and Sanchez Computer Associates, LLC (collectively "Fidelity") and are protected by U.S. copyright law. They may not be copied or distributed in any form or medium, disclosed to third parties, or used in any manner not authorized in said license agreement except with prior written authorization from Fidelity.
This document contains a description of Fidelity products and the operating instructions pertaining to the various functions that comprise the system. It should not be construed as a commitment of Fidelity. Fidelity believes the information in this publication is accurate as of its publication date; such information is subject to change without notice. Fidelity is not responsible for any inadvertent errors.
23 February 2005
|
GT.M Group Fidelity 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.sanchez-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 Alpha/AXP/Tru64 UNIX | 5.1B | - |
| Hewlett-Packard Alpha/AXP Open VMS | 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 Open VMS, be sure to carefully review all the provided kits for that product and apply them appropriately. |
IBM eServer pSeries (formerly RS/6000) AIX | 5.1/5.2/5.3 | - |
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, integrity errors, 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. |
Sun SPARC Solaris | 9.0 | - |
x86 GNU/Linux - Red Hat Enterprise Server Series | 3 | The software should run on any contemporary combination of kernel, glibc and version 5 of ncurses. |
All M sources must be recompiled.
[VMS] 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 [VMS] or shared-libraries [UNIX] created from compiled M sources must be relinked [VMS] or recreated [UNIX] from the recompiled sources.
[VMS] Any existing images created from the compiled call-in (MACRO) tables must be relinked.
The global directory file format has been changed in V5.0-FT01. After installing the software, all existing global directory (.gld) files that were created by V4.x releases must be upgraded to the new format before carrying on with any database activity. The upgrade can be done by setting the environment variable $gtmgbldir (Unix) or gtm$gbldir (VMS) to the old global directory (.gld) file and invoking GDE and using the EXIT command to save the file in the new format.
Before upgrading an existing global directory (.gld) file, ensure that you have a backup copy of the old .gld file. GDE does not provide an option to downgrade a global directory to the V4.x format.
Perform MUPIP UPGRADE (unless upgrading from a V4.4-003 or V4.4-004 release). For upgrades from GT.M V4.x, only the file header is modified. As always, at any given time, a database can be open only by processes of one version of GT.M. However, it is possible to switch back and forth between V5.0-FT01 and earlier V4.x releases unless a V5.0-FT01 database:
has global variables longer than 8 characters, or
has M standard null subscript collation defined and has nodes with null subscripts, or
has NULL_SUBSCRIPTS set to ALLOWEXISTING,
If a database has global variables longer than 8 characters, it is not possible to switch back and forth. To revert, the data will need to be extracted from the V5.0-FT01 database with MUPIP EXTRACT and loaded into a freshly created V4.x database with a MUPIP LOAD.
If a database has M standard subscript collation defined and has nodes with null subscripts, these will need to be Killed before the database is opened with a V4.x version of GT.M; otherwise unpredictable behavior will result, including possibly crashes, hangs and database damage.
If a database has NULL_SUBSCRIPTS set to ALLOWEXISTING, it has to be reset to ALWAYS/YES if there are existing nodes with null subscripts (as there presumably are) or to either ALWAYS/YES or NEVER/No, depending on the pre-upgrade value of the setting, if there are no such nodes.
If using replication and upgrading from V4.2-002 UNIX editions to any later version, recreate the replication instance files as the replication instance file for V4.2-002 is incompatible with subsequent versions.
Due to changes in the journal file format, journal files from older versions are not compatible with V5.0-FT01 and later releases. This means that new journal files will need to be created, which will happen automatically when a database file is opened by a process.
In a dual site configuration running different versions of GT.M on the two systems, when one system is on GT.M version V4.4-002 or higher, the earliest supported version for the other system is GT.M V4.3-000 on UNIX and V4.3-001 on VMS.
It is strongly advisable for the installation procedure to include the creation of a new backup and new journal files with no previous links.
Although the VMS file system (RMS) has a facility for versioning files, GT.M is designed to have only single version of a database file or journal file with a given file specification (excluding the version designator). Fidelity does not test or provide support for multiple versions of these files. Multiple versions of database files or journal files can lead to unpredictable results.
Refer to "Installing GT.M" in the GT.M Administration and Operations Guide (Chapter 2 in the UNIX edition; Chapter 3 in the VMS edition).
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 corruption).
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. In future releases, this question may be removed or modified.
GT.M V4.4-002 and later releases for IBM pSeries AIX now requires 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 next rebooted.
Command Syntax: UNIX syntax (i.e., lowercase text and "-" for flags/qualifiers) is used throughout this document. VMS accepts both lowercase and uppercase text; flags/qualifiers on VMS should be preceded with "/".
Number: The reference numbers used to track software enhancements and customer support requests appear in parentheses ( ).
Identifier: If a new feature or software enhancement does not apply to all platforms, the relevant platform or platforms appear in brackets [ ].
See the Change History for a list of the differences among V5.0-FT01 and V4.4-004.
The most significant enhancement of this release is the support of M names up to 31 characters long from the existing limit of 8 characters. Effective V5.0-FT01, GT.M allows up to 31 characters for the following names:
M Variable names - local and global
M routine names
M source file names
M Label names
M locks - local and global, i.e. with and without preceding caret (^) sign respectively
Database region and segment names (from the existing limit of 16 characters)
Any characters after the first 31 are ignored. All utilities MUPIP, LKE, DSE and GDE are also enhanced accordingly to allow up to 31 character names.
This release also includes the following enhancements.
Support of a new intrinsic function, $INCREMENT(glvn[,expr]), to atomically increment a global variable by a numeric value.
Support of case-sensitive M labels for external routines to call into. On VMS, there is an existing restriction that any calls from external C routines to M must refer to an upper-case M label. Effective V5.0-FT01, this restriction no longer applies and the external routines can refer to mixed-case M labels. The technical bulletin TB5-036 contains the details on enabling this enhancement.
Support of an option for a database to allow reading global variables with existing null subscripts but prohibit setting/updating global variables with null subscripts. The technical bulletin TB5-035 contains the details of the enhancements related to these changes.
Support of standard null subscript collation where the null subscript ("") collates before all other subscripts. By default, GT.M collates the null subscript between numeric and string subscripts (see TB5-035 for details on enabling this option).
In addition to the above enhancements, there are a number of fixes, performance enhancements and minor adjustments.
V5.0-FT01 is a field test version of the forthcoming GT.M V5.0-000, which will include changes to the database file header and block structure (the transaction counter will be increased from the present 32-bits to 64 bits. In order to simplify the database upgrade at the time, Fidelity strongly recommends that new databases files be created with the RESERVED_BYTES parameter set to 8 (in Unix) and 9 (in VMS).
Fixes and enhancements specific only to V5.0-FT01 are:
The environment variable[UNIX] or logical name[VMS] "gtm_gdscert" controls database block certification for all utilities (MUPIP/DSE/LKE etc.) and GT.M. If the environment-variable/logical-name is defined and evaluates to "TRUE" (or part thereof), or "YES" (or part thereof) or a non zero integer, then database block certification is turned ON. For all other cases, it is turned OFF (i.e. the default behavior). To turn ON the block certification, this variable/logical has to be set to any one of the above appropriate values before starting the utility (MUPIP/DSE/LKE etc.) or GT.M. Note that the VIEW "GDSCERT" command achieves similar control without the need for the environment-variable/logical-name but it is available only within GT.M (C9B11-001796).
A new function, $INCREMENT(glvn[,expr]) is now added to GT.M, with semantics as described below (C9D03-002249).
$I, $INCR, $INCREMENT, $ZINCR, and $ZINCREMENT are considered as valid synonyms of the full function name.
If not specified, expr defaults to 1. Otherwise, it is evaluated and coerced to a numeric value. The "expr" argument will be evaluated ahead of the "glvn" argument.
If glvn is undefined, a run-time error will be issued unless VIEW "NOUNDEF" is ON in which case glvn will be treated as having the null string value before the increment. This is true even if glvn is a global variable that resides on a remote note and is accessed through a GT.CM GNP server. glvn will be evaluated and coerced to a numeric value before the increment.
If the function is inside a transaction ($TLevel is non zero), or if glvn refers to a local variable, it is equivalent to SET glvn=glvn+expr.
If the function is not inside a transaction ($TLevel is zero) and glvn refers to a global variable, the function is equivalent to a SET glvn=glvn+expr that is performed as an Atomic, Consistent and Isolated operation. Note that the evaluation of expr is not Atomic, Consistent or Isolated; it is only the actual incrementing of the glvn that is. If the region containing the glvn is journaled, then the operation is also Durable. Only BG, MM (VMS only) and GT.CM GNP access methods are supported for the region containing the global variable (glvn). GT.CM OMI and GT.CM DDP access methods are not supported and there are no plans to support them in future.
$INCREMENT is not supported for global variables that have NOISOLATION turned ON (through the VIEW "NOISOLATION" command). If a $INCREMENT is attempted on such a variable, the run time error GTM-E-GVINCRISOLATION is generated.
The naked reference is affected by the usage of global variables (with or without indirection) in the glvn and/or expr components. The fact that "expr" is evaluated ahead of "glvn" needs to be used to determine the value of the naked reference after the $INCREMENT. If no indirection is used in either glvn or expr, the naked reference after the $INCREMENT will be:
glvn, if glvn is a global or
the last global reference in "expr" if glvn is a local or
unaffected if neither glvn nor expr has any global reference
The value of the glvn after the increment is returned as the value of the function.
GT.M now supports global variable names up to 31 characters long and ignores any characters after the first 31 in a global variable name. See the technical bulletin TB5-036 for details on this enhancement (C9D03-002250).
GT.M provides an option for allowing the global variables to collate the null subscript before all other subscripts. Please see the technical bulletin TB5-035 for enabling this option. By default, GT.M collates the null subscript between numeric and string subscripts. (S9B03-001813).
GT.M provides an option for a database to allow reading an existing global variable with null subscripts but prohibit updating/creating new global variables with null subscripts. Please see the technical bulletin TB5-035 for enabling this option (C9D03-002251).
An issue in the GT.M database logic with the BG (Buffered Global) access method which could in very rare circumstances cause integrity errors and/or false GVUNDEF errors has been fixed. Although this issue could show up with any number of global buffers, the likelihood of this decreases significantly with the number of global buffers typically used (for example 1024 and higher) (C9E07-002610).
M-sets done within a TP transaction, where the destination is a global variable, could in very rare circumstances corrup process private memory which in turn could potentially affect the integrity of the database. This is now fixed. Non-TP sets of global variables are unaffected by this issue. This was reported as having been fixed by C9E03-002537 in GT.M V4.4-004 but the fix was later found to have been incomplete. It is now completely fixed (C9E09-002635).
In very rare cases, a TP transaction that creates a lot of global variables could end up causing integrity errors in the directory tree. This is now fixed (C9E11-002655).
MUPIP REORG on a database that has concurrent GT.M activity (read/update) could in rare cases terminate abnormally. In extremely rare cases, this could end up corrupting the database too. This issue is now fixed. (C9E12-002676).
GT.M now supports M names up to 31 characters long. The features that were restricted to use 8 character names, i.e. local variables, global variables, LOCK resources, routines and labels, now support up to 31 characters. GT.M ignores any characters after the first 31 in a name. See the technical bulletin TB5-036 for details on this enhancement C9D03-002250).
GT.M provides an option for allowing M local and global variables to collate the null subscript before all other subscripts. Please see the technical bulletin TB5-035 for enabling this option. By default, GT.M collates the null subscript between numeric and string subscripts. (S9B03-001813).
When an M file name had more than 8 characters (i.e. longer than the earlier M name limit) , in some cases, ZLINK would fail reporting error messages filled-in with junk characters. This bug is fixed and ZLINK works correctly even if the M file name contains more than 31 characters (i.e. the new M name limit). GT.M truncates the compiled object file names to 31 characters, not including the .o or .OBJ extension (C9E11-002670).
A bug in $TEXT(), that would cause abnormal process termination due to access violation when an indirection argument is used with $TEXT(), has been fixed (S9D12-002412).
A bug in the intrinsic function $REVERSE() which could in very rare cases cause memory corruption or abnormal termination has been fixed. This was an issue only if the argument to $REVERSE() evaluated to a numeric (non-string) expression (C9E04-002559).
In direct mode, a TSTART command that specifies a list of un-subscripted local variable names to be restored on a RESTART works correctly (previous versions would abnormally terminate with this usage). Please note that with GT.M's optimistic concurrency control, TSTART is probably not appropriate anyway in direct mode (S9E10- 002504).
A bug in M Profiling that, in rare circumstances, would terminate the process abnormally or produce corrupted and/or missing information in the global on the VIEW "TRACE", is now fixed. [Solaris] (S9E08-002479).
A rare case of malformed messages being exchanged by GT.CM client and server leading to unexpected disconnects, or abnormal termination has been fixed. The issue could occur only when the size of data or global subscripts were large (approximately 16K or more), and the host running the GT.CM client or server was little endian [UNIX] (C9E04-002561).
The internal consistency checks in DSE INTEG have been improved to detect and report a few cases of previously undetected DBMAXNRSUBS, DBKEYORD, DBINVGBL, DBDIRTSUBSC, DBBDBALLOC errors (C9E04-002574).
The following error messages are newly added in this release. In addition, please see technical bulletins TB5-035 and TB5-036 for more messages.
DBDIRTSUBSC <xxxx Directory tree block contains non name-level entries>
Run Time/DSE Information : This indicates that the specified database block has an internal integrity error since it contains subscripts global variable names even though this block is part of the directory tree.
Action : Report this database structure error to the group responsible for database integrity at your operation.
GVINCRFAIL <Global variable $INCR failed. Failure code: xxxx.>
Run Time Error : This indicates that a $INCREMENT command encountered a database problem when it attempted to update a global variable. xxxx contains the failure codes for the four attempts. It is very likely that the database may have integrity errors or that the process-private data structures are corrupted.
Action : Report this database error to the group responsible for database integrity at your operation.
GVINCRISOLATION <$INCREMENT cannot be performed on global xxxx as it has NOISOLATION turned ON>
Run Time Error : Global xxxx has NOISOLATION turned ON (through a VIEW "NOISOLATION" command). $INCREMENT is currently not supported for such globals.
Action : Change the application either to turn OFF NOISOLATION on the global or not use $INCREMENT on it.
HTEXPFAIL, Hash table expansion failed for lack of memory
Run Time/MUPIP Error : The hash table, an internally expanding data structure maintained by GT.M, has exceeded its maximum capacity. In GT.M, each unique local variable name uses up some hash table space. In MUPIP, it is backward recovery (or rollback) that might encounter this error. Here each TP transaction that is encountered in the backward processing phase of recovery uses up some hash table space. In either case, it is more likely that a process will run out of virtual memory much before it reaches the maximum hashtable capacity.
Action : Increase process memory quotas to increase available process virtual memory. Reduce the number of unique local variable names referenced by the GT.M process. For MUPIP backward recovery/rollback, reduce the number of TP transactions encountered in the backward processing phase by using a later timestamp in the SINCE_TIME qualifier or higher RESYNC_SEQNO for rollback.
MAXTRACEHEIGHT <The maximum trace tree height (xxxx) has been exceeded. The trace information will be incomplete.>
Run time information : The internal GT.M data structure used to gather information during M Profiling can not hold all the information.
Action : Not all lines executed will be reported in the global specified by VIEW "TRACE". There is no impact on the actual execution of the user program. Please report this to GT.M Support with all information necessary to reproduce this error.
STPEXPFAIL Stringpool expansion failed. It could not expand to xxxx bytes,
Run Time Error : The stringpool, an internally expanding data structure maintained by GT.M to store primarily M-local variable content, needs more memory than is available in the process virtual memory.
Action : Increase process memory quotas to increase available process virtual memory. Change application to reduce memory requirements of the stringpool by using lesser M-local variables.