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. Nested TP transactions now guard against a possible rare spurious conflict in internal representation. In previous versions of GT.M, in very rare cases nested TP transactions could fail with a TPFAIL or GTMASSERT error and also cause database damage. (S9I07-002693)

GDS Block Certification is a debugging feature that can currently be turned on by a VIEW "GDSCERT":1 command. This causes GT.M to verify the integrity of the block after every update. This feature now works correctly for TP transactions that do both SETs and KILLs of globals inside the same transaction. In previous versions of GT.M, in rare cases this could incorrectly fail with a GTMASSERT error.

If a runtime error occurs in the midst of committing a transaction, GT.M prints the error code in the DBCOMMITCLNUP message sent to the syslog (operator log in VMS). Previous versions of GT.M sent a DBCOMMITCLNUP message which did not contain the error code. (S9I09-002701)

The update process issues "Number of transactions from Primary which did NOT update JNLSEQNO on Secondary is xxx" message whenever it applies updates from the primary to non-replicated databases on the secondary. Previously such updates caused a "Secondary ahead of Primary by xxx" message in the update process log. Both new and old versions provide one such message for every such unreplicated transaction. (S9I11-002712)

The MM database access method is again an option on UNIX editions of GT.M. This access method bypasses the BG buffer pool and relies entirely on the operating/file system to manage traffic between memory and disk. Because with MM, GT.M has no control over the timing of disk updates, before-image journaling is not an option with MM; attempts to use these two facilities together produce an error. MM has been a continuing option on VMS, where it can provide improved performance for smaller regions with lower volatility (such as code tables). However on UNIX systems, the benefits proved so marginal that it was not used, Fidelity ceased testing it and it was not properly maintained. As UNIX file systems improved and GT.M replication has become more common, we found real benefit in reviving support for the MM option as it can provide a modest performance improvement under a range of circumstances. [UNIX] (C9904-001024)

The logical names GTM_TPRESTART_LOG_FIRST and GTM_TPRESTART_LOG_DELTA now reliably control the frequency of logging of TPRESTART messages. GTM_TPRESTART_LOG_FIRST indicates the number of TP restarts to log after GT.M invocation. Once GT.M has logged that number of TP restarts, it logs one such message, for every GTM_TPRESTART_LOG_DELTA TP restarts. Previous versions of GT.M occasionally used different values for the two parameters than those the user had specified in the logical name, causing unintended logging behavior. [VMS] (C9B11-001824)

The GT.CM GNP server now guards against external signals (including MUPIP STOP) interrupting it while it is in the middle of running down the database on behalf of a client process by deferring the signal handling until the database rundown is complete. Previously, the server attempted to handle the signal right away and would try to rundown the database already in the process of being rundown resulting in SIG-11 (UNIX) or ACCVIO (VMS) errors. (C9E02-002509)

GT.M manages shared resources through the use of shared memory. As processors, caches, and multi-processor interconnects have evolved, computer architectures have become more prone to memory update patterns that appear to a reading process in a different order than they do in the code of the updating process (commonly called out-of-order stores). GT.M uses platform specific primitives (commonly called memory barriers) to prevent out-of-order store issues where they pose problems. GT.M adopted memory barriers some time ago in selected places within the database and journal logic. We recently found that the replication code, which is subject to less intense inter-process contention, needs some as well. This release adds a few memory barriers to the receiver server and update process logic to prevent rare out-of-order store related problems including a very rare potential for the primary and secondary databases to become out of sync (although no actual customer or in-house environment has experienced or reported any such issue). The likelihood of encountering this issue is a function of both the particular hardware (different models of the same CPU line may have different characteristics) and the level of contending activity. [AIX, HP-UX HPPA, HP-UX Itanium, Tru64, OpenVMS] (C9E04-002588)

GT.M now handles MUPIP STOPs appropriately even if it is cleaning up after a TP transaction. In previous versions, MUPIP STOP of a GT.M process that is cleaning up after a TP transaction could cause it to abnormally terminate with SIG-11 (ACCVIO in VMS) errors. (C9E11-002660)

