GT.M allows keys up to 1019 bytes in length. To accommodate the fact that a key must still fit within one database block, the maximum key size is also limited to 40 bytes less than the block size, e.g., a 1024 byte block can support a maximum key size of 984 bytes and a 1536 byte block size is the smallest that supports a key with the maximum size of 1019 bytes. Both GDE and MUPIP also enforce these limits. Previously keys were limited to 255 bytes. Since the smallest database block size is 512 bytes, neither GDE nor MUPIP previously needed to validate the maximum key size against the block size. [UNIX] (GTM-358)

GT.M now has a field test grade implementation of an Instance Freeze facility. This provides users with a mechanism to freeze regions associated with an instance on a set of conditions they control. It provides an alternative to the GT.M design of keeping the system up in the face of operational challenges, even when they represent rising levels of risk. That original design continues to be what FIS considers wholesome practice for maximum business continuity and recommends that you use it in conjunction with logical multi-site configurations layered on replication. Instance freeze is provided for those users who prefer for operational reasons to freeze an operating instance instead of switching over.

GT.M recognizes the gtm_custom_errors environment variable as a flag that enables a facility to freeze updates to an instance on the occurrence of a configurable set of errors. We refer to this mechanism as "Instance Freeze" to differentiate it from the region freeze associated with MUPIP and DSE operator actions. $gtm_custom_errors must resolve to a file, including its path, which contains a text list of error mnemonics from the set documented in the GT.M Message and Recovery Guide. The mnemonics must be capitalized, one per line. To be affected by this mechanism, a region must be a part of the instance and the error must have a database region context. To activate a freeze, a region must be configured to set freezes. In other words, a region can be affected by freezes, but also be excluded from setting freezes. An operator can set or clear Instance Freeze with a MUPIP command (see below). When Instance Freeze is active, GT.M modifies the NOSPACEEXT message from error (-E-) to warning (-W-) to indicate it is performing the extension even though the available space is less than the specified extension amount. When GT.M detects a hard out-of-space condition in any database, journal or replication instance file storage media, it sends a DSKNOSPCAVAIL message to the operator log. DSKNOSPCAVAIL is a condition which GT.M retries indefinitely and, if and when the condition clears due to operator intervention, GT.M automatically lifts the freeze (sending a DSKSPCAVAILABLE). When an instance is frozen, attempts to flush buffers to the database and journal files hang, but flushes to ancillary files like the backup temporary file, journal extract file, etc. may continue.

If the freeze scheme is turned ON ($gtm_custom_errors is defined) and $gtm_repl_instance is defined, the following MUPIP operations and any GT.M process that opens a database (even for the purpose of reading a global) attempt to open the replication journal pool. Any error while opening the journal pool, except for the case when it is unavailable (due to the instance being cleanly shutdown), results in a runtime error.

The following lists the syntax for GDE and MUPIP commands that manage the facility:

 GDE 
 === 
 add -region B -dynamic_segment=B -noinst[_freeze_on_error] 
 add -region C -dynamic_segment=C -inst[_freeze_on_error] 
 template -region -inst[_freeze_on_error] 
 template -region -noinst[_freeze_on_error] 
 change -region A -inst[_freeze_on_error] 
 change -region C -noinst[_freeze_on_error]
 show -region # includes inst freeze on error flag 
 show -template # includes inst freeze on error flag 
 show -command # includes inst freeze on error flag 
 
 MUPIP 
 ===== 
 mupip set -region B -inst[_freeze_on_error] 
 mupip set -region D -noinst[_freeze_on_error] 
 mupip replicate -source -freeze # display freeze state 
 mupip replicate -source -freeze=on -[no]comment[='"for example comment"'] # freeze instance with optional comment 
 mupip replicate -source -freeze=off # unfreeze instance 
 mupip replicate -source -checkhealth # checks freeze state, displays if frozen 

There are certain error messages which can occur before attaching to, or after detaching from, a journal pool - in such cases, those error message do not have access to the journal pool and cannot activate a freeze. For example, GT.M detects SCNDDBNOUPD after detaching from the journal pool and hence can't cause an Instance Freeze. Because processes typically can't update instance database files without access to the journal pool, this should not be a material restriction.

If an I/O error occurs while flushing global buffers, GT.M reports a DBIOERR error to the operator log; if such an error occurs while writing an EPOCH, GT.M raises the DBIOERR as a run-time error. Previously, GT.M did not report such errors and repeatedly invoked cache-recovery logic.

GT.M distribution kits include a custom_errors_sample.txt file which can be used as a target for the gtm_ custom_errors environment variable. The configure script copies this file into the installation directory. [UNIX] (GTM-4525)

The checksum used by GT.M to validate journal records includes the entire record. Previously, GT.M computed the checksum only on parts of the journal record deemed sufficient to detect damaged journal records. A system failure that resulted in damage only to the unprotected part of a journal record could previously result in database damage, or memory segmentation violations (SIG-11 on UNIX; ACCVIO in OpenVMS) if that journal record was used in recovery or rollback. We are not aware of such a failure ever occurring at an actual user site. Recent testing by FIS alerted us to possibility of failure scenarios that could damage the unprotected parts but not also damage the protected parts, while in system failure scenarios previously analyzed, the prior approach provided sufficient protection. (GTM-5698)

