Re: Trigger program - open / close file question

Brown, Stephen GRNRC wrote:

We have recently made some extensive changes to a Trigger program. Part
of these changes meant adding a series of system control files for input
only purposes.
These control file are used throughout our system for various things
like holding next numbers, environment codes etc so sometimes they are
defined for input and sometimes for update.

Anyway, we are having a problem because the control files in the trigger
pgm are currently being left open as the trigger is just issuing a
return. This is causing an issue in that in some programs these control
files are being open / closed within the calling program and some are
not. e.g Pgm 1 open / closes ctrlfile1 ( ctrlfile1 defined for Update).
Closes CtrlFile1 - invokes trigger - trigger opens ctrfile1 leaves open
- return to pgm1 - pgm1 tries to open ctrlfile1 again for update - can't
fails with CPF5125.

Stephen:

Be aware of another issue if this file is ever accessed from within a QZDASOINIT job and the remote client uses XA APIs for distributed transactions. The XA_end() API can (and often will) cause QZDASOINIT to close _every_ file that is open in the job, regardless of its involvement in any transaction and regardless of sharing and activation groups.

Now I don't want to have to review all usages of the control files in
conjunction with where the file hat has the trigger program associates
with it so best option would be to have a fit all solution made within
the trigger. ( I hope)
I need to make sure that if the trigger program is called that it
doesn't "upset" the calling programs i/o of the control files. I thought
the best way to do this would be to user define the control files in the
trigger and ensure they are closed prior to the return to the calling
program. I'm now questioning myself as I'm unsure that by closing the
file in the trigger will close it in the calling program and therefore
still give me an error ?

"Upsetting" the calling program won't be the big problem in the case I mentioned. Your trigger program may get a big surprise if the QZDASOINIT pre-start job is "re-used" and your trigger tries to check the control file again. MCH3402 -- the ODP has mysteriously disappeared.

I then thought of checking the status of the control files in the
trigger using %OPEN but I'm not sure if this only applies to the status
of the file in the trigger program or in the call stack.

Strictly speaking, it applies only to the OPEN that was performed within that specific program and to any CLOSE in the same program. It has no guaranteed knowledge of whether or not the file was closed from outside of that program.

As far as your trigger programming is concerned, the file status will show as 'open'. It simply won't be there when you try to do anything with it. And because status is 'open', you generally can't OPEN it again with any success. The QZDASOINIT job must end.

If it does it
within the call stack fine if it doesn't then what does my close in the
trigger close it in the calling pgm ?
Can anyone offer some words of wisdom.

Make sure no clients are using the XA functions from the latest Java Toolkit against V5R3 or V5R4 servers when pre-starts are set for re-use nor against V6R1 unless appropriate V6R1 DB2 PTFs are applied. (At least one fix exists for V6R1. Applying a recent DB2 Group should cover things.)

I'm not aware of any similar effect from the XA APIs on any jobs other than QZDASOINIT.

For this kind of reason, I strongly recommend against using database I/O in a trigger program. Use a user index or other kind of data object.

Tom Liotta