Exit XFCLDEL, file control logical delete exit

Exit XFCLDEL is invoked whenever a WRITE to a VSAM ESDS, or to a BDAM data set, is being backed out. Because these types of data set do not support deletion, you can use XFCLDEL to perform a logical delete by amending the record in some way that flags it as deleted.

Exit-specific parameters

UEPBLOGR

Address of the file control portion of the log record representing the update that is to be backed out by logical deletion. The log record can be mapped using the DSECT DFHFCLGD.

UEPTRANS

Address of the 4-byte transaction id under which the update that is being backed out was made.

UEPTRMNL

Address of the 4-byte terminal id for the terminal or principal facility from which the update that is being backed out was made.

UEPTASK

Address of the 4-byte (packed decimal) task number for the task under which the update that is being backed out was made.

UEPFDATA

Address of a variable-length field containing the data in the file control request. The exit program can amend the record data addressed by this field, marking it in some way that applications can recognize as representing a logically deleted record.

UEPFLEN

Address of a fullword containing the length of the data in the file control request.

Return codes

UERCFAIL

Do not perform the logical delete, and treat this as a backout failure. This is the default action taken if the exit is not enabled.

UERCLDEL

Perform the logical delete by reapplying the updated record.

A return code of UERCPURG is not allowed. There is no need to set a UERCPURG return code, because the conditions under which this exit is invoked should mean that “purged” cannot be returned by any XPI or API calls.

XPI calls

All can be used, but subject to the same caution as for API and SPI calls.

API and SPI calls

Although this exit is allowed to issue API and SPI calls, you should be very careful about which commands you use because the exit is invoked during file backout, which is part of syncpoint phase 2.

It is recommended that you restrict EXEC CICS® commands to inquiries, and avoid commands that update CICS resources, because the resources may themselves be in a state of recovery. In particular, the following restrictions apply:

1. Do not issue any recoverable operations.
2. Do not use operations that access systems or resource owners external to this CICS, even if the target resource is non-recoverable.
3. Do not disable or close files, because this could cause further error conditions.
4. It is possible for this exit to be invoked under a different transaction environment from that under which the updates that are being backed out were originally made. If your exit program wants to perform any actions (such as writing a message to the terminal) that require it to be running under the original transaction environment, it must first check the value returned in the RE_ATTACHED_TRANSACTION parameter of a transaction manager INQUIRE_TRANSACTION XPI call.

The CICS file definition does not have to specify UPDATE=YES in order for CICS to update the record with the logical delete flag set by an XFCLDEL user exit like DFH$FCLD. When a backout is being done, checking the SERVREQS like UPDATE is bypassed.