GT.M reports JNLPROCSTUCK and JNLFSYNCLSTCK errors with a -W- (warning) severity level. Previously, it gave these messages a -I- (informational) severity level. (GTM-5870)

GT.M now invokes all encryption functions, defined in gtmcrypt_interface.h and implemented by an encryption plugin, in an interrupt-safe manner. Previously, only the gtmcrypt_encrypt & gtmcrypt_decrypt functions were invoked in an interrupt-safe manner. In addition to MUPIP INTRPT, GT.M processes use timer interrupts to cooperatively manage databases. As a consequence of not calling the functions in an interrupt safe manner, a process could in theory conclude, for example, that it had an incorrect password for a database, resulting in a run-time error, or possibly process termination. Although theoretically possible, the probability of such a scenario is extremely low and we are not aware of any user ever having encountered it; indeed, we were unable to create such a scenario in the GT.M development and testing environment. The worst consequences of such a scenario are errors within a process, or premature process termination - there is no potential for database damage or data loss from data written to the database encrypted with the wrong password. [UNIX] (GTM-6634)

A GT.M process attempting to read a database block from disk to the global buffer pool retries indefinitely. Previously, failure to read a database block in 4 minutes caused GTMASSERT. (GTM-7192)

GT.M writes idle EPOCHs, which ZSHOW "G" or DSE DUMP -FILEHEADER count in the JRI statistic, only when there is no update for approximately five (5) seconds. Previously, with multiple processes under low update activity, several processes might write idle EPOCHs due to their own inactivity, even though other processes were actually updating at a light rate and the database was not actually static. [UNIX] (GTM-7443)

See GTM-7451. (GTM-7445)

See GTM-7451. (GTM-7450)

V6.0-001 brings changes to the database encryption plugin to provide more choices, to make it easier to use, and to fix bugs and misfeatures. If you are currently using encrypted databases, please note the following two important points regarding upward compatibility:

The choice of encryption plugin and cipher is effected in two ways:

When a GT.M process first opens a shared library providing an encryption plugin, it ensures that the library resides in $gtm_dist/plugin or a subdirectory thereof. This ensures that any library implementing an encryption plugin requires the same permissions to install, and is protected by the same access controls, as the GT.M installation itself.

On all platforms on which GT.M supports encryption, the distribution includes three reference implementations of the plugin, provided by the shared libraries libgtmcrypt_gcrypt_AES256CFB.so, libgtmcrypt_openssl_AES256CFB.so and libgtmcrypt_openssl_BLOWFISHCFB.so. On installation, platforms other than AIX, libgtmcrypt.so is a symbolic link to libgtmcrypt_gcrypt_AES256CFB.so; on AIX symbolic link is to libgtmcrypt_openssl_AESCFB.so. To use Blowfish CFB as the default, you should change the symbolic link after installing GT.M. To use AES CFB as the default, but retain Blowfish CFB for databases migrated from V6.0-000, you can set gtm_crypt_plugin when using those databases. For scripts intended to be portable between V6.0-000 and V6.0-001, you can safely set a value for gtm_crypt_plugin, which V6.0-000 ignores.

Enhancements to the helper scripts to accompany these changes are:

GT.M V6.0-001 includes fixes to bugs and misfeatures pertaining to encrypted databases:

The reference implementations of encryption plugins shipped with GT.M are now tested using AES CFB as implemented by OpenSSL (version >= 0.9.8) and libgcrypt (version >= 1.5).

Please remember that FIS neither endorses nor supports your use of any specific cryptographic library or cipher. Before using encrypted databases, please make sure you read and fully understand the Disclaimer in Chapter 12, Database Encryption, of the GT.M Administration and Operations Guide, UNIX Edition.

[UNIX] (GTM-7445) (GTM-7450) (GTM-7451)

GT.M now resumes appropriately from an Instance Freeze. In V6.0-000, there was a small window in which a process resuming from an Instance Freeze might inappropriately issue an error. [UNIX](GTM-7468)

GT.M now reports error messages which trigger an instance freeze before the freeze is set. Previously the freeze could encounter lock contention which would prevent the error from being reported until the freeze was lifted. [UNIX] (GTM-7471)

custom_errors_sample.txt now includes two new messages: DBIOERR and JNLCNTRL. [UNIX] (GTM-7474)

See GTM-7451. (GTM-7477)

