Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 9 Using Data Object Broker User Exits : Overview

Overview
This chapter identifies and explains the purpose and use of the Data Object Broker user exits provided by TIBCO Object Service Broker. You are responsible for the development and support of the routines invoked at these user exits.
User Exits
The Initialization exit is the only one that you must supply, because it provides a road map to the others.This is done via USERMODB as described in Sample Template and Application
The following user exits are available:
See Page
Usage Notes
When writing your exit routines, note the following:
Other than data specifically passed to a user exit, no attempt to access or monitor Data Object Broker activity is permitted from a user exit.
Control passes to the user exits using the Branch and Stack (BAKR) instruction. Before the exit is called, Register 13 is set to zero. The exit is APF‑authorized and is entered in 31‑bit addressing mode and in storage-key 8.
If the Data Object Broker is executing with ESTAE support (this is the default and is recommended), when an abend occurs in a user exit, the Data Object Broker generates a message in its log. All user exit abends, except those from the Command exit, terminate the Data Object Broker. The Command exit is called from OPERTASK and, when the exit abends, OPERTASK automatically restarts.
Register usage Notes
Register 0 points to the general parameter list, which contains a pointer to shared storage and pointers to all active user exits.
Serialization by TIBCO Object Service Broker Task
The exits are serialized by the task they are called from:
Take care when performing z/OS actions that are task‑dependent. For example, a data set opened under the control of one task cannot be closed under the control of another task. A possible solution is to perform any such function within a subtask that you write and attach during Data Object Broker initialization and detach during termination.
Processing Flow
During initialization the routine associated with the initialization exit is called from SUPVTASK. Assuming that this exit routine enables all other possible user exits, the processing proceeds as follows:
1.
The Parameter exit routine is called for each user parameter specified in the input parameters under the control of SUPVTASK. Then the Initialization Complete exit routine is called under the control of SUPVTASK, the Open exit routine is called under the control of FILETASK, and the Recovery exit routine is called once for each recovered intent (if any).
When the last recovered intent (if any) is passed to the Recovery exit, the Data Object Broker finishes its initialization process.
2.
For every update intent processed by FILETASK, the Redolog-1 exit is called, followed by the Redolog-2 exit, for the same commit transaction.
No other exit is called by FILETASK during this interval.
3.
4.
When a checkpoint is triggered, CHPTTASK calls the Checkpoint Start exit for this checkpoint, followed by the Cache Complete exit for the same checkpoint.
CHPTTASK does not call any other exit during this interval.
5.
For any given checkpoint, the File Management Checkpoint exit in FILETASK is called after the Checkpoint Start and Cache Complete exits in CHPTTASK for the previous checkpoint, and before the Checkpoint Start and Cache Complete exits for the current checkpoint.
6.
7.
F DOBNAME,PARAMETER=Zuserparm=value
8.

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved