GT.M Version 5.0-000D Release Notes

When a backup was (re)started, several fields related to backup error processing were not properly cleared. If an earlier backup failed, it prevented any fresh backups from starting and displayed an error message. This led to "file not found" errors or denial of permissions. The error, introduced in GT.M V5.0-000, has now been fixed. (S9G02-002597)

GT.M V5.0-000D has improved error handling capability with respect to writes to the journal file. Even when a journal write error occurred, previous versions of GT.M would treat it as a completed journal write and this would result in gaps in journal files, making the files unusable by MUPIP JOURNAL RECOVER/ROLLBACK. GT.M now keeps retrying each write until it succeeds. In addition, GT.M now prints additional debugging information in the syslog whenever it encounters a journal-file-write-error. (C9D11-002447) (S9F01-002525)

As a troubleshooting tool, M programs have been able to programmatically turn on (and off) a check for the structural integrity of database blocks written with the VIEW "GDSCERT" command. This functionality is now enhanced with the addition of a new environment variable [UNIX] or logical name [OpenVMS] gtm_gdscert. If it is defined, and evaluates to a non-zero integer, the string "TRUE", or the string "YES" (or any case independent leading substrings thereof), then block certification is turned on at process startup. Any other value keeps block certification off (default behavior) at process start up. The use of this feature now enables block certification also for the GT.M utilities DSE and MUPIP. It does not apply to LKE, which never modifies database blocks. (C9B11-001796)

Prior versions of GT.M would send a GTM-E-JNLACCESS message to the syslog every time a process encountered an out-of-space error while writing to the journal file. GT.M V5.0-000D fixes this syslog flooding by logging only one message for every 100 out-of-space errors while writing to the journal file. (C9B11-001810)

M names can be up to 31 characters long. GT.M allows up to 31 characters for M local and global variable names; M routine names; M source file names; M Label names; M lock names; and database region and segment names. Leading carets (^) continue to not count towards identifier length. Any characters after the first 31 are ignored. See the technical bulletin GT.M Long Names for details on this enhancement. (C9D03-002250)

There is now an option for a database file to allow existing global variable nodes with null subscripts but to prohibit setting/updating global variables with null subscripts. See the technical bulletin GT.M Null Subscripts for details. (C9D03-002251)

GT.M issues an informational TPNOTACID message if it is executing a TP transaction in the final retry and of the following three conditions is encountered:

Previous versions of GT.M inaccurately identified the condition in the TPNOTACID message text and always reported that a ZSYSTEM command was encountered. This has been fixed and GT.M now identifies the correct condition in the message text. (C9D07-002369)

GT.M V5.0-000D has improved error handling capability with respect to writes to the journal file. Even when a journal write error occurred, previous versions of GT.M would treat it as a completed journal write and this would result in gaps in journal files, making the files unusable by MUPIP JOURNAL RECOVER/ROLLBACK. GT.M now keeps retrying each write until it succeeds. In addition, GT.M now prints additional debugging information in the syslog whenever it encounters a journal-file-write-error. (C9D11-002447) (S9F01-002525)

A new keyword has been added to the VIEW command: VIEW "FLUSH"[:region], which is analogous to the "JNLFLUSH" keyword. Just as "JNLFLUSH" flushes dirty journal buffers, "FLUSH" flushes dirty global buffers from the global buffer cache. If journaling is active, "FLUSH" flushes dirty journal buffers prior to flushing dirty global buffers. If no region is specified, all regions in the current global directory that the GT.M process has opened are flushed. (C9E02-002525)

GT.M on the PA-RISC HP-UX platform now uses pread/pwrite calls for database IO rather than the more expensive lseek/read/write calls [HP-UX] (C9E03-002531)

A rare case of malformed messages being exchanged by GT.CM client and server leading to unexpected disconnects, or abnormal termination has been fixed. The issue could occur only when the size of data or global subscripts were large (approximately 16K or more), and the host running the GT.CM client or server was little endian. [UNIX] (C9E04-002561)

