File operations performed during a call

[kpandian]

Re: File operations performed during a call

Wish you all a happy christmas and a happy new year in advance.

Pandian

[tomliotta]

Re: File operations performed during a call

It seems odd that authority for database journaling is restricted, yet creation of triggers is allowed. Creating trigger operations could have far more serious effects than creating receivers and journals and assigning PFs to them. But you know your environment and the choice is yours.

Also, if data volumes are high enough that journal receiver sizes over just 15 files is excessive, then you'll want to be careful about the performance of your triggers. A trigger that needs to continually update and share access to a data area, and resolve its call stack in order to determine what program caused each file operation, and then output its results (which will also take space, though less than receiver entries) is likely to impact each transaction more than journaling. In a high-volume scenario, performance of each trigger might need close attention. Journaling can also impact performance, but it's often easier to manage.

The use of the *LDA is possibly a good idea. That should help with performance, as long as there is no other use of *LDA in the application and possibly no use at any time in the future. I've never checked anything about *LDA performance, but I'd expect it to be very good. That could indeed help.

"The maintenance program (Pgm-A) invokes one of the transactional programs (Pgm-1, Pgm-2, ... Pgm-X), depends on the transaction/operation and it is required to list the files inserted during the transactional program calls."

But that restates things in a way that makes your requirements much more clear. Earlier, it looked as if you wanted information out of "(Pgm-1, Pgm-2, ... Pgm-X)". Now it seems clear that you want information out of "(Pgm-1, Pgm-2, ... Pgm-X) only if they are invoked out of Pgm-A and not if they're invoked some other way".

To me that means each trigger will resolve the call stack to see (1) if the file operation came out of any of (Pgm-1, Pgm-2, ... Pgm-X), and then (2) if the identified program was invoked with Pgm-A above it in the stack. Is that a correct understanding?

If it is, it could certainly explain how a trigger could consume much less space than a journal.

There are things to balance against, but I can see why triggers can fit. Good luck. (And Christmas/New Year's wishes back to you.)

[kpandian]

Re: File operations performed during a call

Hi Tom,
Yes, you got me correctly.
One more thing, this implementation is for the non-productive environments, hence i guess performance is not a major concern.

Also thinking of using Static memory for storing the Sequence value (using Export and Import), to evaluate the trigger program action.
In that way, could possibly avoid the risk of using *LDA.

Thanks again for your valuable time and ideas.
(Lot to learn from.....)

[tomliotta]

Re: File operations performed during a call

I've used a service program in a named AG to set and get values. I needed to pass a couple additional new parms from a program high in the call stack to some programs deep in the stack, but I couldn't change the parm lists for programs in between. (At least, not without a lot of unrelated changes to other programs.)

Stashing values that way worked well. The service program was trivial. The procedures simply set or returned values. The named AG hung around as long as I wanted and nothing else even noticed.

[kpandian]

Re: File operations performed during a call

Similar case is mine too...
Got to play with that *CALLER thing.