Intended to reduce spikes in response time at epochs caused by flushing global buffers and the filesystem cache (using fsync()), the database segment setting [NO]EPOCHTAPER controls whether GT.M tries to minimize epoch duration by reducing the number of dirty buffers in anticipation of an approaching epoch (time-based or due to a journal file auto-switch). GDE ADD and CHANGE REGION, DSE CHANGE FILEHEADER and MUPIP SET all have -[NO]EPOCHTAPER qualifiers. As a setting of EPOCHTAPER (i.e., to taper) resulted in throughput equal to or better than NOEPOCHTAPER in all workloads tested, it is the default. A setting of NOEPOCHTAPER reverts to the prior behavior should you find that preferable.. (GTM-6638)

See GTM-6638. (GTM-7409)

$ORDER(gvn,-1) has a code path only slightly longer than $ORDER(gvn,1); previously a longer code path made the reverse $ORDER(), or $ZPREVIOUS(), take close to twice the time of a $ORDER() for the identical gvn. Also, MERGE and $QUERY() show a modest improvement. (GTM-7917)

Within a SET trigger context, $ZTDE[LIM] returns the piece separator, as specified by -delim in the trigger definition. This allows triggers to extract updated pieces defined in $ZTUPDATE without having the piece separator hard coded into the routine. Outside of a SET trigger context, $ZTDELIM is null. Previously GT.M did not implement $ZTDELIM. (GTM-8071)

GT.M appropriately handles a case where the file system block size exceeds the operating system page size. Previously, such a situation caused journal file damage (e.g. JNLBADRECFMT errors) on rare occasions. This was only encountered in the GT.M development environment, and was never reported by a user. (GTM-8183)

$ZTRIGGER() and MUPIP TRIGGER work reliably; previously they could occasionally produce segmentation violations (SIG-11) or garbling of trigger names. This issue was discovered in the GT.M development environment and was never reported by any user. (GTM-8214)

KILL appropriately handles the case where there the target gvn has a KILL trigger and there is a concurrent MUPIP REORG TRUNCATE or ROLLBACK ONLINE that moves the root block of the target gvn. Previously, in this unusual case the target gvn might not be killed. This was only encountered in the GT.M development environment and was never reported by a user. (GTM-8242)

MERGE gvn2=gvn1 where gvn1 falls in a spanning node, either because of its own key-value length or the key-value length of one of its descendent nodes that starts in the same data block as gvn1, works correctly. Previously, if the block size of the region holding gvn2 was less than that of the region holding gvn1 or $LENGTH($VIEW("YGVN2GDS",gvn2))>$LENGTH($VIEW("YGVN2GDS",gvn1)), such a MERGE damaged gvn2 so that a subsequent reference to it resulted in a TPFAIL error with retry codes uuuu. (GTM-8245)

SETs within trigger code that updates nodes having the same unsubscripted name as the node with the trigger work reliably; previously there was a small chance such a SET placed a garbled value in the destination. This was only encountered in the GT.M development environment and was never reported by a user. (GTM-8256)

GT.M correctly handles a KILL of a NOISOLATION global node within a TP transaction where the same transaction had SET at least one node in the same GDS block as the node being KILL'd. Previously, if a concurrent SET from another process happened at the same time as the KILL and both updated the same GDS block and the KILL action made the block empty, GT.M incorrectly applied the NOISOLATION optimization which meant that the concurrent SET was lost. Note that any missing SET was captured in the journal and by replication. (GTM-8269)

Trigger upgrades with MUPIP TRIGGER UPGRADE and trigger maintenance with $ZTRIGGER() and MUPIP TRIGGER actions, other than UPGRADE, refer to the same trigger. In V6.2-001, identical triggers could appear as duplicates, and attempts to delete triggers that had been upgraded did not work. The workaround was to delete all triggers with a "-*", and then load the correct set of triggers. This was only encountered in the GT.M development environment and was never reported by a user. (GTM-8277)

When execution of GT.M is restricted to members of a group, regardless of database file owner and group, and independent of whether the owner is a member of the group, shared resources never have world permissions. When the owner is not a member of the group, and when execution of GT.M is restricted to members of a group, the group of all GT.M-generated shared resources is the group permitted to execute GT.M. Previously, in this edge case, GT.M created shared resources with world access. GT.M sets permissions for shared resources (journal files, shared memory, and semaphores) that are rational, but as restrictive as possible, in certain implausible but technically feasible edge cases; for example: a database file with read-only access for an owner, who is not a member of its group, with read-write group access. Previously, in such edge cases, it was possible for journal file and shared memory permissions to be impractical; e..g, with the combination of permissions above, a journal file created by a user who is a member of the group (but not the owner of the database) could have read-only permissions for the creator of the journal file. Note that FIS recommends against attempting such dubious group memberships and file permissions. In addition, When installing GT.M with the option to restrict GT.M access to members of a group, the configure script terminates with the GROUPNOTVALID error if the group is root or bin; and with the NOTINGROUP error if owner is not (a) root, (b) bin, or (c) a member of the group. Previously, the configure script did not check for these unusual combinations. (GTM-8278)