An issue in the GT.M database logic with the BG (Buffered Global) access method which in very rare circumstances could cause structural damage and/or false GVUNDEF errors has been fixed. Although this issue could show up with any number of global buffers, the likelihood of this decreases significantly with the number of global buffers typically used (for example: 1024 and higher). (C9E07-002610)

An issue in GT.M journaling that in rare cases previously generated benign GTM-E-JNLCNTRL is now fixed. This error occurred around the time a journal file switch happened (explicitly by MUPIP SET JOURNAL or implicitly by an autoswitch). [UNIX] (C9E08-002618) (S9F11-002574)

M-sets done within a TP transaction, where the destination is a global variable, in very rare circumstances could corrupt process private memory which in turn could potentially affect the integrity of the database. This is now fixed. Non-TP sets of global variables are unaffected by this issue. This was reported as having been fixed by C9E03-002537 in GT.M V4.4-004 but the fix was later found to have been incomplete. It is now completely fixed. (C9E09-002635)

In very rare cases, a TP transaction that creates a lot of global variables could end up causing integrity errors in the directory tree. This is now fixed. (C9E11-002655)

With alternative collation type > 0, $next() now returns the correct string if the input subscript is numeric type and the output subscript is string. (C9E12-002674)

MUPIP REORG on a database that has concurrent GT.M activity (read/update) in rare cases could terminate abnormally. In extremely rare cases, this could structurally damage the database too. This issue is now fixed. (C9E12-002676)

GT.M allows TP transactions to be nested i.e. TSTART can be specified within a transaction to start a sub-transaction. The nested TP transaction can be rolled back or committed using TROLLBACK or TCOMMIT. KILL of globals in such nested TP transactions previously could in very rare instances cause database damage. This is now fixed. (C9E12-002698)

A bug that has never been reported at a production site, but which can in theory occur because it was detected during internal stress testing by Fidelity, has been fixed. Under certain very unlikely conditions, a database block in principle could be written to the wrong database, and the only recovery would be to restore a backup and perform a mupip forward recovery. Users of GT.M versions V43001F, V44003, V44003A and V44004 are therefore advised to upgrade to V5.0-000 as soon as practicable. [OpsenVMS] (C9F05-002726)

Every journal record in the journal file has a checksum field. With before-image journaling, it was possible in very rare cases that GT.M would write a before-image journal record with an incorrect checksum value. This would cause MUPIP RECOVER/ROLLBACK to issue a "Checksum validation failed" error. GT.M is now fixed to write the correct checksum. (C9F10-002762)

The JNLFSYNCLSTCK message now prints the associated journal file name. [UNIX] (C9G04-002780)

GT.M traditionally collated a null subscript between numeric subscripts and string subscripts. The M standard specifies that null subscripts be collated before numeric subscripts. When a database file is created, it can now be created to use either traditional GT.M collation or M standard collation for null subscripts. See the technical bulletin GT.M Null Subscripts for details. (S9B03-001813)

GT.M now handles ZTP transactions (ZTSTART and ZTCOMMIT) correctly when journaling is turned on. Previously, it was possible for GT.M to issue GVGETFAIL or other database errors for a global reference following ZTCOMMIT when such a global belonged to a region other than the region last accessed within the ZTP transaction. (S9E08-002484)

GT.M is designed to repair and recover from certain classes of damage to the shared memory control structures used to manage database global buffers. This recovery has been speeded up - there were previously cases when it could take many tens of minutes - and should now take no longer than four minutes. (S9E12-002516)

The TPRESTART message in the syslog now additionally displays the name of the region where the transaction restarted. (S9F02-002529)

In before image journaled databases, an EPOCH is periodically written to record a checkpoint for future recovery. As a part of this, all updates to the database are hardened to disk. If GT.M encounters an error during this hardening, it issues a GTM-E-DBFSYNCERR error. Previous versions of GT.M did not release the lock on the journal file before issuing this error. This could result in a deadlock and cause application hangs. GT.M now releases the lock before issuing the DBFSYNCERR error. (S9F07-002560)

