Are you using OPTION(*NOUNREF)? If so, good! If not, read on

Are you using OPTION(*NOUNREF)? If so, good! If not, read on

If you're not already using OPTION(*NOUNREF), I recommend that you consider doing so.

OPTION(*NOUNREF) was introduced in 6.1. It tells the compiler not to generate unused fields into the module.

By default, with OPTION(*UNREF), the ILE RPG compiler generates unused fields into the module. Before 6.1, you had no control over this.

The default *UNREF has some negative effects.

• Too much storage for the module

  The most common ways for a module to have unused variables is due to unused fields from input files (sometimes there are hundreds or even thousands of RNF7031 messages for modules with lots of files), and unused fields in /COPY files. This usually contributes to unnecessary amounts of static storage, which can both affect the amount of static storage used by the module, and the amount of time needed to activate the module into an activation group.

  It's less likely to have unused automatic storage in a procedure, although variables can become unused over time, and it's possible to code a /COPY in a procedure.

• Confusion while debugging input operations

  For modules that have input files where many of the fields are not used in the module, when an input field is not used in the module, the compiler doesn't load the field during an input operation.

  With the default OPTION(*UNREF), after a READ to a file, you might want to look at a few fields to see what record you got. If you didn't use a field in the module, the compiler wouldn't load it, so it would have blanks or zeros. This can be extremely confusing.

  With OPTION(*NOUNREF), if you try to look at one of the fields you didn't use in the module, the debugger says that the field doesn't exist. This is also confusing, but it is less confusing than seeing blanks or zeros. When the value of the field is blanks or zeros, the first thing you check is the actual record in the file. Eventually, you might look in the manual or post a question in a forum. When the debugger says that the field doesn't exist, you are more likely to immediately look in the manual or post a question in a forum.

  Note: If you want to see the values of all the fields in your records after a read while debugging, code DEBUG(*INPUT) in your H spec. That will cause all the input fields to be available in the program and loaded by an input operation.