On 03-Aug-2015 10:02 -0600, Voris, John wrote:
Yes, we also are perplexed with this intermittent failure and what we
saw in the journals (Code ZC=Object Changed).
Probably better to journal the Data Queue to show both the activity
of and the actual messages written\removed, versus merely exposing that
a particular type of change transpired [per the audit entries].
I think it is a threads-problem from work being done in the
interactive job, <<SNIP>>
Multiple threads in an interactive job; only system-created threads
would be possible as I recall.? So is the implication that the
retrieval of data from the Open Query File (OPNQRYF) is running
multi-threaded? The Add Physical File Trigger (ADDPFTRG) has the
Threadsafe (THDSAFE) parameter with a default of *UNKNOWN and the other
options of *NO or *YES to identify if the Trigger Program (PGM) is
thread-safe and what the effect should be when the trigger fires in a
multithreaded job per the Multithreaded Job Action (MLTTHDACN) parameter
with options of *SYSVAL, *MSG, *NORUN, and *RUN.
"Multithreaded job action (MLTTHDACN)
Specifies the action to take when the trigger program is called in a
multithreaded job. The THDSAFE attribute of the trigger program can be
used in determining the action, however, there is no direct relationship
between the THDSAFE and MLTTHDACN keywords.
If you do use the THDSAFE value to determine the value for MLTTHDACN,
please read the following recommendations:
• If the THDSAFE value is *NO, MLTTHDACN should be set to *NORUN.
• If the THDSAFE value is *UNKNOWN, MLTTHDACN should be set to *SYSVAL.
• If the THDSAFE value is *YES, MLTTHDACN should be set to *RUN.