Message CPF502B tells you to review related joblog messages to help determine the cause. With nothing else to go on, it appears as if your trigger program failed. If you need help with why it failed, we’ll need to see the relevant messages and possibly relevant sections of your trigger program code.
Most likely you now need journaling because of the failure. If your trigger doesn’t fail, then journaling can probably be dropped (though it shouldn’t be.) A trigger program is considered to be part of the database, not part of any of your applications. When the database fails, you need proper commitment control to clean things up.
The file is in a kind of indeterminate state until the failure is cleared — that’s essentially what the system is telling you. You need effectively to rollback the transaction. Ending your job gets that done.
BTW, I don’t get the part of your question that says “where I have a halt”. You shouldn’t be interrupting a trigger program. If you need to check attributes, just execute DSPJOB *PRINT and continue running. Actually, it’d probably be better to call QUSRJOBI or similar API to retrieve what’s needed and store the info into a user space. Or use SNDPGMMSG to log info to the joblog. Anything but trying to stop execution while a transaction is being handled.