In prior versions of GT.M on UNIX, when a process switched the journal file of a database region to a new file, the other processes kept the previous generation journal file open until they updated that region. Even though there was no impact on robustness or recoverability, this meant that older generation journal files were potentially kept open for an indefinite amount of time in spite of having switched the journal file one or more times. To mitigate this situation, GT.M now checks for open older generation journal files approximately every 8 seconds and closes them right away instead of awaiting the next update. GT.M on OpenVMS is immune to this issue as it closes the older generation journal file at the time of the journal switch instead of waiting for the next update. [UNIX] (S9F07-002561)

On HP-UX, a large number of system calls were made to ascertain the status of existing processes when a database was being closed. On some systems, the number of these system calls created a bottleneck resulting in hung processes, sometimes for many hours. GTM is now fixed to avoid this system call bottleneck. [HP-UX] (S9G01-002593)

With GT.M replication, GT.M processes are supposed to update replicated databases coresponding to the replication instance they were started with only. Although updating a replicated database that is not part of the current replication instance (e.g. using an extended reference) is a not permitted, this condition was not detected and reported in previous GT.M versions, potentially resulting in missing journal sequence numbers in the current replication instance. This would then cause the source server to issue a REPLBRKNTRANS error and the only way to recover from this situation would be to restore the secondary from a backup of the primary. GT.M now detects such out-of-instance updates and issues a REPLINSTMISMTCH error thereby disallowing such updates. (S9G03-002599)

GT.M issues a SYSTEM-W-NOTVOLSET error while opening a journal file that is assigned a OpenVMS file id with a file-sequence-number (the second of the three numbers reported by a DIR/FULL command) that is greater than or equal to 32K, due to an issue with the OpenVMS C compiler that generated incorrect machine code when used with optimization flags. This issue was fixed in later releases of the compiler. The current version of GT.M is built with an upto date compiler that fixes this issue. [OpenVMS] (S9G03-002601)

VIEW "JNLFLUSH" not only writes the journal buffers to disk but also hardens the writes to the journal file on disk, thereby ensuring that all updates until that point are recoverable in case of a system crash. This is only applicable to GT.M on UNIX as writes on OpenVMS are automatically hardened. Note that with the use of transaction processing, except for transactions flagged as “batch” transactions, a TCommit command (or the outermost TCommit command, in the event of nested transactions) always flushes journal buffers and hardens them on disk. [Unix] (S9G03-002610)

GT.M source code was modified to use ANSI C stdargs.h style of variable argument list parameter passing instead of the earlier K&R C varargs.h style. This change has enabled the use of optimizer flags with GCC C compiler thus improving CPU performance of GT.M applications on the x86 GNU/Linux platform. The change is internal to GT.M and has no functional or operational impact. [x86 GNU/Linux] (C9907-001201)

A new intrinsic function, $INCREMENT(glvn[,expr]), is provided to atomically increment a global variable by a numeric value. Please note that the increment is atomic, but the evaluation of the expression is not, unless inside a transaction (TStart/TCommit). (C9D03-002249)

In certain situations, when journaling is ON during the database file extension, GT.M would cause a process to hang within a self inflicted-deadlock waiting for an OpenVMS system trap (AST) after the process previously disabled AST. This bug is now fixed. [OpenVMS] (C9E04-002557)

A bug in the intrinsic function $REVERSE() which in very rare cases could cause memory corruption or abnormal termination has been fixed. This was an issue only if the argument to $REVERSE() evaluated to a numeric (non-string) expression. (C9E04-002559)

GT.M previously displayed certain control characters incorrectly in ZWRite output when the decimal representation of character's collating value contained a non-zero digit in the 100s position and zero in the 10s position. The problem only occurred when the standard PATCODE C was redefined with an alternative pattern table. This is now fixed. (C9E07-002609)

