GT.M releases the shared resource required for writing the journal file and committing it to permanent media when the operation encounters an error. Previously, in the very unusual case of such an error, GT.M did not release the shared resource, which caused subsequent journal activity to encounter fatal GTMASSERT errors. [UNIX] (GTM-6892)

GT.M invokes triggers for globals having null-subscripts. Null string used in range is considered either -infinity or +infinity. Previously, invoking such triggers could produce a segmentation violation (SIG-11). [UNIX] (GTM-6899)

By improving heuristics used to manage database and journal writes by the Update Process, journal files on replicating secondary instances are now potentially smaller owing to fewer EPOCH and PBLK records. Previously, overly aggressive heuristics resulted in workloads that consisted of bursts of updates interspersed with periods of idleness on a primary instance causing larger than warranted journal files in instances receiving replication streams. [UNIX] (GTM-7054)

ZPRINT or ZBREAK targeting a trigger definition that falls outside of the namespace of the current global directory issue a TRIGNAMENF error; in that situation $TEXT() returns the empty string. Previously, these actions caused a TPFAIL.[UNIX](GTM-7093)

GT.M properly closes journaling when it encounters file system out-of-space conditions while flushing journal buffers. Previously, GT.M processes could issue a fatal GTMASSERT error under these conditions. [UNIX] (GTM-7268)

When GT.M encounters a high number of retries to acquire the resource controlling flushing of journal records from memory to disk it issues a JNLFLUSHNOPROG warning to the syslog facility and continues to retry. Previously it issued JNLFLUSHNOPROG or FSYNCTIMOUT errors and terminated the process with a GTMASSERT. (GTM-7381)

When a database file with extension disabled (zero extension size) starts to get full, GT.M now logs a warning in the system log. So as not to compromise performance, GT.M checks whenever the master bit map must be updated to show that a local bit map is full, and issues the warning if there are fewer than 512 free blocks, or if the number of free blocks is less than one thirty-second of the number of total blocks. Note: this means that for databases whose size is 512 blocks or less the warning comes at the last successful update before the database is out of room. (GTM-7412)

An attempt to attach to a database belonging to one node on another node produces a HOSTCONFLICT error which includes the owner node and the node attempting the attach. Note that a crash can sometimes create abandoned ownership. Previously this condition produced a CLSTCONFLICT error, which had less context and less clear terminology, [UNIX] (GTM-7490)

When a GT.M run-time process or utility encounters an error attaching to a database, it releases control of the shared resources that control initial database access. Previously, if a process remained active after such an error, it could prevent other processes from attaching to the database in question. [UNIX] (GTM-7503)

For errors in the sample custom errors file, GT.M and its utilities use the correct region to determine whether INST_FREEZE_ON_ERROR applies to a particular error message. Previously some errors which could occur during RECOVER or ROLLBACK set the instance freeze (or decided not to do so) based on the INST_FREEZE_ON_ERROR setting of a different region. If you are concerned about the behavior for other errors, please contact your FIS support representative. [UNIX] (GTM-7548)

GT.M appropriately writes idle EPOCH records (corresponding to the GVSTATS statistic JRI) for MM access method database files. In V6.0-001, in some cases, it was possible they were not written which meant that in case of a crash shutdown some journal records at the end of the journal file could get permanently lost after a journal recovery/rollback. Note that BG access method was not affected by this. (GTM-7586)

GT.M allocates the memory used by each process for journal records it generates based on the current active configuration. Previously, starting in V6.0-000 this memory was allocated based on a worst case calculation to allow large global variable nodes; on UNIX, the reduction is approximately 2MiB for each process that accesses a journaled database. (GTM-7595)

In GT.M databases with the MM mode access method, the first process to open the database does not need write permission for the database file. Previously, a read-only process attempting the first open of an MM database received a signal 11 (SIGSEGV). The workaround was for the first process opening the database to have write access to the database file. [UNIX] (GTM-7599)

When GT.M finds the process holding the journal flushing resource no long exists, it sends a JNLQIOSALVAGE informational message to the operator log. Previously under this circumstance, it sent a JNLFLUSH message, which was inappropriate because JNLFLUSH, indicating a real problem with journal write, might appear in the custom errors file, thereby inappropriately causing an Instance Freeze on UNIX platforms. (GTM-7622)

A TP transaction attempting to update more than 32Ki blocks in a region with MM access method issues a TRANS2BIG error. Previously, such an attempt did not detect this boundary, potentially causing database damage. (GTM-7630)