GT.M no longer logs a JNLACCESS message with ENOSPCQIODEFER. Previously, with Instance Freeze configured, if the journal file system ran out of space doing a non-critical write the JNLACCESS message triggered an Instance Freeze which would not be automatically cleared when space became available.[UNIX](GTM-7481)

GT.M database errors check the Instance Freeze settings for the appropriate region. In V6.0-000, there were certain cases where an error could check the settings in the wrong region. [UNIX] (GTM-7493)

GT.M invokes the current set of triggers for a global when trigger definitions change concurrently. Previously, in case a GT.M process had invoked a set of trigger definitions for a global as part of an update outside of a TSTART/TCOMMIT fence and those definitions changed concurrently, the first update (after the trigger definition change) to that global by the GT.M process incorrectly used the old set of trigger definitions. Subsequent updates would correctly use the revised triggers; only the first update used the out-of-date triggers. [UNIX](GTM-7495)

When an Instance Freeze has stopped updates, GT.M and its utilities bypass database shutdown logic that typically occurs as part of process termination. In V6.0-000, exiting processes would hang if they encountered a frozen region. [UNIX] (GTM-7505)

GT.M appropriately handles I/O errors that occur as it attempts to flush global buffers to database files at process exit. Previously, such an I/O error could cause process termination with a GTMASSERT (GTM-7517)

An untimed LOCK waiting for a resource name owned by another process resumes waiting for the LOCK after a MUPIP INTRPT. In V5.5-000, the change to better manage the timeout when a process received a MUPIP INTRPT during a timed LOCK (GTM-5997) introduced a regression in untimed LOCKs that caused the process to continue past the LOCK command without ensuring it had acquired the specified resource(s). (GTM-7525)

GT.M on Linux now supports using huge pages (depending on the CPU architecture, typically 2MiB or 4MiB rather than the default 4KiB) for shared memory segments for BG access and for the heap of mumps processes. Using huge pages reduces the need for page tables at the cost of a slight increase in total system virtual memory usage. While your mileage may vary, FIS believes that many large applications will benefit from configuring and using huge pages. If you do not configure your system for huge pages, GT.M continues to use the default page size. Note that using huge pages requires no change whatsoever at the application code level, or even to database management operations such as replication, backup, integ, reorg, etc. - the changes discussed here pertain entirely to configuring system memory and the virtual memory manager to improve application performance.

To use huge pages:

At this time, huge pages cannot be used for MM databases; the text, data, or bss segments for each process; or for process stack.

Refer to the documentation of your Linux distribution for details. Other sources of information are:

Note

In order to assure predictable performance, FIS strongly recommends that you invest the effort to appropriately tune your system before using huge pages in production. For example, use of on demand huge pages (over-committing) may result in delays while the kernel performs memory management activities to satisfy requests for memory - but this may or may not be material in your situation. Since the memory allocated by Linux for shared memory segments mapped with huge pages is rounded up to the next multiple of huge pages, there is potentially unused memory in each such shared memory segment. You can therefore increase any or all of the number of global buffers, journal buffers, and lock space to make use of this otherwise unused space. You can make this determination by looking at the size of shared memory segments using ipcs. Contact FIS GT.M support for a sample program to help you automate the estimate. Transparent huge pages may further improve virtual memory page table efficiency. Some Supported releases automatically set transparent_hugepages to "always"; others may require it to be set at or shortly after boot-up. Consult your Linux distribution's documentation.

We categorized this as a Database item in these Release Notes because we expect it to have the largest impact on shared pages used by BG access method database files, but it also affects process foot-print [Linux on x86/x86_64] (GTM-7529)

GT.M now manages lookups of non-existent global variable roots (unsubscripted names) more carefully in very rare cases of heavy database contention. Starting in V5.4-000, such a rare event could cause incorrect results, and, in case of an update, create database damage reported by MUPIP as a DBINVGBL integrity error. (GTM-7534)

The reference implementation of the encryption plugin reports "Incorrect password or error while obtaining password" as the secondary text to CRYPTKEYFETCHFAILED message in cases where GPGME provided a less descriptive error code. Previously, the encryption plugin reported "Incorrect password" as the secondary text even when the password was correct in the environment but an error occurred during retrieval of the password. Refer to the revised CRYPTKEYFETCHFAILED message in Message and Recovery manual for more details. [UNIX] (GTM-7546)