Logging interval (in count of transactions) is now configurable for all replication servers - source, receiver and update process. The source server -START, -ACTIVATE, -DEACTIVATE, and -CHANGELOG commands accept an optional qualifier -LOG_INTERVAL=n where n is a positive number. Source server prints a message in the server log after sending every n transactions. If -LOG_INTERVAL is not specified with -START or specified as 0, the logging interval is set to its default value 1000. If -LOG_INTERVAL is not specified or specified as 0 with -CHANGELOG or -ACTIVATE or -DEACTIVATE, the logging interval is left unchanged. The receiver server START (except when -UPDATEONLY is specified) and CHANGELOG commands accept an optional qualifier -LOG_INTERVAL=[m][,n] where n and m are numbers. The receiver server prints a message in the receiver log after receiving every m transactions. The update process server prints a message in the update log after processing every n transactions. If -LOG_INTERVAL is not specified with -START, the logging interval for both receiver and update process is set to the default 1000. If -LOG_INTERVAL is specified with -START, and either interval (m or n) is not specified or specified as 0, the default value of 1000 is used for the corresponding server. If -LOG_INTERVAL is not specified with -CHANGELOG, the logging interval of receiver and update process are left unchanged. The same holds when -LOG_INTERVAL is specified, but the corresponding server's interval is specified as 0, or not specified (m is specified but not n, or vice versa). To change the receiver's logging interval alone, you can specify -LOG_INTERVAL=m (or -LOG_INTERVAL=m,0). To change the logging interval of update process alone, you can specify -LOG_INTERVAL=,n (or -LOG_INTERVAL=0,n). Note: The source server optimizes communication with receiver by bunching multiple transactions into a single send operation. This may mean that more than LOG_INTERVAL transactions may be sent before the source server logs a message. This may also mean that source server messages are not always spaced at LOG_INTERVAL transactions. LOG_INTERVAL specification for source server must be considered as advisory - there is no guarantee that the interval specification will be strictly followed. Special note for OpenVMS: The receiver server -LOG_INTERVAL specification must be quoted. That is, /LOG_INTERVAL="m,n" form must be used. (C9E09-002633)

When an M file name had more than 8 characters (i.e. longer than the earlier M name limit), in some cases, ZLINK would fail, reporting error messages with junk characters. This bug is fixed and ZLINK works correctly even if the M file name contains more than 31 characters (i.e. the new M name limit). GT.M truncates the compiled object file names to 31 characters, excluding the .o or .OBJ extension. (C9E11-002670)

GT.M on UNIX/Linux now recognizes when the $PRINCIPAL device is a TCP/IP socket. Previously such devices were treated as regular files. This feature is designed to allow a GT.M process to be started in response to a connection request made via inetd/xinetd. [UNIX] (S9C05-002119)

When using xinetd, socket_type should be "stream" and wait should be "no" as in the example below:

 service gtmserver
    {
	disable		= no
	type		= UNLISTED
	port		= 7777
	socket_type	= stream
	wait		= no
	user		= gtmuser
	server		= /path/to/startgtm
    }
                                                    
                                                    
                                                    

If the service is defined in /etc/services, the type and port options are not needed. See the xinetd.conf man page for more details.

When using inetd, the sockettype should be "stream", protocol "tcp", and the "nowait" flag should be specified as in the example below, which assumes a gtmserver service is defined in /etc/services:

    gtmserver stream tcp nowait gtmuser /path/to/startgtm
                                                   

In both of the above examples, "gtmserver" is the arbitrary name for the service being defined, "gtmuser" is the name of the user the service should be run as, and "/path/to/startgtm" is the name of a script which defines some environment variables needed by GT.M before starting it.

The minimum variables are $gtm_dist which should specify the directory containing the GT.M distribution and $gtmroutines. As an example:

    #!/bin/bash
    cd /path/to/workarea
    export gtm_dist=/usr/local/gtm
    export gtmroutines="/var/myApp/o(/var/myApp/r) $gtm_dist"
    export gtmgbldir=/var/myApp/g/mumps.dat
    $gtm_dist/mumps -r start^server
                                                   
                                                   

When start^server begins, the $PRINCIPAL device will already be connected and $KEY will contain "ESTABLISHED|socket_handle|remote_ip_address". In most cases, a USE should be executed to set various device parameters such as delimiters.

ZSHOW "D" will provide both the local and remote addresses and ports:

                                                   

  0 OPEN SOCKET TOTAL=1 CURRENT=0
          SOCKET[0]=h11135182870 DESC=0 CONNECTED ACTIVE  NOTRAP