GT.M periodically explicitly hardens NOBEFORE journal records to disk. Because of an imperfect optimization in V6.0-000 (GTM-7383), GT.M did not perform this explicit hardening under all appropriate circumstances. Note that Durability of neither BEFORE image journal records nor any journal records for regular TP transactions (i.e., those not specifying "BATCH" on TSTART) was affected. [UNIX] (GTM-7633)

When a GT.M process is unable to expand the memory needed to access an extension of an MM database, it produces DBFILERR/GBLOFLOW errors, and if the process attempts any further access to that database, it produces MMREGNOACCESS errors. Previously, subsequent attempts to access the inaccessible database produced a fatal SEG-V (SIG-11) error. [UNIX] (GTM-7636)

When a region has the MM access method and hugepages are configured, GT.M creates shared memory that is a multiple of hugepage size (typically 2MB or 4MB). Previously, in hugepages environment, shared memory for MM databases were not a multiple of hugepage size and caused standalone operations to error out. [LINUX](GTM-7637)

A TRESTART in an error handler when no transaction is active ($TLEVEL=0) produces a TLVLZERO. In V6.0-001, this situation produced an inappropriate TPRESTNESTERR. (GTM-7642)

GT.M processes not operating in an Instance Freeze environment handle ENOSPC conditions during file extensions appropriately. In addition, during file extensions, GT.M processes no longer issue WAITDSKSPACE messages to stderr. Previously when not operating in an Instance Freeze environment, GT.M when handling ENOSPC conditions during file extensions, inappropriately allowed multiple processes to concurrently extend the same region, which, in very rare cases, could cause database damage. [UNIX] (GTM-7651)

On 32-bit platforms, GT.M issues an MMFILETOOLARGE error when an attempt to open a database file with the MM access method fails because of addressability limits. Previously, GT.M memory mapped only a part of the file. Subsequent global variable read and write attempts issued GVxxxFAIL errors, resulting in indefinite file extensions and database damage. [UNIX] (GTM-7659)

GT.M issues DBMBMINCFREFIXED warning to the operator log whenever it notices a master bitmap incorrectly marking a local bitmap as incorrectly free and auto corrects this by marking the local bitmap as full in the master bitmap. Previously, GT.M issued no such messages thereby leaving no record of such an unusual event. [UNIX] (GTM-7692)

When GT.M fails to dynamically load the encryption plugin and gtm_passwd is set to an empty string, it issues a CRYPTDLNOOPEN2 error. In V6.0-001, for this combination of circumstances, GT.M terminated with either a SEG-V (SIG-11) or SIGILL (SIG-4). [UNIX] (GTM-7701)

When GT.M encounters a failure to extend an MM database, it leaves the database in a consistent state, although inaccessible to the process. Previously, such a failure left the database with a DBFGTBC integrity error. Also, during file extension in BG and MM, GT.M utilities check and, if appropriate correct, the accuracy of the free blocks counter. Previously, the check was done only by GT.M [UNIX] (GTM-7712)

When opening a database that was not cleanly shut down, GT.M issues a REQROLLBACK error in cases with replication and BEFORE IMAGE journaling, and REQRECOV error with NOBEFORE journaling. Together, REQRUNDOWN, REQROLLBACK and REQRECOV messages provide more context-specific instructions, thus better guiding you in protecting and recovering data after a process crash. Previously, GT.M issued REQRUNDOWN error on a process crash regardless of journal and replication states. [OpenVMS] (GTM-7723)

When an external routine specifies a non-positive time to the gtm_start_timer() function, GT.M schedules the timer for 10 ms. Previously, GT.M issued a GTMASSERT whenever the expiration time specified in gtm_start_timer() call was non-positive. [UNIX] (GTM-1937)

GT.M provides an interface intended for use with Java---please refer to the Java Interface Technical Bulletin. The work to add this feature also addressed a number of issues with the C-oriented call-in/out interface. GT.M preserves precision of a double call-in or call-out argument at 15 decimal digits and a float argument at six decimal digits overall when converting to a GT.M internal representation, matching the persistent decimal precision of doubles and floats, respectively, in the IEEE 754 format. Previously, GT.M always reserved six digits after the decimal point. Additionally, GT.M correctly interprets long, long *, unsigned long, and unsigned long * arguments in their full 8-byte capacity when making calls out from M to C and calling-in from C to M. Previously, on 64-bit platforms, internal representations whose values exceeded 4-bytes did not correctly translate into 8-byte long integers; and, in both 32- and 64-bit editions, casting of signed and unsigned long arguments passed by value was reversed in case of call-outs. Also, returning a non-zero value from a C routine with gtm_status_t return type raises an error status. Previously, GT.M sent the error message text to $PRINCIPAL. [UNIX] (GTM-3220)

