DL/I and CA IDMS/DB Correspondences

CA IDMS DLI Transparency allows a DL/I application program to access a CA IDMS/DB database. To support this access, you must define a CA IDMS/DB schema and subschema that correspond to the specific DBD and PSB definitions expected by the application. For example, for each DL/I segment, hierarchy, and logical relationship, you must make sure that there is a corresponding CA IDMS/DB record type and set structure. For more information on the rules for defining schemas and subschemas, see the CA IDMS Database Administration Section.
idms
CA IDMS DLI Transparency allows a DL/I application program to access a CA IDMS/DB database. To support this access, you must define a CA IDMS/DB schema and subschema that correspond to the specific DBD and PSB definitions expected by the application. For example, for each DL/I segment, hierarchy, and logical relationship, you must make sure that there is a corresponding CA IDMS/DB record type and set structure. For more information on the rules for defining schemas and subschemas, see the
CA IDMS Database Administration Section
.
The following table summarizes the required correspondences between DL/I and CA IDMS/DB.
DL/I structure
CA IDMS/DB equivalence
Segment
Record
Parent segment
Owner record
Child segment
Member record
Parent/child relationship
Set relationship where parent is the owner and the child is the member
Child segment with a sequence field
Member record of a sorted set
Sequence field for a dependent segment
Sort key
Unsequenced child segments with insert rules as follows:
HERE
FIRST
LAST
Member record of a set with an order option as follows:
PRIOR
FIRST
LAST
Child segments with nonunique sequence fields with an insert rule as follows:
FIRST
LAST
Member record of a sorted set with the following duplicates option:
FIRST
LAST
Child segments with nonunique sequence fields with an insert rule of HERE*
Member record of a set with a set order option of PRIOR
Logical relationship
Physical parent segment
Logical parent segment
Logical child segment
Many to many relationship
Owner record
Owner record
Junction record
Dependent segments in a physical access database
Members of a CA IDMS/DB set
Root segment in an ACCESS=HDAM database
CALC record
Root segment in an ACCESS=HISAM database
DIRECT record in a SYSTEM-owned indexed set; ascending or descending sort order on the record's symbolic key (equivalent to the sequence field of the HISAM root segment)
Root segment in an ACCESS=INDEX database (pointer segment)
Member record in a SYSTEM-owned indexed set; ascending sort order on the record's symbolic key (equivalent to the sequence field of the index pointer segment); also, VIA member in a set owned by the target record
Pointer segment (root segment in the corresponding ACCESS=INDEX database)
Member record in a SYSTEM-owned indexed set; ascending sort order on the record's symbolic key (equivalent to the sequence field of the index pointer segment); also, VIA member in a set owned by the target record
Target segment (root segment)
CALC record that owns the pointer record in the target-pointer set
Secondary index target segment
Owner record of a target-pointer set
Pointer segment (root segment of the corresponding ACCESS=INDEX database)
Record that is a member of an indexed set sorted in ascending order on the value of the sort key (i.e. the sequence field for the equivalent segment); record is also a VIA member of a set owned by the target record
ACCESS=HIDAM database:
Root segment (target segment)
Record equivalents for ACCESS-HIDAM database:
CALC record that owns a pointer record through the target-pointer set
*Special considerations apply to insert rules (see Sequenced and Unsequenced Child Segments).
Segments and Record Types
For each segment defined in a physical DBD, there must be a corresponding record type in a CA IDMS/DB schema. Segments from logical DBDs are exceptions and must not appear in the schema. Logical segments are redefinitions of segments already defined in physical DBDs.
The CA IDMS DLI Transparency syntax generator creates the necessary correspondences in the resulting schema, subschema, and DMCL source. You do not have to code the CA IDMS/DB definitions sectionly.
Sequenced and Unsequenced Child Segments
CA IDMS/DB requires different definitions for child segments, depending on whether they are sequenced or unsequenced.
Sequenced Child Segments
Sequenced child segments correspond to member record types in sorted sets. The child segment's sequence field is used for the sort key in the CA IDMS/DB sorted set.
  • If the child segment is defined for U (unique) sequence field values, duplicates are not allowed for the set (DUPLICATES NOT ALLOWED).
  • If the child segment is defined for M (multiple or duplicate) sequence field values, the value for the insert RULES parameter determines where duplicate fields are stored within the set sequence:
    • FIRST
      ── the set is ordered DUPLICATES FIRST.
    • LAST
      ── the set is ordered DUPLICATES LAST.
    • HERE
      ── the corresponding record type is a member in an unsorted set with a set order option of PRIOR.
Unsequenced Child Segments
Unsequenced child segments correspond to member record types in unsorted sets. The set ORDER option is determined by the value for the RULES parameter on the child's SEGM statement:
  • HERE
    ── Corresponds to an order option of PRIOR.
  • FIRST
    ── Corresponds to an order option of FIRST.
  • LAST
    ── Corresponds to an order option of LAST. Note that LAST is the DL/I default for unsequenced segments. If a child segment does not have RULES specified, LAST is used for the order option in the corresponding unsorted set.
Deletable Segments
If a DL/I segment can be deleted, the corresponding record type must have prior pointers. As a rule,
all
sets should have prior pointers.
Hierarchies and Sets
Parent/Child Relationships Correspond to Sets
DL/I parent/child relationships (hierarchies) correspond to CA IDMS/DB sets. There must be a CA IDMS/DB set for each physical parent/child relationship. In a CA IDMS/DB set, the owner record type corresponds to the parent segment, and the member record type corresponds to the child segment.
With CA IDMS DLI Transparency, CA IDMS/DB sets can have only one member record type. Multi-member sets are not allowed.
DL/I Hierarchies and CA IDMS/DB Sets
The diagram below shows a sample DL/I hierarchy converted to a series of CA IDMS/DB sets.
IDMSDB--Hierarchies and Sets
Figure 20. DL/I hierarchies and CA IDMS/DB sets
Logical Relationships and Sets
In CA IDMS DLI Transparency, each segment in a logical relationship corresponds to one of three CA IDMS/DB record types.
Junction Record
The
logical child segment
is defined as a junction record that is a member of two sets. The owner of one set corresponds to the
physical parent segment
; the owner of the other set corresponds to the
logical parent segment
.
Owner and Member Records
If the DL/I physical and logical parents are the same segment, one record type is used to represent both parents. In this case, the record type is the owner of the two sets of which the junction record (equivalent to the logical child) is the member.
The junction record must always have a location mode of VIA. The VIA set is the set of which the record type for the physical parent is the owner. Note that database load procedures can override this consideration.
CA IDMS DLI Transparency requires that all logical relationships (that is, unidirectional, bidirectional virtual, and bidirectional physical) be implemented as bidirectional virtual relationships. The conversion to bidirectional virtual is transparent to an application. However, the conversion of bidirectional physical relationships requires special consideration.
Implementing a Bidirectional Physical Relationship
To implement a bidirectional physical relationship as a bidirectional virtual relationship in CA IDMS/DB, a record type is defined for each of the parent segments. Additionally, a single record type is used to represent the physically paired child segments. This record type is defined as a VIA junction record in the set owned by each of the parent record types. In bidirectional virtual terms, the junction record type becomes the equivalent of the real logical child and the virtual logical child.
DL/I Logical Relationship and CA IDMS/DB Sets
The following diagram illustrates a DL/I bidirectional virtual relationship and the CA IDMS/DB set structures used to implement it.
IDMSDB--Logical Relationships and Sets
Figure 21. DL/I logical relationship and corresponding CA IDMS/DB sets
DL/I Access Methods in CA IDMS/DB
Each of the four access methods allowed for physical DBDs requires a different implementation in CA IDMS/DB. The HSAM, HISAM, HDAM, and HIDAM access methods are discussed below.
HSAM
CA IDMS DLI Transparency does not implement HSAM databases directly. However, the indirect implementation is transparent to any DL/I application using an HSAM database. The CA IDMS DLI Transparency implementation depends on whether the HSAM database is sequenced or unsequenced:
  • A
    sequenced HSAM database
    has a root segment that is sorted on the basis of its sequence field. A sequenced HSAM database is defined in the same way as a HISAM database (see "HISAM" below). In the schema, the root segment of the HSAM database is treated as the root segment of a HISAM database. Once the HSAM database is defined as a HISAM database, the appropriate structures are defined in the corresponding CA IDMS/DB schema.
  • An
    unsequenced HSAM database
    is defined as a separate area in the CA IDMS/DB schema. This area contains only the record types and sets needed to reflect the HSAM segments and their hierarchies. All record types are defined with a location mode of DIRECT.
