The YottaDB Message and Recovery Procedures Reference Manual describes the meaning of messages issued by YottaDB components, including the M compiler, the run-time system and utility programs.

This manual is organized alphabetically according to the message identifier. The meaning of each message is provided, as well as suggestions for locating and addressing the cause of error-type messages.

## Intended Audience¶

This manual is for programmers and system managers who use YottaDB.

## Purpose of the Manual¶

The YottaDB Message and Recovery Procedures Reference Manual helps you understand and act on YottaDB messages. This manual complements the other YottaDB manuals.

## How to Use This Manual¶

The YottaDB Message and Recovery Procedures Reference Manual is intended to be used primarily to determine the nature of a message and interpret its meaning. Therefore, messages are listed in alphabetical order, according to the mnemonic that precedes them. Cross references to additional information are provided in individual entries, as appropriate.

## Conventions Used in this Manual¶

YottaDB messages are identified by a signature of the form YDB-s-abcdef where -s- is a severity indicator and abcdef is an identifier. The severity indicators are: -I- for informational messages, -W- for warnings, -E- for errors and -F- for events that cause a YottaDB process to terminate abnormally. For more information on monitoring YottaDB messages, refer to “Appendix B: Monitoring YottaDB Messages” in the Administration and Operations Guide.

Each entry in this manual is presented in the following format as illustrated by the NOTPRINCIO message.

1. NOTPRINCIO
2. NOTPRINCIO, Output currently directed to device xxxx
3. Run Time Warning: This message displays the current device xxxx when it is not the principal device and the process enters Direct Mode.
4. Action: To redirect all I/O to the terminal, note the current device or save it in a temporary variable and USE \$P. If you decide to resume program execution, remember to restore the current device with a USE command.


where

• 1 indicates the unique mnemonic preceding the error message and is the component by which the entry is alphabetized.
• 2 indicates the mnemonic and the actual message that accompanies it.
• 3 indicates the YottaDB component that generates the message, its severity, and a short description of its implication(s).
• 4 suggests action(s) to take when the message appears.

This manual can be used with YottaDB on any of its supported platforms. However, because in some instances the suggested actions are more useful when platform-specific information is provided, the following conventions are used as necessary.

Although the terms “host shell command” and “file-specification” have some platform-specification connotations, they are used in their most generic sense throughout this manual. The former describes commands that originate from the host operating system, rather than from YottaDB. The latter may refer to a simple file name or a full directory path to that file.

An “initiating instance” is always the instance that first records a transaction (including non-TP mini-transactions). A “replicating instance” is always the instance following the action of an “originating instance”, previously called “root primary”. We have called secondaries that replicate propagating primaries, but they are not originating instances.

## Following Up on Suggested Actions¶

When the suggested action is to “Report the error to the group responsible for database integrity at your operation,” you may also refer to the Maintaining Database Integrity chapter in the Administration and Operations Guide.

For information about utility-generated messages, refer to the chapter that describes that utility in the Administration and Operations Guide.

If a MUPIP LOAD error occurs, ensure that the proper media is loaded and that the command input includes the proper file-specification.

If the input file is FORMAT=GO or ZWR, the database should contain the correct content to the point where the failure occurred and should be usable. You can edit and possibly correct the input file.

If the input file is FORMAT=BIN, the database is probably corrupt. Fix the database intergrity issues and EXTRACT the file again.

For information on salvaging damaged extracts, refer to the Maintaining Database Integrity chapter in the Administration and Operations Guide.

For details on the internals of spanning nodes, refer to the YottaDB Database Structure (GDS) chapter in the Administration and Operations Guide.

## Plug-In Errors¶

The plug-in architecture of YottaDB allows you to choose your preferred encryption software. Some plugin errors that you may encounter are as follows:

Plugin error: The plugin is unable to find the specified database file.

Action: Verify that the database file exists, the corresponding entry in the master key file points to the database file, and appropriate authorizations exist in the directory path and the database file.

Encryption handle corrupted

Plugin error: The plugin detected an internal error.

Action: This error indicates that there is a communication error between YottaDB and the gtmcrypt plug-in. Replace the process with an undamaged one. Report the entire incident context to your YottaDB support channel.

Plugin error: The plugin was not able to find the key file on the specified path.

Action: Verify that the master key file entry for this key file points to the correct path. Verify that the key file itself exists. Verify proper authorizations on directory path and file.

Encryption library has not been initialized

Plugin error: A gtmcrypt function was called before gtmcrypt_init().

Action: Call gtmcrypt_init() before calling any other encryption functions.

