Abstract: Tailoring diagnostic information specific to current activity of multiple threads within a computer system. A request to dump system state is received. A system dump is created, including main memory and system state information. The system dump is stored to a database. In response to a request to format the system dump, the system dump is loaded from the database, whereby a virtual memory image of system state at system dump time is created. The virtual memory image and system state information is scanned to identify tasks that were running, tasks that have failed due to an error, and tasks that were suspended at system dump time. State information and control blocks associated with the identified tasks are collected from the system dump and collated based on task number. The database is updated with a formatted system dump, including the state information and control blocks associated with the identified tasks.

Abstract: Techniques are provided for executing, by one or more first processors, one or more software products associated with a measured usage pricing model. An indication is received, during the execution of the software products, to execute a set of diagnostic machine instructions related to the execution of the software products. Responsive to that received indication, the one or more first processors initiate execution, by one or more distinct second processors, of the set of diagnostic machine instructions. The initiating of the execution by the distinct second processors of that set of diagnostic machine instructions is based at least in part on such execution not being associated with the measured usage pricing model.

Abstract: Techniques are provided for executing, by one or more first processors, one or more software products associated with a measured usage pricing model. An indication is received, during the execution of the software products, to execute a set of diagnostic machine instructions related to the execution of the software products. Responsive to that received indication, the one or more first processors initiate execution, by one or more distinct second processors, of the set of diagnostic machine instructions. The initiating of the execution by the distinct second processors of that set of diagnostic machine instructions is based at least in part on such execution not being associated with the measured usage pricing model.

Abstract: Techniques are provided for executing a software product that includes a plurality of machine instructions and that is associated with a measured usage pricing model. The executing of the software product includes tracking the usage of one or more computing resources for executing the software product in accordance with the associated measured pricing model. The executing also includes, for each of multiple sets of machine instructions, determining whether the set is associated with a token indicating that the set is a set of diagnostic machine instructions related to the executing of the software product. For each of those multiple sets of machine instructions, the executing of the software product further includes, responsive to a determination that the set of machine instructions is associated with the token, not tracking the usage of the one or more computing resources during execution of that set of diagnostic machine instructions.

Abstract: Tailoring diagnostic information specific to current activity of multiple threads within a computer system. A request to dump system state is received. A system dump is created, including main memory and system state information. The system dump is stored to a database. In response to a request to format the system dump, the system dump is loaded from the database, whereby a virtual memory image of system state at system dump time is created. The virtual memory image and system state information is scanned to identify tasks that were running, tasks that have failed due to an error, and tasks that were suspended at system dump time. State information and control blocks associated with the identified tasks are collected from the system dump and collated based on task number. The database is updated with a formatted system dump, including the state information and control blocks associated with the identified tasks.

Abstract: Tailoring diagnostic information specific to current activity of multiple threads within a computer system. A request to dump system state is received. A system dump is created, including main memory and system state information. The system dump is stored to a database. In response to a request to format the system dump, the system dump is loaded from the database, whereby a virtual memory image of system state at system dump time is created. The virtual memory image and system state information is scanned to identify tasks that were running, tasks that have failed due to an error, and tasks that were suspended at system dump time. State information and control blocks associated with the identified tasks are collected from the system dump and collated based on task number. The database is updated with a formatted system dump, including the state information and control blocks associated with the identified tasks.

Abstract: Techniques are provided for executing a software product that includes a plurality of machine instructions and that is associated with a measured usage pricing model. The executing of the software product includes tracking the usage of one or more computing resources for executing the software product in accordance with the associated measured pricing model. The executing also includes, for each of multiple sets of machine instructions, determining whether the set is associated with a token indicating that the set is a set of diagnostic machine instructions related to the executing of the software product. For each of those multiple sets of machine instructions, the executing of the software product further includes, responsive to a determination that the set of machine instructions is associated with the token, not tracking the usage of the one or more computing resources during execution of that set of diagnostic machine instructions.

Abstract: Techniques are provided for executing a software product that includes a plurality of machine instructions and that is associated with a measured usage pricing model. The executing of the software product includes tracking the usage of one or more computing resources for executing the software product in accordance with the associated measured pricing model. The executing also includes, for each of multiple sets of machine instructions, determining whether the set is associated with a token indicating that the set is a set of diagnostic machine instructions related to the executing of the software product. For each of those multiple sets of machine instructions, the executing of the software product further includes, responsive to a determination that the set of machine instructions is associated with the token, not tracking the usage of the one or more computing resources during execution of that set of diagnostic machine instructions.

Abstract: Tailoring diagnostic information specific to current activity of multiple threads within a computer system. A request to dump system state is received. A system dump is created, including main memory and system state information. The system dump is stored to a database. In response to a request to format the system dump, the system dump is loaded from the database, whereby a virtual memory image of system state at system dump time is created. The virtual memory image and system state information is scanned to identify tasks that were running, tasks that have failed due to an error, and tasks that were suspended at system dump time. State information and control blocks associated with the identified tasks are collected from the system dump and collated based on task number. The database is updated with a formatted system dump, including the state information and control blocks associated with the identified tasks.

Abstract: Techniques are provided for executing, by one or more first processors, one or more software products associated with a measured usage pricing model. An indication is received, during the execution of the software products, to execute a set of diagnostic machine instructions related to the execution of the software products. Responsive to that received indication, the one or more first processors initiate execution, by one or more distinct second processors, of the set of diagnostic machine instructions. The initiating of the execution by the distinct second processors of that set of diagnostic machine instructions is based at least in part on such execution not being associated with the measured usage pricing model.

Abstract: Techniques are provided for executing, by one or more first processors, one or more software products associated with a measured usage pricing model. An indication is received, during the execution of the software products, to execute a set of diagnostic machine instructions related to the execution of the software products. Responsive to that received indication, the one or more first processors initiate execution, by one or more distinct second processors, of the set of diagnostic machine instructions. The initiating of the execution by the distinct second processors of that set of diagnostic machine instructions is based at least in part on such execution not being associated with the measured usage pricing model.

Abstract: Techniques are provided for executing a software product that includes a plurality of machine instructions and that is associated with a measured usage pricing model. The executing of the software product includes tracking the usage of one or more computing resources for executing the software product in accordance with the associated measured pricing model. The executing also includes, for each of multiple sets of machine instructions, determining whether the set is associated with a token indicating that the set is a set of diagnostic machine instructions related to the executing of the software product. For each of those multiple sets of machine instructions, the executing of the software product further includes, responsive to a determination that the set of machine instructions is associated with the token, not tracking the usage of the one or more computing resources during execution of that set of diagnostic machine instructions.

Abstract: Performance data for a healthy system is captured and used to create benchmarks that represent behavior of the computing environment in a healthy state. Current behavior (e.g, run-time characteristics) of the computing environment are monitored in an on-going manner, and are compared to the benchmarks. When a benchmark is violated, performance data capture is dynamically and automatically enabled. Or, if performance data is already being captured, then performance data capture may be enabled for a larger subset of possible data. Optionally, performance data capture may be automatically disabled upon detecting that the current behavior of the computing environment has returned to a healthy state where benchmarks are no longer violated.

Abstract: Performance data for a healthy system is captured and used to create benchmarks that represent behavior of the computing environment in a healthy state. Current behavior (e.g, run-time characteristics) of the computing environment are monitored in an on-going manner, and are compared to the benchmarks. When a benchmark is violated, performance data capture is dynamically and automatically enabled. Or, if performance data is already being captured, then performance data capture may be enabled for a larger subset of possible data. Optionally, performance data capture may be automatically disabled upon detecting that the current behavior of the computing environment has returned to a healthy state where benchmarks are no longer violated.

Abstract: A multithreaded computing environment for capturing diagnostic data includes initiating a trap delay component having a delay threshold in response to a monitor determining that the computing environment is in a predetermined invalid state. The multithreaded computing environment for capturing diagnostic data also includes recording, by a first thread, diagnostic data for the computing environment. The trap delay component delays the step of recording diagnostic data until the monitor determines that the predetermined invalid state has been repeated for at least one of a total count or a period corresponding to a predetermined indicator that it is a state other than a transient state of the computing environment. The transient state corresponds to a transition of the computing environment by one or more other threads from a first valid state to a second valid state.

Abstract: Identifying conflicting declared invalid runtime references of overlaid data structures of a shared memory area as declared in a program listing. The identifying includes identifying a first data structure and a first parameter list in the program listing. A first routine call and a sequential flow of execution of the first routine call through the program listing in order to write data to the shared memory area are identified. A second data structure and a second parameter list in the program listing are identified. A second routine call and a second sequential flow of execution of the second routine call through the program listing in order to write data to the shared memory area are identified. It is determined whether the second routine call is attempting to overwrite data of the first routine call with the data of the second routine call in the shared memory area.

Abstract: Performance data for a healthy system is captured and used to create benchmarks that represent behavior of the computing environment in a healthy state. Current behavior (e.g, run-time characteristics) of the computing environment are monitored in an on-going manner, and are compared to the benchmarks. When a benchmark is violated, performance data capture is dynamically and automatically enabled. Or, if performance data is already being captured, then performance data capture may be enabled for a larger subset of possible data. Optionally, performance data capture may be automatically disabled upon detecting that the current behavior of the computing environment has returned to a healthy state where benchmarks are no longer violated.

Abstract: A multithreaded computing environment for capturing diagnostic data includes initiating a trap delay component having a delay threshold in response to a monitor determining that the computing environment is in a predetermined invalid state. The multithreaded computing environment for capturing diagnostic data also includes recording, by a first thread, diagnostic data for the computing environment. The trap delay component delays the step of recording diagnostic data until the monitor determines that the predetermined invalid state has been repeated for at least one of a total count or a period corresponding to a predetermined indicator that it is a state other than a transient state of the computing environment. The transient state corresponds to a transition of the computing environment by one or more other threads from a first valid state to a second valid state.

Abstract: Identifying conflicting declared invalid runtime references of overlaid data structures of a shared memory area as declared in a program listing. The identifying includes identifying a first data structure and a first parameter list in the program listing. A first routine call and a sequential flow of execution of the first routine call through the program listing in order to write data to the shared memory area are identified. A second data structure and a second parameter list in the program listing are identified. A second routine call and a second sequential flow of execution of the second routine call through the program listing in order to write data to the shared memory area are identified. It is determined whether the second routine call is attempting to overwrite data of the first routine call with the data of the second routine call in the shared memory area.