Re: SQL Filling Job Log

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.