IEG has developed several LDA runtime products and utilities requiring this information. Since Unisys did not provide this information, IEG has decided to make it public.

Disclaimer

The accuracy of information contained herein is not guaranteed. The information in this document has been discovered by experimentation and researching the resulting disk files. This document is subject to change as our understanding of D-ISAM evolves and as LDA III's usage of D-ISAM may change. Unless noted otherwise, the information relates to LDA 2.1 and later.

File "Cluster" Members

Each Usage I-O and Output ISPEC creates a "Cluster" of files in LDA III's run-time environment. All files in the cluster begin with the underscore character "_" and include the ISPEC name. Symbolic files are simple ASCII text files which describe the characteristics of the run-time database files.

Symbolic Files

_<Ispec>.DFN

_<Ispec>.DAT

Data in the DAT file is always accessed through the _<Ispec>.IDX file. This is the heart of D-ISAM. The layout of the IDX file is quite complex compared to the other files in the cluster, so a little background is necessary. The IDX file:

• Is accessed in "blocks," each of which is 2048 characters long.
• Contains "sizes" and "pointers."
  • Sizes are 2-byte (16 bit) "integers." The leftmost bit is the sign - always zero; the rightmost bit is the least significant bit. Thus, a size can be from 0 through 32,767.
  • Pointers are 4-byte (32 bit) "longs." The leftmost bit is the sign - always zero; the rightmost bit is the least significant bit. Thus, a Pointer can be from 0 through 2,147,483,647.
• Contains Indexes in the form of "trees" of "coarse" (optional) and "fine" tables for each Profile targeting the ISPEC.
  • Coarse table entries point to another coarse table or to a fine table.
  • Fine table entries point to a record in the DAT file. Each record in the DAT file will have an corresponding entry in a fine table.

Conceptually, the IDX file contains:

• Block "0"
  • Pointers to the other parts of the IDX file
  • Counts and statistics related to the indices and the DAT file
• "DK" table, a list of deleted (Purged) records in the DAT file.
• Index Descriptors
• Coarse and Fine Tables (indices)

_<ispec>.IDX Layout

Block "0"

• Is at the beginning of the IDX file.
• Byte 7 indicates blocksize used in address calculations below:
  • 1 = 512 bytes (LDA 1.2)
  • 7 = 2048 bytes (LDA 1.3)
• Byte 16 has a long pointer which may be to the beginning of the index descriptors. The actual address is obtained by multiplying this number (if greater than 0) -1 by blocksize.
• Byte 26 has a long pointer to the current DK table of purged record numbers. The actual address is obtained by multiplying this number (if greater than 0) -1 by blocksize.
• Byte 30 has a long pointer to the prior DK table address. The actual address is obtained by multiplying this number (if greater than 0) -1 by blocksize.
• Byte 34 has a long count of the number of records (including purged records) in the DAT file.
• Byte 42 has a long count of the number of update transactions
• Byte 46 has a long pointer which points to the beginning of the index descriptors. The actual address is obtained by multiplying this number by blocksize.
• Byte 99(?) has a long count of the number of file opens.

DK Table

• When a record is purged, its record number is added to the end of the DK table and the DK table size is increased by 4 (length of a long).
• When records have been purged from the DAT table, new records are added in place of the most recently purged record (LIFO) by retrieving the record number from the final entry in the DK table and decreasing the DK table size by 4.
• The format of the DK table is:
  • Integer table size (including the 2-byte integer).
  • Long pointer to prior (?) DK table, if any.
  • A series of long record numbers (one relative) which have been purged.

Index Descriptors

• D-ISAM uses this information to know where in IDX the first table ("root") is for each Profile and where the keys are in data records.
• The format of the Index Descriptor table is:
  • Integer table size (including the 2-byte integer)
  • A Long of zero (perhaps a pointer to an overflow).
  • A Dummy entry:
    • 00 07 (Entry size = 7 bytes)
    • 00 00 00 00 00
  • A series of Index Descriptors, one for each Profile, each with the format:
    • Integer entry size (including the 2-byte integer)
    • Long pointer, "r," to the Profile's "root" table
      • Actual address (one relative) = 1 + (blocksize * (r - 1) )
    • Integer of 00 00 or 00 80. 00 80 indicates the Profile allows duplicates.
    • 01 00. I haven't seen anything else.
    • 0n 00. Appears to be a Profile number, but it's the wrong format.
    • Key Descriptors, one for each key, each having the form:
      • Integer key size. This can be zero for the "dummy" Profile for Memos and Events. Remember that all numerics will be 8 bytes long (double precision) prior to 2.1.
      • Integer position within the data record.
      • One character Key Type:
        • 00 = alpha
        • 03 = numeric
        • 80 = descending alpha
        • 83 = descending numeric
        • There is no indication of LIFP; this implies that LIFP conditions are evaluated at run time and the record is marked as a non-member.
  • The rest of the block is filled with 00.

Coarse/Fine Tables

• As records are added to DAT, each Profile has an entry added pointing to the record and the data is checked against each Profile's membership criteria.
• As records are Purged from the DAT, the corresponding entry in each Fine table is marked as "not a member."
• As records are updated in the DAT, the conditions of membership in each Profile are reevaluated and the fine table membership flag is updated as required.
• Both types of tables share the same format:
  • Integer table size (including the 2-byte integer). 00 02 means the table is empty.
  • A series of entries each having the form:
    • Key. If this is a coarse table, these items are a copy of the values from the final entry of the table pointed to by the long pointer below (unless this is the final entry in this table - in which case this equals the prior entry's key (I think this a D-ISAM bug). If this is a fine table, these items are a copy of the values from the data record in DAT pointed to by the long pointer below.
      • One character validity flag (Y or N).
      • User key values - size according to length in the Key Descriptor.
      • Long duplicates resolver, only if duplicates are allowed. Key values along with the resolver make a unique value.
    • Long pointer.
      • If this is a coarse table, this points to another table in IDX. The actual address (one relative) is = 1 + (blocksize * (r - 1) )
      • If this is a fine table this field contains record number (one relative) in the DAT file.
  • The rest of the block up to the last four bytes is filled with 00
  • Integer Profile number
  • Table type "0n xx":
    • "n" is the table level, zero being a fine table.
    • "xx" is ignored.

D-ISAM limitations

These limits are not based on D-ISAM APIs or LDA III interpreter design - that information is not available. Hence, consider these limits as purely theoretical and more liberal than actual implementation limits.

Limited Item	Limit	Basis of Limit
Number of ISPECs	unknown
File size	2,147,483,647	Size of byte pointer in file read/write operations
Number of Records	2,147,483,647	Fine table record # field is a "long"
Number of Records with Duplicate key values	2,147,483,647	Fine table duplicates resolver is a "long"
Record Size	2,147,483,647	Size of byte pointer in memory accesses
Key starting position within record	32,767 bytes	Index descriptor key position field is an "integer"
Number of Profiles	see below	Index descriptor table size (32,767), number of Profiles and number of keys
Number of keys within a Profile	6,550	Index descriptor table size (32,767) less 12. Each key descriptor requires 5 bytes.
Total key size within a Profile with no duplicates allowed	16,372 bytes	(Coarse table size less 4)/2 - 9.
Total key size within a Profile with duplicates allowed	16,376 bytes	(Coarse table size less 4)/2 - 5

Remember that any numeric key requires 8 bytes in 1.3 and prior.

Number of Profiles is limited by a combination of factors. The following relationship must hold:

Implications on LINC

• LU; EVERY reads records from the DAT via an implied Profile, such as the standard Component ordinate profile; thus records will be retrieved in a logical order. Even the EVENT has an implied Profile, and LU; EVERY EVENT will return records in the order they were added; thus results may differ from host LINC on some platforms where the Event would be read in physical order.
• DT; ACTUAL (<component>) reads the DAT file directly, skipping over purged records (records ending in hex 00). Note that due to record purging and re-additions, this order likely will not match the results of a LU; EVERY.
• Upon initial opening of a file, up to 7000 records may be added. After that, D-ISAM is instructed to do a "commit" after each record addition so that memory locks may be freed. Thus, records will add quickly at first, then quite slowly.
• Upon subsequent opens of a file, up to 7000 records may be added. After that, LB.STATUS is set to (*****) and no more records are added. (Why couldn't this be the same as initial open?)
• Upon subsequent opens of a file, up to 7000 records may be FLAGed. After that, the run time simply aborts. (They wanted to make it like the A-series 50,000 record limit, but smaller because it's a PC.) Note that EXCLUSIVE.USE is not available on the PC.
• Therefore, when loading test data, be cognizant of what's going on! Same for testing reports which update many records. The best approach is make the report recoverable (using your own pointers/logic), close the report and re-run the report.