|
Could you write an exit program for exit point QIBM_QZDA_SQL2 (an exit--
point for QZDASOINIT) that...
1. Swaps to a user profile that can perform the necessary change.
2. Makes the change.
3. Swap back to the calling user profile.
?
Gary Monnier
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Tuesday, May 08, 2012 12:12 PM
To: midrange-l@xxxxxxxxxxxx
Subject: 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_secu
ri
ty_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
--
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
