RE: Memory Layout (was URGENT! - Program Error)

Thanks,

Like the DS idea. Usually just go through Plists until I find the parm with
the wrong len. Glad I did not start seeing these type errors(I/O,data
dec.,etc) After Clients started with a wider modular design of system apps.
Could see where this could be a late for just have a parm one digit off.
Might be a good tool to write. Follows call path and compares parms along
the way.

Yours
"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."

That's what I was after. Whenever I've had these errors I've always
"Speculated" "Hypothesized" and "Guessed" why one field overlaid the other
in memory based off 'D' specs order. I can drop it now the next time :).

I've gotten to the point where if I get a message that makes no
sense(code/fields look good)  for that area of program I look for wrong
parms. Guess I should three finger and one thumb type them in right in the
first place. :)

Anyone got any "way out there in left field" message stories from wrong parm
lengths? That they want to share so others may be looking out for them.
Thanks
Bill H.

-----Original Message-----
From: Jon Paris [mailto:Jon.Paris@Partner400.com]
Sent: Monday, September 16, 2002 12:07 PM
To: rpg400-l@midrange.com
Subject: Memory Layout (was URGENT! - Program Error)


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


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