HP3000-L Archives

July 2002, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Gavin Scott <[log in to unmask]>
Reply To:
Gavin Scott <[log in to unmask]>
Date:
Mon, 1 Jul 2002 10:46:07 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (56 lines)
Gibson writes:
> Yes, it sound like the dump analyzer is powerful.
> Who has it and will it be available after 2006?

You have it:

:LISTF @.DAT.TELESUP

and even the manual:

http://docs.hp.com/mpeix/onlinedocs/32650-90901/32650-90901.html

Of course you have to know what to look for if you want to get very far.
But it's always been my strong conviction that every (serious) programmer
and key systems management people should know how their machine works at
least down to the machine instruction level so that they can debug programs
at the machine level when required.  This means learning a little about the
machine instruction set (mind the wrap):

http://h21007.www2.hp.com/dspp/files/unprotected/devresource/Docs/Refs/PA1_1
/acd.pdf

and a more about the calling conventions:

http://devresource.hp.com/STK/partner/rad_10_20.pdf

so that you can put breakpoints at functions and see what the parameters and
results are for the call.

But as far as reading dumps goes:

Determining the "root cause" of a software bug is rarely easy and often
impractical without source code, but generally it's not too hard to
determine the sequence of events that lead to the hang/failure so that the
customer can avoid triggering the problem in the future.  Remember that
thousands of people are running the same version of MPE that you are and are
not seeing the problem, so you generally have to be doing something unusual
to crash a system due to an MPE software bug.

Third party software that crashes the system is usually very easy to
identify, often down to exactly what the 3rd party did wrong.  It's always
fun to call in a bug report where you can say "I don't know what your source
code looks like, but I can tell you that you have a line of code that looks
very much like "XYZ" that needs to be changed to "ABC" :-)

Hardware problems are the most common cause of system failures and are
usually straightforward to identify from a memory dump.  For these problems
the "fix" is to repair/replace/discontinue use of the offending component,
so these become issues for your hardware maintenance provider (HP or
otherwise).

G.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2