GT.M handles global variable nodes up to 1MiB - the same maximum as that of a local variable node - by spanning large global variable nodes across multiple database blocks. The meaning of the maximum record size for a database region henceforth refers only to the size of the value. In the event a global variable node spans multiple blocks, and the process is not already within a TP transaction, the GT.M run-time system automatically and transparently performs the entire operation within an implicit TP transaction (just as is the case with triggers). GDE and MUPIP restrict the maximum record size to 1,048,576 bytes without regard to the database block size. Previously the maximum record size was limited by the block size and referred to the maximum size of the record within a database block including the key and delimiters.

The following journaling-related limits and defaults have been updated to support the increased record and key sizes:

In conjunction with these changes, the maximum database size has been increased to 1,040,187,392(992Mi) blocks. Previously this limit was 234,881,024(224Mi) blocks.

MUPIP INTEG and DSE deal appropriately with global variable nodes that span database blocks. MUPIP INTEG validates record size using the revised definition and limit, and also validates spanning node format and ordering. The INTEG report contains the total number of spanning nodes and the number of blocks holding spanning node fragments. DSE DUMP BLOCK -FORMAT=ZWR output for a block containing a spanning node has the syntax of a SET $ZEXTRACT() argument. MUPIP LOAD -FORMAT=ZWR accepts input including $ZEXTRACT() syntax. Together these utilities enable a block level salvage strategy as described in the Maintaining Database Integrity chapter of the Administration and Operations Guide.

The binary extract header format supports maximum record lengths up to 7 decimal digits. Formerly, maximum record length could not exceed 64KiB. Since the binary extract is at the record level and new subscripts have been added, binary extracts cannot be used to transfer data to previous GT.M versions that do not support spanning nodes. If the key lengths and value length allow all global variable nodes to fit in one database block of previous GT.M versions, use ZWR format for MUPIP EXTRACT and LOAD.

Operationally, this uncoupling of the maximum size of a global variable node from the database block size means that a minuscule percentage of large global variable nodes - perhaps just one large global variable node - need no longer force your application to use a larger block size than the optimum one for application performance. Although there is no performance impact from this enhancement for global variable nodes that do not span blocks, nodes that span blocks do incur some overhead, and optimum application performance is likely to be obtained from a block size that accommodates the majority of nodes within a single block. When and if you tune for smaller block sizes to take advantage of this new feature to enhance performance, you should also adjust the number of global buffers. Start with the number of global buffers that gives the same product of block size and number of global buffers, and adjust from there. A further consideration is that since TP can be involved in an update and a transaction is limited to half the number of global buffers, the number of global buffers should be at least twenty-six plus twice the number of the blocks required by the largest global variable node in your application.

Spanning nodes are not supported via GT.CM. Maximum record size checking was enhanced to only use the size of the value (and create a spanning node if needed). Since spanning nodes are not supported on GT.CM, maximum record size is calculated as done previously (meaning that there must be space for the record header, key, etc). If a GT.CM GNP server finds a database contains spanning nodes and a particular non-spanning node contains the value $c(0), it will issue an error even though the node is not a spanning node. [UNIX]

In addition to the above UNIX-only features, as a part of this project GT.M has also introduced the following cross-platform changes: MUPIP no longer issues JNLBUFFTOOSM and JNLBUFFTOOLG errors when the journal buffer size specified by the user or previously stored in the database file header falls outside the permissible range. Instead, the journal buffer size is automatically adjusted, up or down, to take a legitimate value. Note that the auto-adjustment occurs on top of the pre-existing rounding-up of the journal buffer size to the next multiple of [block size / 512] ratio. MUPIP issues a notification about any adjustment of the journal buffer size via the newly introduced JNLBUFFREGUPD or JNLBUFFDBUPD warning message, for region and database file accordingly. If the value prior to adjustment was invalid, MUPIP reflects that fact in an appendix message following one of the above warnings. A MUMPS process may also increase the journal buffer size value in the database file header when it initializes shared memory, to prevent insufficient resource allocation if, for example, using a database created with older GT.M executables. (GTM-6341)

GT.M appropriately handles the case where an unsubscripted global variable name exceeds the maximum key size of the database region, a case that requires a maximum key size of less than 32, by issuing a KEY2BIG error. As part of this change GT.M is likely to display more of the over-length key when reporting a GVSUBOFLOW condition. Previously a name that exceeded the maximum key size could cause an incorrect GTMASSERT error and/or memory corruption, which in turn caused a memory segmentation fault (UNIX SIG-11 or OpenVMS ACCVIO); because this required both an unusually small maximum key size and an unusually long global variable name, we expect this was never encountered outside our test scenarios. (GTM-6502)

The critical section management that produces the MUTEXLCKALERT warnings in the operator log includes the gtm_procstuckexec mechanism for automating the gathering diagnostic information or other operator actions. The MUTEXLCKALERT mechanism is much more careful to only issue alerts if a single process is holding a resource without ever releasing it and does so at intervals in the range of approximately 30-60 seconds. Previously it only took into account how long a single process had waited regardless of whether other work was getting completed and it did not include the gtm_procstuckexec capability. [UNIX](GTM-6571)

To facilitate usage (for example, benchmarking scenarios) where it is desirable for a large number of processes to shut down almost concurrently, GT.M database files provide a [NO]QDBRUNDOWN setting (the default of NOQDBRUNDOWN preserves current behavior for normal usage). If QDBRUNDOWN is set for a database region, when a terminating process observes that a large number of processes are attached to the database, it bypasses logic to check whether it is the last process attached to that database (so that it can clean up the database fileheader and IPC resources associated with that database file when it is the last process) . Since the check to determine whether a process is the last process must be performed in a critical section, eliminating the check when there are a large number of processes attached to the database allows rapid process shutdown, as well as removing an impediment to process startup. Note that with QDBRUNDOWN there exists the possibility of race conditions that leave the database fileheader and IPC resources in need of cleanup. Although the logic minimizes the probability of such a race condition, it cannot eliminate it. When using QDBRUNDOWN, FIS recommends an explicit MUPIP RUNDOWN of the database file after the last process exits, to ensure cleanup of the database fileheader and IPC resources.

