×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 1/18/2012 3:39 AM, PAPWORTH Paul wrote:
Just out of interest have you any tips on how we might find this
problem. I suspect a pointer management error in a downline program from
the one that falls over on a write instruction. In the log the line in
error is a endsr which has nothing to do with the write that falls over.
Assume for a moment that you know that a particular variable is being
passed around as a parameter, and that one of the called programs is
assuming its parameter is bigger than it really is.
What you can do to track down the problem is to get control of the
storage that is being corrupted so that you can watch it in debug and
see where it's being corrupted.
Temporarily, change the definition of that variable so it's a subfield
of a data structure, and add another subfield following it.
Before:
D myfld s 10a
After:
D ds
D myfld 10a
D check 10a inz(*all'ff')
If that's not possible, try making that variable based, and define the
actual storage to be big enough for that variable plus the check subfield.
Before
D myDs ds likeds(something)
After:
D myDs ds likeds(something) based(pMyDs)
D pMyDs s * inz(%addr(storage))
D storage ds
D ds like(myDs)
D check 10a inz(*all'ff')
If everything is working correctly, the "check" subfield should never be
changed. To debug this, put a watch on the check subfield (debug command
"watch check") and let the application run. As long as all the programs
are debuggable, you should get a watch breakpoint as soon as the check
subfield is modified.
The biggest task is usually to figure out what variables you should be
suspecting, but it sounds like you already have a good idea what those
might be.
midrange.com
