Disregard. There was a rename of the field in the I specs and apparently it's not valid, or something, because neither the actual field name or the renamed field name displayed a value. So, I guess with that said, if you can't rename a field in the I specs anymore, how can I do it without having to do it at the file level?

If a field isn't touched by the program, the optimizer will throw it out. Perhaps it is related to your issue?

I don't think you can do it at file level, but in control spec (H-spec), you can use OPTION(*UNREF) to force it to generate all variables. Or *NOUNREF, which means unreferenced variables are not generated unless needed by some other module. The same values are in the OPTION keyword on CRTBNDRPG and CRTRPGMOD.

Just thinking... often times we forget that D-spec oriented numeric fields will default to Packed when no datatype is specified, where as Input spec defined fields default to Zoned. I'm wondering if you have an Input field that has been previously defined on a D spec (D specs appear before I specs) if it forces the field defintion to the D-spec attributes.

Suppose you have an Input spec that is Zoned, but there is also a D-spec version of the field that is Packed. I'm wondering if there is a priority of "I over D" or if normal chronology is taken into account? Something to set and document, I suppose.