Information Technology Reference
In-Depth Information
You could actually figure out what was wrong without reading the dump in many
cases. Of course you would need to know at about what statement your program abended.
If you could figure that it was one of two or three lines, you could see where the difficulty
lay. The statement that was the problem was more or less spelled out to you as an
interrupt, that is, there would be some statement to the effect
INTERRUPT AT 003A6
but you had to interpret which line that represented in your program. The way to do this
involves looking at the listing of your program, which has numbers somewhere relating
this number to some line of your program. That is to say, this strange number
003A6
actually points to the statement in your program where the interrupt or problem occurred.
The listing that correlates your program statements to another set of numbers is called a
PMAP, which stands for procedure map and it ties the statement number to a number in
storage.
Of course you could look at the PMAP and not find the
003A6
anywhere but you saw on two successive lines
003A2
003B4
and this would indicate that the statement corresponding to
003A6
was either of the two lines above. This is so because our strange number is a
hexadecinmal number between 003A2 and 003B4. I don't expect you to understand that
since you probably don't know how to count in base 16 so take it on faith for now. Since
our interrupt is between these two numbers, this means that one of the statements
corresponding to these two numbers is what caused our program to abend.
The complicated procedure above is how I used to track down abends in
programs, provided I had a PMAP. I would then look at the statement or two and since
only a variable or two was involved, I quickly got to the root of the problem. In addition,
the dump would actually show you what was in the variables but you had to find that area
of working storage in the dump and it may not have always been easy.
Today we don't actually need to worry about this technique as some software tool
might be very specific in pointing out not only the statement where the problem exists but
also the field that's in error. All you have to do is look at it and proceed from there. If the
variable in question wasn't specifically spelled out, you could look at the troublesome
statement and check each variable on that line. If a variable was supposed to be numeric
you might easily discover that it had spaces in it and that was the cause of the abend.
Whenever I worked with testing programs, I always felt there were only two
possibilities. Either I wrote the program from scratch and so I was very familiar with the
goings on of the process, or I made a small change to an existing program. If the program
was new and abended, I would probably know without too much trouble what was wrong
since I had a good grasp of all that was happening. If the program wasn't new and
involved a change, there was a high probability that the abend occurred at the line that
was modified or something related to the change. That thinking usually worked for me.