Whenever GT.M does a cache recovery (one way of triggering this is by DSE CACHE -RECOVER), it now waits appropriately for all concurrent writer processes to complete before proceeding with manipulating the shared memory structures. Previous versions had some timing issues in the wait logic which in very rare situations could result in GTMASSERT errors. (C9I03-002973)

Databases created by any GT.M V5 version no longer require MUPIP REORG -UPGRADE when upgrading to GT.M V5.3-003. Previously, upgrading from a pre-V5.3-000 GT.M version to V5.3-000 or higher version would cause periodic DBVERPERFWARN2 messages to show up in the syslog (operator log in VMS) until a MUPIP REORG -UPGRADE was run on that database. (C9I05-002987)

On UNIX systems, the replication source server can now compress the journal records before sending them across in the replication stream. The receiver process detects whether the incoming records are compressed, and if so, decompresses these journal records before placing them in the receive pool. [UNIX] (C9I08-003020)

GT.M journaling now recovers more gracefully from additional runtime errors. If the control structures in the journal buffer (in database shared memory) get set to invalid values (such as an unanticipated out-of-design condition), GT.M journal buffer flushing logic now detects this situation and ensures that journaling gets turned OFF by one and only one process. In previous versions of GT.M, more than one process could attempt to turn journaling off at the same time. While in UNIX this was not an issue, in VMS this would cause every process except for the first one to terminate abnormally with a GTMASSERT error. [VMS](C9I08-003022)

GT.M now correctly handles situations in MM access mode when extending database files. In V53002 it was possible for a file extension in MM access mode to result in GTMASSERT failures. [UNIX](C9I08-003025)

In VMS, GT.M journaling logic now waits appropriately (a maximum of 2 minutes) for GT.M and the file system to flush the journal buffers in database shared memory to the journal file on disk even in the case where there is no other process doing the journal flush. Prior versions of GT.M, in these cases, could occasionally terminate prematurely with a GTMASSERT error without giving the writes adequate time to happen. [VMS] (C9I10-003045)

GT.M now correctly handles VIEW "NOISOLATION" commands even in the case the global names specified involve different regions (in one or more global directories) that map to the same database file. In rare situations, GT.M V5.3-001A and V5.3-002 did not handle this properly and could terminate with SIG-11 (ACCVIO in VMS) errors. (C9I11-003055)

GT.M now does a timely flush (one second unless a longer delay is specified) of the journal file to disk when used with the MM access method. Previous versions could wait more than 4 minutes after starting a timer before flushing the file. [UNIX] (C9I11-003056)

Database file extension for MM database files requires standalone access with MUPIP on the HP-UX PA-RISC platform, whereas on other UNIX/Linux platforms where GT.M now supports MM allow for automatic extension during use, as they do for database using the BG access method. On the HP-UX PA-RISC platform, GT.M now returns a GBLOFLOW error rather than extending an MM database during normal use. It previously returned the generic, and less meaningful, DBFILERR message. [HP-UX PA-RISC] (C9I12-003058)

$VIEW("GVSTATS", <region>) now records SET operations even if they are inside TP transactions. For details on all the statistics recorded, see C9I09-003044. (S9709-000529)

A GT.M process on OpenVMS will occasionally terminate on receipt of a MUPIP INTRPT. The probability of process termination appears to depend on how likely the process is to be processing an error or a transaction restart. As far as we can determine, the failure appears to be limited to the process receiving the interrupt without database damage or other issues. Given the impact of the issue, and the effort to fix it (which would involve the use of different operating system facilities that are believed to be more robust than the facilities used by GT.M), FIS does not intend to address this in the foreseeable future. [OpenVMS] (S9E08-002477)

GT.M, DSE, MUPIP, LKE properly handle external UNIX signals while writing to any device or file. In previous versions of GT.M, in rare cases, using a MUPIP STOP or Ctrl-C (for example) to interrupt a DSE DUMP BLOCK or MUPIP REORG command while output was being written to the terminal would cause an indefinitely repeating sequence of the same messages. Although this had been observed only during terminal writes, this could also have occurred during writes to a file. [UNIX] (S9H05-002657)(S9I10-002706)

