GT.M Version 5.0-000D Release Notes

Release Notes : GT.M Version 5.0-000D Maintenance Release

Legal Notice

May 03, 2006

Revision History
Revision 1.103 May 2006
Revision 1.06 September 2005





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

Bulletin Overview
Platforms
Recompile
Relink
Global Directory Upgrade
Note on Database Upgrade
Installation Instructions
UNIX
OpenVMS
GT.M V5.0-000D Maintenance Release
Previous Releases
GT.M V5.0-000C Maintenance Release
GT.M V5.0-000B Maintenance Release
GT.M V5.0-000 Mainline Release
Change History
V5.0-000D
V5.0-000C
V5.0-000B
V5.0-000
M-Database Access
M-Other Than Database Access
Utilities-MUPIP
Utilities-Other Than MUPIP
Error Messages
V5.0-000D
V5.0-000C
V5.0-000
Supplementary Information
Typographical Conventions

Return to top

Bulletin Overview

Return to top

Platforms

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).

Return to top

Recompile

  • On UNIX, unless upgraded from GT.M V5.0-000B maintenance release, 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.

    [Note]

    This is not applicable on GT.M V5.0-000C, which is a UNIX-only release. However, this is applicable for all other releases of GT.M.

  • [UNIX] GT.M will automatically recompile as required provided $gtmroutines/$ZROutines is set up correctly.

  • 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.

[Note]

The Relink feature on OpenVMS is not applicable for the GT.M V5.0-000C release that is UNIX-only. However, this is applicable for all other releases of GT.M. On UNIX, unless upgraded from V5.0-000B, this feature is applicable.

Return to top

Global Directory Upgrade

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]

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.

Return to top

Note on Database Upgrade

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.

Return to top

Installation Instructions

Refer to "Installing GT.M" in the GT.M Administration and Operations Guide.

UNIX

  1. 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.

  2. Any database files that were opened using the old version must be rundown (using MUPIP RUNDOWN) with the old software.

  3. In UNIX editions, make sure gtmsecshr is not running. If found running, perform kill <pid of gtmsecshr>.

  4. 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).

  5. 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.

Additional Information for AIX

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.

OpenVMS

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.

Return to top

GT.M V5.0-000D Maintenance Release

GT.M V5.0-000D is a maintenance release that includes several fixes, performance enhancements, and other improvements.

The following is a brief description of notable fixes that are in GT.M V5.0-000D:

  • When a backup was (re)started, several fields related to backup error processing were not properly cleared. If an earlier backup failed, it prevented any fresh backups from starting and displayed an error message. This led to "file not found" errors or denial of permissions. The error, introduced in GT.M V5.0-000, has now been fixed. (S9G02-002597)

  • GT.M V5.0-000D has improved error handling capability with respect to writes to the journal file. Even when a journal write error occurred, previous versions of GT.M would treat it as a completed journal write and this would result in gaps in journal files, making the files unusable by MUPIP JOURNAL RECOVER/ROLLBACK. GT.M now keeps retrying each write until it succeeds. In addition, GT.M now prints additional debugging information in the syslog whenever it encounters a journal-file-write-error. (C9D11-002447) (S9F01-002525)

See the Change History for a complete list.

Return to top

Previous Releases

Return to top

GT.M V5.0-000C Maintenance Release

GT.M V5.0-000C is a UNIX-only release for GT.M V5.0-000B maintenance release.

The following is the description of the fixes that went in the GT.M V5.0-000C release:

  • In rare cases, when a GT.M process was interrupted while switching journal files, the process failed to close the older generation journal file despite successfully switching to the latest generation to store journal updates. Even though database integrity and recoverability were never compromised in any way, the process would have multiple generations of journal files open. A side effect of this behavior was that deleting the old journal files would not reclaim the disk space and make it available as long as the process was alive and had the journal file(s) open. GT.M is now fixed to successfully close earlier generation journal files even in the presence of interrupts [UNIX] (S9F10-002571)

  • The READ editing capability that was extended to UNIX in GT.M V5.0-000B introduced a bug that has now been fixed. This bug generated an error status if a READ command was executed while $X was greater than the WIDTH of the terminal and NOWRAP was in effect regardless of whether EDITING had been enabled. This bug is now fixed. The M-Read Edit Technical Bulletin contains a detailed description of this editing capability. [UNIX] (S9F05-002548)

Return to top

GT.M V5.0-000B Maintenance Release

GT.M V5.0-000B is a maintenance release that adds editing capability to the READ statement on UNIX and fixes issues with the dbcertify utility on OpenVMS.

  • The READ editing capability available on OpenVMS has been extended to UNIX in GT.M V5.0-000B. An editing capability similar to that available at the direct mode prompt has been added to the READ statement when reading from the $PRINCIPAL device if that device is a terminal. The M-Read Edit Technical Bulletin contains a detailed description of this editing capability. [UNIX] (S9F05-002548)

  • The dbcertify utility that was a part of the V5.0-000 release would not process databases larger than 2GB, and would fail at the first IO past the 2GB line on OpenVMS. This bug has been fixed in the V5.0-000B release. [OpenVMS] (S9F09-002568)

Return to top

GT.M V5.0-000 Mainline Release

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.

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. Note that if you are using an application deployed in a logical dual site configuration, the upgrade can be accomplished with continuous application availability.

See the Change History for a list of the differences between V5.0-000 and V4.4-004.

The most significant enhancements in this release are as follows:

  1. As discussed above, transaction count 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 on GT.M Database Migration 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 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 C9D03-002249 below.

  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 S9C05-002119 below.

  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 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 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 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 for details.

In addition to the above enhancements, there are a number of fixes, performance enhancements, and other improvements, as discussed below.

Return to top

Change History

Return to top

V5.0-000C

Fixes and enhancements specific to V5.0-000C are:

Return to top

V5.0-000B

Fixes and enhancements specific to V5.0-000B are:

Return to top

