Re: Default user ID in SQL table - trigger

Alan Campin wrote:

Not sure how removing a mediator would solve your problem. In
the case of my trigger mediator, there is a database with the
data about what to use so if you changed the database it would instantly begin to use the correct trigger service program. Everything goes to the same place.
As far as how it works, IBM did all locks for performance reasons. Trick was how to get the almost the same performance
using the mediator as without it and I think I solved that
problem.

And yes you can always shoot yourself in the foot but that doesn't matter how you do it. Somebody can screw up. I am also
curious how if you have a single trigger program on one file how
different programs can get called for the same file. They were
using different mediators?

The most probable origin for such an issue would be the use of [by a mediator] of a static call method [e.g. via a stored address] versus a fully dynamic call method [e.g. call by name, resolved to an address each time]. Given that design, any activation which was ended & then restarted [as described had occurred over time in the error scenario] since its prior resolution of name-to-address would get the new address for the new program by that name. The new cached\stored address would be used for successive calls from the mediator in that new activation, whereas old activations which were not restarted would continue using the old program for successive calls from the mediator. The program object by the old name would best go missing as part of the any change to activate a new program, in order to force the mediator to /notice/ the change. For example if the program were to go missing due to a DLTPGM, a call by address fails with an MCH3402 and call by name with MCH3401. If the program instead goes missing due to either RNMOBJ or MOVOBJ [or by those combined, as in REPLACE(*YES)], there would be no failure for a call by address, until the application was required to re-resolve; or for when the program is the same as original name to simply start using the new copy of that program [albeit with a minor time window for the mch3401; coded or defaulted for error inquiry with retry, still only a minor impact].

The use of static call by address is the very reason why for a file that is opened [with options that may activate a trigger], the database will lock that trigger program; i.e. the address of the program is obtained when the file is opened, and that trigger program would be locked and would be called by address for all I/O via that open. Because the trigger program is locked while the open is maintained, that program can not be renamed [explicitly nor /replaced/ into QRPLOBJ, which is implemented as both a rename and a move] nor deleted. The lock ensures the /correct/ & /same/ program object will continue to be both callable and called. Noting that the implementation is /for performance reasons/, correlates with the fact that a dynamic call is inherently slower than a call by stored address; i.e. the dynamic call requires a name to object address resolution for each invocation at each I/O, whereas the static call requires only one object address resolution which is performed at each open.

Regards, Chuck