REMOTE=10.1.2.3@53731 LOCAL=10.2.3.4@7777
	                ZDELAY  ZBFSIZE=1024 ZIBFSIZE=0
                                                   

Currently this feature is not available on OpenVMS.

A bug in $TEXT(), that would cause abnormal process termination due to access violation when an indirection argument is used with $TEXT(), has been fixed. (S9D12-002412)

Heavy usage of routine calls passing indirect argument(s) by reference [e.g. do label(.@arg)], or for loops using indirect index variable [e.g. for @index=1:10] in a long running M process used to cause abnormal termination. This has now been fixed. (S9E04-002439)

Changes introduced in V4.4-004 for long records in RMS files as part of TR S9D06-002345 had an undesirable side effect of not allowing access to NFS mounted files. This has been fixed. [OpenVMS] (S9E06-002470)

A bug in M Profiling that, in rare circumstances, would terminate the process abnormally or produce corrupted and/or missing information in the global on the VIEW "TRACE", is now fixed. [Solaris] (S9E08-002479)

When there is a situation where GT.M fails to write to a journal file (say, due to lack of disk space or other disk I/O problem) for a region that is replicated, GT.M now turns OFF both journaling and replication issuing a REPLJNLCLOSED error in the operator log. The only way to turn replication back ON is by bringing down the instance as the transition from replication off to replication on needs standalone access. However, GT.M would previously permit a user to turn journaling ON while keeping the replication state OFF. In a replicated environment, this state is an out-of-design situation that would cause GT.M processes to terminate with cascading GTMASSERT errors. (S9E08-002485)

Effective V5.0-000, GT.M provides the means to:-

In order to support these features, GT.M internally maintains an additional replication state, called WAS_ON, which is also reflected in the file header, to indicate that replication was ON but currently turned OFF due to journal file I/O problems. The following are the commands with new behavior when the replication state is WAS_ON:

These commands also switch the journal files implicitly cutting previous journal links of those regions for which replication state is restored from WAS_ON to ON. No previous journal files of those regions can be used for rollback.

DSE DUMP displays the new replication state WAS_ON in the file header as shown below:

DSE > dump -f

File            /xyz/mumps.dat
Region          DEFAULT
Date/Time       31-MAY-2005 15:34:48 [$H = 60051,56088]
  Access method                          BG  Global Buffers                1024
  Reserved Bytes                          0  Block size (in bytes)         1024
  Maximum record size                   256  Starting VBN                   129
  Maximum key size                       64  Total blocks            0x00000065
  Null subscripts                     NEVER  Free blocks             0x00000062
  Standard Null Collation             FALSE  Free space              0x00006000
  Last Record Backup     0x0000000000000001  Extension Count                100
  Last Database Backup   0x0000000000000001  Number of local maps             1
  Last Bytestream Backup 0x0000000000000001  Lock space              0x00000028
  In critical section            0x00000000  Timers pending                   0
  Cache freeze id                0x00000000  Flush timer            00:00:01:00
  Freeze match                   0x00000000  Flush trigger                  960
  Current transaction    0x0000000000000001  No. of writes/flush              7
  Maximum TN             0xFFFFFFFFDFFFFFFF  Certified for Upgrade to        V5
  Maximum TN Warn        0xFFFFFFFF5FFFFFFF  Desired DB Format               V5
  Master Bitmap Size                     64  Blocks to Upgrade       0x00000000
  Create in progress                  FALSE  Modified cache blocks            0
  Reference count                         1  Wait Disk                        0
  Journal State                         OFF  Journal Before imaging        TRUE
  Journal Allocation                    100  Journal Extension              100
  Journal Buffer Size                   128  Journal Alignsize              128
  Journal AutoSwitchLimit           8388600  Journal Epoch Interval          30
  Journal Yield Limit                     8  Journal Sync IO              FALSE
  Journal File: /xyz/mumps.mjl
  Mutex Hard Spin Count                 128  Mutex Sleep Spin Count         128
  Mutex Spin Sleep Time                2048  KILLs in progress                0
  Replication State            [WAS_ON] OFF  Region Seqno    0x0000000000000001
  Resync Seqno           0x0000000000000001  Resync trans    0x0000000000000001
                                                        