Failures of non-critical writes intended to reduce the number of dirty global buffers caused by a (potentially transient) lack of space in the database file system do not report a DBIOERR in the system log, and do not initiate a freeze in environments configured for Instance Freeze. Previously, in such cases, GT.M reported a DBIOERR in the system log, and also initiated a freeze which required an explicit MUPIP REPLICATE -FREEZE=OFF action. Note that all critical database writes (those required to ensure durability) generated and continue to generate ENOSPC messages, and initiate freezes. Instances frozen with an ENOSPC error monitor available space, and automatically release the freeze when space becomes available. [UNIX] (GTM-7555)

If a replicating secondary instance or a supplementary instance is configured for Instance Freeze, the Update Helper processes - Readers and Writers - honor Instance Freeze. Previously, the Update Helpers did not open the Journal Pool and as a result could neither initiate nor honor Instance Freeze. [UNIX] (GTM-7557)

Database updates correctly handle heavy IO loads on OpenVMS. Previously, owing to a potential race condition in a very small window, in rare cases involving concurrent database updates, the database could potentially sustain structural damage, with the probability of damage increasing with update concurrency. FIS is not aware of this having been encountered at any customer site. [OpenVMS] (GTM-7564)

GT.M appropriately handles $REFERENCE in certain unusual error conditions such as out-of-memory (MEMORY error mnemonic). In previous versions, if these unusual errors occurred while performing a database access, and the next global reference (either inside the error trap or in some routine to which the trap transferred control) relied on $REFERENCE or a naked reference, that subsequent reference could have been incorrect. (GTM-7571)

When a processes that is part of an instance configured for instance freeze behavior encounters an error with journaling, it freezes the instance and invokes its own error trap even if it does not have the gtm_custom_errors environment variable set. Previously, under certain circumstances, such as being unable to create a new journal file because of directory permissions, a process in an Instance Freeze environment might turn journaling off. Since the operation of GT.M processes is controlled with environment variables, and GT.M relies on directory and file access permissions of the underlying operating system, it was, and remains, possible to set up abnormally configured systems where processes without appropriate values of environment variables can cause undesirable results such as turning off journaling in instances configured for instance freeze. [UNIX] (GTM-7575)

ZMESSAGE transforms two sets of error messages into SPCLZMSG errors. The internal error messages which should not be user visible and the error messages which are expected to be driven when their corresponding internal state is available. The list of such errors is as follows: (CTRLY, CTRLC, CTRAP, JOBINTRRQST, JOBINTRRETHROW, REPEATERROR, STACKCRIT, SPCLZMSG, TPRETRY, UNSOLCNTERR). Previously, passing to ZMESSAGE the IDs of some of the these errors could cause the process to terminate with a GTMASSERT. [UNIX](GTM-3357)

When the UNIX environment variable gtm_side_effects (OpenVMS logical name GTM_SIDE_EFFECTS) is set to one (1) at process startup, GT.M generates code that performs left to right evaluation of actuallist arguments, function arguments, operands for non-Boolean binary operators, SET arguments where the target destination is an indirect subscripted glvn, and variable subscripts. When the environment variable is not set, or set to zero (0), GT.M retains its traditional behavior, which re-orders the evaluation of operands using rules intended to improve computational efficiency. This reordering assumes that functions have no side effects, and may generate unexpected behavior (x+$increment(x) is a pathological example). When gtm_side_effects is set to two (2), GT.M generates code with the left-to-right behavior, and also generates SIDEEFFECTEVAL warning messages for each construct that potentially generates different results depending on the order of evaluation. As extrinsic functions and external calls are opaque to the compiler at the point of their invocation, it cannot statically determine whether there is a real interaction. Therefore SIDEEFFECTEVAL warnings may be much more frequent than actual side effect interactions and the warning mode may be most useful as a diagnostic tool to investigate problematic or unexpected behavior in targeted code rather than for an audit of an entire application. Note that a string of concatenations in the same expression may generate more warnings than the code warrants. Other values of the environment variable are reserved for potential future use by FIS. It is important to note that gtm_side_effects affects the generated code, and must be in effect when code is compiled - the value when that compiled code is executed is irrelevant. Note also that XECUTE and auto-ZLINK, explicit ZLINK and ZCOMPILE all perform run-time compilation subject to the characteristic selected when the process started. Please be aware that programming style where one term of an expression changes a prior term in the same expression is an unsafe programming practice. The existing UNIX environment variable gtm_boolean (OpenVMS logical name GTM_BOOLEAN) may separately control short-circuit evaluation of Boolean expressions but a setting of 1 (or 2) for gtm_side_effects causes the same boolean evaluations as setting gtm_boolean to 1 (or 2). The differences in the compilation modes may include not only differences in results, but differences in flow of control.(GTM-6395)(GTM-3907)