Indirection gives a syntax error when passed the string "@". Previously, a command such as SET @"@"=1 would neither have any effect nor give a syntax error. (GTM-4324)

Indirection appropriately issues a syntax error when a string contains either control characters or extra characters. Previously, indirection would ignore the tail of such a string. (GTM-5284)

For applications whose source code includes literals, GT.M provides options to help optimize performance and virtual memory usage.

As the scalability and performance from reduced per-process memory usage may or may not compensate for the incremental cost of dynamically loading and unloading the data structures, and as the performance of routines vs. inline code can be affected by the availability of routines in cache, FIS suggests benchmarking to determine the combination of qualifiers best suited to each workload. Note that applications can freely mix routines compiled with different combinations of qualifiers. In addition, MUMPS compile invocation mode and the ZCOMPILE command inherit default qualifiers from the environment variable gtmcompile. Previously, gtmcompile was only effective within the GT.M run-time environment, for explicit ZLINKs and auto-ZLINKs. [UNIX] (GTM-6330)

The JOB command now creates .mje and .mjo files only in the working directory of the JOB'd process. Previously, when the DEFAULT process parameter of JOB command specified a directory which was different than the current working directory of the process executing JOB command and VIEW "JOBPID":1 was in effect, GT.M inappropriately also created .mje and .mjo files in the working directory of the process executing the command. [UNIX] (GTM-6548)

GT.M reports $ZREALSTOR, $ZALLOCSTOR, and $ZUSEDSTOR ISVs with 18 digits of precision. Previously, GT.M returned inappropriate results for the aforementioned ISVs if the values exceeded 4,294,967,295. (GTM-6717)

GT.M processes no longer hang or terminate abnormally if interrupted by a signal within a specific time window. Previously, a GT.M process could hang or terminate abnormally if it encountered a signal interrupt within one of the certain unprotected, very short time windows. [UNIX] (GTM-6802)

A sequential disk device accepts the [NO]FOLLOW deviceparameters for OPEN and USE. In FOLLOW mode, a READ returns only when it has a complete record or reaches any specified timeout; it waits for more input rather than terminating for an EOF (end-of-file) condition. Each argument to a READ command is considered a separate READ in the following discussion.

For STREAM or VARIABLE record format files, a READ returns when it encounters an EOL, or has read #length characters if specified, or WIDTH characters if #length is not specified, whichever occurs first.

For non Unicode FIXED record format files, a READ returns when it has read #length characters, or WIDTH characters if #length is not specified. For Unicode FIXED record format files, each READ obtains characters from a single RECORDSIZE bytes long record, and an untimed READ that needs a new record does not return until RECORDSIZE bytes are available.

The USE command can switch a device from NOFOLLOW to FOLLOW or from FOLLOW to NOFOLLOW. This provides a READ mode of operation similar to a tail -f in UNIX. [UNIX] (GTM-7540)

M-tracing correctly reports elapsed time per each executed line and label of M code. Previously, M-tracing reports could overestimate the elapsed time for certain lines (and labels, as a result) by an unusually large amount. (GTM-7588)

GT.M correctly parses parentheses around @x@() indirection. Previously, due to enhancements made in V6.0-000 for GTM-5896, commands with indirect arguments encased in parentheses such as COMMANDWORD (@x@()) or LOCK +(@x@()) gave INDEXTRACHARS errors at runtime. (GTM-7609)

When exiting, GT.M appropriately deals with internal timer resources. Previously, under very rare circumstances a terminating GT.M process could signal a GTMASSERT due to an unexpected timer start. [UNIX] (GTM-7611)

The ZALLOC command processes timeouts by resuming with the remaining time after a MUPIP INTRPT. Previously it resumed using a random time which could cause it to wait significantly less or more than the specified time. (GTM-7612)

GT.M compiles expressions with pathologically deep (hundreds) levels of nesting. Previously, compiling such expressions resulted in a segmentation fault. (GTM-7634)