GT.M deals appropriately with a situation when high contention for a database resource results in all available mutex_slots being used. Previously such an unusually high contention could cause processes to inappropriately wait a couple of seconds for a resource even after it became available. Note that in releases V6.0-000 through V6.1-000, a mutex queue slot leak, fixed in V6.2-000 with the tracking number GTM-7804, a leak in mutex queue slots could cause the same behavior by causing all slots to appear to be in use. (GTM-8286)

$ORDER(gvn,expr) correctly handles the case where expr is not a literal; previously if a function with these characteristic appeared in a global subscript within a Boolean expression, this somewhat unusual case caused a segmentation violation (SIG-11). (GTM-8291)

When an instance changes roles from a secondary (also known as a propagating primary) to a primary (also known as a root primary), the first Source Server process on the primary, or the MUPIP REPLICATE SOURCE ACTIVATE command for on-the-fly switching, creates a new set of journal files for all journaled regions (which are also all replicated regions) in the global directory. When called by lost (unreplicated) transaction processing logic on the root primary, the new journal files make $ZQGBLMOD(gvn) less likely to report a false positive (1) as to whether the node gvn was changed by a local update since the instance became the new root primary. Note that by design $ZQGBLMOD() must be pessimistic, in that while a return value of 0 means that the node has not changed, a return value of 1 reports that the node may have changed. For applications that use $ZQGBLMOD() to attempt automatic lost (unreplicated) transaction processing, making $ZQGBLMOD() less pessimistic means that falling back to manual reconciliation is less likely. Starting a Receiver Server in a secondary instance and allowing it to communicate with the Source Server no longer resets $ZQGBLMOD() on the primary instance. Although deployments usually perform a ROLLBACK FETCHRESYNC before starting up a Receiver Server, starting a secondary instance with AUTOROLLBACK, or inadvertently forgetting to perform a ROLLBACK FETCHRESYNC previously reset internal state information used to compute $ZQGBLMOD() so that all calls to $ZQGBLMOD() thereafter returned 1, thereby requiring manual reconciliation for all lost (unreplicated) transaction processing using $ZQGBLMOD() to make this determination. The workaround was to first perform a separate ROLLBACK FETCHRESYNC step, before starting replication. In addition, $ZQGBLMOD() works on Supplementary Instance (SI) replication as it does for Business Continuity (BC) replication; previously ROLLBACK always caused $ZQGBLMOD() return 1 in SI environments. This was only encountered in the GT.M development environment and was never reported by a user. Note that lost (unreplicated) transaction processing is always the responsibility of the application designer. GT.M lacks the knowledge of application design required to determine whether a zero return value means that it is safe to apply the update, and $ZQGBLMOD() is only a tool to assist the application. (GTM-8298)

For database segments opened with the MM access method, GT.M ensures it continuously flushes journal buffers. Previously after at least one database file extension, when there were no active updates, occasionally GT.M did not flush the journal buffers until subsequent updates filled journal buffers, a VIEW "JNLFLUSH", or the exit of the last process with the database open for writing. This was only encountered in the GT.M development environment and was never reported by a user. (GTM-8299)

In a case where the last process with a database open for writing bypasses the rundown on exit, leaving associated the shared memory open, allocated and potentially unflushed, GT.M sends a LASTWRITERBYPAS warning message to the system log. This can occur if the instance is frozen at the time of the process exit. Previously, GT.M did not provide this notification. (GTM-8300)

GT.M performs automatic database upgrades for all V5 and V6 versions. Previously, (a) versions subsequent to V5.4-002A did not properly upgrade databases created in or upgraded to V5.3-003 and V5.3-004; and (b) databases created in or upgraded to V5.0-000 had to first be upgraded to V5.1-000. If you need to upgrade a V5.3-003 or V5.3-004 database to a version prior to V6.2-002, first upgrade to V5.4-002A and then, as a second step upgrade, to the target version. If you need to upgrade a V5.0-000 database to a version prior to V6.2-002, first upgrade to V5.2-000, and then to the version prior to V6.2-002. This was only encountered in the GT.M development environment and was never reported by a user. (GTM-8335)

TPRESTART messages from GT.M processes include the $ZPOSITION of the line of M code that caused the restart of the transaction; utilities leave this field blank. Previously, the restart recording facility did not report this information. (GTM-8350)

See GTM-8239 (GTM-1759)

