MUPIP TRIGGER limits trigger expression source lines to 80 characters including a trailing ellipsis to indicate there was more text, and they also replace any non-graphic characters with a dot (.) Previously, such messages had non-graphic characters represented by OS or terminal [emulator] conventions and no embedded indication of the truncation. [UNIX](GTM-6900)

GT.M maps trigger definitions to the region to which they apply. Previously, it mapped them partially to the default region of the global directory in use at the time of their definition, which caused documented limitations and pitfalls when using multiple global directories or spanning regions. A $ZTRIGGER() or MUPIP TRIGGER action (delete or select) applies to all triggers in all regions matching the specified signature. If the argument specifies an incomplete trigger signature, for example, only the name, the specification may match multiple triggers and apply the delete or select to all of them. FIS recommends you run a select and analyze the scope of the signature before any signature limited delete. GT.M allows defining triggers with the same name and signature in different regions, but does not allow defining triggers with the same name in different regions within the same global directory if they have different signatures; previously it allowed neither. When loading a trigger definition, if a user-defined name conflicts with a name in any region to which the trigger applies, $ZTRIGGER() and MUPIP TRIGGER report an error. However, when the name is auto-generated, they generate a name in every region, so if there are multiple (spanning) regions, the same trigger might have a differing auto-generated name in each region.

Trigger definitions are subject to the same maximum record length checks as documented for other GT.M components; when GTM-6341 changed the definition changed in V6.0-000, trigger definitions retained the prior convention. A trigger deletion attempt on a read-only database fails with a TRIGMODREGNOTRW error, but only if the attempt specifies existing triggers; previously it failed even if there were no matching triggers to delete.

GT.M manages concurrent trigger definition updates appropriately. Previously, in the unlikely circumstance of conflicting trigger definition updates, a process could get a segmentation violation (SIG-11). ZPRINT of a trigger concurrently being deleted produces the trigger source; previously it caused a GTMASSERT.

$ZTRIGGER() and MUPIP TRIGGER skip regions with a GT.CM (client) access method; previously, using these facilities with a global directory caused a segmentation violation (SIG-11) on the client if the corresponding server was active..

