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'


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-2022 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.