The LOAD command:
Enables you to enter global variable names and their corresponding data values into a GT.M database from a sequential file.
Uses the Global Directory to determine which database files to use.
Supports user collation routines.
Operates concurrently with normal GT.M database access.
From an application perspective, loading data while an application is running may result in an inconsistent database.
The format of the LOAD command is:
L[OAD] [-qualifier...] file-name
The optional qualifiers are:
-FO[RMAT]=GO | B[INARY] | ZWR
-BE[GIN]=integer
-E[ND]=integer
-FI[LLFACTOR]=integer
LOAD takes its input from the file defined by the file-name
LOAD may take its input from a UNIX file on any device that supports such files.
For information on loading with an M "percent utility," refer to the %GI section of the "M Utility Routines" chapter in the GT.M Programmer's Guide. LOAD is typically faster, but the %GI utility can be customized.
<CTRL-C> produces a status message from LOAD. Entering <CTRL-C> twice in quick succession stops LOAD. A LOAD that is manually stopped or stops because of an internal error is incomplete and may lack application level integrity, but will not adversely affect the database structure unless terminated with a kill -9.
Specifies the format of the input file. The format must match the actual format of the input file for LOAD to operate.
The format codes are:
GO - Global Output format
B[INARY] - Binary format
Z[WR] - ZWRITE format
By default, LOAD uses FORMAT=ZWR.
-FORMAT=GO stores the data in record pairs. Each global node produces one record for the key and one for the data.
-FORMAT=ZWR stores the data for each global node in a single record.
-FORMAT=BINARY only applies to Greystone Database Structure (GDS) files. A BINARY format file loads significantly faster than a GO or ZWR format file. -FORMAT=BINARY stores the data in a proprietary format. -FORMAT=BINARY has one header record, therefore LOAD -FORMAT=BINARY starts active work with record number two (2).
Specifies the record number of the input file with which LOAD should begin. Directing LOAD to begin at a point other than the beginning of a valid key causes an error.
It is important to consider the number of header records when choosing a -BEGIN point. For more information, refer to the section on -FORMAT.
For -FORMAT=GO input, the value is usually an odd number. Since -FORMAT=BINARY requires important information from the header, this type of load requires an intact file header regardless of the -BEGIN value.
For -FORMAT = ZWR input, each record contains a complete set of reference and data information. The beginning values are not restricted, except to allow two records for the header.
By default, LOAD starts at the beginning of the input file.
Specifies the record number of the input file at which LOAD should stop. -END=integer must be greater than the -BEGIN=integer for LOAD to operate. LOAD terminates after processing the record of the number specified by -END or reaching the end of the input file.
The value of -FORMAT=GO input should normally be an even number. By default, LOAD continues to the end of the input file.
Specifies the quantity of data stored in a database block. Updates to the block fill the remaining available space. Blocks that receive subsequent updates and avoid block splits operate more efficiently.
If you have database performance issues or a high rate of database updates, you should examine the defined FILL_FACTORs. Unless the application only uses uniform records, which is not typical for most applications, FILL_FACTORs do not work precisely.
The FILL_FACTOR for data that is relatively static, or grows by the addition of new nodes that collate before or after pre-existing nodes, should be 100 percent. The FILL_FACTOR for data that is growing by additions to existing nodes may be chosen to leave room in the typical node for the forecast growth for some period of time. Generally, this is the time between the LOAD and first REORG, or between two REORGs. This is also true for additions of nodes that are internal to the existing collating sequence.
For example, if a global is expected to grow by five percent each month (from relatively uniformly distributed updates), and REORGs are scheduled once every quarter, the FILL_FACTOR for both the original LOAD and subsequent REORGs might be 20 percent ((3 months + 1 month "safety" margin) * five percent per month).
By default, LOAD uses -FILL_FACTOR=100 for maximum data density.