Processes use a lightweight strategy in acquiring a fine granularity resource lock used for flushing blocks from the global buffers to secondary storage. Previously, it was possible for a process to unnecessarily wait for the resource when multiple processes were competing for it. While we are not aware of this having been an issue for customers, we identified this improvement from testing that showed secondary helper processes interfering with the update process. [UNIX] (GTM-7635)

GT.M properly handles issuing additional messages during error handling. Previously, in rare cases an INFO-level message could be issued while handling an ERROR or FATAL-level message, causing GT.M to proceed as if the original message were INFO-level. [UNIX] (GTM-7646)

While opening the syslog, GT.M defers the handling of signals (such as SIGTERM) that could lead to a process hang. Previously, there was a very small chance that a signal could interrupt a GT.M process in the middle of opening the syslog, thus causing the process to hang indefinitely. [UNIX] (GTM-7655)

GT.M appropriately processes an empty call-in table file. Previously, specifying an empty call-in table file could cause a segmentation violation (SIG-11) during an invocation of an M routine from C. [UNIX] (GTM-7674)

The $ZPEEK() intrinsic function provides a way to examine memory in the current process address space. It is intended as a tool to make it more convenient for FIS to access information in the address space of processes more efficiently than by calling out to external functions. It is documented here for completeness. While FIS normally maintains stability of GT.M functionality from release to release, this function is not designed for non-FIS usage, and FIS may change or eliminate this function at any time.

The $ZPEEK() function returns the contents of the memory requested as a string depending on the requested (or defaulted) formatting.

The format of the $ZPEEK() function is:

$ZPEEK("mnemonic[:argument",offset,length[,format])

Notes

$ZPEEK() has no UTF-8 checking. It is possible for values returned by the 'C' and 'S' codes to have invalid UTF-8 values in them. Take care when processing values obtained by these codes to either use "VIEW NOBADCHAR" when dealing with such values and/or use the $Zxxx() flavors of functions like $ZPIECE(), $ZEXTRACT(),etc which also do not raise BADCHAR errors when encountering invalid UTF-8 encoded strings. Note that $ZPEEK() with 8 byte numeric formatting can return numeric string values that exceed GT.M's current limit of 18 digits of precision. If the values are used as strings, the extra digits are preserved, but if used arithmetically, the lower precision digits can be lost. When values from replication structures are requested and the structures are not available due to replication not running or, in the case of the gtmrecv.* control block base options, if not running on a non-primary instance where the gtmrecv.* control are available, a ZPEEKNOREPLINFO error is raised.

(GTM-7685)

ZGOTO level:entryref within INTRPT code where level specifies the base level of the INTRPT stays within the INTRPT context and the resulting M stack frame shows up in ZSHOW "S[TACK]" output. Previously this odd action created a state that incompletely removed the INTRPT context and created an M stack frame that ZSHOW "STACK" hid. (GTM-7702)

GT.M issues a FALLINTOFLST error if M code reaches a label with a formallist as a result of a "fall-through" from the previous label. Prior to V5-5.000 GT.M issued an ACTLSTEXP error in such situations, but in the subsequent releases falling through to a label with a formallist could erroneously trigger an ACTLSTTOOLONG error, leading to abnormal process termination in certain situations. (GTM-7703)

GT.M uses %GTM to introduce messages in the syslog. Starting in V54001 GT.M messages started with two percent signs (%%GTM). [UNIX](GTM-7713)

For T greater than or equal to .001, "HANG T" suspends execution for no less than the T seconds. As in previous versions, "HANG T" where T is less than .001 is treated as equivalent to "HANG 0". Previously, if the argument to a HANG command contained more than three decimal places, the command would round down to the nearest second. (GTM-7718)

MUPIP RUNDOWN issues a MUUSERLBK error on a previously crashed replication-enabled database with BEFORE IMAGE journaling, and MUUSERECOV error in case of a non-replicated or NOBEFORE-journaled database. To bypass the errors and proceed with the rundown, MUPIP RUNDOWN requires an OVERRIDE qualifier. Previously, MUPIP RUNDOWN would perform a rundown regardless of the replication and journaling state of the database, thus complicating data recovery from a journal file or another replicated instance. [UNIX] (GTM-7420)

MUFILRNDWNFL, MUJPOOLRNDWNFL, MURPOOLRNDWNFL and MUFILRNDWNFL2 messages have the error (E) type. Previously, these messages had the informational (I) type; there is no change in behavior - only in the displayed message. (GTM-7447)

