# Patent

## Title
System and method for automatically initiating a tracing facility and

## Abstract

A selective data capture method for software exception conditions in the operation of a data processing system includes steps for describing the pertinent data to collect before loss of control of the faulty program occurs. First the program preventively declares in a table all the data to capture in case of error (501). In a second stage, at the key points of the code, the pertinent sets of data in the table are activated (502). On the occurrence of an error (503), only the data previously declared and activated are collected (504) by the external code in charge of managing the error reporting to a maintenance subsystem (505). The invention is attached to the global data capture strategy, particularly to the Error Notification and Selective Dump processes.

## Background
The present invention relates to program debugging methods and more particularly to a selective method for capturing data in software exception conditions during the operation of a data processing system.

When a new computer software product is conceived, there is a typical cycle or process that takes place in the course of bringing the product to the market to ensure all the reliability and serviceability required by the customer. The programming cycle typically includes:

Normally the release of a software product depends on meeting a development calendar. If defects or errors (known as bugs) appear in the code, the product deadlines will be missed. This is particularly likely if the bugs are complex, subtle or otherwise difficult to find. Such delays can cause a software product to fail in the marketplace. In the same way, the availability, the quality and the ease of maintenance of a software product are the key factors of a success in a competitive environment.

Historically, most software was designed under the assumption that it would never fail. Software had little or no error detection capability designed into it. When a software error or failure occurred, it was usually the computer operating system that detected the error and the computer operator cancelled the execution of the software program because the correct result was not achieved. To facilitate the development, test and maintenance of more and more important and complex programs, it has been necessary to define debugging methods and tools to detect, isolate, report and recover all software and hardware malfunctions.

Error handling and problem determination are based on the following principles: with all the data needed to understand what is going on. A transient error means a temporary failure which is recovered by the program itself but is however reported for information purpose. course of executing instructions. They can be classified as Faults, Traps, or Aborts depending to the usage of the different suppliers of data processors.

Upon a software error, the most commonly used method is to capture the entire storage area allocated to the program: this process is called Global or Physical Dump. However, to determine the cause of the error or failure are often lost or overlaid difficulty to isolate complex errors storage and can affect the customer performances.

As frequently happens, so much output is generated that any significant information is buried in a mass of unimportant details. Thus the programmer must always guess whether the benefits of preserving and retrieving all the data in the processor storage outweigh the disadvantages of an endless and laborious analysis. In another way, it is not always obvious to follow the path of execution to the point where the error finally appears and most program developers use a process called Trace to isolate a software error. According to this process, Trace points are placed within the failing program in order to sample data through the path of execution, the problem is recreated and data from the trace points are collected. Unfortunately, Traces have some bad side effects including the following: encountered, often resulting in a significant impact to not only the problem program's performance, but to other programs executing on the same system Trace points invariably finds himself sifting through large amounts of data, the majority of which does not reflect on the cause of the error timing problem between two programs (e.g., two networking programs communicating with each other), the trace can slow the program execution down to the point where most timing problem cannot be recreated.

Solicited Dumps and Traces, as described previously, are triggered on request of an external intervening party: console, host, operator . . . . They are based on a methodology which waits for the damage caused by a software error to surface. In both cases large amounts of data are collected, hopefully catching the data that will determine what was wrong.

Immediate error detection and automatic diagnostic data collection can be achieved by means of error code placed directly within the program during development. When an error or failure occurs, it is detected by the program itself which calls a process to capture and report only the data required to debug the error: this process is usually called Error Notification. The description of the data such as layout and format are generally stored in a predefined table whose entries are selected by the error detection code of the program. Typical of this state of the art is the U.S. Pat. No. 5,119,377 disclosing a method and system for detecting and diagnosing errors in a computer program. The major advantages of this process are the following: real time mode. error appears: the problem does not have to be recreated. can occur. data report and the problem isolation and correction. remains completely idle until such condition occurs. The impact on the computer resources and the programs performances remains minimum. triggered and retrieved on request of the program itself (Unsolicited Dump). Traces, also called internal Traces, are an integral part of the code. They are cyclically updated according to the program progress and thereby allow a dynamic view of the suspected code. stages of the code progress or at particular occurrences.

The Error Notification process, previously described, implies that all pieces of code can detect and describe the errors in which they are involved with the actions to be done to recover the control or minimize the impact of the failing element. That means a systematic checking of all inputs (internal and external), the use of hardware checkers and the implementation of functional tests and timers in the key points of the code.

At this stage of analysis, it appears opportune to classify errors in two different types: associated pertinent information are collected by means of a dedicated error code. able to detect itself the error or failure. The error is detected by an external system (the operating system, control program, data processor . . . ) and the pertinent information are collected and reported independently of the faulty program. The exceptions conditions such as divide error, invalid operation code, loop, floating point error . . . belong to this category of major error.

Major Errors pose the problem of the selective data capture by an independent system: the faulty program is no longer able to describe the useful data to report and the Error Notification method previously detailed becomes, in this case, inoperative. By lack of specific guidelines, the external code is constrained to collect without discernment all the available data by the means of a global Dump or external Traces. In addition of the disadvantages inherent to the Dump or Trace usage, this situation forbids:

One object of the present invention is, when a Major Error occurs, to provide an efficient and very simple data selection method ensuring a high quality and integrity of the information collected with a minimum impact on the performance and the resources of the data processing system.

The data capture includes means for describing the pertinent data to collect before loss of control of the faulty program occurs. In a preferred embodiment, the program preventively declares in a list all the data to capture in case of Major error. In a second stage, at the key points of the code, the pertinent sets of data in the list are activated. On the occurrence of an error, only the data previously declared and activated are collected by the external code in charge of the error reporting.

The invention is attached to the global data capture strategy and particularly to the Error Notification and Selective Dump processes.

The present invention contributes to an efficient and an high quality software development and maintenance.

FIG. 1 illustrates the main characteristics of the different prior art debug tools commonly used and the situation of the present invention in the context of the global data capture strategy.

FIG. 2 describes the Task Data Table used by the Major Error Notification process in accordance with the present invention.

FIG. 3 describes the Data Field Descriptions contained in a Task Data Table in accordance with the present invention.

FIG. 4 illustrates the Major Error Notification general mechanism in accordance with the present invention.

FIG. 5 illustrates the basic operations involved in the data declaration and capture process in accordance with the present invention.

FIG. 6 describes a data processing system particularly adapted to an implementation of the present invention.

FIG. 7 illustrates the Major Error Selective Dump general mechanism in accordance with the present invention.

The general process of the error handling can be summarized by the following steps:

FIG. 1 illustrates the place of the present invention in the context of a global data capture strategy. This strategy has been conceived in function of constraints which can be described in term of:

The capacity of the different methods to satisfy theses requirements can be measured on the basis of two criterions: the selectivity and the dynamic (represented in the figure respectively on the horizontal and the vertical axis). By selectivity, it is meant the capacity of a tool to target the most pertinent information at a given time. The dynamic, on the other side, is representative of the ability to follow the progress of a piece of code and its execution path during a defined time interval.

The main characteristics of the different data capture tools commonly used are listed hereunder: selective mode (until several mega bytes of data generated) to investigate an error. However, it can represent the only solution when the control program or the processor becomes inoperative requiring the complete restart of the system. related to the code in error. Two types of data are particularly useful for the problem determination: contribute to the general understanding of the error in the system: system Traces, registers, stacks . . . occurrence of the error.

The amount of data collected during a Selective Dump can vary from ten to several hundreds of kilobytes depending on the complexity of the problem to solve.

