Chuck,
Your detail has been a big help. I know my OP was not complete details.
The reference to "1 per library" was response to someone else's question, and
the mention of the dynamic create of QAQQINI was someone elses posted
code a couple years ago to deal with needing diff versions, & I agree it's way
too much overhead.
We need only 2 versions, to turn on/off the derived index setting which can send
a
query thru CQE or SQE (we have some queries that will (not yet) work
under SQE, and IBM is working on the issue in a major production app).
For the client environment we had to default the CQE route by setting
ignore_derived_index = *no in a QUSRSYS version (some of IBM's
docs show creating it here, although I question putting stuff in that lib.
Rewriting the offending app, at this point is not an option.
Because diff apps are written with diff tools, our issue right now is using one
app with
IBM ODBC driver with MS Visual client, and we have (according to the developer)
no access to all the parts of the connection string, but can specify a QAQQINI
lib in a DSN properties dialog box.
This app needs the SQE to perform well, & was running fine till recent 6.1 db2
ptfs,
followed by our setting the derived index=*no in QUSRSYS. Along with those ptfs
came the change in security requirements.
Our OPS will like the SQLADMIN supplemental group idea, and we are preparing a
test.
Thanks
Jim Franz
________________________________
From: CRPence <CRPbottle@xxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Sent: Wed, May 9, 2012 12:38:59 PM
Subject: Re: v6r1 ptfs chg security requiremnt setting QAQQINI lib
On 09 May 2012 08:59, J Franz wrote:
I have seen sample code of even dynamically creating a copy,
altering it, then CHGQRYA, but we are looking at
How or why would that help, if the issue is knowing both what to
effect via, and then the authority to effect, the CHGQRYA?
high volume data entry, need sub-second response.
That requirement seems a logical reason to avoid any create of a
QAQQINI. Creation on the object-based system is already expensive,
DataBase Files especially, but that specific DBF object is particularly
expensive.
I wonder though, since usage of query options should be the exception
rather than the rule, what environment requires such an amount of tweaking?
Right now it appears the QIBM_DB_SQLADM function usage is our best
option.
As I understand how those "Function Usage" permissions work, like
authority, they are available from a [supplemental] group profile.
Creating a user profile SQLADMIN with no private nor special
authorities, and then changing any particular user to have the user
SQLADMIN as a supplemental group might be an option as well. That may
or may not be better for assigning and tracking the capability.
Regards, Chuck
midrange.com
