GT.M V5.3-002 — 64-bits on x86_64 Sun SPARC Solaris

GT.M journaling logic now recovers from additional runtime errors. If the control structures in the journal buffer (in database shared memory) get set to invalid values (such as unanticipated, out-of-design condition), GT.M journal buffer flushing logic detects this situation, turns OFF journaling right away and sends appropriate messages to the syslog (operator log in VMS). Subsequent updates to the database continue to work without any issues. Previous versions of GT.M used to hang for minutes trying to recover from this situation and terminate unlucky processes abnormally with GTMASSERT errors. In addition, processes could try writing to non-allocated portions of the journal file, which in turn caused a flood of JNLACCESS messages in the operator log. (S9D11-002394, S9I07-002690)

This release includes a field test grade implementation of the MM (Mapped Memory) database access method for UNIX/Linux. The OpenVMS editions of GT.M previously supported MM and continue to do so unchanged. The MM access method maps database files (with the mmap() system call) to the address space of all processes accessing the corresponding MM region, thereby using the operating system to manage traffic between memory and disk rather than using the global buffer pool as in the Buffered Global (BG) access method. Note that before image journaling and backward recovery require that before-image journal records be committed to disk before the corresponding database updates are committed. Since this is not possible with MM, before-image journaling, and consequently mupip backward recovery/rollback to recover a database without a restore are not available with MM. Attempts to use MM with before image journaling produce an error. The MM access method supports nobefore_image journaling and mupip forward recovery, as well as mupip journal rollback with the -resync or -fetchresync qualifiers to generate lost and broken transaction files. The implementation of MM on UNIX/Linux allows databases to extend dynamically, as they do with BG; as before, the implementation of MM on OpenVMS does not permit dynamic database file extension. The MM access method may provide a performance advantage in situations where its restrictions are acceptable. Although we do not yet recommend this feature in production (the next GT.M release will make MM fully Supported), we encourage you to try it in appropriate development, testing and benchmarking environments and to tell us how it works for you – especially about any issues you encounter and any performance gain you experience. Note that the field test designation refers only to the new MM access method for UNIX/Linux. V5.3-002, including MM for OpenVMS, is a fully tested and qualified, production grade GT.M release that is at least as robust as, if not more robust than, any previous GT.M release. [UNIX] (C9904-001024)

The Linux version of GT.M can now utilize O_DIRECT support for journal files. The O_DIRECT option is made available by using the sync_io option to the MUPIP SET -JOURNAL command just as for the other platforms that support direct I/O. [Linux] (C9D10-002409)

The 'VIEW "FLUSH"' (originally introduced in V5.0-000), now always flushes all dirty buffers from the global buffer pool. Previous versions might only do a partial flush. (C9E02-002525)

GT.M now correctly maintains the database file corresponding to $REFERENCE even in case of runtime errors during TCOMMIT or ZTCOMMIT where those transactions reference multiple regions. In previous versions, GT.M maintained $REFERENCE correctly but could leave it associated with an incorrect database file. This meant that if the next global reference inside of the error-trap routine is the same as $REFERENCE at the time of the runtime error, GT.M could return incorrect values and/or report false errors (for example, it could report GVUNDEF errors on a global node that existed). (C9F03-002709)

GT.M now performs database commits in two phases. Phase 1 consists primarily of transaction (TP or mini/non-TP) validation and journal management while the process holds the critical section on the database region. Phase2 performs the actual block updates under block locks after the release of the region critical section. By reducing the per-transaction time that a transaction holds the region critical section, this change improves database transaction throughput under conditions of contention. In prior versions GT.M did all transaction commit work while holding the critical section.

GT.M now better maintains database integrity throughout a database update operation even when it encounters an error in the middle of committing the update. Prior versions used to complete the database commit operation under these unusual circumstances, but in cases such as where the error occurred in the middle of a TP transaction that did KILLs of globals, it could result in a variety of errors including database structural damage.

GT.M now better protects against abnormal process termination. Previous versions of GT.M could in very rare cases issue GVxxxFAIL or TPFAIL errors if one or more other processes terminated abnormally or were stopped using a MUPIP STOP.

GT.M now writes correct checksums in the journal file. 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. Similar issues were fixed in GT.M V5.0-000D as part of C9F10-002762 and in GT.M V5.3-000 as part of C9B11-001813 but there were a few very rare cases that were not. These are now fixed.