HISAM
CA IDMS DLI Transparency relates the root segment in the HISAM database to the member record type in a system-owned indexed set. The member record has a location mode of DIRECT; its symbolic key corresponds to the root segment's sequence field. If it is necessary to keep the member record (the root segment equivalent) in physical sequential order, ascending or descending order is defined for its symbolic key.
For more information on indexed sets, see the
CA IDMS Database Administration Section
.
Sample HISAM Database and CA IDMS/DB Sets
The diagram below, shows a sample HISAM database and the CA IDMS/DB sets used to implement it.
IDMSDB--DL/I Access Methods in CA IDMS/DB
Figure 22. Sample HISAM database and corresponding CA IDMS/DB sets
HDAM
In CA IDMS DLI Transparency, the root segment in an HDAM database corresponds to an owner record type with a location mode of CALC. The root segment's sequence field is defined as the CALC key.
Sample HDAM Hierarchy and CA IDMS/DB Sets
The diagram below shows a sample HDAM hierarchy and the corresponding CA IDMS/DB set structures.
IDMSDB--DL/I Access Methods in CA IDMS/DB (2)
Figure 23. Sample HDAM hierarchy and corresponding CA IDMS/DB sets
HIDAM
As with an HDAM database, the HIDAM root segment is defined as an owner record with a location mode of CALC. The root segment's sequence field becomes the CALC key.
In a HIDAM database, the root segment is also the source and target segment for the associated index database. To account for the index pointer segment, a member record type is defined with a location mode of VIA within an indexed set owned by the CALC owner record type. The index record contains a single element to match the root segment's sequence field (CALC key in the owner record type). The index record also contains any data fields defined in the index. During processing, CA IDMS/DB maintains matching occurrences between the index (member) record and the owner of the set.
Sample HIDAM Hierarchy and CA IDMS/DB Sets
The diagram below shows a sample HIDAM hierarchy and the corresponding CA IDMS/DB set structures.
IDMSDB--DL/I Access Methods in CA IDMS/DB (3)
Figure 24. Sample HIDAM hierarchy and corresponding CA IDMS/DB sets
DL/I Secondary Indexes in CA IDMS/DB
A DL/I secondary index involves a primary database and an index database. The primary database contains a source and a target segment. The index database contains an index pointer segment, which is also the root segment.
Define Index Pointer Segment as Member Record
In CA IDMS DLI Transparency, the index pointer segment is defined as a member record type with a location mode of VIA in a set owned by the target record. The pointer segment is also defined as a member record in a system-owned indexed set. This set is sorted in ascending order on the pointer record's symbolic key, which is equivalent to the sequence field in the pointer segment.
CA IDMS/DB does not require a separate set to reflect the source segment and pointer segment relationship.
Implementing Pointer and Target Relationships in CA IDMS/DB
The illustration below illustrates the CA IDMS/DB set structure that relates the pointer and target segments. Note that this relationship is the same for a secondary index and a HIDAM index database.
IDMSDB--DL/I Secondary Indexes in CA IDMS/DB
Figure 25. CA IDMS/DB implementation of pointer and target relationship
DL/I Secondary Index and CA IDMS/DB Sets
The following diagram shows a secondary index for an HDAM primary database and the corresponding CA IDMS/DB set structures. Note that the primary database is an HDAM database and the pointer segment is in the index (secondary) database.
IDMSDB--DL/I Secondary Indexes in CA IDMS/DB (2)
Figure 26. DL/I secondary index and corresponding CA IDMS/DB sets
Parallel Processing Support in CA IDMS/DB
CA IDMS DLI Transparency supports DL/I parallel processing in two ways:
  • Multiple PCBs
    ── A CA IDMS/DB subschema can include definitions to reflect any number of PCBs in a corresponding PSB, with no limitation on the DL/I structures contained in the PCBs. For example, when two PCBs that define the same hierarchy are both used by a DL/I application, CA IDMS DLI Transparency will maintain database positioning (currency) independently for each PCB.
  • Multiple positioning
    ── The DL/I PCB statement allows you to optionally specify separate positioning for each hierarchical path in a database definition. CA IDMS DLI Transparency will maintain separate currency for each CA IDMS/DB structure that corresponds to one of the DL/I hierarchies.