When MUPIP encounters problems getting standalone access to a database, in addition to MUSTANDALONE or SYSCALL errors, it may report an FTOKKEY message, a SEMID message, or additional SYSTEM-E-ENO* messages, depending on the particular circumstances. Previously, MUPIP did not provide this error detail. [UNIX](GTM-7518)

MUPIP RUNDOWN does not issue an error if another process concurrently removes a shared memory identifier RUNDOWN has identified for removal. Previously in such a situation, MUPIP RUNDOWN issued an error and created a state that caused subsequent startups to issue one of the following errors: REQRECOV, REQROLLBACK or REQRUNDOWN. [UNIX] (GTM-7568)

MUPIP REORG and MUPIP SIZE SCAN work safely with MM databases. Previously, due to a regression introduced in V6.0-000, in the presence of concurrent file extensions, running either utility could have resulted in a SIG-11. In addition, DSE DUMP -FILEHEADER reports a reduced number of Non-TP retries. Previously, unnecessary retries internal to MUPIP SIZE SCAN could have inflated the number displayed by DSE. Also, MUPIP SIZE SCAN gives a more reliable approximation for BG databases. Previously, a rare concurrent event could have distorted the results. [UNIX] (GTM-7592)

MUPIP RUNDOWN protects against possible inappropriate results from the UNIX ipcs utility. In its argumentless form, MUPIP RUNDOWN captures output from the UNIX ipcs utility in order to locate GT.M IPC resources. Previously, a buffer not protected against possible overflow from a subverted ipcs could potentially cause the MUPIP RUNDOWN process to misbehave. Note that any misbehavior would be limited by the access permissions of files and shared memory segments accessible to the userid and groups of the MUPIP process. Also, there was no misbehavior from any normal ipcs output. [UNIX] (GTM-7616)

MUPIP REPLIC -FREEZE=OFF, on a frozen instance, works when a Receiver Shutdown command is already in progress. Previously, attempting to release an instance freeze when a Receiver Shutdown command was already in progress resulted in a deadlock. The work around was to identify the shutdown command (with the string "-receiver -shutdown" in the ps process listing) and issue a MUPIP STOP on that process. Reissuing the shutdown command after this took care of completing the previously interrupted shutdown command. [UNIX] (GTM-7639)

MUPIP JOURNAL -EXTRACT appropriately handles signals, such as SIGTERM, within an identified time window. Previously, MUPIP journal extract could terminate abnormally if it encountered a signal interrupt within a certain, very short time window. [UNIX] (GTM-7650)

An ONLINE INTEG started by a process having read-only access to database files creates snapshot files with ownership and permissions identical to those it would use for shared memory if it were the first process to open that database file. Previously, such an ONLINE INTEG process created snapshot files without providing write permissions to other processes updating the database; this eventually caused the INTEG to fail with REGSSFAIL error. [UNIX] (GTM-7652)

MUPIP INTEG -REGION on MM databases works even if the process only has read permissions on the database. Previously, such a MUPIP INTEG -REG issued DBRDONLY error and continued to the next region. (GTM-7653)

MUPIP now properly sets exit status on error. Previously, exit status could be zero (0) after errors encountered during database rundown. [UNIX] (GTM-7666)

GT.M better maintains the snapshot file used for MUPIP INTEG -ONLINE. Previously, an odd condition could result in an EFAULT error and prevent the INTEG from completing. [UNIX] (GTM-7682)

MUPIP SET -FILE -MUTEX_SLOTS=integer maintains the size of a structure GT.M uses to manage contention for the principal critical section for a database. The minimum value is 1024, which is also the default; the maximum value is 32768. This MUPIP SET option requires standalone access. DSE DUMP -FILEHEADER output shows the current value for this field with the label: "Mutex Queue Slots". When there are many processes contending for database access, if this structure cannot accommodate all the waiting processes, GT.M performance can become erratic and poor. Therefore, FIS recommends setting this value to a minimum of slightly more than the maximum number of concurrent processes you expect to access the database. Previously, GT.M fixed the size of this structure at 1024 slots, which was adequate for most environments; DSE DUMP -FILEHEADER formerly displayed a field "Mutex Spin Sleep Time" which is now obsolete and replaced by "Mutex Queue Slots". (GTM-7683)

