Example: Describing a physical file using DDS

Example: Describing a physical file using DDS

This example shows how to describe a physical file using DDS. The DDS for a physical file, as shown in the next example, must be in the following order:

1

File-level entries (optional). The UNIQUE keyword is used to indicate that the value of the key field in each record in the file must be unique. Duplicate key values are not allowed in this file.

2

Record format-level entries. The record format name is specified, along with an optional text description.

3

Field-level entries. The field names and field lengths are specified, along with an optional text description for each field.

4

Key field-level entries (optional). The field names used as key fields are specified.

5

Comment (optional).
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
     A* ORDER HEADER FILE (ORDHDRP)
     A  5
     A                                 1  UNIQUE      A      2 R ORDHDR                    TEXT('Order header record')
     A        3 CUST           5   0      TEXT('Customer number')
     A            ORDER          5   0      TEXT('Order number')
     A            .
     A            .
     A            .
     A          K CUST      A    4   K ORDER
The following example shows a physical file ORDHDRP (an order header file), with an arrival sequence access path without key fields specified, and the DDS necessary to describe that file.

Record format of physical file ORDHDRP

Customer number (CUST) — Packed decimal length 5, No decimals
Order number (ORDER) — Packed Decimal Length 5, No decimals
Order date (ORDATE) — Packed decimal length 6, No decimals
Purchase order number (CUSORD) — Packed decimal length 15, No decimals
Shipping instructions (SHPVIA) — Character length 15
Order status (ORDSTS) — Character length 1
...
State (STATE) — Character length 2
|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....8
     A* ORDER HEADER FILE (ORDHDRP)
     A          R ORDHDR                    TEXT('Order header record')
     A            CUST           5   0      TEXT('Customer Number')
     A            ORDER          5   0      TEXT('Order Number')
     A            ORDATE         6   0      TEXT('Order Date')
     A            CUSORD        15   0      TEXT('Customer Order No.')
     A            SHPVIA        15          TEXT('Shipping Instr')
     A            ORDSTS         1          TEXT('Order Status')
     A            OPRNME        10          TEXT('Operator Name')
     A            ORDAMT         9   2      TEXT('Order Amount')
     A            CUTYPE         1          TEXT('Customer Type')
     A            INVNBR         5   0      TEXT('Invoice Number')
     A            PRTDAT         6   0      TEXT('Printed Date')
     A            SEQNBR         5   0      TEXT('Sequence Number')
     A            OPNSTS         1          TEXT('Open Status')
     A            LINES          3   0      TEXT('Order Lines')
     A            ACTMTH         2   0      TEXT('Accounting Month')
     A            ACTYR          2   0      TEXT('Accounting Year')
     A            STATE          2          TEXT('State')
     A
The R in position 17 indicates that a record format is being defined. The record format name ORDHDR is specified in positions 19 through 28.
You make no entry in position 17 when you are describing a field; a blank in position 17 along with a name in positions 19 through 28 indicates a field name. The data type is specified in position 35. The valid data types are:

Entry

Meaning

A

Character

P

Packed decimal

S

Zoned decimal

B

Binary

F

Floating point

H

Hexadecimal

L

Date

T

Time

Z

Timestamp

Notes:

For double-byte character set (DBCS) data types, see Double-byte character set considerations.

The system performs arithmetic operations more efficiently for the packed-decimal than for the zoned-decimal data type.

Some high-level languages do not support floating-point data.

Some special considerations that apply when you are using floating-point fields are:

The precision associated with a floating-point field is a function of the number of bits (single or double precision) and the internal representation of the floating-point value. This translates into the number of decimal digits supported in the significant and the maximum values that can be represented in the floating-point field.

When a floating-point field is defined with fewer digits than supported by the precision specified, that length is only a presentation length and has no effect on the precision used for internal calculations.

Although floating-point numbers are accurate to 7 (single) or 15 (double) decimal digits of precision, you can specify up to 9 or 17 digits. You can use the extra digits to uniquely establish the internal bit pattern in the internal floating-point format so identical results are obtained when a floating-point number in internal format is converted to decimal and back again to internal format.

If the data type (position 35) is not specified, the decimal positions entry is used to determine the data type. If the decimal positions (positions 36 through 37) are blank, the data type is assumed to be character (A); if these positions contain a number 0 through 31, the data type is assumed to be packed decimal (P).
The length of the field is specified in positions 30 through 34, and the number of decimal positions (for numeric fields) is specified in positions 36 and 37. If a packed or zoned decimal field is to be used in a high-level language program, the field length must be limited to the length allowed by the high-level language you are using. The length is not the length of the field in storage but the number of digits or characters specified externally from storage. For example, a 5-digit packed decimal field has a length of 5 specified in DDS, but it uses only 3 bytes of storage.
Character or hexadecimal data can be defined as variable length by specifying the VARLEN field-level keyword. Generally you would use variable length fields, for example, as an employee name within a database. Names usually can be stored in a 30-byte field; however, there are times when you need 100 bytes to store a very long name. If you always define the field as 100 bytes, you waste storage. If you always define the field as 30 bytes, some names are truncated. You can use the DDS VARLEN keyword to define a character field as variable length. You can define this field as:

Variable-length with no allocated length. This allows the field to be stored using only the number of bytes equal to the data (plus two bytes per field for the length value and a few overhead bytes per record). However, performance might be affected because all data is stored in the variable portion of the file, which requires two disk read operations to retrieve.

Variable-length with an allocated length equal to the most likely size of the data. This allows most field data to be stored in the fixed portion of the file and minimizes unused storage allocations common with fixed-length field definitions. Only one read operation is required to retrieve field data with a length less than the allocated field length. Field data with a length greater than the allocated length is stored in the variable portion of the file and requires two read operations to retrieve the data.

Parent topic:
Describing database files using DDS