ZPRINT/$TEXT()/ZBREAK recognize both a runtime-disambiguator, delimited with a hash-sign (#), and a region-disambiguator, delimited by a slash(/); previously they supported only the runtime-disambiguator. ZPRINT and ZBREAK treat a trigger-not-found case as a TRIGNAMENF error, while $TEXT() returns the empty string. When their argument contains a region-disambiguator, these features ignore a null runtime-disambiguator. When their argument does not contain a region-disambiguator, these features act as if runtime-disambiguator is specified, even if it has an empty value. When an argument specifies both runtime-disambiguator and region-disambiguator and the runtime-disambiguator identifies a trigger loaded from a region different from the specified region, or the region-disambiguator identifies a region which holds a trigger that is not mapped by $ZGBLDIR, these features treat the trigger as not found. Here are some examples of disambiguator combinations:

ZPRINT ^x#/BREG      : Print           trigger routine user-named "x" in region BREG
ZPRINT ^x#1#/BREG    : Print           trigger routine auto-named "x#1" in region BREG
ZPRINT ^x#1#A/BREG   : Print           trigger routine auto-named "x#1", runtime disambiguated by "#A", AND in region BREG
ZPRINT +1^x#1#A/BREG : Print line 1 of trigger routine auto-named "x#1", runtime disambiguated by "#A", AND in region BREG

DSE accepts ^#t as a valid global name when specifying a key; previously it treated ^#t as invalid. Also, DSE uses the same maximum record length checks as documented for other GT.M components; when GTM-6341 changed the definition changed in V6.0-000, DSE retained the prior convention. [UNIX]( GTM-7641)(GTM-6901)

$ZTRIGGER() and MUPIP TRIGGER do not require a delete specified with a wild-card (*) to find any matching triggers, but rather report this in the action summary. Previously they treated this as an error. [UNIX](GTM-7076)

MUPIP TRIGGER -UPGRADE upgrades older trigger definitions into current format. If GT.M encounters an old trigger definition it produces a NEEDTRIGUPGRD message. To preserve the possibility of a straightforward downgrade to an earlier version, perform a select "*" action with MUPIP TRIGGER (or $ZTRIGGER() and save the result. Note that TRIGGER -UPGRADE assumes that the existing trigger definitions are properly defined; if the prior release has produced defective triggers delete them with a wild-card ("*") and redefine them in the new release. In the event of a downgrade, delete "*" all triggers before the downgrade and insert the saved version from before the upgrade. Attempting to perform a MUPIP TRIGGER -UPGRADE on a database without write authorization to the database produces a TRIGMODREGNOTRW error. [UNIX] (GTM-7083)

$ZTRIGGER()and MUPIP TRIGGER always operate within a TP transaction even if they need to implicitly create one to encapsulate their work. These trigger maintenance operations reserve their output until the transaction commits (TCOMMIT where $TLEVEL goes to zero) at which time they deliver the entire output consistent, including that for all $ZTRIGGER() invocations in the successful processing of a larger transaction, to the $IO current at that ultimate TCOMMIT. If an explicit transaction ends with a TROLLBACK, it does not produce any $ZTRIGGER() output. Previously, $ZTRIGGER() produced potentially inappropriate error reports indicating name collisions where none existed, and also incorrect, differing, and in cases of RESTARTs, multiple, outputs. Trigger definition reporting operations, $ZTRIGGER("SELECT",) and MUPIP TRIGGER -SELECT, return a non-zero exit status when their selection criteria encounter an error in the middle of the select. Previously, under a variety of conditions, these operations returned a success indicator even though the operation actually failed. MUPIP TRIGGER -SELECT now displays all output on stdout. Previously it displayed valid output on stdout and error output on stderr. [UNIX](GTM-7522)

See GTM-6901. (GTM-7641)

In cases where a KILL trigger shared some common characteristics (e.g. global name, XECUTE string etc.) with one or more SET triggers, $ZTRIGGER() and MUPIP TRIGGER appropriately establish the KILL trigger. Previously, they could set up an inappropriate KILL trigger, corrupt the trigger database or issue an incorrect TRIGDEFBAD error. In addition, if a specified trigger signature otherwise exactly matches an existing trigger, any -options specified in the specification replace any -options in the existing trigger. However, if the command portion of the input definition only partially matches an existing trigger, $ZTRIGGER() and MUPIP TRIGGER issues an error. Previously the trigger update facilities added the specified -options to any existing options. Similar to the trigger update -options handling, the trigger update facilities allow changing the name of an existing trigger only if the every other element of the definition signature matches an existing trigger. Previously the specified -name replaced the existing trigger name even when the command portion of the input definition only partially matched an existing trigger. Also, the error handling, output and error messages for trigger loads, selects and deletes changed to improve clarity, completeness and consistency. Finally, the trigger update facilities ignore -options specified for trigger deletes; previously if a delete included a -options specification, the delete inappropriately removed the options from definitions of similar remaining triggers with differing command characteristics. [UNIX](GTM-7678)

Access statistics for global variables include the following items:

CAT - total of critical section acquisitions successes
CFE - total attempts in CFT caused by epochs
CFS - sum of squares of blocked critical section acquisitions
CFT - total of blocked critical section acquisitions
CQS - sum of squares of critical section acquisition queued sleeps
CQT - total of critical section acquisition queued sleeps
CYS - sum of squares of critical section acquisition processor yields
CYT - total of critical section acquisition processor yields

Note that statistics reported by $VIEW() or DSE output are those for the database region, while those reported by ZSHOW "G" output are process-specific.

$VIEW("PROBECRIT",<region>) acquires and releases a critical section for the region (the "probe"), returning a string with the following fields:

CPT - nanoseconds for the probe to get the critical section
CFN - number of failures of the probe to get the critical section
CQN - number of queue sleeps by the probe
CYN - number of process yields by the probe
CQF - number of queue fulls encountered by the probe
CQE - number of empty queue slots found by the probe
CAT - total of critical section acquisitions successes

[UNIX](GTM-7779)

When Instance Freeze is in effect, GT.M seldom produces MUTEXLCKALERT messages in the operator log; previously it frequently produced such messages. [UNIX](GTM-7843)

GT.M triggers now apply to spanning regions (which means the TRIGNOSPANGBL error is obsolete). When $ZTRIGGER() or MUPIP TRIGGER define triggers that apply to globals spanning multiple regions, each of the spanned regions install a definition. In the example below, ^example is a non-spanning global and ^example2 spans AREG, BREG and DEFAULT:

File tmp4.trg, Line 1: All existing triggers (count = 2) deleted
File tmp4.trg, Line 5: Added Non-SET trigger on ^example named example#1
File tmp4.trg, Line 6: Added Non-SET trigger on ^example2 (region AREG) named example2#1
File tmp4.trg, Line 6: Added Non-SET trigger on ^example2 (region BREG) named example2#1
File tmp4.trg, Line 6: Added Non-SET trigger on ^example2 (region DEFAULT) named example2#1
File tmp4.trg, Line 11: Modified SET and/or Non-SET trigger on ^example named example#1

note unlike the output for the spanning region global ^example2, the output for the single-region global ^example does not include the region. The "select" and "delete-by-trigger-name" operations report the region for the trigger, regardless of whether the global name corresponding to this trigger spans regions or not. [UNIX](GTM-7877)

Deletion of a trigger with wildcards using $ZTRIGGER() or MUPIP TRIGGER works correctly. Previously if more than one trigger matched the specified wild-card and corresponded to the same global name which was also greater than 21 characters, it caused a segmentation violation (SIG-11). [UNIX](GTM-7947)

Specifying a trigger name with a trailing wild-card in $ZTRIGGER() and MUPIP TRIGGER selects all triggers that start with the prefix before the asterisk (*); previously it only selected triggers matching the prefix that were mapped to the same region as the first name that matches. Specifying a trigger name more than once in a list of names selects the trigger just once; previously this caused a segmentation violation. [UNIX](GTM-7974)

$ZTRIGGER() and MUPIP TRIGGER update operations enforce a limit of 8KiB bytes per line and a total of 1MiB bytes for a multi-line trigger XECUTE string. Previously, exceeding the limits could cause a segmentation violation (SIG-11) [UNIX](GTM-7985)

VIEW "GVSRESET"[:"<region>"] resets the process-specific fields that are part of the ZSHOW "G" result and database file header fields holding records reported by: GVSTAT, BG trace, buffer pool accounting and the TP block modification details. Note a VIEW "GVSRESET" performed by a process with read-only database access changes only the process-specific information and has no effect on the database file header. DSE CHANGE -FILEHEADER -GVSTATSRESET clears the same database file header fields as VIEW "GVRESET"; previously it only cleared the records for GVSTAT. In addition, regions for VIEW and $VIEW() arguments with region elements treat region names as case insensitive, and, in VIEW command cases where a missing region element means all regions, accept a region name of "*" as meaning all regions. Previously region name elements in VIEW command arguments did accept "*" and required upper-case, as did $VIEW() region arguments. (GTM-8106)

Available as field test grade functionality in a production release, VIEW "POOLLIMIT":<region>:expr, where expr is of the form n[%] provides a mechanism for a process that has the potential to "churn" global buffers to limit the potential impact on other processes by restricting the number of global buffers it uses. If the expression ends with a per-cent sign (%), the number is taken as an as a percentage of the configured global buffers and otherwise as an ordinal number of preferred buffers; standard M parsing and integer conversions apply. Preferred buffer values are limited to between 32 and one less than half the buffer pool inclusive; with the exception of zero (0) or 100 per cent, which turn off the limitation; specifications exceeding those limits provide the value of the nearer limit. If the argument specifies "*" for the region, the command applies to all regions. $VIEW("POOLLIMIT",<region>) returns the current value for the region as an ordinal number - zero (0) when there is no limit in place. Note that this facility is designed for use by a relatively small subset of processes. In addition, MUPIP REORG uses this facility to limit its buffers to a value established by the UNIX environment variable (or OpenVMS logical name) gtm_poollimit using the syntax described for VIEW "POOLLIMIT" with a default of 64 if gtm_poollimit is not specified. Note that this may slightly slow a standalone REORG but can be overridden by defining gtm_poollimit as 0 or "100%". Previously REORG used all of the available buffer pool and thus could have a larger impact on concurrent processing. (GTM-8191)

GT.M replicates $ZTWOrmhole correctly when the originating and replicating instance do not use the same null collation; previously, in an especially rare case, which required using $ZTWOrmhole, it could be modified during replication. [UNIX](GTM-8207)

When a JOB command specifies the PASSCURLVN jobparameter, the new process inherits the current collation, all locals, aliases, and alias containers from the JOB'ng process' current stack level. As a result of this, a ZWRITE issued in the JOB'd process has the same output, except for any out of scope aliases, as a ZWRITE in the context of the JOB command. If the JOB command finds a ZWRITE representation of any lvn, consisting of a its full name, its subscripts, corresponding value, quotes and the "=" sign, exceeding 1MiB, it produces an JOBLVN2LONG error both in the JOB'ng process and in the JOB'd processes error output stream. If a JOB command does not specify PASSCURLVN, the JOB'd process(es) inherits no local variables from the parent. While not an inexpensive command, you can use the "exclusive" NEW command to control the context passed to the JOB'd process; for example, adding "NEW (LOCALA, LOCALB)" before the JOB command would pass only LOCALA and LOCALB. [UNIX](GTM-4414)

ZWRITE and ZSHOW "V" do not add spaces within a given local variable's corresponding value. Previously, both of the commands could insert spaces at the beginning of every line after the first. (GTM-5022)

SOCKET devices support encrypt connections with TLS using an encryption plugin. GT.M ships with a reference implementation of the plugin which uses OpenSSL and also supports TLS of replication stream. OpenSSL options are controlled by a configuration file. The WRITE /TLS command activates this feature for connected sockets. Because this functionality has a wide variety of user stories (use cases) and has substantial complexity, although the code appears robust, we are not confident that we have exercised a sufficient breadth of use cases in testing. Also we may make changes in future releases that are not entirely backwards compatible. We encourage you to use with this facility in development and testing, and to provide us with feedback. If you are an FIS customer and wish to use this in production, please contact us beforehand to discuss your use case(s).

The WRITE /TLS command has the form:

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

where option is "server" or "client" indicating which TLS role to assume or "renegotiate" which is used by a server to request a new handshake to reevaluate the client credentials. The server role requires a certificate specified in the configuration file section with the label matching tlsid. The client role may require a certificate depending on the OpenSSL options. If the argument specifies a timeout, GT.M sets $TEST to 1 if the command successfully completed or to 0 if it timed out. $DEVICE provides status information in case of an error. ZSHOW "D" includes "TLS" in the second line of the output for an encrypted socket.

Note that SOCKET device actions may produce the following previously documented errors (all with a TLS prefix and previously only issued by MUPIP for a TLS replication stream): TLSDLLOPEN, TLSINIT, TLSCONVSOCK, TLSHANDSHAKE, TLSCONNINFO, TLSIOERROR, and TLSRENEGOTIATE.

The TLS plugin uses OpenSSL options in the configuration file specified under the tls: label as the default for all TLS connections and under the specific labels to override the defaults for corresponding connections. Previously, GT.M recognized a more limited set of OpenSSL options under the tls: label and only certificate related items under the lower level labeled sections. In addition to the previous items allowed in the tls: section of the configuration file for TLS replication, GT.M recognizes the following for both sockets and TLS replication:

When placing the private key for a certificate at the beginning of the certificate file, you may omit the "key" item from the configuration file. The format of the combined file is:

             -----BEGIN RSA PRIVATE KEY-----
             [encoded key]
             -----END RSA PRIVATE KEY-----
             [empty line]
             -----BEGIN CERTIFICATE-----
             [encoded certificate]
             -----END CERTIFICATE-----
             [empty line]

GT.M buffers WRITEs to TLS enabled sockets until a subsequent USE :FLUSH, WRITE !, WRITE #, or an internal 400 millisecond timer expires.

Owing to the range of OpenSSL versions in use across the breadth of platforms and versions supported by GT.M, on all platforms, but especially on non-Linux UNIX platforms, FIS recommends rebuilding the plugin from sources included with the GT.M binary distribution with the specific version of OpenSSL installed on your systems for any production or production staging environments that use TLS. Please also review & edit the following common header and library paths in the Makefile to reflect those on your systems when you rebuild the plugin.

# Common header and library paths
IFLAGS += -I /usr/local/ssl/include -I /usr/local/include -I /usr/include -I $(gtm_dist) -I $(CURDIR)
ifeq ($(BIT64),0)
 LIBFLAGS += -L /usr/local/ssl/lib -L /usr/lib/x86_64-linux-gnu -L /usr/local/lib64
 LIBFLAGS += -L /usr/local/lib -L /usr/lib64 -L /usr/lib -L /lib64 -L /lib -L `pwd`
else
 LIBFLAGS += -L /usr/local/ssl/lib -L /usr/lib/x86-linux-gnu -L /usr/local/lib32
 LIBFLAGS += -L /usr/local/lib -L /usr/lib32 -L /usr/lib -L /lib32 -L /lib -L `pwd`
endif

[UNIX](GTM-7418)

On the rare occasions GT.M or its utilities add or change an environment variable, they protect the operation against interruption by a signal (such as SIGTERM). Previously, there was a very small chance a signal could interrupt a GT.M process in the middle of adding or changing an environment variable, causing the process to hang indefinitely. This issue was discovered in the GT.M development environment and was never reported by any user. [UNIX] (GTM-7914)

CMakeLists.txt now builds all three of the reference implementation encryption libraries. Previously it built only the reference implementation that worked with libgcrypt. [UNIX](GTM-7929)

If an OPEN command argument for a PIPE device specifies the PARSE deviceparameter and a COMMAND that GT.M cannot locate and the PATH environment variable has not been defined for the process, the DEVOPENFAIL message contains these circumstances. Previously, this combination of conditions caused a segmentation violation (SIG-11). [UNIX](GTM-7964)

GT.M reports ZLINKFILE/ZLMODULE errors when a routine name in the corresponding object file does not match the routine name specified with $gtm_dist/mumps -run <routine-name>. The mismatch can arise from moving an object file to a different name or compiling with the -NAMEOFRTN option on the mumps command. This matches the report produced by direct mode in response to the same circumstance. Previously this raised a GTMASSERT2 referencing job_addr.c. [UNIX](GTM-8068)

A GT.M process (including utilities) that cannot start a child process handles and reports the error appropriately; previously such an error could cause a failure in the parent process and/or produce misleading error messages. This issue was discovered in the GT.M development environment and was never reported by any user. [UNIX](GTM-8094)

When $PRINCIPAL identifies a device that supports REWIND, the REWIND or INREWIND device parameters perform a REWIND of the input and OUTREWIND performs a REWIND of the output. Previously, no REWIND of the output side of $PRINCIPAL was possible. [UNIX](GTM-8132)

When $PRINCIPAL input and output are different devices, ZSHOW "D" shows them as separate items identified as 0 for input and 0-out for output. Note: algorithms processing ZSHOW "D" output may need adjustment. If they process output saved to a variable the additional output line[s] must be accounted for by $ORDER() or an integer iteration. Previously, ZSHOW "D" only provided the input side of the device. [UNIX](GTM-8134)

$ZSEARCH() range (0-255) checks its stream argument; previously it silently used a stream matching stream#256. This was fixed in V6.2-000, but not documented in the original release notes. (GTM-8146)

GT.M loads an object file linked from an object directory (in $ZROUTINES) with a *-suffix (i.e. auto-relink-enabled) into a shared memory segment (referred to henceforth as a Rtnobj shared memory segment). In V6.2-000 this was in mmap() memory which could increase the number of file descriptors required.

For each auto-relink enabled directory which a GT.M process accesses while searching through $ZROUTINES, GT.M creates a small control file (Relinkctl) in the directory identified by $gtm_linktmpdir (defaulting to $gtm_tmp, which in turn defaults to /tmp, if unspecified). The names of these files are of the form gtm-relinkctl-<murmur> where <murmur> is a hash of the realpath() to an auto-relink directory; for example: /tmp/gtm-relinkctl-f0938d18ab001a7ef09c2bfba946f002). With each Relinkctl file, GT.M creates and associates a block of shared memory that contains associated control structures. Among the structures is a cycle number corresponding to each routine found in the routine directory; a change in the cycle number informs a process that it may need to determine whether there is a new version of a routine. Although GT.M only creates relinkctl records for routines that actually exist on disk, it may increment cycle numbers for existing relinkctl records even if they no longer exist on disk.

GT.M creates both the Relinkctl file and shared memory with permissions based on the logic described in the "IPC Permissions" column of the "Shared Resource Authorization Permissions" section in the Administration and Operations Guide, except that the object directory, rather than the database file, provides the base permissions.

An auto-relink-enabled directory uses one or more Rtnobj shared memory segments to store the object (.o) files, creating the first one when linking the first object file from an auto-relink-enabled directory. By default, GT.M creates an initial Rtnobj shared memory segment of 1 MiB. You can control this size by defining an environment variable gtm_autorelink_shm to an integer value in MiB. If the value of gtm_autorelink_shm is not a power of two, GT.M rounds the value to the next higher integer power of two. If the first object (.o) file does not fit in a new Rtnobj segment, GT.M rounds the allocation up to the smallest integer power of two required to make it fit. When GT.M needs room for object files, and existing Rtnobj segments have insufficient free space, it creates an additional shared memory segment, double the size of the last. Note that when hugepages are enabled, the actual Rtnobj shared memory size might be more than requested implicitly or explicitly through $gtm_autorelink_shm.

GT.M creates Rtnobj shared memory with the same permissions as Relinkctl shared memory, as described above, but with execute permissions enabled to correspond with read permissions.

The MUPIP RCTLDUMP command reports information related to relinkctl files and their associated shared memory segments. The syntax is MUPIP RCTLDUMP [dir1]. If the optional parameter dir1 is not specified, MUPIP RCTLDUMP dumps information on all its active auto-relink-enabled directories (those with with a *-suffix) identified by $gtmroutines. With a directory path specified for dir1, MUPIP RCTLDUMP reports information on the one directory. An example output follows. It lists the full path of the Object directory; its corresponding relinkctl file name; the number of routines currently loaded in this relinkctl file; the number of processes including the reporting MUPIP process that have this Relinkctl file open; the shared memory id and length of the Relinkctl shared memory segment; one or more Rtnobj shared memory segment(s); and a listing of all the routine names loaded in this file (lines starting with rec#...).

> mupip rctldump .
Object Directory         : /obj
Relinkctl filename       : /tmp/gtm-relinkctl-f0938d18ab001a7ef09c2bfba946f002
# of routines            : 1
# of attached processes  : 2
Relinkctl shared memory  : shmid: 11534344  shmlen: 0x57c6000
Rtnobj shared memory # 1 : shmid: 11567113  shmlen: 0x100000  shmused: 0x200  shmfree: 0xffe00  objlen: 0x1c0
    rec#1: rtnname: abcd  cycle: 1  objhash: 0xedbfac8c7f7ca357  numvers: 1  objlen: 0x1c0  shmlen: 0x200

Two lines need more explanation.

Given a relinkctl file name, one can find the corresponding directory path using the Unix "strings" command on the Relinkctl file. For example, "strings /tmp/gtm-relinkctl-f0938d18ab001a7ef09c2bfba946f002", corresponding to the above MUPIP RCTLDUMP output example, would output "/obj" the corresponding directory name.

The environment variable gtm_autorelink_keeprtn if set to 1, t[rue], or y[es] causes exiting processes to leave auto-relinked object code in the shared memory repositories, while if undefined, 0, f[alse] or n[o] causes exiting processes to purge any routines currently use by no processes. All values are case-independent. When gtm_autorelink_keeprtn is defined and TRUE:

ZSHOW "A" (A code to mean Autorelink) provides output in the same format as MUPIP RCTLDUMP, but restricted to the routines linked by the process issuing the command. ZSHOW "*" does not include ZSHOW "A" because of an expectation that the typical volume of the information does not provide a good return for its value. If you wish your error handling or INTRPT routines to dump this information, ask for it explicitly, possibly by doing a ZSHOW "A" into a local variable before doing a ZSHOW "*".

GT.M does not support VIEW "RCTLDUMP" as it has been supplanted by ZSHOW "A" and MUPIP RCTLDUMP.

The MUPIP RUNDOWN -RELINKCTL command cleans up orphaned Relinkctl files. FIS strongly recommends avoiding actions that tend to make such cleanup necessary - for example, kill -9 of GT.M processes or ipcrm -m of active Relinkctl and/or Rtnobj shared memory segments. The syntax is MUPIP RUNDOWN -RELINKCTL [dir1]. If the optional parameter dir1 is not specified, MUPIP RUNDOWN -RELINKCTL examines the env var $gtmroutines, attempts to verify and correct their attach counts and runs down all its inactive auto-relink-enabled directories (those with with a *-suffix). Alternatively, one can specify a directory path for the parameter dir1 and MUPIP RUNDOWN -RELINKCTL treats it as an auto-relink-enabled directory and runs down the resources associated with this one directory. It prints a RLNKCTLRNDWNSUC message on a successful rundown and a RLNKCTLRNDWNFL message on a failure (usually because live processes are still accessing the Relinkctl file).

GTM issues a REQRLNKCTLRNDWN message if it finds evidence of need for a rundown of the Relinkctl file (e.g. processes killed using kill -9 or relinkctl/rtnobj shared memory segments removed using ipcrm -m).

FIS recommends that a directory in the $zroutines of a process be either auto-relink-enabled or auto-relink-disabled for the life of the process. Changing the auto-relink mode of the directory within a process is likely to result in counter-intuitive results.

As arguments, ZRUPDATE takes object file names, including wild-cards of the form accepted by $ZSEARCH(). If ZRUPDATE fails to find at least one file to match an argument with a wild card, it issues an INFO message (seen only if $PRINCIPAL has CENABLE). When an explicit name without a wild card is specified, but there is no file in the directory or a corresponding entry in the Relinkctl, ZRUPDATE produces an error. ZRUPDATE issues most errors as FILEPARSE errors with a secondary error describing the actual issue although some errors, depending on the reason and path by which ZRUPDATE detects them, can be rather cryptic. In V6.2-000, some wild card handling was incorrect.

An explicit ZLINK or an auto-relink check the hash of an object and its replacement. If they are identical, GT.M takes no action to replace the current object, saving both memory and time.

An explicit ZLINK from an auto-relink directory acts as an implicit ZRUPDATE.

Any ZBREAK in a routine disables that routine from auto-relinking by a process until all ZBREAKs are removed.

The $gtmroutines value set by the gtmprofile file enables auto-relink by default for object files in the $gtmdir/$gtmver/o directory in M mode, and $gtmdir/$gtmver/o/utf8 in UTF-8 mode.[UNIX](GTM-8160)

GT.M schedules and delivers user-initiated timed events, such as HANGs and gtm_start_timer() call-in invocations, with the highest accuracy available to GT.M via standard operating system calls. Note that GT.M ensures that the HANG or other operation waits for at least as long as the specified time; the actual time depends on when the process gets resources to allow it to resume execution depends on the operating system. Previously, GT.M scheduled such events with both an extended duration and highest accuracy of 10ms. [UNIX] (GTM-8168)

GT.M appropriately manages old copies of recursively linked routines when they retire from use. Previously, GT.M did not release the parts of a recursively linked routine when the last instance of the old (replaced) routine left the M virtual-machine stack due to a QUIT or ZGOTO. ZBREAKs in the replaced routine increased the size of the memory leak. [UNIX] (GTM-8172)

Raising zero to a negative power (0**-x) produces a DIVZERO error; previously it returned 0, which was inconsistent with the result of dividing by zero: i.e. 1/(0**x). (GTM-8174)

When GT.M encounters problems creating object files it follows GT.M error handling protocol; in V6.2-000 such errors sent text of the form: " tmp_object_file_name: ..." to $PRINCIPAL. [UNIX] (GTM-8181)

GT.M uses a 128 bit hash based on the MurmurHash3 algorithm, for source file text identification as visible in the output of ZSHOW "R" and $VIEW("RTNCHECKSUM",rtn). MUPIP HASH <file-names> provides the hash of source files from the command line. Previously GT.M used an MD5 hash. [UNIX](GTM-8194)

WRITE /WAIT with no timeout appropriately resumes waiting for a socket event after processing an INTRPT; previously it could return prematurely with no socket selected. In UNIX, WRITE /WAIT on a socket which has an error condition appropriately defers reporting the error until the next command that accesses the socket; starting with V6.1-000 WRITE /WAIT on a socket with an error condition could result in a GTMASSERT. (GTM-8196)

$ZPEEK() accepts the following keyword first arguments:

 
JNL[REG]:region - to obtain fields in the jnl_private_control structure.
JBF[REG]:region - can obtain fields in shared jnl_buffer structure

The associated field mnemonics and characteristics are defined by the running the GTMDefinedTypesInit.m utility, which produces a cross-index in the form:

gtmtypfldindx(<structure-name>.<field-mnemonic>)=<n>

where gtmtypes(<structure-name>,<n>,*) nodes contain the field characteristics.$ZPEEK recognizes the "T" format code as selecting a $HOROLOG format for a field of 4 or 8 bytes which is intended for use on fields in UNIX time format (seconds since 01/01/1970).[UNIX](GTM-8204)

MUPIP LOAD detects file format (BINARY/ZWR/GO) based on the file header of extract files from MUPIP EXTRACT, ^%GO and DSE. If it cannot recognize the header, or if the detected format does not match that selected by the user supplied -FORMAT=(BINARY/ZWR/GO) qualifier, LOAD produces a LDBINFMT error. For example, MUPIP LOAD -STDIN of a BNIARY file using shell redirection for STDIN works with or without the -FORMAT=BINARY. Previously LOAD required the -FORMAT qualifier to recognize the BIN format, ignored the qualifier for GO and ZWR, and, when it did not recognize the header, it tried to skip the first two records and treat the file as GO format and could cause a segmentation violation (SIG-11) if the selection was -FORMAT=BIN, but the file was in GO format. [UNIX](GTM-6597)(GTM-7868)(GTM-8182)(GTM-227)

See GTM-227. (GTM-6597)

MUPIP REPLICATE -SOURCE -START accepts the -[NO]JNLF[ILEONLY] qualifier. Specifying -JNLFILEONLY forces the source server to read transactions from journal files instead of journal pool shared memory. When combined with the SYNC_IO journal option, this feature delays replication of transactions until their journal records are hardened to disk. This may be useful when replicating to a supplementary instance, as a crash and rollback on the primary could otherwise necessitate a rollback of local updates on the receiving instance. The default is -NOJNLFILEONLY. [UNIX] (GTM-7862)

See GTM-227. (GTM-7868)

The receiver process correctly handles large compressed messages (> 16 MiB before compression) which are partially read. Such messages can occur when there is a large backlog of journal records for this receiver on the source, though the particular circumstances required to encounter this issue are rare. Previously the messages could be handled incorrectly, resulting in a corrupt message, causing a zlib message to be written to the receiver log and compression to be disabled; otherwise, replication was unaffected. This issue was introduced with GTM-7743 in V6.1-000. [UNIX] (GTM-8081)

MUPIP LOAD reports an accurate key count; in prior releases, key counts above 2**32-1 wrapped to inappropriately smaller values. [UNIX](GTM-8175)

See GTM-227. (GTM-8182)

The Update Process correctly issues a REC2BIG error message when handling updates that exceed the configured maximum. Previously, the Update Process terminated with a segmentation violation (UNIX SIG-11, or OpenVMS ACCVIO) while issuing the REC2BIG error for a TP fenced update. This fixes a regression introduced in V6.0-003. (GTM-8185)

GT.M handles failures it encounters while opening database files correctly, issuing the appropriate error messages. Previously, on rare occasions, when it attempted to report such errors, it could produce a bus error (SIG-7) or segmentation fault (SIG-11). [UNIX] (GTM-8195)

The replication receiver server works correctly when connecting to a cross-endian source server running an older version of GT.M. In V62000 if the receiver connected to a source server running any version of GT.M from V55000 through V61000, it inappropriately exited with an INSNOTJOINED error . [UNIX](GTM-8205)

The MUINFOUINT6 message reports used in MUPIP JOURNAL -EXTRACT -DETAIL show $HOROLOG representations of times close, or prior, to UNIX Epoch (0 seconds on 1-Jan-1970) accurately; previously such times (typically 0), appeared to be a day too close to the current day. [UNIX] (GTM-8209)

The Update Process appropriately handles restarts that occur within trigger logic due to concurrent database activity (from MUPIP REORG or local updates on a Supplementary Instance). Previously in rare instances, the Update Process might get into an indefinite repetition of implicit TPRESTARTs recognizable by repeating TPRETRY messages in its log file. [UNIX](GTM-8210)

CMakeLists.txt now builds all three of the reference implementation encryption libraries (libgtcrypt: AES256, OpenSSL: AES256 and BLOWFISH). Previously it built only one reference implementation that used libgcrypt with AES256. [UNIX](GTM-7927)

A GT.M process (including utilities) that cannot start gtmsecshr puts a UNABLETOEXECGTMSECSHR message in the operator log; previously it used an inappropriate INVTRANSGTMSECSHR message. [UNIX](GTM-8093)

The maskpass utility restores terminal settings when terminated with a Ctrl-C or a TERM signal. Additionally, all other signals except SEGV, ABRT, BUS, FPE, TRAP, KILL, and STOP are ignored. Previously, it could leave the terminal in a state where an "stty sane" command would be required to restore terminal settings to a usable state. [UNIX] (GTM-8101)

Makefile shipped with the reference implementation of the GT.M encryption plug-in consolidates a number of related simplistic targets into more functional ones (such as 'maskpass', 'maskpass.o', and 'gtmcrypt_util_syslib.o' into 'maskpass'; 'gtmtls' and 'gtm_tls_impl.o' into 'libgtmtls.so'; and so on). Compilation and linking of shared libraries and executables occur in one step rather than individually. Each target announces the actions it is going to perform. The 'install' target copies the maskpass executable to the plugin's gtmcrypt subdirectory and safely overwrites the existing libgtmcrypt.so softlink rather than erroring out if it is present. AIX installations no longer print warnings about duplicate symbols. Targets correctly specify and resolve internal dependencies to minimize the risk of errors or redundant operations. [UNIX] (GTM-8153)