The GT.M 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; GT.M deletes them when the M process terminates.
Global variables contain data that persists beyond the process. GT.M stores global variables on disk. A Global Directory organizes global variables and describes the organization of a database. The GT.M administrator uses the Global Directory Editor (GDE) to create and manage Global Directories. A Global Directory maps global names to a database file. GT.M uses this mapping when it stores and retrieves globals from the database. Several Global Directories may refer to a single database file.
For more information about the GT.M data management system, refer to the "Global Directory Editor", "MUPIP" and "GT.M Journaling" chapters in the GT.M Administration and Operations Guide.
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 GT.M database management and database journaling.
For more information regarding GT.M database utilities, refer to the "Global Directory Editor", "MUPIP" and "GT.M Journaling" chapters in the GT.M Administration and Operations Guide.
In the GT.M programming environment, source routines are generated and stored as standard UNIX files. They are created and edited with standard UNIX text editors. GT.M accepts source lines of up to 8192 bytes. When GT.M encounters a line with a length greater than 8192 bytes in a source file, it emits an 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.
GT.M 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 GT.M and from the operating system.
In addition to standard M "percent" utilities, GT.M permits the use of the standard UNIX file manipulation tools, for example, the diff, grep, cp, and mv commands. The GT.M 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.
GT.M programs are compatible with most source management software, for example, RCS and SCCS.
The GT.M programmer 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.
The GT.M programmer also uses the Direct Mode facility to interactively debug, modify, and execute M routines. In Direct Mode, GT.M executes each M command immediately, as if it had been in-line at the point where GT.M 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 GT.M 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. GT.M provides syntax error checking at compile-time and allows you to enable or disable the compile-as-written mode. By default, GT.M 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.
A GT.M 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.
The run-time system utilizes a GT.M facility called ZLINK to link in an M routine. When a program or a Direct Mode command refers to an M routine that is not part of the current process, GT.M automatically uses the ZLINK facility and attempts to link the referenced routine (auto-ZLINK). The ZLINK facility also determines whether recompilation of the routine is necessary. When compiling as a result of a ZLINK, GT.M typically ignores errors in the source code.
The run-time system also provides incremental linking. The ZLINK command adds an M routine to the current image. This feature facilitates the addition of code modifications during a debugging session. The GT.M programmer can also use the feature to add patches and generated code to a running M process.
The GT.M compiler detects and reports syntax errors at the following times:
Compile-time - while producing the object module from a source file
Run-time - while compiling code for M indirection and XECUTEs
Run-time - when the user is working in Direct Mode.
The compile-time error message format displays the line containing the error and the location of the error on the line. The error message also indicates what was incorrect about the M statement.
GT.M can not detect certain types of errors associated with indirection, the functioning of I/O devices, and program logic until run-time.
The compile-as-written feature allows compilation to continue and produces an object module despite errors in the code. This permits testing of other pathways through the code. The errors are reported at run-time, when GT.M encounters them in the execution path.
The GT.M run-time system recognizes execution errors and reports them when they occur. It also reports errors flagged by the compiler when they occur in the execution path.
For more information, see Chapter 13: “Error Processing”.
GT.M supports input and output processing with the following system components:
Terminals
Sequential disk files
Mailboxes
FIFOs
Null devices
Socket devices
GT.M input/output processing is device-independent. Copying information from one device to another is accomplished without reformatting.
GT.M has special terminal-handling facilities. GT.M performs combined QIO operations to enhance terminal performance. The terminal control facilities that GT.M provides include escape sequences, control character traps, and echo suppression.
GT.M supports RMS sequential disk files that are accessed using a variety of deviceparameters.
GT.M supports block I/O with fixed and variable length records for file-structured (FILES-11) tapes and non-file-structured unlabeled (FOREIGN) tapes. GT.M supports the ASCII character set for unlabeled FOREIGN and FILES-11 tapes. GT.M supports the EBCDIC character set for FOREIGN tapes only. GT.M also supports FOREIGN DOS-11 and ANSI labelled tapes or stream format records. It also supports ASCII and EBCDIC character sets.
GT.M uses permanent or temporary mailboxes fifos for interprocess communication. GT.M treats mailboxes as record-structured I/O devices.
GT.M provides the ability to direct output to a null device. This is an efficient way to discard unwanted output.
GT.M provides device-exception processing so that I/O exception handling need not be combined with process-related exception conditions. The OPEN, USE, and CLOSE EXCEPTION parameters define an XECUTE string as an error handler for an I/O device.
GT.M 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.
GT.M 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”.
GT.M allows the definition of alternative collation sequences and pattern matching codes for use with languages other than English. Chapter 12: “Internationalization” describes the details and requirements of this functionality.
