![]() |
Copyright © TIBCO Software Inc. All Rights Reserved |
While journal and backup information can be used to recover page data sets, you must also be prepared to recover from other failures you encounter. Other data sets that can fail include the journals, redolog, CACHE1 and CACHE2 data sets, and the contingency log. Each situation is described in the following sections.If the redolog data set becomes damaged, it is possible that you cannot automatically recover the system.If the Data Object Broker fails due to either the redolog or its duplex becoming damaged, restart the Data Object Broker using a copy of the good data set as the redolog.
2. Run the S6BTLFRL (Format Redolog) utility to re-initialize the redolog data set and copy the contents of the good data set into the new redolog.Refer to TIBCO Object Service Broker for z/OS Utilities.
IDCAMS cannot be used to back up or copy TIBCO Object Service Broker redolog data sets because it changes the placement of records within the VSAM control interval.If no duplex exists, you must delete, redefine, and re-initialize it. Loss of the redolog with no duplex causes the loss of commits received by the Data Object Broker since the last successful checkpoint.
3. Capture any data from the active journal by manually submitting a spin for the active journal. Refer to Spinning the Journals.You do this so as to have this data still available, if needed. This is necessary because, at restart, TIBCO Object Service Broker sees that you re-initialized the redolog and overwrites the existing journal data.
5. Reply “G” to message S6BKR098, which should appear, along with message S6BKR011, because you have both a reformatted redolog and a cache data set available at this time.
If you have segments online when the Data Object Broker fails, and error messages S6BKX067 and S6BKX022 appear, modify the DBDGEN to include the segment shown in S6BKX067 as online at initialization.
1. Use the S6BTLFCL (Format Contingency Log) utility to delete, redefine, and re-initialize the contingency log data set (REDOLOG.PENDING).Loss of the contingency log could result in data inconsistency in a distributed data environment. For more information about the role of the contingency log in distributed data environments, refer to Chapter 3, Understanding Fail Safe Processing.The CACHE1 and CACHE2 data sets are used to record checkpoint information quickly prior to actual segment updates. Loss of either of these data sets is detected during checkpoint processing.If a cache data set fails, you must delete and redefine it. Information is not lost because all information is recoverable from the redolog. Pending update information is reconstructed from the redolog data set when the Data Object Broker is restarted.Check the report to see the status of checkpoints. For more information on S6BTLDBR, refer to TIBCO Object Service Broker for z/OS Utilities.
We recommend that, before proceeding with the rest of this procedure, you contact TIBCO Support for assistance.
2. If all checkpoints are complete, that is, all checkpoint starts have a corresponding checkpoint end, run IEFBR14 to delete and reallocate both cache data sets, run the S6BTLFCA (Format Cache Data Sets) utility to re-initialize the cache data sets, and restart the Data Object Broker.
3. If a checkpoint is outstanding and its data is in the good cache, that is, the checkpoint number in the cache header for the good cache matches the number of an incomplete checkpoint in the redolog information, run IEFBR14 to delete and reallocate the bad data set, run the S6BTLFCA (Format Cache Data Sets) utility to re-initialize this data set, and restart the Data Object Broker, replying G (go) to the S6BKR098A message.
4. If a checkpoint is outstanding and the good cache contains the data for the previous checkpoint, contact TIBCO Support.If one of your journal data sets fails, you are not able to recover to the point of failure for subsequent page data set failures. For this reason, you should immediately reset the continuous backup process with a new master backup.After the Data Object Broker is started, you can use subsequent journal images, along with your backup, to recover any page data set failures up to the time of failure. Although the page images contained within the failing journal are lost, your repository and other control data sets are still intact. The steps for recovery are:
1.
3. Spin any residual data from the last current journal into your SPINOUT generation data sets.
![]() |
Copyright © TIBCO Software Inc. All Rights Reserved |