Performance considerations for logical relationships

Logical parent pointers

The logical child segment on DASD has a pointer to its logical parent. You choose how this pointer is physically stored on external storage. Your choices are:

• Direct pointing (specified by coding POINTER=LPARNT in the SEGM statement for the logical child)
• Symbolic pointing (specified by coding the PHYSICAL operand for the PARENT= keyword in the SEGM statement for the logical child)
• Both direct and symbolic pointing

The advantages of direct pointers are:

• Because direct pointers are only 4 bytes long, they are usually shorter than symbolic pointers. Therefore, less DASD space is generally required to store direct pointers.
• Direct pointers usually give faster access to logical parent segments, except possibly HDAM or PHDAM logical parent segments, which are roots. Symbolic pointers require extra resources to search an index for a HIDAM database. Also, with symbolic pointers, DL/I has to navigate from the root to the logical parent if the logical parent is not a root segment.

The advantages of symbolic pointers are:

• Symbolic pointers are stored as part of the logical child segment on DASD. Having the symbolic key stored on DASD can save the resources required to format a logical child segment in the user's I/O area. Remember, the symbolic key always appears in the I/O area as part of the logical child. When retrieving a logical child, IMS has to construct the symbolic key if it is not stored on DASD.
• Logical parent databases can be reorganized without the logical child database having to be reorganized. This applies to unidirectional and bidirectional physically paired relationships (when symbolic pointing is used).

Symbolic pointing must be used:

• When pointing to a HISAM logical parent database
• If you need to sequence logical child segments (except virtual logical children) on any part of the symbolic key

KEY/DATA considerations

When you include a concatenated segment as part of a logical DBD, you control how the concatenated segment appears in the user's I/O area. You do this by specifying either KEY or DATA on the SOURCE= keyword of the SEGM statement for the concatenated segment. A concatenated segment consists of a logical child followed by a logical (or destination) parent. You specify KEY or DATA for both parts. For example, you can access a concatenated segment and ask to see the following segment parts in the I/O area:

• The logical child part only
• The logical (or destination) parent part only
• Both parts

By carefully choosing KEY or DATA, you can retrieve a concatenated segment with fewer processing and I/O resources. For example:

• Assume you have the unidirectional logical relationship shown in the following figure.

  Figure 1. Example of a unidirectional logical relationship

  

• Assume you have the logical structure shown in the following figure.

  Figure 2. Example of a logical structure

  

• Finally, assume you only need to see the data for the LINEITEM part of the concatenated segment.

You can avoid the extra processing and I/O required to access the MODEL part of the concatenated segment if you:

• Code the SOURCE keyword of the concatenated segment's SEGM statement as:

  SOURCE=(lcsegname,DATA,lcdbname),(lpsegname,KEY,lpdbname)

• Store a symbolic logical parent pointer in LINEITEM. If you do not store the symbolic pointer, DL/I must access MODEL and PRODUCT to construct it.

To summarize, do not automatically choose DATA sensitivity for both the logical child and logical parent parts of a concatenated segment. If you do not need to see the logical parent part, code KEY sensitivity for the logical parent and store the symbolic logical parent pointer on DASD.

Sequencing logical twin chains

With virtual pairing, it is possible to sequence the real logical child on physical twin chains and the virtual logical child on logical twin chains. If possible, avoid operations requiring that you sequence logical twins. When a logical twin chain is followed, DL/I usually has to access multiple database records. Accessing multiple database records increases the resources required to process the call.

This problem of increased resource requirements to process calls is especially severe when you sequence the logical twin chain on all or part of the symbolic logical parent pointer. Because a virtual logical child is not stored, it is necessary to construct the symbolic logical parent pointer to determine if a virtual logical child satisfies the sequencing operation. DL/I must follow physical parent pointers to construct the symbolic pointers. This process takes place for each virtual logical child in the logical twin chain until the correct position is found for the sequencing operation.

Placement of the real logical child in a virtually paired relationship

In placing the real logical child in a virtually paired relationship, here are some considerations:

• If you need the logical child sequenced in only one of the logically related databases, put the real logical child in that database.
• If you must sequence the logical child in both logically related databases, put the real logical child in the database from which it is most often retrieved.
• Try to place the real logical child so logical twin chains are as short as possible. This placement decreases the number of database records that must be examined to follow a logical twin chain.