gtpd1m2nDatabase Reference

How an Object Can Overflow into Additional Records

As mentioned previously, not every collection part that TPFCS wants to file for a given collection can fit in a single DATXPAGE envelope in the control record because this envelope itself must fit in a 4-K record. When this occurs, the object splits and overflows into one or more additional DATXPAGE envelopes, each of which is filed in a separate 4-K record.

When an overflow condition occurs, TPFCS files another object (called an xternalObject) in the very first 4-K record along with the beginning of the object. The xternalObject serves as a pointer that contains the file addresses of all the 4-K records that TPFCS needed to use to file a single object or set of related objects. Once again, each portion of the object that is filed in each record is packaged in a separate DATXPAGE envelope.

Note:
Do not confuse a portion of an object with an ObjectPart (collection part). A collection part or ObjectPart is itself an entire object, which can be divided into several portions and filed in separate records. OBJECTA in Figure 52 is most likely a collection part object.

The following figure shows how an object is split into portions and packaged into several DATXPAGE envelopes to be filed in more than one 4-K record:

Figure 52. How OBJECTA Is Spread Across Three Records (with Shadowing)


Note:
When an object such as OBJECTA does not fit in a single record, it can split at any location. It could also have split in the middle of its object header. Furthermore, the split could have occurred in the middle of the OIDentry object rather than in OBJECTA. (These scenarios are not shown for the sake of simplicity.)

The previous example could also have contained more than a single object in place of OBJECTA. For example, we could have been dealing with objects called OBJECT1, OBJECT2, and OBJECT3. In this example, TPFCS would have attempted to file all three objects in sequence, one immediately after the other starting with OBJECT1, in a single DATXPAGE envelope and corresponding 4-K record. As soon as the first DATXPAGE envelope and its corresponding record was filled, TPFCS would continue with the current object and begin to fill another envelope in another record until all of the objects have been accounted for. By the time TPFCS filed all of the objects, it could have filed them in separate records, but this does not imply that each object would be contained entirely in its own record.

Not every object will fit in a single 4-K record along with all of the other objects TPFCS chooses to file there for the same collection. For example, for a compact-resident collection, the structure object, which houses the data elements of that collection, can overflow into additional records that are beyond the control record. The following figure shows such an example, where the structure object for a compact-resident array collection overflows into another 4-K record. When this occurs, an xternalObject is included in the first DATXPAGE envelope and points to the next and any subsequent records into which an overflow has occurred.

Figure 53. Control Record for a Nonshadowed Array with Overflow


It is important to realize that TPFCS will handle both physical records as a single logical control record when reading them into memory to service an application request to access the collection. Because of this, all displacements in the OIDentry table of contents are relative to the beginning of the OIDentry when all of the objects of our previous example are read into one contiguous buffer with the surrounding DATXPAGE envelopes removed as follows:

Figure 54. How TPFCS Handles the Control Record Contents


In addition, any other object attributes or fields containing pointers for the logical control record refer only to the first physical 4-K record in which control record information is written: that is, the record containing the xternalObject. For example, the PID of the array whose control record is shown in Figure 53 would contain the file address of First Record. This same file address is stored in the owner ID discussed below.