Thanks Tom but when we use exit program for exit point (QIBM_QZDA_INIT/ ZDAI0100) we just allow or not allow, my needing here is allow but allow what file in what library as we want.
You'd need to utilize Parameter fields for exit point QIBM_QZDA_SQL2 format ZDAQ0200. The actual SQL statement is available there.
It's clearly not a trivial undertaking. (Well, that is, it becomes clear after enough testing over enough possible submissions through the server.)
I suggest an initial exit program that simply scans the SQL statement for the string of characters that match the file name. Don't reject anything at first; just log the statement with an indication whether it should be accepted or not.
After a significant number of transactions have passed, review the logged statements to see if any were incorrectly judged. Fine tune the coding to fix any false positives or negatives, and try again.
An alternative is to purchase a 3rd-party exit point product. I can suggest PowerTech's Network Security product, but there are products from other vendors. Network Security's 'Rules by object' feature would apply. (Disclaimer: I was employed by PowerTech for 12 years before resigning last year.)
Parsing SQL on the fly introduces a lot of CPU cycles into transactions, so it's not always a good solution. It is sometimes the only solution though.
In this case, if it truly is intended to limit remote access to a single file (or very limited subset), there could be an alternative concept. Have the exit program switch to an alternative user profile. Set *CHANGE authority on the single file for this alternative profile and *EXCLUDE on other files. Set *EXCLUDE on other libraries for this profile.
Once the switch is made, the job will only have authority to the single library and to the single file. No need to parse SQL.
You can create the profile and set the authority first without an exit program. Use the profile to test various statements with remote SQL. Once you're satisfied that the authority is correct, then you can add the exit program to enforce the authority. Every remote SQL transaction will then run under the alternative profile's authority regardless of who submits it. Any transaction against a *EXCLUDE object will fail.
There might be better methods. It's hard to tell without knowing a lot more about the whole environment. But in the absence of correct authority on all potential objects, exit programming is about all there is.
Tom
Application Admin will be on Alll ODBC files
Only if the ODBC client honors the setting. The server does not enforce the setting. If an ODBC client doesn't check the function registry, it won't matter if you set it or not. The iSeries Access ODBC client driver is the only I'm sure of that will honor Application Administration ODBC settings.
See Block Crystal Reports from iSeries access for IBM's recommendation.
Tom
Discuss This Question: 7 Replies