GT.M now uses a “wrapper” to guard gtmsecshr. The wrapper starts gtmsecshr in a clean environment and allows gtmsecshr to have permissions such that a non-root user can’t access it except though the mechanism used by the wrapper. This is an enhanced version of the mechanism described in the security bulletin of 23 October 2008. The subsections below describe other changes (applied to UNIX unless otherwise specified) that accompany this change. In prior versions, gtmsecshr resided in the main distribution directory and other GT.M components started gtmsecshr directly. [UNIX] (S9I10-002703)

Invoking the $ZJOBEXAM() function at process startup no longer causes GT.M to abnormally terminate with a "Segmentation fault" or "SIG-11" (ACCVIO in VMS) error. (S9I11-002713)

GT.M now restricts the maximum message length limit for the DISTPATHMAX error to 1024 bytes across all platforms. Previously it allowed a much higher limit on Linux. [Linux] (S9I10-002703)(C9B11-001783)

The update process now writes out dirty buffers when it is idle (when the backlog on the receiver side is zero). (C9G01-002769)

GT.M V5.3-003 provides support for a new PIPE device on the UNIX/Linux platforms as a mnemonic space device. An OPEN of the device starts a sub-process. Data written to the device by the M program is available to the process on its STDIN. The M program can read the STDOUT and STDERR of the sub-process. This facilitates output only applications, such as printing directly from a GT.M program to an lp command; input only applications, such as reading the output of a command such as ps; and co-processing applications, such as using iconv to convert data from one encoding to another. Refer to the PIPE IO Technical Bulletin for details. [UNIX] (C9H05-002859)

GT.M now again reports error context correctly on x86 and x86_64 Linux. A change made in V5.2-001 could cause misreporting for certain limited kinds of address/location context. As the misreporting was typically confined to fatal errors, the potential impact would have been minimal. [Linux x86 and x864_64] (C9I08-003016)

GT.M now detects end-of-line when the source line contains a string literal missing its closing quote. In addition, this change moves the LITNONGRAPH warning to the conventional place after the source line display in stead of before. The changes for S9I07-002688 in V5.3-002 caused GT.M to miss the end-of-line in this case and produce many inappropriate errors and warnings. (C9I09-003032)

GT.M now properly handles the negation of an undefined variable. Starting with version V5.3-001, negation of an undefined variable caused a SEG-V (SIG-11 on UNIX, and an ACCVIO on VMS)(C9I09-003041)

GT.M now provides per-process statistics for database and LOCK-related operations. Previously similar statistics accumulated since file creation were only available using $VIEW("GVSTATS",<region>) or DSE on a database region. The file statistics have been adjusted to better align with the process statistics. DSE now has a facility to reset the file statistics. (C9I09-003044)

The ZSHOW command supports a new information code "G" that displays statistics for each type of global variable access done by the current process for each database file that it has open. The statistics reflect the total activity since the process startup. Each database file's statistics are prefixed by the full pathname of the global directory and region to which they correspond. In addition, a line containing aggregated statistics (across all database files) displays with a prefix of * for the global directory and region name.

The counts are displayed in the following order in a comma-separated list where each statistic has its mnemonic followed by a colon and the count. The characters used to arrive at each mnemonic are highlighted in upper-case in the corresponding description. The usage TP applies those database operations that are surrounded by a TSTART/TCOMMIT. The usage non-TP applies other operations, also called "mini-transactions."

