× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



You can have 1 per lib (should not alter the QAQQINI name).
I have seen sample code of even dynamically creating a copy, altering it, then
CHGQRYA, but we are looking at

high volume data entry, need sub-second response.
Right now it appears the QIBM_DB_SQLADM function usage is our best option.
Jim Franz
 




________________________________
From: "Monnier, Gary" <Gary.Monnier@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Wed, May 9, 2012 11:29:48 AM
Subject: RE: v6r1 ptfs chg security requiremnt setting QAQQINI lib

Frankly, I'm not sure.  A user profile swap can get you to a point where you
have the necessary authority to change QAQQINI (> > but short of giving user
*jobctl auth).

Gary Monnier

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx]
On Behalf Of Jack Kingsley
Sent: Wednesday, May 09, 2012 6:59 AM
To: Midrange Systems Technical Discussion
Subject: Re: v6r1 ptfs chg security requiremnt setting QAQQINI lib

how many of these( QAQQINI) can you have by library.


On Tue, May 8, 2012 at 3:28 PM, Monnier, Gary <Gary.Monnier@xxxxxxxxx>wrote:

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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.