DL/I Calls in CA IDMS/DB
DL/I Database Calls
CA IDMS DLI Transparency supports all of the DL/I database calls and all of the DL/I command codes shown in the tables below.
Call Function
Meaning
GU
GET UNIQUE
GN
GET NEXT
GNP
GET NEXT WITHIN PARENT
GHU
GET HOLD UNIQUE
GHN
GET HOLD NEXT
GHNP
GET HOLD NEXT WITHIN PARENT
ISRT
INSERT
DLET
DELETE
REPL
REPLACE
DL/I Command Codes
Code
Purpose
C
Allows use of concatenated keys in SSAs
D
Specifies path calls (that is, allows retrieval, modification, or insertion of several segments with one call)
F
Permits search for a segment to start at the first occurrence under its parent, regardless of positions.
L
Causes the last occurrence of a segment type to be used in satisfying a call
N
Prevents the replacement of the specified segment(s) following a path retrieval call
P
Establishes parentage at the specified level when used with a retrieval call
U
Maintains current positioning at the specified level
V
Maintains current positioning at all levels higher than the specified level
- (null command code)
Causes no special processing to occur
Extensions to Basic Calls
As extensions to the basic calls shown in the DL/I command codes table above, CA IDMS DLI Transparency also supports:
  • Path calls
    ── Calls used to retrieve, modify, or insert multiple segments in a hierarchical path.
  • Qualified and unqualified calls
    ── Calls specified with or without segment search arguments (SSAs).
  • Qualified and unqualified SSAs
    ── SSAs with qualification statements or qualified by segment type only.
DL/I System Service Calls
The following DL/I system service calls are also supported under CA IDMS DLI Transparency:
  • PCB
    ── Schedules a PSB call (used only with CICS)
  • TERM
    ── Terminates a PSB call (used only with CICS)
  • ROLL and ROLB
    ── Treated as a DML ROLLBACK request
  • CHKP (CHECKPOINT)
    ── Treated as a DML COMMIT request
Usage Considerations
When defining the CA IDMS/DB equivalents for your DL/I structures, keep in mind the following usage considerations:
  • CA IDMS DLI Transparency does not support multiple noncontiguous sequence fields for a virtual logical segment. A single sequence field, however, is supported.
  • CA IDMS DLI Transparency always uses the following delete rules:
    physical
    ,
    virtual
    ,
    logical
    , for the physical parent, logical child, and logical parent, respectively. Refer to the appropriate DL/I documentation for a description of the delete rules.
  • CA IDMS DLI Transparency supports sparse indexing through null-value specifications or index suppression exits. If you use index suppression exits, you must convert the exits to CA IDMS/DB database procedures.
    For more information on a detailed description of index suppression exits, see Index Suppression Exit Support.
  • You must convert segment edit/compression exits to CA IDMS/DB database procedures.
  • CA IDMS DLI Transparency supports PROCOPT E on the PCB statement. To reflect this processing option, you must specify EXCLUSIVE for the CA IDMS/DB area ready option.
  • CA IDMS DLI Transparency automatically supports PROCOPT O and requires no additional specification for it.