• SET : # of SET   operations (TP and non-TP) 
• KIL : # of KILl  operations (kill as well as zwithdraw, TP and non-TP) 
• GET : # of GET   operations (TP and non-TP) 
• DTA : # of DaTA  operations (TP and non-TP) 
• ORD : # of ORDer operations (TP and non-TP) 
• ZPR : # of ZPRevious (reverse order) operations (TP and non-TP) 
• QRY : # of QueRY operations (TP and non-TP) 
• LKS : # of LocK calls (mapped to this db) that Succeeded 
• LKF : # of LocK calls (mapped to this db) that Failed 
• CTN : Current Transaction Number of the database for the last committed read-write transaction (TP and non-TP) 
• DRD : # of Disk ReaDs from the database file by this process (TP and non-TP, committed and rolled-back) 
• DWT : # of Disk WriTes to the database file by this process (TP and non-TP, committed and rolled-back) 
• NTW : # of Non-tp committed Transactions that were read-Write on this database 
• NTR : # of Non-tp committed Transactions that were Read-only on this database 
• NBW : # of Non-tp committed transaction induced Block Writes on this database 
• NBR : # of Non-tp committed transaction induced Block Reads on this database 
• NR0 : # of Non-tp transaction Restarts at try 0 
• NR1 : # of Non-tp transaction Restarts at try 1 
• NR2 : # of Non-tp transaction Restarts at try 2 
• NR3 : # of Non-tp transaction Restarts at try 3 
• TTW : # of Tp committed Transactions that were read-Write on this database 
• TTR : # of Tp committed Transactions that were Read-only on this database 
• TRB : # of Tp read-only or read-write transactions that got Rolled Back (incremental rollbacks are not counted) 
• TBW : # of Tp transaction induced Block Writes on this database 
• TBR : # of Tp transaction induced Block Reads on this database 
• TR0 : # of Tp transaction Restarts at try 0 (counted for all regions participating in restarting tp transaction) 
• TR1 : # of Tp transaction Restarts at try 1 (counted for all regions participating in restarting tp transaction) 
• TR2 : # of Tp transaction Restarts at try 2 (counted for all regions participating in restarting tp transaction) 
• TR3 : # of Tp transaction Restarts at try 3 (counted for all regions participating in restarting tp transaction) 
• TR4 : # of Tp transaction Restarts at try 4 and above (restart counted for all regions participating in restarting tp transaction) 
• TC0 : # of Tp transaction Conflicts at try 0 (counted only for that region which caused the tp transaction restart) 
• TC1 : # of Tp transaction Conflicts at try 1 (counted only for that region which caused the tp transaction restart) 
• TC2 : # of Tp transaction Conflicts at try 2 (counted only for that region which caused the tp transaction restart) 
• TC3 : # of Tp transaction Conflicts at try 3 (counted only for that region which caused the tp transaction restart) 
• TC4 : # of Tp transaction Conflicts at try 4 and above (counted only for that region which caused the tp transaction restart)

The use of comma-separated pieces allows for future releases of GT.M to provide additional data while facilitating upward compatibility of application code. Since FIS reserves the right to change the order in which statistics are reported in future versions of GT.M, application programs should use the names (mnemonics) when picking pieces from the string instead of relying on field position or ordering.

$Order(xxx,1) operations get recorded under the ORD category while $Order(xxx,-1) operations get reported under ZPR.

The DWT statistic in the ZSHOW "G" output always reports 0 for databases that use the MM (memory-mapped) access method as this has no real meaning in that mode.

KILL/GET/DATA/QUERY/ORDER/ZPREVIOUS operations on globals that never existed are not counted (nor were they previously) while the same operations on globals that once existed but have since been killed are counted (as they were previously).

Name-level ORDER/ZPREVIOUS operations (for example, $ORDER(^a) with no subscripts) increment the count for each transition into a region as they process the global directory map up to the point they find a global with data (as they were previously).

Data for M locks refers to M locks mapped to the shared memory of a database file. If "local" M locks are mapped to a file, the data for M locks includes these local locks.

These statistics report on global variable operations performed by a process. If an operation is performed inside a TP transaction, and not committed as a consequence of a rollback, or an explicit or implicit restart, GT.M still counts it.

If two or more regions (in the same or different global directories) map to the same physical database file, the ZSHOW "G" reports identical statistics for those two regions, but counts them only once towards the aggregated statistics across all database files in the line beginning with GLD:*,REG:*.