M-Database Access

  • As a troubleshooting tool, M programs have been able to programmatically turn on (and off) a check for the structural integrity of database blocks written with the VIEW "GDSCERT" command. This functionality is now enhanced with the addition of a new environment variable [UNIX] or logical name [OpenVMS] gtm_gdscert. If it is defined, and evaluates to a non-zero integer, the string "TRUE", or the string "YES" (or any case independent leading substrings thereof), then block certification is turned on at process startup. Any other value keeps block certification off (default behavior) at process start up. The use of this feature now enables block certification also for the GT.M utilities DSE and MUPIP. It does not apply to LKE, which never modifies database blocks. (C9B11-001796)

  • Prior versions of GT.M would send a GTM-E-JNLACCESS message to the syslog every time a process encountered an out-of-space error while writing to the journal file. GT.M V5.0-000D fixes this syslog flooding by logging only one message for every 100 out-of-space errors while writing to the journal file. (C9B11-001810)

  • 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 for details on this enhancement. (C9D03-002250)

  • 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 for details. (C9D03-002251)

  • GT.M issues an informational TPNOTACID message if it is executing a TP transaction in the final retry and of the following three conditions is encountered:

    1. ZSYSTEM command

    2. Runtime error that transfers control to user-defined $ZTRAP/$ETRAP or

    3. Entering Direct mode

    Previous versions of GT.M inaccurately identified the condition in the TPNOTACID message text and always reported that a ZSYSTEM command was encountered. This has been fixed and GT.M now identifies the correct condition in the message text. (C9D07-002369)

  • GT.M V5.0-000D has improved error handling capability with respect to writes to the journal file. Even when a journal write error occurred, previous versions of GT.M would treat it as a completed journal write and this would result in gaps in journal files, making the files unusable by MUPIP JOURNAL RECOVER/ROLLBACK. GT.M now keeps retrying each write until it succeeds. In addition, GT.M now prints additional debugging information in the syslog whenever it encounters a journal-file-write-error. (C9D11-002447) (S9F01-002525)

  • A new keyword has been added to the VIEW command: VIEW "FLUSH"[:region], which is analogous to the "JNLFLUSH" keyword. Just as "JNLFLUSH" flushes dirty journal buffers, "FLUSH" flushes dirty global buffers from the global buffer cache. If journaling is active, "FLUSH" flushes dirty journal buffers prior to flushing dirty global buffers. If no region is specified, all regions in the current global directory that the GT.M process has opened are flushed. (C9E02-002525)

  • GT.M on the PA-RISC HP-UX platform now uses pread/pwrite calls for database IO rather than the more expensive lseek/read/write calls [HP-UX] (C9E03-002531)

  • 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)

  • An issue in the GT.M database logic with the BG (Buffered Global) access method which in very rare circumstances could cause structural damage 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)

  • An issue in GT.M journaling that in rare cases previously generated benign GTM-E-JNLCNTRL is now fixed. This error occurred around the time a journal file switch happened (explicitly by MUPIP SET JOURNAL or implicitly by an autoswitch). [UNIX] (C9E08-002618) (S9F11-002574)

  • M-sets done within a TP transaction, where the destination is a global variable, in very rare circumstances could corrupt 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)

  • With alternative collation type > 0, $next() now returns the correct string if the input subscript is numeric type and the output subscript is string. (C9E12-002674)

  • MUPIP REORG on a database that has concurrent GT.M activity (read/update) in rare cases could terminate abnormally. In extremely rare cases, this could structurally damage the database too. This issue is now fixed. (C9E12-002676)

  • GT.M allows TP transactions to be nested i.e. TSTART can be specified within a transaction to start a sub-transaction. The nested TP transaction can be rolled back or committed using TROLLBACK or TCOMMIT. KILL of globals in such nested TP transactions previously could in very rare instances cause database damage. This is now fixed. (C9E12-002698)

  • A bug that has never been reported at a production site, but which can in theory occur because it was detected during internal stress testing by Fidelity, has been fixed. Under certain very unlikely conditions, a database block in principle could be written to the wrong database, and the only recovery would be to restore a backup and perform a mupip forward recovery. Users of GT.M versions V43001F, V44003, V44003A and V44004 are therefore advised to upgrade to V5.0-000 as soon as practicable. [OpsenVMS] (C9F05-002726)

  • Every journal record in the journal file has a checksum field. With before-image journaling, it was possible in very rare cases that GT.M would write a before-image journal record with an incorrect checksum value. This would cause MUPIP RECOVER/ROLLBACK to issue a "Checksum validation failed" error. GT.M is now fixed to write the correct checksum. (C9F10-002762)

  • The JNLFSYNCLSTCK message now prints the associated journal file name. [UNIX] (C9G04-002780)

  • 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 for details. (S9B03-001813)

  • GT.M now handles ZTP transactions (ZTSTART and ZTCOMMIT) correctly when journaling is turned on. Previously, it was possible for GT.M to issue GVGETFAIL or other database errors for a global reference following ZTCOMMIT when such a global belonged to a region other than the region last accessed within the ZTP transaction. (S9E08-002484)

  • GT.M is designed to repair and recover from certain classes of damage to the shared memory control structures used to manage database global buffers. This recovery has been speeded up - there were previously cases when it could take many tens of minutes - and should now take no longer than four minutes. (S9E12-002516)

  • The TPRESTART message in the syslog now additionally displays the name of the region where the transaction restarted. (S9F02-002529)

  • In before image journaled databases, an EPOCH is periodically written to record a checkpoint for future recovery. As a part of this, all updates to the database are hardened to disk. If GT.M encounters an error during this hardening, it issues a GTM-E-DBFSYNCERR error. Previous versions of GT.M did not release the lock on the journal file before issuing this error. This could result in a deadlock and cause application hangs. GT.M now releases the lock before issuing the DBFSYNCERR error. (S9F07-002560)

  • In prior versions of GT.M on UNIX, when a process switched the journal file of a database region to a new file, the other processes kept the previous generation journal file open until they updated that region. Even though there was no impact on robustness or recoverability, this meant that older generation journal files were potentially kept open for an indefinite amount of time in spite of having switched the journal file one or more times. To mitigate this situation, GT.M now checks for open older generation journal files approximately every 8 seconds and closes them right away instead of awaiting the next update. GT.M on OpenVMS is immune to this issue as it closes the older generation journal file at the time of the journal switch instead of waiting for the next update. [UNIX] (S9F07-002561)

  • On HP-UX, a large number of system calls were made to ascertain the status of existing processes when a database was being closed. On some systems, the number of these system calls created a bottleneck resulting in hung processes, sometimes for many hours. GTM is now fixed to avoid this system call bottleneck. [HP-UX] (S9G01-002593)

  • With GT.M replication, GT.M processes are supposed to update replicated databases coresponding to the replication instance they were started with only. Although updating a replicated database that is not part of the current replication instance (e.g. using an extended reference) is a not permitted, this condition was not detected and reported in previous GT.M versions, potentially resulting in missing journal sequence numbers in the current replication instance. This would then cause the source server to issue a REPLBRKNTRANS error and the only way to recover from this situation would be to restore the secondary from a backup of the primary. GT.M now detects such out-of-instance updates and issues a REPLINSTMISMTCH error thereby disallowing such updates. (S9G03-002599)

  • GT.M issues a SYSTEM-W-NOTVOLSET error while opening a journal file that is assigned a OpenVMS file id with a file-sequence-number (the second of the three numbers reported by a DIR/FULL command) that is greater than or equal to 32K, due to an issue with the OpenVMS C compiler that generated incorrect machine code when used with optimization flags. This issue was fixed in later releases of the compiler. The current version of GT.M is built with an upto date compiler that fixes this issue. [OpenVMS] (S9G03-002601)

  • VIEW "JNLFLUSH" not only writes the journal buffers to disk but also hardens the writes to the journal file on disk, thereby ensuring that all updates until that point are recoverable in case of a system crash. This is only applicable to GT.M on UNIX as writes on OpenVMS are automatically hardened. Note that with the use of transaction processing, except for transactions flagged as “batch” transactions, a TCommit command (or the outermost TCommit command, in the event of nested transactions) always flushes journal buffers and hardens them on disk. [Unix] (S9G03-002610)

Return to top