The Unsolicited Dump is requested from inside the processor by the code itself; the Solicited Dump as is activated from an operator console or by any external maintenance system. and dynamic view of the code execution. However, to limit the impact on the system performances, their content is limited to the strict minimum. Internal Traces are managed by the faulty program itself and are usually reported by means of the Error Notification (Minor or Major) or Selective Dump mechanism. component. They complete the Internal Traces in that they allow a general investigation, in deferred mode, of the code progress, under the condition, of course, to be able to reproduce the problem. or hardware, permanent or transient, is responsible for creating and reporting an error record whose function is to identify the situation with the first available data needed to understand what is going on. This record is generally composed of: with some general information such as the time of day, the error type . . . context of the faulty application and are usually mentioned under the generic term of FEDC for First Error Data Capture. Because of performance constraints, the error record is generally limited in size to some hundreds of bytes and a Selective Dump is, most of the time, required to complete the information. operations and the error is detected by an external code endowed with extended privileges. This code reports an error record with the data previously declared by the program before is becomes inoperative. This Major Error Record is similar to this reported in case of Minor Errors with the difference that the error data are captured in place of the faulty program and are for this reason less accurate and selective. In most of cases more than one kilo bytes data are necessary to identify and isolate the problem. The object of present invention concerns the way the data are described before a Major Error occurs and the way they can be selectively captured by the external error code in case of failure. error or to trigger an automatic alarm or an immediate recovery. It completes the information already collected by the Major Error Notification process and authorizes an extensive investigation of the problem in deferred time from a console or from any problem management system. The principle of the data declaration and activation is similar to that implemented in the Major Error Notification process. The data report method, as for it, is conventional and will not be detailed in the present description.

FIG. 2 describes the Task Data Table used by the Major Error Notification process in accordance with the present invention.

Generally, to optimize the system resources in function of the specific needs of the applications, the code is divided in logical subsets called Tasks. A Task is an independent entity recognized like that by the Control Program supervising the execution of all applications. Each Task is supposed to represent a particular application and is attributed some specific resources in the system. The Major Error Notification is a process dedicated to any Tasks, allowing an external code, common to all the system and that we can call Error Handler, to build an error record in place of a failing Task with information prepared beforehand by the Task itself. This record is reported by means of a channel common to Minor and Major Errors. To be operational at any time, this method requires, at the key points of the code, an update of parameters describing the data needed to understand the problem if it occurs. Each Task is responsible for its own data in a table called Major Error Task Data Table (MJEN_TDT). The different Task Data Tables (MJEN_TDT) are shared with the Error Handler, are unique for each Task and divided in a certain number of subareas called Major Error Families (MJEN_FAMILY) themselves containing the description of the data fields to capture.

For performance reasons: initial period in the Task Data Tables (MJEN_TDT) realized at the key points of the code by the update of an area shared with the Error Handler called Activation Table (MJEN_AT). This table is located in the Task environment to allow a direct access at the activation time.

To limit the storage occupancy: exact requirements of the Tasks. entered in the Task Data Tables (MJEN_TDT) duration of the allocation and are deleted after that.

To guarantee the integrity of the data descriptions: and is addressed indirectly by the Task by means of service procedures.

In a data processing system, two types of memory are generally used by the Tasks, each one requiring a particular mode of data declaration: The data in the static memory are declared in the Task Data Table (MJEN_TDT) once for all at the beginning of the code progress. the code. The declaration of dynamic data in the Task Data Table is done temporarily, just during the time of the allocation.

The Major Error Notification process is entirely based on the anticipation capacity of the Task with regard of an hypothetic problem. Nobody else better than the Task is able to realize the best choice in term of type and quantity of information to activate for an error which has not yet occurred.

As illustrated on the FIG. 2, the Task Data Table (MJEN_TDT) (200) is logically structured as follows: manage the table according to the storage constraints of the system: each one composed of: by the Error Handler to capture the right data

