Tags give the ability to mark specific points in history as being important
  • V6.3-007
    7a1d2b3e · GT.M V6.3-007 ·
  • V6.3-006
    74ea4a3c · GT.M V6.3-006 ·
  • r1.24

    YottaDB r1.24

    Binary Distributions

    sha256sum file
    7e405a94e0be03ac24be5d6c2741f0195414c875b0a72fe8c6fdfb6d9693b375 yottadb_r124_linux_aarch64_pro.tgz
    e01dd5cebe5c407d0f32419eab08429765f653df24e7a2b857485d386abaed54 yottadb_r124_linux_armv6l_pro.tgz
    01c6f70216a5e07df0cba611c5d549c6caefc13fec43e481d8efe7a4c4679731 yottadb_r124_linux_armv7l_pro.tgz
    4010f898fc190dce8e3fe3b73e6e26b76461dd8352c372cc22731d85b0d6c943 yottadb_r124_linux_x8664_pro.tgz
    8e125474aed4b1aa0e0a66c527ad5f558da48353bd4b2b82bfd29e58fe1d26dd yottadb_r124_rhel7_x8664_pro.tgz

    Release Note Revision History

    Revision Date Summary
    1.01 February 6, 2019 Added additional error message information
    1.00 January 31, 2019 r1.24 Initial Release

    Contact Information

    YottaDB LLC

    40 Lloyd Avenue, Suite 104
    Malvern, PA 19355, USA
    info@yottadb.com
    +1 (610) 644-1898

    Support

    Customers

    Contact your YottaDB support channel.

    Others

    For free (to you) support from members of communities who run widely available applications on YottaDB, please use an application-specific list where appropriate.

    r1.24

    Overview

    r1.24 is a major release that brings much new functionality to YottaDB.

    pkg-config is a standard tool on Linux systems for managing package versions, for example, to query the location and latest installed version of a package. YottaDB is now part of this ecosystem: the ydbinstall script creates a pkg-config file for YottaDB at /usr/share/pkgconfig/yottadb.pc. In turn, this means that an application can write a script to use YottaDB without the script needing to be updated when a new YottaDB release is installed on a system, or if a YottaDB release is installed in different directories on different systems, e.g.

    source $(pkg-config --variable=prefix yottadb)/ydb_env_set # setup environment
    gcc -I $ydb_dist -L $ydb_dist -o myprog myprog.c -lyottadb
    ./myprog

    or

    source $(pkg-config --variable=prefix yottadb)/ydb_env_set # setup environment
    mumps -run mypro

    Fitting into the standard ecosystem becomes increasingly important as we release YottaDB wrappers providing standard APIs for a variety of languages starting with Go.

    Released as field test grade functionality are Simple API functions that support multi-threaded applications. Although the YottaDB engine is itself single-threaded, it supports multi-threaded applications as described in our blog post YottaDB Support for Multi-threaded Applications and in the Simple API section of the Multi-Language Programmers Guide. An API with support for threads allows YottaDB to create wrappers for inherently multi-threaded language implementations such as Go, as described in the Programming in Go section of the Multi-Language Programmers Guide. Note that r1.24 is otherwise considered a production release. This means that we consider YottaDB r1.24 to be suitable for use in production except for functionality to support multi-thread applications which are suitable for use in development and testing, but not in production. In the next release, if not sooner, we intend for that functionality to be suitable for production use, like the rest of YottaDB.

    64-bit ARM (aarch64) is a supported CPU architecture, running Ubuntu 18.04 LTS, tested on Raspberry Pi 3. If you need another distribution of Linux to be Supported, or testing on another hardware implementation of the architecture, please contact us. YottaDB thanks community member Steve Johnson for contributing the port.

    r1.24 comes with numerous & noteworthy functional & performance enhancements, fixes (including fixes to issues in the upstream GT.M code base), as described below with full details on Gitlab.

    YottadB r1.24 is upward compatible with both YottaDB r1.22 and GT.M V6.3-005.

    Platforms

    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.

    CPU Architecture Supported OS Version(s) Notes
    64-bit x86 Ubuntu 18.04 LTS; Red Hat Enterprise Linux 7.6 There are separate binary distributions for Ubuntu and Red Hat, owing to differences in library versions of those distributions.
    64-bit ARM (Raspberry Pi 3 Model B) Ubuntu 18.04 LTS While YottaDB is Supportable on other ARMv8-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 info@yottadb.com if you want a specific combination of OS and CPU microarchitecture to be Supported.
    32-bit ARM (Raspberry Pi 3 Model B; BeagleBone Black Wireless) Raspbian GNU/Linux 9.1; Stretch IoT (non GUI) While YottaDB r1.24 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 info@yottadb.com if you want a specific combination of OS and CPU microarchitecture to be Supported.
    32-bit ARM (Raspberry Pi Zero) Raspbian GNU/Linux 9.1 While YottaDB r1.24 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 info@yottadb.com 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. Specific notes:

    • On Ubuntu releases after 18.04 LTS, YottaDB needs the libtinfo5 package to be installed.
    • On Arch Linux and possibly other leading edge distributions, YottaDB may need to be recompiled from source code owing to library and tool chain versions significantly more recent than those used in building the distribution.

    Installation

    See our Get Started page to use YottaDB.

    We strongly recommend that you install YottaDB r1.24 in a newly created directory, different from those of YottaDB r1.22 and any GT.M versions you may have installed on the system.

    Removing an installed YottaDB release

    Assuming $ydb_dist points to the directory where YottaDB is installed:

    • Cleanly shut down all application processes using that release.
    • Execute mupip rundown && mupip rundown -relinkctl.
    • Ensure that there are no gtcm* or gtmsecshr processes active.
    • Use sudo lsof | grep $ydb_dist to ensure there are no open files.
    • Delete the directory with sudo rm -rf $ydb_dist.

    Upgrading to YottaDB r1.24

    As YottaDB r1.24 is upward compatible from both YottaDB r1.22 and GT.M V6.3-005, the minimal upgrade steps are:

    • Install YottaDB r1.24.
    • Recompile any object code, and recreate shared libraries where appropriate.
    • If you are using encryption, compile and install the reference implementation plugin or your customized plugin.
    • Cleanly shut down the application and ensure that the database files are shut down using mupip rundown from the prior release.
    • Switch journal files with the new YottaDB release.
    • Start using the new YottaDB release.

    To upgrade from older GT.M releases, first upgrade to GT.M V6.0-000 or later and follow the steps above, or contact your YottaDB support channel for assistance and guidance.

    A more sophisticated upgrade technique is:

    • Install YottaDB r1.24.
    • Create a new replicated instance of your application (on the same system or a different system).
    • Assuming the existing instance is A, and the new instance is B, upgrade B to r1.24 and start replicating from A to B.
    • Once B catches up, switchover so that B is in a primary role replicating to A.
    • Once you are satisfied with B, remove (or upgrade) A.

    Change History

    r1.24

    YottaDB r1.24 includes the following changes from YottaDB r1.22.

    ID Category Summary
    (#95) DB MUPIP LOAD reports 0 records loaded on an empty ZWR or GO format extract file
    (#96) DB AIMG records include DSE CHANGE command effecting the change
    (#113) Admin ydb_lct_stdnull environment variable
    (#114) Admin GDE defaults to standard null collation
    (#183) Language ydb_incr_s() accepts NULL ret_value parameter
    (#191) DB Force access through GNP server even when client and server are on the same host
    (#230) Language $ZSEARCH() context of -1 is always new
    (#253) Language Attempting to update a database mapped through multiple global directories and for which a process does not have write access issues a DBPRIVERR
    (#255) Admin ydbinstall script checks for Supported or known Supportable platform and issues a warning otherwise
    (#264) Other Source Server issues FILTERNOTALIVE when external filter program terminates abnormally
    (#267) Language MUPIP BACKUP issues a FILENAMETOOLONG error when the absolute path length of the target backup filename is too long
    (#272) Admin MUMPS, DSE, LKE, MUPIP BACKUP etc. honor the ydb_poollimit environment variable
    (#275) Other LISTENING sockets can be passed between processes
    (#277) Language $$set^%PATCODE works in UTF-8 mode
    (#280) Other WRITE /WAIT on a SOCKET device with no sockets returns immediately
    (#282) DB Source Server clears as much backlog as possible when reading from journal files of instance frozen because of errors in journal file switching
    (#284) DB MUPIP JOURNAL -EXTRACT on concurrently updated journal file works
    (#290) DB During MUPIP FREEZE -ONLINE, exiting YottaDB processes detach from database files without hanging
    (#293) Admin SET $ZGBLDIR inside a Update Process trigger correctly switches global directory
    (#295) Language ZSTEP inside trigger ignored completely if TRIGGER_MOD restriction is in place
    (#297) DB LOCK commands work correctly in a rare case of multiple hash collisions
    (#309) Admin ydb_env_set leaves gtm_prompt untouched
    (#310) Other DEVOPENFAIL messages in the syslog correctly identify the device name and system error number in case of errors during OPEN of a PIPE device
    (#312) DB Fixes to issues affecting processes part of multiple replication instances
    (#313) DB MUPIP FTOK -JNLPOOL and -RECVPOOL recognize instance-file-name on command line
    (#315) Language ZCOMPILE omits warnings during compilation if $ZCOMPILE includes "-nowarning"
    (#318) Other Changes to ZSYSTEM_FILTER/PIPE_FILTER in restrict.txt accepted even when within one second
    (#321) Language Journal records fed to replication filters include timestamps
    (#324) Language Errors inside indirection usage while in the direct mode using $ETRAP return control to the direct mode prompt
    (#329) Language Compiling M program with literal optimization in UTF-8 mode works correctly
    (#333) Other $VIEW("PROBECRIT") CPT time resolution is nanoseconds
    (#338) Admin Improvements to the ydbinstall.sh script
    (#341) DB Journal updates separated in time by more than an epoch interval guaranteed to have an EPOCH journal record between them
    (#344) Language Simple API calls subsequent to a ydb_zwr2str_s() call work correctly
    (#345) Other OPEN of a PIPE device with the STDERR deviceparameter set to the name of an already-open device issues a STDERRALREADYOPEN error
    (#346) Other Certain cases of invalid collation specification in directory tree records handled correctly
    (#347) Admin ydbinstall.sh checks at startup for all utilities it needs
    (#348) DB OPEN of SOCKET device previously closed after TPTIMEOUT works correctly
    (#349) DB MUPIP REORG on a database file with non-zero RESERVED_BYTES retains structural integrity of file
    (#350) Admin Change terminal characteristics only during READ or Direct Mode
    (#351) Language API for Multi-threaded applications to use the single-threaded YottaDB engine
    (#352) Other Unhandled error from C to M call-in is returned to caller after Simple API call that sets a spanning node
    (#353) Language $INCREMENT() supported for a global that has NOISOLATION turned on
    (#354) Language $ZSTATUS reports correct actual and maximum string length following ERR_INVSTRLEN return from Simple API call
    (#356) Language Extended global reference correctly reports NETDBOPNERR error when $zgbldir / $ydb_gbldir not set
    (#357) Admin SIGINT/SIGQUIT (kill -2 or kill -3) handled when sent to a mumps process waiting for spawned process to complete
    (#358) DB Avoid DBIOERR error in forked child process when using simpleAPI in database file using ASYNCIO
    (#360) Language $ZEDITOR reflects exit status of the last ZEDIT
    (#361) Other Avoid SI replication REPLINSTNOHIST after Receiver Server shutdown before any data is replicated
    (#362) DB Ensure logical consistency between primary and secondary instances after a switchover following kill -9 of processes on secondary
    (#363) Language Issue NUMOFLOW for overlarge numeric expressions encountered during literal optimization
    (#364) DB For a frozen instance Source Server shutdown reports whether or not it deleted the Journal Pool ipcs
    (#365) DB Use prior journal type in MUPIP SET JOURNAL; default depending on access method
    (#369) Admin VIEW "SETENV" and VIEW "UNSETENV" commands to set and unset environment variables in M
    (#371) Language $SELECT() stops evaluating tvexprs or exprs after the first true tvexpr is found
    (#372) Language Report syntax error for SET command where first setleft is an invalid ISV and later setleft uses indirection
    (#374) Language Ensure $TEXT() strips line terminators for object code compiled with -EMBED_SOURCE flag
    (#375) Other Drop support for SSL 2.0, SSL 3.0 and TLS1.0 in the reference TLS implementation shipped with YottaDB
    (#376) Other Support TLS 1.3 in the reference TLS implementation that ships with the encryption plugin
    (#383) Language ydb_tp_s() returns negative GBLOFLOW error code
    (#385) Admin Recompile .m file if .o has same timestamp
    (#392) Admin Environment variables ydb_linktmpdir/gtm_linktmpdir default to ydb_tmp/gtm_tmp
    (#393) Admin YDB_RELEASE in libyottadb.h specifies YottaDB release
    (#394) Language ydb_subscript_next_s() for nonexistent local returns next subscript "0"
    (#395) Admin /tmp/yottadb/$ydb_ver has read-write-execute permissions for all users permitted to run YottaDB
    (#396) Language ydb_node_next_s() and ydb_node_previous_s() report PARMINVALID when output ydb_buffer_t structure has NULL buf_addr
    (#397) Admin Access through SimpleAPI issues ZGBLDIRACC if ydb_app_ensures_isolation is set to a non-null value but global directory does not exist
    (#401) Language Correct behavior when a call-in invokes an external call that uses Simple API
    (#402) Language gtm_init(), gtm_ci() and gtm_cip() entry points for backward compatibility with GT.M

    Database

    • MUPIP LOAD reports 0 records loaded on an empty ZWR or GO format extract file. Previously, it reported MAXSTRLEN and LDBINFMT errors. [#95]

    • AIMG records (After-Images of database blocks) reported by MUPIP JOURNAL -EXTRACT -DETAIL include the DSE CHANGE command that caused the block state to change. Previously they did not. [#96]

    • GDE CHANGE -SEGMENT -FILE and GDE ADD -SEGMENT -FILE accept a database file name specification of the form @: where is the local host name or a remote host name where the GT.CM GNP server runs. Any database access to such a region/segment by a client process now goes through the GNP server even if is the current host. The : syntax where a database access goes through a GNP server only if is not the current host remains supported. The optional "@" prefix allows a client to force every database access to go through a GNP server, thereby allowing client processes running different releases of YottaDB to access a database file. [#191]

    • When an instance is frozen due to an error switching journal files (for example, file system permissions) a Source Server clears the backlog as much as possible and then waits for the instance freeze to clear. Previously, the Source Server could terminate with a FILEDELFAIL or RENAMEFAIL. [#282]

    • MUPIP JOURNAL -EXTRACT on a journal file that is being concurrently updated creates an extract file reflecting the state of the journal file when the command started. Previously, the extract command could terminate abnormally with JNLBADRECFMT, JNLUNXPCTERR, and, rarely, GTMASSERT2 errors, sometimes with a core file. [#284]

    • When a MUPIP FREEZE -ONLINE is active, exiting YottaDB processes detach from database files without hanging. Previously, they could hang. [#290]

    • LOCK commands work correctly when more than 31 subscripts at a given lock name subscript level (across all processes concurrently using a particular database region) hash to the same value. $$^%PEEKBYNAME("sgmnt_data.lock_hash_bucket_full_cntr",<region>) now returns the number of times such a rare event was seen (and handled correctly) in . Previously, effective YottaDB r1.20, it was possible for LOCK commands in this rare case to spin and incorrectly seize ownership of the lock resource from a concurrently holding process. [#297]

    • Database file updates to a process that is part of multiple replication instances works correctly in several cases. Previously it was possible for the process to incorrectly

      • issue REPLINSTMISMTCH errors;
      • terminate with a fatal GTMASSERT2 error;
      • terminate with a fatal KILLBYSIGSINFO1/SIGMAPERR/SIG-11 error;
      • freeze the wrong instance;
      • cause a memory leak when using PEEKBYNAME on the Journal Pool; or
      • attach to a Journal Pool even though no update was attempted on a corresponding database file.

      [#312]

    • MUPIP FTOK -JNLPOOL and MUPIP FTOK -RECVPOOL operate on the specified instance-file-name. Previously they ignored the input instance-file-name and always operated on the instance file name specified by the ydb_repl_instance or gtm_repl_instance environment variable. [#313]

    • Two updates to the journal file are separated by n seconds where n is greater than the epoch_interval for that region, then are guaranteed to have at least at least one intervening EPOCH record in the journal file. Previously, this setting was not honored in some cases (e.g. when an idle/free epoch was written) resulting in delaying the EPOCH record by as much as 6 seconds. [#341]

    • OPEN of a SOCKET device that was previously closed after a TPTIMEOUT error while in a READ command works correctly. Previously this would abnormally terminate the process with a GTMASSERT2 fatal error. [#348]

    • MUPIP REORG on a database file with non-zero RESERVED_BYTES retains the integrity of the database file. Previously, it was possible for cause a structurally damaged database file (for example DBINVGBL integrity error). [#349]

    • A child process forked from a parent using the Simple API to update a database file that has ASYNCIO turned on can successfully update that database file. Previously, such a child process raised a DBIOERR. [#358]

    • MUPIP JOURNAL -ROLLBACK -BACKWARD -FETCHRESYNC keeps user data in sync between primary and secondary sides of a replication connection when processes on the secondary are terminated with kill -9 followed by a switchover. Previously, this could cause primary and secondary database instances to have different content. Note that YottaDB strongly recommends against use of kill -9. [#362]

    • MUPIP REPLICATE -SOURCE -SHUTDOWN reports whether or not it deleted the Journal Pool shared memory and semaphores even if the instance is frozen. Previously, it reported this information only if the instance was not frozen. [#364]

    • The -[NO]BEFORE_IMAGES option of the MUPIP SET JOURNAL command is optional. If neither option is specified and journaling is currently disabled in the database file header (i.e. DSE DUMP -FILEHEADER lists "Journal State" as "DISABLED"), MUPIP SET -JOURNAL defaults to BEFORE_IMAGES for databases with the BG access method, and to NOBEFORE_IMAGES for databases with the MM access method. If neither option is specified and journaling is not disabled in the database file header (i.e. "Journal State" is not "DISABLED"), the prior journal type from the database file header is used for the new journal file. Previously, one of BEFORE_IMAGES or NOBEFORE_IMAGES option was required. [#365]

    Language

    • ydb_incr_s() accepts a NULL ret_value parameter, slightly simplifying application programs and marginally improving performance for applications that need to increment a node, but do not need to use the value. [#183]

    • A value of -1 as the optional intexpr second parameter of $ZSEARCH() always returns the first file name matched by the pattern searched for, i.e., it does not use a stream. Previously, a value of -1 returned a ZSRCHSTRMCT error. [#230]

    • Attempting to update a database file for which a process does not have write access, and which is mapped through multiple global directories issues a DBPRIVERR error. In prior versions, such an attempted update would abnormally terminate the process with a KILLBYSIGINFO1 error (SIG-11). [#253]

    • MUPIP BACKUP issues a FILENAMETOOLONG error when the absolute path length of the target backup filename is too long (approximately 255 bytes). Previously, this resulted in an abnormal termination of the backup process with a KILLBYSIGSINFO1 fatal error (signal 6/SIGABRT). [#267]

    • $$set^%PATCODE loads user defined pattern tables in UTF-8 mode, returning 1 in case of a successful load. Previously it always failed in UTF-8 mode, returning 0. [#277]

    • When the TRIGGER_MOD restriction is in place, ZSTEP is completely ignored. Previously it would be executed on completion of the trigger code. [#295]

    • ZCOMPILE omits warnings during compilation if $ZCOMPILE includes -nowarning. Previously, the compilation incorrectly issued warnings even with this setting. Note that an application can set $ZCOMPILE directly or through the environment variables ydb_compile/gtmcompile. [#315]

    • Journal update records in MUPIP JOURNAL EXTRACT format fed to replication filters include time stamps. Previously the time stamps were zero. [#321]

    • Errors inside indirection usage (@ syntax) while in the direct mode using $ETRAP return control to the direct mode prompt after executing the $ETRAP error handler. Previously, such errors caused the mumps process to abruptly terminate. [#324]

    • Compiling M programs with $select() containing invalid $char() usages in UTF-8 mode correctly issues a INVDLRCVAL error. Previously, in some cases where the M line could be optimized (due to literal usage in the $CHAR() function which corresponded to an invalid codepoint), the compilation would abnormally terminate with a GTMASSERT2 fatal error. [#329]

    • Simple API calls subsequent to a ydb_zwr2str_s() call work. Previously, Simple API calls subsequent to a ydb_zwr2str_s() call would fail with a SIMPLEAPINEST error. [#344]

    • Even though the YottaDB data management engine is single-threaded, YottaDB has Simple API functions to support multi-threaded applications. An overview is in the blog post YottaDB Support for Multi-threaded Applications and details are in the Multi-Language Programmers Guide. [#351]

    • $INCREMENT() is supported for global variables that have NOISOLATION turned on. Previously this reported GVINCRISOLATION errors, albeit not consistently. Note that for variables that have NOISOLATION turned on YottaDB expects application logic to ensure Isolation within a transaction without requiring YottDB to do so. [#353]

    • $ZSTATUS reports the correct actual and maximum string length values in all cases following a YDB_ERR_INVSTRLEN error returned by a Simple API function call e.g. ydb_get_s(). Previously, $ZSTATUS could contain a 0 string length and max length value in the INVSTRLEN. [#354]

    • An extended reference correctly issues a NETDBOPNERR error if it points to a remote database file that cannot be opened (for example, the GNP server is not started on the remote host). Previously, if $zgbldir was not set (or the ydb_gbldir / gtmgbldir environment variables were not set), a similar extended reference would terminate with a KILLBYSIGSINFO1 fatal error (SIG-11). [#356]

    • $ZEDITOR reports the exit status of the last edit session invoked by a ZEDIT command. Previously, it reported 0 even if the editor invocation exited with a non-zero status. [#360]

    • YottaDB issues NUMOFLOW errors for literal expressions which contain large numeric values stored as strings. Previously, in some cases (e.g., 0!("1E47"*10))YottaDB would return potentially incorrect values rather than issue a NUMOFLOW error. [#363]

    • $SELECT stops evaluating tvexprs or exprs once a true tvexpr is encountered even if evaluating later tvexprs or exprs would result in a NUMOFLOW or INVDLRCVAL errors. Previously a NUMOFLOW or INVDLRCVAL runtime error would be incorrectly issued (e.g., if $select(1:1,1:1E47)). [#371]

    • Indirection in a setleft correctly generates a compilation error if it is preceded by a setleft which has an invalid ISV usage (e.g. set ($iv,@y(2))=1). Previously such a usage would cause process termination with a fatal GTMASSERT2 error during compilation. [#372]

    • $TEXT() returns source lines without line terminators. Previously, if a .m source file had line terminators and was compiled with the -EMBED_SOURCE compilation flag, $TEXT() returned source lines with line terminators in some cases and without them in others. [#374]

    • ydb_tp_s() returns a negative error code (YDB_ERR_GBLOFLOW) in case of a GBLOFLOW error. Previously it incorrectly returned the positive value of this error code (i.e. -YDB_ERR_GBLOFLOW). [#383]

    • ydb_subscript_next_s() and ydb_subscript_previous_s() for a nonexistent local variable return the null string (i.e. ret_value.len_used is 0) as the next subscript. Previously, it used to incorrectly return the next subscript as the string literal "0" (i.e. ret_value.len_used is 1). [#394]

    • ydb_node_next_s() and ydb_node_previous_s() report a PARAMINVALID error when a ydb_buffer_t structure passed via the *ret_subsarray parameter has a NULL buf_addr member. In this case, *ret_subs_used is the index into the *ret_subsarray array where the NULL buf_addr was encountered. Previously this usage caused the process to terminate with a fatal KILLBYSIGSINFO1 error (SIG-11). [#396]

    • Application code that calls in to M code (using ydb_ci() / ydb_cip()) which in turn calls out to code that in turn calls the Simple API works. Previously, such usage could result in errors and otherwise behave incorrectly. [#401]

    • Routines gtm_ci(), gtm_cip(), and gtm_init() are available for C code to call M code providing upward compatibility to allow non-M applications using FIS GT.M to run unchanged with YottaDB. Previously, while YottaDB provided upward compatibility for M applications, non-M applications had to replace the calls with ydb_ci(),ydb_cip(), and ydb_init() respectively. [#402]

    Other

    • The Source Server issues a FILTERNOTALIVE error in case an external filter (invoked with the -FILTER qualifier at process startup) terminates abnormally. Previously, the Source Server could loop indefinitely waiting for a response from the terminated filter process. [#264]

    • Sockets in LISTENING state can now be passed to other processes using a JOB command or the WRITE /PASS with WRITE /ACCEPT. Previously this used to hang. [#275]

    • WRITE /WAIT on a SOCKET device with no sockets returns immediately. Previously it would loop until the command timed out (indefinitely if there was no timeout). [#280]

    • DEVOPENFAIL messages in the syslog correctly identify the device name and system error number in case of errors during OPEN of a PIPE device. Previously, reported incorrect (garbage) device name and/or system error number/text in some cases. [#310]

    • With GT.M V6.3-005, one can specify M code to run a filter that decides whether to allow a restriction or not and to control what commands actually get run when a user specifies ZSYSTEM or a PIPE OPEN command (see GTM-8877 for details). While testing this feature out, we noticed that if the $ydb_dist/restrict.txt or $gtm_dist/restrict.txt file is updated multiple times within the same second, where the first update included one M labelref for ZSYSTEM_FILTER/PIPE_FILTER and the second update included a different M labelref, the second (and later) M labelref did not take effect when a ZSYSTEM or PIPE OPEN command ran afterwards. The first M labelref still took effect incorrectly. [#318]

    • $VIEW("PROBECRIT") CPT time resolution is nanoseconds. Previously, it was reported in nanoseconds, but it was a multiple of 1000, effectively making it microsecond resolution. [#333]

    • OPEN of a PIPE device with the STDERR deviceparameter set to the name of an already-open device issues a STDERRALREADYOPEN error. Previously such usages resulted in unexpected device state and behavior (e.g. unexpected errors). [#345]

    • When a directory tree record has an invalid collation specification (a structural error), MUPIP INTEG issues an INVSPECREC error with appropriate context (block number and offset where the error was noticed), while DSE and application programs assume no collation and proceed. Previously, in some cases of an INVSPECREC error, it was possible for all the above commands to loop for ever. [#346]

    • A C→M call-in that encounters an error which is not handled by the error trap handler ($ETRAP or $ZTRAP) returns the error code back to the calling C code. Previously, in this situation, the process could terminate with a GTMASSERT2 fatal error if the call-in was preceded by a ydb_set_s() Simple API call that set a node in the database spanning more than one database block. [#352]

    • A Receiver Server on a Supplementary Instance starts replicating after a prior Receiver Server was shutdown after it connected to a Source Server for the first time but before it actually received any data. Previously, a receiver startup in this case could incorrectly terminate with a REPLINSTNOHIST error. [#361]

    • The encryption plugin shipped with YottaDB, which uses OpenSSL for TLS for replication and SOCKET devices) does not support SSL 2.0, SSL 3.0 and TLS 1.0 as these are vulnerable to cryptographic attacks (e.g., POODLE). The plugin continues to support the TLS 1.1 and TLS 1.2 protocols. [#375]

    • The reference implementation of the encryption plugin supports TLS 1.3 (which in turn is supported by OpenSSL 1.1.1). [#376]

    System Administration

    • If the environment variable ydb_lct_stdnull environment variable has the value 1, YottaDB uses standard collation for empty string (null) subscripts of local variables, i.e., the empty string collates first, before all numeric values. If set to 0, YottaDB uses the legacy collation, where the empty string collates between numeric and non-empty string subscripts. If the environment variable is not set, YottaDB uses the gtm_lct_stdnull environment variable, and if neither is set, YottaDB uses standard collation. Previously, the ydb_lct_stdnull environment variable was not recognized, and the default of legacy collation (which is not used by any application we know of) was an opportunity for an application to have an obscure, hard to troubleshoot, bug. YottaDB strongly recommends against use of legacy collation. [#113]

    • The default value for the GDE region parameter STDNULLCOLL is STDNULLCOLL. Previously it was NOSTDNULLCOLL. As we are aware of no application that uses empty string (null) subscripts and NOSTDNULLCOLL, changing the default is an opportunity to keep an application from having obscure, hard-to-troubleshoot bugs as a consequence of inadvertently using NOSTDNULLCOLL. Note that YottaDB strongly recommends against use of legacy collation. (#114 (closed))

    • The ydbinstall script checks for existence and contents of /etc/os-release, and aborts the install of YottaDB if it detects an unsupported platform. Rerunning it with --force-install overrides this behavior and goes ahead with the install even if it is an unsupported platform. [#255]

    • MUMPS, DSE, LKE, MUPIP BACKUP etc. honor the ydb_poollimit environment variable and set the poollimit value at process startup. Previously only MUPIP REORG honored this environment variable. In MUMPS, VIEW "POOLLIMIT" continues to be honored and overrides the poollimit setting initially set from the environment variable. [#272]

    • The Update Process operates correctly when a trigger executes a SET $ZGBLDIR to switch the current global directory. Previously it switched the global directory correctly the first time the trigger was invoked but later invocations of the trigger did not switch the global directory resulting in any updates in the trigger code unintentionally happening in the primary global directory with which the Update process was started. A workaround in prior versions was to do a NEW $ZGBLDIR before the SET $ZGBLDIR in the trigger code. [#293]

    • When sourced, the ydb_env_set file does not clear the value of the environment variable gtm_prompt. Previously it did. The workaround was to use the ydb_prompt environment variable. As the gtm_prompt environment variable is deprecated, YottaDB recommends using ydb_prompt except in cases where compatibility with GT.M must be maintained. This also preserves ANSI escape sequences included in the ydb_prompt/gtm_prompt environment variables (for example one can use this to color the direct mode prompt). Previously such usages could cause a "bad variable name" error (reported as Issue 348 on GitHub). [#309]

    • The ydbinstall.sh script now issues an error when an option has been specified with no value following it. For example, ydbinstall.sh --installdir --utf8 default. In this case, --installdir needs to be followed by a directory name but that was missed out in the specification. Previously, --utf8 (because that parameter immediately follows --installdir in the command line) was assumed to be the directory where the install was desired and this led to confusing results. Additionally, if a relative path is specified as the install directory name, the script now creates a subdirectory under the current directory at the time when the script was invoked and installs YottaDB there. Previously, it used to install YottaDB in a subdirectory under /tmp, later remove the entire directory and yet confusingly display a message indicating the install was successful. Finally, the geteuid executable is no longer part of the YottaDB install. Its sole purpose was to get the effective user id at the time of installing YottaDB and this is easily obtained without a standalone executable. If you have any scripts that use getuid, please replace it with id -un. [#338]

    • The ydbinstall.sh script checks at the outset for the existence of all utilities that it relies on (e.g. tar, gzip, grep etc.) and exits with a clear error message if any of them do not exist. Previously, it reported hard to diagnose errors at the first point of failure from a missing utility program. [#347]

    • YottaDB changes terminal characteristics internally only for the duration of a READ command or while interacting in Direct Mode. Previously, YottaDB changed terminal characteristics at process startup and restored them at process exit, which meant that non-M code reading from a terminal used by M code might not behave as expected by the non-M code. [#350]

    • SIGQUIT/SIGINT signals (generated by kill -3 and kill -2 respectively) are correctly handled by YottaDB processes. Previously, these signals were ignored if the target process had spawned another process (for example using the $ydb_procstuckexec) and was waiting for it to finish. [#357]

    • Environment variables can be set and unset inside M using VIEW commands. VIEW "SETENV":"envvar":value sets the environment variable named envvar to value and VIEW "UNSETENV":"envvar" unsets the environment variable envvar. [#369]

    • YottaDB recompiles a .m source file to generate a new .o object file if a source file and its corresponding object file (as matched by $zroutines) have the same time stamp. Previously, YottaDB recompiled only if the timestamp of the matching object file was older than than of the source file. To avoid unnecessary recompilation, YottaDB ensures that a generated object file has a later timestamp than its source file. Previously, it was possible for both to have the same timestamp. [#385]

    • If the environment variables ydb_linktmpdir and gtm_linktmpdir are unspecified, but ydb_tmp or gtm_tmp are, YottaDB uses the latter for the location of the relinkctl control files for auto-relink enabled directories. Previously, owing to a regression effective GT.M V6.3-002 (and in turn YottaDB r1.10), in this case, the relinkctl control files were created in /tmp. [#392]

    • YDB_RELEASE is a numeric constant defined in libyottadb.h (e.g., 124 for YottaDB r1.24) that C code accessing YottaDB can use for conditional compilation. [#393]

    • The permissions of the temporary directory /tmp/yottadb/$ydb_ver (e.g., /tmp/yottadb/r1.24_x86_64) created by ydb_env_set are read-write-execute for user, group and world if YottaDB is installed to be world-executable, and read-write-execute for the user, and the group permitted to run YottaDB, if YottaDB is installed to allow only members of a group to execute it. Previously it was read-write-execute only for the user, which while appropriate for a single-user environment, is not well suited to multi-user systems. [#395]

    • Accessing through SimpleAPI functions issues a ZGBLDIRACC error if the ydb_app_ensures_isolation environment variable is set to a non-null value but the global directory file does not exist. Previously, this abnormally terminated the process with a KILLBYSIGSINFO1 error (SIG-11). [#397]

    GT.M V6.3005

    The GT.M release notes, edited where appropriate for YottaDB, follow the table. Each of those release notes has a link to the original GT.M release note.

    ID Category Summary
    (GTM-3659) Admin Improved MUPIP LOAD error messaging
    (GTM-4647) Admin The ydb_mstack_size environment variable specifies M stack size in KiB
    (GTM-5059) Admin ydb_mstack_crit optionaly specifies the percentage of the stack at which YottaDB should produce a STACKCRIT
    (GTM-5574) Other Percent conversion routines handle larger numbers
    (GTM-7960) Admin Warnings of approach to maximum database file size
    (GTM-8836) Admin Account for MUPIP journal rollback multi-threading in hash table condition handler
    (GTM-8875) Other More complete detection of STACKOFLOW
    (GTM-8877) Admin Allow user to create M filters for the commands passed to zsystem and PIPE
    (GTM-8910) DB Prevent disruption of $ORDER(gvn,1) by MUPIP REORG
    (GTM-8930) Language Improvement to return values from $VIEW("JNLPOOL")
    (GTM-8940) DB Performance improvement for ftok semaphores
    (GTM-8941) Admin LKE recognizes the full keyword for the -CRITICAL qualifier
    (GTM-8942) Other Reduce impact of signal management
    (GTM-8943) Language ZGOTO 0 in a call-in returns to the invoking C code
    (GTM-8945) Admin Prevent Receiver hang after killing an Update Process
    (GTM-8949) Other Prevent recursive calls to system memory allocator
    (GTM-8951) Language $TEXT() and ZPRINT use auto-relink when their argument includes a routinename
    (GTM-8953) Admin ROLLBACK FORWARD with -VERIFY properly applies all valid updates
    (GTM-8954) Admin Source Server sends all errors to the log file
    (GTM-8955) Other Relink Locking Speedup
    (GTM-8956) Other -NOWARNING compiler qualifier suppresses more messages
    (GTM-8957) Admin MUPIP SET -NOREADONLY -ACC=BG works in one command
    (GTM-8958) Admin TLS reference implementation plug-in disables SSLv3 by default
    (GTM-8959) Language For 64-bit Linux, fix ZGOTO 0 within a call-in
    (GTM-8962) Language Clean up ZSHOW "i" output
    (GTM-8964) Admin MUPIP respects -READONLY (MM) database state
    (GTM-8965) Language Alternation pattern with a large match produces a PATALTER2LARGE error
    (GTM-8967) DB Correct reporting of globals reported by TPRESTART
    (GTM-8969) DB When encrypting for the first time, prevent spurious CRYPTOPFAILED errors
    (GTM-8973) Other External call table loading more careful about M labelrefs
    (GTM-8974) DB Improved handling of significant IO pauses in Database or Journal I/O
    (GTM-8980) Language VIEW and $VIEW() fixes, particularly related to region arguments
    (GTM-8981) Language Fix to IF @<literal>
    (GTM-8985) Language Prevent possible incorrect result from a function with all literal arguments in a Boolean expression
    (GTM-8988) Admin MUPIP RESTORE handling of out-of-space
    (GTM-8989) Admin Prevent unusual MUPIP RUNDOWN hang
    (GTM-8990) Language ZRUPDATE treats a cycle of symbolic links like a simple missing routine
    (GTM-8992) DB YottaDB never decrements database statistics for $DATA(), $GET(), $ORDER(), or $QUERY()
    (GTM-8996) Admin YottaDB issues an fsync on the database file after a region freeze goes into effect
    (GTM-9001) Other Improved bounds checking in DSE and MUPIP

    Database

    • $ORDER(gvn,-1) and $ZPREVIOUS(gvn) appropriately handle the concurrent move of the global variable tree root block of the gvn by MUPIP REORG; previously, this concurrence could occasionally produce a GVORDERFAIL with a status code of tSSS. (GTM-8910)

    • YottaDB avoids superfluous public (ftok) semaphore control operations on database startup or rundown. (GTM-8940)

    • TPRESTART messages correctly identify the global causing the conflict; previously they could report an incorrect global name. (GTM-8967)

    • YottaDB processes work correctly when a concurrent MUPIP REORG -ENCRYPT encrypts a previously unencrypted database file. Previously YottaDB processes could fail with CRYPTOPFAILED errors unaccompanied by other errors explaining the reason for the failure. This issue was only observed in the development environment, and was never reported by a user. (GTM-8969)

    • YottaDB processes attempting to acquire a shared database resource and encountering long delays continue to wait if the process holding the resource is still active. Previously they intervened prematurely which could cause DBDANGER errors and accompanying database damage. YottaDB processes attempting to acquire a shared resource required to perform journal writes and encountering an extended delay in acquiring the resource, issue JNLSENDOPER/JNLFLUSH/JNLPROCSTUCK messages to the system log, and, if so configured, freeze the instance as a result, sending REPLINSTFROZEN/REPLINSTFREEZECOMMENT messages to the system log. They continue to attempt the journal writes, removing the instance freeze if they eventually succeed. Previously, such processes received an error, and the instance required a operator action to release the freeze. (GTM-8974)

    • YottaDB does not decrement database statistics for $DATA(), $GET(), $ORDER(), or $QUERY(). Note that, to minimize performance impact, YottaDB updates most database statistics without concurrency controls, so the statistics are approximate and may have brief fluctuations. Previously YottaDB made explicit adjustments which reporting was more likely to detect. MERGE operations increment DATA and GET database statistics to more accurately reflect database activity. Previously, Merge suppressed increments to those statistics under certain conditions.(GTM-8992)

    Language

    • If the process has access to an instance file designation, $VIEW("JNLPOOL") returns its name; if the process has not yet opened the pool, the return contains an asterisk after the name. If the process does not have sufficient information to determine a replication journal instance file, the function returns "No replication instance defined." Previously, the function with this argument returned an empty string if the process had not opened the journal pool. (GTM-8930)

    • A ZGOTO 0 in case of call-in, unwinds all the M stack frames and returns to the invoking C routine. In case of a non-CI invocation, this terminates the process. A ydb_ci invocation without calling ydb_init() first, proceeds with the CI invocation. Previously, this produced a segmentation violation (SIG-11) error. This issue was only observed in the development environment, and was never reported by a user. (GTM-8943)

    • With auto-relink enabled, $TEXT() and ZPRINT use auto-relink when their argument includes a routinename. Note that ZBREAK does not use auto-relink because its intended purpose is as a debugging facility and if the user intends the ZBREAK for a new version they can explicitly request it with a ZLINK. Previously, $TEXT() and ZPRINT used the version most recently linked by the process even if a new version had become available in an auto-relink enabled environment. (GTM-8951)

    • ZGOTO 0 in a call-in returns to the invoking program. Previously on x86-64 Linux systems with glibc 2.24 or later, this generated a segmentation violation (SIG-11).(GTM-8959)

    • ZSHOW "I" outputs $ZPIN and $ZPOUT even if they are the same as $PRINCIPAL and no longer displays $ZPROCESS, as it was only meaningful on OpenVMS; also, $ZTNAME appears in proper alphabetic sequence. Previously if $ZPIN or $ZPOUT matched $PRINCIPAL, ZSHOW "I" omitted them, $ZPROCESS appeared as an empty string and $ZTNAME was not ordered appropriately. (GTM-8962)

    • Pattern match of a string with an alternation match exceeding what YottaDB can handle produces a PATALTER2LARGE error; previously this condition produced a segmentation violation (SIG-11). (GTM-8965)

    • VIEW and $VIEW() with a empty string or inappropriate region-list works appropriately; in r1.22, these could cause inappropriate results, including a segmentation violation (SIG-11). $VIEW("statshare") returns a 0 when the process has sharing disabled, a 1 when it has sharing enabled and a 2 when sharing is selectively enabled. In r1.22, it did not differentiate between the all and selective cases and returned 1 when sharing was disabled and selective disabling was also specified. $VIEW("statshare","<region>") works appropriately even if the region had been selectively disabled when full sharing is disabled and the region had not been opened. In r1.22, this set of conditions produced a segmentation violation (SIG-11). The error messages when invalid parameters are passed to VIEW/$VIEW() print the name of the parameter; previously such error messages did not have the name of the parameter. (GTM-8980)

    • IF @<literal> works correctly when the literal evaluates to FALSE; previously, it tended to fail with an inappropriate INDEXTRACHARS error or a segmentation violation (SIG-11). (GTM-8981)

    • The compiler appropriately handles possible string returns into Boolean expressions from functions with all literal arguments; previously, it could produce an incorrect result. The workaround was to avoid all literal arguments for $CHAR(), $EXTRACT(), $PIECE(), their $Z*() variants and $SELECT() when they appeared in Boolean expressions. (GTM-8985)

    • When ZRUPDATE encounters a cycle of symbolic links without finding a specified routine, it treats the cycle the same as a simple routine not found and ignores the missing routine. Previously, the command issued an error with text about "too many levels of symbolic links". This issue was observed in the development environment after upgrading to newer Linux distributions. (GTM-8990)

    System Administration

    • MUPIP LOAD reports ranges of records not loaded due to missing database files; previously it reported an error for every such record. (GTM-3659)

    • YottaDB supports specifying the M stack size in KiB with the ydb_mstack_size environment variable. No setting or a setting of 0 uses the default (272KiB). The minimum supported size is 25 KiB; YottaDB reverts values smaller than this to 25 KiB. The maximum supported size is 10000 KiB; YottaDB reverts values larger than this to 10000 KiB. (GTM-4647)

    • YottaDB recognizes setting the environment variable ydb_mstack_crit_threshold to specify an integer between 15 and 95 defining the percentage of the stack which should be used before YottaDB emits a STACKCRIT warning. If the value is below the minimum or above the maximum YottaDB uses the minimum or maximum respectively. The default is 90. (GTM-5059)

    • An automatic database file extension, MUPIP EXTEND, INTEG and SIZE all put a message in the system logs when the database reaches 88% of its maximum size. Beyond this 88% threshold, manual and automatic extends only report at 1% intervals, but INTEG and SIZE report at every subsequent invocation while the condition persists. All but the automatic extension also produce the message for the operator. Previously, YottaDB gave no such warnings, which made it necessary to proactively check on database size. (GTM-7960)

    • When a multi-threaded instance of MUPIP journal -rollback runs out of memory during a rehashing operation, child threads transfer error-handling to the parent thread and terminate. Previously, child threads occasionally failed to report the error, causing MUPIP to halt without a descriptive error message. This issue was only observed in the development environment, and was never reported by a user. (GTM-8836)

    • The YottaDB restriction mechanism recognizes the following lines:

      ZSYSTEM_FILTER[:M labelref]
      PIPE_FILTER[:M labelref]

      The labelref must include a routine name. If a process is restricted by a ZSYSTEM or PIPE_OPEN line in the restrictions file that restriction takes precedence over the corresponding filter restriction. Otherwise when a process is subject to these restrictions, YottaDB inserts an invocation of the labelref prior to the restricted command, passing a string containing the argument to the ZSYSTEM command or the command deviceparameter of the PIPE OPEN. The path to the filter routine must be included in $zroutines. YottaDB recommends that the filter routine is placed in a location with restricted access such as $ydb_dist. If the filter invocation return is -1, YottaDB produces a RESTRICTEDOP error, otherwise it executes the command using the returned string via output parameters as a, possibly identical, replacement for the original string. Since YottaDB uses the call-ins mechanism to execute the filters, a filter invocation inside a TP transaction in call-ins produces a CITPNESTED error. Note that because ZSYSTEM and OPEN are not Isolated actions YottaDB recommends against their use within a TP transaction. Filters also increment the nested level of call-ins. A recursive filter invocation produces a NOFILTERNEST error. YottaDB reports all filter errors to the operator log accompanied by a COMMFILTERERR.

      The M labelref is mandatory. If it is not specified a syntax error is assumed (which in turn enables all restrictions unconditionally).

      An example restrict file for this:

      cat $ydb_dist/restrict.txt
      
      ZSYSTEM_FILTER:^filterzsy
      PIPE_FILTER:^filterzsy

      The actual filter routine:

      filterzsy(inarg,outarg);
       if ""=inarg set outarg="-1;must provide a command" quit
       for i=1:1 set arg=$piece(inarg,";",i) quit:""=arg  do  quit:$data(outarg)
       . for  quit:$zchar(9,32)'\[$extract(arg)  set arg=$extract(arg,2,9999)
       . set cmd=$piece(arg," ")
       . for restrict="sudo","cd" if cmd=restrict set outarg="-1;command "_restrict_" not permitted" quit
       . quit:$data(outarg)
       . if "echo"=cmd set $piece(arg," ")="echo #",$piece(inarg,";",i)=arg    ;example of modification
       set:'$data(outarg) outarg=inarg
       quit +outarg

      Filter execution starts with $STACK=1 ($ZLEVEL=2).

      Following are the YottaDB commands, Intrinsic Special Variables, and functions whose behavior changes in the context of a filter invocation.

      ZGOTO 0 (zero) returns to the processing of the restricted command as does ZGOTO 1 (one) with no entryref, while ZGOTO 1:entryref replaces the originally invoked filter and continues filter execution.

      $ZTRAP/$ETRAP NEW'd at level 1.

      $ZLEVEL initializes to one (1) in GTM$CI, and increments for every new stack level.

      $STACK initializes to zero (0) in GTM$CI frame, and increments for every new stack level.

      $ESTACK NEW'd at level one (1) in GTM$CI frame.

      $ECODE/$STACK() initialized to the empty string at level one (1) in GTM$CI frame.

      After the filter completes, YottaDB restores the above to their values at the invocation of the filter. (GTM-8877)

    • LKE recognizes the full keyword for the -CRITICAL qualifier; previously it only accepted -CRIT. (GTM-8941)

    • The Receiver Server process recovers after its Update process was terminated with a signal while idle. Previously, on Linux systems with glibc 2.25 or newer, the Receiver Server process could hang indefinitely, requiring manual cleanup of the process and shared memory. This issue was only observed in the development environment, and was never reported by a user. (GTM-8945)

    • MUPIP JOURNAL -ROLLBACK -FORWARD when executed with -VERIFY properly applies all updates. Previously updates that should have been applied to the database were instead sent to the lost transaction file. The workaround was to execute MUPIP JOURNAL -VERIFY independent of the FOWARD ROLLBACK. (GTM-8953)

    • The Source Server directs errors to the Source Server log file. A previous fix with GTM-8576 was incomplete and could result in TLS initialization error messages not logged to the server log file. (GTM-8954)

    • Executing MUPIP SET -NOREAD_ONLY -ACC=BG on a read-only database sets the access mode to BG and turns off read-only. Previously, this action would result in a READONLYNOBG error message and no changes to the file. (GTM-8957)

    • The TLS reference implementation plug-in disables SSLv3 by default. Previously, customers wishing to disable SSLv3 needed to add the configuration option 'ssl-options: "SSL_OP_NO_SSLv3";' to the "tls" namespace in the $ydbcrypt_config configuration file. (GTM-8958)

    • MUPIP does not modify -READONLY (MM) database files; previously various MUPIP commands could inappropriately update state information in such database files, causing errors when subsequently using the database. (GTM-8964)

    • MUPIP RESTORE exits with an error when it encounters an out-of-space condition. Previously, if MUPIP RESTORE encountered an out-of-space condition, it crashed with a segmentation violation (SIG-11). This issue was only observed in the development environment, and was never reported by a user. (GTM-8988)

    • MUPIP RUNDOWN works as expected. In rare situations, processes killed during transaction commits could leave the transaction information in an inconsistent state that caused MUPIP RUNDOWN to hang. Note that YottaDB strongly recommends against kill -9 of a process accessing the database as it can induce database damage. This issue was only observed in the development environment, and was never reported by a user. (GTM-8989)

    • YottaDB issues an fsync on the database file after a region freeze goes into effect, which forces the underlying file system to harden changes to secondary storage. (GTM-8996)

    Other

    • The %DH,%HD,%OH,%HO,%OD, and %DO routines now handle conversions with numbers up to YottaDB's maximum string length in size. Additionally, %DH and %DO routines now handle the conversion of negative decimal numbers properly, even when the specified length is not long enough to represent that fully converted number. Previously, the %DH,%HD,%OH,%HO,%OD, and %DO routines could only deal with numbers up to the equivalent of the maximum 18-digit decimal number. Attempting to convert a number larger than this would cause roundoff in the final result, which still occurs if they are used for arithmetic. Moreover, specifying a length for the %DH and %DO routines that was not long enough to hold the fully converted result would cause the routines to produce incorrect values. The workaround for both these issues was to avoid using these percent routines with numbers greater than the maximum 18-digit decimal number and to always specify an appropriate length for the %DH and %DO routines. (GTM-5574)

    • When a stack frame exceeds the M virtual machine stack pointer, YottaDB issues a STACKOFLOW error and produces a YDB_FATAL_* context dump, but no core file, as this an application issue, rather than a YottaDB problem. A module with a very large number of variables and/or dynamic literals can cause this problem. Note that the $ydb_mstack environment variable can, within limits, set the size of the M virtual machine stack size. Previously if the overflow was sufficient to make the stack pointer negative, the process exited with a segmentation violation (SIG-11). (GTM-8875)

    • YottaDB avoids superfluous signal management operations. Previously system traces showed more sigprocmask system calls than desirable, particularly on Linux systems with Meltdown/Spectre mitigation in place. (GTM-8942)

    • YottaDB prevents recursive calls to the system memory allocator. Previously, the system memory allocator could be called recursively which resulted in a process hanging. This issue was only observed in the development environment, and was never reported by a user. (GTM-8949)

    • YottaDB uses a lighter weight locking mechanism to protect the relink control file. Previously, a large number of concurrent relink control operations such as those done on process shutdown could cause the system to use an excessive amount of CPU. (GTM-8955)

    • The YottaDB compiler -NOWARNING qualifier for the MUMPS command and $ZCOMPILE suppresses warning messages for BADCHAR, BLKTOODEEP, and LITNONGRAPH; previously it did not. (GTM-8956)

    • YottaDB external call loading is more discriminating about M labelrefs; previously it did not detect all invalid labelrefs, which deferred error detection and made diagnosis more challenging. (GTM-8973)

    • YottaDB appropriately bounds checks variable length input parameters to MUPIP and DSE. Previously it did not detect an off-by-one buffer overrun. Also, MUPIP EXTRACT issues the ICUNOTENABLED warning message when used with the -OCHSET qualifier while in M mode. Previously, attempting to use -OCHSET while in M mode resulted in a SIG-11. These issues were only observed in the development environment, and was never reported by a user. (GTM-9001)

    More Information

    (Section Blank for this Release)

    Messages

    From YottaDB

    INVLNPAIRLIST, Invalid lockname/subscript pair list (uneven number of lockname/subscript parameters)

    Runtime Error: This message comes only from the Golang wrapper. When specifying the locks to be acquired in the parameter list of LockE(), each lock is represented by a pair of arguments - a lock name and a list of subscripts. If the arguments aren't paired properly such that the last lock name read has no subscripts specified, this error is given.

    Action: Determine why the parameter list is not paired up correctly and fix it.

    INVSPECREC, pppp Invalid global modifier record

    MUPIP Error: This indicates that MUPIP INTEG found a corrupt 4-byte collation record was found for a global variable (that is the 1st of the 4 bytes is not 1). pppp identifies the path in the directory tree (each element of the path consisting of a block#/offset) leading to the error.

    Action: Use DSE to examine the corrupt record and fix it. Report the entire incident context to your YottaDB support channel.

    INVTPTRANS, Invalid TP transaction - either invalid TP token or transaction not in progress

    Runtime Error: This message comes from the threaded Simple API engine (both C and Golang). Each TP callback routine is given a 'tptoken' when it is driven. This token (unmodified!) must be used in all calls to the runtime from THIS TP callback routine at this level or this error message is returned.

    Action: Determine why the tptoken value is incorrect and correct it.

    NODEEND, End of list of nodes/subscripts

    Runtime Error: This 'error' is indicator (like EOF) that the list of nodes or subscripts being fetched via ydb_node_next/ydb_node_previous or ydb_subscript_next/ydb_subscript_previous or their equivalent Golang wrappers, is at an end.

    Action: Not an error strictly speaking - Terminate the loop the list is being read in as it is complete.

    RECLOAD, Error loading record number: nnnn

    MUPIP Error: This message identifies nnnn, a record or a range of records, that MUPIP could not LOAD and follows a message about the cause. If this message is Fatal, which it can be for BIN format, it produces a core file for diagnostic analysis.

    Action: Address the cause or, for GO and ZWR format input files, examine the record or range of records with a text editor for possible correction or alternate action and for BIN format if fixing the cause does not resolve the error switch to ZWR format EXTRACT.

    REGSSFAIL, Process pppp encountered error eeee contributing to the snapshot for region rrrr - the snapshot is no longer valid.

    MUPIP Error: A YottaDB process encountered failure while opening snapshot file or attaching to shared memory or writing a block to the snapshot file, any of which invalidate the snapshot file. The original error eeee that process pppp encountered follows the REGSSFAIL error message and can also be found in the syslog (search for messages from process pppp).

    Action: Examine the syslog for messages issued by process pppp to obtain details of the failure and take action, possibly by modifying file access characteristics or user roles, to address the problem.

    SETENVFAIL, VIEW "SETENV":"eeee" failed in setenv() system call

    Run Time Error: This indicates that a setenv() system call failed for the environment variable named eeee.

    Action: Examine the accompanying SYSCALL error message which has more detail on the error returned by the setenv() call.

    SIMPLEAPINOTALLOWED, Process cannot switch to using Simple API while already using threaded API.

    Run Time Error: This indicates a process has started using the threaded Simple API functions (e.g. ydb_set_st()) and is now trying to use the Simple API functions (e.g. ydb_set_s()).

    Action: A process can only use either Simple API functions or threaded Simple API functions, not both.

    STAPIFORKEXEC, Calls to YottaDB are not supported after a fork() if threaded Simple API functions were in use in parent. Call exec() first

    Run Time Error: This indicates a process that has already used at least one threaded Simple API function did a fork() to create a child process and is trying to use YottaDB (e.g. Simple API functions like ydb_set_s(), or threaded Simple API functions like ydb_set_st()).

    Action: Once a process that has used threaded Simple API functions or threaded Simple API functions does a fork(), the child process has to do an exec() before it can call again into YottaDB (using Simple API functions or threaded Simple API functions).

    STDERRALREADYOPEN, STDERR deviceparameter specifies an already open device xxxx

    Run Time Error: This indicates that the STDERR deviceparameter in the OPEN command of a PIPE device specifies a device name xxxx that is already open in the process.

    Action: Specify a device name that is not already an open device in the process.

    STRUCTNOTALLOCD, Structure not previously called with Alloc() method

    Runtime Error: This message comes only from the Golang wrapper. If a BufferT or BufferTArray structure is used without having been allocated by the Alloc() message, the wrapper can return this error.

    Action: Be sure the structure has been allocated before attempting to use it.

    TCPCONNTIMEOUT, Connection wait timeout (ssss seconds) has expired

    Runtime Error: When MUPIP RESTORE or MUPIP BACKUP are pushing/pulling data over a socket, the attempt to attach to "the other side" can timeout. If it does timeout, this is the error that is returned.

    Action: Determine the source of the connection delay, fix and retry.

    THREADEDAPINOTALLOWED, Process cannot switch to using threaded Simple API while already using Simple API

    Run Time Error: This indicates a process has started using the Simple API functions (e.g. ydb_set_s()) and is now trying to use the threaded Simple API functions (e.g. ydb_set_st()).

    Action: A process can only use either Simple API functions or threaded Simple API functions, not both. If the base program corresponding to this process is an M program, it can only use Simple API functions.

    UNKNOWNSYSERR, An unknown system error has occurred:

    Runtime Error: An unrecognized error code has been passed to ydb_message_t() (C) or MessageT() (Golang)

    Action: Determine the source and meaning of the unknown message code such that a proper error message code can be passed in.

    UNSETENVFAIL, VIEW "UNSETENV":"eeee" failed in unsetenv() system call

    Run Time Error: This indicates that a unsetenv() system call failed for the environment variable named eeee.

    Action: Examine the accompanying SYSCALL error message which has more detail on the error returned by the unsetenv() call.

    From GT.M

    COLLDATAEXISTS, Collation type cannot be changed while xxxx data exists

    Run Time Error: This indicates that an attempt was made to change the collation type while xxxx was either a subscripted local for a process collation change or a gvn name for global variable collation.

    Action: KILL or NEW the local variables before you change the local collation type, or KILL a gvn before changing its collation.

    COMMFILTERERR, Error executing the command filter for FFFF DDDD

    Run Time Error: Reports a problem in filter code where FFFF describes the nature of the filter and DDDD some thing about the nature of the issue. There may be associated/related messages. Because filters are a potential security tool, these errors tend are generally reported to the operator log.

    Action: Analyze the filter code in light of the messages and revise accordingly.

    EXTRINTEGRITY, Database ffff potentially contains spanning nodes or data encrypted with two different keys

    MUPIP Error: MUPIP EXTRACT cannot run because the database file ffff might contain spanning nodes or be partially encrypted with a particular key. Proceeding on a live database in such situation could result in data corruption.

    Action: If you encounter this error while running MUPIP EXTRACT with -FORMAT="BINARY", re-run the command with the -FREEZE qualifier. MUPIP EXTRACT requires -FREEZE to acquire stand-alone access to produce a consistent copy of the data. However, not using -FREEZE when you request a MUPIP EXTRACT may produce a loadable, if inconsistent output. If you encountered this error while running MUPIP EXTRACT with ZWR or GO format, it is likely that your database is encrypted with more than one key; with BINARY output it may be multiple keys or spanning node data. If the issue is a key change, run MUPIP REORG -ENCRYPT to complete the encryption of the database. As a final resort, you may use an -OVERRIDE qualifier to proceed on a live database that either contains spanning nodes or is undergoing (re)encryption. Although EXTRACT -OVERRIDE may produce text for analysis, the result is not suitable as input for MUPIP LOAD and YottaDB highly discourages using -OVERRIDE.

    FAILEDRECCOUNT, LOAD unable to process MMMM records

    MUPIP Error: MUPIP LOAD was unable to load MMMM records from the specified input extract.

    Action: Examine prior RECLOAD error messages for causes for the failed records and address them.

    ICUNOTENABLED, ICU libraries not loaded

    Run Time Warning: The operation required the library containing support for International Components for Unicode (ICU) but YottaDB could not find libicu. There may be other messages.

    Action: If you require UTF-8 support, install an appropriate ICU library - see the YottaDB Administration and Operations Guide for information on ICU setup.

    LOADRECCNT, Last EXTRACT record processed by LOAD: RRRR

    MUPIP Information: This message indicates number of records (RRRR) MUPIP LOAD processed. The number of records represents the sum of header records, successfully loaded data records, and failed records. Note: LOAD may have stopped processing due to a record limit in the command or a <CTRL-C>.

    Action: Ensure the identified stopping point corresponds with your intentions.

    LOWSPC, WARNING: Database DDDD has less than PPPP% of the total block space remaining. Blocks Used: UUUU Total Blocks Available: AAAA

    Operator log Information: The database has UUUU block in use and is appoaching its current limit of AAAA blocks. When the database reaches the 88% size threshold, and for every 1% increase in size and beyond, YottaDB reports the blocks used in the LOWSPC warning as the sum of the data blocks and the local bit map blocks.

    Action: Purge data if possible. Consider a MUPIP REORG to compact the remaining data. Investigate whether migrating to a database created by a current version has a higher limit. Move some data to another, possibly new, region and delete it from this one.

    MSTACKCRIT, User-specified M stack size critical threshold of xxxx not appropriate; must be between mmmm and nnnn; reverting to kkkk

    Run Time Error: The environment variable ydb_mstack_crit_threshold was set to an invalid value, either too large, in which case YottaDB uses the largest acceptable value or too low, in which case YottaDB uses the smallest acceptable value.

    Action: If the adjusted value is unacceptable, revise or unset the environment variable.

    NOFILTERNEST, Filter nesting not allowed

    Run Time Error: Filter code must not invoke other code that requires a filter.

    Action: Revise the filter code to adhere to the requirement.

    PATALTER2LARGE, Pattern match alternation exceeded the LLLL repetition limit on prospective matches

    Run Time Error: An alternation pattern applied to a long occurrence of that pattern reached a YottaDB limit (LLLL) on tracking the match.

    Action: Revise the logic to reduce the size of the string being matched or to otherwise break up the match into smaller parts.

    REGFILENOTFOUND, Database file DDDD corresponding to region RRRR cannot be found

    MUPIP Error: This indicates MUPIP cannot locate the database file DDDD mapped to region RRRR.

    Action: Ensure that the current global directory is the one intended and that it maps the file intended. If the path is relative or includes environment variables, ensure that the current working directory and any environment variables are appropriate. Also ensure the file exists and has authorizations, including its path, that make it available to the user attempting to access it. If the MUPIP command involves a statsDB (for example MUPIP INTEG -STATS), ensure that the appropriate regions have STATS enabled, that the $ydb_statsdir environment variable has been properly defined, and that other processes are using shared statistics, as MUPIP by itself does not create new statsDB databases. Note that MUPIP INTEG does not create statsDB and reports any that it skips with an informational message, but exits with a normal status after such skips.

    VIEWCMD, View parameter pppp is not valid with the VIEW command

    Run Time Error: This indicates that the VIEW command has an argument pppp that is only valid with the $VIEW() function.

    Action: Modify the argument.

    VIEWFN, View parameter pppp is not valid with the VIEW command

    Run Time Error: This indicates that the $VIEW() function has an argument pppp that is only valid with the VIEW command.

    Action: Modify the argument.

    Legal Stuff

    Copyright © 2019 YottaDB LLC

    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 registered trademark of YottaDB LLC. GT.M is a trademark of Fidelity National Information Services, Inc. Other trademarks belong to their respective owners.

    This document contains a description of YottaDB and the operating instructions pertaining to the various functions that comprise the software. This document does not contain any commitment of YottaDB LLC. YottaDB LLC believes the information in this publication is accurate as of its publication date; such information is subject to change without notice. YottaDB LLC is not responsible for any errors or defects.

  • V6.3-005
    df1555e8 · GT.M V6.3-005 ·
  • r1.22

    yottadb_r122_linux_armv7l_pro.tgz

    yottadb_r122_linux_armv6l_pro.tgz

    yottadb_r122_linux_x8664_pro.tgz

    yottadb_r122_rhel7_x8664_pro.tgz

    yottadb_r122_src.tgz

    YottaDB r1.22

    Release Note Revision History

    Revision Date Summary
    1.10 Jan 22, 2019 Added specific notes to the Platforms section for the possible need to recompile YottaDB
    1.00 May 15, 2018 r1.22 Initial Release

    Contact Information

    YottaDB LLC

    40 Lloyd Avenue, Suite 104 Malvern, PA 19355, USA info@yottadb.com +1 (610) 644-1898

    Support

    Customers

    Contact your YottaDB support channel.

    Others

    For free (to you) support from members of communities who run widely available applications on YottaDB, please use an application-specific list where appropriate.

    r1.22

    Overview

    YottaDB r1.22 is a minor release, primarily intended to make available in a YottaDB release the enhancements and fixes in the upstream GT.M release.

    YottaDB r1.22 is built on (and except where explicitly noted, upward compatible with) both YottaDB r1.20 and GT.M V6.3-004.

    As always, there as other enhancements and fixes, as noted below. See our Get Started page to use YottaDB.

    Platforms

    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.

    CPU Architecture Supported OS Version(s) Notes
    64-bit x86 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.22 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 info@yottadb.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.22 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 info@yottadb.com 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. Specific notes:

    • On Ubuntu releases after 18.04 LTS, YottaDB needs the libtinfo5 package to be installed.
    • On Arch Linux) and possibly other leading edge distributions, YottaDB may need to be recompiled from source code owing to library and tool chain versions significantly more recent than those used in building the distribution.

    Installation

    See our Get Started page to use YottaDB.

    We strongly recommend that you install YottaDB r1.22 in a newly created directory, different from those of YottaDB r1.20 and any GT.M versions you may have installed on the system.

    Removing an installed YottaDB release

    Assuming $ydb_dist points to the directory where YottaDB is installed:

    • Cleanly shut down all application processes using that release.
    • Execute mupip rundown && mupip rundown -relinkctl.
    • Ensure that there are no gtcm* or gtmsecshr processes active.
    • Use sudo lsof | grep $ydb_dist to ensure there are no open files.
    • Delete the directory with sudo rm -rf $ydb_dist.

    Upgrading to YottaDB r1.22

    As YottaDB r1.22 is upward compatible from both YottaDB r1.20 and GT.M V6.3-004, the minimal upgrade steps are:

    • Install YottaDB r1.22.
    • Recompile any object code, and recreate shared libraries where appropriate.
    • If you are using encryption, compile and install the reference implementation plugin or your customized plugin.
    • Cleanly shut down the application and ensure that the database files are shut down using mupip rundown from the prior release.
    • Switch journal files with the new YottaDB release.
    • Start using the new YottaDB release.

    To upgrade from older GT.M releases, first upgrade to GT.M V6.0-000 or later and follow the steps above, or contact your YottaDB support channel for assistance and guidance.

    A more sophisticated upgrade technique is:

    • Install YottaDB r1.22.
    • Create a new replicated instance of your application (on the same system or a different system).
    • Assuming the existing instance is A, and the new instance is B, start replicating from A to B.
    • Once B catches up, switchover so that B is in a primary role replicating to A.
    • Once you are satisfied with B, remove (or upgrade) A.

    Change History

    r1.22

    YottaDB r1.22 includes the following changes from YottaDB r1.20.

    ID Category Summary
    (#102) Other ydb_coredump_filter to control information in core dumps
    (#159) Language $TEXT returns source code lines with both carriage return and newline line terminators removed
    (#193) Language GDE @ command reports success after executing good command files
    (#197) Language ydb_env_set preserves ydb_gbldir/gtmgbldir and ydb_routines/gtmroutines
    (#207) DB TPRESTART syslog messages identify correct global name and message type
    (#209) Other Complete set of ydb_* environment variables corresponding to all gtm*/GTM* environment variables
    (#210) Admin Source Server errors always appear in the Source Server log file
    (#215) Admin Ctrl-Z (the suspend signal) is honored in all cases
    (#217) DB SET and $INCREMENT() work correctly without abnormal process termination in a very rare case
    (#218) DB ydb_app_ensures_isolation provides initial setting for global variables where application design ensures Isolation
    (#220) Other mumps -nowarning does not display BLKTOODEEP messages
    (#221) Admin ydb_* environment variables to drive operation of ydbinstall.sh script
    (#224) Language Certain edge cases of VIEW and $VIEW() work correctly without terminating the process
    (#228) Language $ZSEARCH() calls in a loop work correctly in certain edge cases
    (#233) DB Option to reduce IO impact of MUPIP REORG
    (#235) Other Source server fails rarely with JNLSWITCHRETRY error when instance is frozen
    (#237) Other Establish replication connections more efficiently in an edge case
    (#247) DB Epoch tapering works correctly without process termination from signal 8 in a rare case

    Database

    • Type 0 and type 3 TPRESTART messages in the syslog (enabled by turning on TP restart logging) correctly report the global variable causing the restart. Furthermore, type 3 messages correctly identify themselves as type 3 messages. Previously, they could report an incorrect global variable reference, and type 3 messages were sometimes incorrectly identified as type 2. (#207)

    • SET and $INCREMENT() operations on a global variable work correctly without abnormal termination in a very rare case. Previously, it was possible for a process doing the operation to terminate abnormally with a SIG-11. This was only observed in internal testing, and there was no risk of database damage from this issue. (#217)

    • A string value of a comma-separated list of global variable names in the environment variable ydb_app_ensures_isolation informs YottaDB that application design ensures the transaction property of Isolation for global variables in that list and YottaDB need not do so, potentially increasing application throughput by reducing random, accidental TP restarts. The effect is functionally equivalent to executing the M language command view "noisolation":"<list>" where "<list>" is the value of the environment variable. For example, export ydb_app_ensures_isolation="^TMP,^XREF" is equivalent to a process executing view "noisolation":"^TMP,^XREF" before it makes any database accesses. Note that using the environment variable ydb_app_ensures_isolation requires the environment variable ydb_gbldir to be set to a valid global directory. The setting applies to the global variables mapped by that global directory. (#218)

    • MUPIP SET -REORG_SLEEP_NSEC= specifies the number of nanoseconds that a MUPIP REORG process operating between blocks that it processes, with default value of 0 and a maximum of 999999999 (i.e. 999,999,999, or 1 nanosecond less than 1 second). Using non-zero values reduces the IO impact of MUPIP REORG, at the cost of increasing the duration of the operation. Note that the existing environment variable ydb_poollimit / gtm_poollimit is the appropriate technique to limit the impact of MUPIP REORG on global buffers; the -reorg_sleep_nsec can be used to limit the impact on the IO subsystem. (#233)

    • Epoch tapering works correctly. Previously, on very rare occasions, epoch tapering could result in process termination with a signal 8 resulting from a divide-by-zero error. This issue was only observed in the development environment, and was never reported by a user. (#247)

    Language

    • $TEXT() returns source code lines with both the carriage return and newline characters removed from routine files that have lines ending with them. Previously, only the newline was removed. (#159)

    • The GDE @ command reports success after executing good command files. In r1.20, it would issue a YDB-E-IOEOF error even after sucessfully executing the commands in the file specfied. A workaround was to set the environment variable ydb_msgprefix to "GTM" for the GDE process. (#193)

    • Values of environment variables ydb_gbldir/gtmgbldir and ydb_routines/gtmroutines set before sourcing ydb_env_set are preserved. The ydb_* versions of the environment variables is used if both ydb_* and gtm* versions are defined. (#197)

    • VIEW commands and $VIEW functions work correctly. Previously, edge cases in YottaDB, and newly introduced in GT.M V6.3-004, in commands like VIEW "NOISOLATION", functions like $VIEW("GVFILE"), etc., could terminate the process abnormally with a SIG-11, SIG-6, GTMASSERT2 error. (#224)

    • $ZSEARCH() calls in a loop using the same stream and the same pattern work by ignoring edge cases of changes in the underlying files (such as a permission change of a directory that makes a file inaccessible to the process) and pathological cases such as an infinite symbolic link loop. Previously, ZSEARCH() calls in these edge cases could incorrectly issue an error (SYSTEM-E-ENO40, SYSTEM-E-ENO13, etc.), with some difference in behavior between Ubuntu 18.04 LTS and prior releases resulting from a change in the underlying API. (#228)

    System Administration

    • Replication Source Server startup errors always appear in the Source Server log file. In previous versions of YottaDB, if the Source Server was started from the terminal, and the Source Server startup command failed or the Source Server successfully started but later failed (e.g. with errors like NULLCOLLDIFF, REPLOFFJNLON, REPLINSTNOHIST, SECNOTSUPPLEMENTARY etc.) this error message did not show up in the Source Server log file or on the terminal where it was started (assuming that terminal still exists at the time of the error). The release notes of GT.M V6.3-004 mention that this issue has been fixed by GTM-8576 but we found the issue exists even in GT.M V6.3-004. (#210)

    • Ctrl-Z (the suspend signal) is honored by YottaDB processes in all cases. Previously, if the signal was delivered while the process was executing a section of code where it was not safe to suspend it, the signal was ignored and the user had to retry the Ctrl-Z. Note that as handling the signal is deferred when the process is in sensitive areas of code, it is possible for the response to be momentarily delayed. (#215)

    • The ydbinstall.sh script uses environment variables ydb_buildtype, ydb_dryrun, ydb_gtm, ydb_group_restriction, ydb_keep_obj, ydb_lcase_utils, ydb_overwrite_existing, ydb_prompt_for_group, and ydb_verbose to drive its operation, corresponding to the environment variables gtm_buildtype, gtm_dryrun, gtm_gtm, gtm_group_restriction, gtm_keep_obj, gtm_lcase_utils, gtm_overwrite_existing, gtm_prompt_for_group, and gtm_verbose. The latter remain supported, with the proviso that if a ydb_ prefixed environment and the corresponding gtm_ prefixed environment variable are both defined, the former takes precedence. (#221)

    Other

    • A value of "0xXX" where XX are case-insensitive hexadecimal digits in the environment variable ydb_coredump_filter, sets the corresponding value to /proc//coredump_filter (see man 5 core) at process startup without explicitly setting a value if unspecified. This controls the contents of core dumps generated by the process. A YottaDB process that terminates or is terminated abnormally (terminates with any signal except SIGKILL, SIGQUIT, or SIGTERM) generates a core file, if generating core files is enabled in the system and for that process. As core files can contain confidential / proprietary information, please limit the content of core files to that required for diagnostic purposes, and generate them with appropriate protection. If ydb_coredump_filter is not specified, but gtm_coredump_filter is, the latter environment variable is used. If both are specified, the former takes precedence. Previously, only the environment variable gtm_coredump_filter was recognized, with a default value of "0x73". (#102)

    • YottaDB has a complete set of environment variables with "ydb_" prefixes for environment variables with "gtm" and "GTM" prefixes. For example, ydb_routines is the equivalent of gtmroutines, ydb_chset is the equivalent of gtm_chset, ydb_repl_instance is the equivalent of gtm_repl_instance etc. YottaDB continues to support the gtm* environment variable if the corresponding ydb_* environment variable is not defined. If both variables are defined, the ydb_* definition takes precedence. The full list of environment variables is in the Environment Variables section of the Administration and Operations Guide. (#209)

    • mumps -nowarning does not display BLKTOODEEP messages. Previously, mumps -nowarning displayed YDB-W-BLKTOODEEP errors even though it did not display other types of errors (e.g. YDB-E-EXPR). (#220)

    • Source Server processes continue operation even when the instance is frozen due to an error while switching journal files. In prior versions of YottaDB (and GT.M versions V6.3-001A and above), the Source Server could terminate with a JNLSWITCHRETRY error in this uncommon occurrence. This issue was only observed in the development environment and was never reported by a user. (#235)

    • Initiating replication connections between Source and Receiver Servers is more efficient. Previously, in rare cases, the Source Server unnecessarily disconnected the connection and reconnected. This is very similar to (#136) but under slightly different circumstances. (#237)

    GT.M V6.3004

    ID Category Summary
    (GTM-1042) Other The gtm_mstack environment variable can control the M stack size
    (GTM-3146) Other MUPIP BACKUP command ignores aliases
    (GTM-5730) Admin Update Process logs show record type descriptions
    (GTM-6747) Admin MUPIP SET -JOURNAL does not adjust sequence numbers on replicated regions
    (GTM-7483) Other Improve message from a MUPIP INTEG when a Directory Tree issue is detected
    (GTM-7872) Admin Improve message from a MUPIP INTEG directed to an non-existent database file
    (GTM-7915) DB Trigger key size not limited by database key size
    (GTM-8202) Admin Journal extract for specific sequence number(s)
    (GTM-8576) Admin Source Server logs errors to its log file rather than stderr
    (GTM-8643) Language SOCKET device listen queue depth determined by OS configuration; better retry management for local connects
    (GTM-8699) Language Optional region argument for $VIEW("STATSHARE")
    (GTM-8777) Other %GCE, %GSE, %RCE, and %RSE support QUIET entrypoint. %RCE and %RSE support QCALL entrypoint
    (GTM-8791) Other Prevent certain control character inputs to LKE from causing a SIG-11
    (GTM-8859) Admin Correct turn-around point calculation for MUPIP JOUNAL -ROLLBACK when dealing with "idle" regions
    (GTM-8860) Admin Prevent multiple slashes (/) from appearing in MUPIP JOURNAL -EXTRACT output
    (GTM-8870) Other Clean up some rough edges
    (GTM-8874) Language VIEW "[NO]STATSHARE" accepts an optional region-list
    (GTM-8883) DB Online Freeze/Journal switch cleanup
    (GTM-8891) Language Prevent process failure from a certain pattern of $SELECT() errors
    (GTM-8894) Language $ZRELDATE ISV provides the UTC data and time of the YottaDB build
    (GTM-8895) Other %PEEKBYNAME protects the str variable from inappropriate modification
    (GTM-8899) Other Work-around for bugs in the GnuPG agent
    (GTM-8900) Admin MUPIP SET -NOENCRYPTABLE works without valid encryption setup
    (GTM-8903) Language Prevent process failure from a certain pattern of $SELECT() usage
    (GTM-8906) Admin MUPIP JOURNAL -ROLLBACK and -RECOVER handle a larger number of records
    (GTM-8909) Other Online help does not report an inappropriate error when exiting after the user typed <CTRL-C>
    (GTM-8914) Language $VIEW("GVSTATS"), ZSHOW "G" and ZSHOW "T" flag results that are probably not current
    (GTM-8919) DB MUPIP REORG -ENCRYPT does not induce CRYPTOPFAILED errors in concurrent processes
    (GTM-8922) Language VIEW region subarguments can be a list of regions
    (GTM-8923) Language UTF-16 READ * and WRITE * Fixes
    (GTM-8924) Language Fix for unusual conditions with a $PRINCIPAL SOCKET device for a JOB'd process
    (GTM-8926) Other Flush Timer Deferred During External Call
    (GTM-8927) DB Prevent inappropriate JNLCTRL errors

    Database

    • YottaDB limits the key size of a trigger to 1019 bytes. Previously, it limited the key size to the configured limit of regions that used the trigger, which caused a need to increase the maximum key limit and/or change the name of the trigger. This change also allows YottaDB to store triggers more compactly in cases where regions have a small record size limit. (GTM-7915)

    • YottaDB handles journal switch errors encountered during a MUPIP FREEZE -ONLINE -ON correctly. Previously it could leave the specified region with a very large Epoch Interval, which could cause a replication source server to issue SRVLCKWT2LNG errors. In addition, YottaDB only sends a PREVJNLLINKCUT message to the system log when the links have been cut. Previously the message could be reported in rare cases where a journal switch was deferred, then later switched without cutting links. Also, the source server reports the SRVLCKWT2LNG message correctly. Previously the values for PID and the wait time were reversed and the message reported minutes instead of seconds as the unit of time. (GTM-8883)

    • YottaDB processes work correctly when a concurrent MUPIP REORG -ENCRYPT changes the encryption key. Previously processes could fail with CRYPTOPFAILED errors unaccompanied by other errors explaining the reason for the failure. This issue was only observed in the development environment, and was never reported by a user. MUPIP RESTORE issues an encryption setup error when attempting to restore an encrypted backup without the correct encryption setup. Previously MUPIP RESTORE issued a CRYPTOPFAILED when the restore instance was not configured for encryption. (GTM-8919)

    • YottaDB avoids issuing JNLCNTRL errors inappropriately. This issue was only observed in the development environment, and was never reported by a user. (GTM-8927)

    Language

    • The listen queue depth specified with WRITE /LISTEN for a listening socket is limited only by the OS; previously, YottaDB enforced an artificial limit of 5. A SOCKET device retries connection attempts on local sockets that fail due to possible transient issues on the other end of the attempted connection (for example an insufficiently large listen queue). Previously such attempts could sometimes appear to succeed, when they actually did not, leading to subsequent errors from READ and WRITE on the socket. (GTM-8643)

    • $VIEW("STATSHARE",<region>) returns TRUE (1) if the process is currently sharing database statistics for the region and FALSE (0) if it is not. For the process to be sharing the database must be enabled for sharing and the process must have opted in to share. $VIEW("STATSHARE") with no region argument indicates the process has enabled sharing. (GTM-8699)

    • VIEW "[NO]STATSHARE"[:<region-list>] enables or disables database statistics sharing for listed regions which permit such sharing. Without the region-list, the command acts on all regions enabled for sharing. When a targeted region has sharing disabled, STATSHARE has no effect. Note: a VIEW "[NO]STATSHARE" with no region sub-argument opens any unopened mapped regions and any enabled associated statsDB regions; the $gtm_statshare environment variable applies to databases as the application first uses them. When the last VIEW "[NO]STATSHARE" had no region sub-argument, regions implicitly share when the process first references them, but after a VIEW specifies selective sharing, regions don't implicitly share as they open. Previously the VIEW command only supported enabling or disabling sharing for all enabled regions. (GTM-8874)

    • A <side-effect-expression><pure-Boolean-operator>$SELECT(0:side-effect-expression)) sequence produces a SELECTFALSE run-time error; a regression introduced with the literal optimizations in V6.3-002 caused this combination to produce a SIG-11 (segmentation violation) at compilation. (GTM-8891)

    • The $ZRELDATE Intrinsic Special Variable provides the UTC date/time of the YottaDB build in the form YYYYMMDD 24:60 (using $ZDATE() notation). While $ZVERSION and $ZYRELEASE are probably better identifiers for most uses, $ZRELDATE may be a helpful alternative for those testing pre-release builds. (GTM-8894)

    • $SELECT() deals with cases where the first value is evaluated to a literal TRUE (1) and later arguments to the function contain one or more global references. Due to a regression in V6.3-002 associated with compiler optimizations caused this combination to produce a SIG-11 (segmentation violation) at compilation. (GTM-8903)

    • $VIEW("GVSTATS",<region>), ZSHOW "G" and ZSHOW "T" return a question-mark (?) at the end of their output strings when the process does not have access to the current shared statistics; they did not do this previously. Please adjust your scripting as needed to allow for this format enhancement. (GTM-8914)

    • VIEW commands accepting a region sub-argument also accept a comma (,) delimited string listing of regions. As part of deadlock prevention, YottaDB sorts the regions in an internal order, eliminating any duplicates from the list. Note: a VIEW with no region sub-argument opens any unopened mapped regions in the current global directory, while one with a list only opens the listed regions. If the VIEW argument has a corresponding environment variable to set the default state, the state applies to databases as the application implicitly opens them with references. Previously such commands accepted either one argument or an asterisk ("*") for all regions, but if supplied with a region string tended to do more than the specified region. (GTM-8922)

    • READ * and WRITE * operate correctly on files and sockets with a CHSET of UTF-16, UTF-16BE, or UTF-16LE. Previously READ * returned an incorrect codepoint and WRITE * produced an incorrect character or a BADCHAR error. (GTM-8923)

    • YottaDB handles socket errors on JOB process startup correctly. Previously if the INPUT and/or OUTPUT for a JOB were in a bad state (e.g. LISTEN) the JOB process could terminate with a KILLBYSIGSINFO1 (signal 11) and a core dump or hang indefinitely. (GTM-8924)

    System Administration

    • The Update Process logs record types with their corresponding type description; previously it only logged the integer type value. Note that it is possible, the change could disrupt code that parses the modified results. (GTM-5730)

    • MUPIP SET -JOURNAL in a replicated environment respects existing region sequence numbers, which aligns with the behavior of MUPIP BACKUP, which can also create new journal files. Previously, MUPIP SET -JOURNAL updated the region sequence numbers to the maximum of the sequence numbers for all regions specified for the command. (GTM-6747)

    • MUPIP INTEG produces a MUNOACTION error when the command specifies non-existent database; previously it produced an INTEGERRS message in this situation. (GTM-7872)

    • MUPIP JOURNAL -EXTRACT recognizes the -SEQNO=<sequence_number_list> qualifier. <sequence_number_list> is a comma separated list of sequence number(s) in decimal form. It specifies a list of sequence numbers to include or exclude in the journal extract. When a sequence number has a (~) prefix, -SEQNO excludes it from the journal extract. For replicated regions, EXTRACT -SEQNO uses replication sequence numbers, which may select records from multiple regions. For unreplicated regions, EXTRACT uses database transaction numbers, but specifying sequence number selection with more than one region produces a JNLEXTRCTSEQNO error. When the sequence number list contains a sequence number involved in a TP transaction, EXTRACT reports it in a broken transaction file when the result does not contain all regions, which is commonly the case without replication, and may be the case with replication when not all regions are available to the utility. Previously EXTRACT did not support record selection by sequence number. (GTM-8202)

    • The Source Server directs errors to the Source Server log file. Be sure to check the Source Server log; previously it directed errors to stderr, which meant that if it was started from a terminal and the terminal session closed, a subsequent error logged an inappropriate NOPRINCIO error and terminated the Server. (GTM-8576)

    • MUPIP JOURNAL -ROLLBACK ignores Idle regions (those that received their last updates a long time previously). GT.M V6.3-000 introduced a regression whereby idle regions were not appropriately excluded from determining the ROLLBACK turn-around point. The result was that ROLLBACK could adjust time so far back that the journal files are not present (say due to periodic removal to conserve space) which terminated the ROLLBACK. The operational work-around for this issue was to cut new journal files when deleting old journal files. (GTM-8859)

    • YottaDB appropriately removes extra slashes (/) from journal files and output files provided to the MUPIP JOURNAL -EXTRACT command. Previously, when extracting journal files, YottaDB kept any extra slashes in the journal file name or output file name, causing multi-slash paths to appear in the output of the extract. The workaround was to avoid using journal files and output files with successive slashes in their paths. (GTM-8860)

    • MUPIP SET -NOENCRYPTABLE can set the database encryptable flag to FALSE. Previously, after invoking MUPIP SET -ENCRYPTABLE attempting to undo that action failed unless the GNUPGHOME pointed to a valid directory and gtm_passwd was defined in the environment. This issue was only observed in the development environment, and was never reported by a user. MUPIP SET -ENCRYPTABLE now performs some basic encryption setup checks. To execute this command, GNUPGHOME must point to a valid directory and gtm_passwd must be defined in the environment. Previously, the command did not require these environment variables. (GTM-8900)

    • MUPIP JOURNAL -ROLLBACK and -RECOVER handle large amounts of journal data; while there are still limits, previously when they attempted to handle around 55 million updates or more they inappropriately failed with a GTM-F-MEMORY error. (GTM-8906)

    Other

    • YottaDB supports setting the M stack size using the gtm_mstack_size environment variable. This specifies the size of the M stack in KiB. No setting or a setting of 0 uses the default (272KiB). The minimum supported size is 25 KiB; YottaDB reverts values smaller than this to 25 KiB. The maximum supported size is 10000 KiB; YottaDB reverts values larger than this to 10000 KiB. (GTM-1042)

    • The MUPIP BACKUP command ignores aliases when executing system commands (cp, mv etc.) under the covers. Previously, aliases for cp, mv etc. (in one's .bashrc/.cshrc etc.) could cause the backup to use those alias versions of the cp/mv commands which might not work as desired. (GTM-3146)

    • MUPIP INTEG issues a DBKEYMX error in case of a long key name stored in the DT (Directory Tree); previously, it issued a INVSPECREC with no context. This issue was only observed in the development environment, and was never reported by a user. (GTM-7483)

    • When invoked at their QUIET or QCALL entrypoints, the %GCE, %GSE, %RCE, and %RSE utility routines report only globals or routines in which they find a match, for example: do QUIET^%GCE or do QCALL^%RSE. The QCALL entryref only exists in %RCE and %RSE. Previously these routines always reported every item they processed regardless of whether it contained a match. (GTM-8777)

    • LKE handles certain control characters appropriately; previously, for example, <CTRL-Z> caused a segmentation violation (SIG-11). (GTM-8791)

    • YottaDB addresses some issues identified by static analysis tools which appear to be obscure, and, in most cases, harmless. Previously an error with a source file could leak a file descriptor, and, in odd circumstances, trigger management could fail with a segmentation violation. These issues were only observed in the development environment, and were never reported by a user. (GTM-8870)

    • %PEEKBYNAME protects the variable str against inappropriate modification in the user symbol space; previously an error in %PEEKBYNAME, possibly caused by user input, would change the value of this variable. (GTM-8895)

    • The YottaDB reference encryption plugin library retries a failing decryption request once to mask a bug in GnuPG that caused spurious CRYPTKEYFETCHFAILED errors during process startup or re-encryption. GnuPG version 2.2.4 fixes the underlying bug, so upgrading to GnuPG 2.2.4 and libgcrypt 1.8.2 fixes the underlying issue. These problems were only seen in development and not reported by a customer. (GTM-8899)

    • The help facility for the utility programs MUPIP, DSE and LKE ignores control-C; previously if a user pressed <CTRL-C> while using help, the facility could exit with a harmless, but inappropriate, ENO256 error. (GTM-8909)

    • MUMPS processes which attempt to process a flush timer while executing an external call defer the timer processing until after the external call is complete. Previously, flush timers could interfere with non-reentrant routines used in the external call with undesired results. In particular, memory allocation operations in the external call can interfere with ASYNCIO setup in the flush timer, resulting in process hangs. (GTM-8926)

    More Information

    (Section Blank for this Release)

    Messages

    From GT.M

    CRYPTJNLMISMATCH, Encryption settings mismatch between journal file jjjj and corresponding database file dddd

    All Components Error: Encryption settings in the header of database file dddd do not match those stored in the header of journal file jjjj. This prevents access to the database. The most likely cause is inappropriate operator action such as replacing the current journal file with an older journal file.

    Action: Correct the error that caused the incorrect journal file to be pointed to by the database file. If the correct journal file has been inadvertently deleted, create new journal files with the -noprevjnl switch. Take a backup as soon as possible thereafter. Depending on your situation, you may need to refresh secondary instances.

    ENCRYPTCONFLT2, Message: A concurrent MUPIP REORG -ENCRYPT changed the encryption key for RRRR before the process could initialize it

    Run Time Warning: Due to a concurrent MUPIP REORG -ENCRYPT, a process was forced to defer encryption key initialization for region RRRR.

    Action: None. This information message is only important when followed by other encryption errors.

    INVSEQNOQUAL, Invalid SEQNO qualifier value xxxx

    MUPIP Error: This error indicates that MUPIP JOURNAL -EXTRACT -SEQNO command could not extract a journal file because an invalid SEQNO format was specified.

    Action: Enter a comma separated list of valid sequence numbers ('0' or positive integers) as value for the SEQNO qualifier. The format of the -SEQNO qualifier is -SEQNO=seqno1[,seqno2,seqno3.....] where seqno is the region sequence number in decimal format.

    JNLACCESS, Error accessing journal file jjjj

    Run Time Error: YottaDB sends this message to the system log followed by other messages detailing the failure. jjjj is the file-specification for the inaccessible journal. In most situations, this error occurs when the journal file storage runs out of disk space.

    Action: Review the accompanying message(s) for additional information. This means an error while trying to write to the journal file.

    JNLBADRECFMT, Journal Record Format Error encountered for file jjjj at disk address yyyy

    MUPIP/Run Time Error: This indicates that an attempt to open a journal file encountered an invalid record.

    Action: Report the entire incident context to your YottaDB support channel.

    JNLCYCLE, Journal file jjjj causes cycle in the journal file generations of database file dddd

    MUPIP Error: This indicates that MUPIP encountered journal file jjjj causing cycle in the journal file generations of database file dddd; that is following the back-pointers in the journal files can wind up repeatedly finding the same journal file.

    Action: Contact your YottaDB support channel with appropriate log messages.

    JNLDBERR, Journal file jjjj does not correspond to database dddd

    Run Time Error: This indicates that YottaDB could not open journal file jjjj for database file dddd because the journal file header identifies itself as belonging to a different database file that does not exist in the system.

    Action: Use a MUPIP SET command with the qualifier JOURNAL to create a journal file that matches the database.

    JNLDISABLE, Specified journal option(s) cannot take effect as journaling is DISABLED on database file dddd

    MUPIP Warning: This indicates that none of the specified journal option(s) in MUPIP SET -JOURNAL or MUPIP BACKUP command took effect, because journaling was found DISABLED on database file dddd.

    Action: Revise the selection qualification to exclude the DISABLED region(s) or, if appropriate, enable journaling on those regions.

    JNLEXTEND, Journal file extension error for file jjjj.

    Run Time/MUPIP Error: Journal file jjjj failed to extend. If the environment is not configured for instance freeze, this causes journaling to be turned off for the region.

    Action: Review the accompanying message(s) and take appropriate action. If the environment is not configured for instance freeze, perform a MUPIP BACKUP, that turns journaling on again, to reestablish durability.

    JNLEXTR, Error writing journal extract file: xxxx

    MUPIP Error: This indicates that an error was encountered while trying to write to either the JNL EXTRACT file or lost-transaction file or broken-transaction file as part of a MUPIP JOURNAL command.

    Action: Review the accompanying message(s) for additional information.

    JNLEXTRCTSEQNO, Journal Extracts based on sequence numbers are restricted to a single region when replication is OFF

    MUPIP Error: When replication is enabled YottaDB applies a uniform set of sequence numbers across regions, but when it is not in use each region has its own set of sequence numbers, and, in that case, MUPIP only works on a region at a time.

    Action: If you need cross region sequence numbers, start replication with at least a passive Source Server; otherwise use one MUPIP JOURNAL -EXTRACT command for each region when using the -SEQNO qualifier.

    JNLFILOPN, Error opening journal file jjjj for database file dddd

    Run Time/MUPIP Error: This indicates that YottaDB was unable to open journal file jjjj for the specified database file dddd. The Source Server exits with a JNLFILOPN message after six failed attempts to open journal files.

    Action: Check the authorizations for the user of the process and the health of the file system holding the journal file.

    JNLFLUSHNOPROG, No progress while attempting to flush journal file jjjj

    Run Time Warning: Indicates processes needing space in the journal buffers were unable to write journal jjjj because even though multiple processes have controlled the resource, this process has not been able to flush records. JNLPROCSTUCK means one process is hogging, while this message means more than one process has tried but none have succeeded. Might indicate a clogged disk subsystem on which journal file JJJJ resides.

    Action: Check the log file for other journaling related messages. Consider balancing disk subsystem load.

    JNLFSYNCLSTCK, Journaling fsync lock is stuck in journal file jjjj

    Run Time Error: A resource controlling journal file actions has remained unavailable for a long period.

    Action: Check on the condition of the process identified in the associated messages.

    JNLINVALID, jjjj is not a valid journal file Region: rrrr

    MUPIP Error: This indicates that YottaDB could not open journal file jjjj, due to an error that is detailed in the accompanying previous message(s). While trying to create a new journal file for the same region it encountered errors. rrrr is the region name associated with the journal.

    Action: Review the accompanying error message(s) to determine the cause of the failure of the new journal file creation. After the cause is resolved, to reestablish durability, perform a MUPIP BACKUP that turns journaling back on.

    JNLNAMLEN, Journal file jjjj: for database file dddd exceeds maximum of MMMM

    MUPIP Error: This indicates that the file-specification jjjj of the journal for database file dddd exceeds the maximum supported length of MMMM.

    Action: Modify the journal file-specification to adhere to the file length restrictions.

    JNLNOCREATE, Journal file jjjj not created

    MUPIP/Run Time Error: This indicates that YottaDB could not create journal file jjjj.

    Action: Review the accompanying message(s) for additional information.

    JNLORDBFLU, Error flushing database blocks to dddd. See related messages in the operator log

    MUPIP Error: This message indicates that hardening journal or database records could not be completed due to an error. The operator log should contain one or more accompanying messages indicating the cause of the error.

    Action: Verify the normal state of the file system and appropriate permissions of the database and journal files. Report the entire incident context to your YottaDB support channel along with any operator log messages within the same time frame.

    JNLREADEOF, End of journal file encountered for jjjj

    MUPIP/Run Time Error: This indicates that MUPIP JOURNAL or a run-time journal operation encountered the end-of-file for the journal file jjjj, before it completed processing.

    Action: This error indicates an improperly closed journal file. Restart journaling with a MUPIP BACKUP -NEWJNLFILES or a MUPIP SET -JOURNAL and report all available circumstance to those responsible for supporting your database operations.

    JNLRECFMT, Journal file record format error encountered

    MUPIP Error: This indicates that MUPIP JOURNAL encountered an invalid record in the journal file.

    Action: In the event of YottaDB issuing this error message, use MUPIP BACKUP to ensure durability by creating a fresh set of journals consistent with the database. Else, to resume operation, restore the database from the last backup and play forward the updates using the appropriate MUPIP JOURNAL command. As soon as possible, report the entire incident context with information from the operator log and any other relevant information to your YottaDB support channel.

    JNLSPACELOW, Journal file jjjj nearing maximum size, nnnn blocks to go

    Run Time Information: This indicates that the journal file jjjj is approaching the maximum size specified for it. The system creates a new journal file when the limit is reached.

    Action: None required except as part of monitoring journaling space requirements or when operational practice uses this as a trigger to intervene in journal file management.

    JNLSWITCHSZCHG, Journal AUTOSWITCHLIMIT [aaaa blocks] is rounded down to [bbbb blocks] to equal the sum of journal ALLOCATION

    MUPIP Information: This indicates that the specified AUTOSWITCHLIMIT value was rounded down as little as possible to make it aligned to the ALLOCATION + a multiple of EXTENSION. Any subsequently created journal file will use this value for AUTOSWITCHLIMIT.

    Action: If the rounded value is inappropriate examine the alignsize, allocation and extension values and choose a more suitable value.

    JNLSWITCHTOOSM, Journal AUTOSWITCHLIMIT [aaaa blocks] is less than journal ALLOCATION [bbbb blocks] for database file dddd

    MUPIP Error: This indicates that the value of AUTOSWITCHLIMIT specified in a MUPIP SET JOURNAL command is less than the default or specified value of ALLOCATION. This error also indicates that the AUTOSWITCHLIMIT value specified was greater or equal to the ALLOCATION but in turn got rounded down, and this rounded down value is lesser than the ALLOCATION.

    Action: Specify a higher value of AUTOSWITCHLIMIT.

    JNLWRERR, Error writing journal file jjjj. Unable to update header Region: yyyy

    Run Time/MUPIP Error: This indicates that YottaDB encountered an error while updating the journal file header as part of trying to open the journal file.

    Action: Review the accompanying message(s) for detail on the cause of the error. YottaDB automatically closes the current journal file and creates a new one. To reestablish durability, perform MUPIP BACKUP to create a fresh set of journals consistent with the database.

    MSTACKSZNA, User-specified M stack size of SSSS KiB not appropriate; must be between LLLL KiB and MMMM KiB; reverting to VVVV KiB

    Run Time Information: The gtm_mstack environment variable species an M stack size outside the range YottaDB supports, where LLLL and MMMM are the lower and upper bounds respectively; VVVV is the value actually used.

    Action: None required immediately as the process operates with the reported size M stack, however it would be preferable to eliminate such messages by setting gtm_mstack to a value in the supported range.

    PREMATEOF, Premature end of file detected

    MUPIP/Run Time Error: A file read or write detected an end-of-file when it was expecting additional records.

    Action: Analyze accompanying messages for the type of file on which the operation failed. If the operation was a MUPIP LOAD, refer to the About this Manual section on MUPIP LOAD errors. If the circumstances warrant, contact the group responsible for database integrity at your operation with all the diagnostic context you can gather.

    SYSUTILCONF, Error determining the path for system utility. tttt

    Run Time Error: tttt represents text describing details of an issue finding a POSIX function that it needed.

    Action: Check for aliases or environment variables related to paths that might be interfering with YottaDB's ability to invoke functions.

    Tarball Hashes

    sha256sum File
    dab80777a1d4d5be52f7c5d0749d8701f383aa8601eb9037884b14512d2b854d yottadb_r122_linux_armv6l_pro.tgz
    62dce638fee3fbac38de2c0f495730ab52abd05bf622d6ab7c89c98718dd5185 yottadb_r122_linux_armv7l_pro.tgz
    7c187371924429e30d3254cd17fc1b9d9fb3ac3792254880bec250be728ef056 yottadb_r122_linux_x8664_pro.tgz
    ac4cc25b1d1de4e3571aa8a5b448a584931095f9e7f1a9208c034ecc42d6f7f5 yottadb_r122_rhel7_x8664_pro.tgz
    44678b658fe6d1396b02250c837826c97aaf2706d9963a70aac6d0ea78085c9b yottadb_r122_src.tgz

    Legal Stuff

    Copyright © 2018 YottaDB LLC

    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.

    This document contains a description of YottaDB and the operating instructions pertaining to the various functions that comprise the software. This document does not contain any commitment of YottaDB LLC. YottaDB LLC believes the information in this publication is accurate as of its publication date; such information is subject to change without notice. YottaDB LLC is not responsible for any errors or defects.

  • V6.3-004
    83bc0ab9 · GT.M V6.3-004 ·
  • r1.20

    yottadb_r120_linux_x8664_pro.tgz

    yottadb_r120_rhel7_x8664_pro.tgz

    yottadb_r120_linux_armv7l_pro.tgz

    yottadb_r120_linux_armv6l_pro.tgz

    yottadb_r120_src.tgz

    YottaDB r1.20

    Release Note Revision History

    Revision Date Summary
    1.00 March 29, 2018 r1.20 Initial Release

    Contact Information

    YottaDB LLC

    40 Lloyd Avenue, Suite 104 Malvern, PA 19355, USA info@yottadb.com +1 (610) 644-1898

    Support

    Customers

    Contact your YottaDB support channel.

    Others

    For free (to you) support from members of communities who run widely available applications on YottaDB, please use an application-specific list where appropriate.

    r1.20

    Overview

    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:

    Highlights from the upstream V6.3-003A code base, thanks to the GT.M team include:

    As is the case in every release, YottaDB r1.20 brings other enhancements, e.g., callin when an application is already inside a transaction processing fence, and sending syslog messages to stderr when there is no syslog, as well as fixes to issues as detailed below.

    As always, there as other enhancements and fixes, as noted below. See our Get Started page to use YottaDB.

    Platforms

    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.

    CPU Architecture Supported OS Version(s) Notes
    64-bit x86 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 info@yottadb.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 info@yottadb.com 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.

    Getting Started

    See our Get Started page to use YottaDB.

    We strongly recommend that you install YottaDB r1.20 in a newly created directory, different from those of YottaDB r1.10 and any GT.M versions you may have installed on the system.

    Removing an Installed YottaDB Release

    Assuming $ydb_dist points to the directory where YottaDB is installed:

    • Cleanly shut down all application processes using that release.
    • Execute mupip rundown && mupip rundown -relinkctl
    • Ensure that there are nogtcm* or gtmsecshr processes active.
    • Use sudo lsof | grep $ydb_dist to ensure there are no open files.
    • Delete the directory with sudo rm -rf $ydb_dist

    Upgrading to YottaDB r1.20

    As YottaDB r1.20 is upward compatible from both YottaDB r1.10 and GT.M V6.3-003/-003A, the minimal upgrade steps are:

    • Install YottaDB r1.20.
    • Recompile any object code, and recreate shared libraries where appropriate.
    • If you are using encryption, compile and install the reference implementation plugin or your customized plugin.
    • Cleanly shut down the application and ensure that the database files are shut down using mupip rundown from the prior release.
    • Switch journal files with the new YottaDB release.
    • Start using the new YottaDB release.

    To upgrade from older GT.M releases, first upgrade to GT.M V6.0-000 or later and follow the steps above, or contact your YottaDB support channel for assistance and guidance.

    A more sophisticated upgrade technique is:

    • Install YottaDB r1.20.
    • Create a new replicated instance of your application (on the same system or a different system).
    • Assuming the existing instance is A, and the new instance is B, start replicating from A to B.
    • Once B catches up, switchover so that B is in a primary role replicating to A.
    • Once you are satisfied with B, remove (or upgrade) A.

    Change History

    r1.20

    ID Category Summary
    (https://github.com/YottaDB/YottaDB/issues/23) Admin Change references to GT.M into references to YottaDB - shared libraries
    (https://github.com/YottaDB/YottaDB/issues/33) Other Reduce footprint of engine
    (https://github.com/YottaDB/YottaDB/issues/59) Data Directly access YottaDB data from C
    (https://github.com/YottaDB/YottaDB/issues/77) Other Fix reporting glitch in Indirection cache hit ratio when cache hits are greater than 43 million
    (https://github.com/YottaDB/YottaDB/issues/80) Data Improve performance of large local arrays
    (https://github.com/YottaDB/YottaDB/issues/83) Language Recall history for READ command to match direct mode
    (https://github.com/YottaDB/YottaDB/issues/85) Data Stringpool garbage collector performance enhancements
    (https://github.com/YottaDB/YottaDB/issues/90) Language YottaDB correctly runs M programs which had PATNOTFOUND errors at compile time
    (https://github.com/YottaDB/YottaDB/issues/94) Admin Ignore gtm_dist environment variable
    (https://github.com/YottaDB/YottaDB/issues/97) Admin Customize YottaDB message prefix
    (https://github.com/YottaDB/YottaDB/issues/99) Other ydbinstall.sh correctly reports "YottaDB" or "GT.M" on successful installation
    (https://github.com/YottaDB/YottaDB/issues/100) Language Timeouts specifying sub-millisecond resolutions time out correctly
    (https://github.com/YottaDB/YottaDB/issues/109) Admin ydb_repl_filter_timeout environment variable to control replication filter timeout
    (https://github.com/YottaDB/YottaDB/issues/115) Admin Environment variables ydb_dbglvl, ydb_gbldir, ydb_maxtptime are initialized
    (https://github.com/YottaDB/YottaDB/issues/118) Admin MUPIP SET JOURNAL issues JNLCRESTATUS error when unable to rename current journal file
    (https://github.com/YottaDB/YottaDB/issues/120) Language $ZEOF set correctly for files in /proc filesystem
    (https://github.com/YottaDB/YottaDB/issues/122) Admin Simpler MUPIP JOURNAL ROLLBACK recovery following abnormal termination of process inside transaction commit logic
    (https://github.com/YottaDB/YottaDB/issues/126) Other ydb script to run YottaDB, and files ydb_env_set & ydb_env_unset to source to set and clear environment
    (https://github.com/YottaDB/YottaDB/issues/136) Admin Establish replication connections more efficiently in an edge case
    (https://github.com/YottaDB/YottaDB/issues/141) Language ZSTEP OVER and ZSTEP OUTOF work correctly across extrinsic function returns using QUIT @ syntax
    (https://github.com/YottaDB/YottaDB/issues/143) Other libyottadbutil.so created when YottaDB for Linux/ARM is installed with UTF-8 support
    (https://github.com/YottaDB/YottaDB/issues/145) Language DIVZERO error correctly issued in certain edge cases of dividing by zero
    (https://github.com/YottaDB/YottaDB/issues/150) Admin Fixes to multiple issues affecting databases with READ_ONLY set
    (https://github.com/YottaDB/YottaDB/pull/160) Other Use ydb and ydb_env_set scripts instead of gtm and gtmprofile scripts, and ydb_prefix environment variables
    (https://github.com/YottaDB/YottaDB/pull/161) Other Change relative path to ydbmerrors to use src directory
    (https://github.com/YottaDB/YottaDB/pull/162) Other Create Docker Images
    (https://github.com/YottaDB/YottaDB/issues/169) Data Certain edge cases of nested triggers work correctly without abnormal process termination
    (https://github.com/YottaDB/YottaDB/issues/184) Language C program that invokes call-in leaves terminal characteristics in sane state on exit
    (https://github.com/YottaDB/YottaDB/issues/186) Language EXCEPTION handler correctly executes when Ctrl-C entered
    (https://github.com/YottaDB/YottaDB/issues/188) Language Call-ins permitted inside TP
    (https://github.com/YottaDB/YottaDB/issues/189) Admin Send messages to stderr if syslog not present or not functional

    Admin

    • 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)
    • Multiple issues with READ_ONLY features from GTM-8735 in the upstream code base that generated errors while accessing the help database were addressed and corrected. More details: (https://github.com/YottaDB/YottaDB/issues/150)
    • 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)

    Data

    • The YottaDB engine is directly accessible using a C-callable API. See https://docs.yottadb.com/MultiLangProgGuide/index.html for user documentation. (https://github.com/YottaDB/YottaDB/issues/59)
    • Local arrays with large number of subscripts scale much better. When the number of nodes in a local array is in the millions, node creation time is now noticeably faster (https://github.com/YottaDB/YottaDB/issues/80)
    • 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)

    Language

    • 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)

    Other

    • The YottaDB install directory size is 14-15Mb (down from 34Mb in prior versions). (https://github.com/YottaDB/YottaDB/issues/33)
    • 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)
    • The YDB_SOURCE_DIR cmake variable is used to get the path to ydbmerrors.h instead of a hardcoded relative path (https://github.com/YottaDB/YottaDB/pull/161)
    • A Docker image to build and deploy a YottaDB runtime environment is available. (https://github.com/YottaDB/YottaDB/pull/162)

    GT.M V6.3-003A

    ID Category Summary
    GTM-8880 Language Fix issue with (non-default) Standard Boolean evaluation with side-effects
    and certain patterns
    GTM-8887 Other Fix rare timer issue
    GTM-8889 Other Prevent UNDEF error after <CTRL-C> within ZHELP navigation

    GT.M V6.3-003

    ID Category Summary
    GTM-4212 Admin MUPIP better deals with over length file names
    GTM-6115 Language Please see GTM-8792
    GTM-7986 Language Warning on implicit wrapping of source lines exceeding maximum supported length
    GTM-8182 DB Allow updating globals belonging to different instances
    GTM-8186 Language Accept offset alone for an entryref in DO, GOTO and ZGOTO
    GTM-8587 Language Maintain $DEVICE and $KEY for all supported devices
    GTM-8617 Admin MUPIP SET supports N[ULL_SUBSCRIPTS] and STD[NULLCOLL] qualifiers.
    GTM-8680 DB LOCK Improvements
    GTM-8732 Admin Better validation for MUPIP REPLICATE -LOG_INTERVAL and -HELPER, and MUPIP SET -DEFER_TIME
    GTM-8735 Admin READ_ONLY characteristic to prevent state changes to MM databases
    GTM-8754 Other Prevent odd ASYNCIO deadlock
    GTM-8767 Admin MUPIP SET -HARD_SPIN_COUNT and -SPIN_SLEEP_MASK support
    GTM-8769 Language Syntax check $ETRAP, $ZSTEP, $ZTRAP, and EXCEPTION when specified
    GTM-8779 Admin Freeze Notification
    GTM-8780 Language Fix $SELECT() handling of certain syntax errors
    GTM-8781 Other Prevent memory leak in ZSYSTEM
    GTM-8786 Language $NAME() of a naked reference returns any current extended reference
    GTM-8787 Admin MUPIP JOURNAL -EXTRACT='-stdout' doesn't explode at termination if stdout is gone
    GTM-8788 Language The compiler excludes BLKTODEEP lines from the object files
    GTM-8789 Language Prevent NEW $ZGBLDIR from setting up an Update Process failure
    GTM-8790 DB Retain any extended first reference in $REFERENCE when sharing statistics
    GTM-8792 Language Prevent keys that exceed the supported maximum string length
    GTM-8794 Admin MUPIP RUNDOWN -OVERRIDE works on a non-MUPIP backup made during an Instance Freeze
    GTM-8795 DB Journal Updates promptly during MUPIP FREEZE -ONLINE
    GTM-9796 DB Improved error handling during TP and mini transaction commits
    GTM-8797 Admin Installation script fixes
    GTM-8798 Admin MUPIP ENDIANCVT converts Mutex Queue Slots
    GTM-8799 Other Improve performance for a pattern of local variable creation
    GTM-8801 Other cmake build produces appropriate support for the ^%YGBLSTATS utility.
    GTM-8804 Language ZSHOW "T" option to return summary for ZSHOW "GL"
    GTM-8805 DB Fix to havesting of LOCKs abandoned by an abnormally terminated process
    GTM-8832 Language Appropriately report NUMOFLOW for string literal with a huge value when used as a number
    GTM-8839 Language $DEVICE shows the full error message
    GTM-8840 Admin Normalized gtmsecshr message severities
    GTM-8842 Admin ZBREAK and ZSTEP restricted in triggers when TRIGGER_MOD is restricted
    GTM-8844 Admin Restriction available for HALT and ZHALT; ZGOTO 0 can return a non-zero status to the shell
    GTM-8846 Admin GT.M accepts multi-slash journal file names
    GTM-8847 Language Provide a way to detect and limit process private heap storage
    GTM-8849 Other Help databases built with make files have QDBRUNDOWN and NOGVSTATS characteristics
    GTM-8850 DB Allow process exit when MUPIP FREEZE -ONLINE is in place
    GTM-8854 Language Compiler handles a syntax error after a literal postconditional that's FALSE
    GTM-8855 Other Prevent memory leak from an error locating a global directory
    GTM-8856 Language Defer failing evaluations of literal pattern matches to run time
    GTM-8857 Language Improve error detection for certain pattern match cases
    GTM-8858 DB Improve available information in cases of apparent database integrity issues
    GTM-8859 Admin MUPIP ROLLBACK handles idle regions better
    GTM-8866 Language Prevent timeouts with more than three decimal digits from being too long
    GTM-8873 DB Prevent occasional $ORDER(,-1) problem

    More Information

    (Section Blank for this Release)

    Messages

    From YottaDB

    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.

    FATALERROR1, Fatal error raised. Generating core and terminating process. Error: .

    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 the generation of a core file. 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.

    FATALERROR2, Fatal error raised. Bypassing core generation and terminating process. Error:

    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.

    From GT.M

    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.

    REPLINSTACC, Error accessing replication instance file xxxx

    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.

    Tarball Hashes

    sha256sum File
    cd26897549405b33e63966df52aefb8ad581afd1633db1cb2723ff2c12acce25 yottadb_r120_linux_armv6l_pro.tgz
    8993fbb7300cb732da06e90bc7cb1334e9ab5318da7d0b7427900be8919aa640 yottadb_r120_linux_armv7l_pro.tgz
    6e7bf4c1fa0b12e29fa2b0e1629bfdaaeebd0541c458eaf561d5676d1f0fc5e6 yottadb_r120_linux_x8664_pro.tgz
    e32dc5ffbdd1e8fd17d4ed2f1df97145f05d5748489f2b5d8322ad9ee33008ce yottadb_r120_rhel7_x8664_pro.tgz
    f4310725ff72ff6bd5da41fc0b3eaf5ab918978ce33d08878ed717c1d1cf04c4 yottadb_r120_src.tgz

    Legal Stuff

    Copyright © 2018 YottaDB LLC

    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.

  • V6.3-003A
    a9fb63ac · GT.M V6.3-003A ·
  • V6.3-003
    63ea0f73 · GT.M V6.3-003 ·
  • r1.10

    yottadb_r110_src.tgz

    YottaDB r1.10

    Release Note Revision History

    Revision Date Summary
    1.05 October 27, 2017 Updated tarballs with new ydbinstall.sh and configure scripts (address additional fallout because the installation automation could not be fully tested in advance), update sha256sums
    1.04 October 26, 2017 Add example of installation with UTF-8 support
    1.03 October 26, 2017 Update ydbinstall.sh for correct installation directory default (ydbinstall.sh could not be fully tested without an actual r1.10 release), rebuild tarballs, update sha256sums
    1.02 October 26, 2017 Add sha256sum for ydbinstall.sh
    1.01 October 26, 2017 Update tarballs, update sha256sums, correct date
    1.00 October 26, 2017 r1.10 Initial release

    Contact Information

    YottaDB LLC

    40 Lloyd Avenue, Suite 104 Malvern, PA 19355, USA info@yottadb.com +1 (610) 644-1898

    Support

    Customers

    Contact your YottaDB support channel.

    Others

    For free (to you) support from members of communities who run widely available applications on YottaDB, please use an application-specific list where appropriate.

    r1.10

    Overview

    YottaDB r1.10 is a major release that adds support for Linux on ARM CPUs. Enhancements in this release include reverse $query() - $query(,-1) - as well as optimizations for certain $order() use cases. The ydbinstall.sh script automatically downloads and installs the current YottaDB release. As always, there as other enhancements and fixes, as noted below.

    YottaDB r1.10 is built on (and except as noted, upward compatible with) both YottaDB r1.00 and GT.M V6.3-002.

    We would like to acknowledge and thank Steve Johnson (@sljohnson1) and Sam Habiel (@shabiel) for making the ARM port possible.

    Platforms

    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.

    CPU Architecture Supported OS Version(s) Notes
    64-bit x86 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.10 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 info@yottadb.com 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.

    Installation

    The simplest way to install the current release of YottaDB for your platform is the ydbinstall.sh script. Download it, make the file executable, and execute it:

    • sudo ./ydbinstall.sh downloads and installs the current YottaDB release with a reasonable set of defaults.
    • sudo ./ydbinstall.sh --utf8 default downloads and installs the current YottaDB release with UTF-8 support, using the default ICU version on the operating system.
    • ./ydbinstall.sh --help prints a list of command line options.
    • sudo ./ydbinstall.sh --verbose outputs information as it executes, for troubleshooting purposes (for example if Internet access is stalled by a proxy server, the script will print the wget command it is trying to execute and hang).

    You can also download the YottaDB binary distribution tarball for your platform from the release notes for the latest release, unpack it, change to the directory with the unpacked files, and (a) run the ydbinstall therein or (b) install the historical way per the instructions for installing GT.M in the Installation Procedure section of Chapter 2 (Installing GT.M) in the GT.M Administration and Operations Guide.

    We strongly recommend that you install YottaDB r1.10 in a newly created directory, different from those of YottaDB r1.00 and any GT.M versions you may have installed on the system.

    Removing an installed YottaDB release

    Assuming $gtm_dist points to the directory where YottaDB is installed:

    • Cleanly shut down all application processes using that release.
    • Execute mupip rundown && mupip rundown -relinkctl.
    • Ensure that there are nogtcm* or gtmsecshr processes active.
    • Use sudo lsof | grep $gtm_dist to ensure there are no open files.
    • Delete the directory with sudo rm -rf $gtm_dist.

    Upgrading to YottaDB r1.10

    As YottaDB r1.10 is upward compatible from both YottaDB r1.00 and GT.M V6.3-002, the minimal upgrade steps are:

    • Install YottaDB r1.10.
    • Recompile any object code, and recreate shared libraries where appropriate.
    • If you are using encryption, compile and install the reference implementation plugin or your customized plugin.
    • Cleanly shut down the application and ensure that the database files are shut down using mupip rundown from the prior release.
    • Switch journal files with the new YottaDB release.
    • Start using the new YottaDB release.

    To upgrade from older GT.M releases, first upgrade to GT.M V6.0-000 or later and follow the steps above, or contact your YottaDB support channel for assistance and guidance.

    A more sophisticated upgrade technique is:

    • Install YottaDB r1.10.
    • Create a new replicated instance of your application (on the same system or a different system).
    • Assuming the existing instance is A, and the new instance is B, start replicating from A to B.
    • Once B catches up, switchover so that B is in a primary role replicating to A.
    • Once you are satisfied with B, remove (or upgrade) A.

    Change History

    r1.10

    YottaDB r1.10 includes the following changes from YottaDB r1.00.

    Id Category Summary
    #8 Other gtmgblstat.xc in binary distribution package
    #10 Language Support reverse $query for globals and locals
    #11 Database Speed up $order(gvn,-1) where gvn is of the form ^xxx("")
    #12 Database Repeated calls to $order(^xxx("")) run faster
    #19 Other gtmprofile sets "YDB>" as default prompt
    #25 Language Issue MAXSTRLEN error if length of $query(lvn) exceeds maximum string length
    #30 Operations Source server behaves correctly (no SIG-11) if started with an external filter followed by a deactivate and shutdown
    #32 Language Improve efficiency of C to M calls
    #44 Utilities %HD works on hexadecimal numbers with a 0x or 0X prefix
    #47 Database OFRZAUTOREL message includes full path of database file
    #61 Other Port to Linux on ARM
    #66 Other Make it easier to install YottaDB from a source or binary tarball

    In addition to the changes described above, YottaDB r1.10 includes changes released in GT.M V6.3-002 with one exception.

    More Information

    (Section blank for this release)

    Messages

    OFRZAUTOREL

    This is an existing message with updated text. The Action remains unchanged.

    OFRZAUTOREL, Online Freeze automatically released for database file aaaa

    Operator log Warning: A process needed to modify the database file aaaa, which had an Online Freeze, but with AutoRelease selected. The process continued normally, modifying the file.

    Action: Discard any database copy or snapshot made after the Online Freeze, as its contents are suspect. Perform a MUPIP FREEZE -OFF to clean up the prior Online Freeze. If the AutoRelease behavior is not desired, try again with MUPIP FREEZE -ON -ONLINE -NOAUTORELEASE. If the cause of the AutoRelease is unclear, report this and the accompanying ERRCALL message to your YottaDB support channel.

    QUERY2

    QUERY2, Invalid second argument to $QUERY. Must be -1 or 1

    Run Time Error: This indicates that the second argument to a $QUERY function was not a 1 or -1, which are the only permitted values.

    Action: Modify the application code to provide a correct value.

    From GT.M

    In addition to the error messages added by YottaDB, error messages from GT.M V6.3-002 are also present in YottaDB r1.10.

    Tarball hashes

    sha256sum File
    ed6b38f96c864a36da0b58e0f991a452e00ffb155c58f50beebaab41e05ef363 ydbinstall.sh
    6f6f8eb36a307847e7becb6fd36b2281207352d33f921e16622c0933b7f648ec yottadb_r110_linux_armv7l_pro.tgz
    52e7160dce7fefb1ec91812012084e113c81e0af7e9c4baa9f560bc038ceecc3 yottadb_r110_linux_x8664_pro.tgz
    3c4f5ec09f03de42c845c2d0800fb91249be92f8699a10793f230c4d341b7d02 yottadb_r110_rhel7_x8664_pro.tgz
    2ee6d1c28b5bbb39dbfe2b52ad2fbef9327edcf462127ce31491d66ef06b7bf4 yottadb_r110_src.tgz

    Legal Stuff

    Copyright © 2017 YottaDB LLC

    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.

    This document contains a description of YottaDB and the operating instructions pertaining to the various functions that comprise the software. This document does not contain any commitment of YottaDB LLC. YottaDB LLC believes the information in this publication is accurate as of its publication date; such information is subject to change without notice. YottaDB LLC is not responsible for any errors or defects.

  • V6.3-002
    2ef796b0 · V6.3-002 ·
  • r1.00

    YottaDB r1.00

    Release Note Revision History

    Revision Date Summary
    1.00 July 4, 2017 r1.00 - Initial release

    Contact Information

    YottaDB LLC Support
    40 Lloyd Avenue, Suite 104 Customers: Contact your YottaDB support channel
    Malvern, PA 19355, USA All others: See below

    For free (to you) support from members of communities who run widely available applications on YottaDB, please use an application-specific list where appropriate.

    r1.00

    Overview

    YottaDB r1.00 is the first YottaDB release, intended to validates the development processes of production grade releases of YottaDB LLC. Each YottaDB release is built on a GT.M release, and on the preceding YottaDB release (this first release of course has no preceding YottaDB release). Except for bugs and fixes, which by their nature are not upward compatible, our intent is for each YottaDB release to be functionally and operationally upward compatible with both its YottaDB and GT.M predecessors. The release notes call your attention to any changes that we think you should review with possible compatibility issues in mind.

    Platforms

    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.

    Platform Supported Version(s) Notes
    x86 GNU/Linux Ubuntu 16.04 LTS Recent releases of major Linux distributions (including Red Hat Enterprise Linux 7.x) with contemporary versions of kernels, glibc and ncurses are Supportable. Running on Arch Linux requires the ncurses5-compat-libs package to be installed.

    Installation

    Follow the instructions for installing GT.M in the Installation Procedure section of Chapter 2 (Installing GT.M) in the GT.M Administration and Operations Guide.

    Upgrading to YottaDB r1.00

    As YottaDB r1.00 is an upward compatible alternative to GT.M V6.3-001A, install YottaDB and follow the instructions in the GT.M V6.3-001A Release Notes.

    Change History

    r1.00

    Id Category Summary
    #2 Language A way for application code to determine whether it is running on YottaDB or GT.M
    #3 Language Two argument $[z]length to use $[z]piece cache
    #4 Other Change default direct mode prompt to make it easier for users to know whether they're interacting with YottaDB or GT.M

    More Information

    (Section blank for this release)

    Messages

    (Section blank for this release)

    Legal Stuff

    Copyright © 2017 YottaDB LLC

    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.

    This document contains a description of YottaDB and the operating instructions pertaining to the various functions that comprise the software. This document does not contain any commitment of YottaDB LLC. YottaDB LLC believes the information in this publication is accurate as of its publication date; such information is subject to change without notice. YottaDB LLC is not responsible for any errors or defects.

  • V6.3-001A
    634c33c6 · V6.3-001A ·
  • V6.3-001
    dab2fc11 · V6.3-001 ·
  • V6.3-000A
    cd9b7b01 · V6.3-000A ·
  • V6.3-000
    60e7e2d7 · V6.3-000 ·
  • V6.2-002A
    b7137a20 · V6.2-002A ·
  • V6.2-002
    fd22a532 · V6.2-002 ·
  • V6.2-001
    39d304f7 · V6.2-001 ·
  • V6.2-000
    3ee7bd62 · V6.2-000 ·