YottaDB r1.20 is the most significant release to date from the YottaDB team. With the ability to call the data management engine directly from C, and eliminating the need for any application code to be written in M (by separating the M language from the database without compromising either in any way), YottaDB r1.20 represents a historic milestone for the YottaDB/GT.M code base.
YottaDB r1.20 is built on (and except where explicitly noted, upward compatible with) both YottaDB r1.10 and GT.M V6.3-003A. Highlights of enhancements and fixes made by the YottaDB team include:
A C API to call the data management engine directly. As C is the lingua franca of computer languages, this makes the engine accessible from other languages that can call C APIs. In the future, we anticipate creating standard wrappers to the engine from other languages, and we invite members of the community to do so as well.
Docker containers make it easy to get up and running with YottaDB for experimentation, DevOps and Microservices.
Performance improvements (up to two orders of magnitude in specific test cases) in large local arrays and garbage collection, especially in applications with large numbers of strings that change often.
As always, there as other enhancements and fixes, as noted below. See our Get Started page to use YottaDB.
A platform is a combination of a CPU architecture and an operating system. A platform is Supported, Supportable, or Unsupported. Supported means that we have the platform in our development environment and test each release on that platform. Supportable means that although we do not necessarily have such a platform in our environment, we have no reason to believe that the software will not run on it. All others are Unsupported.
Supported OS Version(s)
Ubuntu 16.04 LTS; Red Hat Enterprise Linux 7.4
Note that there are separate binary distributions for Ubuntu and Red Hat, owing to differences in library versions of those distributions.
Raspberry Pi 3 Model B; BeagleBone Black Wireless
Raspbian GNU/Linux 9.1; Stretch IoT (non GUI)
While YottaDB r1.20 is Supportable on other ARMv7-A CPUs, owing to variations in the implementations of ARM microarchitectures, we recommend that you ensure the software runs correctly before committing to any specific hardware other than those Supported. Please contact email@example.com if you want a specific combination of OS and CPU microarchitecture to be Supported.
Raspberry Pi Zero
Raspbian GNU/Linux 9.1
While YottaDB r1.20 is Supportable on other ARMv6 CPUs, owing to variations in the implementations of ARM microarchitectures, we recommend that you ensure the software runs correctly before committing to any specific hardware other than those Supported. Please contact firstname.lastname@example.org if you want a specific combination of OS and CPU microarchitecture to be Supported.
Recent releases of major GNU/Linux distributions with contemporary kernels, glibc and ncurses are Supportable. Running on Arch Linux requires the ncurses5-compat-libs package to be installed.
Send messages to stderr if syslog not present or not functional
The file libyottadb.so contains the runtime logic that was previously in libgtmshr.so, which is now a relative symbolic link to libyottadb.so. Similarly, libyottadbutil.so contains the object code for utility routines, and libgtmutil.so is a relative symbolic link to libyottadbutil.so. If UTF-8 support is installed, a similar change also occurs in the utf8 subdirectory. There should be no change to the behavior of any application program or scripting that does not explicitly check the nature of libgtmshr.so and libgtmutil.so. (https://github.com/YottaDB/YottaDB/issues/23)
YottaDB ignores the environment variable gtm_dist, deriving any needed information from within the running process. Previously, it required $gtm_dist to contain the name of the directory from which it ran. (https://github.com/YottaDB/YottaDB/issues/94)
The environment variable ydb_msgprefix specifies a prefix for YottaDB messages generated by a process, with the prefix defaulting to "YDB", e.g., YDB-I-DBFILEXT. Previously, the prefix was always "GTM". A value of "GTM" retains the previous format. (https://github.com/YottaDB/YottaDB/issues/97)
An integer value in seconds for the environment variable ydb_repl_filter_timeout sets a limit for the Source Server to await a response from an external filter program. The default value is 64 seconds; a value less than 32 is treated as 32 seconds; and a value greater than 131072 (2**17) is treated as 131,072 seconds. Set a value for ydb_repl_filter_timeout if, for example, your filter program is functionally correct, but needs more time to respond. Previously, the value was always 64 seconds. (https://github.com/YottaDB/YottaDB/issues/109)
At process startup, YottaDB initializes the following intrinsic special variables: (1) $zgbldir to the global directory file pointed to by $ydb_gbldir. If ydb_gbldir is not defined, YottaDB uses the gtmgbldir environment variable instead. (2) $zmaxtptime to the number of seconds specified by $ydb_maxtptime. If ydb_maxtptime is not defined, YottaDB uses the gtm_zmaxtptime environment variable instead, defaulting to 0 seconds (infinite timeout).To facilitate debugging application memory allocation bugs, the environment variable ydb_dbglvl optionally provides debugging flags as specified in the file gtmdbglvl.h. If ydb_dbglvl is not defined, YottaDB uses the gtmdbglvl environment variable instead. If neither is defined, no memory allocation debugging is turned on. Previously YottaDB ignored the ydb_dbglvl, ydb_gbldir, and ydb_maxtptime environment variables. (https://github.com/YottaDB/YottaDB/issues/115)
MUPIP SET JOURNAL issues a JNLCRESTATUS error in case it is not able to rename the current journal file (for example, because of read-only permissions on the directory containing the journal file) before creating the new journal file. In YottaDB r1.10, the MUPIP command used to abnormally terminate with a SIG-11.(https://github.com/YottaDB/YottaDB/issues/118)
MUPIP JOURNAL ROLLBACK works correctly in case a process updating multiple regions in a TP transaction terminates abnormally (e.g., kill -9). In YottaDB r1.10 (and GT.M V6.3-002), it was possible for the rollback to fail with a DUPTOKEN error in rare cases, depending on where in the transaction commit logic the process was killed. The workaround was to rerun the MUPIP JOURNAL ROLLBACK with a non-zero ERROR_LIMIT qualifier value to allow DUPTOKEN errors. In addition, NULL records are placed in the correct file (journal extract file, broken transaction file, lost transaction file). Previously, they could be incorrectly placed in the lost transaction file instead of the broken transaction file. Finally, the NULL records are extracted in the correct order (journal sequence number) in the extract file (or broken transaction or lost transaction file). Previously, the extract file would be sorted in terms of journal sequence number except for the NULL type of journal records (00 record type in the first column of the extract file) which could be placed in arbitrary order. Note that such a transaction remains Atomic, because the process termination means the transaction was never committed. Note also that YottaDB recommends terminating processes with MUPIP STOP and not kill -9. (https://github.com/YottaDB/YottaDB/issues/122)
Initiating replication connections between Source and Receiver Servers is more efficient. Previously, in rare cases, the Source Server unnecessarily disconnected the connection and reconnected. (https://github.com/YottaDB/YottaDB/issues/136)
In environments without a syslog facility (such as default Docker containers), messages intended for the syslog go to stderr of the YottaDB process. Previously, they appeared on the user's interactive session. YottaDB uses the existence of /dev/log to decide whether a syslog faclity exists. As syslog messages record important information about the operation of the YottaDB engine, we strongly recommend a syslog facility in all cases except single-user development environments. (https://github.com/YottaDB/YottaDB/issues/189)
Applications with large numbers of strings, which can occur with large numbers of local variables, local variables with many nodes, or both, and whose performance is limited by garbage collection, i.e. applications where the strings change frequently, run much faster. In one test case, the improvement was two orders of magnitude. (https://github.com/YottaDB/YottaDB/issues/85)
Nested database triggers (i.e. database triggers that invoke code to update global variables, which in turn invoke other triggers) work correctly. Previously, it was possible in rare cases involving multiple processes loading triggers at the same time for the processes to abnormally terminate with fatal SIGABRT (SIG-6) errors. (https://github.com/YottaDB/YottaDB/issues/169)
With the [NO]EDITING deviceparameter set to EDITING, the number of previous inputs to the READ command from a terminal device that can be recalled is a circular buffer of 99 entries, matching the size of the RECALL command buffer for direct mode. READ X#, READ *X, and READ X all share the same history. Empty inputs are excluded from the buffer, and multiple consecutive occurrences of the same input are stored once. The up-arrow key goes back in history, and the down-arrow key goes forward, towards more recent inputs. Previously the READ buffer was limited to just the previous line. (https://github.com/YottaDB/YottaDB/issues/83)
YottaDB correctly runs M programs which had PATNOTFOUND errors at compile time. Previously, in r1.10 it was possible for mumps processes to terminate abnormally with a SIG-11 as a consequence of a defect in the GT.M V6.3-002 code base.(https://github.com/YottaDB/YottaDB/issues/90)
Timeouts in JOB, LOCK, OPEN, READ, WRITE /WAIT, WRITE /LISTEN, WRITE /ACCEPT, and WRITE /TLS commands with more than three digits after the decimal point time out shortly after the requested time has elapsed. Previously, in r1.10, timeouts with more than three digits after the decimal point would be treated as 2Gi msec (≃24.8 days), owing to a defective enhancement to allow fractional timeouts introduced in the GT.M V6.3-002 code base GTM-5250 (https://github.com/YottaDB/YottaDB/issues/100)
$ZEOF is set correctly for files in the /proc file system. Previously, $ZEOF used to incorrectly return 1 after reading one line of such files even though the file had many more lines. (https://github.com/YottaDB/YottaDB/issues/120)
ZSTEP OVER and ZSTEP OUTOF work correctly across extrinsic function calls which return using the QUIT @ syntax. Previously, the ZSTEP would not pause (and execute the ZSTEP action) after the return from such function calls. (https://github.com/YottaDB/YottaDB/issues/141)
YottaDB issues a DIVZERO error when the divisor in a division operation is 0. In previous versions (r1.10 and r1.00 as well as all GT.M versions up to V6.3-003A), dividing by 0 in some numeric expressions resulted in a fatal KILLBYSIGSINFO1/SIGINTDIV error (for example set x=2E20 write 1/(x*0)). (https://github.com/YottaDB/YottaDB/issues/145)
A C program that invokes a call-in leaves the terminal in a sane state when it exits. Previously, some terminal characteristics would be changed (for example, character echo would be disabled) on exit, requiring an stty sane command to restore them. Additionally, YottaDB now changes the terminal characteristics only when necessary (i.e. a READ or WRITE from/to the terminal, or direct mode). Previously, it used to change them unconditionally at process startup. (https://github.com/YottaDB/YottaDB/issues/184)
A USE statement for a terminal device with parameters (CTRAP=$C(3):EXCEPTION="…") executes the specified M code fragment when a Ctrl-C is entered. Previously, the Ctrl-C was ignored. A workaround was to also specify the NOCENABLE option. (https://github.com/YottaDB/YottaDB/issues/186)
Call-ins are allowed even if a TP transaction is active (process is within a TSTART/TCOMMIT fence). Previously, a call-in while already in TP was not permitted, resulting in a CITPNESTED error. (https://github.com/YottaDB/YottaDB/issues/188)
When run with ydb_dbglvl / gtmdbglvl set as described in (https://github.com/YottaDB/YottaDB/issues/115), YottaDB reports correct ratios when the number of indirection cache hits exceeds 43 million. Previously, it could report a negative number. Note that ydb_dbglvl / gtmdgblvl is not part of the published and supported API whose stability we strive to maintain, and exists to assist YottaDB in supporting customers. (https://github.com/YottaDB/YottaDB/issues/77)
When asked to install GT.M using the gtm qualifier, the ydbinstall.sh script reports "GT.M" on a successful install. Previously, it reported "YottaDB" unconditionally, whether it installed YottaDB or GT.M. (https://github.com/YottaDB/YottaDB/issues/99)
For "out of the box" use of YottaDB, ydb_env_set is a file you can source with a POSIX or compatible shell to configure an environment with a default structure and required environment variables, creating a default environment if one does not exist. At this time, support has not been implemented in YottaDB for all ydb_ prefixed environment varables, but each release will increase that set. So as to not require changes as future YottaDB releases add YottaDB counterparts to GT.M environment variables, sourcing ydb_env_set sets both sets of environment variables to appropriate values, which are usually, but not always, the same. Sourcing ydb_env_unset unsets the above environment variables, unsets the aliases, and removes any occurrence of $ydb_dist in $LD_LIBRARY_PATH. For more information, see Issue (https://github.com/YottaDB/YottaDB/issues/126)
Installing YottaDB with UTF8 support builds $gtm_dist/utf8/libyottadbutil.so (previously named libgtmutil.so) on the Linux/ARM platform. In r1.10, libgtmutil.so was built only in the $gtm_dist (non-utf8) directory. (https://github.com/YottaDB/YottaDB/issues/143)
When installing YottaDB, gtm is created as a symbolic link to ydb, and gtmprofile is a symbolic link to ydb_env_set. The default names for global directory, database files, and journal files are changed, but if current files exist, their environment setting is done with an M program rather than with shell commands. (https://github.com/YottaDB/YottaDB/pull/160)
CALLINTCOMMIT, TCOMMIT at call-in-level=xxxx not allowed as corresponding TSTART was done at lower call-in-level=yyyy.
Run Time Error: This indicates that at least one call-in invocation happened in between when the TP transaction started (either through a ydb_tp_s() call in C or a TSTART command in M) and when the corresponding transaction commit is attempted (through a TCOMMIT command in M).
Action: If a TP transaction is started using SimpleAPI, and the user function driven by ydb_tp_s() does a call-in invocation, care should be taken to ensure the call-in code does not do a TCOMMIT.
CALLINTROLLBACK, TROLLBACK at call-in-level=xxxx not allowed as corresponding TSTART was done at lower call-in-level=yyyy
Run Time Error: This indicates that at least one call-in invocation happened in between when the TP transaction started (either through a ydb_tp_s() call in C or a TSTART command in M) and when the corresponding transaction rollback is attempted (through a TROLLBACK command in M).
Action: If a TP transaction is started using SimpleAPI, and the user function driven by ydb_tp_s() does a call-in invocation, care should be taken to ensure the call-in code does not do a TROLLBACK.
Run Time Error: This indicates that there was a fatal error in a SimpleAPI call that resulted in the termination of the running process, and no core file was generated as a result of this. Appears in the system log.
Action: Look up the error indicated in the secondary message text in the documentation to correct the cause of the fatal error.
INSUFFSUBS, Return subscript array for an API call too small.
Run Time Error: This indicates that the return subscript array needs more entries for the ydb_node_next_s() or ydb_node_previous_s() SimpleAPI call than is currently allocated (specified by the input/output parameter *ret_subs_used). In this case *ret_subs_used is set to the needed entries.
Action: Ensure the return subscript array ("ret_subsarray" parameter of ydb_node_next_s() or ydb_node_previous_s()) is allocated with at least *ret_subs_used entries and retry the ydb_node_next_s() or ydb_node_previous_s() call.
INVNAMECOUNT, Number of varnames (namecount parameter in a rrrr call) cannot be less than zero.
Runtime Error: This indicates that the number of variable names specified in a SimpleAPI call (identified in the message text) is less than zero.
Action: Redo the SimpleAPI call with a number of variable names that is greater than or equal to zero.
INVVARNAME, Invalid local/global/ISV variable name supplied to API call.
Run Time Error: This indicates that a SimpleAPI call received an invalid variable name. The invalidity can be one of the following types:
a) The ydb_buffer_t structure corresponding to the variable name has a "len_used" field greater than "alloc_len" OR
b) The ydb_buffer_t structure corresponding to the variable name has a zero value of "len_used" OR
c) The ydb_buffer_t structure corresponding to the variable name has a non-zero value of "len_used" but a NULL value of "buf_addr" OR
d) The variable name starts with a ^ (i.e. is a global variable name), but the second character is not a % or an alpha character (lower or upper case) or at least one of the following characters is not an alphanumeric character (lower or upper case alphabet or a decimal digit) OR
e) The variable name starts with a $ (i.e. is an intrinsic special variable name), but is not followed by any other character (i.e. "len_used" has a value of 1) OR
f) The variable name starts with a character other than a % or an alpha character (lower or upper case) OR
g) The variable name starts with a % or alpha character (lower or upper case) but at least one of the following characters is not an alphanumeric character (lower or upper case alphabet or a decimal digit)
Action: Determine which of the described failures scenarios is the issue and accordingly fix the variable name passed in to the SimpleAPI call
LIBYOTTAMISMTCH, $ydb_dist/libyottadb.so does not match the shared library path.
Runtime Error: This indicates that the full path of the currently running libyottadb.so shared library does not match the path described by $ydb_dist. This is possible for example if a C program tries to directly invoke a base image function (e.g. gtm_main, dse_main, mupip_main etc.) for more than one build/release of YottaDB in the same process.
Action: Make sure a C program invokes a base image function of only one libyottadb.so executable.
MINNRSUBSCRIPTS, Number of subscripts cannot be a negative number.
Run Time Error: This indicates that the number of subscripts in an input array (usually the "subs_used" parameter in various SimpleAPI calls) is a negative number.
Action: Redo the SimpleAPI call with a subscript count that is greater than or equal to zero.
MIXIMAGE, Cannot load more than one base image function on a process.
Run Time Error: This indicates that a C function tries to invoke more than one base image function included in libyottadb.so (e.g. gtm_main, dse_main, mupip_main etc.). Only one base image function can be invoked and only once for the lifetime of the process.
Action: Make sure only one base image function is invoked for the lifetime of one process.
NAMECOUNT2HI, Number of varnames specified (namecount parameter in a rrrr call) exceeds maximum cccc allowed.
Runtime Error: This indicates that the number of variable names specified in a SimpleAPI call (identified in the message text) exceeds the maximum number of allowed variable names (also identified in the message text).
Action: Redo the SimpleAPI call with a fewer number of variable names specified.
PARAMINVALID, Invalid parameter dddd specified in an API (rrrr) call.
Run Time Error: This indicates that a parameter in a SimpleAPI call was not properly specified. The function name (e.g. ydb_set_s()) and the name of the invalid parameter (e.g. subsarray) along with the type of the invalidity is identified in the error message text. If the parameter is an array, the index of the element where the invalidity is detected is also identified. If the parameter is an input parameter of type ydb_buffer_t it is invalid if "len_used" is greater than "alloc_len" OR if it has a "len_used value of 0 but a NULL value of "buf_addr". If the parameter is an output parameter, it is invalid if the ydb_buffer_t pointer is NULL or if the "buf_addr" field in the ydb_buffer_t structure is NULL. Note that no error checks are done if an input ydb_buffer_t typed pointer parameter is NULL (the process would get a SIG-11 and dump core in that case).
Action: Fix the cause of the invalidity and pass in a valid parameter to the SimpleAPI call.
QUERY2, Invalid second argument to $QUERY. Must be -1 or 1.
Run Time Error: This indicates that there is an invalid second argument passed to the function $QUERY. It must be either -1 or 1.
Action: Refer to $QUERY in the Programmer's Guide <https://docs.yottadb.com/ProgrammersGuide/functions.html#query>_ for correct usage.
READONLYLKFAIL, Failed to get a lock on READ_ONLY database file.
Run Time Error: This error is issued by a MUPIP command that requires standalone access (e.g. MUPIP SET -NOREAD_ONLY) to a database file (which has Read-only mode turned on) if other processes are still accessing the database OR by any process that tries to open a database file (which again has Read-only mode turned on) while a MUPIP command that has standalone access on the same database file is concurrently running.
Action: If the error is from the MUPIP command which requires standalone access, ensure all processes which have the database file open are shut down and reattempt the command. If the error is from a process trying to open the database file, wait for the concurrent MUPIP command requiring standalone access to finish and reattempt to open the database.
READONLYNOSTATS, Read-only and Statistics sharing cannot both be enabled on database.
Run Time Error: This error is issued if if one tries to enable the Read-only mode on a database that has Statistics sharing turned on OR if one tries to enable Statistics sharing on a database that has Read-only mode turned on OR if one tries to enable both at the same time.
Action: Make sure at most one of Read-only or Statistics sharing is turned on in the database at any point in time.
SIMPLEAPINEST, Attempt to nest a SimpleAPI call (rrrr) with another SimpleAPI call (RRRR) - - nesting calls is not permitted in simpleAPI.
Run Time Error: This indicates that a SimpleAPI call (function name identified in the message text) was attempted while another SimpleAPI call (whose function name is also identified in the message text) is still running (possible for example through a call-in or trigger invocation). Nesting of such SimpleAPI calls is not currently permitted.
Action: Avoid nesting SimpleAPI calls. Finish one SimpleAPI call before attempting another.
SUBSARRAYNULL, Non-zero number of subscripts xxxx specified but subscript array parameter is NULL in API call.
Run Time Error: This indicates that the value of the subscript array parameter is NULL, meaning there are no subscripts specified, but the parameter specifying the number of subscripts (usually the "subs_used" parameter) has a non-zero value.
Action: Redo the SimpleAPI call with a non-NULL subscript array parameter or with a zero value for the parameter specifying the number of subscripts.
TIME2LONG, Specified time value exceeds supported maximum limit xxxx allowed.
Run Time Error: This indicates that a timer value specified in a SimpleAPI call (e.g. ydb_lock_s(), ydb_lock_incr_s() etc.) exceeded the maximum allowed limit. Both the specified time value and the maximum allowed limit are indicated in the message text.
Action: Specify a time value below the maximum limit and retry the SimpleAPI call.
VARNAME2LONG, Variable name length exceeds maximum allowed length xxxx.
Run Time Error: This indicates that the length of a variable name specified in a SimpleAPI call exceeded the maximum limit. The maximum value is identified in the message text.
Action: Specify the variable name within the maximum length limit and retry the SimpleAPI call.
DBFREEZEOFF, Region rrrr is UNFROZEN ([NO]OVERRIDE [NO]AUTOREL)
Operator log/MUPIP Information: The database region rrrr is no longer frozen, most likely due to a MUPIP FREEZE -OFF, with the selected options. [NO]AUTOREL indicates whether an autorelease of the region occurred prior to the MUPIP FREEZE -OFF command.
Action: Confirm that this was the desired action.
DBFREEZEON, Region rrrr is FROZEN ([NO]OVERRIDE [NO]ONLINE [NO]AUTOREL)
Operator log/MUPIP Information: The database region rrrr is frozen, most likely due to a MUPIP FREEZE -ON, with the reported options.
Action: Confirm that this was the desired action.
DBNONUMSUBS, XXXX Key contains a numeric form of subscript in a global defined to collate all subscripts as strings
Run Time/MUPIP Error: The record has a numeric subscript but the collation setting for the global or region indicates all subscripts are filed as strings. The leading context (XXXX) identifies the block and offest of the problematic record. This can arise if an operator uses DSE to force a change to a collation setting or to modify a key when the global already has content.
Action: If you can determine the cause of, and reason for, the change and you may choose to reverse it. If you need to change the collation, the appropriate procedure is to EXTRACT the data, KILL the global, or remove and recreate the database file, and them LOAD the extracted data.
DBNULCOL, XXXX NULL collation representation differs from the database file header setting
DSE/MUPIP/Run Time Error: This indicates the database contains a record with an empty subscript ("Null" subscript) representation that is incompatible with the current setting database file header setting for such a representation. The leading context (XXXX) specifies the block number and offset of the problematic record. This can only arise if someone changes the setting for the database while it contains one or more such subscripts. YottaDB recommends against making such a change. This message can originate from MUPIP INTEG, DSE INTEG or from running with VIEW "GDSCERT"
Action: Use the record and block information to remove the problematic record with DSE and restore the data appropriately, typically with a SET command. Note that the record and block of the record many change due to ongoing updates, so this operation requires great care and familiarity with DSE.
GBLOFLOW, Database segment is full
Run Time/MUPIP Error: This indicates that an error was encountered while extending the database file.
Action: Examine the accompanying message(s) for the cause of the error. If the error is due to insufficient authorization, address that. If the error is due to TOTALBLKMAX (refer to the explaination of that message) or a lack of enough free space on the disk to fit the size of a database file, try performing a KILL of some nodes in the database to get free blocks in the existing allocated space (you may need to KILL several subscripted nodes before you can KILL a name node).
LSINSERTED, Line YYYY, source module XXXX exceeds maximum source line length; line seperator inserted, terminating scope of any prior IF, ELSE, or FOR.
Compile Time Warning: Indicates that source XXXX line YYYY exceeded the maximum line length and YottaDB separated it into multiple lines to allow continued parsing. Internally, YottaDB represents the generated code as N lines for this source line, where N is the number of segments extracted from this source line. Be aware that as a result of this, source lines containing a command whose scope is rest of the line (IF, ELSE, FOR), are now split into multiple lines, each with a separate scope.
Action: Consider refactoring code to avoid source line lengths in excess of 8192 characters.
MUTEXFRCDTERM, Mutual Exclusion subsystem detected forced termination of process pppp. Crit salvaged from database file dddd.
Run Time Warning: This indicates that YottaDB confirmed inappropriate termination of the process pppp, while holding crit on database file dddd.
Action: Determine the cause of the termination and take appropriate action.
NULSUBSC, XXXX Null subscripts are not allowed for current region
Run Time/MUPIP Error: This indicates that a global variable specified a null subscript in a database file which does not accept null subscripts. The leading context (XXXX) specifies more about the event or location of the issue
Action: Look for the source of the null subscript(s) and consider whether they are appropriate or due to a coding error. If they are appropriate, use MUPIP SET -NULL_SUBSCRIPTS, and remember to make the same adjustment with GDE CHANGE REGION -NULL_SUBSCRIPTS to ensure the next time you recreate a database that the characteristic persists.
READONLYNOBG, Read-only cannot be enabled on non-MM databases
MUPIP Error: This indicates an attempt to change a BG database to -READ_ONLY or to change a -READ_ONLY to MM access method; -READ_ONLY only compatible with the MM access mode.
Action: Verify whether the database should not be read only and adjust, if appropriate. Alternatively, set the database to MM access mode then mark it as read-only.
Run Time/MUPIP Error: This indicates that some errors were encountered while accessing the specified replication instance file defined by $gtm_repl_instance or the relevant global directory.
Action: Refer to the accompanying message(s) for additional information.
REPLINSTMISMTCH, Process has replication instance file ffff (jnlpool shmid = ssss) open but database dddd is bound to instance file gggg (jnlpool shmid =tttt)
Run Time Error: The process attempted an update on the replicated database dddd associated with the replication instance file ffff and journal pool shared memory id ssss; however, the process has already associated the database with a different replication instance file gggg or journal pool shmid tttt.
Action: A replicated database can only accept updates by processes that have the same replication instance file (defined by the environment variable gtm_repl_instance or in the global directory) open for that database. Ensure the same replication instance file is used for all processes that update the same replicated database file. This error can also occur if the replication instance file was recreated (while processes were still accessing the replication instance). In this case, the name ffff and gggg would be the same but the corresponding journal pool shared memory ids would be different. To recover from this situation, shut down all processes accessing the instance from before and after the instance file recreate. Run an argumentless MUPIP RUNDOWN to clean up the older journal pool tttt and restart the instance. The Source Server (which is the first process to start on a replicated instance) only binds replicated databases from its global directory to the journal pool that it creates. No other replicated database file can be bound with this journal pool.
REPLMULTINSTUPDATE, Previous updates in the current transaction are to xxxx so updates to yyyy (in rrrr) not allowed
Run Time Error: Previous updates in the current TP transaction mapped to database files associated with replication instance file xxxx, so it cannot make updates to database file yyyy which is associated with replication instance file rrrr.
Action: Modify the application so all updates in a TP transaction to replicated regions are associated with a single replication instance.
STACKCRIT, Stack space critical
Run Time Error: This indicates that the process has consumed almost all of the available stack space.
Action: Look for infinite recursion. If you do not take immediate action to reduce your stack, YottaDB is likely to produce a STACKOFLOW error, which terminates the process. Examine the stack with ZSHOW. Trim the stack using QUIT, ZGOTO, HALT or ZHALT.
STACKOFLOW, Stack overflow
Run Time Fatal: This indicates that the process required more stack space than was available in memory.
Action: Reduce the stack when you get a STACKCRIT error. This error terminates the process.
STPCRIT, String pool space critical
Run Time Error: This indicates that the process has exceeded the heap (string pool) limit specified in the $ZSTRPLLIM ISV. If you do not take prompt action to reduce the process memory requirements, at the next heap expansion, YottaDB produces an STPOFLOW error, which terminates the process.
Action: Investigate whether the process memory usage is appropriate, and if so, increase or remove the limit. Otherwise correct the cause(s) of the excessive memory consumption.
STPOFLOW, String pool space overflow
Run Time Fatal: This indicates that the process has previously exceeded the heap (string pool) limit specified in the $ZSTRPLLIM ISV and still needs more memory, so YottaDB terminates the process.
Action: Investigate whether the process memory usage is appropriate, and if so, increase or remove the limit. Otherwise correct the cause(s) of the excessive memory consumption.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts and no Back-Cover Texts.
YottaDB™ is a trademark of YottaDB LLC.
GT.M™ is a trademark of Fidelity National Information Services, Inc.
Other trademarks belong to their respective owners.