The update process is fixed to generate a process dump for memory-exhausted errors GTM-E-MEMORY [UNIX] and GTM-E-VMSMEMORY [OpenVMS]. These error messages are also modified to display the caller information to help identify the error location for debugging purposes. (S9E09-002496)

In direct mode, a TSTART command that specifies a list of un-subscripted local variable names to be restored on a RESTART works correctly (previous versions would abnormally terminate with this usage). Please note that with GT.M's optimistic concurrency control, TSTART is not appropriate anyway in direct mode. (S9E10-002504)

When an M stack overflow occurs, GT.M on both UNIX and OpenVMS tries to prevent a core/dump file from being created as an M stack overflow is indicative of an application software bug rather than a GT.M bug. However, on OpenVMS, under certain conditions, doing a quiet non-dump exit after a stack overflow requires unwinding a stack, which may have become malformed during the unwind. In such a case, various GTMASSERTs or even ACCVIOs are possible. To mitigate this issue, GT.M on OpenVMS platform is being changed so that it will generate a dump (if set proc/dump is enabled) on an M stack overflow. This is not a GT.M system error but is the only way the process can be terminated without spurious other errors. [OpenVMS] (S9F10-002569)

GT.M used to incorrectly evaluate certain hard-to-characterize pattern match expressions that contain alternations. These are now fixed. (S9F11-002577)

Previous versions of GT.M did not correctly save and restore $REFERENCE over the execution of $ZINTERRUPT code if the latter used extended references. This could cause inexplicable changes in $REFERENCE should code be interrupted (by MUPIP INTRPT) in the wrong place. This is now fixed. (S9F12-002580)

When a GT.M process on OpenVMS runs short of storage while allocating string descriptors for an external C call, it used to GTMASSERT. This is now changed to give a VMSMEMORY2 error. Three new ntrinsic Special Variables namely, $ZALLOCSTOR, $ZREALSTOR, and $ZUSEDSTOR are added (in both UNIX and OpenVMS) are now included in ZSHOW reports to help identify storage related problems. The $ZREALSTOR value is the total real (process) storage allocated by GT.M that may or may not actually be in use. The $ZALLOCSTOR value is the storage that is (sub) allocated (including overhead) by GTM to various callers. The $ZUSEDSTOR value is the value in $ZALLOCSTOR minus the overhead and represents the actual amount of storage that was requested. (S9G01-002585)

In previous versions of GT.M on UNIX, the file descriptor used for /dev/null was not released on Close. This caused a leak, and a process repeatedly performing Open, Write, and Close on /dev/null could eventually cause file descriptors to be exhausted or it's quota of file descriptors to be consumed. This bug is fixed. [UNIX] (S9G03-002600)

MUPIP JOURNAL -RECOVER/-ROLLBACK, that could previously fail with HTOFLOW error due to overflow of internal hash tables, now works correctly with no errors. GT.M no longer limits the growth of the hash tables that are used internally as long as adequate system memory resources are available. (C9D06-002288)

MUPIP upgrade now properly checks for standalone access to upgrade a database and will not "re-upgrade" an already upgraded database. (C9D10-002441)

A bug, that would cause MUPIP BACKUP -BYTESTREAM command on multiple regions without SINCE or TRANSACTION qualifiers to backup incorrect transactions, is now fixed. (C9E08-002621)

When too many global variables were specified in the EXCLUDE qualifier with MUPIP REORG, prior GT.M versions would terminate prematurely with a MUREORGFAIL error. This is now fixed. (C9E11-002665)

An online backup of a database with NOBEFORE-IMAGE journaling and which is being updated concurrently by TP transactions in very rare cases could have structural damage. This issue affected only the backup database, not the actual database. This is now fixed. (C9F03-002713)