This setting in the database fileheader is changed by the -[NO]QDBRUNDOWN switch of the MUPIP SET and DSE CHANGE -FILEHEADER commands. DSE DUMP -FILEHEADER -ALL shows the number of processes that have performed a quick exit since the database was last opened). As with other database parameters, the initial value of the setting is taken from the global directory when MUPIP CREATE initially creates a database file. Use the -[NOQDBRUNDOWN] switch of GDE's CHANGE -REGION and TEMPLACE -REGION commands to manage this setting in global directory files. GDE SHOW shows the setting of the switch, labeled QdbRndwn.

In conjunction with this change, GDE SHOW changes the labeling of certain fields, in order to improve the readability of the output:

[UNIX] (GTM-6692)

If the last owner of a critical section terminated without releasing ownership, the last remaining active process can successfully terminate without first doing a database access. Previously under the rare occasions when those conditions existed, typically because of a kill -9 that last process exiting could hang. Note that FIS strongly recommends against terminating processes with kill -9. [UNIX] (GTM-7200)

On 32-bit platforms, GT.M appropriately issues warning messages during buffer pool validation. In most recent releases, these warnings could cause segmentation violations (SIG-11). The most common reason for GT.M processes to initiate buffer pool validation is to clean up after processes are terminated without the opportunity to exit cleanly (for example, terminated with a kill -9); other causes are rare internal GT.M errors. Note that FIS strongly recommends against terminating processes with kill -9. [Linux X86, HP-UX PA-RISC, TRU64] (GTM-7239)

GT.M ensures keys inserted into index blocks honor the maximum key size field in the fileheader. Previously, due to changes introduced in V54002, database updates could create index keys exceeding the maximum key size, resulting in INTEG errors. We are not aware of this having happened outside FIS test environments. (GTM-7308)

GT.M provides protection from certain coding practices that can cause deadlocks (in the worst case) and long hangs (in the best case) by enhancing and extending to HANG, JOB, LOCK, OPEN, READ, and ZALLOCATE, protection previously provided for ZSYSTEM and BREAK when used within TP transactions. When $TRETRY>2 and the GT.M process holds the critical sections for all participating database regions, if the process executes one of the aforementioned commands with no timeout, or with a timeout exceeding the value of the gtm_tpnotacidtime UNIX environment variable or OpenVMS logical name GTM_TPNOTACIDTIME, GT.M sends a TPNOTACID informational message to the system log and releases the critical sections before continuing. GT.M limits gtm_tpnotacidtime to the range zero (0) through 30 seconds, defaulting it to two (2) seconds if it is not specified or its value is outside the range. In the cases of LOCK and ZALLOC with timeouts that do not exceed the gtm_tpnotacidtime, if the resource name is locked on the final retry, the process may generate TPNOACID messages while it tries to ensure there is no possibility of a deadlock. The text in the TPNOTACID message for the Direct Mode case is now: "Entering DIRECT MODE - TP RESTART will fail". This change does not affect application logic; for most cases, it does limit the time which a long running command can hold control of a database resource. A process with a non-Isolated or long running command may encounter potentially indefinite restarts. Such processes constitute a non-productive and disruptive load. If your log file contains TPNOTACID messages, review the logic to see whether the non-Isolated commands can be moved outside of transaction encapsulation, or use timeouts that ensure they are minimally disruptive. As a consequence of this change, a process running code which gives TPNOTACID messages might fail to get an error indicating database damage should it encounter such an unlikely eventuality - since the process is in an indefinite restart; such a case cannot cause any additional damage. Another consequence of this change is that MUPIP TRIGGER operations have an implicit timeout of zero (0), meaning the read must succeed on the first try or the command will act as if it received no input. Consider using $ZMAXTPTIME to prevent transactions from running unreasonably long times. The new gtm_zmaxtptime UNIX environment variable or OpenVMS logical name GTM_ZMAXTPTIME can specify an initial value for the $ZMAXTPTIME Intrinsic Special Variable, which controls whether and when GT.M issues a TPTIMEOUT error for a TP transaction that runs too long. GT.M limits this initial value to from one (1) to 60 seconds and ignores values outside of the recognized range; this range check does not apply to SET $ZMAXTPTIME. Prior versions limited only ZSYSTEM and Direct Mode and did not provide the initialization capabilities. The workaround was to use short timeouts for timed operations in order to prevent them from stalling database activity. (GTM-7327)

As part of an ongoing process to tighten GT.M security, V6.0-000 brings changes to the operation of gtmsecshr as described below.

Please note that these are part of our continuing improvements to GT.M - these changes neither alter the GT.M security philosophy and model nor are they intended to block any particular exploit. [UNIX] (GTM-7336)

GT.M correctly validates TP transactions involving splits of index blocks. Previously, a TP transaction running concurrently with another GT.M process, each doing a specific and unlikely sequence of database updates, could result in data loss. While we we able to create this scenario during our internal testing, we are not aware of it ever having been encountered during actual use. In addition, GT.M transactions in the final retry more robustly invoke cache recovery upon detecting a concurrent transaction that has encountered an error in the midst of commit. Previously, these updates issued an inappropriate error. (GTM-7353)

