The following sections identify the various data sets used by TIBCO Object Service Broker. For performance reasons, each TIBCO Object Service Broker data set should be located on a different device. This is very important for high-use data sets such as the MetaStor, the redolog, the contingency log, and the cache. For faster recovery from DASD failures, the redolog data sets can be duplexed, so that identical updates are written to two data sets, the primary and duplex ones. For information about setting up duplex copies, refer to
Duplexing the Redolog for Recoverability.
TIBCO Object Service Broker for z/OS Installing and Operating for more information on the definition, placement, and sizing of these data sets.
The Pagestore is a collection of VSAM ESDS data sets used for storing data in tables. In simple terms, this is the database. The TIBCO Object Service Broker Pagestore stores data using the TDS (Table Data Store) method. TDS tables are stored in a B+ tree structure.
The Pagestore is divided into partitions known as segments. Each segment contains between 1 and 128 data sets that contain data, as shown in the following illustration.
The only required segment is the base segment (ID = 0), also known as the MetaStor. It contains table definitions, rules, and an index that identifies where the tables are defined. The MetaStor is the most heavily used segment. As distributed, TIBCO Object Service Broker has three segments and the MetaStor has three data sets.
TIBCO Object Service Broker Application Administion for more information about TDS segments and modifying the size of your Pagestore.
The redolog data set retains update requests from the Execution Environment that were processed. TIBCO Object Service Broker uses the redolog in recovery situations to reprocess committed updates made to the Data Object Broker since the last checkpoint.
The contingency log data set contains a record of all transactions that span resources, such as the local Data Object Broker and one or more external resources. An external resource is a database server or a peer TIBCO Object Service Broker Data Object Broker.
In the event of a power failure or external system failure, TIBCO Object Service Broker uses the contingency log to ensure consistency of updates across various peer TIBCO Object Service Broker systems and external database management systems.
TIBCO Object Service Broker uses two cache data sets as write-ahead logs for page images marked as modified at checkpoint time. When the system performs a checkpoint, the modified pages in memory are written to the cache, assuring their recoverability in the event of a failure. The data pages are written out asynchronously to the journals and to the Pagestore.
TIBCO Object Service Broker supports 2 to 255 journal data sets. The journals are used to retain updated page images. Only one journal is active at a time. When a journal is full, it spins off the page images to a backup via the spin process, which prepares the journal for re-use. For more detail, refer to
Spinning the Journals.
If you have some segments that store easily reproducible data and you are sure that data recovery is not an issue, you can turn off journaling for those specific segments. For more information on this option, refer to
Chapter 4, Understanding Journal Processing.
This data set is the repository for data set information for the Data Object Broker and for many utilities. The DBDLIB contains a description of all data sets known to TIBCO Object Service Broker, including: