GT.M currently supports $DEVICE and $KEY for device status on only some devices; GT.M maintains status information in the $ZA, $ZB and $ZEOF ISVs for all devices. (S9F06-002553)

Using a subscripted control variable with a FOR command and assigning to it an expression containing an extrinsic function generates a FORCTRLINDX error. The workaround is to call the function and assign the result to a variable before using it in the FOR command, or otherwise avoiding this odd construct. (C9L03-003392)

A TPRESTART does not reevaluate any expressions used in its arguments or possible postconditional on the initial TSTART. (C9B03-001662)

GT.M provides an option to not short-circuit Boolean expressions. For more information refer to GT.M V5.4-002 series Release Notes.

An intrinsic function containing extrinsic functions in its arguments may not evaluate according to the standard unless the extrinsic functions have no side effects on the other arguments to the intrinsic function, or a sole extrinsic function call is in the first argument to the intrinsic function. If your code must use extrinsic functions with side effects, the workaround is to use precalculated temporary variables to avoid using extrinsic functions as arguments to intrinsic functions. (C9B10-001766)

After a complete ROLLBACK, $REFERENCE evaluates to an empty string in conformance with the standard. However, after an incremental ROLLBACK (invoked by TROLLBACK intexpr), $REFERENCE evaluates to the last global reference whether or not the incremental ROLLBACK action discarded that last global reference. In the future, FIS plans to make the $REFERENCE evaluate to an empty string after all TROLLBACK commands. (C9B12-001841)

For SOCKET devices, certain attributes (WIDTH, LENGTH, [NO]WRAP, EXCEPTION, FILTER, IPCHSET, OPCHSET) and certain status information ($KEY, $DEVICE, $X, $Y, $ZEOF, $ZA, $ZB) apply to the device and are shared if there are multiple sockets associated with the device. Workarounds include using separate devices for each socket, or capturing socket state before a USE of another socket on the same device. (C9C05-001988)

GT.M does not detect the error when you do something like SET a="@",@a="bad" and does nothing. Avoid invalid syntax like this. (C9C05-001992)

GT.M mishandles a pattern match literal of more than 14 characters, producing inappropriate results including possible process failure. The workaround is to break long literals in a pattern match into multiple elements of 14 characters or less. (C9C10-002148)

Where the standard calls for a SOCKET mnemonic space parameter of LISTEN, GT.M supplies ZLISTEN with the same functionality. (C9D01-002216)

GT.M does not accept Intrinsic Special Variables (ISVs) as indirect left-hand arguments to a SET command. Workarounds include avoiding indirection or using indirection on the entire SET argument. (C9D01-002226)

$QUERY() on global variables using the default legacy GT.M null subscript collation does not work if the last subscript specified in the global variable is a null subscript, because the legacy GT.M collation places the null subscript between numeric and string subscripts. If a global variable must have null subscripts, FIS strongly recommends that you specify standard null collation, which places a null subscript before all other subscripts. For more information on enabling standard collation for null subscripts, refer to GT.M Null Subscripts and Null Subscriptions Collation. FIS maintains the legacy behavior as the default to avoid breaking applications that rely on it. (C9E11-002667)

GT.M treats something like SET indr="label+1" DO @indr as a missing label rather than a syntax error. The workarounds are to avoid invalid syntax like this or be aware the resulting error is less helpful than it might be. Note that $TEXT() using this syntax simply returns an empty string result. (C9E12-002682)

For a SOCKET device, if WRAP is enabled for the device (as it is by default) and the device encounters a WRITE or series of WRITEs that produce an exact multiple of WIDTH characters, it can exhibit inappropriate behavior. On UNIX, if those preconditions are met and if the DELIMITER device parameter is specified (say in the OPEN command, or a USE command) and subsequently a USE command specifies NODELIMITER, GT.M may write invalid characters on the output socket at the WRAP boundary. On OpenVMS if those preconditions are met and NODELIMITER is specified, or DELIMITER is not specified in the OPEN or USE command, GT.M incorrectly issues a SOCKWRITE error. Also in OpenVMS, every subsequent WRITE causes the same error, and so, nothing more can be successfully sent until the SOCKET is reinitialized. In both cases, The workaround is to explicitly WRITE # every WIDTH characters. (C9F03-002711)

