Intersection data

When two segments are logically related, data can exist that is unique to only that relationship.

In the following figure, for example, one of the items ordered in ORDER 123 is 5000 bolts. The quantity 5000 is specific to this order (ORDER 123) and this item (bolts). It does not belong to either the order or item on its own. Similarly, in ORDER 123, 6000 washers are ordered. Again, this data is concerned only with that particular order and item combination.

This type of data is called intersection data, since it has meaning only for the specific logical relationship. The quantity of an item could not be stored in the ORDER 123 segment, because different quantities are ordered for each item in ORDER 123. Nor could it be stored in the ITEM segment, because for each item there can be several orders, each requesting a different quantity. Because the logical child segment links the ORDER and ITEM segments together, data that is unique to the relationship between the two segments can be stored in the logical child.

The two types of intersection data are: fixed intersection data and variable intersection data.

Fixed intersection data

Data stored in the logical child is called fixed intersection data. When symbolic pointing is used, it is stored in the data part of the logical child after the LPCK. When direct pointing is used, it is the only data in the logical child segment. Because symbolic pointing is used in the following figure, BOLT and WASHER are the LPCK, and the 5000 and 6000 are the fixed intersection data. The fixed intersection data can consist of several fields, all of them residing in the logical child segment.

Figure 1. Fixed intersection data
One ORDITEM in ORDER database has LPCK Bolt pointing to Bolt in ITEM database and fixed intersection data of QTY-ORDER: 5000. Other ORDITEM has LPCK Washer pointing to Washer in ITEM database and fixed intersection data of QTY-ORDER: 6000.

Variable intersection data

Variable intersection data is used when you have data that is unique to a relationship, but several occurrences of it exist. For example, suppose you cannot supply in one shipment the total quantity of an item required for an order. You need to store delivery data showing the quantity delivered on a specified date. The delivery date is not dependent on either the order or item alone. It is dependent on a specific order-item combination. Therefore, it is stored as a dependent of the logical child segment. The data in this dependent of the logical child is called variable intersection data. For each logical child occurrence, there can be as many occurrences of dependent segments containing intersection data as you need.

The following figure shows variable intersection data. In the ORDER 123 segment for the item BOLT, 3000 were delivered on March 2 and 1000 were delivered on April 2. Because of this, two occurrences of the DELIVERY segment exist. Multiple segment types can contain intersection data for a single logical child segment. In addition to the DELIVERY segment shown in the figure, note the SCHEDULE segment type. This segment type shows the planned shipping date and the number of items to be shipped. Segment types containing variable intersection data can all exist at the same level in the hierarchy as shown in the figure, or they can be dependents of each other.

Figure 2. Variable intersection data
begin figure description. This figure is described in the surrounding text. end figure description.

Fixed intersection data, variable intersection data, and physical pairing

In the previous figures, intersection data has been stored in a unidirectional logical relationship. It works exactly the same way in the two bidirectional logical relationships. However, when physical pairing is used, variable intersection data can only be stored on one side of the relationship. It does not matter on which side it is stored. An application program can access it using either the ORDER or ITEM database. Fixed intersection data must be stored on both sides of the relationship when physical pairing is used. IMS automatically maintains the fixed intersection data on both sides of the relationship when it is changed on one side. However, extra time is required for maintenance, and extra space is required on DASD for fixed intersection data in a physically paired relationship.