M-Other Than Database Access

  • GT.M source code was modified to use ANSI C stdargs.h style of variable argument list parameter passing instead of the earlier K&R C varargs.h style. This change has enabled the use of optimizer flags with GCC C compiler thus improving CPU performance of GT.M applications on the x86 GNU/Linux platform. The change is internal to GT.M and has no functional or operational impact. [x86 GNU/Linux] (C9907-001201)

  • 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). (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 the value of glvn is undefined, it will be treated as having the null string value before the increment, i.e. an implicit $GET() before the increment. This is true even if glvn is a global variable that resides on a remote node 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 (OpenVMS 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.

  • In certain situations, when journaling is ON during the database file extension, GT.M would cause a process to hang within a self inflicted-deadlock waiting for an OpenVMS system trap (AST) after the process previously disabled AST. This bug is now fixed. [OpenVMS] (C9E04-002557)

  • A bug in the intrinsic function $REVERSE() which in very rare cases could 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)

  • GT.M previously displayed certain control characters incorrectly in ZWRite output when the decimal representation of character's collating value contained a non-zero digit in the 100s position and zero in the 10s position. The problem only occurred when the standard PATCODE C was redefined with an alternative pattern table. This is now fixed. (C9E07-002609)

  • Logging interval (in count of transactions) is now configurable for all replication servers - source, receiver and update process. The source server -START, -ACTIVATE, -DEACTIVATE, and -CHANGELOG commands accept an optional qualifier -LOG_INTERVAL=n where n is a positive number. Source server prints a message in the server log after sending every n transactions. If -LOG_INTERVAL is not specified with -START or specified as 0, the logging interval is set to its default value 1000. If -LOG_INTERVAL is not specified or specified as 0 with -CHANGELOG or -ACTIVATE or -DEACTIVATE, the logging interval is left unchanged. The receiver server START (except when -UPDATEONLY is specified) and CHANGELOG commands accept an optional qualifier -LOG_INTERVAL=[m][,n] where n and m are numbers. The receiver server prints a message in the receiver log after receiving every m transactions. The update process server prints a message in the update log after processing every n transactions. If -LOG_INTERVAL is not specified with -START, the logging interval for both receiver and update process is set to the default 1000. If -LOG_INTERVAL is specified with -START, and either interval (m or n) is not specified or specified as 0, the default value of 1000 is used for the corresponding server. If -LOG_INTERVAL is not specified with -CHANGELOG, the logging interval of receiver and update process are left unchanged. The same holds when -LOG_INTERVAL is specified, but the corresponding server's interval is specified as 0, or not specified (m is specified but not n, or vice versa). To change the receiver's logging interval alone, you can specify -LOG_INTERVAL=m (or -LOG_INTERVAL=m,0). To change the logging interval of update process alone, you can specify -LOG_INTERVAL=,n (or -LOG_INTERVAL=0,n). Note: The source server optimizes communication with receiver by bunching multiple transactions into a single send operation. This may mean that more than LOG_INTERVAL transactions may be sent before the source server logs a message. This may also mean that source server messages are not always spaced at LOG_INTERVAL transactions. LOG_INTERVAL specification for source server must be considered as advisory - there is no guarantee that the interval specification will be strictly followed. Special note for OpenVMS: The receiver server -LOG_INTERVAL specification must be quoted. That is, /LOG_INTERVAL="m,n" form must be used. (C9E09-002633)

  • 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 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, excluding the .o or .OBJ extension. (C9E11-002670)

  • GT.M on UNIX/Linux now recognizes when the $PRINCIPAL device is a TCP/IP socket. Previously such devices were treated as regular files. This feature is designed to allow a GT.M process to be started in response to a connection request made via inetd/xinetd. [UNIX] (S9C05-002119)

    When using xinetd, socket_type should be "stream" and wait should be "no" as in the example below:

     service gtmserver
        {
    	disable		= no
    	type		= UNLISTED
    	port		= 7777
    	socket_type	= stream
    	wait		= no
    	user		= gtmuser
    	server		= /path/to/startgtm
        }
                                                        
                                                        
                                                        

    If the service is defined in /etc/services, the type and port options are not needed. See the xinetd.conf man page for more details.

    When using inetd, the sockettype should be "stream", protocol "tcp", and the "nowait" flag should be specified as in the example below, which assumes a gtmserver service is defined in /etc/services:

        gtmserver stream tcp nowait gtmuser /path/to/startgtm
                                                       

    In both of the above examples, "gtmserver" is the arbitrary name for the service being defined, "gtmuser" is the name of the user the service should be run as, and "/path/to/startgtm" is the name of a script which defines some environment variables needed by GT.M before starting it.

    The minimum variables are $gtm_dist which should specify the directory containing the GT.M distribution and $gtmroutines. As an example:

        #!/bin/bash
        cd /path/to/workarea
        export gtm_dist=/usr/local/gtm
        export gtmroutines="/var/myApp/o(/var/myApp/r) $gtm_dist"
        export gtmgbldir=/var/myApp/g/mumps.dat
        $gtm_dist/mumps -r start^server
                                                       
                                                       

    When start^server begins, the $PRINCIPAL device will already be connected and $KEY will contain "ESTABLISHED|socket_handle|remote_ip_address". In most cases, a USE should be executed to set various device parameters such as delimiters.

    ZSHOW "D" will provide both the local and remote addresses and ports:

                                                       
    
      0 OPEN SOCKET TOTAL=1 CURRENT=0
              SOCKET[0]=h11135182870 DESC=0 CONNECTED ACTIVE  NOTRAP
    REMOTE=10.1.2.3@53731 LOCAL=10.2.3.4@7777
    	                ZDELAY  ZBFSIZE=1024 ZIBFSIZE=0
                                                       

    Currently this feature is not available on OpenVMS.

  • 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)

  • Heavy usage of routine calls passing indirect argument(s) by reference [e.g. do label(.@arg)], or for loops using indirect index variable [e.g. for @index=1:10] in a long running M process used to cause abnormal termination. This has now been fixed. (S9E04-002439)

  • Changes introduced in V4.4-004 for long records in RMS files as part of TR S9D06-002345 had an undesirable side effect of not allowing access to NFS mounted files. This has been fixed. [OpenVMS] (S9E06-002470)

  • 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)

  • When there is a situation where GT.M fails to write to a journal file (say, due to lack of disk space or other disk I/O problem) for a region that is replicated, GT.M now turns OFF both journaling and replication issuing a REPLJNLCLOSED error in the operator log. The only way to turn replication back ON is by bringing down the instance as the transition from replication off to replication on needs standalone access. However, GT.M would previously permit a user to turn journaling ON while keeping the replication state OFF. In a replicated environment, this state is an out-of-design situation that would cause GT.M processes to terminate with cascading GTMASSERT errors. (S9E08-002485)

    Effective V5.0-000, GT.M provides the means to:-

    • Prevent the out-of-design situation (i.e. journaling ON and replication OFF) so that GT.M processes will no longer terminate with GTMASSERT error. After replication (as well as journaling) is closed following a journal file I/O error, both MUPIP SET -JOURNAL and MUPIP BACKUP -NEWJNL will not allow switching journal state back ON without also turning replication ON. Both commands will fail issuing REPLJNLCNFLCT message.

    • Support the option to turn replication back ON without bringing down the replication instance. Both MUPIP SET and MUPIP BACKUP commands will allow turning replication (as well as journaling) back ON without requiring standalone access.

    In order to support these features, GT.M internally maintains an additional replication state, called WAS_ON, which is also reflected in the file header, to indicate that replication was ON but currently turned OFF due to journal file I/O problems. The following are the commands with new behavior when the replication state is WAS_ON:

    • MUPIP SET -JOURNAL=ON or MUPIP -BACKUP -NEWJNL: Both commands will fail with REPLJNLCNFLCT message. GT.M no longer allows journaling ON without an accompanying REPLICATION qualifier.

    • MUPIP SET -REPLICATION=ON or MUPIP BACKUP -REPLICATION=ON: Both commands will turn replication (as well as journaling) ON on regions specified. These commands no longer need standalone access. They can be run concurrently with other database activity. However, the user must realize that although replication is restored and the source servers pick up transactions of the newly restored regions, the two sites are NOT in sync until the primary's backup is restored to secondary. The backup used must be one that is taken subsequent to the restoration of replication state.

    These commands also switch the journal files implicitly cutting previous journal links of those regions for which replication state is restored from WAS_ON to ON. No previous journal files of those regions can be used for rollback.

    DSE DUMP displays the new replication state WAS_ON in the file header as shown below:

    DSE > dump -f

    File            /xyz/mumps.dat
    Region          DEFAULT
    Date/Time       31-MAY-2005 15:34:48 [$H = 60051,56088]
      Access method                          BG  Global Buffers                1024
      Reserved Bytes                          0  Block size (in bytes)         1024
      Maximum record size                   256  Starting VBN                   129
      Maximum key size                       64  Total blocks            0x00000065
      Null subscripts                     NEVER  Free blocks             0x00000062
      Standard Null Collation             FALSE  Free space              0x00006000
      Last Record Backup     0x0000000000000001  Extension Count                100
      Last Database Backup   0x0000000000000001  Number of local maps             1
      Last Bytestream Backup 0x0000000000000001  Lock space              0x00000028
      In critical section            0x00000000  Timers pending                   0
      Cache freeze id                0x00000000  Flush timer            00:00:01:00
      Freeze match                   0x00000000  Flush trigger                  960
      Current transaction    0x0000000000000001  No. of writes/flush              7
      Maximum TN             0xFFFFFFFFDFFFFFFF  Certified for Upgrade to        V5
      Maximum TN Warn        0xFFFFFFFF5FFFFFFF  Desired DB Format               V5
      Master Bitmap Size                     64  Blocks to Upgrade       0x00000000
      Create in progress                  FALSE  Modified cache blocks            0
      Reference count                         1  Wait Disk                        0
      Journal State                         OFF  Journal Before imaging        TRUE
      Journal Allocation                    100  Journal Extension              100
      Journal Buffer Size                   128  Journal Alignsize              128
      Journal AutoSwitchLimit           8388600  Journal Epoch Interval          30
      Journal Yield Limit                     8  Journal Sync IO              FALSE
      Journal File: /xyz/mumps.mjl
      Mutex Hard Spin Count                 128  Mutex Sleep Spin Count         128
      Mutex Spin Sleep Time                2048  KILLs in progress                0
      Replication State            [WAS_ON] OFF  Region Seqno    0x0000000000000001
      Resync Seqno           0x0000000000000001  Resync trans    0x0000000000000001
                                                            
  • The update process is fixed to generate a process dump for memory-exhausted errors GTM-E-MEMORY [UNIX] and GTM-E-VMSMEMORY [OpenVMS]. These error messages are also modified to display the caller information to help identify the error location for debugging purposes. (S9E09-002496)

  • 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 not appropriate anyway in direct mode. (S9E10-002504)

  • When an M stack overflow occurs, GT.M on both UNIX and OpenVMS tries to prevent a core/dump file from being created as an M stack overflow is indicative of an application software bug rather than a GT.M bug. However, on OpenVMS, under certain conditions, doing a quiet non-dump exit after a stack overflow requires unwinding a stack, which may have become malformed during the unwind. In such a case, various GTMASSERTs or even ACCVIOs are possible. To mitigate this issue, GT.M on OpenVMS platform is being changed so that it will generate a dump (if set proc/dump is enabled) on an M stack overflow. This is not a GT.M system error but is the only way the process can be terminated without spurious other errors. [OpenVMS] (S9F10-002569)

  • GT.M used to incorrectly evaluate certain hard-to-characterize pattern match expressions that contain alternations. These are now fixed. (S9F11-002577)

  • Previous versions of GT.M did not correctly save and restore $REFERENCE over the execution of $ZINTERRUPT code if the latter used extended references. This could cause inexplicable changes in $REFERENCE should code be interrupted (by MUPIP INTRPT) in the wrong place. This is now fixed. (S9F12-002580)

  • When a GT.M process on OpenVMS runs short of storage while allocating string descriptors for an external C call, it used to GTMASSERT. This is now changed to give a VMSMEMORY2 error. Three new ntrinsic Special Variables namely, $ZALLOCSTOR, $ZREALSTOR, and $ZUSEDSTOR are added (in both UNIX and OpenVMS) are now included in ZSHOW reports to help identify storage related problems. The $ZREALSTOR value is the total real (process) storage allocated by GT.M that may or may not actually be in use. The $ZALLOCSTOR value is the storage that is (sub) allocated (including overhead) by GTM to various callers. The $ZUSEDSTOR value is the value in $ZALLOCSTOR minus the overhead and represents the actual amount of storage that was requested. (S9G01-002585)

  • In previous versions of GT.M on UNIX, the file descriptor used for /dev/null was not released on Close. This caused a leak, and a process repeatedly performing Open, Write, and Close on /dev/null could eventually cause file descriptors to be exhausted or it's quota of file descriptors to be consumed. This bug is fixed. [UNIX] (S9G03-002600)

