Re: v6r1 ptfs chg security requiremnt setting QAQQINI lib

On 08 May 2012 07:08, J Franz wrote:

In some of the recent ptfs, IBM has added an error msg in a
QZDASOINIT job (pc client, odbc) where setting the QAQQINI lib in the
dsn caused a CPF9898 error that allows process to run, but QAQQINI
lib not changed and used default.

I understand why IBM is adding this, and Scott Forstie wrote a great
article:
http://www-03.ibm.com/systems/resources/systems_i_db2_navigator_security_controls.pdf

but short of giving user *jobctl auth (not going to happen) or the
QIBM_DB_SQLADM function usage for each user (lot's of users and
changes often), it seems cannot easily point a job to a diff QAQQINI.

We have lot's of client code written in diff tools, not easily
changed, and need to force certain work thru CQE (it still works
there..), while others need SQE for performance.

Is there an alternative method to point to various QAQQINI's from
various apps? (btw-i'm not the pc client developer..)

There is an exit program for the client requests, and there are also SQL "client" special registers which could presumably be accessed to determine an appropriate setting. I do not recall if the connection string [e.g. for keyword QAQQINILIB or QAQQINILibrary] is available to the exit program interface, which I suppose would be better to allow a transparent transition; i.e. to allow whatever is the security concern to become the onus of the exit program implementing the same effect as what was done by the OS prior to any [PTF] changes.

Presumably a stored procedure call, a program using adopted authority, could issue a CHGQRYA. The program implementing the stored procedure could be a CLP that accepts an input parameter for the QRYOPTLIB. Then instead of the connection string, the client application could insert a CALL to that procedure.?

Regards, Chuck