See GTM-7949. (GTM-5428)

When $PRINCIPAL input is a terminal device and $PRINCIPAL output is /dev/null GT.M directs WRITEs to $PRINCIPAL to /dev/null; previously, it sent such output to the $PRINCIPAL input terminal. When $PRINCIPAL input and output are different sockets, GT.M treats them as separate input and output SOCKET devices; previously, it set up a SOCKET device with only the input socket so output went to the input socket. When $PRINCIPAL has different input/output devices, the USE command recognizes intrinsic special variables $ZPIN or $ZPOUT and applies deviceparameters to the input or output side of $PRINCIPAL, respectively. USE $PRINCIPAL continues to apply appropriate deviceparameters to both input and output devices. A USE with any of the $PRINCIPAL variants sets $IO to $PRINCIPAL. Previously, it was not possible to modify a split device separately. $ZSOCKET() also accepts $ZPIN or $ZPOUT as its first argument and, if the device is a split SOCKET device, supplies information on input or output side, respectively. In any context other than USE or $ZSOCKET(), or if $PRINCIPAL is not a split device, $PRINCIPAL, $ZPIN and $ZPOUT are synonyms. In the case of a split $PRINCIPAL, $ZPIN and $ZPOUT return the value of $PRINCIPAL followed by the strings "< /" and "> /", respectively. Any attempt to OPEN $ZPIN or $ZPOUT results in a DEVOPENFAIL error. Note: if $PRINCIPAL input and output are different SOCKETs, WRITE /WAIT applies to the input side of the device. (GTM-5688)

See GTM-8239 (GTM-6112)

On Linux x86-64 the C stack is aligned to 16 bytes. Previously problems such as SIG-10 bus error or SIG-11 segmentation faults could occur as a consequence of an 8-byte stack alignment. These were only encountered in the GT.M development environment, and were never reported by a user. [Linux x86-64] (GTM7894)(GTM-6524)

$$ZHOROLOG^%POSIX returns the correct number of seconds and microseconds. Previously, when the number of microseconds was 0, the function reported ten times the seconds count with no fractional part. This functionality is actually provided by the POSIX plugin rather than core GT.M, and was release in version r1 of the GT.M POSIX plugin, which is released independently. This release note appears here as a matter of record. Note also that the new intrinsic special variables $ZHOROLOG and $ZUT may provide you with comparable functionality at a lower computational cost. (GTM-7725)

See GTM-6524(GTM-7894)

$ZUT (UNIX time, or universal time) returns the number of microseconds since January 1, 1970 00:00:00 UTC, which provides a time stamp for directly comparing different timezones. $ZUT accuracy is subject to the precision of the system clock. $ZH[OROLOG] returns four comma-separated numbers (e.g. "63638,39194,258602,14400"). The first two numbers are identical to $HOROLOG, and for existing application code of the form $PIECE($HOROLOG,",",...), $ZHOROLOG is a drop-in replacement. The third is the number of microseconds in the current second, and the fourth is the number of seconds to be added to the time reported in the first two numbers to determine the UTC time. Note that the fourth number can be positive or negative, and because the time zone of the computer can have a different date from UTC, generating a UTC time from it may require adjustment to both first and second pieces. (GTM-5428) (GTM-7949)

ZSHOW "C" provides the list of loaded external call packages and their routines. Packages that are accessible but have not been accessed are not reported. When a local or global variable is targeted for output, the package and routine names are placed as subscripts for ease of programmatic manipulation. ZSHOW "C" is included in ZSHOW "*". (GTM-8087)

The JOB command accepts up to 28 routine arguments, each of which may be up to 8192 bytes long. If any argument exceeds the limit, the JOB command issues a JOBPARTOOLONG error message. Previously, the limit was 8190 bytes, but arguments exceeding 1024 may have been truncated, included extraneous data, or resulted in a SIGABRT, and a JOB command exceeding the former 8190 byte limit incorrectly issued a JOBFAIL error message along with EBADF indicating: Job error in socketpair. (GTM-8167)