MUPIP FREEZE on a database with abandoned kills proceeds after producing a warning message. Previously in this situation, the FREEZE operation gave an error and did not complete. (GTM-7365)

GT.M handles a specific trigger-related concurrency issue correctly. Previously, there was a small possibility of a SIG-11 or access violation during a trigger invocation if trigger definitions changed concurrently. As far as we know this issue has only been encountered in our test environment. [UNIX] (GTM-7426)

GT.M reports all DBFSYNCERR occurrences to the system log. Previously, journal flushes did not report DBFSYNCERR to the system log. Such errors should be rare, however, please contact FIS if this becomes an issue in your environment.[UNIX] (GTM-7431)

GT.M correctly switches journal files when the remaining space in the file seems insufficient to accommodate a journal EOF record. In previous versions, GT.M did not ensure that there was adequate space at the end of a journal file to close it cleanly (for example, to write an EOF record). This resulted in abnormal process termination (and possible core files) for all processes accessing the database, as each in turn attempted to close the journal file, leaving an improperly terminated journal file. Scenarios in which this could occur were very rare and more likely to be encountered in testing / benchmark scenarios than in normal usage - although the issue was long-standing, FIS is not aware of it ever having been encountered in other than testing / benchmarking scenarios. (GTM-7439)

Messages that GT.M sends to the terminal or operator log are printed in their entirety. Previously, when dealing with timer-driven events, GT.M sometimes wrote a second message on top of a message under construction, which resulted in rare instances of garbled messages. [UNIX] (GTM-6686)

GT.M gives a LOCKINCR2HIGH error when an Incremental LOCK (LOCK +) attempts to raise the level above 511. Previously GT.M had the same limit but did not enforce it, causing an asymmetrically small number of decrements (LOCK -) to release the LOCK; ZSHOW "L" showed the wrapped value. (GTM-6779)

GT.M processes appropriately handle a MUPIP INTRPT arriving in a certain specific window during a SOCKET READ. Previously processes could fail when a SOCKET READ was interrupted. Even with knowledge of the fix, FIS was never able to reproduce the failure in our development environment and it was only ever reproduced at one site under a specific workload involving intensive SOCKET READs on a heavily loaded system. While the only observed failure was a segmentation violation (signal-11 on UNIX; ACCVIO on OpenVMS), it was theoretically possible for the failure to happen even on a lightly loaded system performing infrequent SOCKET READs, and it was also theoretically possible for the READ to return incorrect data without failing. (GTM-6907)

M-profiling appropriately handles large values for the user, CPU, and elapsed time values collected for individual lines, labels, and master and child processes. Previously, these values could overflow on long-running processes, yielding incorrect values in the tracing report. In addition, in UNIX editions, $HOROLOG is not subject to hardware or operating system rounding errors. Previously, on certain (at least AIX) platforms $HOROLOG could occasionally report the same value when, in fact, at least one second had elapsed between the measurements. (GTM-7075)

A LOCK operation that finds no room in LOCK_SPACE to queue a waiting LOCK, does a slow poll waiting for space. Previously a LOCK encountering such a situation generated a LOCKSPACEFULL error (GTM-7205)

M LOCKS issue a LOCKSUB2LONG error when a subscript in the resource name exceeds 255 bytes. Previously, a LOCK with such a resource name allocated the memory but LKE SHOW and ZSHOW "L" could not report it. (GTM-7208)

GT.M does more appropriate checking for maximum length output value for SET $PIECE() and SET $EXTRACT(). Previously, a large piece value or byte position respectively could cause MEMORY (UNIX) or VMSMEMORY (VMS) errors, return corrupt or otherwise incorrect data, or result in a memory segmentation violation (UNIX SIG-11 or OpenVMS ACCVIO). (GTM-7227)

GT.M handles an invalid command within a FOR body appropriately. In V5.5-000, the change to permit the run-time to skip over an INVCMD error with a FALSE postconditional created a situation where an invalid command within a FOR with a termination condition generated a memory segmentation violation (UNIX SIG-11 or OpenVMS ACCVIO) at compile time. (GTM-7255)

In "full Boolean" mode, GT.M handles all known cases where parentheses surround a term other than the last term with multiple components. In V5.5-000, depending on the order and sense of the terms GT.M could evaluate such constructs incorrectly.(GTM-7277)

The GT.M compiler reports an error if it encounters a numeric literal that contains multiple decimal points. This corrects an unintended change associated with the numeric normalizations (C9H02-002826) in V5.4-002. (GTM-7283)

READ from stderr of a PIPE device in UTF-8 works appropriately. Previously, such a READ could hang. [UNIX] (GTM-7306)

The [NO]DESTROY deviceparameter for the CLOSE command for sequential files, FIFO and SOCKET devices determines whether the process retains device characteristics after the CLOSE. Preserving prior GT.M behavior, the default is DESTROY for sequential disk files and FIFO devices, and NODESTROY for SOCKET devices. While NODESTROY allows the re-OPEN of previously CLOSE'd device with the same characteristics as when it was last CLOSE'd, as described by the M standard, every tracked device uses process memory. A device that has been DESTROYed on CLOSE cannot be re-opened with the previous characteristics, but reclaims memory used by the process for that device. This device parameter is ignored for other devices - terminals and VMS MBX devices act as if the specification were NODESTROY and PIPE devices act as if the specification were DESTROY. Also, the device parameter is ignored for CLOSE of a specific socket rather than the entire socket device. Previously, CLOSE removed all information for a sequential file and FIFO, and kept the information for a SOCKET. (GTM-7319)