Return to top

Utilities-MUPIP

  • MUPIP JOURNAL -RECOVER/-ROLLBACK, that could previously fail with HTOFLOW error due to overflow of internal hash tables, now works correctly with no errors. GT.M no longer limits the growth of the hash tables that are used internally as long as adequate system memory resources are available. (C9D06-002288)

  • MUPIP upgrade now properly checks for standalone access to upgrade a database and will not "re-upgrade" an already upgraded database. (C9D10-002441)

  • A bug, that would cause MUPIP BACKUP -BYTESTREAM command on multiple regions without SINCE or TRANSACTION qualifiers to backup incorrect transactions, is now fixed. (C9E08-002621)

  • When too many global variables were specified in the EXCLUDE qualifier with MUPIP REORG, prior GT.M versions would terminate prematurely with a MUREORGFAIL error. This is now fixed. (C9E11-002665)

  • An online backup of a database with NOBEFORE-IMAGE journaling and which is being updated concurrently by TP transactions in very rare cases could have structural damage. This issue affected only the backup database, not the actual database. This is now fixed. (C9F03-002713)

  • On the HP Alpha/AXP Tru64 UNIX platform, a MUPIP RESTORE could in rare cases result in a damaged database due to one or more bitmap blocks not being properly restored. This resulted from an issue in the Tru64 C compiler, which generated incorrect machine code with certain optimization flags. As a workaround pending a fix to the compiler, the GT.M C source code has been reordered to ensure that proper machine code is generated. [Tru64 UNIX] (C9F08-002750)

  • While restoring from the TCP sockets, MUPIP RESTORE would report a SIG-11 (segmentation violation) if it encountered any errors when reading from the TCP stream. This is now fixed to issue a more appropriate error and terminate gracefully. (C9G04-002781)

  • MUPIP JOURNAL -RECOVER/-ROLLBACK is now much more robust in recovering (backward recovery) from before-image journal files that were actively being updated during a system crash. There are two aspects to this. One is that each journal record has a new checksum field which helps better differentiate valid versus invalid journal records in the tail of the journal file. Another is that backward recovery/rollback now knows to handle journal files that have a sequence of invalid journal data followed by valid journal data on disk (this is possible in some cases of a system crash). In earlier versions, backward recovery/rollback on such journal files would error out prematurely. (S9E04-002440)

  • MUPIP JOURNAL -ROLLBACK -FETCH_RESYNC could fail incorrectly with a GTMASSERT message in case one or more regions had no updates after the source server was started and before it was shutdown. This is now fixed. (S9E04-002447)

  • Restarting the source server no longer keeps journal files open when such files do not need to be read for replication. (S9E05-002460)

  • Source server reports "GTM-E-NOPREVLINK, Journal file <file-name> has a null previous link" if it detects a null previous link in a journal file that it reads. Previously, an error of the form "GTM-E-JNLFILOPN, Error opening journal file for database file <region-name>, %SYSTEM-E-UNKNOWN, Unknown system error 0" would have been issued. (S9E06-002468)

  • MUPIP SET -JOURNAL on multiple regions that had concurrent GT.M activity could, in rare cases, cause deadlocks. This bug is now fixed. (S9E09-002490)

  • The source server has two modes of operation, reading from the journal pool (pool-read) and reading from the journal files (file-read). If there is little or no backlog, then the source server reads journal records from the pool. Whenever the backlog builds up more than the pool can hold, the source server switches to reading from the files and similarly switches to reading from the pool if the backlog reduces to what the journal pool can hold. When the source server transitions from file-read to pool-read mode and it has multiple journal files (including earlier generations) open for one or more regions, it used to fail to close the oldest generation journal file of those regions. With every such transition from file-read to pool-read mode, the number of un-closed (and hence open) files used to keep increasing until the maximum-open-files limit for the process was reached. At that point, the source server used to exit with a "Too many open files" error. The source server now correctly closes the oldest generation journal file thereby avoiding this open file buildup. (S9E09-002493)

  • 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 technical bulletin GT.M Helper Processes for details.(S9E10-002497)

  • The MUPIP SET -FLUSH=xx command that is used to set the number of buffers being flushed at each IO flush is no longer ignored nor does it require standalone access, as it did before. (S9F11-002578)

  • In rare cases, MUPIP LOAD when used with a fillfactor that is less than 100% used to issue a GVPUTFAIL error with the failure code HHHH even though the record it tried to load was valid. This issue is now fixed. (S9G01-002587)

  • The maximum lockspace size is increased in both GDE and MUPIP SET from 1000 to 65536 blocks of 512 bytes each. (S9G01-002589)

  • GT.M V5.0-000D fixes several issues with MUPIP LOAD when used with the BEGIN or END qualifiers. (S9G01-002592)

    1. Previously, the maximum number of records (GO and ZWR format) or blocks (binary format) that MUPIP LOAD could handle were 999,999,999. Large databases exceed this value especially with the GO and ZWR formats. The maximum number of records/blocks that MUPIP LOAD can handle is now increased to 4,294,967,295.

    2. Previously, if MUPIP LOAD did not load any records due to errors while loading, it reported a non-zero value for the "Last LOAD record number". It now reports this as a zero value.

    3. BINARY extract format has ONE header record followed by the data records while ZWR and GO format have TWO header records followed by the data records. If MUPIP LOAD specifies a BEGIN qualifier that is less than or equal to the number of header records for the corresponding extract format, BEGIN is automatically adjusted to start at the first data record for that format.

    4. If MUPIP LOAD encounters an error while loading a particular record, it now prints the record number where the error occurred before moving on to load the next record.

    5. MUPIP LOAD now prints a "Beginning LOAD at record number" message with the record number from which it starts loading.

    6. On OpenVMS, MUPIP LOAD when used with a ZWR or GO extract file and with the BEGIN and/or END qualifiers did not load the specified range of records but instead loaded a different range. This is now fixed.

    7. On Unix, MUPIP LOAD when used with a BINARY extract file and with BEGIN and/or END qualifiers used to report incorrect values for "Last LOAD record number" as well as "Key Cnt:" in the reported "LOAD TOTAL" summary. This is now fixed.

  • When a backup was (re)started, several fields related to backup error processing were not properly cleared. If an earlier backup failed, it prevented any fresh backups from starting and displayed an error message. This led to "file not found" errors or denial of permissions. The error, introduced in GT.M V5.0-000, has now been fixed. (S9G02-002597)

  • All database updates during a MUPIP BACKUP ONLINE operation are logged into a temporary file that is used by MUPIP BACKUP after creation of a database copy. The temporary file size could increase to more than 2 GB depending on the duration of the copy creation and the update activities. In such cases, MUPIP BACKUP previously issued an EOVERFLOW error when it tried to read from an offset greater than 2 GB. This error has been fixed in GT.M V5.0-000D and MUPIP BACKUP can now handle temporary files of arbitrary size. (S9G03-002608)

