File representation of objects

z/TPFCS is implemented using many of the object-oriented concepts previously described. All data in a z/TPFCS database is stored and maintained using objects. The data comprising an object consists of the attributes that the object inherits from its own class, preceded by all the attributes the object inherits from higher classes.

There are several similarities between the design of the previously discussed sample vehicle database and the design of the z/TPFCS database. Recall that, in our vehicle database, we have an abstract OBJECT class that is the base class; that is, all objects in the database inherit attributes and methods from the OBJECT class. z/TPFCS also implements an abstract class named OBJECT as the base class from which all objects stored in the database inherit.

Furthermore, just as in the vehicle database, the z/TPFCS object-oriented design uses single inheritance and, therefore, does not use multiple inheritance.

Suppose z/TPFCS created an object of ClassC, where ClassC objects inherit from higher classes as follows:

z/TPFCS would store a ClassC object in a pool record in the z/TPF database as follows:

Because all of the objects in the z/TPFCS database design inherit from the base OBJECT class, the attributes of the OBJECT class always precede all other attributes contained in a z/TPFCS object. We refer to the attributes the object inherits from the OBJECT class as the object header. As was the case for the definition of our hypothetical vehicle database objects in Figure 1, one of the attributes inherited from OBJECT is the class ID, which is an identifier in the object header that indicates the most detailed classification of the object. This identifier would always indicate the most immediate (and detailed) class to which the object belongs. Therefore, for a ClassC object, even though it also belongs to other classes (such as ClassA and ClassB), this attribute would identify the object as an instance of ClassC.

Keeping in mind that the attributes inherited from the OBJECT class constitute an object header, which, in turn, identifies or describes the object, the following is another way to depict the same ClassC object as stored in a 4-K pool record:

As shown in Figure 3, the object header would identify the object in question as an instance of ClassC.

z/TPFCS sometimes chooses to store separate objects in the same record in the z/TPF database. For example, there might be other objects immediately surrounding our ClassC object in the same record:

In Figure 4, each object would contain its own unique header as well as its own unique set of attributes, including those it inherits from other classes. Furthermore, even though z/TPFCS can use the ClassC, ClassD, and ClassE objects to write information about the same collection in the z/TPF database, those objects would be unrelated to each other in terms of class inheritance. z/TPFCS could also choose to embed the same three objects in the data area attribute of yet another, larger object of ClassX to which they are also unrelated in terms of inheritance. A single record might then contain all these objects as follows:

A data area attribute is an attribute (field) within an object that is used to store generic data. Depending on how z/TPFCS implements the object, the generic data can be comprised of other objects, as in our example.

The easiest way to understand how z/TPFCS objects will appear in the database is to consider the vehicle objects of our hypothetical example described in Figure 1. If a Limousine object were written in the z/TPF database in the same way as an object created by z/TPFCS, it would appear in a 4-K pool record as follows:

Similarly, other objects associated with the Limousine would be embedded in the data area attribute of a ClassX object as shown in the following figure:

The ClassX object shown would appear in a separate 4-K pool record from the one containing the Limousine object. The AutoProxy object contained in its data area would contain an attribute where the file address of the Limousine object record is stored. In this way, the ClassX object is used to store or locate all the objects used to represent a real limousine.