QIBM_QSQ_CLI_CONNECT exit point is for CLI aka native ODBC aka native JDBC
driver interface. By default, these run under QSQSRVR jobs. So, this is the
wrong exit point to use.
For QZDASOINIT jobs, you'd want to use the QIBM_QZDA_INIT exit point.
Since you don't want to check the user, you can instead check for the
subsystem job is running in and implement your policy accordingly.
As for doing it in any other way...nope, I don't think there is a way around
the CHGQRYA command.
Elvis
Celebrating 11-Years of SQL Performance Excellence on IBM i, i5/OS and
OS/400
www.centerfieldtechnology.com
-----Original Message-----
Subject: Use a specific QAQQINI for QZDASOINIT jobs in a particular
subsystem
All,
I've got a special subsystem set up with it's own set of QZADSOINIT
jobs to handle connections from a particular IP address.
I'd like these particular jobs to use a specific QAQQINI file also.
I ran across this article,
http://www.mcpressonline.com/database/db2/maximize-sql-query-engine-sqe-usag
e-of-your-db2-web-query-reports.html
, that describes using the QIBM_QSQ_CLI_CONNECT exit point to assign
custom QAQQINI files based upon the user.
In addition, there's an article in Centerfield's newsletter,
http://www.centerfieldtechnology.com/publications/archive/December%202005%20
Newsletter.pdf,
about using the QIBM_QZDA_INIT exit point to assign a custom QAQQINI
file based upon the user.
I think I can get away with checking the user, as the QZDASOINIT jobs
in the special subsystem will all be used by one user.
But I'm wondering which exit point would be better, or if there's another
way.
Thanks!
Charles Wilt
midrange.com