GT.M now works more correctly when VIEW "GDSCERT" is turned on. In previous versions, in rare cases it was possible to get GTMASSERT errors when VIEW "GDSCERT" was turned on with TP transactions and a high contention in the database (for example, with MUPIP REORG concurrently running).

MUPIP INTEG -REGION works correctly when a MUPIP SET -VERSION or MUPIP REORG UPGRADE/DOWNGRADE runs at the same time. In previous V5 versions, in rare cases it could incorrectly issue a DBTNNEQ error.

DSE MAPS -RESTORE now works correctly when the total blocks in the database file is a multiple of 512. Previously, it could cause either of two kinds of benign database structural damage: free blocks counter in file header incorrect, or DBMBPINCFL errors where Master bit map incorrectly marks this local map full. Similar issues existed for MUPIP JOURNAL RECOVER/ROLLBACK and were fixed in GT.M V5.3-001 as part of C9H10-002923.

DSE DUMP -FILE now prints a new field in the file header "Commit Wait Spin Count". When a GT.M process must wait for another process to complete its update on a particular block, it does a sequence of CPU spins followed, if still unsuccessful, by a yield of the CPU. The spin reduces unnecessary time spent waiting. A process uses this spin/yield sequence as many times as needed until the wait time is approximately 1 minute, at which point it logs an operator message. The new file header field, which has a default value of 16, determines the number of times the waiting process spins before yielding the CPU. DSE CHANGE -FILE now supports a new qualifier -COMMITWAIT_SPIN_COUNT= for modifying the spin_count value. Setting the spin_count to 0 will cause the waiting process to do a sequence of small sleeps instead of the spins or yields. In Tru64 Unix (where the spin_count is displayed in DSE DUMP -FILE) and VMS (where it is not even displayed), the waiting process does unconditional sleeps and therefore the spin_count value is immaterial. The spin_count applies only to Unix databases that have an access method of BG. (C9F06-002736)

GT.M now handles a journal align size of 2GB correctly. In previous versions the size was interpreted incorrectly resulting in a request for a large, negative size; which could result in journal failures. While larger align sizes trade off crash recovery time in favor of increased journaling throughput, especially when before image journaling is in use, there is marginal value in using align sizes larger than a few MB. (C9I03-002972)

GT.M now properly handles certain cases of multiple updates within a TP transaction to a global having the NOISOLATION characteristic. A flaw in the optimization work for C9I01-002938 introduced the potential for a memory access violation (SIG-11) in V5.3-001. Although apparently rare, this case could be dangerous because prior to the failure it could damage shared memory used in managing the database. (C9I05-002989)

Non-TP SET operations on journaled globals now deal appropriately with boundary conditions that very rarely coincide with a journal file switch. In previous versions of GT.M, in these very rare cases it was possible for the process doing a SET operation to terminate abnormally with a GTMASSERT error. (C9I07-003007)

GT.M now warns of non-graphic characters in string literals (which are an M standard violation) at compile time, but produces no error at run-time. Such errors are completely ignored within XECUTE arguments and indirection. In previous versions, GT.M treated such constructs as errors in accordance with the standard. (S9D08-002359, S9I07-002688)

Turning off MPROF tracing to write the results to the array now functions correctly. GTM no longer intermittently fails with a signal-11/ACCVIO error in this situation. (S9F06-002552)

GT.M now accepts source lines up to 8192 bytes in length. While FIS does not recommend long lines as a wholesome programming practice, this adds flexibility for those who found the prior length of 2048 bytes too confining, especially for strings used in XECUTE. This change also increases the maximum length of a single line of ZSHOW output. (S9F01-002523)

For characters in Unicode, GT.M assigns patcodes based on the default classification of the Unicode character set by the ICU library with three adjustments:

This is the resulting Unicode general category to M patcode mapping:

For a description of the Unicode general categories see http://unicode.org/versions/Unicode4.0.0/ch04.pdf (section 4.5)

	Even though non-ASCII decimal digits (with $ZPATNUMERIC set to "UTF-8") match patcode N, GT.M does not treat them as digits.

For example:

GTM> w $c($$FUNC^%HD("D67"))?.N ; This is the Malayalam decimal digit 1                            
1
GTM>w 1+$c($$FUNC^%HD("D67"))
1
GTM>w 1+$c($$FUNC^%HD("31")) ; This is the ASCII digit 1
2

Previously, non-ASCII code points from the following Unicode general categories only matched patcode E:

On AIX and Tru64 systems, certain SOCKET reads and replication communication operations no longer use excessive CPU time. [AIX, Tru64] (S9I06-002687)

GT.M now provides an environment variable (or VMS logical) gtm_zquit_anyway, which, if defined to 1 (or case insensitive TRUE or YES), causes the compiler to generate what might be described as paranoid object code for QUITs, turning them into the form of Q:$Q arg Q. In other words, QUIT with an argument if the virtual stack frame was invoked as an extrinsic and without an argument if it was invoked with a DO. If the original code has an argumentless QUIT, GT.M supplies an empty string return value. This has no effect on QUIT from FOR loops, or implicit QUITs, whether at the end of a block or at the end of a routine. At run-time, the value of this setting is available as $ZQUIT and may be SET. Nonetheless the setting is not a run-time setting, but rather a compile-time one, so $ZQUIT has no effect on the behavior existing object code - it only effects code generated by auto-ZLINK or the ZCOMPILE command. This setting has no effect on late bound code such as that in XECUTE arguments, $ETRAP, $ZTRAP device EXCEPTIONS. FIS recommends M standard coding practice of explicitly coding QUITs as they are intended to be used, which avoids the need for this feature and provides useful error checking. (S9I07-002689)

ZPRINT now issues an error if the object and source file names don't match. In prior versions the operation could fail with a memory violation (Signal 11/SEG-V/ACCVIO). (S9I07-002692)

On Solaris, GT.M now operates as a 64-bit application. Henceforth, there are no 32-bit GT.M processes on that platform. GT.M now uses the Solaris libumem package to provide memory allocation in place of the default libc malloc. libumem can provide more predictable memory allocation when using large address spaces.

GT.M now generates somewhat more compact code on the Linux x86_64 platform. [Linux x86_64]

GT.M error messages now include 64-bit contexts where appropriate including adapting between 32- and 64-bit addresses depending on the platform. Previously some context might have either excluded some information or included extra information. As part of this change, DBFHEADERR messages have become either DBFHEADERR4 or DBFHEADERR8 messages, which accept 4-byte and 8-byte context values respectively. (C9D10-002413)

GT.M now handles MEMORY (UNIX) or VMSMEMORY (VMS) out-of-storage events with the following attributes:

Prior versions of GT.M were less graceful in handling these errors, with symptoms including recursive errors, missing or mangled messages and severely limited context for debugging. (C9D12-002471, C9I04-002977)

The SOCKET device now works on HP-UX IA64 11V3. In addition, GT.M now has better error handling for HP-UX SOCKET devices and replication receiver servers. It retries ENOBUFS errors from socket calls before reporting an error, since these may be transient on HP-UX. Previous versions reported ENOBUFS immediately as an error. [HP-UX] (C9I04-002974, C9I04-002975)

In the unusual case where there's no valid error handling in place for an error and the error handler that is ultimately found contains a BREAK command, GT.M now reports the original error and error location before entering direct mode. Previously in such a case, GT.M would report the error condition followed by the BREAK location while the correct error location is recorded in $ZTATUS. This mixed report on entering direct mode was deemed confusing.

The RTSLOC error message now prints the correct M source location. Previously, in case of certain runtime errors (for example, a FMLLSTPRESENT error), the error location reported could be incorrect (one more than the actual location).

While the first two paragraphs of this item (C9I04-002976) apply to all platforms, the next two only apply to the following platforms: Linux Itanium, HPUX Itanium, and HPUX HPPA.

In case the OPEN, USE, READ or WRITE command on an IO device errors out and the current EXCEPTION deviceparameter contains a string that results in a compile error, the location reported in $ZSTATUS is now correct. Previously, it could be one line before the actual location where the IO command was invoked.

GT.M now reports errors from DO, extrinsic functions ($$) and other transfers of control accurately. Previously in some unusual cases GT.M could report a location one line before the actual location. (C9I04-002976)

When run in UTF-8 mode, GT.M requires ICU 3.6 installed and available to GT.M, however, it no longer requires ICU 3.6 to be the current version. An operating system may have installed multiple versions of a library such as ICU, with one version being the current version. Prior releases running in UTF-8 mode required ICU 3.6 to be the current version, which could cause a conflict with other software using ICU. [UNIX] (C9I06-002998)