What is called Activation is the fact for a Task to update a table shared with the Error Handler with the identification of the right Family (MJEN_FAMILY) to handle in case of error. The direct access by the Task to this table called Major Error Activation Table (MJEN_AT) minimizes the impact of the activation process on the code performance. In return the fact that this table is located in the Task environment does not ensure the total integrity of the information after the error has occurred: the solution presented here is not any more than a compromise between performance and protection and can be modified according to the particular conditions of the implementation. Two types of Families are used is always active and is reserved for the description of the data common to all Major Errors described in the Task. It avoids to consume entries in the Task Data Table (MJEN_TDT) for identical information. associated one and only one specific Family only one can be active at the same time and a new activated Family replaces the previous one.

At minimum only one Family is active, the Common Family (MJEN_FAMILY.sub.-- 00) and at maximum two, the Common and the activated Specific Family (MJEN_FAMILY.sub.-- 00 & MJEN_FAMILY_XX).

FIG. 3 describes the Data Field Descriptions contained in the Task Data Table in accordance with the present invention.

Each Family (MJEN_FAMILY) previously defined is organized as follows: by the Error Handler. To each active Family can be associated until 5 error records: the Task specifies for each entry (see appendix MJEN_ADDITION_P) the number of the record under which the Data Field has to be reported. retrieve the data from the memory space of the Task:

FIG. 4 and FIG. 5 illustrate the general mechanism and the basic operations related to the Major Error Notification process in accordance with the present invention. its own Task Data Tables (MJEN_TDT) by means of two service procedures (see appendix for more details) defined Task Data Table the beginning of the code execution and for storage reasons, the Common Family (MJEN_FAMILY.sub.-- 00) is defined prior to all others. after the other at the key points (KP X) of the code. At each key point a Family is selected (404) by the Task in the Activation Table (MJEN_AT) (405) and the situation is described with a specific parameter called Major Error Identificator (406). a defined period of time. The data stored in this dynamic memory can be declared (407) for the duration of the allocation. After that the entry in the table is deleted by means of the procedure: Table operations. The Control Program (410) detects the error and calls the Error Handler (411) to capture and report the appropriate data. The Error Handler is a specific code shared will all the Tasks in the system and endowed with extended privileges such as (not exhaustive list): Activation Table (MJEN_AT) the identification of the Common (MJEN_FAMILY.sub.-- 00) (412) and Specific (MJEN_FAMILY_XX) (404) Families activated at last key point. From the descriptions, length, address, name . . . contained in the Data Field Descriptions (MJEN_DFD) (413), the right data (414) are retrieved from the Task memory space. creates and reports a Minor Error Record with its own information (First Error Data Capture (FEDC) and with the maximum of System Data like the (not exhaustive list):

In a second stage, it builds a Major Error Record with the Major Error Identificator (406) retrieved from the Activation Table (MJEN_AT) and with the data captured by means of the Family previously selected. This record is reported through the same path as the Minor Errors. But, owing to the fact that the volume of the data to report is more important for a Major Error, until ten kilo bytes in most cases versus some hundreds of bytes, it must be necessary to adapt the size of the Major Error Record to the capacity offered by the traditional report mechanism. For performance reasons, transfer time and storage capacity, the Major Error Record is split in several distinct records not exceeding the size of a Minor Error Record. The way the data are split and the error records built is under the responsibility of each Task: with each Data Field Description entry, the Task specifies the number of record under which the data must be reported (see appendix MJEN_ADDITION_P). That means that for each active Specific Family, the Fault Handler associates from one to five chained error records. All these records are correlated with a specific correlation indicator according to a well known process.

The objectives related to the Selective Dump process can be summarized to the following considerations: Notification process, for an extensive investigation of the problem in deferred mode. The data captured are not strictly limited to the error data but includes functional data for a better understanding of the problem and its context. transferred, in term of time and storage, to the console or to the maintenance subsystem performance the data to dump. This is possible by providing service functions to the applicative code to define dynamically the areas to dump. process is not interrupted by application when it has started.

According these constraints, the Selective Dump process is organized in a way which is very similar to the Major Error Notification Process. This means that: capture and to dump. Table (MJSD_TDT) and declares the data fields to dump application, the pertinent data sets within the Task Data Table (MJSD_TDT) are selected at the key points of the code the declared data.

A Selective Dump is constituted of the following elements: be useful for the general understanding of the problem: stack, register, system Trace buffer . . . The System Data are directly collected by the Error Handler. the appropriate Dump procedures. They are divided in three types: The Public Data represent a general interest for all the applications and are described in a Public Data Table (MJEN_PDT) shared with all the Tasks of the system. This table has the same structure as the Task Data Tables (MJEN_TDT) but is organized around a unique Family permanently activated. are described in the Common Family (MJSD_FAMILY.sub.-- 00) within the Task Data Table associated to the Task. This Common Family is activated each time the Task is operational. The Specific Data should constitute the most valuable debug information. They are described in the so called Specific Families (MJSD_FAMILY_XX) activated at the key points of the code.

Compared with the Major Error Notification Process, the Selective Dump extends the data capture area to Tasks. By this means, the Tasks can select data in their own environment and declare them as general interest for all the Dumps in the system. Functional Data are related to the Task functionality and to the general execution of the operations independently to any error condition.

The general structure of the Selective Dump and Error Notification Task Data Tables is the same and is illustrated in the FIG. 2 previously described. The content of the Data Field Descriptions differs, as for it, on two points compared with FIG. 3: more reported to the maintenance subsystem by means of chained records but in a file. because in most of the cases, the Public Data captured have not been declared by the faulty Task itself but by other Tasks in the same system.

Each Family (MJSD_FAMILY) is organized as follows:

FIG. 7 and 5 illustrate the general mechanism and the basis operations related to the Selective Dump process in accordance with the present invention. its own Error Notification and Selective Dump Task Data Tables. The Selective Dump Task Data Table (MJSD_TDT) is created by means of two procedures (see appendix for more details): (MJSD_TDT) in the Error Handler environment. The Public Data Table (MJSD_PDT) is under the direct control of the Error Handler and has not to be defined by the applications. in the Task Data Table (MJSD_TDT) previously defined or in the Public Data Table (MJSD_PDT). the beginning of the code execution. For storage reasons the Common Family (MJSD_FAMILY.sub.-- 00) is defined prior to all others. after the other at the key points (KP X) of the code. The Task selects the proper Dump Family by updating the Family identification parameter (704) in the Selective Dump Activation Table (705) (MJSD_AT). This table is located in the Task environment and its access is shared with the Error Handler (711) a defined period of time. The data stored in this dynamic memory can be declared (707) for the duration of the allocation. After that the entry in the table is deleted by means of the procedure: Task Data Table (MJSD_TDT) operations. The Control Program (710) detects the error and calls the Error Handler (711) to manage the capture and report the appropriate data. the Activation Table (MJSD_AT) (705) the identification of the Families, common (MJSD_FAMILY.sub.-- 00)(712) and Specific (MJSD_FAMILY_XX) (704) activated at last key point. From the descriptions contained in the Data Field Descriptions (MJSD_DFD)(713), the right Common and Specific Data (714) are retrieved from the Task memory space. The Public Data are, as for them, retrieved from the descriptions contained in the Public Data Table (MJSD_PDT) whose Family is permanently activated. Most of the Public Data having not been declared by the Task itself, their capture overrun the limited space of the Task. The System Data are not described in the Task Data Tables (MJSD_TDT): for that reason their selection and capture are under the entire responsibility of the Error Handler. All the data retrieved are transferred to a dedicated area in the Error Handler environment to release as soon as possible the applications resources frozen by the Control Program during the Dump process. creates and reports a Minor and Major Error according to the Error Notification process previously described. reported according a classic method which is not the object of the present invention. In our case the Minor Error record previously reported notifies a maintenance subsystem of the presence of a Selective Dump File ready to report. The error Notification records and the Selective Dump are correlated by the means of a specific indicator to make easier the problem determination at the maintenance subsystem level.

Major Error Notification and Selective Dump are particularly adapted to multitasking and multiprocessing environments. The system illustrated on FIG. 6 and described hereafter is typical of the context inside which the present invention can be implemented. This data processing system is composed of: configuration, change management and problem analysis

The whole system represents approximately half a million lines of code.

The program exceptions are specific to the processor 80486 and are detailed in the INTEL Programmer's Reference Manual. They handle Major Error conditions detected by the processor 80486 itself in the course of executing instructions.

All the data captured in the subsystems are reported to the console for analysis.

The following values are characteristic of the present environment: (Common & Specific Data)

Observations:

The Major Error process is suitable to all operating systems.

The partition of the code in Tasks such as defined previously for the Major Error Notification and Selective Dump is particularly adapted to the multitasking operating mode. This segmentation in independent applications converges with the organization of multitasking processors such as the 80486.

The impact of the Major Error process on on the architecture of an application is very limited and allows an easy adaptation of the reuse or multi-source codes.

The development of the code necessary for the present invention requires preferably the use of highly structured and strongly typed languages like ADA, C/C++ . . . well suited for the creation of complex, massive and software intensive systems.

The specific procedures related to the Major Error Notification and Selective Dump process are detailed in the following paragraphs:

MJEN_INITIATION_P

This procedure is called by the Task to configure the logical space used to declare the data to collect in case of Major Error. This logical space, called Major Error Task Data Table (MJEN_TDT) is: (MJEN_FAMILY) themselves containing the description of the data fields to capture.

To adapt the storage resources to the particular needs of each task, the number of Families (MJEN_FAMILY) and of Data Field Description (MJEN_DFD) must be declared by the applicative code before to be operational.

The code calls the MJEN_INITIATION_P procedure with a list of input parameters: subscribing Task subscribed by the Task Descriptions (MJEN_DFD) subscribed by the Task really attributed to the task. The identification of these the Family is defined as a range of contiguous values starting from zero. attributed to the task. This number depends of the storage available at the required time. initiation procedure.

MJEN_ADDITION_P

This procedure is called after configuration of the Task Data Table (MJEN_TDT) to store in the Families (MJEN_FAMILY) the description of the data the Task would like to capture in case of Major Error.

The code calls the MJEN_ADDITION_P procedure with a list of input parameters subscribing Task contain the declared data field. description of the data field defined hereunder Family (MJEN_FAMILY) previously defined Description (MJEN_DFD) returned by the procedure operation.

MJEN_DELETE_P

This procedure is called to remove a Data Field from a Family.

The code calls the MJEN_DELETE_P procedure with a list of input parameters: requesting the removal of the data field. removed. A specific value indicates the request of the complete clearance of all Families. remove from the Family. A specific value allows the delete of all entries of a same Family. operation

MJSD_INITIATION_P

This procedure is called by the Task to configure the logical space used to declare the data to collect in case of Major Error. This logical space, called Major Error Task Data Table (MJSD_TDT) is: (MJSD_FAMILY) themselves containing the description of the data fields to capture. number of Families (MJSD_FAMILY) and of Data Field Description (MJSD_DFD) must be declared by the applicative code before to be operational.

The code calls the MJSD_INITIATION_P procedure with a list of input parameters: subscribing Task subscribed by the Task subscribed by the Task really attributed to the task. The identification of these the Family is defined as a range of contiguous values starting from zero. attributed to the task. This number depends of the storage available at the required time. initiation procedure.

MJSD_ADDITION_P

This procedure is called to add a Data Field to a Family.

The code calls the MJSD_ADDITION_P procedure with a list of input parameters: requesting the service. Public means that the Data Field is to be included in all the performed dumps. Its description is entered in the Public Data Table managed by the Error Handler. Specific and Common Data Fields are, as for them, entered in the Task Data Table (MJSD_TDT) of the declaring Task. dumped at the same time. previously declared: Description (MJSD_DFD) returned by the procedure with the maximum length authorized. operation

MJSD_DELETE_P

This procedure is called to remove a Data Field from a Family.

The code calls the MJSD_DELETE_P procedure with a list of input parameters: requesting the removal of the data field. specific value indicates the request of the complete clearance of all Families. remove from the Family. A specific value allows the delete of all entries of a same Family operation

## Claims

1. A selective method for capturing data in software exception conditions (Major Errors) during the operation of a data processing system, said system operating with at least one task, each said task being endowed with a dedicated memory space and being executed on instruction of a control program, characterized in that it involves the steps of: data table being divided into a certain number of subsets (Families 206) execution, the data fields, permanently defined in the memory of the task, which are relevant for the Major Errors anticipated by the task, the task, the data fields, dynamically defined by means of a temporary memory allocation, which are relevant for the exception condition (Major Error) anticipated by the task, appropriate subset (Family 206) in an activation table (405 or 705) unique for each task, identifying the faulty task, Handler 411 or 711), said code being endowed with a priority level higher than the level of the tasks and being authorized to access the tasks memory, pertinent data fields from the descriptions (208) contained in the last subset (Family 206) selected in the activation table (405 or 705) associated with the faulty task.

