Re: SQL Filling Job Log

[CRPence <CRPbottle@xxxxxxxxx>]

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.