On the HP Alpha/AXP Tru64 UNIX platform, a MUPIP RESTORE could in rare cases result in a damaged database due to one or more bitmap blocks not being properly restored. This resulted from an issue in the Tru64 C compiler, which generated incorrect machine code with certain optimization flags. As a workaround pending a fix to the compiler, the GT.M C source code has been reordered to ensure that proper machine code is generated. [Tru64 UNIX] (C9F08-002750)

While restoring from the TCP sockets, MUPIP RESTORE would report a SIG-11 (segmentation violation) if it encountered any errors when reading from the TCP stream. This is now fixed to issue a more appropriate error and terminate gracefully. (C9G04-002781)

MUPIP JOURNAL -RECOVER/-ROLLBACK is now much more robust in recovering (backward recovery) from before-image journal files that were actively being updated during a system crash. There are two aspects to this. One is that each journal record has a new checksum field which helps better differentiate valid versus invalid journal records in the tail of the journal file. Another is that backward recovery/rollback now knows to handle journal files that have a sequence of invalid journal data followed by valid journal data on disk (this is possible in some cases of a system crash). In earlier versions, backward recovery/rollback on such journal files would error out prematurely. (S9E04-002440)

MUPIP JOURNAL -ROLLBACK -FETCH_RESYNC could fail incorrectly with a GTMASSERT message in case one or more regions had no updates after the source server was started and before it was shutdown. This is now fixed. (S9E04-002447)

Restarting the source server no longer keeps journal files open when such files do not need to be read for replication. (S9E05-002460)

Source server reports "GTM-E-NOPREVLINK, Journal file <file-name> has a null previous link" if it detects a null previous link in a journal file that it reads. Previously, an error of the form "GTM-E-JNLFILOPN, Error opening journal file for database file <region-name>, %SYSTEM-E-UNKNOWN, Unknown system error 0" would have been issued. (S9E06-002468)

MUPIP SET -JOURNAL on multiple regions that had concurrent GT.M activity could, in rare cases, cause deadlocks. This bug is now fixed. (S9E09-002490)

The source server has two modes of operation, reading from the journal pool (pool-read) and reading from the journal files (file-read). If there is little or no backlog, then the source server reads journal records from the pool. Whenever the backlog builds up more than the pool can hold, the source server switches to reading from the files and similarly switches to reading from the pool if the backlog reduces to what the journal pool can hold. When the source server transitions from file-read to pool-read mode and it has multiple journal files (including earlier generations) open for one or more regions, it used to fail to close the oldest generation journal file of those regions. With every such transition from file-read to pool-read mode, the number of un-closed (and hence open) files used to keep increasing until the maximum-open-files limit for the process was reached. At that point, the source server used to exit with a "Too many open files" error. The source server now correctly closes the oldest generation journal file thereby avoiding this open file buildup. (S9E09-002493)

On the secondary of an application deployed in a logical dual site configuration, helper processes can now be used to speed the rate at which updates can be committed to disk. For those environments where the primary is able to commit updates faster than the secondary can, resulting in the build up of a backlog on the primary, helper processes may be able to increase the rate at which the secondary can commit updates. See technical bulletin GT.M Helper Processes for details.(S9E10-002497)

The MUPIP SET -FLUSH=xx command that is used to set the number of buffers being flushed at each IO flush is no longer ignored nor does it require standalone access, as it did before. (S9F11-002578)

In rare cases, MUPIP LOAD when used with a fillfactor that is less than 100% used to issue a GVPUTFAIL error with the failure code HHHH even though the record it tried to load was valid. This issue is now fixed. (S9G01-002587)

The maximum lockspace size is increased in both GDE and MUPIP SET from 1000 to 65536 blocks of 512 bytes each. (S9G01-002589)

GT.M V5.0-000D fixes several issues with MUPIP LOAD when used with the BEGIN or END qualifiers. (S9G01-002592)

When a backup was (re)started, several fields related to backup error processing were not properly cleared. If an earlier backup failed, it prevented any fresh backups from starting and displayed an error message. This led to "file not found" errors or denial of permissions. The error, introduced in GT.M V5.0-000, has now been fixed. (S9G02-002597)

