Re: SQL Filling Job Log

[Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>]

Another crazy idea - I've heard that some say to do an OVRDBF for every 
file being used. It adds lots of lines to CL that I think are completely 
unnecessary.

But it does open an idea - have the OVRDBF with one of the values be the 
INHWRT value - then use a job switch or some other method to choose 
whether test or production.

Maybe?

Vern

On 6/7/2013 4:12 PM, Anderson, Kurt wrote:
> 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.