A remap redescribes a data set record. The remap enables the database administrator to change the appearance of a record, to restrict access to items in the record, and to control which records are accessed. The following facilities are available:
-
Items in the record can be reordered.
-
Items can be omitted or declared as hidden. These items are inaccessible.
-
Items can be required. The system ensures that these items are assigned a nonnull value before the record is stored.
-
Items can be declared as read only. The value of a read-only item can be accessed, but it cannot be modified.
-
Items can be given initial values.
-
A select condition can be specified. Only records which satisfy the select condition are returned to the user. The database administrator can construct a select condition which enables access to some data set records while hiding others completely.
-
A verify condition can be stipulated. The verify condition ensures that only valid records are stored using the remap.
Remaps also provide data independence. When the database is declared in DASDL, the data set and remap record formats are described. For remaps, records located in the system buffer are stored in data set record format, while records in the user work area are stored in remap record format. When the Accessroutines is compiled, code is generated to move data from the system buffer to the user work area and vice versa. If the data set and remap record formats are identical, a single move statement is generated. If the formats are different, several move statements can be generated to reformat the record.
When the format of a data set record is changed, the DMSUPPORT library must be recompiled. While the remap remains the same, user programs that use the remap continue to run without reprogramming or recompilation.
This approach to data independence is extremely efficient. It does not require run-time interpretive code. The only central processing unit (CPU) overhead is that required to reformat the record, and I/O time is not affected at all.
Note that you must use a logical database to access remaps.
The following diagrams illustrate the syntax for specifying a remap:
<remap specification>
── <remap name> REMAPS <data set name> ─┬───────────┬──────────────────►
└─<comment>─┘
►─┬────────────────┬─<remap record description>────────────────────────┤
└─<remap option>─┘<remap option>
┌◄───────────────────── , ────────────────────┐
──┴─┬─/1\─ REQUIRED ALL ──────────────────────┬─┴──────────────────────┤
└─/1\─ READONLY ALL ─┬────────────────────┤
├─ NO EXCEPTION ─────┤
└─ GIVING EXCEPTION ─┘Refer to “Remap Record Description” for information on the remap record description option. The remaining elements of the syntax diagram are described in the following table:
Example
The following example illustrates the DASDL syntax for a remap:
D DATA SET
(
A ALPHA(5);
B BOOLEAN;
F FIELD(15);
G GROUP
(
G1 ALPHA(2);
G2 REAL;
);
N NUMBER(S5,2);
P REAL(S6);
);
R REMAPS D
(
A ALPHA(5);
F;
B BOOLEAN INITIALVALUE TRUE;
G GROUP
(
G1 ALPHA(2) HIDDEN;
G2 REAL READONLY;
);
N NUMBER(S5,2) INITIALVALUE 1.0, REQUIRED;
)
SELECT N GEQ 1.0,
VERIFY N GEQ 1.0;