The aggregated statistics line in the ZSHOW "G" output (GLD:*,REG:* line) always reports the value for the CTN category as 0 because this statistic makes sense only for individual database files.

ZSHOW "G" reports process private global access statistics only for regions whose corresponding segments have an access method of BG or MM in the global directory. For regions with other access methods, for example GT.CM GNP, which maps a region/segment to a remote database file, ZSHOW "G" does not report any process private statistics even though aggregated statistics (across all processes) will continue to be gathered in the remote database file header.

Processes with read-only access to the database have their global access statistics counted in the database file header as long as the last process to shut down the database has read-write access.

The counters are 8-byte quantities (can get as high as 2**64). If these counters exceed 18 decimal digits (somewhere between 2**59 and 2**60), which is the current GT.M numeric representation precision threshold, their use in arithmetic expressions in GT.M results in loss of precision.

As an example of use for this enhancement: during a benchmark, a process can make periodic commands to ZSHOW "G" and store the returned strings in a local variable - a fast storage mechanism in GT.M - for subsequent analysis.

Alternatively, since the $ZJOBEXAM() function by default does a ZSHOW "*" which in turn automatically includes the "G" information code, invoking MUPIP INTRPT commands periodically on a particular process will now cause it to additionally record all global access statistics in the $ZJOBEXAM dump file.

The following examples use 0 values for all counters.

Assuming that a GT.M process uses the global directory "/tmp/x1.gld" and opens two regions REG1 and REG2 corresponding to two database files, the output of a ZSHOW "G" command performed before any database operation appears as follows.

GLD:*,REG:*,SET:0,KIL:0,GET:0,DTA:0,ORD:0,ZPR:0,QRY:0,LKS:0,LKF:0,CTN:0,DRD:0,DWT:0,NTW:0,NTR:0,NBW:0,NBR:0,NR0:0,
NR1:0,NR2:0,NR3:0,TTW:0,TTR:0,TRB:0,TBW:0,TBR:0,TR0:0,TR1:0,TR2:0,TR3:0,TR4:0,TC0:0,TC1:0,TC2:0,TC3:0,TC4:0
GLD:/tmp/x1.gld,REG:REG1,SET:0,KIL:0,GET:0,DTA:0,ORD:0,ZPR:0,QRY:0,LKS:0,LKF:0,CTN:0,DRD:0,DWT:0,NTW:0,
NTR:0,NBW:0,NBR:0,NR0:0,NR1:0,NR2:0,NR3:0,TTW:0,TTR:0,TRB:0,TBW:0,TBR:0,TR0:0,TR1:0,TR2:0,TR3:0,TR4:0,
TC0:0,TC1:0,TC2:0,TC3:0,TC4:0
GLD:/tmp/x1.gld,REG:REG2,SET:0,KIL:0,GET:0,DTA:0,ORD:0,ZPR:0,QRY:0,LKS:0,LKF:0,CTN:0,DRD:0,DWT:0,NTW:0,
NTR:0,NBW:0,NBR:0,NR0:0,NR1:0,NR2:0,NR3:0,TTW:0,TTR:0,TRB:0,TBW:0,TBR:0,TR0:0,TR1:0,TR2:0,TR3:0,TR4:0,TC0:0,TC1:0,
TC2:0,TC3:0,TC4:0

The following is the result of a ZSHOW "G":zgbl done by the same process under the same circumstances, redirecting the output of ZSHOW into a local or global variable.

