Subject: | |
From: | |
Reply To: | |
Date: | Fri, 30 Jul 1999 10:25:47 +0200 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
"Schlosser, Robert (Contractor)" wrote:
>
> Martin
>
> HP has a product, AUTORESTART, that will automatically take a memory
> dump to disk and restart the system. You can then store it to tape or use it on
> the system to discover the problem. It does require a dedicated volume set, with
> preallocated dump areas. Have used it at another site and it works well, has
> several configuration options.
A few comments to the general discussion about memory dumps:
- AutoRestart/iX dump files do not have to be on a separate volume set,
but it helps managing it this way. When these diskdump files are
created a VSCLOSE needs to be done. This is of course more convenient
on a separate volumeset, but can a less used volume_set (like for
development) can also be used. Creating diskdump files in the $SYS_SET
requires a SHUTDOWN.
- AFAIK, the labs are actively investigating what can be done to reduce
dump sizes (and dumping time) with respect to the larger memory systems
that we will see in the future.
- Stan already pointed out that there is a 'primitive' standalone analysis
tool (ISL > SAT), which can be used to retrieve some first pass information
about a system halt/abort. Information like the system abort number/message
coupled with a stack trace of the aborting process and its program
name can
sometimes already lead to indentify problems that are already reported,fixed,
or under investigation. Someties this can save you he extra time to
take the
dump. It will not suffice for investigation of new problems, and is
also less
usefull for analysing system hangs.
- A mostly unknown feature of the AutoRestart/iX product is the 'minidump'
facility. This can be used to automate the capture of system abort info
via the SAT tool. AFAIR, it can be configured to compare the actual abort
information (I think it is only the system abort number) with your own
'system abort database', therefore automatically decide that no dump needs
to be taken because you already previously dumped an 'identical' abort.
(I humbly think that this is only useful with system aborts that are very
specific and can be judged to have the same cause by the SA ####,
which is
not true in general). Stan already pointed out that SAT has no knowledge
of the file system and cannot use the DAT macros for that reason. I seem
to remember that the MiniDump facility can be configured to execute macros
as well. The method to set this up are similar to that enabling DUMP to
find the diskdump files i.e. via disk and sector adresses .
Goetz.
|
|
|