2. The selective data capture method according to claim 1 characterized in that the descriptions in the the data table (Task Data Table 200) of the data fields dynamically defined are deleted after release of the temporary memory allocated to the task.

3. The selective data capture method according to anyone of claims 1 and 2 characterized in that the data fields (414) described in data tables (Task Data Table 200), one data table for each task, contain all the information to identify potential program exceptions and the corresponding failing elements, said data fields (414) are the object, when a program exception occurs, of an error notification to a maintenance subsystem.

4. The selective data capture method according to claim 3 characterized in that the data fields (714) described in data tables, one data table for each task, contain all the information required to understand potential program exceptions within the general context of the operations, said data fields (714) are the object, when a Major Error occurs, of a file transfer to a maintenance subsystem.

5. The selective data capture method according to claim 4 characterized in that each data table (Task Data Table 200) contains in one side a common subset (Family 209), permanently selected, with data fields descriptions common to all potential program exceptions identified in the task and on the other side specific subsets (Families 206) with data fields specific to each potential exception condition, only one specific subset (Family 206) being selected at the same time.

6. The selective data capture method according to claim 5 characterized in that the data fields of common interest for all the tasks and all the program exceptions in the system are described in a public table shared by all the tasks, said table containing a unique subset (Family 209) permanently selected.