Since GT.M compiles, rather than interprets code, when it encounters an invalid argument, even one for a command followed by a postconditional that is literally zero (FALSE), it issues a compilation warning. If there is a need for such arguments, the workaround is to keep them after an IF with an argument that evaluates to FALSE. Note invalid arguments to commands bypassed by postconditions do not cause run-time errors, only compile-time errors. (C9I05-002991)

A SET where the left-hand side of the argument is an indirection that resolves to a subscripted variable and the right-hand side contains an extrinsic function or special variable that modifies a subscript of the left-hand target, uses the modified subscript while it should use the unmodified subscript. The workaround is to avoid the indirection if possible, indirect the entire argument, or assign the result of the extrinsic to a temporary variable and use the temporary variable in the original right-hand argument. (C9J06-003133)

While writing M program and scripts, you should consider the following GT.M internal limits:

Numbers	Numbers in GT.M are nominally accurate to 18 significant digits. As long as the integer part is less than or equal to 15 digits, GT.M ensures accuracy to at least three decimal places. The range of numbers represented is 1E-43 through 1E47. When application code results in a number that is in-range but with more than 18 significant digits, GT.M silently retains the most significant 18 digits. When a computation results in a large number out of range, GT.M gives a NUMOFLOW error. When a computation results in a small fractional number out of range, GT.M treats it as zero (0).
Local and global variable names, label names, routine names and M lock resource names	GT.M distinguishes these names using the first 31 characters (not counting any leading caret). GT.M silently uses only the first 31 characters of longer names internally.
Source and object file names (not including the extension)	31 characters. When forming routine names, the GT.M compiler truncates default filenames to 31 characters. For example, the compiler considers the routine name for a source file Adatabaseenginewithscalabilityproven.m to be Adatabaseenginewithscalabilityp.m. This silent truncation can work, but is best avoided as it can cause frequent recompilation and problems should the recognized name length increase.
Local variable string	1 MB
Trigger Names	GT.M silently uses only the first 28 characters of longer names internally.
Replication instance name	16 characters
Subscript Limit	31 subscripts
Key size	The maximum key size is 255 bytes. When determining the maximum key size, applications should consider the following: GT.M uses packed decimal representation for numeric subscripts which may be larger or smaller than the original representation. GT.M substitutes an element terminator for the caret (^), any comma (,), and any right parenthesis ()). GT.M adds an extra byte for every string element, including the global name. For example, the key ^ACN ("Name", "Type") internally occupies 17 bytes.
Record size	The maximum record size (in bytes) is: block_size - block_header_size - reserved_bytes where block_header_size is 16 bytes.
Block size	The maximum block size is 65,024 bytes. FIS recommends against using databases with block sizes larger than 16KB. If a specific global variable has records that have large record sizes, FIS recommends placing that global variable in a file by itself with large block sizes and using more appropriate block sizes for other global variables. 4KB and 8KB are popular database block sizes.

GT.M does not compile a routine containing more than 4096 [AIX, HPUX, Tru64 Unix, OpenVMS] or 16384 [Linux, Solaris] unique local variable names. If a routine contains more local names than this limit, GT.M terminates with a GTMASSERT error. Note that this restriction does not apply to local variable names used in indirection code. The workaround is to break the large routine into two or more smaller routines containing fewer local names. (S9E11-002507)

GT.M does not support database and journal files which reside on an NFS mounted filesystem. However, you can use an NFS mounted filesystem for keeping source and object code modules and performing sequential file IO.

In order to prevent Direct Mode activity from affecting other processes, a process always releases any critical sections at the time of entering the Direct Mode. For M transactions, this has 2 implications:

	FIS strongly recommends not including any Direct Mode - or indeed any human interaction - inside a transaction. (S9911-001425)

"Z" pseudo transactions (those bracketed with ZTSTART/ZTCOMMIT commands) are no longer supported - they do not work in a replicated environment. Remove their use from your application code before using replication.