GT.M limits trigger names used as arguments to ZBREAK, ZPRINT and $TEXT() to 30 characters in order to maintain the trailing pound-sign (#), which acts as an identifier that the object named is a trigger. Previously, attempts to provide trigger name arguments of 31 or more characters to these features caused them to issue a ZLINKFILE error rather than a TRIGNAMENF error. In addition, GT.M recognizes the region-name selector on long trigger names in regions with long region names; previously if the trigger existed but the combination of the trigger name and selector exceeded 31 characters, GT.M inappropriately produced a TRIGNAMENF error. (GTM-8197)

The optional fourth expression (after the tlsid) in the argument of a WRITE /TLS command specifies an obfuscated password for the private key in the tlsid section of a configuration file. This key overrides any existing password. Previously GT.M required an environment variable of the form gtmtls_passwd_<tlsid> to specify an obfuscated password. The optional fifth expression in the argument of a WRITE /TLS command specifies configuration file options that add to or replace existing options in the section labeled tlsid. If there is no section with the label tlsid, GT.M creates a new virtual section, which persists for the life of the process. These options use the same format as the configuration file including the terminating semi-colon (";"). The format for WRITE /TLS is:

WRITE /TLS(option[,[timeout][,[tlsid][,[obfuscatedpassword][,options]]]]) 

When the second argument of $ZSOCKET() specifies "TLS" as the keyword expression, $ZSOCKET() returns a string of the form "1,<SERVER|CLIENT>[,<tlsid>]" when the SOCKET is using TLS or the empty string if it is not. The optional tlsid comes from the WRITE /TLS which enabled TLS on the specified socket. The optional fourth argument specifies that $ZSOCKET() return additional information where the argument may contain (case-insensitive) "CIPHER" and/or "OPTIONS" separated by a comma. The returned information for "CIPHER" is the TLS protocol prefixed by "P:" and the algorithm prefixed by "C:" and the information for OPTIONS is prefixed by "O:" delimited by vertical-bars. For example to return the TLS options and cipher on the current socket in the device specified by the local variable S:

WRITE $ZSOCKET(S,"TLS",,"options,CIPHER")

The missing third argument specifies the current socket. (GTM-8219)

JOBLVN2LONG error message has been changed, and it no longer includes the maximum and encountered ZWRITE representation lengths. Previously, it was reporting both sizes as 0 from the parent process. The correct sizes were visible from the child process only. The child process now reports an additional informational message, JOBLVNDETAIL, which includes those two sizes. (GTM-8221)

GT.M handles interactions between ZBREAK and recursive relink appropriately. Previously, recursively linking a new version of an active routine, inserting ZBREAKs, relinking it again, could cause a segmentation violation (SIG-11) or illegal instruction (SIG-4) when a routine which had linked a pre-ZBREAK version of the routine with the ZBREAKs attempted to invoke it anew after the ZBREAK version had disappeared from the stack. In addition, GT.M issues a more appropriate REQRLNKCTLRNDWN error message in case an actively used rtnobj shared memory segment gets deleted (by say an "ipcrm -m") and a new process tries to attach to that; previously one would get a RELINKCTLERR error message. Also, in case an actively used relinkctl shared memory segment gets deleted, the REQRLNKCTLRNDWN message has more detail indicating the shmid and the actual error returned by the "shmat()" system call; previously the additional detail was absent. As result of this effort GT.M produces somewhat smaller object files with a small uptick in performance. (GTM-8224)

On exit, processes release their M locks in a fast operation; previously it was possible for the release to delay process termination. (GTM-8228)

GT.M correctly handles I/O errors when its stdout and stderr are conjoined to a file, FIFO, or PIPE device. Previously, when a process's stdout and stderr were conjoined to a file, FIFO, or PIPE device, a failure to write to either of the streams, for instance in a broken pipe situation, could trigger a segmentation violation (SIG-11). (GTM-8229)

$VIEW("POOLLIMIT") with a missing size argument defaults to 0 (100% availability) and with a missing or asterisk (*) region argument, applies to all regions; previously such inputs produced a segmentation violation (SIG-11). In addition, VIEW("POOLLIMIT") for database regions with access methods other than BG returns a zero (0); in V6.2-001, it could inappropriately return a non-zero value. Also, error messages that contain VIEW/$VIEW() problematic arguments use ZWRITE format to display non-graphic characters, and GT.M appropriately handles errors with VIEW/$VIEW() region names; in V6.2-001 such errors could damage local storage of the bad name. (GTM-8231)

$ZSEARCH() skips symbolic links that result in loops; previously it gave an error when the search encountered such a link. (GTM-8237)

ZRUPDATE rejects file-name arguments that are symbolic links or start with a percent-sign (%); previously it accepted file names starting with '%' as well as symbolic links with a '.o' extension that resolved to any file. In addition, ZRUPDATE recognizes question-mark (?) as a single character wild-card; previously it did not. Also, ZRUPDATE always updates the existing shared memory relinkctl information for a file with an existing entry; previously if the process had never previously accessed the directory containing the entry and the directory no longer existed, ZRUPDATE inappropriately failed to maintain the relinkctl memory. (GTM-8238)

GT.M does not send extraneous newlines to principal devices that are files, PIPEs, or FIFOs. Previously, in certain situations, such as during a ZSYSTEM command, or when processing an error, GT.M could send extraneous newlines to file, pipe or FIFO principal devices (but not to terminal principal devices). Additionally, if the stderr and stdout of a process are conjoined to a terminal or a single file (e.g., with shell redirection), $X and $Y are correctly maintained, and application output to stdout and error messages to stderr are correctly merged. Previously, under such circumstances $X and $Y did not reflect the output to stderr, and lines written to stdout and stderr could be commingled. Finally, receiving a signal, such as SIGTERM, while processing a READ command does not result in an indeterminate hang. Previously, there was a small window in processing of the READ command, receiving a signal during which could cause GT.M to hang indefinitely. Please review scripting that captures and compares GT.M output to determine whether it is affected by this fix. (GTM-1759)(GTM-6112)(GTM-8239)

The environment variable gtm_autorelink_ctlmax specifies the maximum number of entries for unique routine names in the relink control file created by a process for any directory, with a minimum of 1,000, a maximum of 16,000,000 and a default of 50,000 if unspecified. If a specified value is above or below the allowed range, the process logs the errors ARCTLMAXHIGH or ARCTLMAXLOW respectively in the syslog, and uses the nearest acceptable limit instead. MUPIP RCTLDUMP and ZSHOW "A" outputs include the maximum number of unique routine names available in a relink control file. Previously (effective V6.2-001, when auto relink became production grade software), relink control files for each directory had a fixed capacity of 1,000,000 unique routine names. Note that any application code or scripting that parses the output of MUPIP RCTLDUMP or ZSHOW "A" needs to be changed. [AIX, Linux x86_64, Solaris] (GTM-8240)

Acquisition attempts by processes of M LOCKs held by other processes are lightweight with little impact on database throughput. Previously, large numbers of processes - hundreds to thousands - waiting for LOCKs held by existing processes and mapped to the shared memory of a database region could interfere with one another and negatively impact database activity for the region. (GTM-8241)

$ZWIDTH() respects the [NO]BADCHAR setting; previously it ignored this setting and always reported invalid UTF-8 characters. (GTM-8246)

The JOB command accepts up to 32 arguments and issues MAXACTARG error on the child's error stream if the argument count is beyond the limit. The parent process continues to receive a JOBFAIL if the number of arguments exceeds the limit. Previously, the limit was 28 and exceeding the limit caused a GTMASSERT. (GTM-8249)

VIEW "NOISOLATION":strexpr reports a VIEWGVN error if the strexpr is not a literal and contains only a plus-sign or minus-sign; previously this caused a segmentation violation (SIG-11). (GTM-8258)

Setting VIEW "[NO]FULL_BOOLEAN[WARN]" works appropriately in certain rare cases involving indirection and direct mode, previously executed expressions retained the behavior from the setting in effect at the time the code was compiled for execution. Also, compilation does not result in a segmentation violation (SIG-11) in rare cases when switching back and forth between Boolean modes. (GTM-8261)

Inside a trigger, ZPRINT and $TEXT() work correctly when using just label and offset for the entryref. Previously, neither ZPRINT nor $TEXT() would work correctly unless the trigger routine name was included in the entryref. This was only encountered in the GT.M development environment and was never reported by a user. (GTM-8273)

The auto-relink facility appropriately manages memory when it encounters errors; previously under unusual conditions it could leak memory. In addition, the facility carefully manages the propagation of authorizations to new objects; previously in unusual circumstances it managed the permissions incorrectly. MUPIP RUNDOWN -RELINKCTL when invoked with an argument that does not resolve to an existing directory and does not match a previously existing directory with a left-over relinkctl file produces a FILEPARSE error; previously such invocations did not produce any output. MUPIP RUNDOWN -RELINKCTL for the every auto-relink-enabled directory in $gtmroutines, or specified as an argument when no corresponding relinkctl file is found, follows the RLNKCTLRNDWNSUC message with a TEXT message saying "No relinkctl file found"; previously MUPIP did not provide the supplementary message. This was only encountered in the GT.M development environment and was never reported by a user. (GTM-8280)

Measurement of time for M LOCK timeouts is consistent with that of other timed operations, and only includes the total elapsed time, although it makes a final attempt after returning from an interrupt during which the time elapsed. Previously it included the elapsed time plus any time spent handling interrupts, both interrupts internal to GT.M operation as well as executing $ZINTERRUPT(). This was only encountered in the GT.M development environment and was never reported by a user. (GTM-8282)

Recursive relink of a routine that has one or more breakpoints set works correctly. In GT.M V6.2-001, this could occasionally cause the process to abnormally terminate with a segmentation violation (SIG-11). This was only encountered in the GT.M development environment and was never reported by a user. (GTM-8290)

Timed commands wait the full duration of the specified time. Previously, the time interval could (if interrupted just prior to completion by a MUPIP INTRPT or operations internal to the GT.M run-time logic) be up to 1ms less than the specified time in rare occasions. The most observable effect of such a small time interval was the possibility of two accesses to $HOROLOG separated by a HANG 1 returning the same value. (GTM-8295)

WRITE or ZWRITE of $ZC now returns the same value as $ZCstatus. Previously WRITE $ZC always returned zero and ZWRITE $ZC produced a GTMASSERT2. (GTM-8306)

GT.M sends an INVTMPDIR error to the system log when $gtm_tmp is invalid. In addition, GT.M bypasses $gtm_linktmpdir validation for the gtmsechsr image. Previously, if $gtm_tmp was invalid and $gtm_linktmpdir was not defined, GT.M incorrectly sent an INVLINKTMPDIR error to the system log. Also, if $gtm_linktmpdir was defined, an INVLINKTMPDIR error was sent to the operator when gtmsecshr was started because the gtmsecshr wrapper converted the value to the NULL string. (GTM-8317)

In a fatal error situation, GT.M typically creates a GTM_FATAL_ERROR*.txt file before it exits. GT.M skips the creation of the .txt file for M stack overflows or a SIG-11 addressing exceptions. The .txt extension promotes the ability to easily open such files with common editors. Previously the name of a GTM_FATAL_ERROR* file did not end with a .txt extension, and, under certain very rare circumstances, GT.M could encounter a segmentation violation (SIG-11) when creating the file, which at least partially masked the original failure. This was only encountered in the GT.M development environment and was never reported by a user. (GTM-8320)

GT.M deals with suspended processes holding shared resources used by auto-relink in a timely fashion. Note that you should not suspend a GT.M process using shared resources, and almost all GT.M processes do so. Previously, a process attempting to auto-relink, depending on the inappropriately held resource, could wait up to approximately twenty minutes. (GTM-8330)

GT.M protects against a SIGINT (generated by a <CTRL-C> with the default key binding) while initializing a $PRINCIPAL terminal at process start up; previously, a SIGINT in a small window could cause a segmentation violation (SIG-11). (GTM-8333)

GT.M processes with open PIPE devices terminate promptly when interrupted by a terminal signal, such as SIGTERM. Previously, sending a terminal signal to a GT.M process that had one or more open PIPE devices could under very rare circumstances result in an indefinite hang. This was only observed in the GT.M development environment and was never reported by a user. (GTM-8339)

GT.M manages memory better during process start up. Previously, an interruption during a small window in memory allocation could terminate a process without any error messages or dump files. This was only observed in the GT.M development environment, and was never reported by a user. (GTM-8364)

GT.M processes correctly handle interrupts (such as a timer pop, <CTRL-C>, or a MUPIP INTRPT). Previously interrupts received in very small windows of code could in rare cases terminate processes in various ways including segmentation violations (SIG-11) or GTMASSERTs. This was only observed in the GT.M development environment and was never reported by a user. (GTM-8365)

OPEN and USE commands on sequential devices using deviceparameters APPEND, SEEK, and TRUNCATE work for files over 4GiB in size. In V6.2-000 and V6.2-001, the TRUNCATE mispositioned for files over 4GiB since V6.1-000. (GTM-8369)

ZSHOW works correctly after a MERGE command that invokes a trigger (that is, the target of the MERGE is a GVN) which in turn encounters a runtime error and transfers control out of the trigger code using a ZGOTO. Previously, such a ZSHOW would abnormally terminate with a segmentation violation (SIG-11). (GTM-8370)

$QUERY(lvn) works correctly in the case lvn was previously the target of a ZSHOW "V" when no variables existed. Previously this situation would cause $QUERY(lvn) to result in a segmentation violation (SIG-11). (GTM-8371)

$SELECT() works correctly in several scenarios where it previously did not.

Although the above cases describe the core of the previous behavior, it is likely that there are cases that overlap the above in ways that are not obvious. When gtm_boolean and gtm_side_effects are undefined (or set to zero), GT.M assumes that the code has no side effects other than $REFERENCE and indirection, and can, and does, rearrange computation to improve performance: the evaluation of operands in expressions, the order in which function call parameters are evaluated, etc. In order to be more consistent with other optimizations, when neither gtm_boolean nor gtm_side_effects are set to non-zero values, GT.M V6.2-002A rearranges computation to evaluate a $SELECT() that appears within a Boolean expression only when its arguments contain a global variable or indirection, where previously it always did. If such a $SELECT() has an argument containing an extrinsic ($$) function call with side effects, results on V6.2-002A may differ from those on previous GT.M releases. Note: as the rearranging can change from release to release, you may encounter unexpected and varying results if you compile application code that has side effects with environment variables that tell GT.M that it has no side effects. Where code contains side-effects, FIS strongly recommends compiling it with gtm_side_effects and gtm_boolean set to 1. (GTM-8376)

GT.M provides an option to preallocate blocks from the file system when creating or extending a database file; by default UNIX file systems, and GT.M, use sparse (or lazy) allocation, which defers actual allocation until blocks are first written. The GDE segment qualifier -[NO]DEFER_ALLOCATE, with a default of DEFER_ALLOCATE, determines whether MUPIP CREATE preallocates blocks on database creation, and determines whether subsequent extensions also preallocate. The MUPIP SET qualifier -[NO]DEFER_ALLOCATE provides a mechanism to control GT.M behavior when subsequently extending existing database files, whether using MUPIP EXTEND or auto-extend. To switch an existing database file so it immediately preallocates all blocks, first use MUPIP SET -NODEFER_ALLOCATE to set the switch in the database file header, followed by MUPIP EXTEND -BLOCKS=n, where n >= 0. The DSE DUMP -FILEHEADER ("Defer allocation" field) and GDE SHOW ("DALL" field) show the setting of the switch for each database file. Failures to preallocate space produce a PREALLOCATEFAIL error. On platforms where GT.M does not support preallocation (HP-UX and Solaris), although GDE accepts -NODEFER_ALLOCATE, MUPIP CREATE ignores it and sets the database file to DEFER_ALLOCATE. On those platforms, any attempt to change this flag with MUPIP SET produces a NODFRALLOCSUPP error.

In testing this enhancement, FIS exposed a bug in the Linux ext4 file system which is present in the upstream Linux kernel since at least 3.10, and which is fixed by kernel commit d2dc317d564a46dfc683978a2e5a4f91434e9711 (search for d2dc317d564a46dfc683978a2e5a4f91434e9711 at https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.0.3). The Red Hat Bugzilla identifier for the bug is 1213487. We are also investigating the possibility of a different bug in ext3 and jfs filesystems that may be triggered by use of NODEFER_ALLOCATE. Although the bug appears to be very rare, it manifests itself as a database block which is all zeros (ext4), or zero data bytes (ext3 and jfs) resulting in data loss. Please avoid NODEFER_ALLOCATE for database files on Linux ext3, ext4, or jfs file systems. The default behavior of DEFER_ALLOCATE avoids the bugs. On Linux, place any database files for which you wish to use use NODEFER_ALLOCATE on xfs file systems.[AIX, Linux] (GTM-5894)

The source server sends a REPLSRCEXITERR message to the system log when the server exits abnormally; previously GT.M did not provide notification of such an event. (GTM-7783)

MUPIP REORG TRUNCATE always relocates global root blocks if there is room to relocate them nearer to the beginning of a database file; previously, it could leave them unrelocated under certain conditions thereby limiting the amount of space returned to the file system. The workaround was to repeat the operation as soon as possible. (GTM-8187)

MUPIP commands that produce a lot of output (e.g. MUPIP RCTLDUMP, MUPIP REORG etc.) correctly maintain terminal characteristics in case they are used in a UNIX pipeline involving other tools (e.g. "more") that also play with terminal characteristics. Previously this could result in the terminal not echoing characters once the MUPIP command returned (more likely if the command was not allowed to run to completion). A workaround was to issue a "stty sane" to the shell on completion. (GTM-8232)

Terminating a MUPIP process with a signal, such as SIGTERM, does not result in segmentation violations (SIG-11). Previously, sending a signal to a MUPIP process in a small window shortly after its start-up could cause a segmentation violation (SIG-11). This was only encountered in the GT.M development environment and was never reported by a user. [AIX, SunOS, Linux x86_64] (GTM-8303)

GT.M ensures that timestamps of successive records in a journal file as well as across journal files that were switched on-the-fly (e.g. auto switches) never decrease. Previously this was not ensured which meant that in rare cases a later update could have an older/lesser timestamp in the journal record even though the system time did not go backward. This in turn could affect time related MUPIP JOURNAL commands (e.g. time-based backward recovery etc.) This was only encountered in the GT.M development environment and was never reported by a user. (GTM-8332)

MUPIP JOURNAL - ROLLBACK and -RECOVER handle being interrupted appropriately. Previously, in a rare combination of circumstances, it was possible for a rollback/recover to lose data, or issue incorrect EPOCHTNHI errors, after an interrupted attempt. This was only encountered in the GT.M development and testing environment, and was never reported by a user. (GTM-8334)

MUPIP EXTRACT in binary format can include global variable nodes from both encrypted and unencrypted regions. When an extract includes data from one or more encrypted regions, MUPIP EXTRACT uses a level 8 format (the first 26 characters of the label are "GDS BINARY EXTRACT LEVEL 8"), which cannot be loaded by MUPIP LOAD of earlier GT.M releases. MUPIP LOAD attempts to read extracts of level 7 format using a heuristic approach, which can fail with an error, but we have found typically successful. Previously, extracts from V6.1-000, V6.2-000 and V6.2-001 (extract format level 7) that included both encrypted and unencrypted regions caused MUPIP LOAD to behave badly, including termination with a segmentation violation (SIG-11) or loading incorrect data (the latter, while theoretically possible, was never reported by user). The workaround for loading an extract from any of those three versions was to create separate extracts for encrypted regions and unencrypted regions. Additionally, MUPIP LOAD can read extracts of level 5 format. Previously, MUPIP LOAD failed loading extracts of that version with an error. (GTM-8360)

The configure install script compiles M object files in UTF-8 mode as long as it finds at least one UTF-8 locale. Previously, the configure script required the en_US.UTF-8 locale in order to compile object files in UTF-6 mode. Also, the gtminstall script displays any errors produced by the configure script output; previously, the gtminstall script masked all configure script output inappropriately masking error information. These two changes fix Debian Bug #775302 associated with fis-gtm-6.2-000. (GTM-8041)

On AIX, the reference implementation of the encryption plugin works as expected when using GPG libraries compiled using instructions from Appendix D (Building Encryption Libraries) of the GT.M Administration and Operations Guide.

The reference implementation of the encryption plugin included in GT.M versions V5.5-000 through V6.2-001 referenced a non-standard compilation of the GPGME encryption library (libgpgme). Without the solution below, the administrators setting up the database will encounter either %GTM-E-CRYPTINIT or %GTM-E-CRYPTDLNOOPEN examples below, with extended detail indicating a failure to load GPGME or the encryption reference plugin library.

%GTM-E-CRYPTINIT, Could not initialize encryption library while opening encrypted file gtm.dat.
Error initializing GpgME: GPGME/No such file or directory

%GTM-E-CRYPTDLNOOPEN, Could not load encryption library while opening encrypted file ffff. Could not load module llll.

The solution to this problem required either recompilation of the reference implementation encryption plugin or a modification of the installed GPGME library. FIS strongly recommends recompiling the reference implementation encryption plugin. Please see the section "Plugin Architecture & Interface" packaging in Chapter 12 (Database Encryption) of the GT.M Administration and Operations Guide for compilation instructions. If you have a reason that requires you to modify the GPG libraries after installation, and have GT.M support from FIS, contact your support channel. [AIX] (GTM-8235)

%RSEL handles $ZOUTINES directories designated for auto-relink; previously it ignored such directories. (GTM-8247)

The PINENTRY routine used for unattended password entry does not create temporary directories or files when $gtm_dist and $gtmroutines are properly specified. If the routine encounters an error, it hands off the password request to the system default pinentry program. The PINENTRY routine only fails when GTMXC_gpgagent is not defined correctly. Typically users encounter this problem during database setup. Previously, the PINENTRY routine always created temporary directories and files and did not support a hand off to the system pinentry program which resulted in a CRYPTKEYFETCHFAIL error. (GTM-8272)

See GTM-8275.(GTM-8274)

The reference implementation of the GT.M plug-in makes appropriately efficient use of GnuPG, under all conditions, but especially when multiple databases and devices use the same key file. Previously, recent versions of GnuPG included a component that greatly benefits from this change. Because the plug-in stops processing as soon as it finds a key it is looking for, a given look up does not detect or report subsequent errors in the configuration file. Previously, such subsequent errors could stop GT.M from using keys specified even in the correctly specified part of a configuration file. Note that this reference plug-in is compatible with V6.2-000 and V6.2-001.(GTM-8274)(GTM-8275)

DBCERTIFY CERTIFY correctly handles a split in the root level of a global variable tree that occurs after a SCAN. This was previously reported as fixed in V5.2-000A as part of GTM-5873 (C9G04-002790), but had a regression in V6.0-001 due to fixes made for GTM-7559. Also, it no longer gives occasional spurious DBPREMATEOF or DBCINTEGERR errors. Previously these (fortunately rare) conditions required reverting to a V4 format database followed by repeating the scan and upgrade. This was only encountered in the GT.M development environment and was never reported by a user. (GTM-8287)

The gtmprofile setup script correctly handles ICU versions ending in zero, such as 50, when defining gtm_icu_versions; previously gtmprofile inappropriately defined gtm_icu_version as just an integer instead of a decimal value. The workaround was to edit the script produced by gtmprofile. This was only encountered in the GT.M development environment and was never reported by a user. (GTM-8315)

DSE CHANGE FILEHEADER produces a CLIERR, Unrecognized option : SPIN_SLEEP_CNT error when given the long-deprecated SPIN_SLEEP_TIME field, which is also not displayed by the DSE DUMP FILEHEADER command. Previously DSE accepted this qualifier, which was harmless. (GTM-8316)