RECORD SECTION

The RECORD SECTION names the CA IDMS/DB records to be used either explicitly or implicitly to satisfy DL/I calls, and defines the DL/I fields to be referenced in SSA parameter lists used in DL/I database requests. The RECORD SECTION consists of RECORD statements and FIELD statements.
idms19
The RECORD SECTION names the CA IDMS/DB records to be used either explicitly or implicitly to satisfy DL/I calls, and defines the DL/I fields to be referenced in SSA parameter lists used in DL/I database requests. The RECORD SECTION consists of RECORD statements and FIELD statements.
The RECORD SECTION draws upon information in the:
  • CA IDMS/DB schema
  • DL/I PSB
    Since each PSB requires a separate IPSB, the information in one PSBGEN statement is used to complete each RECORD SECTION.
  • DL/I DBDs
    The DBDs required are those specified in the PCBs. You should have available all of the DBDs specified in each PCB within the PSB.
    If a PCB calls for a logical database or an index database, you also need the DBDs for the associated physical databases or indexed databases, respectively.
    When a PCB calls for a HIDAM database or a database with a secondary index(es), you should have available the DBD for the associated index database.
Contents
Syntax
►►─── RECORD SECTION. ────────────────────────────────────────────────────────►    ►─── RECORD statements. ─────────────────────────────────────────────────────►    ►─── FIELD statements. ──────────────────────────────────────────────────────►◄
Parameters
  • RECORD SECTION.
    RECORD SECTION must be the first entry in the section followed by RECORD and FIELD statements.
  • RECORD statements
    Following the RECORD SECTION is one RECORD statement for each DL/I segment specified in every PCB in the application program's PSB. The RECORD statement defines the CA IDMS/DB record that corresponds to the DL/I segment.
    In addition to these
    explicit correspondences
    , you must make sure that there are RECORD statements for those records whose corresponding segments are not specified in the PCBs but must be accessed by DL/I to process DL/I calls. These
    implicit correspondences
    are required for the following types of segments:
    • Dependent segments of any segment specified in the PCB if the specified parent segment can be deleted (that is, PROCOPT=A or PROCOPT=D appears in the PCB or SENSEG statement)
    • All dependent segments of the preceding dependent segments
    • Pointer segments for all target and source segments specified in the PCB
    • Source segments for all target segments specified in the PCB
    • All segments in the hierarchical path of the destination parent segment in its physical database
  • FIELD statements
    There can be from 0 to 255 FIELD statements following each RECORD statement. The sources for these FIELD statements consist of the appropriate FIELD statements within the relevant DBDs.
The RECORD and FIELD statements are discussed in detail below.
RECORD Statement
A RECORD statement names a CA IDMS/DB record and optionally specifies either the type of CA IDMS/DB ERASE command issued or that a DISCONNECT command was issued. The CA IDMS/DB ERASE or DISCONNECT command is issued in response to a DL/I DLET call for the segment corresponding to the named record.
To determine the RECORD statements required for an IPSB:
  1. Locate the PSB that corresponds to the IPSB being coded
  2. Locate the PCBs in this PSB
  3. If a PCB names a physical DBD (that is, with ACCESS=HDAM, HSAM, HISAM, HIDAM, or INDEX), use the following sectionlines:
    • Locate the DBD named in the PCB.
    • Prepare for each DBD a hierarchy diagram showing each segment defined in the DBD.
    • Check off all the segments specified in each PCB within the PSB. Each of these segments will need a corresponding CA IDMS/DB record, which is to be described in a RECORD statement.
    • Check off all those segments in the hierarchy diagrams that meet one of the following conditions:
      • The segment is a dependent segment of any segment that is both specified in the PCB and is subject to deletion.
      • The segment is a source segment associated with a target segment that is specified in the PCB.
      • The segment is a pointer segment associated with a target segment that is a segment specified in the PCB or a dependent of a segment specified in the PCB. The pointer segment for a target segment is located in the associated index DBD.
  4. If the PCB names a logical DBD (that is, with ACCESS=LOGICAL), use the following sectionlines:
    • Find both the logical DBD and the associated physical DBDs.
    • Note each SEGM statement in the logical DBD with only one SOURCE parameter. In each of these SEGM statements, the SOURCE parameter identifies the segment in the physical database. Identify the corresponding CA IDMS/DB record for each of these physical segments.
    • Locate each SEGM statement that defines a concatenated segment. Identify the real logical child segment and the destination parent segment and locate the names of their corresponding CA IDMS/DB records.
    • Prepare hierarchy diagrams of the two associated physical databases. Using the diagram containing the destination parent segment, check off all the segments in the hierarchical path of the destination parent segment. For each of the checked off segments, identify the corresponding CA IDMS/DB record.
    • Note if any of the identified segments from the above sectionlines can be deleted. If this is the case, note all of the dependents of this segment. (Do not include virtual logical child segments.) For each noted segment, identify the corresponding CA IDMS/DB record.
    • Note if any of the segments identified in the above sectionlines is a source segment or a target segment of either a HIDAM database or a secondary index. If this is the case, locate the associated index pointer segment, which is defined in a DBD with ACCESS=INDEX. Then, identify the corresponding CA IDMS/DB record for the index pointer segment.
    • Make sure there is a RECORD statement for each of the records identified in the above sectionlines.
Syntax
►►─── RECORD SECTION ── . ───────────────────────────────────────────────────►    ►─── RECORD name is idms-record-name ───────────────────────────────────────►    ►─── LENGTH is ─┬─ dl1-segment-length ────────────────────────────┬─────────►                  └─ dl1-max-segment-length dl1-min-segment-length ─┘    ►─┬───────────────────────────────────────────────┬─────────────────────────►◄    └─ DELete by ──┬── ERASE ALL ◄──────┬─── . ─────┘                   ├── ERASE PERManent ─┤                   ├── ERASE SELective ─┤                   └── DISConnect ──────┘
Parameters
  • RECORD name is
    idms-record-name
    Identifies the CA IDMS/DB record to be accessed by the CA IDMS DLI Transparency run-time interface.
    Idms-record-name
    must be a 1- to 16-character name that corresponds to a DL/I segment and must be defined in the subschema named in the IPSB SECTION.
  • LENGTH is
    Specifies the length of the DL/I segment to which the
    idms-record-name
    corresponds.
  • dl1-segment-length
    Specifies the length of the DL/I segment if it is a fixed-length segment.
  • dl1-max-segment-length dl1-min-segment-length
    Specifies the maximum and minimum lengths of the DL/I segment if it is a variable-length segment. See "Determining values for variable length segments" under "Examples" later in this section.
  • DELete by
    Specifies the CA IDMS/DB DML command that the interface will issue in response to a DL/I DLET call for the segment corresponding to the named record.
  • ERASE ALL
    Specifies that the named record and all mandatory and optional member record occurrences it owns are to be erased.
    All members that are owners of any set occurrences are treated as if they were the object of an ERASE ALL statement.
    ERASE ALL is the default.
  • ERASE PERManent
    Specifies that the named record and all mandatory member record occurrences it owns are to be erased from the database. Optional member record occurrences are disconnected.
    All erased mandatory members that are owners of set occurrences are treated as if they were the object of an ERASE PERMANENT statement.
    For more information on CA IDMS/DBset membership options, see the
    CA IDMS Database Administration Section
  • ERASE SELective
    Specifies that the named record and all mandatory member record occurrences it owns are to be erased from the database. Optional member record occurrences are erased only if they do not currently participate as members in other set occurrences.
    All erased members that are owners of set occurrences are treated as if they were the object of an ERASE SELECTIVE statement.
  • DISConnect
    Specifies that the membership of the named record is cancelled from all sets in which it currently participates as an optional member. The record, however, remains in the database.
Usage
Determining the Value for a Fixed Length Segment
To locate the
dl1-segment-length
, find the SEGM statement defining the segment that corresponds to the named record. Use the entry in the SEGM statement's BYTES clause for
dl1-segment-length
.
Note that if the DL/I segment is a logical child segment, the length of the physical and/or logical parent concatenated key may be required along with the BYTES clause entry when determining the value of
dl1-segment-length
.
Determining Values for Variable Length Segments
To locate
dl1-max-segment-length
and
dl1-min-segment-length
values, find the SEGM statement defining the segment that corresponds to the named record. Use the first entry in the SEGM statement's BYTES clause for
dl1-max-segment-length
; use the second entry in the SEGM statement's BYTES clause for
dl1-min-segment-length
.
Note that if the DL/I segment is a logical child segment, the length of the physical and/or logical parent concatenated key may be required along with the BYTES clause entries when determining the value for
dl1-max-segment-length
and
dl1-min-segment-length
.
Calculating the Length of a Concatenated Key
The length of a concatenated key equals the sum of the lengths of the sequence field, from the sequence field of the named key through the root segment's sequence field.
IDMSDB--RECORD Statement
Figure 36. Finding the length of a concatenated key
Determining Record Length for Logical Child Equivalent
The examples below show how you can determine the record length for the logical child equivalent.
Refer to "LOGICAL PARENT FIELD Statement" later in this section for details on determining whether the physical parent concatenated key and the logical parent concatenated key are stored virtually or physically.
Example 1
Assume the LPCK is stored virtually and the PPCK is stored physically.
IDMSDB--RECORD Statement (2)
  1. Find the LPCK's length. Subtract this key length from the entry(ies) in the logical child's BYTES clause.
  2. Find the PPCK's length. Add this key length to the value calculated in step 1 above:
    For fixed-length segments
    :
    dl/i-segment-length
    = (BYTES entry - LPCK-length) + PPCK-length
    For variable-length segments
    :
    dl/1-max-segment-length
    = (First BYTES entry - LPCK-length) + PPCK-length
    dl/1-min-segment-length
    = (Second BYTES entry - LPCK-length) + PPCK-length
