COBOL-TRIGGER Directive

Use this directive to indicate that a COBOL trigger is to be executed.

Syntax

$XFD COBOL-TRIGGER=program name

*(( XFD COBOL-TRIGGER=program-name ))

This XFD must be located immediately before the FD of the file for which the trigger is defined.

Three parameters are passed to the COBL program:

01  OPCODE.
    88  READ-BEFORE         VALUE "r".
    88  READ-AFTER          VALUE "R".
    88  WRITE-BEFORE        VALUE "w".
    88  WRITE-AFTER         VALUE "W".
    88  REWRITE-BEFORE      VALUE "u".
    88  REWRITE-AFTER       VALUE "U".
    88  DELETE-BEFORE       VALUE "d".
    88  DELETE-AFTER        VALUE "D".

01  FILE-RECORD             PIC X(MAX-RECORD-SIZE).

01  ERROR-CODE              PIC 99.

You can use the C$PARAMSIZE library routine to determine the size of the record passed, in case you have variable-length records. See Appendix I. Library Routines for more information on C$PARAMSIZE.

In cases where the record size is known, the actual record is passed (READ-AFTER (all), WRITE-BEFORE, WRITE-AFTER, REWRITE-BEFORE, REWRITE-AFTER)
In cases where the record size is not known, the maximum record size is passed (READ-BEFORE (all), DELETE-BEFORE, DELETE-AFTER

The contents of this field will be identical to the record area given to the file operation. The BEFORE images will have the value before the file operation, and the AFTER images will have the value after the file operation.

Use the ERROR-CODE parameter to signal to Acu4GL that an error occurred.

Setting this in a BEFORE trigger causes the actual file operation to not execute
Setting this in an AFTER trigger causes the runtime to treat the file operation as an error, though in fact the file operation did execute

This means that, for sequential access (next or previous), the file position has changed and a subsequent next or previous will act as if the prior file operation succeeded. Also, setting an error in the REWRITE-AFTER or DELETE-AFTER will not actually return the record to its prior state — the record will be modified or deleted in the database. We suggest using transactions if this behavior is not acceptable.

If the COBOL program can not be called (for any reason), it is treated as having succeeded.