Return to top

Utilities-Other Than MUPIP

  • GT.CM OMI server's PID is written into log file. [Solaris] (C9C04-001967)

  • The internal consistency checks in DSE INTEG have been improved to detect and report a few cases of previously undetected DBMAXNRSUBS, DBKEYORD, DBINVGBL, DBDIRTSUBSC, and DBBDBALLOC errors. (C9E04-002574)

  • LKE SHOW -ALL -WAIT, now displays correct values of process-ids that are waiting for all LOCKs to be granted. A bug where incorrect values were sometimes displayed has been fixed. (C9E07-002607)

  • DSE CACHE/CHANGE command on OpenVMS now works on all valid locations in database shared memory. Previously it would work only for a small portion of shared memory. [Alpha/AXP OpenVMS] (C9G03-002776)

  • Network conditions when performing a network IO operation can result in an hang of GT.CM OMI server. There is now a -servtime command line parameter (default value 60). If a network IO operation does not complete within the number of seconds specified by the -servtime parameter, the GT.CM OMI server process will go through an internal recovery procedure to clear the "hang". [Solaris] (S9C11-002246)

  • The startup script of GT.CM OMI server has been modified to check the existence of running other GT.CM OMI servers, which eliminates the possibility of "Address already in use" error. [Solaris] (S9D06-002330)

  • GT.CM OMI servers no longer dump core in the case of errors that need to be logged in syslog. [Solaris] (C9B11-001829) (S9E11-002509) (S9E04-002453)

  • The DSE add -star command no longer terminates abnormally with a SIGADRALN error on Solaris, SIG-10 on HP-UX or unaligned access errors on Tru64 UNIX if the STAR key is added the end of an index block whose bytes in use field (before the add -star command) is not a multiple of 4. [Solaris/HPUX/Tru64] (S9E12-002512)

  • GDE previously incorrectly disabled the STDNULLCOLL parameter for the TEMPLATE region, while reading from a global directory (.gld) file. Even when STDNULLCOLL was enabled in a previous session, saving and reloading the file in a subsequent session previously would result in an incorrect value. This bug is now fixed. (S9G01-002590)

  • DSE Numeric Input Changes

    DSE interprets all numeric input as hexadecimal, except:

    For the CHANGE -BLOCK command:

    LEVEL
                                                      

    For the CHANGE -FILEHEADER command - all the time values:

    AVG_BLKS_READ
    BLK_SIZE
    DEF_COLLATION                                                   
    HARD_SPIN_CPUNT
    JNL_YIELD_LIMIT
    KEY_MAX_SIZE
    RE_READ_TRIGGER
    RC_SRV_COUNT
    RECORD_MAX_SIZE
    REFERENCE_COUNT
    RESERVED_BYTES
    SLEEP_SPIN_COUNT
    SPIN_SLEEP_TIME
    TIMERS_PENDING
    TRIGGER_FLUSH
    UPD_RESERVED_AREA
    UPD_WRITER_TRIGGER_FACTOR
    WAIT_DISK
    WRITES_PER_FLUSH
                                                          

    If -DECIMAL is specified on EVAL, and -VERSION on the REMOVE and RESTORE commands, decimal is used. This convention corresponds to the displays provided by DSE and by MUPIP INTEG.

    The following qualifiers now always interpret values as decimal. Previously, for UNIX, if there was a "0x" prefix or hexadecimal digits, the value would be interpreted as hexadecimal.

    CHANGE -BLOCK:  -LEVEL
    CHANGE -FILE:  -TIMERS_PENDING, -WRITES_PER_FLUSH
    EVAL:  -NUMBER if -DECIMAL is specified
                                                          

    The following qualifiers now always interpret values as hexadecimal. Previously, they only interpreted values as decimal.

    CHANGE -FILE:  -REG_SEQNO, -RESYNC_SEQNO
                                                          