Failure to close any database file at exit causes the process to return a non-success status code to the shell. Previously, such errors had no effect on the status returned to the shell. [UNIX] (GTM-3989)

When a GT.M process within certain small but sensitive areas of the database code receives a terminal-related signal that would suspend the process because the terminal is unavailable for pending input or output, it now correctly sends itself a continue signal and defers the suspension until it reaches an area of the code where it is safe to suspend. The terminal related signals are TTIN, TTOU, and TSTP, and the continue signal is CONT. Previously, when a process in such a sensitive area received such a signal, it sent itself a continue signal but a problem in signal handling could result in an indefinite loop. If the process happened to hold critical resources this indefinite loop could cause resource starvation, blocking other processes needing resources. For example, a process unable to read a block within approximately four (4) minutes could terminate with a GTMASSERT. Since TTIN and TTOU result from terminal IO by processes running in the background, and TTSTP commonly results from typing Ctrl-Z to an interactive process, the workaround was to avoid these situations. Also, because a process cannot ignore a STOP signal, which causes it to suspend processing immediately, any processes waiting for a critical resource held by a suspended process send the CONT signal to the suspended process. Previously, a STOP signal suspending a GT.M process holding a critical resource could indefinitely block other processes. Note that FIS continues to recommend against suspending GT.M processes. [UNIX](GTM-4661)

The VIEW command keyword, [NO]LOGT[PRESTART][=intexpr] allows a process to dynamically change the logging of TPRESTART messages to the operator log established at process startup by the environment variables gtm_tprestart_log_delta and gtm_tprestart_log.

VIEW "NOLOGTPRESTART" turns off the logging of TPRESTART messages to the operator log.

VIEW "LOGTPRESTART"[=intexpr] turns on logging of TPRESTART messages to the operator log. If no intexpr is specified, GT.M uses the value of environment variable gtm_tprestart_log_delta, if it is defined, and one otherwise (i.e., every transaction restart will be logged). A negative value of intexpr turns off the logging of TPRESTART messages.

The TPRESTART message has a "local tn value" which may be helpful to FIS GT.M support in the event you contact us for support. It now has a 0x prefixed to it to indicate that it is a hexadecimal number. Previously, it was printed as a series of hexadecimal digits without the leading 0x. (GTM-5378)

Loops involving indirection of the form @x@() where x is a global or local variable name execute faster when the subscripts vary with each iteration. Although this enhancement takes a different approach, FIS thanks Mikhail Ilyin and Komitex JSC for initially suggesting a refinement in this area. In addition, GT.M correctly evaluates nested indirection. Previously, if a subscripted indirect expression contained both nested indirection and multiple '@' characters, the result could have been incorrect. Also, the ZWRITE command accepts an argument of the form @x@(*), which previously gave a syntax error. (GTM-5896)

The JOB command jobparameter CMD[LINE]=" <text>" passes the content of <text> to the $ZCMDLINE of the JOB'd process (The cmdline can be shown through the UNIX ps command). This is new functionality.[UNIX](GTM-6015)

See GTM-3907.(GTM-6395)

GT.M includes the %TRIM, %MPIECE, and %DSEWRAP utility programs and a new utility label for %XCMD called LOOP. The description of these utilities is as follows:

(GTM-7160)

The LOCK command now implements fairer access when multiple processes need the same lock resource. Previously, when multiple processes sought to get the same lock resource, there was no attempt to ensure fairness. Note that although the technique attempts to be fair, it does not guarantee that no processes will "jump the queue" especially when there is heavy contention for the same lock resource. Applications we expect to be typical should experience no change in overall behavior. (GTM-7254)

