Browse Prior Art Database

Intelligent Dump for I/O Processor

IP.com Disclosure Number: IPCOM000104414D
Original Publication Date: 1993-Apr-01
Included in the Prior Art Database: 2005-Mar-19
Document File: 4 page(s) / 104K

Publishing Venue

IBM

Related People

Bashore, TJ: AUTHOR [+2]

Abstract

A method for reducing the amount of dump space required for a subsystem is disclosed. Memory use within the subsystem is tracked and memory segments are prioritized according to their contents. The tracking mechanism is built into the memory allocation component within the subsystem through the use of a simple table. This table is rebuilt when a memory dump is requested so that the highest priority memory segments are dumped first.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 41% of the total text.

Intelligent Dump for I/O Processor

      A method for reducing the amount of dump space required for a
subsystem is disclosed.  Memory use within the subsystem is tracked
and memory segments are prioritized according to their contents.  The
tracking mechanism is built into the memory allocation component
within the subsystem through the use of a simple table.  This table
is rebuilt when a memory dump is requested so that the highest
priority memory segments are dumped first.

      This solution was developed for managing the AS/400* I/O
processor (IOP) dump process.  While the description below is
tailored for an IOP, the general solution could be used in other
subsystems.

      This solution uses a dump table which takes on two forms:
run-time and dump-time.  The run-time table is maintained by the
storage allocation routines and users who allocate storage can assign
priorities to the data areas through the storage allocation
interfaces.  The table will also contain a key field, usually a task
ID, which is used when a task causes a fatal error.  When a task
detects a critical situation, it can promote its data areas to a
higher priority than the other tasks.  If the task recovers, it may
then demote its data areas to their original priority levels.  The
dump-time table is built using the run-time table and will contain
the entries in priority order.  The dump-time table will be the first
thing in the dump and the storage will be dumped in priority order.

In developing this solution, several goals were kept in mind:

o   Provide a method of providing both a smart (small) dump and a
    total dump.  The priority and key fields provide the smart dump
    capability.

o   Provide a dump table that could be used in the following manners:

            - The dump code needed a programmable method of
     determining how/what to dump.
          - Dump analysis tools needed some method of locating memory
     areas in the dump.
          - Support teams need ways to read dumps either online or on
     paper.  This involves
            locating memory areas in the dump.
          - Provide a method to subset dumps so that they could be
     sent over slow communi-
            cation lines.  Because the storage is dumped in priority
     order, a utility could be built to
            just transfer the most important part of the dump.

DUMP TABLE

The IOP would maintain a dump table during run-time so that dump code
can use it to build the dump-time table.  The dump code will then
re-order the entries in priority order, filling in some of the fields
that are specific to dump time (see the figure).

The fields are defined as follows:

FIELD NAME               DESCRIPTION

Total # of entries       Total number of entries in the table,
                including the table extensions.
# of used entries ...