Down in the dumps - Computers for Smart People - page 108

21. Down in the dumps
Before I get into dumps , let's review what happens when we run a program. The
program is somewhere in the computer and each statement or instruction as well as data
structures and the data itself could be in the machine. Much of this can be found in an
area called working storage , and it is nothing more than a temporary place for a program
as it gets executed, or run. If there is a problem as the program runs, we will have the
luxury of looking at these areas of working storage to see what the problem is. As you
know, a program that has difficulty running is said to abend and the result is a dump, or
more specifically a picture of working storage. But it is not a pretty picture.
A dump shows instructions in our program and data in almost unreadable format.
After all, the computer processes programs that we wrote as object code or machine
language, which is foreign to us. The result is a dump in hexadecimal format, which
happens to be base 16. We will need to be able to count in that base in order to read a
dump. Fortunately with all the tools and advances in information technology, we really
won't need to worry about reading dumps on a serious level. If you own a PC and
sometimes run into unexplainable problems (if you don't have crashes you are probably
from another planet), the result on your screen is a meaningless message, or perhaps
nothing is happening. A restart of the PC will remedy that.
The early days of computing forced people to know hexadecimal and how to read
dumps. I'll talk about specifics regarding other base systems in the next chapter but for
now I will summarize what a dump involves. To begin with, you could get a dump if you
tried to run a program and that program couldn't be found on the computer. Maybe you
put the executable program in library B but the computer was looking in library A so
that's why it wasn't found. The solution is either put the program in library A or point to
library B when you run the program. If we have the program not found scenario we might
get a dump along with some kind of system code, which right away indicates to us that
the program was not in the library where it should have been. Thus the dump was not
really needed.
You could also get a dump if you tried to create a file but didn't allow enough
space for the records in the file. Once again you would see a familiar system code along
with the redundant and unnecessary dump. After getting the same system code, you
would easily recognize that your file needed more space. A similar situation would occur
for other little problems and in most cases, the system code would tell you all you needed
to know without any need for that hexadecimal junk.
However, back in the old days there may have been other times when you had bad
data and you got a dump along with a certain system code. You might recognize that the
system code indicates bad data but it wouldn't tell you which record and what field
caused the problem. On that occasion you had to dig into the dreaded dump. There was a
specific code that warned you of an attempt to divide by zero, which is not allowed since
it can't be done. If you ran into this system code, you could just search your program for
the division operation since it was rare in programs and you would have a fairly good idea
of your problem. Bad data other than that was another story altogether.