Return to top

Error Messages

Return to top

V5.0-000D

The following error messages are newly added in this release.

  • BKUPTMPFILOPEN, Open of backup temporary file aaaa failed

    Severity: Error (to backup but not to process)

    Run Time Error: When an online backup is in progress, a GT.M process doing updates to the database is saving away the pre-update images of the blocks it updates in a special backup area used to make sure the backups are consistent. Periodically, these blocks need to be flushed out to a temporary file and are flushed by the process needing the space to put its own changed blocks. This means every running process needs to have R/W access to the temporary file created by the backup. If the process cannot open the temporary file, this error is written to the operator log, the backup is flagged as having encountered an error and the process proceeds. So this error is only backup related. It is NOT an error in the process itself which proceeds as if backup were not running.

    Action: Determine cause of why process could not open temporary file, fix, and restart backup.

  • BKUPTMPFILWRITE, Write to backup temporary file aaaa failed

    Severity: Error (to backup but not to process)

    Run Time Error: When an online backup is in progress, a GT.M process doing updates to the database is saving away the pre-update images of the blocks it updates in a special backup area used to make sure the backups are consistent. Periodically, these blocks need to be flushed out to a temporary file and are flushed by the process needing the space to put its own changed blocks. This means every running process needs to have R/W access to the temporary file created by the backup. If the database write generates an error, the BKUPTFWFAIL error is written to the operator log, the backup is flagged as having encountered an error and the process proceeds. So this error is only backup related. It is NOT an error in the process itself which proceeds as if backup were not running.

    Action: Determine cause of why the write failed, fix, and restart backup.

  • VMSMEMORY2, Central storage exhausted during allocation of dynamic file descriptor with yyyy bytes - check page file quota and page file size

    Severity: Error

    Run Time Error: In VMS, dynamic file descriptors used in external routine processing have their space allocated differently from other VMS memory. If one of these special allocations fails, this new version of the VMSMEMORY error is reported.

    Action: Adjusting the pagefile size and quota can increase memory efficiency. Refer the "Planning for GT.M" chapter of the GT.M Administration and Operations Guide - VAX/VMS Edition to determine the appropriate pagefile settings.

  • LOADBGSZ2, Load error: BEGIN too large. No records loaded

    Severity: Error

    MUPIP Error: This error is returned when the BEGIN qualifier's value exceeds the maximum (4GB - 1) value.

    Action: Reduce the size of the parameter value and retry.

  • LOADEDSZ2 Load error: END too large. No records loaded

    Severity: Error

    MUPIP Error: This error is returned when the END qualifier's value exceeds the maximum (4GB - 1) value.

    Action: Reduce the size of the parameter value and retry.

  • JNLPVTINFO, Pid aaaa cycle mmmm fd_mismatch nnnn channel rrrr sync_io ssss pini_addr xxxx qio_active yyyy old_channel zzzz

    Severity: Information

    Run Time Information: This message always accompanies some other GT.M journaling error message. This gives detailed information on the state of the journal buffers at the time of the accompanying error.

    Action: For information purposes only. Review the accompanying message(s) for additional information.

  • RSVDBYTE2HIGH, Record size ssss is greater than the maximum allowed for region rrrr with Block size bbbb and Reserved bytes cccc

    Severity: Error

    Run Time Error: The attempted database update would result in a record size that is greater than what is allowed by the current database block size and reserved byte setting.

    Action: If the Reserved Bytes setting for the database region identified is non-zero, try reducing it to allow this update. Otherwise, modify the update to reduce the resulting record size.

  • REPLINSTMISMTCH, Process has journal pool for aaaa open but database bbbb corresponds to cccc

    Severity: Error

    Run Time Error: An update is being attempted on the replicated database bbbb which was first updated by a process that had replication instance file cccc open but the currently updating process has a different replication instance file aaaa open.

    Action: A replicated database can only be updated by processes that have the same replication instance file (defined by the environment variable gtm_repl_instance) open. Ensure the environment variable gtm_repl_instance is defined to be the same for all processes that update the same replicated database file.

The severity of the following messages is moved from "Severity: Information" to "Severity: Error"

  • LOADBGSZ

  • LOADFMT

  • LOADEDBG

  • LOADEOF

  • LOADEDSZ

