YottaDB runs on a wide variety of computer platforms. Consult YottaDB for the current list of supported platforms.
In addition to preserving the traditional features of M, YottaDB also offers an optimized compiler that produces object code that does not require internal interpreters during execution.
On all platforms, the YottaDB dynamic linking mechanism activates compiled objects. On some platforms, you can link the object modules into shared object libraries.
In keeping with the focus on creating fully compiled code, YottaDB is tightly integrated with the operating system environment and permits the use of operating system utilities for program development.
YottaDB also provides a full complement of M tools for creating, compiling, and debugging source code. Many of these tasks are accomplished from the facility called Direct Mode, which offers the look and feel of an interpreted language that is familiar to the traditional M programmer.
The Programming Environment is described in the following sections.
The scope of M data is either process local or global.
Local variables last only for the duration of the current session; YottaDB deletes them when the M process terminates.
Global variables contain data that persists beyond the process. YottaDB stores global variables on disk. A Global Directory organizes global variables and describes the organization of a database. The YottaDB administrator uses the Global Directory Editor (GDE) to create and manage Global Directories. A Global Directory maps global names to a database file. YottaDB uses this mapping when it stores and retrieves globals from the database. Several Global Directories may refer to a single database file.
Database Management Utilities¶
The Global Directory Editor (GDE) creates, modifies, maintains, and displays the characteristics of Global Directories. GDE also maps LOCKs on resource names to the region of the database specified for the corresponding global variables.
The M Peripheral Interchange Program (MUPIP) creates database files and provides tools for database management and database journaling.
For more information regarding database utilities and the data management system, refer to the “Global Directory Editor”, “MUPIP” and “YottaDB Journaling” chapters in the Administration and Operations Guide.
In the YottaDB programming environment, source routines are generated and stored as standard UNIX files. They are created and edited with standard UNIX text editors. YottaDB accepts source lines of up to 8192 bytes. When YottaDB encounters a line with a length greater than 8192 bytes in a source file, it emits a
%YDB-W-LSEXPECTED warning. This warning identifies cases where a line greater than 8192 bytes is split into multiple lines, which causes statements beyond the character prior to the limit to execute irrespective of any starting IF, ELSE or FOR commands. The 8192 byte limit applies to XECUTE command arguments and Direct Mode input as well.
YottaDB is designed to work with the operating system utilities and enhances them when beneficial. The following sections describe the process of programming and debugging with YottaDB and from the operating system.
Source File Management¶
In addition to standard M “percent” utilities, YottaDB permits the use of the standard UNIX file manipulation tools, for example, the
mv commands. The programmer can also use the powerful facilities provided by the UNIX directory structure, such as time and date information, tree-structured directories, and file protection codes.
YottaDB programs are compatible with version control software. For example YottaDB version control is managed using git.
Programming and Debugging Facilities¶
You can use any UNIX text editor to create M source files. If you generate a program from within the Direct Mode, it also accesses the UNIX text editor specified by the environment variable
EDITOR and provides additional capabilities to automate and enhance the process.
You can also use the Direct Mode facility to interactively debug, modify, and execute M routines. In Direct Mode, YottaDB executes each M command immediately, as if it had been in-line at the point where YottaDB initiated Direct Mode.
The following is a list of additional enhancements available from the Direct Mode:
The capability to issue commands from Direct Mode to the shell
A command recall function to display and reuse previously entered commands
Many language extensions that specifically optimize the debugging environment
The compiler operates on source files to produce object files consisting of position-independent, native object code, which on some platforms can be linked into shared object libraries. YottaDB provides syntax error checking at compile-time and allows you to enable or disable the compile-as-written mode. By default, YottaDB produces an object file even if the compiler detects errors in the source code. This compile-as-written mode facilitates a flexible approach to debugging.
The Run-Time System¶
A YottaDB programmer can execute an M routine from the shell or interactively, using the M commands from Direct Mode.
The run-time system executes compile-as-written code as long as it does not encounter the compile-time errors. If it detects an error, the run-time system suspends execution of a routine immediately and transfers control to Direct Mode or to a user-written error routine.
YottaDB offers capabilities that allow you to optimize your programming environment. These include allowing you to call into M routines from programs written in other programming languages, access your M databases with interfaces that provide functionality equivalent to M intrinsic database functions, and to alter your programming environment when working with languages other than American English. These include allowing you to call programs written in other programming languages that support C-like interfaces and to alter your programming environment when working with languages other than American English. This capability is described in more detail in chapters throughout this manual.
YottaDB routines can call external (non-M) routines using the external call function. This permits access to functions implemented in other programming languages. For more information, see Chapter 11: “Integrating External Routines”.