Example 2
IDMSDB--RECORD Statement (3)
Assume both the PPCK and the LPCK are stored virtually.
IDMSDB--RECORD Statement (4)
Find the LPCK's length. Subtract this key length from the entry(ies) in the logical child's BYTES clause:
For fixed length segments
:
dl/i-segment-length
= BYTES entry - LPCK-length
For variable length segments
:
dl/1-max-segment-length
= First BYTES entry - LPCK-length
dl/1-min-segment-length
= Second BYTES entry - LPCK-length
Example 3
Assume that the logical parent concatenated key (LPCK) is stored physically and the physical parent concatenated key (PPCK) is stored virtually.
IDMSDB--RECORD Statement (5)
Use the BYTES parameter value(s) in the logical child's SEGM statement as the value(s) for the LENGTH parameter:
For fixed length segments
:
dl/i-segment-length
= BYTES entry in logical child's SEGM statement
For variable length segments
:
dl/1-max-segment-length
= First BYTES entry in logical child's SEGM statement
dl/1-min-segment-length
= Second BYTES entry in logical child's SEGM statement
Example 4
Assume both the LPCK and the PPCK are stored physically.
IDMSDB--RECORD Statement (6)
Find the PPCK's length. Add this key length to the entry(ies) in the logical child's BYTES clause:
For fixed length segments
:
dl/i-segment-length
= PPCK-length + BYTES entry in logical child's SEGM statement
For variable length segments
:
dl/1-max-segment-length
= PPCK-length + first BYTES entry in logical child's SEGM statement
dl/1-min-segment-length
= PPCK-length + second BYTES entry in logical child's SEGM statement
FIELD Statement
A FIELD statement defines a DL/I field within the named record and corresponds to the FIELD statement in the DBD. Following each RECORD statement, there must be a FIELD statement for every field listed in the DBD for the segment corresponding to the named record. Some records (that is, those corresponding to the logical child segments) will need additional FIELD statements, as explained below. Up to 255 FIELD statements can follow each RECORD statement. If, however, a named record corresponds to a segment for which no fields are defined in the DBD, the RECORD statement stands alone without any FIELD statements.
Five FIELD Statement Formats
There are five FIELD statement formats available:
  • Sequence
    -- Defines DL/I sequence fields
  • Field
    -- Defines DL/I search fields other than sequence fields
  • Logical parent
    -- Defines logical parent concatenated key fields
  • Physical parent
    -- Defines physical parent concatenated key fields
  • Logical sequence
    -- Defines logical sequence fields (that is, sequence fields for the virtual logical child segments)
How to Determine the Appropriate FIELD Statement Format
To determine which format of the FIELD statement is appropriate to define a particular DL/I field, first consider the segment equivalent of the record being described in the RECORD statement. Find the SEGM statement defining the segment and determine whether the segment is a root segment, a dependent segment (that is, with only one parent), or a logical child segment (that is, with two parents). After making this determination, apply the appropriate set of rules as follows:
  • Root and dependent segments
    -- If the segment is either a root segment or a dependent segment, note its sequence field (if any). Define this sequence field by using the SEQUENCE FIELD statement. This FIELD statement must appear immediately following the appropriate RECORD statement. Next, determine if the segment has search fields (that is, fields defined without a SEQ in the NAME clause of the FIELD statement). If there are search fields, each one must be defined by using the FIELD statement. Each of these FIELD statements must appear under the appropriate RECORD statement.
  • Logical child segment
    -- If the segment is a logical child segment, the RECORD statement must be followed by LOGICAL PARENT FIELD and PHYSICAL PARENT FIELD statements to define the logical parent concatenated key field and the physical parent concatenated key field, respectively. Additionally, the logical child segment corresponding to the named record may have a sequence field. If so, define this sequence field with a SEQUENCE FIELD statement following the RECORD statement.