The following error messages have some changes:

  • BEGINST, Beginning LOAD at record number: xxxx

    Severity: Information

    MUPIP Information: This indicates that the LOAD command with the FORMAT=BINARY qualifier started with record number xxxx.

    [Note]

    The BEGINST message text is modified with the inclusion of the " record number: xxxx".

  • JNLBUFINFO, Pid aaaa dsk bbbb free cccc bytcnt dddd io_in_prog eeee fsync_in_prog ffff dskaddr gggg freeaddr hhhh qiocnt iiii now_writer xxxx fsync_pid yyyy filesize zzzz cycle oooo errcnt pppp wrtsize qqqq fsync_dskaddr rrrr

    Severity: Information

    Run Time Information: This message always accompanies some other GT.M journaling error message. This gives detailed information on the state of the journal buffers at the tiem of the accompanying error.

    Action: For information purposes only. Review the accompanying message(s) for additional information.

    [Note]

    The JNLBUFINFO message is modified to include "cycle oooo".

  • JNLCLOSE, Error closing journal file: xxxx

    Severity: Error

    Run Time Error: This indicates that GT.M could not properly close journal file xxxx.

    Action: Review the accompanying message(s) for additional information.

    [Note]

    The JNLCLOSE message is modified with the removal of the database name in the message.

  • JNLFSYNCLSTCK, Journaling fsync lock is stuck in journal file jjjj

    Severity: Error

    Run Time Error: This indicates that the system has been unable to write to the journal file for a long duration and information useful for debugging will be logged in the syslog. It is printed after one minute and two minutes, if sync has not occurred yet, after which there will be an FSYNCTIMEOUT error.

    Action: No action required, unless accompanied by FSYNCTIMEOUT. If this message comes up frequently without FSYNCTIMEOUT, you might still want to check the disk subsystem for hardware or software problems.

    [Note]

    The JNLFSYNCLSTCK is modified to print the corresponding journal file name.

  • TPNOTACID, tttt at xxxx in a final TP retry violates ACID properties of a TRANSACTION; indefinite RESTARTs may occur

    Severity: Information

    Run Time Information: GT.M issues this message if it is executing a TP TRANSACTION in the final retry and control gets transferred out of GT.M due to any one of three conditions (i) ZSYSTEM command (ii) Runtime error that transfers control to a user-defined $ZTRAP/ETRAP or (iii) Entering direct mode (e.g. due to a BREAK command). The xxxx indicates the $ZPOSITION where the transfer of control occurred and the condition that caused this is identified in tttt.

    Action: Modify the program to avoid the transfer of control outside of GT.M at the M-source location identified. For example, if the M-program contains a ZSYSTEM, try placing it outside the TRANSACTION.

    [Note]

    The TPNOTACID message text, description and action have changed. See revised version above.

  • TPRESTART, Database mmmm; code: xxxx; blk: yyyy in glbl: zzzz; pvtmods: aaaa, blkmods: bbbb, blklvl: cccc, type: dddd, readset: eeee, writeset: ffff, local_tn: gggg

    Severity: Information

    Run Time Information: This UNIX environment variables or VMS logical names GTM_TPRESTART_LOG_FIRST and GTM_TPRESTART_LOG_DELTA control the logging of TPRESTART messages. GTM_TPRESTART_LOG_FIRST indicates the number of TP restarts to log from GT.M invocation. Once tha many have been logged, for every GTM_TPRESTART_LOG_DELTA TP restarts, a restart message is logged. If GTM_TPRESTART_LOG_DELTA is undefined no operator logging occurs. The default value for GTM_TPRESTART_LOG_FIRST is 0 (zero), which leaves the control completely with GTM_TPRESTART_LOG_DELTA. This message is supposed to serve as a debugging tool in developmental environments to indicate globals of contention.

    Action: Disable or adjust the frequency of these messages with the mechanism described above. To reduce the number of restarts, consider changes to the global structure, varying the time when work is scheduled, whether the business and program logic permits the use of NOISOLATION.

    [Note]

    The TPRESTART message text now includes "Database mmmm".

Return to top

V5.0-000C

The following error messages are newly added in this release.

  • DBVERPERFWARN1, Performance warning: Database xxxx is running in compatibility mode which degrades performance. Run MUPIP REORG UPGRADE for best overall performance

    Severity: Warning

    Run time Warning: When a database is opened by any GT.M component a check is made to see if the database is running optimally. This message is sent to the operator log if the database is running in compatibility mode (database writes are done in V4 mode). Note the message is only generated once per database per 24-hour period.

    Action: For better performance, run MUPIP REORG UPGRADE to switch the database writes to V5 and to convert the entire database to V5 format .

  • DBVERPERFWARN2, Peformance warning: Database xxxx is not fully upgraded. Run MUPIP REORG UPGRADE for best overall performance

    Severity: Warning

    Run Time Warning: When a database is opened by any GT.M component a check is made to see if the database is running optimally. This message is sent to the operator log if the database is not fully upgraded to V5 format. Note the message is only generated once per database per 24-hour period.

    Action: For better performance, run MUPIP REORG UPGRADE to convert the entire database to V5 format.

Several message mnemonics violated GT.M's rule of 15 characters or less for message mnemonics, and were shortened:

Long Form (from)

Short Form (to)

COMMAORPARENEXP

COMMAORRPAREXP

GTMSECSHRSHUTDOWN

GTMSECSHRSHUTDN

GTMSECSHRSRVFILE

GTMSECSHRSRVFIL

GTMSECSHRSTARTUP

GTMSECSHRSTART

ISOLATIONSTSCHNG

ISOLATIONSTSCHN

NEWJNLFILECREATE

NEWJNLFILECREAT

