An Initialization exit called USRX0000 must be present, to set the pointers for all user exits that are to be called.The Initialization exit does this by turning off the high-order bit for the address for that user exit.
The Data Object Broker terminates with an error message if USRX0000 is present in the load library and the Data Object Broker Parameter USEREXIT is set to N, or USRX0000 is not present in the load library and the Data Object Broker Parameter USEREXIT is set to Y.
The Cache Complete exit is called after the last Cache buffer has been built and before the write request is issued. You can use this exit to ensure that all intent list user processing is complete. Invoking the exit routine before the last Cache buffer is written ensures that the transactions for the checkpoint are recovered in the event of an abnormal termination of the Data Object Broker.
Pending page image updates are written serially to one of the Cache data sets before the asynchronous processing of the page image data sets and journals. Before the Cache write is initiated, the Checkpoint Start exit is invoked.
If your application requires dynamic external influence on the processing, the exits must support user operator commands. To support user commands, the optional Command exit must be enabled. If there are no user commands, the Command user exit should remain inactivated (that is, USREXTPL.UXCMND@ = 0). If present, the Command exit is called when a command received from the operator starts with the character “Z”. The exit is responsible for producing any log notification that results from user commands, such as return code 0 or 4.
A user command must be 5 to 14 alphanumeric characters long starting with a “Z”. The format of the command should be the same as for other keyword Data Object Broker operator commands with a value, such as “ZUSER=value”, or without a value, such as “ZSPIN”.
A checkpoint can be triggered based on volume of processing, a timed event, an operator command, or via the user Redolog-1 and Redolog-2 exits. When preparing for a checkpoint, the File Management routine switches the Cache buffer. When this Cache switching is about to occur, the File Management Checkpoint user exit is invoked.
After completing phase-1 initialization, the Data Object Broker calls the Initialization Complete exit. During Phase 1, the Data Object Broker obtains the majority of the space it requires, allocates the control data sets, and makes any parameter adjustments necessary, such as the values of checkpoint, transaction, and page limits. The Initialization Complete exit provides the best opportunity for the calculation and acquisition of user storage. The UXSPACE@ field in the USREXTPL is available to store the start address of the user storage block. This is also the time to perform sanity checks on the user parameters that are processed.
The Open exit is called at the end of the File Management third‑stage initialization. At this point, the TIBCO Object Service Broker data sets required to start processing are allocated and opened. The Open exit provides the opportunity to open the data sets you require.
If your application requires external influence, you can accommodate this with user runtime parameters. To support user parameters, the optional Parameter exit must be enabled. If there are no user parameters, the Parameter user exit should be left inactivated (that is, USREXTPL.UXPARM@ = 0). The Data Object Broker invokes parameter processing during initialization and when a “PARAMETER=” operator command is received. When the Data Object Broker encounters a parameter keyword starting with the character “Z”, it invokes the user parameter exit if UXPARM@ is a positive non-zero value. The exit routine is responsible for doing any user-parameter reporting required.
A user parameter must be 5 to 16 alphanumeric characters long starting with a “Z”. The format of the parameter should be the same as for other Data Object Broker runtime parameters with a value, for example, “ZUSER=value”.
During Data Object Broker start-up processing after an abnormal termination of the Data Object Broker, the intent lists saved on the redolog that have not reached checkpoint are reapplied. After each “recovery” intent has been processed, control passes to the Recovery exit.
Refer to Redolog Entries for details of the layout of the redolog entries.
After an intent list has been validated by the Data Object Broker, it is written to the redolog. TIBCO Object Service Broker uses an asynchronous write so that I/O processing of the primary and duplex redologs can overlap. TIBCO Object Service Broker calls the Redolog-1 exit after issuing the asynchronous write request.
When the intent is written to the redolog, it could be split into segments depending on the space available in the VSAM Control Interval. In this case, TIBCO Object Service Broker calls the Redolog-1 exit after issuing the asynchronous write request to the redolog for the first block.
The Redolog-1 and Redolog-2 exits are designed to work in series to provide a processing window that overlaps the I/O processing of the redolog. Processing requirements in Redolog-2 are dependent on the processing initiated in Redolog-1.
Refer to Redolog Entries for details of the layout of the redolog entries.
As stated under Redolog-1 Exit, the write request of the intent to the redolog is asynchronous. After the check to verify a successful write was satisfied, the Redolog-2 exit is called. If the intent is written over a number of redolog VSAM Control Intervals, TIBCO Object Service Broker calls the Redolog-2 exit only after successfully writing the last Control Interval.
The Redolog-1 and Redolog-2 exits are designed to work in series to provide a processing window that overlaps the I/O processing of the redolog. Processing requirements in Redolog-2 are dependent on the processing initiated in Redolog-1.
Refer to Redolog Entries for details of the layout of the redolog entries.