Define Search Fields with Separate FIELD Statement
Define each of the segment's search fields to the IPSB with a separate FIELD statement following the LOGICAL PARENT FIELD and PHYSICAL PARENT FIELD statements that define the logical parent concatenated key and the physical parent concatenated key, respectively. Next, locate the SEGM statement that defines the associated virtual logical child segment. This SEGM statement is generally not located in the same DBD as the SEGM statement that defines the logical child segment.
If the virtual logical child segment has a sequence field, a LOGICAL SEQUENCE FIELD statement is required to define the sequence field under the named record. For each of the remaining search fields for the virtual logical child segment, there must be a FIELD statement. Each of these FIELD statements must appear under the RECORD statement that identifies the record corresponding to the logical child segment.
USAGE Clause
Each of the five formats of the FIELD statement can end with the optional USAGE clause. As with DL/I, this clause is for documentation purposes only. This clause and the five FIELD statement formats are described separately below.
USAGE clause
The USAGE clause defines the data type of the named field. It is used at the
end
of each of the five formats of the FIELD statement and is not repeated for the individual formats of the FIELD statement.
Syntax
>─┬──────────────────────────────────┬──────────────────────────────────────><   └─ USAGE is ──┬── DISplay ◄──┬─ . ─┘                 ├── BINary ────┤                 └── PACKed ────┘
Parameters
  • USAGE is
    Specifies the data type of the named field. To determine the appropriate option, note the FIELD statement in the DBD.
  • DISplay
    Specify if the FIELD statement in the DBD specifies TYPE=C. DISPLAY is the default value.
  • BINary
    Specify if the FIELD statement in the DBD specifies TYPE=F, TYPE=H, or TYPE=X.
  • PACKed
    Specify if the FIELD statement in the DBD specifies TYPE=P.
SEQUENCE FIELD statement
This format of the FIELD statement defines the sequence field for the named record. A sequence field can be defined for:
  • Each record corresponding to a root segment
  • A dependent segment ordered under its physical parent, including the logical child segment
  • A pointer segment
Sequence fields defined for pointer records must comprise the concatenation of the constant, search, and subsequence fields for the pointer segment. (Constant and subsequence fields are described below.)
A field defined as a sequence field can be used as a search field in an SSA.
Syntax
►►─┬─────────────────────────────────────────┬───────────────────────────────►    └─ SEQuence FIELD name is dl1-field-name ─┘    ►─┬──────────────────────────────────────────┬──────────────────────────────►    └─ STARTING POSition is starting-position ─┘    ►─┬──────────────────────────────┬──────────────────────────────────────────►◄    └─ LENgth is dl1-field-length ─┘
Parameters
  • SEQuence FIELD name is
    dl1-field-name
    Specifies the name of the sequence field.
    Dl1-field-name
    is the entry in the NAME clause of the DL/I FIELD statement defining the sequence field.
  • STARTING POSition is
    starting-position
    Specifies the position in the record in which the sequence field begins. Use the START clause value in the DL/I FIELD statement defining the sequence field.
  • LENgth is
    dl1-field-length
    Specifies the length of the sequence field. Use the BYTES clause entry in the DL/I FIELD statement defining the sequence field.
FIELD statement
This format of the FIELD statement defines the named record's search fields (that is, the search fields other than the sequence fields).
There must be a separate statement to define each search field in each record that corresponds to a segment with search fields.
For a record corresponding to a logical child segment, this format defines the search fields for the logical child segment and for the virtual logical child segment.
DL/I fields whose names begin with /CK or /SX are treated like any other search fields and are defined with this format of the FIELD statement.
Syntax
►►─┬────────────────────────────────┬────────────────────────────────────────►    └─ FIELD name is dl1-field-name ─┘    ►─┬──────────────────────────────────────────┬──────────────────────────────►    └─ STARTING POSition is starting-position ─┘    ►─┬──────────────────────────────┬──────────────────────────────────────────►◄    └─ LENgth is dl1-field-length ─┘
Parameters
  • FIELD name is
    dl1-field-name
    Names the DL/I field being defined. Use the NAME clause entry in the DL/I FIELD statement that defines the search field for the segment corresponding to the named record.
    Ensure that
    dl1-field-name
    is identical to the field name by which the DL/I application will refer to the field.
  • STARTING POSition is
    starting-position
    Specifies the position in the record in which the search field begins. Use the START parameter value in the DL/I FIELD statement that defines the search field. Omit this field if the name field is a /SX field.
  • LENgth is
    dl1-field-length
    Specifies the length of the search field. Use the BYTES parameter value in the DL/I FIELD statement that defines the search field.
LOGICAL PARENT FIELD statement
This format of the FIELD statement defines the logical parent concatenated key field for a record corresponding to a logical child segment. A logical parent concatenated key is a symbolic pointer to the logical parent.
LOGICAL PARENT FIELD statements and PHYSICAL PARENT FIELD statements (for defining the physical parent concatenated key field) are both required when the named record corresponds to a logical child segment.
Syntax
►►─┬────────────────────────────────────────────────────────────────┬────────►    └─ LOGical PARENT CONCATenated KEY FIELD name is dl1-field-name ─┘    ►─┬─────────────────────────────┬───────────────────────────────────────────►    └─ STORED ─┬── PHYSically ◄───┤               └── VIRTually ─────┘    ►─┬──────────────────────────────────────────┬──────────────────────────────►    └─ STARTING POSition is starting-position ─┘    ►─┬──────────────────────────────┬──────────────────────────────────────────►◄    └─ LENgth is dl1-field-length ─┘
Parameters
  • LOGical PARENT CONCATenated KEY FIELD name is
    dl1-field-name
    Specifies the name by which the concatenated key to the logical parent segment is defined to DL/I. Any 1- to 8-character name can be used for the
    dl1-field-name
    , since this name serves only as a filler.
    Ensure that the name selected for
    dl1-field-name
    is not used to define any other field for the named record.
  • STORED PHYSically/VIRTually
    Specifies whether the logical parent concatenatecd key is stored with the record corresponding to the logical child segment or is built by the CA IDMS DLI Transparency run-time interface.
  • PHYSically
    Specifies that the logical parent concatenated key is stored with the record corresponding to the logical child segment. The use of this option for the segment corresponding to the named record depends on the type of logical relationship defined in the relevant DBDs as follows:
Relationship
What to specify
Unidirectional and bidirectional virtual logical relationships
If PHYSICAL or P is specified on the SEGM statement PARENT parameter defining the real logical child segment, specify PHYSICALLY.
For bidirectional physical logical relationships, the relationship must appear like a bidirectional virtual logical relationship.
Choose one logical child segment to represent the real logical child segment and the other to represent the logical virtual child segment. Hence, the parent of the assigned real logical child segment is considered the physical parent segment; the parent of the assigned virtual logical child segment is considered the logical parent segment.
If the entry in the PARENT parameter of the SEGM statement defining the segment assigned as the real logical child segment is PHYSICAL or P, specify PHYSICALLY.
The default for this IPSB clause is PHYSICALLY.
If either of the destination parent concatenated key fields is STORED PHYSICALLY, that field must be the first field in the record.
If both destination parent concatenated key fields are STORED PHYSICALLY (see note below), they must be the first two fields in the record. These however, can be preceded by the halfword-length field if the record is a variable-length record. If PHYSICALLY is specified, the STARTING POSITION clause (see below) must be included in the FIELD statement.
  • VIRTually
    Specifies that the logical parent concatenated key is absent from the record corresponding to the logical child segment and is built by the run-time interface. The use of this option for the segment corresponding to the named record depends on the type of logical relationship defined in the relevant DBDs, as follows:
Relationship
What to specify
Unidirectional and bidirectional virtual logical relationships
Specify VIRTUALLY if VIRTUAL or V is specified in the PARENT parameter of the SEGM statement defining the real logical child segment.
For bidirectional physical logical relationships, the relationship must appear as a bidirectional virtual logical relationship, as described under bidirectional physical logical relationships above.
If the entry in the PARENT parameter of the SEGM statement defining the segment assigned as the real logical child segment is VIRTUAL or V, specify VIRTUALLY.
If VIRTUALLY is specified, you must omit the STARTING POSITION clause.
Although DL/I bidirectional virtual relationships permit only the logical parent concatenated key to be stored physically in the logical child, CA IDMS DLI Transparency allows either one or both of the concatenated keys to be stored physically or virtually.
  • STARTING POSition is
    starting-position
    Specifies the position in the record in which the concatenated key field begins, where the record begins in position 1. What you specify on this clause depends upon what you specified on the STORED VIRTUALLY/PHYSICALLY clause:
STORED VIRTUALLY/PHYSICALLY clause
STARTING POSITION clause
If STORED VIRTUALLY is specified for the named field
Don't include it for the named field.
If STORED PHYSICALLY is specified only for the named field (that is, only for the LOGICAL PARENT CONCATENATED KEY field)
START POSITION IS 1.
If both the named field and the PHYSICAL PARENT CONCATENATED KEY field (PHYSICAL PARENT FIELD statement) are STORED PHYSICALLY
One of the two fields will have a START POSITION of 1. The other field will begin in the next available byte after its complement concatenated key field is stored. For example, assume that the length of the concatenated key for the physical parent is 15 and the STARTING POSITION entered in the IPSB for the PHYSICAL PARENT is 1. Therefore, the LOGICAL PARENT KEY field has a START POSITION of 16.
When both concatenated keys are stored physically and the record is a variable length record
Perform the above calculations and add 2 to the start position to allow for the halfword containing the length of the record.
  • LENgth is
    dl1-field-length
    Specifies the length of the concatenated key for the logical parent.
    To determine the entry for this clause, first find the DL/I FIELD statements that define the sequence fields of the logical parent segment and of those segments in the logical parent's hierarchical path to the root segment. Add the BYTES clause entries in these FIELD statements.