zgbl("G",0)="GLD:*,REG:*,SET:0,KIL:0,GET:0,DTA:0,ORD:0,ZPR:0,QRY:0,LKS:0,LKF:0,CTN:0,DRD:0,DWT:0,NTW:0,NTR:0,
NBW:0,NBR:0,NR0:0,NR1:0,NR2:0,NR3:0,TTW:0,TTR:0,TRB:0,TBW:0,TBR:0,TR0:0,TR1:0,TR2:0,TR3:0,TR4:0,TC0:0,TC1:0,
TC2:0,TC3:0,TC4:0"
zgbl("G",1)="GLD:/tmp/x1.gld,REG:REG1,SET:0,KIL:0,GET:0,DTA:0,ORD:0,ZPR:0,QRY:0,LKS:0,LKF:0,CTN:0,DRD:0,DWT:0,
NTW:0,NTR:0,NBW:0,NBR:0,NR0:0,NR1:0,NR2:0,NR3:0,TTW:0,TTR:0,TRB:0,TBW:0,TBR:0,TR0:0,TR1:0,TR2:0,TR3:0,TR4:0,
TC0:0,TC1:0,TC2:0,TC3:0,TC4:0"
zgbl("G",2)="GLD:/tmp/x1.gld,REG:REG2,SET:0,KIL:0,GET:0,DTA:0,ORD:0,ZPR:0,QRY:0,LKS:0,LKF:0,CTN:0,DRD:0,DWT:0,
NTW:0,NTR:0,NBW:0,NBR:0,NR0:0,NR1:0,NR2:0,NR3:0,TTW:0,TTR:0,TRB:0,TBW:0,TBR:0,TR0:0,TR1:0,TR2:0,TR3:0,TR4:0,TC0:0,
TC1:0,TC2:0,TC3:0,TC4:0"

The $VIEW("GVSTATS",<region-name>) intrinsic function continues to return the global access statistics across all processes, but with a change in its output format. It displays statistics in the same format as the ZSHOW "G" command as illustrated below.

New output:

SET:0,KIL:0,GET:0,DTA:0,ORD:0,ZPR:0,QRY:0,LKS:0,LKF:0,CTN:0,DRD:0,DWT:0,NTW:0,NTR:0,NBW:0,NBR:0,NR0:0,NR1:0,NR2:0,
NR3:0,TTW:0,TTR:0,TRB:0,TBW:0,TBR:0,TR0:0,TR1:0,TR2:0,TR3:0,TR4:0,TC0:0,TC1:0,TC2:0,TC3:0,TC4:0

Old output:

SET:0,KIL:0,GET:0,ORD:0,QRY:0,ZPR:0,DTA:0,RT0:0,RT1:0,RT2:0,TP0:0,TP1:0,TP2:0,TP3:0,TP4:0,TP5:0,TP6:0,TP7:0,
TP8:0,TP9:0,TP::0,TP;:0,TC0:0,TC1:0,TC2:0,TC3:0,TC4:0,TC5:0,TC6:0,TC7:0,TC8:0,TC9:0,TC::0,TC;:0

The DSE DUMP -FILE -ALL command prints the global access statistics across all processes for the same categories as those reported for the process private global access statistics. It now lists it counters in the same order as $VIEW("GVSTATS",<region>), except for the CTN category, which appears as part of the basic DSE DUMP -FILE output.

All ZSHOW "G" and $VIEW("GVSTATS",<region>) statistics display in DECIMAL while DSE DUMP -FILE -ALL statistics display in HEXADECIMAL (as they did previously).

ZSHOW "*" is now equivalent to ZSHOW "IVBDLGSC" so ZSHOW "G" output appears after ZSHOW "L" output and before ZSHOW "S" output.

The VIEW "RESETGVSTATS" command resets all the process-private global access statistics to 0. This is particularly useful for long running processes which would periodically like to restart the counting without requiring a shut down and restart.

The DSE CHANGE -FILE -GVSTATSRESET command resets all the database file header global access statistics to 0. Note that this erases all statistics previously accumulated in the database file header.

ZSHOW "L" now displays the following additional M-lock statistics in one line just before its current output.

• MLG : # of M Lock commands Granted 
• MLT : # of M Lock commands Timed-out

Suppose a process runs LOCK (^SUCCESS1,^SUCCESS2) which succeeds and a LOCK +^FAIL:1 which times out due to another process holding that lock. A ZSHOW "L" at this point displays the following output.

MLG:1,MLT:1
LOCK ^SUCCESS1 LEVEL=1
LOCK ^SUCCESS2 LEVEL=1

	Note that even though two lock resources ^SUCCESS1 and ^SUCCESS2 were specified in the LOCK command that succeeded, GT.M increments the MLG counter by only 1 because they are part of the same LOCK command. A ZSHOW "L":var by the same process (redirecting the output of ZSHOW into a local or global variable) would result in <var> holding the following contents.

var("L",0)="MLG:1,MLT:1"
var("L",1)="LOCK ^SUCCESS1 LEVEL=1"
var("L",2)="LOCK ^SUCCESS2 LEVEL=1"

For every user level lock request, GT.M increments the MLG or MLT statistic for the ZSHOW "L" output. Every user level lock request in turn translates to one or more calls to the database lock code (depending on the timeout and the number of lock names specified in the same lock command) which increments the LKS and/or LKF statistics of the ZSHOW "G" output appropriately.

MUPIP ENDIANCVT now preserves the global statistics as part of endian converting the database file whereas previously it used to reset them to 0.

MUPIP LOAD FORMAT=ZWR now handles decimal number values correctly. In prior versions it reported a format error for numerics containing a decimal and skipped records with such values. The workaround was to use %GI. (S9I07-002691)

%GO now includes a UTF-8 stamp in the label of its output. In prior versions it omitted this indicator. The workaround was to add the indicator by editing the extract file.

MUPIP online BACKUP now releases locks on all the previous regions, before waiting for KILL(s) to complete. MUPIP BACKUP on multiple regions used to hold locks on all the previous regions, in the region list, while waiting for ongoing KILL(s) command(s) to complete on a region. (S9H12-002672)

GT.M properly handles MUPIP STOPs while opening a journaled database. In previous versions of GT.M, in rare cases, this could cause the process to get deadlocked and the resolution was to kill -9 this process.[UNIX] (C9903-000942)

A MUPIP STOP issued to a MUPIP JOURNAL process should now reliably trigger a graceful termination. In prior versions, it could occasionally cause the process, to terminate abnormally an ACCVIO error. [VMS] (C9F08-002752)

MUPIP BACKUP and MUPIP INTEG REGION both interact with MUPIP REOROG and with the KILL command somewhat differently. Initiation of an online BACKUP or MUPIP INTEG on one or more REGIONs defers KILLs or REORG actions that free entire blocks until it manipulates the database state to record its start. BACKUP waits for any block-freeing KILLs or in progress REORG actions to complete. MUPIP BACKUP now waits for a maximum of one minute across all the regions. MUPIP BACKUP no longer errors out with BACKUP2MANYKILL error; if it waits more than one minute for a clean KILL state, it prints a BACKUPKILLIP warning message and proceeds. INTEG on REGION(S) now waits for any block-freeing KILLs or REORG actions currently in progress to complete; if it waits more than one minute for a clean block state, it gives a warning message and proceeds. If BACKUP or INTEG encounter any ABANDONED_KILLS, they give a warning and proceed. (C9G04-002783)(C9I12-003061)

The startup logic of MUPIP BACKUP or INTEG REGION may defer block-freeing KILLs or REORG actions for a maximum of two (2) minutes after which the KILL logic clears the hold-off flag and proceeds normally. Normally MUPIP BACKUP and INTEG start nearly instantly and clear the hold-off flag immediately.

In addition, work on this issue also changed the mechanism to differentiate between KILLs or REORG actions in progress (doing active cleanup) and abandoned KILLs or REORG actions where the process terminated without completing its cleanup (leaving incorrectly marked busy blocks). When a process that is having KILLs or REORG actions in progress is MUPIP STOP'ed at a stage where it may leave the database blocks in inconsistent state, the process cleanup logic converts the KILLs in progress flag to the abandoned KILLS flag.

Work in this area removed a very slight chance that GT.M could cause OpenVMS to crash (BUGCHECK) if something corrupted memory in certain ways.

DSE CHANGE FILEHEADER can now manipulate flags for ABANDONED_KILLS (in addition to KILL_IN_PROG). DSE DUMP FILEHEADER shows one sum for the combination of KILLs in progress and abandoned KILLs, but DUMP FILEHEADER ALL shows them separately. DSE can also examine and modify the INHIBIT_KILLS flag.

