Chapter 4. Global Directory Editor

Revision History
Revision V5.5-000/46 June 2012

Added AUTOSWITCHLIMIT as an option for -JOURNAL region qualifier.

Revision V5.4-002B24 October 2011Conversion to documentation revision history reflecting GT.M releases with revision history for each chapter.

Table of Contents

Global Directory
GDE Overview
Identifying the Current Global Directory
Creating a Default Global Directory
Mapping Global Variables in a Global Directory
Examining the Default Global Directory
Customizing a Global Directory
Using GDE
Guidelines for Mapping
Global Director Editor Commands
Specifying File Names in Command Lines
Font/Capitalization Conventions Used in this Chapter
@
Add
Change
Delete
Exit
Help
LOCks
LOG
Quit
Rename
SEtgd
SHow
Template
Verify
Name, Region, and Segment Qualifiers
Name Qualifiers
Region Qualifiers
Segment Qualifiers
GDE Command Summary
GDE Command Qualifier Summary

Global Directory

In GT.M, routines are independent of global variables. Routines reside in the file system where as global variables reside in the database files. In this respect, GT.M is different from other M implementations.

A set of M global variables (Names or Name spaces) map to Regions that define the properties relating to the M global. Each Region maps to a Segment that defines the properties relating to the file system. These properties and mapping rules are stored in a binary file called "global directory". A global directory file has an extension of .gld.

The location of the global directory is pointed to by the Intrinsic Special Variable $ZGbldir. $ZGblgdir gets initialized at process startup from the environment variable gtmgbldir and you can modify it during execution. For example, with a simple Set $ZGBldir command, a process can switch back and forth between a development and a testing database.

In many ways, a global directory is like a telephone directory. Just as a telephone directory helps you find the phone number (and the address) given a person's name, the same way a global directory helps GT.M and its run-time processes find the database file of a given M global variable name.

For example, consider the following illustration:

In this illustration, there are four M global variables (^Gharial, ^Hoopoe, ^Jacare, ^Trogon) separated from the rest (for example, sharing globals between applications, or for reasons of protection --perhaps they contain special information so that only herpetologists are to have access to globals ^Gharial and ^Jacare, and only ornithologists are to have access to globals ^Hoopoe and ^Trogon). This is accomplished by creating five Name Spaces (note that a name space can contain a single variable , as in this example, or a range of global variables, for example, everything starting with ^A through ^Gharial). There is always a default (*) name space.

One or more name spaces are mapped to a Region. All global variables in a region share a common set of M global variable properties, such as the maximum record length, whether null subscripts are permitted, and so on. In this case, ^Gharial and ^Jacare are mapped to the region REPTILES, whereas ^Hoopoe and ^Trogon are mapped to the region BIRDS. The default name space * is mapped to a region called DEFAULT.

Each region is mapped to a Segment. Just as a region defines properties pertaining to M global variables, the segment defines properties pertaining to the database for that region, such as the file name, the initial allocation, number of global buffers, and so on. The database file is just an ordinary file in the file system of the underlying operating system.

Each database file can have a single active journal file. A journal can be linked to a previous journal file to form a chain of journal files.