RE: Default user ID in SQL table - trigger

Alan;

Your mediator solves the problem we encountered, the mediator programs we used were just wrappers for the trigger programs. Although it removes a well defined procedure to add/change/remove a trigger program and/or its logic, it does add a procedure, that is not as widely known, to solve the same problem.

Duane Christen


--


Duane Christen
Senior Software Engineer
(319) 790-7162
Duane.Christen@xxxxxxxxxx

Visit PAETEC.COM


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan Campin
Sent: Wednesday, May 20, 2009 12:42 AM
To: Midrange Systems Technical Discussion
Subject: 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.

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