The following error messages are newly added in this release. In addition, please see technical bulletins GT.M Null Subscripts, GT.M Long Names and GT.M Database Migration for more messages.

  • CHNGTPRSLVTM, Mupip will change tp_resolve_time from aaaa to bbbb because expected EPOCH or EOF record was not found in Journal File cccc.

    Severity: Info

    MUPIP Information: At startup, backward recovery/rollback internally computes a time called the tp_resolve_time, which is until when backward processing will be performed across journal files of all regions. During backward processing it is possible in very rare cases that recovery does not see an EPOCH record or an EOF record as the last record in the journal file of those regions that had not been updated for quite a long time. In such cases, recovery reduces the tp_resolve_time further by taking into account the timestamp of the last journal record. This effectively causes further backward processing but is necessary for a clean recovery. A CHNGTPRSLVTM message is printed whenever such journal files are encountered by backward recovery.

    Action: None necessary.

  • DBADDRANGE8, Database file xxxx, element location yyyy: control zzzz was outside aaaa range bbbb to cccc.

    Severity: Info

    Run time Error: This message is the same as a DBADDRANGE message except that bbb8 and ccc8 are 8-byte quantities (as opposed to 4-byte quantities in DBADDRANGE).

    Action: GT.M often fixes this error unless there is a serious problem causing this error. If there is a serious problem, the accompanying messages identify the cause.

  • DBCRERR, Database file xxxx, cr location yyyy blk = zzzz error: aaaa was bbbb, expecting cccc -- called from module xxx at line yyy

    Severity: Info

    Run time Error: This usually indicates that a process was abnormally terminated and left database control structures in an inconsistent state in shared memory.

    Action: GT.M often fixes this error unless there is a more serious problem causing this error. If there is a more serious problem, accompanying messages identify the cause.

  • DBCRERR8, Database file xxxx, or location yyyy blk = zzzz error: aaaa was bbbb, expecting cccc -- called from module yyy at line xxx

    Severity: Info

    Run time Error: This message is the same as a DBCRERR message except that bbbb and cccc are 8-byte quantities (as opposed to 4-byte quantities in DBCRERR). See Error description for message DBCRERR.

    Action: GT.M often fixes this error unless there is a more serious problem causing this error. If there is a more serious problem, accompanying messages identify the cause.

  • DBDIRTSUBSC <xxxx Directory tree block contains non name-level entries>

    Severity: Info

    Run Time/DSE Information: This indicates that the specified database block has an internal structural damage 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.

  • EPOCHTNHI, At the EPOCH record at offset xxxx of yyyy transaction number [0xaaaa] is higher than database transaction number [0xbbbb]

    Severity: Error

    MUPIP Error: This indicates that during turnaround point from where mupip applies logical records, backward recover found that epoch's transaction number is greater than the current database transaction number.

    Action: Contact your system administrator and report to GT.M Support if necessary.

  • GVINCRFAIL <Global variable $INCR failed. Failure code: xxxx.>

    Severity: Error

    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 structural damage 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>

    Severity: Error

    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

    Severity: Error

    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 hash table 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.

  • JNLBADRECFMT, Journal Record Format Error encountered for file xxxx at disk address yyyy.

    Severity: Error

    MUPIP Error: This indicates that MUPIP has found an error in the journal file.

    Action: Report this error to GT.M Support.

  • JNLUNXPCTERR, Unexpected error encountered for Journal aaaa at disk address 0xbbbb

    Severity: Error

    MUPIP Error: This indicates that MUPIP JOURNAL has detected an unexpected error in the journal file that prevents the command from proceeding. A recovery or rollback that uses this journal file cannot successfully complete.

    Action: Report this error to GT.M Support.

  • MAXTRACEHEIGHT, <The maximum trace tree height (xxxx) has been exceeded. The trace information will be incomplete.>

    Severity: Info

    Run time information: The internal GT.M data structure used to gather information during M Profiling cannot 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.

  • MUINFOSTR, xxxx : aaaa

    Severity: Info

    MUPIP Information: MUINFOSTR message is issued by a variety of MUPIP commands to inform the user of the command's progress. This indicates the string xxxx has the value aaaa.

    Action: None necessary.

  • MUINFOUINT4, xxxx : aaaa [0xbbbb]

    MUPIP Information: MUINFOUINT4 message is issued by a variety of MUPIP commands to inform the user of the command's progress. This indicates the string xxxx has the decimal value aaaa and hexadecimal value bbbb.

    Action: None necessary.

  • MUINFOUINT8, xxxx : aaaa [0xbbbb]

    Severity: Info

    MUPIP Information: MUINFOUINT4 message is issued by a variety of MUPIP commands to inform the user of the command's progress. This indicates the string xxxx has the decimal 8-byte value aaaa and hexadecimal 8-byte value bbbb.

    Action: None necessary.

  • MUNOSTRMBKUP, Database xxxx has a block size larger than yyyy and thus cannot use stream (incremental) backup

    Severity: Warning

    MUPIP Warning: GT.M does not support bytestream (a.k.a incremental) backup of a database file that is created with a GDS block size larger than xxxx. As of GT.M version V5.0-000, this limit is 32256 bytes. MUPIP CREATE issues MUNOSTRMBKUP warning when creating a database file with a block size that exceeds the limit. MUPIP BACKUP -BYTESTREAM issues MUNOSTRMBKUP error and skips backing up a file that has block size that exceeds the limit. NOTE: Comprehensive BACKUP does not impose any limit on the GDS block size of the database file being backed up.

    Action: Create the database file with a block size that does not exceed the limit.

  • MUTNWARN, Database file xxxx has 0xaaa more transactions to go before reaching the transaction number limit (0xbbbb). Renew database with MUPIP INTEG TN_RESET.

    Severity: Warning

    MUPIP Warning: This indicates that MUPIP INTEG detected that the transaction numbers in the named database are approaching the maximum number as specified by the Maximum TN Warn field in the database file header. The actual maximum TN is less than this theoretical limit. DSE DUMP FILEHEADER shows what the limit is. The actual limit reflects some overhead used, for example, during a TN_RESET operation.

    Action: Use MUPIP INTEG with the qualifier TN_RESET to reset the transaction numbers in the database. If the database is in the V4 format, consider converting it to the V5 format.

  • REPLJNLCLOSED, Replication and journaling closed at region seqno <xxx> [<XXX>], system seqno <yyy> [<YYY>] for <zzz> GT.M

    Severity: Warning

    Run time error: This operator log message indicates that from this point replication is not possible between primary and secondary. The message also displays the region and journal sequence numbers for debugging purposes.

    Action: In order to restore replication without bringing down the system:

    • Turn replication ON using MUPIP SET -REPLICATION=ON or MUPIP BACKUP -REPLICATION=ON for the database file <zzz>.

    • Since the two sites are out of sync during this timeframe, take primary backup of the database file and restore it to secondary.

  • REPLJNLCNFLCT, Journaling cannot be turned <xxx> on database file <yyy> as the replication state is <zzz>

    Severity: Warning

    MUPIP Error: If journaling could not be turned ON, it indicates that MUPIP could not use SET -JOURNAL=ON or BACKUP -NEWJNL option for the database file <yyy>, because it has replication turned OFF.

    Action: Do not use MUPIP SET -JOURNAL=ON or MUPIP BACKUP -NEWJNL when the current replication state of the database file <yyy> is OFF.

  • REPLOFFJNLON, Replication state for database file <xxx> is OFF but journaling state is enabled.

    Severity: Fatal

    Replication error: In a replicated environment, this indicates that the database file <xxx> cannot have journaling ENABLED or ON when the replication state is OFF. This is an out of design situation due to implications on recovery as journal files can't be a mix of SET/KILL records that were created when replication was ON and those created when replication was OFF.

    Action: In order to prevent this situation, enable replication state for the database file <xxx> (using MUPIP SET -REPLICATION=ON or MUPIP BACKUP -REPLICATION=ON) or disable journaling using MUPIP SET -JOURNAL=DISABLE whichever is desirable.

  • REPLSTATEERR, Replication state cannot be changed to the specified value for database file <xxx>.

    Severity: Error

    MUPIP BACKUP Error: This indicates that the specified change in the replication state cannot be done due to the reason described in a following GTM-E-TEXT message.

    Action: If the message indicates, "Standalone access required", try to enable the replication in the standalone mode using MUPIP SET REPLICATION. If the message suggests switching journal file, specify the backup qualifier NEWJNL in the command line.

  • SHMPLRECOV, Shared memory pool block recovery invoked for region xxxx

    Severity: Info

    Run time information: GT.M carves out a portion of shared memory/global section allocated for each database region to use for ONLINE BACKUP - this portion is called "shared memory pool". This portion is also used by GT.M on OpenVMS while the region is being downgraded dynamically. In the unlikely event of corruption of shared memory pool, or if the blocks are "lost" due to stopped/killed or failed processes, GT.M detects the corruption or lost blocks and runs a recovery procedure to fix these errors. Such an occurrence is logged in the operator log (syslog on UNIX) with SHMLRECOV message.

    Action: Report occurrence to GT.M Support. No user action required. GT.M will continue to operate normally.

  • STPEXPFAIL, Stringpool expansion failed. It could not expand to xxxx bytes

    Severity: Error

    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.

Return to top

Supplementary Information

For supplementary information on GT.M V5.0-000D Release, refer to GT.M V5.0-000D Supplementary Information Technical Bulletin

Return to top

Typographical Conventions

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 [ ].

Return to top

For more information, see the GT.M web site.