FIS strongly recommends that you avoid suspending a running GT.M process (on UNIX) with <CTRL>-Z or by sending a SUSPEND signal. Suspending a process actively participating in the management of a shared database may result in a database hang if the suspended process holds a critical section. You can redefine ^Z in the shell to avoid sending a SUSPEND. [UNIX] (S9C09-002229)

Using the ^%gbldef function while journaling (or database replication) is in progress can corrupt the journal file. The workaround is to turn off journaling when performing administrative actions with ^%gbldef.(C9B03-001658)

GT.M currently treats all segments whose file specification is of the form VOLUMESET::UCI (access method USER) as remote DDP segments, even if the VOLUMESET is served by the GT.CM DDP server running on the local node. A GT.M client access to a global residing in such a VOLUMESET generates GTM-E-NOCONNECT error. The workaround is to map locally residing globals to local files, and not to a VOLUMESET::UCI pair. FIS has no plans to change this behavior. [OpenVMS]

TSTART may abnormally terminate the process if there are more than 4 variables specified in the list of preserved locals variables. [OpenVMS] (C9E11-002656)

MERGE ^gvn2=^gvn1 does not work correctly if ^gvn1 and ^gvn2 have different alternative collation (act) settings, The subscripts of the source global may not be transformed according to the destination collation setting before placing them in the destination global. The workaround is to set up a loop to sequence through the global nodes in ^gvn1 and copy each in turn to ^gvn2. (C9E11-002663)

If your user-defined alternate collation routines gtm_ac_xform_1()/gtm_ac_xback_1() use the OpenVMS mailbox facility, you must initialize the dsc64$w_mbo and dsc64$l_mbmo fields in the control structures, as GT.M does not. [OpenVMS]

For the a terminal Principal device ($PRINCIPAL), GT.M works with the terminal characteristics or settings in place when it is invoked, changes terminal settings as specified by deviceparameters on USE commands, and leaves the terminal in its then current state when GT.M terminates. If invoking code and GT.M need different terminal characteristics, they must be explicitly managed by some combination of USE commands and code in the invoking program or script. For example in UNIX, an invoking script might use the "stty sane" command after a GT.M invocation. (S9F01-002524)

Using ZMESSAGE with arguments outside the range of messages defined by GT.M can simulate operating system conditions that terminate the process. (C9A10-001605)

In OpenVMS, GT.M truncates all error messages that are longer than 255 characters. This is most likely to happen with long file specifications - a workaround is to shorten file names and paths. [OpenVMS] (C9C04-001974)

In UNIX, the STARTUP jobparameter cannot define environment variables for the M process (GT.M documentation states otherwise). [UNIX] (C9C07-002091)

Attempts to remove the stack level caused by an implicit Xecute such as $ZTRAP immediately above a Direct Mode frame with a QUIT may not work. The workaround is to use ZGOTO in these cases. (C9C11-002180)

A GTM-E-STACKCRIT error while executing $ZTRAP leaves GT.M in direct mode. In general, such errors in $ZTRAP should cause GT.M to terminate instead of entering direct mode. Error trapping with $ETRAP ensures that the process does not unintentionally enter direct mode. FIS strongly recommends using $ETRAP, or $ZTRAP code that detects the STACKCRIT error and terminates the process or takes corrective action such as a suitable ZGOTO. (C9C11-002181)

ZGOTO with an indirect entry reference argument (i.e. ZGOTO level:@entryref where entryref is of the form "lab^rtn") fails with a LABELMISSING error even if the label is available in the specified routine. This is consistent with the specification for ZGOTO - use indirection of the entire ZGOTO argument instead.

If a routine of more than 31 characters long is auto-compiled by auto-ZLINK or ZLINK, GT.M does not truncate the object file name to the maximum routine length (31 characters). This behavior causes any subsequent auto-ZLINK to fail to locate the object file. The workaround is to compile the routines with long names explicitly with the mumps command before auto-ZLINK attempts to compile. (C9E12-002678)