Previously neither MUPIP REORG nor KILL would hold off to let BACKUP and FREEZE actions start, and GT.M did not differentiate between KILL in progress and abandoned KILL, where both include the “virtual” KILLs performed by MUPIP REORG in moving data to more optimal places.

Backward journal recovery (MUPIP JOURNAL RECOVER or ROLLBACK -BACKWARD) after an abnormal termination of the database now runs faster, especially for large databases. MUPIP achieves this by avoiding bit map reads. In previous versions of GT.M, recovery used to read ALL the local bitmaps of the database multiple times in order to fix certain fields in the file header. (C9H09-002906)

MUPIP ENDIANCVT no longer issues "wc_blocked is set - rundown needed" and "the database is frozen" messages. Instead it resets the corresponding fields in the file header and proceeds with the conversion. Additionally, it supports a new -OVERRIDE qualifier which if specified will enable it to proceed with the conversion is long as it had only issued one or more of these errors: [UNIX] (C9I06-002996)

The OVERRIDE qualifier has no effect for database fields whose state indicates serious issues that endanger the success of the conversion process (for example fields that indicate the database has integrity errors etc.).

MUPIP FREEZE defers KILLs that free entire blocks until the database state reaches a consistent state suitable for a FREEZE. FREEZE waits for any block-freeing KILLs currently in progress to complete; if it waits more than one (1) minute for a clean KILL state, it gives an error and terminates marking unfrozen any of the regions that were it had previously marked frozen. (C9I06-002997)

The replication instance file format changed in GT.M V5.3-003. Therefore, you must recreate all replication instance files when installing this version of GT.M. If GT.M encounters an old instance file, it reports a REPLINSTFMT error. Additionally, GT.M reports a REPLINSTFMT error whenever it encounters: a) an instance file created on a different endian system or b) an instance file created by a 32-bit (or 64-bit) version of GT.M differing from the current 64-bit (or 32-bit) version of GT.M. [UNIX] (C9I08-003021)

MUPIP CREATE now creates appropriately sized database files. In previous versions of GT.M, it could occasionally try to write out much more data than a local bitmap block can hold causing it to abnormally terminate with SIG-11 and/or IO related errors. [UNIX] (C9I11-003053)

GT.M now processes forward recovery while using the MM access method properly. In rare situations, previous versions could incorrectly return a DBTNTOOLRG error erroneously. [UNIX] (C9I11-003054)

GT.M now gives valid results for the SHOW and VERIFY options of the DSE CACHE command when using the MM access method. Previous versions did not use the MM specific internal structures for the cache and could return incorrect information.

GT.M now properly initializes the default value to NOBEFORE image journaling when running with the MM access method, and journaling characteristics have not been previously specified. Previous versions could have a default value of BEFORE image journaling with MM, leading to potential conflicts with other journaling attributes and resulting in an MMBEFOREJNL error.

GT.M now correctly handles MUPIP REORG for the MM access method. In previous versions the MUPIP process would occasionally terminate with a SIGMAPERR. [UNIX] (C9I12-003059)

The replication source server, receiver server and MUPIP JOURNAL -ROLLBACK -FETCHRESYNC now correctly handle two kinds of errors at connection establishment time. (C9I12-003060)

The MUPIP REPLIC /RECEIV /START command now issues a proper error message if it is unable to start update helper processes. Previous versions could abnormally terminate with an ACCVIO error. [OpenVMS]

When LKE encounters an error while opening the file specified in the -OUTPUT qualifier of a command (say because of permission issues), it now reports the cause of the error. Previous versions printed only a "Cannot create <filename>" message without accompanying detail.

V5CBSU (a utility program that is used during a V4 to V5 GT.M database migration) now operates as described below. (S9I09-002700)

The GT.M installation now offers to give ownership of the distribution to a particular group, and, if this is option chosen, restricts access to the distribution to the designated group. Previously you could put such a restriction in place after the installation, but this makes a security related option more convenient. [UNIX] (C9I10-003048)