When MUPIP JOURNAL -ROLLBACK -ONLINE changes the logical state of a database it issues an ORLBKROLLED message to the system log. Previously, MUPIP did not announce this state change in the system log. (GTM-F217678)

In the event of failure to acquire the TLS password, the GT.M TLS reference plugin issues an appropriate error message. Previously, in some cases, failure to acquire the TLS password resulted in a garbled error message. (GTM-DE324947)

GT.M issues an NOSOCKETINDEV error the first time a process in direct mode attempts to read from or write to a socket principal device with no socket descriptors, and issues a fatal NOPRINCIO error upon a subsequent attempt. Previously a process that entered direct mode with an empty socket principal device would loop indefinitely and consume CPU resources. (GTM-DE533918)

$ZTIMEOUT presents the time remaining value to microsecond precision; previously it only showed time with precision in milliseconds or less. (GTM-DE534846)

The GT.M TLS plugin library exposes an external call interface providing ciphersuite and version information. The four new functions are:

getversion:                     xc_long_t gtm_tls_get_version(O:xc_char_t*[2048])
gettlslibsslversion:            xc_long_t gtm_tls_get_TLS_version(O:xc_char_t*[2048],I:xc_char_t*,O:xc_char_t*[2048])
getdefaultciphers:              xc_long_t gtm_tls_get_defaultciphers(O:xc_char_t*[4096],I:xc_char_t*,O:xc_char_t*[2048])
getciphers:                     xc_long_t gtm_tls_get_ciphers(O:xc_char_t*[4096],I:xc_char_t*,I:xc_char_t*,I:xc_char_t*,I:xc_char_t*,O:xc_char_t*[2048])

The following entry points provide the supported cipher suite information. Except where noted, the $gtmcrypt_conf configuration file and gtmtls_passwd_<TLS_ID> are not required.

getdefaultciphers

getciphers

The following entry points provide version information.

getversion

gettlslibversion

(GTM-F167995)

The $ZICUVER Intrinsic Special Variable provides the current International Character Utilities (ICU) version or an empty string if ICU is not available. GT.M requires ICU to support UTF-8 operation. Previously, GT.M did not make this information available to the application code. (GTM-F229760)

The Update Process properly closes prior generation journal files. Previously, due to a regression in V6.3-005, it was possible for the Update Process to miss closing a prior journal file when a MUPIP SET switched a journal file and the Update Process was waiting to receive updates from the Receiver Server. The workaround was to avoid explicitly switching journal files on the replicating instances. (GTM-DE538928)

MUPIP REORG traverses all index blocks and achieves a compact and optimally-structured database with a single pass. Previously, REORG failed to visit certain categories of blocks, including the root block and blocks it newly created or modified, and it required an indefinite number of passes to achieve optimal block structure. As a workaround for previous releases, users may consider repeating REORG operations until the command reports few blocks coalesced and split. In addition, REORG now recognizes a new qualifier, -MIN_LEVEL=n, which specifies the minimum level of block it may process. The default is -MIN_LEVEL=0. -MIN_LEVEL=1 instructs reorg only to process index blocks and can be understood as the REORG equivalent of an INTEG -FAST. (GTM-DE549071)

MUPIP REORG correctly handles block splits at the index level which are caused by a reorg-related block split at a lower-level index or data block. Previously, GT.M would sometimes fail to split these blocks, which prevented the original lower data- or index-level split from taking place. Together, these could prevent REORG from enforcing the provided fill factor and/or reserved bytes setting; a failure which persisted on all subsequent attempts, or until the database structure has changed as a result of new updates. As a workaround, users of previous releases can address a subset of the failures-to-split by passing a slightly different -fill_factor, provided that reserved bytes are disabled. (GTM-DE549072)

MUPIP REORG enfoces a minimum target block size of the block size minus the maximum reserved bytes. Previously, GT.M failed to reject a combination of reserved bytes and -fill_factor which effectively reserved a space larger than the database block size and caused database damage. Users of previous releases should use either reserved bytes or -fill_factor, but not both, as a means of achieving REORG sparseness. (GTM-DE549073)

The Receiver Server, configured to use TLS, continues waiting for new connections when a Source Server fails to establish a TLS session (e.g. misconfiguration). Previously, a Receiver Server configured for TLS but without -PLAINTEXTFALLBACK would exit with TLSCONVSOCK error message when it failed to establish a TLS session. (GTM-DE556365)