For more information on the plug-in errors and their fixes, see the documentation of your preferred encryption software.

Appendix B: Reference Implementation Error messages lists some errors that the YottaDB team encountered while testing YottaDB’s plug-in architecture with GNU Privacy Guard, the widely available implementation of Pretty Good Privacy (see “PGP: Pretty Good Privacy” by Simson Garfinkel).

## MUPIP Integ Errors¶

Database errors reported by MUPIP INTEG differ in impact and severity. Some require an immediate action to prevent extending the damage, action on other less severe errors may be delayed.

The following table outlines the MUPIP INTEG error messages with their severity using the codes as listed below:

 A Access: Prevents Database Access B Benign: Presents no risk of additional damage and has little or no effect on database performance D Dangerous: Presents a high risk that continuing updates may cause significant additional damage I Index: If the block is an index block, continuing updates will be quite dangerous: treat as a D; if the block is a datablock, continuing updates can only cause limited additional damage. T Transient: Usually cleared by an update to the database.

MUPIP INTEG Error Messages

Error Name Message Severity Section *
DBBDBALLOC Block doubly allocated D K3
DBBFSTAT Block busy/free status unknown (local bitmap corrupted) D M1
DBBNPNTR Bit map block number as pointer D K4
DBBPLMGT2K Blocks per local map is greater than 2K D I3
DBBPLMLT512 Blocks per local map is less than 512 D I3
DBBPLNOT512 Blocks per local map is not 512 D I3
DBBSIZZRO Block size equals zero A I3
DBCOMPTOOLRG Record has too large compression count I O2
DBDATAMX Record too large B O5
DBFGTBC File size larger than block count would indicate B I4
DBFSTBC File size smaller than block count would indicate D I4
DBGTDBMAX Key larger than database maximum I K7
DBINCLVL Block at incorrect level D O1
DBINCRVER Incorrect version of YottaDB database A I2
DBINVGBL Invalid mixing of global names D K3
DBKEYGTIND Key greater than index key I or B K2 or O5
DBKGTALLW Key larger than maximum allowed length I K1
DBLOCMBINC Local bitmap incorrect B M1
DBLRCINVSZ Last record of block has invalid size I K5
DBLTSIBL Key less than sibling’s index key I K2
DBLVLINC Local map block level incorrect B M2
DBMAXKEYEXC Maximum key size for database exceeds design maximum D I3
DBMAXRSEXBL Maximum record size for database exceeds what the block size can support D I3
DBMBMINCFREZ Master bit map incorrectly asserts this local map has free space. B M1
DBMBPFLDIS Master bit map shows this map full, in disagreement with both disk and INTEG results B M1
DBMBPFLDLBM Master bit map shows this map full, agreeing with disk local map B M1
DBMBPFLINT Master bitmap shows this map full, agreeing with MUPIP INTEG B M1
DBMBPFRDLBM Master bit map shows this map has space, agreeing with disk local map B M1
DBMBPFRINT Master bit map shows this map has space, agreeing with MUPIP INTEG B M1
DBMBPINCFL Master bit map incorrectly marks this local map full B M1
DBMBSIZMN Map block too small B M2
DBMBSIZMX Map block too large B M2
DBMBTNSIZMX Map block transaction number too large T I6
DBMRKBUSY Block incorrectly marked busy B M1
DBMRKFREE Block incorrectly marked free D M1
DBMXRSEXCMIN Maximum record size for database is less than the design minimum D I3
DBNOTDB File does not have a valid GDS file header A I3
DBNOTMLTP Block size not a multiple of 512 bytes. A I3
DBRBNLBMN Root block number is a local bit map number D K4
DBRBNNEG Root block number negative D K4
DBRBNTOOLRG Root block number greater than last block number in file D K4
DBRLEVLTONE Root level less than one D O1
DBRLEVTOOHI Root level higher than max D O1
DBSPANCHUNKORD Chunk of blocks is out of order B O5
DBSPANGLOINCMP Spanning node is missing B O5
DBSVBNMIN Start VBN smaller than possible A I3
DBSZGT64K Block size greater than 64K A I3
DBTNNEQ Current tn and early tn are not equal T I6
DBTNTOOLG Block transaction number too large T I6
DBTTLBLK0 Total blocks equal zero A I4
DBUNDACCMT Cannot determine access method ; Trying with BG T I6

Note

Section * refers to the specified section in the Finding and Fixing Database Errors chapter of the Administration and Operations Guide. The section details a description along with the action item to be taken on encountering the error message.