Numeric equality comparisons of certain fractional exponents correctly evaluate to 1. Previously, as a consequence of incorrect internal flags, although such results printed correctly, and produced accurate results when used in subsequent calculations, a comparison for equality could incorrectly evaluate to 0. The result values subject to this incorrect behavior were a subset of the range -999999.999 through 999999.999 (i.e., with up to three digits after the decimal point). For example, 4**.5=2 previously incorrectly evaluated to 0. (GTM-7332)

Prior to closing the underlying UNIX pipe file descriptor, a WRITE /EOF to a PIPE device now flushes output in the same way as a CLOSE and sets $X to zero (0). If you do not want WRITE /EOF to flush any pending output including padding in FIXED mode or a terminating EOL in NOFIXED mode, SET $X=0 prior to the WRITE /EOF. A READ from a PIPE device in FIXED mode operates correctly after a WRITE /EOF. Previously, WRITE /EOF on a PIPE closed the output file descriptor without flushing any pending output and a READ after a WRITE /EOF in FIXED mode caused a "SYSTEM-E-ENO9, Bad file descriptor" error. [UNIX](GTM-7351)

GT.M appropriately handles some situations where it could, under some circumstances, stimulate underlying system-related software to behave in an unintended fashion usually (always as far as we know) resulting in a segmentation violation (UNIX SIG-11 or OpenVMS ACCVIO). This has only been reported on certain combinations of LINUX releases and x86 or x86-64 hardware, but could, at least in theory, occur on other platforms. (GTM-7358)

GT.M correctly handles TP transactions where the only updates to the database are definitions and/or deletions of triggers. Previously, in some rare cases, such transactions could result in a segmentation violation (SIG-11). [UNIX] (GTM-7388)

ZSHOW "G" reports the following [additional] process statistics as part of a comma separated list where each statistic has its mnemonic followed by a colon and the count. DSE DUMP -FILEHEADER reports the same statistics for a region. The characters used to arrive at each mnemonic are highlighted in upper-case in the corresponding description.

DFL : # of Database FLushes
DFS : # of Database FSyncs
JFL : # of Journal FLushes
JFS : # of Journal FSyncs
JBB : # of Journal Buffer Bytes written
JFB : # of Journal File Bytes written
JFW : # of Journal File Writes
JRL : # of Journal Logical Records
JRP : # of Journal Records for Pblks
JRE : # of Regular Epoch Journal Records 
JRI : # of Idle epoch Journal Records
JRO : # of Journal Records of Other types
JEX : # of Journal file EXtensions
DEX : # of Database file EXtensions

The above list is in the order of presentation. The below list describes the mnemonics in more detail.

(GTM-7389)

The ]] ('sorts-after') operator sorts canonical numerics ahead of strings when using an alternate local collation. Previously, the ]] operator gave no precedence to canonical numerics over strings in alternate local collations. For information on how to revert to the prior behavior please contact FIS. (GTM-7397)

The configure installation script retains the GTMHELP.o object file needed to execute the MUMPS zhelp online documentation command. Previously the installation deleted this file which prevented ZHELP from working as intended. The workaround was to compile GTMHELP.m into the gtm_dist direcory. [UNIX] (GTM-7400)

The GT.M call-in interface properly passes negative integers and longs between -1 and -999999 to GT.M. In 5.5-000, it passed these numbers as positive. (GTM-7410)

The OPEN command appropriately opens /dev/zero, /dev/random and /dev/urandom devices. Previously, an OPEN command for the /dev/zero, /dev/random or /dev/urandom devices with FIXED device-parameter could result in a memory segmentation violation, while without that deviceparameter, it gave an UNIMPLOP error. (SIG-11). [UNIX](GTM-7411)

A failing OPEN of a new SOCKET device releases the memory allocated to set up the device and a subsequent ZSHOW "D" does not show that device. Previously, a failed OPEN of a new SOCKET device leaked some memory and the device subsequently showed up as CLOSED device in ZSHOW "D". (GTM-7413)

