CPF502B: Error occurred in trigger program

What it means

A trigger is a program that Db2 for i calls automatically when a file changes. It can be an external program added with the ADDPFTRG command, or an SQL trigger made with CREATE TRIGGER. The database calls it before or after the insert, update or delete, depending on how the trigger was defined.

When the trigger program fails, the database doesn't hide it. It tells the application that issued the file operation, and CPF502B is the message it uses. The text is short, "Error occurred in trigger program", and it names the file and member. It doesn't tell you what went wrong inside the trigger. That part is in the messages the trigger program left in the job log before CPF502B arrived.

Programs can monitor for CPF502B. ILE COBOL sets file status 9T, and an ILE RPG program can catch it with an error indicator or the E extender.

For a before trigger, the change normally hasn't happened yet. For an after trigger, the row may already be written, so whether it stays depends on commitment control. Under commitment control the application can roll the change back.

Common causes

• The trigger program rejected the change on purpose. Many triggers check business rules and send an escape message when a rule fails, for example a negative quantity or a closed account.
• The trigger program hit its own run-time error, such as a decimal data error, a divide by zero or a record lock on another file it updates.
• An object the trigger uses is missing or locked, such as a log file it writes to. In batch jobs the library list is a common reason a trigger can't find its files.
• The user running the job isn't authorized to something the trigger program touches.
• The file's record layout changed and the trigger program still assumes the old one, so it reads the wrong bytes from the trigger buffer.

How to find the problem

1. Run DSPJOBLOG, or press F10 on the message screen to show all messages. The messages just before CPF502B came from the trigger program. Put the cursor on each and press F1, then F9, to see which program sent it and at which statement.
2. List the triggers on the file with DSPFD FILE(ORDLIB/ORDHDR) TYPE(*TRG). The output gives each trigger program, its library, the event and the time (before or after). With SQL you can query QSYS2.SYSTRIGGERS for the same thing.
3. If the job log only shows CPF502B, change the job's logging to keep everything (CHGJOB LOG(4 00 *SECLVL)), run it again, and look again.
4. To step through the trigger, start debug on the trigger program with STRDBG, using UPDPROD(*YES) if the file is in a production library, then repeat the change that fails.

How to fix it

• Fix the cause the trigger reported. If it rejected the data on purpose, correct the data and try again. That is the trigger working as designed.
• If the trigger program itself failed, fix and recompile it. Have it handle its own errors and send one clear escape message, so the next person sees a useful reason before CPF502B.
• Make sure every file and data area the trigger uses can be found in every job that changes the file, including batch and server jobs, or qualify the names in the trigger.
• In the application, handle the error on the write, update or delete (an error indicator or the E extender in RPG, file status 9T in COBOL) so a trigger rejection doesn't leave a user facing an inquiry message.
• If you must load data while the trigger is broken, the trigger can be switched off for a while with CHGPFTRG STATE(*DISABLED). Agree that with the application owner first, because the trigger's rules won't run until you enable it again.

What it looks like

Error occurred in trigger program.

DSPMSGD MSGID(CPF502B) MSGF(QSYS/QCPFMSG)

Technical reviewer: Albert Joseph, WND Software.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s documentation for your IBM i release.