Re: Default user ID in SQL table - trigger

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.â

If implication here is that the mediator uses a program call it does not.
The service service program is loaded dynamically at load time (either when
the program first called or reload request is made) and the address stored
in a data structure mapped into a user space. Each time it comes in, it does
a binary search to find the file and has it's pointer to the correct
procedure. I wanted a solution that did not use dynamiic program calls
because of the performance implications. By using a service program, I get
the performance and can have multiple procedures in the same service program
if I need them.

Using this system also prevents problems with pointing at the wrong program.
When a reload request is received, everything is reloaded and resolved again
so if the service program is renamed and a new one installed you get the new
version which is why you can add or remove a file from a trigger instantly.

On Tue, May 19, 2009 at 10:30 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

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
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.