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



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.

This thread ...


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.