GT.M needs to be able to execute code in a process' heap/stack space because GT.M is a compiler and M requires code that is able to dynamically compile and execute. As this is not a requirement of typical C/C++ programs, and one of the precepts of good security is to grant no privileges save those that are required, it is increasingly common for default security settings to disable the ability of a process to execute code from heap/stack space.

Different operating systems have different ways to configure this security setting, and there can be multiple ways to configure this functionality on any given operating system. Users may experience unexpected segmentation violation – SEGV (sig-11) errors such as:

%GTM-F-KILLBYSIGSINFO1, GT.M process 23914 has been killed by a signal 11 at address 0x092C57D0 (vaddr 0x092C57D0)

Identify the security configuration setting that prevents GT.M processes from executing code in heap/stack space and configure it to allow GT.M processes to do so. One example of an implementation of such a feature is exec-shield on some distributions of GNU/Linux.  Examine the following files to determine the status of exec-shield:

/proc/sys/kernel/exec-shield and /proc/sys/kernel/exec-shield-randomize
cat /proc/sys/kernel/exec-shield
cat /proc/sys/kernel/exec-shield-randomize

If either value is non-zero, you may need to set it to 0: 

echo 0 >/proc/sys/kernel/exec-shield
echo 0 >/proc/sys/kernel/exec-shield-randomize

Versions of GT.M starting from V4.2-000 do not process the response to the "What file: " prompt on the initiating terminal when a mumps -run omits routine names on the command line. The workaround is to specify the routine name as an argument to the original command. [UNIX] (C9C04-001965)

A file specification for the -LOG qualifier containing semicolon (;), or a version number causes the replication server to issue an RMS file specification error. [OpenVMS] (S9C07-002161)

MUPIP JOURNAL RECOVER/ROLLBACK -BACKWARD may leave a database with KILL_IN_PROG and "GTM-E-DBMRKBUSY, Block incorrectly marked busy" errors. Although you should address these errors as soon as convenient, they are benign as long as they are the only integ errors in the database (as discussed in the GT.M User documentation). (C9902-000863)

Replication filters are not supported on OpenVMS. (C9B04-001674) [OpenVMS]

When the disk space is too low for recover/rollback to operate, recover/rollback can terminate abnormally. (C9B09-001758)

Replication instance definition on OpenVMS uses a global directory, rather than a replication instance file. [OpenVMS] (C9B11-001785)

If there is no space left in the disk where a journal file resides, GT.M will stop journaling for that database. If that database is part of a replicated instance, GT.M also turns replication off if it needs to use the missing journal, in other words, if the in-memory journal pool overflows. Depending on the circumstances, recovery may involve recreating secondary instances that replicate from that instance. Please ensure that there is always adequate space on devices where journal files are written.

MUPIP EXTRACT fails to extract globals residing on a local node if the next global in collation sequence resides on a remote node. The workaround is to use a global directory that omits remote globals before performing MUPIP EXTRACT operations. (C9B11-001834)

Always perform a MUPIP RECOVER or ROLLBACK as the first step to restore a journaled database after a crash. Never start GT.M updates or use MUPIP SET -JOURNAL before the recovery, as this affects subsequent recover or rollbacks and prevents them from being successful. GT.M does not strictly enforce this order of steps. (C9C01-001892)

MUPIP INTRPT commands initiated while the target process is already handling an interrupt can cause failure of the target process. The workaround is to avoid using MUPIP INTRPT on any given process too soon after the previous MUPIP INTRPT - a delay of a second is ample in most environments. [OpenVMS] (C9C04-001970)

If the logical names SYS$OUTPUT and/or SYS$ERROR are redefined to a file with a DEFINE /USER command, certain utility commands (for example. MUPIP JOURNAL /SHOW, MUPIP BACKUP, DSE) on a journaled database terminate with a RMS-E-FLK error. The workaround is to use a script that runs only the utility command. The script then can perform, in the beginning, a DEFINE SYS$OUTPUT and DEFINE SYS$ERROR without the /USER qualifier. [OpenVMS] (C9C05-001984)

FENCE=ALWAYS may work incorrectly when multiple regions are involved. FIS strongly recommends migrating your application to standard transaction processing rather than the less capable ZTSTART/ZTCOMMIT approach. (C9C06-002025)