The GT.M compiler, invoked with the MUMPS shell command and the GT.M ZCOMPILE command, returns a status of 1 after any error in compilation. Previously the compiler returned 255, which caused some shell services such as xargs to exit prematurely. Scripts or programs explicitly checking for 255 (rather than non-zero) must be revised. The workaround was to wrap the MUMPS command with a script that modified the return before returning to any utility that was sensitive to a return status of 255. Note that unless invoked with the NOIGNORE qualifier, unless there are more than 150 compilation errors in a source file, the GT.M compiler still creates an object file with the compilation errors embedded in the code paths where they appeared.[UNIX](GTM-7281)

GT.M properly handles TPFAIL errors inside a trigger by raising an appropriate error. Previously, under certain rare conditions, a TPFAIL in a trigger could lead to a GTMASSERT. Dealing with the implication of this issue led to changes in GT.M behavior under the following circumstances:

Although we do not expect these changes to have any impact on a production environment with appropriate error handling, you may be required to modify your debugging techniques for problems in indirection and XECUTE code. [UNIX](GTM-7355)

OPEN of a DECnet task as a GT.M I/O device releases all extra channels associated with the device. Previously, an extra channel remained open for each GT.M OPEN of a DECnet task until the process terminated. [OpenVMS] (GTM-7387)

OPEN on a directory now yields a GTMEISDIR error in both READONLY and NOREADONLY modes along with the directory name which failed to open. UNIX directories contain metadata that is only available to the file system. Previously OPEN READONLY of a directory appeared to work but any subsequent READ yielded a EISDIR error and OPEN NOREADONLY on directories yielded EISDIR. Note that you can use the ZSEARCH() function to identify files in a directory, and you can call the POSIX stat() function to access metadata. The optional GT.M POSIX plug-in packages the stat() function for easy access from M application code. This change was made to make directory related errors more consistent. [UNIX] (GTM-7395)

$ZMESSAGE() appropriately handles unused error codes by returning %SYSTEM-E-UNKNOWN. Previously, $ZMESSAGE() could produce a segmentation violation (SIG-11) for some unused error codes. Also more than one unused error codes could be incorrectly mapped into a single known error message.[UNIX] (GTM-7415)

The $ZWRITE() function takes a single expression argument and returns that expression with the non-graphic characters represented in the $CHAR() format used by the ZWRITE command. Note that the non-graphic characters differ between M mode and UTF-8 mode. This is a new function.(GTM-7475)

The FOR command correctly handles indirect control variables, as well as control variables whose subscripts contain an extrinsic function. Previously, due to a regression introduced in V54002B while addressing C9L03-003392, certain such cases would result in a segmentation violation (UNIX SIG-11 or VMS ACCVIO). In addition, FOR now safely issues an UNDEF error if the control variable is KILLed during a loop iteration. Previously, with NOUNDEF and an unsubscripted control variable, this scenario resulted in an access violation on most platforms; on AIX, execution continued with indeterminate behavior. (GTM-7492)

GT.M provides a C header file gtm_common_defs.h, in the distribution directory, which contains general purpose helper macros for use by external calls and plugins. (GTM-7494)

GT.M no longer restricts indirection nesting to 32 levels and more robustly handles error conditions, TP restarts, and ZGOTO commands while executing indirect code. Previously, it restricted indirection nesting to 32 levels and the aforementioned occurrences during indirection could cause an access violation (UNIX SIG-11 or VMS ACCVIO) or result in unexpected INDMAXNEST messages. (GTM-7497)

GT.M appropriately signs the results of exponential expressions. Previously, while assignments to a variable worked correctly, temporary representations were incorrectly negative.(GTM-7501)

ZSHOW "G" accurately counts the LKS statistic (the number of successfully obtained LOCKs). Previously, LOCK logic incorrectly incremented LKS twice if the LOCK was not immediately available, that is: was held initially by another process. (GTM-7510)

The gtmxc_types.h highlights the preferred types (gtm_xxx_t) and explicitly marks the old types (xc_xxx_t) as deprecated. It also includes definitions for the following entry points exported from libgtmshr:

Where:

gtm_hiber_start() always sleeps until the time expires; gtm_hiber_start_wait_any() sleeps until the time expires or an interrupt by any signal (including another timer). gtm_start_timer() starts a timer but returns immediately (no sleeping) and drives the given handler when time expires unless the timer is canceled [UNIX](GTM-7515)

