RE: Overlaying a DS Array In a LIKEREC DS

Jon, I believe this is related to age-old "unreferenced fields"
idiosyncrasy. Even as far back as the System/3, the RPG compiler has always
removed fields that are unreferenced (RNF7031 "errors"). Going back to
those days, the compiler removed any such fields because that saved effort
on READ/WRITE operations (no need to move from the input buffer if it's
never used). I believe the practice remains today. *BUT* I don't know what
happens when the READ is to a data structure. Seems to me at that point
that the fields should be populated. If they're blank in that scenario,
then it seems to me that either there's mystery happening and the
READ-INTO-DS doesn't work like it appears to be designed (which I doubt), or
the compiler is wiping the unreferenced fields (which I also doubt).

But I think (if this is the issue) that you can hand-define those fields all
you want, and it won't eliminate the 7031 "error," and therefore neither the
compiler's propensity to remove them for efficiency's sake.

Barbara, am I off base here?

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"Experience enables you to recognize a mistake when you make it again."
-- Franklin P. Jones

>> That's not true, I use this method all the time and have never
encountered a time when all the fields didn't get populated after a
read.

And I had always believed that until recently when trying to resolve
an issue that came up on another forum - see
http://www.code400.com/forum/showthread.php/9364-Hi
for the details.

But I must explore further because you have got me wondering whether
there is a difference between a DS where you simply list the field
names and an externally described one. It wouldn't make any sense for
the compiler to do it that way but ...

>> Notice that in the DSPECS, I did not redefine how the fields are
defined. So the program is using the fields from the file therefore
they are being used in the program.

As I said I am very familiar with the technique - I published it years
ago and teach it frequently.

>>How is the example I gave too error prone. If the field sizes are
identical, there's nothing to screw up. In this example position 1 is
where field 1 begins. If you try to dim incorrectly the editor will
tell you that it's wrong. Also that's what testing is for.

OK - too error prone for _me_ - you manually specified the length and
told the compiler to divide by 20 i.e.

D array 1 100 Dim(20)

If all the elements are the same - which of course they have to be -
then a safer approach surely would be:

D array Like(Field1) Dim(20)

That way if the field definitions change it self-corrects. As far as
I'm concerned testing should be a last resort - if there are coding
techniques that I can use to reduce./remove the possibility of error
then I prefer to use them particularly as in this case it means _less_
work (no calculation of total length needed)


Jon Paris

www.Partner400.com
www.SystemiDeveloper.com



--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.