Re: SQL Filling Job Log

On 07 Jun 2013 14:14, Anderson, Kurt wrote:

In our stand-alone test environments (not using the production
library) we use special test user profiles. <<SNIP>>

In such a controlled environment, the Database Open exit point could be utilized to directly replace the effect of STRDBG UPDPROD(*NO) with an exit program. The exit program for database open could effect the identical work as the database open either would have already performed or will perform [i.e. I am unsure if the exit point precedes or fallows its UpdProd testing by the DB-Open processing]. So instead of the work being predicated on the debug feature having been activated while disallowing update to production files, the action of the exit program would be predicated on the job being identified as a testing-job; e.g. per the /test user profile/ being the job or current user, or some other indication. If the job is not part of known testing, then the exit program would just return without doing anything except setting the output value, the /Return Code/ to one to indicate the open should continue. Otherwise if the open options include anything other than read capability, per details provided to the exit program via the format DBOP0100, and the Library Type (TYPE) [e.g. RTVLIBD; or a cached\static value] for the library of the file(s) is not equal to 'TEST', the exit program would send the diagnostic CPF4203 and tell the exit point to disallow the open; i.e. the /Return Code/ would be set to zero to indicate that "The open should be rejected."

http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/apis/xopendbf.htm
_i Open Database File Exit Program i_
"...
Exit Point Name: QIBM_QDB_OPEN
...
# <<Start of change>> Exit program data can be specified to control whether the exit program is called for a specific file. Three exit program data values are supported that are used in conjunction with the object audit attribute:
..."

Note: This exit was updated to allow data on the ADDEXITPGM to narrow against which files the exit will be invoked, so as to limit the formerly effective system-wide all-non-system-file-opens impact. See the change flagged information in the above doc link. The capability would depend on the testing user profile(s) being established for some level of auditing, as well as established for those files in the production library, even if user\object audit logging is not actually in effect.