CICS BAC request server user exits

CICS BAC provides two user exit points for which you can provide your own user exit programs. These exit programs are driven during the processing of CICS BAC batch request utility commands in the CICS region:

You specify the names of the exit programs in the CICS region properties record using the CICS BAC workstation administration client or the CICS BAC batch file maintenance utility. If you specify a program name for one or both of these exit points, the relevant exit point is enabled and active after CICS BAC has loaded the CICS region properties record. You specify the exit program names on the Miscellaneous(2) tab of the CICS region properties panel. The exits are called only when a CICS BAC command is processed by the CICS request server running in the region. Batch request commands that are serviced directly by the batch request utility itself do not result in the user exits being called. CICS BAC commands from an application program calling the CICS BAC request server through the callable API also drive the user exit programs. The user exit programs are not called during CICS BAC startup processing in the CICS region.

You can use the pre-command exit to suppress the execution of a command by setting the appropriate return code before returning to CICS BAC. If the command is not suppressed, it will be executed using the parameter values described by the COMMAREA passed to the exit program. You cannot alter the command by changing values in the COMMAREA. All changes to the COMMAREA to fields other than the return code fields and message text field are ignored. You can also perform in your exit program any other processing permitted by CICS in an application program.

You can use the post-command exit only to perform some additional processing of your own following the completion of a command. If your user exit program makes any changes to the COMMAREA passed to it, they are ignored.

CICS BAC calls user exit programs before and after the state of a CICS resource (file, transient data queue, program, or transaction ID) is changed. This can occur as a result of a CICS BAC command that results in the resource state being changed directly (as in a CICS BAC SET PROGRAM command), or indirectly, such as a transaction ID state being changed as a result of a request to change the open state or enable state of a file with which the transaction ID is associated. Resource state changes that result from a CICS BAC SET LIST or SET GROUP command also result in the user exits being called. Note that the exits are not called if the resource named on a SET command is already at the requested state. For example, if a command specifies that a file is to be closed, but the file is already closed, the state of the file is not changed and therefore the pre-command and post command user exits are not called.

The user exit programs are not called for the following events:
  • Processing of a CICS BAC SET LIST command. However, the exits are called for each of the resources whose states are being changed as a result of the SET LIST command.
  • Processing of a CICS BAC SET GROUP command. However, the exits are called for each of the resources whose states are being changed as a result of the SET GROUP command.
If specified, the CICS BAC user exit programs are driven by a standard EXEC CICS LINK command. A data area describing:
  • The EXEC CICS SET command that is about to be processed for the pre-command exit, or
  • The results of the command that has just been processed for the post-command exit,
is passed to the user exit program as a COMMAREA. To help you develop your user exit programs, the SCBKSAMP data set provides the following:
  • A DSECT describing the layout of the COMMAREA in member CBKXPI
  • A sample user exit program in member CBKUEXIT.

Reference Reference

Feedback


Timestamp icon Last updated: Monday, 2 December 2013


http://pic.dhe.ibm.com/infocenter/cicsts/v5r1/topic/com.ibm.cics.bac.doc/cbka1/cbka1af3.html