Physical options for a data set, set, subset, or Access can be declared either with the description of the structure or independently using a physical specification. A physical specification enables the user to place all physical options at the end of the DASDL source input. It also allows physical options to be specified for global data.
| Note: | The data set physical options DATAENCRYPT and DATAMASK apply to items within a data set, rather than the data set itself. Therefore, DATAENCRYPT and DATAMASK cannot be specified independently using a physical specification. |
Physical specifications for data sets, sets, subsets, and accesses must refer to structures that have been previously declared. Physical specifications must be declared at the disjoint level; they can refer to embedded structures, provided the structures have unique names. Any option appearing in a physical specification overrides the same option when specified in a data set, set, subset, or Access declaration.
When the database name appears, the physical specifications apply only to the global data. To set them as defaults for all data sets, refer to Using the Defaults Specification. The database name must be the name specified in the compiler control card when the database description is compiled.
The following diagrams illustrate the syntax for the physical specifications:
<physical specification>
──┬─<Access name>── ( <Access physical option> ) ────────┬──────────────┤ ├─<data set name>── ( <data set physical options> ) ───┤ ├─<database name>─ ( <global data physical options> ) ─┤ ├─<set name>────┬─ ( <set-subset physical options> ) ──┘ └─<subset name>─┘
<global data physical options>
┌◄────────────────── , ──────────────────┐
──┴─┬─/1\─ CHECKSUM ─┬───────────────────┬─┴───────────────────────────┤
│ └─ = ─┬─ FALSE ─────┤
│ └─ TRUE ──────┤
├─/1\─<disk/pack>────────────────────┤
├─/1\─ EXTENDED ─┬───────────────────┤
│ └─ = ─┬─ FALSE ─────┤
│ └─ TRUE ──────┤
├─/1\─ GUARDFILE = <file title> ─────┤
├─/1\─ SECURITYGUARD = <file title> ─┤
├─/1\─ STATISTICSLOC = ┬─ PRINTER ───┤
│ └─ <packname> ┤
├─/1\ ─ VSSWARN ──┬──────────────────┤
│ └─ = ─┬─ FALSE ────┤
│ └─ TRUE ─────┤
├─/1\ ─ VSS2OPTIMIZE ─┬──────────────┤
│ └─ = ─┬─ TRUE ─┤
│ └─ FALSE ┤
└────────────────────────────────────┘<disk/pack>
┌◄──────── , ────────┐
──┴─┬─/1\─<diskkind>─┬─┴───────────────────────────────────────────────┤
└─/1\─<diskname>─┘<diskkind>
──┬──────────┬─┬─ disk ─────┬──────────────────────────────────────────┤
└─ kind = ─┘ ├─ pack ─────┤
└─ diskpack ─┘<diskname>
──┬─ pack ───────┬─ = ──<familyname>───────────────────────────────────┤ ├─ diskpack ───┤ ├─ packname ───┤ └─ familyname ─┘
The following table explains the elements of the syntax diagrams:
|
Option |
Description |
|---|---|
|
<Access physical option> |
Refer to “Access Physical Option” in Sets, Subsets, and Accesses for information. |
|
<data set physical options> |
Refer to “Data Set Physical Options” in Data Set Declaration for information. |
|
<set-subset physical options> |
Refer to “Set and Subset Physical Options” in Sets, Subsets, and Accesses for information. |
|
CHECKSUM |
The CHECKSUM option is used to detect I/O errors. A checksum is a value computed for each block by applying an equivalence operator to each word in the block. When the block is physically written, the checksum value is stored in a checksum word appended to the end of the block. When the block is read, the checksum is recomputed and the result is compared to the stored value. A checksum error occurs if the two values are not equal. When an error occurs, the user program is notified of the error and the READLOCK bit for the row in error is turned on. For databases not using XE, if the CHECKSUM option is not specified (either in the Defaults section or at the structure level), the CHECKSUM option is reset by default. Specifying CHECKSUM or CHECKSUM = TRUE sets the option. The recommended setting is TRUE. |
|
CHECKSUM (cont.)  |
For XE databases using, if the CHECKSUM option is not specified (either in the Defaults section or at the structure level),
For existing structures that add the EXTENDED attribute, a record format reorganization is required to add
The global CHECKSUM default can be overridden in either the global data set and set Defaults section, or at the structure level for data sets and their associated sets. If the CHECKSUM option is not specified at the structure level, the option is FALSE for new structures if the EXTENDED attribute for the structure is FALSE and
More global specifications of CHECKSUM are still in effect for any new XE structures. Take into account the explicit or implicit setting of the CHECKSUM option when calculating data set BLOCKSIZE and set-subset TABLESIZE specifications. |
|
EXTENDED |
The global EXTENDED attribute is only available with XE features. |
|
EXTENDED (cont.) |
When set to TRUE, the EXTENDED attribute causes structures to have records that contain two additional words:
If the global EXTENDED attribute is not specified, its value is FALSE for the database. However, you can set the EXTENDED attribute for individual structures. If the database is audited, and the EXTENDED attribute is set to TRUE for at least one structure, then the INDEPENDENTTRANS database option must also be specified. The EXTENDED attribute can also be set to TRUE if the database is unaudited. The INDEPENDENTTRANS database option must not be set. The Restart data set is unaffected by setting the global EXTENDED attribute because this attribute is not allowed for the Restart data set. Because the global data set contains 1 record only, you cannot specify SECTIONS for this data set. |
|
The GUARDFILE option designates the name and location of the guard file, if any, that controls access to the database files through the Accessroutines. If the guard file is located under a usercode, the user must ensure that the usercode is also designated in DASDL. The usercode must be designated in DASDL because the system does not apply family substitution or usercode inheritance when searching for the guard file at run time. If the guard file is not present when the database is opened, user programs that attempt to open the database are terminated with the following exception message: OPENERROR 26. DMVERB access violations can be recorded automatically in the system log by setting the log option for Major Type 1 and Minor Type 30. Example system command syntax includes: LOGGING1, 30 SUMLOG ALL. Violations are recorded for the following DMVERBS: FIND, LOCK, SECURE, ASSIGN, CREATESTORE, DELETE, GENERATE, INSERT, LOCKSTORE and REMOVE. The following is example output from a SYSTEM/LOGANALZYER “LOG DMS” command that reports a CREATESTORE violation: 12:42:16 DMS 6500 (HART)CANDE/CODE1730 ON RDBCP. DATABASE ACCESS VIOLATION. DATABASE NAME :(HART)TESTDB. (6501, STACK 0867) STRUCTURE NAME :PERSONNEL, STRUCTURE#9 VIOLATION :CREATESTORE NOT PERMITTED |
|
|
The SECURITYGUARD option sets the SECURITYGUARD file attribute to the name and location of the guard file that controls direct access to the database files by programs other than the Accessroutines. Standard system security rules prevail. The following conditions cause security errors: With both the GUARDFILE and SECURITYGUARD options, the guard file can be created using the SYSTEM/GUARDFILE utility, which is described in the Security Operations Guide. |
|
|
STATISTICSLOC |
Allows you to designate the location of the statistics report. It requires that the STATISTICS option be set to TRUE. If you choose to specify the pack name, the statistics output is reported as follows: <dbusercode>DBSTATS/<dbname>/YYYYMMDD/HHMMSS ON <packname> If it is a permanent directory database, the DATAPATH is assumed and stored as <path name>/DBSTATS/<dbname>/YYYYMMDD/HHMMSS ON <packname> Where YYYYMMDD and HHMMSS are the date and time when the statistics are generated. |
|
The VSSWARN option provides a run-time indication of discrepancy between the blocking attributes of a structure and the storage device type upon which it resides. This option is specifically associated with VSS-2 devices. When the VSSWARN option is set to TRUE, the Accessroutines generates a durable warning message if the blocking attributes of the structure are not optimized for the members of the pack family. The message is sent as a task that is placed in the waiting mix. You can view the message by using the IB (Instruction Block) system command. The VSSWARN option is useful when a VSS-2 device is unexpectedly configured in a 180-byte aligned pack family. The default is FALSE. |
|
|
The VSS2OPTIMIZE option, when set to TRUE, is an explicit request for an existing structure (or structures) that uses the default blocking attributes of DASDL to be automatically reorganized for VSS-2 optimization. A setting of FALSE merely serves as notice to ignore an existing structure (or structures) that is not optimized. A setting of FALSE cannot be used to “unoptimize” a structure. VSS-2 optimized structures are aligned on block boundaries that are multiples of 60 words. Placing VSS-2 optimized structures on 180-byte aligned disks does not impact performance. New structures, whether created as part of new databases or added to existing databases, are by default automatically optimized for VSS-2 if they allow DASDL to supply the blocking specifications. Specifying this option for those structures serves as documentation only. The default applies to existing structures and is FALSE. |
Example
The following example illustrates the DASDL syntax for the physical specifications. In this example, physical specifications are designated for the database, and for data sets D and E.
G1 ALPHA(20);
G2 NUMBER(5,2);
G3 POPULATION (1000) OF D;
D DATA SET
(
D1 ALPHA(20) OCCURS 20 TIMES;
D2 REAL;
E UNORDERED DATA SET
(
E1 NUMBER(5);
E2 BOOLEAN;
)
ALLOCATE DENSELY;
);
% PHYSICAL SPECIFICATIONS
%
DBNAME (KIND = PACK, PACKNAME = DBPACK); %GLOBAL DATA
D (POPULATION = 900, BUFFERS = 2 + 2 PER USER,
EXTENDED = TRUE;
);
E (ALLOCATE FROM END);