× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.