The SQLRPGLE invokes the following before preparing the SQL statement:
C/EXEC SQL
C+ SET OPTION USRPRF=*OWNER,
C+ DYNUSRPRF=*OWNER,
C+ ...
C/END-EXEC
It seems to work fine except with the update triggers. I'm confident
that Ed Fishel's description of the problem is on the mark:
"...if the trigger program is in this library...then a user will not be
authorized to call that trigger program if you have excluded them from
that library. If this is the case, then even if the trigger program
adopts authority from QSECOFR, it will not help because the not
authorized problem is occurring before the trigger program has a chance
to run."
I felt that was the issue, but could not find the right words to
describe it. Unless someone has a better idea, I need to move the
triggers to a library to which LMTUSR has access or use a data queue to
send the information to a job whose user does have authority to the
library. To cut down on the proliferation of libraries (on our single
iSeries we would need at least two trigger libraries--one for triggers
against production data and one for test data libraries) we are leaning
towards the data queue solution.
Thanks everyone for your input.
Roger Mackie
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Brian
Sent: Tuesday, April 03, 2007 11:24 AM
To: Midrange Systems Technical Discussion
Subject: Re: Adopted authority and triggers
Roger,
On your SQLRPGLE program, check to see what is specified for Dynamic
User Profile; the default is *USER. To fully adopt authority when
creating an SQLRPGLE program, you need to specify DYNUSRPRF(*OWNER) on
the CRTSQLRPGI command in addition to USRPRF(*OWNER).
Kind regards,
BJ
midrange.com
