Memory Layout (was URGENT! - Program Error)

["Jon Paris" <Jon.Paris@xxxxxxxxxxxxxx>]

 >> By the way anyone have good layman's why of explaining how the memory is
handle so you know what field is overlaying another and why.  Meaning how
memory storage orders fields behind the scenes???

The only thing you can be sure of is if the field is in a DS.  The compiler
will guarantee that a DS is as you lay it out - beyond that - particularly
with RPG IV - I think all bets are off.  Even if the compiler lays out
memory in a specific order, the optimizer (and there's always some
optimization) will move stuff around.  This problem is often spotted for the
first time after a program is converted to RPG IV for  RPG III.  The change
in the memory map causes corruption to occur somewhere that matters!

In the past what I have often done to locate this kind of problem is to move
all parms that are passed _from_ the program that experience the explosion
into a DS to try to further isolate the field that has the problems.  So if
I am passing a 10ch field - I place it in a DS and follow it with (say) a
20ch field consisting of all *'s or something (not blanks or zeros - they
are too often the ultimate culprit).  Then when things go boom, you look at
all the DSs and hopefully locate the trouble.

Remember as well that the corruption may be occurring many levels away (and
sometimes many hours away!) from where the problem is detected.  If A calls
B calls C calls D and B blows up, you look to C and D for the answers.  It
could have happened at any time since the program started running.  Also if
from time to time B also calls X and Y, they are candidates too - even if
they were called during initialization and that was hours ago.

Jon Paris
Partner400