GT.M relies on the monotonic increase of time stored in the journal records to maintain application consistency across multi-region fenced transactions. If the time stamp in later journal records states an earlier time than the time stamp in earlier journal records, GT.M database recovery after a crash may be complicated and even compromised.

When adjusting the system clock to maintain the correct time, FIS strongly recommends "slewing" it rather than "stepping" it. Standard packages such as NTP provide this capability.

Since the system clock is traditionally set to UTC on UNIX systems, the transition from Daylight Savings Time to Standard Time does not involve stepping the clock, and the transition is transparent to GT.M on such systems.

On systems where the system clock is set to local time (which includes OpenVMS systems as well as those UNIX/Linux systems where the clock is not set to UTC), stepping the clock backwards is required when changing from Daylight Saving Time to Standard Time. At such times, as well as when the system clock has drifted so far that slewing it back to the right time is impractical, it may be necessary to step system time backwards.

Use the procedure below when you need to step the time backwards.

Whenever the new system time is prior to the recorded system time (that is, the time step was negative), then all future MUPIP RECOVER commands that use time qualifiers, which fall in the time range of adjustment need to use a time that is either less than the start time (for SINCE and AFTER qualifiers), or greater than the end time of the time range (for BEFORE qualifiers). In other words, possible recovery time options should never reference a time that is ambiguous because of the time change, but rather one that is either before any "overlapping time" or after the change. This includes the time in the journal files created by the first command in the instructions, but may include earlier times as well. (C9D06-002282)

MUPIP EXTRACT of a database in binary format on OpenVMS fails when database block sizes are over 32,765. In addition, MUPIP JOURNAL EXTRACT or MUPIP EXTRACT in ZWR or GO format terminate if they produce a record larger than 32,767 bytes, including the record header and terminators. This is due to OpenVMS RMS' limitation of 32767 bytes for the maximum record size of a sequential file. FIS recommends that you use a database block size of 32254 (the largest legal block size smaller than 32768) on OpenVMS. FIS has no plans to change this behavior. [OpenVMS]

If the duplicate SET optimization (see Release Notes for GT.M V4.4-004 for C9D12-002472) is enabled and if the update pattern is such that the last update in a sequence of updates is a duplicate-SET and there are no more updates for quite a while although the updating processes are still attached to the database, it is possible that the database file header does not get flushed in a timely manner. In this case, if before-image journaling is turned ON, it is also possible that EPOCHs are not written to disk in a timely manner. If the processes attached to the database are then killed abnormally due to a system crash or using a kill -9 (UNIX) or STOP/ID (OpenVMS), then a MUPIP JOURNAL ROLLBACK and/or RECOVER /BACKWARD on the same database produces an error as these commands rely on EPOCHs being written in a timely manner. The workaround is to issue a backward recovery with a /SINCE_TIME that matches the time of last update to this database or a rollback with a /RESYNC_SEQNO that matches the last update to this database. (C9E03-002536)

In GT.M versions starting from V4.4-002, the files that are created as a result of MUPIP EXTRACT /FORMAT=ZWR (or /FORMAT=GO) command have a maximum record size of 65,535 which may cause problems if other programs and OpenVMS utilities use them. To resolve this, issue the following DCL command:

set file/attribute=mrs=<longest record length> file.glo

where <longest record length> is the appropriate value from a DIRECTORY/FULL of the file (file.glo above.) [OpenVMS] (C9E03-002549)

If a process containing a HANG command is frequently interrupted by MUPIP INTRPT and the length of that HANG exceeds the period of the interrupt, the HANG command will never complete as it is restarted in its entirely when it is resumed after the process responds to the interrupt. The same is applicable to timeout on locks. Any timeout except READ SOCKET and READ TERMINAL reset when a RETURN from $ZINTERRUPT restarts the command. (C9H04-002848)

GT.M does not support LKE operations on LOCKs that are mapped to regions served by GT.CM. LKE still operates on LOCKs that exist on the local node even if a remote process through a GT.CM server holds them . The solution is to use LKE on the node which is processing the LOCK. (C9C05-001991)