7. The selective data capture method according to claim 6 characterized in that: the data tables (Task Data Tables 200) and the public table are located in the memory space of the error handler code (411 & 711), and each activation table (405 & 705) is in the memory space of its associated task.

8. The selective data capture method according to claim 7 characterized in that: the data tables (Task Data Tables 200) definition, the entry and delete of the data fields descriptions (208) are realized synchronously by the tasks by means of service procedures common to all the tasks.

9. In a data processing system including operating system, an application program having at least one task running thereunder and an Independent Error Handling program running under the operating system, a method for selectively capturing data under software exception (Major Error) conditions including the following steps: Independent Error Handling program domain, said Table being divided into a plurality of subsets (Families 206) each of which includes a description of data fields in the task memory which are relevant to exception condition (Major Error) anticipated by the task; predetermined and appropriate subset (Family 206) in an activation table (405 or 705) shared with the Independent Error Handling program; in a task, transferring control to the said Independent Error Handling program along with authority to access the task memory and at a priority level greater than the task priority level; and, descriptions (208) contained in the last subset (Family 206) selected in the activation table associated with the failed task.

10. The selective data capture method set forth in claim 9 in which the data fields described in the task data table, include information for identifying potential program exceptions and corresponding failing elements, said descriptions may be used as the object of an error notification to a maintenance subsystem.

11. The selective data capture method set forth in claim 9 in which the data fields described in the task data table, include information required to understand potential program exceptions within the general context of the operations, said data fields may be used as the object of a file transfer to a maintenance system when a Major Error occurs.