Usage
The Length of the Concatenated Key for the Logical Parent
To calculate the length of the concatenated key for the logical parent, assume the DBD has the following entries from the root segment through the sequence field of the logical parent segment:
SEGM     NAME=SEGRT,PARENT=0,BYTES=31,PTR=TWINBWD FIELD    NAME=(FIELD1,SEQ,U),BYTES=21,START=,TYPE=C FIELD    NAME=FIELD2,BYTES=10,START=22 SEGM     NAME=LPSEG,PARENT=SEGRT,BYTES=20,PTR=TWINBWD FIELD    NAME=(FIELD3,SEQ,U),BYTES=60,START=1,TYPE=C
In this example, the sum of the sequence fields (FIELD1 and FIELD3) is 81, which is the value entered in the LENGTH clause of the IPSB FIELD statement. For more details, see Figure 36.
PHYSICAL PARENT FIELD statement
This format of the FIELD statement defines the physical parent concatenated key field for the record corresponding to the logical child segment. A physical parent concatenated key is a symbolic pointer to the logical parent. LOGICAL PARENT FIELD and PHYSICAL PARENT FIELD statements (used to define the logical parent concatenated key field) are both required when the named record corresponds to a logical child segment.
Syntax
►►─┬─────────────────────────────────────────────────────────────────┬───────►    └─ PHYSical PARENT CONCATenated KEY FIELD name is dl1-field-name ─┘    ►─┬─────────────────────────────┬───────────────────────────────────────────►    └─ STORED ─┬── PHYSically ◄───┤               └── VIRTually ─────┘    ►─┬──────────────────────────────────────────┬──────────────────────────────►    └─ STARTING POSition is starting-position ─┘    ►─┬──────────────────────────────┬──────────────────────────────────────────►◄    └─ LENgth is dl1-field-length ─┘
Parameters
  • PHYSical PARENT CONCATenated KEY FIELD name is
    dl1-field-name
    Specifies the name by which the concatenated key to the physical parent is defined to CA IDMS/DB. Any 1- to 8-character name can be used for the
    dl1-field-name
    , since this name serves only as a filler.
    Make sure that the name selected for
    dl1-field-name
    is not used to define any other field for the named record.
  • STORED PHYSically/VIRTually
    Specifies whether the physical parent concatenated key is stored with the record corresponding to the logical child segment or is built by the CA IDMS DLI Transparency run-time interface.
  • PHYSically
    Specifies that the physical parent concatenated key is stored with the record equivalent of the logical child segment.
    The default is PHYSICALLY. The following considerations apply to the use of this option:
Relationship
What to specify
When the named record corresponding to the logical child segment is participating in a bidirectional physical logical relationship.
In such cases, CA IDMS DLI Transparency requires that the logical relationship be made to appear as a bidirectional virtual logical relationship. As described above (in the STORED PHYSICALLY syntax rules under LOGICAL PARENT FIELD Statement), one of the logical child segments must be treated as the real logical child segment, and the other segment must be assigned as the virtual logical child segment. If PHYSICAL or P is entered in this parameter, specify PHYSICAL in the IPSB clause.
STORED PHYSICALLY.
If either of the destination parent concatenated key fields is stored physically, make that field the first physical field in the record.
If both destination parent concatenated key fields are stored physically (see the discussion of STORED PHYSICALLY/VIRTUALLY under "LOGICAL PARENT FIELD Statement"), they must be the first two physical fields in the record. These fields, however, can be preceded by the halfword-length field if the record is a variable-length record. If PHYSICALLY is specified, the STARTING POSITION clause (see below) must be included in the FIELD statement.
  • VIRTually
    Specifies that the physical parent concatenated key is absent from the record corresponding to the logical child segment and is built by the CA IDMS DLI Transparency run-time interface. The use of this option for the segment corresponding to the named record depends on the type of logical relationship defined in the relevant DBDs, as follows:
Relationship
What to specify
For unidirectional logical relationships and bidirectional virtual logical relationships
VIRTUALLY
For bidirectional physical logical relationships, CA IDMS DLI Transparency requires that one logical child segment be treated as the real logical child segment, and the other logical child segment be treated as the virtual logical child segment. (See the discussion of STORED PHYSICALLY under LOGICAL PARENT FIELD Statement.)
If the entry in the PARENT parameter of the SEGM statement defining the segment that is being treated as the virtual logical child segment specifies VIRTUAL or V
VIRTUALLY
If VIRTUALLY is specified, the STARTING POSITION clause must be omitted.
  • STARTING POSition is
    starting-position
    Specifies the position in the record in which the concatenated key field begins, where the record begins in position 1. Omit this clause if STORED VIRTUALLY is specified for the named field.
Relationship
What to specify
If STORED PHYSICALLY is specified only for the named field (that is, only for the LOGICAL PARENT CONCATENATED KEY field)
Specify START POSITION IS 1.
If both the named field and the LOGICAL PARENT CONCATENATED KEY field are stored physically, one of the fields will have a START POSITION of 1. The other field will begin in the next available byte after its complement concatenated key field is stored.
When both concatenated key fields are stored physically and the record is a variable-length record, add 2 to the START POSITION to allow for the halfword containing the length of the record.
  • LENGTH IS
    dl1-field-length
    Specifies the length of the concatenated key to the physical parent.
    To determine the entry for this clause, first find the DL/I FIELD statements that define the sequence fields of the physical parent segment and of those segments in the physical parent's hierarchical path to the root segment. Add the BYTES clause entries in these FIELD statements. The result is the entry for
    dl1-field-length
    .
LOGICAL SEQUENCE FIELD statement
This format of the FIELD statement defines the logical sequence field and its attributes. A logical sequence field must be defined for the named record corresponding to a logical child segment whenever the associated virtual logical child has a sequence field. A field defined as a logical sequence field can be used as a search field in an SSA.
Syntax
►►─┬─────────────────────────────────────────────────┬───────────────────────►    └─ LOGical SEQuence FIELD name is dl1-field-name ─┘    ►─┬──────────────────────────────────────────┬──────────────────────────────►    └─ STARTING POSition is starting-position ─┘    ►─┬──────────────────────────────┬──────────────────────────────────────────►◄    └─ LENgth is dl1-field-length ─┘
Parameters
  • LOGical SEQuence FIELD name is
    dl1-field-name
    Identifies the sequence field of the virtual logical child segment. Use the NAME clause entry in the DL/I FIELD statement defining the sequence field for the virtual logical child segment.
  • STARTING POSition is
    starting-position
    Specifies the position in the record in which the sequence field begins. Use the START clause entry in the DL/I FIELD statement defining the sequence field for the virtual logical child segment.
  • LENgth IS
    dl1-field-length
    Specifies the length of the sequence field. Use the BYTES clause entry in the DL/I FIELD statement defining the sequence field for the virtual logical child segment.
Usage
Sample PSB
This sample PSB calls for DBD1, which is shown in the hierarchy diagram in Figure 38. The DBD that defines DBD1 is shown in Figure 39. Figure 40 shows the resulting RECORD SECTION that is developed.
     PCB     TYPE=DB,DBDNAME=DBD1,PROCOPT=G,KEYLEN=45,PROCSEQ=INDEX1      SENSEG  NAME=SEGRT1,PARENT=0      SENSEG  NAME=SEG3,PARENT=SEGRT1      SENSEG  NAME=SEG4,PARENT=SEG3      SENSEG  NAME=SEG2,PARENT=SEGRT1      PSBGEN  LANG=COBOL,PSBNAME=PSB1      END