$STACK(lvl) where lvl is greater than zero and less than or equal to $STACK(-1), reports "TRIGGER" for a stack level invoked by a trigger (UNIX only). Previously, $STACK() reported "DO" for this invocation. In addition, $STACK(lvl) reports "ZINTR" for a stack level invoked by MUPIP INTRPT. Previous, GT.M reported "XECUTE" for this invocation.(GTM-7516)

$GET(), $NAME() and $ORDER() with an indirect first argument and a side effect expression for a subsequent argument, evaluate left-to right. Previously while the evaluation of the indirect glvn occurred before the subsequent argument, the evaluation of its result (the actual first argument) evaluated after the subsequent argument.(GTM-7535)

When the target of a SET $EXTRACT()/$PIECE()/$ZEXTRACT()/$ZPIECE() command is an indirect subscripted glvn, SET evaluates side effect expressions only once. Previously, SET evaluated the subscripts twice, which inappropriately doubled any side effects.(GTM-7536)

$ORDER() in the reverse direction and $ZPREVIOUS() return the correct result. Previously, if any global directory name-spaces shared a common prefix and if either of these commands was specified with an unsubscripted global name, an extension referred to as "name-level $ORDER()", the result could have been a global in an incorrect region. (GTM-7541)

$ORDER() and $ZPREVIOUS() in which the first argument is an extended global reference work safely. Previously, if a GT.M process used either function in this manner, without having already done a non-extended global reference, an access violation (UNIX SIG-11 or VMS ACCVIO) could have occurred. (GTM-7544)

