RE: URGENT! - Program Error -- RPG400-L

I agree with Joe; following method below you sometimes do not even have to
know what code is doing at first. Process of elimination narrows it down for
you then you just figure out a small part. I been through all this before
with bad parm lengths. One time had I/O error on whichever File was first in
F Specs. So Error occur where ever that file chain,read,etc occur in code.
Pretty scary. All came back to *Entry Plist which LOOKED GOOD. *** Note it
was larger and overflow in memory. Soooo noting the comments from others I
wonder what it could be????

Just for the record I'm no expert in these matters. Probably why I've seen
so many of these problems on this list. Wished I had had this kind of
resource. It makes for a long day to figure out on your own and still not
know why exactly.

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

Good Eliminating to you Sir.
Bill H.

-----Original Message-----
From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]
Sent: Saturday, September 14, 2002 12:21 AM
To: rpg400-l@midrange.com
Subject: RE: URGENT! - Program Error


When you have eliminated the impossible, whatever remains, however
improbable, must be the truth. - Sherlock Holmes

Much of debugging is about eliminating possibilities.  You need to find what
is causing the error, then determine the why.  By commenting out the new
subroutines, you will determine whether their existence is causing the
problem.  There are two possibilities:

1. Having the code in the program causes the problem
2. Having the code in the program does not cause the problem

In the former case the error will go away when you comment out the code.  In
that case, uncomment one subroutine at a time, and determine which
subroutine causes the problem.  Once you've identified the subroutine,
reverse the process and comment out one line of code at a time in that
subroutine until you determine exactly which one causes the error.

In the latter case, the error still occurs even with the subroutines
commented out.  The next step is to physically delete them and see if the
problem exists.  If the problem still exists, then the original code had the
problem, and we can address the issue from there.

Debugging is not divination or sorcery - it's simply a matter of using the
scientific method to identify the code that causes the problem.  The
technique I've outlined is guaranteed to either isolate the code that breaks
the program, or to identify the problem as existing in the original code.

Joe



> From: Wills, Mike N. (TC)
>
> .... but I am not using those routines.
>
> From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]
>
> > From: Wills, Mike N. (TC)
> >
> > These new subroutines aren't even being touched right now
> though. I don't
> > see how they could affect the program.
>
> I know this maye seem a bit silly at first, but have you tried commenting
> out all the lines in the new subroutines and then trying again?  If that
> WORKS, then comment each one back in and see which one breaks the program.
>
> If commenting out doesn't work, then you've got a different problem.
>
> This is my own personal method of "divide and conquer".
>
> Joe

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