Re: SQL Filling Job Log

[CRPence <CRPbottle@xxxxxxxxx>]

On 07 Jun 2013 09:26, Anderson, Kurt wrote:
> <<SNIP>> we run them with STRDBG on so we don't accidentally update
> production.  The unfortunate side effect is that the test runs a lot
> longer than it needs to because it's filling up the job log with SQL
> messages. <<SNIP>>

  I thought there was an option to /suppress/ the message irrespective 
of the Debug being active using some tooling that was a precursor to the 
QAQQINI options file\feature.  That tooling had been shipped via a 
test-fix or similar from IBM service\support, along with a variety of 
other IBM internal-use commands.  If such a suppress feature exists 
however, one would expect they probably would have added that same 
capability as a setting for the MESSAGES_DEBUG option... so maybe I do 
not recall correctly.  Someone with the aforementioned tooling to which 
I allude, could investigate; I unfortunately do not recall the command 
name either.

  While not effected completely\thoroughly so easily as STRDBG 
UPDPROD(*NO), the OVRDBF can accomplish something similar for protection 
from change of production data.  Except even if that can be easily 
enough effected, e.g. by generating a script for all file names in the 
production library, that method is possibly problematic for lack of an 
error being manifest; instead, the I/O is just ignored.  That feature is 
the "Inhibit write" INHWRT() parameter.  Thus if there was one 
production file named PRODFILE in PRODLIBR, then the OVRDBF PRODFILE 
TOFILE(*FILE) INHWRT(*YES) OVRSCOPE(as_required) would be able to 
prevent update I/O activity to that file; any triggers should not fire 
because the I/O request should never reach the database.