A TP RESTART, either implicit or explicit, while executing $ZINTERRUPT in response to an interrupt (i.e., $ZININTERRUPT is 1), and while error processing is in effect (i.e, $ECODE'=""), raises a TPRESTNESTERR error and engages nested error handling, which unstacks M virtual machine frames back to where the incompletely handled error occurred, unstacks that frame and rethrows the error. Since GT.M version V5.4-000, GT.M has saved and restored error context ($ECODE, $STACK, etc.) over the execution of a $ZInterrupt invocation, but the RESTART exposes the underlying error. Previously, this situation caused a GTMASSERT.[UNIX](GTM-7550)

GT.M handles M-locks inside TP transactions correctly. Previously, if an M-lock was used in a TP transaction and the lock name mapped to a database file where no other database references had occurred in that TP transaction, a TP RESTART could in rare cases cause the TP transaction to resume processing from the M line where the retry occurred instead of from where the TSTART happened. This in turn could result in application level database inconsistency, TPFAIL errors in GT.M and in rare cases database damage. A workaround for this was to ensure every lock usage inside a TP transaction is preceded by a global reference (e.g. $GET(), $DATA()) that maps to the exact same region. Note that FIS recommends against the use of LOCKs in TP transactions. (GTM-7552)

GT.M recognizes >= as the syntactic equivalent of '< and <= as the syntactic equivalent of '>. Previously GT.M did not accept these non-standard binary operators. (GTM-7556)

MUPIP EXTRACT can redirect the database extract to the standard output stream if -STDOUT is specified. Also, MUPIP EXTRACT now issues an EXTRFILEXISTS error if the output file already exists and an EXTRACTFILERR if there is a problem (such as authorization) opening the output. Previously these errors did not have documented mnemonics. [UNIX] (GTM-4115)

The GT.M replication connection between a Source Server and a Receiver Server and the GT.CM connection between a Client and a Server protect against communication issues when one side of the connection drops in a way that prevents the communication stack on the other side from receiving the dropped notification. When either side ceases to receive a heartbeat, it terminates the connection and then attempts to restore communications; the Receiver Server reverts to listening at its TCP port, and the Source Server makes an attempt to connect to the Receiver Server. Previously, in some cases, an abnormal shutdown of a GT.M replication or a GT.CM connection required operational recycling either or both sides of the connection. [UNIX] (GTM-7168)

MUPIP JOURNAL -RECOVER -FORWARD works correctly for database files with the MM access method. Previously, it terminated with a segmentation violation (UNIX SIG-11 or OpenVMS ACCVIO) if the recovery caused a database file extension which was particularly common if -REDIRECT was also used. [UNIX] (GTM-7241)

The new MUPIP SIZE command estimates and reports the size of global variables using a format that is similar to the one that appears at the end of the MUPIP INTEG -FULL report. In comparison with MUPIP INTEG -FAST -FULL, MUPIP SIZE provides the option of choosing any one of the three estimation techniques to estimate the size of global variables in a database file. These techniques vary in measurement speed and estimate accuracy. The format of the MUPIP SIZE command is:

MUPIP SI[ZE] [-h[euristic]=estimation_technique] [-s[elect]= global-name-list] [-r[egion]=region-list]

The optional qualifiers of MUPIP SIZE are:

-Heuristic=estimation_technique

Specifies the estimation technique that MUPIP SIZE should use to estimate the size of global variables. The format of the -HEURISTIC qualifier is:

-h[euristic]=sc[an][,level=<lvl>] | a[rsample][,samples=<smpls>] | i[mpsample][,samples=<smpls>]

estimation-technique is one of the following:

	Important
	For large databases, MUPIP SIZE is faster than MUPIP INTEG -FAST -FULL. IMPSAMPLE is expected to be the fastest estimation technique, followed by ARSAMPLE and then SCAN. In terms of accuracy, MUPIP INTEG -FAST -FULL is the most accurate.

-Select

Specifies the global variables on which MUPIP SIZE runs. If -SELECT is not specified, MUPIP SIZE selects all global variables.

The format of the SELECT qualifier is:

-s[elect]=global-name-list

global-name-list can be:

-Region

Specifies the region on which MUPIP SIZE runs. If REGION is not specified, MUPIP SIZE selects all regions. The format of the REGION qualifier is:

-R[EGION]=region-list

Examples:

$ mupip size -heuristic="impsample,samples=2000" -select="y*" -region="AREG"

This example estimates the size of all global variable starting with "y". It uses importance sampling with 2000 samples on the region AREG.

$ mupip size -heuristic="scan,level=-1"

This example counts the number of blocks and records at 1 level below the root of the database tree.

$ mupip size -heuristic="arsample" -select="g1:g3"

This example estimates the size of global variables g1, g2 and g3 using accept/reject sampling with the default number of samples regardless of the region in which they reside.

	Note
	Apart from randomness caused by sampling heuristics, MUPIP SIZE also has randomness from concurrent updates because it does not use the snapshot technique that MUPIP INTEG uses.

[UNIX] (GTM-7292)

The Receiver Server and Update Process now record the IPC identifiers associated with the Journal Pool and Receive Pool in the respective log files. Previously, no such information was logged by the Receiver Server and Update Process. [UNIX] (GTM-7356)

MUPIP INTEG now exits with a MUNOTALLINTEG warning message if it did not find any integrity errors in the regions it checked, but could not check on one or more of the requested regions. For example, MUPIP cannot INTEG regions that are frozen, have an endian mismatch between the database and the machine (DBENDIAN message), have database format too old to support snapshot (SSV4NOALLOW message), etc. Previously, MUPIP INTEG exited with INTEGERRS in such situation, which was misleading as there were no errors found in the processed regions. (GTM-7427)

MUPIP BACKUP displays GTM-E-BKUPRUNNING message if started when there is an already running BACKUP. Previously, it terminated with a less helpful and undocumented message. (GTM-7432)

MUPIP REORG and the snapshot mechanism work to minimize the impact of a MUPIP INTEG -FAST on other processes. Previously GTM-7194 in V6.0-000 eliminated the writing of some, but not all, blocks that are not necessary for an INTEG -FAST. [UNIX] (GTM-7454)

Online REORG works safely again on OpenVMS. Previously, due to a regression introduced in V6.0-000 while addressing GTM-6341, a concurrency issue could cause memory corruption and result in an OPCDEC error. [OpenVMS] (GTM-7455)

The Receiver Server, on receiving MUPIP STOP after abnormal termination of the Update Server, resets IPC fields in the replication instance file header. Previously, in such cases, the Receiver Server removed IPC resources but did not reset them in the instance file header causing future startup commands to fail with REPLREQROLLBACK errors. The workaround was to do a MUPIP RUNDOWN -REG "*" before restarting the replication servers. [UNIX] (GTM-7458)

MUPIP JOURNAL -ROLLBACK and MUPIP RUNDOWN support Instance Freeze configuration by opening the Replication Journal Pool if it already exists. Previously an error during a JOURNAL ROLLBACK or RUNDOWN did not set or respect Instance Freeze.[UNIX](GTM-7461)

When run concurrently with MUPIP REORG ONLINE TRUNCATE, MUPIP BACKUP ONLINE generates correct backup files. Previously MUPIP BACKUP ONLINE could produce incomplete backup files. [UNIX](GTM-7476)

When MUPIP JOURNAL EXTRACT, with neither the RECOVER nor ROLLBACK qualifier, needs to access the database file to determine collation information to use for the extracted data, a positive integer value of the environment variable gtm_extract_nocol instructs the MUPIP process to use the default collation if it is not able to read the database file. For example, the database file may be inaccessible, or the replication instance may be frozen with a critical section required for the access held by another process. In such a situation, the MUPIP process issues the DBCOLLREQ warning and proceeds with the extract using the default collation. Note that if default collation is used for a database with custom collation, the subscripts reported by MUPIP JOURNAL EXTRACT are those stored in the database, which may differ from those read and written by application programs. Furthermore, the BG access method now always reserves 32 global buffers for read-only use, which ensures that non-dirty global buffers are always available. If gtm_extract_nocol is not set, or set to a value other than a positive integer, MUPIP JOURNAL EXTRACT exits with SETEXTRENV error if it encounters such a situation. Previously, MUPIP JOURNAL EXTRACT would hang if it encountered a frozen instance, or silently use default collation if it was unable to access the database file. [UNIX] (GTM-7478)

The Source and Receiver Server shutdown processing in response to MUPIP REPLICATE commands appropriately manage shared memory and semaphores related to instance file and Journal/Receive Pool. Also, the REPLREQROLLBACK error message now provides additional detail. Previously, the server shutdown processing left the IPC resources temporarily unattached, which could allow a concurrent argument-less MUPIP RUNDOWN to treat them as abandoned and remove them, which, in turn, caused the in-progress shutdown command to exit with ENO22, and subsequent startup commands to exit with REPLREQROLLBACK. The workaround was to do a MUPIP RUNDOWN -REGION "*". [UNIX] (GTM-7485)

Argumentless MUPIP RUNDOWN command issues MUJPOOLRNDWNFL and MURPOOLRNDWNFL messages with correct shared memory ID. Previously, it issued these messages with incorrect shared memory IDs and attempted to remove such memory segments if no process was attached to those segments which, in rare cases, could cause future replication startup commands to exit with REPLREQROLLBACK errors. [UNIX] (GTM-7486)

The update process now handles Instance Freeze conditions while shutting down. In GT.M V6.0-000, the update process closed the journal pool early in its shutdown logic, which prevented it from handling custom errors and frozen instances appropriately, and could occasionally produce GTMASSERT failures. [UNIX] (GTM-7502)

The update process operates correctly even in cases where it encounters an Instance Freeze. Previously, when an update process encountered an Instance Freeze, it would terminate abnormally with a GTMASSERT error after the freeze cleared. [UNIX] (GTM-7526)

The source server, recover, and rollback processes issue a JNLFILRDOPN message when unable to open a journal file for read. Previously they issued a JNLFILOPN message. The new message allows for distinction between read-write and read-only use of the journal file, particularly in a gtm_custom_errors file. (GTM-7530)

MUPIP no longer terminates with a segmentation fault (SIG-11) when performing a checkhealth while the replication instance is frozen, DSKNOSPCAVAIL is in the custom errors file, and no other processes are attached to the journal pool. [UNIX] (GTM-7538)

The Source Server exits with one or more JNLFILOPN messages followed by a SEQNUMSEARCHTIMEOUT error after six failed attempts to access journal files in order to read a record needed to satisfy the corresponding Receiver Server. The JNLFILOPN messages contain information on the journal files and regions - the state of each journal file, the last sequence number read by the Source Server, etc. The first five failures generate REPL_WARN messages. Previously, the source server generated REPL_WARN messages every 10 seconds indefinitely and provided no information on which files were associated with the failure. [UNIX](GTM-7566)

The README, README.txt, and COPYING files in all GT.M distribution kits are now read-only. Previously, they had the write and/or execute permissions set. (GTM-7374)

LKE SHOW -MEM now displays LOCKSPACEINFO message. Previously this message was only displayed after LOCKSPACEFULL errors. (GTM-7553)

DBCERTIFY CERTIFY correctly handles a very rare case where the output file from dbcertify scan contains a global variable tree root block whose rightmost child tree path contains a block with just a *key record. Previously, this scenario failed with a DBCINTEGERR error. (GTM-7559)