Browse Prior Art Database

Distributed Error Reporting in a Network Environment

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

Publishing Venue

IBM

Related People

Bybee, G: AUTHOR [+11]

Abstract

In a distributed application, the processing required to complete an application task may be parcelled out for execution on a number of different nodes. Errors encountered by one of the parcelled processes should be reported both on the node where the process is executing, and on the node from which the application task was initiated. Such reporting must also be enabled for National Language Support (NLS) so that errors can be reported in each node's configured language.

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

Distributed Error Reporting in a Network Environment

      In a distributed application, the processing required to
complete an application task may be parcelled out for execution on a
number of different nodes.  Errors encountered by one of the
parcelled processes should be reported both on the node where the
process is executing, and on the node from which the application task
was initiated.  Such reporting must also be enabled for National
Language Support (NLS) so that errors can be reported in each node's
configured language.

      Described is a method for reporting the same error occurrence
on differing nodes in a distributed application.  National Language
Support is provided so that the error is reported in each machine's
configured language.

      The distributed product effort that lead to this article
involved an application that vended work out to remote nodes in a
network environment to complete the processing associated with a
user's request.  The work vended to one node is independent of that
vended to another; both pieces could proceed in parallel and were
subject to independent error conditions that could be encountered on
each node.

      To facilitate the task of tracking parcelled work in progress,
the application uses a number of control files:

o   A status table on each node that tracks the processing parcels of
    work that have been vended:

    -   A primary request entry in the table tracks the overall
        status of a request that was started on the current node, and
        for which some processing may have been parcelled out to
        other nodes.

    -   A secondary request entry in the status table represents a
        parcel of work from a primary requests that has been assigned
        for execution on the current node.

    -   A results file, referenced by the status table entry,
        containing detailed information on the parcel of processing
        work that is to be done by the application.  In the
        distributed application, the results file tracked files and
        directories that needed to be backed up or recovered by the
        application.

          This scheme is illustrated in the figure.

          The tasks associated with items in a single results file
    are usually done by a single process or thread on the node.
    Status on the work completed and in process is recorded in the
    results file and status table.

          The status table and results file have error fields
    associated with each entry.  When an error occurs in the
    processing for an item in the results file, an error record is
    created and stored in the item's associated field in the file.
    Similarly, when an error occurs with the creation or termination
    of a work parcel, the error record is written into the field
    associated...