I'll have to take a look at the OVRDBF option. Although that would rely on either specifying all necessary files to be overridden, or have a process automatically perform such override for all files in the production library.
I'm not sure what to with knowing about FRCQRYI. Would I open a PMR and request this tool from IBM?
-Kurt
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Friday, June 07, 2013 3:13 PM
To: midrange-l@xxxxxxxxxxxx
Subject: 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.
--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