All database updates during a MUPIP BACKUP ONLINE operation are logged into a temporary file that is used by MUPIP BACKUP after creation of a database copy. The temporary file size could increase to more than 2 GB depending on the duration of the copy creation and the update activities. In such cases, MUPIP BACKUP previously issued an EOVERFLOW error when it tried to read from an offset greater than 2 GB. This error has been fixed in GT.M V5.0-000D and MUPIP BACKUP can now handle temporary files of arbitrary size. (S9G03-002608)

GT.CM OMI server's PID is written into log file. [Solaris] (C9C04-001967)

The internal consistency checks in DSE INTEG have been improved to detect and report a few cases of previously undetected DBMAXNRSUBS, DBKEYORD, DBINVGBL, DBDIRTSUBSC, and DBBDBALLOC errors. (C9E04-002574)

LKE SHOW -ALL -WAIT, now displays correct values of process-ids that are waiting for all LOCKs to be granted. A bug where incorrect values were sometimes displayed has been fixed. (C9E07-002607)

DSE CACHE/CHANGE command on OpenVMS now works on all valid locations in database shared memory. Previously it would work only for a small portion of shared memory. [Alpha/AXP OpenVMS] (C9G03-002776)

Network conditions when performing a network IO operation can result in an hang of GT.CM OMI server. There is now a -servtime command line parameter (default value 60). If a network IO operation does not complete within the number of seconds specified by the -servtime parameter, the GT.CM OMI server process will go through an internal recovery procedure to clear the "hang". [Solaris] (S9C11-002246)

The startup script of GT.CM OMI server has been modified to check the existence of running other GT.CM OMI servers, which eliminates the possibility of "Address already in use" error. [Solaris] (S9D06-002330)

GT.CM OMI servers no longer dump core in the case of errors that need to be logged in syslog. [Solaris] (C9B11-001829) (S9E11-002509) (S9E04-002453)

The DSE add -star command no longer terminates abnormally with a SIGADRALN error on Solaris, SIG-10 on HP-UX or unaligned access errors on Tru64 UNIX if the STAR key is added the end of an index block whose bytes in use field (before the add -star command) is not a multiple of 4. [Solaris/HPUX/Tru64] (S9E12-002512)

GDE previously incorrectly disabled the STDNULLCOLL parameter for the TEMPLATE region, while reading from a global directory (.gld) file. Even when STDNULLCOLL was enabled in a previous session, saving and reloading the file in a subsequent session previously would result in an incorrect value. This bug is now fixed. (S9G01-002590)

DSE Numeric Input Changes

DSE interprets all numeric input as hexadecimal, except:

For the CHANGE -BLOCK command:

LEVEL
                                                  

For the CHANGE -FILEHEADER command - all the time values:

AVG_BLKS_READ
BLK_SIZE
DEF_COLLATION                                                   
HARD_SPIN_CPUNT
JNL_YIELD_LIMIT
KEY_MAX_SIZE
RE_READ_TRIGGER
RC_SRV_COUNT
RECORD_MAX_SIZE
REFERENCE_COUNT
RESERVED_BYTES
SLEEP_SPIN_COUNT
SPIN_SLEEP_TIME
TIMERS_PENDING
TRIGGER_FLUSH
UPD_RESERVED_AREA
UPD_WRITER_TRIGGER_FACTOR
WAIT_DISK
WRITES_PER_FLUSH
                                                      

If -DECIMAL is specified on EVAL, and -VERSION on the REMOVE and RESTORE commands, decimal is used. This convention corresponds to the displays provided by DSE and by MUPIP INTEG.

The following qualifiers now always interpret values as decimal. Previously, for UNIX, if there was a "0x" prefix or hexadecimal digits, the value would be interpreted as hexadecimal.

CHANGE -BLOCK:  -LEVEL
CHANGE -FILE:  -TIMERS_PENDING, -WRITES_PER_FLUSH
EVAL:  -NUMBER if -DECIMAL is specified
                                                      

The following qualifiers now always interpret values as hexadecimal. Previously, they only interpreted values as decimal.

CHANGE -FILE:  -REG_SEQNO, -RESYNC_SEQNO