Figure 37. Sample PSB
Hierarchy Diagram of DBD1
This hierarchy diagram corresponds to database DBD1. SEGRT1, SEG2, SEG3, and SEG4 are specified in the PSB shown in Figure 37 and, therefore, require RECORD statements to define their equivalent records. SEG5 is indicated by broken lines because it is a virtual logical child segment, which is not a real segment.
IDMSDB--LOGICAL SEQUENCE FIELD statement
Figure 38. Hierarchy diagram of DBD1
Sample DBDs
DBD1 is the database called for by the PCB shown in Figure 37 DBD2 is the database that contains the logical parent segment of logical child SEG2 and the virtual logical child segment paired with SEG2. Information from the DBDs for both databases is required to complete the RECORD SECTION shown in Figure 40.
        DBD      NAME=DBD1,ACCESS=HDAM,RMNAME=(DLZHDC30,3,1800,3000)         DATASET  DD1=HDAM1,DEVICE=3350,BLOCK=2048,SCAN=3         SEGM     NAME=SEGRT1,PARENT=0,BYTES=115,POINTER=TWINBWD,RULES=PPV         FIELD    NAME=RT1KEY,SEQ,U,BYTES=11,START=1         FIELD    NAME=FIELD2,BYTES=5,START=1         FIELD    NAME=FIELD3,BYTES=6,START=6         SEGM     NAME=SEG2,PARENT=((SEGRT1),(LPSEGRT,P,DBD2)),                   BYTES=120,POINTER=TWIN6WD),RULES=(PLV)         FIELD    NAME=(KEY2,SEQ,U),BYTES=6,START=1         SEGM     NAME=SEG3,PARENT=SEGRT1,BYTES=10,POINTER=TWIN         FIELD    NAME=(KEY3,SEQ,U),BYTES=3,START=1         FIELD    NAME=FIELD5,BYTES=4,START=4         SEGM     NAME=SEG4,PARENT=SEG3,BYTES=6,POINTER=TWIN         FIELD    NAME=(KEY4,SEQ,U),BYTES=6,START=1         SEGM     NAME=SEG5,PARENT=SEG4,PTR=PAIRED,                   SOURCE=((LCSEG,DATA,DBD3))         FIELD    NAME=(KEY5,SEQ,U),BYTES=21,START=1,TYPE=F         FIELD    NAME=FIELD-5,BYTES=20,START=22,TYPE=F         DBDGEN         FINISH         END             DBD      NAME=DBD2,ACCESS=HDAM         DATASET  DD1=HDAM2,DEVICE=3350,BLOCK=2048,SCAN=3         SEGM     NAME=SEGRT2,PTR=TWINBWD,RULES=LLV         FIELD    NAME=(KEY6,SEQ,U),BYTES=60,START=1         FIELD    NAME=FIELD6,BYTES=15,START=61         FIELD    NAME=FIELD-7,BYTES=75,START=76         LCHILD   NAME=(SEG2,DBD1),PAIR=SEG6,PTR=DBLE         SEGM     NAME=SEG6,PARENT=SEGRT2,PTR=PAIRED                       SOURCE=(SEG2,DATA,DBD1)         FIELD    NAME=(KEY7,SEQ,U),BYTES=21,START=61         FIELD    NAME=FIELD8,BYTES=20,START=22         SEGM     NAME=SEG7 BYTES=200,PARENT=SEG1         FIELD    NAME=(KEY8,SEQ,U)BYTES=99,START=1         FIELD    NAME=FIELD9,BYTES=101,START=100         SEGM     NAME=SEG8,BYTES=100,PARENT=SEG1         FIELD    NAME=(KEY9,SEQ,U),BYTES=15,START=1         FIELD    NAME=FIELD10,BYTES=15,START=51         DBDGEN         FINISH         END
Figure 39. Sample DBDs
Sample RECORD SECTION
The information used to define this RECORD SECTION example is based on information in Figure 37 through Figure 39.
SEG5, defined in the first DBD shown in Figure 39, is omitted from this RECORD SECTION example because SEG5 is a virtual logical child segment. However, the fields of a virtual logical child segment are entered under the record corresponding to the logical child when the PSB calls for the associated logical child segment.
Thus, under REC2, which corresponds to SEG2 in DBD1, a logical sequence field and a search field are defined.
These two fields come from the virtual logical child segment (SEG6) located in DBD2, which is defined in the second DBD in Figure 39.
        RECORD SECTION.         RECORD NAME IS RECRT1 LENGTH IS 115.           SEQ FIELD NAME IS RT1KEY START POS 1 LENGTH 11.               FIELD NAME IS FIELD2 START POS 1 LENGTH 5.               FIELD NAME IS FIELD3 START POS 6 LENGTH 6.         RECORD NAME IS REC2 LENGTH IS 120         LOGICAL PARENT CONCAT KEY FIELD NAME IS FILFLD1                      STORED PHYSICALLY START POS 1 LENGTH 60.         PHYSICAL PARENT CONCAT KEY FIELD NAME IS FILFLD2                     STORED VIRTUALLY LENGTH 11.           SEQ FIELD NAME IS KEY2 START POS 1 LENGTH 6.           LOGICAL SEQUENCE FIELD NAME IS KEY7                     START POS 61 LENGTH 21.               FIELD NAME IS FIELD8 START POS 22 LENGTH 20.         RECORD NAME IS REC3 LENGTH IS 10.           SEQ FIELD NAME IS KEY3 START POS 1 LENGTH 3.               FIELD NAME IS FIELD5 START POS 4 LENGTH 4.         RECORD NAME IS REC4 LENGTH IS 6.           SEQ FIELD NAME IS KEY4 START POS 1 LENGTH 6.
Figure 40. Sample RECORD SECTION