On 7/14/2014 12:12 PM, Edmund Reinhardt wrote:
I understand the desire to use UPDPROD(*NO) while debugging in order to
prevent data corruption while debugging programs.
I'd like to share an embarrassing experience in the hopes that someone
will learn from my mistake. Once upon a time, I had a complex program
that I needed to debug. It was one program in the middle of a fairly
complex batch process. Setting up a test environment with 100% of all
the objects needed was going to be very tiresome given that only a few
files were going to be updated: most of the files were read-only, or
printer files. So I copied the update capable files to my test library
and ran the production job with my test library at the top of the
library list and UPDPROD(*NO), thus making sure none of the programs
would open a production file for update. Caught a few I missed, which
was a good deal. Got to the troublesome code, set breakpoints, narrowed
it down and ran it a few more times until I was able to recreate that
bug 100% of the time.
I'd completely forgotten that one of the steps of this complex job
stream was to send purchase orders to our EDI trading partners. Which
it did. Multiple times.
The moral of this funny old story is that if you want to be sure you
don't muck up your production data, don't rely on UPDPROD(*NO). Use a
full test environment, down to each and every program, printer file and
data area. Did you know that UPDPROD(*NO) doesn't protect data areas?
Guess how I found that out. More fun times. [1]
Under what circumstances
would UPDPROD(*YES) be useful when analyzing code coverage?
Running coverage over production data would reveal old code designed to
work with data that may no longer be in the system. Things put in place
for corporate mergers, product numbering changes, brand name changes,
that sort of thing.
In my mind, I'm not as concerned about UPDPROD(*YES) as I am about the
production library list. UPDPROD only comes into the picture
accidentally, as a side effect of the use of debug to capture the trace
data.
--buck
[1] Try it yourself:
pgm
chgdtaara qgpl/buckdebug '1'
endpgm
CRTDTAARA DTAARA(QGPL/BUCKDEBUG) TYPE(*CHAR) VALUE('0')
strdbg updprod(*no)
call buckdtaara
dspdtaara buckdebug
Value
*...+
'1'
midrange.com