GT.M now handles any DAY picture in the format specification of $ZDATE() function correctly. GT.M V5.2-000 and later ignored the DAY picture and unconditionally used the three-character English abbreviations for days of the week. (C9I06-003002)

GT.M now guards against signals interrupting memory allocation requests. Previously limitations on reentrancy of Unix services could occasionally cause memory allocation requests to hang if a signal resulted in another memory allocation while one was already active. [UNIX] C9I07-003004

GT.M now correctly handles run-time errors encountered during indirection in accordance with the M standard. In previous versions of GT.M, if a run-time error occurred inside indirection (for example, SET REF="^GBL(UNDEF)" WRITE $ORDER(@REF), where UNDEF is an undefined variable and hence causes a GTM-E-UNDEF error) and if $ETRAP includes a NEW command (e.g. SET $ETRAP="NEW X SET X="ERROR ENCOUNTERED" WRITE X,! QUIT") followed by a QUIT without resetting $ECODE to "", the UNDEF error would not be re-thrown in the caller function, which did not conform to the M-standard. (C9I07-003006)

GT.M now clears $ECODE (assigns it the value of the empty string) after an error in the GT.M utility which implements the display of help text; if the utility encounters no errors, it leaves $ECODE at its value on entry. This can cause the loss of some error context. In prior versions of GT.M (subsequent to the introduction of $ECODE functionality) errors in the help utility could change $ECODE and cause unintended behavior in subsequent error handling. Note that both the prior and current behavior of errors in ZHELP can disturb debugging of error handling. [UNIX] (C9I07-003009)

GT.M now avoids a class of shared memory corruption that could be caused by reusing the same buffer more than once in a transaction. In versions prior to V5.3-001, when this was fixed as a consequence of other changes, such corruption could occasionally occur and cause process failure or even database damage. While in theory this could happen under other circumstances, this was discovered (and is by far most likely) during a MUPIP JOURNAL RECOVER of a KILL that clears multiple blocks. (S9H03-002644)

MUPIP JOURNAL -RECOVER -BACKWARD or MUPIP JOURNAL -ROLLBACK now honor the current database full-block-write setting (controlled by the "gtm_fullblockwrites" environment variable/logical) while playing before-image journal records into the database. While they honored the setting for other database writes, previous versions of GT.M would write only as much data as available in the before-image journal record even though gtm_fullblockwrites was set to 1. This could potentially result in GT.M writing partial blocks (as far as the underlying file system is concerned). Depending on the type of file system used, this could take longer than writing full blocks - in other words, than padding the before-image record enough to write data that is a multiple of the underlying file system page size. (S9I05-002681)

The Update Process on a secondary instance now issues an UPDREPLSTATEOFF error whenever it encounters a record in the replication pipe that is destined to a non-replicated database file. After issuing the message, the update process shuts down immediately. The UPDREPLSTATEOFF error message section in the Messages and Recovery manual describes how to restart replication in this situation. Previous versions used to allow updates to non-replicated databases, which caused various issues including (a) even when a secondary instance was shutdown with zero backlog, a restart would show it as having a huge backlog and (b) a switchover to this secondary instance could cause the databases to no longer be logically equivalent. (S9I05-002682)

GT.M now allows the OpenVMS XFC file cache to be bypassed for journal files.

Depending on your configuration, this may improve journaling performance under certain workloads. Note that any concurrent journal file read operations, including the replication source server if it needs to refer to the journal file, also bypass the XFC file cache. However, if there are no writers that have a journal file open, the XFC file cache is used which may be useful when doing journal extracts or recoveries.

Note that enabling this feature for journal files which are on volumes not enabled for the XFC file cache either has no effect or may cause errors. This includes early versions of XFC which just provided VIOC emulation. Please check with your OpenVMS system manager.

MUPIP SET /FILE /JOURNAL= has a new option, NOCACHE, which sets the GT.M NOCACHE mode. The default if it is not specified is CACHE.

This option is also available for MUPIP BACKUP /NEWJNLFILES= to change the mode after the backup.

MUPIP DOWNGRADE and UPGRADE now have slightly different outputs when journaling is enabled. Previously, two fields which only have meaning on UNIX were output:

%GTM-I-MUINFOSTR, Journal sync_io :  FALSE 
%GTM-I-MUINFOUINT4, Journal yield limit : 0 [0x00000000]

The above two lines are now replaced with the following line on OpenVMS:

%GTM-I-MUINFOSTR, Journal NOCACHE :  FALSE

DSE DUMP /FILE output now has an additional line to show whether the associated journal file is opened in NOCACHE mode. The following line comes before the "Journal File:" line:

Journal NOCACHE IO                  FALSE

DSE CHANGE /FILE now has an additional qualifier, /JNL_CACHE= which accepts the values TRUE or FALSE. TRUE sets the GT.M CACHE mode. FALSE sets the GT.M NOCACHE mode.

The default CACHE mode causes the journal file to be opened in the caching mode specified by the OpenVMS caching attribute which defaults to write through. However, when the journal file is switched, whether by operator action or the auto-switch limit, the new journal file has the OpenVMS default caching attribute. If the directory in which the journal file(s) exists has its caching attribute set to NO_CACHING, that becomes the default for all files created in the directory. If the NO_CACHING file attribute is set, all operations on that file bypass the XFC file cache, not just writes, regardless of the GT.M journal caching mode. This behavior is unchanged from earlier versions of GT.M. (C9C06-002064) [VMS]

GT.M is now robust enough to recognize when it is dealing with partially initialized shared memory and handles it appropriately. Previously, it would try to dereference uninitialized fields, leading to access violations. (C9D07-002355)

Please refer to the M Database section for MUPIP information in the description for C9F06-002736.

The source server now moves on to the next region whenever it detects a sought after transaction that has no record in the journal files of its current region. In previous versions, the source server could possibly enter an indefinite loop when unusual circumstances combined with this condition. (C9I06-003000)

The GT.M replication source server now deals properly with journal files on Tru64 that are 2GB or larger. In V53001A, the source server could terminate with a GTM-E-REPLFILIOERR error when using journal files 2GB or larger. [Tru64] (C9I08-003012)

The LKE CLEAR command now recognizes the -[NO]EXACT qualifier which limits the CLEAR to the exact resource name specified with the -LOCK= qualifier. Without this qualifier, LKE treats the resource name specified by the -LOCK= qualifier as a leading prefix for an implicit wild card search of all locks that start with the specified name. With the -INTERACTIVE qualifier (the default) this allows the operator to select one or more LOCKs or to "quit" if the desired LOCK(s) have already been cleared, but with NOINTERACTIVE, the prior behavior (without -EXACT) is extremely awkward. (S9I03-002677)

Please refer to the M Database section for DSE information in the description for C9F06-002736.

When directed to a region with a file header that's marked corrupt, DSE now issues a DBFLCORRP as a warning message and continues. In previous versions DSE terminated when it encountered this error. You can now use the previously documented DSE CHANGE -FILE -CORRUPT_FILE=FALSE command to clear this flag. The CORRUPT_FILE flag is set during a MUPIP JOURNAL -RECOVER and cleared on completion of a successful recovery; you can also set this flag with DSE CHANGE -FILE. Changing this flag does not correct or create any database damage. FIS advises against modifying this flag except on specific instructions from FIS. (C9I01-002946)

DSE CHANGE -FILE now has a -INTERRUPTED_RECOV=TRUE|FALSE qualifier you can use to manipulate a MUPIP JOURNAL RECOVER related flag in the file header. FIS advises against modifying this safety-related flag except on specific instructions from FIS. (C9I01-002947)

DSE CHANGE -FILE now has a -FULLY_UPGRADED=TRUE|FALSE you can use to manipulate the setting of an upgrade-related flag in the file header. FIS strongly advises against modifying this safety-related flag except on specific instructions from FIS and certainly not without a full understanding of the implications. V5.3-000/1/2 versions have an ambiguity with respect to V4-to-V5 upgrade status, which they deal with conservatively by requesting a rerun of MUPIP REORG -UPGRADE. Setting FULL_UPGRADED to TRUE on a file definitively known to be fully upgraded is an alternative to running REORG -UPGRADE. Inappropriately setting this flag to TRUE can cause database structural damage. Setting this flag to FALSE causes some additional overhead and requests to run MUPIP REORG -UPGRADE. (C9I01-002953)