$ORDER() and $ZPREVIOUS() return an empty string when they reach the trigger definitions (stored in ^#t) as it is not a normally accessible global. Since the introduction of triggers in V5.4-000 if there were trigger definitions, these functions could return ^#t. [UNIX] (GTM-7433)

$ZTRIGGER() appropriately processes trigger definitions stored as constants in routine within a shared library. In addition, MUPIP TRIGGER and $ZTRIGGER() accurately report trigger locations in error messages. Previously $ZTRIGGER() gave a segmentation violation (SIG-11) when trying to define a trigger from a string value embedded in a shared library and, along with MUPIP TRIGGER, could slightly misstate trigger locations in error reports. The workaround for the $ZTRIGGER() issue was to use a flat file to hold the trigger definition. [UNIX] (GTM-7452)

The receiver server log prints the timestamp as well as the current backlog (on the receiver side) as part of the "REPL INFO - Seqno" messages. Previously, it did not print this information. A sample new message follows.

Wed Jul 11 13:39:15 2012 : REPL INFO - Seqno : 23001 [0x59d9] Jnl Total : 2208264 1 Msg Total : 2392384 1 Current backlog : 9263 [0x242f]

The source server prints hexadecimal values as well as the timestamp as part of the "REPL INFO - Seqno" messages. Previously, it printed only decimal values. A sample new message follows.

Wed Jul 11 13:39:15 2012 : REPL INFO - Seqno : 23482 [0x5bba] Jnl Total : 2254272 [0x2265c0] Msg Total : 2442128 [0x254390] CmpMsg Total : 2442128 [0x254390] Current backlog : 0 [0x0]

(GTM-6057)

Argumentless MUPIP RUNDOWN leaves shared memory associated with databases or replication servers if there are processes attached to the respective shared memories. Previously, argumentless MUPIP RUNDOWN in some cases removed shared memories associated with database or replication servers thereby causing errors during replication server shutdown commands. [UNIX]

If Argumentless MUPIP RUNDOWN does not remove a database or replication shared memory segment (due to errors with database or replication instance files), it reports MUFILRNDWNFL2 and MUJPOOLRNDWNFL or MURPOOLRNDWNFL (depending on whether the segment is a Journal Pool or Receive Pool) messages along with appropriate details in the terminal and operator log. Previously, argumentless MUPIP RUNDOWN did not issue such messages. [UNIX] (GTM-7010)

The Source Server logs its unsuccessful connection attempts starting frequently and slowing to approximately every five minutes. This change does not affect the rate of connection attempts, only the frequency of logging unsuccessful attempts. Previously the Source Server logged every connection attempt. (GTM-7167)

As MUPIP INTEG with the FAST option does not check data (level 0) blocks, an optimization results in application processes never updating the snapshot file for modifications to level 0 blocks. This reduces IO impact and improves performance. Previously, application processes wrote before images of data blocks as well during a MUPIP INTEG FAST. Note that this speeds up MUPIP INTEG -FAST -FULL, which is a quick way to get an approximate size of each global variable in the database.[UNIX] (GTM-7194)

In the event that the replication log file specified on a MUPIP REPLICATE command line is not writable (for example, the directory does not exist or the process lacks permission to create or write to the file), the MUPIP process immediately terminates with an error message, returns a failure status to the shell and does not report an issue to the system log. Previously during the start-up of servers, the MUPIP process reported the problem in the system log; or during the running of servers, MUPIP ignored the problem so it appeared that the command executed successfully without returning failure status to the shell, but the server running background subsequently terminated with a segmentation fault (SIG-11 on UNIX; ACCVIO on OpenVMS). (GTM-7218)

GT.M manages external filters in a more robust manner by correcting, if necessary, journal sequence and stream sequence numbers for transactions returned by the filter; it also removes any null records generated by the filter inside a wrapped transaction. Previously a filter that damaged these values or produced inappropriate null records could cause replication to fail or to enter an indefinite loop. [UNIX] (GTM-7221)

MUPIP JOURNAL -EXTRACT starts appropriately independent of the state of the corresponding database file and does not write new records to journal file. Previously, if the database had a buffer pool in a suspect state, typically from an incomplete or improper shutdown, a JOURNAL -EXTRACT attempt involving the region terminated with a segmentation fault (UNIX SIG-11 or OpenVMS ACCVIO) or inappropriately wrote to the journal file. (GTM-7231)

By default MUPIP REORG block reordering includes all global data and index blocks except the master root block for the region. This permits the -TRUNCATE option to more consistently free space; it also induces reorganization of blocks occupied by trigger definitions for a given region. Previously REORG did not move Global Directory Tree blocks, the root blocks of individual globals, or blocks occupied by trigger definitions for a given region; this meant that globals created for the first time when the database was in a reasonably full state could substantially reduce the effectiveness of -TRUNCATE. [UNIX] (GTM-7242)

MUPIP JOURNAL -SHOW=HEADER reports details of the process that first opened the journal file under the section labeled "Process That First Opened the Journal File". Previously it incorrectly labeled the section as "Process That Last Wrote to the Journal File". (GTM-7243)

MUPIP ROLLBACK -ONLINE is now considered production grade functionality. Since it can take a database backwards in state space, please make sure that you understand what it is that you intend it to do when you invoke it. Please refer to the V5.5-000 release notes for more discussion of its operation. As FIS developed it as a step towards a much larger project, we anticipate that it will not be broadly useful as is.

The following changes were made as part of GTM-7253:

[UNIX] (GTM-7253)

Replication from a Propagating Instance, including a Supplementary Instance to a Receiving Instance works more robustly. Previously in some rare cases, the Receiving Instance could have incorrect history records written in its instance file causing inappropriate STRMSEQMISMTCH errors. [UNIX] (GTM-7257)

MUPIP REPLICATE -RECEIVE -START -UPDATERESYNC accepts the -INITIALIZE qualifier. For SI replication, -INITIALIZE specifies that this is the first connection between the instances, while -RESUME (mutually exclusive with -INITIALIZE) specifies that replication should continue from where the previous replication connection left off. Use of UPDATERESYNC when starting an SI replication connection requires an accompanying -INITIALIZE or -RESUME. MUPIP ignores these qualifiers when starting BC replication (that is, no updates permitted on the instance with the Receiver Server). In previous versions of GT.M, starting an SI replication connection with UPDATERESYNC without an explicit RESUME caused replication to operate as if it was an initial connection, which could result in replication starting from a different point from where the previous connection left off, potentially causing gaps in the data. You need to revise existing shell scripts to ensure explicit use of the INITIALIZE qualifier where the initial connection was implicit. FIS has determined that the additional protection against inadvertent error warrants making this change which is not strictly upward compatible.

The -UPDNOTOK qualifier works as documented. In V5.5-000, any source server command involving -UPDNOTOK incorrectly terminated with a CLIERR error.

MUPIP rejects conflicting -PROPAGATEPRIMARY and -UPDOK qualifiers on the same command and issues a CLIERR. In V5.5-000, a Source Server command with conflicting -UPDOK and -PROPAGATEPRIMARY qualifiers incorrectly proceeded as if only - UPDOK had been specified.

A replication configuration of A->B->P where A->B replication is BC replication and B->P replication is SI replication works as documented. Previously, P's Receiver Server terminated with a PRIMARYNOTROOT error when connecting with B's Source Server. [UNIX] (GTM-7258)

The replication source server log displays a correct value of "Start Seqno" in the message that describes the content of the history record sent across (this messages reads "New History Content ..."). In GT.M V5.5-000, in some cases, it used to display a "Start Seqno" that was less than what it actually sent across, which was the correct value. The corresponding message in the receiver log for the same time showed the correct value. This did not affect the correctness of replication but confused anyone who looked at both logs and found the discrepancy. [UNIX] (GTM-7265)

MUPIP SET -JOURNAL now cuts the link to the previous-generation journal file if it was not properly closed due to a system crash, and the database has been the subject of a MUPIP RUNDOWN afterwards. Previously, when creating a new journal file upon a system crash and a subsequent database rundown, MUPIP SET -JOURNAL tried to link the created journal file back to the potentially invalid pre-crash journal file. Problems with integrity in the older journal file could result in a number of other journaling-related issues. Note that in the event of a crash FIS strongly recommends performing a MUPIP ROLLBACK on a database with replication, MUPIP JOURNAL RECOVER on a journaled database, and MUPIP RUNDOWN only if using neither journaling nor replication. To promote this decision-making model, in addition to REQRUNDOWN message in a process crash scenario with neither journaling nor replication enabled, on UNIX GT.M now issues a REQROLLBACK error in cases with replication and BEFORE IMAGE journaling, and REQRECOV error with NOBEFORE journaling. Together, REQRUNDOWN, REQROLLBACK and REQRECOV messages provide more context-specific instructions, thus better guiding the user in protecting and recovering data after a process crash. Previously, GT.M issued REQRUNDOWN error on a process crash regardless of journal and replication states. (GTM-7339)(GTM-7286)

When journaling is off and replication is in the "WAS_ON" state for any target database, MUPIP JOURNAL -ROLLBACK -BACKWARD issues a REPLSTATEOFF and terminates immediately with a non-zero exit status. When the journal files are inaccessible, UNIX editions of MUPIP JOURNAL -ROLLBACK -BACKWARD or -RECOVER -BACKWARD issues a JNLACCESS error and terminates with a non-zero exit status. Running the journal file storage out of space most commonly causes both of these conditions. In prior versions for these cases, MUPIP terminated without reporting the issue and gave a success exit return even though it was not able to restore the database(s) to a wholesome state. (GTM-7294)

Specifying -LOG=<file-name> with MUPIP REPLICATE -{RECEIVER |SOURCE} -STATSLOG={OFF | ON} generates a GTM-E-CLIERR, and with STATSLOG=ON the detailed status information appears in the Receiver Server or Source Server log. Previously specifying -LOG= with -STATSLOG caused the server to create the file specified with -LOG with a single entry, and could subsequently cause the Server to terminate with a memory segmentation fault (SIG-11). Although the revised behavior is not technically upward compatible, the previous behavior made the now disallowed combination at best useless and at worse disruptive. [UNIX] (GTM-7296)

MUPIP REORG correctly handles a concurrency issue discovered in the course of our test development. Previously, this very rare case could result in database damage. (GTM-7298)

When reading multiple journal records from the journal file, the Source Server handles buffer expansion correctly. Previously, if buffer expansion occurred concurrently with an action that added history records to the instance file, the Source Server could corrupt its control structures and hang indefinitely. [UNIX] (GTM-7317)

Duplicate of GTM-7286. (GTM-7339)

The Source Server exits with one or more JNLFILOPN messages after six failed attempts to open journal files. The JNLFILOPN messages contain information on the journal files and regions that were not opened. The first five open failures generate REPL_WARN messages. Previously, the Source Server generated REPL_WARN messages every 10 seconds indefinitely and provided no information on which files were associated with the failure. [UNIX] (GTM-7344)

The Source Server properly handles sending very large amounts of data after reestablishing a dropped connection to the Receiver. Previously this could lead to the Source Server sending invalid messages to the Receiver, possibly leading to data corruption, errors, or crashes.(GTM-7363)

MUPIP JOURNAL -ROLLBACK on a supplementary instance works correctly even if there were no locally generated updates since the instance file was created or if the rollback undoes all the updates done to this instance since the instance file was created. Previously, the rollback command incorrectly initialized the Stream Sequence Number fields in the instance file header resulting in REPLINSTDBSTRM errors from the next source server startup command. The workaround for this issue was to repeat the rollback after which the source server startup worked fine. [UNIX] (GTM-7371)

The Receiver Server avoids redundant FETCHRESYNC ONLINE ROLLBACKs. In V5.5-000, the Receiver Server, in some rare cases, did not wait for the Update Server to acknowledge an ONLINE ROLLBACK and could therefore perform multiple ONLINE ROLLBACKs, all but one of which were redundant. Note that although this could cause a momentary hiccup in replication throughput, the extraneous rollbacks could not cause any damage. [UNIX] (GTM-7378)

With NOBEFORE_IMAGE journaling, at an EPOCH, GT.M does not flush global or journal buffers from memory to secondary storage or invoke file system hardening with an fsync system call. Previously, GT.M used flushing and fsync at an EPOCH for all types of journaling, even though they did not add value for NOBEFORE_IMAGE journaling, and unnecessarily limited performance for that mode of journaling. [UNIX] (GTM-7383)

MUPIP ENDIANCVT now correctly recognizes directory tree leaf blocks. Previously, if a such a block lay at an offset approximately 4GB past the beginning of the database file and contained only one record, ENDIANVCT would incorrectly identify it as global variable tree block. ENDIANCVT would therefore leave the block pointer value unconverted, causing a subsequent MUPIP INTEG to fail. [UNIX] (GTM-7390)

MUPIP JOURNAL RECOVER or ROLLBACK handles abnormally terminated journal files (for example, system crash) much more efficiently. Previously, in these scenarios, it could expend more effort than needed in the backward processing phase trying to figure out the last valid record in the journal file. There was no correctness issue. It just look longer to run than it needed to. [OpenVMS] (GTM-7393)

MUPIP SET -PARTIAL_RECOV_BYPASS resets the file_corrupt flag in the database file header. In V5.5-000, this command, in some rare cases, did not reset the file_corrupt flag thereby leading to operational inconvenience. [UNIX] (GTM-7396)

MUPIP JOURNAL ROLLBACK plays forward NULL journal records (usually created by replication filters) with the correct journal sequence number (and stream sequence number if any). Previously the replay wrote NULL journal replacement records with a different journal sequence number than the original records causing various issues including for example the source server issuing incorrect REPLBRKNTRANS errors while replicating. (GTM-7398)

If any errors occur during Source Server startup (like REPLINSTFMT), the error handling logic appropriately cleans up IPC resources. Previously. errors during Source Server startup left IPC resources around unnecessarily complicating subsequent operation. [UNIX] (GTM-7401)

GT.M correctly maintains the KILLs in Progress and Abandoned KILLs counters (displayed by DSE DUMP -FILE) when a KILL command encounters an error. Previously, if a KILL command encountered an error, say a GBLOFLOW, it could increment the counter for one region and decrement the counter in another region, where one or both of the regions might not have held the argument of the KILL, resulting in subsequent inappropriate INTEG errors in one or two regions. (GTM-7402)

MUPIP REORG -TRUNCATE appropriately handles a rare concurrency conflict. Previously, due to rare concurrent circumstances, it could fail with a GTMASSERT2 error.

	Caution
	In V5.5-000 and V6-0.000, GT.M has a known limitation that it does not detect concurrent MUPIP BACKUP and MUPIP REORG -TRUNCATE and so doing can produce a defective backup that has integrity errors.

[UNIX] (GTM-7444)

DSE and LKE start even when another process holds a resource needed to connect to existing shared memory associated with the database. They do this by bypassing the logic used to gain control of the shared resource after a wait of 3 seconds. This does not work if they cannot determine that the shared memory has been properly initialized which they know if there are at least two attached processes. When DSE and LKE bypass the resource control, they also skip resource cleanup when they exit. This means you need to do a MUPIP RUNDOWN to clean up the resources if the bypassing process becomes the last process using the database shared memory to detach as they exit. Previously DSE and LKE could hang waiting for an unavailable shared resource. Note that if DSE and LKE do not start with a bypass, they may still hang on exit if they find the shared resource unavailable, but because they can be presumed to have completed their task(s), this should not pose a significant problem. [UNIX] (GTM-4053)

The OpenVMS distribution kits include a README.txt file which clarifies license related text in the header of each source file and its relationship to the COPYING file. Previously, the kit did not provide this information. [OpenVMS] (GTM-4820)

The Open Source release of GT.M places the GT.M encryption plug-in shell scripts in the plug-in directory. Previously the build Makefile did not copy the encryption plug-in scripts and routines into the documented locations. (GTM-7071)

For the GDE operations involving null subscripts (including add, change and template), when the -null qualifier is set as a distinguishable prefix of one of the following five strings: 'always','true','never','false' or 'existing', (e.g. -null=exist), the GDE processes the null subscripts in the same way as setting the -null qualifier as the complete string (e.g. -null=existing). Previously, if the -null qualifier was set as a distinguishable prefix of one of the above five strings, the GDE always set the null subscripts as "NEVER". (GTM-7184)

In operator log messages from GT.M, the facility starts with "GTM-" followed by a component designation, and, if there is an Instance File or Replication Journal Pool present, another dash and the instance name, as shown in the following table:

In prior releases, the facility was just "GTM". [UNIX](GTM-7219)

The gtmsecshr wrapper validates permissions on the gtmsecshrdir directory and gtmsecshr executable. Previously, the gtmsecshr wrapper did not validate these permissions, leading to a local root shell vulnerability. FIS previously supplied a revised gtmsecshr with this change for use with prior versions. [UNIX] (GTM-7312)

DSE CACHE -VERIFY avoids inappropriate cache verification messages. Previously, in certain rare cases, DSE CACHE -VERIFY incorrectly reported transient control structure problems. [UNIX] (GTM-7338)

GDE SHOW -COMMAND consistently displays the correct value for the NULL_SUBSCRIPTS setting JOURNAL BUFFER_SIZE. Previously, it displayed the corresponding values for the template rather than the region. (GTM-7348)

The gtmstart, gtmstop and gtcm_run scripts follow the convention for executable scripts and explicitly invoke the Bourne shell on the very first line. Previously, these scripts ran in the calling shell which may not be Bourne shell compatible. [UNIX] (GTM-7403)

The gtminstall.sh installation script creates a new configure.sh each time it runs. Previously, repeated executions of gtminstall.sh from the same directory incorrectly duplicated the installation commands in configure.sh. [UNIX] (GTM-7405)