The InnovationQ application will be updated on Sunday, May 31st from 10am-noon ET. You may experience brief service interruptions during that time.
Browse Prior Art Database

Unattended Monitoring of Random, Multi-Client DB2* Stress Workload

IP.com Disclosure Number: IPCOM000015188D
Original Publication Date: 2001-Oct-12
Included in the Prior Art Database: 2003-Jun-20

Publishing Venue



Disclosed is a method to automate the monitoring of a system test workload in an environment where data is randomly generated from testcase to testcase. This method will notify the system tester or developer only in the event of an error condition. This in turn frees up time spent unnecessarily monitoring the testcase in the absence of errors. In most automated environments a scheme to check results without user intervention exists. In most cases that scheme involves maintaining an expected results file. The output of the testcase is then compared to the expected results. If there are any differences, these are reported to the user. This works very well in an environment where the testcases are static. It is impossible to use this method in a multi-client environment where the output/results of testcases the "users" would run is random. This situation arises in most system test environments. Here is a sample situation. The system tester has a suite of C applications with embedded SQL (Structured Query Language). These applications use a random seed. Based on this random seed the application will generate data. Each pass through the application can generate different results depending on the seed. A manual check of the database instance by the user can determine the status of the testcase. In a fully automated environment the system tester should not have to manually intervene if the testcase is still running (i.e. there are no problems). The problem to solve is to provide a series of checks that can be automated such that the user is only notified when there is a problem. In a DB2 environment, the status of a testcase can be verified by looking at a few key items. 1. Monitor timestamp of last client log