MUPIP UPGRADE correctly handles global trees with depths greater than supported by GT.M version 6.x, but possible when running version 7.x on a version 6.x database. Previously, attempts to upgrade V6 databases containing these tall global trees would result in a segmentation violation and the process would terminate early without upgrading the database. (GTM-DE556760)

GT.M issues JNLCLOSED and REPLSTATE syslog messages for a database file when journaling is closed and the replication status changes from ON to WAS_ON. In the WAS_ON state, replication continues until and unless replication requires records that are no longer available from the replication journal pool, as it can no longer use the journal files to find those records. While in this WAS_ON state if you can resume journaling, you may be able to avoid having to refresh the associated Secondary Instances. The need to use journal files in replication is a function of the size the replication journal pool, the rate of updates and operator actions that impact replication. Previously, GT.M issued a REPLJNLCLOSED message when journaling was disabled for a database file, but did not indicate that the replication status changed to WAS_ON. (GTM-F135405)

The -INDEX_RESERVED_BYTES and -DATA_RESERVED_BYTES qualifiers for MUPIPSET (and DSE CHANGE -FHEAD) allow independent adjustment of reserved bytes for each block type. Previously GT.M did not provide the flexibility to set these values independently. The -RESERVED_BYTES qualifier continues to adjust both types of block to the same value. When the command specifies -RESERVED_BYTES along one of the more specific qualifiers, MUPIP applies the more general -RESERVED_BYTES value to the block type unspecified by the other qualifier. MUPIP DUMPFHEAD reports the number of bytes reserved for each type of block (as does DSE DUMP -FHEAD). Reserving additional bytes in index blocks can reduce the number of records in any given index block and may reduce invalidation and search restarts in some workloads. (GTM-F197635)

GT.M recognizes the -[NO]{SEND|RECV}BUFFSIZE=n qualifiers for use with MUPIP REPLICATE -{SOURCE|RECEIVER} -START invocations. These qualifiers affect the TCP send and receive buffers associated with the socket GT.M uses for replication, rather than the receive/journal pools. When invoked with -{SEND|RECV}BUFFSIZE=n, where n is a positive decimal or hexadecimal (0x) integer, GT.M attempts to increase the specified socket buffer size to match the provided value. If the specified buffer is already larger than the provided value, GT.M does not attempt to reduce its size. By default, GT.M attempts to increase the size of the send buffer (SO_SNDBUF) or receive buffer (SO_RCVBUF) if either is smaller than the internal target value specified below.

                SO_SNDBUF    SO_RCVBUF
Source          1MiB         1KiB
Receiver        1KiB         1MiB

If a user requests a size for either buffer smaller than necessary to support GT.M replication, GT.M will print a BUFFSIZETOOSMALL warning, act as if the minimum size had been specified instead, and continue. Due to a quirk in how the Linux kernel reports socket buffer sizes, users of GT.M on Linux can expect GT.M to report a final size approximately twice what is requested; the additional space is used internally by the kernel. When invoked with -NO{SEND|RECV}BUFFSIZE, GT.M leaves the management of the initial size of the specified buffer to the execution environment, including the system defaults, local configuration settings, and operating system. In some cases, such as when the operating system dynamically manages the size of the relevant buffers, this can may lead to better performance in conditions which call for larger sizes than the GT.M default. Previously GT.M enforced a fixed minimum size for each buffer and did not permit the explicit request of receive and send buffer sizes. In addition, GT.M now correctly sets the buffer sizes, when warranted, before establishing a connection. Previously, GT.M waited until after the source and receiver had established a connection to perform any modification of the buffer sizes, which prevented the TCP connection from taking full advantage of any increase in size. (GTM-F236066) (GTM-F235980)

GT.M issues an EXCEEDRCTLRNDWN error message when competing processes repeatedly rundown the relinkctl and another process tries to connect to the relinkctl more than 16 times. Previously, under these circumstances GT.M failed with an GTMASSERT2 error. (GTM-F135409)

When using TLS configuration verify-mode option SSL_VERIFY_PEER, GT.M enables TLSv1.3 Post Handshake Authentication (PHA) for client connections. When using TLS configuration verify-mode options SSL_VERIFY_PEER and SSL_VERIFY_POST_HANDSHAKE, GT.M enables TLSv1.3 PHA for server connections. By itself, SSL_VERIFY_POST_HANDSHAKE does not enable PHA. Previously, GT.M did not support TLSv1.3's PHA capability. This could cause problems when connecting to some TLSv1.3 servers that require PHA. (GTM-F167609)