On 2012/4/6 10:56 AM, Jeff Crosby wrote:
... I have read you can't
debug a variable that's not used in the program if NOUNREF is specified,
but if the variable isn't used I'm not sure how often one would need to see
the value when it isn't even used . . .
I would always use *NOUNREF. I don't think there are any circumstances
where *UNREF would be better.
If the default of UNREF is specified, you can debug a variable that's
not used in the program, but if it's a variable that would normally be
loaded by an input operation, the value of the variable won't change.
H spec DEBUG(*INPUT) overrides NOUNREF for unused input fields. If you
specify H spec DEBUG(*INPUT) (or just DEBUG, or DEBUG(*YES)), then
during input, RPG will load the values for fields that aren't
referenced. And even if you specified *NOUNREF, RPG will keep those
unused input fields.
So, for unused input fields:
- without DEBUG(*INPUT)
- - with NOUNREF, you can't see those fields in debug
- - with UNREF, you can see those fields in debug, but their values
never change even after an input operation
- with DEBUG(*INPUT), and either NOUNREF or UNREF, you can see those
fields in debug, and the values change after an input operation
Say you code a new program with an externally-described file with just a
READ operation, but no other logic. Now, you want to see how that will
work, so you fire up the debugger.
1. If you don't code the DEBUG keyword, and you have *UNREF, your debug
session will go like this:
> EVAL name
NAME = ' '
"Hey, why is the NAME field blank?
> EVAL id
ID = 000000000000000.
"Hey, and id is zero? The READ's not working!"
2. If you don't code the DEBUG keyword, and you have *NOUNREF, your
debug session will go like this:
> EVAL name
Identifier does not exist.
"Huh?"
> EVAL id
Identifier does not exist.
"Hey, why don't my variables show up in debug? ... hmm ... maybe I have
to use them in the program before they show up in debug"
3. If you code DEBUG(*INPUT), then your debug session will go like this:
> EVAL name
NAME = 'John Smith'
"Perfect, all the values are exactly what I expected."
Almost nobody codes the DEBUG keyword, so most people would be in
scenario 1 or 2. I think scenario 1 is the worst one to experience - it
looks like a problem with the program logic when it's really a debug issue.
When it looks like a problem with the READ, the poor programmer will
start messing with their code trying to fix a problem that doesn't
exist. When it looks like a problem with the debugger, at least the
programmer isn't going to waste their time messing up their program logic.
As an Amazon Associate we earn from qualifying purchases.