MUPIP JOURNAL -ROLLBACK appropriately invalidates the shared memory identifier (shmid) of the Receive Pool stored in the replication instance file. Previously, in environments configured for Instance Freeze, MUPIP JOURNAL -ROLLBACK did not appropriately invalidate this stored identifier, causing subsequent Receiver Server restarts to terminate with a GTMASSERT. The work around was to issue a MUPIP RUNDOWN -REG "*" before restarting the Receiver Server. [UNIX](GTM-7698)

In environments configured for Instance Freeze, argumentless MUPIP RUNDOWN now removes IPC resources associated with Journal Pool on the Originating and/or the Replicating instance. Previously, in Instance Freeze environments, such IPC resources were not removed by argumentless MUPIP RUNDOWN. [UNIX] (GTM-7706)

In order to not unnecessarily tie up a device which they do not use, the replication Source and Receiver Servers ensure their standard input device is assigned to /dev/null. Previously, they retained whatever device with which they were started. [UNIX](GTM-7708)

An update process reader helper moves on to the next block when it finds the data block it is attempting to pre-read is already being read by some other process. In limited benchmarking this seems to make the update reader helpers more effective when a replicating instance is processing a high level of updates. Previously, an update reader helpers waited like other processes for any block it was trying to access to complete a concurrent read. (GTM-7715)

The Source Server robustly reads journal records from the journal files. Previously, in certain rare cases involving either a ROLLBACK (on a replicating instance) or a replication setup consisting of one or more tertiary instances, the Source Server terminated with GTMASSERT. [UNIX] (GTM-7721)

LKE SHOW/CLEAR -LOCK qualifier now accepts concatenations of $CHAR()/$ZCHAR() and graphic characters for resource argument subscripts, rejects incorrect subscript termination and empty subscript parenthesis, works properly when a comma or double-quote appears within a subscript string. Previously, any use of the concatenation operator would issue an error, $CHAR()/$ZCHAR() representation required a case sensitive $C()/$ZCH(), subscripts could be empty parenthesis or list of subscripts could be terminated with a comma, and using a double-quote or comma inside a subscript string gave unintended results.(GTM-6181)

DSE does not attach to a region after a VERMISMATCH error. Previously, VERMISMATCH was an informational message for DSE. This exception allowed DSE to attach the shared memory associated with a region having a different GTM version. While this behavior was consistent with the DSE design goal of being able to adjust anything, it ultimately seemed too dangerous for any benefit it might provide. (GTM-7545)

When reading DSE output, %DSEWRAP ignores duplicated file header output. It returns only the last duplicated file header information. Additionally, %DSEWRAP ignores GT.CM regions. To provide appropriate input for %DSEWRAP for a GT.CM region, the operator must do a file header dump on the computer where the GT.CM hosted database file resides.(GTM-7596)

The gtmsecshr wrapper program replaces control characters with asterisks (*) before sending messages to syslog. Previously control characters in $gtm_dist were sent unaltered to syslog, and if the syslog service did not suppress control characters, the log file's appearance could be altered by embedded control characters such as newlines, carriage returns and vertical tabs. [UNIX] (GTM-7617)

The gtm script now implements -help and -? command line options to assist new users. Previously using either option resulted in a GTM-E-CLIERR error message. [UNIX] (GTM-7679)

GDE correctly maps global names to corresponding regions. Previously, in some odd cases where name specification ended in "*" to correctly specify a range, GDE VERIFY failed causing GDE not to exit; and in other cases GDE exited, writing a new global directory which gave an INPINTEG error when read; even when they worked properly such cases sometimes showed maps that could be reduced to simpler form. (GTM-7681)

When the environment variable gtm_repl_instance is set, but the environment variable gtm_dist is not set, sourcing the gtmprofile file does not generate an error and leaves gtm_repl_instance with an appropriate value. Previously, sourcing gtmprofile with this combination of gtm_repl_instance and gtm_dist elicited the complaint "sed: -e expression #1, char 0: no previous regular expression" and cleared the existing value of gtm_repl_instance. [UNIX] (GTM-7689)

GDE SHOW COMMANDS generates proper output if the * namespace is mapped to a region other than DEFAULT ($DEFAULT in VMS) OR the DEFAULT segment ($DEFAULT in VMS) is renamed. Previously if the GDE SHOW COMMANDS output for the above cases were fed to a fresh GDE session, it would fail verification and issue a OBJNOTFND error. (GTM-7700)

GTMSECSHR messages to the syslog start with "%GTM". [UNIX] (GTM-7707)